CT scanner, patient monitor, laboratory analyser and workstation linked through one gateway

Medical devices and clinical systems that exchange data reliably.

Devices, PACS (the image archive), record systems and laboratory systems from different vendors have to share images, results and patient data without retyping. Silurus Software specifies, builds and tests the DICOM (the standard for medical images and their exchange), HL7 (a standard for exchanging clinical messages) and FHIR (a web standard for exchanging health records) interfaces and device gateways between them, for device makers, integrators and hospitals in Europe and the US, under IEC 62304 where the software is a medical device or part of one.

Book a 30 minute call Write to us

Standards: DICOM · HL7 · FHIR · IHE
Markets: Europe · US
Connects to: PACS · LIS · EHR · devices
Process: IEC 62304 · ISO 13485 · ISO 14971

What we cover

Interfaces between devices and clinical systems

Imaging

DICOM networking, worklists, DICOMweb and result objects, with the conformance statement kept current.

Medical and dental imaging software →

Hospital messaging

HL7 v2 interfaces for admissions, orders, results and scheduling (ADT, ORM, ORU, SIU over MLLP with acknowledgements), mapped and tested per system.

FHIR and web APIs

FHIR R4 resources and APIs, and applications launched from the record with SMART on FHIR.

Device data

Device gateways that map parameters, units and patient identity into the charting or record system. Whether the gateway is itself a medical device is settled first, since passing on alarms or data for active monitoring can make it one.

National records

Connections to national health record systems, built to each country's specification and kept working when a system changes.

Identity and sign-in

Single sign-on and patient context across the record and the connected tools.

Vendor to vendor integration

The gateway, the interface specification and a test report the tender can use.

Project delivery →

Testing and operation

Failure cases tested before go live, every message logged, monitoring and a runbook for the day a link goes down.

In practice

Situations we are asked to solve

Situation

A device platform that has to talk to hospital systems

A device platform has to exchange data with the electronic health record over FHIR and with PACS over DICOM, in Europe and the US.

How we approach it

We specify and build the FHIR resources and the DICOM services (C-STORE, C-FIND, C-MOVE, modality worklist (the list of scheduled examinations sent to the imaging device) and DICOMweb), test them against the hospitals' systems or vendor simulators and write the DICOM conformance statement and the FHIR capability statement. Where the platform is a medical device, the interface code falls under IEC 62304, with its own requirements, tests and SOUP (software of unknown provenance, meaning third party code used in the device) records.

Situation

A purchased AI tool inside the hospital systems

A hospital bought an AI diagnostic tool, and its results have to appear in PACS and in the record.

How we approach it

Studies are routed from the modality or PACS to the tool, results return as DICOM SR or SEG and as HL7 or FHIR results to the record, with single sign-on and launch from the record.

Situation

Devices from one vendor, charting from another

A tender asks that patient monitors and ventilators deliver their data to another vendor's charting system.

How we approach it

We read both interface specifications, agree the parameter, unit and patient identity mapping, build the gateway and deliver the test report the tender needs.

How it runs

From the inventory to go live

Step 1

Inventory

Every system, its version and the interfaces it offers, with the gaps that decide the effort.

Step 2

Specification

Messages, mapping, units, patient identity and error handling, agreed in writing.

Step 3

Build and test

Normal and failure cases against the real systems or vendor simulators.

Step 4

Go live

A runbook for the day a link goes down, and support after go live.

What you receive

Interface results

D-01

Interface specification

Message types, fields, code mapping such as LOINC or SNOMED CT, units in UCUM, timing and error handling.

D-02

Gateway or interface software

Built and deployed. Every message is traceable by ID, time and status, and patient data in logs is kept under the agreed retention rules.

D-03

Test report

Normal and failure cases traced to the specification, usable as tender evidence.

D-04

Runbook

What operators do when a connection fails, and the monitoring that shows it.

Europe and the US

Interfaces for both markets

European Union

Europe

Connections to national record systems kept working when a system changes, and the EU MDR file where the software is a medical device or part of one.

United States

HL7 v2 and FHIR interfaces for US record systems, FHIR built to the US Core profiles, and the FDA documentation where the software is a medical device or part of one, prepared with our FDA consultants.

Technologies and standards

What we work with

Technologies and tools

HL7 v2FHIR R4SMART on FHIRDICOMDICOMwebDCMTKfo-dicomOrthancC#.NETJavaNode.jsPythonOpenID ConnectSAML 2.0Docker

Standards, regulations and practices

IHEIEEE 11073IEC 80001-1IEC 81001-5-1IEC 62304ISO 13485EU MDRFDA

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 work and pages.

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

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.

Digitalisation and workflow automation Clinical AI selection and integration Medical and dental imaging software Hospitals

FAQ

Frequently asked questions

Can you connect our devices to another vendor's system for a tender?

Yes, where both sides offer an interface. We map the data, build the gateway and deliver a test report the tender can use.

Do you build on an existing integration engine?

Yes, on the engine the hospital or the vendor already runs, or we write the gateway where none fits.

Which HL7 and FHIR versions do you work with?

HL7 v2 in the version each system supports, and FHIR R4.

How do you test without access to the live systems?

Against vendor simulators, test instances and anonymised messages first, then on site with test patients.

What does an interface project cost?

The inventory comes first. After it we state the effort and the price in writing, before the contract.

Which DICOM services do you implement?

Storage (C-STORE), query and retrieve (C-FIND, C-MOVE), modality worklist, DICOMweb (QIDO-RS, WADO-RS, STOW-RS) and result objects such as SR and SEG.

Are the interfaces secured?

Yes. Encrypted connections, authentication and logging are part of the specification, and for medical devices the interfaces are covered by the security risk assessment, threat model (a structured analysis of how the device could be attacked) and security tests of the IEC 81001-5-1 process.

Do you work with national record systems such as ePA, ELGA, EPD or EESZT?

Yes. The connection is built to the specification and the conformance process of the country, for example the Telematikinfrastruktur and ePA in Germany, ELGA in Austria, EPD in Switzerland and EESZT in Hungary, and to the national system of other countries the same way.

Talk to us

Tell us what has to connect.

The devices or systems, the receiving side and the deadline. We reply with the questions that decide the effort.

Book a 30 minute technical call