Review de Messaging Workbench

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)

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)

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.