We hope you'll join us for our 4/23 webinar on using data tables to apply reference ranges and AE codes in OC4. For more information and to register, visit https://register.gotowebinar.com/register/2882170018956684555

Administrative Editing and Hidden Groups

Hi all,

It is known that OpenClinica has an issue with hidden fields in repeating groups that lead to problems in Administrative Editing (see, e.g., https://docs.openclinica.com/release-notes/openclinica-3.1.4-release-notes). I have encountered a far more general problem which seems related: When I mark a CRF as complete which at that time has a hidden repeating group (no individual hidden items, but the whole group is hidden, it would be shown by means of a rule), OpenClinica displays a severe bug in later administrative editing: If I change a visible item, reason-for-change alerts are also given for all items in this hidden group. Of course, these fields are hidden, so (1) they have certainly not been changed and (2) I have no way to provide reasons for change for them (as I would need to be able to save the CRF to apply the rule to show them), so in effect the CRF cannot be changed at all after being marked as complete. This strange behaviour does not occur if all originally hidden tables are shown at the time the CRF is marked as complete.

This behaviour strikes me as really limiting, as we have employed hidden tables in our CRF a lot (e.g., have a table requesting details for inclusion/exclusion criteria displayed only if it has been stated that not all criteria have been met). Hiding repeating groups is an attractive feature and I cannot believe that it would generally interfere with administrative editing. However, I have now noted this behaviour across a number of different CRFs and different OpenClinica (albeit all 3.1.3.1) installations and have provided a minimal example in issue #18265.

Has anyone else experienced this problem or can anyone replicate it with the CRF and rule file I have provided? Are there any workarounds?

Many thanks!

Henrik

Henrik DITTMANN
Database Administrator
Br.E.A.S.T. Data Centre
Jules Bordet Institute
Bld de Waterloo, 121 (7th Floor)
1000 Brussels – Belgium
Tel: +32(0)2 541 7362
Fax: +32(0)2 541 3477
http://www.br-e-a-s-t.org
BrEAST
Confidentiality Note: This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information.
If you are not the intended recipient, please contact the sender and delete this message. Any unauthorized use of the information contained in this message is prohibited.
P

Please consider the Environment before printing this email.


Disclaimer : http://www.bordet.be/disclaimer/disclaimer.html

Comments

  • anneliesrotteanneliesrotte Posts: 11
    Hi Henrik,
    The good news is a workaround is available, but the investigator or data entry person need to contact the Study Director, Busines or technical administrator for that.
    The work around is that the businessadministrator can go to the specific CRF for the subject and select: Remove and confirm with Remove Event CRF and confirm again with OK. After this action undo that action by selecting Restore and confirm by click on Restore Event CRF and confirm again with OK. After that the CRF is no longer marked complete.
    At http://www.trialdatasolutions.com/tds/howto/transferdatanewversion.jsp Gerben Rienk describes a similer issue for data being imported through webservices:
    The CRF is marked as complete, as a result of the import. This means we have to give a reason for change and whatever reason we give, we can not save the CRF! (OpenClinica tries to add a Discrepancy Note to a DataItem, but the DataItem does not exist.) The trick to remove the "Marked as Complete" status is to "Remove" the CRF. That's the blue cross-icon, no the red one. Immediately after we've done that, we restore it and now the status is set to "Data Entry Started" and we can edit whatever we like.
    Annelies

    Van: [email protected] [mailto:[email protected]] Namens Dittmann Henrik
    Verzonden: woensdag 26 juni 2013 20:02
    Aan: [email protected]
    Onderwerp: [Users] Administrative Editing and Hidden Groups

    Hi all,

    It is known that OpenClinica has an issue with hidden fields in repeating groups that lead to problems in Administrative Editing (see, e.g., https://docs.openclinica.com/release-notes/openclinica-3.1.4-release-notes). I have encountered a far more general problem which seems related: When I mark a CRF as complete which at that time has a hidden repeating group (no individual hidden items, but the whole group is hidden, it would be shown by means of a rule), OpenClinica displays a severe bug in later administrative editing: If I change a visible item, reason-for-change alerts are also given for all items in this hidden group. Of course, these fields are hidden, so (1) they have certainly not been changed and (2) I have no way to provide reasons for change for them (as I would need to be able to save the CRF to apply the rule to show them), so in effect the CRF cannot be changed at all after being marked as complete. This strange behaviour does not occur if all originally hidden tables are shown at the time the CRF is marked as complete.

    This behaviour strikes me as really limiting, as we have employed hidden tables in our CRF a lot (e.g., have a table requesting details for inclusion/exclusion criteria displayed only if it has been stated that not all criteria have been met). Hiding repeating groups is an attractive feature and I cannot believe that it would generally interfere with administrative editing. However, I have now noted this behaviour across a number of different CRFs and different OpenClinica (albeit all 3.1.3.1) installations and have provided a minimal example in issue #18265.

    Has anyone else experienced this problem or can anyone replicate it with the CRF and rule file I have provided? Are there any workarounds?

    Many thanks!

    Henrik

    Henrik DITTMANN
    Database Administrator
    Br.E.A.S.T. Data Centre
    Jules Bordet Institute
    Bld de Waterloo, 121 (7th Floor)
    1000 Brussels - Belgium
    Tel: +32(0)2 541 7362
    Fax: +32(0)2 541 3477
    http://www.br-e-a-s-t.org
    BrEAST
    Confidentiality Note: This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information.
    If you are not the intended recipient, please contact the sender and delete this message. Any unauthorized use of the information contained in this message is prohibited.
    P

    Please consider the Environment before printing this email.


    Disclaimer : http://www.bordet.be/disclaimer/disclaimer.html
  • Henrik DittmannHenrik Dittmann Posts: 17
    Dear Annelies, dear all,

    Thanks for the workaround. We are afraid that this would still leave us with a lot of work in data management and monitoring, so we have now opted for another solution.

    One point I had not mentioned in my original mail was that we had "Forced Reason For Change in Administrative Editing" activated in the study setup. If you deactivate that, you don’t have the behaviour I have described. We now have opted to forgo a forced Reason for Change, which should get us the closest to where we want to be.

    Best, Henrik


    From: Annelies Rotte [mailto:[email protected]]
    Sent: 27 June 2013 12:23
    To: [email protected]; [email protected]
    Subject: Re: [Users] Administrative Editing and Hidden Groups

    Hi Henrik,
    The good news is a workaround is available, but the investigator or data entry person need to contact the Study Director, Busines or technical administrator for that.
    The work around is that the businessadministrator can go to the specific CRF for the subject and select: Remove and confirm with Remove Event CRF and confirm again with OK. After this action undo that action by selecting Restore and confirm by click on Restore Event CRF and confirm again with OK. After that the CRF is no longer marked complete.
    At http://www.trialdatasolutions.com/tds/howto/transferdatanewversion.jsp Gerben Rienk describes a similer issue for data being imported through webservices:
    The CRF is marked as complete, as a result of the import. This means we have to give a reason for change and whatever reason we give, we can not save the CRF! (OpenClinica tries to add a Discrepancy Note to a DataItem, but the DataItem does not exist.) The trick to remove the "Marked as Complete" status is to "Remove" the CRF. That's the blue cross-icon, no the red one. Immediately after we've done that, we restore it and now the status is set to "Data Entry Started" and we can edit whatever we like.
    Annelies

    Van: [email protected] [mailto:[email protected]] Namens Dittmann Henrik
    Verzonden: woensdag 26 juni 2013 20:02
    Aan: [email protected]
    Onderwerp: [Users] Administrative Editing and Hidden Groups

    Hi all,

    It is known that OpenClinica has an issue with hidden fields in repeating groups that lead to problems in Administrative Editing (see, e.g., https://docs.openclinica.com/release-notes/openclinica-3.1.4-release-notes). I have encountered a far more general problem which seems related: When I mark a CRF as complete which at that time has a hidden repeating group (no individual hidden items, but the whole group is hidden, it would be shown by means of a rule), OpenClinica displays a severe bug in later administrative editing: If I change a visible item, reason-for-change alerts are also given for all items in this hidden group. Of course, these fields are hidden, so (1) they have certainly not been changed and (2) I have no way to provide reasons for change for them (as I would need to be able to save the CRF to apply the rule to show them), so in effect the CRF cannot be changed at all after being marked as complete. This strange behaviour does not occur if all originally hidden tables are shown at the time the CRF is marked as complete.

    This behaviour strikes me as really limiting, as we have employed hidden tables in our CRF a lot (e.g., have a table requesting details for inclusion/exclusion criteria displayed only if it has been stated that not all criteria have been met). Hiding repeating groups is an attractive feature and I cannot believe that it would generally interfere with administrative editing. However, I have now noted this behaviour across a number of different CRFs and different OpenClinica (albeit all 3.1.3.1) installations and have provided a minimal example in issue #18265.

    Has anyone else experienced this problem or can anyone replicate it with the CRF and rule file I have provided? Are there any workarounds?

    Many thanks!

    Henrik

    Henrik DITTMANN
    Database Administrator
    Br.E.A.S.T. Data Centre
    Jules Bordet Institute
    Bld de Waterloo, 121 (7th Floor)
    1000 Brussels - Belgium
    Tel: +32(0)2 541 7362
    Fax: +32(0)2 541 3477
    http://www.br-e-a-s-t.org
    BrEAST
    Confidentiality Note: This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information.
    If you are not the intended recipient, please contact the sender and delete this message. Any unauthorized use of the information contained in this message is prohibited.
    P

    Please consider the Environment before printing this email.


    Disclaimer : http://www.bordet.be/disclaimer/disclaimer.html
    Disclaimer : http://www.bordet.be/disclaimer/disclaimer.html
  • agoodwinagoodwin Posts: 131 admin
    Hello Henrik,
    Thank you for reporting this issue. I did add it to Jira: http://jira.openclinica.com:8081/browse/OC-2924 . We will consider fixing it in a future release. I am not sure we will be able to include it in the next release, but we'll look into it and try to size it.
    It is possible that this will be addressed when we rewrite data entry entirely (which is on our longer term roadmap: https://docs.openclinica.com/release-notes) .

    Best Regards,
    Alicia
    On Wed, Jul 3, 2013 at 11:02 AM, Dittmann Henrik wrote:
    Dear Annelies, dear all,

    Thanks for the workaround. We are afraid that this would still leave us with a lot of work in data management and monitoring, so we have now opted for another solution.

    One point I had not mentioned in my original mail was that we had "Forced Reason For Change in Administrative Editing" activated in the study setup. If you deactivate that, you don’t have the behaviour I have described. We now have opted to forgo a forced Reason for Change, which should get us the closest to where we want to be.

    Best, Henrik


    From: Annelies Rotte [mailto:[email protected]]
    Sent: 27 June 2013 12:23
    To: [email protected]; [email protected]
    Subject: Re: [Users] Administrative Editing and Hidden Groups

    Hi Henrik,
    The good news is a workaround is available, but the investigator or data entry person need to contact the Study Director, Busines or technical administrator for that.
    The work around is that the businessadministrator can go to the specific CRF for the subject and select: Remove and confirm with Remove Event CRF and confirm again with OK. After this action undo that action by selecting Restore and confirm by click on Restore Event CRF and confirm again with OK. After that the CRF is no longer marked complete.
    At http://www.trialdatasolutions.com/tds/howto/transferdatanewversion.jsp Gerben Rienk describes a similer issue for data being imported through webservices:
    The CRF is marked as complete, as a result of the import. This means we have to give a reason for change and whatever reason we give, we can not save the CRF! (OpenClinica tries to add a Discrepancy Note to a DataItem, but the DataItem does not exist.) The trick to remove the "Marked as Complete" status is to "Remove" the CRF. That's the blue cross-icon, no the red one. Immediately after we've done that, we restore it and now the status is set to "Data Entry Started" and we can edit whatever we like.
    Annelies

    Van: [email protected] [mailto:[email protected]] Namens Dittmann Henrik
    Verzonden: woensdag 26 juni 2013 20:02
    Aan: [email protected]
    Onderwerp: [Users] Administrative Editing and Hidden Groups

    Hi all,

    It is known that OpenClinica has an issue with hidden fields in repeating groups that lead to problems in Administrative Editing (see, e.g., https://docs.openclinica.com/release-notes/openclinica-3.1.4-release-notes). I have encountered a far more general problem which seems related: When I mark a CRF as complete which at that time has a hidden repeating group (no individual hidden items, but the whole group is hidden, it would be shown by means of a rule), OpenClinica displays a severe bug in later administrative editing: If I change a visible item, reason-for-change alerts are also given for all items in this hidden group. Of course, these fields are hidden, so (1) they have certainly not been changed and (2) I have no way to provide reasons for change for them (as I would need to be able to save the CRF to apply the rule to show them), so in effect the CRF cannot be changed at all after being marked as complete. This strange behaviour does not occur if all originally hidden tables are shown at the time the CRF is marked as complete.

    This behaviour strikes me as really limiting, as we have employed hidden tables in our CRF a lot (e.g., have a table requesting details for inclusion/exclusion criteria displayed only if it has been stated that not all criteria have been met). Hiding repeating groups is an attractive feature and I cannot believe that it would generally interfere with administrative editing. However, I have now noted this behaviour across a number of different CRFs and different OpenClinica (albeit all 3.1.3.1) installations and have provided a minimal example in issue #18265.

    Has anyone else experienced this problem or can anyone replicate it with the CRF and rule file I have provided? Are there any workarounds?

    Many thanks!

    Henrik

    Henrik DITTMANN
    Database Administrator
    Br.E.A.S.T. Data Centre
    Jules Bordet Institute
    Bld de Waterloo, 121 (7th Floor)
    1000 Brussels - Belgium
    Tel: +32(0)2 541 7362
    Fax: +32(0)2 541 3477
    http://www.br-e-a-s-t.org
    BrEAST
    Confidentiality Note: This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information.
    If you are not the intended recipient, please contact the sender and delete this message. Any unauthorized use of the information contained in this message is prohibited.
    P

    Please consider the Environment before printing this email.


    Disclaimer : http://www.bordet.be/disclaimer/disclaimer.html
    Disclaimer : http://www.bordet.be/disclaimer/disclaimer.html
  • lindsay.stevenslindsay.stevens Posts: 404 ✭✭✭
    I think another workaround is to put the grid item group on a different section to the rule trigger. Because the grid isn't being saved at the time that the show rule is triggered you shouldn't get the notes bug. If the grid is the only thing on that other section then the section is shown when the grid is shown.
    I had set up a CRF in this way, e.g. section 1 has non-repeating item 'did you have any reportable events' yes/no; if yes then a grid on section 2 is shown, and each event can be recorded in the grid.
    There would still be the workflow with forced reason for change where if you'd said 'no' on section 1 then marked complete, came back and changed it to 'yes', when you start entering events on the section 2 grid you have to give a reason for change for every value.
    I think that's reasonable but we probably need a way for regular site-level users to undo 'mark CRF complete', so that there is an alternative to asking the admin to remove/restore the CRF. Even better if you could switch the undo-mark-complete ability on or off for your study or site or event or crf or user.
    Best regards,
    Lindsay
    On 24 July 2013 06:20, Alicia Goodwin wrote:
    Hello Henrik,
    Thank you for reporting this issue. I did add it to Jira: http://jira.openclinica.com:8081/browse/OC-2924 . We will consider fixing it in a future release. I am not sure we will be able to include it in the next release, but we'll look into it and try to size it.
    It is possible that this will be addressed when we rewrite data entry entirely (which is on our longer term roadmap: https://docs.openclinica.com/release-notes) .

    Best Regards,
    Alicia
    On Wed, Jul 3, 2013 at 11:02 AM, Dittmann Henrik wrote:
    Dear Annelies, dear all,

    Thanks for the workaround. We are afraid that this would still leave us with a lot of work in data management and monitoring, so we have now opted for another solution.

    One point I had not mentioned in my original mail was that we had "Forced Reason For Change in Administrative Editing" activated in the study setup. If you deactivate that, you don’t have the behaviour I have described. We now have opted to forgo a forced Reason for Change, which should get us the closest to where we want to be.

    Best, Henrik


    From: Annelies Rotte [mailto:[email protected]]
    Sent: 27 June 2013 12:23
    To: [email protected]; [email protected]
    Subject: Re: [Users] Administrative Editing and Hidden Groups

    Hi Henrik,
    The good news is a workaround is available, but the investigator or data entry person need to contact the Study Director, Busines or technical administrator for that.
    The work around is that the businessadministrator can go to the specific CRF for the subject and select: Remove and confirm with Remove Event CRF and confirm again with OK. After this action undo that action by selecting Restore and confirm by click on Restore Event CRF and confirm again with OK. After that the CRF is no longer marked complete.
    At http://www.trialdatasolutions.com/tds/howto/transferdatanewversion.jsp Gerben Rienk describes a similer issue for data being imported through webservices:
    The CRF is marked as complete, as a result of the import. This means we have to give a reason for change and whatever reason we give, we can not save the CRF! (OpenClinica tries to add a Discrepancy Note to a DataItem, but the DataItem does not exist.) The trick to remove the "Marked as Complete" status is to "Remove" the CRF. That's the blue cross-icon, no the red one. Immediately after we've done that, we restore it and now the status is set to "Data Entry Started" and we can edit whatever we like.
    Annelies

    Van: [email protected] [mailto:[email protected]] Namens Dittmann Henrik
    Verzonden: woensdag 26 juni 2013 20:02
    Aan: [email protected]
    Onderwerp: [Users] Administrative Editing and Hidden Groups

    Hi all,

    It is known that OpenClinica has an issue with hidden fields in repeating groups that lead to problems in Administrative Editing (see, e.g., https://docs.openclinica.com/release-notes/openclinica-3.1.4-release-notes). I have encountered a far more general problem which seems related: When I mark a CRF as complete which at that time has a hidden repeating group (no individual hidden items, but the whole group is hidden, it would be shown by means of a rule), OpenClinica displays a severe bug in later administrative editing: If I change a visible item, reason-for-change alerts are also given for all items in this hidden group. Of course, these fields are hidden, so (1) they have certainly not been changed and (2) I have no way to provide reasons for change for them (as I would need to be able to save the CRF to apply the rule to show them), so in effect the CRF cannot be changed at all after being marked as complete. This strange behaviour does not occur if all originally hidden tables are shown at the time the CRF is marked as complete.

    This behaviour strikes me as really limiting, as we have employed hidden tables in our CRF a lot (e.g., have a table requesting details for inclusion/exclusion criteria displayed only if it has been stated that not all criteria have been met). Hiding repeating groups is an attractive feature and I cannot believe that it would generally interfere with administrative editing. However, I have now noted this behaviour across a number of different CRFs and different OpenClinica (albeit all 3.1.3.1) installations and have provided a minimal example in issue #18265.

    Has anyone else experienced this problem or can anyone replicate it with the CRF and rule file I have provided? Are there any workarounds?

    Many thanks!

    Henrik

    Henrik DITTMANN
    Database Administrator
    Br.E.A.S.T. Data Centre
    Jules Bordet Institute
    Bld de Waterloo, 121 (7th Floor)
    1000 Brussels - Belgium
    Tel: +32(0)2 541 7362
    Fax: +32(0)2 541 3477
    http://www.br-e-a-s-t.org
    BrEAST
    Confidentiality Note: This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information.
    If you are not the intended recipient, please contact the sender and delete this message. Any unauthorized use of the information contained in this message is prohibited.
    P

    Please consider the Environment before printing this email.


    Disclaimer : http://www.bordet.be/disclaimer/disclaimer.html
    Disclaimer : http://www.bordet.be/disclaimer/disclaimer.html
This discussion has been closed.