Regulació del software com a medical device: classe de risc i fases del procés

BreakfastandLearn

La classificació del software en funció de la seva classe de risc (I, IIA, IIB o III) és un dels punts centrals a definir en la fase inicial de la creació d’aquest tipus de productes sanitaris

El software com a medical device es classifica, per defecte, en risc IIA, fet que incideix en el procés regulatori d’aquests productes sanitaris i precisa la implicació d’un organisme notificat per dur a terme la seva validació i sortida al mercat. Aquesta ha estat una de les idees centrals del 10è Breakfast&Learn de la Xarxa TECSAM.

Aquesta nova cita del B&L, sota el nom Regulació del software com a medical device”, ha estat a càrrec de Dominique Monferrer, Medical Device Director d’Asphalion, qui ha traçat els passos que tot investigador o investigadora ha de dur a terme per tal d’acreditar el seu software, des de la conceptualització i disseny fins a la validació clínica i la posterior comercialització.

Un dels criteris imprescindibles a tenir en compte tant en la fase inicial de configuració del software com en el seu desenvolupament és la classe de risc (I, IIA, IIB o III) del software en funció de la usabilitat i el grau d’error potencial que podem identificar en el seu funcionament, segons ha explicat Monferrer.

Segons s’estipula als nous reglaments, concretament la norma 11 de la Medical Device Regulation, d’entrada, el software com a MD està subjecte a la classe IIA, quelcom que fa que hagi de passar per un procés de regulació de conformitat amb un organisme notificat. Els softwares que es classifiquen en IIB i III són aquells que tenen un major risc d’impacte en la gestió del pacient. D’altra banda, els que es classifiquen en classe I (es donen en casos molt puntuals) tenen un control regulatori molt lax i no han de passar per l’auditoria de l’organisme.

Malgrat aquesta classificació, l’experta en regulació d’Asphalion ha indicat que s’han de tenir en compte moltes regles i subregles aplicables en funció de la tipologia i finalitat de cada software i que s’ha de mirar cas per cas. Tot i això, ha afirmat que, en cas de dubte, sempre s’ha d’aplicar la regla i subregla més estricta que doni lloc a la classificació de risc més elevada.

Roadmap regulatori del software com a medical device, per fases

Tot software com a medical device té la potencialitat de resoldre una necessitat mèdica, però abans d’esdevenir un medical device ha de passar per un camí regulatori complex i amb moltes fases intermèdies. En aquesta sessió, tots els i les assistents han pogut conèixer de primera mà el full de ruta a seguir per donar compliment a la regulació i el marc europeu que regeix aquestes tecnologies.

D’acord amb la Dominique, el procés regulatori del software com a producte sanitari bé definit per 5 moments clau: disseny del software, definició de la classe de risc, desenvolupament del producte (validació clínica), documentació tècnica i el procediment d’avaluació de la conformitat.

Conceptualització i disseny del producte

Tal com ha explicat Monferrer, ja des de la configuració del producte, i a banda dels requisits de disseny (funcionalitat) i usabilitat (user-friendly), els fabricants de software han d’adoptar una mirada regulatòria per mostrar conformitat amb els requisits regulatoris i normes tècniques (ISO).

Així mateix, és la fase en la qual es determina la classe de risc de la tecnologia, que, tal com s’ha mencionat abans, ve marcada per les conseqüències d’un possible error del software en l’usuari. El producte també ha de complir amb especificacions quant a ciberseguretat i interoperabilitat, quelcom que obliga als desenvolupadors la implementació de plans de ciberseguretat.

En la sessió celebrada també s’ha posat la lupa sobre les principals diferències per discernir quan un software es classifica com a medical device i, per tant, ha d’atenir-se a la Medical Device Regulation, i quan es tracta d’un producte de diagnòstic in vitro, governat per la In Vitro Diagnostic Regulation.

Malgrat que tots dos tenen una finalitat mèdica i duen a terme accions complexes de dades, el software com a IVDR analitza una mostra biològica obtinguda del cos humà, incloses les donacions de sang i teixits, i la seva anàlisi ha de ser exviva.

Desenvolupament: verificació i validació clínica

A mig camí, els i les investigadores arriben al procés de desenvolupament del producte, on a banda de la verificació de la seva tecnologia, tot software ha de passar per una avaluació clínica, per tal de demostrar la seva validesa amb dades clíniques, segons ha subratllat l’experta en medical devices d’Asphalion.

Documentació tècnica i comercialització

Un cop es duen a terme aquestes últimes fases del desenvolupament, té lloc la “compilació de documentació tècnica “(pack documental que descriu el producte: què és, ús previst, mecanisme d’acció o principi operatiu a través del qual s’assoleix la finalitat, procés de disseny i desenvolupament, verificació en tots els seus nivells i validació clínica final) per tal d’enviar-se a l’organisme notificat.

Una vegada al mercat, el software serà objecte de plans de monitoratge i seguiment de postcomercialització per garantir la seva seguretat i eficiència. La regulació és un procés viu que obliga als i les investigadores a posar l’atenció en tota la normativa vigent.

Tant si et trobes en fase de desenvolupament i avaluació clínica del teu software com a medical device com si ets a un pas de llançar-lo al mercat, necessites conèixer tota la regulació que envolta aquesta tecnologia. Aquesta sessió és una oportunitat per endinsar-se en el complex camp regulatori. T’has perdut el B&L o vols tornar a veure la jornada? Ja pots accedir a la sessió gravada en vídeo.

Pots consultar el programa del dia i més informació sobre la sessió en el següent enllaç.

Deixa un comentari

L'adreça electrònica no es publicarà. Els camps necessaris estan marcats amb *