1 / 22

Privacy Metadata

Privacy Metadata . High-level business analysis Vancouver WGM May 2012. User Stories: Building Blocks. System Requirements Tiger Team. Information Exchange Tiger Team. Consent Management Tiger Team. Common Requirements across S&I. Applicable to all initiatives not only DS4P :

kassia
Download Presentation

Privacy Metadata

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. Privacy Metadata High-level business analysis Vancouver WGM May 2012

  2. User Stories: Building Blocks System Requirements Tiger Team Information Exchange Tiger Team Consent Management Tiger Team

  3. Common Requirements across S&I • Applicable to all initiatives not only DS4P : • Patient Identity • Cross enterprise/community identification • Transaction for management and query of identity • Provider Identity (Healthcare Provider Directory Initiative) • Includes digital certificates • Organization (for node authentication) • Person (for Direct) • Data encryption, integrity • Personally identifiable information should always be encrypted regardless whether it appears in message or envelope • Protected information • Authentication (system), audit, logging • Document Exchange

  4. Standards Snapshots: By Purpose Information Exchange Tiger Team • Document Exchange Standards • IHE XDS, IHE XDR, IHE XCA • Depend on Infrastructure: ATNA, CT, DEN (supplement) • Content Profile OMG hData REST Binding for RLUS • Document/Standards • Disclosed Data Content • Consolidated CDA Templates- US Realm (based on CCD, CDA R2) • HL7 hData Record Format V1DSTU • Consent Directive • HL7 Consent Directive CDA IG (based on CDA R2) • Document Submission Metadata Standards – in support of Document Exchange Standards for IHE XD*, XCA • IHE XDS Metadata, IHE XCA metadata. IHE XDM Metadata • CDA Header – part of the CDA-based documents and will be analyzed there • Relies heavily terminology standards • Terminology Standards • Privacy metadata (for codes for confidentiality, obligation/condition, purpose) • Protected diagnosis, document types, clinical data encoding (LOINC, SNOMED-CT, ICD-9, ICD-10) • Provider classification - 42 CFR Part provider • Analysis Models • Domain Models: HL7 Security Domain Analysis, FHIM • Functional Models: HL7 EHR System Functional Model Consent Management Tiger Team System Requirements Tiger Team

  5. Privacy Policy Overview Composite Privacy Policies • Composite policies are complex, they comprise of several, computable policies • Privacy metadata used to summarize the relevant base policies: • Confidentiality level • Information source is a covered substance abuse treatment • Consent required for disclosure/re-disclosure

  6. Request Metadata – aligned with PCAST HIT recommendation

  7. Example Data Segmentation for Privacy • Criteria for data filtering are identified by privacy policies • Protected diagnoses (Title 38) • Facility type (42 CFR Part 2) • Payment type (ARRAHITECH) • Example value set based terminology standards • SNOMED-CT • LOINC • HL7

  8. Protected Diagnoses List

  9. Payment/Coverage

  10. Facility Type

  11. Privacy Metadata Inside CDA Clinical Document Architecture (CDA) based Documents • Atomic data objects • Support confidentiality level in a hierarchical way • Global – in the header, it applies overall to the document • Per section – the highest level must apply to the document Confidentiality = Restricted Confidentiality = Restricted Confidentiality = Normal Confidentiality = Restricted Assumptions: - Receiving EHR system can enforce access control to control access to restricted information - Only information receiving organization is authorized to receive is sent Recommendation: - Apply “highest watermark approach” to applying confidentiality code to document - Use HL7 confidentiality code system, CDA subset (N, R, VR)

  12. Sending 42 CFR protected information Confidentiality Code Select documents to be sent IHE XUA ++ Metadata Submission Set Metadata DocumentEnvelope Metadata DocumentEnvelope Metadata DocumentEnvelope Metadata Segment protected information Submit documents to recipient Specify user, role, purpose, consent reference Document Envelope Metadata is the XDSDocumentEntry

  13. Receiving 42 CFR protected information Parse XUA Metadata Submission Set Metadata XUA ++ Metadata DocumentEnvelopeMetadata DocumentEnvelopeMetadata DocumentEnvelopeMetadata Interpret Submission Metadata Parse Document Metadata Persist documents and metadata Purpose of Use Confidentiality Code

  14. Re-disclosure: Sending 42 CFR protected information Submission Set Metadata Locally created Document Envelope Metadata Document Envelope Metadata Document EnvelopeMetadata Select documents to be sent XUA ++ Metadata Segment protected information Submit documents to recipient Specify user, role, purpose, consent reference Third-party documents and metadata Third-party author

  15. Open Issues Redisclosure Notification: - Machine readable and/or human readable? 2. Can the approach presented here satisfy use case requirements if the payload is not a CDA?

More Related