1. Kickoff Meeting Josh Mandel, Co-Chair Meg Marshall, Co-Chair November 30, 2015 API Security Task Force

2. 1 Welcome, Opening Remarks & Member Introduction Review Charge Review Draft Workplan Background Information Public Comments Privacy and Security Workgroup Recommendations Adjourn Agenda

3. 2 API Task Force Membership MemberOrganizationRole Josh MandelHarvard Medical SchoolCo-Chair Meg MarshallCernerCo-Chair Leslie Kelly HallHealthwiseMember Robert JarrinQualcomm IncorporatedMember Rajiv KumarStanford University School of MedicineMember Richard LoomisPractice FusionMember Aaron MiriWalnut Hill Medical CenterMember Drew SchillerValidicMember Aaron SeibNational Association for Trusted ExchangeMember David YakimischakSurescriptsMember Ivor HornSeattle Children'sMember Federal Ex Officio Linda Sanches, Office for Civil Rights- Health and Human Services ONC Staff Jeremy Maxwell Rose-Marie Nsahlai, Staff Lead Maya Uppaluru The objective of this membership mix is to have a small, diverse and nimble group of stakeholders to bring forth legitimate concerns re: APIs from multiple perspectives.

4. Application Programming Interface (API) Application Programming Interface (API) – a technology that allows one software program to access the services provided by another software program In its 2015 Edition CEHRT rule, ONC has included certification criteria for fully functioning APIs to support patient access to health data via view, download, and transmit (VDT). However, in discussing this concept in the proposed rule with our FACAs, many members expressed concerns about privacy compliance and security of APIs. Therefore, the API Task Force was created to… 3

5. Task Force Charge and Questions 4 Identify perceived security concerns and real security risks that are barriers to the widespread adoption of open APIs in healthcare. – For risks identified as real, identify those that are not already planned to be addressed in the Interoperability Roadmap (for example, identity proofing and authentication are not unique to APIs); Identify perceived privacy concerns and real privacy risks that are barriers to the widespread adoption of open APIs in healthcare. – For risks identified as real, identify those that are not already planned to be addressed in the Interoperability Roadmap (for example, harmonizing state law and misunderstanding of HIPAA); Identify priority recommendations for ONC that will help enable consumers to leverage API technology to access patient data, while ensuring the appropriate level of privacy and security protection.

6. Out of Scope Issues Terms of Use Licensing Requirements Policy Formulation Fee Structures Certifying Authorities Formulation of Standards 5

7. Proposed Workplan 6 MeetingsTask Monday, November 30 th 10:30am-12:00pmET Kick-off Meeting Introduction, review and refinement of charge, review of workplan Friday, December 4 th 11:30am-1:00pmET API overview presentation Introduce virtual hearing, discuss goals and outcomes Review panelist questions Friday, December 11 th 12:00-1:30pm ET Refine panel structure and questions Offline Administrative Call - TBD Identify and refine hearing presenters Tuesday, January 12 th 10:30am-12:00pm ET Prepare for Virtual Hearings Tuesday, January 26 th 12:00-5:00pm ET Virtual Hearing (two sessions will be held on the calendar for the moment) Thursday, January 28 th 12:00-5:00pm ET Virtual Hearing (two sessions will be held on the calendar for the moment) Tuesday, February 9 th 10:30am-12:00pm ET API Task Force Call 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 Tuesday, March 22 nd 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, April 12 th 10:30am-12:00pm ET API Task Force Call April 19 Joint Committee Meeting Present final recommendations

8. Background Information 7

9. APIs APIs, like all technologies, can have privacy and security vulnerabilities. APIs are fundamental to large scale data interoperability and are widely used in other industries, like finance and government, where privacy and security concerns are similar to those we have in healthcare. Therefore, we need to understand and address whether there are privacy and security issues unique to APIs for interoperable movement of health data, and if there are, prioritize how to address them. We seek the task force’s assistance in this process. 8

10. HIPAA Omnibus Rule of 2013 Access of Individuals to Protected Health Information – Section 13405(e) provides that when a Covered Entity uses or maintains an EHR with respect to Protected Health Information of an individual, the individual shall have a right to obtain from the Covered Entity a copy of such information in an electronic format and the individual may direct the Covered Entity to transmit such copy directly to the individual's designee, provided that any such choice is clear, conspicuous, and specific. 1 – Section 13405(e) of the HITECH Act strengthens the HIPAA Privacy Rule's right of access as contained in 164.524, with respect to Covered Entities that use or maintain an Electronic Health Record ("EHR"). 2 9

11. CMS Meaningful Use Stage 3 Final Rule CMS included 2 objective in the Meaningful Use Stage 3 Final Rule 1, that references the use of APIs: – Objective 5: Patient Electronic Access to Health Information 2 – Objective 6: Coordination of Care Through Patient Engagement 3 CMS reiterates in these objectives that there are four basic actions that a patient (or patient-authorized representative) should be able to take: – View their health information; – Download their health information; – Transmit their health information to a third party; and – Access their health information through an API CMS believes that these actions may be supported by a wide range of system solutions, which may overlap in terms of the software function used to do an action or multiple actions, including facilitating provider-to-provider exchange as well as patient access CMS proposed for the Patient Electronic Access objective to allow providers to enable API functionality in accordance with the proposed ONC requirements in the 2015 Edition proposed rule 10

12. 2015 Health IT Certification Criteria – API Access ONC established new 2015 Edition criterion at § 170.315(g)(7) that requires health IT to demonstrate it can provide application access to the Common Clinical Data Set via an application programming interface (API) Certification criterion is split into three separate certification criteria with each individual criterion focused on specific functionality to enable modularity and flexibility in certification. The three certification criteria will be adopted at §170.315(g)(7), (g)(8), and (g)(9): – (g)(7) Application access—patient selection – (g)(8) Application access—data category request – (g)(9) Application access—all data request 11

13. 2015 Health IT Certification Criteria – API Access To be certified for the “API” criteria, three privacy and security criterion must also be met: – Section 170.315(d)(1) “authentication, access control, and authorization;” – Section 170.315(d)(9) “trusted connection;” and – Section 170.315(d)(10) “auditing actions on health information” or § 170.315(d)(2) “auditable events and tamper resistance.” 12

14. Public Comments 13

15. 2015 Health IT Certification Criteria – Summary of Public Comments Related to API Access 14 A total of 51 public comments received related to the API Certification Criteria from a variety of stakeholders 25 comments focused on the concern that without specifying a standard API, we wont achieve interoperability. This is important to note but it is outside the scope of the API Task Force. 19 comments received relating specifically to privacy and security issues: Vendors – 10 Comments (20%) Provider Organizations – 2 Comments (4%) Independents – 2 Comments (4%) Professional Associations – 2 Comments (4%) Academic Institutions – 1 Comment (2%) Advocacy Groups – 1 Comment (2%) Consulting Firms – 1 Comment (2%)

16. 2015 Health IT Certification Criteria – Summary of Public Comments for the Proposed Rule General Comments Related to Privacy and Security: – It is vital that privacy and security measures are applied to access of patient health information in a manner that is aligned with patient privacy expectations. 15

17. 2015 Health IT Certification Criteria – Summary of Public Comments for the Proposed Rule General Comments Related to Privacy and Security (Cont’d): – There is a concern around health care organizations exposing a public-facing API (providing access to PHI) around security, configuration, hosting and maintenance. – Exposing such an API could significantly increase the chance of successful security attacks, potentially impacting not only the health care organization itself but also those applications and organizations accessing the API. – Providers and institutions currently struggle with managing SSL certificate management, monitoring and alarming on service availability, maintenance, and managing intentional or unintentional misuse. 16

18. 2015 Health IT Certification Criteria – Summary of Public Comments for the Proposed Rule Implementation Specific Comments Related to Privacy and Security: – An API may not need to include a means of establishing a trusted relationship; because through patient portals the relationship could be handled “within the confines of a known entity, the patient” – and that patient manages the authorization of API access that is specific to them. – Query for a patient’s token is one means but should not be the required means – alternatives exist such as an application passing the API a patient identifier, or posting the patient’s identity. Other alternatives may offer more effective and trusted patient matching and transaction design. 17

19. 2015 Health IT Certification Criteria – Summary of Public Comments for the Proposed Rule Implementation Specific Comments Related to Privacy and Security (Cont’d): – Multiple commenters suggested OAuth and/or some combination of OAuth, Open ID Connect, and UMA as standards for authentication/authorization. – HTTPS standard has found widespread success as an application layer protocol for APIs, and APIs should be accessible through this format due to its wide support and use. 18

20. Recommendations 19

21. HITPC Recommendations related to Privacy and Security Risks Associated with APIs Accessing PHI Risks associated with increased patient access to data 1 – Heightened security risks from increasing numbers of applications connecting to EHRs – Vendors’ unclear or incorrect understanding and implementation of privacy and security legal requirements – Vendors’ inadequate or incorrect implementation of entity’s privacy and security policies – Use of app/device with weak security controls – Use of app/device without privacy policy, or with unclear policy, or with policy that shares data liberally with third parties or allows broad uses 20

22. HITPC: Privacy and Security Workgroup Recommendations ONC is already working with FTC and OCR to develop mobile health best practice guidance for developers which will eventually promote protection of user data. The Privacy and Security Workgroup urged these agencies to work quickly to widely disseminate this guidance so it would be useful for Stages 2 and 3 of MU. Guidance should include: – Guidance for app developers on best practices for protecting privacy and security of information collected by the app and connecting with EHRs covered by HIPAA. 21

23. HITPC: Privacy and Security Workgroup Recommendations In addition, they recommended development of guidance for patients/consumers and providers. Guidance should include: – Checklists for consumers on what to look for in a privacy/data use policy; – Mechanisms for consumers to compare privacy policies across apps (similar to ONC's model PHR notice) 2 – How to do a security risk assessment on patient app/device connections (such as through the API) and the extent to which a provider may reject a patient’s request for electronic access due to a perceived security risk for the provider; – The extent to which a provider may reject a patient’s request for electronic access in the absence of a security risk. 22

24. HITPC: Privacy and Security Workgroup Recommendations ONC and CMS should provide specific guidance to address transmit-related risks and in making VDT and APIs available to patients. Such guidance should address: – When liability for data shifts from providers to patients, and the extent to which providers must make patients aware when patients take responsibility for protecting data – Best practices for counseling patients on assessing and managing privacy and security risks – Responsibilities of vendors to include the CEHRT security safeguards in VDT and API modules 23

25. HITPC: Privacy and Security Workgroup Recommendations Such guidance should also address (cont’d): – Technical approaches vendors may take to further protect data (for example, “just in time” notices before download and transmit that should be able to be turned off by the patient after the first notice, and non-caching of data) – ONC also should act on prior recommendations on for guidance on identity proofing and authentication of patients, family members, friends and personal representatives 24

26. HITPC: Privacy and Security Workgroup Recommendations Timely guidance is needed – but is not enough. We call for further exploration of a multi-stakeholder (including industry and patients) developed program for evaluating patient-facing health apps. – The Workgroup sees value in a program to evaluate such apps – but believes they should be evaluated on a range of aspects, including: Privacy and security Usability for consumers/patients Clinical validity 25

27. HITPC: Privacy and Security Workgroup Recommendations Such guidance should also address (cont’d): – The effort should leverage the guidance developed by federal government entities (including ONC, CMS) – Even a voluntarily adopted guidelines could have some teeth: The FTC under its existing FTCA authority - can enforce voluntary best practices for those who adopt – The evaluation effort also could enhance transparency about privacy and security practices 26

28. HITPC: Consumer Workgroup Recommendations We recognize APIs are a strong technical solution that: – Offer consumers more choice and better uses of health information for self- care, care management and family caregiving; – Break down silos in health care; and – Allow patients to use their health information in apps suited to their needs. 27

29. HITPC: Consumer Workgroup Recommendations While we recommend use of both APIs and VDT/portal, the following things must happen: – Adoption and implementation of the API-related recommendations of HITPC Privacy & Security Workgroup; – Educating small practices and hospitals about APIs and their privacy and security implications (per August 16, 2011 HITPC transmittal letter) so they may educate patients and families accordingly; – Consideration of certifying additional functions such that APIs may be used for functions beyond download/transmit; and – Requirement that APIs are publicly available. 28

30. Discussion/Questions 29

31. Next API Task Force Meeting Friday, December 4 th 11:30am-1:00pmET – API overview presentation – Introduce virtual hearing, discuss goals and outcomes – Review panelist questions 30