Entrades classificades amb: HL7

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.

Nova edició del taller d’Introducció a SNOMED CT i Vocabularis Clínics Controlats

Leer en castellano

Els passats dies 30 i 31 de maig es va dur a terme el taller presencial d’introducció a SNOMED CT i Vocabularis Clínics Controlats, organitzat des del CCI, HL7 Spain i TicSalut. El curs de 10 hores es va fer a Barcelona i va comptar amb la participació de 9 alumnes de diferents regions d’Espanya.

Al taller es va realitzar una introducció a la terminologia biomèdica i a l’estàndard semàntic SNOMED CT. Es van descriure els components bàsics (conceptes, descripcions, relacions i historial) i avançats (mapejos, subconjunts i extensions) de SNOMED CT i es va explicar com crear Clinical Statements amb expressions post-coordinades. L’edició d’enguany també va incloure una presentació sobre serveis de terminologia i l’estàndard d’HL7 CTS2 (Common Terminology Services Release 2). El taller va finalitzar amb un repàs pels estàndards d’HL7, detallant com utilitzar CDA en combinació amb SNOMED CT per representar documents clínics i el significat del seu contingut, d’una manera inequívoca.

Els coneixements teòrics es van complementar amb exercicis pràctics i un cas d’ús de SNOMED CT pel domini d’al·lèrgies basat en l’experiència real del Sistema Sanitari Català. Els alumnes van instal·lar i utilitzar el navegador de SNOMED CT ClíniClue Xplore i el servidor de Terminologia ITS (Integrated Terminology System) d’Indizen per dur a terme les parts pràctiques.

Al següent enllaç es pot consultar el tríptic del taller: Taller presencial introducció a SNOMED CT i Vocabularis Clínics Controlats, edició Barcelona.

Llegir en català

Los pasados días 30 y 31 de mayo se realizó el taller presencial de introducción a SNOMED CT y Vocabularios Clínicos Controlados, organizado des del CCI, HL7 Spain y TicSalut. El curso de 10 horas tuvo lugar en Barcelona y contó con la participación de 9 alumnos de diferentes regiones de España.

En el taller se hizo una introducción a la terminología biomédica i al estándar semántico SNOMED CT. Se describieron los componentes básicos (conceptos, descripciones, relaciones e historial) y avanzados (subconjuntos, mapeos y extensiones) de SNOMED CT y se explicó cómo crear Clinical Statements con expresiones post-coordinadas. La edición de este año también incluyó una presentación sobre servicios de terminología y el estándar de HL7 CTS2 (Common Terminology Services Release 2). El taller finalizó con un repaso por los estándares de HL7, detallando como utilizar CDA en combinación con SNOMED CT para representar documentos clínicos y el significado de su contenido, de una manera inequívoca.

Los conocimientos teóricos se complementaron con ejercicios prácticos y un caso de uso de SNOMED CT para el dominio de alergias basado en la experiencia real del Sistema Sanitario Catalán. Los alumnos instalaron y utilizaron el navegador de SNOMED CT ClíniClue Xplore y el servidor de Terminología ITS (Integrated Terminology System) de Indizen para realizar las partes prácticas.

En el siguiente enlace se puede consultar el tríptico del taller: Taller presencial de introducción a SNOMED CT y Vocabularios Clínicos Controlados, edición Barcelona.

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.

Interoperabilidad, la base para una atención integrada del paciente crónico

Leer en castellano

El CCI va participar els passats dies 19 i 20 de març a la Jornada tècnica d’interoperabilitat organitzada pel Servei Andalús de Salut, IHE Espanya i HL7 Spain que tenia per títol “Interoperabilidad, la base para una atención integrada del paciente crónico”.
Al primer dia de la jornada es van realitzar les tres sessions següents:

  • Reunió del comitè tècnic d’HL7 Spain, en la qual es van repassar les principals novetats i avenços més rellevants des de l’última reunió. Destacar que s’ha començat a treballar en les derivacions de proves diagnòstiques, tant des del punt de vista funcional com de missatgeria i informes associats.
  • Presentació “Últimos avances en los estándares de documentación clínica”, orientada a acostar els estàndards al perfil documentalista.
  • Sessió IHE centrada en la implantació de XDS a Espanya.

Al segon dia es van realitzar diferents intervencions sobre la interoperabilitat entre sistemes i la integració de dispositius, presentant estàndards i sistemes que permeten garantir la continuïtat assistencial a diferents nivells. Es van destacar els nous reptes que tenen els CIOs en quant a la interoperabilitat i a l’atenció dels pacients crònics, així com a la importància de la capacitació del ciutadà de manera que formi part activa de la seva salut. Aquestes ponències es van complementar explicant el paper dels perfils IHE, de la norma CONTSYS (ISO/DIS 13940) i dels estàndards d’HL7, incloent els d’àmbit semàntic com CTS2 (Common Terminology Services Release 2). L’esdeveniment va finalitzar amb la compartició d’experiències i la presentació de diferents eines. Des del CCI-OFSTI es va realitzar una ponència sobre serveis terminològics avançats:

A la presentació es va explicar la necessitat d’aquesta mena de serveis, així com les funcionalitats que poden cobrir les eines que els ofereixen. També es va presentar l’estàndard CTS2, que defineix, a nivell funcional, una interfície estàndard per l’ús i la gestió de terminologies. Per acabar la intervenció, es va resumir la participació del CCI al grup de serveis semàntics del projecte europeu epSOS, en el qual es treballa amb l’estàndard CTS2.

Llegir en català

El CCI participó los pasados 19 y 20 de marzo en la Jornada técnica organizada por el Servicio Andaluz de Salud, IHE España y HL7 Spain que tenía por título “Interoperabilidad, la base para una atención integrada del paciente crónico”.
En el primer día de la jornada se realizaron las tres sesiones siguientes:

  • Reunión del comité técnico de HL7 Spain, en la cual se repasaron las principales novedades y avances des de la última reunión. Destacar que se ha empezado a trabajar en las derivaciones de pruebas diagnósticas, tanto a nivel funcional como de mensajería y informes asociados.
  • Presentación “Últimos avances en los estándares de documentación clínica”, orientada a acercar los estándares al perfil documentalista.
  • Sesión IHE centrada en la implantación de XDS en España.

En el segundo día se realizaron distintas intervenciones sobre la interoperabilidad entre sistemas y la integración de dispositivos, presentando diferentes estándares y sistemas que permiten garantizar la continuidad asistencial a distintos niveles. Se destacaron los nuevos retos que tienen los CIOs en cuanto a la interoperabilidad y a la atención de los pacientes crónicos, así como la importancia de la capacitación del ciudadano de manera que forme parte activa de su salud. Estas ponencias se complementaron explicando el papel de los perfiles IHE, de la norma CONTSYS (ISO/DIS 13940) y de los estándares de HL7, incluyendo los de ámbito semántico como CTS2 (Common Terminology Services Release 2). El evento finalizó con la compartición de experiencias y la presentación de distintas herramientas. Des de CCI-OFSTI se realizó una ponencia sobre servicios terminológicos avanzados:

En la presentación se explicó la necesidad de este tipo de servicios, así como las funcionalidades que pueden cubrir las herramientas que los ofrecen. También se presentó el estándar CTS2 que define, a nivel funcional, una interface estándar para el uso y la gestión de terminologías. Para acabar la intervención se resumió la participación del CCI-OFSTI en el grupo de servicios semánticos del proyecto europeo epSOS, en el cual se trabaja con el estándar CTS2.

CCI participa en la impartició del taller d’introducció a SNOMED CT i vocabularis clínics controlats

Leer en castellano

El Centre de Competències d’Integració va participar en la impartició del taller d’introducció a SNOMED CT i vocabularis clínics controlats, organitzat per HL7 Spain. La sessió es va realitzar a Barcelona, els passats dies 15 i 16 de novembre, i també va comptar amb una ponència de l’Oficina d’Estàndards i Interoperabilitat.

El taller va començar amb una presentació de tots els assistents i un repàs als estàndards d’HL7. Es va realitzar una introducció a la terminologia biomèdica i es van explicar els components bàsics i avançats de SNOMED CT. També es va presentar una guia de la gramàtica de l’estàndard, per construir expressions clíniques a través de la post-coordinació. Aquests coneixements es van compaginar amb exercicis pràctics i un cas d’ús basat en l’experiència real del Sistema Sanitari Català. Per acabar, es va introduir l’estàndard CDA R2 i es van presentar les estratègies i eines necessàries per desplegar SNOMED CT a una xarxa assistencial.

L’assistència al taller va ser de 9 alumnes, 4 d’ells de Navarra:

Es pot consultar més informació sobre la formació que el CCI ofereix a través del web: Formació i jornades.

Llegir en català

El Centre de Competències d’Integració participó en la impartición del taller de introducción a SNOMED CT y vocabularios clínicos controlados, organizado por HL7 Spain. La sesión se realizó en Barcelona, los días 15 y 16 de Noviembre y también contó con una ponencia de la Oficina d’Estàndards i Interoperabilitat.

El taller empezó con una presentación de todos los asistentes y un repaso a los estándares de HL7. Se realizó una introducción a la terminología biomédica y se explicaron los componentes básicos y avanzados de SNOMED CT. También se presentó una guía de la gramática del estándar, para construir expresiones clínicas a través de la post-coordinación. Estos conocimientos se compaginaron con ejercicios prácticos y un caso de uso basado en la experiencia real del Sistema Sanitario Catalán. Para acabar, se introdujo el estándar CDA R2 y se presentaron las estrategias y herramientas necesarias para desplegar SNOMED CT en una red asistencial.

La asistencia al taller fue de 9 alumnos, 4 de ellos de Navarra:

Se puede consultar más información sobre la formación que ofrece CCI a través de la web: Formación y jornadas.

“Workshop on semantic interoperability of ePrescription in the cross border setting” del projecte epSOS

Leer en castellano

Dins el marc del projecte europeu epSOS (European Patients – Smart open Services), els passats dies 11 i 12 d’octubre va tenir lloc el workshop sobre interoperabilitat semàntica en la prescripció electrònica a nivell europeu. La trobada es va realitzar al Statens Serum Institut, a Copenhaguen, Dinamarca. L’objectiu general de les sessions fou investigar com poden col·laborar les organitzacions internacionals de desenvolupament d’estàndards i epSOS, per ajudar a assolir la prescripció electrònica de medicaments de manera transparent i coherent, entre diferents països. Les fites concretes del taller que es van fixar van ser intentar acotar el problema a resoldre i identificar els propers passos a seguir. El workshop va comptar amb la participació d’alguns membres del grup de treball 3.D Technical Liaison d’epSOS, incloent l’OFSTI (Oficina d’Estàndards i Interoperabilitat), i amb representants de les principals organitzacions de desenvolupament d’estàndards a nivell europeu i internacional, com HL7 (Health Level 7), IHE (Integrating the Healthcare Enterprise), IHTSDO (International Health Terminology Standards Development Organisation), EMA (European Medicines Agency), etc. Les presentacions dels participants van oferir una visió general sobre els diferents estàndards i com poden ajudar a resoldre la prescripció electrònica a diferents nivells.

epSOS
El workshop va començar amb una sèrie de presentacions sobre el projecte epSOS. Es va explicar que el seu objectiu és desenvolupar un marc de treball i una infraestructura TIC, que habilitin l’accés segur a la informació clínica dels pacients a nivell europeu, sobretot a l’HCR (Història Clínica Resumida) i a la prescripció electrònica. L’arquitectura del projecte està orientada a serveis i s’ha dissenyat de manera que no interfereixi amb les infraestructures nacionals de cada país. La interoperabilitat entre els diferents països s’assoleix a través de NCPs (National Contact Points) que actuen de pont per la compartició. La implantació proposada es basa en perfils d’IHE, estàndards d’HL7 i diferents terminologies com SNOMED CT (Systematized Nomenclature of Medicine–Clinical Terms), ATC (Anatomical Therapeutic Chemical), UCUM (Unified Code for Units of Measure), etc. L’evolució del projecte passa per ampliar el framework semàntic, treballant en l’estàndard d’HL7 CTS2 (Common Terminology Services). Aquest marc de treball inclou la interoperabilitat semàntica en la prescripció electrònica. En aquest sentit, es van presentar alguns aspectes a tenir en compte (p.ex. cal determinar quina informació compartir) i introduir varies alternatives per representar els medicaments (ATC, INN International Nonproprietary Names, SNOMED CT, EMA, etc. ).

DG SANCO
Des del departament de Sanitat i Consum de la Comissió Europea (DG SANCO) es van presentar els objectius sanitaris que es persegueixen amb l’eHealth a nivell europeu: seguretat, continuïtat, reutilització d’informació per recerca i accés a expertesa (telemedicina), en el procés assistencial. També es va presentar l’anomenada eHealth network, una xarxa d’autoritats nacionals de més de 27 estats membres que esdevé el principal mecanisme de governança estratègica per la interoperabilitat, en l’àmbit de la salut, a nivell europeu. Aquesta xarxa avarca la gestió de diferents projectes europeus, entre ells epSOS.
La definició de directrius per la interoperabilitat de la prescripció electrònica és una de les prioritats de la Comissió Europea, de manera que es van llençar algunes preguntes relacionades amb la identificació i representació de medicaments.

Semantic Healthnet
Semantic Healthnet és una xarxa d’excel·lència en interoperabilitat semàntica patrocinada per la Comissió Europea i formada per més de 17 partners i 40 experts. La presentació d’aquesta entitat va oferir una visió general sobre com l’estandardització pot contribuir a comunicar la informació dels medicaments d’una manera més efectiva. Es van definir quatre nivells d’interoperabilitat semàntica: 0, on no hi ha interoperabilitat; 1, en el qual només hi ha interoperabilitat tècnica i sintàctica; 2, on la interoperabilitat semàntica és parcial (es separa en 2a i 2b en funció de si és unidireccional o bidireccional) i 3, on és total. Per a la prescripció electrònica, és essencial assolir el nivell 2a com a mínim, de manera que es pugui compartir el significat. Per assolir aquest objectiu, cal comptar amb un model d’informació comú (p.ex. HL7 V3 Rx), amb tipus de dades estàndard (harmonització a ISO 21090:2011, International Organization for Standardization), terminologies (com SNOMED CT o les d’IDMP, Identification of Medicinal Products, d’ISO) i una especificació per l’intercanvi d’informació (com SOA, domini de farmàcia d’HL7 V3, etc.). A la presentació s’apuntava que totes aquestes necessitats es poden cobrir amb diferents estàndards que es complementin.

IHE
Des d’IHE s’ha treballat el domini de farmàcia diferenciant entre les farmàcies hospitalàries i les ordinàries, generant 5 perfils i 1 whitepaper de treball. La proposta que es realitza es basa en mantenir un model semàntic de dades consistent i en usar estàndards existents (HL7 V2.5 de missatgeria en l’àmbit de les farmàcies hospitalàries i HL7 V3 CDA, Clinical Document Architecture, per documents clínics, en el de les ordinàries). L’aproximació inclou un marc de treball tècnic que descriu els detalls de cada integració i el contingut dels perfils. Els perfils d’IHE assenyalen l’ús de vocabularis estàndard, però no especifiquen quina terminologia utilitzar pels diferents subdominis. Els perfils involucrats són, per les farmàcies hospitalàries: HMW (Hospital Medication Workflow) i per les ordinàries: CMPD (Community Medication Prescription and Dispense), PRE (Content Profile: Medication Prescription), PADV (Content Profile: Pharmaceutical Advice) i DIS (Content Profile: Medication Dispense).

HL7
Des d’HL7 es mantenen, actualitzen i distribueixen diferents estàndards de missatgeria (HL7 V2.x) i d’estructuració de documents clínics (HL7 V3 CDA), així com de serveis terminològics (CTS). La versió 3 de l’estàndard també inclou SPL (Structured Product Labeling), CMETS (Common Product Model) i RPS (Regulated Product Submission). El domini de farmàcia inclou missatges i document estructurats, a més d’anàlisis de casos d’ús concrets. La presentació realitzada va detallar l’estàndard CDA, que usant fitxers XML i un model d’informació de referència, permet formalitzar l’estructura de document clínics i el seu contingut, per assolir l’intercanvi coherent entre sistemes. Els fitxers CDA permeten usar vocabularis controlats per codificar la informació més rellevant dels documents clínics. En aquest sentit, existeix un acord de col·laboració entre IHTSDO i HL7 per tal de crear sinèrgies entre ambdós estàndards. A la sessió també es va explicar més a fons el CTS, que ja compta amb una versió 2 en fase beta.

IHTSDO
IHTSDO és una organització internacional sense ànim de lucre que compta amb uns 19 estats membres. L’entitat té la propietat de l’estàndard semàntic SNOMED CT i s’encarrega de distribuir-lo i actualitzar-lo. SNOMED CT és una terminologia dissenyada per representar la informació clínica als sistemes d’informació, de manera que aquesta es pugui utilitzar i compartir sense que perdi el seu significat. L’estàndard també afegeix un context a aquestes dades, per tal que es puguin interpretar correctament. SNOMED CT és multillenguatge i conté diferents dominis de l’àmbit sanitari. IHTSDO col·labora amb altres organitzacions per tal d’harmonitzar els diferents estàndards. A la presentació també es va explicar el model de dades pels productes farmacèutics i les substàncies (per principis actius) que inclou SNOMED CT on, a través de les relacions entre conceptes, és possible identificar de manera única cada element. A SNOMED CT, un producte farmacèutic està relacionat amb el seu principi actiu, amb la forma farmacèutica, la potència, etc. i proposa usar UCUM com a estàndard per les unitats de mesura.

EMA
EMA està desenvolupament una BBDD (Base de Dades) de medicaments basant-se en el marc legal europeu. La implementació del projecte s’ha dividit en les quatre fases següents: notificació del format d’enviament per tal que les entitats autoritzades enviïn els medicaments; recepció, en format electrònic dels productes farmacèutics; processament i validació de la informació rebuda i implementació d’estàndards IDMP d’ISO. Aquesta darrera fase encara no s’ha completat. La implementació inicial s’ha orientat a garantir el compliment de la legislació vigent i de la seguretat del pacient. La BBDD conté la informació relacionada de cada medicament rebut (nom, excipients, forma farmacèutica, dosi, etc.), així com el codi ATC (que no es fa servir per codificar, sinó per classificar en funció dels usos terapèutics) i les indicacions terapèutiques codificades en MedDRA. Els elements de la BBDD són multillenguatge i permetran donar suport a la representació de principis actius i al mapeig de productes farmacèutics. S’està col·laborant amb altres organitzacions per incloure estàndards a la BBDD com UCUM, per les unitats de mesura, o EDQM (European Directorate for the Quality of Medicines), per les vies d’administració.

Conclusions
Amb les presentacions realitzades es va poder comprovar que hi ha diversos estàndards que poden ajudar a resoldre la prescripció electrònica a nivell europeu. Cadascuna d’aquestes normes pot aportar solucions a diferents nivells, ja que la majoria es complementen. La implantació d’estàndards pot resultar força complexa, de manera que caldrà dissenyar un marc de treball prou ambiciós com per donar resposta a les necessitats reals, però sense perdre de vista les capacitats actuals dels sistemes nacionals de salut. L’objectiu del workshop no era decidir quins estàndards utilitzar, però sembla que hi ha força consens en seguir els perfils d’IHE i usar estàndards HL7. En quant a la terminologia, es va considerar que cal una terminologia de referència a nivell europeu, així com un model de referència i l’ús d’estàndards per assegurar la precisió de la informació. Un altre punt a resoldre és la definició de quina informació cal transmetre, per tal que la prescripció sigui segura pel ciutadà.

Per acabar, només destacar una frase de la presentació de Semantic Healthnet: “Semantic interoperability doesn’t happen – it has to be designed and built and governanced”.

Llegir en català

Dentro del marco del proyecto epSOS (European Patients – Smart open Services), los días 11 y 12 de Octubre tuvo lugar el workshop sobre interoperabilidad semántica en la prescripción electrónica a nivel europeo. El taller se realizó en el Statens Serum Institut, en Copenhague, Dinamarca. El objetivo general de las sesiones fue investigar cómo pueden colaborar las organizaciones internacionales de desarrollo de estándares y epSOS, para ayudar a alcanzar la prescripción electrónica de medicamentos de forma transparente y coherente, entre distintos países. Los propósitos concretos que se fijaron para el taller, fueron intentar delimitar el problema a resolver e identificar los siguientes pasos a seguir. El workshop contó con la participación de algunos miembros del grupo de trabajo 3.D Technical Liaison de epSOS, incluyendo la OFSTI (Oficina d’Estàndards i Interoperabilitat), y con representantes de las principales organizaciones de desarrollo de estándares a nivel europeo e internacional, como HL7 (Health Level 7), IHE (Integrating the Healthcare Enterprise), IHTSDO (International Health Terminology Standards Development Organisation), EMA (European Medicines Agency), etc. Las presentaciones de los participantes ofrecieron una visión general sobre los diversos estándares y cómo pueden ayudar a resolver la prescripción electrónica a distintos niveles.

epSOS
El workshop comenzó con una serie de presentaciones sobre el proyecto epSOS. Se explicó que su objetivo es desarrollar un marco de trabajo y una infraestructura TIC, que habiliten el acceso seguro a la información clínica de los pacientes a nivel europeo, sobre todo a la HCR (Historia Clínica Resumida) y a la prescripción electrónica. La arquitectura del proyecto está orientada a servicios y se ha diseñado de manera que no interfiera con las infraestructuras nacionales de cada país. La interoperabilidad entre los distintos países se alcanza a través de NCPs (National Contact Points), que actúan de puente para la compartición. La implantación propuesta se basa en perfiles de IHE, estándares de HL7 y distintas terminologías como SNOMED CT (Systematized Nomenclature of Medicine–Clinical Terms), ATC (Anatomical Therapeutic Chemical), UCUM (Unified Code for Units of Measure), etc. La evolución del proyecto pasa por ampliar el framework semántico, trabajando en el estándar de HL7 CTS2 (Common Terminology Services). Este marco de trabajo incluye la interoperabilidad semántica en la prescripción electrónica. En este sentido, se presentaron algunos aspectos a tener en cuenta (p.ej. determinar qué información se va a compartir) e introdujeron varias alternativas para representar medicamentos (ATC, INN International Nonproprietary Names, SNOMED CT, EMA, etc.).

DG SANCO
Des del departamento de Sanidad y Consumo de la Comisión Europea (DG SANCO), se presentaron los objetivos sanitarios que se persiguen con la eHealth a nivel europeo: seguridad, continuidad, reutilización de información para la investigación y el acceso a expertos (telemedicina), en el proceso asistencial. También se presentó la denominada eHealth network, una red de autoridades nacionales con más de 27 estados miembro que conforma el principal mecanismo de gobernanza estratégica para la interoperabilidad, en el ámbito de la salud, a nivel europeo. Esta red abarca la gestión de diferentes proyectos europeos, entre ellos epSOS.
La definición de directrices para la interoperabilidad de la prescripción electrónica es una de las prioridades de la Comisión Europea, de manera que lanzaron varias preguntas relacionadas con la identificación y la representación de medicamentos.

Semantic Healthnet
Semantic Healthnet es una red de excelencia en interoperabilidad semántica patrocinada por la Comisión Europea y formada por más de 17 partners y 40 expertos. La presentación de esta entidad ofreció una visión general sobre cómo la estandarización puede contribuir en comunicar los medicamentos de una manera más efectiva. Se definieron cuatro niveles de interoperabilidad semántica: 0, en el que no hay interoperabilidad; 1, en el que solo hay interoperabilidad técnica y sintáctica; 2, donde la interoperabilidad semántica es parcial (se separa entre 2a y 2b en función de si es unidireccional o bidireccional) y 3, donde es total. Para la prescripción electrónica es esencial alcanzar el nivel 2a, como mínimo, de manera que se pueda transmitir el significado. Para lograr este propósito, es necesario contar con un modelo de información común (p.ej. HL7 V3 Rx), con tipos de datos estándar (armonización en ISO 21090:2011, International Organization for Standardization), terminologías (como SNOMED CT o les de IDMP, Identification of Medicinal Products, de ISO) y una especificación para el intercambio de información (como SOA, dominio de farmacia de HL7 V3, etc.). En la presentación se apuntaba que todas estas necesidades se pueden cubrir con diferentes estándares que se complementen.

IHE
Des de IHE se ha trabajado el dominio de farmacia diferenciando entre las farmacias hospitalarias y las ordinarias, generando 5 perfiles y 1 whitepaper de trabajo. La propuesta que se realiza se basa en mantener un modelo semántico de datos consistente y en usar estándares existentes (HL7 V2.5 de mensajería en el ámbito de las farmacias hospitalarias y HL7 V3 CDA, Clinical Document Architecture, para documentos clínicos, en el de las ordinarias). La aproximación incluye un marco de trabajo técnico que describe los detalles de cada integración y el contenido de los perfiles. Los perfiles de IHE señalan el uso de vocabularios estándar pero no indican qué terminología utilizar para los diferentes subdominios. Los perfiles involucrados son, para las farmacias hospitalarias: HMW (Hospital Medication Workflow) y para las ordinarias: CMPD (Community Medication Prescription and Dispense), PRE (Content Profile: Medication Prescription), PADV (Content Profile: Pharmaceutical Advice) y DIS (Content Profile: Medication Dispense).

HL7
Des de HL7 se mantienen, actualizan y distribuyen diferentes estándares de mensajería (HL7 V2.x) y de estructuración de documentos clínicos (HL7 V3 CDA), así como de servicios terminológicos (CTS). La versión 3 del estándar también incluye SPL (Structured Product Labeling), CMETS (Common Product Model) y RPS (Regulated Product Submission), a demás del análisis de casos de uso concretos. La presentación detalló el estándar CDA, que usando archivos XML y un modelo de información de referencia, permite formalizar la estructura de documentos clínicos y su contenido, para alcanzar el intercambio coherente entre sistemas. Los archivos CDA permiten usar vocabularios controlados para codificar la información más relevante de los documentos clínicos. En este sentido, existe un acuerdo de colaboración entre IHTSDO y HL7 para crear sinergias entre los dos estándares. En la sesión también se explicó más a fondo el CTS, que ya cuenta con una versión 2 en fase beta.

IHTSDO
IHTSDO es una organización internacional sin ánimo de lucro que cuenta con unos 19 estados miembro. La entidad tiene la propiedad del estándar semántico SNOMED CT y se encarga de distribuirlo y actualizarlo. SNOMED CT es una terminología diseñada para representar la información clínica en los sistemas de información, de manera que esta se puede utilizar y compartir sin que se pierda su significado. El estándar también añade contexto a estos datos, para que se puedan interpretar correctamente. SNOMED CT es multilenguaje y contiene distintos dominios del ámbito sanitario. IHTSDO colabora con otras organizaciones para armonizar los diferentes estándares. En la presentación también se explicó el modelo de datos para los productos farmacéuticos y las sustancias (para principios activos) que incluye SNOMED CT donde, a través de las relaciones entre conceptos, es posible identificar de manera única cada elemento. En SNOMED CT, un producto farmacéutico está relacionado con su principio activo, con la forma farmacéutica, la potencia, etc. y propone UCUM como estándar para las unidades de medida.

EMA
EMA está desarrollando una BBDD (Base de Datos) de medicamentos basándose en el marco legal europeo. La implementación del proyecto se ha divido en las cuatro fases siguientes: notificación del formato de envío para que las entidades autorizadas manden los medicamentos; recepción en formato electrónico de los productos farmacéuticos; procesamiento y validación de la información recibida e implementación de estándares IDMP de ISO. Esta última fase aun no se ha completado. La implementación inicial se ha orientado a asegurar el cumplimiento de la legislación vigente y de la seguridad del paciente. La BBDD contiene la información relacionada de cada medicamento recibido (nombre, excipientes, forma farmacéutica, etc.), así como el código ATC (que no se usa para codificar sino para clasificar en función de los usos terapéuticos) y las indicaciones terapéuticas codificadas en MedDRA. Los elementos de la BBDD son multilenguaje y permitirán ofrecer soporte a la representación de principios activos y al mapeo de productos farmacéuticos. Se está colaborando con otras organizaciones para incluir estándares a la BBDD como UCUM para las unidades de medida o EDQM (European Directorate for the Quality of Medicines) para las vías de administración.

Conclusiones
Con las presentaciones realizadas se pudo comprobar que existen diversos estándares que pueden ayudar a resolver la prescripción electrónica a nivel europeo. Cada una de estas normas aporta soluciones a distintos niveles, ya que la mayoría se complementan. La implantación de estándares puede resultar bastante compleja, de manera que será necesario diseñar un marco de trabajo lo bastante ambicioso como para responder a las necesidades reales, pero sin perder de vista las capacidades actuales de los sistemas nacionales de salud. El objetivo del workshop no era decidir qué estándares utilizar, pero parece que hay bastante consenso en seguir los perfiles de IHE y usar estándares de HL7. En cuanto a la terminología, se consideró que es necesario contar con una terminología de referencia a nivel europeo, así como un modelo de referencia y el uso de estándares para garantizar la precisión de la información. Otro punto a resolver es la definición de qué información transmitir, para que la prescripción sea segura para el ciudadano.

Para acabar, destacar una frase de la presentación de Semantic Healthnet: “Semantic interoperability doesn’t happen – it has to be designed and built and governanced”.

HAPI (HL7 application programming interface)

Leer en castellano 

HAPI (HL7 application programming interface) és una API de codi obert per al tractament de missatges HL7 2.X amb Java. El projecte no està afiliat a la organització de HL7 però en compleix les especificacions. Va ser iniciat per la University Health Network.

Les principals funcions de HAPI són les següents:

-Extreure la informació dels camps del missatge d’una manera més senzilla, mitjançant un conjunt de  classes que permeten convertir els missatges HL7 en objectes Java que contindran la informació.

//Es recupera  el missatge com un objecte

hapiMsg = p.parse(msg);

//Es realitza un “downcasting” al tipus de missatge

ADT_A01 adtMsg = (ADT_A01)hapiMsg;

//Es recupera un camp del missatge

PN patientName = adtMsg.getPID().getPatientName();

-Crear missatges HL7 a partir d’ objectes Java del tipus del missatge i assignar els valors desitjats als atributs del objecte que es corresponen amb cadascun dels camps del missatge HL7. Els missatges es poden crear tant en ER7 com en XML.

//Es crea un nou missatge ADT_A01

ADT_A01 adt = new ADT_A01();

//Es recupera el segment PID

PID pid = adt.getPID();

//S’omplen tres camps del segment PID

pid.getPatientName(0).getFamilyName().getSurname().setValue("Doe");

pid.getPatientName(0).getGivenName().setValue("John");

pid.getPatientIdentifierList(0).getID().setValue("123456");

-Rebre missatges, permet crear un servidor que rebi un o diversos tipus de missatges HL7.Cadascun dels tipus de missatges poden  tenir assignat un tractament diferent.

-Enviar missatges a servidors receptors de missatges HL7.

-Validar missatges, quan es realitza la conversió del missatge a un objecte Java es possible dur a terme també una validació del format del missatge per verificar que es compleixen les especificacions establertes per HL7. Per a una validació més avançada es pot validar contra perfils de conformitat que són restriccions l’estàndard HL7.Alhora de realitzar la validació es pot programar manualment per que corregeixi certs errors en els missatges.

-Llegir un o més missatges Hl7 emmagatzemats en un fitxer de text.

Mirth Connect, la plataforma d’integració open source, utilitza la llibreria HAPI com a base per tractar tots els missatges HL7 dins la plataforma. Aquesta API permet tractar molt més fàcilment als missatges alhora de construir-los, com per exemple en el cas dels segments de repetició com els OBX, els quals es poden crear com a objectes mitjançant la API, i assignar-los a diferents parts del missatge.

HAPI TestPanel

HAPI TestPanel és una eina amb interfície gràfica que actualment es troba en fase “alpha”. Permet principalment editar, enviar,rebre i validar missatges HL7.

Aquesta eina permet realitzar altres tasques com creació de perfils de Grup que són conjunts d’un o més perfils de conformitat, creació de taules de validació o comparació semàntica de dos missatges HL7 per tal de validar si el seu contingut és el mateix encara que l’estructura sigui diferent, ja que únicament es compara el contingut dels camps. Es pot veure un exemple a la següent imatge.

HAPI ens proporciona doncs l’accés a missatges HL7 a nivell d’objecte, amb la qual podrem crear tot tipus d’aplicacions per generar missatges, parsejar-los, transformar-los i validar-los sota l’estàndard HL7.

Llegir en català 

HAPI (HL7 application programming interface) es una API de código abierto para el tratamiento de mensajes HL7 2.X con Java. El proyecto no está afiliado a la organización de HL7 pero cumple las especificaciones. Fue iniciado por la University Health Network.

Las principales funciones de HAPI son las siguientes:

-Extraer la información de los campos del mensaje de una manera más sencilla, mediante un conjunto de clases que permiten convertir los mensajes HL7 en objetos Java que contendrán la información.

//Se recupera el mensaje como un objeto

hapiMsg = p.parse(msg);

//Se realiza un “downcasting” al tipo de mensaje

ADT_A01 adtMsg = (ADT_A01)hapiMsg;

//Se obtiene un campo del mensaje

PN patientName = adtMsg.getPID().getPatientName();

-Crear mensajes HL7 a partir de objetos Java del tipo del mensaje y asignar los valores deseados a los atributos del objeto que se corresponden con cada uno de los campos del mensaje HL7. Los mensajes se pueden crear tanto en ER7 como en XML.

//Se crea un nuevo mensaje ADT_A01

ADT_A01 adt = new ADT_A01();

//Se recupera el segmento PID

PID pid = adt.getPID();

//Se rellenan 3 campos del segmento PID

pid.getPatientName(0).getFamilyName().getSurname().setValue("Doe");

pid.getPatientName(0).getGivenName().setValue("John");

pid.getPatientIdentifierList(0).getID().setValue("123456");

-Recibir mensajes, permite crear un servidor que reciba uno o varios tipos de mensajes HL7.Cada uno de los tipos de mensajes pueden tener asignado un tratamiento diferente.

-Enviar mensajes a servidores receptores de mensajes HL7.

-Validar mensajes, cuando se realiza la conversión del mensaje a un objeto Java es posible llevar a cabo también una validación del formato del mensaje para verificar que se cumplen las especificaciones establecidas por HL7. Para una validación más avanzada se puede validar contra perfiles de conformidad que son restricciones del estándar HL7.La validación se puede programar manualmente por que corrija ciertos errores en los mensajes.

Leer uno o más mensajes Hl7 almacenados en un fichero de texto.

Mirth Connect, plataforma de integración open source, utiliza la librería HAPI como base para tratar todos los mensajes HL7 dentro de la plataforma. Esta API permite tratar mucho más fácilmente los mensajes en el momento de construirlos, como por ejemplo en el caso de los segmentos de repetición OBX, los cuales se pueden crear como objetos mediante la API, y asignarlos a diferentes partes del mensaje.

HAPI TestPanel

HAPI TestPanel es una herramienta con interfaz gráfica que actualmente se encuentra en fase “alpha”. Permite principalmente editar, enviar,recibir y validar mensajes HL7.

Esta herramienta permite realizar otras tareas como creación de perfiles de Grupo que son conjuntos de uno o más perfiles de conformidad, creación de tablas de validación o comparación semántica de dos mensajes HL7 para validar si su contenido es el mismo aunque la estructura sea diferente, puesto que únicamente se compara el contenido de los campos. Se puede ver un ejemplo a la siguiente imagen.

HAPI nos proporciona pues el acceso a mensajes HL7 a nivel de objeto, con la cual podremos crear todo tipo de aplicaciones para generar mensajes, parsear-los, transformarlos y validarlos bajo el estandard HL7.

Formació Entorns d’Interoperabilitat

Leer en castellano 

El CCI-TCM (Centre de Competències d’Integració de la fundació Tecnocampus Mataró-Maresme) ofereix serveis de formació en l’àmbit dels Entorns d’Interoperabilitat i el de la Terminologia. Aquesta entrada vol presentar el curs d’integració de dispositius, referent a l’àmbit dels entorns d’interoperabilitat, que es proposa des del CCI i TicSalut.

Descripció del Curs

El curs d’integració de dispositius té com a objectiu formar especialistes en dispositius mèdics, amb coneixements en estàndards d’informació mèdica (HL7) i en els marcs d’interoperabilitat existents, tot fent ús d’una de les plataformes d’integració orientades a sanitat més utilitzades: Mirth Connect. Per això, el curs va dirigit a responsables d’integració i a tècnics informàtics, que puguin entendre i aprendre a desenvolupar aplicacions i solucions d’integració sota  la plataforma d’integració Mirth.

A continuació podeu veure el tríptic del curs:



Com es pot veure en el temari, el curs es divideix en diversos apartats:

Primer de tot, una introducció explicant la base dels estàndards i la interoperabilitat, veient la seva aplicació en diferents àmbits i en els sistemes d’informació y dispositius, que s’expliquen al següent apartat. A continuació, es fa referència als marcs d’interoperabilitat d’IHE i Continua Alliance, que defineixen les bones pràctiques d’utilització dels estàndards.

El curs continua amb una segona part més tècnica, on s’expliquen primer de tot les plataformes d’integració, basades en l’arquitectura ESB (en concret Mirth Connect). Finalment, l’últim apartat consisteix en desenvolupar dos casos d’ús per integrar un espiròmetre i un electrocardiògraf.

Edicions del curs

Als passats 10 i 11 de Maig es va dur a terme la primera edició del curs, amb 20 participants que van omplir totes les places, i amb uns resultats satisfactoris. En el curs, els alumnes van poder aprendre les bases dels estàndards en l’àmbit de sanitat, i es van poder enfrontar als problemes reals d’una integració, treballant amb la plataforma Mirth Connect. Els assistents alhora, tenen la possibilitat de posar en comú els seus coneixements en l’àmbit, i proposar problemes amb els que es troben dia a dia.

La segona edició es durà a terme aquest Setembre del 2012, dies 26 i 27, la qual ja esta tenint una bona acollida degut a l’interès mostrat per part de la gent que es comença a inscriure. Les inscripcions estan obertes, amb places limitades, i es poden realitzar al següent enllaç:

Inscripció al Curs d’Integració de Dispositius 2a Edició

Llegir en català 

El CCI-TCM (Centre de Competències d’Integració de la fundació Tecnocampus Mataró-Maresme) ofrece servicios de formación en el ámbito de los Entornos de Interoperabilidad y el de la Terminología. Esta entrada quiere presentar el curso de integración de dispositivos, referente al ámbito de los entornos de interoperabilidad, que se propone des del CCI y TicSalut.

Descripción del Curso

El curso de integración de dispositivos tiene como objetivo formar especialistas en dispositivos médicos, con conocimientos en estándares de información médica (HL7) y en los marcos de Interoperabilidad existentes, haciendo uso de una de las plataformas de integración orientadas a salud más utilizadas: Mirth Connect. Por eso, el curso va dirigido a responsables de integración y técnicos informáticos, que puedan entender y aprender a desarrollar aplicaciones y soluciones de integración bajo la plataforma de integración Mirth.

A continuación podéis ver el tríptico del curso:



Com se puede ver en el temario, el curso se divide en varios apartados:

Primero de todo, una introducción explicando la base de los estándares y la interoperabilidad, viendo su aplicación en diferentes ámbitos y en los sistemas de información y dispositivos, que se explican en el siguiente apartado. A continuación, se hace referencia a los marcos de interoperabilidad de IHE y Continua Alliance, que definen las buenas practicas de utilización de los estándares.

El curso continua con una segunda parte más técnica, donde se explican primero de todo las plataformas de integración, basadas en la arquitectura ESB (en concreto Mirth Connect). Finalmente, el último apartado consiste en desarrollar dos casos de uso para integrar un espirómetro y un electrocardiógrafo.

Ediciones del curso

Los pasados 10 y 11 de Mayo se llevo a cabo la primera edición del curso, con 20 participantes que llenaron todas las plazas, y con unos resultados satisfactorios. En el curso, los alumnos pudieron aprender las bases de los estándares en el ámbito sanitario, y pudieron enfrentarse a los problemas reales de una integración, trabajando con la plataforma Mirth Connect. Los asistentes a la vez, tuvieron la posibilidad de poner en común sus conocimientos en el ámbito, y proponer problemas con los que se encuentran dia a dia.

La segunda edición se llevará a cabo éste Septiembre del 2012, días 26 y 27, la cuál ya esta teniendo una buena aceptación debido al interés mostrado por parte de la gente que empieza a escribirse. Las inscripciones estan abiertas, con plazas limitadas, y se pueden realizar al siguiente enlace:

Inscripción al Curso de Integración de Dispositivos 2a Edición

Formació SNOMED CT

Leer en castellano

El CCI-TCM (Centre de Competències d’Integració de la fundació Tecnocampus Mataró-Maresme) ofereix serveis de formació en l’àmbit dels Entorns d’Interoperabilitat i el de la Terminologia. Aquesta entrada té per objectiu presentar i explicar en detall les diferents modalitats i tipologies de formació relacionada amb SNOMED CT:

Tallers d’interoperabilitat semàntica al TCM
Aquesta mena de tallers s’organitzen des del CCI-TCM i es realitzen al Tecnocampus Mataró-Maresme, amb la col·laboració de la fundació TicSalut. S’han realitzat dues edicions i la tercera, la inscripció de la qual ja està oberta, està programada pels dies 3 i 4 d’octubre del 2012. La informació sobre aquesta 3a edició es pot consultar a l’enllaç següent: tríptic. A aquesta mena de formació s’expliquen els diferents tipus de llenguatges i vocabularis controlats, es fa una introducció a SNOMED CT i s’aprofundeix en els mecanismes de conjunts de referències creuades (mapejos), subconjunts i extensions. També s’ofereix una visió general del procés de gestió de SNOMED CT a Catalunya i en línia amb el MSSSI (Ministerio de Sanidad, Servicios Sociales e Igualdad) i epSOS (projecte europeu de compartició d’informació clínica), i es fa un repàs a les eines existents que permeten treballar amb la terminologia. Les explicacions teòriques d’aquests conceptes es combinen amb exercicis pràctics de navegació i codificació amb SNOMED CT i de creació de components. El taller d’enguany compta amb varies novetats:

  • Presentació dels subconjunts de SNOMED CT creats per l’HC3 i pautes d’implantació i ús.
  • Cas pràctic de creació de components basat en l’experiència real del Sistema Sanitari Català.
  • Presentació i pràctica del navegador SNOB a més a més de CliniClue Xplore.
  • Cas real de navegació i codificació a partir de l’experiència real de l’Hospital Clínic de Barcelona.

Tallers de SNOMED CT amb HL7
El CCI-TCM ha col·laborat amb HL7 en la impartició de varis tallers sobre SNOMED CT i vocabularis clínics controlats, a diferents Comunitats Autònomes. Aquestes modalitats solen ser més concentrades que els tallers d’interoperabilitat semàntica i inclouen una part d’HL7 i CDA que permet obtenir una visió general de com transmetre i compartir la informació codificada en SNOMED CT.
El dia 18 de juny va començar la primera edició online d’aquesta mena de cursos amb el taller virtual d’introducció a SNOMED CT. L’edició e-learning, programada en 5 setmanes, ha permès augmentar el nivell de detall amb el qual es tracta cada part de SNOMED CT i maximitzar la part pràctica dels tallers. Cada setmana es lliura una unitat teòrica als alumnes, sobre la qual han de realitzar un qüestionari i una pràctica. La informació sobre aquesta primera edició online es pot consultar al següent enllaç: tríptic.

Jornades tècniques i altres accions de difusió
El CCI-TCM també ha participat en les dues edicions de la jornada tècnica de SNOMED CT que s’ha organitzat des de la fundació Doctor Robert, UAB. L’esdeveniment d’enguany va tenir molt d’èxit i va oferir una visió general de l’evolució de SNOMED CT al Sistema Sanitari Català orientada a experts en documentació clínica. El grup també ha participat en altres congressos i jornades que tenen per objectiu potenciar l’ús de les TIC al sector salut, com InforSalut, InforMed, FòrumCis, la segona reunió del foro de Interoperabilidad, etc. amb ponències sobre SNOMED CT.

La informació sobre els cursos, tallers, congressos, etc. en els quals està involucrat el CCI-TCM es pot trobar al web del grup:

La propera entrada tractarà sobre la formació que ofereix el CCI-TCM en l’àmbit dels EI (Entorns d’Interoperabilitat). Avançar que ja està oberta la inscripció per la segona edició del taller d’integració de dispositius mèdics amb Mirth Connect, els dies 26 i 27 de setembre del 2012. La informació relacionada i el formulari d’inscripció es poden consultar a l’enllaç que es presenta a continuació: tríptic.

Llegir en català

CCI-TCM (Centre de Competències d’Integració de la fundación Tecnocampus Mataró-Maresme) ofrece servicios de formación en el ámbito de los Entornos de Interoperabilidad y el de la Terminología. Esta entrada tiene por objetivo presentar y explicar en detalle las diferentes modalidades y tipologías de formación relacionada con SNOMED CT:

Talleres de interoperabilidad semántica en TCM
Este tipo de talleres se organizan des del CCI-TCM y se llevan a cabo en el Tecnocampus Mataró-Maresme, con la colaboración de la fundación TicSalut. Se han realizado dos ediciones y la tercera, cuya inscripción ya está abierta, está programada para los días 3 y 4 de Octubre del 2012. La información sobre esta 3a edición se puede consultar en el enlace siguiente: tríptico. En este tipo de formación se explican los diferentes tipos de lenguajes y de vocabularios controlados, se hace una introducción a SNOMED CT y se profundiza en los mecanismos de conjuntos de referencias cruzadas (mapeos), subconjuntos y extensiones. También se ofrece una visión general del proceso de gestión de SNOMED CT en Catalunya y en línea con el MSSSI (Ministerio de Sanidad, Servicios Sociales e Igualdad) y epSOS (proyecto europeo de compartición de información clínica), y se hace un repaso de las herramientas existentes que permiten trabajar con la terminología. Las explicaciones teóricas de estos conceptos se combinan con ejercicios prácticos de navegación y codificación con SNOMED CT, y de creación de componentes. El taller de este año cuenta con diversas novedades:

  • Presentación de los subconjuntos de SNOMED CT creados para HC3 y pautas de implantación y uso.
  • Caso práctico de creación de componentes basado en la experiencia real del  Sistema Sanitario Catalán.
  • Presentación y práctica del navegador SNOB, a demás de CliniClue Xplore.
  • Caso real de navegación y codificación a partir de la experiencia real del Hospital Clínic de Barcelona.

Talleres de SNOMED CT con HL7
CCI-TCM ha colaborado con HL7 en la impartición de varios talleres sobre SNOMED CT y vocabularios clínicos controlados, en diferentes Comunidades Autónomas. Estas modalidades suelen ser más concentradas que los talleres de interoperabilidad semántica y incluyen una parte de HL7 y CDA, que permite obtener una visión general sobre cómo transmitir y compartir la información codificada con SNOMED CT.
El día 18 de Junio empezó la primera edición online de este tipo de cursos, con el taller virtual de introducción a SNOMED CT. La edición e-learning, programada en 5 semanas, ha permitido aumentar el nivel de detalle con el que se trata cada parte de SNOMED CT y maximizar la parte práctica. Cada semana se entrega a los alumnos una unidad teórica, sobre la cual tienen que realizar un cuestionario y una práctica. La información sobre esta primera edición online se puede consultar en el siguiente enlace: tríptico.

Jornadas técnicas y otras acciones de difusión
CCI-TCM también ha participado en las dos ediciones de la jornada técnica de SNOMED CT, organizada des de la fundación Doctor Robert, UAB. El evento de este año ha tenido un gran éxito y ofreció una visión general de la evolución de SNOMED CT en el Sistema Sanitario Catalán orientada a expertos en documentación clínica. El grupo también ha participado en otros congresos y jornadas que tienen por objetivo potenciar el uso de la TIC en el sector salid, como InforSalut, InforMed, FòrumCis, la segunda reunión del foro de Interoperabilidad, etc. con ponencias sobre SNOMED CT.

La información sobre los cursos, talleres, congresos, etc. en los que está involucrado el CCI-TCM se pueden encontrar en la web del grupo:

La siguiente entrada tratará sobre la formación que ofrece CCI-TCM en el ámbito de los EI (Entornos de Interoperabilidad). Adelantar que ya está abierta la inscripción para la segunda edición del taller de integración de dispositivos médicos con Mirth Connect, los días 26 y 27 de Setiembre del 2012. La información relacionada y el formulario de inscripción se pueden consultar en el enlace que se presenta a continuación: tríptico.

Foro de Interoperabilidad, SNOMED CT

Leer en castellano

Els passats dies 16 i 17 de maig va tenir lloc la segona reunió del Foro de Interoperabilidad a La Granja San Ildefonso, Segovia. El CCI-TCM va participar a la segona sessió de l’esdeveniment “terminologia (SNOMED CT)“, amb una presentació sobre la metodologia de creació de subconjunts.

El Foro de Interoperabilidad és l’evolució del de Normalización, i a l’edició d’aquest any es va presentar l’estat de l’art de la interoperabilitat, tractar la terminologia i aprofundir en la interoperabilitat organitzativa. A través de les diferents sessions es va mostrar tant el punt de vista de la indústria, com el de l’administració pública. Destacar les presentacions sobre els avenços, en termes d’integració, digitalització i interoperabilitat de SACyL, el Sistema de Salut de Castilla y León.

La comunicació presentada per part del CCI-TCM es mostra a continuació:

Al recurs es va fer una breu introducció al vocabulari controlat i es va explicar el procés de creació de subconjunts que s’ha definit des del CCI-TCM i l’OFSTI (Oficina d’Estàndards i Interoperabilitat) de la fundació TicSalut. També es van presentar els subconjunts que s’han treballat (vacunes, al·lèrgies, prestacions quirúrgiques i anatomia patològica), a la definició dels quals s’ha aplicat la metodologia de creació de subconjunts.

Al torn de preguntes i debat de la sessió sobre SNOMED CT van sorgir dos temes molt interessants:

  • Eines que permetin explorar, explotar i gestionar l’estàndard.
  • Ús de SNOMED CT.

 

STERMCAT

Es va preguntar si a Catalunya s’està utilitzant alguna eina per gestionar SNOMED CT o centralitzar els recursos semàntics. Per respondre la qüestió es va explicar que des de l’OFSTI s’ofereixen diferents serveis, més que eines concretes, recollits sota el nom de STERMCAT. No es limita el desplegament de SNOMED CT a l’ús d’una sola eina, sinó que s’enfoca a serveis terminològics que es poden oferir per part de programari diferent. Actualment el web de l’OFSTI té un apartat dedicat exclusivament a terminologia, on es publiquen manuals, guies, notícies, etc. Destacar el cens de catàlegs que conté una fitxa amb la informació bàsica de més de 60 catàlegs. Amb aquest registre, tothom pot consultar si existeix un vocabulari estàndard que cobreixi les seves necessitats. L’apartat de terminologia també conté l’àrea de descàrrega de SNOMED CT, a través de la qual es pot obtenir la versió INT i l’ES-ARG de la terminologia, així com l’extensió catalana amb els subconjunts creats.

 

Ús de SNOMED CT

Una altra de les preguntes que es van realitzar fou què era necessari per tal que els subconjunts creats no caiguessin en desús. En aquest aspecte es va fer primer una reflexió sobre l’evolució de la terminologia en els darrers dos anys.

Espanya és membre de l’IHTSDO des del 2009, això significa que ara farà només tres anys que es pot usar l’estàndard de manera lliure. També cal destacar que fa un parell d’anys no es sabia què era SNOMED CT i no es coneixia prou com per pensar en o parlar d’implantar-lo. Feia falta crear massa crítica,  definir metodologies, processos de gestió i formar professionals.

Actualment es pot afirmar que ja es parla de SNOMED CT amb una certa naturalitat. Encara queda molt per aprendre i definir, però ja podem dir que tenim una massa crítica ferma, experts de diferents disciplines formats i hem aprés a adaptar l’estàndard a les nostres necessitats a través de traduccions, subconjunts, extensions, mapejos, etc. La conclusió d’aquestes afirmacions és que ja estem llestos per fer un pas més. Tenim tot el que cal per començar a implantar l’estàndard als sistemes d’informació i que comencin a aflorar casos d’èxit. Destacar breument en aquest punt els SIAPs (Sistemes d’Informació d’Anatomia Patològica), ja que a Catalunya són els sistemes que més avançat tenen l’ús real de SNOMED CT.

Era necessari un procés d’apropament a SNOMED CT, conèixer-lo i aprendre com fer-lo servir. Com que aquesta etapa ja està molt avançada, es pot començar a passar a la següent: implantar-lo.

Per tant, els subconjunts que es van creant no cauran en desús si els professionals assistencials els fan servir, ja sigui com a terminologia d’interfase o de referència. Quan tinguem SNOMED CT als sistemes d’informació i això aporti un valor afegit a la feina dels facultatius. Per tal que això es consolidi, caldrà saber explicar quin és aquest valor i com compensa els esforços inicials d’implantar SNOMED CT.

Llegir en català

El 16 y 17 de Mayo se realizó la segunda reunión del Foro de Interoperabilidad en La Granja San Ildefonso, Segovia. CCI-TCM participó en la segunda sesión del evento “terminología (SNOMED CT)“, con una presentación sobre la metodología de creación de subconjuntos.

El Foro de Interoperabilidad es la evolución del de Normalización, y en la edición de este año se presentó el estado del arte de la interoperabilidad, se trató la terminología y profundizó en la interoperabilidad organizativa. A través de las diferentes sesiones se mostró tanto el punto de vista de la industria, como el de la administración pública. Destacar las presentaciones sobre los avances, en materia de integración, digitalización e interoperabilidad de SACyL, el Sistema de Salud de Castilla y León.

La comunicación presentada por CCI-TCM se muestra a continuación:

En el recurso se hace una breve introducción al vocabulario controlado y se explica el proceso de creación de subconjuntos que se ha definido des de CCI-TCM y la OFSTI (Oficina d’Estàndards i Interoperabilitat) de la fundación TicSalut. También se presentaron los subconjuntos que se han trabajado (vacunas, alergias, prestaciones quirúrgicas y anatomía patológica), en la definición de los cuales se ha aplicado la metodología de creación de subconjuntos.

En el turno de preguntas y debate de la sesión sobre SNOMED CT surgieron dos temas muy interesantes:

  • Herramientas que permiten explorar, explotar y gestionar el estándar.
  • Uso de SNOMED CT.

 

STERMCAT

Se preguntó si en Cataluña se está usando alguna herramienta para gestionar SNOMED CT o centralizar los recursos semánticos. Para responder esta cuestión se explicó que des de la OFSTI se ofrecen diferentes servicios, más que herramientas concretas, recogidas bajo el nombre STERMCAT. No se limita el despliegue de SNOMED CT al uso de una sola herramienta, sino que se enfoca a servicios terminológicos que se pueden ofrecer por parte de aplicaciones distintas. Actualmente la web de la OFSTI tiene un apartado dedicado exclusivamente a terminología, donde se publican manuales, guías, noticias, etc. Destacar el censo de catálogos que contiene una ficha con la información básica de más de 60 catálogos. Con este registro, se puede consultar si existe un vocabulario estándar que cubra las necesidades concretas. El apartado de terminología también contiene el área de descarga de SNOMED CT, a través del cual se puede obtener la versión INT y la ES-ARG de la terminología, así como la extensión catalana, con los subconjuntos creados.

 

Uso de SNOMED CT

Otra de las preguntas que se hizo fue qué es necesario para que los subconjuntos creados no caigan en desuso. En este aspecto primero se hizo una reflexión sobre la evolución de la terminología en los últimos dos años.

España es miembro de IHTSDO desde 2009, esto significa que hará solo tres años que se puede usar el estándar de manera libre. También es necesario destacar que hace un par de años no se sabía qué era SNOMED CT y no se conocía bastante como para pensar en o hablar de implantarlo. Hacía falta crear masa crítica, definir metodologías, procesos de gestión y formar profesionales.

Actualmente se puede afirmar que se habla de SNOMED CT con cierta naturalidad. Aún queda mucho por aprender y definir, pero ya podemos decir que tenemos una masa crítica fuerte, expertos de diferentes disciplinas formados y hemos aprendido a adaptar el estándar a nuestras necesidades a través de traducciones, subconjuntos, extensiones, mapeos, etc. La conclusión de estas afirmaciones es que ya estamos listos para dar un paso más. Tenemos todo lo necesario para empezar a implantar el estándar en los sistemas de información y que empiecen a aflorar casos de éxito. Destacar brevemente en este punto los SIAPs (Sistemas de Información de Anatomía Patológica), ya que en Catalunya son los sistemas que más avanzado tienen el uso real de SNOMED CT.

Era necesario un proceso de acercamiento a SNOMED CT, conocerlo y aprender cómo usarlo. Esta etapa ya está muy avanzada, por lo que se puede empezar a pasar a la siguiente: implantarlo.

Por lo tanto, los subconjuntos que se van creando no caerán en desuso si los profesionales asistenciales los usan, ya sea como terminología de interface o de referencia. Cuando tengamos SNOMED CT en los sistemas de información y esto aporte un valor añadido al trabajo de los facultativos. Para que esto se consolide, será necesario saber explicar cuál es este valor, y como compensa los esfuerzos iniciales de implantar SNOMED CT.