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.

Location — Lieu de soin physique ou virtuel

De la chambre d'hospitalisation au domicile patient, en passant par l'ambulance et le drive de vaccination : Location modélise tout endroit où des soins sont fournis, avec géolocalisation et hiérarchie.

Objet de la ressource

Location représente un endroit où des services sont fournis et où des ressources matérielles et des participants peuvent être stockés, trouvés, contenus ou hébergés. La ressource couvre une variété de granularités : un campus hospitalier, un bâtiment, un étage, une chambre, un lit, un véhicule d'urgence, le domicile d'un patient, voire une zone géographique (région sanitaire) ou une plateforme virtuelle.

Location supporte aussi bien les instances spécifiques (« chambre 312 du bâtiment A ») que les types généralisés (« une salle d'examen standard »), via l'élément mode. La hiérarchie physique est matérialisée par partOf — un Location pointe vers le Location qui le contient.

Champs clés

ChampTypeCardinalitéRôle
identifierIdentifier[]0..*Identifiants externes (code SIRH, FINESS, OID local…).
statuscode0..1Statut administratif : active, suspended, inactive.
operationalStatusCoding0..1Statut opérationnel du lit ou de la chambre (v2-0116 : U/O/K/I/H/C — Unoccupied, Occupied, Contaminated…).
namestring0..1Nom officiel (visible utilisateur).
aliasstring[]0..*Noms alternatifs ou abréviations.
descriptionmarkdown0..1Description détaillée (markdown).
modecode0..1instance = lieu réel et unique. kind = type générique.
typeCodeableConcept[]0..*Type fonctionnel (hôpital, pharmacie, ambulance, ICU… — v3-RoleCode).
contactExtendedContactDetail[]0..*Téléphones, e-mails, contacts associés au lieu.
addressAddress0..1Adresse postale (structurée : line, city, state, postalCode, country).
formCodeableConcept0..1Forme physique : bâtiment, étage, chambre, lit, véhicule, virtuel… (location-physical-type).
positionBackboneElement0..1Coordonnées GPS : longitude, latitude, altitude (degrés WGS84).
managingOrganizationReference(Organization)0..1Organisation responsable de la maintenance du lieu.
partOfReference(Location)0..1Lieu parent dans la hiérarchie physique.
characteristicCodeableConcept[]0..*Caractéristiques (PMR accessible, anti-allergène, isolement infectieux…).
hoursOfOperationAvailability[]0..*Horaires d'ouverture/disponibilité.
virtualServiceVirtualServiceDetail[]0..*Détails de service virtuel (URL Zoom, salle Teams…) si form = vi (virtual).
endpointReference(Endpoint)[]0..*Endpoints techniques rattachés (FHIR, HL7 v2, DICOM…).

Mode instance vs kind

Le champ mode est central pour le bon usage de Location. Deux valeurs :

  • instance — un lieu physique unique et identifiable. Exemple : chambre 312, lit B, bâtiment A. C'est ce qu'on référence depuis un Encounter ou un Appointment.
  • kind — un type de lieu générique. Exemple : « une salle d'examen ECG standard ». Sert à modéliser des catégories de ressources sans instance physique.

En pratique, un Encounter doit référencer un Location en mode=instance. Un Location kind est utilisé en amont pour le paramétrage des Schedule, des services, des inventaires d'équipement.

Exemple JSON

Exemple canonique HL7 de Location : deuxième étage de la South Wing du Burgers University Medical Center, anciennement utilisé par la psychiatrie, avec adresse, coordonnées GPS et horaires d'ouverture.

json location-example.json
{
  "resourceType": "Location",
  "id": "1",
  "identifier": [{
    "value": "B1-S.F2"
  }],
  "status": "active",
  "operationalStatus": {
    "system": "http://terminology.hl7.org/CodeSystem/v2-0116",
    "code": "U",
    "display": "Unoccupied"
  },
  "name": "South Wing, second floor",
  "alias": ["BU MC, SW, F2", "Burgers University Medical Center, South Wing, second floor"],
  "description": "Second floor of the Old South Wing, formerly in use by Psychiatry",
  "mode": "instance",
  "type": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-RoleCode",
      "code": "HOSP",
      "display": "Hospital"
    }]
  }],
  "contact": [{
    "telecom": [{
      "system": "phone",
      "value": "2328",
      "use": "work"
    }, {
      "system": "fax",
      "value": "2329",
      "use": "work"
    }, {
      "system": "email",
      "value": "second wing admissions"
    }]
  }],
  "address": {
    "use": "work",
    "line": ["Galapagosweg 91, Building A"],
    "city": "Den Burg",
    "postalCode": "9105 PZ",
    "country": "NLD"
  },
  "form": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/location-physical-type",
      "code": "wi",
      "display": "Wing"
    }]
  },
  "position": {
    "longitude": -83.6945691,
    "latitude": 42.25475478,
    "altitude": 0
  },
  "managingOrganization": { "reference": "Organization/f001" },
  "partOf": { "reference": "Location/2" },
  "hoursOfOperation": [{
    "availableTime": [{
      "daysOfWeek": ["mon", "tue", "wed", "thu", "fri"],
      "availableStartTime": "09:00:00",
      "availableEndTime": "17:00:00"
    }]
  }],
  "endpoint": [{ "reference": "Endpoint/example" }]
}

À noter dans cet exemple :

  • mode=instance — c'est un étage réel et unique.
  • form = « Wing » (aile) — la forme physique.
  • operationalStatus reprend la table HL7 v2-0116 héritée du segment PL (Person Location).
  • partOf pointe vers Location/2 qui est le bâtiment parent.
  • position permet la recherche par proximité géographique (?near=42.25,-83.69|10|km).

Hiérarchie via partOf

Location s'utilise typiquement en arborescence : campus → bâtiment → étage → département → chambre → lit. Chaque niveau pointe vers son parent via partOf. Cette hiérarchie permet :

  • Recherche transitive : GET /Location?partof=Location/campus-x renvoie tout ce qui est sur le campus X.
  • Inclusion ascendante : GET /Location/room-312?_include=Location:partof:iterate remonte toute la chaîne jusqu'à la racine.
  • Modélisation par contenance : la chambre est part of l'étage, qui est part of le bâtiment, etc.

Pièges courants

  • Confondre address et position — l'adresse postale ne donne pas la latitude/longitude : il faut renseigner position séparément. Beaucoup de serveurs FHIR ne géocodent pas automatiquement.
  • Encounter qui pointe vers un Location[mode=kind] — invalide. Un Encounter référence une instance physique précise, pas une catégorie.
  • Boucle dans partOf — l'arborescence doit être acyclique. Une Location A qui pointe vers B qui pointe vers A casse les agrégations.
  • status=active sur un Location kind — sémantique floue. Le statut administratif est conçu pour les instances physiques.
  • Plusieurs position — la cardinalité est 0..1. Pour les lieux étendus (campus), il faut choisir un point central.
  • Horaires sans timezoneavailableStartTime est de type time sans timezone. Le contexte timezone est porté par l'address ou la Organization rattachée.
  • Location virtuelle sans virtualService — si form=vi, il faut renseigner virtualService avec les détails de connexion.

Ressources liées

  • Organization — la structure qui gère le Location (managingOrganization).
  • Encounter — référence un ou plusieurs Location pour modéliser le parcours intra-séjour (chambre A → bloc op → SSPI → chambre B).
  • Appointment, Schedule — peuvent référencer un Location comme acteur ou comme lieu du RDV.
  • HealthcareService — service de soin offert dans un Location.
  • Endpoint — points techniques d'accès rattachés au Location.

Voir aussi : l'index FHIR R5.