|
5 min de lectura
|

SMART on FHIR: Guía práctica para ampliar las aplicaciones de HCE

Resumir este artículo con:
ChatGPTPerplexityClaudeGrok

Cómo SMART on FHIR amplía las capacidades de los HCE

No existe ningún HCE o EHR capaz de cubrir todos los casos de uso. En lugar de intentar incorporar todas las funcionalidades necesarias en un único producto, lo habitual es ofrecer interfaces externas que puedan ser aprovechadas por extensiones de terceros. FHIR proporciona la guía de implementación SMART App Launch, que aborda precisamente este problema. El presente artículo ofrece una guía práctica, paso a paso, para ingenieros de software que buscan una forma eficiente de ampliar sus aplicaciones sanitarias.

Mi nombre es Ilya Beda. Soy CTO en Beda Software.

En Beda Software estamos desarrollando una solución HCE de código abierto. Está diseñada para actuar como interfaz de usuario y convertir cualquier servidor FHIR en un HCE FHIR. Recientemente participé en la pista SMART Launch del HL7 AU FHIR Connectathon. Asumí el rol de proveedor de lanzamiento SMART y el HCE de Beda se utilizó para lanzar aplicaciones SMART on FHIR de terceros. El objetivo era comprobar el funcionamiento de la implementación y probar la integración entre las aplicaciones aportadas por los participantes.

Antes de entrar en los detalles técnicos, aclaremos qué es SMART. SMART (Substitutable Medical Applications, Reusable Technology) es una plataforma para crear aplicaciones sanitarias que pueden ejecutarse en diferentes sistemas EHR (historia clínica electrónica). Proporciona un marco para desarrollar aplicaciones seguras, interoperables y sustituibles. Las aplicaciones SMART están diseñadas para ser fáciles de desarrollar y desplegar en distintos entornos sanitarios.

SMART on FHIR se basa en OAuth 2.0, por lo que resulta bastante sencillo entender su funcionamiento.
FHIR EMR schema El HCE FHIR inicia el lanzamiento SMART pasando dos parámetros a la aplicación SMART.

El primer parámetro, denominado iss, es la URL base del servidor FHIR. El segundo parámetro —launch— es una secuencia única que realiza el seguimiento del proceso de lanzamiento y asigna contexto a una sesión.

Una vez iniciada la aplicación, esta carga información del servidor FHIR sobre el endpoint de autenticación OAuth. A continuación, redirige al usuario a dicho endpoint. Esta autenticación contiene una lista de alcances (scopes) que define los permisos solicitados por la aplicación. Veamos con más detalle el aspecto de un alcance: FHIR EMR scope La primera parte identifica el rol. Patient indica que los datos estarán restringidos a un paciente concreto, mientras que user indica que los datos estarán restringidos a un usuario concreto. Si el usuario es un paciente, solo podrá acceder a sus propios datos. Si el usuario es un profesional sanitario, estarán disponibles los datos de todos los pacientes que hayan prestado su consentimiento.

Por último, system status proporciona acceso a todos los recursos.

El tipo de recurso es autoexplicativo y define un recurso FHIR específico.

El resto son operaciones codificadas por letras:

  • C para create (creación);
  • R para read by id (lectura por identificador);
  • U para update (actualización);
  • D para delete (eliminación);
  • S para search (búsqueda).

Así, si su aplicación necesita acceso a una Observation de un paciente, debe proporcionar el siguiente alcance: «patient/Observation.rs».

Si desea crear cualquier tipo de recurso QuestionnaireResponse, el alcance será: «system/QuestionnaireResponse.c».

Una vez que la aplicación solicita los alcances al servidor FHIR, el usuario debe autorizar y conceder permisos para dichos alcances. Si esto ocurre, el servidor FHIR proporciona un código de acceso que puede intercambiarse por un token de acceso, un token de identidad y un fhirContext.

Cuando el HCE FHIR realiza el lanzamiento, guarda el contexto, que estará disponible bajo la clave fhirContext en la respuesta del intercambio de tokens.

Ahora que conoce los fundamentos de SMART on FHIR y del lanzamiento SMART, veamos cómo puede implementarse con Aidbox.

El componente principal es el recurso Client de Aidbox, que representa el cliente OAuth. Este recurso también contiene un campo smart que se utiliza para definir propiedades específicas de SMART on FHIR, como el URI de lanzamiento, el nombre y la descripción: Auth of FHIR EMR El código es accesible aquí.

Construyamos ahora una página de galería de aplicaciones que muestre todas las aplicaciones SMART on FHIR. Para ello, necesitaremos consultar los recursos Client. Los recursos Client no se utilizan exclusivamente para SMART on FHIR, por lo que es necesario establecer algún criterio para seleccionar únicamente los clientes que representan aplicaciones SMART on FHIR. Utilicé el campo Client.type y lo asigné al valor «smart-on-fhir». De este modo, puedo consultar todos los datos de la siguiente manera: El código es accesible aquí.

Aquí utilizo la librería https://github.com/beda-software/aidbox-react para interactuar con los recursos personalizados de Aidbox.

Una vez cargados los datos, el HCE FHIR puede renderizar la galería de aplicaciones SMART: Rendered FHIR EMR Veamos cómo lanzar la aplicación. Aidbox proporciona la RPC API para muchas funciones internas.

La función aidbox.smart/get-launch-uri rpc genera el URI de lanzamiento para la aplicación SMART que se está utilizando. El código es accesible aquí.

Aquí puede observarse que el método rpc requiere los parámetros user, iss y ctx. Ctx es un fhirContext tal como se describió anteriormente. Lo utilizo para compartir información sobre el paciente actual.

El resultado de esta llamada contiene el URI que inicia el lanzamiento de la aplicación SMART. Lo utilizo para reemplazar la página actual del navegador: Launch  of the SMART app in EMR El código es accesible aquí.

Cuando un usuario hace clic en el botón de lanzamiento, será redirigido a la aplicación SMART, que a su vez nos redirige de vuelta al endpoint de autenticación de Aidbox y, a continuación, a la página de autorización con la lista de alcances solicitados. EMR authorization Una vez que el usuario concede el acceso, Aidbox redirige de vuelta a la aplicación SMART con el código de autorización. Este código se intercambia por un token de acceso y un fhirContext.

La aplicación recibe información sobre el usuario actual y el paciente actual. Si un usuario desea revocar el acceso de la aplicación a sus datos, puede hacerlo a través de la interfaz de sesiones de Aidbox:

Demostración en vivo: HCE FHIR + Aplicación SMART

Puede conocer el funcionamiento de este proceso mediante nuestra versión de demostración en vivo de Beda EMR aquí.

Como puede observarse, Aidbox sigue las especificaciones que hemos analizado anteriormente y permite añadir la funcionalidad de lanzamiento SMART al Beda EMR en tan solo un par de días. Probé este enfoque durante el HL7 AU FHIR Connectathon y funcionó correctamente con todas las aplicaciones aportadas.

Si está interesado en una solución HCE nativa en FHIR que cumpla con todos los estándares modernos, póngase en contacto con Beda Software.

Para experimentar con la ampliación de las capacidades de su HCE mediante aplicaciones SMART on FHIR, pruebe la versión gratuita de Aidbox. Proporciona un entorno completamente funcional para probar y desarrollar estas integraciones, con todas las herramientas necesarias disponibles sin limitaciones.

Autor:

Ilya Beda, CTO en Beda Software

Conéctese con Ilya a través de LinkedIn

Véase también: RBAC con Keycloak y SMART on FHIR V2 y Por qué necesita un servidor FHIR independiente.

Compartir este artículo
Comments
Comments
Sign in
Loading comments...
Subscribe to our blog

Get the latest articles on FHIR, interoperability, and healthcare IT.