Software-ul ca dispozitiv medical: definiție și domeniul de aplicare al reglementărilor
Publicat: 2019-09-06În ultimii 40 de ani, numărul de inovații tehnologice atât în interiorul, cât și în jurul dispozitivelor medicale a crescut dramatic. În special, ultimii 20 de ani au fost martorii unei accelerari a sectorului, datorită Internetului obiectelor și creșterii altor părți corespunzătoare, cum ar fi conectivitatea wireless, cloud computing și AI etc. Aceste progrese au transformat procesele de asistență medicală.
Chiar și după 20 de ani, aceste tehnologii de vârf continuă să genereze o schimbare seismică în procesul de administrare și livrare a asistenței medicale.
Și acum, aplicațiile mobile s-au infiltrat și au devenit o parte importantă a acestor scopuri medicale și non-medicale foarte solicitate, bazate pe tehnologie.
Aceste aplicații sau software care sunt un dispozitiv medical în sine – dimensiunea pieței Software ca dispozitiv medical au crescut pentru a deveni o parte inerentă a vieții utilizatorilor. Aplicațiile SaMD nu se limitează doar la diagnostic, ci și-au făcut loc și în procesul de monitorizare și tratament. De fapt, SaMD este cea care a dus la evoluția asistenței medicale 1.0 la asistența medicală 3.0 .
Având în vedere includerea tot mai mare a SaMD în asistența medicală de zi cu zi, forumul internațional de reglementare a dispozitivelor medicale (IMDRF), al cărui membru FDA din SUA este membru, a descris în detaliu conceptul și categoriile de risc SaMD pentru ca industria de dezvoltare a aplicațiilor medicale să le urmeze. Software-ul FDA ca dispozitiv medical a dezvoltat și clarificat politici bazate pe risc pentru o mai bună comunicare a cerințelor și și-a aliniat abordarea de reglementare cu natura în evoluție a dispozitivelor digitale.
* SaMD nu este singura conformitate pe care părțile interesate din industria sănătății ar trebui să o urmeze – antreprenorii aplicațiilor mHealth și producătorii de dispozitive. Există și alte conformități, cum ar fi FDA, HIPAA, HL7 și FCPA. Am atins aceste conformități în detaliu în Ghidul nostru În acest articol, vom arunca puțină lumină asupra SaMD, software-ul ca reglementare pentru dispozitive medicale și tipurile de aplicații mHealth și alte tipuri de software medical care sunt clasificate ca software ca dispozitiv medical.
Cuprins
- Ce este software-ul ca dispozitiv medical?
- Cum să știi dacă aplicația ta mobilă este SaMD?
- Factori de luat în considerare pentru caracterizarea SaMD
- Care sunt exemplele de software ca dispozitiv medical?
- Cum clasificați software-ul ca dispozitiv medical?
- Ce pot face producătorii SaMD pentru a asigura reglementările?
- Concluzie
- Întrebări frecvente despre SaMD
Ce este software-ul ca dispozitiv medical?
Terminologia – Software ca dispozitiv medical înseamnă orice software care este destinat utilizării pentru unul sau mai multe scopuri medicale și care îndeplinește aceste scopuri fără a fi integrat într-un dispozitiv medical hardware.
Iată cum definește IMDRAF SaMD –
„Termenul „Software ca dispozitiv medical” (SaMD) este definit ca software destinat a fi utilizat în unul sau mai multe scopuri medicale care îndeplinesc aceste scopuri fără a face parte dintr-un dispozitiv medical hardware.”
Cum să știi dacă aplicația ta mobilă este un SaMD?
- SaMD este un dispozitiv medical și include unele dispozitive medicale de diagnostic in vitro (IVD).
- Este capabil să ruleze pe platforme de calcul de uz general (non-medicale).
- Software -ul nu îndeplinește definiția SaMD dacă scopul său este de a conduce dispozitive medicale hardware .
- Poate fi utilizat cu alte produse, cum ar fi dispozitivele medicale.
- Poate fi interfațat cu alte dispozitive medicale, inclusiv cu dispozitive medicale hardware și alte software-uri SaMD, precum și cu software de uz general.
Factori de luat în considerare pentru caracterizarea SaMD
Există două moduri prin care SaMD-urile sunt caracterizate:
Informații furnizate de SaMD
- Pentru a diagnostica sau trata pacienții
- Pentru a informa managementul clinic
- Pentru a conduce managementul clinic
Starea de sănătate
- Condiție critică
- Stare grava
- Stare negravă
Pe baza acestor caracterizări, SaMD-urile sunt împărțite în patru categorii.
Care sunt exemplele de software ca dispozitiv medical?
- Software-ul ca dispozitiv medical poate fi interfațat cu alte gadget-uri medicale, inclusiv gadget-uri medicale hardware și alte software ca dispozitiv clinic, de asemenea, ca software de utilizare generală. Software-ul care oferă limite devine intrarea pentru un echipament hardware diferit sau alt SaMD. De exemplu, software-ul ca exemplu de dispozitiv medical poate fi un software de planificare a terapiei care furnizează date utilizate într-un accelerator liniar este SaMD.
- De exemplu, software-ul care este așteptat pentru analiza unei stări utilizând accelerometrul tri-axial care funcționează pe procesorul instalat pe o cameră digitală de consum este văzut ca software ca Dispozitiv medical.
- Software-ul care este conectat la un dispozitiv hardware medical, dar care nu este cerut de acel dispozitiv pentru a-și îndeplini scopul medical, este Software ca dispozitiv medical și nu un accesoriu al dispozitivului medical.
- Software-ul SMD poate rula pe platforme de calcul cu scop general (adică motiv non-clinic). Aceste software care rulează pe aceste platforme de calcul de uz general ar putea fi situate într-un gadget medical hardware.
Exemple înțelepte de categorie de SaMD
Categoria IV:
- SaMD care efectuează analize de diagnosticare a imaginii pentru a permite deciziile de tratament atunci când pacienții suferă un accident vascular cerebral acut
- SaMD care calculează dimensiunea fractală a unei leziuni și construiesc o hartă structurală care dezvăluie diferite modele de creștere pentru a oferi diagnostic sau identificare dacă leziunea este benignă sau malignă.
- SaMD -urile combină datele din imunotestele pentru a detecta focarul de agenți patogeni mutabili care pot fi foarte comunicabili.
Categoria III:
- SaMD care folosește microfonul telefonului pentru a detecta respirația întreruptă în timpul somnului.
- Este folosit pentru furnizarea de informații făcând clic pe imagini, monitorizarea creșterii sau alte date pentru a completa alte informații pe care un furnizor de asistență medicală le utilizează pentru a diagnostica dacă o leziune a pielii este benignă sau malignă.
Categoria II:
- SaMD-uri care analizează ritmul cardiac.
- SaMD care utilizează datele din fișele de sănătate ale indivizilor pentru a prezice riscurile de boli de inimă sau accident vascular cerebral și creează strategii de prevenire.
- SaMD care integrează și analizează mai multe teste pentru a oferi recomandări de diagnostic în anumite indicații clinice.
Categoria I:
- Dispozitive medicale software care adună date din jurnalele de simptome pentru a furniza informații pentru a evalua apariția unui episod de astm.
- Software Dispozitive medicale care analizează imagini, mișcarea ochiului pentru ghidarea următoarei acțiuni de diagnostic pentru astigmatism.
- Software- uri care stochează informații istorice despre tensiunea arterială pentru ca furnizorii de servicii medicale să le examineze.
- Software- uri care utilizează date despre sensibilitatea auzului, vorbirea în zgomot și le solicită utilizatorilor să răspundă la chestionare despre situațiile comune de ascultare pentru autoevaluarea pierderii auzului.
Cum clasificați software-ul ca dispozitiv medical?
Noul EU MDR (Regulamentul Uniunii Europene privind dispozitivele medicale) oferă definiții, reguli, clasificări și necesități procedurale pentru standardele software pentru dispozitivele medicale.
Anexa VIII MDR a UE vorbește despre diverse programe software ca reguli de clasificare a dispozitivelor medicale.
Regula 11 din anexa VIII se referă la clasificarea software-ului și se referă în mod specific la clasificarea software-ului utilizat singur sau în combinație cu dispozitive medicale.
Software-ul planificat pentru a furniza date care sunt utilizate pentru a face alegeri în ceea ce privește diagnosticul sau scopurile terapeutice este clasificat ca Clasa IIa, în afară de cazul în care astfel de alegeri au un efect care poate cauza moartea sau o deteriorare ireversibilă a sănătății unei persoane. În astfel de cazuri, este în clasa a III-a sau o deteriorare gravă a stării de sănătate a unei persoane sau o intervenție chirurgicală, caz în care este clasificată ca clasa IIb.
Software-ul care se așteaptă să monitorizeze procesele fiziologice este delegat ca Clasa IIa, cu excepția cazului în care este propus pentru observarea parametrilor fiziologici esențiali, unde natura varietăților acelor parametri este de așa natură încât ar putea aduce o amenințare imediată pentru pacient, caz în care este numită Clasa IIb. Toate celelalte programe software rămase sunt delegate ca Clasa I.
De exemplu, software-ul folosit pentru a monitoriza ritmul cardiac sau alți parametri fiziologici în timpul unui control de rutină este delegat ca Clasa IIa. Dacă, din întâmplare, monitorizarea se concentrează pe parametrii fiziologici imperativi și acolo unde acești parametri ar putea aduce un pericol imediat pentru pacient, clasificarea este ridicată la Clasa IIb.
Ce pot face producătorii SaMD pentru a asigura reglementările?
Companiile SaMD ar trebui să aibă un sistem de management al calității bun încorporat în procesul de dezvoltare pentru a asigura conformitatea cu orice reglementare. Platforma QMS aleasă ar trebui să fie capabilă să respecte cerințele de reglementare, cum ar fi FDA 21 CFR Part 820 și ISO 13485:2016.
Orice pas greșit în direcție poate duce la consecințe grave, interzicerea aplicației dvs. fiind doar punctul de basculanță. Luând în considerare importanța crucială, se recomandă să vă asociați cu o companie personalizată de dezvoltare de software de asistență medicală, care lucrează alături de medici care înțeleg aceste reglementări și conformități în întregime.
Concluzie
Companiile de dezvoltare a aplicațiilor de asistență medicală din SUA care dezvoltă în prezent software pentru a fi utilizat în legătură cu dispozitivele medicale sau ca dispozitiv medical de sine stătător ar trebui să fie conștiente de aceste modificări și să se asigure că implementează măsurile pentru a se asigura că software-ul lor este în conformitate cu noul regim.
Întrebări frecvente despre SaMD
Î. Care sunt exemplele de software care nu sunt SaMD ?
- Aplicații de care dispozitivele medicale hardware au nevoie pentru a-și îndeplini rolul.
- Aplicații care depind de datele dispozitivului medical.
- Aplicații care permit comunicarea și simplificarea fluxului de lucru clinic, cum ar fi cele pentru programarea vizitelor, apelurilor video sau vocale etc.
Exemplele de aplicații nu se limitează la acestea. Există o serie de alte tipuri de aplicații care nu se încadrează în definiția SaMD-urilor.
Î. Ce poate face de fapt software-ul ca dispozitiv medical?
Aplicațiile SaMD sunt cele care acționează ca o aplicație de sănătate de sine stătătoare, care oferă utilizatorilor o perspectivă asupra sănătății lor fizice prin diagnosticarea, procesarea cu raze X sau calcularea dozelor de insulină.
Î. Ce este IEC 62304?
IEC 62304 este un standard care specifică cerințele ciclului de viață necesare pentru crearea de software ca dispozitiv medical și software în cadrul dispozitivelor medicale. Când este utilizat împreună cu ISO 13485, oferă un cadru important pentru proiectarea și întreținerea în siguranță a software-ului pentru dispozitive medicale.
Î. Descrieți procesul dumneavoastră QMS pentru dezvoltarea software-ului pentru dispozitive medicale
Avem propriul nostru QMS intern pentru a lucra cu clienți de dispozitive medicale și farmaceutice, pentru a ne asigura propria calitate. Nu suntem auditați de clienți, terți sau autorități de reglementare.
Etapa 1 : Inițierea proiectului: Realizați o teleconferință de lansare cu Clientul pentru:
Examinați planul proiectului și calendarul
Finalizați sursele cheie de informații
Definiți echipa de proiect
Etapa 2 : Revizuirea documentației: Evaluați și examinați toate documentele relevante, inclusiv informațiile existente despre produse, datele/planurile nonclinice și documentația de reglementare. Sursele acestor informații sunt:
Date non-clinice, corespondență de reglementare, specificații tehnice ale produsului, referințe la dispozitive predicate, revendicări ale produsului propus și intenție/indicații de utilizare etc.
Etapa 3 : Determinați calea de reglementare Folosind informațiile din secțiunea de mai sus, dezvoltați o cale de reglementare FDA care să determină dacă 510(k) sau de novo este cea mai potrivită (o strategie de reglementare PMA este mai complexă și va necesita un buget mai mare). Scopul va fi acela de a consilia clientul cu privire la abordarea optimă a FDA.