BAHMNI → openIMIS - eClaiming Workflow

BAHMNI → openIMIS - eClaiming Workflow

Content

 

Properties

 

Purpose

When a patient receives care at a health facility, the claim should follow automatically (not through paperwork submitted days later). This workflow connects Bahmni, the hospital system used by clinical staff, directly to openIMIS: as soon as an encounter is recorded, a claim is generated and submitted in real time. Facilities get faster reimbursement, errors from manual entry are eliminated, and the financing system always reflects what actually happened at the point of care.

It serves as a proof-of-concept for real-time electronic claiming (eClaiming) aligned with openHIE architectural principles standards, demonstrating how structured clinical data can seamlessly feed into health financing workflows.

Key objectives:

  • Enable automated, real-time FHIR claim submission from point-of-care systems

  • Improve claim accuracy and adjudication speed

  • Reduce administrative overhead at health facility level

image-20260614-133327.png

 


Trigger

A patient receives healthcare services in a facility using Bahmni, and a clinical encounter is recorded.


Workflow Overview

Field

Value

Field

Value

Workflow Maturity

Newly Defined — Specified and approved. Proof-of-concept implemented.

Referenced Standards

HL7 FHIR R4 Claim / ClaimResponse: Financial-module - FHIR v5.0.0 · openHIE Architecture: https://ohie.org

openHIE Alignment

Fully aligned — actors mapped to PoS / IOL / FIS roles

Actors

 

Role

System

Description

PoS (Point of Service)

Bahmni (OpenMRS core)

Hospital information system. Captures clinical encounters and generates FHIR Claim resources. Receives adjudication responses.

IOL (Interoperability Layer)

openHIM

Mediates all transactions between Bahmni and openIMIS. Validates payloads, enforces security (JWT/digital signatures), and orchestrates routing via configured mediators.

FIS (Financing & Insurance System)

openIMIS

Processes FHIR Claim resources, applies country-specific benefit rules, and returns ClaimResponse resources.

Assumptions & Prerequisites

  1. Patient identity is established in openIMIS (beneficiary enrolled, policy active).

  2. Bahmni uses OpenMRS core services with FHIR-aligned entity mapping (Patient, Encounter, Condition, Procedure).

  3. openHIM is deployed and configured with mediators for Bahmni→openIMIS routing.

  4. Authentication is enforced via JWT / digital signatures at the openHIM layer.

  5. openIMIS is configured with country-specific benefit and adjudication rules.

Validations

openHIM (IOL) must validate:

  • FHIR Claim payload structure and completeness

  • JWT / digital signature authentication

  • Routing logic to the correct openIMIS FHIR endpoint

openIMIS (FIS) must validate:

  • Beneficiary eligibility and active policy coverage

  • Clinical code validity (diagnosis, procedure codes)

  • Claim completeness before adjudication

⚠️ Current sandbox limitation: Payload transformation is not performed by openHIM. PoS systems are responsible for generating valid FHIR R4-compliant payloads before submission, for any domain.

Diagram

Workflow Steps

Step 1 — Clinical Encounter in Bahmni

A clinician records a patient encounter in Bahmni. The system captures:

  • Patient — demographic and identity data

  • Encounter — visit context and date

  • Condition — diagnosis (ICD codes)

  • Procedure — services rendered


Step 2 — FHIR Claim Generation

Bahmni's backend (or a dedicated FHIR service) composes a FHIR Claim resource from the encounter data, enriched with optional resources: Coverage, Practitioner, Location.


Step 3 — Claim Transmission to openHIM

The composed FHIR Claim is POSTed to the openHIM endpoint.