Introduction

It has been a while since I last posted so I am going to try and explain that there is a good reason for this. I went of at a bit of a tangent, but a good tangent…

A few weeks ago at the CDISC Interchange in Europe I was having a discussion which led to another discussion which, you get the picture, around the CDISC Therapeutic Area work and tools to support content generation and the need to make the work easier. Also rattling around in my mind were some wise words from the deep past along the lines of ‘don’t get obsessed with the technology, remember the process’. Some other words from Sam Hume I think from the last CDISC intrachange about ‘minimum viable product’ had struck a cord and also my own desire to see some tangible outputs was nagging at the internal thought process. In parallel with this I was beginning to document the semantic model (see the ‘Last 5 Posts In Series’ box to the right ) that I have created but was feeling that I needed to make the work more visible in some way combined with a feeling that there was a need to talk about Research Concepts and explain them further.

So all of these thoughts and concerns went into the melting pot and I came up with an amended plan that built on everything I had done to date. The plan consists of four steps:

1. Create a semantic model / implementation. I have an implementation and this is what I was beginning to write up and post onto GitHub in previous posts.
2. Create a simple MDR and Study Build tool to show the ideas working. The tool will use a simple file-based database to speed progress. If  it helps I would like to use this to assist those grappling with the CDISC content creation. This is what this post is all about.
3. Link the semantic implementation with the simple MDR / Study Build tool replacing the file-based database with the semantic one.
4. Improve the tools and the semantic implementation. Iterate adding functionality and fixing issues.

And so this is what I have done, about 4 weeks ago I put my head down and I got on with implementing a simple UI that uses a file-based database (based on CDISC ODM and define.xml along with a few bespoke file formats) that demonstrates Research Concepts and their use. What I have done is kept the ‘file database’ logically aligned with the semantic one so as to make life easier when I reach stage 3 when the UI and semantic world are brought together.

Now I was going to write this up when everything was looking wonderful but I have reached the stage where I think it is safe to show some of this work. I have a few more days of testing and bug fixing but I wanted to get this post out this week.

So what has been built? I have built a combined web-based tool (I will stress the tool is very simple and takes a lot of shortcuts) that handles and manages:

1. Terminology
2. Research Concept Templates
3. Research Concepts
4. Forms
5. Domains
6. Studies

I have wrapped these functions into a set of web pages and created a single entry page so I will start there in the description below.

Before I do provide a quick overview I know that as soon as people see this I will get a series of  “can it do X” and “it doesn’t do Y” type questions and comments. I have shown some early builds to a few people and I have already had a few. Please fell free to make these comments. The feedback is very useful and helps build a better demonstration and answer the trickier questions.

Home Page

Home Page

As can be seen from the screen shot to the right and those below the general layout I have chosen is that of having a menu down the left hand side so as to provide access to the main operations (the list seen above). On the right is the content for the page in question. In this case the home (entry) page just has some help / explanatory text and a simple login form.

The login form is present such that when I upload this to the web (I am hoping to do that this week after going through cleaning up bugs and making sure it all works reasonably well) I can let people have a play but provide some controls such that it is not a free-for-all as the content will be shared.

One feature I would point out is the main menu on the left, the items within it and the separation between items. Work from the top, ignoring the home option, you see Terminology, Templates and Concepts, Forms and Domains and then Studies. This represents the expected workflow and user role separation expected to be seen within a sponsor organisation. Also the Study versus the remainder of the items reflects the separation between the Metadata Repository function and the tool(s) that use the MDR content.

Terminology

CDISC Terminology Browser

The terminology section currently allows only the CDISC terminology to be browsed. One thing that definitely is required is the ability to enter and manage Sponsor terminology and this feature is something I intend adding over the next few weeks.

Obviously the CDISC terminology should not be modified, you might want to select subsets etc, but you should not be modifying (you might want to extend). With the sponsor terminology you obviously want to be able to create new items as well as manage the existing content.

The other feature that users would want is the ability to load new versions and that then leads to thinking about impact analysis. This is a topic I will return to on a regular basis of the coming weeks.

One thing to note are the tabs across the top of the main window. There are always two tabs with some features having additional tabs. Here we have the main terminology tab and a help tab with the help tab being present on every page.

Research Concept Templates

Research Concept Template

This feature allows the Research Concept Templates to be created. The templates ensure that Research Concepts are well structured and we use there BRIDG model as the basis of that structure along with the ISO 21090 data types. As can be seen there are four windows:

1. Basic Research Concept Template information window
2. Existing templates window, allows existing items to be selected for editing
3. Main Research Concept Template editing window
4. BRIDG window to select BRIDG components

The idea is to select various BRIDG items that are used to build up a generic set of data items that build an observation of the type desired: a time, a date, result, units for the result, a method, a body position, a body location and other attributes that together make sense. This information is then saved as a template.

Note: The above is a quick explanation to give a flavour of the actions taken. As we go into posts over the coming weeks the way to use the tool will be explained in more detail.

While BRIDG is a tree-like structure I have chosen to present the template in a flat format using an alias mechanism to make the parts meaningful to the SDTM user. Also, most templates should be provided by CDISC thus making the sponsor’s life a lot easier.

Research Concepts

Research Concept

Having got a template for an Research Concept we can then fill the template in to create an actual concept. A similar layout is used as for the template editor but with an additional window:

1. Basic Research Concept information window
2. Existing Research Concepts and Research Concept Templates window. Allows existing Research Concepts to be selected for editing and for the selection of the appropriate template.
3. Main Research Concept editing window
4. Research Concept Template window to select which bits of a template are needed for a given Research Concept
5. Terminology window to allow terms to be bound to the Research Concept

To build an Research Concept we would select the items from the Research Concept Template; do we need a method, a location, and then add the appropriate terminology from the terminology fo those methods, the appropriate locations (note that this is effectively setting up the value level metadata). We would also set the question text, formats etc (e.g. CDASH type of information).

Like the templates, what we want to happen is that the vast majority of Research Concepts should come from CDISC with a lot emerging from the Therapeutic Area development work. Hence the interest in helping getting things working in that area.

Forms

Form Construction

And then we reach the useful business objects. Forms and domains from which we can build studies. Again the layout is similar to those already seen but using three windows here:

1. Basic Form information window
2. Existing Forms and Research Concepts window, allows existing Forms to be selected for editing and selecting Research Concepts for inclusion within the form.
3. Main Form editing window.

Here we select the Research Concepts we want on our form, name it and save it. I have added some sophistication to group Research Concepts and also extract common elements (e.g. time and date) that appear in a lot of Research Concepts but we only want to collect once.

Automated Annotated CRF

You will notice the Visualisation tab. this is where we start to benefit from the power of Research Concepts. I can visualise the form and annotate it automatically based on the Research Concept definition and the Domain / Research Concept links setup (see below). The layout of the CRF is a bit poor at the moment. It is simply a style sheet running over an ODM file so I can set the look and feel to be whatever I wish. In the interests of time I have kept it simple at the moment but it could be written to look like the company standard, an EDC system or whatever layout is desired.

One feature we would want within the form editor is the ability to deal with optionality, such as fix a code list to a single value rather than being able to select it, ability to amend question text and a range of other functions that bring operational flexibility. I have gone with the very basic feature set at the moment in th interests of getting the first cut implementation out there; the minimum viable product mentioned above.

Domains

Domain Editor

The second business object, domains. Similar layout again to those already seen but with four windows:

1. Basic Form information window
2. Existing Domains and Research Concepts window, allows existing domains to be selected for editing and selecting Research Concepts for inclusion in the domain.
3. Main Domain editing window containing all those things we know and love from SDTM, looks very much like the SDTM IG.
4. A window with the associated Research Concept list; which Research Concepts belong to this domain.

A lot of this information should come from CDISC but, naturally, for custom (sponsor) domains a new definition will be required. I have taken a tad of a short cut with the implementation here in that I have just imported domains from some existing work and not implemented proper SDTM classes on which the domains are then based.

Studies

Study Editor

The above are all MDR-related but we have built some forms. We can now deploy those into a study. The study editor uses four windows:

1. Basic Study information window.
2. Existing Studies and Forms window, allows existing studies to be selected for editing or Forms to be selected for a study.
3. Study Visits editing window containing all the visits in the study with basic parameters for each.
4. Study Table of Events window to allow forms to be associated with visits.

The visit table and Table of Events allows for visits to be inserted, named and forms associated with them to build up that table we typically see in the protocol document.

Having constructed the Table of Events then the study detail can be displayed (the second tab) where we would deal with optionality and other  operational flexibility features. We also want the study aCRF is a similar fashion to the form aCRF. This can be automated based on the Research Concept Form and Domain relationships.

Another facility that I will implement is being able to generate the study define.xml file. This can be generated automatically with the expected study definition. This is something I will implement in the coming weeks using define 2.0.0.

Update: I wanted to note here that, in addition to a study define.xml file (useful for sending to a CRO for instance, SDTM programmers etc.) users would also want other study-level outputs such as EDC configuration files (ODM, Medidata ALS etc.). These can be readily generated.

And Finally …

One other feature that I will implement is what I refer to as the placeholder. We need top be able to specify roughly what content might be required within a form or  study when that content has not been defined within form or a Research Concept. I also know from previous experience that there needs to be flexibility in handling SDTM annotations with some of the more weird cases and one very useful feature I have implemented in the past is the ability to add notes to the study CRF to add explanation about certain points.

So I will fix the last few bugs, test a little more and then publish the tool. After that it will be time to link to the semantic database and get back to documenting the semantic side plus additional UI features with a few more posts.

Update: Should publish the tool tomorrow (Friday 3rd July).

Update: Tool has now been made available, click for further information

There may be a gap in posts … the Tour de France is upon us!