L'IT sanitario non può spostare le immagini nel cloud. Ecco come mantenere conformi i sistemi on-premise.

Perché alcuni sistemi non vanno da nessuna parte

Ogni sistema sanitario sta guardando al cloud in questo momento. Lo storage costa meno, la scalabilità è più semplice, e i fornitori continuano a chiedersi perché l'EMR non è ancora lì. Ma entra in qualsiasi reparto di radiologia e la risposta è ovvia: quei file di imaging sono enormi, e i clinici ne hanno bisogno rapidamente. La maggior parte degli ospedali gestisce già una cache locale in ogni sede solo per mantenere bassa la latenza per le immagini. Quel carico di lavoro non sparirà.

L'EMR è una scelta più difficile. Alcune organizzazioni lo hanno migrato al cloud. Molte no, perché le integrazioni costruite intorno ad esso (sistemi di laboratorio, farmacia, programmazione, interfacce dei dispositivi) dipendono da una bassa latenza che un EMR ospitato nel cloud non può sempre garantire quando i dati devono fare il giro in tempo reale. Rimuovere un'integrazione e si rischia che un medico guardi un indicatore di caricamento durante un incontro dal vivo con il paziente.

E finché i sistemi clinici principali rimangono on-premise, Active Directory rimane anche lui. È il livello di identità contro cui si autentica tutto il resto. Spostarlo prima che il resto dell'ambiente sia pronto aggiunge solo rischi senza rimuoverne alcuno.

Rimanere on-premise significa anche che rimanere statici non è un'opzione. Non c'è nessun fornitore cloud che silenziosamente aggiorni il sistema operativo o rafforzi la configurazione in background. Se un ospedale mantiene un sistema internamente, l'intero ciclo di vita per mantenere quel sistema aggiornato e sicuro rimane anch'esso interno, e dimostrare che ciò avviene realmente diventa compito dell'organizzazione, non del fornitore.

Quindi la realtà pratica per molte squadre IT sanitarie: la migrazione al cloud è reale, ma parziale. I server di radiologia, i punti di integrazione EMR e AD rimarranno on-premise per il prevedibile futuro. E quei sistemi devono comunque rispettare gli stessi standard di conformità di tutto il resto.

Cosa si aspetta HIPAA quando qualcosa va storto

La Regola di Notifica delle Violazioni HIPAA presume il peggio per impostazione predefinita. Se le informazioni sanitarie protette vengono utilizzate o divulgate in un modo non consentito da HIPAA, la legge presume che si tratti di una violazione a meno che l'organizzazione non possa documentare una valutazione del rischio che dimostri una bassa probabilità che le PHI siano state effettivamente compromesse. Tale valutazione deve considerare fattori come il tipo di PHI coinvolta, chi vi ha avuto accesso, se è stata effettivamente visualizzata o acquisita e se il rischio è stato mitigato.

Una volta confermata una violazione, il tempo inizia a scorrere. Le persone interessate devono essere informate senza ritardi irragionevoli e non oltre 60 giorni dalla scoperta. Le violazioni che coinvolgono 500 o più persone richiedono anche una notifica all'HHS entro 60 giorni, oltre a una notifica ai media in alcuni casi. Le violazioni più piccole vengono incluse in un rapporto annuale all'HHS.

Ecco la parte che conta di più per un server di radiologia on-premise o una scatola di integrazione EMR: l'organizzazione deve essere in grado di ricostruire cosa è successo. Chi ha toccato il file. Quando. Se la modifica era prevista. Senza questo, la valutazione del rischio predefinita è "non lo sappiamo", e "non lo sappiamo" predefinito è una violazione segnalabile.

I registri da soli non reggono in un audit

I sistemi on-premise cambiano costantemente: patch, modifiche di configurazione, nuovi account, un ingegnere del fornitore che si collega da remoto a un'interfaccia PACS alle 2 di notte per sistemare una coda di stampa. La maggior parte di questo va bene. Alcune cose non sono affatto autorizzate, e i log nativi del sistema operativo non ti dicono quale sia quale. Ti dicono che una chiave di registro è cambiata. Non ti dicono se quel cambiamento corrispondeva a un ticket approvato o proveniva da qualcuno che non avrebbe dovuto avere accesso.

Quindi, quando OCR o un revisore chiedono se un server specifico dell'interfaccia EMR è stato toccato nell'ultimo trimestre, la risposta onesta per molte squadre è "dovremmo andare a controllare." Non è una buona posizione in cui trovarsi quando il tempo per determinare una violazione è già in corso.

Creazione di prove di audit senza aumentare il personale

Netwrix Change Tracker offre all’IT sanitario un modo per mantenere l’integrità dei sistemi che devono rimanere on-premise, inclusi i server di radiologia, i punti di integrazione EMR e l’infrastruttura Active Directory che non si sposteranno.

Costruisce una baseline nota e affidabile per quei sistemi, quindi monitora in tempo reale l'integrità dei file e lo stato della configurazione su Windows, Linux e i dispositivi di rete tra di loro. Quando qualcosa cambia, sia una chiave di registro, un file di configurazione o un account locale, Change Tracker lo verifica rispetto ai Cambiamenti Pianificati approvati. Se corrisponde a una finestra di cambiamento approvata, viene archiviato come attività prevista. Se non corrisponde, viene segnalato immediatamente e l'IT lo sa in pochi minuti invece di scoprirlo durante un audit o una revisione dell'incidente.

Ciò significa che "dovremmo andare a controllare" diventa "ecco qui." Il registro mostra già cosa è cambiato, quando e se è stato autorizzato, e questo è la maggior parte del lavoro dietro una valutazione del rischio a quattro fattori difendibile.

Change Tracker include anche più di 250 report di conformità predefiniti mappati su framework come HIPAA, NIST, e PCI DSS, quindi dimostrare che il controllo era in atto non significa costruire un report da zero ad ogni ciclo di audit. Le evidenze sono già strutturate nel modo in cui un revisore si aspetta di vederle.

La conversazione sul cloud nell'IT sanitario non è finita, e non dovrebbe esserlo. Ma i sistemi che rimangono on-premise devono ancora dimostrare di essere sotto controllo. Change Tracker offre ai team IT e di conformità un modo per farlo senza aspettare che il resto dell'infrastruttura si aggiorni.