HIT Standards CommitteeHIT Standards CommitteeMetadata Analysis Power TeamMetadata Analysis Power Team

Stan Huff, Chair

June 22, 2011

Power Team Members

• Stan Huff, Chair • John Halamka• Steve Ondra• Dixie Baker• Wes Rishel• Carl Gunter• Steve Stack

2

Power Team Charge

Identify metadata elements and standards for the following categories:

Patient Identity Provenance Privacy

The HIT Standards Committee previously approved recommendations from the Power Team on Patient Identity and Provenance

Today’s discussion recaps those decisions, as well as presents recommendations for privacy

3

Metadata Elements

Rationale Additional Suggestions

Standard

• Patient’s name

• Date of birth• Current zip

code• Patient

identifiers• Address

Represent the minimum elements that are required to uniquely select a patient from a population with a guaranteed degree of accuracy

• Add a display name element to accommodate non-western names

• Use a URI to act as a namespace for the identifier 

Use the HL7 CDA R2 header format.

XML based format for describing generic clinical documents can best accommodate international representation of names.

Patient Identity Summary

HIT Standards Committee has already supported the following decisions for patient identity

4

Metadata Elements Rationale Additional Suggestions

Standard

• Tagged Data Element (TDE) identifier

• Time stamp• The actor and

the actor’s affiliation

• A digital certificate 

 

Envelope will provide information permitting the recipient to judge whether a trusted source sent the data, when it was packaged, and whether any content tampering took place. 

• The use of an X.509 certificate to digitally sign the envelope contents

Metadata elements be expressed using the HL7 CDA R2 format. 

Provenance Summary

HIT Standards Committee has already supported the following decisions for provenance

5

PRIVACY

6

Use Cases from PCAST Analysis

Patient pushes data from PHR– Patient has complete control of what is sent

Simple query authorized by the patient– Queries are directed to facilities known to hold the data– The party that holds the data must respect any consent and

privacy preferences specified by the patient and include the identity, provenance, and privacy information with the data

Complex query based on policies– Query to DEAS to discover where the data exists– Requests to each data source for specific data needed– The party that holds the data must respect any consent and

privacy preferences specified by the patient and include the identity, provenance, and privacy information with the data

7

Privacy - Sensitive Information Model

8

Can the envelope be broken into parts?

Yes No

• Expose just the patient identity• Allow requests for provenance, privacy• Can defer policy evaluation• Greater complexity

• Perform all checking up front• Provenance and privacy can

expose sensitive information• More work for policy enforcement

points

Can the envelope contain sensitive information?

Yes

No

• This has an impact on the provenance work already done.

Privacy - Rationale for Suggested Metadata

Privacy policies include the following:– Content metadata: Datatype, Sensitivity, Coverage– Request metadata: Recipient, Affiliation, Role, Credential,

Purpose– Obligations

Approaches for storing policies:– Self-contained = Policy attached to each Tagged Data Element

(TDE) External policy registries not needed Difficult for patients to find and manage all TDEs when policies

change

– Layered = Policy referenced by each TDE External policy registries needed Minimal set of metadata tags associated with TDEs

9

Out of Scope

Infeasible

Policy Pointer: URL that indicates which privacy policy governs the release of the TDE.

Content Metadata: Describes the information in the TDE.– Datatype: information category from a clinical perspective;– Sensitivity: indicates special handling may be necessary;– Coverage: who paid to acquire the information – eliminated from

consideration

10

Privacy - Suggested Metadata Elements

Privacy Suggestions – Metadata Elements

Rationale: the Power Team agreed to focus on the Content metadata:– Needed to enforce the current federal and state policies, as

well as more granular policies that may be adopted in the future

– Other information was agreed to be out of scope for this effort, including: request metadata (such as recipient, affiliation, purpose, etc.), environmental metadata (such as location, time, etc.), and policy specification (including obligations)

– External policy registries would be needed but we did not address the specifics of how this might be accomplished

11

Privacy - Standards Comparison

12

Suggestion Rationale

Modify CDA CDA already includes datatype information (using HL7 class codes and document type codes) and sensitivity tags (using confidentiality codes).

Modify XDS XDS allows new tags and values to easily be added.

Create a new standard • Class codes may need to be augmented (e.g., to include allergies).

• Confidentiality codes need to be augmented to handle common sensitivity tags.

• Coverage and policy pointers need to be added.

Four standards were investigated:BPPC w/ IHE XDSCDA R2 PCD w/ CDA headersP3PEPAL

13

Privacy - Analyzed Standards

Built for online businesses;no capture of content metadata

MITRE suggestions:

14

Privacy - Use Case Example

CDA<?xml version="1.0" encoding="UTF-8"?><ClinicalDocument xmlns="urn:hl7-org:v3" classCode="DGIMG"> <realmCode code="US"> <typeId root="2.16.840.1.113883.1.3" extension="09230” /> <confidentialityCode value="SDV" /> <code code="34788-0" displayName= "Psychiatric Consult note" codeSystemName="LOINC"/></ClinicalDocument>

IHE XDS<rim:Name> <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="Generic Image"></rim:Name><rim:Name> <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="Restricted"></rim:Name>

Generic format relies on context to find relevant fields

Legitimate values defined by an Affinity Domain

Relies on HL7 class hierarchy

Limited set of confidentiality codes

Privacy Suggestions - Standards

Standard chosen:  HL7 CDA R2 w/ headers

Coded values for Data type:  – Suggest using the HL7 Class Codes as the basis

and the LOINC codes specified in the CDA document type to provide additional granularity.

– LOINC codes are attractive because of the ease with which new codes can be added.

15

Privacy Suggestions - Standard

Coded Values for Sensitivity: – New coded value set will need to be developed, need process

for defining the values for this etc.  Strawman list of sensitivity tags includes

Substance Abuse (ETH) Reproductive Health Sexually Transmitted Disease (HIV) Mental Health (PSY) Genetic Information Violence (SDV) Other

Strongly encourage that these values be extensible by adding new levels in the hierarchy.

16