report to the hitpc security and privacy tiger team s&i framework data segmentation for privacy...
TRANSCRIPT
Report to the HITPC Security and Privacy Tiger TeamS&I Framework Data Segmentation for Privacy Initiative Pilots 3/10/2014
1
User Story Example (1)
The Patient receives care at their local hospital for a variety of conditions, including substance abuse as part of an Alcohol/Drug Abuse Treatment Program (ADATP). Data requiring additional protection and consent directive are captured and recorded. The patient is advised that the protected information will not be shared without their consent.
User Story Example (2)
3
A clinical workflow event triggers additional data to be sent to Provider/Organization 2. This disclosure has been authorized by the patient, so the data requiring heightened protection is sent along with a prohibition on redisclosure.
Provider/ Organization 2 electronically receives and incorporates patient additionally protected data, data annotations, and prohibition on redisclosure.
HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1
• Completed Normative Ballot in Jan 2014 and was successfully reconciled in Feb 2014. HL7 approved the final standard for publication and are processing with ANSI.
• The standard uses document level tagging to convey confidentiality levels and obligations.
• The standard uses vocabularies to convey specific meanings, such as “Do not re-disclose without consent” or “This document is restricted”.
DS4P Standard
4
HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1
• Contains three volumes: • Content Specification• DS4P with Direct• DS4P with Exchange
DS4P Standard
5
Volume 1: CDA R2 and Privacy Metadata Reusable Content Profile • Contains templates and reusable building blocks for the
transport specifications.– The reusable building blocks may be applied to other information
exchange standards
• Enables the association of information object (e.g. document) with security labels, which can be linked to privacy policies.
• Supports the requirement to specify the provenance of clinical data contained in the structured content of a clinical document.
DS4P Standard
6
Volume 2 : NwHIN Direct Transport Profile, andVolume 3: NwHIN Exchange Transport Profile
• Transport Profiles containing transport specific constraints based on the reusable building blocks.
• The constraints are applied to the transport-specific metadata (e.g. Document Sharing /XDS Metadata used by Exchange, and XDM Metadata used by Direct).
• The generic transport-specific metadata were added to the underlying technical framework (i.e. IHE ITI Vol. 3)
DS4P Standard
7
Selected Standards
Selected Standards
8
STANDARD: HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1(Includes Content Profile, Profile for Direct, Profile for exchange)
Capability Standards/Profiles used by the HL7 DS4P R1 Standard
Specific Usage
Metadata Vocabularies (for Transport and/or Document Metadata)
HL7 RefrainPolicy Conveys specific prohibitions on the use of disclosed health information (e.g. prohibition of redisclosure without consent)
HL7 PurposeofUse Conveys the purpose of the disclosure of health information (e.g. treatment, research, emergency)
HL7 BasicConfidentialityCodeKind
Used to represent confidentiality codes associated with disclosed health information (e.g. restricted) as specified in the HL7 Healthcare Security Classification standard (HCS).
HL7 ObligationCode Used to convey specific obligations associated with disclosed health information (e.g. encryption)
HL7 ActPolicyType Used to convey a type of policyHL7 SensitivityPrivacyPolicy
Used to convey the sensitivity level of a specific policy
Capability Standard/Profile Specific Usage
Patient Consent Structure
HL7 Implementation Guide for CDA®, Release 2: Consent Directives, Release 1 (DSTU)
Provides representations for expressing privacy preferences and exchanging privacy policies that can be enforced by consuming systems
Transport SOAP Transport-level securityTransport SMTP and S/MIME S/MIME attributes are bound to SMTP
to provide for the use of secure email as the transport mechanism for exchanging patient data
Conveying Identity
- Cross-Enterprise User Assertion (XUA)
- OASIS SAML Specification Version 2.0
IHE XUA Metadata
SAML Assertion (SAML Request and Response)
Conveying Identity X.509 Digital Certificates PKI to support Direct implementations
Selected Standards
9
Other Standards Referenced by the HL7 DS4P Standard:
DS4P PILOT ACCOMPLISHMENTSData Segmentation for Privacy Initiative
10
VA/SAMHSA Pilot:
• The pilot was successfully tested and demonstrated in multiple venues, including the Interoperability showcase at HIMSS 2013 and the HL7 Plenary meeting in Baltimore, September 2013.
• VA have extended the DS4P capabilities to demonstrate utilization of FHIR for DS4P (demonstrated at HL7 in Jan 14, in real time, using resources from Australia, Canada and USA).
Pilot Accomplishments
11
NETSMART Pilot:
• The pilot was successfully tested and demonstrated in multiple venues, including the Interoperability showcase at HIMSS 2013.
• The Netsmart DS4P Part 2 solution has been implemented with the community services referral network in Tampa Bay (2-1-1 system), helping them manage restricted data associated with programs regulated by 42 CFR part 2.
Pilot Accomplishments
12
Jericho Systems / University of Texas/Conemaugh Pilot:
• Utilized an external patient consent repository to provide machine readable consent directives that can be processed according to various privacy policies as part of any automated release of PHI on the eHealth Exchange.
• The pilot used standards based message formats, consistent with current healthcare standards to support patient consent over released PHI, including segmented data.
Pilot Accomplishments
13
CERNER BH (Formerly SATVA Pilot):Included Cerner Anasazi, Valley Hope Association, Defran Systems, Inc. and HEALTHeLINK
• Cerner recently reported their Behavioral Health solution will have DS4P (using Direct) incorporated into full production for release in April of this year.
• At HIMSS 2014 Cerner demonstrated marked-up CCDs being sent from the Cerner BH solution to the Cerner Millennium (large scale, general medical) solution.
• Demonstrated ability to send notice of prohibition on re-disclosure (as required by 42 CFR part 2)
• The Cerner Millennium solution design teams have begun work to recognize and process the DS4P marked-up data received from the Cerner BH solution. Their expectation is to include this functionality in a production release later this year.
Pilot Accomplishments
14
CONCLUSIONData Segmentation for Privacy Initiative
15
Conclusion:
• Data segmentation standards are readily available, normative standards. They utilize widely adopted vocabularies to allow BH systems to better control how the information is handled.
• Pilots have demonstrated ability to mark data and to accompany data with requisite notice at the document level.
• One major vendor expects to include sending, receiving and processing BH information, using DS4P functionality, in a production release later this year (BH to general EHR)
16
Contact Information
Thank you!Johnathan Coleman, CISSP, CISMInitiative Coordinator, Data Segmentation for PrivacyPrincipal, Security Risk Solutions Inc.698 Fishermans Bend,Mount Pleasant, SC 29464Email: [email protected] Tel: (843) 647-1556
Julie Chua, PMP, CAP, CISSPOffice of the Chief Privacy OfficerOffice of the National Coordinator for Health Information TechnologyDepartment of Health and Human ServicesEmail: [email protected] Tel: (202) 690-3911
17
Ioana Singureanu, MSStandards SME, Data Segmentation for PrivacyPrincipal, Eversolve LLC8 Woodvue Road, Windham, NH 03087Email: [email protected]: (603) 548 5640
BACKUP SLIDESData Segmentation for Privacy Initiative
18
Layered Approach for Privacy Metadata
• “Russian doll” concept of applying metadata with decreasing specificity as layers are added to the clinical data.
• Privacy metadata uses standards to convey:– Confidentiality of data in clinical payload– Obligations of receiving system– Allowed purpose of use
Technical Approach
19
Types of Privacy Metadata used by DS4P
• Purpose of Use: – Defines the allowed purposes for the disclosure (e.g.
Treatment, Emergency Treatment etc).
• Obligations:– Refrain Codes: Specific obligations being placed on the
receiving system (e.g. do not re-disclose without consent)
• Confidentiality Codes:– Used by systems to help convey or
enforce rules regarding access to data requiring enhanced protection. Uses “highest watermark” approach.
Technical Approach
20
SENDING SYSTEM: Provider/Healthcare
Organization A
System Behavior
Add privacy metadata to health information to be
disclosed to other organization
Identify Information that is further restricted
Verify the patient’s privacy consent allows
the disclosure of protected information
RECEIVING SYSTEM: Provider/Healthcare
Organization B
Verify patient’s consent before re-disclosure of
protected health information
Process privacy metadata associated with health
information received from other organizations
Identify third-party protected information before re-disclosure
Technical Approach
21
- LOINC Document Type/Datatype for CDA- ASC X12 4010/5010 for Healthcare Provider & facility types and Healthcare Coverage Type- SNOMED-CT for Protected diagnoses/problems
- Query for consent directive location (optional)- Query for consent directive (optional)- Check HL7 CDA R2 PCD
- HL7 Confidentiality Code: for CDA (N,R,V)- HL7 Refrain Code: (e.g. prohibition on re-disclosure
without consent) - HL7 Purpose of Use: The purpose for the information
disclosure (e.g. support treatment, payment, operations, research, etc.)
- URL or XACML Pointer for Policy Reference if needed
Requirements of Sending System
Technical Approach
SENDING SYSTEM: Provider/Healthcare
Organization A
Add privacy metadata to health information to be
disclosed to other organization
Identify Information that is further restricted
Verify the patient’s privacy consent allows
the disclosure of protected information
22
ALIGNMENT WITH PREVIOUS HITSC RECOMMENDATIONS
Data Segmentation for Privacy Initiative
23
Response to HITSC S&P WG
24
HITSC Recommendation DS4P Analysis
Metadata pertaining to privacy should include:• Policy Pointer: A URL that points to the
privacy policy in effect at the time the TDE is released.
• A Policy Pointer should point to a universally recognized Policy Reference to enable the consuming organizations to apply their interpretation of that policy.*
• Metadata can also be used to provide some context as to why the information is protected (i.e. policy pointer/reference), as well as the special handling obligation placed on the receiver as a result of the policy.
*The Policy Pointer can be included in the IHE XD* metadata or in the Patient Consent Directive.
Excerpt from 6/29/2012 Report
Response to HITSC S&P WG
25
HITSC Recommendation DS4P Analysis
Metadata pertaining to privacy should include Content Metadata (Datatype and Sensitivity).
Content Metadata that are needed to enforce current federal and state policies as well as to anticipate more granular policies that may be defined. • Datatype: Information category from a clinical
perspective.
• Sensitivity: Indicates special handling that may be necessary per the referenced policy.
DS4P Approach uses Datatype and Confidentiality* content metadata
• Datatype as a data element refers to the document type (patient data) being exchanged. An initial list of possibly sensitive document types that would require data segmentation has been provided in the implementation guide.
• DS4P Approach leverages Confidentiality codes. Initial approaches recommended for piloting focus on using the confidentiality code specified within privacy metadata, or by using the Patient Consent Directive.
* DS4P approach uses HL7 confidentiality codes as metadata to describe sensitivity. * Initial approaches recommended for piloting focus on using either the Patient Consent Directive as expressed using CDA or by specifying a confidentiality code within the IHE XDS/XDR/XDM metadata.
Excerpt from 6/29/2012 Report
Response to HITSC S&P WG
26
HITSC Recommendation DS4P Analysis
• In order to provide coded values for Datatype, the LOINC codes specified in the CDA document code element are suggested. LOINC codes are suggested because they provide additional granularity.
• DS4P concurred with this recommendation and a constrained list of document types are included in the Data Segmentation for Privacy implementation guide that are specific to the requirements of data segmentation.
• As recommended by the Health IT Standards Committee, document codes MUST be defined using LOINC, and Sending and receiving systems MUST be able to validate and evaluate LOINC document types to be able to implement this guide.
Excerpt from 6/29/2012 Report