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

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.

From the patient perspective, an API enabled by a provider will empower the patient to receive information from their provider in the manner that is most valuable to the patient. Patients could collect their health information from multiple providers and potentially incorporate all of their health information into a single portal, application, program, or other software requirements of the API. Providers are expected to provide patients with detailed instructions on how to authenticate their access through the API and provide the patient with supplemental information on available applications that leverage the API. (CMS also stated that it wouldn’t expect providers to charge patients for access to their health information through an API to offset their costs.)

As far as timing goes, CMS said it disagrees that the API functionality cannot be implemented successfully by 2018 “as the technology is already in widespread use in other industries and API functions already exist in the health IT industry.”

All of this should be a boon for the FHIR (Fast Healthcare Interoperability Resources) standard development community and the Argonaut Project, working on API-related standards, as well as for the broader community of mobile app and personal health record developers. With barriers to patient access to their data coming down, patients will finally be able to create their own portals, separate from any health system and share that data with whomever they want.

In patient education requirements, the physician or hospital must use clinically relevant information from CEHRT to identify patient-specific educational resources and provide electronic access to those materials to more than 35 percent of unique patients seen by the EP or discharged from the eligible hospital or CAH inpatient or emergency department during the EHR reporting period.

CMS didn’t back down as it finalized measures related to “Coordination of Care through Patient Engagement.” Although it adjusted some threshold levels, providers must attest to all three measures and must meet the thresholds for at least two measures to meet the objective.

• Measure 1 says that during the EHR reporting period, more than 10 percent of all unique patients seen by the EP or discharged from a hospital actively engage with the electronic health record made accessible by the provider and either: (1) view, download or transmit to a third party their health information; or (2) access their health information through the use of an API, or a combination of the two.

• In Measure 2, for more than 25 percent of all patients seen by the EP or discharged from the hospital during the EHR reporting period, a secure message was sent using the electronic messaging function of CEHRT to the patient (or the patient-authorized representative), or in response to a secure message sent by the patient or their authorized representative. For an EHR reporting period in 2017, the threshold for this measure is 5 percent rather than 25 percent.

• In Measure 3, patient-generated health data or data from a nonclinical setting is incorporated into the CEHRT for more than 5 percent of all unique patients seen by the physician or discharged from the hospital inpatient or emergency department during the EHR reporting period.

That patient-generated health data goal is a good one but it is going to be a challenge to meet, I predict!

There is much more to discuss about other Stage 3 objectives, including health information exchange and public health. But we’ll save those for another day!