--- { "title": "Devriez-vous utiliser les ressources FHIR comme format de stockage de données?", "description": "L'utilisation de FHIR pour la persistance des données devient un sujet de discussion populaire dans la communauté. Notre directeur technique partage ses réflexions sur le moment et les raisons pour lesquels vous utiliseriez FHIR comme format de stockage de vos données de santé.", "date": "2018-09-05", "author": "Nikolai Ryzhikov", "reading-time": "4 min read", "tags": [ "Database", "System Design" ] } --- *G*r*ahame Grieve a publié un billet sur son blogue au sujet de la persistance des ressources FHIR —* [*lisez-le ici*](http://www.healthintersections.com.au/?p=2776)*. La question principale qu'il aborde est la suivante : comment stocker les ressources FHIR — devrait-on les mettre dans une base de données « telles quelles » en utilisant JSON (ProtoBuf, etc.), ou créer un schéma qui vous est propre?* ### Format de persistance La première affirmation de Grahame est que le format FHIR a été conçu pour l'échange d'information, et non pour la persistance. Nous (Health Samurai) discutons avec la communauté FHIR de la possibilité d'utiliser la [spécification du format FHIR pour la persistance](https://github.com/fhir-fuel/fhir-fuel.github.io). Cependant, Grahame ne nie pas cette possibilité dans son billet! Il s'agit donc d'un des sujets à aborder lors de notre piste de connectathon — [Storage & Analytics on FHIR](https://wiki.hl7.org/index.php?title=201809_FHIR_Storage_and_Analytics). ### Systèmes spécialisés versus systèmes génériques Grahame distingue les systèmes spécialisés à modèle fixe des systèmes plus génériques (c'est-à-dire les dépôts de données cliniques). Dans le premier cas, vous pouvez potentiellement concevoir un schéma plus efficace pour stocker et interroger vos données. Cependant, plus votre système devient générique, plus il devient intéressant de stocker les ressources FHIR telles quelles. J'aimerais partager quelques réflexions à ce sujet. ### La complexité structurelle des systèmes d'information de santé À mon avis, l'un des problèmes les plus complexes en informatique de la santé est celui d'un bon modèle d'information. Qu'est-ce qui rend un modèle d'information bon? Un bon modèle résiste aux changements d'exigences et de cas d'utilisation parce qu'il entretient des relations objectives avec le monde réel. Quiconque a travaillé en informatique de la santé sait à quel point il est difficile de bien faire les choses. Notre domaine est complexe. L'une des valeurs qu'offre FHIR est un modèle d'information prêt à l'emploi qui est suffisamment bon. Si vous n'êtes pas un expert en informatique de la santé avec de nombreuses années d'expérience et que vous souhaitez développer la prochaine application en santé numérique, je vous recommande de commencer avec le modèle de données FHIR, qui a accumulé une grande sagesse d'experts. À ce stade, il serait souhaitable de disposer d'un cadre technique bien adapté. ### Isomorphisme et transformations Si vous souhaitez avoir votre propre schéma/modèle et prendre en charge FHIR, vous serez confronté à une transformation de votre modèle vers FHIR et inversement. Ce type de transformation est trivial si votre modèle est isomorphe à FHIR. Cependant, si les modèles à traduire ne correspondent pas l'un à l'autre — vous avez alors un problème majeur. Il existe un bien connu [décalage d'impédance objet-relationnel](https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch). Voici un autre exemple tiré de l'informatique de la santé : la traduction de HL7 v.2 vers FHIR est assez simple — ils sont similaires, mais la traduction de HL7 v.3 vers FHIR est un cauchemar — ils sont conçus de manière complètement différente. ### Documents versus tables Les ressources FHIR sont conçues comme des [agrégats issus du Domain Driven Design](https://martinfowler.com/bliki/DDD_Aggregate.html). Le mouvement NoSQL a affirmé que l'utilisation des [bases de données orientées documents](https://www.martinfowler.com/bliki/AggregateOrientedDatabase.html) s'aligne bien avec l'approche par agrégats. Si vous tentez de créer une base de données relationnelle normalisée pour les ressources FHIR — vous obtiendrez des milliers de tables générées. Travailler avec autant de tables n'est pas trivial. La plupart des opérations nécessitent une ressource en tant qu'agrégat, et obtenir/manipuler une ressource à partir d'une douzaine de tables n'est pas simple et a des répercussions sur les performances. ### Ouvert versus fermé Un autre aspect crucial à prendre en compte est de savoir si votre système est ouvert ou fermé. Dans un système ouvert, vous permettez potentiellement une extension flexible du modèle — ajout de nouveaux attributs et contraintes aux entités existantes. Dans FHIR, nous disposons d'extensions pour les ressources FHIR. Les systèmes réels évoluent généralement vers des systèmes ouverts. Construire un système ouvert avec un schéma strict représente un défi de taille. L'approche documentaire permet la flexibilité et l'extensibilité bien plus aisément. ### Bases de données documentaires et relationnelles La plupart des bases de données relationnelles courantes (PostgreSQL, Oracle, MySQL et MS SQL) et les bases de données modernes comme Spark, BigQuery et Spanner vous permettent d'utiliser à la fois SQL, les relations et les documents. Vous pouvez donc adopter une approche hybride — stocker efficacement vos ressources telles quelles (sans couches de transformation) et exploiter la puissance de SQL ainsi que d'autres fonctionnalités des bases de données (transactions, indexation, etc.). ### Conclusion Je pense que stocker les ressources FHIR « telles quelles » en utilisant des technologies modernes comme PostgreSQL/jsonb ou BigQuery/ProtoBuf est une approche très prometteuse, qui vaut la peine d'être envisagée si vous démarrez un nouveau système d'information de santé ou une plateforme analytique. ### Participez à la conversation! Pour discuter de ce genre de sujets, faites partie de nos groupes [Analytics on FHIR](https://chat.fhir.org/login/#narrow/stream/73-analytics-on.20FHIR) et [Storage on FHIR](https://chat.fhir.org/login/#narrow/stream/134-storage-for.20FHIR). Rencontrez-nous en personne lors de la [piste de connectathon Storage & Analytics](https://wiki.hl7.org/index.php?title=FHIR_Connectathon_19#Storage_and_Analytics). N'hésitez pas à vous joindre à nos discussions et à partager vos réflexions. [![Aidbox FHIR Platform Free Trial](image-1.avif)](https://www.health-samurai.io/aidbox) Voir aussi : [SQL on FHIR : un regard de l'intérieur](/blog/sql-on-fhir-an-inside-look) et [Préparer FHIR pour la production](/blog/first-steps-to-get-your-fhir-based-solution-ready-for-production).