caBIG: Using the BRIDG Model:  Application Development vs Message Specification
Throughout the course of the BRIDG Project’s 3-year history, there has been speculation that the perspectives of the stakeholders interested in message specification (i.e. HL7, CDISC, and FDA) would have different requirements or expectations of a DAM compared to those of stakeholders concerned with application development (i.e. NCI).  To date, that has not been the case and, therefore, R1.0 of the BRIDG Model reflects a common consensus of domain-of-interest semantics although the bulk of the dynamic content of R1.0 does come from the NCI’s CTMSi (Clinical Trial Management System interoperability) project.    The reasons for this continued unity most likely result from the fundamental link that exists in the domain-of-interest between the business processes that drive data exchange and the semantics of the data elements themselves.  Future evolution of the BRIDG model will indicate whether it becomes necessary to split off the high-level constructs of the model (e.g. the BRIDG Backbone of Release 1.0) from stakeholder-specific views such as “cancer research,” “applications,” “messages,” “drug development,” etc.  It should be stressed that even if such package partitioning becomes necessary, the overarching  scope definition of the BRIDG model remains the unifying force that will motivates the four current stakeholders involved in presenting the shared semantics of the BRIDG model.

Following are links to additional resources detailing how each of three of the four BRIDG stakeholder organizations are utilizing the BRIDG model (the fourth BRIDG stakeholder – the Federal Drug Administration – utilizes BRIDG indirectly by its influence and direction over both CDISC and HL7 RCRIM projects):

• HL7 RCRIM TC (need URL)
• CDISC (need URL)
• NCI/caBIG™ (need URL)

caBIG™ CTMS WS Silver Compatibility:  An Instance of Application Development Processes Using the BRIDG Model

  Although there is, to date, no essential difference in the semantic representation requirements for use of the BRIDG model as the basis for data interchange specification (e.g. CDISC or HL7 messages) vs the basis for application interoperability (e.g. NCI CTMS WS application interactions), there are certainly differences in the perspective of a team using the BRIDG model to define standards for static data interchange (i.e. system-to-system “messages”) vs those using the BRIDG model to drive application development and the exposure of Application Programming Interfaces (APIs).  A specific instance of this difference in perspective can be seen in the process that is emerging in the caBIG™ Clinical Trial Management System Workspace (CTMS WS).  While it is beyond the scope of the BRIDG 1.0 Release Notes to discuss the details of caBIG™ compatibility certification, the THC believes that a brief review of the use of the BRIDG Model in this process is instructive to readers of the Release Notes.

In summary, the sequence of steps is as follows:

• application teams begin their analysis activities by downloading the current release of the BRIDG model;
• as they work on their specific requirements gathering and specification tasks, they add or modify the content of their instance of the BRIDG model;
• in parallel, they derive a Mapping Document first performing their analysis modeling (as part of requirements specification) using a model built from the current BRIDG release;
• at a point where the team believes it is ready to freeze its analysis artifacts, it presents its “harmonizable BRIDG artifacts” (i.e. static and dynamic semantics represented appropriately in various UML diagrams as discussed above) to the THC;
• a collective decision is made on each proposed mapping and changes, if necessary, are made to the mapping document;
• post-harmonization, the project team modifies its implementation to reflect semantic changes (e.g. disambiguations) in its initial analysis models;
• if necessary, the process is repeated;
• the project team’s final BRIDG-compliant specification is registered in the caBIG™ Data Standards Repository (caDSR) with BRIDG elements receiving unique Concept Unique Identifiers (CUIs);
• the project’s static analysis artifacts are processed by a series of caBIG™ infrastructure tools resulting in the publication of BRIDG-compliant, registered APIs that can be accessed by other applications in the caBIG™ infrastructure.

     The use of the BRIDG model as a fundamental piece of the CTMS WS infrastructure facilitates the process of building applications that can exchange data at a computationally semantically interoperable level.

  Relationship of the BRIDG Model to the HL7 Reference Information Model (RIM)

As shown in FIGURE 2, the HL7 RIM is a cross-domain model that is distinctly not domain-expert friendly because it is designed to abstract the static semantics common to multiple domains into a single representational view.  The domains-of-interest to the RIM include, but are not limited to:

• clinical care (inpatient and outpatient)
• healthcare administration
• reimbursement
• community care
• veterinary care
• genomics
• imaging.  

Although the RIM is, for the most part, relatively free of implementation details, it is not a DAM because, as just mentioned, it is not readily understandable by domain experts in any one of the listed domains (e.g, “Where are vaccinations in the RIM?” “How do I represent a provider credential?”  “Where is a SNP found?”, etc.), a fact that arises from the requirement that the RIM abstract cross-domain semantics.  However, because it is important to the BRIDG stakeholders that BRIDG semantics be expressible in HL7 XML, the THC is responsible for ensuring that BRIDG semantics can be represented in RIM structures.  If this is not the case, the THC works with project teams to bring their specific semantics to HL7 for harmonization of the RIM, i.e. expansion of RIM semantics.  To date, only a handful of such instances have been identified and have, in fact, been included in the current RIM.  (NOTE:  Saying that BRIDG semantics are mappable to the HL7 RIM does not mean that the mappings are one-to-one, e.g. attribute to attribute.  In fact, they are most often not of that nature., i.e. a BRIDG class doesn’t often map to a RIM class (exceptions being concepts like “Person” or “Role” and, likewise, a single attribute in the BRIDG model may map to a combination of RIM attributes or a collection of RIM data type properties.  The details of the mapping are not important.  Semantic equivalence is the critical issue.) 

In the context of ensuring that BRIDG to RIM mappings can be built by interested project teams in the course of either message or application development, the THC follows a general guideline of using RIM-like structures whenever such use can be done without obscuring the required domain friendliness of the BRIDG representations.  So, for example, BRIDG distinguishes the notion of a “static role” (role played by an organization, person, or material) from a “dynamic role” (role assumed in the context of an activity), but uses a different, more domain-friendly term for the latter concept (FunctionalRole  rather than Participation.)   Also, as previously discussed in Section 2, the THC consistently chooses explicit rather than RIM-flavored implicit representations of concepts to ensure whenever possible that the BRIDG model will be readily understandable by domain experts familiar with the concepts, attributes, and relationships in the BRIDG model’s domain-of-interest.

Use of RIM Color-coding in the BRIDG model

One area of high commonality with the RIM is the use of color coding in the static views of the BRIDG model.  The RIM derived its inspiration for using color codes from an important book by Peter Coad et al entitled “Java Modeling in Color with UML.”  Coad argues that there are certain “archetypes” present in virtually all static models, e.g. Parties (Persons or Organizations) acting in Roles (time-limited Capabilities, Capacities, or Competencies) participating in Events.  He also states that there are often “libraries” or “repositories” of static information that are utilized in various ways by the Parties, Roles, or Events.  For each of these archetypes, he assigns a color:  Green (Party), Yellow (Role), Red (Event), and Blue (Library).  He then observes the existence of a number of simple “visual rules” which are true for all grammatically correct models, e.g. “green must have yellow between it and red,” thereby allowing a model to be grammatically validated “from across the room.”

Because the early builders of the HL7 RIM felt that this approach had significant merit, it was adopted with some necessary modifications.  In particular, the HL7 RIM adopted verbatim Green for its Entity class hierarchy (Party was abstracted to Entity to allow for the inclusion of animals, tissues, and materials/devices), Yellow for the Role hierarchy, and Red for the Act hierarchy (Event was abstracted to Act and a rich sub-class hierarchy was created to cover the specific semantics of a number of cross-domain Acts such as Substance Administration, ObservationResult, etc.).   The RIM then added three additional colors for its three “relationship” classes:  the Participation class -- Role in the context of an Act -- which relates static Role instances to dynamic Act instances was assigned turquoise (to distinguish it from Coad’s blue), the ActRelationship class which specifies the semantics linking two instances of the Act class was assigned light red (pink in the BRIDG model), the RoleLink class specifying the semantics of complex role-to-role relationships was assigned light yellow (NOTE:  to date, the semantics of the RoleLink class have not appeared in BRIDG domain modeling sessions although they can be expected to at some point in time in the future.)  Blue was used for RIM infrastructure and is accordingly used in the BRIDG model for BRIDG complex data types.  Like HL7, the BRIDG THC has found the use of “the grammar of color” – Green à Yellow à Turquoise à Red à Pink à Red -- to be very helpful in orienting domain experts to the basic semantics of a particular static statement, a fact that is demonstrated in other sections of these Notes where specific instance-diagrams are presented to clarify particular BRIDG representational choices and in which the color grammar is immediately noted.

The RIM Participation and BRIDG FunctionalRole Classes

The difference in the semantics of the BRIDG Role class – time-scoped capability, capacity, or competency – vs the BRIDG FunctionalRole class – Role in the context of an Activity – have been previously discussed.  The motivation for the use of the name FunctionalRole in BRIDG vs Participation in the RIM was simply one of clarity and domain-friendliness, resulting in large part from the common domain usage of the term participant to refer to the role of a patient that is, at some point, enrolled as a ResearchSubject in a particular clinical trial.  The THC felt that the use of the term “participant” as a Role would be confusing in if a “ResearchSubject” were then represented as a subtype of a class called Participation.  Future releases of the BRIDG model are expected to expand considerably on the explicit representation of the semantics of a number of trial-specific “roles” which will be, by virtue of their association with the Activity of a trial, be represented as subtypes of the turquoise class FunctionalRole.   

In the HL7 RIM, there are actually two Participation classes:  the supertype Participation and its sub-type ManagedParticipation, the latter adding the two attributes necessary to track state – ID and status – to the attribute set of its parent.  Discussion of the reasons for this separation in HL7’s RIM is beyond the scope of this document.  However, because there are specific use cases in the BRIDG domain supporting the concept of ManagedParticipation (e.g. supervised vs unsupervised procedure execution), the BRIDG model places all attributes of the two RIM classes in a single FunctionalRole (turquoise) class.

Exemplar HL7 Code Lists

Appendix C contains a number of enumerated code lists for HL7 core HL7 Version 3 concepts that have either been directly or indirectly represented in the BRIDG Model Release 1.0.  These include:

Act.status (from Act StateDiagram)

Role.status (from Role State Diagram)

ManagedParticipation.status (from Act State Diagram)

ActRelationship.typeCode

ManagedParticipation.typeCode

Act.moodCode

The Absence of HL7 “Act.moodCode”:  A Specific Example of RIM vs BRIDG Representational Choices

Readers familiar with the HL7 RIM will immediately recognize the BRIDG explicit representation of Planned, Scheduled, and Performed Activities and Calendars as explicit representations of a concept that HL7 refers to as mood.  The THC has chosen to use an explicit representation of these three major business process phases of a clinical trial rather than hide the semantics in a value of an attribute such as Activity.businessProcessCode¸ whose value set would presumably be PLANNED/SCHEDULED/PERFORMED.  At present, it has been consistently stated by domain experts in the context of harmonization meetings that this explicit representational choice was far more user friendly than the latter, more RIM-friendly representation.  Going forward, if the domain community that is represented by the BRIDG model becomes sufficiently comfortable with the folding of the model’s current explicit representation of these well-known phases of a study/protocol/trial into a single multi-valued attribute similar to the HL7 mood attribute, the THC will make the appropriate representational changes in the model.  At present, the important fact is that BRIDG model semantics around the RIM concept of Act.mood remain mappable between the BRIDG model and the RIM.

A Brief Explanation of the concept of “mood”

One of the most significant knowledge representation decisions made so far in the course of the BRIDG Project has been around the representational choices used to capture the well-known but not standardized representation of a somewhat obtuse concept that HL7 has named mood (manifest in the value of the moodCode attribute of the RIM class Act and its various subtypes.)  The name of the concept comes from the world of grammar:

In linguistics, many grammars have the concept of grammatical mood (or mode), which describes the relationship of a verb with reality and intent. (WikiPedia)

The term is used in HL7 to distinguish “phases of a business process through which multiple instances of a concept can pass” from “state:  the named phases of the life cycle of an instance of a concept.”  If one studies this definition carefully, one realizes that the concepts of state and mood are orthogonal, i.e. they each describe different perspectives on complex business processes and workflow, the former (state) describing phases of the lifecycle of a single instance of the concept, while the latter (mood) describes the phases of the business process itself, through which multiple instances – each in a different mood --  may pass.  It is beyond the scope of this document to explain or explicate the notions of mood and state in more detail.  However, for reference, we have included the list of values that the moodCode attribute of the Act class (FIGURE 24) may assume (one value per instance for its entire existence), in contrast to the values of the status (i.e. state) attribute (FIGURE 25) that an instance may assume during its life cycle and that are exactly equivalent to the named states in the Act State Machine diagram (FIGURE 22).

In the domain of BRIDG, there are several well-known (if not completely robustly delineated) phases of the clinical trial business process, e.g. Plan, Schedule, Execute/Perform, Analyze, Report.  In HL7 terms, these would be values of the moodCode of the various ‘Act instances’ that occurred during this ‘business lifecycle’ of a clinical trial (e.g in terms of the BRIDG Backbone, the various instances of Documentation, Activity, ObservationResult, and Assessment that were collected within an instance of a particular Study Protocol.)  As is the case in many domains besides BRIDG, one finds that at the analysis level, there are many common structures (i.e. classes and attributes) shared across business process phases.  However, one also quickly discovers that there are small but essential differences, e.g. a scheduled Calendar is associated with a specific Study Subject whereas a Planned Calendar is not even though the two calendars contain virtually identical information with the exception that the Scheduled Calendar uses absolute dates and the Planned Calendar uses relative dates.  (A similar difference in “mood-based attributes” is found in clinical care when an order for a specific test does not contain a result value and contains somewhat different details of time specification, in many ways similar to the timing differences between a Planned Calendar and a Scheduled Calendar.)

Early versions of the BRIDG model attempted to use a single attribute called businessProcessMode which was modeled directly off of the HL7 attribute Act.moodCode to simplify the model by allowing reuse of classes (with the caveat that there needed to be mood-specific restrictions on attribute usage).  This approach was found to be too confusing and obfuscating to domain experts.  As a result, the composite BRIDG model contains explicit structural manifestations of each ‘mood’ of a clinical trial.  Specifically present in Release 1.0 are the ‘moods’ of “Planned,” “Scheduled,” and “Performed.”  To emphasize the differences (and similarities) of these three business process phases (aka ‘moods’), we present each in a separate view (FIGURES 6-8.)  Future versions of the BRIDG model may, in fact, adopt a representation strategy that collapses the static structures in a manner similar to that used by HL7.  As has been stated previously in this document, the choice of representational style has been – and will continue to be – driven by the overarching requirement that the BRIDG model be easily comprehensible to domain experts familiar with and working in the domain spanned by the BRIDG model.