Restructure FU Form layout and read-only view

[ij-cope]

In the Follow-up forms: When rejection (django.db.models.NullBooleanField) – “FB19 rejection” is answered as 'NO'

the following questions are given the answer 'MAYBE' rejection_prednisolone (django.db.models.NullBooleanField) – “FB20 treated with prednisolone” rejection_drug (django.db.models.NullBooleanField) – “FB21 treated with other drug” rejection_drug_other (django.db.models.CharField) – “FB22 Other rejection drug” rejection_biopsy (django.db.models.NullBooleanField) – “FB23 biopsy proven”

However, if “FB19 rejection” is NO, than the rest of the questions will not be answered (there is no need to answer them). It would be better to have the default answer be 'NOT APPLICABLE' as 'maybe' will cause confusion when data is analysed (as this would imply that a rejection might have been present while the question was answered as NO).

Print screens from WP415001R in the test environment:

[ij-cope]

@marshalc In Issue #150 - that covers the same topic and which I only found now - you ask:

Additionally, please suggest what you would like to have done with the existing data entered using either paper or previous online forms.

I believe most of the data entered as MAYBE should be NOT APPLICABLE but this needs to be checked

For paper forms - this check can be done when data is entered as the NOT APPLICABLE button would hopefully be available by then. For online forms completed - I would expect these to all answer MAYBE when Rejection is NO as this seems to be the default. I would not expect MAYBE to be answered if Rejection is YES because then a YES / NO should be available but this will need to be checked against the data.

Would you be able to provide us (Sarah and myself) with a report for all entered follow-up forms (closed cases cannot be viewed at the moment) so we can check what has been answered and if needed go back to the investigator to clarify?

Amending data entry (i.e. reopening closed forms and correcting data) would need to be done and is filed as Issue #168

This is fairly urgent as the more data entered into the system without the enhancements the more checking we will need to do.

[marshalc]

The "Maybe" outputs are a default result of the way Django interprets Null (or no data) answers to Boolean fields (i.e. Yes/No). The basic premise here is that NullBooleanFields should have validation to force an answer to be selected before saving - but that was veto'd on FU forms earlier. As real-world Yes/No questions have four possible answers, these should be reflected and recorded - something the paper forms don't address, and thus we have the same limitation in this version of the FU forms.

The changes here would be to identify which questions need amending to be Yes/No/Unknown/Not-answered, and which should be Yes/No/Not-answered. Additionally, any questions that are Not Applicable should be linked to the question or existing data item that identifies whether they are applicable or not, and thus they can be removed from the form dynamically when not applicable. I.e. We should not be asking questions that are not applicable, and their results should be marked as Unanswered.

This means working through the FU process and turning it into a proper web form and process, rather than a duplicate of a flawed and limited paper form.

Identifying what to do with existing data will have to wait till a new FU solution is proposed.

To that end, please can @ij-cope / @mertenssarah / @AllyBradley propose a structured list of questions (best represented as a hierarchical listing with conditional values highlighted) in this thread.

For example:

1. Question 1 : Y/N
   • If YES:
   • 1.1 Question : Free text
   • 1.2 Question : List of values
   • If NO:
   • 1.3 Question : Y/N/U
   • 1.4 Question : Int
2. Question 2 : Multiple choice
   • If choice includes OTHER:
   • 2.1 Question : Free text

Once I have that I can begin to work out changes and implementation issues.

The report request will need to be broken out into a separate issue for consideration and definition. I'll do that in a moment.

There is no close process on FU forms presently - they remain indefinitely open and open to indefinite changing - so I'm not sure what the closed forms refers to?

[marshalc]

... or I won't because #169 seems to mention this report request again...

[marshalc]

I'll flag this one for discussion on 12th Jan

[marshalc]

The discussion points are:

• Should we enhance the FU forms at this stage
  • If we do, need to get a defined structure for them, as close to the existing data as possible
• How do we address the S/AE reporting, e.g. death of patient, that isn't being done correctly because it's appearing in the FU data only (Issue #163)

[mertenssarah]

@marshalc How would you like me to show you how the hierarchy works in the FU forms. What would be the easiest way for you to make this clear?

Something like this or isn't this clear enough?

Rejection: Yes No If yes to rejection, questions below need answering: Post Tx Rejection treated with Prednisolon: Yes No Post Tx Rejection treated with other drug: Yes No If Yes, please specify: ……………………………………………………………………………………………………………………………………. If no to rejection, questions below are not applicable: Post Tx Rejection treated with Prednisolon:
Post Tx Rejection treated with other drug:

[mertenssarah]

As promised the document with the hierarchy in the FU forms. We also added which fields need to be completed for the form to count as ‘complete’. Hope the document is clear. WP4follow-up Data hierarchy.docx

[marshalc]

Word document structuring is poor (auto-layout appears to have removed tabs, so indentation versus formatting isn't as clear as I had wanted), so reformatting this into this Issue as text to clarify:

Follow Up Initial

1. Date Day 1: dd/mm/yyyy - start_date DateField
2. Patient Death Prompt - Issue #163.
3. Permanent Graft Loss within 7 days? Y/N - Form field, no data recorded. Uses has_graft_failed property
   • If YES:
     1. Date of graft failure: dd/mm/yyyy - graft_failure_date DateField
     2. Primary cause: (Now multiple choice, rather than a primary cause, so new fields!)
        • Immunologic - primary_cause_immunologic NullBooleanField
        • Preservation - primary_cause_preservation NullBooleanField
        • Technical Artery - primary_cause_artery NullBooleanField
        • Technical Venous - primary_cause_venous NullBooleanField
        • Infection Bacterial - primary_cause_bacterial NullBooleanField
        • Infection Viral - primary_cause_viral NullBooleanField
        • Patient Death - primary_cause_death NullBooleanField
        • Other - primary_cause_other TextField
4. Graft Removal? Y/N - Form field, no data recorded. Uses was_graft_removed property
   • If YES:
     1. Date of graft removal: dd/mm/yyyy - graft_removal_date DateField
5. Serum Creatinine:
   • Unit: 3 choices. Presumed same for all 7 days. - serum_creatinine_unit PositiveSmallIntegerField using UNIT_CHOICES
   • Day 1 Value: - serum_creatinine_1 DecimalField
   • Day 2 Value: - serum_creatinine_2 DecimalField
   • Day 3 Value: - serum_creatinine_3 DecimalField
   • Day 4 Value: - serum_creatinine_4 DecimalField
   • Day 5 Value: - serum_creatinine_5 DecimalField
   • Day 6 Value: - serum_creatinine_6 DecimalField
   • Day 7 Value: - serum_creatinine_7 DecimalField
6. Dialysis requirement:
   • Day 1 Y/N: - dialysis_requirement_1 NullBooleanField <- Because checkboxes don't address the difference between Not Answered, and No.
   • Day 2 Y/N: - dialysis_requirement_2 NullBooleanField
   • Day 3 Y/N: - dialysis_requirement_3 NullBooleanField
   • Day 4 Y/N: - dialysis_requirement_4 NullBooleanField
   • Day 5 Y/N: - dialysis_requirement_5 NullBooleanField
   • Day 6 Y/N: - dialysis_requirement_6 NullBooleanField
   • Day 7 Y/N: - dialysis_requirement_7 NullBooleanField

.... And this is where I have to stop this right now because this FU Form is ILLOGICAL and can not be represented in a computer as described in the Word document. Not to mention changes to data structures that will require further remapping of existing data (assuming remapping is possible).

@ij-cope @AllyBradley - I refer back to my comment above saying we need work through the FU process and turning it into a proper web form and process, rather than a duplicate of a flawed and limited paper form.

Pulling FU Form changes from the 0.8.0 release pending a F2F discussion and planning.

[ij-cope]

@marshalc - it would indeed seem most efficient to talk our way through this.

My week is pretty busy but this is important, so I can make time on Monday 20/3 PM or Tuesday 21/3 AM for a Skype call where I hope you can share screens etc.

Let me know

[marshalc]

Tuesday AM assuming @AllyBradley is available. I'll be focussing release today and ensuring that the live deployment works like the development given we're skipping the test step due to data issues.

[ij-cope]

I can make time between 11 and 12 AM on 21/3 where I will be able to answer specific questions you have with regard to the follow-up process and answers we would expect to receive. I will block this hour provisionally. Thanks for confirming - preferentially by a calendar invite.

Sarah is pivotal in the collection of follow-up data, as is Aukje, and I would like both of them to be kept updated even though I appreciate they may not be able to join a Skype call at this short notice.

[marshalc]

I'll let @AllyBradley handle the arrangements.

[marshalc]

Reminder that the FU data structure in use was set and cleared in Apr/May last year (see Issue #79) following conversations with Rutger. Please see the live site for reference to the questions asked and their formats (i.e. what is recorded) as this is the starting point for the discussion, not the paper forms from prior to this going live.

[ij-cope]

OK - I can access the test site - I have not logged on the the live site intentionally as is has become clear that I would see data I am not supposed to see (from a being blinded perspective).

For the purpose of the discussion, I had indeed envisioned going over the (live/test) site structure and go from there to optimise it as discussed during our F2F meeting. The important bit there were

1. patient death and SAE reporting
2. avoiding ambiguity between data not entered into the database, or data that are unknown.

@marshalc, I am waiting for your clearance to re-ask my password, which I assume will be OK with the next release.