absolute reference vs urn

[PhilippeQuertemont]

We are receiving test protocol from labo tienenen to be integrated in HEALHT one (They are testing live with some practice)
and we have some process issues.
They are using Urn while we have use the absolute reference in our implementation
For example, we receive a link to a practitioner
"generalPractitioner": [ { "reference": "urn:uuid:4c4c2e0d-722e-5961-a91d-c81eebd0afe4" } ]
and the resource of the practitioner is:
{
"fullUrl": "urn:uuid:4c4c2e0d-722e-5961-a91d-c81eebd0afe4",
"resource": {
"resourceType": "Practitioner",
"id": "35512",
"meta": {
"profile": [ "https://www.ehealth.fgov.be/standards/fhir/core/StructureDefinition/be-practitioner" ]
},
Normally the ID of the resource correspond to the URL (At least in all sample on the test server...)

What is the recommended approach for the lab?
Should we support both?

Many thanks
Philippe Quertemont

[bdc-ehealth]

@PhilippeQuertemont

Indeed Philippe, the file by RZ Tienen is correct. This is also a valid way to refer to a resource in a bundle. If you check the examples on the testserver, you will find many examples like this (e.g. for test 1B, the Vivalia IFAC test with number 2855). So you will need to support this, I am afraid!

[AlexisVZ-MDS]

Hello, I believe testcase 1A from Regionaal Ziekenhuis Tienen vzw, with ID 1841 is an example to test if this is a problem.
@bdc-ehealth Can you confirm this ?
(We could import it without problem)

[tomdebacker-corilus]

@bdc-ehealth I have a similar question after our call on tuesday.
We received a labfile containing the following reference and we are now not sure whether we should or should not be able to import this one

"performer": [ {
"reference": "Organization/fL6a.vFxYqeg6BaBT4fTD7Q4"
} ],

"fullUrl": "https://www.saintluc.be/fhir/Organization/fL6a.vFxYqeg6BaBT4fTD7Q4",
"resource": {
"resourceType": "Organization",
"id": "fL6a.vFxYqeg6BaBT4fTD7Q4",
"meta": {
"profile": [ "https://www.ehealth.fgov.be/standards/fhir/core/StructureDefinition/be-organization" ]
},

[bdc-ehealth]

@tomdebacker-corilus ,

no this one is not valid, because it does not follow the bundle resolution rules: https://www.hl7.org/fhir/R4/bundle.html#:~:text=Except%20for%20transactions,used%20(urn%3Auuid%3A...).

[sebwautelet]

@tomdebacker-corilus ,

no this one is not valid, because it does not follow the bundle resolution rules: https://www.hl7.org/fhir/R4/bundle.html#:~:text=Except%20for%20transactions,used%20(urn%3Auuid%3A...).

Hi @bdc-ehealth ,
Can you clarify why it does not follow the bundle resolution rules?
From my understanding of the FHIR R4 specs (§ 2.36.4.1) , it does :

How to resolve a reference in a Bundle:
• If the reference is not an absolute reference, convert it to an absolute URL:
o if the reference has the format [type]/[id], and
o if the fullUrl for the bundle entry containing the resource is a RESTful one (see the RESTful URL regex)
 extract the [root] from the fullUrl, and append the reference (type/id) to it
 then try to resolve within the bundle as for a RESTful URL reference.

This type of resolution is included in the example Bundle included in the FHIR R4 specs.

  "entry": [
    {
      "fullUrl": http://example.org/fhir/Patient/23,
      "resource": {
        "resourceType": "Patient",
        "id": "23",

        "subject": {
          "reference": "Patient/23"
        }

[bdc-ehealth]

@sebwautelet

if you take a look at this section (https://www.hl7.org/fhir/R4/bundle.html#:~:text=Except%20for%20transactions,used%20(urn%3Auuid%3A...): "Where a resource is not assigned a persistent identity that can be used in the Bundle, a UUID should be used (urn:uuid:...)", it is clear that if an URL of a type that is different from 'urn:uuid:' is used then the resource should be persisted at that location ('persistent identity'). If you use "Patient/23" in the fullUrl field, you have to take the following steps:

1. make an absolute URL from the relative URL (this bundle is sent by the eHealthBox, so what server would you use to create the absolute URL?).
2. the absolute URL should be the location where the resource is persisted (and my interpretation: can be retrieved with the necessary credentials).

It will be very difficult to come up with URLs where both conditions hold. Therefore they say you are supposed to use (urn:uuid:...)

[sebwautelet]

@bdc-ehealth
By "persistent identity", I think they mean that the ID assigned to the Patient (so 23 in the example) won't change in the source system, not that it should be already accessible by the absolute URL.

1. This section explains that the absolute URL should be created using the base of the Bundle.entry.fullUrl
2. The section about Logical IDs states that "implementations SHOULD NOT assume that the location of a resource is always resolvable to an accessible server - it may be temporarily unavailable, or not available by policy (e.g. firewalls) or in some cases, it might not actually exist (e.g. use of resource outside a RESTful environment)". Resolving references in Bundle also states that "Applications reading a Bundle should always look for a resource by its identity in the bundle first before trying to access it by its URL externally.".

So can you clarify what kind of reference we can use in eHealthBox bundles?

• only urn:uuid:...?
• urn:uuid:... and absolute URLs (the same absolute URL in the entry.fullURL and reference)?
• both of the above + absolute URL in the entry.fullURL and relative URL in the reference (as in my example)?

This should also be clearly stated in the Belgian FHIR profiles (here it says that any way allowed by international FHIR is fine).

[bdc-ehealth]

@sebwautelet ,

the current policy for approval is that everything the validator_cli.jar accepts is accepted + the relative URLs that were accepted at the moment of the creation of the standard.

From phase 2 on, only what is accepted by validator_cli.jar will be accepted.

We align with what is allowed in the international standard (and for phase 1, we are even more lenient). Since your opinion and mine differ regarding the international standard, there seems to be room for interpretation. To be on the safe side, I would use "urn:uuid:...." , because that is certainly accepted by validator_cli.jar. If you, however, use another solution that is accepted by validator_cli.jar, that is perfectly OK for me.

You can find validator_cli.jar here: https://github.com/hapifhir/org.hl7.fhir.core/releases . As you can see, it is a moving target and not always backwards compatible, but that is what we have to live with if we want to use HL7 FHIR (it has already caused us trouble in the past: #278 )