A task force of the Office of the National Coordinator for Health IT (ONC) has prepared a series of recommendations to address privacy and security concerns around application programming interfaces (APIs), technology that allows one software program to access the services provided by another software program. The task force said it did not identify any “show-stopping” barriers that would prevent the deployment of APIs within the timelines ONC has set for 2015 certification criteria or Meaningful Use stage 3.
In its 2015 Edition of Health IT Certification Criteria (2015 CHIT), ONC established three new criteria that requires certified health IT to demonstrate the ability provide a patient-facing app access to the Common Clinical Data Set via an API. In parallel, CMS included two objectives in MU Stage 3 that reference the use of APIs involving patient electronic access to health information and coordination of care through patient engagement.
After hearing testimony from many stakeholders, the task force found that although access to health data via APIs does require additional considerations and regulatory compliance needs, existing standards, infrastructure and identity-proofing processes are adequate to support patient-directed access via APIs today.
It recommends that ONC analyze the feasibility of a single, simple, comprehensive oversight framework mechanism that would address the needs of the patient-directed API ecosystem. “We recognize implementation of such a framework may require Congressional action; however, using its role as advisor for all things health IT, ONC should seek to harmonize conflicting, redundant and confusing laws that govern access to health information,” the task force said.
As part of that oversight framework, ONC should coordinate with the relevant agencies a single location for all API actors (EHR API developers, app developers, providers and patients) to access in order to become educated and to ask questions about the oversight and enforcement mechanisms specific to patient-directed health apps, as well as their specific rights, obligations and duties. For instance, the task force said, patients should have one place to access in order to log complaints regarding an app’s behavior, and app developers should have one place to access in order to log complaints that could launch investigations regarding a provider or an EHR API developer’s behavior regarding information blocking.
Here is the basic use case the task force considered:
App Developer builds an app that can benefit from patient data accessed via an API-based connection to EHR data. App Developer registers App with Hospital or its EHR. Patient becomes aware of App, reviews App's data use and privacy policies and decides to connect App to her EHR data at Hospital. Patient signs into Hospital’s portal, which displays an authorization screen. Patient agrees to share some or all of her EHR data for some duration of time with App, and Hospital records this decision. Hospital’s portal sends Patient back to App, and App gets a unique, time- and scope-limited access token for Patient. App can use the token to access Patient's authorized EHR data for some duration of time in keeping with Patient’s approval.
Within that use case, it identified eight topics for which it made recommendations. For instance, its recommendation about types of apps and organizations that provide them is that ONC should coordinate with the relevant agencies and explicitly state in formal guidance that the type of app, and the kind of organization that developed it, are not considerations with respect to patient access. The only relevant concerns should be technical compatibility (i.e. app works with the API technical specifications) and patient choice.
Other key recommendations in the task force’s report:
• ONC should supports a Model Privacy Notice for app developers. It should clearly define who is responsible for what (individual, app developer, provider, API developer), including example indemnification clauses where applicable.
• ONC should not require centralized certification or testing of apps. Instead, ONC should encourage a secondary market in app endorsements.
• ONC should clarify that while API Providers may impose security-related restrictions on app access (e.g., rate-limiting, encryption, and expiration of access tokens), it is inappropriate for API providers to set limitations on what a patient-authorized app can do with data downstream.
• ONC should expand certification criteria to require CHIT to make API access audit logs available to patients through an Accounting of Disclosures via the portal. This would show patients a list of all active app authorizations in the portal; include the ability for the patient to revoke any app authorization; and show patients a list of which apps have accessed their data via the API (including relevant details).
The task force’s findings will be presented to a joint Health IT Policy and Standards Committee meeting on Tuesday, May 17.
