HL7 v2 and FHIR R4
The record moves in and out over standard interfaces. R4 is the version national programmes profile against, so it is the contract we build to rather than the newest one on the shelf.
Standards, not lock-in: the formats and rails that let docDule join a practice mid-flight instead of asking it to start over. Below, what connects today and what is still being built, in separate bands.
docDule is a cockpit that sits on top of your existing HIS or ERP, or runs standalone on Narra OS. Either way the interface is a published standard rather than a private format.
The record moves in and out over standard interfaces. R4 is the version national programmes profile against, so it is the contract we build to rather than the newest one on the shelf.
ABHA-aware timelines and consent-first flows, built on the ABDM sandbox track. Available to practices that want it, and never a prerequisite to onboard.
A referral carries the coded record rather than a re-typed paragraph, and the reply comes back onto the same patient instead of into an inbox.
Reports, scans, and letters attach to the visit they belong to, so the record is one place rather than a shared drive and somebody who knows where things are.
A page that lists only wins is a page you cannot use to plan. These are real and named, and none of them is a prerequisite for the work docDule does today.
ICD-11 codes are suggested against the assessment today. SNOMED CT and LOINC as a full coded layer underneath the note are on the roadmap, and they are the gap we are least willing to paper over: coded data is what makes analytics, claims, and any regulator-facing export possible.
India now runs a National Health Claims Exchange under ABDM. A rail is a better answer than sixty bilateral integrations, and connecting to it is on the roadmap rather than done.
Telemedicine exists in the platform and is being surfaced. Where it lands it follows the NMC telemedicine guidance on practitioner identity, consent, and record keeping.
DICOMweb is how studies will reach the record: QIDO-RS to find them, WADO-RS to read them, STOW-RS to store them. We are not claiming it until it works end to end.
Every Dule reads and writes the same encounter, so these are not integrations in the ordinary sense. There is nothing between them to synchronise.
Lab orders leave the consult and results come back to it, without a phone call in either direction.
The consultation you record is the consultation the clinic bills, on the same record and the same ledger.
Appointments, prescriptions, and results reach the patient without the desk re-sending anything by hand.
One identity across every surface, so a doctor who is also a patient and also on staff is still one person to the system.
Every capability our own screens use is reachable over the same documented HTTP API. There is no private back channel that only we can call.
Clinical and operational events are published, so another system can react to a signed note or a raised order rather than polling for it.
The model is meant to be a choice, not a lock. A provider gateway for your own account and keys is built into the platform and rolls out with early access.
Notes, prescriptions, the coded record, and the access log export in open formats. Nothing about docDule depends on you being unable to leave.
Send us the systems already in your practice and we will tell you honestly what connects today, what is on the sandbox track, and what would be new work.
ABDM integration is available to clinics that want it, and never required to start.
The full picture, one page at a time.
The whole clinical cockpit, from the spoken consult to the signed discharge summary.
Who docDule is for, by speciality, by the shape of the practice, and by the moment it saves.
The AI clinical cockpit for doctors, priced per clinician. Free during early access, founding rates locked before launch.