Les dejo el video de la charla, para descargarla haga clic aquí.
¿Buscas capacitación en Bases de Datos Clínicas? Encuéntrala en CaboLabs
¿Porqué hablar de estos temas?
Es muy frecuente que para la para la persistencia de información clínica se utilicen las mismas tecnologías que se utilizan para la persistencia de otras clases de información, por ejemplo información demográfica o administrativa. Estas tecnologías son las bases de datos relacionales.
El principal problema es que la información clínica no tiene la misma estructura que la información administrativa, y además es utilizada de forma distinta.
Por otro lado hoy existe un gran número de tecnologías de persistencia de datos que no siguen el modelo relacional, y que son interesantes para analizar, investigar y probar para la persistencia de información clínica.
Además, hablamos un poco de arquitectura de sistemas de historia clínica electrónica, donde mostré distintos usos de la información en distintos componentes del sistema, donde podríamos utilizar distintas soluciones tecnológicas para la persistencia de información clínica basándonos en los servicios que cada componente provee y en la utilización que se le dará a la información que se accede mediante esos servicios.
Particularidades de la información clínica
El gran problema de la información clínica es que es altamente jerárquica, es decir que tiene forma de árbol. La persistencia de este tipo de información en bases de datos relacionales es difícil e ineficiente.
Además, se tienen distintos tipos de información clínica según cómo esta se utiliza. Por un lado está la información documental, que equivale a los documentos firmados por el médico que son parte de la historia clínica de un paciente. Mientras que el otro tipo de información se podría llamar "vinculado" o "persistente", ya que es información clínica que es persistente en el estado de salud del paciente (como saber si el paciente es alérgico o diabético), y es información que se debe vincular entre distintos documentos. Esta última clase de información es lo que el médico debe saber del paciente antes de cualquier acto asistencial y claramente no tiene una forma documental.
Para hablar sobre la complejidad de la información clínica, en la página 5 de la presentación mencioné algunos de los modelos estándar de información clínica más conocidos. Aquí les dejo algunas referencias sobre estos modelos:
- http://informatica-medica.blogspot.com/2010/10/openehr-el-estandar-abierto-para.html
- http://informatica-medica.blogspot.com/2011/02/hl7-normalizando-la-comunicacion-en.html
- http://www.ncbi.nlm.nih.gov/pmc/articles/PMC130066/
Distintos enfoques de persistencia
Les dejo algunos links con productos que siguen cada uno de los enfoques de persistencia:
Relacional:
Orientadas a objetos:
Orientadas a documentos:
Orientadas a grafos:
Clave/Valor (orientadas a columnas) - Entidad/Atributo/Valor:
Sobre arquitectura de Sistemas de Historia Clínica Electrónica
En esta sección de la charla, hice foco en los grandes componentes de un sistema de HCE global que podría implementarse a nivel federal o nacional, y que excede claramente las capacidades de una aplicación de HCE específica.
Dentro del contexto de la charla, mencioné que los distintos componentes deberían tener soluciones de persistencia específicas según los servicios que proveen.
También mencioné la utilidad de separar la capa de presentación o interfaz de usuario de la aplicación, y de separar el servidor de historias clínicas del servidor demográfico, para lograr una mayor mantenibilidad y escalabilidad del sistema a futuro.
La presentación:
Entradas
Pablo, ÇQue ventaja le vez a bases tipo couchdb por sobre una relacional con con capacidad documental?. Ejemplo postgresql y sus funciones xml y json. En el caso particular de xml con postgresql, la evidencia reporta resultados de muy buen rendimiento.
ResponderEliminargracias
eduardo
Hola Eduardo,
EliminarA priori la gran ventaja es que son específicas para documentos. Las relacionales con soporte por ejemplo para xml mezclan conceptos relacionales y documentales, y en realidad son distintos tipos de información que debería ser utilizada de distinta forma (o sea las queries que se hacen son para cosas distintas).
La gran ventaja de las bases como CouchDB o MongoDB sobre cualquier base relacional es la independencia del esquema, lo que permite modificar el sistema sin tener que cambiar la estructura de la base cada vez.
Por favor publica la referencia a la evidencia que mencionas para compartirla con los compañeros del blog.
Saludos.
El asunto es totalmente relevante y de grandísimo intertés para nuestra investigación.
ResponderEliminarMe alegro que les haya servido, si tienen algún comentario, no duden en ponerlo aquí.
EliminarPablo, a mediados del año pasado consulté en el la lista de correos (pgsql-es-ayuda@postgresql.org), la cual leo constantemente, por funcionalidades xml sobre postgresql. En ese entonces en el lugar donde trabajo, Ancora UC - Red de centros de salud familiar (chile), requeríamos hacer una interfaz entre dos sistemas clínicos, con tecnología web Services, soap, xml. Yo estaba preocupado por el tema de rendimiento, dado lo extenso de los documentos clínicos (mensajes xml) y el rendimiento que tiene web Services. Pregunté, que es mejor construir los documentos en la base de datos o en el código de mi aplicación. La respuesta fue que la capacidad de postgresql para documentos xml es muy buena, y se mencionó una empresa X que lo estaba ocupando con muy buenos resultados. Ahora consulta por interno y me enviaron la siguiente referencia (http://wiki.postgresql.org/images/7/7d/Casos_estudio.pdf) empresa Enova, no tengo datos estadísticos específicos de lo que tienen en xml pero quedaron de conseguirme los datos para ver la magnitud del proyecto.
ResponderEliminarPor mi parte me lance a programar, haciendo pruebas con buenos resultados (postgresql + xml + perl script). Finalmente al conseguir presupuesto se contrató una empresa que hizo la interfaz, pero ellos no ocuparon xml desde la db.
En mi experiencia, he trabajado administrando sistemas clínicos, he trabajado en extracción de datos, y últimamente en la gestión de una oficina de informática médica. Tengo que confesar que me cuesta pensar en un modelo distribuido de almacenamiento, donde por ejemplo podrías tener: a) una db documental para documentos ejemplo resultados de exámenes de laboratorio (lis), imágenes (ris/pacs), una ficha en una db relacional u orientada a objetos, y así muchos otros sistemas con sus db específicas independientes. Creo que hay riesgo de perder la unificación de la ficha y perder flexibilidad para consultar datos. Al igual como tu propones que los datos que se refieren a una mimo formato como pueden ser una receta médica, un consentimiento informado, un resultado de laboratorio, quedan mejor en un documento único. Pienso lo mismo para el cúmulo de esos documentos, creo que quedan mejor en una sola db.
Hola Eduardo,
EliminarLa charla trata de mostrar un panorama amplio de las distintas necesidades de información en salud, analizando el aspecto de persistencia. El mensaje es: si tenemos distintas necesidades, analicemos distintas soluciones. Creo que ante un nuevo desarrollo debemos preguntarnos si el esquema relacional es el más correcto, y luego ir a analizar productos específicos.
Para una aplicación particular, un producto puede ser más o menos efectivo, depende mucho de los requerimientos. En tu caso los requerimientos eran de almacenamiento de XML y de performance, pero en otros caso no lo es. Es más, en la mayoría de las comunicaciones entre sistemas en el área de la salud, la performance no es algo demasiado necesario, porque las comunicaciones no necesitan ser en tiempo real y pueden darse en segundo plano a medida que los recursos se liberen.
Imaginarse un sistema con repositorios distribuidos es fácil, es más, hoy en la mayoría de los centros asistenciales existen múltiples bases de datos. El principal problema es que no están integradas (integrado y centralizado son cosas distintas!). Teniendo un sistema lógico consistente de bases de datos distribuidas y comunicaciones confiables, el riesgo de que se "pierdan" datos es menor. El mismo riesgo ocurre con los sistemas monolíticos donde el software se comunica con la base de datos por TCP.
El problema no está en la distribución, tampoco está en es que use PostgreSQL, MySQL o MongoDB, el problema es que la arquitectura, diseño y servicios provistos por los componentes del sistema sean consistentes, luego la implementación deberá seguir esa consistencia y tomar medidas para reducir riesgos de problemas que se puedan dar, por ejemplo creando bases replicadas para brindar alta disponibilidad de datos. Agregado a esto está el uso de estándares y buenas prácticas que también aportan a que se reduzcan los problemas.
Saludos.
Pablo,
ResponderEliminarConcuerdo contigo, en que hay que analizar productos específicos de acuerdo a las necesidades del proyecto, y que las soluciones tecnológicas no son el problema en si (párrafos 1 y 2).
Mi llamado de atención va por el lado de que a medida que un sistema de información se va poniendo más complejo, van apareciendo más componentes ejemplo un sistema documental. Y también es cierto que si los sistemas están integrados, y tenemos el cuidado suficiente al cambiar un componente, la ficha clínica debería conservar todos sus datos.
Pero en papel, la historia clínica es un documento único, y esa indivisibilidad es resguardada por cada una de las personas que la trabajan con ella. Aun cuando hay datos que quedan en otro sistema como podría ser un sistema de laboratorio, igual existe una copia en la ficha (redundancia en post de la unicidad de del documento). Por este lado van mis ideas, ¿Cómo hacemos para que esas redundancias que dan unicidad se sigan dando?, y no nos confiemos que tales datos estarán en un determinado sistema especifico, aun cuando exista interoperabilidad perfecta.
Quizás en esta lógica de componentes específicos, falta un componente central que se preocupe de la unicidad, integridad, y resguardo de datos históricos.
Espero darme a entender
Saludos
Hola Eduardo,
EliminarEstoy de acuerdo en que el la cantidad de sistemas de información en una institución sanitaria y su complejidad va en aumento, y en que esto puede generar problemas.
El punto no es evitar este crecimiento, sino preguntarse cómo lo deberíamos gestionar. O sea, los sistemas van a crecer en función de las necesidades, y uno como informático debería buscar la mejor solución para cada necesidad, pero además, debería permitir que el sistema sea gestionable (y a veces también debemos gestionar todo el sistema).
La capacidad de gestión de sistemas de cada institución sanitaria depende de un conjunto de factores locales, y esto determinará si ante un nuevo requerimiento se agrega un nuevo componente al sistema o se intenta cumplir el requerimiento modificando componentes actuales. Muchas veces una u otra decisión no depende de la mejor decisión técnica, sino de lo que se puede hacer.
Creo que lo que mencionas apunta a esto último, mientras que yo me estaba centrando en buscar cual sería la mejor solución técnica.
El último párrafo tuyo creo que plantea justamente este componente de gestión de sistemas tan necesario, el cual debería contener la base de conocimiento de las aplicaciones (toda la documentación, en formato dado, según estándares), toda la gestión de versiones de las aplicaciones con todos los cambios hechos en cada versión, monitoreo de aplicaciones en tiempo real, etc. Un proyecto "grande" sin un componente de gestión, depende únicamente de las personas, y si hay pocas personas y no están capacitadas, es un riesgo enorme para todo el proyecto a largo plazo.
Muy interesante el intercambio en el que derivó la charla!
¿Qué te parece?
Saludos,
Pablo.