Stream: conformance
Topic: Extension.url - fixedString or fixedUri?
Michel Rutten (Sep 19 2019 at 09:40):
I notice that in the official FHIR R4 extension definitions (e.g. extension-definitions.json), the [...].extension.url elements in the snapshot specify a fixedUri property with the canonical url of the extension definition. However the Extension.url element is defined with special "system" string type and "compiler magic" extensions (profiles-types.json). Doesn't this imply that the fixed value should be a fixedString?
Grahame Grieve (Sep 19 2019 at 09:42):
maybe... but we've never discussed that the URL the refers to an extension shouldn't have extensions, and it can in the way it is represented. And I suppose if I was to, well, wear my Lloyd hat, I could find some reasons why it might be rationale to extend it ;-)
Michel Rutten (Sep 19 2019 at 09:51):
If an element needs to support extensions, then it must be defined with a FHIR (primitive) type.
Elements with system types (compiler magic) do not support extensions.
Currently, in R4, Extension.url is currently defined using a system type. So it does not support extensions.
Right?
Michel Rutten (Sep 19 2019 at 09:52):
@Ewout Kramer ?
Grahame Grieve (Sep 19 2019 at 09:53):
yes that's correct. But it's still a URL, even if it's a special type.
Michel Rutten (Sep 19 2019 at 10:05):
But a system url, not a FHIR url, right? If I understand correctly, this implies that the element should specify fixedString, not fixedUri? Because the latter applies to FHIR Uri, not to system Uri.
Grahame Grieve (Sep 19 2019 at 10:32):
I don't think that's true. For several reasons:
- replacing FHIR.uri with FHIR.string doesn't get your closer to System.uri
- there's no way to use System.string in that location
- FHIR.uri has a conversion relationship with System.uri
- there's imagineable uses for extensions in that location
Michel Rutten (Sep 19 2019 at 10:50):
So how is the mapping defined between Extension.url and fixedUri?
i.e. how can a system derive this knowledge programmatically?
The type of Extension.url is defined using compiler magic extensions with value "string".
There is no additional metadata indicating that this string value actually represents an uri.
Or am I missing something?
Michel Rutten (Sep 19 2019 at 10:51):
FYI Extension.url element is defined with the following type:
<type>
<code>
<extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-json-type">
<valueString value="string"/>
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-xml-type">
<valueString value="xsd:string"/>
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-rdf-type">
<valueString value="xsd:string"/>
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/regex">
<valueString value="((http|https)://([A-Za-z0-9\\\.\:\%\$]*\/)*)?(Account|ActivityDefinition|AdverseEvent|AllergyIntolerance|Appointment|AppointmentResponse|AuditEvent|Basic|Binary|BiologicallyDerivedProduct|BodyStructure|Bundle|CapabilityStatement|CarePlan|CareTeam|CatalogEntry|ChargeItem|ChargeItemDefinition|Claim|ClaimResponse|ClinicalImpression|CodeSystem|Communication|CommunicationRequest|CompartmentDefinition|Composition|ConceptMap|Condition|Consent|Contract|Coverage|CoverageEligibilityRequest|CoverageEligibilityResponse|DetectedIssue|Device|DeviceDefinition|DeviceMetric|DeviceRequest|DeviceUseStatement|DiagnosticReport|DocumentManifest|DocumentReference|EffectEvidenceSynthesis|Encounter|Endpoint|EnrollmentRequest|EnrollmentResponse|EpisodeOfCare|EventDefinition|Evidence|EvidenceVariable|ExampleScenario|ExplanationOfBenefit|FamilyMemberHistory|Flag|Goal|GraphDefinition|Group|GuidanceResponse|HealthcareService|ImagingStudy|Immunization|ImmunizationEvaluation|ImmunizationRecommendation|ImplementationGuide|InsurancePlan|Invoice|Library|Linkage|List|Location|Measure|MeasureReport|Media|Medication|MedicationAdministration|MedicationDispense|MedicationKnowledge|MedicationRequest|MedicationStatement|MedicinalProduct|MedicinalProductAuthorization|MedicinalProductContraindication|MedicinalProductIndication|MedicinalProductIngredient|MedicinalProductInteraction|MedicinalProductManufactured|MedicinalProductPackaged|MedicinalProductPharmaceutical|MedicinalProductUndesirableEffect|MessageDefinition|MessageHeader|MolecularSequence|NamingSystem|NutritionOrder|Observation|ObservationDefinition|OperationDefinition|OperationOutcome|Organization|OrganizationAffiliation|Patient|PaymentNotice|PaymentReconciliation|Person|PlanDefinition|Practitioner|PractitionerRole|Procedure|Provenance|Questionnaire|QuestionnaireResponse|RelatedPerson|RequestGroup|ResearchDefinition|ResearchElementDefinition|ResearchStudy|ResearchSubject|RiskAssessment|RiskEvidenceSynthesis|Schedule|SearchParameter|ServiceRequest|Slot|Specimen|SpecimenDefinition|StructureDefinition|StructureMap|Subscription|Substance|SubstanceNucleicAcid|SubstancePolymer|SubstanceProtein|SubstanceReferenceInformation|SubstanceSourceMaterial|SubstanceSpecification|SupplyDelivery|SupplyRequest|Task|TerminologyCapabilities|TestReport|TestScript|ValueSet|VerificationResult|VisionPrescription)\/[A-Za-z0-9\-\.]{1,64}(\/_history\/[A-Za-z0-9\-\.]{1,64})?"/>
</extension>
</code>
</type>
Grahame Grieve (Sep 19 2019 at 10:52):
Or am I missing something?
Y. check out the proposed technical correction which sorted that
Michel Rutten (Sep 19 2019 at 10:54):
The correction will certainly improve this and make it more explicit. I'm now focusing on current R4 implementation.
For example, compare the current type declaration of Element.id:
<type>
<code>
<extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-json-type">
<valueString value="string"/>
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-xml-type">
<valueString value="xsd:string"/>
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-rdf-type">
<valueString value="xsd:string"/>
</extension>
</code>
</type>
So the type declaration is similar to that of Extension.url, however the element id does not represent a uri.
Grahame Grieve (Sep 19 2019 at 10:56):
no, you're right, it doesn't. But now I'm not sure what your point is.
Michel Rutten (Sep 19 2019 at 11:02):
I'm wondering how my logic could determine programmatically (from definitions) that Extension.url requires fixedUri, not fixedString?
Currently my logic inspects these extensions and maps the value back to a FHIR type, using the following mapping table:
xsd:string => FhirString xsd:token => FhirString xsd:div => FhirString xsd:boolean => FhirBoolean xsd:anyURI => FhirUri xsd:dateTime => Instant xsd:time => Time xsd:gYear OR xsd:gYearMonth OR xsd:date => Date xsd:gYear OR xsd:gYearMonth OR xsd:date OR xsd:dateTime => FhirDateTime xsd:int => Integer xsd:positiveInteger => PositiveInt xsd:nonNegativeInteger => UnsignedInt xsd:decimal OR xsd:double => FhirDecimal
Michel Rutten (Sep 19 2019 at 11:06):
Specifically, both Element.id and Extension.url specify the exact same type declaration with compiler magic extensions ("xsd:string"). How can a system determine that Extension.url actually needs fixedUri?
Grahame Grieve (Sep 19 2019 at 11:09):
are you asking about the current deficient definitions, or the fixed ones?
Michel Rutten (Sep 19 2019 at 11:12):
The current R4 ones. We haven't started implementing the technical correction, pending final publication.
Michel Rutten (Sep 19 2019 at 11:12):
Just want to make sure that both our outputs are in sync.
Grahame Grieve (Sep 19 2019 at 11:15):
well, the answer right now is that you need magic knowledge to know that Extension.uri is actually a uri
Grahame Grieve (Sep 19 2019 at 11:15):
the technical corrections fix that
Michel Rutten (Sep 19 2019 at 11:20):
Ouch... I prefer not to rely on "magic knowledge" at all, as it is brittle and error prone.
So why can't we use fixedString then? Are there any compelling reasons for introducing "magic knowledge" so we get a fixedUri? What benefits does this provide?
Grahame Grieve (Sep 19 2019 at 11:25):
what benefits? How about consistency with the actual specification? Finding an issue in the structure definitions, with a known fix, and you want to solve it in a way that is inconsistent with the spec?
Michel Rutten (Sep 19 2019 at 11:42):
Is it really inconsistent? You just mentioned that this aspect requires "magic knowledge". So there is no way to programmatically determine this and it is not (clearly) defined by the spec, i.e. ambiguous. By some historic convention (?), the official snapshots now introduce fixedUri. However the official definitions could also introduce fixedString, as the spec itself does not explicitly define what the type of the fixed value should be. And the latter wouldn't require any "magic knowledge".
Apologies for the hammering, I'm just trying to determine if I can avoid any _magic_.
Grahame Grieve (Sep 19 2019 at 11:51):
you cannot avoid magic and be conformant until I get the technical correction out
Grahame Grieve (Sep 19 2019 at 11:54):
you could not use fixedString and be conformant with what the specification says (not the structure definitions).
Michel Rutten (Sep 19 2019 at 12:18):
The specification currently doesn't explicitly _say_ anything about this (hence my questioning), so it is unclear what conforms. The core profiles now seem to make arbitrary (inconsistent) decisions when introducing fixed values for system type elements, w/o any formal rules. Specifying fixedString for all element with system type "xsd:string" makes the definitions regular (consistent) and allows for deterministic logic w/o any magic.
Or are you simply worried about backwards compatibility with existing R4 definitions?
Grahame Grieve (Sep 19 2019 at 12:20):
it absolutely does say that. it says that extension.url is a uri
Michel Rutten (Sep 19 2019 at 12:26):
Indeed, I see. I guess this is the "magic" that you mentioned, as this isn't expressed in the XML definitions.
I consider this a historic design mistake. Apparently I have no other option than to implement "magic" :(
Lloyd McKenzie (Sep 19 2019 at 12:45):
The extension.url and the fixedUri won't necessarily be the same. The StructureDefinition.url is the canonical URL for the extension 'profile'. The fixedUri for the Extension.url identifies the semantics. You can have extension profiles that constrain other extension profiles. The fixedUri is set to the canonical url of the base extension profile. The 'constraining' extension profiles define additional constraints and have their own distinct canonical URLs (possibly with different roots), but do not change the fixedUri.
Lloyd McKenzie (Sep 19 2019 at 12:46):
When you reference the extension in a profile, you might point to the profile for the constrained version of the extension.
Michel Rutten (Sep 19 2019 at 12:57):
@Lloyd McKenzie thank you for the helpful clarification!
Quite subtle. I see why derived extension profiles should inherit fixed url values from the base.
Will revisit .NET (R4) SnapGen & Forge to harmonize this.
Grahame Grieve (Sep 19 2019 at 13:05):
well, the good news is that ot won't be magic once I issue the technical correction
Ewout Kramer (Sep 19 2019 at 19:50):
But there is indeed a subtle point here that in fixed[x], the 'x' cannot be a System.X type - but that manifests only in Extension.url and Element.id - which are already a bit exceptional anyway.
Michel Rutten (Sep 20 2019 at 09:01):
@Ewout thanks, that explains.
Last updated: Apr 12 2022 at 19:14 UTC
