Although I don’t expect Pharma companies to twitter around their clinical study information, there are better ways to disseminate information and to collaborate across Oceans and continents then using Fedex and organizing Investigator meetings. Most of the Clinical Trial Portals (CTPs), or Clinical Investigator Portals, used sofar are mere post-offices where you can collect your mail. That’s it.

But nowadays, using web 2.0 technologies, a Study Portal could do so much more and benefit all participants, Sponsors, Site personnel and Study subjects alike.

Imagine a Sponsor who could use a Clinical Trial Webportal to Post Protocol updates, the Portal would notify all Investigators, and would track who has opened the Protocol update. In a Study with 100 sites, this single action would allow a protocol update to be available within seconds and save $ 6,341.

Imagine an Investigator who would only need to logon once and have access to all information of a Study (or any other Study of that same Sponsor). Who would be able to share information with his Sponsor’s contact, colleague Investigator or perhaps his group of Study Subjects. Or have access to Training documentation or videos. Or who would be able to search a Forum to see how his collaegues in this study have handled a certain situation and discuss problems, experiences and ideas.

Imagine a Medical Device study where Patients would be able to learn from the experience of other patients in the study. Or where the Sponsor could benefit by learning from the actual experience of their patients using their device. Or where patients might get a text message as a reminder not to forget something.

If you are intrigued by how these new technologies can enhance your Clinical Study workflow and facilitate collaboration among all parties involved in a study, then don’t hesitate to contact Thorin or have a look at www.study-portal.com.

A major reason for this is that Adobe Indesign allows for Layers. Most DataFax users are using Masterpages, one for each Plate or Unique Page. So everything which changes over Visits needs to go on the Bodypage. And if you have a Vital Signs page where Height is only collected on the first visit, you need to create two Masterpages, one for the first visit (including Height) and another for all the other visits without Height. Not so much trouble until one of your reviewers request to update a Vital Signs item, then your CRF designer needs to figure out which Masterpages might be effected. If you have a single Layer containing the Vital Signs items, you update the Layer and that’s it. So from a QA point of view, there is a lot to say for using Layers.

In Adobe Indesign, this can all be done a lot easier by using Layers. So for the Vital Signs example. You just create one Vital Signs Masterpage. It has a Layer containing all the regular Vital Signs stuff. And for the first Visit, you just add another Layer with the Height. And along these same lines, using Indesign, you can more efficiently create even a basic Masterpage. In Framemaker, a Masterpage contains everything, in Indesign, your Masterpage might consist of several layers. Like a layer holding the Company logo, Study name, Study Barcode, etc. And another layer with the actual items. And the Items Layer, might even be two separate layers, one with the text of the individual questions and one with the boxes.

Same method can be used on the actual pages. While a Bodypage in Framemaker contains everything which cannot go on the Masterpage, in a properly designed Indesign CRF page, the page might contain multiple Layers. You could create separate Layers for each Visit, containing things like the Visit barcode, the Visit name, etc. So rather then copying/pasting this information from one page to another, you just turn on the proper layer.

So if you have a standard library of CRF pages, which are used for both paper and EDC, it will be a lot easier to adjust a new CRF for the data collection method. Purely EDC? Just turn off the layers containing the barcodes and the actual boxes. So unless all of your studies are 100% EDC, I think Indesign can help you in adjusting your CRF to have the proper content for the data collection method selected in a study.
You can find more information on our website regarding our CRF Design Training courses.

For a Sponsor this also opens up possiblities for branding or marketing. Any investigator using the RVD will see a completely personalized Desktop. Like his usual Windows desktop, but then completely dedicated for a given Study or Clinical trial. If you want your logo on the Desktop, no problem. If you want a product database on the Virtual Desktop, no problem. And again, it is as safe as if it was in your own LAN.

Similar to allowing iDataFax access without having to install the client software, you could also install things like a Citrix client. Whenever the user logs in, they can start the Citrix client from the RVD, and the Remote Virtual Desktop server (RVD-server) will make the connection to your Citrix server. So the RVD-server will never hold any clinical data. It only has one or more predefined Virtual Desktops and whenever a user wants to login, the VD-server will take a Virtual Desktop from its pool. And whenever the user logs out, the Virtual Desktop will simply be trashed.

And if you include a webserver on the RVD-server, you will be able to have things like a user adjusted Study Portal. So if a local Monitor, whether he/she uses the RVD from within your office or from a PC at the clinical site, he/she will get the same information through the Study Portal. And the information in the Study Portal is completely secured: the information is send over a safe connection and is geared towards that person. And in fact, different to most other secured information on a webserver, this webserver is not ‘on the internet’. Without Virtual Desktop, it doesn’t exists.

So an essential question at the start of a new EDC based DataFax Study is: “Is there any chance that (part of) the data collection will be paper based? And/or do we need to allow some sites to ‘fall back’ on paper collection of study information ?

If the Answer is no, then there is no reason to include barcodes on your eCRF (which will be used to create the Data Entry screens). They are only a rememberance to a ‘paper-based past’, serve no purpose and use valuable space on each Form.

And another issue to take into account is the impact boxes and related information might have on the Data Entry screens. Have a look at the field CRF No, in a paper based study, this was a pre-printed number. So you would need a square box around the pre-printed number. This box is partly visible on the Data Entry screen, nothing to do about that in a paper based. But in an EDC study, the box serves no purpose and can easily be deleted.

The same holds for the “Day   Month    Year”, they originate from additional text below the boxes for DD/MMM/YYYY. The boxes itself have been deleted, a new (much shorter) has replaced the original boxes, but the text is still there. Confusing as it is in the wrong location. Again, in an EDC study, there is no need to even have boxes on your eCRF.

For reasons like these, we (Thorin) have always created a separate PDF file to be used for the creation of the background images.

But what if you want to combine ‘paper sites’ with ‘EDC sites’, or collect some information by paper Forms and other information by EDC ? That’s something to be discussed in a next Blog, so stay tuned….Or click on CRF Design using Adobe Indesign, which will take you to the next Post.

The basic difference being that in a paper based study, all Edit Checks will (usually) be triggered within the walls of the Data Management center. So, ideally they are being handled by experienced and trained people. And even if they have a problem, there is always a collaegue around the corner who can help. So as long the Queries which are raised as a result of Edit Checks are clear, you are fine. And perhaps just as important, Edit Checks are being handled by people who’s sole task it is to handle study data (in whatever format or role)

Which is a different story than in an Electronic Data Capture study where Edit Checks are being triggered at sometimes far and remote sites, and handled by people with different levels of computer and study knowledge, and with no help around the corner. And compared to the example above, site personnel often have other things to do than do handle clinical study data. Unless of course, this is handled by a dedicated study nurse.

So a first question you need to ask yourself is: “Do we want to fire all Edit Checks directly at Data Entry at the site?”. Phrased this way, the answer is probably ‘No’. So then the next question is, when and where and by whom do we want to trigger which Edit Check ?

• The question regarding when needs to be answered in terms of things like Field exit or Plate Exit and also in terms of at which validation level.
• The where question relates to the specific item or plate at which to attach the Edit Check.
• Whom relates to the person, or more specifically the user role which should/should not trigger a query

Where questions like these might be more trivial in a paper Form based study, they gain a lot of importance in an EDC study. I have explained in an earlier blog that we use a phased approach at Thorin towards Querying illegal data values. So we have separate Edit Checks to query for a missing value, an illegal value or an inconsistency between two different variables. This distinction is also very helpful in deciding which Edit Check to trigger and when.

There can hardly be any argument that, in an EDC study, the best moment to trigger an Edit Check regarding a missing value or a variable being illegal is when the person doing the first data Entry is leaving the field. So we are talking a Field_Exit Edit Check, linked to that variable, which is triggered from first level Data Entry onwards. In a paper form study, people doing first level data entry are probably not that happy with Edit Checks popping up every time an item is missing or illegal. So if you have a hybrid study, combining paper Forms with EDC, you will need to build in something into your Edit Checks, which takes the role into account. Luckily, there is function available in the Edit Check programming language to help you with this. So you probably want to include something like:

if ( dfrole() !="SITE"  && dflevel() <= 2 ) return;

This example of a missing or illegal item is one end of the spectrum, then there is the other of the line, which are Edit Checks involving multiple items from multiple Plates. Let’s take an example of a check that “Date of Signature on End of Study Form should be within 7 days of the last available visit.”. First of all, you need to post yourself the question whether you want to pose this question directly during first level Data Entry. Chances are slim that the investigator will be able to solve this right away (unless it is a clear typo). So either you add Queries like these later on the workflow, or at least you should include Wayne’s idea of including a line like: “there is a problem, do you want to fix it now or later ?”.

And then another thing you need to consider is the timing of Events. In the above example, it will be clear that the Edit Check only makes sense when it is triggered from the End of Study page. But how confident are you about the order in which the site will perform Data Entry. Can it be that they first enter data from End of Study, and then later on they supply data for earlier visits. If scenario’s like this don’t sound like nonsense, you have to seriously consider if you want to have to have an Edit Checks triggered on EOS from level 1 onwards. As it might trigger a non-relevant Query.

And let’s take another example, a simple within-a-plate Edit Check verifying that Date of Vital Signs should be the same as Date of Visit (both are on the same plate). It goes without saying, that this Edit Check should be triggered from Field Exit of the last Field involved, which is Date of Vital Signs. But do you leave the cursor at Date of Vital Signs or do you want the cursor to jump back, by using dfmoveto() to the first Field involved (Date of Visit) ? Personally I feel that jumping back to the first Field involved makes the most sense. Main thing is that you have consequent behavior, whatever you do, do it everywhere.

As a last word of advice, put as much of functionality like this into functions (or #include statements). The major advantage of such an approach is that whenever you want to update your policy in any of the above issues, you only need to update the function itself and not 100+ different Edit Checks.

Most of the ‘other’ clinical trial database management systems do not know where each variable is located on a CRF page. Luckily with DataFax, it is a different story, in order for the OCR to work, DataFax needs to know exaclty where each item is located. In fact, if you have an item spanning several groups of boxes, DataFax even knows the location of each individual box. And as the developers of DataFax have been kind enough to store all relevant information in readable files, it is possible to retrieve information on both Variable names and their position, and to automate the process of creating an Annotated CRF. I know that there are several DataFax clients who have been doing this.

Once the process has moved from manual to a kind of automatic (you still need to push a couple of buttons), the Annotated CRF can serve the whole process, rather than being a kind of boring nuisance. That is, now that the Annotated CRF is created automatically, you can assume that it is error-free, so others, like Biometrics, can rely on it. Also, as the process is automated, it is relatively easy to include things you hardly ever see in a manual created Annotated CRF, like including meta information. Things like different colour coding for Required/Optional Fields. Or including the DataFax Field number. Which makes the Annotated CRF extremely helpful when creating a SAS export (where you will refer to a Field being exported by its Field number).

And when this Annotad CRF is combined with information from the Visit map, different Bookmarks can be created to allow different indexes to the CRF pages. So a Study manager can easily open a Bookmark for say Visit 2 and see which CRF pages are part of that Visit. Or a Statistician can open the Bookmark for a Lab page, and see from which Visits this information is being collected.

And one step further is to combine it with other sorts of information, like your export to SAS datasets or to CDISC/SDTM Domains. At Thorin, we are using an application which allows us to ‘map’ DataFax Plates & Variables to SAS Datasets/Fields. Based on this ‘mapping’, it is possible to create a SDTM Annotated CRF, where the DataFax Field names are replaced by the SDTM Fieldnames, preceded by the SDTM Domain name.

So with this level of detail, the Annotated has moved from a boring Necessity to a powerful tool to open meta-information from a study to a larger group of people. And in my experience, not only to access the meta-information, but also to review it. And thus becoming part of the QA process.

It’s all too easy to say, “OK, there is a problem, let’s fire a Query.”. But do you know, or I should say, does your Edit Check know, that a given Field has already an open Query for a similar problem? Or perhaps an open Query for a completely unrelated issues, which might in itself lead to the Field being updated, and perhaps making this new Query Obsolete ? Like when a Date Field with an illegal value, which will trigger a Query for the Field being illegal. But the illegal value might in itself trigger another Query as the Field, say Date of Informed Consent, might now fall after Date of First Visit. So either you sent out the two Queries at once (#1 for illegal Date of IC and #2 for Date of IC falling after First Visit), or you wait until #1 is resolved, until you decide if #2 still makes sense (or has been resolved by now). A feature we call “Phased Triggering”.

And to make it even more complex, if you have an Edit Check involving two ore more Fields (perhaps on a different page), do you, better again, does your Edit Check, take into account that the Field on the other CRF page might get updated because of an outstanding Query. Or does your Edit Check take into account that perhaps the other CRF page hasn’t gone through the second Data-Entry pass ?
The Solution

Let’s expand on the earlier example of Date of Informed Consent (“INDTC”) <= Date of First Visit (“VSTDTC”). Assuming that there are other Edit Checks taking care of each the Fields having a value and the value also being within Legal range, we have a whole list of Skip rules built into each Edit Check. So whenever any of the followign conditions is met, the Edit Checks skips (“return()”):

    * the CRF page with INDTC hasn't reached a sufficient validation level (then we will wait until it has)
    * INDTC is missing or illegal (then we will wait until it has been updated)
    * INDTC has an unresolved query for something else (then we will wait until it has been resolved)
    * the CRF page with VSTDTC hasn't been received or hasn't reached a sufficient validation level (then we will wait until it has)
    * VSTDTC is missing or illegal (then we will wait until it has been updated)
    * VSTDTC has an unresolved query for something else (then we will wait until it has been resolved)

Is it difficult? Yes and No. Anybody who has ever worked with DFsas, will understand that this tool is extremely helpful in this. Anybody who has used this tool, knows it versatility. As with most things in life, this strength is also its weakness. Meaning that you have to be very careful with its programming. If you replace

15    SEX               "Sex"
16    RACE              "Ethnic group"
with
16    SEX               "Sex"
15    RACE              "Ethnic group"

The contents for Sex and Race will be swapped, so a Black Male will ‘turn into’ Caucasian Female.

Anyway, this same feature of exporting Fields by their Field reference (so by a number) is very helpful when exporting to SDTM. Some SDTM Domains are highly Normalized, meaning each item on a CRF page results in the creation of a single record in the SDTM Domain. Examples of these are the “VS” or “QS” Domains. So if you have a single CRF page with a number of different Vital Signs, your SAS job file might look like:

# data1
NORMALIZE
DFVISIT    "DataFax Visit Number"
VSTPTNUM   "Planned Time Point Number"
VSTESTCD   "Vital Signs Test Short Name"
VSDTC_D    "Date/Time of Measurements"
VSORRES    "Result or Finding in Original Units"
VSORRESU   "Original Units"
#
# Variables from plate ...
#
RECORDS 123
6 "1" "SYSBP"   8:s 11 "mmHg"
6 "1" "DIABP"   8:s 12 "mmHg"
6 "1" "PULSE"   8:s 13 "BEATS/MIN"
6 "1" "HEIGHT"  8:s 14 "cm"
6 "1" "WEIGHT"  8:s 15 "Kg"
6 "1" "TEMP"    8:s 16 "C"

This same method can off course be used for the “QS” Domain where each individual item (of a Questionnaire) needs to be exported as a single record

And the bigger the company, the more they rely on their SOPs. As if a SOP can avoid getting a corrupt database when an untrained user adds a new variable in the middle of a CRF page halfway data collection in a large study. Anybody who has been trained in Study Setup and done this pre version 3.9, will know its impact. SOPS usually document what SHOULD be done, not what you SHOULDN”T DO.

I guess it is the same with SOPs as with hotels. That is, the average person will not visit the kitchen of a four or five star hotel, nor will the average sponsor see all the details of a CRO handled study, nor will the average Auditor see all the details of a SOP governed trial at a Sponsor. As a matter of fact, in my role of Exhibitor at DIA meetings, I have seen kitchens of 4/5 star hotels, and to be honest, in most cases my appetite was not raised in any way. And no, I am not going to present any comment on what I have seen over the years at some DataFax sites.

Does this mean that SOPs are of limited use ? No, certainly not. They are certainly useful in documenting a best practice. I only think that sometimes the focus has shifted to much from user education to SOP adherence. And the only safeguard against ‘bad things happening’ is a well educated user, not a well documented SOP. At least, that is my perception.