Documentazione del software FDA per i dispositivi medici

Freelance scrittore normativo Shreya Chenni fornisce una guida alla documentazione del software FDA per i dispositivi medici, compresa una ripartizione dei requisiti in base alla classificazione. 

Il dispositivo medico industry is seeing rapid technological advancement and a high rate of innovation.  Nowadays, many devices are AI-enabled, which allows early detection of disease, identification of different patterns of a biological activity, and improved diagnostic accuracy. Some examples of AI-enabled applications or devices include Arterys Application, Philips WSI and QuantX by Quantitative Insights. The software has to be verified and validated, to ensure its safety and effectiveness. 

Per qualsiasi dispositivo che contiene software che passa attraverso il Percorso 510(k), devono essere presentati documenti specifici relativi al software. In questo articolo discutiamo i documenti richiesti per Presentazioni 510(k) e capire come redigerli in base alla classificazione del vostro software.  

Come classificare il vostro software per dispositivi medici? 

Identificare il livello di preoccupazione (LoC) applicabile. Ci sono tre livelli: 

• Maggiore: un guasto o un difetto latente potrebbe causare direttamente la morte o lesioni gravi al paziente o all'operatore 

O 

 un guasto o un difetto latente potrebbe indirettamente provocare la morte o lesioni gravi del paziente o dell'operatore attraverso informazioni errate o ritardate o attraverso l'azione di un operatore sanitario.

• Moderato: un guasto o un difetto di progettazione latente potrebbe provocare direttamente lesioni minori al paziente o all'operatore

 O 

un guasto o un difetto latente potrebbe indirettamente provocare lesioni minori al paziente o all'operatore attraverso informazioni errate o ritardate o attraverso l'azione di un operatore sanitario. 

• Minore: se è improbabile che guasti o difetti di progettazione latenti causino lesioni al paziente o all'operatore. 

Utilizzare la tabella 1 e la tabella 2 del Guida FDA per il contenuto delle presentazioni pre-mercato per il software contenuto nei dispositivi medici per rispondere alle domande e determinare il tuo livello di preoccupazione per il software. 

Documenti software FDA per dispositivi medici

Quali sono i documenti da presentare?

I software di livello di preoccupazione moderato e maggiore hanno 11 documenti diversi da presentare. Mentre, il software sotto il livello di preoccupazione minore richiede sette documenti diversi. La portata e l'estensione dei dettagli in questi documenti varia in base al loro LoC.

La seguente tabella identifica i documenti richiesti per ogni livello di preoccupazione: 

Minor	Moderato	Maggiore
Livello di preoccupazione	Livello di preoccupazione	Livello di preoccupazione
Descrizione del software	Descrizione del software	Descrizione del software
Analisi dei pericoli del dispositivo	Analisi dei pericoli del dispositivo	Analisi dei pericoli del dispositivo
Specifica dei requisiti del software (SRS)	Specifica dei requisiti del software (SRS)	Specifica dei requisiti del software (SRS)
Analisi della tracciabilità	Analisi della tracciabilità	Analisi della tracciabilità
Documentazione di verifica e convalida	Documentazione di verifica e convalida	Documentazione di verifica e convalida
Storia del livello di revisione	Storia del livello di revisione	Storia del livello di revisione
————	Grafico di progettazione dell'architettura	Grafico di progettazione dell'architettura
————	Documento con le specifiche di progettazione del software	Documento con le specifiche di progettazione del software
————	Software Development Environment Description	Descrizione dell'ambiente di sviluppo software
————	Anomalie non risolte (bug o difetti)	Anomalie non risolte (bug o difetti)

 

Descrizione dei documenti 

1. Livello di preoccupazione 

Registra le risposte alle domande della tabella 1 e della tabella 2 del Guida FDA per il contenuto delle presentazioni pre-mercato per il software contenuto nei dispositivi medici  in questo documento. Includere una motivazione per il livello di preoccupazione determinato. 

2. Descrizione del software

Questo documento introduce il software del dispositivo e quindi dovrebbe fornire una panoramica completa delle caratteristiche, delle funzionalità, dell'uso previsto. Includere il linguaggio di programmazione, la piattaforma hardware, il sistema operativo e l'uso di software Off-the-Shelf se applicabile. Figure e diagrammi dovrebbero essere inclusi come appropriato. 

Nel caso in cui il dispositivo utilizzi un software Off-the-Shelf, fare riferimento al documento guida della FDA "Guida per l'uso di software off-the-shelf nei dispositivi medici." 

3. Analisi dei pericoli del dispositivo 

 A device hazard analysis is a must. All the foreseeable hazards associated with the intended use of the device (software and hardware) should be captured. The risk analysis should be conducted in compliance with ISO 14971. The hazard analysis should identify the hazard, hazardous, severity of the hazard, cause of the hazard, risk control measure and verification of the control measure. 

4. Specifica dei requisiti del software

La Specifica dei Requisiti del Software (SRS) documenta tutti i requisiti del software. Fondamentalmente, i requisiti descrivono ciò che il software dovrebbe fare. I requisiti possono essere messi in diversi gruppi come funzionali, di performance, di interfaccia utente e normativi. 

Per i LoC minori l'SRS può essere un riassunto dei requisiti funzionali, tuttavia per quelli moderati e maggiori i requisiti devono essere dettagliati e tipicamente elencati. Assicurarsi che ogni requisito elencato abbia un ID di requisito assegnato come SRS-01, SRS-02 e così via. 

Ecco alcuni esempi di SRS: 

Requisiti hardware: Includere i requisiti su -  

• microprocessori 
• dispositivi di memoria
• sensori 
• fonti di energia 
• caratteristiche di sicurezza
• comunicazioni

Requisiti di programmazione: Includere i requisiti di dimensione del programma, le restrizioni e così via 

Requisiti di interfaccia: Includono i requisiti che descrivono la comunicazione tra il software e i dispositivi hardware come stampanti, monitor. Altri requisiti come il sistema operativo con cui il software è compatibile e così via. 

Software Performance and Functional Requirements Software performance and functional requirements include algorithms or control characteristics for therapy, diagnosis, monitoring, alarms, analysis, and interpretation with full text references or supporting clinical data, if necessary. 

Le prestazioni del software e i requisiti funzionali possono anche includere:

• Limitazioni del dispositivo dovute al software 
• Test e verifiche interne del software
• Gestione degli errori e degli interrupt 
• Caratteristiche di rilevamento, tolleranza e recupero dei guasti 12 Contiene raccomandazioni non vincolanti 
• Requisiti di sicurezza
• Requisiti di tempo e di memoria 
• Identificazione del software off-the-shelf, se appropriato. 

5. Grafico di progettazione dell'architettura

 Questo documento presenta chiaramente la relazione, il flusso di dati e l'interazione tra i principali componenti o blocchi funzionali del software. Questo è solitamente rappresentato sotto forma di diagramma di flusso, diagrammi a blocchi e altre forme a seconda dei casi. Per il software di livello moderato e maggiore, il diagramma di progettazione può includere diagrammi di stato. 

6. Specifiche di progettazione del software (SDS)

L'attuazione dei requisiti è dettagliata in questo documento. Ogni SDS deve essere numerata, ad esempio SDS-01, come l'SRS. Ogni requisito incluso nell'SRS dovrebbe avere una corrispondente specifica di progettazione. Tuttavia, è anche possibile che una singola specifica di progettazione possa corrispondere a un gruppo di requisiti. 

7. Analisi della tracciabilità

Questo documento collega i requisiti, le specifiche di progettazione, i pericoli e i test V&V. La matrice di tracciabilità può essere redatta come segue, i dettagli possono essere aggiunti come appropriato: 

Necessità dell'utente (opzionale)	SRS	SDS	Pericoli	Casi di test V&V
UND-001	SRS-001 SRS-002	SDS-001	Haz-001	TC-001
UND-002	SRS-002	SDS-001 SDS-002	Haz-002	TC-002 TC-004

 

8. Descrizione dell'ambiente di sviluppo del software (SDED)

I software di livello moderato e maggiore sono tenuti a presentare un SDED che descrive il piano del ciclo di vita del software, la manutenzione e le attività del software. Il livello di dettaglio differisce per Moderato e Maggiore. Fare riferimento alla EN 62304 Tabella 1: Tabella A.1 - Riassunto dei requisiti per classe di sicurezza del software. Questo può essere usato per identificare gli elementi da includere e le attività che devono essere documentate per la loro classe. Le tre classi A, B e C si allineano al livello di preoccupazione della FDA.  

9. Documentazione di verifica e convalida

LoC minore: Documentare i test a livello di dispositivo e i test di integrazione (se applicabile). Assicurarsi che i casi di test abbiano un criterio di accettazione e un riassunto dei risultati dei test. 

LoC moderato: Elenco riassuntivo documentato delle attività di convalida e verifica e dei loro risultati. Includere i criteri di accettazione. Assicurarsi che l'analisi della tracciabilità faccia riferimento agli ID dei casi di prova. 

Major LoC: Oltre alle informazioni di cui sopra (Moderate LoC), dovrebbe essere documentata la descrizione di qualsiasi test fallito e i cambiamenti fatti in risposta a questi. 

10. Storia del livello di revisione

Documentare le principali modifiche al software assicurandosi che l'ultima riga/inserimento sia l'ultima versione del software. Identificare il numero di versione, la data e descrivere i cambiamenti rispetto alla versione precedente. 

11. Anomalie irrisolte 

Documentare i bug irrisolti esistenti nel software in fase di rilascio. Catturare quanto segue per ogni bug: 

• Il problema
• Impatto sulle prestazioni del dispositivo 
• Tempistiche previste per correggere questi bug (se applicabile) 

The above eleven documents cover the entire documentation necessary for the device software. Additionally, FDA requires Cybersecurity Documentation such as cybersecurity plan, risk management and V&V tests and their results. For more information on this FDA guidelines on Cybersecurity requirements refer to: Contenuto delle presentazioni pre-mercato per la gestione della sicurezza informatica nei dispositivi medici. 

Riferimenti: 

• Guida al contenuto delle presentazioni pre-commercializzazione per il software contenuto nei dispositivi medici

Hai bisogno di aiuto con la documentazione software FDA per i dispositivi medici? Mettiti in contatto con gli scrittori freelance di normative e Esperti di presentazione della FDA su Kolabtree.