The technical details of an endpoint that can be used for electronic services, such as for web services providing XDS.b, a REST endpoint for another FHIR server, or a s/Mime email address. This may include any security context information.

Identifier for the organization that is used to identify the endpoint across multiple disparate systems.

The endpoint status represents the general expected availability of an endpoint.

This element is labeled as a modifier because the status contains codes that mark the endpoint as not currently valid. Temporary downtimes or other unexpected short-term changes in availability would not be represented in this property.

A coded value that represents the technical details of the usage of this endpoint, such as what WSDLs should be used in what way. (e.g. XDS.b/DICOM/cds-hook).

For additional connectivity details for the protocol, extensions will be used at this point, as in the XDS example. If there are multiple payload types or mimetypes they are all applicable for all connection types, and all have the same status.

A friendly name that this endpoint can be referred to with.

The description of the endpoint and what it is for (typically used as supplemental information in an endpoint directory describing it's usage/purpose).

The type of environment(s) exposed at this endpoint (dev, prod, test, etc).

The organization that manages this endpoint (even if technically another organization is hosting this in the cloud, it is the organization associated with the data).

This property is not typically used when searching for Endpoint resources for usage. The typical usage is via the reference from an applicable Organization/Location/Practitioner resource, which is where the context is provided. Multiple Locations may reference a single endpoint, and don't have to be within the same organization resource, but most likely within the same organizational hierarchy.

Contact details for a human to contact about the endpoint. The primary use of this for system administrator troubleshooting.

The interval during which the endpoint is expected to be operational.

Temporary downtimes or other short-term changes in availability would not be represented in this property.

The payload type describes the acceptable content that can be communicated on the endpoint.

The payloadFormat describes the serialization format of the data, where the payloadType indicates the specific document/schema that is being transferred; e.g. DischargeSummary or CarePlan.

The mime type to send the payload in - e.g. application/fhir+xml, application/fhir+json. If the mime type is not specified, then the sender could send any content (including no content depending on the connectionType).

Sending the payload has obvious security consequences. The server is responsible for ensuring that the content is appropriately secured.

The uri that describes the actual end-point to connect to.

For rest-hook, and websocket, the end-point must be an http: or https: URL; for email, a mailto: url, for sms, a tel: url, and for message the endpoint can be in any form of url the server understands (usually, http: or mllp:). The URI is allowed to be relative; in which case, it is relative to the server end-point (since there may be more than one, clients should avoid using relative URIs)

This address will be to the service base, without any parameters, or sub-services or resources tacked on.

E.g. for a WADO-RS endpoint, the url should be "https://pacs.hospital.org/wado-rs"

and not "https://pacs.hospital.org/wado-rs/studies/1.2.250.1.59.40211.12345678.678910/series/1.2.250.1.59.40211.789001276.14556172.67789/instances/...".

Additional headers / information to send as part of the notification.

Exactly what these mean depends on the channel type. The can convey additional information to the recipient and/or meet security requirements.