Stream: IG creation
Topic: uri resolution error
Eric Haas (Aug 31 2019 at 20:40):
for the US Core Implantable Device Profile we get this qa error on the instance:
Device/udi-3: Device.udiCarrier[0].issuer error URL value 'http://hl7.org/fhir/NamingSystem/gs1-di' does not resolve
for the element Device.udiCarrier.issuer note that it defines the this URL value in the definition. (And there is no further guidance here unfortunately)
Here is what I understand about uri resolution (from the identifier datatype:
If the system is a URL, it SHOULD resolve. Resolution might be to a web page that describes the identifier system and/or supports look-up of identifiers. Alternatively, it could be to a NamingSystem resource instance. Resolvable URLs are generally preferred by implementers over non-resolvable URNs, particularly opaque URNs such as OIDs (urn:oid:) or UUIDs (urn:uuid:). If used, OIDs and UUIDs may be registered in the HL7 OID registry and SHOULD be registered if the content is shared or exchanged across institutional boundaries.
I am going to remove from this instance since not required in Profile But it would be nice to know whether the Device definition and thus this uri value is wrong or the validator is being too strict here.
Eric Haas (Aug 31 2019 at 20:49):
@Brett Marquard @Grahame Grieve @Lloyd McKenzie ?
Lloyd McKenzie (Aug 31 2019 at 20:55):
The expectation of the validator is that if you're pointing to a canonical URL in the hl7.org namespace, that it should be something declared in the version of FHIR you're using or one of the ancestor IGs. So this should presumably be a NamingSystem exposed in the core specification package for the version you're referencing. Is it not there?
Grahame Grieve (Sep 01 2019 at 20:15):
in general, it should resolve, yes. but for publishing integrity purposes, we require that all references in the hl7.org/fhir namespace do resolve - people find it confusing when we apparently reference content that we haven't created.
You can refer to example.org/.... if you want to reference content that doesn't actually exist
Eric Haas (Sep 02 2019 at 14:54):
Thanks for the responses, I think will make tracker to look into these namespaces in UDI further and let OO/FDA figure it out. I think they should resolve as well.
Last updated: Apr 12 2022 at 19:14 UTC
