Stream: implementers
Topic: us-core birthsex
Nick George (Oct 05 2018 at 21:47):
why does the us core birthsex extension have a slice as the root element? This seems odd, and is different from any other extension I've seen (where the root name is just Extension, and things that use it list the slice name they want)
http://hl7.org/fhir/us/core/1.0.1/StructureDefinition-us-core-birthsex.json.html
Nick George (Oct 06 2018 at 19:54):
(True of all us-core extension profiles)
Eric Haas (Oct 07 2018 at 12:47):
You are correct. After reviewing the spec, this section defines what the id should look like: http://hl7.org/fhir/elementdefinition.html#id It looks like none of the current validation tools are enforcing this restriction or this would have been discovered much earlier. I will create a tracker to change them the next version of US Core.
Grahame Grieve (Oct 07 2018 at 15:14):
should be fixed in the current IG publisher
Eric Haas (Oct 07 2018 at 17:01):
Extensions are currently validating without error in the IG publisher. (just checked)
Nick George (Oct 07 2018 at 20:35):
another note, the "defining url" for us-core valuesets don't seem to resolve: e.g., http://hl7.org/fhir/us/core/1.0.1/ValueSet-us-core-birthsex.html has http://hl7.org/fhir/us/core/ValueSet/us-core-birthsex
Grahame Grieve (Oct 08 2018 at 03:19):
is this good or bad?
Nick George (Oct 10 2018 at 05:40):
I guess I don't care that much but I'd assume "bad" - isn't the idea that you can look up the valueset at its url?
Grahame Grieve (Oct 10 2018 at 07:06):
I was asking @Eric Haas actually.
Grahame Grieve (Oct 10 2018 at 07:06):
getting those URLs to resolve is on my todo list
Eric Haas (Oct 10 2018 at 11:38):
bad - there is no validation error when the id is wrong. (Since it reads like one, I think this should be an invariant in R5 if it can be logically defined and assuming the intent is still valid.)
Last updated: Apr 12 2022 at 19:14 UTC
