The FDA and the "Standard Issues Document"

A week ago, I had a teleconf with a number of people of a department of the FDA regarding the "CDER Common Data Standard Issues Document".

The FDA itself had asked readers of the document to provide/send comments, so I did.
In my comments, I protested against (amongst others) the additional requirement that variables such as EPOCH, ELEMENT, ECTD must be added for each observation domain.
My comment was that this is ridiculous, as this information is already in the study design domains, and can easily be looked up easily e.g. though the visit number. A simple "table join" suffices.

In my classes on databases to undergradute (Bachelor) students, I learn them that redundant data in tables (of databases in this case) should always be avoided, as this easily leads to inconsistency (violation of the "ACID" properties).
With their additional requirements, the FDA is massively introducing redundant data in the SDTM tables, which I consider very bad practice.
But back to the teleconference: it was set up by the FDA represenatives to explain to me the "why" of these additional requirement. It looks as I am sufficiently influencial that they decided I should be talked to.

They explained to me that the reason for these additional (redundancy creating) requirements is that they do not have any mean of joining two tables. So they use the SDTM tables both for storage AND for presentation, as is. They do not load the tables into a database, as they haven't got one, nor the knowledge to create one, nor a server to put them on. They have SAS, but no people that can uses it. That is what they told me.

I was shocked!

Creating databases, populating them, and generating views of them (with joins) is something I learn my undergraduates, and which they pick up quickly, as it is not difficult.

But, the FDA people told me, they hope they will be able to do so in about 1-2 years.
They however appreciated my comments, and told me that they expect a lot of the new cooperation with Phuse, especially with the results of the (now yearly) "FDA/Phuse Computational Science Symposium". So they asked me to attend the next one (in Silverspring, March 2012). I objected that I live in Europe and so would need at least compensation for travel and accomodation, which they can't provide me. I can hardly imagine that the university provides me the necessary funds to attend that symposium. After all, as a professor I am expected to do innovative work, and not to teach the FDA how they can make a join or view on two tables.

So unless someone provides me the funding, I will not attend that symposium.

My personal opinion is that the FDA (i.e. the department I was speaking to) should first get things straight: start hiring people that can install databases, populate the latter with SDTM tables, and create views on them based on the requirements and requests of the reviewers, and make these available to them.
It is all a question of priorities: do I hire an extra reviewer or do I invest in IT (hardware, software and people)? Personally I am convinced that such investment would pay itself back in less than a year.


This teleconf has, unfortunatey, confirmed my feelings about the current state of IT at the FDA (at least as this department is concerned). It is even worse than I expected.
I was feeling very depressed after this teleconf: more than five years after the introduction of SDTM (and the commitment of the FDA was given), they are still not able to do anything with the datasets than just looking at them.
This is not very encouraging for the so many volunteers that have put so much time and effort in the development of the standards and formats, and makes me doubt whether we should put any more effort in projects such as define.xml 2.0, or in an XML format for SDTM submissions, this as long as the FDA is not able implement these within a reasonable period of time.

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