Health systems
Clinical software is used by tired people under time pressure, and it is judged on whether it slows down a consultation.
Regulation determines the architecture rather than decorating it. Access has to be role-based and least-privilege, every read and write of a patient record has to be logged in a way that cannot be edited, data has to be encrypted in transit and at rest, and retention has to follow a schedule you can evidence. None of that is difficult individually, and all of it is close to impossible to add convincingly afterwards — an audit log that starts in month nine cannot prove anything about month eight.
Interoperability is where most of the unexpected effort goes. Standards like HL7 and FHIR exist, and every organisation implements them with local variation, so integrating with a hospital system is a bespoke exercise regardless of the standard's promise. Budget for a discovery phase against the actual systems you must talk to rather than against the specification, because the specification is the optimistic version.
The clinical interface itself is judged by a standard most software never faces: it is used during a consultation, by someone who is behind, while a patient watches. Anything that adds thirty seconds per appointment is felt across a whole clinic day and will be worked around. That makes the unglamorous work — defaults, keyboard entry, how few taps a common note takes — worth more here than any feature, and it is why these systems have to be tested in a real clinic rather than in a demo.
How we work
- Audit logging and role-based access from the first commit, because neither can be evidenced retroactively.
- Integration is scoped against the systems you actually have to talk to, not against the standard they claim to implement.
- Clinical screens are timed during real consultations. Thirty seconds per appointment is a whole clinic day.
What this includes
Pick what you need and send it over.