Security Labels and Transmission Control¶
Introduction¶
A security label on Resource.meta.security travels with a resource and says something about how
it must be handled. This guide gives operational meaning to five of them, for three obligations PHIPA places on a
custodian:
- marking a record that must not be transmitted,
- marking a record ingested under a consent override as purpose-limited, and
- telling a recipient that what they were given is incomplete.
The vocabulary is disclosure control labels.
Every code is an HL7 v3 ActCode RefrainPolicy concept, already a member of R4's security-labels
value set — so a resource carrying one is structurally valid against base R4 without this guide.
That is a statement about the shape of the data and nothing more. It is not a claim that the label is honoured, that any privacy requirement is met, or that the system is compliant with anything.
A label is not an enforcement¶
Nothing about writing NODSCLCD onto a resource prevents it from being transmitted.
The label declares an obligation. A release path has to implement it. This is worth being blunt about because shipping the vocabulary and calling the requirement met would describe a control that does not exist — and the label would then give false assurance to everybody who saw it.
The four labels¶
| Code | Meaning | Use for |
|---|---|---|
NODSCLCD |
No disclosure without consent directive | A record the individual has restricted from transmission |
NORDSCLCD |
No redisclosure without consent directive | A record obtained under an override — see below |
NOAUTH |
No disclosure without the subject's authorization | Where the individual's authorization gates release specifically |
ORCON |
No disclosure without the originator's authorization | Content from another custodian that they control |
The override-ingested case, and why NORDSCLCD¶
Where records are pulled from the provincial EHR under a consent override and ingested here, they must be identified as subject to a consent directive, so that later users know they may be used and disclosed only for the purpose they were collected for.
NODSCLCD would say "do not disclose this without a directive", which is not quite the fact: the
record is here lawfully, under an override that has already been exercised. NORDSCLCD — no
redisclosure without a consent directive — says the true thing: the collection was authorized, and
passing it on needs its own basis.
This is the requirement most often missed in a first pass, because it is a labelling obligation on ingested data rather than on anything the estate authored. Nothing implements it today.
Telling the recipient the record has a gap¶
This is the obligation most often missed, and it is the one with clinical consequences.
PHIPA does not stop at do not disclose. Where a custodian discloses personal health information to another custodian for the provision of health care, and the individual has withheld or withdrawn consent to part of it, the disclosing custodian must notify the recipient — at the first reasonable opportunity — that the information given to them is incomplete.
A receiving clinician who cannot see that the record has a gap will read it as a complete picture and treat the patient on that basis. That converts a patient's privacy choice into a clinical hazard, and it does so silently. Modelling the suppression without modelling the notice implements half of a safety mechanism and ships the wrong half.
The marker is REDACTED, applied
to meta.security on the Bundle, document or packet being released — never on the source record,
which is not itself incomplete.
REDACTED, not SUBSETTED, and the source settles it. Both mark a filtered view and they look
interchangeable. SUBSETTED carries the usage note "This is not suitable to be used when
information is removed for security reasons — see the code REDACTED for this use." SUBSETTED is
for a view narrowed by a configuration option — a summary, an element filter — and using it for a
lockbox suppression would understate a privacy decision as a formatting choice.
The label says something was removed. It deliberately does not say what, or why, or how much: describing the shape of the hole can disclose the very thing the restriction exists to protect.
Confidentiality codes are a different axis¶
R, V, N and the rest classify how sensitive information is. The labels above say what may
be done with it. Conflating them causes a specific, predictable failure.
R4's rule for matching a security label inside a Consent is a high-water mark: "If the consent
specifies a security label of 'R' then it applies to all resources that are labeled 'R' or lower." So
a restriction written against restricted also catches normal, moderate, low and
unrestricted. In a chart where most resources carry no elevated label at all, that is close to
restricting the entire record.
A deployment reaching for a confidentiality code as a transmission control will get a far broader restriction than it intended. The failure over-restricts rather than over-discloses, so it will not cause a breach — it will deny a clinician information they are entitled to.
Who may apply a label, and what a consumer must do¶
Both need deciding by a deployment and neither is settled here. What the model requires:
- A consumer that meets a label it does not recognise must refuse the disclosure, not proceed without honouring it. An unknown handling instruction is not an absent one.
- A label on
Patientdoes not automatically label everything in that patient's compartment. - A provenance link does not automatically copy labels to a derived summary. Propagation to derivatives has to be implemented deliberately, and it is where labelled content most often escapes: a generated summary of labelled sources is new, unlabelled text saying the same things.
Element-level segmentation is not supported¶
Marking individual elements within a resource — inline security labels — is deliberately out of scope for this release.
The reason is that removing a value from a structured element does not remove it from the resource. It
may remain in Resource.text, in a PDF attachment, or in a generated paragraph. Element-level
segmentation requires an explicit processing contract on both sides, and shipping the mechanism
without it would produce resources that look segmented while disclosing the segmented content
through the narrative.
Whole-resource labelling is what this release supports. State at the integration boundary that labelling is whole-resource only, rather than implying finer control than exists.
Enforcement surfaces¶
Where a label has to be honoured, if it is ever honoured at all:
| Surface | What must happen |
|---|---|
Read, search, history, _include / _revinclude |
Apply policy before returning; do not let history or inclusion bypass a label |
| Search metadata and errors | Counts, references and diagnostic text can leak what a filter removed |
| Attachment download | Re-evaluate on every retrieval, including URLs issued earlier |
| Referral and document packets | Evaluate every attachment before assembly |
| Generated summaries | Filter sources before generation; label and govern the output |
| Caches and indexes | Re-evaluate after a label or directive changes |
| Subscriptions and async export | Check policy at delivery, not at scheduling |
| Bulk extracts and reporting | Decide the disclosure and de-identification policy explicitly |
What is not implemented¶
Nothing writes these labels and nothing reads them. No surface in the table above consults
meta.security. Records ingested under a provincial override are not labelled, because no provincial
ingestion path exists yet.
No disclosure is marked incomplete. Since nothing suppresses a record on the strength of a directive, nothing yet has an occasion to. When enforcement is built, the notice must be built with it: a release path that filters without labelling produces exactly the silent, complete-looking record this section exists to prevent.
The vocabulary and its meanings are the deliverable of this release. The enforcement is not.