hit standards committee metadata analysis power team
DESCRIPTION
HIT Standards Committee Metadata 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. Power Team Charge. - PowerPoint PPT PresentationTRANSCRIPT
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