...
El uso de un estándar de mensajería nos permite disponer de una semántica común para común para el intercambio de datos entre los distintos sistemas. Por este motivo, nos ceñimos al estándar HL7 en su versión 2.5, tanto en formato XML como en formato plano ER7, HL7 FHIR Release 3 (STU) 4 y HL7 CDA para las comunicaciones entre los distintos sistemas sanitarios.
...
En el caso de HL7 v2.5, se establece como prioritario el formato XML (http://www.w3.org/XML/) para toda la nueva mensajería que se defina para el catálogo de servicios. Se establecen los trabajos necesarios para pasar la mensajería creada hasta la fecha en texto plano, a formato XML, en coordinación con los sistemas de información impactados por estar enviando o recibiendo mensajería en formato texto plano. En próximas versiones de este documento se establecerá como único formato válido el XML, quedando prohibido a partir de ese momento el formato texto plano. El calendario de validez de la mensajería corporativa en formato texto plano vendrá marcada por la STIC y será anunciada convenientemente en el portal Unifica.
En el caso de HL7 FHIR, se establece como prioritario el formato JSON para toda la nueva mensajería que se defina para el catálogo de servicios.
Para las invocaciones REST se debe respetar el protocolo HTTP donde el método (GET, POST, PUT, PATCH, DELETE) tiene un significado específico. Otros métodos que se utilizan son OPTIONS y HEAD. Una API debe proveer un mensaje de error útil en un formato conocido. La representación de un error debe no ser diferente a la representación de cualquier recurso, con su propio set de campos.
En cuanto al filtrado y la búsqueda de resultados, se debe mantener la URL base de recursos tan simple como sea posible. Se debe tener en cuenta lo siguiente:
- Un parámetro de búsqueda siempre debe estar contemplado en la definición del recurso como atributo.
- Los valores permitidos dentro de un filtro deben corresponderse con los establecidos en la definición.
Trazabilidad de Mensajes
La identificación de los mensajes y endpoints involucrados en los procesos de comunicación, es un elemento esencial a la hora de realizar procesos de auditoría, monitorización, detección de duplicados, etc. Además, estos mismos elementos posibilitan la creación de un gran número de procesos de enrutamiento y mediación basados en los mismos.
...
- Todos los sistemas que envíen un mensaje al ESB deben garantizar que en caso de reenviar ese mensaje al ESB, el identificador del mensaje que se informa en la cabecera del mismo es único.
- El ESB garantiza que no procesará dos veces un mismo mensaje (es decir, no procesará un mensaje con un identificador de mensaje ya procesado).
- Todos los sistemas que reciban un mensaje desde el ESB deben garantizar que no procesan dos veces el mismo mensaje (es decir, que no procesará un mensaje con un identificador de mensaje ya procesado).
- Además, es obligatorio incluir en los planes de pruebas funcionales estos escenarios entre los casos de uso de error, para garantizar que de producirse esos timeouts en producción, ningún mensaje va a ser procesado más de una vez.
Por otro lado, para los servicios definidos sobre el estándar HL7 FHIR se debe realizar un control y gestión de versionado.
Tiempos de respuesta de los servicios
...