Comment utiliser les APIs EHR ?

EN BREF

Les API des DSE (Dossiers de Santé Électroniques) accèdent aux dossiers de santé des patients stockés dans des systèmes comme Epic, Cerner et Athenahealth. La plupart des DSE modernes prennent en charge FHIR (Fast Healthcare Interoperability Resources), un format standard pour les données de santé. L'authentification utilise OAuth 2.0 avec les extensions SMART on FHIR. Pour les tests, utilisez Apidog pour valider les ressources FHIR, tester par rapport à des environnements de test (sandboxes) et vous assurer que votre intégration gère correctement les données des patients avant de vous connecter aux systèmes de production.

Introduction

Les Dossiers de Santé Électroniques contiennent tout ce qui concerne les soins aux patients : diagnostics, médicaments, résultats de laboratoire, allergies et plans de traitement. Les hôpitaux, les cliniques et les systèmes de santé stockent ces données dans des plateformes DSE comme Epic, Cerner et Athenahealth.

Développer des applications de santé signifie se connecter à ces systèmes. Vous ne pouvez pas demander aux hôpitaux d'exporter des fichiers CSV. Vous avez besoin d'API. Mais les API de santé sont différentes des API web typiques. Elles traitent des informations de santé protégées (ISP) et doivent se conformer à des réglementations comme la HIPAA aux États-Unis.

La bonne nouvelle : la plupart des fournisseurs de DSE prennent désormais en charge FHIR, un format d'API standard. La mauvaise nouvelle : l'authentification, l'autorisation et le mappage des données restent complexes.

Si vous développez des intégrations de santé, Apidog vous aide à tester les ressources FHIR, à valider les structures de données et à garantir que votre application gère correctement les données des patients. Vous pouvez effectuer des tests sur des environnements de test publics avant de travailler avec de véritables systèmes hospitaliers.

Testez les API FHIR avec Apidog - gratuit

À la fin de ce guide, vous serez en mesure de :

Comprendre les types et la structure des ressources FHIR
Vous authentifier avec SMART on FHIR
Interroger les données démographiques et cliniques des patients
Créer et mettre à jour des ressources patient
Tester avec des environnements de test DSE

Comprendre FHIR

FHIR (Fast Healthcare Interoperability Resources) est la norme moderne pour les API de santé. Il définit :

Ressources : Types de données pour les concepts de santé (Patient, Observation, Médication)
API REST : Opérations standard sur les ressources
Formats : Représentations JSON et XML

Structure de l'URL de base

https://ehr.example.com/fhir/r4/{resource-type}/{id}

Exemple :

GET https://ehr.example.com/fhir/r4/Patient/123

Version de FHIR

La plupart des DSE utilisent FHIR R4 (Release 4). Certains systèmes plus anciens utilisent DSTU2. Ce guide couvre la version R4.

Types de ressources

Ressource	Objectif
Patient	Données démographiques et administratives
Praticien	Prestataires de soins de santé
Organisation	Hôpitaux, cliniques
Observation	Résultats de laboratoire, signes vitaux
MedicationRequest	Prescriptions
Condition	Diagnostics, problèmes
Encounter	Visites, admissions
DocumentReference	Documents cliniques
AllergyIntolerance	Allergies et réactions indésirables

Structure des ressources FHIR

Exemple de ressource Patient

{
  "resourceType": "Patient",
  "id": "123",
  "active": true,
  "name": [
    {
      "use": "official",
      "family": "Smith",
      "given": ["John", "Michael"]
    }
  ],
  "gender": "male",
  "birthDate": "1985-03-15",
  "address": [
    {
      "use": "home",
      "line": ["123 Main St"],
      "city": "Boston",
      "state": "MA",
      "postalCode": "02101",
      "country": "USA"
    }
  ],
  "telecom": [
    {
      "system": "phone",
      "value": "555-123-4567",
      "use": "home"
    },
    {
      "system": "email",
      "value": "john.smith@example.com"
    }
  ],
  "identifier": [
    {
      "system": "http://hospital.example.org/mrn",
      "value": "MRN-123456"
    }
  ]
}

Exemple de ressource Observation

{
  "resourceType": "Observation",
  "id": "obs-123",
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "vital-signs",
          "display": "Vital Signs"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "8480-6",
        "display": "Systolic blood pressure"
      }
    ]
  },
  "subject": {
    "reference": "Patient/123"
  },
  "effectiveDateTime": "2026-03-24T09:30:00Z",
  "valueQuantity": {
    "value": 120,
    "unit": "mmHg",
    "system": "http://unitsofmeasure.org",
    "code": "mm[Hg]"
  }
}

Authentification avec SMART on FHIR

SMART on FHIR étend OAuth 2.0 pour les soins de santé. Il gère le contexte du patient et les portées (scopes) spécifiques aux DSE.

Flux OAuth pour l'accès patient

Étape 1 : Obtenir l'URL d'autorisation

GET https://ehr.example.com/fhir/r4/.well-known/smart-configuration

La réponse inclut :

{
  "authorization_endpoint": "https://ehr.example.com/oauth2/authorize",
  "token_endpoint": "https://ehr.example.com/oauth2/token",
  "scopes_supported": [
    "patient/*.read",
    "patient/*.write",
    "user/*.read",
    "launch/patient"
  ]
}

Étape 2 : Rediriger l'utilisateur pour l'autorisation

https://ehr.example.com/oauth2/authorize?
  response_type=code&
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https://yourapp.com/callback&
  scope=patient/*.read&
  state=random_state_value

Étape 3 : Échanger le code contre un jeton

curl -X POST "https://ehr.example.com/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=AUTHORIZATION_CODE" \
  -d "redirect_uri=https://yourapp.com/callback" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET"

Réponse :

{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "patient/*.read",
  "patient": "123"
}

Le champ `patient` vous donne le contexte de l'ID du patient.

Portées SMART

Portée	Accès
`patient/*.read`	Lire toutes les données du patient
`patient/Patient.read`	Lire uniquement les données démographiques du patient
`patient/Observation.read`	Lire uniquement les observations
`user/*.read`	Lire toutes les données pour l'utilisateur autorisé
`launch/patient`	Le DSE lance votre application avec le contexte du patient

Interrogation des données patient

Obtenir les données démographiques du patient

curl -X GET "https://ehr.example.com/fhir/r4/Patient/123" \
  -H "Authorization: Bearer ACCESS_TOKEN"

Rechercher des observations

curl -X GET "https://ehr.example.com/fhir/r4/Observation?patient=123&category=vital-signs" \
  -H "Authorization: Bearer ACCESS_TOKEN"

La réponse est un Bundle :

{
  "resourceType": "Bundle",
  "type": "searchset",
  "total": 5,
  "entry": [
    {
      "resource": { ... Observation resource ... }
    }
  ]
}

Paramètres de recherche courants

# Résultats de laboratoire par plage de dates
GET /Observation?patient=123&category=laboratory&date=gt2026-01-01

# Code LOINC spécifique
GET /Observation?patient=123&code=http://loinc.org|8480-6

# Médicaments
GET /MedicationRequest?patient=123&status=active

# Conditions (diagnostics)
GET /Condition?patient=123&clinical-status=active

# Rencontres (Consultations)
GET /Encounter?patient=123&type=AMB

Pagination

Les grands ensembles de résultats sont paginés :

GET /Observation?patient=123&_count=20

La réponse inclut des liens :

{
  "link": [
    {
      "relation": "next",
      "url": "https://ehr.example.com/fhir/r4/Observation?patient=123&_count=20&page=2"
    }
  ]
}

Création et mise à jour des ressources

Créer une observation

curl -X POST "https://ehr.example.com/fhir/r4/Observation" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -H "Content-Type: application/fhir+json" \
  -d '{
    "resourceType": "Observation",
    "status": "final",
    "code": {
      "coding": [{
        "system": "http://loinc.org",
        "code": "8480-6",
        "display": "Systolic blood pressure"
      }]
    },
    "subject": {
      "reference": "Patient/123"
    },
    "effectiveDateTime": "2026-03-24T09:30:00Z",
    "valueQuantity": {
      "value": 118,
      "unit": "mmHg",
      "system": "http://unitsofmeasure.org",
      "code": "mm[Hg]"
    }
  }'

Mettre à jour un patient

curl -X PUT "https://ehr.example.com/fhir/r4/Patient/123" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -H "Content-Type: application/fhir+json" \
  -d '{
    "resourceType": "Patient",
    "id": "123",
    "name": [{
      "family": "Smith",
      "given": ["John", "Michael"]
    }],
    "telecom": [{
      "system": "phone",
      "value": "555-999-8888",
      "use": "home"
    }]
  }'

Spécificités des fournisseurs de DSE

Epic

L'API FHIR d'Epic est disponible dans la plupart des grands hôpitaux.

URL de base : https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/
Environnement de test (Sandbox) : https://fhir.epic.com/test/api/FHIR/R4/
Documentation : https://fhir.epic.com

Epic exige l'enregistrement de l'application sur sa place de marché pour un accès en production.

Cerner

Cerner (Oracle Health) utilise le FHIR standard avec quelques extensions.

URL de base : https://fhir-myrecord.cerner.com/r4/{tenant-id}
Environnement de test (Sandbox) : https://fhir-deprecated.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d
Documentation : https://docs.oracle.com/en/health/health-cerner/

Athenahealth

Athenahealth propose des API FHIR et des API héritées.

URL de base : https://api.platform.athenahealth.com/fhir/r4/{practice-id}
Environnement de test (Sandbox) : Disponible via le programme développeur
Documentation : https://docs.athenahealth.com

Tester avec Apidog

Les API de santé nécessitent des tests rigoureux. Les données des patients sont sensibles.

1. Utiliser des environnements de test publics

Testez par rapport aux environnements de test FHIR publics :

# HAPI FHIR (open source)
https://hapi.fhir.org/baseR4

# Environnement de test SMART Health IT
https://launch.smarthealthit.org

2. Valider les ressources FHIR

pm.test('Resource is valid Patient', () => {
  const response = pm.response.json()
  pm.expect(response.resourceType).to.eql('Patient')
  pm.expect(response.id).to.exist
  pm.expect(response.name).to.be.an('array')
})

pm.test('Observation has required fields', () => {
  const resource = pm.response.json()
  pm.expect(resource.status).to.exist
  pm.expect(resource.code).to.exist
  pm.expect(resource.subject).to.exist
})

3. Tester le flux d'authentification

Enregistrer la configuration SMART comme environnement :

AUTHORIZATION_ENDPOINT: https://ehr.example.com/oauth2/authorize
TOKEN_ENDPOINT: https://ehr.example.com/oauth2/token
CLIENT_ID: your_client_id
CLIENT_SECRET: your_client_secret
SCOPE: patient/*.read

Testez les API FHIR avec Apidog - gratuit

Considérations de conformité

HIPAA

Aux États-Unis, les applications de santé doivent être conformes à la HIPAA. Cela affecte :

Transmission des données : Utiliser TLS 1.2+
Stockage des données : Chiffrer au repos
Contrôle d'accès : Journalisation d'audit, accès minimal nécessaire
Accord d'associé commercial (BAA) : Requis avec les fournisseurs de DSE

Sécurité SMART on FHIR

Les jetons expirent (généralement 1 heure)
Jetons de rafraîchissement disponibles pour des sessions prolongées
Le contexte patient est lié à la portée du jeton
La déconnexion nécessite la révocation du jeton

Minimisation des données

Ne demandez que les portées dont vous avez besoin :

Bon : patient/Observation.read
À éviter : patient/*.read sauf si nécessaire

Erreurs courantes et solutions

401 Non autorisé

Cause : Jeton expiré ou invalide.

Solution : Rafraîchissez le jeton en utilisant le jeton de rafraîchissement de l'autorisation initiale.

403 Interdit

Cause : La portée n'inclut pas la ressource demandée.

Solution : Vérifiez vos portées. Si vous avez besoin de plus d'accès, demandez des portées supplémentaires lors de l'autorisation.

404 Introuvable

Cause : Le patient ou la ressource n'existe pas.

Solution : Vérifiez l'ID de la ressource. Assurez-vous que le patient est accessible avec le contexte patient de votre jeton actuel.

422 Entité non traitable

Cause : La validation de la ressource FHIR a échoué.

Solution : Vérifiez les champs obligatoires et les terminologies :

{
  "resourceType": "OperationOutcome",
  "issue": [{
    "severity": "error",
    "code": "required",
    "details": {
      "text": "Observation.status is required"
    }
  }]
}

Alternatives et comparaisons

Caractéristique	Epic	Cerner	Athenahealth	OpenEMR
FHIR R4	✓	✓	✓	Partiel
SMART on FHIR	✓	✓	✓	Non
Accès à l'environnement de test	✓	✓	Limité	Auto-hébergement
Documentation API	Excellente	Bonne	Bonne	Basique
Part de marché	Grands hôpitaux	Systèmes de santé	Petits cabinets	Open source

Epic et Cerner dominent les grands systèmes de santé. Athenahealth dessert les cabinets plus petits. OpenEMR est open source mais son support API est limité.

Cas d'utilisation réels

Portail patient. Un système de santé construit un portail patient qui extrait des données d'Epic. Les patients consultent leurs résultats de laboratoire, leurs médicaments et leurs rendez-vous à venir. Le portail utilise les API FHIR avec l'authentification SMART on FHIR.

Recherche clinique. Une entreprise pharmaceutique doit identifier les patients éligibles pour les essais cliniques. Elle interroge les API FHIR de plusieurs systèmes hospitaliers pour trouver les patients correspondant aux critères, avec une gestion appropriée du consentement.

Surveillance à distance. Une entreprise de télésanté intègre les signes vitaux rapportés par les patients aux systèmes DSE. Les observations sont créées via l'API FHIR et sont immédiatement visibles par les cliniciens dans Epic.

En résumé

Voici ce que vous avez appris :

FHIR est la norme pour les API de santé
Les ressources représentent des concepts de santé tels que les patients et les observations
SMART on FHIR gère OAuth avec le contexte patient
Chaque fournisseur de DSE a des détails d'implémentation spécifiques
Testez avec des environnements de test avant la production

Vos prochaines étapes :

Explorez l'environnement de test public HAPI FHIR
Comprenez les types de ressources FHIR pour votre cas d'utilisation
Inscrivez-vous aux programmes développeur des DSE
Testez avec Apidog en utilisant des données patient fictives
Mettez en œuvre la gestion des données conforme à la HIPAA

Testez les API FHIR avec Apidog - gratuit

button

FAQ

Quelle est la différence entre FHIR et HL7 v2 ?HL7 v2 est une norme de messagerie plus ancienne utilisée dans les interfaces hospitalières. FHIR est une norme d'API REST moderne. La plupart des nouvelles intégrations utilisent FHIR, mais HL7 v2 est encore courant dans les systèmes hérités.

Ai-je besoin d'un BAA pour utiliser les API des DSE ?Oui, si vous traitez des ISP. Des Accords d'Associé Commercial (BAA) sont requis entre les entités couvertes et les associés commerciaux. Vérifiez auprès de l'équipe de conformité du fournisseur de DSE.

Comment puis-je accéder à l'API FHIR d'Epic ?Inscrivez-vous sur la place de marché App Orchard d'Epic. Pour les tests en environnement de test, utilisez leur environnement de test public. L'accès en production nécessite l'approbation de l'hôpital.

Qu'est-ce qu'un contexte patient ?Les jetons SMART on FHIR incluent un identifiant patient. Vos appels d'API sont limités aux données de ce patient. Cela garantit que les applications ne peuvent accéder qu'aux données que le patient a autorisées.

Puis-je écrire des données dans les DSE ?Oui, mais avec des limitations. La plupart des DSE permettent de créer des observations et de mettre à jour les données démographiques des patients. La saisie de diagnostics ou de médicaments nécessite généralement l'approbation du support à la décision clinique.

Comment gérer les codes de terminologie ?FHIR utilise des terminologies standard :

LOINC pour les tests de laboratoire et les observations
SNOMED CT pour les concepts cliniques
CIM-10 pour les diagnostics
RxNorm pour les médicaments

Utilisez ces systèmes lors de la création de ressources.

Qu'en est-il des soins de santé internationaux ?FHIR est mondial. Chaque pays peut avoir des guides d'implémentation. Les États-Unis utilisent les profils US Core. Vérifiez les spécifications de votre région.