Successfully reported this slideshow.
HIT Standards Committee Metadata Analysis Power Team Stan Huff, Chair June 22, 2011
Power Team Members <ul><li>Stan Huff, Chair  </li></ul><ul><li>John Halamka </li></ul><ul><li>Steve Ondra </li></ul><ul><l...
Power Team Charge <ul><li>Identify metadata elements and standards for the following categories: </li></ul><ul><ul><li>Pat...
Patient Identity Summary <ul><li>HIT Standards Committee has already supported the following decisions for patient identit...
Provenance Summary <ul><li>HIT Standards Committee has already supported the following decisions for provenance </li></ul>...
PRIVACY
Use Cases from PCAST Analysis <ul><li>Patient pushes data from PHR </li></ul><ul><ul><li>Patient has complete control of w...
Privacy  -  Sensitive Information Model <ul><li>Can the envelope be broken into parts? </li></ul>Yes No <ul><li>Expose jus...
Privacy  -  Rationale for Suggested Metadata  <ul><li>Privacy policies include the following: </li></ul><ul><ul><li>Conten...
<ul><li>Policy Pointer: URL that indicates which privacy policy governs the release of the TDE. </li></ul><ul><li>Content ...
Privacy Suggestions – Metadata Elements <ul><li>Rationale:  the Power Team agreed to focus on the Content metadata: </li><...
Privacy - Standards Comparison
<ul><li>Four standards were investigated: </li></ul><ul><li>BPPC w/ IHE XDS </li></ul><ul><li>CDA R2 PCD w/ CDA headers </...
Privacy -  Use Case Example  CDA <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <ClinicalDocument  xmlns = &qu...
Privacy Suggestions - Standards <ul><li>Standard chosen:  HL7 CDA R2 w/ headers </li></ul><ul><li>Coded values for Data ty...
Privacy Suggestions - Standard <ul><li>Coded Values for Sensitivity:  </li></ul><ul><ul><li>New coded value set will need ...
Upcoming SlideShare
Loading in …5
×

Metadata Power Team

1,121 views

Published on

Published in: Health & Medicine
  • Be the first to comment

  • Be the first to like this

Metadata Power Team

  1. 1. HIT Standards Committee Metadata Analysis Power Team Stan Huff, Chair June 22, 2011
  2. 2. Power Team Members <ul><li>Stan Huff, Chair </li></ul><ul><li>John Halamka </li></ul><ul><li>Steve Ondra </li></ul><ul><li>Dixie Baker </li></ul><ul><li>Wes Rishel </li></ul><ul><li>Carl Gunter </li></ul><ul><li>Steve Stack </li></ul>
  3. 3. Power Team Charge <ul><li>Identify metadata elements and standards for the following categories: </li></ul><ul><ul><li>Patient Identity </li></ul></ul><ul><ul><li>Provenance </li></ul></ul><ul><ul><li>Privacy </li></ul></ul><ul><li>The HIT Standards Committee previously approved recommendations from the Power Team on Patient Identity and Provenance </li></ul><ul><ul><li>Today’s discussion recaps those decisions, as well as presents recommendations for privacy </li></ul></ul>
  4. 4. Patient Identity Summary <ul><li>HIT Standards Committee has already supported the following decisions for patient identity </li></ul>Metadata Elements Rationale Additional Suggestions Standard <ul><ul><li>Patient’s name </li></ul></ul><ul><ul><li>Date of birth </li></ul></ul><ul><ul><li>Current zip code </li></ul></ul><ul><ul><li>Patient identifiers </li></ul></ul><ul><ul><li>Address </li></ul></ul>Represent the minimum elements that are required to uniquely select a patient from a population with a guaranteed degree of accuracy <ul><ul><li>Add a display name element to accommodate non-western names </li></ul></ul><ul><ul><li>Use a URI to act as a namespace for the identifier  </li></ul></ul>Use the HL7 CDA R2 header format. XML based format for describing generic clinical documents can best accommodate international representation of names.
  5. 5. Provenance Summary <ul><li>HIT Standards Committee has already supported the following decisions for provenance </li></ul>Metadata Elements Rationale Additional Suggestions Standard <ul><li>Tagged Data Element (TDE) identifier </li></ul><ul><li>Time stamp </li></ul><ul><li>The actor and the actor’s affiliation </li></ul><ul><li>A digital certificate  </li></ul><ul><li>  </li></ul>Envelope will provide information permitting the recipient to judge whether a trusted source sent the data, when it was packaged, and whether any content tampering took place.  <ul><li>The use of an X.509 certificate to digitally sign the envelope contents </li></ul>Metadata elements be expressed using the HL7 CDA R2 format. 
  6. 6. PRIVACY
  7. 7. Use Cases from PCAST Analysis <ul><li>Patient pushes data from PHR </li></ul><ul><ul><li>Patient has complete control of what is sent </li></ul></ul><ul><li>Simple query authorized by the patient </li></ul><ul><ul><li>Queries are directed to facilities known to hold the data </li></ul></ul><ul><ul><li>The party that holds the data must respect any consent and privacy preferences specified by the patient and include the identity, provenance, and privacy information with the data </li></ul></ul><ul><li>Complex query based on policies </li></ul><ul><ul><li>Query to DEAS to discover where the data exists </li></ul></ul><ul><ul><li>Requests to each data source for specific data needed </li></ul></ul><ul><ul><li>The party that holds the data must respect any consent and privacy preferences specified by the patient and include the identity, provenance, and privacy information with the data </li></ul></ul>
  8. 8. Privacy - Sensitive Information Model <ul><li>Can the envelope be broken into parts? </li></ul>Yes No <ul><li>Expose just the patient identity </li></ul><ul><li>Allow requests for provenance, privacy </li></ul><ul><li>Can defer policy evaluation </li></ul><ul><li>Greater complexity </li></ul><ul><li>Perform all checking up front </li></ul><ul><li>Provenance and privacy can expose sensitive information </li></ul><ul><li>More work for policy enforcement points </li></ul>Can the envelope contain sensitive information? Yes No <ul><li>This has an impact on the provenance work already done. </li></ul>
  9. 9. Privacy - Rationale for Suggested Metadata <ul><li>Privacy policies include the following: </li></ul><ul><ul><li>Content metadata: Datatype, Sensitivity, Coverage </li></ul></ul><ul><ul><li>Request metadata: Recipient, Affiliation, Role, Credential, Purpose </li></ul></ul><ul><ul><li>Obligations </li></ul></ul><ul><li>Approaches for storing policies: </li></ul><ul><ul><li>Self-contained = Policy attached to each Tagged Data Element (TDE) </li></ul></ul><ul><ul><ul><li>External policy registries not needed </li></ul></ul></ul><ul><ul><ul><li>Difficult for patients to find and manage all TDEs when policies change </li></ul></ul></ul><ul><ul><li>Layered = Policy referenced by each TDE </li></ul></ul><ul><ul><ul><li>External policy registries needed </li></ul></ul></ul><ul><ul><ul><li>Minimal set of metadata tags associated with TDEs </li></ul></ul></ul>Out of Scope Infeasible
  10. 10. <ul><li>Policy Pointer: URL that indicates which privacy policy governs the release of the TDE. </li></ul><ul><li>Content Metadata: Describes the information in the TDE. </li></ul><ul><ul><li>Datatype : information category from a clinical perspective; </li></ul></ul><ul><ul><li>Sensitivity : indicates special handling may be necessary; </li></ul></ul><ul><ul><li>Coverage : who paid to acquire the information – eliminated from consideration </li></ul></ul>Privacy - Suggested Metadata Elements
  11. 11. Privacy Suggestions – Metadata Elements <ul><li>Rationale: the Power Team agreed to focus on the Content metadata: </li></ul><ul><ul><li>Needed to enforce the current federal and state policies, as well as more granular policies that may be adopted in the future </li></ul></ul><ul><ul><li>Other information was agreed to be out of scope for this effort, including: request metadata (such as recipient, affiliation, purpose, etc.), environmental metadata (such as location, time, etc.), and policy specification (including obligations) </li></ul></ul><ul><ul><li>External policy registries would be needed but we did not address the specifics of how this might be accomplished </li></ul></ul>
  12. 12. Privacy - Standards Comparison
  13. 13. <ul><li>Four standards were investigated: </li></ul><ul><li>BPPC w/ IHE XDS </li></ul><ul><li>CDA R2 PCD w/ CDA headers </li></ul><ul><li>P3P </li></ul><ul><li>EPAL </li></ul>Privacy - Analyzed Standards Built for online businesses; no capture of content metadata MITRE suggestions : Suggestion Rationale Modify CDA CDA already includes datatype information (using HL7 class codes and document type codes) and sensitivity tags (using confidentiality codes). Modify XDS XDS allows new tags and values to easily be added. Create a new standard <ul><li>Class codes may need to be augmented (e.g., to include allergies). </li></ul><ul><li>Confidentiality codes need to be augmented to handle common sensitivity tags. </li></ul><ul><li>Coverage and policy pointers need to be added. </li></ul>
  14. 14. Privacy - Use Case Example CDA <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <ClinicalDocument xmlns = &quot;urn:hl7-org:v3&quot; classCode = &quot;DGIMG&quot; > <realmCode code = &quot;US&quot; > <typeId root = &quot;2.16.840.1.113883.1.3&quot; extension = &quot;09230” /> <confidentialityCode value = &quot;SDV&quot; /> <code code=&quot;34788-0&quot; displayName= &quot;Psychiatric Consult note&quot; codeSystemName=&quot;LOINC&quot;/> </ClinicalDocument> IHE XDS <rim:Name> <rim:LocalizedString xml:lang = &quot;en-us&quot; charset = &quot;UTF-8&quot; value = &quot;Generic Image&quot; > </rim:Name> <rim:Name> <rim:LocalizedString xml:lang = &quot;en-us&quot; charset = &quot;UTF-8&quot; value = &quot;Restricted&quot; > </rim:Name> Generic format relies on context to find relevant fields Legitimate values defined by an Affinity Domain Relies on HL7 class hierarchy Limited set of confidentiality codes
  15. 15. Privacy Suggestions - Standards <ul><li>Standard chosen:  HL7 CDA R2 w/ headers </li></ul><ul><li>Coded values for Data type:  </li></ul><ul><ul><li>Suggest using the HL7 Class Codes as the basis and the LOINC codes specified in the CDA document type to provide additional granularity. </li></ul></ul><ul><ul><li>LOINC codes are attractive because of the ease with which new codes can be added. </li></ul></ul>
  16. 16. Privacy Suggestions - Standard <ul><li>Coded Values for Sensitivity: </li></ul><ul><ul><li>New coded value set will need to be developed, need process for defining the values for this etc.  Strawman list of sensitivity tags includes </li></ul></ul><ul><ul><ul><li>Substance Abuse (ETH) </li></ul></ul></ul><ul><ul><ul><li>Reproductive Health </li></ul></ul></ul><ul><ul><ul><li>Sexually Transmitted Disease (HIV) </li></ul></ul></ul><ul><ul><ul><li>Mental Health (PSY) </li></ul></ul></ul><ul><ul><ul><li>Genetic Information </li></ul></ul></ul><ul><ul><ul><li>Violence (SDV) </li></ul></ul></ul><ul><ul><ul><li>Other </li></ul></ul></ul><ul><li>Strongly encourage that these values be extensible by adding new levels in the hierarchy. </li></ul>

×