So lets start by considering the writing of a protocol. Within the protocol document today, we typically see statements such as “Demographics (age, gender, height and weight)” or “The following baseline demographics and disease characteristics will be captured in the eCRF: Sex, age, body weight, height/length, and race.” Through statements such as these the protocol writer is giving us the first indication of what data is to be captured as part of the study but at a high level using the name of a “concept” such as AGE, SEX and so on.

Figure 1 - The flow of metadata

The reason I put the word concept in quotes is that this single word conveys many different meanings to many people, it is desperately overloaded. What I mean when using the term is a collective designator for one or more atomic items of data that in combination represent some meaningful notion or idea. AGE is a simple example. It is meaningful to most people, consists of value and units and we can provide a good definition for the concept.

So in the first diagram, I see the initial use of the concept within the protocol simply via use of its name. That protocol document is then converted into a study implementation that consists of a set of paper or electronic CRFs – it should be noted that I don’t distinguish the usefulness of metadata simply because of the use of paper CRFs, they need to follow the same rules – with the CRF expanding the concept into its constituent parts.  In addition to the basic definition we will also be interested in how the data are to be captured, how the units are to be presented and other such considerations.

In my simple example AGE, as I said, will consist of two parts, the AGE value and the associated AGE UNITS and we will need to capture these items on a CRF. Now most of the time the units will be fixed, years most likely, may be months but we still need units to make sense of the value. I am of the school that likes to have the variable hidden within the system even if the user cannot change it simply for the purposes of consistency across studies when data are exported. And obviously this data will be collected for the N subjects within the study, hence the multiple CRFs in figure 1.

Once we have our data collected, we will want to take the values into a tabulation with columns holding the AGE and AGE UNITS values from the N subjects. As we move into the world of the tabulation from that of the CRF, we will need to think about the columns and definitions in relation to the dataset as a whole and information about the dataset itself such as its name.

Figure 2 - Extract The Common Parts

So what we see is that in each part of the above chain – I stopped at the tabulation rather than adding further use cases such as analysis dataset, warehousing, data aggregation etc –  there is a common set of information used within each use case but that each use case also requires its own particular metadata. And for these reasons, I created the second diagram and show in figure 2 that we would like to extract that common core definition and bring it into one place to be shared across the use cases.

This then leads to a desire to organize the metadata in a layered fashion as shown in figure 3. In this simplified view, we want to put at the base of our metadata “stack” our code lists – the controlled terminology – and then in the layer above the definition of  our concept. This provides our core building blocks, a definition that is independent of the use case but consistent across all use cases.

On top of these two lower levels, we can then layer on top the extra metadata applicable to the use case, the CRF for example with the presentation information and such items as range/edit checks that we would need to assist in collecting data. For the tabulation, we want to add precision around the column definitions, may be formats, whether a value is required or is optional, rules for missing values etc.

Figure 3 - The Metadata Layers

One thing to note about the diagram is the warehouse and that I have placed the Study Configuration linked to the warehouse. In reality, the Study Configuration will be created as part of the study build process earlier in the life-cycle but my thought was that the use cases that best illustrate its relevance in the metadata world is the desire to aggregate data across studies. This need drives the requirement that we know what is on each of those studies in the sense of the study construction all the way down to concepts, variables and code lists. Hence my decision to draw it there for the sake of an uncluttered picture.

Finally the submission and review, where the metadata needs to be passed to the regulatory authority, define.xml is one such item but annotated CRF and other such items are also applicable.

I have tried to keep this short and sweet but get the message across. We should be organising our metadata. It needs to be well structured.

It is good to be back writing again, hopefully a few more blogs will flow over the coming weeks.

My concern is based around a commercial organization taking out a patent on work that I consider to be already in the public domain. What is worse is that I, and many others, worked hard to not only produce the idea but also ensure that the work was placed into the public domain with no restrictions on who could use it.

My story begins in 2000 and before working with eDiaries within clinical trials. When working with customers, about the fourth question they asked was, – this is after the “is it part 11 compliant” question – “Where is the source data?” At that time, I did not have an answer but it interested me. So, when in 2002, I had some time, I started reading everything I could find on the regulations about source data. I remember reading papers by Paul Bleicher, then at Phase Forward, and by Steve Raymond of PHT fame and discussing the issues with these learned folks at DIA meetings. In 2003, I wrote a paper for the peer-reviewed, Applied Clinical Trials. In order to get that article past peer-review, I remember having to remove a suggestion that the basis of an eSource Data Store should be the CDISC Operational Data Model (ODM). Apparently, the suggestion of using standards at that time was considered too controversial! The article was published in February of 2004.

By this time, I was working with CDISC furthering the cause of the ODM with the FDA. I have just looked back at presentations that I gave with Dr Rebecca Kush at the FDA in late 2004, extolling the virtues of the ODM and starting to discuss eSource. In late 2004 the FDA invited CDISC to look at the question of eSource and the existing regulations. I was fortunate enough to co-lead the team and, in November of 2006, the final version (after six drafts, four of which went out for public review) of the eSDI paper was published.

While working on the eSDI paper, CDISC were attacked for having the audacity to tackle the subject and there were those on the CDISC Board who questioned whether CDISC should be dealing with such a topic. But in the end the work was well worth it because that document lays the foundation for the use of eSource within clinical trials, irrespective of technology. By developing the 12 principles that are described within the document, any solution can be assessed and seen to meet the regulatory need or not. The paper also presented five potential architectures.

Then came something that I am proud of. The EMA decided to base their eSource guidance on the eSDI work and by doing so, I believe, improved on the eSDI content. The FDA also updated the Computerized Systems Used in Clinical Trials (CSUCT) document to become the CSUCI guidance document and put a toe into the eSource waters. Unfortunately the FDA then released a draft eSource guidance and failed to follow the EMA’s lead by utilizing the CDISC paper.

In parallel with all of this, I was working with Landen Bain as he led the charge to look at practical – and I stress the practical – ways to integrate Electronic Health Records with Clinical Research. Through Integrating the Healthcare Enterprise (IHE), he led the work on the RFD profile that came to fruition in 2007, with several demonstrations of capability at the HIMSS conference in New Orleans. Included in that demonstration was the first incarnation of an eSource Archive based upon the CDISC ODM. This demonstration turned into a formally developed system that has been used in subsequent IHE connectathons and HIMSS events both in the US and Europe. It has been used in several demonstrations of eSource capability to the FDA and has been demonstrated at the 2011 DIA Annual conference. That eSource tool contains the ability to use ODM as an eSource Document, read them, it has audit trails, user roles and leverages the ODM’s metadata to provide meaningful displays of the data and audit trail.

The picture I am painting is one of several threads of activity, all undertaken within open standards development organizations since 2004, with many volunteers and organizations giving their time feely and working in a spirit of cooperation to develop solutions that are for the benefit not only for those giving their time but also for the benefit of clinical research organizations (in the most generic sense), regulatory agencies and ultimately the public with the provision of better and safer products.

I looked back through many presentations that I have given on eSource. Within these presentations are ideas for system topologies, descriptions of the issues and many suggestions. Audiences include the FDA, EMA GCP inspectors and DIA meetings in both the US and Europe.

I am deeply saddened by the discussion in the thread. Having put in many hours working with many others who have also made significant contributions to bring clarity to a difficult subject for the benefit of all, it is galling to consider that an organization can patent ideas where there appears to be a huge overlap with the work done by CDISC and IHE. I have yet to see anything within this patent – I am happy to be proved wrong -  that is not covered by the work undertaken by many volunteers since the first steps back in 2004.

Here are just a few of the presentations across the year’s to give a flavour

DIA Euro Meeting, Lisbon, March 2005

Slides 37 through to 43 inclusive discuss the Trusted Third Party

EMEA, London, June 2006

Slides 49 & 50 are interesting. They present the generic eSource archive/store architecture.

DIA CDM Meeting, Florida, March 2007

Slides 22 to 25 show the relationship between the IHE RFD profile, eSource and a Trusted Third Party (the Archiver)

So it is for those reasons that this is one of those difficult blog posts to write simply because the subject matter is one that has caused quite a bit of confusion, as well as being one that has resulted in a releasing of emotions in the past. So either this post will result in a flurry of comments or a deathly silence.

I cannot start off by giving that wonderfully simple definition. Wouldn’t it be wonderful to simply say “round data is …” however. I can’t. But I believe the vision of round data, for that is what it is really, a vision. I believe round data is all about context. I have taken part in many conversations about the CDISC standards and context and I have even understood some of them. In the current standards, you will find that there is a lot of implicit context or assumptions. It is these assumptions that get us into trouble because implementation of the same standard will undoubtedly make different assumptions and thus we don’t have a standard, we have two similar implementations.

Consider the value, 180. That one item of information tells you nothing. If I add the units “cm” so as to make 180 cm, you now know it is a dimension. Given the magnitude you might make an assumption it is a height. Now if I add HEIGHT, to build HEIGHT=180 cm I am beginning, but only beginning, to add the context around the recording – or observation – of the height.

But more questions immediately emerge. When did I observe, why did I observe, what happened before and what happened after? So the observation needs to be placed into the context of the method of collection, the collection instrument, be it a case report form or a medical record both of which may be paper or electronic. In the event of the case report form that probably exists within the context of a study and thus a protocol. So as you start to see from this very simple picture of our clinical research world, the context of a simple observation becomes increasingly complex.

What we strive for is to place the observation into the right context. A human does that very well. You or I can read the protocol, examine the annotated CRF and look at the resulting dataset. But if we want to get more from our data, to be easily able to aggregate across studies, we need the computer, the machine, to have access to that same context. Some of the things we might wish to see are:

• Relationship between a clinical observation and the planned observations, did we capture everything intended? Did we capture more? Which observation is which?
• Parent child relationships, for example, these multiple results came from a single sample
• Relating adverse events to interventions
• Terminology relationships

We have some of these relationships today but they are, as I have said, implicit. The value and units of our observation are related but only by an implicit positional relationship because the two columns are next to each other in the dataset and the data specification (human readable only) tells me what those two columns contain. We need to make those relationships tangible. SDTM has gone a long way to achieving this but suffers from only providing them in a human-readable form and not having the scope of relationships that we may wish to see in the future.

We therefore need to build on SDTM and all the other good work to get to the round world. But the relationships extend across a single standard. Consider the issue of traceability of submitted data back to the case report form. The relationships in this scenario encompass not only SDTM but CDASH and potentially ADaM.

So a definition for round data? I would suggest round data as being nothing more than a richness of relationships. The challenge is defining the relationships we want, how best to describe them and how to transmit them.

First of all I thought I’d draw your attention to John Halamka’s blog. It’s an interesting mix of highly technical records of the current developments in the HIT world (which at times seems mind boggling!) and government policy, along with some new and interesting technology observations and some very personal revelations about his family. I don’t think I have ever read anything controversial or even remotely tricky in his Blogs (which in my opinion is not the purpose of a Blog, it should always raise questions and invite comments), however to read that he has had his Blog used against him was rather surprising. Blogs and other forms of social media are public documents that are there to engage an audience; they are snapshots of thoughts and ideas that help to create a better understanding of our industry. I think we need to be careful about what we say but not so careful that freedom of expression and good debate are squandered for dry renditions of current developments that don’t interest anyone! Most criticism seems to come from those who either don’t write blogs themselves or can’t imagine how anyone who is doing any work has time for such linguistic efforts.

So moving on, CDISC have been producing some interesting Blogs about the Interoperability Showcase at the recent DIA Annual meeting in Chicago (There’s a good webinar about it here). For Dave and I, this has a personal interest as we are an integral part of the Archiving solution for the Retrieve Form for Data (RFD) capture profile (developed by IHE) along with our partners IPL. From the first moment Dave and I started working together, he had a deep conviction about the way that an electronic archiver could solve many of the ‘paper’ based challenges for research and also that having an archiver meant that health records did not have to be 21 CFR Part 11 compliant (This is a fairly weighty but important tome which you can find here). Dave and Dr Kush (CEO CDISC) worked together on the highly influential eSDI document that has been referenced by EMA and I was extremely privileged to be at White Oak when they met with the FDA to give some clarity around the 12 scenarios. You can find out more about the archiver by contacting us and of course we are more than happy to explain how important it is to the success of RFD. One of the key benefits of the archiver however is the notion of traceability. When the regulator asks to see the source of your data 7 years after you started your study, can you find it easily? Is the physician’s office where you conducted the original research still there? Is the CD of the paper report forms still in existence and does it still work? What if you are looking for data to look for new indications for a therapy? Can you quickly retrieve all the original data? If you don’t have a central source, this can be tricky at best, time consuming at worst or perhaps a complete disaster if you can’t find the data at all. Another important consideration is that while there are disparate electronic health records and systems that have been implemented globally, the RFD solution is the best possible way to capture research data in order to develop that truly electronic trial. This is something Assero is passionate about (in fact Dave has written about it here in a recent blog and our main page on Standards for eClinical also outlines what we do). It was a shame that Dave and I were simply too busy to attend the Showcase and the Annual but I am hoping a certain Landen Bain will be bringing his great carnival to Europe next year, as after all we have electronic health records here too and it would be interesting to get a discussion going this side of the pond!

Finally, I know that the on-going debate about social media for research has moved on from when I wrote one of my previous blogs, there has been news about Pfizer using social media (or an interactive method for collecting data)  and there is a good blog here about the relationships involved and participation in trials where you don’t necessarily talk to a  physician. It makes for an interesting read and, as I suspect the industry seeks better data and compliance by patients, new methodologies will be sought to capture data of that I am sure. So watch this space as the debate rumbles on and don’t be shy, let us know your thoughts.

The question was “What is the semantic web and linked data?” So first of all Kerstin suggested that I read an article  An Intro To The Semantic Web: Why You Need To Know About It Sooner Than Later and watch a video Linked Data (and the Web of Data), a 4-minute video from Ireland’s Digital Enterprise Research Institute (DERI).

I did not feel that either gave me that one sentence answer I was seeking to the question posed. I wanted something short and sweet. Kerstin and I had a chat via a web conference, she sitting in a café in Goteborg with me in the UK, the power of the internet allowing us to connect and discuss. Around the same time Kerstin posted a link via twitter (you can follow her via @kerfors) to a presentation by Juan Sequeda on Slide Share. So I looked and read. Fortunately this particular slide set and explanation made far more sense to me.

I also did that thing we all do when faced with explaining some concept to people when we ourselves do not really know the answer, we step back to first principles. We used to reach for the dictionary on the shelf, now we go to the technological wonder that is Wikipedia.

The Semantic Web is a “web of data” that enables machines to understand the semantics, or meaning, of information on the World Wide Web.

After digesting these two additional sources, in particular the presentation by Juan Sequeda, the light bulb in my brain started to glow, a little dimly may be, but glow nonetheless. My conclusion?

While the web we know today is a series of documents designed for human consumption, the semantic web wants to permit access to all the data across the web and allow machines to process it.

Now Kerstin changed this in the draft of the article to:

While the web we know today is a series of documents designed for human consumption, the semantic web wants to make data ready for automation where machines can directly process it and hence give humans new insights

But there may be something missing. And it is that word semantic in “Semantic Web”. We also want to understand the data, get at the meaning of the data. So my final version of a description for the semantic web:

While the web we know today is a series of documents designed for human consumption, the semantic web wants to expose the data, allow the meaning of the data to be understood and permit the data to be consumed by machines so as to give humans new insights about the data

To allow the machine access, we need a mechanism by which data sources can describe and expose their data. This is not something I want to discuss in this post but we will certainly be returning to this topic in subsequent ones. Now, if two sites publish their data and there is a common component within those data (some part is common), then the two sets of data can be linked. And thus we have linked data.

The semantic web is a way of publishing data, linked data is the process of linking it together.

One final thought that crossed my mind as I was reading through the materials referenced above is about the definition of the data. The semantic web seems, and I stress this is an initial impression bred from ignorance, to be built on less than precise definitions. This is another question we will look into in subsequent posts.

So our set of questions can now be extended to:

1. What is the semantic web and linked data? See this blog post
2. What is an ontology?
3. Where do RDF and OWL fit?
4. How do I link my data?
5. How precise are the definitions?
6. What could these things, if they are relevant , bring to a metadata repository?
7. What do they mean to clinical trial data, what is the benefit, what is in it for me?
8. What can other industries teach us?

Hopefully we will reach then end of the questions rather than just generate new ones!

There are no simple answers and a short-ish blog post will not provide detailed answers. I thought it might be interesting to write down a collection of high-level thoughts and see if people find them useful to fashion and guide their own thinking.

Tracing the Data - FDA 2006

One goal I keep in my head is based on a presentation I did back in late 2006 to some folks at the FDA, as part of talking about the potential of using the CDISC Operational Data Model (ODM). In particular, I spoke about the “Chain of Custody”. The idea was not only being able to trace forward from the capture of the data through analysis and onwards to submission but also in the opposite direction. I painted a picture of an FDA reviewer being able to view data on screen, click on a data point and instantly see the entire history of that data point, its providence, be it a data point that was captured or some summary statistic or calculation. If it was a captured data point, we would want to see the CRF page, the audit trail of changes and then its flow through the analysis process and the final submission.

Why this scenario? Well I choose it because it encompasses an awful lot of capabilities. It requires electronic data for starters rather than paper, it requires standards at a number of levels such that the data can be understood, stored and transmitted. It requires high-quality data, it requires an audit trail, it requires data in known places that can, as I say, be understood, it requires metadata. It requires many capabilities we are working on, but it places them into context and paints a vision, a vision from the perspective of standards and technology but also from that of the regulator and protecting the public health.

From the pharmaceutical company’s perspective, there is a need for technology and standards to support that “better” process – and we need to define better, quicker, cheaper obviously come to mind but support the mainstream development and submission activities. Companies want to be able to:  understand the data, know all about it, know that the data is traceable and be in a position to answer any query about it from a solid position of knowledge, rather than one of semi-ignorance. It might also be good to be able to find the data when we need to! A company also needs to avoid “data decay”. By this I mean that we want to be able to understand the data in five years, 10 years or 15 years in the same way as today, whether or not the people who worked on it are still around or have moved on to pastures new. And a company would want to be able to be able to use the data: manipulate, aggregate, review and re-examine in ways that we may not have envisaged today.

As an aside from a company’s vision, I would say it is unfortunate that we do not have an industry-wide vision. It is, in my opinion, not a technical challenge as such though there are technology challenges. It is more a question of having the will to build that vision as a collaboration of regulators – note the plural there – and industry and others engaged in research. It requires a vision stating what is required rather than what should be built. But that is an aside.

Returning to a company vision, the high-level statements I presented above are the sort of statements that help fashion a vision. One advance I have never yet understood is the deployment of clinical data warehouses without the associated, “sufficient and appropriate” metadata. When I said, “use the data: manipulate, aggregate, review and re-examine in ways that we may not have envisaged today,” I cannot envisage that being possible without well-structured metadata. That then brings you to the role of the CDW, is it a simple repository of data such that the data is not lost, or is it the source of institutional knowledge?

A vision should be short and concise. It should guide you in what you need to do and be there to refer to when you are down in the weeds and forgetting why you are there in the first place. Acting without a vision is rather like trying to build a car without knowing what a car is or why you need it; in the end the resulting “product” won’t do the jobs you need it to do and, more likely, actually hinder you.

Triples, RDF, Owl, Ontology, Linked Data, Semantic Web. I’ll stop because I think I have just exhausted my knowledge of the semantic web; I am not even sure that I have the right title for this Blog. What I do know is that the topic of the “semantic web” is important. As part of volunteering on the CDISC SHARE project and building the metadata repository, we will need to be aware of what this could bring and build in the necessary hooks to do so, may be not for the first release, but certainly at some time in the future.

But the challenge is to understand it and get to grips with it. And so it is very fortunate that I have met someone who knows about these things and is prepared to try and make me “ontologically aware.” Kerstin Forsberg is someone I have met a few times now through various projects. Kerstin works for AstraZeneca in Goteborg and has considerable experience in the field and she has very kindly agreed to educate the dumb Englishman in this important field and we both felt that it would be useful to invite you along for the journey.

I like to keep things simple so I thought I would pose a few questions that Kerstin can try and answer and explain the various issues, technologies and other aspects. I will document the answers over a few blog posts and share them so that everyone can benefit.

So the questions

1. What is the semantic web and linked data?
2. What is an ontology?
3. Where do RDF and OWL fit?
4. What could these things, if they are relevant , bring to a metadata repository?
5. What do they mean to clinical trial data, what is the benefit, what is in it for me?
6. What can other industries teach us?

Finally, I would like to thank Kerstin for helping the ontologically challenged people like myself.

At the recent CDISC English Speaking User Group (ESUG) Meeting, I gave a presentation (posted here) about the way that standards can be seen as a challenge for many companies and that in order for them to be implemented you need to build stakeholder engagement. The standard methodologies for this are to rely on email, a few dry PowerPoint presentations and then try to implement. In my experience building engagement requires a far more dynamic approach and this is where getting the communications right is so important.

I started by outlining the new communications landscape, it is vast and changing rapidly. It’s interesting to me that most people in the room, admitted to having email, Linked-In and perhaps Twitter or other social media platforms open on their desktops at work, whilst they engage in their day to day activities. We are masters at multi-tasking. When I commented that very few people now pick up the phone and offices are often silent, I was met with understanding nods. We have effectively stopped talking. Teleconferences often do not have our full attention either as we’re typing or doing something else. In other words, communications is breaking down and falling behind our workflow. We have, like the technologies, become siloed in our functions and rarely talk to other departments about workflow and impact. So then when it comes to change, like implementing standards, we need to think about how we can engage people on the project. How do we communicate to one another and ensure that all the communications meet the needs of all the stakeholders, after all, not everyone wants standards or indeed see the need for them.

There is then the education piece. The reason you don’t see many slides on my presentation is because actually, I don’t use slides! Having been a teacher, I don’t particularly like slides; I would rather engage the audience and get them to join in the presentation. That is the difference between educating and lecturing. Education requires interaction and should have elements of discussion and feedback from the audience; it should not be about a ‘presenter’ or for that matter the teacher. What’s more important is that education in financially pressurised environments should minimise the disruption of workflow and ensure that people can learn without giving up extensive amounts of time. I am a keen exponent of using video techniques to support learning, particularly those that give valuable information quickly and accessibly and that can be shared easily with colleagues. We’ll be putting up some examples on this site soon, so look out for those.

The Standards Landscape in Acronyms

Perhaps what surprised me most about the ESUG Meeting was the response from some very experienced CDISC users to a presentation that focused on the peripheral aspects of standard implementation, communications, education and people. There was a core group who really wanted to understand the current issues around communicating the value of standards and it demonstrated something that I believe is fundamental to mass implementation, we must think about the people involved in the work. We need to support them in new and innovative ways and think about people in the planning, as we do the tools and technical aspects. We also need to move away from talking to people in acronyms and assuming that they already speak our standards language.  Speaking clearly is very hard to do once you are imbued with technical language, starting with the basics and a narrative approach helps everyone to understand what it is you are striving to do with standardization. It is better to start simple and then build on layers of complexity than blind people with information that confuses at best and at worst loses the message and their support completely.

I would like to thank all those that were at the ESUG meeting for the positive response and I gather at least two companies are already exploiting the use of Yammer to help them with their internal communications, I will be asking for some feedback about how useful they have found it. In particular, I would like to thank someone who I have met on numerous occasions and I know is hard to impress, who wrote on his feedback form, [the presentation] ‘Should have been longer’. There is obviously more work to do in this area.

Well good news. They have indeed told us what they want. Well a significant part of the FDA has told us what they want. The Center for Drug Evaluation and Research (CDER) have released a succinct ten page text entitled, “CDER Common Data Standards Issues Document.” The document discusses the CDISC standards – SDTM, ADaM and SEND – their use, some CDER wishes when using the standards, terminology and highlights some common errors. You can find a PDF on the Study Data Standards for Submission to CDER web page (a very useful page, the PDF is the first in the list, but this is a direct link to the PDF).

The document is incredibly useful. Why? Well consider the opening sentence:

The Center for Drug Evaluation and Research (CDER) is strongly encouraging sponsors to submit data in standard form as a key part of its efforts to continue with advancement of review efficiency and quality.

Good, CDER wants standards. The remainder of the first paragraph then talks about the CDISC standards. So they want standards and they want the CDISC standards. The second paragraph reflects on the submissions CDER has received to date and comments that everything is not what it should be:

however, due to differences in sponsor implementation of the standard, CDER has observed significant variability in submissions containing “standardized” electronic clinical trial data. CDER has received numerous “SDTM-like” applications over the past several years in which sponsors have not followed the SDTM Implementation Guide.

The paragraph concludes with:

The goal of this document is to communicate general CDER preferences and experiences regarding the submission of standardized data in order to aid sponsors in the creation of standardized datasets.

So, they want standards, they want CDISC standards, they want them this way and please read the Implementation Guide. It seems pretty clear to me.

Contents

There are two final paragraphs on the opening introductory page, the first about the need to communicate with the center – please note the US spelling for all my US colleagues – regarding submissions. We all know nothing beats good communication and the final paragraph states that the document will be updated in the future and notes the CDER data standards website which is a very useful resource. The remainder of the document goes into details about using the standards and what CDER would like to see in particular circumstances. To get a flavour of the document see the contents in the image to the right.

I will draw your attention to three paragraphs at the bottom of page 3 and the top of page 4. The first of the three paragraphs starts with:

The ideal time to implement SDTM standards for representation of clinical trial tabulation data is prior to the conduct of the study. The use of case report forms that incorporate SDTM-standard data elements (such as with CDASH-style case report forms) allows for a simplified process for creation of SDTM domains. This approach is preferred to the alternative of collecting data in a non-standard format and then converting to SDTM format after the trial (legacy data conversion).

The document then discusses legacy data conversion and the need for traceability and concludes with words about the potential pitfalls of late-stage conversion:

CDER has received applications in which the converted SDTM data sets were not consistent with the submitted analysis datasets and study report analyses, thus causing confusion during application review.

The FDA complains about inconsistent SDTM and Analysis

This last point about consistency is important and I believe both this and the traceability problem will become important issues in the coming years.

There are a couple of additional references that are worth reading. One is the new draft amendment 1 to SDTM that can be found on the CDISC website while the second is a guide to ensuring that define.xml schema validates. The define document is not new as it has been around a good while but I think it’s existence is not well known.

In this post I have picked out particular quotes and presented them as though they are the most important items to note. They are not. The whole text is important and I recommend that those working in the area of submission and/or standards should read the whole document carefully.

So this is all related to CDER, what about the Center for Biologics Evaluation & Research (CBER)? Well look at the CBER web page because the center is accepting SDTM submissions but it would be best to follow the information on the web page.

This plug and play capability, courtesy of the micro Universal Serial Bus (USB) standard, is something that we strive for within the eClinical landscape enabled by the use of data standards. But I detect a trend whereby a few vendors are trying to build the all-encompassing eClincal suite, either by developing the various components or by acquisition of the components and then integrating them into an overall solution. This sounds good until you realise that, unlike the mobile phone charger where I can keep the charger but change the phone, with the eClinical suite from a single vendor, I am stuck with that single solution, one that is not so readily changed or modified. I am constrained, as in the meantime a tool from an agile developer suddenly emerges as the best of breed tool and overtakes the competition. I am left with the second-best solution.

So what should I be looking for? I want that plug and play capability with the ability to swap tools in and out with the tools having the capability to communicate both at a transport level and at a level were content is understood. In a previous blog I talked about the three layers of Presentation, Content and Transport. I want our tools working at all of these levels, the connectivity at the transport level, the content passing over the connection and the understanding of that content at a business level.

Referring back to the previous blog  on standards development, commandment one stated:

“Cooperate on Standards, Compete on Products”

We are looking to vendors to implement standards correctly and fully such that they work with other tools out of the box. The competition is about the functionality of their products, the user interface, costs and support. Is should not be about whether or not it can connect to the increasing standards based infrastructures that are growing in the industry.

For the providers of the suites I believe the message to them is that they should ensure the components of their suite are based on standards that allow customers not only to add their own components but that these components can be  replaced twith those best in breed tools.