Memories and Musings About Models

When I was a boy, my mother once had a job working at a model factory. This was a geek kid's ideal, because she'd periodically bring home a puzzle activity treat in a box that would keep me enthralled for days, weeks or even months.

Over the course of her employment she brought me home an armada of modern and classic weaponry, a bedroom-sized lot full of vintage sports cars, and-on one memorable occasion-the piece de resistance in those modest, simpler days: a surprisingly discreet "Visible Woman." Many a kid in my day were fascinated by models, because we could not be certain we'd ever get a chance to see the real thing (well, at least for some of that classical weaponry anyway).

These models consisted of kits full of plastic parts, which kids like me would assemble with model glue. You could tell we were focused and innocent in those days, because we used the glue sparingly to build the models rather than for other inconceivable recreational purposes (though it did have quite an attractive smell now that I think of it). After your first few tries, you'd graduate beyond glue alone and invest in a set of enamel paints to add the finishing touches to make the monotone models look more realistic (except for those pesky, unintended glue fingerprints and drips of course).

These models were made to create a scale replica of something real-and something really cool to show off and play with, if you were a kid. (Yes, this was in ancient times, before the Internet. My son's modeling stage was rapidly subsumed by video games.)

Later, in college, I started working with other types of scale models, such as the model stage sets I designed for my theatre classes and productions, or the whimsical buildings I imagined when contemplating a dream of becoming an architect. These types of models didn't scale down something that already existed to toy size but were a way to represent an idea in three dimensions. Of course, we had to build these out of cardboard, papier-mâché, and balsa wood in those days. Today, for a modest investment (probably less than I spent on all of my hobby materials), one can allegedly buy a three dimensional printer that can render a plastic model from a concept depicted on a computer screen. Oh, to be a geeky kid now.

Now that I've put away (most of) my childish things, in my real life world of systems and technologies for drug development, we have a need-and increasingly available options-for models of another type. These are the models we design to depict the world we know and guide the development of system applications we need. In a sense, these models fall somewhere between the other two types I experienced in my youth-they try to represent the world we already know as a two dimensional illustration, and they also depict an ideal framework in which to represent the world we want to create.

These are thought-provoking, complex models generally expressing the input of many business and technology experts. They might not be quite so amusingly easy to build, but they do have better uses for a bigger audience. And they're becoming an indispensable part of the processes we use to define standards and systems.

A lexicon of relevant models

You can get a lot of different answers when you ask about models. A Chief Technology Officer may talk about Model Driven Architecture (MDA), which is a method for designing software systems developed by the Object Management Group (OMG). A programmer may advocate Model Driven Development (MDD), an agile programming technique that uses tools to generate code from models.

Both of these probably fall under the umbrella of Model Driven Engineering (MDE). To fully exploit such models in making the transition from concept to implementation, it's necessary to represent the model in a smart model definition language that can be used to generate specifications or even code, such as the Unified Modeling Language (UML). It's difficult to see where the differences, if any, lie between terms like MDA, MDD, and MDE. Instead, it's probably safer just to think about where models are used in our industry.

Since clinical research is composed of a series of well-defined processes, often governed by regulatory requirements and standard operating procedures, many of us are familiar with process models such as use cases, flowcharts, and activity and state diagrams. Busy people tend to get buried in the weeds when they do their daily tasks, and business process models help them to step back, see the bigger picture, and identify inefficiencies and improvements.

Within the world of standards, Health Level 7 (HL7) has based its development process on the Reference Information Model (RIM), which is a master model for depicting how the world of health care works and a fundamental organizing principle behind HL7's goals of achieving interoperability.

Since the RIM is a very abstract model, it's more suitable for the technical elite rather than the layperson. So we use domain models to represent the world in terms more familiar to the rest of us.

Models for the rest of us

That brings us to the Biomedical Research Integrated Domain Group Model for protocol-driven research, or BRIDG. The first BRIDG model was initially drafted by a core, cross-functional group of subject matter experts from CDISC, and it later evolved into a collaborative effort involving CDISC, the National Cancer Institute (NCI), HL7, and the FDA. BRIDG is a model that is intended to be understood by subject matter experts and participants in clinical research that describes their world. Eventually, almost everything we need to do in clinical research is likely to be represented at some level in BRIDG.

It's nice to know that models such as BRIDG exist, and that they may be playing a key part in guiding the development of standards. But what can they do for you?

Well, using a model like BRIDG can be invaluable when designing an information architecture or defining a standard, or even building an application. And the bigger the project, the more essential a model is. Even within our own companies, we often find that the medical professionals and statistical analysts have trouble getting on the same page with the regulatory and technology people. There are very few individuals who can interrelate comfortably with all these different players. Using models like BRIDG help verify that all parties are speaking the same language, which makes it all the more likely that systems and information will be able to interoperate more efficiently. And an outsider with specialized technical skills but no research experience can rapidly develop a more thorough understanding of our business by walking across the BRIDG.

BRIDG is not everything-in fact, the latest version of BRIDG was adapted so it could represent its concepts not only in domain-friendly terms but also in a way that is fully compatible with the HL7 RIM. Defining actual working business processes and new system applications or data models will still be necessary after BRIDG-but these efforts can be dramatically reduced while avoiding later disconnects. BRIDG should provide a starting point for developing any new data standard or expressing any new concept relevant to research processes, or for developing or implementing any new clinical application.

We wouldn't try to navigate a strange city on our own without a good map, and we shouldn't be trying to develop an information infrastructure or application without at least consulting the BRIDG. We gain even more if we download the relevant concepts and data elements from the BRIDG to initialize the entire development process before getting into the unique, company-specific details.

So in our complex world, which is growing more tightly integrated and interdependent all the time, it's clear that we need to depend a lot more on models. We simply can't afford to depend on dense specification documents that must be interpreted by subjective human beings to keep up with the rapid changes to systems, standards, and information. And we need to be using the same models if we expect to consistently exchange and share the information we need to compete in our increasingly challenging world.

So, fellow retired hobbyists, it's time to pull out those old modeling tools once again. You need to cross that BRIDG to get to the other side.

Editors Note: Users can access the BRIDG at http://bridgmodel.org/

Wayne R. Kubick is Senior Vice President and Chief Quality Officer at Lincoln Technologies, Inc., a Phase Forward company based in Waltham, MA. He can be reached at wayne.kubick@phaseforward.com.