¿Qué debe ocurrir después de que un MPI encuentra una coincidencia de paciente?
Un MPI ha identificado dos registros como una posible coincidencia. El sistema puede conservar ambos registros y establecer una relación entre ellos, o consolidar uno en otro.
Estas acciones se tratan a veces como pasos consecutivos dentro del mismo proceso. En la práctica, la coincidencia solo identifica registros que pueden pertenecer a la misma persona. No determina qué debe ocurrir con ellos a continuación.
Con la vinculación, las aplicaciones pueden recuperar registros relacionados, mapear identificadores entre sistemas y construir una vista longitudinal del paciente mientras los registros originales permanecen intactos.
La fusión modifica los propios registros. El destino se convierte en la identidad activa del paciente, las referencias al origen deben redirigirse y los valores en conflicto han de resolverse.
¿Cuándo es suficiente una vinculación y cuándo requiere un flujo de identidad del paciente una fusión? La respuesta depende de la confianza en la coincidencia, la titularidad de los datos, la procedencia, los flujos de trabajo posteriores y lo que ocurre si la decisión resulta ser incorrecta.
Por qué una fusión incorrecta no equivale a una coincidencia no detectada
Un falso negativo deja separados los registros del mismo paciente. El historial del paciente puede quedar incompleto, pero los datos siguen asignados a las identidades originales.
Un falso positivo tiene un efecto diferente. Una vez que se fusionan registros pertenecientes a dos personas distintas, su información demográfica, administrativa y clínica puede pasar a formar parte de la misma identidad del paciente.
El Informe Final sobre Identificación y Coincidencia de Pacientes de la ONC describe las coincidencias de falsos positivos como un riesgo para la seguridad del paciente mayor que las coincidencias no detectadas, porque la atención puede prestarse utilizando información que pertenece a otra persona. Esta asimetría es una de las razones por las que los sistemas de coincidencia se configuran habitualmente para tolerar algunos duplicados no resueltos en lugar de aumentar el número de superposiciones.
Superposición de pacientes
Una superposición ocurre cuando se mezcla en un mismo historial médico información perteneciente a dos pacientes.
El registro resultante puede contener datos de otro paciente, como:
- alergias;
- medicación;
- diagnósticos;
- resultados de laboratorio;
- grupo sanguíneo;
- procedimientos.
La información clínica incorrecta puede afectar a las decisiones de tratamiento. La fusión también puede dar a un paciente acceso a la información sanitaria protegida de otra persona a través de un portal de pacientes, una solicitud de divulgación o una regla de acceso basada en identidad.
Cuando una fusión incorrecta da lugar a un acceso o divulgación no autorizados de PHI, el incidente puede tener que evaluarse conforme a la Norma de Notificación de Brechas de HIPAA. Con arreglo a 45 CFR Parte 164, se presume que un uso o divulgación no permitidos de PHI constituyen una brecha, salvo que la entidad cubierta o el socio comercial demuestren una baja probabilidad de que la información se haya visto comprometida.
Las consecuencias pueden extenderse, por tanto, más allá de la calidad de los datos y la seguridad clínica, hasta abarcar obligaciones de investigación, notificación y remediación.
Reversión de la fusión
Reactivar el registro de origen no restaura necesariamente el estado existente antes de la fusión.
El equipo de corrección puede tener que revisar encuentros, observaciones, documentos, reclamaciones y otros recursos para determinar a qué paciente pertenecía cada elemento. Algunos sistemas admiten la reversión solo mediante un proceso manual. Otros requieren que los registros originales se reconstruyan a partir del historial de auditoría.
La trazabilidad debe, por tanto, estar diseñada dentro del flujo de trabajo de fusión. La organización debe ser capaz de identificar los registros de origen y destino, los valores modificados, la persona que aprobó la acción y la evidencia utilizada en la decisión.
Propagación a sistemas dependientes
Las actualizaciones de la identidad del paciente pueden ser consumidas por historiales clínicos electrónicos, laboratorios, sistemas de facturación, portales de pacientes, entornos de analítica y aplicaciones de pagadores.
Una fusión incorrecta puede seguir afectando a estos sistemas después de que el MPI haya sido corregido. Cada destinatario necesita una forma de procesar la corrección y determinar qué datos recibidos anteriormente deben modificarse.
Cuanto más amplia sea la distribución de la identidad del paciente, menos útil resulta tratar la fusión como una operación local de base de datos.
Cuándo los registros de pacientes deben permanecer separados
Los riesgos de la fusión no significan que cada coincidencia deba quedar sin resolver. Significan que reconocer a una misma persona en distintos registros y consolidar físicamente esos registros deben tratarse como decisiones independientes.
La coincidencia aún no es concluyente
La coincidencia probabilística divide habitualmente los resultados en coincidencias definitivas, coincidencias posibles y no coincidencias.
Una coincidencia definitiva puede calificar para un procesamiento automatizado bajo una política aprobada. Una coincidencia posible necesita revisión adicional.
Mientras el caso está en revisión, ambos registros permanecen disponibles. Un responsable de datos puede inspeccionar identificadores, atributos demográficos, valores ausentes, fiabilidad de la fuente y eventos de identidad anteriores sin necesidad de separar previamente datos que ya hayan sido fusionados.
El revisor puede confirmar la coincidencia, rechazarla o dejar el caso sin resolver. La confirmación establece que los registros pertenecen a la misma persona. Por sí sola, no requiere consolidación física.
Los registros pertenecen a organizaciones diferentes
Una HIE, una red de laboratorios, un grupo hospitalario o un intercambio entre pagador y proveedor puede necesitar reconocer que varios identificadores locales hacen referencia a la misma persona.
Cada participante sigue manteniendo su propio registro de paciente y sigue siendo responsable de sus datos. Un servicio de identidad compartido puede mapear los identificadores y recuperar información relacionada sin transferir la titularidad de los registros de origen.
El perfil de Referencias Cruzadas de Identificadores de Pacientes de IHE (PIX), el perfil de Consulta Demográfica de Pacientes (PDQ) y el perfil de Descubrimiento de Pacientes entre Comunidades (XCPD) abordan la identificación y las referencias cruzadas de pacientes dentro de las comunidades sanitarias y entre ellas. La Plataforma de Estándares de Interoperabilidad de la ONC enumera estos perfiles como enfoques a nivel de producción para el intercambio de información de identidad del paciente.
Sin un marco de gobernanza que autorice expresamente la consolidación, una coincidencia entre organizaciones debería dar lugar a una vinculación en lugar de una fusión.
El contexto de origen debe preservarse
La información del paciente puede provenir de sistemas con distintos niveles de autoridad, completitud y fiabilidad.
Un origen puede contener un nombre legal verificado. Otro puede tener una dirección o un número de teléfono más reciente. Mantener los registros separados permite mostrar estos valores conjuntamente, conservando al mismo tiempo de dónde proviene cada valor, cuándo se recibió y qué organización lo suministró.
Esto favorece de forma natural los requisitos de procedencia y auditoría. Un registro fusionado también puede preservar la procedencia, pero la implementación debe almacenarla explícitamente una vez que los límites originales de la fuente han sido eliminados.
El flujo de trabajo solo necesita una vista combinada
Un MPI de tipo registro mapea una identidad empresarial con los identificadores de paciente utilizados por los sistemas de origen individuales.
Las aplicaciones pueden utilizar esos vínculos para encontrar registros relacionados y presentarlos como una vista longitudinal del paciente. Los sistemas de origen permanecen sin cambios y el MPI no se convierte en el propietario transaccional de sus datos clínicos.
Este modelo puede respaldar el descubrimiento de registros, la analítica, la coordinación de la atención y el acceso entre sistemas sin crear un único registro físico del paciente. El Informe de la ONC sobre Gestión de Datos Maestros en Infraestructuras HIE describe este uso de un identificador maestro para conectar identidades de pacientes locales en sistemas distribuidos.
Cuándo un único registro físico se vuelve necesario
La vinculación funciona mientras las aplicaciones que consumen los datos pueden operar con varios registros conectados. Deja de ser suficiente cuando un proceso operativo requiere una única identidad activa del paciente.
Un duplicado dentro de un único historial clínico electrónico, por ejemplo, puede interferir con la facturación, las actualizaciones transaccionales, el acceso basado en identidad o el mantenimiento de un sistema centralizado de registro. En este caso, recuperar los registros relacionados conjuntamente no resuelve el problema. El propio duplicado debe eliminarse.
Antes de proceder, la organización debe establecer tres cosas:
- Tiene autoridad para consolidar ambos registros.
- Se ha confirmado que los registros pertenecen a la misma persona.
- Una vista vinculada no puede satisfacer el requisito operativo.
El caso más claro de fusión es un duplicado confirmado dentro de un mismo historial clínico electrónico, MPI u otro sistema controlado por la misma organización.
Puede haberse creado un segundo registro a causa de una diferencia ortográfica, datos de registro incompletos, un identificador ausente o un registro duplicado durante un encuentro de urgencias. Una vez confirmado el duplicado, mantener ambos registros puede seguir alterando los procesos que dependen de un único ID de paciente.
La fusión entre organizaciones es un caso aparte. Requiere un marco de gobernanza acordado que defina la titularidad de la identidad resultante, la autoridad para fusionar y las acciones esperadas de los sistemas participantes.
El perfil de Registro Maestro de Identidad del Paciente de IHE (PMIR) describe un flujo de trabajo en el que varias identidades maestras se consolidan en una única Identidad Dorada del Paciente y la decisión se distribuye a los propietarios de los datos. Sin este tipo de gobernanza, la gestión de identidad entre organizaciones sigue siendo un caso de uso de vinculación.
Qué debe resolverse antes de la fusión
Una vez que la consolidación física está justificada, el equipo debe determinar cómo la fusión modificará la identidad del paciente y los datos vinculados a ella.
Seleccionar el origen y el destino
Un registro se convierte en la identidad de destino. El otro se convierte en el origen que es reemplazado o marcado como inactivo.
El destino no debe seleccionarse únicamente porque fue creado primero. La decisión también puede depender de qué identificadores ya están en uso, la autoridad y la completitud de cada registro, y los sistemas que los referencian.
Definir las reglas de supervivencia
Los registros duplicados confirmados pueden contener nombres, identificadores, direcciones, números de teléfono y atributos demográficos diferentes.
Las reglas de supervivencia determinan qué valores se escriben en el destino. Pueden priorizar:
- una fuente más autorizada;
- un valor verificado;
- el valor más reciente;
- el registro más completo;
- una decisión tomada por un responsable de datos.
Los valores que no sobrevivan deben permanecer disponibles a través del historial del recurso, la procedencia u otro mecanismo de auditoría. De lo contrario, puede resultar imposible explicar cómo se creó el registro de destino o reconstruir el estado anterior a la fusión.
Con la vinculación, estos conflictos no necesitan resolverse de inmediato. Cada valor permanece en su registro de origen y puede presentarse con su contexto original.
Redirigir las referencias
Los datos clínicos, administrativos y financieros pueden ya referenciar al paciente de origen.
Una fusión debe identificar esas referencias y redirigirlas al destino. El alcance puede extenderse más allá de los datos almacenados en el MPI, hasta las aplicaciones conectadas que ya han recibido o copiado la identidad.
Prepararse para la corrección
La organización necesita comprender qué pueden y qué no pueden revertir automáticamente sus sistemas.
Un proceso de corrección debe definir:
- cómo se detecta e investiga una fusión incorrecta;
- quién decide qué datos pertenecen a cada paciente original;
- cómo se reconstruye el estado anterior a la fusión;
- cómo reciben los sistemas dependientes la corrección;
- cómo se gestionan los incidentes de privacidad y seguridad del paciente.
Estos controles forman parte de la preparación para la fusión, no son trabajo que deba diseñarse después de que se produzca el primer error.
Pasar de una coincidencia al descubrimiento de fusión
Un flujo de trabajo controlado de identidad del paciente separa la generación de candidatos, la confirmación de identidad y la consolidación física.
1. Encontrar candidatos
El motor de coincidencia compara identificadores y atributos demográficos y devuelve registros que pueden pertenecer a la misma persona.
El resultado debe incluir la evidencia utilizada en la coincidencia y, cuando corresponda, una puntuación de confianza.
2. Clasificar el resultado
Cada candidato se asigna a una categoría operativa:
- coincidencia definitiva;
- coincidencia posible;
- sin coincidencia.
La organización define los umbrales y las acciones permitidas para cada categoría.
3. Revisar los casos inciertos
Las coincidencias posibles permanecen separadas y entran en una cola de gestión.
El revisor examina la evidencia disponible y confirma la coincidencia, la rechaza o deja el caso sin resolver.
4. Elegir la acción de identidad
Una coincidencia confirmada puede permanecer vinculada cuando el flujo de trabajo solo necesita acceso a los registros relacionados.
El caso avanza hacia la fusión cuando la consolidación está autorizada y un proceso requiere una única identidad activa del paciente.
5. Aplicar los controles de fusión
Antes de la consolidación, el equipo selecciona el registro de destino, aplica las reglas de supervivencia, preserva el historial de decisiones e identifica los sistemas dependientes afectados.
El flujo de trabajo puede resumirse así:
coincidencia → clasificar → revisar cuando sea necesario → vincular o fusionar
La vinculación es el resultado apropiado para los casos inciertos, la titularidad distribuida de datos y los flujos de trabajo que solo necesitan una vista combinada. La fusión se reserva para los casos confirmados en los que un único registro físico es operativamente necesario.
Coincidencia, vinculación y fusión de pacientes en FHIR
FHIR proporciona un mecanismo independiente para cada parte del flujo de trabajo.
Patient/$match
Patient/$match acepta información de identidad del paciente y devuelve recursos Patient candidatos.
Las implementaciones pueden incluir una puntuación de 0 a 1 que representa la confianza en cada resultado. La puntuación puede evaluarse a continuación frente a los umbrales de la organización.
Patient.link
Patient.link registra una relación entre recursos Patient que hacen referencia a la misma persona real.
Los recursos permanecen separados y conservan sus identificadores y datos originales. Esto hace que Patient.link sea adecuado para referencias cruzadas, implementaciones de MPI de tipo registro y relaciones que pueden necesitar revisarse o eliminarse.
FHIR define cuatro tipos de vínculo de Patient: replaced-by, replaces, refer y seealso.
Patient/$merge
Patient/$merge consolida un recurso Patient de origen en un recurso Patient de destino.
Las referencias al origen se redirigen al destino. El origen queda inactivo, mientras que los vínculos replaced-by y replaces preservan una traza de la relación entre los recursos.
FHIR separa estos mecanismos porque confirmar una coincidencia de paciente no siempre requiere consolidar los registros.
Gestión del flujo de trabajo con MDMbox
MDMbox admite la coincidencia, la vinculación, la gestión y la fusión como partes independientes del flujo de trabajo de identidad del paciente.
Los equipos pueden utilizar Patient/$match para encontrar y puntuar candidatos. Los registros que deben permanecer separados pueden conectarse mediante Patient.link, mientras que las coincidencias posibles pueden enrutarse para su revisión.
Cuando un duplicado confirmado debe consolidarse, Patient/$merge redirige las referencias al destino y preserva la relación entre los recursos Patient.
La organización define la política detrás de estas acciones, incluidos los umbrales de coincidencia, la autoridad para fusionar, las responsabilidades de gestión, las reglas de supervivencia y los sistemas que necesitan recibir actualizaciones de identidad.
Verifique un flujo de trabajo antes de habilitar la fusión
La Lista de Verificación para la Decisión de Vincular o Fusionar la Identidad del Paciente ayuda a los equipos a determinar si un flujo de trabajo requiere vinculación, revisión de gestión o consolidación física.
La primera parte abarca la titularidad, la confianza en la coincidencia y la necesidad de un único registro de paciente. La segunda comprueba si los controles de fusión requeridos están en vigor.
