# Presentation: 299799

## NKOSNext Generation Knowledge Organization Systems: Integration Challenges and StrategiescaDSR Use Case

- Denise Warzel
- Assistant Director
- NCICB, caDSR
- June 10, 2005

## NCI’s Semantic IntegrationGoals	

- Sharable data, aggregatable across research domains
- Unambiguous data characteristics
- to convey semantic, syntactic and lexical meaning
- _Human and Machine understandable_
_**EMPHASIS ON MACHINE UNDERSTANDABLE**_
- Tools to create, maintain, deploy data standards
- Widely and publicly accessible
- Available as an Open Source Download
- Open Development Initiative (June 2005)

## NCI caCORE Infrastructure

**Enterprise Vocabulary**

**Data Standards**

**Bioinformatics Objects**

- caCORE is the open-source foundation upon which the NCICB builds its research information management systems

- NCI Thesaurus
- NCI Metathesaurus
- LOINC
- MGED
- ......

- Metadata descriptors
- Based on concepts

**Notes:**
The three key components of caCORE are the Enterprise Vocabulary Services, figuratively and literally the foundation of caCORE; 

the cancer bioinformatics objects, caBIO, providing biomedical data objects implemented in a robust extendable architecture;

and the cancer Data Standards Repository, caDSR, providing, among other things, a semantic bridge between the data elements in registered data objects and standard vocabularies and ontologies.  

NCICB-developed caCORE components are distributed under open-source licenses that support unrestricted usage by both non-profit and commercial entities, downloadable from the NCICB web site.

The question is how does all this fit together?

The next question is, of course, how do all of these things work together? 

## Approaches: Semantic Integration and Interoperability

- Option 1
- “Forced Collectivization”
- Everyone adopts a single data model for a particular domain
- Genbank, PDB, HL7 are examples of these sorts of models
- Option 2:
- “Local Networks”
- Several sites agree on a format for interchanging data
- Sites maintain a local data dictionary, XML schema, etc. to describe information model

- Advantages:
- Ensures interoperability
- Minimal overhead
- Disadvantages:
- Not flexible
- Does not allow for data stores for particular use cases
- Advantages:
- Flexible
- Low Overhead
- Disadvantages:
- Works only where existing bilateral (or multilateral) agreements exist
- Each new node must arrange to be interoperable with all other nodes or node cluster

- * **Derived from slides by G. Komatsoulis NCICB**

## Approaches: for Semantic Integration and Interoperability

- Option 3
- “Common Data Elements”
- Provide a complete description of all attributes in a systematic, uniform and unambiguous format
- Description must be based on a common (but expandable) vocabulary.
- Rely on concept codes, not concept names

- Advantages:
- Provides more ways to surface semantic matches – words and immutable codes
- Allows new systems to find points of interoperability with all other data systems at once
- Machine understandable
- Stable immutable identifiers
- Disadvantages:
- Requires a very complete description of the contents of an attribute.
- Some degree of overhead associated with creating and maintaining a compatible system

*** ******caDSR is based on ISO 11179 Information Technology – Metadata Registries (MDR) parts 1-6***

## Utilizing Semantic Integration for Interoperability

- Agent

- name

- nSCNumber

- FDAIndID

- CTEPName

- IUPACName

- Drug

- id

- NDCCode

- approver

- approvalDate

- fdaCode

- = C1708:C41243

- = C1708:C41243

- C1708 Drug/Agent

- id

- NDCCode

- approver

- approvalDate

- nSCNumber

- name

- FDAIndID

- CTEPName

- IUPACName

- =

*** Example provided by Dr. George Komatsoulis, NCICB**

## Concept Use and Integration 

_**Object Class**_
_**Chemopreventative Agent**_

_**Property**_
**Name**

_**Conceptual Domain**_
**Agent**

_**Data Element Concept**_
**Chemopreventive Agen Namet**

_**Data Element**_
**Chemopreventive Agent Name**

_**Value Domain**_
**CTEP Drug Names**

_**Representation**_
**Name**

_**Valid Values**_
**Cyclooxygenase Inhibitor**
**Doxercalciferol**
**Eflornithine**
**...**
**Ursodiol**

- Concept Use and Integration

*** based on  ISO/IEC 11179 Part 3 Metamodel**

## Concept Use and Integration 

- Specific order of concepts is determined by the ISO 11179 Part 5 Naming and Identification Principals + NCICB Convention
- Concept codes are strung together in a specified order so they can be compared for semantic equivalence by a computer
**DEC = ObjectClassQualifer(1..n):****ObjectClass: ****Property Qualifer(1..N):****Property**
- DataElement:** Physician**** Person ****Birth**** ****Name**
- concept string: **C25741****:****C25190:****C25155****:****C25284**
- Naming Wizard
- Construct naming and definitional metadata registry attributes by building up the pieces from underlying concepts
- Names and Definitions.
- Semantic Connector
- Parses and matches UML Domain Object Model class and attribute names and searches NCI Thesaurus for matches
- Human intervention to review and confirm preferred matching
- Model owner signoff, loaded to caDSR

## Concept caDSR Search/Retrieval Requirements

- Search by name(s) using multiple languages
- Search by synonym(s) using multiple languages
- Search in definition(s) using multiple languages
- Search by source terminology concept identifier
- Search in specific terminology
- Find all administered items associated with the concept

## Concept caDSR Usage Requirements

- Navigate parent/child within a structured concept system
- Navigate sub/super concepts across concept systems
- Access status (e.g. exclude/include retired concepts)
- Access History
- We save in caDSR: concept preferred name, preferred definition, source, source concept identifier, alternate definitions (and who used it)
- Relationships to other caDSR administered items (many to many) currently: VD, VM, OC, P
- Concept identifier
- Concept order
- Derivation Rule – currently either Simple or Compound Type rule

## Concept RelationshipscaDSR Requirements

- We save in caDSR: concept preferred name, preferred definition, source, source concept identifier, alternate definitions (and who used it)
- Relationships to other caDSR administered items (many to many) currently: VD, VM, OC, P
- Concept identifier
- Concept order
- Derivation Rule – currently either Simple or Compound Type rule

## Object Class AssociationscaDSR Requirements

- Stored as “Object Class Relationships”
- Target
- High multiplicity
- Low multiplicity
- Source name
- High multiplicity
- Low multiplicity

## EVS and caDSR Distinctions

- caDSR is a metadata repository
- maintains metadata to permit a user to locate the correct data element defining the characteristics of a piece of datum, an instance of a specific concept, in sufficient detail to be collected and stored on a computer
- EVS is a terminology server
- provides services for synonymy, mapping between vocabularies, hierarchical structures, access to ontololgies, terminologies and the constructs associated with those (broader, narrower, Subconcepts, Superconcepts, Roles, Semantic type, etc.)

**Notes:**
The point here is that we have separated terminology development from data element development.  caDSR is a customer of EVS. 

## Integration Challenges

- Terminology shifts
- Name changes
- Definition Changes
- Concept Retire, merge, split
- Harmonization across Context
- Different lifecycle paradigms
- Metadata Paradigm – Versioning, lifecycle management within specific Context
- Terminology Paradigm – Absent specific Context/Domain
- In the process of developing a monthly maintenance program to keep the caDSR and terminology synchronized

**Notes:**
The point here is that we have separated terminology development from data element development.  caDSR is a customer of EVS. 

## Summary NCI SemanticIntegration Strategy

- Create a data sharing architecture or “grid”
- Create sharable data descriptors, reusable across research domains
- Unambiguous data characteristics to convey semantic, syntactic and lexical meaning
- _Human and Machine understandable_
_**EMPHASIS ON MACHINE UNDERSTANDABLE**_
- Simplify creation of applications that can leverage the architecture

## Acknowledgements

**NCICB**
- Peter Covitz
- Denise Warzel
- George Komatsoulis
- Frank Hartel
- Gilberto Fragoso
**Oracle**
- Edmond Mulaire
- Ram Chilukuri
- Prerna Aggarwal
- Dan Ladino
- Christophe Ludet
- Shaji Kakkodi
- Jane Jiang

**ScenPro**
- Bill McCurry
- Tom Phillips
- Robert Harding
- Jennifer Brush
- Larry Hebel
- Smita Hastak
**ISO**
- ISO/IEC 11179 Information Technology - Metadata Registries (MDR) Parts 1-6
**2002(E) +**

## NCICB Concept ClassCommon Attributes

- Concept Class
- Administered Item attributes +
- Concept Unique Identifier
- Pointer to an externally defined concept
- Concept Definition Source
- Names the source terminology/ontology/vocabulary
- Concept Relationship
- Semantic Order of the concepts
- NOTE: ISO describes a ‘Concept Relationship’ as a semantic link among two or more concepts.  There is a subtlety in our implementation.  In caDSR use the concept relationships as more of a derivation rule, naming the order of the concepts - not semantic relationships in an ontologic or object model sense of ‘relationship’.
- Object Class, Property, Representation term, Qualifier terms, Value Domains

**Notes:**
Our approach separates development of data element metadata from construction of an actual ontology, terminology or taxonomy, leveraging existing standards instead of creating something anew.  

## caCORE Infrastructure wiring

**Notes:**
Starting on the left side of the slide, this represents the genesis of data elements arising from clinical trials and scientific research, and their transformation into descriptive metadata represented in the caDSR.  APIs between the caDSR and EVS provide access to standard vocabularies and ontologies curated by external standards development groups such as the National Library of Medicine, LOINC and MGED.  These vocabularies are used in naming and defining the metadata for the data elements.   

caBIO data objects provide a roadmap of the biology of cancer, represented in UML.  The UML is transformed into ISO 11179 metadata, including data elements.  caBIO Model Driven Architecture (MDA), allows users to easily generate public APIs to access the data model. 

Today we will delve into the caDSR in more detail.