CT-berendezés, betegmonitor, laboratóriumi analizátor és munkaállomás összekapcsolása közös gateway-en keresztül

Megbízható adatcsere orvostechnikai eszközök és klinikai rendszerek között

A különböző gyártók eszközeinek, PACS-rendszereinek (képarchívum), betegdokumentációs és laboratóriumi rendszereinek ismételt adatrögzítés nélkül kell képeket, eredményeket és betegadatokat cserélniük. DICOM (az orvosi képek és adatcseréjük szabványa), HL7 (a klinikai üzenetek cseréjének szabványa) és FHIR (az egészségügyi adatok webes cseréjének szabványa) interfészeket és eszközátjárókat specifikálunk. Ezeket európai és amerikai eszközgyártóknak, integrátoroknak és kórházaknak fejlesztjük és teszteljük. Az IEC 62304 szerint járunk el, ha a szoftver orvostechnikai eszköz vagy annak része.

Foglalj időpontot egy 30 perces egyeztetésre Írj nekünk

Szabványok: DICOM · HL7 · FHIR · IHE
Piacok: Európa · USA
Kapcsolódó rendszerek: PACS · LIS · EHR · eszközök
Folyamat: IEC 62304 · ISO 13485 · ISO 14971

Mivel foglalkozunk

Összekapcsoljuk az eszközöket a klinikai rendszerekkel

Képalkotás

DICOM hálózati kapcsolatokat, worklisteket, DICOMweb-interfészeket és eredményobjektumokat kezelünk. A DICOM megfelelőségi nyilatkozatot (conformance statement) naprakészen tartjuk.

Orvosi és fogászati képalkotó szoftverek →

Összekapcsoljuk a kórházi rendszerek üzenetforgalmát

HL7 v2 interfészeket fejlesztünk a betegfelvételhez, a vizsgálatkérésekhez, az eredmények közléséhez és az időpontok kezeléséhez. Az ADT-, ORM-, ORU- és SIU-üzeneteket MLLP-n keresztül továbbítjuk, és kezeljük a visszaigazolásokat. Az adatmezőket minden rendszerhez külön megfeleltetjük, és az interfészeket is külön teszteljük.

FHIR és webes API-k

FHIR R4 erőforrásokat és API-kat fejlesztünk. A SMART on FHIR segítségével lehetővé tesszük, hogy az alkalmazások közvetlenül a betegnyilvántartó rendszerből induljanak.

Orvostechnikai eszközök adatainak továbbítása

Olyan eszközgateway-eket fejlesztünk, amelyek a mérési paramétereket, a mértékegységeket és a betegazonosítókat a fogadó dokumentációs vagy betegnyilvántartó rendszerhez illesztik. Először tisztázzuk, hogy a gateway önmagában orvostechnikai eszköznek minősül-e. A riasztások továbbítása vagy az aktív betegmonitorozáshoz szükséges adatok kezelése miatt a gateway is ebbe a kategóriába tartozhat.

Kapcsolódunk az országos egészségügyi nyilvántartásokhoz

Az országos egészségügyi nyilvántartó rendszerekhez az adott ország előírásai szerint fejlesztünk interfészeket. A rendszerek változásakor is gondoskodunk a kapcsolatok működéséről.

Azonosítás és bejelentkezés

Egyszeri bejelentkezést (single sign-on) és egységes betegkontextust alakítunk ki a betegnyilvántartó rendszer és a kapcsolódó alkalmazások között.

Összekapcsoljuk a különböző gyártók rendszereit

Elkészítjük a gateway-t és az interfészspecifikációt. A beszerzési eljárásban felhasználható tesztjelentést is átadjuk.

Projektalapú fejlesztés →

Tesztelés és üzemeltetés

Az éles indulás előtt a hibaforgatókönyveket is teszteljük. Minden üzenetet naplózunk, monitorozást építünk ki, és runbookot készítünk arra az esetre, ha megszakad a kapcsolat.

A gyakorlatban

Feladatok, amelyekkel hozzánk fordulnak

Kiindulási helyzet

Az eszközplatformnak kommunikálnia kell a kórházi rendszerekkel

Egy eszközplatformnak FHIR-en keresztül kell adatot cserélnie az elektronikus betegnyilvántartással, DICOM-on keresztül pedig a PACS-rendszerrel. Az integrációnak Európában és az Egyesült Államokban is működnie kell.

Így dolgozunk

Megtervezzük és elkészítjük a FHIR-erőforrásokat és a DICOM-szolgáltatásokat (C-STORE, C-FIND, C-MOVE, modality worklist (a képalkotó berendezésnek küldött előjegyzett vizsgálatok listája) és DICOMweb). Az interfészeket a kórházak rendszereivel vagy gyártói szimulátorokkal teszteljük. Elkészítjük a DICOM conformance statementet és a FHIR capability statementet. Ha a platform orvostechnikai eszköznek minősül, az interfészkódra is az IEC 62304 vonatkozik. Ehhez külön követelményeket, teszteket és SOUP-nyilvántartást (az eszközben használt, ismeretlen eredetű, külső féltől származó kódok jegyzéke) készítünk.

Kiindulási helyzet

Megvásárolt AI-alapú eszköz integrálása a kórházi rendszerekbe

Egy kórház AI-alapú diagnosztikai eszközt vásárolt. Az eszköz eredményeit a PACS-rendszerben és a betegnyilvántartásban is meg kell jeleníteni.

Így dolgozunk

A vizsgálatokat a képalkotó berendezésről vagy a PACS-rendszerből továbbítjuk az AI-eszközhöz. Az eredményeket DICOM SR vagy SEG formátumban, illetve HL7- vagy FHIR-eredményként juttatjuk vissza a betegnyilvántartásba. Egyszeri bejelentkezést is kialakítunk, és lehetővé tesszük az alkalmazások indítását közvetlenül a betegnyilvántartásból.

Kiindulási helyzet

Az egyik szállító eszközeit egy másik szállító betegadat-rögzítő rendszerével kapcsoljuk össze

Egy beszerzési eljárásban előírják, hogy a betegmonitorok és lélegeztetőgépek adatait egy másik gyártó betegadat-rögzítő rendszerébe kell továbbítani.

Így dolgozunk

Áttekintjük mindkét rendszer interfészspecifikációját. Egyeztetjük a paraméterek, a mértékegységek és a betegazonosítók megfeleltetését. Ezután elkészítjük a gateway-t és a beszerzési eljáráshoz szükséges tesztjelentést.

A folyamat menete

Így jutunk el a rendszerfelméréstől az éles indulásig

1. lépés

Rendszerfelmérés

Felmérjük az összes érintett rendszert, azok verzióit és elérhető interfészeit. Feltárjuk a hiányosságokat, és ezek alapján meghatározzuk a szükséges munka mennyiségét.

2. lépés

Specifikáció

Írásban rögzítjük az egyeztetett üzenetformátumokat, az adatmezők megfeleltetését, a mértékegységeket, a betegazonosítást és a hibakezelést.

3. lépés

Fejlesztés és tesztelés

A normál működést és a hibaforgatókönyveket a tényleges rendszerekkel vagy gyártói szimulátorokkal teszteljük.

4. lépés

Éles indulás

Runbookban írjuk le, mit kell tenni a kapcsolat megszakadásakor. Az éles indulás után is segítjük az üzemeltetést.

Mit adunk át

Mit adunk át az interfészfejlesztés végén

D-01

Interfészspecifikáció

Rögzítjük az üzenettípusokat, a mezőket, a kódok megfeleltetését (például LOINC vagy SNOMED CT), az UCUM szerinti mértékegységeket, az időzítést és a hibakezelést.

D-02

Gateway vagy interfészszoftver

Elkészítjük és üzembe helyezzük a szoftvert. Minden üzenetet vissza lehet keresni azonosító, időpont és státusz alapján. A naplózott betegadatokat a megállapodásban rögzített megőrzési szabályok szerint kezeljük.

D-03

Tesztjelentés

A normál működés és a hibaforgatókönyvek tesztjeit összekapcsoljuk a specifikáció megfelelő követelményeivel. A teszteredményeket a beszerzési eljárásban is fel lehet használni.

D-04

Runbook

Leírjuk, mit kell tenniük az üzemeltetőknek, ha megszakad egy kapcsolat. A hibák észleléséhez monitorozást alakítunk ki.

Európa és USA

Interfészeket fejlesztünk az európai és az amerikai piacra

Európai Unió

Európa

Az országos egészségügyi nyilvántartó rendszerekkel kiépített kapcsolatokat a rendszerek változásakor is működőképesen tartjuk. Ha a szoftver önálló orvostechnikai eszköz vagy annak része, elkészítjük az EU MDR szerinti dokumentációt.

Egyesült Államok

Az amerikai betegnyilvántartó rendszerekhez HL7 v2 és FHIR interfészeket fejlesztünk, utóbbiakat a US Core profilok szerint. Ha a szoftver önálló orvostechnikai eszköz vagy annak része, FDA-tanácsadóinkkal együttműködve elkészítjük az FDA által előírt dokumentációt.

Technológiák és szabványok

Amivel dolgozunk

Technológiák és eszközök

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

Szabványok, előírások és fejlesztési gyakorlatok

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

Silurus Software

A Silurus Software 2017-ben alakult, irodái Budapesten és Szingapúrban találhatók
Több mint 40 mérnök, EU MDR szabályozási szakértők és FDA-tanácsadók
Az ügyfél ISO 13485 szerinti minőségirányítási rendszerében dolgozunk. A feladatokat és a felelősségi köröket még a munka megkezdése előtt írásban rögzítjük. Ha az ügyfélnek még nincsenek dokumentált szoftverfejlesztési eljárásai, IEC 62304 szerinti sablonokat adunk. Ezeket az ügyfél beépítheti a saját rendszerébe.
Többéves mérnöki együttműködés egy európai MedTech-gyártóval
Török Péter alapító és CTO 1999 óta foglalkozik orvostechnikai szoftverekkel. Korábban a Siemens Healthcare (syngo.via) szoftverfejlesztési igazgatója, majd a Mediso Medical Imaging Systems K+F vezetője volt.
ISO 9001:2015 (NQA, 171041 számú tanúsítvány, érvényes 2027. márciusig) és ISO/IEC 27001:2022 (NQA, 728872 számú tanúsítvány, érvényes 2029. augusztusig)
2025-ben AAA minősítést kaptunk a Dun & Bradstreet hitelképességi értékelésében, amely a legmagasabb minősítési fokozat
A budapesti Eötvös Loránd Tudományegyetem (ELTE) kutatási partnerei vagyunk
2027-től ipari partnerként veszünk részt az EU Horizon Europe LOGOS projektjében a Bolognai Egyetemmel, a Pisai Egyetemmel, az Amszterdami Egyetemmel és a brnói Masaryk Egyetemmel
Dr. Szántó Linda ügyvezető 2025-ben elnyerte a Female Business Leader of the Year, 2026-ban pedig a The Pioneer Award díjat

Hogyan dolgozunk →Minőség és szabványok →Dokumentumminták →Esettanulmányok →

Kapcsolódó tartalmak

Kapcsolódó projektek és oldalak

Az ügyfelek nevét csak a hozzájárulásukkal tesszük közzé.

Esettanulmány

Felhőplatform sugárterápiás kontúrozó algoritmusokhoz

Egy európai gyártó felhőplatformján kutatókórházak futtatják saját kontúrozó algoritmusaikat. A platform DICOM segítségével kapcsolódik a PACS-hoz.

Digitalizáció és munkafolyamat-automatizálás Klinikai AI kiválasztása és integrációja Orvosi és fogászati képalkotó szoftverek Kórházak

FAQ

Gyakori kérdések

Össze tudjátok kapcsolni az eszközeinket egy másik gyártó rendszerével egy beszerzési eljáráshoz?

Igen, ha mindkét rendszer rendelkezik interfésszel. Elvégezzük az adatok megfeleltetését, elkészítjük a gateway-t, és átadjuk a beszerzési eljárásban felhasználható tesztjelentést.

Meglévő integrációs motorra is fejlesztetek?

Igen, használhatjuk a kórház vagy a gyártó meglévő integrációs motorját. Ha egyik sem megfelelő, saját gateway-t fejlesztünk.

A HL7 és a FHIR mely verzióival dolgoztok?

A HL7 v2 esetében az adott rendszer által támogatott verzióval dolgozunk, a FHIR esetében pedig az R4-gyel.

Hogyan teszteltek, ha nem fértek hozzá az éles rendszerekhez?

Először gyártói szimulátorokkal, tesztkörnyezetekben és anonimizált üzenetekkel tesztelünk. Ezután a helyszínen, tesztbetegek adataival ellenőrizzük a működést.

Mennyibe kerül egy interfészfejlesztési projekt?

Először felmérjük a rendszereket. Ezután, még a szerződéskötés előtt, írásban megadjuk a szükséges ráfordítást és az árat.

Mely DICOM-szolgáltatásokat fejlesztitek?

Tárolás (C-STORE), keresés és lekérés (C-FIND, C-MOVE), modality worklist, DICOMweb (QIDO-RS, WADO-RS, STOW-RS), valamint eredményobjektumok, például SR és SEG.

Gondoskodtok az interfészek biztonságáról?

Igen. A titkosított kapcsolatok, a hitelesítés és a naplózás már a specifikációban szerepelnek. Orvostechnikai eszközöknél az interfészekre is kiterjed az IEC 81001-5-1 szerinti biztonsági kockázatértékelés, a threat model (az eszköz elleni lehetséges támadások módszeres elemzése) és a biztonsági tesztelés.

Országos egészségügyi nyilvántartó rendszerekkel, például az ePA, ELGA, EPD vagy EESZT rendszerrel is dolgoztok?

Igen. A kapcsolatokat az adott ország műszaki előírásai és megfelelőségellenőrzési eljárásai szerint alakítjuk ki. Németországban a Telematikinfrastruktur és az ePA, Ausztriában az ELGA, Svájcban az EPD, Magyarországon az EESZT rendszeréhez kapcsolódunk. Más országok egészségügyi nyilvántartó rendszereivel is ugyanezen elvek szerint dolgozunk.

Vedd fel velünk a kapcsolatot

Írd meg, mely rendszereket kell összekapcsolni

Add meg az összekapcsolandó eszközöket vagy rendszereket, a fogadó rendszert és a határidőt. Válaszunkban tisztázzuk azokat a kérdéseket, amelyek alapján meghatározhatjuk a szükséges munkát.

Foglalj időpontot egy 30 perces szakmai egyeztetésre