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.