La tendencia FHIR sigue dominando en 2024. Las normas de la ONC suponen un reto considerable para los proveedores, ya que necesitan ofrecer una API HL7® FHIR con soporte SMART on FHIR para cada cliente.

Muchos proveedores de EHR aún tienen dudas sobre cómo reducir la carga de gestionar tantos servidores FHIR. La respuesta es sencilla: la multitenencia es siempre la solución correcta. En este artículo encontrará respuesta a las siguientes preguntas:

• ¿Qué es la multitenencia? ¿Cuáles son sus ventajas?
• ¿Cómo se construye una API FHIR multi-tenant?
• ¿Cómo se integra una API FHIR en su solución EHR existente?

¿Qué es la multitenencia?

La multitenencia es una ventaja clave de los sistemas ERP SaaS. En pocas palabras, es una forma de proporcionar recursos compartidos a varios clientes (tenants), donde cada cliente dispone de su propio entorno dedicado.

Los tenants están aislados entre sí, lo que significa que los datos de uno no serán visibles para otro en ningún caso. Los usuarios pueden acceder a sus propios datos sin vulnerar la privacidad ni los datos de otros tenants.

Esto la convierte en una opción atractiva para las empresas que necesitan compartir recursos entre varios usuarios, pero también deben mantener la privacidad y la seguridad de los datos individuales.

No obstante, al hablar de multitenencia, también debe tenerse en cuenta el aislamiento físico. El grado de aislamiento físico es flexible y puede ir desde una separación física completa hasta un espacio de alojamiento compartido en el que cada tenant dispone de su propio espacio único en la plataforma.

El grado de aislamiento físico entre los distintos tenants viene determinado por la tecnología subyacente, pero en general debe proporcionar un aislamiento lógico completo para garantizar que los datos de cada tenant permanezcan seguros (Gartner).

¿Qué ventajas ofrece la multitenencia?

Veamos ahora las ventajas de la multitenencia para los proveedores de EHR y otros servicios de plataforma:

• Reducción de los costes operativos: Del mismo modo que compartir un vehículo resulta más económico, compartir recursos en la nube también lo es. Así, obtiene muchos servidores FHIR al precio de uno.
• Escalabilidad sencilla: Los clientes tienen la opción de añadir o eliminar recursos. Esta adaptabilidad es ideal para empresas con un crecimiento rápido pero impredecible.
• Seguridad de los datos: Aunque el modelo de tenant único es más seguro, la multitenencia es más eficaz a la hora de identificar amenazas y aislar los recursos de cada tenant.

Dicho esto, ninguna solución es perfecta. Desde el punto de vista del host, la multitenencia es más compleja que el modelo de tenant único. No nos quedamos en la teoría, ¡siga leyendo!

Comience con el servidor FHIR de Aidbox para el almacenamiento de datos, integraciones, análisis sanitarios y mucho más, o contrate a nuestro equipo para cubrir sus necesidades de desarrollo de software.

¿Qué ocurre con FHIR?

FHIR no admite la multitenencia a nivel de especificación. De hecho, no es necesario que lo haga. Sin embargo, muchos servidores FHIR como Aidbox combinan lo mejor de dos mundos: FHIR y la arquitectura multi-tenant. Obtenga más información sobre la multitenencia en la documentación de Aidbox.

La multitenencia es una cuestión de decisiones arquitectónicas internas. FHIR expone la FHIR_BASE_URL para poner la funcionalidad a disposición de terceros. Cada uno de sus clientes debe recibir su propia FHIR_BASE_URL. Lo explicaremos con más detalle a continuación.

Implementación de la multitenencia

A continuación exploraremos algunas técnicas que pueden ayudarle a construir una solución altamente compartida. Además, permite migrar a un nivel inferior de multitenencia bajo demanda en caso de que algunos clientes necesiten recursos más dedicados. Para implementarla, debemos seguir algunos pasos clave:

• Definir los tenants de forma explícita;
• Marcar los datos con un ID de tenant para que pertenezcan a un tenant específico;
• Incorporar el ID de tenant en la FHIR_BASE_URL;
• Incorporar el ID de tenant en la AUTH_SERVER_BASE_URL.

Al finalizar el proceso, su cliente tendrá plena confianza en su aislamiento total a nivel de datos y API, lo cual estará plenamente justificado.

Definir los tenants de forma explícita

Definir los tenants de forma explícita es fundamental por dos razones importantes:

• Inevitablemente querrá saber qué tenants tiene en su sistema;
• Con el tiempo, querrá realizar personalizaciones para ellos.

Los recursos de tenant explícitos son un buen lugar para rastrearlos e introducir configuraciones personalizadas específicas. Puede considerar la introducción de recursos adicionales:

id: my-clinic resource Type: Tenant name: My Clinic

Los datos pertenecen al tenant

Esta es la razón por la que optamos por la multitenencia en primer lugar. Le sugiero que convierta el tenant en una propiedad explícita de cada recurso. Esto abrirá un gran espacio donde podrá almacenar datos, y también le permitirá llevar a cabo migraciones y evolucionar su infraestructura para satisfacer los requisitos de rendimiento a medida que crezcan.

La tenencia es una metapropiedad, así que tomemos Aidbox como ejemplo y veamos cómo la almacenamos bajo el campo meta en los recursos FHIR.

Aidbox format

meta: tenant: id: my-clinic resourceType: Tenant

FHIR format

meta: extension:

• url: https://aidbox.app/tenant-id valueReference reference: Tenant/my-clinic

Esta es una representación externa. En cuanto a la representación interna, podemos empezar con un enfoque sencillo desde el punto de vista de la infraestructura. Podemos almacenar los datos en una sola base de datos y una sola tabla por tipo de recurso.

La única restricción importante que veo es que tendrá que implementar el filtrado por tenant a nivel de aplicación, lo cual es un coste bastante razonable para mantener su infraestructura lo más simple posible.

En caso de que un tenant requiera más recursos, genere una carga elevada y afecte a otros tenants, siempre podrá migrar sus datos a otra base de datos y ejecutar una instancia dedicada de la misma aplicación para ese tenant.

La URL base de FHIR debe contener el ID de tenant

Cuando todos sus clientes disponen de una API FHIR dedicada, debe proporcionarles una FHIR_BASE_URL diferente sobre la que se ejecutará su servidor FHIR virtual. Hay dos formas de hacerlo:

• Puede incluir el ID de tenant en el nombre de dominio, como my-clinic.aidbox.app/fhir-api;
• El ID de tenant puede aparecer en la ruta de la URL, por ejemplo, aidbox.app/tenant/my-clinic/fhir-api.

Ambas opciones son válidas, aunque la primera resulta más precisa y limpia.

Si tiene acceso completo a su dominio y puede reservar subdominios para sus tenants, puede considerar incluir el ID de tenant en el nombre de dominio. Su aplicación también debe ser capaz de trabajar con diferentes dominios en la misma instancia, y generalmente así lo hace.

Incluir el ID de tenant en la ruta de la URL también es una opción válida. No requiere sacrificar tantos nombres de dominio, incluso si no tiene acceso a ellos. La API FHIR implementa el estilo REST, y la API REST no espera ninguna sesión entre solicitudes, lo que significa que no hay cookies de navegador.

La autenticación debe pertenecer al tenant

Ahora disponemos de una API FHIR dedicada para cada cliente, y los datos en el almacenamiento también pertenecen a los tenants. El toque final es dedicar el servidor de autenticación. ¿Por qué? Puede preguntarse si es posible tener un único servidor de autenticación. Creo que no, y aquí le explico por qué.

Supongamos que un usuario tiene una cuenta en dos tenants diferentes. ¿Qué ocurre entonces? ¿Puede este usuario estar conectado simultáneamente a ambos tenants? Técnicamente, sí. Google es un buen ejemplo. Puede utilizar los servicios de Google y cambiar entre cuentas en un par de clics. Pero, ¿es esta la experiencia de usuario (UX) que busca? Creo que no. Hay dos razones para ello:

• Sus usuarios deberán seleccionar su cuenta cada vez que trabajen con cualquiera de sus tenants, aunque solo tengan una cuenta (no puede estar seguro de si tienen otras cuentas y tendrá que preguntarles cada vez que deseen interactuar con su API FHIR);
• Al saber que usted tiene diferentes tenants, sus usuarios podrían teóricamente interactuar con filtraciones externas. Nuestro objetivo es el aislamiento total desde el lado del usuario.

Pero esto no termina aquí, ya que el servidor de autenticación también debe ser multi-tenant. Esto puede lograrse siguiendo el mismo método que utilizamos para separar las API FHIR por tenants: una AUTH_BASE_URL dedicada. No importa si el ID de tenant aparece en el nombre de dominio o en la ruta de la URL. Lo único que importa es que los tenants puedan estar conectados simultáneamente a todos sus servidores de autenticación e interactuar con sus servidores FHIR como entidades independientes.

Conclusión

Hay cuatro pasos sencillos para lograr la multitenencia:

• Defina su tenant de forma explícita y como elemento de primera clase;
• Guarde un enlace al tenant en cada recurso;
• Incorpore el ID de tenant en una URL base de FHIR;
• Haga que su servidor de autenticación también sea multi-tenant.

Una vez aplicados estos cuatro sencillos pasos, podrá crear un servidor FHIR sin costes de infraestructura adicionales, ya que solo necesita crear un recurso Tenant y un servidor FHIR virtual, lo que significa que el servidor de autenticación ya estará desplegado para él.

Si alguno de sus tenants supera su asignación, puede fácilmente dedicar un nivel superior de aislamiento. Simplemente necesita:

• desplegar la misma aplicación en otro servidor;
• migrar los datos del tenant;
• redirigir las solicitudes a la nueva aplicación.

Actualización: Control de acceso jerárquico basado en organización mejorado

Recientemente hemos mejorado el sistema añadiendo un control de acceso jerárquico basado en organización. Esta nueva funcionalidad permite una gestión del acceso a los datos más flexible y precisa, basada en la jerarquía organizativa. Los administradores ahora pueden establecer permisos de acceso en distintos niveles organizativos, garantizando que los usuarios solo vean los datos que están autorizados a consultar. Esta mejora incrementa significativamente la seguridad y la capacidad de gestión del sistema, especialmente en organizaciones grandes con estructuras complejas. Puede encontrar información detallada sobre la nueva funcionalidad en la documentación de Aidbox.

Para explorar la implementación de una API FHIR multi-tenant en su sistema EHR, considere utilizar la versión gratuita de Aidbox. Proporciona un entorno robusto para probar y desarrollar estas capacidades, ofreciendo todas las herramientas necesarias sin limitaciones de funcionalidades.

Autor: Vlad Ganshin, Ingeniero de Software en Health Samurai

Si busca una API FHIR multi-tenant que le lleve al 2024 y más allá, pruebe el módulo de API FHIR Aidbox certificado por la ONC hoy mismo.

Véase también: Por qué necesita un servidor FHIR independiente.