Dear All > 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.
For all sorts of reasons one cannot separate the mother and fetus until quite late in pregnancy - many tests have implications for the fetus and for the mother and her pregnancy. > 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. I am not sure about this - I think this is getting far too complicated for what is a relatively simple situation and the reason why we had subject of care as a concept (along with family history and donation). > 2a. THese could refer to distinct demographic entities found in the > demographic server, if we think that the foetus should be given one. This goes against legal views as well as common practice and I think is the thin end of a large wedge that I would not like to see the EHR caught up in - the human status of a fetus - beware! > 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"). Don't forget there can be up to 8! > 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. It does not have to be the transaction - a scan of the uterus is a good example - much of the information is about the mother - but the length of the femur and abdominal circumference is clearly about the fetus and needs to be identified as such. Such a scan might then be copied to the child's EHR at some future date with a transform from 'fetus' to 'self' and from 'self' to 'mother'. > These would then be moved out of > the mother's EHR when the baby is born. No - they would be copied if appropriate - they are clearly related to the pregnancy and would stay there. > 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....?-). Quite a cute idea. > 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, No > link it to an "unborn baby" demographic entity Will have some specific markers as there may be more than 1. > b - define the semantics of an EHR "being pregnant" with another nascent This will have to evolve to some extent with experience. A Cardiotocogram is a good example - where the contractions are of the mother's uterus and the heart rate is of the fetus. But they are read together. > 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). These would stay in the mother's EHR - no need to 'clean up' at all. > > 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. That is why it is there! Sam ____________________________________________ Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __________________________________________ - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
