La tendencia FHIR sigue dominando en 2024. Las normas de 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 adecuada. 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 multitenencia?
- ¿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 múltiples clientes (inquilinos), donde cada cliente dispone de su propio entorno dedicado.
Los inquilinos están aislados entre sí, lo que significa que los datos de uno no serán visibles para otro de ninguna forma. Los usuarios pueden acceder a sus propios datos sin vulnerar la privacidad ni los datos de otros inquilinos.
Esto la convierte en una opción atractiva para las empresas que necesitan compartir recursos entre múltiples usuarios, pero también deben mantener la privacidad y seguridad de los datos individuales.
Sin embargo, 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 inquilino dispone de su propio espacio de plataforma exclusivo.
El grado de aislamiento físico entre los distintos inquilinos viene determinado por la tecnología subyacente, pero en general debe proporcionar un aislamiento lógico completo para garantizar que los datos de cada inquilino 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 costes operativos: Del mismo modo que compartir un viaje resulta más económico, compartir recursos en la nube también lo es. Así, obtiene numerosos 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 la tenencia única es más segura, la multitenencia sigue siendo superior a la hora de identificar amenazas y aislar los recursos de los inquilinos.
Dicho esto, ninguna solución es perfecta. Desde el punto de vista del proveedor, la multitenencia es más compleja que la tenencia única. No nos quedamos en la teoría, ¡siga leyendo!
Comience con el Servidor FHIR de Aidbox para almacenamiento de datos, integraciones, análisis sanitario 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 están aprovechando lo mejor de dos mundos: FHIR y la arquitectura multitenencia. 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 FHIR_BASE_URL para poner la funcionalidad a disposición de terceros. Cada uno de sus clientes debe obtener su propia FHIR_BASE_URL. Lo explicaremos con más detalle a continuación.
Implementación de la multitenencia
Aquí 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 implementarlo, es necesario seguir algunos pasos clave:
- Hacer explícitos los inquilinos;
- Marcar los datos con un ID de inquilino para que pertenezcan a un inquilino específico;
- Enriquecer
FHIR_BASE_URLcon el ID del inquilino; - Enriquecer
AUTH_SERVER_BASE_URLcon el ID del inquilino.
Al final del proceso, su cliente tendrá plena confianza en su aislamiento total a nivel de datos y API, y estará justificado.
Hacer explícitos los inquilinos
Definir los inquilinos de forma explícita es crucial por dos razones importantes:
- Inevitablemente querrá saber qué inquilinos tiene en su sistema;
- Con el tiempo, querrá realizar personalizaciones para ellos.
Los recursos de inquilinos explícitos son un buen lugar para hacer su seguimiento e introducir algunas 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 inquilino
Esta es la razón por la que apostamos por la multitenencia. Le recomiendo hacer del inquilino una propiedad explícita de cada recurso. Esto abrirá un amplio espacio donde 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 exploremos cómo la almacenamos bajo el campo meta en los recursos FHIR.
Formato Aidbox meta: tenant: id: my-clinic resourceType: Tenant
Formato FHIR meta: extension:
- url: https://aidbox.app/tenant-id valueReference reference: Tenant/my-clinic
Esta es una representación externa. En cuanto a la interna, podemos comenzar con un enfoque sencillo desde el punto de vista de la infraestructura. Podemos almacenar los datos en una base de datos y una tabla por tipo de recurso.
La única restricción importante que puedo identificar es que tendrá que implementar el filtrado por inquilino 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 inquilino requiera más recursos, genere una carga elevada y afecte a otros inquilinos, siempre podrá migrar sus datos a otra base de datos y ejecutar una instancia dedicada de la misma aplicación para ese inquilino.
La URL base de FHIR debe contener el ID del inquilino
Cuando todos sus clientes disponen de una API FHIR dedicada, necesita proporcionarles una FHIR_BASE_URL diferente sobre la que se ejecutará su servidor FHIR virtual. Hay dos formas de hacerlo:
- Puede incluir el ID del inquilino en el nombre de dominio, como
my-clinic.aidbox.app/fhir-api; - El ID del inquilino 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 inquilinos, puede considerar incluir el ID del inquilino en el nombre de dominio. Su aplicación también debe ser capaz de trabajar con diferentes dominios en la misma instancia, y habitualmente lo hace.
Incluir el ID del inquilino en la ruta de la URL también es válido. 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 peticiones, lo que significa que no hay cookies de navegador.
La autenticación debe pertenecer al inquilino
Ahora disponemos de una API FHIR dedicada para cada cliente, y los datos en el almacenamiento también pertenecen a los inquilinos. El toque final es dedicar el servidor de autenticación. ¿Por qué? Puede que se pregunte si es posible tener un único servidor de autenticación. Creo que no es posible, y aquí está la razón.
Supongamos que un usuario tiene una cuenta en dos inquilinos diferentes. ¿Qué ocurre entonces? ¿Puede este usuario estar conectado simultáneamente a ambos inquilinos? Técnicamente, sí. Google es un buen ejemplo. Puede usar los servicios de Google y cambiar entre cuentas con un par de clics. Pero, ¿es esa la experiencia de usuario (UX) que busca? Creo que no. Hay dos razones para ello:
- Sus usuarios tendrán que seleccionar sus cuentas cada vez que trabajen con cualquiera de sus inquilinos, incluso si solo tienen una cuenta (no puede estar seguro de si tienen otras cuentas y tendrá que preguntarlo cada vez que quieran interactuar con su API FHIR);
- Al saber que tiene diferentes inquilinos, 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 multitenencia. Esto puede lograrse siguiendo el mismo método que utilizamos para separar las API FHIR para los inquilinos: una AUTH_BASE_URL dedicada. No importa si el ID del inquilino aparece en el nombre de dominio o en la ruta de la URL. Lo único que importa es que los inquilinos 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:
- Haga que su inquilino sea explícito y de primer nivel;
- Guarde un enlace al inquilino en cada recurso;
- Inyecte el ID del inquilino en una URL base de FHIR;
- Haga que su servidor de autenticación también sea multitenencia.
Una vez que aplique esos 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 algunos de sus inquilinos superan 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 inquilino;
- 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 en función de 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 potencia significativamente la seguridad y la capacidad de gestión del sistema, especialmente en grandes organizaciones 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 multitenencia 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 está buscando una API FHIR multitenencia que le lleve a 2024 y más allá, pruebe el módulo de API FHIR Aidbox certificado por ONC hoy mismo.
Véase también: Por qué necesita un servidor FHIR independiente.
