Healthcare software development
Most practices run patient contact across three or four disconnected surfaces: a website contact form, a third-party booking widget that does not see the real diary, a paper repeat prescription slip in a box by reception, and a separate portal for test results that nobody remembers the password for. Staff spend a meaningful share of the working day reconciling those channels against what EMIS Web, TPP SystmOne or Vision actually holds.
We build patient portals that read and write against the live clinical diary rather than a synchronised copy, apply the same clinical rules to repeat prescriptions and results release that the practice already runs manually, and treat identity verification and proxy access as first-class problems rather than an afterthought bolted on before go-live.
The workflow this replaces
Before a portal exists, every one of these steps runs through a person, a phone line or a paper form, and every step is an opportunity for a booking to land against the wrong slot type or a request to sit unactioned in an inbox.
Step 01
A patient calls asking for an appointment and the receptionist has to judge, from a description of symptoms, which session template and slot type the request belongs to — a ten-minute routine slot, a longer chronic disease review, a telephone triage slot or an urgent same-day slot — before checking whether that slot type exists anywhere in the clinician's diary that week.
Step 02
A handwritten or printed repeat slip is brought in or posted through the door, read by a member of staff who matches the drug name against the patient's repeat template in the clinical system, and queued for the prescriber to authorise. Illegible handwriting, discontinued brands and dose changes are resolved by phoning the patient or guessing.
Step 03
A blood test, scan or biopsy result arrives in the clinical system and sits in an inbox until a GP or consultant has reviewed it and coded a follow-up action. Nothing about the process tells the patient anything has happened; if they ring in advance of that review, staff have to judge on the phone whether it is safe to say the result has simply arrived.
Step 04
Requests for sensitive information — a referral letter, a fit note, a set of results — are typically verified by asking for name, date of birth and address, a standard that would not pass a formal identity assurance framework and that varies from one staff member to the next.
Step 05
A parent is given verbal or informal access to a child's record with no review date, and access is rarely revisited as the child grows older, which creates a compliance gap once the young person reaches an age at which they are entitled to control their own record.
Step 06
Where a total triage model operates, every contact request — by phone, online form or walk-in — is read by a duty clinician or care navigator, who decides whether it needs a same-day appointment, a routine booking, self-care advice or signposting elsewhere, all recorded by hand against a target response time.
Step 07
A federation or primary care network wanting to know DNA rates, results turnaround times or portal adoption across its member practices has to request an export from each practice's clinical system separately and reconcile the definitions used in each one.
None of this is a technology failure so much as the absence of a system designed for the workflow. The clinical record was built to hold a consultation, not to run a booking, prescribing and triage service around it.
What we build
Reads real clinician availability and slot type configuration from the connected clinical system through GP Connect appointment management or an IM1 booking interface, so a patient sees only slots the practice has actually opened for online booking, filtered by appointment reason.
Matches requested items against the patient's repeat template using dm+d codes, flags items nearing review date or requiring a synchronisation check, and routes each request into a prescriber approval queue with a clear audit trail of who authorised what and when.
Applies embargo windows and clinician sign-off rules before any result is visible to the patient, distinguishing between result types that can release automatically after a set period and those, such as certain cancer pathway results, that always require explicit clinician release.
Maps NHS Login identity verification levels to what the portal will disclose, so basic account functions are available at a lower verification level while results, full record access and proxy management require a higher level, consistent with national guidance.
Grants and reviews carer and parental access on a schedule tied to the patient's age and any safeguarding flag, automatically prompting a review or transition to patient-controlled consent at the practice's configured age threshold rather than leaving access open indefinitely.
Captures structured contact reasons rather than free text where the practice runs a total triage model, presents a prioritised worklist to the duty clinician or care navigator, and records the outcome and response time against the practice's own service standard.
Built and tested against WCAG 2.2 AA, including target size, focus appearance and dragging alternatives, with content authored at a reading level appropriate for a public health service audience and supported in the languages the practice's population requires.
Every booking, prescription request, results view and proxy access change is logged against the acting identity, whether that is the patient, a verified proxy or a member of staff, producing the audit trail expected under DCB0129 and DSPT self-assessment.
Integrations
Primary care clinical systems
National identity and demographics
Referral and results pathways
Coding and terminology
Messaging and payments
Which of these are reachable depends on the principal clinical system supplier's current interface offering and on what the practice or federation has switched on. We confirm the exact read and write scope during discovery rather than assuming full access.
Data and compliance
Architecture note
The portal is built as a layer that reads and writes against the clinical system's published interfaces rather than holding a separate copy of the clinical record. Where GP Connect covers the required capability, that is the default route; where it does not, we use IM1 pairing with the practice's principal system supplier, agreed and scoped before build starts because supplier lead times for interface access are often the longest item on the critical path.
Identity and consent are handled in a dedicated authorisation service that maps NHS Login verification levels and proxy relationships to a permission set, so the same booking or results endpoint behaves differently depending on who is asking and at what verification level, rather than embedding that logic in the presentation layer.
Prescription and results workflows run as asynchronous queues rather than synchronous calls into the clinical system, because prescriber approval and clinician sign-off are human steps with no fixed turnaround time. The portal reflects the current state of each request and notifies the patient when it changes, without ever implying a faster process than the practice actually runs.
Accessibility is treated as an architectural constraint: server-rendered pages, a tested component library against WCAG 2.2 AA and content that degrades gracefully without JavaScript, because a meaningful proportion of the patient population uses assistive technology, older devices or low-bandwidth connections.
Timeline
Weeks 1–4
Confirm which clinical system capabilities are reachable via GP Connect or IM1, map current results release and prescribing rules, and agree the proxy access policy and age transition thresholds with the practice's clinical safety officer.
Weeks 4–7
Design the NHS Login verification mapping, proxy access model and audit logging schema, and produce the initial DCB0129 hazard log entries for review.
Weeks 6–13
Build the live diary booking flow and the repeat prescription requesting and approval queue against a sandbox or test instance of the connected clinical system.
Weeks 12–18
Implement rule-based results release, embargo windows and, where required, structured message triage intake for a total triage model.
Weeks 16–20
Test against WCAG 2.2 AA success criteria with assistive technology, and produce the DTAC usability and accessibility evidence pack.
Weeks 19–24
Run a supervised pilot with a single practice or site, review hazard log entries against real use, then extend to the full estate.
Indicative cost
Bands assume UK primary care deployment with one principal clinical system per site. Mixed clinical system estates or bespoke IM1 interface work increase scope and are estimated separately.
Where this sits
Questions
Yes, where the practice or federation has enabled the relevant GP Connect appointment management capability or an IM1 booking interface. The portal reads live slot types and clinician availability rather than a cached schedule, so double-booking against the clinical system is not possible by design.
Every request is matched against the patient's current repeat template using dm+d codes rather than free text, so a request for a branded product resolves to the correct clinical concept before it reaches the prescriber's approval queue. Ambiguous matches are flagged for a human decision rather than guessed.
NHS Login issues an identity verification level rather than a single yes or no. Level P9 permits basic account access; higher levels, reached through document checks or an NHS App identity check, are required before the portal will release results or full record access, and we enforce that mapping in the authorisation layer.
Proxy access is time-bounded and reviewed against the patient's age rather than granted indefinitely. Automatic access for a parent typically ends around a child's eleventh or twelfth birthday under practice policy, after which continued access requires the young person's own consent, and the portal enforces the transition date rather than relying on staff to remember it.
Yes, that is a build requirement rather than an add-on: keyboard operation, focus visibility, target size and dragging alternatives are tested against the 2.2 success criteria before release, and the DTAC usability and accessibility evidence is produced alongside the build rather than retrofitted.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us