In a previous posting, I made reference to a technology called XForms. I mentioned that it might prove of some value in addressing the challenges that eClinical systems face in meeting business demands.
XForms is an interesting technology in a number of ways. To understand what it brings, it should be understood what the traditional method of browser data presentation lacks. HTML remains the standard means of presenting form information on a screen. It fundamentally dates back to 1995 in its present state when the Internet really took off. As far as broad standards for forms based data capture, things have not really moved forward greatly since then.
HTML forms are built in 100's of different ways by software residing on the server. Typically, the developers will take lots of strings containing things like <Head>, <TR> or <BR> etc and glue them together to make up the necessary codes required to present a form on a browser. Admittedly, there are lots of 'helper' technologies to make things easier such as Extensible Style Sheets (XSLT), Dynamic HTML etc, but, ultimately, there is no one way to effectively create and deploy forms to a browser. In particular, there is no way to easily separate what a Form Does from how a form Looks
The W3c group recognized this challenge and create the XForms standard released October 2003.
'So, yet another standard that will disappear into obscurity!' I hear you say. Well, maybe, but, even if it does, it has some attributes that are worth understanding, when considering how things should work in the ideal world.
Benefits of xForms
- User Interfaces built on XForms require fewer round-trips from client to server - they are more self contained than pure HTML implementations. This leads to a better, faster user experience
- Mobile device capabilities vary significantly. Creating a form interface that works on a iPhone as well as on a 1400x1200 resolution desktop is very difficult. XForms provides the separation to allow this to occur with common code.
- Javascript is the tool many developers use, on the client browser side, to workaround the limitations of HTML. However, Javascript is implemented differently by different browsers, and, can even be disabled for security reasons. XForms provides a means to avoid this limitation.
More about xForms
All sounds cool.... so, lets find out more about xForms...
XForms implements the concept of Model/View/Controller. Sounds like mumbo jumbo, yes, so lets translate that into some meaningful.
When you capture information from forms, you can define 3 distinct layers to efficiently achieve a design.
Presentation - 'the View'
Starting at the user side, you have the Presentation side. On a regular desktop browser, you will maybe have a form presented in a free form layout with 20 questions, nice shaded graphics etc etc. On a PDA, you want something simply, that scrolls well - so you would have a smaller set of questions, presenting with no fancy graphics, and in a simple list layout. The Data you are after is the same. The Logical rules you want to apply to the data are the same - it is only the presentation medium that is changing.
Logic - 'the Controller'
Next, we have the brain. The part where all the rules exist. This is not 'eClinical' specific, but, to use an EDC requirement, this is where all the edit check rules exist. The logic is attached here, and separated from the Presentation Layer in order to ensure that regardless of the layout of the form, or, the device used, the same rules can be applied (and most importantly) re-used. This controller can be split into two areas - handling requests form the presentation for dynamic activities - as well as processing the results in a common way.
Data - 'the Model'
Finally, the 'what' in the structure. The data resides in the Model - or rather the definition of what data. Aligning with the eClinical analogy, SDTM would be an appropriate specification for the definition of what might exist here.
xForms and CDISC - applying the Model
So, how might XForms be applied to the CDISC in general?
To some degree, CDASH defines a set of fields that will be captured without consideration of the device that might capture them. You could have a situation where a PDA might capture 4 questions at a time whereas a desktop browser would capture 20. The definition of the form itself will differ due to the medium. So - CDASH in this perspective doesn't fully fit. However, as a means to standardize the 90% rule - most forms are completed on a full size browser - it is fine. CDASH provides a recommendation of what would be captured together in the presentation layer for one type of device.
So, where would CDASH fit in the XForms Model / View / Controller paradigm?
Lets look at a possible model for metadata that could be implemented with xForms:-
Starting from the left - the obvious model for the Data (Model) is SDTM. This would include a list of all of the standards Domains. It could be extended as required, and include sponsor specific extensions structured as per the SDTM standards specification
Next in the middle, we have the Logic (Controller). CDASH could potentially work in this middle tier although you would need to add the logic elements. A Module could equal a CDASH Domain with all of the potential (required and optional) fields included.
Finally, at the Presentation (View) the Form. This would be a representation of the CDASH domain with specific controls (drop downs, radio's etc) added and fields not required for a specific instance removed. Multiple instances of the form might exist with the same rules and relationship to the Data Model carried forward.
Conclusion
xForms in the context of CDISC and eClinical is not so much a means of capturing the data. Rather, it is a means for modelling the metadata to better support the separation of the data that is needed from the logic that must be applied, and the presentation of how this is achieved.
With a model applied similar to the above SDTM data sets could be quickly achieved while at the same time offering flexibility in the medium used to capture the data together with a consistency in the rules enforced.
I have purposely left out references to ODM in the above article. It may have a place here, but I will expand on this in a future posting.
