Stream: conformance
Topic: ElementDefinition.id
Grahame Grieve (Jun 06 2016 at 13:49):
@Chris Grenz: I'm going to commit some changes in for elementdefinition.id for consideration
Grahame Grieve (Jun 06 2016 at 13:50):
instead of what we talked about, I've done something slightly different: I'm leaving the root on the id, and appending the slice name with a : instead of a .
Grahame Grieve (Jun 06 2016 at 13:50):
root:name.element.element:slice.element
Grahame Grieve (Jun 06 2016 at 13:50):
I think it delivers what you need, but is easier to generate and manage, and ensures wider uniqueness to
Grahame Grieve (Jun 06 2016 at 13:51):
but I've run of time to commit it before the call
Chris Grenz (Jun 06 2016 at 14:31):
don't like the inconsistency of root:firstelement vs. element:slice, but overall I'm OK with that approach. So we could also have element:slice/reslice ?
Grahame Grieve (Jun 07 2016 at 22:49):
yes. and I don't think it's inconsistent, actually. root:name is still element:slice.
Grahame Grieve (Jun 07 2016 at 22:49):
I could've described it more consistently
Grahame Grieve (Jun 07 2016 at 22:50):
I've committed my changes, minus the constraint that element id values must be unique in a snapshot and differential. When I build with that, I get a series of failures that surface bugs in snapshot generation. I'm working through them slowly
Grahame Grieve (Jun 29 2016 at 22:26):
Follow up for @Alexander Henket referred here from elsewhere. See task 10256
Grahame Grieve (Jun 29 2016 at 22:27):
task 10256 is resolved by the resolution on task 9843.
Grahame Grieve (Jun 29 2016 at 22:27):
I don't understand the releveance of concept map and structure map
Alexander Henket (Jun 30 2016 at 05:57):
http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9843
Yes that indeed is everything we wanted, so is making it required a business rules enforced by the build tool or something? I know Forge doesn't currently create them (I'll point @Michel Rutten to this tracker item) and I also found several profiles that do not adhere to the rule.
As for ConceptMap and StructureMap (and ElementDefinition.mapping): we have been examining various ways to do what we wanted. ConceptMap contains very confusing wording on what its intended purpose is. Especially on ConceptMap.SourceElement.code you would get the impression that it is suitable for our purposes and that ConceptMap is not meant just for code equivalence.
StructureMap is what you pointed us to when we first came forward with our requirements, but we found that the solution was lacking examples to determine suitability, but even without examples it felt like something we could not apply in our context given the toolset and nature of artifacts. Lastly from what we could tell it seemed to be overly complicated.
Finally ElementDefinition.mapping looked appealing, but those would require us to update third party profiles if we want to leverage work others have done.
In short: the Element.id request was on a detail of making mapping possible. The ConceptMap/StructureMap remarks were part of our venture into various ways of defining the mapping with those Element.ids
Grahame Grieve (Jun 30 2016 at 21:04):
well, we only made the changes around ElementDefinition.id last week, so of course Forge hasn't done that yet.
Grahame Grieve (Jun 30 2016 at 21:06):
ConceptMap was originally intended to handle mapping between models, but when we started investigating that, it became clear that it fell short of requirements by an order of magnitude.
Grahame Grieve (Jun 30 2016 at 21:07):
if you're just mapping concepts between models, then you can still do that with ConceptMap, but it won't enable conversion of data. If you think that StructureMap is too complicated, then you haven't tried to convert data driven by ConceptMap.
Grahame Grieve (Jun 30 2016 at 21:08):
Since we narrowed the intent of ConceptMap, we haven't fully updated the narrrative, nor have we made it clear how you would map between concepts in models, though mostly we can't, since we only control one end...
Chris Grenz (Jul 06 2016 at 20:16):
@Grahame Grieve Looking at how you've implemented element id...appears that each token is path:slicename. Assume slicename for reslices is the / separated form? Is the pattern documented anywhere?
Chris Grenz (Jul 06 2016 at 20:17):
Also, I expected the ElementDefinition profile to be updated with id required?
Chris Grenz (Jul 06 2016 at 20:17):
Found this... http://hl7-fhir.github.io/extension-patient-birthtime.xml.html
<element id="Extension.value[x]">
<path value="Extension.valueDateTime"/>
is this intended?
Chris Grenz (Jul 06 2016 at 20:19):
Id should be either Extension.valueDateTime OR Extension.value[x]:valueDateTime if we want to consider variable types "slices" in this case.
Chris Grenz (Jul 06 2016 at 20:22):
And another ??? http://hl7-fhir.github.io/daf/daf-patient.profile.xml.html
<element id="Patient:DAF-Patient"> <path value="Patient"/> <name value="DAF-Patient"/>
Not a slice...are we continuing to allow name on non-sliced elements? I thought we agreed that name was ONLY allowed at the slice root...
Chris Grenz (Jul 06 2016 at 20:22):
Understand that this may all just be lag in the tooling being updated...just wondering what the end state intent is so I can update my tooling for my work with Ewout.
Grahame Grieve (Jul 06 2016 at 21:52):
mostly this is lag in the implementation. I'm not sure about the name on the root - I'll have to investigate that
Last updated: Apr 12 2022 at 19:14 UTC
