Every service the trust adds brings an integration to build, a review to run and one more thing to keep alive. Adapters absorb most of it, and we keep the connections live.
What stays on your side
Pre-built adapters absorb most of the message transformation, and how much depends on the system. What stays with you is some of the underlying configuration, the data feed and connectivity, plus a named dependency on a few systems: Nautilus on Cerner scheduling, and System C vendor API access.
Go live before your queue reaches it
Your EPR is the system of record. DrDoctor is the system of action on top of it: it reads what the record says is due, takes the next step with the patient, and returns the result where the integration supports it. Core Communications runs from a patient list, so a service can go live while the connection work runs alongside it.
Your DPIA has documents to cite
DrDoctor acts as data processor under contract, with your trust as data controller. Personal data is never sold and no automated decisions are made about patients. Sub-processors are named publicly with their agreements linked, and the certifications, clinical safety file and IG policies sit on the Trust Centre.
The data comes out where you report
Data Share records what happened: messages sent and delivered, appointments viewed and acted on, form completion, and PIFU activity over time. It goes into Power BI, or exports into the systems your trust already reports from.
What each system needs from your build
We hold live integrations with 20+ distinct trust systems, counted on 12 August 2026, through whichever engine you run: Rhapsody, Ensemble, Mirth, Iguana, HealthShare, Viaduct or Silverlink, over HL7, FHIR, API or JSON.
Oracle Cerner
Demographics and appointments arrive over HL7 largely as they are. Our adapter covers around 80%, and scheduling depends on Nautilus.
EPIC
Standard HL7 in and out. Form responses return to the record where the integration covers them, and the NHS App scope runs on the same HL7.
Access Rio
No HL7 feed, so appointments come over the API, and write-back is supported over the API too. We scope your build before go-live.
System C
Careflow and Medway. Our adapter covers around 90%, and System C's API enriches the HL7 feed, which needs vendor API access from you.
EMIS
No HL7 feed here either, so appointments come to us over the API. Appointment write-back into EMIS is a known limitation.
System One
No HL7 feed either. Appointments arrive through a bespoke JSON extract, which is the piece your team sets up with us.
Lorenzo
Appointment data and patient communications kept in step over HL7. Assessment write-back as PDF is supported.
CRIS
Our radiology adapter covers CRIS and gets around 90% of the way. Bookings, reminders and letters run from the imaging feed.
Soliton
Covered by the same radiology adapter as CRIS, running from the imaging feed. Assessment write-back as PDF is supported.
Can’t find what you’re looking for?
Check out our integrations library for a complete list of systems we integrate with.