Stream: implementers
Topic: sdf-0 and core Extensions
Patrick Werner (Aug 10 2020 at 14:37):
I'm probably very late to the party, but sdf-0 is a real annoyance. Even the core Extensions in FHIR don't comply to it.
Jens Villadsen (Aug 10 2020 at 16:18):
Lol
Jens Villadsen (Aug 10 2020 at 16:18):
I agree
Grahame Grieve (Aug 10 2020 at 19:23):
it's just a warning, and we never had the time to enforce this on the editors :-(
Grahame Grieve (Aug 10 2020 at 19:23):
why is it such an annoyance?
Jens Villadsen (Aug 10 2020 at 20:24):
warnings (IMHO) are usually things that needs fixing before they become errors
Jens Villadsen (Aug 10 2020 at 20:25):
it is something that one should react on
Lloyd McKenzie (Aug 24 2020 at 00:28):
The reaction is to investigate and determine whether it's an error in the circumstance or not. This one really ought to be an error, but it's too late to tighten it. Feel free to negative ballot every violation of it though.
David Simons (May 07 2021 at 12:45):
Also running into this conflict between sdf-0 and the FHIR Naming Rules & Guidelines:
We do keep filename, canonical, and Name the same, across our Profiles:
- inpatientCareObservationAlgorithmOutcome.structuredefinition.xml
- <url value=".../inpatientCare/common/observation-v1/inpatientCareObservationAlgorithmOutcome" />
- <name value="inpatientCareObservationAlgorithmOutcome" />
Warning @ StructureDefinition (line 2, col2) :
- sdf-0: 'Name should be usable as an identifier for the module by machine processing applications such as code generation' failed [name.matches('A-Z{0,254}') ] (ie. Capitalized)
whereas we _are_ following [assuming extensions are elements]:
- Names for operations, resources and resource elements must: be lowerCamelCase for elements, UpperCamelCase for resources, be lowercase for operations
from https://confluence.hl7.org/display/FHIR/Guide+to+Designing+Resources#GuidetoDesigningResources-NamingRules&Guidelines
What are the resolutions that folks have taken to avoid this Warning? Some FHIR Servers reject not only Errors, but also reject Resources with validation Warnings.
Lloyd McKenzie (May 07 2021 at 13:27):
The reference to 'name' for operation in terms of lowerCamelCase is actually referring to OperationDefinition.code, not OperationDefinition.name. I've updated the guidance to be more clear.
David Simons (May 07 2021 at 13:50):
So you are saying that the FHIR Naming Rules&Guidelines are not about the .name attributes?
I see you added StructureDefinition.id rather than StructureDefinition.name
I think id should be assigned upon instantiation of the profile (by a server upon upload), upon design the name is much more relevant (for version control and cataloging in a registry)
My fallback is to prefix everything with "Extension" (no dash!)
- ExtensioninpatientCareObservationAlgorithmOutcome.structuredefinition.xml
- <url value=".../inpatientCare/common/observation-v1/ExtensioninpatientCareObservationAlgorithmOutcome" />
- <name value="ExtensioninpatientCareObservationAlgorithmOutcome" />
Lloyd McKenzie (May 07 2021 at 14:39):
You can only define resources in HL7, so we can control the id. For profiles, the ids will vary as they propagate to different servers. What really matters is what's in the canonical URL.
Not fully understanding the reason to put 'Extension' on the front And not clear why the 'i' in Inpatient is lower-case
David Simons (May 07 2021 at 18:25):
ok - we made it lower-case per our interpretation of the FHIR Naming Rules - plus aligning filename, canonical, and name for consistency.
Name for this structure definition (computer friendly) is mandatory, so we derive it from the canonical.
Note that most of the entries in the FHIR Extensions list are camelCased:
https://www.hl7.org/fhir/extensibility-registry.html
and many also have the name attribute camelCased, correspondingly.
e.g.
<url value="http://hl7.org/fhir/StructureDefinition/condition-occurredFollowing"/>
<version value="4.0.1"/>
<name value="occurredFollowing"/>
will give a HL7 Validator warning on sdf-0: 'Name should be usable as an identifier for the module by machine processing applications such as code generation' failed [name.matches('A-Z{0,254}') ]
Lloyd McKenzie (May 07 2021 at 19:17):
Yeah, we don't really have any standard for the ids or URLs of extensions - but the computable names (which are largely irrelevant seeing as no-one does code-generation based on profiles yet) must be UpperCamelCase. There's no expectation that the .name element and the id or url tail match.
Robert Scanlon (May 07 2021 at 21:43):
We generate code based on profiles for some test suites, and it is a bit of an annoyance this element can't be used for its stated purpose (e.g. observation-bodyweight forced us to massage the name in our US Core tests). Not a huge deal, but it is a little annoying.
Lloyd McKenzie (May 07 2021 at 21:51):
Originally, name and title were the same element. When they got split, the tools didn't necessarily support title yet, so name still got used for that purpose. We've since added additional validation that yells at people when they populate it wrong, but getting the authors to pay attention to that is still challenging. Feel free to submit change requests on the ones that are specifically causing you grief to provide additional incentive to make the fixes sooner rather than later.
David Simons (May 17 2021 at 17:58):
Thank you! - have not yet settled on an internal approach for us - but this is another - sacrificing consistency a bit.
(Consistency that is crucial in an automated validation/build/packaging pipeline)
- inpatientCareObservationAlgorithmOutcome.structuredefinition.xml
- url value=".../inpatientCare/common/observation-v1/inpatientCareObservationAlgorithmOutcome"
- name value="InpatientCareObservationAlgorithmOutcome"
Lloyd McKenzie (May 17 2021 at 18:06):
Consistency between id and name isn't something you can count on. Id will vary from server to server. The tail of the URL is also not guaranteed to align with the name, though that's more in the control of the author, so consistency there is at least possible.
Last updated: Apr 12 2022 at 19:14 UTC
