Laying a Foundation for the Next 10 Years
of Secure, Interoperable Exchange
Jeremy Maxwell, PhD
IT Security Specialist, ONC June 24, 2015
Learning Objectives
• Explain the core elements of the Shared Nationwide Interoperability Roadmap • Assess open challenges to be solved to
achieve an interoperable health system
• Describe the ways in which ONC is working with the health care industry to ensure the foundation for health IT interoperability
Agenda
• Basics of the Shared Nationwide Interoperability Roadmap
Interoperability
The ability of a system to exchange electronic health information with and use electronic
health information from other systems without
Why Does Interoperability Matter?
• Individuals and providers need access to the right
information at the right time in a manner they can use to make decisions that impact their health regardless of
geographic or organizational boundaries
• Typical Medicare beneficiary receives care from 2 primary care providers and 5 specialists each year
• Only 10-20% of health outcomes are attributable to health care
• Information needs to flow inside and outside the care delivery system to support health
Why Now?
• Consumers increasingly expect and demand real-time access to their electronic health information
• Significant progress in digitizing the care experience
• Evolving delivery and payment models are not only driving appropriate data sharing, but depend on it
• Successes and promising practices exist and can be built on • Technology is rapidly evolving
Removing Roadblocks to
DRAFT Shared Nationwide Interoperability Roadmap The Vision 2021 - 2024 Broad-scale learning health system 2018 - 2020 Expand interoperable data, users, sophistication, scale 2015 - 2017 Nationwide ability to send, receive, find,
use a common clinical data set
2021 - 2024 Broad-scale learning health system 2018 - 2020 Expand interoperable data, users, sophistication, scale 2015 - 2017 Nationwide ability to send, receive, find,
use a common clinical data set
DRAFT Shared Nationwide Interoperability Roadmap
Critical Near Term Actions by Building Block
Privacy and security protections for health information
• Educate stakeholders on current federal laws & cybersecurity
• Work with states and organizations to align laws that provide additional protections, without undermining privacy
Critical Near Term Actions by Building Block
Privacy and security protections for health information
• Educate stakeholders on current federal laws & cybersecurity
• Work with states and organizations to align laws that provide additional protections, without undermining privacy
Agenda
• Basics of the Shared Nationwide Interoperability Roadmap
Privacy & Security Portions of the Roadmap
• Section E: Ubiquitous, secure network infrastructure • Section F: Verifiable identity and authentication of all
participants
• Section G: Consistent representation of permission to collect, share and use identifiable health
information
• Section H: Consistent representation of authorization to access health information
Section E: Ubiquitous, Secure
Security Risk Management
Killing Security Myths
• We have firewall and VPN. We’re safe • We have encryption. We’re safe
• We have _______. We’re safe • Security is a technical problem • Security is a policy problem
• We’ll secure it later
• Security controls cause performance problems • Security controls are hard to use
Call to Action:
Multi-Layered, Defense in Depth
• Security risk management program • Usability, usability, usability
• Documented security controls
• Cross-organizational threat information sharing • Incident response capabilities
• Operational & behavioral monitoring (particularly those credentials that have system-level access to APIs or databases that contain PHI) • Develop & deploy health IT following DHS and NIST guidance for
“building security in”
• Assess the security of applications and infrastructure via penetration testing & other means, to identify vulnerabilities before they are
exploited
• Encrypt the contents of all network messages in transit
Section F: Verifiable Identity and
Auth* Concepts
IDENTITY
Call to Action: Things to Solve
• Levels of Assurance
– Identity proofing vs. authentication – Remote patient authentication
– Remote provider/IT admin authentication • Continued innovation for authentication
technology
• Identifying and recovering from medical identity theft
Section G: Consistent Representation of
Permission to Collect, Share and Use
or
Laws, regulations, and policies for patient consent
Laws, regulations, and policies for sensitive information
Consent models (opt-in, opt-out, with restrictions, etc.)
HIO/HIE Architecture
EHR system interoperability Patient consent directive (paper/electronic)
HIPAA Permitted Uses and Disclosures
D.C. Code § 7-1201.01 Definitions
District of Columbia Official Code—Division I. Government of District—Title 7. Human Health Care and Safety— Subtitle C. Mental Health—Chapter 12. Mental Health Information—Subchapter I. Definitions; General provisions
Mental health information means any written, recorded or oral information acquired by a mental health professional in attending a client in a professional capacity which:
(A) Indicates the identity of a client; and
(B) Relates to the diagnosis or treatment of a client’s mental or emotional condition. N.C. Gen. Stat. § 122C-3 Definitions
General Statues of North Carolina—Chapter 122C. Mental Health, Developmental Disabilities, and Substance Abuse
Act of 1985—Article I. General Provisions
Confidential information means any information, whether recorded or not, relating to an individual served by a facility that was received in connection with the performance of any function of the facility. Confidential information does not include statistical information from reports and records or information regarding treatment or services which is shared for training, treatment, habilitation, or monitoring purposes that does not identify clients either directly or by reference to publicly known or available information.
Sample State Definitions of Mental Health
• States philosophically aligned
• State privacy and consent laws are diverse in content • Diversity in organizational
policies within states
• See roadmap appendix A and B for ONC Consent Bibliography
Data Segmentation for Privacy (DS4P) How it Works
Separating Policy from Technical Capability
The DS4P standard enables interoperability and provides a capability to support existing privacy law, including federal, state, and local laws
The standard uses document level tagging as the mechanism to convey confidentiality levels and obligations, but also
specifies how to be more granular (e.g. sections or entries inside the document)
• Depends if the implementing (sending or receiving) system can support it
• Laws tell data-holders not to disclose; law rarely tells them what to say about that non-disclosure. For example:
– HIV Status: **Redacted**
• This is a likely indicator that the patient has a test result – if the applicable law protects results of tests, not
occurrences, this may indicate a positive result; or – HIV Status: **No data available**
• This is may be misleading for a physician, who may then make a health decision for the patient without knowing important details that could lead to safety issues.
– HIV Status: [record is silent]
• This is ambiguous. The recipient does not know if there was a redaction, or no data is available.
• How to Segment: There are multiple levels at which segmentation could occur, such as:
– Type of Data category of data - e.g. medications, diagnostic codes, etc.
– Clinical category of code of whatever type – Disclosing provider
– Intended recipient
– Program type (e.g. Part 2 clinic)
• Structured vs Unstructured Data: Prevalence of free-text complicates identification of data that is subject to enhanced protection.
Call to Action: Things to Solve
• Granularity: Should data be segmented:
– At the “whole document” level? – For parts of a document?
– According to clinical nature within the document?
• Standardized mapping of specially protected categories to codes would make segmentation more predictable:
– For individuals through standard understanding – For providers through standard expectations
– For developers, with less confusion about what law requires
• Currently, not every receiving system can understand 42 CFR Part 2
Section H: Consistent Representation of
Authorization to Access Health
Defining Terms
• authorization - the scope or amount of information a person or system is allowed to access
• Authorization - a signed HIPAA document pursuant to which when HIPAA requires it, documenting that an individual authorizes the covered entity to release their PHI (can be paper or electronic)
Local user authorization is out of scope for the Roadmap
Call to Action: Things to Solve
• What needs to be documented to ensure that callers are authorized to access data:
– Patients
– Personal representatives – Other providers
– Other health IT
• Building trust so that apps do not need prior
approval by the API vendor (whitelisting) – Trustmarks as a way to convey trust?
Summary
• Ensuring that privacy & security is not a
roadblock but an enabler to appropriate data flows
• Address both policy & technical questions • Collaboration and industry involvement
Additional Resources
• Security Risk Assessment Tool
http://www.healthit.gov/providers-professionals/security-risk-assessment-tool
• Guide to Privacy and Security of Electronic Health Information
http://www.healthit.gov/providers-professionals/guide-privacy-and-security-electronic-health-information
• OCR’s website
Backup &
Examples of ONC’s Efforts to Work With Industry
• Health IT certification program • Governance efforts
• Standards efforts – Advisory, S&I Framework, SITE
• Programs – recent funding opportunities • FACAs, listening sessions
National Strategy for Trusted Identities
in Cyberspace (NSTIC)
• DS4P was tested on substance abuse information (for example, 42 CFR Part 2 data)
where the category of special protection derives from the federally funded program
where the care is supplied
– 42 CFR Part 2 (Part 2) is a federal law and does not change across state lines – 42 CFR Part 2 protect adheres to care supplied in buildings covered by that
regulation and the statute it derives from
• DS4P can therefore recognize that a provider applied special protections because of the physical source of the data;
– Therefore, segmentation can be based on the whole program, not specific clinical portions of it
DS4P Standards:
What can DS4P do?
For example, in a Part 2 covered program a physician may track a patient’s blood
pressure. Although this data might not be specially protected otherwise, it is specially
• What about segmentation necessary due to the clinical nature of the data (not a location)?
• There are 8 basic categories of special privacy protections due to clinical nature, not
necessarily where care was provided
– HIV/AIDS; Drug/Alcohol Abuse (not Part 2), Mental Health/Behavioral Health;
Reproductive Health of Women; Genetic Information (not GINA); STD; Teen Health Information; Domestic Violence health information.
• DS4P might be effective if there was harmonization between legal definitions of what is
protected and medical codes (e.g. ICD10).
• Harmony is lacking:
Example: in a PCP office, some collected information is specially protected, such as evidence that a Chlamydia test occurred, while other information is not. All care occurs in the same place.
DS4P Standards:
• Technical standards can help organizations implement policy, but first the policy must support the use of the technical standards.
• Currently, although state law is philosophically aligned, it is not harmonized, so nationwide mapping to code sets has not taken root.
• Lack of harmony may:
– Exaggerate privacy concerns because of confusion. – Undermine potential business cases for
interoperable information exchange.
– Foster skepticism about the ability of information exchange to deliver comprehensive data.
DS4P Standards:
