Stream: dotnet
Topic: Firely - Unable to resolve reference to profile
Corey Wen (Jun 17 2021 at 16:18):
I am trying to validate a Patient resource that follows the us-core-patient using the Firely server. I have been following Firely documentation for validation and trying the validation on a system and ResourceType level. However I get the error Unable to resolve reference to profile 'http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient'
. To reference the us-core-patient I either put the canonical url in the endpoint like so
https://server.fire.ly/Patient/$validate?profile=http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient
or put it in the meta field for the resource
"resourceType": "Patient",
"meta": {
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
]
},
I managed to get the validation working using the FHIR validator jar [FHIR Validation tool Version 5.4.4 (Git# 952db0248a25)] for the Patient resource.
@Ewout Kramer Do you or anyone else know what might be the issue?
Additionally, another situation when validating a bundle using the Firely server I receive no errors, but the FHIR validator jar returns errors such as Bundle entry missing fullUrl
or Except for transactions and batches, each entry in a Bundle must have a fullUrl which is the identity of the resource in the entry
; what could account for these differences?
Ewout Kramer (Jun 18 2021 at 09:12):
You reference the profile correctly, but unless that profile is present in the Firely Server so the validator can locate it and use it, it still will not work. I don't know if/how our public server has these us-core profiles installed, @Matthijs van der Wielen or @Christiaan Knaap will surely know more about that.
Ewout Kramer (Jun 18 2021 at 09:14):
Except for transactions and batches, each entry in a Bundle must have a fullUrl which is the identity of the resource in the entry
There are certainly differences between the two validators, the Java one has more "hand-built" rules like these. This validation is not expressed in, say, the profile for Bundle, but rather these are present as written narrative rules in the spec only. The .NET validator still misses quite a few of those rules.
Ewout Kramer (Jun 18 2021 at 09:17):
I have added this request to the list at https://github.com/FirelyTeam/firely-net-sdk/issues/1766
Matthijs van der Wielen (Jun 18 2021 at 09:26):
Hi @Corey Wen ,
I checked and the us-core-patient is loaded on the public endpoint, but only for STU3. So when you try to validate a R4 profile this will not work. Could you let me know it that is the case?
FYI you can check weather this profile is included using ({{BASE_URL}}/administration/StructureDefinition?url=http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient)
Corey Wen (Jun 18 2021 at 13:52):
Hi, I believe I was trying to validate a R4 profile but I am not sure how confirm if that is actually the case. I'm relatively new to FHIR so I'm not 100% sure. There is no data in my resource that denotes it being R4 or STU3, but this is the profile for us-core patient I was following.
Ewout Kramer (Jun 18 2021 at 14:32):
If you used https://server.fire.ly/Patient/$validate?profile=http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient
, I am pretty sure this is the R4 endpoint. @Matthijs van der Wielen , correct?
Matthijs van der Wielen (Jun 21 2021 at 07:00):
Yes, that is correct. I meant to respond to this, we are investigating why the STU3 resources has been loaded on the R4 endpoint. This should be the us-core R4 patient and not the STU3 patient. I will let you know once we've fixed this.
Matthijs van der Wielen (Jun 23 2021 at 06:48):
Hi @Corey Wen ,
One of my colleagues pointed out to me that we do have the R4 resource for the us-core-patient preloaded on our admin db. Let me explain how this works:
server.fire.ly by default still returns STU3.
Ways to get to STU3 or R4 explicitly:
- server.fire.ly/R3/
- server.fire.ly/R4/
- server.fire.ly, Content-Type = application/fhir+json; fhirVersion=3.0
- server.fire.ly/, Content-Type = application/fhir+json; fhirVersion=4.0
For more information on that please take a look at our documentation: https://docs.fire.ly/projects/Firely-Server/en/latest/features/multiversion.html
Finally, us-core Patient is loaded for both R3 and R4:
<base>/administration/R3/StructureDefinition?url=http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient
<base>/administration/R4/StructureDefinition?url=http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient
Note to add /administration before the version part of the path.
We are working on changing the default to R4 instead of STU3. So the validation should work if you use https://server.fire.ly/R4/Patient/$validate?profile=http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient
Corey Wen (Jun 24 2021 at 14:12):
I tried sending a post request using Postman and unfortunately I still received the same error of
"Unable to resolve reference to profile 'http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient'"
.
I have both "Content-Type" and "Accept" as application/fhir+json; fhirVersion=4.0
and tried the post request to two endpoints, one being
https://server.fire.ly/R4/$validate
with the us-core patient in the .meta field of my Patient resource, and another endpoint
https://server.fire.ly/R4/Patient/$validate?profile=http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient
.
Mirjam Baltus (Jun 24 2021 at 18:03):
Sorry for the inconvenience @Corey Wen. Usually the us-core profiles are loaded into our administration database by default after a reset, but it seems after the last one this did not happen. I have uploaded the profiles manually now, so it should work if you try again.
Last updated: Apr 12 2022 at 19:14 UTC