Health organisation walkthroughs: Munitas

Set-up: Departments, Roles and Limits

Before any data arrives, an organisation decides which department owns which data, who may approve access to it, which role each person holds, and what people are allowed to ask for.

1. Health organisation

Before the programme starts: who owns what, and who may do what

Before a research programme brings in any new data, the Health organisation already has its structure in place. The platform administrator walks through it: the departments and who answers for each, the people and their roles, what each role may read without asking, and the limits on what people may ask for.

You will see: The departments with their approvers, the people and their roles, what each role may read without asking, and the limits an organisation has set.

5 steps, about 4 minutes. Open →

Regular data

Data that does not identify anyone, such as a table of hospital admissions counted by ward and quarter. At first nobody can read the table, not even the person who brought it in. A researcher finds it and asks to read it, and the department that owns it decides. The researcher then uses it from a notebook and makes a new table from a query.

2. Health organisation

Bring in a table, and see that nobody can read it yet

A data engineer brings in a table of hospital admissions and a small public list of diagnosis codes. The admissions table starts closed to everybody, including the person who brought it in. The list is registered with a claim that it is open to all, and the custodian of the owning department agrees with the claim.

You will see: Registering a dataset with an owner, a contract and rows checked and sealed as a table, a version that nobody can read yet, and a claim that a custodian agrees with.

8 steps, about 6 minutes. Open →

3. Health organisation

Find a table, ask to read it, and the custodian decides

A researcher is stopped at the table of admissions that a data engineer brought in, and sees only the public lookup. The researcher asks for access with a purpose and a reason, the custodian of the owning department grants it for a limited time, and the table opens.

You will see: Python and the console side by side: a refusal with its reason, a request, the custodian's decision, and rows that could not be read a moment before.

8 steps, about 6 minutes. Open →

4. Health organisation

Sign a notebook in, with a pass that cannot decide anything

A researcher signs a Python notebook in as themself: the notebook shows a code, the researcher types it in the console and approves, and the notebook receives a short-lived pass. The pass cannot decide a request, and the researcher ends it from the list of notebooks.

You will see: A code typed in the console, a page that says what the notebook will and will not be able to do, a refusal of the one thing a notebook cannot do, and the sign-in ending.

10 steps, about 8 minutes. Open →

5. Health organisation

Make a new dataset from a query, under the same rules

The researcher makes a new dataset from a query over the admissions and the diagnosis lookup. Munitas plans it, runs it, and keeps the new dataset as restricted as its inputs. A colleague without access is refused, a query that reaches too far is stopped, and when the custodian withdraws the access the new dataset closes too.

You will see: A plan, a finished dataset that records where it came from, three refusals with reasons, and a dataset that closes when access is withdrawn.

11 steps, about 9 minutes. Open →

Locked patient data

Data that does identify patients, such as consultation recordings and a table of clinic appointments about the same patients. Unlike the admissions table, it names people, so every identifying detail is locked under a key made for each patient. An approver decides who may open a few rows or files. A reviewer decides whether the names have been removed well enough to release the result. An auditor can see how everything was used without seeing a name.

6. Health organisation

Bring in patient data, locked under a key for each patient

A data engineer brings in data that identifies patients. The page first asks whether anybody will ever need to be erased from it. Three consultation recordings are then locked under a key made for each patient, and a table of appointments about the same patients is sealed with what identifies them locked too.

You will see: The question that comes first, every mistake listed before anything is sent, recordings locked and counted without naming anybody, a table refused and then sealed, and what was done to each column.

11 steps, about 9 minutes. Open →

7. Health organisation

Read five locked rows, with an approver's say

The data engineer who brought in a table of appointments is refused its locked names and reasons, asks to read five rows for three days, and the custodian of the owning department decides. A researcher has no way to ask. The platform reports which readable columns could single a person out, and the lease opens exactly five rows.

You will see: A refusal with its reason, a request, the custodian's decision with a note, a report on small groups, and five rows with their locked values opened.

11 steps, about 9 minutes. Open →

8. Health organisation

Open two of the recordings, with an approver's say

The data engineer asks to open three of the locked recordings in the page, for an hour. The custodian allows two, the platform chooses which, and the engineer plays one. When the custodian ends the permission, the files close again.

You will see: A request for files, a custodian allowing fewer, a recording playing in the page, and the files closing when the permission ends.

6 steps, about 5 minutes. Open →

9. Health organisation

Set the standards a result is released under

The data protection officer writes down how much identifying detail a de-identified result may still hold, once for each audience it is released to, as named sets of limits. Everyone in the organisation can read them, and nobody else can set one.

You will see: The page that explains how to read a standard, a first standard written, saved with who made it and when, a stricter second standard, and a reviewer who can read both and cannot change either.

6 steps, about 5 minutes. Open →

10. Health organisation

Remove names from the recordings, and a reviewer decides

The built-in pipeline removes names, dates and addresses from the three locked recordings and is scored against their answer keys. The person who started the run cannot decide the result, and neither can the custodian of the owning department. The de-identification reviewer chooses the standard for the audience, decides with a written reason, and a release widens access by one step.

You will see: A run on real speech, two people refused for different reasons, the same measurement checked against two standards, a reviewer's decision that keeps the standard it was judged by, and a researcher who still cannot read the released result.

12 steps, about 10 minutes. Open →

11. Health organisation

See how locked data was used, without seeing a name

The privacy auditor and the data protection officer read the record of everything that happened to the locked data: who read, who was refused, what was done to each column, and which key was opened and why. No patient's name appears, and the same person code ties a patient's recording to the same patient's row.

You will see: An audit page with no names on it, how each column was treated, and every key opening with its reason.

4 steps, about 3 minutes. Open →

Roles and approvers

A person asks for a role and an approver decides. When a department's usual approver is away, another approver covers for them.

12. Health organisation

Ask for a role, and see who may grant it

A researcher asks to hold a role and cannot decide the request alone. The person who runs Munitas is refused when trying to grant it, and the custodian of a department grants it instead.

You will see: A request for a role, a refusal with its reason, and a grant that nobody has yet confirmed is still needed.

9 steps, about 7 minutes. Open →

13. Health organisation

Cover a department while its custodian is away

The custodian of Cardiology names a colleague from another department as cover. The cover confirms a claim about Cardiology's data on their own, then the custodian ends the cover. The platform refuses to remove the last permanent approver and keeps a record of every change.

You will see: Adding an approver with a reason and an end date, a claim confirmed by the cover, a removal, a refusal with its reason, and the history of who answered for the department.

9 steps, about 7 minutes. Open →

AI agents

A program that works on data is held to the same rules as a person: it asks for access and waits for an approver to decide. A network architect decides which external hosts a version of it may call. The organisation also gives each agent a risk level, two people approve a version that lets an agent do more, and a person checks what an agent produces.

14. Health organisation

Grant an AI agent permission to read a dataset

An AI agent that ranks radiology documents is given a new version of its code and run. The run waits until the custodian of the Radiology department grants it permission to read a dataset, in the same way a person's request would wait, and a second run has to ask again.

You will see: An agent version sealed, a run waiting for permission, a request that names who asked and who will read, and the runs finishing.

9 steps, about 7 minutes. Open →

15. Health organisation

Grant an AI agent permission to call an external host

A data engineer uploads a new version of a radiology agent and lists the one external host it needs to call. The version is sealed but cannot be deployed. Neither the engineer nor the custodian who owns the agent can decide the list: the network architect does, with a written reason. An approved version can then be deployed, and a version whose host is refused cannot.

You will see: A version waiting for a decision with its Deploy button greyed out, two people refused for different reasons, the architect's approval and refusal with their reasons, and what each decision does to the version.

13 steps, about 10 minutes. Open →

16. Health organisation

Set the risk levels for AI agents

The AI risk owner writes a short list of risk levels that says how strictly each kind of AI agent is held. A change to the list, here how often an agent at the Moderate level has to be confirmed again, is saved as a new version with who made it, when and why, and the earlier version is kept. Everybody signed in can read the list, nobody else can change it, and the change reaches the agents held at that level.

You will see: The list of levels with who wrote it and when, the editor with each level's settings, a reason written for a change, a new version and the earlier one side by side, a reviewer who can read the list and has no way to change it, and an agent whose due date moved.

8 steps, about 6 minutes. Open →

17. Health organisation

Approve an AI agent before it can work with patient records

The AI risk owner has written risk levels. A data engineer registers an agent for the Cardiology department and proposes a level, an approver of the department agrees to its first version, and the AI risk owner confirms the level and the version in one decision. A sponsor is named, the agent is listed in the registry, and a later version that adds a tool the platform does not know needs both people again before it can be deployed.

You will see: Risk levels with who wrote them and when, a proposed level waiting for the AI risk owner, a version that cannot be deployed and says why, two different people deciding, a confirmed level with its reason, a sponsor, and a second version approved by both.

19 steps, about 15 minutes. Open →

18. Health organisation

Approve the tools AI agents may add in advance, and decide the rest one at a time

The AI risk owner writes a list of tools the organisation has approved in advance, each with the highest risk level it is approved for, the conditions it is approved under and a date to look at it again. A new version of an agent that adds only listed tools does not wait for the people who would otherwise decide it, or needs only the department that owns the agent. A tool approved only up to a lower level, a tool that is not on the list and a tool that pages a person are each decided by a named person, with a written reason.

You will see: The list with who wrote it and when, a tool added and the earlier version kept, a version approved in advance with the entry that covered it, a version that needs only the department, a version that needs both people, and two versions refused with their reasons.

19 steps, about 15 minutes. Open →

19. Health organisation

Review what an AI agent produced, and show an auditor what was decided

An agent that drafts visit notes from consultation transcripts runs for real in a sandbox. The data engineer who started the run cannot review it, so a reviewer corrects one run and accepts another, and the platform records who decided, when and how soon after the run ended. The data protection officer reads the counts for the agent, makes an evidence pack for an auditor and checks that no record was changed.

You will see: A run waiting for permission, a custodian granting it, three drafts, a form that is offered to the reviewer and withheld from the person who started the run, a correction and an acceptance recorded, counts for the agent, an evidence pack and a check of its records.

16 steps, about 13 minutes. Open →

Custom pipelines

An organisation can write its own pipelines, which are series of steps that Munitas runs on data. A new version first runs only on development data, and a step that reads recordings needs an approver's agreement.

20. Health organisation

Register a custom pipeline, and run it

A data engineer in Cardiology registers a pipeline of their own, asks for access to a note, and runs the pipeline. A reviewer makes the final decision, as for every other pipeline.

You will see: Registering a pipeline, asking for access, running it, and a reviewer's decision.

18 steps, about 14 minutes. Open →

21. Health organisation

Test a new pipeline version on a development sample

A data engineer in Cardiology has written a pipeline version that is still in development, so it may run only on development data. The engineer asks for a sample of the locked recordings, a custodian approves fewer, and the platform draws them. The pipeline version then runs for real on the sample and is refused on the real recordings. The sample ends, and recordings with no real person in them are declared synthetic.

You will see: A request for a sample, a custodian lowering it and the platform drawing it, a sample that says what it is, a run refused on real recordings and working on the sample, a sample that ends, and a declaration of synthetic recordings.

15 steps, about 12 minutes. Open →

22. Health organisation

Approve a custom step before it runs

A data engineer in Cardiology uploads a pipeline with a step of their own that reads recordings and writes files. The platform refuses to run it until an approver of the owning department, who did not upload it, approves it. The run then makes a new version that waits for a review.

You will see: A version waiting for an approver, a refused run, an approval, a finished run that links to what it made, and a new version that records exactly what produced it.

10 steps, about 8 minutes. Open →

Audit

Every request to read data, from a person or a program, is recorded with who asked, what for and why it was allowed or refused. The people who watch can read the record and change nothing.

23. Health organisation

Read every access decision, including every refusal

The data protection officer opens a home page of counts, then the list of every request to read data, newest first, and then only the refusals, each with its date and time, who asked, what for and the reason. Each request is recorded twice, once for whether it was allowed and once for whether the access was given, and reading the record is itself recorded.

You will see: A home page of counts and the latest refusals, every request in one list, the refusals alone with the reason for each, and the auditors' own reading appearing in the list.

3 steps, about 3 minutes. Open →