Privacy

Two different people use this software, and privacy law treats them differently, so this policy does too.

The building — the senior living community or company that pays for When’s My Shift — decides who is in its schedule, what is recorded about them, and who may see it. In the language of privacy law, the building is the controller of that information.

Uoma Labs holds and processes it on the building’s behalf, under their instructions. We do not decide what goes in your record, we do not use it for our own purposes, and we do not carry it from one building to another.

One exception, and it is small. If you fill in the form on this website asking for a look at the product or a conversation about custom work, there is no building in between yet: you gave that to us, we hold it for ourselves, and we are the controller of it. What we keep and for how long is set out below.

The practical consequence for staff: if you want your phone number changed, your name spelled differently, or your record removed, your scheduler can do all three today, and that is the faster road. If they cannot help, write to us and we will work with them.

Three kinds of thing about staff, one about prospects, and nothing else worth calling data.

Your job

Your name, your job title, the department and unit you work in, your target hours a week, and what the software lets you do — caregiver, scheduler, director. Your email address and phone number, if your building gave us either; both are optional, and many people have neither.

Your schedule

The shifts you are on and have been on, shifts you have offered to give away, shifts you have asked to pick up and whether that was approved, time off you have requested with any note you wrote on it and any reason your scheduler wrote back, and the days and times you have marked as preferred or as blackout.

Your sign-in, if you have one

Not everybody does — plenty of people are on a schedule without ever logging in. If you do: the email address or phone number you sign in with, and your password, which is stored only as a salted PBKDF2-SHA256 hash and cannot be read back by us or by anyone who obtained the database. When you sign in we keep a session record with the browser or app you used; the session token itself is stored only as a hash. Failed sign-in attempts are recorded with the identifier tried and the IP address it came from, purely to slow down somebody guessing at passwords, and those rows are deleted after a day.

We also write down each time you sign in and each time you sign out: which account it was, which of the two, when, the browser or app, and where the request came from — the IP address, and the rough place your connection reports, which is usually a city and the name of your phone carrier or internet provider. That is not your phone’s location and is often out by a town or more; it is what the network says about itself, not what your device says about you.

It is there for one reason: so a sign-in nobody recognises can be noticed. If somebody got hold of your password, this is what shows it — a login from a country nobody works in, at an hour nobody works. Nobody at your building sees any of it; it is visible only to Uoma Labs staff, and only when we are looking into a question about an account.

If you turn on notifications, we store the address your device’s push service issued for it, so a message can be sent to that device. That address is not a location and cannot be used to read anything on your phone.

If you asked us for a look

The buttons on the front page open a short form. What you type into it — your name, your email address, a phone number and the name of your building if you give them, and anything you write in the message box — is stored so that we can reply, and for no other reason. The IP address the form was sent from and the browser it was sent with are kept with it, so that one address cannot fill the form over and over. It sits in our own database, and a copy is emailed to us so that we see it.

Run the schedule, and nothing beyond it: draw the board, work out where cover falls short, decide who is allowed to see which building, send the notification that says a shift opened up, and keep you signed in between visits.

We look at a building’s actual data only when we have to — a support question you have asked us about, or a fault we are chasing — and we keep that as brief as the problem allows.

We do not profile anybody, score anybody, train models on your building’s staffing, or make automated decisions about employment. What the software decides is which shifts are uncovered; every decision about a person is made by a person.

Three, all strictly necessary, none of them advertising or measurement — which is why there is no consent banner in your way.

• wms_sessionKeeps you signed in. Set when you log in, cleared when you log out.
• wms_viewing_asOnly ever set for a director looking at the app as one of their own staff, to check what that person sees.
• wms_platform_accountOnly ever set for Uoma Labs support staff, and only while helping a building that has asked for help.

The phone app keeps its sign-in token in the device keychain rather than in a cookie — the same idea, in the place a phone puts secrets.

A short list, deliberately. Each of these holds data only to do the job named, and none of them may use it for anything else.

• NeonThe Postgres database everything is stored in. United States.
• CloudflareRuns the website and the API, and serves them. United States and their global network.
• ExpoPasses notifications to Apple and Google for the phone app. Holds the device address and the text of the notification, which is a line like “a shift opened up” — never a schedule.
• Apple and GoogleDeliver the notification to the phone itself, through the push services built into iOS and Android. The same is true of your browser’s push service if you use notifications on the web.

That is the whole list. There is no analytics provider, no advertising network, no customer-data platform, no session recorder, and no email or SMS provider — the app does not send either.

In the United States. Everything in transit runs over HTTPS, and the database is encrypted at rest by Neon.

Inside a building, people see what their job requires: a caregiver sees their own schedule and the open shifts they could take, a scheduler sees the departments they run, a director sees the building. One building cannot see another, and that boundary is enforced on the server on every request rather than by hiding buttons.

Passwords are hashed, session tokens are hashed, and sign-in links are stored only as a fingerprint of themselves. A copy of the database, in the wrong hands, would still not let anybody sign in as anybody.

A building’s data is kept while they are a customer. Past schedules stay on purpose — a schedule is a record of who worked, and buildings need to be able to look back at it.

Somebody who leaves is marked inactive rather than erased, so the weeks they worked still say the truth; their building can delete them outright instead, and that is their call to make.

Sessions expire after 90 days, or immediately when you sign out. Failed sign-in attempts are deleted after a day.

The record of a sign-in or sign-out is cut back in two steps. After 90 days — the same 90 days a session lasts, so by then the sign-in it describes can no longer be used for anything — the IP address and the location are erased from it. What is left says that somebody signed in to that account, at that time, from that kind of browser, and no longer says from where. The line itself is deleted after 400 days: a year, with enough slack that looking back over last year still finds it.

Both of those steps happen the next time anybody signs in, rather than on a clock of their own. There is no scheduled job in this software, and a window that leaned on one would be a promise that stopped being kept the first time the schedule broke — so the moment a record is written is also the moment the old ones are aged, and every sign-in ages all of them, not just yours. In an ordinary week that is many times a day. If nobody signed in at all for a stretch, a record would wait past its window until somebody did.

What you sent through the form on the front page is kept until the conversation it started is over — either you became a customer, in which case the building’s record takes over and the form entry is deleted, or you did not, in which case it is deleted once we have replied and heard back or stopped waiting. Ask and it goes sooner. There is no automatic clock on it because there is no automatic anything on it: each entry is one person we are meant to write back to.

A device’s notification address is dropped when you turn notifications off, when you sign out of the app, or when the push service tells us the app is gone. When a building stops being a customer, we delete their data on request, and otherwise within 90 days.

Notifications are off until you turn them on, and you can turn them off again in the app or in your phone’s settings. Nothing about the schedule depends on them.

Depending on where you live — California and a number of other states, among others — you may have the right to know what is held about you, to have it corrected, to have it deleted, and not to be discriminated against for asking. Because your building controls the record, start with your scheduler or administrator. If you would rather ask us first, or they are unable to help, dan@uomalabs.com reaches a person, and we answer within 30 days.

We have never sold personal information and have no plans to. There is nothing to opt out of.

When’s My Shift schedules staff. It is not a medical record, not a care plan, and not a place for anything about a resident — no names, no room numbers, no health information. The free-text fields in here — a note on a shift, a reason for turning down time off — are for staffing, and should be written as though a colleague will read them, because one will.

We are not acting as a HIPAA business associate, because the software is not built to hold protected health information and buildings should not put it here.

This is a workplace tool for employees. It is not directed at children, and we do not knowingly collect anything from anyone under 16 except where a building has lawfully employed a young worker and entered them as staff.

When this changes, the date at the top changes with it. If a change matters — new categories of data, a new company touching it — we will tell the buildings using the software directly rather than leaving it to be noticed.

Uoma Labs LLC
dan@uomalabs.com

A real person reads that address. Privacy questions, deletion requests, and “what exactly do you have about me” all go to the same place.