ADR: How to reference to resources in GF Addressing

[stevenvegt]

This ADR is requested for GF Addressing, but it may be applicable to every reference that is made in any (FHIR) resource instance.

Example use-cases:

1. An eOverdracht has a target Organization (Task.owner), how to reference to this organization in the Task?
2. What if the Task.owner stores a copy of the Task; how to reference the original Task and the ServiceRequest it was basedOn?

Options:

1. By logical identifier, such as URA

Only top-level Organization instances have a URA-number. Not a solution for the majority of the data in a Query Directory. You could provide every instance with a logical identifier, but it lacks a way of knowing where to find this logical identifier. It is possible to use the identifier.assigner element (reference to an Organization), which could also contain an identifier (with, again, an assigner, etc..). This way, references can become huge and clients may not know how to handle/resolve these identifiers. An assigners may not be the organization that publishes the instance (e.g. BSN)

2. By to UUID in the LRZA directory

The LRZa registry is not the authoritative source for (all) Organization-instances; it is only the authoritative source for a top-level Organization identifier (and specifically the URA number). Not a solution for the majority of the data in a Query Directory.

3. By (full-)URL to the original instance

Pro: simple and resolvable
Con: FHIR-base-URL should be stable for the long term (think about e.g. domain-ownership). If FHIR-base-URL must be changed, use the Endpoint.status and Endpoint.extension.replacedBy to publish the change. Other providers should plan to consume these changes (find-and-replace URLs). The instance ID should also be stable for the long term (e.g. avoid ID-collisions when joining/merging databases); use UUIDs.
Fetching data from remote repositories can be challenging (access, time-outs, etc.), but a local copy (cache) of entities with the fullURL to the original in 'meta.source' could help.

4. By local ID to the copied instance (e.g. in a query directory)

Referring to copies of (original) instances is undesirable in general and the Query Directory contains (often) only copies. Referring to (just) an ID won't provide the location of the original; you still need to know where original document is located using, e.g., the fullURL to the original in 'meta.source'. If copied instances are copied again, you risk getting a chain of copied instances (local or remote) that may or may not have been updated; risk for a big mess.

5. By local UUID to the original and copied instance (reusing the UUID of the original instance for the copied instance)

Referring to copies of (original) instances is undesirable in general and the Query Directory contains (often) only copies. Referring to (just) an UUID won't provide the location of the original; you still need to know where original document is located using, e.g., the fullURL to the original in 'meta.source'. If copied instances are copied again, you risk getting a chain of copied instances (local or remote) that may or may not have been updated; risk for a big mess. Additionally, it does require usage of UUIDs at the original instance (which may never happen).

Proposal:

Reference to resources using fullURL to the original instance. An additional logical ID may be provided as well.

NB: if an instance does not exist, a URL (or local ID/UUID) doesn't exist either. A logical ID is the only option.

[stevenvegt]

As a reaction on the example-use-cases:
I would say in general: data should stay at its source. So no copies of data. The one source can be used to reference to.

However, mCSD and the GF Adressing is an exception to this "rule", since there is no real "one source" of an organization. There are multiple sources. So I would want to scope this ADR on the GF Adressing and not the reference problem in general.

As a reaction on the proposal for Option 3:
How do you know the original source? We already concluded that eventually these local resources in the query directory are possible consolidated from multiple sources. meta.source can only hold one value. We probably need to look into using Provenance resources to keep track of the sources per field. But I think using the provenance resources to find out the original source is inconvenient.

My proposal would be Option 1. With the addition to agree on a logical identifier for each resource in the GF. There are not that much of these resources. And in practice you probably would only refer to Organizations, Locations, and Practitioners? All of these should eventually have a logical identifier anyway.

I believe this would lead to a less brittle system where we refer to logical identifiers and not to the systems which represent them. Imagine the hassle of switching from mCSD provider. This would become practically impossible. This is also the reason we decided in Nuts not to use the did:nuts to identify the organisation, but switched to logical ids.

[bramwesselo]

We did not conclude multiple instances are merged to 1 instance because that leads to a provenance-challenge. Values/elements of non-authoritative sources are simply verified using the designated authoritative source.

You shouldn't make an exception for addressing, because that doesn't make any sense. Every time you notify some other organization (TA NP), a copy will be made. Practitioners also tell me they need copies, because they have the 'dossier-plicht'.

We tried using logical identifiers; no standard support from FHIR-servers, no deterministic behaviour. Yes, you can add logical identifiers to improve robustness. However, the basis of references should still be a local reference or fullURL whenever possible. (e.g. in the NVI you don't want to store the fullURL of the Patient-instance)

[stevenvegt]

We did not conclude multiple instances are merged to 1 instance because that leads to a provenance-challenge. Values/elements of non-authoritative sources are simply verified using the designated authoritative source.

Wat do you mean by this? If I search for an organization by AGB on my local Query directory, this identifier came from the AGB registry and thus has been merged into 1 instance?

We tried using logical identifiers; no standard support from FHIR-servers, no deterministic behaviour

Those are new arguments and should be added to the analysis. What do you mean by non-deterministic behavior? Why is it not possible to search on logical identifier? Observation?subject=bsn|123 is a really common search operation right? Why would this be a problem?

Every time you notify some other organization (TA NP), a copy will be made.

What I understand they create an archive of the data that was used to come to an insight/diagnosis etc., but this data is usually not active in their own system. They cannot serve this as their own. If there is for example an author, this practitioner resource is also not copied into their own practitioners table. I would be really concerned if everytime someone request a actual medication overzicht this will be copied over to their own fhir server.