Sign in
A connected monitoring device with its firmware, patient app, cloud and clinician view
Services · Complete device software development

The software team for your medical device.

Device makers whose strength is hardware, optics or clinical science, and startups with a first device, need a software organisation that works under IEC 62304 from the first line of code. Silurus Software takes the software from requirements to release inside your ISO 13485 quality management system, with our regulatory specialists and FDA consultants on the documentation for CE marking and the FDA submission.

Book a 30 minute call Write to us
Scope
Requirements to release
Software
Device · desktop · mobile · cloud
Process
IEC 62304 · ISO 13485 · ISO 14971
Route
EU MDR · FDA
What we cover

Every software part of a medical device

01

Requirements and architecture

We write testable requirements and an architecture with software items, interfaces and risk controls placed in the design.

04

Mobile and companion apps

Mobile and companion apps connected to the device over Bluetooth or the cloud.

05

Cloud, web and hospital interfaces

Cloud backends, web dashboards and interfaces to PACS and record systems over DICOM (the standard for medical images and their exchange), HL7 and FHIR.

Interoperability →
06

User interface and usability

Interfaces designed and evaluated with the usability engineering IEC 62366-1 asks for.

07

Test automation and DevOps

CI/CD, automated tests, signed builds and release records from the first sprint, with release only after approval under change control.

Verification and validation →
08

Regulatory file

Our regulatory specialists and FDA consultants prepare the software sections, the Pre-Submission and the answers to the reviewers.

Regulatory consulting →
In practice

Situations we are asked to solve

Situation

A connected sensor, a patient app and a clinician dashboard

A digital health company builds a remote monitoring system: a sensor, a mobile app for patients and a web dashboard for clinicians, as a medical device, for example Class IIa or IIb under the EU MDR (Annex VIII rules 10 and 11) and Class II for the FDA, depending on its intended purpose (what the manufacturer states the software is for).

How we approach it

One development plan covers the firmware, the app, the cloud backend and the dashboard. The software system gets its safety class (A, B or C, by the harm a software failure could cause) from the hazards it can contribute to, and items segregated in the architecture can carry a lower class, with the segregation verified and the rationale recorded. Bluetooth link, data flow and cloud boundary are in one threat model (a structured analysis of how the device could be attacked), and the usability work covers patients and clinicians.

Verification runs from the first sprint, so the technical documentation and the FDA submission are written from records that already exist.

Situation

A product in use, documented after the fact, then developed further

An app, a cloud backend and a dashboard are in use outside the MDR, now have to become a medical device and need their software file before new development can continue under the MDR.

How we approach it

We first confirm the intended purpose, the qualification as a medical device and the class. A gap analysis (a review of what is missing against the standard) then documents the product as it runs today. Records that were never created are not backdated: the gaps are closed with new risk analysis and verification, and new development follows the lifecycle, so every new feature arrives with its requirement, risk assessment and tests.

Situation

A startup with a prototype and a funding round behind it

A MedTech startup has a working prototype, written by a contractor or by one of the founders, and now needs software that can go into a first EU MDR or FDA submission.

How we approach it

A gap analysis of the prototype code decides for each software item whether it is kept, refactored or rewritten. The development plan, the safety classes and the risk analysis come first, and development continues from there to the submission.

Situation

An instrument with firmware and a clinician application

A Class IIb instrument has firmware that controls the hardware and a PC application for the clinician, and both have to be developed and documented as one device.

How we approach it

One architecture covers both. The system gets its safety class from the hazards, and the firmware or the application can carry a lower class only where segregation justifies it. The interface between them is specified as interface requirements, implemented in identified software items and verified in integration testing, and verification of both parts feeds one traceability matrix (a table linking each requirement to its design, tests and risk controls) and one release.

How it runs

One lifecycle, written into your QMS

Plan

Development plan

Lifecycle, safety classification, tools and the documents of the project.

Design

Requirements and architecture

Testable requirements, software items and their interfaces, risk controls placed in the design.

Build

Code and verification

Code, reviews and tests in your repositories, with the risk file and the traceability kept current.

Release

Release and submission

Release evidence and known anomalies, and the software sections for the EU MDR and the FDA.

Maintain

After release

Change control, problem resolution, SOUP (software of unknown provenance, meaning third party code used in the device) and SBOM (software bill of materials, the list of every software component in the build) updates and security patches after release.

What you receive

The software and its file

D-01

Software

The device software, applications and cloud parts, with source code in your repositories.

D-02

Lifecycle documents

Development plan, requirements, architecture and detailed design.

D-03

Risk and security

Software risk analysis, SOUP list, SBOM and the threat model of connected parts.

D-04

Verification and release

Test protocols and reports, traceability matrix and release notes.

EU and US

Software for both markets

European Union

EU MDR and CE marking

The software part of the technical documentation, written with our regulatory specialists.

United States

FDA 510(k) and De Novo

The software documentation of the submission at the Basic or Enhanced documentation level of the FDA software guidance, prepared with our FDA consultants, with a Pre-Submission where the regulatory strategy calls for one.

Technologies and standards

What we work with

Technologies and tools

CEmbedded CC++C#.NETPythonKotlinSwiftTypeScriptReactQtZephyrFreeRTOSBluetooth LEPostgreSQLAzureDockerGitHub ActionsGoogleTestCI/CD

Standards, regulations and practices

IHEIEC 62304ISO 13485ISO 14971IEC 62366-1IEC 81001-5-1EU MDRFDA 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 →
Related

Related work and pages.

Client names are withheld unless the client has agreed to be named.

Case study

IEC 62304 feature development in a large .NET codebase

Senior developers inside a European manufacturer's lifecycle, QMS and review workflow, over several years.

Case study

Cloud platform for radiotherapy contouring algorithms

A European manufacturer's cloud platform on which research hospitals run their own contouring algorithms, connected to PACS over DICOM.

Project deliveryRegulatory consulting, EU MDR and FDAEmbedded and firmware developmentMedical device cybersecurityDedicated engineering teamsLegacy modernisation and takeoverAI coding tools in regulated developmentMedTech startups
FAQ

Frequently asked questions

01

We have no software team. Can you develop the whole device software?

Yes. We take the software from the development plan and the requirements to the release documents, with our regulatory specialists on the file. Design validation of the whole device and the approval of the documents stay with you as the manufacturer, with our support.

02

Do you work inside our ISO 13485 QMS?

Yes. If the QMS has no software procedures yet, we bring templates for the IEC 62304 documents and fit them to it.

03

Can the same team write the firmware, the app and the cloud backend?

Yes. All parts run under one development plan, with a SOUP list per part and a recorded safety class for the software system and, where verified segregation in the architecture justifies it, for each item.

04

We already have code from a contractor. Can you continue it?

Yes. The first step is a gap analysis of the code, the documents and the process, then development continues on that plan.

05

Which cloud platforms do you work with?

We work on Azure, AWS and Google Cloud, whichever the product runs on. The lifecycle is the same on each: the SDKs and libraries go into the SOUP list and the SBOM, the managed cloud services are recorded with their configuration and risk assessment, and the threat model covers the cloud part.

06

How large is the team, and how fast does it start?

It is sized to the work and grows or shrinks with the phase of the product. The first engineers start within two to three weeks of signature.

07

Which device classes do you work on?

Software of Class I, IIa, IIb and III devices under the EU MDR, and devices on the 510(k) and De Novo routes of the FDA, with IEC 62304 safety classes A, B and C.

08

Which FDA quality rules apply to the software process?

The FDA Quality Management System Regulation (QMSR, 21 CFR 820), in force since 2 February 2026, incorporates ISO 13485 by reference, so one software process inside an ISO 13485 system is the base for both markets, with the FDA specific requirements added. For a cyber device under section 524B, the submission needs the SBOM, the plan for handling vulnerabilities after release and evidence of secure development and maintenance processes, and the FDA cybersecurity guidance expects the threat model and the security tests as part of that evidence.

Talk to us

Tell us about the device.

The device, its class and where the software stands today. We reply with the first step.

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