If this is not already underway, I think it is time that we examined how we can do a better job of combining SDTM data submissions with ODM data and metadata. The following commentary is hopefully going to raise some comments, and, ideas as to next steps.
The Challenge
CDISC SDTM – the standard for the Submission of Clinical Data for New Drug Applications - is challenging to work with for a number of reasons. Data is structured per Domain, rather than per CRF – quite rightly in my view – however, this re-modeling does create a number of issues that deserve to be addressed.
First of all – getting the data into this format in the first place. In a typical EDC system, you have data captured across many pages. Often these pages contain 1 or more domains for data. Data is presented in nice friendly CRF Page like formats, with quick links to audit trails, queries, comments etc. In the SDTM world, things are not quiet as friendly. You have long lists of records structured by domain. You cannot see the audit trail. You struggle to relate the comments. The queries may not even exist.
Now – ok – maybe the audit trail and query log should be of no significant relevance to the Medical Reviewers… It is supposedly more evidence of the data cleaning process having taken place. Maybe that is just a carry over from working with paper CRF’s for decades. However,I would argue that data is never 100% clean. It is sufficiently clean to merit safe statistical analysis. Reviewers may feel that in a position of doubt, that they would like to see context behind the data being recorded, and therefore see the query and audit logs.
So – after that short ramble – how could we make the life for Reviewers better?
Combining ODM with SDTM
Well, first of all, why not leverage the standards we already have for clinical data – ODM and SDTM – but combine them in a more effective way to offer SDTM directly linked to ODM?
What I mean by this – and I am sure XML4Pharma will point out that this has been suggested previously – is that we extend the ODM specification to accommodate SDTM Domains within the ODM spec, AND that we provide the means to link the SDTM domain content with the associated eCRF data & metadata in the present ODM.
To the end user – this would result in a mechanism to switch between a tabular SDTM view of data to an eCRF view of data, with ready access to the audit trail and queries, as well as potentially a better context of the data in the way it was captured.
Easy to achieve?
Sponsors struggle to create SDTM today. However, I am not certain that this is due to underlying faults in SDTM itself. I think the tools will mature, the standards will mature, and sponsor companies will simply get better at it.
Creating related ODM is also not too difficult. Any EDC vendor for instance that wish to be credible in the marketplace need to be able to offer data and metadata in the CDISC ODM format.
Programmatically linking the SDTM and ODM is probably the hardest part.
In theory, you could have a situation where every field that exists on a SDTM records belongs to a separate ODM page instance. The problem can be solved, but, it is not going to be easy.
Conclusion
Delivering SDTM data in a ODM style format, and creating a means to link the SDTM/ODM to the present ODM data and metadata will create data that is considerably more useful for both analysis, submission and archiving.
1 comment:
You mentioned me (XML4Pharma), so here I am!
The CDISC ODM/define.xml team was already working on such an extension three years ago, but was stopped by the decision of the FDA that SAS Transport (the current transport format for SDTM datasets) would be replaced by HL7-XML, and not by an ODM-extension! At that time, at least 3 vendors had already an intermediate format that is an ODM-extension to exactly carry SDTM data (only in the last step, their XML is "downgraded" into SAS Transport), so it would only be a matter of aligning these 3 “dialects”, and add some additional extension elements/attributes in cooperation with the FDA.
So at that time, the FDA “killed” our project.
The recent decision of the FDA to "put the HL7-XML on ice" (see http://www.cdisc.org/fda-cber-cder) and the recent comment that "We may need to go back to the ODM piloting that we were doing" (see http://www.cdisc.org/fda-town-hall) gives us a window of opportunity to take this work up again and try to convince both CDISC and the FDA that an ODM extension for carrying SDTM data is the right way to go.
This would also perfectly fit with define.xml, which is the ODM-extension for carrying the metadata of the submission.
It would also allow us to define the SDTM rules in a machine-readable format (e.g. using Schematron).
As you say, the step going from operational clinical data (e.g. as ODM) to SDTM is not an easy step. This is however only partially due to the technology (SAS Transport is 30 years old and makes things unnecessary difficult), but mostly due to the fact that going to SDTM is an interpretation and categorization step. Tools like SDTM-ETL(R) help a lot, but one still needs to understand the clinical data as well as have (a lot of) experience with SDTM.
Your suggestion to allow a “linking” in the SDTM-ODM to the original ODM data is a very good one (which we will pick up), but this presumes that the FDA reviewers have tools to inspect ODM files including the audit trails, which they currently do not have at all.
I am thinking about submitting an abstract for the automn CDISC Interchange in Washington, so that I can give a presentation on this topic, with the goal that we can (re)start the discussion within CDISC and with the FDA.
It's only so unfortunate that we lost three years due to some stupid (political?) decisions within the FDA.
Post a Comment