metadata power team
TRANSCRIPT
HIT Standards CommitteeHIT Standards CommitteeMetadata Analysis Power TeamMetadata Analysis Power Team
Stan Huff, Chair
June 22, 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 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
3
Patient Identity Summary
HIT Standards Committee has already supported the following decisions for patient identity
4
Metadata Elements
Rationale Additional Suggestions
Standard
• Patient’s name
• Date of birth• Current zip
code• Patient
identifiers• Address
Represent the minimum elements that are required to uniquely select a patient from a population with a guaranteed degree of accuracy
• Add a display name element to accommodate non-western names
• Use a URI to act as a namespace for the identifier
Use the HL7 CDA R2 header format.
XML based format for describing generic clinical documents can best accommodate international representation of names.
Provenance Summary
HIT Standards Committee has already supported the following decisions for provenance
5
Metadata Elements Rationale Additional Suggestions
Standard
• Tagged Data Element (TDE) identifier
• Time stamp• The actor and
the actor’s affiliation
• A digital certificate
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.
• The use of an X.509 certificate to digitally sign the envelope contents
Metadata elements be expressed using the HL7 CDA R2 format.
PRIVACY
6
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
7
Privacy - Sensitive Information Model
8
Can the envelope be broken into parts?
Yes No
• Expose just the patient identity• Allow requests for provenance, privacy• Can defer policy evaluation• Greater complexity
• Perform all checking up front• Provenance and privacy can
expose sensitive information• More work for policy enforcement
points
Can the envelope contain sensitive information?
Yes
No
• This has an impact on the provenance work already done.
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
9
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 – eliminated from
consideration
10
Privacy - Suggested Metadata Elements
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
11
Privacy - Standards Comparison
12
Four standards were investigated:BPPC w/ IHE XDSCDA R2 PCD w/ CDA headersP3PEPAL
13
Privacy - Analyzed Standards
Built for online businesses;no capture of content metadata
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 • Class codes may need to be augmented (e.g., to include allergies).
• Confidentiality codes need to be augmented to handle common sensitivity tags.
• Coverage and policy pointers need to be added.
MITRE suggestions:
14
Privacy - Use Case Example
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= "Psychiatric Consult note" codeSystemName="LOINC"/></ClinicalDocument>
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
Relies on HL7 class hierarchy
Limited set of confidentiality codes
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.
– LOINC codes are attractive because of the ease with which new codes can be added.
15
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.
16