Historia Clínica Personal Personal Health Record (PHR) en FHIR

FHIR es un estándar marco que define una forma común de resolver problemas de atención médica y proporciona un conjunto de recursos que se pueden usar de muchas maneras diferentes. Esta página describe cómo se implementan ciertos escenarios de uso común utilizando las capacidades que define FHIR. Los escenarios proporcionados son ejemplos de uso y no son de ninguna manera exhaustivos. FHIR puede y será utilizado en una amplia variedad de circunstancias.

La diferencia fundamental  respecto a la Historia Clinica Electrónica (HCE) es que la Historia Clinica Personal es mantenida por el paciente mientras que la HCE es mantenida por el médico.

La Historia Clínica personal  Personal Health Record PHR en español Registro Personal de Salud RPS: Es un registro de información clínica informatizado en donde solo el paciente es el que lleva la información de los distintos eventos relacionados con su salud. Este modelo tiene la ventaja de que el paciente puede tener toda la información relevante de su salud a su alcance y como desventaja que no siempre el paciente está en condiciones de entender que es relevante o no para el cuidado de su salud.

En el escenario de  la PHR,  proporciona una API RESTful que permite a los pacientes acceder a su propia historia clínica a través de un portal web común o aplicación móvil, generalmente proporcionada por un tercero fiesta. En este escenario, el proveedor de PHR:

Proporciona al paciente un inicio de sesión que los identifica (o vincula el registro del paciente a una identidad externa proporcionada por OpenID, Facebook, Google, etc.)

Autentica al cliente usando un servidor OAuth apropiado para el inicio de sesión (posiblemente el suyo) y restringe al cliente a ver los registros asociados con el paciente específico (o pacientes, donde se ha organizado el acceso apropiado).

La HCE expone un servidor FHIR que admite las operaciones de búsqueda y lectura en los siguientes recursos:

el recurso del paciente para proporcionar datos demográficos al cliente. Cuando un cliente busca pacientes sin criterios de búsqueda, obtienen una lista de todos los pacientes a los que tienen acceso

busque y lea en el recurso de referencia del documento para proporcionar acceso a los documentos generales del paciente en forma de archivos PDF, etc. (se prefieren los archivos PDF)

buscar y leer en un conjunto de recursos clínicos

Aquí está la Declaración de Capacidades para este escenario: XML o JSON.

El EMR también puede optar por proporcionar funcionalidad adicional, como acceso compartido a los registros del paciente por parientes / cuidadores, para permitir al paciente cargar sus propios documentos, declaraciones de medicamentos, observaciones (por ejemplo, desde dispositivos de monitorización del paciente) y / o permitir al paciente para hacer citas Esta funcionalidad adicional implicará capacidades API adicionales para ser implementadas y expuestas. El servidor EMR también puede elegir exponer la operación de búsqueda, lectura e historial en el recurso AuditEvent para los registros específicos del paciente para permitir la revisión del acceso al registro por parte del paciente. Tenga en cuenta que todo el uso de la API RESTful debe registrarse en un recurso AuditEvent.

Referencias
https://www.hl7.org/fhir/usecases.html
http://www.hl7spain.org/2016/12/28/proyecto-fhir/
https://hl7latam.blogspot.com/2018/08/modelos-de-historias-clinicas.html