Skip to content Skip to navigation

First Look at Stage 3: CMS Sticks to Its Guns on APIs, Patient Engagement

October 7, 2015
| Reprints
Retaining API requirement a victory for patient electronic access

There are so many aspects and details that one could zero in on in the hundreds of pages of rulemaking around the meaningful use program that came out Oct. 6 that it is difficult to know where to begin. But my interest was drawn to the patient engagement requirements in Stage 3, and the addition of application programming interface (API) functionality. After poring over the details, it appears that CMS stuck to its guns in asking providers to significantly enhance their patient engagement processes by 2018.

Much of the documentation released Oct. 6 deals with simplification, alignment and additional flexibility in terms of timing and exceptions. It is obvious from reading through the CMS publication that the whole MU regime had grown horribly complex and confusing to providers trying to participate. The feds dug that hole for themselves and are now trying to rectify the situation after hearing so many complaints.  From the initial publicly released comments by industry associations and early reactions the our editor in chief Mark Hagland received from CIOs and CMIOs, it appears that they have mollified people to some extent. (There were also changes to threshold requirements in Stage 3 for CPOE and clinical decision support in some instances, which again demonstrates that CMS is responding to comments about the difficulty of achieving particular thresholds and their impact on patient safety and clinical work flow.)

But because there had been so many complaints about efforts to improve patient engagement, I wondered if CMS might back away from some fairly ambitious goals laid out in the Stage 3 proposed rules. You will recall that after hearing so many complaints about the view, download and transmit requirements in Stage 2, CMS modified those so that to meet the requirement only one patient had to use the VDT function. CMS is keeping that low threshold in the 2015-2017 requirements.

But in the Stage 3 requirement for 2018, there are measures related to patient access to data and patient engagement, and the thresholds remain high. First, for more than 80 percent of all patients seen by the physician or discharged from the hospital or emergency department, the patient is provided timely access to view online, download, and transmit his or her health information; and the patient’s health information is available to access using any application of their choice that is configured to meet the technical specifications of the API (application programming interface) in the provider’s certified EHR.

CMS further specified that any patient health information must be made available to the patient within 48 hours of its availability to the provider for a physician and 36 hours of its availability to the provider for an eligible hospital.

As the document noted, CMS got lots of questions and negative feedback on this API provision. Many commenters requested clarification on if the API would replace their patient portal or be a part of it or an additional website. Some commenters expressed concern about supporting a “second patient portal.” Many expressed concern that the API technology and certification by ONC is not mature enough yet. Some asked CMS to make the API functionality optional in Stage 3, but in response to these comments, CMS went into great detail explaining why it thinks APIs are important for patient engagement, and that 2018 is not too early for it to happen.

CMS said that the Stage 3 objective for patient electronic access is not a "patient portal" versus "API" requirement or a requirement to support two patient portals. Instead, this proposed objective is supporting four basic actions that a patient 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 further explains that not only does it not require a "patient portal" format for VDT, it also does not advocate a limit on innovation in software or systems designed to allow patients to access and engage with their health information. “We believe that the efficacy of the health IT environment now and the potential for future innovation, relies on the establishment of clear standards and functionality requirements paired with the flexibility.”

This intent to allow for innovation and change within the scope of health IT development is part of a broader goal to lay the foundation for healthcare systems to support the patient and provider. An API is a set of programming protocols established for multiple purposes. APIs may be enabled by a provider or provider organization to provide the patient with access to their health information through a third-party application with more flexibility than is often found in many current "patient portals."

From the provider perspective, an API could complement a specific provider “branded” patient portal, CMS noted, or could also potentially make one unnecessary if patients were able to use software applications designed to interact with an API that could support their ability to view, download, and transmit their health information to a third party.