**Crosscutting Model Harmonization White Paper**

> ***Final Version***
>
> **November 20, 2006**

Steven D. Sandberg

Robert R. Freimuth, Ph.D.

Christopher G. Chute, M.D., Dr.P.H.

Mayo Clinic College of Medicine

# Executive Summary

caBIG workspaces have produced remarkable proposals, plans, products,
and services. However, many have commented that these efforts are not
coordinated beyond semantic content managed by VCDE -- specifically some
the information models or object architectures failed to borrow from
each other or in some cases even align due to lack of coordinated
process or design.

A task force was convened by the Strategic Planning group to examine
this question, and a []{#TaskRptRef .anchor}preliminary report[^1] was
issued in the summer of 2006. The problems statements, analyses, and
recommendations within this task force report were uniformly
well-received. The present white paper is an expansion of the task force
document to include more background; however, the conclusions and
recommendations have not substantively changed. These are presented in
detail below. The major points include:

-   Semantic interoperability cannot be sustained by normalized
    vocabulary and data elements alone -- information model alignment is
    also required.

-   Creation of a shared Backbone Model is demonstrable and desirable.

-   The BRIDG project has forged considerable experience and products in
    a manner consistent with our topic, and some of the tools and
    processes within BRIDG might be leveraged to build a caBIG-wide
    activity.

-   A standing group should be established within caBIG for Backbone
    Model creation and maintenance, architectural alignment of caBIG
    artifacts, and coordinated adoption of shared information models.

Table of Contents

[1 Executive Summary 2](#executive-summary)

[2 Preface 4](#preface)

[3 Background 4](#background)

[3.1 Use Cases 5](#use-cases)

[3.1.1 Information Model for a New Application
5](#information-model-for-a-new-application)

[3.1.2 Maintain An Existing Model 7](#maintain-an-existing-model)

[3.1.3 UK NCRI Defining Example 7](#uk-ncri-defining-example)

[4 Large Scale Model Harmonization Task Force
9](#large-scale-model-harmonization-task-force)

[4.1 Participants: 9](#participants)

[4.2 Contributors: 9](#contributors)

[4.3 Task Force Process 9](#task-force-process)

[4.4 Task Force Findings 10](#task-force-findings)

[4.5 Task Force Recommendations 14](#task-force-recommendations)

[4.5.1 Model Recommendations 14](#model-recommendations)

[4.5.2 Process Recommendations 14](#process-recommendations)

[5 Review of Existing Models 16](#review-of-existing-models)

[5.1 Identified Shared Objects 16](#identified-shared-objects)

[6 caBIG Semantic Tool Utilization 18](#cabig-semantic-tool-utilization)

[6.1 Enterprise Architect 18](#enterprise-architect)

[6.2 Semantic Integration Workbench 19](#semantic-integration-workbench)

[6.3 cancer Data Standards Repository
19](#cancer-data-standards-repository)

[6.4 CDE Browser 20](#cde-browser)

[6.5 UML Model Browser 20](#uml-model-browser)

[6.6 Enterprise Vocabulary Services (EVS)
21](#enterprise-vocabulary-services-evs)

[6.7 LexBIG/LexGrid 21](#lexbiglexgrid)

[6.8 Global Model Exchange 22](#global-model-exchange)

[6.9 Ontology Web Language (OWL) 23](#ontology-web-language-owl)

[7 Development of a Backbone Model 24](#development-of-a-backbone-model)

[7.1 Initial Approach 24](#initial-approach)

[7.2 BRIDG Harmonization Process 25](#bridg-harmonization-process)

[7.2.1 What is Harmonization? 25](#what-is-harmonization)

[7.2.2 Pre-harmonization Process 25](#pre-harmonization-process)

[7.2.3 General Modeling Recommendations
26](#general-modeling-recommendations)

[7.2.4 Post-harmonization Process 27](#post-harmonization-process)

[7.2.5 Versioning/Change Control 27](#versioningchange-control)

[8 Next Steps 29](#next-steps)

[8.1 Recommendation: Creation of a New Task Force to Define in Detail
Processes Required for the Model Harmonization Effort
30](#recommendation-creation-of-a-new-task-force-to-define-in-detail-processes-required-for-the-model-harmonization-effort)

[8.2 Recommendation: Create a Standing Model Harmonization Entity within
caBIG
31](#recommendation-create-a-standing-model-harmonization-entity-within-cabig)

[8.3 Recommendation: The Development of New Tooling to Support the Model
Harmonization Activities
31](#recommendation-the-development-of-new-tooling-to-support-the-model-harmonization-activities)

[8.4 Recommendation: Active Engagement of the Community Regarding the
Conclusions of this White Paper
32](#recommendation-active-engagement-of-the-community-regarding-the-conclusions-of-this-white-paper)

[8.5 Resource Balancing 32](#resource-balancing)

[9 Appendices 33](#appendices)

[9.1 Appendix 1: Model Inventory 34](#appendix-1-model-inventory)

[9.2 Appendix 2: Draft Backbone Model
39](#appendix-2-draft-backbone-model)

[9.3 Appendix 3: Glossary 40](#appendix-3-glossary)

[9.4 Appendix 4: Tool Requirements 42](#appendix-4-tool-requirements)

# Preface

This document is the fulfillment of the white paper on Crosscutting
Model Harmonization commissioned by Booz Allen Hamilton on behalf of the
NCI caBIG project to Mayo Clinic. It expands upon the task force
report[^2] produced in the summer of 2006; a preliminary of the present
white paper was circulated in October 2006.

# Background

One of caBIG's principals is to use Model Driven Architecture (MDA) in
achieving semantic interoperability. In the first few years of the caBIG
pilot program, software development projects and the cross-cutting
workspaces (VCDE and Architecture) were principally concerned with
attaining silver level compatibility. Silver level compatibility seeks
to achieve a moderate level of compatibility and interoperability.
Recently, development projects have begun to address higher levels of
compatibility and interoperability. At the Gold level of compatibility,
the guidelines include the general but straightforward statement:

> *"Gold requirements for Information Models will likely involve an
> added degree of harmonization across caBIG domains."*

The absence of an overarching framework for integrating caBIG
applications was noted by the caBIG Strategic Work Space and others.
Specifically, the issue of model harmonization was raised at the April
2006 meeting of the Strategic Planning Workspace. At that meeting a task
force was formed within the Vocabulary and Common Data Elements (VCDE)
Workspace to address model harmonization across all caBIG workspaces.

Most people would agree that any harmonization of information models
must include the idea of a larger "caBIG Domain Model". This would be
used to inform new application development (pre-harmonization efforts)
and to evaluate existing applications (post-harmonization efforts). A
framework for sharing objects, model components, and information
structures will facilitate data and programmatic interoperability,
simplify subsequent application design, and provide a big-picture view
of the caBIG information space.

However, there has been little, if any, agreement on what form and what
processes would surround such a "caBIG Domain Model". All proponents
agreed that such an overarching information model (proposed as the
Backbone Model) must be informed by components emerging from
workspace-specific application models, domain models, and objects, e.g.
caBIO, caTissue, and BRIDG (Biomedical Research Integrated Domain Group
[^3]).

The ultimate purpose of a Backbone Model is to facilitate semantic
interoperability between caBIG applications. This is accomplished by the
alignment of attributes and characteristics of information objects
across all caBIG workspaces, which ultimately leads to the reuse of
information objects and CDEs. This effort must align with the
harmonization of individual data elements in the caDSR and with
harmonization efforts within each workspace, e.g., the BRIDG effort
within the CTMS Workspace.

An alternate purpose of the Backbone Model is to provide a means for
semantic interoperability with other non-caBIG groups, such as NCRI,
CDISC and HL7. Harmonization of the BRIDG model with the Backbone Model
will provide semantic interoperability with the CDISC and HL7 standards.
The NCRI Platform project[^4] considers a Backbone Model the cornerstone
for interoperability between caBIG and the NCRI Platform and the linked
projects. Moreover, the Backbone Model is a candidate for the domain
model within the NCRI Platform's reference architecture.

The idea of having an overarching domain model used as reference for all
the sub-domains (or workspaces, in caBIG terminology) related to cancer
research is already established in the NCRI Platform project. Within the
NCRI's initiatives, the Platform Reference Model (PRM) project has been
working on a proof-of-concept reference model for the NCRI Platform.
This model will be used as a reference for describing the semantics of
data and services offered by initiatives linked to the NCRI Platform.
Similar to the backbone model, the PRM is intended as a guide to
identify the proper CDEs for fine-grained semantic description of
application services. As the NCRI platform is committed to achieving
full semantic compatibility with the caBIG network, full compliance
between the models (or even using a common reference model) is
considered a key requirement for the Platform development.

## Use Cases

### Information Model for a New Application

> \[Use case provided by Patrick McConnell\]

The Backbone Model can be used by new application development teams in
two ways. First, the Backbone Model can be used to "seed" a new model
(pre-harmonization). This will save the development team from redefining
the requirements for those objects. Second, the Backbone Model can be
used by development teams that are creating applications that span other
applications. The Backbone Model will document how the other
applications are integrated, i.e., it defines the common objects and how
they are related. Even if the applications have not yet been integrated,
the Backbone Model will identify how this integration should occur. This
will save the development team from having to redefine these
requirements. This will also allow the development team to develop fewer
integration points, that is application-to-common-hub (n) integration
points rather than application-to-application (n\*(n-1)/2) integration
points.

The following two cases are real caBIG projects that could have
benefited from a Backbone Model, had one existed. Instead the project
teams had to develop their own version of the Backbone Model.

-   The caTissue Suite (new TBPT application) needed to integrate the
    concepts of Participant, Accession and Biospecimen across caTissue
    Core, caTissue CAE and caTIES. \[Use case provided by Rakesh
    Nagarajan, M.D., Ph.D.\]

-   The caTRIP Backbone needed to integrate the concepts of MRN (Medical
    Record Number), Participant, Accession and Specimen across caTissue
    CAE, caTissue CORE, Tumor Registry and caIntegrator SNP. An example
    of the caTRIP integration is illustrated in the following table:

  ---------------- -------------------------------- ------------------ ------------------------- --------------
  **Model**        **MRN**                          **Participant**    **Accession**             **Specimen**

  **caTissue       ParticipantMedicalIdentifier.\   Participant        SpecimenCollectionGroup   Specimen
  CORE**           medicalRecordNumber                                                           

  **CAE**          ParticipantMedicalIdentifier.\   Participant        Accession                 Specimen
                   medicalRecordNumber                                                           

  **Tumor          PatientIdentifier.\              Patient                                      
  Registry**       medicalRecordNumber                                                           

  **caIntegrator   StudyParticipant.\               StudyParticipant                             Specimen
  SNP**            studySubjectIdentifier                                                        
  ---------------- -------------------------------- ------------------ ------------------------- --------------

![](media/image1.jpeg){width="7.322222222222222in" height="5.3125in"}

### Maintain An Existing Model

As applications such as caTissue Core, caTissue CAE and caTIES are
enhanced, they should be harmonized with the Backbone Model. This will
facilitate future integration efforts (such as those mentioned above) as
they work to integrate data from across multiple applications. The above
Figure is an example of a small domain backbone model that may require
versioning and harmonization as the pathology workspace projects evolve
their own data models. However, as these project in turn evolve, the
degree they begin to consider a backbone model, such as the one above,
as a consensus effort will influence their latitude for unilateral
modifications.

### UK NCRI Defining Example

> \[Use case provided by Vito Perrone\]

In the NCRI Platform Reference Model a number of use cases have been
analyzed to define the reference model. This use case is one of these
and in particular it was taken from one of the caBIG general meetings
(2004) and slightly adapted to reflect the platform needs.

*A scientist wishes to investigate genetic variation in tumor response
to treatment with a specific class of chemotherapy. She would like to
identify specimens of a specific tumor type, flash-frozen and prepared
using a specific methodology, and for which there are associated medical
records for treatment outcome. With sections of those specimens, the
researcher would like to carry out microarray experiments for tumor
cells and normal cells on the periphery of the tumor. She needs to store
and analyze the data using conventional clustering methodologies. She
would also like to compare the clusters to currently-known metabolic
pathways, some of which are known to be chemotherapy targets. With the
list of genes from the pathways of interest showing expression variation
related to the chemotherapy treatment, the investigator can then
identify common genetics variations in the public databases for
subsequent follow-up. At the time of publication of her study she wants
to maximize the impact of her achievements on the scientific community
for follow-up studies by depositing the microarray data in public
repositories.*

Having harmonized information objects will allow these disparate
applications to integrate the data and present the scientist with a
unified and seamless experience with the applications. Rather than
requiring the scientist to manually translate or transcribe data from
one system to another.

# Large Scale Model Harmonization Task Force

The present report is an expansion of the preliminary Large Scale Model
Harmonization report (see URL footnote on page [2](#TaskRptRef)), which
was produced by a volunteer task force that grew out of an initiative by
the Strategic Planning Workspace.

## Participants:

-   Christopher G. Chute, Mayo Clinic (Chair)

-   James Buntrock, Mayo Clinic

-   Brian Davis, 3^rd^ Millennium, Inc.

-   Lewis Frey, University of Utah

-   Mike Keller, Booz Allen Hamilton

-   George Komatsoulis, NCI Center for Bioinformatics

-   Paul Mandel, Booz Allen Hamilton

-   Frank Manion, Fox Chase Cancer Center

-   Patrick McConnell, Duke University

-   Rakesh Nagarajan, Washington University

-   Vito Perrone, University College London (in cooperation with
    National Cancer Research Institute)

-   Steve Sandberg, Mayo Clinic (Coordinator)

## Contributors:

-   Robert Freimuth, Mayo Clinic

-   Doug Fridsma, University of Pittsburgh

-   Meg Gronvall, Booz Allen Hamilton

-   Charlie Mead, Booz Allen Hamilton

The segments in the present report that were edited and adopted from the
task force report include:

-   Background

-   Process and Products

-   Findings

-   Recommendations

-   Next Steps

## Task Force Process 

Members of the task force agreed to use the approach for building the
Backbone Model suggested in George Komatsoulis' original
presentation[^5], which was a hybrid approach that combined aspects of a
bottom-up and a top-down approach. The bottom-up approach was followed
when information from various caBIG application models (e.g., caTissue,
caBIO, etc.) was used to develop the Backbone Model. The top-down
approach was used when task force members employed their own knowledge
of the domain to extend and consolidate the model. The task force
discussed the possibility of using existing tools (e.g., Semantic
Integration Workbench) and content to facilitate the development of the
Backbone Model. However, it was determined that sufficient content was
not yet available in these tools for that purpose.

The members of the task force also agreed the Backbone Model developed
by the present effort would be a proof-of-concept model only and not a
complete domain model. As a starting point the group focused on the
concept of Biospecimen, as illustrated in George Komatsoulis' example
model. Since all of the information models that were surveyed during
this effort were developed using Enterprise Architect, the task force
choose to use this tool for modeling the Backbone Model.

In addition to the domain knowledge from the various application
information models, the task force also gathered input from other
sources, such as members of the BRIDG project team and other invited
guests. The task force also presented a preliminary Backbone Model at
the Joint Architecture and VCDE Face-to-Face meeting in July 2006 to
solicit feedback, much of which was incorporated into the model.
Feedback that could not be resolved was documented as issues or as next
steps.

Refer to the Task Force report for the initial Backbone Model, which has
been modified slightly in this White Paper.

## Task Force Findings

The findings of the task force are detailed below. These findings formed
the basis of the Recommendations discussed subsequently.

1)  Consensus on Value\
    Members of the task force universally agreed upon the value of a
    common, overarching model. However, this was tempered by a firm
    belief that such a model should not be obtuse, overly abstract, or
    non-intuitive. Members explicitly asserted that any domain expert
    should see value in the model at first glance.

2)  Magnitude of Effort\
    Significant participation by domain experts and harmonizers will be
    necessary to appropriately accommodate the spectrum of caBIG
    activities. While this will impose a measurable burden, the benefit
    and advantages accruing from this investment were judged to be worth
    the effort.

3)  Issues and Resolutions

    a.  [Level of Abstraction]{.underline} -- The degree to which
        objects and elements are generalized into high-level and
        potentially unrecognizable things. The HL7 Reference Information
        Model is often cited as an example of a highly-abstract model.

> There was an overwhelming preference that an overarching model must be
> concretely interpretable by professionals familiar with the domain.
> While the Backbone Model should not be specific to any single
> implementation, it is intended to be of use to application development
> teams. Therefore, the Backbone Model (as shown in Appendix 2) is one
> level of abstraction above an implementation model and explicitly
> illustrates portions of the information models from which it derives.

b.  [Model Ownership]{.underline} -- A designated, supported, and
    representative group of domain experts must own the model and the
    harmonization process.

> The roles and responsibilities of the various groups involved in
> harmonization must be identified, defined, instantiated and supported.
> These groups include, but are not limited too, the following: a
> harmonization group, domain experts, application developers, and caBIG
> oversight. A standing body of caBIG participants should be given clear
> responsibility for owning the model and the processes for maintenance
> and harmonization, and be available for advice on the use of the
> model.

c.  [Scope of Identifiers (Global vs. Local)]{.underline} -- On caGrid,
    instances of objects have a unique identity (identifier). That
    identifier is a forever globally unique name for the data-object
    such that it can be unambiguously used to refer to the object from
    different application contexts. For example, objects such as
    Biospecimen or Participant should be defined (identified) once and
    reused across application, system, and cancer center boundaries.\
    \
    Principles must be developed to establish which objects should be
    instantiated as global and which are more appropriate to be defined
    locally within an application. Other groups within caBIG are
    addressing this issue (e.g., the LexGrid project is discussing how
    this relates to vocabulary services). The functionality provided by
    caGrid's Identifier Services Framework supports having "identifiers"
    for individual data-objects.  How this overlaps or integrates with
    the notion of domain identifiers (such as patient id) needs to be
    investigated.

d.  [Static vs. Dynamic]{.underline} -- Dynamic models accommodate state
    transition of objects over time or through a workflow; static models
    do not.

> A major lesson from the BRIDG group is that confusion about object
> definitions and attributes was often reconciled by adopting a dynamic
> view of those objects. Our task force was strongly encouraged to add a
> dynamic perspective (e.g., state transition diagrams) to the Backbone
> Model. These suggestions were incorporated in the section detailing
> next steps. However, the task force decided that drafting a static
> model of caBIG had substantial value and represented an achievable
> starting point. Participants noted that existing workspace application
> models are uniformly static, though the BRIDG domain analysis model
> has dynamic diagrams.

e.  [Semantic Interoperability]{.underline} -- The mechanisms by which
    caBIG application models share common object definitions.\
    \
    The Backbone Model will provide common definitions of objects.
    Individual application models may share these definitions by a
    number of mechanisms. Subclassing should be used if the application
    wishes to inherit all attributes and characteristics of the common
    object. Associations can be used if the application wishes to define
    its own unique object but still link to the common object. Finally,
    an application may choose to reuse individual attributes from a
    common object without reusing the entire object. The issue of
    metadata reuse is being analyzed by a small group under the auspices
    of the VCDE workspace
    (<http://gforge.nci.nih.gov/projects/metadata-re-use>).

f.  [Data Types]{.underline} -- Information models define or adopt
    formats and element structures to be re-used throughout the model.

> The VCDE workspace systematically examined HL7 and Java data types.
> The designation of caBIG data types is an ongoing process that must
> harmonize with any effort to develop an overarching model. The caDSR
> Datatype small group
> (<http://gforge.nci.nih.gov/projects/cadsr-datatypes>) is currently
> working on this effort.

g.  [Naming Conventions]{.underline} -- Rules and conventions for
    creating object names in an overarching model must be consistent.

> The naming issue is complex in a design where existing application
> models, in a bottom-up process, inform an overarching starting point.
> Conflicting names between similar objects from contributing models is
> immediately obvious. Furthermore, rules of inheritance,
> specialization, or refinement often invoke compositional naming rules
> which adhere to an inheritance path. Additionally, naming issues are
> tightly coupled with global vs. local object identity (see
> Globalization issues above). The naming conventions for classes in the
> Backbone Model should conform to the caCORE SDK Programmers Guide[^6].

h.  [Tooling Issues]{.underline} -- A number of tools can and should be
    used to facilitate the harmonization process, which includes
    submission, review, feedback, and updating of application models.

> The task force accomplished much of its work manually, using few tools
> other than Enterprise Architect as a modeling tool. To ensure the
> ongoing process of harmonization is effective and efficient, the use
> of automated tools will be required. This could include the
> development of new tools as well as the incorporation of existing
> tools, such as the Semantic Integration Workbench. Members of the task
> force specifically mentioned that a tool is needed to globally look
> across application models to identify reusable objects, i.e., a UML
> repository. The ICR Workspace Strategic Plan also mentions the need
> for such a tool.\
> \
> The selection of tools will depend upon the determination of
> harmonization standards, such as the version of UML standard used (is
> it more critical to have automated JAVA code generation (using version
> 2.0) or to have human readable patterns (using version 1.5)).
>
> See caBIG Semantic Tool Utilization section below.

i.  [Resources for Alignment]{.underline} -- Identifying the human and
    organizational resources to carry out the overarching harmonization
    work.

> The scope of this task force was to define the problem and suggest a
> direction for progress. It cannot complete, nor make substantial
> progress toward, the creation of a draft model, never mind engage the
> more difficult work of on-going harmonization and model evolution. A
> well-defined and supported follow-on group must be established if the
> goals and objectives surrounding a high-level model are to be
> achieved.
>
> See the Next Steps section, below.

j.  [Scalability]{.underline} -- The degree to which model and process
    can be expanded to the entire caBIG domain.\
    \
    The scope of the task force was just a proof-of-concept and focused
    primarily on the Biospecimen class. It is the task force's
    recommendation to review the processes used by the BRIDG project and
    f it where appropriate. It is important to determine whether the
    process used by the BRIDG project will prove to be scalable.

## Task Force Recommendations

The ultimate purpose of the Backbone Model is to maximize semantic
interoperability between caBIG applications. This is accomplished by the
alignment of attributes and characteristics of information objects
across all caBIG workspaces, ultimately leading to the reuse of
information objects and CDEs. This effort must align with the
harmonization of individual data elements in the caDSR, and with
harmonization efforts within each workspace, e.g., the BRIDG effort
within the CTMS Workspace.

The harmonization effort will include two components. The first is the
development of an overarching model for all caBIG workspaces. The second
is the definition of the process for harmonizing individual application
models.

### Model Recommendations

The Backbone Model should be an implementation-independent, but not
highly abstract model. The model should be detailed enough to be readily
useful for application developers and easily mapped to application
models. It is expected the model will not be a complete model of the
caBIG domain but rather a conglomeration of existing application models.
The primary focus should be on boundary objects that operate across
applications (e.g., Biospecimen). Boundary (or Common) objects are those
objects that are, or could be, shared across application models.
Therefore, the model will be an "underspecified" model. The Backbone
Model will link to application models to identify specific
implementation objects. (It should be noted that a tool does not yet
exist to support this functionality.) As the model is incrementally and
iteratively evolved to include more applications (using a bottom-up
approach) it will eventually be used to identify missing components (a
top-down approach).

### Process Recommendations

The process for harmonization must include a framework to harmonize
existing application models, to gracefully evolve those models toward
the common model, and must detail the process for how the information
models for new applications (or new versions of existing applications)
will be guided by this model. It is the task force's recommendation to
review the processes used by the BRIDG project and adopt it where
appropriate.

> Whatever the final process, it is the task force's concerted
> recommendation that applications must be reviewed prior to the
> development of the application models. Reviewing application models
> after they are implemented will refine the Backbone Model (bottom-up),
> but to provide the greatest benefit to the developers the Backbone
> Model should be reviewed as early in the design process as possible
> (top-down).

# Review of Existing Models

To develop the proof-of-concept model the task force used models with
which they were familiar, e.g., caBIO and caTissue. Eventually, the
Backbone Model will be expanded to include models from all workspaces.
To that end, an inventory of caBIG models will be necessary.

The inventory of models within the caBIG domain is constantly changing
as new projects are initiated and existing applications are revised. The
attached inventory (Appendix 1) was developed over several weeks, and
the status of the models in caDSR was determined on October 7, 2006. As
of that date, there were 15 models loaded in the production caDSR (the
two versions of caTIES are counted as two models) and 39 models uploaded
to the Project Registry for registry within the caDSR. In addition,
there were 46 other projects in various caBIG workspaces, and at that
time, we were unable to determine if those projects would generate UML
models.

> Refer to Appendix 1 for complete inventory of models within the caBIG
> domains.
>
> Sources:
>
> caDSR = <http://umlmodelbrowser.nci.nih.gov/umlmodelbrowser/>
>
> Project Registry =
> <http://gforge.nci.nih.gov/projects/registrymodels/>
>
> Various workspace GForge sites =
> <http://gforge.nci.nih.gov/softwaremap/trove_list.php?form_cat=336>

## Identified Shared Objects

Seven information objects were identified as the Backbone Model was
developed: Biospecimen, Participant, Organism, Accession, Gene, Protein,
and mRNA. These objects were identified as common across the various
models used by the task force to develop the Backbone Model (see
Appendix 2). As other models are harmonized with the Backbone Model this
list of shared information objects will increase.

In addition to the shared objects described above, the members of the
task force agreed to include information objects that may not yet be
shared across information models, but have the potential to be shared. A
partial list of potential shared objects includes: Institution, User,
and Protocol. However, since not all caBIG models have been harmonized
these objects already may be tacitly shared across models.

The definitions of the shared object classes were developed from
concepts in the NCI Thesaurus
(<http://nciterms.nci.nih.gov/NCIBrowser>).

-   [Biospecimen]{.underline}: Natural substances derived from living
    organisms such as cells, tissues, proteins, and DNA.

-   [Participant]{.underline}: Someone who takes part in an activity.

-   [Organism]{.underline}: A living thing, such as an animal, a plant,
    a bacterium, or a fungus.

-   [Accession]{.underline}: A process of increasing by addition (as to
    a collection or group).

-   [Gene]{.underline}: A functional unit of heredity which occupies a
    specific position (locus) on a particular chromosome, is capable of
    reproducing itself exactly at each cell division, and directs the
    formation of a protein or other product. The gene as a functional
    unit consists of a discrete segment of a giant DNA molecule
    containing the purine (adenine and guanine) and pyrimidine (cytosine
    and thymine) bases in the ordered and correct sequence that encodes
    a specific functional product (i.e., a protein or RNA molecule).

-   [Protein]{.underline}: A group of complex organic macromolecules
    composed of one or more chains (linear polymers) of alpha-L-amino
    acids linked by peptide bonds and ranging in size from a few
    thousand to over 1 million Daltons. Proteins are fundamental
    genetically encoded components of living cells with specific
    structures and functions dictated by amino acid sequence.

-   [mRNA]{.underline}: Messenger RNA. A class of RNA molecules that
    contain protein-coding information in their nucleotide sequence and
    can be translated into the amino acid sequence of a protein.
    Bacterial mRNAs are generally primary transcripts in that they do
    not require post-transcriptional processing. Eukaryotic mRNA is
    synthesized in the nucleus and must be exported to the cytoplasm for
    translation. Most eukaryotic mRNAs have a sequence of polyadenylic
    acid at the 3\' end, referred to as the poly(A) tail. The function
    of this tail is not known for certain, but it may play a role in the
    export of mature mRNA from the nucleus as well as in helping
    stabilize some mRNA molecules by retarding their degradation in the
    cytoplasm.

-   [Institution]{.underline}: An established society, corporation,
    foundation or other organization founded and united for a specific
    purpose, e.g. for health-related research; also used to refer to a
    building or buildings occupied or used by such organization.

-   [User]{.underline}: An individual who uses a computer, program,
    network, or related service for work or entertainment.

-   [Protocol]{.underline}: A rule which guides how an activity should
    be performed.

# caBIG Semantic Tool Utilization

There are many software tools in use throughout caBIG: Enterprise
Architect, SIW, caDSR, CDE Browser, UML Browser, EVS, LexBIG, and GME. A
brief description of each tool and how they might be used within the
harmonization process is presented here.

## Enterprise Architect

[http://www.sparxsystems.com](http://www.sparxsystems.com/)

Enterprise Architect (EA) is a popular Computer-Aided Software
Engineering tool suite. EA facilitates the system development, project
management, and business analysis process. EA is an object-oriented tool
supporting full life-cycle development and the accompanying artifacts:
Use Case Diagrams, Class Diagrams, Sequence Diagrams, Collaboration
Diagrams, Activity Diagrams, Component Diagrams, and Deployment
Diagrams. Enterprise Architect is a flexible, complete, and powerful UML
modeling tool.

Unified Modeling Language™ (UML) is an industry-standard language for
specifying, visualizing, constructing, and documenting the artifacts of
software systems standardized by the Object Management Group (see
[www.omg.org/uml](http://www.omg.org/uml)). UML simplifies the complex
process of software design by using "blueprints" for software
construction.

> Benefits of UML:

-   Software systems are professionally designed and documented before
    they are coded so that all stakeholders know exactly what they are
    getting, in advance.

-   Since system design comes first, UML enables re-usable code to be
    easily identified and coded with the highest efficiency, thus
    reducing software development costs.

-   UML enables logic \'holes\' to be spotted in design drawings so that
    software will behave as expected.

-   The overall system design described in UML will dictate the way the
    software is developed so that the right decisions are made early in
    the process. Again, this reduces software development costs by
    eliminating re-work in all areas of the life cycle.

-   UML provides an enterprise level view of the system and as a result,
    more memory and processor efficient systems can be designed.

-   UML enables ease of maintenance by providing more effective visual
    representations of the system. Consequently, maintenance costs are
    reduced.

-   UML diagrams assist in providing efficient training to new members
    of the development team.

-   UML provides a vehicle of communication with both internal and
    external stakeholders as it efficiently documents the system.

Most projects within caBIG will produce UML models; indeed silver level
compatibility requires UML models for data and analytic services that
are meant to be shared on caGrid. Enterprise Architect is the preferred
tool for developing those models, primarily because of the ease in
sharing the models (Enterprise Architect has a free read-only version
called EALite;
[http://www.sparxsystems.com](http://www.sparxsystems.com/)).

One issue that arose during analysis was the dichotomy in versions of
UML, in particular, between version 1.5 and version 2.0. Modeling of the
static components did not change, but modeling of the dynamic components
changed dramatically. To date very few caBIG projects have had the need
to model the dynamic components. However, as the applications become
more sophisticated and the need increases for greater interoperability,
it is anticipated that projects will require more dynamic modeling
techniques. The question then arises, what form should those models
take? The dynamic modeling in UML version 1.5 is very informal and
easily understood by domain experts. In version 2.0 of UML the
constraints around dynamic modeling have been greatly formalized to
allow easier code generation. This latest version of UML is not as
easily interpreted by domain experts. The question will need to be
resolved by determining which is the greater importance: validation of
the dynamic component by domain experts or automatic generation of
application code. The first would suggest using UML version 1.5, while
the second would encourage using UML version 2.0.

## Semantic Integration Workbench

[http://cadsrsiw.nci.nih.gov](http://cadsrsiw.nci.nih.gov/)

In order to achieve caBIG Silver and Gold level compatibility the domain
model must be tagged with semantic concept codes from the NCI Thesaurus.
The Semantic Integration Workbench (SIW) was created to aid the
developer by providing user interfaces to perform this task. The results
of semantic tagging are stored in the caDSR. For details about this
process see the "Semantic Integration SOP" by Denise Warzel
(<http://gforge.nci.nih.gov/frs/download.php/457/Semantic_Integration_SOP-.3.zip>).

## cancer Data Standards Repository

<http://ncicb.nci.nih.gov/NCICB/infrastructure/cacore_overview/cadsr>

Once the domain model has been annotated it can be loaded into the
cancer Data Standards Repository (caDSR). The caDSR is an ISO 11179
compatible metadata registry
(<http://ncicb.nci.nih.gov/NCICB/infrastructure/cacore_overview/cadsr/ISO11179>).

Currently, the metadata for a project is loaded into the caDSR only
towards the end of the project, which ensures that the metadata in the
caDSR is relatively complete and stable. However, this has the effect of
making available only a small percentage of caBIG metadata, as many of
the caBIG projects are still in the process of being developed. As caBIG
matures, this will become less of an issue. At the present time the
greatest benefit in sharing information objects is between projects
still under development. The caDSR does not facilitate this type of
sharing.

Within the caDSR information objects are linked, or tagged, with
semantic concept codes that allow users to identify similar information
objects. However, this does not provide the precision necessary to
identify if an object should be reused. Two information objects may
relate to the same semantic concepts, but this does not mean they are
interchangeable. A more precise matching is necessary to indicate if
(and how) two information objects are interoperable.

## CDE Browser

> <http://cdebrowser.nci.nih.gov/CDEBrowser/>

CDE browser is a front end for the caDSR and is a starting point for
exploring the contents of the caDSR. The tool supports browsing,
searching, and exporting CDEs within or across contexts. The Shopping
Cart feature lets you create a customized set of CDEs for exporting and
the Form Builder feature lets you organize them as \"forms\". There is
also a [DTD](http://ncicb.nci.nih.gov/xml/dtds/cadsr) used by the CDE
Browser to export/download data elements in XML format.

This tool is currently used to aid the compatibility review process to
look for CDEs that could have been reused, either caBIG-approved
standard CDEs or CDEs from other information models. A similar function
can be performed using the UML Model Browser, as described in the next
section.

## UML Model Browser

> <http://umlmodelbrowser.nci.nih.gov/umlmodelbrowser/>

This tool allows users to browse administered items that are part of
registered UML Models. The tool supports browsing and searching the
classes, attributes and relationships between classes of a UML domain
model.

The UML Model Browser is up and running but not fully functional (e.g.,
currently there is no ability to export data). More work is needed to
equal the functionality in the CDE Browser and, as stated above, the
current instantiation of the caDSR only allows the identification of
semantically similar information objects, i.e. those mapped to the same
concept code(s). It does not directly indicate which objects could be
reused, nor how they could be reused (e.g., direct reuse of full or
partial CDEs, reuse by inheritance, or reuse through associations).

## Enterprise Vocabulary Services (EVS)

<http://ncicb.nci.nih.gov/NCICB/infrastructure/cacore_overview/vocabulary>

The NCI EVS is a set of services and resources that address NCI\'s needs
for controlled vocabulary. The EVS Project is a collaborative effort of
the Center for Bioinformatics and the NCI Office of Communications. The
NCI Thesaurus (http://nciterms.nci.nih.gov/NCIBrowser/Dictionary.do) is
a biomedical thesaurus produced by the NCI EVS project and created
specifically to meet the needs of the NCI. The NCI Thesaurus is provided
under an open content license.  The EVS Project also produces the NCI
Metathesaurus (http://ncimeta.nci.nih.gov/), which is based on NLM\'s
Unified Medical Language System Metathesaurus supplemented with
additional cancer-centric vocabulary. In addition, the EVS Project
provides NCI with licenses for MedDRA, SNOMED, ICD-O-3, and other
proprietary vocabularies.

This tool provides the semantic concepts for the caDSR and SIW (see
above). The current implementation does not provide the rigor necessary
to support the harmonization process; however, if semantic concepts were
more rigorously defined (see discussion of ontology below), the EVS
could be used in the harmonization process.

## LexBIG/LexGrid

> <http://informatics.mayo.edu/LexGrid/index.php?page=lexbig>
>
> LexBIG is the caBIG adoption and implementation of LexGrid.
>
> The purpose of the Lexical Grid is to provide a framework that:

-   Is flexible enough to represent yesterday's, today's and tomorrow's
    terminological resources using a single information model

-   Allows these resources to be published online, cross-linked, and
    indexed

-   Standardized building blocks and tools that allow applications and
    users to take advantage of the content where and when it is needed

-   Essentially, provides consistency and standardization required to
    support large-scale terminology adoption and use

-   Information model that names and defines the classes to support a
    variety of terminologies

-   Master representation is currently maintained in XML Schema, with
    (semi) automatic transformations to ...

    -   Unified Modeling Language (UML)

    -   XML Model Interchange (XMI)

    -   Eclipse Modeling Framework (EMF)

    -   Java classes/OO implementation

    -   Relational database schema

    -   LDAP schema

Essentially, LexBIG presently provides a set of data services to import,
export or browse a variety of vocabularies, including EVS (see above).
As such it now has the same uses and limitations as EVS. However, the
capacity to expand considerably beyond this functionality is implicit
since LexBIG is based upon LexGrid. LexGrid has substantiable additional
functionally as implemented within the CDC (LexPHIN), the National
Center for Biomedical Ontology under NIH Roadmap grant funding, and the
core vocabulary management and services (including CTS -- Common
Terminology Services) within the HL7 development environment and
internal HL7 table management. All of these are discoverable on the
LexGrid URL above.

## Global Model Exchange

<http://projectmobius.osu.edu/docs/gmeqs.php>

The Global Model Exchange (GME) is like a data definition registry and
exchange service that is responsible for storing and linking together
data models in the form of XML schema. As the caDSR facilitates semantic
interoperability, the GME facilitates programmatic data exchange
(syntactic) interoperability.

In order for services on caGrid to communicate with each other, their
data must be described in a format that is understood by all necessary
components involved. Thus a data management system for caGrid must
provide a method for defining metadata and data via a universal
consistent modeling pattern, distinct instances of which we call data
models. The \"data model\" is the specification of the structure,
format, syntax, and occurrences of the data instances it represents.

The data models must be globally available to every authorized and/or
authenticated service to enable the system to work. To get around the
problem that data models from different areas and institutions, though
they may define a similar entity (a Patient entity, for example), will
not necessarily be equivalent, entities within models are assigned to a
namespace that effectively makes a Patient entity from one institution
distinct from a Patient entity at another one. Another issue is
persistence and availability of models. Data and the data models
registered with the GME ought to persist and be attainable from any node
within the GME.

To these ends, the GME is responsible for storing and linking data
models as defined within namespaces in a distributed environment. It
enables other services to publish, retrieve, discover, and version
metadata definitions (data models). GME services are composed in a
DNS-like architecture, in which parent-child namespaces organize the
connection of nodes into a hierarchical tree structure. To provide
versioning and the potential for exchange between model versions, the
GME provides model version and model to model dependency management.
Modified and republished models will be versioned automatically,
allowing for multiple model versions to be used concurrently.
Furthermore, if a suitable mapping between models can be established,
the models can be interchanged seamlessly.

## Ontology Web Language (OWL)

[http://ontoware.org](http://ontoware.org/)

OWL-ODM provides software tools based on the OWL Object Definition
Metamodel (ODM) to allow interoperability of OWL ontologies with
MOF-compatible software environments. This includes the ODM itself, a
UML profile for visual modeling of ontologies and a converter from EMF
models to OWL.

> See also:

-   SWOOP: <http://www.mindswap.org/2004/SWOOP>

-   Protégé: [http://protege.stanford.edu](http://protege.stanford.edu/)

-   RDF: <http://www.w3.org/RDF>

# Development of a Backbone Model

## Initial Approach

As stated previously, the development of a Backbone Model is critical
for the harmonization process. The draft Backbone Model presented in
Appendix 2 was developed as a "proof of concept". Most of the work that
went into developing that model was a manual effort. What is presented
here is an idealized process for developing the Backbone Model assuming
appropriate personnel and tooling resources are available.

1.  Ensure that all appropriate and available application models are
    loaded into a metadata repository (e.g., caDSR).

2.  Extract semantically similar objects from the metadata repository.
    This can be accomplished in the caDSR by using objects mapped to the
    same concepts. The ontology of the concepts can be used to identify
    semantically similar objects. Criteria will need to be specified to
    identify an appropriate level of matching between objects. This
    could include concept matching on classes, attributes or value
    domains.

3.  Group semantically similar objects into clusters and define
    relationships between those objects. The structure of the cluster is
    anticipated to be hierarchical, with inheritance relationships
    between objects. New objects may need to be created to form
    intermediate levels in the hierarchy.

4.  Define inter-cluster relationships. This could be accomplished by
    leveraging the source UML object relationships.

5.  Select generic or archetypical objects from the hierarchical
    structures. The archetype objects are candidates for object classes
    in the Backbone Model. Selection of objects should be done at the
    appropriate level of abstraction. That is, they should not be
    implementation--specific, nor should they be too abstract. A general
    guideline for the appropriate level of abstraction are objects that
    are not specific enough for inclusion within an information model
    but would be useful to developers after additional domain-specific
    qualifiers are added. The Backbone Model should not contain value
    sets, as they would indicate a specific level of implementation
    within a particular domain. The domain (DMIM -- Domain Model
    Information Model) level within HL7 modeling is an example of the
    appropriate level of abstraction.

## BRIDG Harmonization Process

These segments are adopted from BRIDG documents, provided by Doug
Fridsma, Charlie Mead, Smita Hastak, and Julie Evans. The BRIDG
reference sources are provided as URLs at the end of this section.

### What is Harmonization?

Harmonization is the process of making identical or minimizing the
differences between objects and attributes within a specified domain. In
this context harmonization refers to objects within two or more
information models.

There are two aspects of the harmonization of information models. The
first is the technical aspects of harmonization. This will depend upon
the toolset in use and will not be covered in this document. The second
aspect is the semantics of harmonization. This aspect is the primary
focus of this section.

Harmonization can occur at various points in the life cycle of a
project. The task force recommended two points at which harmonization
should occur. The first was designated pre-harmonization and should
occur as early in the project as possible. The second was designated
post-harmonization and occurs after the development of the application
has completed.

Although the task force realizes many project are already underway, the
pre-harmonization effort is viewed as the most beneficial to
interoperability of caBIG applications, as illustrated in the following
quote from the Draft BRIDG Versioning Process document.

"*In the BRIDG project so far, we have had experience with both
subprojects that used the BRIDG model as the starting point for model
development and with those that did not ... We have found that these
projects* \[that used BRIDG as starting point\] *have proceeded more
quickly, because they can re-use some of the semantics that had
previously been specified, and new classes and attributes could be
easily integrated using the synchronization features of Enterprise
Architect.*"

### Pre-harmonization Process

Before any modeling activity can begin certain preparatory steps must
take place. The first step is to register the project with the Core
Model Harmonization Entity \[in this adoption of BRIDG materials, this
Entity is within BRIDG\]. This will allow the harmonization group to
assign a mentor and establish a target timeline for harmonization.
Second, some initial requirements must be established to scope the
project. Finally, the current version of the Backbone Model should be
downloaded. Since the Backbone Model is not intended to become an all
inclusive model, there is no need to create versioning branches within
the Backbone Model for each project \[this perhaps should be revisited
within an overarching caBIG Backbone Model -- versioning may make
eminent sense\].

The initial modeling for the project should be done in collaboration
with a harmonization mentor \[note: these are defined within VCDE, but
not for the modeling purpose in this segment\]. Based on the initial
scoping requirements, objects from the Backbone Model will be selected
to create a draft or outline model for the project. Since objects can be
reused in a variety of ways, it is also recommended that a spreadsheet
be used to document relationships between objects in the project model
and objects in the Backbone Model \[this may not be optimal for the
overall caBIG effort. Our overview of tools in §6 and Appendix §9.4).
For example, Backbone objects may be reused in entirety, reused with
modifications, backbone object may be split in project models, or
backbone object may be combined in project models. Objects in project
models may be implemented as sub-classes of a backbone object, or they
may be simply associated, or attributes from the backbone object may be
reused within the project model.

### General Modeling Recommendations

Some general principles should be kept in mind as the modeling effort
proceeds. While these principles are not directly related to the
harmonization process, they do help ensure efficient and effective
modeling efforts, which in turn will help the harmonization process.

The first principle is to "model in small groups, vet in large groups".
A modeling team should be limited to 6-8 participants. This allows
efficient definition of the information objects. The model can then be
reviewed by a larger group.

The second principle is to "collaborate, coordinate and share". All
modeling artifacts should be made available in a public forum, e.g.,
GForge. This allows projects to learn from others and understand why
certain modeling choices are made.

The third principle is to "include mentors in modeling efforts". This
does not require the mentor be invited to every meeting. However,
communication with the mentor should be done on a regular basis to
ensure the project team is kept abreast of the changes to the Backbone
Model.

The fourth principle is to "spend adequate time constructing both static
and dynamic aspects of the model". The natural tendency of modeling
teams is to focus on static modeling (UML class diagrams). However,
dynamic modeling can help the project in two ways. First it can engage
the domain experts, by allowing them to start with free-text
storyboards, progressing to flowcharts, state models, sequence diagrams,
activity diagrams, or use cases. As the dynamic components are discussed
the static components will naturally emerge. The second way in which
dynamic models can help a project team is to clarify that differences in
a static structure may be the result of changes in its state. For
example, a Biospecimen may have different characteristics when it is
accessioned, processed and stored.

A final suggestion is that a glossary be maintained for complex
definitions and semantic associations. While this is not required in the
harmonization process it can greatly enhance the understanding of the
project model and speed the review process.

### Post-harmonization Process

When the information model for a project has stabilized, usually at the
end of the development phase, it is ready for a final review and
harmonization with the Backbone Model. The first step is to prepare the
artifacts for review. Primarily this is the UML model, but could also
include supplementary documentation such as a glossary or a spreadsheet
of project-to-backbone object relationships. Then a meeting is scheduled
with the project team and the Harmonization team. During the
harmonization meeting changes could be identified for the project model
or the Backbone Model. Finally, changes to the Backbone Model will
require vetting with the wider caBIG community.

### Versioning/Change Control

A related concept to the harmonization process is version control, as it
will be critical to know what version of the application model is
harmonized with what version of the Backbone Model. This document will
not cover the technical mechanics of version control. We will only
discuss some of the requirements a version control system must have to
support the harmonization process.

The Backbone Model should be freely available to any project team.
However, we must ensure accidental changes are avoided. Reviews with
multiple projects may occur simultaneously, therefore we need to ensure
these separate effort can be synchronized. Finally, tracking of all
changes will be required for auditing purpose.

Finally a regular release cycles should be established to set
expectations in the greater caBIG community. This will avoid confusion
and anxiety relating to an ever changing Backbone Model.

> The BRIDG harmonization process is more fully documented in:

1)  Draft BRIDG Versioning Process v.2\
    [http://cabigcvs.nci.nih.gov/viewcvs/viewcvs.cgi/bridg_leadership/DRAFT%20Versioning%20Plan%20BRIDG2.0.doc](http://cabigcvs.nci.nih.gov/viewcvs/viewcvs.cgi/bridg_leadership/DRAFT Versioning Plan BRIDG2.0.doc)

2)  Draft processes for harmonizing BRIDG with existing models and
    messages Version 2\
    [http://cabigcvs.nci.nih.gov/viewcvs/viewcvs.cgi/bridg_leadership/DRAFT%20process%20for%20harmonizing%20existing%20models%20with%20BRIDGv2.doc](http://cabigcvs.nci.nih.gov/viewcvs/viewcvs.cgi/bridg_leadership/DRAFT process for harmonizing existing models with BRIDGv2.doc)

3)  Draft process for developing fully annotated caBIG™ UML models from
    BRIDG\
    [http://cabigcvs.nci.nih.gov/viewcvs/viewcvs.cgi/bridg_leadership/Constructing%20application%20models%20using%20BRIDGv2.doc](http://cabigcvs.nci.nih.gov/viewcvs/viewcvs.cgi/bridg_leadership/Constructing application models using BRIDGv2.doc)

# Next Steps

Throughout this whitepaper, there are many statements of further work
that needs to be accomplished. A summary of those tasks is presented
here.

1)  Create a Core Model Harmonization entity\
    A formal, ongoing body must be created to:

    a.  complete the first draft Backbone Model

    b.  integrate caBIG workgroup application models

    c.  harmonize (pre- and post-) with caBIG workgroups

    d.  perform ongoing maintenance and development of the Backbone
        Model

2)  Review processes from the BRIDG harmonization project\
    The processes/techniques developed and used by the BRIDG project
    should be reviewed and, where appropriate, adopted for the Backbone
    Model. These include:

    a.  the toolset -- Enterprise Architect, CVS and GForge

    b.  the focus on a domain analysis model rather than a highly
        abstract model

    c.  the use of dynamic as well as static modeling constructs

    d.  the techniques for interaction with other groups for
        requirements gathering, model design and consensus building

    e.  the techniques for identifying object clusters as reusable
        components

3)  Develop a pre-harmonization process\
    A pre-harmonization process should be defined to review application
    models as early in the development life cycle as possible. This
    process should be similar to the VCDE mentor program, but may
    require more resources.

4)  Develop a post-harmonization process\
    A "post-harmonization" process should be defined to review
    application models after they are complete, to update and inform the
    Backbone Model.

5)  Complete the draft of the Backbone Model\
    The "proof-of-concept" model developed by the task force should be
    expanded to include shared information objects from all caBIG
    application models.

6)  Engage community\
    The task force's products (model, report and white paper) will be
    disseminated to various bodies within caBIG, including the Strategic
    Planning Workgroup, the Architecture and VCDE Workspaces, the
    application workspaces, and the Cooperative Groups[^7], and feedback
    will be solicited. As model harmonization proceeds, lessons learned
    will continue to refine the methods used in the harmonization
    process.

7)  Create a repository for UML models\
    As part of the harmonization process, a tool will be needed to
    browse various UML models. Much of the information required is in
    caDSR and can be accessed via the CDE and UML model browsers, but
    currently neither tool is sufficient to perform the functionality
    described above.. Specifically, the harmonization process will
    require the ability to identify potential reusable objects across
    all known application models.

These initial recommendations have been captured by this white paper;
however, there is still a need to describe a process and supporting
structure to best accomplish the tasks laid out in this document. For
this reason, on October 2, 2006, the caBIG Strategic Planning Workspace
stated that the model harmonization effort outlined in the report was
possibly the most critical activity facing caBIG and requested the task
force examine which of the action items in the August report could and
should be immediately used to change processes within the caBIG project
to fully operationally implement the recommendations from the task force
and of this whitepaper.

Critical analysis of the next steps described above, and of the detailed
recommendations of the white paper, shows that there are three major
activities that should be immediately undertaken to achieve the outcome
recommended by this white paper. These activities are:

1.  The analysis, definition, and operation of the model harmonization
    processes, including incorporation of best practices from other
    modeling efforts such as BRIDG.

2.  The iterative definition and development of new tooling to support
    ongoing model harmonization activities.

3.  The active and ongoing engagement of the community regarding the
    conclusions of this whitepaper.

Since both (1) and (2) have a definitional phase and an operational
phase, from a practical standpoint it makes sense to factor these
activities out. This leaves us with the following recommended action
steps.

-   The creation of a new task force to define in detail the processes
    required for the model harmonization effort.

-   The creation of a standing model harmonization entity within caBIG.

-   The development of new tooling to support the model harmonization
    activities.

-   The active engagement of the community regarding the conclusions of
    this whitepaper.

## Recommendation: Creation of a New Task Force to Define in Detail Processes Required for the Model Harmonization Effort

As identified in this white paper, there are a series of action items
that need to be performed to incorporate the Backbone Model into the
caBIG project as a whole.

These are at a minimum:

1.  A thorough review of the processes and techniques developed and used
    by the BRIDG project should be performed. Where appropriate, these
    should be adopted for use in model harmonization.

2.  The development of the recommended pre- and post-harmonization
    processes for new applications development.

3.  Finishing the first draft version of the Backbone Model across the
    caBIG project.

4.  The development of a process to evolve existing application models
    into the Backbone Model.

5.  Defining the tooling necessary to support the harmonization process.

To fully define and oversee this process, we recommend that a new task
force be chartered to fully scope each of these activities, including
the recommended manner in which these tasks are to be implemented and
funded.

## Recommendation: Create a Standing Model Harmonization Entity within caBIG

The task force recommends that the VCDE workspace undertake the
formation of a standing, permanent workgroup within the workspace. This
workgroup would be operationally responsible for the specific activities
associated with model harmonization activities, such as overseeing the
pre- and post-harmonization processes.

While dedicated, separate working groups are a new model for the VCDE
workspace, this model is successfully used within the Clinical Trials
(CTMS) workspace. Again, since these represent new effort on the part of
the workspace, resource considerations are important for caBIG project
leadership to consider.

## Recommendation: The Development of New Tooling to Support the Model Harmonization Activities

Shortcomings with the existing tooling to support Model Harmonization
and the development of the Backbone Model have been detailed elsewhere
within this document. It is clear that a variety of new tools such as a
UML repository to expose models under development will need to be both
defined and developed, in particular beyond cataloging functions
presently provided by caDSR for models.. Furthermore, the development of
these tools will be an iterative process, supporting both the creation
and maintenance of the Backbone Model. The task force recommends that a
second group be created within VCDE focused on the creation and
maintenance of these tools.

## Recommendation: Active Engagement of the Community Regarding the Conclusions of this White Paper

We believe that successful development of the Model Harmonization
process will require good communication of the results of the current
task force, and of the proposed changes that will develop from the
follow-on work. Further, we believe that this engagement should be
proactive and seek to solicit input on models and processes as soon, and
as much, as possible as it represents a real opportunity to develop
buy-in. As a preliminary step, the task force's products (model, report
and white paper) should be disseminated to various bodies within caBIG,
and feedback solicited. In addition, a number of critical outside
groups, such as the cooperative groups and the NCRI, should be
approached.

A number of members of the current task force have indicated that they
are willing to represent the findings of this group, either via
teleconference or at face to face meetings. Ultimately, we suggest,
however, that the ongoing communication process be codified via VCDE
participation awards to a small, ongoing group charged with this
process.

## Resource Balancing 

It must be noted that a number of the activities described above are
very substantial undertakings. The task force and follow-on efforts
concluded that these are resource-intensive activities and that a number
of them will be required to continue on an ongoing basis. Thus it is
important to understand that these activities cannot simply be made the
responsibility of the existing VCDE workspace without a commensurate
reallocation of resources. The taskforce also concluded that specific
timelines for these activities could not be determined without a better
understanding of the funding, resource availability, and magnitude of
effort for each task.

# Appendices

1)  Model Inventory

2)  Backbone Model

3)  Glossary

4)  Tool Requirements

## Appendix 1: Model Inventory

> Sources: caDSR = <http://umlmodelbrowser.nci.nih.gov/umlmodelbrowser/>
>
> Registry = <http://gforge.nci.nih.gov/projects/registrymodels/>
>
> Explanation of fields in table:

+---------------+------------------------------------------------------+
| **Field**     | **Description**                                      |
+---------------+------------------------------------------------------+
| Model         | Name of the UML model or project                     |
+---------------+------------------------------------------------------+
| Version       | Identified version of the UML model                  |
+---------------+------------------------------------------------------+
| Date          | Date UML model was uploaded to the Project Registry  |
+---------------+------------------------------------------------------+
| Status        | -   the model has been [abandoned]{.underline}       |
|               |                                                      |
|               | -   the model is [immature]{.underline}, early       |
|               |     development                                      |
|               |                                                      |
|               | -   the model is fairly [robust]{.underline},        |
|               |     although not yet complete                        |
|               |                                                      |
|               | -   the model is [complete]{.underline} and          |
|               |     available for sharing across caBIG               |
|               |                                                      |
|               | -   [na]{.underline} = the identified project will   |
|               |     not generate a UML model                         |
+---------------+------------------------------------------------------+
| caDSR         | -   [caDSR]{.underline} -- Model has been loaded     |
|               |     into the production caDSR                        |
|               |                                                      |
|               | -   [Registry]{.underline} -- Cancer center domain   |
|               |     models which have been or are being processed    |
|               |     through SIW and the UML Model Loader for         |
|               |     registry within the caDSR                        |
|               |                                                      |
|               | -   *blank* -- A project was identified on a caBIG   |
|               |     workspace GForge site and this project may or    |
|               |     may not produce a UML model                      |
+---------------+------------------------------------------------------+
| Format        | Most UML models are documented using the Enterprise  |
|               | Architect tool. A value of "EA" indicates this       |
|               | assumption has been verified                         |
+---------------+------------------------------------------------------+
| Location      | GForge address of the model                          |
+---------------+------------------------------------------------------+
| Workspace     | Associated caBIG workspace, if identified            |
+---------------+------------------------------------------------------+

  ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  **Model**          **Version**   **Date**    **Status**   **caDSR**   **Format**   **Location**                                                                          **Workspace**
  ------------------ ------------- ----------- ------------ ----------- ------------ ------------------------------------------------------------------------------------- ---------------
  Agnis              1.0           February                 Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=128)   
                                   10, 2006                                                                                                                                

  best practices                                                                                                                                                           Architecture

  Best Practices,                                                                                                                                                          DSIC
  Data Sharing and                                                                                                                                                         
  MTAs                                                                                                                                                                     

  BioConductor                                                                                                                                                             ICR

  bioPAX Object      1.0           May 26,                  Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=421)   
                                   2006                                                                                                                                    

  BRIDG                                                                                                                                                                    CTMS

  C3PR               1.1           September                Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=732)   
                                   29, 2006                                                                                                                                

  ca Workbench                                                                                                                                                             ICR

  caAdapter                                                                                                                                                                CTMS

  caAERs             1.0           February                 Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=151)   CTMS
                                   22, 2006                                                                                                                                

  caArray                                                                                                                                                                  ICR

  caBIG Portal                                                                                                                                                             Strategic
                                                                                                                                                                           Planning

  caBIG Security                                                                                                                                                           DSIC
  Program                                                                                                                                                                  
  Development                                                                                                                                                              

  caBIO              3.1           March 10,                Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=186)   
                                   2006                                                                                                                                    

  caCORE             3.0                                    caDSR                                                                                                          

  caCORE Common      3.1           March 10,                Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=184)   
                                   2006                                                                                                                                    

  caDSR              3.0           March 29,                Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=238)   
                                   2006                                                                                                                                    

  CAE Remote         1.0                       Robust       caDSR       EA                                                                                                 Tissue Banks

  CAE Remote         1.2           August 16,               Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=628)   Tissue Banks
                                   2006                                                                                                                                    

  caFE Server        1.0                                    caDSR                                                                                                          

  caFE Server        1.1           February                 Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=155)   
                                   23, 2006                                                                                                                                

  caGRID                                                                                                                                                                   Architecture

  caIntegrator                                                                                                                                                             ICR

  Caisis             1.0           September                Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=740)   
                                   29, 2006                                                                                                                                

  caLAB              0.5           May 18,                  Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=392)   
                                   2006                                                                                                                                    

  caMOD (caCORE      3.1           March 10,                Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=185)   
  context)                         2006                                                                                                                                    

  caMOD 2.0 (caBIG   2.1           May 9, 2006              Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=348)   
  context)                                                                                                                                                                 

  Cancer Modeds      1.0                                    caDSR                                                                                                          
  Database 2.0                                                                                                                                                             

  Cancer Molecular   1.0           February 7,              caDSR                    [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=115)   ICR
  Pages                            2006                                                                                                                                    

  Cancer Nutrition                             na                                                                                                                          VCDE
  Ontology Project                                                                                                                                                         

  CAP Cancer         1.0           May 2, 2006              caDSR                    [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=324)   
  Checklists                                                                                                                                                               

  CAP Protocols                                na                                                                                                                          Tissue Banks

  caTIES             1.0           March 29,   Robust       caDSR       EA           [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=239)   Tissue Banks
                                   2006                                                                                                                                    

  caTIES             2.0                                    caDSR                                                                                                          

  caTISSUE Core      1.1           August 15,  Robust       Registry    EA           [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=621)   Tissue Banks
                                   2006                                                                                                                                    

  caTissue                                     na                                                                                                                          Tissue Banks
  Integrated Suite                                                                                                                                                         

  Chronic Fatigue    1.0           April 19,                Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=310)   
                                   2006                                                                                                                                    

  Clinical Genomics  2.0           July 14,                 Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=547)   
                                   2006                                                                                                                                    

  Common Logging     3.2           September                Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=683)   
  Module (CLM)                     14, 2006                                                                                                                                

  Common Query                                                                                                                                                             Architecture

  Core Middleware                                                                                                                                                          Imaging
  Developer                                                                                                                                                                

  CPAS               1.6           August 31,               Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=645)   
                                   2006                                                                                                                                    

  cPath                                                                                                                                                                    ICR

  CSM                3.1           September                Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=728)   
                                   28, 2006                                                                                                                                

  CTOM               1.0           October 3,               Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=746)   
                                   2006                                                                                                                                    

  Cytoscape                                                                                                                                                                ICR

  DAS2                                                                                                                                                                     ICR

  DWD                                                                                                                                                                      ICR

  Elmir                                                                                                                                                                    ICR

  Embedding caBIG in                                                                                                                                                       Strategic
  the Larger                                                                                                                                                               Planning
  Community                                                                                                                                                                

  EVS                3.1           March 10,   Complete     Registry    EA           [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=183)   VCDE
                                   2006                                                                                                                                    

  EVS Core Service   1.0           October 6,               Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=755)   
                                   2006                                                                                                                                    

  Firebird           1.0           April 4,                 Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=258)   
                                   2006                                                                                                                                    

  Function Express                                                                                                                                                         ICR

  Gene Connect       1.0           September                Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=731)   
                                   29, 2006                                                                                                                                

  Gene Identifiers                                                                                                                                                         ICR

  GeneConnect                                                                                                                                                              ICR

  GenePattern                                                                                                                                                              ICR

  Genomic            1.0                                    caDSR                                                                                                          
  Identifiers                                                                                                                                                              

  GoMiner            1.0           February 7,              Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=118)   ICR
                                   2006                                                                                                                                    

  gridPIR            1.0           February 7,              Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=117)   
                                   2006                                                                                                                                    

  HapMap and VPD                                                                                                                                                           ICR

  Identifiers                                                                                                                                                              Architecture

  Laboratory                                                                                                                                                               CTMS
  Interface Hub                                                                                                                                                            

  LexGrid Vocabulary                           Robust                   EA           ?                                                                                     VCDE
  Services for caBIG                                                                                                                                                       

  MAGE               1.1           September                Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=708)   
                                   25, 2006                                                                                                                                

  Magellan                                                                                                                                                                 ICR

  Mage-OM            1.0                                    caDSR                                                                                                          

  Mouse-Human                                  na                                                                                                                          VCDE
  Anatomy Project                                                                                                                                                          

  NCI-60 Data                                                                                                                                                              ICR
  Sharing                                                                                                                                                                  

  NCI-60 Drug Screen 1.0           February                 Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=156)   
                                   27, 2006                                                                                                                                

  NCI-60 SKY         1.0           February                 Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=157)   
                                   27, 2006                                                                                                                                

  NCIA Projects      1.0                                    caDSR                                                                                                          

  Ongoing                                                                                                                                                                  Strategic
  Operational                                                                                                                                                              Planning
  Support                                                                                                                                                                  

  Organization       1.0           March 2,                 Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=163)   
  (based on BRIDG)                 2006                                                                                                                                    

  P50                1.0           April 5,                 Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=265)   
                                   2006                                                                                                                                    

  Participant                                                                                                                                                              Architecture

  Patient Study                                                                                                                                                            CTMS
  Calendar                                                                                                                                                                 

  PIR                1.0                                    caDSR                                                                                                          ICR

  PIR                1.1           May 17,                  Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=388)   ICR
                                   2006                                                                                                                                    

  Population                                                                                                                                                               ICR
  Sciences                                                                                                                                                                 

  Prostate SPORES                              na                                                                                                                          Tissue Banks

  Protein            1.0           March 8,                 Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=174)   
  Identification                   2006                                                                                                                                    

  ProteomicxLIMS     1.0                                    caDSR                                                                                                          ICR

  protLIMS           1.0           March 29,                Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=240)   
                                   2006                                                                                                                                    

  Protocol Lifecycle                                                                                                                                                       CTMS
  Tracking                                                                                                                                                                 

  Q5                                                                                                                                                                       ICR

  QPACA                                                                                                                                                                    ICR

  Reactome (fka      1.0           February 7,              Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=116)   ICR
  caBIOExtensions)                 2006                                                                                                                                    

  Regulated                                                                                                                                                                Architecture
  Information                                                                                                                                                              
  Exchange                                                                                                                                                                 

  Rproteomics        1.0           February 7,              caDSR                    [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=111)   ICR
                                   2006                                                                                                                                    

  Security                                                                                                                                                                 Architecture

  Seed               1.0           February                 Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=129)   ICR
                                   10, 2006                                                                                                                                

  SNP500Cancer       1.0           March 29,                caDSR                    [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=241)   
                                   2006                                                                                                                                    

  SPORES             1.0           May 9, 2006              Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=350)   

  TrAPSS             1.0           February 7,              Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=112)   ICR
                                   2006                                                                                                                                    

  Tumor Registry     1.0           September                Registry                 [[Download]{.underline}](http://gforge.nci.nih.gov/frs/?group_id=64&release_id=667)   
                                   12, 2006                                                                                                                                

  VISDA                                                                                                                                                                    ICR

  Workflow                                                                                                                                                                 Architecture

  Workflows                                                                                                                                                                Strategic
                                                                                                                                                                           Planning
  ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

## Appendix 2: Draft Backbone Model

**Enterprise Architect file:\
**<http://gforge.nci.nih.gov/frs/download.php/792/ICR_and_TBPT_Model_Harmonization_Final.EAP>

![](media/image3.png){width="7.795833333333333in"
height="7.166666666666667in"}

## Appendix 3: Glossary 

  --------------------- -------------------------------------------------
  **Term**              **Definition**

  Application Model     An information model defined for the
                        implementation of a specific application.

  Attribute             Information within a managed object that is
                        visible at the object boundary.

  Backbone Model        An overarching model, derived from application
                        models that is used to guild the semantic
                        interoperability of those application models.

  Class                 A model or template that can be instantiated to
                        create objects with a common definition and
                        therefore, common properties, operations, and
                        behavior.

  Data Model            The \"data model\" is the specification of the
                        structure, format, syntax, and occurrences of the
                        data instances it represents.

  Gold Level            Currently being defined by caBIG. Is expected to
  Compatibility         provide for a formalized grid architecture and
                        data standards that will enable standardized
                        advertising, discovery, and use of all federated
                        caBIG resources.

  Harmonization         The process of making identical or minimizing the
                        differences between objects and attributes within
                        a specified domain.

  Harmonization, Post   The process of building or updating the Backbone
                        model based on application specific models.

  Harmonization, Pre    The process of building or seeding application
                        specific models based upon the Backbone model.

  Identifier, class     The name or other reference used to uniquely
                        refer to a class within a model or across
                        multiple models.

  Identifier, instance  An attribute within a class used to uniquely
                        reference each occurrence of that class.

  Information Model     A model of the information requirements of a
                        business or business area. An information model
                        consists of a diagram and definitions of each
                        entity, attribute and relationship.

  Inheritance           A way to form new classes (instances of which
                        will be objects) using pre-defined objects or
                        classes where new ones simply take over old
                        ones\' implementations and characteristics.

  Model Driven          An approach to software development that provides
  Architecture          a set of guidelines for structuring
                        specifications expressed as models.

  Object                A concrete realization of a class that consists
                        of data and the operations associated with that
                        data.

  Object Reuse          The ability to define object within one domain or
                        model based on object in another domain or model.
                        This will include partial reuse, that is, the
                        ability to define the object with only some of
                        the characteristics of the original object, e.g.,
                        reuse of the data type but not the value set.

  Property              A characteristic or attribute that describes a
                        unit of information.

  Semantic              Data semantics is the relationship between data
  Interoperability      and what the data stand for. In order to obtain
                        mutual understanding of interchanged data, the
                        actors have to share a model of what the data
                        represent. Semantic interoperability is about how
                        to achieve such mutual understanding.

  Silver Level          A rigorous set of requirements that, when met,
  Compatibility         significantly reduce the barrier to use of a
                        resource by a remote party who was not involved
                        in the development of that resource.

  UML Model             Unified Modeling Language™ (UML) is an
                        industry-standard language for specifying,
                        visualizing, constructing, and documenting the
                        artifacts of software systems standardized by the
                        Object Management Group

  Value Domain          The Value Domain provides representation, but has
                        no implication as to what Data Element Concept
                        the Values may be associated with nor what the
                        Values mean

  Value Set             The list of values an attribute may contain.
  --------------------- -------------------------------------------------

## Appendix 4: Tool Requirements

As identified within this white paper, automated tools will be required
for an efficient and effective harmonization process. A draft set of
requirements for those tools is listed below:

-   Identify semantically similar objects from the caDSR based supplied
    criteria such as shared concepts, ontologies, shared attributes or
    shared value domains.

-   Cluster the semantically similar object into hierarchical
    structures.

-   Document inter and intra cluster relationships, based on source UML
    relationships.

-   Identify and document generic/archetype object within the
    hierarchical structures based upon criteria for appropriate level of
    abstraction. The generic objects would be candidate backbone
    objects.

-   Document how application objects relate to backbone objects, i.e.,
    describe object reuse.

-   Enable side-by-side browsing of existing UML models, both
    application models and backbone model.

-   Versioning system and protection of the backbone model from
    unintended changes.

-   Identify which objects (and their forms of reuses) are required or
    optional.

> Overall benefits the tools should provide:

-   improve reuse of objects and CDEs

-   reduce duplication of objects

-   reduce effort for defining new application models

-   increase the level of interoperability between caBIG applications

-   increase compatibility with other external initiatives (e.g., NCRI)

[^1]: <http://gforge.nci.nih.gov/docman/view.php/135/3203/caBIG_Model_Harmonization_Report.doc>

[^2]: <http://gforge.nci.nih.gov/docman/view.php/135/3203/caBIG_Model_Harmonization_Report.doc>

[^3]: [http://www.bridgproject.org](http://www.bridgproject.org/)

[^4]: [http://www.ncri.org.uk](http://www.ncri.org.uk/)

[^5]: <http://gforge.nci.nih.gov/frs/download.php/510/Komatsoulis-Harmonization.ppt>

[^6]: <http://ncicb.nci.nih.gov/infrastructure/cacoresdk>

[^7]: <http://www.cancer.gov/cancertopics/factsheet/NCI/clinical-trials-cooperative-group>