Stream: IG creation
Topic: binding an element of a composit type to a valueset
Mohammad Jafari (Jul 26 2020 at 01:33):
I have an extension of type Contributor. The type in Contributor is bound to the vlueset contributor-type. In our IG we want to bind this to a different valueset defined to include some more codes. Is this possible and how can I do this in the StrucuturedDefinition resource that defines that extension?
https://www.hl7.org/fhir/valueset-contributor-type.html
https://www.hl7.org/fhir/metadatatypes.html#Contributor
Lloyd McKenzie (Jul 26 2020 at 03:46):
You can't. You can't use contributor without using one of the specified codes. However, it seems like a reasonable thing to want to do - can you submit a change request and we might be able to fix that in a future release. (@Bryn Rhodes
k connor (Jul 26 2020 at 17:12):
That won't help if Bryn and Rick have decided to dump Contributor entirely citing our ability to use Provenance/Audit Event as a response to my CR https://jira.hl7.org/browse/FHIR-25223 to add a Contributor extension http://build.fhir.org/metadatatypes.html#contributor on a security label Coding datatype so that the type, name, and contact information for the contributor or "classifier" of a security label can be identified and retrieved.
Problem is that those don't necessarily "stick" to their targets, they merely "point" to them. Security labels are designed to be an integral part of a Resource to ensure that they are persisted. There's also a strong requirement to track metadata about the labels themselves, such as the location of related artifacts upon which they are based, and in particular, who classified/reclassified/declassified the Resource, i.e., the entity accountable for deeming the Resource as governed under a policy.
This use case is particularly important for the current implementation of Controlled Unclassified Information (CUI) markings in the US. All information sourced from a Federal Agency or their contractors are required to carry CUI labels, and the authority that classified the information as CUI. See https://confluence.hl7.org/display/SEC/Controlled+Unclassified+Information+%28CUI%29+Problem+and+Solutions. The requirement explicitly requires the classifier to be included in displays of the markings. See https://www.archives.gov/files/cui/20161206-cui-marking-handbook-v1-1.pdf
If NIEM can handle CUI, it would be sad if HL7 cannnot.
Lloyd McKenzie (Jul 26 2020 at 20:37):
I don't think there's any question about FHIR being able to handle CUIs, is there? We just don't mandate support for it.
k connor (Jul 27 2020 at 02:06):
I wouldn't expect FHIR core to mandate support for a US specific security label. But I would expect that the core would not remove Contributor, which is necessary for supporting CUI in the FHIR US Regulatory Security Labeling IG where specifying the "contributing classifier" would be mandatory to meet the CUI statutory requirements.
Lloyd McKenzie (Jul 27 2020 at 02:22):
The capability will remain - just in Provenance. Contributing classifier wouldn't likely have made it as 'core' for Contributor anyhow, given world-wide adoption.
k connor (Jul 27 2020 at 04:53):
Provenance won't help with the CUI requirements. Guess NIEM it is.
Grahame Grieve (Jul 27 2020 at 04:59):
it's not clear from what you've said why provenance won't help with CUI requirements. Nor is it clear why removing a feature that doesn't do what you need makes any difference to doing what you need. Nor is it clear why you can't use extensions
k connor (Jul 27 2020 at 05:06):
Provenance doesn't persist with the security label as stated above. CUI law requires that the classifier be included and displayed in the banner as stated above. We proposed an extension on Contributor in FHIR DS4P IG Structure definition for the extension-sec-label-classifier extension http://hl7.org/fhir/uv/security-label-ds4p/2020May/StructureDefinition-extension-sec-label-classifier.html
Grahame Grieve (Jul 27 2020 at 05:09):
Provenance doesn't persist with the security label as stated above
I don't see that this is an unresolvable problem. It certainly means you can't use provenance with out some thought and extra rule making but you have to make extra rules as it is. Also, I don't think that the statement per se is strictly true.
CUI law requires that the classifier be included and displayed in the banner as stated above
What are the exact words around "included"? Because I'd be surprised if the law actually deal with such a specific technical issue
We proposed an extension on Contributor
And it was moved, so you move the extension. Unless I've missed the point here
k connor (Jul 27 2020 at 05:17):
The requirement explicitly requires the classifier to be included in displays of the markings. See https://www.archives.gov/files/cui/20161206-cui-marking-handbook-v1-1.pdf. RE proposed extension, my CR to include the extension was dismissed with statement that Contributor metadata is going to be/has been removed. As stated above, in response to Lloyd " 8:46 PM
You can't. You can't use contributor without using one of the specified codes. However, it seems like a reasonable thing to want to do - can you submit a change request and we might be able to fix that in a future release. (@Bryn Rhodes" My response: Bryn and Rick have decided to dump Contributor entirely citing our ability to use Provenance/Audit Event as a response to my CR https://jira.hl7.org/browse/FHIR-25223 to add a Contributor extension http://build.fhir.org/metadatatypes.html#contributor on a security label Coding datatype so that the type, name, and contact information for the contributor or "classifier" of a security label can be identified and retrieved.
Grahame Grieve (Jul 27 2020 at 05:19):
The requirement explicitly requires the classifier to be included in displays of the markings
"included and displayed" is meaningfully different in this context that "included in displays".
Grahame Grieve (Jul 27 2020 at 05:20):
You can use provenance, so far as I can see, or you can still define an extension.
k connor (Jul 27 2020 at 05:25):
We defined an extension as stated. We simply want Contributor to continue to be included in the core for this purpose.
Grahame Grieve (Jul 27 2020 at 05:36):
well, you might be able to convince the committee to do that, but you have other choices. What specific data elements does the Contributer data have that you need?
k connor (Jul 27 2020 at 05:47):
Here's what we have but we need to add a timestamp and in addition to current contributor types we need ones specific to classifiers of national security labels as included in the FHIR DS4P value set @ http://hl7.org/fhir/uv/security-label-ds4p/2020May/ValueSet-valueset-sec-label-contributor-type.html
http://hl7.org/fhir/uv/security-label-ds4p/2020May/StructureDefinition-extension-sec-label-classifier.html
Name Flags Card. Type Description & Constraintsdoco
.. Extension I 0..* Extension Extension
... id 0..1 string Unique id for inter-element referencing
... extension I 0..* Extension Additional content defined by implementations
Slice: Unordered, Open by value:url
... url 1..1 uri "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-sec-label-classifier"
... value[x] I 1..1 (Slice Definition) Value of extension
Slice: Unordered, Closed by type:$this
.... value[x]:valueContributor I 1..1 Contributor Value of extension
doco Documentation for this format
k connor (Jul 27 2020 at 05:48):
Additional note - when US Federal Agency sourced information gets shared internationally, that information will also need to carry the CUI labels and the classifier information.
Grahame Grieve (Jul 27 2020 at 07:28):
what parts of contributer do you need?
I would think you'd be better to define your own extension CUIContributer:
date: date of contribution
role: role of contribution
agent: Reference(Practitioner...)
John Moehrke (Jul 27 2020 at 12:11):
The IG will need to have business behavior defined for the recipient. That business behavior is what drives persistence, not the location of the data. Persisting the CUI, and displaying the CUI information, can be driven by business rules on Provenance just as well as an element. For any system claiming compliance to the IG, they are agreeing to not just the network encoding, but also agreeing to the business rules. I prefer the Provenance pathway as more clean, compact, targeted, and implementable.
Grahame Grieve (Jul 27 2020 at 12:34):
right. So provenance is possible. The question is whether it's desired, and therefore whether to use Provenance or whether to denormalise with an extension
k connor (Jul 27 2020 at 18:08):
Mohammad and I spoke with John during the FHIR Security call, and I think he's ok with our use case for not using Provenance. Hope he will confirm on this thread. I wasn't sure whether having Contributor removed from Core would be a problem for us using it as an extension - as we've already done in the May ballot. Sounds like that's ok, and all we're going to do is add a timestamp and an additional Contributor type for a Security Labeling Service so that system triggered labeling can be tracked in addition to tracking the classifier entity accountable for the selection of a security label. Appreciate everyone's input. K
Lloyd McKenzie (Jul 27 2020 at 18:17):
If Contributor gets yanked, you won't be able to use it. But you're free to define a complex extension that contains exactly what you need
k connor (Jul 27 2020 at 20:12):
RE: Lloyd McKenzie: If Contributor gets yanked, you won't be able to use it. But you're free to define a complex extension that contains exactly what you need.
Is CR https://jira.hl7.org/browse/FHIR-25223 even an open question? Ticket says it's resolved as non-persuasive.
When will I know whether Contributor has been "yanked"? It's still in R5 http://build.fhir.org/metadatatypes.html#Contributor
While I asked for in person resolution, they voted it non-persuasive and no change required. Resolution = "The Contributor data type is being removed on the grounds that it's not being used in any resources and is not terribly consistent with FHIR design principles - FHIR prefers that participations be explicit to allow distinct control over constraints. We're not comfortable retaining the data type solely for this new proposed use-case. As well, we're concerned about throwing a large amount of history data on a single data element. In general, the history of what's happened to a resource is managed using the built-in 'history' capability as well as Provenance and AuditEvent. If you care who changed a security tag (and why), that's the mechanism that should be used."
Resolution is that I need to create a new CR to justify a change request for a disposition decision for which, as far as I recall, I was not notified about occurring. Think the decision needs to be reopened for in person discussion rather than submit a similar CR.
RE Resolution's suggestion to use AuditEvent - AuditEvents are not typically exchanged and have many unnecessary elements for this use case.
RE Resolution's suggestion to use Provenance, adding the need to retrieve Provenance for every security label element, which may change depending on consent directives or exchange of Resource across policy domains has a lot of unnecessary overhead including a trust agreement to generate and make available Provenance Resource for every created/changed security label. Not only is the target (or sub-resource target) needing to be repeated in the Provenance Resource, but the agent, the action, the security labels in the predecessor and in the successor etc.
All that's needed for the Security Label Classifier is the timestamp, name, contact, and role of the classifier. If someone wants a complete accounting, then they may want to retrieve a Provenance Record, e.g., if they want to see which labels changed. But that's more than what's needed to establish the accountability for the label. Reason that matters? As a receiver, I may care about who labeled the Resource in order to know whether I need to enforce/persist it (e.g., because of a Trust Agreement) or whether I can change it per my policy domain.
Provenance info - Why they changed it (their policy), how they changed it (upgraded/downgraded/declassified etc., where the action repeats the classifier functional role type so not informative), from what to what etc. is irrelevant.
Lloyd McKenzie (Jul 27 2020 at 20:31):
FHIR-25223 is closed. You could ask the work group to re-open it, but it seems unlikely they'd do so for this. A standard extension is a better bet.
Grahame Grieve (Jul 27 2020 at 20:42):
the IG should define the extension, I think. And it should be clear how to generate the extension from other provenance resources, or vice versa. A more general question: does CUI only apply to data created under CUI governance?
Lloyd McKenzie (Aug 24 2020 at 19:18):
See discussion here: https://chat.fhir.org/#narrow/stream/179165-committers/topic/Removing.20the.20Contributor.20DataType
k connor (Aug 28 2020 at 02:10):
FYI NARA has a CUI blog e.g., latest: https://isoo.blogs.archives.gov/2020/08/17/cui-q4-stakeholders-update-wednesday100et/ and there's an upcoming CUI Marking Tutorial CUI Marking class (Webex)
by Charlene Wallace
CUI Marking fundamentals webex on
August 28, 2020 from 11 am – 1 pm (EDT).
Participants will receive a completion certificate for attending the webex.
In addition to providing an overview of the principles of marking in the unclassified environment, this class will provide an update on the CUI Program and its implementation among Executive Branch agencies.
During this class we will discuss the new CUI Notices 2020-01 (CUI Program Implementation Deadlines) and CUI Notice 2020-02 (Alternative Marking Methods)
The conference begins at 11:00 AM Eastern Time on August 28, 2020; you may join the conference 10 minutes prior.
Step 1: Dial into the conference.
Dial-in: 888-251-2949 or 215-861-0694
Access Code: 9214891#
Need an international dial-in number?
Step 2: Join the conference on your computer.
Entry Link: https://ems8.intellor.com/login/831806
Last updated: Apr 12 2022 at 19:14 UTC
