How to design response labels for different response types

Michael Sweeney

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."

mcoyne

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."

Michael Sweeney

“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."

Jozef

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

mcoyne

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
> >
> >

mcoyne

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
> >
> >

bobbysidhu

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
> >
> >

Michael Sweeney

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
> >
> >

Jozef

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

mcoyne

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

Jozef

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 ?
===========================================================================