Location is an entity that can be used to understand where resources are present or where data entry has taken place. Care is designed to use locations for a variety of use-cases, primarily patient management.

Locations are abstract hierarchal concepts ie you can have infinite nesting within. Patients can be assigned to locations or beds within locations and permissions can be written at a location level.

The primary requirements for Locations are

A location can have the following spec, Its derived from its FHIR spec available here.

{
  "id": "f7adec73-a67e-4dd5-bded-9e978a7e8395", // Unique ID of the location in care 
  "status": "active", // Derived from FHIR
  "operational_status": "C", // Derived from FHIR
  "name": "test parent location", // Name of the location, unqiue to the level it is at
  "description": "sdfsdf", // Description of the location
  "location_type": {}, // Code, Refer to FHIR
  "form": "bu", // Refer to FHIR
  "mode": "kind", // kind - a type of location, like a building or a ward / instance - an instance of a location like Bed 1 or ICU 1
  "has_children": false, // Does this location have any children
  "availability_status": "available", // available if the location is not actively associated to an encounter
}

Locations can be connected to multiple organizations, the users under than organizations can then access the encounters tied to the location under the roles they are attached to the organization.

Locations access scoping is very complicated, for this reason, access control for location is done via an async process that is triggered whenever a location’s organization changes ( Might be very rare ), This process has an SLA of 5 minutes under normal load. This must be taken into account whenever working with locations.

Locations can further be used to connect devices, create schedules for reservations and so on.. These will be explained in the spec concerning them. the location spec only deals with the location itself.