repeaqting group vs repeating event

Hi everyone

We’ve been using a simple repeating group on both our conmeds and adverse events CRFs (and any other “log” style CRFs), which I think is fairly standard practice.

However, we’ve noticed that there are some issues with using this approach. It makes using required fields problematic, out-of-range validation messages don’t display correctly if the field is on the last line, rules don’t fire correctly, there seem to be random problems with adding discrepancy notes.

But we do want the flexibility to add as many items as we need.

So we’ve been looking at a different approach. We’ve set up both types of log in a repeating event. The AE CRF itself only contains fields to record a single event (and no groups) but as it’s a repeating event, the CRF can be completed as many times as required.

We’ve used a similar approach to ConMeds except that we generally expect there to be more of these in a study so we’ve added as many sets of fields as there are entries on a single page of the paper log. Once again these are defined as separate fields rather than as a repeating group. So we might have NAMEOFDRUG1, NAMEOFDRUG2 etc. Hopefully that won’t be too messy to deal with at analysis. Then, if the subject has more than one page in the log, we enter a new Event and a fresh CRF is displayed. And so on.

To keep the look of the CRF neat, we use a “header” field for each Med and show/hide all the other fields. We cross reference each repeated CRF with a page number on the log.

We’re hoping this will overcome the problems we’ve had but as this is a new approach for us to a common set of CRFs, we thought we’d seek your thoughts.

Michael


Michael Hannah
Trial Database Manager
Tayside Medical Science Centre
Residency Block
Level 3
Ninewells Hospital & Medical School
Dundee
Scotland


The University of Dundee is a registered Scottish Charity, No: SC015096

Comments

  • tdpurnattdpurnat Posts: 126
    Hi Michael,
    I've also set up AEs and concomitant medications this way for the very same reasons. One "event" is one AE; For ConMeds and Previous conditions, I use sets of 8 in one event (same idea as yours), and if there are more, they are repeated. Most of our patients have fewer than 8 con meds/previous conditions.
    Two drawbacks - it's harder for the user to use the web UI get an overview of all AEs (or con meds/previous conditions if there are more than 8). It forced me to prioritize creation of basic patient-based reports of these three categories, and clinics file printouts of these in the subject files.
    Second, our clinics requested to get the queries printed ahead of time, to work off of a paper list as they resolve them. The DN download/print do not identify the event occurrence/start date for queries that are in repeatable events --- this is only available in the web UI directly. So query resolution/identification of what AE the query relates to becomes challenging for clinical staff, unless you train them to use OC for query resolution directly.
    And a minor drawback - the data exports require some variable renaming and reshuffling, to handle the variable names you hard code with numeric suffixes (for con meds/previous conditions for example) together with repeats of the event occurrences.
    Tina.
    ----------
    Skype: tdpurnat | Office: +49 89 38 03 89 67
    Why are my emails so terse? emailcharter.org
    2013/5/28 Michael Hannah
    Hi everyone

    We’ve been using a simple repeating group on both our conmeds and adverse events CRFs (and any other “log” style CRFs), which I think is fairly standard practice.

    However, we’ve noticed that there are some issues with using this approach. It makes using required fields problematic, out-of-range validation messages don’t display correctly if the field is on the last line, rules don’t fire correctly, there seem to be random problems with adding discrepancy notes.

    But we do want the flexibility to add as many items as we need.

    So we’ve been looking at a different approach. We’ve set up both types of log in a repeating event. The AE CRF itself only contains fields to record a single event (and no groups) but as it’s a repeating event, the CRF can be completed as many times as required.

    We’ve used a similar approach to ConMeds except that we generally expect there to be more of these in a study so we’ve added as many sets of fields as there are entries on a single page of the paper log. Once again these are defined as separate fields rather than as a repeating group. So we might have NAMEOFDRUG1, NAMEOFDRUG2 etc. Hopefully that won’t be too messy to deal with at analysis. Then, if the subject has more than one page in the log, we enter a new Event and a fresh CRF is displayed. And so on.

    To keep the look of the CRF neat, we use a “header” field for each Med and show/hide all the other fields. We cross reference each repeated CRF with a page number on the log.

    We’re hoping this will overcome the problems we’ve had but as this is a new approach for us to a common set of CRFs, we thought we’d seek your thoughts.

    Michael


    Michael Hannah
    Trial Database Manager
    Tayside Medical Science Centre
    Residency Block
    Level 3
    Ninewells Hospital & Medical School
    Dundee
    Scotland


    The University of Dundee is a registered Scottish Charity, No: SC015096
  • mvirtosumvirtosu Posts: 275
    Hi All,

    I would like to add two more drawbacks to the repeating group log format:
    1. A large number of rows (40+) makes the CRF load slowly.
    2. You cannot use radio buttons inside of a repeating group because there is no way to delete radio buttons data.

    I also agree with Tina that a large number of repeating events clutters the View Subject Data page and makes it hard to navigate.

    Mihai
    Sent: Tuesday, May 28, 2013 10:55 AM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event

    Hi Michael,

    I've also set up AEs and concomitant medications this way for the very same reasons. One "event" is one AE; For ConMeds and Previous conditions, I use sets of 8 in one event (same idea as yours), and if there are more, they are repeated. Most of our patients have fewer than 8 con meds/previous conditions.

    Two drawbacks - it's harder for the user to use the web UI get an overview of all AEs (or con meds/previous conditions if there are more than 8). It forced me to prioritize creation of basic patient-based reports of these three categories, and clinics file printouts of these in the subject files.

    Second, our clinics requested to get the queries printed ahead of time, to work off of a paper list as they resolve them. The DN download/print do not identify the event occurrence/start date for queries that are in repeatable events --- this is only available in the web UI directly. So query resolution/identification of what AE the query relates to becomes challenging for clinical staff, unless you train them to use OC for query resolution directly.

    And a minor drawback - the data exports require some variable renaming and reshuffling, to handle the variable names you hard code with numeric suffixes (for con meds/previous conditions for example) together with repeats of the event occurrences.

    Tina.


    ----------
    Skype: tdpurnat | Office: +49 89 38 03 89 67

    Why are my emails so terse? emailcharter.org

    2013/5/28 Michael Hannah
    Hi everyone

    We’ve been using a simple repeating group on both our conmeds and adverse events CRFs (and any other “log” style CRFs), which I think is fairly standard practice.

    However, we’ve noticed that there are some issues with using this approach. It makes using required fields problematic, out-of-range validation messages don’t display correctly if the field is on the last line, rules don’t fire correctly, there seem to be random problems with adding discrepancy notes.

    But we do want the flexibility to add as many items as we need.

    So we’ve been looking at a different approach. We’ve set up both types of log in a repeating event. The AE CRF itself only contains fields to record a single event (and no groups) but as it’s a repeating event, the CRF can be completed as many times as required.

    We’ve used a similar approach to ConMeds except that we generally expect there to be more of these in a study so we’ve added as many sets of fields as there are entries on a single page of the paper log. Once again these are defined as separate fields rather than as a repeating group. So we might have NAMEOFDRUG1, NAMEOFDRUG2 etc. Hopefully that won’t be too messy to deal with at analysis. Then, if the subject has more than one page in the log, we enter a new Event and a fresh CRF is displayed. And so on.

    To keep the look of the CRF neat, we use a “header” field for each Med and show/hide all the other fields. We cross reference each repeated CRF with a page number on the log.

    We’re hoping this will overcome the problems we’ve had but as this is a new approach for us to a common set of CRFs, we thought we’d seek your thoughts.

    Michael


    Michael Hannah
    Trial Database Manager
    Tayside Medical Science Centre
    Residency Block
    Level 3
    Ninewells Hospital & Medical School
    Dundee
    Scotland


    The University of Dundee is a registered Scottish Charity, No: SC015096
  • LizRLizR Posts: 60
    Hi,
    We find that most of the issues we have with the repeating group errors are only triggered when people enter data on the last line. As ridiculous as it may sound, we train people not to do that and try to set up CRFs with much more room on it than we think they'll need. We do have high counts in medical history and concomitant medications and opted to leave them as repeating groups and rely on training to get around the bug. It's working more than 95% of the time. I figure we lose less time to correcting errors created this way than we do in validation of log crfs where we have a lot of data. I enjoy querying on thirty different log pages even less than sites enjoy entering data on thirty different log pages.
    On the AEs, though, even though we have a ton of them, we find it useful to do one to a page, anyway. It's easier to track which ones have been SDV'd and are really closed, taken one at a time.
    NameofDrug1, Nameofdrug2 /is/ messy to deal with in analysis and it does add time to programming. If you've only got 8 of them, it's not unholy terrible. Say you have eight rows with eight columns, that's sixty four variables instead of eight. So, the programmer has to keep those straight and you lose elegance and flexibility in programming, which means losing time in program execution. 8x8? Tolerable. 40x8? Better take up wearing pencil-proof jackets.
    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
    Sent: Tuesday, May 28, 2013 9:54 AM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event
    Hi Michael,
    I've also set up AEs and concomitant medications this way for the very same reasons. One "event" is one AE; For ConMeds and Previous conditions, I use sets of 8 in one event (same idea as yours), and if there are more, they are repeated. Most of our patients have fewer than 8 con meds/previous conditions.
    Two drawbacks - it's harder for the user to use the web UI get an overview of all AEs (or con meds/previous conditions if there are more than 8). It forced me to prioritize creation of basic patient-based reports of these three categories, and clinics file printouts of these in the subject files.
    Second, our clinics requested to get the queries printed ahead of time, to work off of a paper list as they resolve them. The DN download/print do not identify the event occurrence/start date for queries that are in repeatable events --- this is only available in the web UI directly. So query resolution/identification of what AE the query relates to becomes challenging for clinical staff, unless you train them to use OC for query resolution directly.
    And a minor drawback - the data exports require some variable renaming and reshuffling, to handle the variable names you hard code with numeric suffixes (for con meds/previous conditions for example) together with repeats of the event occurrences.
    Tina.
    ----------
    Skype: tdpurnat | Office: +49 89 38 03 89 67
    Why are my emails so terse? emailcharter.org
    2013/5/28 Michael Hannah
    Hi everyone

    We’ve been using a simple repeating group on both our conmeds and adverse events CRFs (and any other “log” style CRFs), which I think is fairly standard practice.

    However, we’ve noticed that there are some issues with using this approach. It makes using required fields problematic, out-of-range validation messages don’t display correctly if the field is on the last line, rules don’t fire correctly, there seem to be random problems with adding discrepancy notes.

    But we do want the flexibility to add as many items as we need.

    So we’ve been looking at a different approach. We’ve set up both types of log in a repeating event. The AE CRF itself only contains fields to record a single event (and no groups) but as it’s a repeating event, the CRF can be completed as many times as required.

    We’ve used a similar approach to ConMeds except that we generally expect there to be more of these in a study so we’ve added as many sets of fields as there are entries on a single page of the paper log. Once again these are defined as separate fields rather than as a repeating group. So we might have NAMEOFDRUG1, NAMEOFDRUG2 etc. Hopefully that won’t be too messy to deal with at analysis. Then, if the subject has more than one page in the log, we enter a new Event and a fresh CRF is displayed. And so on.

    To keep the look of the CRF neat, we use a “header” field for each Med and show/hide all the other fields. We cross reference each repeated CRF with a page number on the log.

    We’re hoping this will overcome the problems we’ve had but as this is a new approach for us to a common set of CRFs, we thought we’d seek your thoughts.

    Michael


    Michael Hannah
    Trial Database Manager
    Tayside Medical Science Centre
    Residency Block
    Level 3
    Ninewells Hospital & Medical School
    Dundee
    Scotland


    The University of Dundee is a registered Scottish Charity, No: SC015096
  • mvirtosumvirtosu Posts: 275
    Liz,

    Are the problems with the last line documented somewhere in a ticket?

    Thanks,

    Mihai
    Sent: Tuesday, May 28, 2013 12:28 PM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event

    Hi,
    We find that most of the issues we have with the repeating group errors are only triggered when people enter data on the last line. As ridiculous as it may sound, we train people not to do that and try to set up CRFs with much more room on it than we think they'll need. We do have high counts in medical history and concomitant medications and opted to leave them as repeating groups and rely on training to get around the bug. It's working more than 95% of the time. I figure we lose less time to correcting errors created this way than we do in validation of log crfs where we have a lot of data. I enjoy querying on thirty different log pages even less than sites enjoy entering data on thirty different log pages.
    On the AEs, though, even though we have a ton of them, we find it useful to do one to a page, anyway. It's easier to track which ones have been SDV'd and are really closed, taken one at a time.
    NameofDrug1, Nameofdrug2 /is/ messy to deal with in analysis and it does add time to programming. If you've only got 8 of them, it's not unholy terrible. Say you have eight rows with eight columns, that's sixty four variables instead of eight. So, the programmer has to keep those straight and you lose elegance and flexibility in programming, which means losing time in program execution. 8x8? Tolerable. 40x8? Better take up wearing pencil-proof jackets.

    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
    Sent: Tuesday, May 28, 2013 9:54 AM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event
    Hi Michael,

    I've also set up AEs and concomitant medications this way for the very same reasons. One "event" is one AE; For ConMeds and Previous conditions, I use sets of 8 in one event (same idea as yours), and if there are more, they are repeated. Most of our patients have fewer than 8 con meds/previous conditions.

    Two drawbacks - it's harder for the user to use the web UI get an overview of all AEs (or con meds/previous conditions if there are more than 8). It forced me to prioritize creation of basic patient-based reports of these three categories, and clinics file printouts of these in the subject files.

    Second, our clinics requested to get the queries printed ahead of time, to work off of a paper list as they resolve them. The DN download/print do not identify the event occurrence/start date for queries that are in repeatable events --- this is only available in the web UI directly. So query resolution/identification of what AE the query relates to becomes challenging for clinical staff, unless you train them to use OC for query resolution directly.

    And a minor drawback - the data exports require some variable renaming and reshuffling, to handle the variable names you hard code with numeric suffixes (for con meds/previous conditions for example) together with repeats of the event occurrences.

    Tina.


    ----------
    Skype: tdpurnat | Office: +49 89 38 03 89 67

    Why are my emails so terse? emailcharter.org

    2013/5/28 Michael Hannah
    Hi everyone

    We’ve been using a simple repeating group on both our conmeds and adverse events CRFs (and any other “log” style CRFs), which I think is fairly standard practice.

    However, we’ve noticed that there are some issues with using this approach. It makes using required fields problematic, out-of-range validation messages don’t display correctly if the field is on the last line, rules don’t fire correctly, there seem to be random problems with adding discrepancy notes.

    But we do want the flexibility to add as many items as we need.

    So we’ve been looking at a different approach. We’ve set up both types of log in a repeating event. The AE CRF itself only contains fields to record a single event (and no groups) but as it’s a repeating event, the CRF can be completed as many times as required.

    We’ve used a similar approach to ConMeds except that we generally expect there to be more of these in a study so we’ve added as many sets of fields as there are entries on a single page of the paper log. Once again these are defined as separate fields rather than as a repeating group. So we might have NAMEOFDRUG1, NAMEOFDRUG2 etc. Hopefully that won’t be too messy to deal with at analysis. Then, if the subject has more than one page in the log, we enter a new Event and a fresh CRF is displayed. And so on.

    To keep the look of the CRF neat, we use a “header” field for each Med and show/hide all the other fields. We cross reference each repeated CRF with a page number on the log.

    We’re hoping this will overcome the problems we’ve had but as this is a new approach for us to a common set of CRFs, we thought we’d seek your thoughts.

    Michael


    Michael Hannah
    Trial Database Manager
    Tayside Medical Science Centre
    Residency Block
    Level 3
    Ninewells Hospital & Medical School
    Dundee
    Scotland


    The University of Dundee is a registered Scottish Charity, No: SC015096
  • ccollinsccollins Posts: 378 admin
    > Are the problems with the last line documented somewhere in a ticket?
    Yes, they are described in the 3.1.3 known issues:
    Data Entry in Repeating Groups - During the administrative editing phase; entering Discrepancy Note(s) on the last added row of a Repeating Group will cause the Discrepancy Note(s) to be saved to the first row. Also, saving data on the last row of the displayed Repeating Group that is a part of Rules target triggers an alert that prevents user from going to the next section. The following issues fall under this category: 12108, 12091, 12174.
    Mihai, as I believe you do not use the discrepancy notes feature I'm not exactly sure how you'd be impacted by this.
    In general, the data entry servlet, which generates the layout of the CRF and handles the submitted data, has become a bit long in the tooth (okay very long actually) and we are proceeding with an overhaul of this entire part of the codebase. The next generation will be based around the code that you'll first see as part of the new PrintCRF module in 3.1.4 (http://blog.openclinica.com/2013/04/26/new-openclinica-developer-release-revamped-print-module/). Liz' advice (adding extra lines by default, train users as best you can) is currently the best method to avoid trouble in the meantime.
    Cal
    On Tue, May 28, 2013 at 2:36 PM, Mihai Virtosu wrote:
    Liz,

    Are the problems with the last line documented somewhere in a ticket?

    Thanks,

    Mihai
    Sent: Tuesday, May 28, 2013 12:28 PM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event

    Hi,
    We find that most of the issues we have with the repeating group errors are only triggered when people enter data on the last line. As ridiculous as it may sound, we train people not to do that and try to set up CRFs with much more room on it than we think they'll need. We do have high counts in medical history and concomitant medications and opted to leave them as repeating groups and rely on training to get around the bug. It's working more than 95% of the time. I figure we lose less time to correcting errors created this way than we do in validation of log crfs where we have a lot of data. I enjoy querying on thirty different log pages even less than sites enjoy entering data on thirty different log pages.
    On the AEs, though, even though we have a ton of them, we find it useful to do one to a page, anyway. It's easier to track which ones have been SDV'd and are really closed, taken one at a time.
    NameofDrug1, Nameofdrug2 /is/ messy to deal with in analysis and it does add time to programming. If you've only got 8 of them, it's not unholy terrible. Say you have eight rows with eight columns, that's sixty four variables instead of eight. So, the programmer has to keep those straight and you lose elegance and flexibility in programming, which means losing time in program execution. 8x8? Tolerable. 40x8? Better take up wearing pencil-proof jackets.

    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
    Sent: Tuesday, May 28, 2013 9:54 AM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event
    Hi Michael,

    I've also set up AEs and concomitant medications this way for the very same reasons. One "event" is one AE; For ConMeds and Previous conditions, I use sets of 8 in one event (same idea as yours), and if there are more, they are repeated. Most of our patients have fewer than 8 con meds/previous conditions.

    Two drawbacks - it's harder for the user to use the web UI get an overview of all AEs (or con meds/previous conditions if there are more than 8). It forced me to prioritize creation of basic patient-based reports of these three categories, and clinics file printouts of these in the subject files.

    Second, our clinics requested to get the queries printed ahead of time, to work off of a paper list as they resolve them. The DN download/print do not identify the event occurrence/start date for queries that are in repeatable events --- this is only available in the web UI directly. So query resolution/identification of what AE the query relates to becomes challenging for clinical staff, unless you train them to use OC for query resolution directly.

    And a minor drawback - the data exports require some variable renaming and reshuffling, to handle the variable names you hard code with numeric suffixes (for con meds/previous conditions for example) together with repeats of the event occurrences.

    Tina.


    ----------
    Skype: tdpurnat | Office: +49 89 38 03 89 67

    Why are my emails so terse? emailcharter.org

    2013/5/28 Michael Hannah
    Hi everyone

    We’ve been using a simple repeating group on both our conmeds and adverse events CRFs (and any other “log” style CRFs), which I think is fairly standard practice.

    However, we’ve noticed that there are some issues with using this approach. It makes using required fields problematic, out-of-range validation messages don’t display correctly if the field is on the last line, rules don’t fire correctly, there seem to be random problems with adding discrepancy notes.

    But we do want the flexibility to add as many items as we need.

    So we’ve been looking at a different approach. We’ve set up both types of log in a repeating event. The AE CRF itself only contains fields to record a single event (and no groups) but as it’s a repeating event, the CRF can be completed as many times as required.

    We’ve used a similar approach to ConMeds except that we generally expect there to be more of these in a study so we’ve added as many sets of fields as there are entries on a single page of the paper log. Once again these are defined as separate fields rather than as a repeating group. So we might have NAMEOFDRUG1, NAMEOFDRUG2 etc. Hopefully that won’t be too messy to deal with at analysis. Then, if the subject has more than one page in the log, we enter a new Event and a fresh CRF is displayed. And so on.

    To keep the look of the CRF neat, we use a “header” field for each Med and show/hide all the other fields. We cross reference each repeated CRF with a page number on the log.

    We’re hoping this will overcome the problems we’ve had but as this is a new approach for us to a common set of CRFs, we thought we’d seek your thoughts.

    Michael


    Michael Hannah
    Trial Database Manager
    Tayside Medical Science Centre
    Residency Block
    Level 3
    Ninewells Hospital & Medical School
    Dundee
    Scotland


    The University of Dundee is a registered Scottish Charity, No: SC015096
  • mvirtosumvirtosu Posts: 275
    Cal,

    I was concerned more about these: “out-of-range validation messages don’t display correctly if the field is on the last line, rules don’t fire correctly”

    We still user validation and rules, as far as I know.

    Thanks for your response,

    Mihai
    Sent: Tuesday, May 28, 2013 3:09 PM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event

    > Are the problems with the last line documented somewhere in a ticket?
    Yes, they are described in the 3.1.3 known issues:
    · Data Entry in Repeating Groups - During the administrative editing phase; entering Discrepancy Note(s) on the last added row of a Repeating Group will cause the Discrepancy Note(s) to be saved to the first row. Also, saving data on the last row of the displayed Repeating Group that is a part of Rules target triggers an alert that prevents user from going to the next section. The following issues fall under this category: 12108, 12091, 12174.

    Mihai, as I believe you do not use the discrepancy notes feature I'm not exactly sure how you'd be impacted by this.

    In general, the data entry servlet, which generates the layout of the CRF and handles the submitted data, has become a bit long in the tooth (okay very long actually) and we are proceeding with an overhaul of this entire part of the codebase. The next generation will be based around the code that you'll first see as part of the new PrintCRF module in 3.1.4 (http://blog.openclinica.com/2013/04/26/new-openclinica-developer-release-revamped-print-module/). Liz' advice (adding extra lines by default, train users as best you can) is currently the best method to avoid trouble in the meantime.

    Cal





    On Tue, May 28, 2013 at 2:36 PM, Mihai Virtosu wrote:
    Liz,

    Are the problems with the last line documented somewhere in a ticket?

    Thanks,

    Mihai
    Sent: Tuesday, May 28, 2013 12:28 PM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event

    Hi,
    We find that most of the issues we have with the repeating group errors are only triggered when people enter data on the last line. As ridiculous as it may sound, we train people not to do that and try to set up CRFs with much more room on it than we think they'll need. We do have high counts in medical history and concomitant medications and opted to leave them as repeating groups and rely on training to get around the bug. It's working more than 95% of the time. I figure we lose less time to correcting errors created this way than we do in validation of log crfs where we have a lot of data. I enjoy querying on thirty different log pages even less than sites enjoy entering data on thirty different log pages.
    On the AEs, though, even though we have a ton of them, we find it useful to do one to a page, anyway. It's easier to track which ones have been SDV'd and are really closed, taken one at a time.
    NameofDrug1, Nameofdrug2 /is/ messy to deal with in analysis and it does add time to programming. If you've only got 8 of them, it's not unholy terrible. Say you have eight rows with eight columns, that's sixty four variables instead of eight. So, the programmer has to keep those straight and you lose elegance and flexibility in programming, which means losing time in program execution. 8x8? Tolerable. 40x8? Better take up wearing pencil-proof jackets.

    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
    Sent: Tuesday, May 28, 2013 9:54 AM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event
    Hi Michael,

    I've also set up AEs and concomitant medications this way for the very same reasons. One "event" is one AE; For ConMeds and Previous conditions, I use sets of 8 in one event (same idea as yours), and if there are more, they are repeated. Most of our patients have fewer than 8 con meds/previous conditions.

    Two drawbacks - it's harder for the user to use the web UI get an overview of all AEs (or con meds/previous conditions if there are more than 8). It forced me to prioritize creation of basic patient-based reports of these three categories, and clinics file printouts of these in the subject files.

    Second, our clinics requested to get the queries printed ahead of time, to work off of a paper list as they resolve them. The DN download/print do not identify the event occurrence/start date for queries that are in repeatable events --- this is only available in the web UI directly. So query resolution/identification of what AE the query relates to becomes challenging for clinical staff, unless you train them to use OC for query resolution directly.

    And a minor drawback - the data exports require some variable renaming and reshuffling, to handle the variable names you hard code with numeric suffixes (for con meds/previous conditions for example) together with repeats of the event occurrences.

    Tina.


    ----------
    Skype: tdpurnat | Office: +49 89 38 03 89 67

    Why are my emails so terse? emailcharter.org

    2013/5/28 Michael Hannah
    Hi everyone

    We’ve been using a simple repeating group on both our conmeds and adverse events CRFs (and any other “log” style CRFs), which I think is fairly standard practice.

    However, we’ve noticed that there are some issues with using this approach. It makes using required fields problematic, out-of-range validation messages don’t display correctly if the field is on the last line, rules don’t fire correctly, there seem to be random problems with adding discrepancy notes.

    But we do want the flexibility to add as many items as we need.

    So we’ve been looking at a different approach. We’ve set up both types of log in a repeating event. The AE CRF itself only contains fields to record a single event (and no groups) but as it’s a repeating event, the CRF can be completed as many times as required.

    We’ve used a similar approach to ConMeds except that we generally expect there to be more of these in a study so we’ve added as many sets of fields as there are entries on a single page of the paper log. Once again these are defined as separate fields rather than as a repeating group. So we might have NAMEOFDRUG1, NAMEOFDRUG2 etc. Hopefully that won’t be too messy to deal with at analysis. Then, if the subject has more than one page in the log, we enter a new Event and a fresh CRF is displayed. And so on.

    To keep the look of the CRF neat, we use a “header” field for each Med and show/hide all the other fields. We cross reference each repeated CRF with a page number on the log.

    We’re hoping this will overcome the problems we’ve had but as this is a new approach for us to a common set of CRFs, we thought we’d seek your thoughts.

    Michael


    Michael Hannah
    Trial Database Manager
    Tayside Medical Science Centre
    Residency Block
    Level 3
    Ninewells Hospital & Medical School
    Dundee
    Scotland


    The University of Dundee is a registered Scottish Charity, No: SC015096
  • ccollinsccollins Posts: 378 admin
    Hi Mihai, I'm not exactly sure but will see if someone else here can answer the question.
    Thanks,
    Cal
    On Tue, May 28, 2013 at 5:22 PM, Mihai Virtosu wrote:
    Cal,

    I was concerned more about these: “out-of-range validation messages don’t display correctly if the field is on the last line, rules don’t fire correctly”

    We still user validation and rules, as far as I know.

    Thanks for your response,

    Mihai
    Sent: Tuesday, May 28, 2013 3:09 PM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event

    > Are the problems with the last line documented somewhere in a ticket?
    Yes, they are described in the 3.1.3 known issues:
    · Data Entry in Repeating Groups - During the administrative editing phase; entering Discrepancy Note(s) on the last added row of a Repeating Group will cause the Discrepancy Note(s) to be saved to the first row. Also, saving data on the last row of the displayed Repeating Group that is a part of Rules target triggers an alert that prevents user from going to the next section. The following issues fall under this category: 12108, 12091, 12174.

    Mihai, as I believe you do not use the discrepancy notes feature I'm not exactly sure how you'd be impacted by this.

    In general, the data entry servlet, which generates the layout of the CRF and handles the submitted data, has become a bit long in the tooth (okay very long actually) and we are proceeding with an overhaul of this entire part of the codebase. The next generation will be based around the code that you'll first see as part of the new PrintCRF module in 3.1.4 (http://blog.openclinica.com/2013/04/26/new-openclinica-developer-release-revamped-print-module/). Liz' advice (adding extra lines by default, train users as best you can) is currently the best method to avoid trouble in the meantime.

    Cal





    On Tue, May 28, 2013 at 2:36 PM, Mihai Virtosu wrote:
    Liz,

    Are the problems with the last line documented somewhere in a ticket?

    Thanks,

    Mihai
    Sent: Tuesday, May 28, 2013 12:28 PM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event

    Hi,
    We find that most of the issues we have with the repeating group errors are only triggered when people enter data on the last line. As ridiculous as it may sound, we train people not to do that and try to set up CRFs with much more room on it than we think they'll need. We do have high counts in medical history and concomitant medications and opted to leave them as repeating groups and rely on training to get around the bug. It's working more than 95% of the time. I figure we lose less time to correcting errors created this way than we do in validation of log crfs where we have a lot of data. I enjoy querying on thirty different log pages even less than sites enjoy entering data on thirty different log pages.
    On the AEs, though, even though we have a ton of them, we find it useful to do one to a page, anyway. It's easier to track which ones have been SDV'd and are really closed, taken one at a time.
    NameofDrug1, Nameofdrug2 /is/ messy to deal with in analysis and it does add time to programming. If you've only got 8 of them, it's not unholy terrible. Say you have eight rows with eight columns, that's sixty four variables instead of eight. So, the programmer has to keep those straight and you lose elegance and flexibility in programming, which means losing time in program execution. 8x8? Tolerable. 40x8? Better take up wearing pencil-proof jackets.

    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
    Sent: Tuesday, May 28, 2013 9:54 AM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event
    Hi Michael,

    I've also set up AEs and concomitant medications this way for the very same reasons. One "event" is one AE; For ConMeds and Previous conditions, I use sets of 8 in one event (same idea as yours), and if there are more, they are repeated. Most of our patients have fewer than 8 con meds/previous conditions.

    Two drawbacks - it's harder for the user to use the web UI get an overview of all AEs (or con meds/previous conditions if there are more than 8). It forced me to prioritize creation of basic patient-based reports of these three categories, and clinics file printouts of these in the subject files.

    Second, our clinics requested to get the queries printed ahead of time, to work off of a paper list as they resolve them. The DN download/print do not identify the event occurrence/start date for queries that are in repeatable events --- this is only available in the web UI directly. So query resolution/identification of what AE the query relates to becomes challenging for clinical staff, unless you train them to use OC for query resolution directly.

    And a minor drawback - the data exports require some variable renaming and reshuffling, to handle the variable names you hard code with numeric suffixes (for con meds/previous conditions for example) together with repeats of the event occurrences.

    Tina.


    ----------
    Skype: tdpurnat | Office: +49 89 38 03 89 67

    Why are my emails so terse? emailcharter.org

    2013/5/28 Michael Hannah
    Hi everyone

    We’ve been using a simple repeating group on both our conmeds and adverse events CRFs (and any other “log” style CRFs), which I think is fairly standard practice.

    However, we’ve noticed that there are some issues with using this approach. It makes using required fields problematic, out-of-range validation messages don’t display correctly if the field is on the last line, rules don’t fire correctly, there seem to be random problems with adding discrepancy notes.

    But we do want the flexibility to add as many items as we need.

    So we’ve been looking at a different approach. We’ve set up both types of log in a repeating event. The AE CRF itself only contains fields to record a single event (and no groups) but as it’s a repeating event, the CRF can be completed as many times as required.

    We’ve used a similar approach to ConMeds except that we generally expect there to be more of these in a study so we’ve added as many sets of fields as there are entries on a single page of the paper log. Once again these are defined as separate fields rather than as a repeating group. So we might have NAMEOFDRUG1, NAMEOFDRUG2 etc. Hopefully that won’t be too messy to deal with at analysis. Then, if the subject has more than one page in the log, we enter a new Event and a fresh CRF is displayed. And so on.

    To keep the look of the CRF neat, we use a “header” field for each Med and show/hide all the other fields. We cross reference each repeated CRF with a page number on the log.

    We’re hoping this will overcome the problems we’ve had but as this is a new approach for us to a common set of CRFs, we thought we’d seek your thoughts.

    Michael


    Michael Hannah
    Trial Database Manager
    Tayside Medical Science Centre
    Residency Block
    Level 3
    Ninewells Hospital & Medical School
    Dundee
    Scotland


    The University of Dundee is a registered Scottish Charity, No: SC015096
  • mhannahmhannah Posts: 11
    Just wanted to say thanks for all the replies to this thread.

    There never seems to be the perfect solution – we’re always working with compromises but it helps to know how folk deal with this.


    Best wishes to all


    Michael
    Sent: 28 May 2013 19:28
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event

    Hi,
    We find that most of the issues we have with the repeating group errors are only triggered when people enter data on the last line. As ridiculous as it may sound, we train people not to do that and try to set up CRFs with much more room on it than we think they'll need. We do have high counts in medical history and concomitant medications and opted to leave them as repeating groups and rely on training to get around the bug. It's working more than 95% of the time. I figure we lose less time to correcting errors created this way than we do in validation of log crfs where we have a lot of data. I enjoy querying on thirty different log pages even less than sites enjoy entering data on thirty different log pages.
    On the AEs, though, even though we have a ton of them, we find it useful to do one to a page, anyway. It's easier to track which ones have been SDV'd and are really closed, taken one at a time.
    NameofDrug1, Nameofdrug2 /is/ messy to deal with in analysis and it does add time to programming. If you've only got 8 of them, it's not unholy terrible. Say you have eight rows with eight columns, that's sixty four variables instead of eight. So, the programmer has to keep those straight and you lose elegance and flexibility in programming, which means losing time in program execution. 8x8? Tolerable. 40x8? Better take up wearing pencil-proof jackets.

    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
    Sent: Tuesday, May 28, 2013 9:54 AM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event
    Hi Michael,

    I've also set up AEs and concomitant medications this way for the very same reasons. One "event" is one AE; For ConMeds and Previous conditions, I use sets of 8 in one event (same idea as yours), and if there are more, they are repeated. Most of our patients have fewer than 8 con meds/previous conditions.

    Two drawbacks - it's harder for the user to use the web UI get an overview of all AEs (or con meds/previous conditions if there are more than 8). It forced me to prioritize creation of basic patient-based reports of these three categories, and clinics file printouts of these in the subject files.

    Second, our clinics requested to get the queries printed ahead of time, to work off of a paper list as they resolve them. The DN download/print do not identify the event occurrence/start date for queries that are in repeatable events --- this is only available in the web UI directly. So query resolution/identification of what AE the query relates to becomes challenging for clinical staff, unless you train them to use OC for query resolution directly.

    And a minor drawback - the data exports require some variable renaming and reshuffling, to handle the variable names you hard code with numeric suffixes (for con meds/previous conditions for example) together with repeats of the event occurrences.

    Tina.


    ----------
    Skype: tdpurnat | Office: +49 89 38 03 89 67

    Why are my emails so terse? emailcharter.org

    2013/5/28 Michael Hannah
    Hi everyone

    We’ve been using a simple repeating group on both our conmeds and adverse events CRFs (and any other “log” style CRFs), which I think is fairly standard practice.

    However, we’ve noticed that there are some issues with using this approach. It makes using required fields problematic, out-of-range validation messages don’t display correctly if the field is on the last line, rules don’t fire correctly, there seem to be random problems with adding discrepancy notes.

    But we do want the flexibility to add as many items as we need.

    So we’ve been looking at a different approach. We’ve set up both types of log in a repeating event. The AE CRF itself only contains fields to record a single event (and no groups) but as it’s a repeating event, the CRF can be completed as many times as required.

    We’ve used a similar approach to ConMeds except that we generally expect there to be more of these in a study so we’ve added as many sets of fields as there are entries on a single page of the paper log. Once again these are defined as separate fields rather than as a repeating group. So we might have NAMEOFDRUG1, NAMEOFDRUG2 etc. Hopefully that won’t be too messy to deal with at analysis. Then, if the subject has more than one page in the log, we enter a new Event and a fresh CRF is displayed. And so on.

    To keep the look of the CRF neat, we use a “header” field for each Med and show/hide all the other fields. We cross reference each repeated CRF with a page number on the log.

    We’re hoping this will overcome the problems we’ve had but as this is a new approach for us to a common set of CRFs, we thought we’d seek your thoughts.

    Michael


    Michael Hannah
    Trial Database Manager
    Tayside Medical Science Centre
    Residency Block
    Level 3
    Ninewells Hospital & Medical School
    Dundee
    Scotland


    The University of Dundee is a registered Scottish Charity, No: SC015096
  • willilx9willilx9 Posts: 40
    We have decided to only run Edit Checks or Rules on fields in Grids in Batch. This seems to work better for us instead of not entering the last line. Cheers.
    Sent: Monday, June 03, 2013 3:56 AM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event

    Just wanted to say thanks for all the replies to this thread.

    There never seems to be the perfect solution – we’re always working with compromises but it helps to know how folk deal with this.


    Best wishes to all


    Michael
    Sent: 28 May 2013 19:28
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event

    Hi,
    We find that most of the issues we have with the repeating group errors are only triggered when people enter data on the last line. As ridiculous as it may sound, we train people not to do that and try to set up CRFs with much more room on it than we think they'll need. We do have high counts in medical history and concomitant medications and opted to leave them as repeating groups and rely on training to get around the bug. It's working more than 95% of the time. I figure we lose less time to correcting errors created this way than we do in validation of log crfs where we have a lot of data. I enjoy querying on thirty different log pages even less than sites enjoy entering data on thirty different log pages.
    On the AEs, though, even though we have a ton of them, we find it useful to do one to a page, anyway. It's easier to track which ones have been SDV'd and are really closed, taken one at a time.
    NameofDrug1, Nameofdrug2 /is/ messy to deal with in analysis and it does add time to programming. If you've only got 8 of them, it's not unholy terrible. Say you have eight rows with eight columns, that's sixty four variables instead of eight. So, the programmer has to keep those straight and you lose elegance and flexibility in programming, which means losing time in program execution. 8x8? Tolerable. 40x8? Better take up wearing pencil-proof jackets.

    Liz Robertson
    Director of Data Management and IT
    TRACON Pharmaceuticals, Inc.
    [email protected]
    office: 858.550.0780 ext. 237
    cell: 760.481.5527
    Sent: Tuesday, May 28, 2013 9:54 AM
    To: [email protected]
    Subject: Re: [Developers] repeaqting group vs repeating event
    Hi Michael,

    I've also set up AEs and concomitant medications this way for the very same reasons. One "event" is one AE; For ConMeds and Previous conditions, I use sets of 8 in one event (same idea as yours), and if there are more, they are repeated. Most of our patients have fewer than 8 con meds/previous conditions.

    Two drawbacks - it's harder for the user to use the web UI get an overview of all AEs (or con meds/previous conditions if there are more than 8). It forced me to prioritize creation of basic patient-based reports of these three categories, and clinics file printouts of these in the subject files.

    Second, our clinics requested to get the queries printed ahead of time, to work off of a paper list as they resolve them. The DN download/print do not identify the event occurrence/start date for queries that are in repeatable events --- this is only available in the web UI directly. So query resolution/identification of what AE the query relates to becomes challenging for clinical staff, unless you train them to use OC for query resolution directly.

    And a minor drawback - the data exports require some variable renaming and reshuffling, to handle the variable names you hard code with numeric suffixes (for con meds/previous conditions for example) together with repeats of the event occurrences.

    Tina.


    ----------
    Skype: tdpurnat | Office: +49 89 38 03 89 67

    Why are my emails so terse? emailcharter.org

    2013/5/28 Michael Hannah
    Hi everyone

    We’ve been using a simple repeating group on both our conmeds and adverse events CRFs (and any other “log” style CRFs), which I think is fairly standard practice.

    However, we’ve noticed that there are some issues with using this approach. It makes using required fields problematic, out-of-range validation messages don’t display correctly if the field is on the last line, rules don’t fire correctly, there seem to be random problems with adding discrepancy notes.

    But we do want the flexibility to add as many items as we need.

    So we’ve been looking at a different approach. We’ve set up both types of log in a repeating event. The AE CRF itself only contains fields to record a single event (and no groups) but as it’s a repeating event, the CRF can be completed as many times as required.

    We’ve used a similar approach to ConMeds except that we generally expect there to be more of these in a study so we’ve added as many sets of fields as there are entries on a single page of the paper log. Once again these are defined as separate fields rather than as a repeating group. So we might have NAMEOFDRUG1, NAMEOFDRUG2 etc. Hopefully that won’t be too messy to deal with at analysis. Then, if the subject has more than one page in the log, we enter a new Event and a fresh CRF is displayed. And so on.

    To keep the look of the CRF neat, we use a “header” field for each Med and show/hide all the other fields. We cross reference each repeated CRF with a page number on the log.

    We’re hoping this will overcome the problems we’ve had but as this is a new approach for us to a common set of CRFs, we thought we’d seek your thoughts.

    Michael


    Michael Hannah
    Trial Database Manager
    Tayside Medical Science Centre
    Residency Block
    Level 3
    Ninewells Hospital & Medical School
    Dundee
    Scotland


    The University of Dundee is a registered Scottish Charity, No: SC015096
This discussion has been closed.