MDR

MDR-Compliant Medical Device Backend

MDR moved most clinical software up the classification ladder. Class IIa and IIb backends now carry technical-documentation obligations that used to apply only to Class III devices. Fire Arrow is developed under an ISO 27001-aligned QMS (certification in progress) and ships release artifacts and product documentation that the manufacturer pulls into their own technical file, so the manufacturer's effort focuses on the device-specific evidence rather than on reconstructing the backend's release record.

Read the deployment docs Book an MDR supplier review

What you can build

Backend-layer inputs for the technical file
Architectural description, data flows, identity model, and access-control rules are documented in the product reference. The manufacturer cites and incorporates these when assembling the technical file under Annex II.
Supplier-qualification context
Fire Arrow is developed under Evoleen's ISO 27001-aligned QMS (certification in progress), and shipped as versioned containers with change history and a security advisory channel. The customer's supplier-evaluation procedure references these artifacts.
Stable interface contracts
FHIR R4 and a stable rule schema mean the backend's interface to the rest of the device does not require re-validation on every backend release.

What you get out of the box

Capability With Fire Arrow Building it yourself

Class IIa and IIb support Architectural and operational documentation that aligns with the manufacturer's technical-documentation obligations under Annex II. The manufacturer pulls it into their technical file rather than authoring it from scratch. Custom backend whose every component must be qualified under the manufacturer's QMS.

Supplier-evaluation inputs Versioned releases with change history, a security advisory channel, and product documentation. Fire Arrow is developed under Evoleen's ISO 27001-aligned QMS (certification in progress); the customer's supplier-evaluation procedure references these artifacts. Self-build or use of a vendor without published change-control or advisory channels; supplier-evaluation cycles repeated per major change.

Risk management inputs Anomaly list, security advisory history, and architectural descriptions available for the manufacturer's risk file. The manufacturer authors the risk file; Fire Arrow's artifacts are the inputs. Risk evidence reconstructed from in-house incident records.

Post-market surveillance Security advisories, vulnerability disclosures, and version-specific notices delivered through Evoleen's customer channel. Manual monitoring of every dependency in a custom stack.

Clinical evaluation support The backend does not implement clinical decision logic, so it does not constrain the clinical evaluation. The product documentation describes scope clearly. Backend that conflates persistence with clinical logic and complicates the evaluation boundary.

Notified Body review evidence Architectural diagrams, identity-model description, audit-log shape, and rule schema available for citation in the technical file. Equivalent documentation produced from scratch for every submission.

Who this is for

Medical-device software manufacturers preparing or maintaining MDR submissions for Class IIa or Class IIb software, and Notified Body reviewers evaluating the backend layer of those submissions.

Clinical applicability

A connected diagnostic platform classified as MDR Class IIb uses Fire Arrow as the FHIR persistence and access layer between mobile clients, clinician dashboards, and an inference service. The backend is in scope of the technical file.

MDR for software backends in plain terms

MDR pulled most diagnostic and treatment-supporting software into Class IIa or higher. The technical-documentation obligations under Annex II now apply to almost any commercial digital health backend that touches a clinical decision. The backend has to describe what it does, how it does it, what it does not do, and how it changes over time.

The realistic question is which inputs come from the backend supplier and which evidence the manufacturer has to produce themselves. The cleaner that split, the faster the submission. Fire Arrow is structured so that the backend-side inputs (architecture documentation, configuration, change-control history, security advisories) are published with each release, and the manufacturer's QMS authors the device-specific evidence on top.

Where Fire Arrow contributes to the technical file

Section 1 of Annex II asks for a description of the device. The backend's description sits inside the manufacturer's overall device description; Fire Arrow's product documentation provides architectural description, identity model, and operational characteristics that the manufacturer cites in that section.

Section 4 asks for design and manufacturing information. The backend's manufacturing artifact is the container image, with pinned dependencies and a documented build process. Section 6 asks for clinical evaluation support; the backend does not contribute clinical claims but documents what data it handles and what it does not interpret.

Section 8 covers post-market surveillance. Security advisories, anomaly notifications, and operational guidance for upgrades are shipped through the customer channel and feed the manufacturer's surveillance plan.

Class IIa, IIb, and III differences

Class IIa devices typically have lighter Notified Body involvement than Class IIb. The backend evidence requirements scale with the manufacturer's QMS, not with the backend itself. Fire Arrow's published release artifacts and product documentation are the same regardless of class; what changes is the verification activity the manufacturer's QMS layers on top.

Class III deployments are rare for backend persistence layers but possible in configurations where the backend is part of an implant management system or similar. These deployments typically add joint risk reviews and a deeper supplier-evaluation engagement; both are available as a separate engagement.

Related docs

FAQ

Does Fire Arrow have a CE mark?

Fire Arrow is not a medical device on its own; it is a backend component used inside medical-device software. The CE mark applies to the manufacturer's device. Fire Arrow contributes backend-layer inputs (release artifacts, product documentation, supplier-evaluation context) that the manufacturer assembles into their own technical file.

Can Fire Arrow handle Class III devices?

Yes for backend persistence and access roles. Class III deployments typically add joint risk reviews and a deeper supplier-evaluation engagement; both are available as a separate engagement. The architecture and configuration model is the same as for Class IIa and IIb.

How are security advisories handled?

Security advisories are shipped through a dedicated channel for production customers. Each advisory typically includes the affected versions, an impact summary, and a recommended remediation path. Where the advisory affects a medical-device deployment specifically, Evoleen can work with the manufacturer on translating that summary into terms relevant to the device's risk file as a separate engagement.

Does Evoleen support our Notified Body review?

Yes, as a separate engagement. Evoleen can join Notified Body discussions covering the backend, supply additional documentation on request, and sign supplier statements the manufacturer includes in their technical file. Evoleen does not ship a packaged Notified Body dossier as part of the product license.

What about software updates after CE marking?

Each release ships with documented changes and an impact assessment. The manufacturer's change-control procedure decides which updates trigger a re-evaluation under MDR Article 120 or the post-market surveillance plan.