The initial proposal was that they would use the Description to record the particular maladies affecting the person. But since their goal was to eventually calculate a genetic predisposition to fatal illnesses, I felt this would be too difficult to maintain enough consistency for analysis.
I suggested that they use ICD-10 codes ( International Classification of Diseases) as a custom attribute instead. It would be less susceptible to typos.
But the question then becomes, how do you export Custom Attributes with their Events (or other objects) to a CSV file for analysis?
nlc-icd10-classifier A simple web app that shows how Watson’s Natural Language Classifier (NLC) can classify ICD-10 code. The app is written in Python using the Flask framework and leverages the Watson Developer Cloud Python SDK
Just curious, are they tracking only diseases which resulted in death, or also any case of such diseases even if the person survived that and then later died of something else (or is still living)? In other words, does this really belong on a Disease event rather than a Death event?
If I knew enough Python, I would add add the attribute as a column to the Event category view so that it could be included when exporting the view as csv. And if I knew more Python than that, I would make the category view configurable so that the user could choose which attributes to add. But I don’t, so instead I would export my database to SQLite and write some SQL.
If the Attribute is stored as Cause of Death type Event, then yes. Interestingly, the co-morbidity Python tool creates a 3x3 matrix of ICD Codes for analyzing contributing or underlying conditions.
However, the Medical Information type Events could be used for wider purposes: recording medical procedures, inoculations, illnesses. ICD codes are commonly used for Medical Billing purposes and could be used for building a living Medical History. A new report for an Individual’s Medical Information could generate something you take to a new doctor or for a Hospital stay.
I believe that an explicitly naming an Event type or specifying it in the Description is too error-prone. ICD codes are easier to group & validate.
Although new features are always welcome, I am more interested in what is possible NOW. We have 2 built-in Event types that are viable for the purpose. And a single Attribute would allow adding nearly infinite resolution.
Can a CSV formatted report be written (by an end-user) that includes a user defined Attribute value?
Sorry I wasn’t clear. I mean, instead of putting the code in the value of the attribute, you could put it in the description of a “Disease” event".
Regardless of where you store the code, you’ll need a lookup table to decode it into the appropriate description, unless you concatenate the code and description and store that as the value of the attribute (or as the description of the event). That’s one reason why it might be better to export the data from Gramps.
Yes, users who know enough Python can create their own add-on reports. Or are you referring to something else?
It isn’t that no one wants to… it’s just that everybody has their own projects and limits to their capacity.
I want to rework large parts of the manual where the information is scattered. But the questions that pop-up in the support forums send me haring off after answers to those questions & nearly always require a tweak to clarify the wiki or a Bug Report for some under-explored interaction. The experience is enlightening but leaves me scattered and frustrated.
In other projects involving database systems, writing reports has proven a Users entry point for expanding file export options.
I often wrote a reports that output in the target system’s format. Reports allowed incremental on-screen development of simple structured formats (like tab delimited or comma separated) without the hassle of getting a development project approved. Once it worked on-screen, I’d redirect the output to file.
Once that file actually worked for import, I’d have a validated design document that could easily be converted to a subroutine which eliminated the bottleneck of the redirection. And then it was a trivial task for a competent programmer to adapt my clumsy hack into clean feature for the program.
I’d like to write similar reports for Gramps. They would be good sample reports (covering all the data structures) that people can adapt into standard Genealogical reports or webpages. And adapt into other formats.
As far as I can see (which, admittedly, is perhaps not far enough) the “simple access API” doesn’t seem to expose attributes. But at least, I think, it gives you a handle to the objects to which the attributes are attached, so maybe you could still access them when writing a report using that API. Otherwise I guess you would have to navigate the data model directly, perhaps looking at the code for the Extended Attributes gramplet for clues.
I too would like to try writing reports someday, but since I’m more familiar with SQL than Python, I currently find it much easier to use the SQLite export. (It’s also less risky! )
By the way, has anyone ever used the “Query” add-on? I haven’t been able to get it to register, though I don’t get any errors about it.