A Programmer's View on IDMCs


An IDMC (sometimes known as a DMC/DMEC/DSMB) is an Independent Data Monitoring Committee, whose role it is to monitor the conduct of a clinical trial, to ensure the safety of its participants and the scientific integrity of the study. By periodically reviewing the accumulating safety, and sometimes efficacy data, the IDMC will make recommendations on the continuation and management of the study.

The IDMC is an independent committee with a Chair, made up of two or more disease-specific experts and at least one statistician. They are usually governed by an IDMC charter, which outlines their role and responsibilities, the study data to be reviewed, any stop-go criteria, and IDMC quorum and voting rights.

The Role of the Blinded Statistician

Within PHASTAR, we’re often tasked with producing the blinded IDMC outputs for clients, which will then be sent to a third-party vendor who will be responsible for unblinding the outputs ready for the IDMC’s review. As the blinded statistician working on an IDMC deliverable, we’re responsible for creating the mock shells, and producing the blinded outputs, as per the study Statistical Analysis Plan (SAP) and IDMC charter. We may come across data issues that need resolving, or have questions about the presentation of the data, all of which we’ll work to resolve with the client, to ensure the IDMC review is based on reliable and optimally presented data. We’re also often used to working within strict timeframes, to ensure the IDMC review can take place at the agreed milestones  and be based on as up to date data as possible.

Writing Portable Code

The challenge of writing study reporting programs to be run by a third party is that you don’t have overall visibility of what their environment will look like. The programs all need to work together – an SDTM program might create a dataset which is read in by an ADaM program, while both programs might call utility macros – so if they cannot locate each other, then the whole system quickly falls apart. 

PHASTAR’s solution to looking after every ‘moving part’ of these reporting programs is to house everything in a standard folder structure, meaning that every file remains in a fixed location relative to each other. Now when the structure is copied to a new area, the location of any individual file can easily be found.

For example, say our reporting area for study ABC1234 lives in a folder called ABC1234 on our server’s C: drive, and the SDTMs are stored in the folder C:\ABC1234\Data\SDTM. We are delivering the folder to a third party called TPV who will run the programs on unblinded data in their server’s D: drive. A SAS statement like

libname sdtm "C:\ABC1234\Data\SDTM";

would work correctly for our internal programming, but once the folder has been copied to TPV, the location would be incorrect and therefore the programs won’t run. Manually changing all file references across the programs would be time-consuming and can lead to errors.

Rather than using a fixed filepath, we can use relative filepaths which describe the location of files relative to the location of the top-level folder. We can do this by creating a SAS macro variable in the study’s autoexec program (the code that runs before each study program to configure study-level settings):

%let root = C:;

and instead of referring to the C: drive directly in our programs, we use the macro variable reference:

libname sdtm "&root\ABC1234\Data\SDTM";

When SAS runs a program and encounters the & symbol, it treats the subsequent word as a macro variable and replaces &root with the stored value of this variable, which we have set to be C:. Now the folder location only appears once in one program, and TPV just need to change one line of code to adjust every filepath: 

%let root = D:;

Other considerations

PHASTAR always aims to write high-quality programs that will work first time when run by a third party, but sometimes some support is required to figure out where the issues are coming from. We always test IDMC deliveries before delivery by running them in a separate area to simulate a third-party server, but differences in the OS and version of SAS used can sometimes cause issues which are hard to test for.

For this reason, it is crucial to communicate well with the third-party programmers as they run the programs, so any problems can be fixed quickly. With this partnership in place, PHASTAR has managed to successfully deliver IDMCs on several studies.