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.

A new challenge

I have recently obtained a professorship in "Medical Informatics and Documentation" at the eHealth department of the "University of Applied Sciences FH Joanneum" in Graz, Austria.
This will enable me to continue my work on the development of CDISC standards (and even being paid for it), but also to do exciting projects in the area of e-healthcare and its integration with clinical research.
My company XML4Pharma will also further exist in the future, but will concentrate more on software development (for CDISC implementation) and less on consultancy and training.

At the university, I am teaching "databases" and "medical informatics", the latter concentrating especially on hospital information systems, their architecture, standards in healthcare (HL7, DICOM, semantic standards like SNOMED, ICD-10, LOINC...).

Austria is currently, slowly but steadily, rolling out a nationwide system for electronic health records (ELGA) and I hope to also contribute to that. For example, I am currently discussing a project with 3 Master students in which they will develop an XForms implementation of the Austrian "elektronische Arztbrief", a letter that is send from one physician to another physician when the latter takes over the care of the patient. When submitted to the server, the form will then be converted into HL7-CDA format.

But I also will work on the further development of the CDISC standards. One of the teams I am in recently published the "Study Design Model in XML" (SDM-XML), an extension to the ODM standard. But that does not finish the work: we need to develop an implementation guide, and provide samples. We need to demonstrate the usefulness of the standard and convince the vendors to implement it in their tools.
I did already take some steps in that direction: the "ODM Designer" now implements SDM-XML, and I also demonstrated (also see previous posts) that an SDM-XML study design can easily be transformed in a "caBIG Patient Study Calendar" (PSC), and its workflow and timings part into a BMPN-2 workflow XML document, that can easily be read into a hospital information system.
That brings us back to the topic of integration between healthcare and clinical research, which is also taken care of by a number of IHE-profiles. So also there, I will be contributing, as I already did in the past (RDF and RPE profiles).

Of course there are already thoughts about the further development of the ODM standard (version 1.4). If you have some things that you think should be added to the "user requirements", please let us know, and we I will add them.

What I will probably discontinue, are my contributions to the further development of CDISC submission standards, such as define.xml and the "MetaData Submission Guide". Reason is that as a professor, I need to do innovative work. My strong impression (confirmed yesterday in a teleconference with people of the FDA - but that's another post) is that, even more than five years after SDTM and define.xml were first introduced (because the FDA wanted to standardize), the FDA is still not able to work with SDTM nor define.xml - the review environment is still completely absent.
So as long as the FDA is not modernizing their IT (to my opinion they are 20 years behind with respect to industry), it may be a waste of time spending time on the further development of formats for submission standards. On the other hand, proving that e.g. an XML format for SDTM submissions (NOT based on HL7-v3) is a giant step forward (which would also enable the FDA to come to a great review environment without high costs - especially statistical software licenses), might boost the modernization of IT at the agency.

But that's another story...