RE: Extensions: Should extension server be accessible, and if accessible, can a Resource be validated against it?

1

My question is about extensions and the server that is referenced in the “url”… If the extension definition is placed on a server that can’t be accessed by the Resource receiver, then it’s pretty much like the “Z” segments in HL7 v2.x, yes? And if the server that is referenced in the extension is accessible by receiver… Is the value that is given in the extension (“TET2” below) in any way validated against the extension definition?

    "extension": [
      {
        "url": "http://hl7.org/fhir/StructureDefinition/observation-geneticsGene",
        "valueCodeableConcept": {
          "text": "TET2"
        }
      }
   ]
2

The url for the extension is meant to be a unique identifier for the structure, and does not need to be a retrievable url.
For a validator it is important to have access to all structures needed to validate the resource content. This could be done by trying to access the url to retrieve the definition, but for a lot of extension definitions this will fail. A validator can also reach out to a profile repository like Simplifier.net to search for the canonical url used in any extension it does not know. Another option is to download the structures needed for validation to the filesystem the validator can access, for example by using a package created for the project.

The value used in the extension will usually only be validated when the extension definition - or profile it is part of - has set a required or extensible binding to a particular ValueSet. So in addition to the extension definition, you will need to have access to the value set definition as well, and possibly a terminology service to expand the value set for validation.

1 Like
3

A key rule with extensions is that the definition of the extension must be known to or discoverable by the recipient. The easiest way to do this is for the URL to resolve. Registering the extension in a common public registry or in an agreed space by the implementation community is also appropriate.

Mirjam isn’t quite correct about validation. Other types of validation that would occur is what the value data type is and constraints such as length, regular expressions, etc. No system is required to validate any inbound instance - however systems are required to ensure that outbound instances are valid.

1 Like