The Centers for Medicare and Medicaid Services (CMS) and the Office of the National Coordinator (Office of the National Coordinator for Health Information Technology (ONC) – Located within the Office of the Secretary for the U.S. Department of Health and Human Services (HHS), the Office of the National Coordinator (ONC) coordinates nationwide ...) released the final rules for the ERH Incentive Program Meaningful Use Stage 3, as well as the related 2015 Electronic Health Record (EHR), as defined in Defining Key Health Information Technology Terms (The National Alliance for Health Information Technology, April 28, 2008): An electronic record of health-related information on an individual that conform... 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.
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 FHIR stands for Fast Healthcare Interoperable Resource. This emerging standard combines the best features of HL7 V2, HL7 V3, and CDA, while leveraging the latest web service technologies. The design of FHIR is based on RESTful web services. With REST... would be farther along in becoming normative, then An HL7 standard that is short for Fast Healthcare Interoperability Resources and pronounced “Fire”. The standard defines a set of “Resources” that represent granular clinical concepts. The resources provide flexibility for a range of healthca... 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 Hospital Information System (HIS) is the main system in a hospital used by most caregivers. Sends ADT broadcasts to all ancillary applications. The HIS is typically the patient administrative system and order entry system for a hospital. Synonyms: Ho... 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 is a Standards Developing Organization accredited by the American National Standards Institute (ANSI) to author consensus-based standards representing a board view from healthcare system stakeholders. HL7 has compiled a collection of message form... 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.Tags: FHIR, Healthcare Interoperability, Meaningful Use HiTech, radiology