Metadata Standards for Patient Identity, Provenance, and Privacy

1. HIT Standards CommitteeMetadata Analysis Power Team Stan Huff, Chair May 18, 2011

2. Power Team Members • Stan Huff, Chair • John Halamka • Steve Ondra • Dixie Baker • Wes Rishel • Carl Gunter • Steve Stack

3. Power Team Charge Identify metadata elements that are required for the following categories: • Patient Identity • Provenance • Privacy Review standards that represent those metadata elements: • An existing standard is available and can be used as is • An existing standard is available but must be modified to be used • Merge standards • Create new standard

4. 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, Country

5. Patient Identity - Standards Comparison

6. 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

7. 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>

8. Provenance - Use Case Goal: Who created this data? How can I be sure? • 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

9. 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 protection

10. Provenance – Standards Comparison Other Provenance Stds Healthcare Stds Denotes a “superficially” matching metadata element

11. 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

12. Provenance - HL7 CDA Header Example <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>

13. Privacy • Goal: Determine what privacy metadata are needed for each TDE • Power team is still discussing Privacy

14. 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 Out of Scope Infeasible

15. Privacy - Suggested Metadata • 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.

16. Privacy - Standards Comparison