Utilisation de l'adaptateur FHIR pour la fourniture de services FHIR sur des systèmes existants - Architecture

Nous reprenons notre exemple d'utilisation de l'adaptateur FHIR, dans cet article nous allons voir comment le configurer dans nos instances IRIS et quel est le résultat de l'installation.

Les étapes de configuration du projet sont les mêmes que celles présentées dans la documentation officielle, que vous pouvez consulter directement ici. Bon, au travail !

Installation

Comme vous pouvez le voir dans le projet associé à l'article, nous avons déployé notre instance IRIS dans Docker, de sorte que la majeure partie de la configuration initiale sera effectuée dans le fichier Docker. Rassurez-vous, nous n'entrerons pas dans les détails de la configuration de Docker.

Pour installer notre adaptateur FHIR, nous n'avons que :

1. Créer un espace de noms (Namespace) appelé ADAPTER dans notre instance IRIS avec la fonctionnalité d'interopérabilité.
2. Depuis le terminal IRIS, accéder à notre espace de noms et exécuter la commande suivante.

set status = ##class(HS.FHIRServer.Installer).InteropAdapterConfig("/Adapter/r4")

Dans notre cas, nous avons défini que l'URL du point de terminaison IRIS recevant les requêtes REST sera l'adaptateur /Adapter/r4.

Résultat de l'installation

Une fois l'installation de l'adaptateur FHIR terminée, nous pouvons examiner ce qui se passe dans notre instance IRIS. Pour ce faire, nous allons d'abord passer en revue le menu des applications web (Administration du système -> Sécurité -> Applications -> Applications Web).

Comme nous le voyons, une nouvelle application web a été ajoutée à la liste, ce qui indique qu'elle correspond à notre espace de noms adaptateur (ADAPTER Namespace). Accédons-y pour examiner sa configuration plus en détail.

Comme nous le voyons, l'application web créée permet la réception d'appels REST et la classe responsable de la gestion de ces appels est HS.FHIRServer.HC.FHIRInteropAdapter. Un autre détail que nous voyons est l'activation de l'authentification par mot de passe et des appels non authentifiés. Pour notre exemple, nous n'allons rien modifier, mais il serait intéressant que l'authentification JWT soit activée dans un environnement de production.

Passons en revue ce qui se passe dans la production de notre espace de noms.

Dans le cadre de cette installation, deux nouveaux composants ont été créés et déployés, le service métier InteropService et l'opération métier InteropOperation. Pour notre exemple, nous allons utiliser uniquement InteropService qui sera chargé de transmettre le message FHIR reçu, celui-ci sera de la classe HS.FHIRServer.Interop.Request et c'est sur celui-ci que nous travaillerons pour extraire l'information reçue. La réponse reçue par InteropService pour retourner la réponse JSON sera de type HS.FHIRServer.Interop.Response.

Configuration de notre "HIS"

Nous avons mentionné dans l'article précédent que notre but était de simuler l'interopérabilité avec un SIH théorique, pour cela nous avons déployé une instance PostgreSQL dans notre Docker avec une série de tableaux de test. Pour lancer des requêtes sur cette base de données externe, nous avons inclus et configuré la passerelle Java Gateway, de manière à ce que nous puissions effectuer les connexions nécessaires via JDBC. Nous avons également inclus la bibliothèque JAVA que nous utiliserons pour nous connecter à PostgreSQL.

Examinons donc les éléments de production responsables de cette connexion.

Nous avons configuré notre JavaGateway pour qu'elle pointe vers la machine virtuelle Java déployée dans notre Docker :

L'opération métier FromAdapterToHIS sera en charge des requêtes vers notre PostgreSQL, passons à sa configuration :

Comme nous pouvons le voir, elle utilise EnsLib.SQL.OutboundAdapter comme classe d'adaptateur, ce qui nous permettra de nous connecter directement à la base de données de notre "HIS". La valeur DSN sera la chaîne de connexion à l'instance PostgreSQL déployée dans notre Docker.

Pour résumer...

Reprenons ce que nous avons fait dans cet article :

1. Installation du FHIRAdapter dans notre espace de noms et vérification de la présence d'un point de terminaison vers lequel les messages FHIR peuvent être envoyés.
2. Vérification des composants créés par des défauts dans la production de notre espace de noms (InteropService et InteropOperation).
3. Création des composants nécessaires pour communiquer avec notre base de données "HIS".

En suivant ces étapes, nous disposons de tous les éléments nécessaires pour commencer à recevoir des messages FHIR au format JSON. Dans le prochain article, nous créerons le processus métier responsable du traitement des messages reçus et nous implémenterons les différentes fonctionnalités que nous devrons consulter et écrire sur notre base de données PostgreSQL.

Je vous remercie de votre attention !