🔥 FHIR FUSE : FHIR à la manière Unix

Depuis des décennies, les systèmes Unix reposent sur une philosophie simple mais puissante : tout est un fichier. Cette abstraction permet à de petits utilitaires ciblés de se combiner harmonieusement. Besoin de traiter des données ? Enchaînez une commande après l'autre. Utilisez grep, sed, jq, diff et les autres outils standard que vous connaissez déjà.

Et si travailler avec des données FHIR suivait la même voie Unix ? Pas d'API complexes, pas de maux de tête liés à l'authentification, pas d'outillage personnalisé — juste votre éditeur de texte préféré, des commandes Unix standard et un dossier plein de ressources FHIR. FHIR-FUSE apporte cette philosophie Unix à l'interopérabilité en santé.

Résumé rapide

FHIR-FUSE associe les données de santé aux concepts du système de fichiers, permettant d'utiliser des outils Unix plutôt que des clients API
La découverte dynamique, le chargement différé et des abstractions intuitives simplifient l'exploration de FHIR
Idéal pour le développement, l'apprentissage, l'analyse de données et les migrations — pas pour les systèmes de production à forte charge
Apporte des décennies de sagesse de composition Unix à l'interopérabilité en santé

Le défi du hackathon de Noël

Chaque année, notre hackathon de Noël réunit des passionnés de la santé pour explorer des idées audacieuses qui repoussent les limites des technologies de l'information en santé. Cette année, nous nous sommes posé une question provocatrice : Et si nous pouvions éliminer les frictions entre les développeurs et les données FHIR ?

Dans la pratique, les développeurs en santé passent d'innombrables heures à écrire des clients API, à gérer l'authentification, à gérer la pagination, à analyser les réponses JSON et à déboguer les requêtes HTTP. Mais et si rien de tout cela n'était nécessaire ? Et si vous pouviez simplement faire un cd dans votre serveur FHIR et commencer à travailler ?

Le résultat fut FHIR-FUSE : une interface de système de fichiers pour les serveurs FHIR construite sur FUSE (Filesystem in Userspace). Vous pouvez explorer le projet entièrement libre sur GitHub.

Repenser FHIR comme un système de fichiers

Travailler avec FHIR implique habituellement des API, des clients et de la logique de requêtes — mais les données elles-mêmes possèdent déjà une structure claire. L'intuition centrale derrière FHIR-FUSE est simple : les ressources FHIR se mappent naturellement aux concepts du système de fichiers.

Types de ressources (Patient, Observation, Encounter) → Répertoires
Ressources individuelles → Fichiers JSON
Identifiants de ressources → Noms de fichiers
Opérations CRUD → Opérations sur les fichiers (créer, lire, mettre à jour, supprimer)
Requêtes de recherche → Répertoires spéciaux
Historique des ressources → Dossiers de versions cachés
Opérations → Fichiers spéciaux

Ce modèle mental est intuitif pour quiconque a déjà travaillé avec des fichiers. Au lieu d'apprendre encore une autre API, vous tirez parti des connaissances que vous possédez déjà.

La structure du système de fichiers

Lorsque vous montez un serveur FHIR avec FHIR-FUSE, vous voyez une structure de système de fichiers virtuel comme celle-ci :

./mnt/
├── README.md                          # Documentation
├── Patient/                           # Resource type directory
│   ├── patient-001.json               # Individual resources
│   ├── patient-002.json
│   ├── .patient-001/                  # Hidden history folder
│   │   ├── 1.json                     # Version 1
│   │   ├── 2.json                     # Version 2
│   │   └── 3.json                     # Version 3
│   └── _search/                       # Search directory
│       └── name=Smith/                # Search query
│           └── Patient/
│               └── patient-003.json
├── Observation/
│   ├── observation-001.json
│   └── _search/
└── ViewDefinition/
    ├── patient_demographics.json
    └── $run/                          # Operation directory
        └── patient_demographics.csv   # Operation results

Chaque répertoire et fichier dans cette structure de système de fichiers virtuel est généré dynamiquement en fonction des capacités du serveur FHIR, ou créé par des fichiers ou répertoires de l'utilisateur.

Principes de conception

Traiter un serveur FHIR comme un système de fichiers semble simple en théorie, mais cela soulève des questions pratiques. Comment gérer différents serveurs, de grands ensembles de données et des schémas en évolution ? FHIR-FUSE répond à ces questions par quelques principes de conception fondamentaux.

1. Découverte dynamique

FHIR-FUSE ne code pas en dur les types de ressources. Il interroge plutôt le CapabilityStatement du serveur au démarrage pour découvrir les ressources disponibles. Cela signifie qu'il fonctionne avec n'importe quel serveur FHIR R4 sans configuration — qu'il s'agisse d'Aidbox, de HAPI FHIR ou d'une implémentation personnalisée.

pub async fn fetch_capability_statement(
    client: &Client,
    fhir_base_url: &str,
) -> anyhow::Result<ServerCapabilities> {
    let url = format!("{}/metadata", fhir_base_url);
    let response = client.get(&url).send().await?;
    let capability_statement: CapabilityStatement = response.json().await?;
    ServerCapabilities::from_capability_statement(capability_statement)
}

Le système de fichiers crée automatiquement des répertoires pour chaque type de ressource pris en charge, rendant les capacités du serveur immédiatement visibles et explorables.

2. Chargement différé

Les ensembles de données en santé peuvent être massifs. Charger toutes les ressources d'entrée de jeu serait prohibitivement lent et gourmand en mémoire. FHIR-FUSE utilise le chargement différé partout :

Les listes de répertoires ne sont récupérées que lorsque vous faites un ls sur un répertoire
Le contenu des ressources n'est chargé que lorsque vous lisez un fichier
Les résultats de recherche sont mis en cache pendant quelques secondes pour éviter les requêtes redondantes
Les versions de l'historique sont récupérées à la demande lorsque vous accédez aux dossiers cachés

Cela maintient le système de fichiers réactif même lorsqu'on travaille avec des serveurs contenant des millions de ressources.

3. Abstractions intuitives

L'interface du système de fichiers associe les concepts FHIR à des opérations de fichiers familières.

Créer une ressource :

# Create a new patient with basic demographics
echo '{"resourceType":"Patient","name":[{"family":"Smith"}]}' > ./mnt/Patient/new-patient.json

Lire une ressource :

# View a patient record
cat ./mnt/Patient/patient-001.json | jq .

Mettre à jour une ressource :

# Edit with your favorite editor
vim ./mnt/Patient/patient-001.json

# Or use jq for programmatic updates
jq '.active = true' ./mnt/Patient/patient-001.json > temp.json
mv temp.json ./mnt/Patient/patient-001.json

Supprimer une ressource :

# Remove a patient record
rm ./mnt/Patient/patient-001.json

Pas de clients HTTP, pas de jetons d'authentification dans vos scripts — juste des outils Unix standard.

4. La recherche comme création de répertoire

L'un des choix de conception les plus élégants de FHIR-FUSE est la façon dont il gère la recherche FHIR. Au lieu d'un langage de requête ou d'une commande séparée, vous créez un répertoire dont le nom contient les paramètres de recherche :

# Search for female patients named Smith
mkdir -p "./mnt/Patient/_search/name=Smith&gender=female"

# View search results
ls "./mnt/Patient/_search/name=Smith&gender=female/Patient/"
cat "./mnt/Patient/_search/name=Smith&gender=female/Patient/patient-003.json"

Le nom du répertoire est la requête. Lorsque vous créez le répertoire, FHIR-FUSE exécute la recherche et le remplit avec les résultats. En conséquence :

Rend les recherches découvrables (vous pouvez voir les recherches passées avec ls)
Permet la mise en cache des résultats de recherche (le répertoire persiste jusqu'à ce que vous le supprimiez)
Prend en charge les requêtes complexes avec plusieurs paramètres
Gère les paramètres _include naturellement (les résultats apparaissent dans des sous-répertoires par type de ressource)

5. Les opérations comme répertoires spéciaux

L'une des parties les plus importantes de FHIR est constituée par les opérations. Certaines d'entre elles peuvent être représentées comme des répertoires dans le système de fichiers. Pour tester cette hypothèse, nous avons essayé d'implémenter l'opération $run comme un répertoire qui exécute une ViewDefinition et retourne les résultats.

# List available ViewDefinitions
ls ./mnt/ViewDefinition/

# Execute a ViewDefinition
touch "./mnt/ViewDefinition/\$run/patient_demographics.json"

# Read the results
cat "./mnt/ViewDefinition/\$run/patient_demographics.json" | jq .

# Get CSV output
touch "./mnt/ViewDefinition/\$run/patient_demographics.csv"
cat "./mnt/ViewDefinition/\$run/patient_demographics.csv"

La commande touch déclenche l'exécution, et la lecture du fichier retourne les résultats. Différentes extensions de fichier permettent de demander différents formats de sortie.

Perspectives d'implémentation

Jusqu'ici, nous nous sommes concentrés sur le comportement de FHIR-FUSE de l'extérieur : comment les ressources FHIR apparaissent comme des fichiers, comment les recherches fonctionnent comme des répertoires, et comment les outils Unix standard peuvent être utilisés pour explorer les données.

Sous le capot, faire fonctionner cette abstraction nécessite une coordination minutieuse entre la sémantique du système de fichiers et les API HTTP de FHIR. Cette section présente les principales décisions d'implémentation qui permettent à FHIR-FUSE de rester réactif, prévisible et compatible avec différents serveurs FHIR.

Architecture du système de fichiers virtuel

FHIR-FUSE est construit sur FUSE (Filesystem in Userspace), qui permet d'implémenter un système de fichiers entièrement en espace utilisateur sans modifications du noyau. L'architecture est composée de plusieurs éléments clés :

1. Index des inœuds

Chaque fichier et répertoire dans le système de fichiers possède un numéro d'inœud unique. Nous maintenons un index en mémoire qui associe les inœuds aux entrées du système de fichiers virtuel :

pub enum VFSEntry {
    Directory(Directory),             // /Patient
    TextFile(TextFile),               // /README.md
    FHIRResource(FHIRResource),       // /Patient/pt-1.json
    ResourceVersion(ResourceVersion), // /Patient/.pt-1/1.json
    SearchPath(SearchPath),           // /Patient/_search
    SearchQuery(SearchQuery),         // /Patient/_search/gender=female
    SearchResultGroup(SearchResultGroup),
    OperationPath(OperationPath),     // /ViewDefinition/$run
    OperationExecution(OperationExecution),
}

Cette énumération capture tous les types d'entrées possibles dans le système de fichiers, chacun ayant son propre comportement et ses propres attributs.

2. Listes de répertoires dynamiques

Lorsque vous listez un répertoire, FHIR-FUSE génère dynamiquement le listing en fonction du type de répertoire :

Répertoire racine : Affiche les répertoires de types de ressources issus du capability statement
Répertoire de type de ressource : Récupère les ressources du serveur FHIR (avec pagination)
Répertoire de recherche : Affiche les requêtes de recherche passées
Répertoire de requête de recherche : Affiche les sous-répertoires de types de ressources avec les résultats
Répertoire d'historique : Affiche toutes les versions d'une ressource spécifique

3. Stratégie de mise en cache

Pour équilibrer réactivité et fraîcheur des données, FHIR-FUSE implémente une mise en cache basée sur le temps :

const TTL: Duration = Duration::from_secs(30);
const CACHE_DURATION: Duration = Duration::from_secs(5);

En pratique, cela signifie :

Les listes de répertoires sont mises en cache pendant 5 secondes
Les attributs des fichiers (taille, date de modification) ont une durée de vie de 30 secondes
Les résultats de recherche sont mis en cache jusqu'à une actualisation explicite
Le contenu des ressources est toujours récupéré à jour lors de la lecture pour garantir l'exactitude

4. Récupération parallèle des ressources

Lors du chargement d'un répertoire de type de ressource, FHIR-FUSE récupère plusieurs pages en parallèle :

pub async fn fetch_resources_parallel(
    client: &Client,
    fhir_base_url: &str,
    resource_type: &str,
) -> anyhow::Result<Vec<Value>> {
    // Discover pagination structure from first page
    let bundle = fetch_first_page(client, fhir_base_url, resource_type).await?;

    // Generate all page URLs
    let page_urls = generate_page_urls(&bundle, MAX_PAGES);

    // Fetch all pages concurrently
    let results = stream::iter(page_urls)
        .map(|url| fetch_page_by_url(&client, &url))
        .buffer_unordered(MAX_CONCURRENT_FETCHES)
        .collect()
        .await;

    // Combine results
    combine_resources(results)
}

Cette approche améliore considérablement les performances lors du travail avec de grands ensembles de données, en récupérant jusqu'à 10 pages simultanément.

Cas d'usage concrets

L'interface du système de fichiers déverrouille des flux de travail difficiles ou maladroits à exprimer avec des clients API traditionnels. Au lieu d'écrire des scripts personnalisés autour de requêtes HTTP, les développeurs peuvent réutiliser des opérations standard sur les fichiers et des outils Unix pour déplacer, inspecter, versionner et transformer des données FHIR.

Les exemples ci-dessous illustrent comment cette approche transforme les tâches quotidiennes, des migrations ponctuelles au développement et au débogage.

Migration de données

# Migrate all patient records from one server to another
cp -r /mnt/source-server/Patient/* /mnt/destination-server/Patient/

Sauvegarde et contrôle de version

# Create timestamped backup of all observations
tar -czf observations-backup-$(date +%Y%m%d).tar.gz /mnt/fhir/Observation/

# Track patient data changes with git
cd /mnt
git init
git add fhir/Patient/*.json
git commit -m "Initial patient data snapshot"

Analyse de données avec des outils standard

# Count all FHIR resources
find /mnt/fhir -name "*.json" | wc -l

# Extract patient family names and count occurrences
cat /mnt/fhir/Patient/*.json | jq -r '.name[0].family' | sort | uniq -c

# Search for patients with diabetes diagnoses with grep
grep -r "diabetes" /mnt/fhir/Condition/

# Analyze patient demographics (ID, birthDate, gender) with awk
cat /mnt/fhir/Patient/*.json | jq -r '[.id, .birthDate, .gender] | @csv' | \
  awk -F, '{print $3}' | sort | uniq -c

Scripts et automatisation

# Activate all patient records with a batch operation
for file in /mnt/fhir/Patient/*.json; do
  jq '.active = true' "$file" > "$file.tmp" && mv "$file.tmp" "$file"
done

# Monitor patient directory for recent changes
watch -n 5 'ls -l /mnt/fhir/Patient/ | tail -10'

# Export patient demographics as CSV
cat /mnt/fhir/Patient/*.json | \
  jq -r '[.name[0].family, .name[0].given[0], .birthDate] | @csv' | \
  csvtool col 1,2,3 - | \
  head -20

Développement et tests

# Inspect test patient data during development
cat /mnt/fhir/Patient/test-patient-1.json | jq .

# Create reusable test fixtures from FHIR server
cp /mnt/fhir/Patient/example.json ./test/fixtures/

# Validate all patient JSON files for syntax errors
for file in /mnt/fhir/Patient/*.json; do
  jq empty "$file" 2>/dev/null || echo "Invalid JSON: $file"
done

Travailler avec l'historique des ressources

L'une des fonctionnalités les plus puissantes de FHIR-FUSE est l'accès à l'historique des versions de ressources via des répertoires cachés. Chaque fois qu'une ressource est mise à jour, les serveurs FHIR conservent les versions historiques. FHIR-FUSE les expose sous forme de fichiers dans des dossiers cachés .resource-id :

# View the current patient record
cat /mnt/fhir/Patient/patient-123.json

# List all historical versions of this patient
ls -la /mnt/fhir/Patient/.patient-123/
# Output:
# 1.json
# 2.json
# 3.json

# View how the patient record looked at version 1
cat /mnt/fhir/Patient/.patient-123/1.json

Comparer les versions avec diff standard

Une fois que les versions des ressources sont disponibles comme fichiers, vous pouvez immédiatement utiliser des outils diff familiers pour voir ce qui a changé entre les mises à jour — sans écrire de scripts personnalisés ni assembler manuellement des réponses API.

# See what changed between version 1 and version 2
diff /mnt/fhir/Patient/.patient-123/1.json \
     /mnt/fhir/Patient/.patient-123/2.json

# Compare an old version against the current record
diff /mnt/fhir/Patient/.patient-123/2.json \
     /mnt/fhir/Patient/patient-123.json

Utiliser difftastic pour de beaux diffs structurels

Difftastic est un outil de diff structurel qui comprend la syntaxe JSON et produit une sortie bien plus lisible que le diff traditionnel ligne par ligne. Au lieu de comparer des lignes, il met en évidence les changements sémantiques, rendant les différences plus faciles à analyser.

# Install difftastic
brew install difftastic  # macOS
# or: cargo install difftastic

# Compare versions with syntax-aware diffing
difft /mnt/fhir/Patient/.patient-123/1.json \
      /mnt/fhir/Patient/.patient-123/2.json

Exemple de sortie de difftastic :

Patient/patient-123.json
  {
    "resourceType": "Patient",
    "id": "patient-123",
-   "active": false,
+   "active": true,
    "name": [{
      "family": "Smith",
-     "given": ["John"]
+     "given": ["John", "Michael"]
    }],
+   "telecom": [{
+     "system": "phone",
+     "value": "+1-555-0123"
+   }],
    "birthDate": "1980-01-15"
  }

Analyse de la piste d'audit

Comme chaque version est un fichier ordinaire, il est facile d'écrire des scripts parcourant l'historique complet pour répondre à des questions de type audit : quand un champ a changé, qui l'a mis à jour, ou comment une ressource a évolué dans le temps.

# View when each version was last updated
for version in /mnt/fhir/Patient/.patient-123/*.json; do
  echo "=== $version ==="
  jq '.meta.lastUpdated' "$version"
done

# Track when the active status changed for a patient
for version in /mnt/fhir/Patient/.patient-123/*.json; do
  active=$(jq -r '.active' "$version")
  updated=$(jq -r '.meta.lastUpdated' "$version")
  echo "$updated: active=$active"
done

# Create a visual timeline of structural changes with difftastic
v1=/mnt/fhir/Patient/.patient-123/1.json
v2=/mnt/fhir/Patient/.patient-123/2.json
v3=/mnt/fhir/Patient/.patient-123/3.json

echo "Changes from v1 to v2:"
difft "$v1" "$v2"
echo -e "\nChanges from v2 to v3:"
difft "$v2" "$v3"

Cela rend le débogage des problèmes de données, la compréhension de l'évolution des ressources et l'audit de conformité considérablement plus simples. Au lieu de faire plusieurs appels API pour récupérer l'historique et comparer manuellement du JSON, vous pouvez utiliser des outils de système de fichiers familiers et des utilitaires de diff modernes.

Défis et compromis

La construction de FHIR-FUSE nous a enseigné de précieuses leçons sur le décalage d'impédance entre les API REST et les systèmes de fichiers. Bien que l'abstraction du système de fichiers soit puissante, elle comporte des contraintes inhérentes. Comprendre ces compromis vous aide à décider si FHIR-FUSE convient à votre cas d'usage.

1. Opérations asynchrones

L'un des premiers défis apparaît à la frontière entre les systèmes de fichiers et les API réseau. Les opérations sur les systèmes de fichiers sont traditionnellement synchrones, mais les appels à l'API FHIR sont asynchrones. Nous utilisons le runtime de Tokio pour combler cet écart :

struct FhirFuse {
    runtime: Arc<Runtime>,
    http_client: Client,
    // ...
}

// Block on async operations in FUSE callbacks
fn read(&mut self, ino: u64, ...) {
    let result = self.runtime.block_on(async {
        fetch_resource(&self.http_client, &self.fhir_base_url, resource_id).await
    });
    // ...
}

Ceci est approprié pour les flux de travail de développement où la latence réseau est acceptable. Les systèmes de production gérant un débit élevé bénéficient de clients API directs avec regroupement de connexions et opérations par lots.

2. Pagination et grands ensembles de données

Une autre limitation pratique provient de la façon dont les systèmes de fichiers gèrent les grands répertoires. Les serveurs FHIR ont souvent des milliers ou des millions de ressources. Nous limitons les listes de répertoires à 1 000 ressources par défaut pour maintenir la réactivité du système de fichiers. Lorsque vous travaillez avec des ensembles de données plus volumineux, les requêtes de recherche offrent un moyen plus évolutif de restreindre les résultats.

3. Sémantique d'écriture

Les opérations de création et de mise à jour conditionnelles de FHIR ne se mappent pas parfaitement aux écritures dans le système de fichiers. FHIR-FUSE adopte donc une sémantique pragmatique :

Écrire dans un nouveau fichier crée une ressource avec le nom du fichier comme identifiant
Écrire dans un fichier existant met à jour cette ressource
Le serveur peut rejeter des ressources invalides, ce qui entraîne l'échec des opérations d'écriture

4. Différences entre plateformes

Enfin, le comportement du système de fichiers lui-même varie selon la plateforme. FUSE fonctionne différemment sous Linux, macOS et d'autres plateformes. Les utilisateurs macOS ont besoin de macFUSE, et l'architecture de machine virtuelle de Docker Desktop empêche la propagation du montage vers l'hôte. FHIR-FUSE documente ces contournements et fournit des options de déploiement natif et conteneurisé.

Quand NE PAS utiliser FHIR-FUSE

Bien que FHIR-FUSE soit puissant pour certains flux de travail, il est important de comprendre ses limitations :

Pas pour les systèmes de production à forte charge

FHIR-FUSE n'est pas conçu pour les environnements de production à forte charge. Chaque opération sur le système de fichiers se traduit par des requêtes HTTP vers le serveur FHIR, ce qui introduit de la latence et une surcharge. Pour les systèmes de production gérant des milliers de requêtes simultanées, utilisez des clients API FHIR directs ou des trousses de développement qui peuvent implémenter le regroupement de connexions, le traitement par lots des requêtes et une logique de nouvelle tentative sophistiquée.

Limites d'évolutivité du système de fichiers

Cette limitation n'est pas propre à FHIR-FUSE — elle est inhérente à toute approche basée sur un système de fichiers. Les systèmes de fichiers peinent avec :

Les grandes listes de répertoires : Lister un répertoire contenant plus de 100 000 fichiers est lent sur n'importe quel système de fichiers
Les écritures simultanées : Plusieurs processus écrivant simultanément peuvent provoquer des conflits
Les contraintes de mémoire : Maintenir des index d'inœuds pour des millions de ressources consomme une quantité significative de mémoire

Si votre serveur FHIR contient des millions de ressources, l'interface du système de fichiers devient impraticable pour parcourir des types de ressources entiers. Les requêtes de recherche aident, mais elles ne constituent pas une solution complète.

Là où FHIR-FUSE brille vraiment : apprentissage et développement

Là où FHIR-FUSE brille vraiment, c'est dans le développement, l'apprentissage et l'exploration, où la facilité d'utilisation et la transparence comptent plus que le débit :

Apprendre FHIR : Les débutants peuvent explorer la structure des données FHIR sans apprendre les clients API
Flux de travail de développement : Inspecter rapidement les données de test, créer des données de test, déboguer les intégrations
Prototypage : Expérimenter rapidement avec des ressources FHIR en utilisant des outils familiers
Analyse de données : Requêtes et analyses ad hoc avec des utilitaires Unix standard
Scripts de migration : Migrations de données ponctuelles entre environnements de développement et de pré-production

Pour ces cas d'usage, la simplicité et l'intuitivité de l'interface du système de fichiers l'emportent largement sur les limitations de performance.

Exigences de plateforme

FHIR-FUSE nécessite la prise en charge de FUSE (Filesystem in Userspace), qui varie selon la plateforme :

Linux : Prise en charge native. FUSE est intégré au noyau et largement disponible. Il suffit d'installer les paquets fuse3 ou libfuse et vous êtes prêt.

macOS : Nécessite macFUSE avec des compromis de sécurité. Vous devez installer macFUSE, ce qui nécessite :

D'autoriser les extensions de noyau tierces dans les Préférences Système
Sur les Mac à puce Apple Silicon, de potentiellement désactiver certaines fonctionnalités de la Protection de l'intégrité du système (SIP)
D'accorder des autorisations de sécurité supplémentaires

Ceci est gérable sur les machines de développement, mais peut entrer en conflit avec les politiques de sécurité des entreprises.

Windows : FUSE est une technologie Unix/Linux et n'est pas nativement prise en charge sous Windows. Cependant, WSL2 (Windows Subsystem for Linux) pourrait fonctionner puisqu'il exécute un vrai noyau Linux. Théoriquement, FHIR-FUSE devrait fonctionner dans WSL2 avec FUSE installé. Si vous l'essayez, faites-le-nous savoir !

FreeBSD : Pris en charge. FreeBSD dispose d'une prise en charge native de FUSE via fusefs-libs.

Ce que nous avons appris

Le hackathon a validé notre hypothèse centrale : traiter les données FHIR comme des fichiers est intuitif et puissant. Les développeurs ont immédiatement compris comment interagir avec le système de fichiers sans lire la documentation. Les outils Unix standard ont « simplement fonctionné » pour les tâches courantes.

Plus important encore, nous avons découvert que la métaphore du système de fichiers révèle la structure des données FHIR d'une façon que la documentation des API ne permet pas. Parcourir les répertoires vous montre quels types de ressources existent, quelles ressources sont disponibles et comment elles se rapportent — le tout sans lire des spécifications ni faire des appels API.

Le projet a également mis en évidence la valeur de la superposition des abstractions. FUSE fournit l'interface du système de fichiers, Rust fournit la sécurité de la mémoire et les capacités asynchrones, et FHIR fournit le modèle de données. Chaque couche fait ce qu'elle fait de mieux.

Conclusion

FHIR-FUSE démontre que l'interopérabilité en santé n'a pas à être compliquée. En associant les concepts FHIR aux primitives du système de fichiers, nous tirons parti de décennies d'outillage Unix et des connaissances des développeurs.

L'interface du système de fichiers n'est pas destinée à remplacer les API FHIR — c'est un outil complémentaire qui simplifie considérablement certains flux de travail. Que vous migriez des données, analysiez des ressources, déboguiez des intégrations ou que vous exploriez simplement un serveur FHIR, FHIR-FUSE vous permet de travailler comme vous savez déjà le faire.

Parfois, la meilleure innovation consiste à rendre les choses complexes simples. Et si votre serveur FHIR n'était qu'un dossier sur votre ordinateur ? Maintenant, c'est possible.

Prêt à essayer FHIR-FUSE ? Le projet est entièrement libre et prêt à être exploré : Dépôt GitHub

En savoir plus sur Aidbox : Serveur FHIR Aidbox

Rejoignez la discussion : Communauté Health Samurai

Voir aussi : Les agents ne sont pas des humains.