1 / 39

Data Segmentation for Privacy Summary

Data Segmentation for Privacy Summary. Process of segmentation and exchange of privacy policy protected information across provider organizations . Summary. Based on federal (and state) privacy policy Substance abuse treatment facility (42CFR Part2)

caia
Download Presentation

Data Segmentation for Privacy Summary

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. Data Segmentation for Privacy Summary Process of segmentation and exchange of privacy policy protected information across provider organizations

  2. Summary • Based on federal (and state) privacy policy • Substance abuse treatment facility (42CFR Part2) • Substance Abuse related problems (Title 38) • Self-pay • Identified encounters where the services were “out-of—pocket”, explicit opt-in require • Translates the patient privacy preference into computable rules • Identifies the sensitive information using explicit

  3. Project Need References • Data Segmentation for Privacy Project documents referenced in this IG are available on the DS4P Project Wiki • Data Segmentation for Privacy Project specified the requirements for this Implementation Guide in the Use Case Document • Detailed description of the project: S&I Initiative DS4P Project Executive Summary

  4. Data Segmentation for Privacy (DS4P) Project • Privacy Annotation Building Blocks • Interoperability standard neutral representation of metadata required to support privacy policies for • Interoperability standard specific building blocks (CDA templates) • Privacy Annotations • Provenance specified as mandatory information • Entry-level provenance mandatory if different than the header-specified provenance • Transport-specific building blocks for IHE XD* and Direct protocols • Metadata in addition to the “confidentialityCode” specifying the purpose of the data and receiver responsibilities

  5. 1) CDA Content Profile • CDA R2 and Privacy Metadata Reusable Content Profile (HL7_IG_DS4P_R1_CH1_CONTENT) • document template, clinical statements templates, and reusable building blocks for the transport specifications. • This document introduces the requirements and the technical approach to addressing unmet needs

  6. Templates: Clarify the use of Provenance

  7. Templates: Clarify the use of Provenance Document DocumentProvenance Section Section EntryProvenance Entry Privacy Annotation

  8. Templates: Privacy Annotation

  9. Templates: Reuse in Privacy Marking Section Section Privacy Marking Privacy Annotation

  10. 2) Transport Specifications • Two Transport Profiles containing transport specific constraints based on the reusable building blocks. • constraints represented in the reusable building blocks are applied to the transport-specific metadata (e.g. Document Sharing Metadata/XDS Metadata, XDM Metadata used by Direct) intended for implementation (e.g.SOAP. NwHIN Direct, REST). • two transport specification profiles are available to implementersfor use in the US

  11. NwHIN Transport Specifications • NwHINDirect Transport Profile, Release 1, January 2014 Normative Ballot • Unique Ballot ID: HL7_IG_DS4P_R1_CH2_DIRECT_N2_2014JAN • NwHINExchange Transport Profile, Release 1, January 2014 Normative Ballot • Unique Ballot ID: HL7_IG_DS4P_R1_CH3_EXCHANGE_N2_2014JAN

  12. Implementation-neutral Privacy Annotation Building Blocks Confidentiality Code – the only existing privacy annotation in CDA and IHE protocols, constrained to avoid disclosure of sensitive information Obligation Policy Code – encoded using standard HL7 value set, specifies receiver responsibilities (e.g. encrypt, comply with disclosure consent) Value Set Binding Value Set Binding Purpose of Use Code – added to the disclosed data set, specifies the purpose of the disclosed data (e.g. treatment) Refrain Policy Code – encoded using standard HL7 value set, specifies receiver responsibilities (e.g. no redisclosure) Value Set Binding Value Set Binding

  13. Building Blocks implementation • Document Exchange Metadta (aka XDS) • Reuses the DocumentEntry.confidentialityCode classification object • Mandatory according ot IHE ITI TF Vol.3, first occurrence ConfidentialityCode, constrained value set bindings • Additional, one ore more occurrences of Purpose of Use, constrained value set bindings • Additional, zero or more occurrences of Refrain Policy , constrained value set bindings • Additional, zero or more occurrences of Obligation Policy, , constrained value set bindings

  14. Additional Constraints Applied to Document Exchange Metadata • Constrain the coded values allowed for DocumentEntry metadata to avoid disclosure of protected information (e.g. substance abuse treatment facility) • DocumentEntry.practiceSettingCode (SNOMED-CT) • DocumentEntry.healthcareFacilityTypeCode (SNOMED-CT) • DocumentEntry.typeCode (LOINC) • Constrain the use of sender intended recipient to allow for digital certificates based on email address • For those projects like NwHIN and Direct where the • SubmissionSet.intendedRecipient

  15. HL7 DS4P Project Requirements • DS4P S&I Framework Initiative developed user scenarios for organizations exchanging medical records • Share All • Share Partial • Query/response vs. Push • Emergency/Break the glass • Additional requirements developed by the pilot implementers of the DSP Implementation Guide developed by ONC S&I Framework Initiative

  16. HL7 DS4P Ballot Structure CDAR2_IG_DS4P_CONTENT_R1_N2_2014JAN • DS4P Content • Building blocks • CDA Templates • Generic transport-related constraints • Provenance and Receiver details • Privacy Metadata • Constraints to existing metadata (value set constraints) • Transport specific XDS Metadata constraints • IHE XDR, XDS, etc. • IHE XDM (email) CDAR2_IG_DS4P_EXCHANGE_R1_N2_2014JAN CDAR2_IG_DS4P_DIRECT_R1_N2_2014JAN

  17. Privacy Annotation Building Blocks • Encoded metadata • Terminology based on the HL7 Healthcare Classification Scheme (HCS) specification • Obligation • Refrain • Purpose of Use • Confidentiality Level (confidentialityCode) • Based on the “Security Label” consisting of multiple privacy-related metadata elements

  18. Privacy Policies and Interoperability Privacy Policies are typically composites of simple, basic policies • Composite privacy policies (e.g. 42CFR Part)comprise of several basic, computable data sharing policies • Privacy metadata used to represent simple data sharing policies: • Confidentiality level • Purpose of use/disclosure • Information source is a covered substance abuse treatment • Consent required for disclosure/re-disclosure • Privacy metadata allows loosely-coupled systems and organization to exchange the most meaningful metadata related to the data shared among systems/organizations • Information exchanged may reference basic data sharing policies as privacy metadata • Confidentiality Code = restricted • Purpose of Use Code[1] = treatment • Purpose of Use Code[1] = treatment • Refrain Policy Code[1] = no redisclosure without consent Basic Data Sharing Policy Basic Data Sharing Policy Composite Privacy Policy

  19. Privacy Metadata used in Information Exchange to specify simple data exchange policies across organizations Transport Metadata No re-disclosure Summary Document/Message For treatment purpose Restricted

  20. Provenance Metadata - XML structure for items authored by a person Date/time • Author • Date/time • Organization • Provider name/title Provider Address Provider Name Provider Organization

  21. Provenance Metadata - XML structure for items authored by a device Date/time • Authoring device • Date/time • Organization • Device type/id Device Id Device Details Provider Organization

  22. Provenance Metadata – Rendered to users as HTML • Document Author • Date/time • Organization • Provider name/title

  23. Author specified at the clinical statement level – e.g. problem Section author Author Name Provider Organization Authoring Date • The author information may be displayed along with each problem • The author may be specified for the section

  24. Author specified at the clinical statement level – e.g. problem

  25. Next steps for implementers.. • To ensure that the data provenance requirements for exchange and persistence are met: • EHR system that send/disclose patient information using standard C-CDA document should or must include the author for each data element • EHR systems that receive this information must persist the provenance information (along with the privacy metadata) • The EHR system may not display the author unless the user needs it

  26. Privacy-Segmented C-CDA Document Structure – Provenance Document Provenance Entry Provenance • Specifies the author for all the content of the document in the header (e.g. an organization, clinician,or device). Already mandatory. Mandatory if the entry is authored by a differentmore specific (e.g. a specific clinician in theorganization identified in the header)

  27. Privacy-Segmented C-CDA Document-2 Privacy SegmentedSection Privacy Marking Entry • Specifies global metadata • Text describing prohibitions on redisclosure to the reader • Any C-CDA section may be privacy-segmented • Include PrivacyAnnotations to specify receiver responsibilities

  28. Data Provenance in C-CDA • Typically only the CDA document header specifies the provenance of the entire document • If a summary document contains data authored by more than one person, organization, or device the “MandatoryProvenanceTemplate” could be used

  29. Cross-Enterprise Document Sharing Metadata includes metadata for DS4P • Part of the “XDSDocumentEntry” are additional privacy metadata based on the DS4P building blocks contains

  30. Cross-Enterprise Document Sharing Metadata: Obligation and Refrain Policy • Indicating receiver responsibilities – including HIE responsibilities contains

  31. Purpose of Use Metadata in the XDS Metadata • Specifies purpose of use of the data in the XD* metadata used for IHE document exchange protocols • Consistent with the SecurityObservation and ebXML

  32. Refrain Policy Metadata in the XDS Metadata • Specifies receiver responsibilities in the XD* metadata used for IHE document exchange protocols • Consistent with the SecurityObservation and ebXML

  33. Obligation Policy Metadata in the XD* metadata • Specifies receiver responsibilities in the XD* metadata used for IHE document exchange protocols • Consistent with the SecurityObservation and ebXML

  34. PrivacyAnnotation Template • Based on HCS and new terminology/value set specifications • Specifies a choice of privacy annotations consistent with the PCAST Health IT report (Dec. 2010) • Constrained specifically to meet the use cases identified by the S&I Framework Initiative • Building blocks Confidentiality Purpose of Use Obligation Policy Code Refrain Policy Code

  35. Applying Privacy Annotations to an Entry • Privacy annotations may be associated with an entry in the (e.g. Privacy Markings entry) that reuses the PrivacyAnnotation template to specify confidentiality, receiver responsibilities (e.g. “redisclosure prohibited without consent”)

  36. Example: Applying Privacy Annotations to a Protected Problem • A protected problem may have specify privacy annotations (e.g. confidentiality level, added obligations, added refrains, and a specific purpose of use) • If the author differs from that specified in the header, the mandatory author information provides provenance details

  37. Privacy across the NwHIN C-CDA C-CDA C-CDA C-CDA NwHIN Gateway - Added privacy annotation

  38. Project Change Management and Maintenance • Change Management using HL7 GForge • SVN source control • CBCC Project to check in the MDHT Project containing the project constraints. It is also the home of the Consent Directive IG. • Security Project to maintain domain analysis, use cases, etc. It is the home of the harmonized Security and Privacy DAM • Any IHE, OASIS, etc. change requests also to be maintained here.

  39. Security Modeling Projects

More Related