En este momento me encuentro preparando algunos trabajos para presentar en el CAIS (http://www.39jaiio.org.ar/cais). Quedan gratamente invitados a las charlas:
Miércoles 1 de setiembre de mañana:
Presentación de mi proyecto de grado de la carrera de Ingeniería en Computación
Traumagen, historia clínica electrónica de trauma, con acceso a estudios imagenológicos digitales.
Temas principales: aplicación de estándares a una HCE, OpenEHR, DICOM, HL7 CDA, CIE 10.
Jueves 2 de setiembre depués del mediodía:
Tutorial sobre OpenEHR
Temas principales: objetivos del estándar, OpenEHR como arquitectura de sistemas de HCE, modelo dual: el conocimiento clínico por fuera de la aplicación de software, el modelo de información clínica y los arquetipos. Será teórico-práctico, viendo primero algunos conceptos y luego probando herramientas.
Saludos y espero poder verlos por el congreso.
19 de agosto de 2010
26 de marzo de 2010
Aumento de calidad de datos patronimicos
En el 2009 estuve trabajando sobre un algoritmo para realizar búsquedas de pacientes en un base de datos. Si bien esto es una tarea más que resuelta en muchas instituciones, el objetivo del algoritmo era no solo obtener una lista de datos de personas que se correspondieran con un criterio dado, si no detectar en cuanto se corresponden, de forma de encontrar los registros que más se parezcan a lo que buscamos.
Si bien se logró un algoritmo junto al Subcomité Técnico de Identificación de Personas (STID) de SUEIIDISS (HL7 Uruguay), del que participé en el 2009, yo me concentré en otro problema, el de la calidad de los datos. Si bien podemos pensar en cómo resolver las búsquedas de la mejor forma, si la calidad de los datos en nuestra base de datos es pobre, el resultado de la búsqueda será de poca utilidad, y si se llevara la calidad a niveles óptimos, cualquier mecanismo simple de búsqueda nos ayudaría a encontrar lo que necesitamos, por eso el cambio de enfoque. Dicho sea de paso, aquí se puede obtener una copia del documento logrado en el STID.
El resultado de mi investigación fue un algoritmo que sirve para comparar dos identidades, formadas por los atributos: nombres, apellidos, fecha de nacimiento y sexo de una persona. Cualquier tipo de identificador de la persona no forma parte de su identidad, por eso no se consideran números de documentos nacionales ni otros tipos de identificadores en las identidades. El resultado del algoritmo es un número entre 0 y 1 donde 0 indica coincidencia nula y 1 coincidencia total. Un resultado de 0.85 indica que las identidades coinciden en un 85%.
Este algoritmo fue probado en bases de datos con miles de registros, y los resultados obtenidos son óptimos. Según estos experimentos, las identidades cuya coincidencia supera el 95% corresponden a la misma persona, y la diferencia se debe a que hay errores en los datos, por ejemplo un nombre mal escrito, que en base a mis experimentos, es uno de los casos más frecuentes en los de fuentes de error, por ejemplo una letra faltante o la transposición de letras son de los errores más comunes.
Detrás del algoritmo hay tres ideas muy intuitivas:
Descripción del Algoritmo de Verificación de Identidades Básico (AVI-b):
Aquí voy a bajar a un nivel muy técnico, igualmente voy a ir explicando los detalles para que nadie pierda el hilo.
La identidad mínima de una persona, como mencioné antes, está formada por los atributos: nombres, apellidos, sexo y fecha de nacimiento. Vamos a tomar dos identidades id1 e id2 para compararlas según el AVI-b.
Como se mencionó, una de las ideas detrás del algoritmo es que, cada atributo de la identidad tiene un peso distinto en cuanto a la identificación de la persona. A continuación se especifica el peso de cada atributo en la identificación, donde la regla que deben cumplir estos valores es que deben sumar 1, porque si se tienen todos los atributos de la identidad, estos sirven para identificar a la persona en un 100%. Esto se traduce a que si el peso del primer nombre es 0.175, quiere decir que el primer nombre identifica a una persona en un 17,5%. Los valores aquí propuestos son valores encontrados empíricamente, para los cuales se obtuvo un buen funcionamiento del algoritmo (AVI-b).
No está de más comentar que si bien los pesos planteados para el algoritmo básico (AVI-b) son constantes, por lo expresado en las ideas que están detrás del algoritmo, para el algoritmo avanzado (AVI-a), estos pesos serían funciones que dependen del valor de cada atributo.
A continuación se especifican los algoritmos de comparación de atributos simples que se utilizan para calcular el índice de coincidencia, que es el resultado del AVI-b. Se plantean dos algoritmos distintos para la comparación de nombres y apellidos, uno para el sexo y otro para la fecha de nacimiento. El primer algoritmo para comparar nombres hace la cuenta de cuantos caracteres coinciden en valor y posición y retorna esta cantidad dividida el largo de la palabra más larga, por lo que se obtiene un resultado en el rango 0..1, con valor 1 cuando los nombres y apellidos coinciden completamente. El segundo algoritmo de comparación de nombres está basado en la distancia de Levenshtein, que calcula cuantos caracteres se le deben agregar a una palabra para hacerla coincidir con otra, por lo tanto si el resultado de Levenshtein es 0 las palabras son la misma. La el índice basado en Levenshtein va a dar resultados más altos cuando haya errores de transposición u omisión de caracteres en alguno de los nombres que se están comparando, mientras que el primer algoritmo va a dar más bajo cuando uno de los nombres que se compara tiene alguna letra de menos. Luego voy a mostrar un ejemplo de esto, así que si no se entendió, luego lo retomaremos.
// Case Insensitive Levenshtein:
// comparacion de palabras utilizando indice basado en distancia de Levenshtein
// Mas info>
// - http://www.levenshtein.net/
// - http://es.wikipedia.org/wiki/Distancia_de_Levenshteincoin_ci_levens( String a, String b)
Por último, el cálculo del Índice de Coincidencia que será resultado del AVI-b, como vemos usamos los pesos y los algoritmos para calcular la comparación de atributos simples. En el ejemplo se utiliza coin_ci_cbc como comparador de nombres, éste se podría cambiar por coin_ci_levens.
En la siguiente tabla se puede ver el comportamiento del algoritmo básico (AVI-b) probando con algunos casos donde se toma una identidad y se varía algún dato para verificar cómo esta modificación afecta al Índice de Coincidencia (IC) que obtengo como resultado. Algunas aclaraciones para poder interpretar correctamente los resultados:
Trabajo futuro:
Si bien se probó empíricamente el buen funcionamiento del Algoritmo de Verificación de Identidades Básico (AVI-b) creo que se podría ajustar aún más el resultado utilizando el algoritmo avanzado, donde los pesos se ajustan según los valores de los atributos de las identidades. Esto sería fácil de hacer si se tienen calculadas las frecuencias de nombres y apellidos de las identidades que se tienen en la base de datos donde están registradas las identidades a verificar, esto quiere decir, calcular cuántas personas tienen cada nombre (Pablo, Pedro, Juan, etc) y dividir cada una de esas cantidades entre el número total de identidades en la base. Luego esa frecuencia sería utilizada para aumentar el peso de un atributo (si es que hay poca frecuencia de ese nombre o apellido), o disminuir el peso de un atributo (si es que hay muchas personas que se llaman igual). Esta técnica ajustaría los valores resultantes de las comparaciones a un porcentaje más ajustado a la realidad. Como puede resultar obvio, los valores de frecuencias se deberían actualizar cada tanto, y con esto logramos un resultado que puede estar oculto a primera vista: el algoritmo se ajusta a las distintas frecuencias de nombres que se dan en distintos momentos. Es sabido que hay épocas donde un nombre se hace muy popular, y en algunos años el nombre más popular cambia, cambiando la frecuencia de personas que podemos encontrar con esos nombres en nuestras bases de datos. Con esto logramos un algoritmo que se adapta automáticamente (algoritmo adaptable) a cambios que se dan en la cultura de la sociedad. ¿Interesante no?
Conclusiones:
Cómo se puede apreciar en las filas 1 y 4 de la tabla de resultados, al cambiar una sola letra de un nombre o un apellido, el IC es mucho más alto usando el algoritmo ci_levens que el ci_cbc para comparar nombres, esto se debe a que el índice que se calcula en base a Levenshtein es más fuerte o se comporta mejor ante pequeños cambios. Este cambio se puede deber a un error humano en el registro, y es bueno tener un algoritmo que lo pueda detectar. Es decir que la detección de duplicados también ayuda a la detección de errores en el registro, y por lo tanto a mejorar la calidad del mismo, que es el objetivo planteado al inicio.
En las filas 2 y 5 no vemos cambio en el resultado del CI porque lo que es distinto entre las identidades es la fecha de nacimiento.
Por último, en las filas 3 y 6 vemos una pequeña diferencia en el CI, esto se debe a que el primer nombre es tan distinto entre ID1 e ID2 que tanto el índice basado en Levenshtein como el índice basado en la cuenta carácter a carácter detectan que ambos nombres son distintos, bajando el valor del CI en cantidades similares.
Espero que se hayan entendido las ideas detrás del algoritmo, cuáles eran los objetivos y que hayan quedado claras las conclusiones. Por cualquier consulta o comentario no duden en agregar un comentario.
Si bien se logró un algoritmo junto al Subcomité Técnico de Identificación de Personas (STID) de SUEIIDISS (HL7 Uruguay), del que participé en el 2009, yo me concentré en otro problema, el de la calidad de los datos. Si bien podemos pensar en cómo resolver las búsquedas de la mejor forma, si la calidad de los datos en nuestra base de datos es pobre, el resultado de la búsqueda será de poca utilidad, y si se llevara la calidad a niveles óptimos, cualquier mecanismo simple de búsqueda nos ayudaría a encontrar lo que necesitamos, por eso el cambio de enfoque. Dicho sea de paso, aquí se puede obtener una copia del documento logrado en el STID.
El resultado de mi investigación fue un algoritmo que sirve para comparar dos identidades, formadas por los atributos: nombres, apellidos, fecha de nacimiento y sexo de una persona. Cualquier tipo de identificador de la persona no forma parte de su identidad, por eso no se consideran números de documentos nacionales ni otros tipos de identificadores en las identidades. El resultado del algoritmo es un número entre 0 y 1 donde 0 indica coincidencia nula y 1 coincidencia total. Un resultado de 0.85 indica que las identidades coinciden en un 85%.
Este algoritmo fue probado en bases de datos con miles de registros, y los resultados obtenidos son óptimos. Según estos experimentos, las identidades cuya coincidencia supera el 95% corresponden a la misma persona, y la diferencia se debe a que hay errores en los datos, por ejemplo un nombre mal escrito, que en base a mis experimentos, es uno de los casos más frecuentes en los de fuentes de error, por ejemplo una letra faltante o la transposición de letras son de los errores más comunes.
Detrás del algoritmo hay tres ideas muy intuitivas:
- Distintos datos de la identidad de una persona pesan distinto en la identificación de la misma. Nuestra identidad es lo que nos diferencia de las demás personas, pero distintas partes de esta identidad puede diferenciarnos en mayor o menor medida. No es lo mismo diferenciarse por los nombres que por la fecha de nacimiento, seguramente hayan muchas más personas que nacieron el mismo día que uno, que personas que se llaman igual. Entonces cada atributo de la identidad tiene un peso asociado.
- No solo pasa que cada atributo pesa distinto en la identificación de la persona, si no que este peso en realidad debería variar dependiendo del valor de los atributos. Por ejemplo, si un apellido es muy común, el peso debería ser menor, y si es un apellido poco usual, su peso debería ser mayor. El algoritmo que considera esta afirmación se llamará "Algoritmo de Verificación de Identidades Avanzado" o "AVI-a", y no será descrito en este artículo.
- El algoritmo debe comportarse bien ante casos de errores en los datos, es decir que si se comparan dos identidades, y una tiene errores en los datos, el algoritmo debería igualmente detectar la similitud entre las identidades. Es por esto que condiciones de igualdad o igualdad parcial no son útiles para el cálculo del índice de coincidencia porque consideran a los datos como un todo o lo divide en grandes partes, es necesario llegar a un nivel de comparación con granularidad suficiente para que los errores no afecten tanto a las comparaciones.
Descripción del Algoritmo de Verificación de Identidades Básico (AVI-b):
Aquí voy a bajar a un nivel muy técnico, igualmente voy a ir explicando los detalles para que nadie pierda el hilo.
La identidad mínima de una persona, como mencioné antes, está formada por los atributos: nombres, apellidos, sexo y fecha de nacimiento. Vamos a tomar dos identidades id1 e id2 para compararlas según el AVI-b.
// Tipo que define la Identidad
Identidad {
String nom1
String nom2
String ap1
String ap2
CodigoSexo sexo
Fecha fecha_nac
}
const String MASCULINO = "M"
const String FEMENINO = "F"
const String IDENFINIDO = "UN"
// Debe ser alguna de las constantes definidas previamente
String codigo
}
// Tipo que define la el código para el sexo según la
// codificación utilizada en HL7 que se puede ver aquí:
CodigoSexo {const String MASCULINO = "M"
const String FEMENINO = "F"
const String IDENFINIDO = "UN"
// Debe ser alguna de las constantes definidas previamente
String codigo
}
// Identidades a comparar, con respectivos sus valores para cada atributo
Identidad id1 = { nom11, nom12, ap11, ap12, sexo1, fecha_nac1 }
Identidad id2 = { nom21, nom22, ap21, ap22, sexo2, fecha_nac2 }
Como se mencionó, una de las ideas detrás del algoritmo es que, cada atributo de la identidad tiene un peso distinto en cuanto a la identificación de la persona. A continuación se especifica el peso de cada atributo en la identificación, donde la regla que deben cumplir estos valores es que deben sumar 1, porque si se tienen todos los atributos de la identidad, estos sirven para identificar a la persona en un 100%. Esto se traduce a que si el peso del primer nombre es 0.175, quiere decir que el primer nombre identifica a una persona en un 17,5%. Los valores aquí propuestos son valores encontrados empíricamente, para los cuales se obtuvo un buen funcionamiento del algoritmo (AVI-b).
// Los pesos deben sumar 1
pesos[nom1] = 0.175
pesos[nom2] = 0.175
pesos[ap1] = 0.175
pesos[ap2] = 0.175
pesos[sexo] = 0.1
pesos[fecha_nac] = 0.2
No está de más comentar que si bien los pesos planteados para el algoritmo básico (AVI-b) son constantes, por lo expresado en las ideas que están detrás del algoritmo, para el algoritmo avanzado (AVI-a), estos pesos serían funciones que dependen del valor de cada atributo.
A continuación se especifican los algoritmos de comparación de atributos simples que se utilizan para calcular el índice de coincidencia, que es el resultado del AVI-b. Se plantean dos algoritmos distintos para la comparación de nombres y apellidos, uno para el sexo y otro para la fecha de nacimiento. El primer algoritmo para comparar nombres hace la cuenta de cuantos caracteres coinciden en valor y posición y retorna esta cantidad dividida el largo de la palabra más larga, por lo que se obtiene un resultado en el rango 0..1, con valor 1 cuando los nombres y apellidos coinciden completamente. El segundo algoritmo de comparación de nombres está basado en la distancia de Levenshtein, que calcula cuantos caracteres se le deben agregar a una palabra para hacerla coincidir con otra, por lo tanto si el resultado de Levenshtein es 0 las palabras son la misma. La el índice basado en Levenshtein va a dar resultados más altos cuando haya errores de transposición u omisión de caracteres en alguno de los nombres que se están comparando, mientras que el primer algoritmo va a dar más bajo cuando uno de los nombres que se compara tiene alguna letra de menos. Luego voy a mostrar un ejemplo de esto, así que si no se entendió, luego lo retomaremos.
// Case Insensitive Char by Char:
// comparacion de palabras utilizando indice basado en
// comparacion caracter a caracter.
// comparacion de palabras utilizando indice basado en
// comparacion caracter a caracter.
coin_ci_cbc( String a, String b)
{
// Se pasa todo a minusculas para comparar
a = pasar_a_minusculas( a )
b = pasar_a_minusculas( b )
// Se pasa todo a minusculas para comparar
a = pasar_a_minusculas( a )
b = pasar_a_minusculas( b )
int max_len = maxLargo(a, b) // Largo del string mas largo
int min_len = minLargo(a, b) // Largo de string mas corto
int coincidencias = 0
for (i = 0..min_len)
{
if ( a[i] == b[i] ) coincidencias ++
}
return coincidencias / max_len
}
// Case Insensitive Levenshtein:
// comparacion de palabras utilizando indice basado en distancia de Levenshtein
// Mas info>
// - http://www.levenshtein.net/
// - http://es.wikipedia.org/wiki/Distancia_de_Levenshtein
{
// Largo del string mas largo
int max_len = maxLargo(a, b)
// Calcula el indice basado en la distancia de levenshtein
return 1 - ( levenshtein(a, b) / max_len )
// Se pasa todo a minusculas para comparar
a = pasar_a_minusculas( a )
b = pasar_a_minusculas( b )
// Largo del string mas largo
int max_len = maxLargo(a, b)
// Calcula el indice basado en la distancia de levenshtein
return 1 - ( levenshtein(a, b) / max_len )
}
coinSEXO(CodigoSexo s1, CodigoSexo s2)
{
if (s1.codigo == s2.codigo) return 1
return 0
}
coinFECHA (Fecha f1, Fecha f2)
{
if (f1 == f2) return 1
return 0
}
Por último, el cálculo del Índice de Coincidencia que será resultado del AVI-b, como vemos usamos los pesos y los algoritmos para calcular la comparación de atributos simples. En el ejemplo se utiliza coin_ci_cbc como comparador de nombres, éste se podría cambiar por coin_ci_levens.
IC( id1, id2 ) = pesos[nom1] * coin_ci_cbc(id1.nom1, id2.nom1) +
pesos[nom2] * coin_ci_cbc(id1.nom2, id2.nom2) +
pesos[ap1] * coin_ci_cbc(id1.ap1, id2.ap1) +
pesos[ap2] * coin_ci_cbc(id1.ap2, id2.ap2) +
pesos[sezo] * coinSEXO(id1.sexo, id2.sexo) +
pesos[fecha_nac] * coinFECHA(id1.fecha_nac, id2.fecha_nac)
En la siguiente tabla se puede ver el comportamiento del algoritmo básico (AVI-b) probando con algunos casos donde se toma una identidad y se varía algún dato para verificar cómo esta modificación afecta al Índice de Coincidencia (IC) que obtengo como resultado. Algunas aclaraciones para poder interpretar correctamente los resultados:
- La identidad ID1 es siempre la misma, la que varía es ID2 en algunos valores.
- Se hicieron 3 casos de comparación, probando con los dos algoritmos distintos para la comparación de nombres y apellidos.
- Las filas de igual color corresponden a comparaciones de las mismas identidades pero utilizando algoritmos distintos para la comparación de nombres, es decir: ci_cbc o ci_levens.
- En las filas 1 y 4, la variación de ID2 con respecto a ID1 es que en el segundo nombre se sacó una letra, la C.
- En las filas 2 y 5, la variación de ID2 con respecto a ID1 es en la fecha de nacimiento.
- En las filas 3 y 6, la variación de ID2 con respecto a ID1 es el primer nombre completo, manteniendo todos los otros datos. Este caso se podría dar en hermanos gemelos o mellizos, y el algoritmo debería ayudar a diferenciar entre ellos, si no es así, se debería utilizar la identidad extendida mediante los datos de "indicador de nacimiento múltiple" y "orden de nacimiento" que se describen en el documento del STID.
| # | IC | Algor. | ID1 | ID1 fecha | ID2 | ID2 fecha |
|---|---|---|---|---|---|---|
| 1 | 0.86 | ci_cbc | Ana Jacqueline Gomez Rodriguez | 1983-11-22 F | Ana Jaqueline Gomez Rodriguez | 1983-11-22 F |
| 2 | 0.8 | ci_cbc | Ana Jacqueline Gomez Rodriguez | 1983-11-22 F | Ana Jacqueline Gomez Rodriguez | 1983-11-12 F |
| 3 | 0.825 | ci_cbc | Ana Jacqueline Gomez Rodriguez | 1983-11-22 F | Carla Jacqueline Gomez Rodriguez | 1983-11-22 F |
| 4 | 0.9825 | ci_levens | Ana Jacqueline Gomez Rodriguez | 1983-11-22 F | Ana Jaqueline Gomez Rodriguez | 1983-11-22 F |
| 5 | 0.8 | ci_levens | Ana Jacqueline Gomez Rodriguez | 1983-11-22 F | Ana Jacqueline Gomez Rodriguez | 1983-11-12 F |
| 6 | 0.895 | ci_levens | Ana Jacqueline Gomez Rodriguez | 1983-11-22 F | Carla Jacqueline Gomez Rodriguez | 1983-11-22 F |
Tabla de resultados
Trabajo futuro:
Si bien se probó empíricamente el buen funcionamiento del Algoritmo de Verificación de Identidades Básico (AVI-b) creo que se podría ajustar aún más el resultado utilizando el algoritmo avanzado, donde los pesos se ajustan según los valores de los atributos de las identidades. Esto sería fácil de hacer si se tienen calculadas las frecuencias de nombres y apellidos de las identidades que se tienen en la base de datos donde están registradas las identidades a verificar, esto quiere decir, calcular cuántas personas tienen cada nombre (Pablo, Pedro, Juan, etc) y dividir cada una de esas cantidades entre el número total de identidades en la base. Luego esa frecuencia sería utilizada para aumentar el peso de un atributo (si es que hay poca frecuencia de ese nombre o apellido), o disminuir el peso de un atributo (si es que hay muchas personas que se llaman igual). Esta técnica ajustaría los valores resultantes de las comparaciones a un porcentaje más ajustado a la realidad. Como puede resultar obvio, los valores de frecuencias se deberían actualizar cada tanto, y con esto logramos un resultado que puede estar oculto a primera vista: el algoritmo se ajusta a las distintas frecuencias de nombres que se dan en distintos momentos. Es sabido que hay épocas donde un nombre se hace muy popular, y en algunos años el nombre más popular cambia, cambiando la frecuencia de personas que podemos encontrar con esos nombres en nuestras bases de datos. Con esto logramos un algoritmo que se adapta automáticamente (algoritmo adaptable) a cambios que se dan en la cultura de la sociedad. ¿Interesante no?
Conclusiones:
Cómo se puede apreciar en las filas 1 y 4 de la tabla de resultados, al cambiar una sola letra de un nombre o un apellido, el IC es mucho más alto usando el algoritmo ci_levens que el ci_cbc para comparar nombres, esto se debe a que el índice que se calcula en base a Levenshtein es más fuerte o se comporta mejor ante pequeños cambios. Este cambio se puede deber a un error humano en el registro, y es bueno tener un algoritmo que lo pueda detectar. Es decir que la detección de duplicados también ayuda a la detección de errores en el registro, y por lo tanto a mejorar la calidad del mismo, que es el objetivo planteado al inicio.
En las filas 2 y 5 no vemos cambio en el resultado del CI porque lo que es distinto entre las identidades es la fecha de nacimiento.
Por último, en las filas 3 y 6 vemos una pequeña diferencia en el CI, esto se debe a que el primer nombre es tan distinto entre ID1 e ID2 que tanto el índice basado en Levenshtein como el índice basado en la cuenta carácter a carácter detectan que ambos nombres son distintos, bajando el valor del CI en cantidades similares.
Espero que se hayan entendido las ideas detrás del algoritmo, cuáles eran los objetivos y que hayan quedado claras las conclusiones. Por cualquier consulta o comentario no duden en agregar un comentario.
19 de diciembre de 2009
Estandares que salvan vidas
Ayer en el hipódromo de Maroñas se lanzó el número cero de la revista 1024, en la cual fue publicado un artículo de quien les escribe estas palabras. Gracias a Enrique González, editor de la revista, por confiar en mi para escribir este artículo y a todos los colegas que participaron y colaboraron en la creación de la misma.
Milveinticuatro, o simplemente 1024, es una revista de informática y tecnología para Uruguay, que viene a llenar un hueco en cuanto a la comunicación de los principales actores vinculados a las TICs el medio local.
Si bien "estándares que salvan vidas" es un título fuerte para un tema tan complicado y complejo como la informatización y estandarización aplicadas a la salud, creo que va a captar la atención del lector. Aquí les dejo el artículo publicado:
La Historia Clínica Electrónica (HCE) de un paciente debe ser completa, por lo que debe tener la capacidad de registrar toda la información que surge de cada acto médico durante toda la vida del paciente. Para lograrlo se debe elegir cuidadosamente el modelo de información que se usará para almacenar toda la información clínica, se destacan tres modelos estándar: HL7 CDA [1], ISO/CEN 13606 [2] y OpenEHR [3]. En la figura 1 se muestra un esquema de la relaciones entre estándares, en el sitio de OpenEHR-ES [4] está el análisis de donde se derivan estas relaciones.
Milveinticuatro, o simplemente 1024, es una revista de informática y tecnología para Uruguay, que viene a llenar un hueco en cuanto a la comunicación de los principales actores vinculados a las TICs el medio local.
Si bien "estándares que salvan vidas" es un título fuerte para un tema tan complicado y complejo como la informatización y estandarización aplicadas a la salud, creo que va a captar la atención del lector. Aquí les dejo el artículo publicado:
Hoy las instituciones de salud son sistemas caóticos, con pocos procesos definidos, con un modelo de registro sumamente heterogéneo y donde existe una enorme necesidad de información por parte de los médicos y los gestores de estas instituciones. Solo pensar en qué los médicos que nos atienden no disponen de toda nuestra información clínica en el momento de la atención, nos hace dudar de la calidad del cuidado que estamos recibiendo, no por los médicos, si no por la falta de información completa y precisa. La única solución a estos problemas es la informatización de la mano de la estandarización.
Los sistemas de información en el ámbito de la salud tienen varias diferencias con los sistemas en otros ámbitos. El dominio de la salud es complejo, cada acto médico es ejecutado por diversos roles, los procesos de atención se adaptan y varían caso a caso, y se manejan una inmensa cantidad de variables y registros.
Figura 1. Relación entre estándares
HL7 es una organización que desarrolla estándares focalizados en el intercambio de información entre sistemas en salud. HL7 CDA (Clinical Document Architecture) es su estándar para modelar de documentos clínicos. CDA sirve tanto para la comunicación, como para el almacenamiento documental que compone la Historia Clínica
ISO/CEN 13606 es un estándar nacido en la Comunidad Europea y hoy en día es estándar mundial ISO. Es también un estándar para modelar documentos clínicos. Existe una compatibilización con CDA haciéndolos intercambiables. El 13606 se basa en el modelo de OpenEHR, simplificándolo de forma sustancial para cumplir específicamente con el objetivo de comunicar de información clínica en formato electrónico.
El modelo de referencia de OpenEHR es uno de los modelos de información clínica más completos y genéricos que existe. Con similitudes al modelo de HL7 y al ISO 13606, OpenEHR define un modelo de información y una arquitectura que soporta la implementación de cualquier HCE, tal que sea completa, segura, única para cada paciente y longitudinal a la vida del paciente. Muchas de las características con las que cumple OpenEHR están definidas en la especificación técnica ISO/TS 18308. Cómo este estándar no es muy conocido en la región, estamos comenzando una comunidad en español sobre OpenEHR [4] para aportar a su difusión.
Las razones de por qué informatizar la Historia Clínica
Informatizando la HC y aplicando estándares resolvemos uno de los principales problemas: la fragmentación de la información clínica. Los sistemas informático-clínicos de hoy en día son verdaderas “islas” de información, donde se fragmenta la información del paciente atentando contra el decreto de 30/09/2003 de Historia Clínica Única para cada persona. La información clínica expresada en forma estándar permite que diversos servicios e instituciones de salud estén interconectados. Si en un accidente de tránsito se tiene una persona gravemente herida, el médico pide su HCE a la institución de la que es socio, accediendo a su información clínica, lo cual le permite dar una mejor atención. Por ejemplo, si el paciente accidentado es alérgico a un medicamento, el médico que lo atiende en la calle lo sabrá, evitándole administrar una droga que lo puede matar.
Algo no muy visto en sistemas de HCE en Uruguay es la geo-referenciación. Imaginemos que una institución tiene a todos sus pacientes ubicados geográficamente, con algunos datos clínicos asociados, como sus “problemas de salud” (diabetes, hipertensión, asma u obesidad), y a cada problema le asocia un color, el resultado es que se podrá ver un mapa con la distribución de problemas de salud de los pacientes de la institución, permitiendo que se tomen acciones de prevención a nivel poblacional, impactando directamente en la calidad de vida de las personas a largo plazo. Con algo tan simple como ver que el 30% de la población atendida es hipertensa, la institución podría lanzar una campaña de control de la presión, y a los pocos meses se puede ver si esa población de riesgo tiene su presión arterial dentro de los rangos normales, logrando prevenir futuros problemas cardíacos.
Con un sistema de este tipo, cuando ocurrió el problema de la plombemia en algunos barrios de Montevideo, se habría detectado de forma temprana las zonas de riesgo y tomado medidas en menor tiempo.
Actualmente en la Universidad de la República , en la carrera de Ingeniería en Computación, estamos trabajando en una tesis de grado: “Historia Clínica Electrónica de Trauma” [6].
Este trabajo lo estamos realizando junto al Dr. Fernando Machado y la encargada del centro de cómputos Lucía Grundel del Hospital Maciel, una de las principales puertas de emergencia con entrada de pacientes traumatizados del Uruguay. Adicionalmente se realizó un adelanto del proyecto final al que se lo denominó “MiniClin”[5].
MiniClin: la HCE minimal
Es un sistema de HCE completa, minimal y estándar. Es completa porque permite integrar todos los tipos de registros que forman la HCE. Minimal
HCE de Trauma
Es la implementación de la arquitectura propuesta por el estándar OpenEHR, en el cual, como salida hacia otros sistemas clínicos, se generan documentos clínicos CDA.
Junto al registro de información se implementa el proceso de atención del paciente traumatizado, así la aplicación sigue paso a paso las tareas que los médicos van realizando. La generación de CDA tiene dos objetivos, la comunicación de información clínica entre sistemas, y que los documentos clínicos puedan ser firmados electrónicamente, para darle a la HCE la validez legal que tiene un documento en papel.
Otras características de esta HCE es que clasificará los diagnósticos con el estándar internacional de enfermedades definido por al Organización Mundial de la Salud en la versión 10 (CIE10), también integrará el acceso a exámenes imagenológicos digitales adquiridos desde equipos que cumplan con la norma de imagen digital y comunicaciones en medicina (por siglas en inglés, DICOM).
Tanto MiniClin como la HCE de Trauma fueron pensados con la idea de que en el futuro sean los propios médicos quienes definan los formularios para registro en el sistema, así estos registros se adecuarán a las necesidades de los médicos, quitándole una pesada y tediosa tarea de análisis a los informáticos. Esto aporta también a disminuir la barrera cultural entre médicos e informáticos, haciendo a los médicos partícipes activos en el desarrollo de la HCE.
En conclusión, los sistemas que no sigan estándares, tanto en el modelado interno de la información clínica como en su representación para la comunicación, tenderán a desaparecen en los próximos años. Estos sistemas serán islas de información dentro de una institución e irá en contra de sus necesidades de integración interna entre sistemas y externa con otras instituciones. Además, quienes no adopten estándares estarán violando el decreto de Historia Clínica Electrónica única de cada persona, desde el registro perinatal hasta el fallecimiento.
A/C Pablo Pazos Gutiérrez
[A] Tesis de grado en elaboración: “Historia Clínica Electrónica de Trauma” A/C Pablo Pazos, A/C Leandro Carrasco, Tutor: Prof. Franco Simini, Facultad de Ingeniería, UdelaR.
Referencias
[1] Health Level Seven, Inc
[2] ISO/CEN 13606
[3] OpenEHR, future-proof and flexible EHR System Architecture
[4] OpenEHR-ES: comunidad OpenEHR en español
[5] MiniClin
18 de diciembre de 2009
Informática Clínica y Estándares
Hace un tiempito hice un trabajo resumiendo algunos estándares, dando un poco de contexto, buscando complementariedades, y analizando qué lugar ocupan en el desarrollo de la Historia Clínica Electrónica. Aquí dejo la presentación que hice en las Jornadas de Informática e Investigación Operativa de la Facultad de Ingeniería de Montevideo, espero sea de su agrado.
¡Los comentarios son bienvenidos!
¡Los comentarios son bienvenidos!
5 de diciembre de 2009
Super estandares en informatica medica
De distintas charlas profesionales tanto informáticos cómo médicos acerca de los estándares en informática médica, sobre todo en HL7, he notado que varios conceptos no están del todo claros o literalmente no saben de lo que están hablando. Por ejemplo muchos piensan que HL7 es un solo estándar y que su aplicación es directa, cómo definir el estándar para una entrada de corriente: tanto el macho cómo la hembra son especificados de forma estándar y cuando son fabricados por distintos proveedores, si cumplen con el estándar, macho y hembra encajan a la perfección. En la informática médica este es un ideal que no podrá ser logrado mientras estos conceptos no estén claros. Y se podría afirmar que sería imposible que HL7 u otros estándares funcionen de esta manera.
Primero cabe aclarar que HL7 es una organización que crea estándares, y que si vemos a HL7 como estándar, es en realidad un gran conjunto de estándares dedicados sobre todo a resolver la comunicación entre sistemas clínicos y administrativos. Estos estándares aplican a áreas específicas o “dominios” dentro del ambiente de la salud.
Si por “estándar” pensamos en el ejemplo de la entrada de corriente la cual se conecta y encaja perfectamente, en realidad HL7 se comporta como un “súper estándar” porque no tiene esa capacidad, o sea que es un paso previo o superior a la aplicación de un estándar. En el mundo de HL7 para que cualquier estándar sea implementado es necesario definir las llamadas “guías de implementación”, las cuales especifican acuerdos entre distintos actores para definir cómo implementarán uno o varios estándares HL7, o sea que sin un acuerdo previo es prácticamente imposible que dos o más sistemas intercambien mensajes HL7 y lleguen a interoperar semánticamente.
Existe una organización llamada Integrating the Healthcare Enterprise o simplemente IHE que se encarga de definir especificaciones de cómo utilizar mensajería HL7 para cumplir con determinados propósitos, por ejemplo resolver toda la mensajería necesaria para tener informatizados los ciclos de pedido, reporte y consulta de exámenes imagenológicos. Estas especificaciones se llaman “perfiles” y cada perfil aplica a un dominio particular como ser: anatomía patológica, cardiología, oftalmología, laboratorio, coordinación de cuidado del paciente, oncología, radiología, etc. Si bien IHE no es un estándar, si no que es una forma de usar los estándares HL7 y DICOM (para radiología digital), es una orientación a las guías de implementación HL7 para definir acuerdos entre los actores, así que podría verse como un estándar complementario o de guía.
En definitiva logramos una relación cómo la descrita en la figura 1.
Figura 1.
HL7 no es el único “súper estándar”, existen otros como OpenEHR o DICOM, dos con una característica común: son estándares abiertos.
OpenEHR intenta resolver la forma en que se desarrollan los sistemas de información clínicos, que son los sistemas que forman la ya conocida Historia Clínica Electrónica. OpenEHR plantea una arquitectura con los distintos componentes del sistema, propone un completo modelo de información clínica y administrativa, y propone la “orientación al conocimiento” de los sistemas de información en salud, a través de sus Arquetipos. Los arquetipos son la forma de expresar conceptos médicos en un formato computable, y es la forma de bajar del “súper estándar” al estándar aplicable. Los arquetipos también son la forma de especificar los acuerdos entre los actores, es decir que si dos o más actores implementan su propia Historia Clínica Electrónica y se ponen de acuerdo en los arquetipos de los conceptos clínicos que manejarán en cada historia, luego podrán intercambiar información clínica sin problemas. Los conceptos pueden ser por ejemplo: “presión arterial”, “administración de medicamento”, “escala de coma de Glasgow”, etc.
Figura 2.
En el mundo de los exámenes imagenológicos digitales encontramos al estándar DICOM, otro súper estándar. DICOM propone un modelo de información y un conjunto de interacciones o transacciones entre sistemas los cuales se ejecutan para automatizar los procesos de: solicitud de un estudio, coordinación de un estudio, ejecución del estudio, elaboración del informe por el radiólogo, entrega del informe al médico solicitante. Cómo DICOM es un “súper estándar” es necesario llegar a un acuerdo previo para definir cómo será utilizado, en el mundo DICOM este acuerdo se llama “DICOM Conformance Statement” ó “Declaración de Conformidad DICOM”. Éste es un documento que especifica todas las decisiones particulares que un proveedor tomó al implementar la norma, el cual debe entregar cada vez que quiera conectar su producto con otros productos “DICOM compatibles”, o sea que esta declaración de conformidad en realidad no es un acuerdo entre actores, si no que es una forma de mostrarle a otros actores cómo es que un sistema implementa DICOM. El capítulo 2 de la norma DICOM define qué es la declaración de conformidad y cómo debe ser creada.
Figura 3.
En conclusión, los estándares propuestos en el área de la salud no son por sí mismos estándares aplicables, si no que son “súper estándares”, los cuales necesitan de acuerdos y decisiones previas que bajen la complejidad y generalidad de los mismos a algo implementable en un sistema de información clínica. Por lo tanto debemos tener cuidado al comprar productos que se ofrezcan como “compatibles HL7” o “compatibles OpenEHR” o “compatibles DICOM”, lo que necesitamos realmente son: las guías de implementación, los arquetipos o la declaración de conformidad, respectivamente.
Suscribirse a:
Comentarios (Atom)
Entradas
