ÚNICAS Rare Diseases HL7 FHIR Implementation Guide - Local Development build (v0.0.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Decisiones de diseño FHIR para ÚNICAS

El ciclo de vida y la seguridad de los recursos FHIR en la Red ÚNICAS siguen las directrices establecidas por HL7 FHIR, asegurando la integridad, confidencialidad y trazabilidad de la información de los pacientes.

Pero queremos destacar que esta guía de implementación quiere enfatizar la necesidad de tener en cuenta los siguientes conceptos de FHIR: “Mime-type”, "Version-parameter", “HTTP Headers”, “Lifecycle”, “Security & Privacy”, “FHIR_Validators”, “HTTP Errors”, etc.

Mime-type y Version-parameter

La red de ÚNICAS recomienda definir el parámetro de tipo MIME fhirVersion como un parámetro para indicar en qué versión de la versión FHIR se basa un recurso:

Accept: application/fhir+json; fhirVersion=5.0
Accept: application/fhir+xml; fhirVersion=5.0

El valor de este parámetro es el número de versión principal y secundaria de la especificación FHIR:

Preferiblemente JSON para la publicación de información. El formato RDF (Turtle) no está disponible en la red de ÚNICAS.

IG Language

El idioma de la Plataforma ÚNICAS y el contenido de la información de la mensajería FHIR de ÚNICAS es el castellano. Por este motivo se ha priorizado el uso de las ediciones Spanish de los catálogos y terminologías para indicar la preferencia idiomática de las descripciones.

This implementation guide is written in Spanish. If you need any clarification, you can contact the Spanish Ministry of Health (https://www.sanidad.gob.es/home.htm).

Meta.tag

En el recurso Meta de FHIR se informa:

​

Los tag, profiles y los security labels son atributos de Meta, pero nunca se utilizan para almacenar información necesaria para interpretar su contenido; su función se limita a encontrar y controlar el acceso al recurso, así como a conectarlo con el flujo de trabajo técnico o clínico.

Los Tags se utilizan para asociar información operativa adicional con los recursos, como la gestión del flujo de trabajo.

"meta": {
   "tag": [
      {
         "system": "urn:unicas:process",
         "code": "ÚNICAS",
         "display": "ÚNICAS"
      }
   ]
}  

En la red de ÚNICAS se quiere utilizar para identificar que la información es relevante para enfermedades minoritarias o para indicar que la información es sobre un paciente ÚNICAS.

Binary resource

En la red de ÚNICAS hay un tráfico de intercambio de base64 en PDF o HL7 CDA muy elevado que hace que el recurso Attachment pese mucho.

Para evitar este tráfico y poder consultar la información del Attachment antes de decidir si necesitamos visualizar el contenido o no, se ha decidido hacer uso del recurso Binary. El recurso Binary se utiliza generalmente como destino en el tipo de dato Attachment para referenciar el contenido mediante el elemento .url, como en los recursos DocumentReference.

El recurso Binary tiene sus particularidades y se comporta de forma ligeramente diferente a los demás recursos de la API RESTful:

• Binary.data es opcional porque se excluye al solicitar una vista resumida del recurso Binary (esto puede ser útil cuando el recurso binario forma parte de una solicitud más amplia, por ejemplo, una búsqueda _include). Pero esto no significa que el Binary.data sea opcional de informar porque un recurso binario sin contenido especificado no es útil.
• Cuando se realiza una solicitud de lectura con un tipo FHIR en el encabezado Accept (p. ej., "application/fhir+xml" o "application/fhir+json"), el recurso Binary se devuelve en el formato FHIR solicitado. Esto aplica incluso cuando los datos binarios tienen un tipo MIME FHIR.
• El recurso Binary siempre se representa en el formato FHIR nativo cuando se encapsula en un Bundle.
• El parámetro _format anula el encabezado Accept y debe interpretarse como si se usaran los tipos MIME FHIR estándar, incluso si se proporcionan los tipos MIME más genéricos como valor.
• Cuando la solicitud de lectura tiene otro tipo en el encabezado Accept, el contenido debe devolverse con el tipo de contenido indicado en el recurso en el encabezado Content-Type. Por ejemplo, si el tipo de contenido del recurso es "application/pdf", el contenido debe devolverse directamente como PDF. El parámetro _summary no aplica en este caso. Debido al funcionamiento de la infraestructura web, no es posible establecer reglas generales sobre la relación entre el campo "Accept" en la solicitud HTTP y el tipo de retorno, por lo que no existe una regla estricta al respecto. Sin embargo, la intención es que, a menos que se solicite específicamente, no se devuelva la representación XML/JSON de FHIR.
• Cuando se escriben datos binarios en el servidor (POST o PUT), estos se aceptan tal cual, y se tratan como contenido de un Binary, incluso cuando el tipo de contenido es "application/fhir+xml" o "application/fhir+json", excepto en el caso especial en que el contenido sea realmente un recurso Binary.
• Cuando el cliente solicita un recurso Binary utilizando un tipo MIME genérico (application/xml, text/xml o application/json), el servidor DEBERÍA devolver el contenido directamente si el formato del tipo de contenido coincide con el tipo MIME solicitado (por ejemplo, si el encabezado "Accept" es application/json y el tipo de contenido es vnd.xacml+json). Sin embargo, es posible que los servidores no siempre puedan interpretar correctamente los tipos MIME y los clientes DEBEN estar preparados para recibir cualquiera de los formatos.

Para recuperar/leer el Binary.data hay algunas dificultades, porque FHIR no establece reglas sobre la funcionalidad de lectura avanzada del recurso binario y los servidores pueden admitir estas funciones, pero no son obligatorias, como:

• Recuperar rangos de bytes
• Determinar el tamaño del contenido antes de recuperarlo (aunque esto puede lograrse mediante una solicitud HEAD)
• Transmitir contenido desde el recurso Binary
• Generar contenido dinámicamente sobre la marcha
• FHIR no admite la búsqueda de recursos Binary.
• FHIR no especifica la semántica de una operación PATCH en un recurso Binary.
• FHIR no especifica SearchParameters para el recurso Binary.

En esta guía se explica distintas soluciones que pueden servir de inspiración para entender un poco más la dificultad a la que nos enfrentamos y posibles soluciones ejemplo: https://smilecdr.com/docs/fhir_repository/binary_data.html

Es por todos estos motivos que, si en algún momento se considera que no es suficiente para los requerimientos funcionales de la plataforma ÚNICAS, es posible que se vuelva a recomendar el uso del Attachment.data.

HTTP Headers

La red de ÚNICAS tiene en cuenta algunos HTTP headers para el uso de la API FHIR tanto para solucionar problemas de inconsistencia de datos, como para identificar con una etiqueta que X información es relevante para la red de ÚNICAS.

Conditional update

Cada recurso dentro de la red ÚNICAS atraviesa distintas etapas desde su publicación hasta posible consulta:

• Publicación: Se publica un nuevo mensaje (Bundle) con datos iniciales.

Para asegurar la publicación de mensaje no está duplicado la información, se utiliza actualización condicional, que permite crear recurso solo si no existe un recurso equivalente en el servidor y modificar recurso existente basándose en criterios de creación/modificación. En el mensaje utilizado siguiente interación para definir equivalencia. Para más información: https://www.hl7.org/fhir/http.html#cond-update.

PUT [base]/[tipo recurso]?[parámetros de búsqueda]

Donde parámetros de búsqueda se utiliza el identifier:

PUT [base]/Encounter?identifier=urn:regcess:0908005177|id-interno-interacionClinica

Cuando el servidor procesa esta publicación, realiza una búsqueda como se especifica utilizando sus funciones de búsqueda estándar para el tipo de recurso. La acción que se lleva a cabo depende de la cantidad de coincidencias que se encuentren:

• Sin coincidencias: el servidor procesa la publicación como se indicó anteriormente, donde, si se publica el recurso.
• Una coincidencia: el servidor realiza la actualización contra el recurso coincidente como se indicó anteriormente.
• Varias coincidencias: el servidor devuelve un 412 Precondition Failederror que indica que los criterios del cliente no fueron lo suficientemente selectivos.

Esta variante se puede utilizar para evitar el riesgo de que el servidor cree recursos duplicados para el mismo registro.

• Modificación: Se actualizan los datos del recurso según actividad.
• Consulta: Se accede al recurso según parámetros introducidos.

patch

Como alternativa a actualizar un recurso completo, se pueden realizar una interacción de tipo PATCH. Esta interacción se realiza mediante HTTP PATCH, como se muestra a continuación:

PATCH [base]/[type]/[id] {?_format=[mime-type]} 

Las interacciones PATCH también pueden utilizarse dentro de operaciones Batch o Transaction con el formato FHIRPath Patch.

Para más información consultar: https://www.hl7.org/fhir/http.html#patch.

LifeCycle

En FHIR la gestión del ciclo de vida de los recursos y su contenido es importante. En la red de ÚNICAS es necesario plantearse el mantenimiento de los recursos a lo largo del tiempo para no generar un gran BigData sino que toda la información que resida en los Nodos Autonómicos sea información útil, en el presente y en el futuro.

Por este motivo es importante contemplar y analizar los cambios de estado de los recursos y definir acciones en función de estos cambios.

Los casos de baja de un paciente a la red de ÚNICAS también requieren de una definición de acciones en función del motivo de baja en la red. Se debe definir en qué casos se van a eliminar recursos (p. ej. cuando hayan pasado más de una década de la baja) o lo que se decida para el mantenimiento de la información inactiva.

El LifeCycle de FHIR consiste en:

• Resource Status: cómo funcionan los códigos de estado del recurso
• Current List: problemas relacionados con la recuperación de la "lista X actual" de recursos
• Entered in Error: información sobre cómo se gestionan las entradas erróneas de los recursos

ÚNICAS contempla los siguientes aspectos que ayudan a gestionar el mantenimiento de los recursos:

• Clinical Workflow Process Life Cycle: describe los estados del ciclo de vida de actividades complejas comunes en la atención médica. Normalmente, estos estados siguen un ciclo de vida cronológico que va desde el inicio hasta la conclusión de la acción.

  En ÚNICAS se debería tener en cuenta:

  • Appointment.status
  • Encounter.status
  • Goal.lifesycleStatus
  • MedicationAdministration.status

• Request/Order Life Cycle: algunos recursos en FHIR representan órdenes o solicitudes. El ciclo de vida de la solicitud puede resumirse en cuatro etapas: creación de la solicitud, envío de la solicitud, recepción de la aceptación o rechazo de la solicitud y cumplimiento de la solicitud.

  En ÚNICAS de momento no hacemos uso de ninguno de estos recursos.

• Entity Availability Life Cycle: El ciclo de vida de disponibilidad de la entidad indica si el recurso, o la entidad descrita por él, está listo para usarse, aún no está listo para usarse o ha sido retirado del servicio.

  En ÚNICAS se debería tener en cuenta:

  • DiagnosticReport.status
  • MedicationStatement.status
  • CapabilityStatement.status
  • StructureDefinition.status
  • DocumentReference.status
  • Location.status
  • Organization.active
  • Patient.active

• Clinical Status Life Cycle: El estado clínico es algo diferente a los valores de estado anteriores, ya que no aborda el flujo de trabajo ni el ciclo de vida. En cambio, indica cómo la evidencia afecta la interpretación clínica.

  En ÚNICAS se debería tener en cuenta:

  • AllergyIntolerance.clinicalStatus
  • Condition.clinicalStatus

Para obtener más información sobre la gestión del ciclo de vida de los recursos, consultar: https://www.hl7.org/fhir/lifecycle.html.

Security & Privacy

El Módulo de Seguridad y Privacidad describe cómo proteger un servidor FHIR (mediante control de acceso y autorización), cómo documentar los permisos otorgados por un usuario (consentimiento) y cómo mantener registros de los eventos realizados (registro de auditoría y procedencia). FHIR no exige un enfoque técnico único para la seguridad y la privacidad; más bien, la especificación proporciona un conjunto de componentes básicos (Audit Event, Consent, Permission, Provenance, Signature, Security Labels (Resource.meta.security)) que pueden aplicarse para crear sistemas seguros y privados.

Para más información consultar: https://build.fhir.org/secpriv-module.html, https://build.fhir.org/security.html#http.

Auditoria - Perfil de integración IHE RESTful Audit Trail and Node Authentication (RESTful ATNA)

ÚNICAS se ha alineado al máximo con los perfiles IHE teniendo en cuenta solo las transacciones y actores que tienen sentido en FHIR, en concreto con el RESTful Audit Trail and Node Authentication (RESTful ATNA) que es un perfil de IHE para el seguimiento de auditoría y autenticación de nodos que especifica los elementos fundamentales que necesitan todas las formas de sistemas seguros: autenticación de nodos, autenticación de usuarios, registro de eventos (auditoría) y cifrado de telecomunicaciones. También se utiliza para indicar que se proporcionan otras propiedades de seguridad interna, como control de acceso, control de configuración y restricciones de privilegios. Muchos otros perfiles de IHE requieren o recomiendan agruparse con actores de ATNA como parte de sus consideraciones de seguridad. Para más información: https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html.

A continuación, se muestran los actores directamente involucrados en el Perfil ATNA y las transacciones relevantes entre ellos.

En la red de ÚNICAS el cumplimiento de este perfil garantiza un marco de seguridad entendido globalmente.

La siguiente tabla muestra las equivalencias de los distintos actores del perfil, con los componentes del proyecto ÚNICAS.

La siguiente tabla muestra las equivalencias de las distintas transacciones del perfil, con las transacciones de los actores identificados en la tabla anterior en el proyecto ÚNICAS.

Igualmente, es necesario entender que el Nodo Central del ministerio va a tener su auditoria que es posible que adapte para las validaciones crossborder con el nodo del Punto de Contacto Nacional (NCP) para la Salud Electrónica que recibe y procesa mensajes transfronterizos (https://build-fhir.ehdsi.eu/ncp-api/application.html).

I en el caso de la red de ÚNICAS la auditoria la va a marcar la componente auditoria del NA y la app SMART, ver apartado siguiente.

SMART on FHIR

La plataforma ÚNICAS es una aplicación SMART on FHIR que facilita autenticación e integración de los sistemas.

Integración de UI y seguridad

• SMART App Launch: Aplicaciones orientadas al usuario que se conectan a HCE y portales de salud
• SMART Backend Services: Conexiones FHIR de servidor a servidor

Para más información sobre SMART on FHIR: https://docs.smarthealthit.org/.

Validating Resources

Es importante que las CCAA se responsabilicen de validar por adelantado que la información que envían tiene un formato conformance. Para ello existen distintas herramientas que validan a más o menos nivel técnico en función de la necesidad.

Existen múltiples maneras de validar recursos y cuáles de los aspectos mencionados permiten validar:

• XML Schema
• XML Schema + Schematron
• JSON Schema
• ShEx
• Validator
• Validation Operation

​
Pude ser muy útil para los SSII de cada CCAA para validar los Bundles antes de hacer el POST/PUT a la API FHIR de su Nodo Autonómico.

En la red ÚNICAS, el siguiente validador también puede ser muy útil para la validación de mensajes: Simplifier Validator.

Versión Management

​Esta guía se ha creado basada en la versión current de FHIR que es la R5, pero siendo conscientes que puede ser un reto para los sistemas que deben lidiar con versiones anteriores como R4, que es una versión más extendida e implementada hasta el momento. Por este motivo, en ÚNICAS se ha analizado las diferencias entre R5 y R4 que pueden ser útiles para entender los cambios más relevantes de los recursos y elementos utilizados en la red de ÚNICAS:

HTTP Errors

L’API FHIR es una API RESTful basada en el protocolo HTTP, HTTP define unos códigos de error estándar devueltos relacionados con FHIR (además de los errores HTTP normales relacionados con problemas de seguridad, encabezado y negociación de tipo de contenido):

• 201 Creado: código de éxito, el recurso se ha creado
• 202 Aceptado: el servidor no desea comprometerse con el resultado de la creación; consulte el Patrón de solicitud de interacción asíncrona para obtener más información.
• 400 Solicitud incorrecta: el recurso no se pudo analizar o no cumplió con las reglas básicas de validación de FHIR
• 401 No autorizado: se requiere autorización para la interacción intentada
• 404 No encontrado: el tipo de recurso no es compatible o no es un punto final de FHIR
• 405 Método no permitido: el servidor no admite el método solicitado para esta solicitud (GET o POST) y el cliente debe volver a intentarlo con el otro método
• 409 Conflicto/412 Precondición fallida: gestión de conflictos de versiones
• 422 Entidad no procesable: el recurso propuesto infringió los perfiles de FHIR aplicables o las reglas de negocio del servidor. Esto debe ir acompañado de un recurso OperationOutcome que proporcione detalles adicionales.

En general, si una instancia no cumple con las restricciones documentadas en la Declaración de capacidad, la respuesta debe ser un 400, mientras que, si la instancia no cumple con otras reglas de negocio no descritas externamente, la respuesta sería un error 422. En la práctica, los servidores también pueden devolver errores 5xx en estos casos sin que se los considere no conformes. Si el fallo se produce en un nivel de procesamiento compatible con FHIR, la respuesta HTTP DEBE ir acompañada de un OperationOutcome.

Simplemente, se informa en este apartado para tener a mano las definiciones de los errores que pueden surgir en la publicación de información a la red de ÚNICAS.

También puede ser que en la red ÚNICAS se personalicen algunas respuestas de errores definiendo OperationOutcome, si fuera el caso se irá añadiendo en esta misma guía de implementación. Para más información sobre los OperationOutcome: https://build.fhir.org/operationoutcome.html.

Testing FHIR

En la guía de implementación ÚNICAS no se ha especificado de momento ningún entorno de testing, pero si en algún momento fuera necesario hacer pruebas se pueden identificar teniendo en cuenta las siguientes guidelines de FHIR: https://build.fhir.org/testing.html#howTos.

Existen diversas herramientas disponibles para los evaluadores de soluciones que desean comprobar la conformidad de las implementaciones de FHIR con la especificación FHIR. Puede encontrar una lista actualizada de estas herramientas aquí: https://confluence.hl7.org/spaces/FHIR/pages/35718869/Testing+Platforms.

Financial

Queda fuera del alcance de la red de ÚNICAS la gestión financiera de las derivaciones o interconsulta. Las gestiones a realizar por las Comunidades Autónomas para la atención de los pacientes en CSUR ubicados en otra Comunidad Autónoma se efectuarán siempre a través del Sistema de Información del Fondo de Cohesión (SIFCO).

Por lo que por ahora la red de ÚNICAS no plantea el uso de recursos FHIR como:

Para más información consultar: https://build.fhir.org/financial-module.html.