Why are Clinical Data Standards Essential for EDC and Non-EDC Data?

During a recent webinar, we surveyed 130 individuals from CROs, pharmas and biotechs about their standardization journey, and this is what we learned:

We asked: Has your organization implemented standards?

• 0% said no
• 60% said partially
• 40% consider themselves to be standards superheroes

We asked: If you have implemented clinical data standards, what system are you using?

• 42% said they manage standards in spreadsheets
• 29% through inhouse clinical metadata repositories (CMDRs)
• 29% in off-the-shelf CMDRs

We can see from these results that in general the industry is aware of clinical data standards, and that research organizations are on the path to standardization in some form or another.

But are study build teams using clinical data standardization to its full potential?

Many organizations have managed their standards ‘manually’ in Word and Excel documents for many years. It works – sort of – so why change it?

Do the following questions sound familiar?

• Who actually owns that master spreadsheet I’m using to spec my case report forms (CRFs)?
• Have I got the latest version of this standard?
• What if I need to make changes?
• Who is responsible for approving these changes?

These are the types of questions you might face if you’re building studies using clinical data standards stored in Word or Excel documents. You may be manually updating content or creating content from scratch for every study. And the study content you produce might not be accessible to all stakeholders.

Compliance with CDISC standards is probably a headache; to keep up with new standards as they are released, you might need to create completely new standards or update existing content.

It’s also a challenge to validate content stored in spreadsheets, and there’s no proper governance. This means it can be difficult to make decisions around the impact of changes to standards.

All these manual processes take time, are prone to error, and can result in:

• Delays in study build and set up
• A lack of consistency across standards and related studies
• Longer SDTM conversion times
• Delays in submission deliverables
• Increased resources
• Increased costs

As we mentioned above, CDISC standards should be your first port of call when implementing standardization. But you also want to make sure you efficiently manage internal or sponsor driven standards.

By that we mean not just forms and datasets, but also:

• Controlled terminology (CT), subset NCI CT, and sponsor driven CT
• Proprietary datasets for data transformations and data transfer specs
• Standardized CRFs with built in annotations and edits checks

With internal and regulatory standards to consider, the idea of implementing and managing clinical data standardization can seem overwhelming. But it’s important to remember that when standardization is in place, the benefits are great.

Ultimately, standardization delivers value. By utilizing standards, you’ll get faster study start up times because less effort is required to set up studies. You’ll see resource efficiencies and better outputs: higher quality metadata leads to higher quality data. You’ll get greater consistency across studies, compliance with data standards, and visibility and control as a result of governance processes.

The problem with managing clinical data standards in spreadsheets is that standardization is not a one-time thing. It requires maintenance. The upkeep of standards in Word or Excel is not easy. By instead using software such as an off-the-shelf clinical metadata repositories (CMDR), this task becomes far easier.

With a CMDR, you’ll get a ‘single source of truth’ for all your study metadata; one resource that makes collaboration between Data Managers, Programmers, and submission teams far easier.

You’ll know where standards are, who owns them, whether they are up to date and approved for use. CDISC compliance and internal standards compliance is made easy with in-built validation rules.

You’ll get better visibility of your data; for example, you’ll see how a CRF would look in a specific EDC before it’s built. This means smoother approvals cycles, and visibility around the history of changes to content.

With the right software, you can get added value features such as the ability to build studies from multiple EDCs using the same core content. You can even standardize your SDTM mappings, meaning automated SDTM conversion.

Find out more about choosing and implementing your CMDR.

The volume and complexity of data collected during clinical trials is increasing. This is especially the case with data coming from non-EDC sources, like biomarkers, labs, genetics, and imaging. The average study uses data from four or more different sources. For therapeutic areas such as oncology, this is more like nine to 12.

It’s very difficult for researchers to keep up with the volume and complexity of this data, and this causes a huge impact on end-of-study timelines. The average cost to get a new drug to market is $2-3bn, so each day a trial is delayed is very costly. There are also negative effects on patients; every day without access to a potentially lifesaving or life-enhancing treatment has a huge impact on patients’ quality of life.

There are so many challenges to managing this massive amount of data, and research organizations need to have systems in place to help ease this process.

For the past decade, there has been a lot of investment focused on CRF data. But what about ingesting and managing this vast amount of non-EDC data?

One of the best things you can do to help ease the burden of this task is to control the metadata for non-EDC data as stringently as you do for EDC data.

The process of transforming non-EDC or ‘third party’ data often looks like this: Capture data > Convert data > Submit data.

This might look easy, but the reality is different. To get non-EDC data into the structures and formats required by regulatory authorities and sponsors is no simple task. It takes a lot of time and involves a lot of grey areas. Even though there are CDASH guidelines available to help you collect novel data types, there’s always going to be room for interpretation between stakeholders. Internal teams and CROs will interpret and manage the standards in different ways.

Standardized metadata is the decoder ring that helps all stakeholders interact, manage and interpret data consistently, and share more easily. So how do you implement metadata standardization for non-EDC data?

Create the Data Transfer Agreement (DTA) and Data Transfer Specification (DTS) upfront – these documents form the contract/agreement between internal teams and external vendors and define the data transfer requirements. It allows teams to translate and understand what is to be collected and how it will be mapped to SDTM, and on to ADaM and TLFs (Tables, Listings and Figures). These agreements should be put in place upfront, before any data is collected, to avoid the hassle of mapping non-standardized data downstream.

Don’t capture more data than is needed – An excess of data means more work to consolidate and interpret what has been collected. Avoid this problem by ensuring that all teams involved in the study (the teams who would be impacted if collected data was incorrect) do a thorough review of the specifications above as soon as the protocol and contracts are finalized. That way you can be sure everyone gets exactly what they need – and no more. Eliminate redundant data collection for more streamlined data processing.

Account for changes during build – Most studies go through post go-live protocol changes which will impact the agreed data specification. It’s important to make sure the requirements in the spec are not so rigid that you can’t manage and govern changing requirements in a way that’s easily understandable for internal and external teams. This means having rules in place around data integrity and transparency, and a method to help teams understand changes. Details of changes and the reason they happened should be documented in the submission package, so this is a key factor to consider.

Ideally, you’ll want to manage these steps in a cloud-based application designed to help with collaboration and automation. That way, you’ll ensure teams aren’t spending unnecessary time navigating specifications, requirements, and document changes, or communicating issues ‘manually’ over Excel, Word, or emails.

Find out how the Pinnacle 21 Clinical Data Management and Automation Suite can help you manage your clinical data standards.