Security Labeling Service

Data may be “Normal” medical data or “Restricted” medical data. The distinction is for this IG focused purely on data classification for sensitive topics.

The various clinical Resources in FHIR are very complex and highly variable. Although Observation is the most often used Resource, sensitive data may exist in ANY other FHIR resource including Allergies, Procedures, CarePlan, Medication, Problems, DiagnosticReport, DocumentReference, ImagingStudy, Genomics, etc… By assessing the sensitivity 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 direct 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 across 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.

Which has the advantage that the access to the data does not need to assess the data, it just uses the existing sensitivity 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 sensitivity, 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 temporarily 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 incur 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.

There are some valueSets that were authored 9 years ago by SAMSA (requires a free login to see the details). This was during a critical point in the early development of the use of Security Labeling. These valueSets are old, but they are informative. Any standards based managed ValueSet would need to be used as input to a organizational use in an SLS. So the fact these are 9 years old is not as important as that they are a well informed base to start with. I have put the SAMSA valuesets into some ValueSets of my own. 

• Set of codes that indicate ETH
• Set of codes that indicate PSY
• Set of codes that indicate SEX
• Set of codes that indicate HIV

Example Data with tags

• Observation of Alcohol Use marked with ETH
• Observation of a Blood Sugar not marked sensitive

MHD Document Responder: patient.identifier chaining

This is a quick article on a requirement of the MHD Document Responder that may be less obvious to some. The specific requirement is related to chained search parameters, like `patient.identifier`;  `source.given` and `source.family`; and `author.given` and `author.family`. These search parameters have a `.` that indicates that one is to search deeper, aka chaining the search value to a different kind of resource and use the results in the primary search.

The requirement is hinted at being special with a mention of FHIR Chaining Parameters:

This use of patient.identifier follows the FHIR Chaining Parameters search methodology.

But these hints might not be enough, because they do not tell you how to solve the requirement, and this is because there are many ways to solve this, and the implementation details of your system are more important than any factor.

The hints just indicate that the parameter provided is to be matched in a chained way. For example with patient.identifier the parameter is an identifier that should be first looked up with the Patient Identity Manager to find the Patient resource that is then used to find the DocumentReference resources.

That hint tells the Document Responder, that when the Document Source chooses to use `patient.identifier` rather than `patient`; that the Document Source is expecting the Document Responder to do this lookup, rather than the Document Source to do that very same lookup. So, it seems reasonable that queries using chained search parameters might be slower than those that are not.

There are cases where this is inverted, such as when the MHD has an XDS or XCA backend; in these cases the use of patient.identifier that is from the Affinity Domain or Community is better than providing the Patient link. As when a Patient link is the search parameter then a MHD front end to XDS or XCA would need to convert the patient link into the Affinity Domain or Community. This case is likely to be a system such that the Document Responder can quickly do this lookup.

Another place where patient.identifier is going to be preferred are environments that have a national patient identifier. In these cases the national patient identifier is more readily available to both Document Consumer and Document Responder. In these cases it is possible that the DocumentReference.subject element could hold both the Patient id link and the national patient identifier.

The chaining of given name and last name are similar but different in how one must support them on the Document Responder given the system design you have.