Stream: patient administration WG
Topic: GF#16429 remove STU-Tag from merge
Simone Heckmann (Aug 03 2018 at 11:01):
...does the resolution mean, we also remove the feedback link from http://build.fhir.org/patient.html#merge pointing at http://wiki.hl7.org/index.php?title=FHIR_Specification_Feedback_(STU_3) ???
Brian Postlethwaite (Aug 07 2018 at 00:02):
@Grahame Grieve, each of the places those links exist for feedback I assume we should be updating at the last moment to a new location for R4?
Grahame Grieve (Aug 07 2018 at 00:44):
well, it can't be 'STU feedback' if it's normative content. Ideally, all that should be resolved. And if you still want input, what kind of actions might you take?
Brian Postlethwaite (Aug 07 2018 at 00:54):
The STU title is being removed as suggested in the tracker, however the think to link to for additional feedback on the non normative descriptive content is needed
Brian Postlethwaite (Aug 07 2018 at 00:54):
And I expect all the other locations in the spec where feedback is being sought will need to be updated to the new location also (non STU3)
Grahame Grieve (Aug 07 2018 at 00:55):
well, if the content is trial-use then you can continue asking for STU feedback
Grahame Grieve (Aug 07 2018 at 00:55):
I'll update the location late in the processing under my authority as product director to fix external links
Brian Postlethwaite (Aug 07 2018 at 00:55):
Excellent, thanks for that.
Brian Postlethwaite (Aug 07 2018 at 00:56):
This is an odd one, as the text itself is accurate and very generic in nature, hence is ok on the normative nature, but the details of the implementation and implications are what would be in the feedback. - More of an FYI now.
Grahame Grieve (Aug 07 2018 at 00:56):
The description of the merging is very generic in nature and does not describe any operational or data requirements, and thus will be accurate for any implementation of merge capabilities defined in the future.
Grahame Grieve (Aug 07 2018 at 00:57):
well... not so easy. Are you going consider adding normative rules about merge that might mean existing implementations are no longer conformant?
Grahame Grieve (Aug 07 2018 at 00:57):
... because I don't see how you could not be considering that
Grahame Grieve (Aug 07 2018 at 00:57):
but if you are, the description might be fine, but you're going to have a problem adding new rules
Brian Postlethwaite (Aug 07 2018 at 01:00):
There is no definition of merge as it is, so there is no normative rule existing, it acknowledges the problem space, and seeks feedback on the implementation. So there is no "conformant merge" at present, so won't be breaking things.
Grahame Grieve (Aug 07 2018 at 01:01):
should observation resources from all linked/merged patients be returned when querying for one of them
Grahame Grieve (Aug 07 2018 at 01:01):
that sounds like making breaking change to me?
Brian Postlethwaite (Aug 07 2018 at 01:01):
Its a question, not a statement on the page.
Grahame Grieve (Aug 07 2018 at 01:03):
but some of the possible answers would involve breaking change... so procedurally, I think there is only one possible answer to the question: no.
Brian Postlethwaite (Aug 07 2018 at 01:03):
If you thought we should restructure the wording to make it more obvious that it is a question, and not a statement as to how to do the merge.
Grahame Grieve (Aug 07 2018 at 01:04):
what I'm getting it is that in 2 places, we've said: we will be considering making changes here, implementers are warned. We think that gives a little wiggle room. So I'd like the same here: leave the question, but make a definitive statement about this. here's an example:
Grahame Grieve (Aug 07 2018 at 01:05):
The impact of Code System supplements on value set expansion - and therefore value set validation - is subject to ongoing experimentation and implementation testing, and further clarification and additional rules might be proposed in future versions of this specification.
from just above http://build.fhir.org/valueset.html#identifiers
Brian Postlethwaite (Aug 07 2018 at 01:05):
Ok, I'll do some word-smithing along that lines and get back to you.
Grahame Grieve (Aug 07 2018 at 01:06):
thx
Brian Postlethwaite (Aug 08 2018 at 13:07):
ok, here is the proposed wording
<b>Note:</b> We are seeking input from the implementer community on what effect linking/merging/unlinking should have on other functionality such as the GET operation, searching, reverse includes, etc.;<br/> How should an unlink behavior be done?<br/> How will the patient compartment interact with the merge?<br/> This functionality and related behaviors is subject to ongoing experimentation and implementation testing. With a definition to be proposed in a future version of this specification. </p>
@Grahame Grieve for your review
Grahame Grieve (Aug 08 2018 at 20:09):
looks good to me
Last updated: Apr 12 2022 at 19:14 UTC
