Skip to content

Now selecting the first cohort of facilities in Sierra Leone. Request a briefing

Who it serves

HealthOS for insurers

Structured, coded claims arriving from the encounter that produced them. Fewer rejections, shorter cycles, a smaller fraud surface.

Request a briefing

Follow one patient

One visit. Five institutions. One record.

Illustrative: Fictional data. Not a live system.

  1. 04 · Insurer

    The visit is claimed

    Roadmap

    The problem

    Money moves slower than care

    Claims are assembled by hand after the fact, from notes that were never structured for adjudication. Rejections are discovered weeks later, and the facility carries the float.

    Revenue detached from the encounter

    Claim validated

    The claim is checked against the encounter it pays for, before it is submitted.

03

Revenue Cycle

Claims that are complete before they are submitted.

Billing generated from the clinical encounter itself, coded as care is delivered. Invoices reconcile to the encounter that produced them, and a claim is validated against payer rules before it leaves the building.

  • Encounter-driven billing
  • Coded claims and adjudication
  • Payments and reconciliation
  • Financial approvals and controls
See the module Revenue Cycle

Claim before submission

Illustrative: Fictional data. Not a live system.
01

Patient Identity

One patient. One record. Everywhere.

A unified patient identifier with deterministic and probabilistic matching across facilities, duplicate detection with human merge review, and a permanent, queryable trail of who accessed what and on whose consent.

  • Unified patient identifier
  • Deterministic + probabilistic matching
  • Duplicate detection and merge review
  • Consent and access audit trail
See the module Patient Identity

Possible duplicate

Illustrative: Fictional data. Not a live system.

Engineered to the standards national systems require

  • HL7 FHIR R4

    Clinical data exchange

  • ICD-11 · SNOMED CT

    Coded diagnoses and terminology

  • OpenHIE architecture

    National exchange patterns

  • ISO 27001 controls

    Information security baseline

  • Data residency

    Set by national law

Standards HealthOS is built to. Formal certification follows first production deployment.

Immutable audit trail

Every read and write against a patient record is logged with actor, purpose and consent basis. The trail is queryable and cannot be edited after the fact.

Consent as a first-class object

Cross-facility access will be governed by recorded patient consent, with scope and expiry, not by whoever holds a login.

Audit trail

HOS-DEMO-0142

Illustrative: Fictional data. Not a live system.
  • Time
    10:03:52
    Actor
    Pharmacist · Illustrative pharmacy
    Action
    Read prescriptionHOS-DEMO-0142
    Purpose
    Dispensing
    Consent basis
    Patient consent, cross-facility
  • Time
    10:03:31
    Actor
    Emergency physician · Illustrative district hospital
    Action
    Read full recordHOS-DEMO-0142
    Purpose
    Emergency care
    Consent basis
    None on record

    Break-glass. Flagged for review

  • Time
    10:02:58
    Actor
    Clinician · Illustrative clinic
    Action
    Read medication historyHOS-DEMO-0142
    Purpose
    Direct care
    Consent basis
    Patient consent, cross-facility
  • Time
    10:02:42
    Actor
    Lab technician · Illustrative district hospital
    Action
    Wrote lab resultHOS-DEMO-0142
    Purpose
    Direct care
    Consent basis
    Treating facility
  • Time
    10:02:14
    Actor
    Nurse · Illustrative district hospital
    Action
    Read vital signsHOS-DEMO-0142
    Purpose
    Direct care
    Consent basis
    Treating facility

Deployment

Three ways to run it. One codebase.

How HealthOS is hosted is a procurement and sovereignty decision, not a product decision. The platform is designed to be the same in all three.

Choose a deployment model

Clinics and hospital groups

Managed cloud

HealthOS will run it. Designed as the fastest path to production: no infrastructure team required, regional hosting.

Insurers and large networks

In-country cloud

Designed to be deployed to a national or regional cloud region, so data residency requirements are satisfied by architecture, not by policy promise.

Ministries and public health systems

Sovereign / on-premise

Designed to run inside government infrastructure, operated by your team with our support, with full control of data, keys and upgrade cadence.

In-country cloud

Illustrative: A simplified diagram, not an architecture specification.

Inside the country

  • Your infrastructure

    Government or institutional

    • —

  • In-country cloud region

    National or regional provider

    • Data
    • Keys

  • HealthOS

    Regional hosting and operations

    • Operations team

Data and keys will sit in a cloud region inside the country, the keys in a key service separate from application access. HealthOS will operate it.

Questions we are asked

The questions procurement asks first

Relevant to youWe already have systems. Do we replace them?

No. Facilities will connect existing systems through the FHIR API and keep them. Deployments are designed to begin with identity and exchange, and to adopt clinical or revenue modules only where the current system is the constraint.

Relevant to youWhere does patient data live?

Wherever national law requires. HealthOS is designed to deploy to managed cloud, to an in-country region, or inside government infrastructure. The sovereign model is designed so that data never has to leave the jurisdiction that governs it.

Relevant to youHow do you handle consent across facilities?

Consent is a recorded object with scope and expiry, not an implicit property of holding a login. Cross-facility access will be granted against that record, and every access written to an immutable audit trail.

If it runs where you are, the next step is a conversation. Not a procurement process. We are selecting the first cohort of facilities now.

Request a briefing