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 whether the endpoint can currently be used for connections or why it can't be used.

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 its usage/purpose).

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

The organization that provides technical management services for this endpoint. This would be the organization that acts as the public help desk for when the endpoint is not functioning. It does NOT necessarily represent the organization who is the steward of data being provided/accepted by the endpoint.

This property would NOT be used if the organization is only providing technical infrastructure. For example, it would NOT refer to the cloud hosting provider if that provider were not providing helpdesk support for the endpoint.

This property would NOT be used to represent the entity that is the steward of the data exposed by the endpoint. This should be represented via Organization.endpoint. PractitionerRole.endpoint, Location.endpoint, or the other directory resources that may refer to endpoints.

This property is not typically used when searching for Endpoint resources for the purpose of retrieving or sending clinical or administrative data. However you may use this property to find endpoints for other technical administrative reasons such as if an organization that is managing endpoints is going out of business, you may need to update to the new managing organization.

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 times the endpoint is expected to be available, including transient downtimes and any exceptions.

Endpoint.availability is meant to represent specific availability, including temporary downtimes or other short term changes in availability. Conversely, Endpoint.period is meant to represent the general planned period of time when the Endpoint may be used, for example when an endpoint is being commissioned or decommissioned. For example, if an Endpoint is only available during business hours (9-5), the lack of availability during the night would not be reflected in Endpoint.period,but would be reflected in Endpoint.availability.

The set of payloads that are provided/available at this endpoint.

Note that not all mimetypes or types will be listed under the one endpoint resource, there may be multiple instances that information for cases where other header data such as the endpoint address, active status/period etc. is different.

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

The mimeType describes the serialization format of the data, where the payload.type 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 FHIR profile that is expected at this endpoint. It describes the resources that are handled, or even simply which resource types -e.g. Vital Sign Observations or QuestionnaireResponse. The profileUri may be used when a FHIR Structure Definition is not available/appropriate.

The profile (as a uri) that is expected at this endpoint when not represented using a FHIR profile.

e.g. CDA Template ID expressed as an OID (in the Uri).

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.