Stakeholders

Stakeholders of BRIDG

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 — 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”

 

Steve Bridge

University Researcher at On Leave
I'm a researcher specialising in microbiological data analysis, including the natural ecosystem influences and changes over time.

Latest posts by Steve Bridge (see all)