Location — Physical or virtual place of care

From a hospital room to a patient's home, from an ambulance to a vaccination drive-through: Location models any place where care is delivered, with geolocation and hierarchy.

Purpose of the resource

Location represents a place where services are provided and resources and participants may be stored, found, contained, or accommodated. The resource covers a variety of granularities: a hospital campus, a building, a floor, a room, a bed, an emergency vehicle, a patient's home, even a geographical area (health region) or a virtual platform.

Location supports both specific instances ("room 312 in building A") and generalised types ("a standard examination room") through the mode element. Physical hierarchy is materialised by partOf — a Location points to the Location that contains it.

Key fields

Instance vs kind

The mode field is central to using Location correctly. Two values:

• instance — a unique, identifiable physical place. Example: room 312, bed B, building A. This is what an Encounter or Appointment references.
• kind — a generic place type. Example: "a standard ECG examination room". Useful for modelling resource categories without a physical instance.

In practice, an Encounter must reference a Location with mode=instance. A kind Location is used upstream to configure Schedules, services, and equipment inventories.

JSON example

HL7 canonical Location example: second floor of the Burgers University Medical Center South Wing, formerly used by Psychiatry, with address, GPS coordinates and opening hours.

{
  "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" }]
}

Worth pointing out in this example:

• mode=instance — this is a real, unique floor.
• form = "Wing" — the physical form.
• operationalStatus reuses the HL7 v2-0116 table inherited from the PL (Person Location) segment.
• partOf points to Location/2, the parent building.
• position enables proximity search (?near=42.25,-83.69|10|km).

Hierarchy through partOf

Location is typically used as a tree: campus → building → floor → department → room → bed. Each level points to its parent via partOf. This hierarchy enables:

• Transitive search: GET /Location?partof=Location/campus-x returns everything on campus X.
• Ancestor inclusion: GET /Location/room-312?_include=Location:partof:iterate walks up the chain to the root.
• Containment modelling: room is part of floor, which is part of building, and so on.

Common pitfalls

• Confusing address and position — the postal address does not give latitude/longitude: position must be populated separately. Many FHIR servers don't auto-geocode.
• Encounter pointing to Location[mode=kind] — invalid. An Encounter references a specific physical instance, not a category.
• Cycle in partOf — the tree must be acyclic. A Location A pointing to B pointing to A breaks aggregations.
• status=active on a kind Location — fuzzy semantics. Administrative status is designed for physical instances.
• Multiple position — cardinality is 0..1. For large places (campus), pick a central point.
• Hours without timezone — availableStartTime is of type time without timezone. Timezone context is carried by address or the attached Organization.
• Virtual Location without virtualService — when form=vi, virtualService with connection details must be populated.

Related resources

• Organization — the organisation managing the Location (managingOrganization).
• Encounter — references one or more Locations to model an intra-stay journey (room A → OR → recovery → room B).
• Appointment, Schedule — may reference a Location as actor or appointment place.
• HealthcareService — care service offered at a Location.
• Endpoint — technical access points attached to the Location.

See also: the FHIR R5 index.