The Centers for Medicare and Medicaid Services (CMS) and the Office of the National Coordinator (ONCOffice of the National Coordinator for Health Information Technology (ONC) – Located within the Of... More) released the final rules for the ERH Incentive Program Meaningful Use Stage 3, as well as the related 2015 EHRElectronic Health Record (EHR), as defined in Defining Key Health Information Technology Terms (The ... More 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.

Request a demo of Corepoint Integration Engine

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 FHIRFHIR stands for Fast Healthcare Interoperable Resource. This emerging standard combines the best fea... More would be farther along in becoming normative, then FHIRAn HL7 standard that is short for Fast Healthcare Interoperability Resources and pronounced “Fire... More would be the obvious answer. But with the FHIRAn HL7 standard that is short for Fast Healthcare Interoperability Resources and pronounced “Fire... More definition still in a draft state, the ONCOffice of the National Coordinator for Health Information Technology (ONC) – Located within the Of... More was likely hesitant to write it into the rule.

But as a software vendor, it still probably makes sense to seriously consider FHIRAn HL7 standard that is short for Fast Healthcare Interoperability Resources and pronounced “Fire... More 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 HISHospital Information System (HIS) is the main system in a hospital used by most caregivers. Sends AD... More solutions. Because of this, it is likely that vendors will lean towards developing their API around FHIRAn HL7 standard that is short for Fast Healthcare Interoperability Resources and pronounced “Fire... More even in its draft state. If the industry is moving the direction of FHIRAn HL7 standard that is short for Fast Healthcare Interoperability Resources and pronounced “Fire... More, 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 FHIRFHIR stands for Fast Healthcare Interoperable Resource. This emerging standard combines the best fea... More, 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 FHIRFHIR stands for Fast Healthcare Interoperable Resource. This emerging standard combines the best fea... More become the de facto required ‘generic’ API.

Tags: , , ,
 Print Friendly