<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=905310923417895&amp;ev=PageView&amp;noscript=1">

FDA Study Data Exchange Standards

Aug 16, 2013 12:00:00 AM




Find me on

Why adopt CDISC? Solutions for study data exchange standards in clinical trials.

The Food and Drug Administration (FDA) recently announced a meeting, “Regulatory New Drug Review: Solutions for Study Data Exchange Standards” the purpose of which was to solicit input from industry, technology vendors, and other members of the public regarding the advantages and disadvantages of current and emerging open, consensus-based standards for the exchange of regulated study data. FDA also sought input from stakeholders and other members of the public on this topic and a set of pre-meeting questions were issued for stakeholders to respond to.

The Formedix team, experts in Clinical Data Interchange Standards Consortium (CDISC) since its inception in 2000, responded in support of CDISC as the chosen Study Data Exchange Standard.

Read on in this Technical Expert opinion piece, outlining the case for CDISC as the chosen study data exchange standard…




What are the most pressing challenges the industry faces for study data management?

Increasingly, as more and more studies are outsourced to contract research organizations (CROs), pharmaceutical companies face the challenge of producing very detailed specifications that address how data will be captured and how data will be submitted.

Traditionally, these study specifications have been developed using Microsoft Excel which is time-consuming and laborious to produce, as well as making content standards unmanageable and re-use impractical. CDISC Operational Data Model (ODM) and Define.xml, coupled with content standards in the form of Clinical Data Acquisition Standards Harmonization (CDASH) and Study Data Tabulation Model (SDTM), have been proven to reduce study set-up and specification by up to 68%. CDISC XML allows role-centric specifications (CRFs for clinicians, tabular database specifications for data managers, tabular dataset specifications for biostatisticians, etc.) to be produced in any format (proprietary metadata for Electronic Data Capture (EDC) solutions, PDF, Excel, Word, etc.), automatically, with the appropriate clinical trial automation technologies.




Why does the industry need to make clinical trials' data management more effective?

Industry requirements could be achieved to an even greater extent with a standardized XML representation of datasets based on CDISC Define.xml as well as a standard mapping language that describes how CDISC ODM and Define.xml are mapped together. Much of this work is beyond what volunteers can achieve and CDISC requires further funding to support a full-time staff for the maintenance, improvement, development, and documentation of the core CDISC ODM, SDTM, ADaM, and Define.xml models and content standards.

The ability to transform CDISC ODM into multiple proprietary EDC metadata formats, coupled with the widespread adoption of CDISC ODM metadata by major EDC vendors, has led to the automation of the EDC build/test processes with proven time reductions of over 55%.

In the data capture arena, significant opportunities exist to use CDISC ODM as the data transport of choice between EDC, Interactive Voice Response System (IVRS) and Electronic Patient-Reported Outcomes (ePRO) solutions. Again, many of these vendors support CDISC ODM today.

The standardized hierarchal ODM structure makes it easy to automate transformations to CDISC SDTM datasets, which has been difficult to achieve with dataset to dataset transformations in the past. CDISC metadata greatly assists here by allowing content standardized metadata repositories to be set-up with acquisition metadata (using CDISC ODM) and dataset metadata (using CDISC Define.xml for SDTM and Analysis Data Model (ADaM). Examples of how these metadata repositories are being used in real studies today in large pharmaceutical companies can be found at
http://lillyodmlibrary.codeplex.com/. Both acquisition and submission metadata can be linked, not only to generate the code required to do these transformations but also to provide traceability from acquisition to submission.

Today, large clinical data repositories exist which have been built on the core CDISC ODM model allowing aggregation of multiple studies from multiple sources in one industry-standard format and enabling global safety re-coding and global reporting, regardless of study or phase or data capture technology deployed. In addition, archives of entire studies or single sites can be produced quickly and efficiently in the vendor-neutral and platform-independent CDISC ODM format.

Regulatory submission documentation such as submission-ready Case Report Forms (CRFs) (data populated CRFs with full audit trails) can be automatically produced from a data populated ODM (regardless of proprietary EDC system or platform (EDC, ePRO, IVRS or Lab) deployed) and human-readable Define.pdf from a CDISC Define.xml.

No-one likes change. To change the CDISC XML, which everyone is now used to, will cause confusion and impede adoption.

Industry and the FDA want to achieve more standards adoption to facilitate greater scalability, quality, and traceability across the end-to-end clinical trial process. All the opportunities and solutions highlighted above exist today with CDISC, and vendors have shown their willingness, not only to adopt them but bring new and innovative solutions to the market.

In our opinion, changing the fundamental infrastructure on which many of these tools are built will not only deter the adoption of new transport formats but slow down the important work that has already been undertaken.




How could FDA's regulatory requirements makes the study data management process more efficient?

Presently, CDISC Define.xml is seen as a regulatory document that should be produced and submitted at the end of a clinical trial. However, using this standard upfront has a significant impact on how data will be acquired and transformed to produce datasets for submission. Early input by FDA reviewers on CRFs and the corresponding dataset definitions (Define.xml) before a study has commenced will ensure that SDTM datasets are produced in a more uniform manner, without ambiguity.

Furthermore, the present requirements for SAS XPT files for datasets are enforcing various limitations on how data can be represented, as well as making it unnecessarily difficult to write applications to process datasets. Moving to a format that is easier to work with, defined by a standards organization, would simplify the process of working with data and remove unnecessary restrictions on the format of the data (e.g. 200 character length restrictions on variables).




What data standards are you currently using for the conduct of regulated research studies?

Formedix heavily utilizes CDISC standards in all areas of the end-to-end clinical trial, from upfront data collection using ODM and CDASH, through to submission of data using SDTM, ADaM and Define.xml (CRT-DDS).




Would Health Level Seven v3 be a viable study data exchange standard?

At Formedix, we strongly believe that a move to HL7 standards for study data exchange would be wrong for our Industry. End-to-end process improvements already seen with CDISC would require re-engineering, with many waiting on the sidelines to see what was to be regulated and what was not.

Furthermore, there is a low level of familiarity with HL7 standards in our industry, partly due to their complexity and partly due to their abstract nature. It would take a comparatively long time to develop suitable standards based on HL7, and require a high level of expertise to do so. The burden of implementing such standards would also be great, with a large amount of technical expertise required. We believe this would cost our Industry a substantial and unnecessary amount of money, and severely delay the final implementation of a data exchange standard.

Our Industry struggled to adopt XML as a format initially, and today there are very few tools for working with HL7. In the current economic environment, we would be asking many players within our Industry to re-tool around HL7. At the same time, we are still waiting for definitive legislation around the need to implement the core CDISC standards.

In our minds CDISC ODM (as opposed to CDISC SDTM) has never been seen as the format the FDA will favor for submissions, however, EDC vendors, major pharmaceutical companies, and CROs have all adopted it as they have seen huge time, cost, and quality savings by implementing this standard.

We are asking adopters to turn their back on these benefits as well as move to a completely different set of standards which are unsupported within any eClinical software tools currently available. Eventually, when software is available it will be more expensive to implement and likely harder to use.




Would CDISC Operational Data Model be a viable study data exchange standard?

We strongly believe that a CDISC ODM-based standard for study data exchange would be a huge leap forward. It would remove the current limitations imposed by the use of SAS XPT files by providing a much richer data type system and also making it possible to greatly improve the submission of SDTM-based data (e.g. by removing the need to separate Supplemental Qualifier data into separate datasets.)

CDISC ODM is already accepted and implemented widely by our Industry for transmitting operational data and metadata and submission metadata. Expertise has been demonstrated by transmitting data in ODM formats between different EDC and ePRO vendors during live trials and certification processes undertaken by CDISC to ensure compliance with the core standard. CDISC ODM was developed specifically for, and by, our Industry and, as such, has been proven to be well suited to our needs.

With this level of understanding and available expertise, it would be a relatively easy task to develop an ODM-based mechanism to replace SAS XPT files and, in fact, there are already several companies using such a format internally, Formedix included. Producing a standardized XML based dataset standard will be fairly trivial considering all the work that has already been undertaken to date. Many EDC systems today support the export of operational metadata in ODM format, so for them to also provide dataset exports in a similar ODM-based format would not be a technical challenge.

The metadata for submissions is already described using the ODM-based CRT-DDS (Define.xml) model and therefore the use of a similar model to represent data would mean the data and metadata were aligned.

Formedix believes an ODM-based data exchange standard would be the fastest, most practical, simplest and easiest to understand the way to free our Industry from the limitations of SAS XPT files while providing capabilities for enhanced functionality and applications as required.




What would be a reasonable phased implementation period for each recommended exchange standard?

Formedix believes that a CDISC ODM-based data exchange standard could be reviewed and publicly released in 8-12 months, and probably less if the requirement is simply to “replace SAS XPT”. Minimal re-tooling would be required for implementation and the initial model could be incrementally improved over time with relative ease.

By contrast, Formedix expects an HL7-based data exchange standard to take in the region of 18-30 months and to be complex and cumbersome both to develop and for companies to implement, requiring significant HL7 expertise that simply does not exist at the present time.

Furthermore, we do not believe that multiple concurrent competing data exchange standards would be a good idea as it would fragment Industry adoption rather than providing one target that everyone standardizes around.




What are the challenges and opportunities for sponsors designing study data collection systems?

In order to ensure that relationships between data elements and relationships across data domains can be captured at the point of data entry, an open standardized machine-executable mapping standard would allow mappings to be executed in a number of extract, transform, and load tools, whilst providing traceability between CRFs and SDTM datasets and ADaM and SDTM datasets.




About Formedix

Formedix clinical trial automation software and services enable you to remove manual, expensive, inefficient, and labor-intensive tasks from study set-up, EDC build, validation, and submission publication processes.

In fact, across every area of your end-to-end clinical trial, the time and cost savings they deliver speak for themselves and continue to do so time and time again…

Formedix software has been proven to reduce study set-up time by 68% and cut EDC build time by over 55%. Deploying our study design (metadata) repositories allows 70% reuse of your design content across the end-to-end clinical trial, reducing management resources by 23% at the same time.

It’s all in the numbers.

Design & Specify. Execute & Deploy. Utilize & Verify. Publish. With Formedix.

Similar blogs you might like...