For rescue teams
This page is addressed to search and rescue organisations, not to the general public. It summarises what myJikita data is, what it is worth in an operational context, and how to obtain it.
What the system holds
myJikita is a consumer application for people moving in the outdoors. When a user starts an outing, the app records a position at a chosen interval between one and ten minutes and transmits it when the device has connectivity.
For an outing, the following may exist:
| Item | Notes |
|---|---|
| Position track | Timestamped positions with accuracy. Recorded at the user's chosen interval; buffered on the device when out of coverage and transmitted later, retaining the original capture time. |
| Capture time vs receipt time | Both are held separately. The difference identifies coverage gaps and prevents a delayed batch being read as fresh movement. |
| Coverage gaps | Positions recorded where the device had no connectivity are marked. Useful for interpreting silence and for assessing whether an alert could have been raised. |
| Planned route | A GPX route the user attached before setting off, where present. |
| Plan metadata | Activity, place in free text, expected return time, party composition. |
| Off-route state | Whether the user deviated more than approximately 200 m from the planned route, and where. |
| SOS | Whether an SOS was raised by the user, and when. |
| Messages | The outing conversation between the user and their contacts. |
| Jikita tag sightings | See below. |
Interpreting the data
A short list of things worth knowing before reading a track.
Capture time is not receipt time. A device out of coverage buffers positions and sends them on reconnection. A batch arriving at 18:00 may consist entirely of positions captured between 14:00 and 16:00. Always read the capture timestamps.
A stationary marker is not evidence. It may mean a stop, a coverage gap, a flat battery, or a casualty. The coverage marking and the capture times distinguish these cases far better than the marker position does.
Interval determines uncertainty. At a ten-minute interval, the subject may have travelled for up to ten minutes beyond the last position. The interval is recorded.
Accuracy varies with terrain. Positions taken against a cliff, in a narrow valley or under dense canopy are less accurate. Accuracy is recorded per position.
Expected return time is user-entered and optimistic bias is common. Treat "overdue by thirty minutes" accordingly, and "overdue by three hours" as significant.
The party may be larger than the track. Only the device that started the outing transmits positions. Listed participants describe the party but are not individually tracked.
Jikita tags
A Jikita is a BLE and long-range-radio tag carried by some users. Relevant operational properties:
- It transmits roughly once per second over BLE, and separately over a long-range low-power network.
- Its broadcast carries its identity, status, battery, motion state, and its own last known position with an age field.
- A tag can assert distress in the clear, readable by any receiver without pairing or ownership.
- Any phone running myJikita reports every tag it hears, including tags belonging to other people. Sightings are buffered when out of coverage and submitted later with the original time of hearing.
- Each broadcast is cryptographically signed by the tag, and sightings are verified server-side. A sighting is therefore evidence about the tag, not a claim by the phone that submitted it.
Practically, this means a tag can be located in areas with no mobile coverage, by long-range radio or by an unrelated passer-by's phone. Tags are identified by a serial number printed on the device.
Direction-finding procedure for locating a Jikita tag in the field with rescue service equipment — to be written with the hardware team and validated operationally.
What the system does not do
- It does not alert you. A user's SOS goes to their nominated contacts, who are instructed to call the emergency services. This is deliberate: it puts a human who knows the subject between an accidental button press and a control room. Expect notification by ordinary emergency call, not by system alert.
- It does not assess risk. No scoring, no automatic flagging, no triage. Every judgement is made by people.
- It does not hold a live feed of all users. Data exists only for outings a user deliberately started.
Obtaining data for an active search
You are set up in advance, not at the moment of an incident
DATALPS provisions each rescue organisation as an organisation in the console, and your operators authenticate as named users within it. There is no request to raise and no callback to wait for during an operation — you already have access, and the access is attributable to the individual who used it.
Search, then access
Two steps, and the distinction matters operationally because only the second one notifies the subject.
1. Search. You can search for a person. A search returns whether they are a myJikita user and, where an outing is running, its name, its date, the expected return time, and whether an SOS has been raised. It does not return their position, their track or their messages.
A search does not notify the person searched for. Searching is how you establish that you are working the right case: ruling out homonyms, people with no shared outing, and people with no connection to the person who called you. Everyone you eliminate at that step is someone you never needed to know anything about, and notifying them would alarm uninvolved people about an emergency that is not theirs.
Use it that way. The search exists so that you open fewer records, not more — narrow to one person first, then access. Opening a record is the step that notifies.
2. Access. Opening a profile, a position or any other information about a person notifies that person by email, at the moment you open it. The email identifies your organisation's Data Protection Officer as the contact point for questions.
The subject then receives nothing for 24 hours regardless of how many actions you take. If your access is still open after 24 hours they are emailed again, and every 24 hours after that. Close an operation out rather than leaving sessions open.
Notification is never deferred or suppressed, and there is no mechanism to request that it be. If an operation cannot tolerate the subject being told, this is not the tool for it.
What is logged, and who answers for it
Every action is recorded with its timestamp, the action taken, and the individual operator who took it. That log is available to your organisation's DPO.
This places a real obligation on your side, and it is a settled position rather than an open question. Once your service accesses the data and decides what to do with it, your service is a separate data controller for that processing — not a processor acting for DATALPS. That is precisely why the subject is given your DPO's contact details and not ours. In practice:
- Your DPO, not ours, answers the subject's questions about what was done with their data and why. The notification email sends them to you.
- Your organisation needs its own lawful basis — ordinarily its public task, GDPR Art. 6(1)(e) — alongside the vital-interests basis covering the disclosure itself.
- A data-sharing agreement between your organisation and DATALPS sets this out.
Access is limited to what is needed for the specific operation. The legal framing is in Who can see your position and in the Privacy Policy.
Interested in working with us
If your organisation operates in an area where myJikita and Jikita tags are in use and you would like to discuss access, integration with your existing tools, or field trials: contact@alpik.fr.