I love the idea of the CDISC Operational Data Model (ODM). I'd have to say that right now it's my favorite CDISC standard and I think it has huge potential.
But I'm wary of Vendor Extensions.
What are Vendor Extensions?
Vendor Extensions are a mechanism for adding new attributes and elements to an ODM file. Since the ODM is an XML format new namespaces can be declared and mixed into an existing file to decorate it with more information for a particular flavor of system.
The Operational Data Model is just that, a model for clinical data. It allows you to model clinical trial metadata (study events, forms, fields...) for the purposes of adding context and meaning to the clinical data. But it's fuzzy: the ODM does not include elements that describe, say, the color or font size of a question label but it does include elements that can describe the validations executed on the data. In my view both are providing some context to the data.
Anyway, sooner or later you are going to want to bend the ODM to do something just a little outside its abilities - like use it as a transport mechanism between SystemA and SystemB. This is exactly what FastTrack did when they announced that they were exporting ODM files from their TrialSpace Designer® into five different EDC systems (FastTrack are now owned by Medidata) What happens if TrialSpace captures important information that would be useful to those EDC systems (like label color or font size) but which aren't modeled by the ODM? Do we just shrug and accept the limitations of the ODM? No, we'll use the Vendor Extension mechanism and add the elements we want.
Why I don't like the idea of Vendor Extensions
That's what I don't like about Vendor Extensions, the fact that they are not themselves standardized. If I'm building a tool that provides eClinical systems with study metadata using the ODM then I'll need to work with every eClinical vendor to support their particular extensions. Yes, I can just ignore the vendor extensions and supply a baseline ODM file but it's not going to be as satisfying for my end users.
The ODM is an open standard, the spec is available for free and anyone can implement it. This encourages innovation and lowers the barriers to entry and therefore costs. Vendor Extensions are not open, the vendor is under no obligation to share them with the market and the effect is that meta-tools and inter-operability are held back.
Many sponsors would like a write-once-run-anywhere approach to EDC systems. Cook up the study design in your ODM designer of choice (including notepad for the die-hard techies) and then apply it to the most appropriate EDC system for the study at hand.
Standards that arn't standards, closed standards, standards that have been embraced-and-extended limit that vision and ultimately hold back the market.
So what can be done?
Vendors aren't motivated to publish their own extensions widely, why should they be? It would be like giving their competitors a free preview of their system architecture.
ODM end-users need to be wary of the charms of vendor extensions. Use them when there is no other choice but lobby the CDISC ODM group to extend the base ODM to include features that are the same between vendors.
Overall, my point is that Vendor Extensions to the ODM are useful but have the potential to balkanize the market. As an industry we shouldn't be distracted by Vendor Extensions to the detriment of the underlying ODM. Vendor extensions help the vendor, the ODM helps the whole market.
2012 Europe Interchange — EHRs
1 week ago
Posts
11 comments:
Like your blog, excellent topics and neutral perspectives...
Can you share who you are? or do you work for one of the EDC vendors?
keep it up
Hi Anonymous.
A problem we have in this industry is that there are too few genuine voices.
We have the company-serving position pieces that you find in the industry magazines (and to some extent ClinPage) which are carefully groomed by marketing before release and we have the toll-booth, invitation only reports by people like Forrester and Waife.
Nothing wrong with those, they all serve their purpose. But where are the voices of the people who really built this industry? I've met my share of the pioneers and they always have something to say but you can be sure that the companies they work for would much rather they worked hard and stayed silent.
I'm sure my employers past, present and future feel the same way. Even though I'm not going to use this blog to reveal trade secrets, trash-talk individuals/vendors or to give away competitive information (and I will remove comments that do) I would become associated with them if I didn't post anonymously.
That's a pity because I'm not usually shy. But the upside is that at least we can have a real conversation even if we have to hide behind masks to do it.
I'm convinced that we could have made more progress in these last 20 years if we'd just talked more.
I hope everyone with an opinion will join the conversation and we'll all understand if you have to do it anonymously.
Ditto Anonymous's comment. Excellent blog with interesting discussion topics.
Here's to blog driven progress!!!
Lowest Common Denominator
I was never a great fan of the ODM standard. On the surface it models the metadata for capturing clinical data, and, it relates the metadata from fields, to forms and events. However, it is not the optimal structure for building studies. I will probably write up a blog on that one... another day...
ODM is the lowest common denominator when it comes to capabilities. If an EDC vendor was to limit themselves to the scope of the native ODM in their own systems, then the systems would be very poor.
So, to be competitive, vendors develop features in the metadata that go well beyond ODM.
Now, lets say, SystemA sends basic ODM to SystemB. SystemB has the basics of a study definition. Sounds good. However, to take this basic study definition and convert it to a full vendor specific study definition without the benefits of potentially local vendor libraries may take longer, than building the study natively from scratch.
The largest chunk of time spent when building an EDC study is typically the edit check building. A typical study might have 500 edit checks. A proportion might be handled by field attributes such as 'Required'. However, that still leaves a chunk of edit check development work.
So, the value of an ODM transfer without extensions should be measured by the time-savings that might be gained versus manually building and checking a study in the target system.
When vendors consider ODM support, they also have a decision to make regarding the general portability of their own metadata. Do they create a proprietary format in addition to ODM that supports the full scope of their EDC system potential, or, do they look at extending ODM through vendor extensions.
If the vendor creates a proprietary metadata interchange format, then that works for the vendor only. If the vendor goes with ODM + vendor extensions, then that works for the vendor + other ODM compliant companies. Easy decision for those vendors that can make it.
So - how do we handle these incompatible non standard vendor extensions? I think the answer is that vendors will cope. Vendors will either create toolkits that accept ODM, and add the means to process non standard vendor extensions beyond just ODM. OR, the vendors will offer custom development services to process the non standard extensions during import.
Eventually, new standards for things like edit check logic will evolve. The most successful vendors will be in the strongest position to push their own vendor extensions 'provided' they are open.
It's me Anonymous... I'll call myself "Anonymous_S" to keep my anonymity specific....
Again, keep it up! I plan to pass the word and share you blog and will continue to contribute, thanks for creating this...
Anonymous_S
User "EDC Consultant" and user "eClinicalOpinion", would you join the CDISC ODM Team ?
We can always use good people that come with POSITIVE contributions.
Vendor Extensions are indeed there to allow to extend the standard for those things the ODM team could not find a solution or could not find consensus.
As such, they are better than having nothing in place.
Remind that developing a standard is for 90% finding consensus and for 10% technical implementation.
In some cases also standards find their limits, especially when coming on the playground of other standards, or of competing standards.
Let me give an example: in one of the blogs you mention color and label of fonts. There are several competing "standards" for this: (X)HTML, CSS, not to speak about Java, C#, ...
So should the ODM team have arbitrarily selected one of them ?
Or should they have reinvented the wheel and develop one another "standard" for colors and fonts ?
The CDISC ODM team wants to further improve and extend the standard, but it needs people (unpaid volunteers) to do the job.
The ODM team has always invited vendors to propose their extensions for use in future core ODM, and some have really done that.
So, extensions are also very good "sources of inspiration" for the ODM team.
So, if you would like the ODM standard become better, so that study designs and study date become even more portable, please join us !
Best regards,
Jozef Aerts
XML4Pharma
CDISC ODM Team and ODM co-developer.
Hello Jozef, welcome to the conversation!
First let me say that I am very grateful for your work on the ODM and admire your tenacity in pursing it for all these years. I believe the hard work is starting to pay off and that vendor acceptance and USE! of the ODM is beginning.
It is obviously painful for you to see your work criticised by people hiding behind pseudonyms online. Please understand that many of us would rather speak anonymously but geninuely than be called to heel by our employers.
If you read my posts on the ODM you will see that I am a strong supporter of it but I am wary of vendors desire to "embrace and extend" the standard in a way that weakens its wider appeal. I want the ODM to be one true standard and not a set of competing implementations.
I know you are working to the same goal. I may not be able to join the ODM team but I will continue to promote the ODM in my day job and also through this blog.
As an outsider to CDISK ODM I am wondering what - if any - developments have been achieved over the past year or so. The discussion seems to have stopped about at that time.
Currently I am in the process of deciding whether to use CDISK ODM, DDI (Data Documentation Initiative DDI 3.0 - http://www.ddialliance.org/ddi3/#ddi3.1main) or another xml standard for conversion of a system, until now based on a documented flat file syntax system (Epidata.dk). The problem seems to be that the ODM format actually are lacking these parts:
1 screen font selections and positions for fields
2 user access control indication
3 encryption principles
Are there any plans for such extensions or should we - if choosing ODM - document these as extensions.
Hi Epidata,
first a small correction: it is CDISC, not CDISK.
DDI is surely not a bad alternative. However, it will probably lead you to a file that is not portable between EDC systems, and surely not very usable for moving along to FDA submission (SDTM) data once the database is closed.
The CDISC ODM standard is a minimum set (although that "minimum" grows). The great thing about the ODM is that it is fully extensible, i.e. you can add additional features to it as "vendor extensions". Every major vendor has added its own extensions, exactly for covering things such as screen fonts, screen layout, credentials etc..
Technically spoken, each of these extension XML attributes/elements "live" in their own XML namespace, so that it is always clear whether the element/attribute belongs to the ODM standard or whether it extends it. There is no real enforcement that you need to document the extensions, although it is surely not a bad idea.
I have been developing ODM "vendor extensions" for quite a number of EDC systems (some of them now being ODM-certified, see http://www.cdisc.org/odm-certification) and I must say that the vendor extension mechanism in an extremely powerful one.
With best regards,
Jozef Aerts
XML4Pharma
(and CDISC ODM Team member)
The problem with ODM is the "vendor extensions" the standard needs to evolve to ensure true "end to end".
They are!
We more and more encourage users of the standard to add infomation for "end-to-end", i.e. CDASH and SDTM information. This is done using the "Alias" element. See http://www.xml4pharmaserver.com/XML4PharmaWiki/doku.php and look for "annotating ODM with SDTM and CDASH information".
Some of us also have started a new initiative (after the FDA finally found out that HL7 messages are NOT a good idea for SDTM) to extend the ODM and the define.xml for also porting SDTM information.
Furthermore, a (standardized) extension is currently being developed for carrying study design (arms, epochs, segments, activities, workflow, timing etc.).
All this can lead (if the FDA cooperates) to an ODM that is used end-to-end.
Best regards,
Jozef Aerts
XML4Pharma
Post a Comment