[Babase] The infamous dcauses
Susan Alberts
babase@www.eco.princeton.edu
Sun, 16 Oct 2005 15:14:31 -0400
I would be inclined to go with Karl's change so that there are no
restrictions on the dcause for fetal losses. My understanding is that
Jeanne was in the middle of reviewing dcauses a few years ago and got
as far as identifying and naming an updated set of dcauses but didn't
get through reviewing all the dcauses in babase. This means that
there are types of cases we haven't identified, probably. This is
obviously something we will have to come back to but perhaps it is a
good idea not to make a rule, at this point, that constrains or makes
difficult our reconsideration of this area.
I guess my general view is that, without constraining dcauses, it
will still not be difficult to ID fetal losses that occurred due to
death of the mother because those will generally be all cases where
the fetus died on the same day as the mother. It is possible but
unlikely that a female would have a miscarriage on a given day AND be
eaten by a lion on the same day but later, so that she and fetus died
on same day but had different dcauses. It is even more unlikely -- to
the point of impossible, I would almost be willing to say -- that we
could actually DETECT it if mom and fetus died of separate causes in
this way. If such an event occurred I feel confident that we could
figure out a way to make it clear.
This all requires and assumes a sophisticated user, as we've
discusssed before, but we can't get away from that.
How does this sound?
SUsan
>Hi,
>
>In the interest of actually finishing with something
>I'm looking at wrapping up BIOGRAPH and the
>issue of dcauses again came up. I'm looking for a
>decision here from Jeanne and Susan.
>
>The docs say:
>
>Those rows that record data on fetal losses must maintain the
>following relations between their data values: the Sname and Name
>values must be NULL; the Statdate must be the same as the birth date
>(Birth); the Status must be 1 (definitely dead); and the Dcause must
>be 7 (unknown) or 5 (loss of mother). Jeanne needs to confirm that
>this is still the case since her changes to DCAUSES.
>
>I want to change this to:
>
>Those rows that record data on fetal losses must maintain the
>following relations between their data values: the Sname and Name
>values must be NULL; the Statdate must be the same as the birth date
>(Birth); and the Status must not be 0 (alive).
>
>So, there are no restriction on the dcauses for fetal losses.
>This is consistent with what I recall was decided, but see
>below for the issues. (I think we have no written record
>of our ultimate decision.)
>
>For the record, here's the breakdown on dcauses for fetal losses.
>(Note spiffy query that manipulates summarized data.)
>
>babase=# select count(*), dcauses.dcause, descr from biograph,
>dcauses where sname is NULL and biograph.dcause = dcauses.dcause
>group by dcauses.dcause, dcauses.descr order by count(*) desc,
>dcauses.dcause;
>
> count | dcause | descr
>-------+--------+-------------------------------
> 137 | 8 | Under review
> 26 | 7 | Unknown
> 1 | 4 | Pathology/congenital problems
> 1 | 5 | Loss of mother
>(4 rows)
>
>See Daphne's mail to the list on:
>Date: Fri, 07 May 2004 11:23:58 -0400
>4) The situation that needs clarifying is when the fetus dies because
>the mother dies. At the beginning of the new dcause definition list, it
>says the following:
>
>------------------
>If a mother and infant disappear at the same time and a cause is
>attributed to the mother's death, the same cause is attributed to the
>infant's death unless contraindicated by available evidence.
>
>When Jeanne and Suan and I talked about dcauses earlier, and it was
>decided that this applied to infants AND fetuses (I have another note
>about this on the sheet). Do we want to stick with this? As I see it,
>this would have 2 implications. First, it would mean that aborts, if
>they are due to the mom's death, would NOT be restricted to certain
>dcauses - they could get whatever dcause was assigned to the mother.
>Second, it means that an infant (or fetus, if that's what we decide)
>would not get a dcause of 5 (loss of mother in both old and new lists)
>unless the mother's cause of death is unknown. (Right? Am I
>interpreting this correctly?) So I think there are some 5s for infants
>(and maybe fetuses) that should have the mother's dcause instead.
>Steph, I think it would be a good idea to check for these 5s, both in
>the pre-01b list I'm sending you, and in the post-01b data currently in
>Biograph, and see if they shouldn't get the mother's dcause instead.
>------------
>
>I then wrote:
>---------------
>Everything depends on how you're querying and using the data so long as
>either system of coding abort's dcauses you don't lose any information.
>Note that with the old way of encoding death due to mother's death
>you can query for that event directly and trace the dcause through to
>the dcause of the mother. With the new system it's easier to get
>abortion cause of death but harder to tell if the death is due to
>death of the mother. With the new system the assumption is that
>death is due to death of the mother when both infant and mother die
>on the same day. (Note that if they happen to die on the same day
>but in separate events you can only tell if the dcause is different
>for the mother and infant. Theoretically this is a problem
>with the new system's coding, the one place where information
>can be lost.) Seems like the 5 code is pretty much
>redundant in the new system as it always means "unknown".
>I'd consider getting rid of it for the sake of consistency.
>------------
>
>There's no more mail addressing the subject.
>
>
>Karl <kop@meme.com>
>Free Software: "You don't pay back, you pay forward."
> -- Robert A. Heinlein
>
>_______________________________________________
>Babase mailing list
>Babase@www.eco.princeton.edu
>http://www.eco.princeton.edu/mailman/listinfo/babase
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Susan Alberts, Associate Professor
Department of Biology, Duke University, Box 90338, Durham NC 27708
phone 919-660-7272 fax 919-660-7293