Issuu on Google+

The Protocol Representation Model Version 1.0

Prepared by:

The Protocol Representation Group (PRG)

Š CDISC, 2009

29/April/2009


CDISC Protocol Representation Model

Protocol Representation

Revision History Document Number

Release Date

Updates

Version 1.0

16/April/2009

First version for public comment.

Version 1.01

29/April/2009

Updated model diagram and List of Classes, Attributes, and Their Definitions to include additional classes left out of original document.

CDISC, Inc. 15907 Two Rivers Cove, Austin, Texas 78717 http://www.cdisc.org Š Copyright 2009 by CDISC, Inc. All rights reserved. No part of this publication may be reproduced without the prior written consent of CDISC. CDISC welcomes user comments and reserves the right to revise this document without notice at any time. CDISC makes no representations or warranties regarding this document. The names of actual companies and products mentioned herein are the trademarks of their respective owners. CDISCŽ and the CDISC logo are trademarks or registered trademarks of CDISC, Inc. and may be used publicly only with the permission of CDISC and require proper acknowledgement. Other listed names and brands are trademarks or registered trademarks of their respective owners.


CDISC Protocol Representation Model

Protocol Representation

Table of Contents Prepared by: ................................................................................................................................................ 1  1.0 

List of Acronyms ............................................................................................................................ 2 

2.0 

Purpose of This Document ............................................................................................................ 2  2.1  Who are the intended readers? ............................................................................................... 2  2.2  What will readers get from this document? ........................................................................... 2 

3.0 

Introduction to the Protocol Representation Model (PRM) v1.0 .............................................. 2  3.1  What is the protocol representation model (PRM)? ............................................................... 2  3.2  Why is the PRM important? ................................................................................................... 5  3.3  Why is the PRM represented as a UML diagram? ................................................................. 6  3.4  How is the PRM related to other models?.............................................................................. 6  3.5  When and how was it developed? .......................................................................................... 7  3.6  Who was (or is) involved? ..................................................................................................... 8 

4.0 

Introduction to Basic UML Concepts and Terms ....................................................................... 9  4.1  What is UML? ........................................................................................................................ 9  4.2  What type of UML diagram is the PRM based on? ............................................................... 9  4.3  What is a class diagram? ........................................................................................................ 9 

5.0 

The Complete Protocol Representation Model in UML........................................................... 14  5.1  How should I read this diagram? ......................................................................................... 16  5.2  Why do the rectangles have different colors? ...................................................................... 16 

6.0 

Protocol Representation Model v1.0 – List of Classes, Attributes, and Their Definitions .... 17  6.1  Major Classes and Associated Attributes ............................................................................. 17 

7.0 

Representations and Warranties, Limitations of Liability, and Disclaimers ......................... 95 

8.0 

Appendix ....................................................................................................................................... 96  Appendix A: References ................................................................................................................ 96 

1

© CDISC, 2009 Version 1.0

iii

29/Apr/2009


CDISC Protocol Representation Model

2

Protocol Representation

1.0 List of Acronyms ASPIRE

Agreement on Standardized Protocol Inclusion Requirements for Eligibility

BRIDG

Biomedical Research Integrated Domain Group

®

caBIG

cancer Biomedical Informatics Grid

CDA

Clinical Document Architecture

CDISC

Clinical

CRA

Clinical Research Associate

CRF

Case Report Form

EMEA

European Medicines Agency

EudraCT

European Union Drug Regulating Authorities Clinical Trials

FDA

U.S. Food and Drug Administration

HL7

Health Level 7

ICH

International Conference on Harmonisation

IHE

Integrating the Healthcare Enterprise

IRB

Institutional Review Board

NCI

National Cancer Institute

PR

Protocol Representation

PRG

Protocol Representation Group

PRM

Protocol Representation Model

PSC

Patient Study Calendar

RCRIM

Regulated Clinical Research Information Management

SAP

Statistical Analysis Plan

SCTP

Structured Clinical Trial Protocol

SDTM

Study Data Tabulation Model

TDM

Trial Design Model

UML

Unified Modeling Language

WHO

World Health Organization

© CDISC, 2009 Version 1.0

2

29/Apr/2009


CDISC Protocol Representation Model

Protocol Representation

3

2.0 Purpose of This Document

4 5 6 7 8

The purpose of this document is fourfold: to describe what the Protocol Representation Model (PRM) Version 1.0 is, explain why it is important, show how it relates to the BRIDG and other relevant CDISC models, and give guidance on how to read it. Hence, the document’s purpose is to inform readers of the concepts and benefits of the PRM in the context of clinical research, and is intended as a first phase rollout for public comment. Plans for future development of an implementation guide are being made.

9

2.1 Who are the intended readers?

10 11 12 13 14 15 16 17 18 19 20 21

The intended readers of this document include a broad range of personnel involved in the planning, development, support, conduct, administration, operations, and ongoing maintenance of clinical research protocols, such as clinical program managers/directors, project managers, monitors/CRAs, medical writers, clinical data managers, system implementers, software developers, statisticians, data capture designers, and protocol authors. As much as possible, the content has been developed and presented so as to be comprehensible to a variety of readers at different levels of expertise. At the same time, the document assumes a basic knowledge of certain concepts in clinical research and information technology. For example, a working understanding of terms and concepts such as “clinical data standards,” the “Biomedical Research Integrated Domain Group (BRIDG)” “machine readable,” “protocol,” “UML” and “XML” will make it easier to comprehend the concepts and benefits behind the PRM. To gain a better understanding of some these key concepts, see Section 3.4.1 for information on the relationship between the PRM and BRIDG, and Section 4.0 for an introduction to basic UML concepts.

22

2.2 What will readers get from this document?

23

As a result of reading this document, readers should be able to:

24 25 26 27 28 29

• • • • •

30

3.0 Introduction to the Protocol Representation Model (PRM) v1.0

31

3.1 What is the protocol representation model (PRM)?

32 33 34 35 36 37 38 39 40

The PRM v1.0 is a clinical data standard that identifies, defines, and describes a set of over 300 common protocol elements, and maps those elements to the elements within the Biomedical Research Integrated Domain Group (BRIDG) model. The BRIDG is a comprehensive domain analysis model representing the domain of protocol-driven research and its associated artifacts and processes. (You can find more information on the BRIDG at www.bridgmodel.org. Also, the relationship between the PRM and BRIDG is further explained below in Section 3.4.1.) The PRM elements were developed so that protocol information could be reused and repurposed across multiple documents, databases, and systems from study start-up through reporting and regulatory submissions. So far, there are four major components of the PRM v1.0—that is, four major areas of a protocol that the elements are related to:

41 42 43

Explain to others what the PRM is Explain why the PRM is important and what its advantages are Explain how the PRM relates to other CDISC or HL7 models Gain a foundational understanding of UML in order to read the PRM Begin to understand how the model can be used for specific purposes, software applications, and database designs

Clinical Trial/Study Registry: Elements related to the background information of a study, based on the requirements from WHO and Clintrials.gov. Examples of elements in this area include Study Type, Registration ID, Sponsors, and Date of First Enrollment.

© CDISC, 2009 Version 1.0

2

29/Apr/2009


CDISC Protocol Representation Model

Protocol Representation

44 45

Eligibility: Elements related to eligibility criteria such as minimum age, maximum age, and subject ethnicity.

46

Study Design Part 1: Elements related to a study’s experimental design, such as Arms and Epochs.

47

Study Design Part 2: Elements related to a study’s Schedule of Events and Activities.

48 49 50

Additional components of the PRM are being planned for future development, in order to target other parts of the protocol such as the Statistical Analysis Plan (SAP). The PRG will announce updated versions of the PRM as they become available.

51 52 53

3.1.1

The PRM and the PR Elements Spreadsheet

The PRM first began as a spreadsheet of elements known as the PR Elements Spreadsheet. A sample of the spreadsheet is shown in Figure 1 below. (It is also posted separately on the CDISC web site.) Definition Source indicates the glossary, dictionary, or other source where the element definitions come from

Section hierarchy groups the elements based on ICH.

Element Names are the names of the common protocol elements identified by the PRG.

BRIDG Mapping indicates the name of the BRIDG element to which each PR element is mapped.

Figure 1: Partial view of PR Elements Spreadsheet. The spreadsheet helps define and elaborate on the common protocol elements, and maps them to corresponding elements in the BRIDG model. 54 55

Within the spreadsheet, the elements are grouped into sections based on a hierarchical structure in the International Conference on Harmonisation (ICH) E6 and E3 guidelines.1 The spreadsheet also includes 1

This was done because the ICH has already prescribed much of the content for regulated clinical research protocols, specifically regarding data elements related to efficacy and safety trials. More information on the ICH guidelines can be found online at http://www.ich.org/.

© CDISC, 2009 Version 1.0

3

29/Apr/2009


CDISC Protocol Representation Model

56 57 58 59 60 61 62 63 64

Protocol Representation

explanations and sources for each element and definition, as well as how each element maps to a specific BRIDG element. The CDISC Glossary was often used as a source for the definitions. (For more information on the CDISC Glossary, see http://cdisc.org/glossary/index.html.) This spreadsheet drove the development of the PRM over time. 3.1.2

The PRM and its representation in the BRIDG model

The group responsible for developing the PRM, the Protocol Representation Group (PRG), harmonized the elements of the PR Elements Spreadsheet with the BRIDG model—i.e., they mapped the elements from this spreadsheet to appropriate elements within the BRIDG model. A sample view of some PR elements and their counterparts in the BRIDG UML model is given below in Figure 2. Class

This PR element … … is mapped to this BRIDG element.

65 66 67 68 69 70

Relationship or “association”

This PR element … … is mapped to this BRIDG element.

Attributes

Figure 2: Sample view of how the PRM is actually a subset of the BRIDG model. Note that the white tags are not actually part of the model, but are used to show the mapping between the elements of the PRM and the elements of BRIDG. If the PRG did not find a corresponding element in BRIDG, they created a new one. This resulted in representing the elements of the PRM in a UML, because the BRIDG model is currently represented as UML class diagram. Although the UML diagram may look complex, it is relatively easy to read once you have a working knowledge of UML basics. (An overview of UML basics is provided in Section 4.0.) In the sections that follow, more information is provided on the historical development of the PRM, as well as how to read and interpret the PRM as represented in UML.

© CDISC, 2009 Version 1.0

4

29/Apr/2009


CDISC Protocol Representation Model

Protocol Representation

71

3.2 Why is the PRM important?

72 73 74 75 76 77 78

The primary motivation for developing the PRM grew from the recognition that the protocol is the core to every clinical research study. The protocol is used in designing the study, selecting investigative sites, developing the data collection tools, and describing the study procedures and the analysis plan. Institutional Review Boards (IRBs) use the protocol as the basis for approving whether a study can be initiated. A well-constructed protocol should ensure common understanding of the study objectives and procedures to be implemented, thereby improving quality and saving time and effort for those using it. Clearly, it is one of the most important documents used in clinical research.

79 80 81 82 83

However, the development of a protocol can consume significant company resources and time, particularly when the review group is large or the review process is complex. Leveraging technology can streamline aspects of this process and/or be used to evaluate the integrity within a protocol before it is finalized. However, to develop such an application requires that at least certain portions of the protocol are “machine-readable” as well as “human-readable,” and implies some commonality across all protocols.

84 85 86 87 88 89 90

The PRM provides such commonality. Specifically, it provides a common structure for protocols and streamlines the creation, maintenance, sharing, and reuse of a protocol by breaking it down into standard, machine-readable “chunks” or components of text that can be electronically stored (e.g., in a database). These components can then be updated, shared across disparate systems, and maintained independently of each other. The practical benefit is that it becomes less time consuming and expensive to develop and maintain a protocol, and downstream systems, like CRF and SAP creation and Supply Ordering, can be supported with consistent and accurate information.

91 92 93 94 95 96 97

Furthermore, the PRM helps address the sheer volume of information generated within the biopharmaceutical industry in the form of documents such as protocols, investigator brochures, and statistical and data management plans. As these documents become more numerous and complex, it grows increasingly difficult to search for and find information within and across them, let alone reuse information within them effectively. Transcribing such documents into other documents or databases remains a highly manual, time-consuming process, even though organizations use templates to promote consistency. This is because the key information within most documents is buried in paragraphs of text.

98 99 100 101 102 103 104 105 106 107

However, by defining the standard sections, sub-sections, and elements of a protocol, the PRM brings structure to a protocol, and makes it much easier to find key elements that are usually hidden within the lengthy textual descriptions. Essentially, the PRM extracts and labels these key elements so they can be searched and read by a computer. Once this is done, protocol information can be readily entered into an information system or online registry that allows key protocol information to be searched, shared, analyzed, reported on, and reused. This would support a range of important clinical research goals, such as increasing transparency in clinical research, providing patients with the ability to find studies in which they are eligible to participate, adhering to study registry requirements, populating study management/tracking systems, sending information to IRBs or Ethics Committees, providing FDA with Study Summary and Study Design information, and writing post-study clinical reports.

108 109

Implementations of the model itself have already occurred in the areas listed below. The star (*) indicates which are in production. All others are under development.

110 111 112 113 114

• • • • •

CDISC SDTM standard* CDISC ODM Study Design extension HL7 Clinical Trial Registration and Results message HL7 Study Design message (in development) caBIG® Patient Study Calendar (PSC) application*

115

© CDISC, 2009 Version 1.0

5

29/Apr/2009


CDISC Protocol Representation Model

116 117

• •

Protocol Representation

ASPIRE (Agreement on Standardized Protocol Inclusion Requirements for Eligibility) IHE Retrieve Protocol for Execution profile

118

3.3 Why is the PRM represented as a UML diagram?

119 120 121 122 123 124 125 126 127 128 129

The PRM is represented in UML because the PRM is closely linked with the BRIDG modeling effort. As the PRM and BRIDG models evolved in parallel, people involved in both efforts decided it would be best to represent the PRM elements within the BRIDG model, which was being developed in UML. (More information on this evolution is provided in Section Error! Reference source not found..) As a robust modeling tool, UML has several advantages over a spreadsheet. First, UML provides a standard set of notation elements—e.g., standard lines, shapes, symbols, numbers, etc.—to specify how parts within a system are related to each other. Secondly, in addition to showing hierarchical relationships between elements and objects, UML can show many other kinds of relationships such as multiplicity, inheritance, unidirectional relationships, and so on (concepts that are explained in more detail in Section 4.0). So in addition to creating a spreadsheet of elements, the PRG took the elements and represented them visually in a class diagram using UML.

130

3.4 How is the PRM related to other models?

131 132 133 134 135

The PRM contains elements that relate to other models and information elements within the clinical study life cycle. For example, as stated earlier, elements within the PRM map to elements within the BRIDG model. This section explains how the PRM is related to the BRIDG model, the CDISC Study Data Tabulation Model (SDTM), CDISC Trial Design Model (TDM), the HL7 Study Design Message (in progress), and the HL7 Clinical Trial Registration and Reporting Message (in progress).

136

3.4.1

The PRM’s relationship to BRIDG

137 138 139 140 141 142 143

In order to understand the relationship between the PRM and the BRIDG, some background information on the BRIDG may be warranted for readers who are unfamiliar with the purpose of BRIDG. The BRIDG model is distinct from the other CDISC models in that it is a formal model of the shared semantics of regulated bio-medical research. The BRIDG is developed and maintained by an open community of stakeholders who include CDISC, HL7 Regulated Clinical Research Information Management (RCRIM) Workgroup, the National Cancer Institute (NCI), cancer Biomedical Informatics Grid (caBIG®), and the U.S. Food and Drug Administration (FDA).

144 145 146 147 148

The aim of the BRIDG Project is to have a shared view of the data, relationships, and processes which collectively define the domain of clinical and pre-clinical protocol-driven research and its regulatory artifacts. In other words, BRIDG is a communication tool for bringing together a variety of stakeholders, and for bridging medical research experts from standards development organizations, government organizations, academia, and the biopharmaceutical industry.

149 150 151 152 153

Starting in 2004, CDISC initiated the BRIDG model activity based upon recommendations from an HL7 expert asked to evaluate the best strategy for ensuring a link between CDISC standards for clinical research and the healthcare standards of HL7. The purpose of the BRIDG model was to create a domain analysis model for clinical research—one that domain experts could comprehend, not just those who had technical expertise in HL7.

154 155 156 157 158

Not long after the BRIDG modeling was begun, with the protocol at its center, the NCI expressed interest in collaborating on this model development. The BRIDG model was actually transformed by focusing specifically on incorporating elements from the PR Elements Spreadsheet and representing them in the BRIDG. As of 2009, most of the elements of the PR Elements Spreadsheet—along with their attributes and appropriate relationships—have been represented in the BRIDG model.

© CDISC, 2009 Version 1.0

6

29/Apr/2009


CDISC Protocol Representation Model

159 160 161 162 163 164

3.4.2

Protocol Representation

The PRM’s relationship to CDISC SDTM

The PRM contains elements from the CDISC Study Data Tabulation Model (SDTM), specifically the Trial Design Model (TDM), which is a subset of the SDTM. Additionally, when the PRM was first being developed, the Protocol Representation Group referenced elements from the Study Summary component of the SDTM in the Clinical Trial Registry portion of the PRM. 3.4.3

The PRM’s relationship to the HL7 Study Design Message

165 166

The Trial Design component of the PRM provides the standard content for the HL7 Study Design message, a transport standard which is currently under development and not yet approved.

167

3.5 When and how was it developed?

168 169 170

The PRM has undergone a series of phases to arrive at its current version. The following summary describes in broad strokes what was involved in the model’s evolution, and will help you understand why the PRM is in the form it’s in today.

171 172 173 174 175

1. The Protocol Representation project was launched in 2002 as an HL7 and CDISC joint project. A group of experts and representatives from various organizations and CDISC member companies was formed (i.e., the Protocol Representation Group, or PRG) to develop the model. See Section 3.6 for a list of the organizations who have contributed active participants/resources to the PRG since 2002.

176 177 178 179 180 181 182

2. Over the years, through a series of meetings, discussions, conferences, and strategic planning efforts, the PRG first created a spreadsheet of common protocol elements, later called the PR Elements Spreadsheet. (You can see the most up-to-date version on the CDISC web site. It is titled “PRM – BRIDG Mapping 15 April 2009.”) The section headers in the spreadsheet reflect those from the ICH E6. Sub-sections and then elements were added. The elements were derived from other regulatory authorities worldwide such as EudraCT (European Union Drug Regulating Authorities Clinical Trials).

183 184 185 186 187

3. The PRG further elucidated each element with a glossary definition, source of the element (e.g., ICH, EudraCT), suggested code lists and attributes, cardinality, use case application, and other relevant information. The PR Elements Spreadsheet was first posted in 2004 and an updated version was posted in 2005. Figure 3 below provides an abstract view of how these elements were organized in the spreadsheet.

Figure 3: Abstract view of the sections, sub-sections, and elements of the PR Elements Spreadsheet. © CDISC, 2009 Version 1.0

7

29/Apr/2009


CDISC Protocol Representation Model

Protocol Representation

188 189 190 191 192 193 194

Using this hierarchical structure, the PRG was able to develop an extensive protocol glossary and create a structured clinical trial protocol. In this way, the PRM moves a protocol’s “unstructured” information from a Word document or PDF and formats it into a series of data fields with attributes and relevant relationships, thereby making it “structured” information. “Structured,” in this context, means that the data elements, and the relationships between them, are defined consistently and unambiguously, and are thus computable (i.e., amenable to automated processing) and will enable semantic interoperability (i.e., exchange of content and meaning).

195 196 197 198

4. The spreadsheet was also used for an initial modeling attempt to develop an HL7 Clinical Document Architecture (CDA) for a Structured Clinical Trial Protocol (SCTP), but the need for an approach that allowed for more structured data was acknowledged. At this juncture, it was decided that the BRIDG model was the better method for developing a PRM.

199 200 201 202 203 204 205 206 207

Why was the BRIDG model considered the better method? One reason is that the advantages of UML were recognized. Developing a spreadsheet for a model is one thing; translating it into a diagram that forms the semantic foundation for software application development, message development, and database design is another. A spreadsheet does a good job of showing hierarchical relationships, but faces limitations in showing other kinds of relationships between elements and objects such as multiplicity, inheritance, unidirectional relationships, and so on (these are UML concepts that are explained in more detail below in Section 4.0). So in addition to creating a spreadsheet of elements, the PRG took the elements and represented them visually in a diagram to describe structure, by using the Unified Modeling Language (UML).

208 209 210

5. The PRG mapped elements from the PRM to appropriate parts of the BRIDG model. As of the first quarter of 2009, the PRG has successfully completed version 1.0 of the PRM, which is a subset of the BRIDG Model.

211

3.6 Who was (or is) involved?

212 213 214 215 216 217 218 219 220

The PRM was initiated as a project by leaders from CDISC and FDA within the HL7 Regulated Clinical Research Information Management (RCRIM) Technical Committee. Medical communication specialists, statisticians, project managers, and other domain experts were recruited from CDISC member companies to augment the initial group and to provide domain expertise, including direct experience with protocol development for regulated clinical research. The resulting group, the PRG, is both an HL7 RCRIM project team and a CDISC team. Additionally, it now includes representatives from the NCI, caBIG®, the World Health Organization (WHO), and 'observers' from FDA and EMEA. It is therefore a multidisciplinary effort, representing the major types of stakeholders in clinical studies. The following organizations have contributed active participants/resources to the PRG since 2002: Bayer Healthcare Beardsworth Consulting Boehringer-Ingelheim Booz Allen Hamilton CDISC City of Hope Digital Infuzion Eli Lilly and Company EMEA FDA GlaxoSmithKline HP IBM Intrasphere

J&J PRD Medidata (Fast Track) Memorial Sloan Kettering Merck NIH, NCI, caBIG Novartis Novo Nordisk Octagon Research Omnicare Oracle Pfizer PHT Quintiles SAIC

Sanofi-Aventis Sanofi-Synthelabo SAS Seattle Children's TAP Pharmaceutical Products UCB Group UCSF Med Ctr University of Pittsburgh USF WHO Wyeth Zurich Biostatistics Sanofi-Aventis

© CDISC, 2009 Version 1.0

8

29/Apr/2009


CDISC Protocol Representation Model

Protocol Representation

221

4.0

Introduction to Basic UML Concepts and Terms

222 223 224 225 226

The PR Elements Spreadsheet serves as a foundation on which to develop a visual model, namely, a UML diagram depicting structure (class diagram) that is useful for information systems development. For readers who are unfamiliar with UML, a basic introduction to UML concepts is provided in this section. Readers who are familiar with UML can skip ahead to Section 5.0 to see a comprehensive visual representation of the PRM as a UML class diagram.

227

4.1 What is UML?

228 229 230 231 232 233 234

The Unified Modeling Language (UML) is an industry-standard language for specifying, visualizing, constructing, and documenting the requirements of software systems. Through UML, developers can visually describe and represent the components and activities of a system they are creating. This is done by using standard lines, arrows, connectors, shapes, and colors to draw diagrams. Generally speaking, there are two major categories of UML diagrams: structure diagrams and behavior diagrams. Within these categories, there are a variety of diagram types developers can choose from in order to represent the activities of a system.

235

4.2

236 237 238 239 240 241 242 243 244 245 246 247 248 249 250

For the PRM v1.0 modeling effort, the structure diagram category was selected, since the Protocol Representation Group was interested in describing a structure. Within the structure category, there are a variety of other diagram types, such as class diagrams and component diagrams. Of these, the class diagram was chosen to represent the PRM. Why? Because class diagrams are useful for describing the structure, relationships, and characteristics of objects within a system. Figure 4: Hierarchy of UML Diagram Types. The class diagram is the type that was chosen to base on the PRM on.

251

4.3

252 253 254

A class diagram describes the structure of a system by depicting classes, class attributes, and relationships. A “class” is usually an entity that represents a person, place, or thing. See Figure 9 below (on the next page) for an example.

What type of UML diagram is the PRM based on?

What is a class diagram?

© CDISC, 2009 Version 1.0

9

29/Apr/2009


CDISC Protocol Representation Model

255 256 257 258 259 260 261 262 263

Protocol Representation

The diagram shows there is a class called Employee. An Employee has certain attributes (e.g., a “name”) and can perform certain functions. Classes are, moreover, represented as boxes or rectangles, as depicted by the yellow boxes in the figure below. Each class has three compartments: the top compartment contains the class name, the middle compartment contains one or more attributes, and the bottom compartment contains the class’s operations. (“Operations” are not shown here, since none of the classes in the class diagrams for the PRM show operations.) Also, classes are often related to each other in some way. Such relationships are depicted by different types of lines connecting the classes (i.e., “relationships” or “associations”), and multiplicity values tell you about the numeric aspects of that relationship.

264 Class name: In this diagram, there are two class names: Employee and Company. Both classes can include multiple attributes.

Relationship: Known more formally as an “association,” a relationship is a line connecting classes. As we’ll see below, there are several kinds of associations.

Employee

Attribute: An attribute is a descriptive feature of a class, depicted as being contained within the class.

Company

-name : String

-name : String 1..*

1 Multiplicity Values: Values that indicate a numeric relationship between objects in a class diagram. As we’ll see below, the values have specific meanings that say a lot about how the objects relate to each other.

Figure 5: High-level overview of the parts of a class diagram. 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280

What is this diagram communicating? Several things. First, it’s saying that both instances of the classes called Employee and Company have the attribute “name.” Furthermore, the diagram says there is certain kind of relationship between Employee and Company. Specifically (and we’ll explain this more below), the line connecting the classes is bi-directional, which means that both classes are aware of their relationship; that is, the relationship goes two ways. You’ll notice a few other things like the numbers of the multiplicity values and the word “String,” but don’t worry about them now. We’ll address them below. 4.3.1

Attribute names and data types

Let’s look more specifically at the chief characteristics of a class’s attributes, since this will help immensely in being able to read the PRM information that is in the BRIDG model. As explained above, every class has a class name, and each class has one or more attributes. Most attributes have at least three parts: one, an attribute name; two, an attribute type; and three, a visibility mark, represented by a sign such as the plus (+) or minus (-) sign in front of the attribute name. The plus sign indicates that the attribute is “public,” and the minus sign indicates that it is “private.” Other marks can be used to indicate whether the attribute is “protected” or “package,” but the BRIDG UML model doesn’t use them.

© CDISC, 2009 Version 1.0

9

29/Apr/2009


CDISC Protocol Representation Model

Protocol Representation

281 Class name

A visibility mark is in front of the attribute name, and tells you whether the attribute is public, private, protected, or package. The plus sign here means that this attribute is “public.”

Employee +name : String

The attribute type (a.k.a. “data type”) is a unit or value that tells you how the attribute is expressed. “String” means alphabetical characters.

Attribute name

Figure 6: Anatomy of a UML class and its parts. 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298

What does this particular class tell us? First, the plus sign tells us the “name” attribute is public. In fact, in the PRM, all elements are public, so the only visibility indicator you will encounter in the PRM v1.0 is the plus (+) sign. What does the attribute type “String” mean, though? “String” in particular means that the name attribute must be represented as a set of alphabetical characters. For example, an employee’s name could be “Julia Roberts,” and can’t contain any numbers. Of course, there can be other attribute types such as “integer” (i.e., numbers only) and “Boolean” (i.e., truth or false), as shown in the next example. Together, this group of attributes makes up what is called an “attribute list” for a class. To apply these concepts, let’s look at a specific example of a class from the BRIDG model. The class we will examine is the StudyProtocol class. 4.3.2

Example of an attribute list of a class from the PRM

The StudyProtocol class, shown on the next page in Figure 7, is one of the most important classes in the PR model. Let’s use our newly-gained knowledge of attributes to interpret what it says. (See next page.)

© CDISC, 2009 Version 1.0

10

29/Apr/2009


CDISC Protocol Representation Model

299 300 301 302 303 304 305 306

Protocol Representation

First, notice that each attribute has a plus sign next to it, meaning that all the attributes are “public.” Second, take a look at the attribute names. Many of them, such as accrualReportingMethodCode and subjectTypeCode, are pretty self-explanatory to people working in clinical research. The former is a coded value used to represent format on how subject accrual data should be reported back to the study sponsor (e.g., as “complete” or “abbreviated”). The latter is a coded value used to represent the target entity of the study of investigation. For example, in a clinical study, the subject type would be “human,” but in other studies it could be animals such as “rats” or “mice.” This title shows which version of the BRIDG model the class is from.

Class name

The “CD” data type stands for “code.” A code can be a numeric or alphanumeric value.

The “BL” data type stands for “Boolean,” which means the data will be either “True” or “False.”

The “SET” data type means you can have a limited set of distinct values to choose from. In this case, the user would be able to choose from a set of country codes.

This italicized word indicates that the StudyProtocol class is getting attributes from another class. This is known as “inheritance.” Don’t worry about it for now. We’ll address it below.

Figure 7: Example attribute list of the StudyProtocol class.  307 308 309 310 311 312 313 314 315 316 317 318

Next, notice that each attribute has a corresponding attribute type, or data type. These types are all based on HL7 version 1 Data Types Specification, which can be found on the HL7 web site, http://www.hl7.org/v3ballot/html/welcome/environment/index.htm.  (Use the navigation tree to go to Foundation, then Data Types.) Each type indicates what kind of data is used to represent the attribute. For example, look at the first attribute in the list, acceptsHealthyVolunteersIndicator. You can imagine that this attribute is designed to answer the question, “Does this protocol accept healthy volunteers?” The answer must be either yes or no. Hence, it makes sense that its data type is BL, or Boolean, which means the data can be expressed as either “true” or “false.” 4.3.3

Different types of associations between classes in a UML diagram

The next important UML concept to know in order to read and understand the PRM is the concept of relationships or associations. There are multiple types of associations between classes: bi-directional,

© CDISC, 2009 Version 1.0

11

29/Apr/2009


CDISC Protocol Representation Model

Protocol Representation

319 320

inheritance, and composition aggregation. While the names sound pretty technical, these are relatively simple ideas, each of which we’ll cover below.

321

Bi-Directional Associations A bi-directional association means that both classes are aware of each other and their relationship. That is, both class are “known” to each other. A bi-directional association is indicated by a solid line between the classes. At either end of the class is a multiplicity value. For example, in the diagram below, the multiplicity value of 0..* next to StudySubject class means that when an instance of StudySite exists, it can have zero or more instances of a StudySubject associated with it. Taken in the context of clinical research, this makes sense. After all, even when a study site is activated, it may take time for the first study subject to be enrolled. Moreover, the number of study subjects associated with a study site should be left open-ended in order to account for variations on each study protocol.

322 323 324 325 326 327 328 329 330

1

0..*

Figure 8: Example of a bi-directional relationship between two classes from the PRM. 331 332 333 334

Conversely, the multiplicity value of 1 next to the StudySite class means that when an instance of StudySubject exists, it can only have one StudySite associated with it. This also makes sense in context, because in a particular study, a study subject is not assigned to more than one treatment location.

335 336

There are, of course, a variety of ways you can designate multiplicity values. A few examples are shown in the table below. Multiplicity Value

Meaning

0..1

Zero or one

1

One only

0..* *

Zero or more Zero or more

1..*

One or more

2

Two only

0..6

Zero to six

5..15

Five to fifteen

337

© CDISC, 2009 Version 1.0

12

29/Apr/2009


CDISC Protocol Representation Model

338

Protocol Representation

339 340 341 342 343

Inheritance Inheritance is the ability of a class to receive or acquire the same exact attributes and functionality of another class, in addition to its own set of unique attributes and functionalities. This relationship is expressed in terms of “parent” and “child.” Take an example from real life: a child may inherit a parent’s brown hair. However, that same child may be the only one in the family to have blue eyes. Likewise in UML, a class may inherit attributes from a parent class but still retain unique attributes of its own.

344 345 346

In the context of UML, inheritance is shown by drawing a solid line from the child to the parent class. At the end of the solid line is a closed, unfilled triangle (or arrowhead) pointing to the parent class. The child class also includes a listing of the parent class’s elements under an italicized heading.

347 348 349

As an example from the BRIDG model, the StudyProtocol class is a “child” to the Document class. This means that, in addition to its unique attributes, the StudyProtocol class receives or acquires the full set of attributes from the Document class.

Parent Class

Inheritance is shown by a solid line with an unfilled triangle pointing to the parent class

Child Class

Unique attributes

Italicized heading indicates which class the inherited attributes are coming from Attributes inherited from the Document class

Figure 9: Example of inheritance within the PRM.

© CDISC, 2009 Version 1.0

13

29/Apr/2009


CDISC Protocol Representation Model

Protocol Representation

350 351 352 353 354 355 356 357

Now consider this relationship in context. “Document” is a generic term that could encompass many kinds of documents. Indeed, all clinical research involves regulatory processes that require the submission of multiple documents from the Applicant to the Regulatory Authority. The Document class is, therefore, an abstract concept that contains attributes common to all types of study documents, such as publicTitle, publicDescription, etc., which should be present no matter what type of document is being developed, whether an adverse event report or autopsy report. A Study Protocol is a specific type of document that falls under the broader category of document. It thus makes sense for the StudyProtocol class to inherit attributes from the Document class.

358 359 360 361 362 363

Composition Aggregation The association known as composition aggregation shows a “parts to the whole” relationship between a parent and a child class. In this relationship, the child class is part of the parent class. Additionally, the child class’s existence depends on the parent class’s existence. If the parent class removed, the child class is automatically removed as well. This relationship is represented by a solid line with a filled diamond shape on the parent class’s association end.

364 365 366

Consider the relationship between the RegulatoryApplication and Submission classes from the BRIDG model. In this diagram, one or more Submission classes are part of the RegulatoryApplication class. There is only one RegulatoryApplication, and if it is removed, then Submission is removed as well. Parent Class

1

Composition aggregation is shown by a solid line with a filled diamond shape pointing to the parent class

1..* Child Class

Figure 10: Example of composition aggregation 367 368 369 370 371 372

As the name implies, the RegulatoryApplication class refers to a collection of submissions that are grouped together for regulatory purposes, and are usually specific to a particular device, food, or feed additive or biopharmaceutical substance. The Submission class refers to any compilation of the contents of one or more submission units that supports a specific regulatory purpose or decision. It therefore makes sense that there is a composition aggregation relationship between these two classes, since a regulatory application in the world of clinical research may consist of multiple submissions.

373

5.0 The Complete Protocol Representation Model in UML

374 375 376 377

The UML diagram below provides a holistic view of the classes, attributes, and relationships of the PRM and its components as represented in the BRIDG model. The diagram is followed by several explanations of how to read and interpret its contents. You can also refer to Section 3.0 for an introduction to UML concepts, which explains some basic UML concepts that will help in deciphering the model.

© CDISC, 2009 Version 1.0

14

29/Apr/2009


CDISC Protocol Representation Model

Protocol Representation

378

Holistic Overview of the Protocol Representation Model

379 class P...

ArmSoA

1 +

«StudyRel ationshi p» DocumentRelationship

identifies events for / has

Legend

referenceTi mePoi ntText: ST 1

0..*

associ ates from / may be the source for

HL7 RIM Enti ty

1

HL7 RIM Role

1 Document

i s authored by / authors

HL7 RIM Participation HL7 RIM Act

1

HL7 RIM Act Rel ationship Placeholder

«StudyRel ationship» DocumentIdentificationRelationship

IdentifiedBiologicEntity

Draft + 0..* + + +

plays / is played by

i denti fi er: II typeCode: CD statusCode: CD statusDateRange: IVL<TS>

associ ates from / i s i denti fi ed by

0..*

1

i denti fies 1 / associ ates to

0..*

+ + + + + + + + + + + +

Arm + + + +

PlannedArm

Busi ness Rul e: T he targetAccrual i n Pl annedArm places a l i mi t on the number of instances of Schedul edArms that can be associ ated to that Pl annedArm

1..*

name: ST typeCode: CD descri ption: ST randomizationWei ghtText: ST

0..*

+ + + + + + + + + + + + + + + + + + +

0..*

associ ates to / may be the target for

associ ates from / may be the source for 1

categori zes / is categori zed by

+ targetAccrualNumber: INT ::Arm + name: ST + typeCode: CD + descri ption: ST + randomizati onWeightText: ST

StudyRelationship

«StudyRel ationshi p» Subj ectStudyEncounterRule

Busi ness Rul e: T he ti mi ng for the SoACell i s handl ed through the Acti vi tyRel ati onship.pauseQuanti ty attribute where the Acti vi ty in the SoACell is rel ated through the Acti vi tyRel ati onship to the Acti vi ty that i s the reference poi nt for the offset in the pauseQuanti ty. Pl ease refer to the TDM instance di agram of the TDM SOA Exampl e for further cl arifi cation.

1

publ i cTi tl e: ST offi ci al Titl e: ST typeCode: CD publ i cDescri pti on: ST sci enti ficDescri pti on: ST keywordCode: SET<CD> keywordText: SET<ST> text: ST revisi onText: ST uni versalResourceLocator: URL bibli ographi cDesignati on: ST languageCode: CD

1

1

contai ns the activiti es for / i s descri bed by

0..* associates to / may be the target for

1

Subj ectStudyEncounter + +

name: ST typeCode: CD 1

typeCode: CD i nversionIndi cator: BL contextControl Code: CD contextConducti onIndi cator: BL sequenceNumber: INT pri ori tyNumber: INT pauseQuanti ty: PQ checkpoi ntCode: CD spli tCode: CD j oi nCode: CD negationIndi cator: BL conj uncti onCode: CD separabl eIndicator: BL subsetCode: CS uncertaintyCode: CD descri ption: ST probabi li ty: REAL eval uabl eExpressi onCode: CD comment: ST

1

1 DocumentIdentification BiologicEntity + + + + +

sexCode: CD bi rthOrder: INT bi rthCountryCode: CD bi rthDate: TS deathDate: TS

+ + + +

BiologicEntityGroup groups / is grouped by

+ 0..* + +

1..*

name: TN typeCode: CD quantity: INT

1..*

1..*

identifi er: II primaryIndicator: BL typeCode: CD assi gnedDate: TS

is issued by / i ssues 0..*

PlannedSubj ectStudyEncounter

1..* Busi ness Rul e: If the Epoch is SCREENING then there are ZERO i nstances of Arm associ ated wi th the StudyCel l. If the StudyCel l has an associati on wi th an Arm i nstance, the Epoch.name canNOT = SCREENING

StudySubj ect

+ speciesCode: CD + breedCode: CD + genderStatusIndicator: BL ::BiologicEntity + sexCode: CD + bi rthOrder: INT + bi rthCountryCode: CD + bi rthDate: TS + deathDate: TS

+ i denti fier: SET<II> + actual Subj ectIndi cator: BL + confidentiali tyIndi cator: BL + paymentMethodCode: CD + subgroupCode: CD + statusCode: CD + statusDateRange: IVL<TS> ::Subject + state: ST

i s assi gned to / i s the treatment l ocation for

+

0..*

plays / i s pl ayed by 1

0..1

+ + + +

0..1

functi ons as / i s represented by

postal Address: AD telecomAddress: SET<T EL> statusCode: CD statusDateRange: IVL<T S>

rol eCode: SET<CD> pri maryIndi cator: BL postal Address: AD tel ecomAddress: SET<TEL> statusCode: CD statusDateRange: IVL<TS>

may be the target for / associ ates to

1

plays / is played by is scoped by / scopes

1..*

i denti fi es the timeslot for / i s pl anned wi thin

0..*

+ plannedDurati on: PQ ::StudySegment + name: ST + descri ption: ST + fi rstStudySegmentIndicator: BL

may be the contai ner of / associ ates to

associ ates from / may be the source for

+ + + + + +

+ + + + + +

Busi nessRule: When a StudySi teContact is a StudySi teInvesti gator, use the HealthCareProvider associ ation rather than the Person associ ation.

rol eCode: CD pri maryIndi cator: BL postal Address: AD tel ecomAddress: SET <TEL> statusCode: CD statusDateRange: IVL<TS>

0..1

functions as/ i s represented by

0..1

0..* StudySiteInv estigator

pl ays/ i s pl ayed by 0..*

0..1

::StudySi teContact + roleCode: CD + primaryIndicator: BL + postalAddress: AD + telecomAddress: SET<TEL> + statusCode: CD + statusDateRange: IVL<TS>

1

+ i denti fier: II + signatureText: ST + dateRange: IVL<TS> ::StudyContact + rol eCode: SET<CD> + pri maryIndi cator: BL + postal Address: AD + tel ecomAddress: SET<TEL> + statusCode: CD + statusDateRange: IVL<TS>

BusinessRul e: For Inteventi onal Studi es, a StudyInvesti gator must be represented by a HealthCareProvider rather than a Person or Cl inicalResearchStaff.

StudyRecruitmentStatus + +

+ + + + +

ResearchOrganization + + +

1

Busi nessRul e: For Inteventi onal Studies, a StudySi teInvesti gator must be represented by a Heal thCareProvi der rather than a Person.

typeCode: CD statusCode: CD statusDateRange: IVL<TS>

1 0..1

functi ons as / i s represented by

HealthCareFacility + + + +

i denti fier: II postal Address: AD statusCode: CD statusDateRange: IVL<TS>

typeCode: SET<CD> primaryIndi cator: BL postalAddress: AD telecomAddress: SET<TEL> statusCode: CD statusDateRange: IVL<TS>

0..1

1

1

Ov ersightCommittee

0..* + + +

0..1

typeCode: CD statusCode: CD statusDateRange: IVL<TS>

oversees / is overseen by

0..*

0..*

i s pl ayed by / pl ays is played by / pl ays

0..*

Busi ness Rule: A StudySi te may be rel ated to ei ther a Heal thCareFaci li ty or an Organization (servi ng as a study si te but i s not a heal thcare faci l ity)

StudySite + + + + + + + + + + +

describes / may have

0..*

1

statusCode: CD statusDate: TS anti ci patedIndicator: BL studyStoppedReasonCode: CD comment: ST

descri bes / has 1..*

1

1

0..*

scopes/ i s scoped by

statusCode: CD statusDate: TS

StudyOv erallStatus

Busi ness Rule: A StudySi teInvestigator can be represented by ei ther a Person or a Heal thCareProvi der but not both.

1

identifier: II leadOrgani zati onIndicator: BL reviewBoardApprovalNumberText: ST reviewBoardApprovalStatusCode: CD reviewBoardApprovalDate: T S targetAccrual Number: INT accrualStatusCode: CD accrualStatusDate: TS dateRange: IVL<TS> statusCode: CD statusDateRange: IVL<TS>

1

1

+ acronym: ST + phaseCode: CD + di seaseCode: SET<CD> + targetAnatomi cSi teCode: CD + pri maryPurposeCode: CD + purposeStatement: ST + desi gnConfi gurati onCode: CD + studySchemati c: ED + al l ocati onCode: CD + confidential i tyCode: CD + popul ationDescripti on: ST + subj ectTypeCode: CD + pl annedStudySubjectExperi ence: ST + acceptsHeal thyVolunteersIndi cator: BL + targetAccrualNumberRange: IVL<INT> + peri odi cTargetAccrualNumber: RTO<INT,PQ> + accrual Reporti ngMethodCode: CD + responsiblePartyCode: CD + /multi Instituti onIndi cator: BL + participatingOrgani zati onTypeCode: CD + participatingCountryCode: SET <CD> + AECodi ngSystem: CD ::Document + publi cT itle: ST + official Ti tl e: ST + typeCode: CD + publi cDescri pti on: ST + sci entifi cDescri pti on: ST + keywordCode: SET<CD> + keywordT ext: SET<ST> + text: ST + revi si onText: ST + universal ResourceLocator: URL + bi bl iographi cDesi gnati on: ST + l anguageCode: CD

1

0..*

groups / is grouped by

+ + + + + + + + +

1..*

1

1

1

pl ays / is played by

Organization i denti fier: SET<II> name: SET<ON> typeCode: CD descri ption: ST postal Address: AD tel ecomAddress: SET<TEL> statusCode: CD statusDateRange: IVL<TS>

plays / i s pl ayed by 0..1

contai ns / i s contai ned i n + 1..* +

descri ption: ST pri maryIndi cator: BL

1

name: ST typeCode: SET<CD> primaryIndicator: BL ti meFrameT ext: ST

1..*

0..* + +

0..1

plays / is played by

0..1

1

1

activeIndi cator: BL i nactiveComment: ST

StudyLegalSponsor +

::StudyResourci ng + acti veIndi cator: BL + inactiveComment: ST

pl ays / i s pl ayed by 1

0..*

pl ays / is pl ayed by

functi ons as / is represented by

Laboratory +

i denti fier: II

1

+ +

name: ST acronym: ST

+ grantNumberT ext: ST + seri al Number: INT + fundi ngMechanismCode: CD + ni hInsti tuteCode: CD + fundi ngT ypeCode: CD + suffi xGrantYearText: TS + suffi xAmendment: ST + suffi xSupplement: ST + suffi xAl lowance: ST ::StudyResourci ng + acti veIndicator: BL + i nacti veComment: ST

0..*

StudyOv ersightAuthority

Ov ersightAuthority

0..*

oversees / i s overseen by

0..*

0..* RegulatedProduct + + + +

RegulatoryAuthority + + +

1

approval Identi fi er: SET<II> authori zati onT ypeCode: CD approval StatusCode: CD expandedAccessStatusCode: CD

RegulatoryApplicationSponsor

1

scopes / i s scoped by

+ 1..* +

statusCode: CD statusDateRange: IVL<TS>

0..* 0..*

j urisdi ctionCode: CD statusCode: CD statusDateRange: IVL<T S>

BiologicSpecimen Material i s pl ayed by / pl ays

+ + + + + +

identifi er: SET<II> name: SET<TN> descripti on: ST formCode: CD statusCode: CD statusDateRange: IVL<TS>

PlannedProcedure NOT E: The numberOfInterventi onGrou ps attribute may be deri vabl e once we redi scuss the issue of Trial Desi gn.

+ methodCode: CD + approachSi teCode: CD + targetSiteCode: CD + targetSiteCondi ti onCode: CD ::Pl annedActi vi ty + name: SET<ST> + actualIndi cator: BL + conti ngentIndicator: BL + studyFocusIndicator: BL + inStudySegmentPl annedActi vi tyTypeCode: CD + additional DurationDescripti on: ST + pl annedRangeOfRepeti tionsText: ST ::Acti vi ty + identifi er: II + nameCode: CD + textDescripti on: ST + categoryCode: CD + subcategoryCode: CD + reasonCode: SET<CD> + statusCode: CD + statusDateRange: IVL<TS> + comment: ST

Gov ernmentFunding

plays / i s pl ayed by

controls / is controll ed by

1

pri maryIndi cator: BL

PerformingLaboratory

0..1

1

functi ons as / i s represented by

1

::StudyResourci ng + acti veIndi cator: BL + inactiveComment: ST

0..1

Registry

pl ays / is pl ayed by 0..1

0..*

i s responsible for / i s the responsibil ity of

NonMonetarySupport

FoundationFunding

0..1

1

1

is the resource for / is resourced by

1

::StudyResourci ng + acti veIndicator: BL + inacti veComment: ST

0..*

0..*

1

primaryIndicator: BL

IndustryFunding

operates as / represented by

1

StudyResourcing

+

+ +

provi des / i s provi ded by

StudyResourceProv ider 1 0..*

Busi ness Rule: A ResourceProvider can be pl ayed by onl y a Organi zati on or Heal thCareProvi der, not both.

LegalSponsor 0..1

scopes / is scoped by

1..*

responsi bi li tyCode: SET<CD> tel ecomAddress: TEL

operates as / represented by

ResourceProv ider

Busi ness Rul e: A Legal Sponsor can be pl ayed by only a Organi zati on or HealthCareProvi der, not both. 0..1

1

Busi ness Rul e: For bl i ndedRol eCode, the rol es i denti fi ed map to StudySubject, StudyInvestigator, Assessor, and Associ atedPerson.

0..* BRIDG Release 2.1 -- Static Classes:: StudyCoordinatingCenter

plays / i s pl ayed by 1

identifi er: II statusCode: CD statusDateRange: IVL<TS>

::Materi al + i denti fi er: SET<II> + name: SET<TN> + descri ption: ST + formCode: CD + statusCode: CD + statusDateRange: IVL<TS>

Interv entionalStudyProtocol

Observ ationalStudyProtocol ExpandedAccessStudyProtocol ::StudyProtocol + acronym: ST + phaseCode: CD + di seaseCode: SET<CD> + targetAnatomi cSi teCode: CD + pri maryPurposeCode: CD + purposeStatement: ST + desi gnConfigurati onCode: CD + studySchemati c: ED + al l ocati onCode: CD + confidentiali tyCode: CD + popul ationDescripti on: ST + subj ectTypeCode: CD + pl annedStudySubjectExperi ence: ST + acceptsHeal thyVolunteersIndi cator: BL + targetAccrualNumberRange: IVL<INT> + peri odicTargetAccrual Number: RTO<INT,PQ> + accrual Reporti ngMethodCode: CD + responsiblePartyCode: CD + /mul ti Instituti onIndi cator: BL + parti ci patingOrgani zati onTypeCode: CD + parti ci patingCountryCode: SET <CD> + AECodi ngSystem: CD ::Document + publ icTitl e: ST + officialTi tle: ST + typeCode: CD + publ icDescri pti on: ST + sci entifi cDescri pti on: ST + keywordCode: SET<CD> + keywordText: SET<ST> + text: ST + revi sionText: ST + universal ResourceLocator: URL + bi bl i ographi cDesi gnati on: ST + l anguageCode: CD

+ sampl ingMethodCode: CD + timePerspecti veCode: CD ::StudyProtocol + acronym: ST + phaseCode: CD + di seaseCode: SET<CD> + targetAnatomi cSi teCode: CD + primaryPurposeCode: CD + purposeStatement: ST + desi gnConfi gurati onCode: CD + studySchematic: ED + al locati onCode: CD + confidential i tyCode: CD + popul ationDescripti on: ST + subj ectTypeCode: CD + pl annedStudySubj ectExperi ence: ST + acceptsHeal thyVolunteersIndi cator: BL + targetAccrualNumberRange: IVL<INT> + peri odi cTargetAccrual Number: RTO<INT ,PQ> + accrual Reporti ngMethodCode: CD + responsiblePartyCode: CD + /multi InstitutionIndi cator: BL + participatingOrgani zati onTypeCode: CD + participatingCountryCode: SET<CD> + AECodi ngSystem: CD ::Document + publi cT itle: ST + offi cial Ti tl e: ST + typeCode: CD + publi cDescri ption: ST + scientifi cDescripti on: ST + keywordCode: SET <CD> + keywordT ext: SET<ST> + text: ST + revi si onText: ST + uni versal ResourceLocator: URL + bi bl iographi cDesi gnati on: ST + l anguageCode: CD

+ numberOfInterventi onGroups: INT + i nterventi onDescri ption: ST + controlType: CD + controlConcurrencyType: CD + al l ocati onCode: CD + bl i ndi ngSchemaCode: CD + bl i ndedRol eCode: SET<CD> ::StudyProtocol + acronym: ST + phaseCode: CD + di seaseCode: SET<CD> + targetAnatomi cSi teCode: CD + pri maryPurposeCode: CD is eval uati ng / + purposeStatement: ST is a research + desi gnConfigurati onCode: CD + studySchemati c: ED topic i n + al l ocati onCode: CD + confidentiali tyCode: CD + popul ationDescripti on: ST + subj ectTypeCode: CD + pl annedStudySubjectExperi ence: ST + acceptsHealthyVolunteersIndi cator: BL + targetAccrual NumberRange: IVL<INT> + peri odicTargetAccrual Number: RTO<INT,PQ> + accrual Reporti ngMethodCode: CD + responsiblePartyCode: CD + /mul ti Instituti onIndi cator: BL + parti ci patingOrgani zati onT ypeCode: CD + parti ci patingCountryCode: SET<CD> + AECodi ngSystem: CD ::Document + publ icTitl e: ST + officialTi tle: ST + typeCode: CD + publ icDescripti on: ST + sci entifi cDescri ption: ST + keywordCode: SET<CD> + keywordText: SET<ST> + text: ST + revi sionText: ST + universal ResourceLocator: URL + bi bl i ographicDesi gnati on: ST + l anguageCode: CD

1 Product + typeCode: CD + classCode: SET<CD> + pre1938Indicator: BL + expi rati onDate: TS ::Materi al + i denti fier: SET<II> + name: SET<TN> + descri ption: ST + formCode: CD + statusCode: CD + statusDateRange: IVL<TS>

is shi pped or del i vered wi thin / contains

1..*

0..1

+ + + + + + +

Specimen

i denti fi er: SET<II> name: TN typeCode: CD formCode: CD l otNumberText: ST capTypeCode: CD capacityQuantity: PQ

0..1

+ + + +

1

1

+ targetCodingSystem: CD ::ObservationResul t + resul tCode: CD + textResult: ST + numericResul t: PQ + bool eanResul t: BL + targetSi teCode: CD + confi denti al ityCode: CD + uncertai ntyCode: CD + baseli neIndicator: BL + reportedDate: TS + comment: SC

1..*

::PlannedObservati onResult + targetCodi ngSystem: CD ::Observati onResul t + resultCode: CD + textResul t: ST + numeri cResult: PQ + bool eanResul t: BL + targetSi teCode: CD + confidentiali tyCode: CD + uncertaintyCode: CD + basel i neIndi cator: BL + reportedDate: T S + comment: SC

i s defi ned by / defines

1 PlannedObserv ation ::Pl annedActi vi ty + name: SET <ST> + actual Indi cator: BL + conti ngentIndicator: BL + studyFocusIndi cator: BL + inStudySegmentPl annedActi vi tyTypeCode: CD + addi tional DurationDescripti on: ST + plannedRangeOfRepeti ti onsText: ST ::Acti vi ty + identifi er: II + nameCode: CD + textDescri pti on: ST + categoryCode: CD + subcategoryCode: CD + reasonCode: SET<CD> + statusCode: CD + statusDateRange: IVL<TS> + comment: ST

Business Rul e: For Pl annedStrati fi cati onCri teri on i t would al ways be associ ated to 2 or more Pl annedStrati fi cati onCri teri onPermi ssi bl eResul t.

0..*

PlannedAdv erseEv entObserv ation

PlannedEligibilityCriterion

::Pl annedActi vi ty + name: SET<ST> + actual Indi cator: BL + conti ngentIndi cator: BL + studyFocusIndi cator: BL + i nStudySegmentPlannedActi vi tyTypeCode: CD + addi tional Durati onDescripti on: ST + plannedRangeOfRepeti ti onsText: ST ::Acti vi ty + i dentifier: II + nameCode: CD + textDescri ption: ST + categoryCode: CD + subcategoryCode: CD + reasonCode: SET<CD> + statusCode: CD + statusDateRange: IVL<TS> + comment: ST

+ criteri onName: ST + requi redResponse: ST + val ue: ST + criteri onCode: CD + operator: ST + di spl ayOrder: INT ::Pl annedActi vi ty + name: SET<ST> + actualIndi cator: BL + conti ngentIndicator: BL + studyFocusIndicator: BL + inStudySegmentPl annedActi vi tyTypeCode: CD + additional DurationDescripti on: ST + pl annedRangeOfRepeti tionsText: ST ::Acti vi ty + identifi er: II + nameCode: CD + textDescripti on: ST + categoryCode: CD + subcategoryCode: CD + reasonCode: SET<CD> + statusCode: CD + statusDateRange: IVL<TS> + comment: ST

PlannedSpecimenCollection ::PlannedProcedure + methodCode: CD + approachSi teCode: CD + targetSi teCode: CD + targetSi teConditi onCode: CD ::PlannedActi vi ty + name: SET<ST> + actual Indi cator: BL + conti ngentIndi cator: BL + studyFocusIndi cator: BL + i nStudySegmentPlannedActi vi tyTypeCode: CD + addi ti onalDurati onDescri pti on: ST + plannedRangeOfRepeti ti onsText: ST ::Acti vi ty + i denti fier: II + nameCode: CD + textDescri ption: ST + categoryCode: CD + subcategoryCode: CD + reasonCode: SET<CD> + statusCode: CD + statusDateRange: IVL<TS> + comment: ST

::PlannedActivity + name: SET<ST> + actual Indicator: BL + contingentIndi cator: BL + studyFocusIndi cator: BL + i nStudySegmentPlannedActivityTypeCode: CD + addi ti onalDurati onDescri ption: ST + pl annedRangeOfRepetiti onsText: ST ::Activity + i denti fier: II + nameCode: CD + textDescri ption: ST + categoryCode: CD + subcategoryCode: CD + reasonCode: SET <CD> + statusCode: CD + statusDateRange: IVL<TS> + comment: ST

uses / i s admi ni stered duri ng

PlannedSpecimenStorage

0..*

identifi er: II accessi onNumberText: ST typeCode: CD condi ti onCode: CD

may be stored / may store 1

PlannedStratificationCriterion + cri teri onCode: CD ::Pl annedActivity + name: SET<ST> + actualIndicator: BL + contingentIndi cator: BL + studyFocusIndicator: BL + i nStudySegmentPl annedActi vi tyTypeCode: CD + additi onal Durati onDescri ption: ST + pl annedRangeOfRepetitionsT ext: ST ::Acti vi ty + i denti fi er: II + nameCode: CD + textDescripti on: ST + categoryCode: CD + subcategoryCode: CD + reasonCode: SET<CD> + statusCode: CD + statusDateRange: IVL<T S> + comment: ST

PlannedAdministrativ eActiv ity

may be col l ected during / may resul t i n 1

+ dose: PQ + doseDescri pti on: ST + doseFrequencyCode: CD + doseRegi men: ST + doseFormCode: CD + doseTotal: PQ + routeOfAdmi ni strati onCode: CD + l ocati onOfDoseAdministrationCode: CD + treatmentVehi cl eCode: CD + treatmentVehi cl eAmount: PQ ::PlannedActivity + name: SET<ST> + actual Indicator: BL + contingentIndi cator: BL + studyFocusIndi cator: BL + i nStudySegmentPlannedActivityTypeCode: CD + addi ti onalDurati onDescri ption: ST + pl annedRangeOfRepetiti onsText: ST ::Activity + i denti fier: II + nameCode: CD + textDescri ption: ST + categoryCode: CD + subcategoryCode: CD + reasonCode: SET <CD> + statusCode: CD + statusDateRange: IVL<TS> + comment: ST

0..*

1 pl ays / is pl ayed by-BRIDG Release 2.1 Static Classes::Package

1

+ name: SET<ST> + actual Indi cator: BL + conti ngentIndi cator: BL + studyFocusIndi cator: BL + i nStudySegmentPlannedActi vi tyTypeCode: CD + addi ti onalDurati onDescri pti on: ST + plannedRangeOfRepeti ti onsText: ST ::Acti vi ty + i denti fier: II + nameCode: CD + textDescri ption: ST + categoryCode: CD + subcategoryCode: CD + reasonCode: SET<CD> + statusCode: CD + statusDateRange: IVL<TS> + comment: ST

1..*

StudyOutcomeMeasure

BRIDG Release 2.1 -- Static Classes:: DocumentReceiv ingOrganization

pl ays / i s pl ayed by

+ + +

associates to / may be the target for

PlannedActiv ity

is measured by / measures 1..*

0..*

IdentifierAssigner

1

0..1

0..*

PlannedAdv erseEv entObserv ationResult

StudyObj ectiv e

+ + + +

THC Note: Consider resol vi ng thi s many to many associ ation i n future rel ease of BRIDG i f/when a fundi ng subdomain comes forward.

0..1

pl ays/ i s pl ayed by

PlannedObserv ationResult

associates from / may be contai ned by

PlannedSubstanceAdministration

0..*

0..1

associ ates from / may be the source for

Busi ness Rul e: The ti mi ng for Pl annedActivity is handled through the Acti vi tyRel ati onshi p.pauseQuanti ty attri bute where the Pl annedActi vi ty is rel ated through the Acti vi tyRel ati onshi p to the Pl annedActivity that i s the reference point for the offset i n the pauseQuanti ty.

::Pl annedObservati onResul t + targetCodi ngSystem: CD ::Observati onResul t + resultCode: CD + textResul t: ST + numeri cResul t: PQ + booleanResul t: BL + targetSiteCode: CD + confi denti al i tyCode: CD + uncertaintyCode: CD + basel ineIndi cator: BL + reportedDate: TS + comment: SC

1

Business Rul e: StudyCoordi natingCenter.telecomAddress onl y used i f StudyCoordi natingCenter.responsi bi l ityCode incl udes Randomization Center.

functi ons as / i s represented by

0..1

0..*

1

identifi er: II nameCode: CD textDescri pti on: ST categoryCode: CD subcategoryCode: CD reasonCode: SET<CD> statusCode: CD statusDateRange: IVL<TS> comment: ST

i s scoped by / scopes 1

groups / i s grouped by

is defined by / defi nes

1..*

resul tCode: CD textResult: ST numeri cResul t: PQ bool eanResul t: BL targetSi teCode: CD confi denti al ityCode: CD uncertai ntyCode: CD basel ineIndi cator: BL reportedDate: TS comment: SC

Acti vi ty

descri bes / is descri bed by

medl ineIdenti fi erNumber: INT ci tati onDescri ption: ST li nkPageDescripti on: ST uni versalResourceLocator: URL resul tReferenceIndicator: BL

0..*

1

1

StudyReference + + + + +

executes/ i s executed at

0..*

«StudyRel ationship» Activ ityRelationship

Busi ness Rule: The type of activity determi nes what the val ue set should be for category.

StudyProtocol .multi Institution Indi cator can be derived when StudyProtocol .parti ci pati onTy peCode = Mul ti Center

StudyProtocol

StudyInv estigator

i dentifier: II certi ficateLi censeText: ST postal Address: AD tel ecomAddress: SET<TEL> statusCode: CD statusDateRange: IVL<TS>

0..1

is scoped by / scopes

0..1 i s sent to / receives

Business Rul e: A StudyInvesti gator can be represented by ei ther a Cl inicalResearchStaff, a Person, or a HealthCareProvider but onl y one.

i s scoped by / scopes 0..*

HealthCareProv ider

+ + + + + + + + + +

0..* «StudyRel ationship» Activ ityStudySegmentRule

0..*

«StudyRel ationship» StratumGroupRelationship 1..*

1

ObservationResult

PlannedStratificationCriterionPermissibleResult

is defined by /defi nes

0..* associ ates to / may be the target for

1

Business Rule: For associati ons between PlannedStrati fi cati onCri teri on and PlannedStrati fi cati onCri teri onPermi ssi bleResul t, the cardi nal i ty should be 2..* on the PlannedStrati fi cati onCri teri onPermi ssi bleResul t.

PlannedEpoch

parti ci pates i n / is conducted by

StudySiteContact

0..* 0..*

0..*

«StudyRelati onshi p» Observ ationResultRelationship

0..1

1

::Epoch + name: ST + typeCode: CD + descri pti on: ST + fi rstEpochIndi cator: BL

Busi ness Rul e: A StudyContact can be represented by ei ther a Cl inical ResearchStaff or a Person but not both.

A Cli ni calResearchCoordi nator could potenti al ly be a rol e for StudySiteContact.

0..1

0..*

1

1

name: ST typeCode: CD descri pti on: ST fi rstEpochIndicator: BL

devel ops / is authored by

StudyContact

+ + + + 0..* + +

pl ays / i s pl ayed by

Department

may be the source for / associ ates from

posi ti onNumber: INT posi ti onFil ledIndi cator: BL

Epoch

0..*

1

1

+ 0..* +

+ + + +

1..*

0..1

0..1

scopes / i s scoped by

is randomi zed by / randomi zes

1

groups / is grouped by

StudyAuthor ClinicalResearchStaff

pl ays / i s pl ayed by 0..1

1

StudySegment name: ST descripti on: ST fi rstStudySegmentIndi cator: BL

PlannedStudySegment

i s represented by / functi ons as

plays / is played 0..1 by

groupNumber: INT

1

+ + +

1 Busi ness Rul e: Vali d roles to associate to a StudyAuthor are Heal thCareProvi der and Cl i ni cal ResearchStaff

functi ons as / i s represented by

0..*

+ + + + + + + +

1..* associ ates to / i s a component of

0..*

is a component of / is compri sed of

0..*

scoped by / scopes

Business Rul e: A gi ven StudySegment can bel ong to one and only one StudyCel l.

1..*

«StudyRel ationship» EpochRule

0..* 0..*

RandomizationBookEntry

StratumGroup

i s a di vi si on of / i s di vi ded i nto

DocumentAuthor

OrganizationalContact

1

1..*

1

pl ays / is played by

+ + + + + +

name: ST bl i ndedDescripti on: ST

::StudyCel l + name: ST + bli ndedDescri ption: ST

i s randomized by / i denti fies a cel l for

Person

plays / is played by 0..*

+ +

PlannedStudyCell

«StudyRelati onshi p» StudySegmentStudyCellRule

is comprised of / associ ates from

StudyCell

0..* 1..*

+ name: PN + i ni ti al s: ST + postal Address: AD + tel ecomAddress: SET<TEL> + educati onLevelCode: CD + academicDegree: SET<CD> + ethnicGroupCode: SET<CD> + raceCode: SET<CD> + mari talStatusCode: CD + pri maryOccupati onCode: CD + occupationDateRange: IVL<TS> + deathIndi cator: BL + statusCode: CD + statusDateRange: IVL<TS> ::BiologicEnti ty + sexCode: CD + birthOrder: INT + birthCountryCode: CD + birthDate: TS + deathDate: TS

Busi ness Rul e: T he ti ming for the Pl annedSubj ectStudyEncounter i s handl ed through the SubjectStudyEncounterRul e.pauseQuanti ty attribute where the Pl annedSubjectStudyEncounter i s related though the SubjectStudyEncounterRul e to the Pl annedSubj ectStudyEncounter that is the reference point for the offset in the pauseQuanti ty. For example, in the case of 28 days after enrol l ment on the study, pauseQuanti ty = 28 days from the Pl annedSubjectStudyEncounter of enrol lment on the study.

::SubjectStudyEncounter + name: ST + typeCode: CD 0..1

is comprised of / is a component of

Subject

Animal

1..* SoACell

0..1

0..*

i s issued by / i ssues 0..*

0..*

+ bi ospecimenRetentionIndi cator: BL + potenti al ForDNAExtracti onIndicator: BL ::Pl annedActivity + name: SET<ST> + actualIndicator: BL + contingentIndi cator: BL + studyFocusIndicator: BL + i nStudySegmentPl annedActi vi tyTypeCode: CD + additi onal Durati onDescri ption: ST + pl annedRangeOfRepetitionsT ext: ST ::Activity + i denti fi er: II + nameCode: CD + textDescripti on: ST + categoryCode: CD + subcategoryCode: CD + reasonCode: SET<CD> + statusCode: CD + statusDateRange: IVL<T S> + comment: ST

PlannedInclusionCriterion

PlannedExclusionCriterion

::PlannedEli gi bi li tyCriteri on + cri teri onName: ST + requiredResponse: ST + value: ST + cri teri onCode: CD + operator: ST + di splayOrder: INT ::PlannedActivity + name: SET<ST > + actual Indicator: BL + contingentIndi cator: BL + studyFocusIndi cator: BL + i nStudySegmentPl annedActivityTypeCode: CD + addi ti onalDurati onDescri ption: ST + pl annedRangeOfRepetiti onsText: ST ::Activity + i denti fi er: II + nameCode: CD + textDescri pti on: ST + categoryCode: CD + subcategoryCode: CD + reasonCode: SET<CD> + statusCode: CD + statusDateRange: IVL<TS> + comment: ST

::Pl annedEl i gi bil i tyCri terion + criteri onName: ST + requi redResponse: ST + val ue: ST + criteri onCode: CD + operator: ST + di spl ayOrder: INT ::Pl annedActi vi ty + name: SET<ST> + actualIndi cator: BL + conti ngentIndicator: BL + studyFocusIndicator: BL + inStudySegmentPl annedActi vi tyTypeCode: CD + additional DurationDescripti on: ST + pl annedRangeOfRepeti tionsText: ST ::Acti vi ty + identifi er: II + nameCode: CD + textDescripti on: ST + categoryCode: CD + subcategoryCode: CD + reasonCode: SET<CD> + statusCode: CD + statusDateRange: IVL<TS> + comment: ST

0..* StudyAgent 0..* + + + +

l eadAgentIndi cator: BL comparatorIndi cator: BL statusCode: CD statusDateRange: IVL<TS>

may use / is used for

0..* 0..*

0..*

has component / used as component

is used as / is ful fil led by

0..1

TherapeuticAgent

1

1

+ + +

pl ays / is pl ayed by

pl ays / is pl ayed by

identifi er: II statusCode: CD statusDateRange: IVL<TS>

is used as / is 1 fulfil l ed by

ConcomitantAgent 0..*

0..1 1

NonTherapeuticAgent 0..1

Dev ice FoodProduct

Biologic

+ l otNumberT ext: ST + strength: RTO<PQ,PQ> + activeIngredi entIndi cator: BL ::Product + typeCode: CD + classCode: SET<CD> + pre1938Indicator: BL + expi rati onDate: TS ::Material + i denti fier: SET <II> + name: SET<TN> + descri pti on: ST + formCode: CD + statusCode: CD + statusDateRange: IVL<TS>

380

+ reprocessedDevi ceCode: CD + avai labl eForEvaluationIndicator: BL + overTheCounterProductIndicator: BL + singl eUseDevi ceIndi cator: BL + devi ceAge: PQ + manufactureDate: TS ::Product + typeCode: CD + classCode: SET<CD> + pre1938Indicator: BL + expi rati onDate: TS ::Materi al + i denti fier: SET<II> + name: SET<T N> + descri ption: ST + formCode: CD + statusCode: CD + statusDateRange: IVL<TS>

+ l otNumberText: ST + strength: RTO<PQ,PQ> ::Product + typeCode: CD + classCode: SET<CD> + pre1938Indicator: BL + expi rati onDate: TS ::Materi al + i denti fier: SET<II> + name: SET<TN> + descri ption: ST + formCode: CD + statusCode: CD + statusDateRange: IVL<TS>

Cosmetic

Drug

+ lotNumberText: ST + strength: RTO<PQ,PQ> + acti veIngredientIndicator: BL ::Product + typeCode: CD + cl assCode: SET<CD> + pre1938Indi cator: BL + expirationDate: TS ::Materi al + identifi er: SET<II> + name: SET<TN> + descripti on: ST + formCode: CD + statusCode: CD + statusDateRange: IVL<TS>

+ l otNumberText: ST + strength: RT O<PQ,PQ> + acti veIngredientIndicator: BL ::Product + typeCode: CD + cl assCode: SET<CD> + pre1938Indi cator: BL + expi rati onDate: TS ::Materi al + i denti fi er: SET<II> + name: SET<TN> + descri ption: ST + formCode: CD + statusCode: CD + statusDateRange: IVL<T S>

© CDISC, 2009 Version 1.0

15

29/Apr/2009


CDISC Protocol Representation Model

Protocol Representation

381

5.1 How should I read this diagram?

382 383 384 385 386 387 388 389

1. Read the diagram according to the conventions of a UML class diagram. For an introduction to the UML concepts you will need in order to read and understand the diagram, see Section 4.0 above. In short, three are three important things to know: (1) Each rectangle in the diagram is a “class” that has “attributes.” (2) Classes are commonly used in UML diagrams to represent “entities,” i.e., a unit that is either a person, place, or thing. (3) The lines between the rectangles represent a variety of “associations” or relationships between the classes, and these lines define how the classes interact or relate to each other. For guidance on how to interpret the different types of associations between classes in the PRM, please see Section 4.3.3.

390 391 392 393 394

2. Read the diagram according to any applicable BRIDG and HL7modelling conventions. The most important convention to understand is that the rectangles do not just represent entities. As indicated by the color coding, the rectangles also represent roles, activities, or the participation of a role in an activity. Understanding these colors is an important part of understanding the overall model. The meaning of each color is explained in the table below.

395

5.2 Why do the rectangles have different colors?

396 397 398 399

The rectangles use different colors to indicate whether the class is an Entity, Role, Participation of a Role, Act, ActRelationship, or Draft. The meanings of the colors are based on conventions developed by HL7, and are explained in the table below. Color

HL7 Meaning Green rectangles are entities that represent a person, place, or thing in a very broad sense. For example, the BiologicEntity class refers to any individual living (or previously living) being such as an animal or human. Yellow rectangles represent roles played by an entity. For example, a “person” can play the role of a “healthcare provider.” This is shown by the relationship between the Person and HealthCareProvider classes. Red rectangles represent an act or BRIDG activity. For example, an activity may be the development of a protocol (i.e., StudyProtocol) or the conduct of activities in a study arm (i.e., Arm). Blue rectangles represent participation of a role in an activity. For example, for a limited period of time, a healthcare provider may participate as a study investigator in the context of a clinical study. This is shown by the relationship between the HealthCareProvider, StudyInvestigator, and StudyProtocol classes. Pink rectangles only apply to acts, and represent an ActRelationship, i.e., a relationship that allows two act classes to have a “many to many” as opposed to a “one to many” relationship. For example, consider a DocumentIdentification, which is an identifier used to identify a document. A single DocumentIdentification may be used to identify a set of documents. Similarly, one Document may have more than one DocumentIdentification, which might be used to represent it. Orange rectangles represent classes that have been recently added and are therefore subject to a greater possibility of change, since they have not undergone the same degree of evaluation and refinement at the other classes.

400

© CDISC, 2009 Version 1.0

16

29/Apr/2009


Protocol Representation Model Documentation