health information protection taskforce of the state alliance for e-health monthly conference...
TRANSCRIPT
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.
Health Information Protection Taskforce of the State Alliance for e-Health
Monthly Conference Meeting
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
Sources of Variation (continued)
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
Sources of Variation (continued)
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
Sources of Variation (continued)
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
Health Information Protection Taskforce of the State Alliance for e-Health
Monthly Conference Meeting
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
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%
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)
Total Number of Cases = 113
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)
Total Number of Cases = 113
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)
Health Information Protection Taskforce of the State Alliance for e-Health
Monthly Conference Meeting
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
Approach to Work Product
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
Approach to Work Product
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
Approach to Work Product
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
Approach to Work Product
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
Health Information Protection Taskforce of the State Alliance for e-Health
Monthly Conference Meeting
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
53Evaluation of Standards Harmonization Process for HIT
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%)
54Evaluation of Standards Harmonization Process for HIT
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
55Evaluation of Standards Harmonization Process for HIT
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.
56Evaluation of Standards Harmonization Process for HIT
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
57Evaluation of Standards Harmonization Process for HIT
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
58Evaluation of Standards Harmonization Process for HIT
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.
59Evaluation of Standards Harmonization Process for HIT
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
60Evaluation of Standards Harmonization Process for HIT
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
5/08 – 5/10TC Face to Face
Arlington VA
6/18 – 6/20TC Face to Face
San Diego CA
09/04 – 09/06TC Face to Face
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
61Evaluation of Standards Harmonization Process for HIT
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
62Evaluation of Standards Harmonization Process for HIT
HITSP Security and Privacy Constructs under Consideration
63Evaluation of Standards Harmonization Process for HIT
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]
Health Information Protection Taskforce of the State Alliance for e-Health
Monthly Conference Meeting
April 25-26, 2007
72
Elements of Privacy Principles
Health Information Protection Taskforce of the State Alliance for e-Health
Monthly Conference Meeting
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
‘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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
Analysis Study Observations Common Terminology
Four Examples Illustrating More Granular Privacy Requirements
85
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
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
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
Questions?Questions?
Health Information Protection Taskforce of the State Alliance for e-Health
Monthly Conference Meeting
April 25-26, 2007
103
Elements of Privacy Principles
Health Information Protection Taskforce of the State Alliance for e-Health
Monthly Conference Meeting
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
Certification Commission for Healthcare Information Technology
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
Certification Commission for Healthcare Information Technology
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)
Certification Commission for Healthcare Information Technology
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
Health Information Protection Taskforce of the State Alliance for e-Health
Monthly Conference Meeting
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
Health Information Protection Taskforce of the State Alliance for e-Health
Monthly Conference Meeting
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.
California Confidentiality Statutes
139
California Confidentiality Statutes
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
California Confidentiality Statutes
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
Health Information Protection Taskforce of the State Alliance for e-Health
Monthly Conference Meeting
April 25-26, 2007