Subtitle Title Date Josh Mandel, Co-Chair Meg Marshall, Co-Chair March 8, 2016 API Security Task Force

1 Welcome, Opening Remarks Finish Reviewing Key Themes from Hearings Discuss Draft Recommendations Next Steps Public Comment Adjourn Agenda

Key Themes from January Hearings Continued 2

Security Best Practices APIs are not inherently more vulnerable to security risks, and should be treated using best practices including all technical controls, policies and procedures, an “engineering culture”, and adapting to the constant evolution of threats and newest security standards. Technical controls are necessary but not sufficient to building a secure system (Google) Well known best practices include for security hygiene not unique to APIs: – Use of encryption – Authorization/authentication/identity verification mechanisms – Data access management controls & Role-based/Attribute-based access – Code review – Testing – Monitoring and audit logs – Integrity controls – Rate limiting mechanisms – Scanning for incoming attack vectors (SQL Injection) 3

Policy and Cultural Factors to Promote Security Fraud prevention partnerships are also formed between public and private sectors to share information on vulnerabilities GE testified that internal policies are more important than technology with respect to authentication, consent and accountability – Development of internal policy is out of scope Technology exists to support good policies, but the policies have to come first, and aim for security best practices Organizational buy-in, culture and workflow considerations should also be taken into account as it is difficult to change – Fostering this kind of “engineering culture’ requires a tremendous amount of organizational bias. APIs that are backed by an engaged developer community have an increased likelihood to be leveraged by a developer 4

API-Specific Factors to Promote Security Well-designed APIs are clear with specifications and documentation of security controls and differentials that need to be acquired before they are built and used (Apigee). These can also be offered with a ”web portal” for potential developers to learn and interact with offering team However, a secure ecosystem and infrastructure is necessary as those who wish to exploit a system keep trying, no matter how clever the engineering – Organizations need to stay on top of current security best practices 5

Patient Access Rights Consumers are really looking for APIs as a way to gain access to their healthcare information that may be held in multiple provider and payer systems today. Consumer panelists uniformly wanted to access their own health information, – Even if that is through insecure methods; – Consumers would rather have the data than risk their care providers NOT having access to the information; – Consumers want to send it where it works for them, even if that is to a less secure environment; and – A task force member said a patient is not giving away his/her rights by sending data outside their provider’s system, rather, they were exercising them. We need to educate consumers so they understand risks. Patients have right to use data as they wish. HIPAA highlights a patient’s right to access his or her own PHI Many providers have “closed” systems and patient portals that limit access Open frameworks, improved interoperability, and access to data was supported and advocated for by groups including Imprivata, Aetna, Redox Engine, as well as by Consumer/Patient Advocates 6

Liability OCR Access guidance from 1/7/16 states that when a consumer requests that a copy of his or her own data be transmitted to a third party of their choosing, the discloser is not responsible for security failures at the destination ONC/OCR Fact Sheets published 2/4/16 state that when two providers are exchanging data, if the disclosing provider sends the data in a manner compliant with the HIPAA Security Rule, the disclosing provider is not responsible for security failures at the destination What other liability issues remain to be solved that derive from Privacy or Security rules? 7

Remaining Questions for OCR 8

9 OCR Access Guidance is available on the OCR website. OCR will be drawing on it for their responses to the questions. professionals/privacy/guidance/access/index. html professionals/privacy/guidance/access/index. html

Next Steps Joint HITPC & HITSC Committee Meeting 3/10/16 – Present Draft Recommendations Next Meeting is planned for 3/22/16 Recommendations and process moving forward – Deliberate topic areas from which to formulate recommendations – Continue to refine and formulate recommendations – What are the most important items for ONC to focus on to address privacy and security concerns for APIs? 10

Workplan 11 MeetingsTask Monday, February 22 11:30am-1pm ET API Task Force Call Tuesday, March 8 10:30am-12:00pm ET API Task Force Call March 10 Joint Committee Meeting Present themes at Joint HITSC and HITPC Tuesday, March 22 10:30am- 12:00pm ET API Task Force Call Monday, March 28, 10:30am-12:00pm ET API Task Force Call Tuesday, April 12 10:30am-12:00pm ET API Task Force Call April 19 Joint Committee Meeting Present draft recommendations Tuesday, April 26, 10:30am-12:00pm ET API Task Force Call May 4/5 Committee Meetings Present final recommendations to HITSC and HITPC

Out of Scope Topics from January Hearings 12

Write APIs (Out of Scope) ONC’s 2015 Edition API requirement is for a read-only API. Some comments about APIs that support write capabilities): There are additional challenges when an API allows data to be written to the system with which it is connected Accuracy, matching, provenance and reliability of patient generated health data that is written to a record through an API (Imprivata) Security of the arriving data - all data coming from the outside should be considered unsecure unless tested (Google) Challenges in assuring the integrity of PGHD, and the need to assert the integrity of that block of data from the moment the patient is uploaded to verify identity through some means (Imprivata) 13

Business & Legal Issues (Out of Scope) Privacy and security regulations may be a barrier to the market advancing for fear of legal liability, criminal charges to “white hat” activity, and uncertainty of standards to meet compliance policy. Complex contracting (ForgeRock, LexisNexis) including issues of intellectual property protection and indemnification Hard to take advantage of white-hat hacking in healthcare due to regulation of the underlying data (Google, Programmable Web, and ForgeRock) – In the healthcare industry “white hats” will not risk legal liability, as they do in other sectors – Testimony was asserted that “hackathons” provide valuable information (IBM) 14