Our product runs on an operating system that is going out of support. Can you move it?

Yes, after an assessment. We check what depends on the operating system and whether a move is feasible, then move the product to a supported version and verify and document the change under your change control. Where a move is not feasible, the risk controls and an end of life plan are documented instead.

How do you handle outdated or vulnerable third party libraries?

Each SOUP item is checked for its support status and known vulnerabilities. Updates are assessed for risk, tested and recorded in the SOUP list and the SBOM.

Do you rewrite old software?

If you decide so, yes. We start with the smallest change that solves the problem, then set the priorities with you: which modules to keep, which to refactor and which to rewrite. The whole product rarely has to be rewritten, and every step is your decision, built under IEC 62304 and released under your change control.

Can you take over the product from our supplier?

Yes. Silurus Software is first qualified as a supplier in your quality system, and your regulatory team decides whether the notified body has to be told of the supplier change. We run handover sessions while the supplier is still available, then take over the build, the maintenance and the releases.

How do we keep a clear picture of the software?

Automated builds and regression tests run on every change, and the traceability and the SOUP list are updated with every release.

Can our own team take the product back later?

Yes. The structure, the tests and the records are written so that your own team or another supplier can maintain them.

Yes. Qt 5 and Qt 6 with C++ and QML, including the migration from Qt 5 to Qt 6.

How fast can you take over a product?

The first engineers start within two to three weeks of signature. The handover plan is set for the time the outgoing supplier is still available.

Do you support CAPA and post market surveillance?

Yes. Problem reports are investigated to their root cause and documented as input to your CAPA, complaint handling and post market surveillance processes.

Do you modernise WPF, WinForms and .NET Framework applications?

Yes. Our engineers have long experience with WPF and WinForms desktop applications and have migrated products from the .NET Framework to current .NET, step by step and verified at each release.

Egy régebbi radiológiai munkaállomás, amelyet build szerver köt össze a korszerűbb utódjával

Szolgáltatások · Legacy orvostechnikai szoftverek átvétele és korszerűsítése

Legacy orvostechnikai szoftverek átvétele és korszerűsítése

Átvesszük és hosszú távon karbantartjuk a már forgalomban lévő orvostechnikai szoftvereket. Korszerűsítjük az elavult technológiai környezetet, javítjuk a kódot és a dokumentációt, valamint megbízható tesztelési és buildfolyamatokat vezetünk be. A változtatások szabályozási hatásának értékelésével támogatjuk a biztonságos és ellenőrizhető szoftverkiadásokat, az EU MDR és az FDA követelményeit is figyelembe véve.

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

Programozási nyelvek: C · C++ · C# · Java · Python
Fő szakterületeink: SOUP, támogatás nélkül maradó komponensek, biztonság
Folyamat: IEC 62304 · ISO 13485 · ISO 14971
Szabályozási eljárás: EU MDR · FDA

Mivel foglalkozunk

Régóta forgalomban lévő termékek karbantartása

Platformok megszűnő támogatással

Felmérjük a platformfüggőségeket, és megvizsgáljuk, hogy műszakilag és gazdaságilag megvalósítható-e az átállás egy támogatott verzióra. Ha igen, átállítjuk a terméket, majd az új környezetben elvégezzük a verifikációt.

Elavult vagy sérülékeny SOUP-komponensek

Minden külső komponensnél ellenőrizzük a támogatottságot és az ismert sérülékenységeket. A frissítéseket egyenként értékeljük, teszteljük és dokumentáljuk.

Orvostechnikai eszközök kiberbiztonsága →

A fejlesztés átvétele a korábbi beszállítótól

Egyeztetünk a beszállítóval, és átvesszük a forráskódot, a build folyamatot és a dokumentációt. A karbantartást az előre egyeztetett időponttól folytatjuk.

IEC 62304 gap analysis →

Nehezen tesztelhető forráskód

Karakterizációs tesztekkel rögzítjük a szoftver jelenlegi működését. Ezeket elkülönítjük a jóváhagyott követelményektől. Az ismert hibákat külön dokumentáljuk, nehogy elvárt működésként rögzüljenek. A kódot modulokra bontjuk, és olyan unit teszteket készítünk, amelyek CI-ban, hardver nélkül is futnak. Mérjük és fokozatosan növeljük a tesztlefedettséget. A modulokat hardware-in-the-loop tesztkörnyezetben, a tényleges hardveren is ellenőrizzük.

Build folyamatok és regressziós tesztelés

A buildeket CI-ban futtatjuk, rögzített fejlesztőeszköz-verziókkal és függőségekkel. Minden módosítás után regressziós teszteket végzünk.

A kórházi működéshez szükséges interfészek

Valós üzenetek és adatkészletek alapján minden release-hez regressziós teszteket készítünk. Az adatokat még az eredeti környezetükben anonimizáljuk. Ha az adatvédelmi szabályok megengedik, álnevesítést is alkalmazhatunk, mielőtt az adatok kikerülnének onnan.

Interoperabilitás →

Üzem közben jelentkező hibák és karbantartás

Feltárjuk a hibák kiváltó okát, majd a karbantartási terv szerint elvégezzük a javításokat és kiadjuk az új szoftververziót. Minden release-hez frissítjük a dokumentációt is.

A felhasználói felület megújítása

A felhasználói felületet fokozatosan újítjuk meg. Az új és áttervezett részeknél az IEC 62366-1 szerinti teljes használhatósági tervezési és értékelési folyamatot elvégezzük. A C melléklet szerinti eljárást csak a meglévő felület változatlan, korábban nem értékelt részeinél alkalmazzuk.

A gyakorlatban

Feladatok, amelyekkel hozzánk fordulnak

Kiindulási helyzet

A bejelentett szervezet hiányosságokat talált egy régóta forgalomban lévő eszköznél

Egy IIb osztályú eszköz még az irányelvek hatálya alatt került forgalomba. A bejelentett szervezet hiányosságokat talált a szoftverdokumentációban, de a termék forgalmazását folytatni kell.

Így dolgozunk

A Silurus Software minden megállapítást az IEC 62304 megfelelő tevékenységéhez rendel. A korábban fejlesztett szoftverekre vonatkozó eljárást (IEC 62304 1. módosítás, 4.4. pont) alkalmazzuk. A kockázatalapú gap analysis (a szabvány követelményeihez képest fennálló hiányosságok vizsgálata) alapján elkészítjük a szükséges dokumentumokat. Ha nincs korábbi bizonyíték, megjelöljük, mely verifikációkat kell megismételni. A kódból visszafejtett követelményeket külön jelöljük, és az ügyfél csapata jóváhagyás előtt felülvizsgálja őket. A terméket nem írjuk újra. Minden változtatást az ügyfél változáskezelési eljárása szerint végzünk.

Kiindulási helyzet

A beszállító nyolc hét múlva megszünteti a támogatást

Egy IIa osztályú termék külső beszállítója nyolc hét múlva megszünteti a támogatást. A C++- és Qt-alapú kódbázist és a build környezetet főként a beszállító ismeri.

Így dolgozunk

Az első héten átvesszük a forráskódot és a build környezetet, és gondoskodunk arról, hogy kapcsolatban maradjunk a beszállítóval. Amíg elérhető, átadási egyeztetéseket tartunk, és saját környezetünkben reprodukálhatóvá tesszük a buildet. Az IEC 62304 gap analysis során felmérjük a forráskód és a dokumentáció állapotát. A nyolcadik hét végére átvesszük a karbantartást az egyeztetett feladatkörben, és összeírjuk a fennmaradó teendőket. A következő release-t már a gap analysis alapján készített terv szerint adjuk ki.

Kiindulási helyzet

Qt 5- és .NET-alapú asztali alkalmazás modernizálása

A fő termék egy Windows alatt futó asztali alkalmazás, amelyet C++-ban, Qt 5-tel és néhány .NET-komponenssel fejlesztettek. A termék jól fogy, de a módosítások sok időt vesznek igénybe.

Így dolgozunk

A meglévő működéshez teszteket készítünk, majd a programlogikát tesztelhető modulokba szervezzük. A Qt 6-ra történő átállást szoftvermódosításként értékeljük. A még irányelv szerinti tanúsítvánnyal forgalomban lévő eszközöknél azt is megvizsgáljuk, hogy az átállás jelentős változtatásnak minősül-e. Ehhez az Orvostechnikai Eszközökkel Foglalkozó Koordinációs Csoport MDCG 2020-3 útmutatóját alkalmazzuk. Ezután lépésenként megtervezzük az átállást. Minden lépést verifikálunk, majd az ügyfél változáskezelési folyamatában adunk ki.

Kiindulási helyzet

A termék régóta forgalomban van, az eredeti fejlesztők már távoztak

Az eszköz évek óta forgalomban van. Az eredeti fejlesztők már nem dolgoznak rajta, a komponensek elérik életciklusuk végét, és biztonsági javításokra van szükség.

Így dolgozunk

Átvesszük a hosszú távú karbantartó fejlesztést. Kivizsgáljuk a hibajelentéseket, feltárjuk a kiváltó okokat, és adatokat adunk a CAPA-hoz (helyesbítő és megelőző intézkedések). Részt veszünk a panaszkezelésben és a forgalomba hozatal utáni felügyeletben. Frissítjük a SOUP-ot és az operációs rendszereket, telepítjük a biztonsági javításokat, és előkészítjük az ütemezett release-eket. A munkát kijelölt, állandó csapat végzi. Személycsere esetén dokumentáltan adjuk át a feladatokat.

A folyamat menete

Így vesszük át és tartjuk karban a szoftvert

1. lépés

Felmérés

Átvizsgáljuk a forráskódot, a build folyamatot, a SOUP-komponenseket és a dokumentációt. Összeírjuk a kockázatokat, külön kitérve a megszűnő támogatású komponensekre és a hiányzó tesztekre.

2. lépés

A kiindulási állapot rögzítése

Olyan buildet készítünk, amely tiszta gépen is működik. Rögzítjük a SOUP-komponensek aktuális verzióit, és tesztekkel dokumentáljuk a szoftver jelenlegi működését.

3. lépés

Modernizálás

Modulról modulra haladva frissítjük a platformot, refaktoráljuk a kódot és kijavítjuk a hibákat. Minden módosítást verifikálunk és dokumentálunk.

4. lépés

Karbantartás

A karbantartási terv szerint kezeljük a hibajelentéseket, elvégezzük a biztonsági frissítéseket és új release-eket készítünk. A szoftver állapota minden buildnél ellenőrizhető.

Átvétel

Ezekre van szükségünk a fejlesztés átvételéhez

A munka megkezdéséhez az alábbiakat kérjük

Hozzáférés a forráskód-repozitóriumokhoz és a build környezethez, vagy mindkettő másolata
Aktuális szoftverdokumentáció, kockázatkezelési dokumentáció és nyitott hibajelentések
A kiadott szoftververziók listája és az egyes verziók telepítési helyei
Kapcsolattartó a távozó beszállítónál az átadási egyeztetésekhez
Név szerint kijelölt felelős a gyártónál a döntésekhez és a változáskezeléshez

Mit adunk át

Hosszú távon is karbantartható termék

D-01

SOUP-jelentés és a támogatások megszűnésének áttekintése

Minden külső komponensnél rögzítjük a verziót, a támogatottságot és az ismert sérülékenységeket. A szükséges intézkedéseket is dokumentáljuk.

D-02

Reprodukálható build

A buildet CI pipeline-ban futtatjuk, rögzített fordítóprogram-, könyvtár- és eszközverziókkal, pontosan meghatározott függőségekkel. Egy korábban kiadott verzió újbóli buildelésével ellenőrizzük a reprodukálhatóságot. Az eredményt összehasonlítjuk a korábban kiadott állományokkal, az eltéréseket pedig megmagyarázzuk és dokumentáljuk.

D-03

Regressziós tesztkészlet

Minden buildnél automatizált teszteket futtatunk. Ezek azonnal jelzik, ha egy módosítás hibát okoz a korábban tesztelt működésben.

D-04

Karbantartott szoftververziók

A hibajavításokat, frissítéseket és új funkciókat hatáselemzéssel, release note-okkal és frissített nyomon követhetőségi dokumentációval adjuk ki.

EU és USA

Tanúsított termékek módosításai

Európai Unió

EU MDR

Elkészítjük a bejelentett szervezetnek szánt változásértékelés szoftveres részét. Az irányelv alapján kiadott tanúsítvánnyal még forgalmazott eszközöknél az MDCG 2020-3 szerint is értékeljük a módosítást.

Egyesült Államok

FDA

Értékeljük, hogy egy 510(k) clearance alapján forgalmazott eszköz szoftvermódosításához szükséges-e új 510(k) benyújtása. Azt is megvizsgáljuk, hogy elegendő-e a módosítást a minőségirányítási rendszer szerinti tervezési és fejlesztési dokumentációban rögzíteni.

Technológiák és szabványok

Amivel dolgozunk

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

CC++QtQMLC#.NETWPFWinFormsJavaSonarQubeclang-tidyCoverityGoogleTestNUnitSquishJenkinsAzure DevOpsDockerGitCI/CD

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

Karakterizációs tesztekSOUP-listaSBOMIEC 62304ISO 13485ISO 14971IEC 81001-5-1IEC 62366-1EU MDRMDCG 2020-3FDA 510(k)FDA útmutató a szoftvermódosítások 510(k) követelményeirőlFDA QMSR (21 CFR 820)

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

Laboratóriumi eszköz refaktorálása és IEC 62304 szerinti dokumentációja

Egy holland egyetemi egészségügyi központ laboratóriumi eszközének asztali alkalmazását és firmware-ét három hónap alatt refaktoráltuk, hogy mindkettő tesztelhető legyen. Az IEC 62304 szerinti dokumentációt is elkészítettük.

Esettanulmány

Funkciófejlesztés az IEC 62304 szerint egy nagy .NET-kódbázisban

Tapasztalt fejlesztőink több éven át dolgoztak egy európai gyártónak. Munkájuk során a gyártó fejlesztési életciklusát, minőségirányítási rendszerét és felülvizsgálati folyamatait követték.

IEC 62304 gap analysis Utólagos dokumentáció készítése az IEC 62304 szerint Orvostechnikai eszközök kiberbiztonsága Szabályozási tanácsadás az EU MDR és az FDA követelményeihez Hosszabb ideje működő orvosiszoftver-cégek

FAQ

Gyakori kérdések

A termékünk olyan operációs rendszeren fut, amelynek hamarosan megszűnik a támogatása. Át tudjátok állítani?

Igen, előzetes felmérés után. Megvizsgáljuk, hogy a szoftver mely részei függnek az operációs rendszertől, és megvalósítható-e az átállás. Ha igen, támogatott verzióra állítjuk át a terméket. A módosítást a gyártó változáskezelési eljárása szerint verifikáljuk és dokumentáljuk. Ha az átállás nem lehetséges, dokumentáljuk a kockázatcsökkentő intézkedéseket és a támogatás megszűnésére készített tervet.

Hogyan kezelitek az elavult vagy sérülékeny külső könyvtárakat?

Minden SOUP-elem támogatási állapotát és ismert sérülékenységeit ellenőrizzük. Felmérjük a frissítések kockázatát, majd teszteljük és rögzítjük a frissítéseket a SOUP-listában és az SBOM-ban (a buildben szereplő összes szoftverkomponens jegyzéke).

Újraírjátok a régi szoftvereket?

Igen, ha így döntesz. Először megkeressük a probléma megoldásához szükséges legkisebb módosítást. Ezután közösen döntünk arról, mely modulokat tartjuk meg, refaktoráljuk vagy írjuk újra. A teljes terméket ritkán kell újraírni. Minden lépésről te döntesz, mi pedig az IEC 62304 szerint végezzük a fejlesztést. A módosításokat a változáskezelési eljárásod szerint adjuk ki.

Át tudjátok venni a terméket a jelenlegi beszállítónktól?

Igen. Először a gyártó a saját minőségirányítási rendszere szerint beszállítóként minősíti a Silurus Software-t. A gyártó szabályozási csapata dönti el, hogy a beszállítóváltásról értesíteni kell-e a bejelentett szervezetet. Amíg a korábbi beszállító elérhető, egyeztetünk vele az átadásról. Ezután átvesszük a build folyamatot, a karbantartást és a release-ek kezelését.

Hogyan követhetjük nyomon a szoftver állapotát?

Minden módosításnál automatizált buildeket készítünk és regressziós teszteket futtatunk. A nyomon követhetőségi dokumentációt és a SOUP-listát minden release-nél frissítjük.

Később visszaveheti a saját csapatunk a terméket?

Igen. Úgy alakítjuk ki a kódszerkezetet, a teszteket és a dokumentációt, hogy a karbantartást később a saját csapatotok vagy egy másik beszállító is folytathassa.

Dolgoztok Qt-vel?

Igen. Qt 5-tel és Qt 6-tal dolgozunk, C++ és QML használatával. A Qt 5-ről Qt 6-ra történő átállást is vállaljuk.

Mennyi idő alatt tudjátok átvenni a terméket?

Az első mérnökeink a szerződés aláírását követő két-három héten belül munkába állnak. Az átadás ütemezését a távozó beszállító rendelkezésre állásához igazítjuk.

Támogatjátok a CAPA-folyamatot és a forgalomba hozatal utáni felügyeletet?

Igen. A hibajelentéseknél feltárjuk a kiváltó okokat, és dokumentáljuk az eredményeket. Ezeket a gyártó felhasználhatja a CAPA-folyamatban, a panaszkezelésben és a forgalomba hozatal utáni felügyeletben.

Modernizáltok WPF-, WinForms- és .NET Framework-alkalmazásokat?

Igen. Mérnökeink sokéves tapasztalattal rendelkeznek WPF- és WinForms-alapú asztali alkalmazások fejlesztésében. Korábban több terméket is átállítottunk .NET Frameworkről a .NET aktuális verziójára. Az átállást lépésenként végezzük, és minden release-nél verifikáljuk a módosításokat.

Vedd fel velünk a kapcsolatot

Mutasd be a termékedet

Írd meg, milyen termékről és platformról van szó, és min szeretnél változtatni. Válaszunkban javaslatot teszünk az első lépésre.

Foglalj időpontot egy 30 perces szakmai egyeztetésre