Rövid válasz: ha egy szoftvernek orvosi rendeltetése van (diagnosztika, megelőzés, monitorozás, előrejelzés, prognózis, kezelés), akkor az orvostechnikai eszközökről szóló EU rendelet (MDR, 2017/745) értelmében orvostechnikai eszköznek minősül, és kockázati osztályba sorolják: I, IIa, IIb vagy III, többnyire a VIII. melléklet 11. szabálya alapján. Az osztály dönti el, hogy önminősítést végezhet-e (csak I. osztály esetén), vagy bejelentett szervezet bevonása szükséges, milyen mélyreható legyen a klinikai értékelés, és hogyan működjön a piacfelügyelet. Külön, az IEC 62304 mérnöki szabvány a szoftvernek biztonsági osztályt ad: A (nem okozhat sérülést), B (nem súlyos sérülés okozható) vagy C (halál vagy súlyos sérülés okozható), ami meghatározza, mennyi dokumentációra, tervezésre és tesztelésre van szükség az életciklus során. A két besorolás összefügg, de független, és mindkettőt a szoftver által okozható kár határozza meg, nem pedig a komplexitása.
1. lépés: egyáltalán eszköznek minősül?
A szoftver orvostechnikai eszközként minősül az EU MDR szerint, ha a rendeltetése orvosi jellegű: diagnosztizálás, megelőzés, monitorozás, előrejelzés, prognózis vagy kezelés (2. cikk (1) bekezdés). Az adatokat csak tároló, archiváló, kommunikáló, megjelenítő vagy kereső szoftver nem minősül eszköznek; az orvosi információkat létrehozó vagy módosító szoftver a diagnosztikai vagy kezelési döntések támogatása érdekében az MDCG 2019-11 szerint eszköznek minősül.
Az MDR definíciója (2. cikk (1) bekezdés) a rendeltetésen alapul. Az az adatokat tároló, archiváló, kommunikáló, megjelenítő vagy egyszerű kereséseket végző szoftver nem eszköz (az MDCG 2019-11 ezt említi). Az az szoftver, amely orvosi információt hoz létre vagy módosít a diagnózis vagy kezelési döntés támogatására, az. Egy olyan feljegyzés, amely egy laboratóriumi értéket mutat a labor referencia-tartományával, nem eszköz; az a szoftver viszont igen, amely közli a felhasználóval, hogy az érték egy állapotot jelez, vagy adagolást javasol. A Egészségügyi alkalmazás orvostechnikai eszköznek minősül? részletesen tárgyalja a minősítési lépést.
2. lépés: az MDR kockázati osztály, 11. szabály
Az MDR 11. szabálya az orvostechnikai eszközök szoftvereit a károk alapján osztályozza, amelyeket egy téves döntés okozhat. A diagnosztikai vagy terápiás döntésekhez információt nyújtó szoftver alapértelmezés szerint IIa. osztályú, IIb. osztályú, ha ilyen döntések súlyos romlást vagy műtétet okozhatnak, és III. osztályú, ha halált vagy visszafordíthatatlan romlást okozhatnak. A monitorozó szoftver IIa. osztályú, vagy létfontosságú paraméterek esetén IIb. osztályú.
| Szoftver rendeltetése… | MDR osztály |
|---|---|
| információ nyújtása diagnosztikai vagy terápiás célú döntések meghozatalához (az alapértelmezett) | IIa |
| …ahol ilyen döntések halált vagy az egészség visszafordíthatatlan romlását okozhatják | III |
| …ahol ilyen döntések az egészség súlyos romlását vagy sebészeti beavatkozást okozhatnak | IIb |
| élettani folyamatok monitorozása (az alapértelmezett) | IIa |
| …élettani paraméterek monitorozása, ahol eltérések azonnali veszélyt jelenthetnek a betegre | IIb |
| bármi más (olyan szoftver, amely eszköz, de nem tartozik a fentiek egyikébe sem) | I |
A 11. szabály a korábbi I. osztályú szoftverek nagy részét IIa vagy magasabb osztályba sorolta, ami a fő oka annak, hogy az MDR jelentős változást hozott a digitális egészségügyben. Az MDCG 2019-11 és az IMDRF kockázati keretrendszer (az információ jelentősége × egészségügyi helyzet állapota) segítenek a határesetek elhelyezésében. Az olyan szoftverek, amelyek hardvereszközt vezérelnek vagy befolyásolnak, az adott eszköz osztályát veszik át (a végrehajtási szabályok 3.3. szabálya).
Következmények osztályonként: az I. osztály önbevallásos, műszaki dokumentációval és regisztrációval, bejelentett szervezet nélkül (kivéve Im, Is, Ir); a IIa osztály bejelentett szervezet általi értékelést igényel a minőségbiztosítási rendszerről és a műszaki dokumentáció mintájáról; a IIb osztály ugyanezt, több dokumentáció-ellenőrzéssel; a III. osztály teljes műszaki dokumentáció-felülvizsgálatot és, ahol releváns, szakértői panel konzultációt. Minden osztályhoz minőségirányítási rendszer, az osztálynak megfelelő klinikai értékelés, felelős személy a szabályozási megfelelőségért, UDI, regisztráció az EUDAMED-ban, piacfelügyelet és riasztási rendszer szükséges.
3. lépés: az IEC 62304 szoftver biztonsági osztálya
Az IEC 62304 szoftverbiztonsági osztály a külső kockázatkezelés utáni legrosszabb károk alapján osztályozza az orvostechnikai eszközök szoftvereit: A. osztályú, ha nem lehetséges sérülés, B. osztályú, ha nem súlyos sérülés lehetséges, C. osztályú, ha halál vagy súlyos sérülés lehetséges. Az osztály meghatározza, hogy a szoftver életciklusához mennyi tervezésre, ellenőrzésre és dokumentációra van szükség.
Az IEC 62304 (2006, módosítva 2015) az orvostechnikai eszközök szoftver életciklus-folyamataira vonatkozó harmonizált szabvány. Biztonsági osztálya abból a legrosszabb veszélyhelyzetből származik, amelyhez a szoftver hozzájárulhat, miután figyelembe vették a szoftveren kívüli kockázatcsökkentő intézkedéseket:
| Osztály | Veszélyhelyzet eredményezhet… | Az életciklus mit igényel |
|---|---|---|
| A | semmilyen sérülést vagy egészségkárosodást | Szoftverfejlesztési terv, követelmények, kiadás; problémamegoldás; konfigurációkezelés |
| B | nem súlyos sérülést | A: plusz építészeti tervezés, integrációs és rendszeres tesztek igazolása, dokumentált egység-ellenőrzés |
| C | halált vagy súlyos sérülést | B: plusz részletes tervezés minden egységhez, további építészeti szegregáció, szigorúbb ellenőrzés |
Az osztályokat szoftverrendszerenként rendelik hozzá, és szoftverelemekre is bontható, így csak a kockázatos részekre vonatkozik a C osztály szigorúsága; a szabvány magyarázza az ehhez szükséges szegregációs érvelést. Az ISO 14971 (kockázatkezelés) adja a besorolás alapját; az IEC 82304-1 termékszintű követelményeket ad az általános célú platformokon (telefonok, felhő) futó egészségügyi szoftverekre.
Hogyan viszonyulnak egymáshoz
Az MDR kockázati osztálya és az IEC 62304 biztonsági osztálya független: az MDR osztály (I-től III-ig) határozza meg a szabályozási utat és a bejelentett szervezet bevonását, míg az IEC 62304 osztály (A-tól C-ig) határozza meg a mérnöki folyamat szigorúságát. Egy IIa. osztályú alkalmazás lehet 62304 B. vagy C. osztályú attól függően, hogy egy téves kimenetel milyen kárt okozhat.
Az MDR osztály a szabályozási útvonalról szól; az IEC 62304 osztály a mérnöki folyamatról. Egy 11. szabály szerinti IIa osztályú alkalmazás lehet IEC 62304 B osztályú (téves információ nem súlyos késést okozhat az ellátásban), vagy C osztályú (ha egy téves dózisjavaslat halálos lehet). Egy I. osztályú eszköz általában 62304 A osztályú, de nem feltétlenül. A bejelentett szervezetek elvárják, hogy a műszaki dokumentáció tartalmazza a 62304 osztályt annak indoklásával, az életciklus dokumentumait ezen a szinten, és a kockázatkezelési fájlhoz való kapcsolódást. A kiberbiztonságot (MDCG 2019-16, IEC 81001-5-1) együtt értékelik.
Kidolgozott példa
Kidolgozott példa szoftverre orvostechnikai eszközként (SaMD): egy tünetkövető alkalmazás, amely naplózza, megjeleníti és megosztja a tüneteket, nem minősül orvostechnikai eszköznek. Ha hozzáadnak egy olyan funkciót, amely a tüneteket egy validált skála alapján pontozza, és jelzi a felhasználónak, mikor forduljon orvoshoz, az eszközzé teszi, alapértelmezés szerint MDR 11. szabály IIa. osztályú, IEC 62304 B. osztályú, vagy szív-érrendszeri használati esetekben C. osztályú.
Egy tünetkövető alkalmazás, amely lehetővé teszi a felhasználók számára a tünetek rögzítését, a trendek megtekintését és orvosukkal való megosztását: nem eszköz (tárolás, megjelenítés, kommunikáció). Ugyanez az alkalmazás hozzáad egy olyan funkciót, amely az rögzített tüneteket egy validált skála alapján pontozza, és tájékoztatja a felhasználót, amikor az pontszám azt sugallja, hogy orvoshoz kell fordulnia: most eszköz, 11. szabály szerinti alapértelmezett IIa osztály (információ diagnosztikai döntéshez; egy téves "nem kell orvoshoz fordulni" késleltethetné a kezelést, ami súlyos, de általában nem visszafordíthatatlan, így nem IIb vagy III, hacsak a célzott állapot nem teszi azzá). IEC 62304: egy hamis megnyugtatás késleltetett ellátáshoz vezethet, nem súlyostól súlyosig terjedhet az állapottól függően, így B osztály, esetleg C osztály kardiális használati esetekben. Útvonal: ISO 13485 QMS, bejelentett szervezet, a skála klinikai értékelése, használhatósági mérnöki munka (IEC 62366-1), piacfelügyelet.
Az Egyesült Államok, röviden
Az Egyesült Államokban az FDA a szoftvereket rendeltetésük szerint szabályozza orvostechnikai eszközként, I., II. és III. osztályokkal, valamint az 510(k), De Novo és PMA utakkal. A 21. századi gyógymódokról szóló törvény (21st Century Cures Act) kizárja az adminisztratív szoftvereket, az általános wellness termékeket, az elektronikus egészségügyi nyilvántartásokat és bizonyos klinikai döntéstámogató rendszereket az eszköz státuszából. Az FDA elismeri az IEC 62304-et konszenzusos szabványként.
Az FDA ugyanazt a rendeltetés-logikát követve szabályozza a szoftvereket orvostechnikai eszközként, I., II. és III. osztályokkal, valamint 510(k), De Novo és PMA utakkal. A 21. századi gyógymódokról szóló törvény (3060. szakasz) számos kategóriát kivont az eszköz státusz alól: adminisztratív szoftverek, általános wellness, elektronikus egészségügyi nyilvántartások és olyan klinikai döntéstámogató rendszerek, amelyek lehetővé teszik a klinikus számára, hogy önállóan felülvizsgálja az ajánlás alapját (az FDA 2022-es CDS útmutatója ezt szűken értelmezi). Az FDA elismeri az IEC 62304-et konszenzusos szabványként, és 2023 óta kiberbiztonsági dokumentációt ír elő a "kibereszközökre". Az ISO 13485 2026-ban az amerikai minőségbiztosítási rendszer szabályozásának (QMSR) alapjává vált.
Az Anpheros-ban
Az Anpheros Daily tárol, megjelenít és megoszt; nem pontoz, nem értelmez és nem javasol, és a rendeltetése ezt így is rögzíti. Ezért nem minősül orvostechnikai eszköznek a 11. szabály vagy a Cures Act kizárásai alapján, és a csapat az ISO 27001 stílusú biztonságot és dokumentált szoftvergyakorlatot alkalmazza az eszközökkel kapcsolatos eljárások nélkül. Ha valaha is orvosi célt szolgáló funkciót adnának hozzá, azt a 11. szabály alapján osztályoznák, és az IEC 62304 szerint fejlesztenék ki a kiadás előtt. Lásd: Egészségügyi átláthatóság.
Ez az oldal a termék- és mérnöki csapatok szabályozási hátterét magyarázza el. Nem jogi tanácsadás; a Források alatt linkelt szövegek az irányadóak, és az Ön adatvédelmi tisztviselője, bejelentett szervezete vagy jogi tanácsadója dönt az Ön esetében. Utolsó felülvizsgálat: 2026. október.
Kapcsolódó oldalak
- Egészségügyi alkalmazás orvostechnikai eszköznek minősül? EU MDR 11. szabály
- MDR vs IVDR
- CDS Hooks magyarázata
- Egészségügyi adatszabályozási térkép
- Az EU AI Act és az egészségügyi AI
Források
- 2017/745 (MDR) rendelet, VIII. melléklet, EUR-Lex
- MDCG 2019-11: Szoftver minősítése és osztályozása
- IEC 62304:2006+AMD1:2015, Orvostechnikai eszközök szoftver életciklus-folyamatai
- IEC 82304-1:2016, Egészségügyi szoftver termékbiztonság
- FDA: Clinical Decision Support Software útmutató (2022)
- FDA: Szoftver mint orvostechnikai eszköz
Gyakori kérdések
Lehet-e egy szoftver I. osztályú az MDR szerint?
Igen, de ritkán: csak olyan orvosi célt szolgáló szoftver, amely sem diagnosztikai vagy terápiás döntéseket nem támogat, sem élettani folyamatokat nem monitoroz. A legtöbb olyan alkalmazás, amely eszköznek minősül, IIa osztályba kerül.
Szükséges-e klinikai vizsgálat egy IIa osztályú eszközhöz?
Klinikai értékelésre van szükség, amely támaszkodhat irodalomra, ekvivalenciára és teljesítményadatokra; klinikai vizsgálatra akkor van szükség, ha a meglévő bizonyítékok nem elegendőek. A diagnosztikai teljesítményt állító szoftver általában saját teljesítményvizsgálatot igényel.
Kötelező az IEC 62304?
Ez egy harmonizált szabvány, így annak betartása az MDR szoftverkövetelményeinek (I. melléklet, 17. pont) való megfelelés vélelme. Használhat más megközelítést is, de akkor bizonyítania kell az ekvivalenciát, amit a gyakorlatban senki sem tesz meg.
Mi a helyzet az AI funkciókkal?
Ugyanazok a szabályok vonatkoznak rájuk, plusz az EU AI Act: egy bejelentett szervezet által értékelt eszköz magas kockázatú AI rendszernek minősül az I. melléklet szerint, adat-, naplózási, átláthatósági és emberi felügyeleti követelményekkel, amelyeket az MDR-rel együtt értékelnek.
Próbálja ki ingyen a sandboxban
Az első FHIR-hívás 5 perc alatt. Egy HL7 FHIR R4 API, amely tartalmazza a beteg beleegyezését: próbáld ki a sandboxban, majd csatlakoztasd saját alkalmazásodat vagy klinikai rendszeredet.
Ingyenes · 30 szintetikus beteg · kártya nélkül
Az Anpheros egy olyan egészségügyi nyilvántartást épít, amelyet a beteg irányít, és megoszthat bármelyik klinikával, egy EU-ban működő HL7 FHIR R4 platformon. Ezek az útmutatók segítenek megérteni és rendszerezni az egészségügyi adataidat; nem helyettesítik az orvosodat.
Tudj meg többet az Anpherosról →