BRIDG Model A Comprehensive Information Model for Biomedical

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

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.

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

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 HL 7 • BRIDG has become a collaborative mechanism with other people interested in developing standards – HL 7 is using it as the basis for HL 7 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

CDISC Roadmap Timeline

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

Why BRIDG?

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 Semantic interoperability • interoperability : ability of two or more systems or components to exchange information and to predictably use the information that has been exchanged. Syntactic interoperability (interchange) » Source: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990] Source: Charles Mead, MD, HL 7

Computerized doesn’t mean syntactic interoperability 6 1 2 5 3 4

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

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: HL 7

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 (ca. DSR) • 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” – HL 7 and implementation specifications – CDISC standards development process – ca. BIG unified process/model driven architecture

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 – HL 7 Domain analysis model in Regulated Clinical Research (RCRIM) technical committee – ca. BIG analysis model for model-driven development – CDISC integrating model for current standards • The semantic foundation for application and message development in HL 7, ca. BIG, and CDISC

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 HL 7 – NCI – 2004, started ca. BIG initiative to construct a structured protocol representation and interoperability among clinical trials research in cancer

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 HL 7 RCRIM, Fall 2004

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

Merging the ca. BIG and CDISC projects • Fall 2004 – ca. BIG identified “best of breed” models in the CDISC standards and HL 7 messages • November 2004 – First joint CDISC/HL 7/ca. BIG 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

Current Organization of the BRIDG project FDA • HL 7 CDISC – Representation from the current stakeholders – Help to allocate priorities and identify resources – Assist with vetting the model in the various constituents ca. BIG NCI Ph. RMA BRIDG Advisory Board CDISC ca. BIG • HL 7 BRIDG Technical Harmonization Group BRIDG Advisory Board 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

BRIDG projects and contributors BRIDG model Eudra. CT SDTM (CDISC) CONSORT (cancer. GRID) WHO JANUS (IBM) SDTM (CDISC) PDQ Clinical. Trials. gov FDA (M. Walker) HL 7 (M Walker) Fast. Track Protocol Authoring & Trial Design Protocol Registration Clinical Trials Operations Adverse Events ca. AERS (ca. BIG) ca. BIG NCI Oracle CDISC ODM Study calendar (ca. BIG) Lab Specification e. DCI SDTM (CDISC) CTOM (ca. BIG) ODM (CDISC) HL 7 (M Walker) JANUS (IBM) SDTM (CDISC) Lab SIG (ca. BIG) CTLab std (CDISC)

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

Model organization • Dynamic View – Captures the business process decomposition of the lifecycle of clinical trials research

Behavioral Aspects of BRIDG

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

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

Model organization • Logical View – Contains three core packages • Harmonized elements • Staging Area • Manual review area – Addition resources • HL 7 V 3 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

Current Classes in Core Elements

Harmonized BRIDG elements

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

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

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 cancer. GRID 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 HL 7 v 3 message POC – Lakshmi Grama, NCI

CT Registration message

BRIDG Sub-Projects (cont’d) • e. DCI 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 HL 7 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 -https: //www. bridgproject. org/edci/ – Current Status – • Requirements have been defined for 1 st iteration • UML class diagram is completed • Working on building the message specification (RMIM) • POC – Don Kacher, Oracle

DCI Definition (aka CRF)

SDTM • SDTM model – Being harmonized with adverse event reporting, CTOM (NCI clinical trial object model) and HL 7

SDTM Class Diagram

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

ca. AERS

Harmonization

Project plan • Registration of the project – 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)

Models in the staging area

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

BRIDG - Implementation Independent Domain Analysis Model Implementation Specific Models CTOM ca. AERS • Lab SIG Model • Study Calendar SIG Model • Financial SIG Model

Harmonized BRIDG elements Observation Classes from CTOM and SDTM

CTOM and SDTM harmonization (work in progress)

Harmonizing attributes

Adding tags to provide semantic traceability (and notes)

Simple semantic can be tracked in tagged values

This linking can be extended down to the CDE level

More complex relationships

Application Development ca. CORE Tooling V 3 Message Development HL 7 Tooling Interoperability NCI/ca. BIG xml data Exchange CDISC xml Interoperability HL 7 (RCRIM) CDISC FOUNDATION MODEL STAKEHOLDERS IMPLEMENTATION SOLUTIONS Achieving interoperability BRIDG – Domain Analysis Model for Clinical Research

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

Cumulative Registered Users

What have we accomplished? • BRIDG – Established excellent collaboration with CDISC, HL 7 and other ca. BIG modelers – Constructed the initial pieces of a comprehensive model – still much to do – Have established this model as the HL 7 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 HL 7, CDISC, the NCI, and ca. BIG

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

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

• BRIDG Best Practices – draft! – Developing New Models – Harmonizing existing Models

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 F 2 F meeting)

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

Ways to interact with BRIDG

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)

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 F 2 F meeting)

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)

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 F 2 F meeting)

• Best Practices for Class Modeling – Annotate – Definitions – Associations and names

• BRIDG Harmonization

• BRIDG Access – Collaborative Space (GForge) – Model Management

Collaborative tools • GForge site – www. BRIDGproject. org was the first GForge implementation within the CTMS workspace – Recently, NCI has developed a comprehensive GForge site to support ca. BIG • 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

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 ca. BIG but others – Once these issues have been resolved, anticipate moving to a shared site for modeling

Model Management • Tools – CVS repository • 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

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

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.

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.

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'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.

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

Further Information • • • www. CDISC. org ncicb. nci. nih. gov ca. BIG. nci. nih. gov www. BRIDGproject. org fridsma@cbmi. pitt. edu jevans@cdisc. org