Heramientras y tecnologias (soka)

Herramientas y tecnologías

Herramientas y tecnologIas

Las herramientras y las tecnologías para nosotros son como piezas de lego, que uniendo unas con otras nos ayudan a construir las aplicaciones y desarrollos que hacemos diariamente

Herramientas y tecnologIas

VsCode

SourceTree

Oxygen

SoapUI

GitLab

Squirrel

Postman

kiTTY

WinCSP

PeticionesREST: JSON

PeticionesSOAP: XML

Estandares

Python

JavaScript

XSLT

Ensemble

Herramientas y tecnologIas

OAuth 2.0/Open ID

Snomed

Fhir

HL7

kitty

kiTTY es un cliente SSH y telnet para sistemas operativos Windows. Este programa proporciona multitud de opciones, como por ejemplo la posibilidad de hacer SSH Tunneling, entre otras muchas cosas.

Wincsp

WinSCP es un cliente SFTP gráfico para Windows que emplea SSH. Su función principal es facilitar la transferencia segura de archivos entre dos sistemas informáticos, el local y uno remoto que ofrezca servicios SSH

Squirrel

Es un cliente SQL gráfico multiplataforma. Se trata de una aplicación implementada en Java, que te permite gestionar cualquier base de datos compatible con JDBC que es una API que permite el acceso a bases de datos, muy popular en Java. SQuirreL es software libre.

Os voy a enseñar comoconectaros a vuestras bases de datos

Squirrel

Para conectarse a la base de datos de cualquier namespace de IRIS hay que seguir los siguientes pasos: 1. En Drivers buscar “Intersystem Iris”. Hacer doble click. 2. Aparece una Ventana emergente, que hay que completar de la siguiente manera: En la URL de ejemplo hay que poner la IP y el puerto del nodo activo del Mirror donde esté el namespace de la base de datos a la que queremos acceder. Para agregar el driver simplemente es seleccionar agregar y seguir la ruta que aparece en la imagen. Cuando tengamos todo, le damos a “OK”.

Squirrel

3. Ahora hay que crear la conexión con el namespace que queremos. Para ello vamos a la pestaña “ALIASES” y le damos a “+” para crear una nueva conexión.

Ponemos el nombre que queramos (algo que nos ayude a distinguir la conexión). Seleccionamos el driver que hemos configurado antes y añadimos a la URL la base de datos a la que queremos acceder. Ya solo nos queda poner usuario, contraseña y conectar. Para hacer consultas, basta con escribir la petición sql en la pestaña “SQL” y seleccionar el icono

SOAPui

SoapUI es una herramienta de gran alcance diseñada para ayudar en la prueba y el desarrollo de aplicaciones. Permite efectuar el testeo de la web mediante una interfaz simple, fácil e intuitiva. Se pueden utilizar métodos de captura y repetición, simulando servicios web con el envío de mensajes XML desde un sistema origen a un sistema destino y obtener el mensaje de respuesta de este. Es una herramienta que nos ayuda en la realización de pruebas de carga de gran alcance, informes detallados, gráficos, etc...

SOAPui

Si se hace una visión general del programa se observa algo parecido a la imagen, en la que se destacan dos cosas:- Recuadro de mayor tamaño: Navegador en el que se mostrarán todos los proyectos SOAP que se hayan ido creando. - Recuadro de menor tamaño: Icono para crear nuevos proyectos SOAP.

(https://www.adictosaltrabajo.com/2009/12/28/introduccion-soap-ui/)

SOAPui

Creación de un sistema origen 1. Se pulsa el icono de “SOAP” para crear un nuevo proyecto SOAP. 2. Para la creación se utiliza el WSDL Origen (Archivo Inicial). Se pulsa el botón “Browse…” y se abre el archivo deseado. De nombre le pondremos el del servicio.

SOAPui

NOTA: Si se diera el caso de que no tenemos el WSDL del sistema origen, lo que se debe hacer es lo siguiente: Primero se deberá ir al workspace actual en Studio y abrir el archivo del servicio que queremos de la carpeta servicio. Hacer clic en el icono para ir a la página web. Una vez abierta la página hacer clic en donde pone “Descripción del servicio” como se indica en la imagen.

SOAPui

Copiar la ruta de la nueva página que aparece.Pegar la ruta en “Initial WSDL” de la ventana de nuevo proyecto SOAP, por defecto se pondrá un nombre de proyecto al pegarla. 3. Dar clic a “OK” para crear el proyecto.

Tras darle a “OK” se puede observar que en el navegador ya no se encuentra vacío y que se ha creado nuestro proyecto “SXXX” con un “SXXXServiceSoap” que contiene SXXX y SXXXB (el que acaba en B se ignorará ya que normalmente solo habrá uno).

SOAPui

Copiar la ruta de la nueva página que aparece.Pegar la ruta en “Initial WSDL” de la ventana de nuevo proyecto SOAP, por defecto se pondrá un nombre de proyecto al pegarla. 3. Dar clic a “OK” para crear el proyecto.

Tras darle a “OK” se puede observar que en el navegador ya no se encuentra vacío y que se ha creado nuestro proyecto “SXXX” con un “SXXXServiceSoap” que contiene SXXX y SXXXB (el que acaba en B se ignorará ya que normalmente solo habrá uno).

SOAPui

Como se observa en la imagen anterior, en S071 hay un Request. Si se hace doble clic en él, se abre una ventana como se ve a continuación. Aquí vamos a recrear el sistema origen y podremos ver el intercambio de mensajes que envía/recibe el mismo.

SOAPui

Recuadro 1: Muestra el mensaje de entrada que se enviará desde el sistema origen.Recuadro 2: Ahí se pegará o escribirá el mensaje que se desea enviar. Recuadro 3: Ruta del servicio (Normalmente suele ser una ruta tipo http://localhost:5777X/csp/gobsas-XXX/sas.xxx.servicio.SXXX.cls sustituyendo para cada servicio) Recuadro 4: Mostrará el mensaje de respuesta que le llega por parte del sistema destino tras enviar su mensaje de entrada. Recuadro 5: Botón para realizar el envío del mensaje de entrada al sistema destino.

SOAPui

4. El mensaje que se desea enviar se abre con NotePad++ u otro programa de edición de texto y se copia todo el contenido para pegarlo en la zona del mensaje indicada anteriormente (recuadro 2) tal y como se muestra a continuación.

SOAPui

Creación de un sistema origen: Para crear un sistema destino, utilizaremos un procedimiento similar al del sistema de origen, con la única diferencia que se genera una entidad llamada MOCK Service, el cual puede activarse o desactivarse. Los pasos para su creación serán los siguientes: 1. Se pulsa el icono de “SOAP” para crear un nuevo proyecto SOAP. 2. Para la creación se tiene que usar un servicio web (WSDL Destino). Este WSDL se obtiene del contrato atómico del servicio de respuesta o suministrado por el supervisor de la Factoría. 3. Se crea de la misma forma que el origen, con el nombre que se desee, aunque generalmente se escribe “MOCK” y el identificador del servicio destino.

SOAPui

Se puede observar que, en el navegador, se ha creado un proyecto “MOCK SXXX” con un “SXXXServiceSoapPortBinding”.

SOAPui

4. Una vez creado el nuevo proyecto, hay que dar un paso adicional. Para ello se hace clic con el botón derecho en “SXXXServiceSoapPortBinding”, y se deberá seleccionar la opción Generate Soap Mock Service.

SOAPui

5. Una vez hecho esto, debemos determinar la operación del Mock Service a utilizar. Para ello, pulsamos con el botón derecho y seleccionamos New Mock Operation. En el pequeño menú desplegable, aparecerán las operaciones contenidas en el Mock. Seleccionamos la que nos interese (Generalmente es una) y le damos a aceptar. 6. Si abrimos ese Mock Operation, podremos ver que hay un Response. Este Response, simula la respuesta que nos va a ofrecer el destino cuando reciba un mensaje, así que pegaremos el XML de respuesta entre las etiquetas.

SOAPui

SOAPui

7. Una vez hecho esto, vamos a configurar el Mock Service y a arrancarlo. Si hacemos doble clic en él (No en la operación), obtendremos una ventana similar a esta:

- Recuadro 1: Configura el MOCK. - Recuadro 2: Arranca el MOCK.

SOAPui

8. Para la configuración, pulsamos en el engranaje y obtendremos una ventana como esta:

Normalmente la configuración (A excepción del puerto que es variable) es como esta. Tiene que ser igual al campo URL del Servicio Web que está en la operación de configuración de producción (Portal del Gestión). Ya solo queda arrancar el MOCK mediante el icono de Play.

POSTMAN

Partiendo de la idea de testear las APIs, Postman nos ofrece un conjunto de utilidades adicionales para poder gestionar las APIs de una forma más sencilla. Es por ello por lo que nos va a proporcionar herramientas para documentar los APIs, realizar una monitorización sobre las APIs, crear equipos sobre un API para que trabajen de forma colaborativa… convirtiendo a Postman plataforma de desarrollo de APIs que se basa por un modelo de desarrollo API First.

oXYGEN

oXygen XML Editor es un programa editor de XML. En él se puede ver el contenido de los mensajes con sus correspondientes nodos y hacer comprobaciones para ver que el contenido del mensaje XML está correcto.

gitlab

GitLab es una suite completa que permite gestionar, administrar, crear y conectar los repositorios con diferentes aplicaciones y hacer todo tipo de integraciones con ellas, ofreciendo un ambiente y una plataforma en cual se puede realizar las varias etapas de su SDLC/ADLC y DevOps.

VsCode

Visual Studio Code es un editor de código fuente independiente. Incluye soporte para la depuración, control integrado de Git, resaltado de sintaxis, finalización inteligente de código, fragmentos y refactorización de código. Además, tiene un amplio catálogo de extensiones, que además de aportar funcionalidades interesantes, hace que VS pueda admitir casi cualquier lenguaje de programación.

VsCode

Podemos crear un proyecto nuevo, abrirlo desde una carpeta local o clonar un proyecto que tengamos en un repositorio de Git

VsCode

Como se puede ver en la imagen anterior, podemos crear un proyecto nuevo, abrirlo desde una carpeta local o clonar un proyecto que tengamos en un repositorio de Git. Vamos a ver con detalle las funcionalidades del menú lateral: 1. Explorador de archivos: Cuando importemos o creemos un proyecto, se listarán cada uno de los archivos de los que consta. 2. Buscador 3. Visual Studio Code consta de una función para depurar código directamente desde el editor. 4. Biblioteca de extensiones. 5. Esta parte es para trabajar con GIT directamente. Podemos crear y cambiarnos de rama, hacer commits … entre otras muchas cosas.

SourceTree

SourceTree simplifica la forma en que interactúa con sus repositorios de Git para que pueda concentrarse en la codificación. Permite visualizar y administrar sus repositorios a través de una sencilla interfaz de usuario que provee la aplicación.

xslt

Una de las principales funciones de los ESB es la modificación de datos y la transformación de estructura de los mensajes. Con XPATH obtenemos valores y contenidos tanto de las etiquetas como de los atributos. Sin embargo, para modificar los mensajes en sí, se hace uso de XSLT. XSLT es una tecnología basada en la definición de una plantilla, la cual toma como entrada un mensaje XML y devuelve como salida un mensaje XML transformado. Estas plantillas hacen un uso extendido de XPATH para construir el nuevo XML, tanto a nivel de condicionales como de inserción de contenidos del XML de entrada.

xslt(Plantilla)

xml

xml

transformado

xslt

XSLT es una herramienta que proporciona múltiples plantillas, procedimientos y funciones. Dotando de mucha flexibilidad a la hora de transformar los mensajes. Esto se aprovecha para, además de transformar los mensajes, para validar el contenido de los mensajes que llegan al ESB. En el ESB aplicamos una transformación XSLT sobre el mensaje origen, obteniendo un ACK o NACK como mensaje transformado según cuente o no con sus restricciones cumplidas (existencia de nodos, valores por defecto, longitudes máximas, etc.)

xslt

Relativo al validador de contenido, al igual que la transformación, también se aplica sobre el mensaje de respuesta. Esta validación XSLT suele hacerse al principio del procesamiento de los mensajes para que, en caso de validación no superada, notificar al origen y finalizar la comunicación.

xslt

TRANSFORMACIÓNA partir de esta imagen iremos viendo paso a paso el XSLT para ver qué contiene y cómo se define:

El funcionamiento es en base a templates. Cuando el match de un template se cumple, se realizan las acciones contenidas en él. La barra "/" representa el nodo raíz, entonces ese template se activa con el nodo raíz del mensaje XML de entrada. Dentro del primer template puedes observar que se hace uso de la sentencia <xsl:apply-templates select="/descendant-or-self::node()/*[local-name()='Mensaje']"/>, donde se utiliza un XPATH. Esta función propia de XSLT sirve para aplicar otros templates.

xslt

El segundo template del XSLT sirve para copiar sobre el mensaje de salida el trozo XPATH del mensaje origen, permitiendo de este modo coger partes completas del mensaje origen para construir la transformación. Otro aspecto destacable es la función xsl:value-of, que permite insertar contenido procedente del mensaje origen, de otras funciones (como en este caso con la función date) o incluso parámetros que se pasen al XSLT.

xslt

VALIDACIÓN DE CONTENIDO Partiendo de una imagen de referencia: Aquí puedes ver un mensaje ACK bajo el estándar HL7. Sobre ese mensaje, que puede ser una respuesta de cualquier sistema destino, vamos a validarlo para ver si cumple los requisitos exigidos para confirmar que es un mensaje ACK correcto y válido.En primer lugar, destacar el xsl:template, donde hacemos uso de un namespace denominado hl7 que definimos en el propio XSLT y es coincidente con el namespace por defecto del mensaje de entrada.

xslt

Posteriormente, se utiliza un xsl:if, donde en el test, y con el uso de XPATH, definimos una condición que, si se cumple, inserta varios nodos o etiquetas en el mensaje de salida. En XSLT, además de los xsl:if, también se hace un uso común de los xsl:for-each para los nodos repetitivos de los mensajes.

xslt

De este modo funciona una validación XSLT, aplicando sobre un mensaje XML de entrada diversas comprobaciones para construir otro mensaje XML con referencias a la validación no superada. De este modo, si un mensaje es válido, la transformación devolverá únicamente la etiqueta de apertura y cierre: <ACK/>. En caso contrario, devolverá información del error.

JAVASCRIPT

JavaScript es un lenguaje de programación que los desarrolladores utilizan para hacer páginas web interactivas. Desde actualizar fuentes de redes sociales a mostrar animaciones y mapas interactivos, las funciones de JavaScript pueden mejorar la experiencia del usuario de un sitio web.Se define como orientado a objetos, basado en prototipos, imperativo, débilmente tipado y dinámico.

PYTHON

Python es un lenguaje de alto nivel de programación interpretado cuya filosofía hace hincapié en la legibilidad de su código, se utiliza para desarrollar aplicaciones de todo tipo. Además, en la OTI lo usamos para el desarrollo de los bots de telegram

PETICION REST: JSON

JSON es un formato de texto para representar información y utilizado para intercambiarla. La intención y el uso es disponer de un lenguaje que permita la interconexión entre los sistemas. Desde hace algunos años, en el catálogo de servicios web de la Oficina de Interoperabilidad se han incrementado sustancialmente aquellos que envían y reciben mensajes en formato JSON (principalmente, servicios REST que se enseñará más adelante). JSON es fácil de entender, leer y comprender, así que para conocer mejor sus particularidades nos iremos basando en el siguiente ejemplo:

PETICION REST: JSON

En este pequeño ejemplo podemos ver todas las particularidades propias de JSON: - El mensaje JSON representa un objeto, así que siempre va a empezar con una apertura { y va a terminar con un cierre }. - Está conformado por pares con formato "nombre":"valor", donde nombre representa la descripción o identificador de la información y valor es el valor asociado. Estos valores pueden ser de texto (puestos entre comillas, como Extracción de muestras en el ejemplo), numéricos (sin comillas, como la sala. Los números con decimales se separan con punto), booleanos (como activo, permitiendo los valores true o false, nulos (con el valor null) y tanto arrays (definidos con corchetes [...] y cada elemento separado por coma. Por ejemplo: ["azul","rojo","amarillo"]) como objetos (conjunto de pares nombre-valor dentro de otro nombre. En el ejemplo cada muestra es un objeto compuesto por nombre, valor y activo. Muestras es un array de objetos en este caso) … - Los pares nodo-valor pertenecientes a un mismo objeto, ya sea a la raíz o a uno interior, se separan por comas.

PETICION SOAP:XML

La gran mayoría de mensajes que pasan por los ESB son mensajes XML. Siendo estrictos en la definición, XML es un metalenguaje que permite definir lenguajes de marcas, almacenando datos de forma legible y permite una amplia expansión y utilización. Su nombre de lenguaje de marcas viene determinado por el hecho de que XML está compuesto de elementos denominados marcas, nodos o etiquetas (la forma más común de llamarlo). Una etiqueta tiene una apertura y un cierre, siendo de la siguiente forma: <nombreEtiqueta>...</nombreEtiqueta>, yendo entre los puntos suspensivos el contenido de esa etiqueta. Si una etiqueta no tiene contenido, la apertura y el cierre pueden estar unidos de esta forma: <nombreEtiqueta/>

PETICION SOAP:XML

- Siempre debe existir una etiqueta o nodo raíz que engloba al resto. Un mensaje XML no es válido si cuenta con varias etiquetas al primer nivel:

Hay ciertas restricciones que un mensaje XML tiene que cumplir para ser un mensaje XML válido. Principalmente, son: - Debe seguir una estructura estrictamente jerárquica. Es decir, una etiqueta abierta dentro de otra debe ser cerrada dentro de la misma. En este sentido, se actúa en "modo pila" (la última etiqueta abierta será siempre la primera etiqueta cerrada):

PETICION SOAP:XML

- Es Case Sensitive, lo que significa que hay distinción entre mayúsculas y minúsculas. Pese a estas restricciones, es muy flexible para estructurar los datos y dotarlos de significado, al poder nombrar las etiquetas de tal forma que sean descriptivas del valor que contienen, por ejemplo <precio>100</precio>, pudiendo repetirse las etiquetas a lo largo del mensaje sin ningún problema. Además, cuenta con capacidades de extensibilidad, permitiendo añadir nuevas etiquetas a los mensajes sin (en teoría) afectar a los sistemas que no esperan dichos nodos. La realidad luego suele ser distinta y, ante etiquetas no esperadas, pueden producirse errores.

PETICION SOAP:XML

En la siguiente imagen, verás los conceptos que definen un mensaje XML y que te servirán para controlar mejor esta tecnología:

PETICION SOAP:XML

- Prólogo: No forma parte del cuerpo del mensaje XML, es opcional y sirve, generalmente, para establecer la versión de XML y la codificación del cuerpo del mensaje. También pueden incluir la declaración standalone, que indica si la información que contiene el cuerpo es completa y autónoma para su interpretación.

PETICION SOAP:XML

- Cuerpo: Es el contenido de información del mensaje. Engloba desde la apertura de la etiqueta raíz hasta el cierre de esta.

PETICION SOAP:XML

- Comentario: La forma de añadir comentarios es tal y como puede verse en el ejemplo: <!-- ... -->. Importante tener en cuenta que los comentarios pueden ser multilínea (aunque no se aconseja). De esta forma, todo lo contenido entre la apertura y cierre de comentario, esté en la misma línea o no, se considera comentario y no se interpreta.

PETICION SOAP:XML

-- Atributo: Los atributos son información que se añaden a una propia etiqueta, no a su contenido. Como puede verse en el ejemplo, sirven para añadir información diferenciadora entre dos etiquetas con el mismo nombre.

PETICION SOAP:XML

- Entidad predefinida: Al igual que en otros lenguajes, cuando se quiere utilizar algún carácter especial como contenido del mensaje, este carácter debe escaparse. La forma de escapar en XML es usando el nombre asociado al carácter con el prefijo "&" y el sufijo ";".

PETICION SOAP:XML

- CDATA: La sección CDATA, cuya apertura y cierre es: <![CDATA[ ... ]]>, hace que el contenido sea analizado como una cadena de caracteres de texto y no como caracteres de texto. En el ejemplo puede verse como el contenido de la etiqueta Autor es el mismo, pero en uno utilizándose la entidad predefinida y en el otro la sección CDATA. Es importante entender lo que ofrece CDATA, puesto que, si introducimos un texto con estructura XML dentro, será texto y en ningún momento etiquetas del cuerpo del mensaje.

HL7

HL7 es un protocolo de comunicaciones para el intercambio de datos en entornos de salud cuyo objetivo es definir y publicar especificaciones y protocolos para comunicar sistemas de información sanitarios, diferentes, dispersos y heterogéneos. En este sentido, es importante que entiendas que HL7 no es una aplicación, ni una estructura de datos o especificación, es un estándar con tal de homogeneizar la forma en la que se envía mensajería sanitaria. Que entiendas todas las particularidades de HL7 y de sus versiones (dentro de Interoperabilidad en el SAS, se usa la versión 2.5) no es el objetivo de esta formación inicial, donde sí aprenderás conceptos básicos de HL7 para poder desenvolverte. Hay que tener en cuenta que la gran mayoría de mensajería XML que pasa a través de los ESB es HL7, de ahí la importancia de este tema.

HL7

Tomaremos como referencia la siguiente imagen que representa un mensaje HL7 ACK en formato XML:

HL7

Un mensaje HL7 tiene un nodo raíz que identifica su propósito y el evento disparador que define el evento. Por eso, en la mayoría de los mensajes HL7 que veas (menos en los ACK), veras que su nodo raíz está compuesto por "Tipo de mensaje_Evento disparador". Cada mensaje HL7 está compuesto por segmentos que, a su vez, está compuesto por nodos. Cada segmento aporta una información específica. Por ejemplo, todos los mensajes cuentan con el segmento MSH (Message Header) que cuenta con información propia del mensaje. Hay una gran cantidad de segmentos, algunos muy recurrentes como el PID (Patient identification), que tiene información del paciente (nombre, apellidos, dirección, etc.).

HL7

Los nodos, al igual que los segmentos, representan información específica. Estos nodos pueden ser complejos (cuentan con más nodos en su interior) o simples (cuentan con un valor ya sea numérico, de texto, un código, etc.). Por ejemplo, los nodos TS (timestamp) representan fechas. El formato de fecha en HL7 es peculiar y sigue el patrón yyyymmddhhmiss.

HL7

Todos los mensajes cuentan con un GUID, que viene en el nodo MSH.10. Este código es un identificador único que identifica en exclusiva a ese mensaje. Está compuesto por 32 caracteres (o 36, si incluye los cuatro guiones). Cuando existe la necesidad de buscar algún mensaje concreto entre todos los que viajan a través del ESB, suele ser uno de los filtros que se utilizan (siemrpe y cuando se disponga del valor, claro está). Como se ha visto, este es un mensaje ACK. La forma en la cual se sabe la diferencia entre un ACK y un NACK es atendiendo al valor del nodo MSA/MSA.1. Si el valor es AA, es un ACK correcto. En caso de error, el valor de este nodo será AE.

HL7

Ya hemos roto el hielo con un primer ejemplo de mensaje HL7. Como pudiste aprender en Bloque I - Interoperabilidad, en el ESB definimos servicios web. Cada servicio web cuenta con un mensaje de entrada y un mensaje de salida. Estos mensajes deben cumplir el estándar, requisitos de implementación y restricciones de contenido, tamaño y obligatoriedad. Toda esta información se recoge en los contratos atómicos. En las siguientes páginas aprenderás lo que necesitas saber de HL7 para interpretar correctamente un contrato atómico. Lo primero es que te descargues este contrato atómico para que veas cómo se agutlina en este documento toda la información necesaria sobre el servicio. Aunque te recomendamos que te lo leas entero, en este tema nos centraremos en los apartados sobre el detalle del mensaje (puntos 2.4.2 y 2.4.3) y en el apartado de los segmentos HL7 (punto 2.4.4).

HL7

El apartado 2.4.2 y 2.4.3 tienen la siguiente información:

HL7

Esta información define la estructura a nivel de segmentos que puede tener los mensajes, tanto el de entrada del servicio (mensaje OMS_O05 del apartado 2.4.2) como el de salida (mensaje ACK del apartado 2.4.3). Hay que tener en cuenta los siguientes aspectos a la hora de entender la estructura de los mensajes:

• Un segmento que no esté contenido ni entre {...} y ni entre [...] significa que es obligatorio y único en el mensaje, debiendo aparecer una sola vez. Puede verse que el segmento MSH (en ambos mensajes) y el segmento MSA (en el mensaje ACK) son así.
• Un segmento o bloque de segmento que esté contenido entre [...] significa que es opcional. Es decir, debe aparecer entre 0 y 1 veces en el mensaje. En el mensaje OMS_O05, el segmento RQ1 es opcional.
• Un segmento o bloque de segmento que esté contenido entre {...} significa que es repetitivo. Es decir, debe aparecer entre 1 y n veces en el mensaje. En el mensaje OMS_O05, el grupo de segmentos que conforman el ORDER son así. Por cada bloque ORDER que haya, deben venir obligatoriamente informados los segmentos ORC y RQD y, opcionalmente, el segmento RQ1. En el mensaje ACK, es así el nodo ERR. Ya que cuando sea un NACK (ACK AE) debe venir informado el error o errores que han provocado que no sea un ACK (ACK AA).

HL7

• Para definir un segmento o conjunto de segmentos como opcional y repetitivo, deben estar contenidos entre [{...}], permitiendo así que dichos segmentos vengan informados entre 0 y n veces.

El otro apartado del contrato con especial interés es el 2.4.4, donde se define estáticamente todos los nodos que conforman los segmentos del mensaje. Es decir, en un contrato atómico hay tantos segmentos detallados como segmentos haya en la estructura del mensaje. Tomemos la siguiente imagen con el detalle del segmento ORC de ejemplo:

HL7

Veamos qué representa cada columna:

• La columna Campos describe el número identificativo del nodo dentro del segmento. En este caso, el campo 1 en el mensaje HL7 será <ORC.1>...</ORC.1>.
• La columna Long. restringe el tamaño máximo del nodo. Esta columna tiene su utilidad sobre todo en los nodos finalistas o simples, aquellos que tienen contenido que no son nodos. En la imagen, por ejemplo, serían los nodos 1, 2.1, 2.3, 3.1, 5, etc. Esta restricción de longitud suele contemplarse en los XSLT.

HL7

• La columna Tipo describe el tipo HL7 del nodo. A la hora de interpretar un mensaje suele dar confusión, pero es fácil de entender si se aplica la siguiente regla: En un mensaje, un nodo tendrá como identificador el tipo del nodo padre. De este modo, en un mensaje el nodo ORC 2.1 sería <ORC.2><EI.1>...</EI.1></ORC.2>, no sería <ORC.2><ST.1>...</ST.1></ORC.2>.
• La columna Opt puede tomar cuatro valores. El valor R, indicando que ese nodo es Requerido y debe venir siempre informado en el mensaje. El valor RE, que ese nodo es Requerido si existe la información que transmite dicho nodo. A nivel de validación XSLT o XSD, no debe considerarse obligatorio. El valor O, indicando que el nodo es Opcional y, se tenga la información o no, puede o no transmitirse en el mensaje. Y por último el valor C, indicando que es Condicional su requerimiento atendiendo a alguna condición que debe venir especificada en el propio contrato atómico (que otro nodo tenga un cierto valor, por ejemplo).

HL7

• La columna Rep. detalle si el nodo es repetitivo. Al igual que puede haber segmentos repetitivos, lo mismo pasa con los nodos. En caso de serlo, en la columna viene una 'Y' (de Yes). Si no son repetitivos, vienen vacíos o con una 'N'. Cuando cada repetición puede tener valores concretos, viene una fila por nodo y repetición, indicándose en esta misma columna a qué repetición pertenece con el valor 'Y' (Rep. X).
• La columna Tabla identifica si los valores permitidos del nodo están recogidos en alguna tabla maestra.
• La columna Información Servicio ofrece el detalle del nodo, desde su descripción funcional hasta su valor o valores por defecto. En caso de venir información en la columna Tabla y valores por defecto en esta, tiene más prioridad los valores por defecto descritos en esta columna.

HL7

Ya hemos visto lo básico de HL7 y tienes los conocimientos necesarios para saber interpretar un contrato atómico, desde la estructura del segmento hasta el detalle de todos los nodos que lo componen. En esta última página del tema vamos a profundizar un poco más en HL7. HL7, como tal, no es un estándar condicionado a XML, sino que cuenta con su propia representación del mensaje. Esta representación puede también hacerse en XML como hemos visto. En la jrgea usada en el proyecto, hablamos de esta forma distinta de representar un HL7 como HL7 plano y, en la siguiente imagen, puedes ver cómo es y su comparación con XML:

HL7

Un mensaje HL7 plano es un mensaje donde cada segmento es una línea y la información está separada por ciertos caracteres especiales. Los bloques azules que ocultan información es por cuestioens de privacidad al tratarse de un mensaje real sacado de un ESB distribuido de producción. Aunque la imagen es muy representativa y puedes ver la correlación entre XML y HL7 plano, vamos a describir cada aspecto:

• El caracter | se utiliza para separar campos. Los campos son los nodos de primer nivel (MSH.1, MSH.2, MSH.3, etc.).
• El caracter ^ se utiliza para separar componentes. Los componentes son los nodos de segundo nivel (MSH.3.1, MSH.3.2, MSH.4.1, etc.).
• El caracter & se utiliza para separar subcomponentes. Los subcomponentes son los nodos de tercer nivel (PID.3.9.1, PID.3.9.2, etc.).

HL7

• Para definir un campo, componente o subcomponente nulo (en XML significa que no viene informado) se deja vacío (aunque en la imagen veas el caracter · a la hora de escribirlo es vacío). De esta forma, para definir un campo vacío, el mensaje HL7 plano tendría: ||. ¿Qué pasa si el valor del campo es una cadena vacía? ¿Cómo se distingue del valor nulo? Pues en dicho caso, tendría: |""|. Esta misma regla se aplica también para componentes (nulo: ^^, vacío: ^""^) y para subcomponentes (nulo: &&, vacío: &""&).
• En el día a día, hablando con tu equipo, no escucharás la diferenciación entre campo, componente o subcomponente, se denominarán a todos nodos o campos por comodidad. Con esta última pincelada de HL7 acaba tu formación sobre el estándar. En la OTI también trabajamos con otro estándar, de nombre FHIR, aunque de momento está fuera de esta formación inicial.

FHIR

La mayoría de los mensajes JSON que pasan a través de los ESB siguen el estándar sanitario FHIR FHIR, al igual que HL7, es un estándar sanitario que actualmente está en expansión y la adopción de uso en servicios REST con JSON es cada vez mayor. Define un conjunto de capacidades para su uso en todo el proceso de atención médica, en todas las jurisdicciones y en muchos contextos diferentes. Los conceptos básicos de la especificación FHIR son relativamente sencillos. Más información:https://hl7.org/FHIR/resourcelist.html

snomed

SNOMED CT (Systematized Nomenclature of Medicine – Clinical Terms) es la terminología clínica integral, multilingüe y codificada de mayor amplitud, precisión e importancia desarrollada en el mundo. SNOMED CT es, también, un producto terminológico que puede usarse para codificar, recuperar, comunicar y analizar datos clínicos permitiendo a los profesionales de la salud representar la información de forma adecuada, precisa e inequívoca. La terminología se constituye, de forma básica, por conceptos, descripciones y relaciones. Estos elementos tienen como fin representar con precisión información y conocimiento clínico en el ámbito de la asistencia sanitaria.

OAUTH2.0/OPEN ID

OAuth 2.0, que significa “Open Authorization” (autorización abierta), es un estándar diseñado para permitir que un sitio web o una aplicación accedan a recursos alojados por otras aplicaciones web en nombre de un usuario. OpenID es un estándar de identificación digital descentralizado, con el que un usuario puede identificarse en una página web a través de una URL (o un XRI en la versión actual) y puede ser verificado por cualquier servidor que soporte el protocolo.

PRESENTATION LOREM IPSUM DOLOR

Section 01

LOREM IPSUM DOLOR SIT

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt

PRESENTATION LOREM IPSUM DOLOR

LOREM IPSUM DOLOR SIT

• Lorem ipsum dolor sit amet, consectetuer adipiscing elit
• Ut wisi enim ad minim veniam, quis nostrud exerci tation
• Lorem ipsum dolor sit amet, consectetuer adipiscing elit
• Ut wisi enim ad minim veniam, quis nostrud exerci tation
• Lorem ipsum dolor sit amet, consectetuer adipiscing elit
• Ut wisi enim ad minim veniam, quis nostrud exerci tation

PRESENTATION LOREM IPSUM DOLOR

LOREM IPSUM DOLOR SIT

LOREM IPSUM DOLOR SIT

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.

+info

+info

PRESENTATION LOREM IPSUM DOLOR

Lorem ipsum dolor sit amet, consectetuer adipiscing elit

Lorem ipsum dolor sit amet, consectetuer adipiscing elit

+info

+info

Lorem ipsum dolor sit amet, consectetuer adipiscing elit

Lorem ipsum dolor sit amet, consectetuer adipiscing elit

+info

+info

PRESENTATION LOREM IPSUM DOLOR

LOREM IPSUM DOLOR SIT AMET

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam

+info

PRESENTATION LOREM IPSUM DOLOR

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod"

Lorem ipsum dolor

PRESENTATION LOREM IPSUM DOLOR

"Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh"

Lorem ipsum dolor

"Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh"

Lorem ipsum dolor

"Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh"

Lorem ipsum dolor

PRESENTATION LOREM IPSUM DOLOR

LOREM IPSUM DOLOR SIT AMET

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet

+info

PRESENTATION LOREM IPSUM DOLOR

LOREM IPSUM DOLOR

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam

PRESENTATION LOREM IPSUM DOLOR

+info

+info

+info

+info

+info

+info

PRESENTATION LOREM IPSUM DOLOR

ViDEO

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod

+info

PRESENTATION LOREM IPSUM DOLOR

LOREM IPSUM DOLOR

Lorem ipsum dolor sit amet, consectetuer

+info

LOREM IPSUM DOLOR

Lorem ipsum dolor sit amet, consectetuer

+info

PRESENTATION LOREM IPSUM DOLOR

Lorem ipsum dolor sit amet, consectetuer adipiscing elit

Lorem ipsum dolor sit amet, consectetuer adipiscing elit

Lorem ipsum dolor sit amet, consectetuer adipiscing elit

+info

+info

+info

PRESENTATION LOREM IPSUM DOLOR

PROCESO 01

PROCESO 02

PROCESO 03

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh

+info

+info

+info

PRESENTATION LOREM IPSUM DOLOR

75%

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut

+info

PRESENTATION LOREM IPSUM DOLOR

VERSUS 01

VERSUS 02

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore.

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore.

+info

+info

PRESENTATION LOREM IPSUM DOLOR

VERSUS 01

VERSUS 02

+info

+info

PRESENTATION LOREM IPSUM DOLOR

2010

2030

1990

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet

2000

2020

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet

PRESENTATION LOREM IPSUM DOLOR

Lorem ipsum dolor sit amet, consectetuer adipiscing elit

1990

Lorem ipsum dolor sit amet, consectetuer adipiscing elit

2000

Lorem ipsum dolor sit amet, consectetuer adipiscing elit

2010

Lorem ipsum dolor sit amet, consectetuer adipiscing elit

2020

Lorem ipsum dolor sit amet, consectetuer adipiscing elit

2030

PRESENTATION LOREM IPSUM DOLOR

40%

35%

Lorem ipsum dolor sit amet, consectetuer adipiscing elit

25%

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet

PRESENTATION LOREM IPSUM DOLOR

LOREM IPSUM DOLOR SIT

35%

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commod.

+info

PRESENTATION LOREM IPSUM DOLOR

35%

LOREM IPSUM DOLOR SIT

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore

25%

LOREM IPSUM DOLOR SIT

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore

40%

LOREM IPSUM DOLOR SIT

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore

PRESENTATION LOREM IPSUM DOLOR

NAME

name

name

name

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet

PRESENTATION LOREM IPSUM DOLOR

PRESENTATION LOREM IPSUM DOLOR

Thanks!

LoREM IPSUM DOLOR SIT