What your support worker sees on day one.
Design · 6 min read
Here's a scenario that happens every week in disability services. A new support worker shows up to someone's house for the first time. They've never met the person. They might be a temp filling in while the regular worker is on leave. They need to know the person's name, their address, their emergency contacts, what's happening today, and what to do if something goes wrong. They don't need three years of case notes. They don't need the person's full medical history. They don't need personal journal entries.
Getting this balance right — enough information for safety, not so much that it's a privacy violation — turned out to be one of the most nuanced design challenges in the whole project.
The problem with "just give them access"
The lazy approach is to give every support worker full access to everything. It's simpler to build. It's easier to explain. And it's a terrible idea.
The client put it bluntly: "Someone recruited yesterday shouldn't see everything that's happened over the last two years." That's not paranoia. It's basic privacy. Case notes contain sensitive information — medical details, behavioural incidents, family situations. A day-one worker doesn't need that context to do their job. And the person receiving care deserves to have that information shared on their terms, not by default.
This is where permission layers go from an abstract technical concept to a real design problem. It's not "admin vs user." It's "what does this specific person need to see at this specific moment in their relationship with the participant?"
What day one actually needs
We mapped it out from the worker's perspective. They're standing at the front door. What do they need?
Address. Obviously. Emergency contacts with tap-to-call, because if something goes wrong in the first five minutes, they need to reach someone immediately, not scroll through a contact list. Key medical alerts — allergies, swallowing risks, seizure history. Not the full medical record. Just the things that matter right now. Today's schedule — what appointments are coming up, what activities are planned. If the person's going to hydrotherapy, the worker needs to know to bring swimming gear. If there's a coordinator visit at 2pm, the worker should know to have the person ready.
That's the day-one view. Clean. Essential. Nothing more. As the relationship develops and the participant chooses to share more, the worker's access can expand. But the starting point is minimal, not maximal.
The participant stays in control
This is the principle underneath the whole design: the participant controls what gets shared. Not the organisation. Not the worker. Not the family. The person whose data it is decides who sees what. That sounds obvious, but it's the opposite of how most care systems work. In most systems, the organisation grants access. The participant is the last to know who's reading their notes.
We built it so the participant (or their nominated decision-maker) can grant and revoke access. A worker leaves? Access revoked. A new worker starts? They get the day-one view until the participant decides otherwise. Family members get a different view again — typically broader, but still controlled by the participant.
It's more work to design than a simple on/off access switch. But it reflects how trust actually works in the real world. You don't hand someone your full life story on day one. You share what's needed. And over time, as trust builds, you share more.
Why this matters for any app with multiple user types
If your app has different types of users — admins and customers, managers and staff, buyers and sellers — you have the same problem at a different scale. What does each person need to see? What shouldn't they see? And how does access change over time?
The temptation is to give everyone the same view and use a role dropdown to differentiate. That's quick to build and terrible for users. A well-designed app shows each person exactly what they need, no more, no less. That requires thinking about each user type's first interaction, their daily interaction, and the edge cases in between.
Start with day one. What does the newest, least-trusted user need to see to do their job? Build that view first. Everything else is an expansion of trust.
Sources
The Privacy Act 1988 (OAIC) - Australian privacy legislation governing collection and disclosure of personal information.
Provider Obligations (NDIS Quality and Safeguards Commission) - Requirements for information management in NDIS services.
Related blog posts:
Building an app with multiple user types?
Book a free 20 minute call. Tell me about your idea. I'll be honest about whether this is the right fit. And if it is, we can start within the week.
Book a free 20 minute call