Null flavors in SDTM - a good idea?

CDISC recently published the "revised Trial Summary datasets" for the SDTM standard and implementation guide. One of the new "features" of the TS data set is that it has a number of so-called "null flavors". You can think of a null flavor as something similar like "reason not done" (--REASND), but than enumerated. For the TS dataset the enumerations (each a "flavor of null") are:

• NI (no information)
• INV (invalid)
• OTH (other)
• PINF (positive infinite)
• NINF (negative infinite)
• UNC (unencoded)
• DER (derived)
• UNK (unknown)
• ASKU (asked but unknown)
• NAV (temporarily unavailable)
• NASK (not asked)
• QS (quantity sufficient)
• TRC (trace)
• MSK (masked)
• NA (not applicable)

the explanation being given in brackets.

It is clear that the idea, and its CDISC-SDTM-TS implementation, come from the HL7-v3 world, as the enumerated values (and not by accident I believe) are exactly the same as those in HL7-v3.
The use of "null flavors" is however even within HL7 highly contested. For me, and for many others, it is e.g. very illogical that a value can be null and positive infinite at the same time.
So some implementations of HL7-v3, such as the Austrian "Entlassungsbrief" (similar to the US "Continuity of Care" (CCD) document, have limited the enumeration to the absolute minimum - in this case to only two allowed values.

Personally, I am always suspicious when a list of enumerations has say more than 5-6 values, especially when it is not about "hard" characteristics. You can make an enumeration for "gender", like F (female), M (male) and U (unknown) which is good enough for 99.9% of the cases.
But in the "null flavor" case here, everything is pretty subjective ...
For example, when to apply "NI" and when to apply "UNK"?
And when we know that a value is "<1mg", should we add it as a value, or should we set it to NULL, and fill the "null flavor" with "TRACE"?

And what to think about "positive infinite" and "negative infinite"? These are surely not null!
Wasn't this introduced due to the unability of SAS Transport 5 to use the "∞" character?
In XML (Schema) one can simply define a value of being of type "xs:double" which includes "INF" (positivive infinite) and "-INF" (negative infinite).

Let us have a look why the authors of the new TS-SDTM introduced "null flavors". The argumentation (copied from the document) is:
"The proposal to include a null flavor variable to supplement the TSVAL variable in the Trial Summary dataset arose when it was realized that the Trial Summary model did not have a good way to represent the fact that a protocol placed no upper limit on the age of study subjects.When the trial summary parameter is AGEMAX, then TSVAL should have a value expressed as an ISO8601 time duration (e.g., P43Y for 43 years old or P6M for 6 months old).While it would be possible to allow a value such as NONE or UNBOUNDED to be entered in TSVAL, ..."
OK, but wait a minute ... why should the maximum age be expressed as a ISO-8601 "period". It was never designed for that. And what about a maximum age criterium like "at least 30 years older than the age at which birth was given the last time". The latter could surely be a valid "age" criterium (but it could also be part of an inclusion criterium). So in my opinion, the developers of the SDTM have abused the "duration" data type here.
And for the AGEMAX parameter, shouldn't "unbounded" be "null" (i.e. there is none), or alternatively "∞". But yes, the latter cannot be depicted in SAS Transport 5 ...

What do you think? Is it a good idea to have "null flavors" in SDTM? Or do you think it isn't?
Just let me know ...

Study Design in XML (SDM-XML): what is still missing?

Last year, our CDISC volunteer team published the "Study Design Model im XML", an extension to the ODM standard, filling some functionality gaps (i.e. study design features I was already asking for for years) of the existing ODM standard.
We are now almost a year further, and have had the time to implement the SDM-XML in our tools (such as the ODM Study Designer). We also tested the model against many use cases (even as a possible replacement for submitting study design information to the regulatory authorities).
So it is now time to make an inventory.

We found that the model is already used (or has been prototyped) intensively for searching for possible subjects for studies using patient information such as from EHRs (from the inclusion/exclusion part of the model). We also found that our "workflow" model of SDM-XML can easily be transformed in BPMN-2-XML, which is the generally accepted standard for workflows. This e.g. allows to import a clinical workflow into a hospital information system (HIS) and integrate it with the workflow of the patient care.

There are a few things however that are still failing in our model:
- subactivities: i.e. activities within activities. For example, there can be an activity "place an ambulatory ECG device", which itself consists of a number of subactivities. In ODM/SDM-XML this is not supported (yet). This also has to do with the lack of support for subworkflows.
- subworkflows: i.e. workflows within workflows. Building on the previous example, the activity "place an ambulatory ECG device" will consist of a number of subactivities which need to be executed in a certain order, and maybe with some forking or branches, so needing a subworkflow.
- swimlanes. Those knowing a bit about workflows do also know the concept of "swimlanes". For those who don't, I could try to explain, but wikipedia does a much better job  here.

In order to implement swimlanes, we do however need "roles", such as "primary investigator", "study nurse" or "monitor". We don't have this in ODM, we only have the concept of "user" (which is in priciple a person) with a "UserType" attribute. The latter could be used for "role", but this could better be avoided as its current enumerated list is just too limited and not adequate.

So we would need to extend the ODM further than we already did.
At the same time, we have the problem that "StudyEvent" (for a visit) is not a good concept anymore. In SDM-XML, a visit is essentially a container for a number of activities, which can be datacollection activities or activities in which no data is captured (such as placing the ambulatory ECG device). If we allow activities to have subactivities (and subworkflows) isn't a StudyEvent nothing more than an Activity?
Also (in my opinion) we should introduce an element "Role" in the "AdminData section" of the ODM, and allow to assign roles to "Users" (P.S. A person can have one or more roles).
This could then allow us to introduce the concept of "swimlanes" in the workflow part of ODM/SDM-XML.

I do already have a list of other wishes I have for ODM.
If we find the necessary (human) resources, wouldn't it be time to start thinking about a future ODM Version 1.4?

Let me know what you think!

Define.xml - an extension or a subset of ODM?

In my second-last post, I wrote about the discussion within the define.xml team (that is currently working on define.xml v.2) whether ODM elements not explicitely mentioned in the define.xml specification should be allowed or not. The majority of the team finds that it should not (i.e. they should be forbidden). The people that work on end-to-end insist that they should be allowed.
A typical example is "MeasurementUnitRef" and "MeasurementUnitDef".

As define.xml has been developed as a "vendor extension" to the ODM, I looked into the ODM specification about what it says about vendor extensions.

Section 2.4 of the ODM specification (1.3.1) which is about vendor extensions states:

• The extension may add new XML elements and attributes, but may not render any standard ODM elements or attributes obsolete
• Removing all vendor extensions from an extended ODM file must result in a meaningful and accurate standard ODM file

and last but not least:

• Applications that use extended ODM files must also accept standard ODM files

The latter means for me that if I do have a define.xml file containing "MeasurementUnitRef" elements and "MeasurementUnitDef" elements, an application that reads such files would not be allow to reject these elements (or mark them as error, warning or "not part of the standard". They should just accept them.
Whether they then do something with the information is another case.

So for me it is clear that the define.xml team is not allowed to forbid the use of ODM elements that are not explicitely mentioned in the define.xml spec, nor state that such elements "are not part of the standard".

If they do so, they break the rules of the ODM standard on which they base their extension.

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 ...

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 http://cdisc-end-to-end.blogspot.com.

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

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 ...

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.