We're a small CRO, operating a proprietary EDC system. We're in the process of developing a CDISC ODM compliant export. The plan is that exported data structures can be configured in the EDC system, thus reducing the programming effort required to import into SAS data sets.
We anicipate that a CDISC export will also load directly into popular CDM systems such ac Clintrial and Oracle Clinical.
Does anyone out there have any feedback regarding CDISC support from either of those systems?
Both Phase Forward and Oracle are participants in CDISC (http://www.cdisc.org/sponsors_members/index.html) and information should be available on their respective websites. I'm curious though what the value is in pushing data back into the CDMS systems from your EDC solution. Is this a requirement of your customers? It seems that since you're already exporting data into SAS, pushing it back into the CDMS is moving the data in the wrong direction.
Our EDC system 'exports' the data by copying it into a seperate Oracle database in which the data structures are somewhet simpler than in the main EDC tool. We then pull the data out of these tables using SAS/Access. The problem is that this still requires a significant amount of coding because the we have to 'map' the incommng data to the SAS datasets (not all of our CDM can be achieved in the EDC system). So we have a suite of SAS code that performs a simple 'ETL' type of function. Our plan is to modify our EDC system so that the relationships between the online forms and the CDISC domains, forms, etc is configured prior to export. We can then import into SAS using PROC CDISC or our clients can import directly into their CDMS using their systems CDISC support.
Also, it is my understanding that many sponsors collect the data using EDC but perform final data management tasks in a CDMS such as Oracle Clinical. So although most of our data management is done directly in SAS we will also have the ability to supply the data to sponsors directly from our EDC system in a format compatible with their internal systems.
I work for a CRO that has had some internal activity with regard to preparing for CDISC standards, but until now, has had very little need to produce compliant deliverables for clients. We recently had a request for a DEFINE.XML and are wondering how to begin. We have little, if any experience with XML here - should we be trying to come up to speed with learning it, or should are there SAS tools available so that this wouldn't be necessary? In a more general sense, the question goes for the whole CDISC process - where do we start? How much XML knowledge is needed?
There are SAS tools that support define.xml, but they generally require some additional work beyond using just 'proc cdisc'.
There's a wealth of information available on the web regarding where to start -- www.cdisc.org lists training classes and the like. In the end, the answer to the question comes back to 'what do you want to do with CDISC?'. Are you just interested in creating the define.xml? Do you need to deliver SDTM data to your sponsors? Do you need to load ODM data from an EDC system?
The makeup of DEFINE.XML is described in a PDF document on the CDISC web site. It wasn't too hard to understand. From Mike's post it seems like XML is quite unknown to him. I can tell you that XML is the easy part. Knowing your specific standard is where the complexity comes in.
XML is just a way to mark up data. You surround it with tags that you make up. Like this.
John Leveille d-Wise Technologies, Inc.
So, since XML is markup using any tag names you like -- how can it be useful? Well, it becomes useful when someone makes a standard that we all try to use. That is precisely what CDISC is doing for the Pharma community.
So, there is this standard that CDISC has come up with called SDTM - Study Data Tabulation Model. The grand idea is that if we all put our study data into SDTM XML formatted files, then we can have a file called DEFINE.XML that basically provides a manifest of all the tables in columns in the study -- then we should be able to exchange data between lots of different companies and software systems.
The reality is far from this utopic vision, but that is where the CDISC organization wants to help us go.
I think Mike points out an interesting fact. Smaller organizations don't have the inertia of big pharma. So many times they just decide that it is both easiest and cheapest to come up with the most expeditious, albeit proprietary, data transfer mechanism. It is within the larger Pharma where the motivation is higher to embrace the standard in an effort to save money and rework.