ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

Endpoint — Adresse technique de service

La carte d'identité d'un service FHIR : URL, protocole, payloads acceptés, environnement. Le bottin technique des plateformes interopérables.

Objet de la ressource

Endpoint décrit une adresse technique avec laquelle communiquer : serveur FHIR REST, MLLP HL7 v2, e-mail Direct Project, IHE XDS, SMTP, DICOM, WebSocket. Une Organization, une Location ou une PractitionerRole peuvent référencer un ou plusieurs Endpoint via endpoint[] — découverte par le client.

Champs clés

ChampTypeCardinalitéRôle
identifierIdentifier[]0..*Identifiants externes.
statuscode1..1Obligatoire. active, suspended, error, off, test, entered-in-error.
connectionTypeCodeableConcept[]1..*Obligatoire. Type de connexion (hl7-fhir-rest, hl7-fhir-msg, dicom-wado-rs, secure-email…).
namestring0..1Nom lisible.
descriptionstring0..1Description.
environmentTypeCodeableConcept[]0..*prod, test, dev, staging, training.
managingOrganizationReference(Organization)0..1Organisation responsable.
contactContactPoint[]0..*Contact technique.
periodPeriod0..1Validité.
payloadTypeCodeableConcept[]0..*Types de payload acceptés.
payloadMimeTypecode[]0..*MIME types acceptés.
addressurl1..1Obligatoire. URL technique.
headerstring[]0..*En-têtes HTTP requis.

Exemple JSON

Endpoint FHIR R5 production d'un hôpital :

json endpoint-fhir-prod.json
{
  "resourceType": "Endpoint",
  "id": "ep-hospital-1-fhir",
  "status": "active",
  "connectionType": [{
    "system": "http://terminology.hl7.org/CodeSystem/endpoint-connection-type",
    "code": "hl7-fhir-rest"
  }],
  "name": "FHIR R5 — Hospital 1",
  "description": "Endpoint FHIR R5 principal de l'hôpital 1, base de production",
  "environmentType": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/endpoint-environment",
      "code": "prod",
      "display": "Production"
    }]
  }],
  "managingOrganization": { "reference": "Organization/hospital-1" },
  "contact": [{
    "system": "email",
    "value": "interop@hospital-1.example.org"
  }],
  "period": {
    "start": "2024-01-01"
  },
  "payloadType": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/endpoint-payload-type",
      "code": "any"
    }]
  }],
  "payloadMimeType": ["application/fhir+json", "application/fhir+xml"],
  "address": "https://fhir.hospital-1.example.org/r5"
}

Pièges courants

  • Endpoint sans environmentType — confondre prod et test est une cause classique de fuites de PHI vers des environnements non sécurisés.
  • HTTP non-HTTPS — un Endpoint FHIR doit toujours être en HTTPS ; la spec recommande TLS 1.2+.
  • Pas de contact — quand l'endpoint tombe, qui prévenir ? Indispensable.
  • payloadMimeType incohérent avec connectionType — un endpoint hl7-fhir-rest qui annonce application/json simple (au lieu de application/fhir+json) crée des bugs Content-Negotiation.
  • Confondre avec CapabilityStatement — Endpoint = juste l'URL et le type, CapabilityStatement = ce que le serveur sait faire à cette URL.

Ressources liées