The short version
- A coordinate is recorded when you send one — to clock in, to clock out, or to say you are on your way. And, if your agency has turned it on and you have agreed to it, while a visit is open your phone sends its position about every two minutes.
- Only while a visit is open. Not overnight, not between visits, not on a day off. When you clock out it stops, and there is no timer running at any other time.
- Your administrator cannot see where those positions are. They see how far you are from the client and when that was measured — a distance and a time, no map, no coordinates. The database itself refuses to show them anything else.
- Positions sent while you are on shift are deleted after 7 days. The rest of the trail after 30. The arrival and departure points on a visit stay with the visit.
- You can decline, you can withdraw later, and you can delete the positions already collected — all from Settings, all immediate, none of it affects your job.
What actually causes a coordinate to exist
Four of the five things that create a coordinate are things you did. The fifth is a timer, it only runs while you are clocked in, and it is described in full below.
- You clock in by sending your location.The coordinate is checked against the client’s address, and the visit opens with your arrival point on it.
- You clock out by sending your location. Optional — clocking out without one always works, and the distance is recorded but never enforced. Somebody who has walked to their car must still be able to end their shift.
- You press “on my way” and then send a fix, so the office can see the round is covered before you arrive. Two presses, deliberately: one tap could not be told apart from the tap that opens a visit.
- Your clock-in is refused for being too far away. Where you were standing is recorded alongside the refusal, so somebody can look at it rather than the system simply saying no.
The fifth: while a visit is open, your phone sends its position about every two minutes. This only happens if your agency has switched it on and you have agreed to it. It starts when you clock in and stops when you clock out. It uses the low-power position estimate — roughly the accuracy of a nearby wifi network or a phone mast, not satellite GPS — so it costs very little battery and is deliberately not precise.
It only runs while the app is on your screen. On an iPhone this is not a choice we made: a web app is frozen the moment you switch to another app, and nothing can wake it. So in practice it sends while you are looking at it and stops when you put your phone away. If a visit goes quiet for twenty minutes, the bot texts you a link you can tap to confirm you are still there — tapping it does not clock you out, and ignoring it does nothing at all.
Your agency can also switch on automatic clock-in. With it on, opening the app while you are standing at a client who is both on your roster and on your schedule for today starts the visit for you. You are told straight away, and replying NO to the message cancels it immediately — the visit is deleted and a note goes to your administrator saying the automatic guess was wrong. It reads your position when you open the app and at no other time, and if you are not at a scheduled client, nothing is stored at all: the reading is discarded rather than kept as a record of where you were.
These are the boundaries it is built to, and they are what you are agreeing to. Each one is enforced by the software rather than by a policy somebody has to remember: only while a visit is open — the database will not store a position that is not attached to one; deleted after 7 days; revocable by you at any time; deletable by you at any time; readable by you; and never triggered by an administrator, because there is still no way for anyone to ask your phone where it is.
Where coordinates are stored — all six places
There are six places in this system where a coordinate can end up. Not five, and not “a location table” — an inventory that is only approximately true is not an inventory.
| Where | What puts it there | How long |
|---|---|---|
| Arrival point on a visit | Recorded when you clock in, if you clocked in by sending a location. Frozen — if the client's pin is moved later, this keeps saying where you were. | Kept with the visit record |
| Departure point on a visit | Recorded when you clock out, if you sent a location to do it. Clocking out without one is always allowed. | Kept with the visit record |
| A location you sent as a message | If you send a location through the messaging channel, that message is stored like any other message you send, with its coordinates on it. | Kept with the message trail |
| The position trail | Each fix you send outside a clock-in — the "on my way" ping — and a copy of the clock-in and clock-out fixes, so the office can see movement across a day. | Deleted after 30 days |
| Positions sent while you are on shift | The every-two-minutes stream, if your agency has it on and you have agreed. Your administrator cannot read these at all — only a distance calculated from them. You can delete them yourself at any time. | Deleted after 7 days |
| A refused clock-in | When a clock-in is refused for being too far from the client, where you were standing is recorded with the refusal, so the refusal can be reviewed rather than just enforced. | Kept with the exception record |
A single clock-in therefore writes a coordinate in more than one place: onto the visit, where it is part of the record of that visit, and into the position trail, where it expires. They serve different purposes and have different lifetimes, which is why they are not the same row.
How long each one is kept
Positions sent while you are on shift: 7 days, deleted automatically. Shorter than everything else, on purpose. These are the ones a timer produced rather than ones you chose to send, there are hundreds of them per shift, and nothing about proving you did your job depends on them — that is the arrival and departure pair on the visit, which is stored separately and is not affected. A minute-by-minute record of an employee’s movements, kept longer than it is useful, is only a liability.
The rest of the position trail: 30 days. This is enforced by the software itself, not by a policy somebody has to remember. Where you were on an ordinary Tuesday is not a record an agency needs, and keeping it is pure liability for them.
Coordinates that are part of a visit record: as long as the visit record. A visit is the evidence that care was delivered, and it is normally retained for as long as the payer requires — six years is the common answer under Medicaid record-retention rules, and your agency’s own agreement is what actually governs. Retention periods are described in the Privacy Policy.
Be clear about what the software does and does not do: the only automatic deletions in this system are the 7-day and 30-day trail expiries. Nothing else deletes itself on a timer. Longer retention periods are contractual and are carried out by people, not by a job that runs at midnight.
What your administrator sees
Proximity, not a live trail.What the office sees against a visit is how far you were from the client’s address at the moment you clocked in — a distance and a verified-or-not mark. That distance is frozen when the visit opens: if somebody later moves the pin for that client’s home, your record keeps saying what was true when you were at the door.
They also see the position trail for the last 30 days, which is the “on my way” pings you sent plus your clock-in and clock-out points. That is a list of moments you created, not a continuous track — there are gaps between them, and the gaps are most of the day.
They do not see the positions your phone sends during a shift. At all. This is the part worth reading twice, because it is the opposite of what you would expect. Those positions exist in the database and your administrator is not permitted to read a single one — not filtered out of a screen, not hidden behind a setting: refused by the database, for every tool they could ever use to ask.
What they get instead is one sentence, calculated for them without the coordinates ever leaving the database: “Last confirmed 6 minutes ago: at Eleanor’s (within 30 m).” A distance, rounded to the nearest ten metres, and how old it is. Never a position, never a series of them, and never a sentence that claims to be current — every one of them names a time, because a reading from twenty minutes ago shown as though it were live is worse than showing nothing.
You can see everything they can see about you. Your own fixes are readable by you in the app. That is a rule written into the database, not a screen we chose to build: if your position is recorded, you get to read what was recorded.
What this system does not do
Stated as flatly as possible, because these are the fears:
- There is no button anywhere that makes your phone report its position. Not for an administrator, not for support, not for us. It does not exist as a disabled feature or a permission — there is no such endpoint in the system.
- Nothing keeps reporting after you close the app or clock out. There is a timer now — it is described in section 02 and it is the honest exception to what this page used to say — but it runs only while a visit is open and only while the app is on your screen. There is no background service.
- Nothing is recorded off shift. When you are not clocked in and have not pressed anything, no coordinate is created. This one is not a promise about our code being careful: the database will reject a position that is not attached to an open visit, so a bug cannot cause it either.
- Your location is not used to decide your pay or your shifts. It verifies that a visit happened. Scheduling and pay are your agency’s decisions and are made by people.
- Nobody outside your agency sees it. Location is not sold, not shared with advertisers, and not used to build a profile of you.
Declining, and withdrawing later
You can say no when you are asked, and you can change your mind afterwards from Settings. Both are one press. Nobody has to approve it and you do not have to give a reason.
Withdrawing takes effect on the next fix. It is not a request that gets processed — the next time the software would write a position for you, it reads your decision and does not.
What declining covers is the trail, not the act of clocking in. Sending your location is how a visit opens, so if you clock in that way, that arrival point is on the visit record — you put it there, on purpose, and it is the thing that proves you were at the door. Declining stops everything else: nothing is sent during a shift, no “on my way” pings are kept, no visit ever starts by itself, and no separate position history is built up about you.
You can also delete the positions your phone sent during your shifts. One button in Settings, no approval, and it tells you how many it removed. That is a separate act from withdrawing: withdrawing stops the next one, this removes the ones already taken, and for data a timer collected rather than data you chose to send, being able to stop it without being able to delete it would be a thin promise.
What deleting does not cover:your clock-in and clock-out points. Those stay on the visit, because that record is the agency’s evidence that care was delivered and it is not yours or ours to edit after the fact — the same reason nobody else can edit it either. The “on my way” pings you sent expire on their own within 30 days. If you want something else removed, ask your agency; they hold the records.
Your decision is recorded, and so is every change to it. Not as a setting that gets overwritten, but as a list of decisions with dates. You can read your own list in Settings. That protects you as much as anyone: nobody can later claim you agreed to something you did not.
Accuracy, and what a verified stamp means
A phone’s position is an estimate. It is worse indoors, worse in cities, worse in bad weather, and worse on an old handset. A clock-in can be refused when you are genuinely at the door, and it can succeed from the pavement outside.
That is why a refusal is not the end of it. A refused clock-in is recorded as an exception for an administrator to look at, and you can clock in anyway by naming the client and saying what happened — that visit is marked as needing review rather than being blocked. A verified stamp is evidence, not proof, and a missing one is a question rather than an accusation.
The same applies in reverse: a verified stamp means a phone reported a coordinate near an address. It is good evidence and it is not a certainty, and no part of this system should be treated as if it were.
Questions
About a record with your name on it, or to ask for a copy or a correction: contact your agency. They hold the records; Annalog provides the software.
About this document, or about how the software behaves: privacy@annalogcare.com.
If anything on this page turns out not to match what the software does, the software is wrong and we want to know. This document is meant to be checkable.