• FEATURES
  • PRICING
  • MARKETPLACE
  • CASE STUDIES
  • BLOG
    •

    Changing Custom Forms with Real Data

    Technical Questions
    #1

    Hello,

    I am looking for insight on how best to manage custom form changes and existing data.

    Currently, OpenSpecimen does warn me when I change or delete a question on a custom form, but it does not let me know if I have data stored under that question. This is fine, unless I am storing real data under these questions and not test data. I can delete data unknowingly. The system does not seem to have a concept of testing vs. real data collection.

    How do other institutes manage data integrity and form changes? Are users allowed to manage forms, even after testing? Do users run queries on fields they may delete to see if there is any data in them first? I’m thinking of restricting form access in our production instance to only super users, and having regular users make changes in the testing instance and then I can import the changed form.

    Any suggestions or insights would be helpful. Thanks!

    Sam Walkow
    Research Data Coordinator
    BC Children’s Hospital

    #2

    At Johns Hopkins, we keep form management to Super Admins mostly. We do have a few trusted users that we allow to manage their own, but that is an exception. It leaves more work on our plate, but also prevents potential mistakes like what you describe. It also allows us to reuse forms that might apply across protocols.

    #3

    Form add/edit is not available to all users. It is available only to super admins and any else delegated by the super admins to manage forms. This means that only those users who are trained and understand the implications of form management have access to add/edit forms.

    When such a user is deleting a column, then it means he/she has taken enough precautions. E.g. use query interface to check if there is data in that column. Depending on the reason for delete, you may want to delete a column even if it has data in it.

    A future enhancement would be to “archive” a column. That is the column is not visible for future data entry but would still be available in query interface for older records.

    ~Sri

    #4

    Thanks @bob_lange for the reply. It’s good to know others have tackled this issue. I think this will be our approach as well.

    #5

    @Srikanth_Adiga2 Thanks for the reply. It helps to know how you and/or the developers envision the custom forms to work. We will take this into consideration.

    An archive option, or maybe some sort of form version control would be very helpful.

    Sam