Healthcare software carries an obligation most business software does not: when it is wrong or unavailable, the consequences land on patients and on the staff trying to care for them.
That justifies engineering practices which would be over-specified elsewhere, and it changes which trade-offs are acceptable. In most sectors you can ship something that is fast and mostly right and correct it later. Here, “mostly right” in a medication record or a staffing roster is not a defect to be triaged next sprint.
What we build
- Patient portals. Appointment booking, results access, secure messaging and repeat-prescription requests.
- Scheduling and resource management. Clinician calendars, room and equipment allocation, waiting lists, and the cancellation handling that largely determines utilisation.
- Workforce management. Rostering and shift allocation across large clinical and support workforces, including qualification matching, rest-period compliance and last-minute cover.
- Clinical workflow tooling. Referral pathways, triage, care-plan tracking and structured note capture.
- Integration. Connecting to existing patient administration systems, laboratory systems and national infrastructure, typically over HL7 v2 or FHIR.
Non-negotiables
Data protection by design
Under GDPR, health data is a special category with a higher bar. In practice: encryption at rest and in transit, role-based access enforced server-side rather than by hiding buttons in the interface, and access logging detailed enough to answer who viewed which record and when.
That last one is not optional. Inappropriate-access investigations are a normal part of healthcare operations, and a system that cannot answer the question has failed at something basic.
Availability during clinic hours
Deployment windows sit outside them. That sounds obvious and is routinely violated by teams used to shipping continuously.
More importantly, degraded modes are designed deliberately. If a laboratory integration is failing, a clinician must still be able to open a patient record. A non-critical dependency must never be able to take down a critical path. Deciding in advance which dependencies are which is an architectural exercise, not an operational one.
Data integrity over convenience
Clinical records are corrected by appending, never by overwriting. The prior value, who changed it, when, and why all remain visible.
This is occasionally argued against on the grounds that it complicates the interface. It does. It is also the difference between a record that can be relied on in a clinical review and one that cannot.
Accessibility is a requirement, not a score
Patient-facing services are used by people with a wide range of impairments, frequently under stress, sometimes on old devices. WCAG 2.2 AA is the working standard, and it needs verifying with actual assistive technology rather than an automated audit. Automated tools catch perhaps a third of real barriers.
Scheduling is a constraint problem
Where we build rostering and allocation, the distinction that matters is between two kinds of constraint. Hard constraints cannot be violated: qualification requirements, statutory rest periods, contracted maximums. Soft constraints should be optimised but can bend, such as preferred locations, shift-pattern continuity and fair distribution of unsociable hours.
Encoding that difference explicitly is what allows a system to generate a roster automatically without generating an illegal one. Allocating greedily in sequence produces a schedule that is valid at the start and impossible at the end, because early assignments consume the availability later ones needed.
Integration is where the effort goes
Healthcare is not a greenfield sector. Almost every system we build has to coexist with a patient administration system that predates it, a laboratory system with its own model, and often national infrastructure with prescribed message formats.
HL7 v2 remains widespread despite FHIR being the modern answer, and in practice you support both. Message formats vary between installations of nominally the same product, so “we speak HL7” is never a complete answer to whether two systems will talk.
We plan integration work as its own workstream with its own risk profile, because treating it as a task at the end of a project is how healthcare builds slip.
Where we fit, and where we do not
We are a software engineering partner. We are not a clinical safety consultancy, and we are not your regulatory advisor.
Where a system falls under medical device regulation, we work alongside your regulatory lead and build the traceability their process requires. That boundary is easier to cross than teams expect, particularly with anything that supports a clinical decision. What we will not do is tell you which side of that line your product sits on. Get that assessed early, because the answer materially changes the cost and the timeline.
What we would ask you first
Which existing systems the new one must coexist with, and what they speak; whether any part of what you are describing supports a clinical decision; who your Data Protection Officer is and whether they have seen the proposal; what your availability expectations are during clinic hours; and what the current process does when it fails.
The last question usually surfaces the requirements nobody thought to write down.