[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