Content

Summary

1. Overview

openIMIS is built to manage the complex administration of social health protection schemes. However, a critical missing link in many health financing deployments is the beneficiary's voice. Did the patient actually receive the care that was billed? Were they asked to make informal out-of-pocket payments?

This wiki outlines the architecture and real-world implementation strategies for capturing claims feedback. It covers two primary avenues to ensure no demographic is left behind:

1. Direct Self-Service: Using a native openIMIS application for digitally connected populations.

2. Assisted Feedback: Using interoperability with third-party platforms like the Community Health Toolkit (CHT) for rural, offline, or digitally excluded populations.

2. The Value of Claims Feedback

Incorporating feedback directly into the claims workflow solves several real-world health financing challenges:

• Fraud Detection (Phantom Billing): Identifying facilities that bill the insurance scheme for services, diagnostics, or drugs the patient never actually received.

• Informal Payments: Detecting when patients are illegally forced to pay out-of-pocket for services fully covered by their insurance tier.

• Quality of Care Monitoring: Tracking patient satisfaction to inform facility accreditation and contract renewals.

• Trust & Transparency: Giving beneficiaries a tangible way to interact with their health insurance, which historically drives up policy renewal rates.

3. Scenario A: Direct Feedback via Native Mobile App

For urban populations or users with smartphone access, a native openIMIS application provides the most immediate feedback loop. Instead of relying on a middleman, the insuree interacts directly with their medical history.

Real-World Scenario:

Aarav visits a contracted hospital for a fever. The hospital submits a claim to openIMIS for a consultation and a round of expensive antibiotics. The next day, Aarav opens his openIMIS app, sees the claim history, and submits a feedback form indicating he received a basic consultation but the pharmacy was out of stock, so he never received the medication.

Technical Workflow

1.Authentication & Claim Retrieval:FHIR API Integration.

The beneficiary logs into the native openIMIS app. The app queries the openIMIS backend using the HL7 FHIR standard (GET /Claim?patient=[uuid]) to retrieve a historical list of their recent encounters.

2.Reviewing Claim Details:

The user selects a specific claim. The app parses the ClaimResponse resource to display human-readable details: date of visit, facility name, diagnosis, and provided items/medications.

3.Feedback Submission:

The app prompts the user with a short digital survey, rendered dynamically from a FHIR Questionnaire resource.

4.Data Transmission:

The app bundles the user's answers into a FHIR QuestionnaireResponse, links it to the specific Claim ID, and pushes it back to the openIMIS server via REST API.

Example Mockup:

Open

4. Scenario B: Assisted Feedback via Third-Party Apps (CHT)

https://docs.communityhealthtoolkit.org/building/interoperability/openimis/

For rural populations or those lacking digital literacy, self-service apps are ineffective. This is where interoperability with Community Health Worker (CHW) platforms like the Community Health Toolkit (CHT) becomes crucial.

Real-World Scenario:

Sita, living in a remote village, visits a local clinic. She does not own a smartphone. When the clinic's claim hits openIMIS, it automatically triggers a task in her local CHW's CHT app. During a routine home visit a week later, the CHW asks Sita about her clinic visit and logs the feedback offline on her behalf.

Interoperability Architecture (Accomplished tasks in sandbox project)

This data exchange relies on the HL7 FHIR standard and OpenHIM mediators to bridge openIMIS and CHT.

1.Claim Subscription Setup:FHIR Webhooks.

The CHT mediator subscribes to the openIMIS Claim resource using a FHIR Subscription endpoint. This ensures CHT is notified via a rest-hook whenever a new claim enters the system.

2.Triggering the Mediator:

When a claim is created in openIMIS, a ClaimResponse payload containing the Claim UUID, Patient ID, and Date is pushed to the CHT mediator's callback endpoint.

3.Task Generation in CHT:

The mediator formats this data and pushes it to the CHT Records API (/api/v2/records). CHT creates a patient profile (if one does not exist) and schedules a "Claims Feedback" task for the assigned CHW.

4.CHW Data Collection:

The CHW visits the patient and completes the CHT feedback form offline. They capture data on care rendered, informal payments, drug availability, and overall rating.

5.Sync and Return to openIMIS:

Once the CHW's device regains connectivity and syncs, CHT's outbound configuration detects the claims_feedback document. The data is routed back through the mediator and stored in openIMIS against the original claim.

5. Core Data Dictionary

Regardless of the source (Native App or CHT), the feedback payload must standardize around a core set of actionable data points to ensure openIMIS can process it uniformly:

6. Implementation Best Practices for the Real World

To make these technical pipelines truly effective at scale, implementers should consider the following enhancements:

Smart Filtering (Don't Overwhelm Users/CHWs)

Not every single claim requires a feedback loop. Implement business logic in the mediator or openIMIS backend to only trigger feedback tasks for:

• High-value claims: (e.g., inpatient surgeries, expensive diagnostics).

• High-risk facilities: Claims originating from hospitals with a history of poor ratings or billing anomalies.

• Randomized Sampling: A randomized 5-10% sample of all routine claims to maintain a baseline of quality assurance without causing survey fatigue.

Automated Anomaly Detection

Collecting data is only the first step. openIMIS should cross-reference Claim data with QuestionnaireResponse data. If a facility bills for $10,000 worth of antibiotics in a month, but 70% of beneficiary feedback states "Drugs not received," the system should automatically freeze payouts and trigger an audit alert for the scheme operator.

Closing the Loop with the Beneficiary

If a beneficiary reports being illegally charged out-of-pocket, the openIMIS system (or CHT) should trigger a follow-up SMS or a subsequent CHW task. Informing the patient that "The scheme operator is investigating the clinic based on your report" builds immense trust and validates their participation in the scheme.