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

1 Welcome, Opening Remarks OCR Presentation Finish Reviewing Key Themes from Hearings Questions/Clarification Needed More Information/Action Items Top Challenges/Key Drivers for Success Discussion/Questions Next Steps Adjourn Agenda

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

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 3

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 best practices 4

Read-Only Access API There are additional challenges when an API allows data to be written to the system it is connected with ONC’s 2015 Edition API requirement is for a read-only API. Some comments about APIs that can have data written to them (this is out of scope for this TF): 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 (Google) asserted that all data coming from the outside should be considered unsecure unless tested Imprivata discussed the challenge 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. 5

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) 6

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. – OCR has new guidance that consumers have a right to their own data (more to come 2/23) 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 – 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 their 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 7

Liability OCR Access guidance 1/7/16 states that when a consumer directs that a copy of 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 sharing, 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? 8

More Information/Action Items ForgeRock provided example of ‘Open Bank’ API in the UK – recommended for identity authentication, security, content; reduces complexity; enables bridging of different data sources with fewer vulnerabilities, and is more commercial and open source Also look into ForgeRock’s open source project- establishes-openidm-project-for-open-source-identity- management/ establishes-openidm-project-for-open-source-identity- management/ Differences between OAuth and OAuth 2.0 Google is doing a “deep dive” on how scoping permissions are implemented and could provide more information IBM has consumer-facing educational resources that it may share Identify standards in the industry that should be focused on (FHIR, Blue Button) 9

Top Challenges/Key Drivers for Success Top Challenges Business drivers for enabling open API access Need for trust across the ecosystem Enabling patient driven trust decisions Transparent terms of use Disparities in resources, means, and information between larger organizations and smaller provider practices Cultural and workflow issues Fear of legal liability Key Drivers for Success Industry collaboration to develop standards-based open APIs Fostering a cultural shift to encourage development and innovation “Financial incentives – Shifts in costs with move to value-based care and delivery of services – Shift from low tech to higher tech including more prevalent consumer driven technologies 10

Discussion/Questions 11

Next Steps Next Meeting is planned for 3/8/16 Recommendations and process moving forward – Identify additional themes for consideration. – Deliberate topic areas from which to formulate recommendations – What are the most important items for ONC to focus on to address privacy and security concerns for APIs? 12

Workplan 13 MeetingsTask Monday, February 22 nd 11:30am-1pm ET API Task Force Call Tuesday, March 8 th 10:30am-12:00pm ET API Task Force Call March 9 HITSC and March 10 HITPC Present draft recommendations to both HITSC and HITPC Tuesday, March 22 nd 10:30am- 12:00pm ET API Task Force Call Tuesday, April 12 th 10:30am-12:00pm ET API Task Force Call April 19 Joint Committee Meeting Present final recommendations