Come rendere la tua app sanitaria conforme all’HIPAA

Tra le altre cose, l’HIPAA protegge le informazioni sanitarie dei pazienti.

Anthem, la più grande compagnia assicurativa statunitense, lo ha imparato a sue spese.

Quello che è iniziato con una semplice e-mail di phishing, ha portato alla più grande violazione dei dati sanitari della storia. Gli hacker hanno rubato i dati di 79 milioni di pazienti. Le informazioni includevano i loro nomi, numeri di previdenza sociale e ID medici.

I pazienti infuriati hanno fatto causa ad Anthem e hanno vinto un accordo da 115 milioni di dollari. Anche se l’azienda ha evitato le multe del regolatore, avrebbe dovuto spendere fino a 260 milioni di dollari per migliorare la sua sicurezza.

HHS Office for Civil Rights (OCR) supervisiona la conformità HIPAA. Solo nel 2017 ha multato i fornitori di assistenza sanitaria degli Stati Uniti per quasi 20 milioni di dollari.

Anche se sei una piccola organizzazione, trascurare i requisiti HIPAA può portare a gravi problemi.

Nel 2013 Fresenius Medical Care North America ha avuto cinque violazioni dei dati. Insieme, hanno esposto i dati di appena 525 pazienti. Ma l’azienda ha dovuto pagare una multa mostruosa di 3,5 milioni di dollari perché non ha analizzato correttamente i rischi per la sicurezza.

Secondo il grado di negligenza, ci sono quattro tipi di multe HIPAA:

Glossario HIPAA

Si dovrebbero capire questi tre termini chiave prima di affrontare i requisiti HIPAA.

• Informazioni sanitarie protette (PHI) – qualsiasi dato che può essere usato per identificare un paziente.

PHI consiste di due parti: informazioni sanitarie e identificatori personali. Questi ultimi includono nomi di pazienti, indirizzi, date di nascita, numeri di previdenza sociale, cartelle cliniche, foto, ecc. Il fatto che un individuo abbia ricevuto servizi medici è di per sé un PHI.

Cosa è considerato PHI? La lista completa.

• Entità coperte – organizzazioni e individui che offrono servizi/operazioni sanitarie, o che accettano pagamenti per essi.

Comprendono tutti i fornitori di servizi sanitari (ad esempio ospedali, medici, dentisti, psicologi), piani sanitari (ad esempio fornitori di assicurazioni, HMO, programmi governativi come Medicare e Medicaid) e stanze di compensazione (le organizzazioni che agiscono come intermediari tra i fornitori di servizi sanitari e le compagnie di assicurazione).

• Business Associates – le terze parti che gestiscono PHI per conto delle entità coperte.

Questa categoria include gli sviluppatori di applicazioni sanitarie, i fornitori di hosting/conservazione dei dati, i servizi di posta elettronica, ecc.

Secondo l’HIPAA, è necessario firmare un accordo Business Associate (BAA) con ogni parte che ha accesso alle tue PHI. Decidere di non firmare un BAA non ti libera dai requisiti dell’HIPAA.

Ci possono essere molti modi involontari in cui i dati sensibili possono entrare nel vostro sistema.

Prendiamo, per esempio, un servizio che permette ai medici di diagnosticare le condizioni della pelle sulla base di foto anonime. L’app non gestisce PHI in quanto non è possibile identificare i suoi utenti. Ma non appena si aggiunge il nome o l’indirizzo della persona alle foto, queste diventano PHI.

Se la tua applicazione raccoglie, memorizza o trasmette PHI alle entità coperte, è necessario rispettare l’HIPAA.

Come diventare conforme all’HIPAA?

Per essere conforme all’HIPAA, dovrai fare regolari valutazioni tecniche e non tecniche dei tuoi sforzi per proteggere le informazioni sanitarie e documentarle accuratamente. Il regolatore ha pubblicato un protocollo di audit campione che può aiutarti a valutare la tua conformità HIPAA.

Puoi assumere un revisore indipendente per fare la valutazione per te. Ci sono molte organizzazioni come HITRUST che sono specializzate in questo genere di cose. Ricorda solo che l’OCR non riconosce nessun certificato di terze parti.

Salvaguardie tecniche. Misure di sicurezza come login, crittografia, accesso di emergenza, registri di attività, ecc. La legge non specifica quali tecnologie si debbano usare per proteggere PHI.

Le salvaguardie fisiche hanno lo scopo di proteggere le strutture e i dispositivi che conservano PHI (server, data center, PC, computer portatili, ecc.).

Con le moderne soluzioni basate sul cloud, questa regola si applica principalmente all’hosting conforme a HIPAA.

La legge si applica a una vasta gamma di software medici. Un sistema di gestione ospedaliera (HMS) differisce radicalmente dalle applicazioni di diagnostica a distanza. Ma ci sono alcune caratteristiche che sono essenziali per tutte le app conformi all’HIPAA.

Quindi ecco una lista minima di caratteristiche richieste per il software conforme all’HIPAA:

1. Controllo degli accessi

Ogni sistema che memorizza PHI dovrebbe limitare chi può visualizzare o modificare i dati sensibili. Secondo la HIPAA Privacy Rule, nessuno dovrebbe vedere più informazioni sui pazienti di quelle necessarie per fare il proprio lavoro. La regola specifica anche la de-identificazione, i diritti del paziente di vedere i propri dati e la loro capacità di dare o limitare l’accesso alle loro PHI.

Un modo per realizzare questo è quello di assegnare ad ogni utente un ID unico. Questo vi permetterebbe di identificare e tracciare l’attività delle persone che accedono al vostro sistema.

In seguito, dovrete dare a ogni utente una lista di privilegi che gli permettono di visualizzare o modificare certe informazioni. Puoi regolare l’accesso alle singole entità del database e agli URL.

Nella sua forma più semplice, il controllo di accesso basato sull’utente consiste in due tabelle del database. Una tabella contiene la lista di tutti i privilegi e i loro ID. La seconda tabella assegna questi privilegi ai singoli utenti.

In questo esempio, il medico (ID utente 1) può creare, visualizzare e modificare le cartelle cliniche, mentre il radiologo (ID utente 2) può solo aggiornarle.
Un controllo di accesso basato sui ruoli è un altro modo per implementare questo requisito. Con esso, è possibile assegnare privilegi a diversi gruppi di utenti a seconda della loro posizione (ad esempio medici, tecnici di laboratorio, amministratori).

2. Autenticazione di persone o entità

Dopo aver assegnato i privilegi, il sistema dovrebbe essere in grado di verificare che la persona che cerca di accedere a PHI sia quella che dice di essere. La legge offre diversi modi generali in cui è possibile implementare questa salvaguardia:

Una password è uno dei metodi di autenticazione più semplici. Purtroppo, è anche uno dei più facili da decifrare. Secondo Verizon, il 63% delle violazioni di dati avviene a causa di password deboli o rubate. Un altro rapporto afferma che un quinto degli utenti aziendali ha password facilmente compromettibili.

D’altra parte, una password veramente sicura:

• Consiste di almeno 8-12 caratteri che includono lettere maiuscole, numeri e caratteri speciali;
• Esclude le combinazioni comunemente usate (es. “password”, “123456”, “qwerty”, e per qualche inspiegabile ragione “monkey”) e parole del vocabolario;
• Disabilita qualsiasi variazione del nome utente;
• Evita il riutilizzo della password.

In alternativa, potrebbe essere una stringa di parole casuali schiacciate insieme come un ghiacciolo di cemento.

La vostra applicazione potrebbe controllare questi requisiti nella schermata di registrazione e negare l’accesso agli utenti con password deboli.

Non esiste una cosa come troppa sicurezza. Fonte: mailbox.org

Alcune organizzazioni obbligano i loro impiegati a cambiare le password ogni 90 giorni circa. Farlo troppo spesso può effettivamente danneggiare i vostri sforzi di sicurezza. Quando vengono obbligati a cambiare le password, le persone spesso se ne escono con combinazioni non originali (es. password ⇒ pa$$word).

Inoltre, gli hacker possono craccare una cattiva password in pochi secondi e usarla immediatamente.

Ecco perché dovresti considerare l’uso di un’autenticazione a due fattori. Tali sistemi combinano una password sicura con un secondo metodo di verifica. Questo può essere qualsiasi cosa, da uno scanner biometrico a un codice di sicurezza monouso ricevuto via SMS.

L’idea è semplice: anche se gli hacker ottenessero in qualche modo la tua password, avrebbero bisogno di rubare il tuo dispositivo o le tue impronte digitali per accedere a PHI.

Ma l’autenticazione sicura non è sufficiente. Alcuni aggressori potrebbero inserirsi tra il dispositivo dell’utente e i vostri server. In questo modo, gli hacker potrebbero accedere al PHI senza compromettere l’account. Questo è noto come session hijacking, un tipo di attacco man-in-the-middle.

Uno dei modi possibili per dirottare una sessione. Fonte: Heimdal Security

La firma digitale è un modo per difendersi da questi attacchi. Reinserire la password quando si firma un documento proverebbe l’identità dell’utente.

Quando i ruoli nel tuo sistema diventano più complessi, l’autorizzazione HIPAA può ostacolare l’assistenza ai pazienti. Ha senso implementare un accesso di emergenza. Tali procedure permettono agli utenti autorizzati di visualizzare qualsiasi dato di cui hanno bisogno quando la situazione lo richiede.

Un medico potrebbe, per esempio, accedere a PHI di qualsiasi paziente in caso di emergenza. Allo stesso tempo, il sistema informerebbe automaticamente diverse altre persone e lancerebbe una procedura di revisione.

3. Sicurezza delle trasmissioni

È necessario proteggere i PHI che si inviano sulla rete e tra i diversi livelli del sistema.

Ecco perché si dovrebbe forzare HTTPS per tutte le comunicazioni (o almeno per le schermate di iscrizione, tutte le pagine contenenti PHI e i cookie di autorizzazione). Questo protocollo di comunicazione sicura cripta i dati con SSL/TLS. Usando un algoritmo speciale, trasforma PHI in una stringa di caratteri senza significato senza chiavi di decrittazione.

Un file chiamato certificato SSL lega la chiave alla tua identità digitale.

Quando si stabilisce una connessione HTTP con la tua applicazione, il browser richiede il tuo certificato. Il client controlla quindi la sua credibilità e avvia il cosiddetto SSL handshake. Il risultato è un canale di comunicazione criptato tra l’utente e la tua applicazione.

Per abilitare HTTPS per la tua applicazione, ottieni un certificato SSL da uno dei fornitori affidabili e installalo correttamente.

Inoltre, assicurati di usare un protocollo sicuro SSH o FTPS per inviare i file contenenti PHI invece del normale FTP.

SSL handshake; fonte: the SSL store

Le e-mail non sono un modo sicuro per inviare PHI.

I servizi popolari come Gmail non forniscono la protezione necessaria. Se invii email contenenti PHI oltre il tuo server firewalled, dovresti crittografarle. Ci sono molti servizi ed estensioni del browser che possono farlo per te. In alternativa, puoi usare un servizio di posta elettronica conforme all’HIPAA come Paubox.

Dovresti anche implementare politiche che limitano quali informazioni possono essere condivise via e-mail.

4. Crittografia/decrittografia

La crittografia è il modo migliore per assicurare l’integrità dei PHI. Anche se gli hacker riuscissero a rubare i tuoi dati, sembrerebbero una baggianata senza le chiavi di decrittazione.

I computer portatili non criptati e altri dispositivi portatili sono una fonte comune di violazioni HIPAA. Per essere al sicuro, crittografate i dischi rigidi di tutti i dispositivi che contengono PHI. Puoi farlo con strumenti di crittografia gratuiti come BitLocker per Windows o FileVault per Mac OS.

5. Smaltimento di PHI

Dovresti distruggere permanentemente PHI quando non è più necessario. Finché la sua copia rimane in uno dei tuoi backup, i dati non sono considerati “eliminati”.

Nel 2010 Affinity Health Plan ha restituito le sue fotocopiatrici alla società di leasing. Tuttavia, non ha cancellato i loro dischi rigidi. La violazione risultante ha esposto le informazioni personali di più di 344.000 pazienti.

Affinity ha dovuto pagare 1,2 milioni di dollari per questo incidente.

PHI può nascondersi in molti luoghi inaspettati: fotocopiatrici, scanner, attrezzature biomediche (ad esempio, macchine per risonanza magnetica o ultrasuoni), dispositivi portatili (ad es.Ad esempio, computer portatili), vecchi floppy disk, unità flash USB, DVD/CD, schede di memoria, memoria flash nelle schede madri e nelle schede di rete, memoria ROM/RAM, ecc.

Oltre a cancellare i dati, dovresti anche distruggere correttamente i supporti che contengono PHI prima di gettarli o darli via. A seconda della situazione, puoi cancellarli magneticamente (per esempio usando un degausser), sovrascrivere i dati usando un software come DBAN, o distruggere fisicamente l’unità (per esempio spaccandola con un martello).

Nelle unità di memoria basate su flash (per esempio le chiavette USB), i dati sono sparsi su tutto il supporto per evitare l’usura. Per questo motivo, è difficile cancellare completamente le informazioni sensibili con un normale software di distruzione dei dati. È possibile, tuttavia, utilizzare utility del produttore come Samsung Magician Software per smaltire le unità flash (o semplicemente usare un martello).

6. Backup e conservazione dei dati

I backup sono essenziali per l’integrità dei dati. Una corruzione del database o un crash del server potrebbe facilmente danneggiare il tuo PHI. Così come un incendio in un centro dati o un terremoto.

Ecco perché è importante avere più copie dei tuoi PHI memorizzati in diversi luoghi.

Il tuo piano di backup PHI dovrebbe determinare la probabilità di compromissione dei dati. Tutte le informazioni ad alto e medio rischio dovrebbero essere sottoposte a backup giornaliero e conservate in una struttura sicura. Dovresti anche firmare un BAA con i tuoi fornitori di backup.

Un backup è inutile se non puoi ripristinarlo.

Nell’agosto 2016, Martin Medical Practice Concepts è stata vittima di un attacco ransomware. L’azienda ha pagato gli hacker per decifrare il PHI. Ma a causa di un errore di backup, gli ospedali locali hanno perso le informazioni su 5.000 pazienti.

Testate regolarmente il vostro sistema per prevenire errori di recupero. Dovresti anche registrare il tempo di inattività del sistema e qualsiasi fallimento del backup della PHI.

E ricorda, i backup stessi dovrebbero essere conformi agli standard di sicurezza HIPAA.

7. Controlli di audit

L’assenza di controlli di audit potrebbe portare a multe più alte.

Dovresti monitorare cosa viene fatto alla PHI memorizzata nel tuo sistema. Registra ogni volta che un utente entra ed esce dal tuo sistema. Dovreste sapere chi, quando e dove i dati sensibili sono stati acceduti, aggiornati, modificati o cancellati.

Il monitoraggio può essere fatto tramite software, hardware o mezzi procedurali. Una soluzione semplice sarebbe quella di utilizzare una tabella in un database o un file di log per registrare tutte le interazioni con le informazioni del paziente.

Tale tabella dovrebbe essere composta da cinque colonne:

• user_id. L’identificatore unico dell’utente che ha interagito con PHI;
• nome_entità. L’entità con cui l’utente ha interagito (un’entità è una rappresentazione di qualche concetto del mondo reale nel vostro database, per esempio una cartella clinica);
• record_id. L’identificatore dell’entità;
• tipo_azione. La natura dell’interazione (creare, leggere, aggiornare o cancellare);
• action_time. Il momento preciso dell’interazione.

In questo esempio, un medico (user_id 1) ha creato la cartella di un paziente, un radiologo l’ha vista, e più tardi lo stesso medico ha modificato la cartella.

Dovrete controllare periodicamente i registri delle attività per scoprire se alcuni utenti abusano dei loro privilegi per accedere a PHI.

8. Logoff automatico

Un sistema con PHI dovrebbe terminare automaticamente qualsiasi sessione dopo un determinato periodo di inattività. Per continuare, l’utente dovrebbe reinserire la sua password o autorizzare in qualche altro modo.

Questo proteggerebbe PHI se qualcuno perde il suo dispositivo mentre è connesso alla tua applicazione.

Il periodo esatto di inattività che fa scattare il logout dovrebbe dipendere dalle specifiche del tuo sistema.

Con una workstation sicura in un ambiente altamente protetto, puoi impostare il timer per 10-15 minuti. Per le soluzioni basate sul web, questo periodo non dovrebbe superare i 10 minuti. E per un’applicazione mobile, si può impostare il timeout per 2-3 minuti.

Diversi linguaggi di programmazione implementano il logoff automatico in modi diversi.

Fonte: MailChimp

9. Extra-sicurezza delle app mobili

I dispositivi mobili presentano molti rischi aggiuntivi. Uno smartphone potrebbe essere facilmente rubato o perso in una zona ad alto traffico compromettendo le informazioni sensibili.

Per prevenire questo, si può usare:

• Blocco schermo (Android/iOS);
• Crittografia completa del dispositivo (Android/iOS);
• Cancellazione remota dei dati (Android/iOs).

Non potete forzare queste caratteristiche agli utenti, ma potete incoraggiare le persone ad usarle. Puoi includere le istruzioni nel tuo onboarding o inviare email che descrivono come abilitarle.

Suggerimento: Puoi archiviare PHI in un contenitore sicuro separatamente dai dati personali. In questo modo, è possibile cancellare a distanza le informazioni sanitarie senza influenzare nient’altro.

Molti medici usano smartphone personali per inviare informazioni sanitarie. È possibile neutralizzare questa minaccia con piattaforme di messaggistica sicura.

Queste applicazioni ospitano i dati sensibili in un database sicuro. Per accedere a PHI, gli utenti devono scaricare il messenger e accedere ai loro account.

Un’altra soluzione è rappresentata dai portali sanitari criptati e protetti da password dove i pazienti possono leggere i messaggi dei loro medici. Tali portali inviano notifiche senza PHI (ad esempio “Caro utente, hai un nuovo messaggio da “).

Ricorda che le notifiche push non sono sicure di default. Possono apparire sullo schermo anche se è bloccato. Quindi assicurati di non inviare PHI tramite le notifiche push. Lo stesso vale per gli SMS e qualsiasi messaggio automatico.

Fonte: Bridge Patient Portal

Un’altra cosa da considerare è che la FDA potrebbe classificare alcune app mHealth come dispositivi medici (software che influenza il processo decisionale dei professionisti sanitari).

Ricorda quindi di controllare se la tua app deve essere conforme ad altri regolamenti sanitari prima di iniziare lo sviluppo. Puoi controllare questo test della Federal Trade Commission per avere una risposta veloce.

Involucro

Ora hai una lista minima di caratteristiche per un software conforme all’HIPAA.

Da sole non garantiscono la sicurezza. Non vi proteggeranno dal phishing o dall’ingegneria sociale.

Ma avere queste caratteristiche dovrebbe convincere un revisore che avete fatto abbastanza per proteggere i dati dei vostri clienti.

Per rendere gli audit meno dolorosi, documentate tutti i vostri sforzi di conformità HIPAA. Per ogni versione della tua applicazione, fornisci le specifiche scritte, i piani per testare la sua sicurezza e i loro risultati. E non dimenticate di controllare se avete bisogno di conformarvi ad altri regolamenti prima di iniziare lo sviluppo.

.