th

Boris Brodsky, FDA

Jean-Henri Duteau, Duteau Design

Hugh Glover, Blue Wave/Parexel

Terry Hardin, Parexel

Smita Hastak, Samvit Solutions

Wendy Ver Hoef, Samvit Solutions

Julie James, Blue Wave/Parexel

Armando Oliva, FDA

Jane Pollack, NMDP

Diane Wold, CDISC

Structural Terminology Comments Dependence on structural terminology in AE example. E.g.
PerformedObservationResult has type code constrained by CD that describes the AE itself.

If we decide the terminology content should change, how do we create it as part of BRIDG release, and what level of depth? Start with what’s already in BRIDG. E.g. for empty classes, could be using type codes (possibly in place of existing attributes).

Another example of Structural terminology: Need to distinguish between organizational functions and types: Type may not be determined by function, since the type never changes, but the role/function may change. (Similar to HL7’s entity vs role).

Implications for modeling conventions (e.g. empty classes): Keep context out of the terminology
(e.g. BRIDG reason codes); otherwise, results in a very large model, difficult to use. Challenges with expressing negation (something was not done).
Summary: We need terminology bindings, structured and domain. The latter is a challenge, resourceintensive, hence want to leverage established ones. The former is in the purview of this group, could schedule calls for each data element or a subset of classes to get this started
Very specific concepts, embedding a range of semantics.
Deferred the discussion, to take place in parallel with the architectural review.
Sustainable information architecture requires separation of architectural decisions from user presentations.

Differences in skill sets between domain experts, business analysts, and information modelers.
1


Without a separation, overlapping requirements of different stakeholders would result in an unnecessarily complex model (which becomes particularly critical as the model evolves over time through multiple projects).

Domain experts may tend to mistakenly relate the visual prominence of a class/attribute and its conceptual importance.

Multiple presentation views could be created for different types of users (modelers, analysts, domain experts) with a single underlying architecture.

The separation allows making significant changes to the underlying architecture without affecting the presentation views (i.e. the information model is transparent to the end users).
Opened the discussion, to be continued at the next meeting.
How are the Presentation Views related to the various BRIDG User Types? Are we saying we would develop views for various BRIDG User Types?
BRIDG has multiple user types and each has a specific role to perform and contribute. We need to decide who is the main target audience of BRIDG: a.
Subject Matter Experts i.
Provide the business use cases, identify the relationships between concepts, help identify and build terminology; identify the attributes/properties of concepts; identify lifecycle of certain concepts; build definitions, validate concepts and relationships; etc. b.
Analysts/Modelers i.
Work with SMEs to convert the business use cases and domain concepts into an implementable model; flesh out the business requirements (data and process) in further detail; Identify and flesh out the gaps in domain representation; maintain model integrity, identify and assign appropriate data type and vocab bindings, develop state transitions, etc. c.
Architects/Developers/Implementers i.
Develop design strategies to implement a model; build out a platform specific implementation approach(es) (database, data exchange, etc.); Build out the need system and supporting artifacts, etc.
BRIDG started off with being a model for the Subject Matter Expert group, but very quickly the SCC realized that the greater value of the shared model was to the Analysts/Modelers and Implementers since these are the groups that will help build out the BRIDG vision of shared semantics and support interoperability.
2