Announcement

Collapse
No announcement yet.

Building entry screens for lean tables

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Building entry screens for lean tables

    The way I have been using ClinPlus 3.0 thus far has mostly involved constructing wide tables, with one data entry screen pointing to one row in the database and capturing a variety of data. The times I have had to make progressions of sequenced screens, and I have seen the entry time increase, the data entry error rate grow, and the review and update become more difficult. Now that I wish to build a CDISC-compliant structure, I see the lean tables used by CDISC would make small, monotonous sequenced screens the norm. I would like to avoid that. How can I set up a single screen that will capture multiple pieces of information, storing them in multiple rows of a single table, and thus avoiding endless successions of sequenced screens?
    Last edited by cfeder; 07-26-2005, 02:19 PM.

  • #2
    The problem is that CDISC was not designed with efficient data entry in mind and ClinPlus can only enter one row per screen. The best way to achieve efficient data management and be CDISC complient is to design your data structures with CDISC naming conventions in mind but don't be too concerned with the CDISC structure. After your database is locked you could transform your data to the CDISC structure.

    This seems to be the prevailing thinking in the industry since most, if not all, data management systems were not designed to capture data directly to CDISC structures.

    Also, when you use a sequenced data structure, are you setting sequence header fields in screen design? These will carry values forward so they don't need to be reentered. You can also add code in the onLoad method to initialize values as you progress through your sequences, such as initializing the body system field for a phys page.

    Comment


    • #3
      Thanks for your help. I thought to minimize the post-processing of the data by implementing CDISC at this level, but I guess it will only do so at a price. I was hoping there was an easier way that had eluded me.

      As for easing the pain on sequenced screens, I use carried-forward fields and some onEnter and onLostFocus methods, but nothing extensive. The main problem is not being able to see the data you're entering in the context of the rest of the page or the other rows being entered. Adding code like this makes the entry easier, but requires additional planning for irregular entry and update conditions, plus more testing time (though not nearly as much time as it would've taken to code from scratch; thanks!). The time cost outweighed the benefits in the past, but if I want lean tables, I'll have to reassess that.

      Comment

      Working...
      X