26
Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE IT Infrastructure Committee Blog – http://healthcareSecPrivacy.blogspot.com October 20, 2010

Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

Embed Size (px)

Citation preview

Page 1: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

Consumer Privacyusing HITSP TP30

John Moehrke – GE Healthcare• Co-Chair HITSP Security/Privacy/Infrastructure • Co-Chair HL7 Security Workgroup• Member IHE IT Infrastructure Committee• Blog – http://healthcareSecPrivacy.blogspot.com

October 20, 2010

Page 2: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

Focus

• Electronic standards for privacy, not so much security

• Interoperability between systems, not so much within internal systems

• Applicability to EHRs, PHRs and HIEs• Capabilities to capture, exchange and execute privacy

consents, authorizations, directives and preferences

2

Page 3: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

Basic Concepts• What is Privacy (of health information)?

– An individual's (or organization's) right to determine whether,

what, when, by whom and for what purpose their personal

health information is collected, accessed, used or disclosed

• What is Security (of health information)?– A defined set of administrative, physical and technical actions

used or taken to protect the confidentiality, availability and

integrity of health information

Source: HITSP Vocabulary – modified and expanded from 45 CFR 164.304

Page 4: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

Privacy of Health Information – Important Underlying Realities

• Medical records among the most sensitive information about a person

• Health care is an information-driven field• Information is much more complex than other

industries (amount, type, frequency)• Once exposed, can’t be revoked

Health information is central to the doctor-patient relationship

Privacy and security of health information are central to the doctor-patient relationship

Page 5: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

• Health care is a complex system, when it comes to health information– Many actors (patient, provider, health plan,

employer, government, public health, researchers, vendor, etc)

– Various types of information (demographic, clinical, financial)

– Many processes related to health information (collection, creation, maintenance, access, use, disclosure)

– Different purposes (treatment, payment, operations, public health, research, judicial, legal, etc)

– Many places where health information reside– Lack of common identifiers and other standards

Privacy of Health Information – Important Underlying Realities

Page 6: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

• Inter-jurisdictional Portability

– Consumer privacy consent laws and requirements, and consumer privacy desires and directives in one jurisdiction may not be legally applicable/enforceable in another jurisdiction

• An entity operating in one jurisdiction uses and discloses health information based on its own policies and procedures, created to meet consent requirements under that jurisdiction

• When information is disclosed to a different entity in another jurisdiction, the receiving entity applies its own policies and procedures to the received data, which where created to meet consent requirements under the receiving entity’s jurisdiction

Privacy of Health Information – Portability Issues

Page 7: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

• Cross-validation and verification of conflicting consents

– What is the most recent/latest consent from a patient?

– Does that override other consents for specific data, specific purpose?

– Where can I find the various consents issued by a consumer to perform cross-validation and verification?

Privacy of Health Information – Cross-validation Issue

Page 8: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

• A Consent Directive is a record of a consumer’s privacy policy, in accordance with governing jurisdictional and organization privacy policies, that grant or withhold consent:– To one or more identified entities in a defined role – To perform one or more operations (e.g., collect, access, use, disclose,

amend, or delete)– On an instance or type of health information– For a general or specific purpose, such as treatment, payment, operations,

research, public health, quality measures, health status evaluation by third parties, or marketing

– Under certain conditions (e.g., when unconscious)– For specified time period (e.g. effective and expiration dates)– In certain context (e.g., in an emergency)

Electronic Standards for Consumer Consent– What are Privacy Consent Directives?

Page 9: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

9

Most consumer privacy consent/authorization still conducted via paper forms General consumer privacy consent

offered at initial point of care/enrollment (when required)

Additional patient consent/authorization used for specific types of health information, specific disclosure purposes (when required)

No standard paper consent forms within a jurisdiction (national, state)

Each organization/program has its own forms

Some States beginning to establish a standard ‘reference’ form (i.e. MN)

Consent/Authorization – Current Practices

Page 10: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

10

EHRs Specific screens and ‘forms’ used within the EHR to capture

various consumer consents Informed consent (for treatment) Release of Information Authorization (i.e., payment purposes) Authorization for other disclosures, when required

Some data ‘flagged’ by EHR due to sensitivity Defined by organization and customized by vendor Based on specific laws that afford special protections to certain data

Consumer signature captured via digital pad or through consumer acknowledgment (“…click here to accept…”)

Consent/Authorization – Current Practices

Page 11: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

11

PHRs (vendor-provided) Consumer controls all information added

to the PHR, accessed or disclosed “EULA” or “Agree to Terms” screen Additional authorizations used for

specific disclosures

HIEs Opt-in / Opt-out approach

General Opt-out General Opt-in (all-or-nothing) Opt-in with Specific Restrictions

Consent/Authorization – Current Practices

Page 12: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

12

Offer consumers and the health care industry

an interoperable, standard-based electronic mechanism to

collect/capture, maintain, report/ transfer/exchange and

act/execute consumer consent directives and preferences, in a

manner that allow users to meet different types of jurisdictional

requirements and organizational policies

Electronic Standards for Consumer Consent A New Paradigm

Page 13: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

13

Consumer-friendly mechanism To allow consumer to manage their consent preferences and

directives electronically in a simple, reliable, secure, efficient and effective manner

Scalable Allow to go from General (overall opt-in/opt-out) to Granular (specific

data, specific people, specific people)

Codifiable Uses standard codes to express consent directives

Machine-readable/Machine-actionable Does not require human intervention to process Allow systems to operationalize access, use and disclosure controls

Electronic Standards for Consumer Consent– Key Characteristics

Page 14: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

14

Portable/Transferable/Interoperable Uses interoperable standards that allow it to be electronically

ported/transferred between organizations and across jurisdictions

Flexible/Adaptable Supports different jurisdictional requirements Features can be ‘turn-on’ or ‘turn-off’ based on differing

levels of requirements and organizational policies

Valid/Verifiable/Auditable Supports digital signature, non-repudiation, audit controls

Unambiguous/Completeness Conflicts between directives can be identified and resolved

Electronic Standards for Consumer Consent– Key Characteristics

Page 15: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

15

From Privacy Consent to Comprehensive Consent Management

Consent/Authorization

Consumer Privacy Preferences

Consent Directives

Access Control Policies

Consent Management System

Page 16: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

Interoperability – The Focus of HITSP

Internal SecurityPolicies, Procedures

and Practices

Secure System Architecture

Internal SecurityPolicies, Procedures

and Practices

Secure System Architecture

Inter-organizationalExchange

Security Privacy

Infrastructure

Intra-organizationalSecurity, Privacy, Infrastructure

Intra-organizationalSecurity, Privacy, Infrastructure

Page 17: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

17

Integrating the Healthcare Enterprise, a world-wide consortium of vendors and health care organizations (www.ihe.net)

Developed the BPPC Profile = Basic Patient Privacy Consent Most widely recognized standard ‘profile’ for capturing and

sharing privacy preferences within an affinity domain (i.e., an HIE) Provides the mechanism to:

Record the patient privacy consents Mark documents with the patient privacy consent Enforce the privacy consent appropriate to the use

Leverages the same Transport mechanism as the Clinical Documents

IHE

Page 18: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

18

BPPC uses Object Identifiers (OIDs) to codify the privacy preferences within an affinity domain (i.e., HIE)

The affinity domain (exchange) defines the consent policies and each is identified with an OID

Organizations within the affinity domain offer the consent policy options to consumers

Consumers makes privacy preferences based on consent policies offered

Consumer Consent Acknowledgement is captured in a CDA document (the BPPC profile) and published like any other HIE document

IHE - How BPPC works:

Page 19: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

19

Opt-In to clinical use Opt-Out of sharing outside of local event use, allowing emergency override Opt-Out of sharing outside of local event use, without emergency override Specific document is marked as available in emergency situations Additionally allow specific research project Additionally allow specific documents to be used for specific research

projects Limit access to functional roles (eg: healthcare) (direct care) providers Limit access to structural roles (eg: organizational) (radiologist, cardiologist) Allow direct use of the document, but not allowed to re-publish when the document is published on media when the document is published point-to-point when the document is retrieved across communities individual policy for opt-in at each clinic individual policy for opt-in for a PHR choice (choosing from all possible PHRs)

IHE - Types of Policies Supported

Page 20: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

Written Policy Example

20

The patient agrees to share their healthcare data to be accessed only by doctors wearing a chicken costume.

Page 21: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

Basic Patient Privacy Consents• 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

Page 22: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

• Scanned Document details• Privacy Consent details

• Policy 9.8.7.6.5.4.3.2.1

SSttrruuccttuurreedd CCoonntteenntt wwii tthh ccooddeedd sseecctt iioonnss::

Structured and Coded CDA Header

Time of Service, etc.

Base64 encoded

BPPC + XDS-SD

Patient, Author, Authenticator, Institution,

XDS Metadata:

Consent DocumentDigital Signature

IHE-DSG – Digital SignatureSignature valuePointer to Consent document

Consent document

Page 23: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

23

All Clinical Documents are Published with Metadata sensitivity classification (aka ConfidentialityCode)

All Users identified with Roles Access Permissions Users can be clinical, financial, operational, research, patient, guardian,

etc (See IHE XUA)

When a User requests access to a resource an Access Control decision YES/NO User Rights, Physical Location Purpose of Use, Data sensitivity classification Current Consent/Authorizations

Enforcing Policy (aka HITSP TP20)

Page 24: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

24

Access Control: UML Activity Diagram

Page 25: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

Patient ID Manager

Document Registry

Document Repository

HIE

Complex Patient Privacy Policy Enforcement

PCP gets HIV History

PCP Security Domain 1

3.

Submits psychiatristReferral

4.

Mental Specialist Security Domain 2

Specialistgets allHistory5.

SpecialistsubmitsrestrictedMental Eval

6.

PCP does notget restrictedMental Eval

7.

Emergencycare teamgets all doc

Hospital Emergency Security Domain 4

9.

DieticianSpecialist Security Domain 3

8.

Dietician does not get HIV results or Mental Eval

Lab TestSecurity Domain 1

Lab publishesHIV Results

2.

1.PatientSecurity Domain 1

PatientHIE ConsentOpt-in

Page 26: Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE

HHS Whitepaper on Consent (March 2010)

• No consent. Health information of patients is automatically included—patients cannot opt out;

• Opt-out. Default is for health information of patients to be included automatically, but the patient can opt out completely;

• Opt-out with exceptions. Default is for health information of patients to be included, but the patient can opt out completely or allow only select data to be included;

• Opt-in. Default is that no patient health information is included; patients must actively express consent to be included, but if they do so then their information must be all in or all out; and

• Opt-in with restrictions. Default is that no patient health information is made available, but the patient may allow a subset of select data to be included.

26