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

Why is it not possible to change an integer to a real in the eCRF design?

It does not seem possible to change an integer to a real is a running study without changing the variable name.
We see that this is one of the common made mistakes, in eCRF design.
It is understandable that the most type changes should be avoided, however this is one that I don't see any harm in.
Is there a logical reason why the type change from Integer to Real should be prevented?
This would help explaining it to the designers of studies.
Thx in advance.
Frank

Comments

  • lindsay.stevenslindsay.stevens Posts: 404 ✭✭✭
    via Email
    Say there's saved values 1.3 and 1.6.

    How should the system know whether you want to round up or down? Does the
    data change get assigned to your user in the audit trail, or the CRF owner,
    or the data entry user? What if this rounding causes a discrepancy note
    invalidation, or some other rule to be triggered? What about rules that
    were triggered based on the decimal value that shouldn't be triggered with
    the integer value? What about CRF migrations - do the same get applied? How
    to handle extracts where some data is integer and some is decimal? What if
    you decide to add a choice list to your integers which is invalid for
    decimal?

    Not as simple as it may seem.


    On 8 May 2017 10:43 pm, "FZweerus"
    wrote:

    OpenClinica https://forums.openclinica.com/
    FZweerus started a new discussion: Why is it not possible to change an
    integer to a real in the eCRF design?

    It does not seem possible to change an integer to a real is a running study
    without changing the variable name.
    We see that this is one of the common made mistakes, in eCRF design.
    It is understandable that the most type changes should be avoided, however
    this is one that I don't see any harm in.
    Is there a logical reason why the type change from Integer to Real should
    be prevented?
    This would help explaining it to the designers of studies.
    Thx in advance.
    Frank
  • FZweerusFZweerus Posts: 12
    Thanks lindsay.stevens,

    When you would change an Item from Real to an Integer, I can see several serious issues, like the ones you described.
    However, when changing the definition of an item from an Integer to a Real, I don't see how these could cause serious issues.

    Obviously there is an issue with precision, 100, would become 100.00 for example which has a higher precision, but that is an issue of interpretation that can be taken into account when evaluating the data.
    However I don't see any technical problems that arise from this change, nor do I see any reasons to prevent this?

    Or am I overlooking something?

    Frank
  • kristiakkristiak Posts: 1,338 ✭✭✭
    I fully agree with Lindsay. This is much more complex than it may seem. For an interesting reading about number definitions please check
    http://www-classes.usc.edu/engr/ce/108/text/fbk01.htm
    A number may not always be as simple as it may sound!
  • FZweerusFZweerus Posts: 12
    Kristiak,

    Thanks for your reply. I also agree with Lindsay. However his reply was focusing on changing a real to an integer. There I agree.
    My questions is about the reverse.: Changing an Integer to a Real. This should be much more straight forward in my view.

    Frank
  • GerbenRienkGerbenRienk Posts: 838 ✭✭✭
    Hi Frank,
    I'm afraid I agree with Lindsay and Krister and I think your question isn't the reverse of what Lindsay is stating: it is the same from a regulatory point of view.
    If in CRF-version 1 an investigator measures a real, like 1.6, but can input an integer she must make a decision and probably chooses 2. If in CRF-version 2 this item could be changed into a real then the next time she measures 1.6 she would be able to enter it. So for two identical situations the values in the database would be different. Most people would like to avoid that in their data-collection.
    Kind regards,
    Gerben Rienk
  • lindsay.stevenslindsay.stevens Posts: 404 ✭✭✭
    via Email
    For integer to real, it's the same issues except the first, plus:

    When changing a 1, should the system assume you consider 1.0 an equivalent
    representation, or a false precision to be manually confirmed for every
    value? What should happen when a CRF is uploaded or migrated and the
    integer doesn't fit in the width spec for the real (e.g. 100 into 1(1))?

    All these questions may have clear answers for your research group. However
    it may not be the same for another team. Should the system handle both sets
    of preferences, particularly at the expense of implementing other features
    - remember OC is made by real people with non-infinite resources ;)



    On 9 May 2017 4:48 am, "GerbenRienk"
    wrote:

    OpenClinica https://forums.openclinica.com/
    GerbenRienk commented on Why is it not possible to change an integer to a
    real in the eCRF design?

    Hi Frank,
    I'm afraid I agree with Lindsay and Krister and I think your question isn't
    the reverse of what Lindsay is stating: it is the same from a regulatory
    point of view.
    If in CRF-version 1 an investigator measures a real, like 1.6, but can
    input an integer she must make a decision and probably chooses 2. If in
    CRF-version 2 this item could be changed into a real then the next time she
    measures 1.6 she would be able to enter it. So for two identical situations
    the values in the database would be different. Most people would like to
    avoid that in their data-collection.
    Kind regards,
    Gerben Rienk
  • FZweerusFZweerus Posts: 12
    @lindsay.stevens . Thanks for your second clarification. I had not thought about "...integer doesn't fit in the width spec for the real (e.g. 100 into 1(1)).."
    That is a good point that I had overlooked.
    Thx a lot.
  • FZweerusFZweerus Posts: 12
    @GerbenRienk . Thanks for your clarification. You are making a valid point here.
    Thanx, Frank
Sign In or Register to comment.