Stream: implementers
Topic: FHIR Security Partial Display of Instance
Joel Francis (Feb 11 2020 at 21:11):
Hi,
In FHIR is is possible to view certain attributes of a specific resource only? Can an example of how this can be achieved with FHIR Security Labels be shared? If it is posisble, do the FHIR queries depending on the role differ or is it common practice to have the token/username/password in the HTTP header, this means that the query is the same but the security access engine will decide if the request can be fulfilled.
Thanks,
Joel
Lloyd McKenzie (Feb 11 2020 at 23:55):
Systems can absolutely filter what data elements (and even which resource instances) are exposed - be it to a specific user or a specific system. Such filtering rules could take security labels into account in doing this. Alternatively, users can request filtering using the _elements criteria. Typically authentication/authorization is managed via OAuth tokens, but FHIR doesn't mandate a specific mechanism.
Joel Francis (Feb 12 2020 at 00:02):
filtering of data can happen if the trust framework is established between sending and receiving systems is established that all interpret the security labels uniformly but if the same query is executed by two different roles then it is the access engine that uses the labels to determine what pieces of the resource to share? for example if a patient wanted to see a practioner profile but their home address needed to be hidden vs the practioners supervisor viewing the same practioner resource?
Lloyd McKenzie (Feb 12 2020 at 00:06):
It could be driven by system, user, user role, time of day or any other considerations. FHIR doesn't specify what the rules are for determining access, nor the architecture by which the decisions are made. It just defines the data model used to share the information.
Joel Francis (Feb 12 2020 at 00:09):
thanks @Lloyd McKenzie . i think using security labels attached to roles is most logical to hide sections of a resource.
John Moehrke (Feb 13 2020 at 21:19):
Please provide examples of where a Resource type needs sub-level segmentation. I suspect there are some, and the FHIR community needs to see these use-cases as rational for separating that Resource into two or more Resources so that we need mostly only Resource level controls. This is not to say that there will be no cases where sub-level segmentation is needed, just that we should try to avoid cases where sub-level segmentation is going to be needed 80% of the time.
John Moehrke (Feb 13 2020 at 21:22):
As lloyd has pointed out a resource server (authorization enforcement point) can provide a filtered view. If it does, then it should set the flag indicating the data has been subsetted. see the discussion of SUBSETTED on the _elements parameter http://build.fhir.org/search.html#elements
John Moehrke (Feb 13 2020 at 21:23):
seems this should be exposed on the security page, not only on the _summary and _elements section. Can you enter a Change Request?
Brian Postlethwaite (Feb 14 2020 at 02:52):
Sub level segmentation, are you referring to an example where some properties of a specific resource should be filtered based on security context?
If that's what you're looking for, check these examples from the VhDir IG
http://build.fhir.org/ig/HL7/VhDir/Bundle-womens-shelter.xml.html
Note the http://hl7.org/fhir/uv/vhdir/StructureDefinition/usage-restriction extension usage there.
John Moehrke (Feb 14 2020 at 14:31):
Yes I think that is what people are thinking about.. BUT it is an unfortunate divergence from use of security tags, by inventing a non-standard extension and non-standard vocabulary. I would rather we drive this into a standard extension using standard vocabulary. The reason is that the benefit of security tags is that a security layer could process them without knowing the structure of the Resource. I recognize that this is within a specific IG, so has the benefit of only affecting those claiming conformance to that IG.
This might happen in the context of one of the security IG. Possibly as part of the DS4P?
Brian Postlethwaite (Feb 14 2020 at 20:14):
Would love to see it done. The approach we took doesn't require knowledge of the structure, you tag the parts of the resource you want masked to whom.
Would be much happier if it was used as "inspiration" to go into something more core.
Sexurity tags at the top of the resource imply knowledge, and preagreement. This way doesn't.
Brian Postlethwaite (Feb 14 2020 at 20:15):
Vocab, yes would rather use someone else's.
Hans Buitendijk (Feb 17 2020 at 16:29):
Question: Are you indicating that one can apply security tags to attributes, not just Resource (through .meta)? If so, where is it documented how to do so? Is anybody currently using that? v2 has that ability through ARV, but not aware that attribute/field level security tags are in play.
Brian Postlethwaite (Feb 18 2020 at 00:56):
The VhDir IG has it drafted for consideration, and the example of it I've listed above.
Brian Postlethwaite (Feb 18 2020 at 00:57):
To my knowledge isn't used anywhere as yet.
Brian Postlethwaite (Feb 18 2020 at 00:59):
The intent was this was information to be used into the consuming system so that when IT exposed the FHIR resources, it would use that information to mask it on use, depending on the users calling for the data in the secondary system that received the content with masking definitions in it.
Jose Costa Teixeira (Feb 18 2020 at 04:24):
Do we want to tag attributes individually, or do we want to inform at the resource level "the attributes below have the following classifications: ..." ?
Jose Costa Teixeira (Feb 18 2020 at 04:24):
+1 : would love to see this happening
Brian Postlethwaite (Feb 18 2020 at 04:45):
We explicitly tagged the element to reference the consent rules, rather than putting fhirpath refs to the elements (less indirection)
Brian Postlethwaite (Feb 18 2020 at 04:46):
(and had it contained, so that the rules weren't disconnected from the content)
Jose Costa Teixeira (Feb 18 2020 at 05:21):
Putting this on the element level may be adding a lot of metadata, especially if it repeats.
Jose Costa Teixeira (Feb 18 2020 at 05:24):
also, we are putting this in the resource instance - perhaps we could put also this on the conformance resource -
for example -
In this country, the MedicationRequest resource has the following fields classified as "sensitive" - .reason, .supportingInformation, .detectedIssue.
Jose Costa Teixeira (Feb 18 2020 at 05:25):
then the server knows what to do for every resource instance, even if they are not individually tagged.
Jose Costa Teixeira (Feb 18 2020 at 05:25):
(this is just for brainstorming)
Jose Costa Teixeira (Feb 18 2020 at 05:28):
BTW, the draft Permission resource is intended to hold exactly such metadata.
I will update it to have .dataScope as a list of fhirPath expressions - feedback welcome.
Brian Postlethwaite (Feb 18 2020 at 08:20):
If you can constrain based on type, then you're ok. The cases we were dealing with, any property could have been masked. And in the case of addresses and Telecoms, they do repeat, but only some of them need to be masked.
Jose Costa Teixeira (Feb 18 2020 at 08:32):
Not sure I follow - My idea would be to "tag" any property or slice of a resource (or a resource instance), but not to expose that on the property, but rather on the resource metadata somewhere (e.g. using a Permission that says what is tagged).
Joel Francis (Feb 18 2020 at 16:55):
@John Moehrke thanks for the response. To make sure the data is tage as subsetted, can security tags not be used for this purpose. The intent is that if a resource was marked "R" (restricted) then certain key data would not be displayed and this would depend on the framework/understanding setup by the parties involved.
Also can security tags be added for each attribute? I guess I am echoing @Hans Buitendijk question which didn't get answered.
John Moehrke (Feb 18 2020 at 20:15):
The code subsetted is intended to be used in a case where the data has been subsetted for non-security purposes like the use of _summary or _elements query parameter. When the data are removed for security reasons the tag REDACTED should be used to indicate that (Or one of the others as appropriate).
Jose Costa Teixeira (Feb 20 2020 at 11:54):
Also can security tags be added for each attribute? I guess I am echoing Hans Buitendijk question which didn't get answered.
Jose Costa Teixeira (Feb 20 2020 at 11:54):
Not out of the box.
Jose Costa Teixeira (Feb 20 2020 at 11:55):
Security labels are on meta which is in Resource, not in Element
Jose Costa Teixeira (Feb 20 2020 at 11:59):
We just got some requirements for this purpose. An interesting one:
Jose Costa Teixeira (Feb 20 2020 at 12:00):
If the rule is that nurses cannot see the patients' SSN, then nurses can also not search Patients using SSN as criteria.
Jose Costa Teixeira (Feb 20 2020 at 12:02):
While we could use an extension like @Brian Postlethwaite shows, I think this would be best served with a definition in the resource instance metadata or in the profile itself - e.g. "in Belgium, SSN has a classification 'Private'"
Brian Postlethwaite (Feb 20 2020 at 20:58):
The security tag meta is more appropriate for this, as our purpose is for a specific record in a specific resource instance, not a general rule that always applies to the ssn field.
Brian Postlethwaite (Feb 20 2020 at 20:59):
Interestingly, would the nurse be able to search with other identifiers? Drivers license or healthcare card num, but not ssn?
In which case it's a specific system within the identifier.
Jose Costa Teixeira (Feb 21 2020 at 06:41):
in Belgium I think we'll indeed limit visibility on SSN, but not on other ids
Jose Costa Teixeira (Feb 21 2020 at 06:45):
Ok so there are different cases for segmentation / partitioned access to resources:
- by type or profile - all belgian prescriptions have the elements X, Y, Z with a given classification
- by instance - each instance may have some classified items
Jose Costa Teixeira (Feb 21 2020 at 06:47):
I'm thinking of classifying the elements on the logical models, so by type.
Joel Francis (Mar 05 2020 at 13:45):
Thanks @Jose Costa Teixeira this helps.
John Moehrke (Mar 05 2020 at 14:09):
There is a group of security tags specifically defined for indicating in a policy (permission, consent, contract, rules) that there is a requirement to blind XYZ type of data regardless of where that data is within the data schema. Where the valueSet of XYZ includes types of data such as (not a complete list):
*Demographics
*Date of Birth
*Gender
*Living Arrangements
*Marital Status
*Patient Location
*Race
*Religion
*Employer
This in practice can be used as tags on the Resource (meta.security) to indicate that somewhere within this resource is this type of data as an indication of 'meta' about the data. There is discussion that this tags could be on the specific element (specific index of address...). This is an indication of fact, not an indication of policy.
It is the combination of the indication of policy to blind Gender, combined with the processing of Resources with that are tagged as containing Gender; that one then processes deeper that Resource to bind the Gender.
How one tags data is not an easy task. The Security workgroup defined that a 'service' would be able to inspect data and tag it with these meta tag 'decorations'. Likely this service (SLS) would be based on CDS like magic.
The valueSet one uses in a realm will depend on that realm need. It likely will use some of the codes in HL7, but might have other codes beyond (e.g. Belgium SSN)
http://build.fhir.org/security-labels.html
This is all within the DS4P
k connor (Oct 18 2020 at 22:36):
image.png
Re John's list of types of data above - all of these are in the Sensitivity codes - seehttps://build.fhir.org/ig/HL7/UTG/ValueSet-v3-ActCode.html @ _InformationSensitivityPolicy. So a resource in which both DOB and gender have a higher level of confidentiality protection could have a security label with confidentiality = R (restricted), sensitivity = DOB and GENDER, and any compartment to which a requester must belong, e.g., research or care team, any limitations on the purpose of use, obligations, such as redact/mask, and refrains such as NOORGPOL (no disclosure without organizational authorization).
k connor (Oct 18 2020 at 22:46):
I'm curious about Brian's statement image.png Brian Postlethwaite 8:45 PM
"We explicitly tagged the element to reference the consent rules, rather than putting fhirpath refs to the elements (less indirection)" in comparison to the the level of effort a security labeling service takes to parse a resource looking for a sensitive element type based on a meta.security tag. Seems like comparable tasks. And either case, if the policy is to mask a sensitive type/instance, there still needs to be a Privacy Protective Service that does the actual masking. Also, what happens when there's a mix of sensitive types tagged with a security label and sensitive instances tagged inline?
OS (Nov 02 2020 at 20:36):
I'm looking for an approach to partial display as well, and came across this thread. Very interested to see how this could be implemented in the core, as every engagement I've been a part of has had to solve this problem... show different things to different people.
FWIW - solutions I've seen have either fallen into the bucket of a custom service that masks the data (whether on request, or tokenizing/encrypting at rest) OR store different versions of the same resource, and structure those resources accordingly.
Coming from a data engineering background it occurs to me, this is somewhat a problem of how to construct a view on data. That is, given the same source data, can we construct different views on it that can be used to access the data. I know alot of this discussion is how to manage this problem with metadata, but could it be possible to define a different resourcetype that serves as a mask on the base resource? That resource would have the same elements as the base resource, but the value of those fields would describe some sort of transformation on that element, in this case perhaps security operations (tag to scope, encrypt, hide, etc.) but could be extended to other operations (expose as KG not LB, convert MR to Mister, etc etc)....
Then a user would have access to only that view resource (if defined), and you could store different versions of that view for different audiences, rather than duplicating the content wholesale... Also search operations could check the views you have access to prior to completing a search operation. (And similar logic for post-ing/updating resoruces).
Lloyd McKenzie (Nov 02 2020 at 21:24):
Multiple views can work, but get tricky if you allow subsequent update.
OS (Nov 02 2020 at 21:41):
Do you mean the scenario of if I change the underlying structuredefinition? And so lead to 2 classes of resources (one set using the 'old' definition, one using the 'new' definition)?
In that case, (and just shooting from the hip here), you could probably expand the definition of the view resource to include a superset of fields in both definitions. That way, your view could be a living document... Depending on the number of audiences (and views) you have, I'd imagine this would be entirely feasible, and anyway would be the responsibility of the implementer of how they want to plan to manage changes etc.
Am I thinking about this the right way?
John Moehrke (Nov 03 2020 at 01:26):
anything is possible. but we are certainly no longer talking about http REST.
John Moehrke (Nov 03 2020 at 01:29):
I have advocated for a long time that if a Resource definition is found to need sub structure segmentation for Privacy or Security purposes; then the Resource should be broken up into two(or more) Resources. It seems clear to me that these mega Resources may initially seem good, but present operational issues that should be avoided with more intelligent Resource design. I would recommend that you point out specific Resource definitions that present this kind of a problem. Not all will justify breaking up, but some might.
OS (Nov 03 2020 at 19:47):
Thanks for that perspective @John Moehrke - one example I might consider is a practitioner - with NPI, SSN, maybe some other personal information. And lets say we have 3 different audiences - one can see everything, one can see everything but the SSN, and one can only see NPI.
In this case, per your suggestion I'd have to maintain an 'other info' resource, an SSN only resource, and an NPI only resource. Additonally, for the first consumer, I'd have to have logic to make sure they get all three. Also, I'd have to keep all the IDs in sync, etc, and if there's an update that may impact all 3, there's potential transactional complexity there. Not to mention the question of which resource I use as reference. Would you advise using this approach despite the difficulties, or is there another way to approach this?
In my experience, this is cumbersome enough that folks have elected the options I described above, which made me think it might be beneficial to separate the view logic from the storage logic (similarly to an MVC argument). Largely, though, I do agree with your point that resources should be intelligently designed
Lloyd McKenzie (Nov 03 2020 at 19:51):
Having 3 different instances is definitely going to create serious challenges. You don't want some allergies tied to the NPI one and some to the SSN one. Typically you have a single resource instance and then have logic that strips out information the recipient isn't allowed to see and - if appropriate - add on a security tag that indicates the resource has been redacted. That way all of the references still work. If someone tries to update a redacted resource, you'll have to have logic that considers what data exists vs. what they had access to when applying their updates (or deciding if they can safely update at all)
Lloyd McKenzie (Nov 03 2020 at 19:51):
You certainly wouldn't be able to split out the identifiers for a patient from the patient resource itself - because the identifiers don't themselves have independent manageable state and aren't useful outside the context of the Patient resource.
John Moehrke (Nov 03 2020 at 19:56):
Lloyd, don't switch to allergies... the use-case is Practitioner and the variation of sensitivity is Practitioner.identifier... that is my understanding of the use-case
John Moehrke (Nov 03 2020 at 19:57):
With this, there should be no problem with View.. right? a subset of the Practitioner can be returned with SSN removed, and this marked as a subset (much like a summary is marked as a subset).
Lloyd McKenzie (Nov 03 2020 at 19:57):
What I'm saying is that if you create multiple Patient instances, all of the other resources (allergies, procedures, whatever) can only point to one of them. And that's going to break things.
John Moehrke (Nov 03 2020 at 19:57):
The problem is with Update. right?
Lloyd McKenzie (Nov 03 2020 at 19:57):
You should only ever have one Patient.id independent of view.
John Moehrke (Nov 03 2020 at 19:58):
Practitioner and .identifier... not Patient and not .id
John Moehrke (Nov 03 2020 at 19:59):
with Practitioner.identifier being subsetted for some users, where those users do have authority to UPDATE... what is the likelyhood of being able to use PATCH rather than UPDATE?
John Moehrke (Nov 03 2020 at 20:00):
Practitioner.id is consistent regardless of full or subset returned.. just like how summary is handled.
John Moehrke (Nov 03 2020 at 20:02):
right @OS ?
John Moehrke (Nov 03 2020 at 20:05):
There are even security label tags that can indicate that the full version of the Practitioner contains sensitive (e.g. SSN), and that is why you got a subset -- #ABSTRED -- this is used just like #SUBSETTED --> http://hl7.org/fhir/v3/SecurityIntegrityObservationValue/vs.html
John Moehrke (Nov 03 2020 at 20:06):
actually I think #REDACTED is likely more proper
John Moehrke (Nov 03 2020 at 20:10):
I would very much like to see these kind of use-cases get formally documented so others can get guidance on some methods that can be used. As it stands they tend to not be discussed openly, and thus many feel there are no solutions.
OS (Nov 03 2020 at 20:20):
Lloyd McKenzie said:
Having 3 different instances is definitely going to create serious challenges. You don't want some allergies tied to the NPI one and some to the SSN one. Typically you have a single resource instance and then have logic that strips out information the recipient isn't allowed to see and - if appropriate - add on a security tag that indicates the resource has been redacted. That way all of the references still work. If someone tries to update a redacted resource, you'll have to have logic that considers what data exists vs. what they had access to when applying their updates (or deciding if they can safely update at all)
I certainly share this perspective, though it requires custom logic to strip out the information, which lead to my question of whether it could be done natively in FHIR
John Moehrke said:
Practitioner.id is consistent regardless of full or subset returned.. just like how summary is handled.
I may be a little out of my league here, but I'm not sure I understand. If you take the approach of splitting the resource, how would the practitioner.id be the same, wouldn't each have it's own id? As far as summary, my apologies, could you clarify what you mean there?
I do see the security labels you linked to, but those seem to be specific for Observations. But on the whole, I do very much agree that this would be a great use case to get formally documented and have some suggested patterns to address, as (at least in my experience) it's a very common need.
Happy to help document, or in any way I can.
John Moehrke (Nov 03 2020 at 20:22):
sorry, I was not clear that I had looked at the use-case and then decided that masking was the best approach for THAT use-case. meaning that use-case is not a good one for breaking up a Resource that was overengineered.
John Moehrke (Nov 03 2020 at 20:23):
the security labels are intended to be used with ALL resource types. they are NOT observation specific
John Moehrke (Nov 03 2020 at 20:23):
it is true that observation tends to bring to the surface the need more than others..
Lloyd McKenzie (Nov 03 2020 at 20:28):
Defining what data to strip is something they're theoretically trying to define in an automated fashion with contract, though even that's sort of magic. CQL might be able to do it too.
John Moehrke (Nov 03 2020 at 20:31):
things like identifiers are easy... you have a set of assigning authorizes that are considered sensitive.,..
https://www.hl7.org/fhir/identifier-registry.html
so any identifier with the assiging authority of http://hl7.org/fhir/sid/us-ssn
John Moehrke (Nov 03 2020 at 20:31):
this rule could be put into a "Security Labeling Service"...
John Moehrke (Nov 03 2020 at 20:32):
This is very much what General IT Security does with "Data Loss Prevention". This is general IT security (cybersecurity) tools.
Last updated: Apr 12 2022 at 19:14 UTC
