¿Transmitir el MRN del paciente en una URL del servicio web es una violación de la PHI de HIPAA?

7

Estoy creando un servicio web para acceder a los datos del paciente dentro de nuestro EMR y me gustaría suscribirme a los principios de diseño RESTful. Sin embargo, la idea de incluir el MRN del paciente en una solicitud GET me inquieta. Estaba pensando en ser simplemente "RESTfulesque" y confiar exclusivamente en POSTS para que el MRN pudiera incluirse dentro del cuerpo de la solicitud.

por ejemplo En lugar de

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

Yo usaría

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

PatientID, Type y UserID y Type serían propiedades de encabezado de solicitud.

Parece que la mayoría de los proveedores de EMR usarán los verbos tradicionales REST y expondrán los ID en la URL, pero esto se siente mal. ¿Estoy siendo demasiado paranoico con mi diseño? Quiero que mis servicios sean muy amigables con los desarrolladores, por lo que no quiero romper con los principios de diseño de REST a menos que sea necesario.

¿Estoy arriesgando una violación de HIPAA al exponer MRN de pacientes dentro de una URL de solicitud?

    
pregunta Daniel Wilson 03.01.2015 - 00:32
fuente

4 respuestas

3

Depende de una serie de factores.

Debido a que el Número de registro médico (MRN) es Información médica protegida (PHI), usted es responsable de su Confidencialidad, Integridad y Disponibilidad y es responsable de identificar y proteger contra amenazas razonablemente anticipadas a su seguridad (e integridad) Y contra Usos o divulgaciones razonablemente anticipados e inadmisibles. Regla de seguridad de HIPAA

Aunque HTTPS protegerá los parámetros contra la intercepción, las entradas de registro para las solicitudes GET mostrarán la URL completa sin cifrar tanto en el cliente como en el servidor. Estos crean al menos revelaciones razonablemente anticipadas (como a empleados no autorizados), y también necesitan controles.

¿Qué tipo de controles de acceso hay entre las máquinas cliente y el servidor? ¿Se puede conectar cualquier máquina si proporciona una identificación de usuario y una contraseña que indique un usuario autorizado? ¿O solo ciertas máquinas en combinación con ciertos usuarios? ¿Alguien en el lado del servidor tendría acceso a los archivos de registro que no deberían tener acceso a los datos del paciente? (por ejemplo, ¿los registros de pacientes se encuentran en una base de datos encriptada y, sin embargo, cualquier técnico podría tropezar con los registros)? ¿Los archivos de registro del cliente están encriptados y / o se ha desactivado el historial del navegador en todos los navegadores?

    
respondido por el Dee Hendrick 03.01.2015 - 07:24
fuente
2

El MRN (o la identificación del paciente) en la URL no es un problema. Las API basadas en REST de athenahealth llevan las identificaciones de los pacientes directamente en las URL, y supongo que tienen mejores abogados que usted.

El problema es si la URL en sí misma o el uso de su servicio en general le permitiría a alguien implicar algo sobre el paciente. Por ejemplo, si tiene direcciones URL como /history/{MRN}/suicide/definitely-at-risk , entonces no está bien. Pero si sus URL son benignas (todo el mundo tiene un "Historial médico"), poner el MRN (o identificación del paciente) en la URL es perfectamente correcto.

    
respondido por el Christopher Schultz 27.04.2016 - 23:18
fuente
0

Creo que la verdadera respuesta es HTTPS. Si a ambos extremos del enlace se les permite el acceso a la información del paciente, solo tiene que protegerla en tránsito. Con HTTPS, los parámetros GET se encapsulan en los datos cifrados: SSL con GET y POST

Incluso si estuviera usando POST, aún tendría que cifrar la información en tránsito a menos que controle toda la ruta de la red, y quizás incluso entonces.

(Esta es una respuesta técnica, no una respuesta legal).

    
respondido por el Bob Brown 03.01.2015 - 00:43
fuente
0

Mi lectura de §164.514 Otros requisitos relacionados con el uso y la divulgación de información de salud protegida (página 96+ del pdf) es que si no tiene información de salud en la solicitud, registros, URL, etc., puede usar un número de acceso generalizado incluso si es un número de registro médico. En otras palabras, si está cumpliendo con las pautas generales de privacidad, está utilizando HTTPS, etc. y no está exponiendo ninguna información de salud (como lo indicó Christopher Shultz), el uso del número de registro médico está bien, incluso es apropiado (para auditorías y similares). Cuando esto se combina con datos de salud, se excluye específicamente, por lo que el número de registro médico junto con el resto de la información se convierte en PHI porque crea una conexión entre el individuo y la información de salud, y eso tiene la posibilidad de que ocurra para cualquiera queriendo hacer la conexión.

De hecho, parece que en los números de aislamiento que son únicos e inexistentes de datos significativos adicionales, y que se usan en una URL, incluso si apuntan a un registro médico, no son PHI. Son punteros a un récord. Una vez que cualquiera de los datos contenidos en ese registro se combine con el número único, no importa cómo se llame (registro médico, etc.) se convierte en PHI y se aplican los detalles de esta sección. Se pueden aplicar otras reglas dependiendo de la naturaleza del número único (por ejemplo, números de seguridad social).

Cuando estos tipos de números únicos (junto con otros detalles de identificación) se eliminan de los datos de salud, se desidentifican.

De hecho, en el caso de información como registros con URL filtrados, no sería necesario informar a menos que el incidente incluyera información de salud. Por lo tanto, mantener registros de este tipo, siempre que no incluyan información de salud, no parece requerir un acuerdo o manejo específico de HIPAA.

Mi lectura de la MIT COUHES HIPAA Guidance fue muy útil para tratar de entender este tema. Lea la ley, confirme con un experto y comparta las correcciones.

    
respondido por el jimmont 10.07.2017 - 05:44
fuente

Lea otras preguntas en las etiquetas