Building, Maintaining, and Evolving a Model of Shared Semantics -- The BRIDG Project: Lessons Learned and Next Steps Charles Mead MD, MSc Chief Technology Officer National 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 Problem Space Solution Space Implementation-Independent Implementation-Specific Abstraction

BRIDG circa 2004: Separating Analysis from Design/Implementation ODM RIM / DMIM Problem-Space Model (a la HL7 Development Framework) RMIM / HMD / XSD Level of Abstraction

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 From Wish to Reality Analysis MessagesServicesApplications Design MessagesServicesApplications Implementation MessagesServicesApplications 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 From Wish to Reality Analysis MessagesServicesApplications Design MessagesServicesApplications Implementation MessagesServicesApplications 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 1Sub-Domain 2Sub-Domain 3Sub-Domain 4Sub-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 worth a thousand Requirements Documents words An OWL-DL definition is 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 worth a thousand Requirements Documents words An OWL-DL definition is worth at least several UML classes formally specifies / informs the representation of provides input for / is vetted by Is described by / facilitates computational in

BRIDG circa 2008 Separating Analysis from Design/Implementation Requirements From Wish to Reality Analysis MessagesServicesApplications Design MessagesServicesApplications Implementation MessagesServicesApplications Implementation-dependencies Technology/platform bindings

A Q & Q U E S T I O N S A N S W E R S