Personnalisation et façade du serveur FHIR d'InterSystems

Article

Guillaume Rongier · Nov 21 23m de lecture

#API #FHIR #Framework #Interopérabilité #JSON #REST API #Service aux entreprises #Health Connect #HealthShare #InterSystems IRIS for Health

Serveur FHIR

Le Serveur FHIR est une application logicielle qui met en œuvre la norme FHIR (Fast Healthcare Interoperability Resources), ce qui permet aux systèmes de soins de santé de Stocker, accéder, échanger, et gérer les données de soins de santé de manière standardisée.

InterSystems IRIS permet de stocker et de récupérer les ressources FHIR suivantes:

Référentiel de ressources – Le serveur natif IRIS FHIR permet de stocker facilement les paquets/ressources FHIR directement dans le référentiel FHIR.
Façade FHIR – La couche de façade FHIR est un modèle d'architecture logicielle à l'aide duquel une API compatible FHIR peut être exposée au-dessus d'une API existante (souvent non-FHIR). Cette couche permet également de rationaliser le système de données de soins de santé, y compris les dossiers médicaux électroniques (DME), les bases de données existantes ou le stockage de messages HL7 v2, sans nécessiter la migration de toutes les données vers un système natif FHIR.

Qu'est-ce que FHIR?

FHIR (Fast Healthcare Interoperability Resources) est un framework standard créé par HL7 International afin de faciliter l'échange de données de soins de santé de manière flexible, conviviale pour les développeurs et moderne. Il exploite les technologies web contemporaines pour assurer une intégration et une communication transparentes entre plusieurs systèmes de soins de santé.

Technologies clés FHIR

API RESTful : les interactions entre les ressources.
JSON et XML : la représentation des données
OAuth2 : l'autorisation et l'authentification sécurisées.

FHIR est structuré autour de composants modulaires appelés ressources, chacun représentant un concept spécifique des soins de santé, y compris:

Patient : données démographiques et identifiants.
Observation : mesures cliniques (par exemple, signes vitaux, tests diagnostiques).
Rendez-vous : interactions entre le patient et le prestataire.
Médicaments, allergies/intolérances, état de santé, etc.

Façade FHIR:

Une façade FHIR est une couche architecturale qui expose une API compatible FHIR au-dessus d'un système existant non FHIR (par exemple, un DME hérité, un stockage HL7 v2 ou une base de données personnalisée), sans vous obliger à stocker les données directement au format FHIR.

Elle permet de convertir à la demande les données héritées au format de ressource FHIR (JSON ou XML), facilitant ainsi l'interopérabilité tout en préservant votre infrastructure backend existante.

La façade FHIR reçoit et envoie des ressources FHIR, en s'appuyant sur l'architecture du serveur FHIR préconstruit sans les conserver dans le référentiel de ressources. Elle fournit donc un niveau de contrôle granulaire sur votre logique.

Architecture de façade FHIR IRIS

HS.FHIRServer.RestHandler Cette classe reçoit et traite toutes les requêtes FHIR entrantes provenant des systèmes clients, puis les transmet à la classe HS.FHIRServer.Service pour un traitement ultérieur.
HS.FHIRServer.Service Cette classe singleton centrale est chargée de traiter les ressources et les paquets FHIR. Elle détermine le type de requête entrante et l'achemine de manière appropriée vers le chemin suivant:

Interactions FHIR: gérées par HS.FHIRServer.Storage.JsonAdvSQL.Interactions. Il s'agit d'une classe d'interactions qui sert de gestionnaire d'interactions principal.
Transactions du regroupement du paquet FHIR: Gérées par HS.FHIRServer.DefaultBundleProcessor.
Opérations FHIR: Traitées par HS.FHIRServer.API.OperationHandler.

Implémentation de la façade FHIR

Conditions préalables à la création d'un serveur FHIR et à l'implémentation d'une façade FHIR dans InterSystems IRIS

Avant de créer un serveur FHIR et d'implémenter la façade FHIR dans InterSystems IRIS, assurez-vous que les configurations suivantes sont correctement définies:

Configurez et activez la base FHIR Foundation dans l'espace de noms requis.
Personnalisez les classes d'implémentation FHIR, y compris les classes suivantes
- RepoManager
- InteractionStrategy
- Interactions

Configuration de la base FHIR Foundation

Étape 1 : Activez la Base FHIR Foundation

Vous devez d'abord activer la base FHIR Foundation. Pour ce faire, suivez les étapes suivantes:

Passez à l'espace de noms HSLIB dans le Portail de gestion du système.
Accédez au menu Health.

Vous y trouverez une liste des espaces de noms de base disponibles.

Pour cette démonstration, nous utiliserons comme exemple l'espace de noms LEARNING (base de données).

Dans la partie supérieure de l'écran, cliquez sur l'assistant d'installation "Installer Wizard" pour afficher l'état de l'espace de noms de la base.
Assurez-vous que votre espace de noms est marqué comme "Activé". Si ce n'est pas le cas, cliquez sur le bouton "Active" pour l'activer.

Configuration manuelle de l'espace de noms de base

Si votre espace de noms n'apparaît pas dans la page de l'assistant d'installation, vous pouvez le configurer manuellement en suivant les étapes ci-dessous:

Cliquez sur Configure Foundation (Configuration de base).
Saisissez les informations requises.
Activez l'espace de noms (par exemple, celui que vous venez de configurer).

Remarque: avant d'ajouter l'espace de noms de base, assurez-vous que les conditions préalables suivantes sont remplies:

Tous les packages, routines et globales HealthShare (HS)* sont correctement mappés à votre espace de noms cible.
Tous les rôles requis sont créés et attribués de manière appropriée.

Sinon, vous risquez de faire face à des erreurs inattendues lors de la configuration.

Une fois configuré, vous pouvez voir l'espace de noms dans la liste de base.

Configuration de la base programmatique

Exécutez la méthode de la classe d'installation ci-dessous:

Do ##class(HS.Util.Installer.Foundation).Install(“FoundationNamespace”)

Bravo! L'espace de noms de base a été configuré et activé avec succès! Cette configuration étant en place, vous êtes désormais prêt à continuer.

Comme toutes les activités liées à la configuration sont automatiquement enregistrées dans des fichiers journaux, vous pouvez vous y référer pour le dépannage si vous rencontrez des problèmes pendant le processus de configuration. (Consultez la section Analyse des fichiers journaux HS pour la configuration pour plus de détails.)

L'étape suivante consiste à personnaliser les classes d'implémentation FHIR afin de répondre à vos besoins spécifiques en matière d'intégration et de traitement.

Personnalisation des classes d'implémentation FHIR

L'architecture du serveur IRIS FHIR permet une personnalisation flexible de ses classes d'implémentation FHIR, que vous étendiez le référentiel de ressources ou que vous écriviez un backend personnalisé. Cela peut être réalisé de deux manières:

Approche façade (recommandée): vous pouvez personnaliser les classes FHIR préconstruites pour interagir directement avec vos ressources FHIR. Cette méthode correspond au modèle de conception façade en abstraissant les systèmes sous-jacents via les interfaces FHIR.
Approche de routage d'interopérabilité: vous pouvez configurer le serveur FHIR pour qu'il transfère les requêtes entrantes vers IRIS Interoperability dès le début du traitement des requêtes. Cela vous permet de tirer parti des composants d'interopérabilité pour la logique et le routage personnalisés. Avec cette approche, vous pouvez configurer la classe Interoperability Service directement dans la configuration du serveur FHIR sous “Service Config Name.” Le serveur FHIR redirigera alors la requête vers votre environnement de production d'interopérabilité.

Remarque: pour cette méthode de routage d'interopérabilité, seule la classe HS.FHIRServer.Interop.Service ou ses sous-classes sont prises en charge. IRIS n'autorise pas l'utilisation d'autres classes de services métiers généraux.

Généralement, un référentiel de ressources de serveur FHIR sans production d'interopérabilité peut permettre d'obtenir des performances nettement plus rapides.

À cette étape, passons à la création de classes personnalisées.

Personnalisation des classes pré-intégrées

Pour commencer à personnaliser le serveur FHIR, créez des sous-classes dans les classes répertoriées ci-dessous. Vous pouvez modifier leur comportement en ajustant les paramètres, en modifiant la logique ou en réécrivant les fonctionnalités selon vos besoins spécifiques.

Remarque: à partir de la version IRIS 2024.1, la logique d'interaction a été mise à jour. Les détails de la nouvelle implémentation sont disponibles ci-dessous. Pour des raisons de compatibilité ascendante, les deux classes héritées et mises à jour sont toujours disponibles. Cependant, si vous travaillez avec la dernière version, il est recommandé d'utiliser l'implémentation mise à jour.

À partir de la version 2024.1:

Pour les versions antérieures à la version 2024.1:

Si vous écrivez une logique backend entièrement personnalisée pour gérer votre architecture de serveur FHIR au lieu d'utiliser le référentiel de ressources, vous devez créer une sous-classe des superclasses d'architecture:

Avant de personnaliser les classes, arrêtons-nous un instant pour comprendre le concept des interactions FHIR.

Qu'est-ce que les interactions FHIR?

Les interactions FHIR sont des opérations standards définies par la spécification FHIR (Fast Healthcare Interoperability Resources) et que les clients peuvent effectuer sur les ressources FHIR à l'aide d'une API RESTful.

Ces interactions définissent la manière de communiquer pour les clients et les serveurs, notamment pour récupérer, créer, mettre à jour ou supprimer des données de soins de santé représentées sous forme de ressources FHIR.

Les interactions FHIR courantes

Ci-dessous, nous avons dressé une liste des principaux types d'interactions FHIR:

Read (Lecture): récupère une ressource à partir de son identifiant (par exemple, GET /Patient/123).

Vread (Lecture versionnée): récupère une version spécifique d'une ressource (par exemple, GET /Patient/123/_history/2).

Update ((mise à jour): met à jour partiellement une ressource (par exemple, PUT /Patient/123).

Patch (correction): interroge les ressources en fonction de paramètres (par exemple, PATCH /Patient/123).

Delete (suppression): supprime une ressource (par exemple, DELETE /Patient/123).

Create (création): ajoute une nouvelle ressource (par exemple, POST /Patient).

Search (recherche): interroge les ressources en fonction de paramètres (par exemple, GET /Patient?name=Ashok).

History (historique): récupère l'historique des modifications d'une ressource ou d'un type de ressource (par exemple, pour une ressource: GET /Patient/123/_history; pour toutes les ressources: GET /_history).

Capabilities (capacités): renvoie une CapabilityStatement indiquant ce que le serveur FHIR prend en charge (par exemple, GET /metadata).

A présent, il faut continuer la personnalisation de nos classes.

Ces trois classes principales forment une chaîne hiérarchique, où elles sont liées les unes aux autres, et constituent ensemble l'infrastructure de base pour l'implémentation de votre serveur FHIR.

Classe d'interaction

HS.FHIRServer.Storage.JsonAdvSQL.Interactions est la classe centrale qui sert de base pour gérer les interactions FHIR via la classe InteractionsStrategy. Elle facilite la communication entre la classe de service et le référentiel de ressources.

Cette classe fournit des méthodes API pour interagir avec le référentiel FHIR au niveau des ressources:

Add(): Crée et stocke une nouvelle ressource dans le référentiel FHIR.
Delete(): Supprime une ressource existante du référentiel.
Read(): Récupère une ressource spécifique du référentiel.
LoadMetadata(): Télécharge les métadonnées à l'aide desquelles la déclaration de capacité est définie. (Consultez la section Modification de la CapabilityStatement Modification de la CapabilityStatement.)

Cette liste de méthodes n'est pas exhaustive.

Les méthodes de la classe d'interactions, qui sont invoquées par la classe Service (HS.FHIRServer.Service.cls) pendant le traitement des requêtes FHIR, peuvent également être appelées directement à partir d'une application Object Script côté serveur. Par exemple, au lieu d'envoyer une requête POST au service, une application côté serveur peut appeler la méthode Add() de la classe d'interactions plutôt que d'envoyer une requête POST au service.

Classe de stratégie d'interaction

La classe HS.FHIRServer.JsonAdvSQL.InteractionsStrategy définit la stratégie globale et la logique backend pour le serveur FHIR. Elle sert de stratégie de stockage et détermine comment les ressources FHIR sont stockées et récupérées.

Chaque InteractionsStrategy est associée à une sous-classe de HS.FHIRServer.API.RepoManager, qui gère les services liés à cette stratégie.

De plus, vous devez configurer les deux paramètres de la classe InteractionsStrategy mentionnés ci-dessous:

StrategyKey: attribue une clé unique utilisée à la fois par InteractionsStrategy et RepoManager (par exemple, Parameter StrategyKey As %String = "MyFacade").

2. InteractionsClass: spécifie la classe d'interactions personnalisée à utiliser (par exemple, Parameter InteractionsClass As %String = "FHIRFacade.Storage.JsonAdvSQL.Interactions").

Classe de gestionnaire de référentiel ((Repo Manager)

Le référentiel de ressources HS.FHIRServer.Storage.JsonAdvSQL.RepoManager est la stratégie de stockage par défaut pour un serveur FHIR. Il vous permet d'installer un serveur FHIR entièrement fonctionnel sans aucune tâche de développement supplémentaire. Ce référentiel stocke automatiquement les données FHIR reçues par le serveur. Cette classe peut créer de nouveaux référentiels, configurer des bases de données FHIR, formuler une stratégie, etc.

En outre, vous devez configurer un paramètre dans la classe RepoManager indiquée ci-dessous:

StrategyKey: attribue une clé unique utilisée à la fois par InteractionsStrategy et RepoManager.

Personnalisation de la classe Interactions

Pour commencer le processus, examinons d'abord la classe d'Interactions.

Création d'une classe personnalisée Étendez la classe HS.FHIRServer.Storage.JsonAdvSQL.Search pour définir votre comportement personnalisé.
Remplacement de la méthode Add() pour des types de ressources spécifiques Au lieu de stocker la ressource dans le référentiel par défaut, redirigez sa gestion vers votre implémentation personnalisée (par exemple, lorsque le type de ressource est Patient). Pour ce faire, remplacez la méthode Add() dans votre classe personnalisée.
Définition des métadonnées requises sur l'objet ressource Dans le cadre de cette personnalisation, assurez-vous que les champs de métadonnées spécifiques sont définis sur pResourceObj. Si vous ne le faites pas, vous risquez de faire face à des erreurs inattendues. Les champs obligatoires sont les suivants:
```
Set pResourceObj.meta = {}
Set pResourceObj.meta.versionId = 1
Set pResourceObj.meta.lastUpdated = $ZDT($H, 3, 7)
```

Cela permettra d'assurer le bon versionnage et l'horodatage des ressources qui sont nécessaires au bon fonctionnement du serveur FHIR.

Include HS.FHIRServer
Class MyFacade.HS.FHIRServer.Storage.JsonAdvSQL.Interactions Extends HS.FHIRServer.Storage.JsonAdvSQL.Search
{
Method Add(pResourceObj As %DynamicObject, pResourceIdToAssign As %String = "", pHttpMethod = "POST") As %String
{
    If pResourceObj.resourceType="Patient" {
        Set sc = ##class(MyFacade.FHIRFacade.Patient.Utils).Create(pResourceObj)
        If $$$ISOK(sc) {
            Return pResourceObj.Id
        }
    }
    Else {
        $$$ThrowFHIR($$$HSFHIRErrResourceNotSupported,pResourceObj.resourceType)
    }
    }
}

/// Ma classe personnalisée pour la gestion de la ressource FHIR. Ici, je peux modifier et stocker des données dans mes classes/globale 
Class MyFacade.FHIRFacade.Patient.Utils Extends %RegisteredObject
{

ClassMethod Create(pResourceObj)  As %Status
{
    ///
    /// Stockage de logique 
    /// Vous devez définir les valeurs ci-dessous comme paires clé-valeur obligatoires dans pResourceObj
    Set pResourceObj.Id=11
    Set pResourceObj.meta = {}
    Set pResourceObj.meta.versionid=1
    Set pResourceObj.meta.lastUpdated = $ZDT($H,3,7)
    Set pResourceObj.meta.LastModified = $ZDT($H,3,7)
}

}

Remarque:dans IRIS, une fois que le serveur FHIR est configuré et activé, les instances de vos classes StrategyInteractions et Interaction sont intentionnellement mises en cache afin d'améliorer les performances globales.

Avant de passer à l'étape suivante de personnalisation, il est important de comprendre la notion de métadonnée CapabilityStatement et comment la définir pour votre serveur FHIR.

Capability Statement

La métadonnée Capability Statement d'un serveur FHIR est une métadonnée destinée au client, elle décrit les fonctionnalités prises en charge par le serveur FHIR. Elle contient des détails que les clients FHIR peuvent récupérer sur le comportement du serveur, les opérations qu'il prend en charge et la manière dont il traite les requêtes FHIR.

Personnalisation de la CapabilityStatement du serveur FHIR

Lorsque vous personnalisez votre serveur FHIR (FHIR Facade), vous devez également mettre à jour la CapabilityStatement afin que les clients FHIR puissent disposer de la description précise de ses capacités. Deux options s'offrent à vous pour ce faire.

En règle générale, vous pouvez accéder à la CapabilityStatement en invoquant l'appel API REST vers votre serveur avec la ressource des métadonnées (your_FHIRServer_URL/metadata).

Par exemple, http://127.0.0.1:52782/fhirapp/r4/metadata

InterSystems IRIS fournit deux méthodes pour personnaliser la CapabilityStatement de l'architecture du serveur FHIR:

1. Remplacement des méthodes dans une classe InteractionStrategy personnalisée (recommandé)

Il s'agit de l'approche préférée et la plus flexible, car elle vous offre un meilleur contrôle sur la manière dont la CapabilityStatement est générée.

La CapabilityStatement est automatiquement régénérée lorsque certains comportements du serveur FHIR changent et est mise en cache Par conséquent, CapabilityStatement est généralement générée lors de l'activation ou de la désactivation du serveur FHIR, etc.

IRIS propose plusieurs méthodes pour mettre à jour différentes parties de la CapabilityStatement, dont la principale est la suivante:

GetCapabilityTemplate()

Cette méthode permet de personnaliser les informations de base (par exemple, le nom, la version, l'éditeur, la description, le statut, etc.). Vous pouvez également remplacer la méthode GetCapabilityTemplate() dans votre classe InteractionStrategy personnalisée afin de renvoyer une structure modifiée adaptée à votre implémentation.

LoadMetadata()

Cette méthode fait partie de la classe Interactions et peut être invoquée par la classe InteractionStrategy pour générer la CapabilityStatement.

Vous pouvez configurer votre CapabilityStatement personnalisée soit directement dans cette méthode, soit en déléguant la logique à une autre classe et en l'appelant à partir de LoadMetadata().

Exemple de personnalisation

J'ai personnalisé la méthode LoadMetadata() comme suit:

J'ai créé une classe personnalisée (FHIRFacade.Utils) pour définir et conserver la CapabilityStatement.
J'ai validé la déclaration et l'ai enregistrée dans les propriétés ..metadata et ..metadataTime.

Method LoadMetadata() As %DynamicObject
{
    #; Obtenez votre déclaration CapabilityStatement en appelant la méthode de votre classe
    Set metadata = ##class(FHIRFacade.Utils).FHIRFacadeCapabilityStatement()
    Set GLOBAL = ..strategy.GetGlobalRoot()
    if metadata="" {
        $$$ThrowFHIR($$$HSFHIRErrMetadataNotConfigured,$$$OutcomeIs(503, "fatal", "transient"))
    }
    if @GLOBAL@("capability", "time") '= ..metadataTime {
        Set ..metadata = ##class(%DynamicObject).%FromJSON(metadata)
        Set ..metadataTime = $Get(@GLOBAL@("capability", "time"),$ZDT($H,3,7))
    }
    Return ..metadata
}

Mise à jour de la CapabilityStatement pour le serveur FHIR

Comme je l'ai mentionné précédemment, le serveur FHIR met en cache la CapabilityStatement afin d'améliorer les performances. Cela signifie que toute modification apportée à la configuration ou à l'implémentation ne peut prendre effet tant que la CapabilityStatement n'a pas été explicitement mise à jour.

Pour mettre à jour la CapabilityStatement, faites comme suit:

Ouvrez le terminal IRIS et exécutez la commande suivante:

DO ##class(HS.FHIRServer.ConsoleSetup).Setup()

Dans le menu, sélectionnez l'option 7 : Mettre à jour la ressource CapabilityStatement.
Choisissez le point de terminaison FHIR que vous souhaitez mettre à jour.
Confirmez la mise à jour lorsque vous y êtes invité.

Vous pouvez également utiliser la méthode de classe mentionnée ci-dessous pour mettre à jour la CapabilityStatement:

ClassMethod UpdateCapabilityStatement(pEndPointKey As %String = "/csp/healthshare/learning/fhirmyfac/r4")
{
    #dim strategy as HS.FHIRServer.API.InteractionsStrategy = ##class(HS.FHIRServer.API.InteractionsStrategy).GetStrategyForEndpoint(pEndPointKey)
    if '$IsObject(strategy) {
    $$$ThrowFHIR($$$GeneralError, "Unable to create Storage Strategy Class")
    }
    Set interactions = strategy.NewInteractionsInstance()
    do interactions.SetMetadata( strategy.GetMetadataResource() )
}

Modification manuelle de la CapabilityStatement

Vous pouvez récupérer, modifier et télécharger manuellement la CapabilityStatement pour un point de terminaison serveur FHIR. Cette approche permet un contrôle total sur la structure et le contenu de la déclaration.

Étapes pour récupérer et exporter la CapabilityStatement:

Obtenez la stratégie d'interaction pour votre point de terminaison FHIR.
Créez une nouvelle instance d'interactions.
Téléchargez la CapabilityStatement existante.
Exportez-la vers un fichier JSON local:

ClassMethod UpdateCapabilityStatamentViaFile()
{
    Set strategy = ##class(HS.FHIRServer.API.InteractionsStrategy).GetStrategyForEndpoint("/fhirapp/r4")
    Set interactions = strategy.NewInteractionsInstance()
    Set capabilityStatement = interactions.LoadMetadata()
    Do capabilityStatement.%ToJSON("c:\localdata\MyCapabilityStatement.json")
}

5. Modifiez le fichier JSON exporté en fonction de votre configuration. Exécutez ensuite le code ci-dessous pour charger la CapabilityStatement mise à jour dans le serveur FHIR:

ClassMethod LoadCapabilitystatmentToFHIR(){ 
      set strategy = ##class(HS.FHIRServer.API.InteractionsStrategy).GetStrategyForEndpoint("/fhirapp/r4")
      set interactions = strategy.NewInteractionsInstance()
      set newCapabilityStatement = {}.%FromJSONFile("c:\localdata\MyCapabilityStatement.json")
      do interactions.SetMetadata(newCapabilityStatement)
}

Configuration du serveur FHIR

Configuration d'un point de terminaison du serveur FHIR

L'interface de configuration FHIR et le processus d'installation ont subi des changements importants dans la version 2025.1, qui sert de référence pour cette documentation

Dans la version 2025.1: pour ajouter un point de terminaison FHIR, accédez à to Portail de gestion IRIS → Health > Gestion du serveur FHIR > Configuration FHIR
- URL: /csp/healthshare/learning/fhirfac/r4
- Espace de noms: sélectionnez votre espace de noms
- Version FHIR: sélectionnez la version FHIR

Dans les versions antérieures à la version 2025.1: Le chemin d'accés a été v → Health > Configuration FHIR Exemple de point de terminaison: /csp/healthshare/learning/fhirfac/r4

Configuration avancée

La section Configuration avancée vous permet de définir une classe de stratégie d'interaction personnalisée après avoir fourni les informations requises:

Configurations supplémentaires

Vous pouvez configurer les paramètres suivants si nécessaire. Sinon, le système appliquera les valeurs par défaut:

Enfin, cliquez sur Créer pour lancer le processus de configuration. Veuillez noter que cela peut prendre un certain temps, car le système effectuera les tâches suivantes:

Configuration de la base de données du serveur FHIR

Base de données des ressources: stocke les ressources FHIR actuelles.

Base de données historique: stocke les versions historiques des ressources.

Cette configuration crée deux bases de données pour stocker les ressources.

Mappages globaux et configuration supplémentaire Le système établit automatiquement les mappages globaux et applique les paramètres de configuration supplémentaires requis pour le serveur FHIR.

Le système est désormais prêt à recevoir les requêtes FHIR et à envoyer les réponses correspondantes.

Analyse des fichiers journaux HS pour la configuration

Fichiers journaux d'activation de l'espace de noms de base

Pendant l'activation de l'espace de noms de base (Foundation) via l'assistant d'installation Installer Wizard, InterSystems IRIS génère automatiquement un ensemble de fichiers journaux.

Ces journaux sont inestimables pour la compréhension et le dépannage du processus de configuration, car ils comprennent généralement les éléments suivants:

Événements d'installation de haut niveau liés à la configuration du serveur FHIR.
Détails de configuration spécifiques à l'espace de noms, qui montrent ce qui a été configuré ou modifié dans chaque espace de noms ciblé.

Les noms des fichiers journaux suivent un modèle précis. Ils commencent par HS.Util.Installer, suivi du nom de l'espace de noms, d'un tiret (-), d'un nombre entier et de l'extension .log. Par exemple: HS.Util.Installer.HSSYS-0.log.

Remarque: le nombre entier augmentera à chaque activation de la base.

Pour récupérer ces répertoires par programmation, procédez comme suit:

Utilisez $system.Util.InstallDirectory() pour obtenir le répertoire d'installation d'IRIS.
Utilisez $system.Util.ManagerDirectory() pour obtenir le chemin d'accès complet au répertoire /mgr/.

Fichiers journaux courants:

HS.Util.Installer.1.log
HS.Util.Installer.HSSYS-0.log
HS.Util.Installer.HSCUSTOM-0.log
HS.Util.Installer.HSLIB-0.log
HS.Util.Installer.HSSYSLOCALTEMP-0.log

Si vous rencontrez des problèmes lors de l'installation ou de la configuration, consultez ces fichiers journaux pour obtenir des informations de diagnostic détaillées.

Remarque: consultez toujours ces fichiers journaux pour vous assurer qu'aucune erreur n'est présente après chaque mise à niveau d'IRIS.

De plus, l'application IRISFHIRServerLogs sur Open Exchange fournit une interface Web permettant de consulter ces journaux.

Débogage du serveur FHIR

InterSystems IRIS fournit un mode de débogage pour le serveur FHIR afin de faciliter le débogage.

Compréhension de la mise en cache des classes dans le serveur FHIR d'InterSystems IRIS

Dans InterSystems IRIS, une fois que le serveur FHIR est configuré et activé, il démarre intentionnellement la mise en cache des instances de vos classes StrategyInteractions et interaction afin d'améliorer les performances globales.

Cependant, en raison de ce mécanisme de mise en cache, les modifications apportées à vos sous-classes ne peuvent pas être reflétées une fois que les classes ont été mises en cache. Autrement dit, les mises à jour de votre logique personnalisée ne prendront effet que si le serveur FHIR crée de nouvelles instances de ces classes.

Pour vous assurer que vos modifications sont reflétées pendant le développement ou les tests, vous pouvez activer le mode débogage, qui force le serveur à produire une nouvelle instance pour chaque requête.

Activation du mode débogage via IRIS Shell

Procédez comme suit pour activer le mode débogage à l'aide du terminal IRIS:

Ouvrez le terminal IRIS et exécutez la commande suivante:

Do ##class(HS.FHIRServer.ConsoleSetup).Setup()

Dans le menu, sélectionnez "Configuration d'un point de terminaison de serveur FHIR".
Lorsque vous y êtes invité, choisissez le point de terminaison que vous souhaitez configurer. Dans la section de modification de la configuration du service FHIR (Edit FHIR Service Configuration), recherchez le paramètre du mode débogage (Debug Mode). Modifiez ensuite sa valeur de 0 à 7 pour activer le mode débogage complet.

Ce paramètre active également les options suivantes:

Autorisation d'accès non authentifié
Nouvelle instance de service par requête
Inclusion des traces dans des réponses

Enregistrez la configuration.

Mises à jour de la déclaration de capacité CapabilityStatement

La commande Do ##class(HS.FHIRServer.ConsoleSetup).Setup() est un outil polyvalent qui ne se limite pas au débogage. Elle peut également être utilisée pour les opérations suivantes:

Configuration, mise à jour et mise hors service des points de terminaison FHIR.
Mise à jour de la déclaration de capacité CapabilityStatement

Macros, classes et globales utiles

Macros

$$$ThrowFHIR: utilisé pour lancer des exceptions conformes à FHIR dans la logique du serveur.
$$$HS*: ensemble de macros qui définissent les messages d'erreur standard liés à FHIR.

Classes

HS.FHIRServer.Installer: fournit les méthodes de classe pertinentes pour l'installation.
HS.FHIRServer.Tools.CapabilityTemplate: offre des modèles et des méthodes d'aide pour créer et personnaliser FHIR CapabilityStatement.
HS.FHIRServer.API.OperationHandler: gère les opérations FHIR personnalisées sur le serveur.
GetMetadataResource(): modifie ou étend le CapabilityStatement renvoyé par le serveur FHIR en remplaçant cette méthode dans votre classe personnalisée.
HS.Util.Installer.Foundation
HS_HC_Util_Installer.Log: stocke de manière interne les détails des fichiers HS.Util.Installer.*.log.

Globales

^HS.FHIRServer.*: stocke les données de configuration du serveur FHIR et les instances de ressources.
^FSLOG: stocke les entrées du journal du serveur FHIR à des fins d'audit et de débogage. L'application Open Exchange FSLog permet de consulter ces journaux sur le Web.
^%ISCLOG: active la journalisation des requêtes HTTP à différents niveaux. Vous trouverez ci-dessous un exemple d'activation de la journalisation détaillée:

Activation de la journalisation:

Définissez ^%ISCLOG = 5

Définissez ^%ISCLOG("Category","HSFHIR") = 5

Définissez ^%ISCLOG("Category","HSFHIRServer") = 5

Désactivation de la journalisation:

Définissez ^%ISCLOG=1

^FSLogChannel: Pour l'activation de la journalisation dans l'espace de noms de base. Cette variable globale spécifie les types d'informations de journalisation qui doivent être capturés. Une fois ^FSLogChannel défini, le système commence à stocker les journaux dans la variable globale ^FSLOG. Pour désactiver les journaux, supprimez le fichier tueur de globale ^FSLogChannel.

Les valeurs channelType disponibles sont "Msg", "SQL", "_include" et "all".

Exemple: Paramétrage ^FSLogChannel("all") = 1; Activation de la journalisation pour tous les types de chaînes.

Erreurs courantes et leurs solutions

"Erreur à la base: "Class Does Not Exist" (La classe n'existe pas):

Même si toutes les configurations ont été effectuées correctement, vous pouvez parfois rencontrer l'erreur suivante. Dans ce cas, pensez à vérifier les points suivants:

Vérifiez que tous les rôles %HS_DB_* ont été créés et correctement mappés à l'espace de noms de base.
Vérifiez les fichiers journaux HS.Util.Installer.* pour l'espace de noms HSSYS et votre espace de noms cible.

Cet article fournit une vue d'ensemble de la configuration de base de la façade FHIR.

Aller à la publication initiale écrit par @Ashok Kumar T