|
||||
| Home | Services | CDISC | Software | About us |
XML4Pharma has itself developed a new, fascinating technology for use in EDC.
The technology is based on the automated transformation of a study setup in CDISC ODM format (v.1.2 or 1.3) into a set of eCRFs based on XForms technology.
Consider the typical example CDISC ODM file containing the definition of the study in the Study section.
This information (more specifically, each FormDef and ItemGroupDef section) can easily be transformated into an eCRF in XForms format using
an XSL stylesheet. The result of such a transformation can be seen here.
Once this single stylesheet has been developed, it can be used over and over again to construct new eCRFs, which each
can be deployed on different platforms and devices.
You can try out this technology yourself on our demo application server !
The eCRF in XForms format can be send to a device with or without extra presentation items (in our example we added a tiny amount of XHTML to have it a better look in your browser). Adding presentation can again be done using stylesheets. In smaller devices (like PDAs and cell phones), adding presentation will usually not be necessary, as the device itself takes care of that.
XForms have much more functionality than classic HTML forms,
as they take care of edit checking before the data
is send to the server (usually checking is already performed as one jumps to the next field). This is very well demonstrated
in our CDISC ODM example (note that we changed a few things in the data type definitions in order to demonstrate this).
In our CDISC ODM Study definition, it is stated that the data in the "IT.R_DRUG" field of the "IG.DEMOG" form,
containing the information about the Compound that is being tested, may not have more than 8 characters (see the
ItemDef element with OID="IT.R_DRUG" attribute). Through our XSL transformation stylesheet, this information is passed to the XForm.
When the user now adds more than 8 characters into the corresponding field of the XForm, the field is highlighted and a message is shown.
The same is true for the "Protocol Number" field (remark that we changed the definition in the ODM to demonstrate this): in the ODM it is defined that the Protocol Number should be an integer. This information is passed to the XForm, and if the user tries to fill something else than an integer into the corresponding field of the XForm, the field is highlighted.
The same is true for the "Height" and "Weight" field, which will only accept floating point numbers (or integers) but no other characters. At the same time the ODM "RangeCheck" elements are transformed into XForms constraint so that input outside the given range is simply not accepted. These constraints can even be calculated constraints: for example the acceptable range will differ whether the weight is given in Pounds or in Kilograms.
Try out some of the samples ...
Depending on the device, a lot of functionality can be available. For example, devices can show a Calendar, if a date has to be given. This avoids that the user gives a date in an invalid format, or that an invalid date is entered. In our example, this is the case for the DOB (Date of Birth item). In the browser implementation, a Calendar frame pops up where the Date of Birth can very easily be entered.
Very interesting is that enumerated lists (i.e. the value can be only one of a certain list) are automatically transformed into a suitable widget by the device (remark that in the XForm itself, it is not defined how lists should be presented). This widget will or can be different for each device, depending on the screen size and the possibilities of the device). It is the device itself that decides how the presentation is done. The great advantage is that e.g. codelists can be passed to the XForm, which are then presented as choices to the user. This means that the user sees the actual string values that the code represents, and not the code itself. However, when the data is send, it is the code that is send to the server. This means that it is much more difficult to return an inappropriate value, as the user does not have to know the codes themselves.
In our example, there are two codelists passed: one for the gender (IT.SEX with possible values of F (Female) and M (Male)),
and for the record status (IT.F_STATUS with possible values of S (Source verified, not queried) or V (Source verified, queried)).
The user of the device never sees the codes themselves, but is presented the actual values (in his own language),
so that mistakes are nearly impossible.
Also ODM RangeChecks are easily transformed into XForms 'language', so that values entered by the user can be accepted or rejected depending on whether they are within range as defined in the CDISC ODM file with metadata. As already said, these ranges can be (on-the-fly) calculate ones, e.g. as function of the units of measure that is used by the investigator.
The upcoming CDISC ODM 1.3 standard even takes a step further. The new EDC features of the standard allow to define conditions on almost any level of the metadata.
It allows to define conditions under which a visit must not be executed, a form must not be filled, a group of questions or a single question can be skipped.
For example, it allows to define (as a machine-readable expression) that questions about smoking habits are automatically skipped when it is ticked that the
user is a non-smoker.
These ODM conditions are transformed into XForms conditions automatically with our technology. This causes e.g. all the questions about smoking habits to disappear from the screen
(or blanked out) when the investigator ticks that the user is a non-smoker.
When using XForms in EDC, one of the great advantages of XForms becomes striking: as XForms applications send their data back to the server in XML format, this XML can easily be transformed into CDISC ODM clinical data, and the result can easily be be stored in a datawarehouse of native XML database, in ODM format, until they are collected, and assembled into a full ODM file (ClinicalData section). This may implicate that much simpler (and much more inexpensive) CDM or EDC systems can be developed, with the additional advantage that the data is already in the (by the FDA preferred) ODM format.
Although the CDISC ODM already allowed for localization of questions and codelists (i.e. having them defined for different languages in one and the same file),
the new ODM 1.3 standard has further extended the concept to the level of StudyEvents, Forms, ItemGroups and Conditions.
This means that when using the ODM 1.3, all eCRFs can be generated automatically for all necessary languages with one or only a few mouseclicks.
A number of eCRF samples in XForms format, most of them automatically generated from a CDISC ODM file with metadata, can be tried out on the samples page.
Convinced about the advantages of automated transformation of ODM metadata into eCRFs ?
XML4Pharma can help you with the development of the technology for automated generation of eCRFs from CDISC ODM metadata, being it using XForms technology, or
any other technology for use in web browsers, on PDAs or on smart phones.
For more information, contact us at info@XML4Pharma.com.
Well, here are the answers on frequently asked questions
