Arxius de l'autor: Nestor González Vila

Nestor González Vila

Sobre Nestor González Vila

Estudiant Grau en Enginyeria Informàtica, treballo al CCI-TCM actualment en la línia d’entorns d’interoperabilitat.

Pàgina web:

Review de Messaging Workbench

Leer en castellano
 

L’entorn de treball de missatgeria Messagging Workbench (MWB) és una eina de productivitat polivalent destinada a implementadors d’HL7 v2.x. Aquesta eina vol facilitar el ràpid desenvolupament d’especificacions i informes. MWB també incorpora un servei de validació de missatges en línia i un generador de missatges per utilitzar en proves. MWB permet la documentació dels missatges/perfils HL7 que un equip de desenvolupament en farà ús i provarà aquestes definicions per tenir consistència amb HL7 i els altres estàndards locals.

Els missatges poden ser creats sobre la base dels arxius de llibreria que representen en cada versió de l’estàndard HL7, per l’entrada inversa o a través d’entrada manual. A més es poden desenvolupar biblioteques addicionals per a convencions implementades a nivell local. L’eina també inclou un banc de diagrames MWB per facilitar una major varietat de formes redimensionables i configurables per així crear múltiples diagrames de forma lliure per a cada perfil. Els diagrames també poden ser importats d’altres eines que produeixen sortides BMP o JPG tal com pot ser Visio.

Amb Messaging Workbench es poden generar, imprimir i exportar una àmplia gamma d’informes. L’eina també pot generar missatges de prova per als perfils dissenyats i capturar les transaccions que es poden validar contra perfils dissenyats. També es pot utilitzar per registrar els comentaris sobre els perfils.

Resumint, MWB es una bona eina molt polivalent per definir, generar i validar perfils de missatges HL7, així com la creació de llibreries personalitzades a partir de ja existents, definició de tipus de dades que contindrà el perfil, i també la generació de fitxers XML amb els perfils de missatges creats, entre d’altres funcions. Com a punts negatius cal destacar que la eina només es pot executar des d’un entorn Windows i el seu ús es pot fer una mica difícil i enrevessat degut a la gran quantitat de funcionalitats i opcions que disposa la eina.

 


Llegir en català

 

El entorno de trabajo de mensajería Messagging Workbench (MWB) es una herramienta de productividad polivalente destinada a implementadores de HL7 v2.x. Esta herramienta pretende facilitar el rápido desarrollo de especificaciones e informes. MWB también incorpora un servicio de validación de mensajes en línea y un generador de mensajes para utilizar en pruebas. MWB permite la documentación de los mensajes/perfiles HL7 que un equipo de desarrollo hará uso y probará estas definiciones para tener consistencia con HL7 y los otros estándares locales.

Los mensajes pueden ser creados sobre la base de los archivos de librería que representan en cada versión del estándar HL7, por la entrada inversa o através de entrada manual. Además se pueden desarrollar bibliotecas adicionales para convenciones implementadas a nivel local. La herramienta también incluye un banco de diagramas MWB para facilitar una mayor variedad de formas redimensionables y configurables para así crear múltiples diagramas de forma libre para cada perfil. Los diagramas también pueden ser importados de otras herramientas que producen salidas BMP o JPG tal como puede ser Visio.

Con Messaging Workbench se pueden generar, imprimir y exportar una amplia gama de informes. La herramienta también puede generar mensajes de prueba para los perfiles diseñados y capturar las transacciones que se pueden validar contra perfiles diseñados. También se puede utilizar para registrar los comentarios sobre los perfiles.

Resumiendo, MWB es una buena herramienta muy polivalente para definir, generar y validar perfiles de mensajes HL7, así como la creación de librerías personalizadas a partir de ya existentes, definición de tipo de datos que contendrá el perfil, y también la generación de ficheros XML con los perfiles de mensajes creados, entre otras funciones. Como puntos negativos cabe destacar que la herramienta sólo se puede ejecutar desde un entorno Windows y su uso se puede hacer un poco difícil y lioso debido a la gran cantidad de funcionalidades y opciones que dispone la herramienta.

 



FHIR, la nova especificació HL7 (Part IV)

Leer en castellano 

Des del CCI varem començar parlant sobre la nova especificació FHIR, ara seguirem amb la continuació en aquesta quarta i última entrega la qual parlarem sobre les extensions, les decripcions narratives i les referències internes dels recursos.

Extensions
Aquesta especificació d’intercanvi com es FHIR es basa en els requisits comuns d’acceptació general a tot l’àmbit de la salut – que abasta moltes jurisdiccions, dominis i diferents enfocaments funcionals. Com a tal, és comú per les implementacions específiques que tinguin requisits vàlids no s’incloguin directament en aquesta memòria descriptiva. La incorporació de tots aquests requisits faria de FHIR una especificació molt molesta i difícil d’implementar. En canvi, aquesta especificació espera que aquests diferents requisits addicionals s’implementin com a extensions.

Com a tal, és l’extensibilitat una part fonamental del disseny d’aquesta especificació. Cada element en un recurs pot tenir elements secundaris d’extensió per representar la informació addicional que no és part de la definició bàsica del recurs. Aplicacions compatibles no se’ls permet rebutjar els recursos, ja que contenen extensions, encara que puguin necessitar haver de rebutjar-los a causa dels continguts específics de les extensions.

Cal tenir en compte que, a diferència de moltes altres especificacions, no pot haver-hi un estigma associat amb l’ús d’extensions per qualsevol aplicació, projecte o estàndard – sense importar la institució o la jurisdicció que utilitza o defineix les extensions. L’ús d’extensions és el que permet a l’especificació FHIR retenir un nucli de simplicitat per a tothom.

Per tal de fer que l’ús d’extensions sigui segur i manejable, hi ha una legislació estricta aplicada a la definició i l’ús de les extensions. Encara que qualsevol implementador se li permet definir una extensió, hi ha una sèrie de requisits que s’han de complir en el marc de la definició de l’extensió.

Extensions a un element
Cada element en un recurs inclou un element opcional “extensió” que es pot presentar qualsevol nombre de vegades en l’element. L’element d’extensió apareix com el primer fill, abans de qualsevol altre element secundari definit. Aquest és el model de contingut de l’extensió que apareix en cada recurs:

<[name] xmlns=”http://hl7.org/fhir”>
<url value=”[uri]”/><!– 1..1 Identifica el significat de l’extensió –>
<isModifier value=”[boolean]”/><!– 0..1 Si l’extensió modifica altres elements/extensions –>
<value[x]><!– 0..1 Valor de la extensió –></value[x]>
<extension><!– 0..* Extension Valors niats per l’extensió  –></extension>
</[name]>

Exemple, extensió d’un pacient amb un opt-in-status d’un assaig clínic amb 3 camps: estat, data de l’enregistrament i la persona que va fer el registre.

<Patient>
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status” />
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status-code” />
<valueCode value=”unsure” />
</extension>
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status-date” />
<valueDate value=”2009-03-14″ />
</extension>
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status-who” />
<valueResourceReference>
<type value=”Practitioner” />
<reference value=”../Practitioner/@example” />
</valueResourceReference>
</extension>
</extension>
<!– other data for patient –>
</Patient>

Descripció Narrativa
A cada recurs s’inclourà una descripció llegible que contindrà un resum del mateix recurs, i pot ser usat per representar el contingut del recurs a un ésser humà. La narració no necessita codificar totes les dades estructurades, però és necessària per contenir el detall suficient perquè sigui “clínicament segura” per a un ésser humà que acaba de llegir la descripció. Les definicions de recursos poden definir quin serà el contingut que ha de ser representat en la descripció narrativa per garantir la seguretat clínica.
A la descripció narrativa per un recurs s’hi permet que hi contingui informació addicional que no estigui a les dades estructurades prèviament definides, incloent el contingut editat per una persona. Aquesta informació addicional per això ha d’estar en l’àmbit de la definició del recurs. En entorns petits i tancats de socis comercials, poder no hi necessitat d’un text narratiu. En aquests casos, la implementació es permesa omplint la descripció amb el text equivalent a “[Nom de recurs] No hi ha text llegible proporcionat per aquest recurs” – en l’idioma apropiat. Els implementadors han de tenir en compte que es molt probable que els entorns petits i tancats de socis comercials els obrin durant la vida útil dels recursos que ells defineixen.

La narració és un fragment xhtml, que també inclou les imatges en el seu cas:

<[name] xmlns=”http://hl7.org/fhir”>
<status value=”[code]”/><!– 1..1 generated | extensions | additional –>
<div xmlns=”http://www.w3.org/1999/xhtml”< <!– Limited xhtml content< –> </div>
<blob>  <!– 0..* Binary content referenced in xhtml –>
<mimeType value=”[code]”/><!– 1..1 Mime type of binary attachment –>
<content value=”[base64Binary]”/><!– 1..1 base64 data for attachment –>
</blob>
</[name]>

El contingut de l’element div és un fragment d’XHTML que conté només els elements de format HTML bàsics descrits en els capítols 7-11 (excepte la secció 4 del capítol 9) i 15 de la norma HTML 4.0, els elements <a> (nom o href), les imatges i els atributs d’estil que conté internament. El contingut XHTML no ha de contenir un head, un element body, les referències externes de fulls d’estil, scripts, formularis, base / enllaç / XLink, frames, iframes i objectes. L’element div ha de tenir algun contingut que no estigui en blanc.

<narrative>
<div xmlns=”http://www.w3.org/1999/xhtml”>Aquest es un exemple amb només text pla</div>
</narrative>

<narrative>
<div xmlns=”http://www.w3.org/1999/xhtml”>
<p>
Aquest es un <i>exemple</i> amb algun <b>xhtml</b> format.
</p>
</div>
</narrative>

La porció interna del contingut div s’utilitza sovint per a la propietat innerHTML en un navegador. Per tal de simplificar el processament, la narració es codificarà de manera que el contingut entre el primer “>” i l’últim “<” caràcters és el contingut de l’element <div>.
Cal tenir en compte que l’XHTML es troba contingut en un XML, per la qual cosa no hi ha suport per a les entitats en HTML com per exemple &nbsp; o &copy; etc. Per arreglar-ho es farà servir caràcters Unicode al seu lloc. A l’exemple anterior &#160; substituiria &nbsp;
El contingut narratiu ha d’estar en l’idioma del recurs, però no hi ha raó per esperar que aquest tipus d’eines HTML entenguin l’element de llenguatge del recurs. Per aquesta raó, també s’ha d’utilitzar un atribut lang al <div> (i veure la nota en l’especificació d’HTML 5 sobre l’ús de la llengua).

Les referències “image source” poden ser una referència local dins del recurs:
<img src=”#a5″/>

Aquesta és una referència interna a un atribut id d’un element al mateix recurs, ja sigui en els arxius adjunts binaris en l’element de text directament, o un element de tipus “Annex”.

<narrative>
<div xmlns=”http://www.w3.org/1999/xhtml”>
<p>
<img src=”#a1″/>.
</p>
</div>
<blob id=”a1″>
<mimeType value=”image/png” />
<content value=”MEKH….SD/Z” />
</blob>
</narrative>

Atès que la presència de les imatges que no formen part dels recursos no està garantit, imatges que són una part essencial de la narració sempre han de ser incorporades com aquest.
El fragment XHTML en la descripció narrativa pot ser d’estil usant CSS de forma normal, amb una barreja de classes, identificadors i elements d’estil en línia. S’aplicaran fulls d’estil CSS específics  al XHTML quan s’extregui aquesta narració des del recurs de què es mostrarà a un ésser humà per crear la presentació desitjada en el context d’ús.

Els autors poden fixar els següents aspectes d’estil del contingut:
negreta, cursiva, subratllat, ratllat, color de la font, família, la mida, color de fons, alineació del text,  interpretació dels espais en blanc, llista de format de número ordenat (ja que pot ser contemplada en el text).
Aquestes propietats d’estil s’especifiquen en línia utilitzant l’atribut d’estil. Si hi ha un element HTML equivalent, com “i”, o “pre”, es poden utilitzar en el seu lloc però cal tenir en compte que alguns d’aquests elements s’han desaprovat (estan en estat deprecated) en HTML 4 i no han de ser utilitzats en la descripció narrativa XHTML (com “o”, i “font”).
Es requereixen sistemes de representació per respectar qualsevol d’aquests estils de reproducció quan s’especifiquen a XHTML, encara que es permet la interpretació apropiada (per exemple, una pantalla de baix contrast per diferents contextos, com una cambra fosca, o en una pantalla d’alt contrast per als discapacitats visuals poden ajustar els colors en conseqüència) .
Els autors poden especificar estils addicionals i les propietats d’estil com s’especifica en l’especificació CSS, però aquestes són extensions d’aquesta especificació i aquests no estan obligats a complir amb ells. Cal tenir en compte, però, les normes addicionals de l’estil que s’apliquen en el context dels documents.

Referències internes
Hi ha 4 casos on els elements dins d’un recurs fan referència a un altre:

  • Dins d’un tipus de dades “CodeableConcept” per identificar la codificació primària.
  • Una referència <img src = “”/> dins la descripció narrativa, en referència a una imatge que es troba en el recurs.
  • Entre els elements de la narrativa i elements de dades estructurades.
  • Entre un ResourceReference i un recurs contingut.

Aquestes referències es fan usant un enfoc basat en un id/idRef, on un element d’origen indica que té el mateix contingut que l’element de destinació. L’element de destinació té un atribut “id” que ha de tenir un valor únic en el recurs respecte a qualsevol altre atribut id. L’atribut “id” no es troba en cap espai de noms (namespace). La referència de l’element d’origen ha de fer referència a un atribut en el mateix recurs (o, per a un CodeableConcept, dins del mateix tipus de dades).

<example>
<target id=”a1″>
<child>…</child>
</target>
<– other stuff –>
<source idref=”a1″>
</example>

En un sol recurs, això funciona com xml: id/idRef, però hi ha una diferència important: la singularitat i l’abast de la resolució d’aquestes referències d’identificació és en el recurs que els conté. Si múltiples recursos es combinen en una sola peça XML, com ara un àtom d’alimentació, valors duplicats poden ocórrer entre els recursos. Això ha de ser gestionat per aplicacions que llegeixen els recursos.
Cal destacar que totes les referències entre els elements XHTML i els elements de dades s’han d’entendre per establir una “deriva de” relació, on el contingut derivat (ja sigui text o dades) es refereixi al contingut d’origen. S’ha de tenir en compte que això significa que algunes referències poden ser referències a termini (referències a elements definides més endavant a la instancia).

Fins aqui la última entrega del post sobre FHIR.

Llegir en català 

Desde el CCI empezamos hablando sobre la nueva especificación FHIR, ahora vamos a seguir con la continuación en esta cuarta y última entrega en la que hablaremos sobre las extensiones, las decripciones narrativas y las referencias internas de los recursos.

Extensiones
Esta especificación de intercambio como es FHIR se basa en los requisitos comunes de aceptación general en todo el ámbito de la salud – que abarca muchas jurisdicciones, dominios y diferentes enfoques funcionales. Como tal, es común para las implementaciones específicas que tengan requisitos válidos no se incluyan directamente en esta memoria descriptiva. La incorporación de todos estos requisitos haría de FHIR una especificación muy molesta y difícil de implementar. En cambio, esta especificación espera que estos diferentes requisitos adicionales se implementen como extensiones.

Como tal, es la extensibilidad una parte fundamental del diseño de esta especificación. Cada elemento en un recurso puede tener elementos secundarios de extensión para representar la información adicional que no es parte de la definición básica del recurso. Aplicaciones compatibles no se les permite rechazar los recursos, ya que contienen extensiones, aunque puedan necesitar tener que rechazarlos debido a los contenidos específicos de las extensiones.

Hay que tener en cuenta que, a diferencia de muchas otras especificaciones, no puede haber un estigma asociado con el uso de extensiones para cualquier aplicación, proyecto o estándar – sin importar la institución o la jurisdicción que utiliza o define las extensiones. El uso de extensiones es el que permite la especificación FHIR retener un núcleo de simplicidad para todos.

Para hacer que el uso de extensiones sea seguro y manejable, hay una legislación estricta aplicada a la definición y el uso de las extensiones. Aunque cualquier implementador se le permite definir una extensión, hay una serie de requisitos que se deben cumplir en el marco de la definición de la extensión.

Extensiones a un elemento
Cada elemento en un recurso incluye un elemento opcional “extensión” que se puede presentar cualquier número de veces en el elemento. El elemento de extensión aparece como el primer hijo, antes de cualquier otro elemento secundario definido. Este es el modelo de contenido de la extensión que aparece en cada recurso:

<[name] xmlns=”http://hl7.org/fhir”>
<url value=”[uri]”/><!– 1..1 Identifica el significado de la extensión –>
<isModifier value=”[boolean]”/><!– 0..1 Indica si la extensión modifica otros elementos/extensiones –>
<value[x]><!– 0..1 Valor de la extensión –></value[x]>
<extension><!– 0..* Extension Valores anidados por la extensión –></extension>
</[name]>

Ejemplo, extensión de un paciente con un opt-in-status de un ensayo clínico con 3 campos: estado, fecha del registro y la persona que hizo el registro.

<Patient>
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status” />
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status-code” />
<valueCode value=”unsure” />
</extension>
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status-date” />
<valueDate value=”2009-03-14″ />
</extension>
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status-who” />
<valueResourceReference>
<type value=”Practitioner” />
<reference value=”../Practitioner/@example” />
</valueResourceReference>
</extension>
</extension>
<!– other data for patient –>
</Patient>

Descripción Narrativa
En cada recurso se incluirá una descripción legible que contendrá un resumen del mismo recurso, y puede ser usado para representar el contenido del recurso a un ser humano. La narración no necesita codificar todos los datos estructurados, pero es necesaria para contener el detalle suficiente para que sea “clínicamente segura” para un ser humano que acaba de leer la descripción. Las definiciones de recursos pueden definir cuál será el contenido que debe ser representado en la descripción narrativa para garantizar la seguridad clínica.
En la descripción narrativa para un recurso se permite que contenga información adicional que no esté en los datos estructurados previamente definidos, incluyendo el contenido editado por una persona. Esta información adicional para ello debe estar en el ámbito de la definición del recurso. En entornos pequeños y cerrados de socios comerciales, quizá no hay necesidad de un texto narrativo. En estos casos, la implementación se permite llenando la descripción con el texto equivalente a “[Nombre de recurso] No hay texto legible proporcionado por este recurso” – en el idioma apropiado. Los implementadores deben tener en cuenta que es muy probable que los entornos pequeños y cerrados de socios comerciales les abran durante la vida útil de los recursos que ellos definen.

La narración es un fragmento xhtml, que también incluye las imágenes en su caso:

<[name] xmlns=”http://hl7.org/fhir”>
<status value=”[code]”/><!– 1..1 generated | extensions | additional –>
<div xmlns=”http://www.w3.org/1999/xhtml”< <!– Limited xhtml content< –> </div>
<blob> <!– 0..* Binary content referenced in xhtml –>
<mimeType value=”[code]”/><!– 1..1 Mime type of binary attachment –>
<content value=”[base64Binary]”/><!– 1..1 base64 data for attachment –>
</blob>
</[name]>

El contenido del elemento div es un fragmento de XHTML que contiene sólo los elementos de formato HTML básicos descritos en los capítulos 7-11 (excepto la sección 4 del capítulo 9) y 15 de la norma HTML 4.0, los elementos <a> (nombre o href), las imágenes y los atributos de estilo que contiene internamente. El contenido XHTML no debe contener un head, un elemento body, las referencias externas de hojas de estilo, scripts, formularios, base / enlace / XLink, frames, iframes y objetos. El elemento div debe tener algún contenido que no esté en blanco.

<narrative>
<div xmlns=”http://www.w3.org/1999/xhtml”>Este es un ejemplo solo con texto plano</div>
</narrative>

<narrative>
<div xmlns=”http://www.w3.org/1999/xhtml”>
<p>
Este es un <i>ejemplo</i> con algun <b>xhtml</b> formato.
</p>
</div>
</narrative>

La porción interna del contenido div se utiliza a menudo para la propiedad innerHTML en un navegador. Para simplificar el procesamiento, la narración se codificará de manera que el contenido entre el primero “>” y el último “<” carácteres es el contenido del elemento <div>.
Hay que tener en cuenta que el XHTML se encuentra contenido en un XML, por lo que no hay apoyo para las entidades en HTML como por ejemplo &nbsp; o &copy; etc. Para arreglarlo se utilizará caracteres Unicode en su lugar. En el ejemplo anterior &#160; substituiria &nbsp;
El contenido narrativo debe estar en el idioma del recurso, pero no hay razón para esperar que este tipo de herramientas HTML entiendan el elemento de lenguaje del recurso. Por esta razón, también se debe utilizar un atributo lang al <div> (y ver la nota en la especificación HTML 5 sobre el uso de la lengua).

Las referencias “image source” pueden ser una referencia local dentro del recurso:
<img src=”#a5″/>

Esta es una referencia interna a un atributo id de un elemento al mismo recurso, ya sea en los archivos adjuntos binarios en el elemento de texto directamente, o un elemento de tipo “Anexo”.

<narrative>
<div xmlns=”http://www.w3.org/1999/xhtml”>
<p>
<img src=”#a1″/>.
</p>
</div>
<blob id=”a1″>
<mimeType value=”image/png” />
<content value=”MEKH….SD/Z” />
</blob>
</narrative>

Dado que la presencia de las imágenes que no forman parte de los recursos no está garantizado, imágenes que son una parte esencial de la narración siempre deben ser incorporadas como este.
El fragmento XHTML en la descripción narrativa puede ser de estilo usando CSS de forma normal, con una mezcla de clases, identificadores y elementos de estilo en línea. Se aplicarán hojas de estilo CSS específicas al XHTML cuando se extraiga esta narración desde el recurso de que se mostrará a un ser humano para crear la presentación deseada en el contexto de uso.

Los autores pueden fijar los siguientes aspectos de estilo del contenido:
negrita, cursiva, subratllado, rallado, color de la fuente, família, el tamaño, color de fondo, alineación del texto, interpretación de los espacios en blanco, lista de formato de número ordenado (ya que puede ser contemplada en el texto).
Estas propiedades de estilo se especifican en línea utilizando el atributo de estilo. Si hay un elemento HTML equivalente, como “i”, o “pre”, se pueden utilizar en su lugar pero hay que tener en cuenta que algunos de estos elementos se han desaprobado (están en estado deprecated) en HTML 4 y no deben ser utilizados en la descripción narrativa XHTML (como “o”, y “fuente”).
Se requieren sistemas de representación para respetar cualquiera de estos estilos de reproducción cuando se especifican en XHTML, aunque se permite la interpretación apropiada (por ejemplo, una pantalla de bajo contraste para diferentes contextos, como un cuarto oscuro, o en una pantalla de alto contraste para los discapacitados visuales pueden ajustar los colores en consecuencia).
Los autores pueden especificar estilos adicionales y las propiedades de estilo como se especifica en la especificación CSS, pero estas son extensiones de esta especificación y éstos no están obligados a cumplir con ellos. Hay que tener en cuenta, sin embargo, las normas adicionales del estilo que se aplican en el contexto de los documentos.

Referencias internas
Hay 4 casos donde los elementos dentro de un recurso hacen referencia a otro:

  • Dentro de un tipo de datos “CodeableConcept” para identificar la codificación primaria.
  • Una referencia <img src = “”/> dentro de la descripción narrativa, en referencia a una imagen que se encuentra en el recurso.
  • Entre los elementos de la narrativa y elementos de datos estructurados.
  • Entre un ResourceReference y un recurso contenido.

Estas referencias se hacen usando un enfoque basado en un id / idRef, donde un elemento de origen indica que tiene el mismo contenido que el elemento de destino. El elemento de destino tiene un atributo “id” que debe tener un valor único en el recurso respecto a cualquier otro atributo id. El atributo “id” no se encuentra en ningún espacio de nombres (namespace). La referencia del elemento de origen debe hacer referencia a un atributo en el mismo recurso (o, para un CodeableConcept, dentro del mismo tipo de datos).

<example>
<target id=”a1″>
<child>…</child>
</target>
<– other stuff –>
<source idref=”a1″>
</example>

En un solo recurso, esto funciona como xml: id / idRef, pero hay una diferencia importante: la singularidad y el alcance de la resolución de estas referencias de identificación es en el recurso que los contiene. Si múltiples recursos se combinan en una sola pieza XML, como un átomo de alimentación, valores duplicados pueden ocurrir entre los recursos. Esto debe ser gestionado por aplicaciones que leen los recursos.
Cabe destacar que todas las referencias entre los elementos XHTML y los elementos de datos deben entenderse para establecer una “deriva de” relación, donde el contenido derivado (ya sea texto o datos) se refiera al contenido de origen. Hay que tener en cuenta que esto significa que algunas referencias pueden ser referencias a plazo (referencias a elementos definidas más adelante en la instancia).

Hasta aqui la última entrega del post sobre FHIR.

FHIR, la nova especificació HL7 (Part III)

Leer en castellano

Des del CCI varem començar parlant sobre la nova especificació FHIR, ara seguirem amb la continuació en aquesta tercera entrega la qual parlarem sobre els diferents formats en que es poden representar els recursos i els tipus de dades que els composen.

Formats dels recursos

Els recursos es poden descriure de dues formes diferents: un diagrama UML que resumeixi el contingut del recurs i una sintaxi pseudo-XML que proporciona una sensació visual de que les instàncies de recursos finals es veuran com en XML. Cal tenir en compte que encara que la descripció dels recursos es basa en la seva representació XML, altres representacions (com la ja esmentada en parts anteriors del post JSON) són igualment vàlides.

Representació XML

La sintaxis XML presenta la següent anotació:

<name xmlns=”http://hl7.org/fhir” (attrA=”value”)>
<nameA><!– 1..1 type descripció de contingut –><nameA>
<nameB[x]><!– 0..1 type1|type1 descripció –></nameB>
<nameC> <!–  1..* –>
<nameD><!– 1..1 type>Relevant records –></nameD>
</nameC>
<name>

Notes sobre els formats i la instanciació de recursos en XML:

  • Per construir una instància de XML vàlida d’un recurs, simplement cal substituir el contingut dels elements i atributs amb contingut vàlid tal com es descriu, per la cardinalitat, les regles del tipus i la descripció del contingut que es troba en el comentari a cada element.
  • S’ha de tenir en compte que les úniques propietats que representen com a atributs són els definits en les especificacions subjacents com ara xml: lang i Atom (veure més a baix), que s’utilitzen com la representació XML per paquets.
  • Tots els elements que tenen un tipus primitiu tindran un atribut per contenir el valor real de l’element.
  • Als elements se’ls assigna una cardinalitat que especifica quantes vegades es pot o ha d’aparèixer l’element. Si la cardinalitat es mostra en rosa llavors hi ha una condició addicional que impacta en la cardinalitat permesa.
  • Als elements a més se’ls assigna un o més tipus. Tots els tipus son definits en els tipus de dades a excepció de “recursos” i “descripció narrativa” que es documenten més endavant. Els noms dels tipus tenen hipervincles.
  • Quan un element lògic pot tenir més d’un tipus, el seu nom pren la forma xxx[y]. La part de “xxx” del nom és constant, i la [y] es reemplaça amb el nom del tipus que s’utilitza realment.
  • Cada nom d’un element en la pseudo-sintaxi també és un hipervincle a la definició formal de l’element en el diccionari de dades que està subjacent als formats d’intercanvi.
  • Si el nom està subratllat, es requereixen aplicacions de suport i/o enteniment.
  • El joc de caràcters per a un recurs és sempre Unicode, codificat en format UTF-8.
  • Especificació de la codificació de caràcters en XML és opcional però recomanat.
  • Elements FHIR estan sempre a l’espai de noms (namespace) http://hl7.org/fhir. Això s’especifica com l’espai de noms per defecte en l’element arrel. Els únics altres espais de noms que es produeixen en els recursos són FHIR on alguns model de contingut extern s’introdueix explícitament en el model de contingut de recursos. Per exemple, XHTML es troba en tots els recursos.
  • Qualsevol dels elements XML poden tenir un atribut “id” per servir com a destinació d’una referència interna. L’atribut “id” no es mostra en aquest format.
  • Elements FHIR mai estan buits. Si un element està present en el recurs, ha de tenir ja sigui un atribut de valor, elements secundaris com es defineix pel seu tipus, un atribut “id” que és la destinació de l’enllaç de la narrativa, o 1 o més extensions.
  • Els atributs no poden estar buits. O estan absents, o presents però amb almenys un caràcter de contingut (no en blanc).
  • L’atribut xml: lang pot aparèixer en l’element arrel, on s’especifica l’idioma base del recurs. També pot aparèixer en els arxius adjunts i en el contingut XHTML, però en cap altre lloc.
  • El tipus MIME formal de recursos FHIR representats en XML és definit com application/FHIR + xml.

Representació UML

Els diagrames UML representen el mateix contingut que una sèrie de classes que representen elements XML. Els elements es marquen amb una “R” per al recurs, o una “D” per a un tipus de dades. Classes sense etiqueta són classes normals que són només una part del contingut d’un recurs o d’un tipus de dades.

Quan un element pot tenir una varietat de tipus de dades, aquestes es representen en la elecció utilitzant la mateixa sintaxi que la sintaxi XML. A causa de la forma de treballar en UML, l’ordre real dels elements no es pot determinar a partir del diagrama, ni és visible si una propietat és un element o un atribut. Aquests diagrames, principalment el que pretenen es informar sobre el contingut del recurs a les persones.

Tipus de dades dels recursos

L’especificació FHIR defineix un conjunt de tipus que s’utilitzen per als elements dels recursos. Hi ha dues categories de tipus de dades: tipus simples/primitius, importats d’esquema XML i tipus complexos, que són grups reutilitzables dels elements.

(A la imatge es pot veure com s’estructuren els tipus de dades que poden contenir els recursos)

Tipus Primitius:

Aquests tipus es representen com a elements XML amb el valor del tipus en el text de l’element. El nom de l’element es definit allà on s’utilitza el tipus. Els elements XML poden tenir un atribut id. En format JSON, el tipus de dades està representat per un objecte amb dues propietats: “_id” per a l’atribut id, i “valor” per al valor del tipus.

Exemple:

data (per exemple, data de naixement):

<date value=”1951-06-04″ />
<date id=”a1″ value=”1951-06-04″ />

En JSON:

date : {
value : “1951-06-04”
}

O bé:

date : {
_id : “a1”,
value : “1951-06-04”
}

Tipus Complexos:

Aquests tipus es representen com a elements XML, amb elements fills amb el nom dels elements definits del tipus. El nom de l’element es definit allà on s’utilitza el tipus. Qualsevol dels elements XML poden tenir un atribut id. En JSON, el tipus de dades està representat per un objecte amb les propietats amb nom igual que els elements amb format XML. La representació JSON és gairebé exactament igual, de manera que només el primer exemple té una representació addicional JSON.

(A la imatge superior e inferior es pot veure els diferents tipus complexos i els diferents atributs que els composen)

Fins aqui la tercera part del post sobre FHIR en una propera entrega acabarem de parlar sobre aquesta nova especificació.

Llegir en català

Desde el CCI empezamos hablando sobre la nueva especificación FHIR, ahora seguiremos con la continuación en esta tercera entrega la que hablaremos sobre los diferentes formatos en que se pueden representar los recursos y los tipos de datos que los componen.

Formatos de los recursos

Los recursos se pueden describir de dos formas diferentes: un diagrama UML que resuma el contenido del recurso y una sintaxis pseudo-XML que proporciona una sensación visual de que las instancias de recursos finales se verán como en XML. Hay que tener en cuenta que aunque la descripción de los recursos se basa en su representación XML, otras representaciones (como la ya mencionada en partes anteriores del post JSON) son igualmente válidas.

Representación XML

La sintaxis XML presenta la siguiente anotación:

<name xmlns=”http://hl7.org/fhir” (attrA=”value”)>
<nameA><!– 1..1 type descripción del contenido –><nameA>
<nameB[x]><!– 0..1 type1|type1 descripción –></nameB>
<nameC> <!– 1..* –>
<nameD><!– 1..1 type>Relevant records –></nameD>
</nameC>
<name>

Notas sobre los formatos y la instanciación de recursos en XML:

  • Para construir una instancia de XML válida de un recurso, simplemente hay que sustituir el contenido de los elementos y atributos con contenido válido tal como se describe, por la cardinalidad, las reglas del tipo y la descripción del contenido que se encuentra en el comentario a cada elemento.
  • Hay que tener en cuenta que las únicas propiedades que representan como atributos son los definidos en las especificaciones subyacentes tales como xml: lang y Atom (ver más abajo), que se utilizan como la representación XML para paquetes.
  • Todos los elementos que tienen un tipo primitivo tendrán un atributo para contener el valor real del elemento.
  • A los elementos se les asigna una cardinalidad que especifica cuántas veces se puede o debe aparecer el elemento. Si la cardinalidad se muestra en rosa entonces hay una condición adicional que impacta en la cardinalidad permitida.
  • A los elementos además se les asigna uno o más tipos. Todos los tipos son definidos en los tipos de datos a excepción de “recursos” y “descripción narrativa” que se documentan más adelante. Los nombres de los tipos tienen hipervínculos.
  • Cuando un elemento lógico puede tener más de un tipo, su nombre toma la forma xxx [y]. La parte de “xxx” del nombre es constante, y la [y] se reemplaza con el nombre del tipo que se utiliza realmente.
  • Cada nombre de un elemento en la pseudo-sintaxis también es un hipervínculo a la definición formal del elemento en el diccionario de datos que subyace a los formatos de intercambio.
  • Si el nombre está subrayado, se requieren aplicaciones de soporte y / o entendimiento.
  • El juego de caracteres para un recurso es siempre Unicode, codificado en formato UTF-8.
  • Especificación de la codificación de caracteres en XML es opcional pero recomendado.
  • Elementos FHIR están siempre en el espacio de nombres (namespace) http://hl7.org/fhir. Esto se especifica como el espacio de nombres por defecto en el elemento raíz. Los únicos otros espacios de nombres que se producen en los recursos son FHIR donde algunos modelos de contenido externo se introduce explícitamente en el modelo de contenido de recursos. Por ejemplo, XHTML se encuentra en todos los recursos.
  • Cualquiera de los elementos XML pueden tener un atributo “id” para servir como destino de una referencia interna. El atributo “id” no se muestra en este formato.
  • Elementos FHIR nunca están vacíos. Si un elemento está presente en el recurso, debe tener ya sea un atributo de valor, elementos secundarios como se define por su tipo, un atributo “id” que es el destino del enlace de la narrativa, o 1 o más extensiones.
  • Los atributos no pueden estar vacíos. O están ausentes, o presentes pero con al menos un carácter de contenido (no en blanco).
  • El atributo xml: lang puede aparecer en el elemento raíz, donde se especifica el idioma base del recurso. También puede aparecer en los archivos adjuntos y en el contenido XHTML, pero en ningún otro lugar.
  • El tipo MIME formal de recursos FHIR representados en XML es definido como application / FHIR + xml.

Representación UML

Los diagramas UML representan el mismo contenido que una serie de clases que representan elementos XML. Los elementos se marcan con una “R” para el recurso, o una “D” para un tipo de datos. Clases sin etiqueta son clases normales que son sólo una parte del contenido de un recurso o de un tipo de datos.

Cuando un elemento puede tener una variedad de tipos de datos, éstas se representan en la elección utilizando la misma sintaxis que la sintaxis XML. Debido a la forma de trabajar en UML, el orden real de los elementos no se puede determinar a partir del diagrama, ni es visible si una propiedad es un elemento o un atributo. Estos diagramas, principalmente el que pretenden es informar sobre el contenido del recurso a las personas.

Tipos de datos de los recursos

La especificación FHIR define un conjunto de tipos que se utilizan para los elementos de los recursos. Hay dos categorías de tipos de datos: tipos simples/primitivos, importados de esquema XML y tipos complejos, que son grupos reutilizables de los elementos.

(En la imagen se puede ver cómo se estructuran los tipos de datos que pueden contener los recursos)

Tipos Primitivos:

Estos tipos se representan como elementos XML con el valor del tipo en el texto del elemento. El nombre del elemento se definió allí donde se utiliza el tipo. Los elementos XML pueden tener un atributo id. En formato JSON, el tipo de datos está representado por un objeto con dos propiedades: “_id” para el atributo id, y “valor” para el valor del tipo.

Ejemplo:

fecha (por ejemplo, fecha de nacimiento):

<date value=”1951-06-04″ />
<date id=”a1″ value=”1951-06-04″ />

En JSON:

date : {
value : “1951-06-04”
}

O bien:

date : {
_id : “a1”,
value : “1951-06-04”
}

Tipos Complejos:

Estos tipos se representan como elementos XML con el valor del tipo en el texto del elemento. El nombre del elemento se definió allí donde se utiliza el tipo. Los elementos XML pueden tener un atributo id. En formato JSON, el tipo de datos está representado por un objeto con dos propiedades: “_id” para el atributo id, y “valor” para el valor del tipo.

(En la imagen superior e inferior se puede ver los diferentes tipos complejos y los diferentes atributos que los componen)

Hasta aquí la tercera parte del post sobre FHIR en una próxima entrega terminaremos de hablar sobre esta nueva especificación.

FHIR, la nova especificació HL7 (Part II)

Leer en castellano

Des del CCI varem començar parlant sobre la nova especificació FHIR, ara seguirem amb la continuació en aquesta segona part la qual parlarem sobre algunes particularitats dels recursos com son els paquets, les referencies entre recursos i els recursos continguts.

Paquets de recursos:
Una operació comú que es realitza amb els recursos és reunir una col•lecció de recursos en una sola instància. El paquet de recursos no és només una llista de referències als recursos, sinó que inclou tot el contingut (un tipus, una URL i una descripció de text). Aquests paquets de recursos són útils per a una varietat de raons diferents, entre les quals hi ha les següents:

  • Es pot retornar un conjunt de recursos que compleixin alguns criteris com a part d’una operació del servidor.
  • Es pot retornar un conjunt de versions dels recursos, com a part de l’operació de la història al servidor.
  • Emmagatzematge d’una col•lecció de recursos.
  • L’intercanvi d’un conjunt de recursos, com a part d’una transacció de missatge.
  • Agrupació d’un conjunt autònom de recursos per actuar com un grup intercanviable i persistent amb integritat clínica (és a dir, un document clínic).

Conceptualment, un paquet té un identificador (URL), una data d’actualització, i una llista de recursos. Per a cada recurs a la llista, el paquet té els recursos i també les meta-dades com s’ha indicat anteriorment. Cada entrada al conjunt conserva el seu identificador original. Això significa que les aplicacions que llegeixen el paquet sempre han de buscar un recurs per la seva identitat (després de la conversió de URL relativa a URL absoluta) en el paquet primer abans d’intentar accedir-hi per la seva URL.

Cardinalitat de recursos:
Tots els elements definits en FHIR tenen una cardinalitat com a part de la seva definició – un nombre mínim d’aparicions requerides, i un nombre màxim permès. Aquest número indica el nombre de vegades que l’element pot aparèixer en la instància. En l’especificació, el nombre mínim està sempre entre 0 o 1, i el nombre màxim està sempre entre 1 o *, vol dir que no hi ha límit. Els perfils poden utilitzar qualsevol nombre enter de cardinalitat tant mínima i màxima, sempre que mínim sigui menor o igual a màxim.
Per als elements que tenen cardinalitat superior a 1, l’ordre en què apareixen pot tenir significat. Llevat que la definició de l’element (ja sigui en aquesta memòria descriptiva o l’extensió) defineix un significat a l’ordre explícitament, el significat de l’ordre no es defineix, i les implementacions se’ls permet canviar l’ordre dels elements. Cal tenir en compte que no es pot definir un significat per a l’ordre dels elements d’un perfil. Quan no hi ha definició del significat de l’ordre, les implementacions que han de triar un sol element d’una llista d’elements per a algun ús han de fer basats en la semàntica del contingut dels elements que es repeteix. Perfils i guies d’implementació sovint poden fer regles sobre aquest procés de selecció.

Referències entre recursos:
Els elements definits en un recurs poden incloure moltes referències a altres recursos. Els recursos es combinen per construir una xarxa d’informació sobre la salut. En un recurs, les referències estan representades amb un tipus, una referència, i una descripció de text. La propietat clau de la referència és la referència que conté – els recursos són identificats i adreçats per la seva URL. La referència real té un aspecte com aquest:

<[name] xmlns=”http://hl7.org/fhir”>
<type value=”[code]”/><!– 0..1 Tipus de recurs –>
<reference value=”[string]”/><!– 0..1 Relativa, interna o absoluta URL de referència –>
<display value=”[string]”/><!– 0..1 Text alternatiu del recurs –>
</[name]>

El type ha d’especificar el tipus de recurs, si el tipus de referència de recursos és fixa per l’element de la definició dels recursos.
L’element de referència conté una adreça URL que és o bé una URL absoluta, o una adreça relativa a l’URL base de servei, o un fragment intern de referència.
Utilitzant URL absolutes es proporciona un enfocament escalable i estable adequat per a un context de núvol/web, mentre que l’ús de referències relatives/lògiques proporciona un enfocament flexible adequat per utilitzar quan es realitzin a través dels límits de l’ecosistema tancat.
Les URL absolutes no han d’apuntar a un servidor RESTful FHIR, encara que aquest és l’enfocament preferit. Si la cua de la URL s’ajusta a l’estructura “/ [tipus] / @ [id]” o “/ [tipus] / @ [id] / history / @ [id]”, aleshores cal suposar que la referència és a un servidor RESTful FHIR. Independentment de si la referència és a un servidor RESTful FHIR, la referència ha d’apuntar a un recurs com es defineix en aquesta especificació
Les URL sempre son sensibles al tipus de lletra (majúscula-minuscula) i es prefereix en minúscules.

Exemple d’una referència relativa al pacient “034AB16” d’un element anomenat “context” al servidor REST FHIR:

<context>
<type value=”Patient” />
<reference value=”patient/@034AB16″ />
</context>

Exemple d’una referència absoluta al perfil d’un recurs en un element anomenat “profile”:

<profile>
<type value=”Profile” />
<reference value=”http://fhir.hl7.org/svc/profile/@c8973a22-2b5b-4e76-9c66-00639c99e61b” />
</profile>

Recursos continguts:
En algunes circumstàncies, el contingut esmentat en la referència del recurs no té una existència independent a part del recurs que el conté – no pot ser identificat de forma independent, i no pot tenir el seu propi àmbit de transacció independent. Típicament, tals circumstàncies sorgeixen on el recurs està sent assemblat per un usuari secundari de les dades origen, com un motor de middleware.
Si les dades disponibles quan es construeix el recurs no inclou claus de registre o informació d’identificació absoluta, llavors un recurs identificat correctament no es pot muntar, i fins i tot si una identificació arbitrària es va associar amb ell, el recurs no pot ser l’objecte d’una operació fora del context del recurs al que es refereix.
En aquestes circumstàncies, el recurs es col•loca directament en línia a la referència. Això mai s’ha de fer quan el contingut pot ser identificat correctament, ja que un cop es perd la identificació, és extremadament difícil (i depenent del context) tornar a restaurar-lo de nou.

Un exemple d’un recurs contingut:

<Document xmlns=”http://hl7.org/fhir”>
<extension>…</extension>
<text>…</text>
<contained>
<Organization id=”org1″>
<!– whatever information is available –>
</Organization>
</contained>
<information>
<!– other attributes –>
<custodian>
<type value=”Organization” />
<reference value=”#org1″ />
</custodian>
<!– other attributes –>
<information>
</Document>

El mateix exemple escrit amb JSON:

{ “Document” : {
“extension” : { … },
“text” : { .. },
“contained: [
{“Organization” : {
“_id” : “org1”,
.. whatever information is available …
}}
]
“information: {
… other attributes …
“custodian” : {
“type” : { “value” : “Organization” },
“url” : { “value” : “#org1” }
}
… other attributes …
}
}}

Algunes notes sobre l’ús i la interpretació dels recursos continguts:

  • Els recursos continguts comparteixen el mateix identificador d’espai intern de resolució com el recurs pare.
  • Els recursos continguts no contenen recursos continguts addicionals.
  • Els recursos continguts no és necessari  que continguin cap text narratiu.

Fins aqui la segona part del post sobre FHIR en una propera entrega continuarem parlant sobre aquesta nova especificació.

Llegir en català

Desde el CCI empezamos hablando sobre la nueva especificación FHIR, ahora seguiremos con la continuación en esta segunda parte la que hablaremos sobre algunas particularidades de los recursos como son los paquetes, las referencias entre recursos y los recursos contenidos.

Paquetes de recursos:
Una operación común que se realiza con los recursos es reunir una colección de recursos en una sola instancia. El paquete de recursos no es sólo una lista de referencias a los recursos, sino que incluye todo el contenido (un tipo, una URL y una descripción de texto). Estos paquetes de recursos son útiles para una variedad de razones diferentes, entre las que se encuentran las siguientes:

  • Se puede devolver un conjunto de recursos que cumplan algunos criterios como parte de una operación del servidor.
  • Se puede devolver un conjunto de versiones de los recursos, como parte de la operación de la historia en el servidor.
  • Almacenamiento de una colección de recursos.
  • El intercambio de un conjunto de recursos, como parte de una transacción de mensaje.
  • Agrupación de un conjunto autónomo de recursos para actuar como un grupo intercambiable y persistente con integridad clínica (es decir, un documento clínico).

Conceptualmente, un paquete tiene un identificador (URL), una fecha de actualización, y una lista de recursos. Para cada recurso en la lista, el paquete tiene los recursos y también los meta-datos como se ha indicado anteriormente. Cada entrada en el conjunto conserva su identificador original. Esto significa que las aplicaciones que leen el paquete siempre deben buscar un recurso para su identidad (después de la conversión de URL relativa URL absoluta) en el paquete primero antes de intentar acceder por su URL.

Cardinalidad de recursos:
Todos los elementos definidos en FHIR tienen una cardinalidad como parte de su definición – un número mínimo de apariciones requeridas, y un número máximo permitido. Este número indica el número de veces que el elemento puede aparecer en la instancia. En la especificación, el número mínimo está siempre entre 0 o 1, y el número máximo está siempre entre 1 o *, significa que no hay límite. Los perfiles pueden utilizar cualquier número entero de cardinalidad tanto mínima y máxima, siempre que el mínimo sea menor o igual al máximo.
Para los elementos que tienen cardinalidad superior a 1, el orden en que aparecen puede tener significado. Salvo que la definición del elemento (ya sea en esta memoria descriptiva o la extensión) define un significado al orden explícitamente, el significado de la orden no se define, y las implementaciones se les permite cambiar el orden los elementos. Hay que tener en cuenta que no se puede definir un significado para el orden de los elementos de un perfil. Cuando no hay definición del significado de la orden, las implementaciones que tienen que elegir un solo elemento de una lista de elementos para algún uso deben hacer basados ​​en la semántica del contenido de los elementos que se repite. Perfiles y guías de implementación a menudo pueden hacer reglas sobre este proceso de selección.

Referencias entre recursos:
Los elementos definidos en un recurso pueden incluir muchas referencias a otros recursos. Los recursos se combinan para construir una red de información sobre la salud. En un recurso, las referencias están representadas con un tipo, una referencia, y una descripción de texto. La propiedad clave de la referencia es la referencia que contiene – los recursos son identificados y dirigidos por su URL. La referencia real tiene un aspecto como éste:

<[name] xmlns=”http://hl7.org/fhir”>
<type value=”[code]”/><!– 0..1 Tipo de recurso –>
<reference value=”[string]”/><!– 0..1 Relativa, interna o absoluta URL de referencia –>
<display value=”[string]”/><!– 0..1 Texto alternativo del recurso –>
</[name]>

El type debe especificar el tipo de recurso, si el tipo de referencia de recursos es fija para el elemento de la definición de los recursos.
El elemento de referencia contiene una dirección URL que es o bien una URL absoluta, o una dirección relativa a la URL base de servicio, o un fragmento interno de referencia.
Utilizando URL absolutas se proporciona un enfoque escalable y estable adecuado para un contexto de nube/web, mientras que el uso de referencias relativas/lógicas proporciona un enfoque flexible adecuado para utilizar cuando se realicen a través de los límites del ecosistema cerrado.
Las URL absolutas no deben apuntar a un servidor RESTful FHIR, aunque este es el enfoque preferido. Si la cola de la URL ajusta a la estructura “/ [tipo] / @ [id]” o “/ [tipo] / @ [id] / history / @ [id]”, entonces hay que suponer que la referencia es un servidor RESTful FHIR. Independientemente de si la referencia es a un servidor RESTful FHIR, la referencia debe apuntar a un recurso como se define en esta especificación
Las URL siempre son sensibles al tipo de letra (mayúscula-minuscula) y se prefiere en minúsculas.

Ejemplo de una referencia relativa al paciente “034AB16” de un elemento llamado “context” al servidor REST FHIR:

<context>
<type value=”Patient” />
<reference value=”patient/@034AB16″ />
</context>

Ejemplo de una referencia absoluta al perfil de un recurso en un elemento llamado “profile”:

<profile>
<type value=”Profile” />
<reference value=”http://fhir.hl7.org/svc/profile/@c8973a22-2b5b-4e76-9c66-00639c99e61b” />
</profile>

Recursos contenidos:
En algunas circunstancias, el contenido mencionado en la referencia del recurso no tiene una existencia independiente a parte del recurso que lo contiene – no puede ser identificado de forma independiente, y no puede tener su propio ámbito de transacción independiente. Típicamente, tales circunstancias surgen donde el recurso está siendo ensamblado por un usuario secundario de los datos origen, como un motor de middleware.
Si los datos disponibles cuando se construye el recurso no incluye claves de registro o información de identificación absoluta, entonces un recurso identificado correctamente no se puede montar, e incluso si una identificación arbitraria se asoció con él, el recurso no puede ser el objeto de una operación fuera del contexto del recurso al que se refiere.
En estas circunstancias, el recurso se coloca directamente en línea en la referencia. Esto nunca debe hacerse cuando el contenido puede ser identificado correctamente, ya que una vez se pierde la identificación, es extremadamente difícil (y dependiendo del contexto) volver a restaurarlo de nuevo.

Un ejemplo de un recurso contenido:

<Document xmlns=”http://hl7.org/fhir”>
<extension>…</extension>
<text>…</text>
<contained>
<Organization id=”org1″>
<!– whatever information is available –>
</Organization>
</contained>
<information>
<!– other attributes –>
<custodian>
<type value=”Organization” />
<reference value=”#org1″ />
</custodian>
<!– other attributes –>
<information>
</Document>

El mismo ejemplo escrito con JSON:

{ “Document” : {
“extension” : { … },
“text” : { .. },
“contained: [
{“Organization” : {
“_id” : “org1”,
.. whatever information is available …
}}
]
“information: {
… other attributes …
“custodian” : {
“type” : { “value” : “Organization” },
“url” : { “value” : “#org1” }
}
… other attributes …
}
}}

Algunas notas sobre el uso y la interpretación de los recursos contenidos:

  • Los recursos contenidos comparten el mismo identificador de espacio interno de resolución como el recurso padre.
  • Los recursos contenidos no contienen recursos contenidos adicionales.
  • Los recursos contenidos no es necesario que contengan ningún texto narrativo.

Hasta aquí la segunda parte del post sobre FHIR en una próxima entrega continuaremos hablando sobre esta nueva especificación.

FHIR, la nova especificació HL7 (Part I)

Leer en castellano

Al llarg dels darrers anys, dins l’àmbit de la interoperabilitat entre sistemes al sector sanitari, des de la creació de HL7 i les seves posteriors versions com la actual V3 i altres estàndards com CDA, sempre s’ha intentat buscar una eficient i rapida integració de la informació encapsulada dins aquests missatges i documents mèdics que ajudessin a fer del sistema sanitari mundial alguna cosa que sigui el més beneficiós possible per tothom. FHIR intenta anar més enllà i vol aconseguir una major eficiència en interoperabilitat adaptant les necessitats tecnològiques que hi ha en els temps actuals. Des del CCI explicarem una mica de que tracta aquesta nova especificació.

Perquè es fa necessari?

FHIR es fa necessari perquè:

  • Tot i ser més robust i menys ambigu, HL7 V3 es massa dur, sever i difícil d’aprendre degut a la seva rigidesa i poca flexibilitat i això el fa més lent.
  • Els Documents Clínics CDA no son suficients ja que si bé ofereixen més flexibilitat en estructuració i continguts per altra banda es perd en les avantatges que ofereix HL7 V3.
  • HL7 V2 necessita alguna nova eina pels executors que permeti un camí de transició òptim ja que V2 no proporciona una plataforma moderna pel processament intern i la manipulació de les dades sanitàries.
  • Hi ha nous mercats emergents, com per exemple el de la telefonia mòbil, i si surten noves eines com aplicacions per dispositius cel•lulars HL7 necessita alguna cosa més que oferir.
  • El mon està en constant evolució i la tecnologia i l’enfoc dins l’àmbit de la interoperabilitat també han canviat.

Però…Que és FHIR? Per a què serveix? Quins avantatges ofereix?

FHIR (Recursos d’Interoperabilitat Ràpids en Salut) és un nou projecte estàndard HL7 per a l’intercanvi de dades en l’assistència sanitària que es basa en els principis actuals de la indústria, incloent el núvol, la Web 2.0 i els principis REST. Aquesta especificació HL7 es basa en la definició d’un conjunt de recursos que representen conceptes clínics granulars que es poden gestionar de forma aïllada, o agregats en documents complexos. Aquesta flexibilitat ofereix solucions coherents per a una àmplia gamma de problemes d’interoperabilitat.

Aquests recursos cobreixen els elements bàsics de cobertura sanitària de pacients, admissions, informes de diagnòstic, medicacions i llistes de problemes -amb els seus elements de dada típics- i també permeten donar suport a una gamma de models clínics més ric i complex. Les senzilles i directes definicions d’aquests recursos es basen en la recopilació dels requisits de fonts, anàlisi formal i del mapeig encreuat extensiu de dades a través d’altres estàndards pertinents.

FHIR destaca per reduir la rigidesa dels sistemes (punt dèbil HL7 V3) i treu la necessitat de tractar ineficiències burocràtiques que els sistemes podrien haver arrossegat en casos anteriors. Aquest és un dels beneficis de la integració amb FHIR.

Un dels principals avantatges que també ofereix es que combina les millors característiques d’HL7 V2, HL7 V3 i CDA (Clinical Document Architecture), alhora que aprofita les últimes tecnologies de serveis web.

Com bé diu la definició de l’acrònim FHIR, aquesta especificació com s’ha dit està definida mitjançant l’ús de recursos… però com venen definits i que caracteritza aquests recursos?

Un recurs és una entitat que:

  • Té una identitat coneguda la qual pot ser adreçada.
  • S’identifica com un dels tipus de recursos definits en aquesta especificació.
  • Conté un conjunt d’elements de dades estructurades com descripció per la definició dels recursos.
  • Conté una representació XHTML llegible del contingut del recurs.
  • Pot canviar amb el temps.

Els recursos tenen múltiples representacions. Un recurs és vàlid si compleix les normes anteriors i està representat en XML o JSON (JavaScript Object Notation, format lleuger per l’intercanvi de dades el qual destaca per la seva simplicitat i per ser una alternativa a XML), d’acord amb les regles definides en aquesta especificació. Es permeten altres representacions, però no es descriuen en el present document.

(La imatge mostra com els recursos es combinen per construir una xarxa d’informació sobre l’entorn sanitari).

Tots els recursos estan formats pels següents elements:

  • Un conjunt bàsic d’estructures de dades definides (definició del recurs) mitjançant l’ús de diferents tipus de dades que composen aquestes estructures.
  • Extensions (elements de dades opcionals) addicionals afegides per implementacions. La seva funció es representar aquella informació extra que no forma part de la definició bàsica del recurs.
  • Una descripció narrativa llegible que contindrà un resum del mateix recurs, la seva funció es per representar el contingut del recurs a una persona.
  • Recursos continguts – Recursos addicionals que són part de la identificació i l’espai de transacció d’aquest recurs.
  • Les meta dades (informació important sobre el recurs que no és part del model de contingut del recurs).

Aquests elements han d’aparèixer sempre en aquest ordre. Els elements bàsics comuns a tots els recursos estan en primer lloc per tal de donar suport a definicions consistents per l’esquema i el codi derivat UML.

Fins aqui la primera part del post sobre FHIR. En una propera entrega continuarem parlant sobre aquesta nova especificació.

Llegir en català

Durante los últimos años, en el ámbito de la interoperabilidad entre sistemas en el sector sanitario, desde la creación de HL7 y sus posteriores versiones como la actual V3 y otros estándares como CDA, siempre se ha tratado de buscar una eficiente y rápida integración de la información encapsulada dentro de estos mensajes y documentos médicos que ayuden a hacer del sistema sanitario mundial algo que sea lo más beneficioso posible para todo el mundo. FHIR intenta ir más allá y quiere conseguir una mayor eficiencia en interoperabilidad adaptando las necesidades tecnológicas que hay en los tiempos actuales. Des del CCI explicaremos un poco de que trata esta nueva especificación.

¿Por qué se hace necesario?

FHIR se hace necesario porque:

  • A pesar de ser más robusto y menos ambiguo, HL7 V3 es demasiado duro, severo y difícil de aprender debido a su rigidez y poca flexibilidad y esto lo hace más lento.
  • Los Documentos Clínicos CDA no son suficientes ya que si bien ofrecen más flexibilidad en estructuración y contenidos por otro lado se pierde en las ventajas que ofrece HL7 V3.
  • HL7 V2 necesita alguna nueva herramienta para los ejecutores que permita un camino de transición óptimo ya que V2 no proporciona una plataforma moderna para el procesamiento interno y la manipulación de los datos sanitarios.
  • Hay nuevos mercados emergentes, como por ejemplo el de la telefonía móvil, y si salen nuevas herramientas y aplicaciones para dispositivos celulares HL7 necesita algo más que ofrecer.
  • El mundo está en constante evolución y la tecnología y el enfoque en el ámbito de la interoperabilidad también han cambiado.

Pero… ¿Qué es FHIR? ¿Para qué sirve? ¿Qué ventajas ofrece?

FHIR (Recursos de Interoperabilidad Ràpidos en Salud) es un nuevo proyecto estándar HL7 para el intercambio de datos en la asistencia sanitaria que se basa en los principios actuales de la industria, incluyendo la nube, la Web 2.0 y los principios REST. Esta especificación HL7 se basa en la definición de un conjunto de recursos que representan conceptos clínicos granulares que se pueden gestionar de forma aislada, o agregados en documentos complejos. Esta flexibilidad ofrece soluciones coherentes para una amplia gama de problemas de interoperabilidad.

Estos recursos cubren los elementos básicos de cobertura sanitaria de pacientes, admisiones, informes de diagnóstico, medicaciones y listas de problemas -con sus elementos de datos típicos- y también permiten apoyar una gama de modelos clínicos más rico y complejo. Las sencillas y directas definiciones de estos recursos se basan en la recopilación de los requisitos de fuentes, análisis formal y de mapeo cruzado extensivo de datos a través de otros estándares pertinentes.

FHIR destaca por reducir la rigidez de los sistemas (punto débil de HL7 V3) y saca la necesidad de tratar ineficiencias burocráticas que los sistemas podrían haber arrastrado en casos anteriores. Este es uno de los beneficios de la integración con FHIR.

Una de las principales ventajas que ofrece es que combina las mejores características de HL7 V2, HL7 V3 y CDA (Clinical Document Architecture), al tiempo que aprovecha las últimas tecnologías de servicios web.

Como bien dice la definición del acrónimo FHIR, esta especificación como se ha dicho está definida mediante el uso de recursos… pero ¿como vienen definidos y que caracteriza a estos recursos?

Un recurso es una entitad que:

  • Tiene una identidad conocida la cual puede ser direccionada.
  • Se identifica como uno de los tipos de recursos definidos en esta especificación.
  • Contiene un conjunto de elementos de datos estructuradas como descripción para la definición de los recursos.
  • Contiene una representación XHTML legible del contenido del recurso.
  • Puede cambiar con el tiempo.

Los recursos tienen múltiples representaciones. Un recurso es válido si cumple las normas anteriores y está representado en XML o JSON (JavaScript Object Notation, formato ligero para el intercambio de datos el cual destaca por su simplicidad y por ser una alternativa a XML), de acuerdo con las reglas definidas en esta especificación. Se permiten otras representaciones, pero no se describen en el presente documento.

(La imagen muestra como los recursos se combinan para construir una red de información sobre el entorno sanitario).

Todos los recursos estan formados por los siguientes elementos:

  • Un conjunto básico de estructuras de datos definidas (definición del recurso) mediante el uso de diferentes tipos de datos que componen estas estructuras.
  • Extensiones (Elementos de datos opcionales) adicionales añadidas por implementaciones. Su función es representar aquella información extra que no forma parte de la definición básica del recurso.
  • Una descripción narrativa legible que contendrá un resumen del mismo recurso, su función es para representar el contenido del recurso a una persona para que pueda leerlo con facilidad.
  • Recursos contenidos. Recursos adicionales que son parte de la identificación y el espacio de transacción de este recurso.
  • Los meta datos (información importante sobre el recurso que no es parte del modelo de contenido del recurso).

Estos elementos deben aparecer siempre en este orden. Los elementos básicos comunes a todos los recursos están en primer lugar para dar apoyo a definiciones consistentes para el esquema y el código derivado UML.

Hasta aquí la primera parte del post sobre FHIR. En una próxima entrega seguiremos hablando sobre esta nueva especificación.

Introducció a JSON

Leer en castellano 

JSON (Notació d’Objectes de JavaScript) és un format lleuger d’intercanvi de dades el qual està basat en un subconjunt literal d’objectes del Llenguatge de Programació JavaScript.
Llegir-lo i escriure-ho és simple per persones, mentre que per a les màquines és simple d’interpretar i generar-lo. JSON és un format de text que és completament independent del llenguatge de programació però utilitza convencions que són àmpliament conegudes pels programadors de la família de llenguatges C, incloent C++, C#, Java, JavaScript, Perl, i molts altres.
Aquestes propietats fan que JSON sigui un llenguatge ideal per a l’intercanvi de dades i una molt bona alternativa (o complement) a XML degut a la seva simplicitat i lleugeresa.

JSON està constituït per dues estructures:

– Una col•lecció de parells de nom/valor. En diversos llenguatges això és conegut com un objecte, registre, estructura, diccionari, taula hash, llista de claus o un arranjament associatiu.
– Una llista ordenada de valors. En la majoria dels llenguatges, això s’implementa com arranjaments, vectors, llistes o seqüències.

Els vectors i altres estructures seqüencials per l’estil són estructures universals; virtualment tots els llenguatges de programació les suporten d’una manera o altra. És raonable que un format d’intercanvi de dades que és independent del llenguatge de programació es basi en aquestes estructures.

En JSON, les estructures es presenten d’aquestes formes:

– Un objecte és un conjunt desordenat de parells nom/valor. Un objecte comença amb “{“ (clau d’obertura) i acaba amb “}” (clau de tancament). Cada nom és seguit per dos punts i els parells nom / valor estan separats per una coma.
– Un vector es una col•lecció de valors que comença amb “[“ i acaba amb “]”. Els valors es separen per una coma.
– Un valor pot ser una cadena de caràcters amb cometes dobles, o un número , o true o false o null, o un objecte o un vector. Les estructures poden ser niades.
– Una cadena de caràcters es una col•lecció de 0 o més caràcters Unicode, tancats entre cometes dobles i usant barres divisòries invertides com escape. Un caràcter esta representat per una cadena de caràcters d’un únic caràcter.
– Un número es similar a un número en C o JAVA , excepte que no es fan servir els formats octals i hexadecimals.

Aquí un exemple simple per la definició d’una barra de menús:

{“menu”: {
“id”: “file”,
“value”: “File”,
“popup”: {
“menuitem”: [
{“value”: “New”, “onclick”: “CreateNewDoc()”},
{“value”: “Open”, “onclick”: “OpenDoc()”},
{“value”: “Close”, “onclick”: “CloseDoc()”}
]
}
}
}

La representació JSON es descriu en relació amb la representació XML de la següent manera:

– Els noms dels membres d’objecte JSON són els mateixos que els noms dels elements i atributs XML, inclosos els elements que poden repetir-se.
– En els tipus de dades, el tipus primitiu integer es representa mitjançant un int nadiu JSON, mentre la dada booleana en JSON es representa mitjançant els valors “true” i “false”. Altres tipus primitius com els strings, els decimals, etc es representen com una cadena JSON, utilitzant la mateixa serialització com la forma XML (incloent instant, que es representa com a text pla, no en un dels formats de data JSON personalitzats proposats).
– Igual que en XML, els atributs de propietat JSON mai tenen valors buits, s’omet un valor si està buit.

Hi ha diferències també:

– No hi ha espais de noms (namespaces) en la representació JSON.
– L’ordre no és significatiu en la representació JSON.
– JSON no té una noció d’atributs davant dels elements, de manera que els atributs (xml: id, valor) són tractats com a membres d’objectes JSON.
– JSON té una notació per als vectors i matrius, que s’utilitza per a representar elements que es repeteixen. Cal tenir en compte que aquest és el cas, inclús encara si no es repeteixen en la instància particular.
– L’element <div> XHTML en el tipus de dades narrativa es representa com una sola cadena escapada de XHTML. Això és per evitar problemes en JSON amb contingut mixt etc. XHTML majoritàriament s’ajusta a les regles descrites anteriorment.
– També es pot mencionar que JSON és més lleuger que el format XML a l’ocupar menys espai i representar millor les estructures de les dades.

Exemples per contrastar XML i JSON:

el següent fragment en XML:

<date value=”1972-11-30″/>
<deceased value=”false”/>
<count value=”23″/>

està representat en JSON com:

“date” : { value: “1972-11-30” }
“deceased” : { value: false }
“count” : { value: 23 }

Tots els elements XML poden tenir un atribut ‘id’, que es representa en JSON com una propietat de nom “_id”:

el següent fragment en XML:

<dob id=”314159″ value=”1972-11-30″/>

està representat en JSON com:

“dob”: {
“_id”: “314159”,
“value”: “1972-11-30”
}

Repetició d’elements:

Els elements repetits es fonen dins d’un vector JSON amb el nom de l’element, de manera que si un element <dob> es repeteix en XML, en JSON queda dins d’un vector.

el següent fragment en XML:

<dob value=”2011-11-30″/>
<dob id=”314159″ value=”1972-11-30″/>

està representat en JSON d’aquesta manera:

“dob”: [
{“value”: “2011-11-30”},
{“_id”: “314159”, “value”: “1972-11-30”}
]

 

Llegir en català 

JSON (Notación de Objetos de JavaScript) es un formato ligero de intercambio de datos el cual está basado en un subconjunto literal de objetos del Lenguaje de Programación JavaScript.
Leerlo y escribirlo es simple para personas, mientras que para las máquinas es simple de interpretar y generarlo. JSON es un formato de texto que es completamente independiente del lenguaje de programación pero utiliza convenciones que son ampliamente conocidas por los programadores de la familia de lenguajes C, incluyendo C++, C #, Java, JavaScript, Perl, y muchos otros.
Estas propiedades hacen que JSON sea un lenguaje ideal para el intercambio de datos y una muy buena alternativa (o complemento) a XML debido a su simplicidad y ligereza.

JSON está constituido por dos estructuras:

– Una colección de pares de nombre/valor. En varios lenguajes esto es conocido como un objeto, registro, estructura, diccionario, tabla hash, lista de claves o un arreglo asociativo.
– Una lista ordenada de valores. En la mayoría de los lenguajes, esto se implementa como arreglos, vectores, listas o secuencias.

Los vectores y otras estructuras secuenciales por el estilo son estructuras universales; virtualmente todos los lenguajes de programación las soportan de una manera u otra. Es razonable que un formato de intercambio de datos que es independiente del lenguaje de programación se base en estas estructuras.

En JSON, las estructuras se presentan de estas formas:

– Un objeto es un conjunto desordenado de pares nombre/valor. Un objeto comienza con “{” (llave de apertura) y termina con “}” (llave de cierre). Cada nombre es seguido por dos puntos y los pares nombre / valor están separados por una coma.
– Un vector es una colección de valores que empieza con “[” y termina con “]”. Los valores se separan por una coma.
– Un valor puede ser una cadena de caracteres con comillas dobles, o un número, o true o false o null, o un objeto o un vector. Las estructuras pueden ser anidadas.
– Una cadena de caracteres es una colección de 0 o más caracteres Unicode, encerrados entre comillas dobles y usando barras divisorias invertidas como escape. Un carácter está representado por una cadena de caracteres de un único carácter.
– Un número es similar a un número en C o JAVA, excepto que no se usan los formatos octales y hexadecimales.

Aquí un ejemplo simple para la definición de una barra de menús:

{“menu”: {
“id”: “file”,
“value”: “File”,
“popup”: {
“menuitem”: [
{“value”: “New”, “onclick”: “CreateNewDoc()”},
{“value”: “Open”, “onclick”: “OpenDoc()”},
{“value”: “Close”, “onclick”: “CloseDoc()”}
]
}
}
}

La representación JSON se describe en relación con la representación XML de la siguiente manera:

– Los nombres de los miembros de objeto JSON son los mismos que los nombres de los elementos y atributos XML, incluidos los elementos que pueden repetirse.
– En los tipos de datos, el tipo primitivo integer se representa mediante un int nativo JSON, mientras el dato booleana en JSON se representa mediante los valores “true” y “false”. Otros tipos primitivos como los strings, los decimales, etc se representan como una cadena JSON, utilizando la misma serialización como la forma XML (incluyendo instante, que se representa como texto plano, no en uno de los formatos de fecha JSON personalizados propuestos).
– Al igual que en XML, los atributos de propiedad JSON nunca tienen valores vacíos, se omite un valor si está vacío.

Hay diferencias también:

– No hay espacios de nombres (namespaces) en la representación JSON.
– El orden no es significativo en la representación JSON.
– JSON no tiene una noción de atributos ante los elementos, de modo que los atributos (xml: id, valor) son tratados como miembros de objetos JSON.
– JSON tiene una notación para los vectores y matrices, que se utiliza para representar elementos que se repiten. Hay que tener en cuenta que este es el caso, incluso aún si no se repiten en la instancia particular.
– El elemento <div> XHTML en el tipo de datos narrativa se representa como una sola cadena escapada de XHTML. Esto es para evitar problemas en JSON con contenido mixto etc. XHTML mayoritariamente se ajusta a las reglas descritas anteriormente.
– También se puede mencionar que JSON es más ligero que el formato XML al ocupar menos espacio y representar mejor las estructuras de los datos.

Ejemplos para contrastar XML i JSON:

el siguiente fragmento en XML:

<date value=”1972-11-30″/>
<deceased value=”false”/>
<count value=”23″/>

está representado en JSON como:

“date” : { value: “1972-11-30” }
“deceased” : { value: false }
“count” : { value: 23 }

Todos los elementos XML pueden tener un atributo ‘id’, que se representa en JSON como una propiedad de nombre “_id”:

el siguiente fragmento en XML:

<dob id=”314159″ value=”1972-11-30″/>

está representado en JSON como:

“dob”: {
“_id”: “314159”,
“value”: “1972-11-30”
}

Repetició d’elements:

Los elementos repetidos se unen dentro de un vector JSON con el nombre del elemento, de manera que si un elemento <dob> se repite en XML, en JSON queda dentro de un vector.

el siguiente fragmento en XML:

<dob value=”2011-11-30″/>
<dob id=”314159″ value=”1972-11-30″/>

está representado en JSON de la siguiente manera:

“dob”: [
{“value”: “2011-11-30”},
{“_id”: “314159”, “value”: “1972-11-30”}
]

 

Introducció als Serveis Web RESTful

Leer en castellano

Els serveis web REST (Transferència d’estat representacional) defineixen un conjunt de principis arquitectònics pels quals es dissenyen serveis web fent focus en els recursos del sistema, incloent com s’accedeix a l’estat d’aquests recursos i com es transfereixen per protocol HTTP cap a clients escrits en diversos llenguatges. REST ha emergit en els últims anys com el model predominant per al disseny de serveis. De fet, REST va aconseguir un impacte tan gran a la web que pràcticament va aconseguir desplaçar a SOAP i les interfícies basades en WSDL per tenir un estil bastant més simple d’utilitzar.

Es basa en 4 principis que descriuen la seva manera en que està implementat:

– Utilitza els mètodes HTTP de manera explícita.
– No manté l’estat.
– Exposa URIs amb forma de directoris.
– Transfereix XML, JavaScript Object Notation (JSON), o tots dos.

Utilitza els mètodes HTTP de manera explícita:
Una de les característiques claus dels serveis web REST és l’ús explícit dels mètodes HTTP, seguint el protocol definit per RFC 2616. Per exemple, HTTP GET es defineix com un mètode productor de dades, l’ús està pensat perquè les aplicacions client obtinguin recursos, busquin dades d’un servidor web, o executin una consulta esperant que la web la realitzi i retorni un conjunt de recursos .

REST fa que els desenvolupadors usin els mètodes HTTP explícitament de manera que resulti consistent amb la definició del protocol. Aquest principi de disseny bàsic estableix una associació un-a-un entre les operacions de crear, llegir, actualitzar i esborrar i els mètodes HTTP.

D’acord a aquesta associació:

–    S’usa POST per crear un recurs al servidor.
–    S’usa GET per obtenir un recurs.
–    S’usa PUT per canviar l’estat d’un recurs o actualitzar.
–    S’usa DELETE per eliminar un recurs.

Una falla de disseny poc afortunada que tenen moltes APIs web és l’ús de mètodes HTTP per a altres propòsits. Per exemple, la petició de la URI en una comanda HTTP GET, en general identifica un recurs específic. O el string de consulta al URI inclou un conjunt de paràmetres que defineixen el criteri de recerca que farà servir el servidor per trobar un conjunt de recursos. Almenys, així com el RFC HTTP/1.1 descriu l’GET.

No manté l’estat:
Els serveis web REST necessiten escalar per poder satisfer una demanda en constant creixement. S’usen clústers de servidors amb balanceig de càrrega i alta disponibilitat, proxies, i gateways de manera de conformar una topologia servicial, que permeti transferir peticions d’un equip a un altre per disminuir el temps total de resposta d’una invocació al servei web.
L’ús de servidors intermedis per millorar l’escalabilitat fa necessari que els clients de serveis web REST enviïn peticions completes i independents, és a dir, s’han d’enviar peticions que inclouen totes les dades necessàries per complir la comanda, de manera que els components en els servidors intermedis puguin redireccionar i gestionar la càrrega sense mantenir l’estat localment entre les peticions.

Una petició completa i independent fa que el servidor no hagi de recuperar cap informació de context o estat en processar la petició. Una aplicació o client de servei web REST  ha d’incloure dins de la capçalera i del cos HTTP de la petició tots els paràmetres, context i dades que necessita el servidor per generar la resposta. D’aquesta manera, el no mantenir estat millora el rendiment dels serveis web i simplifica el disseny i implementació dels components del servidor, ja que l’absència d’estat al servidor elimina la necessitat de sincronitzar les dades de la sessió amb una aplicació externa.

Exposa URIs amb forma de directoris:
Des del punt de vista del client de l’aplicació que accedeix a un recurs, la URI determina què tan intuïtiu serà el web service REST, i si el servei va a ser utilitzat tal com va ser pensat al moment de dissenyar-lo. La tercera característica dels serveis web REST és justament sobre les URIs.

Les URI dels serveis web REST han de ser intuïtives, fins al punt que sigui fàcil endevinar. Pensem en les URI com una interfície auto-documentada que necessita de molt poca o cap explicació o referència perquè un desenvolupador pugui comprendre al que apunta, i als recursos derivats relacionats.

Una forma d’aconseguir aquest nivell d’usabilitat és definir URIs amb una estructura a l’estil dels directoris. Aquest tipus d’URIs és jeràrquica, amb una única ruta arrel, i va obrint branques a través de les subrutes per exposar les àrees principals del servei. D’acord a aquesta definició, una URI no és només una cadena de caràcters delimitada per barres, sinó més aviat un arbre amb subordinats i pares organitzats com a nodes. Per exemple, en un servei de fils de discussions que té temes diversos, es podria definir una estructura d’URI com aquesta:

http://www.elmeuservei.org/discusio/temes/ {tema}

L’arrel, /discusio, té un node /temes com fill. Sota aquest node hi ha un conjunt de noms de temes (com ser tecnologia, actualitat, i més), cadascun dels quals apunta un fil de discussió. Dins d’aquesta estructura, resulta fàcil recuperar fils de discussió al tipejar alguna cosa després d’/ temes /.

En alguns casos, la ruta a un recurs encaixa molt bé dins la idea de “estructura de directoris”. Per exemple, prenguem alguns recursos organitzats per data, que són molt pràctics d’organitzar usant una sintaxi jeràrquica.

Transfereix XML, JavaScript Object Notation (JSON), o tots dos:
La representació d’un recurs en general reflecteix l’estat actual del mateix i els seus atributs al moment en què el client de l’aplicació realitza la petició. La representació del recurs són simples “fotos” en el temps. Això podria ser una representació d’un registre de la base de dades que consisteix en l’associació entre columnes i tags XML, on els valors dels elements en l’XML contenen els valors de les files. O, si el sistema té un model de dades, la representació d’un recurs és una fotografia dels atributs d’una de les coses en el model de dades del sistema.

L’última restricció al moment de dissenyar un servei web REST té a veure amb el format de les dades que l’aplicació i el servei s’intercanvien en les peticions/respostes. Aquí és on realment val la pena mantenir les coses simples, llegibles per persones, i connectades.

Els objectes del model de dades generalment es relacionen d’alguna manera, i les relacions entre els objectes del model de dades (els recursos) s’han de reflectir en la forma en què es representen al moment de transferir les dades al client. En el servei de fils de discussió anterior, un exemple d’una representació d’un recurs connectat podria ser un tema de discussió arrel amb tots els seus atributs, i links embeguts a les respostes al tema.

<discusio data=”{data}” tema=”{tema}”>
<comentari> {comentari} </comentari>
<respostes>
<resposta de = “gaz@mail.com “href =” /discussió/temes/{tema}/gaz “/>
<resposta de = “gir@mail.com “href =” /discussió/temes/{tema}/gir “/>
</respostes>
</discusio>

Conclusió: No sempre REST és la millor opció. Està sorgint com una alternativa per dissenyar serveis web amb menys dependència en middleware propietari (per exemple, un servidor d’aplicacions), que el seu contrapart SOAP i els serveis basats en WSDL. D’alguna manera, REST és la volta a la Web abans de l’aparició dels grans servidors d’aplicacions, ja que fa èmfasi en els primers estàndards d’Internet, URI i HTTP. XML sobre HTTP és una interfície molt poderosa que permet que aplicacions internes, com interfícies basades en JavaScript asíncron + XML (AJAX) puguin connectar-se, situar i consumir recursos. De fet, és justament aquesta gran combinació amb AJAX la que va generar aquesta gran atenció que ha tingut REST avui en dia.
Resulta molt flexible el poder exposar els recursos del sistema amb un API REST, de manera de brindar dades a diferents aplicacions, formats en diferents maneres. REST ajuda a complir amb els requeriments d’integració que són crítics per construir sistemes on les dades s’han de poder combinar fàcilment i estendre. Des d’aquest punt de vista, els serveis REST es converteixen en alguna cosa molt més gran.

Llegir en català

Los servicios web REST (Transferencia de estado representacional) definen un conjunto de principios arquitectónicos por los que se diseñan servicios web haciendo foco en los recursos del sistema, incluyendo cómo se accede al estado de estos recursos y cómo se transfieren por protocolo HTTP a clientes escritos en varios lenguajes. REST ha emergido en los últimos años como el modelo predominante para el diseño de servicios. De hecho, REST logró un impacto tan grande en la web que prácticamente logró desplazar a SOAP y las interfaces basadas en WSDL por tener un estilo bastante más simple de utilizar.

Se basa en 4 principios que describen su forma en que está implementado:

– Utiliza los métodos HTTP de manera explícita.
– No mantiene el estado.
– Expone URIs con forma de directorios.
– Transfiere XML, JavaScript Object Notation (JSON), o ambos.

Utiliza los métodos HTTP de manera explícita:
Una de las características claves de los servicios web REST es el uso explícito de los métodos HTTP, siguiendo el protocolo definido por RFC 2.616. Por ejemplo, HTTP GET se define como un método productor de datos, el uso está pensado para que las aplicaciones cliente obtengan recursos, busquen datos de un servidor web, o ejecuten una consulta esperando que la web la realice y devuelva un conjunto de recursos.

REST hace que los desarrolladores usen los métodos HTTP explícitamente de manera que resulte consistente con la definición del protocolo. Este principio de diseño básico establece una asociación uno-a-uno entre las operaciones de crear, leer, actualizar y borrar y los métodos HTTP.

De acuerdo a esta asociación:

– Se usa POST para crear un recurso en el servidor.
– Se usa GET para obtener un recurso.
– Se usa PUT para cambiar el estado de un recurso o actualizar.
– Se usa DELETE para eliminar un recurso.

Una falla de diseño poco afortunada que tienen muchas APIs web es el uso de métodos HTTP para otros propósitos. Por ejemplo, la petición de la URI en un pedido HTTP GET, en general identifica un recurso específico. O el string de consulta al URI incluye un conjunto de parámetros que definen el criterio de búsqueda que utilizará el servidor para encontrar un conjunto de recursos. Al menos, así como el RFC HTTP/1.1 describe el GET.

No mantiene el estado:
Los servicios web REST necesitan escalar para poder satisfacer una demanda en constante crecimiento. Se usan clústeres de servidores con balanceo de carga y alta disponibilidad, proxies, y gateways de manera de conformar una topología servicial, que permita transferir peticiones de un equipo a otro para disminuir el tiempo total de respuesta de una invocación al servicio web.
El uso de servidores intermedios para mejorar la escalabilidad hace necesario que los clientes de servicios web REST envíen peticiones completas e independientes, es decir, se deben enviar peticiones que incluyen todos los datos necesarios para cumplir el pedido, de manera que los componentes en los servidores intermedios puedan redireccionar y gestionar la carga sin mantener el estado localmente entre las peticiones.

Una petición completa e independiente hace que el servidor no tenga que recuperar ninguna información de contexto o estado al procesar la petición. Una aplicación o cliente de servicio web REST debe incluir dentro de la cabecera y del cuerpo HTTP de la petición todos los parámetros, contexto y datos que necesita el servidor para generar la respuesta. De esta manera, el no mantener estado mejora el rendimiento de los servicios web y simplifica el diseño e implementación de los componentes del servidor, ya que la ausencia de estado en el servidor elimina la necesidad de sincronizar los datos de la sesión con una aplicación externa.

Expone URIs con forma de directorios:
Desde el punto de vista del cliente de la aplicación que accede a un recurso, la URI determina qué tan intuitivo será el servicio web REST, y si el servicio va a ser utilizado tal como fue pensado al momento de diseñarlo. La tercera característica de los servicios web REST es justamente sobre las URIs.

Las URI de los servicios web REST deben ser intuitivas, hasta el punto que sea fácil adivinar. Pensamos en las URI como una interfaz auto-documentada que necesita de muy poca o ninguna explicación o referencia para que un desarrollador pueda comprender al que apunta, y los recursos derivados relacionados.

Una forma de lograr este nivel de usabilidad es definir URIs con una estructura al estilo de los directorios. Este tipo de URIs es jerárquica, con una única ruta raíz, y abriendo ramas a través de las subrutas para exponer las áreas principales del servicio. De acuerdo a esta definición, una URI no es sólo una cadena de caracteres delimitada por barras, sino más bien un árbol con subordinados y padres organizados como nodos. Por ejemplo, en un servicio de hilos de discusiones que tiene temas diversos, se podría definir una estructura de URI como esta:

http://www.miservicio.org/discusion/temas/ {tema}

La raíz, /discusión, tiene un nodo /temas como hijo. Bajo este nodo hay un conjunto de nombres de temas (como ser tecnología, actualidad, y más), cada uno de los cuales apunta un hilo. Dentro de esta estructura, resulta fácil recuperar hilos de discusión en tipear alguna cosa después de /temas/.

En algunos casos, la ruta a un recurso encaja muy bien dentro de la idea de “estructura de directorios”. Por ejemplo, tomemos algunos recursos organizados por fecha, que son muy prácticos de organizar usando una sintaxis jerárquica.

Transfiere XML, JavaScript Object Notation (JSON), o ambos:
La representación de un recurso en general refleja el estado actual del mismo y sus atributos al momento en que el cliente de la aplicación realiza la petición. La representación del recurso son simples “fotos” en el tiempo. Esto podría ser una representación de un registro de la base de datos que consiste en la asociación entre columnas y tags XML, donde los valores de los elementos en el XML contienen los valores de las filas. O, si el sistema tiene un modelo de datos, la representación de un recurso es una fotografía de los atributos de una de las cosas en el modelo de datos del sistema.

La última restricción al momento de diseñar un servicio web REST tiene que ver con el formato de los datos que la aplicación y el servicio se intercambian en las peticiones / respuestas. Aquí es donde realmente vale la pena mantener las cosas simples, legibles por personas, y conectadas.

Los objetos del modelo de datos generalmente se relacionan de alguna manera, y las relaciones entre los objetos del modelo de datos (los recursos) se reflejarán en la forma en que se representan en el momento de transferir los datos al cliente. En el servicio de hilos de discusión anterior, un ejemplo de una representación de un recurso conectado podría ser un tema de discusión raíz con todos sus atributos, y links embebidos en las respuestas al tema.

<discusion data=”{data}” tema=”{tema}”>
<comentario> {comentario} </comentario>
<respuestas>
<respuesta de = “gaz@mail.com “href =” /discusion/temas/{tema}/gaz “/>
<respuesta de = “gir@mail.com “href =” /discusion/temas/{tema}/gir “/>
</respuestas>
</discusion>

Conclusión: No siempre REST es la mejor opción. Está surgiendo como una alternativa para diseñar servicios web con menos dependencia en middleware propietario (por ejemplo, un servidor de aplicaciones), que su contraparte SOAP y los servicios basados en WSDL. De alguna manera, REST es la vuelta a la Web antes de la aparición de los grandes servidores de aplicaciones, ya que hace hincapié en los primeros estándares de Internet, URI y HTTP. XML sobre HTTP es una interfaz muy poderosa que permite que aplicaciones internas, como interfaces basadas en JavaScript asíncrono + XML (AJAX) puedan conectarse, ubicar y consumir recursos. De hecho, es justamente esta gran combinación con AJAX la que generó esta gran atención que ha tenido REST hoy en día.
Resulta muy flexible el poder exponer los recursos del sistema con un API REST, de manera de brindar datos a diferentes aplicaciones, formatos en diferentes maneras. REST ayuda a cumplir con los requerimientos de integración que son críticos para construir sistemas donde los datos deben poder combinar fácilmente y extender. Desde este punto de vista, los servicios REST se convierten en algo mucho más grande.

Anàlisis Mirth Connect VERSIÓ 2.2.1 vs. VERSIÓ 3.0.0 Beta 2 (II)

Leer en castellano

Des del CCI estem analitzant les diferencies entre la versió 2.2.1 i la 3.0 de Mirth Connect, la setmana passada varem fer la primera part del post, avui acabarem d’analitzar la resta de finestres i aspectes a destacar restants.

Anàlisis de millores/modificacions a l’editar Settings:
Per fer i restaurar un Backup (copia de seguretat) ara es fa des de la barra lateral esquerra, a més han aparegut tres noves pestanyes amb noves opcions.


En aquestes pestanyes es pot configurar alguns aspectes destacables. La primera pestanya (server) es divideix en dos parts (Configuration i Email) en la qual es poden configurar paràmetres com per exemple esborrar el global map al fer redeploy, decidir la comprovació d’actualitzacions o triar la URL des d’on es faran aquestes. A la part de sota es poden configurar paràmetres de connexió amb una adreça de correu electrònic. La segona pestanya (Administrator) permet configurar una secció de preferències entre les quals és pot decidir l’intèrval de temps que ha de transcórrer per actualitzar el Dashboard, la mida de la pàgina de l’explorador dels missatges entre altres paràmetres a destacar. La tercera pestanya (Message Pruner) permet planificar o programar l’esborrament dels missatges així com altres aspectes relacionats amb l’arxivament d’aquests.

A la següent imatge es poden veure el contingut de cadascuna de les noves pestanyes de Settings:


Anàlisis de millores/modificacions a la pestanya Alerts:
Totes les funcionalitats referents a la creació, edició i la importació d’Alertes no es veuen alterades i funciona de la mateixa manera que amb la versió anterior.

Anàlisis de millores/modificacions a la pestanya Events:
El seu contingut no difereix gaire del que ja tenia la versió anterior.


Anàlisis de millores/modificacions a la pestanya Extensions:
A la versió anterior aquesta pestanya s’anomenava “Plugins”, a la nova versió aquesta pestanya incorpora a més els connectors així com els plugins instal.lats, i a més a la part inferior s’adjunta una barra amb botons per indicar la ruta del connector o plugins per fer la instal.lació en cas de voler-ne afegir manualment.


Modificació a la finestra per enviar missatges:
La finestra per enviar missatges a través d’una caixa de text s’ha vist millorada al poder triar les diferents destinacions que es vulgui, així es pot tenir més opcions per fer les proves i verificacions pertinents entre els canals que es desitgi provar.

Fins aquí el post d’anàlisis comparatiu de les versions Mirth connect 2.2.1 i 3.0!

Llegir en català

Desde el CCI estamos analizando las diferencias entre la versión 2.2.1 y la 3.0 de Mirth Connect, la semana pasada hicimos la primera parte del post, hoy acabaremos de analizar el resto de ventanas y aspectos a destacar restantes.

Anàlisis de mejoras/modificaciones al editar Settings:
Para hacer y restaurar Copias de Seguridad (Backups) ahora se hacen desde la barra lateral izquierda, además han aparecido tres nuevas pestañas con nuevas opciones.

En estas pestañas se pueden configurar algunos aspectos destacables. La primera pestaña (server) se divide en dos partes (Configuration y Email) en la cual se pueden configurar parámetros como por ejemplo borrar el global map al hacer redeploy, decidir la comprobación de actualizaciones o elegir la URL desde donde se harán estas. A la parte de debajo se pueden configurar parámetros de conexión con una dirección de correo electrónico. La segunda pestaña (Administrator) permite configurar una sección de preferencias entre las cuales se puede decidir el intervalo de tiempo que tiene que transcurrir para actualizar el Dashboard, la medida de la página del explorador de los mensajes entre otros parámetros a destacar. La tercera pestaña (Message Pruner) permite planificar o programar el borrado de los mensajes así como otros aspectos relacionados con el archivamiento de estos.

En la siguiente imagen se puede ver el contenido de cada una de las nuevas pestañas de Settings:

Anàlisis de mejoras/modificaciones en la pestaña Alerts:
Todas las funcionalidades referentes a la creación, edición y la importación de Alertas no se ven alteradas y funcionan del mismo modo que con la versión anterior.

Anàlisis de mejoras/modificaciones en la pestaña Events:
Su contenido no difiere mucho del que ya tenía la versión anterior.

Anàlisis de mejoras/modificaciones en la pestaña Extensions:
En la versión anterior esta pestaña se denominaba “Plugins”, en esta nueva versión esta pestaña incorpora además los conectores así como los plugins instalados, y además en la parte inferior se adjunta una barra con botones para indicar la ruta del conector o plugins para hacer la instalación en caso de querer añadirlos manualmente.

Modificación en la ventana para mandar mensajes:
La ventana para enviar mensajes a través de una caja de texto se ha visto mejorada al poder elegir los diferentes destinos que se quiera, así se puede tener más opciones para hacer las pruebas y verificaciones pertinentes entre los canales que se desee probar.

Hasta aqui el post de anàlisis comparativo de las versiones Mirth connect 2.2.1 i 3.0!

Anàlisis Mirth Connect VERSIÓ 2.2.1 vs. VERSIÓ 3.0.0 Beta 2 (I)

Leer en castellano

Des del CCI estem analitzant les diferencies entre la versió 2.2.1 i la 3.0 de Mirth Connect, en aquesta primera part explicarem aquelles modificacions que s’han realitzat a les finestres i dels nous usos que s’han introduït.
Primerament abans d’entrar a fer l’anàlisi, a continuació es mostra un llistat d’aquells punts a destacar més importants que s’han introduït d’una versió a l’altre (només algunes de les millores més importants o destacables).

Llista de les millores més destacades:

  • Els Scripts/plantilles de canal només es guarden sense ser emmagatzemats a la base de dades.
  • Es permeten LLP destí per reenviar missatges NACK un nombre de vegades determinat.
  • Un missatge enviat a través d ‘”Enviar Resposta a” ha d’especificar la ID del canal font a la ChannelMap.
  • Mostrar sessió JMS (servei de missatges Java) per publicar Script de processament.
  • Reescriptura dels connectors JMS (Els connectors JMS ara tenen la habilitat de restablir automàticament
    la connexió en cas que es perdi de manera inesperada).
  • Canvi de les columnes de text a nvarchar (max) per Scripts SQL Server.
  • Afegit “filtre de resposta / transformador” al connector de destinació.
  • Possibilitat d’actualitzar per iText 2.1.7 i Flying Saucer 9.0.1.
  • Cues a una IP i port que només permeten una sessió.
  • Canvis en els tipus de dades per permetre diferents propietats d’entrada i sortida.
  • Crear un nou quadre de diàleg per eliminar tots els missatges, que inclou l’opció per a esborrar les estadístiques.
  • Reescriptura de lector/gravador de bases de dades.
  • El FileReader permet canviar el nom dels arxius entrants sense moure a un altre directori.
  • Millora de l’aspecte dels quadres combinats (combo box) en cel·les de la taula.
  • Afegida una opció per activar/desactivar la podadora de missatges (Message Pruning).
  • Fer que el diàleg dels tipus de dades només es permeti guardar si es premut el botó Acceptar.
  • Es determina el comportament correcte quan l’error/excepció ocorre en el transformador resposta.
  • Es determina si els valors nuls s’han de revisar en els serialitzadors de tipus de dades.
  • Es determina per a cada tipus de dades sense propietats per defecte les que causaran l’execució del transformador.
  • Afegida columna Errors a la finestra del missatge.
  • Actualització de les columnes de l’examinador de missatges predeterminat.

Llista d’algunes noves característiques:

  • Afegida la possibilitat d’importar missatges des del sistema de fitxers del servidor.
  • Es desen història de cua i reintents (estat, missatge d’error, data i hora).
  • Es pot convertir tipus de dades a un format plug-in.
  • S’afegeixen els mapes connector/canal/resposta i el nom del connector a l’abast del preprocessador.
  • Es desen els errors del post-processor i es mostren a la finestra del missatge.

Si es desitja aprofundir més en tota aquesta informació de manera més detallada aquí s’adjunta l’enllaç oficial de les notes de la versió:

http://www.mirthcorp.com/community/issues/secure/ReleaseNote.jspa?projectId=10000&version=11879


Anàlisis de millores/modificacions al Dashboard:
El Dashboard és pràcticament igual en aspecte al de la versió anterior però al peu de la finestra han aparegut noves característiques:

A diferència del Dashboard de la versió anterior han afegit unes noves pestanyes per poder consultar les estadístiques actuals i l’historial. A més apareix un boto per habilitar una mena de filtres per tipus de canals que s’hauràn definit previament al crear/editar un canal. Aquest filtratge es fa amb la definició de tags (etiquetes). També apareixen les estadístiques del connector origen i destinació (A la següent imatge es veu la finestra on es mostren les estadístiques pels missatges que passen pel source. La del destination té el mateix tipus d’aspecte). En aquesta pantalla es veura desglosat per cada missatge enviat les diferents estadístiques tant pel source com pel destination i si s’ha produït algun error es podrà accedir millor per veure a quin punt ha succeït.

 

Anàlisis de millores/modificacions a l’editar canals (Edit Channel):
Quan es crea i edita un canal a la pestanya summary apareixen un conjunt de noves característiques:

 

Cal destacar a la inclusió del botó Set Data Types, que al pitjar-lo apareix una nova finestra (veure següent imatge) per poder canviar el tipus de dades i permetre diferents propietats d’entrada i sortida, el checkbox per decidir si es vol esborrar el global map al tornar a posar en funcionament (redeploy) un canal que s’ha modificat.
També destaca el fet que es pot afegir informació útil adjunta (Attachment) la qual es pot escollir entre diferents tipus com l’estàndard d’intercanvi d’imatges mèdiques(DICOM), codi Javascript, o expressions regulars (Regex) entre altres.
Després s’inclou una subfinestra per modificar el tipus d’emmagatzematge dels missatges (Message Storage) per si es vol fer de tota la informació del missatge o de menys. Una altre subfinestra (Channel Tags) per definir les etiquetes del canal per així poder fer un mostreig per filtratge (es mostren els canals que tinguin definida un mateix tag (etiqueta)) així com una altre per la configuració de l’esborrament dels missatges (Message Pruning), tant de meta dades com de continguts.

 

La pantalla anterior Set Data Types permet modificar propietats entrants i sortints així com propietats de serialització i de generació de respostes. Per exemple, si s’escull que el tipus de missatge a processar es un document en XML, llavors aquí es podria triar les propietats que tindria aquest fitxer tant pel source com pel destination. Cada tipus de missatge te uns paràmetres propis que poden ser modificats de manera individual (Single Edit) o de manera conjunta (Bulk Edit).

A l’hora d’editar filtres o transformadors, la manera de fer la configuració continua sent la mateixa sense haver introduït cap mena de modificacions destacades.

Anàlisis de millores/modificacions a la pestanya Users:

Totes les funcionalitats referents a la creació, edició i eliminació d’usuaris es manté igual que a la versió anterior.

Fins aqui la primera part del post, la semana vinent es publicarà la segona part!

Llegir en català

Desde el CCI estamos analizando las diferencias entre la versión 2.2.1 y la 3.0 de Mirth Connect, en esta primera parte explicaremos aquellas modificaciones de las ventanas y de los nuevos usos que se han introducido.
Primeramente antes de entrar a analizar las modificaciones y mejoras de las diferentes ventanas que componen Mirth, a continuación se muestra un listado de aquellos puntos a destacar más importantes que se han introducido de una versión a otra (sólo algunas de las más importantes o destacables).

Lista de las mejoras más destacadas:

  • Los Scripts/plantillas de canal sólo se guardan sin ser almacenados a la base de datos.
  • Se permiten LLP destino para reenviar mensajes NACK un número a veces determinado.
  • Un mensaje enviado a través de ‘”Enviar Respuesta a” tiene que especificar la ID del canal fuente a la ChannelMap.
  • Mostrar sesión JMSSession (servicio de mensajes Java) para publicar Script de procesamiento.
  • Reescritura de los conectores JMS (Los conectores JSM ahora tienen la habilidad de restablecer automáticamente la conexión en caso de que se pierda de manera inesperada).
  • Cambio de las columnas de texto a nvarchar (max) por Scripts SQL Server.
  • Añadido “filtro de respuesta / transformador” al conector de destino.
  • Posibilidad de actualizar por iText 2.1.7 y Flying Saucer 9.0.1.
  • Colas a una IP y puerto que sólo permiten una sesión.
  • Cambios en los tipos de datos para permitir diferentes propiedades de entrada y salida.
  • Crear un nuevo cuadro de diálogo para eliminar todos los mensajes, que incluye la opción para borrar las estadísticas.
  • Re-escritura de lector/grabador de bases de datos.
  • El FileReader permite cambiar el nombre de los archivos entrantes sin mover a otro directorio.
  • Mejora del aspecto de los cuadros combinados (combo box) en celdas de la tabla.
  • Añadida una opción para activar/desactivar la podadora de mensajes (Message Pruning).
  • Hacer que el diálogo de los tipos de datos sólo se permita guardar si se ha pulsado el botón Aceptar.
  • Se determina el comportamiento correcto cuando el error/excepción ocurre en el transformador respuesta.
  • Se determina si los valores nulos se tienen que revisar en los serializadores de tipos de datos.
  • Se determina para cada tipo de datos sin propiedades por defecto las que causarán la ejecución del transformador.
  • Añadida columna Errores a la ventana del mensaje.
  • Actualización de las columnas del examinador de mensajes predeterminado.

Lista de algunas nuevas características:

  • Añadida la posibilidad de importar mensajes desde el sistema de ficheros del servidor.
  • Se guardan historia de cola y reintentos (estado, mensaje de error, fecha y hora).
  • Se puede convertir tipo de datos a un formato plug-in.
  • Se añaden los mapas conector/canal/respuesta y el nombre del conector al alcance del preprocessador.
  • Se guardan los errores del post-processor y se muestran a la ventana del mensaje.

Si se desea profundizar más en toda esta información de manera más detallada aquí se adjunta el enlace oficial de las notas de la versión:
http://www.mirthcorp.com/community/issues/secure/ReleaseNote.jspa?projectId=10000&version=11879

Anàlisis de mejoras/modificaciones en el Dashboard:
El Dashboard es prácticamente igual en aspecto al de la versión anterior pero al pie de la ventana han aparecido nuevas características:

A diferencia del Dashboard de la versión anterior se han añadido unas nuevas pestañas para poder consultar las estadísticas actuales y el historial. Además aparece un botón para habilitar la visibilidad mediante el uso de filtros por tipos de canales que se hallan definido previamente al crear/editar un canal. También aparecen las estadísticas del conector origen y destino (A la siguiente imagen se ve la ventana donde se muestran las estadísticas por los mensajes que pasan por el source. La del destination tiene el mismo tipo de aspecto). En esta pantalla se verá desglosado por cada mensaje enviado las diferentes estadísticas tanto por el source cómo por el destination y si se ha producido algún error se podrá acceder mejor para ver en qué punto ha sucedido.

 

Anàlisis de mejoras/modificaciones al editar canales (Edit Channel):

Cuando se crea y edita un canal en la pestaña summary aparecen un conjunto de nuevas características:

 

Hay que destacar a la inclusión del botón Set Data Types, que al pulsarlo aparece una nueva ventana (ver siguiente imagen) para poder cambiar el tipo de datos y permitir diferentes propiedades de entrada y salida, el checkbox para decidir si se quiere borrar el global map al volver a poner en funcionamiento (redeploy) un canal que se ha modificado.
También destaca el hecho que se puede añadir información útil adjunta (Attachment) la cual se puede escoger entre diferentes tipos como el estándar de intercambio de imágenes médicas (DICOM), código Javascript, o expresiones regulares (Regex) entre otras.
Después se incluye una sub-ventana para modificar el tipo de almacenamiento de los mensajes (Message Storage) por si se quiere hacer de toda la información del mensaje o de menos. Otra sub-ventana (Channel Tags) para definir las etiquetas del canal para así poder hacer un muestreo por filtraje (se muestran los canales que tengan definida un mismo tag (etiqueta)) así como otra por la configuración del borrado de los mensajes (Message Pruning), tanto de meta datos como de contenidos.

 

La pantalla anterior Set Data Types permite modificar propiedades entrantes y salientes así como propiedades de Serialización y de generación de respuestas. Por ejemplo, si se elije que el tipo de mensaje a procesar es un documento XML, entonces aquí se podrían elegir las propiedades que tendría este fichero tanto en el source como el destination. Cada tipo de mensaje tiene unos parámetros propios que pueden ser modificados de manera individual (Single Edit) o de manera conjunta (Bulk Edit).

A la hora de editar filtros o transformadores, la manera de hacer la configuración sigue siendo la misma sin haber introducido ningún tipo de modificaciones destacadas.

Anàlisis de mejoras/modificaciones en la pestanya Users:

Todas las funcionalidades referentes a la creación, edición y eliminación de usuarios se mantiene igual que en la versión anterior.

Hasta aquí la primera parte del post, la próxima semana se publicará la segunda parte!