Healthcare software development
A single-site practice can run scheduling and recall in the clinical system's native tools. A multi-site group cannot: session templates diverge between sites, chair and room utilisation is never reported the same way twice, claims reconciliation happens in a spreadsheet against a remittance PDF, and the waiting list has entries nobody has checked are still valid.
We build practice management software that sits across a mixed estate of EMIS Web, TPP SystmOne, Vision or dental clinical systems, standardising scheduling logic, recall programmes and financial reconciliation so a group can run and report on operations centrally without forcing every site onto a single clinical system.
The workflow this replaces
Each site manages its own diary, its own recall list and its own claims process, and a group office assembles a picture of the whole estate from what each site is willing and able to export.
Step 01
Each site's practice manager configures clinician session templates, slot durations and appointment types inside its own clinical system, with no shared definition of what a routine slot or a long appointment means across the group, which makes group-level utilisation reporting meaningless without manual reclassification.
Step 02
Chronic disease reviews, screening recalls and dental check-up recalls are generated from searches run inside each clinical system by local staff, on a schedule that depends on when someone remembers to run the search, with no group visibility into recall backlog or compliance rate.
Step 03
A group wanting to know whether a site has spare capacity for another clinician has to ask the site manager, who estimates utilisation from memory or a printed rota, because no system tracks actual room or chair occupancy against booked and attended appointments.
Step 04
NHS or insurance claims are submitted from the clinical or billing system, and remittance advice arrives separately by post or portal download. A member of the billing team manually matches each remittance line against the submitted claim, and short payments or rejections are chased individually with no queue or ageing report.
Step 05
Patients added to a waiting list months earlier remain on it whether or not their circumstances or clinical priority have changed, because validating an entry means someone telephoning the patient, and there is no prompt to say an entry is overdue for review.
Step 06
A did-not-attend is logged in the clinical system, but whether the patient is rebooked immediately, asked to confirm by phone first, or referred to a different pathway depends on whichever staff member handles the rebooking that day, rather than a documented and consistently applied rule.
Step 07
Once a month, someone extracts data from each site's clinical system, opens it in a spreadsheet, applies a set of filters that differ slightly from last month's, and produces a group report that two people in the same meeting will each independently doubt.
What we build
A shared definition of appointment types and slot durations that maps to each site's local clinical system session templates, so group-level utilisation and capacity reporting compares like with like rather than reconciling inconsistent local definitions after the fact.
Generates chronic disease, screening and check-up recalls on a defined schedule per site and per programme, tracks whether each recall resulted in a booked and attended appointment, and reports recall compliance and backlog at site and group level.
Tracks booked, attended and available time per room or chair against the session template, giving group operations a real utilisation figure rather than an estimate, and flagging sites with persistent spare capacity or persistent overbooking.
Matches submitted claims against incoming remittance advice automatically on claim reference and patient identifier, routes short payments, rejections and unmatched remittances to a reconciliation queue with an ageing view, and reports outstanding value by payer.
Tracks clinical priority, date added and last validation date for every waiting list entry, prompts automated or staff-led revalidation contact at a configurable interval, and reports the proportion of the list that is currently validated versus overdue.
Records did-not-attend history per patient and applies practice-defined rebooking rules — confirmation calls, slot restrictions or pathway referral — consistently rather than leaving the decision to whichever staff member handles the rebooking.
A single reporting layer drawing from every connected site regardless of which clinical system it runs, so recall compliance, DNA rate, utilisation and claims ageing are reported on the same definitions across the whole group, refreshed on a schedule rather than assembled by hand each month.
Manages clinician sessions, locum cover and role-based access across sites, so a locum working at two sites in a group has one identity and one access record rather than a separate account per site's clinical system.
Integrations
Clinical systems
Dental clinical systems
Billing and claims
National reference data
Operational systems
Where clinical systems differ between sites, the reconciliation layer normalises identifiers and appointment categorisation before reporting, and we confirm each site's available interface during discovery.
Data and compliance
Architecture note
The platform is built as an operational layer above the clinical systems at each site, reading appointment, recall search and identifier data through each system's available interface — GP Connect or IM1 pairing for primary care systems, and vendor-specific interfaces for dental systems — rather than requiring a single shared clinical system across the group.
A normalisation service reconciles differing appointment type taxonomies, session template structures and patient identifiers into a common model before anything reaches the reporting layer, which is where most of the domain-specific engineering effort sits, because no two sites configure their clinical system identically.
Claims reconciliation runs as an event-driven pipeline: submitted claims and incoming remittance files are ingested, matched automatically where the reference data allows, and anything unmatched is surfaced to a queue rather than silently dropped, so nothing is reconciled by assumption.
Reporting is built on a data warehouse populated by scheduled extracts rather than live queries against clinical systems, both because clinical system interfaces are rate-limited and because group reporting tolerates a short lag in exchange for a stable, comparable dataset across sites.
Timeline
Weeks 1–5
Map every site's clinical system, session template structure, claims process and current reporting method, and agree a common appointment and recall taxonomy for the group.
Weeks 5–12
Build the identifier and appointment normalisation service against each connected clinical system's interface, starting with the highest-volume site.
Weeks 10–20
Build the recall programme engine, room and chair utilisation tracking and waiting list validation workflow, tested against real historical data from one site.
Weeks 16–24
Build the claims and remittance matching pipeline and reconciliation queue, integrated with the payer or claims routes the group actually uses.
Weeks 22–28
Build the data warehouse and reporting views used by group operations, with definitions agreed and signed off by every site.
Weeks 26–36
Roll the platform out site by site, starting with a pilot site, resolving local data quality issues before extending to the rest of the group.
Indicative cost
Bands assume a UK primary care or dental group of two to fifteen sites. Larger estates or additional clinical system variants increase normalisation scope and are estimated separately.
Where this sits
Questions
No. The clinical system remains the system of record for the consultation and coded clinical entries. Practice management software sits alongside it to run scheduling, recall, room and chair utilisation, claims reconciliation and waiting list management — the operational work the clinical system was never designed to manage across a whole site or group.
Yes. We build a normalising layer that reconciles patient identifiers, appointment types and claim references across EMIS Web, TPP SystmOne, Vision or dental systems such as Dentally, so a group can report on utilisation, DNA rates and recall compliance at group level without manually merging exports.
Submitted claims are matched automatically against remittance advice on receipt, using claim reference and patient identifier, with variances — short payments, rejected items, missing remittances — routed to a reconciliation queue for a member of the billing team to resolve, rather than checked line by line against a spreadsheet.
A validated entry has a confirmed clinical priority, an up-to-date patient contact record and no outstanding query about continued need for treatment. We build validation reminders and automated patient contact into the waiting list module so entries do not sit unvalidated for months, which is the usual cause of inflated or inaccurate waiting list reporting.
The system records did-not-attend history per patient and can apply a practice-defined rebooking rule — for example, requiring a phone confirmation before a repeat DNA patient is offered another slot, or limiting rebooking to specific slot types — rather than treating every DNA the same way regardless of history.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us