Software defects in most industries cause financial loss, reputational damage, and operational disruption. In healthcare, they can cause patient harm. A drug interaction check that fails to fire, a dose calculation that rounds the wrong way, a patient matching algorithm that merges two records incorrectly — these are not hypothetical risks. They are the real-world consequences of inadequate software quality assurance in clinical systems. This guide describes how healthcare organisations should approach QA across the software development and implementation lifecycle.
Why Healthcare Software Failures Have Clinical Consequences
Clinical software operates in a domain where errors have physical consequences for patients. The systems most directly involved in clinical decisions — prescribing systems, dosing calculators, clinical decision support, laboratory and imaging systems, patient monitoring — operate in conditions where a software defect can directly affect patient safety.
The historical record of software-related clinical incidents includes cases of incorrect radiation doses delivered due to software faults in radiotherapy systems, medication overdoses resulting from dose calculation errors in infusion management software, and diagnostic errors caused by incorrect result display in laboratory systems. These incidents drive the regulatory and standards frameworks that govern medical device software, and they provide the context for understanding why QA in healthcare is a patient safety issue, not just an IT quality issue.
QA in the Software Development Lifecycle
Quality assurance is not a phase that happens at the end of development before release. It is a set of activities distributed across the full software development lifecycle (SDLC).
Requirements Review
Defects introduced at the requirements stage are the most expensive to fix. A requirement that is ambiguous, incomplete, or internally inconsistent produces software that behaves incorrectly by design. Requirements review — a structured process of examining requirements for clarity, completeness, and testability before development begins — prevents these defects from propagating forward.
In healthcare, requirements review should include clinical stakeholders who can identify clinical workflow implications that technical authors may miss. A requirement that is technically clear but clinically incorrect is a defect.
Unit Testing
Unit testing verifies that individual software components behave correctly in isolation. Developers write unit tests for functions and modules as they build them. Automated unit test suites are run continuously in the development pipeline, catching regressions immediately.
Unit testing catches a large proportion of coding defects at minimal cost. Code coverage metrics — the percentage of code exercised by unit tests — are a useful proxy for unit test completeness, though high coverage alone does not guarantee quality.
Integration Testing
Integration testing verifies that components and systems work correctly together. In healthcare, where clinical systems exchange data via HL7 interfaces, FHIR APIs, and proprietary integrations, integration testing is particularly important. A component that works correctly in isolation may fail when it sends or receives data from a real interface under realistic conditions.
Integration test environments should mirror production as closely as possible, including representative data volumes and realistic interface behaviour.
User Acceptance Testing (UAT)
UAT is performed by end users — clinical and operational staff — who verify that the system supports their actual workflows and meets their requirements. UAT is not a rubber stamp; it is a genuine verification activity that catches issues the development and test teams have not anticipated.
Effective clinical UAT requires:
- Clearly documented test scenarios based on real workflows, not feature lists
- Adequate time for clinical staff to perform testing without being rushed
- A clear process for raising and tracking defects
- Defined acceptance criteria that specify what constitutes a pass
UAT should be completed before any go-live decision is made. Go-live decisions made before UAT is complete are a risk management failure.
Regression Testing
Every change to a clinical system — whether a new feature, a bug fix, or a configuration change — has the potential to introduce unintended consequences in functionality that previously worked. Regression testing re-executes tests for existing functionality after a change to verify that nothing has broken.
Manual regression testing for a complex clinical system is time-consuming. Automated regression test suites, built up over the life of the system, allow comprehensive regression testing to be executed in a fraction of the manual time. Building automation investment gradually — prioritising the most critical workflows first — is a practical approach for resource-constrained teams.
IEC 62304: Medical Device Software
IEC 62304 is the international standard for the lifecycle processes of medical device software. It applies to software that is a medical device in its own right (standalone software that performs a medical function) and to software embedded in a medical device. The standard classifies software systems and units by safety class, based on the severity of harm that could result from a software failure:
- Class A: No injury or damage to health is possible
- Class B: Non-serious injury is possible
- Class C: Death or serious injury is possible
The higher the safety class, the more rigorous the development and testing requirements. Class C software requires, among other things, software unit testing of all units, integration testing, system testing, and full traceability from requirements through to test evidence.
Healthcare organisations that develop or extensively customise clinical software should understand whether IEC 62304 applies to their software and maintain documentation accordingly. Many enterprise clinical systems fall into this category, including custom clinical decision support logic, dosing calculators, and patient-facing health applications.
Test Case Design for Clinical Workflows
Effective test cases for clinical software are designed around workflows, not features. A test case for a medication prescribing module should describe a clinical scenario: "Dr. Smith is prescribing amoxicillin for a patient with a documented penicillin allergy. The system should alert the prescriber and require a documented clinical override before the prescription can be saved."
This workflow-based approach catches defects that feature-based testing misses, because it tests the system behaviour in realistic clinical conditions rather than in laboratory isolation. Clinical staff who participate in test case design bring knowledge of edge cases — unusual patient presentations, atypical workflows, rare but significant scenarios — that technical testers do not have.
Negative test cases — testing what happens when things go wrong — are as important as positive test cases. What happens when a network connection drops mid-entry? What happens when a patient record is locked by another user? What happens when a required field is left empty?
Performance Testing for High-Volume Systems
Clinical systems must perform adequately under realistic load. A system that responds in two seconds when five users are logged in may become unusable when two hundred concurrent users are active during the morning admission rush.
Performance testing establishes baseline performance characteristics and identifies the load thresholds at which performance degrades below acceptable levels. Load testing subjects the system to realistic expected loads. Stress testing identifies the breaking point by gradually increasing load beyond normal expectations. Performance requirements — maximum acceptable response times for key operations under defined concurrency levels — should be established as part of system requirements and verified through testing before go-live.
Test Environments and Data Management
Test environments that do not resemble production produce test results that do not predict production behaviour. Healthcare organisations should maintain at least two non-production environments: a development/integration environment for active work, and a staging environment that mirrors production as closely as possible for pre-release testing.
Managing test data in healthcare requires special attention to patient privacy. Real patient data must not be used in non-production environments without de-identification. De-identification processes should produce data that is realistic — representative of the data distributions, code values, and edge cases found in production — while removing all direct and indirect patient identifiers. Synthetic data generation tools can supplement de-identified data, particularly for edge cases that may not appear frequently in real data.
Defect Management and Release Management
Defects identified during testing must be tracked through a structured defect management process. Each defect should be categorised by severity (the clinical or operational impact if it reaches production), priority (when it must be fixed), and status (open, in progress, resolved, verified).
Release management defines the process for moving software changes from development through test environments to production. In healthcare, releases must be planned carefully to minimise disruption to clinical operations, communicated to affected staff, and accompanied by rollback plans in case a release introduces unexpected problems.
FZ Consulting LLP supports healthcare organisations in developing testing strategies, QA frameworks, and release governance for clinical systems. Contact us to discuss your software quality requirements.