Young medical researchers in white coats in a university hospital corridor

Research groups whose software can become a medical device.

University medical centres and research institutes build devices and models that work in the lab and in clinical studies. Taking them further needs requirements, tests and a technical file that research code does not have. We develop and document research software under IEC 62304, so the code can enter a technical file once a manufacturer and its quality system are in place, and in Horizon Europe and EIC consortia we can take the software work packages.

Book a 30 minute call Write to us

Research partners: ELTE · University of Bologna · University of Pisa · University of Amsterdam · Masaryk University
Framework: IEC 62304 · ISO 13485 · ISO 14971 · EU MDR
First step: Free 30 minute call with engineering

The software path

A research device from the lab to the market.

Research prototype

Doctoral students and postdocs write the software for the experiment. When the grant ends they move on, and nobody on the team can take it further.

ImprovementWe make the code testable and document it, so a new team can maintain it.

Funding call

The call needs a named industrial partner for the software, verification and exploitation work packages.

ImprovementWe join the consortium as the industrial software partner and write the software parts of the proposal.

Clinical use

The device is used in a clinical study. Validation needs requirements, tests and traceability that research code does not have.

ImprovementRequirements, tests and a traceability matrix are written on the code, so validation can start.

Model to service

After the paper, hosting, data protection and the DICOM (the standard for medical images and their exchange) connection of the model are still open.

ImprovementThe model runs as a versioned service, connected to PACS over DICOM for research use until its regulatory route is decided.

Who is the manufacturer

The hospital, a spin off or an industrial partner takes the device forward, and investors ask what the regulatory route will cost.

ImprovementA gap analysis lists what the first release needs, in work packages a business plan can budget.

Software lifecycle

The research code cannot be tested as it is, so the IEC 62304 file has nothing to build on.

ImprovementWe write the IEC 62304 file on the restructured code, under the manufacturer's quality system.

In use or on the market

An in house device under MDR Article 5(5) cannot be transferred to another legal entity, and a CE marked product needs a complete technical file.

ImprovementThe documentation written for the in house version becomes the base of the CE technical file.

The goal

A research device with a clear route.

For the institute

A clear route to a regulated product before the grant ends
Software a new team can maintain
The cost of the first product release, in work packages

For researchers and clinicians

Requirements and tests behind the software used in a clinical study
Tests that run without the hardware
Models that run as versioned services next to PACS

For patients

New treatments from research that reach them sooner
Clinical studies that run on validated software
Their data processed under the GDPR and pseudonymised before it leaves the hospital

Research partners

Universities we work with.

Problems and solutions

What we hear, and what we do about it.

The prototype works in our lab, and nobody on the team can take it further.

We review the code and restructure it so it can be tested. We add a simulation mode, so the tests run without the hardware. Then we write the documentation on the restructured code, and your own team can maintain it.

IEC 62304 gap analysis

The call needs an industrial partner who can build and document medical device software.

In the consortium we take the work packages for the software architecture, development, verification and IEC 62304 documentation. We also describe the route to a regulated product for the exploitation plan and write the technical content of the software parts of the proposal.

Medical software development

Our device is used in a clinical study, and its software was written for research.

We first make the code testable. Then we write the requirements, the verification plan, the test reports and the traceability matrix (a table linking each requirement to its design, tests and risk controls) under your quality system. For the firmware of an in house laboratory or measurement device, a simulation mode lets the tests run without the hardware.

Embedded and firmware development

We have a model trained on our own data and no path to a regulated product.

We host the model as a versioned service and connect it to PACS over DICOM. We write the IEC 62304 and ISO 14971 file and state the position of the model under the EU AI Act (the EU regulation on artificial intelligence) and the MDR.

AI model to medical device

We do not know who will be the manufacturer.

The hospital, a spin off or an industrial partner can take the device forward, and that is the first decision. We set up the software lifecycle under the quality system of whoever becomes the manufacturer.

Medical software development

A spin off is planned, and investors ask what the regulatory route will cost.

The device class, the software safety class (A, B or C, by the harm a software failure could cause) and the size of the documentation gap set the budget. A gap analysis (a review of what is missing against the standard) lists what the first release needs, in work packages a business plan can use.

IEC 62304 gap analysis

We are afraid the work ends up locked into one supplier.

We develop the software in the project's repositories, together with its verification records. A spin off or an industrial partner can continue with its own team or with ours.

How we work

Fit

When we are the right partner.

Call us when

You want a research device or model to become a product
You need an industrial software partner for the software work packages of a call
You want the device software of a clinical study validated
You want to know what the first release of a spin off requires

Talk to us

Tell us what you are working on.

A research device, a model or a call for proposals. Write a few lines, or book a free 30 minute call with our engineering team.

Book a 30 minute technical call

FAQ

Frequently asked questions.

Can Silurus join our Horizon Europe or EIC consortium as the industrial software partner?

Yes. In a consortium we take the work packages for the software architecture, development, verification and IEC 62304 documentation, plus the regulatory route in the exploitation plan. Send us the funding call, and in the first meeting we tell you which work packages we could take.

Can you help write the proposal?

Yes. We write the technical content of the software parts, from the architecture and the work plan to the route to a regulated product.

Our device software was written by doctoral students. Can it be validated as it is?

First it has to become testable. We review the code and its tests, restructure it where the structure does not allow testing, add a simulation mode for testing without the hardware and write the IEC 62304 package on top. Your own team can then maintain and extend it.

We have a model trained on our own imaging data. What does a product need around it?

Hosting as a versioned service, a secure connection to PACS over DICOM, model version control, and the IEC 62304 and ISO 14971 file with the AI Act position stated.

How is a research project staffed, and what does it cost?

A dedicated team works in English from Budapest on Central European time, sized to the work package. The 30 minute call is free, and each step after it is quoted individually, with scope, deliverable, duration and price agreed in writing.

Related services and sectors.

IEC 62304 gap analysis AI model to medical device Embedded and firmware development Complete device software development MedTech startups