Visualización de datos clínicos complejos antes de crear el modelo

La lectura de la presión arterial parece sencilla hasta que Ian McNicoll se pregunta qué debe significar dentro de un historial médico. ¿Qué unidades debe admitir? ¿Cuál era la postura del paciente? ¿Qué contexto debe acompañar al número? Para Ian, informático clínico y antiguo médico de cabecera escocés, preguntas como estas se sitúan entre la medicina y el software.
Como fundador y director ejecutivo de freshEHR Clinical Informatics y miembro de la junta y antiguo copresidente de openEHR International, Ian ayuda a transformar el conocimiento clínico en modelos de datos reutilizables. Mucho antes de que esos modelos lleguen a un sistema técnico, él y la comunidad de openEHR en general utilizan Xmind para hacer visible su estructura.
Una sola medición puede contener todo un árbol de decisiones
Cuando Ian explica el modelado de datos clínicos, suele empezar con algo familiar: el peso corporal. Registrarlo podría parecer que requiere un solo número. Pero entonces empiezan las preguntas. ¿Debe el modelo aceptar kilogramos y medidas imperiales? ¿Se pesó al niño con ropa? ¿Necesita la medición un comentario? ¿Cómo funcionará el mismo concepto en distintos idiomas?
La presión arterial aporta sus propias ramificaciones: valores sistólicos y diastólicos, la postura del paciente, las circunstancias de la lectura y el contexto clínico circundante. Cada respuesta puede revelar otra decisión que debe representarse con claridad.
Ian describe los datos y las ideas médicas como algo fractal y arborescente. Su significado no depende solo de los puntos de datos individuales, sino de cómo se relacionan entre sí. Para quienes crean modelos clínicos compartidos, el reto no es simplemente recopilar información, sino encontrar una estructura que los clínicos puedan comprender, cuestionar y perfeccionar antes de fijar nada en el software.
Un mapa tiende un puente entre la hoja de cálculo y el sistema
Los mapas de Ian ocupan un lugar específico en el proceso de modelado. Se sitúan entre los requisitos aportados por los clínicos y los modelos formales que los sistemas de software acabarán utilizando.
De los requisitos clínicos a una estructura visible
El trabajo suele comenzar con una hoja de cálculo de un grupo clínico. Un especialista en oftalmología, por ejemplo, puede enumerar toda la información que debe recopilarse sobre el glaucoma. Las filas reflejan los requisitos, pero no revelan necesariamente la forma clínica que hay detrás.
Ian reconstruye ese material en Xmind. Una estructura mixta —un organigrama en la parte superior y un diagrama de árbol más abajo— le permite pasar de la organización general de un conjunto de datos a sus ramas clínicas más detalladas. Así puede conectar los puntos de datos solicitados con los modelos de openEHR existentes y ver dónde puede ser necesario trabajar más.
Cada elección visual tiene un significado práctico:
Los marcadores muestran qué puntos de datos están listos y cuáles necesitan atención.
Los límites mantienen agrupadas las listas de códigos relacionados.
Las notas conservan las explicaciones de la fuente original.
El esquema presenta la misma estructura de forma lineal cuando resulta más fácil de revisar.
Juntos, estos detalles ayudan a Ian a convertir una hoja de cálculo plana en una estructura que refleja cómo entienden los datos los profesionales clínicos.
De un mapa de trabajo a un modelo de datos formal
El mapa no es el modelo clínico acabado. Es el espacio preparatorio donde la comunidad interpreta una hoja de cálculo, organiza sus relaciones y decide cómo encaja cada parte en un panorama clínico más amplio.
Una vez clara la estructura, se utilizan herramientas específicas de openEHR para crear arquetipos y plantillas formales con los que puedan trabajar los sistemas de software. A continuación, estos modelos pueden revisarse, traducirse, versionarse e incorporarse a una biblioteca compartida.
Xmind no sustituye la experiencia clínica ni el modelado técnico. Ofrece a ambas partes un lugar común para decidir qué debe significar el modelo antes de que ese significado se exprese en código.
Una estructura se convierte en el lenguaje de una comunidad
Ian introdujo Xmind en el flujo de trabajo hace al menos una década, después de que la comunidad probara otra herramienta de mapas mentales. La capacidad de combinar estructuras se adaptaba a la forma en que se desarrollaban sus modelos. Sin ninguna obligación formal de usarlo, Xmind se convirtió gradualmente en lo que Ian llama el "estándar de facto" de la comunidad para esta fase inicial de la cadena de herramientas.
La comunidad openEHR es internacional y colaborativa. Clínicos y modeladores comparten archivos .xmind en su foro de debate, revisan modelos, los traducen y devuelven el trabajo terminado a una biblioteca común. Los miembros experimentados suelen recomendar Xmind cuando los recién llegados preguntan qué utilizar, pero la herramienta importa porque la estructura es útil, no porque la participación dependa de ella.
Ese lenguaje visual compartido ayuda a que personas con trayectorias distintas se entiendan. Un clínico no necesita leer un lenguaje de modelado técnico para examinar si las ramas reflejan la práctica real. Un modelador puede rastrear cómo encaja cada campo solicitado en el panorama clínico general.
La escala llega más tarde: los modelos formales obtenidos mediante este proceso más amplio sirven de apoyo a proyectos sanitarios en varios países, como el Plan de Cuidados Universales de Londres e iniciativas de openEHR en Alemania, Eslovenia e Irlanda. El primer paso sigue siendo que un grupo de personas se asegure de que están hablando de lo mismo.
El modelo empieza con una pregunta que la gente puede ver
Para Ian, un mapa mental es más útil antes de que las respuestas parezcan definitivas. Mantiene visibles los supuestos clínicos mientras aún pueden cuestionarse, reorganizarse y mejorarse. Para cuando un modelo llega a un almacén de datos, gran parte de su significado ya se ha decidido.
El sistema final puede contener una presión arterial, un peso corporal o las voluntades de un paciente. Detrás de cada campo hay un árbol de decisiones que alguien tuvo que hacer explícitas. El trabajo de Ian comienza dando a esas decisiones una forma que clínicos y tecnólogos puedan ver juntos.



