IEC 62304

SaMD and IEC 62304 FHIR Backend

IEC 62304 governs the lifecycle of software in a medical device. The third-party components inside that lifecycle are SOUP, and qualifying SOUP is one of the more time-consuming parts of an MDR submission. Fire Arrow is developed under an ISO 27001-aligned QMS (certification in progress) and shipped as versioned container images with change history and a security advisory channel, so the manufacturer can qualify it as SOUP without having to reconstruct the release record themselves.

Read the deployment docs Book an IEC 62304 supplier review

What you can build

Backend-layer SOUP inputs the manufacturer can qualify
Versioned container images with pinned dependencies, release notes per version, change history, known anomalies and limitations published with each release, and a security advisory channel. The manufacturer pulls these into their own SOUP qualification activity.
Software safety class A, B, or C supported
Fire Arrow does not implement clinical decision logic, so the safety class of the backend follows the device design and the architecture of the integration.
Quality-system flexibility for self-hosted deployments
The customer's QMS covers the backend's operating environment in self-hosted deployments. Where Evoleen hosts the deployment, the operating environment runs under Evoleen's ISO 27001-aligned QMS (certification in progress).

What you get out of the box

Capability With Fire Arrow Building it yourself

SOUP identification and qualification inputs Versioned releases with documented intended use, requirements summary, anomaly history, and known limitations published per release. The manufacturer references these in their own SOUP qualification. Internal qualification of every third-party library used to build a custom FHIR backend, repeated on every release.

Configuration management Rules, identity mappings, and deployment expressed as versioned FHIR resources and container images, in source control on the customer's side. Configuration distributed across application code, environment variables, and ad hoc database state.

Change control Release notes per minor and patch version, with security advisories shipped through a dedicated channel. Changelog discipline applied across the whole stack, audited per change for medical-device impact.

Reproducible builds Container images pinned to known-good digests. Same image runs in dev, staging, and production. Reproducible build pipeline assembled from scratch, including dependency pinning and verifiable supply chain.

Quality management system context Fire Arrow is developed under an ISO 27001-aligned QMS (certification in progress). The release artifacts above are the product-side output of that QMS. Internal QMS documentation is not a customer deliverable. Customer-side QMS covering every line of code in the custom backend.

Risk file inputs Anomaly list, known limitations, and operational characteristics published per release. The manufacturer cites these when assembling the risk file for the device. Risk file evidence reconstructed from internal incident history and code review notes.

Who this is for

Medical-device software teams whose product is qualified under IEC 62304 and who need a FHIR backend that fits cleanly into a regulated software lifecycle.

Clinical applicability

A diagnostic software classified as MDR Class IIa uses Fire Arrow as the persistence and access layer for clinical inputs and outputs. The backend sits inside the device's software architecture, with documented requirements, change control, and traceability assembled by the manufacturer using Fire Arrow's release artifacts as inputs.

Where Fire Arrow fits in the IEC 62304 lifecycle

IEC 62304 expects every software unit in the medical device to have a documented role, requirements, and verification. Third-party components are SOUP, and the standard requires the manufacturer to identify them, document the requirements they meet, list known anomalies, and incorporate them into risk management.

Fire Arrow is positioned as a SOUP component the manufacturer qualifies inside their own IEC 62304 lifecycle. The release artifacts that support that qualification (intended use of the backend, requirements summary, known anomalies and security advisories from prior releases, and change-control history) are published per release. The qualification itself is the manufacturer's activity; Fire Arrow does not ship a pre-built SOUP dossier.

Software safety classification

IEC 62304 classifies software into safety classes A, B, and C based on the harm a software failure could cause. The classification belongs to the device, not to the backend, but the backend has to be qualified at the same class as the device or higher.

Fire Arrow does not implement clinical decision logic. It enforces access control, persists FHIR resources, and runs CarePlan scheduling. The qualification effort follows from the device's classification: Class A device deployments use the published release artifacts as the basis for SOUP qualification; Class B and Class C deployments add the verification activities the manufacturer's QMS requires for that class. Evoleen can support those verification activities as a separate engagement.

Two operating shapes

Self-hosted is the primary deployment shape. The customer operates the backend in their own environment under their own QMS, using the published release artifacts as the SOUP record. Evoleen ships new releases on a published cadence; the customer's change-management procedure decides when to apply them.

Evoleen-hosted is a separate engagement where Evoleen operates the deployment for the customer. The operating environment runs under Evoleen's ISO 27001-aligned QMS (certification in progress) and on ISO 27001-certified cloud infrastructure. Once Evoleen's certification is in place, customers can reference it as a supplier control in their own audits and, where their own auditor requires it, conduct a supplier-procedure audit of Evoleen as a separate engagement. Internal QMS documents are not opened up as a customer deliverable in either case.

Related docs

FAQ

Is Fire Arrow IEC 62304 certified?

IEC 62304 certifies the manufacturer's software development lifecycle, not a third-party component. Fire Arrow is developed under an ISO 27001-aligned QMS (certification in progress) and shipped with the release artifacts a manufacturer needs to qualify it as SOUP within their own IEC 62304 lifecycle.

What software safety class can Fire Arrow support?

Up to Class C, depending on the device design and the verification the manufacturer adds. The backend itself does not contain clinical decision logic, so the qualification effort scales with the device's safety class rather than with the backend's complexity.

What release artifacts are published?

Versioned container images with pinned dependencies, release notes per version, intended use of the backend, a requirements summary, known anomalies and limitations, change history, and security advisories. These are the product-side inputs the manufacturer pulls into their own SOUP qualification and risk file. They are not a pre-assembled SOUP dossier; the dossier is the manufacturer's activity.

Can I rely on Evoleen's QMS for the backend layer?

Evoleen's QMS is ISO 27001-aligned and certification is in progress. After certification, the certificate (and a customer's supplier-procedure audit, where their auditor requires one) can be referenced as a supplier control in the customer's own ISMS or QMS. Internal QMS documents are not opened up as a customer deliverable. If your submission timeline requires a packaged QMS dossier today, that is best addressed in a separate engagement where Evoleen helps you produce the documentation against your own QMS.

What about post-market surveillance?

Security advisories and anomaly notifications are shipped through a dedicated channel for production customers. Operational metrics from the deployment stay with the operator; Fire Arrow does not phone home.