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"
GerbenRienk commented on Why is it not possible to change an integer to a
real in the eCRF design?
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.