HL7 Security WG November 2012

Harmonization Proposals

Kathleen Connor VA (ESC)Oct. 23, 2012

2

Nov 2012 Proposals

• Change CEL Sensitivity Code to VIP• Change PRD Sensitivity Code to PDS• General POU Technical Correction • Security Observation Vocabulary

3

Change CEL Sensitivity Code to VIPProposal: • Change CEL Code to VIP, as VIP is considered by the

Security WG to be the conventional code for this concept, and therefore, more user-friendly

• No change to print name or definition

_InformationSensitivityPolicy 

.CEL

.VIPC:ActCode:CEL:23331

celebrity information sensitivity

Policy for handling information related to a celebrity (people of public interest (VIP), which will be afforded heightened confidentiality. Description: Celebrities are people of public interest (VIP) about whose information an enterprise may have a policy that requires heightened confidentiality. Information deemed sensitive may include health information and patient role information including patient status, demographics, next of kin, and location.Usage Notes: For use within an enterprise in which the information subject is deemed a celebrity or very important person. If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code.

4

Change PRD Sensitivity Code to PDS

Proposal: • Change PRD Code to PDS is more user-

friendly• No change to print name or definition

_InformationSensitivityPolicy  .PRD PDSC:ActCode:PDS:23336

patient default sensitivity

Policy for handling information reported by the patient about another person, e.g., a family member, which will be afforded heightened confidentiality. Description: Sensitive information reported by the patient about another person, e.g., family members may be deemed sensitive by default. The flag may be set or cleared on patient's request. Usage Notes: For sensitive information relayed by or about a patient, which is deemed sensitive within the enterprise (i.e., by default regardless of whether the patient requested that the information be deemed sensitive.) If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code.

5

General POU Technical Correction

• Technical Correction to July 2012 Harmonization Proposal “2012Jul_HARM_Approved_FINALPROPOSAL_VOCAB_SECURE_kathleen_connor_Final PurposeOfUse_20120701160914”

• Need to add COVERAGE and ETREAT in GeneralPurposeOfUse value set as approved in previous cycle.

6

Security Observation Vocabulary

• Enables association of Security Metadata with HL7 Acts and Roles, e.g., – Confidentiality Codes– Sensitivity and Privacy Law Codes– Obligation and Refrain Codes– Integrity Codes

• Integrity Status – e.g., legally authenticated• Integrity Confidence – e.g., reliable, not reliable• Provenance – e.g., reported by clinician, asserted by patient• Data Integrity – e.g., ensured by digital signature• Data Alteration – e.g., masked, anonymized

7

HL7 Security Observation Vocabulary

8

INTEGRITY TYPE DEFINITIONS

9

HL7 Security Integrity Observation Vocabulary

10

Integrity Status Definition

• Conveys the completion status or workflow state of a Resource– (data, information, objects or system capabilities, which may

be targets of access control decisions)• May be used to determine a user’s (Initiator’s)

entitlement to operate on a Resource based on its completion status, e.g., legally authenticated or in progress

• Binds to HL7 DocumentCompletion Code System– Defined as: Identifies the current completion state of a

clinical document.

11

HL7 DocumentCompletion Code System0-L

AU authenticated Definition:

A completion status in which a document has been signed manually or electronically by one or more individuals who attest to its accuracy. No explicit determination is made that the assigned individual has performed the authentication. While the standard allows multiple instances of authentication, it would be typical to have a single instance of authentication, usually by the assigned individual.

0-L

DI dictated Definition:

A completion status in which information has been orally recorded but not yet transcribed.

0-L

DO documented Definition:

A completion status in which document content, other than dictation, has been received but has not been translated into the final electronic format. Examples include paper documents, whether hand-written or typewritten, and intermediate electronic forms, such as voice to text.

0-L

IN incomplete Definition:

A completion status in which information is known to be missing from a transcribed document.

0-L

I P in progress Definition:

A workflow status where the material has been assigned to personnel to perform the task of transcription. The document remains in this state until the document is transcribed.

0-L

LA legally authenticated

Definition:

A completion status in which a document has been signed manually or electronically by the individual who is legally responsible for that document. This is the most mature state in the workflow progression.

0-L

PA pre-authenticated

Definition:

A completion status in which a document is transcribed but not authenticated.

12

Integrity Confidence Definition

• Conveys the perceived or policy-based attribution of likely veracity or trustworthiness of a Resource for the purpose of use for which it is being acted upon.

• The user should consider IntegrityConfidence when making decisions based on that resource.

• For example, a Resource created by a clinician and used for treatment may be perceived or assigned a higher level of IntegrityConfidence than a Resource created by a patient.

13

Integrity Confidence Codes

Integrity Confidence Code Print Name Definition HRELIABLE highly

reliable Indicates that the veracity or trustworthiness of a Resource (data, information, objects or system capabilities, which may be the target of access control decisions) for specified purposes of use is perceived to be or deemed by policy to be very high.

RELIABLE reliable Indicates that the veracity or trustworthiness of a Resource (data, information, objects or system capabilities, which may be the target of access control decisions) for specified purposes of use is perceived to be or deemed by policy to be adequate.

UNCERTREL uncertain reliability

Indicates that the veracity or trustworthiness of a Resource (data, information, objects or system capabilities, which may be the target of access control decisions) for specified purposes of use is perceived to be or deemed by policy to be of uncertain adequacy.

UNRELIABLE unreliable Indicates that the veracity or trustworthiness of a Resource (data, information, objects or system capabilities, which may be the target of access control decisions) for specified purposes of use is perceived to be or deemed by policy to be inadequate.

14

Provenance Definition

• Conveys metadata about the originating source of the Resource especially when reported second-hand by another author. Examples of vocabulary include:– Clinician, Healthcare Professional, Patient, Payer,

Device reported– Clinician, Healthcare Professional, Patient, Payer,

Device asserted

15

USE OF SECURITY OBSERVATION VOCABULARY

16

Use of Security Observation Vocabulary

• Supports – Resource Security Labels– Requester Security Clearance

• Enables labeling of CDA Entries with codes for – Confidentiality– Sensitivity– Obligation– Refrain– Integrity

17

Resource Security Classification LabelS& DAM Resource attributes convey key Security Classification Labels:

+ categoryType+ confidentiality+ sensitivity+ compartment+ integrityStatus+ integrityConfidence+ provenance+ dataIntegrity+ dataAlteration

Resource “compartment” may be populated with information from component classes such as Policy/Program

18

Initiator Security Clearance LabelS& DAM Initiator attributes convey key Security Clearance Label Fields:

+ resourceCategoryType+ POU+ confidentiality+ sensitivity+ compartment+ integrityStatus+ x509SubjectName+ LoA

Initiator “compartment” may be populated with information from Hierarchical and Functional Group

19

Security Labels on CDA Encounter Entry

20

21