CCTS Messaging Architecture

From CTMS_WIKI

Introduction

Background

The caBIG Clinical Trials Suite (CCTS) is an enterprise clinical trials system being designed primarily for use in trial sites. The suite is comprised of a collection of interoperable modules covering a broad range of key areas in cancer clinical trials management. These include patient registration via C3PR, patient scheduling via PSC, adverse events reporting via caAERS, lab analysis via LabViewer, and clinical data management via C3D. Integration between these applications is centered around five key scenarios: Study Creation, Register Subject, Load Labs in CDMS, Lab-driven AE Creation, and AE-Triggered Schedule Change. The implementation is based upon the caGrid infrastructure with caXchange as the Enterprise Service Bus for reliable message routing and GAARDS providing robust security.

Scope

This document is a work in progress used strictly for planning for the CCTS 2.0 release. Up until that release, it could be altered in any way.

Related Documentation

Requirements

Architecture

Semantics

In order to implement the use cases and workflows within CCTS, a messaging infrastructure is leveraged to exchange data between different applications. This infrastructure consisted of both message structures based on BRIDG model semantics as well as a physical infrastructure (for example, grid services and ESB). These messages contain information that supports both discrete business functionality ("register subject", for example) and the information component ("patient id", for example). These messages are unwrapped and examined to find the explicit rules covering their routing and processing based on predefined business rules.

For example, in order to facilitate a patient registration to a study, a "patient registration message" is communicated from C3PR to PSC, C3D, caAERS, and LabViewer. These messages contain the necessary data from C3PR that the other applications need to place a "subject" on a "study". In order for the other applications to be able to handle the message, it must be semantically harmonized (pre-coordinated) across the applications. Furthermore, it must either be syntactically harmonized or a translation must be performed.

Semantic harmonization is facilitated by the BRIDG model, which provides a basis for the informational semantics of the business process. BRIDG is a domain model for the analysis of clinical trials that provides a core set of concepts that are shared across each application participating in a business case. The subset of BRIDG necessary to meet the messaging use cases has been adopted and extended for use within CCTS. The CCTS messaging semantics are supported by BRIDG to the fullest extent possible. The BRIDG model can be located at www.bridgmodel.org.

Image:CCT BRIDG Overview.jpg

The model leveraged in CCTS has classes related to participants, organizations, labs, and adverse events. Each message in the workflow does not need to capture all of the semantics of the entire model, so for each message, the BRIDG-derived model is subsetted into a smaller model that captures a single message. The following is the BRIDG harmonized model of the registration message that is passed out of C3PR.

Image:CCTS Registration Model.jpg

BRIDG-based implementation models and XML Schemas can be found in the CCTS Interface Specification.

Syntactics

It is necessary but not sufficient to harmonize the informational semantics of the messages across both applications and scenarios. If the meaning of the inbound and outbound messages are the same, then the application should be able to consume of them or some formatted translation of them. However, it is convenient that the syntax, or structure, of the message is also harmonized, and it is necessary that the structure is known to each application. To this end, an XML Schema is produced from the messaging models that realizes the semantics of the BRIDG harmonized model. The following diagram shows the registration message XML schema.

Image:CCTS Registration Schema.jpg

Messaging Identifiers

In order for messages to be locally persisted and hooked into existing data, a consistent set of identifiers should be used to cross-link data. This document describes those identifiers on a message-by-message basis.

CCTS currently supports the following messages:

• Create Study: study message sent from C3PR to PSC, caAERS, and LabViewer
• Register Subject: registration message sent from C3PR to PSC, caAERS, LabViewer, and C3D; response required from C3D
• CT Load Labs: lab messages sent into LabViewer through caXchange
• Load Labs: lab messages sent from LabViewer to C3D
• Lab-based AE: lab message sent from LabViewer to caAERS
• Schedule Modification: schedule modification message sent from caAERS to PSC

The following identifiers are sent for cross-linking:

Semantics and Syntactics Infrastructure

As described in the previous sections, messages are based upon BRIDG-derived models that are realized with corresponding XML Schemas that define the syntactic structure. The semantics of the messages, while BRIDG derived, is registered in the caDSR (Cancer Data Standards Repository). This provides a central repository for classes and attributes to be registered as data elements with semantic concepts registered in the EVS (Enterprise Vocabulary Service). Centralizing the registration of these models allows for common data elements to be shared across models, providing for a basis for semantic interoperability, as well as grid and non-grid based mechanisms to discover and consume of the semantic metadata. In a similar fashion, XML Schemas are registered and shared in the GME (Global Model Exchange), which is a centralized grid service for advertising and consuming of XML Schemas. This allows for the syntactics of the messages to be available when developing and consuming of services outside of the context of the service itself.