search

hl7-be / lab

Creative Commons Zero v1.0 Universal
6 stars 9 forks source link

Unexpected error generated for use case 5 (Specimen Management) when using fullUrl with servername #310

Open nicovn opened 3 months ago

nicovn commented 3 months ago

When validating the message for use case 5 (https://fhir-testserver.be/index.php/user/secured/testgroup/details?id_testgroup=35) we get this error:

actual: false,

§ field: "Bundle.entry.where(resource is Specimen).fullUrl.select($this.toString().replaceMatches('.[:/]+([^:/]+)', '$1').trace('a')) | Bundle.entry.where(resource is Observation).resource.specimen.reference.select($this.substring($this.indexOf('/')+1,$this.length())).select($this.substring($this.indexOf(':')+1,$this.length())).select($this.substring($this.indexOf(':')+1,$this.length())).distinct().select($this.trace('b')) ~ Bundle.entry.where(resource is Specimen).fullUrl.select($this.toString().replaceMatches('.[:/]+([^:/]+)', '$1').trace('c'))",

§ expected: true

Though I think that our test message is correct. (but I can be wrong of course)

Our "fullUrl" contains the FQDN ("https://sezz.be/fhir/LIS/Specimen/d6ede94b-1861-4f63-8b3f-50c96443c956") as suggested by FHIR. When I remove the server information ("Specimen/d6ede94b-1861-4f63-8b3f-50c96443c956") the FHIRPath expression above returns true.

Example message: 84161455998.20240617143950307-fhir-bundle.json

Can you please investigate ?

Thanks a lot !

Best Regards

Nico

nicovn commented 3 months ago

Bart, ter info; uw bewering dat absolute urls in FHIR bundles moeten resolven (via HTTP GET lookups) klopt niet 100% hoor.

cfr https://build.fhir.org/bundle.html#references

bdc-ehealth commented 3 months ago

@nicovn

Using the solution you propose is attractive, but it is not completely compliant with the standard: look here: Bundle - FHIR v4.0.1 Although it is not obligatory to make the resource accessible in a REST FHIR way, it is indicated always that the fullUrl is the physical place where we can, perhaps by means of another protocol, obtain the resource. In your case, the server http://system.sys does not exist, so I would not use this URL. In this case, an “urn:” solution (maybe “uuid:”, or whatever) would be more appropriate. In addition, I don't know if this is the case in your system, but a REST type URL can only be used when the resource is really persisted with this id: Bundle - FHIR v4.0.1.