search

MathematicalMedicine / diver-issues

Semipublic tracking of issues for the DIVER front end
0 stars 0 forks source link

NRGR_ and promoted construct CAPS_ variables need their own generated PDF and a display approach #179

Open WValenti opened 1 year ago

Viqsi commented 1 year ago

After some realtime discussion, a generated PDF might not necessarily be required - but that would get Interesting(tm) on diverweb.

The structure desired is very similar to FHV details - each NRGR_ variable has "component variables" that contribute to it, and we want to be able to link to those variables' PDFs. Which is very reminiscent of how we display FHV component variables... except that these things can be themselves components of FHVs. Oh dear. So we'd potentially end up nesting things.

In diverweb, this could be done by recognizing such a variable in the system and linking not to a PDF but to another details page that displays this information (we would be able to pull it from the DB because @WValenti plans on making database entries for this stuff anyways; his tentative plan was to use that to generate PDFs). That does mean that if these things get nested that a user could find themselves drilling down into a maze of twisty passages... but that's inherent to the nature of the beast, and if they want to know that level of detail it's on them. It's not inherently required for app usage; it's for the super-curious.

Viqsi commented 9 months ago

The info's there per @WValenti so now this is entirely in my corner.

WValenti commented 9 months ago

An example is "head_injury" which is answered w/0/1/2 (No/Yes/DX), and can harmonize with i20070 but only after downcoding to produce NRGR_i20070.

This has been produced in codebooks as composition_variables.pdf, and its ATM taking the place of DIGS 3.0/B+ as an instrument PDF.

NOTE that MRI somehow did not get converted to NRGR_MRI.