¿Qué debe ocurrir después de que un MPI encuentre una concordancia de paciente?
Un MPI ha identificado dos registros como una probable concordancia. El sistema puede mantener ambos registros y establecer una relación entre ellos, o consolidar un registro en otro.
Estas acciones se tratan a veces como pasos consecutivos dentro del mismo proceso. En la práctica, la concordancia solo identifica registros que pueden pertenecer a la misma persona. No determina qué debe ocurrir con ellos a continuación.
Mediante 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 registro de destino se convierte en la identidad activa del paciente, las referencias al registro de origen deben redirigirse y los valores en conflicto han de resolverse.
¿Cuándo es suficiente un vínculo y cuándo requiere el flujo de trabajo de identidad del paciente una fusión? La respuesta depende de la confianza en la concordancia, la titularidad de los datos, la procedencia, los flujos de trabajo dependientes y las consecuencias en caso de que la decisión resulte incorrecta.
Por qué una fusión incorrecta no equivale a una concordancia omitida
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 los registros de dos personas distintas, su información demográfica, administrativa y clínica puede pasar a formar parte de la misma identidad de paciente.
El Informe final de ONC sobre identificación y concordancia de pacientes describe las concordancias con falsos positivos como un riesgo para la seguridad del paciente mayor que las concordancias omitidas, 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 concordancia se configuran habitualmente para tolerar algunos duplicados sin resolver en lugar de aumentar el número de superposiciones.
Superposición de pacientes
Una superposición ocurre cuando la información de dos pacientes se mezcla en un mismo expediente médico.
El registro resultante puede contener información de otro paciente, como:
- alergias;
- medicamentos;
- diagnósticos;
- resultados de laboratorio;
- grupo sanguíneo;
- procedimientos.
La información clínica incorrecta puede afectar a las decisiones de tratamiento. Además, la fusión puede dar a un paciente acceso a la información sanitaria protegida (PHI) de otra persona a través de un portal del paciente, una solicitud de divulgación o una regla de acceso basada en identidad.
Cuando una fusión incorrecta da lugar a un acceso no autorizado o a la divulgación de PHI, el incidente puede tener que evaluarse conforme a la Norma de notificación de brechas de HIPAA. Según el 45 CFR Parte 164, se presume que el uso o la divulgación no permitidos de PHI constituyen una brecha, a menos que la entidad cubierta o el socio comercial demuestren una baja probabilidad de que la información haya sido comprometida.
Las consecuencias pueden, por tanto, ir más allá de la calidad de los datos y la seguridad clínica, y abarcar obligaciones de investigación, notificación y remediación.
Deshacer la fusión
Reactivar el registro de origen no restaura necesariamente el estado previo a 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 permiten deshacer la fusión únicamente mediante un proceso manual. Otros requieren reconstruir los registros originales a partir del historial de auditoría.
La trazabilidad debe, por tanto, diseñarse dentro del flujo de trabajo de fusión. La organización debe poder 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 identidad del paciente pueden ser consumidas por sistemas de historia clínica electrónica (HCE), laboratorios, sistemas de facturación, portales del paciente, entornos de analítica y aplicaciones de pagadores.
Una fusión incorrecta puede seguir afectando a estos sistemas una vez corregido el MPI. Cada destinatario necesita un mecanismo para 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 toda concordancia 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 concordancia aún no es concluyente
La concordancia probabilística divide habitualmente los resultados en concordancias definitivas, concordancias posibles y no concordancias.
Una concordancia definitiva puede ser elegible para procesamiento automatizado conforme a una política aprobada. Una concordancia posible requiere 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 primero datos que ya han sido fusionados.
El revisor puede confirmar la concordancia, rechazarla o dejar el caso sin resolver. La confirmación establece que los registros pertenecen a la misma persona. Por sí sola, no exige la consolidación física.
Los registros pertenecen a organizaciones distintas
Una red de intercambio de información sanitaria (HIE), una red de laboratorios, un grupo hospitalario o un intercambio entre pagadores y proveedores 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 compartida puede mapear los identificadores y recuperar información relacionada sin transferir la titularidad de los registros de origen.
El perfil IHE de Referencias Cruzadas de Identificadores de Paciente (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 la referenciación cruzada de pacientes dentro de comunidades sanitarias y entre ellas. La Plataforma de Estándares de Interoperabilidad de ONC enumera estos perfiles como enfoques en producción para el intercambio de información sobre identidad del paciente.
Sin un marco de gobernanza que autorice expresamente la consolidación, una concordancia entre organizaciones debe dar lugar a vinculación en lugar de fusión.
El contexto de origen debe preservarse
La información del paciente puede proceder de sistemas con distintos niveles de autoridad, completitud y fiabilidad.
Una fuente puede contener el nombre legal verificado. Otra 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 el origen de cada uno, cuándo se recibió y qué organización lo proporcionó.
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 eliminadas las fronteras originales entre fuentes.
El flujo de trabajo solo necesita una vista combinada
Un MPI de tipo registro mapea una identidad empresarial a los identificadores de paciente utilizados por los sistemas de origen individuales.
Las aplicaciones pueden usar esos vínculos para encontrar registros relacionados y presentarlos como una vista longitudinal del paciente. Los sistemas de origen permanecen inalterados y el MPI no se convierte en el propietario transaccional de sus datos clínicos.
Este modelo puede dar soporte al descubrimiento de registros, la analítica, la coordinación asistencial y el acceso entre sistemas sin crear un único registro físico del paciente. El informe de 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 consumidoras pueden operar con varios registros conectados. Deja de ser suficiente cuando un proceso operativo requiere una única identidad activa de paciente.
Un duplicado dentro de un mismo sistema HCE, 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 ese 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 sistema HCE, MPI u otro sistema controlado por la misma organización.
Puede haberse creado un segundo registro por una diferencia ortográfica, datos de registro incompletos, un identificador ausente o un registro duplicado durante una atención de urgencias. Una vez confirmado el duplicado, mantener ambos registros puede continuar perturbando 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 de fusión y las acciones esperadas de los sistemas participantes.
El perfil IHE de Registro de Identidad Maestra del Paciente (PMIR) describe un flujo de trabajo en el que múltiples identidades maestras se consolidan en una 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 justificada la consolidación física, 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 desactivado.
El destino no debe seleccionarse únicamente por haber sido creado primero. La decisión también puede depender de qué identificadores ya están en uso, la autoridad y completitud de cada registro, y los sistemas que los referencian.
Definir las reglas de supervivencia
Los registros duplicados confirmados pueden contener distintos nombres, identificadores, direcciones, números de teléfono y atributos demográficos.
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 accesibles mediante el 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 previo 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 a 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 a qué paciente original pertenece cada dato;
- cómo se reconstruye el estado previo a la fusión;
- cómo reciben la corrección los sistemas dependientes;
- cómo se gestionan los incidentes de privacidad y seguridad del paciente.
Estos controles forman parte de la preparación para la fusión, y no son trabajo a diseñar después del primer error.
Pasar de la detección de una concordancia a la 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 concordancia 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 concordancia y, cuando sea aplicable, una puntuación de confianza.
2. Clasificar el resultado
Cada candidato se asigna a una categoría operativa:
- concordancia definitiva;
- concordancia posible;
- no concordancia.
La organización define los umbrales y las acciones permitidas para cada categoría.
3. Revisar los casos inciertos
Las concordancias posibles permanecen separadas y entran en una cola de gestión.
El revisor examina la evidencia disponible y confirma la concordancia, la rechaza o deja el caso sin resolver.
4. Elegir la acción de identidad
Una concordancia confirmada puede permanecer vinculada cuando el flujo de trabajo solo necesita acceso a registros relacionados.
El caso procede a fusión cuando la consolidación está autorizada y un proceso requiere una única identidad activa de 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í:
concordancia → clasificar → revisar cuando sea necesario → vincular o fusionar
La vinculación es el resultado apropiado para los casos inciertos, la titularidad distribuida de los 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.
Concordancia, 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 de cada resultado. Dicha puntuación puede evaluarse entonces frente a los umbrales definidos por la organización.
Patient.link
Patient.link registra una relación entre recursos Patient que hacen referencia a la misma persona del mundo 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 un rastro de la relación entre los recursos.
FHIR separa estos mecanismos porque confirmar una concordancia de paciente no siempre requiere consolidar los registros.
Gestión del flujo de trabajo con MDMbox
MDMbox admite la concordancia, la vinculación, la gestión de datos y la fusión como partes independientes del flujo de trabajo de identidad del paciente.
Los equipos pueden usar Patient/$match para encontrar y puntuar candidatos. Los registros que deben permanecer separados pueden conectarse mediante Patient.link, mientras que las concordancias posibles pueden enrutarse para 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 que respalda estas acciones, incluidos los umbrales de concordancia, la autoridad de fusión, las responsabilidades de gestión de datos, las reglas de supervivencia y los sistemas que necesitan recibir las actualizaciones de identidad.
Verifique un flujo de trabajo antes de habilitar la fusión
La Lista de verificación de decisiones: ¿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 cubre la titularidad, la confianza en la concordancia y la necesidad de un único registro del paciente. La segunda verifica si los controles de fusión necesarios están implantados.
