Stream: implementers
Topic: Composition.confidentiality
Craig Newman (Jan 25 2019 at 19:52):
I'm curious what thoughts folks have on the use of Composition.confidentiality versus the confidentiality code described by security labels (http://build.fhir.org/security-labels.html) is there a particular reason why Composition has an explicit element for confidentiality? Is it better to use it than the security labels? Thanks
Lloyd McKenzie (Jan 25 2019 at 19:58):
I know Structured Documents has been asked to remove the Composition.confidentiality element on the grounds that it's unnecessary and redundant with the security label capability. I don't know where that landed though. @John Moehrke ?
John Moehrke (Jan 27 2019 at 16:17):
The Composition.meta element is the place for security tags about THE Composition. The Composition.confidentiality element holds the sum of all the security tags for all of the things that would be included in a document made from the Composition. My argument to remove it was that the sum total is just combining the total of the parts, but the group indicated that there may be a need to have an adjustment or manually set tag for the whole document that is not simply the combination of the parts. Thus the whole is greater than the sum of the parts... :-)
David Moorhouse (Jul 25 2019 at 01:43):
Given that Composition is a DomainResource and can therefore have a meta node with a confidentiality code, what do you do with a Composition resource that contains both its own confidentiality code and a meta confidentiality code ?
For bonus points, what do you do when the codes are conflicting ?
Grahame Grieve (Jul 26 2019 at 11:01):
I see no one knows the answer to this question. @Rick Geimer can you take this to SD?
Lloyd McKenzie (Jul 26 2019 at 14:23):
There's also an ability to put a security tag on the overall document Bundle.
Rick Geimer (Jul 26 2019 at 16:18):
@Sean McIlvenna I seem to remember that SDWG had a tracker about this. Was there a disposition?
Sean McIlvenna (Jul 26 2019 at 16:58):
@Rick Geimer I believe you are referring to this: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=17301&start=0
Sean McIlvenna (Jul 26 2019 at 16:59):
We need to pick the discussion back up in SDWG.. we left off on it quite a while back saying we needed to reach out to the security WG to see what they thought. I didn't realize that @John Moehrke had commented on that ticket. I need to review his lengthy ;) comment and figure out where to go with it in SDWG.
Sean McIlvenna (Jul 26 2019 at 17:00):
I'm going to put it on next week's agenda in SDWG, if anyone would like to attend
David Moorhouse (Jul 30 2019 at 04:47):
Thanks for the follow up - look forward to the update from the SDWG
John Moehrke (Jul 30 2019 at 18:00):
sorry for the delayed response. I have been away at the IHE face-to-face. This all is related to a concept often referred to as "high water mark", in that any container needs to represent the "high water mark" of the things within the container. This is not always simple math, but is often influenced by policy. Sometimes these policies do enable for down grading some tags because of the target of a communication, or authorization by the patient or sender. I did see some movement on the comment I put into Bundle to express that the concept of "high water mark" should be added to Bundle. This would apply to query results, messages, documents, and any other use of Bundle to contain other resources.
SO, the answer to the original question is not a question for SD, but a question for Security workgroup.
David Moorhouse (Sep 08 2021 at 01:26):
Deleted
Last updated: Apr 12 2022 at 19:14 UTC
