Mostrando entradas con la etiqueta sistemas de informacion clinicos. Mostrar todas las entradas
Mostrando entradas con la etiqueta sistemas de informacion clinicos. Mostrar todas las entradas

17 de julio de 2019

Curso de Modelado de Información Clínica con openEHR

Curso de Modelado de Información Clínica con Arquetipos y Plantillas openEHR 2a ed.

Del 12 de Agosto al 8 de Septiembre de 2019. Organizan ACHISA y CaboLabs



Abrimos las inscripciones a la segunda edición online del Curso de Modelado de Información Clínica con openEHR. Se recibirán inscripciones hasta el 9 de Agosto de 2019.

El objetivo del curso es ganar experiencia en el Modelado de Información Clínica para los sistemas de información, utilizando la metodología formal propuesta por el estándar openEHR, basada en Arquetipos y Plantillas. Utilizaremos herramientas de modelado para crear nuestros propios Arquetipos y Plantillas, y veremos todos los pasos necesarios para crear modelos clínicos a ser utilizados en software.

Este es el primer curso de Modelado de Información Clínica en Español, que se brinda 100% online. Este curso complementa los otros cursos diseñados por CaboLabs sobre openEHR, como el curso de Fundamentos de openEHR, Diseño de bases de datos clínicas openEHR, y el curso de Implementación de Sistemas de Información en Salud con openEHR (más info: https://www.cabolabs.com/educacion). En CaboLabs contamos con más de 13 años trabajando con el estándar openEHR.

El curso comenzará el 12 de Agosto de 2019. Las sesiones virtuales sincrónicas serán los días 13, 20, 27 de Agosto y 3 de Septiembre. Tendrán una duración aproximada de entre 2 horas (incluye espacio para consultas).

En el Formulario de Inscripción encontrarás las instrucciones para realizar el pago y así confirmar tu inscripción. Si tienes alguna duda, consulta en info@cabolabs.com


Formulario de inscripción: https://goo.gl/forms/WRRXWlTDbX1bcqWL2


Resumen de temas:
  • Mapas mentales y UML como técnicas de análisis y modelado 
  • Rol del modelador clínico en proyectos de sistemas de información en salud 
  • Modelo de información de openEHR 
  • Proceso de modelado de arquetipos 
  • Clasificación de conceptos clínicos 
  • Herramienta: Clinical Knowledge Manager 
  • Herramienta: Archetype Editor Actividades de creación de arquetipos y plantillas 
  • Ciclo de vida de los arquetipos 
  • Validación técnica de arquetipos 
  • Uso de plantillas en software (registro de información clínica)

En nuestra página de educación se encuentra el programa completo.

Valores de inscripción:
  • Inscripción Normal 200 USD
  • Socio activo ACHISA * 150 USD 

* Hágase socio de ACHISA para contar con estos y otros beneficios: https://www.achisa.cl/inscripcion-como-socio/


Les agradecemos la difusión del workshop entre sus contactos. Consultas: pablo.pazos@cabolabs.com Aquí puedes encontrar más información sobre otros cursos y workshops de interoperabilidad, estándares (HL7, DICOM, openEHR) y tecnologías: https://cabolabs.com/educacion/


Organizan

https://www.achisa.cl/

https://cabolabs.com/



Apoyan
https://www.spis.org.py/
https://www.veratech.es/

2 de enero de 2012

Nuevo Open EHRGen v0.7

Estoy muy contento de anunciar la liberación de la nueva versión de Open EHRGen, la herramienta para crear Historias Clínicas Electrónicas estándar, basadas en la gestión del conocimiento clínico.

Descarga: http://code.google.com/p/open-ehr-gen-framework/downloads/list
Instalación: http://code.google.com/p/open-ehr-gen-framework/wiki/Instalacion


¿Qué es EHRGen?

No es un software de EHR, es un framework que permite crear uno.

Con la ventaja de que es genérico y está diseñado para soportar cualquier estructura de registro clínico, desde un registro simple completamente en texto libre, hasta un registro completamente estructurado y tan complejo como sea necesario.

Para ajustar los registros clínicos no es necesario modificar el código fuente de EHRGen, todo se hace por fuera del software y la integración es por configuración. Los registros clínicos se representan mediante templates, que utilizan conceptos clínicos representados como arquetipos openEHR. Los arquetipos permiten modelar conceptos clínicos tales como la presión arterial, frecuencia cardíaca, diagnósticos, evaluación de vía aérea, administración de medicamentos, etc., definiendo su propósito y estructura interna de forma genérica, estándar y procesable por computadora (más info sobre openEHR).

Los arquetipos y templates conforman una base de conocimiento capaz de ser utilizada por EHRGen para generar pantallas de registro clínico web para los profesionales de la salud.

EHRGen es un proyecto de código abierto en pleno desarrollo, se agradece la difusión del mismo.


Principales cambios con respecto a la versión 0.6:

Búsqueda semántica

Esta es la característica más interesante de la nueva versión. La búsqueda semántica permite que un profesional de la salud realice búsquedas basadas en conceptos clínicos y sus componentes, permitiendo una agregación de datos simple.

La ventaja desde el punto de vista del software es que estas búsquedas son genéricas, basándose únicamente en los conceptos clínicos (arquetipos) y sus elementos (identificados mediante rutas). Esto repercute en que las búsquedas no necesitan ser implementadas a medida, y que si se agregan nuevos arquetipos a la base de conocimiento, se pueden realizar búsquedas en base a esos conceptos clínicos sin necesidad de ningún cambio en el código fuente de la aplicación.

En las próximas versiones se dará más flexibilidad a las agregaciones de datos y a los filtros de la búsqueda. Una que EHRGEn esté instalado y corriendo, para ingresar a la búsqueda semántica se debe ingresar a http://localhost:8080/ehr/archetypeManager/query

Para realizar una búsqueda semántica, el profesional de la salud debe seleccionar un concepto clínico en el listado de conceptos clínicos:

Búsqueda semántica: listado de conceptos clínicos


Una vez seleccionado el concepto, se deben seleccionar las rutas (paths) a los elementos de interés dentro de la estructura del concepto clínico:

Búsqueda semántica: selección de concepto "triage de trauma"


Cuando se seleccionan las rutas y se hace clic en el botón "seleccionar paths", se muestran los datos registrados en el sistema para ese concepto clínico y esas rutas, agrupadas por el registro clínico de cada paciente:

Búsqueda semántica: selección de rutas dentro del concepto "triage de trauma"


Por último, para los datos de tipo DvCodedText o DvOrdinal, es posible seleccionar los datos para agregarlos en clases. Por ejemplo, el elemento "evaluación de trauma" es DvOrdinal, y tiene 5 valores posibles, en la siguiente imagen se muestra la agregación de los registros existentes en esos valores posibles:

Búsqueda semántica: agrupación de datos para una ruta




Mejoras en el uso de templates

EHRGen utiliza los templates para generar pantallas de registro clínico. Una de las mejoras es la generación de pantallas para cualquier idioma configurado en la herramienta, esto permite reutilizar los conceptos clínicos modelados en arquetipos para crear Historias Clínicas Electrónicas estándar a nivel internacional.

Otra mejora es el versionado de templates, permitiendo evolucionar las pantallas de registro indefinidamente. Por ejemplo, si se tiene un template.v1 y se realizan registros clínicos en la pantalla generada con ese template, pero luego se requieren hacer cambios, generando un template.v2, los registros para la versión anterior del template quedan incambiados y se pueden visualizar sin problemas. Mientras que los nuevos registros se guardan utilizando el template.v2.


Mejoras con respecto a la seguridad

En la versión 0.6 se comenzó la implementación de la verificación por rol de usuario de la autorización para ejecutar acciones en el sistema. En la versión 0.7 se agrega la gestión de permisos por dominio (ambulatorio, hospitalización, emergencia, etc.) y por tipo de registro clínico (template). En las próximas versiones se culminará la implementación completa con la gestión y verificación de permisos por rol, dominio, template, acción y también por credenciales del usuario (por ejemplo especialidad de un médico).

Listado de roles

Listado de permisos para el rol Médico

Gestión de personas



Correcciones generales y mejoras

Se corrigen pequeños errores encontrados, se agregan traducciones de términos, se mejoran aspectos de interfaz de usuario, y se corrigen las rutas al filesystem en linux (gracias por reportar el problema a los usuarios de linux).



Recorrida general por la aplicación

Este ejemplo muestra a EHRGen utilizando una base de conocimiento donde está modelado el registro clínico de emergencia de trauma. Otros dominios pueden ser modelados de forma análoga, esto es totalmente configurable.

Autenticación de usuarios

Listado de dominios

Listado de registros dentro del dominio de trauma

Vista de un registro en el dominio de trauma

Registro del triage (autogenerado a partir de template y arquetipos)

Registro de evaluación del estado circulatorio (autogenerado a partir de template y arquetipos)

Selección de diagnósticos CIE-10

Búsqueda de paciente para asociar al registro clínico

Resultado de búsqueda de pacientes

Selección de paciente para el registro actual



¡Seguiremos trabajando para crear mejores EHRs!

23 de septiembre de 2011

Nueva version de OpenEHR-Gen Framework

Estoy muy contento de anunciar una nueva liberacion de Open EHR-Gen Framework, la herramienta libre para crear sistemas de Historia Clínica Electrónica basados en estándares internacionales como openEHR, HL7 CDA y CIE 10.

La nueva versión 0.6 está disponible para la descarga aquí: http://code.google.com/p/open-ehr-gen-framework/downloads/list

 OpenEHR-Gen Framework es 100% código abierto y gratuito. Se agradece la difusión del mismo. 

¿Qué quiere decir esto? Que cualquiera puede bajar el código, probarlo, modificarlo, hacerle mejoras y adaptaciones a la realidad de cada institución sanitaria, y podrá contribuir con el desarrollo en comunidad de la herramienta.

¿Qué valor ofrece este proyecto? ¿Qué lo hace distinto?

En el corazón de la herramienta están considerados aspectos de estandarización que aportan a la interoperabilidad del sistema con cualquier otro sistema externo (farmacia, laboratorio, imagenología, sistemas administrativos, etc).
Otro diferenciador es la orientación a la gestión del conocimiento clínico, a través del uso de arquetipos openEHR como especificación del contenido del registro clínico. Ver más sobre arquetipos en el gestor de conocimiento clínico: http://www.openehr.org/knowledge. ¿Esto en qué te beneficia? En el el proceso de desarrollo de software es independiente del proceso de especificación del contenido clínico, y el resultado es un mejor proceso global, una herramienta de software más ligera y adaptable, y el control completo del contenido clínico por parte de los médicos.
Por último, está desarrollado sobre tecnologías web de nivel empresarial de última generación, como ser Grails, Groovy y Java.

Principales cambios con respecto a la versión anterior (*):
  • Reescritura completa del generador de interfaces de usuario, con gran aumento de performance.
  • Se agrega un gestor de usuarios y de roles.
  • Se modifica el modelo de datos persistentes para simplificarlo y mejorar performance de lectura-escritura de la base de datos.
  • Se sustituye librería javascript Prototype por jQuery. Con jQuery se implementa parte de la nueva generación de interfaces de usuario.
  • Se hacer varias correcciones y mejoras al componente data binder.
  • Se cambia un poco el estilo de la interfaz de usuario.
(*) Aquí se puede ver más información sobre la versión anterior, y puedes encontrar presentaciones y documentos sobre el proyecto.


Algunas capturas de pantalla de la nueva versión (clic para ver en grande):

Ingreso al sistema

 Selección de dominio
Ingreso a dominio de trauma

Registro en dominio de trauma

Registro de triage en trauma

Registro de triage almacenado

Evaluación primaria de trauma: vía aérea

Evaluación primaria de trauma

 Evaluación primaria de trauma

 Evaluación primaria de trauma

 Evaluación primaria de trauma: disfunción neurológica

 Búsqueda de paciente para asociar al registro clínico

Resultado de la búqueda

Registro clínico con paciente seleccionado


 Gestión de personas

 Detalle de una persona


Listado de roles

Detalle de un rol

 Edición de permisos de un rol

 Rol con permisos guardados


Como siempre, todas las preguntas y comentarios son muy bienvenidos.

30 de agosto de 2011

Gestion de proyectos de informatizacion en salud

La informatización en el área clínica es un camino que muchas instituciones sanitarias están emprendiendo a nivel mundial. Este camino no es sencillo, está lleno de obstáculos, problemas, desentendimientos, expectativas incumplidas y proyectos fallidos.

Es este contexto tan hostil, ¿existirá alguna metodología o proceso que nos acerque al éxito o nos aleje del fracaso?. El objetivo de este artículo es dar mi opinión personal sobre algunas "áreas sensibles" que los gestores de proyectos deberían cuidar para que "el bote no haga agua".

Algunos de estos puntos podrán coincidir más o menos con los métodos y estrategias usados por los gestores de proyectos, y deberían considerarse como la humilde opinión de alguien que observa y analiza la realidad (de cerca), no como una solución a todos los problemas. Además trato de hacer énfasis en el "qué", no en el "cómo", pero la discusión está abierta.


El proyecto debería ser solo un grano de arena

El proyecto de informatización debe ubicarse en una estrategia organizacional de mejora, el proyecto no debería ser la estrategia, sino un resultado de esta.
Tener claro este punto facilita que el apoyo de los tomadores de decisión de la institución se haga visible, y ubica al proyecto en un lugar de la agenda institucional. De lo contrario, el apoyo se hace esquivo, y no se tiene una puerta donde ir a tocar cuando hay problemas a nivel de la institución.


La informatización es un camino solo de ida

Junto a la planificación de las distintas etapas de desarrollo e implantación de las soluciones informáticas en el área clínica, debería planificarse la estrategia de eliminación del papel de los procesos clínicos.
Dejar "vivo" al papel es atentar contra el uso de los productos del proyecto.


Evitar el proyecto de duración infinita

Todo gestor de proyectos sabe que un elemento característico de éstos es que tienen una fecha de fin.
Esa fecha de fin debería ser fija e inamovible, y se debería tener claro qué es lo que se va a entregar y qué es lo que no. Tres factores se debe tener en cuenta siempre: el alcance (cantidad y complejidad de necesidades a satisfacer), la calidad (cantidad de ciclos de mejora sobre una necesidad satisfecha) y el tiempo (demora en satisfacer una necesidad o de mejorar la forma en la que esta es satisfecha). Se dice que tenemos 3 balas y solo podemos disparar 2, por ejemplo un proyecto con un alcance muy grande y con gran calidad, requerirá mucho tiempo en desarrollarse. Otra posible combinación es que si tenemos poco tiempo y un alcance fijo, no podemos pedir mucha calidad. La regla general es que si aumentamos alcance, calidad o tiempo, aumenta el costo/presupuesto.
Siempre hay aspectos que pueden mejorar, y siempre habrá tiempo para mejorarlos, pero sobre la entrega de los productos no podemos empezar procesos de mejora. Es mucho mejor para el proyecto, para el proveedor y para el cliente: 1. entregar lo pactado, ni más ni menos; 2. aceptar lo que se debe entregar; 3. cerrar el proyecto; 4. sentarse a pensar en mejoras (...y ver si queda algo de presupuesto).


Las expectativas y la comunicación son también elementos a gestionar

Luego de fijar el alcance del proyecto, los clientes y los usuarios finales deberían saber qué es lo que se va a entregar y cuándo. Esto incluye el saber que es lo que NO se va a entregar.
La comunicación de estos elementos se debería hacer en cada oportunidad que se tenga, y si no se dan estas oportunidades, se deben crear. Por otro lado, todos los usuarios finales (sobre todo los médicos) tienen una idea de lo que quieren, y todos se imaginan que el producto será exactamente como ellos lo imaginan. Para evitar desilusionar a estos usuarios (riesgo a rechazo del producto), se debe dar una imagen clara del producto, de lo que tendrá y no tendrá, y bajar o subir las expectativas al nivel correcto. Esto también debería hacerse en todas las oportunidades que se tengan.


Contraparte es algo más que once letras

Sin contraparte no existe proyecto. Si somo un proveedor de software, la contraparte está formada por los tomadores de decisión, los usuarios finales y el staff informático del cliente. El cliente debe ser comunicado claramente de que para que el proyecto sea un éxito, se necesita tiempo de trabajo de los recursos humanos de la institución: médicos, enfermeras, técnicos, informáticos, etc.
Una forma de que el cliente tome conciencia de esta necesidad es que sepan claramente cómo será el proceso de desarrollo e implantación de los productos del proyecto, y que en cada una de esas etapas se requerirá la participación de ciertos roles claves, que necesitan un tiempo asignado a esas tareas, y que deberán dejar de hacer otras tareas que hoy tienen asignadas.
Este punto es tan obvio que muchas veces los gestores lo pasan por alto, y como consecuencia se pierde tiempo por no contar con alguien del otro lado a quien hacerle preguntas o con quien discutir posibles soluciones a los problemas que el propio cliente plantea.


Mantener las audiencias y el interés es un gran punto a favor

En los proyectos de informatización en salud se tienen dos grandes audiencias: los tomadores de decisión y los usuarios finales. Es frecuente que por la poca visibilidad del proyecto y sus avances, por la poca comunicación, o a veces por la duración tan prolongada de estos proyectos, las audiencias que antes nos apoyaban, aportaban y se interesaban por el proyecto, ya no están tan interesados.
Perder el interés de las audiencias, es perder apoyo y ganar resistencia, lo que es un gran punto en contra para el proyecto. El interés es otro punto a gestionar y cuidar, porque hay que recuperarlo antes de que sea demasiado tarde, por ejemplo: que se entregue el producto y nadie lo use.
A los gestores les gusta saber que se tienen productos listos, y a los usuarios les gusta dar su opinión y ver como esta repercute en el producto que van a usar. Ellos debe participar en todas las etapas del proyecto!.


El proyecto informático médico

La informática es un camino para lograr un objetivo, no debería ser considerado como el objetivo en si.
Tanto los tomadores de decisiones como los usuarios finales no deberían hablar de bases de datos ni servidores, con ellos y a ellos siempre se les debería hablar en un plano médico de usos y funcionalidades que soportará la herramienta. Como estrategia general, el proyecto debería presentarse como un proyecto médico, no un proyecto informático.


El paradigma del hiper-mercado vs. las pequeñas tiendas especializadas

Existen dos formas de encarar los proyectos de informatización en salud. El primero y más frecuente, es el de una gran herramienta centralizada, con una única base de datos, que provee soporte a diferentes sectores y diferentes usuarios. Donde los requisitos y necesidades de cada uno de estos sectores y usuarios es esencialmente distinto al de los demás. Este tipo de proyectos suele ser desarrollado en un largo período de tiempo, lo que contribuye a la pérdida de interés que mencioné antes. Este producto es el hiper-mercado.
Por otro lado, está el enfoque de partir el "problema" en pedazos, el clásico "divide y vencerás" (que muchas veces olvidamos al gestionar proyectos). La idea es desarrollar pequeñas herramientas, especializadas a cada sector o tipo de usuario, y con independencia de las demás herramientas, sectores y usuarios. Este tipo de herramientas son más sencillas de desarrollar, tienen un público objetivo acotado, un tiempo de desarrollo más pequeño, y por lo tanto un riesgo menor de fallar como proyecto. Por otro lado, este enfoque agrega un elemento nuevo: es necesario pensar en estándares e interoperabilidad para que estas herramientas puedan compartir información para lograr una verdadera sinergia. Estas son las pequeñas tiendas donde cada uno encuentra exactamente lo que quiere y necesita.
Este segundo es mi enfoque preferido, ya que como gestores nos permite concentrarnos en un elemento acotado a la vez, y nos permite hacer lo mejor en cada uno, a la vez que no perdemos de vista el proyecto global.


El éxito del proyecto no debería medirse en cantidades de usuarios o registros

Muchos gestores, para mostrar el éxito de sus proyectos muestran resultados numéricos como la cantidad de usuarios, la cantidad de registros clínicos, la cantidad de prescripciones electrónicas que fueron hechas, etc.
Si bien esos valores nos sirven para medir niveles de uso (cosa que se debe hacer frecuentemente), el éxito de un proyecto no se debería medir en esos términos, sino que debería medirse en los términos de "cómo ayudaron los productos del proyecto en alcanzar os objetivos organizacionales (tanto clínicos como de gestión)". Recordemos que estos proyectos son herramientas para lograr objetivos, y que sin estrategias organizacionales y objetivos de mejora estos proyectos no existirían. Por lo tanto deberíamos preguntarnos cosas como: con estas herramientas ¿cómo se aumenta la calidad de la asistencia a los pacientes? o ¿cómo se mejora el uso de recursos limitados?


Como siempre: ¡sus comentarios son muy bienvenidos!

Hasta la próxima.

4 de abril de 2011

Nueva version de OpenEHR-Gen Framework

Estamos muy contentos de anunciar la liberación de una versión mejorada de OpenEHR-Gen Framework, la herramienta que ayuda a crear sistemas de Historia Clínica Electrónica usando estándares internacionales como openEHR, HL7 CDA y CIE 10. La nueva versión está disponible aquí: http://code.google.com/p/open-ehr-gen-framework

Lo interesante (o distinto) de este proyecto, es que todo el registro clínico es generado de forma dinámica y "al vuelo", en base a arquetipos que modelan conceptos clínicos (presión arterial, escala de Glasgow, frecuencia respiratoria, etc), y plantillas que indican cómo se debe mostrar cada formulario. Tanto los arquetipos como plantillas pueden ser definidos por el equipo de salud, y la herramienta genera el registro a partir de lo que ellos definen, sin necesidad de programar. 

OpenEHR-Gen Framework es 100% código abierto y gratuito. Se agradece la difusión del mismo.

Aquí se pueden descargar algunas capturas de pantalla de la historia clínica del dominio de trauma: http://www.subirfacil.com/files/1BIEYWYQ/capturas_openehr-gen.zip

Este proyecto fue concebido desde nuestra tesis de grado, el cual también tenía integración del estándar DICOM (integración con imagenología digital) y de la especificación IHE PDQ (consulta de datos demográficos): http://informatica-medica.blogspot.com/2010/12/documentacion-de-mi-pr...

Algunas presentaciones y documentos sobre el proyecto que pueden ser de interés:

Los principales cambios con respecto a la versión anterior son:
  • Actualización del framework de desarrollo: Grails Framework de v1.1.1 a v1.3.7
  • Agregamos la implementación de la clase Folder del modelo de referencia de openEHR. La usamos para modelar distintos dominios de registro como "emergencia", "ambulatorio", "prehospitalario", etc., los registros de cada dominio van al mismo Folder.
  • Se mejoró el diseño de la interfaz de usuario para que sea más compacta, y se mejoró la generación dinámica de la interfaz de usuario.
  • Se agregó soporte a la directiva de interfaz de usuario "type=smallText" para los templates, que sirve para mostrar inputs de texto pequeños para los nodos DvText de los arquetipos. Antes se mostraban controles textarea/memo para todos los DvText aunque fueran para ingresar textos pequeños.
  • Se cambió el cierre del registro clínico por verificación dinámica de condiciones, ahora el registro debe ser explícitamente cerrado y firmado por el médico. Esto da mayor flexibilidad para la definición de nuevos tipos de registros.
  • Se agregó la validación de restricciones de ocurrencias sobre nodos de tipo ITEM_SINGLE, que no estaba implementado. Se corrigieron errores pequeños y se limpió el código.

Cualquier consulta o comentario es todo bienvenido.
Estamos completamente abiertos a la  colaboración.

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!

    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.