Taxonomia de estandares en informatica medica

Este artículo más que mostrar y explicar algo que existe, está más orientado a dar mi opinión personal, a hacer alguna propuesta y a generar discusión al respecto.

Me ha pasado varias veces, que hablando con colegas en el ámbito de la Informática Médica (IM) (informáticos, médicos, técnicos, etc), me preguntan si elegir tal o cual estándar para aplicar en sus sistemas de información.

Me han preguntado cosas como ¿elegimos CIE 10 o Snomed?, ¿elegimos OpenEHR o HL7?, etc. En estos casos, detecto que hay dos problemas presentes. Primero, no se tiene claro "el requerimiento", o esa ¿para qué aplicar un estándar?. Suena obvio, pero muchos quieren aplicar estándares sin saber realmente en donde y porqué. Es como el típico comentario sobre la aplicación de la tecnología por la tecnología en sí, sin ver realmente a la tecnología como la herramienta (que es) para alcanzar un objetivo. Segundo, no podemos comparar papas con manzanas. El problema (creo) es que no existe una taxonomía clara que clasifique, catalogue y agrupe estándares que cubren una misma área o que tienen un objetivo similar.

El objetivo de este artículo es por un lado, tener un referencia para poder compartir con los colegas cuando hayan dudas respecto a los estándares, y otra, es proponer una taxonomía que pueda ayudar a ordenar un poco este "mar de estándares" en el que estamos inmersos. Creo que una "taxonomía definitiva" es difícil de alcanzar, porque para crearla se necesitan múltiples visiones, tanto la de los expertos en los estándares, la clínica y la informática (es necesario saber cómo se crean los sistemas informáticos para catalogar estándares que afecten a la arquitectura de un sistema, y a cómo un conjunto de sistemas se comunican entre sí, y estas son áreas cubiertas por múltiples estándares).

Existe un trabajo de K. Kim para la California Healthcare Foundation del 2005, en donde propone a grandes rasgos una categorización para los estándares, que divide en las siguientes categorías:

• Intercambio de datos/mensajes
• Terminología
• Documentos
• Conceptuales
• De aplicación
• De arquitectura

A continuación vemos con un poco más de detalle el significado de lo que llamaremos la "categorización de Kim".


Intercambio de datos/mensajes
Permiten que las transacciones fluyan consistentemente entre sistemas [informáticos] u organizaciones, debido a que contienen instrucciones (o especificaciones) para el formato, datos y estructura. Ejemplos que brinda Kim: HL7 para datos administrativos como información demográfica y de encuentros, DICOM para imágenes radiológicas, y NCPDP para prescripciones electrónicas.

Terminología
Estos vocabularios proveen códigos específicos para los conceptos clínicos como enfermedades, listas de problemas, alergias, medicaciones, y diagnósticos, que pueden tener descripciones textuales variables para un registro en papel o una transcripción. Ejemplos que brinda Kim: LOINC para resultados de laboratorio, SNOMED para términos clínicos, ICD para diagnósticos médicos.

Documentos:
Para indicar qué tipo de información es incluida en un documento y dónde esta información puede ser encontrada. Ejemplos que brinda Kim: formato SOEP (subjetivo, objetivo, evaluación, plan), CCR (continuity of care record), CDA (clinical document architecture).

Conceptuales:
Permiten que los datos puedan ser transportados entre sistemas sin que pierdan significado y contexto. Ejemplos que brinda Kim: HL7 RIM.

De aplicación:
Estos determinan la forma en que las reglas de negocio son implementadas, y en que los sistemas de software interaccionan. Ejemplos que brinda Kim: SSO (single sign-on), estándares para visualización de información entre bases de datos distribuidas.

De arquitectura:
Estos definen el proceso comprendido en el almacenamiento y distribución de datos. Ejemplos que brinda Kim: centros de control de enfermermedades y salud pública (PHIN), arquitectura funcional del Institute of Medicine y HL7.


Si bien la categorización de Kim parece comprensible, incluso creo que es un buen inicio cuando uno se está introduciendo en los estándares para Informática Médica, mi impresión al ver esta lista por primera vez fue "aquí falta algo". Esta impresión creo que se dio por dos razones. La primera, conocía estándares que no estaban considerados estríctamente en las categorías de Kim. Segundo, la categorización, así como todo el trabajo de Kim, está guiada más que nada por estándares HL7, de las terminologías que éste utiliza y de los estándares que comprenden los perfiles IHE (fuértemente ligados a HL7), entonces ¿qué pasa con los estándares ISO, CEN, OpenEHR, OMG, ...?

La crítica que le puedo hacer a la categorización de Kim (que como dije: es buena como primer aproximación), es para quienes necesitamos una categorización más clara, que considere la mayoría de estándares de aplicación en IM, sin un estándar que pueda caer en varias categorías (o sea categorías que se solapen), y que cada categoría tenga una descripción clara de qué tipos de estándares entran en ella y cuáles no. En definitiva: una categorización más rigurosa. Algunos ejemplos de la falta de rigurosidad de la categorización de Kim, en mi humilde opinión, son:

• Las descripciones de las categorías "Intercambio de datos/mensajes" (...formato, datos y estructura), "Documentos" (...qué tipo de información es incluida en un documento y dónde esta información puede ser encontrada), "Conceptuales" (Permiten que los datos puedan ser transportados...) y "Arquitectura" (...distribución de datos), tienen claros signos de solapamiento. Entonces es útil definir una categoría donde se puedan agrupar los estándares que definen datos y su estructura, otra categoría para estándares que especifican la semántica de esos datos, otra para indicar cómo esos datos son representados mediante documentos y mensajes, y otra que especifique cómo distintos actores intercambian esos documentos y mensajes.
• Los nombres de las categorías son ambiguos y su descripción no ayuda a clarificarlos. Por ejemplo, los estándares de "Terminología" son en sí clasificadores de conocimiento clínico, y la codificación de este conocimiento es un producto de estas clasificaciones que simplifica su uso en sistemas informáticos, aquí se presenta como que el objetivo de los estándares terminológicos es la codificación. Luego, el nombre de "Estándares conceptuales" es algo tan genérico que no agrega información. En si todos los estándares son conceptuales, ya que todos de una forma u otra intentan ordenar el conocimiento médico para permitir su representación en sistemas informáticos, y esto obviamente se hace mediante modelos y otras construcciones conceptuales. En este caso el nombre "Modelo" sería equivalente al de "Conceptual", el problema es que es necesario especificar modelo de qué cosa. El ejemplo que da Kim es HL7 RIM, así que una opción es "modelo de información para la mensajería", pero existen otras construcciones conceptuales que no son modelos de mensajería, como lo es el modelo datos de DICOM o el modelo de información de OpenEHR. Lo mismo ocurre con "estándares de aplicación", de una forma u otra todos son estándares que deben ser implementados en una aplicación de software. Además estándares para el almacenamiento y comunicación de información podrían estar en esta categoría, sin embargo están en la categoría "estándares de arquitectura". Y por último, los "estándares de arquitectura", para cualquier arquitecto de software es fácil saber que debería entrar en esta categoría: estándares para definir componentes, sus dependencias, y la forma en que estos interactúan (interfaces, transacciones, mensajes, servicios, etc, todos items que pueden caer en cualquiera de las categorías anteriores).
• Algunos problemas con los ejemplos: en el caso de "estándares de documentos", se brinda SOEP como un estándar de formato de documento, junto con CCR y CDA. Si bien SOEP podría tomarse como una estructuración de un documento clínico con cuatro áreas bien marcadas, creo que SOEP es más un "modelo de registro" que un "formato de documento". Además en el contexto de los ejemplos, difiere de CCR y CDA en que éstos son definiciones para documentos electrónicos estructurados. En la categoría de "estándares conceptuales", ¿solo HL7 RIM permite que los datos puedan ser transportados sin perder significado y contexto? ¿qué hay de ISO 13606 o mismo del ASTM CCR?. Por otro lado, en la categoría de "arquitectura", los ejemplos que se brindan son de superarquitecturas al nivel de Estados Unidos, ¿donde entran las micro y meso arquitecturas?, es decir, arquitecturas a nivel de una institución, de una federación, o de un país pequeño. Por otro lado, muchos elementos descritos en las demás categorías, influyen en la arquitectura del sistema, cualquiera sea el tamaño de este, por lo que todas las categorías están relacionadas e interconectadas.

La pregunta que surge es ¿habrá una mejor categorización? ¿con categorías más claras y menos solapadas?. Creo que si, pero no creo que la presentación en un nivel sea la más correcta para esta categorización. Éste creo que es el principal problema de la categorización de Kim, que laa categoría "A" mira un conjunto de atributos desde un punto de vista, y otra categoría "B" mira otro conjunto de atributos (potencialmente compartidos con la categoría "A"), y ambas categorías se encuentran en un mismo nivel, entonces al querer clasificar un estándar no sabré en cual categoría ponerlo (tal vez elija la que considera más atributos importantes del estándar en cuestión, por ejemplo si hay que clasificar HL7 RIM en una sola categoría, lo pondría en "intercambio de mensajes", porque el objetivo de ese estándar es la representación de datos para el intercambio de mensajes).

De esta discusión surge entonces que para clasificar podría ser útil considerar distintos "puntos de vista", y luego clasificar según ese punto de vista, y tal vez el mismo estándar se pueda clasificar varias veces según distintos puntos de vista.

Según mi experiencia en el estudio de estándares en IM y en la creación de Sistemas de Información en Salud (SIS), algunos "puntos de vista" o "dimensiones" interesantes podrían ser (lista no exhaustiva):

• Dimensión de la información y la semántica: cómo se definen y se representan los datos, la información y el conocimiento en salud.
• Dimensión del sistema: componentes de un SIS, requerimientos, funcionalidad, servicios, etc.
• Dimensión de la comunicación: cómo se comunican distintos SIS, qué información intercambian, con qué finalidad, protocolos, seguridad, interfaces, mensajes, etc.
• Dimensión de la integración: evolución desde sistemas aislados hasta infraestructuras de información para salud, indica los distintos niveles por los que es necesario pasar para lograr un sistema de salud integrado.

Algunas ideas atrás de estas dimensiones:

Información y semántica
Múltiples estándares definen alguna forma de representar datos, estructuras, restricciones, reglas, contexto, etc. Creo que es útil analizar en qué se diferencian estos modelos de información y semántica y cuáles cosas tienen en común. Esto no solo sirve para clasificar un estándar en uno u otro grupo, si no que sirve para detectar compatibilidades o incompatibilidades entre varios estándares del mismo grupo.
Esta dimensión encierra todo lo referido al modelado y representación de la información, independientemente de su uso (persistencia, comunicación, conceptualización del dominio, etc).

Dimensión del sistema
Todo estándar de una u otra forma afecta a cómo son construidos los sistemas. Esta dimensión trata de catalogar los estándares según el componente que afecten dentro de la construcción del sistema. Y si son estándares que directamente definen una arquitectura determinada, también contemplarlos en esta dimensión.

Dimensión de la comunicación
El nombre está más que claro. Esta dimensión agrupará todos los estándares que afecten de alguna forma a algún elemento que participe en la comunicación de información, esto quiere decir que afecta: al emisor, al receptor, al canal, al mensaje y/o al contexto. Dentro de esta dimensión, distintos categorías pueden agrupar estándares de "protocolos de comunicación", de "formatos de mensajes", de "interfaces", etc.

Dimensión de la integración
Esta dimensión es la de "más alto nivel", es en donde se agrupan todas las visiones para lograr objetivos específicos, primero sistemas orientados por estándares, segundo redes de sistemas, y por último una plataforma de servicios que permita que nuevas redes y nuevos servicios puedan desplegarse bajo demanda (si, como un Internet para salud, a esta idea le dedicaré su propio artículo).

Una quinta dimensión podría agrupar los estándares de uso general, que suelen ser usados por estándares específicos en Informática Médica, como pueden ser XML, ADL, UML, OWL, etc. A esta dimensión podríamos llamarle "Dimensión de infraestructura" o "Dimensión transversal", porque atraviesa a las demás dimensiones.

El lector astuto ya habrá detectado un padrón en estas dimensiones, y es que si las seguimos en orden, lo que estamos haciendo es crear sistemas desde la unidad más básica, hasta llegar a grandes redes que pueden ofrecer servicios y soportar los sistemas de salud de los distintos países, cosa que es posible solamente si partimos de la estandarización a niveles casi atómicos en los SIS. Además, de estas descripciones pueden desprenderse algunas categorías interesantes, formando así una taxonomía genérica que podría clasificar cualquier estándar para IM. El resultado es algo así:

Dimensión de la información y la semántica:

• Datos: son hechos, símbolos y señales objetivas. Son elementos semánticos atómicos. Por si solos son irrelevantes, por lo que necesitan un contexto que permita utilizar los valores Por ejemplo el símbolo "I10" por si solo no dice nada, pero si se establece el contexto de que es un código CIE 10, éste símbolo representa el concepto de "hipertensión arterial primaria". Existen varios ejemplos de elementos que caen en esta categoría, entre ellos las codificaciones resultado de las terminologías, y las definiciones de tipos de datos básicos que proveen varios estándares.
• Información: es un conjunto de datos procesados, que tienen un significado (relevancia, propósito, contexto). En general se obtiene brindando formato, estructura, relaciones, restricciones y una correcta visualización sobre los datos atómicos. Un ejemplo claro de los elementos de esta categoría son los modelos de información.
• Conocimiento:es todo mecanismo que permita procesar la información, integrarla, agregarla, consolidarla y derivar nueva información a partir de ella. En general tienen forma de reglas lógicas que deben cumplirse. Otro elemento que encontramos en está categoría es la "meta-información", o sea elementos y mecanismos que permiten definir y procesar información sobre la información, como pueden ser definiciones formales de información y clasificaciones, por ejemplo las ontologías y arquetipos.

 

Relación entre datos, información y conocimiento (fuente: Curso 10x10, Unidad 3, HIBA [1])

Dimensión del sistema:

• Arquitectura: en esta categoría entran los estándares que definen los componentes de un sistema de información computarizado, cuáles son sus dependencias y cómo se relacionan y comunican.
• Funcionalidad: en esta categoría se agrupan los estándares que especifican requerimientos sobre las funcionalidades del sistema.
• Persistencia: aquí se agrupan todos los estándares que especifiquen mecanismos y elementos relacionados con cómo es persistida le información en los sistemas de información.
• Reglas de negocio: esta categoría agrupa estándares que ayudan a definir reglas de negocio y los mecanismos para ejecutar esas reglas, y las condiciones y contexto en el que dichas reglas deben ser ejecutadas.
• Procesos: esta categoría agrupa todo estándar que tenga que ver con la definición y formalización de los distintos procesos que se dan en la realidad y que repercuten en el sistema de información (generando, procesando y/o consumiendo información).
• Servicios: aquí se agrupan todos los estándares que tengan que ver con la definición de servicios que un sistema de información puede prestar a otros sistemas. Implica obviamente que existirá una comunicación entre distintos sistemas, pero no especifica cómo se dará esta comunicación, se limita a especificar una interfaz que será consumida o utilizada por otro sistema.

Dimensión de la comunicación:

• Protocolos: agrupa todo estándar que especifique algún protocolo de comunicación entre dos o más sistemas. Un protocolo involucra la definición de interfaces, mensajes, orden en que los mensajes se deben enviar y recibir, cómo debe reaccionar un sistema al recibir un mensaje (qué debe responder, qué acciones debe llevar a cabo), bajo qué condiciones deben darse las interacciones.
• Mensajes: aquí se agrupa todo estándar que defina únicamente los mensajes que pueden ser intercambiados entre diversos sistemas. Se especifica la estructura interna de estos mensajes.
• Interfaces: pueden depender de los protocolos usados para comunicarse. Los estándares en esta categoría permiten definir las interfaces mediante las cuales diversos sistemas se comunicarán. Las interfaces deben ser públicas (publicarse) para que otros sistemas que desean comunicarse puedan hacerlo. Agregar un nuevo sistema a la red de comunicación no debería afectar a las interfaces existentes (regla de bajo acoplamiento).
• Seguridad: son estándares que permite definir mecanismos que permitan agregar seguridad sobre el acceso a la información en salud. Pueden ser tanto mecanismos sobre un sistema (como autenticación de usuarios y acceso por roles), hasta autenticación entre sistemas que se comunican (intercambio de certificados).
• Contexto: en esta categoría entran los estándares que permiten definir el contexto de la información comunicada, por ejemplo, ¿dónde se generó la información?, ¿con qué propósito?, ¿quién la generó? ¿para quién se generó?, ¿cómo deberá o no ser usada esa información?, etc. Esto es sumamente necesario si queremos lograr interoperabilidad semántica.

Dimensión de la integración:

• Sistemas: desde un punto de vista macro, éstos son átomos de generación y almacenamiento de información. Los estándares en esta categoría definen la responsabilidad de cada sub-sistema en un macro-sistema formado por múltiples sub-sistemas. Puede involucrar macro-sistemas formados por sistemas de información de distintos sectores de una misma organización, de distintas organizaciones, incluso de distintos países.
• Redes: los estándares en esta categoría son los que definen los macro-sistemas que mencionamos antes, con todo lo que estos involucran: integración, servicios, protocolos, mensajes, etc. Estar redes pueden ser creadas mediante algún tipo de afinidad, como por ejemplo compartir el mismo modelo de información clínica y el mismo modelo de conocimiento clínico. Esto permitirá la creación de servicios de mayor nivel, incluso se podrán crear nuevos servicios, para los que ni los sistemas ni las redes fueron diseñados, sin necesidad de modificar los sistemas.
• Infraestructura de información: es la categoría de más alto nivel. Implica la interconexión de diversas redes de sistemas (si, una redes de redes, ¿suena conocido?), sobre la cual puedan crearse servicios de uso público, que serán soportados por las diversas redes y sistemas de información. Para tener una idea de lo que se puede hacer con tecnologías y estándares que hoy existen: con un clic, en tiempo real, saber cuantos pacientes hay hoy en el sistema de salud nacional, o por ejemplo, se podrá implementar que una persona reciba un SMS cuando se le esté por vencer alguna vacuna o el carnet de salud, e incluso indicarle el centro de vacunación más cercano a su posición actual, o el centro de certificación para renovar el carnet de salud. Diría que en esta categoría entran todos los estándares existentes, ya que no existe un estándar específico enfocado en esta categoría, pero todos los estándares de una u otra forma, permitirán que estas ideas (no tan locas) puedan ser implementadas en el corto plazo, para que los pacientes se vean realmente beneficiados (es el objetivo de todo lo que hacemos, ya que los pacientes somos nosotros, nuestras familias y amigos).

Volviendo al inicio, antes de pensar en elegir un estándar u otro, primero es necesario saber qué se desea hacer y para qué se quiere aplicar, luego buscar los estándares que entran en esa categoría de aplicación, luego elegir el que más se adapte a las necesidades, basándose en algún criterio como recursos disponibles, conocimiento del estándar, experiencia, o simplemente elegir uno al azar (siempre es lo menos recomendado, pero a veces no hay otra opción). Lo bueno es que ahora se puede contar con una organización que permita simplificar la comparación y selección de un estándar (esa es la intensión).

Ahora la discusión:

• ¿Cuáles otras dimensiones piensas que serían interesantes considerar?
• ¿Cuáles otras categorías agregarías dentro de cada dimensión?
• En general, esta taxonomía ¿te parece lo suficientemente clara, correcta, completa?

¡Todos los comentarios son bienvenidos!


[1] Curso 10x10, HIBA
http://campus.hospitalitaliano.org.ar/course/explicativa.php?curso=245