Existing Wording: Consent.except.securityLabel Definition: A set of security labels that define which resources are controlled by this exception. If more than one label is specified, all resources must have all the specified labels.

Proposed Wording: Consent.except.securityLabel Definition: A security label, comprised on 1..* security label fields , which define which resources are controlled by this exception. Any Consent.except.class, Consent.except.code and any Consent.except.data all be labeled with the same Consent.except.securityLabel comprised of the same Security Label fields populated with the same HCS values. Assumes conformance to HL7 HCS Security Label syntax and semantics.

Comment:

Current wording: "A set of security labels that define which resources are controlled by this exception." Incorrect. According to HCS, there should be 0..1 Security Label on any portion of content to which a Security Label must be applied per policy. A Security Label is the syntactic structure defined in multiple ISO and ITEF standards, in the HCS for specific healthcare labeling rules, and by NIST specifications. A Security Label is comprised on security label fields, which are valued with appropriate privacy and handling caveat tags. Therefore, there can only be one Security Label. Unfortunately, FHIR has misnamed Security Label Fields a s Security Labels.

*The Consent.except.securityLabel comment discusses a "high water mark", which makes no sense in the context of a Consent.except.securityLabel. The Consent.except.securityLabel represents the policy rules in this Consent Directive that pertain to particular types or instances of information governed under that rule. If information governed by the Consent Directive merges more than one consent policy, then there must be more than one Consent.except that specifies the information that each policy rules governs, even if the Consent.except.actor and Consent.except.action are the same. This includes any Consent.except.data.meaning inclusion of associated resources. I.e., if prior to the construction of the Consent.except, the Consent.except.data.meaning is comprised of information governed under more than one consent policy, e.g., an episode of care, when the Consent.except are assembled, that bundle of Consent.except.data must be broken up into sets governed by each consent policy.

For example, the VA Form 10-0485 consent directive type allows a veteran to opt-in for disclosure on eHealth Exchange for all HIPAA and Title 38 Section 7332 consent policies. This is a "basic opt-in" Consent Directive. However, because it includes more than one consent policy and because of how the FHIR Consent is structured, there would be no Consent.securityLabel, and there would be two Consent.except, one for HIPAA and one for Title 38 governed information even if type of information governed under these consent policies includes the veteran's entire medical record being disclosed by the VA. The Consent.except for HIPAA governed information would have a Consent.except.securityLabel that includes at a minimum the Confidentiality Security Label field valued as "normal" and 1.. allowable HIPAA POUs . The Consent.except for Title 38 governed information would have a Consent.except.securityLabel that includes the Confidentiality Security Label field valued as "restricted", all Title 38 pertinent Sensitivity Security Label fields - i.e.,

, eHealth Exchange allowed POUs, and the Refrain Security Label field prohibiting redisclosure without consent. There would be no high water mark. No Consent Directive should contain a policy rule encoded with a Security Label representing a high water mark for the governed information. However, the Consent Directive itself should be assigned a Security Label, which would reflect the high water mark for all the protected information governed by that directive.

The FHIR Consent Resource needs to remodel its use of Security Labels to better reflect their role as representing the consent policies upon which a specific Consent Directive is based.

Summary:

Change definition of securityLabel