Concept explainer
Apps inherit access
Explains how a tool built in Durin inherits the platform's authorisation, so it shows each person only the data they are already permitted to see.
A tool built in Durin inherits the platform's authorisation. It shows each person only the data they are already permitted to see, because it asks the same access decision every other tool asks.
One authorisation decision
Every read and every write in Pensieve resolves against one authorisation decision, held by Cirith Manager. A built tool asks that same decision. It carries the platform's access model unchanged, so a tool composed by an administrator holds the access rules of the platform rather than rules of its own.
This is the property that makes a built tool safe to publish. The composition adds a screen. The screen still passes through the one decision that guards every other screen.
The patient lens
The record read path applies a patient lens, so a query returns only the records the person is entitled to see. A built tool reads through that same path.
A table in a built tool shows a person the rows their role and relationship allow, and the rest stay outside the query at the boundary. Two people open the same table and each sees their own permitted set.
The projection holds at the boundary
The lens is applied where the record is read, so a built tool receives only permitted rows to begin with. The screen renders what the person may see, because the boundary returns only what the person may see.
The projection
The interface a built tool draws is a projection of the viewer's permissions. Access is decided from two things together: the person's role, and their relationship to the patient in front of them. Role alone opens no record; a current care relationship, established by admission and consent, opens the reach.
Parity with tools
A built tool and a shipped tool behave the same way at the access boundary. Both resolve against the one decision, both read through the patient lens, and both write to the audit trail.
| A built tool | A shipped tool | |
|---|---|---|
| Resolves against the one access decision | Present | Present |
| Reads through the patient lens | Present | Present |
| Writes to the audit trail | Present | Present |
| Holds access rules of its own | Absent | Absent |
The audit trail
A built tool's reads and writes are written to the same audit trail as any tool, inside the same transaction as the change they describe. The access log answers who saw a record through a built tool exactly as it does for a shipped one.
Common questions
Can a built tool widen a person's access?
A built tool carries the platform's access model. Publishing it hands a role the tool, and each person keeps the exact reach they hold everywhere else.
What does a person see if the tool holds rows beyond their reach?
The table returns the rows their role and relationship allow. The remaining rows stay outside the query, so the person sees a set that matches their permissions.
Does emergency access work inside a built tool?
Emergency access follows the same defined path a built tool inherits with every other action, always recorded with the clinician, the time and the stated reason. Read more on emergency access.
Read how the platform decides a single permission.