# Presentation: 284219

## CTMS Metadata Project – Challenges and Issues

- Hemant Shah M.D.
- City of Hope National Medical Center
- hshah@coh.org

## Original Metadata Project

- The Scope
- Create data elements for the CTMS workspace
- Approach
- Use Information Models available – if none available create one
- Manual extraction of data elements
- Manual mapping of data element components to vocabulary

## Need for Metadata Project Revision

- Models started evolving rapidly
- Tools were developed
- Processes were defined

## Revised Metadata Project Principles

- Create CDEs for focused areas
- Utilize the existing models - Work within the ambit of caAERS-BRIDG harmonization effort
- Enhance the “areas” in the models if required
- Follow the caCORE SDK process
- Review by the caBIG community

## Steps for Revised Metadata Project

- Step 1 – Selection and Prioritization of Areas
- Step 2
- Step 2 A – Selection of the Base Representation
- Step 2 B – Creation of Metadata Appropriate Representation
- Step 3 – caCORE SDK Process
- Step 4 – VCDE Review Process

## Step 1 – Selection and Prioritization of Areas

- Definition of “Area”
- A class or a set of closely related classes representing a facet or a feature of the domain
- Selection / Prioritization Criteria
- Classes that are or should be represented in both models (BRIDG and caAERS)
- Classes that are likely to be of interest to other sub-domains
- Classes that are more stable in the reference model

## Initial Selected Areas

- Organization
- Person
- Study Subject
- Product
- Location
- Device
- Material
- Product

- Drug
- Ingredient
- Participation
- Observation
- Clinical Study
- Protocol
- Procedure
- Treatment

## Modeling Effort – Step 2 A – Selection of the Base Representation

- The representation that is closest to being a “***metadata appropriate representation***” will be selected
- Additional criteria for Base representation
- Expressivity/Comprehensibility
- Flexibility
- Practicality
- Reusability

## Modeling Effort – Step 2 B – Creation of Metadata Appropriate Representation

- Definition of Metadata Appropriate Representation:
***A UML static model that***:
- Meets the caCORE SDK requirements for the Semantic Connector and UML loader tools
- Will generate data elements that are
- Semantically appropriate and connected to concepts in NCI Thesaurus
- Compatible with the existing caBIG Data Standards already approved by VCDE

## Modeling Effort – Step 2 B – Additional Goals

- The representation should:
- Be semantically and syntactically compatible with the reference models/larger domain models like HL7 RIM and BRIDG
- Be comprehended by the domain personnel
- Lead to data elements that are easily understood by the domain personnel
- Be suitable for being used/adapted by sub-domains
- Meet the caCORE SDK Code Generator expectations
- Retain the best features from both representations

## Stratagem - Examples

- Intermediate Representation (Buffer Zone)
- Inheritance for Reuse Vs. Composition for Reuse
- Façade design pattern

## Stratagems – Intermediate Representation

**Reference Model**

**Sub-Model**

**Stratagems – Intermediate Representation**

## Stratagems – Intermediate Representation

**Reference Model**

**Sub-Model**

**Buffer Model**

**Stratagems – Intermediate Representation**

## Stratagems – Intermediate Representation

**Sub-Model**

**Buffer Zone**

**Stratagems – Intermediate Representation**

## Stratagems – Intermediate Representation

**Sub-Model**

**Buffer Zone**

**Stratagems – Intermediate Representation**

## Stratagems – Intermediate Representation – Advantages

- A representation that is more implementation oriented but retains semantic links with the implementation independent model
- Delineates clearly the area where we contributed
- Creates a representation that the other sub-domain models/implementations can utilize if suitable
- The authors of the reference model may consider the intermediate representation when they revise the model
- If changes occur in either models the linkage can still be maintained by making changes only in the intermediate representation

## Stratagems – Reuse by Inheritance Vs. Reuse by Composition

- Problem:
- Cannot get intuitive data elements like:
**	****Subject First Name**
**	****Subject Last Name**
**But **Names like:
**	****Person Name First Name**
**	****Person Name Last Name**

**Option 1 – Reuse by Composition**

## Stratagems – Reuse by Inheritance Vs. Reuse by Composition

- Problem:
- Each class will have to have the same attributes repeated

**Option 2 – No Reuse**

## Stratagems – Reuse by Inheritance Vs. Reuse by Composition

**Option 3 – Reuse by Inheritance**

- Each class can have the same set of attributes without the need to repeat and the data elements generated will be intuitive e.g., Subject First Name, Data Manager Last Name etc.

## Stratagems – Façade design pattern

*Definition: *
*	**A Class or Object provides a single point of entry for services of a subsystem*
- Aim is to hide a complex system of objects behind a single object

## Stratagems – Façade design pattern

**HL7 RIM Organization Related Classes**

## Stratagems – Façade design pattern

**Transformed View of HL7 RIM Related Classes**

## Stratagems – Façade design pattern

**Stratagems – Façade design pattern**

## Stratagems – Façade design pattern

## Step 3 – caCORE SDK Process

**Generate Semantic Report Using Semantic Connector**

**Review & Annotate Semantic Report**

**Review & Annotate Semantic Report**

**Generate Annotated XMI**

**Generate & load CDEs using UML Loader**

**CDE curation in caDSR**

- COH

- NCICB

**1**

**2**

**3**

**4**

**5**

**7**

**8**

**Create submission Package**

**6**

- 1 Day

- 1 Week

- 3 Days

- 1 Day

- 1 Week

- 1 Day

**Step 3 – caCORE SDK Process**

## Step 4 – VCDE Review Process 

- The caBIG community and VCDE WS will be invited to comment at every stage
- The data elements will be submitted for the formal VCDE review process

## Miscellaneous Issues

- Complex datatypes
- HL7 datatypes
- Units of Measure
- Use of LOINC

## Problems with the Standard Data Elements Approach

- Fragility
- Every time the model undergoes a change, the DEs have to be changed
- The applications have to deal with two kinds of changes – the model changes, the DE changes
- The domain experts spend their times deciding validity twice
- At the model level
- At the data standard level
- Potential of conflict at the two levels
- DEs are only a tunnel view of a larger picture

## Too Many Dependencies

**Vocabulary/Ontology**

**Application**

**Data Elements**

**Too Many Dependencies**

## Common Model Repository Approach

- Have a caMSR instead of caDSR
- The application developers only identify the attributes from the model + the extent of context information they want to include
- The repository should allow negotiation of models in a graphical manner
- The data elements would be generated on-the-fly by the client end components, from the models
- New Developer tools
- Closely integrated with Enterprise Architect
- With the current functionality of SIW
- With the ability to interact directly with the caMSR

## Common Model Repository Approach

**Vocabulary/Ontology**

**Application**

**Common Model Repository Approach**