By Dr. Sunny Malhotra, Cardiologist & Founder of Robotic Process Automation Holdings
The healthcare industry has been plagued for years by an interoperability problem that organizations are finding can be solved using robotic process automation (RPA).
Background
To share, exchange, and retrieve information from one electronic medical record (EMR) to another, Health Level Seven (HL7) is the current international not-for-profit organization that provides interface standards. HL7 makes the transfer of laboratory results, pharmacy data, and other medical information possible across various computer systems. The U.S. Centers for Medicare and Medicaid Services (CMS) finalized a requirement for the use of Fast Healthcare Interoperable Resources (FHIR), the most recent HL7 standard, among many CMS-regulated payers and providers by July 1, 2021. An RPA FHIR API interface allows us to standardize connectivity within and between organizations to simplify and expedite coordination of care.
HL7 produced several standards to facilitate sharing of healthcare information over the years, in which HL7 V2 became the most widely implemented healthcare standard. HL7 V2 works by allowing different systems like EMRs, radiology imaging archives, and billing systems to transmit information utilizing ASCII text-based messages as a means of communication. This allowed HL7 V2 flexibility and a customizable solution without complex software interface requirements. However, this limits its functionality as the lack of messaging models and specifications compelled organizations to utilize custom coding and interface engines in order to be interoperable. In response, HL7 released V3, a standard with stricter specifications and a more defined framework. Although HL7 V3 overcame many of the shortcomings of HL7 V2, it lacked backward compatibility and required more time and cost to be implemented, which kept it from being widely adopted by healthcare industries.
The CMS Interoperability Rule
Under the new rule, healthcare organizations in the U.S. are required to support increasing interoperability and access to patient-level health data. The CMS interoperability rule mandating FHIR as a specialized standard has compliance implications with financial penalties for those who are non-compliant.
The Act supports customers’ admittance to their patient-level information and the necessity of all wellbeing intends to help API access to the information. The final rule entails that all Medicare Advantage, Medicaid, CHIP, and ACA plans give a Patient Access API, available utilizing third-party applications.
The CMS Interoperability and Patient Access final rule has presented specialized guidelines that require most public payer entities and healthcare organizations to receive FHIR. This includes:
- CMS-directed payers currently should execute and keep a protected Patient Access API permitting the patient to effectively see data about claims utilizing third-party apps.
- Medical services plans and providers should make supplier index data openly accessible in a Provider Directory API.
- CMS-directed payers should provide patient clinical information to different payers when patients’ require it.
RPA solutions may be used to exchange data between disparate systems (e.g., between two different EMR/EHR systems or between a PACS/VNA and an EMR/HER). The solution facilitates the ability of two or more systems or components to exchange and utilize the information; data migration to a cloud platform to be used as a managed repository to expose data to patient- and provider-facing apps; allows for ease of a cloud platform to ingest data and export data into data warehouses for analysis, machine learning (ML) model training, and many other apps.
“An RPA ‘bridge to FHIR’ approach will reduce the cost of data sharing between health organizations by producing reports with information from the Hospital Information System (HIS) and EMR/EHR,” says Jason Warrelmann, global director of Healthcare and Life Sciences at UiPath.
Using FHIR For API
HL7 created FHIR to enhance the interoperability of healthcare systems. FHIR simplifies implementation compared to previous standards. It improves communication efficiency and provides easily understood specifications that enable developers to benefit from open web technologies. FHIR works by building upon previous standards and employs RESTful web services and various data formats such as XML, JSON, and RDA. FHIR can support messaging and documents (such as Clinical Document Architecture) like previous standards. In addition, it utilizes a RESTful API approach, which streamlines data sharing and efficiently onboards new data exchange systems. With one-to-many interface technology instead of a one-to-one interface, this creates the potential for broader interoperability among various systems and devices, including mobile apps and medical devices and wearables proving advantageous to patients as well. FHIR extracts meaningful pieces of data that can be composed of metadata, text, or collections of information that form clinical documents. These pieces of data are termed “resources” and have unique identifying tags that allow devices and applications to access only the required data without any complicated exchange processes, much like that of a website URL.
FHIR also supports sustainable medical applications reusable technologies (SMART). SMART reduces the time and effort to connect healthcare systems. It enables app developers to write an app once and run it anywhere in the healthcare system. Furthermore, SMART has security capabilities through authorization servers allowing providers and patients alike to manage their data without any concern for data breaches.
With the July 2021 Patient Access API mandate, organizations must decide whether to maintain FHIR-based patient access API in-house or to work with the third-party FHIR implementation partner. If you opt for in-house, several factors must be taken into consideration:
- FHIR-based API expertise is non-negotiable. Per the final rule, health plans will need to build an API that empowers their individuals’ claims and clinical information to be delivered as FHIR resources after being mapped to the Common Payer Consumer Data Set (CPCDS) and the United States Core Data for Interoperability (USCDI) elements.
- Capability in application authentication and consumer validation. The standard FHIR mandates that a customer’s request for information can emerge out of any third-party application. Health plans will require the capacity to verify the application and approve the use of the application.
Conclusion
Transitioning interface standards from HL7 V2 to HL7 FHIR will provide clinicians with efficient sharing of patient information and effective clinical decision-making. It can also be utilized by health insurance companies to supplement claims with clinical data to assess risks, decrease costs, and improve healthcare service. FHIR allows patients access and control of their health by providing access to medical information through apps on mobile devices, wearables, and even tablets. FHIR provides effective and efficient interoperability between healthcare systems allowing for streamlined clinical workflows, better patient care, and improved patient outcomes.
* https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index
If you liked this article, please sign up to RPA Today! Registrants will receive our free weekly RPA newsletter updating you on the most recent developments in the Robotic Process Automation, Intelligent Automation and AI space. In addition to news updates, we will also provide feature articles (like this one) with a more in-depth examination of RPA issues for end users and their enterprises.
