Building, Maintaining, and Evolving a Model of

Shared Semantics --

The BRIDG Project: Lessons Learned and

Next Steps

Charles Mead MD, MSc

Chief Technology OfficerNational Cancer Institute (NCI)

Center for Biomedical Informatics and Information Technology

(CBIIT)

Definition: Domain Analysis Model

• General: An implementation-independent representation of the dynamic (i.e. behavioral, interaction- based) and static (i.e. concepts, attributes, relationships) semantics of a domain-of-interest

• Dynamic semantics expressed as• Storyboards (text)• Activity, Sequence, State Diagrams (UML)• Service Specifications (UML++)

• Static semantics expressed as• Class and Instance Diagrams (UML)• Abstract Data Type bindings• Value Sets

• All semantics robustly and non-ambiguously defined

• Restricted: Domain semantics limited to static only• Historically, BRIDG has followed the Restricted definition• Going forward, BRIDG semantics will most likely move to the General

definition, driven by use SOA adoption

Why build a Domain Analysis Model?

• Raison ´d’être: “the two faces of a DAM”• To SMEs: domain-friendly terms in a robust semantic context• To Technologists/Developers:• Traceability: Requirements (Analysis) Design Implementation

• A DAM can be used to define (static and dynamic) semantics in multiple development contexts if…• Requirements are complex and/or changing• Multiple stakeholders have conflicting understandings of requirements

• The same (particularly static) semantics can be utilized in a number of technology contexts, e.g.

• message development (payload)

• service specification (run-time binding)

• application development (query API)

The Communication Pyramid

Communication

`Free-text Documents

Structured Documents

ad hoc Drawings

Non-standard Graphics

Discussions

Standardized Models (UML) -- DAM

Probl

em S

pace

Solution Space

Impl

emen

tatio

n-In

depe

nden

t

Implem

entation-Specific

Ab

stra

ctio

n

BRIDG circa 2004:Separating Analysis from Design/Implementation

ODM

RIM / DMIM

Problem-Space Model (a la HL7 Development Framework)

RMIM / HMD / XSD

Leve

l of

Abs

trac

tion

Maintaining and Evolving BRIDG(circa 2007-present)

• Infrastructure Management

• Model Maintenance

• Model Harmonization

• Education

Infrastructure: ~25% FTE

• Web hosting, List Serve, Tech Support

• gForge capabilities for• Error Logging• Version Management

• Additional Reporting Capabilities• Model in an RDBMS• Support for other tooling options

Education: ~??% FTE

• Outreach to SDOs

• “How to Utilize the BRIDG Model”

• Currently task-shared by multiple THC members

Model Maintenance: ~50% FTE

• Recasting model to reflect ongoing input• Representational changes only• Creation of illustrative Instance Diagrams• Management of Mapping Documents• Management of Release Notes• Monitor of internal consistency (definitions, etc.)

• Scribe during THC meetings

Model Harmonization: ~150% FTE

• Partitioning Responsibilities• ~25% FTE THC Manager (Planning THC meetings, calls, etc.)• 5x ~25% FTE THC participants (1 FDA, 2 CDISC, 2 NCI)

• THC meets monthly for 3 days + 1 concall/week

• THC has adopted principles and practices to make harmonization more efficient and effective

• THC continues to define principles and practices to make harmonization more timely and agile

Lessons Learned:Using a DAM

• DAMs need to be applied in the context of a larger development (message, service, application) management process

• DAMs should be both domain-friendly and semantically robust (technology useful)

• In order to be truly effective, standards development needs to become less like the Waterfall and more ‘Agile,’ i.e. embedded in an interactive, iterative, incremental process.• Exemplar process has been successfully piloted at NCI and is now

ready for application to all projects

• A DAM that is ultimately used in message, application, or service development needs to address

• Data Type bindings• Terminology bindings for coded data types

Lessons Learned:Working with BRIDG (1)

• BRIDG only makes sense ‘in context’• e.g. message development, application development, service specification,

etc.• Analysis Paralysis occurs otherwise• Most effective use is in the context of an iterative/incremental development

process (e.g. RUP, SCRUM, Agile, ect.)

• NCI has integrated use of the BRIDG Model (and the use of analysis models in general) into its development practices

• HL7 RCRIM appears to be ready to do the same

• The BRIDG domain-of-interest is stable after 4+ years of use• Protocol-driven research involving human, animal, or device subjects and

associated regulatory artifacts• Recently, questions have been raised as to whether the BRIDG domain-of-

interest should include post-marketing safety/adverse events• Initial indications are that the answer is ‘Yes’ and that the effect on the model’s

structure will be minimal

Lessons Learned:Working with BRIDG (2)

• Teams need to start with the existing BRIDG Model• Subset as needed based on project focus• Add new semantics (e.g. classes, attributes, relationships,

business rules, etc.) as needed• All new editions must be rigorously defined

• Identify existing elements in the BRIDG model which are incorrect, unclear, too restrictive, etc.

An Agile THC Process:Maximizing the Benefits of Shared Semantics

• Projects start with the BRIDG Model (current version) as base analysis model

• Add, subtract, etc. to starting model as needed• Project team maintains an up-to-date Mapping Document

• Communicate as frequently as needed with THC regarding newly discovered semantics, deltas in the existing model, etc.• Assess “semantic ripples” of project• THC schedules harmonization as needed

• Process has worked effectively at NCI• When process is not followed, interoperability problems result

BRIDG circa 2008:Separating Analysis from Design/Implementation

Requirements

Fro

m W

ish

to R

ealit

y

Analysis

Messages Services Applications

Design

Messages Services Applications

Implementation

Messages Services Applications

Implementation-dependencies

Technology/platform bindings

What Doesn’t Work

• Retrograde harmonization of design artifacts into the BRIDG model• Loss of traceability from requirements• Considerable reworking for design team in face of “semantic

consequences” resulting from/impacting other projects• Loss of value proposition of a DAM, i.e. a model of shared semantics

What Hasn’t Worked:Post-design Analysis

Requirements

Fro

m W

ish

to R

ealit

y

Analysis

Messages Services Applications

Design

Messages Services Applications

Implementation

Messages Services Applications

Implementation-dependencies

Technology/platform bindings

Evolving BRIDG:July 2008 (1)

• BRIDG Model is increasingly being referenced as the ‘standard’ for defining the semantics of “Protocol-Driven Research and associated regulatory artifacts”• Original domain definition and scope have been stable for over 4

years this is a well-circumscribed domain-of-interest

• BRIDG Model is increasingly being utilized as a basis for both application and data interchange development• Domain Analysis Model for HL7 RCRIM• FDA HL7/CDISC Messaging Project• NCI utilization within CTMS Work Space• Pharmaco-vigilence project in Europe• others…

Evolving BRIDG:July 2008 (2)

• Increased visibility brings increased responsibilities• Requirements for

• Content Coherence

• Content Responsiveness

• Versioning and Infrastructure Management

• Reporting Capabilities

• Robustness suitable for possible formal standards balloting

• Increased scrutiny from both Developer and Domain Expert communities for a model that ‘makes sense’ to each given their perspective on the notion of ‘shared semantics in a well-defined domain’

The Problem with the current BRIDG Model: SME Perspective (examples)

• BRIDG Model has become ‘too complicated’ for most SMEs to easily understand• “Where are my words?”

• E.G. “An Adverse Event is a type of Observation”• “We don’t use the word ‘arm’”• “That’s not what we call it on submission”

• SMEs tend to be focused on a particular ‘sub-domain’ (< 8 total)• Protocol Representation• Study Scheduling/Execution• Analysis/Reporting• Adverse Events• Common Infrastructure (e.g. Persons, Organizations, etc.)

• Certain constructs in the current model have little relevance to the average SME• Data Type bindings could be hidden

The Problem with the current BRIDG Model:(RIM) Developer Perspective (examples)

• Requirement for domain explicitness has moved model away from normal modeling abstractions to somewhat artificial duplications of structure• Protocol phases as ‘pillars’ causes unnecessary (and confusing)

duplication of classes and attributes• Use of UML stereotypes to partially solve the question of ‘Where are

my words?’ is leading to a model that is increasingly difficult to unambiguously map to the RIM

• ‘islands of observations’ from attributes named with domain-friendly terms but actually containing complex semantics from a RIM perspective

The Current BRIDG Model

Varying levels of abstraction, explicitness, and ‘RIM-compliance’

Understandable to Domain Experts

Unambiguously mappable to HL7 RIM

The Revised, 2-layered (2-views) BRIDG Model (Alpha release date Oct. 08)

Consistent levels of abstraction and explicitness in multiple sub-domain ‘Requirements Models’

Consistent levels of RIM-compliance and explicitness in a single ‘Analysis Model’

Sub-Domain 1 Sub-Domain 2 Sub-Domain 3 Sub-Domain 4 Sub-Domain 5

Understandable to Domain Experts

(DaM)

Unambiguously mappable to HL7 RIM

(DAM)

NOTE: Sub-domains may or may not intersect semantically

Understanding a Domain-of-Interest

Follow traditional object-oriented methods for defining requirements including knowledge acquisition and engineering and building of analysis artefacts. Expectation setting is critical. Collect information from authoritative sources. Describe a structured interpretation of the acquired knowledge. Pictures are very helpful in understanding a domain.

-- Representing Information Using OWL

Lee W. Lacy

Visual Conceptualization

(UML DAM)

Ontologic Representation

(OWL-DL)

DAMs and Ontologies (1)

Domain-of-

Interest

Visual Conceptualization

(UML DAM)

Ontologic Representation

(OWL-DL)

A UML picture is wortha thousand

Requirements Documents words

An OWL-DL definitionis worth at least several

UML classes

visualized by

described by

DAMs and Ontologies (2)

Domain-of-

Interest

Visual Conceptualization

(UML DAM)

Ontologic Representation

(OWL-DL)

A UML picture is wortha thousand

Requirements Documents words

An OWL-DL definitionis worth at least several

UML classes

form

ally

spe

cifie

s / i

nfor

ms

the

repr

esen

tatio

n of

provides input for /

is vetted by

Is described by /facilitates computational in

BRIDG circa 2008Separating Analysis from Design/Implementation

Requirements

Fro

m W

ish

to R

ealit

y

Analysis

Messages Services Applications

Design

Messages Services Applications

Implementation

Messages Services Applications

Implementation-dependencies

Technology/platform bindings

AQ&Q U E S T I O N SQ U E S T I O N SA N S W E R SA N S W E R S