The CDISC ODM Study Designer 2011

I really worked hard on it during the last days and weeks, but now it is there: the 2011 (beta) release of our popular CDISC ODM Study Designer.


The major new feature is a full implementation of the new CDISC "Study Design Model" (SDM) that was published for public review by CDISC just a few days ago. As this new standard (which is an extension to the ODM Standard) is still "in public review", I also designated the ODM Designer as "beta". The final 2011 version of the software will then be released once the SDM standard is approved and formally released.


You may wonder how it is possible that our new version of the ODM Designer is already there although the SDM has been released just a few days ago! The reason is simple: I was one of the co-developers of the SDM standard (together with Jan Kratky, Andrew Fowler and Peter Villiers), and in each state of the development I tested whether the proposed structure, elements and attributes were implementable in software. In our e-world, a standard that is not implementable in software doesn't make sense isn't it?


So every detail of the standard was tested on implementability, and the result is not only a good standard, but also the immediate availability of a software tool to work with it.



As such, one may say that our ODM Study Designer can be seen as a reference implementation of the new SDM standard.




By using the new standard, one can define features of a study that we not covered yet by the CDISC ODM standard (and that I already wanted to have in it for many years), such as study parameters (also required to be submitted in SDTM format to the FDA), eligibility criteria (i.e. inclusion/exclusion) - also in machine-readable format, study structure (arms, epochs, segments, activities, ...), and most important in my opinion: workflows and timings.





Within the team, I was responsible for the Workflow part, maybe the hardest part. Our workflow implementation is still pretty simple, e.g. not allowing workflows within other workflows, but I think we made something that is simple and easy enough to work with for people that design clinical studies. Of course one can already attach (very) complicated workflows in XML languages like BPEL, XPL, Window Workflow Foundation, or BPMN 2.0, to ODM through the vendor extension, but we wanted something that is easy to learn (the named ones have a steep learning curve) and can easily be implemented, and is still sufficient for describing >90% of the clinical workflows.





In the new ODM Study Designer I also implemented some special features that are very interesting for integration with the patient care world, and especially with hospital planning and information systems. For example, the new version of the ODM Designer allows export of the study workflow in BPMN 2.0 format, which is believed to become the most important standard for workflow definitions. Such an export (which is an XML file) can then be used in a hospital information planning system, in order to plan the clinical study within the care plan.


Another feature of the ODM Study Designer is that it allows to gerate a caBIG Patient Study Calendar (one for each arm on the study). The PSC is used by caBIG (and many other researchers) to provide a study plan for groups of subjects in a clinical study. Our export provides a PSC-XML file that can then be imported into the caBIG PSC software tool and used there.


The new Study Designer now also has a full implementation of the CDASH standards (v.1.0 and v.1.1). Users can just load CDASH forms from a repository that comes with the software, and can immediately start working with these forms.


But have a look for yourself - I already posted some information on the ODM Study Designer website, and there is also a "New features" brochure that is available on request.

Implementing the SEND 3.0 standard

SEND 3.0 final is out, so I started implementing it in one of my software tools (SDTM-ETL) . Now one of the problems is that the standard is delivered as a PDF file (which it should of course) full of tables with information about the individual domains like variable names, variable labels, data type, "CDISC notes" etc..

In order to bring this "knowledge" in a computer program, which I do by means of XML files that are read in when the program starts up, I needed to copy-and-paste the content of the tables from the PDF into the XML using an XML editor.
This of course stupid work! It took me already a full day, and I am still not completely ready.
So why are these tables not delivered by CDISC in a real machine-readable form? And I do not mean Excel files (although that would already be a start). Ideal would of course be that these tables are delivered as XML, as one can then easily transform them (just write a little XSLT) into the XML I need, which can then be read in by any software program that implements or uses the SEND standard.

During this "copy-and-paste" excercise I have been thinking a lot about why this is so (yes, although I am male I can do two things at the same time).
In CDISC we have to kinds of standards: content standards such as SDTM, SEND, controlled terminology, and format standards such as ODM and define.xml. The former are developed by domain specialists, the latter by technical (IT) people. Some of the latter have also become domain experts, but unfortunately there is not much technical (XML?) knowledge in the former group, not sufficient to also publish the content standards in a machine-readable form.
Should these people have these technical skills? Or should the technical people better help the domain experts with making these standards also available in a machine-readable form? I believe in the latter. But are the domain experts really interested in delivering their standards in a machine-readable form? I have some doubts.

CDISC already develops controlled terminology (CT) for more than 5 years. But only very recently all controlled terminology is being made available in a machine-readable XML form (thanks Lex!). I have been asking for this "feature" already for many years, as I had to spend so much time in doing copy-and-paste or using advanced tricks (to transform from Excel to ODM) each time an update was published, and I wanted to implement the new controlled terminology in software. But the CT team was not really interested. Only after NCI took over publication, and started asking for a machine-readable form of the CDISC controlled terminology, things were getting done.

I think we (CDISC) can improve here considerably by encouraging the domain people and the technical people to better work together. Why not make a rule that a technical person should be added to each "domain" working group (SDTM, SEND, ...) and made responsible to take care that a machine-readable version of the new standard is published together with it?
I agree that we do not have sufficient technical people (I mean people with an IT background) in the CDISC volunteer teams. It is volunteer work, and so it is difficult to find people that want to spend a few hours, or a day per week on the development of standards, unpaid. Maybe CDISC should find better ways to reward these people (volunteers must currently even pay their own travel and hotel costs to come to a face-to-face volunteers meeting). There is currently a giant amount of money available in the US for e-health, and it should be possible to obtain some of it to make it attractive to volunteers to work for CDISC.

But back to SEND.
Most of you know that I am an innovative guy who does not like SAS Transport 5. It is an ancient format stemming from the days of mainframe computers (internally SAS Transport 5 is based on IBM-mainframe binary formats). During my copy-and-paste excercise, each time I read sentences like "The value ... cannot be longer than 8 characters, nor can it start with a number" I became pretty frustrated. Why do we still use this ancient format for electronic submissions? Why don't we have an XML based format for this yet? Are SDTM, SEND, ADaM real vendor-neutral standards? Or are they still developed with one vendor in mind? Why isn't there any XML knowledge at the FDA?
But yes, this is a conservative industry. We made some progress, but I think we are still 10 years behind relative to other industries who have already completely switched to XML for many years.
With the very innovative people we have (I hope I can say I am one of them), we can leap up, but we need to get all the stakeholders convinced, especially the FDA.
But that's another topic I will later spend a blog on.

About this blog

Why this blog?

I have become involved as a commenter in several blogs about clinical research, CDISC standards, e-Health, electronic health records, so that I think it is now start to start my own one.

What I will do in this blog is give my thoughts about the CDISC standards, my involvement in their development, my involvement in different IHE-profiles for integration of electronic health records (and eHealth in general) and clinical research, and from time to time some technical tips, especially for working with ODM, define.xml, and SDTM and SEND standards.

I am now involved in the development and implementation of CDISC standards for 10 years, and I can say that I can (almost) claim to be a "CDISC guru". I think I am one of the very few independent consultants that have so many years of experience with the set of CDISC standards.

But I do not want to keep all this knowledge for myself. I want to share it with others. That's one reason for starting this blog. Another is that it is sometimes a good thing to publicly comment on what is currently happening with standards in healthcare, especially in the area of electronic health records and CDISC.
Where can we do better? What is holding is up? Why do acceptance and implementation take so long? What is the status of these standards at the FDA?
These are all topics I have a meaning about, and which I will try to post here.
I apologize in advance if people feel bad or even insulted by my comments. I have seen that people that have been involved in the development of a specific standard feel insulted when I criticize a standard. They shouldn't.
Standards development work is human work, and often compromises must be made in order to get them accepted by all stakeholders. Even when I say something negative about a standard, or give suggestions for improvements, this does not mean that I criticize the people that developed the standard. At the contrary, I have a huge amount of respect for these people.

So let us start now. I hope you will like this blog and send many comments.

Jozef

Jozef Aerts, XML4Pharma