Szakterületek · Régóta piacon lévő orvosi szoftverek

Több évtizede forgalmazott orvostechnikai szoftverek gyártói

A tizenöt-harminc éve forgalmazott C++- és MFC-alapú asztali alkalmazások néhány tapasztalt fejlesztőtől, régi toolchaintől és az MDD szerint készült szoftverdokumentációtól függenek. A kórházak FHIR-t és DICOMwebet kérnek, miközben minden módosításnál meg kell őrizni az eszköz tanúsított állapotát. Átvesszük a kódot, aktuális toolchainre állítjuk át a buildet, és az első módosítás előtt tesztekben rögzítjük a jelenlegi működést.

Foglalj 30 perces konzultációt Írj nekünk

Technológiák: C++ · MFC · .NET · DICOM · HL7
Szabványok: IEC 62304 4.4. pont · ISO 13485 · EU MDR · FDA
Első lépés: Ingyenes, 30 perces műszaki konzultáció

A szoftvermódosítás folyamata

Így jutnak el a módosítások az évtizedek óta forgalomban lévő termékekbe

Követelmények

Az eredeti követelmények csak régi hibajegyekből és néhány tapasztalt fejlesztő emlékezetéből ismerhetők meg.

JavulásDokumentáljuk a követelményeket, és összekapcsoljuk őket a kóddal, hogy az új igényeket össze lehessen vetni velük.

Tervezés

Az architektúráról nincs külön dokumentáció, csak a forráskód őrzi a terveket, ezért minden módosítás előtt újra el kell készíteni őket.

JavulásAz architektúrát és a részletes terveket egyszer rekonstruáljuk, majd a vállalat dokumentációjában rögzítjük és megőrizzük őket.

Megvalósítás

A forráskód fordításához régi fordítóprogramok szükségesek, és kevés fejlesztő vállal szívesen munkát rajta.

JavulásA buildet korszerű toolchainre állítjuk át, így új fejlesztők is bekapcsolódhatnak a munkába.

Verifikáció

Nincsenek automatizált tesztek, ezért minden release előtt újra el kell végezni a manuális regressziós teszteket.

JavulásA tesztekkel rögzítjük a szoftver jelenlegi működését, és minden módosításkor automatikusan lefuttatjuk őket.

Release

Minden release-hez az MDD szerint összeállított szoftverdokumentáció alapján kell hatáselemzést készíteni.

JavulásMinden release-hez hatáselemzést mellékelünk, a dokumentációt pedig az MDR szerinti tanúsítványhoz szükséges műszaki dokumentáció követelményeihez igazítjuk.

A telepített rendszerek támogatása

Az ügyfeleknél megnő a memóriahasználat, vagy összeomlik az alkalmazás. Laboratóriumi körülmények között nem sikerül reprodukálni a hibákat, ezért megoldatlanul maradnak.

JavulásA hibákat az adott helyszínen használt verziónak megfelelő builden reprodukáljuk, majd kijavítjuk őket, és regressziós tesztet készítünk hozzájuk.

Változtatás

A pályázatok FHIR- és DICOMweb-támogatást követelnek meg, a termék azonban HL7 v2 és DIMSE segítségével kommunikál.

JavulásA meglévő interfészek mellé FHIR- és DICOMweb-interfészeket fejlesztünk, így a telepített rendszerek továbbra is működnek.

A cél

A termék piacon marad, és továbbfejleszthető

A gyártóknak

A jelentős változás vizsgálata minden release-nél
A szoftvermag működését rögzítő dokumentáció
Új fejlesztők bevonása korszerű toolchain használatával

A kórházaknak és a klinikai szakembereknek

Hosszú munkamenet alatt is stabilan működő alkalmazás
Korszerű interfészek a kórházi rendszerekkel való kapcsolathoz
A frissítések megőrzik azt a működést, amelyre a felhasználók támaszkodnak

A betegek számára

Gyorsan érkező javítások a kórház működéséhez szükséges szoftverhez
A betegellátást javító új funkciók hamarabb elérhetők a kórházban
Minden frissítés után a korábban rögzített működéshez viszonyítva ellenőrizzük az eredményeket

Problémák és megoldások

Ügyfélproblémák és a megoldásuk

A szoftver magját megtervező fejlesztők már nem dolgoznak nálunk.

A forráskód és a build alapján rekonstruáljuk az architektúrát és a részletes terveket. A tapasztalt fejlesztők rövid egyeztetéseken segítenek pótolni a hiányzó információkat, az eredményt pedig beépítjük a dokumentációba.

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

Az ügyfeleknél lelassul vagy összeomlik az alkalmazás, de nálunk nem sikerül reprodukálni a hibát.

A telepített verziónak megfelelő builden reprodukáljuk a helyszíni körülményeket, és megismételjük a hibajelentésekben szereplő munkafolyamatokat. A rendelkezésre álló crash dumpokat is elemezzük. Minden hibajavításhoz regressziós tesztet készítünk.

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

A tanúsítási eljárás újraindítása nélkül nem módosíthatjuk a szoftver magját.

Az első módosítás előtt tesztekkel rögzítjük a rendszer jelenlegi működését. Minden release-hez hatáselemzést készítünk, és értékeljük, hogy a módosítás jelentős változásnak minősül-e.

IEC 62304 gap analysis

Az újraírás évekig tartana, és elveszítenénk a már meglévő verifikációs bizonyítékokat.

Megtartjuk a szoftver magját. Először korszerű toolchainre állítjuk át a buildet, és elkészítjük a regressziós teszteket. Egy modult csak akkor cserélünk le, ha már feltártuk és teszteltük a működését. Minden lépést külön release-ben adunk ki, saját hatáselemzéssel és írásban rögzített tartalommal.

Így dolgozunk

A kórházak FHIR- és DICOMweb-kapcsolatokat kérnek, a meglévő interfészeink azonban HL7 v2-t és DIMSE-t használnak.

Az új interfészt külön rétegként építjük be a telephelyeken már működő HL7 v2 és DIMSE kapcsolatok mellé. A korábbi kapcsolatok változatlanul működnek tovább. Az új réteghez saját hitelesítést és titkosított adatátvitelt alakítunk ki. A threat modelt (az eszköz elleni lehetséges támadások módszeres elemzése) is frissítjük. Az integrációt a telephelyeken működő rendszerekkel teszteljük.

Interoperabilitás

A szoftverdokumentációnk még az MDD alapján készült, és a bejelentett szervezet hiányosságokat fog találni benne.

A gap analysis (a szabvány követelményeihez képest fennálló hiányosságok vizsgálata) során átvizsgáljuk a kódot, a dokumentációt és a folyamatokat. A már forgalomban lévő szoftvereknél a jelentést az IEC 62304 4.4. pontja szerinti dokumentáció részeként készítjük el. Értékeljük a forgalomban lévő termékről érkezett visszajelzéseket, és dokumentáljuk az eredményeket. Rögzítjük a hiányok megszüntetésének tervét és a további használat indoklását is. Ezután az ügyfél sablonjai, felülvizsgálati folyamatai és jóváhagyási rendje szerint készítjük el a dokumentumokat.

Utólagos IEC 62304 dokumentáció

A külső fejlesztésű könyvtárak verziói évekkel elmaradnak a jelenleg elérhető változatoktól.

Minden külső fejlesztésű könyvtárat felveszünk az SBOM-ba (a buildben szereplő összes szoftverkomponens jegyzéke), és SOUP-ként (ismeretlen eredetű szoftver, vagyis az eszközben használt, külső féltől származó kód) is nyilvántartunk. A könyvtárakat ott frissítjük, ahol ezt biztonságosan megtehetjük. A frissítéseket ugyanúgy teszteljük, mint a többi módosítást.

Orvostechnikai eszközök kiberbiztonsága

Kódfelülvizsgálat

A régi C++-kód felülvizsgálatának megállapításai és a dokumentáció tartalma

Feltárt probléma	Mit teszünk	Dokumentáció
Hosszú munkamenetek során növekvő memóriahasználat	A telepített verziónak megfelelő builden reprodukáljuk a hosszú munkamenetet, majd memóriaelemző eszközökkel megkeressük a hiba okát.	Hibajelentés · regressziós teszt
Laboratóriumi körülmények között nem reprodukálható összeomlások	Elemezzük a crash dumpokat, és felülvizsgáljuk a megosztott állapot és a szálak kezelését.	Hibajelentés · anomálialista
Elavult fordító és régóta nem karbantartott könyvtárak	A buildet korszerű toolchainre állítjuk át. Nyilvántartásba vesszük a harmadik féltől származó könyvtárakat, és ahol biztonságosan megoldható, frissítjük őket.	SOUP-lista · SBOM
Nincsenek automatizált tesztek	Tesztekben rögzítjük a jelenlegi működést, a hardveres és hálózati interfészekhez pedig szimulációs módot alakítunk ki.	Verifikációs terv · tesztjelentések
A forráskódon kívül nem dokumentált tervek	A forráskód és a build alapján rekonstruáljuk az architektúrát és a részletes terveket. A hiányzó információk pótlásában a tapasztalt fejlesztők rövid egyeztetéseken segítenek.	Architektúra · részletes tervek
A pályázati feltételeknek már nem megfelelő interfészek	A FHIR- és DICOMweb-interfészeket külön rétegként építjük be, miközben a meglévő HL7 v2- és DIMSE-kapcsolatok tovább működnek.	Interfészspecifikáció · megfelelőségi nyilatkozat

Kinek ajánljuk

Amikor a Silurus a megfelelő partner

Keress meg minket, ha

A meghatározó fejlesztők nyugdíjba vonulása után is forgalmazni szeretnéd a terméket
Olyan helyszíni hibákat szeretnél feltárni és kijavítani, amelyeket a csapatod nem tud reprodukálni
Egy távozó beszállítótól szeretnéd átvenni a kódot
MDR szerinti műszaki dokumentációt szeretnél, amely a termék korábban hiányzó szoftverdokumentációját is tartalmazza

Kapcsolat

Írd meg, milyen feladaton dolgozol.

Helyszíni hiba, régi toolchain, új interfész vagy az MDR-hez szükséges szoftverdokumentáció. Írj néhány sort a használt programozási nyelvről, a kódbázis koráról és az eszköz osztályáról, vagy foglalj egy ingyenes, 30 perces műszaki konzultációt.

Foglalj 30 perces műszaki konzultációt

GYIK

Gyakran ismételt kérdések.

Korszerűsíthetitek a C++- és MFC-alkalmazásunkat a CE-jelölés elvesztése nélkül?

Igen, ha minden módosítás az ügyfél változáskezelési eljárásán halad át, hatáselemzéssel és verifikációval együtt. Minden release esetén külön meg kell vizsgálni, hogy jelentős változásnak minősül-e. Az MDD szerinti tanúsítvánnyal rendelkező eszköz addig maradhat az átmeneti szabályok hatálya alatt, amíg a kialakítása és a rendeltetése (amire a gyártó a szoftvert szánja) nem változik jelentősen. A jelentős változások megítéléséhez az MDCG 2020-3 ad útmutatást. A korszerűsítést egymást követő release-ekre bontjuk. Az első módosítás előtt rögzítjük a regressziós tesztelés kiindulási állapotát.

Újraírjuk vagy refaktoráljuk a terméket?

A kódfelülvizsgálat után modulonként döntjük el, melyik megoldás indokolt. A teljes szoftvermag újraírásával elvesznének az évek során összegyűjtött verifikációs bizonyítékok. A tesztelhetővé tehető kódot refaktoráljuk, a többi modult szükség esetén lecseréljük. A gap analysis során készült jelentés modulonként tartalmaz javaslatot.

A szoftverdokumentációnk még az MDD alapján készült. Az IEC 62304 a már piacon lévő termékekre is vonatkozik?

Az MDR a technika állásának megfelelő szoftver-életciklust követel meg. Ennek igazolására az IEC 62304 elfogadott módszer. Az IEC 62304 első módosításának 4.4. pontja a régi szoftverekre vonatkozik. Előírja a használat során érkezett visszajelzések és a kockázatkezelés felülvizsgálatát, a gap analysist, a hiányosságok megszüntetésének tervét és a további használat indoklását.

Hozzá tudtok adni FHIR- vagy DICOMweb-interfészt egy HL7 v2-re és DICOM DIMSE-re épülő termékhez?

Igen. Az új interfészt külön rétegként tervezzük és fejlesztjük, így a telepített rendszerek meglévő HL7 v2- és DIMSE-kapcsolatai változatlanul működnek. Az új réteget a helyszíni rendszerekkel teszteljük, és az interfészspecifikációban, valamint a DICOM megfelelőségi nyilatkozatban dokumentáljuk.

Meddig maradhat piacon egy MDD szerint tanúsított orvostechnikai eszköz?

Az (EU) 2023/607 rendelet alapján az eszköz besorolásától függően 2027 vagy 2028 végéig. Az átmeneti időszak meghosszabbítása csak meghatározott feltételekkel érvényes. A gyártónak 2024. május 26-ig kérelmeznie kellett az MDR szerinti tanúsítást egy bejelentett szervezetnél (az eszközt az EU MDR szerint tanúsító független szervezet). A szervezettel 2024. szeptember 26-ig írásbeli megállapodást kellett kötnie. A gyártónak emellett az MDR szerinti minőségirányítási rendszert kell működtetnie. Az eszköz kialakítását vagy rendeltetését sem módosíthatja jelentősen. Ha ezek a feltételek nem teljesülnek, az eszköznek már most MDR szerinti tanúsítványra van szüksége.

Az Egyesült Államokban is forgalmazzuk a terméket. Ott milyen következményekkel jár egy módosítás?

Az FDA 510(k) clearance alapján forgalmazott eszköz minden szoftvermódosítását az FDA meglévő eszközök szoftverváltozásaira vonatkozó útmutatója szerint értékeljük. Megállapítjuk, hogy szükséges-e új 510(k) benyújtás. Az eredményt a módosítás dokumentációjában rögzítjük, az EU szerinti jelentős változás értékelésével együtt.

Hogyan kezdjük el?

Egy IEC 62304 gap analysis elkészítésével. Átvizsgáljuk a kódot, a dokumentációt és a fejlesztési folyamatot. Írásos jelentést és a hiányosságok megszüntetésére szolgáló intézkedési tervet adunk át, amely a korszerűsítés lépéseinek sorrendjét is tartalmazza. A további lépésekre külön-külön adunk ajánlatot, és azokat írásban egyeztetjük.

Kapcsolódó tartalmak

Kapcsolódó szolgáltatások és szakterületek.

Legacy orvostechnikai szoftverek átvétele és korszerűsítése IEC 62304 gap analysis Utólagos IEC 62304 dokumentáció Interoperabilitás Orvostechnikai eszközök kiberbiztonsága Orvosi képalkotó rendszerek gyártói