[Babase] The infamous dcauses
Jeanne Altmann
babase@www.eco.princeton.edu
Mon, 17 Oct 2005 14:05:41 -0400
This is to confirm what I said on the conf call; I agree that decauses for
fetal losses should not be constrained.
jeanne
At 03:14 PM 16/10/2005, you wrote:
>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
>_______________________________________________
>Babase mailing list
>Babase@www.eco.princeton.edu
>http://www.eco.princeton.edu/mailman/listinfo/babase