Health Information Protection Taskforce of the State Alliance for e-Health Monthly Conference Meeting April 25-26, 2007

Health Information Protection Taskforce of the State Alliance for e-Health

Monthly Conference Meeting

April 25-26, 2007

2

Revised Work Product

Health Information Protection Taskforce Work Product(accepted by the Taskforce on February 23, 2007; accepted by the State Alliance on March 30, 2007)

(1) Conduct an analysis that:

a) examines the rationale behind the major state health privacy protection laws that affect the sharing of health information across entities (whether paper-based or electronic);

b) discusses the applicability of each kind of protection, with an emphasis on an individual’s health in an electronic HIE environment; and

c) provides recommendations for addressing issues arising from such protections.



April 25-26, 2007

Privacy and Security Solutions for Interoperable Health Information Exchange

Presented byDr. Linda L. Dimitropoulos

RTI International

Presented atMonthly Meeting of the Health Information Protection Task Force

State Alliance for eHealthApril 25, 2007

RTI International is a trade name of Research Triangle Institute

230 W. Monroe ■ Suite 2100 ■ Chicago, IL 60606Phone 312-456-5246 E-mail [email protected] 312-456-5250

5

Background

Variation in privacy and security business practices and policies creates a barrier to electronic clinical health information exchange

The existing paradigm for privacy and security protections does not fully accommodate active consumer participation in health information exchange

Consumers, organizations, and state and federal entities share concerns related to maintaining the privacy and security of health information

6

Assumptions

Decisions about how to protect the privacy and security of health information should be made at the local community level

Discussions need to take place to develop an understanding of the current landscape and the variation that exists between organizations within each state, and ultimately across nation

Stakeholders at the state and community levels, including patients and consumers, must be involved in identifying the challenges and developing solutions to achieve broad-based acceptance

7

Project Tasks

Identify the variation in organization-level business practices, policies, and state laws that creates barriers to eHIE Identify practices and policies that serve as “checkpoints” Document the rationale or “driver” behind the practice or policy

Develop solutions Incorporate the “good” practices and policies into proposed

solutions Work with stakeholders toward consensus-based solutions to

harmonize the variation and create appropriate protections

Develop a plan to implement the solutions

8

Project Outcomes

Preserve privacy and security protections in a manner consistent with interoperable electronic health information exchange

Incorporate state and community interests, and promote stakeholder identification of practical solutions and implementation strategies through an open and transparent consensus-building process

Leave behind in states and communities a knowledge base about privacy and security issues in electronic health information exchange that endures to inform future HIE activities

9

Sources of Variation

Variation Related to Misunderstandings and Differing Applications of Federal Laws and Regulations HIPAA Privacy Rule

Patient Authorization/Consent Variation in Determining “Minimum Necessary”

HIPAA Security Rule Confusion regarding the different types of security required Misunderstandings regarding what was currently technically

available and scalable CFR 42 part 2

Variation in the treatment facilities’, physicians’, and integrated delivery systems’ understanding of 42 CFR pt. 2, its relation to HIPAA, and the application of each regulation

10

Sources of Variation (continued)

Variation Related to State Privacy Laws Scattered throughout many chapters of law When found, it is often conflicting Antiquated—written for a paper-based system

Trust in Security Organizations Consumers/patients

Cultural and Business Issues Concern about liability for incidental or inappropriate

disclosures General resistance to change

11


Variability in the use and implementation of patient consent or authorization across organizations Lack of understanding about when federal and state laws

require patient consent Lack of a standardized requirement for when to use patient

consent Lack of a standard form to be used in connection with patient

consent and authorization

12


Variability in the interpretation and application of the “Minimum Necessary” standard Widespread belief that it applies to disclosures to providers

for treatment purposes Lack of models and best practices for applying “Minimum

Necessary” in all other non-treatment-related disclosures Increases the time required for the exchange and affects the

ability to receive comprehensive records

13


Lack of a standard, reliable way of accurately matching records to patients

Lack of standard authentication and authorization protocols

Inability to appropriately segregate data poses a challenge to appropriate role-based access

Current lack of auditing capability because of technical inadequacies and nonexistent or poor audit programs

14

Moving Forward

Proposed Solutions Fall into 5 CategoriesLeadership and GovernancePractice and PolicyLegal and RegulatoryTechnology and Data StandardsEducation and Outreach

15

Implementing Solutions

Within each project teamClarify Assumptions and Define Core Principles Identify Measurable Goals and OutcomesDefine “critical path” activitiesDefine Milestones and Action Steps

Across teamsCreate communication channels and coordinate

work to prevent duplication of effort

16

Timelines

Final Reports due to AHRQ and ONC

May 15Assessment of Variation and Analysis of Solutions Implementation Plan

June 30 Nationwide Summary

17

Thank You

http://Healthit.ahrq.gov/privacyandsecurity

www.rti.org\hispc

http://healthit.ahrq.gov/privacyandsecurity

http://www.rti.org/hispc



April 25-26, 2007

Is HIPAA Preemption a Legal Barrier to Health Information Transparency and

Interoperability?

Professor Phyllis C. Borzi, J.D., M.A.

The George Washington University

School of Public Health and Health Services

Department of Health Policy

20

Background for Study

• Concern was expressed to and by policymakers that the HIPAA preemption rule allowing application of more strict state laws was a legal barrier to creation of interoperable health information systems and reporting of transparent data

• We were asked to undertake a judicial review of current cases to examine this question

21

Why Focus on Judicial Opinions?

– One source of evidence as to the existence of a problem

– Evidence as to how the health care system understands the sources of power and legal constraints within which it operates

22

Methodology

• Systematic review of all reported federal and state cases decided between 1996 and 2006 in which HIPAA was mentioned (479 cases; after elimination of duplicate cases involving appeals, 446 cases)

• Each case was initially examined and categorized based on:– Parties and nature of underlying dispute– Whether the dispute involved HIPAA preemption

• If so, whether the court was required to determine if state law was “contrary to” or “more stringent than” HIPAA to decide the case

• Analysis then focused on latter group of cases in which there was an allegation of conflict between HIPAA and state law (113 cases)

• Tabulation of results in these 113 cases by case domain, underlying claim, type of information sought, types of entities involved, result (e.g., HIPAA governed; state law governed; both governed because no conflict)

23

Key Findings

• To date, no HIPAA cases involve state law barriers to access to PHI for treatment, payment, patient safety or quality

• Underlying conflicts generally involve the disclosure of PHI as part of the legal process, rather than use of the information to improve , reduce disparities or create transparency

• No evidence in the cases that HIPAA preemption poses a barrier to HIT interoperability

24

Overwhelming Number of HIPAA Preemption Cases Involve State Legal

Process DisputesPrincipal HIPAA Privacy Rule Case Domains

Total Number of Cases = 113

Source: GW HIPAA Case Law Database, 11/21/06

Access to Health Information as Part of the Legal Process

96 Cases 85%

Other

17 Cases

15%

Principal HIPAA Privacy Rule Case Domains


Source: GW HIPAA Case Law Database, 11/21/06

Access to Health Information as Part of the Legal Process

96 Cases 85%

Other

17 Cases

15%

25

Context of Disputes

• The cases typically involve state laws that govern what information can be used in a pre-trial or trial proceeding

• The legal question involves access to PHI in– court-supervised discovery in lawsuits between private litigants– government or insurance investigations

• Courts have concluded that HIPAA is procedural in nature and does not create new substantive federal rights (e.g., new physician/patient privilege)

– HIPAA establishes procedural steps that covered entities must follow in order to use/disclose PHI or, more typically, to justify withholding PHI from requester

• Cases illustrate the flexibility that covered entities have to determine whether and under what circumstances they will disclose

• No instances in which a more stringent state law blocks provider disclosure for patient care purposes

26

Types of Entities Involved in Dispute Over PHI

State Agency

(9)N/A(7)

Employer(6)

Hospital(27)

Insurance Company

(5)Provider(58)

Bank(1)


GW HIPAA Case Law Database, 11/21/06

27

Types of Underlying Claims

Types of Underlying Claims in Relevant HIPAA Privacy Rule Cases

Other Negligence (12)

Medical Malpractice (29)Medicaid Reimbursement (1)

Criminal Indictment (1)

Child Pornography (1)

Intentional Tort (1)

Products Liability (5)

Public Information Request (5)

Probate (3)

Insurance (8)

Fraud (9)

DUI (8)Divorce (1)

Constitutional (12)

Child Custody (7)

Bankruptcy (1)

Wrongful Death (3)

Discrimination (6)

SOURCE: GWU-DHP HIPAA Case Law Database, 11/21/06Total Number of Cases = 113

Types of Underlying Claims in Relevant HIPAA Privacy Rule Cases

Other Negligence (12)

Medical Malpractice (29)Medicaid Reimbursement (1)

Criminal Indictment (1)

Child Pornography (1)

Intentional Tort (1)

Products Liability (5)

Public Information Request (5)

Probate (3)

Insurance (8)

Fraud (9)

DUI (8)Divorce (1)

Constitutional (12)

Child Custody (7)

Bankruptcy (1)

Wrongful Death (3)

Discrimination (6)

SOURCE: GWU-DHP HIPAA Case Law Database, 11/21/06Total Number of Cases = 113

28

Types of Claims, cont.

• The most common scenario involves a health care provider attempting to either shield PHI from disclosure to a patient or third party or obtain it for defensive purposes in a liability action– Depending on the facts and the nature of the

dispute, the same type of entity might attempt to seek or deter disclosure

– HIPAA is used as both a sword and a shield

29

Nature of PHI Dispute

N/A(7)

Withold(62)

Disclose(20)

Obtain(24)


GW HIPAA Case Law Database, 11/21/06

30

Role of Covered Entities

• Although they may not always be litigants, covered entities are always involved in the dispute, since typically they are the holders of PHI at issue

• Three basic questions confront the covered entity:– Must the PHI be disclosed?– May the PHI be disclosed?– Is the disclosure prohibited?

31

What are the Courts Doing to Resolve Potential Disputes over PHI?

• Clear trend in cases: reconciliation of state and federal law to avoid the type of conflicts that would unduly burden data exchange

• Courts nearly always find a way to allow the covered entity to comply with both HIPAA and state law

• Court decisions frequently focus not on whether disclosure can be made, but on terms and conditions of disclosure, permissible purposes and uses, and extent of disclosure required– Few cases in which disclosure barred per se.

•

32

Resolution of Disputes, cont.

• How do the courts avoid conflicts between HIPAA and state law?– Pathway to reconciliation: discretionary power of

covered entities to disclose information under HIPAA so no HIPAA bar to complying with state laws

• Many disclosures are “permitted” under HIPAA; very few are required or prohibited

• Most confusing category of permitted disclosures: those that are required under state law (36/113 cases)

• Covered entity is “permitted” to comply with requirements of state laws

33

Conclusions

• No evidence in case law that HIPAA or state privacy laws are barriers to disclosure of PHI for:– treatment– creation of transparent interoperable HIT systems,

or – using aggregated and/or de-identified PHI for

patient safety, improving quality or reducing disparities

• Vast majority of cases focus on use of PHI in legal process itself

34

Conclusions, cont.

• Clear desire of courts to reconcile state disclosure laws with HIPAA and to avoid conflicts– Generally disclosure sought is permitted by HIPAA– Therefore covered entities can comply with state law if they

want to

• Covered entities can minimize problems by adopting clear and detailed privacy policies thus substituting their uniform policies for varying state laws

• Courts have concluded that HIPAA creates no new substantive rights but rather establishes a process for managing and disclosing PHI

35

Policy Implications

• If Congress were to expand HIPAA preemption and substitute uniform federal standards for more stringent state laws, the most serious and potentially disruptive impact would be on state legal process

• It is unclear that creating a federal ceiling as well as floor through HIPAA would improve legal certainty and reduce litigation– Traditional “field preemption” still ambiguous

• “relate to” health information privacy/health information systems• “in connection with” privacy, confidentiality, security of PHI

• Perhaps the bigger challenge is reconciling HIPAA with other federal laws (e.g., Medicaid, Medicare, privacy standards for federally funded alcohol and substance abuse treatment programs)



April 25-26, 2007

Health Information Protection Taskforce Activities to Date

38

Our Charge

Support the State Alliance for e-Health on issues regarding the protection of consumer health information that ensures appropriate interoperable, electronic health information exchange (HIE) within states and across states; and develop and advance actionable policy statements, resolutions, and recommendations for referral to the State Alliance on these issues.

39

Revised Work Product

Health Information Protection Taskforce Work Product(accepted by the Taskforce on February 23, 2007; accepted by the State Alliance on March 30, 2007)

(1) Conduct an analysis that:

a) examines the rationale behind the major state health privacy protection laws that affect the sharing of health information across entities (whether paper-based or electronic);

b) discusses the applicability of each kind of protection, with an emphasis on an individual’s health in an electronic HIE environment; and

c) provides recommendations for addressing issues arising from such protections.

40

Approach to Work Product

Pre-work product activities (March/April 2007):

1. Determine categories of major state health privacy protection laws to be considered (completed)

2. Develop privacy principles to use as a metric in conducting analysis

Gain an understanding of the benefits to an individual’s health from electronic exchange of health information

Gain an understanding of privacy benefits and risks/gaps in the electronic exchange of health information

3. Identify examples from 3-4 states of representative laws in each of the identified categories

41


Phase I: Examine rationale behind major state health privacy protection laws (May 2007)

1. Identify rationale behind each of the representative laws or categories of laws (gather state perspectives, both historical and current)

42


Phase II: Determine the applicability of each kind of protection, with an emphasis on an individual’s health in an electronic HIE environment (June 2007)

1. Determine if the rationale behind each category of state health privacy laws is still relevant today and relevant to the electronic exchange of health information, with an emphasis on an individual’s health

43

In Determining Applicability…

• Develop or adopt a set of privacy principles to use as a metric to assess the applicability of the major state health privacy laws specific to the exchange of specially protected health information for the purposes of treatment in an electronic HIE environment.

• Build on existing privacy principles.

44


Phase III: Provide recommendations to the State Alliance (July 2007)

1. Determine which categories of laws are still relevant in an electronic environment and frame recommendations to states (through the State Alliance) on how they can evaluate existing state law protections

in the context of an electronic environment

45


Post-work product activities:

(August-September 2007)

1. Create resources for states to support implementation of each recommendation. Resources could include:

a. Example situations (e.g., vignettes)

b. Model laws

c. Tool kits

46

Identified Categories of Major Health Privacy Protection Laws

Types of Information

• Mental health and substance use

• HIV and other communicable diseases

• Genetic information

• Disability

Uses of Information

• Treatment

• Payment

• Health care operations

• Public health

• Clinical research

• First response to emergencies

Access by Whom to Information

• Individual’s access to information about them

• Provider (physicians and hospitals) access to patient information

• Personal representatives access to patient information (i.e., minors and incapacitated adults)

47

Focus Area Considerations

Under existing state privacy laws:

• What does the law say about … Who has the permission to access? How is access authorized?

• What was the underlying rationale for the legal requirement?

• Is the rationale applicable in electronic exchange environment?

• If it is and the legal requirement is also applicable, are there technical solutions that can facilitate exchange while ensuring protections are in place?

• If the rationale is no longer applicable, should (and can) the legal requirement be modified? If so, what are the steps to modify the law? (i.e., model law)

• If the legal requirement cannot be modified, what other kinds of tools and resources can the Taskforce provide to help the states?

48

Parking Lot Issues

• Provider liability

• Enforcement

• Choice of law

49

Possible Taskforce Outcomes

• Work product report Recommendations on how states can address privacy and

security challenges to electronic health information exchange

• Privacy framework/principles

• Tool kit

• Model law

• Vignettes



April 25-26, 2007

April 25, 2007

HITSP Security and Privacy Johnathan Coleman, CISM, CISSPPrincipal, Security Risk Solutions, Inc.HITSP Security and Privacy Technical Committee Facilitator

52Evaluation of Standards Harmonization Process for HIT

Agenda

1. Relationship between HITSP, HISPC and CCHIT2. HITSP Charter and Goals 3. Harmonization Process 4. Current Status of HITSP Security and Privacy Activities5. HITSP Security and Privacy Constructs under Consideration6. HITSP Contact Information


A public-private “Community” was then established to serve as the focal point for America’s health information concerns and drive opportunities for increasing interoperability

Healthcare Information Technology

Standards Panel (HITSP)

Nationwide Health

Information Network

Architecture Projects (NHIN)

The Health Information Security and

Privacy Collaboration

(HISPC)

The Certification Commission for

Healthcare Information Technology

(CCHIT)

American Health

Information Community

The Community is a federally-chartered commission and will provide input and

recommendations to HHS on how to make health records digital and interoperable, and assure that the privacy and security of those records are protected, in a smooth, market-

led way.

The Community is a federally-chartered commission and will provide input and

recommendations to HHS on how to make health records digital and interoperable, and assure that the privacy and security of those records are protected, in a smooth, market-

led way.

HITSP includes 348 different member organizations and is administered by

a Board of Directors24 SDOs (7%)

247 Non-SDOs (71%) 30 Govt. bodies (9%)

12 Consumer groups (3%)36 Project Team and Undeclared (10%)

HITSP includes 348 different member organizations and is administered by

a Board of Directors24 SDOs (7%)

247 Non-SDOs (71%) 30 Govt. bodies (9%)

12 Consumer groups (3%)36 Project Team and Undeclared (10%)


The HITSP team is charged with completing eleven different tasks, with current efforts focused on the harmonization process

The CommunityHHS Secretary

Mike Leavitt, Chair

Project Management TeamExecutive in Charge, F. Schrotter, ANSI

Program Manager, L. Jones GSIDeputy PM, J Corley, ATI

Project Manager, Julie Pooley, Booz Allen

Project Management TeamExecutive in Charge, F. Schrotter, ANSI

Program Manager, L. Jones GSIDeputy PM, J Corley, ATI

Project Manager, Julie Pooley, Booz Allen

Harmonization Process Delivery

Technical Manager

Joyce Sensmeier, HIMSS

Harmonization Process Delivery

Technical Manager

Joyce Sensmeier, HIMSS

Harmonization Process Definition

Technical Manager

Michelle Deane, ANSI

Harmonization Process Definition

Technical Manager

Michelle Deane, ANSI

HHS ONCHIT1 PO, Dr. John Loonsk

HHS ONCHIT1 PO, Dr. John Loonsk HITSP

Dr. John Halamka, ChairMember populated

Technical Committees

Eleven Tasks are included in this contract:

1. Comprehensive Work Plan

2. Conduct a Project Start Up Meeting

3. Deliver Recommended Use-Cases

4. Participate in related meetings and activities, including the AHIC Meetings

5. Develop a Gap Analysis

6. Standards Selection, Evaluations and Testing

7. Define a Harmonization Approach

8. Develop Interoperability Specifications

9. Develop and Evaluate a Business Plan for the self-sustaining processes

10. Submit Monthly Reports – ongoing efforts

11. Assist with communications – ongoing efforts


HITSP formed Technical Committees to focus on AHIC breakthrough areas - Initial focus is on 3 use cases

Biosurveillance -- Transmit essential ambulatory care and emergency department visit, utilization, and lab result data from electronically enabled health care delivery and public health systems in standardized and anonymized format to authorized public health agencies with less than one day lag time.

Consumer Empowerment -- Deploy to targeted populations a pre-populated, consumer-directed and secure electronic registration summary. Deploy a widely available pre-populated medication history linked to the registration summary.

Electronic Health Records -- Deploy standardized, widely available, secure solutions for accessing laboratory results and interpretations in a patient-centric manner for clinical care by authorized parties.

Security and Privacy – Initially a formed as a Work Group to address Security and Privacy (S & P) requirements of the first three Use Cases. Now a Technical Committee charged with addressing S & P requirements for all Use Cases provided to HITSP.


HITSP Coordinating Committees and Leadership

Foundations Committee – Steve Wagner– Bob Dolin

HITSP Process Review Committee– Lynne Gilbertson– Erik Pupo

HITSP-CCHIT Joint Work Group– Jamie Ferguson, Kaiser Permanente

Harmonization Readiness Committee– Lynne Gilbertson

Business Plan Committee– Steve Lieber

International Landscape Committee– Bill Braithwaite

Governance Committee– Michael Aisenberg

HITSP Technical Committee - Care Delivery– James Ferguson, Kaiser Permanente– Steve Hufnagel, DoD– Steve Wagner, Department of Veterans Affairs

HITSP Technical Committee - Consumer Empowerment– Elaine Blechman, PhD, University of Colorado,

Boulder– Charles Parisot, GE Healthcare– Scott Robertson, Kaiser Permanente

HITSP Technical Committee- Population Health– Floyd Eisenberg, MD, MPH, Siemens Medical

Solutions– Peter Elkin, MD, Mayo Clinic College of Medicine– Shaun Grannis, Department of Family Medicine,

Indiana University School of Medicine

HITSP Technical Committee- Security and Privacy – Cochair nominations in progress

HITSP Technical Committees and Leadership


I

Harmonization Request

Harmonization Process Steps

II

RequirementsAnalysis

III

Identificationof Candidate

Standards

IV

Gaps,Duplications

and Overlaps

Resolution

V

Standards Selection

VI

Constructionof

InteroperabilitySpecification

VII

InspectionTest

VIII

InteroperabilitySpecification

Releaseand

Dissemination

IXProgram Management

BeginSupport

ReceiveRequest

The actual harmonization process is a series of steps taken by industry stakeholders within the context of HITSP


HITSP Security and Privacy Goals/Charter

Harmonize HITSP standards for EHR-Lab reporting, Population Health and Consumer Empowerment with relevant Security and Privacy standards.

Convene regular meetings with adequate representation from each TC to review current Interoperability Specifications and identify areas of Security and Privacy that were previously deferred.

– This will be expanded to include Security and Privacy requirements from the ER-EHR Use Case and other new Use Cases provided to HITSP

Begin work on identifying security standards, approaches, and identifying unresolved issues. Leverage activities of other Security and Privacy related workgroups.

– The purpose of the HITSP SPWG/TC is to ensure that technical standards to address privacy and security needs are identified and harmonized. We will rely on both the HISPC project and the State Alliance for e-Health to inform our work surrounding policy and regulatory considerations.


Current Status of HITSP Security and Privacy Activities Review Use Cases and identify Security and Privacy Requirements. This will serve to

populate the Requirements sections of the Requirements, Design and Standards Selection (RDSS) document. Completed

Identify candidate standards (from our Inventory of Standards and other sources), and sort them into buckets which correspond to the security and privacy requirements (potential HITSP constructs). Completed

Develop Requirements, Design, Standards Selection (RDSS) document Completed

– Technical Actors, Business Actors & mappings from use cases

– UML diagrams (initially a high level relationship roadmap)

– Identify Security and Privacy Requirements and map to use cases

– Public Comment Period: 05/16 – 06/14

Apply Tier 2 criteria to select from the existing standards for each of our potential constructs. Current Activity

Develop HITSP Security and Privacy Constructs which will frame implementation of the selected standards to achieve the requirements as identified in the Use Cases. Current Activity

Inspection Test and Public Comment: 07/20 – 08/16

Comment Resolution and Panel Approval: 08/17 – 10/15


JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC

HITSP 2007 Timeline

02/05/07HITSP Board

04/23/07HITSP Board

07/09/07HITSP Board

10/09/07HITSP Board

03/19/07HITSP Panel

05/11/07HITSP Panel

09/07/07HITSP Panel

03/06 – 03/08TC Face to Face

Chicago IL


Arlington VA


San Diego CA


Arlington VA

Public Comment

Inspect Test and Public Comment

Implementation Support and Testing

(with annual updates as required)

Comment Resolution and Panel Approval

02/15 – 05/16

04/13 – 05/16

IS Construct Development

05/17 – 07/19 07/20 – 08/16 08/17 – 10/15

Implementation Support and Testing(includes minor document updates)

EHR, CE and BIO v 2.0

Activity 1 – Version 2.0 of Existing EHR, CE, BIO ISs

Activity 2 – Security and Privacy for All Use CasesActivity 3 – New Emergency Responder EHR Use Case

On-going Support

10/15/07HITSP Panel

07/16/07HITSP Panel

02/12/07HITSP Panel

Activity 4 –New Use Cases from AHIC

Detail Schedule to be Established Upon Review of the Use Cases

Work Plan and Schedule Overview

S&P and EHR-ER v 1.0

Requirements, Design, Standards Selection

Public Input on S&P

05/17 – 06/14


HITSP Security and Privacy Constructs under Consideration

1. Secured Communication Channel (includes mutual node authentication, integrity and confidentiality of transmission contents)

2. Collect and Communicate Security Audit Trail

3. Privacy Consents

4. Verify Privacy Consents

5. Manage Entity Identity Credentials

6. Document Integrity

7. Authenticate User

8. Manage and Control Data Access

9. Non Repudiation

10. Fail-Safe/Emergency access (now rolled into #4 and #8)

11. Consistent Time


HITSP Security and Privacy Constructs under Consideration


Questions

For General Technical Committee related questions please contact: Joyce Sensmeier MS, RN-BC, CPHIMS, FHIMSS

Vice President, Informatics HIMSS 230 East Ohio, Suite 500 Chicago, IL 60611-3269 Phone: 312-915-9281 email: [email protected]

Or

Jessica KantCoordinator, Standards HarmonizationHealthcare Information & Management Systems Society230 E. Ohio St., Suite 500Chicago, IL 60611Phone: 312-915-9283 Fax: 312-915-9511 email: [email protected]

For HITSP Security and Privacy related questions please contact:Johnathan ColemanPrincipal, Security Risk Solutions, Inc.690 Libbys Pt. Mt. Pleasant, SC 29464Tel: 843-442-9104 email: [email protected]

mailto:[email protected]

mailto:[email protected]



April 25-26, 2007

72

Elements of Privacy Principles



April 25-26, 2007

74

Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved

Analysis of Privacy Principles: An Operational Study

John LindquistPresident EWA IIT

Board Member and Treasurer

International Security Trust and Privacy Alliance (ISTPA)

75


What is the ISTPA?

The International Security, Trust, and Privacy Alliance (ISTPA), founded in 1999, is a global alliance of companies, institutions and technology providers working together to clarify and resolve existing and evolving issues related to security, trust, and privacy

ISTPA’s focus is on the protection of personal information (PI).

ISTPA

76


ISTPA’s Perspective on Privacy Operational - Solution Focus

…“making Privacy Operational” Recognizing this is a hard problem

Privacy Framework Supporting Full PI Lifecycle Basis for Convergence

Shared Privacy Vocabulary Personal Information Taxonomy Standardized Set of Industry Specific Use Cases Platform for Multidisciplinary Collaboration

Policy, Law, Regulatory, Business, Consumer, Security, Technology

Migrate to Privacy Engineering Discipline

ISTPA

77


ISTPA Framework Submitted as ISO Publicly

Available Specification

Submitted by ISSEA (International Systems Security Engineering Association) in October 2003

resubmitted after technical changes June 4, 2004

Balloting was to close December 11, 2004

Caused significant discussion, including Privacy Technology Study Group under ISO JTC-1

Withdrawal requested November 22, 2004

Initiated work to address comments of the commissioners

78


Four ISTPA Companion Projects Analysis of Privacy Requirements - Assessing data protection

regulations, the Analysis proposes a common basis for understanding core components of privacy

ISTPA-ISSEA Project: Map Security Safeguards to ISTPA Privacy Framework - Using the International Systems Security Engineering Association (ISSEA) Maturity Model for Information Security, security will be mapped to the Framework

Master Tool Set for Privacy - Given any set of privacy principles or practices (input requirements), the ISTPA Tool Set will enable mapping into detailed actions under each Privacy Framework Service

Framework revision

79


Analysis-Laws and Directives Included

The Privacy Act of 1974 (U.S.) OECD Privacy Guidelines UN Guidelines Concerning Personalized Computer Files EU Data Protection Directive 95/46/EC Canadian Standards Association Model Code (incorporated in the

Personal Health Insurance Portability and Accountability Act (HIPAA) Privacy Regulations)

US FTC statement of Fair Information Practice Principles US-EU Safe Harbor Privacy Principles Australian Privacy Act – National Privacy Principles Japan Personal Information Protection Act APEC (Asia-Pacific Economic Cooperation) Privacy Framework

80


Analysis Methodology Select representative international privacy laws and directives

Analyze disparate language, definitions and expressed requirements

Parse expressed requirements into working set of privacy categories

and terms

Cross-map common and unique requirements

Establish basis for a revised operational privacy framework to ensure

ISTPA Framework Services supports full suite of requirements

Note: For purposes of this discussion, we use the term “principles”

generically to describe privacy actions and more abstract principles

defined in the laws and directives.

81


Comparative Analysis-Sample OECD Guidelines – 1980

Collection Limitation Data Quality Purpose Specification Use Limitation Security Safeguards Openness Individual Participation Accountability

Australian Privacy Principles – 2001

Collection Use and Disclosure Data Quality Data Security Openness Access and Correction Identifiers Anonymity Transborder Data

Flows Sensitive Information

82


Derive Common Privacy Requirements

Accountability Notice Consent Collection Limitation Use Limitation Disclosure Access & Correction Security/Safeguards

Data Quality Enforcement Openness

Less common: Anonymity Data Flow Sensitivity

83


‘Special Requirements’

Anonymity: a state in which data is rendered anonymous so that the data subject is no longer identifiable (Reference Source Used: EU Data Directive)

Data Flow: the communication of personal data across jurisdictions by private or public entities involved in governmental, economic or social activities

Sensitivity: specified data or information, as defined by law, regulation or policy that requires stronger security controls or special processing

84


Analysis Study Observations Common Terminology

Four Examples Illustrating More Granular Privacy Requirements

85


Notice

Information regarding an entity’s privacy policies and practices including:

1. definition of the personal information collected2. its use (purpose specification)3. its disclosure to parties within or external to the

entity4. practices associated with the maintenance and

protection of the information5. options available to the data subject regarding

the collector’s privacy practices6. changes made to policies or practices7. information provided to data subject at

designated times and under designated circumstances

86


Consent

The capability provided to data subjects to allow 1. the collection and/or specific uses of some or all

of their personal data2. either through an affirmative process (opt-in)3. or implied (not choosing to opt-out when this

option is provided)4. including support for

Sensitive Information Informed Consent Change of Use Consent and Consequences of Consent Denial

87


Access and Correction

Capability allowing individuals having adequate proof of identity

1. to find out from an entity, or find out and/or to correct

2. their personal information

3. at reasonable cost

4. within reasonable time constraints

5. with notice of denial of access

6. and options for challenging denial

88


Data Quality

Ensures that information collected and used is

1. adequate for purpose

2. relevant for purpose

3. not excessive in relation to the purposes for which it is collected and/or further processed

4. accurate at time of use and

5. where necessary, kept up to date, rectified or destroyed

89


Next Steps: Path to Framework 2.0

Complete Final version of Analysis in May Use Analysis study to evaluate existing Framework Complete expansion of Framework functions,

including function labeling Continue collaboration with ISSEA on security

mapping Continue development of Master Toolset project to

make Framework more accessible and usable Expected draft v 2.0: December 2007 or early 2008

90


Questions?Questions?



April 25-26, 2007

103

Elements of Privacy Principles



April 25-26, 2007

Certification Commission for Healthcare Information Technology

Technology Considerations for Health Information Privacy:Role of Health IT Certification

Alisa Ray

Executive Director, Certification Commission for Healthcare Information Technology (CCHIT)

State Alliance for e-HealthHealth Information Taskforce MeetingApril 25, 2007


Background in Brief

© 2007 | Slide 107 |

Who Is CCHIT?

CCHIT is an independent, nonprofit organization with the mission of accelerating the adoption of robust, interoperable health ITby creating an efficient, crediblecertification process

© 2007 | Slide 108 |

CCHIT’s Role within theHealth IT Strategy

StandardsHarmonization

(HITSP)CCHIT:

ComplianceCertificationContractor

Health InfoSecurity & Privacy

Collaboration(HISPC)

Office of the National Coordinator

American Health Information Community

NHINProjects

HarmonizedStandards

NetworkArchitecture

PrivacyPolicies

Governance and Consensus Process EngagingPublic and Private Sector Stakeholders

Certificationof

EHRsand Networks

Strategic Direction +Breakthrough Use Cases

Accelerated adoption of

robust, interoperable,

privacy-enhancing health

IT

Accelerated adoption of

robust, interoperable,

privacy-enhancing health

IT

Certification is a voluntary, market-based mechanism to accelerate the adoption of standards and interoperability

© 2007 | Slide 109 |

Four Goals of Certification

• Reduce the risks of investing in health IT

• Facilitate interoperability of EHRs and emerging networks

• Enhance availability of adoption incentives and regulatory relief

• Ensure that the privacy of personal health information is protected

© 2007 | Slide 110 |

Scope and Timing of Certification

• May 2006: Ambulatory (office-based) EHR certification launched

• May 2007: Development expanded to address 3 specialized areas (child health, emergency department, cardiology); more to follow

• August 2007: Inpatient (hospital) EHR certification to be launched

• July 2008: Network (RHIO / health information exchange) certification to be launched

© 2007 | Slide 111 |

Evidence of Broad Acceptance of Certification

• Approximately 80 Ambulatory EHR products certified in first year

• Endorsement by physician professional societies:– American Academy of Family Physicians– American Academy of Pediatrics– American College of Physicians– American College of Emergency Physicians– Association of Emergency Physicians– Medical Group Management Association– Physicians’ Foundations for Health Systems Excellence

• Federal recognition under Stark/AKA safe harbor rules

• Payer IT incentive programs

• State and regional health information networks


Current Certification Requirements in Security and Privacy

© 2007 | Slide 113 |

2007 Ambulatory EHR Criteria Available at www.cchit.org

© 2007 | Slide 114 |

2007 Ambulatory EHR Criteria Available at www.cchit.org

some under security

some under functionality

© 2007 | Slide 115 |

Summary of 2007 EHRSecurity-Related Criteria

• User-, role-, and context-based access control (S1-S4)• Audit trail of all information accesses (S5-S9)• Authentication, session control, and password control

(S12-S21)• Protection and encryption of transmitted information

(S24-S30)• Backup and recovery of data (R1-R3)• System integrity and reliability (R4-R17)

© 2007 | Slide 116 |

Summary of 2007 EHRPrivacy-Related Criteria

• Authorship and integrity of clinical documents (F54-F61)• Patient annotation/correction (F71)• Capture and manage patient consents (F147-F151)• Maintain provider directories for purpose of user- and

role-based access authorization (F210-F214)• De-identification of data for export (F259)• Maintain directory of provider-patient relationships and

roles for access purposes (F240-F243)• Enforce jurisdiction-specific privacy rules (F247-F251 –

some items on roadmap for 2008 or 2009)


Privacy Laws and Policies in aNetworked Health Information Environment

© 2007 | Slide 118 |

Needed: A Uniform Framework for Privacy Laws and Policies

• Parameters within the framework:– Common definitions for categories of health information

• Examples: demographics; prescriptions; HIV-related diagnoses; chemical-dependency-related treatment; etc.

– Common definitions of parties sending and receiving information

• Examples: primary care physician; hospital; emergency room physician; home care nurse; etc.

– Common definitions of contexts for information requests• Examples: payment; treatment; emergency treatment; etc.

– Common definitions of patient consent options• Examples: opt-in; opt-out; partial opt-out; time-limited opt-in;

allow emergency override; etc

© 2007 | Slide 119 |

Needed: A Uniform Framework for Privacy Laws and Policies

• For health information exchange to function:– Rules covering disclosure can vary from state-to-

state, but they must all be expressed within the uniform framework

– Rules must be capable of being automated – health information networks will not function if human intervention is required for most disclosure decisions

Recommended reading: Pritt J, Connor K, “The Implementation of eConsent Mechanisms in Three Countries: Canada, England and the Netherlands”, prepared under contract to SAMHSA, Feb 2007, http://hpi.georgetown.edu/pdfs/prittse-consent.pdf

Thank you!

Q & A

For more information:www.cchit.org



April 25-26, 2007

NYS’ Approach to Electronically Exchanging HIV Data for Treatment

Jean Orzech QuarrierAssociate Counsel

April 26, 2007_________________________________

Health Information Protection Task Force Meeting

123

Goals

Discuss NYS laws re: release of HIV data for treatment

Discuss NYS’ approach to electronic exchange of HIV data

Comment on challenges/issues Address possible future directions for NYS

and national assistance

124

NYS Laws on Release of HIV data for treatment Note: NYS has laws limiting release of any

type of medical information for treatment General rule – Release of information gained

in a professional capacity is prohibited without consent or when not authorized/required by law found in NYS laws governing lic. providers

(EdL), lic. facilities (PHL) and in laws re: special categories of information (e.g. HIV, MH, genetic testing, etc.)

125

Specifically….

NYS HIV law (PHL Art.27-F; 1986) requires written special consent for disclosures unless an exception applies Can release to the patient without written special

consent. The patient can redisclose at will Can release without written special consent if

“necessary to provide appropriate care or treatment” Protection follows information/each redisclosure needs

to be justified Notice restricting redisclosure is required (similar to 42

CFR Part 42)

126

NYS’ Approach to HIV Electronic Exchange Short term:

Draft consolidated consent for use when loading or accessing the exchange (general info, HIV, mental health, etc.)

Discuss need for HIV information with clinical experts Educate the public

Long term: Continue investigating IT applications to feasibly and

reliably redact sensitive data and assess the willingness of providers to participate in a fragmented system

Consider legislation to allow up-loading and accessing of all data for treatment, with audit and enforcement safeguards

Educate the public

127

Issues & Challenges

Will patients and providers embrace the HIE? Patient issues:

May perceive extraordinary protections of HIV data as minimized by the exchange

“All or nothing” approach may drive the patients, who stand to benefit most, away from the exchange

Many may favor a clear, simple choice which holds a potential for improved, coordinated care

128

Provider issues: Providers overwhelmingly favor access to all

information for enhanced decision-making, complete evaluation and coordination of care

Impossible to assess the need for information for evaluation and diagnosis without first seeing the information

Categorization of data and redaction is burdensome & costly

129

Provider issues continued

Varying redaction standards create unreliable records where completeness is unpredictable

Liability risks to providers increase if redaction is not complete

130

Future Directions

Need increased interstate collaborations Facilitate expedited standardization of data

elements/data sets Look to national leadership for models on how to

address special categories of data E.g. Federal position on loading and accessing alcohol

and substance abuse data in HIEs Is an “all or nothing” consent approach acceptable to

federal authorities? Issuance of a model form would help guide states in handling similar sensitive information situations

E.g. favorable opinion on the acceptability of disclosing medicare/medicaid claims data for treatment purposes

131

Summary

Including HIV data as part of a clinical data exchange promises to improve the quality of care for those infected

Many compelling positions must be considered in decision-making regarding inclusion of such sensitive data into the exchanges

National leadership will be helpful to states as they review how sensitive information can be integrated into exchanges

Most of all, patient education is essential

132

Good luck to everyone as you deliberate on the way forward

Thank you



April 25-26, 2007

134

State of CaliforniaDepartment of Health Services, Office of AIDSBarbara Bailey, RDH, MSActing Chief

California’s Statutes and Practices California’s Statutes and Practices Regarding Exchange of HIV Data for TreatmentRegarding Exchange of HIV Data for Treatment

135

Background

Health and Safety Code (HSC) 100119 designates the California Department of Health Services, Office of AIDS (OA) as the lead agency responsible for coordinating state programs, services and activities related to HIV/AIDS.

OA is comprised of: • HIV/AIDS Epidemiology Branch• HIV Education & Prevention Services Branch• HIV Care Branch• AIDS Drug Assistance Program

136

California Confidentiality Statutes

HSC 120980 - Requires that persons responsible for providing medical care obtain written permission before disclosing the results of an HIV test to a third party in any manner that identifies the individual who took the test.

HSC 121025 - Requires that state and local agencies maintain the confidentiality of HIV/AIDS-related public health records that contain any personally identifying information. Except for public health purposes, disclosure of such information must be authorized in writing by the individual named in the record or his/her guardian or conservator.

137

Penalties for HSC 120980 &121025

Each negligent disclosure is subject to a civil penalty of up to $2,500 plus court costs and actual damages.

Each willful or malicious disclosure carries a civil penalty of $5,000-$10,000 plus court costs and actual damages.

Each willful, malicious, or negligent disclosure resulting in economic, physical, or psychological harm to an individual who takes an HIV test is a misdemeanor punishable by imprisonment for up to one year and/or a fine of up to $25,000 plus court costs.

138

HSC 121022 requires that OA and local health department staff and contractors sign a formal Confidentiality Agreement before being allowed access to any confidential HIV-related public health records

– Staff and contractors must sign at the time of employment and renew it every twelve months thereafter.


139


HSC 123148 permits certain laboratory test results to be posted on the Internet or other electronic method if requested by the patient and deemed appropriate by the health care provider who ordered the test.

– Consent of the patient is required

– The electronic delivery of any HIV-related test result is specifically prohibited.

140


HSC 121010 allows disclosure of an individual’s HIV test result without prior authorization to:– The health care provider, but not to a health

care service plan– An agent or employee of the subject’s health

care provider who provides direct care and treatment

– The subject of the test or the legal guardian or representative

141

Confidentiality Protections OA staff:

– All staff sign an annual confidentiality agreement (whether they work directly on client issues or not)

– All staff have a legal & ethical obligation to protect client confidentiality

– Staff working with confidential client information are physically located in a secure environment with restricted access

– HIV/AIDS case reports (surveillance cases) are kept in a secure environment in a stand-alone system that is not connected to the Internet

All patients have a right to privacy and to expect that their confidential information:

Will be handled with the utmost confidentiality Will be used only for public health purposes Will not be divulged without authorization to persons in a manner

that identifies the individual named in the record, either directly or indirectly

142

Office of AIDS Treatment Programs

AIDS Drug Assistance Program (ADAP)

CARE/Health Insurance Premium Payment Program

HIV Care Branch – Home and Community-Based Care – AIDS Medi-Cal Waiver– AIDS Case Management – Therapeutic Monitoring – Early Intervention – Care Services– Housing Opportunities for Persons with AIDS– Residential AIDS Licensed Facilities Program

143

Transfer of HIV client information Most OA care and treatment programs are HIPAA entities or work

with protected health information and must follow federal and state laws regarding the confidentiality of client information.

HIPAA compliance is the responsibility of the local health care sites; however, OA ensures that our programs have appropriate consent forms for the release of confidential information.

OA staff with access to the Medical Electronic Data System, which holds confidential information about California’s Medicare clients, must annually sign an Oath of Confidentiality.

Clients of our publicly funded care and treatment programs must sign a release form before their confidential information is shared with/transferred to other providers.

144

AIDS Drug Assistance Program Provides life-saving medications to clients who have no

other means of paying for their HIV/AIDS drugs.

All ADAP clients:– Receive an ADAP Notice of Privacy Practices – Sign a consent to release confidential personal and

medical information– Nearly all pharmacy transactions are electronic,

utilizing the National Council for Prescription Drug Programs standard

– Information shared electronically with pharmacy benefits manager and Public Health Service Bureau

145

AIDS Drug Assistance Program ADAP Medicare Part D clients:

– Clients sign a disclosure statement which allows OA to share confidential information with Medicare Part D plans

– Files are encrypted using software installed on both the sending and receiving computer

– Confidential password required to access information

– Decryption instructions and encrypted files are sent via separate emails

146

ARIES: Web-based HIV/AIDS client case management system

Care services providers coordinate care for shared clients

Ensures provision of appropriate services Avoids duplicate services Service providers enter client demographic,

program, medical and service data Web-based with extensive security features Client written permission is required for sharing

data between care service providers

147

Phasing Out Older Systems

Several care-based data collection systems that function on stand-alone databases

Providers must download client data from personal computers and sent data on a diskette through the mail to OA

All programs using this system utilize client consent forms

Data collection by paper or data files creates chances for confidentiality breaches

148

Challenges – Considerations A national data base of HIV client information:

– May increase the risk of confidentiality breaches, due to the number of users accessing the data

– May cause confusion by conflicting with the variety of state statutes regarding security and confidentiality

– Would have a significant fiscal impact due to the education, outreach and training that would be required to implement a national program

– May create concern among clients and advocates regarding trust of an electronic system of transferring confidential information

– May result in unintended consequences.

149

Contact Information Barbara Bailey, RDH, MS Acting Chief Office of AIDS CA Department of Health Services 1616 Capitol Avenue, Suite 616 P.O. Box 997426 MS 7700 Sacramento, California 95899-7426

(916) 449-5905 [email protected] Website: www.dhs.ca.gov/AIDS



April 25-26, 2007

Documents

Health Information Protection Taskforce of the State Alliance for e-Health Monthly Conference Meeting April 25-26, 2007