CCTS BRIDG 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 describes some of the motivations, challenges, and technical approaches to adopting BRIDG 2.1.

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

There are a number of challenges in harmonizing with BRIDG, including:

• Domain modeling
  • Correctly mapping and defining the implementation model for classes and attributes
  • Correctly mapping and defining the implementation model for complex datatypes
• Implementation of complex datatypes
  • Mapping complex datatypes to the backend database
  • Integration with analytical service layers (e.g. serialization)
  • Integration with data service layers (e.g. HQL access to complex datatype values)
• Flavors of null
  • Choosing which flavors of null to send
  • Correctly handling flavors of null
  • Implementing and serializing flavors of null
• Registration and mapping in the caDSR and EVS
  • Registering CDEs with complex datatypes
  • Mapping registered CDEs and concepts back to BRIDG CDEs and concepts

The following sections address these challenges and the architectural approach to solving them.

Domain Modeling

Each project in CCTS derives their domain model from BRIDG 2.1.

Correctly mapping and defining the implementation model for classes and attributes

Each application team generates BRIDG 2.1 compliant analysis and implementation models using the standard BRIDG implementation process. These models are reviewed by CCTS Analysists and Architects to determine whether the models have been implemented appropriately.

Correctly mapping and defining the implementation model for complex datatypes

Each application team leverages complex datatypes by performing the following mappings:

• Combine existing attributes into a single complex attribute (e.g. parts of a postal address into AD)
• Replace an existing class(es) with a single complex attribute
• Replace an existing attribute with a single complex attribute

Implementation of ISO Datatypes

BRIDG 2.1 leverages a number of complex datatypes from the ISO 21090 specification (HL7 also derives datatypes from this specification).

Mapping complex datatypes to the backend database

Standard Hibernate mapping is leveraged for attributes with complex datatypes. Each complex datatype is implemented by a Java class (implementations from COPPA are leveraged wherever possible). Standard Hibernate ORM is leveraged to map the complex types into database tables.

Integration with analytical service layers (e.g. serialization)

Custom serializers are leveraged to create compliant XML from the complex datatypes. These serializers are plugged into the caGrid infrastructure.

Integration with data service layers (e.g. CQL access to complex datatype values)

For purposes of grid querying, a new CQL construct is implemented called ComplexAttribute. It takes a name (the name of the attribute) and allows the user to query into the attributes of the complex type. The XSD for this would be something like:

<xsd:complexType name="ComplexAttribute">
  <xsd:annotation>
    <xsd:documentation>An attribute with a complex type</xsd:documentation>
  </xsd:annotation>
  <xsd:complexContent>
    <xsd:extension base="cql:Object">
      <xsd:attribute name="name" type="xsd:string" use="required"/>
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

A custom CQL implementation based on the caGrid implementation is leveraged to implement the ComplexAttribute construct. It behaves very similarly to the Association construct.

Flavors of Null

When value are uncertain or unknown, ISO specifies a variety of values called flavors of null that can be leveraged.

Choosing which flavors of null to send

Each project team defines the attributes that are appropriate for substituting values with flavors of null. These are tied directly to business use cases.

Correctly handling flavors of null

In the case of business use cases for handling flavors of null, each product implements the appropriate handling of flavors of null. For example, when a subject name is not captured during registration, each application handles the flavor of null appropriately. In the case when flavors of null are not exchanged according to known business flows, each product acts on a documented default policy (e.g. rejects the message for partial data, accepts empty values for certain attributes, etc.)

Implementing and serializing flavors of null

Each flavor of null is represented by a Java class with appropriate serializers and deserializers. In addition, the XML Schemas for all messages must take into account that flavors of null may be exchanged instead of actual data.

Semantic Registration and Mapping

To facilitate dynamic discovery, computable semantics, and sharing of semantic metadata, each product registers its models (with ISO datatypes) in the caDSR and has concepts registered in the caDSR.

Registering CDEs with complex datatypes

The caDSR has the appropriate ISO datatypes registered as caDSR datatypes, so all models registered with ISO datatypes are automatically associated with the appropriate caDSR datatypes. The Semantic Integration Workbench (SIW) is updated to handle this.

Mapping registered CDEs and concepts back to BRIDG CDEs and concepts

Wherever there is full overlap with BRIDG 2.1 and a product's domain model (e.g. class, name, and concepts), CDEs are automatically reused. Wherever there is not complete overlap, then separate CDEs are created within in the caDSR. However, these are manually linked back to BRIDG CDEs wherever appropriate.