Digital health companies whose app has become a medical device.

An iOS or Android app, its cloud backend and its web dashboard fall under the EU MDR, and in the US under the FDA rules for device software functions, once they have a medical purpose. The notified body (the independent organisation that certifies a device under the EU MDR) or the FDA reads the software documentation, and an IEC 62304 file is the accepted way to provide it. The app ships every week, and the file has to keep pace. We write the IEC 62304 file for software that is already in use and develop the next releases under it, inside your quality system. Our regulatory specialists and FDA consultants write and review the file, the risk analysis and the cybersecurity documentation and support you through the submission.

Book a 30 minute call Write to us

Systems: iOS · Android · cloud · web dashboard
Standards: EU MDR · FDA · IEC 62304 · ISO 14971 · ISO 13485
First step: Free 30 minute call with engineering

The software path

How a health app release is made under the MDR.

Requirement

The app store description and the marketing claims define what the app is for, and no written specification exists.

ImprovementRequirements are written into a specification and traced to the code and the tests.

Design

The architecture of app, backend and dashboard lives in the developers' heads.

ImprovementThe architecture and the SOUP list are written down and updated with each release.

Implementation

Open source libraries and SDKs enter the build without a record.

ImprovementEach new library or SDK is recorded in the SOUP list when it enters the build.

Verification

The risk analysis and the test protocols are written after the code, if at all.

ImprovementRisks such as a wrong value shown, data lost in sync or a record assigned to the wrong patient are tested before release.

Release

The shipped version cannot be traced to the version the notified body or the FDA reviewed.

ImprovementThe CI pipeline writes the release record, so each shipped version is traced to its review.

Field support

Crashes, complaints and the model changes of an AI feature arrive in different places.

ImprovementAnomalies and complaints go into one list, and each model change goes through change control.

Change

Change control, risk assessment and test evidence slow down the weekly release.

ImprovementChange control runs inside the pipeline, so the app keeps its weekly releases.

The goal

A health app that keeps its release speed under the MDR.

For the company

Software documentation that matches the released code, for the notified body and the FDA
A regulatory route the whole company can plan around
Weekly releases that pass design controls

For clinicians

Patient data they can trust, exactly as the app recorded it
Alerts that behave as specified, also when the connection fails
Updates that keep the behaviour they rely on

For patients

Improvements to the app that reach them every week, verified before release
Defects fixed quickly
Readings that reach their doctor without loss or mix up

Problems and solutions

What we hear, and what we do about it.

The app is live, and its IEC 62304 documentation does not exist yet.

We first establish whether the live app is already on the market as a medical device, since that decides the route. Then a gap analysis (a review of what is missing against the standard) of the code, the documents and the process covers the mobile code, the cloud services and the dashboard under one safety classification. Then we reconstruct the requirements, the architecture, the SOUP list (software of unknown provenance, meaning third party code used in the device), the risk analysis and the test protocols from the code, in your templates and with your developers in short sessions.

Retrospective IEC 62304 documentation

The agency that built the app has moved on.

We read the code the agency or the freelance team left, document it and take over the next releases while the product stays on the market. Design controls apply from the first change.

Legacy modernisation and takeover

We release every week, and the quality system will slow us down.

Change control runs inside the CI pipeline, so the app keeps its store release cadence, and each change is assessed for whether it needs notified body approval or a new FDA submission before release. Each change carries its requirement, risk assessment and test evidence. Each release gets a version record and a list of known anomalies.

Medical software development

We need regulatory experts who write the file and the submission with us.

Our regulatory specialists and FDA consultants write the technical file, the risk management file and the cybersecurity documentation with your team, and review them against the MDR and the FDA guidance before submission. They advise on the classification and the submission strategy, write the FDA Pre-Submission and answer the questions of the notified body or the FDA with you. The threat model (a structured analysis of how the device could be attacked), the SBOM (software bill of materials, the list of every software component in the build) and the vulnerability process are written with the architecture, under IEC 81001-5-1 and section 524B.

QA, compliance and regulatory

We added an AI feature and do not know what it changes.

The model becomes a versioned configuration item with its training data, verification results and change control. A new AI feature in a certified device is assessed for significant change, which can call for notified body approval and an updated clinical evaluation, and in the US for a new submission or a PCCP. The MDR file gets the model description and the performance evidence.

From AI model to medical device

Fit

When we are the right partner.

Call us when

You want the IEC 62304 file for a live app that the notified body or the FDA asks about
You want to take over an app and backend that an agency or a freelance team built and left
You want an AI feature in a product that is already a medical device, with the file updated
You want regulatory specialists who write the file and the FDA Pre-Submission with you

Talk to us

Tell us what you are working on.

A live app without a file, a submission or a new AI feature. Write a few lines about the product, its platforms and the documents that exist today, or book a free 30 minute call with engineering.

Book a 30 minute technical call

FAQ

Frequently asked questions.

Is our health app a medical device under the MDR or for the FDA?

The intended purpose your company states decides it. In the EU, software intended to provide information for diagnosis or therapy qualifies as a medical device, as MDCG 2019-11 explains, and is classified under Annex VIII Rule 11, Class IIa or higher. In the US, the FDA guidance on device software functions, clinical decision support and general wellness draws the line, and the route is a 510(k) (the FDA premarket notification for a device similar to one already on the market), a De Novo or a PMA. We document the software to the class and the route that apply.

Can you write the IEC 62304 documentation for an app that is already live?

Yes. We start with a gap analysis of the code, the documents and the process. Then we reconstruct the SRS, the architecture, the SOUP list, the software risk analysis and the test protocols from the code, in your templates and inside your QMS (quality management system).

Do you also build the app and the backend, or only the documents?

Both. Our engineers write mobile apps, cloud backends and web dashboards and keep the IEC 62304 file next to the code. For a companion app of a wearable, the app, the Bluetooth link and the backend are verified as one system with the device.

Can you prepare an FDA Pre-Submission for our app?

Yes. Our FDA consultants prepare the Pre-Submission (Q-Submission) with the device description, the intended use, the proposed route and the questions for the FDA, and prepare your team for the meeting. The software, risk and cybersecurity documentation behind it is written by the same team.

Can we keep releasing every week under IEC 62304?

Yes, when change control is part of the pipeline. Each change carries its requirement, its risk assessment and its test evidence, and each release gets a version record and a list of known anomalies.

How long does a gap analysis take, and what does it cost?

The standard review takes three weeks and ends in a written report and a remediation plan. For an app with a backend and a dashboard we set the duration and quote the price after a first look at the code and the documents.

Related services and sectors.

Retrospective IEC 62304 documentation IEC 62304 gap analysis AI model to medical device Medical device cybersecurity Embedded and firmware development Digital applications and wearable devices