Zib-FamilySituationChild #418
Conversation
…cluding some basic manual examples
jd-nictiz
force-pushed
the
zib-FamilySituationChild
branch
from
616a47d
to
94d2a02
Compare
jd-nictiz
force-pushed
the
zib-FamilySituationChild
branch
from
2e5dd90
to
fb6cf8f
Compare
| </element> | ||
| <element id="List.mode"> | ||
| <path value="List.mode"/> | ||
| <comment value="This element has no functional counterpart in the zib and cannot be implicitly mapped to other concepts. Unless a more appropriate status is recorded, it is assumed that only _working_ or _snapshot_ List resources will be exchanged, depending on the functioning of the source system."/> |
There was a problem hiding this comment.
I wonder if we shouldn't make a stronger stance here. I think it's undesirable if one implementation creates a new List for each exchange over time while the next one updates the same List over and over again.
I think an argument can be made that the zib represents something fixed at some point in time and that each time it is readjusted, a new List resource will be created. (Then again, the argument could also be made that same resource should change over time).
There was a problem hiding this comment.
I think a .status of 'current' is much more important than the exact .mode. I do not think we are able to impose any additional implicit constraints on the . mode. We just cannot state that all systems involved will be able to use one of the modes.
https://hl7.org/fhir/R4/list-definitions.html#List.mode under 'Is Modifier' acknowledges that both modes snapshot and current contain a complete list.
The problem that you highlight here is not exclusive to this zib or profile, this goes for any fhir resource. Isn't it up to the standards to state something about this?
There was a problem hiding this comment.
The distinction is between a "living" object that keeps being updated, or an "observation". I think this is pretty unique for this profile.
There was a problem hiding this comment.
During meeting with the profilers: the zib does not provide enough information to choose one value over the other, but we could add a comment to hint that for anamnesis purposes snapshot would be the recommended value.
# Conflicts: # resources/zib/zib-ContactPerson.xml
No description provided.