Medical Informatics at Cerner Corporation [NASDAQ:CERN]

Consumers have greater expectations for personalization when seeking care than ever before. It’s up to the health IT industry to catch up with these demands and deliver access to patient health information anytime, anywhere. The phrase, “View, Download And Transmit,” (VDT) is a now-familiar Meaningful Use (MU) requirement that provides consumers with multiple options for access to their Electronic Health Record (EHR) data. VDT is only the beginning. Application Programming Interfaces (APIs), which have been the backbone of the ecosystems that have revolutionized many other industries, are coming soon to healthcare. Providers need to get up to speed on what’s required and have a plan to meet those requirements.

APIs offer direct programming access to the underlying health IT system data and enable app developers to create tools that can ingest a patient’s EHR data in order to provide new services to consumers. Through projects such as SMART® on HL7 FHIR®, the combination of the SMART HealthIT® and HL7 FHIR® standards, providers are becoming familiar with APIs that support customization of the EHR experience. However, API access is not limited to providers. A new class of APIs will give consumers the ability to access their health information on demand via apps that they choose. These APIs are emerging not simply based on consumer expectations, but also are driven by major regulations and incentives coming into effect in the near future.

The Office of the National Coordinator for Health Information Technology (ONC) 2015 Edition requirements, which defines numerous interoperability standards for EHR prodicts, will start being enforced in 2018. Under Meaningful Use Stage 3 (MU3) incentives, patients must be granted access to EHR portal-hosted APIs upon request. ONC’s expectation is that patients will be able to select apps which can then be connected to the patient’s portal account. The patient can use their portal login information to authorize the app to download their health data from the EHR. Unlike provider-facing APIs, a consumer’s app can only access the patient’s own data, but otherwise, the provider and patient API specifications are very similar.

"A new class of APIs will give consumers the ability to access their health information on demand via apps that they choose"

Granting patients access to EHR data through the use of APIs was a major change, so ONC designated a joint task force (co-chaired by Meg Marshall, senior director of health policy with Cerner, and Josh Mandel, formerly with Boston Children’s) to survey various stakeholder opinions and concerns. The task force concluded there were no “show stopping” barriers that would prevent the deployment of APIs within the timelines for ONC’s certification standards and MU3.

The task force also recommended that ONC continue its pursuit of an API strategy as another important mechanism for enabling patient choice and promoting a more efficient healthcare marketplace.

Advancement with APIs and real-life application is becoming reality. Recently, some of the largest health Information Technology (IT) suppliers in the country, in conjunction with The Department of Health and Human Services’ Office of the National Coordinator for Health Information Technology (ONC), coordinated a live demonstration of consumer-controlled applications accessing patient data.

Over the course of several months Cerner identified and pursued ONC’s challenge to give patients the ability to download their own medication prescriptions from several different EHR suppliers, through EHR APIs. Cerner’s team was able to leverage the work already underway on Cerner’s own implementation of a FHIR API, called Cerner Ignite APIs for Millennium and the Cerner Open Developer Experience (or code). In addition, we were able to combine our efforts with Boston Children’s Hospital, where we already participated and sponsored the Massachusetts’ state digital health accelerator called PULSE@ MassChallenge. This involvement connected use with leading app companies.

Just after two months, the app developers were able to successfully connect applications to a public Cerner test system hosting mock patient data. This workflow was demonstrated in a showcase session hosted by ONC. We hope that the Medisafe app will be one of the first patient applications that Cerner clients can choose to make available to patients this year.

What made this event successful was the high level of collaboration between providers, suppliers and third-party app developers. Standards-based APIs enable competitors and collaborators to work together for a common goal to create usable, practical applications for today’s patient market.

In the near future, one important use of the new consumer access APIs will be demonstrated through the Sync for Science (S4S) pilot program. In February 2016, the National Institutes of Health (NIH), in collaboration with the ONC, launched S4S to enable individuals to access their health data and then voluntarily share it with researchers associated with the NIH Precision Medicine Initiative (PMI). The PMI, now known as the “All of Us Research Program,” intends to create a 1 million-member volunteer research cohort, with the expectation that many of the participants will choose to “donate” their health data directly to the PMI.

Cerner is one of several EHR suppliers involved in S4S working to verify that these APIs can accurately retrieve the patient’s data. The APIs used for S4S are the same ones that will help our clients meet the Meaningful Use requirements for API-based patient access.

Cerner is proud to be a leader in the movement to enable consumers to have more control of their healthcare data. However, as an industry, we should enter this new “app era” cautiously, because there are still numerous unanswered technical and policy questions to be worked out.

For example:

• How will patients know which apps are medically useful, and won’t use the patient’s sensitive health data in some unacceptable way?
• How will providers know which apps to recommend to patients? And what should a provider do if the paitent wants to use an app that the provider considers harmful?
• Should EHR vendors automatically trust any app that claims API compliance, or should a “certification” process be followed to ensure that that app does not compromise system integrity?

We don’t have answers to all these questions yet, but we think it’s worth a broader discussion. It’s not a question of whether consumer API access is coming, but when—and our industry needs to be prepared.