Documentation

Integrations

Connect Cari to health information exchanges, national reporting systems, and external services.

FHIR R4

HL7 FHIR R4 as the primary data interoperability standard.

Cari implements HL7 FHIR R4 (Fast Healthcare Interoperability Resources) as the primary data interoperability standard. The gateway includes a built-in FHIR resource validator and cross-border patient lookup capabilities.

Supported FHIR Resources

Patient

Demographics, identifiers, contact information

Encounter

Clinical encounters with status and class

Observation

Vitals, lab results, and clinical findings

MedicationRequest

Prescriptions and medication orders

Condition

Diagnoses and clinical conditions

AllergyIntolerance

Allergy records

Practitioner

Healthcare provider demographics

Organization

Healthcare facility information

Procedure

Clinical procedures performed

Immunization

Vaccination records

Bundle

Collections of resources

OperationOutcome

Error and warning details

Cross-Border Patient Lookup

Cari can query national Health Information Exchanges (HIEs) to look up patient records across borders. This enables continuity of care when patients travel between African countries.

GET /api/fhir/cross-border/Patient/{national_id}?country=KE
Authorization: Bearer v4.public.eyJ...

// Supported country codes:
// KE — Kenya (hie.health.go.ke)
// GH — Ghana (openempi.ghana.moh.gov.gh)
// NG — Nigeria (ndhis.health.gov.ng)
// ZA — South Africa (hie.health.gov.za)
// TZ — Tanzania (hie.moh.go.tz)
// UG — Uganda (dhis2.health.go.ug)
// RW — Rwanda (rhies.moh.gov.rw)
// ET — Ethiopia (hie.moh.gov.et)

// Response:
{
  "resourceType": "Bundle",
  "meta": {
    "source": "https://hie.health.go.ke/fhir/r4",
    "country": "KE",
    "national_id": "12345678"
  },
  "entry": [...],
  "total": 1
}

You can also supply a custom HIE endpoint for testing with sandbox environments using the hie_endpoint query parameter instead of country.

SMART on FHIR

Cari supports SMART on FHIR application launch for third-party clinical applications. The configuration discovery endpoint follows the SMART App Launch Framework specification.

// Discovery endpoint (public, no auth required)
GET /.well-known/smart-configuration

// Launch a SMART app
POST /api/smart/launch
Content-Type: application/json

{
  "patient": "patient-uuid",
  "encounter": "encounter-uuid",
  "launch_url": "https://thirdparty-app.com/launch"
}

// Response:
{
  "launch_id": "uuid",
  "context": { ... }
}

FHIR Resource Validation

The gateway validates all incoming FHIR resources before processing. Each resource type has specific required fields that are checked structurally:

  • Patientmust have id or identifier
  • Encountermust have status and class
  • Observationmust have status, code, and subject
  • MedicationRequestmust have status, intent, subject, and medication reference
  • Conditionmust have code and subject
  • AllergyIntolerancemust have patient
  • Bundlemust have type

DHIS2

Bidirectional data exchange with national health reporting systems.

Cari integrates with DHIS2 (District Health Information Software 2) for bidirectional data exchange with national health reporting systems. DHIS2 is used by over 80 countries for aggregate health data management.

Data Export to DHIS2

The CDS service aggregates clinical data and formats it for DHIS2 submission. This enables automatic reporting of notifiable diseases, vaccination coverage, and other public health indicators.

// Export data formatted for DHIS2 consumption
GET /api/public-health/dhis2-export
Authorization: Bearer v4.public.eyJ...

// Push data directly to a DHIS2 instance
POST /api/public-health/dhis2-push
Authorization: Bearer v4.public.eyJ...
Content-Type: application/json

{
  "dhis2_url": "https://dhis2.health.go.ke",
  "dataset": "disease_surveillance",
  "period": "2026Q1",
  "org_unit": "ou-id-123"
}

// Export surveillance data to DHIS2
POST /api/surveillance/export/dhis2
Authorization: Bearer v4.public.eyJ...

National Dataset

The /api/public-health/national-dataset endpoint produces aggregate, anonymized data suitable for national health information system integration. This supports Ministry of Health reporting requirements across multiple African countries.

Supported Use Cases

Aggregate disease surveillance reporting
Vaccination coverage data by facility and district
Syndromic surveillance alert forwarding
Maternal and child health indicators
Malaria RDT result aggregation
Public health dashboard data feeds

HL7v2

Lab result ingestion from laboratory information systems.

Cari supports HL7v2 message ingestion for receiving lab results from laboratory information systems (LIS). This is the most widely deployed standard for lab result delivery in healthcare.

Lab Result Ingestion

POST /api/lab/hl7-ingest
Authorization: Bearer v4.public.eyJ...
Content-Type: text/plain

MSH|^~\&|LAB_SYSTEM|FACILITY|CARI|CARI|20260415120000||ORU^R01|MSG001|P|2.5
PID|1||PAT001||DOE^JANE||19900315|F
OBR|1||ORD001|CBC^Complete Blood Count
OBX|1|NM|WBC^White Blood Cell Count||7.5|10*3/uL|4.5-11.0|N

// 200 OK
{
  "success": true,
  "data": {
    "lab_result_id": "uuid",
    "patient_matched": true,
    "patient_id": "patient-uuid",
    "observations_created": 1
  }
}

Currently, only ORU^R01 (Unsolicited observation result) messages are supported for lab result ingestion.

Lab Result Workflow

1

External LIS sends HL7v2 ORU message to /api/lab/hl7-ingest

2

Cari parses the message, extracts patient identifiers and observations

3

Patient matching is performed against the MPI

4

Lab results are stored and linked to the matched patient

5

Clinicians can review results via GET /api/patients/:id/lab-results

6

Critical/panic values trigger alerts via POST /api/cds/panic-values/check

Clinical HL7v2 Ingestion (Session Service)

The session service also provides an HL7v2 ingestion endpoint for clinical workflow integration:

POST /api/clinical/hl7/ingest
Authorization: Bearer v4.public.eyJ...
Content-Type: text/plain

// Accepts HL7v2 messages within the clinical session context

Medplum

Open-source FHIR server for interoperability-ready health records.

The Patients and Doctors services integrate with Medplum, an open-source FHIR server, for storing and retrieving FHIR-formatted clinical data. Medplum provides a compliant FHIR R4 data store that Cari uses as a backend for interoperability-ready health records.

How It Works

  • When clinical records are created in Cari, a FHIR representation is stored in Medplum
  • The MPI service can retrieve FHIR Patient resources: GET /api/mpi/patients/:id/fhir
  • External FHIR-compliant systems can query the Medplum instance for standardized data exchange

Medplum connectivity is configured via environment variables on the Patients and Doctors services. The MedplumClient is initialized from the service configuration at startup.

DICOM Imaging

Digital Imaging and Communications in Medicine for medical imaging workflows.

Cari supports DICOM (Digital Imaging and Communications in Medicine) for medical imaging workflows. The session service provides endpoints for accessing and annotating DICOM studies.

// Access a DICOM study (generates viewer URL)
POST /api/clinical/dicom/access
Authorization: Bearer v4.public.eyJ...
Content-Type: application/json

{
  "study_uid": "1.2.840.113619.2.55.3.604688119",
  "patient_id": "patient-uuid"
}

// Save annotations on a DICOM study
POST /api/clinical/dicom/annotate
Authorization: Bearer v4.public.eyJ...
Content-Type: application/json

{
  "study_uid": "1.2.840.113619.2.55.3.604688119",
  "annotations": [...]
}

CDS Hooks

HL7 CDS Hooks specification for clinical decision support integration.

Cari implements the HL7 CDS Hooks specification for clinical decision support integration. Third-party EHR systems can discover and invoke Cari's CDS services using the standard protocol.

// Service discovery (public, per CDS Hooks spec)
GET /cds-services

// Response:
{
  "services": [
    {
      "hook": "patient-view",
      "title": "Drug Interaction Check",
      "description": "Checks for drug-drug interactions",
      "id": "drug-interaction-check"
    }
  ]
}

// Invoke a hook
POST /cds-hooks/drug-interaction-check
Authorization: Bearer v4.public.eyJ...
Content-Type: application/json

{
  "hookInstance": "uuid",
  "hook": "patient-view",
  "context": {
    "patientId": "patient-uuid",
    "medications": [...]
  }
}

Webhook Events

Incoming webhooks from external services like Stripe, LiveKit, and mobile money.

Cari sends webhook notifications for key events. The platform currently supports Stripe payment webhooks and LiveKit telemedicine session webhooks. For incoming webhooks from external services:

POST /api/webhooks/stripe

Stripe payment and subscription events

POST /api/webhooks/livekit

LiveKit video session events (signature-verified)

POST /api/payments/webhooks/orange-money

Orange Money payment callbacks

POST /api/payments/webhooks/mtn-momo

MTN MoMo payment callbacks

POST /api/gtm/webhooks/resend

Resend email delivery events

POST /api/gtm/webhooks/inbound

Inbound lead capture

See the Webhooks documentation for details on setting up outbound webhook endpoints and event payload formats.

WhatsApp (Notifications)

WhatsApp Business API integration for patient communication.

The Notifications service integrates with WhatsApp Business API for patient communication. It manages message templates, session state, and webhook verification for two-way messaging.

Appointment reminders and confirmations
Lab result notifications
Prescription refill reminders
Custom notification templates

Mobile Money

Three major mobile money providers across Africa.

The Payments service integrates with three major mobile money providers in Africa:

M-Pesa(Kenya, Tanzania)

STK push and payout APIs

MTN MoMo(Ghana, Uganda, Cameroon, and 10+ countries)

Collection and disbursement

Orange Money(Senegal, Ivory Coast, Mali, and more)

Payment collection

See the API Reference for payment endpoints.