JohnMoehrke Consent with Segmented data
0.1.0-current - ci-build International flag

JohnMoehrke Consent with Segmented data, published by John Moehrke (himself). This guide is not an authorized publication; it is the continuous build for version 0.1.0-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/JohnMoehrke/ConsentWithSegmentation/ and changes regularly. See the Directory of published versions

Security Labeling Service

Page standards status: Informative

Data may be "Normal" medical data or "Restricted" medical data. The distinction is for this IG focused purely on data classificaiton for sensitve topics.

The various clinical Resources in FHIR are very complex and highly varable. Although Observation is the most often used Resource, sensitve data may exist in ANY other FHIR resoruce including Allergies, Procedures, CarePlan, Medication, Problems, DiagnosticReport, DocumentReference, ImagingStudy, Genomics, etc… By assessing the sensitity classification and placing that assessment into a well-known location found in all FHIR Resources - .meta.security, the Access Control does not need to be aware of the kind of FHIR Resource, it can just process the data as a DomainResource and simply look at the .meta.security element.

The classification of data into sensitive topcs is the role of the Security Labeling Service (SLS). The SLS inspects the data, and may use the context of the data to identify the sensitivity classification. It is expected that most data will not be considered sensitive, aka "Normal".

Data tagging Considerations

Some data are directl and clearly in a sensitive category. But there can be indirect relationships, such as three medications prescribed together are a clear indication of a sensitive category but are not individually.

Some data may also not be sensitive in the coding, but rather sensitive in the narrative, this would be poor data quality but it is a reality that should be considered. Thus an SLS may need to include some Natural Language Processing to find sensitive human words in narrative.

Some approaches use well-defined ValueSets, where others use a list of words. The list of words can be search accross the data without regard for the data structure, which has the benefit of not needing to have the SLS data schema aware. The list of words can be codes, such as snomed numeric codes.

Architecture approaches to data tagging

When the SLS is executed is a systems design decision. General alternatives are:

Pre Tagging data

Tagging the data as it is created, updated, or imported.

Pre categorize data within the EHR databaseEHRSLSBatch/New/Updatetagged results


Which has the advantage that the access to the data does not need to assess the data, it just uses the existing sensitvity tag.

Query/Use enforcement based on pre-calculated SLSEHRAppACEQueriestagged resultsenforce rules


This solution is likely to be more performant on use of data, but may not have as accurate sensitivity tags due to the dynamic nature of policies around sensitivty, and dynamic nature of data relationships. This solution also requires that the EHR database support data tags.

Use time tagging data

Alternative is that the data are temporarly tagged prior to use, thus the sensitivity is freshly determined and used only for that access enforcement

Real-Time sensitivty classification at Use/Query/ExportEHRSLSAppACEQueries/Uses/ExportQuery resultstagged resultsenforce rules


This solution does not require that the EHR database be updated to support tagging of data, but may see a performance impact on data use.

Example ValueSets

One way to understand a very basic SLS is that it looks for clinical codes in the data. It might do this using ValueSets, but likely would need to do this in a more performing way.

Example Data with tags

Dependency Table

IGPackageFHIRComment
.. JohnMoehrke Consent with Segmented datajohnmoehrke.consentwithsegmentation#0.1.0-currentR5
... HL7 Terminology (THO)hl7.terminology.r5#6.1.0R5Automatically added as a dependency - all IGs depend on HL7 Terminology
... FHIR Extensions Packhl7.fhir.uv.extensions.r5#5.1.0R5Automatically added as a dependency - all IGs depend on the HL7 Extension Pack
... VSACus.nlm.vsac#0.9.0R4

Package hl7.fhir.uv.extensions.r5#5.1.0

This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, Apr 27, 2024 18:39+1000+10:00)

Globals Table

There are no Global profiles defined