Our own Kevin Burges, Head of Product Management, recently featured in CDISC's monthly Volunteer Spotlight!
How long have you been volunteering at CDISC?
I believe it has been around 23 years now.
What encouraged you to volunteer your time and expertise with CDISC?
In 1999, I developed an XML-based language for defining CRFs, to expedite study build in an EDC system. I quickly realized that the emerging CDISC ODM model was solving a very similar problem, so rather than continue to develop a competing technology I joined the ODM team around 2000 and flooded them with many hundreds of comments about the in-progress ODM 1.3 specification (I have an eye for detail!). I felt it was better to help drive an industry initiative than to go it alone. CDISC seemed to appreciate the help, so I also joined the Define-XML team when it began.
Then came the XML Technology Governance team, Dataset-XML, and the Data Exchange Standards team which exists today. I've had the pleasure of working with some amazing volunteers over the years.
How did you begin working in clinical research?
After finishing university, I met Mark (Wheeldon - if you haven't heard of him where have you been!), who had just started Formedix and wanted to develop an EDC system for concurrent Phase 1 trials. I didn't know anything about the industry, but I thought it sounded like an interesting technical challenge and had the potential to move an industry forward by doing things a different way.
We quickly realized that EDC was a busy and well-funded market, so pivoted to focus on study design tools based on ODM initially, then Define-XML. Back in 2003 it seemed clear to me that the future was in standardizing your metadata, rapidly producing study designs, integrating with multiple EDCs, and automation. From then on my vision was to build what we know today as a metadata repository, though it took many years for this concept to become accepted in the industry.
What did you want to be when you grew up?
Until I was about 15 I wanted to be a vet, so although I had an interest in computers from an early age (coding by 10 and progressing to C/C++ and 68000 assembler by 14) I didn't take computing at school until my final year. Then, I realised the bad sides of being a vet and switched over to Computer Science, winning the school CS prize that year.
My project was designing and building a sound sampling device and writing the software to drive it, where my assembler knowledge came in handy to get the required performance. That led neatly into a Computer and Electronic Systems degree, split 70/70 between software and hardware engineering (yes, we did about 70% of a Computer Science degree, and 70% of an Electronic and Electrical Engineering degree - it was a busy time!)
You are working on the release of the ODM, version 2.0. What are you excited about with this release and what updates do you think the user community will find most useful?
ODM hasn't changed much over the years. I guess that's a testament to its initial design and its extensibility - it has managed to serve a useful purpose for 20 years with very little change. Another way to look at it is that ODM 2.0 has been a long time coming, and there are certainly a lot of changes.
Everybody will have their favorite features, and I'll mention some of mine. One area where ODM was lacking was the ability to define how repeating sections on a form should repeat. I defined ODM extensions years ago to define, for example, that a Medical History form could have a repeating section that repeated X times for each entry in a "Body System" CodeList. This is sometimes called a matrix form, and it has now been built into the core ODM model. A semantic layer has been added, allowing metadata objects to reference standard code systems. Nested ItemGroups allow ODM to be used to represent more complex metadata structures, including Biomedical Concepts. StudyEventGroups allow the definition of much more complex study designs that support the full complexity allowed by advanced EDC systems.
New traceability features allow better definition of the data flow through a study. These are just a few of the updates that will greatly expand the usefulness of ODM in the years to come.
Please provide a tip that someone would find helpful in working with CDISC Standards.
The CDISC volunteer teams are generally a very helpful bunch of people. If you have difficulty understanding how any of the CDISC models should be used, whether they support a particular use case, or even if you have a suggestion for the future, get in touch with the relevant team and they will likely be more than willing to help you out.
