← Back to use cases

IEC 62304 and the Backend Layer: SOUP, Verification, and Lifecycle Evidence

How IEC 62304 applies to a server-side software component of a medical device, including software safety classification, SOUP management for the backend stack, verification activities the backend has to support, and the lifecycle evidence a notified body expects to see.

Executive Summary

IEC 62304 is the software lifecycle standard for medical device software. It defines the activities a manufacturer has to perform across the lifecycle of the software, from planning through release through post-market surveillance. The standard is widely understood as a standard for the device-level software that runs on the medical device itself. It also applies to server-side software that is part of the device, but the backend-specific guidance is harder to find than the device-software guidance.

This paper is a backend-layer companion to IEC 62304. It walks through the parts of the standard that apply to a backend, including software safety classification, SOUP (Software of Unknown Provenance) management, verification activities, configuration management, and the lifecycle evidence a notified body expects to see during an audit.

The audience is regulatory affairs leads, engineering leads, and quality leads of medical device manufacturers whose product includes a backend layer. The paper assumes familiarity with the standard’s high-level structure. It focuses on how the activities translate to the backend’s reality and where teams most often get stuck.

The paper is not legal advice and does not replace the standard text or notified body guidance. It is meant as a working reference for the technical and quality decisions involved in applying the standard to a backend.

1. Where the Backend Sits in IEC 62304

IEC 62304 covers software that is part of a medical device. Three forms of backend qualify.

The first is a backend that is itself a Software-as-a-Medical-Device (SaMD) under MDR. The backend runs server-side and performs a clinical function (decision support, alarm generation, image analysis). The backend is the device, and IEC 62304 applies to the backend in full.

The second is a backend that is part of a medical device system (typically a mobile or web app that depends on the backend for clinical function). The backend is part of the device system, and IEC 62304 applies to the backend as a software component of the device.

The third is a backend that supports a medical device but is not itself part of the device’s clinical function (analytics, reporting, configuration). The backend is in scope for the manufacturer’s QMS and for some IEC 62304 activities (configuration management, security advisories) but not for the clinical-function-specific activities.

The first and second cases are where the backend sits squarely in IEC 62304. The third is a lighter touch but is not exempt.

2. Software Safety Classification

IEC 62304 classifies software into three safety classes:

  • 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 safety class determines the rigour of the lifecycle activities. Class A requires the basic activities; Class B adds detailed design activities; Class C adds detailed verification activities and the most extensive evidence requirements.

For a backend, the classification depends on the worst-case clinical consequence of the backend’s failure. A backend that fails in a way that loses or corrupts patient data with potential clinical consequences is typically Class B at a minimum. A backend that fails in a way that leads to a missed alarm, a wrong dose, or a delayed diagnosis is typically Class C.

Classify the entire backend at the highest applicable class and document the classification in the device’s risk management file. Splitting the backend into components with different classes is technically allowed but creates a configuration management burden that often exceeds the savings.

3. SOUP Management for the Backend Stack

Software of Unknown Provenance (SOUP) is software whose development records the manufacturer does not own. Most of the backend stack is SOUP: the operating system, the language runtime, the database, the FHIR server, the dependencies pulled in through the package manager. IEC 62304 requires the manufacturer to manage each SOUP component.

3.1 SOUP inventory

The manufacturer maintains an inventory of every SOUP component used in the backend, with the version, the source, the licence, and the documented use. The inventory is generated automatically from the build system; manual inventories drift fast and are a common audit finding.

3.2 SOUP risk assessment

Each SOUP component has a documented risk assessment that covers the failure modes the component contributes to the device’s risk. The assessment does not have to be exhaustive; it has to cover the failure modes that matter for the device’s clinical function.

A tiered assessment scales. A small number of “core” SOUP components (the database, the FHIR server, the runtime) get a detailed assessment. The long tail of dependencies gets a shallower assessment that documents the supplier’s status, the licence, and the security advisory channel.

3.3 SOUP version management

Each SOUP component is pinned to a specific version, and version changes go through a documented review. A dependency upgrade that the build system performs without review is not compliant with the standard’s expectations.

The practical pattern is dependency lock files (lockfiles, manifests) committed to source control, with version changes proposed through pull requests that go through the configured review.

3.4 SOUP advisory handling

Security advisories that affect SOUP components have to be reviewed and acted on. The backlog of unreviewed advisories is a common audit finding. Automated advisory ingestion (vulnerability scanners, dependency tracking) feeding into a documented review process with a defined SLA per severity is what scales.

3.5 The managed-backend case

When the manufacturer uses a managed FHIR backend (a vendor’s deployment running on the vendor’s infrastructure), the SOUP boundary moves. The backend itself becomes a single SOUP component from the manufacturer’s perspective; the components inside the backend are the vendor’s responsibility under their own QMS.

Require the vendor to publish the SOUP-equivalent artifacts (release records, SOUP inventory, change history, security advisories) on an ongoing cadence, so the manufacturer’s QMS plugs those artifacts into the manufacturer’s own dossier rather than reconstructing them.

4. Verification Activities

IEC 62304 requires verification activities at multiple levels: software requirements, software architecture, software detailed design (Class B and C), software unit (Class C), software integration, and software system. The verification activities for the backend translate as follows.

4.1 Software requirements verification

The backend’s software requirements are derived from the device’s system requirements. The verification activity confirms that the requirements are correct, complete, and traceable to the system requirements.

Write the requirements in a tracked format (a requirements management tool, a structured markdown document, a tracked file in a documentation repository) with explicit links to the system requirements. The traceability is the verification artifact.

4.2 Software architecture verification

The backend’s software architecture is verified against the requirements. The verification activity confirms that the architecture supports the requirements and that the architecture’s design decisions are documented.

An architecture document that names the major components, the interfaces between them, the data flows, and the design decisions, with explicit links to the requirements each component supports, satisfies the activity.

4.3 Software unit verification (Class C)

For Class C software, unit-level verification is required. Automated unit tests with coverage targets, integrated into the CI pipeline, with the coverage report committed as evidence, is the standard implementation. The standard does not specify a coverage percentage; the manufacturer documents and justifies the target.

4.4 Software integration verification

The integration verification confirms that the components fit together correctly. Automated integration tests that exercise the major data flows, integrated into the CI pipeline, with the test report committed as evidence, is the standard implementation.

4.5 Software system verification

The system verification confirms that the assembled backend meets the requirements. A structured test suite that exercises the backend against the requirements, with the test report committed as evidence and reviewed before each release, is the standard implementation.

4.6 Verification under the data-protection envelope

A common challenge for the backend is that the verification activities involve test data. Test data that includes real patient data is a data-protection problem; synthetic data that does not exercise the real data shapes is a verification problem. A synthetic data generator that produces structurally-real data without using real patient identities resolves both, and the generator is itself part of the verification toolchain.

5. Configuration Management

Configuration management covers the identification, control, and reporting of the configuration items that make up the backend. For a backend, the configuration items include the source code, the build artifacts, the deployment configurations, the SOUP inventory, the test results, and the documentation.

5.1 Source control as the configuration baseline

Treat the source control system as the configuration baseline. Every release ties to a commit; every commit ties to the developer who made it; every change ties to a code review. The release process produces a tagged commit and an immutable artifact built from it.

5.2 Deployment configurations

Deployment configurations (environment variables, secret stores, service definitions) are also configuration items and should be in source control alongside the application code. Configurations applied through console UIs without source-control records are a common audit finding.

5.3 Release records

Each release ships with a release record that lists the included changes, the verification activities performed, and the SOUP versions. The record is committed as evidence.

Generate the release record automatically from the source control history, the verification reports, and the SOUP inventory. Manual release records are a maintenance burden and drift fast.

6. Risk Management Coupling

IEC 62304 is coupled to ISO 14971 (risk management for medical devices). Each backend failure mode that contributes to a hazard is captured in the risk management file with a risk control measure and a verification activity.

6.1 Failure modes in scope

For a backend the failure modes that matter most are: data loss, data corruption, unauthorised access, denial of service, and incorrect computation. Each failure mode has a defined risk control (backup and recovery, validation and constraint checking, authentication and authorization, scaling and rate limiting, verification testing) and a verification activity.

6.2 Risk control verification

Each risk control’s verification has to be documented. Bind the risk control to a specific verification artifact (a test, a procedure, a configuration check) and refer to the artifact from the risk management file.

6.3 Cybersecurity in the risk file

Cybersecurity-related failure modes are part of the risk management file. FDA pre-market guidance and EU MDR coordination group guidance both expect cybersecurity threats to be modelled alongside safety hazards. A cybersecurity threat model that shares the structure of the safety risk model and feeds into the same risk file is the standard implementation.

7. Post-Market Surveillance

After release, the backend’s lifecycle continues. Post-market surveillance covers monitoring the backend in production, handling field issues, and feeding the findings back into the risk file and the requirements.

7.1 Monitoring

Operational monitoring (uptime, latency, error rates, audit completeness) feeds into a defined incident response process. Incidents are triaged, root-caused, and where appropriate, fed back into the risk file.

7.2 Field issue handling

Field issues reported by users or clinicians go through a documented complaint handling process under the manufacturer’s QMS. The backend’s role is to support the investigation with audit logs, error logs, and version-tagged reproductions.

7.3 Periodic safety updates

Major software updates that change the device’s safety profile have to be reported under MDR Article 88 (Periodic Safety Update Reports). The backend supports this by maintaining a lifecycle log of the safety-relevant changes.

8. The Notified Body Audit

Notified body audits of the backend layer focus on the configuration management discipline, the SOUP management, the verification evidence, and the post-market surveillance. The audit is more often a documentation exercise than a code review; the auditor wants to see that the manufacturer’s QMS produces the artifacts the standard requires.

8.1 What the auditor asks for

The auditor typically asks for the SOUP inventory, the release records for the recent releases, the verification reports for those releases, the risk management file, the post-market surveillance records, and a sample of incidents and their resolution. The auditor cross-checks the artifacts against each other (a release record references SOUP versions that match the inventory, a verification report references requirements that match the requirements file).

8.2 What the auditor pushes back on

The pushback patterns we see most often are: SOUP inventories that drift from the build system; release records that are produced manually after the fact and miss commits; verification reports that exercise a happy path but not the failure modes; post-market surveillance records that are reactive only.

The fix in each case is to push the artifact production into the engineering workflow rather than producing it for the audit.

8.3 Software-of-the-vendor audits

When the backend is supplied by a vendor, the auditor reviews the vendor’s QMS through the supplier evaluation process. The vendor does not have to be ISO 13485 certified, but the supplier evaluation has to demonstrate that the vendor’s processes satisfy the manufacturer’s QMS requirements.

A vendor whose published release artifacts are built around the manufacturer’s audit needs (SOUP inventory, release records, verification evidence, security advisory handling) reduces the work substantially. A vendor whose materials are sales-shaped rather than engineering-shaped creates work the manufacturer has to do themselves.

9. Where Teams Most Often Get Stuck

Across IEC 62304 audits of backend layers, four issues account for most of the time-sinks.

9.1 SOUP discipline

Maintaining an accurate SOUP inventory across a stack with hundreds of dependencies is a discipline problem. Teams that automate the inventory through their build system spend a small amount of effort continuously; teams that rebuild the inventory before each audit spend a lot of effort each time.

9.2 Verification rigour

Verification activities that test the happy path but not the failure modes are a common finding. The fix is to write the verification suite around the risk file’s failure modes, not around the requirements alone.

9.3 Release record discipline

Release records that are produced manually after the fact are a common finding. The fix is to generate the records from the source control history and the verification artifacts as part of the release pipeline.

9.4 Cybersecurity coupling

Cybersecurity threats that are managed in a separate document from the safety risk file are a common finding. The fix is to use a single risk file structure that covers safety and security and to feed both threat models into it.

10. The Backend’s QMS-friendly Pattern

A backend can make the IEC 62304 work substantially easier for its manufacturer-customers by shipping a small number of artifacts as a matter of course.

  • A SOUP inventory generated from the build system, available per release.
  • Release records that list the included changes, the SOUP versions, and the verification artifacts.
  • Verification reports for the supplier’s own development that the manufacturer can reference under their supplier evaluation.
  • A security advisory channel for production deployments.
  • A documented incident response process with notification procedures.

A vendor that ships these artifacts as ongoing engineering output reduces the manufacturer’s IEC 62304 work to integrating the published artifacts into the manufacturer’s QMS rather than reconstructing them.

11. Closing

IEC 62304 applied to a backend is mostly about discipline. The activities are well-defined; the artifacts are well-defined; the trick is to produce them as part of the engineering workflow rather than as an audit project. The standard rewards teams that automate the artifact production, that ship release records and SOUP inventories per release, and that couple their verification activities to a thoughtful risk file.

The standard is also forgiving for teams that bring in a vendor whose published release artifacts are built around the standard’s needs. Those artifacts substitute for a substantial chunk of the SOUP and verification work the manufacturer would otherwise produce themselves.

References

  • IEC 62304:2006/A1:2015, Medical device software — Software life cycle processes.
  • ISO 14971:2019, Medical devices — Application of risk management to medical devices.
  • ISO 13485:2016, Medical devices — Quality management systems.
  • EU 2017/745, Medical Device Regulation (MDR).
  • FDA Guidance on Cybersecurity in Medical Devices (2023).
  • MDCG 2019-16, Guidance on Cybersecurity for medical devices.
  • Fire Arrow documentation: Authorization concepts, Audit log.
  • Related landing pages on this site: SaMD and IEC 62304 backend, MDR medical device backend, Compliance.