29/02/2024
Systems Engineering
Lo sviluppo dei Devices Medicali ed il Systems Engineering
Che cos’è un Sistema?
INCOSE*, l’International Council on Systems Engineering suggerisce la definizione di un Sistema con la frase:
"A system is an arrangement of parts or elements that together exhibit behaviour or meaning that the individual constituents do not."
(Un sistema è un insieme di parti o elementi che congiuntamente mostrano un comportamento o un significato che i singoli componenti non mostrano.)
Il concetto di Sistema è associabile ad una visione molto ampia dello stesso: se immaginiamo, per esempio, gli impianti di distribuzione dei medicali compressi e per vuoto (IDGM) per le strutture ospedaliere e di ricovero, questi sono composti da innumerevoli parti, che interagendo tra loro, offrono il servizio per il quale sono stati ingegnerizzati.
Un Sistema ha una serie di caratteristiche che lo definiscono come tale, il cui aspetto fondamentale ed imprescindibile è quello del ciclo di vita, che ne definisce le fasi (stages) dalla progettazione, all’implementazione, alla manutenzione e allo smaltimento finale. Per rimanere in tema con l’esempio, la normativa EN ISO 7396-1 proprio inerente gli impianti di distribuzione dei gas medicinali, cita proprio alcuni di questi aspetti inerenti il ciclo di vita e lo smaltimento dello stesso.
La definizione di Sistema è anche applicabile alle parti, ovvero agli elementi che costituiscono il Sistema. Difatti, secondo la letteratura, un impianto come quello dell’esempio può essere addirittura considerato un Sistema di Sistemi**, quindi un insieme di Sistemi i quali interagendo tra loro offrono una serie di capabilities che non sarebbero in grado di offrire singolarmente.
L’ingegneria dei Sistemi - Systems Engineering
Il termine Systems Engineering risale al 1940, dove veniva utilizzato per la prima volta nei Bell Laboratories negli Stati Uniti. La definizione si collega esplicitamente alla necessità di identificare le proprietà e le caratteristiche di un Sistema nella sua interezza.
Il termine si diffonde innanzitutto in ambito militare statunitense, che in quegli anni è un terreno florido e ne contribuisce all’identificazione dei processi formali, attività e discipline che saranno la base di quello che ad oggi è il Systems Engineering e di fatto anche l’ingegneria moderna.
Negli anni il Systems Engineering e le discipline che ne fanno direttamente parte, vengono adottate largamente anche al di fuori dell’ambito militare, in particolare nell’aerospazio e nell’automotive e l’applicazione delle pratiche allo sviluppo di dispositivi e sistemi medicali è senza dubbio tra gli ambiti più interessanti avendo in comune con gli altri citati molte peculiarità distintive.
Il settore dello sviluppo dei dispositivi medicali è in continuo e rapido sviluppo, i macchinari e i devices stanno diventando sempre più complessi ed integrati in Sistemi di Sistemi, e questo ambito può indubbiamente beneficiare dell’esperienza del Systems Engineering.
Sono molti i punti comuni, ad esempio, al settore aerospaziale: avere sistemi composti da innumerevoli parti, dover operare in ambienti critici per la sicurezza e in condizioni operative critiche (es. elettromagnetismo, radiazioni, ambienti difficili), fattori umani, affidabilità, costi elevati, materiali speciali. Essere in un contesto in cui il prodotto può impattare direttamente sulla sicurezza di un paziente obbliga le aziende produttrici di sistemi medicali a tenere costantemente in considerazione le regolamentazioni ed obbliga ad applicare processi formali di risk management che devono obbligatoriamente essere eccellenti.
Lo sviluppo dei dispositivi medici è tutt’altro che semplice: a causa degli standard rigorosi e delle complessità intrinseche dello sviluppo dell’hardware e del software, il creare dispositivi è una vera e propria sfida. Inoltre la dimostrazione di conformità agli standard e la valutazione da parte dei Comitati Etici e clinica negli ambiti Sanitari, sono attività dispendiose, in termini sia economici che temporali.
Queste attività ed i processi a loro correlati sono assolutamente necessari per evitare problemi legali e di qualità del prodotto, così come di evitare sanzioni e lancio di prodotti stessi sul mercato in ritardo (sia per la pianificazione iniziale desiderata che rispetto la competizione) così come, per ultimo ma non meno importante, per evitare la “brand erosion”, ovvero l’associazione tra prodotto non riuscito, non conforme o persino dannoso e nome dell’Azienda produttrice.
Solo le aziende che riescono a tenere il passo con la giusta agilità possono ottenere un vantaggio maggiore rispetto la competizione.
Gli Standard ed il Systems Engineering
Il Systems Engineering, come insieme di discipline, si relaziona in modo diretto alla normativa di riferimento ISO 15288 (Systems and software engineering — System life cycle processes), che insieme alla ISO 29148 (Systems and software engineering — Life cycle processes — Requirements engineering) può aiutare le Aziende che operano nell’ambito dello sviluppo di sistemi medicali, al tailoring dei processi per offrire prodotti ancora più competitivi e di qualità elevata. Infatti, per esempio, il System Engineering applica un occhio di riguardo per i processi formali di Verification and Validation, che rispettivamente assicurano che il prodotto funzioni correttamente e che sia correttamente sviluppato secondo le specifiche.
Nell’ambito del Systems Engineering è comune e fondamentale l’attività di revisione degli standard che possono essere imposti (dagli enti governativi e/ o dal settore merceologico specifico), nel rispetto degli stakeholders*** che utilizzeranno il prodotto. I processi e le attività relative di Quality Assurance sono fondamentali per identificare eventuali carenze nel design ed i rischi potenziali il prima possibile nell’ambito dello sviluppo del Sistema e del prodotto, rendendo anche di fatto il più esplicite possibili all’interno di tutti i processi e ai team di sviluppo, le aspettative dei clienti, assicurando una maggiore qualità e riducendo i rischi.
Infatti una tipica attività dell’SE è quella di analizzare le necessità degli stakeholders (stakeholder needs), trasformando queste necessità in stakeholder requirements. Per assicurare il corretto processo di Quality Management, gli stakeholder needs devono essere espressi correttamente e divenire parte di un processo dove i requisiti derivati devono essere misurabili, verificabili e tracciabili in qualsiasi fase dello sviluppo ed da parte di qualsiasi attore coinvolto nello sviluppo.
Uno dei capisaldi del Systems Engineering è proprio la tracciabiltà, ovvero il concetto di riportare sempre ed in ogni fase dello sviluppo**** la relazione tra i singoli artefatti che fanno parte della filiera di ingegnerizzazione (es. architetture, design, pianificazione, test plan etc) verso l’origine, ovvero vero gli stakeholder needs, in modo da garantire sempre da una parte la soddisfazione delle richieste della parte committente e dall’altra evitare il più possibile gli errori come la sovra progettazione o sovra ingegnerizzazione, o semplicemente l’implementazione di funzionalità non richieste e non indispensabili.
I processi di sviluppo delle apparecchiature medicali sono già evidentemente molto influenzate dalle stringenti normative che obbligano le Aziende ed i team di lavoro a controlli molto rigidi, processi a volte inflessibili e dispendiosi: la ISO 15288 ha lo scopo invece di rappresentare con una visione di insieme lo sviluppo di un sistema e di un prodotto, in modo completamente trasparente rispetto agli obblighi naturali derivati dalle specifiche categorie merceologiche.
Il Systems Engineering ha dato naturale battesimo al concetto del Systems Thinking*****, ovvero il concetto di visione sistemica e di insieme che è fortemente consigliato adottare nello sviluppo dei sistemi complessi.
L’importanza di un Quality Management System (QMS)
Per rispondere nel modo corretto, rapido ed efficiente sia alle richieste normative che alla crescente necessità di collaborazione, resa ancora più evidente dalla drammatica situazione di distanziamento obbligatorio che stiamo vivendo, è sempre più indispensabile l’utilizzo di strumenti che facilitino le operazioni di condivisione e tracciamento delle operazioni durante l’intera filiera produttiva di ingegnerizzazione.
I sistemi di Quality Management System (QMS) sono nati con l’obiettivo di offrire queste capabilities essenziali proprio per adottare un approccio di tipo risk-based, che vada oltre la fase di ingegnerizzazione e sviluppo, ma che sia anche in grado di offrire la sorveglianza necessaria nel post market come piano di safety.
Un sistema QMS conforme alla normativa ISO 13485 è considerato valido quando è in grado di gestire tutte le fasi del ciclo di vita di un sistema, includendo:
- la gestione dei requisiti;
- il risk management;
- la pianificazione;
- la gestione delle forniture (outsourcing);
- il design;
- lo sviluppo del software;
- la verifica e validazione;
- la tracciabilità;
- la reportistica;
- la generazione (automatica) della documentazione di progetto;
- la generazione automatica (ma modificabile da operatore) della documentazione per gli enti certificatori e/o per i Comitati Etici.
Conclusioni
L’applicare modifiche di qualsiasi natura ai processi esistenti è sempre un’attività molto delicata, innanzitutto perchè è indispensabile mantenere la continuità operativa dei gruppi di lavoro e non avere impatti (negativi) sul business. Di fatto è impensabile bloccare interi team di lavoro nella speranza che gli improvement applicati possano essere accettati e “digeriti” senza impatti negativi.
Così come l’introduzione di nuovi strumenti, nella fattispecie di governo come i QMS, richiedono molta attenzione. Nonostante la maggior parte di questi sistemi siano del tutto simili a strumenti che utilizziamo giornalmente (grazie al continuo studio da parte dei Vendor sull’usabilità e alle similitudini che questi possono avere) si tratta in ogni caso di cambiamenti che richiedono un effort da parte di chi poi quegli strumenti li andrà ad utilizzare.
Questi sono evidentemente i motivi che rendono impensabile ed inutilmente rischioso attuare una “tabula rasa” ed imporre strumenti e processi a team già consolidati.
L’approccio corretto è senza dubbio di tipo incrementale “agile”, ovvero
1. definizione delle necessità e proposizione;
2. implementazione delle proposizione;
3. rilascio e training verso i team di lavoro.
Queste tre attività fondamentali, applicabili sia ai processi che agli strumenti, possono essere ripetute nel tempo fino al raggiungimento della personalizzazione ottimale e certamente garantiscono l’accettazione da parte dei membri dei team di lavoro.
Anche la personalizzazione è indispensabile: così come adottare un nuovo strumento richiede sempre un grado di configurazione, anche gli standard che prevedono processi ed attività devono essere modellati e adeguati, tenendo sempre in mente gli obiettivi, che possono essere riassunti con le caratteristiche quali:
- utili;
- adottabili;
- adattabili;
- compliant;
- e collaborativi.
_______________________________________
* https://www.incose.org : International Council on Systems Engineering è un'organizzazione associativa senza fini di lucro, attiva nella definizione e diffusione delle pratiche legate alla ingegnerizzazione dei sistemi a livello internazionale. INCOSE ha circa 18000 membri tra cui membri singoli, aziende e studenti.
** System of Systems - SoS - https://www.incose.org/products-and-publications/sos-primer
*** Per stakeholder si intende non solamente gli utenti finali, ma chiunque possa essere coinvolto nell’uso o ancor prima nella concettualizzazione iniziale di un sistema o di un prodotto o nella richiesta di creazione di un sistema (es. il committente).
**** Fino al termine della vita del sistema o del prodotto, quindi durante le attività di dismissione.
***** Systems Thinking https://thesystemsthinker.com/introduction-to-systems-thinking/ https://thesystemsthinker.com/systems-thinking-what-why-when-where-and-how/
tecnologici: Partner
metodologico: