kickoff meeting josh mandel, co-chair meg marshall, co-chair november 30, 2015 api security task...

Kickoff Meeting

Josh Mandel, Co-ChairMeg Marshall, Co-Chair

November 30, 2015

API Security Task Force

2

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

Agenda

3

API Task Force Membership

Member Organization RoleJosh Mandel Harvard Medical School Co-ChairMeg Marshall Cerner Co-ChairLeslie Kelly Hall Healthwise MemberRobert Jarrin Qualcomm Incorporated MemberRajiv Kumar Stanford University School of Medicine MemberRichard Loomis Practice Fusion MemberAaron Miri Walnut Hill Medical Center MemberDrew Schiller Validic MemberAaron Seib National Association for Trusted Exchange MemberDavid Yakimischak Surescripts MemberIvor Horn Seattle Children's MemberFederal Ex OfficioLinda Sanches, Office for Civil Rights- Health and Human ServicesONC StaffJeremy MaxwellRose-Marie Nsahlai, Staff LeadMaya 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.

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…4

Task Force Charge and Questions

5

• 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.

Out of Scope Issues

• Terms of Use• Licensing Requirements• Policy Formulation• Fee Structures• Certifying Authorities• Formulation of Standards

6

Proposed Workplan

7

Meetings Task

Monday, November 30th 10:30am-12:00pmET • Kick-off Meeting• Introduction, review and refinement of charge, review of workplan

Friday, December 4th 11:30am-1:00pmET • API overview presentation• Introduce virtual hearing, discuss goals and outcomes

• Review panelist questions

Friday, December 11th 12:00-1:30pm ET • Refine panel structure and questions

Offline Administrative Call - TBD • Identify and refine hearing presenters

Tuesday, January 12th 10:30am-12:00pm ET • Prepare for Virtual Hearings

Tuesday, January 26th 12:00-5:00pm ET • Virtual Hearing (two sessions will be held on the calendar for the moment)

Thursday, January 28th 12:00-5:00pm ET • Virtual Hearing (two sessions will be held on the calendar for the moment)

Tuesday, February 9th 10:30am-12:00pm ET • API Task Force Call

Monday, February 22nd 11:30am-1pm ET • API Task Force Call

Tuesday, March 8th 10:30am-12:00pm ET • API Task Force Call

Tuesday, March 22nd 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 12th 10:30am-12:00pm ET • API Task Force Call

April 19 Joint Committee Meeting • Present final recommendations

Background Information

8

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.

9

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

10

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 Information2

– Objective 6: Coordination of Care Through Patient Engagement3

• 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

11

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 12

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.”

13

Public Comments

14

2015 Health IT Certification Criteria – Summary of Public Comments Related to API Access

15

• 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%)

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.

16


• 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.

17


• 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.

18


• 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.

19

Recommendations

20

HITPC Recommendations related to Privacy and Security Risks Associated with APIs Accessing PHI

• Risks associated with increased patient access to data1

– 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

21

HITPC: Privacy and Security WorkgroupRecommendations

• 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.

22


• 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.

23


• 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 modules24


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

25


• 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

26


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

27

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.

28

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.

29

Discussion/Questions

30

Next API Task Force Meeting

• Friday, December 4th 11:30am-1:00pmET – API overview presentation– Introduce virtual hearing, discuss goals and

outcomes– Review panelist questions

31

kickoff meeting josh mandel, co-chair meg marshall, co-chair november 30, 2015 api security task...

Documents