A Call to CDISC Arms – Recapping My SDTM Posts

Posted on by Wayne Kubick

I’ve been posting a series of thoughts on the CDISC SDTM over the past few weeks, and realize that most people won’t have time to read them all, so thought I’d sum up with these CliffsNotes before moving on to other thoughts for improving clinical research.  So, as former CDISC CTO, here are my essential hindsight thoughts in a nutshell on what should be done with the SDTMIG:

  1. Prioritize stability for the SDTMIG so the world can catch up. In SDTM as a Cookbook I make a plea to aim for more SDTMIG stability by minimizing new versions, suggesting that new domains be presented as recipes to be crafted from the SDTM rather than as fixed domain models in the IG.  I propose a leaner, more flexible approach to applying the SDTM to create new custom domains for data not previously addressed in the current SDTMIG, a suggestion which should be adopted by TAUGs immediately.
  2. Fix supplemental qualifiers now! RIP Time for Supplemental Qualifiers makes another plea to represent non-standard variables (NSVs) in the parent domain where they belong, using Define-xml tags.  Acknowledging past FDA concerns about file size, suggests an alternative of representing these as a separate file that can be easily merged onto the parent as extra columns (much more easily than the vertical method in SUPPXX files today).  This has been a nuisance for far too long – fix it.
  3. Hit the brakes on creating so many new domains. As in the “Cookbook” blog,  The Lumping and Splitting Acid Test makes another plea to be more conservative in creation of new SDTMIG domains, proposing a default “lumping” approach which should only support new domains when there’s no ambiguity about what data to put there.  The more domains we give adopters to choose from, the more likely that they’ll make different decisions – the exact opposite of what a standard should do.  It’s also time to realize that such granular separation of domains probably won’t be the way of the future with patient data in integrated data repositories – see the FDA’s Janus CTR for an example.
  4. Describe use cases for applying the SDTM instead of IG version updates. A Recipe from the SDTM Cookbook gives an example of creating a new domain following the SDTM as a Cookbook approach.   This can be done without creating new IG versions, meaning that people can actually get accurate new information more quickly instead of waiting years for the next IG version.
  5. Time to plan the next generation. Life after the v3.x SDTMIG offers yet another plea to refrain from creating too many new versions of the SDTMIG v3.x series, and begin work instead on a next generation v2 SDTM and, subsequently, v4 SDTMIG that fixes long-standing problems and limitations and is more compatible with interoperability goals and newer technologies.
  6. Clarify the role of CFAST Therapeutic Area User Guides. No blog on this yet, but it’s essential to clarify that CFAST Therapeutic Area User Guides should NOT be considered as separate new standards – they should be viewed as ways to apply current standards. We can provide new examples of how to use a standard whenever a valid new example is created – but we simply can’t allow more confusion to be introduced into an industry still learning how to use our standards by frequently pushing out conflicting information or confusing directions about draft domains or modeling approaches that don’t conform to current standards acceptable to regulators.  My feeling is that TAUGs should focus on describing use cases and recipes to apply the current standards as well as identify new terminology to be applied.  Of course, would be better if we fixed a few things first – notably supplemental qualifiers and probably the disease milestones approach introduced with the Diabetes TAUG.  So maybe a v3.3 SDTMIG is necessary – but let’s draw the 3.x line there.

As we get clearer to the onset date of the binding guidance, we need to think differently if we want to make implementation of data standards the success story it ought to be.  So (maybe after finishing v3.3 soon, I hope) let’s take a breather, let the soup simmer awhile.  Meanwhile, let’s arouse the community to share their implementation challenges and experiences more openly and widely (as some of the User Groups already do, with a special mention to the energetic example set by the CDISC Japan User Group).  Let’s agree we need to gather more common practical experience and knowledge before we jump to develop new disruptive content.

And let’s get going collecting those requirements for the next, great leap forward instead.

That’s the pitch, so let the cards and rotten tomatoes fly.

4 thoughts on “A Call to CDISC Arms – Recapping My SDTM Posts”

  1. Hi Wayne

    Thank you for some great writing. Pleasure to read – out of the six points posted above this one really resonates “let’s take a breather, let the soup simmer awhile.”

    We are getting to fad status with these multiple new versions. Do we change Windows versions as quickly as we get new standards versions. Windows 7 is still going strong and its six years old. What happens if we release a new version in the 3.x series that is flawed or is not widely accepted – hello Windows ME and Windows 8? How will our credibility be damaged when we are so near to regulatory acceptance?

    Versions of standards are not even as easy as the Windows argument – should we not just go with the latest version in the Standards Catalog from the FDA/PMDA? But its not that easy is it?

    I doubt any of us are still running programs from Windows XP on Windows 10? But we need to try and keep all studies in our submission on the same version or should we up version them say move them all from Windows XP to Windows 10 when we submit? In the Pharmaceutical software game we are constantly being asked to maintain versions that are over 2 years old.

    So drug companies don’t like constant change – FDA is several versions behind. Standards development organisations push for more and more versions with functionality that is barely used or nobody really knows how to implement or worse still costs too much to implement.

    Does this sound like Windows Metro UI? Should we not be listening to our customers – the pharmaceutical industry who develop drugs and the FDA, PMDA and EMEA who approve them.

    After all these are the folks who fund and donate time to advance Standards Organisations.

    Must dash here comes another version of CT.

    Regards

    Mark

    Like

  2. Martin Luther nailed his 95 theses on the church door, Moses carved his 10 commandments onto stone plates. Wayne uses more modern methods and reduces his “demands” to only 6. Moses was an authority in his time (so is Wayne in his field), so had not to fear any rotten tomatoes (tomatoes were first introduced in Europe in the 16th century anyway). Also at Luthers time, they did not have tomatoes yet in Wittenberg, but I presume that he had to fear for much more…
    I agree with most of Wayne’s theses. I also think that in not too far future, SDTM domains should have considerably less variables instead of more, and more flexibility (e.g. BRTHDTC OR AGE). SDTM Team: please remove all “derived” variables (–DY, EPOCH, …): these can be calculated “on the fly” by the review tools and be obtained by RESFful web services anyway. FDA: switch to XML now: file size cannot be an issue as such large amounts of data do not belong into files anyway – they should be in databases (see http://cdiscguru.blogspot.com/2015/11/sdtm-moving-away-from-files.html). We should start learning from FHIR keeping it simple and easy to implement, and let “services” do the other work.
    We should also start recognizing that the define.xml is the “sponsor’s truth”. Sponsors now fill pages and pages in the reviewers guide explaining why their (legacy) submission does not pass OpenCDISC (the latter being not open nor representing CDISC), whereas the “truth” is essentially the define.xml contents (RTFDXML).
    Another thing we (as CDISC) should urgently do is to use international standards (like LOINC and UCUM) instead of reinventing the wheel. The variables LBTESTCD, LBTEST, LBCAT, LBSCAT, LBSPEC and LBMETHOD can all be replaced by one variable: LBLOINC. The full description of the test need not to be in the submission, as it can be retrieved by a web service (already available). Values from different sources or submissions for the same test can be compared by UCUM unity conversion services (also already available).
    As Wayne states, we (and first of all the FDA) should all more flexibility: the current SDTM is like a box with Lego and allowing the kids only to build things for which there are printed plans. Anything else is not allowed…

    For those who say that I am only criticizing, please read my blogs “CDISC end-to-end” and “working on and with CDISC standards” (easy to find on the web). Also have a look at the web services that have already been developed by me and others (also easy to find on the web). We (the ODM team) are currently already discussing about how the transport formats (and their contents) can be made more “web services friendly” by taking an example on FHIR (some articles also easily findable…)

    If we modernize our SDTM, throwing about half of the variables away and have the tools and web services do the derivations work, and allow more flexibility in which variables are used, we could end up with 50% less domains and 50% less variables. Wouldn’t that make life much easier, also for the reviewers?

    Like

Leave a comment