How healthcare delivery differs: regulatory classification, interoperability standards, clinical safety duties, and practices that survive audit.
Healthcare product engineering is ordinary software engineering constrained by obligations that determine architecture, release process, and team composition from the first sprint. Teams that discover those obligations at month nine rebuild; teams that design for them ship.
The determining question is asked early and often answered casually: is this a medical device?
Regulatory classification decides everything downstream
Software that diagnoses, treats, prevents, or monitors a condition is generally regulated as a medical device. Software that stores, transfers, or displays data without interpreting it generally is not.
The boundary is narrower than product teams assume. A system that calculates a dosage, triages by acuity, or flags a result as abnormal has crossed it. A system that displays a value a clinician interprets has not.
Under UK MDR and the EU MDR, most clinical decision-support software classifies at Class IIa or above, which requires notified body involvement, a quality management system, clinical evaluation, and post-market surveillance. In the US, FDA treatment depends on whether the software qualifies as a device and whether it falls under enforcement discretion; clinical decision support has specific criteria around whether the clinician can independently review the basis of a recommendation.
Consequences for engineering:
A quality management system, typically ISO 13485, governing how you develop. Not a document produced for audit — a process you actually follow, with evidence.
IEC 62304 software lifecycle compliance, with rigour scaled to safety classification.
Design controls — requirements traceable to design, to implementation, to verification. Every requirement traceable to a test, both directions.
Change control. Significant changes may require regulatory notification or re-certification. Continuous deployment as practised elsewhere may be unavailable for regulated components.
Risk management under ISO 14971, maintained throughout the lifecycle.
Establish classification before architecture. It determines whether you can deploy weekly or must batch releases through a quality process, and that shapes everything about how the team works.
A common and legitimate strategy: architect so regulated and unregulated functionality are genuinely separable. Scheduling, messaging, and administrative features iterate freely; the clinical calculation engine sits behind a controlled boundary with its own release process. This requires deliberate design and is difficult to retrofit.
Interoperability is a first-class requirement
Healthcare software that cannot exchange data has limited value, and integration is where timelines slip.
HL7 FHIR is the modern standard and where new development should start. Resource-based, REST-friendly, well-tooled. The complication is profiles — UK Core FHIR, US Core, and national variants constrain and extend base resources differently. Building against base FHIR and discovering the local profile late means rework.
HL7 v2 remains extremely common in hospital environments. Pipe-delimited, decades of accumulated local variation. Many integrations still require it, and "we support HL7 v2" means little without specifying message types and the receiving system's particular dialect.
DICOM for imaging, with its own infrastructure assumptions.
SNOMED CT, ICD-10, LOINC for terminology. Mapping between local codes and standard terminologies is a persistent, underestimated workstream requiring clinical input — not a lookup table someone builds in a sprint.
In the UK specifically, NHS integration adds NHS Number validation, Spine services, PDS for demographics, and increasingly NHS Login for patient identity. Each has its own onboarding, assurance, and technical conformance process with lead times measured in months.
Budget integration as a workstream, not a task. On many healthcare products it exceeds core feature development.
Clinical safety in the UK
NHS deployment requires compliance with DCB0129 (manufacturers) and DCB0160 (deploying organisations). These mandate:
A named Clinical Safety Officer, a registered clinician with appropriate training.
A hazard log identifying clinical risks, mitigations, and residual risk.
A clinical safety case report documenting the safety argument.
Ongoing review as the system changes.
This is not documentation produced at the end. The hazard log should influence design — identifying a hazard around ambiguous unit display should change the interface, and the evidence of that change is what the safety case records.
Teams that treat DCB0129 as a paperwork exercise before go-live find hazards that require design changes, at the worst possible moment.
Engineering practices that survive audit
Traceability from requirement to test. Every requirement links to design, implementation, and verification, navigable in both directions. Modern tooling makes this less painful than it sounds — issues linked to commits linked to tests — but it must be deliberate from the start.
Documented, reproducible builds. You must reproduce the exact artefact deployed on a given date. Pinned dependencies, recorded toolchain versions, retained build artefacts.
Verification evidence retained. Test results kept, not merely observed passing in CI. The evidence must survive.
Controlled environments with representative data. Development against real patient data is generally unacceptable. Realistic synthetic data that exercises edge cases is required, and generating it well is a genuine task — clinically implausible synthetic data produces software that fails on real patients.
Audit logging as a functional requirement. Who accessed which record, when, and why. In many jurisdictions this is a legal obligation with defined retention.
Segregation of duties. The person who wrote the code should not be the sole approver of its release into a regulated environment.
Team composition
Healthcare product teams need roles that general product teams do not:
Clinical Safety Officer — registered clinician, appropriately trained.
Regulatory lead — owns classification, technical file, and notified body relationship.
Quality manager — maintains the QMS and audit readiness.
Clinical input into design, ongoing rather than consultative. Practising clinicians who use the workflow, not only clinical executives.
Integration specialists with actual FHIR and HL7 v2 experience. This is scarce and expensive, and generalists learning on the project is a common source of delay.
Engaging clinicians only for requirements gathering and validation produces software that is technically correct and clinically unusable. Clinical workflow is full of constraints that are invisible from outside and obvious from within.
Sequencing
Determine regulatory classification with qualified advice. Everything depends on it.
Establish the QMS before substantial development, if regulated.
Design the regulated boundary so unregulated functionality can iterate freely.
Start the hazard log at design, not before go-live.
Prototype integration early against real target systems. Assumptions about interfaces are usually wrong.
Build traceability into tooling from the first sprint. Retrofitting it means reconstructing history you no longer have.
Frequently asked questions
Is our software a medical device? If it diagnoses, treats, prevents, or monitors a condition — or interprets data to produce a clinical recommendation — probably yes. Storing, transferring, or displaying data without interpretation generally is not. Get qualified advice before architecture, because classification determines your entire delivery process.
What does regulatory compliance add to timelines? For a Class IIa device, expect six to twelve months additional for QMS establishment, clinical evaluation, and notified body assessment, running partly in parallel with development. Building the QMS after development is substantially slower.
FHIR or HL7 v2? FHIR for new development. HL7 v2 where hospital systems require it, which remains common. Identify the specific national profile early — building against base FHIR and discovering the local profile late causes rework.
What is DCB0129? The NHS clinical risk management standard for health software manufacturers. It requires a named Clinical Safety Officer, a hazard log, and a clinical safety case report. Treat it as a design input rather than pre-launch documentation.
Can we deploy continuously? For unregulated components, yes. For regulated functionality, significant changes may require notification or re-certification. Architecting a clean separation between the two is the standard approach and must be designed in from the start.
Further reading
Related
Written by
Moueen Togarvi
Founder & CEO at Voquarn Code, focused on product engineering, search growth, and practical AI systems.