Please join your peers on either March 26 (8pm GMT) or March 28 (8am GMT) to watch as user extraordinaire and forum legend @"lindsay.stevens" demonstrates OpenClinica Insight.

See preview and register at https://openclinica.com/insight-webinar

Insight makes it easy to ask questions of ALL of your clinical and operational data and visualize answers via interactive reports and dashboards. The idea is simple, but the results are powerful: ask your questions, choose your visualizations, then return often for updated, interactive results that link you to all of the underlying data.

How to design response labels for different response types

Hello,

How to design response labels for “text” and “textarea” response types

When designing CRFs with the CRF Design Template, you must specify a RESPONSE TYPE, RESPONSE LABEL and DATA TYPE for each item.

RESPONSE TYPE is the type of HTML control that appears for the data point. Options are “text”, “textarea”, “checkbox”, “radio”, “single-select”, “multi-select”

RESPONSE LABEL must be alphanumeric, 1 to 80 characters long.
For “text” and “textarea” Response Types, the label “text” may be entered. Response Options Text and Response Values may be left blank.
For all other response types, a distinctive response label must be entered. Response Options Text and Response Values must not be blank for the label in the first row that it appears. Thereafter, Response Options Text and Response Values may be left blank in subsequent items that use the Response Label.

The Response Label field allows you to identify a complex response item (such as a set of radio buttons with “Yes” and “No” options) for reuse within the CRF. This item can serve as a standard control that can be referenced by other items in the CRF.

The first time a Response Label is used, it must have a corresponding set of Response Options Text and Response Values; both comma-delimited lists with the same number of arguments.

Filling in the Response Options Text and Response Values fields for multiple items that use the same label is unnecessary, and can result in upload errors if these values are inconsistent.

Response Labels cannot be reused across CRFs, so they must be fully defined in each CRF spreadsheet.

Mike Sweeney
Account Manager
Akaza Research LLC
One Kendall Square, Bldg. 400
Cambridge, MA 02139
U.S.A.
p. 617..621.8585 x24
f. 617.621.0065
e. [email protected]

www.akazaresearch.com
www.OpenClinica.org

"Open Source Informatics for Public Research."
«1

Comments

  • mcoynemcoyne Posts: 20
    Would CRFs of different versions, but of the same name be considered ‘across CRF’s? In other words, the Response_label will not be able to be reused among same crf name with different versions?

    One could argue that there should not be such restrict use of RESPONSE_LABEL – fully qualified to be used in only one CRF (equivalent to one excel file). If one looks at RESPONSE_LABEL with unique name and unique attributes of OPTION_TEXT, VALUES, and DATA_TYPE, then the RESPONSE_LABEL can be used (re-used) among many different CRFs

    A classic example, an organization can predefine the following label: MY_ORGANIZATION_YES_NO to be ‘1-YES’, ‘2-NO’ and *ALL* CRFs of that organization can use MY_ORGANIZATION_YES_NO response-label throughout, across all CRFs.

    My Coyne
    Sent: Thursday, November 09, 2006 3:00 PM
    To: [email protected]
    Subject: [Users] How to design response labels for different response types

    Hello,

    How to design response labels for “text” and “textarea” response types

    When designing CRFs with the CRF Design Template, you must specify a RESPONSE TYPE, RESPONSE LABEL and DATA TYPE for each item.

    RESPONSE TYPE is the type of HTML control that appears for the data point. Options are “text”, “textarea”, “checkbox”, “radio”, “single-select”, “multi-select”

    RESPONSE LABEL must be alphanumeric, 1 to 80 characters long.
    For “text” and “textarea” Response Types, the label “text” may be entered. Response Options Text and Response Values may be left blank.
    For all other response types, a distinctive response label must be entered. Response Options Text and Response Values must not be blank for the label in the first row that it appears. Thereafter, Response Options Text and Response Values may be left blank in subsequent items that use the Response Label.

    The Response Label field allows you to identify a complex response item (such as a set of radio buttons with “Yes” and “No” options) for reuse within the CRF. This item can serve as a standard control that can be referenced by other items in the CRF.

    The first time a Response Label is used, it must have a corresponding set of Response Options Text and Response Values; both comma-delimited lists with the same number of arguments.

    Filling in the Response Options Text and Response Values fields for multiple items that use the same label is unnecessary, and can result in upload errors if these values are inconsistent.

    Response Labels cannot be reused across CRFs, so they must be fully defined in each CRF spreadsheet.

    Mike Sweeney
    Account Manager
    Akaza Research LLC
    One Kendall Square, Bldg. 400
    Cambridge, MA 02139
    U.S.A.
    p. 617..621.8585 x24
    f. 617.621.0065
    e. [email protected]

    www.akazaresearch.com
    www.OpenClinica.org

    "Open Source Informatics for Public Research."
  • “Would CRFs of different versions, but of the same name be considered ‘across CRF’s? In other words, the Response_label will not be able to be reused among same crf name with different versions?” No, and no.

    The only way to put a response label into OpenClinica is to define it in a CRF design spreadsheet. This way, the response label is tied to a CRF and version because its definition data originates there. This info has to originate somewhere for other items to reference it, also so that CRFs don’t change independently of creating new versions.

    Perhaps system-wide response labels could be created separately in OpenClinica somehow. This is what eDCI and CDEs are all about. We would prefer to leverage that approach in a future release of OpenClinica.

    Mike

    From: My Coyne [mailto:[email protected]]
    Sent: Thursday, November 09, 2006 9:43 PM
    To: Michael Sweeney; [email protected]
    Subject: RE: [Users] How to design response labels for different response types

    WRT: Response Labels cannot be reused across CRFs, so they must be fully defined in each CRF spreadsheet

    Would CRFs of different versions, but of the same name be considered ‘across CRF’s? In other words, the Response_label will not be able to be reused among same crf name with different versions?

    One could argue that there should not be such restrict use of RESPONSE_LABEL – fully qualified to be used in only one CRF (equivalent to one excel file). If one looks at RESPONSE_LABEL with unique name and unique attributes of OPTION_TEXT, VALUES, and DATA_TYPE, then the RESPONSE_LABEL can be used (re-used) among many different CRFs

    A classic example, an organization can predefine the following label: MY_ORGANIZATION_YES_NO to be ‘1-YES’, ‘2-NO’ and *ALL* CRFs of that organization can use MY_ORGANIZATION_YES_NO response-label throughout, across all CRFs.

    My Coyne
    Sent: Thursday, November 09, 2006 3:00 PM
    To: [email protected]
    Subject: [Users] How to design response labels for different response types

    Hello,

    How to design response labels for “text” and “textarea” response types

    When designing CRFs with the CRF Design Template, you must specify a RESPONSE TYPE, RESPONSE LABEL and DATA TYPE for each item.

    RESPONSE TYPE is the type of HTML control that appears for the data point. Options are “text”, “textarea”, “checkbox”, “radio”, “single-select”, “multi-select”

    RESPONSE LABEL must be alphanumeric, 1 to 80 characters long.
    For “text” and “textarea” Response Types, the label “text” may be entered. Response Options Text and Response Values may be left blank.
    For all other response types, a distinctive response label must be entered. Response Options Text and Response Values must not be blank for the label in the first row that it appears. Thereafter, Response Options Text and Response Values may be left blank in subsequent items that use the Response Label.

    The Response Label field allows you to identify a complex response item (such as a set of radio buttons with “Yes” and “No” options) for reuse within the CRF. This item can serve as a standard control that can be referenced by other items in the CRF.

    The first time a Response Label is used, it must have a corresponding set of Response Options Text and Response Values; both comma-delimited lists with the same number of arguments.

    Filling in the Response Options Text and Response Values fields for multiple items that use the same label is unnecessary, and can result in upload errors if these values are inconsistent.

    Response Labels cannot be reused across CRFs, so they must be fully defined in each CRF spreadsheet.

    Mike Sweeney
    Account Manager
    Akaza Research LLC
    One Kendall Square, Bldg. 400
    Cambridge, MA 02139
    U.S.A.
    p. 617..621.8585 x24
    f. 617.621.0065
    e. [email protected]

    www.akazaresearch.com
    www.OpenClinica.org

    "Open Source Informatics for Public Research."
  • JozefJozef Posts: 71
    We have international standards for setting up eCRFs and so we should use them ....

    Generating CRFs from spreadsheets seems not only to be in full contrast with the open source idea, it is also really very oldfashioned (stone age I would say).

    Best regards,

    Jozef Aerts
    XML4Pharma
  • mcoynemcoyne Posts: 20
    Dear Michael,
    It took almost a month to receive a reply to this opinion; and I almost
    forget what opinion that I had a month ago. (it is a long day and it
    means to be funny. Please laugh.)
    Let's be argumentative here. Logically, I would strongly disagree with
    your assertion in the second paragraph. While it is true that the
    response label has originiated from a CRF, it does not have to follow that
    ONLY that one CRF can use the response label, which is my question was.
    Practically, I can see the solution to the question is more complicated to
    implment. For example,
    a. Let CRF(1) creates and holds the definition for response label A (rl-A)
    b. Let CRF(2) decides to use rl-A (because the person down load the CRF(1)
    and thinks that matches his needs perfectly). In CRF(2), only the name of
    the response label is refered to, no definition for the response label is
    given, since it is given in CRF(1).
    If the owner or the PI of CRF(1) decides to delete its CRF(1), what happens?
    (i) OC will delete all metadata relates to the CRF(1).
    (ii) Let's say that OC is vigilant, it checks to see if any CRF is using
    this rl-A. Ooops, CRF(2) is using rl-A (whether it ties to a study event
    or not). What are the options? (a) leave rl-A alone. Don't delete it.
    If no CRF uses the rl-A, then go ahead delete rl-A.
    With this argument "Perhaps system-wide response labels could be created
    separately in. This is what eDCI and CDEs are all about" (I don't know
    what CDE is ), are you saying that Openclinica is NOT and cannot be a
    eDCI? I would claim differently.
    eDCI (electronic data capture, I assume) is only different than eCRF in
    that there is no paper form in eDCI. The design in eDCI is aimed at
    entering the data immediately into a db without having a clinician to
    enter data into a paper form and having a clerk to type the data in. It
    seems to me there are lot of usabilities (user extra friendly) that would
    place on a eDCI, and a person (data entry clerk) would be removed from the
    process. (Although, one can outsource this to other countries, but that's
    not the point.)
    Do you know that the ADI-R (of NDAR) is aimed to be used as eDCI? In
    which, a parent or a clinician will enter the data directly into the form
    without having using a paper format?
    While the ADOS (of NDAR) cannot be used in the same manner. Since the
    clinician has to pay complete attention to the patient and it is not
    desirable to distract such attention because one has to navigate around
    the form.
    The answer is 'depends on what the end user's needs'. I can see
    Openclinica can be used as eDCI.
    Thanks for an interesting conversation.
    > > My,
    > >
    > > "Would CRFs of different versions, but of the same name be considered
    > > 'across CRF's? In other words, the Response_label will not be able to
    > > be reused among same crf name with different versions?" No, and no.
    > >
    > > The only way to put a response label into OpenClinica is to define it in
    > > a CRF design spreadsheet. This way, the response label is tied to a CRF
    > > and version because its definition data originates there. This info has
    > > to originate somewhere for other items to reference it, also so that
    > > CRFs don't change independently of creating new versions.
    > >
    > > Perhaps system-wide response labels could be created separately in
    > > OpenClinica somehow. This is what eDCI and CDEs are all about. We
    > > would prefer to leverage that approach in a future release of
    > > OpenClinica.
    > >
    > > Mike
    > >
    > >
  • mcoynemcoyne Posts: 20
    My humble opinion: It is not because it is in a stone age, one would
    discard the idea completely. Excel is still widely used.
    I have seen many researchers are quite familiar with excel sheets. For
    that reason, a reasearcher can always navigate around the excel and
    quickly create his/her own CRF.
    With the advance of technology, many scientists and clinicians speak xml
    well to fluently, these audience can always use the Excel XML version to
    define his/her CRFs.
    OC version 2.0 would be able to generate CDISC. Pershaps someone from
    Akaza can comment on whether or not OC version 2.0 would accept an import
    of CDISC form metat data. I don't see why not.
    > > Well, what about CDISC ODM ?
    > > We have international standards for setting up eCRFs and so we should use
    > > them ....
    > >
    > > Generating CRFs from spreadsheets seems not only to be in full contrast
    > > with the open source idea, it is also really very oldfashioned (stone age
    > > I would say).
    > >
    > > Best regards,
    > >
    > > Jozef Aerts
    > > XML4Pharma
    > >
    > >
  • I agree completely. The current excel model provides a efficient
    standardized and non-complicated way to translate meta-data into ecrfs.
    Everyone has access to and understands excel making it an ideal tool for
    laymen to create ecrf's thru OC.
    -Bobby
    -----Original Message-----
    [mailto:[email protected]] On Behalf Of [email protected]
    Sent: Friday, December 01, 2006 2:53 PM
    To: dr. Jozef Aerts
    Cc: [email protected]
    Subject: Re: [Users] How to design response labels for different
    response types
    My humble opinion: It is not because it is in a stone age, one would
    discard the idea completely. Excel is still widely used.
    I have seen many researchers are quite familiar with excel sheets. For
    that reason, a reasearcher can always navigate around the excel and
    quickly create his/her own CRF.
    With the advance of technology, many scientists and clinicians speak xml
    well to fluently, these audience can always use the Excel XML version to
    define his/her CRFs.
    OC version 2.0 would be able to generate CDISC. Pershaps someone from
    Akaza can comment on whether or not OC version 2.0 would accept an
    import of CDISC form metat data. I don't see why not.
    > > Well, what about CDISC ODM ?
    > > We have international standards for setting up eCRFs and so we should
    > > use them ....
    > >
    > > Generating CRFs from spreadsheets seems not only to be in full
    > > contrast with the open source idea, it is also really very
    > > oldfashioned (stone age I would say).
    > >
    > > Best regards,
    > >
    > > Jozef Aerts
    > > XML4Pharma
    > >
    > >
  • My,
    I agree with your logic; I just wanted to make OpenClinica's present
    logic clear. This is a design limitation that we will eventually
    overcome.
    I also agree with your suggestions for how this capability can be
    incorporated into the product.
    eDCI (Electronic Data Capture Interchange) is an emerging standard, and
    CDEs (Common Data Elements) provide a definitive approach for collecting
    data points such as blood pressure, height, age, etc. - all of which, as
    you know, raise questions such as; how is the data defined, how many
    sub-parts of the data are there, how should it be displayed, what's the
    best control to use, should responses be limited or not, etc., etc.
    These initiatives address this problem on a larger scale than even
    OpenClinica! Ideally these CDEs would be developed and maintained
    independently, and would be freely available for users to include by
    reference in their OpenClinica CRFs. These could be used along with the
    items that users currently define inside of OpenClinica.
    Mike
    -----Original Message-----
    Sent: Friday, December 01, 2006 5:45 PM
    To: Michael Sweeney
    Cc: [email protected]; [email protected]
    Subject: RE: [Users] How to design response labels for different
    response types
    Dear Michael,
    It took almost a month to receive a reply to this opinion; and I almost
    forget what opinion I had a month ago. (it is a long day and it
    means to be funny. Please laugh.)
    Let's be argumentative here. Logically, I would strongly disagree with
    your assertion in the second paragraph. While it is true that the
    response label has originated from a CRF, it does not have to follow
    that
    ONLY that one CRF can use the response label, which was my question.
    Practically, I can see the solution to the question is more complicated
    to
    implement. For example,
    a. Let CRF(1) creates and holds the definition for response label A
    (rl-A)
    b. Let CRF(2) decides to use rl-A (because the person downloads CRF(1)
    and thinks that matches his needs perfectly). In CRF(2), only the name
    of
    the response label is referred to; no definition for the response label
    is
    given, since it is given in CRF(1).
    If CRF(1) is deleted, what happens?
    (i) OC will delete all metadata related to CRF(1).
    (ii) Let's say that OC is vigilant, it checks to see if any CRF is using
    this rl-A. Ooops, CRF(2) is using rl-A (whether it's tied to a study
    event
    or not). What are the options?
    (a) leave rl-A alone. Don't delete it.
    (b) If no CRF uses the rl-A, then go ahead delete rl-A.
    With this argument "Perhaps system-wide response labels could be created
    separately in. This is what eDCI and CDEs are all about" (I don't know
    what CDE is ), are you saying that Openclinica is NOT and cannot be a
    eDCI? I would claim differently.
    eDCI (electronic data capture, I assume) is only different than eCRF in
    that there is no paper form in eDCI. The design in eDCI is aimed at
    entering the data immediately into a db without having a clinician to
    enter data into a paper form and having a clerk to type the data in. It
    seems to me there are lot of usabilities (user extra friendly) that
    would
    place on a eDCI, and a person (data entry clerk) would be removed from
    the
    process. (Although, one can outsource this to other countries, but
    that's
    not the point.)
    Do you know that the ADI-R (of NDAR) is aimed to be used as eDCI? In
    which, a parent or a clinician will enter the data directly into the
    form
    without having using a paper format?
    While the ADOS (of NDAR) cannot be used in the same manner. Since the
    clinician has to pay complete attention to the patient and it is not
    desirable to distract such attention because one has to navigate around
    the form.
    The answer is 'depends on what the end user's needs'. I can see
    Openclinica can be used as eDCI.
    Thanks for an interesting conversation.
    > > My,
    > >
    > > "Would CRFs of different versions, but of the same name be considered
    > > 'across CRF's? In other words, the Response_label will not be able to
    > > be reused among same crf name with different versions?" No, and no.
    > >
    > > The only way to put a response label into OpenClinica is to define it
    in
    > > a CRF design spreadsheet. This way, the response label is tied to a
    CRF
    > > and version because its definition data originates there. This info
    has
    > > to originate somewhere for other items to reference it, also so that
    > > CRFs don't change independently of creating new versions.
    > >
    > > Perhaps system-wide response labels could be created separately in
    > > OpenClinica somehow. This is what eDCI and CDEs are all about. We
    > > would prefer to leverage that approach in a future release of
    > > OpenClinica.
    > >
    > > Mike
    > >
    > >
  • JozefJozef Posts: 71
    Yes, I realize many researchers still use Excel for CRF design.
    But, what I meant, isn't that a bit primitive in an age of visual design and drag-and-drop ?
    A few issues with Excel worksheets:
    - how do you validate a worksheet ? (in my previous job as head of scientific software development in a large pharma company, this was regarded as horror)
    - eCRFs in Excel format are not portable between EDC systems - CDISC ODM files are.
    - Can you submit a CRF design in Excel to the FDA ? Will the reviewers understand what is in your design ? With CDISC ODM you can and the FDA will understand.
    - when you design a CRF worksheet with Excel, can you immediately see how your eCRF looks like ? With many modern design tools you can.
    - there are many other issues that are solved when using the generally accepted open standards from CDISC.
    I would say that a BASIC requirement for each modern EDC system is that it can import CDISC ODM files to set up the system automatically.
    The tools for generating study designs (including the eCRFs) are already available (see e.g. www.xml4pharma.com/CDISC_Products/ODMDesigner.html, but there are also other vendors). Maybe they are a bit more expensive than Excel, but peanuts against the total cost of a clinical research investigation, and much more efficient.
    Wih best regards,
    Jozef Aerts
    XML4Pharma
  • mcoynemcoyne Posts: 20
    Disclaimer: I am an IT/analyst/bioinformatics user (as opposed to
    scientists, researchers, or clinicians) of Openclinica and don't have any
    interest in making propaganda for the product. I am all ears to hear great
    discussion on technical issues.
    I don't' know much about xml4pharma, but hope to see it one day, at some
    conferences, hopefully. I have used Openclinica quite extensively and feel
    that I can address some of the points you have mentioned.
    A. But, what I meant, isn't that a bit primitive in an age of visual design
    and drag-and-drop?
    Yes, it is primitive in designing of the form. But the product is not aimed
    to have The jury (consists of researchers) is out on this. I have observed
    researchers using both models: using a Excel and drag-drop software to build
    CRFs, and my assessments are:
    1. First impression, researchers are very comfortable seeing the Excel
    tool. There is no need to look for what widget to use for text; there is
    not a need to place a text box at a correct area, etc. The final form
    aesthetics look and feel are important; but it is more important to a
    researcher to put down the essential and critical questions on the CRF.
    2. Observing how a researcher navigate around an Excel sheet and a tool
    with GUI drag-and-drop, one will definitely see the difference in ease.
    Let's assume that a GUI Drag-and-drop has a great intuitive way to guide
    researchers in design their own CRF; this would minimize the learning time;
    I would claim that researchers, first and foremost thing in their mind is: I
    have *Important, critical, and well designed* questions to put down on my
    form to gather the information I need for my study; how do I do this? I
    don't think the researcher will ask "will the text box be a better choice
    than a drop down?". Should they be asking this question? Perhaps they
    should because how the data is collected would give them more accuracy to
    the data that they will rely on during the data analysis phase of their
    research.
    3. Cost: Most researchers do not have a lot of budget to hire a person to
    make sure the form look-and-feel perfectly pretty; if they can do it
    themselves with no cost, no learning time, why not? Excel is installed with
    the machine already. Kids in middle school use it already.
    With regards to the issues that you've mentioned:
    B. how do you validate a worksheet ?
    What kind of validation that you are talking about? Openclinica provides
    the following validations:
    a. When the Excel sheet is uploaded, there are general check for syntax.
    Example, the presentation of an item is 'text', not 'test'.
    b. checking in terms of consistency of metadata for an item (general term
    -- openclinica refers to it as response values, response options, etc.) An
    example of this is if an item (a question) was previously has response value
    of YES/NO, now it is changed to 'TRUE/FALSE'.
    Would there be more types of checking that you are looking for?
    C. Can you submit a CRF design in Excel to the FDA ? Will the reviewers
    understand what is in your design ? With CDISC ODM you can and the FDA will
    understand.
    Not knowing the FDA process, I am out in the limb here. I suspect that you
    might have used the term design with different meaning. In the context of
    using Excel to design CRF, I mean 'design the look and feel of a CRF'.
    While the meaning and standards used on each data item should be addressed
    in an organization. For example, a Patient ID should be named certain way,
    with a standardized format used for a patient id, etc. must be determined by
    the organization.
    Would FDA be interested in the CRF with data on them? Or Would FDA be
    interested in a DESIGN of a CRF? I would suspect that the FDA is interested
    in the CRF with data on them. In any case,
    a. CRF can be printed out in hard copy. Would this be sufficient for the
    later? (FDA has not gone completely to electronic, last I check the news).
    b. With an CRF that has data on them, Openclinica version 2.0 provide the
    export in CDISC format.
    D. when you design a CRF worksheet with Excel, can you immediately see how
    your eCRF looks like ? With many modern design tools you can.
    If "immediately" means couple clicks of buttons, then yes, you can. But if
    "immediately" means ONE click (e.g. view), then no. Yes, you are right OC
    (openclinica, I'm tired of typing the entire name. Is there OC a brand name
    in clothing?) is not quite slick in this aspect.
    E. there are many other issues that are solved when using the generally
    accepted open standards from CDISC.
    I claim that an organization can adopt CDISC standards and use this to
    implement via Openclinica. Many products would advertise that they 'support
    CDISC' and leave it at that; as a developers, I would say 'look under the
    hood... evils are in the details...'
    I would love to hear opinion of someone in Akaza Research with regards to
    this broad issue.
    F. I would say that a BASIC requirement for each modern EDC system is that
    it can import CDISC ODM files to set up the system automatically.
    Collectively as a group, we all work hard to achieve the utopia 'set up the
    system automatically'. I think we are far away from it; CDISC/HL-7 are all
    important standards, we all want to contribute to it. It is an organization
    issue to well define their CRF in conformant to CDISC; and tools help. But
    it is not to say that tool is the ONLY thing that would help to lower the
    cost of clinical research. It still requires a conscientious and vigilant
    care in designing the CRF using CDISC standards (or any standards) AND
    carefully using the tool as it was designed for.
    Thank you for a interesting discussion.
    -----Original Message-----
    From: dr. Jozef Aerts [mailto:[email protected]]
    Sent: Saturday, December 02, 2006 4:09 AM
    To: Sidhu, Bobby [CORP]; [email protected]
    Cc: [email protected]
    Subject: Re: [Users] How to design response labels for different response
    types
    Yes, I realize many researchers still use Excel for CRF design.
    But, what I meant, isn't that a bit primitive in an age of visual design and
    drag-and-drop ?
    A few issues with Excel worksheets:
    - how do you validate a worksheet ? (in my previous job as head of
    scientific software development in a large pharma company, this was regarded
    as horror)
    - eCRFs in Excel format are not portable between EDC systems - CDISC ODM
    files are.
    - Can you submit a CRF design in Excel to the FDA ? Will the reviewers
    understand what is in your design ? With CDISC ODM you can and the FDA will
    understand.
    - when you design a CRF worksheet with Excel, can you immediately see how
    your eCRF looks like ? With many modern design tools you can.
    - there are many other issues that are solved when using the generally
    accepted open standards from CDISC.
    I would say that a BASIC requirement for each modern EDC system is that it
    can import CDISC ODM files to set up the system automatically.
    The tools for generating study designs (including the eCRFs) are already
    available (see e.g. www.xml4pharma.com/CDISC_Products/ODMDesigner.html, but
    there are also other vendors). Maybe they are a bit more expensive than
    Excel, but peanuts against the total cost of a clinical research
    investigation, and much more efficient.
    Wih best regards,
    Jozef Aerts
    XML4Pharma
  • JozefJozef Posts: 71
    Thanks,
    It's getting to become an interesting discussion indeed !
    I am located in Europe, that's probably why you haven't seen me at conferences in the US yet. I try to catch 1-2 conferences in the US each year, but that is not always possible. Most of my customers are EDC vendors (both in the US and Europe) that need help with CDISC implementation.
    One of my recent customers specializes on rescue studies, and without CDISC standards this would be very difficult or nearly impossible.
    I think OpenClinica is a great development, is the first open source clinical system after Phosco that may become successful (others failed).
    I agree that if researchers feel more comfortable with Excel for CRFs, than they can use it,but the problem of portability between EDC system remains.
    OpenClinica does already have export in CDISC format which I think is very (but also the easiest to implement), but there is still a way to go (Lab data for example, what format does OC use for that ?)
    I think researchers indeed shouldn't have themselves ask what kind of widget should be used (i.e. the visual stuff) but that is also not what I meant. A study design tool (at least if based on CDISC standards), only requires that the user defines the question, the datatype (integer, float, date ...), whether there is a list of possible answers (codelist) and whether an answer to the question is mandatory or not. The EDC system should then automatically create the eCRFs and the visual layout (look-and-feel) based on some predefined rules. So this should not have to cost a single dollar and the researcher can concentrate on the science.
    I do not know what Excel costs in the US nowadays, but it is not for free, so also there there is a cost, although it may be hidden. For an open source system I was a bit surprised that it encourages to use Excel, and not for example OpenOffice, which is open source and freely available.
    And I do agree, some study design tools are overpriced !
    About the validation, this might be less an issue when the designer of the CRF is at the same time the user of the EDC system. But what in the case the designer of the CRF is at another location, has another function, and thus never sees the CRFs after they have been ported to the EDC system. What guarantee is there that the CRF is the same in the EDC system than in the worksheet ? I know that study design tools need to be validated, and the forms that come out of it, so I presume that also the Excel systems need to be validated. I know from practice however that usually this isn't done, as it is difficult to do...
    I think also the FDA issue is important. Sponsors need to submit the study data AND metadata to the FDA. The FDA is encouraging sponsors to do this in CDISC format. They are more and more also asking for the annotated eCRFs (i.e. unfilled, but annotated with submission - SDTM - information, i.e. which clinical domain and which submission SDTM variable), and the ideal format for this is CDISC ODM. I do not mean a visual representation of the eCRF, but the questions, codelists used, data types, application logic etc.., also the science and logic behind the CRF.
    To finalize, it is not an utopia that an EDC system is being set up fully automatically from a study desing in CDISC ODM format. I know of at least 5 EDC systems that have this feature. The study design is either made using a study design tool or an XML editor (which can be cheaper than Excel). The whole DB and EDC system is then set up in usually less than a minute. It might be less an issue in academic research, but doing so, the cost of EDC design is decreased enormously (sponsors sometimes pay pretty large amounts of money for that).
    I downloaded OC a few weeks ago, but haven't found the time yet to start working with it. I hope to have so during the next week. I will also try to set up CRFs using the worksheet mechanism (although I will try to use OpenOffice). So I can see how that works. I am especially interested how question dependency logic (e.g. automatically skip the question about pregnancy when the investigator enters that the subject is male) and range checks can be and are implemented.
    I am very positive about OC so far, but I find their statement "OpenClinica uses an extensive data model based on the CDISC standard for clinical research" pretty exagerated. But maybe I should first have a look at the source code to find out what the data model exactly is.
    Have a very nice weekend,
    Jozef Aerts
    XML4Pharma
    P.S. Just a remark about the naming "OC". In large pharma and at CROs, it is used for "Oracle Clinical" so indeed confusing isn't it ?
    ===========================================================================
This discussion has been closed.