HEALS.ASIA

Challenges

to expose the provider directory FHIR API (search facilities, search in practitioners by name or specialty), as well as the appointments FHIR API (book an appointment, check in, etc.), for a third-party mobile application

to collect the clinical data from two separate EHR systems, connected to the TPA, in the centralized clinical data repository (CDA)

Solutions

For the first set of functionalities, an FHIR facade implementing extract-transform-load from the client’s proprietary data in real-time was developed based on the Edenlab Kodjin FHIR server. Our team created custom profiles corresponding to the proprietary data with all the relevant terminologies
The appointments module was developed from scratch with the FHIR-first approach with custom FHIR profiles and a custom business logic layer

Custom profiles were created, and the terminology service was configured with the custom terminologies. A pseudonymization technique was used to protect the patients’ clinical data

Challenges

to standardize the financial API consumed by various providers connected to the TPA: all the main workflows from the FHIR financial module should be exposed as FHIR operations
to automate these workflows from the TPA side, i.e., to introduce the auto-adjudication engine that was able to generate the eligibility responses and claim predetermination responses based on the insurance plan data and the history of claims

Solutions

The solution was a hybrid FHIR/non-FHIR application. While all the data that was exchanged was stored in the FHIR server, for the insurance plan the complex structure enabling the auto-adjudication logic was implemented. The engine itself was designed as a framework, so new limits and constraints could be added in the future.