Matthew Darlison wrote:
>Regardig new EHRs etc, might there be scope for mimicking what nature >does - a child EHR which for example must inherit its identifier >context from its mother as it really can only be identified >meaningfully by a qualifier of "this is the demographic person inside >which it is located"...? > This could be solved in at least two ways. 1. In the demographic server, we create 2 PERSONs, and use a foetus archetype for one. We put a mother/in utero PARTY_RELATIONSHIP between them. however, the in utero relationship as a clinical phenomenon is probably more important than the legal mother/child relationship, which is the kind of thing demographic systems are designed for (this relationship does not change as long as both parties are alive, but the carrying/in utero physical relationship is fairly temporary. 2. In the EHR system we use an archetype for a persistent transaction in the foetus's EHR which indicates the "in utero" situation (this would probably be the same archetype that carries other important clinical indicators, like "living", "deceased" etc). In the mother's EHR there is also a "carrying child" indicator. 2a. THese could refer to distinct demographic entities found in the demographic server, if we think that the foetus should be given one. If not (and I agree that it might not be that useful, since there is no name, contact address etc (other than the mother) and the foetus is not "contactable" in any real way - in fact it cannot act as a PARTY (i.e. participate in anything). So - let's say that the foetus either has nothing in the demographic system, or else we introduce a special party called "unborn foetus" (the same thing I suggest for "anonymous donor"). Then the Foetus can have a demographic entity to which its EHR is attached, without the needless creation of "real" PARTYs with all their details, all initially meaningless for a foetus (and probabl a newborn for quite some time...). The alternative which I imagine Sam would prefer is to make one or more transactions dedicated to the foetus in the mother's EHR and put them in their own "unborn child" folder or so. These would then be moved out of the mother's EHR when the baby is born. I think this would work ok, but it is kind of a special case, and we have to make sure all software understands it. Maybe we could formalise this situation so that one EHR can "give birth" to another, which is implied by Matthew's words. It sounds funny, but maybe it isn't - why not - there is nothing to stop us from defining a "give birth" operation on the interface of the EHR (trekkies and unix-heads will naturally insist that the operation be called "spawn", and who would I be to argue....?-). The situation is not necessarily the same for anonymous donors, since no care is being given to them - they don't need their own EHR - the observations of the organs etc belong in the EHR or the recipient since it is about his/her care, not the donors. For non-anonymous donors, then of course an EHR is needed - the health of both donor and recipient during kidney, bone marrow and other similar operations, and afterward is important jsut as in the normal situation of any individual. I am happy to see this discussed further; in summary I suggest that the basic possibilities are : a - create a new EHR as soon as a foetus has any observation done on it, link it to an "unborn baby" demographic entity b - define the semantics of an EHR "being pregnant" with another nascent EHR, and a "give birth to EHR"/"spawn EHR" operation to be carried out when the real birth takes place. (The less fortunate outcomes for the foetus could also make sense, as long as they have operations defined for them, including "abort", "die naturally" etc). Having thought of b), and the possibility of one day seeing one EHR give birth to another, I am quite taken with the possibility....however, it still creates the precedent that there are EHRs containing two (or more) subjects of care. thoughts? - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
