Ed
Thanks for that - I think this is the correct approach - recognising that
there will be times when a fetal record may be required - such as with
antenatal surgery etc.
Any thoughts on the EHR SIG?
Cheers, Sam
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
It is my belief that there will not be one good for all model of the
demographics.
There are several points of view: medical perinatologist, - genetical,
-peadiatrician, - gynacologist, - pharmacist, -etc, phycological,
sociological, legal, ethical, administrative, etc.
Each viewpoint will have different models for different contexts.
The consequence is that one RIM with one Demographics part will be to
restrictive.
One RIM with several types of demographic models (using
Archetypes/Templates) is the sensible way to think about it.
Gerard
<private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
+31 252 544896
+31 654 792800