FHIR Chat · Proposed extension for CUI codes · Security and Privacy

Stream: Security and Privacy

Topic: Proposed extension for CUI codes

John Moehrke (Oct 15 2019 at 18:00):

@k connor and I discussed this on the FHIR Security call. Would like others comments and endorsements.

Add an extension on the Coding datatype, for use when the code is a CUI*** code, so that the author of that CUI tag can be identified and so that the manditory banner can be included.

this annotation extension is only to be used in .meta.security, and only when the system is v3-ActCode and the code is one of the CUI codes.

proposed extension uri "http://hl7.org/fhir/StructureDefinition/coding-cui-annotation"

Example:

<Patient xmlns="http://hl7.org/fhir">
<meta>
<security>
<extention url="http://hl7.org/fhir/StructureDefinition/coding-cui-annotation">
<authorReference value="http://example.fhir.org/Organization/vha
<text>
CUI//SP-HLTH/HLTH/PRVCY
</text>
</extension>
<system value="http://terminology.hl7.org/CodeSystem/v3-ActCode"/>
<code value="CUIHLTH"/>
<display value="CUI//HLTH"/>
</security>
<security>
<extention url="http://hl7.org/fhir/StructureDefinition/coding-cui-annotation">
<authorReference value="http://example.fhir.org/Organization/vha
<text>
CUI//SP-HLTH/HLTH/PRVCY
</text>
</extension>
<system value="http://terminology.hl7.org/CodeSystem/v3-ActCode"/>
<code value="CUIPRVCY"/>
<display value="CUI//PRVCY"/>
</security>
<security>
<extention url="http://hl7.org/fhir/StructureDefinition/coding-cui-annotation">
<authorReference value="http://example.fhir.org/Organization/vha
<text>
CUI//SP-HLTH/HLTH/PRVCY
</text>
</extension>
<system value="http://terminology.hl7.org/CodeSystem/v3-ActCode"/>
<code value="CUISP-HLTH"/>
<display value="CUI//SP-HLTH"/>
</security>
<security>
<system value="http://terminology.hl7.org/CodeSystem/v3-Confidentiality"/>
<code value="R"/>
<display value="Restricted"/>
</security>
</meta>
... [snip] ...
</Patient>

k connor (Oct 16 2019 at 07:09):

For background on US law requiring Federal Agencies to label and render Controlled Unclassified Information (CUI) markings see
CUI Documents & Reference Links @ https://confluence.hl7.org/display/SEC/Controlled+Unclassified+Information+%28CUI%29+Problem+and+Solutions

John Moehrke (Oct 22 2019 at 19:32):

any comment on this proposal from @Lloyd McKenzie @Grahame Grieve @Josh Mandel or anyone else from FHIR core?

Grahame Grieve (Oct 22 2019 at 19:34):

so what's the actual problem?

John Moehrke (Oct 22 2019 at 19:48):

The problem the extension is addressing is that there are regulated requirements on what must be displayed on the screen when the data have CUI class of tags. The thing that is displayed is a combination of codes, not just the list of codes.. I am not clear.. see the link Kathleen adds.

John Moehrke (Oct 22 2019 at 19:48):

the question to the community is if this extension is the best way to solve that problem. thus I am looking for creative types to help

Grahame Grieve (Oct 22 2019 at 19:54):

I read the documentation quickly, but didn't see any answer to my question

Add an extension on the Coding datatype, for use when the code is a CUI*** code, so that the author of that CUI tag can be identified and so that the manditory banner can be included.

I don't understand. what's the 'author'? THe organization that defined the policy? That should be part of the definition of the CUI code? Why is any of this needed to display a banner?

John Moehrke (Oct 22 2019 at 19:57):

take a look at the example I gave above. It started with the example on the security-labels page, and adds the three CUI codes that will typically be added (they are always added in tripplets as far as I can tell). They then have the annotation explaining that this data must have the text "CUI//SP-HLTH/HLTH/PRVCY" displayed on the screen

Grahame Grieve (Oct 22 2019 at 20:00):

I don't begin to understand this. Why is this not a matter of policy? If you call it R, then policy follows... ?

John Moehrke (Oct 22 2019 at 20:08):

I don't know.... @k connor ???

k connor (Oct 22 2019 at 20:41):

See CUI Marking Handbook https://www.archives.gov/files/cui/20161206-cui-marking-handbook-v1-1.pdf page 13 per US 32 CFR Part 2002 https://www.federalregister.gov/documents/2016/09/14/2016-21665/controlled-unclassified-information requires that the banner of Federal Agency information be rendered to end users include both the required CUI codes and the name/contact information of the Designator's Agency.

Grahame Grieve (Oct 22 2019 at 21:53):

sounds like a rule about how you build the narrative then. What's it got to do with security codes?

Mohammad Jafari (Oct 23 2019 at 01:37):

It seems to me that what we are missing is a mechanism (either as an extension to the narrative section, or as a security label) to specify a marking that SHALL be displayed in any rendering of the resource to a human user (e.g. on screen, printout, etc.). If we have this mechanism, then an IG can define the rules for computing the mandatory marking from the CUI codes, either by the sender or the recipient.

Grahame Grieve (Oct 23 2019 at 02:48):

where do you want to specify it? We have a way to do this in an implementation guide, to mark an element and particular codes as 'must-support' and to say what this means, such that if you claim to conform to the IG, you are bound to do what it says

Lloyd McKenzie (Oct 23 2019 at 03:57):

One thing I'm a bit concerned about is the notion of calling it out in all US implementation guides. I don't think it's appropriate to replicate the same language across all of the various Da Vinci, CARIN and other IGs. It would be better to stick the expectations in one place and then those IGs where the requirement is relevant can just 'point'. It also means that if the guidance or recommendations evolve, there's only one place we'd need to make the change rather than worrying about trying to update everything.

k connor (Oct 23 2019 at 17:31):

In John's example at the top of this thread, you'll see 3 security labels that contain CUI codes that are already adopted by HL7. The Annotation extension is intended to indicate how the 3 codes are to be concatenated for display to end users via the narrative along with the Designator's Federal Agency name and contact information. The Designator is the CUI classifier. So we have the mechanisms to meet 32 CFR Part 2002 requirements. I agree that this guidance should be documented in one place, e.g., the Security Label Module, so that any IG can reference it. I will create a CR for this.

Grahame Grieve (Oct 23 2019 at 17:40):

what will the CR say?

John Moehrke (Oct 23 2019 at 17:47):

It seems to me that what we are missing is a mechanism (either as an extension to the narrative section, or as a security label) to specify a marking that SHALL be displayed in any rendering of the resource to a human user (e.g. on screen, printout, etc.). If we have this mechanism, then an IG can define the rules for computing the mandatory marking from the CUI codes, either by the sender or the recipient.

I like this idea. So it would not be on each .meta.security code. but rather would be one narrative extension at the resource level? This would seem to be more easy to process and more easy to create and manage

Grahame Grieve (Oct 23 2019 at 17:50):

I guess we would define an extension that has a mandatory banner, with a type markdown, with the idea that this is some explicit narrative that systems are required by applicable regulation to display one way or another when they display the resource

John Moehrke (Oct 23 2019 at 17:54):

That seems far more useful. @k connor does that meet the letter of the regulation? It seems to support what is needed, and it is more easy and less noisy.

k connor (Oct 23 2019 at 19:05):

The CUI Codes are defined as requiring that they be rendered to end users "Mandatory control marking, which must be displayed on the top portion of each rendered or printed page containing controlled information. https://confluence.hl7.org/display/SEC/HL7+CUI+Codes+for+Security+Labels
RE proposed extension - doesn't seem to support the Designator's Agency name/contact like Annotation extension would. But maybe I'm missing something.

Grahame Grieve (Oct 23 2019 at 19:52):

well, what is the Annotation extension?

k connor (Oct 23 2019 at 19:59):

At the start of this tread, John put an example of how it would be used - and it includes both the required concatenation of the 3 CUI codes for display and the Designator's Agency name/contact. Seems perfect to me. That's what we agreed on FHIR Security call to put into a CR.

Grahame Grieve (Oct 23 2019 at 20:02):

well, it's not actually valid, so maybe if it was a valid example, I'd understand it better, but this:

<Patient xmlns="http://hl7.org/fhir">
  <meta>
    <security>
      <extension url="http://hl7.org/fhir/StructureDefinition/coding-cui-annotation">
        <authorReference value="http://example.fhir.org/Organization/vha
          <text>CUI//SP-HLTH/HLTH/PRVCY</text>
      </extension>
      <system value="http://terminology.hl7.org/CodeSystem/v3-ActCode"/>
      <code value="CUIHLTH"/>
      <display value="CUI//HLTH"/>
    </security>
    <security>
      <extention url="http://hl7.org/fhir/StructureDefinition/coding-cui-annotation">
        <authorReference value="http://example.fhir.org/Organization/vha
          <text>
          CUI//SP-HLTH/HLTH/PRVCY
          </text>
      </extension>
      <system value="http://terminology.hl7.org/CodeSystem/v3-ActCode"/>
      <code value="CUIPRVCY"/>
      <display value="CUI//PRVCY"/>
    </security>
    <security>
      <extention url="http://hl7.org/fhir/StructureDefinition/coding-cui-annotation">
        <authorReference value="http://example.fhir.org/Organization/vha
          <text>
          CUI//SP-HLTH/HLTH/PRVCY
          </text>
      </extension>
      <system value="http://terminology.hl7.org/CodeSystem/v3-ActCode"/>
      <code value="CUISP-HLTH"/>
      <display value="CUI//SP-HLTH"/>
    </security>
    <security>
      <system value="http://terminology.hl7.org/CodeSystem/v3-Confidentiality"/>
      <code value="R"/>
      <display value="Restricted"/>
    </security>
  </meta>
  ... [snip] ...
</Patient>

Grahame Grieve (Oct 23 2019 at 20:03):

the annotation says... nothing. It has no meaning to me. so perhaps a correct example and a formal definition might be useful

k connor (Oct 23 2019 at 20:27):

@Grahame Grieve - Please let us know how to fix the example if Annotation is the correct extension to use or suggest a different extension. My understanding is that the Annotation text is where the correct concatenation of the 3 CUI labels goes. CUI IG would required implementers to display the Annotation text at the top of the narrative and in the following line, display the name and contact information from the authorReference Organization. If there's a better way to meet the rendering requirements, please advise.

Grahame Grieve (Oct 23 2019 at 20:34):

well, I don't understand what is being proposed and it doesn't seem to correlate with the discussion. 3 CUI codes, each with the same extension... are you being asked to do the same thing 3 times?

What does the combination CUI//SP-HLTH/HLTH/PRVCY mean anyway?

• CUIHLTHP: "A displayed mark, required to be rendered as "(CUI//HLTH)", indicating that a portion of an electronic or hardcopy information is protected at the level of the subset of CUI for which the authorizing law, regulation, or Government-wide policy does not set out specific handling or dissemination controls. "

• CUIPRVCY: "A displayed mark, required to be rendered as "CUI//PRVCY", indicating that the electronic or hardcopy controlled unclassified basic privacy information is private and must be protected at the level of the subset of CUI for which the authorizing law, regulation, or Government-wide policy does not set out specific handling or dissemination controls"

• CUISP-HLTH: "A displayed mark, required to be rendered as "CUI//SP-HLTH", indicating that the electronic or hardcopy information is protected at the level of the subset of CUI in which the authorizing law, regulation, or Government-wide policy contains specific handling controls that it requires or permits agencies to use that differ from those for CUI Basic"

The combination of those makes no sense to me - they're all saying the same thing. Which is a null statement. This resource contains information which is controlled as set out by some regulation.... or not... what?

Grahame Grieve (Oct 23 2019 at 20:35):

the the apparent annotation apparently presents a rendering of the concepts that violates the stated requirements

Grahame Grieve (Oct 23 2019 at 20:35):

and I don't understand the author reference at all either

John Moehrke (Oct 23 2019 at 21:11):

This is why I liked Mohamed's recommendation that there need be only one extension at the .meta level for a security-header.
I fail to see why that is not covering the need. I do not see how the requirement is that the narrative must be so directly embeded in the exact location where the codes are, and that the narrative be repeated three times

John Moehrke (Oct 23 2019 at 21:13):

Grahame, we chose Annotation as we need both the author and the narrative. The author to point at what organization applied the CUI, and the narrative to be displayed. I am not sure Annotation is the right datatype, it seems overkill.

John Moehrke (Oct 23 2019 at 21:13):

the fact that the example is not valid..... well, that is why we are asking for help on zulip...

Grahame Grieve (Oct 23 2019 at 21:23):

which would look like:

<Patient xmlns="http://hl7.org/fhir">
  <meta>
    <security>
      <system value="http://terminology.hl7.org/CodeSystem/v3-ActCode"/>
      <code value="CUISP-HLTH"/>
      <display value="CUI//SP-HLTH"/>
    </security>
    </security>
  </meta>
  <extension url="http://hl7.org/fhir/StructureDefinition/extension-must-display">
    <valueAnnotation>
      <authorReference>
        <reference value="http://example.fhir.org/Organization/vha"/>
      </authorReference>
      <text value="**CUI//SP-HLTH** ([VHA](http://example.fhir.org/Organization/vha))"/>
    </valueAnnotation>
  </extension>
  .. snip ...
</Patient>

k connor (Oct 23 2019 at 21:31):

Thanks for the example. Problem is that all of the required CUI codes must be concatenated into one for the banner. So how do we avoid putting the same extension-must-display after each of the security labels with CUI codes, i.e., CUISP-HLTH, CUIHLTH, CUIPRVCY so that the "must display" text = CUI//SP-HLTH/HLTH/PRVCY?

k connor (Oct 23 2019 at 21:33):

Or maybe, the extension just has to repeat on each? I'm hoping we only have to deal with one default concatenated CUI for most healthcare business.

Grahame Grieve (Oct 23 2019 at 21:34):

well, perhaps that combination has meaning, but it's not at all apparent from the definitions of the codes what that would mean. Not the definitions have any meaningful content at all. But if that's what you want, then:

<Patient xmlns="http://hl7.org/fhir">
  <meta>
    <security>
      <system value="http://terminology.hl7.org/CodeSystem/v3-ActCode"/>
      <code value="CUISP-HLTH"/>
    </security>
    <security>
      <system value="http://terminology.hl7.org/CodeSystem/v3-ActCode"/>
      <code value="CUIHLTH"/>
    </security>
    <security>
      <system value="http://terminology.hl7.org/CodeSystem/v3-ActCode"/>
      <code value="CUIPRVCY"/>
    </security>
  </meta>
  <extension url="http://hl7.org/fhir/StructureDefinition/extension-must-display">
    <valueAnnotation>
      <authorReference>
        <reference value="http://example.fhir.org/Organization/vha"/>
      </authorReference>
      <text value="**CUI//SP-HLTH/HLTH/PRVCY** ([VHA](http://example.fhir.org/Organization/vha))"/>
    </valueAnnotation>
  </extension>
  .. snip ...
</Patient>

John Moehrke (Oct 23 2019 at 21:47):

Thanks for the example. Problem is that all of the required CUI codes must be concatenated into one for the banner. So how do we avoid putting the same extension-must-display after each of the security labels with CUI codes, i.e., CUISP-HLTH, CUIHLTH, CUIPRVCY so that the "must display" text = CUI//SP-HLTH/HLTH/PRVCY?

Why does it need to repeat on each code? It is one thing that must be displayed...

Grahame Grieve (Oct 23 2019 at 21:59):

it doesn't. the extension goes once on the resource itself

John Moehrke (Oct 23 2019 at 22:00):

I hope so.. but not sure Kathleen agrees

k connor (Oct 23 2019 at 22:06):

I'm fine if it works to put the extension on one of the CUI labels as long as the display requirement is to concatenate all of the CUI labels in the prescribed format. Just wasn't sure how this works. Seems like the rules are set in an IG and then programmed to do what's prescribed. I'm happy if you all think this works. Just in time, because Sequoia will be meeting on this again on Thursday, so should I update the information with this new extension??? Do I need to put into a CR?

Grahame Grieve (Oct 23 2019 at 22:08):

I think this works, but given that the nature of the extension, it should be run past FHIR-I - so yes, create a task

k connor (Oct 24 2019 at 01:49):

RE Grahame's noting the seemingly duplicative definitions at https://confluence.hl7.org/display/SEC/HL7+CUI+Codes+for+Security+Labels- one has to check the link to the multiple "authorities" categorized by these codes. A bunch of lawyers went through the statutes and regs and pulled out ones that seem to be in a particular domain (e.g., Health vs Privacy, but those are overlapping), and then differentiated those that seemed to have different security requirements than specified by NIST SP 800-171 - and made those laws/authorities "specified". So check the examples for the codes for idea on why they are different.
I'm the last to argue that any of this makes sense. It would likely have been much more efficient to just tell everyone to comply with 800-171 except where there's a more stringent security safeguard. Guessing this was the only way to downstream these security controls to the private sector. Oh well.

Anyway, had some questions about Grahame's example so I can write a proper CR.
We think we need to have all 3 CUI labels in the text, and that each of the CUI should be listed as a label so that access control systems can key off of the codes to determine which security controls to apply to the contents.

       <Patient xmlns="http://hl7.org/fhir">
          <meta>
          <security>
                <system value="http://hl7.org/fhir/v3/ActCode"/>
                <code value="CUISP-HLTH"/>
                <display value="CUI//SP-HLTH"/>
            </security>
            <security>
                <system value="http://hl7.org/fhir/v3/ActCode"/>
                <code value="CUIHLTH"/>
                <display value="CUI//HLTH"/>
            </security>
            <security>
                <system value="http://hl7.org/fhir/v3/ActCode"/>
                <code value="CUIPRVCY"/>
                <display value="CUI//PRVCY"/>
            </security>     
           </meta>
         <extension url="http://hl7.org/fhir/StructureDefinition/extension-must-display">
        <valueAnnotation>
          <authorReference>
            <reference value="http://example.fhir.org/Organization/vha"/>
          </authorReference>
          <text value="**CUI//SP-HLTH/HLTH/PRVCY** ([VHA](http://example.fhir.org/Organization/vha))"/>
        </valueAnnotation>
        </extension>

    RE <text value="**CUI//SP-HLTH/HLTH/PRVCY** ([VHA](http://example.fhir.org/Organization/vha))"/>

    How should the text indicate that CUI//SP-HLTH/HLTH/PRVCY has to be alone on the top line, and that below, the following example Designator Agency name/contact information must be displayed. (Must be some kind of mark-up magic I don't know.)

    Is this how it works?
     ([Veterans Health Administration, Washington, DC 20420] (http://example.fhir.org/Organization/vha))"/>

Grahame Grieve (Oct 24 2019 at 02:06):

this would be this:

     <text value="**CUI//SP-HLTH/HLTH/PRVCY**\r\n\r\n ([Veterans Health Administration, Washington, DC 20420](http://example.fhir.org/Organization/vha))"/>

Grahame Grieve (Oct 24 2019 at 02:07):

the content of the text value attribute is markdown using the commonmark syntax

John Moehrke (Oct 24 2019 at 12:35):

Is there any advantage to defining this extension within FHIR core, and having an IG defining conformance criteria such as displaying the must display content; vs defining both the extension and the actor conformance requirements in a CUI implementation guide? Seems the second is more clear to everyone who might need or use this. right?

Lloyd McKenzie (Oct 24 2019 at 12:37):

This is very much a U.S.-specific notion. I've never heard of this happening elsewhere. (To be honest, I haven't heard of it happening for real in the U.S. either). I wouldn't add it into core unless we have an indication that some other country is likely to use it. US Core seems like a more appropriate location

John Moehrke (Oct 24 2019 at 12:41):

This IG might be a rather small one... requiring compliance with NIST 800-171, requiring all data are labeled with three CUI codes (providing a ValueSet with these codes, and a combination rule), requiring all data have this annotation attached, and requiring all display of data display the annotation found in the data. That could be a nice compact security IG to add to the library of security/privacy IG.

Lloyd McKenzie (Oct 24 2019 at 12:44):

The issue isn't size, it's applicability/relevance

John Moehrke (Oct 24 2019 at 13:15):

I think small can e effective on this topic. are you saying it can't?

Lloyd McKenzie (Oct 24 2019 at 14:22):

Small is good. I'm just arguing against inclusion in core

John Moehrke (Oct 24 2019 at 15:10):

ah, so am I... I am looking at the need to have requirements that one would declare and be tested against... which is what an IG does (core can't). So I am just arguing that since we need an IG anyway, why not put the extension in that IG.

k connor (Oct 24 2019 at 17:10):

I'm fine with a US Core CUI IG, but think that are other use cases for the extension - e.g., take COPYMark or ConfidentialMark. There's nothing US specific about a business need to have certain security labels generally or PrivacyMark specific security label, defined as being used for rendering. So I propose that the extension-must-display be added to FHIR Core and that a US Core CUI IG, which would include a profile on that extension specific to the CUI use case be developed.

Lloyd McKenzie (Oct 24 2019 at 17:26):

Be aware that unless an implementation guide makes the extension "mustSupport" and a system declares conformance with the IG, it's free to ignore (and even strip and throw away) the extension.

John Moehrke (Oct 24 2019 at 17:29):

right. that is my point on how necessary an IG is.
A second IG can always re-use the same extension

Grahame Grieve (Oct 24 2019 at 17:36):

When you have a rule that 'all data must be tagged, and the tag must be displayed' I fail to see why the data should be tagged. It's kind of directly a tax, in that you have to waste bytes to say something that you have to do anyway. I really don't understand what is going on here

Grahame Grieve (Oct 24 2019 at 17:37):

on the other hand, a generic 'we think that this particular text is what you must display with this resource base on applicable regulation' is something that I could see being useful in the core spec, not a US specific thing

k connor (Oct 24 2019 at 18:24):

The CUI security labels tell the access control system about which of the CUI policies apply - e.g., SP-HLTH (specified health) says enforce HIPAA Security Safeguards in the statute, which governs IIHI in addition to the subsect ePHI governed under the HIPAA Security Rule, which is considered basic health (HLTH), for which access control must enforce NIST SP 800-171. PRVCY is also NIST SP-800-171 for purposes of protecting against breach of PII. So there's more going on here than requiring a display. There's a machine readable aspect which is the same for the other security label tags - Confidentiality codes limit access to those authorized for that level of confidential information, ditto purpose of use restricts the uses per policy.

Grahame Grieve (Oct 24 2019 at 18:27):

but those things are required anyway... (except for Confidentiality).

John Moehrke (Oct 24 2019 at 18:31):

how is a UI to behave when it is showing multiple resources? There are times when only one is displayed, but more likely many... and what about a list of resources (here is the list of medications that are prescribed to the patient)? Is the list of medications sufficient to require the banner be displayed?

John Moehrke (Oct 24 2019 at 18:31):

It seems far more reasonable that this banner display is a system requirement, than that it is a data labeling requirement.

John Moehrke (Oct 24 2019 at 18:32):

yes, the CUI codes are a data labeling requirement... I fully defend that.

John Moehrke (Oct 24 2019 at 18:33):

it is the banner that I am so very confused by... and the fact that someone wrote a regulation that has no possible relationship to reality is a well understood problem of regulation.

Grahame Grieve (Oct 24 2019 at 18:33):

right. It's no wonder users hate health IT solutions

John Moehrke (Oct 24 2019 at 18:33):

all the more reason for this to be done in an IG... sp that it can be made more clear to those regulation writers what a mess they have caused

k connor (Oct 24 2019 at 19:55):

Well, best that we figure out how to do this - I'm listening to a NARA representative who is saying that they plan on everyone implementing NIEM for CUI compliance. Such fun....

k connor (Oct 24 2019 at 19:58):

Well, guess it's just that we have to map to the NIEM CUI metadata.

John Moehrke (Oct 24 2019 at 20:07):

we have been threatened with NIEM many times over the past decade. Everyone sees their 'hammer' as the best tool

Mohammad Jafari (Oct 24 2019 at 20:56):

I think these are interesting UX/UI design questions that the IG can address or at least propose some guidelines/examples for rendering banners in such cases.

how is a UI to behave when it is showing multiple resources? There are times when only one is displayed, but more likely many... and what about a list of resources (here is the list of medications that are prescribed to the patient)? Is the list of medications sufficient to require the banner be displayed?

k connor (Oct 24 2019 at 21:16):

RE is the list of medications sufficient to require the banner? Yes, I'm fairly sure that there won't be "portion marking" - i.e., everything will be treated as CUI if anything is CUI. Portion marking would be very burdensome with little value. The difference between the security controls required by HIPAA Security Safeguards in the statute [which covers a broader set of information - i.e., IIHI, and not just ePHI] and those required by NIST SP 800-171 is a set of 26 controls, which are not heavy lifts - although in combination, they will take effort. But that's nothing compared to trying to segregate CUI from non-CUI. And that's likely not unintended - raising all security boats via CUI. Eventually every provider/payer/BA will have CUI in their system, so think they'll all eventually comply with 800-171 in addition to whatever other security requirements pertain from other policies.

Grahame Grieve (Oct 24 2019 at 21:22):

so I'm still mystified about all this. Why mark the resource itself when the policy applies in a context, not to the content?

k connor (Oct 25 2019 at 03:55):

Policy applies to the content. See https://www.archives.gov/cui/registry/cui-glossary.html definition of "document" - it applies to every utterance of Fed Agencies or their contractors. Don't know what you mean by context as differentiating. Within a few years, if the laws don't change, every health IT system will have CUI and need to comply with NIST SP 800-171. Pretty much the take-away from today's Sequoia CUI call. For fun and giggles - check out the CUI videos, from which this conclusion can be derived - which features NARA Devin Casey who joined today's Sequoia CUI call. https://www.youtube.com/watch?v=Ov0HwefzHww

John Moehrke (Oct 25 2019 at 15:09):

I liked the much shorter https://youtu.be/UxpF21AsxZE

John Moehrke (Oct 25 2019 at 15:13):

Seems the codes we have are the right thing to do on each Resource. However it seems to me that these banner and many of the marking functions would be much better handled with Provenance. It might be a specific kind of Provenance so that it can be readily found (and included in a Bundle). Much of these banner requirements seem far more Provenance based. Including who put the tags on, why (policy), etc.

John Moehrke (Oct 25 2019 at 15:14):

additional marking would be done within documents (pdf, CDA, and FHIR). but that function is more UI based and already supported in those encodings.

John Moehrke (Oct 25 2019 at 15:15):

I am also noticing that the banner is a algorithmic combination of the CUI codes applied. So, it seems unclear to me why we would need to include the banner string in the Resource, as it is just algorithmic combination of the total codes.

Grahame Grieve (Oct 25 2019 at 20:49):

I'm only half way through the video, but I'm still much mystified by this. why 3 codes? Why in the resource itself? Do you remove them when you give the information to the patient? or the public? or some contractors? Why do you insert the source into the narrative?

Agree with John that this is really about provenance

k connor (Oct 25 2019 at 22:20):

Initial review suggested that 3 codes are needed for each of the authorities that apply. That still hasn't been fully vetted. However, NARA agreed that at least SP-HLTH is required. RE Provenance inside of Bundle - not sure that makes sense since Bundle doesn't support narrative. But can't really include Provenance in a Composition or a Resource as far as I know. As for algorithm to determine how to concatenate - that might be useful if we were solving the issue for other industries, but NIEM has that job. Hope is to land on a single default CUI marking for exchanged health information, so having an algorithm that only yields the same display seems like overkill.
RE GG "why in the Resource itself?" If a Resource is displayed on its own, it's a CUI document per https://www.archives.gov/cui/registry/cui-glossary.html so it needs it's own banner. Anyway, I'm not wedded to any solution for FHIR so happy to work on alternatives.

k connor (Oct 26 2019 at 01:59):

Another thought about why this is not provenance (over and above the case that provenance resource doesn't seem to work for the use case as stated above) - the purpose of CUI markings is to control access and to give obligations to the recipient, and to tell them who told them so - not to give the history of who told them so - specifically so that the recipient can go back to the classifier (Designator's Agency) and ask to reclassify or to let them know that they classified it incorrectly. Access control is not something that provenance should be used for - unless we want to greatly expand the scope of this resource. It's prospective instructions, not historical metadata.

John Moehrke (Oct 28 2019 at 13:13):

Note, I am not moving the tagging into Provenance. That is clearly data tagging. What I am suggesting is Provenance is the banner and the requirements to indicate who applied the tags and why they assigned the tags. I see no reason why a Provenance can't be included in a document, where do you see that as a limit? However, documents already have mechanics for banner so in a document I would leverage THAT mechanics (might use both if one really wants to).

John Moehrke (Oct 28 2019 at 13:14):

Given your mention that this is still being vetted... makes me want to do all of this in an IG even more strongly... I think this is very useful IG work.

k connor (Oct 29 2019 at 16:36):

CUIs are needed on Resources, not just in Documents. Are you supporting having inline Provenance in all Resources?

John Moehrke (Oct 29 2019 at 17:06):

all Resources can have Provenance. I don't understand why you think it needs to be 'inline' or what you are meaning by that.

Mohammad Jafari (Oct 29 2019 at 17:15):

I think the argument here is that FHIR specs seem to have already accepted that certain provenance information (e.g. author or some things in meta) be encoded inline with the resource, for reasons such as simpler and more efficient traceability and/or to minimizing the risk of separating the resource from the metadata. So, considering we already store some provenance information within the resource, I think the question is whether those arguments apply here to the case of CUI labeling authority. I think if the CUI guidelines consider the labeling authority a mandatory field which must be displayed as part of the CUI banner, then that is an argument in favor of not separating the labeling authority from the label.

Mohammad Jafari (Oct 29 2019 at 17:18):

RE inline provenance,
I thought of this as a potential remedy instead of defining all kinds of new extensions. Will it be helpful if we allow meta to encode a Provenance resource for the cases where it's crucial that (certain types of) provenance information remain tied to, and inseparable from, the resource?

John Moehrke (Oct 29 2019 at 17:35):

anything is possible. There is a proposal above that is an extension on .meta, and it is still part of the discussion. Having Provenance as a Resource has merit. Pulling that inline can be done with "Contained", but then the benefits of being a Resource are lost. My point of preference for Provenance vs extension on .meta is because everything I hear about the authority and banner requirements simply are Provenance. I don't think we should have a totally different provenance mechanism for CUI provenance, than we expect for all other kinds of provenance.

John Moehrke (Oct 29 2019 at 17:41):

I am expecting that we would have a CUI Implementation Guide that has specific requirements on data publishers and data consumers. That IG can demand the consumer to do all the required mechanics regardless of the FHIR encoding we use. Thus we should not look to overload the encoding with mechanics, the encoding should be logical and efficient. So the mandate to display the banner has more to do with the IG, any of the proposed FHIR encodings would likely work.

Grahame Grieve (Oct 29 2019 at 19:29):

it's still not clear to me what is actually needed in the resource. Why 3 codes, an 3 codes with definitions I can't differentiate? Why no extension for the authority?

John Moehrke (Oct 29 2019 at 19:39):

we could do an extension for the authority.. I was just wondering if Provenance could be used rather than an extension.

Grahame Grieve (Oct 29 2019 at 19:44):

it's possible. but I'm still waiting till I understand the use case properly

John Moehrke (Oct 29 2019 at 19:55):

so, hearing that possibly the banner requirement might be satisfied by simply making sure all participants agreeing to CUI (an IG conformance) will assure that all .text elements have the banner text encoded within, and all who display will display the banner text (and make the .text element available )

John Moehrke (Oct 29 2019 at 19:57):

I hear this is what is being proposed for HL7 v2 and CDA... so .text element might be a simple solution without need for extensions

John Moehrke (Oct 29 2019 at 19:59):

so we might be down to just needing a simple extension for the authority that applied that code. This might be a useful thing for other purposes too? is this just a .meta.security need? Or is this more general to CodeableConcept everywhere?

Grahame Grieve (Oct 29 2019 at 20:01):

across the eco-system there's a really diverse set of requirements for 'why this code' which morph into 'who wanted this code'

k connor (Oct 29 2019 at 22:05):

RE .text element - where's that going so that it is associated with the CUI security labels? What's wrong with providing guidance for how it is to be displayed in the Resource narrative? Still think that annotation extension works and is good enough. Seems like too much machinery is being proposed.

k connor (Oct 29 2019 at 22:09):

RE "Why this security label" - think that there are different use cases needing different extensions - e.g., RelatedArtifact extension would be useful for pointing to both the instance of a consent directive document or the url for the FHIR Contract or Consent, and the law that governs that consent directive.

John Moehrke (Oct 29 2019 at 22:21):

RE "Why this security label" - think that there are different use cases needing different extensions - e.g., RelatedArtifact extension would be useful for pointing to both the instance of a consent directive document or the url for the FHIR Contract or Consent, and the law that governs that consent directive.

yuck. that is over-engineered and I predict that if that is the solution then the whole CUI system will totally fail (like the government mandate for us to retire TCP/IP and use TP4/CLNP). Regulations that are unrealistic are ignored and go away.

Grahame Grieve (Oct 29 2019 at 22:26):

@k connor I still don't understand some fundamentals here. Can we start simple (for me). Can you give a concise explanation as to why the 3 codes are required?

k connor (Nov 05 2019 at 03:39):

Why 3 codes. Review of applicable CUI authorities suggests that there are 3 types of CUI Categories involved in general US health information exchange: HIPAA Statute Security safeguards (SP-HLTH), prevalent health privacy laws - e.g.,42 CFR Part 2 (SAMSHA SUD), Title 38 Section 7332 (VA Confidentiality), and HIPAA Security/Privacy Regulations (not the statute, which covers IIHI of which ePHI/PHI are a subset), and the Privacy requirements under OMB -17-12, and this intersection of authorities is explained at https://confluence.hl7.org/display/SEC/Controlled+Unclassified+Information+%28CUI%29+Problem+and+Solutions. But I didn't create the concatenation from hell code set when I put in the CUI codes. I made one for each CUI type in the CUI marking handbook since each has their own conceptual space. So if more than one CUI code applies, they need to be concatenated in the display required to be rendered to end users. Hope this helps. Maybe we won't need 3 codes in the end. Maybe we'll only need SP-HLTH, which NARA has already confirmed we'll need. Then this issue may evaporate at least for this CUI use case.

John Moehrke (Nov 05 2019 at 14:06):

so, lets hope

John Moehrke (Nov 06 2019 at 13:32):

Note new CR created based on the initial post GF#25180: Add annotation extension to security labels posted by kconnor

Last updated: Apr 12 2022 at 19:14 UTC