Laying a Foundation for the Next 10 Years of Secure, Interoperable Exchange

Transcription

1 Laying a Foundation for the Next 10 Years of Secure, Interoperable Exchange Jeremy Maxwell, PhD IT Security Specialist, ONC June 24, 2015

2 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 2

3 Agenda Basics of the Shared Nationwide Interoperability Roadmap Privacy & security portions of the Roadmap 3

4 Interoperability The ability of a system to exchange electronic health information with and use electronic health information from other systems without special effort on the part of the user 4

5 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 5

6 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 Opportunities to improve care and advance science in a learning health system environment demand rapid action 6

7 Removing Roadblocks to Accessing Patient Data 7

8 DRAFT Shared Nationwide Interoperability Roadmap The Vision Nationwide ability to send, receive, find, use a common clinical data set Expand interoperable data, users, sophistication, scale Broad-scale learning health system 8

9 DRAFT Shared Nationwide Interoperability Roadmap The Vision Nationwide ability to send, receive, find, use a common clinical data set Expand interoperable data, users, sophistication, scale Broad-scale learning health system 9

10 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 10

11 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 11

12 Agenda Basics of the Shared Nationwide Interoperability Roadmap Privacy & security portions of the Roadmap 12

13 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 13

14 Section E: Ubiquitous, Secure Network Infrastructure 14

15 Security Risk Management Back to Basics 15

16 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 People are the greatest weakness 16

17 What Do All These Say? 17

18 18

19 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 Secure all data stored in databases by encrypting data at rest and securing the encryption keys 19

20 Section F: Verifiable Identity and Authentication of All Participants 20

21 Auth* Concepts IDENTITY PROOFING CREDENTIALS AUTHENTICATION AUTHORIZATION 21

22 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 22

23 Section G: Consistent Representation of Permission to Collect, Share and Use Identifiable Health Information 23

24 Current U.S. Privacy Rules Environment 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) or HIPAA Permitted Uses and Disclosures (background rules) 24

25 Sample State Definitions of Mental Health Information (for Disclosure Purposes) D.C. Code 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. 25

26 Current State Law Environment 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 26

27 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 27

28 Policy Challenges 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. 28

29 Call to Action: Things to Solve 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. 29

30 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 segmented data, i.e., their system does not recognize that it is receiving data that is subject to heightened protections based on Part 2 law. 30

31 Section H: Consistent Representation of Authorization to Access Health Information 31

32 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 32

33 Authorization Across Exchange Contexts 33

34 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? 34

35 Summary 35

36 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 needed 36

37 Additional Resources Security Risk Assessment Tool Guide to Privacy and Security of Electronic Health Information OCR s website 37

38 Thank You 38

39 Backup & Additional Reading 39

40 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 Education efforts 40

41 Tracking Progress and Measuring Success 41

42 National Strategy for Trusted Identities in Cyberspace (NSTIC) Calls for building an identity ecosystem where: 42

43 DS4P Standards: What can DS4P do? 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 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 protected because the care is supplied in a Part 2 covered program. 43

44 DS4P Standards: What are DS4P Limits? 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. Even if a disclosing system segments data, the receiving system may not be able to recognize that segmentation (more later). 44

45 DS4P Standards: What does this tell us? 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. 45