Stream: Argo Write
Topic: Security labels
Josh Mandel (Aug 25 2021 at 21:09):
In my experience "please read the spec" is technically correct advice but rarely an effective persuasion technique:-)
John Moehrke (Aug 25 2021 at 21:10):
yeah, I know.
John Moehrke (Aug 25 2021 at 21:10):
should I do a Josh style 10 minute walking webinar?
John Moehrke (Aug 25 2021 at 21:11):
in the style of "let me read that out loud for you"
Josh Mandel (Aug 25 2021 at 21:11):
I mean, it's worth it a shot. I promise I'll watch ;-)
Josh Mandel (Aug 25 2021 at 21:12):
But a focused argument might be better (my "checklist" series really is just "here's what the spec says"; it's not trying to persuade anyone of anything)
John Moehrke (Aug 25 2021 at 21:12):
understood. The key for me is to understand the audience need.
John Moehrke (Aug 25 2021 at 21:13):
especially when the argument is "seems counter intutitive" so lets use the exact same datatype on an element sitting right next to it.
Josh Mandel (Aug 25 2021 at 21:16):
That's fair. One technical question: is there an existing label that means "supplied by patient or another patient designated representative" (i.e., a roll-up code covering this whole space)? That's what (1) in my post upthread was getting at. I think (2) is indeed covered by an existing concept
Josh Mandel (Aug 25 2021 at 21:17):
And if it helps you craft an argument: I think these use cases have nothing obvious to do with security, by the time the data have landed in a server. It's more like context/provenance. So sticking the information in an element called "security" is indeed counter to my intuitions about where it "belongs".
John Moehrke (Aug 25 2021 at 21:23):
Josh Mandel said:
And if it helps you craft an argument: I think these use cases have nothing obvious to do with security, by the time the data have landed in a server. It's more like context/provenance. So sticking the information in an element called "security" is indeed counter to my intuitions about where it "belongs".
I suspect this feeling is due to a lack of understanding of Security. Too often Security is perceived as only about access control. Security is about managing risks to "Confidentiality" + "Availability" + "Integrity". This is why there are a set of codes to indicate the integrity status of the data. This set of codes indicating the integrity status is where PATAST comes from. There are other codes for indicating that the data is from a payer, etc.; also where the codes are for this data has been degraded by de-identification or summarization.
https://terminology.hl7.org/2.0.0/ValueSet-v3-SecurityIntegrityObservationValue.html
John Moehrke (Aug 25 2021 at 21:24):
note that PATRPT might be an alternative to PATAST. slightly different meaning.
John Moehrke (Aug 25 2021 at 21:26):
BUT, as you point out these codes are specific to the Patient. and not patient delegated devices. this is not a concept that we have run across. So I would be fine with identifying that it is new, and this newness is promulgated by the prominence of FHIR and apps.
John Moehrke (Aug 25 2021 at 21:26):
however it could also be just PATRPT + DEVRPT
Paul Church (Aug 25 2021 at 21:27):
On one hand, the security label is used to "determine what handling caveats must be conveyed with the data". Being patient-supplied is a type of handling caveat, it speaks to the reliability and little-p provenance of the data.
On the other hand, tags are "used to relate resources to process and workflow". If the FHIR Write concept is that patient-supplied resources are landed somewhere before potentially being reviewed/processed and then incorporated into the clinical record (whatever that means), that sounds more like a tag to me as it indicates that some workflow needs to happen.
Another distinction is that an application consuming this data should look at security labels but is under no particular obligation to look at tags. This doesn't seem like a clear-cut decision to me - applications should consider this but there may be nuances about patient-supplied, patient-mediated, device-generated, etc. going beyond meta.security that the application would probably have to look at Provenance to understand. Some applications probably won't care at all.
The general thinking on the Google side (which hasn't turned into anything real yet) is that we like tags because we expect to land data and then take some action on it (validation, connecting references to other non-patient-supplied resources, generating provenance, flagging for review or notification, the list goes on) after which point it might transition to having a different tag. So the tag for "totally unvetted patient input" is a workflow stage rather than something fundamental that has to be carried along with the data.
Josh Mandel (Aug 26 2021 at 00:09):
Indeed, applying these tags on influx was intended to allow for this kind of ingestion workflow without segregating the new data or requiring any particularly workflow.
Josh Mandel (Aug 26 2021 at 00:10):
EHRs are free to strip these tags downstream as they see fit, or to retain them to allow queries that use them to filter data.
Eric Haas (Aug 26 2021 at 01:03):
Here is a draft of an Observation profile to apply these element to observations. Notice the patient supplied tag and the and security integrity label plus all the other elements that we think provide context for the write.
Josh Mandel (Sep 02 2021 at 19:46):
I'm reading but struggling with http://hl7.org/fhir/uv/security-label-ds4p/2021Sep/concept.html#security-labeling-requires-classification
a security label without a Confidentiality code is not a security label because without this minimum bar for entry, such a label would be useless for interoperable access control, and should be regarded as some other type of meta data.
@John Moehrke for a "simple" example like a .meta.security value of PATRPT, the text I quoted seems to day it "is not a security label" because it has no Confidentiality code. But this use case isn't about confidentiality.
(I'm probably taking this quote out of context, but I'm not trying to! I'm reading DS4P for ballot review, and trying to apply it to areas I'm more familiar with to check my own understanding.)
John Moehrke (Sep 02 2021 at 19:52):
Please file a CR. That text is not in my view correct.
Last updated: Apr 12 2022 at 19:14 UTC
