1. BRIDG Model: A Comprehensive Information Model for Biomedical Research
25-April-2006
Douglas B. Fridsma
University of Pittsburgh School of Medicine
Julie Evans CDISC

2. CDISC Mission
The mission of CDISC is to develop and support global, platform-independent data standards that enable information system interoperability to improve medical research and related areas of healthcare.

3. Future of CDISC Models Future Uniform CDISC Standard
Harmonized with HL7
Operational
Data
Interchange
& Archive:
ODM, LAB
Submission
Data
Interchange
& Archive:
SDTM,
SEND, ADaM
Data Sources
Site CRFs
Laboratories
Contract
Research
Organizations
Development
Partners
Operational
Database
Study Data
Audit Trail
Metadata
Submission
Data
CRT/Domain Datasets
Analysis Datasets
Metadata
Protocol
ODM = Operational Data Model SDS = Submission Domain Standards
LAB = Laboratory Data Model ADaM = Analysis Dataset Models
SEND = Std. Exchg. Non-clinical Data
Standard Protocol Representation and Terminology

4. How does BRIDG support these goals?
CDISC started constructing an analysis model in 2003 to clarify semantic interoperability among CDISC models, and between the CDISC models and HL7
BRIDG has become a collaborative mechanism with other people interested in developing standards
HL7 is using it as the basis for HL7 messages in RCRIM
NCI is using it to develop interoperable applications to support cancer research
Technology providers are using it to develop standards-based applications
CDISC continues to use it to clarify the semantics of the existing CDISC models
BRIDG has provided a way for CDISC standards to gain visibility among standards, research, and technology organizations

5. CDISC Roadmap Timeline

6. CDISC Standards Harmonization
Operational
Data
Interchange
& Archive:
ODM, LAB
Submission
Data
Interchange
& Archive:
SDS, ADaM
SEND
Data Sources
Site CRFs
Laboratories
Contract
Research
Organizations
Development
Partners
Operational
Database
Study Data
Audit Trail
Metadata
Submission
Data
CRT/Domain Datasets
Analysis Datasets
Metadata
BRIDG: Harmonizing to THE CDISC Standard
Protocol
ODM = Operational Data Model/Std SDS = Submission Domain Standards
LAB = Laboratory Data Model/Std ADaM = Analysis Data Models
SEND = Standards for the Exchange of Non-Clinical Data

7. Why BRIDG?

8. Interchange vs Interoperability
Syntax  Structure Semantics  Meaning
Main Entry: in·ter·op·er·a·bil·i·ty : ability of a system ... to use the parts or equipment of another system Source: Merriam-Webster web site
interoperability : ability of two or more systems or components to exchange information and to predictably use the information that has been exchanged.
Source: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990]
Semantic interoperability
Syntactic interoperability
(interchange)
Source: Charles Mead, MD, HL7

9. Computerized doesn’t mean syntactic interoperability6 1 5 2 3 4

10. Semantic interoperability: “Protocol” and the Semiotic Triangle
“We need to sign off on the protocol by Friday”
Concept 1
Thing 1
Document
Study
“Protocol XYZ has enrolled 73 patients”
Thing 2
Concept 2
Symbol
“Protocol”
“Per the protocol, you must be at least 18 to be enrolled”
Concept 3
Thing 3
Plan
Source: John Speakman/Charlie Mead

11. Semantic Interoperability
To understand the data being received you must know both:
The definition of each element of data, and its relationship with each of the other elements
you must have a semantic model of the data and
The terminology to be used to represent coded elements, including the definitions, and relationships within the terminology
Source: HL7

12. The Pillars of (Semantic) Interoperability Necessary but not Sufficient
Common model across all domains-of-interest
The representation of clinical trials in BRIDG
Model grounded on robust data type specification
Common data elements (ISO 11179) in the cancer Data Standards Repository (caDSR)
Methodology for binding terms from concept-based terminologies
Enterprise Vocabulary Server, terminologies
A formally defined process for defining specific structures to be exchanged between machines, i.e. a “messaging standard”
HL7 and implementation specifications
CDISC standards development process
caBIG unified process/model driven architecture

13. What is BRIDG?
A formal model of the shared semantics of regulated clinical trials research
A communication bridge between
clinical trial domain experts and technical experts
different models of clinical trials information
An open community of stakeholders interested in developing standards for exchanging information about clinical trials
HL7 Domain analysis model in Regulated Clinical Research (RCRIM) technical committee
caBIG analysis model for model-driven development
CDISC integrating model for current standards
The semantic foundation for application and message development in HL7, caBIG, and CDISC

14. So how did BRIDG get started?
Two important streams of development that have been brought together into a collaborative framework
CDISC – 2003, started constructing an analysis model to map ODM standards to HL7
NCI – 2004, started caBIG initiative to construct a structured protocol representation and interoperability among clinical trials research in cancer

15. Model History – the CDISC work
Fall 2003 – CDISC board meeting – recognized that integration of their standards required an comprehensive model of clinical trials
Jan 2004 – CDISC begins work on integrated domain analysis model
Mar 2004 – First modeling session in Philadelphia
Summer 2004 – Multiple modeling sessions to expand the model
Presentation to HL7 RCRIM, Fall 2004

16. caBIG and the Development of Structured Protocol Representation
Spring 2004 – kick-off of the caBIG project
University of Pittsburgh award the contract to develop a structured protocol representation to support clinical trials

17. Merging the caBIG and CDISC projects
Fall 2004 – caBIG identified “best of breed” models in the CDISC standards and HL7 messages
November 2004 – First joint CDISC/HL7/caBIG modeling session
Between November 2004 and March 2005 – multiple modeling sessions to develop the “scaffolding” of the domain analysis model (SPR). Renamed BRIDG to reflect the shared interests of all stakeholders
March 2005 to now
Development of the dynamic aspects of the model
Develop scalable processes to support collaboration and expansion of the model, based on software best practices
Initiation of 8 subdomain projects within BRIDG

18. Current Organization of the BRIDG project
FDA
HL7
BRIDG Advisory Board
Representation from the current stakeholders
Help to allocate priorities and identify resources
Assist with vetting the model in the various constituents
Technical Harmonization Group
Responsible for ongoing model maintenance
Developing shared harmonization processes
Multiple subdomain projects
Representation from pharmaceutical companies, technology companies, government agencies, and cancer centers
CDISC
caBIG
NCI
PhRMA
BRIDG
Advisory Board
CDISC
caBIG
HL7
BRIDG
Technical Harmonization Group

19. BRIDG projects and contributors
BRIDG model
Protocol Authoring &
Trial Design
FDA
(M. Walker)
HL7
(M Walker)
SDTM
(CDISC)
caAERS
(caBIG)
PDQ
ClinicalTrials.gov
EudraCT
CONSORT
(cancerGRID)
WHO
ODM
CTOM
CDISC
Oracle
caBIG
NCI
Study calendar
JANUS
(IBM)
Lab SIG
CTLab std
FastTrack
Protocol Registration
Clinical Trials Operations
Adverse
Events
Lab Specification
eDCI

20. Principles for model organization
Make the work process explicit
Recognizes that concepts and models are in different stages of development and harmonization
Provide a mechanism to scale the development work
Parallelize the development
Prevent collaborators from “colliding” with each other
Allows us to modeling in the open

21. Model organization Dynamic View
Captures the business process decomposition of the lifecycle of clinical trials research

22. Behavioral Aspects of BRIDG

23. Behavioral Aspects of BRIDG
Roles are defined in the swim lanes with examples drawn from discussions with the domain experts

24. Behavioral Aspects of BRIDG
The activities are described in activity diagrams that can be drilled down to provide additional detail. These are linked to the static (logical) portions of the model

25. Model organization Logical View Contains three core packages
Harmonized elements
Staging Area
Manual review area
Addition resources
HL7 V3 RIM
Contains the semantics for the static objects (data) that is used in clinical trials research
Currently have 9 subdomain models in the process of harmonization

26. Current Classes in Core Elements

27. Harmonized BRIDG elements

28. BRIDG Sub-Projects Trial Design Model
Based on CDISC and FDA/Janus standard
Developing common concepts and understanding for arms, treatment groups, visits, cycles, courses, etc.
At present, input from Pharmaceutical companies thru CDISC and FDA
Current Status –
Recently worked with CDISC SDTM team to model SDTM requirements
Plans to harmonize with BRIDG
Trial design
CDISC trial design subcommittee has moved their work into enterprise architect and UML modeling to speed the development efforts
Update the model every 2 weeks with results of teleconference
Statistical design
eDCI subproject
General purpose HL7 message to describe a data capture instrument, or case report form. Using HL7 “early adopter” mechanisms.
Actively using gForge documents, forums, webpages, and CVS repository
Clinical Registry message
Development of an HL7 message for registering a clinical trial in a clinical trial repository
Eudract (europe)
Clinicaltrials.gov, PDQ
Traditional HL7 project development (not early adopter)
Adverse events
First significant sub-model to be harmonized
Will lead to both application development and message specification
Harmonization branch and maintenance
Additional definitions added from CTOM
Reference implementation
Cleaning up the model and definitions

29. Example: Dissimilar Arms
Epoch
Screen
Run-In
Treatment
Follow-up
Arm
Arm segment
Trt Phase 1
Trt Phase 2
Follow-up
Screen
Run-In
Standard Care
Follow-up
Source: Diane Wold - GSK

30. BRIDG Sub-Projects (cont’d)
Clinical Trial Registry
Objective: To define requirements for registering a clinical trial in a clinical trial repository
Working with NCI, CDISC, PDQ, clinicaltrials.gov and European EUDRACT
Have recently established collaboration with the WHO activity of clinical trials registry
Becky Kush (CDISC president) on the advisory board
Working with cancerGRID to incorporate and make explicit the CONSORT model
Current Status –
Group has defined a list of 70 elements
Modeled in BRIDG April 2006
Planning on developing a HL7 v3 message
POC – Lakshmi Grama, NCI

31. CT Registration message

33. BRIDG Sub-Projects (cont’d)
eDCI message (electronic Data Capture Instrument)
A DCI is a set of related questions for which values are to be collected during a clinical trial visit.
This model will be used as an HL7 message definition (or a set of definitions) that can be used to transmit a DCI Definition between databases managed by clinical data management systems (CDMS).
Participation from NCI, CDISC, Oracle
UML model on bridgproject site --
Current Status –
Requirements have been defined for 1st iteration
UML class diagram is completed
Working on building the message specification (RMIM)
POC – Don Kacher, Oracle
In addition to questions, a DCI (for the purposes of this modeling effort) also contains instructions on the rendering of the prompts for the questions, the relative positioning of questions, and rules for non-default navigation among questions

34. DCI
Definition
(aka CRF)

35. SDTM
SDTM model
Being harmonized with adverse event reporting, CTOM (NCI clinical trial object model) and HL7

36. SDTM Class Diagram

37. Subprojects caAERS Project lead: Joyce Niland
Developing an HL7 message and application(s) to support adverse event reporting
Other AE models –
CDC – incidence reporting
HL7 – patient safety and public health reporting
caBIG (caAERS)
FDA and SDTM (CDISC)
Harmonization meeting in May with all stakeholders to identify commonalities and differences between these models, and harmonize them into BRIDG

38. caAERS

39. Harmonization

40. Project plan Registration of the project Regular releases
Allows the BRIDG team to provide information and updates
Regular releases
Monthly modeling session
Priorities and resources determined by the BRIDG advisory board (and stakeholders)

41. Models in the staging area

42. What does it mean to “adopt BRIDG” or “harmonize with BRIDG?”
Adopting and harmonizing with BRIDG is a two-way street
The model is not complete, and harmonization and adoption requires participation and contribution to BRIDG from others
The model is new and is changing, so harmonization and adoption requires flexibility and change
Early adopters will have a more significant impact on the direction and development of BRIDG
Adopting and harmonization with BRIDG is less about a commitment to a specific model, but the realization that
A common standard is a shared good that all can benefit from
It will require contribution and collaboration as we collectively determine the best approaches
It will require compromise and collective action

43. BRIDG - Implementation Independent Domain Analysis Model
Implementation Specific Models
CTOM
caAERS
Lab SIG Model
Study Calendar SIG Model
Financial SIG Model

44. BRIDG - Implementation Independent Domain Analysis Model
Implementation Specific Models
CTOM
caAERS
Lab SIG Model
Study Calendar SIG Model
Financial SIG Model

45. BRIDG - Implementation Independent Domain Analysis Model
Implementation Specific Models
CTOM
caAERS
Lab SIG Model
Study Calendar SIG Model
Financial SIG Model

46. Harmonized BRIDG elements
Observation Classes from CTOM and SDTM

47. CTOM and SDTM harmonization (work in progress)

48. Harmonizing attributes

49. Adding tags to provide semantic traceability (and notes)

50. Simple semantic can be tracked in tagged values

51. This linking can be extended down to the CDE level

52. More complex relationships

53. Achieving interoperability
Application
Development
caCORE Tooling
V3 Message
Development
HL7 Tooling
xml data
Exchange
CDISC xml
IMPLEMENTATION
SOLUTIONS
Interoperability
Interoperability
STAKEHOLDERS
NCI/caBIG
HL7 (RCRIM)
CDISC
BRIDG – Domain Analysis Model for Clinical Research
FOUNDATION
MODEL

54. BRIDG BRIDG development Top-Down scaffolding Development
Use case driven, subproject Development

55. Cumulative Registered Users

56. What have we accomplished?
BRIDG
Established excellent collaboration with CDISC, HL7 and other caBIG modelers
Constructed the initial pieces of a comprehensive model – still much to do
Have established this model as the HL7 Domain analysis model
Have developed processes and organization of the model that will support more scaleable collaborative development
This model will serve as the semantic foundation for all data interchange specifications in HL7, CDISC, the NCI, and caBIG

57. Final thoughts: our approach to modeling
Scope – keep it clear and focused (ie, solve a problem that exists) and standardize to the extend needed
Refine through experience, and not endless discussions. This keeps the modeling effort clear and focused
BRIDG is not complete – but the scaffolding is there to help organize the analysis and model development in subprojects
Keep it generic, faithful, free of implementation specific formalisms, and supporting the requirements
If the tools and models don’t work with reality – it is probably the tools and the models that need to change
If it’s broke, fix it
The model is in evolution with known problems – the problems should be an opportunities for improvement and a call to arms, not barriers to use
Model in the open
Collaborate until it hurts
With thanks to Dipak Kalra for discussion

58. BRIDG Supports semantic interoperability
Defines the semantic of static and dynamic structures in context
Provides a mechanism and focus for collaborating around shared semantics

59. BRIDG Best Practices – draft!
Developing New Models
Harmonizing existing Models

60. Project Team Activities
Register Project
with BRIDG & submit
Project info.
Items for submission – POC, Project Name, project
description, high-level project schedule, project
Sponsor, etc.
BRIDG THC assigns
Mentor
A BRIDG mentor will be assigned to your project
Download BRIDG
Replica
Begin modeling
using BRIDG replica
and follow BRIDG
guidelines
Refer to best practices for modeling in BRIDG environment
Submit BRIDG
Harmonization
Package to THC
Harmonization Package artifacts – the EAP file, package level xmi
Export, Modeling analysis & harmonization document)
Submit BRIDG
Harmonization
Package to THC
Meet with BRIDG THC to harmonize project model (virtual or F2F
meeting)

61. BRIDG THC Activities
Review the Project
Registration material.
Assign Mentor
to project
BRIDG mentor will be available to answer questions
Take project to BAB and
assign priority and timeline
for harmonization
Inform Project POC
May require some negotiations based on other efforts
Review harmonization
Package submission
Perform analysis and prepare for harmonization meeting
Schedule project
Harmonization meeting
Develop harmonization
Results package for project
team

62. Ways to interact with BRIDG

63. De-novo modeling (starting with BRIDG)
Register the project
Provide POC and some minimal project info
BRIDG mentor is assigned to you and your project is scheduled for review with the BAB for assignment of priority schedule
Download the BRIDG replica
Create a new project package in Staging area (for both dynamic and static)

64. De-novo modeling (starting with BRIDG) (II)
Begin Modeling
Model in small groups, vet in large groups
Identify classes that can be re-used
Construction of a strawman (possibly using some existing BRIDG classes)
Annotate existing classes with notes on the diagram (do not alter core classes or other classes in Staging area)
Develop a modeling analysis and harmonization document that identifies updates, additions, deletions, change in definitions, comments, etc.
Periodic review with BRIDG mentor
Submit the complete pacakge to BRIDG THC/BAB
xmi export file, EAP file, analysis and harmonization document
Schedule a harmonization meeting between project memebers and THC (centra sessions or F2F meeting)

65. Existing models Register the project
Provide POC and some minimal project info
BRIDG mentor is assigned to you and your project is scheduled for review with the BAB for assignment of priority schedule
Download the BRIDG replica
Create a new project package in Staging area (for both dynamic and static) and import model
Identify points of intersection
Link model elements from other packages in the harmonized elements (realize that these elements will not be exported when the model is exported)
Annotate with notes (do not alter core classes or other classes in Staging area)

66. Existing Models (II)
Develop analysis and harmonization document that identifies updates, additions, deletions, change in definitions, comments, etc.
Periodic review with BRIDG mentor
Submit the complete package to BRIDG THC/BAB
xmi export file, EAP file, analysis and harmonization document
Schedule a harmonization meeting between project memebers and THC (centra sessions or F2F meeting)

67. Best Practices for Class Modeling
Annotate Annotate Annotate
Definitions
Associations and names

68. BRIDG Harmonization

69. BRIDG Access
Collaborative Space (GForge)
Model Management

70. Collaborative tools GForge site
was the first GForge implementation within the CTMS workspace
Recently, NCI has developed a comprehensive GForge site to support caBIG
Risk is that subproject domain modeling will occur in isolation, and not have the level of integration into the BRIDG model
Possible to harmonize these models, but will take more time and resources
Goal:
A single place for all analysis modeling related to BRIDG
Shared forums,
Shared documents
Shared learning
Shared models

71. Goal: A single place for domain modeling
Collaborative analysis modeling, with the range of stakeholders in the BRIDG project, required extensions of the GForge functionality
Completed a requirements and gap analysis
Working with the other BRIDG stakeholders to develop processes to support not only caBIG but others
Once these issues have been resolved, anticipate moving to a shared site for modeling

72. Model Management Tools CVS repository Enterprise Architect
Organizes file-level coordination and versioning control
Implemented in the BRIDG GForge site
Enterprise Architect
Useful model-level (class/attribute) coordination and versioning
Equivalent to dif and merge of text based files, but applies to the model
Two parts of the same issue
Different than model vetting or voting

73. Replication
Replication allows different users to work independently of one another, and to merge their changes at a later time.
This is inherently a hazardous exercise, and so there is no substitution for good collaboration and communication

74. Enterprise Architect Merge Rules
Additions are cumulative - i.e. Two replicas creating 3 new classes each will result in 6 new classes after merging.
Deletions prevail over modifications, if one replica changes a class name and other deletes the class, performing a  merge will result in both files losing the class.
EA can generate an interactive dialogue that allows a user to review conflicts in the replication process.
EA also allows the construction of a “baseline” that can be used to compare changes within a particular file – This is useful to know what has changed as a group has made changes to a particular file.

75. Using Replication
Convert the base project to a Design Master using the Make Design Master option in the Tools | Manage .EAP File submenu).
Create replicas from the design master using the Create New Replica option in the Tools | Manage .EAP File submenu.                
Take the replica away and work on it as required, then bring it back for synchronization with the design master.  
Synchronize the replicas. During synchronization, all changes to both the master and the replica are propagated in both directions, so at the end they both contain the same information.

76. Avoid Change Collisions
If two or more people make changes to the same element, eg. a class, Enterprise Architect will arbitrarily overwrite one person's change with other other's. To avoid this, different users should work on different packages whenever possible
However, since Enterprise Architect does not enforce this rule, it is possible for users' work to conflict. To minimize the difficulties this causes, please note the following guidelines:
If users are likely to have worked in the same area of the model - they should both witness the synchronization and confirm that they are happy with the net result. 
If small pieces of information have been lost, they should be typed into one of the merged models after synchronization. 
If a large piece of information has been lost - for example, a large class note that was overwritten by another user who had made a minor change to the same class  use the Resolve Replication Conflicts dialog.

77. BRIDG model replica
BRIDG has a model master and a replica – the replica is where all of the modeling is currently taking place
Using BRIDG as a starting point allows users to take advantage of the EA infrastructure to support collaborative model development

78. Further Information www.CDISC.org ncicb.nci.nih.gov caBIG.nci.nih.gov