Search This Blog

Tuesday, February 10, 2009

Applying XForms to CDISC

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

  1. 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
  2. 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.
  3. 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:-

xforms123

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.

6 comments:

Eco said...

Interesting. I see a few barriers to adoption however.

1. XForms provides client-side form validation. Do I hear the sound of DataSci's lawyers parachuting in as I type?

2. Browsers that end-users have (IE 5/6/7) are still lacking in support. That leaves server side approach as the only really viable option.

But you are pressing one of Jozef Aerts hot buttons. No doubt he will be along in a moment to comment.

Doug Bain said...

All valid points.

1). Sadly, the cost of doing business - like it or not.

2). Native support is achievable, but I accept some work is required to make this seamless.

3). I think Jozef is hot for the ODM based XForms approach. I am not sold on that part yet. ODM is the sort of unfolded equivalent of the 3 tiers. It could serve a purpose - the sort of compiled down version of the definition, but I don't see it as the building blocks.

Alessandro Vernet said...

@eClinicalOpinion, regarding #2, like you said, a server-side solution will work on all the mainstream browsers deployed in the field nowadays.

Depending on the implementation you use, it is also a solution to #1. At least in Orbeon, we make sure that all the constraints you declare in your form are also enforced on the server for you.

In the same vein, Orbeon makes sure that users can't modify parts of the XML they are not given access to, or even that they can't see parts of the XML which are they are not given access to.

Today, all those issues are well known and I think that server-side XForms provides a reasonable solution.

Alex

Doug Bain said...

I took a look at the Orbeon Forms product, following your post. If you're product is as well organized as your website, then it should be high quality.

Without digging deeper, I cannot tell how an existing set of standards such as CDISC ODM or CDISC SDTM might be realized using Orbeon Forms. Possibly just a standard method that - as you say - would allow the balancing of logic on the front end with logic on the back-end without complex Javascript & Ajax coding. Whether it avoids eC's point 1... too early to say.

Thanks for your input Alessandro.

Alessandro Vernet said...

Can you point us to more information about CDISC ODM and CDISC SDTM? Maybe there is something I can help with there.

Alex

Doug Bain said...

The best place to go is the cdisc.org site itself. The standards are under http://www.cdisc.org/standards/index.html

SDTM, ODM and CDASH are probably to most relevant.