The Centers for Medicare and Medicaid Services (CMS) and the Office of the National Coordinator (ONC) released the final rules for the ERH Incentive Program Meaningful Use Stage 3, as well as the related 2015 EHR certification criteria last week. Stage 3 is set to begin as an optional requirement for eligible physicians and eligible hospitals in 2017, with mandatory participation in 2018.
One requirement that received considerable attention is the requirement for API utilization. This requirement is contained under the view, download, and transmit (VDT) criteria. With Stage 2, five percent of all unique patients had to view, download, or transmit to a third party their health information within a given timeframe. This was achieved using a patient portal. With Stage 3, now an API figures into the equation.
CMS explains in the rule, “The Stage 3 objective for Patient Electronic Access is not a ‘patient portal’ versus ‘API’ requirement or a requirement to support two patient portals.”
The rule goes on to explain that a patient should be able to take four basic actions. As included in Stage 2, the patient should have the ability to view their health information, download their health information, and transmit their health information to a third party. With Stage 3, the fourth action is the ability to access their health information through an API.
{{cta(‘aa1521cb-5277-4f92-afda-230e28538341’)}}
The reasoning behind this is flexibility for the patient. The hope is that APIs will 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. The API itself could complement a specific provider-branded patient portal, but on the other hand it could make to portal essentially unnecessary if patients were able to use apps designed to interact with an API that enabled their ability to view, download, and transmit.
One big question remains: What will an API look like? If HL7 FHIR would be farther along in becoming normative, then FHIR would be the obvious answer. But with the FHIR definition still in a draft state, the ONC was likely hesitant to write it into the rule.
But as a software vendor, it still probably makes sense to seriously consider FHIR as the API that they would release with a product. One option would be to create an API that is completely custom for the given product. While this allows the vendor to completely customize the solution for its product, it is not efficient for app developers who are trying to write apps for a variety of HIS solutions. Because of this, it is likely that vendors will lean towards developing their API around FHIR even in its draft state. If the industry is moving the direction of FHIR, it is an easier transition from a draft-FHIR API to a normative API than from a completely customized API solution.
While the final rule did not specifically mandate HL7 FHIR, it nonetheless has gone a long way to promoting its use through the more generic API requirement. Over the next year or two it will be interesting to see how two things develop: (1) will patient portals fade away in favor of VDT apps, and (2) will HL7 FHIR become the de facto required ‘generic’ API.
