Health Information Protection Taskforce
of the State Alliance for e-Health
Monthly Conference Meeting
April 25-26, 2007
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 paperbased 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.
2
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 by
Dr. Linda L. Dimitropoulos
RTI International
Presented at
Monthly Meeting of the Health Information Protection Task Force
State Alliance for eHealth
April 25, 2007
230 W. Monroe
Phone 312-456-5246
■
Suite 2100
Fax 312-456-5250
■
Chicago, IL 60606
E-mail lld@rti.org
RTI International is a trade name of
Research Triangle Institute
Background
5

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
Assumptions
6

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 broadbased acceptance
Project Tasks



7
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
Project Outcomes
8

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
Sources of Variation

9
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
Sources of Variation (continued)
10

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
Sources of Variation (continued)

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
Sources of Variation (continued)

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
Sources of Variation (continued)
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
Moving Forward

14
Proposed Solutions Fall into 5 Categories

Leadership and Governance

Practice and Policy

Legal and Regulatory

Technology and Data Standards

Education and Outreach
Implementing Solutions


Within each project team

Clarify Assumptions and Define Core Principles

Identify Measurable Goals and Outcomes

Define “critical path” activities

Define Milestones and Action Steps
Across teams

15
Create communication channels and coordinate
work to prevent duplication of effort
Timelines

Final Reports due to AHRQ and ONC

May 15


Assessment of Variation and Analysis of Solutions

Implementation Plan
June 30

16
Nationwide Summary
Thank You

http://Healthit.ahrq.gov/privacyandsecurity

17
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
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
20
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
21
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)
22
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
23
Overwhelming Number of HIPAA
Preemption Cases Involve State Legal
Process Disputes
Principal HIPAA Privacy Rule Case Domains
Other
17 Cases
15%
Access to Health Information as
Part of the Legal Process
96 Cases
85%
Total Number of
Cases = 113
Source: GW HIPAA Case Law Database, 11/21/06
24
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
25
Types of Entities Involved
in Dispute Over PHI
State
Agency
(9)
Bank
(1)
Provider
(58)
N/A
(7)
Employer
(6)
Hospital
(27)
Insurance
Company
(5)
Total Number of Cases = 113
GW HIPAA Case Law Database, 11/21/06
26
Types of Underlying Claims
Types of Underlying Claims in
Relevant HIPAA Privacy Rule Cases
Wrongful Death (3)
Public Information Request (5)
Products Liability (5)
Probate (3)
Other Negligence (12)
Medical Malpractice (29)
Medicaid Reimbursement (1)
Insurance (8)
Intentional T ort (1)
Fraud (9)
DUI (8)
Divorce (1)
Discrimination (6)
Criminal Indictment (1)
Constitutional (12)
Child Pornography (1)
Child Custody (7)
Bankruptcy (1)
SOURCE: GWU-DHP HIPAA Case Law Database, 11/21/06
Total Number of Cases = 113
27
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
28
Nature of PHI Dispute
N/A
(7)
Obtain
(24)
Withold
(62)
Disclose
(20)
Total Number of Cases = 113
GW HIPAA Case Law Database, 11/21/06
29
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?
30
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.
•
31
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
32
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
33
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
34
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)
35
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
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.
38
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 paperbased 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.
39
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


3.
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
Identify examples from 3-4 states of representative
laws in each of the identified categories
40
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)
41
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
42
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.
43
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
44
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
45
Identified Categories of Major
Health Privacy Protection Laws
Types of Information
• Mental health and substance use
• HIV and other communicable diseases
• Genetic information
• Disability
Access by Whom to Information
• Individual’s access to information
about them
Uses of Information
• Treatment
• Provider (physicians and
hospitals) access to patient
information
•
Payment
•
Health care operations
•
Public health
•
•
Clinical research
•
First response to emergencies
Personal representatives access to patient
information (i.e., minors and incapacitated
adults)
46
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?
47
Parking Lot Issues
• Provider liability
• Enforcement
• Choice of law
48
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
49
Health Information Protection Taskforce
of the State Alliance for e-Health
Monthly Conference Meeting
April 25-26, 2007
HITSP Security and Privacy
Johnathan Coleman, CISM, CISSP
Principal, Security Risk Solutions, Inc.
HITSP Security and Privacy Technical Committee Facilitator
April 25, 2007
Agenda
1.
2.
3.
4.
5.
6.
Relationship between HITSP, HISPC and CCHIT
HITSP Charter and Goals
Harmonization Process
Current Status of HITSP Security and Privacy Activities
HITSP Security and Privacy Constructs under Consideration
HITSP Contact Information
Evaluation of Standards Harmonization Process for HIT
52
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
The Certification
Commission for
Healthcare
Information
Technology
(CCHIT)
Healthcare
Information
Technology
Standards Panel
(HITSP)
American
Health
Information
Community
The Health
Information
Security and
Privacy
Collaboration
(HISPC)
Nationwide
Health
Information
Network
Architecture
Projects (NHIN)
Evaluation of Standards Harmonization Process for HIT
HITSP includes 348 different member
organizations and is administered by
a Board of Directors
24 SDOs (7%)
247 Non-SDOs (71%)
30 Govt. bodies (9%)
12 Consumer groups (3%)
36 Project Team and Undeclared (10%)
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, marketled way.
53
The HITSP team is charged with completing eleven different
tasks, with current efforts focused on the harmonization
process
Eleven Tasks are included in this contract:
The Community
HHS Secretary
Mike Leavitt, Chair
1. Comprehensive Work Plan
HHS ONCHIT1
PO, Dr. John Loonsk
HITSP
Dr. John Halamka, Chair
Member populated
Technical Committees
Project Management Team
Executive in Charge, F. Schrotter, ANSI
Program Manager, L. Jones GSI
Deputy PM, J Corley, ATI
Project Manager, Julie Pooley, Booz Allen
Harmonization
Process Definition
Technical
Manager
Michelle Deane,
ANSI
Harmonization
Process Delivery
Technical
Manager
Joyce Sensmeier,
HIMSS
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
Evaluation of Standards Harmonization Process for HIT
54
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.
Evaluation of Standards Harmonization Process for HIT
55
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 Committees
and Leadership
 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
Evaluation of Standards Harmonization Process for HIT
56
The actual harmonization process is a series of steps taken
by industry stakeholders within the context of HITSP
Harmonization Process Steps
Receive
Request
I
Harmonization
Request
II
III
IV
Requirements
Analysis
Identification
of Candidate
Standards
Gaps,
Duplications
and
Overlaps
Resolution
V
VI
Standards
Selection
Construction
of
Interoperability
Specification
VII
Inspection
Test
VIII
Interoperability
Specification
Release
and
Dissemination
IX
Program Management
Begin
Support
Evaluation of Standards Harmonization Process for HIT
57
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 EREHR 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.
Evaluation of Standards Harmonization Process for HIT
58
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:
Evaluation of Standards Harmonization Process for HIT
08/17 – 10/15
59
Work Plan and Schedule Overview
HITSP 2007 Timeline
02/05/07
HITSP Board
02/12/07
HITSP Panel
JAN
FEB
04/23/07
HITSP Board
03/19/07
HITSP Panel
MAR
MAY
JUN
JUL
AUG
6/18 – 6/20
TC Face to Face
San Diego CA
5/08 – 5/10
TC Face to Face
Arlington VA
03/06 – 03/08
TC Face to Face
Chicago IL
09/07/07
HITSP Panel
07/16/07
HITSP Panel
05/11/07
HITSP Panel
APR
10/09/07
HITSP Board
07/09/07
HITSP Board
10/15/07
HITSP Panel
SEP
OCT
NOV
DEC
09/04 – 09/06
TC Face to Face
Arlington VA
Activity 1 – Version 2.0 of Existing EHR, CE, BIO ISs
EHR, CE and BIO v 2.0
Implementation Support and Testing
(includes minor document updates)
On-going
Support
Activity 2 – Security and Privacy for All Use Cases
Activity 3 – New Emergency Responder EHR Use Case
Requirements, Design,
Standards Selection
02/15 – 05/16
04/13 – 05/16
Public Input
on S&P
S&P and EHR-ER v 1.0
05/17 – 06/14
Public
Comment
IS Construct Development
05/17 – 07/19
Inspect Test
and Public
Comment
07/20 – 08/16
Comment Resolution and
Panel Approval
Implementation Support and
Testing
(with annual updates as required)
08/17 – 10/15
Activity 4 –New Use Cases from AHIC
Detail Schedule to be Established Upon Review of the Use Cases
Evaluation of Standards Harmonization Process for HIT
60
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
Evaluation of Standards Harmonization Process for HIT
61
HITSP Security and Privacy Constructs under Consideration
Evaluation of Standards Harmonization Process for HIT
62
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: jsensmeier@himss.org
Or
Jessica Kant
Coordinator, Standards Harmonization
Healthcare Information & Management Systems Society
230 E. Ohio St., Suite 500
Chicago, IL 60611
Phone: 312-915-9283 Fax: 312-915-9511 email: jkant@himss.org
For HITSP Security and Privacy related questions please contact:
Johnathan Coleman
Principal, Security Risk Solutions, Inc.
690 Libbys Pt.
Mt. Pleasant, SC 29464
Tel: 843-442-9104 email: jc@securityrisksolutions.com
Evaluation of Standards Harmonization Process for HIT
63
Health Information Protection Taskforce
of the State Alliance for e-Health
Monthly Conference Meeting
April 25-26, 2007
Elements of Privacy Principles
72
Health Information Protection Taskforce
of the State Alliance for e-Health
Monthly Conference Meeting
April 25-26, 2007
Analysis of Privacy Principles: An
Operational Study
John Lindquist
President EWA IIT
Board Member and Treasurer
International Security Trust and Privacy
Alliance (ISTPA)
74
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).
75
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
ISTPA
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
76
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
ISTPA
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
77
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
78
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
AnalysisLaws 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
79
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.
80
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
81
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
82
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
83
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
Analysis Study Observations
Common Terminology
Four Examples Illustrating More
Granular Privacy Requirements
84
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 collected
2.
its use (purpose specification)
3.
its disclosure to parties within or external to the
entity
4.
practices associated with the maintenance and
protection of the information
5.
options available to the data subject regarding
the collector’s privacy practices
6.
changes made to policies or practices
7.
information provided to data subject at
designated times and under designated
circumstances
85
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 data
2.
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
86
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
87
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
88
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
89
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
Questions?
90
Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved
Health Information Protection Taskforce
of the State Alliance for e-Health
Monthly Conference Meeting
April 25-26, 2007
Elements of Privacy Principles
103
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-Health
Health Information Taskforce Meeting
April 25, 2007
Certification Commission
for Healthcare
Information Technology
Background in Brief
Who Is CCHIT?
CCHIT is an independent, nonprofit organization
with the mission of accelerating the adoption
of robust, interoperable health IT
by creating an efficient, credible
certification process
© 2007 | Slide 107 |
CCHIT’s Role within the
Health IT Strategy
American Health Information Community
Office of the National Coordinator
Standards
Harmonization
(HITSP)
NHIN
Projects
Health Info
Security & Privacy
Collaboration
(HISPC)
Strategic Direction +
Breakthrough Use Cases
Harmonized
Standards
Network
Architecture
CCHIT:
Compliance
Certification
Contractor
Certification
of
EHRs
and Networks
Privacy
Policies
Accelerated adoption
of robust,
interoperable,
privacy-enhancing
health IT
Governance and Consensus Process Engaging
Public and Private Sector Stakeholders
Certification is a voluntary, market-based mechanism
to accelerate the adoption of standards and interoperability
© 2007 | Slide 108 |
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 109 |
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 110 |
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
© 2007 | Slide 111 |
Certification Commission
for Healthcare
Information Technology
Current Certification
Requirements in
Security and Privacy
2007 Ambulatory EHR Criteria
Available at www.cchit.org
© 2007 | Slide 113 |
2007 Ambulatory EHR Criteria
Available at www.cchit.org
some under functionality
some under security
© 2007 | Slide 114 |
Summary of 2007 EHR
Security-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 115 |
Summary of 2007 EHR
Privacy-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)
© 2007 | Slide 116 |
Certification Commission
for Healthcare
Information Technology
Privacy Laws and
Policies in a
Networked Health
Information Environment
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 118 |
Needed: A Uniform Framework
for Privacy Laws and Policies
• For health information exchange to function:
– Rules covering disclosure can vary from state-tostate, 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
© 2007 | Slide 119 |
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 Quarrier
Associate Counsel
April 26, 2007
_________________________________
Health Information Protection Task Force Meeting
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
123
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.)
124
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)
125
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

126
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
127
 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
128
 Provider issues continued


Varying redaction standards create unreliable
records where completeness is unpredictable
Liability risks to providers increase if redaction
is not complete
129
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
130
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
131
Good luck to everyone as you
deliberate on the way forward
Thank you
132
Health Information Protection Taskforce
of the State Alliance for e-Health
Monthly Conference Meeting
April 25-26, 2007
State of California
Department of Health Services, Office of AIDS
Barbara Bailey, RDH, MS
Acting Chief
California’s Statutes and Practices
Regarding Exchange of HIV Data for Treatment
134
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
135
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.
136
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.
137
California Confidentiality Statutes
 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.
138
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.
139
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
140
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
141
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
142
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.
143
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
144
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
145
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
146
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
147
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.
148
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
 bbailey@dhs.ca.gov
 Website: www.dhs.ca.gov/AIDS
149
Health Information Protection Taskforce
of the State Alliance for e-Health
Monthly Conference Meeting
April 25-26, 2007