Date post: | 02-Jan-2016 |
Category: |
Documents |
Upload: | veda-everett |
View: | 21 times |
Download: | 0 times |
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