Le défi n'est pas insurmontable
La spécification FHIR R5 comprend 157 ressources, des plus fondamentales comme Patient et Observation aux plus spécifiques comme ExplanationOfBenefit pour la facturation. Il existe toutefois des cas où vos données ne correspondent à aucune ressource FHIR existante et où vous souhaitez créer un type de ressource personnalisé.
Dans cet article, nous aborderons 3 façons de créer des types de ressources personnalisés sur votre serveur FHIR et nous en évaluerons les forces et les faiblesses.
Regardons de plus près
De manière générale, FHIR propose plusieurs façons de créer des ressources personnalisées :
- Utiliser la ressource Basic avec des extensions : Cette approche vous permet de personnaliser votre modèle de données tout en restant compatible avec le cadre FHIR.
- Créer de nouvelles ressources de la même façon que FHIR : Cette méthode n'est pas autorisée par la spécification FHIR, mais le résultat est ce qui se rapproche le plus du style FHIR.
- Utiliser des modèles logiques : N'importe qui peut les définir, mais ils semblent souvent déconnectés du modèle de ressource FHIR.
Explorons chacune de ces méthodes afin de déterminer laquelle convient le mieux à vos besoins.
1. Utiliser la ressource Basic dans FHIR
La ressource Basic est conçue pour traiter des concepts qui ne sont pas encore définis dans le cadre FHIR. Elle fournit principalement des métadonnées sur la ressource, tous les autres éléments de données étant exprimés à l'aide d'extensions FHIR.
Avantages :
- Recommandée par FHIR lui-même
- Assure l'interopérabilité
Inconvénients :
- Nécessite la gestion des extensions via un Implementation Guide
- Peut mener à un modèle de données complexe
L'un des principaux problèmes est la nécessité de mapper vos données vers et depuis les ressources Basic. Voici un exemple d'une ressource simple :
id: my-custom-resource
resourceType: MyCustomResource
myKey: test
Et voici à quoi elle ressemble lorsqu'elle est modélisée à l'aide de la ressource 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. Créer de nouvelles ressources de la même façon que FHIR
Une autre façon consiste à définir une ressource personnalisée à l'aide d'une StructureDefinition avec « kind: resource » et « derivation: specialization ». C'est ainsi que FHIR définit toutes ses ressources.
Toutefois, la spécification interdit cette pratique à quiconque, à l'exception de la spécification FHIR elle-même.
Cette approche présente certaines limites. Certaines ressources FHIR, comme SearchParameter ou CapabilityStatement, font référence à des types de ressources et n'autorisent que les types définis dans la spécification FHIR (par liaison obligatoire à certains ValueSet). Une autre limite est qu'une ressource personnalisée ne peut pas être la cible d'une référence.
Avantages :
- Définition directe des ressources à l'aide de StructureDefinition, spécifiquement conçue à cet effet
- Certaines implémentations utilisent déjà cette méthode
Inconvénients :
- Produit des ressources non interopérables
- Interdite par la spécification FHIR
- Présente certaines limitations dans l'interaction avec d'autres ressources
3. Utiliser des modèles logiques
Une autre façon de définir une ressource personnalisée consiste à utiliser une StructureDefinition avec « kind » défini à « logical » et « derivation » défini à « specialization ». Contrairement à la méthode précédente, n'importe qui peut créer ces ressources. Ces StructureDefinitions, souvent appelées modèles de données logiques FHIR ou simplement modèles logiques, sont destinées à modéliser n'importe quelles données à l'aide des abstractions FHIR.
Un bon exemple d'utilisation récente des modèles logiques est le SQL on FHIR Implementation Guide et la ressource ViewDefinition. Ce modèle représente une projection tabulaire d'une ressource FHIR, où les colonnes et les critères d'inclusion sont définis par des expressions FHIRPath.
Le Da Vinci Project tire également parti des modèles logiques dans ses Implementation Guides pour améliorer l'interopérabilité et soutenir les initiatives de soins basés sur la valeur. Par exemple, le guide Coverage Requirements Discovery (CRD) inclut des modèles logiques pour décrire les informations qui devraient être saisies pour chaque transaction CRD, assurant ainsi une collecte et une déclaration cohérentes des données entre différents systèmes.
Cette approche présente néanmoins des inconvénients. Les modèles logiques n'ont pas été conçus pour être des ressources. On s'attend à ce qu'un modèle logique soit dérivé du type Base ou Element. Bien qu'il ne soit pas interdit de dériver un modèle logique du type Resource, la spécification FHIR ne fournit aucune orientation sur la sémantique dans ce cas. Si vous définissez un nouveau type de ressource à l'aide d'un modèle logique, toutes les limitations de l'approche précédente s'appliquent. De plus, les Bundles ne peuvent contenir que des modèles logiques dérivés du type Resource. Par ailleurs, la propriété « type » du modèle logique doit contenir une URL complète, incluant le schéma et d'autres détails d'URL, ce qui nécessite un traitement supplémentaire de votre part en tant qu'implémenteur dans le cas d'interactions CRUD.
Avantages :
- Définition directe des ressources via StructureDefinition
- Interopérable
Inconvénients :
- Les modèles logiques sont des citoyens de second rang
- Doivent dériver de types trop rudimentaires
- Présentent des limitations dans l'interaction avec d'autres ressources
- Présentent des limitations dans l'interaction avec la ressource Bundle
Pas de magie : simplement des méthodes qui fonctionnent
Voici comment vous pouvez créer des ressources personnalisées à l'aide des capacités intégrées du serveur FHIR Aidbox, et pourquoi cette méthode est si pratique.
Définir des ressources personnalisées comme des ressources FHIR standard
Bien que la spécification FHIR ne le permette pas, suivre l'approche de FHIR pour les ressources personnalisées est souvent la façon la plus simple. Elle se comporte exactement comme n'importe quelle autre ressource. Vous pouvez utiliser les outils standard pour les créer. Aidbox offre un moyen de pallier les limitations de cette méthode.
Gardez toutefois à l'esprit que les ressources personnalisées ne sont pas interopérables et ne devraient être utilisées que si les ressources prédéfinies de FHIR ne peuvent pas répondre à vos besoins.
Résoudre les limitations précédentes
FHIR définit certains ValueSets qui répertorient tous les types de ressources. Lors de la validation, Aidbox vérifie que le type de ressource est soit inclus dans le ValueSet, soit qu'il s'agit d'une ressource personnalisée. Cela permet l'utilisation de ressources personnalisées au sein d'autres ressources comme CapabilityStatement ou SearchParameter, ou dans la propriété « type » des références.
FHIR permet aux références de ne pointer que vers des ressources FHIR. Aidbox étend cette capacité en vous permettant de spécifier des ressources personnalisées comme cibles de références également.
👉 Cliquez ici pour en savoir plus dans la documentation Aidbox.
Exécuter Aidbox localement ou dans le nuage
Aidbox peut être exécuté localement ou dans le nuage, offrant la flexibilité nécessaire pour tester toutes ces méthodes. Que vous exploriez des ressources personnalisées ou que vous tiriez parti des ressources existantes, Aidbox propose une plateforme robuste pour améliorer les capacités de votre serveur FHIR.
Des licences de développement gratuites sont également disponibles.
Auteurs : Evgeny Mukha, Ingénieur logiciel full-stack chez Health Samurai
Vasiliy Kupriakov, Ingénieur logiciel full-stack chez Health Samurai
