Eleven modules · one clinical record · See all
The platform · IHIP

One record,
understood in layers.

The Integrated Health Interoperable Platform runs as three connected layers — capture, institution and individual — over one patient identity and one terminology substrate.

Clients — Android · web console · partner API
│ FHIR · SMART ▼
API gateway — auth · consent · rate limiting · routing
CaptureAttribute Box
BindSNOMED · ATC
RecordFHIR R4 CDR
ExchangeABDM · consent
Sync queue · terminology index · rules engine · audit log
Offline-first client · India-resident, empanelled infrastructure · append-only clinical estate
Standards & complianceSNOMED CT·LOINC·ICD-10/11·ATC·HL7 FHIR·ABHA·DPDP
Layer view 01 — capture

Records are made in ninety seconds,
or they are not made.

Every architectural decision downstream exists to protect the capture path. If coding is slower than the pad, nothing else in this document matters.

01
Local first

The capture path issues no network request. The terminology index is resident on the device and ranked by the clinician's own history.

02
Non-blocking by specification

No validation, alert or sync condition may prevent a consultation being finished and a prescription printed. Advisories are inline and dismissible.

03
Original words preserved

The clinician's verbatim entry is stored alongside the bound concept — the only recoverable ground truth when a mapping is later found wrong.

04
Bundles assembled afterwards

FHIR assembly and ABDM linkage happen after the encounter closes and the patient has left, never in the path between the doctor and the printer.

Layer view 02 — architecture

Offline is the normal case,
not the fallback.

Specified as an offline application that opportunistically synchronises. A clinic on a dead connection is not a degraded clinic; it is the design centre.

Client

Thick, self-sufficient

Full capture, print and search with no network for a rolling 72 hours.

Sync

Append-only events

Idempotent by client-generated identifier. Replay is safe and expected.

Conflict

Union, never merge

Two devices adding to one encounter union. Duplicate patients are never merged automatically.

External

Never user-facing

An ABDM outage is queued, retried and reported to operations — not to the clinic.

Layer view 03 — the record

A record that outlives
the software that wrote it.

Every coded entry carries the code system, the version in force at the time, the author's registry identifier and the device it came from. Amendment creates a version.

01Concept

Code, system URI, and the code-system version in force at entry — permanently distinguishable from a later revision.

02Original text

Exactly what the clinician typed or said, retained on every entry including coded ones.

03Provenance

Author, HPR identifier, device, timestamp, input mode and index version.

04Attributes

Duration, severity, laterality, dose, frequency — structured, and always optional.

05Version

Append-only. Correction supersedes; nothing is overwritten and nothing is hard-deleted.

Master case record
Complaints3 coded
Investigations2 ordered · 1 returned
Diagnosis1 confirmed · 1 differential
Medication2 active
Outcome — a record that is still computable in twenty years.
Principles

Built for software that lives
next to patient care.

Nothing blocks

No validation, no gate and no sync failure may stop a clinician finishing a consultation. Incompleteness is recorded, never enforced.

Coding is a by-product

If a clinician performs an action whose only beneficiary is the data model, the design has failed.

Offline is the normal case

Specified as an offline application that opportunistically syncs — not an online one with a fallback.

Compliance is invisible

Registry onboarding, consent and linkage are done on the clinic's behalf. Nobody is sent to a portal.

Get started

Put the platform to work on your cases.

Anchor clinics get early capability and a real say in what gets built next.