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.
- Department
- A team inside an organisation that owns some of its data, such as Cardiology.
- Dataset
- A named collection of records, such as a table of patient admissions.
- Version
- One sealed state of a dataset. Changing the contents means making a new version, never editing an old one.
- Sealed
- Finished and closed for good, so that it can never be edited.
- Access level
- How restricted a dataset is. Raw is the most restricted, and nobody may read it without permission. Published is the most open.
- Custodian
- A person who holds the data custodian role, which allows deciding who may read data. A custodian decides for the departments they are an approver for.
- Request
- A written ask to read one dataset for one stated purpose. The custodian of the department that owns the dataset decides it.
- Purpose
- The reason a person states for reading data. A lease covers that purpose only, unless the custodian chooses otherwise.
- Lease
- Permission, given by the custodian, to read one dataset for one stated purpose and for a limited time.
- 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.
- Run
- One execution of an agent or a pipeline, started for a stated purpose.
- Gate decision
- The final step of a pipeline, where a person decides whether a dataset version may be released to a more open access level. The person who started the run may not decide it.
- De-identification reviewer
- A role that allows a person to review data from which identifying details have been removed, and to decide whether it may be released.
- Open for annotation
- An access level above Under review, where people who label data may work with it.
- Release
- A decision to let a dataset version be read more widely than before. A release changes who may read it and moves no data.
- Under review
- The access level of something that no person has reviewed. Nobody may use it until a reviewer decides that it may be released.
Devi registers a pipeline of their own
A pipeline is a series of steps that Munitas runs on a dataset version, each step after the ones it depends on. Munitas offers a starter pipeline, De-identify these recordings, but an organisation may need checks that no starter can know about. Devi, a data engineer in the Cardiology department, needs cardiology notes checked for the fields that Cardiology's quality reporting requires, so Devi registers a pipeline for that.
The page lists the pipelines registered in the Health organisation, each with an owning department and a version number. Nobody in Health has registered one yet, so the list is empty and the page says so.
Devi types a name and chooses Cardiology as the owner. A department is a team inside an organisation that owns some of its data. Ownership says which department is answerable for what the pipeline does. The name ends in a date and a number so that each example has a name of its own.
Registering created a name and an owner and nothing else. The page says so, and offers the upload of the first version below.
A version is two files. The first, cardiac-note-qc.yaml, names each step in order and says which steps each one depends on. The second is a zip of the scripts that those steps name. This pipeline has two steps: check_notes, Devi's own script, and decide, a gate that comes last.
Munitas checked that every step's dependencies and every script that a step names were present, and then sealed version 1, which means finished and closed for good. A sealed version is never edited: a change is registered as the next version.
decide depends on check_notes. The heading below reads Upload the next version, and says there is no editing in place.A dataset comes in, and Devi has to ask
Registering a pipeline gives Devi no right to read any data with it. A cardiology note still has to be registered and sealed as a dataset, and a request to read it goes to the custodian of the department that owns it. A custodian is the person a department trusts to decide who may read its data.
A dataset is a named collection of records, and Munitas decides who may read it. Devi names it, gives Cardiology as the owner, and leaves the access level at its default. The form does not ask what kind of data it is, because the platform reads that from the files once they are sealed. The access level says how restricted a dataset is, and Raw is the most restricted level.
Devi uploads consult-note.txt, a one-line cardiology note, and seals the version. After sealing, nothing can be added to it. A later upload becomes a new version.
The version page offers a place to run a pipeline, and under Your access it explains that the data is more sensitive than Devi's own role may read. A request is a written ask to read one dataset for one stated purpose. Devi fills in the purpose, the reason that something less sensitive would not do, and how long access is needed.
Devi cannot approve the request, whatever the request says. The page reports that the request has gone to the person answerable for this data, and that nothing is readable until that person grants it.
The custodian of Cardiology decides
Hartley is the data custodian of the Cardiology department, the person answerable for who may read what that department owns, including a note that a Cardiology engineer registered.
Hartley's home page lists the requests to read Cardiology's data. The first card carries everything Devi wrote.
Granting creates a lease, which is permission to read one dataset for one stated purpose and for a limited time. The request leaves the waiting list and moves into the history of decisions.
Devi runs the pipeline
With the lease in place, the version page tells Devi what the access covers, and Devi can choose the pipeline that Devi registered.
In place of the request form, Your access states what the lease covers and until when.
The Pipeline list used to offer only the starter pipeline. It now also offers the pipeline that Devi registered in Part One.
A run is one execution of a pipeline. The run page says what is running, who started it, and what has and has not happened. Nothing is decided or released at this point.
The list of steps is read from what the run reported, so the console shows the two steps of Devi's pipeline and not a fixed list. Under it, the page says that a reviewer has to decide whether the note may be released, and that the reviewer cannot be whoever started the run.
Every pipeline ends with a person's decision
The last step of a pipeline is a gate decision: a person decides whether a dataset version may be released to a more open access level. It works the same way for a pipeline that Devi wrote as for the starter pipeline, and only a de-identification reviewer may clear it. A de-identification reviewer is a role that allows a person to review the result of a pipeline and release it or hold it back.
The decision would move the note from Raw to Open for annotation, an access level above Under review where people who label data may work with it, and the page says this cannot be undone. Devi started the run, so Devi may not clear it.
Imani holds the de-identification reviewer role. A reason has to be written before either button can be pressed, so that whoever reads the record later has the reasoning and not only the outcome.
The note moves from Raw to Open for annotation. The decision and its reason are now part of the record on this page.
