API’s and Stage 3 Meaningful Use: What Does it Mean for Patient Engagement Platforms of the Future? By Jeff Oberlander, VP of Engineering The Centers for Medicare & Medicaid Services (CMS) released its proposed guidelines for Stage 3 Meaningful Use (MU) and there are some exciting implications for how patients will one day be able to access their electronic health records. Namely, the guidelines call for more flexibility in this regard, and introduce the notion of an Application-Program Interface (API). What does this mean in terms of patients being able to better engage in their own healthcare?
Stage 2 Requirements Allow Patients Electronic Access to their Health Information
To put Stage 3 into context, let’s take another look at Stage 2. Stage 2 Meaningful Use was the impetus to giving patients access to their health information electronically. Stage 2 required that the healthcare organizations provide the ability for a patient to view, download or transmit their health record electronically within 24 hours of this information becoming available to that patient’s provider. On the surface, this was a great thing – a patient’s timely access to their own health information facilitates patient engagement, the lynchpin of realizing better health outcomes through digital health. This is especially true for cancer patients, who often receive care across multiple clinics, providers and geographies.
Unfortunately, providers didn’t have many options to satisfying this criterion, beyond their EHR vendor built patient portal. Because patient-friendly software is not the core business of EHR vendors, most built patient portals just to meet the bare minimum requirements for MU. These tools can be clunky and hard-to-use, and do little to invite patient engagement.
A portal that facilitates patient engagement takes a dedicated team to build and get right. To be useful, it has to be built with the patient experience in mind. This is where Stage 2 missed the mark, and true patient engagement has yet to be realized. The API initiative in Stage 3 presents a great opportunity to correct this. However, it will come with its own big challenges.
How is an API proposed to be used in the context of Meaningful Use Stage 3?
In the guidelines for Meaningful Use Stage 3 proposed thus far, providers would be able to support patient access to their personal health information through the use of an API. A provider using an API would not be required to purchase and implement a patient portal. Rather, the provider would only need to enable the API functionality, and provide patients with detailed instructions on the steps required to access their information. In a recent blog post, Jonah Comstock asserts that an API could replace the patient portal for some providers.
What will it take to make this successful?
But let’s examine what an API actually is. It is a set of routines, protocols, and tools for building software applications. In other words, it is not something patients can use on their own.
The bottom line is that a useful API requires technical work on the back-end, and ongoing support on the front-end. Currently, there is nothing in the proposed rule that requires the API to come with either of these in order for EHR vendors to check this box and call it built. In this regard, the proposed guidelines allow for EHR vendors to create an API that is hard to use, error prone, and technically challenging for experienced software engineers, let alone patients. This scenario would be a step backwards on the path towards facilitating patient engagement.
To make it useful for patients, APIs will require user interfaces developed by dedicated software developers. Software companies exist that are well-suited to build these applications with the patient experience in mind.
In order for an API to be successful, it needs to be user-friendly and well-documented. It requires sufficient support and support tools. And it needs to implement clear error handling. Good documentation will come in the form of a clear outline of the API interface itself – inputs, outputs, errors, etc. It will also require sample code and applications that demonstrate a successful use of the API calls. At minimum, good support comes in the form of a community forum, but often comes with a means of sending questions to support staff – either an email address or a ticketing system. What is the role of EHR vendors and application developers? In the web world, we often interchange API and web services. In essence, a web service is a delivery mechanism for an API over the Internet. But nothing about the definition of an API says that this has to be the transport. In other words, an EHR vendor could, in theory, create an API that requires even deeper knowledge of their platform, instead of user-friendly, well-known standards such as RESTful web services. Hopefully, vendors will provide the latter.
Enter Navigating Cancer
While the API proposal does not require EHR vendors to have an API (they can still provide a portal instead), it does free them up to let 3rd parties, who are dedicated to building patient-centered software, create a great experience for their customers. Importantly, it allows companies like Navigating Cancer the ability to integrate with any provided API.
At Navigating Cancer, we started our business in 2008 to create a better way for cancer patients to connect and engage in their healthcare journey. Today, we are the leading patient engagement platform and mobile care management solution for cancer centers across the United States. For patients, Navigating Cancer provides a single, comprehensive hub that seamlessly interoperates with any EHR system, enabling patients to stay informed, connected and engaged in their own health across the care continuum of multiple clinics, caregivers and geographies. For providers, Navigating Cancer offers a convenient, scalable solution for care management and engagement, a vital platform for the evolution to value-based care, and an agile means of satisfying current requirements for Meaningful Use, Commission on Cancer and new payment reform models.
As software developers at Navigating Cancer, our access to EHR data has proven challenging at times. We have tight integrations with some, and no integration with others, which has left our customers with a portal they love, but in a bind when their current EHR is closed off. This lack of access and interoperability on the part of EHR vendors has hindered our ability to provide patients with a comprehensive view of their health records, right in one place, on our portal.
At Navigating Cancer, it is our hope that the final rule provides more guidelines and requirements for certified vendors to build APIs. If done correctly, this could be the start of data liquidity, with patients finally being able to control and aggregate their own health information across the care continuum. Stage 3 is an exciting development in the world of Meaningful Use, so long as the certification criteria for the API sufficiently cover the quality and support capabilities necessary to successfully realize patient engagement.