Скачать презентацию Basic Patient Privacy Consents IHE Educational Workshop 2007 Скачать презентацию Basic Patient Privacy Consents IHE Educational Workshop 2007

b1c94d24223654436d6ed5d62e517e15.ppt

  • Количество слайдов: 33

Basic Patient Privacy Consents IHE Educational Workshop 2007 John Moehrke GE Healthcare Lori Fourquet Basic Patient Privacy Consents IHE Educational Workshop 2007 John Moehrke GE Healthcare Lori Fourquet e-Health. Sign LLC 3/15/2018 1

Basic Patient Privacy Consents XDS-MS Medical Documents History and Physical Preprocedure History and Physical Basic Patient Privacy Consents XDS-MS Medical Documents History and Physical Preprocedure History and Physical Medical Summaries Consent BCCP PHR Extract BCCP PPHP Lab Report Referral Discharge Summary E D E PHR Update XPHR XDS-LAB 2

What do Standards Define? Policy Ø Driven by business goals Ø Informed by Risk What do Standards Define? Policy Ø Driven by business goals Ø Informed by Risk Assessments Ø Defines rights and responsibilities Ø Defines punishment Policy Process Ø Enforces policy Ø How people or organizations act Ø who / what / where / when / how Technology Ø Enforces policy Ø How equipment should act Ø Algorithms and data formats 3

Before One Policy for the Affinity Domain Patient doesn’t agree Don’t publish VIP Patient Before One Policy for the Affinity Domain Patient doesn’t agree Don’t publish VIP Patient Don’t publish Sensitive Data Don’t publish Research Use No Access 4

Basic Patient Privacy Consents Small number of pre-coordinated Affinity Domain Privacy Consent Ø Patient Basic Patient Privacy Consents Small number of pre-coordinated Affinity Domain Privacy Consent Ø Patient can choose which ones to agree to Data is classified and published under the authority of a specific Privacy Consent Data is used in conformance with original Privacy Consent Applicable for XD* mechanism 5

Abstract The Basic Patient Privacy Consents (BPPC) profile provide mechanisms to: ØRecord the patient Abstract The Basic Patient Privacy Consents (BPPC) profile provide mechanisms to: ØRecord the patient privacy consent(s), ØMark documents published to XDS/XDR/XDM with the patient privacy consent(s) that was used to authorize the publication, ØEnforce the privacy consent(s) appropriate to the use. 6

XD* OPTIONS XDS Document Source XDS Document Consumer XDR Document Source XDR Document Recipient XD* OPTIONS XDS Document Source XDS Document Consumer XDR Document Source XDR Document Recipient XDM Document Sources XDM Document Receivers Nothing new for XDS Registry and Repository 7

Key Technical Properties Human Readable Machine Processable Supports standards-based Access Controls Multiple Consent Types Key Technical Properties Human Readable Machine Processable Supports standards-based Access Controls Multiple Consent Types and Documents (e. g. , HIPAA) Ø Ø Ø Opt-in or Opt-out Implicit or Explicit Time Limited Wet Signature Capture (i. e. XDS-SD) Digital Signature Capture Possible (i. e. DSG) Ø Provider, Witness, Patient or Legal Representative Extensible 8

Value Proposition An Affinity Domain (RHIO, HIE) Ø develop a set of privacy policies, Value Proposition An Affinity Domain (RHIO, HIE) Ø develop a set of privacy policies, Ø and implement them with role-based or other access control mechanisms supported by EHR systems. A patient can Ø Be made aware of the privacy policies. Ø Have an opportunity to selectively control access to their healthcare information. 9

Standards and Profiles Used CDA Release 2. 0 XDS Scanned Documents Document Digital Signature Standards and Profiles Used CDA Release 2. 0 XDS Scanned Documents Document Digital Signature Cross Enterprise Document Sharing Cross Enterprise Sharing on Media Cross Enterprise Sharing with Reliable Messaging 10

Informed by Privacy Policy Standards ISO IS 22857 Trans-border Flow of Health Information ISO Informed by Privacy Policy Standards ISO IS 22857 Trans-border Flow of Health Information ISO TS 26000 Privilege Management and Access Control (Parts 1, 2, draft 3) ASTM E 1986 Standard Guide for Information Access Privileges to Health Information 11

Deeper Dive 3/15/2018 12 Deeper Dive 3/15/2018 12

Value Proposition An Affinity Domain (RHIO, HIE) Ø develop a set of privacy policies. Value Proposition An Affinity Domain (RHIO, HIE) Ø develop a set of privacy policies. For Example: • • • No HIE use allowed (e. g. Opt-Out) All clinical use (e. g. Opt-In) Restricted to Assigned Clinician + Emergency Mode Emergency Data Set De-Identified document Ø Each policy is given a number (OID) Ø implement them with role-based or other access control mechanisms supported by EHR systems. 13

Capturing the Patient Consent act One of the Affinity Domain Consent policies CDA document Capturing the Patient Consent act One of the Affinity Domain Consent policies CDA document captures the act of signing Ø Effective time (Start and Sunset) Ø template. ID – BPPC document Ø XDS-SD – Capture of wet signature from paper Ø DSIG – Digital Signature (Patient, Guardian, Clerk, System) XDS Metadata Ø class. Code – BPPC document Ø event. Code. List – the list of the identifiers of the AF policies Ø confidentiality. Code – could mark this document as sensitive 14

Consent document XDS-MS + XDS-BPPC + XDS-SD Structured and Coded CDA Header Patient, Author, Consent document XDS-MS + XDS-BPPC + XDS-SD Structured and Coded CDA Header Patient, Author, Authenticator, Institution, Time of Service, etc. St r u c t u r ed Co n t en t w i t h c o d ed s ec t i o n s : XDS Metadata: Consent Document Digital Signature • Scanned Document details • Privacy Consent details • Policy 9. 8. 7. 6. 5. 4. 3. 2. 1 Base 64 encoded IHE-DSG – Digital Signature value Pointer to Consent document 15

Marking all XDS Documents Use Affinity Domain well formed vocabulary Indicated in XDS Metadata Marking all XDS Documents Use Affinity Domain well formed vocabulary Indicated in XDS Metadata – confidentiality. Code Ø List of appropriate-use consents Ø OR logic Registry rejects non-conformant confidentiality. Codes Affinity Domain Policy must indicate rules for publishing documents with codes for which the patient has not specifically consented to. 16

Using documents XDS Registry Stored Query Transaction Ø Consumer may request documents with specific Using documents XDS Registry Stored Query Transaction Ø Consumer may request documents with specific policies Filtered response XDS Consumer Actor Ø Informed about confidentiality. Codes -- Metadata Ø Knows the user, patient, setting, intention, urgency, etc. Ø Enforces Access Controls (RBAC) according to confidentiality codes Ø No access given to documents marked with unknown confidentiality codes 17

XDR & XDM Same responsibilities Should include copy of relevant Consents Importer needs to XDR & XDM Same responsibilities Should include copy of relevant Consents Importer needs to coerce the confidentiality codes Need to recognize that in transit the document set may have been used in ways inconsistent (e. g. Physical Access Controls) 18

Examples 3/15/2018 19 Examples 3/15/2018 19

Sample: HIMSS Privacy Demo Normal sharing Ø treatment, operations, and billing. Ø The normal Sample: HIMSS Privacy Demo Normal sharing Ø treatment, operations, and billing. Ø The normal sharing policy is implicit and does not need to exist prior to publication of documents Ø OID-A = 1. 3. 6. 1. 4. 1. 21367. 2006. 7. 107 Sensitive topic (e. g. HIV tests, and victims of domestic violence) restricted sharing for treatment operations and billing. Emergency override is allowed in cases with serious threat to patient safety, emergency override audit logging must be done. Ø OID-B = 1. 3. 6. 1. 4. 1. 21367. 2006. 7. 109 Ø Ø Ø 20

Basic Patient Privacy Consents Example RHIO XDS Doc Registry/Repositories Consent A Query Retrieve Register Basic Patient Privacy Consents Example RHIO XDS Doc Registry/Repositories Consent A Query Retrieve Register Consent B Log-in= local role R 3=Consent A&B Register Encounter 1 (Patient Requires A) Encounter 2 (Patient OK with B) Log-in= local role R 1=Consent B 21

Sensitive Document Accessibility Private entries shared with GP Entries restricted to sexual health team Sensitive Document Accessibility Private entries shared with GP Entries restricted to sexual health team Entries accessible to administrative staff Entries accessible to clinical in emergency Entries accessible to direct care teams Entries restricted to health service Source: Dipak Kalra & pr. EN 13606 -4 Private entries shared with several named parties 22

e. Health. Connecticut Policy Agreement Interoperability and Standards Document Map Example: using ISO TS e. Health. Connecticut Policy Agreement Interoperability and Standards Document Map Example: using ISO TS 26000 Health Informatics PMAC- Part 1 Overview and Policy Management 24

e. Health. Connecticut Operational Policies Content Dependent Upon Service Provision Annex A – System e. Health. Connecticut Operational Policies Content Dependent Upon Service Provision Annex A – System Implementation Ø This document describes the system process and testing requirements for RHIO participants both for implementation and routine monitoring. Annex C - Business Continuity & Disaster Recovery Plan Ø This document describes the responsibilities and processes to protect business continuity in the event of system availability issues or failures Annex E – Audit Policy Ø This document describes the audit requirements for RHIO participants including retention times, investigation support, and routine monitoring. Annex F – Archive Policy Ø This document describes archival requirements for RHIO participants. Annex H – Participants Roster 25

e. Health. Connecticut Policy Documents Policy Agreement Ø Legal Umbrella Document Annex B – e. Health. Connecticut Policy Documents Policy Agreement Ø Legal Umbrella Document Annex B – BAA Annex D - Interoperability Policy Ø This document describes the interoperability requirements and specifications including standard content, identification schemes, vocabularies, actors and transactions supported by the RHIO and required of RHIO participants Annex G – RHIO Patient Authorization for Sharing of Health Information Ø This document serves as a common patient authorization for access to and disclosure of health information, and is aligned with system information access management configuration. 26

e. Health. Connecticut Policy for Sensitivity Classification RHIO-wide specification for classification of sensitive data e. Health. Connecticut Policy for Sensitivity Classification RHIO-wide specification for classification of sensitive data CEN/ISO Standards-based Sensitivity What defines Ø Care Management data that is accessible administrative staff Ø Clinical Management data that is accessible to health related professionals Ø Clinical Care data that is accessible to Healthcare professionals Ø Privileged care that is accessible to privileged health professional Ø Personal Care data that is accessible to personal health professionals 27

e. Health. Connecticut Sensitivity classes Care Management Ø Patient admission, clerk, billing Clinical Management e. Health. Connecticut Sensitivity classes Care Management Ø Patient admission, clerk, billing Clinical Management Ø Technicians, lab, Clinical Care Ø Direct and indirect care Privileged Care Ø Mental Health, Substance Abuse, AIDS Personal care Ø Patient directed blocks Functional Role Subject of Care Subject of care agent Personal health professional Ø Named by patient Privileged health professional Ø Role specific Health-related professional Ø technician Administrator Ø clerk 28

e. Health. Connecticut Provide Authorization to Access History Standards-based expression to enable automated processing e. Health. Connecticut Provide Authorization to Access History Standards-based expression to enable automated processing which data – Standards-based Sensitivity Ø Ø Ø Care Management (e. g. administrative staff) Clinical Management (e. g. radiology staff) Clinical Care (e. g. most clinical staff) Privileged care (Mental Health, HIV…) Personal Care (abortion, substance abuse…) to whom – Standards-based Functional Role Ø Ø Ø Ø Subject of Care Agent Personal Healthcare Professional Privileged Healthcare Professional Health-related Professional Administrator for what purpose (HIE Policy is to restrict all use to clinical care purposes) Ø Ø At the request of the individual (no purpose need be specified) Insurance Eligibility/Benefits __ Marketing Additional Medical Care __ Research Teaching 29

Consent Matrix Care Mgmt Clinical Privileged Personal Mgmt Care Subject of Care Yes Yes Consent Matrix Care Mgmt Clinical Privileged Personal Mgmt Care Subject of Care Yes Yes Yes Subject of Care Agent Yes Yes Yes Personal Health Professional Yes Yes Yes Privileged Health Prof Yes Yes Yes Health Prof Yes Yes Special Health-Related Prof Yes Yes Special No Administrator Yes Special No No 30

e. Health. Connecticut Treatment allowed uses are enforced through typical role-based-access referencing functional role e. Health. Connecticut Treatment allowed uses are enforced through typical role-based-access referencing functional role A Policy Table shows allowed use between sensitivity classes vs functional role Some table entries include special behaviors • Healthcare Professional needs to get a consent-to -disclose on each publication and/or use of Privileged Care and Personal Care sensitivity classes • Personal care sensitivity class data when accessed by a healthcare professional requires the review the patient’s published consent. 31

Active Consents Centric All clinical documents are published with subset of confidentiality codes, indicating Active Consents Centric All clinical documents are published with subset of confidentiality codes, indicating the type of data only, not the status of consent at the moment. Consent acts are captured and managed as indicated. Including replacement, and time constraints On USE, the Document Consumer is responsible for pulling down all current consent document, and treating the clinical documents according to current consent documents 32

Not currently available Lab results that shouldn’t be disclosed to the patient until they Not currently available Lab results that shouldn’t be disclosed to the patient until they are consulted to by their GP. Ø Could be supported with xds-metadata change transaction Patient block for specified individual Ø Could be through required viewing by the human user of current patient consent policy, with human enforcement Ø Future policies may be machine processable Patient authorization of specified agent Ø Could be through required viewing by the human user of current patient consent policy, with human enforcement Ø Future policies may be machine processable 33

Questions? 3/15/2018 34 Questions? 3/15/2018 34