BRIDG deeper look

First of all, a good fundament in the BRIDG model is done by dividing participating entities (e.g. Activity->Observation) into three pivotal stages in the business process (see Figure 1 and Figure 2):
  • Defined - DefinedActivity->DefinedObservation, measurements that frequently occur and therefore are called out as a reusable templates stored in a global repository. They have a complex structure (e.g. eCRFs template repository) involving other components and/or qualifiers using the associated relationship classes (DefinedCompositionRelationship).
  • Planned/Scheduled - A PlannedActivity->PlannedObservation (missing in BRIDG) may be a container of other activities (or observations) and have a complex structure involving components, options and contingencies using the associated relationship classes (PlannedCompositionRelationship).  This structure allows representing elements included in e.g. CDISC/Study Design Model such as CellDefs, SegmentDefs, ActivityDefs ...
  • Performed - PerformedActivity->PerformedObservation, the completed action of observing, monitoring, measuring or otherwise qualitatively or quantitatively gathering data or information about one or more aspects of a subject, study subject, experimental unit, or product.


Figure 1

In the face of continuously growing number of Therapeutic Areas (TA) it is important to have a flexible model which will allow to accommodate an arbitrary complex activity in an uniform way. As mentioned above the BRIDG model has mechanism to build complex aggregates using so called composition relationship link object. But composition participants (in this context an object of the class (or a subclass of) DefinedObservation) offer a bit clumsy way how to host an arbitrary number of measurement qualifiers. The class DefinedObservation has a series of "hard-wired" instance variables (like the bodyPositionCode or the targetAnatomicSiteCode) and a "sub-classing" mechanism is the only way to cover other qualifiers coming with new TAs. Doing so, there is no way out from this never ending muddling through scenario.

To find a way out of the above mentioned situation, the proposal is the fully normalized approach by implementing additional class called DefinedQualifier which stays in 1:n relation to the DefinedObservation class (see Figure 3). Such an aggregate noted a substantial improvement in the BRIDG model makes it closed and allow high level of automatism regarding the eProtocol Visit Schedule development process and subsidiary downstream activities (essentially an automatic eCRF generation process).


Figure 2

Other weaknesses of the current model:

  • Missing PlannedObservation class and his instantiation path (instantiated by corresponding object of class DefinedObservation and assigned to a planned Visit (the BRIDG SCC foreseen the class PlannedSubjectActivityGroup as an "instantiation body" for the planned Visit)
  • It is a consequence of the previous point. The class PlannedSubjectActivityGroup if embodies a planned Visit has no references. There is no way to link any Activities to the PlannedSubject ActivityGroup. In the BRIDG model example "SOA Example" utilizes the class the class PlannedActivity is used to instantiate a planned Visit object (consistency violation)
  • Wrong instantiation directions (see red arrows in the Figure 2). A performed object can't instantiate a planned object, and a planned object can't instantiate a template (defined) object. By the PlannedCompositionRelationship class there are also wrong cardinalities. By the DefinedCompositionRelationship and PerformedCompositionRelationship classes are directions and cardinalities corrected in the above mentioned figure.

To wrap-up, an instance of the DefinedObservation class is generally used as a template and operationally seen contain no date/time information.

An instance of the PlannedObservation object (missing in the BRIDG model) is instantiated by the DefinedObservation during the Visit Schedule creation process and in the first step is linked to a planned Visit object (planned date assignment). In the second step in the same process concrete time offsets (with respect to corresponding intervention) have been assigned using objects of the ScheduledActivity class.

To render the BRIDG model easy to read would certainly do well to use substantives of tangible (frequently used) things as class names by designing complex problem domains. In the BRIDG model the class PlannedActivity is unfortunately utilized as a multipurpose, proxy construct to embody totally different but pivotal stuff like a Treatment Period elements, Visits, Observations, etc.


Figure 3

BRIDG - Protocol hierarchical structure proposal

The BRIDG logical model operates using complex data types like ED or StrucDoc (of all kinds) which encapsulate document structure and formatting details to simplify a model under consideration. But by data centric document management approach the structure (topics/sections hierarchy) and associate narrative content (body) of a document plays substantial role and this has to be semantically taken into account also in the BRIDG conceptual model.

Therefore to keep meaningful control over Protocol document structure and content we propose additional enhancements to the "BRIDG Protocol Representation Sub-Domain". The above mentioned document structure should be explicitly visualized and together with associated narrative content mapped as a separate entities (see Figure 4). All proposed enhancements fully follow proposals indicated in the CDISC/PRM Document.


Figure 4

An implementation of the externalized document structure opens new opportunities to Regulatory Authorities. They would be in the position to propose (require) specific document structure (see DocumentStructureTemplate) depends on circumstances like TA.

Current StudyProtocolVersion entity accommodates coded and narrative attributes in the same way. In a relational model later on it will cause problems. A narrative long text exceeds from time to time the limit of 4000 chars for the Oracle VARCHAR data type and therefore should be generally treated as a character large object (CLOB). There is also other reason to separate narrative and coded elements. We need to maintain fine grained document access rights down to lowest document section level.

So we can distinguish between three categories of protocol document entities (see blue boxes in Figure 4):

  • study protocol entity (StudyProtocolVersion class) containing exclusively data which have coded/structured values (e.g. phaseCode)
  • document hierarchical structure of topics/sections (StudyProtocolDocumentNode class)
  • document narrative content (StudyProtocolDocumentBody class)

Resulting StudyProtocolDocumentNode class fully describes one node (further document node) in the hierarchical structure of a document. A document node can be numbered or non numbered topic with or without body (textual part), or a non numbered section within a topic. Each document node has a label (header). Each document node has an "OID" attribute which is unique within the document.  An attribute "restrictedTo" defines write-access to the document node for either all writers inclusive the Study Leader (value is null or "ALL"), or for restricted group of persons (coma terminated userid chain) having protocol writer role (see cyan colored box).

Resulting StudyProtocolDocumentBody class (further document body) fully describes a textual content of a corresponding document node. Each document body element is identified by the "OID" attribute which is unique within a document.  The attribute "content" refers to a data type with almost unlimited character storage capacity (CLOB by Oracle).

The two khaki colored boxes denote the possibility to initiate the document structure (and content) by parsing either xml-based (OASIS/DITA standard) document skeleton (see Figure 5), or a legacy WinWord document (an algorithm for both processes exist). The two yellow colored boxes denote so called data referencing mechanism used to keep actual value of coded attribute stored in StudyProtocolVersion and all associated entities (tables).  This mechanism guarantees data consistency between narrative text excerpt tagged as <span> and corresponding effective value in a database table. This is an obligation for advanced authoring tools overall where the final document is a mix of narrative and coded data originated in different locations (tables).


Figure 5

The Figure 6 shows the raw content of narrative text wrapped into a body node with the id="SHORT_TITLE". In the first span segment the system puts the text "open-label" which is the actual decoded value originating from the column "BLINDING_CODE" in the table "PROTOCOL_VERSION".


Figure 6

The Figure 7 shows the rendered narrative content of the above mentioned document body node in the eProtocol document navigation screen.


Figure 7

Enter your comment or question
Name/NicknameDate/timeComment