HIT Standards Committee Metadata Analysis Power Team

1. HIT Standards CommitteeMetadata Analysis Power Team Stan Huff, Chair June 22, 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 and standards for the following categories: • Patient Identity • Provenance • Privacy The HIT Standards Committee previously approved recommendations from the Power Team on Patient Identity and Provenance • Today’s discussion recaps those decisions, as well as presents recommendations for privacy

4. Patient Identity Summary HIT Standards Committee has already supported the following decisions for patient identity

5. Provenance Summary HIT Standards Committee has already supported the following decisions for provenance

6. PRIVACY

7. Use Cases from PCAST Analysis • Patient pushes data from PHR • Patient has complete control of what is sent • Simple query authorized by the patient • Queries are directed to facilities known to hold the data • 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 • Complex query based on policies • Query to DEAS to discover where the data exists • Requests to each data source for specific data needed • 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

8. Privacy - Sensitive Information Model Can the envelope contain sensitive information? Can the envelope be broken into parts? No Yes • This has an impact on the provenance work already done. No Yes • Perform all checking up front • Provenance and privacy can expose sensitive information • More work for policy enforcement points • Expose just the patient identity • Allow requests for provenance, privacy • Can defer policy evaluation • Greater complexity

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

10. Privacy - Suggested Metadata Elements • 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 – eliminated from consideration

11. Privacy Suggestions – Metadata Elements • Rationale: the Power Team agreed to focus on the Content metadata: • Needed to enforce the current federal and state policies, as well as more granular policies that may be adopted in the future • 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) • External policy registries would be needed but we did not address the specifics of how this might be accomplished

12. Privacy - Standards Comparison

13. Privacy - Analyzed Standards Four standards were investigated: • BPPC w/ IHE XDS • CDA R2 PCD w/ CDA headers • P3P • EPAL Built for online businesses;no capture of content metadata MITRE suggestions:

14. Privacy - Use Case Example IHE XDS <rim:Name> <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="Generic Image"></rim:Name> <rim:Name> <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="Restricted"></rim:Name> Generic format relies on context to find relevant fields Legitimate values defined by an Affinity Domain CDA <?xml version="1.0" encoding="UTF-8"?><ClinicalDocument xmlns="urn:hl7-org:v3" classCode="DGIMG"> <realmCode code="US"> <typeId root="2.16.840.1.113883.1.3" extension="09230” /> <confidentialityCode value="SDV" /> <code code="34788-0" displayName= "PsychiatricConsult note"codeSystemName="LOINC"/></ClinicalDocument> Relies on HL7 class hierarchy Limited set of confidentiality codes

15. Privacy Suggestions - Standards • Standard chosen:  HL7 CDA R2 w/ headers • Coded values for Data type:  • Suggest using the HL7 Class Codes as the basis and the LOINC codes specified in the CDA document type to provide additional granularity. • LOINCcodes are attractive because of the ease with which new codes can be added.

16. Privacy Suggestions - Standard • Coded Values for Sensitivity: • New coded value set will need to be developed, need process for defining the values for this etc.  Strawman list of sensitivity tags includes • Substance Abuse (ETH) • Reproductive Health • Sexually Transmitted Disease (HIV) • Mental Health (PSY) • Genetic Information • Violence (SDV) • Other • Strongly encourage that these values be extensible by adding new levels in the hierarchy.