Trasmette paziente MRN in un URL di servizio Web a una violazione PHI HIPAA?

Question

Trasmette paziente MRN in un URL di servizio Web a una violazione PHI HIPAA?

#1 da (3 voti)
#2 da (2 voti)
#3 da (0 voti)
#4 da (0 voti)

7

Sto costruendo un servizio web per accedere ai dati dei pazienti all'interno del nostro EMR e vorrei iscrivermi ai principi di progettazione RESTful. Tuttavia, l'idea di includere MRN paziente in una richiesta GET mi mette a disagio. Stavo pensando di essere semplicemente "RESTfulesque" e fare affidamento esclusivamente sui POSTS in modo che l'MRN potesse essere incluso nel corpo della richiesta.

Ad esempio Invece di

GET | http://OrganizationName.org/ServerName/.../REST/XML/MedicalHistory?PatientID={PatientID}&PatientIDType={PatientIDType}&UserID={UserID}&UserIDType={UserIDType}/

Vorrei usare

POST | http://OrganizationName.org/ServerName/GET/MedicalHistory
POST |                            /ServerName/PUT/MedicalHistory

PatientID, Type e UserID e Type sono le proprietà dell'intestazione della richiesta.

Sembra che la maggior parte dei fornitori di EMR userà i verbi REST tradizionali ed esporrà gli ID nell'URL, ma questo sembra sbagliato. Sono troppo paranoico con il mio design? Voglio che i miei servizi siano molto compatibili con gli sviluppatori, quindi non voglio rompere con i principi di progettazione REST a meno che non sia necessario.

Sto rischiando una violazione HIPAA esponendo MRN paziente all'interno di un URL di richiesta?

rest web-service hipaa

posta Daniel Wilson 03.01.2015 - 00:32

fonte

4 risposte

Leggi altre domande sui tag rest web-service hipaa

C'è un modo per mettere una password autodistruggente sulla crittografia del disco di Ubuntu? Quali misure di sicurezza ha Chrome per implementare account utente di sandbox diversi?

score 3 · Answer 1

Dipende da una serie di fattori.

Poiché il numero di Medical Record Number (MRN) è Protected Healthcare Information (PHI), sei responsabile per la sua riservatezza, integrità e disponibilità e sei responsabile di identificare e proteggere da minacce ragionevolmente previste per la sua sicurezza (e integrità) E contro usi o divulgazioni non consentiti ragionevolmente anticipati. Regola di sicurezza HIPAA

Sebbene HTTPS protegga i parametri contro l'intercettazione, le voci di registro per le richieste GET mostreranno l'URL completo non crittografato sul client e sul server. Questi creano almeno informazioni ragionevolmente anticipate (come per i dipendenti non autorizzati) e richiedono anche controlli.

Che tipo di controlli di accesso ci sono tra le macchine client e il server? Qualche macchina può connettersi se fornisce un ID utente e una password che indicano un utente autorizzato? O solo alcune macchine in combinazione con determinati utenti? Qualcuno sul lato server può accedere ai file di registro che non dovrebbero avere accesso ai dati del paziente? (ad esempio, i record dei pazienti sono in una base di dati crittografata, ma un tecnico potrebbe inciampare nei registri) I file di registro del client sono crittografati e / o la cronologia del browser è stata disabilitata su tutti i browser?

score 2 · Answer 2

L'MRN (o id paziente) stesso nell'URL non è un problema. Le API basate su REST di athenahealth prendono gli ID paziente direttamente negli URL e suppongo che abbiano avvocati migliori di te.

Il problema è se l'URL stesso o l'uso del servizio in generale consentirebbero a qualcuno di implicare qualcosa sul paziente. Ad esempio, se hai URL come /history/{MRN}/suicide/definitely-at-risk , allora non va bene. Ma se i tuoi URL sono benigni (tutti hanno una "Storia medica"), quindi inserire l'MRN (o id paziente) nell'URL è perfettamente a posto.

score 0 · Answer 3

Penso che la vera risposta sia HTTPS. Se entrambe le estremità del collegamento sono autorizzate ad accedere alle informazioni sul paziente, è sufficiente proteggerle durante il trasporto. Con HTTPS, i parametri GET sono incapsulati nei dati crittografati: SSL con GET e POST

Anche se stavate usando POST, dovreste comunque crittografare le informazioni in transito a meno che non controlliate l'intero percorso di rete, e forse anche allora.

(Questa è una risposta tecnica, non una risposta legale.)

score 0 · Answer 4

La mia lettura di §164.514 Altri requisiti relativi agli usi e alla divulgazione di informazioni sanitarie protette (pagina 96+ del pdf) è che se non si dispone di informazioni sulla salute nella richiesta, nei registri, nell'URL, ecc., allora è possibile utilizzare un numero di accesso generalizzato anche se si tratta di un numero di record medico. In altre parole, se stai osservando le linee guida generali sulla privacy, usando HTTPS, ecc. E non esponendo alcuna informazione sulla salute (come indicato da Christopher Shultz) l'uso del numero di cartella clinica va bene, anche appropriato (per auditing e simili). Quando questo viene combinato con i dati sulla salute, viene escluso in modo specifico, quindi il numero della cartella clinica insieme al resto delle informazioni diventa PHI perché crea una connessione tra l'individuo e le informazioni sulla salute e questo ha la possibilità di verificarsi per chiunque volendo effettuare la connessione.

In realtà sembra che in isolamento numeri che sono unici e assenti dati supplementari significativi, e usati in un URL, anche se puntano a una cartella clinica, non sono PHI. Sono indicatori di un record. Una volta che uno qualsiasi dei dati contenuti in quel record è combinato con il numero univoco non importa quale sia il numero chiamato (cartella clinica, ecc.) Diventa PHI e si applicano le specifiche di questa sezione. Altre regole possono essere applicate a seconda della natura del numero univoco (es. Numeri di previdenza sociale).

Quando questi tipi di numeri univoci (insieme ad altri dettagli identificativi) vengono rimossi dai dati sanitari, vengono quindi deidentificati.

Infatti, nel caso in cui informazioni trapelate come log con URL trapelate, non sarebbe necessario riportare a meno che l'incidente includesse informazioni sulla salute. Pertanto, mantenere registri di questo tipo, a condizione che non includano informazioni sulla salute, non sembrano richiedere un accordo o una gestione specifici specifici di HIPAA.

La mia lettura del MIT COUHES HIPAA Guidance è stata di grande aiuto nel cercare di capire questo argomento. Leggi la legge, conferma con un esperto e condividi eventuali correzioni.