El problema no es tan grave
La especificación FHIR R5 incluye 157 recursos, desde los más básicos como Patient y Observation hasta los más específicos como ExplanationOfBenefit para la facturación. Sin embargo, existen casos en los que sus datos no encajan en ningún recurso FHIR existente y necesita crear un tipo de recurso personalizado.
En este artículo cubriremos 3 formas de crear tipos de recursos personalizados en su servidor FHIR y evaluaremos sus ventajas e inconvenientes.
Acerquémonos al tema
En general, FHIR propone varias formas de crear recursos personalizados:
- Usar el recurso Basic con extensiones: Esto le permite personalizar su modelo de datos manteniéndose compatible con el marco FHIR.
- Crear nuevos recursos de la misma forma que lo hace FHIR: La especificación FHIR no lo permite, pero el resultado es el que más se asemeja a FHIR.
- Usar modelos lógicos: Cualquiera puede definirlos, aunque a menudo resultan distantes del modelo de recursos FHIR.
Exploraremos cada uno de estos métodos para determinar cuál se adapta mejor a sus necesidades.
1. Usar el recurso Basic en FHIR
El recurso Basic está diseñado para gestionar conceptos que aún no están definidos en el marco FHIR. Proporciona principalmente metadatos sobre el recurso, mientras que el resto de elementos de datos se expresan mediante extensiones FHIR.
Ventajas:
- Recomendado por el propio FHIR
- Garantiza la interoperabilidad
Inconvenientes:
- Requiere la gestión de extensiones a través de una Implementation Guide
- Puede dar lugar a un modelo de datos complejo
Uno de los principales problemas es que necesita mapear sus datos hacia y desde los recursos Basic. A continuación se muestra un ejemplo de un recurso sencillo:
id: my-custom-resource
resourceType: MyCustomResource
myKey: test
Y así es como se ve cuando se modela usando el recurso Basic:
id: my-custom-resource
resourceType: Basic
code:
coding:
- system: http://example.org/CodeSystem/my-custom-resorces
code: my-custom-resource
meta:
profile:
- http://example.org/StructureDefinition/my-custom-resource
extension:
- url: http://example.org/StructureDefinition/my-custom-resource-my-key
valueString: test
2. Crear nuevos recursos de la misma forma que lo hace FHIR
Una alternativa es definir un recurso personalizado usando StructureDefinition con kind: resource y derivation: specialization. Esta es la forma en que FHIR define todos sus recursos.
Sin embargo, la especificación prohíbe hacerlo a cualquiera que no sea la propia especificación FHIR.
Aun así, este enfoque presenta algunas limitaciones. Algunos recursos FHIR como SearchParameter o CapabilityStatement hacen referencia a tipos de recursos y solo permiten usar los tipos definidos en la especificación FHIR (mediante un binding requerido a cierto ValueSet). Otra limitación es que un recurso personalizado no puede ser el destino de una referencia.
Ventajas:
- Definición de recursos sencilla mediante StructureDefinition, diseñada específicamente para este propósito
- Algunas implementaciones ya utilizan este método
Inconvenientes:
- Genera recursos no interoperables
- Está prohibido por la especificación FHIR
- Presenta limitaciones en la interacción con otros recursos
3. Usar modelos lógicos
Otra forma de definir un recurso personalizado es mediante StructureDefinition con kind establecido en logical y derivation establecido en specialization. A diferencia del método anterior, cualquiera puede crear estos recursos. Estas StructureDefinitions, conocidas habitualmente como modelos de datos lógicos FHIR o simplemente modelos lógicos, están pensadas para modelar cualquier dato usando las abstracciones de FHIR.
Un buen ejemplo del uso reciente de los modelos lógicos es la Implementation Guide de SQL on FHIR y el recurso ViewDefinition. Este modelo representa una proyección tabular de un recurso FHIR, donde las columnas y los criterios de inclusión se definen mediante expresiones FHIRPath.
El Da Vinci Project también aprovecha los modelos lógicos en sus Implementation Guides para mejorar la interoperabilidad y apoyar iniciativas de atención basada en el valor. Por ejemplo, la guía Coverage Requirements Discovery (CRD) incluye modelos lógicos para describir la información que debe capturarse en cada transacción CRD, garantizando una recopilación y notificación de datos coherentes entre distintos sistemas.
Sin embargo, este enfoque tiene sus desventajas. Los modelos lógicos no fueron diseñados para ser recursos. Se espera que un modelo lógico derive del tipo Base o Element. Si bien no está prohibido derivar un modelo lógico de Resource, la especificación FHIR no ofrece orientación sobre la semántica en ese caso. Si define un nuevo tipo de recurso usando un modelo lógico, se aplican todas las limitaciones del enfoque anterior. Y aún más, los Bundles solo pueden contener modelos lógicos derivados del tipo Resource. Además, la propiedad type del modelo lógico debe contener una URL completa, incluyendo el esquema y otros detalles de la URL, lo que requiere un procesamiento adicional por parte del implementador en el caso de interacciones CRUD.
Ventajas:
- Definición de recursos sencilla mediante StructureDefinition
- Interoperable
Inconvenientes:
- Los modelos lógicos son ciudadanos de segunda clase
- Deben derivar de tipos demasiado básicos
- Presentan limitaciones en la interacción con otros recursos
- Presentan limitaciones en la interacción con el recurso Bundle
Sin magia: solo métodos que funcionan
A continuación se explica cómo crear recursos personalizados usando las capacidades integradas del servidor FHIR Aidbox, y por qué este método resulta tan conveniente.
Defina recursos personalizados como si fueran recursos FHIR estándar
Aunque la especificación FHIR no lo permite, seguir el enfoque de FHIR para los recursos personalizados suele ser la forma más sencilla. Se comporta exactamente igual que cualquier otro recurso. Puede usar las herramientas estándar para crearlos. Aidbox ofrece una forma de abordar las limitaciones de este método.
No obstante, recuerde que los recursos personalizados no son interoperables y solo deben utilizarse si los recursos predefinidos de FHIR no pueden satisfacer sus necesidades.
Resolviendo las limitaciones anteriores
FHIR define algunos ValueSets que enumeran todos los tipos de recursos. Durante la validación, Aidbox comprueba que el tipo de recurso esté incluido en el ValueSet o que sea un recurso personalizado. Esto permite el uso de recursos personalizados dentro de otros recursos como CapabilityStatement o SearchParameter, o en la propiedad type de las referencias.
FHIR permite que las referencias apunten únicamente a recursos FHIR. Aidbox amplía esta capacidad permitiéndole especificar también recursos personalizados como destinos de referencias.
👉 Haga clic aquí para obtener más información en la documentación de Aidbox.
Ejecute Aidbox localmente o en la nube
Aidbox puede ejecutarse localmente o en la nube, lo que proporciona flexibilidad para probar todos estos métodos. Tanto si está explorando recursos personalizados como si aprovecha los existentes, Aidbox ofrece una plataforma robusta para potenciar las capacidades de su servidor FHIR.
También están disponibles licencias de desarrollo gratuitas.
Autores: Evgeny Mukha, Ingeniero de software full-stack en Health Samurai
Vasiliy Kupriakov, Ingeniero de software full-stack en Health Samurai
