Coverage Requirements Discovery with WSO2 Accelerator for Healthcare

Introduction

Coverage Requirements Discovery (CRD) is a process in the US healthcare system that aims to improve the efficiency and accuracy of prior authorization workflows in healthcare. It involves a healthcare provider's system (like an Electronic Health Record or EMR) communicating with a payer's system to determine the specific requirements for a particular service or procedure before it is delivered to a patient. CRD has the potential to significantly improve the healthcare delivery process by reducing administrative burden, improving efficiency, enhancing patient care and by reducing overall costs.

In this blog, we’ll provide an overview of how the WSO2 platform and its healthcare accelerators for rapid development can be used to construct a CRD use case. We’ll showcase the power of Ballerina in building healthcare integration use cases as the above, which can then be combined with the rest of the platform to support healthcare modernization initiatives.

Scenario

Mrs. Jones, a 35-year-old previously healthy female, consults Dr. Good for a new onset headache that began abruptly two weeks prior to her visit. The headaches are severe at times, last several hours, and have been occurring with increasing frequency, now occurring daily. Her physical condition, including a neurological exam, is normal. Dr. Good is concerned about an intracranial process.

Dr. Good decides to order a head CT to check for any masses. While filling out the CT order in the Electronic Health Records (EHR), the system initiates a call to the Coverage Requirements Discovery (CRD) server used by Mrs. Jones' payer, a.k.a the healthcare insurance company. The server is provided with information about the patient, her coverage, and the CT order. Within seconds, the CRD service returns information identifying that a prior authorization request must be completed and submitted, along with a list of the additional clinical documentation required (e.g., progress notes or prior studies). It also provides a link to the required form. Dr. Good launches an app to complete the necessary paperwork, initiating the prior authorization and sending the relevant supporting information to the imaging center as part of the referral.

Architecture

This diagram depicts the overall process of how the CRD flow is engaged during a clinical action. The boundaries between the provider, payer and imaging center are indicated here.

Workflow

The steps below explain how the CRD workflow is engaged in a typical clinical action, such as ordering a CT scan for a patient in EHR systems:

1. The practitioner or medical officer logs into the EHR system and selects the patient to be treated.
2. They choose the CT scan option and input the necessary details to create a CT scan order request.
3. Once all required information is entered, the EHR system automatically triggers a CRD request to the appropriate payer for verification before confirming the order.
4. The payer’s Clinical Decision Support (CDS) server responds with CDS card recommendations within seconds.
5. The practitioner or medical officer reviews the cards and either accepts or rejects the suggestions. If any card indicates that prior authorisation is required, it must be accepted, and the necessary actions must be taken. If prior authorization is needed, the relevant links are invoked, and the required information is submitted.
6. Following this, the EHR system displays a window to select an imaging centre for the CT scan. The practitioner or medical officer selects an imaging centre, and before confirming the selection, the system triggers another CRD request to the payer.
7. The payer’s CDS server once again provides card responses, which are reviewed for acceptance or rejection.
8. Finally, the CT scan order is dispatched to the selected imaging centre.

Demo Setup

The diagram below illustrates how the demo setup workflow has been implemented using the WSO2 platform with its healthcare accelerators.

The below video will provide a walkthrough of the demo setup.

You can find the hosted demo EHR setup here.

Deploy the demo setup on your own

This setup contains two components as follows:

1. Web application: This has been implemented using React and contains UI components and elements. Please find the source code here.
2. Backend/ CDS server: This has been implemented using the Ballerina language and contains the CDS server API implementations. Please find the source code here.

You can deploy a replica of this demo setup using these components at your convenience. The following section will explore how to create a customized CDS service.

Create your own CDS service

Ballerina is utilized to develop CDS service templates, core libraries, and utilities.

What is Ballerina?

Ballerina is an open source, cloud-native programming language optimized for integration. It simplifies building, integrating, and deploying APIs, microservices, and serverless applications. Ballerina features a unique visual syntax for designing integrations, supports data transformations, and offers built-in support for protocols like HTTP, gRPC, and GraphQL.

Approach

A CRD solution can be implemented using a service template generated by the Bal Health CLI tool. This template consists of:

1. Necessary CDS service interfaces.
2. Built-in context data validation.
3. Built-in Pre-fetch FHIR data handling and validation.
4. Support for transformation between CDS-specific data structures and external data structures.
5. Other utils methods and records.

Users (developers) need to implement only the backend connectivity of external decision support systems.

Steps to implement your own CDS service

1. Install Ballerina.
2. Pull the Ballerina health tool.
3. Invoke the below command to generate the Ballerina project.
4. Here, we should provide a config file (tool-config.toml). By running the help command, you can find the sample configuration and all other properties of the CDS command. A sample configuration file is attached for reference.
5. The above command will generate a service template with the required project skeleton, and developers should implement the connectivity for the decision servers.

You can find the generated template code here.

Trying it out

Follow the abovementioned steps and use the shared config file to generate a sample CDS service. You can use this Postman collection to try out the generated APIs.

Conclusion

This article went over how a real-world CRD use case can be implemented using the WSO2 Platform alongside its healthcare accelerators, including a hosted demo setup. To implement the CDS service, developers can use the Ballerina Health tool CMD utils to generate a service template with required skeletons and utils. However, developers are expected to implement the required connectivity for the external decision support systems.

For further information and queries, refer to our website.