Răspuns scurt: când un software are un scop intenționat medical (diagnostic, prevenire, monitorizare, predicție, prognostic, tratament), acesta este un dispozitiv medical conform Regulamentului UE privind Dispozitivele Medicale (MDR, 2017/745) și primește o clasă de risc: I, IIa, IIb sau III, în principal prin Regula 11 din Anexa VIII. Clasa decide dacă puteți autoevalua (doar clasa I) sau aveți nevoie de un organism notificat, cât de aprofundată trebuie să fie evaluarea clinică și cum se desfășoară supravegherea post-piață. Separat, standardul de inginerie IEC 62304 atribuie software-ului o clasă de siguranță: A (nu este posibilă nicio vătămare), B (este posibilă o vătămare non-gravă) sau C (este posibilă decesul sau o vătămare gravă), care decide cât de multă documentație, proiectare și testare necesită ciclul de viață. Cele două clasificări sunt legate, dar independente, și ambele sunt stabilite de prejudiciul pe care software-ul l-ar putea cauza, nu de complexitatea sa.
Pasul 1: Este un dispozitiv, în general?
Software-ul este considerat dispozitiv medical conform Regulamentului UE privind dispozitivele medicale (MDR) atunci când scopul său este medical: diagnostic, prevenire, monitorizare, predicție, prognostic sau tratament (Articolul 2(1)). Software-ul care doar stochează, arhivează, comunică, afișează sau caută date nu este un dispozitiv; software-ul care creează sau modifică informații medicale pentru a sprijini o decizie de diagnostic sau de tratament este, conform MDCG 2019-11.
Definiția MDR (Articolul 2(1)) se bazează pe scopul intenționat. Software-ul care stochează, arhivează, comunică, afișează sau efectuează căutări simple pe date nu este un dispozitiv (MDCG 2019-11 le menționează). Software-ul care creează sau modifică informații medicale pentru a sprijini un diagnostic sau o decizie de tratament este. Un fișier care prezintă o valoare de laborator cu intervalul de referință al laboratorului nu este; software-ul care informează un utilizator că valoarea indică o afecțiune sau recomandă o doză, este. Vezi Este o aplicație de sănătate un dispozitiv medical? pentru pasul de calificare în detaliu.
Pasul 2: Clasa de risc MDR, Regula 11
Regula 11 din MDR clasifică software-ul dispozitiv medical în funcție de prejudiciul pe care o decizie greșită l-ar putea cauza. Software-ul care oferă informații pentru decizii de diagnostic sau terapeutice este clasa IIa implicit, clasa IIb dacă astfel de decizii pot cauza o deteriorare gravă sau necesită intervenție chirurgicală, și clasa III dacă pot cauza deces sau deteriorare ireversibilă. Software-ul de monitorizare este clasa IIa, sau IIb pentru parametri vitali.
| Software destinat… | Clasa MDR |
|---|---|
| furnizării de informații utilizate pentru a lua decizii cu scop diagnostic sau terapeutic (implicit) | IIa |
| …în cazul în care astfel de decizii pot provoca decesul sau o deteriorare ireversibilă a sănătății | III |
| …în cazul în care astfel de decizii pot provoca o deteriorare gravă a sănătății sau o intervenție chirurgicală | IIb |
| monitorizării proceselor fiziologice (implicit) | IIa |
| …monitorizării parametrilor fiziologici vitali în cazul în care variațiile ar putea duce la un pericol imediat pentru pacient | IIb |
| orice altceva (software care este un dispozitiv, dar niciunul dintre cele de mai sus) | I |
Regula 11 a mutat majoritatea software-urilor anterior clasa I în IIa sau mai sus, ceea ce reprezintă motivul principal pentru care MDR a fost resimțit ca o schimbare majoră pentru sănătatea digitală. MDCG 2019-11 și cadrul de risc IMDRF (semnificația informației × starea situației sanitare) ajută la plasarea cazurilor limită. Software-ul care controlează sau influențează un dispozitiv hardware preia clasa acelui dispozitiv (Regula 3.3 din normele de punere în aplicare).
Consecințe pe clasă: clasa I este autodeclarată cu un dosar tehnic și înregistrare, fără organism notificat (cu excepția Im, Is, Ir); IIa necesită o evaluare de către un organism notificat a sistemului de calitate și un eșantion de documentație tehnică; IIb același lucru, cu o examinare mai atentă a documentației; III o revizuire completă a documentației tehnice și, acolo unde este cazul, consultarea unui panel de experți. Toate clasele necesită un sistem de management al calității, o evaluare clinică proporțională cu clasa, o persoană responsabilă de conformitatea cu reglementările, UDI, înregistrare în EUDAMED, supraveghere post-piață și vigilență.
Pasul 3: Clasa de siguranță a software-ului IEC 62304
Clasa de siguranță a software-ului IEC 62304 evaluează software-ul dispozitiv medical în funcție de cel mai grav prejudiciu la care ar putea contribui, după controalele de risc externe: clasa A atunci când nu este posibil niciun prejudiciu, clasa B atunci când este posibil un prejudiciu non-grav, clasa C atunci când este posibil decesul sau un prejudiciu grav. Clasa determină cât de riguros trebuie să fie procesul de proiectare, verificare și documentare pe parcursul ciclului de viață al software-ului.
IEC 62304 (2006, modificat 2015) este standardul armonizat pentru procesele ciclului de viață al software-ului dispozitivelor medicale. Clasa sa de siguranță provine din cea mai gravă situație periculoasă la care software-ul poate contribui, după luarea în considerare a măsurilor de control al riscurilor externe software-ului:
| Clasa | Situația periculoasă ar putea duce la… | Ciclul de viață necesită… |
|---|---|---|
| A | nicio vătămare sau deteriorare a sănătății | Plan de dezvoltare software, cerințe, lansare; rezolvarea problemelor; managementul configurației |
| B | vătămare non-gravă | A: plus proiectare arhitecturală, verificare a integrării și teste de sistem, verificare documentată a unității |
| C | deces sau vătămare gravă | B: plus proiectare detaliată pentru fiecare unitate, segregare arhitecturală suplimentară, verificare mai riguroasă |
Clasele sunt atribuite per sistem software și pot fi atribuite per element software după descompunere, astfel încât doar părțile riscante să necesite rigoarea clasei C; standardul explică argumentul de segregare necesar pentru aceasta. ISO 14971 (managementul riscurilor) contribuie la clasificare; IEC 82304-1 adaugă cerințe la nivel de produs pentru software-ul de sănătate care rulează pe platforme de uz general (telefoane, cloud).
Cum interacționează cele două
Clasa de risc MDR și clasa de siguranță IEC 62304 sunt independente: clasa MDR (I până la III) decide calea de reglementare și implicarea organismului notificat, în timp ce clasa IEC 62304 (A până la C) decide rigoarea procesului de inginerie. O aplicație de clasă IIa poate fi de clasă 62304 B sau C, în funcție de prejudiciul pe care o ieșire greșită l-ar putea cauza.
Clasa MDR se referă la ruta de reglementare; clasa IEC 62304 se referă la procesul de inginerie. O aplicație clasa IIa conform Regulii 11 ar putea fi clasa IEC 62304 B (informații greșite ar putea duce la o întârziere non-gravă în îngrijire) sau clasa C (dacă o sugestie greșită de doză ar putea fi fatală). Un dispozitiv clasa I este de obicei clasa 62304 A, dar nu neapărat. Organismele notificate se așteaptă ca fișierul tehnic să prezinte clasa 62304 cu justificarea sa, documentele ciclului de viață la acel nivel și legătura cu fișierul de management al riscurilor. Securitatea cibernetică (MDCG 2019-16, IEC 81001-5-1) este evaluată în paralel.
Exemplu practic
Un exemplu practic de SaMD: o aplicație de urmărire a simptomelor care înregistrează, afișează și partajează simptome nu este un dispozitiv medical. Adăugarea unei funcționalități care evaluează simptomele pe baza unei scale validate și informează utilizatorul când să solicite asistență medicală o transformă într-un dispozitiv, clasa IIa conform Regulii 11 MDR implicit, cu clasa IEC 62304 B, sau clasa C pentru un caz de utilizare cardiacă.
O aplicație de urmărire a simptomelor care permite utilizatorilor să înregistreze simptome, să vizualizeze tendințe și să le partajeze cu medicul lor: nu este un dispozitiv (stocare, afișare, comunicare). Aceeași aplicație adaugă o funcție care punctează simptomele înregistrate în raport cu o scală validată și informează utilizatorul când scorul sugerează că ar trebui să solicite îngrijiri: acum este un dispozitiv, clasa implicită conform Regulii 11 clasa IIa (informații pentru o decizie diagnostică; o greșeală de tipul "nu este necesară solicitarea de îngrijiri" ar putea întârzia tratamentul, grav, dar nu de obicei ireversibil, deci nu IIb sau III decât dacă afecțiunea vizată o face astfel). IEC 62304: o falsă reasigurare ar putea duce la o întârziere în îngrijire, de la non-gravă la gravă, în funcție de afecțiune, deci clasa B, posibil C pentru un caz de utilizare cardiac. Rută: ISO 13485 QMS, organism notificat, evaluare clinică a scalei, inginerie a utilizabilității (IEC 62366-1), supraveghere post-piață.
Statele Unite, pe scurt
În Statele Unite, FDA reglementează software-ul ca dispozitiv medical în funcție de utilizarea intenționată, cu clasele I, II și III și căile de aprobare 510(k), De Novo și PMA. Legea 21st Century Cures exclude software-ul administrativ, produsele de wellness general, dosarele electronice de sănătate și anumite sisteme de sprijinire a deciziilor clinice de la statutul de dispozitiv. FDA recunoaște IEC 62304 ca standard de consens.
FDA reglementează software-ul ca dispozitiv medical sub aceeași logică a scopului intenționat, cu clasele I, II și III și căile 510(k), De Novo și PMA. Legea 21st Century Cures (secțiunea 3060) a eliminat mai multe categorii din statutul de dispozitiv: software administrativ, wellness general, registre electronice de sănătate și suport decizional clinic care permite clinicianului să revizuiască independent baza recomandării (ghidul FDA din 2022 privind CDS interpretează acest lucru în mod restrictiv). FDA recunoaște IEC 62304 ca standard de consens și, începând cu 2023, necesită documentație privind securitatea cibernetică pentru "dispozitive cibernetice". ISO 13485 a devenit baza reglementării sistemului de calitate din SUA (QMSR) în 2026.
În Anpheros
Anpheros Daily stochează, afișează și partajează; nu punctează, nu interpretează și nu recomandă, iar scopul său intenționat afirmă acest lucru. Prin urmare, nu este un dispozitiv medical conform Regulii 11 sau excluderilor din Cures Act, iar echipa aplică securitatea de tip ISO 27001 și practici software documentate, fără ruta dispozitivului. Dacă s-ar adăuga vreodată o funcție cu scop medical, aceasta ar fi clasificată conform Regulii 11 și dezvoltată conform IEC 62304 înainte de lansare. Vezi Transparența sănătății.
Această pagină explică reglementările pentru echipele de produs și inginerie. Nu constituie consultanță juridică; textele legate sub Surse sunt autoritatea, iar ofițerul dvs. de protecție a datelor, organismul notificat sau consilierul decide pentru cazul dvs. Ultima revizuire: Octombrie 2026.
Pagini înrudite
- Este o aplicație de sănătate un dispozitiv medical? Regula 11 MDR UE
- MDR vs IVDR
- CDS Hooks explicat
- Hartă a reglementărilor privind datele de sănătate
- Legea UE privind IA și IA în sănătate
Surse
- Regulamentul (UE) 2017/745 (MDR), Anexa VIII, EUR-Lex
- MDCG 2019-11: Calificarea și clasificarea software-ului
- IEC 62304:2006+AMD1:2015, Procesele ciclului de viață al software-ului dispozitivelor medicale
- IEC 82304-1:2016, Siguranța produselor software de sănătate
- FDA: Ghid privind software-ul de suport decizional clinic (2022)
- FDA: Software ca dispozitiv medical
Întrebări frecvente
Poate fi software-ul clasa I conform MDR?
Da, dar rar: doar software-ul cu scop medical care nu informează deciziile diagnostice sau terapeutice și nici nu monitorizează procesele fiziologice. Majoritatea aplicațiilor care se califică drept dispozitive ajung în clasa IIa.
Un dispozitiv clasa IIa necesită studii clinice?
Necesită o evaluare clinică, care se poate baza pe literatură, echivalență și date de performanță; o investigație clinică este necesară atunci când dovezile existente sunt insuficiente. Software-ul care pretinde o performanță diagnostică necesită, de obicei, propriul studiu de performanță.
Este IEC 62304 obligatoriu?
Este un standard armonizat, deci respectarea sa este prezumția de conformitate cu cerințele MDR privind software-ul (Anexa I, 17). Puteți folosi o altă abordare, dar apoi trebuie să dovediți echivalența, ceea ce în practică nimeni nu face.
Ce se întâmplă cu funcțiile AI?
Se aplică aceleași reguli, plus Legea UE privind IA: un dispozitiv cu evaluare de către un organism notificat este un sistem AI cu risc ridicat conform Anexei I, cu cerințe privind datele, înregistrarea, transparența și supravegherea umană evaluate împreună cu MDR.
Încearcă gratuit în sandbox
Primul apel FHIR în 5 minute. Un API HL7 FHIR R4 cu consimțământul pacientului integrat: încearcă-l în sandbox, apoi conectează-ți propria aplicație sau sistemul clinicii.
Gratuit · 30 de pacienți sintetici · fără card
Anpheros construiește un dosar medical pe care pacientul îl controlează și îl poate da oricărei clinici, pe o platformă HL7 FHIR R4, cu sediul în UE. Ghidurile te ajută să-ți înțelegi și să-ți organizezi sănătatea; nu înlocuiesc medicul.
Despre Anpheros →