The status property covers the general availability of the resource, not the current value which may be covered by the operationStatus, or by a schedule/slots if they are configured for the location.

Note that FHIR strings SHALL NOT exceed 1,048,576 (1024*1024) characters in size

Indicates whether the location is still in use.

The operational status covers operation values most relevant to beds (but can also apply to rooms/units/chairs/etc. such as an isolation unit/dialysis chair). This typically covers concepts such as contamination, housekeeping, and other activities like maintenance.

Codes may be defined very casually in enumerations or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information.

The operational status if the location (where typically a bed/room).

A list of alternate names that the location is known as, or was known as, in the past.

Over time locations and organizations go through many changes and can be known by different names.

For searching knowing previous names that the location was known by can be very useful.

There are no dates associated with the alias/historic names, as this is not intended to track when names were used, but to assist in searching so that older names can still result in identifying the location.

Description of the Location, which helps in finding or referencing the place.

Humans need additional information to verify a correct location has been identified.

Systems are not required to have markdown support, so the text should be readable without markdown processing. The markdown syntax is GFM - see https://github.github.com/gfm/

Indicates whether a resource instance represents a specific location or a class of locations.

When using a Location resource for scheduling or orders, we need to be able to refer to a class of Locations instead of a specific Location.

This is labeled as a modifier because whether or not the location is a class of locations changes how it can be used and understood.

Indicates whether a resource instance represents a specific location or a class of locations.

Physical location.

If locations can be visited, we need to keep track of their address.

Additional addresses should be recorded using another instance of the Location resource, or via the Organization.

Physical form of the location, e.g. building, room, vehicle, road, virtual.

For purposes of showing relevant locations in queries, we need to categorize locations.

Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.

Physical form of the location.

Plain text narrative that identifies the resource in addition to the resource reference.

This is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it.

Another Location of which this Location is physically a part of.

For purposes of location, display and identification, knowing which locations are located within other locations is important.

References SHALL be a reference to an actual FHIR resource, and SHALL be resolvable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.

Collection of characteristics (attributes).

These could be such things as is wheelchair accessible.

A custom attribute that could be provided at a service (e.g. Wheelchair accessibiliy).

What days/times during a week is this location usually open, and any exceptions where the location is not available.

This type of information is commonly found published in directories and on websites informing customers when the facility is available.

Specific services within the location may have their own hours which could be shorter (or longer) than the locations hours.

Systems may choose to render availability differently than it is exchanged on the interface. For example, rather than "Mon, Tue, Wed, Thur, Fri from 9am-12am; Mon, Tue, Wed, Thur, Fri from 1pm-5pm" as would be implied by two availableTime repetitions, an application could render this information as "Mon-Fri 9-12am and 1-5pm".

The availableStartTime is the opening time, and the availableEndTime is the closing time.

Connection details of a virtual service (e.g. shared conference call facility with dedicated number/details).

There are two types of virtual meetings that often exist:

• a persistent, virtual meeting room that can only be used for a single purpose at a time,
• and a dynamic virtual meeting room that is generated on demand for a specific purpose.

Implementers may consider using Appointment.virtualService for virtual meeting rooms that are generated on-demand.

Technical endpoints providing access to services operated for the location.

Organizations may have different systems at different locations that provide various services and need to be able to define the technical connection details for how to connect to them, and for what purpose.

References SHALL be a reference to an actual FHIR resource, and SHALL be resolvable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.