Industries
Healthcare organisations rarely lack systems. They have a clinical system of record, a scheduling tool, a document store, a patient communication product and a spreadsheet that reconciles the four. The work we are asked to do is almost never to replace the clinical record — it is to build the operational layer around it that the record was never designed to provide, and to make that layer exchange data safely with everything else.
We build for GP federations and primary care networks, private clinic groups, dental groups, diagnostic providers and digital health companies selling into the NHS. The constraint that shapes every one of those projects is the same: patient data has a regulatory perimeter, clinical functionality carries safety obligations, and integration routes into EMIS Web, TPP SystmOne and hospital PAS estates are governed rather than open.
Where it breaks
EMIS Web and SystmOne hold consultations, coded observations, medications and documents. They do not run a multi-site recall programme across a federation, a triage queue with service-level thresholds, or a referral pathway with an audit trail across organisational boundaries. Those workflows end up in shared mailboxes, task lists and spreadsheets keyed on NHS number by hand.
Booking sits in one system, SMS in another, the website form in a third, and the results letter in the document store. A patient who books online, replies to a text and then telephones is three separate records to the staff handling them, and no single view shows what has already been said.
A member of staff rekeys demographics from a referral into the clinical system, then rekeys the same details into a billing or claims tool. Every transcription is a chance to attach a record to the wrong patient, which is a clinical safety hazard rather than a data quality annoyance.
DNA rates, waiting list positions, chair or room utilisation and recall compliance are assembled monthly from exports. By the time the numbers exist the month is over, and two departments produce different figures because they filtered the export differently.
A group that acquires practices inherits a mixed estate — EMIS Web in one site, SystmOne in another, Dentally or SOE Exact across the dental arm — and cannot answer basic group-level questions without an integration layer that normalises identifiers and coding.
Patient-facing services procured without WCAG 2.2 AA requirements or without NHS Login integration fail assessment late, and remediation after build costs several times what designing for it would have cost.
Regulatory context
Integration surface
Primary care clinical systems
National services
Dental systems
Hospital and diagnostics
Standards
Operational systems
Solutions
Booking against live practice diaries, repeat prescription requests, rule-based results release, NHS Login identity verification and proxy access for carers, built to WCAG 2.2 AA.
Explore patient portal developmentScheduling and recall, clinician diaries, room and chair utilisation, claims and remittance, waiting list management and DNA tracking across multi-site groups.
Explore practice management softwareIM1 and GP Connect routes, FHIR UK Core resource mapping, write-back permissions, patient matching on NHS number and a defensible audit trail.
Explore ehr and epr integrationConsultation scheduling, WebRTC video, structured clinical note capture, prescribing handoff, consent capture and recording retention policy.
Explore telehealth platform developmentCharting and treatment planning, NHS UDA banding with FP17 submission, private plan billing, recall cycles and imaging integration.
Explore dental software developmentA factual reference for DTAC, DCB0129, DCB0160, DSPT, UK GDPR and MHRA classification, and where each sits in a delivery timeline.
Explore healthcare software complianceEngagement shapes
Questions
Both. The commercial route differs — NHS trusts and integrated care boards buy through framework agreements and formal procurement, private groups and practices buy directly — but the engineering obligations are the same: DCB0129 clinical risk management on our side, DCB0160 on the deploying organisation's side, and DSPT-aligned handling of patient data throughout.
Read access is routinely achievable through GP Connect for the standard capability set, and through IM1 pairing where a deeper or bespoke interface is required. Write-back is narrower: it depends on the specific IM1 interface mechanism agreed with the principal supplier and on what the practice or federation authorises. We map exactly what is readable and writeable in discovery before any build estimate is issued.
It depends on function, not on technology. Software that stores, displays or transmits clinical data is usually not a device; software that interprets data and drives a clinical decision may be classified under UK MDR 2002 and require MHRA registration and a conformity route. We flag classification risk in discovery and, where it is likely, scope the project so the regulated component is isolated and small.
UK regions of Azure or AWS by default, with data residency written into the contract, encryption at rest and in transit, role-based access control, and a full audit trail of who viewed which record and when. Sub-processors and international transfer arrangements are listed in the delivery documentation rather than described in general terms.
We produce the manufacturer-side DCB0129 artefacts — hazard log, clinical risk management plan and clinical safety case report — and work alongside your clinical safety officer, who owns the DCB0160 deployment file.
DTAC consolidates evidence across five areas: clinical safety, data protection, technical security, interoperability and usability with accessibility. Most of it is produced during a build rather than retrofitted, which is why we treat the DTAC response as a deliverable of the project rather than a document written after go-live.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us