Get started
Interoperability

Your data goes where you need it, in a standard it understands.

A key scoped to FHIR reads a patient as FHIR R4, with everything on their record, and a bulk export hands over the whole practice. Narrow keys take bookings and new patients in and feed bills and pharmacy stock out, and signed webhooks say when something changed. DataVault keeps a copy in your own database, and CalendarSync keeps each diary in step with Google or Microsoft 365.

Today

Live: FHIR R4 read of a patient and their whole record, the bulk FHIR export, scoped API keys, signed webhooks, the OpenAPI document with TypeScript and Python clients, DataVault streams to MongoDB, Google Sheets, a webhook, S3 or BigQuery, and a sandbox clinic for developers. CalendarSync connects a calendar once that provider’s sign-in is set up for the deployment, and says so until then. Not yet: the live ABDM gateway, and payouts in the developer programme.

  • 6● live in clinics
  • 1◌ in development
How it works

Five ways out, and the ways in

Each one reaches only its own practice, and every exchange is logged.

  1. FHIR R4, readOne patient as a FHIR Patient, or everything on their record — encounters, observations, conditions, allergies, prescriptions, reports and documents — with a key that carries the FHIR scope.
    ● live in clinicsFHIRBridge →
  2. The whole practice, exportedA bulk FHIR export as NDJSON, one file per resource type, started by a key and collected when it is ready. Every export is audited.
    ● live in clinicsFHIRBridge →
  3. Your own copyRecords streamed to your MongoDB, a Google Sheet, a webhook, an S3 bucket or BigQuery, each stream with its own cursor.
    ● live in clinicsDataVault →
  4. Lists on a scheduleAny list the product shows, exported once or every Monday morning, limited to what the person who set it up may see.
    ● live in clinicsExportDesk →
  5. Calendars in stepA booking appears in the clinician’s own Google or Microsoft 365 calendar, and busy time there closes the slot here.
    ● live in clinicsCalendarSync →
AI in every app

It drafts and suggests. A person decides.

Meet medappz AI
Shows its sourcesClinical and financial answers are grounded in your own records, and name the ones they read.
Drafts, never filesA named person accepts or discards every draft. The model never signs.
You can turn it offOne setting per organisation: off, redacted or full. Off keeps the manual path.
Redacted before it leavesBy default the patient’s name, number and contact details are taken out of what the model sees.
The contract

What FHIRBridge promises

Every app in the store states what it reads, what it writes and what it will never do. This is its listing, word for word.

● live in clinicsFHIRBridge →
Reads
the patient record, visits, results, prescriptions and documents
Writes
exchange log, validation findings, imported observations
Never
It never guesses a code: a field whose terminology is not loaded goes out in this system’s own vocabulary, labelled, rather than under a nearest-looking national code. It writes only observations from an inbound bundle — a diagnosis, prescription, report or document written elsewhere is held for a person to read rather than filed in this hospital’s chart under nobody’s signature. It sends the reference to a document and never the file behind it. And a bundle cannot choose whose chart it lands on: the patient is the one the caller named and this organisation owns.
Your data
Full PHI. All clinical data stays in the record.
The apps

The apps behind it

Every badge is read from the listing it links to.

Live today

FHIRBridgeFHIR R4 in and out, mapped in the open and every exchange logged.DataVaultYour records in your own database, or streamed to it.ExportDeskEvery list, out to a file or a spreadsheet, on a clock.CalendarSyncTwo-way sync with Google Calendar and Microsoft 365 — not just a read-only feed.KeyRingYour own keys and connections, sealed and verifiable.ABDMLinkCare contexts and ABDM consent artefacts, ready for a gateway this deployment does not have.

Offered in some markets only: ABDMLink (India).

In development

ABDMConnectThe live ABDM gateway — ABHA care contexts and consents reaching the national network.

Offered in some markets only: ABDMConnect (India).

Questions, answered

What works today, and what does not yet?
Live: FHIR R4 read of a patient and their whole record, the bulk FHIR export, scoped API keys, signed webhooks, the OpenAPI document with TypeScript and Python clients, DataVault streams to MongoDB, Google Sheets, a webhook, S3 or BigQuery, and a sandbox clinic for developers. CalendarSync connects a calendar once that provider’s sign-in is set up for the deployment, and says so until then. Not yet: the live ABDM gateway, and payouts in the developer programme.
Which apps are behind it?
Live in clinics: FHIRBridge, DataVault, ExportDesk, CalendarSync, KeyRing, ABDMLink. In development: ABDMConnect. Each listing says what the app does and what it does not.
How do I get it?
A practice’s admin makes a scoped API key in Admin → Integrations. A developer can make a sandbox clinic with synthetic patients on the developers page and read every route in the API reference.
Does the AI decide anything?
No. It drafts and suggests from the records on your screen; a named person accepts or discards every draft, and one setting per organisation — off, redacted or full — decides what reaches the model.

Build against the real thing

Make a sandbox clinic with synthetic patients and a key of its own, and read every route a key can reach in the API reference.