Historial de página

...

La Norma de la STIC se puede resumir en:

Reglas de Codificación

En el siguiente apartado se describen un conjunto de reglas de codificación que deberán seguir el desarrollo de los servicios necesarios.

Todos los documentos asociados a la definición de un servicio (WSDLs, esquemas XSD (http://www.w3.org/XML/Schema), etc.) deberán estar codificados en UTF-8.

...

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) 5 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 Unificaeste espacio.

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

Los tiempos de respuesta relacionados con los servicios deben cumplir con los siguientes requerimientos: 

Servicios SOAP:

• • Servicios asíncronos: Al tener que limitarse sólo a devolver el acuse de recepción del mensaje, deben de ofrecer una respuesta inferior a 500ms.
  • Servicios síncronos: Debido a que los servicios de esta tipología requieren de un procesamiento, el destino debe responder en menos de un 1 segundo al 80% de los mensajes y en menos de 2 segundos en el 20% restante.

Servicios REST:

• • Este modelo requiere que los tiempos de respuesta sean lo más óptimos posibles, ya que es habitual se puedan lanzar varias llamadas para obtener la información que requiere el origen. Por lo tanto, cada una de estas llamadas rest debe ser inferior a 300ms.

Seguridad

La seguridad en las comunicaciones, es un elemento muy importante a tener en cuenta a la hora de diseñar un servicio. Los mecanismos de seguridad, además de garantizar la integridad, no repudio y confidencialidad de los mensajes, permiten habilitar mecanismos para la identificación y autorización de servicios y usuarios.

...

La siguiente tabla muestra un resumen de los elementos de seguridad esenciales y su recomendación dentro de la STIC.