So this is an interesting initiative. It is important. In fact it is very important but first the bad news. The 55 areas represent a massive piece of work. It equates to 11 areas per year assuming that each takes a year. It suggests significant staff numbers, 10 or 15, may be more, full time staff. The big danger I perceive is that there is a risk of developing 55 sets of standards that are not fit-for-purpose and that do not take into account the lessons we should have learnt from earlier initiatives. The good news is that this can be done well and to the benefit of all, if it is well thought out.

It is easy to criticize, so this post is my perspective by someone who a) has been using standards within a pharmaceutical company and wants to benefit from emerging standards so as to streamline the processes within that company; and b) as someone who helps develop new standards and has spent time looking at the structure of content standards.

To begin, and just as an example of the need, I will outline a couple of issues encountered within my current work.

The first is the Tanner Scale. This is a scale (1 to 5) of physical development in children, adolescents and adults. Now where do I place this within SDTM in terms of domain? I would immediately think Questionnaire (QS). But I have seen it placed in Subject Characteristics (SC). Which is right? SDTM experts will justify one or the other and that justification might be based on study specific criteria. But I want it to be obvious to someone who has only read the SDTM Implementation Guide, the “average” user in industry. Now one question does arise? Should a piece of content always be placed within the same domain within SDTM? From the FDA viewpoint this makes sense when trying to pool or integrate data. Does it make sense from the FDA perspective for other uses? From other scientific perspectives it may not. These issues seem rather important to me but I have not heard any debate on these topics. The important issue is the fact that I and others can debate it. And that debate does not bode well for a standard. We need precision.

A second example is the recent release of CDISC questionnaire terminology. Within this package were Test Codes, Test Names and Category Codes for a number of instruments. One in particular that I have worked with is the Work Productivity and Activity Impairment (WPAI) scale. Absent however within the terminology were the results scale and associated terminology; I know the results scale in this particular case is not complex but there is still an opportunity for the “average” user to get it wrong. And therefore while I and other companies can align our tests, we cannot align the result. Here there are gaps in the definitions for a given instrument.

I use these two simple examples so as to highlight the sort of information that needs to be defined and what we want from the therapeutic area development. So below is my specification of the TA needs. This is my set. Please feel free to comment, add or disagree. No one person has a monopoly on good thoughts and/or ideas.

I have split my thoughts into four parts, Scope, Methodology, Outputs and Training:

• Scope: what do we mean by therapeutic area? Is it a core of definitions, some meaningful subset? These simple questions then lead to thoughts about versions and increments. It strikes me that we will never be able to deliver the complete scope of an area in one release. Also with a large number of areas being worked upon in parallel, are we in danger of flooding the user community? Can the FDA cope with the flood? Scoping is therefore important as are the release cycles and mechanisms.
• Methodology: We need a methodology that delivers consistent structuring of definitions. I also want to understand the methodology so that I can develop content using it. This allows me to develop consistent content that I could also feed it back to the user community in an immediately useable structure. We simply cannot afford to have differences in the structure of the definitions.
  Also, these definitions will, in the long run, need to be placed into a repository; the industry metadata repository. If definitions are not structured consistently then we will hit problems when we try and load them into such a repository. Also any tools developed to process the data based on the definitions will have problems with inconsistent structuring of definitions.
• Tools: This in turn leads to the need for tools so as to manage the consistent structuring of the definitions but also to manage the sheer amount of work needed. The tools do not need to be complex and sophisticated. We can manage with MS Excel tools in the first instance to get us going quickly and ensure that definitions are structured according to a methodology that brings consistency across the therapeutic areas. What we need to do is decided quickly what the structures are, how best to represent them, some simple tools to help manage them to get us going. Tools can also validate the content checking for consistency and completeness; does the content make sense and have we have filled everything in.
• Outputs: We must have high quality outputs
  • Consistent – The outputs across therapeutic areas must be consistent within themselves and across the areas. This is something that has not been the case in the past.
  • Complete – The outputs must be complete. We cannot have incomplete terminology or any other item for that matter. To have such results in a non-standard.
  • Useable – The outputs must be usable. To be useable they must include not only a human readable forms (e.g. PDF) but also a machine readable forms such that a user can read into, or transform into a form suitable for reading into, their systems so as to gain immediate benefit. These formats will also allow sharing. If we have machine readable forms the human readable forms (PDFs) can be automatically generated.
• Training – We need to train people in the methodology and the tools so as to deliver the attributes discussed above. Without such training we will have great variation in the structure and quality of the deliverables.

None of this is easy. But clarity of thinking around the methodology and tools to support such will pay great dividends. They tools, in the first instance, do not need to be sophisticated. What we do need is the 10, 20 or whatever the number of people working on the project need to understand is what they are producing and why, they need to understand the methodology and be advocates for it.

The views expressed within this post are mine and do not represent the views of any organisation I volunteer for or client that Assero is employed by.

The quote was used by Bernard de Bono from the European Bioinformatics Institute, during a question and answer session at the CDISC EuroInterchange that took place in Stockholm last week.

Bernard was talking in the context of creating a new term, a new piece of terminology, a new definition. His plea was don’t do it and hence the quote, go and lie down until the feeling passes. His argument was that, if you do create the new term you are a) saying that this is some new knowledge because no one has defined it before and b) you are creating a maintenance problem.

I am going to leave the first point; I shall leave that for another day. What I want to focus on is the notion of the creation of the maintenance issue. Since the New Year, it has become apparent to me that CDISC has, over the last year or two, hit a new issue. I have discussed the issue with a few folks over the past two months that the standards are now mainstream; as Chuck Cooper from CDER stated at the interchange, 40% of electronic submissions now use SDTM. This, however, means that the standards now need to be maintained. Exhibit one, Amendment 1 to SDTM, Exhibit two the CDER guide on standards. And this is where we hit the big problem. Volunteers and maintenance don’t mix too well.

Another challenge for CDISC is the simple amount of work it is attempting to undertake. This was witnessed by the Gantt chart presented by Wayne Kubick – the new CDISC CTO – that lists 23 major areas of work. In fact the list is probably longer as some of the items contain multiple projects and the list includes only 10 of the 55 therapeutic areas that has been mentioned as being tackled over the coming five years.

I discussed this with a few people at the interchange. The therapeutic area development is a major challenge – more on this in a future posts – but the one issue that came out of the conversations is that are we simply setting ourselves up for a fall. By trying to do too much are we simply bound to fail? And by failing do we damage the good work achieved to date?

There are no easy answers. Is it that CDISC now needs a new business model? Is it time that we have to accept that CDISC needs more resources? Do we have to give up on the idea of volunteer led standards development?

In a decade or so CDISC and the industry have come a long way. 40% standardised electronic submissions is no mean feat. As I noted above, the session within which Bernard made his quote was a panel, question and answer session. I always feel for the panel in these circumstances. I have been there, you can never win. The questions are always of the negative nature. Why have you not done that? When are you doing this? Why did you do that? We focus on the negative. This post is focusing on the negative in that it is looking at the challenge ahead. However, we also need to be realistic.

I believe that Bernard attributed the exercise quote to Winston Churchill. If I have got this wrong then apologies to Bernard but when I looked on the wonderful web it seemed to be from Robert Hutchins. But if I may borrow and plagiarise another Churchill quote: Never in the field of standards development has so much been owed by an industry to so few volunteers. CDISC has achieved so much. Let us not waste it by trying to do too much in the future without the required resource.

And one final note. The views expressed within this post are mine and do not represent the views of any organisation I volunteer for or client that Assero is employed by.

So if that did not make March frantic enough, I find myself sitting on a plane heading to the US for an exciting week of volunteering. The major event of the week is the FDA /PhUSE Computational Science Symposium with the second half of the week being taken up with a CDISC Technical Leadership Committee (TLC) meeting and a CDISC SHARE team face-to-face meeting.

I was surprised and rather honoured – this is English understatement – to be invited to participate in the PhUSE meeting. In the past two years, the DIA have run the event but it has only really manifested as a two day meeting at which people gathered and after two days left. With this event, the FDA is very much driving the idea that the two day gathering is an initial kick off meeting with working groups continuing their work going forward through 2012 and into 2013.

At the current time six working groups have been set up and have undertaken some preliminary work with the real work starting over the next two days:

• Working Group 1 Validation – focusing on collaborating to develop a robust process to rapidly validate and assess data quality as data moves through the product life cycle across both industry and regulatory review.
• Working Group 2 Site Selection – continuing the ongoing work developing standards for the data set used in a risk model designed to improve the quality of clinical inspection site selection for drug trials.
• Working Group 3 Integration – looking at the challenges of analyzing and integrating data from retrospective studies from both an industry and regulatory perspective
• Working Group 4 CDISC Implementation – looking at specific challenges with implementing the CDISC data standards
• Working Group 5 Standard Scripts – focusing on standard scripts for data transformations and analyses across and/or within a therapeutic area and exploratory analysis.
• Working Group 6. Non-Clinical – discussing various approaches to the standardization of nonclinical data and the possible implications to the development and implementation of data standards.

The meeting has sold out with 300 registrations being accepted by PhUSE for the event. It should be an interesting event and it will be exciting to see the work that will emerge from the working groups.

I will endeavour to tweet news over the two days.

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.