HIT Standards CommitteeHIT Standards CommitteeMetadata Analysis Power TeamMetadata Analysis Power Team

Stan Huff, Chair

May 18, 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 that are required for the following categories:

Patient Identity Provenance Privacy

Review standards that represent those metadata elements:

1. An existing standard is available and can be used as is

2. An existing standard is available but must be modified to be used

3. Merge standards

4. Create new standard

3

Patient Identity - Suggested Metadata

Goal: define a subset of patient data that will uniquely identify the patient

Name: Suffix, Given, Middle, Last Name, etc.– Other Names (Optional): Any previous names, e.g. maiden

name

Date of Birth Postal Code: Current US Zip code Patient ID

– Some form of unique identifier, e.g. (partial) SSN number, driver’s license, provider’s ID

Address– Any part of the following - Street Name, City, County, State,

Country4

Patient Identity - Standards Comparison

5

Patient Identity - Standards Suggestion

Suggested use of HL7 CDA  R2 as the standard, conditional with the request to HL7 to include:– Extend name to include display name as exists in the ASTM

CCR– Extend ID to allow for the use of a URI to act as a namespace

for the identifier, as opposed to an OID– Eliminate licensing fees for header data

Rationale for this Suggestion:  – HL7 CDA can better accommodate international representation

of names – Future support and maintenance of the standard viewed to be

better with HL7

6

Patient Identity - Use Case Example

<recordTarget> <patientRole> <id extension="1234567" root="http://www.nh.gov/safety/divisions/dmv/" /> <addr use="HP"> <streetAddressLine>1234 Main St. Apt 3</streetAddressLine> <city>Bedford</city> <state>MA</state> <postalCode>10730</postalCode> </addr> <patient> <name> <prefix qualifier="AC">Dr.</prefix> <given> John</given> <given>William</given> <family>Smith</family> <displayName>Dr. John William Smith</displayName> </name> <birthTime value="19600427" /> </patient> </patientRole></recordTarget>

7

Provenance - Use Case

The PCAST report identifies many needs and applications for provenance – our approach has been to suggest a subset– Determine the source or owner of information, and its

organizational affiliation

– Prove the data was not subject to tampering

– Provide for non-repudiation of Tagged Data Elements

8

Goal: Who created this data?How can I be sure?

Provenance - Suggested Metadata

Tagged Data Element (TDE) Identifier – Allows other TDEs to link to this particular instance and also allows

users to keep a log of the set of TDEs used for a particular task

TimeStamp– The time the TDE was created and sealed

Actor/Affiliation: The Distinguished Name of the actor who sealed the TDE – The granularity of the “actor” identified in the “wrapper” metadata is

organizational “entity” and not “individual” – Optional: A more granular identification of the Actor

Signature– A digital signature that binds the metadata to the contained

information to provide non-repudiation and integrity protection9

Provenance Stds Healthcare Stds Other

Denotes a “superficially” matching metadata elementS

10

Provenance – Standards Comparison

Provenance – Standards Suggestions

Suggested use of HL7 CDA  R2 Header as the standard– TDE identifier, time stamp, and the optional, more

granular Actor/Affiliation

– Metadata should point to the entity record in the Enterprise-Level Provider Directory, which may be a URI

The X.509 Certificate contains the Actor/Affiliation as a Distinguished Name and is used to sign the metadata and content

11

Provenance - HL7 CDA Header Example

12

<id extension="http://stelsewhere.com/id/12345" /> <effectiveTime value="20011217093047"/><author> <assignedAuthor> <id extension="http://providerdirectory.org/12345" assigningAuthorityName="Provider Directory X" /> <assignedPerson> <name> <family>Fergusson</family> <given>Robert</given> <prefix>Dr.</prefix> </name> </assignedPerson> <representedOrganization> <name>St. Elsewhere Hospital</name> </representedOrganization> </assignedAuthor></author>

Privacy

Goal: Determine what privacy metadata are needed for each TDE

Power team is still discussing Privacy

13

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

14

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.

15

Privacy - Suggested Metadata

Privacy - Standards Comparison

16