Gestionar Mensaje HL7

Diseño de Característica
Gestionar Mensaje HL7
Uno de los principales fuertes del estándar HL7 es el paso de información médica
entre diferentes sistemas, el HL7 messaging define como va a ser tratada la
información, su empaquetado y comunicación. Este estándar define el lenguaje,
estructura y tipos de datos requeridos para una integración sin fisuras de un
sistema a otro.
El uso de mensajes será aplicado en la transmisión de información entre el cliente
móvil y el servidor web, estos mensajes serán utilizados para actualizar y consultar
información médica de los pacientes, ya sea por consultas generales o
procedimientos médicos.
HL7 define distintos tipos de mensaje para determinadas circunstancias dentro de
un sistema de salud, en este prototipo se trabajara con una mínima parte de estos
mensajes según el ámbito del proyecto.
A28 ACK/ADT para añadir información al paciente, cualquier información clínica
del paciente será enviada a través de esta codificación.
I05 RQC/RCI para solicitar información clínica del paciente, HC y antecedentes.
O01 ORM para la solicitud de servicios para el paciente.
Mensajes abstractos:
Los mensajes abstractos sirven para describir los datos, cuando se deben enviar y
cuando se presentan errores.
En los mensajes abstractos se pueden encontrar segmentos y algunos de estos
pueden estar entre caracteres especiales como corchetes y llaves.
[…] un segmento entre estos caracteres significa que puede ó no existir (0-1).
{…} un segmento entre estos caracteres significa que puede haber una ó más
repeticiones de este segmento (1-n).
[{…}] un segmento entre estos caracteres significa que puede haber 0 o muchas
repeticiones de este segmento (0-n).
Cuando el segmento no aparece entre estos caracteres significa que el segmento
debe existir una única vez dentro del mensaje.
Los segmentos son agrupaciones de campos, cada campo representa un dato
dentro del mensaje. Los segmentos se identifican por un código único de 3
caracteres.
Los datos contenidos dentro de los campos pueden ser de diferentes tipos y no
todos los campos son necesarios siempre. Los campos también pueden tener
diferentes componentes como el ^ que es usado para separar información, y el
carácter ~ que se usa para incluir valores repetidos dentro de un campo, como dos
números telefónicos.
Mensaje abstracto para A28
ADT
Mensaje ADT
MSH
EVN
PID
[PD1]
[ { NK1 } ]
PV1
[ PV2 ]
[ { DB1 } ]
[ { OBX } ]
[ { AL1 } ]
[ { DG1 } ]
[ DRG ]
[ { PR1
[{ROL}]
}]
[ { GT1 } ]
[
{ IN1
[ IN2 ]
[ {IN3} ]
}
]
[ ACC ]
[ UB1 ]
[ UB2 ]
Cabecera del mensaje
tipo de evento
Identificación del paciente
datos demográficos
Acudientes y familiares cercanos.
Visita Paciente
Visita Paciente – Información adicional.
Información sobre discapacidades
Observaciones/Resultados
Información de alergias
Información de diagnostico
Grupo relacionado al diagnostico
Procedimientos
Rol
Garante
Seguro
Información adicional seguro.
Información de cuota adicional de seguros – CERT.
Accidente
Información de cuenta universal
Información de cuenta universal 92
Los datos que se enviaran por el mensaje de actualización de consulta médica
serán estructurados de la siguiente manera con base a la información manejada
con el prototipo (los valores en los campos resaltados en azul deben ser escritos
tal cual):
MSH|^~\&|DoC||||timestamp||ADT^A28|Identificación_Única|P|2.3|<cr>
EVN|A28|time_stamp|<cr>
PID|||cedula_paciente||apellido_paciente^nombre_paciente|<cr>
PV1||I|||||cedula_pmedico^apellido_pmedico^nombre_pmedico|<cr>
OBX|numero_consecutivo|TX|código_observacion^titulo_observacion|Ob
servacion _subID|observacion||||||F|<cr>
MSH: es el segmento de cabecera del mensaje, el time-stamp debe ser tomado en
el momento de envío del mensaje y siguiendo el formato usado en HL7
(aaaammddhhmmss); La identificación única es un valor con el cual se representa
el mensaje.
EVN: el segmento que describe el evento que genera la atención al paciente, en
este caso se usa para la actualización de la información, el time-stamp funciona de
la misma manera que en MSH y sirve para registrar el momento en que se genera
el evento.
PID: este segmento sirve para identificar al paciente que genera el evento, se
envía la cedula del paciente, el apellido y el nombre del mismo.
PV1: se describe el tipo de visita que se genera y el personal médico que lo
atiende, se envía la cedula del médico, el apellido y nombre del mismo.
OBX: este segmento se puede enviar cuantas veces sea necesario para registrar
el evento generado ya sea una consulta médica o un procedimiento médico. Cada
segmento OBX que sea enviado describe una observación que se le ha practicado
al paciente durante su consulta o procedimiento. El número consecutivo identifica
al segmento dentro del mensaje, este valor debe ser incrementado por cada
segmento adicional que se envíe; El código de observación es un código que
identifica la observación en la aplicación receptora del mensaje, (en el mundo real
se usan códigos como LOINC que son estándares internacionales para codificar
diferentes procedimientos, como el prototipo no tiene estos alcances ni tiene como
objetivo la implementación de estos códigos, han sido omitidos por su gran
extensión, en su lugar se definieron unos propios para el prototipo); el titulo de la
observación está relacionado con el código de observación; Observación sub-id es
un campo que identifica el segmento cuando se envían varios segmentos con el
mismo código de identificación, se usa un valor consecutivo por cada segmento
con el mismo código de identificación dentro del mensaje; el campo de
observación esta formateado dependiendo del código de observación enviado, se
describe el contenido y los valores de la observación.
Tabla 1 códigos de observación para el prototipo
Código
DoC01
DoC02
DoC03
DoC04
DoC05
DoC06
Titulo
Procedimiento
básico
Procedimiento Triage
Adjunto multimedia
Antecedente
Motivo y diagnostico
Examen físico
DoC07
Revisión GPCAVE
DoC08
Revisión
sistemas
por
Formato
Titulo_procedimiento^descripcion_procedimiento
descripcion_triage^evaluación
url_adjunto
Tipo_antecedente^descripción_antecedente
Motivo_consulta^enfermedad_actual^plan_manejo^diagnostico
Estado_general^fc^fr^ta^to^glasgow^cab_cue^cp^abd^genito
urinario^extremidades^neurologicos^osteomuscular^talla^peso
Gestas^partos^cesareas^abortos^vivos^ectopicos^metodo_ant
iconceptivo^ultima_citologia^ciclos^fechaPP^fechaUP
sentidos^cardiovascular^gastrointestinal^neurologico^endocrin
ologico^respiratorio
Mensaje abstracto para I05
RQC
Solicitud de Información clínica
MSH
QRD
[QRF]
{
PRD
[{CTD}]
}
PID
[{NK1}]
[{GT1}]
[{NTE}]
Cabecera de Mensaje
Definición de consulta
Filtro de consulta
RCI
retornar información clínica
MSH
MSA
QRD
[QRF]
{
PRD
[{CTD}]
}
PID
[{DG1}]
[{DRG}]
[{AL1}]
[
{
OBR
[{NTE}]
[
{
OBX
[{NTE}]
}
]
}
]
[{NTE}]
Cabecera de mensaje
Reconocimiento de mensaje
Definición de consulta
Filtro de consulta
datos de proveedor
Datos de contacto
Identificación del paciente
Acudientes y familiares cercanos
Garante
Notas y comentarios
Datos del proveedor
Datos de contacto
Identificación del paciente
Diagnostico
Grupo relacionado al diagnostico
Alergias
Petición de observación
Notas y comentarios
Observaciones/resultados
Notas y comentarios
Notas y comentarios
Los datos que se enviaran por el mensaje de petición de información médica serán
estructurados de la siguiente manera con base a la información manejada con el
prototipo (los valores en los campos resaltados en azul deben ser escritos tal
cual):
Mensaje de solicitud:
MSH|^~\&|DoC||||timestamp||RQC^I05|Identificacion_unica|P|2.3|<cr>
QRD|time_stamp|D|I|identificador_unico|||LI^max_lineas|cedula_pmed
ico^apellido_pmedico^nombre_pmedico|codigo_consulta^titulo_consult
a||desde^hasta|<cr>
PRD|RP|<cr>
PID|||cedula del paciente||apellido del paciente ^ nombre del
paciente|<cr>
QRD: es el segmento usado para definir el tipo de consulta, el time_stamp es el
mismo que se usa para las actualizaciones de información; El identificador único
puede ser el mismo que para el segmento de mensaje, solo que identifica al
segmento como tal; max_lineas es un campo que limita el número de líneas que
se recibe como respuesta del mensaje; los códigos de consulta de igual manera
que los de observación son definidos de manera propia para el prototipo; desde y
hasta, hace referencia del intervalo de resultados que se mostrara, este intervalo
se define en periodos de tiempo, con time-stamps.
PRD: hace referencia a la información del proveedor, en este caso no es
necesaria, pero el estándar exige que se encuentre presente este segmento, se
usa el rol simple Referring Provider.
Código consulta
DoC09
DoC10
DoC11
DoC12
Titulo consulta
HC
Antecedentes
Procedimientos
Consultas generales
Los datos que se enviaran por el mensaje de respuesta de información médica
serán estructurados de la siguiente manera con base a la información manejada
con el prototipo (los valores en los campos resaltados en azul deben ser escritos
tal cual):
Mensaje de respuesta:
MSH|^~\&|DoC||||timestamp||RCI^I05|Identificacion_unica|P|2.3|<cr>
MSA|AA|identificacion_mensaje_solicitud|<cr>
QRD|time_stamp|D|I|identificador_unico|||LI^max_lineas|cedula_pmed
ico^apellido_pmedico^nombre_pmedico|codigo_consulta^titulo_consult
a||desde^hasta|<cr>
PRD|RP|<cr>
PID|||cedula del paciente||apellido del paciente ^ nombre del
paciente|<cr>
OBR||||codigo_consulta|<cr>
OBX|numero_consecutivo|TX|código_observacion^titulo_observacion|Ob
servacion _subID|observacion||||||F|<cr>
MSA: es el segmento de confirmación del mensaje, para el prototipo suponemos
que todos aquellos que solicitan información al servidor por mensajes HL7 son
usuarios validos, en caso de que no sea así, la solicitud será omitida simplemente
y no se generara una respuesta al solicitante. La identificación del mensaje
solicitante debe ser exactamente igual al del mensaje que genero la consulta.
OBR: el segmento de solicitud contiene un código de consulta que debe ser el
mismo que fue solicitado por el mensaje de solicitud.
Mensaje abstracto para O01
ORM
Mensaje de orden General
MSH
Cabecera de Mensaje
[{NTE}]
Notas y comentarios (para la cabecera)
[
PID
Identificación del paciente
[PD1]
datos demográficos
[{NTE}]
Notas y comentarios (para ID del paciente)
[PV1
Visita Paciente
[PV2]]
Visita Paciente- Información adicional
[{IN1
seguro
[IN2]
Información adicional de seguro
[IN3]
Información de cuota adicional de seguros – CERT.
}]
[GT1]
Garante
[{AL1}]
Alergias
]
{
ORC
Orden Común
[
Segmento de detalles de orden OBR, RQD, RQ1, RXO, ODS, ODT.
[{NTE}]
Notas y Comentarios (para los detalles)
[{DG1}]
Diagnósticos
[
{
OBX
Observaciones/Resultados
[{NTE}] Notas y Comentarios (para los Resultados)
}
]
]
{[CTI]}
Identificación de Ensayos Clínicos
[BLG]
facturación
}
Los segmentos que se usaran para la solicitud de órdenes serán:
MSH|^~\&|DoC||||timestamp||ORM^O01|Identificación_Única|P|2.3|<cr>
PID|||cedula_paciente||apellido_paciente^nombre_paciente|<cr>
ORC|NW|<cr>
OBR|numero_consecutivo|||codigo_orden^descripción_orden|<cr>
RXO|^nombre_medicamento^presentación_medicamento||||^dosis||^modo_
uso|<cr>
ORC: es un segmento que describe información sobre la orden, puesto que lo
único que importa dentro del contexto del prototipo es que el mensaje sea valido, y
este campo es obligatorio se minimiza la cantidad de información solo detallando
que la orden que se envía es de asignación inmediata.
OBR: a diferencia de la respuesta de información, en este segmento se usa para
describir las diferentes órdenes que se pueden enviar, seguidas de su descripción
respectiva.
RXO: si lo que se solicita es una orden de farmacia se debe usar este segmento
en vez del OBR.
Código orden
DoC13
DoC14
DoC15
Titulo de orden
Examen
Remisión
Incapacidad
Formato de descripción
Descripción
Descripción^origen
Descripción^días
Para la implementación de estos modelos de mensajes será necesario crear un
intérprete que los codifique y decodifique, tanto en el sistema móvil como en el
servidor, se debe tener especial cuidado en que la sintaxis y orden de los campos
en los mensajes sean los especificados en esta planeación.
Diagramas de secuencia:
En el repositorio (pendiente a subirlos a este apartado al finalizar la revisión)
Diagramas de clases
En el repositorio (pendiente a subirlos a este apartado al finalizar la revisión)
Descripción de clases y métodos
Subsistema Móvil
Clase
InterpreteHL7Message
Métodos
codificarConsulta()
Descripción
El intérprete revisa la consulta
activa que existe para un paciente
y la codifica según el formato
ADT/A28, generando una cadena
ManejadorHTTP
Subsistema Web
de texto que es el mensaje
codificado.
codificarProcedimiento()
El
intérprete
revisa
el
procedimiento activo que existe
para un paciente y la codifica
según el formato ADT/A28,
generando una cadena de texto
que es el mensaje codificado.
Si existen archivos multimedia
asociados al procedimiento, se
envían antes de enviar la
codificación del procedimiento.
Ver
ManejadorHttp.enviarMultimedia
codificarSolicitudInformacion(String El interprete genera un mensaje
codigoConsulta, long fecha)
de solicitud de información para
un paciente activo según el
formato de mensaje RQC/I05. Los
parámetros de entrada son el
código de consulta definido para
RQC/I05 y la fecha de la consulta:
0 para traerlas todas, el valor
actual para traer el último y una
fecha en especifico.
codificarSolicitudServicios()
El Interprete genera un mensaje
de solicitud de servicios según el
formato de solicitud de ordenes
ORM/O01 y accediendo a los
servicios que el médico ha
asignado a un paciente.
decodificarMensaje( String
El interprete debe decodificar un
mensajeHL7)
mensaje HL7 de respuesta, en
este caso el único tipo de mensaje
interpretado es el RCI/I05, previa
identificacion del mensaje se
actualizan todos los campos
correspondientes.
enviarMultimedia(Object o,
Se envía un objeto multimedia,
boolean audio) : String
este objeto se obtiene de la tabla
de adjuntos guardada en el
procedimiento activo. Genera una
conexión con el servidor donde se
almacena
los
archivos
devolviendo una url donde queda
almacenado el archivo.
File
Conexión.views
Métodos
decodificarMensaje(String mensaje) :
String
Descripción
El
interprete
web
debe
decodificar un mensaje HL7
enviado por el cliente, estos son
los mismos mensajes que se
codifican por el cliente el
ADT/A28, ORM/O01 y el
RQC/I05.
En especial para el mensaje
RQC/I05 se debe realizar una
respuesta al cliente que es otro
mensaje HL7, para los demás
mensajes basta con retornar un
“OK”.
codificarMensajeInformacionClinica() Se codifica un mensaje con la
: String
información solicitada por el
cliente móvil acerca de un
paciente, la consulta se hace
directamente en la base de datos
a partir de los valores del
mensaje
de
solicitud
de
información RQC/I05, el mensaje
retornado debe ser el RCI/I05.
guardarMultimedia(Object o, String
Guarda el archivo dentro de una
nombre)
ruta en el servidor, devuelve el
valor de la URL donde queda
asignado el archivo
Plan de pruebas
Pruebas unitarias
Es necesario diseñar pruebas unitarias para el subsistema web y el subsistema
móvil de forma independiente.
Subsistema web
1. Pruebas de la estructura de datos locales (integridad):
Los valores de los campos contenidos en los mensajes deben ser los
mismos que se encuentran en la base de datos del sistema.
2. Condiciones limite:
Se verificaran casos donde un mensaje contenga muchos segmentos
adjuntos, mayores al límite establecido por el sistema.
3. Caminos independientes:
Se validara la forma en cómo se interpreta cada mensaje HL7 que llega al
sistema y que sea tratado de la manera adecuada.
4. Camino de manejos de errores:
Se corregirán todos los errores encontrados durante la evaluación de los
casos de prueba, ya que esta es una característica crítica dentro del
sistema que se enfoca en el intercambio de información entre aplicaciones
independientes que manejan información médica.
Casos de prueba:
Prueba
El mensaje recibido contiene una
identificación de mensaje no valida.
El mensaje recibido contiene un
segmento adicional no especificado.
El mensaje contiene algún campo con
un valor que no es el correcto
El mensaje contiene la información en
un formato correcto, pero la información
no es válida dentro de la base de datos
del sistema.
Los mensajes generados por la
aplicación deben pasar por un validador
de mensajes HL7.
Éxito
El mensaje se acepta y se trata como si
fuera valido.
El mensaje se acepta y se trata como si
fuera valido.
El mensaje se acepta y se trata como si
fuera valido.
La información contenida en el mensaje
se guarda en el sistema de manera
correcta.
El mensaje no es considerado como
válido por la aplicación externa.
Pruebas de integración
En especial este modulo solo se comunica con la base de datos para la obtención
de información, como el sistema web consigo mismo no necesita implementar el
envío de mensajes HL7, no se necesita añadir directamente la funcionalidad con el
sistema.
Subsistema móvil
1. Pruebas de la estructura de datos locales:
Los mensajes enviados desde la aplicación deberán contener información
consecuente con la guardada en el móvil durante los procesos de atención
a pacientes.
2. Condiciones limite:
Se verificara la cantidad de procesamiento que consume la codificación de
cada mensaje y su envío por la red al servidor.
3. Caminos independientes:
Se verificara que cada mensaje diferente que puede ser creado desde el
móvil se envíe correctamente al servidor.
4. Camino de manejos de errores:
Se verificara el comportamiento del sistema cuando el servidor no acepte el
envío.
Casos de prueba:
Prueba
Se enviara un mensaje previo
procedimiento
medico.
(consulta,
evento, TRIAGE)
Se solicitara información sobre un
paciente en específico.
Éxito
El mensaje enviado no corresponde
con el formato planteado.
La información devuelta no es la
correspondiente
al
paciente
seleccionado.
Se enviara un mensaje con el servidor El sistema no detecta la falla.
caído.
Pruebas de integración.
Este apartado del software será usado directamente por los eventos médicos
generados dentro del sistema, envió de consultas de información médica,
actualización de información y solicitud de servicios para los pacientes. Sera
usado directamente por las conexiones enviadas al servidor al momento de la
actualización y conexión con el servidor.
Para este apartado se validara que la información enviada desde la aplicación sea
correctamente añadida en el servidor.
Inspección de diseño
Es recomendable usar para Django un intérprete en python para los mensajes
HL7, el desarrollo de este modulo en móvil, sigue siendo un prototipo puesto que
hasta el momento no se ha encontrado un generador de mensajes HL7 para Java
ME, para la verificación de la escritura de mensajes se pueden usar paginas que
prestan el servicio de validación de mensajes HL7.
Notas de desarrollo.