Wednesday, December 21, 2011

SDTM Amendment 1 is out

Just released by CDISC: the SDTM Amendment 1.
The amendment was created by a number of CDISC volunteers in cooperation with CDER (FDA) - other departments seem to have not been involved.
It adds a new set of variables (MedDRA codes and decodes) to the Events classes and also some new variables to the Demographics domain. Also the AE domain is extended with the new "MedDRA" variables, so that each row in the AE now has 51 (!) fields.

Fortunately, the changes and additions are not very extensive nor complicated, so that I could implement everything in our SDTM-ETL software package in just two evenings.

However, the SDTM Amenment 1 also raises a lot of new questions like:
- what about submissions that do not go to CDER (but e.g. to CBER): are the new set of rules also applicable in that case?
- or is the Amendment 1 a "CDER dialect" of the standard?
- other departments than CDER seem not to have been involved. Do they agree on these additions and changes? Were they asked at all?
- why isn't this a new version of the standard. Amendments to "final" (?!) standards are always dangerous.
- MedDRA codes need to be provided as numeric values. Now these codes are 8 characters long. Can SAS XPT cope with such very high numbers? I have some doubts.
- how do I deal with this new "standard" in define.xml? The latter is not even mentioned in the document!
- what do I need to fill in for def:StandardVersion in define.xml? Most software packages use that attribute for finding out which version of the standard was used.

and many many more ...

Saturday, December 10, 2011

Difficult days for CDISC end-to-end

The last two-three weeks were difficult ones for the CDISC end-to-end cause.

There was a lot of discussion within the volunteer team that is developing define.xml 2.0 whether elements like "MeasurementUnit" should be allowed in define.xml 2.0. The reason is that some of the team wanted to discourage (or even forbid) the use of "MeasurementUnit" in define.xml 1.0 and future 2.0 files, as "MeasurementUnit" is not explicitely stated in the define.xml specification. Others were of the opinion that "MeasurementUnit" has always been allowed in define.xml, as define.xml is an extension of the ODM standard. Also, several vendors of software for generating define.xml files do use "Measurement" as it is the most natural way to attach information about which units were used in which tests.
The discussion however has a deeper origin. The real question is whether define.xml is part of the chain in end-to-end (i.e. is the "last mile" to the FDA), or is just something totally different for which (unfortunately?) ODM was used (or abused?). Or as one participant stated "define.xml is another animal".
The discussions were heavy: some of the team were of the opinion that (as define.xml is totally something different) not a single element or attribute of the core ODM should be allowed in ODM if not explicitely mentioned in the define.xml spec (and also refusing to have "MeasurementUnit" in the new define.xml spec), others were of the opinion that define.xml is an important part in CDISC end-to-end, and that people should be allowed to provide additional information (such as MeasurementUnit, Question, RangeCheck etc.) to a define.xml and so to the FDA, supported by an appropriate stylesheet. This information would just come from the original protocol in ODM format without needing transformations.

At the moment that a "groaning teeth" compromise was in sight, allowing people to use define.xml either way ("strict" or "loose"), everything was questioned again by a member stating "a standard that has such compromises is not a standard".

So instead of coming to an end, the heavy discussions started again.

My personal opinion (which you may have guessed already) is that define.xml is an important link in the end-to-end chain, and using ODM elements and thus information coming from the original study design has a tremendous value.

I do not know how the discussion will further evolve. The best I think is that the compromise that was ultimately reached (but gives stomache aches to almost all of us) is implemented. If not, I am afraid that the discussions will go on, and a release of define.xml 2.0 is out-of-sight for several more months.

To better explain the (visionary? although already used by several vendors) idea of end-to-end (i.e. using one transport format from protocol design to submission to the FDA) I have decided, together with a few others, to start a new blog site, which you will soon find at

It will be open to anyone having a good heart for the CDISC end-to-end case.

Saturday, December 3, 2011

A glimpse of hope

A few days, Becky Kush (president of CDISC) informed me that the FDA recently appointed a new CIO who has a track record of success in science in pharma industry.
I do not know Eric Perakslis personally, but I heard some very good things about him. Eric launched the TranSMART project at J&J, so he surely is a visionary IT guy.

The one million dollar question will be if he will really get the empowerment that is needed to structurally change something at the FDA, and bring their IT (which is currently in a desperate state - see the previous blog entry) on such a level that it can cope with the IT level on which the industry is acting.

Already more than a year ago at the Baltimore Interchange, I heard Theresa Mullin of the "Office of Planning and Informatics" (i.e. the CIO's department) telling us about all the plans she had for improving things at CDER. More than a year later still nothing seems to have changed: CDER does not have any servers, databases, good viewers, XML or database knowledge ...
The problem is that (which she told us herself) is that she cannot force any department to develop or implement something (advisory role only).

Will Eric Perakslis also be chained into such an "advisory role" as all his predecessors were? Or will he get the power, people and financial means to really change things? Will he be able to force departments like CDER to bring their IT into the 21st century?

I really hope so ...