How to read this page
- Every step is one screen, or one moment, in a real run. The label under the title names where it happens, and the step reads in the same order each time: what is happening, the evidence, and then what to look for in it.
- Screenshots are real pictures of the Munitas console, the web app that people open in a browser. Click any picture to enlarge it.
- Every name of a person, patient or card holder in the example data is invented, and every screenshot is unedited apart from being cropped to the part that matters.
Words used on this page
- Organisation
- A company or hospital group that uses Munitas. Each organisation sees only its own data.
- Dataset
- A named collection of records, such as a table of patient admissions.
- Locked column
- A column whose values are scrambled under a key made for each person. Reading them back needs permission. Destroying a person’s key later makes their values unreadable for good, while the sealed table itself never changes.
- Person code
- A label that stands for one person and means nothing on its own. It replaces the number that identified them.
- Privacy auditor
- A person who checks how locked data was used. The role reads records of use and no personal data.
- Data protection officer
- A person who watches how an organisation handles personal data. The role decides nothing about who may read it.
- Privacy contract
- A file that says, column by column, how identifying each column of a table is and what is done to it when the table is sealed, and how to find the person each row is about.
- Version
- One sealed state of a dataset. Changing the contents means making a new version, never editing an old one.
- Role
- A named set of permissions that a person can hold, such as the permission to decide who may read a department’s data.
- Lease
- Permission, given by the custodian, to read one dataset for one stated purpose and for a limited time.
- Sealed
- Finished and closed for good, so that it can never be edited.
- Pipeline
- A series of steps that Munitas runs on a dataset version, each step after the ones it depends on. The last step is a gate decision.
The auditor checks how locked data was used, and sees no name
A privacy auditor is a person who checks how locked data was used. The role reads records of use and no personal data. Everything that happens to locked data leaves a record, and this page is where those records can be read together.
Marlow holds the privacy auditor role. The page lists every read of locked columns and every opening of locked files, every refusal, every permission with who asked and who decided, and what was done to each column. People appear by name. No name of a patient and no value from any table appears at all.
For each table sealed under a privacy contract, the page lists its columns, how identifying each is, and what was done to it, so an auditor can check that what the contract promised is what happened.
Each patient has a key of their own. It was made when the patient first appeared, and it is opened when their locked values or files are read. The list shows each opening with the time, who did it, why, and a person code, which stands for one patient and means nothing on its own. The pipeline's openings of the recordings appear beside Devi's reading of the table. The same person code appears on lines about the table and on lines about a recording, which is how Munitas shows that the patient in the recording and the patient in the table are one person with one key. A script checked this.
Nakamura is the data protection officer, a person who watches how the organisation handles personal data. The same page is open to that role, with the same limit: it shows how locked data was used and never what the locked data says. A script checked that none of the three patients' names appears anywhere on it.
