Harmonization Dates: Initial proposals due 10/26; final submissions due 11/29; Harmonization meeting scheduled for 12/3 - 4.

Final Report: At the HL7 Harmonization meeting on 12/3/2019 six proposals described at https://confluence.hl7.org/display/SEC/201911+November+Harmonization were approved.  Among these were two related to implementing the 32 CFR Part 2 Controlled Unclassified Information (CUI) requirements to support the Sequoia requested Cross Paradigm CUI Security Labeling IG PSS Minutes at https://confluence.hl7.org/display/HARMZTN/2019+December+20191203+Meeting+Notes.


The following Initial 201911 Harmonization Proposals 1,2,3 were approved on the 2019-10-22 Security WG Agenda/Minutes call

Security approved sponsoring final submission of proposals 1,2 3, and cosponsoring final submission of proposals 4,5, 6 sponsored by CBCP 11/19 2019-11-19 Security Agenda/Minutes

CBCP approved being cosponsor 2019-10-29 CBCP Supports November Harmonization Proposals 4,5,6 as sponsors and cosponsor of 1,2,3. Approved Final as sponsor for 4,5, 6 and cosponsor for 1,2 3 2019-11-19 CBCP Meeting Agenda/Minutes DRAFT


Initial submission of Harmonization Proposals 1,2, 3 approved.

Moved: Kathleen Seconded: Beth

Carrie Hammond abstained

12-1-0

Proposal 1: Create CUIMark Obligation Code

Change Leaf Concept PRIVMARK to Specializable with a CUIMark child concept Proposal.

Create Leaf Concept

CUIMark (display CUI Mark)

Description:

CUI Custodians must create, persist, display, and convey computable and human readable security label CUI tags as required by CUI Marking policies including US 32 CFR Part 2002 and US Executive Order 13556 "Controlled Unclassified Information . CUI Custodians must enforce CUI Security Controls per applicable CUI policies.

Custodians include a CUI classifier of original CUI content; or a CUI derivative classifier, which reclassifies CUI content that has been aggregated with other CUI or Unclassified Uncontrolled Information (U) or dissembled from a larger CUI content

Recipients of CUI tagged content, CUIMark Obligation security labels must consume, persist, display, and enforce CUI controls per applicable CUI policies.

Usage Note:   Applicable CUI policies include:

Initial Proposal
Final Proposal

Proposal 2: Comply with Policy Obligation Codes Proposal

Create a new Specializable parent [CPLYPOL in the ObligationPolicy ActCode system under which the various policies requiring compliance can be nested.  Add a new ObligationPolicy_CPLYPOL_CPLYCUI to support emerging US realm need to inform recipients of Federal Agency source Controlled Unclassified Information (CUI) that they must comply with the applicable laws, regulations, executive orders, and other guidances, such as included in DURSAs, to persist, mark, and enforce required CUI controls.  Add a Comply with Jurisdictional Security Policy.

Update current CPLYPOL to be a Specializable parent of

CPLYCC

CPLYDC

CPLYJPP

CPLYJSP

CPLYOPP

CPLYOSP

CPLYCUI

LEAF CONCEPT:

CPLYJSP (comply with jurisdictional security policy)

Description:

Custodian security system must retrieve, evaluate, and comply with applicable jurisdictional security policies associated with the target information.

LEAF CONCEPT:

CPLYCUI (comply with controlled unclassified information policy)

Description:

Custodian security system must retrieve, evaluate, and comply with applicable US Controlled Unclassified Information (CUI) policies associated with the target information.


Initial Proposal

Final Proposal

Proposal 3: Add Upgrader Role Code Proposal


Initial Proposal


Final Proposal

Add UPGRDER as a child of RoleCode_AffiliationRoleType_AgentRoleType

LEAF CONCEPT:

UPGRDER (upgrader)

Description:


An individual authorized to raise the classification level of labeled content and provide rationale for doing so as directed by a classification guide.

Proposal 4:  Fix a)HIPAAConsent

ActCode_ActPrivacyLaw.a)HIPAAConsent has erroneous code.  Should not have “a)” in the code. Simply need to remove “a)”.



Initial Proposal

Final Proposal

Proposal 5: CDS Compartment

Create a Compartment Security Label tag for CDS (Clinical Decision Support System) to support authorizing CDS to access information to which system end users may not be authorized due to restrictive privacy policies in order to enable patient safety alerts where e.g., an unauthorized provider may be ordering a medication or procedure, which is contraindicated based on masked information in the patient’s record.


Initial Proposal


Final Proposal

Add a child to

SPECIALIZABLE CONCEPT:

COMPT (compartment)

Description:

This is the healthcare analog to the US Intelligence Community's concept of a Special Access Program. Compartment codes may be used in as a field value in an initiator's clearance to indicate permission to access and use an IT Resource with a security label having the same compartment value in security category label field.


Leaf Concept

CDSCOMPT

Description


Description:

A security category label field value, which indicates that access and use of an IT resource is authorized for a Clinical Decision Support System (CDS) as programmed to respond to potential or definitive contraindicated orders by an end user, which may not be authorized to access the same information, based on e.g., allergies, contraindicated medications, procedures, or devices,

until the CDS throws an alert advising the unauthorized orderer to “break the glass” by accepting accountability for that access.

FINAL Proposal 5: CDS Compartment

See notes

CDS Compartment Proposal November 201911 Harmonization

Proposal 6: Specialize MDHHS-5515

The current MDHHS-5515 Michigan Consent to Share Behavioral Health Information for Care Coordination Purposes is actually a compound consent directive under two different laws. In order to efficiently design a security label for governed information, two children codes are needed.

Initial Proposal


Final Proposal


Revise current MDHHS-5515 Description as follows [also embedding text file to deal with MSFT character issues]

 

The State of Michigan standard privacy consent form for sharing of health information specific to behavioral health and substance use treatment in accordance with Public Act 129 of 2014. In Michigan, while providers are not required to use this new standard form (MDHHS-5515), they are required to accept it.


Usage Note: For legislative background, current MDHHS-5515 consent directive form, and provider and patient FAQs see http://www.michigan.gov/mdhhs/0,5885,7-339-71550_2941_58005-343686--,00.html

Add New Leaf Concept: MDHHS-5515Part2 (Michigan Consent to Share Behavioral Health Information for Care Coordination Purposes 42 CFR Part 2)

 

Description:

The State of Michigan standard privacy consent form for sharing of health information specific to substance use information governed under 42 CFR Part 2 in accordance with Public Act 129 of 2014.


Usage Note: For legislative background, current MDHHS-5515 consent directive form, and provider and patient FAQs see http://www.michigan.gov/mdhhs/0,5885,7-339-71550_2941_58005-343686--,00.html


Add New Leaf Concept: MDHHS-5515MMHC (Michigan Consent to Share Behavioral Health Information for Care Coordination Purposes Michigan Mental Health Code)

 

Description:

The State of Michigan standard privacy consent form for sharing of health information specific to behavioral health governed by the Michigan Mental Health Code Act 258 of 1974, which require patient authorization for purposes other than treatment, payment, and coordination of care, in accordance with Public Act 129 of 2014.


Usage Note: For legislative background, current MDHHS-5515 consent directive form, and provider and patient FAQs see http://www.michigan.gov/mdhhs/0,5885,7-339-71550_2941_58005-343686--,00.html