1 / 16

HIT Standards Committee Metadata Analysis Power Team

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.

Download Presentation

HIT Standards Committee Metadata Analysis Power Team

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related