From the experience of provider response to Stage 2 of meaningful use, it was a safe bet that patient engagement measures would be the least popular aspect of Stage 3 proposals. And initial reactions are that boosting the “view, download, and transmit” threshold from 5 percent to 25 percent raised a lot of eyebrows.
Also, the proposal that more than 15 percent of patients contribute patient-generated health data or data from a non-clinical setting into the certified EHR technology during the EHR reporting period looks like a huge mountain to climb for most providers. Of course, in the past, CMS has made bold proposals in the NPRM and then sometimes after strongly negative responses from providers, they backed down (although sometimes they didn’t, too).
But another thing that stood out in the Notice of Proposed Rulemaking (NPRM) in terms of patient engagement is the nod to work going on around application programming interfaces and FHIR (Fast Healthcare Interoperability Resources).
Last fall the ONC JASON Task Force recommended that ONC should consider narrowing the focus of Stage 3 to free up vendor and provider resources to implement and adopt public application programming interfaces. The task force state that it believed that FHIR (Fast Healthcare Interoperability Resources) and FHIR profiles are the best candidate API approach to data-level access to healthcare data. They recommended that the first use of the public API model should be in support of data-sharing networks that promote EHR-to-EHR interchange and consumer access to the core data services via patient portals.
Although the recommendation about narrowing Stage 3 to interoperability was rejected, CMS did include APIs in its proposal (although it referred to them as “application-program interfaces” instead of application programming interfaces).
“We are proposing an additional functionality, known as application-program interfaces (APIs), which would allow providers to enable new functionalities to support data access and patient exchange.
As the NPRM states, “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 often found in many current patient portals. From the provider perspective, using this option would mean the provider would not be required to separately purchase or implement a patient portal, nor would they need to implement or purchase a separate mechanism to provide the secure download and transmit functions for their patients because the API would provide the patient the ability to download or transmit their health information to a third party.”
If the provider elects to implement an API, the provider would only need to fully enable the API functionality, provide patients with detailed instructions on how to authenticate, and provide supplemental information on available applications that leverage the API.
The 2015 Edition proposed certification proposed by ONC would establish API criteria that would allow patients, through a third-party application, to pull certain components of their unique health data directly from the provider's EHR, and potentially could—on demand—pull such information from multiple providers caring for a patient.
So it will be interesting to see if this Patient Electronic Access objective begins the process of creating a third-party ecosystem of companies helping patients gather their own data from multiple providers to avoid the problem of siloed portals from multiple providers. No doubt, the creation of an API-based health data ecosystem will take several years, but you have to start somewhere.
Here is one early positive reaction: “The Patient API change in and of itself is elegant. It allows patients to control more of their information while expanding interoperability,” said Joel White, executive director of the Health IT Now Coalition, in a prepared statement. (The Health IT Now Coalition includes patient groups, provider organizations, employers and payers.)
The Argonaut Project, which is seeking to accelerate HL7’s work on open APIs and FHIR profiles, is working on use cases and a security implementation guide and expects to have those done in time for inclusion in the May 2015 HL7 FHIR Draft Standard for Trial Use revision 2 ballot.
