# Presentation: 247215

## An Introduction to Semantic InteroperabilityAugust 15, 2005

*George Komatsoulis*
*Associate Director, Biomedical Informatics*

**Notes:**
I bring you greetings from George Komatsoulis, the Associate Director for Bioinformatics here at NCICB.

George is on vacation currently, and so will not be here in person to talk with you.  But he has been kind enough to share the following slides and content with us.

## An Introduction to Semantic InteroperabilityPresenters

*Dianne M. Reeves **	*NCICB
*Tommie G. Curtis**	*SAIC

**Notes:**
I am Dianne Reeves.

I work with George in the core infrastructure portion of NCICB, mostly on the curation of metadata for caDSR users.

I also oversee the training courses now being offered by NCICB in the use of caDSR tools.

Tommie Curtis will also be presenting this morning.  Tommie and her team from SAIC are known to many of you.  They are charged with metadata curation responsibilities, and work with many groups loading UML models in order to create the metadata they need.

Tommie and her team are also taking the lead on harmonization and the creation of standards activities in NCICB.

## Learning Objectives

- By the completion of this session, the participant will be able to:
- Discuss the importance of semantic interoperability
- Identify key components of a caDSR CDE
- Outline the steps in UML-based creation of CDEs

**Notes:**
Learning Objectives for this session – only three – include:

## Interoperability

- Semanticinteroperability

- Syntacticinteroperability

*Courtesy: Charlie Mead*

**in·ter·op·er·a·bil·i·ty**
- ability of a system...to use the parts or equipment of another systemSource: Merriam-Webster web site
**interoperability**
- ability of two or more systems or components to exchange information and to use the information that has been exchanged.Source: IEEE Standard Computer Dictionary: A Compilation of  IEEE Standard Computer Glossaries, IEEE, 1990]

**Notes:**
Semantic Interoperability is fundamentally the ability to reuse data collected for some other purpose.   In this case, it allows us to reuse the same concepts or CDEs across multiple trials.  

Of the two – syntactic and semantic interoperability - it is the most difficult.

 It requires a deep understanding of the nature of the data, how it was collected, stored, etc. for the data to be successfully used by a system that did not do the actual collection.

## Obtain and Use Information From the Grid	

- Obtain information
- ‘Syntactic interoperability’
- Grid Services (an extension of Web Services) provides data objects that have been serialized as XML
- Use Information
- ‘Semantic interoperability’
- To actually use data, it is essential to understand exactly what that data means, how it was collected, and what constitutes a valid response for that data.
- This information describing what was being measured is often called ‘data about data’ or ‘semantic metadata’.

**Notes:**
The use of the Grid in the caBIG community will meet two major needs that we have:

It will allow us to obtain information, depending on syntactic interoperability, using Grid services (you will hear more about this later in this presentation),

It will allow us to use information – requiring semantic interoperability.

This means it is essential that we understand exactly what the data means, filter out all ambiguities, so the result is clear.  

## Semantic Metadata: An example

| Class or Attribute Name | Value | NCI Metadata | CIA Metadata |
| --- | --- | --- | --- |
| Agent |  | A chemical compound administered to a human being to treat an existing disease or condition, or prevent the onset of a disease or condition | A sworn intelligence agent; a spy |
| nSCNumber | 007 | Identifier given to a chemical compound by the US Food and Drug Administration (FDA) Nomenclature Standards Committee (NSC) | Identifier given to an intelligence agent by the National Security Council |
| name | Taxol | Name of a chemical compound given by the NCI Cancer Therapeutics Evaluation Program (CTEP) | Code name given to intelligence agents by the Central Intelligence Agency (CIA) |

**Notes:**
The segue from here is so how do we utilize this to provide semantic interoperability?

## Mechanisms to Achieve Semantic Interoperability

- Option 1
- Everyone adopts a single data model for a particular domain
- Genbank, PDB, HL7 are examples of these sorts of models
- Advantages:
- Ensures interoperability
- May occasionally be required for advancement of a particular field of knowledge where the data and technology are fairly well understood (sequence collections for example)
- Minimal overhead
- Disadvantages:
- Not flexible
- Does not allow for data stores for particular use cases

## Mechanisms to Achieve Semantic Interoperability

- 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:
- 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 clusters.

## Mechanisms to Achieve Semantic 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.
- Advantages:
- Allows federated development
- Allows new systems to find points of interoperability with all other data systems at once
- Disadvantages:
- Requires a very complete description of the contents of an attribute.
- Some degree of overhead associated with creating a compatible system

## caCORE Components

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

**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.

## caCORE Infrastructure wiring

- Domain object metadata

**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. 

## Cancer Data Standards Repository (caDSR)

- A system for storing metadata
- Enterprise-class system with APIs that give runtime access to metadata and semantics
- Implements the ISO 11179 standard, a flexible model for describing arbitrary metadata
- The basic unit of information in the caDSR is a Common Data Element or CDE. It can be thought of as a complete description of a datum that is being collected
- CDEs are based on controlled terminology supplied by the NCI Enterprise Vocabulary Services
- The caDSR has been utilized for both clinical case report forms and to describe metadata associated with UML Models

**Notes:**
caDSR is a system or repository for storing metadata – primarily Data elements, but also classification groups containing data elements, or forms, or templates.

APIs give runtime access to metadata and semantics.

caDSR implements the ISO 11179 standard for describing metadata.

The basic unit of information is the Common Data Element, or CDE.  It is the atomic unit, or the smallest possible complete description of a datum that is being collected.

CDEs are built from concepts that are registered, housed and made available through the NCI Enterprise Vocabulary Services, or EVS.

caDSR has been used to hold metadata that supports both case report forms (CRFs) and to describe the metadata in UML models.  

## Terms and Definitions for

**Data Element: **

-    A unit of data for which the definition, identification,

- representation, and permissible values are specified by means of a set of

- attributes.

**Data Element Concept: **

-    An idea

- that can be represented in the

- form of a data element, described

- independently of any particular

- representation.

**Value Domain:**

-    Restricted

- permissible values.

**Value Meaning:**

-    A member of the

- set of finite allowed inventory of

- notions that can be categorized

- for a conceptual domain.

**Permissible Value:**

-    An

- expression of a value

- meaning in a specific

- value domain

**Representation Class:**

-     A

- classification of data

- elements based upon the

- type of representational

- form.

**Conceptual Domain:**

-     A set

- of possible value meanings

- of a data element expressed

- without representation.

**Data Element Representation:**

- The part of a data element having

- a part of a data element having a

- value domain, datatype,and other

- representational specifications.

**Terms and Definitions for**
**ISO/IEC 11179-3**

**Notes:**
The ISO 11179 model relates Data Elements and their permissible values to concepts using Data Element Concepts and Conceptual Domains.  Each of the major components of the model is called an Administered Component and brief definitions are provided for you as references.

## caDSR Implementation of ISO/IEC 11179 Model

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

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

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

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

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

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

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

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

**Notes:**
This is in here so that the presenter can give an overview of the caDSR/ISO metamodel that will figure so prominently in the explanation of semantic interoperability

## Semantic Integration in caBIG

**UML Class = ISO Object Class**
- Example: Agent = C1708 (Agent)
- ISO Object Classes are mapped to 1 or more concepts from EVS (a primary concept + ordered qualifiers)
**UML Class Attribute = ISO Property**
- Example: nSCNumber = C41243 (NSC Code)
- ISO Properties are mapped to 1 or more concepts from EVS (a primary concept + ordered qualifiers)
**UML Class + UML Class Attribute = ISO Data Element Concept**
- Agent:nSCNumber = C1708:C41243
- ISO DEC’s are mapped to 2 or more concepts (from OC + Property)
**UML (Java) Datatype = ISO Value Domain (at least initially)**
- Example: java.lang.Integer
- Enumerated/other value domains curated after initial UML loading
**UML Class + UML Class Attribute + Datatype/Valid Values = ISO Common Data Element**
- Example: Agent:nSCNumber: java.lang.Integer
**A Common Data Element is given a public identifier and a version.**

**Notes:**
Additional points to make on this slide:

Object classes, Properties, and DEC’s that have the same concepts are not created, we just reuse the existing one.

Same with data elements

Such data elements are ‘self-harmonizing’

Having gone through this complex semantic annotation step, what does that buy us?

## Utilizing Semantic Integration for Interoperability

- Agent (C1708)

- name

- nSCNumber

- FDAIndID

- CTEPName

- IUPACName

- Drug (C1708)

- id

- NDCCode

- approver

- approvalDate

- fdaCode

- = CDE 15654 v1

- = CDE 15654 v1

- C1708 Drug/Agent

- id

- NDCCode

- approver

- approvalDate

- nSCNumber

- name

- FDAIndID

- CTEPName

- IUPACName

- =

**Notes:**
There are several important points here:
If two attributes of two distinct classes map to the same data element and version they are defined as ‘Grid Keys’ and can be used to aggregate information.
 If there exists such a set of data elements, then by definition both UML classes have the same object class and hence both UML classes are describing the same thing (perhaps with different attributes).
 Note that I am using public ID and version here (not the concept codes). Interoperability is defined by CDEs, not the concept codes (remember that the concept codes only really cover the DEC). The same DEC with a different value domain is not an aggregatable match.
 We do use the concept codes to identify UML classes+attributes that have the same DEC as existing data elements at UML loading. We also use the concept codes for the advertising and discovery use case (i.e. show me systems that have information about agents/drugs = C1708.

Finally, how do we do this process?

## The caCORE Software Development Kit (SDK)

- http://ncicb.nci.nih.gov/core/SDK

**Notes:**
The NCICB caCORE Software Development Kit is a set of tools designed to aid in the design and creation of a 'caCORE-like' software system. Such a system is said to be 'semantically integrated', that is, all exposed API elements have runtime accessible metadata that defines the meaning of the elements using controlled terminology. 
To achieve this integration, 'caCORE-like' systems follow certain design practices: 
UML Modeling 
n-tier architecture with Open APIs 
Controlled Vocabularies 
Registered metadata 

## SDK Documentation

**caCORE ****SDK Programmers Guide** (revised 05August05) contains detailed instructions on the use of the SDK and how it helps create a caCORE like software system
**caCORE SDK Installation and Basic Test Guide** (revised 05August05) contains detailed instructions on how to install and test your SDK installation
**Release Notes**

**Notes:**
The SDK contains documentation to help the user use the tools.  The most recent version of the documentation is August 2005.

## Components of the Toolkit

**UML Modeling Tool (Programmer Guide, Chapter 5)**
- Not supplied as part of the toolkit
- We use Enterprise Architect (EA) at NCICB, but any modeling tool that supports XMI 1.1 with the Rose/Unisys extensions will work.
**Semantic Connector (Programmer Guide Chapter 6)**
- Assists with the semantic integration component by searching for concepts and annotating the XMI representation of a UML model.
- Distributed with the toolkit. For now, we would prefer that NCICB run the semantic connector for groups with properly annotated UML models.
**UML Loader (Programmer Guide, Chapter 7)**
- Takes the semantically annotated XMI file, creates appropriate CDEs from the UML model and loads them into the caDSR.
- The UML loader is not included in this distribution; for now, all UML loading will be done at NCICB.
**Code Generator (Programmer Guide, Chapter 8)**
- Input is an XMI representation of a UML model
- Creates the ‘caCORE-like’ software system.
- Distributed with the toolkit.

**Notes:**
The SDK Toolkit includes several components to support the application developer and facilitate semantic assignments.  You will be hearing about these tools in more detail during the day.

## Slide 20

**Notes:**
The caCORE components outline previously are key to the development process that will be discussed today.  The semantic information is added to an application by using terms from EVS; the data elements generated from a model are recorded in the caDSR; and the APIs that are used are based on caBIO.   You will be seeing this process throughout the day as the presenters describe the development process.

## Concept Annotations-some details

- Initial concept mapping is performed by the semantic connector
- The connector takes UML entity names (classes and attributes) and searches NCI Thesaurus
- Search Strategy
- Full entity name
- Break entity name based on camel case and reconnect with underscores then search
- Break entity name based on camel case and search by individual terms
- Concept annotation is continued by an annotator from NCI EVS.
- Concept annotation is a **process** involving the model owner and the EVS curator. The model owner is the final arbiter of semantic ‘goodness of fit’

**Notes:**
As we noted in the diagram, the semantic annotation of a model is done using the Semantic Connector.

## Pre- vs. Post-Coordinated Concepts

- There is usually more than one way to annotate some concepts:
- Pre-coordinated: Create/use a concept in EVS that fully describes the attribute
- Property = Primary Gleason Score
- Post Coordinated: Use several concepts to describe the attribute
- Property = Gleason Score
- PropertyQualifier1 = Primary
- The general principle for using pre- vs. post-coordinated concepts is to use post-coordination unless there is semantic value that can be gained by using the pre-coordinated concept

**Notes:**
Pre-coordinated concepts are those that are fully described (and matched) in EVS.  In many cases this is a semantically correct way to describe the concept in a model.  However, in some cases better semantic interoperability can be achieved by using a qualifier term rather than a complex exact match.  This review and decision making is done after the initial Semantic Connector pass and is called Post Coordination.

## Examples for pre-coordination

- When using qualifiers would reduce or eliminate semantic clarity:
- ‘French Fries’ should be a single concept because splitting the terms would not produce a semantically correct mapping.
- When using qualifiers would prevent semantic clarity later on, usually because there are numerous derived attributes, or because the phrase is absolutely central to our activities.
- ‘Clinical Trial’ should be a single concept because we will see many other related attributes, i.e. ‘Clinical Trial Protocol’, ‘Clinical Trial Protocol Start Date’, etc.

## Examples that should use post-coordination

- Date
- beginDate, endDate, dateModified
- Name
- preferredName, alternateName,
- Indicator
- deleteIndicator, latestVersionIndicator
- Identifier/ID
- publicID, locuslinkID,

## Some known gotcha’s associated with concept mapping

- The semantic connector cannot identify concepts for most abbreviations
- Use ‘sequenceLength’ not ‘seqLength’
- Appropriate camel case (or underscoring) is essential
- Use ‘bioassay’ not ‘bioAssay’
- Don’t repeat the class name in attribute names:
- In class ‘Gene’, use attribute ‘identifier’ not ‘geneIdentifier’
**See the Programmer Guide – p. 31 Naming Best Practices**

**Notes:**
See the Programmer Guide for Naming Best Practices guidance.

## Repeating Class Name in Attributes

- Mapping of Gene.identifier:
- Object Class = ‘C16612’ (Gene)
- Property = ‘C25364’ (Identifier)
- Mapping of Gene.geneIdentifier
- Object Class = ‘C16612’ (Gene)
- Property = ‘C25364’ (Identifier)
- PropertyQualifier1 = ‘C16612’ (Gene)
- Could prevent interoperability, since DEC’s are different:
- Gene.identifer = “C16612:C25364”
- Gene.geneIdentifier = “C16612:C16612:C25364”
- Repetition of a concept code is improper

## Post-load Data Element Curation

- After loading, the data elements go through a post-load curation step
- This is a manual process by which appropriate value domains (particularly enumerated value domains) are attached to the data elements.
- This step is essential for proper semantic interoperability even when the value domain is not enumerated.
- Example: Suppose two groups have implemented caBIO’s Agent class. The Agent class has an attribute called id that represents a database ID
- Agent.id is loaded into the caDSR with the datatype java.lang.String
- This would appear to be interoperable, but it is only truly interoperable if the IDs are consistent between the two sites.
- A better set of value domains would probably be ‘First site database ID’ and ‘Other site database ID’

**Notes:**
Generic Value Domains based on the data types in the model will be used for initial registration.  It is important that the developer make sure that the data types in the model are all represented by generic value domains prior to running the UML Loader – having to remove CDEs, create a Value Domain, and reload is not very efficient.

## Ensuring semantic interoperability

## Ensuring Interoperability in caBIG Part I: Compatibility Guidelines

- Syntactic Integration
- Well described APIs
- Semantic Integration
- Information Models for all Data
- Use of controlled terminologies and ontologies wherever appropriate
- Registered metadata for all information models

**Notes:**
Now that we have a solution, there are several practicalities that need to be dealt with. We ensure semantic interoperability in caBIG by a combination of technology, guidance, and business rules. First, technical requirements and guidance.

**Notes:**
The Guidelines are designed to provide a path to caBIG compatibility from Legacy to Gold, with guidance about the four key principles of caBIG.

## Ensuring Interoperability in caBIGPart II: Cross-cutting workspaces

- Although there are no centralized design to caBIG, there are two cross-cutting workspaces that are designed to assist Grid developers in achieving interoperability.
- The two groups are the Architecture and Vocabularies and Common Data Elements (V/CDE) workspaces
- These two groups define the set of compatibility guidelines, assist developer groups, and verify that systems that wish to attach to the Grid have met the compatibility guidelines

## Ensuring Interoperability in caBIGPart III: Data Standards	

- The V/CDE workspace is responsible for facilitating the development and ratification of Data Standards for caBIG
- Data Standards can be Vocabularies or Common Data Elements (CDEs) with their associated controlled terminology.
- A caBIG Data Standard is, in effect, a ‘pre-approved’ mechanism for semantically modeling an attribute or series of attributes in a data object. Ideally, having a standard available shortens development time for other projects that need to present such data.
- In the last year, the V/CDE workspace has developed a consensus driven mechanism for approving Data Standards and applied it to an increasing number of CDEs

## Data Standards Process

**Proposed**
**Standard**

**Acceptance by **
**V/CDE Workspace**

**Review By **
**V/CDE Committee**

**Standard**

**caBIG-Wide**
**Comment Period**

**Final Approval**
**From V/CDE Workspace**

## Data Standards

- Accepted Standards:
- OMB Specification of Race and Ethnicity Codes (4 CDEs)
- CDC/HL7 Specification of Ethnicity
- Specification of Date and Time (7 CDEs)
- Performance Status Scales (8 CDEs)
- Eastern Cooperative Oncology Group (ECOG) Performance Status Scale
- World Health Organization (WHO) Zubrod Performance Status Scale
- Karnofsky Performance Status Scale
- Lansky Play Performance Status Scale (pediatric)
- The New York Heart Association Classification
- Performance Status Scale for Head and Neck Cancer Patients (PSS-HN) - Normalcy of Diet
- Performance Status Scale for Head and Neck Cancer Patients (PSS-HN) -Understanding of Speech
- Performance Status Scale for Head and Neck Cancer Patients (PSS-HN) -Eating in Public
- Standards in caBIG wide review
- Sex and Gender (3 CDEs)
- Specification of Name
- Standards in Small Group review
- Specification of Role Name
- Specification of Address
- Standards being prepared for submission
- Genomic Identifiers
- Specification of Body Mass Index

**Notes:**
Segue here is that I have described a very complex mechanism for making interoperability work. In practice we would like caBIG adoption to be as uncomplicated as possible. To that end NCICB has implemented the caCORE SDK to assist in creating a software system that meets the ‘Silver’ compliance level in all areas.

## Model Maintenance

**Notes:**
When a model is changed, update of the metadata in the caDSR will be need to be done.  The details of this process are currently underdevelopment.    The caCORE models have been through two updates and are being used as test cases for procedure development.

## Types of Versioning for caDSR Metadata

- _Major_ – Administered Component _needs_ to be versioned to its next whole number.
- _Minor_ – Administered Component _needs_ to be versioned by a tenth of a number.
- _None_ – Administered Component _does not_ need to be versioned.

**Notes:**
As an example, these are the versioning rules for caDSR metadata.  The versioning rules being presented were adopted by the NCICB Context Administrators for the maintenance of Administered Components in the caDSR.  The rules for versioning of models and their components have not been finalized.

## A UML Model should be versioned and reloaded when:

- New Classes and Attributes are added (major version)
- Class relationships are changed (major version)
- Classes are removed (major version)
- New Attributes are added to existing classes (minor version)
- Current Attributes are removed from existing classes (minor version)

**Notes:**
This is the current draft guidance for versioning of UML Metadata.  Further details are to be developed.  There will be only one current version of the metadata with the status of Released.  This doesn’t mean you can not keep using a previous version until the next time you reengineer.-

## Need More Information?

## Training Opportunitieshttp://ncicb.nci.nih.gov/core/caDSR/Training

## Training Content is Role Based

**METADATA CONSUMER/USER** _Application Developer using APIs:_ designs and develops applications, creates data models (in UML), searches for and identifies needed metadata in the caDSR, and utilizes the caCORE APIs. _Metadata Analyst:_ conducts analysis of local metadata needs and submits curation needs to a Metadata Curator. This individual does not perform curation activities. _Protocol Builder:_ utilizes identified metadata to assemble into Forms and Templates within an application. _Formbuilder:_ uses identified metadata to assemble into forms and templates within the Formbuilder tool of caDSR. **METADATA DEVELOPER** _Metadata Curator - using Forms:_ uses caDSR Tools to search for and analyze metadata needs and usage, and to curate caDSR metadata. This individual is also responsible for the maintenance of metadata in the caDSR. _Metadata Curator - using UML Models:_ uses caDSR Tools to search for, analyze metadata needs and usage, and curate caDSR metadata. The primary input format is the UML model, with additional manual curation as required. This individual is also responsible for the maintenance of metadata in the caDSR. **SUBJECT MATTER / PROGRAM EXPERT** _Context Administrator:_ oversees the metadata curation performed by Metadata Curators within a context, functioning as the point of contact (POC) for context-level activities and decisions. _Subject Matter Expert / Content Expert:_ works with Applications Developers and Metadata Curators. The Subject Matter Expert / Content Expert searches for and identifies metadata for potential use, evaluates and compares metadata, and makes recommendations that impact metadata selection and curation. _VCDE Reviewer:_ reviews and analyzes the components and structure of CDEs to formulate recommendations on usage and standard adoption.

## How to Enroll in Training

## Recommended Readings	

- ISO 11179 Part-1, Framework and specifications, Section Appendix A.2, Classifications
- ISO 11179 Part-2, Classification of data elements
- ISO 11179 Part-3, Basic attributes of standardized data elements
- ISO 11179 Part-4, Rules and guidelines for formation of definitions
- ISO 11179 Part-5, Naming and identification principals for data elements
- ISO 11179 Part-6, Registration of data elements
- ISO 20944- Part 2: Metadata registry interoperability and bindings – Part 2: Attribute mapping, Section 4, Identifier mangling conventions
- ISO 20943- Part 1: Metadata registry content consistency – Part 1: Data Elements. Section 6: Bottoms-up approach Section 7: Top-down approach
- ISO 20943- Part 3: Metadata registry content consistency – Part 1: Value Domains
- caDSR documentation and business rules - http://ncicb.nci.nih.gov/core/caDSR

## Demo – Finding MetadataSignup for TrainingcaBIG Information

## Questions?Submit questions and bug reports via NCICB Application Support, ncicb@pop.nci.nih.gov