/
openHIM as Interoperability Layer : Generic Data Exchange Workflow

openHIM as Interoperability Layer : Generic Data Exchange Workflow

Content

 

Properties

Reference

https://guides.ohie.org/arch-spec/introduction/openhie-finance-and-insurance-services-workflows/hfw-004-claiming

Sector

Health

Components

github

https://github.com/openimis/sandbox/tree/develop/mediator https://github.com/NidanHIS/nidan-docker

 

Purpose

This page describes a simpler idea: use one shared connector (openHIM) so that any outside system can exchange any type of information with openIMIS, not just claims. Think of it as a single reception desk instead of a separate door for every type of request: whether someone wants to check insurance coverage, look up a patient, or submit a claim, they go through the same entry point.

This page documents the generic role of openHIM as the Interoperability Layer (IOL) for all data exchanges between external Point-of-Service (PoS) systems and openIMIS — not limited to claim submission.

openIMIS manages multiple resource domains beyond claims: insuree/beneficiary records, geographic locations, insurance products and benefit packages, and the services/items billed within claims. Any of these domains can be exchanged through openHIM using the same architectural pattern.

This page serves as a parent page for all PoS integrations — including Medic/CHT and Bahmni — and captures how openHIM orchestrates any PoS → openIMIS data exchange, regardless of the resource domain involved, providing a reusable architectural reference aligned with openHIE principles.

Child workflows covered (eClaiming examples):

ℹ️ Note: eClaiming is the most mature use case implemented to date and is used throughout this page as the illustrative example. The architecture described applies identically to insuree enrollment, location synchronization, product/benefit package distribution, and service/item catalog exchange.

image-20260618-090903.png

 

Trigger

Any Point-of-Service system submits or requests a FHIR resource — a Claim, Patient (insuree), Location, InsurancePlan (product/benefit package), or service/item-related resource — intended for processing in openIMIS.

Workflow Overview

Field

Value

Field

Value

Workflow Maturity

Partially Implemented : Claims domain routed via configured mediators in sandbox. Security layer partially in place (JWT on Bahmni side; CHT pending).

Referenced Standards

HL7 FHIR R4: https://hl7.org/fhir/R4/index.html · openHIE Architecture: https://ohie.org · openHIM Documentation: http://openhim.org

openHIE Alignment

Fully aligned : openHIM fulfills the IOL role as defined by the openHIE Component Framework, across all resource domains

Actors

 

Role

System

Description

PoS (Point of Service)

Any : Medic/CHT, Bahmni, or future PoS

Initiates or requests data exchange transactions across any resource domain (claims, insuree, location, products, services/items). Submits FHIR resources to openHIM and receives responses.

IOL (Interoperability Layer)

openHIM

Central mediator. Receives all inbound FHIR transactions regardless of domain, enforces routing rules, logs all interactions, and relays messages to the appropriate FIS endpoint. Does not transform payloads in the current sandbox implementation.

FIS (Financing & Insurance System)

openIMIS

Receives routed FHIR resources, processes them per domain (adjudication for claims, enrollment for insuree, reference data lookup for location/products/services), and returns the corresponding FHIR response.

Assumptions & Prerequisites

  1. openHIM is deployed and accessible by all PoS systems via HTTPS.

  2. At least one openHIM mediator is configured per PoS integration (Bahmni, CHT) — currently scoped to the Claims domain only.

  3. openIMIS FHIR API is reachable from openHIM (internal network or VPN), exposing endpoints for each resource domain (Claim, Patient, Location, InsurancePlan, service/item catalogs).

  4. Patient identity (insuree) is already established in openIMIS prior to claim submission.

  5. JWT authentication is configured for Bahmni→openHIM transactions. CHT→openHIM authentication is pending configuration.

  6. All transactions are logged in openHIM's audit log for traceability, regardless of resource domain.

Validations

openHIM (IOL) must validate, for any domain:

  • Inbound FHIR payload syntax (well-formed JSON/XML)

  • Authentication credentials (JWT token : Bahmni to be extended to CHT)

  • Routing rule match: correct mediator selected per PoS source and resource type

  • Successful delivery to openIMIS (HTTP 2xx); retry on failure

openIMIS (FIS) must validate, per domain:

  • Claims: beneficiary eligibility, active policy coverage, clinical code validity, claim completeness

  • Insuree: identity mandatory fields

  • Location: hierarchy consistency (Village→Ward→District→Region)

  • Products / Benefit Packages

  • Services & Items: code validity against the active service/item catalog

Diagram

Generic Workflow Steps

The steps below describe the domain-agnostic pattern. The example uses the Claims domain (the current reference implementation); the same sequence applies to Insuree, Location, Products, or Services/Items exchanges once their mediators are configured.

Step 1 — PoS Initiates a Data Exchange Transaction

A PoS system (Bahmni, CHT, or other) composes a FHIR resource appropriate to the domain — Claim, Patient, Location, InsurancePlan, or a service/item-related resource — and submits it to the openHIM entry point via HTTPS.

Transaction: POST /fhir/{resource} or GET /fhir/{resource} (PoS → openHIM)

Step 2 — openHIM Receives and Authenticates