Cause of Death Fact

RootsMagic
, ,
1

I am still using Rootsmagic v9, mainly because I have seen nothing in the upgrade notes that I need in v10. However, one failing I find (or perhaps can’t find) in v9 is a Cause of Death. I have seen suggestions to enter this in “Description” under the Death fact which I’ve actually done despite thinking it’s a dumb way to do it.
I can see that there is a way to create a custom fact but I’ve so far shied away from that on “future proofing” grounds although that also applies to Description.
So, firstly, is there a CauseofDeath fact in v9 that I’ve missed?
Second, is there one in v10 which would likely cause me to upgrade?
Finally, has anyone heard of one coming in v11 which might cause me to wait?

Many thanks

2

Cause of Death Fact is a Custom Fact anyone can add.

Many People simply add in the desc field vs separate fact.
You also have the health info now in RM10.

image
image413×241 3.29 KB

3

I feel pretty strongly about my data transferring from RM to other genealogy software. I suspect it’s not 100%, but I find that custom facts actually do transfer pretty well.

1 Like
4

Agreed – The exception might be if you do something whacky. (nothing I can think of at the moment)

5

Maybe, IDK. My question would be where do they transfer to? For example, if I put Cause of Death in Death Description and transfered to something like Legacy which does have a CoD fact where would my Death Descriptions transfer to. If they go to a Death Description field then I’m no better off, arguably I’m worse off because I have the fact in a wrong field and the CoD blank. Maybe there’s a mapping function in which case it may be Ok. I’m guessing from all this discussion that there’s no CoD in versions 9 or 10 and no one knows about 11? A sad omission.

6

@IanB No there is no built in Cause of Death fact in RM 9 and 10–not even sure if the developers know what they are going to have in RM 11 :grinning:

As for how it would end up on a gedcom transfer-- that is going to depend on the other genealogy program you are using-- after having used several other genealogy software programs, all my customized facts transferred to RM BUT needed to define the sentence in RM-- for some reason RM did NOT like the original birth, death and burial fact from that company we shall NOT name–so I ended up with 2 birth facts etc. which could be changed in bulk in RM 9 but one by one in RM 8…

I do have another genealogy software that I play with ( to check out things like this)-- some of the customized facts transferred-- the customized facts that did transfer are not perfect – such as the sentence the other company uses versus what was in RM…
This other company does have have Cause of Death fact-- so any cause of death that I entered under description WAS transferred to their built in Cause of Death fact-- my customized Cause of Death did transfer BUT NOT to their built in Cause of Death fact– in case anyone else is wondering the health info and DNA info did NOT transfer but a customized DNA fact did…
If you are like some on here who use several different programs, then I would suggest making a test database using Cause of Death fact vs in description --transfer it and see what results you get…

7

" so any cause of death that I entered under description WAS transferred to their built in Cause of Death fact"

Did the transfer dump all the text in the description field of the Death fact into a Cause of Death fact? I ask as I put various other facts in the description, from GRO references to addresses of informants, etc. If I did transfer to another program by GEDCOM I wouldn’t want that to happen.

8

Short of being very intelligent, how could a software parse the cause of death from the mixed data you input in a string of text? It’s going to be all or nothing.

1 Like
9

RM does not support the GEDCOM structure for Death Cause. A user cannot create a custom Fact type in RM that does because the software and database structure does not have a field that could be exported to the GEDCOM CAUS tag. RM only supports the GEDCOM custom EVEN structure in which it maps the Description field to the limited length tag value.

For some background on Cause of Death in GEDCOM, here’s Gemini’s take:

10

I guess I’m lost on this one. Why would someone even need a separate cause of death fact? Using the description field of the death fact is sufficient. If more information is needed I put it in the notes. My old program had a cause of death fact and I was perfectly happy to see that extra fact go away in RM.

1 Like
11

Do you not see a use to being able to report or collate common causes of death over generations?
Gedcom has a “CAUS” tag typically used for Cause of Death and I was hoping RM supported it or perhaps will support it.

12

It’s not so much a question of adding a Cause of Death fact type as it is a matter of support for a GEDCOM attribute for the DEATh tag which should be included in the RM Fact Type definition for conformant interchange with other software. A standalone CoD fact type is but a workaround of that shortcoming.

RM’s use of a value on the same line as the DEATh tag is not in accordance with GEDCOM and does not necessarily represent CoD - it could be anything. Most RM fact Types have the same structure and many therefore vary from the GEDCOM specs. That’s convenient for programming but less so for interchange.

13

@IanB I definitely see a need to report or collate not only common causes of death over generations BUT health issues in general…
For example-- Joe was a diabetic-his mother and 2 of his sister’s kids were diabetic…
Joe’s wife Ann had an uncle who was diabetic. On the descendants of Joe and Ann, they have 2 daughters and 1 son who are diabetic and 2 grandsons.

RM 10 has a special area to enter Health Info --will it transfer on a gedcom-NO but it could be set up to record cause of death under other-- there are at least 2 reports–this is one of the reports for Joe’s family above–everybody but Early Lee is related to Joe…

image
image572×291 20.2 KB

Just a thought

14

If we feel the need to include a cause of death in our trees presumably we feel it is worthwhile (otherwise it is a lot of time wasted typing). Accordingly it would be good to be able to accurately search the data without including all the other information we include in the Description field.

15

The only information I’ve ever entered into the death description is the actual cause of death.

1 Like
16

Greetings!
I’ve just now started using RM11. Learning it slowly.
One of the reasons I wanted RM11 is for reports.

Cause of Death.
I’ve seen where the stance is to put it in Description. Saw a post from 2012 saying that and now.

On some Death Certificates, there are:
Primary Cause (A)
Due to (B)
Due to (C)
And then Contributing to

In my head, each is a unique fact.

Using/expounding on the Diabetes example from earlier-
CoD (Immediate Cause A): Gangrene
Due to (B): Diabetes
Due to (C): Sweet Tooth
Contributing to : Elfs

How does one Document this? Is all of this put in the Description?
Or if I wanted to Search for all that had Diabetes as part of Death Certificate? Instead of showing Due to B, I’d get the whole description and have to figure out what part?

I appreciate your Knowledge Sharing and Logic
-Karl

17

At some point, you will probably need to acknowledge that neither RM’s data model nor the data model of any other genealogy app supports that level of detail and structure for cause of death. Just put the info into the note for the death fact.

18

Well – I have seen other people do all sort of things with the the desc field. I started putting COD in that field in FTM (2017? maybe) not long before I came to RM about 5 years ago

19

I hope this changes one day as I would like searchable data vs Research notes.

I am presuming this is due to the simplicity setup of GEDCOM?

Would love if a fact could have more than one description field.

20

The Description field “approach” (that You choose to implement) will need to be “linear” (ie.

CoD (Immediate Cause A): Gangrene Due to (B): Diabetes Due to (C): Sweet Tooth Contributing to : Elfs

-OR-

Gangrene < Diabetes < Sweet Tooth < Elfs

-OR-

(x)Gangrene ( )Right leg (x)Left Leg (x)Diabetes (x)Sweet Tooth (x) Elfs ( )WillyWonka Employee

-OR-

Descriptive narrative paragraph here that reads exactly as desired for export, but also works internal to RM (in conjunction with Death fact sentence template) for reports, lists, etc.

Note of interest, RootsMagic allows the user to enter (as many as) hundreds of thousands of characters into the Description field AND preserve that in a database, but when exported out to GEDCOM, it will be shortened to a little under 1200 or so.

Will you be consistently attaching a Source for death certificate, hospital record, obituary, hospitalization news article, etc.? Because finding People with Source citations containing any string of characters from your self-created representative “blurb” are easily located for editing via Find Everywhere. As for Death (Any Fact) Description field, it is available for Search/filtering/Find Everywhere, Marking for Groups and/or Color Coding and inclusion in Custom Reports.

What’s most important in these discussions is what You currently CANNOT do, clear suggestion(s) for change consideration to accommodate shortcomings, and any other ideas/discussion around how it might be more than just a “me TOO” request, that most other users might not use very frequently.

Designing a new Fact-type (eg. Cause of Death/Death Cause/CoD) is currently a feature. Creating one does not offer any extra “fields” to enter data into or extra capabilites beyond a Death fact itself, except for the “context” that the new Fact-type’s NAME/Label/Column/Tag might offer “visually” to humans reading their screen or a report/list/chart/group or filtering for in other program file-types (spreadsheets/text editors/AI/etc.).
eg. Father who had another spouse; Mother who had another spouse: Me, their child - #11 by Keith

The custom capability exists “rudimentarily” in RM because the programmer authors know that the future of genealogy features and standards will encompass such fact info as part of capability and interchange and they know they can/will have to adopt/adapt accordingly.

Edited to reflect a ~less specific~ character limit for Death {Description} Details field in block and in the database .