30 de diciembre de 2010

De que hablamos en este blog

A modo de introducción y contextualización de los temas de los que hablamos en este blog, he creado una página con la recopilación de un conjunto de definiciones sobre la Informática Médica, tratando de responder un poco a las preguntas ¿qué es? ¿para qué sirve? ¿a qué aplica? etc.

Aquí está la página: http://informatica-medica.blogspot.com/p/informatica-medica.html

25 de diciembre de 2010

Documentacion de mi proyecto de grado

Estimados,

En esta ocasión me gustaría dejarles un recopilado de la documentación generada durante el transcurso de mi proyecto de grado. El mismo consistió en la creación de una Historia Clínica Electrónica para el registro de la asistencia médica de pacientes gravemente traumatizados, por ejemplo: accidentados en el tránsito, baleados, apuñalados, precipitados de grandes alturas, etc.



Introducción al proyecto

En este proyecto tratamos de balancear dos fuentes de requerimientos bien distintas, los que venían de la parte médica y los requerimientos del equipo de desarrollo (Leandro y quien escribe). Hubo una tercera fuente de requerimientos que venían de la contraparte informática de la institución donde atendían los médicos.

Los requerimientos de la parte médica apuntaban directamente al registro y a la estructuración para permitir el análisis posterior, o sea, que no faltara ningún dato y que los datos necesarios para calcular indicadores estuvieran bien estructurados para simplificar cálculos, agrupaciones y consolidaciones.

Por nuestra parte, buscábamos orientarnos hacia la aplicación de estándares cuando fuera posible. Por otro lado, buscamos optimizar el modelado del a información que nos proveían los médicos. Nuestra experiencia fue que ellos piensan en datos y variables independientes, en lugar de conceptos clínicos y estructuras, y parte de nuestro trabajo consistió en unir y relacionar esos datos y variables independientes en estructuras de más alto nivel, que tuvieran correspondencias con conceptos clínicos de la realidad. También tuvimos en nuestras manos las decisiones sobre las tecnologías a emplear.

Desde la contraparte informática, los requerimientos estuvieron orientados a la alineación con los desarrollos locales y los estándares que ya se habían implementado en la institución.

La institución asistencial es cuestión es el Hospital Maciel, el cual es un hospital público y es una de las principales puertas de emergencia del país en cuanto a los pacientes traumatizados. La contraparte médica estuvo integrada principalmente por el Dr. Fernando Machado y el Dr. Gustavo Sanchez, también participó el Dr. Gerardo Barrios, presidente de la UNASEV.

Resultados y conclusiones

Lo que logramos fueron varias cosas. Por un lado, un producto que permite registrar todo lo que pasa en la atención de emergencia de pacientes traumatizados, desde que ingresan a la emergencia, hasta que salen de esta. Una de las principales características es que este sistema tiene integrado el acceso a estudios imagenológicos digitales, así que un médico puede ver todos los estudios de imágenes de sus pacientes, a través de la misma historia clínica.

Otro resultado fue un framework genérico que sirve para crear diversos sistemas de HCE basados en arquetipos OpenEHR. En realidad el producto final fue desarrollado como una configuración particular del framework genérico. Aquí se puede encontrar toda la información relativa a este nuevo proyecto open source, creado luego de terminar la tesis.

Por otro lado se logró demostrar que la aplicación de estándares en diversos aspectos de una HCE es posible de realizar, en plazos limitados de tiempo y contando con poco recurso humano (el proyecto duró un año y 4 meses, y lo armamos desde cero entre dos personas). Los estándares y especificaciones que integramos son:
  • openEHR: determinó gran parte de la arquitectura, diseño, modelo de información y modelo de conocimiento. Es el corazón del framework.
  • DICOM: se utilizó para crear el componente de acceso a estudios imagenológicos, para poder ver imágenes diagnósticas desde la propia HCE web.
  • CIE 10: se utilizó para la codificación de diagnósticos. Solo se utilizaron los códigos del capítulo XIX: Traumatismos, envenenamientos y algunas otras consecuencias de causa externa.
  • CDA: se utilizó para la generación de documentos clínicos en base a la información registrada en el sistema, de esta forma, toda la información registrada en el sistema queda accesible desde otros sistemas intercambiando documentos HL7 CDA.
  • IHE PDQ: se utilizó para poder consultar la base de datos de pacientes (que ya tenía la institución) desde nuestra HCE de trauma.

Material

A continuación dejo un link con toda la información del proyecto. Por un lado la entrega del proyecto (la tesis) está dividida en dos, los capítulos y los anexos. Luego está la presentación final del proyecto ante el tribunal evaluador. También encontrarán el paper y la presentación hecha en el CAIS 2010 donde hablé sobre el proyecto.

Actualización: dejé la documentación aquí: http://code.google.com/p/open-ehr-gen-framework/downloads/list


Cualquier pregunta o comentario, todo es bienvenido.

¡Feliz 2011!

17 de diciembre de 2010

Algunos pensamientos sobre inversión e impacto

Hace un tiempo vi esta charla de Derek Sivers en TED, que más allá de lo gracioso, me dejó pensando en el modelo de atención médica occidental.

La frase de Derek que me dejó pensando es esta: "en China algunos doctores creen que su trabajo es mantenerte sano. Entonces, cada mes en el que estés sano, les pagas, pero cuando estás enfermo no les pagas porque ellos lo toman como que han hecho mal su trabajo. O sea, que ellos se hacen ricos cuando estás sano y no enfermo".



La primera vez que vi el video no me pude sacar de la cabeza las preguntas: ¿qué pasaría si eso fuera así aquí también? ¿qué pasaría si el objetivo y la acción de los sistemas sanitarios fueran enfocados directamente en la prevención y promoción de la salud?.

Una realidad un poco contradictoria, que se sigue dando, es que la mayor parte de la inversión está destinada a la atención especializada y super-especializada, la cual solo abarca una una pequeñísima parte de los usuarios del sistema sanitario. Mientras que en la atención primaria, donde se debería hacer prevención y promoción de la salud, la inversión es notoriamente menor.

Opino que gastar más en prevenir más, es ahorrar más. Y que esto tiene una gran potencialidad para aumentar la calidad de vida de la mayoría de la población.

Uno de los problemas que veo en ese sentido es que muchas veces los resultados y el impacto de la inversión en el primer nivel de atención son tan difíciles de evaluar, que los gestores prefieren invertir en cosas más notorias, como podría ser la compra de equipamiento, o la creación de un nuevo centro asistencial. También creo que la dificultad que existe para medir los impactos y resultados de las inversiones se dan porque estas inversiones no son acompañadas de un plan efectivo de medición y control. No tengo dudas que con el debido apoyo de las Tecnologías de la Información y la Comunicación (TICs), la medición y control para evaluar resultados e impacto serían más que factibles.

Si esto fuera cierto, algunos de los problemas que pueden tener los equipos de administradores, gestores y efectivizadores de estas inversiones podrían catalogarse como "problemas en gestión de proyectos", y que a su vez podrían estar dentro de esta lista:
  • Problemas en análisis de riesgos: es necesario tener en cuenta los factores externos e internos que pueden poner en peligro los proyectos de inversión, y desarrollar planes de contingencia acordes. Parece redundante mencionar este punto porque está en la tapa de cualquier libro de gestión de proyectos, pero la verdad es que no se pone en práctica.
  • Problemas en plan de comunicación: poner un plan en marcha muchas veces requiere de la participación de múltiples actores. Si un plan se pone en marcha y surgen actores que no quieren llevarlo adelante, o quejas por falta de información, entonces el error es de quien puso en marcha el plan/proyecto antes de contactarse con las personas e instituciones necesarias. El problema claramente no es de quien no quiere hacer la tarea, es de quien no comunicó en su debido momento a esa persona.
  • Problemas en plan de control: previo a la puesta en marcha de cualquier proyecto, debe establecerse un proceso de medición y control, para detectar desvíos de lo planificado lo antes posible, y tomar medidas correctivas antes de que surjan los problemas. No tener un plan de medición y control, es un riesgo que se debe analizar y contener debidamente.
  • Problemas en análisis del impacto: el impacto no es el cumplimiento de los objetivos de un proyecto, plan o estrategia. El impacto es el resultado final de esas acciones. O sea, que es la diferencia entre el estado final y el estado inicial. El impacto muchas veces excede a los objetivos, por que los proyectos pueden impactar positiva o negativamente en un sin número de actores, directa o indirectamente. Para medirlo correctamente se necesita mucha información, tanto de la ejecución y control de cada proyecto, como información de realimentación de los propios actores. Por las inmensas cantidades de información que se deben manejar, no hay otra opción que utilizar TICs para analizar correctamente la información y tener una idea clara del impacto.
  • Problemas de agenda: muchas veces quienes ejecutan estas inversiones y planes son agentes políticos, por lo que a veces vale más poner un plan en marcha y hacerlo visible, a que el propio plan sea un éxito y beneficie realmente a la sociedad.
  • Problemas de asesoría: en cada área existen expertos, tanto en gestión de proyectos, gestión de riesgos, comunicación y cambio cultural, análisis de impacto y retorno de inversión, etc, etc. Sabiendo que existen, no recurrir a estos especialistas es en sí un problema y un riesgo en cualquier proyecto.

Seguramente existan más problemas que no estoy incluyendo aquí. Me gustaría saber sus opiniones sobre el tema, más que nada para ver que tan válido es este razonamiento, o también para ver si estoy muy alejado de la realidad.

10 de diciembre de 2010

Grandes problemas de estandarización

Los grandes problemas de estandarización del Sistema Nacional Integrado de Salud uruguayo

Profundizando un poco la visión del artículo de Heather Leslie, me gustaría gastar algunas palabras en brindar una mirada crítica de lo que está pasando en Uruguay con respecto a la estandarización en salud.

Un hecho (un poco contradictorio) es que los grandes actores en el Sistema Nacional "Integrado" de Salud (SNIS) sostienen el discurso de "la estandarización es necesaria e inevitable si realmente queremos un sistema integrado". Pero por otro lado, la aplicación de TICs en salud que hacen estos mismos actores no contempla ningún tipo de estándar.

Las causas de esto son varias. Por un lado existe un gran ruido externo que promueve una familia de estándares para resolver "todos" los problemas de estandarización en l aplicación de TICs en salud, y nuestra cultura de "seguir al líder" aporta a que muchos quieran ir en el camino del que hace más ruido (muchas veces sin saber a ciencia cierta cual es el costo de ese camino y cual va a ser el retorno de inversión). Esto a su vez hace que quienes "dicen" que quieren aplicar estándares, no los saben aplicar correctamente, entonces cuando deben resolver un problema real, dejan los estándares de lado y se concentran el los desarrollos a medida que los saquen del paso.

Otra causa posible de esta contradicción es la falta de recursos humanos capacitados. En Uruguay existe muy poca gente que sabe de estándares aplicados a TICs en salud. Y con saber me refiero no a gente que sepa algunos nombres y cual es el objetivo de cada estándar, si no de gente que haya probado estándares, que conozca más de una alternativa para resolver un problema, que haya comparado estándares de forma crítica (con visión independiente), y que pueda saber cuál es el costo real de implementar un estándar, y pueda estimar cuál fue el retorno en esa inversión (como para saber si ese camino vale la pena). Lamentablemente existen muy pocos trabajos a nivel nacional en ese sentido.

Por otro lado, los estándares que son más nombrados (pero nunca analizados en profundidad), son estándares para la comunicación de datos clínicos. Pero no se están definiendo cuáles van a ser los contenidos de esas comunicaciones. Entonces tendríamos una gran cañería para pero sin saber que va a transportar: agua, gas, etc. Creo que esto es una de las grandes fallas de visión de todo el sistema, y a lo que apunta el artículo de Heather: concentrémonos en definir de forma coordinada y consensuada el contenido clínico, y luego pensemos en cómo comunicarlo (es un simple tema de orden).

Cabe hacer la aclaración que existen organizaciones dentro del sistema de salud que están definiendo contenidos clínicos, pero estos contenidos están basados en requerimientos locales de esas organizaciones, por lo que es posible que ese contenido no pueda ser reutilizado por otras organizaciones.

Mi visión en este tema es:
  • En lugar de "seguir a líder" (o por lo menos al que "hace más ruido"), "tomemos lo mejor, adaptémoslo al contexto nacional, e innovemos donde nuestros requerimientos no pueden ser satisfechos con estándares internacionales (creemos estándares locales)".
  • Definamos por un lado el contenido clínico: documentos, conceptos, datos, restricciones, reglas, etc, y por otro busquemos estándares que puedan modelar estos elementos (aplicándolos tal cual, o adaptándolos a la realidad nacional).
  • Generemos estándares locales para los elementos que no pueden ser modelados de forma efectiva por estándares internacionales.
  • Definamos procesos de certificación de las herramientas de software, para validar que los proveedores ofrecen herramientas que cumplen nuestros estándares.
  • Hagamos leyes que obliguen a que las herramientas que se usan en las instituciones sanitarias, en los entes reguladores, organismos y en el propio Ministerio de Salud Pública, deban estar certificadas.
  • Creemos una infraestructura de información en salud, criterios de intercambio de esta información, y servicios de uso público (tanto para las instituciones como para los pacientes y médicos). Esta infraestructura permitirá intercambiar toda la información necesaria para controlar a las instituciones sanitarias a nivel de gobierno (lo que hoy se realiza mediante procesos dolorosos, costosos y poco efectivos, hacerlos de forma automática, exacta y con costo cero).
  • Implantemos un proceso de mejora continua de todo el sistema de salud. Al final del proceso tendremos un sistema gestionable, medible, optimizable, coordinado, en definitiva: realmente integrado.

Algunas discusiones sobre estandarización a nivel nacional:

7 de diciembre de 2010

Imagenologia digital: breve introduccion

Este el el primer artículo del blog sobre el tema de la imagenología digital. La idea inicial era crear un artículo sobre experiencias, pero me pareció que sería útil crear un artículo introductorio al tema y luego ahondar en las experiencias.

Seguramente publicaré un par de artículos como guía y contexto, uno sobre modalidades en imagenología digital y otro directamente sobre el estándar DICOM.


Introducción

Hablamos de "imagenología" en lugar de "radiología" porque es un término más inclusivo, ya que la "radiología" implica que las imágenes se obtienen por la emisión de radiación, clasificación que deja por fuera modalidades como ecografía, resonancia magnética o PET.

El término "digital" lo utilizamos porque en última instancia el estudio termina siendo un conjunto de imágenes en formato digital, que se pueden almacenar en un medio magnético u óptico (disco duro, pendrie, DVD, etc). Esto no implica que las imágenes sean generadas de forma digital, existen modalidades generadas de forma analógica y luego digitalizadas, como es la radiografía computarizada (CR).

Por otro lado, la imagenología digital busca mejorar los procesos de petición, coordinación, realización, informe y obtención de resultados, resultando en ventajas para el paciente, el equipo médico, y la institución sanitaria.

Ventajas de la imagenología digital

Seguridad y comodidad del paciente


Con los avances hechos en al área, tanto los equipos digitales como los equipos analógicos cuyos resultados se digitalizan, requieren emitir un menor nivel de radiación para generar una imagen de calidad para el diagnósticos. Por lo tanto, la radiación absorbida por el paciente es menor.

Con el proceso digital, el paciente no se lleva para su casa grandes placas, que debe acumular durante toda su vida en su hogar, y que debe llevar a la institución sanitaria cada vez que tiene consulta con su médico. Por el contrario, toda la información queda almacenada en la propia institución.

Accesibilidad e integración con la Historia Clínica Electrónica

Debido a que toda la información imagenológica se encuentra en la institución sanitaria, esta puede ser accedida desde cualquier punto de su red local, permitiendo que un médico pueda acceder a los estudios de su paciente, independientemente de dónde se encuentre dentro de la institución. Si además la institución permite acceso desde fuera de esta, el médico podría ver los estudios de sus pacientes desde su propia casa, oficina, o tomando un café en un bar.

El acceso a los estudios desde fuera de la institución, permite además la "teleradiología". Esta aplicación permite que un experto o grupo de expertos radiólogos, puedan visualizar y crear informes radiológicos sobre un determinado estudio. Por lo tanto, no se necesitaría un experto constantemente en la institución sanitaria. Entonces, cuando se tenga un estudio que debe ser informado, cualquier radiólogo disponible, puede crear el informe de forma remota. Esto permite que haya centros de diagnóstico especializados, con equipo como los costosos "monitores de grado médico", que permiten visualizar las imágenes digitales con un gran nivel de detalle y calidad. 

Por otro lado, al tener los estudios imagenológicos en formato digital, pueden ser integrados a la historia clínica electrónica del paciente, por lo que cualquier médico que tenga acceso a la historia, podrá ver las imágenes y los informes de esos estudios. Esto aporta a la completitud de la HCE, cosa imposible de hacer con la HC tradicional en papel.

Mejoras en los procesos

La imagenología digital permite que los proceso que hoy se hacen con interfaz humano-humano y humano-papel-humano, con las contras que esto tiene (olvidos, errores, pérdidas, repetición de estudios, etc), sean realizados como procesos humano-sistema informático-humano con las ventajas de que:
  • Queda registrado quién pidió el estudio
  • Queda registrado para quién se pidió el estudio (paciente identificado correctamente desde el inicio)
  • Queda registrada toda la información del estudio (qué estudio, donde, cómo, etc)
  • Queda registrada la coordinación del estudio (día, hora, lugar, condiciones a cumplir por el paciente como ayuno, etc)
  • Queda registrado el estudio (conjunto de imágenes, que a su vez están identificadas con un determinado paciente)
  • Queda registrado el informe del estudio (identificando al autor del informe, al paciente y asociado al estudio correspondiente)
  • Toda la información queda disponible para consulta en cualquier momento
    • Acceso del médico que pidió el estudio
    • Gestión y mejora de calidad (medición de tiempos, satisfacción del paciente, etc)
  • Vinculación del estudio con la HCE a través de la identificación del paciente

Disminución de costos

Por último, ya no es necesario comprar películas ni placas, agentes químicos como reveladores y fijadores. Tampoco es necesaria la compra y mantenimiento de procesadores de placas y equipos de revelado. Por otro lado, el espacio necesario para almacenar esta información se reduce enormemente, debido a que todo puede ser almacenado en un servidor.

Procesos y sistemas de información involucrados

En los procesos relacionados con estudios imagenológicos, pueden existir y coexistir varios sistemas informáticos. En general se habla de la coexistencia de 3 sistemas informáticos bien separados:
  • HIS: Hospital Information System
  • RIS: Radiology Information System
  • PACS: Picture Archiving and Communication System
Si bien en la literatura se pueden encontrar como 3 sistemas bien separados, en realidad muchas veces sus funcionalidades se solapan, hasta el punto, por ejemplo, de que un solo sistema haga de RIS y PACS.

A continuación, dejo un excelente diagrama extraído de una presentación del curso de imágenes médicas [1], que muestra las funcionalidades y las relaciones entre los sistemas:



[1] Curso de imágenes médicas, IIE, FIng.
http://iie.fing.edu.uy/~mdavid/ib/imag%20digital%20y%20pacs%20Daniel%20Geido.pps

6 de diciembre de 2010

Informacion clinica no es solo comunicacion

Hoy he leído un artículo bien interesante de Heather Leslie (@omowizard), donde compara los distintos enfoques de proyectos para sustentar el sistema de salud a nivel país, por un lado EEUU y por otro Suecia. Heather da algunos ejemplos de las áreas en las que hay que tener sumo cuidado, ejemplos de proyectos desastrosos, pero sobre todo el mensaje que da es "concentrémonos en modelar la información de una manera consistente en lugar de buscar mecanismos para intercambiar información (que ni siquiera sabemos si es consistente)".

Sin dudas es un artículo provocativo, pero en lugar de dar opinión sobre cual es el camino a seguir, plantea el debate para que nosotros pensemos en donde queremos estar en un futuro cercano y más a largo plazo.

Aquí el artículo original

Aquí el artículo traducido automáticamente

5 de diciembre de 2010

Importancia de la informacion en salud

Aquí les dejo otra charla TED que no tiene que ver directamente con la informática médica, pero si con la información en general. En esta ocasión el presentador es David McCandless, y su charla "The beauty of data visualization" no tiene desperdicio.

McCandless brinda varios ejemplos de cómo poder visualizar datos y su contexto de forma de que su interpretación sea fundamentada y correcta, sobre todo cuando uno está sumergido en un mar de datos y no sabe por donde empezar a leerlos e interpretarlos. ¡Qué importante es esto para la salud!

Pensando en el dominio de la salud, un concepto que menciona McCandless y que me quedó grabado en la cabeza por varios días es: los datos, su estructura y contexto pueden cambiar nuestra forma de ver las cosas, nuestra perspectiva, y como consecuencia, cambia nuestro comportamiento. Entonces, si la información puede cambiar las acciones que un médico va a realizar, y éste cuenta con información errónea, incompleta, fragmentada, inaccesible, etc, etc, es probable que nuestro médico tome una decisión que no sea la óptima.

Un concepto que me gustaría agregar es que hoy la información (datos, estructura, relaciones y contexto) es un recurso básico en las instituciones sanitarias, con esto quiero decir que es tan o más importante que el agua, la electricidad, el teléfono, etc. Y que al igual que el agua, es necesario crear tanques y cañerías donde se pueda mantener y distribuir la información.

Aquí la charla:



Más información sobre David McCandless: http://www.davidmccandless.com/
Sitio sobre visualización de la información: http://www.informationisbeautiful.net/

1 de diciembre de 2010

Los 10 mandamientos de la HCE

Luego de leer varias "biblias" de lo que se debe y no debe hacer en la implementación de la Historia Clínica Electrónica (HCE) en una institución sanitaria, y considerando de algunas experiencias de campo, creo que puede ser útil hacer una propuesta de los 10 puntos más importantes que son necesarios considerar en la creación e implementación de una HCE (a modo de "mandamientos", solo para hacerlo entretenido).


Los invito a hacer el mismo ejercicio y pensar para ustedes ¿cuáles serían los 10 temas más importantes en la creación e implantación de la HCE en una institución sanitaria?. Debajo del artículo pueden agregar sus comentarios.

1. Identificarás a tus personas

Todas las personas, que participan en cada acto médico y proceso asistencial, deben estar correctamente identificadas: pacientes, médicos, enfermeras, técnicos, administrativos, estudiantes, etc.

La identificación de los pacientes es la más complicada de resolver, ya que no depende de la asignación de un código o número identificador, si no, que depende de los procesos de asignación, verificación y auditoría.
  • Asignación: proceso de registro de información demográfica, y asignación de uno o más identificadores.
  • Verificación: obtención de la información suficiente para realizar una búsqueda y encontrar uno o más identificadores asignados a esa persona.
  • Auditoría: proceso que implica la certificación de que la información demográfica de la persona está completa y es correcta.

2. Identificarás a tus proveedores e insumos

Todas las empresas que provean algún tipo de insumo a una institución sanitaria, debe ser correctamente identificada, se deben tener medios de contacto de las personas que serán contraparte. También se deberá identificar cada insumo provisto por cada proveedor, y saber con certeza cuanto de cada insumo hay disponible en un momento dado (stock).


3. Identificarás a tus productos y servicios

Toda institución sanitaria debe saber con certeza qué productos y servicios provee, cual es el costo que insume brindarlos, por quién o quienes se brindan estos servicios (credenciales), desde donde se pueden brindar (lugares físicos) y para quién o quienes se brindan (clientes).


4. Sabrás quienes son tus pacientes, donde están y qué tienen

Aparte de que todo paciente deba estar unívoca e inequívocamente identificados en una institución sanitaria, los médicos de cabecera o médicos de familia deben saber cuáles pacientes tienen asignados, dónde viven y trabajan, y qué enfermedades, problemas de salud o condiciones tiene cada uno.
En este punto, la información geográfica y la identificación de problemas de salud es crucial. Este punto resume la base de la gestión clínica y de la epidemiología.


5. Especificarás tus procesos

Antes de poder comenzar con la informatización de los proceso asistenciales, es necesario saber cuáles son, quienes son responsables de estos procesos, quiénes participan, cuáles son los resultados esperados, y las precondiciones y restricciones que se dan.
Informatizar procesos indefinidos o caóticos es un error costoso.


6. El ADT es la primer aproximación a la HCE

El ADT (Admisión-Alta-Transferencia en inglés) puede implementarse como un sistema informático que sirva para saber:
  • por dónde, cuándo y con qué motivo ingresan los pacientes.
  • cuándo, a dónde, con qué motivo y a qué especialidad son transferidos los pacientes.
  • cuándo y a qué especialidades se realizan interconsultas.
  • a dónde, cuándo y con qué motivo se realizan las altas.
http://informatica-medica.blogspot.com/2009/11/primer-aproximacion-la-historia-clinica.html


7. La HCE permitirá registrar toda la información clínica

Ningún sistema informático puede establecer trabas a la libertad del registro del médico. La HCE mínima debe, por lo menos, contener al registro análogo en soporte papel.
En etapas tempranas, los registros con cuadros de texto libre son más aconsejables que los registros estructurados.
Estas HCEs mínimas se deberían implantar sobre los sistemas de ADT, ya que los eventos administrativos en el ADT desencadenan procesos de atención médica, con el respectivo registro en la HCE. Luego, los datos de ambos sistemas serán insumos fundamentales para la gestión.


8. Debes proveer trazabilidad en los sistemas informáticos

Debe quedar un registro de todas las acciones que realiza cada usuario del sistema informático. Para una correcta trazabilidad es necesario:
  • Identificar a los usuarios del sistema informático.
  • Registrar qué información ven, qué información agregan, qué información modifican.
  • Desde dónde acceden al sistema (lugar físico, terminal).
  • Cuándo acceden, durante cuánto tiempo (duración de la sesión, momento de cada acción).
  • Saber si intentan realizar acciones para las que no están autorizados (verificación de credenciales).

9. Debes crear un sistema usable

El sistema debe responder rápida y correctamente a los pedidos de los usuarios. Debe estar disponible cuando un usuario lo desea usar. Debe tener una interfaz gráfica amigable, simple, ordenada y fácil de entender. Se debe diseñar la interacción del usuario con el sistema (ejemplo: minimizar la cantidad de clics para que el usuario obtenga lo que desea del sistema). Los médicos deben acceder a la información de sus pacientes cuándo la necesiten y desde dónde la necesiten.


10. Aplicarás estándares

Para crear sistemas informáticos de calidad, debes basar tus sistemas en estándares probados y aceptados por una comunidad. Reutilizando y adaptándolos a la realidad de un país o una institución en particular. No reinventarás la rueda, y reutilizarás las herramientas existentes y disponibles.
La estandarización simplifica la informatización y el desarrollo de nuevos componentes y funcionalidades que extiendan y adapten el sistema informático a nuevos requerimientos.
La estandarización es la base de la interoperabilidad.


Si bien la idea no es crear una religión al rededor de estos mandamientos, tal vez sirvan como guía para quienes empiezan con desarrollos de HCE en sus instituciones (digamos que estamos evangelizando) a la comunidad de informáticos y médicos involucrados en desarrollos de HCE.

¡Espero sus comentarios!

24 de noviembre de 2010

El futuro de la medicina movil

Esta es una gran presentación del Dr. Eric Topol para TED. Desde la primera vez, y siempre que la vuelvo a ver me cuestiono los límites de la aplicación de las Tecnologías de la Información y Comunicación (TICs) en el sector salud, la respuesta es siempre la misma: el límite es la imaginación.

Un mensaje claro del Dr. Topol es que no se está haciendo "futurología", hoy ya existe la tecnología que nos permite hacer cosas impresionantes y ver impactos reales en la mejora de la salud de la población. Lo que nos deberíamos preguntar es porqué estas tecnologías no son implementadas a niveles masivos. ¿Es a caso una resistencia del sector salud? ¿es un problema de los proveedores que no pueden mostrar y demostrar las ventajas de la tecnología bien aplicada? ¿es un problema de los gobiernos, su falta de resolución y la falta de asesoría? ¿es un problema de falta de recursos humanos capacitados y especializados? o ¿será una mezcla de todo?

Aquí la charla:

23 de noviembre de 2010

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

    2 de noviembre de 2010

    Espacio para compartir, discutir y aprender

    OpenEHR-ES intenta ser la génesis de un grupo de discusión en español (el primero en este idioma), en donde se planteen temas relacionados con OpenEHR y su enfoque para la creación de sistemas de información en salud.

    No obstante, también es un espacio para charlar de otros estándares como HL7, CDA, ISO/CEN 13606, DICOM, terminologías y clasificaciones internacionales, etc, etc, etc. Esto es porque quienes creamos sistemas de información en salud, necesitamos distintos estándares para resolver distintos aspectos de nuestros sistemas.

    Para ser parte del grupo, lo único que debes hacer es suscribirte aquí: http://groups.google.com/group/openehr-es

    No es necesario que seas un experto, ni tampoco es excluyente para ningún rol o país. El grupo está formado por informáticos, médicos, veterinarios, y gente curiosa. También tenemos gente de Argentina, Chile, Colombia, Brazil, USA, España, Uruguay y más.

    El primer objetivo del grupo es conocernos, saber quienes están interesados en trabajar con OpenEHR o ya están trabajando, intercambiar opiniones y experiencias, y ser un nexo entre profesionales para la colaboración en proyectos. En el futuro el grupo buscará agregar un área de capacitación, con cursos y materiales, de forma de simplificar la adopción y difusión de la norma, ya que muchos no tienen el tiempo suficiente de estudiar las especificaciones (¡y vaya que son largas!). También buscaremos eventos para poder compartir las experiencias, objetivos y para fortalecer la comunidad OpenEHR de habla hispana.

    ¡Son todos bienvenid@s!

    23 de octubre de 2010

    OpenEHR el estándar abierto para historias clinicas electronicas

    Este es el primer artículo de la serie sobre estándares en Informática Médica.

    El objetivo de esta serie es presentar distintos estándares desde un punto de vista práctico y muy crítico, ya que muchas veces nos llega mucho ruido de quienes promueven sus propios estándares, pero no contamos con una mirada independiente que nos ayude a entender si nos quieren "vender un buzón" o si realmente usando lo que nos dicen podemos solucionar los problemas que plantea la Informática Médica.


    ¿Buscas capacitación en openEHR? Encuéntrala en CaboLabs


    Un posible punto de introducción al tema: http://es.wikipedia.org/wiki/OpenEHR

    OpenEHR en pocas palabras:
    • Estándar abierto que define un modelo de información y un modelo de conocimiento clínico.
    • Propone el enfoque de sistemas informáticos "orientados a la gestión del conocimiento clínico".
    • Objetivo: ayudar a crear sistemas "semánticamente abiertos", durables en el tiempo, y económicamente viables.

    Explicando las "pocas palabras":

    Estándar abierto: es generado, mantenido, probado y validado por una comunidad de usuarios dividida en dos grandes grupos: los expertos clínicos y los expertos en TICs (Tecnologías de la Información y las Comunicaciones). Para formar parte de la comunidad no es necesario pagar, toda la información es libre y para participar en las discusiones solo es necesario registrarse en su lista de correo.

    Define un modelo de información clínica:

    El modelo de información de OpenEHR es una especificación UML (orientada a objetos), y es la parte del estándar que debe implementarse dentro del software. La principal característica es que es un modelo genérico, es decir, que permite representar toda la información que se genera en la asistencia médica, pero no especifica la semántica de cada concepto clínico particular, solo contiene conceptos clínicos generales, como son: observaciones, evaluaciones, instrucciones y acciones. Luego profundizaremos más en los detalles del modelo de información clínica.

    Define un modelo de conocimiento clínico:

    El modelo de conocimiento de OpenEHR es básicamente una especificación de unos artefactos llamados "arquetipos". Los arquetipos son simples archivos de texto plano, que cumplen una sintaxis llamada ADL (Archetype Definition Language). El objetivo de los arquetipos es representar conceptos clínicos particulares y residen fuera del software (al contrario del modelo de información que representa conceptos clínicos generales y reside dentro del software). Los conceptos clínicos particulares son representados como un conjunto de restricciones sobre el modelo de información genérico. Luego veremos algún ejemplo.

    Orientación a la gestión del conocimiento clínico:

    La idea de que los conceptos clínicos particulares residan fuera de la aplicación de software, es en si un cambio de paradigma. Hoy en día, los Sistemas de Información en Salud son fabricados de forma que el conocimiento clínico está definido de forma "dura" en el software. Esto quiere decir, que si cambia el conocimiento clínico que maneja el software, se debe cambiar la aplicación de software (en el sentido que necesita adaptarse a los cambios en el conocimiento clínico). Esto hace que cada cambio sea muy costoso.

    Por el contrario, si el conocimiento clínico es definido y gestionado por fuera del software, como la aplicación de software es genérica, los cambios en el conocimiento no repercuten en el software, ahorrando costos innecesarios. Este paradigma de "gestión del conocimiento clínico" no solo tiene ventajas en ahorro de costos, si no que puede tener implicancias más profundas en los proyectos de TICs en salud.

    Hoy, para crear un sistema de software en salud, un grupo de analistas informáticos tiene una o varias reuniones con un grupo de médicos que les expresan sus necesidades (requerimientos sobre el software). La experiencia indica que este proceso es en general infructuoso. Por ejemplo, una historia que se repite es: cuando el grupo de analistas está convencido de que ha extraído todos los requerimientos, se comienzan a construir prototipos. Una vez finalizados, éstos les son mostrados a los médicos, los cuales comentan cosas como "esto no es lo que pedimos", "esto no me sirve", "yo no te dije esto", o directamente "esto es una porquería". Entonces se tira todo y se vuelve a empezar. Esto se repite unas cuantas veces, hasta que se logra lo que los médicos quieren. La regla del dedo indica: los informáticos no entienden a los médicos y viceversa. Uno de los problemas surge de que en este proceso, los informáticos deben gestionar el conocimiento clínico extraído de los médicos, tarea para lo que no estamos preparados (no somos expertos en el dominio clínico, los médicos si).

    La pregunta clave: ¿porqué no hacer algo que permita que los médicos puedan gestionar el conocimiento clínico directamente sin tener que pasar por los analistas? ¿no nos ahorraríamos muchos dolores de cabeza, tiempo y dinero?. Bueno, esta es la clave de la "orientación a la gestión del conocimiento. Dado que el conocimiento clínico es definido fuera del software, si pudiéramos enseñarles a los médicos a usar una herramienta para generar arquetipos, los médicos podrían definir el contenido de la Historia Clínica Electrónica sin siquiera tener que hablar con un informático. Mientras, con el tiempo ganado, los informáticos podemos crear mejores sistemas de software, más genéricos y más inteligentes, que permitan cargar los arquetipos que definen los médicos y generar el sistema de información en base a ellos.

    Esto tiene varias implicancias. Primero, es el médico quien decide que poner o no poner en un arquetipo, por transitiva, está decidiendo que va y que no va en la historia clínica. Por lo tanto, se evitan las quejas de que el sistema no registra lo que el médico necesita, porque está definiendo justamente lo que necesita. Segundo, se le da a los médicos un rol más preponderante en los desarrollos de TICs en salud. Con el enfoque actual, los informáticos hacemos "uso" de los médicos solo cuando los necesitamos, luego ellos pierden visibilidad del proyecto. Tercero, debido a la satisfacción del médico por haber sido él quien creó la historia clínica y por haber participado activamente en el desarrollo, se facilita el cambio cultural que involucra la inserción de las TICs en salud, evitando rechazos y ganando adeptos que pueden contagiar a los demás en usar el sistema. De esta forma deja de ser un proyecto informático y pasa a ser un proyecto médico.

    Sistemas semánticamente abiertos

    Los arquetipos son definiciones semánticas de conceptos clínicos particulares. Esto quiere decir que cada arquetipo expresa un concepto clínico, junto con su propósito, para qué se debería usar, para que no se debería usar, cual es su estructura interna, qué vínculos con codificaciones y vocabularios controlados tiene, entre otros elementos.

    Los arquetipos pueden traducirse, esto quiere decir que puedo definir un arquetipo junto a sus contexto expresado en múltiples idiomas. Un arquetipo puede compartirse, de modo que si defino un arquetipo para el concepto "presión arterial" en español, puedo traducirlo a inglés y enviárselo a una institución sanitaria en Inglaterra, y ellos podrán entender lo que representa ese arquetipo. Incluso, sus sistemas informáticos podrían hacer uso de ese arquetipo, de modo que si les envío información referente a la presión arterial de un paciente desde Uruguay, ellos la podrían validar e interpretar utilizando el arquetipo.

    Sistemas durables en el tiempo:

    Con el enfoque de "gestión del conocimiento clínico", el conocimiento clínico reside por fuera de la aplicación de software, por lo tanto, a medida que avanza la medicina, el conocimiento puede gestionarse y actualizarse, sin necesidad de modificar la aplicación de software. Por otro lado, las tecnologías cambian, y la aplicación de software podría modificarse sin necesidad de modificar el conocimiento clínico. Esto quiere decir que los procesos de gestión del conocimiento y de gestión del software son independientes. Es más, son ejecutados por roles distintos: expertos en el dominio clínico (médicos, enfermeras, técnicos) y expertos en TICs (ingenieros, analistas, programadores), respectivamente. De esta forma, aunque la tecnología cambie, el conocimiento y la información deben sobrevivir el paso del tiempo, lo importante es mantener estos durante toda la vida del paciente, y aún más tiempo (podríamos hablar de que la información clínica debe durar unos 120 años).

    Sistemas económicamente viables:

    Debido a que ya no es necesario que los analistas extraigan requerimientos y se creen prototipos que los médicos van a rechazar, simplificamos el proceso de desarrollo, y estamos ahorrando en tiempo y dinero. Gracias al enfoque de "orientación a la gestión del conocimiento", el software no necesita modificarse con cada cambio en el conocimiento clínico (que ahora es gestionado de forma independiente por los expertos en el dominio clínico), y considerando que el mayor costo de los proyectos está en el mantenimiento y adaptación del software, este costo se reduce enormemente.


    Dentro del modelo de información genérico:

    El modelo de información de OpenEHR es básicamente un árbol, donde la raíz de éste es la estructura de más alto nivel, llamada "composición". La "composición" puede ser vista como un formulario de registro en papel, el cual está formado por partes más pequeñas que se "componen" para crear la hoja de registro.

    Esas partes más pequeñas son llamadas "entradas" de la historia clínica. Estas entradas no son campos donde se ingresan datos, si no que son grandes conjuntos de campos donde se ingresan datos, que a su vez tienen alguna relación entre ellos, esa relación está contenido en cada "entrada".

    Para no hacer una descripción de todo el modelo de información, vamos a concentrarnos en el modelo de entradas, que me parece fundamental para entender tanto el modelo de información como el modelo de conocimiento. En la figura 1 podemos ver el proceso de resolución de problemas clínicos. En éste vemos que cuando un médico recibe a un paciente, lo primero que hace es observarlo, medirlo, preguntarle. La información que surge de esas observaciones, se debe registrar. Luego el médico realiza evaluaciones, plantea objetivos y planes de cuidado, esto en base a su conocimiento y a fuentes de conocimiento externas. Esta información de las evaluaciones también debe ser registrada. El paso siguiente es dar instrucciones, indicaciones, órdenes. Desde solicitar que se haga un estudio de laboratorio, hasta darle indicaciones al paciente en el alta. Por último, cerramos el ciclo con la ejecución de las instrucciones, lo que vemos aquí como "acciones". Si el paciente no es dado de alta, el ciclo vuelve a ejecutarse. Todo debe quedar registrado.


    Figura 1: proceso de resolución de problemas clínicos.

    Indirectamente, lo que vemos es que toda la información clínica generada en la atención del paciente puede catalogarse en grandes clases, las cuales son: observaciones, evaluaciones, instrucciones y acciones. En la figura 2 vemos el modelo UML de estas clases. Lo central del diagrama, aunque parezca complejo, es ver que todas las entradas tienen una superclase abstracta "Entry". Luego tenemos dos subclases "Admin Entry" y "Care Entry", entradas administrativas y entradas de cuidado, respectivamente.Por último, dentro de las entradas de cuidado tenemos cuatro subclases "Observation", "Evaluation", "Instruction" y "Action". Lo que estamos viendo aquí es el corazón de la Historia Clínica Electrónica.

    Figura 2: modelo UML de entradas OpenEHR

    Algunos detalles del modelo de entradas. Podemos ver que una "instrucción" tiene varias "actividades" relacionadas. Esto modela que las tareas a realizar pueden ser complejas e involucrar varias actividades para ser realizadas, las actividades pueden verse como una lista de pasos para realizar la tarea. Por lo tanto, con una "instrucción" se podría modelar por ejemplo una guía clínica o un protocolo clínico.
    A su vez, vemos que una "acción" puede tener relacionada los detalles de una instrucción, esto es para indicar que la acción fue realizada porque tal "instrucción" y tal "actividad" así lo indicaban. Por último, la "acción" también tiene asociada una "transición en una máquina de estados", esto sirve por ejemplo, en acciones que no son puntuales, si no que se ejecutan durante un período de tiempo (como dar una medicación durante 2 horas), para expresar que se comenzó a ejecutar la acción, se que finalizó, que se canceló, que se suspendió, etc. Todos esos son estados y están asociados a una máquina de estados con transiciones definidas, por ejemplo: no se puede cancelar la administración de un medicamento si todavía no se ha empezado a administrar.

    Previamente comentábamos de que el modelo de información era genérico. ¿Pero donde está lo genérico? Imaginemos que necesitamos representar el concepto clínico "toma de la presión arterial". En el modelo de información no hay ninguna clase particular que represente ese concepto, por el contrario, existe una clase que agrupa todos los conceptos clínicos que sirven para medir cosas sobre el paciente, la "observación". Bien, entonces el concepto "toma de presión arterial" es una "observación", pero necesitamos definir particularidades para esta "observación" específica, eso lo hacemos con los arquetipos.


    Ejemplos de conceptos clínicos particulares y con que clases del modelo de información se corresponden.
    • Toma de presión arterial: observación
    • Frecuencia cardíaca: observación
    • Frecuencia respiratoria: observación
    • Resultado de un estudio de laboratorio: observación
    • Evaluación de vía aérea: evaluación
    • Clasificación de gravedad del paciente (triage): evaluación
    • Evaluación de disfunción neurológica: evaluación
    • Diagnósticos: evaluación
    • Orden de estudios de laboratorio: instrucción
    • Indicaciones para el paciente: instrucción
    • Colocación de vía venosa central: acción
    • Administración de sustancias: acción

    Uso concreto de OpenEHR: Open EHR-Gen Framework

    En un año de trabajo, junto a mi colega Leandro Carrasco, hemos desarrollado una herramienta que implementa el modelo de información de OpenEHR. Esta herramienta toma arquetipos, o sea conceptos clínicos particulares, y genera automáticamente las pantallas de registro para que los médicos ingresen datos. También genera automáticamente las estructuras de información que se deben almacenar en la base de datos, a partir de los datos ingresados por los médicos. Además, valida automáticamente los datos ingresados por los médicos, contra las restricciones definidas en los arquetipos.

    En definitiva, es un sistema de información para la salud, que se genera automáticamente a partir de lo que los médicos definan en los arquetipos. Este tipo de herramientas nos permite pensar en otras formas de construir los sistemas de información para el ámbito de la salud, en formas que se adapten a lo que el médico realmente necesita.

    Además de que estamos hablando de sistemas dinámicos, que no necesitan cambios antes nuevas necesidades de registro por parte de los médicos. Son ellos quienes definen le registro a partir de los arquetipos. Estamos hablando de enormes ahorros potenciales tanto en tiempo como en dinero.

      Lo malo en OpenEHR:

      Esta es la sección donde me pongo duro con la crítica. Hasta ahora no he mencionado nada "malo" de este estándar, y hasta parece una excelente solución para muchos de los problemas que nos enfrentamos día a día quienes construimos sistemas de información en salud. La verdad es que OpenEHR agrega un montón de conceptos que realmente nos ayudan, pero nada es gratis.

      El proceso

      Vimos que el proceso de desarrollo puede simplificarse, en la medida de que los médicos, enfermeras y técnicos (expertos en el dominio clínico) definan sus necesidades mediante arquetipos. Para esto es necesario una capacitación, la cual no todos estarán de acuerdo en hacer. Muchos querrán seguir expresándole sus necesidades a los analistas informáticos. Esto es un problema, no directamente de OpenEHR, pero si de su aplicación práctica.

      Por otro lado, se necesita un proceso definido y controlado en cuanto a la creación corrección y actualización de los arquetipos. Si los médicos empiezan a definir sus arquetipos sin control, muchas veces se llegarán a inconsistencias. Por ejemplo, es necesario un comité médico que evalúe la calidad del arquetipo y que proponga mejoras, antes de integrarlo al registro médico. Una cosa que puede pasar es que un médico defina en parte de un arquetipo, un concepto clínico que ya está modelado con un arquetipo, en lugar de reutilizar el arquetipo existente.

      Limitaciones de los arquetipos

      Los arquetipos son buenos para expresar estructuras de información y restricciones puntuales sobre esa información, pero no es suficiente para expresar restricciones complejas como: si es un hombre entonces no puede estar embarazado. Las restricciones complejas pueden referenciar a varios conceptos clínicos (arquetipo) y no pueden ser definidas dentro de un arquetipo, por lo que se debe buscar una estructura de mayor nivel donde definirlas.

      Esto en sí no es un problema de los arquetipos, si no que los arquetipos no fueron diseñados para expresar esas restricciones complejas, que en cambio, si necesitamos en la práctica. Lo bueno es que teniendo los conceptos clínicos formalizados mediante arquetipos, la definición de esas restricciones complejas puede hacerse de forma sencilla, referenciando a esos arquetipos y sus nodos internos.

      Actualización de las herramientas

      Si bien la comunidad de OpenEHR provee un conjunto de herramientas libres y gratuitas, estas presentan algunos problemas que no parece que puedan ser solucionados a corto plazo. Obviamente, detrás de las herramientas hay personas, que muchas veces utilizan su tiempo libre en corregir y actualizar las mismas, y no reciben remuneración por hacerlo. Por un lado, es difícil exigirle algo a alguien en este esquema. Por otro lado, que estos proyectos queden estáticos, dificulta la introducción de nuevos adeptos al estándar, por que los desanima al momento en que prueban una herramienta y encuentran un problema.

      La clave es que al ser herramientas de código abierto, la comunidad debería participar en mejorar y actualizar el código, tal como pasa con otros proyectos de código abierto. Pero esto no está pasando con las herramientas de la comunidad de OpenEHR. Muchos esperamos que otro solucione los problemas y nos sentamos a ver que pasa. Este es un problema más de la comunidad que del estándar en sí.

      Estándar no oficial (de facto)

      OpenEHR no es respaldado por una organización como ISO o ANSI, organizaciones creadoras de estándares respetadas en el mundo, por lo tanto OpenEHR es visto por los burócratas como un estándar no formal, o simplemente como que no es un estándar. DICOM también es un estándar abierto, pero es soportado por toda la industria en el área de diagnóstico por imágenes, lo cual lo hace el "estándar de facto" en el área de la imagenología digital. Tal vez, con mayor soporte de la industria, OpenEHR pueda ser el "estándar de facto" para crear sistemas de información en salud.


      Conclusión

      OpenEHR es un muy buen estándar y propone soluciones a problemas reales. Su aplicación puede tener serias dificultades, pero con un retorno de inversión potencial enorme. Requiere si un cambio cultural, tanto en los médicos como en los informáticos, ya que requiere cambiar (mejorar) el proceso de creación de los sistemas de información en salud. Y muchos de los problemas que hoy tiene la difusión y adopción del estándar, son debido a una comunidad que pide más de lo que da, y como en el mundo nada es gratis, es bueno que si tomamos algo del estándar, aportemos algo a la comunidad: creando una herramienta, corrigiendo las que ya existen, difundiendo el estándar entre otros, haciendo cursos, exponiendo en congresos, creando sistemas basados en el estándar, publicando artículos en blogs, etc.


      Para ternimar, los invito a participar en el grupo de discusión en español sobre OpenEHR: http://groups.google.com.uy/group/openehr-es

      11 de octubre de 2010

      Serie de articulos sobre estandares

      En este momento estoy armando una serie de artículos enfocados al análisis crítico y las posibles aplicaciones de los distintos estándares existentes para la creación de sistemas de información en salud.

      La idea es que sean resúmenes en lenguaje de alto nivel (tratando de dejar lo técnico de lado) y que toquen los principales objetivos, usos y problemas que tienen los estándares como:
      • OpenEHR (modelos, gestión del conocimiento clínico)
      • HL7 v3 (mensajería, modelos)
      • CDA (documentos clínicos CDA)
      • ISO 13606 (documentos clínicos)
      • CCR/CCD (continuidad del cuidado)
      • IHE (perfiles de uso de HL7 y DICOM)
      • DICOM (imagenología)
      • CIE, CIAP, LOINC, ... (clasificaciones)

      Lo que buscará esta serie es saber:
      • primero de qué estamos hablando realmente cuando decimos "OpenEHR" o "HL7"
      • qué estándar sirve para resolver qué problema
      • cómo aplicar varios estándares en un mismo sistema de información
      • fomentar la discusión y difusión de estos y otros estándares

      Esto servirá de introducción para luego si tocar temas más técnicos.

      12 de septiembre de 2010

      Aumento en la calidad de datos patronimicos 2: heuristicas

      Introducción

      En un artículo previo, he definido un algoritmo para detectar el Índice de Coincidencia (IC) entre dos identidades de personas. Estas identidades están formadas por un conjunto de datos arbitrario, como nombres, apellidos, sexo fecha de nacimiento, etc. En el artículo previo, no se especificó cómo eran seleccionadas las idendidades a ser comparadas. En este artículo la idea es definir los conceptos que permitan entender las distintas formas de pre-selección de identidades de forma que las comparaciones no tarden años en ejecutarse, y a la vez permita detectar la mayor cantidad de registros duplicados en una base de datos.


      Objetivo

      El objetivo final del cálculo del IC entre dos identidades es poder encontrar posibles duplicados en los registros de las personas (sobre todo entre los pacientes). Una vez que se encuentran dos o más registros duplicados, se procede a la unión de esos registros. Esto es esencial para garantizar que los procesos de identificación de personas (en el ámbito de la salud) funcionen correctamente, y para garantizar que el registro clínico se realiza para la persona correcta, y que todos los registros clínicos de esa persona están asignados a una única identidad (si la persona tiene más de una identidad, por tener registros de identidades duplicadas, su información sanitaria estará fragmentada, o sea siempre será incompleta).

      Entonces, es necesario ejecutar el algoritmo que detecta coincidencias tomando y comparando de a 2 los registros de las personas en la base de datos de pacientes de una o múltiples instituciones sanitarias. El problema es que si en una base de datos con 1000 pacientes se hacen comparaciones de a 2, se terminan haciendo 1.000.000 (1M) comparaciones. Tal vez 1M comparaciones no sea un gran problema, pero ¿qué pasaría si la base de datos tuviera 1M registros de pacientes?, ¡las comparaciones se disparan a un millón de millones!. En este caso, si cada comparación tarda unos 3 segundos, el total de las comparaciones tardarían unos 95129 años aproximadamente.

      El objetivo es claramente bajar ese tiempo de ejecución, pero a la vez garantizar que se encontrarán todos los duplicados en las identidades persentes en la base de datos.

      Para lograr esto es necesario disminuir la cantidad de registros a comparar de 2 en 2, por lo que previamente a ejecutar la comparación entre 2 identidades, ejecutaremos una heurística que permita preseleccionar todas las identidades que deben compararse, siendo esta cantidad mucho menor a la cantidad de identidades de personas guardadas en la base de datos.

      Debe quedar claro que el único método que garantiza que se encuentran todos los duplicados en una base de datos es comparar 2 a 2 todos los registros de la base, cosa que, como ya mencionamos, es impracticable en bases de datos con muchos registros.

      La heurística con la que se consigan encontrar todos los duplicados, será la heurística óptima, pero ninguna heurística puede garantizar esto para cualquier base de datos con identidades de personas. O sea, que la los resultados de aplicar la heurística para preselección de registros, depende de la base de datos. Profundizaré sobre este concepto más adelante.


      Metodología

      El objetivo de las heurísticas es obtener conjuntos de registros de identidades que "se parecen en algo", pero sin necesidad de ejecutar el Algoritmo de Verificación de Identidades (AVI) para calcular el Índice de Coincidencia entre las identidades. A estos conjuntos de identidades "parecidas" les llamaremos "Clases de Preselección" o solo "CP". De este modo, las compararciones de a 2 identidades usando el AVI, se hacen solo sobre las identidades de cada CP, no sobre todos los registros de identidades.

      A continuación voy a mostrar el camino lógico que seguí para ir de una comparación de 2 en 2 sobre todos los registros de una base, hasta la solución final encontrando algunas heurísticas por "sentido común", que luego fueron probadas y funcionaron correctamente.

      El peor caso empieza teniendo que comparar todas las identidades de la base, de 2 en 2. Esto se puede representar en un cuadro de doble entrada, donde cada par de entradas señalan una comparación a realizar. En la fig. 1 se puede apreciar este cuadro, y como se realizan todas las comparaciones de 2 en 2, aparece todo pintado de verde (este color indica las comparaciones a realizar).

       Fig. 1: cuadro de comparaciones inicial


      La primer optimización es que si se compara la identidad A con la identidad B, no es necesario hacer la comparación de B con A, por lo que se reducen las comparaciones a algo menos que la mitad, ya que también se evitan las comparaciones de A con A, B con B, etc. En la fig. 2, las comparaciones se hacen solo sobre la mitad de los registros.

      Fig. 2: se comparan solo la mitad de las identidades


      Esta primer optimización reduce la cantidad total de comparaciones pero no cambia el orden o la magnitud de comparaciones a realizar, es decir, si antes había que hacer millones de comparaciones, ahora hay que hacer millones/2. Por lo que si antes tardábamos más de 95000 años en hacer las comparaciones de 1M registros, ahora tardaremos más de 47000 años, cosa que sigue siendo impracticable.

      Bien, ahora ¿qué pasaría si tuviéramos algo que nos dijera que comparaciones hacer antes de hacerlas?, podríamos bajar el número total de comparaciones y llevar el tiempo total de ejecución a algo razonable. Hacer esto implica que debemos agrupar identidades "parecidas" pero sin calcular el IC, ya que eso nos llevaría de nuevo al problema inicial. La idea es que el algoritmo que agrupe entidades parecidas en Clases de Preselección, también sea un algoritmo rápido. O sea que el tiempo total de hacer la preselección, más el tiempo total de calcular el IC entre 2 identidades, para todas las identidades de cada CP, sea muchísimo menor al tiempo total de ejecución de la primer optimización que se muestra en la fig. 2.

      La idea es bien fácil, primero hay que definir el criterio por el cual se agrupan las identidades en las Clases de Preselección. Los criterios que he utilizado en mis pruebas son:
      1. Agrupar por primer letra del primer nombre
      2. Agrupar por primer letra del primer apellido
      3. Agrupar por fecha de nacimiento:
        1. Total: día, mes y año (no sirve si las fechas tienen errores en alguno de sus 3 campos)
        2. Parcial: solo día y mes, o solo mes y año (es más fuerte ante errores en algún campo de la fecha)

      Para el criterio 1, lo que se hace es ordenar todas las identidades por primer nombre y tomar de a X identidades con X arbitrario, tomando como CPs por los registros 1..X, X+1..2X, etc., de esta forma cada CP tendrá solo X registros, siendo X mucho menor a N, con N la cantidad total de registros. Con N=1M y X=200, las comparaciones totales serían 5000 x 200^2 / 2 = 100M (en lugar de 1M de millones!). Igualmente este ejemplo, con cada comparación hecha en 3 segundos, tardaría unos 9 años. Si varía X, se podrá variar la cantidad total de comparaciones necesarias. Obviamente el tiempo de comparación de 2 registros dependerá de la velocidad del hardware y de lo complicado que sea el algoritmo de comparación entre 2 identidades.

      En la fig. 3 se visualizan las comparaciones a realizar usando Clases de Preselección. Las flechas indican que hubo un ordenamiento de los registros según algún criterio. Se puede ver claramente que la cantidad total de comparaciones disminuye de forma considerable.

      Fig. 3: primer aproximación para encontrar Clases de Preselección


      De forma análoga se pueden aplicar otros criterios y obtener CPs alternativas. Un potencial problema es que los registros tengan errores y esos errores repercutan en el criterio que se use para crear las CPs. Por ejemplo, si se usa el criterio de tomar de a X identidades, tal que estén ordenadas por la primer letra del primer nombre, si existen muchos primeros nombres con error de registro en la primer letra, un potencial duplicado puede no ser detectado, ya que las identidades con error en la primer letra del primer nombre van a parar a otra CP. Con esto fundamentamos una afirmación hecha previamente: la heurística o criterio que se utilice para crear las CPs depende de cada base de datos, porque depende de los errores que haya en el registro.

      Para conseguir una heurística fuerte ante los errores más comunes en nuestros registros, se pueden optar por dos estrategias:
      1. Hacer un estudio estadístico de los errores más comunes en el registro
      2. Utilizar más de una heurística para calcular los ICs entre las identidades

      En mi caso opté por la segunda estrategia. Lo que hice fue calcular el IC para los registros de cada CP creada a partir del criterio de "primer letra del primer nombre", pero luego calculé de nuevo el IC para los CPs creados a partir del criterio "primer letra del primer apellido", de esa forma las comparaciones que se me escaparon en la primer vuelta, por tener errores en el primer nombre, en la segunda vuelta, utilizando el criterio por primer apellido, logro que se comparen. Obviamente, un registro puede tener errores en el primer nombre y en el primer apellido, pero la probabilidad de que esto suceda es menor de que un registro tenga error en el primer nombre o en el primer apellido.

      Existe una optimización a este tercer paso, debido a un problema que presenta en los límites de las CPs. Ya que si se ordenan los registros y se toman 2 CPs contiguas, es problable que los últimos registros de la primer CP se parezcan a los primeros registros de la segunda CP, y al no considerar esto, estamos perdiendo duplicados potenciales. Para cubrir esto, lo que se hace es solapar un poco las CPs, así la primer CP calcula el IC entre sus identidades, pero también incluye a las primeras identidades de la segunda CP. En la fig. 4 se muestran las CPs solapadas para evitar que se escapen duplicados en los límites de las CPs.

      Fig. 4: Clases de Preselección solapadas para incluir comparaciones de casos límite


      Otras heurísticas pueden crearse en base a los datos disponibles, y usarse de forma coplementaria para no dejar registros parecidos afuera de las comparaciones.


      Conclusiones

      Es necesario crear alguna heurística que permita preseleccionar los registros que luego se van a comparar de 2 en 2, para así bajar los tiempos totales de ejecución.

      Vimos que el éxito las heurísticas depende de los errores que se tengan en los registros de datos personales, por este motivo, antes de aplicar una heurística cualquiera para encontrar las CPs, es útil estudiar la base de datos para determinar cuáles son los errores más frecuentes y en cuáles datos. De este modo, podemos encontrar heurísticas que sean fuertes ante esos errores, permitiendo encontrar la mayor cantidad de duplicados posible.

      Acompañando a las heurísticas se pueden usar otros métodos para acelerar las comparaciones entre las identidades de cada Clase de Preselección. Por ejemplo, el uso de programación paralela, donde distintos CPs puedan ser procesados en simultáneo, permite acelerar un poco las comparaciones totales, aunque no disminuye el orden de las comparaciones. Por ejemplo, si cada CP tiene 250 identidades, y cada comparación tarda 3 seg., las comparaciones para cada CP serán unas 250*250/2 = 31250 y tardarán unas 26 horas. Si se tienen 4 procesadores en paralelo, el tiempo total de ejecución bajará a unas 6,5 horas.


      Espero que se haya entendido la idea, si no, comentan abajo y lo explicamos mejor.