Los proveedores de MPI no lograron ponerse de acuerdo. Nosotros resolvimos la fusión de pacientes

Tras dos décadas de trabajo, el comité IHE PIX/PDQ dejó deliberadamente la semántica de fusión de pacientes como definida por la implementación. El estándar establece que las fusiones ocurren dentro de un Dominio de Identidad de Paciente, pero no llega a especificar qué hace una fusión, dejando «la responsabilidad de la calidad y gestión de la información demográfica de pacientes dentro de cada Dominio de Identidad de Paciente». Eso no es una laguna en la especificación, sino un reconocimiento: no existe una única fusión correcta.

IHE no es el único. Una revisión reciente del sector califica las operaciones de fusión como «procedimientos operativos dispersos en lugar de un marco unificado y localizable»: ningún organismo de normalización ni ningún regulador ha cerrado esa brecha. ONC y CMS exigen registros de auditoría y siguen elevando las tasas de coincidencia; ninguno prescribe el procedimiento de fusión en sí. Es el mismo reconocimiento que hizo IHE, pero en otra capa.

Nuestro artículo anterior terminó prometiendo $unmerge. Esa promesa sigue en pie, pero quedó pendiente una pregunta: por qué deberían funcionar así la fusión y la desfusión. Este artículo cierra esa brecha. Trata de por qué una fusión dirigida por el servidor no puede funcionar, por muy sofisticado que sea el servidor.

Lo que la especificación FHIR ofrece hoy

FHIR R5 define Patient/$merge en el nivel de madurez 0. Entradas: source-patient, target-patient, result-patient opcional. Se espera que el servidor desactive el origen, copie los identificadores y actualice las referencias. Cómo hace cada una de estas cosas queda a cargo de la implementación. La operación no ha avanzado del nivel de madurez 0 desde que se publicó R5.

La razón no es falta de esfuerzo, sino que cada parte de la «fusión» es una decisión de política, y las políticas varían de forma estructural: entre proveedores, entre despliegues y entre jurisdicciones.

Fusión y enlace son puntos en el mismo espectro

Antes de los ejes, conviene replantear el marco. La fusión y el enlace suelen agruparse como operaciones rivales, pero son puntos en el mismo espectro.

En el extremo del enlace, ambos registros sobreviven, las referencias permanecen donde apuntan, ambos siguen activos y los datos derivados permanecen asociados a cada uno. En el extremo de la fusión, la regla de supervivencia decide qué campos prevalecen, las referencias se reescriben, el origen se desactiva o elimina y los datos derivados deben reconsiderarse. Las implementaciones reales se sitúan entre esos dos polos: CommonWell gradúa explícitamente la solidez del enlace; Oracle Health Millennium mantiene el origen inactivo pero accesible por ID; VistA realiza un borrado definitivo; NHS PDS retira el identificador antiguo y redirige las consultas históricas. Cuanto más se comporta una implementación como un enlace, menos se compromete con el estado superviviente. Cuanto más se comporta como una fusión, más política tiene que asumir.

Los cuatro ejes que se describen a continuación definen dónde se sitúa una implementación en ese espectro. No son variaciones menores dentro de «la fusión como operación», sino lo que separa el enlace de la fusión. Una vez que cada eje admite múltiples respuestas legítimas, las combinaciones se multiplican rápidamente.

Cuatro ejes de variabilidad

Supervivencia — qué campos sobreviven

Cuando se combinan dos registros de paciente, docenas de campos entran en conflicto: nombre, dirección, teléfono, identificadores, alergias, lista de problemas, medicamentos, estado de reanimación. Qué valor prevalece es la regla de supervivencia.

Todos los proveedores serios de MPI exponen esto como configurable, no codificado de forma fija:

• IBM InfoSphere MDM incluye cuatro reglas distintas de supervivencia para fusión de partes como clases Java conectables, que se activan durante la detección de duplicados sospechosos y la contracción explícita de partes. La regla es un parámetro de configuración, no un algoritmo codificado de forma fija.
• Verato ofrece Auto-Steward y Smart Steward como productos de administración diferenciados: uno resuelve duplicados automáticamente contra una base de datos de referencia, el otro proporciona recomendaciones asistidas por IA para administradores humanos — dos respuestas distintas a la pregunta «¿puede automatizarse esta decisión?».
• Smile CDR, un MDM nativo de FHIR, convierte la supervivencia en un manejador JavaScript que escribe el cliente. Se proporcionan utilidades auxiliares mergeAll() y replaceAll(); el manejador las compone o implementa su propia lógica a nivel de campo. No existe un valor predeterminado: el cliente se ve obligado a hacer explícita la decisión de política.

Si existiera una única estrategia de supervivencia correcta, los proveedores la habrían codificado de forma fija. No lo hicieron porque no existe.

El coste cuando la política falla es inmediato. Un caso de AHRQ PSNet describe a una paciente cuya alergia al contraste fue eliminada durante la reconciliación porque un clínico la consideró «no una alergia verdadera». La HCE mostró entonces «sin alergias conocidas» y la paciente fue posteriormente programada para una TC con contraste. Es el mismo tipo de fallo que una fusión ingenua: una regla de «descartar fuentes de baja calidad» borró silenciosamente datos con relevancia clínica. Una política de supervivencia diferente — nunca eliminar una alergia, siempre marcarla para revisión — lo habría detectado.

La guía de identificación de pacientes de ECRI nombra directamente la preferencia direccional: «los registros duplicados son preferibles a los registros fusionados erróneamente». Mejor mantener los registros separados que combinarlos incorrectamente. La regla no puede codificarse de forma genérica porque «erróneo» lo define el contexto clínico que el servidor no puede ver.

Gestión de referencias — qué hacer con los punteros al registro origen

Toda fusión tiene una segunda pregunta: docenas o miles de recursos hacen referencia al paciente origen: Encounters, Observations, Claims, Appointments. ¿Qué ocurre con esas referencias?

Las implementaciones públicas dan respuestas distintas:

• Oracle Health Millennium (Cerner) devuelve un paciente combinado como inactivo con un enlace al paciente actual, y documenta que se admite la separación del paciente.
• VistA (VA) traslada los datos de FROM a TO, redirige los archivos afectados y elimina el registro FROM como registro activo. Si un campo está relleno en FROM y vacío en TO, ese valor se fusiona automáticamente; para obtener un resultado vacío en su lugar, el valor origen debe eliminarse fuera del flujo de fusión.
• CommonWell Health Alliance, un intercambio de información sanitaria a escala nacional en EE. UU., modela la identidad como enlaces entre organizaciones en lugar de un único registro superviviente fusionado. Esos enlaces se gradúan con Niveles de Aseguramiento de Enlace (LOLA, por sus siglas en inglés).
• NHS England's PDS fusiona números NHS duplicados confirmados en un único número superviviente, y su documentación de API explica cómo los números NHS supersedidos devuelven un número de reemplazo.

Cuatro formas, cuatro posiciones diferentes en el espectro enlace↔fusión. Algunas mantienen ambos registros y resuelven la identidad mediante enlaces. Otras redirigen todas las referencias al superviviente en el momento de la fusión. Algunas conservan el origen como un registro inactivo que los clientes aún pueden resolver. Otras se apoyan en un mecanismo de puntero separado entre la identidad antigua y la actual. Todas son defendibles en su propio contexto.

Disposición del origen — qué ocurre con el registro origen

La gestión de referencias trata los punteros entrantes. La disposición del origen es diferente: ¿qué le sucede al propio registro origen tras la fusión? La especificación del FHIR admin-incubator enumera dos resultados permitidos en una sola frase: «un GET sobre el ID del recurso Patient origen devolverá 200 OK (inactivo, replaced-by relleno) o 404 not found (cuando el sistema de fusión eliminó el recurso)». Los despliegues reales añaden más variantes sobre eso:

• Inactivo con enlace replaced-by. Oracle Health Millennium utiliza exactamente este modelo: el origen se devuelve como inactivo y enlazado al paciente actual, accesible únicamente mediante búsqueda directa por ID, nunca a través de búsquedas generales.
• Borrado definitivo. VistA traslada los datos del registro FROM al TO, redirige los archivos afectados y elimina el registro FROM como registro activo. Un GET posterior no encuentra nada.
• Identificador supersedido, nuevo número canónico. NHS England's PDS retira el número NHS antiguo como superseded y emite uno de reemplazo; las consultas históricas se redirigen al superviviente en lugar de conservarse el propio registro origen.
• Obsoleto pero rastreado en una máquina de estados separada. IBM Initiate mantiene el miembro obsoleto con su propia fila y tipo de enlace Merged, conservando el EID del superviviente. El origen no está ni activo ni eliminado: se encuentra en un estado de ciclo de vida diferenciado para que el MDM pueda seguir razonando sobre él.

A esto se suman las normas de retención y borrado específicas de cada jurisdicción: el Artículo 17 del RGPD en la UE, la segmentación del 42 CFR Part 2 en EE. UU., los estatutos estatales de consentimiento de menores, cada uno de los cuales condiciona lo que el registro origen puede o debe convertirse. El marco federal de EE. UU. muestra el mismo patrón por omisión: ONC y CMS exigen auditabilidad y calidad de datos, mientras que iniciativas como la MATCH IT Act reintroducida en marzo de 2025 y TEFCA impulsan la calidad de la identidad hacia arriba en la cadena. Intentan reducir la necesidad de fusión; aún no prescriben el procedimiento de fusión en sí.

Efectos en cascada — artefactos derivados y trabajo posterior

Fusionar el registro del paciente es solo el problema de primer orden. El problema de segundo orden es todo lo derivado del registro que no sigue mecánicamente una reescritura de referencias: grafos de enlace dentro del MDM, cálculos acumulativos como la dosis acumulada de radiación o los totales acumulados de opioides, cachés de terceros. Dos ejemplos públicos ilustran el punto:

• IBM Initiate documenta que cuando el miembro C se fusiona en una nueva entidad, los miembros A y B previamente vinculados a C no siguen automáticamente. Cada uno obtiene un nuevo EID y vuelve a pasar por el proceso de comparación. La fusión no cierra transitivamente el grafo de enlace: el MDM lo reevalúa y algunos registros previamente vinculados pueden terminar asociados a otro lugar o a ninguno.
• La documentación pública de EHI de Epic reserva un flujo de trabajo de revisión explícito sobre el historial de dosis acumulada a lo largo de la vida tras la fusión. La tabla PAT_LIFEDOSE_HX tiene columnas dedicadas a quién revisó la entrada tras la fusión/desfusión, cuándo, y una enumeración de motivo de revisión que incluye Patient Merge, Patient Unmerge, Patient Contact Move, con estados Need Review, Accepted, Rejected. Para los cálculos clínicos acumulativos, la distribución automatizada se considera insegura: una persona debe adjudicar qué corresponde a cada caso.

El hilo común: algunos artefactos post-fusión no pueden reescribirse en la misma transacción. Requieren reevaluación (grafo de enlaces del MDM), enrutamiento a una cola de revisión (dosis acumulada) o reconciliación con sistemas externos que cachearon la identidad antigua. Un servidor que trata la fusión como «cambiar referencias y seguir adelante» descarta silenciosamente esta clase de trabajo.

Dónde se traza la línea

Nótese el patrón. La fusión en el lado del servidor quiere ser un único algoritmo. La realidad son al menos cuatro ejes de política independientes, cada uno con múltiples variantes en producción. Eso es una explosión combinatoria antes de que entren en juego los requisitos regulatorios.

La salida no es un servidor más inteligente, sino trasladar la política a donde vive la política: el cliente. En nuestro $merge, el cliente envía un Bundle de transacción que describe cada PUT, POST y DELETE. El servidor posee las invariantes: atomicidad, auditoría, comprobaciones anti-fusión-circular, bloqueo optimista mediante ifMatch. El cliente posee la política: qué campos sobreviven, cómo se reescriben las referencias, qué ocurre con el origen y qué trabajo posterior debe enrutarse a una cola de revisión.

El registro de auditoría no es un complemento agradable. El kit de herramientas de identificación de pacientes de ECRI y las normas de documentación de CMS exigen efectivamente el mismo registro: quién realizó la fusión, cuándo, por qué, una instantánea previa a la fusión de ambos registros y la lista de recursos afectados. Trasladado a FHIR, eso es una Task (operación, actor, motivo, origen/destino vinculados), una entrada de Provenance en cada recurso modificado y la History API de FHIR para la instantánea previa a la fusión, todo escrito en la misma transacción que la propia fusión. Si cualquiera de estos elementos se divide en transacciones distintas, la auditoría deja de ser una única fuente de verdad.

La desfusión plantea la misma pregunta con mayor complejidad. Cuando la fusión ocurrió el lunes y el martes se publicaron tres nuevos Encounters en el registro destino, ¿a dónde van el miércoles: de vuelta al origen restaurado, distribuidos, o se mantienen en el destino? Cuando el origen fue borrado definitivamente, ¿puede recrearse? No existe una respuesta general. Por eso nuestro $unmerge refleja $merge: el servidor posee las invariantes, el cliente posee la política — la única forma que sabemos cómo hacer segura a esta escala. Describimos el diseño completo en Designing $unmerge: Reversing the FHIR Patient Merge. Para contexto sobre la mecánica subyacente de coincidencia y Maestro de Pacientes, véase Master Patient Index (MPI): How It Works + Examples.

¿Desea probar la fusión dirigida por el cliente en su proyecto? MDMbox está disponible hoy mismo.