CDISC BlogReasons to Celebrate - The Protocol Representation ModelFebruary 8, 2010 at 4:26 AM by cdiscThose of us who started working toward a structured protocol representation in 2003 were motivated by the feeling that there had to be a better way to communicate information about a study than a text document. The protocol is at the heart of clinical research, so it's just not effective or efficient for all the parties involved to extract data from text, often the same piece of data multiple times.
The Protocol Model that was recently published is more abstract than the earlier CDISC interchange standards -- you can't use this standard to write down the information about a particular protocol in a form that someone else will understand. So what good is it?
My experience is that a lot of the work of agreeing on data standards is agreeing on definitions. Often the things that "everyone knows" aren't really that well known, and what one person knows may contradict what another person knows. Also, what people know at a gut level is often hard to articulate. The Protocol Model includes a lot of hard-won definitions. They don't show up in those UML diagrams, but they a big part of the standard. If you want to dip into the Protocol Model, I suggest browsing the definitions. Do they make sense to you? It could be that you recognize a concept, but it's got a somewhat different name than the one you would have used.
The other thing that the Protocol Model does is clarify the relationships between pieces of data. In my day job, I had a recent example of confusion about relationships. There was a question about whether we needed both a "center ID" and an "investigator ID." It turns out that we do, because there are cases where one investigator participates in a study at two different institutions or where two investigators participate in a study at the same institution. These are the kinds of questions that have been thought through and documented in the associations in the Protocol Model.
The abstract Protocol Model is a significant step toward what I really dream of -- applications that handle protocol information as data, and interchange standards that allow those applications to share and re-use the information.
The interchange standards are coming. The SDTM trial design datasets provide a format for a small subset of the protocol information. The CDISC xml Technologies team has a draft of a study design extension for ODM and plans for developing a protocol extension. The Clinical Trial Registration and Results (CTR&R) project at HL7 has used the BRIDG Model, of which the Protocol is a subset, in order to build a message that can, in future, be used to register trials, e.g., with clinicaltrials.gov, EudraCT & WHOICTRP. The message development was fast because the information model already existed.
The applications are coming, too. A domain analysis model like the Protocol Model is a great springboard for software developers, who can use it to understand data requirements. When you talk to vendors about their products, ask them whether they have the capability to export or import data based on the Protocol Model, and whether they are looking to use one of the developing interchange standards to do so.
My dream hasn't come true yet, but I can see that it's much closer, and much more concrete than it was. For me, the release of the Protocol Model is definitely worth celebrating.
Diane Wold Manager, Data Standards GSK Tags: SDTM, Protocol, ODM, CTR&R BRIDG,
Email Post Comments |
  |
Lakshmi Grama