Clinical work does not wait for an IT problem. We build the appointment systems, patient record screens and access controls your staff use every day, and we make them fit the clinical software already in the building.
Booking is where most clinics lose their time. A slot held on the phone, a cancellation noted on paper and an online form nobody checks until noon will produce a double booking inside a week. We build one booking system that reception, the phone line and the patient website all write into. Reminders go out by text or email, a cancellation releases the slot straight away, and the list the clinician sees is the list the front desk is looking at.
Patient information carries duties that ordinary business data does not. We set access by role, so a receptionist sees what a receptionist needs and clinical detail stays with clinical staff. Every open, edit and export is written to a log that a manager can read without an engineer sitting next to them. Data is encrypted where it sits and where it moves between sites. Your own rules on consent and on how long records are kept get built into the system, rather than left to somebody remembering.
Very few clinics get to start again. There is a record system in place, an imaging store, probably a lab link, and a practice management package finance will not give up. We build against what is there, using HL7 and FHIR where your systems support them and a plainer file or API route where they do not. Where a system will not open up at all, we say so early. Quoting for an integration the vendor has closed off is how these projects go wrong.
Clinical software is judged on the morning it is unavailable, not on the year it worked. So the degraded mode gets designed first. Which lists are printed at the start of every clinic so a session can still run on paper, where results are written when the record will not open, who is called, and how the paper is reconciled back into the record afterwards rather than sitting in a tray for a fortnight. That last part is where the harm usually lives, because a result recorded on paper and never entered is invisible to the next clinician who sees the patient. We write the downtime procedure alongside the software, rehearse it once before go live, and print it, since a continuity plan that exists only on the intranet is not available during the outage it was written for.
Ask what happens on a busy ward and you get an honest answer: one account left open on the workstation, because signing in takes thirty seconds and there is a patient waiting. It is entirely rational, and it removes the two things the record is supposed to give you, which are an audit trail that means anything and a note attributed to the person who actually wrote it. The fix is not another policy reminder. It is making identity cheaper than the workaround: card or badge sign in rather than typing, a session that follows the clinician to the next machine instead of making them start again, a lock timeout set from how the room is really used, and forms that reopen where they were left. If signing in is faster than sharing, sharing stops.
One diary that reception, the phone line and the patient website all write into, with a cancellation releasing the slot immediately and reminders going out before the clinic loses the appointment to a no-show.
Self check-in, forms completed before arrival, results and letters. Built for somebody who is anxious, on an old phone, and not willing to create an account in order to answer three questions.
Assessments, checklists and pathways that follow the order a clinician actually works through them, with mandatory fields chosen by clinical need rather than by whoever wanted the data for a report.
HL7 v2, FHIR or a plainer file route, built once into an interface layer so a supplier's upgrade becomes a change in one place rather than an outage in four departments.
Access by role and by relationship to the patient, with every read, edit and export written to a log a manager can query without an engineer sitting next to them.
Who is waiting, for how long, for what, and where the queue is genuinely blocked, taken from the record rather than assembled in a spreadsheet on the last Friday of the month.
Whatever the building runs as its record of truth. We build alongside it and write back where it owns the data, because a second copy of the patient is a safety problem before it is an engineering one.
Registration, scheduling and the money side. Finance will not give this up for a departmental project, and they are right, so we integrate with it rather than quietly duplicating it.
Results and reports arriving as HL7 messages or DICOM studies and filing against the right patient. The matching rules matter more than the transport, because a result on the wrong record is worse than no result.
HL7 v2 in most existing estates, FHIR where a supplier has moved, and a file or database route where neither exists. We confirm which one you have before quoting rather than after.
Pre-authorisation, claims and the paperwork that decides whether the provider gets paid. Routinely the least automated part of a clinic and the one generating the most rework for the fewest people.
Matching a patient across systems, and knowing which member of staff did what. Duplicate patient records are the quiet cost of getting this wrong, and they are expensive to unpick years later.
A single service, one diary, reception and the phone line included. Small enough to reverse, and it exposes the scheduling rules nobody ever wrote down.
Usually results or demographics. Staff can name it in the first meeting, the benefit is visible within a week, and it proves the integration route works before anything larger depends on it.
Who can open what, and who did last month. It is cheap, it is uncomfortable, and it is the work most likely to be asked for at the next inspection.
What staff do when the record system is unavailable during a clinic, written down, printed, and tried once while nothing is actually wrong.
As the constraint the whole design is built around rather than a checklist at the end. Access is by role and by relationship to the patient, every read and write is logged in a form that can be produced later, data is encrypted in transit and at rest, and test environments never carry real records. Where a requirement makes a feature impossible, that is said during design rather than discovered during an audit.
That is usually the bulk of the work. Practice management systems, laboratory systems and scheduling all tend to have an integration route, whether a modern API or an older HL7 or file-based one. We build the interface layer so those connections sit in one place, which is what keeps a supplier’s upgrade from becoming your outage.
It is agreed in writing before it matters, along with what happens in the meantime. Clinical software needs a defined degraded mode: what staff do, what is captured on paper, and how it is reconciled afterwards. Systems designed as though downtime cannot happen are the ones that cause the most harm when it does.
Both, and the work differs more in scale than in kind. A single practice has the same obligations around records and consent as a large provider, with less staff time to spend on them, which usually means the right answer is simpler software and more automation of the routine parts rather than a smaller version of an enterprise system.
It is common, and it is the item that most often breaks a budget late. Plenty of clinical suppliers treat the interface as a licensed product with its own fee, its own lead time and its own queue, and the quote tends to arrive after your project already has a date. So we ask in the first fortnight: what does the supplier charge, what will they support, how long is their queue, and who at the supplier has to approve it. If the answer is that they will not open the system at all, you need to know that before design starts rather than after. Occasionally the honest conclusion is that the interface is not worth its price and a different route serves the same clinical need.
No. Test and development environments carry manufactured or de-identified data, and there is no route by which a live record reaches a laptop. The cost of that is worth naming, because manufactured data does not contain the strange records that break software, so the awkward cases have to be described by clinical staff and built deliberately rather than found by accident. Where a fault can genuinely only be reproduced against live data, that happens in the live environment, by a named person, with the access logged and time limited. Anyone who offers to take a copy of the database home to work on is telling you something important about how they work everywhere else.
Not casually. Software that makes or supports a clinical decision sits in a different category with its own regulatory expectations, and it needs clinical ownership, a documented safety case, a hazard assessment and a named clinician accountable for what it outputs. We are glad to build in that setting, working with whoever holds clinical governance for your organisation. What we will not do is add a suggestion feature to a general system because it demonstrates well, since the risk of that lands on a clinician who assumes somebody checked the number. If what you actually want is a prompt that surfaces information the clinician already relies on, that is usually a safer and cheaper answer to the same problem.
Hosting is decided before the build rather than migrated afterwards, and for most providers here that means records staying in country. The question worth asking any supplier, though, is the exit one. The data is yours and comes out in a documented format rather than a proprietary export, the schema is written down, the code sits in a repository your organisation owns, and the hosting and third-party accounts are in your name rather than ours. We would rather set that out at the start than have you find it during a handover. A clinical supplier who cannot describe a clean exit is relying on the exit being difficult, and that shows up in every other conversation you have with them.
We are happy to answer any questions you have and help you work out which of our services fit your needs.
