"Logical ID" <id value="23"/>

PID: http://test.fhir.org/r4/Patient/23 

The FHIR standard

(1) requires the  logical ID is unique for a specific kind of resource in the server

(2) defines the rule for  building the 'location URL'

as concatenation of the server URL, kind of resource and logical id.

Since the server URL is globally unique also the location URL is globally unique

This is under the organization responsibility.

That is, the organization shall assure that the server end-point is 'always' resolvable. This may be done assuring that the end point doesn't change or by using proxy/redirect mechanisms.

In the FHIR REST paradigm this is true, that is the location URLs shall point to a FHIR RESTful server.

When FHIR resources are used within other paradigms, e.g. they are exchanged by using IHE XD*/XC* transaction or OMG RLUS services, this may not be true.

This resource identifier changes if the server end-point changes.

When an absolute URLs is used this shall point to a FHIR RESTful server

To facilitate redirect / proxy solutions use relative URL in the resource references.

PRO:

• the location URL can be used to access the resources via standard FHIR API (e.g. GET http://test.fhir.org/r4/Patient/23  )

• is the 'natural' way to uniquely identify resources in FHIR and no addition effort is required

• applies to any FHIR resource

• used to cross referencing FHIR resources (as absolute or relative URL)

CONTRA:

• If the organization doesn't guarantee the persistency of the server end point the location URL is not persistent. (but this true for any registry of identifiers..)

<identifier>

  <system value="https://doi.org" />

  <value value="10.5281/zenodo.4474373" />

</identifier>

<identifier>

  <system value="urn:ietf:rfc:3986" />

  <value value="https://doi.org/10.5281/zenodo.4474373" />

</identifier>

PID: https://doi.org/10.5281/zenodo.4474373

If the requirement is that the  object identifier is an URL used to directly access the resource, then it is an assigning organization responsibility to assure that:

• that id is actually resolvable

• a rule to build a machine resolvable URL from the namespace and the identifier is agreed.

• the system and value shall have a format such that the applied rule generate a valid URL 

The business identifier chosen shall be unique and global.

A business identifier is recorded in a FHIR resource using the Identifier type, which holds both the namespace (using Identifier.system) and the identifier itself (using Identifier.value).

If the identifier is itself an url, then the value of the system can be set to "urn:ietf:rfc:3986", otherwise a community rule to build an URL from the namespace and the identifier used as object identifier should be agreed. For example the url  can be constructed using a concatenation of the system and value fields of the identifier and that might be be used as GUPRI for the resource (for example: http://a.particular.system/identifier/123456). It is up to the implementer to make sure that there are indeed systems and policies to govern this namespace.

Finally, it's worth to remind that FHIR provide a standard search syntax to access a resource by using its business identifier [base]/[resource]?identifier=$system|$value).

PRO:

if a registry of permanent and resolvable identifiers is provided all the three properties are assured (e.g. https://doi.org)

CONTRA:

maintenance cost of such a kind of global registry. This includes also the registration process of the large number of FHIR resources a server needs to deal with ...

a call as GET https://$system/$value is not a FHIR API call

PRO:

persistency of the identifier 

CONTRA:

The canonical URL is defined only for a subset of FHIR resources.

The resolution of the canonical URL into an actual accessible end-point is not guaranteed, unless a redirect/proxy solution is applied as for the point 1.