OpenHIE Architecture Specification
5.0-es
5.0-es
  • Resumen de la especificación
  • Cómo utilizar la especificación
  • Especificación de la arquitectura
    • Arquitectura
    • Principios arquitectónicos
    • Estándares y Perfiles
  • Especificaciones de componentes de OpenHIE
    • Requisitos no funcionales
    • Registro de Clientes (CR)
    • Registro de instalaciones (FR) de OpenHIE
    • Servicio de Finanzas y Seguros (FIS) de OpenHIE
    • Sistema de Información de Gestión de Salud (HMIS) de OpenHIE
    • Registro de Trabajadores de la Salud (HWR) de OpenHIE
    • Capa de Interoperabilidad (IOL) de OpenHIE
    • Sistema de Información para la Gestión Logística (LMIS) de OpenHIE
    • Catálogo de productos (PC) de OpenHIE
    • Historia Clínica Compartida (SHR) de OpenHIE
    • Servicio de Terminología (TS) de OpenHIE
    • Sistemas de punto de atención
  • Especificaciones del flujo de trabajo (intercambio)
    • Flujos de trabajo de informes agregados
      • Exportar datos agregados
      • Validar y guardar datos agregados
    • Alertar/enviar recordatorios o información
      • Flujo de trabajo de envío de alertas a los clientes
      • Enviar flujo de trabajo de alerta al trabajador de la salud
    • Descubrir servicios de atención
      • Flujo de trabajo de consulta de registros de trabajadores de la salud o de instalaciones
      • Consulta de flujo de trabajo de registros de servicios de atención
      • Flujo de trabajo de la búsqueda de servicios de atención
      • Flujo de trabajo para la solicitud de actualizaciones de servicios de atención
    • Flujos de trabajo del laboratorio
      • Solicitar prueba de laboratorio
      • Resultados del laboratorio informados
    • Flujos de trabajo de gestión de la identidad del paciente
      • Descripción general del flujo de trabajo de creación de registros demográficos de pacientes
      • Actualizar el flujo de trabajo del registro demográfico del paciente
      • Flujo de trabajo de la consulta de registros demográficos de pacientes por datos demográficos
      • Query Patient Demographic Records by Demographics Workflow
    • Historia Clínica Compartida
      • Guardar flujo de trabajo de datos clínicos a nivel de paciente
      • Consultar el flujo de trabajo de datos clínicos del paciente
    • Flujos de trabajo del servicio de terminología
      • Expandir el conjunto de valores
      • Traducir el código
      • Verificación de código existente
      • Verificación de la membresía del código
      • Consulta del conjunto de valores
      • Consulta de los sistemas de códigos
      • Consulta de mapas conceptuales
      • Código de búsqueda
    • Flujos de trabajo de las vacunas
    • Flujos de trabajo de los servicios de seguros y finanzas de OpenHIE
      • HFW-001: Inscribir beneficiarios
      • HFW-002: Consulta del beneficiario
      • HFW-003: Revisar la elegibilidad para la cobertura
      • HFW-004: Reclamaciones
      • HFW-005: Seguimiento a la reclamación
  • Cómo hacer comentarios y contribuciones
  • Registro de cambios y control de versiones
Powered by GitBook
On this page
  • Requisitos del flujo de trabajo del CR de OpenHIE
  • Requisitos funcionales del CR de OpenHIE
  1. Especificaciones de componentes de OpenHIE

Registro de Clientes (CR)

PreviousRequisitos no funcionalesNextRegistro de instalaciones (FR) de OpenHIE

Last updated 2 years ago

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 es permitir que los distintos servicios de infraestructura (como el Registro de Clientes [Client Register, CR]) sean intercambiables. Para apoyar esto, los 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

principio básico de la arquitectura de OpenHIE
estándares y perfiles de OpenHIE