JohnMoehrke Consent with Segmented data
0.1.0-current - ci-build
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
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".
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.
When the SLS is executed is a systems design decision. General alternatives are:
Tagging the data as it is created, updated, or imported.
Which has the advantage that the access to the data does not need to assess the data, it just uses the existing sensitvity tag.
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.
Alternative is that the data are temporarly tagged prior to use, thus the sensitivity is freshly determined and used only for that access enforcement
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.
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.
ETH
IG | Package | FHIR | Comment |
---|---|---|---|
JohnMoehrke Consent with Segmented data | johnmoehrke.consentwithsegmentation#0.1.0-current | R5 | |
HL7 Terminology (THO) | hl7.terminology.r5#6.1.0 | R5 | Automatically added as a dependency - all IGs depend on HL7 Terminology |
FHIR Extensions Pack | hl7.fhir.uv.extensions.r5#5.1.0 | R5 | Automatically added as a dependency - all IGs depend on the HL7 Extension Pack |
VSAC | us.nlm.vsac#0.9.0 | R4 |
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) |
There are no Global profiles defined