Registro de Clientes (CR)

La identidad de una persona que recibe servicios de salud es fundamental para permitir el intercambio de historias clínicas entre instituciones y sistemas. Sin embargo, compartir las historias clínicas puede ser un reto en un entorno complejo en el que existen varios sistemas a través de múltiples instituciones de asistencia médica, y cada institución o sistema tiene una forma diferente de identificar a sus clientes. Incluso en entornos en los que se asignan tarjetas de identificación nacionales a los ciudadanos, es necesario garantizar la identidad única de una persona entre la gran cantidad de sistemas de información fragmentados que representan colectivamente la historia clínica electrónica de una persona. El Registro de Clientes está diseñado para ayudar a identificar de forma única a personas que reciben servicios de atención médica mediante las siguientes acciones:

• Mantener un registro central de todos los pacientes y sus datos demográficos y asignar un identificador único a cada uno.

• Vincular las entradas de registro de pacientes que se producen debido a cambios en los datos demográficos del paciente (traslado del paciente a otro lugar), errores de introducción de datos durante su registro o falta de información demográfica.

• Permitir al personal de salud identificar las instalaciones en los que un paciente ha recibido atención.

Consulte también “Requisitos no funcionales”.

Requisitos del flujo de trabajo del CR de OpenHIE

Un principio básico de la arquitectura de OpenHIE es permitir que los distintos servicios de infraestructura (como el Registro de Clientes [Client Register, CR]) sean intercambiables. Para apoyar esto, los estándares y perfiles de OpenHIE utilizados por el Registro de Clientes se describen en los siguientes flujos de trabajo. Para ser un componente del CR de OpenHIE (OHIE), la aplicación del RC debe ser capaz de soportar los flujos de trabajo de OHIE que se enumeran a continuación. Las implementaciones pueden admitir solo los flujos de trabajo necesarios para apoyar su caso de uso:

N.º	Flujos de trabajo del CR (descritos en detalle en la parte posterior de este documento)	Recomendación o requisito
CRWF-1	Un CR debe soportar el “flujo de trabajo para crear el registro demográfico del paciente”.	Requisito
CRWF-2	Un CR deberá soportar el “flujo de trabajo para actualizar el registro demográfico del paciente”.	Requisito

CRWF-3	Un CR deberá soportar el “flujo de trabajo de consulta de registros demográficos de pacientes por identificador”.	Requisito
CRWF-4	Un CR deberá soportar el “flujo de trabajo de consulta de registros demográficos de pacientes por datos demográficos”.	Requisito

Requisitos funcionales del CR de OpenHIE

Las siguientes son las características típicas de un registro de clientes o Índice Maestro de Pacientes. Según el caso o casos de uso deseados, el sistema puede soportar muchas o todas estas características funcionales.

N.º	Requisito funcional del CR	Recomendación o requisito
CRF-1	El sistema debe admitir la coincidencia de entidades configurable: un servicio que ayuda a identificar a los pacientes duplicados. a. Las reglas para determinar si dos registros coinciden entre sí deben ser configurables (p. ej., capacidad de utilizar tanto estadísticas como reglas, etc.). b. La estrategia de bloqueo para cargar posibles coincidencias antes de aplicar las reglas de coincidencia debe ser configurable. c. Cualquier componente configurable debe tener una interfaz para que los usuarios avanzados puedan escribir su propia implementación desde cero si lo desean. d. Cualquier interfaz debe tener al menos una implementación por defecto. e. La implementación por defecto debe ser flexible y configurable para que los no programadores puedan ajustarla a sus necesidades. f. En la medida de lo posible, la información sobre la configuración del sistema de CR	Recomendación

	debe gestionarse mediante métodos coherentes y de fácil acceso, como una base de datos, archivos de propiedades o archivos XML). g. Debe permitir una configuración "basada en un asistente" o "guiada" de las reglas de coincidencia.
CRF-2	El sistema deberá permitir la vinculación y la eliminación de duplicación de pacientes. a. El sistema deberá aplicar métodos precisos y eficaces de vinculación y eliminación de duplicación de pacientes. b. Deberá proporcionar una forma fácil e intuitiva de ver las operaciones de fusión/vinculación. c. Deberá permitir una forma fácil de usar e intuitiva de aceptar o rechazar manualmente las sugerencias de fusión, con la posibilidad de elegir los campos de cualquiera de los registros que se van a fusionar.	Requisito
CRF-3	El sistema debe permitir seguimiento y supervisión de transacciones de entrada/salida. a. El sistema debe tener la capacidad de registrar recepción y transmisión de transacciones.	Recomendación
CRF-4	El sistema debe soportar la sincronización de las identificaciones de los clientes con una Historia Clínica Compartida (Shared Health Record, SHR).	Recomendación
CRF-5	El sistema debe admitir una interfaz de usuario para revisar y adjudicar manualmente las coincidencias inciertas ("potenciales") y anular las coincidencias incorrectas.	Recomendación

CRF-6	El sistema debe admitir atributos configurables que incluyan: a. Los atributos que forman un registro de paciente y que se utilizan para la coincidencia deben ser configurables. b. La implementación puede incluir un esquema de paciente de ejemplo/por defecto. c. Debe ser fácil añadir atributos al esquema. d. También debe ser fácil eliminar atributos del modelo por defecto (o empezar de nuevo desde cero).	Recomendación
CRF-7	El sistema debe soportar la gestión de errores. a. Garantizar que la gestión de errores captura y registra de forma exhaustiva todas las excepciones relacionadas y, en la medida de lo posible, muestra las relaciones entre las excepciones.	Recomendación
CRF-8	El sistema debe gestionar un registro de auditoría completo de los cambios en los datos y en las configuraciones, así como de los usuarios.	Requisito
CRF-9	Privacidad y seguridad: el sistema debe tener funciones que incluyan gestión de usuarios y controles de acceso.	Recomendación
CRF-10	El sistema debe ser capaz de persistir la relación padre/hijo, el orden de nacimiento y el indicador de nacimiento múltiple.	Recomendación