Diffusione delle APPSFigura 25 – Samsung: il progetto Simband..... 52. Figura 26 – Diapositiva...

Diffusione delle APPSnel Settore SanitarioOpportunità, rischi e necessità di regolamentazione

Studio

Realizzato con il contributo del Ministero Della Salute Dipartimento programmazione e dell’ordinamentodel Servizio Sanitario NazionaleDirezione generale dei dispositivi medici, del servizio farmaceutico e della sicurezza delle cure – ex DgfdmImpaginazione: Plan.ed srl / www.plan-ed.it

indice dei contenuti

1. Lo sviluppo delle APPS Sanitarie ................................................................................11

1.1. Premessa ......................................................................................................... 11

1.2. I fattori trainanti ............................................................................................... 12

1.3. I principali elementi di attenzione ..................................................................... 13

2. Il contesto di riferimento: le APPS sanitarie ...............................................................15

2.1. Definizione di Dispositivo Medico ..................................................................... 15

2.2. Gli obiettivi dello Studio .................................................................................... 17

3. Analisi della situazione attuale ..................................................................................19

3.1. Il quadro normativo di riferimento.................................................................... 19

3.1.1. La destinazione d’uso: significato e implicazioni .................................. 22

3.1.2. Le attuali classi di rischio (per dispositivi medici) ................................. 22

3.1.3. I concetti di Produttore e Sviluppatore ................................................. 26

3.1.4. Linee Guida Nazionali e Internazionali per la certificazione ................. 27

3.2. L’attuale processo di certificazione CE di un dispositivo medico ....................... 30

3.3. Esempi di banche dati sui dispositivi medici ..................................................... 32

3.3.1. La Banca Dati Nazionale ...................................................................... 32

3.3.2. La Banca Dati Europea – EUDAMED ..................................................... 35

3.3.3. La Banca Dati USA ................................................................................ 35

3.4. Approfondimenti sulle APPS ............................................................................. 41

3.4.1. Il processo di realizzazione ed immissione sul mercato ....................... 41

3.4.1.1. Generalità .................................................................................. 41

3.4.1.2. Il SW Development Life Cycle .................................................... 42

3.4.2. Sviluppo di APPS universali ................................................................... 45

3.4.3. I criteri di sicurezza applicabili ad una APP ........................................... 46

3.4.4. La struttura operativa di un dispositivo mobile .................................... 48

3.5. L’evoluzione delle piattaforme mobili ............................................................... 50

3.5.1. Panoramica del trend di mercato ........................................................ 50

3.5.2. Lo sviluppo di sensori: alcuni esempi ................................................... 50

3.6. Il modello di classificazione delle APPS Sanitarie .............................................. 54

3.6.1. L’approccio metodologico adottato ...................................................... 54

3.6.2. La Mappa concettuale .......................................................................... 55

3.6.3. La tassonomia proposta ....................................................................... 58

3.6.3.1.Gliaspettitecnici ....................................................................... 58

3.6.3.2.Gliaspettiregolamentari ........................................................... 60

3.6.3.3.Iprocessidiverifica,validazione,vigilanzaesorveglianza ....... 60

3.6.3.4.Gliaspettiorganizzativi ............................................................. 61

3.7. Considerazioni finali sulla situazione attuale .................................................... 62

4. Le esigenze poste alla base dello studio .....................................................................63

4.1. Destinazione d’uso del dispositivo tecnologico ................................................. 63

4.2. Validazione integrata APP – Dispositivo – Periferiche ....................................... 64

4.3. Il processo di sviluppo delle APPS Sanitarie ...................................................... 65

4.4. Le attività per la governance delle APPS Sanitarie ............................................ 66

4.5. Necessità di aggiornamento normativo ............................................................ 68

4.6. Conclusioni ........................................................................................................ 68

5. Proposte................. ...................................................................................................69

5.1. Proposta di definizione di APP Sanitaria ........................................................... 69

5.2. Proposta di classificazione del rischio ............................................................... 70

5.3. Proposta di definizione delle Procedure di test................................................. 72

5.3.1. Test funzionali....................................................................................... 73

5.3.2. Test strutturali ...................................................................................... 75

5.3.3. Test di sicurezza .................................................................................... 76

5.3.4. Test di protezione dei dati personali e sensibili .................................... 76

5.4. Proposte di carattere normativo ....................................................................... 77

6. Una ipotesi di Registro delle APPS Sanitarie ...............................................................85

6.1. Premessa 85

6.2. Obiettivi del Registro ......................................................................................... 86

6.3. Possibili sviluppi evolutivi del Registro delle APPS Sanitarie ............................. 87

6.3.1. Connessione con la Banca Dati Nazionale Dispositivi Medici ............... 87

6.3.2. Ipotesi di procedura di validazione di APPS non certificate ................. 88

6.3.2.1.Descrizionedellefasi(proposta)................................................ 88

6.3.2.2.Descrizionedeidocumentirichiesti(proposta) ................................... 89

6.3.3. Ulteriori servizi a favore dei Fabbricanti di APPS ........................................... 90

7. Appendice 1 – Definizioni ..........................................................................................91

8. Appendice 2 – Normativa di riferimento ....................................................................93

indice delle figure

Figura1–MinisterodellaSalute–Dispositivimedici-Aspettiregolatorieoperativi:Regolediclassificazioneperdispositiviattivi ............................................................................................ 25

Figura2–QualificazionedelSWcomeMedicaldevice ............................................................................. 29

Figura3–MinisterodellaSalute–Dispositivimedici-Aspettiregolatorieoperativi:Flussodelleinformazionirelativeaidispositivimedici .............................................................................. 33

Figura4–Bancadatinazionale–Interfacciadiricerca ............................................................................ 34

Figura5–FDA–ProcuctClassification–Interfacciaricerca ..................................................................... 35

Figura6–FDA–ProcuctClassification–Outputdellaricerca .................................................................. 36

Figura7–FDA–ProcuctClassification–DettagliosulDM ....................................................................... 36

Figura8–FDA–510(k)PremarketNotification–Interfacciaricerca ....................................................... 36

Figura9–FDA–510(k)PremarketNotification–Outputdellaricerca.................................................... 37

Figura10–FDA–510(k)PremarketNotification–DettagliosulDM ...................................................... 37

Figura11–FDA–PremarketApproval(PMA)–Interfacciaricerca ...........................................................37

Figura12–FDA–PremarketApproval(PMA)–Outputdellaricerca ........................................................38

Figura13–FDA–PremarketApproval(PMA)–DettagliosulDM ............................................................ 38

Figura14–FDA–EstablishmentRegistration&DeviceListing–Interfacciaricerca ................................ 38

Figura15–FDA–EstablishmentRegistration&DeviceListing–Outputdellaricerca ............................. 39

Figura16–FDA–EstablishmentRegistration&DeviceListing–Outputdellaricerca ............................. 39

Figura17–FDA–MAUDE–Interfacciaricerca ..........................................................................................39

Figura18–FDA–MAUDE–Outputdellaricerca.......................................................................................40

Figura19–FDA–MAUDE–Report............................................................................................................40

Figura20–SchemadimassimadelSWDevelopmentLifeCycle ...............................................................41

Figura21–Esemplificazionedellastrutturaoperativadiunosmartphone .............................................. 48

Figura22–Apple:unaipotesidisensore(progettoiWatch) ..................................................................... 51

Figura23–SamsungGalaxyS5,sensoreperlarilevazionedelbattitocardiaco ...................................... 52

Figura24–Schermatadirilevazionedelbattitocardiaco–SamsungGalaxyS5 ...................................... 52

Figura25–Samsung:ilprogettoSimband ................................................................................................ 52

Figura26–Diapositivasulmonitoraggiocronicodeipazienti. ................................................................. 53

Figura27–LaMappaconcettualedicaratterizzazionedelleAPPSSanitarie ........................................... 57

Tabella1–TassonomiadellefunzioniespletatedaunaAPPSanitaria ......................................................70

1. Lo sviluppo delle APPS Sanitarie

1.1. PremessaNell’ultimo decennio il panorama della comunicazione mobile (basata sull’impiego di dispositivi portatili) si è evoluto, sia in termini di tipologia di apparati (si è passati, sempre più velocemente, dai normali telefoni cellulari agli smartphone1), sia in termini di qualità e diversificazione dei servizi offerti2.

Nello stesso settore, uno dei fenomeni di maggior rilievo ha riguardato la nascita e la sempre maggiore diffusione di applicazioni software specifiche (cosiddette “APPS”) che, installate direttamente dal proprietario (utente) sul proprio dispositivo di comu-nicazione (tipicamente uno smartphone o un tablet), consentono di espanderne le funzionalità native, sfruttando al meglio le diverse numerose periferiche oggi presenti sempre più numerose sul mercato (fotocamera, memoria, schermo, accelerometro, ecc...).

Il gradimento di tali applicazioni, da parte degli utenti possessori di smartphone o tablet, ha incentivato il loro sviluppo, fino ad assumere caratteristiche di vera e pro-pria dinamica di mercato (la cosiddetta “AppEconomy”), andando ad interessare tra-sversalmente tutti i settori merceologici.

In particolare, nel settore sanitario, i processi evolutivi hanno interessato ciascun pos-sessore di smartphone in qualità di potenziale paziente, con lo sviluppo di servizi in mobilità: ciò ha dato luogo allo sviluppo di APPS nel settore sanitario (o “Health APPS”).

1 Letteralmente il termine significa telefono intelligente.2 La recente generazione delle comunicazioni mobili ha consentito lo sviluppo di applicazioni e ser-

vizi multimediali e la loro integrazione con reti satellitari per copertura globale.

12 formit - unint

1.2. I fattori trainanti Le cause poste alla base del significativo sviluppo e diffusione delle APPS Sanitarie, almeno con riferimento al nostro Paese, sono da ricercarsi essenzialmente nelle nuove esigenze che caratterizzano il rapporto medico-paziente. Tra i fattori trainanti, una particolare importanza assumono i seguenti:

• Il costante invecchiamento della popolazione – L’incremento dell’età media della popolazione porta ad una rinnovata esigenza di assistenza domiciliare (per com-prensibili problemi di mobilità), con servizi erogati anche attraverso interazioni remote (telemedicina).

• La criticità sociale ed economica – Il particolare momento di criticità che interessa il nostro Paese induce una sempre maggiore attenzione alle voci di spesa e alle possibili economie applicabili nei vari settori del sociale (tra i quali anche quello sanitario). Da questo deriva l’interesse sui possibili interventi di efficientamento del Sistema Sanitario Nazionale (SSN), da effettuarsi anche con l’impiego delle nuove tecnologie (ad esempio per una diagnosi remota).

• La percezione di miglioramento della qualità di vita – Il sistema di vita, media-mente sempre più agiato e supportato da strumenti e servizi, porta ad un notevole incremento delle aspettative anche riferite ai servizi sanitari.

• La maggiore distribuzione geografica dei pazienti – Le problematiche connesse con la residenza della popolazione, sempre più distribuita sul territorio nazionale (per motivi vari di affollamento delle aree urbane, di costi abitativi, ecc.), compor-ta la presenza di pazienti in zone spesso non facilmente raggiungibili dal medico curante.

• Il “fai da te” – Il ricorso, sempre più diffuso, a pratiche di autodiagnosi ed autome-dicazione porta ad impiegare fonti informative disparate e spesso non controllate (internet), con conseguente adozione di soluzioni di facile reperimento ed impiego (quale può essere, appunto, una APP).

Questi fattori, normalmente considerati come elementi caratterizzanti lo scenario at-tuale, portano necessariamente a considerare strategico lo sviluppo di servizi sanitari in mobilità e, in quest’ottica, strategico deve essere considerato anche lo sviluppo del-le APPS Sanitarie, purché naturalmente sia accompagnato da un insieme di requisiti, procedure e norme che garantiscano un impiego delle stesse quanto più possibile di qualità e scevra da rischi di safety per i destinatari (utenti, personale medico, operatori di settore, ecc.).

diffusione delle apps nel settore sanitario 13

1.3. I principali elementi di attenzioneLo sviluppo di APPS Sanitarie, pur con percentuali inferiori rispetto ad altre cate-gorie, è comunque in forte crescita ed ha spinto alcuni Produttori3 (ad es. Apple) ad avviare iniziative orientate alla costituzione di APP Store sanitari, specifici per il contesto in esame: questo eccezionale trend di crescita è il risultato concomitante dei fattori descritti, della diffusione e delle potenzialità commerciali delle nuove tecnolo-gie, ma anche del cambiamento dello stile di vita e delle conseguenti considerazioni, anche di carattere strategico, sopra richiamate.

Per contro, si deve rilevare che tale sviluppo evolutivo, laddove vengano ignorati o sottovalutati i necessari criteri di controllo e di regolamentazione, oltre ad essere por-tatore di evidenti opportunità e benefici, può essere fonte di criticità, sia per i pazienti che per il Personale Sanitario, considerando anche che la principale caratteristica del-le APPS Sanitarie risiede nel dispositivo tecnologico che le ospita (un apparato per comunicazioni mobili), sicuramente progettato e realizzato per funzioni diverse da quelle mediche.

Tra i principali elementi di attenzione, si ricordano:

• La numerosità delle APPS – L’assenza di requisiti e indicazioni precise, unite alla facilità di realizzazione di software da parte di chiunque, ha causato un eccesso di disponibilità di APPS Sanitarie, con conseguente oggettiva difficoltà e disorienta-mento dell’utente nella scelta della APP giusta, in grado, potenzialmente, di risol-vere le sue esigenze, specie ove l’utente non abbia specifiche competenze mediche.

• Lo scarso controllo del processo produttivo – Il processo produttivo che accom-pagna la realizzazione e la diffusione di APPS Sanitarie è essenzialmente impron-tato a caratteristiche di tipo commerciale e non sempre sostenuto da adeguate competenze specifiche nel settore (sanitario).

• L’assenza di protocolli di verifica e validazione specifici – Questo fattore, in partico-lare, si evidenzia sia con riferimento agli aspetti specificamente sanitari trattati dalle APPS in esame, sia con riferimento agli aspetti, più generali ma ugualmente impor-tanti, di sicurezza del SW prodotto (assenza di errori, riservatezza e disponibilità dei dati, ecc.).

• Le modalità di aggiornamento delle informazioni trattate – La quasi totalità di APPS sanitarie impiega informazioni di particolare delicatezza e criticità, che, in-dipendentemente dalla specifica APP, possono teoricamente essere utilizzate in un

3 Qui e nel seguito, il termine Produttore viene utilizzato per indicare il soggetto (azienda o libero professionista) che cura l’immissione di una APP sul mercato, sotto la propria diretta responsabilità.

14 formit - unint

lasso di tempo indeterminato senza protocolli ufficiali che ne assicurino la riserva-tezza, l’impiego e l’aggiornamento.

• L’utilizzo improprio (APPS e dati/risultati prodotti) – Questo aspetto deriva dai naturali (ma pericolosi) atteggiamenti di autodiagnosi e di automedicazione di tipo fai da te, spesso non supportati da consulti e pareri medici qualificati e, di conse-guenza, potenziali portatori di reali minacce per la salute degli utenti-pazienti.

• L’inadeguatezza normativa – Elemento derivante da una non adeguata regola-mentazione normativa che, anche a seguito di denunce o di rilevazione di illeciti (quando ciò sia possibile), consente, con facili stratagemmi, di eludere i requisiti di qualità, sicurezza e controllo che dovrebbero accompagnare ogni APP sanitaria durante tutto il suo ciclo di vita.

2. Il contesto di riferimento: le APPS sanitarie

In considerazione dello scenario delineato nel precedente Capitolo, sono evidenti i motivi che, in relazione alla rapida evoluzione tecnologica ed alle necessità ed ai fat-tori trainanti descritti, hanno favorito lo sviluppo di APPS per il settore sanitario ed il loro sempre più diffuso impiego da parte di cittadini e di operatori (medici, infer-mieri, farmacisti, ecc.). Grazie alla enorme diffusione ed alla facilità di impiego dei dispositivi mobili, infatti, si sta verificando un forte impulso a tutto ciò che riguarda la telemedicina, alla quale deve essere attribuito l’innegabile vantaggio di minimizzare gli spostamenti di pazienti e personale medico, rendendo più agevoli attività effettua-te a distanza (diagnosi, terapia, formazione medica, consultazione di testi scientifici, ecc.), nonostante al momento l’impianto normativo di regolazione del settore risulti inadeguato a gestire e regolamentare tale fenomeno.

Prima di procedere alla presentazione della situazione attuale, si vogliono fissare in modo non equivoco i presupposti di base sui quali viene fondato il prosieguo del pre-sente Studio, in termini di:• Definizione di Dispositivo Medico, sul quale si fonda l’attuale contesto normativo

e procedurale e a partire dal quale, in linea teorica, è necessario definire una quali-ficazione delle APPS che rientrano nel perimetro di intervento dello Studio e quali siano le principali caratteristiche che le identificano;

• Obiettivi, per definire i risultati che lo Studio si prefigge.

2.1. Definizione di Dispositivo MedicoIl D. Lgs. 24 febbraio 1997, n. 46, emendato col D. Lgs. 25.01.2010, n.37 – Recepi-mento Direttiva 2007/47/CE, in attuazione della direttiva 93/42/CEE concernente i dispositivi medici, all’art. 1 (Definizioni), al comma 2 definisce:a) dispositivo medico: qualunque strumento, apparecchio, impianto, software, sostanza o altro prodotto, utilizzato da solo o in combinazione, compreso il software destinato dal fabbricante ad essere impiegato specificamente con finalità diagnostiche o terapeutiche e

16 formit - unint

necessario al corretto funzionamento del dispositivo, destinato dal fabbricante ad essere impiegato sull’uomo a fini di diagnosi, prevenzione, controllo, terapia o attenuazione di una malattia; di diagnosi, controllo, terapia, attenuazione o compensazione di una ferita o di un handicap; di studio, sostituzione o modifica dell’anatomia o di un processo fisiologico; di intervento sul concepimento, il quale prodotto non eserciti l’azione princi-pale, nel o sul corpo umano, cui è destinato, con mezzi farmacologici o immunologici né mediante processo metabolico ma la cui funzione possa essere coadiuvata da tali mezzi; b) accessorio: prodotto che, pur non essendo un dispositivo, sia destinato in modo speci-fico dal fabbricante ad essere utilizzato con un dispositivo per consentirne l’utilizzazione prevista dal fabbricante stesso.

Pertanto è evidente che uno Studio volto a definire opportunità, rischi e necessità di regolamentazione di APPS nel settore sanitario debba, come primo passo impre-scindibile, procedere alla definizione esatta e non ambigua di cosa si intenda con il termine “APP Sanitaria”. In altre parole, l’analisi e la progettazione delle procedure tecniche e normative di regolamentazione delle APPS non può prescindere da una preliminare definizione di cosa debba rientrare nel perimetro di indagine dello Studio e con quali criteri.

Inoltre, una tale definizione deve necessariamente:• considerare le altre definizioni e tassonomie già in essere in campo medico (es.:

le definizioni di Dispositivo Medico e di Accessorio sopra richiamate), al fine di privilegiare, ove possibile, l’uso, anche semantico, di concetti e notazioni già con-solidati e diffusi;

• considerare le attuali categorie di rischio, in modo tale da privilegiare, ove possi-bile, la loro applicazione (anche parziale) nel contesto delle APPS Sanitarie, even-tualmente integrata da nuovi elementi che tengano conto delle caratteristiche tec-niche ed operative di tali applicazioni software e/o dei dispositivi mobili sui quali queste ultime vengono attivate;

• prevedere modalità di verifica e controllo specifiche per le APPS Sanitarie, cosic-ché, ove possibile, siano mantenute inalterate le procedure attuali (ad es.: quelle che operano sui dispositivi medici), garantendo la continuità operativa ed il man-tenimento delle conoscenze e competenze di tutti gli Attori coinvolti nelle attuali procedure di sorveglianza e vigilanza nel settore medico;

• tener conto delle finalità d’uso delle APPS Sanitarie, in quanto rilevanti ai fini della valutazione dei rischi associati alla salute e al benessere del cittadino, com-prendendo in ciò anche il Dispositivo Mobile (smartphone, tablet, ecc.) sul quale la APP Sanitaria opera.

In merito alla necessità di regolamentazione delle APPS Sanitarie (si noti che in meri-to a questa specifica esigenza si riscontra de facto l’accordo incondizionato di tutti gli


Attori coinvolti: Ministero della Salute, Organismi Notificati, Produttori/Fornitori, ecc.), si possono individuare due distinte scuole di pensiero, che, in sintesi, sostengo-no che la APP Sanitaria:• sia sempre assimilabile ad un Dispositivo Medico, ipotizzando quindi che il di-

spositivo mobile (smartphone, tablet, ecc.) operi quale Accessorio (in modo diret-to o tramite sensore o periferica), in linea con le definizioni sopra richiamate;

• sia assimilabile ad un Dispositivo Medico solo unitamente ed indissolubilmente al Dispositivo Mobile sul quale la stessa è attiva ed opera, ossia, in altre parole, che il concetto di dispositivo medico debba necessariamente essere applicato in solido alla APP Sanitaria ed al Dispositivo Mobile sul quale la APP stessa sta ope-rando in quel momento.

Nel prosieguo dello Studio, apparirà chiaro che, pur conformandosi per certi aspetti al concetto di Dispositivo Medico, una APP Sanitaria se ne differenzia per tutta una serie di peculiarità che rende necessaria una normativa specifica (di carattere tecnico ed organizzativo) finalizzata a regolamentare tutto il suo ciclo di vita, dalla progettazione e realizzazione, alla successiva diffusione sul mercato ed impiego.

2.2. Gli obiettivi dello StudioIl Ministero della Salute, Dipartimento della Programmazione e dell’Ordinamento del S.S.N. – Direzione Generale dei Dispositivi Medici, del Servizio Farmaceutico e della Sicurezza delle Cure (di seguito “Ministero”), con la realizzazione del presente Studio, intende delineare una linea di intervento che, a valere su un progetto di ricer-ca, possa contribuire alla riduzione ed al contenimento degli elementi di rischio deri-vanti dall’uso improprio delle APPS Sanitarie, qualificate come sottocategoria delle APPS sanitarie.

Lo Studio è finalizzato a:• presentare una analisi e una ricognizione della situazione attuale;• definire un modello tecnico-organizzativo che caratterizzi le APPS Sanitarie, illu-

strando tutti i processi connessi con la progettazione, realizzazione, verifica e vali-dazione delle stesse, prima della loro diffusione sul mercato, curando, nei limiti del possibile, anche gli aspetti connessi con la loro gestione nel tempo (manutenzione, evoluzione, ecc.).

3. Analisi della situazione attuale

3.1. Il quadro normativo di riferimentoCome già anticipato precedentemente, il campo di interesse del presente studio è rappresentato dalle APP Sanitarie, in quanto al momento, pur non costituendo di-spositivo medico, in termini di analisi del contesto4 possono essere a questo assimilate secondo quanto previsto dalla Direttiva 93/42/CE, art. 1, comma 2.a:

...qualunque strumento, apparecchio, impianto, software, sostanza o altro prodotto, uti-lizzato da solo o in combinazione, compreso il software destinato dal fabbricante ad essere impiegato specificamente con finalità diagnostiche o terapeutiche e necessario al corretto funzionamento del dispositivo, destinato dal fabbricante ad essere impiegato sull’uomo a fini di:• diagnosi, prevenzione, controllo, terapia o attenuazione di una malattia; • diagnosi, controllo, terapia, attenuazione o compensazione di una ferita o di un han-

dicap; • studio, sostituzione o modifica dell’anatomia o di un processo fisiologico; • intervento sul concepimento,il quale prodotto non eserciti l’azione principale, nel o sul corpo umano, cui è destinato, con mezzi farmacologici o immunologici né mediante processo metabolico ma la cui fun-zione possa essere coadiuvata da tali mezzi...

In accordo con la medesima direttiva, anche un accessorio può essere considerato come

...prodotto che, pur non essendo un dispositivo, sia destinato in modo specifico dal fab-bricante ad essere utilizzato con un dispositivo per consentirne l’utilizzazione prevista dal fabbricante stesso....

4 A valle della Analisi della situazione attuale, lo Studio dovrà suggerire quelle particolari integrazioni dell’impianto normativo necessarie per regolamentare in modo specifico il contesto delle APPS mediche. Pertanto, come già anticipato, il concetto di APPS medica viene qui assimilato a quello di Dispositivo medico solo per semplicità espositiva.

20 formit - unint

Più in particolare, in accordo con le modifiche introdotte dalla Direttiva 2007/47/CE ai requisiti prescritti della Direttiva 93/42/CE, una APP Sanitaria può essere assimila-ta ad un dispositivo medico attivo5, in quanto:

...Dispositivo medico dipendente, per il suo funzionamento, da una fonte di energia elet-trica o di altro tipo di energia, diversa da quella generata direttamente dal corpo umano o dalla gravità e che agisce convertendo tale energia. Un dispositivo medico destinato a trasmettere, senza modificazioni di rilievo, l’energia, le sostanze o altri elementi tra un dispositivo medico attivo e il paziente non è considerato un dispositivo medico attivo. Il software indipendente (stand-alone) è considerato un dispositivo medico attivo...

Se ne deduce che, quando specificamente destinato dal fabbricante ad essere impiega-to per una o più delle finalità mediche stabilite nella definizione di dispositivo medico di cui sopra, il software in sé è un dispositivo medico e l’inserimento esplicito della parola software nella definizione consente di prendere in considerazione la maggior parte delle APPS Sanitarie.

Ne consegue che il quadro normativo da cui partire è quello relativo ai dispositivi medici, costituito da tre direttive principali che riguardano i dispositivi medici impian-tabili attivi, i dispositivi medici in vitro ed i dispositivi medici in generale.

A livello comunitario le direttive sopra citate sono le seguenti:• Direttiva 90/385/CE del Consiglio, del 20 giugno 1990, per il ravvicinamento delle

legislazioni degli Stati Membri relative ai dispositivi medici impiantabili attivi;• Direttiva 93/42/CE del Consiglio, del 14 giugno 1993, concernente i dispositivi

medici (in genere);• Direttiva 98/79/CE del Parlamento Europeo e del Consiglio, del 27 ottobre 1998,

relativa ai dispositivi diagnostici in vitro;• Direttiva 2007/47/CE del Parlamento Europeo e del Consiglio, del 5 settembre

2007, che modifica la direttiva 90/385/CEE del Consiglio per il ravvicinamento delle legislazioni degli Stati membri relative ai dispositivi medici impiantabili attivi, la direttiva 93/42/CEE del Consiglio concernente i dispositivi medici e la direttiva 98/8/CE relativa all’immissione sul mercato dei biocidi.

A livello nazionale le suddette direttive sono state recepite ne:• D. Lgs. 14 dicembre 1992, n. 507, emendato col D. Lgs. 25.01.2010 n.37 – Rece-

pimento Direttiva 2007/47/CE – Attuazione della direttiva 90/385/CEE concer-nente il ravvicinamento delle legislazioni degli Stati membri relative ai dispositivi medici impiantabili attivi;

5 Cfr. D.lgs. n.37/2010 – Allegato IX Criteri di Classificazione – Parte I Definizioni – punto 1.4.


• D. Lgs. 24 febbraio 1997, n. 46 emendato col D. Lgs. 25.01.2010 n.37 – Recepi-mento Direttiva 2007/47/CE – Attuazione della direttiva 93/42/CEE concernente i dispositivi medici.

• D. Lgs 8 settembre 2000, n. 332, emendato col D. Lgs. 25.01.2010 n.37 – Rece-pimento Direttiva 2007/47/CE – Attuazione della direttiva 98/79/CE relativa ai dispositivi medico-diagnostici in vitro;

Con riferimento al quadro normativo sopra richiamato, si precisa che:

• La Direttiva 90/385/CE sui dispositivi medici impiantabili attivi (AIMDD) disciplina...qualsiasi dispositivo medico legato per il suo funzionamento a una fonte di ener-gia elettrica o a qualsiasi altra fonte di energia diversa da quella prodotta diret-tamente dal corpo umano o dalla gravità, destinato ad essere impiantato intera-mente o parzialmente mediante intervento chirurgico o medico nel corpo umano o mediante intervento medico in un orifizio naturale e destinato a restarvi dopo l’intervento....

• La Direttiva 98/79/CE sui dispositivi medico-diagnostici in vitro (IVDD) disciplina...qualsiasi dispositivo medico composto da un reagente, da un prodotto reattivo, da un calibratore, da un materiale di controllo, da un kit, da uno strumento, da un appa-recchio, un’attrezzatura o un sistema, utilizzato da solo o in combinazione, destinato dal fabbricante ad essere impiegato in vitro per l’esame di campioni provenienti dal corpo umano, inclusi sangue e tessuti donati, unicamente o principalmente allo sco-po di fornire informazioni su uno stato fisiologico o patologico, o su una anomalia congenita, o informazioni che consentono la determinazione della sicurezza e della compatibilità con potenziali soggetti riceventi, o che consentono il controllo delle misure terapeutiche....

• La Direttiva 93/42/CE sui dispositivi medici (MDD), infine, disciplina i disposi-tivi medici non soggetti alle precedenti direttive.

Nel prosieguo del Capitolo, per facilità espositiva, l’analisi dell’attuale quadro normativo viene limitata ai soli Dispositivi Medici (Direttiva 93/42/CE), al fine di fornire un quadro esemplificativo delle norme al momento vigenti, dal quale partire per la successiva definizione delle integrazioni specifiche suggerite per regolamentare le APPS Sanitarie.

22 formit - unint

3.1.1. La destinazione d’uso: significato e implicazioniLe Direttive precedentemente richiamate definiscono: • cosa costituisce un dispositivo medico; • come i dispositivi medici dovrebbero essere regolamentati in accordo alle diverse

classificazioni;• come i dispositivi devono essere contrassegnati per dimostrare la loro conformità.

In relazione alle considerazioni espresse, è necessario richiamare l’attenzione su un aspetto fondamentale che influenza la definizione di dispositivo medico, ossia la de-stinazione d’uso. Considerando il D. Lgs. 24 febbraio 1997, n. 46 (nel seguito “De-creto”), quale attuazione della Direttiva 93/42/CEE su i dispositivi medici, si può de-finire la Destinazione d’uso come ...l’utilizzazione alla quale è destinato il dispositivo secondo le indicazioni fornite dal fabbricante nell’etichetta, nel foglio illustrativo o nel materiale pubblicitario... (art.1, c. 2.g del Decreto).

Nel prosieguo dello Studio il concetto della destinazione d’uso dei dispositivi mo-bili (smartphone,tablet,ecc.) viene più volte richiamato (sivedaancheil§4.1)in quanto costituisce uno dei principali elementi di attenzione che è necessario regolamentare per garantire una efficace governance del fenomeno delle APPS Sanitarie. Questo aspetto, infatti, influenza notevolmente la possibilità di assimi-lare una APP Sanitaria ad un dispositivo medico, in quanto la prima è destinata ad operare su un apparato tecnologico (ildispositivomobile) che ha sicuramente una destinazione d’uso diversa da quella tipica di un dispositivo medico o di un accessorio (sivedaledefinizionial§2.1).

3.1.2. Le attuali classi di rischio (per dispositivi medici)Una volta stabilita l’appartenenza o meno di un dispositivo alla categoria medica (sul-la base del suddetto concetto di Destinazione d’uso) è necessario procedere ad una classificazione che tenga conto della valorizzazione del rischio. Nel seguito vengono richiamate le classi di rischio che, in base alla normativa vigente, sono oggi applicate ai Dispositivi Medici: la loro applicazione alle APPS Sanitarie richiede alcune integra-zioni che, in termini di proposta, sono illustrate nel prosieguo dello Studio.

L’art. 8 del Decreto recita: 1. I dispositivi sono suddivisi nelle seguenti classi: classi I, IIa, IIb e III. La classifica-

zione segue le regole di classificazione di cui all’allegato IX.


2. L’eventuale contrasto insorto tra il fabbricante e l’organismo notificato, sulla applica-zione delle regole di classificazione, può essere risolto mediante ricorso al Ministero della Salute che decide d’intesa con il Ministero dello Sviluppo Economico.

Nel dettaglio le classi sono così definite:• Classe I: dispositivi meno critici, quali la gran parte di quelli non attivi e non invasi-

vi. All’interno della classe suddetta sono individuabili anche due sottoclassi:− Classe Is: dispositivi di classe I forniti allo stato sterile;− Classe Im: dispositivi di classe I che svolgono una funzione di misura.

• Classe IIa: dispositivi a rischio medio, quali alcuni dispositivi non attivi (invasivi e non) e dispositivi attivi che interagiscono con il corpo in maniera non pericolosa.

• Classe IIb: dispositivi a rischio medio/alto, quali alcuni dispositivi non attivi (specie invasivi) e i dispositivi attivi che interagiscono con il corpo in maniera pericolosa.

• Classe III: dispositivi ad alto rischio, quali gran parte dei dispositivi impiantabili, quelli contenenti farmaci o derivati animali ed alcuni dispositivi che interagiscono sulle funzioni di organi vitali.

L’allegato IX del Decreto (Criteri di Classificazione) contiene Definizioni e Regole di applicazione necessarie per l’assegnazione della giusta classe al dispositivo medico. I principali criteri di scelta sono:• la durata di impiego;• il grado di invasività;• la destinazione e modalità d’uso;• il principio fisico di funzionamento.

In particolare, il punto II dell’Allegato IX, afferma che:2.1 l’applicazione delle regole di classificazione deve basarsi sulla destinazione dei di-

spositivi.2.2 se un dispositivo è destinato ad essere utilizzato in combinazione con un altro di-

spositivo, le regole di classificazione devono applicarsi separatamente a ciascun di-spositivo. Gli accessori sono classificati separatamente dal dispositivo con cui sono impiegati.

2.3 il software destinato a far funzionare un dispositivo o ad influenzarne l’uso rientra automaticamente nella stessa classe del dispositivo.

2.4 se un dispositivo non è destinato ad essere utilizzato esclusivamente o principalmen-te in una determinata parte del corpo, esso deve essere considerato e classificato in base all’utilizzazione più critica specificata.

2.5 se ad un dispositivo si applicano più regole, tenuto conto delle prestazioni che gli sono assegnate dal fabbricante, si applicano le regole più rigorose che portano alla classificazione più elevata.

24 formit - unint

La classificazione di rischio determina poi i requisiti di conformità (art. 11 del De-creto) e quindi il livello dei controlli normativi imposti6. Per ogni classe sono indicate delle regole specifiche:• classe I: le procedure di valutazione della conformità possono essere svolte gene-

ralmente sotto la sola responsabilità del fabbricante (autocertificazione). • classe IIa: necessita di controlli da parte di un Organismo Notificato durante la

fase di fabbricazione. • classi IIb e classe III: necessitano di controlli da parte di un Organismo Notificato

sia nella fase di progettazione sia nella fase di fabbricazione del dispositivo medico. L’immissione in commercio dei dispositivi della III classe richiede inoltre un’espli-cita autorizzazione di conformità preliminare.

Con maggior dettaglio7:1. Per i dispositivi appartenenti alla classe III, ad esclusione dei dispositivi su misura e

dei dispositivi destinati ad indagini cliniche, il fabbricante deve, ai fini dell’apposizio-ne della marcatura CE:a) seguire la procedura per la dichiarazione di conformità CE (sistema completo di

assicurazione di qualità) di cui all’allegato II, oppureb) seguire la procedura relativa alla certificazione CE di conformità del tipo di cui

all’allegato III, unitamente: 1) alla procedura relativa alla verifica CE di cui all’allegato IV, oppure 2) alla procedura relativa alla dichiarazione di conformità CE (garanzia di qualità

della produzione) di cui all’allegato V. 2. Per i dispositivi appartenenti alla classe IIa, ad esclusione dei dispositivi su misura e

dei dispositivi destinati ad indagini cliniche, il fabbricante deve, ai fini dell’apposizio-ne della marcatura CE, seguire la procedura per la dichiarazione di conformità CE di cui all’allegato VII unitamente: a) alla procedura relativa alla verifica CE di cui all’allegato IV, oppure b) alla procedura relativa alla dichiarazione di conformità CE (garanzia di qualità

della produzione) di cui all’allegato V, oppure c) alla procedura relativa alla dichiarazione di conformità CE (garanzia di qualità del

prodotto) di cui all’allegato VI.

6 Per determinare la classe di rischio di un’APP medica, oltre a quanto previsto, è necessario consi-derare anche ulteriori aspetti associati alle peculiarità proprie di una applicazione software e, in partico-lare, al fatto che una APP medica:

• opera su un Dispositivo Mobile (smartphone, tablet, ecc.) con destinazione d’uso non finalizzata al settore sanitario;• può controllare (gestire, pilotare, ecc.) una periferica connessa al dispositivo medico predetto;• può effettuare ricezione/trasmissione di dati sanitari, con diversi protocolli e conseguente necessità di protezione dei dati.7 Cfr. D. Lgs. 24 febbraio 1997, n. 46 emendato col D. lgs. 25.01.2010 n.37 – art. 11 comma 1, 2, 3,

4 e 5.


3. In sostituzione delle procedure, di cui al comma 2, il fabbricante può seguire la proce-dura prevista al comma 4, lettera a).

4. Per i dispositivi appartenenti alla classe IIb, diversi dai dispositivi su misura e dai dispositivi destinati ad indagini cliniche, il fabbricante deve seguire, ai fini dell’appo-sizione della marcatura CE: a) la procedura relativa alla dichiarazione di conformità CE (sistema completo di

garanzia di qualità) di cui all’allegato II; in tal caso non si applica il punto 4 dell’allegato II, oppure

b) la procedura relativa alla certificazione CE di cui all’allegato III unitamente: 1) alla procedura relativa alla verifica CE di cui all’allegato IV, oppure 2) alla procedura relativa alla dichiarazione di conformità CE (garanzia di qualità

della produzione) di cui all’allegato V, oppure 3) alla procedura relativa alla dichiarazione di conformità CE (garanzia di qualità

del prodotto) di cui all’allegato VI. 5. Per i dispositivi appartenenti alla classe I, ad esclusione dei dispositivi su misura e di

quelli destinati ad indagini cliniche, il fabbricante ai fini dell’apposizione della mar-catura CE, si attiene alla procedura prevista all’allegato VII e redige, prima dell’im-missione in commercio, la dichiarazione di conformità CE richiesta, inviandone copia al Ministero della salute.

Figura1–MinisterodellaSalute–Dispositivimedici-Aspettiregolatorieoperativi:Regolediclassificazioneperdispositiviattivi

26 formit - unint

Con riferimento alle APPS Sanitarie, è evidente la necessità di prevedere una integra-zione della normativa vigente e, in particolare, alle procedure di verifica CE definite negli Allegati IV (verifica CE) e VI (Dichiarazione di conformità CE) del Decreto: infatti, tali procedure prevedono che le verifiche effettuate per il rilascio della certifi-cazione CE avvengano in termini di ispezioni e testing finali dei prodotti e, nel caso di applicazioni SW, ciò non garantisce un adeguato livello di sicurezza a causa dell’im-possibilità di individuare eventuali errori sistematici8.

3.1.3. I concetti di Produttore e SviluppatoreUn ulteriore articolo del Decreto che si desidera segnalare è il comma 2.f dell’articolo 1, che prevede la definizione di Fabbricante:

...la persona fisica o giuridica responsabile della progettazione, della fabbricazione, dell’imballaggio e dell’etichettatura di un dispositivo in vista dell’immissione in com-mercio a proprio nome, indipendentemente dal fatto che queste operazioni siano eseguite da questa stessa persona o da un terzo per suo conto. Gli obblighi del presente decreto che si impongono al fabbricante valgono anche per la persona fisica o giuridica che compone, provvede all’imballaggio, tratta, rimette a nuovo, etichetta uno o più prodotti prefabbri-cati o assegna loro la destinazione di dispositivo in vista dell’immissione in commercio a proprio nome. I predetti obblighi non si applicano alla persona la quale, senza essere il fabbricante compone o adatta dispositivi già immessi in commercio in funzione della loro destinazione ad un singolo paziente....

Quanto sopra premesso, ai fini del presente Studio, si utilizzano i seguenti concetti.

• Produttore – Riferito alle APPS Sanitarie, è la Persona o l’Organizzazione che cura l’immissione della APP sul mercato a proprio nome e ne assume la piena respon-sabilità. Il Produttore coincide con la figura del Fabbricante sopra richiamata ed è obbligato al pieno rispetto della Direttiva.

• Sviluppatore – Riferito alle APPS Sanitarie, è la Persona o l’Organizzazione re-sponsabile delle attività di progettazione e sviluppo di una APP. È necessario che lo Sviluppatore conosca approfonditamente la normativa, al fine di garantirne il pieno rispetto delle prescrizioni e dei vincoli in tutte le fasi che presiedono alla

8 Si precisa che, alla data di rilascio di questa prima versione dello studio, questa specifica considerazio-ne è ancora in via di approfondimento e valutazione e deriva dal confronto tra gli allegati della normativa e quanto riportato nella presentazione IMQ-Processo certificazione SW MD. Infatti, il D. Lgs. 25.01.2010 n.37 non sembra introdurre modifiche agli allegati IV e VI che possano far considerare superati i limiti riscontrati dalla IMQ. La valutazione in corso, pertanto, è volta a verificare se i punti 3 di tali allegati, in cui si parla di procedura sistematica di valutazione dell’esperienza acquisita sui dispositivi nella fase successiva alla produzione possono essere considerati come soluzione al problema sollevato dalla IMQ.


realizzazione di una APP Sanitaria, comprensive, oltre alle operazioni finali di test e collaudo, anche delle successive fasi di gestione e manutenzione nel tempo.

3.1.4. Linee Guida Nazionali e Internazionali per la certificazioneLa certificazione dei Dispositivi Medici, in conformità ai dettami del Decreto, ri-chiede che il Fabbricante implementi e certifichi un sistema di gestione per la qualità in conformità alla norma ISO 13485 Dispositivi medici – Sistemi di gestione per la qualità – Requisiti per scopi regolamentari.

Data la continua evoluzione e diffusione delle APPS Sanitarie e considerato il loro impatto sulla salute, l’applicazione delle direttive di cui sopra non può prescindere dal contestuale riferimento anche alle linee guida in materia pubblicate oltre i confini nazionali. A livello internazionale un’indicazione in tal senso arriva dagli USA ed è rap-presentata dalle linee guida definitive sulla regolamentazione per Mobile Medical Ap-plications pubblicate dalla Food and Drug Administration (FDA) a settembre 2013.

Scopo del provvedimento è:• valutare se e quando le APPS per dispositivi mobili (Mobile APPS) devono essere

considerate dispositivi medici;• fornire agli sviluppatori di APPS Sanitarie una serie di norme su come realizzare

le applicazioni, con particolare riferimento a quelle più complesse che in caso di malfunzionamento possono causare danni ai pazienti e/o porre a rischio la loro vita, tralasciando, invece, quelle che svolgono funzioni più semplici.

La pubblicazione e l’immissione in commercio di tali APPS Sanitarie e è subordi-nata al controllo e all’approvazione della FDA, alla stessa stregua dei farmaci e dei dispositivi medici.

In quel contesto, una APP rappresenta una Mobile Medical APP quando sod-disfa la definizione di Dispositivo medico, in riferimento alla sezione 201(h) della Federal Food, Drug, and Cosmetic Act (FD&C Act):

...A device is an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:• recognized in the official National Formulary, or the United States Pharmacopoeia, or

any supplement to them,• intended for use in the diagnosis of disease or other conditions, or in the cure, mitiga-

tion, treatment, or prevention of disease, in man or other animals, or• intended to affect the structure or any function of the body of man or other animals,

and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes....

28 formit - unint

Inoltre, è necessario che la APP in esame:• venga utilizzata come accessorio per un dispositivo medico regolamentato;

oppure • trasformi una piattaforma mobile in un dispositivo medico regolamentato.

Sulla base di quanto appena affermato le linee guida della FDA distinguono le APPS nelle categorie di seguito elencate.1. APPS per dispositivi mobili che rientrano nella

categoria di dispositivi medici e sono pertanto oggetto del provvedimento di regolamentazione del FDA;

2. APPS per dispositivi mobili per le quali l’Agen-zia intende esercitare una discrezionalità applica-tiva del regolamento;

3. APPS per dispositivi mobili che NON rientrano nella classificazione di dispositivo medico (e non sono pertanto oggetto di regolamentazione).

In realtà molte delle APPS sanitarie rientrano nella categoria 3 del precedente punto elenco e non sono pertanto soggette a regolamentazione9.

Tra le restanti categorie, invece, la FDA garantisce il controllo e la certificazione delle APPS che rientrano nella categoria di dispositivo medico, ossia quelle che permet-tono di trasformare il proprio telefono in uno strumento in grado di misurare, dia-gnosticare o trattare un problema medico, e stabilisce di esercitare una discrezionalità nell’applicazione del regolamento per le APPS che presentano un rischio minore, quali ad esempio quelle relative all’aderenza o alla gestione della terapia.

Così facendo l’Agenzia tutela gli utenti finali in particolare sulla efficacia e sicurezza delle applicazioni che potrebbero essere dannose nel caso di funzionamento non corretto.

L’assegnazione di un Dispositivo (e conseguentemente di una APP Sanitaria sog-getta a regolamentazione) ad una determinata classe definisce il livello di control-li normativi necessario per garantirne sicurezza ed efficacia, oltre alla procedura di commercializzazione necessaria per ottenere l’autorizzazione da parte della FDA. In particolare, i dispositivi di:• Classe I sono considerati a basso rischio e necessitano di controlli generali:• Classe II necessitano di controlli generali e speciali;• Classe III richiedono l’autorizzazione prima dell’immissione in commercio

(pre-market approval – PMA).

9 Vedasi, ad esempio, copie elettroniche di testi e materiale medico non contenente informazioni di specifici pazienti, applicazioni utilizzate esclusivamente per accedere, registrare, tracciare suggerimenti correlati allo stato generale di salute o benessere, ma non destinate a cure, trattamenti, diagnosi, automa-zione di procedure di contabilità, gestione appuntamenti, etc.


A livello comunitario, le Linee Guida di riferimento sono quelle:• MEDDEV, introdotte dalla Comunità Europea (in particolare la MEDDEV 2.1

/ 6 – Orientamenti in materia di qualificazione e classificazione di Stand Alone Software);

• del Medical Products Agency (MPA) Svedese – Medical Information Systems – Guidance for qualification and classification of standalone software with a medical purpose.

Tutte le linee guida in materia sopra citate (MEDDEV 2.1/6, FDA e MPA svede-se) utilizzano lo stesso albero decisionale per guidare alla qualificazione del software come dispositivo medico (si veda il diagramma di Figura 2) .

ISO/IEC 2382-1

IL SW E’UN PROGRAMMAPER COMPUTER?

IL SW NON CONTIENE ISTRUZIONI O SUBROUTINES IN LINGUAGGIO DI

PROGRAMMAZIONE PARTICOLARE IL SW E’INCORPORATO

IN UN DM?SW STAND-ALONE

IL SW EFFETTUASUI DATI UN’AZIONE

DIVERSA DA (*)?

(*)- IMMAGAZZINAMENTO;- ARCHIVIAZIONE;- COMUNICAZIONE;- COMPRESSIONE SENZA PERDITA;- SEMPLICE RICERCA

L’AZIONE E’ SVOLTAA BENEFICIO DEL

SINGOLO PAZIENTE?

L’AZIONE VIENE SVOLTAPER GLI SCOPI INDICATINELLA DIRETTIVA “DM”?

AD ES., SW PER VALUTAZIONE STATISTICA DI STUDI CLINICI, EPIDEMIOLOGICI O REGISTRI

SW NON DM

SW ACCESSORIODI DM??

AD ES., SW CHE PILOTA, CONTROLLA O INFLUENZA LA

PERFORMANCE O L’UTILIZZO DI DM

AD ES., SW CHE AGISCE SU DATI PER

RIMBORSI ECONOMICI, TURNI DEL

PERSONALE, GESTIONE RISORSE O

ALTRI SCOPI NON MEDICI

NON E’ APPLICABILE LA DIRETTIVA MD

E’ APPLICABILE LA DIRETTIVA MD

NO

SI

NO

SI

SI

SI

NO

NO

SI

NO

IL SW E’ PARTEDI UN DM

NO

DESTINATO DAL FABBRICANTE AD ESSERE IMPIEGATO SPECIFICAMENTE CON FINALITA’ DIAGNOSTICHE […]

Figura2–QualificazionedelSWcomeMedicaldevice

Tale diagramma, sulla base della destinazione d’uso del software, permette di verifi-care se il SW stesso può considerarsi o meno dispositivo medico.

30 formit - unint

3.2. L’attuale processo di certificazione CE di un dispositivo medicoPer completezza di informazione, nel seguito viene illustrato il processo di certificazione CE di un dispositivo medico, nelle fasi ed attività che vengono attualmente effettuate10.1 Il fabbricante11 può scegliere uno qualsiasi dei 82 Organismi Notificati europei

purché autorizzato a rilasciare Certificazioni CE per la tipologia e la classe di dispositivo in esame.

2 Il fabbricante presenta all’Organismo Notificato una domanda di certificazione con in allegato una breve descrizione del dispositivo, la classificazione proposta, lo schema di certificazione (Allegati applicati) proposto, il fascicolo tecnico ed il manuale della qualità.

3 L’Organismo Notificato analizza la domanda di Certificazione; verifica che il pro-dotto rientri nella definizione di Dispositivo medico, in base alla destinazione d’uso, alla composizione ed al settore di applicazione; verifica la classificazione proposta e l’applicabilità dello schema di certificazione.

4 L’Organismo Notificato accetta e protocolla la domanda di Certificazione e, tra-mite una Commissione di Assegnazione, procede all’individuazione del gruppo ispettivo che svolgerà la verifica ispettiva e dei valutatori di prodotto che verifi-cheranno la documentazione.

5 Partono parallelamente le attività di verifica della documentazione, con l’even-tuale svolgimento di prove sul prodotto, e quelle di verifica ispettiva (successivi passi da 6 a 12)

10 Descrizione fornita dal Centro Nazionale ONDICO – Istituto Superiore di Sanità11 In questo specifico contesto il termine Fabbricante viene utilizzato per indicare in modo unitario

il soggetto che produce (realizza) un Dispositivo medico, potendo quest’ultimo, in linea generale, riguar-dare anche software. Nel prosieguo dello Studio verranno ripresi e mantenuti i termini di Produttore e Sviluppatore già introdotti al § 3.1.3


VERIFICA DELLA DOCUMENTAZIONE VERIFICA ISPETTIVA6 La documentazione Tecnica deve essere presentata in elettronico e deve essere organizzata in un documento identificato con indice e data di revisione e deve essere in italiano o lingua accettata dall’Organismo Notificato.

7 La Documentazione inviata deve contenere:− Una descrizione generale del dispositivo, comprese le varianti previste, e della sua destinazione d’uso.− L’individuazione della classe di rischio con il riferimento alla regola uti-lizzata.− L’individuazione del fabbricante, del mandatario europeo se il fabbri-cante ha la sede legale al di fuori dell’Europa e delle varie officine di produzione con l’indicazione del processo svolto.− I disegni di progettazione, i metodi di fabbricazione previsti, in partico-lare quelli relativi alla sterilizzazione, gli schemi dei componenti, sottoin-siemi, circuiti e di altri elementi, ai protocolli.− Le descrizioni e le spiegazioni necessarie ai fini della comprensione dei disegni e degli schemi, dei protocolli e del funzionamento del prodotto.− Un elenco delle norme tecniche armonizzate applicate in tutto o in parte. − La descrizione delle soluzioni adottate per soddisfare i requisiti essen-ziali.− L’analisi del rischio, comprensiva dei risultati dei calcoli di progettazio-ne, delle indagini, delle prove tecniche svolte e di analoghe valutazioni effettuate.− Una dichiarazione che indichi se il dispositivo incorpora o meno, come parte integrante, una sostanza farmacologica o un derivato del sangue umano, nonché i dati relativi alle pertinenti prove svolte necessarie a valutare la sicurezza, la qualità e l’utilità di tale sostanza o derivato del sangue umano, considerando la destinazione d’uso del.− Una dichiarazione che attesti se nella produzione sono stati utilizzati tessuti d’origine animale.− Le soluzioni adottate di cui all’allegato I, punto 2, ovvero tutte le solu-zioni adottate dal fabbricante per la progettazione e la costruzione dei dispositivi, che devono attenersi a principi di rispetto della sicurezza, in relazione al progresso tecnologico. − Le tecniche di controllo e di verifica della progettazione, nonché i pro-cessi e gli interventi sistematici che verranno utilizzati nella progettazione dei prodotti.− La prova, nel caso in cui un dispositivo, per funzionare secondo la de-stinazione d’uso, debba essere collegato a un altro dispositivo, che esso sia conforme ai requisiti essenziali quando collegato a qualsiasi dispositi-vo che possieda le caratteristiche indicate dal fabbricante.− La valutazione preclinica, comprensiva delle prove di biocompatibilità e di quelle per valutare la stabilità (ove necessaria) e delle prove sul prodotto e relative validazioni. − La valutazione clinica di cui all’allegato X.− Il progetto di etichettatura, di confezionamento (primario e secondario), e delle istruzioni per l’uso.

8 La valutazione dei vari aspetti contenuti nella documentazione tecnica viene divisa tra i vari esperti interni (es. esperto biocompatibilità, esperto valutazione clinica, esperto analisi dei rischi, ecc.). ogni valutatore riceve un incarico personale con il riferimento ai documenti da valutare ed al protocollo interno.

9 Ogni valutatore emette un report ufficiale con gli eventuali rilievi riscon-trati. L’Organismo Notificato riassume tutti i rilevi ed invia una comunica-zione ufficiale al fabbricante chiedendone la risoluzione.

10 L’aspetto della valutazione della documentazione rimane aperto fino a quando il fabbricante non ha risolto tutti i rilievi comunicati e conseguen-temente non ha ripresentato all’Organismo Notificato tutta la documenta-zione tecnica aggiornata e revisionata.

11 Se necessario l’Organismo Notificato può svolgere o far svolgere delle prove sul prodotto per confermare o verificare che quanto definito e riportato all’interno della documentazione tecnica presentata dal fab-bricante sia conforme a quanto richiesto dai requisiti essenziali ed alle norme armonizzate applicabili. Il luogo di svolgimento delle prove viene individuato e concordato insieme al fabbricante. L’esito delle prove farà parte dei documenti di valutazione del processo di certificazione e sarà conservato insieme agli altri report.

12 I report delle prove svolte insieme alla risoluzione dei report dei vari valutatori della documentazione dovranno tutti essere chiusi per poter considerare terminata la valutazione documentale del prodotto.

6 Il gruppo ispettivo è composto generalmente da esperti di pro-dotto e esperti di sistema. Il gruppo dovrà essere sempre compo-sto da non meno di due persone.

7 Il gruppo ispettivo fissa la data della verifica ispettiva direttamen-te con il fabbricante. La verifica viene svolta presso la sede legale del fabbricante e presso le officine di produzione dove viene mate-rialmente realizzato il dispositivo medico. La verifica potrà essere svolta in qualsiasi Paese sia in Europa che al di fuori dell’Europa. La verifica durerà in media due giorni se in territorio nazionale, un tempo variabile da concordare se all’estero.

8 La verifica ispettiva andrà ad analizzare e verificare come primo aspetto l’implementazione e l’applicazione da parte del fabbrican-te del sistema di gestione della qualità ai sensi di quanto previsto in forma cogente dalla Direttiva sui dispositivi medici, ed in for-ma volontaria dalle norme UNI EN ISO 9001:2008 e UNI EN ISO 13485:2012. Il possesso di una certificazione ISO per la qualità da parte di un Ente certificatore è volontario; è sufficiente che il fab-bricante applichi quanto previsto dalle norme sulla qualità anche senza possedere una certificazione.

9 La verifica ispettiva andrà ad analizzare come secondo aspetto la verifica degli ambienti di produzione, dei macchinari utilizzati e della struttura ed organizzazione degli ambienti utilizzati come magazzino di materie prime, materiale di confezionamento, di semilavorati e di prodotti finiti. Nel corso della verifica possono essere svolte delle interviste direttamente agli operatori per sin-cerarsi della corretta applicazione di quanto previsto dalla proce-dura. Particolare riguardo sarà applicato alla verifica dei processi speciali (come per esempio la sterilizzazione). Verranno verificati anche se presenti i laboratori chimico-fisici, microbiologici e le of-ficine tecniche.

10 La documentazione del sistema della qualità che il fabbricante deve predisporre si compone di un manuale della qualità, di proce-dure (gestionali ed operative), di istruzioni e di moduli di registra-zione necessari per garantire la corretta applicazione del sistema ed il controllo. La documentazione può essere redatta in Italiano o in una lingua accettata dall’Organismo Notificato per il manuale della qualità e per le procedure gestionali, potrà essere accettata nella lingua locale nel caso di procedure operative o di istruzioni e modulistica in modo da permettere agli operatori di utilizzarla con semplicità. L’Organismo Notificato può chiedere l’intervento di un traduttore terzo se necessario sia per comprendere la documenta-zione che per intervistare gli operatori.

11 Il sistema di gestione della qualità implementato dal fabbricante deve coprire i seguenti aspetti:− Gestione della documentazione di sistema (redazione, emissio-ne, verifica, approvazione, distribuzione, archiviazione, conserva-zione, ecc.)− Responsabilità della Direzione (emissione e revisione Politica della Qualità, Riesame della Direzione, pianificazione obiettivi aziendali)− Gestione Risorse (Gestione delle attività di formazione, taratura e manutenzione)− Realizzazione del processo (Descrizione e gestione delle fasi del processo produttivo, Riesame del contratto, qualifica e monito-raggio dei terzisti e dei fornitori, approvvigionamento, attribuzione di numero di lotto o serie, realizzazione ed approvazione del lotto, identificazione e rintracciabilità di ogni fase di lavorazione e del prodotto finito, convalida dei processi speciali, monitoraggio de-gli ambienti a contaminazione controllata, pulizia degli ambienti di produzione)− Analisi e miglioramento (svolgimento di verifiche ispettive inter-ne ed esterne, gestione delle non conformità di prodotto, gestione delle azioni correttive e preventive, ecc.).

12 Il Gruppo di verifica ispettiva redigerà un verbale di verifica in cui saranno riportate tutte le risultanze e gli eventuali rilievi. Il verbale sarà inviato al fabbricante. Il processo legato alla verifica ispettiva risulterà chiuso solo quando il fabbricante avrà risposto a tutti i rilievi.

32 formit - unint

13 L’Organismo Notificato, nella figura del suo Supervisore, controlla che tutti i passaggi siano stati compiuti e che tutti i rilevi siano stati risolti e sblocca l’emis-sione del/dei Certificato/i. i certificati saranno compilati dalla segreteria e firmati dal responsabile della Sezione di certificazione.

14 Una volta firmati entro 5 giorni i Certificati saranno inseriti dalla Segreteria Tec-nica all’interno della banca dati12 del Ministero della Salute (ed inviati in formato cartaceo al Ministero dell’Industria). Il fabbricante successivamente avrà il com-pito di agganciare ad ogni certificato le informazioni richieste dalla banca dati relativamente ad ogni singolo dispositivo.

15 La Certificazione dura 5 anni. Nel corso di questi 5 anni, il fabbricante riceverà ogni anno una verifica di sorveglianza da parte dell’Organismo Notificato. Inol-tre ogni tre anni riceverà almeno una verifica a sorpresa. In ogni caso le verifiche potranno essere svolte sia presso il fabbricante che presso i propri terzisti.

16 Il fabbricante sarà tenuto a comunicare all’Organismo Notificato ogni modifica che avrà impatto sulla sicurezza, qualità, efficacia del dispositivo sia dal punto di vista degli ambienti, che dei macchinari, che del processo che della documenta-zione.

17 Il fabbricante avrà il compito di implementare e gestire quanto previsto dalla propria procedura di vigilanza per poter far fronte ad eventuali comunicazioni di evento avverso e ad eventuali necessità di richiamo del prodotto dal mercato.

18 Il fabbricante in caso volesse rinnovare la certificazione CE dopo i 5 anni, è tenu-to ad avvertire per tempo l’Organismo Notificato scelto in modo da permettere di svolgere nuovamente tutto il processo sopra descritto.

3.3. Esempi di banche dati sui dispositivi medici

3.3.1. La Banca Dati Nazionale L’art. 13 del D.lgs. 46/97 stabilisce l’obbligo (da parte del Fabbricante o del Manda-tario – nel caso di sede legale in territorio nazionale) di comunicare al Ministero della Salute:• per dispositivi medici di Classe I (ad esclusione dei dispositivi su misura e di quelli

destinati ad indagini cliniche): il proprio indirizzo e la descrizione dei dispositivi in questione

• per dispositivi medici di Classe IIa, IIb, III: tutti i dati atti ad identificare tali di-spositivi, unitamente alle etichette e alle istruzioni per l’uso, quando tali dispositivi sono messi in servizio in Italia.

12 Banca Dati Nazionale dei Dispositivi Medici (§ 3.3.1)


Questi stessi dati saranno messi a disposizione, su richiesta, delle altre Autorità Nazionali In accordo con scambio di informazioni secondo le procedure previste (Fi-gura 3).

Figura3–MinisterodellaSalute–Dispositivimedici-Aspettiregolatorieoperativi:Flussodelleinformazionirelativeaidispositivimedici

L’art. 14 del D.lgs. 46/97 stabilisce che il Ministero della Salute deve trasmettere alla banca dati europea (EUDAMED) le seguenti informazioni:a. i dati relativi alla registrazione dei fabbricanti e dei mandatari, nonché dei disposi-

tivi di cui all’articolo 13, ad esclusione dei dati relativi ai dispositivi su misura; b. i dati relativi ai certificati rilasciati, modificati, integrati, sospesi, ritirati o rifiutati

secondo le procedure di cui agli allegati II, III, IV, V, VI e VII; c. i dati ottenuti in base alla procedura di vigilanza definita dall’articolo 9; c-bis) i dati relativi alle indagini cliniche di cui all’articolo 14.

In attesa dell’avvio dell’EUDAMED (in esercizio dal 2011) ed al fine di implementare un sistema che consenta la raccolta e la trasmissione dei i dati richiesti per la banca dati europea, l’Autorità Competente italiana ha provveduto a raccogliere le informa-zioni da parte dei fabbricanti e degli Organismi Notificati, ed ha realizzato la Banca Dati nazionale (BD) sulla base del disposto dell’art.13 D. Lgs 46/97.

Ai sensi dell’art. 19, comma 1-bis, del D.lgs. 46/97 (indica che non sono trattate come riservate le informazioni sulla registrazione delle persone responsabili dell’immissione

34 formit - unint

in commercio di cui all’articolo 13 e le informazioni contenute nei certificati rilasciati, modificati, integrati, sospesi o ritirati) è possibile diffondere alcune informazioni sui dispositivi registrati nella banca dati.

La Banca Dati nazionale è consultabile al seguente link:

http://www.salute.gov.it/interrogazioneDispositivi/RicercaDispositiviServ-let?action=ACTION_MASCHERA

Le figure che seguono rappresentano l’interfaccia per la consultazione

Figura4–Bancadatinazionale–Interfacciadiricerca

È inoltre possibile salvare, in formato excel l’intero data set in modalità Dati aperti. I dati, infatti, sono accessibili a tutti, senza restrizioni di copyright, brevetti o altre forme di controllo che ne limitino la riproduzione.


3.3.2. La Banca Dati Europea – EUDAMEDCome già accennato, l’art. 14 del D.lgs. 46/97 stabilisce che il Ministero della Salute trasmetta alla banca dati europea le informazioni relative:• alla registrazione dei Fabbricanti;• ai dati relativi ai certificati rilasciati, modificati, sospesi, ritirati o rifiutati;• ai dati ottenuti in base alla procedura di vigilanza;• ai dati relativi alle indagini cliniche.

con l’obiettivo di rafforzare la sorveglianza del mercato e la trasparenza nel settore dei dispositivi medici fornendo le informazioni necessarie alle autorità competenti degli Stati membri.

Eudamed è un Portale WEB con funzione di repository centrale per lo scambio di in-formazioni tra le Autorità Nazionali competenti e la Commissione e non è accessibile al pubblico.

3.3.3. La Banca Dati USASi può effettuare la ricerca dei dispositivi medici approvati dalla FDA per mezzo di una banca dati che, propone all’utente diverse viste parziali delle informazioni con-tenute.

Di seguito sono descritte alcune peculiarità di tale banca dati.

Product ClassificationQuesto database include un elenco di tutti i dispositivi medici con le loro relative clas-sificazioni, codici prodotto, le organizzazioni Premarket Review e altre informazioni sulla regolamentazione.

Il database è consultabile al link:http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfpcd/classification.cfm

Le successive figure illustrano i criteri di ricerca e l’output fornito.

Figura5–FDA–ProcuctClassification–Interfacciaricerca

36 formit - unint

Figura6–FDA–ProcuctClassification–Outputdellaricerca

Figura7–FDA–ProcuctClassification–DettagliosulDM

510 (k) Premarket NotificationQuesto database include le Premarket Notification (510 (K)) fatta alla FDA per dimo-strare che il dispositivo è almeno altrettanto sicuro ed efficace, cioè, sostanzialmente equivalenti, ad un dispositivo legalmente in commercio che non è soggetto a Premar-ket Approval (PMA).

Il database è consultabile al link: http://www.accessdata.fda.gov/scripts/cdrh/cf-docs/cfPMN/pmn.cfm

Figura8–FDA–510(k)PremarketNotification–Interfacciaricerca


Figura9–FDA–510(k)PremarketNotification–Outputdellaricerca

Figura10–FDA–510(k)PremarketNotification–DettagliosulDM

Premarket Approval (PMA)L’approvazione pre-commercializzazione (PMA) è il processo di FDA di revisione scientifica e normativa per valutare la sicurezza e l’efficacia dei dispositivi medici di classe III.

Il suddetto processo è consultabile al link:http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfPMA/pma.cfm

Figura11–FDA–PremarketApproval(PMA)–Interfacciaricerca

38 formit - unint

Figura12–FDA–PremarketApproval(PMA)–Outputdellaricerca

Figura13–FDA–PremarketApproval(PMA)–DettagliosulDM

Establishment Registration & Device ListingQuesto database include i produttori di dispositivi medici registrati presso la FDA e i dispositivi medici prodotti da ciascuno di essi.

Il database è consultabile al link: http://www.accessdata.fda.gov/scripts/cdrh/cf-docs/cfRL/rl.cfm

Figura14–FDA–EstablishmentRegistration&DeviceListing–Interfacciaricerca


Figura15–FDA–EstablishmentRegistration&DeviceListing–Outputdellaricerca

Figura16–FDA–EstablishmentRegistration&DeviceListing–Outputdellaricerca

MAUDE – Manufacturer and User facility Device ExperienceIl database MAUDE contiene le relazioni sui dispositivi medici (MDR – medical device report) presentati alla FDA da coloro che ne sono obbligati (produttori, importatori e strutture quali ospedali, strutture diagnostiche ambulatoriali o di trattamento , case di cura e strutture di chirurgia ambulatoriale) e da volontari come operatori sanitari, pazien-ti e consumatori. Anche se tali MDR sono una fonte preziosa di informazioni, questo si-stema di sorveglianza passiva ha dei limiti (dati incompleti , imprecisi , intempestive , non verificati, distorti, mancanti perché coperti da privacy). A causa di questo, MDR sono solo una delle diverse importanti fonti di dati di sorveglianza post-marketing della FDA.

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/TextSearch.cfm

Figura17–FDA–MAUDE–Interfacciaricerca

40 formit - unint

Figura18–FDA–MAUDE–Outputdellaricerca

Si rappresenta nella seguente figura il dettaglio del report.

Figura19–FDA–MAUDE–Report


3.4. Approfondimenti sulle APPS

3.4.1. Il processo di realizzazione ed immissione sul mercato

3.4.1.1. Generalità

L’universo delle applicazioni software per dispositivi mobili13 riguarda numerosissimi set-tori applicativi, che vanno dai giochi, ai multiservizi, agli ambiti aziendali, alle funzioni di carattere informativo, agli impieghi legati a dispositivi medici: con riferimento a queste ultime, si parla spesso di APP Sanitarie. Indipendentemente dallo specifico settore appli-cativo, una APP può offrire contenuti informativi sia di tipo on-line che off-line:

• nel primo caso, i contenuti informativi vengono acquisiti direttamente tramite rete (Servizi WEB, social network, banche dati/applicazioni WEB specifiche, ecc.) e, di conseguenza, non necessitano di aggiornamento e risultano svincolatati dalle logiche produttive e commerciali del Produttore e dello Sviluppatore. Per contro gli aggiornamenti SW (ad es.: aggiornamenti funzionali apportati all’APP) pre-suppongono la disponibilità di una connessione con la quale il dispositivo mobile (smartphone e/o tablet) possa accedere ai repository disponibili in rete;

• nel secondo caso (off-line), l’aggiornamento dei contenuti dell’APP non richiede alcun tipo di connettività, ma necessita comunque di una nuova pubblicazione dell’intera applicazione;

• è possibile, infine, la coesistenza delle due condizioni sopra richiamate, potendo una applicazione presentare entrambe le tipologie informative e rendere visualiz-zabili alcuni contenuti on-line ed altri anche in assenza di connessione.

La scelta delle condizioni ottimali di fruibilità delle informazioni di una APP deve essere effettuata sin dall’inizio del Ciclo di vita impiegato per realizzarla (Software Development Life Cycle). Le fasi di progettazione e sviluppo di una qualsiasi tipo di applicazione sono raffigurate nella figura che segue:

Figura20–SchemadimassimadelSWDevelopmentLifeCycle

13 Si parla volutamente di universo in quanto alcune ultime indicazioni (difficilmente confutabili ma anche difficilmente riscontrabili) quantificano le APPS in oltre 500.000 per IOS, oltre 400mila per An-droid, oltre 55mila per WP7.

42 formit - unint

3.4.1.2. Il SW Development Life Cycle

Analisi e progettazioneL’attività di sviluppo ha inizio con l’individuazione dell’esigenza da soddisfare e con la definizione macroscopica delle funzionalità che l’applicazione deve rendere dispo-nibili e del perimetro operativo.

Nel corso di questa fase, pertanto, un aspetto fondamentale riguarda la definizione dello scopo ultimo del prodotto che si intende sviluppare, tra cui: • Customer Analysis: l’analisi della clientela a cui è rivolto il prodotto;• Competitor Analysis: l’analisi dei concorrenti che sviluppano prodotti simili;• General Requirements Analysis: l’analisi dei vincoli (tecnologici, architetturali,

normativi, ecc.), delle condizioni operative e delle proprietà di carattere generale che l’applicazione deve rispettare;

• Functional’s Requirements Analysis: l’analisi dei requisiti funzionali che l’applica-zione deve esibire.All’interno di questo perimetro viene effettuata l’individuazione dei requisiti e l’a-

nalisi dei casi d’uso. In situazioni in cui un’Azienda sviluppa una determinata APP per conto di un committente, sarà quest’ultimo a fornire parte dei requisiti a chi è incaricato di progettare e sviluppare l’applicazione.

Una volta conclusa l’analisi, inizia il vero processo di definizione dell’APP. In tale conte-sto è necessario produrre un documento dettagliato che contenga in maniera esplicativa: • lo scopo dell’APP;• le funzionalità di base;• le modalità operative;• la tipologia di utenti cui è rivolta.

Ulteriori attività che è necessario svolgere in questa fase, prima dell’avvio dello svi-luppo, sono:• creazione del team di sviluppo;• individuazione dei ruoli e delle responsabilità del team;• individuazione delle risorse di apprendimento da utilizzare (Forum, Libreria di

riferimento, codice di esempio, guide interattive etc).

Dopo aver costituito il Team di sviluppo, aver ottenuto informazioni circa la tipologia di utenti, aver prodotto il Piano del Progetto e le modalità operative dell’applicazione, è indispensabile stabilire la tipologia di piattaforma sulla quale si pensa di voler rendere disponibile i contenuti dell’APP in esame e, quindi, acquisire i vincoli di carattere tecnico.

Gli output della fase di progettazione sono:• elenco di caratteristiche in linea con la definizione principale dell’applicazione;• assegnazione delle rilevanze/priorità ad un elenco di oggetti, attività e concetti, e

definizione delle rispettive correlazioni.


Definizione del designLa fase definizione del design inizia con la progettazione e realizzazione della mockup, ossia di una rappresentazione grezza di quella che sarà l’interfaccia grafica dell’APP. All’interno della/delle mockup vengono individuati pulsanti, transizioni animate e presenza di testo e immagini. La colorazione dell’applicazione, il lettering14 e gli altri parametri di interesse (modalità di presentare i menu ed i comandi, ecc.) vengono an-notati in un documento atto a raccogliere tutti i dettagli per poter ricreare quella che, tecnicamente, viene definita grafica coordinata.

Inoltre, poiché l’applicazione potrebbe essere destinata ad operare su diversi dispo-sitivi target (si pensi, ad esempio, ad un’APP progettata per operare su smartphone e su tablet, con schermi di dimensione, caratteristiche e risoluzione diversi tra loro), è possibile che le mockup raccolgano annotazioni circa eventuali particolarità di un de-terminato dispositivo (ad esempio la disposizione di alcuni elementi a seconda dell’o-rientamento dello schermo verticale o orizzontale).

A tal proposito, si dovrà considerare che i colori non hanno la stessa temperatura (gra-dazione) su tutti i dispositivi mobili, soprattutto a causa delle diversità esistenti tra gli schermi impiegati. Pertanto, la scelta di colori, sfondi, caratteri, deve essere studiata sulla base di queste diversità, scegliendo quanto più possibile colori considerati uguali ed invarianti sui diversi supporti.

Infine, esistono alcune regole volte a facilitare l’organizzazione dei contenuti in rela-zione alla variabilità degli schermi. A titolo di esempio: • gli elementi grafici di utilizzo frequente (ad esempio link e bottoni), dovrebbero es-

sere posti nella parte alta dello schermo senza intralcio alle informazioni visualizzate;• in assenza di spazio disponibile sullo schermo, i comandi dovrebbero essere acces-

sibili richiamando menu a scomparsa con poca profondità strutturale (al massimo due sottolivelli);

• le informazioni considerate più rilevanti dovrebbero essere poste verso l’alto per facilitare la naturale lettura dei contenuti da parte degli utenti (l’occhio, per abitu-dine, tende a scorrere le informazioni dall’alto verso il basso);

• al fine di incrementare sempre di più la qualità dell’interfaccia grafica utente (GUI) e la relativa esperienza di utilizzo, è importante stabilire delle statistiche in merito all’utilizzo degli elementi utilizzati più di frequente allo scopo di riorganizzare i menù e le informazioni nelle (eventuali) successive versioni di aggiornamento;

• rispetto al punto precedente, sempre più di frequente, si fa utilizzo di comandi appositi per la personalizzazione dei menù sia in termini di ordinamento, sia di elementi da visualizzare, in modo che ciascun utente possa effettivamente costruire la propria interfaccia.

14 Il lettering è l’attività finalizzata alla scelta dei caratteri con cui comporre il testo (font, corpo, interlinea, ecc.).

44 formit - unint

Codifica, compilazione e verificaIl processo di sviluppo di un’applicazione, è subordinato a tre fasi principali:

• Codifica (coding) – È la programmazione vera e propria dell’applicazione. All’in-terno di questa, il team di sviluppo, codifica istruzioni, metodi e crea le logiche di funzionamento dell’applicazione. Ci sono alcuni accorgimenti utili da tenere presente in questa fase: non usare codice deprecato, non creare istruzioni che con-sumino eccessiva memoria, evitare metodi considerati pericolosi per la sicurezza del dispositivo mobile. Gli strumenti di supporto allo sviluppo spesso forniscono ausilio immediato al programmatore, attraverso l’auto-compilazione del codice o la segnalazione di codice deprecato. In questo modo la sintassi sarà sempre corret-ta e in linea con i parametri di sicurezza.

• Compilazione (building) – Si avvia alla fine della precedente e prevede la com-pilazione dell’applicazione nel formato finale. Questa fase comprende il collaudo dell’intera applicazione ed i controlli di conformità e coerenza del codice. Il pro-dotto finale di questa fase è l’applicazione così come verrà scaricata ed installata all’interno del supporto mobile.

• Verifica (debugging e test) – È trasversale alle precedenti e prevede costanti ve-rifiche al comportamento dell’applicazione sia per ciò che riguarda gli errori di esecuzioni, sia la gestione di memoria, processore e, più in generale, delle risor-se del dispositivo mobili. Con il debugging si possono individuare punti deboli dell’applicazione, elementi di criticità e comportamenti del dispositivo. Lo scopo finale del debugging è eliminare gli errori e trovare il modo di sfruttare nel modo più completo e bilanciato possibile le risorse messe a disposizione dal dispositivo mobile. Anche in questo caso il Team di Sviluppo ricorrerà a strumenti specifici per testare l’effettivo funzionamento dell’applicazione.

Riepilogando, gli strumenti comunemente utilizzati in fase di sviluppo sono:

Strumenti che offrono completamento del codice, analisi statica in tempo re-ale e debugging istantaneo sul dispositivo.

Strumenti di costituzione interfaccia che semplifica la realizzazione del pro-totipo dell’APP. Basta trascinare gli elementi per creare un’interfaccia utente completa senza scrivere alcun codice.

Strumenti che raccolgono e visualizzano in tempo reale dati come l’uso del di-sco, della memoria o della CPU, semplificando l’individuazione di eventuali aree problematiche.

Strumenti di simulazione che eseguono l’APP permettendo di verificare e testare il codice direttamente dall’ambiente desktop.


Al fine di estendere le potenzialità del dispositivo mobile, e conformemente a quanto previsto dai produttori di hardware, il team di sviluppo può fare ricorso all’Application Programming Interface (API) per aumentare l’operatività della propria applicazione. Le API sono rese disponibili dai produttori di hardware e consistono in comandi già codificati che lo sviluppatore può usare per aggiungere nuove funzionalità alla propria APP. Lo sviluppo delle API crescere in relazione all’evoluzione del sistema operativo del dispositivo mobile che, ad ogni rilascio, implementa nuove funzionalità da utilizza-re da parte degli sviluppatori e produttori di interfacce e dispositivi hardware.

RilascioAl termine del processo di compilazione della verifica finale di funzionamento dell’APP, vi è l’operazione di rilascio che, formalmente, include quanto necessario per rendere fruibile l’applicazione all’interno dello store online. Le procedure varia-no a seconda del fornitore del servizio ma normalmente, prima della pubblicazione dell’APP, prevedono controlli di conformità alle regole di pubblicazione sottoscritte dall’utente sviluppatore che, in genere, sono tesi a verificare che:• i contenuti dell’applicazione siano mantenuti ad un livello di censura idoneo al

pubblico per il quale l’applicazione stessa è destinata;• non risultino anomalie nella compilazione del codice (errori formali o di sintassi

che possono causare un blocco di funzionamento dell’applicazione, presenza di eventuali virus, ecc.).

Da quanto sopra, risulta evidente che, in ogni caso, lo staff tecnico dello store onli-ne, incaricato dell’effettiva pubblicazione, non entra nel merito della meccanica di funzionamento dell’APP e, di conseguenza, non valuta i risultati che l’applicazione produce (correttezza, completezza, aggiornamento, ecc.).

3.4.2. Sviluppo di APPS universaliSi parla di APPS universali nel caso in cui queste siano state progettate, realizzate ed ottimizzate per funzionare su dispositivi diversi dello stesso produttore: in par-ticolare, un’APP universale può determinare autonomamente su quale dispositivo è installata (piattaforma, sistema operativo, ecc.) e può configurarsi di conseguenza per operare al meglio in quell’ambiente specifico.

La tecnologia, denominata così dalla Apple con l’introduzione del primo iPad, fu studiata per rendere fruibili le applicazioni dell’iPhone anche sul tablet di Cupertino. Il termine riprende il concetto di universal binary utilizzato dalla stessa Apple per de-terminare quelle applicazioni che potevano essere eseguite sia su processori PowerPC che sugli attuali Intel.

Le APPS universali sfruttano le caratteristiche hardware specifiche del dispositivo sui cui operano, forniscono la giusta scelta di elementi di interfaccia e usano solo le fun-

46 formit - unint

zioni supportate da quel particolare dispositivo. Nella progettazione di un’APP univer-sale, pertanto, è fondamentale individuare ed applicare metodi specifici per separare (in gergo disaccoppiare) l’interfaccia utente dal codice dell’applicazione sottostante.

Il primo passo per realizzare un’APP universale consiste nel creare design di inter-faccia per ogni fattore di forma (ossia, in altre parole, rendere l’APP in esame indipen-dente dalle caratteristiche dallo schermo del particolare dispositivo in uso): a partire da questo aspetto, gran parte del design sarà poi influenzato dalle funzioni (e dalla grafica) che si vogliono presentare in ciascuno dei diversi fattori di forma.

3.4.3. I criteri di sicurezza applicabili ad una APPLa sicurezza delle applicazioni mobili riguarda essenzialmente i seguenti aspetti e settori:• la sicurezza del dispositivo mobile (ossia dell’apparato tecnologico impiegato);• la sicurezza dell’applicazione;• la sicurezza dei dati gestiti dall’applicazione (specie se trattasi di dati sensibili);• la sicurezza della rete utilizzata.

La sicurezza del dispositivo mobileQuesto aspetto è demandato al Produttore del dispositivo stesso e, normalmente, si ottie-ne separando il cuore del dispositivo dall’ambito operativo utilizzato dalle applicazioni.

Semplificando il concetto: ogni applicazione può far uso esclusivamente di un numero limitato di comandi rispetto alla totalità di quelli disponibili, e questa limi-tazione è voluta ed attuata (dal Produttore del dispositivo mediante meccanismi di protezione del sistema operativo) allo scopo di proteggere il dispositivo stesso da pos-sibili malfunzionamenti o azioni dannose causati da comportamenti non corretti o non ammessi della APP.

A titolo di esempio, al momento un’applicazione non è in grado di impostare au-tonomamente in modalità aereo il dispositivo mobile sul quale opera: ciò significa che l’APP non può intervenire sul core del dispositivo mobile, ma può effettuare questa operazione (indicata a puro titolo di esempio) attraverso una specifica approvazione da parte dell’utente, che viene normalmente fornita con la pressione di un determinato ta-sto. In questo modo il dispositivo mobile si protegge e garantisce una adeguata integri-tà operativa e la sicurezza necessaria a proteggere anche i dati contenuti al suo interno.La sicurezza dell’applicazioneQuesto aspetto è determinato dal livello di qualità con il quale è stato progettato e re-alizzato il codice software da parte dello Sviluppatore e, in particolare, dai metodi da lui adottati per definire le istruzioni. A tal proposito, infatti, si tenga presente che l’im-piego di codice aggiornato e di metodi non deprecati, anche se da soli non sufficienti, sono comunque elementi chiave per garantire il corretto funzionamento dell’applica-zione. Inoltre, l’impiego di logiche di gestione della memoria contribuisce a ridurre la probabilità che si presentino problematiche legate a crash improvvisi e perdite di dati.


Infine, le applicazioni, fin dal momento dell’accesso, possono garantire un elevato livello di protezione attraverso la richiesta di inserimento di PIN (Personal Identifica-tion Number) personalizzati.

La garanzia che tutto questo venga effettivamente applicato risiede principalmente nel fatto che lo Sviluppatore adotti metodologie standard di progettazione e sviluppo, conformi alle prescrizioni dettate da Sistemi di Qualità certificati ISO 9001. D’altra parte, gli stessi requisiti possono venir meno (e, spesso, risultano carenti), quando lo Sviluppatore non appartiene ad una struttura organizzata (in grado di acquisire certi-ficazioni) ed opera in completa autonomia in qualità di libero professionista, auspica-bilmente (ma non sempre) supportato da figure di esperti e specialisti nella specifica materia: in questi casi, anche laddove lo Sviluppatore esprima elevati livelli di compe-tenza ed esperienza nella progettazione e nello sviluppo di APPS, i risultati possono comunque essere inadeguati per carenza di fattori che normalmente assicurano non solo la qualità della APP al momento della sua diffusione, ma anche (ad esempio) la sua manutenibilità nel tempo e la possibilità, quindi, di essere adeguata ad eventuali modifiche e/o integrazioni di carattere tecnologico o normativo.

La sicurezza dei datiQuesto aspetto è affidato all’applicazione che, se opportunamente sviluppata, può prevedere (ove necessario e/o normativamente richiesto) anche meccanismi di auten-ticazione e meccanismi di cifratura dei dati. Durante la normale operatività di un’APP, i dati possono essere gestiti come:• statici, integrati (embedded) direttamente nel codice SW che costituisce l’appli-

cazione e, di conseguenza, non modificabili e non gestibili per operazioni di com-putazione. Questi dati vengono normalmente aggiornati assieme alle nuove release dell’applicazione che li contiene;

• su file piano, contenuti all’interno di un file esterno all’applicazione15, letto e scrit-to da quest’ultima.

• su database, contenuti all’interno di una struttura preposta all’archiviazione e alla gestione di dati. Generalmente il motore di database utilizzato nei dispositivi mo-bili è lo SQL Lite che, all’interno di un file piano, gestisce database, strutture di tabelle e dati anche in modalità cifrata.La cifratura dei dati permette di incrementare notevolmente il livello di sicurezza

anche nel caso di eventuale trasmissione dei dati (ad es.: verso una struttura specializ-zata o verso un operatore di settore – medico o assistente). Indipendentemente dalla

15 Il file, generalmente, viene realizzato in formato:• CVS: valori separati da virgola;• TSV: valori separati da tabulazione;• ASCII Formato fisso: ossia conforme ad un tracciato record con campi di posizione e lunghezza

predefinita;• Specifico: è questo il caso in cui i dati vengono esportati in un formato noto, in quanto appartenente

ad altri programmi di larga diffusione (es.: Microsoft Excel) ovvero conforme a standard di larga diffusione (es: XML – eXtensible Markup Language).

48 formit - unint

particolare forma utilizzata, specialmente laddove (come nel caso in esame) i dati in esame siano dati sensibili16, è necessario che l’applicazione software assicuri un tratta-mento (modalità di archiviazione, modalità di trasmissione, separazione dati sensibili da dati anagrafici o di identificazione, periodo di mantenimento in archivio, ecc.) conforme alle prescrizioni della normativa vigente.

La sicurezza della reteQuesto aspetto, infine, è demandato al gestore, sia che si tratti di reti wireless, che di reti mobili (UMTS, 3G, LTE). L’integrazione tra la sicurezza applicabile ai dati e la sicurezza della rete fornisce, generalmente, un ambiente idoneo per la gestione/trasmissione di dati sensibili.

3.4.4. La struttura operativa di un dispositivo mobileAlla luce di quanto fin qui descritto, è importante comprendere che i livelli con i quali interagisce lo Sviluppatore sono essenzialmente i seguenti (Figura 21):• Application layer• Core layer• Main subsystem layer.

Figura21–Esemplificazionedellastrutturaoperativadiunosmartphone

• Application layer – È il livello in cui viene eseguita l’applicazione software. Quest’ultima dispone delle risorse che le necessitano per operare ed interagisce con il core layer in modo diretto.

• Core layer – È il centro operativo del dispositivo mobile: contiene i file di sistema e tutte le istruzioni essenziali al funzionamento di base dell’apparato. Le capacità

16 Si ricorda, infatti, che i dati sensibili sono dati personali idonei a rivelare l’origine razziale ed etnica, le convinzioni religiose, filosofiche o di altro genere, le opinioni politiche, l’adesione a partiti, sindacati, associazioni od organizzazioni a carattere religioso, filosofico, politico o sindacale, nonché i dati personali idonei a rivelare lo stato di salute e la vita sessuale (art. 4, lett. d, del Codice della Privacy – Dlgs 196/2003).


(funzionalità) contenute in questo livello possono essere richiamate dalle applica-zioni software soprastanti (application layer) ma non possono essere modificate. In questo modo il dispositivo mobile garantisce la sua integrità di sicurezza e previene eventuali danni e malfunzionamenti provocati da operazioni errate o non concesse avviate da una applicazione.

• Il main subsystem layer (sottosistema principale) – È il livello più basso del dispo-sitivo e contiene istruzioni di livello basilare che, assemblate assieme, permettono al core layer di gestire tutte le componenti del dispositivo (es.: tastiera, schermo, periferiche di trasmissione/ricezione, microfono, ecc.). Questa parte dell’apparato non è raggiungibile direttamente da nessuna applicazione, né tantomeno dall’u-tente. Solo il core layer può sfruttarne le funzionalità in modo indipendente dalle applicazioni che sono in esecuzione.

Un esempio: l’attribuzione della priorità durante una chiamata.Quando il dispositivo riceve una telefonata, il sottosistema principale decodifica il se-gnale in ricezione dall’antenna e invia l’informazione (chiamata in arrivo) al core layer. Il core layer provvede ad attivare microfono e auricolare, organizza la schermata di chiamata ricevendo i dati dal sottosistema principale (es: numero chiamante) e con-frontandoli con la rubrica interna. A seconda della configurazione imposta dell’utente, inoltre, il core layer esegue la suoneria impostata, la vibrazione o entrambi. Pertanto, al momento della ricezione di una chiamata, è solo il core layer che assegna una priorità (generalmente la più alta) all’informazione e che mantiene un collegamento primario con il sottosistema principale, ricevendo e trasmettendo dati da/verso l’antenna.

Da quanto sopra discende una considerazione di notevole importanza ai fini dello Stu-dio. Infatti, benché durante la chiamata il dispositivo consenta di eseguire altre applica-zioni, queste ultime non sono autorizzate ad interferire con la chiamata stessa: al momen-to, quindi, nessuna applicazione è in grado di interagire con il sottosistema principale, attivando, disattivando o alterando, ad esempio, lo stato di funzionamento dell’antenna17.

In relazione all’attuale stato dell’arte della tecnologia, sia per le APPS che, soprattut-to, per i dispositivi mobili, le precedenti considerazioni implicano che, ad oggi, una APP Sanitaria:• non è in grado di allocare, in modo dedicato, le risorse del dispositivo stesso (ad

esempio: memoria, CPU, ecc.), al fine di garantire un funzionamento ottimizzato;• non è in grado di verificare lo stato del dispositivo o delle sue componenti essen-

ziali (ad esempio: per verificare il corretto funzionamento del dispositivo o di un sensore, ovvero ancora per segnalazione di eventuali errori o anomalie, ecc.);

17 È possibile, naturalmente, che l’utente, attraverso appositi comandi, possa inibire la ricezione di chiamate: resta ferma la considerazione che tali comandi non sono al momento disponibili alle applica-zioni software che operano sul dispositivo.

50 formit - unint

• non è in grado di impostare/modificare le modalità operative del dispositivo (es.: per impedire la ricezione di chiamate telefoniche durante il funzionamento dell’APP Sanitaria);

• può esclusivamente visualizzare messaggi (con richiesta di pressione tasto a titolo di conferma) con i quali invita l’utente ad effettuare/non effettuare determinate azioni che possono inficiare i risultati dell’attività medica in corso.

È evidente l’elevata criticità derivante da queste limitazioni, dalle quali emerge evi-dente l’attuale incapacità di una APP Sanitaria di governare adeguatamente il dispo-sitivo tecnologico sottostante e le sue periferiche, indipendentemente dal livello di qualità e sicurezza con le quali la APP è stata progettata e realizzata.

3.5. L’evoluzione delle piattaforme mobili

3.5.1. Panoramica del trend di mercato Il mercato dei dispositivi mobili, nel tempo, ha subito tre processi evolutivi distinti nel corso di tre diverse epoche tecnologiche:1. la prima, iniziale, basata sulla naturale competizione che esisteva tra i Produttori

nella creazione di componenti da installare all’interno dei dispositivi mobili;2. la seconda si è sviluppata successivamente, con l’obbiettivo di diversificare tecno-

logicamente tali apparati, al fine di renderli più performanti ed avanzati rispetto a quelli di prima generazione;

3. la terza, quella attuale, è caratterizzata dal ruolo baricentrico dei Produttori che, avendo creato una generazione di dispositivi con caratteristiche più o meno equi-valenti e comparabili dal punto di vista tecnico, stanno orientando le scelte future verso una rivalutazione della finalità d’impiego. La situazione attuale, pertanto, prevede un forte orientamento verso l’e-health,

complice anche la crescente adozione da parte dei possessori di smartphone di una filosofia di vita orientata alla salute e all’attività sportiva18. Per questo motivo, anche al fine di creare un nuovo segmento di mercato, i Produttori di dispositivi mobili, inizia-no a dotare i propri prodotti con sensori specifici per il mondo sanitario.

3.5.2. Lo sviluppo di sensori: alcuni esempiÈ opportuno precisare che, attualmente, i dispositivi mobili sono dotati di due tipo-logie di sensori:• sensori ad uso esclusivo del dispositivo mobile (ad esempio il termometro che

rileva la temperatura del processore) che non risultano adeguati per rilevazioni di

18 Il caso dell’APP Runastatic è emblematico e particolarmente idoneo a descrivere la diffusione di una cultura più orientata verso lo sport e la salute del fisico.


tipo sanitario e che, comunque, non sono sempre utilizzabili dalle APPS e dall’u-tente (normalmente questi sensori espletano funzionalità riservate al core layer o al main subsystem layer);

• sensori utente (ad esempio bussola, accelerometri, giroscopi, localizzatori GPS, ecc.) che possono invece essere utilizzati da una APP Sanitaria (e/o dall’utente) e, purché correttamente impiegati 19, possono validamente supportare funzionalità specifiche del settore sanitario.

Di seguito alcuni esempi.

AppleUn primo esempio è costituito dalla Apple, che, in linea con il trend tecnologico orientato a sviluppi nel settore e-health, procede all’assunzione di due esperti di in-gegneria medica, da impiegare, presumibilmente, nel progetto iWatch. Il progetto (ancora non confermato) sembra prevalentemente orientato alla realizzazione di di-spositivo indossabile, che può essere portato al polso e che può essere connesso ad un dispositivo mobile (come uno smartphone o un tablet), via Bluetooth o wi-fi, per acquisire, elaborare e mostrare informazioni in tempo reale.

Figura22–Apple:unaipotesidisensore(progettoiWatch)

SamsungUn altro esempio, fra le aziende produttrici di dispositivi mobili orientate al suddet-to segmento di mercato, è costituito da Samsung, che ha recentemente lanciato sul mercato il modello Galaxy S5, smartphone dotato di sensore specifico per la rileva-zione del battito cardiaco (Figura 23). A differenza di altre soluzioni tecnologiche, che impiegavano la luce del flash integrato per calcolare le pulsazioni cardiache (me-todo poco affidabile perché non basata su apparati di rilevazione specifici), Samsung ricorre ad un sensore dedicato utile sia al comparto medico-sanitario, che a quello amatoriale sportivo.

19 Questa condizione pone dei limiti e degli aspetti di criticità notevoli, specie nel caso di APPS me-diche utilizzate da utenti senza specifiche competenze e conoscenze in materia.

52 formit - unint

Figura23–SamsungGalaxyS5,sensoreperlarilevazionedelbattitocardiaco

Nell’esempio visto, il software interroga direttamente il sensore illustrato (Figura 23): questa capacità, pro-futuro, potrebbe essere facilmente arricchita introducendo ulte-riori funzionalità sviluppate sui dati rilevati (si pensi, ad esempio, alla trasmissione dei dati afferenti il battito cardiaco ad un medico o, comunque, ad una struttura sanitaria).

Figura24–Schermatadirilevazionedelbattitocardiaco–SamsungGalaxyS5

Ancora la Samsung, nel corso di un evento a San Francisco, ha presentato un dispo-sitivo indossabile e una piattaforma open per applicazioni legate alla salute, Simband, costituito da un braccialetto che, grazie a una serie di sensori integrati, è in grado di misurare e raccogliere informazioni sulla nostra condizione fisica – dal battito cardia-co ai livelli di glucosio.

Figura25–Samsung:ilprogettoSimband


Il dispositivo è ancora a livello prototipale e, di conseguenza, suscettibile di modifiche e integrazioni dipendenti soprattutto dall’evoluzione dei sensori disponibili sul mer-cato. L’elemento innovativo è costituito dalla piattaforma open, che potrà quindi esse-re utilizzata anche da altri fornitori, e dal fatto che il dispositivo prevede la possibilità di configurare i sensori che si vogliono utilizzare, consentendo così di specializzare le funzionalità desiderate in funzione delle specifiche esigenze.

MicrosoftUn ulteriore esempio è costituito dal workshop sull’e-health organizzato da Microsoft nel 2010, ove Wen-Lian Hsu (dell’Institute of Information Science Academia Sinica di Taipei) ha presentato una diapositiva per il calcolo predittivo di disfunzioni cardiache.

Figura26–Diapositivasulmonitoraggiocronicodeipazienti.

La soluzione prospettata prevede:• la raccolta dei dati tramite dispositivo medico;• l’elaborazione degli stessi tramite applicazione software;• il successivo invio dei dati ad un database centrale.

Una volta elaborati i dati, sono poi esaminati automaticamente da un programma ad hoc che, in caso di anomalie nel tracciato dei battiti cardiaci, allerta automaticamente il medico del paziente.

Alcune criticità...Come mostrato nei precedenti esempi, moltissime componenti hardware (sensori, pe-riferiche, ecc.) sono (o, a breve saranno) già presenti all’interno (o a corredo) di un dispositivo mobile: malgrado ciò, il loro impiego per finalità mediche potrà ritenersi

54 formit - unint

realmente sicuro solo quando tali componenti riusciranno a garantire caratteristiche e requisiti di qualità adeguati a tale scopo. A tal proposito, infatti, si osserva che sono stati rilevati numerosi problemi (segnalati normalmente sulla rete) derivati da misu-razioni (o comunque dal funzionamento) di sensori che forniscono risultati affetti da margini di errore e, di conseguenza, potenzialmente pericolosi se utilizzati per finalità mediche.

A mero titolo di cronaca, un esempio in tal senso è costituito dagli accelerometri Apple che, nella versione iPhone 5, sono stati sostituiti provocando gravi disagi agli utenti, quando si è passati dal vecchio produttore (ST Microelectronics) all’accele-rometro Bosch (modello Sensortech BMA 220) con letture variabili di oltre 5 volte rispetto il precedente sensore (a fronte di precedenti letture di +/- 20mg, il nuovo sensore Bosch segnalava +/-95mg). In questo caso specifico, la correzione poteva es-sere effettuata direttamente dall’utente, via software, attraverso una calibrazione dello zero-g offset.

È ovvio che tale rimedio costituisce un evidente palliativo e può essere fonte di rischi, anche elevati, se effettuato da persone (ad esempio: anziani) non esperte nelle operazioni richieste.

ConclusioniGli esempi mostrati evidenziano che la tematica e-health è quanto mai attuale, e la di-mostrazione di ciò si può ritrovare negli sforzi economici e di ricerca che i produttori di dispositivi mobili stanno sostenendo nel lanciare sul mercato sempre più prodotti che possano rispondere a questa richiesta. Naturalmente, l’aggiunta di sensoristica dedicata all’interno dei dispositivi mobili avrà come conseguenza che anche il livello applicativo muterà per consentire agli sviluppatori di aggiungere nuove funzionalità software alle apps già sviluppate o in fase di sviluppo. Questo trend, pertanto, denota quanto i Produttori siano aperti e sensibili al fenomeno delle APPS Sanitarie, attraver-so le quali, grazie anche ad una auspicabile differenziazione dell’offerta, potrebbero conquistare una fetta significativa del mercato sanitario, con prodotti dedicati tanto ai professionisti del settore quanto agli utenti generici (pazienti, sportivi, ecc.).

3.6. Il modello di classificazione delle APPS Sanitarie

3.6.1. L’approccio metodologico adottatoCome già anticipato, il presente Studio è finalizzato ad effettuare e presentare una pa-noramica della situazione che, ad oggi, caratterizza il fenomeno delle APPS Sanitarie, dal momento della loro progettazione e realizzazione, fino alla loro successiva diffu-sione sul mercato. A corredo di tale analisi, inoltre, lo Studio vuole definire le possibili misure necessarie per avviare un processo di governance delle APPS Sanitarie, in grado di contenere le criticità fin qui rilevate, consentendo, nel contempo, di sfruttare


adeguatamente le enormi potenzialità ed i significativi benefici che possono derivare da un loro impiego controllato. Per avviare il processo sopra delineato, è necessario, come primo passo, caratterizzare le APPS Sanitarie con tutta una serie di informazio-ni necessarie per garantirne la governance: tale approccio metodologico, brevemente richiamato nel seguito, si basa sulla definizione di un Modello di rappresentazione che viene sviluppato attraverso l’elaborazione di una Mappa concettuale, ossia uno strumento grafico che consente di rappresentare informazioni e conoscenza afferenti uno specifico argomento e, mediante l’impiego di diagrammi, permette di visualizzare in maniera schematica i contenuti e le relazioni esistenti tra gli elementi che caratte-rizzano l’argomento stesso. Nel caso in esame, la mappa concettuale viene utilizzata per caratterizzare una APP Sanitaria, definendo tutte le informazioni necessarie per la sua identificazione e le relazioni esistenti tra queste. In particolare, la costruzione della mappa avviene seguendo uno schema variabile che, in funzione delle tematiche trattate nello studio e degli obiettivi specifici che si vogliono raggiungere, si basa es-senzialmente sui seguenti passi:• si individuano i concetti fondamentali orientati al raggiungimento degli obiettivi

attesi; tali concetti rappresentano le parole concetto (rappresentate all’interno di figure geometriche dette nodi);

• si definiscono le relazioni esistenti tra le parole concetto individuando le parole legame (collocate su frecce che rappresentano le relazioni e collegano le precedenti parole concetto).In sintesi, la mappa è la rappresentazione grafica di concetti espressi in forma

sintetica (parole concetto) all’interno di una forma geometrica (nodo) e collegati fra loro da linee (frecce) che esplicitano la relazione attraverso parole legame. Queste ultime non sono basate su principi gerarchici ma su gruppi di appartenenza e ciò comporta che gruppi di diversa natura possono essere collegati in relazione diretta fra loro. La scelta di tale approccio metodologico è quindi basata sulla possibilità di aggregare ambiti diversificati all’interno di uno stesso diagramma, ottenendo co-munque una visione armonica e di insieme dell’intero progetto. In tal senso, infatti, non solo è possibile aggregare aspetti tecnici e organizzativi, ma anche verificarne le relazioni. Ogni aspetto trattato, pertanto, mantiene la sua identità ma, al tempo stesso, è inserito in una rappresentazione di contesto più ampia ed uniforme. L’a-dozione di tale metodologia, inoltre, consente di suddividere il diagramma, ovvero la mappa concettuale rappresentata, in diverse viste, ciascuna con il suo livello di dettaglio.

3.6.2. La Mappa concettualeIl panorama delineato nei precedenti paragrafi evidenzia che le APP Sanitarie, qualo-ra non adeguatamente regolamentate, possono comportare rischi per la salute pubbli-ca, allo stesso modo (e forse, in taluni casi, in modo più critico) dei dispositivi medici

56 formit - unint

tradizionali. La destinazione d’uso di una APP Sanitaria determina se la stessa soddi-sfa la definizione di Dispositivo medico. In particolare una APP può considerarsi un Dispositivo medico20 se usata per:• effettuare diagnosi, prevenzione, controllo terapia o attenuazione di una malattia;• effettuare diagnosi, controllo, terapia, attenuazione o compensazione di una ferita

o di un handicap;• effettuare studio, sostituzione o modifica dell’anatomia o di un processo fisiologico;• intervenire sul concepimento.

La mappa concettuale di seguito rappresentata illustra tutti gli elementi che concor-rono alla caratterizzazione/gestione di una APP Sanitaria. In particolare, evidenzia:• i processi in atto per le attività, preliminari all’immissione in commercio, di veri-

fica e approvazione e, in seguito, di vigilanza sugli incidenti verificatisi, nonché di sorveglianza del mercato;

• gli aspetti organizzativi, individuando gli Attori che esercitano un ruolo, attivo o passivo, in una delle fasi/attività che caratterizzano il ciclo di vita per lo sviluppo di una APP;

• gli aspetti tecnici, dai quali derivano i requisiti di sicurezza e di qualità;• gli aspetti regolamentari vigenti, che si concretizzano nelle norme cogenti che re-

golano (oggi) i Dispositivi medici e che potranno eventualmente regolare (domani) le APPS Sanitarie.

Per ciascuno dei precedenti ambiti individuati, sono esplicitate tutte le caratterizza-zioni sia in termini di declinazioni che di relazioni intercorrenti (linee tratteggiate). Inoltre, con il colore rosso, sono riportate le interazioni che i diversi Attori potranno stabilire con il Registro APPS, destinato a contenere tutte le informazioni di caratte-rizzazione delle APPS Sanitarie (secondo le informazioni rappresentate nella mappa concettuale) e a fornire uno strumento di riferimento attraverso il quale veicolare tutte le comunicazioni/informazioni/documenti scambiati/e a vario titolo tra i diversi Attori. Di tali informazioni, sono evidenziati con il colore rosso i nodi.

Nel prosieguo dello Studio viene più volte referenziato il Registro APPS.Si precisa fin d’ora che il presente Studio si limita a fornire indicazioni (requisiti e specifiche) utili per poter procedere, successivamente e tramite altra iniziativa, alla progettazione ed alla realizzazione di tale sistema.

20 Al proposito, si richiama quanto già introdotto al § 2.1 in merito alla possibilità di assimilare una APP medica ad un Dispositivo medico.


Figu

ra27–LaM

appa

con

cettua

ledicaratt

erizz

azione

delleAPP

SSanitarie

58 formit - unint

Nella precedente figura, si usano le seguenti notazioni.

La freccia rappresenta le relazioni dirette (definizioni e/o dipendenze) fra gli elementi (Attori, Requisiti, ecc.) individuati nella mappa

La linea tratteggiata rappresenta le relazioni che intercorrono fra gli elementi (Attori, Requisiti, ecc.) individuati nella mappa

La linea continua rossa rappresenta le relazioni che intercorrono fra gli Attori, che a vario titolo esercitano un ruolo nel processo di sviluppo/commercializzazione di una APP, e il Registro

3.6.3. La tassonomia propostaLa Mappa Concettuale presentata in Figura 27 è stata elaborata a partire dai risultati emer-si dall’analisi della situazione attuale, con particolare riferimento agli aspetti regolamen-tari vigenti e alle modalità di commercializzazione delle APPS. Nei successivi paragrafi si descriverà in maniera dettagliata la tassonomia21 proposta, in termini di parametri indivi-duati. Come precedentemente anticipato, infatti, si è ipotizzato che una APP Sanitaria sia:• progettata e realizzata in base ad aspetti tecnici;• normata in base ad aspetti regolamentari;• verificata, validata, vigilata e sorvegliata in base ai processi attuati;• commercializzata e gestita in base ad aspetti organizzativi, a fronte dei quali si

individuano tutti gli Attori coinvolti nei diversi processi;Come descritto nei precedenti paragrafi, inoltre, nella mappa concettuale si intro-

duce il concetto di Registro (DB APP), quale sistema informatico di supporto desti-nato a contenere tutte le informazioni rappresentate nella mappa stessa. Nei seguen-ti paragrafi si descrivono in dettaglio gli ambiti individuati nella mappa concettuale dell’APP Sanitaria.

3.6.3.1. Gli aspetti tecnici

Gli aspetti tecnici trattati afferiscono alle modalità con le quali viene effettuata la pro-gettazione e la realizzazione di una APP Sanitaria. In linea generale gli aspetti tecnici possono esprimersi attraverso i seguenti requisiti:• Requisiti utente;• Requisiti tecnico-funzionali;• Requisiti di sicurezza;• Requisiti di qualità.

I requisiti utenteRappresentano le funzionalità richieste – ad alto livello – affinché l’APP Sanitaria soddisfi la definizione di dispositivo medico: tali funzionalità devono necessariamente

21 Il termine tassonomia vuole indicare la definizione esatta delle procedure e dei criteri che regolano la classificazione (in questo caso) delle APPS mediche.


dipendere dalla destinazione d’uso dell’APP in esame. Pertanto, in accordo con quan-to accade per i dispositivi medici, l’APP Sanitaria dovrà effettuare diagnosi, controllo, cura (terapia) o prevenzione. In tale contesto, appare evidente che l’analisi dei requi-siti utente non può non considerare eventuali Change Request finalizzate a migliorare e/o integrare le funzionalità richieste.

I requisiti tecnico-funzionali Individuano le funzionalità operative che l’APP Sanitaria deve soddisfare perché sia assimilabile ad un dispositivo medico. In particolare, soddisfare una o più delle se-guenti opzioni: • gestire dati provenienti da origine dati esterne o interne;• leggere dati;• visualizzare dati;• scrivere dati attraverso immissioni manuali o elaborazioni manuali;• cancellare dati.

Le funzionalità operative, inoltre, devono determinare le caratteristiche Hardware e Software del dispositivo mobile (o dei dispositivi mobili) sui quali l’APP in esame è in grado di operare.

I requisiti di sicurezzaSono essenzialmente basati su:• i vincoli di progettazione e sviluppo, imposti dal Produttore dei dispositivi che, di

conseguenza, esercita vincoli sulla progettazione e sulla programmazione dell’APP in esame;

• la normativa vigente, che esercita vincoli cogenti sulla gestione delle informazioni. Per quanto attiene ai vincoli imposti dal Produttore di dispositivi mobili, è neces-

sario ricordare che un qualsiasi dispositivo mobile viene progettato e realizzato solo per consentire comunicazioni mobili, più in generale, funzionalità multimediali. Tale considerazione implica che, sebbene sia possibile installare APPS Sanitarie su tali di-spositivi, questi ultimi si trasformano in un dispositivo medico temporaneo solo ed esclusivamente nel momento in cui la APP Sanitaria è in esecuzione (e il dispositivo non stia già assolvendo alle sue funzionalità primarie). In conclusione, allo stato attua-le, i vincoli imposti sulla progettazione dei dispositivi mobili non prevedono che tali piattaforme possano assolvere a funzioni medicali.

I requisiti di qualitàsono individuati in linea con la normativa vigente, che esercita vincoli sulla gestione delle informazioni. Ulteriori requisiti sono individuati anche a seguito di Segnalazioni di malfunzionamenti da parte degli Utilizzatori.

60 formit - unint

3.6.3.2. Gli aspetti regolamentari

Gli aspetti regolamentari, precedentemente trattati e descritti, sono di rilevante im-portanza in considerazione del fatto che, il campo di interesse del presente Studio è rappresentato dalle APP Sanitarie. Per tali motivazioni, sono state analizzate:• norme e direttive;• linee guida;• standard (ISO, IEC, CEI, ecc.).

per tutto quanto attiene e afferisce ai dispositivi medici, essendo quest’ultimo lo scenario normativo di riferimento in cui si sviluppa l’APP Sanitaria.

Si deve considerare che, la continua evoluzione del mercato di riferimento e delle tecnologie, inciderà inevitabilmente su tale scenario con probabile introduzione di proposte di integrazioni e/o modifiche alle Norme e Direttive vigenti soprattutto per quanto attiene alla individuazione e definizione dei Requisiti di Sicurezza e di Qualità dell’APP Sanitaria.

3.6.3.3. I processi di verifica, validazione, vigilanza e sorveglianza

Una APP Sanitaria è verificata, validata e vigilata, in base a Processi, suddivisi in:• Verifica e Validazione;• Vigilanza e Sorveglianza.

Tali processi, a tutti gli effetti, sono demandati e attuati dagli Attori coinvolti e definiti negli Aspetti Organizzativi poiché interessano aspetti di gestione e commer-cializzazione dei dispositivi medici. Tuttavia, si è ritenuto opportuno rappresentare gli stessi nella mappa concettuale, al fine di esplicitarne al meglio le relazioni intercorren-ti fra gli Attori coinvolti.

Il processo di verifica e validazioneQuesto processo interessa l’Organismo Notificato in qualità di attore principale e riguar-da l’attestazione di conformità ai fini della marcatura CE dei dispositivi medici e rilascia-ta al produttore/fabbricante. Il D. Lgs. 25 gennaio 2010, n. 37 ha introdotto novità che coinvolgono l’operatività degli Organismi Notificati soprattutto per quanto riguarda la:• Valutazione delle indagini cliniche;• Valutazione del software.

Relativamente alla valutazione del SW , l’Allegato I alla suddetta direttiva, al cap. 12.1 bis recita: “...Per i dispositivi che incorporano un software o costituiscono in sé un software medico, il software è convalidato secondo lo stato dell’arte, tenendo conto dei principi del ciclo di vita dello sviluppo, della gestione dei rischi, della validazione e della verifica...”.

In considerazione di tale aspetto, quindi, il processo attuato dall’Organismo Notifica-to potrebbe prevedere in futuro attività di validazione e verifica in tema di ciclo di vita


del software e gestione dei rischi, ad esempio, in accordo con la norma EN 62304 che definisce i requisiti del ciclo di vita del software medicale, ovvero le modalità di pro-gettazione, sviluppo, installazione e supporto nella fase di post commercializzazione.

Il processo di vigilanza e sorveglianzaQuesto processo vede coinvolti. • Il Ministero della Salute, relativamente ai dispositivi medici attivi, opera attività

di sorveglianza del mercato, nella fase successiva all’immissione in commercio, con particolare riferimento alla rintracciabilità, alle segnalazioni di incidenti e le misu-re correttive da attuare una volta immessi sul mercato i dispositivi. Al Ministero, quindi, attengono le attività di sorveglianza e monitoraggio del settore.

• L’Organismo Notificato è interessato dal processo Vigilanza e Sorveglianza ed è esso stesso soggetto ad attività di sorveglianza, effettuata dal Ministero della Salu-te, nel caso richieda di poter espletare le procedure di certificazione per la valuta-zione della conformità CE dei fabbricanti di dispositivi medici di classe IIa, IIb, III e per i dispositivi di classe I con funzioni di misura o forniti allo stato sterile.Il processo, quindi, è attuato da diversi Attori ed è da intendersi come l’insieme

delle azioni e attività volte a incrementare la protezione della salute e la sicurezza dei pazienti, degli utilizzatori riducendo la possibilità che lo tesso tipo di incidente si ri-peta in luoghi diversi in tempi successivi.

3.6.3.4. Gli aspetti organizzativi

Gli aspetti organizzativi trattati afferiscono alle modalità di commercializzazione e gestione delle APP Sanitarie e riguardano:• il Ministero della Salute (con il precipuo compito di gestire il Registro – DB

APP);• l’Organismo Notificato;• il Produttore, rappresentato da:

− Fabbricante di supporto mobile;− Azienda Ospedaliera;− Struttura Sanitaria;− Centro di Ricerca.

• lo Sviluppatore, rappresentato da:− Azienda di sviluppo SW;− Specialista (singolo individuo);− Centro di Ricerca.

• il Distributore, rappresentato da uno o più proprietari di Online APP Store;• l’Utilizzatore, rappresentato da:

− Istituzioni (Pubbliche o Private), − Privato (operatore sanitario o cittadino);

62 formit - unint

Tutti gli Attori individuati avranno interazioni con il Registro, il cui compito di gestione è di esclusiva competenza del Ministero della Salute.

Come già esposto nel precedente paragrafo, gli Attori interessati dal Processo di Verifica e Validazione e dal Processo di Vigilanza e Sorveglianza sono il Ministero della Salute e l’Organismo Notificato.

Si deve osservare inoltre che, nella tipologia di Produttore/Fabbricante (o Manda-tario), è stato individuato anche il Produttore di supporto mobile il quale esercita vin-coli di programmazione nella fase di progettazione e realizzazione dell’APP Sanitaria.

3.7. Considerazioni finali sulla situazione attualeDa quanto sopra, emergono due argomenti di rilievo:• l’effettiva applicabilità e coerenza dell’impianto normativo attuale al mondo delle

APPS ed alle prossime evoluzioni tecnologiche previste;• le piattaforme mobili, in quanto destinate ad ospitare le APPS.

Il primo punto nasce dalla considerazione che, allo stato dell’arte, molte delle APPS Sanitarie sono prodotte da gruppi ristretti di soggetti che non si configurano come im-presa e per i quali risulterebbero di difficile applicabilità tutte le disposizioni normative previste dal processo di certificazione CE per i dispositivi medici. Entrando nel merito della questione, a ns. avviso, si dovrebbe trovare una soluzione che, salvaguardando la qualità del prodotto (intesa in senso estensivo), preservi nel contempo l’enorme ba-gaglio di conoscenze e competenze espresso dal comparto produttivo dello specifico settore, evitando, qualora rimanga inalterato l’iter di certificazione, il naturale depau-peramento della estemporanea creatività propria di chi non è imbrigliato in un sistema.

La seconda considerazione, prende spunto dalla constatazione che un qualsiasi software stand-alone, nelle attuali disposizioni, è il solo oggetto del processo di cer-tificazione indipendentemente dalla piattaforma target per la quale è stato realizzato dal fabbricante, in quanto si presume che la piattaforma sia di per sé un dispositivo medico. In tal caso, dovrebbe essere lasciata all’analisi del rischio e alle successive contromisure tecnico/tecnologiche la definizione delle interazioni tra SW e HW.

Tale approccio ha il suo raziocinio nell’assunzione che, pur rimanendo inalterata la sua destinazione d’uso, il dispositivo mobile divenga un Dispositivo Medico Temporaneo nel momento in cui la APP Sanitaria è in esecuzione. Ma, anche se temporaneo, tale dispositivo medico necessita di qualche accorgimento?In particolare, è necessario normare anche tale aspetto?

Questi ed altri aspetti sono trattati nel prosieguo dello Studio.

4. Le esigenze poste alla base dello studio

A valere sugli aspetti precedentemente descritti e sui risultati emersi dall’analisi della situazione attuale, è possibile delineare una gap – analysis, contenente i fattori e gli elementi sui quali è necessario intervenire per raggiungere gli obiettivi che lo Studio si prefigge e, in particolare, per garantire una più efficace governance dei processi di sviluppo e diffusione delle APPS Sanitarie.

4.1. Destinazione d’uso del dispositivo tecnologicoUna prima considerazione, riguarda la destinazione d’uso del dispositivo mobile sul quale opera una APP Sanitaria: a tal proposito, come già anticipato, l’attuale quadro normativo esprime in modo chiaro l’insieme dei requisiti e delle specifiche (tecniche e di safety) che deve possedere un software stand alone (ad es.: una APP) per essere considerato Dispositivo medico.

È altrettanto chiaro che, nell’esprimere tali prescrizioni, il Legislatore abbia assun-to implicitamente che un SW stand-alone considerato Dispositivo medico è destinato ad operare su una piattaforma tecnologica a sua volta certificata e, di conseguenza, caratterizzata da destinazione d’uso22 propria di un Dispositivo medico23. Quanto so-pra premesso, si osserva che:• una APP Sanitaria può esprimere le funzionalità per le quali è stata progettata

solo durante il periodo nel quale risulta attiva a bordo di una piattaforma mobi-le (smartphone, tablet, ecc.). È evidente, infatti, che la APP, come qualsiasi altro software, non può erogare di per sé alcuna funzionalità (medica o di altro tipo) se non quando stia funzionando su una piattaforma elaborativa;

22 Il termine destinazione d’uso viene qui utilizzato per indicare l’insieme delle modalità operative e delle finalità di impiego di un determinato dispositivo (apparato, software, ecc.) – .

23 A titolo di esempio, è evidente che un aggiornamento del SW che correda un apparato radiologico, anche quando venga diffuso in un momento successivo ed in modo separato dall’apparato stesso (ad es.: tramite CD-ROM, per aggiornamento funzionale o tecnologico), venga progettato e realizzato presumendo che debba operare su un apparato dedicato che non assolve altre funzioni al di fuori di quelle per le quali è stato progettato (nell’esempio in esame, l’apparato radiologico non effettua collegamenti in rete, non effettua/riceve telefonate ne messaggi SMS, ecc.).

64 formit - unint

• il funzionamento24 di una APP dipende dal dispositivo tecnologico sul quale la APP stessa sta operando. Questo concetto, in realtà, si traduce in una duplice di-pendenza, di tipo:

− statico: il funzionamento della APP dipende dalle caratteristiche tecnologiche del dispositivo, ossia, ad esempio, dalla tipologia di processore, dal sistema operativo installato sul dispositivo, dalla memoria installata, ecc.;

− dinamico: il funzionamento della APP dipende anche dalla disponibilità e dallo status di corretta operatività che le componenti tecnologiche e le perife-riche presentano nel preciso momento in cui la APP sta operando (ad esem-pio, per contestuale funzionamento di un’altra applicazione attiva – musica, telefonata in arrivo, ecc.);

• il dispositivo target sul quale opera una APP Sanitaria ha una destinazione d’uso diversa e non specificamente rivolta ad un ambito sanitario: il dispositivo in esame, infatti, viene progettato e realizzato dal costruttore per consentire comunicazioni mobili e, più in generale, funzionalità multimediali ma, sicuramente, non per assol-vere a funzioni medicali.

Le precedenti osservazioni, naturalmente, potranno essere recepite e tradotte in vin-coli e obblighi solo a seguito di un intervento di regolamentazione che tenga conto delle caratteristiche peculiari di una APP e di quelle del dispositivo sul quale opera, compresi eventuali sensori e periferiche impiegati.

4.2. Validazione integrata APP – Dispositivo – PerifericheUna seconda considerazione, riguarda il fatto che, sempre più spesso, una APP Sa-nitaria, oltre al normale utilizzo del dispositivo mobile sul quale è attivata, richiede la disponibilità di periferiche, connesse al predetto dispositivo, per lo sviluppo di funzionalità aggiuntive (rilevazione di foto o immagini, rilevazione di pressione, ac-quisizione dati da elaborare, ecc.).

È evidente che, in situazioni di questo genere, il corretto funzionamento della APP in esame dipenda anche dallo specifico dispositivo mobile sul quale quest’ultima sta operando (marca, modello, configurazione, ecc.) e dalla periferica o dal sensore even-tualmente impiegati 25.

Da ciò emerge evidente l’ulteriore necessità di integrare l’impianto normativo vi-gente con indicazioni e prescrizioni specifiche, che individuino procedure di verifica e controllo ad hoc volte a garantire il controllo unitario delle componenti che concor-rono al funzionamento di una APP Sanitaria: la stessa APP Sanitaria, il dispositivo mobile, le periferiche impiegate, gli eventuali sensori.

24 Con questo termine si vuole indicare l’insieme delle funzionalità, delle performance e dei risultati trattati o prodotti da una APP.

25 A titolo di esempio, si pensi al caso di una APP intrinsecamente e funzionalmente corretta (e, quin-di, singolarmente certificabile) che dia luogo però a malfunzionamenti o risultati errati dovuti a problemi di incompatibilità tra il dispositivo mobile e la periferica o il sensore impiegati.


4.3. Il processo di sviluppo delle APPS SanitarieUna ulteriore considerazione deriva dall’analisi dei processi di sviluppo e diffusione delle APPS Sanitarie, che rivela come un significativo numero di Produttori sia costi-tuito da persone26, spesso in possesso di un elevato livello di capacità e competenze tecniche, che procedono alla realizzazione di software attraverso una (non sempre adeguata) collaborazione con strutture e/o operatori del settore.

Quanto sopra premesso, si osserva che:• laddove lo sviluppo di una componente SW venga curato da una Azienda27, si può

presumere che, per ovvie esigenze di mercato, quest’ultima possa (ed abbia l’inte-resse a) garantire:

− l’aggiornamento professionale del proprio Personale, per assicurare la capaci-tà di intervento su nuove tematiche e nuove tecnologie di mercato;

− l’adozione di un ciclo di vita del software28 conforme a standard, con appli-cazione di processi produttivi certificati29 e la realizzazione di prodotti con adeguati livelli di qualità e sicurezza;

• viceversa, nel caso in cui lo sviluppo SW sia effettuato da uno Specialista, anche se con adeguata preparazione e competenza tecnica, è ragionevole ipotizzare che egli:

− applichi processi produttivi non certificati30, considerando che una certifica-zione richiede quasi sempre la disponibilità di ruoli e responsabilità tipici di una struttura organizzativa;

− possa non essere costantemente aggiornato su tutti gli aspetti (anche norma-tivi e regolamentari) di qualità e sicurezza che devono invece caratterizzare necessariamente un prodotto (specie se rivolto al settore sanitario);

26 Ci si riferisce a specialisti (liberi professionisti) con adeguate conoscenze e competenze professionali.27 Ci si riferisce ad organizzazioni finalizzate all’esercizio in forma associata dell’attività di impresa (a

titolo di esempio, una software house, un system integrator o analoghi soggetti commerciali).28 Ci si riferisce all’insieme delle attività che vanno sotto il nome di SW development life cycle29 A riprova di tale assunzione, si richiama quanto espresso in Proposal for a regulation of the euro-

pean parliament and of the council on medical devices, and amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009, ove in Annex I: General safety and performance requirements – Par. 14: Software incorporated in devices and standalone software, si legge:

− 14.1. Devices that incorporate electronic programmable systems, including software, or standalone software that are devices in themselves, shall be designed to ensure repeatability, reliability and perfor-mance according to the intended use. In the event of a single fault condition, appropriate means shall be adopted to eliminate or reduce as far as possible and appropriate consequent risks.

− 14.2. For devices that incorporate software or for standalone software that are devices in them-selves, the software shall be developed and manufactured according to the state of the art taking into account the principles of development life cycle, risk management, verification and validation.

− 14.3. Software referred to in this Section that are intended to be used in combination with mobile computing platforms shall be designed and manufactured taking into account the specific features of the mobile platform (e.g. size and contrast ratio of the screen) and the external factors related to their use (varying environment as regards to level of light or noise).

30 A titolo esempio, è difficile immaginare un libero professionista che abbia acquisito (e mantenga nel tempo) la certificazione ISO 9001:2008 per il processo di sviluppo e manutenzione di SW applicativo in campo medico.

66 formit - unint

− possa avere difficoltà a garantire un servizio di supporto e manutenzione-31costante nel tempo;

− possa avere difficoltà a garantire il mantenimento della conoscenza tecnica necessaria per assicurare, nel tempo, i necessari aggiornamenti del software realizzato, sia con riferimento ad aspetti tecnologici (es.: diffusione di nuove piattaforme mobile) che di settore specialistico (es.: nuovi concetti e/o indi-rizzi nel settore medico terapeutico)32;

• l’eventuale rigorosa applicazione del quadro normativo e regolamentare attuale33 comporterebbe oggi una fortissima penalizzazione degli specialisti sopra citati34, con conseguente immediata dispersione di un significativo (e, spesso, validissimo) bagaglio di competenze ed esperienze tecniche e professionali e con altrettanto significative penalizzazioni di livello occupazionale, in un momento in cui, tale aspetto, riveste una particolare criticità per il Sistema Paese;È evidente l’importanza di definire modalità operative e procedurali specifiche,

che, tenendo conto delle peculiarità che caratterizzano il mondo delle APPS, possano assicurare una adeguata vigilanza sulle attività svolte dai suddetti specialisti, in modo da valorizzare il loro operato, pur garantendo un adeguato controllo sulla realizzazio-ne e sulla manutenzione, nel tempo, di prodotti sicuri e di qualità.

4.4. Le attività per la governance delle APPS SanitarieLa governance del fenomeno APPS Sanitarie può essere assicurata esclusivamente prevedendo la costituzione di strutture organizzative che, anche grazie al supporto di adeguati sistemi informatici, possano assicurare l’espletamento delle attività necessa-rie per assicurare un adeguato livello di sicurezza alla progettazione, realizzazione e diffusione delle APPS Sanitarie. Premesso che l’approfondimento di questo specifico tema esula dagli obiettivi del presente Studio, in questa sede si possono comunque anticipare alcune delle attività (o servizi) necessarie per gli scopi sopra indicati.

• Analisi del mercato – L’efficace governo di un determinato fenomeno non può assolutamente prescindere da una approfondita osservazione delle modalità con le quali il fenomeno stesso evolve nel tempo. Nel caso in esame, pertanto, è auspi-

31 A titolo di esempio, si pensi alle oggettive difficoltà che dovrebbe affrontare un libero professio-nista nell’assicurare, nel tempo e senza adeguati supporti ed aiuti esterni, una attività di manutenzione correttiva, necessaria a fronte di possibili malfunzionamenti del SW da lui realizzato, ovvero di manuten-zione adeguativa, a fronte, ad esempio, di innovazioni normative.

32 A differenza di quanto avverrebbe nel caso di una Azienda, un libero professionista che abbandoni il mercato (per qualsivoglia motivo personale, di salute, di trasferimento all’estero, ecc.) comporterebbe oggi una seria difficoltà per la gestione del software da lui prodotto e presente sul mercato, in tutti i casi che richiedano la necessità di intervento sul software stesso (manutenzione, evoluzione, ecc.) o sulla documentazione associata.

33 Che prevede esclusivamente una richiesta di attestati e certificazioni (qualità, sicurezza, ecc.)34 Per le difficoltà citate che avrebbe un libero professionista nel garantire processi certificati.


cabile che venga avviata un’attività di monitoraggio del mercato, tesa a rilevare gli indirizzi, gli sviluppi, le novità e quant’altro, più in generale, caratterizzi il trend evolutivo al quale sono soggette le APPS Sanitarie, i dispositivi mobili, con relativi sensori e periferiche, nonché, le eventuali ulteriori apparecchiature elettroniche che possano interagire con un’APP Sanitaria. Infine, oltre agli aspetti sopra citati, quest’attività potrà contribuire efficacemente ad una attenta verifica delle linee di sviluppo dei Dispositivi Mobili, al fine di segnalare tempestivamente eventuali ele-menti di attenzione e/o opportunità che possano correlarsi con eventuali elementi innovativi nella destinazione d’uso degli stessi.

• Diffusione delle informazioni – Un ulteriore elemento chiave di successo è rap-presentato dalla possibilità di concentrare in un unico punto, esposto su internet e di libero accesso, tutte le informazioni, i dati e i documenti che concorrono a caratterizzare il fenomeno APPS Sanitarie. In particolare, questa esigenza potrà risolversi con la realizzazione del Registro APPS Sanitarie, già più volte citato nei precedenti paragrafi dello Studio, e con una successiva attività di gestione opera-tiva dello stesso, che possa presidiare efficacemente i servizi che il Registro stesso erogherà ai suoi utenti (operatori del settore e cittadini), curando anche (ove ciò fosse realizzato pro-futuro) le eventuali interazioni con altri sistemi informativi già in uso (es: Banca Dati nazionale, Sistema di gestione incidenti, ecc.).

• Supporto agli sviluppatori – Sulla base di quanto già espresso in precedenza, è evidente l’importanza che potrebbe assumere un servizio di supporto erogato a favore degli sviluppatori di APPS Sanitarie (sia specialisti che aziende). Anche in questo caso, il Registro APPS Sanitarie potrebbe costituire un valido strumento di supporto, con un ruolo sia informativo (per la diffusione di dati, documenti e informazioni afferenti le modalità più efficaci per procedere allo sviluppo in qualità di una APP Sanitaria) che operativo (per l’eventuale aiuto pratico che potrebbe essere erogato agli sviluppatori – specie se singoli specialisti – nella predisposizione della documentazione necessaria per la certificazione della APP in esame).

• Procedure di Test di APPS Sanitarie – Ad oggi il processo di certificazione di un Dispositivo Medico è completamente regolamentato dalla normativa vigente (mar-chio CE) e, di conseguenza, completamente regolamentato è anche il processo di certificazione di una APP Sanitaria, considerando quest’ultima assimilabile ad un Dispositivo Medico. Pur tuttavia, appare evidente, anche in questo caso, la neces-sità di integrare le attuali procedure di verifica e validazione con tutta una serie di test tesi a controllare gli aspetti peculiari che caratterizzano una APP Sanitaria quando opera su un dispositivo mobile e/o su periferiche o sensori collegati al dispositivo stesso. Ciò premesso, è necessario:

− definire l’insieme delle procedure di test (soprattutto in tema di sicurezza) che dovranno essere effettuate dai Produttori per assicurare una APP Sanitaria sufficientemente sicura e qualitativamente adeguata;

68 formit - unint

− definire i nuovi processi di verifica e validazione che dovranno essere effet-tuati per la certificazione (ancora a marchio CE) di una APP Sanitaria (questi aspetti, naturalmente, daranno luogo a tempi di attuazione molto lunghi in quanto necessitano di una condivisione a livello europeo).

4.5. Necessità di aggiornamento normativoSulla base di quanto anticipato nei precedenti paragrafi, un’ultima considerazione riguarda l’evidente necessità di prevedere un aggiornamento del quadro normativo che possa:• mantenere inalterate le attuali prescrizioni afferenti i dispositivi medici, al fine di

evitare l’apporto di significativi stravolgimenti in un settore (appunto, quello dei dispositivi medici) che appare già compiutamente regolamentato, con procedure di sorveglianza e vigilanza già diffusamente applicate;

• definire un nuovo contesto di applicazione, specifico per le APPS Sanitarie e ca-ratterizzato da aspetti e procedure regolamentari che tengano in debita considera-zione le peculiarità proprie di questo tipo di SW e dello scenario in cui lo stesso si sviluppa.

Ciò premesso, è evidente la necessità che queste nuove norme considerino, diretta-mente nel loro contesto operativo:• le APPS Sanitarie, con le specificità tecniche che le caratterizzano e le distinguono

da altre tipologie di SW (stand-alone o meno): in questa analisi, naturalmente, dovranno essere considerati anche gli apparati tecnologici che ospitano le APPS (smartphone, tablet, ecc.), nonché i sistemi operativi che li corredano (Android, ecc.) e le diverse periferiche utilizzabili;

• gli Sviluppatori di APPS Sanitarie, soprattutto quando questi ultimi siano rap-presentati da singoli specialisti, comunque portatori di un significativo bagaglio di esperienza e competenza professionale, che deve essere valorizzato pur in un contesto di adeguato controllo e sicurezza.

4.6. Conclusioni

Le considerazioni richiamate sono quelle sulle quali, principalmente, si focalizza il presente studio e, in particolare, la soluzione tecnico-organizzativa proposta.

5. Proposte

5.1. Proposta di definizione di APP SanitariaCome già accennato in apertura dello Studio, l’analisi e la progettazione delle proce-dure tecniche e normative di regolamentazione delle APPS Sanitarie non può prescin-dere dalla preliminare definizione di cosa deve rientrare nel perimetro dello Studio e con quali criteri. A tal proposito, sono state già espresse alcune considerazioni (che si riportano qui di seguito per maggior chiarezza) che riguardano i criteri e i razionali che devono porsi alla base della definizione di APP Sanitaria, che deve:• considerare le altre definizioni e tassonomie già in essere in campo medico, al

fine di privilegiare, ove possibile, l’uso, anche semantico, di concetti e notazioni già consolidati;

• considerare le attuali categorie di rischio, in modo tale da privilegiare, ove possibi-le, la loro applicazione nel contesto delle APPS Sanitarie, eventualmente integrata da nuovi elementi;

• prevedere modalità di verifica e controllo specifiche per le APPS Sanitarie, cosic-ché, ove possibile, siano mantenute inalterate le procedure attuali, garantendo la continuità operativa ed il mantenimento delle conoscenze e competenze di tutti gli Attori coinvolti;

• tener conto delle finalità d’uso delle APPS Sanitarie, in quanto rilevanti ai fini dei rischi associati alla salute e al benessere del cittadino.

Quanto sopra premesso, si propone di definire APP Sanitaria:

Una qualunque applicazione software, operante su un dispositivo mobile (smar-tphone, tablet, ecc.), con o senza eventuali periferiche, utilizzata per il tratta-mento di dati utili alle attività di diagnosi, prevenzione, controllo, terapia di un paziente, effettuate con o senza l’impiego di formule e algoritmi, ivi compresa la semplice visualizzazione o la trasmissione di dati sanitari.

70 formit - unint

In particolare, con riferimento alla definizione sopra richiamata, la successiva Tabella 1 presenta le principali funzionalità che possono essere espletate da una APP Sanitaria. L’elenco è di tipo gerarchico e, ad ogni funzione principale (prima colonna a sinistra), associa una o più funzioni secondarie (Funzioni di 2° livello) ed ulteriori opzioni che specificano (ove presenti) particolari modalità di funzionamento, quali, ad esempio, il mantenimento o meno del formato originale dei dati trattati e la manipolazione degli stessi, ossia l’esecuzione di un algoritmo di elaborazione applicato ai dati trattati.

FUNZIONI PRINCIPALI FUNZIONI DI 2° LIV OPZIONI

Acquisizione datiManuale

Automatico*

Memorizzazione datiSu dispositivo mobile Stesso formato / Altro Formato

Su periferica esterna Stesso formato / Altro Formato

Elaborazione e analisiSolo dispositivo mobile

Tramite periferica esterna

Visualizzazione dati Con / senza funzioni di aggregazione (viste) Stesso formato / Altro Formato

Trasmissione dati Con / senza funzioni di sicurezza (es.: cifratura) Stesso formato / Altro Formato

Comando azione Su Dispositivo medico

Invio di allerta Su Dispositivo medico

* Possibili fonti sono: sensori esterni, sensori interni, DB interni (dell’APPS), DB esterni.

Tabella1–TassonomiadellefunzioniespletatedaunaAPPSanitaria

5.2. Proposta di classificazione del rischioLa Tabella 1 illustra dei percorsi tassonomici che portano ad identificare diverse tipo-logie di APPS, in relazione alle funzioni espletate (principali e di 2° livello) nonché alle opzioni specifiche che vengono applicate. Lo sviluppo di tali percorsi influenza la valu-tazione del rischio associato alla APP in esame: è evidente, infatti, la differente perico-losità che sussiste tra una prima APP che acquisisce dati sanitari e li ritrasmette (magari ad un operatore di settore, medico o altro soggetto), senza però effettuare alcuna elabora-zione o modifica di formato, ed una seconda APP che, acquisiti i medesimi dati sanitari, effettua su questi elaborazioni più o meno complesse e presenti dei risultati al paziente (sul visore del dispositivo mobile) inviandoli contemporaneamente ad un medico.

Seguendo la filosofia che ha delineato l’elaborazione dello studio fin dalle sue prime pagine, anche nella classificazione del rischio si è scelto di avvicinare il più possibile il trattamento delle APPS Sanitarie a quello già oggi adottato per i Dispositivi medici, evidenziando (ove opportuno o necessario) le eventuali differenze e le integrazioni da considerare. Ciò premesso, la proposta35 di seguito illustrata si basa sulle categorie di ri-

35 Attenzione: le scelte effettuate devono sempre e comunque essere considerate proposte sperimen-tali che, in quanto tali, necessitano sia di un periodo di test operativo, teso a consolidare o integrare


schio già definite nel il D. Lgs. 24 febbraio 1997, n. 46 (nel seguito, per brevità, indicato ancora come “Decreto”), relativamente ai Dispositivi Medici, e ne estendono e partico-larizzano l’applicazione alle APPS Sanitarie. Nel dettaglio le classi sono così definite36:

• Classe I: APPS Sanitarie a basso rischioQuesta categoria comprende tutte quelle applicazioni software che effettuano:

− acquisizione dati, anche in modo automatico, da eventuali fonti/periferiche esterne;

− memorizzazione dati, su dispositivo mobile o su periferica esterna;− visualizzazione dati (senza funzioni di aggregazione o viste);− misurazioni;− trasmissione dati,

senza alcuna elaborazione o modifica di formato dei dati acquisiti/trattati.Il basso rischio deriva essenzialmente da una scarsa possibilità che venga perso

o modificato in modo inadeguato il contenuto informativo associato ai dati sanitari originali.

• Classe II – A: APPS Sanitarie a medio rischioQuesta categoria comprende tutte quelle applicazioni software che interagiscono con il corpo umano in maniera non pericolosa. Comprende tutte quelle applicazioni software che effettuano:

− acquisizione e/o memorizzazione e/o visualizzazione e/o trasmissione di dati sanitari con cambio del formato originario;

− controllo di sensori e periferiche con acquisizione e visualizzazione di risultati aggregati (risultati di misure effettuati su funzioni biologiche).

• Classe II – B: APPS Sanitarie a rischio medio – altoQuesta categoria comprende tutte quelle applicazioni software che interagiscono con il corpo umano in maniera pericolosa, in quanto effettuano rilevazione, elaborazione ed analisi di dati sanitari anche critici. Comprende le applicazioni software che effet-tuano elaborazione e analisi con:

− produzione di dati complessi o aggregati a partire da dati sanitari semplici, ac-quisiti in modo manuale o automatico, anche mediante l’ausilio di collegamenti telematici o sensori o periferiche esterne, pilotate o meno dalla APP in esame;

− produzione di risultati specifici finalizzati ad diagnosi, prevenzione, controllo o terapia del paziente, effettuata attraverso acquisizione manuale o automati-ca di dati sanitari semplici, anche mediante l’ausilio di collegamenti telematici o sensori o periferiche esterne, pilotate o meno dalla APP in esame.

quanto definito, sia di una attività specifica di verifica e validazione effettuata dai competenti Organi dell’Amministrazione.

36 Viene omessa la classe Is (dispositivi di classe I forniti allo stato sterile) n quanto non applicabile.

72 formit - unint

• Classe III: APPS Sanitarie a rischio altoQuesta categoria comprende tutte quelle applicazioni software finalizzate a interagire (ossia a controllare, scambiare dati o segnali, ecc.) con

− dispositivi medici impiantabili;− periferiche volte ad effettuare rilevazioni, elaborazioni ed analisi di funzioni

vitali.

5.3. Proposta di definizione delle Procedure di testIn linea con gli obiettivi che lo Studio si prefigge, di seguito viene affrontato il pro-blema dei test, ai quali è necessario sottoporre una APP Sanitaria per procedere alla sua validazione.

Si precisa che le procedure di test e validazione proposte:• nulla hanno a che vedere con la Certificazione CE al momento regolata dalla nor-

mativa vigente;• non hanno carattere di cogenza;• nell’ambito del progetto sperimentale delineato nel presente Studio, costituiscono

potenziali servizi resi direttamente ai Produttori/Sviluppatori di APPS Sanitarie, in un’ottica di adesione spontanea e volontaria, finalizzata al possibile migliora-mento qualitativo dell’APP in esame;

• contengono test tipicamente derivati dai sistemi software critici (es.: sistemi mis-sion critical) e si sviluppano su due dimensioni, orizzontale e verticale, dipendenti dalla Classe di rischio associata alla APP in esame. In particolare:

− la dimensione orizzontale riguarda gli argomenti e le tematiche che devono essere sottoposti a procedura di test. I test si sviluppano su diverse categorie (funzionale, strutturale e di sicurezza) con una estensione di argomenti che aumenta con l’aumentare della rischiosità dell’APP stessa;

− la dimensione verticale riguarda il livello di approfondimento e di accettabili-tà di ciascun test (o tipologia di test) e diventa via via più stringente all’aumen-tare della rischiosità dell’APP stessa.

• sono effettuate sempre dallo Sviluppatore in relazione alle rischiosità dell’APP in esame (che identifica le procedure di test, le tematiche di interesse ed il livello di approfondimento). I test effettuati (in termini di: ambiente di test, prove di test effettuate, risultati ottenuti) devono essere documentati dallo Sviluppatore ed alle-gati agli altri documenti richiesti nella procedura di validazione.

• almeno con riferimento alle APPS Sanitarie di maggior rischiosità, devono preve-dere test strutturali e di sicurezza che interessano anche il dispositivo mobile sul quale la APP opera e, ove impiegate, tutte le periferiche e/o i sensori utilizzati.


È opportuno precisare che, in linea con la filosofia che ha guidato fin qui lo Stu-dio, le procedure di test di seguito illustrate hanno carattere indicativo e non cogente, in quanto definite nell’ambito di un progetto sperimentale. Pertanto, pur costituendo una base di partenza molto articolata e dettagliata, le procedure descritte dovranno essere analizzate nelle opportune sedi, per valutare l’oppor-tunità di un eventuale recepimento delle stesse in un nuovo contesto normativo finalizzato a regolare specificamente le APPS Sanitarie.

Quanto sopra premesso, si riporta di seguito una proposta di procedure di test, sud-divise per tematica:• test funzionali;• test strutturali;• test di sicurezza;• test di protezione dei dati personali e sensibili.

5.3.1. Test funzionaliScopo principale dei test funzionali è quello di validare le caratteristiche esterne del software direttamente legate al suo utilizzo da parte degli utenti o dei gestori appli-cativi.

• Test delle funzionalitàVerificano che l’applicativo sviluppato:

− risponde a tutti i requisiti funzionali espressi e rispetta le caratteristiche presta-zionali;

− esegue le funzionalità in modo coerente ed accurato;− elabora le informazioni coerentemente con le politiche, gli standard e le proce-

dure dichiarate;− produce risultati testabili e ripetibili.

• Test di gestione delle condizioni di erroreVerificano che l’applicativo sviluppato:

− intercetta e gestisce opportunamente tutte le condizioni ragionevoli di errore;− gestisce in maniera appropriata le condizioni di errore intercettate e assicura la

continuità delle operazioni (solo se necessario, provvederà alla chiusura ordina-ta ed in sicurezza dell’applicativo);

− esegue opportuni controlli a fronte delle correzioni eseguite.

74 formit - unint

• Test di operativitàI Test di operatività verificheranno che:

− tutti i componenti del sistema e le procedure sono disponibili ed operativi;− tutti i comandi online sono disponibili e funzionano correttamente;− tutte le informazioni relative alla schedulazione dei lavori sono corrette;− la documentazione tecnica è completa e precisa.

• Test di installazioneVerificano che l’applicativo sviluppato:

− consente all’utente di effettuare l’installazione seguendo le istruzioni allagate; − sia corredato di adeguata documentazione che descrive gli ambienti hardware e

software necessari per effettuare e completare l’installazione; − può essere rimosso completamente e in modo automatico dal dispositivo mobile.

• Test di regressioneVerificano che la nuova versione dell’applicativo sviluppato:

− continua a funzionare dopo le modifiche di aggiornamento funzionale (nuove funzionalità);

− non viene interessato negativamente da eventuali modifiche successive apporta-te ad una precedente versione consolidata dell’applicativo stesso.

• Test di paralleloVerificano che la nuova versione dell’applicativo sviluppato:

− dia gli stessi risultati di quelli forniti dalla precedente versione (si presuppone che quest’ultima fornisca risultati corretti);

− si differenzi dalla precedente versione in termini migliorativi (introduzione di nuove funzioni o caratteristiche).

• Test di usabilitàVerificano che l’applicativo sviluppato:

− risulta semplice, intuitivo e facile da utilizzare anche da parte di utenti non esperti;− le schermate e gli output sono concisi e facili da interpretare;− le funzioni help online risultano semplici ed esaustive;− l’immissione dei dati di input risulta semplice, intuitiva e naturale.

• Test della documentazioneVerificano che l’applicativo sviluppato sia corredato di documentazione:

− Completa: la documentazione deve includere la descrizione della procedura di installazione, se è previsto che l’utente possa effettuarla; se la documentazione è in più documenti, deve essere fornita una guida ed un indice; la documenta-zione allegata (di installazione, uso, manutenzione etc..) è conforme alla norma;


− Corretta: la documentazione non deve contenere ambiguità od errori;− Consistente: la documentazione non deve contenere contraddizioni; ogni ter-

mine usato deve avere lo stesso significato in ogni documento allegato;− Comprensibile: la documentazione deve essere facilmente comprensibile;− Apprendibile: la documentazione deve facilitare l’apprendimento dell’uso del

software.

5.3.2. Test strutturaliIl test strutturale esamina le caratteristiche interne dell’applicazione software (APP) in esame, al fine di verificare che:

− la progettazione sia corretta dal punto di vista tecnico ed architetturale;− le tecnologie utilizzate siano state impiegate in modo corretto e coerente;− i componenti siano stati progettati in modo da risultare coesi e disaccoppiati;− le singole parti dell’applicazione funzionino come un insieme unico una volta

integrate.Nota: in questa specifica categoria di test, quando si parla di Dispositivo mobile ci si riferisce

genericamente all’insieme del dispositivo vero e proprio (smartphone, tablet, ecc.) e della periferica o sensore utilizzati per lo svolgimento delle funzionalità Sanitarie

• Test di ripristinoVerificano che l’applicativo sviluppato:

− tramite apposite procedure di backup/restore, garantisce la salvaguardia dei dati e che questi ultimi sono effettivamente accessibili e ripristinabili;

− sia corredato di adeguata documentazione che illustra il funzionamento delle procedure di backup/restore, suggerendo all’utente il modo più efficace di sal-vaguardia dei dati.

• Test di affidabilitàVerificano che l’applicativo sviluppato:

− assicuri che il tempo medio intercorrente tra due difetti consecutivi (detto “Mean Time Between Failure” o “MTBF”) sia in linea quanto dichiarato nella documentazione associata;

− in caso blocco del dispositivo mobile, sia in grado di recuperare i dati e le tran-sazioni eseguite con un margine di perdita predefinito e dichiarato nella docu-mentazione associata.

• Test di portabilitàVerificano che l’applicativo sviluppato:

− è in grado di funzionare correttamente su diversi dispositivi mobili con configu-razione predefinita e dichiarata nella documentazione associata.

76 formit - unint

5.3.3. Test di sicurezzaI Test di sicurezza verificheranno che l’applicazione non consenta l’utilizzo delle sue funzionalità in modo malevolo o a vantaggio di un potenziale attaccante. L’applicazio-ne dei test di sicurezza prevede:

• Test di vulnerabilitàVerificano che l’applicativo sviluppato sia corredato di:

− valutazione delle minacce e delle vulnerabilità potenziali di una APP, in relazio-ne alle specifiche tecnologie utilizzate;

− analisi dei rischi derivati e definizione delle misure di sicurezza da applicare;− esecuzione dei test di tipo White Box (Security Code Review) e Black Box (Pe-

netration Test) per controllare che le misure di sicurezza implementate non siano eluse o alterate;

− verifica il livello effettivo di sicurezza della applicazione individuando il rischio residuo in relazione ai requisiti di sicurezza previsti.

• Test di performanceVerificano che l’applicativo sviluppato:

− abbia effettivamente le prestazioni dichiarate (tempi di risposta, utilizzo delle risorse, quantità di lavoro nell’unità di tempo), quando utilizzato sul dispositivo mobile con configurazione predefinita;

− continui a funzionare correttamente anche in presenza di una chiamata in arri-vo alla quale l’utente non risponde37.

• Test di caricoVerificano che l’applicativo sviluppato, una volta installato sul dispositivo mobile (de-finito in termini di marca, modello e, ove applicabile, configurazione):

− è in grado di elaborare il numero di transazioni previste nell’intervallo di tempo stabilito;

− mantiene il livello di performance dichiarate anche in presenza di una chiamata in arrivo alla quale l’utente non risponde (vedi nota precedente).

5.3.4. Test di protezione dei dati personali e sensibiliQuest’ultima categoria di test, di notevole importanza per la specifica tipologia di dati trattati da una APP Sanitaria (dati sanitari e quindi sensibili), saranno finalizzati a ve-rificare che l’applicazione software (per quanto di pertinenza ed applicabile) rispetti

37 Questo aspetto è fondamentale, in quanto l’APP medica in esame, pur non potendo inibire la ricezione di chiamate telefoniche, può presentare all’utente un messaggio video che lo invita a non ri-spondere alle eventuali chiamate che dovessero pervenire durante il periodo di funzionamento dell’APP stessa e fino alla sua conclusione.


tutti gli adempimenti dettati dal D. Lgs. 30 giugno 2003, n. 196 (Codice in materia di protezione dei dati personali), nonché dalle successive modificazioni ed integrazioni, con particolare a quanto prescritto , art. 34 (Trattamenti con strumenti elettronici), che recita:

...1. Il trattamento di dati personali effettuato con strumenti elettronici è consentito solo

se sono adottate, nei modi previsti dal disciplinare tecnico contenuto nell’allegato B), le seguenti misure minime :a) autenticazione informatica; b) adozione di procedure di gestione delle credenziali di autenticazione; c) utilizzazione di un sistema di autorizzazione; d) aggiornamento periodico dell’individuazione dell’ambito del trattamento consen-

tito ai singoli incaricati e addetti alla gestione o alla manutenzione degli strumenti elettronici;

e) protezione degli strumenti elettronici e dei dati rispetto a trattamenti illeciti di dati, ad accessi non consentiti e a determinati programmi informatici;

f) adozione di procedure per la custodia di copie di sicurezza, il ripristino della dispo-nibilità dei dati e dei sistemi;

g) Abrogato38; h) adozione di tecniche di cifratura o di codici identificativi per determinati trat-

tamenti di dati idonei a rivelare lo stato di salute o la vita sessuale effettuati da organismi sanitari;

1-bis. Abrogato39

1-ter. Ai fini dell’applicazione delle disposizioni in materia di protezione dei dati perso-nali, i trattamenti effettuati per finalità amministrativo-contabili sono quelli connessi allo svolgimento delle

attività di natura organizzativa, amministrativa, finanziaria e contabile, a prescindere dalla natura dei dati trattati. In particolare, perseguono tali finalità le attività organizza-tive interne, quelle funzionali all’adempimento di obblighi contrattuali e precontrattua-li, alla gestione del rapporto di lavoro in tutte le sue fasi, alla tenuta della contabilità e all’applicazione delle norme in materia fiscale,

sindacale, previdenziale-assistenziale, di salute, igiene e sicurezza sul lavoro.

5.4. Proposte di carattere normativoIl fenomeno delle APPS Sanitarie, analiticamente esaminato nei precedenti capitoli dello Studio, ha evidenziato, in sintesi, un sostanziale disallineamento degli aspetti

38 Lettera soppressa dalla lettera c) del comma 1 dell’art. 45, D.L. 9 febbraio 2012, n. 5.39 Il comma 1-bis è stato abrogato dalla lettera c) del comma 1 dell’art. 45, D.L. 9 febbraio 2012, n. 5.

78 formit - unint

normativi rispetto a quelli tecnologici: infatti, emerge chiaramente che l’eventuale avvio di un processo di integrazione ed adeguamento dell’attuale quadro normativo (iniziativa che richiede quantomeno il coinvolgimento di organismi a livello euro-peo) richiede tempi e ritmi molto più lenti e inadeguati, se confrontati con la rapi-dissima crescita tecnologica che, in questo momento, caratterizza lo sviluppo delle APPS Sanitarie, dei dispositivi mobili e dei relativi sensori. D’altra parte, lo Studio ha chiaramente evidenziato la sostanziale inadeguatezza dell’attuale quadro nor-mativo nel governare un fenomeno di recente sviluppo quale è quello delle APPS Sanitarie, per tutta una serie di motivazioni e di elementi di attenzione che sono stati più volte evidenziati nelle precedenti sezioni dello Studio.

Tutto ciò porta ad una situazione di particolare attenzione, dalla quale emerge che:• lo sviluppo tecnologico delle APPS (ivi comprese, quindi, quelle finalizzate al

settore sanitario) è sollecitato quasi esclusivamente da regole di mercato che ri-flettono spesso la sola legge della domanda – offerta e sono soggette principal-mente ad interessi di carattere commerciale ed economico;

• molte di queste APPS Sanitarie (in questo momento possiamo considerare APP Sanitarie anche molte applicazioni software liberamente diffuse dagli app store), pur svolgendo effettivamente funzioni di diagnosi, prevenzione, controllo o te-rapia, non risultano certificate (marchio CE) e, per tale motivo, sono semplice-mente esposte in Internet all’interno di app store e sfuggono alle procedure di verifica e controllo che, in linea con la normativa vigente, sono applicabili ai soli dispositivi medici;

• anche quelle (poche) APPS Sanitarie che, in via del tutto eccezionale, richiedono la certificazione CE, sono poi oggetto di attività di verifica e controllo effettuate sulla base di procedure che considerano esclusivamente criteri e parametri pen-sati per i dispositivi medici classici40: pertanto, anche la certificazione CE di una APP Sanitaria, essendo rilasciata con le attuali modalità tecniche e procedurali, non sempre garantisce all’utente-paziente un adeguato livello di qualità e sicu-rezza, a causa della scarsa protezione dagli elementi di criticità più volte eviden-ziati nello Studio;

• l’unica strada al momento percorribile è quella che prevede:− l’avvio immediato di iniziative che, condivise almeno a livello Europeo, pos-

sano rapidamente portare all’integrazione del quadro normativo attuale, at-traverso la definizione di regole procedurali specifiche per la regolamentazio-ne delle APPS Sanitarie;

40 Si utilizza questo termine, anche se in modo anomalo rispetto a definizioni e standard ufficiali, per indicare tutti i dispositivi medici progettati e realizzati già con questa destinazione d’uso, sia in termini di apparati (elettronici, meccanici, pneumatici, ecc.), sia in termini di software installato su tali apparati per il loro controllo.


− la realizzazione immediata di misure e strumenti di supporto che, pur restan-do comunque nei limiti dettati dalle norme attuali e, quindi, senza presunzio-ne di cogenza, possano consentire fin da subito di effettuare piccoli passi in avanti verso l’obiettivo di governo sopra richiamato.

In altre parole:

Negli spazi innovativi in rapida evoluzione, non sono sicuro che la cosa migliore sia attenersi a regole ferree... Dobbiamo fare in modo che la regolamentazione si muova al ritmo dell’innovazione, essendo del tutto inaccettabile che l’innova-zione si muova al ritmo della regolamentazione.

(Joseph Smith, chief medical and science officer for the West Health Institute) libera traduzione

Sulla base delle precedenti considerazioni, di seguito viene delineata una proposta di intervento normativo basata su una ipotesi di integrazione del D. Lgs. 24 febbraio 1997, n. 46, emendato col D. Lgs. 25.01.2010 n.37 – Recepimento Direttiva 2007/47/CE – Attuazione della direttiva 93/42/CEE concernente i dispositivi medici. Si preci-sa che le norme di seguito delineate:• hanno carattere di proposta e, di conseguenza, necessitano di successivi approfon-

dimenti e verifiche da parte dei competenti Organi, anche a livello Europeo;• non possono e non vogliono risultare esaustive rispetto alla tematica trattata, in

quanto elaborate a titolo di esempio e con riferimento ai principali elementi di attenzione già evidenziati nello Studio;

• si riferiscono ad una ipotetica integrazione del suddetto decreto, ma ignorano, volutamente e per semplicità espositiva, gli altri decreti afferenti a:

− i dispositivi medici impiantabili attivi (D. Lgs. 14 dicembre 1992, n. 507, emendato col D. Lgs. 25.01.2010 n.37 – Recepimento Direttiva 2007/47/CE);

− i dispositivi medico-diagnostici in vitro (D. Lgs. 8 settembre 2000, n. 332, emendato col D. Lgs. 25.01.2010 n.37);

• riportano solo articoli e commi integrati o modificati rispetto al suddetto decreto. In particolare:

− le integrazioni di parole e/o termini non sono evidenziate;− le modifiche all’attuale articolato evidenziate con la dicitura “modificato” po-

sta accanto all’articolo o al comma in esame;− gli articoli e i commi non presenti ovvero sostituiti da ...omissis..., si intendono

inalterati rispetto al decreto attuale.

80 formit - unint

ipotesi di integrazione normativa

• D. Lgs. 24 febbraio 1997, n. 46Art. 1 (Definizioni)

1. (modificato). Il presente decreto si applica ai dispositivi medici ed ai relativi accessori, ivi comprese le APPS Sanitarie. Ai fini del presente decreto, gli accessori sono considerati dispositivi medici a pieno titolo. Ai fini del presente decreto, le APPS Sanitarie sono considerate dispositivi medici a pieno titolo, pur caratterizza-te da peculiarità e caratteristiche di volta in volta evidenziate, ove risulti necessario distinguerle dai restanti dispositivi medici. Nel presente decreto e nei suoi allegati i dispositivi medici ed i loro accessori vengono indicati con termine «dispositivi», fatta salva ogni eventuale diversa indicazione di volta in volta evidenziata.

2. (modificato). Ai fini del presente decreto s’intende per:...omissis...a-bis) Dispositivo Mobile: dispositivi elettronici pienamente utilizzabili

dall’utente in condizioni di mobilità e idonei ad ospitare applicazioni software (APPS)

a-ter) APP Sanitaria: una qualunque applicazione software, operante su un dispositivo mobile (smartphone, tablet, ecc.), eventualmente connesso con di-spositivi medici, periferiche o apparecchiature elettroniche esterne, utilizzata per il trattamento di dati utili alle attività di diagnosi, prevenzione, controllo, terapia di un paziente, effettuate con o senza l’impiego di formule e algoritmi, ivi com-presa la semplice visualizzazione o la trasmissione di dati sanitari.

Art. 2 (Campo di applicazione)...omissis...

2-ter. I dispositivi costituiti da una APP Sanitaria installata ed operante su un dispositivo mobile, nonché dalle eventuali periferiche e sensori controllati dalla APP stessa, purché garantiti dal marchio CE in relazione alla loro destinazione d’uso, sono valutati in conformità al presente decreto.

Art. 15 (Organismi designati ad attestare la conformità)...omissis...

5-sexies. Il Ministero della salute, ovvero lo stesso Organismo Notificato previa esplicita autorizzazione del Ministero stesso, provvede ad inserire e mantenere co-stantemente aggiornate all’interno del Registro APP Sanitarie tutte le informazioni sui certificati rilasciati, modificati, integrati, sospesi, ritirati o rifiutati relativi alle APP Sanitarie, con le modalità indicate nelle norme tecniche specifiche di accesso al Registro emesse dal Ministero della Salute.


Art. 16 (Marcatura CE)...omissis...

2 (modificato). La marcatura di conformità CE, corrispondente al simbolo ri-prodotto all’allegato XIII, deve essere apposta in maniera visibile, leggibile ed indelebile sui dispositivi in questione o sul loro involucro sterile, sempre che ciò sia possibile ed opportuno, e sulle istruzioni per l’uso: se del caso la marcatura di conformità CE deve comparire anche sulla confezione commerciale. Nel caso di APP Sanitaria, la marcatura CE deve comparire in maniera visibile, leggibile ed indelebile anche sulla icona attraverso la quale viene attivata l’APP, su tutte le schermate e menu di interfaccia utente, sugli eventuali report o risultati elaborati, nonché su tutte le pagine della documentazione tecnica ed utente che correda l’APP. La marcatura CE deve essere corredata del numero di codice dell’orga-nismo notificato responsabile dell’adozione delle procedure previste agli allegati II, IV, V e VI. Sul dispositivo, sul confezionamento o sul foglio illustrativo che accompagna il dispositivo, può essere apposto qualsiasi altro marchio, purché la visibilità e la leggibilità della marcatura di conformità CE non siano in tale modo ridotte.

• D. Lgs. 24 febbraio 1997, n. 46 – Allegato I – Requisiti essenziali1. (modificato). I dispositivi devono essere progettati e fabbricati in modo che

la loro utilizzazione, se avviene alle condizioni e per gli usi previsti, non compro-metta lo stato clinico o la sicurezza dei pazienti, né la sicurezza e la salute degli utilizzatori ed eventualmente di terzi, fermo restando che gli eventuali rischi asso-ciati all’uso previsto debbono essere di livello accettabile in rapporto ai benefici apportati al paziente e compatibili con un elevato livello di protezione della salute e della sicurezza. Ciò comporta:

− la riduzione, per quanto possibile, dei rischi di errore nell’utilizzazione de-terminato dalle caratteristiche ergonomiche del dispositivo e dall’ambiente in cui è previsto che il dispositivo sia usato (progettazione per la sicurezza del paziente);

− nel caso di APP Sanitaria, la definizione e l’adozione di tutte le misure che, in fase di progettazione, di realizzazione o di successiva gestione del SW, sono finalizzate a ridurre i rischi derivanti:

o dalla diversa destinazione d’uso del dispositivo mobile sul quale la APP opera;

o dal non completo controllo che, in generale, una APP è in grado di eser-citare sul dispositivo mobile e/o sulle periferiche o sensori impiegati;

− la considerazione del livello della conoscenza tecnica, dell’esperienza, dell’i-struzione e della formazione nonché, a seconda dei casi, delle condizioni me-diche e fisiche degli utilizzatori cui il dispositivo è destinato (progettazione per utilizzatori comuni, professionisti, disabili o altro);

82 formit - unint

2. (modificato). Le soluzioni adottate dal fabbricante per la progettazione e la costruzione dei dispositivi devono attenersi a principi di rispetto della sicurezza, tenendo conto dello stato di progresso tecnologico generalmente riconosciuto. Per la scelta delle soluzioni più opportune il fabbricante deve applicare i seguenti prin-cipi, nell’ordine indicato:

− eliminare o ridurre i rischi nella misura del possibile (integrazione della sicu-rezza nella progettazione e nella costruzione del dispositivo);

− se del caso adottare le opportune misure di protezione nei confronti dei rischi che non possono essere eliminati eventualmente mediante segnali di allarme, ovvero, nel caso di APPS Sanitarie mediante messaggi a video che richiedono una espressa conferma di avvenuta lettura (es.: pressione di un tasto);

− informare gli utilizzatori dei rischi residui dovuti a un qualsiasi difetto delle misure di protezione adottate.

3. (modificato). I dispositivi devono fornire le prestazioni loro assegnate dal fabbricante ed essere progettati, fabbricati e condizionati in modo tale da poter espletare una o più delle funzioni di cui all’articolo 1, comma 2, lettera a), ovvero lettera a-ter, nel caso di APPS Sanitarie, quali specificate dal fabbricante.

...omissis...13. Informazioni fornite dal fabbricante

...omissis...13.1-bis Nel caso di APPS Sanitarie, le informazioni necessarie a garantirne

un’utilizzazione appropriata devono essere inserite sia nei menu e nelle schermate dell’applicazione (ove possibile), sia nella documentazione che correda l’applica-zione stessa. Inoltre, informazioni ed istruzioni d’uso devono essere richiamabile attraverso apposite funzioni di help on-line, dipendenti dal contesto e richiamabili dall’utilizzatore mediante appositi tasti funzione

• D. Lgs. 24 febbraio 1997, n. 46 – Allegato VI – Dichiarazione di conformità CE(Garanzia di qualità del prodotto)

3-bis Sistema di sicurezza per le APPS Sanitarie – Procedure di testNel caso specifico di APPS Sanitarie, il fabbricante presenta all’organismo no-

tificato una domanda di valutazione delle misure di sicurezza definite per la rea-lizzazione del software, nonché delle procedure adottate per l’esecuzione specifica dei test di sicurezza. In particolare, dovrà essere fornita adeguata documentazione comprovante l’avvenuta positiva esecuzione di:

− Test di vulnerabilità: Verificano che il software sviluppato sia corredato di:o analisi delle minacce e vulnerabilità potenziali di una APP, in relazione

alle specifiche tecnologie utilizzate;o analisi dei rischi derivati e definizione delle misure di sicurezza da appli-

care;o esecuzione dei test di tipo White Box (Security Code Review) e Black


Box (Penetration Test) per controllare che le misure di sicurezza imple-mentate non siano eluse o alterate;

o verifica il livello effettivo di sicurezza della applicazione individuando il rischio residuo in relazione ai requisiti di sicurezza previsti.

− Test di performance: Verificano che il software sviluppato:o abbia effettivamente le prestazioni dichiarate (tempi di risposta, utilizzo

delle risorse, quantità di lavoro nell’unità di tempo), quando utilizzato sul dispositivo mobile con configurazione predefinita;

o funzioni correttamente anche in presenza di una chiamata in arrivo.− Test di carico: Verificano che il software, una volta installato sul dispositivo

mobile (definito in termini di marca, modello e, ove applicabile, configurazio-ne):

o è in grado di elaborare il numero di transazioni previste nell’intervallo di tempo stabilito;

o mantiene il livello di performance dichiarate anche in presenza di una chiamata in arrivo.

− Test di conformità al Codice in materia di protezione dei dati personali: ve-rificare che il software sviluppato (per quanto di pertinenza ed applicabile) rispetti tutti gli adempimenti dettati dal D. Lgs. 30 giugno 2003, n. 196 (Co-dice in materia di protezione dei dati personali), nonché dalle sue successive modificazioni ed integrazioni.

• D. Lgs. 24 febbraio 1997, n. 46 – Allegato IX – Criteri di classificazione...omissis...

3-bis. Regole aggiuntive applicabili alle APPS Sanitarie3-bis.1 Regola 12-bisLe APPS Sanitarie utilizzate per gestire, pilotare o controllare un dispositivo

medico o un accessorio assumono la medesima categoria del dispositivo medico o dell’accessorio;

3-bis.2 Regola 12-terLe APPS Sanitarie che non rientrano nel precedente caso e rispondono alla

definizione di cui al precedente Art. 1, comma 2, punto a-ter, rientrano nelle seguenti classi di rischio:

− Classe I: APPS Sanitarie a basso rischio.Questa categoria comprende tutte quelle APPS che effettuano:

o acquisizione dati, anche in modo automatico, da eventuali fonti/peri-feriche esterne;

o memorizzazione dati, su dispositivo mobile o su periferica esterna;o visualizzazione dati (senza funzioni di aggregazione o viste);o misurazioni;o trasmissione dati,

84 formit - unint

senza alcuna elaborazione o modifica di formato dei dati acquisiti/trat-tati.

Il basso rischio deriva essenzialmente da una scarsa possibilità che ven-ga perso o modificato in modo inadeguato il contenuto informativo asso-ciato ai dati sanitari originali.

− Classe II – A: APPS Sanitarie a medio rischioQuesta categoria comprende tutte quelle applicazioni software che in-

teragiscono con il corpo umano in maniera non pericolosa. Comprende tutte le APPS che effettuano:

o acquisizione e/o memorizzazione e/o visualizzazione e/o trasmissione di dati sanitari con cambio del formato originario;

o controllo di sensori e periferiche con acquisizione e visualizzazione di risultati aggregati (risultati di misure effettuati su funzioni biologi-che).

− Classe II – B: APPS Sanitarie a rischio medio – altoQuesta categoria comprende tutte quelle applicazioni software che in-

teragiscono con il corpo umano in maniera pericolosa, effettuando rileva-zione, elaborazione ed analisi di dati sanitari, anche critici, con:

o produzione di dati complessi o aggregati a partire da dati sanitari sem-plici, acquisiti in modo manuale o automatico, anche mediante l’ausi-lio di collegamenti telematici o sensori o periferiche esterne, pilotate o meno dalla APP in esame;

o produzione di risultati specifici finalizzati ad diagnosi, prevenzione, controllo o terapia del paziente, effettuata attraverso acquisizione ma-nuale o automatica di dati sanitari semplici, anche mediante l’ausilio di collegamenti telematici o sensori o periferiche esterne, pilotate o meno dalla APP in esame.

− Classe III: APPS Sanitarie a rischio altoQuesta categoria comprende tutte quelle applicazioni software finaliz-

zate a interagire (ossia a controllare, scambiare dati o segnali, ecc.) con pe-riferiche volte ad effettuare rilevazioni, elaborazioni ed analisi di funzioni vitali del corpo umano.

6. Una ipotesi di Registro delle APPS Sanitarie

6.1. PremessaCome più volte anticipato nei precedenti Capitoli, lo Studio ha analizzato il fenomeno delle APPS Sanitarie e, alla luce dei risultati emersi da una analisi della situazione attuale, ha provveduto a:• impostare una proposta di definizione di APP Sanitaria per l’identificazione e la

caratterizzazione di tali applicazioni software;• delineare i principali elementi di attenzione che caratterizzano la progettazione, la

realizzazione e la diffusione di tali APPS• definire una mappa concettuale che, attraverso la valorizzazione di parametri indi-

catori, fosse in grado di classificare le APPS Sanitarie e, su tale base, di valorizzare il livello di rischiosità a queste associato;

• evidenziare la necessità di integrazioni normative, che possano considerare le spe-cificità proprie delle APPS Sanitarie e dei loro realizzatori (sviluppatori), conside-rando che, in molti casi, questi ultimi sono rappresentati da liberi professionisti che non appartengono a strutture aziendali organizzate;

• avviare la definizione di possibili servizi che si ritiene opportuno vengano erogati agli stakeholder coinvolti dal fenomeno delle APPS Sanitarie (Ministero della Sa-lute, Organismi Notificati, Produttori e Sviluppatori, utenti-cittadini).

In altre parole lo Studio ha provveduto ha delineare la road-map per una più efficace governance del fenomeno delle APP Sanitarie, ossia l’insieme degli interventi tecnici e organizzativi necessari per minimizzare i rischi associati alla loro diffusione, pur nell’ottica di sfruttare al massimo le opportunità che derivano dal loro potenziale d’impiego. Il passo successivo è quello di definire come attuare questa road-map, ovvero in che modo centralizzare ed armonizzare i servizi che possono essere resi agli stakeholder sopra richiamati: la realizzazione di un sistema di supporto, che per sem-plicità chiameremo Registro APPS Sanitarie (o, più brevemente Registro), è la strada suggerita per raggiungere gli obiettivi indicati.

86 formit - unint

6.2. Obiettivi del RegistroLo Studio, tra i diversi risultati raggiunti, ha portato anche alla identificazione di una serie di elementi di attenzione che caratterizzano oggi i processi di progettazione, realizzazione, diffusione e impiego di APPS Sanitarie. In particolare, analizzando i risultati raggiunti da una ricognizione della situazione attuale (dal punto di vista nor-mativo, tecnologico e di scenario sociale), emerge con evidenza la necessità di:• elaborare una proposta di definizione specifica per le APPS Sanitarie, che, a parti-

re dalla quella dei Dispositivi medici, possa recepire quelle caratteristiche proprie delle APPS;

• elaborare una proposta di classificazione di rischio, mutuando quanto già regola-mentato per i dispositivi medici;

• definire i requisiti di sicurezza che le APPS Sanitarie devono soddisfare, anche in relazione al loro impiego su dispositivi mobili (non assimilabili a dispositivi medi-ci), attraverso una proposta che individui la documentazione tecnica da produrre a corredo di una APP Sanitaria;

• elaborare una proposta di rivisitazione ed integrazione del quadro normativo, per consentire una più efficace e puntuale gestione delle APPS Sanitarie, specifica-mente tarata sulle peculiarità che le caratterizzano.

Naturalmente, al di là delle proposte elaborate nel presente Studio (che costituiscono esclusivamente ipotesi evolutive, da concertare a livello europeo con le Autorità e gli Organi a ciò preposti), il Registro, dovendo essere avviato prima di eventuali altre au-spicabili iniziative, deve necessariamente conformarsi al quadro normativo vigente, soprattutto in tema di ruoli e responsabilità poste in capo ai diversi Attori coinvolti:• Ministero della Salute;• Organismi Notificati;• Produttori e Sviluppatori;• Utilizzatori.

Ciò significa che, pur garantendo una assoluta espandibilità verso successive e più sofisticate funzionalità e servizi, il Registro deve oggi operare in un contesto, che già prevede:• norme precise per richiedere la certificazione CE di un dispositivo medico;• ruoli e responsabilità precise, sia in termini di segnalazioni e comunicazioni (un

esempio è dato dall’art. 13 del D. Lgs 46/97 che prevede obblighi in capo ai Fab-bricanti e/o ai Mandatari), sia in termini di sistemi informativi e banche dati di supporto (un esempio è dato dall’art. 14 del D. Lgs. 46/97, che pone in capo al Ministero della Salute l’obbligo di alimentare la banca dati europea EUDAMED con informazioni afferenti i dispositivi medici);

• procedure normate per assicurare la vigilanza e la sorveglianza dei dispositivi medici;• modalità precise di segnalazione e gestione di incidenti.


Ciò premesso, è evidente la necessità di definire e realizzare preliminarmente un regi-stro sperimentale, che possa consentire lo sviluppo di un set minimale di servizi oggi già erogabili (in quanto conformi al quadro normativo vigente): in un momento suc-cessivo, anche in relazione ai risultati che verranno raggiunti da questo primo stadio, il registro potrà essere oggetto di sviluppo evolutivo, meglio se definito ed attuato in un quadro europeo. Pertanto lo Studio costituisce la base per la realizzazione del Re-gistro APPS Sanitarie, essenzialmente costituito da un Portale che, in prima istanza, è grado di acquisire informazioni afferenti le APPS Sanitarie certificate CE, erogando contestualmente servizi di ricerca e consultazione ai cittadini ed ai produttori/svilup-patori mediante condivisione delle informazioni gestite.

Inoltre, attraverso una articolazione in un’Area pubblica e in un’Area riservata, il Portale espone un insieme di servizi fruibili dai diversi Attori coinvolti.

6.3. Possibili sviluppi evolutivi del Registro delle APPS SanitarieCome già anticipato, il Registro APPS ed il Portale che lo ospita nascono con l’obiet-tivo (immediato) di costituire un repository (ovviamente non vincolante per i fabbrican-ti) nel quale, previa iscrizione, possano essere registrate le APPS Sanitarie in possesso di certificazione CE, al fine di rendere più efficace la diffusione delle informazioni su tali APPS.

A partire da questa prima realizzazione, nel seguito si rappresentano alcuni pos-sibili sviluppi evolutivi che presuppongono, però, un adeguato periodo di test sul funzionamento iniziale del Registro.

Tali sviluppi, pertanto, vengono qui illustrati a titolo esemplificativo, per rappre-sentare in modo più completo ed efficace le potenzialità che il Portale ed il Registro potrebbero esprimere in un prossimo futuro, una volta che siano stati adeguatamente valutati dal Ministero della Salute tutti gli eventuali impatti, principalmente di carat-tere organizzativo, derivanti dalla messa in esercizio di tali strumenti.

6.3.1. Connessione con la Banca Dati Nazionale Dispositivi MediciAl momento la Banca Data Nazionale dei dispositivi medici è deputata alla ricezione delle comunicazioni obbligatorie contenenti tutte le informazioni sui dispositivi medi-ci realizzati (inoltrate dai Fabbricanti o dai Mandatari, a norma dell’art. 13 del D.lgs. 46/97 che prescrive queste comunicazioni come obblighi): la struttura architetturale e funzionale della predetta banca dati, però, non risponde al meglio alle esigenze infor-mative di registrazione e ricerca di APPS Sanitarie. A mero titolo esemplificativo, non è possibile formulare una ricerca semplice che possa evidenziare tutte e sole le APPS Sanitarie registrate nella banca dati. Per tale motivo, sembra opportuno prevedere un intervento evolutivo finalizzato a garantire un allineamento costante tra le informazio-ni relative ad APPS Sanitarie contenute nella predetta banca dati ed il Registro prece-

88 formit - unint

dentemente descritto. Le modalità tecniche di attuazione di questo flusso informativo tra i due sistemi non sono oggetto del presente Studio, ma, fin d’ora, si può ipotizzare un trasferimento effettuato in modo quanto più possibile automatizzato.

6.3.2. Ipotesi di procedura di validazione di APPS non certificateDi seguito viene descritta una ipotetica Procedura di validazione di una APP Sanita-ria, sottolineando ancora che l’iter descritto non costituisce un adempimento cogente ma rappresenta una Proposta e, come tale, deve intendersi suscettibile di modifiche ed integrazioni che potranno essere individuate ed apportate dai competenti organi preposti a livello nazionale ed europeo.

6.3.2.1. Descrizione delle fasi (proposta)

La procedura proposta costituisce un servizio attraverso il quale i Produttori/Svi-luppatori, previa iscrizione al Registro, potrebbero seguire tutte le fasi dell’iter di validazione, scambiando informazioni e documenti in formato elettronico. Prelimi-narmente, il Produttore/Sviluppatore accede al Portale e si iscrive (ossia definisce gratuitamente un account), ricevendo indietro, via mail, le credenziali personali di accesso ai servizi. Questa operazione, naturalmente, deve essere effettuata una-tan-tum al momento del primo accesso al Registro: le successive interazioni prevedono esclusivamente il login al Portale.

• Fase 1 – Invio documentazione

Accedendo al Portale per la validazione di una APP Sanitaria, il Produttore/Svi-luppatore potrà scegliere l’organismo a lui più consono tra quelli indicati41, al quale potrà inviare (in formato elettronico) la seguente documentazione prodotta a cor-redo dell’APP:

− Fascicolo tecnico (identificazione tecnica e funzionale dell’APP in esame);− Piano di qualità;− Piano di sicurezza;− Piano di test;− Indagine clinica prevista (opzionale).

I documenti indicati, secondo quanto illustrato in Appendice al presente Stu-dio42, dovranno contenere tutte le informazioni necessarie per caratterizzare il pro-getto per la realizzazione di un’APP Sanitaria, in linea con caratteristiche tecniche e funzionali predefinite.

41 Questo aspetto dipenderà dalle modalità con le quali verrà eventualmente attuata l’iniziativa in esame. Ove ammissibile, potrà essere pubblicato o meno un elenco di possibili organismi deputati ad effettuare l’attività di validazione descritta.

42 Attenzione: lo Studio riporta in Allegato una bozza dei documenti indicati e, di conseguenza, for-nisce già una traccia sufficientemente precisa delle informazioni e dei documenti da produrre.


• Fase 2 – Validazione L’organismo preposto acquisisce la documentazione trasmessa dal Produttore/Svi-luppatore e la associa all’APP in esame, rilasciando via mail una semplice attesta-zione di validazione Attenzione: si precisa ancora che questa procedura:

− non costituisce alcun tipo di vincolo per il Produttore/Sviluppatore;− non rilascia alcun giudizio di qualità e/o di conformità a standard per l’APP

in esame, né tantomeno costituisce elemento di qualifica e/o di certificazione;− rappresenta esclusivamente una validazione attestante che, nel processo di

progettazione e realizzazione, il Produttore/Sviluppatore ha realizzato ed as-sociato all’APP tutta la documentazione necessaria per assicurarne il control-lo di qualità da parte di eventuali organi preposti.

• Fase 3 – Caricamento dell’APP nel RegistroIl Produttore/Sviluppatore, una volta ricevuta la validazione, se lo desidera, può inserire l’APP Sanitaria nel Registro all’interno di un apposito elenco di APPS validate (le APPS certificate, si ricorda, sono tutte e sole quelle in possesso del marchio CE).

6.3.2.2. Descrizione dei documenti richiesti (proposta)

Per la presentazione/validazione di un Progetto, il Produttore/Sviluppatore, acceden-do al Portale con le sue credenziali, deve specificare: Titolo del progetto; Destinazione d’uso; Classe di rischio; Utilizzatore; Progetto di riferimento (nel caso di aggiorna-mento di un altro Progetto).

I documenti da allegare al progetto sono:• Fascicolo tecnico;• Piano di qualità;• Piano di sicurezza;• Piano di test;• Indagine clinica (ove prevista).

Naturalmente, all’interno del Fascicolo tecnico, dovranno essere fornite tutte le in-formazioni necessarie per una caratterizzazione completa dell’APP in esame. A titolo esemplificativo:• Nome e versione dell’APP;• Descrizione sintetica;• Dati trattati (con eventuale dichiarazione di conformità alle prescrizioni del D.

Lgs. 30 giugno 2003, n. 196 – Codice in materia di protezione dei dati personali – nonché dalle successive modificazioni ed integrazioni, con particolare a quanto dettato dall’art. 34 – Trattamenti con strumenti elettronici;

• Dispositivi mobili supportati (marca, modello, fabbricante, versione – se applicabile, ecc.);

90 formit - unint

• Sistemi operativi sui quali potrà operare l’APP Sanitaria;• APP Store attraverso i quali sarà distribuita l’APP Sanitaria.

6.3.3. Ulteriori servizi a favore dei Fabbricanti di APPSIl Portale, infine, potrebbe erogare un servizio di supporto ai Fabbricanti di APPS Sanitarie che abbiano necessità di essere guidati per procedere:• alla realizzazione/certificazione CE di una APP Sanitaria;• alla realizzazione/validazione di una APP Sanitaria, con eventuale pubblicazione

nell’area del Registro riservata alle APPS validate (non certificate);• alla ricognizione (non cogente) dei criteri di qualità e di sicurezza che è opportuno

soddisfare nello sviluppo di una APP Sanitaria;• ecc.

7. Appendice 1 – Definizioni

Si riportano di seguito le definizioni dei termini utilizzati nel presente Studio.

• Applicazione software: in informatica individua un programma o una serie di pro-grammi in fase di esecuzione su un computer con lo scopo e il risultato di rendere possibile un servizio, una serie di servizi o strumenti utili e selezionabili su richiesta dell’utente, spesso attraverso un elaborazione a partire da un input fornito dall’utente interagendo con esso. È dunque il risultato a livello utente dalla combinazione di ri-sorse software e rispettive risorse hardware di processamento per la loro esecuzione.

• APP: dicitura abbreviata per indicare Applicazione software, sia ludica che di uti-lità, per dispositivi Smartphone, palmari e più recentemente Tablet Computer. Il termine ha avuto larga diffusione dopo che il costruttore Apple ha chiamato così i software scaricabili dal proprio sito (APP Store) ed installabili sui dispositivi delle famiglie iPhone, iPod Touch e, successivamente, iPad. Una APP per dispositivi mobili si differenzia dalle tradizionali applicazioni sia per il supporto con cui vie-ne usata sia per la concezione che racchiude in sé. Si tratta a tutti gli effetti di un software che per struttura informatica è molto simile a una generica applicazione ma è caratterizzata da una semplificazione ed eliminazione del superfluo, al fine di ottenere leggerezza, essenzialità e velocità. Il nome stesso, di per sé un’abbreviazio-ne, può essere percepito come una semplificazione del nome completo applicazio-ne per dare l’idea di un qualcosa di semplice e piccolo, tali APPS si suddividono in mobile APP, Web APPS e APPS native.

• Dispositivo mobile: dispositivo elettronico che è completamente utilizzabile se-guendo la mobilità dell’utente quale, ad esempio, telefono cellulare, palmare, smar-tphone, tablet, ovvero ogni altro dispositivo mobile dotato di un sistema operativo atto ad eseguire un’applicazione software appositamente realizzata per il dispositivo stesso. Possono essere dunque dispositivi dedicati oppure general purpose, comun-que di dimensioni e peso ridotti tali da poter essere trasportati dall’utente.

92 formit - unint

• APPS native: software per dispositivi mobili creata appositamente per uno spe-cifico sistema operativo. L’interazione diretta con le API messe a disposizione dal costruttore del sistema operativo garantirà accesso immediato a tutte le funzionali-tà del dispositivo oltre a permettere prestazioni ottimali e migliorare sensibilmente l’usabilità.

• APPS sanitarie: applicazioni software, fruibili per mezzo di dispositivi mobili, in grado di offrire servizi correlati con la salute pubblica. I servizi offerti, di natura medico-scientifica, hanno lo scopo di:

− effettuare copie di testi e materiale medico;− accedere, divulgare, registrare, tracciare informazioni correlate allo stato ge-

nerale di salute o benessere del paziente, senza fornire alcuna indicazione in merito allo stato stesso di salute;

− automatizzare procedure di contabilità, appuntamenti, cartella clinica elettro-nica, ecc.

• APPS Sanitarie: una qualunque applicazione software, operante su un dispositivo mobile (smartphone, tablet, ecc.), con o senza eventuali periferiche, utilizzata per il trattamento di dati utili alle attività di diagnosi, prevenzione, controllo, terapia di un paziente, effettuate con o senza l’impiego di formule e algoritmi, ivi compresa la semplice visualizzazione o la trasmissione di dati sanitari.

• Dispositivo medico: qualunque strumento, apparecchio, impianto, software, so-stanza o altro prodotto, utilizzato da solo o in combinazione, compreso il software destinato dal fabbricante ad essere impiegato specificamente con finalità diagno-stiche o terapeutiche e necessario al corretto funzionamento del dispositivo, desti-nato dal fabbricante ad essere impiegato sull’uomo a fini di diagnosi, prevenzione, controllo, terapia o attenuazione di una malattia; di diagnosi, controllo, terapia, attenuazione o compensazione di una ferita o di un handicap; di studio, sostituzio-ne o modifica dell’anatomia o di un processo fisiologico; di intervento sul conce-pimento, il quale prodotto non eserciti l’azione principale, nel o sul corpo umano, cui è destinato, con mezzi farmacologici o immunologici né mediante processo metabolico ma la cui funzione possa essere coadiuvata da tali mezzi;

• Accessorio: prodotto che, pur non essendo un dispositivo, sia destinato in modo specifico dal fabbricante ad essere utilizzato con un dispositivo per consentirne l’utilizzazione prevista dal fabbricante stesso.

• Software stand-alone: un software capace di funzionare da solo o in maniera indi-pendente da altri oggetti o software, con cui potrebbe altrimenti interagire.

8. Appendice 2 – Normativa di riferimento

leggi e decreti nazionali

[Rif. 1] Decreto Legislativo 25 gennaio 2010, n. 37 – Attuazione della direttiva 2007/47/CE che modifica le direttive 90/385/CEE per il ravvicinamento delle legislazioni degli stati membri relative ai dispositivi medici impian-tabili attivi, 93/42/CE concernente i dispositivi medici e 98/8/CE relativa all’immissione sul mercato dei biocidi.

[Rif. 2] Decreto Legislativo 8 settembre 2000, n. 332 – Attuazione della direttiva 98/79/CE relativa ai dispositivi medico-diagnostici in vitro.

[Rif. 3] Decreto Legislativo 24 febbraio 1997, n. 46 – Attuazione della direttiva 93/42/CEE concernente i dispositivi medici

direttive comunitarie

[Rif. 4] Direttiva 2007/47/CE del Parlamento Europeo e del Consiglio del 5 settembre 2007 – Modifica la direttiva 90/385/CEE del Consiglio per il ravvicinamento delle legislazioni degli Stati membri relative ai dispositivi medici impiantabili attivi, la direttiva 93/42/CEE del Consiglio concer-nente i dispositivi medici, e la direttiva 98/8/CE relativa all’immissione sul mercato dei biocidi.

[Rif. 5] Direttiva 2001/104/CE del Parlamento Europeo e del Consiglio del 7 di-cembre 2001, che modifica la direttiva 93/42/CEE del Consiglio relativa ai dispositivi medici.

[Rif. 6] Direttiva 2000/70/CE del Parlamento Europeo e del Consiglio del 16 novembre 2000, che modifica la direttiva 93/42/CEE del Consiglio per quanto riguarda i dispositivi medici che incorporano derivati stabili del sangue o del plasma umano.

[Rif. 7] Direttiva 98/79/CE del Parlamento Europeo e del Consiglio del 27 otto-bre 1998 – Dispositivi medico-diagnostici in vitro.

[Rif. 8] Direttiva 93/42/CE del Parlamento Europeo e del Consiglio del 14 giu-gno 1993 – Dispositivi medici.

94 formit - unint

[Rif. 9] Direttiva 90/385/CE del Parlamento Europeo e del Consiglio del 20 giu-gno 1990 – Dispositivi medici impiantabili attivi.

linee guida

[Rif. 10] FDA Regulation of Mobile Health dell’ottobre 2013.[Rif. 11] MEDDEV 2.1/6 Qualification and Classification of stand-alone software

di gennaio 2012

iso/iec

[Rif. 12] UNI CEI EN ISO 14971:2012 – Medical devices – Application of risk management to medical devices

[Rif. 13] IEC 62304:2006 – Medical device software – Software life cycle proces-ses

[Rif. 14] ISO/IEC 2382-1:1993 – Information technology – Vocabulary – Part 1: Fundamental terms

altri documenti

[Rif. 15] SVEZIA – Medical Information Systems – guidance for qualification and classification of standalone software with a medical purpose di gennaio 2013

Gruppo di lavoro

Viviana Armenise

Filomena Biscione

Calogero Di Francesco

Giampiero Gasperini

Edoardo Limone

Michela Lucherini

Carmela Pierri

Simona Trotta

Finito di stamparepresso Trecentosessantagradi srl – Roma

Date post:	22-Mar-2021
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Diffusione delle APPSFigura 25 – Samsung: il progetto Simband..... 52. Figura 26 – Diapositiva...

Documents