Historia Clínica Compartida (SHR) de OpenHIE
La Historia Clínica Compartida (SHR) facilita el intercambio de información clínica entre los sistemas de información de salud para permitir una mejor atención al paciente, mejorando así los resultados de salud. La Historia Clínica Compartida es un medio que permite a diferentes servicios compartir datos de salud almacenados en un repositorio de datos centralizado. Contiene un subconjunto de datos normalizados de un paciente procedentes de varios sistemas, como el Historia clínica electrónica o el sistema de gestión de información de laboratorio. Este registro se consulta y actualiza entre las diferentes instituciones y sistemas que están autorizados a hacerlo. La Historia Clínica Compartida es diferente a un almacén de datos; es una fuente de datos transaccional operativa y en tiempo real.
Una Historia Clínica Compartida está normalizada si todos los elementos de metadatos, como identificadores del paciente, del proveedor y de la instalación, se resuelven con los identificadores universales apropiados (en contraposición a sus identificadores locales utilizados por un sistema de cliente). Además, todos los códigos terminológicos en uso deben asignarse a una terminología de referencia adecuada para garantizar que la información se entienda de forma coherente.
Consulte también “Requisitos no funcionales”.
Requisitos del flujo de trabajo del SHR de OpenHIE
Un principio básico de la arquitectura de OpenHIE es permitir que los distintos servicios de infraestructura (como SHR) sean intercambiables. Para apoyar esto, los Estándares y Perfiles de OpenHIE utilizados por la Historia Clínica Compartida se describen en los flujos de trabajo siguientes.
Para ser un componente del SHR de OHIE, la aplicación del SHR 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 SHR (descritos en detalle en la parte posterior de este documento) |
Recomendación o requisito |
SHRWF-1 | Flujo de trabajo para guardar datos clínicos del paciente. |
Requisito |
SHRWF-2 | Flujo de trabajo para consultar datos clínicos del paciente. |
Requisito |
Requisitos funcionales del SHR de OpenHIE
N.º |
Requisito funcional del SHR | Recomendación o requisito |
SHRF-1 |
Almacena los datos clínicos del paciente que conforman la historia clínica electrónica de un paciente. a. Almacena datos clínicos no estructurados como PDF y texto narrativo. b. Almacena datos clínicos estructurados, como un encuentro con varias observaciones discretas, compatibles con un formato de intercambio estándar. c. Relaciona información clínica con otra, p. ej., anotar/describir un documento con observaciones discretas. |
Recomendación |
SHRF-2 | Expone servicios que tengan la capacidad de recibir y guardar datos clínicos de pacientes en forma no estructurada, tanto de texto como binaria (PDF/imagen), anotados con suficientes metadatos para identificar al paciente o al proveedor |
Recomendación |
SHRF-3 | Expone servicios que tengan la capacidad de recibir y guardar datos clínicos de pacientes en un formato estructurado, como documentos de Arquitectura de Documentos Clínicos (Clinical Document Architecture, CDA) o recursos de FHIR. |
Recomendación |
SHRF-4 | Expone servicios que tengan la capacidad de recibir y guardar datos clínicos de pacientes en un formulario que contenga elementos estructurados y no estructurados. |
Recomendación |
SHRF-5 |
Expone servicios que responden a consultas para la HCE de un paciente. a. Puede devolver un documento específico conocido o una lista de documentos para un paciente (tal y como fue enviado). b. Puede devolver una lista de observaciones discretas para un paciente que satisfaga parámetros de consulta específicos. Estos datos pueden utilizarse posteriormente para establecer tendencias o proporcionar los encuentros anteriores que ha tenido un paciente. c. Puede devolver un conjunto completo de información clínica almacenada sobre un paciente. d. Devuelve el resumen del paciente; todo lo que el SHR sabe sobre un paciente con enlaces para obtener los elementos de datos individuales. |
Recomendación |
SHRF-6 | El SHR deberá mantener el contexto en el que se presentaron los datos. |
Recomendación |
|
El SHR deberá mantener registros de auditoría detallados de todas las interacciones con los datos clínicos. a. Mantiene registros de auditoría de cualquier dato clínico y demográfico que se almacene o modifique. NO es necesario registrar quién ha accedido/visto la información clínica, |
|
SHRF-7 | esto es algo que podría registrar una capa de interoperabilidad. b. Registros y actualizaciones de versiones; los registros nunca pueden ser borrados, solo marcados como tales; cualquier actualización anterior no debe reescribir los datos antiguos; ninguna información debe ser eliminada del sistema. | Recomendación |
SHRF-8 | El SHR debería soportar la capacidad de exportar datos para un uso secundario. |
Recomendación |
SHRF-9 | El SHR debe proporcionar interfaces/puntos de extensión en varias etapas del ciclo de vida de los datos para permitir validación semántica o apoyo a la decisión simple. |
Recomendación |
SHRF-10 | El SHR debe permitir almacenamiento y recuperación de restricciones básicas de privacidad/política (control de acceso: restringir parte del registro y restringir todo el registro). |
Recomendación |
SHRF-11 | El SHR debe ser capaz de almacenar datos de observación identificados y predefinidos, asignados a una terminología de referencia estándar. |
Recomendación |
SHRF-12 | El SHR debe tener un mecanismo para resolver conflictos si los registros se presentan simultáneamente. |
Recomendación |
Last updated