Developer at three monitors with code and an MR brain image
Services · AI model to medical device

From a working AI model to a CE marked or FDA authorised device.

A model that works on research data is the core of a product, and a small part of what a notified body (the independent organisation that certifies a device under the EU MDR) or the FDA reviews. Around the model we build the inference service, the hospital integration, version and change control and the monitoring after release, under IEC 62304. The regulatory specialists and FDA consultants of Silurus Software write the software and AI parts of the technical documentation for the EU MDR, the FDA and the EU AI Act (the EU regulation on artificial intelligence). The manufacturer stays responsible for the intended purpose (what the manufacturer states the software is for), the classification, the clinical evaluation and the conformity assessment. The model stays yours.

The model
Stays yours
We build
Inference service · PACS · DICOM
Process
IEC 62304 · ISO 13485 · ISO 14971
Route
EU MDR · FDA · EU AI Act
What we cover

Everything between the model and the clinic

01

Inference service

The model packaged as a production service with fixed preprocessing, error handling and performance limits.

02

Hospital integration

DICOM input from PACS, results as DICOM SR, DICOM SEG or secondary capture objects, or HL7 (a standard for exchanging clinical messages) messages, tested with the receiving PACS.

Interoperability →
03

Data and training

Versioned data sets with their origin and annotation records, test data kept apart from training data, and training runs recorded with code, environment and seeds, so a released version can be rebuilt within stated tolerances.

04

Performance verification

Testing on data the model never saw, by scanner, site and patient group, against criteria fixed in advance.

05

Change control and retraining

A retraining pipeline under change control, and the change control plan our FDA consultants write for the submission.

Regulatory consulting →
06

Monitoring after release

Every call logged with the model version, drift and subgroup performance watched against the release baseline.

07

Result display and oversight

Result display, editing and rejection designed with the usability work IEC 62366-1 asks for.

08

Regulatory file

Our regulatory specialists and FDA consultants write the software and model documentation for all three.

Regulatory consulting →
In practice

Situations we are asked to solve

Situation

A research model that has to become a product

A startup has a model that finds abnormalities in medical images, trained on research data. It now needs a production inference service, hospital integration and the documentation for the EU MDR or the FDA, depending on the market.

How we approach it

We package the frozen model as a service, connect it to PACS over DICOM and return results the reading workstation shows. The model registry, versioned data and verification on held out data by scanner and patient group are set up, and the software file is written under IEC 62304.

Clinical performance studies stay with your clinical partners, and we deliver the standalone performance evidence and the records they build on.

Situation

Retraining a cleared model without a new submission each time

An AI diagnostic product is FDA cleared and CE marked, and the model should be retrained regularly.

How we approach it

A predetermined change control plan describes the planned modifications, the protocol for retraining, verification and release, and the impact assessment. Our FDA consultants write it following the FDA guidance on predetermined change control plans, and our engineers build the pipeline that executes it. In the EU, planned changes to the certified device are reported to the notified body, which decides whether they need its approval before release, and the EU MDR applies its own test to each change. Under the EU AI Act, changes that the provider predetermined and documented at the initial conformity assessment are not a substantial modification. In the US, for a device already cleared, the plan goes in with a new marketing submission. After authorisation, modifications that fall within the authorised plan and are made as its modification protocol describes need no new submission.

Situation

Monitoring a radiology AI in clinical use

A radiology AI has been in use in several hospitals for two years, and post market performance has to be monitored properly.

How we approach it

Every inference is logged with the model version and acquisition metadata, without patient identifiers, under the retention and access rules agreed with the hospital. Performance is measured on cases with an independent reference result, such as adjudicated reads, pathology or follow up. The final report counts as reference only where the reader did not see the model output, and input and output drift is watched in between. Drift, subgroup performance and override rates are compared with the release baseline, alerts go to named owners, and the results feed the post market surveillance of the EU MDR, the post market monitoring of the EU AI Act, and the complaint handling and medical device reporting the FDA requires.

EU AI Act

The EU AI Act on top of the EU MDR

AI software that is a medical device and needs a notified body under the EU MDR is a high risk AI system under the EU AI Act. The AI Act adds requirements on risk management, data and data governance, technical documentation, record keeping, transparency towards users, human oversight, accuracy and cybersecurity, robustness, a quality management system and post market monitoring. They are written into the same technical documentation and the same quality system as the MDR file, and the conformity assessment stays with the notified body. The requirements for AI systems under product law such as the EU MDR apply from a later date than those for other high risk systems, and the gap assessment checks the dates that apply to your product.

For a product already CE marked, the work starts with a gap assessment of the existing file against these requirements. Our regulatory specialists then add the missing parts, and our engineers build what the requirements need in the software, such as logging, oversight functions and data lineage.

What you receive

Software and evidence around the model

D-01

Inference service

The model packaged as a production service with fixed preprocessing and error handling.

D-02

Model registry

Every released version with its data, code and verification results, and rollback.

D-03

Performance verification

Testing on data the model never saw, by scanner, site and patient group.

D-04

Regulatory file

Software documentation, model description and change control plan, written with our regulatory specialists and FDA consultants.

EU and US

One product, two markets

European Union

EU MDR and EU AI Act

The software and model documentation for CE marking, and the additions the EU AI Act asks for.

United States

FDA

The software documentation and the model description for the submission, and a predetermined change control plan for retraining.

Technologies and standards

What we work with

Technologies and tools

PythonPyTorchTensorFlowONNX RuntimeMONAICUDATensorRTDockerKubernetesPostgreSQLGitHub ActionsGitLab CIAzureAWSGoogle CloudDICOMDICOMweb

Standards, regulations and practices

FDA PCCP guidancePredetermined Change Control Plan (PCCP)Good Machine Learning PracticeIEC 62304ISO 13485ISO 14971IEC 62366-1IEC 81001-5-1EU MDREU AI ActFDA 510(k)FDA De Novo

Silurus Software

  • Silurus Software, founded in 2017, offices in Budapest, Hungary, and Singapore
  • More than 40 engineers, EU MDR regulatory specialists and FDA consultants
  • Work inside the client's ISO 13485 quality management system, with the split of tasks written down before the work starts. Where the client has no documented software process yet, we bring IEC 62304 templates for the client to adopt into its own system
  • Multi-year engineering partner of a European MedTech manufacturer
  • Founder and CTO Péter Török, in medical technology software since 1999, formerly software development director at Siemens Healthcare (syngo.via) and head of R&D at Mediso Medical Imaging Systems
  • ISO 9001:2015 (NQA, certificate 171041, valid until March 2027) and ISO/IEC 27001:2022 (NQA, certificate 728872, valid until August 2029)
  • Awarded AAA, Highest Creditworthiness, by Dun & Bradstreet in 2025
  • Research partner of ELTE Eötvös Loránd University, Budapest
  • Industrial partner of the University of Bologna, the University of Pisa, the University of Amsterdam and Masaryk University, Brno, in the EU Horizon Europe project LOGOS from 2027
  • Female Business Leader of the Year 2025 and The Pioneer Award 2026, awarded to CEO Dr. Linda Szántó
How we work →Quality and standards →Sample deliverables →Case studies →
FAQ

Frequently asked questions

01

We have a research imaging model in Python. Can you turn it into a regulated product?

Yes. We package it as an inference service, connect it to PACS, put version and change control in place and write the software file. Your team keeps the model.

02

Who owns the model and the data?

You do. Weights and data are used only for the contracted work, in environments you approve.

03

Can you set up a change control plan for retraining?

Yes. Our FDA consultants write the plan, and our engineers build the retraining pipeline that follows it.

04

How do you monitor a deployed model?

Each call is logged with the model version and the input metadata, and performance is compared with the release baseline per scanner, site and patient group.

05

Which frameworks do you work with?

Python, PyTorch and MONAI for training, ONNX Runtime or PyTorch for inference, in containers on premise or in the cloud.

06

What does a predetermined change control plan contain?

A description of the planned modifications, the modification protocol with data, retraining, verification and release steps, and an impact assessment.

07

Do you support clinical validation?

We deliver the standalone performance testing, the subgroup results and the software verification. The clinical performance study is run with your clinical partners.

Talk to us

Tell us about the model.

The model, the intended use and the market. We reply with the work between your model and the submission.

Book a 30 minute technical call
We reply within one working day.