Trust
Consent basis on every member
Each member’s row records why they have access — family, healthcare POA, court-appointed guardian. The label that makes the trust story explicit.
The objection nobody says out loud
When three siblings share a workspace for Mom’s care, one of them is thinking — and possibly not saying — "what if my sister snoops?" The medical record of an aging parent is intimate. "Everyone gets to see everything" isn’t the answer everyone wants. Other software gives you that answer by default, and families swallow it because no other option is on offer.
A small label that says why
Every workspace member has a recorded consent basis: family member helping coordinate (the default), patient directly consented, healthcare POA, court-appointed guardian, or executor for post-death access. Not as a permission level — everyone in the workspace can already read and write within their role — but as a record of why their access exists. The basis appears in every audit-log entry, frozen at the moment of the action, so a year later when the family reconstructs a decision the trail stays accurate.
When circumstances change
Six months after the workspace starts, your sister gets named as Mom’s healthcare proxy. She opens her own member row, edits her basis to "Healthcare power of attorney," adds the note "Signed March 14 2026, attorney Jane Miller." From that point forward, every entry she creates is tagged with her new basis. The old entries keep their old label, frozen. The asymmetry is now visible to the rest of the family in a low-drama way — nobody had to wave the POA document.
The longer version
The objection nobody says out loud
When you invite three siblings into a shared workspace for your mother's care, one of them is going to think — and possibly not say — "what if my sister snoops?" The medical record of an aging parent is intimate. Even within a family, "everyone gets to see everything" isn't the answer everyone wants. It's the answer the software gives them by default, and they swallow it because no other option is on offer.
The privacy worry comes from a real place. There are siblings whose relationship with Mom is closer than others. There are family members in different states of estrangement. There are second marriages and stepchildren and ex-spouses. There are situations where one sibling has a healthcare power of attorney and another doesn't, and the legal asymmetry quietly matters more than anyone wants to admit. None of that disappears just because you've all agreed to use the same app.
The traditional answer is "trust each other." Which is fine when it works and corrosive when it doesn't.
What Kintaria does instead
Every workspace member has a recorded consent basis: a small label that says how they have access. Not as a permission level (everyone in the workspace can already read and write within their role) but as a record of why.
The values are deliberately few:
- Family member helping coordinate — the default. Adult children, siblings, partners, anyone helping informally. No documentation expected.
- Patient directly consented — the patient themselves, or anyone they've given explicit verbal or written OK.
- Healthcare power of attorney — you hold a signed POA document.
- Court-appointed guardian — a court has named you guardian.
- Executor — post-death access — reserved for estate executors after death.
The owner sets a basis when they create the workspace. The inviter sets one when they send an invitation. The invitee sees what the inviter picked when they accept, and can change it before joining. Any member can edit their own basis at any time from the workspace home. Every change is recorded.
What this does for the family
Three things, in roughly increasing order of how often they matter.
It surfaces the asymmetry. When everyone's basis says "Family member," that's a kind of equality — three siblings, no formal hierarchy, sharing the load. When one sibling's basis says "Healthcare POA, signed March 2024," that's visible to the rest of the family in a low-drama way. Nobody has to wave the document. The label does the talking. The conversation becomes easier because the legal reality is already on the table.
It makes the audit log readable. Every entry in the activity log records the basis the actor had at the time. So a year later, when the family is reconstructing why a particular decision was made, the record shows not just "Sarah added an appointment" but "Sarah (POA) added an appointment." If circumstances have changed since — if the POA has lapsed, if a guardianship was granted — the historical record stays accurate. Each row is a snapshot of what was true at the time.
It answers the snooping worry. The activity log at /family/[id]/activity is visible to every member of the workspace. Anyone — including the parent themselves, when they have an account — can scroll through and see what their siblings have been doing. Notes they posted. Medications they updated. Appointments they added. Even consent basis changes. There's no admin tier with private access. If your sister opens up Mom's record at 2 AM and reads through everything, the timestamp is in the log and you can see it the next morning. That doesn't prevent snooping — it just makes it visible. Which, in practice, is what stops it.
What we deliberately don't do
We don't verify these. There's no document upload, no court-order lookup, no integration with state guardianship registries. You attest to a basis and that attestation goes into the record. The label is honest about its own limits.
The reason is operational: validating a POA across fifty states would be a legal product, not a caregiving one, and most families don't need it. The right shape of this feature is "the family's own record of who said what about why they have access," not "a regulator-grade legal validation." Families that need the latter usually have lawyers involved already.
We also don't use the basis as an access gate today. A "Healthcare POA" basis doesn't unlock more than a "Family member" basis can already see — both have the same workspace access scoped by their role (owner / caregiver / observer / parent). The label is about provenance, not privilege. If we ever build access scopes that change based on basis (e.g., gating after-death actions on executor status plus a recorded date of death), it'll be a separate explicit feature, not a quiet permission creep.
What this looks like in practice
You set up a workspace for Mom. You pick "Family member helping coordinate" as your basis — it's the default and it's accurate. You invite your brother and your sister. The invite form asks, on each invitation, how they have access — you pick "Family member" for both because that's what they are. They accept. The activity log shows three caregivers, three "Family member" basis labels, and a timeline of everything anyone has done.
Six months later your sister gets named as Mom's healthcare proxy and the document is signed. She opens the workspace, edits her own basis to "Healthcare power of attorney," adds a note — "Signed March 14, 2026, attorney Jane Miller" — and saves. The activity log records the change. From that point forward, every entry she creates is tagged with her new basis. The old entries keep their old basis label, frozen at the moment they were made. The trail stays accurate.
If at some point you need to remove someone from the workspace — a divorce, an estrangement, an executor leaving the role — their record stays in the audit log, labelled by name, with a "removed" pill. They lose all access immediately, but the history they generated is preserved. The next person reconstructing the timeline doesn't hit a wall of unattributed actions.
The basis is not a permission. It's a memory of why this person's access exists, durable enough to outlast the conversation that produced it.
Why this matters
The biggest objection to multi-sibling caregiving software isn't feature parity with the hospital portal. It's the quiet worry that someone in the family is going to see something they shouldn't, or that everyone will discover too late that the wrong person had access the whole time.
The consent basis isn't a fix for either worry. The audit log is. But the basis is what makes the audit log readable to a non-engineer six months from now, when they're scrolling back through history trying to reconstruct what happened. "Sarah added the DNR conversation" raises one set of questions. "Sarah (POA, signed March 2024) added the DNR conversation" mostly answers them.
For families that have always trusted each other, the basis adds nothing visible and costs nothing to set. For families that haven't, or that won't, or that one day might not, it's the answer to a question that would otherwise have no answer.
More of what Kintaria does
Share with a provider
A one-time URL you can hand to a doctor, social worker, or attorney. Read-only, time-limited, revocable.
Learn more →TrustPrint-ready one-pager
A clean PDF summary for the ER, the new specialist, the cardiologist who hasn’t seen the chart. Folds into a wallet.
Learn more →TrustTwo-step sign-in
Text codes or authenticator app. Recovery codes for the emergency. Recommended for every owner.
Learn more →Start your free trial.
Free for 12 months for the founding 500 families. No card, no waitlist.