Analizamos, revisamos y rediseñamos el modelo de datos de su organización para que la información clínica conserve su significado al cruzar de un sistema a otro — con una estrategia de terminologías, un modelo objetivo y un plan de migración que no interrumpe la operación.
Cuando dos sistemas no logran entenderse, casi nunca es porque el mensaje no llegó. Es porque cada uno guarda el mismo hecho clínico de forma distinta: un campo de texto libre donde el otro tiene un código, una tabla propia de diagnósticos, una fecha que a veces es la de la toma y a veces la del reporte, un identificador que se repite entre establecimientos. Estandarizar el intercambio sin ordenar el modelo solo traslada el problema a la capa siguiente. Este servicio trabaja donde el problema se origina: analizamos el modelo actual, revisamos su diseño, acordamos hasta dónde llega el alcance y proponemos un modelo objetivo con las terminologías, las reglas de normalización y el plan de migración necesarios para llegar a él.
Las cinco existen aunque nadie las haya decidido. Cuando una se salta, la decisión igual se toma — la toma quien desarrolla, en el momento de desarrollar, y sin dejar registro.
Quién es dueño de cada dato, quién aprueba un cambio de modelo, con qué cadencia se versiona y cómo se documenta una decisión para que siga siendo comprensible dentro de tres años.
Cada proyecto crea su propia variante del mismo concepto, nadie puede revertir un cambio y entender el modelo se vuelve un trabajo de arqueología.
Qué significa exactamente cada dato: a qué terminología se enlaza, con qué fuerza de binding, en qué unidades se expresa y qué se hace con los valores que no tienen código.
Los sistemas comparten estructuras idénticas y datos incomparables. La analítica agrega cosas distintas bajo el mismo nombre y nadie lo nota.
Cómo se estructura la información: qué es un recurso y qué un atributo, cómo se anidan las observaciones, qué cardinalidades aplican y qué significa exactamente un valor ausente.
Cada integración necesita su propio traductor, ningún mapeo se puede reutilizar y el costo de conectar crece con cada sistema nuevo.
Cómo se persiste y se consulta: esquema físico, índices, versionado de registros, historización y el rendimiento tanto de la consulta clínica como de la analítica.
El modelo es correcto en papel y la consulta que el clínico necesita tarda minutos, así que alguien construye una tabla paralela y el modelo único deja de ser único.
Qué reglas convierten el dato real —el que ya está cargado, con duplicados, abreviaturas y texto libre— en dato conforme al modelo, y qué se hace con lo que no encaja.
El modelo nuevo convive con años de datos que no lo cumplen, y la migración se descubre inviable cuando ya se prometió una fecha.
Cinco etapas. La primera mira los datos reales, no solo el diagrama.
Levantamos lo que existe: esquemas, diccionarios, catálogos de códigos propios, formularios y las estructuras que cada sistema realmente usa. Y perfilamos los datos ya cargados —distribuciones, nulos, texto libre, duplicados— porque el modelo documentado y el modelo en producción rara vez coinciden.
SalidasEvaluamos el modelo contra criterios explícitos en lugar de opiniones: expresividad clínica, trazabilidad de quién registró qué y cuándo, extensibilidad ante un dominio nuevo, consultabilidad para clínica y analítica, y capacidad de sostener el intercambio que la organización necesita.
SalidasAcordamos hasta dónde llega: qué dominios clínicos entran ahora, con qué granularidad, qué se representa de forma estructurada y qué se acepta como texto por el momento. Cuando el dominio ya tiene un DAK de las SMART Guidelines de la OMS, sus elementos de datos esenciales son el punto de partida del alcance en vez de una lista construida desde cero. Un alcance honesto es lo que hace ejecutable todo lo demás.
SalidasDiseñamos el modelo destino y lo expresamos en los artefactos del enfoque elegido: arquetipos y templates, perfiles y extensiones, o un modelo canónico interno. Con identificadores, terminologías y reglas de conformidad definidas, no pendientes.
SalidasUn modelo sin proceso de cambio vuelve a divergir en el primer proyecto urgente. Definimos quién aprueba una modificación, cómo se versiona, cómo se comunica y qué compatibilidad se garantiza entre versiones.
SalidasopenEHR y FHIR se presentan a veces como alternativas excluyentes. No lo son: resuelven problemas distintos y, en más de un ecosistema, conviene usar los dos.
Modela y persiste la información clínica con el modelo separado del software: los arquetipos definen el conjunto máximo de datos de un concepto clínico, los templates lo restringen para un uso concreto y las consultas se escriben contra el modelo, no contra un esquema físico. El contenido lo gobiernan los clínicos, no el equipo de desarrollo.
ArtefactosModela cómo la información sale de un sistema y entra en otro: recursos con una granularidad pensada para el transporte, perfiles que los restringen a un caso de uso concreto y APIs con búsquedas y operaciones definidas. Es el contrato con el mundo exterior.
ArtefactosEl modelo común que la organización usa entre sus propios sistemas, su analítica y sus procesos. No siempre necesita ser un estándar externo, pero sí necesita ser uno solo: es el punto donde se resuelven las diferencias entre fuentes antes de exponer nada hacia afuera.
ArtefactosElegir uno no excluye a los otros. La ruta habitual va del modelo clínico al contrato de intercambio, y el modelo canónico es lo que evita que cada extremo termine hablando un idioma propio.
Descargar SNOMED CT no es adoptarlo. Cada terminología obliga a decisiones sobre alcance, mantenimiento, licenciamiento y versionado que, si no se toman al inicio, terminan tomándose solas y mal.
Vocabulario clínico de referencia para diagnósticos, procedimientos, hallazgos y contexto clínico.
Decisiones que obliga a tomarIdentificación de observaciones, análisis de laboratorio, paneles y variables clínicas.
Decisiones que obliga a tomarClasificación para reporte estadístico, morbilidad, mortalidad y obligaciones regulatorias.
Decisiones que obliga a tomarCatálogos propios del país —establecimientos, servicios, profesionales— y los ValueSets que imponen las guías nacionales.
Decisiones que obliga a tomarLos catálogos que la organización ya tiene y que no van a desaparecer de un día para otro.
Decisiones que obliga a tomarTrabajamos con estas terminologías como marco técnico de referencia. El licenciamiento y la afiliación, cuando aplican, corresponden a la organización o al país que las adopta.
Un modelo nuevo no sirve de nada si los datos que ya existen no llegan a él. La migración se diseña como un proyecto propio, con fases, criterios de aceptación y una salida de emergencia.
Se mide qué hay realmente: volúmenes, calidad, texto libre, duplicados, valores fuera de rango y datos que nunca cumplieron la regla que decían cumplir.
Se definen las transformaciones y los criterios de calidad: qué se limpia, qué se deduplica, qué se enriquece con terminología y qué se marca como no conforme.
Se mapea campo a campo y código a código, declarando el tipo de equivalencia de cada mapeo. Lo que no mapea se documenta como excepción; no se descarta en silencio.
El modelo viejo y el nuevo operan a la vez durante un período acordado, con doble escritura o con vistas de compatibilidad, para que ningún sistema dependa de una única fecha de corte.
El histórico se migra por lotes y se valida por equivalencia: reconciliación de volúmenes, comparación de agregados y revisión clínica por muestreo. La validación es lo que autoriza el corte.
Se corta el flujo hacia el modelo viejo y se retira cuando se demuestra que ya nadie lo lee, conservando la trazabilidad de cada transformación para poder explicar después de dónde salió un dato.
Documentos que se usan durante el rediseño y después de él, no un informe que se archiva.
Inventario de fuentes, diccionario consolidado y perfilado de los datos reales.
Hallazgos por capa, riesgos, deuda de modelo y las decisiones que quedan pendientes.
Dominios, granularidad y qué queda explícitamente fuera de esta iteración.
Modelo lógico y los artefactos del enfoque elegido: arquetipos y templates, perfiles o modelo canónico.
Bindings por elemento y equivalencias declaradas con los códigos locales.
Transformaciones, criterios de calidad y tratamiento explícito de las excepciones.
Secuencia, criterios de aceptación, convivencia y condiciones para autorizar el corte.
Versionado, proceso de cambio y responsables por dominio.
El trabajo de modelado y terminología detrás de guías de implementación que hoy están publicadas y en uso.
Perfiles y ValueSets de las terminologías clínicas compartidas por el ecosistema de salud del país: decidir qué vocabulario aplica a cada elemento, con qué fuerza de binding y quién mantiene el catálogo.
Estructura y reglas de conformidad para notificar resultados: qué se representa como observación, cómo se codifican las pruebas y cómo viajan unidades, valores de referencia e interpretación.
Perfiles para el intercambio de informes de estudios de imágenes: la traducción entre lo que produce el equipamiento y lo que necesita el registro clínico.
Notificación de enfermedades de notificación obligatoria, vacunas y resultados de laboratorio: alinear lo que el sistema de origen registra con lo que la guía nacional exige recibir, y recibirlo en el primer servidor FHIR nacional.
Estos casos corresponden al trabajo de modelado y terminología dentro de guías de implementación nacionales. El enfoque openEHR forma parte del servicio y se evalúa caso por caso; no aparece aquí porque no formó parte de estos proyectos.
Lo que cambia entre una organización y otra no es el método, sino qué tan caro resulta seguir sin un modelo acordado.
Varios sistemas clínicos que registran el mismo hecho de formas distintas. El modelo común es lo que permite una vista única del paciente.
Ecosistemas que deben acordar el modelo antes de exigir conformidad, para que la guía nacional se apoye en algo decidido y no en un supuesto.
Catálogos propios que deben mapearse a LOINC o a códigos nacionales sin perder el detalle que el laboratorio necesita para operar.
Productos cuyo esquema creció por acumulación y que ahora deben exponer datos conformes sin rehacer la base desde cero.
Equipos que dependen de que el dato signifique lo mismo en todas las fuentes para que un indicador sea comparable entre establecimientos.
Intercambio con múltiples prestadores donde cada uno codifica a su manera y la equivalencia hay que declararla, no suponerla.
Si reconoce varias de estas situaciones, el problema no está en las interfaces: está en el modelo que hay debajo.
Antes de exponer APIs o comprometerse con una guía nacional, conviene saber qué representa realmente el modelo y qué falta para llegar a donde se necesita.