Introduction

Dans mon dernier article, j'ai présenté FHIR Data Explorer, une application de validation de concept qui connecte InterSystems IRIS, Python, et Ollama afin de permettre la recherche sémantique et la visualisation des données de soins de santé au format FHIR. Ce projet participe actuellement au concours InterSystems External Language Contest.

Dans cette suite, nous verrons comment j'ai intégré Ollama pour générer les résumés des dossiers médicaux directement à partir des données FHIR structurées stockées dans IRIS, à l'aide de modèles linguistiques locaux légers (LLM) tels que Llama 3.2:1B ou Gemma 2:2B.

L'objectif était de créer un pipeline d'IA entièrement local capable d'extraire, de formater et de présenter les dossiers médicaux des patients tout en garantissant la confidentialité et le contrôle total des données.

Toutes les données des patients utilisées dans cette démonstration proviennent de paquets FHIR, qui ont été analysés et chargés dans IRIS via le module IRIStool. Cette approche facilite la requête, la conversion et la vectorisation des données de soins de santé à l'aide d'opérations pandas familières en Python. Si vous désirez en savoir plus sur la manière dont j'ai construit cette intégration, consultez mon article précédent Création d'un référentiel vectoriel FHIR avec InterSystems IRIS et Python via le module IRIStool.

Les deux outils, IRIStool et FHIR Data Explorer sont disponibles sur InterSystems Open Exchange — et font partie de mes contributions au concours. Si vous les trouvez utiles, n'hésitez pas à voter pour eux!

• IRIStool et Data Manager
• FHIR Data Explorer

1. Configuration avec Docker Compose

Pour simplifier la configuration et la rendre reproductible, tout fonctionne localement au moyen de Docker Compose.
Une configuration minimale se présente comme suit:

services:
  iris:
    container_name: iris-patient-search
    build:
      context: .
      dockerfile: Dockerfile
    image: iris-patient-search:latest  
    init: true
    restart: unless-stopped
    volumes:
      - ./storage:/durable
    ports:
      - "9092:52773"# Management Portal / REST APIs
      - "9091:1972"# SuperServer port
    environment:
      - ISC_DATA_DIRECTORY=/durable/iris
    entrypoint: ["/opt/irisapp/entrypoint.sh"]

  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    pull_policy: always
    tty: true
    restart: unless-stopped
    ports:
      - 11424:11434
    volumes:
      - ./ollama_entrypoint.sh:/entrypoint.sh
entrypoint: ["/entrypoint.sh"]

Toutes les configurations sont disponibles sur la page du projet GitHub.

2. Intégration d'Ollama dans le flux de travail

Ollama fournit une API REST locale simple pour exécuter efficacement des modèles sur le processeur, ce qui le rend idéal pour les applications de santé où la confidentialité et les performances sont importantes.

Pour connecter IRIS et Streamlit à Ollama, j'ai implémenté une classe Python légère pour transmettre les réponses de l'API Ollama:

import requests, json

classollama_request:def__init__(self, api_url: str):
        self.api_url = api_url

    defget_response(self, content, model):
        payload = {
            "model": model,
            "messages": [
                {"role": "user", "content": content}
            ]
        }
        response = requests.post(self.api_url, json=payload, stream=True)

        if response.status_code == 200:
            for line in response.iter_lines(decode_unicode=True):
                if line:
                    try:
                        json_data = json.loads(line)
                        if"message"in json_data and"content"in json_data["message"]:
                            yield json_data["message"]["content"]
                    except json.JSONDecodeError:
                        yieldf"Error decoding JSON line: {line}"else:
            yieldf"Error: {response.status_code} - {response.text}"

Cela permet de transmettre les résultats du modèle en temps réel, ce qui donne aux utilisateurs l'impression de “surveiller“ le travail de l'IA en direct dans l'interface utilisateur Streamlit.

3. Préparation des données du patient pour LLM

Avant d'envoyer quoi que ce soit à Ollama, les données doivent être compactes, structurées et pertinentes sur le plan clinique.
Pour cela, j'ai écrit une classe qui extrait et formate les données les plus pertinentes du patient (données démographiques, état de santé, observations, procédures, etc.) au format YAML, qui est à la fois compréhensible et compatible avec LLM.

Le processus simplifié est le suivant:

1. Sélectionnez la chaîne du patient dans IRIS via pandas
2. Extrayez les données démographiques et convertissez-les au format YAML
3. Traitez chaque table médicale (conditions, observations, etc.)
4. Supprimez les champs inutiles ou superflus
5. Générez un document YAML concis utilisé comme contexte d'invite LLM.

Cette chaîne est ensuite transmise directement à l'invite LLM, formant le contexte structuré à partir duquel le modèle génère le compte rendu sommaire du patient.

4. Pourquoi limiter le nombre d'enregistrements?

Lors du développement de cette fonctionnalité, j'ai remarqué que la transmission de tous les dossiers médicaux provoquait souvent une confusion ou un biais dans les petits LLM envers les saisies plus anciennes, ce qui faisait perdre de vue les événements récents.

Pour résoudre ce problème, j'ai décidé:

• De n'inclure qu'un nombre limité d'enregistrements par catégorie dans l' ordre chronologique inverse (plus récents en premier)
• D'utiliser un format concis YAML au lieu du format brut JSON
• De normaliser les types de données (horodatages, valeurs nulles, etc.) pour plus de cohérence

Cette conception aide les petits LLM à se concentrer sur les données les plus pertinentes sur le plan clinique data en évitant la “surcharge d'invites”.

💬 4. Génération du dossier médical du patient

Une fois les données au format YAML prêtes, l'application Streamlit les envoie à Ollama au moyen d'une simple invite telle que:

“Vous êtes assistant clinique. À partir des données suivantes du patient, rédigez un dossier médical concis en soulignant les pathologies pertinentes et les tendances récentes.”

Le résultat est renvoyé ligne par ligne à l'interface utilisateur, ce qui permet à l'utilisateur de surveiller la rédaction du dossier en temps réel.
Chaque modèle produit un résultat légèrement différent, même au moyen de la même invite, révélant des différences fascinantes dans le raisonnement et le style.

🧠 5. Comparaison des LLM locaux

Pour évaluer l'efficacité de cette approche, j'ai testé trois modèles ouverts et légers, disponibles via Ollama:

Vous trouverez des exemples de résultats dans le  dossier GitHub suivant. Chaque dossier du patient met en évidence la manière dont la taille du modèle et le style d'entraînement influencent la structure, la cohérence et le niveau de détail du texte.

Voici une interprétation comparative de leur comportement:

• Llama 3.2:1B reproduit généralement la structure des données mot pour mot, presque comme s'il effectuait une exportation de base de données. Ses résumés sont techniquement précis, mais ne sont pas fluides, ressemblant davantage à un rapport clinique structuré qu'à un texte naturel.
• Gemma 3:1B offre une meilleure fluidité linguistique, mais compresse ou omet des détails mineurs. 
• Gemma 2:2B offre le meilleur équilibre. Il organise les informations en sections significatives (conditions, facteurs de risque, recommandations de soins) tout en conservant un ton fluide.

En bref:

• Llama 3.2:1B = précision factuelle
• Gemma 3:1B = dossiers médicaux concis
• Gemma 2:2B = narration cliniquement pertinente

Même sans ajustement, une curation des données et une conception des invites judicieuses permettent aux petits LLM locaux de produire des comptes rendus cliniques cohérents et pertinents dans leur contexte.

🔒 6. Pourquoi les modèles locaux sont-ils importants?

En utilisant Ollama localement, vous obtenez:

• Un contrôle total des données — les données du patient ne disparaissent jamais de l'environnement
• Des performances déterministes — une latence stable sur le processeur
• Un déploiement léger — fonctionne même sans processeur graphique
• Une conception modulaire — facile de passer d'un modèle à l'autre ou d'ajuster les invites

Cette configuration est donc idéale pour les hôpitaux, les centres de recherche ou les environnements universitaires qui souhaitent expérimenter en toute sécurité la documentation et la synthèse basées sur l'IA.

🧭 Conclusion

Cette intégration démontre que même les petits modèles locaux, lorsqu'ils sont correctement guidés par des données structurées et des invites claires, peuvent produire des dossiers médicaux utiles et proches de ceux rédigés par des humains.

Au moyen d'IRIS pour la gestion des données, Python pour convertir les données et Ollama pour la génération de texte, nous obtenons un pipeline IA entièrement local et axé sur la confidentialité pour la génération de renseignements cliniques.

Introduction

Dans mon article précédent, j'ai présenté le module IRIStool, qui intègre de manière transparente la bibliothèque pandas pour Python à la base de données IRIS. Je vais maintenant vous expliquer comment utiliser IRIStool pour exploiter InterSystems IRIS comme base pour une recherche sémantique intelligente dans les données de soins de santé au format FHIR.

Cet article décrit ce que j'ai fait pour créer une base de données pour mon autre projet, FHIR Data Explorer. Les deux projets sont candidats au concours InterSystems actuel, alors n'hésitez pas à voter pour eux si vous les trouvez utiles.

Ils sont disponibles sur Open Exchange:

• IRIStool et Data Manager
• FHIR Data Explorer

Dans cet article, nous aborderons les sujets suivants:

• Connexion à la base de données InterSystems IRIS via Python
• Création d'un schéma de base de données compatible FHIR
• Importation de données FHIR au moyen d'intégrations vectorielles pour la recherche sémantique

Conditions préalables

Installez IRIStool à partir de la page Github IRIStool et Data Manager.

1. Configuration de la connexion IRIS

Commencez par configurer votre connexion à l'aide des variables d'environnement dans un fichier .env:

IRIS_HOST=localhost
IRIS_PORT=9092
IRIS_NAMESPACE=USER
IRIS_USER=_SYSTEM
IRIS_PASSWORD=SYS

Connectez-vous à IRIS à l'aide du gestionnaire de contexte du module IRIStool:

from utils.iristool import IRIStool
import os
from dotenv import load_dotenv
load_dotenv()
with IRIStool(
host=os.getenv('IRIS_HOST'),
port=os.getenv('IRIS_PORT'),
namespace=os.getenv('IRIS_NAMESPACE'),
username=os.getenv('IRIS_USER'),
password=os.getenv('IRIS_PASSWORD')
) as iris:
# IRIStool manages the connection automatically
pass

2. Création du schéma FHIR

Commencez par créer une table pour stocker les données FHIR, puis, tout en extrayant les données des paquets FHIR, créez des tables avec des capacités de recherche vectorielle pour chacune des ressources FHIR extraites (comme Patient, Osservability, etc.). 

Le module IRIStool simplifie la création de tables et d'index!

Table de référentiel FHIR

# Créer une table de référentiel principal pour les paquets FHIR brutsifnot iris.table_exists("FHIRrepository", "SQLUser"):
    iris.create_table(
        table_name="FHIRrepository",
        columns={
            "patient_id": "VARCHAR(200)",
            "fhir_bundle": "CLOB"
        }
    )
    iris.quick_create_index(
        table_name="FHIRrepository",
        column_name="patient_id"
    )

Table de patients avec support vectoriel

# Création d'une table de patients au moyen de la colonne vectorielle pour la recherche sémantiqueifnot iris.table_exists("Patient", "SQLUser"):
    iris.create_table(
        table_name="Patient",
        columns={
            "patient_row_id": "INT AUTO_INCREMENT PRIMARY KEY",
            "patient_id": "VARCHAR(200)",
            "description": "CLOB",
            "description_vector": "VECTOR(FLOAT, 384)",
            "full_name": "VARCHAR(200)",
            "gender": "VARCHAR(30)",
            "age": "INTEGER",
            "birthdate": "TIMESTAMP"
        }
    )
<span class="hljs-comment"># Création d'index standards</span>
iris.quick_create_index(table_name=<span class="hljs-string">"Patient"</span>, column_name=<span class="hljs-string">"patient_id"</span>)
iris.quick_create_index(table_name=<span class="hljs-string">"Patient"</span>, column_name=<span class="hljs-string">"age"</span>)

<span class="hljs-comment"># Création d'un index vectoriel HNSW pour la recherche par similarité</span>
iris.create_hnsw_index(
    index_name=<span class="hljs-string">"patient_vector_idx"</span>,
    table_name=<span class="hljs-string">"Patient"</span>,
    column_name=<span class="hljs-string">"description_vector"</span>,
    distance=<span class="hljs-string">"Cosine"</span>
)</code></pre>
3. Importation de données FHIR à l'aide de vecteurs
Générez facilement des intégrations vectorielles à partir des descriptions des patients FHIR et insérez-les dans IRIS:
from sentence_transformers import SentenceTransformer
# Initialisation du modèle de convertisseur
model = SentenceTransformer('sentence-transformers/all-MiniLM-L6-v2')
# Exemple : Traitement des données du patient
patient_description = "45-year-old male with hypertension and type 2 diabetes"
patient_id = "patient-123"# Création d'un encodage vectoriel
vector = model.encode(patient_description, normalize_embeddings=True).tolist()
# Insertion des données du patient à l'aide du vecteur
iris.insert(
table_name="Patient",
patient_id=patient_id,
description=patient_description,
description_vector=str(vector),
full_name="John Doe",
gender="male",
age=45,
birthdate="1979-03-15"
)
4. Recherche sémantique
Lorsque vos données sont téléchargées, vous pouvez effectuer des recherches par similarité:
# Requête de recherche
search_text = "patients with diabetes"
query_vector = model.encode(search_text, normalize_embeddings=True).tolist()
# définition de requête SQL
query = f"""
SELECT TOP 5
patient_id,
full_name,
description,
VECTOR_COSINE(description_vector, TO_VECTOR(?)) as similarity
FROM Patient
ORDER BY similarity DESC
"""# définition des paramètres de requête
parameters = [str(query_vector)]
# Recherche de patients similaires à l'aide de la recherche vectorielle
results = iris.query(query, parameters)
# Impression des données du DataFrameifnot results.empty:
print(f"{results['full_name']}: {results['similarity']:.3f}")
Conclusion
Le module IRIStool simplifie l'intégration d'IRIS avec des méthodes Python intuitives pour la création de tables et d'index
IRIS prend en charge le stockage hybride SQL + vecteur de manière native, ce qui permet de réaliser les deux requêtes traditionnelles et la recherche sémantique
Les intégrations vectorielles permettent une recherche intelligente dans les données de soins de santé FHIR à l'aide du langage naturel
Les index HNSW fournissent une recherche par similarité efficace à grande échelle
Cette approche prouve qu'InterSystems IRIS peut servir de base solide pour créer des applications de santé intelligentes avec des capacités de recherche sémantique sur les données FHIR.

Salut!

C'est encore moi 😁. Dans l'article précédent Comment écrire un service API REST pour exporter le paquet FHIR généré au format JSON, nous avons généré une ressource DocumentReference, dont le contenu était encodé en Base64

Question!! Est-il possible d'écrire un service REST pour le décoder? Je voudrais vraiment savoir ce que contiennent les données du message🤔🤔🤔

Bien, allons-y!

1. Créez une nouvelle classe utilitaire datagen.utli.decodefhirjson.cls pour décoder les données contenues dans DocumentReference
 

Class datagen.utli.decodefhirjson Extends%RegisteredObject
{
}

2. Écrivez une fonction Python decodebase64docref pour 
a. parcourir le paquet FHIR
b. découvrir la ressource DocumentReference
  - récupérer le premier élément dans le contenu
   - récupérer la pièce jointe à partir de  contenu
     - récupérer les données à partir de la pièce jointe
c. décoder les données par Base64
 (pour cette partie, j'ai demandé l'aide de Chat-GPT😂🤫) 

Class datagen.utli.decodefhirjson Extends%RegisteredObject
{
ClassMethod decodebase64docref(fhirbundle = "") As%String [ Language = python ]
{
# w##class(datagen.utli.decodefhirjson).decodebase64docref()
import base64
import json
def decode_discharge_summary(bundle_json):
    <span class="hljs-string">"""
    Extracts and decodes the Base64-encoded discharge summary note
    from a FHIR Bundle containing a DocumentReference.
    """</span>
    <span class="hljs-keyword">for</span> entry in bundle_json.get(<span class="hljs-string">"entry"</span>, []):
        resource = entry.get(<span class="hljs-string">"resource"</span>, {})
        <span class="hljs-keyword">if</span> resource.get(<span class="hljs-string">"resourceType"</span>) == <span class="hljs-string">"DocumentReference"</span>:
            # Traverse to the attachment
            content_list = resource.get(<span class="hljs-string">"content"</span>, [])
            <span class="hljs-keyword">if</span> not content_list:
                <span class="hljs-keyword">continue</span>
            attachment = content_list[<span class="hljs-number">0</span>].get(<span class="hljs-string">"attachment"</span>, {})
            base64_data = attachment.get(<span class="hljs-string">"data"</span>)
            <span class="hljs-keyword">if</span> base64_data:
                decoded_text = base64.b64decode(base64_data).decode(<span class="hljs-string">"utf-8"</span>)
                <span class="hljs-keyword">return</span> decoded_text
    <span class="hljs-keyword">return</span> None


# Example usage
# Load your FHIR Bundle JSON from a file or object
#with <span class="hljs-keyword">open</span>(<span class="hljs-string">"fhir_bundle.json"</span>, <span class="hljs-string">"r"</span>) <span class="hljs-keyword">as</span> f:
#    fhir_bundle = json.loads(f)
<span class="hljs-keyword">if</span> fhirbundle==<span class="hljs-string">""</span>:
    rtstr=f<span class="hljs-string">"&#x26a0;&#xfe0f; No input found - JSON string is required."</span>
    jsstr={<span class="hljs-string">"operation_outcome"</span> : rtstr}
    <span class="hljs-keyword">return</span> json.dumps(jsstr, indent=<span class="hljs-number">2</span>)

fhir_bundle = json.loads(fhirbundle)
decoded_note = decode_discharge_summary(fhir_bundle)

<span class="hljs-keyword">if</span> decoded_note:
    #<span class="hljs-keyword">print</span>(<span class="hljs-string">"&#x1f4dd; Decoded Discharge Summary:\n"</span>)
    #<span class="hljs-keyword">print</span>(decoded_note)
    rtstr=f<span class="hljs-string">"&#x1f4dd; Decoded Discharge Summary:\n {decoded_note}"</span>
<span class="hljs-keyword">else</span>:
    #<span class="hljs-keyword">print</span>(<span class="hljs-string">"&#x26a0;&#xfe0f; No DocumentReference with Base64 note found."</span>)
    rtstr=f<span class="hljs-string">"&#x26a0;&#xfe0f; No DocumentReference with Base64 note found."</span>
jsstr={<span class="hljs-string">"data"</span> : rtstr}
<span class="hljs-keyword">return</span> json.dumps(jsstr, indent=<span class="hljs-number">2</span>)
}
}

Pour tester cette fonction, j' essaie une astuce qui consiste à utiliser la fonction genfhirbundle pour générer un paquet FHIR dans une chaîne JSON,  comme expliqué dans l'article précédent Comment écrire un service API REST pour exporter le paquet FHIR généré au format JSON.  

Générons un paquet FHIR et stockons-le dans une variable jsonstr

set jsonstr=##class(datagen.utli.genfhirjson).genfhirbundle(1)

Testons la fonction de décodage decodebase64docref  avec jsonstr

w##class(datagen.utli.decodefhirjson).decodebase64docref(jsonstr)

Bien 😉 Ça semble correct. Je peux désormais lire le message décodé.

Maintenant,  revenez à l'article précédent Comment écrire un service API REST pour exporter les données patient générées au format .csv

Nous aimerions ajouter une nouvelle fonction et mettre à jour le chemin d'accès pour la classe datagen.restservice .

1. Ajoutez une nouvelle fonction DecodeDocRef, qui est censée traiter le paquet FHIR  joint dans le corps au format JSON.

Par exemple, dans ce cas, nous prévoyons un POST.

Le contenu du corps est packagé par défaut sous la forme %CSP.BinaryStream et stocké dans la variable %request.Content, nous pouvons donc utiliser la fonction .Read()  à partir de la classe %CSP.BinaryStream pour lire le BinaryStream

ClassMethod DecodeDocRef() As%Status
{
    // récupération du corps - chaîne json#dim bistream As%CSP.BinaryStream =""set bistream=%request.Contentset jsstr=bistream.Read()
<span class="hljs-comment">//décodage des données de référence du document</span>
<span class="hljs-keyword">w</span> <span class="hljs-keyword">##class</span>(datagen.utli.decodefhirjson).decodebase64docref(jsstr)
<span class="hljs-keyword">return</span> <span class="hljs-built_in">$$$OK</span>
}

2. Ensuite, nous ajoutons un chemin d'accès pour le service REST et compilons😀

<Route Url="/decode/docref" Method="POST" Call="DecodeDocRef" />

La classe  datagen.restservice mise à jour se présentera comme suit.

Génial!! C'est tout ce qu'il y a à faire!😁

Nous allons vérifier cela dans Postman!!

COLLEZ le chemin d'accès  suivant

localhost/irishealth/csp/mpapp/decode/docref

avec le corps suivant (j'ai utilisé un paquet FHIR simplifié, vous pouvez tester le paquet complet😀)

{
    "resourceType": "Bundle",
    "type": "transaction",
    "id": "98bfce83-7eb1-4afe-bf2b-42916512244e",
    "meta": {
        "lastUpdated": "2025-10-13T05:49:07Z"
    },
    "entry": [
        {
            "fullUrl": "urn:uuid:5be1037d-a481-45ca-aea9-2034e27ebdcd",
            "resource": {
                "resourceType": "DocumentReference",
                "id": "5be1037d-a481-45ca-aea9-2034e27ebdcd",
                "status": "current",
                "type": {
                    "coding": [
                        {
                            "system": "http://loinc.org",
                            "code": "18842-5",
                            "display": "Discharge summary"
                        }
                    ]
                },
                "subject": {
                    "reference": "9e3a2636-4e87-4dee-b202-709d6f94ed18"
                },
                "author": [
                    {
                        "reference": "2aa54642-6743-4153-a171-7b8a8004ce5b"
                    }
                ],
                "context": {
                    "encounter": [
                        {
                            "reference": "98cd848b-251f-4d0b-bf36-e35c9fe68956"
                        }
                    ]
                },
                "content": [
                    {
                        "attachment": {
                            "contentType": "text/plain",
                            "language": "en",
                            "data": "RGlzY2hhcmdlIHN1bW1hcnkgZm9yIHBhdGllbnQgOWUzYTI2MzYtNGU4Ny00ZGVlLWIyMDItNzA5ZDZmOTRlZDE4LiBEaWFnbm9zaXM6IFN0YWJsZS4gRm9sbG93LXVwIGluIDIgd2Vla3Mu",
                            "title": "Discharge Summary Note"
                        }
                    }
                ]
            },
            "request": {
                "method": "POST",
                "url": "DocumentReference"
            }
        }
    ]
}

Ça marche parfaitement!!!😆😉

Merci infiniment à tous d'avoir pris le temps de lire cet article. 😘

Bonjour à tous,

Continuons à travailler sur la génération de données de test et l'exportation des résultats via une API REST. 😁

Ici, je souhaite réutiliser la classe `datagen.restservice` créée dans l'article précédent : « Écriture d'un service API REST pour exporter les données patient générées au format .csv ».

Cette fois-ci, nous prévoyons de générer un bundle FHIR incluant plusieurs ressources pour tester le référentiel FHIR.

Voici une référence si vous souhaitez en savoir plus sur FHIR : « The Concept of FHIR: A Healthcare Data Standard Designed for the Future ».

C'est parti ! 😆

Les versions de maintenance 2025.1.2 et 2024.1.5 de la plateforme de données InterSystems IRIS, d'InterSystems IRIS for Health et d'HealthShare Health Connect sont désormais disponibles en disponibilité générale (GA). Ces versions incluent les correctifs pour plusieurs alertes et avis publiés récemment, notamment :

Salut la Communauté!

Profitez de regarder la nouvelle vidéo sur la chaîne Youtube d'InterSystems France :

📺 HL7 FHIR et l’Espace Européen des Données de Santé, accélérateurs d’innovation au CHU de Toulouse

Composants, architectures et modèles FHIR

FHIR offre un cadre flexible et évolutif pour l'interopérabilité des données de santé. Pour tirer pleinement parti de FHIR, il est nécessaire de comprendre les composants, architectures et modèles clés qui permettent l'intégration et l'échange des données. À un niveau élevé, les capacités de FHIR sont organisées en composants suivants:

• Un courtier FHIR sert en tant qu'intermédiaire multi-routage, rationalisant le flux et l'échange de données de santé entre différents systèmes. Il permet une interopérabilité transparente en gérant les transactions, en coordonnant des systèmes disparates et en garantissant que les données circulent de manière efficace et sécurisée. Pour les partenaires de solutions de santé numériques, les courtiers FHIR simplifient l'échange de données, agissant comme des "chambres de compensation" et facilitant l'intégration et la mise à l'échelle des applications dans un écosystème complexe, sans avoir besoin de récupérer des données FHIR supplémentaires dans une base de données.
• Une façade FHIR agit comme une interface unique qui résume la complexité d'une base de données non FHIR sous-jacente, permettant ainsi aux développeurs de se concentrer sur les fonctionnalités de l'application plutôt que sur la gestion des données de bas niveau. La façade se trouve "devant" un système non FHIR unique afin que les opérations basées sur FHIR puissent fonctionner avec ce système.
• Un référentiel FHIR fournit un magasin de données centralisé qui gère et fournit les données de santé au format FHIR natif et qui garantit l'intégrité, la sécurité et le contrôle d'accès des données. Un référentiel offre les avantages d'une intégration et d'une gestion plus faciles, ainsi que de meilleures performances et des requêtes et mises à jour plus efficaces.

Ensemble, ces composants FHIR permettent aux développeurs de créer des applications de soins de santé flexibles, performantes et sécurisées, améliorant ainsi les résultats pour les patients tout en réduisant les coûts de développement et de maintenance.

La pile FHIR d'InterSystems offre un choix aux développeurs FHIR, en tirant parti d'une expertise solide en matière d'intégration et de gestion des données pour prendre en charge tous les principaux modèles architecturaux FHIR qui combinent les composants FHIR précédents de différentes manières. La suite complète de fonctionnalités FHIR d'InterSystems facilite non seulement la conformité aux normes FHIR, mais améliore également l'interopérabilité des données entre différents systèmes. En combinant ses compétences techniques et sa connaissance approfondie du domaine, InterSystems aide les développeurs à naviguer dans les complexités de l'adoption de FHIR et à mettre en œuvre les solutions FHIR les mieux adaptées à leurs besoins.

La sécurité est un aspect essentiel de la gestion des données relatives aux soins de santé, et InterSystems fournit des outils robustes pour garantir la sécurité de ses interfaces FHIR. Ceux-ci incluent le contrôle d'accès basé sur les rôles (RBAC), la prise en charge OAuth2 pour FHIR et la journalisation des audits afin de garantir la conformité avec les réglementations en matière de soins de santé telles que HIPAA.

Examinons comment chacun de ces composants FHIR fonctionne avec le logiciel InterSystems afin de vous aider à choisir le modèle architectural le mieux adapté à vos besoins.

Courtiers FHIR

Un courtier FHIR est un intermédiaire multi-routage qui facilite l'échange de données rélatif aux soins de santé à l'aide de la norme FHIR. Il agit comme un connecteur entre des systèmes d'information de santé disparates, leur permettant de communiquer efficacement en convertissant et en acheminant les ressources FHIR. Un courtier FHIR est essentiel dans les environnements où plusieurs systèmes, tels que les dossiers médicaux électroniques (EHR) , les applications cliniques et les systèmes de gestion des patients, doivent partager des données de manière transparente tout en respectant la norme FHIR.

Les capacités du courtier FHIR d'InterSystems (InterSystems FHIR Broker) constituent la pierre angulaire d'une architecture FHIR en fournissant des outils robustes pour la conversion, la validation et l'agrégation des données. Cela facilite la mise en œuvre de solutions basées sur FHIR qui peuvent répondre à des défis spécifiques, tels que l'intégration de plusieurs systèmes hérités. Par exemple, un réseau hospitalier peut intégrer les données des patients provenant de divers systèmes EHR, et InterSystems FHIR Broker peut agréger les informations de ces systèmes, les normaliser au format FHIR et les présenter sous une vue unifiée. Les cliniciens peuvent alors accéder en temps réel à des informations complètes sur les patients, ce qui améliore la coordination des soins et réduit le risque d'erreurs. En outre, un courtier FHIR peut faciliter le partage sécurisé et évolutif des données pour la gestion de la santé de la population, permettant aux prestataires de soins de santé d'analyser les tendances et d'améliorer les résultats, par exemple pour les maladies cardiaques, le sevrage tabagique et l'obésité infantile, pour différentes populations de patients.

Le modèle de données InterSystems SDA (Architecture de document récapitulatif) est conçu pour rendrele processus de conversion des formats de données rélatives aux soins de santé hérités en normes modernes telles que FHIR plus efficace. SDA fournit une représentation unifiée des données pour divers formats de données de soins de santé hérités, tels que HL7 v2, CDA (Architecture de document clinique) ou des formats de fichiers plats personnalisés. Ce format intermédiaire comble le fossé entre les systèmes hérités hautement structurés et la structure plus modulaire et flexible de FHIR, et fonctionne idéalement dans le cadre d'une solution de courtier FHIR Broker.

SDA agit également comme une couche d'abstraction qui normalise les données provenant de différentes sources dans un format commun. Cette abstraction réduit la complexité de la conversion directe de chaque format en FHIR, car SDA fournit une structure normalisée.

Une fois converties au format SDA, les données peuvent être réutilisées dans plusieurs systèmes. La conversion au format SDA ne doit être effectuée qu'une seule fois pour chaque format hérité. À partir du format SDA, les données peuvent être exportées vers divers standards modernes, y compris FHIR, ce qui réduit le besoin de conversions multipoints.

InterSystems fournit des outils et des connecteurs intégrés qui facilitent la conversion des formats hérités vers SDA et de SDA vers FHIR. Cela inclut des mappages prédéfinis, des analyseurs syntaxiques et une logique de transformation. InterSystems prend également en charge les profils FHIR personnalisés, ce qui permet de convertir les données SDA en profils FHIR qui répondent à des exigences organisationnelles ou réglementaires spécifiques.

Façades FHIR

Une façade FHIR est un modèle architectural utilisé dans les systèmes de santé pour fournir une interface conforme à FHIR au-dessus d'un système existant non conforme à FHIR. Elle agit comme une interface habilitante qui expose les données et les services des systèmes hérités non FHIR dans un format FHIR standardisé, permettant ainsi l'interopérabilité avec les applications de soins de santé modernes sans avoir besoin de modifier profondément les systèmes hérités sous-jacents. Contrairement à un courtier FHIR qui coordonne plusieurs systèmes, une façade FHIR se place "devant" un seul système non FHIR.

De nombreux systèmes de soins de santé reposent sur des normes plus anciennes telles que HL7 v2, CDA (Architecture de document clinique) ou des formats de données personnalisés incompatibles avec FHIR. Les façades FHIR fournissent une solution en convertissant à la demande les données dans des formats plus anciens au format FHIR, répondant ainsi aux normes d'interopérabilité modernes et s'intégrant à de nouvelles applications, telles que les systèmes de dossiers médicaux électroniques (DME), les échanges d'informations de santé (HIE) et les applications pour patients.

Réussite des clients grâce à InterSystems et FHIR

Leumit Health Services, une organisation de soins de santé en Israël, cherchait à améliorer le partage des données entre les payeurs et les prestataires afin de faciliter l'accès aux soins pour ses membres.

En collaboration avec des experts locaux dans la mise en œuvre de HL7 FHIR et un centre médical local, Leumit a développé une solution intégrant leurs systèmes individuels via une façade FHIR. Avec cette solution, l'enregistrement des patients a été automatisé: l'éligibilité est déterminée immédiatement et sur place grâce au partage de données basé sur FHIR via InterSystems IRIS for Health.

Principales caractéristiques d'une façade FHIR

• Conversion des données en temps réel – Une façade FHIR convertit les données en temps réel, transformant les requêtes et les réponses entre le format natif du système existant et les ressources FHIR.
• Aucune interruption des systèmes existants – Le système sous-jacent continue de fonctionner comme d'habitude, tandis que la façade gère les interactions FHIR, minimisant ainsi le besoin de modifications coûteuses et perturbatrices de l'infrastructure existante.
• Modernisation progressive – Une façade FHIR permet aux organisations de se moderniser progressivement en exposant une API conforme à FHIR pour une utilisation externe sans avoir à réviser les systèmes existants en une seule étape.
• Interopérabilité – En transformant les formats hérités en FHIR, une façade FHIR permet l'interopérabilité avec d'autres systèmes, applications et plateformes de soins de santé qui nécessitent la conformité FHIR.

InterSystems IRIS for Health offre un ensemble idéal d'outils et de technologies pour la mise en œuvre d'une façade FHIR, car elle supporte nativement FHIR et les conversions de données FHIR.

InterSystems IRIS for Health prend en charge l'utilisation de profils et d'extensions FHIR personnalisés, permettant ainsi aux organisations d'adapter la façade FHIR à leurs besoins spécifiques. Grâce à cette flexibilité, la façade FHIR peut s'adapter aux exigences régionales ou organisationnelles en matière d'échange de données tout en respectant les normes FHIR.

Référentiels FHIR

Un référentiel FHIR offre un moyen plus pratique et plus efficace de gérer les données de soins de santé qu'une façade FHIR. Si les deux approches visent à fournir une interopérabilité et à faciliter l'utilisation du FHIR, un référentiel FHIR offre de nombreux avantages en termes de gestion des données, de performances et de facilité d'intégration. Un référentiel FHIR stocke, gère et fournit des données de soins de santé au format FHIR natif, offrant ainsi une plateforme centralisée où les données peuvent être interrogées et mises à jour efficacement. Cela contraste avec une façade FHIR, qui sert en tant que frontal pour les systèmes existants, traduisant en temps réel les formats non FHIR vers le format FHIR.

Le référentiel FHIR d'InterSystems est spécialement conçu pour stocker et gérer les données au format FHIR et élimine le besoin de conversion des données en temps réel. En stockant nativement les ressources FHIR, le référentiel peut traiter plus efficacement les requêtes et les mises à jour FHIR complexes.

Les requêtes directes vers les référentiels FHIR, sans besoin de mappages intermédiaires, sont particulièrement utiles pour les recherches complexes, telles que les requêtes sur les dossiers de patients qui couvrent plusieurs ressources FHIR (par exemple, Patient, Condition, Observation). Toutes les données sont stockées au même endroit au format FHIR. Cela améliore la cohérence, l'efficacité et la fiabilité du stockage et de l'accès aux données.

Les référentiels FHIR d'InterSystems sont conçus pour s'adapter efficacement à la croissance des organisations de soins de santé et à l'augmentation des volumes de données. Étant donné qu'un référentiel stocke des données FHIR préconverties, le système est optimisé pour offrir des performances élevées lors du traitement de requêtes simultanées provenant de plusieurs systèmes. InterSystems dispose d'un laboratoire d'évolutivité pour évaluer les performances FHIR. Ce laboratoire exécute régulièrement une suite complète de tests de performance FHIR, qui montrent une amélioration notable des requêtes de recherche FHIR complexes. De simples recherches dans le référentiel permettent de récupérer plus de 160 000 ressources FHIR par seconde, avec des performances similaires dans des cas plus exigeants (Jamieson & Banand, 2024).¹

InterSystems fournit un référentiel FHIR entièrement conforme et prêt à l'emploi. Cela élimine le besoin d'une configuration complexe et permet aux organismes de santé de déployer rapidement un référentiel FHIR conforme aux normes FHIR les plus récentes. Cette pile prend en charge toutes les principales interactions FHIR, y compris la création, la récupération, la mise à jour et la suppression de ressources. InterSystems veille à ce que son référentiel FHIR reste conforme aux normes FHIR en constante évolution, en offrant une prise en charge des dernières ressources et fonctionnalités FHIR. Cela garantit la compatibilité avec d'autres systèmes basés sur FHIR et la pérennité face à l'évolution des normes de soins de santé.

Extension de la puissance des référentiels FHIR avec InterSystems IRIS

Le référentiel FHIR intégré s'intègre de manière native à la plateforme de données InterSystems IRIS for Health, ce qui permet une interaction transparente avec d'autres systèmes et applications de soins de santé. Cela facilite l'ingestion, le stockage et la récupération des ressources FHIR sans complexité supplémentaire.

InterSystems IRIS for Health contient une base de données multimodèle et prend en charge des modèles avancés d'analyse, d'IA et d'apprentissage automatique. Le référentiel FHIR de cette plateforme peut servir de base à la création de solutions analytiques qui exploitent des données de soins de santé structurées et normalisées. L'outil unique FHIR SQL Builder d'InterSystems permet aux développeurs de "projeter" des ressources FHIR dans un format relationnel, ce qui facilite l'utilisation d'outils ANSI SQL ou BI pour l'analyse. Comme cette plateforme est une véritable base de données multimodèle, elle peut effectuer ces projections en temps réel, ce qui permet aux utilisateurs d'analyse de disposer en permanence d'informations à jour sans avoir à dupliquer leurs données dans un entrepôt de données.

InterSystems IRIS for Health permet aux organisations d'appliquer des analyses de santé publique, de pronostiquer les résultats des patients et d'optimiser les opérations cliniques en stockant et en interrogeant les données au format FHIR.

Pourquoi choisir les solutions FHIR d'InterSystems?

Lorsque vous développez un courtier FHIR, une façade FHIR ou un référentiel FHIR, le choix de la pile technologique peut avoir un impact significatif sur votre réussite. Découvrez pourquoi la pile FHIR d'InterSystems est la solution idéale:

• Prise en charge complète et évolutive de FHIR – Prise en charge complète et évolutive de FHIR – InterSystems fournit une prise en charge complète des normes FHIR les plus récentes dans toutes les versions. Avec une expérience éprouvée dans le traitement de grands volumes de données cliniques, la plateforme InterSystems IRIS for Health est conçue pour être évolutive. Lorsque vous développez un simple courtier FHIR ou un référentiel FHIR complexe, InterSystems vous garantit une évolutivité efficace sans compromettre les performances, même dans des environnements à haut volume. Notre coordinateur InterSystems Bulk FHIR unique permet l'exportation en masse depuis d'autres serveurs FHIR et DME prenant en charge Bulk FHIR, ce qui facilite la gestion de toutes vos données FHIR en un seul endroit.
• Intégration transparente avec les systèmes existants – L'un des plus grands défis dans le domaine des technologies de l'information appliquées aux soins de santé est l'intégration de nouvelles solutions aux systèmes existants. La pile FHIR d'InterSystems offre une passerelle transparente entre les applications modernes basées sur FHIR et les normes HL7 v2, HL7 v3 et CDA plus anciennes. Cette interopérabilité garantit une communication continue dans tout l'environnement informatique de votre organisation sans avoir à réorganiser votre infrastructure existante, ce qui la rend idéale pour les façades FHIR et nos services uniques de conversion FHIR.
• Performance et fiabilité éprouvées – Dans le domaine de la santé, la fiabilité est incontournable. InterSystems a une solide réputation en matière de performances de niveau entreprise, avec une haute disponibilité et une faible latence. La pile FHIR est construite sur InterSystems IRIS for Health, la plateforme de données spécialement conçue pour les charges de travail de soins de santé. Elle garantit une disponibilité constante et un échange de données en temps réel efficace, que vous gériez un référentiel FHIR ou que vous serviez de courtier FHIR.
• Gestion avancée des données et sécurité – La sécurité des données et la confidentialité des patients sont primordiales dans le domaine des soins de santé. FHIR Stack d'InterSystems offre des fonctionnalités de sécurité robustes et intégrées pour protéger les données de soins de santé sensibles. Il est entièrement conforme à la norme HIPAA et à d'autres normes globales, fournissant des contrôles d'accès basés sur les rôles, la journalisation des audits et des capacités de chiffrement. Pour les organisations qui créent des référentiels FHIR, cette conformité est synonyme de tranquillité d'esprit lors du stockage et de l'échange de grands ensembles de données.
• Outils de développement et de personnalisation étendus – Grâce à des environnements de développement complets, comprenant des API, des SDK et FHIR SQL Builder, InterSystems vous aide à personnaliser et à étendre votre solution FHIR en fonction de vos besoins spécifiques. Que vous ayez besoin d'un courtier FHIR léger ou d'un référentiel FHIR riche en fonctionnalités, nos outils et nos services d'assistance robustes permettent une personnalisation rapide, réduisant ainsi les délais de mise sur le marché.
• Soutien exceptionnel aux fournisseurs et écosystème – InterSystems est réputé pour son assistance clientèle exceptionnelle, qui comprend un accès 24 h/24 et 7 j/7 à des ressources techniques et à une vaste communauté de développeurs. Notre solide écosystème de partenaires et de solutions vous garantit de ne jamais travailler de manière isolée. Que vous ayez besoin de conseils sur les meilleures pratiques pour les façades FHIR ou d'une assistance technique pour votre référentiel FHIR, vous pouvez toujours compter sur notre aide.

Plus d'articles sur le sujet:

• FHIR-HL7v2-SQL-Demo
• Mon expérience avec FHIR
• iOS, FHIR et IRIS for Health
• fhir-integratedml-example overview
• Stratégie Python pour FHIR d'Iris
• Voici un exemple simple d'un client Fhir en python
• Voici un exemple simple d'un client Fhir en c#
• Voici un exemple simple d'un client Fhir en java
• Personnalisation du référentiel FHIR avec Python intégré
• Guide de configuration de l'environnement FHIR

Source: Rationalisation de l'intégration des données de santé avec FHIR

Lorsque nous créons un référentiel FHIR dans IRIS, nous avons un point de terminaison pour accéder à l'information, créer de nouvelles ressources, etc. Mais il y a certaines ressources dans FHIR que nous n'aurons probablement pas dans notre référentiel, par exemple, la ressource Binary (cette ressource renvoie des documents, comme des PDF par exemple).

J'ai créé un exemple dans lequel, quand une ressource est demandée via "Binary", l'endpoint FHIR renvoie une réponse, comme si elle existait dans le référentiel. 

Tout d'abord, nous avons besoin du Namespace (espace de noms) et du FHIR endpoint (point d'accès FHIR). Ensuite, nous devons configurer une production d'interopérabilité - Interoperability production - qui sera connectée à l'endpoint FHIR. Cette production devrait contenir les éléments suivants:

• Business Operation:
  • HS.Util.Trace.Operations (Ceci est évidemment facultatif, mais peut s'avérer très utile)
  • HS.FHIRServer.Interop.Operation, avec la propriété TraceOperations configurée à *FULL*
• Business Service:
  • HS.FHIRServer.Interop.Service, avec la propriété TraceOperations configurée à *FULL* et Target Config Name configurée à  HS.FHIRServer.Interop.Operation name

La production se présente comme suit:

Après avoir créé cette production, nous devons la connecter avec l'endpoint FHIR. Il faut donc éditer l'endpoint FHIR et configurer le paramètre Service Config Name avec le nom du Business Service:

Maintenant, si nous commençons à envoyer des requêtes au référentiel FHIR, nous verrons toutes les traces dans l'Afficheur de messages:

Nous pouvons maintenant établir un Business Process pour contrôler ce qu'il convient de faire avec des chemins d'accès spécifiques.

Dans cet exemple, nous avons un Business Process qui reçoit toutes les demandes (maintenant le Business Service est connecté à ce Business Process, au lieu du Business Operation) et 2 nouvelles Business Operations qui effectuent d'autres actions dont nous parlerons plus tard:

Jetons un coup d'œil au Business Process appelé FHIRRouter:

En regardant, nous verrons que, si RequestPath contient "Binary/", alors nous ferons quelque chose avec cette requête: générer notre réponse Binary personnalisée. Sinon, nous enverrons la demande au référentiel FHIR directement.

Jetons un coup d'œil à la séquence appelée "Generate Binary":

Tout d'abord, nous créons une nouvelle instance de HS.FHIRServer.Interop.Response. Nous obtenons document ID à partir du chemin d'accès: Request Path. Comment? Chaque fois que quelqu'un veut une ressource binaire, elle doit être demandée avec l'identifiant du document dans le chemin de l'URL, quelque chose comme ceci: ..../fhir/r4/Binary/XXXXX. Ainsi, pour extraire l'identifiant du document du chemin d'accès, nous utilisons l'expression suivante:

$Replace(request.Request.RequestPath,"Binary/","")

(Ce n'est pas vraiment raffiné, mais cela fonctionne).

Si nous avons un identifiant de document, nous faisons appel à un Business Operation appelée Find pour rechercher le nom de fichier associé à cet identifiant de document:

En fait, cette recherche deBusiness OperationFind renvoie toujours le même nom de fichier:

L'exemple ci-dessus montre ce que nous pouvons faire.

Si nous avons un nom de fichier, alors, nous appelons un autre Business Operation appelé File pour obtenir le contenu de ce fichier, encodé en base64:

And finally, we can return 2 kind of responses:

• Si nous n'avons pas de contenu de fichier (puisque nous n 'avons pas d 'identifiant de document ou que nous ne trouvons pas le nom de fichier ou le contenu associé), nous renvoyons une réponse 404, avec cette réponse personnalisée:

 set json = {
    "resourceType": "OperationOutcome",
    "issue": [
        {
            "severity": "error",
            "code": "not-found",
            "diagnostics": "<HSFHIRErr>ResourceNotFound",
            "details": {
                "text": "No resource with type 'Binary'"
            }
        }
    ]
 }
 set json.issue.%Get(0).details.text = json.issue.%Get(0).details.text_" and id '"_context.docId_"'"
 set qs = ##class(HS.SDA3.QuickStream).%New()
 do qs.Write(json.%ToJSON())
 set response.QuickStreamId = qs.%Id()
 set response.ContentType = "application/fhir+json"
 set response.CharSet = "UTF-8"

• Si nous avons le contenu du fichier, nous renvoyons une réponse 200 avec cette réponse personnalisée:

 set json = {
  "resourceType": "Binary",
  "id": "",
  "contentType": "application/pdf",
  "securityContext": {
    "reference": "DocumentReference/"
  },
  "data": ""
 }
 set json.id = context.docId
 set json.securityContext.reference = json.securityContext.reference_json.id
 set json.data = context.content.Read(context.content.Size)
 
 set qs = ##class(HS.SDA3.QuickStream).%New()
 do qs.Write(json.%ToJSON())
 set response.QuickStreamId = qs.%Id()
 set response.ContentType = "application/fhir+json"
 set response.CharSet = "UTF-8"

La clé ici est de créer un HS.SDA3.QuickStream, qui contient l'objet JSON. Et d'ajouter ce QuickStream à la réponse.

Et maintenant, si nous testons notre point d'accès, si nous demandons un document de type Binary, nous verrons la réponse:

Et si nous requérons un document de type Binary qui n'existe pas (vous pouvez le tester sans spécifier l'identifiant du document), nous obtiendrons la réponse 404:

En résumé, en connectant notre endpoint FHIR avec l'interopérabilité, nous pouvons faire tout ce que nous voulons, avec toutes les capacités d'InterSystems IRIS.

Bonjour la Communauté !

Je voulais vous partager mes impressions du Meetup FHIR France #13, organisé par Fyrstain et sponsorisé par InterSystems – et franchement, c’était une soirée inoubliable ! C’était une soirée riche en échanges, en apprentissages et en belles rencontres !

L’accueil a débuté à 19h et @Guillaume Rongier a aidé à enregistrer les participants

Après avoir laissé les participants arriver tranquillement, nous avons officiellement lancé la soirée. Fanch Rouault a souhaité la bienvenue au nom de Fyrstain

Je sais que ceux qui découvrent VS Code, Git, Docker, FHIR et d'autres outils peuvent parfois avoir des difficultés à configurer l'environnement. J'ai donc décidé de rédiger un article qui explique étape par étape l'ensemble du processus de configuration afin de faciliter les premiers pas.

Je vous serais très reconnaissant de bien vouloir laisser un commentaire à la fin de cet article pour me faire savoir si les instructions étaient claires, s'il manquait quelque chose ou si vous avez d'autres suggestions qui pourraient être utiles.

La configuration comprend:

✅ VS Code – Éditeur de code
✅ Git – Système de contrôle de version
✅ Docker – Lancement d'une instance de la communauté IRIS for Health
✅ Extension VS Code REST Client – Pour l'exécution de requêtes API FHIR
✅ Python – Pour l'écriture de scripts basés sur FHIR
✅ Jupyter Notebooks – Pour les tâches liées à l'IA et au FHIR

Avant de commencer: Vérifiez que vous disposiez des privilèges d'administrateur sur votre système.

Outre la lecture du guide, vous pouvez également suivre les étapes décrites dans les vidéos:

Pour Windows

<iframe allowfullscreen="" frameborder="0" height="360" src="https://www.youtube.com/embed/IyvuHbxCwCY" width="640"></iframe>

Pour macOS

<iframe allowfullscreen="" frameborder="0" height="360" src="https://www.youtube.com/embed/Ss7vU0l3JNU" width="640"></iframe>

Vous trouverez un sondage à la fin de l'article, merci de partager vos progrès. Vos commentaires sont très appréciés.

Alors, c'est parti!

1. Installation de Visual Studio Code (VS Code)

VS Code sera l'éditeur principal pour le développement.

Windows et amp; macOS

1. Accédez à la page de téléchargement de VS Code: https://code.visualstudio.com/
2. Téléchargez le programme d'installation pour votre système d'exploitation:
   • Windows: .exe file
   • macOS: .dmg file
3. Exécutez le programme d'installation et suivez les instructions.
4. (Windows uniquement) : pendant l'installation, cochez la case Add to PATH" (Ajouter au PATH).
5. Vérifiez l'installation:

• ouvrez un terminal (Command Prompt, , PowerShell ou Terminal macOS)
• Exécutez:

code --version

• Vous devriez voir le numéro de version.

2. Installation de Git

Git est nécessaire pour le contrôle de version, le clonage et la gestion des référentiels de code.

Windows

1. Téléchargez la dernière version à partir de: https://git-scm.com/downloads
2. Exécutez le programme d'installation:
   • Choisissez "Use Git from the Windows Command Prompt" (Utiliser Git à partir de l'invite de commande Windows).
   • Conservez les paramètres par défaut et terminez l'installation.
3. Vérifiez l'installation:

git --version

macOS

1. Ouvrez le terminal et exécutez:

git --version

Si Git n'est pas installé, macOS vous demandera d'installer les outils de ligne de commande Suivez les instructions.

3. Installation de Docker

Docker est indispensable pour exécuter InterSystems IRIS for Health Community.

Windows

1.    Téléchargez Docker Desktop à partir de: https://www.docker.com/products/docker-desktop
2.    Exécutez le programme d'installation et suivez les instructions.
3.    Redémarrez votre ordinateur après l'installation.
4.    Activez WSL 2 Backend (si cela vous est demandé).
5.    Verifiez l'installation

À remarquer: L'installation de Docker nécessite des privilèges d'administrateur sur votre machine et au moins un redémarrage.

macOS

1.    Téléchargez Docker Desktop pour Mac à partir de: https://www.docker.com/products/docker-desktop
2.    Installez-le en glissant Docker.app dans le dossier Applications.
3.    Ouvrez Docker à partir du menu Applications.

Pour vous assurer que le moteur Docker Desktop fonctionne sous Windows ou macOS, procédez comme suit:

Démarrez Docker Desktop

Windows: Ouvrez Docker Desktop à partir du menu Start. L'icône Docker en forme de baleine devrait apparaître dans votre barre d'état système.

Mac: Lancez Docker Desktop à partir du dossier Applications. Une fois l'application lancée, l'icône Docker en forme de baleine apparaîtra dans la barre de menu.

Attendez l'initialisation

Une fois que vous avez lancé Docker Desktop, le moteur peut prendre un certain temps à démarrer. Recherchez un message d'état indiquant que Docker est "running" (en cours d'exécution) ou "started" (démarré).

Vérifiez via le terminal/Command Prompt:

Ouvrez le terminal (ou Command Prompt/PowerShell pour Windows) et exécutez:

docker --version

ou

docker info

Dépannage

Si le moteur ne fonctionne pas, essayez de redémarrer Docker Desktop ou vérifiez s'il y a des messages d'erreur dans l'interface utilisateur de Docker Desktop. Assurez-vous également que votre système répond aux exigences de Docker Desktop. Vous pouvez voir des messages d'erreur confus faisant référence à des pipes si vous essayez de créer une image Docker sans que Docker Desktop soit en cours d'exécution.

4. Création de l'image IRIS for Health et son exécution à l'aide de Docker

Avant de pouvoir démarrer un conteneur Docker exécutant IRIS for Health Community (qui comprend notre serveur FHIR), nous devons le créer.

1. Clonez le référentiel FHIR dans un répertoire approprié de votre système de fichiers. Ouvrez un terminal dans VS Code et clonez ce référentiel à l'aide de la commande suivante:

   git clone https://github.com/pjamiesointersystems/Dockerfhir.git

    
2. Accédez à ce répertoire et ouvrez le dossier dans VS Code. Suivez les instructions du fichier readme pour créer et exécuter le conteneur. Une étape essentielle consiste à vous assurer que le référentiel de base est disponible dans votre magasin Docker. Vous pouvez le faire à l'aide de la commande dans le terminal VS Code:

   docker pull containers.intersystems.com/intersystems/irishealth-community:latest-em

   Vous devriez recevoir une confirmation après quelques minutes.
3. Accédez au répertoire dans VS Code où se trouve le fichier docker-compose.yaml, puis exécutez la commande suivante:

   docker-compose build 

   Cela lancera le processus de compilation, qui peut prendre jusqu'à 10 minutes, au cours desquelles un référentiel FHIR complet sera créé et chargé avec un échantillon de patients. 
4. Une fois le processus de compilation terminé, lancez le conteneur à l'aide de la commande suivante:

   docker-compose up -d

   suivi par

   docker ps

   Vous devriez voir un conteneur nommé **iris-fhir** en cours d'exécution. Si le conteneur ne démarre pas, vérifiez les journaux:

   docker logs iris-fhir

    

5. Installation de l'extension VS Code REST Client

Cette extension vous permet d'envoyer des requêtes API FHIR depuis VS Code.

1. Ouvrez VS Code.
2. Accédez aux extensions (Ctrl + Shift + X or Cmd + Shift + X on macOS).
3. Recherchez "REST Client". Il existe plusieurs clients REST, veuillez installer celui-ci:
4. Clickez le bouton "Install".

6. Installation de Python

Python est indispensable pour les tâches de programmation liées à FHIR.

Windows

1.    Télécharger Python à partir de: https://www.python.org/downloads/
2.    Exécutez le programme d'installation et cochez la case "Add to PATH" (Ajouter au chemin). Vous aurez besoin d'informations d'identification administratives pour apporter des modifications au chemin d'accès
3.    Terminez l'installation.
4.    Verifiez l'installation:

python --version

macOS

1. Ouvrez le Terminal et installez Python via Homebrew:

   Brew install python

   Si vous n'avez pas d'Homebrew, installez-le d'abord:

   /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

    
2. Verifiez l'installation:

python3 --version

7. Installation des blocs-notes Jupyter

Les notebooks Jupyter sont utilisés pour l'IA et le FHIR, ainsi que pour les tâches  FHIR SQL.

Windows & macOS

1. Ouvrez le terminal (Command Prompt, PowerShell, ou macOS Terminal).
2. Installez Jupyter à l'aide de pip:

   pip install jupyter
   jupyter --version

    
3. Exécutez le bloc-note Jupyter:

jupyter notebook

Jupyter s'ouvrira alors dans votre navigateur web.

8.  Validation

Exécutez votre conteneur en accédant à votre fichier Docker Compose dans le shell. Exécutez la commande 

docker compose up -d
docker ps

Accédez au Portail de gestion d'IRIS:

• Ouvrez votre navigateur et accédez à: http://localhost:8080/csp/sys/UtilHome.csp
• Informations d'identification par défaut:

Nom d'utilisateur: _SYSTEM
Mot de passe: ISCDEMO

Accédez à l'API FHIR

• Ouvrez votre navigateur et accédez à: http://localhost:8080/csp/healthshare/demo/fhir/r4/metadata

Dernières vérifications

Exécutez les commandes suivantes pour vérifier toutes les installations:

code --version       # VS Code
git --version        # Git
docker --version     # Docker
python --version     # Python
jupyter --version    # Jupyter

Si tout fonctionne, vous avez installé correctement tous les logiciels ci-dessus.

Dépannage

Merci de votre aide. J'attends vos commentaires avec impatience!

Après avoir déployé un nouveau conteneur basé sur containers.intersystems.com/intersystems/irishealth:2023.1 cette semaine, nous avons soudainement constaté que notre dépôt FHIR affichait une erreur 500. Ce problème est dû à des violations de PROTECT sur le nouvel espace de noms et la nouvelle base de données HSSYSLOCALTEMP utilisés par cette version des composants FHIR d'IRIS for Health. Pour résoudre ce problème, ajoutez « %DB_HSSYSLOCALTEMP » aux applications Web qui gèrent les requêtes FHIR. Vous pouvez créer un script pour cela en exécutant la méthode de classe suivante dans les espaces de noms qui définissent ces applications Web

do ##class(HS.HealthConnect.FHIRServer.Upgrade.MethodsV6).AddLOCALTEMPRoleToCSP()

Dans notre cas, cela n'était pas suffisant. Dans certains de nos codes personnalisés, nous avions besoin d'accéder au jeton porteur JWT envoyé par le client. Nous pouvions le récupérer depuis l'élément AdditionalInfo « USER:OAuthToken », qui n'est plus présent dans la version 2023.6.1.809, comme décrit dans https://docs.intersystems.com/upgrade/results?product=ifh&amp;versionFrom=2023.1.0&amp;versionTo=2023.1.6&amp;categories=Business%20Intelligence,Cloud,Core,Development%20Tools,Driver%20Technologies,Embedded%20Python,External%20Languages,FHIR,Healthcare%20Interoperability,Interoperability,Machine%20Learning,Mirroring,Monitoring,Natural%20Language%20Processing,SQL,Security,Sharding,Web%20Applications&amp;audience=All&amp;changes=121 Nous avons contourné ce problème en ajoutant la logique suivante pour récupérer le jeton depuis le cache de jetons :

$$$ThrowOnError(##class(HS.HC.Util.InfoCache).GetTokenInfo(pInteropRequest.Request.AdditionalInfo.GetAt("USER:TokenId"), .pTokenInfo)) set OAuthToken = pTokenInfo("token_string")

Bonjour à tous et a toutes,

Nous sommes heureux d'annoncer le nouveau concours de programmation InterSystems dédié à la santé :

🏆 Concours d'interopérabilité InterSystems FHIR et santé numérique 🏆

Durée : du 12 mai au 1er juin 2025

Prix : 12 000 $

Salut la Communauté !

Nous sommes ravis d'annoncer que le Meetup FHIR France fait son grand retour… en présentiel à l’occasion de SantExpo 2025 ! 

📅 Dates: 21 mai, 2025, à partir de 19h00

📌 Lieu : Halles d'Issy - Biltoki, 1 Rue Rouget de Lisle, Issy-les-Moulineaux

Les référentiels, applications et serveurs FHIR servent généralement des données cliniques en petites quantités, par exemple pour renvoyer des données sur un patient, ses médicaments, ses vaccins, ses allergies, ou d'autres renseignements. Cependant, il est courant qu'une grande quantité de données au format FHIR/JSON soit demandée pour être utilisée pour charger des Data Lakes, identifier des cohortes étudiées, la santé de la population ou transférer des données d'un DME (dossier médical électronique) à un autre. Pour répondre à ces scénarios d'activités commerciales qui nécessitent d'importantes extractions et charges de données, il est recommandé d'utiliser la fonctionnalité d'accès aux données en masse FHIR fournie par l'institution HL7.

InterSystems IRIS for Health met en œuvre l' ccès aux données de masse FHIR (FHIR Bulk Data Access) avec la fonctionnalité BFC - Bulk FHIR Coordinator (https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI.Page.cls?KEY=HXFHIR_bulk). Selon la documentation d'InterSystems, le BFC « simplifie l'interaction des données de masse FHIR pour les clients et, pour ne pas surcharger un serveur FHIR avec des demandes de données de masse, le Bulk FHIR Coordinator (BFC) d'InterSystems sert d'intermédiaire dans l'interaction entre un client de données de masse et un point d'extrémité de serveur de ressources FHIR pour les demandes de données de masse. Le Bulk FHIR Coordinator peut faciliter l'exportation de données de masse FHIR pour les serveurs de ressources FHIR qui ne prennent pas en charge nativement l'interaction de données de masse". Le diagramme de la documentation illustre comment le coordinateur FHIR en bloc sert d'intermédiaire dans l'interaction entre un client et les endpoints FHIR:

Ainsi, si vous souhaitez migrer d'un serveur FHIR vers IRIS for Health, vous pouvez utiliser BFC pour vous connecter à un serveur FHIR cible afin d'obtenir toutes les données dont vous avez besoin sous forme de fichiers json (ressources ndjson), et les importer dans votre serveur FHIR InterSystems.

Dans cet article, vous découvrirez étape par étape les différentes manières de configurer et d'utiliser BFC pour obtenir toutes les données patient d'un référentiel FHIR dans des fichiers JSON en vue d'une utilisation ultérieure.

Étape 1 - Obtenir/configurer une instance IRIS for Health pour utiliser BFC

Si vous n'avez pas d'instance IRIS for Health, cliquez sur le lien suivant pour en obtenir une: https://openexchange.intersystems.com/package/iris-fhir-template. Suivez les procédures d'installation suivantes:

1.1 Installation de Docker:

Clone/git extrait le référentiel dans n'importe quel répertoire local

git clone https://github.com/intersystems-community/iris-fhir-template.git

Ouvrez le terminal dans ce répertoire et lancez:

docker-compose up -d

1.2 Ou installation de l'IPM (nécessite un IRIS for Health en cours d'exécution):

Ouvrez l'installation d'IRIS for Health avec le client IPM installé. Appel dans n'importe quel espace de nom:

USER>zpm "install fhir-server"

Ainsi, le serveur FHIR sera installé dans l'espace de noms FHIRSERVER.

Ou encore, pour une installation programmée, on peut appeler ce qui suit:

set sc=$zpm("install fhir-server")

Étape 2 - Création d'un nouveau justificatif d'identité

1. Access the Management Portal for the namespace FHIRSERVER (http://localhost:32783/csp/sys/%25CSP.Portal.Home.zen?$NAMESPACE=FHIRSERVER).

2. Accédez à l'Interopérabilité > Configuration > Informations d'identification:

3. Paramétrez les valeurs BulkCreds et enregistrez:

• Identifiant: BulkCreds
• Nom d'utilisateur: _SYSTEM
• Mot de passe: SYS

Étape 3 - Configuration du BFC (Bulk Data Coordinator)

1. Accédez à BFC UI (http://localhost:32783/csp/healthshare/fhirserver/bulkfhir/index.html):

2. Appuyez sur le bouton + Nouvelle configuration > Création d'une nouvelle:

3. Configuration des paramètres:

• Nom: BFC_Patients
• Endpoint BFC (tout chemin relatif): /bulkfhir/patients
• Gardez tous les autres paramètres tels quels

4. Appuyez sur le bouton Next.

5. Selectionnez HS.BulkFHIR.Auth.BasicAuth.Adapter et appuyez sur le bouton Next

6. Selectionnez HS.BulkFHIR.Fetch.PureFHIR.Adapter pour le champ Fetch Adapter et définissez les valeurs suivantes:

• URL de l'endpoint: http://fhir-template:52773/fhir/r4
• Configuration SSL: BFC_SSL
• Type d'autorisation: HTTP
• Identifiant HTTP: BulkCreds
• Acceptez les valeurs par défaut pour tous les autres champs

7. Appuyez sur le bouton Next.

8. Selectionnez la valeur de HS.BulkFHIR.Storage.File.Adapter pour le champ Storage Adapter et définissez les valeurs suivantes:

• Storage Adapter: HS.BulkFHIR.Storage.File.Adapter
• URL du fichier: /bulkfhir/file
• Répertoire: /usr/irissys/mgr/Temp/BulkFHIR/FHIRSERVER/

9. Appuyez sur le bouton Next.

10. Vérifiez la configuration et cliquez sur le bouton de configuration "Configure" en bas de la page:

11. Vous verrez le message de réussite: 

Étape 4 (étape finale) - Récupération de vos données de masse

1. Accéder à Exportations (Exports):

2. Appuyez sur le bouton + Nouvelle demande d'exportation:

3. Sélectionnez la valeur du champ de configuration BFC_Patients et appuyez sur le bouton Next

4. Sélectionnez l'option Patient et appuyez sur le bouton Export Now (Exportation immédiate):

5. Vous verrez le message de réussite:

6. Appuyez sur le bouton d'actualisation "Refresh" en haut de la page:

7. Consultez la session de configuration BFC_Patients terminée:

8. Appuyez sur le dernier bouton de téléchargement "Download" ():

9. Consultez la liste des fichiers json exportés:

10. Téléchargez n'importe quel fichier et consultez son contenu:

11. Pour lancer une exportation FHIR en masse à partir d'un client REST, envoyez une requête GET à votre endpoint BFC en indiquant l'opération souhaitée, par exemple:

•     Système — GET https://bfcEndpoint/$export
•     Patient — GET https://bfcEndpoint/Patient/$export
•     Groupe — GET https://bfcEndpoint/Group/groupID/$export

12. Plus de détails sur l'utilisation via l'API: https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI.Page.cls?KEY=HXFHIR_bulk#HXFHIR_bulk_export_rest_initiate

13. Plus de détails sur l'utilisation de BFC:

• https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI.Page.cls?KEY=HXFHIR_bulk#HXFHIR_bulk_intro
• https://www.youtube.com/watch?v=J-AVP9MFMWI

Profitez-en!!

Lors de la création d'un bundle à partir de données héritées, je (et d'autres) souhaitais pouvoir contrôler si les ressources étaient générées avec une méthode de requête FHIR PUT plutôt qu'avec la méthode POST codée en dur. J'ai étendu les deux classes responsables de la transformation de SDA en FHIR dans une production d'interopérabilité afin de prendre en charge un paramètre permettant à l'utilisateur de contrôler la méthode de requête.

Bonjour collègues !

Lors du développement d'une application front-end ou de toute autre communication avec l'API REST, il est souvent judicieux d'utiliser une Swagger UI, une interface de test pour l'API REST conforme à la spécification Open API 2.0. Elle est généralement très pratique, car elle permet d'effectuer des tests manuels rapides avec l'API REST, ses réponses et les données qu'elle contient.

J'ai récemment intégré la prise en charge de Swagger dans InterSystems IRIS FHIR template pour l'API FHIR R4 :

Comment le faire fonctionner.

Introduction

Pour atteindre des performances optimisées en matière d'IA, une explicabilité robuste, une adaptabilité et une efficacité dans les solutions de santé, InterSystems IRIS sert de fondation centrale pour un projet au sein du cadre multi-agent x-rAI. Cet article offre une analyse approfondie de la manière dont InterSystems IRIS permet le développement d'une plateforme d'analyse de données de santé en temps réel, permettant des analyses avancées et des informations exploitables. La solution exploite les points forts d'InterSystems IRIS, notamment le SQL dynamique, les capacités natives de recherche vectorielle, la mise en cache distribuée (ECP) et l'interopérabilité FHIR. Cette approche innovante s'aligne directement sur les thèmes du concours « Utilisation du SQL dynamique et SQL intégré », « GenAI, recherche vectorielle » et « FHIR, DME », démontrant une application pratique d'InterSystems IRIS dans un contexte critique de santé.

Architecture du système

L'Agent Santé dans x-rAI repose sur une architecture modulaire intégrant plusieurs composants :

Couche d'ingestion des données : Récupère les données de santé en temps réel à partir de dispositifs portables via l'API Terra.

Couche de stockage des données : Utilise InterSystems IRIS pour stocker et gérer les données de santé structurées.

Moteur analytique : Exploite les capacités de recherche vectorielle d'InterSystems IRIS pour l'analyse de similarité et la génération d'informations.

Couche de mise en cache : Implémente la mise en cache distribuée via le protocole Enterprise Cache Protocol (ECP) d'InterSystems IRIS pour améliorer l'évolutivité.

Couche d'interopérabilité : Utilise les normes FHIR pour s'intégrer aux systèmes externes de santé comme les DME.

Voici un diagramme d'architecture à haut niveau :

text [Dispositifs portables] --> [API Terra] --> [Ingestion des données] --> [InterSystems IRIS] --> [Moteur analytique] ------[Couche de mise en cache]------ ----[Intégration FHIR]----- Mise en œuvre technique

1. Intégration des données en temps réel avec SQL dynamique

L'Agent Santé ingère des métriques de santé en temps réel (par exemple, fréquence cardiaque, pas effectués, heures de sommeil) depuis des dispositifs portables via l'API Terra. Ces données sont stockées dans InterSystems IRIS à l'aide du SQL dynamique pour une flexibilité dans la génération des requêtes.

Implémentation du SQL dynamique

Le SQL dynamique permet au système de construire adaptativement des requêtes basées sur les structures des données entrantes.

text def index_health_data_to_iris(data): conn = iris_connect() if conn is None: raise ConnectionError("Échec de la connexion à InterSystems IRIS.") try: with conn.cursor() as cursor: query = """ INSERT INTO HealthData (user_id, heart_rate, steps, sleep_hours) VALUES (?, ?, ?, ?) """ cursor.execute(query, ( data['user_id'], data['heart_rate'], data['steps'], data['sleep_hours'] )) conn.commit() print("Données indexées avec succès dans IRIS.") except Exception as e: print(f"Erreur lors de l'indexation des données : {e}") finally: conn.close() Avantages du SQL dynamique

Permet une construction flexible des requêtes basée sur les schémas des données entrantes.

Réduit la charge de développement en évitant les requêtes codées en dur.

Facilite l'intégration transparente de nouvelles métriques sans modifier le schéma de la base.

2. Analytique avancée avec recherche vectorielle

Le type natif vector et les fonctions de similarité d'InterSystems IRIS ont été utilisés pour effectuer une recherche vectorielle sur les données de santé. Cela permet au système d’identifier les dossiers historiques similaires aux métriques actuelles d’un utilisateur.

Flux de travail pour la recherche vectorielle

Convertir les métriques de santé (par exemple, fréquence cardiaque, pas effectués, heures de sommeil) en une représentation vectorielle.

Stocker ces vecteurs dans une colonne dédiée dans la table HealthData.

Effectuer des recherches basées sur la similarité à l'aide de VECTOR_SIMILARITY().

Requête SQL pour la recherche vectorielle

text SELECT TOP 3 user_id, heart_rate, steps, sleep_hours, VECTOR_SIMILARITY(vec_data, ?) AS similarity FROM HealthData ORDER BY similarity DESC; Intégration Python

text def iris_vector_search(query_vector): conn = iris_connect() if conn is None: raise ConnectionError("Échec de la connexion à InterSystems IRIS.") try: with conn.cursor() as cursor: query_vector_str = ",".join(map(str, query_vector)) sql = """ SELECT TOP 3 user_id, heart_rate, steps, sleep_hours, VECTOR_SIMILARITY(vec_data, ?) AS similarity FROM HealthData ORDER BY similarity DESC; """ cursor.execute(sql, (query_vector_str,)) results = cursor.fetchall() return results except Exception as e: print(f"Erreur lors de la recherche vectorielle : {e}") return [] finally: conn.close() Avantages de la recherche vectorielle

Permet des recommandations personnalisées grâce à l’identification des tendances historiques.

Améliore l’explicabilité en reliant les métriques actuelles à des cas passés similaires.

Optimisé pour des analyses rapides grâce aux opérations SIMD (Single Instruction Multiple Data).

3. Mise en cache distribuée pour l’évolutivité

Pour gérer efficacement le volume croissant des données, l’Agent Santé utilise le protocole Enterprise Cache Protocol (ECP) d’InterSystems IRIS. Ce mécanisme réduit la latence et améliore l’évolutivité.

Caractéristiques clés

Mise en cache locale sur les serveurs applicatifs pour minimiser les requêtes vers la base centrale.

Synchronisation automatique garantissant la cohérence entre tous les nœuds du cache.

Évolutivité horizontale permettant l’ajout dynamique de serveurs applicatifs.

Avantages du caching

Réduction des temps de réponse grâce à la mise en cache locale.

Amélioration de l’évolutivité grâce à la répartition des charges entre plusieurs nœuds.

Réduction des coûts d’infrastructure grâce à une moindre sollicitation du serveur central.

4. Intégration FHIR pour l’interopérabilité

Le support d’InterSystems IRIS pour FHIR (Fast Healthcare Interoperability Resources) garantit une intégration fluide avec les systèmes externes comme les DME.

Flux FHIR

Les données issues des dispositifs portables sont transformées en ressources compatibles FHIR (par exemple Observation, Patient).

Ces ressources sont stockées dans InterSystems IRIS et accessibles via des API RESTful.

Les systèmes externes peuvent interroger ou mettre à jour ces ressources via des points d’accès standard FHIR.

Avantages

Assure la conformité avec les normes d’interopérabilité en santé.

Facilite un échange sécurisé des données entre systèmes.

Permet une intégration avec les flux et applications existants dans le domaine médical.

IA explicable grâce aux informations en temps réel

En combinant les capacités analytiques d’InterSystems IRIS avec le cadre multi-agent x-rAI, l’Agent Santé génère des informations exploitables et explicables. Par exemple :

« L’utilisateur 123 avait des métriques similaires (Fréquence cardiaque : 70 bpm ; Pas : 9 800 ; Sommeil : 7 h). Sur la base des tendances historiques, il est recommandé de maintenir vos niveaux actuels d’activité. »

Cette transparence renforce la confiance dans les applications IA dédiées à la santé en offrant un raisonnement clair derrière chaque recommandation.

Conclusion

L’intégration d’InterSystems IRIS dans l’Agent Santé du cadre x-rAI illustre son potentiel comme plateforme robuste pour construire des systèmes IA intelligents et explicables dans le domaine médical. En exploitant le SQL dynamique, la recherche vectorielle, la mise en cache distribuée et l’interopérabilité FHIR, ce projet fournit des informations exploitables et transparentes—ouvrant ainsi la voie à des applications IA plus fiables dans des domaines critiques comme celui de la santé.

Il y a environ un mois, j'ai commencé à travailler sur l'utilisation du logiciel Epic on FHIR.

Création d'une paires de clés publiques-privées

mkdir /home/ec2-user/path_to_key
openssl genrsa -out ./path_to_key/privatekey.pem 2048

Pour les applications back-end, vous pouvez exporter la clé publique vers un certificat X.509 encodé en base64 intitulé publickey509.pem à l'aide de la commande ci-dessous...

openssl req -new -x509 -key ./path_to_key/privatekey.pem -out ./path_to_key/publickey509.pem -subj '/CN=medbank'

où '/CN=medbank' est le nom du sujet (par exemple le nom de l'application) pour lequel la paire de clés est utilisée. Le nom du sujet n'a pas d'impact fonctionnel dans ce cas, mais il est nécessaire pour créer un certificat X.509.

Le logiciel Epic on FHIR est une ressource gratuite pour les développeurs qui créent des applications

J'ai enregistré mon application "medbank" afin d'obtenir un identifiant client J'ai supprimé les identifiants client et modifié l'URL du jeu JWK hors production (Non-Production JWK Set URL) afin de protéger l'adresse IP réelle.

La documentation d'Epic indique que votre application effectue une requête HTTP POST au point de terminaison OAuth 2.0 du serveur d'autorisation pour obtenir un jeton d'accès. J'ai essayé d'écrire du code, mais je n'ai jamais réussi à obtenir un jeton d'accès.

J'ai appelé le WRC InterSystems pour obtenir de l'aide.

Nous avons configuré un client OAuth2 en utilisant le type de certificat "JWT Authorization" et la "private key JWT" pour l'authentification.

Nous avons ensuite essayé de l'exécuter sur le terminal en utilisant IsAuthorized() et GetAccessTokenJWT(), mais la réponse a été "invalid client ID".

Quelques jours plus tard, nous avons vu que le grant_type était en fait supposé être client_credentials, nous avons donc changé pour utiliser cela en passant de GetAccessTokenJWT() à GetAccessTokenClient() et cela a fonctionné.

Je souhaiterais mettre en œuvre Epic sur FHIR en tant que cas d'utilisation pour les iris-http-calls

J'ai utilisé Docker pour déployer les iris-http-calls dans AWS.

sudo docker build --no-cache --progress=plain . -t oliverwilms/iris-http-calls 2>&1 | tee build.log
sudo docker run -d -p57700:52773 oliverwilms/iris-http-calls

J'ai copié des fichiers de clés privées et publiques avec un accès en lecture pour IRIS

chmod 644 privatekey.pem
sudo docker cp ./privatekey.pem container_name:/home/irisowner/dev/ 
sudo docker cp ./publickey509.pem container_name:/home/irisowner/dev/
chmod 600 privatekey.pem

J'ai créé des informations d'identification X509 dans IRIS

Set oX509Credentials = ##class(%SYS.X509Credentials).%New()
Set oX509Credentials.Alias = "medbank"
Set tSC = oX509Credentials.LoadCertificate("/home/irisowner/dev/publickey509.pem")
Do $System.Status.DisplayError(tSC)
Set tSC = oX509Credentials.LoadPrivateKey("/home/irisowner/dev/privatekey.pem")
Do $System.Status.DisplayError(tSC)
Set tSC = oX509Credentials.%Save()
Do $System.Status.DisplayError(tSC)

Configuration d'un client OAuth2

http://localhost:57700/csp/sys/sec/%25CSP.UI.Portal.OAuth2.Client.ServerList.zen

Cliquez sur Create Server Description (Créer une description de serveur)

Création de la description du serveur

https://fhir.epic.com/interconnect-fhir-oauth/oauth2

J'ai cliqué sur Annuler (Cancel) et je suis retourné à

http://localhost:57700/csp/sys/sec/%25CSP.UI.Portal.OAuth2.Client.ServerList.zen

Cliquez sur le lien Client Configurations (configuration des clients).

Création de la configuration des clients

Cliquez sur Create Client Configuration (Créer une configuration des clients)

Sous l'onglet General, indiquez le nom de l'application:

medbank

Choisissez le type de client: Confidential

Choisissez la configuration SSL

Sous l'URL de redirection du client, indiquez le nom de l'hôte

localhost

Port

57700

Décochez la case Use TLS/SSL

Sous Types de certificats requis, cochez la case d'informations d'identification du client "Client Credentials"

Sous Type d'authentification, choisissez clé privée JWT

Sous Algorithme de signature d'authentification, choisissez RS384

Remplissez le champ Audience

https://fhir.epic.com/interconnect-fhir-oauth/oauth2/token

Sous l'onglet JWT Settings (Paramètres JWT), cochez la case Create JWT Settings (Créer des paramètres JWT) à partir d'informations d'identification X509. Choisissez vos informations d'identification dans la liste déroulante. Dans la colonne de signature Signing de la ligne des algorithmes de jetons d'accès, choisissez RS384.

Sous l'onglet Client Credentials (Informations d'identification du client), j'ai copié l'identifiant client hors production que j'avais reçu du logiciel Epic on FHIR. Le code secret client est requis. Je l'ai rempli comme x.

Important: N'oubliez pas de cliquer sur Save (Enregistrer)

InterSystems IRIS for Health v2024.3 est déjà disponible en tant qu'aperçu pour les développeurs depuis un certain temps, et je voulais souligner la nouvelle prise en charge liée à la recherche FHIR qui a été introduite.

Il existe deux modificateurs dont la prise en charge a été ajoutée :

• not
• missing

Salut les Développeurs !

Nous avons le plaisir de vous inviter à participer au Hospitals on FHIR User Day, un événement passionnant dédié à l'interopérabilité des systèmes de santé.

📅 Dates: 25 - 26 novembre, 2024

📌 Lieu : Bluepoint Conference Centre Brussels, Blvd Auguste Reyers 80, 1030 Brussels

Cela fait maintenant plus de 2 ans que j'utilise quotidiennement Embedded Python. Il est peut-être temps de partager un retour d'expérience sur ce parcours.

Pourquoi écrire ce commentaire de retour d'expérience? Parce que, je suppose, je suis comme la plupart de mes collègues ici, un développeur ObjectScript, et je pense que la communauté bénéficierait de ce retour d'expérience et pourrait mieux comprendre les avantages et les inconvénients du choix de Embedded Python pour développer quelque chose dans IRIS. Et aussi éviter certains pièges.

• Commentaire de retour d'expérience : Utilisation quotidienne de Embedded Python pendant 2 ans](#feedback--using-embedded-python-daily-for-2-years)
• Introduction
• Débuter avec Python
  • Python n'est pas ObjectScript
    • Pep8
    • Modules
    • Dunders
  • Conclusion
• Embedded Python
  • Qu'est-ce que Embedded Python ?
  • Comment utiliser Embedded Python ?
  • Comment j'utilise Embedded Python
    • Utilisation des bibliothèques et le code Python comme s'il s'agissait de classes ObjectScript
      • Avec la balise de langue
      • Sans de balise de langue
      • Conclusion
    • Utilisation d'une première approche en python
      • Exemple : iris-fhir-python-strategy
      • Remarques(#remarks)
      • Où trouver le code
        • Comment mettre en œuvre une Stratégie
        • Mise en œuvre d'InteractionsStrategy
        • Mise en œuvre des Interactions
        • Interactions en Python
        • IMise en œuvre de la classe abstraite python
      • Trop long, faisons un résumé

Introduction

Je suis développeur depuis 2010, et j'ai travaillé avec ObjectScript depuis 2013.

Donc, c'est à peu près 10 ans d'expérience avec ObjectScript.

Depuis 2021, et la sortie de Embedded Python dans IRIS, je me suis lancé un défi :

• Apprendre Python
• Faire autant que possible tout ce qui est en Python.

Quand j'ai commencé ce parcours, je n'avais aucune idée de ce qu'était Python. J'ai donc commencé par les bases, et je continue d'apprendre chaque jour.

Débuter avec Python

L'avantage de Python est sa facilité d'apprentissage. C'est encore plus facile quand on connaît déjà ObjectScript.

Pourquoi ? Ils ont beaucoup de choses en commun.

Donc, si vous connaissez ObjectScript, vous en savez déjà beaucoup sur Python.

Mais il y a quelques différences, et certaines d'entre elles ne sont pas faciles à comprendre.

Python n'est pas ObjectScript

Mais il y a quelques différences, et certaines d'entre elles ne sont pas faciles à comprendre.

Pour moi il y a principalement 3 différences :

• Pep8
• Modules
• Dunders

Pep8

Mais qu'est-ce que Pep8 ?

Il s'agit d'un ensemble de règles pour écrire du code Python.

pep8.org

Quelques-unes d'entre elles sont :

• convention de nommage
• noms de variables
  • snake_case
• noms de classes
  • CamelCase
• indentation
• longueur de ligne
• etc.

Pourquoi est-ce important ?

Parce que c'est la façon d'écrire du code Python. Et si vous ne suivez pas ces règles, vous aurez du mal à lire le code écrit par d'autres personnes, et elles auront du mal à lire le vôtre.

En tant que développeurs ObjectScript, nous avons aussi quelques règles à suivre, mais elles ne sont pas aussi strictes que Pep8.

J'ai appris Pep8 à la dure.

Je voudrais vous raconter petite histoire, je suis ingénieur commercial chez InterSystems et je fais beaucoup de démonstrations. Et un jour, que je faisais une démo de Embedded Python à un client, et ce client était un développeur Python, la conversation a tourné court lorsqu'il a vu mon code. Il m'a dit que mon code n'était pas du tout Python (il avait raison), je codais en Python comme je codais en ObjectScript. Et à cause de cela, il m'a dit qu'il n'était plus intéressé par Embedded Python. J'ai été choqué, et j'ai décidé d'apprendre Python de la bonne manière.

Donc, si vous voulez apprendre Python, apprenez d'abord Pep8.

Modules

Les modules sont quelque chose que nous n'avons pas en ObjectScript.

Habituellement, dans les langages orientés objet, vous avez des classes et des paquetages. En Python, vous avez des classes, des paquetages et des modules.

Qu'est-ce qu'un module ?

C'est un fichier avec une extension .py. Et c'est la façon d'organiser votre code.

Vous n'avez pas compris? Moi non plus au début. Prenons un exemple.

Habituellement, quand on veut créer une classe en ObjectScript, on crée un fichier .cls, et on y met sa classe. Et si vous voulez créer une autre classe, vous créez un autre fichier .cls. Et si vous voulez créer un paquetage, vous créez un dossier et vous y placez vos fichiers .cls.

En Python, c'est la même chose, mais Python apporte la possibilité d'avoir plusieurs classes dans un seul fichier. Ce fichier s'appelle un module. Pour information, c'est Pythonic quand il y a plusieurs classes dans un seul fichier.

Prévoyez donc comment vous allez organiser votre code, et comment vous allez nommer vos modules pour ne pas vous retrouver comme moi avec un tas de modules portant le même nom que vos classes.

Un mauvais exemple :

MyClass.py

class MyClass:
    def __init__(self):
        pass

    def my_method(self):
        pass

Pour instancier cette classe, vous allez faire :

import MyClass.MyClass # weird right ?

my_class = MyClass()

Bizarre, hein ?

Dunders

Les dunders sont des méthodes spéciales en Python. Elles sont appelées dunder parce qu'elles commencent et se terminent par un double soulignement.

Ce sont en quelque sorte nos méthodes % en ObjectScript.

Elles sont utilisées pour ce qui suit :

• constructeur
• surcharge d'opérateur
• représentation d'objet
• etc.

Exemple :

class MyClass:
    def __init__(self):
        pass

    def __repr__(self):
        return "MyClass"

    def __add__(self, other):
        return self + other

Ici, nous avons 3 méthodes de dunder :

• __init__ : constructeur
• __repr__ : représentation d'objet
• __add__ : surcharge d'opérateur

Les méthodes Dunders sont partout en Python. C'est une partie importante de la langue, mais ne vous inquiétez pas, vous les apprendrez rapidement.

Conclusion

Python n'est pas ObjectScript, et vous devrez l'apprendre. Mais ce n'est pas si difficile, et vous l'apprendrez rapidement. Gardez simplement à l'esprit qu'il vous faudra apprendre Pep8, et comment organiser votre code avec des modules et des méthodes dunder.

De bons sites pour apprendre Python :

• geeksforgeeks.org
• w3schools.com
• realpython.com

Embedded Python

Maintenant que vous en savez un peu plus sur Python, parlons de Embedded Python.

Qu'est-ce que Embedded Python ?

Embedded Python est un moyen d'exécuter du code Python dans IRIS. C'est une nouvelle fonctionnalité d' IRIS 2021.2+. Cela signifie que votre code Python sera exécuté dans le même processus qu'IRIS. Par ailleurs, chaque classe ObjectScript est une classe Python, de même pour les méthodes et les attributs et vice versa. 🥳 C'est génial !

Comment utiliser Embedded Python ?

Il y a 3 façons principales d'utiliser Embedded Python :

• Utilisation la balise de langue dans ObjectScript
  • Méthode Foo() As %String [ Language = python ]
• Utilisation de la fonction ##class(%SYS.Python).Import()
• Utilisation de l'interpréteur python
  • python3 -c "import iris; print(iris.system.Version.GetVersion())"

Mais si vous voulez vous intéresser sérieusement à Embedded Python, vous aurez à éviter d'utiliser la balise de langue.

Pourquoi ?

• Parce que ce n'est pas Pythonic
• Parce que ce n'est pas ObjectScript non plus
• Parce que vous n'avez pas de débogueur
• Parce que vous n'avez pas de linter
• Parce que vous n'avez pas de formateur
• Parce que vous n'avez pas de cadre de test
• Parce que vous n'avez pas de gestionnaire de paquets
• Parce que vous mélangez 2 langues dans le même fichier
• Parce que lorsque votre processus plante, vous n'avez pas de trace de pile
• Parce que vous ne pouvez pas utiliser d'environnements virtuels ou d'environnements conda
• ...

Ne vous méprenez pas, ça marche, ça peut être utile, si vous voulez tester quelque chose rapidement, mais à mon avis, ce n'est pas une bonne pratique.

Alors, qu'est-ce que j'ai appris de ces 2 années de Embedded Python, et comment l'utiliser de la bonne manière ?

Comment j'utilise Embedded Python

Je crois que vous avez deux options :

• Utiliser les bibliothèques Python comme s'il s'agissait de classes ObjectScript
  • withqvec ##class(%SYS.Python).Import() function
• Utiliser une première approche en python

Utilisation des bibliothèques et le code Python comme s'il s'agissait de classes ObjectScript

Vous voulez toujours utiliser Python dans votre code ObjectScript, mais vous ne voulez pas utiliser la balise de langue. Alors, que pouvez-vous faire ?

"Tout simplement" utilisez les bibliothèques et le code Python comme s'il s'agissait de classes ObjectScript. Prenons un exemplee :

Vous voulez utiliser la bibliothèque 'requests' ( c'est une bibliothèque pour faire des requêtes HTTP ) dans votre code ObjectScript.

Avec la balise de langue

ClassMethod Get() As %Status [ Language = python ]
{
	import requests

	url = "https://httpbin.org/get"
	# faire une requête d'obtention
	response = requests.get(url)
	# récupérer les données json de la réponse
	data = response.json()
	# itérer sur les données et imprimer les paires clé-valeur
	for key, value in data.items():
		print(key, ":", value)
}

Pourquoi je pense que ce n'est pas une bonne idée ?

Parce que vous mélangez 2 langues dans le même fichier, et que vous n'avez pas de débogueur, de linter, de formateur, etc. Si ce code plante, vous aurez du mal à le déboguer. Vous n'avez pas de trace de pile, et vous ne savez pas d'où vient l'erreur. Et vous n'avez pas d'auto-complétion.

Sans de balise de langue

ClassMethod Get() As %Status
{
	set status = $$$OK
    set url = "https://httpbin.org/get"
    // Importation du module Python "requests" en tant que classe ObjectScript
    set request = ##class(%SYS.Python).Import("requests")
    // Appel de la méthode get de la classe de requête
    set response = request.get(url)
    // Appel de la méthode json de la classe de réponse
	set data = response.json()
    // Ici, les données sont un dictionnaire Python
    // Pour parcourir un dictionnaire Python, vous devez utiliser la méthode dunder et items()
	// Importation du module Embedded Python
	set builtins = ##class(%SYS.Python).Import("builtins")
    // Ici, nous utilisons len du module intégré pour obtenir la longueur du dictionnaire
    For i = 0:1:builtins.len(data)-1 {
        // Maintenant, nous convertissons les éléments du dictionnaire en une liste, et nous obtenons la clé et la valeur en utilisant la méthode dunder __getitem__
		Write builtins.list(data.items())."__getitem__"(i)."__getitem__"(0),": ",builtins.list(data.items())."__getitem__"(i)."__getitem__"(1),!
	}
	quit status
}

Pourquoi je pense que c'est une bonne idée ?

Parce que vous utilisez Python comme s'il s'agissait d'ObjectScript. Vous importez la bibliothèque de requêtes comme une classe ObjectScript et vous l'utilisez comme une classe ObjectScript. Toute la logique est en ObjectScript, et vous utilisez Python comme une bibliothèque. Même pour la maintenance, c'est plus facile à lire et à comprendre, n'importe quel développeur ObjectScript peut comprendre ce code. L'inconvénient est que vous avez à savoir comment utiliser les méthodes de duners, et comment utiliser Python comme s'il s'agissait d'ObjectScript.

Conclusion

Croyez-moi, de cette manière vous obtiendrez un code plus robuste, et vous pourrez le déboguer facilement. Au début, cela semble difficile, mais vous découvrirez les avantages de l'apprentissage de Python plus rapidement que vous ne le pensez.

Utilisation de première approche en python

C'est la façon dont je préfère utiliser Embedded Python.

J'ai construit beaucoup d'outils en utilisant cette approche, et j'en suis très satisfait.

Quelques exemples :

• iop
• iris-python-interoperability-template
• iris-imap-adapter
• iris-chemicals-properties
• rest-to-dicom
• iris-fhir-python-strategy

Qu'est-ce qu'une première approche python ?

TIl n'y a qu'une seule règle : Le code Python doit être dans des fichiers .py, le code ObjectScript doit être dans des fichiers .cls

Comment y parvenir ?

L'idée est de créer des classes de wrappers ObjectScript pour appeler le code Python.

Prenons l'exemple de iris-fhir-python-strategy :

Exemple : iris-fhir-python-strategy

Tout d'abord, nous avons à comprendre comment fonctionne le serveur IRIS FHIR.

Chaque serveur IRIS FHIR met en œuvre une Stratégie.

Une Stratégie est un ensemble de deux classes :

Ces deux classes sont des classes abstraites Abtract Abstract.

• HS.FHIRServer.API.InteractionsStrategy est une classe Abstract qui doit être mise en œuvre pour personnaliser le comportement du serveur FHIR.
• HS.FHIRServer.API.RepoManager est une classe Abstract qui doit être mise en œuvre pour personnaliser le stockage du serveur FHIR.

Remarques

Pour notre exemple, nous nous concentrerons uniquement sur la classe HS.FHIRServer.API.InteractionsStrategy même si la classe HS.FHIRServer.API.RepoManager est également implémentée et obligatoire pour personnaliser le serveur FHIR. La classe HS.FHIRServer.API.RepoManager est mise en œuvre par HS.FHIRServer.Storage.Json.RepoManager qui est la mise en œuvre par défaut du serveur FHIR.

Où trouver le code

Tout le code source peut être trouvé dans le référentiel : iris-fhir-python-strategy Le dossier src contient les dossiers suivants :

• python : contient le code python
• cls : contient le code ObjectScript utilisé pour appeler le code python

Comment mettre en œuvre une Stratégie

Dans cette démonstration de faisabilité, nous nous intéresserons uniquement à la manière d'implémenter une Strategie en Python, et non à la manière de mettre en œuvre un RepoManager.

Pour mettre en œuvre une Strategie vous devez créer au moins deux classes :

• Une classe qui hérite de la classe HS.FHIRServer.API.InteractionsStrategy
• Une classe qui hérite de la classe HS.FHIRServer.API.Interactions

Mise en œuvre d'InteractionsStrategy

La classe HS.FHIRServer.API.InteractionsStrategy vise à personnaliser le comportement du serveur FHIR en remplaçant les méthodes suivantes :

• GetMetadataResource : appelé pour récupérer les métadonnées du serveur FHIR
  • C'est la seule méthode que nous remplacerons dans cette preuve de concept

HS.FHIRServer.API.InteractionsStrategy a également deux paramètres :

• StrategyKey : un identifiant unique pour la stratégie InteractionsStrategy
• InteractionsClass : le nom de votre sous-classe Interactions

Mise en œuvre des Interactions

La classe HS.FHIRServer.API.Interactions vise à personnaliser le comportement du serveur FHIR en remplaçant les méthodes suivantes :

• OnBeforeRequest : appelée avant l'envoi de la requête au serveur
• OnAfterRequest : appelée après l'envoi de la requête au serveur
• PostProcessRead : appelée une fois l'opération de lecture terminée
• PostProcessSearch : appelée une fois l'opération de recherche terminée
• Read : appelée pour lire une ressource
• Add : appelée pour ajouter une ressource
• Update : appelée pour mettre à jour une ressource
• Delete : appelée pour supprimer une ressource
• et bien d'autres...

Nous mettons en œuvre la classe HS.FHIRServer.API.Interactions dans la classe src/cls/FHIR/Python/Interactions.cls.

Class FHIR.Python.Interactions Extends (HS.FHIRServer.Storage.Json.Interactions, FHIR.Python.Helper)
{
Parameter OAuth2TokenHandlerClass As%String = "FHIR.Python.OAuth2Token";
Method %OnNew(pStrategy As HS.FHIRServer.Storage.Json.InteractionsStrategy) As%Status
{
// %OnNew est appelé lors de la création de l'objet.// Le paramètre pStrategy est l'objet de stratégie qui a créé cet objet.// La mise en œuvre par défaut ne fait rien// D'abord, le chemin d'accès à python est défini à partir d'une variable d'environnementset..PythonPath = $system.Util.GetEnviron("INTERACTION_PATH")
// Définissez ensuite le nom de la classe python à partir de la variable d'environnementset..PythonClassname = $system.Util.GetEnviron("INTERACTION_CLASS")
// Puis définissez le nom du module python à partir de la variable d'environnementset..PythonModule = $system.Util.GetEnviron("INTERACTION_MODULE")
<span class="hljs-keyword">if</span> (<span class="hljs-built_in">..PythonPath</span> = <span class="hljs-string">""</span>) || (<span class="hljs-built_in">..PythonClassname</span> = <span class="hljs-string">""</span>) || (<span class="hljs-built_in">..PythonModule</span> = <span class="hljs-string">""</span>) {
	<span class="hljs-comment">//quit ##super(pStrategy)</span>
	<span class="hljs-keyword">set</span> <span class="hljs-built_in">..PythonPath</span> = <span class="hljs-string">"/irisdev/app/src/python/"</span>
	<span class="hljs-keyword">set</span> <span class="hljs-built_in">..PythonClassname</span> = <span class="hljs-string">"CustomInteraction"</span>
	<span class="hljs-keyword">set</span> <span class="hljs-built_in">..PythonModule</span> = <span class="hljs-string">"custom"</span>
}


<span class="hljs-comment">// Définissez ensuite la classe python</span>
<span class="hljs-keyword">do</span> <span class="hljs-built_in">..SetPythonPath</span>(<span class="hljs-built_in">..PythonPath</span>)
<span class="hljs-keyword">set</span> <span class="hljs-built_in">..PythonClass</span> = <span class="hljs-keyword">##class</span>(FHIR.Python.Interactions).GetPythonInstance(<span class="hljs-built_in">..PythonModule</span>, <span class="hljs-built_in">..PythonClassname</span>)

<span class="hljs-keyword">quit</span> <span class="hljs-keyword">##super</span>(pStrategy)
}
Method OnBeforeRequest(
pFHIRService As HS.FHIRServer.API.Service,
pFHIRRequest As HS.FHIRServer.API.Data.Request,
pTimeout As%Integer)
{
// OnBeforeRequest est appelée avant le traitement de chaque demande.if$ISOBJECT(..PythonClass) {
set body = ##class(%SYS.Python).None()
if pFHIRRequest.Json '= "" {
set jsonLib = ##class(%SYS.Python).Import("json")
set body = jsonLib.loads(pFHIRRequest.Json.%ToJSON())
}
do..PythonClass."on_before_request"(pFHIRService, pFHIRRequest, body, pTimeout)
}
}
Method OnAfterRequest(
pFHIRService As HS.FHIRServer.API.Service,
pFHIRRequest As HS.FHIRServer.API.Data.Request,
pFHIRResponse As HS.FHIRServer.API.Data.Response)
{
// OnAfterRequest est appelée après le traitement de chaque demande.if$ISOBJECT(..PythonClass) {
set body = ##class(%SYS.Python).None()
if pFHIRResponse.Json '= "" {
set jsonLib = ##class(%SYS.Python).Import("json")
set body = jsonLib.loads(pFHIRResponse.Json.%ToJSON())
}
do..PythonClass."on_after_request"(pFHIRService, pFHIRRequest, pFHIRResponse, body)
}
}
Method PostProcessRead(pResourceObject As%DynamicObject) As%Boolean
{
// PostProcessRead est appelée après la lecture d'une ressource dans la base de données.// Renvoyez 1 pour indiquer que la ressource doit être incluse dans la réponse.// Renvoyez 0 pour indiquer que la ressource doit être exclue de la réponse.if$ISOBJECT(..PythonClass) {
if pResourceObject '= "" {
set jsonLib = ##class(%SYS.Python).Import("json")
set body = jsonLib.loads(pResourceObject.%ToJSON())
}
return..PythonClass."post_process_read"(body)
}
quit1
}
Method PostProcessSearch(
pRS As HS.FHIRServer.Util.SearchResult,
pResourceType As%String) As%Status
{
// PostProcessSearch est appelée après l'exécution d'une recherche.// Renvoyez $$$OK pour indiquer que la recherche a abouti.// Renvoyez un code d'erreur pour indiquer que la recherche a échoué.if$ISOBJECT(..PythonClass) {
return..PythonClass."post_process_search"(pRS, pResourceType)
}
quit$$$OK
}
Method Read(
pResourceType As%String,
pResourceId As%String,
pVersionId As%String = "") As%DynamicObject
{
return##super(pResourceType, pResourceId, pVersionId)
}
Method Add(
pResourceObj As%DynamicObject,
pResourceIdToAssign As%String = "",
pHttpMethod = "POST") As%String
{
return##super(pResourceObj, pResourceIdToAssign, pHttpMethod)
}
/// Renvoie de VersionId pour la version "supprimée"
Method Delete(
pResourceType As%String,
pResourceId As%String) As%String
{
return##super(pResourceType, pResourceId)
}
Method Update(pResourceObj As%DynamicObject) As%String
{
return##super(pResourceObj)
}
}

La classe FHIR.Python.Interactions hérite de la classe HS.FHIRServer.Storage.Json.Interactions et de la classe FHIR.Python.Helper

La classe HS.FHIRServer.Storage.Json.Interactions est la mise en œuvre par défaut du serveur FHIR.

La classe FHIR.Python.Helper vise à aider à appeler du code Python à partir d'ObjectScript.

La classe FHIR.Python.Interactions remplacent les méthodes suivantes :

• %OnNew : appelée lors de la création de l'objet
  • nous utilisons cette méthode pour définir le chemin python, le nom de la classe python et le nom du module python à partir des variables d'environnement
  • si les variables d'environnement ne sont pas définies, nous utilisons les valeurs par défaut
  • nous définissons également la classe python
  • nous appelons la méthode %OnNew de la classe parente

Method %OnNew(pStrategy As HS.FHIRServer.Storage.Json.InteractionsStrategy) As %Status
{
	// Définissez d'abord le chemin python à partir d'une variable d'environnement
	set ..PythonPath = $system.Util.GetEnviron("INTERACTION_PATH")
	// Puis définissez le nom de la classe python à partir de la variable d'environnement
	set ..PythonClassname = $system.Util.GetEnviron("INTERACTION_CLASS")
	// Puis définissez le nom du module python à partir de la variable d'environnement
	set ..PythonModule = $system.Util.GetEnviron("INTERACTION_MODULE")

	if (..PythonPath = "") || (..PythonClassname = "") || (..PythonModule = "") {
		// utilisez les valeurs par défaut
		set ..PythonPath = "/irisdev/app/src/python/"
		set ..PythonClassname = "CustomInteraction"
		set ..PythonModule = "custom"
	}

	// Ensuite, définissez la classe python
	do ..SetPythonPath(..PythonPath)
	set ..PythonClass = ..GetPythonInstance(..PythonModule, ..PythonClassname)

	quit ##super(pStrategy)
}

• OnBeforeRequest : appelée avant l'envoi de la requête au serveur
  • nous appelons la méthode on_before_request de la classe python
  • nous passons l'objet HS.FHIRServer.API.Service, l'objet HS.FHIRServer.API.Data.Request, le corps de la requête et le timeout

Method OnBeforeRequest(
	pFHIRService As HS.FHIRServer.API.Service,
	pFHIRRequest As HS.FHIRServer.API.Data.Request,
	pTimeout As %Integer)
{
	// OnBeforeRequest est appelée avant le traitement de chaque requête.
	if $ISOBJECT(..PythonClass) {
		set body = ##class(%SYS.Python).None()
		if pFHIRRequest.Json '= "" {
			set jsonLib = ##class(%SYS.Python).Import("json")
			set body = jsonLib.loads(pFHIRRequest.Json.%ToJSON())
		}
		do ..PythonClass."on_before_request"(pFHIRService, pFHIRRequest, body, pTimeout)
	}
}

• OnAfterRequest : appelée après l'envoi de la requête au serveur
  • nous appelons la méthode on_after_request de la classe python
  • nous passons l'objet HS.FHIRServer.API.Service, l'objet HS.FHIRServer.API.Data.Request, l'objet HS.FHIRServer.API.Data.Response et le corps de la réponse

Method OnAfterRequest(
	pFHIRService As HS.FHIRServer.API.Service,
	pFHIRRequest As HS.FHIRServer.API.Data.Request,
	pFHIRResponse As HS.FHIRServer.API.Data.Response)
{
	// OnAfterRequest est appelée après le traitement de chaque requête.
	if $ISOBJECT(..PythonClass) {
		set body = ##class(%SYS.Python).None()
		if pFHIRResponse.Json '= "" {
			set jsonLib = ##class(%SYS.Python).Import("json")
			set body = jsonLib.loads(pFHIRResponse.Json.%ToJSON())
		}
		do ..PythonClass."on_after_request"(pFHIRService, pFHIRRequest, pFHIRResponse, body)
	}
}

• Et ainsi de suite...

Interactions en Python

La classeFHIR.Python.Interactions appelle les méthodes on_before_request, on_after_request, ... de la classe python.

Voici la classe python abstraite :

import abc
import iris

class Interaction(object):
    __metaclass__ = abc.ABCMeta

    @abc.abstractmethod
    def on_before_request(self, 
                          fhir_service:'iris.HS.FHIRServer.API.Service',
                          fhir_request:'iris.HS.FHIRServer.API.Data.Request',
                          body:dict,
                          timeout:int):
        """
        on_before_request is called before the request is sent to the server.
        param fhir_service: the fhir service object iris.HS.FHIRServer.API.Service
        param fhir_request: the fhir request object iris.FHIRServer.API.Data.Request
        param timeout: the timeout in seconds
        return: None
        """
        

    @abc.abstractmethod
    def on_after_request(self,
                         fhir_service:'iris.HS.FHIRServer.API.Service',
                         fhir_request:'iris.HS.FHIRServer.API.Data.Request',
                         fhir_response:'iris.HS.FHIRServer.API.Data.Response',
                         body:dict):
        """
        on_after_request is called after the request is sent to the server.
        param fhir_service: the fhir service object iris.HS.FHIRServer.API.Service
        param fhir_request: the fhir request object iris.FHIRServer.API.Data.Request
        param fhir_response: the fhir response object iris.FHIRServer.API.Data.Response
        return: None
        """
        

    @abc.abstractmethod
    def post_process_read(self,
                          fhir_object:dict) -> bool:
        """
        post_process_read is called after the read operation is done.
        param fhir_object: the fhir object
        return: True the resource should be returned to the client, False otherwise
        """
        

    @abc.abstractmethod
    def post_process_search(self,
                            rs:'iris.HS.FHIRServer.Util.SearchResult',
                            resource_type:str):
        """
        post_process_search is called after the search operation is done.
        param rs: the search result iris.HS.FHIRServer.Util.SearchResult
        param resource_type: the resource type
        return: None
        """

Mise en œuvre de la classe abstraite python

from FhirInteraction import Interaction

class CustomInteraction(Interaction):

    def on_before_request(self, fhir_service, fhir_request, body, timeout):
        #Extract the user and roles for this request
        #so consent can be evaluated.
        self.requesting_user = fhir_request.Username
        self.requesting_roles = fhir_request.Roles

    def on_after_request(self, fhir_service, fhir_request, fhir_response, body):
        #Clear the user and roles between requests.
        self.requesting_user = ""
        self.requesting_roles = ""

    def post_process_read(self, fhir_object):
        #Evaluate consent based on the resource and user/roles.
        #Returning 0 indicates this resource shouldn't be displayed - a 404 Not Found
        #will be returned to the user.
        return self.consent(fhir_object['resourceType'],
                        self.requesting_user,
                        self.requesting_roles)

    def post_process_search(self, rs, resource_type):
        #Iterate through each resource in the search set and evaluate
        #consent based on the resource and user/roles.
        #Each row marked as deleted and saved will be excluded from the Bundle.
        rs._SetIterator(0)
        while rs._Next():
            if not self.consent(rs.ResourceType,
                            self.requesting_user,
                            self.requesting_roles):
                #Mark the row as deleted and save it.
                rs.MarkAsDeleted()
                rs._SaveRow()

    def consent(self, resource_type, user, roles):
        #Example consent logic - only allow users with the role '%All' to see
        #Observation resources.
        if resource_type == 'Observation':
            if '%All' in roles:
                return True
            else:
                return False
        else:
            return True

Trop long, faisons un résumé

La classeFHIR.Python.Interactions est un wrapper pour appeler la classe python.

Les classes abstraites IRIS sont implémentées pour envelopper les classes abstraites python 🥳.

Cela nous aide à séparer le code python et le code ObjectScript et à bénéficier ainsi du meilleur des deux mondes.

Salut la Communauté!

Profitez de regarder la nouvelle vidéo sur la chaîne Youtube d'InterSystems France :

📺 CQL, au-delà du FHIR

Salut la Communauté!

Profitez de regarder la nouvelle vidéo sur la chaîne Youtube d'InterSystems France :

📺 Exploitation sécurisée d'un entrepôt de données démographiques FHIR au CHU de Toulouse

Salut la Communauté!

Profitez de regarder la nouvelle vidéo sur la chaîne Youtube d'InterSystems France :

📺 SQL on FHIR au service de la logistique hospitalière

Parfois, nous devons convertir le message FHIR en HL7 V2, par exemple pour enregistrer un patient dans le système PACS.
Dans cet article, les étapes à suivre pour obtenir les résultats souhaités en utilisant la production du serveur IRIS FHIR seront expliquées.

Voici les étapes à suivre:

1. Assurez-vous que la production du serveur FHIR est démarrée.
2. Enregistrez le service métier avec le point de terminaison FHIRServer.
3. Définissez les processus métier pour convertir les messages FHIR en SDA, puis convertissez SDA en HL7 v2.
4. Publiez la ressource JSON sur le point de terminaison FHIRServer et obtenez la réponse HL7 V2.

Examinons les étapes en détail.
 

Étape 1. Assurez-vous que la production du serveur FHIR est démarrée

Ouvrez la page de production et assurez-vous que la Production est démarrée. À l'étape suivante, nous devons nous assurer que le service commercial HS.FHIRServer.Interop.Service est enregistré auprès de FHIRServer

Step 2. Étape 2. Enregistrez le service métier avec le point de terminaison FHIRServer.

Depuis le portail de gestion, cliquez sur l'onglet Health (Santé)

Cliquez ensuite sur Configuration FHIR dans la liste, puis cliquez sur Server Configuration (configuration du serveur)

Sélectionnez le point de terminaison et assurez-vous que HS.FHIRServer.Interop.Service (service commercial défini dans la production) est défini sous le nom Service Config Name.

Étape 3. Définissez les processus métier pour convertir les messages FHIR en SDA, puis convertissez SDA en HL7 v2.

Définissez le rpocessus métier (le processus Solution.BP.Process est déjà défini dans l'application).
Veuillez noter que nous appliquons ici une condition selon laquelle le point de terminaison doit contenir une augmentation hl7 pour procéder à la conversion, sinon il est considéré comme une demande FHIR normale.

Transmettez ensuite le message au processus FHIR_SDA qui le convertira en SDA.
FHIR_SDA est dérivé d'une classe Solution.BP.Process définie par l'utilisateur.
Après conversion FHIR_SDA, le processus transmet le message au processus SDA_HL7
Le processus SDA_HL7 est dérivé d'une classe Solution.BP.SDATransformProcess définied  par l'utilisateur qui convertit le message SDA en message HL7 V2.

Définissez les processus de production comme suit:

Étape 4. Publiez la ressource JSON sur le point de terminaison FHIRServer et obtenez la réponse HL7 V2.

Depuis Postman, appelez le point de terminaison FHIRServer à l'aide de la méthode Post.
Notre point de terminaison FHIRServer est ci-dessous:
http://localhost:32783/csp/fhirserver/fhir/r4/hl7

REMARQUE:Notre point de terminaison FHIRServer est http://localhost:32783/csp/fhirserver/fhir/r4/, mais nous passons hl7 comme argument pour détecter à partir du processus métier de production qu'il ne s'agit pas d'une demande Post FHIR normale mais d'une demande de transformation du message FHIR.

Il s'agit de la même fonctionnalité que celle que nous pouvons utiliser à partir de nos applications Web. 
Sélectionnez la ressource patient, puis cliquez sur la ressource dans la liste, sélectionnez l'onglet HL7 FHIR ou Détails de la ressource, et cliquez sur le bouton "Transformer FHIR en HL7 V2"

L'application obtiendra le message de transformation HL7 V2 à l'aide de la production du serveur FHIR.

Transformation de HL7 V2 à FHIR

Sélectionnez "HL7 to FHIR" dans le menu et entrez les données HL7 V2. Cliquez sur le bouton de conversion pour transformer le message HL7 en message FHIR

La transformation de HL7 en FHIR utilise également la production pour convertir le message HL7 V2 en message FHIR.

Le service métier HL7_Http_Service envoie le message HL7 au processus HL7_SDA, puis HL7_SDA envoie les données SDA au processus SDA_FHIR, qui les convertit finalement en FHIR

Pour plus de détails et une révision du code, veuillez visiter la page d'application de l'échange ouvert iris-fhir-lab .
Merci!

Cet article a pour objectif de fournir au lecteur les informations suivantes:

• Configuration et utilisation du serveur FHIR
• Création d'un serveur d'autorisation OAuth2
• Liaison entre le serveur FHIR et le serveur d'autorisation OAuth2 pour la prise en charge de SMART sur FHIR
• Utilisation des capacités d'interopérabilité dans "IRIS for Health" pour filtrer les ressources FHIR
• Création d'une opération personnalisée sur le serveur FHIR

Schéma de l'article:

Flux de travail de l'article:

1. Table des matières

• 1. Table des matières
• 2. Objectifs
• 3. Installation
  • 3.1. Accès au serveur FHIR
  • 3.2. Accés au portail de gestion d'InterSystems IRIS
• 4. Configuration du serveur d'autorisation OAuth2
  • 4.1. Onglet Généralités
  • 4.2. Onglet Périmètre
  • 4.3. Onglet JWT
  • 4.4. Onglet Personnalisation
• 5. Configuration du Client
  • 5.1. Enregistrement du serveur d'autorisation OAuth2
  • 5.2. Description du serveur
  • 5.3. Création d'un nouveau client
    • 5.3.1. Onglet Généralités
• 6. Configuration du serveur FHIR
  • 6.1. Création un nouveau serveur FHIR
  • 6.2. Liaison entre le serveur FHIR et le serveur d'autorisation OAuth2
  • 6.3. Test du serveur FHIR
• 7. Filtrage des ressources FHIR avec "InterSystems IRIS for Health"
  • 7.1. Cadre d'Interopérabilité
  • 7.2. Installation de l'IoP
  • 7.3. Création de la production d'interopérabilité
    • 7.3.1. Test de la production d'interopérabilité
  • 7.4. Modification du processus métier
    • 7.4.1. Préparation de votre environnement de développement
    • 7.4.2. Exécution des tests
    • 7.4.3. Mise en œuvre du code
      • 7.4.3.1. check_token
      • 7.4.3.2. filter_patient_resource
      • 7.4.3.3. filter_resources
      • 7.4.3.4. on_fhir_request
    • 7.4.4. Exécution des tests
• 8. Création de l'opération personnalisée
  • 8.1. Codage de l'opération personnalisée
    • 8.1.1. add_supported_operations
    • 8.1.2. process_operation
• 9. Trucs & astuces
  • 9.1. Journal de Csp
  • 9.2. Solution de BP

2. Objectifs

Cette session de formation vise à fournir aux participants les compétences suivantes:

• Configuration et utilisation du serveur FHIR
• Création d'un serveur d'autorisation OAuth2
• Liaison entre le serveur FHIR et le serveur d'autorisation OAuth2 pour la prise en charge de SMART sur FHIR
• Utilisation des capacités d'interopérabilité dans "IRIS for Health" pour filtrer les ressources FHIR
• Création d'une opération personnalisée sur le serveur FHIR

3. Installation

Pour installer l'environnement de formation, vous devez avoir installé Docker et Docker Compose sur votre machine.

Vous pouvez installer Docker et Docker Compose en suivant les instructions sur le site Docker website.

Une fois Docker et Docker Compose installés, vous pouvez cloner ce dépôt et exécuter la commande suivante:

docker-compose up -d

Cette commande démarre le conteneur "IRIS for Health" et le conteneur "Web Gateway" pour exposer le serveur FHIR via HTTPS.

3.1. Accès au serveur FHIR

Une fois les conteneurs démarrés, vous pouvez accéder au serveur FHIR à l'URL suivante:

https://localhost:4443/fhir/r5/

3.2. Accés au Portail de Gestion d'InterSystems IRIS

Vous pouvez accéder au portail de gestion InterSystems IRIS à l'adresse suivante:

http://localhost:8089/csp/sys/UtilHome.csp

Le nom d'utilisateur et le mot de passe par défaut sont "SuperUser" et "SYS" respectivement.

4. Configuration du serveur d'autorisation OAuth2

Pour configurer le serveur d'autorisation OAuth2, il faut se connecter au portail de gestion InterSystems IRIS et naviguer jusqu'à l'administration du système: System Administration > Security > OAuth 2.0 > Servers.

Ensuite, nous remplirons le formulaire pour créer un nouveau serveur d'autorisation OAuth2.

4.1. Onglet Généralités

Nous commençons d'abord par l'onglet Généralités.

Les paramètres sont les suivants:

• Description: La description du serveur d'autorisation OAuth2
  • Serveur d'autorisation Oauth2 Auth
• Émetteur: L'URL du serveur d'autorisation OAuth2
  • https://webgateway/oauth2
  • REMARQUE : Nous utilisons ici l'URL de la passerelle Web Gateway pour exposer le serveur FHIR via HTTPS. Il s'agit du nom DNS interne du conteneur de la passerelle Web Gateway.
• Types de subventions pris en charge: Les types de subventions pris en charge par le serveur d'autorisation OAuth2
  • Code d'autorisation
  • Informations d'identification du client
  • Autorisation JWT
  • REMARQUE : Nous utiliserons le type de subvention de Client Credentials (informations d'identification du client) pour authentifier le serveur FHIR auprès du serveur d'autorisation OAuth2.
• Configuration SSL/TLS: La configuration SSL/TLS à utiliser pour le serveur d'autorisation OAuth2.
  • Par défaut: BFC_SSL

4.2. Onglet Périmètre

Ensuite, nous passons à l'onglet Périmètre.

Nous allons créer 3 périmètres:

• user/Patient.read: Le périmètre de lecture des ressources disponibles pour les patients
• VIP: Le périmètre de lecture des ressources disponibles pour les patients VIP
• user/.: Le périmètre de lecture toutes les ressources, à des fins administratives

4.3. Onglet JWT

Ensuite, nous passons à l'onglet JWT.

Ici, nous sélectionnons simplement l'algorithme à utiliser pour le JWT..

Nous utiliserons l'algorithme RS256.

Si nécessaire, nous pouvons sélectionner le cryptage pour le JWT. Nous n'utiliserons pas de cryptage pour cette session de formation.

4.4. Onglet Personnalisation

Ensuite, nous passons à l'onglet Personnalisation.

Voici toutes les classes de personnalisation pour le serveur d'autorisation OAuth2.

Nous changeons les classes suivantes:

• Classe de génération du jeton: La classe à utiliser pour générer le jeton
  • FROM : %OAuth2.Server.Generate
  • TO : %OAuth2.Server.JWT

Nous pouvons maintenant enregistrer le serveur d'autorisation OAuth2.

Félicitations, nous avons maintenant configuré le serveur d'autorisation OAuth2. 🥳

5. Configuration du Client

Pour configurer le Client, il faut se connecter au portail de gestion InterSystems IRIS et naviguer jusqu'à l'administration du système: System Administration > Security > OAuth 2.0 > Client.

Pour créer un nouveau client, il faut d'abord enregistrer le serveur d'autorisation OAuth2.

5.1. Enregistrement du serveur d'autorisation OAuth2

Sur la page client, cliquez sur le bouton de création d'une description de serveur Create Server Description.

5.2. Description du serveur

Dans le formulaire Description du serveur, nous devons remplir les paramètres suivants:

• URL du serveur: L'URL du serveur d'autorisation OAuth2
  • https://webgateway/oauth2
• Configuration SSL/TLS: La configuration SSL/TLS à utiliser pour le serveur d'autorisation OAuth2
  • Par défaut: BFC_SSL

Cliquez sur le bouton Discover and Save (Découvrir et enregistrer). Félicitations, nous avons maintenant enregistré le serveur d'autorisation OAuth2.

5.3. Création d'un nouveau client

Ensuite, nous pouvons créer un nouveau client.

Sur la page client, nous avons un nouveau bouton Client Configuration (Configuration Client).

Cliquez sur le bouton de lien Client Configuration vers la description du serveur.

Nous pouvons maintenant créer un nouveau client..

5.3.1. Onglet Généralités

Nous commençons d'abord par l'onglet Généralités.

Les paramètres sont les suivants:

• Nom de l'application: Le nom du client
  • App
  • REMARQUE : C'est le nom du client.
• Nom du client: Le nom du client
  • App
• *Type de client: Le type du client
  • Confidentiel
  • REMARQUE : Nous utiliserons le type de client "confidentiel" pour authentifier le serveur FHIR auprès du serveur d'autorisation OAuth2.
• URI de redirection: L'URI de redirection du client
  • https://webgateway/oauth2
  • REMARQUE : Nous utilisons ici l'URL de la passerelle Web Gateway pour exposer le serveur FHIR via HTTPS. Il s'agit du nom DNS interne du conteneur de la passerelle Web Gateway.
  • REMARQUE : Ceci ne sera pas utilisé dans cette session de formation.
• Types de subventions: Les types de subventions pris en charge par le client
  • Informations d'identification du client
  • REMARQUE : Nous utiliserons le type de subvention de Client Credentials (informations d'identification du client) pour authentifier l'application client (Client Application) auprès du serveur d'autorisation OAuth2.
• Type d'authentification: Le type d'authentification du client
  • Basique
  • REMARQUE : Nous utiliserons le type d'authentification Basique pour authentifier l'application client (Client Application) auprès du serveur d'autorisation OAuth2.

Maintenant, nous pouvons cliquer sur le bouton Dynamic Registration (Enregistrement dynamique)..

Félicitations, nous avons maintenant créé le client. 🥳

Si nous allons dans l'onglet Client Credentials (Informations d'identification du client), nous pouvons voir les informations d'identification du client.

Notez que les informations d'identification du client sont Client ID et Client Secret (l'Identifiant du client et le Secret du client).

6. Configuration du serveur FHIR

⚠️ AVERTISSEMENT ⚠️ : Assurez-vous d'être sur l'espace de noms FHIRSERVER.

Pour configurer le serveur FHIR, il faut se connecter au portail de gestion InterSystems IRIS et naviguer: Health > FHIR Configuration > Servers.

Ensuite, nous allons créer un nouveau serveur FHIR.

Cliquez sur le bouton Server Configuration (Configuration du Serveur).

6.1. Création un nouveau serveur FHIR

Dans le formulaire Configuration du serveur, nous devons remplir les paramètres suivants:

• Paquet de base FHIR: Le paquet de base FHIR à utiliser pour le serveur FHIR
  • r5
• Adresse URL: L'URL du serveur FHIR
  • /fhir/r5
• Stratégie d'interactions: La stratégie d'interactions à utiliser pour le serveur FHIR
  • FHIR.Python.InteractionsStrategy
  • ⚠️ AVERTISSEMENT ⚠️ : Pas comme sur la photo, il faut sélectionner la stratégie d'interactions FHIR.Python.InteractionsStrategy.

Cliquer sur le bouton Add.

Cela peut prendre quelques minutes. 🕒 Allons prendre un café. ☕️

Félicitations, nous avons maintenant créé le serveur FHIR. 🥳

6.2. Liaison entre le serveur FHIR et le serveur d'autorisation OAuth2

Sélectionnez le serveur FHIR et descendez jusqu'au bouton Edit (modifier).

Dans le formulaire Serveur FHIR , nous devons remplir les paramètres suivants:

• Nom du Client OAuth2: Le nom du Client
  • App

Cliquez sur le bouton Save (sauvegarder).

Félicitations, nous avons maintenant lié le serveur FHIR au serveur d'autorisation OAuth2. 🥳

6.3. Test du serveur FHIR

Pour tester le serveur FHIR, vous pouvez utiliser la commande suivante:

GET https://localhost:4443/fhir/r5/Patient

Sans l'en-tête Authorization, vous obtiendrez une réponse 401 Unauthorized.

Pour authentifier la demande, vous devez ajouter l'en-tête Authorization avec le jeton Bearer.

Pour ce faire, demandons un jeton au serveur d'autorisation OAuth2.

POST https://localhost:4443/oauth2/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <client_id>:<client_secret>

grant_type=client_credentials&scope=user/Patient.read&aud=https://localhost:4443/fhir/r5

Vous obtiendrez une réponse 200 OK avec le jeton d'accès access_token et le type de jeton token_type.

Maintenant, vous pouvez utiliser jeton d'accès access_token pour authentifier la demande auprès du serveur FHIR.

GET https://localhost:4443/fhir/r5/Patient
Authorization: Bearer <access_token>
Accept: application/fhir+json

Félicitations, vous avez maintenant authentifié la demande sur le serveur FHIR. 🥳

7. Filtrage des ressources FHIR avec "InterSystems IRIS for Health"

Eh bien, nous aborderont maintenant un grand sujet.

Le but de ce sujet sera de mettre en place les capacités d'interopérabilité d'IRIS for Health entre le serveur FHIR et l'application cliente.

Ci-dessous, une vue macro de l'architecture:

Et voici le flux de travail:

Ce que nous remarquons ici, c'est que l'EAI (capacités d'interopérabilité d'IRIS for Health) servira de chemin d'accès pour les demandes entrantes vers le serveur FHIR. Il filtrera la réponse du serveur FHIR en fonction des champs d'application et enverra la réponse filtrée à l'application cliente.

Avant d'aller plus loin, permettez-moi de vous présenter rapidement les capacités d'interopérabilité d'IRIS for Health.

7.1. Cadre d'Interopérabilité

Il s'agit du cadre IRIS Framework.

L'objectif de ce cadre est de fournir un moyen de relier différents systèmes entre eux.

Nous avons 4 composants principaux:

• Services métiers: Le point d'entrée du cadre. Il reçoit la demande entrante et l'envoie à la production.
• Processus métier: Le flux de travail du cadre. Il traite la demande entrante et l'envoie à l'opération métier.
• Operations métier: Le point de sortie du cadre. Il traite la demande entrante et l'envoie au service métier.
• Messages: Les données du cadre. Elles contiennent la requête entrante et la réponse sortante.

Pour cette session de formation, nous utiliserons les composants suivants:

• Un service métier Business Service pour recevoir la demande de l'application cliente.
• Un processus métier Business Process pour filtrer la réponse du serveur FHIR en fonction des péramètres.
• Une opération métier Business Operation pour envoyer les messages au serveur FHIR.

Pour cette session de formation, nous utiliserons une production d'interopérabilité pré-construite.

Nous nous concentrerons uniquement sur le processus métier Business Process permettant de filtrer la réponse du serveur FHIR en fonction des périmètres.

7.2. Installation de l'IoP

Pour cette partie, nous utiliserons l'outil IoP. IoP signifie l'Interopérabilité sur Python..

Vous pouvez installer l'outil IoP en suivant les instructions du référentiel de l'IoP

L'outil IoP est pré-installé dans l'environnement de formation.

Connectez-vous au conteneur en cours d'exécution:

docker exec -it formation-fhir-python-iris-1 bash

Et exécutez la commande suivante:

iop --init

Ainsi l'IoP sera installée sur le conteneur IRIS for Health.

7.3. Création de la Production d'Interopérabilité

Toujours dans le conteneur, exécutez la commande suivante:

iop --migrate /irisdev/app/src/python/EAI/settings.py

Ainsi, la production d'interopérabilité sera créée.

Vous pouvez maintenant accéder à la production d'interopérabilité à l'adresse URL suivante:

http://localhost:8089/csp/healthshare/eai/EnsPortal.ProductionConfig.zen?$NAMESPACE=EAI&$NAMESPACE=EAI&

Vous pouvez maintenant lancer la production.

Félicitations, vous avez créé la production d'interopérabilité. 🥳

7.3.1. Test de la Production d'Interopérabilité

Obtenez un jeton du serveur d'autorisation OAuth2.

POST https://localhost:4443/oauth2/token
Content-Type: application/x-www-form-urlencoded
Authorization : Basic <client_id>:<client_secret>

grant_type=client_credentials&scope=user/Patient.read&aud=https://webgateway/fhir/r5

⚠️ AVERTISSEMENT ⚠️ : we change the aud parameter to the URL of the Web Gateway to expose the FHIR server over HTTPS.

Faites passer un patient par la production d'interopérabilité.

GET https://localhost:4443/fhir/Patient
Authorization : Bearer <Token>
Accept: application/fhir+json

Vous pouvez voir la trace de la requête dans la production d'interopérabilité.

http://localhost:8089/csp/healthshare/eai/EnsPortal.MessageViewer.zen?SOURCEORTARGET=Python.EAI.bp.MyBusinessProcess

7.4. Modification du processus métier

Tout le code pour le processus métier Business Process se trouve dans le fichier suivant : https://github.com/grongierisc/formation-fhir-python/blob/main/src/python/EAI/bp.py

Pour cette session de formation, nous adopterons une approche de développement piloté par les tests, TTD (Test Driven Development)..

Tous les tests pour le processus métier Business Process se trouve dans le fichier suivant : https://github.com/grongierisc/formation-fhir-python/blob/main/src/python/tests/EAI/test_bp.py

7.4.1. Préparation de votre environnement de développement

Pour préparer votre environnement de développement, il faut créer un environnement virtuel.

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

7.4.2. Exécution des tests

Pour exécuter les tests, vous pouvez utiliser la commande suivante:

pytest

Les tests échouent.

7.4.3. Mise en œuvre du code

Nous avons 4 fonctions à mettre en œuvre:

• check_token
• on_fhir_request
• filter_patient_resource
• filter_resources

Vous pouvez mettre en œuvre le code dans https://github.com/grongierisc/formation-fhir-python/blob/main/src/python/EAI/bp.py file.

7.4.3.1. check_token

Cette fonction vérifie si le jeton est valide et si le champ d'application contient le périmètre VIP. Si le jeton est valide et que le périmètre contient le périmètre VIP, la fonction renvoie True (vrai), sinon elle renvoie False (faux). Nous utiliserons la bibliothèque jwt pour décoder le jeton.

def check_token(self, token:str) -> bool:

    # décoder le jeton
    try:
        decoded_token= jwt.decode(token, options={"verify_signature": False})
    except jwt.exceptions.DecodeError:
        return False

    # vérifier si le jeton est valide
    if 'VIP' in decoded_token['scope']:
        return True
    else:
        return False

7.4.3.2. filter_patient_resource

Cette fonction filtrera la ressource patient.

Cela supprimera les champ name, address, telecom and birthdate (nom, adresse, télécom et date de naissance) de la ressource patient..

La fonction renverra la ressource patient filtrée sous forme de chaîne.

Nous utiliserons la bibliothèque fhir.resources pour analyser la ressource patient.

Notez la signature de la fonction.

La fonction prend une chaîne en entrée et renvoie une chaîne comme le résultat.

Nous devons donc analyser la chaîne d'entrée en un objet fhir.resources.patient.Patient, puis analyser l'objet fhir.resources.patient.Patient en une chaîne.

def filter_patient_resource(self, patient_str:str) -> str:
    # filtrer le patient
    p = patient.Patient(**json.loads(patient_str))
    # supprimer le nom
    p.name = []
    # supprimer l'adresse
    p.address = []
    # supprimer le télécom
    p.telecom = []
    # supprimer la date de naissance
    p.birthDate = None

    return p.json()

7.4.3.3. filter_resources

Cette fonction filtrera les ressources.

Nous devons vérifier le type de ressource et filtrer la ressource en fonction du type de ressource.

Si le type de ressource est Bundle (Paquet), nous devons filtrer toutes les entrées du paquet qui sont de type Patient.

Si le type de ressource est Patient, nous devons filtrer la resource de type patient.

La fonction renverra la ressource filtrée sous forme de chaîne.

Nous utiliserons la bibliothèque fhir.resources pour analiser la ressource.

    def filter_resources(self, resource_str:str) -> str:
        # analyser le payload
        payload_dict = json.loads(resource_str)

        # quel est le type de ressource?
        resource_type = payload_dict['resourceType'] if 'resourceType' in payload_dict else 'None'
        self.log_info('Resource type: ' + resource_type)

        # c'est un paquet?
        if resource_type == 'Bundle':
            obj = bundle.Bundle(**payload_dict)
            # filtrer le paquet
            for entry in obj.entry:
                if entry.resource.resource_type == 'Patient':
                    self.log_info('Filtering a patient')
                    entry.resource = patient.Patient(**json.loads(self.filter_patient_resource(entry.resource.json())))

        elif resource_type == 'Patient':
            # filtrer le patient
            obj = patient.Patient(**json.loads(self.filter_patient_resource(resource_str)))
        else:
            return resource_str

        return obj.json()

7.4.3.4. on_fhir_request

Cette fonction sera le point d'entrée du processus métier Business Process.

Elle recevra la demande du service métier Business Service, vérifiera le jeton, filtrera la réponse du serveur FHIR en fonction des champs d'application et enverra la réponse filtrée au service métier Business Service.

La fonction renverra la réponse du serveur FHIR.

Nous utiliserons la bibliothèque iris pour envoyer la requête au serveur FHIR.

Le message sera un objet iris.HS.FHIRServer.Interop.Request.

Cet objet contient la requête au serveur FHIR.

Il consiste des composant suivants: Method, URL, Headers et Payload.

Pour vérifier le jeton, nous utiliserons la fonction check_token et pour obtenir un jeton, il faut utiliser l'en-tête USER:OAuthToken.

Pour filtrer la reponse, nous utiliserons la fonction filter_resources et pour lire la réponse du serveur FHIR, nous utiliserons QuickStream.

def on_fhir_request(self, request:'iris.HS.FHIRServer.Interop.Request'):
    # Faire quelque chose avec la requête
    self.log_info('Received a FHIR request')

    # La passer à la cible
    rsp = self.send_request_sync(self.target, request)

    # Essayer d'obtenir le jeton de la requête
    token = request.Request.AdditionalInfo.GetAt("USER:OAuthToken") or ""

    # Faire quelque chose avec la réponse
    if self.check_token(token):
        self.log_info('Filtering the response')
        # Filtrer la réponse
        payload_str = self.quick_stream_to_string(rsp.QuickStreamId)

        # Si le payload est vide, renvoyer la réponse
        if payload_str == '':
            return rsp

        filtered_payload_string = self.filter_resources(payload_str)
        if filtered_payload_string == '':
            return rsp

        # écrire la chaîne json dans un flux rapide
        quick_stream = self.string_to_quick_stream(filtered_payload_string)

        # renvoyer la réponse
        rsp.QuickStreamId = quick_stream._Id()

    return rsp

7.4.4. Exécution des tests

Pour exécuter les tests, vous pouvez utiliser la commande suivante:

pytest

Les tests passent. 🥳

Vous pouvez maintenant tester le processus métier Business Process avec la production d'interopérabilité.

8. Création de l'opération personnalisée

Dernière partie de la session de formation. 🏁

Nous allons créer une opération personnalisée sur le serveur FHIR.

L'opération personnalisée sera opération de fusion de patients Patient et le résultat sera la différence entre les deux patients.

exemple:

POST https://localhost:4443/fhir/r5/Patient/1/$merge
Authorization : Bearer <Token>
Accept: application/fhir+json
Content-Type: application/fhir+json

{
  "resourceType": "Patient",
  "id": "2",
  "meta": {
    "versionId": "2"
  }
}

La réponse sera la différence entre les 2 patients.

{
    "values_changed": {
        "root['address'][0]['city']": {
            "new_value": "fdsfd",
            "old_value": "Lynnfield"
        },
        "root['meta']['lastUpdated']": {
            "new_value": "2024-02-24T09:11:00Z",
            "old_value": "2024-02-28T13:50:27Z"
        },
        "root['meta']['versionId']": {
            "new_value": "1",
            "old_value": "2"
        }
    }
}

Avant de poursuivre, permettez-moi de présenter rapidement l'opération personnalisée sur le serveur FHIR..

L'opération de personnalisation se décline en trois types:

• Opération d'instance: L'opération est effectuée sur une instance spécifique d'une ressource.
• Opération de type: L'opération est effectuée sur un type de ressource.
• Opération de système: L'opération est effectuée sur le serveur FHIR.

Pour cette session de formation, pour la création de l'opération personnalisée nous utiliserons l'Instance Operation.

8.1. Codage de l'opération personnalisée

Une opération personnalisée doit hériter de la classe OperationHandler à partir du module FhirInteraction.

Voici la signature de la classe OperationHandler:

class OperationHandler(object):

    @abc.abstractmethod
    def add_supported_operations(self,map:dict) -> dict:
        """
        @API Enumerate the name and url of each Operation supported by this class
        @Output map : A map of operation names to their corresponding URL.
        Example:
        return map.put("restart","http://hl7.org/fhir/OperationDefinition/System-restart")
        """

    @abc.abstractmethod
    def process_operation(
        self,
        operation_name:str,
        operation_scope:str,
        body:dict,
        fhir_service:'iris.HS.FHIRServer.API.Service',
        fhir_request:'iris.HS.FHIRServer.API.Data.Request',
        fhir_response:'iris.HS.FHIRServer.API.Data.Response'
    ) -> 'iris.HS.FHIRServer.API.Data.Response':
        """
        @API Process an Operation request.
        @Input operation_name : The name of the Operation to process.
        @Input operation_scope : The scope of the Operation to process.
        @Input fhir_service : The FHIR Service object.
        @Input fhir_request : The FHIR Request object.
        @Input fhir_response : The FHIR Response object.
        @Output : The FHIR Response object.
        """

Comme nous l'avons fait dans la partie précédente, nous utiliserons une approche TTD (Développement piloté par les tests).

Tous les tests pour le Processus d'Affaires sont dans ce fichier : https://github.com/grongierisc/formation-fhir-python/blob/main/src/python/tests/FhirInteraction/test_custom.py

8.1.1. add_supported_operations

Cette fonction ajoute l'opération de fusion de patients Patient aux opérations prises en charge.

La fonction retournera un dictionnaire avec le nom de l'opération et l'adresse URL de l'opération. Sachez que le dictionnaire d'entrée peut être vide.

Le résultat attendu est le suivant:

{
  "resource": 
    {
      "Patient": 
        [
          {
            "name": "merge",
            "definition": "http://hl7.org/fhir/OperationDefinition/Patient-merge"
          }
        ]
    }
}

This json document will be added to the CapabilityStatement of the FHIR server.

def add_supported_operations(self,map:dict) -> dict:
    """
    @API Enumerate the name and url of each Operation supported by this class
    @Output map : A map of operation names to their corresponding URL.
    Example:
    return map.put("restart","http://hl7.org/fhir/OperationDefinition/System-restart")
    """

    # verify the map has attribute resource 
    if not 'resource' in map:
        map['resource'] = {}
    # verify the map has attribute patient in the resource
    if not 'Patient' in map['resource']:
        map['resource']['Patient'] = []
    # add the operation to the map
    map['resource']['Patient'].append({"name": "merge" , "definition": "http://hl7.org/fhir/OperationDefinition/Patient-merge"})

    return map

8.1.2. process_operation

Cette fonction traitera l'opération de fusion Patient.

La fonction renverra la différence entre les 2 patients.

Nous allons utiliser la bibliothèque deepdiff pour obtenir la différence entre les 2 patients.

Les paramètres d'entrée sont les suivants:

• operation_name: Le nom de l'opération à traiter.
• operation_scope: Le périmètre de l'opération à traiter.
• body: Le corps de l'operation.
• fhir_service: L'objet FHIR Service.
  • fhir_service.interactions.Read
    • Une méthode pour lire une ressource à partir du serveur FHIR.
    • Les paramètres d'entrée sont les suivants:
      • resource_type: Le type de la ressource à lire.
      • resource_id: L'identifiant de la ressource à lire.
    • Le résultat est un objet %DynamicObject
• fhir_request: L'objet de requête FHIR Request..
  • fhir_request.Json
    • Propriété permettant d'obtenir le corps de la requête, c'est un objet %DynamicObject
• fhir_response: L'objet de réponse FHIR Response.
  • fhir_response.Json
    • Propriété permettant de définir le corps de la réponse, c'est un objet %DynamicObject.

%DynamicObject est une classe permettant de manipuler des objets JSON.

C'est la même chose qu'un dictionnaire Python mais pour ObjectScript.

Téléchargement d'objet JSON:

json_str = fhir_request.Json._ToJSON()
json_obj = json.loads(json_str)

Définition d'objet JSON:

json_str = json.dumps(json_obj)
fhir_response.Json._FromJSON(json_str)

Assurez-vous que la fonction de traitement process_operation est appelée pour vérifier si operation_name est merge, operation_scope est Instance et RequestMethod est POST.

def process_operation(
    self,
    operation_name:str,
    operation_scope:str,
    body:dict,
    fhir_service:'iris.HS.FHIRServer.API.Service',
    fhir_request:'iris.HS.FHIRServer.API.Data.Request',
    fhir_response:'iris.HS.FHIRServer.API.Data.Response'
) -> 'iris.HS.FHIRServer.API.Data.Response':
    """
    @API Process an Operation request.
    @Input operation_name : The name of the Operation to process.
    @Input operation_scope : The scope of the Operation to process.
    @Input fhir_service : The FHIR Service object.
    @Input fhir_request : The FHIR Request object.
    @Input fhir_response : The FHIR Response object.
    @Output : The FHIR Response object.
    """
    if operation_name == "merge" and operation_scope == "Instance" and fhir_request.RequestMethod == "POST":
        # obtenir la ressource primaire
        primary_resource = json.loads(fhir_service.interactions.Read(fhir_request.Type, fhir_request.Id)._ToJSON())
        # obtenir la ressource secondaire
        secondary_resource = json.loads(fhir_request.Json._ToJSON())
        # retrouver la différence entre les deux ressources
        # utiliser deepdiff pour obtenir la différence entre les deux ressources
        diff = DeepDiff(primary_resource, secondary_resource, ignore_order=True).to_json()

        # créer un nouvel %DynamicObject pour stocker le résultat
        result = iris.cls('%DynamicObject')._FromJSON(diff)

        # mettre le résultat dans la réponse
        fhir_response.Json = result
    
    return fhir_response

à tester :

POST https://localhost:4443/fhir/r5/Patient/1/$merge
Authorization : Bearer <Token>
Accept: application/fhir+json

{
  "resourceType": "Patient",
  "id": "2",
  "meta": {
    "versionId": "2"
  }
}

Vous obtiendrez la différence entre les 2 patients.

{
    "values_changed": {
        "root['address'][0]['city']": {
            "new_value": "fdsfd",
            "old_value": "Lynnfield"
        },
        "root['meta']['lastUpdated']": {
            "new_value": "2024-02-24T09:11:00Z",
            "old_value": "2024-02-28T13:50:27Z"
        },
        "root['meta']['versionId']": {
            "new_value": "1",
            "old_value": "2"
        }
    }
}

Félicitations, vous avez créé l'opération personnalisée. 🥳

9. Trucs et Astuces

9.1. Journal de Csp

In %SYS

set ^%ISCLOG = 5
zw ^ISCLOG

9.2. Solution de BP

from grongier.pex import BusinessProcess
import iris
import jwt
import json
from fhir.resources import patient, bundle

class MyBusinessProcess(BusinessProcess):

    def on_init(self):
        if not hasattr(self, 'target'):
            self.target = 'HS.FHIRServer.Interop.HTTPOperation'
            return

    def on_fhir_request(self, request:'iris.HS.FHIRServer.Interop.Request'):
        # Faire quelque chose avec la requête
        self.log_info('Received a FHIR request')

        # La passer à la cible
        rsp = self.send_request_sync(self.target, request)

        # Essayez d'obtenir le jeton de la requête
        token = request.Request.AdditionalInfo.GetAt("USER:OAuthToken") or ""

        # Faire quelque chose avec la réponse
        if self.check_token(token):
            self.log_info('Filtering the response')
            # Filtrer la reponse
            payload_str = self.quick_stream_to_string(rsp.QuickStreamId)

            # si le payload est vide, renvoyer la réponse
            if payload_str == '':
                return rsp

            filtered_payload_string = self.filter_resources(payload_str)
            if filtered_payload_string == '':
                return rsp

            # écrire la chaîne json dans un flux rapide
            quick_stream = self.string_to_quick_stream(filtered_payload_string)

            # renvoyer la réponse
            rsp.QuickStreamId = quick_stream._Id()

        return rsp
    
    def check_token(self, token:str) -> bool:

        # décoder le jeton
        decoded_token= jwt.decode(token, options={"verify_signature": False})

        # vérifier si le jeton est valide
        if 'VIP' in decoded_token['scope']:
            return True
        else:
            return False

    def quick_stream_to_string(self, quick_stream_id) -> str:
        quick_stream = iris.cls('HS.SDA3.QuickStream')._OpenId(quick_stream_id)
        json_payload = ''
        while quick_stream.AtEnd == 0:
            json_payload += quick_stream.Read()

        return json_payload
    
    def string_to_quick_stream(self, json_string:str):
        quick_stream = iris.cls('HS.SDA3.QuickStream')._New()

        # écrire la chaîne json dans le payload
        n = 3000
        chunks = [json_string[i:i+n] for i in range(0, len(json_string), n)]
        for chunk in chunks:
            quick_stream.Write(chunk)

        return quick_stream

    def filter_patient_resource(self, patient_str:str) -> str:
        # filtrer le patient
        p = patient.Patient(**json.loads(patient_str))
        # supprimer le nom
        p.name = []
        # supprimer l'adresse
        p.address = []
        # supprimer le télécom
        p.telecom = []
        # supprimer la date de naissance
        p.birthDate = None

        return p.json()

    def filter_resources(self, resource_str:str) -> str:
        # analyser le payload
        payload_dict = json.loads(resource_str)

        # quel est le type de ressource?
        resource_type = payload_dict['resourceType'] if 'resourceType' in payload_dict else 'None'
        self.log_info('Resource type: ' + resource_type)

        # c'est un paquet?
        if resource_type == 'Bundle':
            obj = bundle.Bundle(**payload_dict)
            # filrer le paquet
            for entry in obj.entry:
                if entry.resource.resource_type == 'Patient':
                    self.log_info('Filtering a patient')
                    entry.resource = patient.Patient(**json.loads(self.filter_patient_resource(entry.resource.json())))

        elif resource_type == 'Patient':
            # filtrer le patient
            obj = patient.Patient(**json.loads(self.filter_patient_resource(resource_str)))
        else:
            return resource_str

        return obj.json()

Ajouter un identifiant pour se connecter à l'interface FHIR REST - dans ce cas, ne considérer qu'une authentification de base

Ajouter un registre de service - dans ce cas, ne considérer qu'une authentification de base

- configurer un service HTTP

- saisir le chemin d'accès au serveur FHIR

- saisir l'URL du service FHIR

- utiliser l'identifiant profilé

Ajouter un "HS.FHIRServer.Interop.HTTPOperation"

Choisissez le nom du service

Tester le client FHIR

Tracer le résultat du test

Nous concluons cette série d'articles SMART On FHIR avec Auth0 et le référentiel FHIR d'InterSystems IRIS en passant en revue notre application développée en Angular 16.

Rappelons à quoi ressemble l'architecture définie pour notre solution:

Notre application qui servira de front-end correspond à la deuxième colonne et comme vous pouvez le voir, elle sera en charge de deux choses:

1. Redirigez la demande de connexion vers Auth0 et recevez la réponse.
2. Envoyez et recevez la réponse des requêtes via REST envoyées au serveur FHIR.

Angular

Angular est un cadre d'application web développé en TypeScript, open source, maintenu par Google, utilisé pour créer et maintenir des applications web mono-page. Cette conception "applications web mono-page" permet de concevoir des applications beaucoup plus dynamiques pour l'utilisateur. Comme nous l'avons déjà expliqué dans le premier article, nous allons utiliser le serveur NGINX comme serveur d'application et reverse proxy qui évitera les problèmes dérivés de CORS en modifiant les en-têtes d'appel pour qu'ils correspondent à ceux du serveur.

Conception de l'application

Nous avons conçu notre application avec Angular Material pour simuler la conception d'une application mobile. Dans notre exemple, l'application est destinée à enregistrer une série de données de patients telles que la fréquence cardiaque, la pression artérielle et le poids et pour cela nous allons envoyer deux types de ressources FHIR à notre serveur, la première sera de type Patient avec laquelle l'utilisateur enregistrera ses données ; La seconde correspondra à la ressource Observation dans laquelle nous enverrons chacun des types de données que nous allons envoyer.

Cette application permettra à l'utilisateur de voir un graphique de l'évolution des données enregistrées.

Écran de connexion

Lorsque l'utilisateur accède à l'itinéraire https:\\localhost, l'écran initial s'affichera à partir duquel on peut demander à se connecter.

En cliquant sur le bouton de connexion, l'application redirigera automatiquement l'utilisateur vers la page Auth0 activée pour l'API configurée:

Après avoir introduit notre nom d'utilisateur et notre mot de passe, Auth0 nous demandera d'autoriser l'application à accéder à nos données. Une fois l'accès aux données confirmé, Auth0 nous redirigera vers l'adresse URL que nous avons indiqué lors du processus de configuration. Une fois le jeton d'accès généré, la bibliothèque Auth0 se chargera de l'inclure dans l'en-tête de tous les appels que nous lançons au serveur. On peut le voir dans l'image suivante :

Écran initial

Une fois connecté, la première communication avec notre serveur FHIR permettra de demander les informations disponibles pour l'utilisateur connecté. Pour cela, nous utiliserons une requête par paramètre en envoyant un appel GET du type suivant:

https://localhost:8443/smart/fhir/r5/Patient?email=lperezra%40intersystems.com

La réponse du serveur sera une ressource de type Bundle (paquet) avec les informations suivantes:

{
    "resourceType":"Bundle",
    "id":"8c5b1efd-cfdd-11ee-a06b-0242ac190002",
    "type":"searchset",
    "timestamp":"2024-02-20T10:48:14Z",
    "total":0,
    "link":[
        {
            "relation":"self",
            "url":"https://localhost:8443/smart/fhir/r5/Patient?email=lperezra%40intersystems.com"
        }
    ]
}

Comme nous pouvons le voir, nous avons un total de 0 patients avec cette adresse e-mail, donc notre application nous montrera un écran initial à partir duquel nous pouvons enregistrer nos données.

Comme vous pouvez le voir, le champ email est déjà rempli avec l'email de l'utilisateur connecté, car comme vous l'avez vu dans la requête initiale, il va être utilisé comme identifiant. Une fois le formulaire rempli, nous allons envoyer un appel du type suivant via POST:

https://localhost:8443/smart/fhir/r5/Patient

With the message body formed by a Patient resource:

{
    "resourceType":"Patient",
    "birthDate":"1982-03-08",
    "gender":"male",
    "identifier":[
        {
            "type":{
                "text":"ID"
            },
            "value":"12345678A"
        }
    ],
    "name":[
        {
            "family":"PÉREZ RAMOS",
            "given":[
                "LUIS ÁNGEL"
                ]
        }
    ],
    "telecom":[
        {
            "system":"phone",
            "value":"600102030"
        },
        {
            "system":"email",
            "value":"lperezra@intersystems.com"
        }
    ]
}

Les données du patient étant enregistrées sur notre serveur, la requête du patient renvoie maintenant un résultat, ce qui nous permet d'enregistrer les différentes données d'observation. Voyons à quoi ressemble l'écran initial:

Observations screen

De la même manière que nous avons envoyé les données du patient, nous enverrons les résultats d'observation à partir de leurs écrans spécifiques:

Pour chaque ressource envoyée au serveur, l'application ajoute un nouveau point dans le diagramme:

Pour ce faire, elle lancera une requête au serveur demandant les ressources type Observation (résultats d'observation) appartenant à l'utilisateur:

https://localhost/smart/fhir/r5/Observation?patient=Patient/1

Et le serveur retournera à nouveau une ressource type Bundle (paquet) avec tous les résultats d'observations enregistrés pour le patient:

Avec le résultat obtenu, l'application extrait toutes les valeurs numériques et construit les diagrammes pertinents.

Conclusion

Comme vous l'avez vu dans cet article et dans les deux précédents, la conception et la création d'applications SMART On FHIR n'est pas très complexe et nous permet de construire rapidement et de manière agile des applications qui profitent de toutes les fonctionnalités disponibles sur notre serveur FHIR.

Une application de ce type ne requiert pas la mise au point d'un back-end complexe pour gérer les opérations type CRUD sur les données et, grâce à l'utilisation d'OAuth2, il n'est pas nécessaire de gérer les utilisateurs à partir de l'application, cette fonctionnalité étant déléguée à Auth0 ou au serveur d'authentification et d'autorisation choisi par l'utilisateur.

Avec SMART On FHIR, nous pouvons, d'une manière simple et aisée, mettre les outils nécessaires à la gestion des données cliniques à la disposition des patients et des professionnels de la santé.

TMerci infiniment pour votre attention!

Dans l'article précédent, nous avons présenté l'architecture de notre projet SMART On FHIR, il est donc temps de passer aux choses sérieuses et de commencer à configurer tous les éléments qui seront nécessaires.

Nous commençons avec Auth0.

Configuration de l'Auth0

Commençons par créer un compte Auth0 avec un email valide, une fois enregistré il nous faut créer notre première application, et nous le ferons à partir du menu de gauche:

Dans notre exemple, l'application sera de type application web monopage car il s'agit d'une application développée dans Angular 16. Nous sélectionnons cette option et cliquons sur Create (Créer).

Dans l'écran suivant, il faut définir les champs suivants:

• Adresses URL de rappel autorisées: https://localhost
• Adresses URL de déconnexion autorisées: https://localhost
• Serveurs web autorisés: https://localhost
• Autorisation de l'authentification croisée: cochée: Checked
• Origines autorisées (CORS): https://localhost

ATTENTION! Les adresses URL doivent toutes être HTTPS, c'est l'une des exigences pour les connexions OAuth2.

Avec cela, nous avons configuré les adresses URL dont Auth0 a besoin pour rediriger l'utilisateur après le processus d'authentification et d'autorisation. Si vous voyez les URL, elles n'ont pas de port défini, c'est parce qu'avec le déploiement du projet Angular dans Docker via NGINX, nous avons indiqué qu'il sera accessible via le port HTTPS par défaut, 443. Vous pouvez mettre le nom qui vous convient le mieux.

Pour la configuration ultérieure de notre projet Angular, indiquez les valeurs que nous trouvons à la fois dans Domain et Client ID (identifiant de domaine et identifiant de client).

Notre application étant configurée, il est temps de définir l'API qui recevra les requêtes de notre application Angular et nous le ferons à nouveau à partir du menu de gauche:

Cette option nous montrera un nouvel écran pour saisir toutes les données nécessaires:

Pour se connecter correctement, il vous faudra définir un identifiant pour l'API qui sera ensuite utilisé par l'application Angular comme "environnement". Comme vous pouvez le voir, il est recommandé de saisir une adresse URL, mais il n'est pas nécessaire que cette adresse soit fonctionnelle, puisqu'elle ne servira que d'identifiant. Dans notre cas, nous pouvons définir:

https://localhost/smart/fhir/r5

Enfin, nous configurons un algorithme de signature RS256 et passons à l'onglet Permissions, où nous définissons le périmètre de FHIR pour les utilisateurs connectés

Si vous souhaitez approfondir le sujet des contextes FHIR, vous pouvez consulter l'URL de la page officielle en cliquant ici. Pour notre exemple, nous avons défini le périmètre de l'utilisateur/*.* qui permet à l'utilisateur validé d'effectuer des opérations CRUD sur toutes les ressources du serveur FHIR.

Parfait! Nous venons de configurer notre compte Auth0 pour qu'il fonctionne comme un serveur OAuth2.

Configuration de l'application Angular

Je souhaiterais développer l'application en Angular 17, qui introduit pas mal de changements, mais malheureusement la documentation associée à Auth0 et ses bibliothèques ne sont que pour Angular 16, j'ai donc décidé de suivre un chemin facile et je l'ai développée dans la version 16.

Pour configurer notre projet Angular, il suffit d'ouvrir la page app.module.ts et de rechercher le fragment de code suivant:

Examinons la signification de chaque paramètre à configurer:

• domain: correspond à la valeur Domain générée lors de la création de notre application dans Auth0.
• clientId: identique à ce qui précède, mais avec la valeur Client ID générée.
• audience: correspond à l'URL que nous avons configuré comme identifiant de notre API.
• uri: avec cette valeur, nous indiquons à la bibliothèque TypeScript Auth0 d'intercepter tous les appels que nous faisons aux adresses URL qui contiennent cette URI et d'inclure l'Access_token qu'Auth0 renverra lorsque nous validerons (en ajoutant le paramètre Authorization à l'en-tête de l'appel: Bearer....).

Une fois ces valeurs modifiées, notre application Angular est configurée pour fonctionner avec Auth0. Dans le prochain article, nous verrons plus en détail comment nous invoquerons Auth0 depuis notre interface utilisateur.

Configuration d'InterSystems IRIS for Health

Ce projet est configuré pour installer automatiquement le serveur FHIR pendant le processus de déploiement, afin de nous épargner une étape. Dans notre cas, nous avons défini l'URI/smart/fhir/r5 comme point de terminaison de notre serveur FHIR. Pour ceux d'entre vous qui ne sont pas familiers avec la terminologie FHIR, r5 fait référence à la dernière version de FHIR, disponible depuis des mois sur IRIS.

Pour configurer notre instance IRIS, nous devons d'abord démarrer notre Docker et déployer les 3 conteneurs disponibles dans le projet. Il nous suffira d'exécuter la commande suivante dans le terminal depuis la racine du projet:

docker-compose up -d --build

Cela nous permettra de construire et d'exécuter les conteneurs contenus dans le projet. Pour les utilisateurs de Windows, si vous utilisez Docker Desktop, un écran comme celui-ci devrait s'afficher:

Voici nos 3 conteneurs:

• iris: avec l'instance IRIS dans laquelle se trouve notre serveur FHIR.
• smart-ui: avec le code de notre application web déployée depuis le serveur NGINX configuré à son tour pour que toutes les connexions se fassent via SSL avec les certificats associés.
• webgateway: avec son serveur Apache associé (rappelons que depuis la version officielle 2023.1, le serveur Web privé (Private Web Server) a été supprimé, bien qu'il soit encore disponible dans les versions communautaires).

Passerelle Web

Je le répète encore une fois, pour utiliser OAuth2 avec notre serveur FHIR, il est obligatoire que toutes les connexions se fassent par HTTPS, le serveur Apache doit donc être configuré pour n'accepter que les appels de ce type, si vous jetez un œil au fichier /webgateway/shared/CSP.conf vous pouvez voir la section suivante responsable de la configuration du serveur Apache:

# SECTION SSL #
# Activez SSL/TLS (https://) sur le serveur Web Apache.
# L'utilisateur est responsable de fournir des certificats SSL valides.
LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so
LoadModule headers_module /usr/lib/apache2/modules/mod_headers.so
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile "/webgateway-shared/apache_webgateway.cer"
SSLCertificateKeyFile "/webgateway-shared/apache_webgateway.key"
Header add ACCESS-CONTROL-ALLOW-ORIGIN "*"
</VirtualHost>

Vous pouvez voir comment la configuration est faite pour que les appels passent par le port 443, c'est-à-dire que l'adresse URL de notre webgateway serait https://webgateway et que tous les appels que nous lançons depuis notre application web vers notre serveur FHIR devraient être redirigés vers cette adresse URL (webgateway est le masque attribué au réseau du conteneur Docker créé par ce dernier).

Tous les appels au serveur depuis Angular viendront avec l'URL https://localhost/smart/fhir/r5 et le serveur NGINX sera en charge de rediriger ce localhost vers le webgateway. Si vous ouvrez le fichier /smart-ui/nginx.conf, vous pourrez voir la configuration suivante:

Dans cette configuration, nous voyons que notre application web écoutera sur le port 443 et que tous les appels qui ont la valeur / dans l'URL seront gérés par l'application Angular, tandis que ceux qui incluent /smart/ seront redirigés vers https://webgateway.

Faites attention avec proxy_set_header, qui sera la valeur qui permettra d'éviter les maux de tête avec CORS. Pour éviter que notre passerelle Web ne rejette les appels provenant d'autres serveurs, nous devons modifier la valeur de l'en-tête Host pour la configurer avec l'adresse de la passerelle Web.

InterSystems IRIS

Maintenant il faut configurer notre IRIS pour qu'il fonctionne avec Auth0, pour cela il faut le configurer en tant que client OAuth2. Pour ce faire, il suffit d'accéder au Portail de gestion avec les identifiants superuser/SYS et d'accéder à l'option System Administration > Security > OAuth 2.0 > Client, puis de cliquer sur Create Server Description et de remplir l'endpoint Issuer avec la valeur Domain que nous avons obtenue au moment de la création de l'application à Auth0 (https://[MY_DOMAIN]/). Soyez prudent! L'adresse URL doit se terminer par"/". Enfin, nous sélectionnons la configuration SSL/TLS et cliquons sur Discover and Save (Découvrir et Sauvegarder):

Notre instance IRIS récupère automatiquement les informations dont elle a besoin auprès d'Auth0.

Il suffit d'ajouter un client au serveur précédemment configuré. En appuyant sur Client Configuration (Configuration client), nous accéderons à un nouvel écran où nous définirons le nom de l'application et du client. Ce nom de client sera celui que nous utiliserons plus tard pour configurer notre serveur FHIR.

Serveur FHIR

The last step to finish the configuration of our project is to tell our FHIR server which OAuth2 client will be used for the connection. Pour accéder à la configuration, nous allons ouvrir le Portail de Gestion et sélectionnez Health > FHIR > Configuration du FHIR > Configuration du serveur et nous allons ouvrir le point de terminaison qui s'affiche à l'écran, nous irons à la fin de celui-ci et cliquerons sur Edit (Modifier). Enfin, nous ajoutons dans le champ de nom du client OAuth OAuth Client Name le nom avec lequel nous avons créé la configuration du client.

Conclusion

Nous avons déjà configuré notre projet, dans le prochain article nous étudierons comment notre application Angular interagit avec chacun des acteurs.

Je vous remercie de votre attention!

Introduction

J'ai récemment participé à une séance pratique formidablement organisée par @Patrick Jamieson au cours de laquelle une application Angular a été configurée avec un serveur IRIS FHIR en suivant les protocoles définis par SMART On FHIR. J'ai trouvé cela très intéressant et j'ai donc décidé de développer ma propre application Angular et de profiter ainsi de ce que j'ai appris en la publiant au sein de la communauté.

SMART On FHIR

Voyons ce que Google nous dit sur SMART On FHIR:

SMART on FHIR est un standard de données qui permet aux applications d'accéder aux informations contenues dans les systèmes de dossiers médicaux électroniques (DME). Un développeur d'application peut écrire une application unique qui se connecte à n'importe quel système de DME adopté selon ce standard.

Les principaux concepts que nous allons traiter dans SMART On FHIR sont:

• Authentification et autorisation déléguées par OAuth2 ou OpenID.
• Gestion des ressources FHIR dans le contexte défini.
• Communications HTTPS.

Architecture de notre projet

Pour cet exercice, nous avons configuré les éléments suivants à la fois dans Docker et dans le service Auth0:

• Une application développée en Angular qui servira de front-end, et qui a été développée selon les principes de SMART On FHIR.
• Serveur web NGINX et serveur proxy inverse qui publiera notre application développée en Angular.
• Auth0 nous fournira le service d'authentification et d'autorisation via OAuth2.
• InterSystems IRIS dans lequel nous déploierons notre serveur FHIR et auquel nous nous connecterons via la passerelle Web incluant un serveur Apache déjà disponible dans son image Docker.

Auth0

Bien que nous puissions déléguer l'authentification et l'autorisation des utilisateurs à un autre serveur IRIS déployé à cet effet, nous allons à cette occasion utiliser le service offert par Auth0.

Qu'est-ce que Auth0?

Auth0 est un service qui nous fournit l'ensemble du mécanisme pour gérer l'autorisation et l'authentification de nos plateformes.

Auth0 dispose également de bibliothèques spécifiques dans différentes langues pour pouvoir s'intégrer facilement à n'importe quel projet, c'est donc toujours une option à prendre en compte pour les développements basés sur SMART On FHIR.

Intégration d'Auth0 dans notre application

L'utilisation d'OAuth2 étant une condition requise pour l'utilisation de SMART On FHIR, cela implique l'inclusion d'un serveur OAuth2 dans le processus habituel d'authentification, d'autorisation et d'accès à l'application. Dans le diagramme suivant, nous pouvons voir la route suivie par les informations envoyées au système avec le service Auth0:

Analysons le processus:

• Login request:
  1. Demande de connexion: L'utilisateur accède à l'application dans son navigateur Internet et demande à se connecter.
  2. Demande de connexion: L'application Angular transmet la demande au service Auth0.
  3. Page de connexion: Auth0 envoie une redirection vers votre propre page au navigateur Internet de l'utilisateur.
• Authentification sur Auth0:
  1. Informations d'identification de l'utilisateur: L'utilisateur saisit son adresse électronique et le mot de passe avec lequel il est enregistré dans Auth0.
  2. Authentification & Autorisation: Auth0 valide les données et génère un Access_token comprenant le contexte attribué à l'utilisateur.
  3. Réponse & redirection de l'Access_token: Auth0 redirige la réponse vers l'URL indiquée dans la configuration du projet en incluant le jeton généré.
  4. Écran du patient: L'application Angular montre à l'utilisateur la page d'enregistrement de ses données personnelles.
• Enregistrement des Ressources FHIR:
  1. Enregistrer le patient: l'utilisateur remplit le formulaire avec ses données, et l'application Angular transforme le formulaire en un objet JSON au format de la ressource FHIR Patient.
  2. Requête POST: l'application Angular envoie un appel HTTP POST au serveur FHIR déployé dans IRIS en incluant l'access_token comme jeton d'authentification dans l'en-tête de la requête
  3. Réponse POST: après avoir reçu la demande POST via Web Gateway, IRIS vérifie la validité du jeton et le contexte de la demande. Si tout est correct, il valide la ressource reçue et l'enregistre sur le serveur FHIR, en renvoyant un HTTP 201 indiquant la création de la nouvelle ressource et en joignant l'identifiant attribué à la nouvelle ressource dans un en-tête.
  4. Opération réussie: L'application Angular redirigera l'utilisateur vers l'écran présentant les principales fonctionnalités.

Une fois connecté, la bibliothèque Auth0 intégrée au projet sera chargée d'intercepter toutes les requêtes que nous faisons à notre serveur FHIR pour y inclure le jeton d'accès reçu d'Auth0.

A venir...

Dans les prochains articles, nous allons voir comment il faut configurer chacun des systèmes concernés et enfin comment les connecter à notre application Angular. Pour ceux qui ne peuvent pas attendre, vous pouvez consulter le README.md présent sur le GitHub associé au projet OpenExchange lié à cet article, qui explique en détail comment configurer à la fois Auth0 et InterSystems IRIS.