# Presentation: 210246

## Annotation Engine

- John Gilbertson
- Rajnish Gupta
- Yimin Nie
- The University of Pittsburgh

## Today’s Presentation

- What is Clinical Annotation?
- Viewpoint, Goals and Visions
- The Technical Challenge
- The Proposed Plan
- Standards Based Data Mapping
- Chronology, Identification & Security
- Caveats and Risks
- Time Frame
- Summary
- Discussion

- Examples and Use Cases...:

## Clinical Annotation

## Clinical Annotation

- Clinical information - of interest to tissue banks and their clients – that is not generated by the tissue bank
- It is generated in over long periods of time in multiple clinical systems as part of the clinical process
- The representation of annotation is often modified by the bank
- Clinical annotation is difficult and expensive for tissue banks to collect and maintain

- Request for samples of high grade, organ confined prostatic adenocarcinoma primaries from patients less than 60 years old at diagnosis and no hormonal therapy prior to resection. Five year follow up with no chemical or anatomic recurrences.

**Time**

**Biopsy**

**Biopsy (DX)**

**Tumor Marker**

**Resection (GX****)**

**Biopsy (?)**

**Tumor Marker**

**Tumor Marker**

**Tumor Marker**

**EMR Extract**

**Follow up**

**Follow up**

**Pathology         Laboratory          Registry**

## Clinical Annotation

- Clinical data is not generated for tissue banks
- Source systems have different data models, representations, workflows and timeframes
- Different clients have different data needs and models

- Person

- Surgical
- Accessions

- Specimens
- (“parts”)

- Samples

- Cancer
- Patient

- Cancer
- Patient

- Primary
- Tumor

- Grade
- Stage

- Progression

- Outcomes

- Primary
- Tumor

- Grade
- Stage

- Progression

- Outcomes

**Pathology LIS Data Model**

**Registry / SPORE Data Model**

## Clinical Annotation is a Problem

- Clinical annotation is difficult and expensive for tissue banks to collect and maintain
- Tissue banks & users require and maintain different representations of the same data - resulting in a major impediment to sharing tissue resources
- Infernal triangle of (multiple, independent) source systems, tissue banks and user communities – each with their own data representations

- Identified and De-identified Representations of a data set
- How does one identify a patient across the triangle?
- PCABC, CPCTR, CAP, EDRN and SPORE have different “CDEs” for the same concept
- Consider the “contexts” in the caDSR implementation of ISO 11179

- The infernal triangle
- Sources                  Users
-   Banks

## Viewpoint, Goals and Visions

## Viewpoint

- I am not a tissue banker

## Viewpoint

- Enterprise informatics infrastructure
- An environment of:
- Multiple information systems and research data sets
- Multiple tissue collections and banks
- Multiple research projects and user communities
- Our viewpoint is looking into and across tissue banks

- How many cases of high grade lung adenocarinoma have we had at UPMC?
- Of those, how many samples of the primary tumor do we have?
- Of those how many do we have frozen tissue and two year follow up?
- Of those, how many do  we have metastatic tissue on?

- Each environment has its own “point of view”
- (its own metadata!)

- “Strategic” Director/PI
- level questions

## Structural Problems

- Tissue banks exist outside of the informatics infrastructure of medical centers – Tissue banks are not connected (effectively) to clinical sources
- There are multiple, independent tissue banks in each medical center. Each with a different representation of clinical data and with no mechanism to effectively “look across” all banks.
- There are multiple, independent research projects and user communities each requesting/mandating one or more representations of clinical annotation data
- There are others...

- Manual re-entry of clinical data into tissue bank systems...
- A single patient/specimen may be present in more that one tissue collection – how does one generate a tissue inventory on a patient?
- How does one present prostate data to CPCTR and EDRN?

## Primary Goals

**Make the core informatics and operational infrastructure of medical centers** (data from the core clinical systems) **more directly** **available to tissue banks** [This is the Annotation Service Model] In other words: tie the core clinical informatics systems of the medical center to the medical center’s tissue bank infrastructure
**Make tissue banks at an institution directly available to each other through a common clinical representation.** [This is the Enterprise Tissue Resource Model]. In other words, tie disparate tissue collections in a medical center together in a common view of tissue resources
**Allow tissue banks** (and other collections of clinical data) **to serve multiple user communities by presenting data in multiple representations.** In other words,** **allow tissue banks to support multiple user communities more directly by “speaking” multiple languages.** **

- 1)

## AP LIS

- CP LIS

- Registry

- CTMS

- Common
- Clinical
- Representation

- Tissue
- Bank

**Annotation Service Model**

## Secondary (Implied) Goals

**Integrate data between internal systems**
**Tie “internal” clinical systems or data sets to external collaborations such as caGRID**
**Provide**** large ****amounts of computable clinical data to the caGRID**
- Implications of the work go far beyond Tissue Banking

- 1) The SPIN project (TIES) is example of a project that externalizes a large of “computable” data from a large, ubiquitous clinical system (and has implications well beyond tissue banking)

- Workspace

- caGRID

- EDRN

- CPCTR

- Firewall

- GRID

- WEB

- AP LIS

- CP LIS

- Registry

- EMR

- Medical Center

- Identification

- De-Identification

## The Technical Challenge

## The Technical Challenge

- Multiple, Independent Data Sources that we don’t control with different vocabularies, DE, models, access, messaging, identifiers
- Manage Identification
- Discrepant and Redundant Data
- Operational Chronology
- Versioning
- Integrate and Transform the source data to a canonical model(s)
- Continued...

- For example, the Cancer Registry & the AP LIS have very different data models
- An example of chronology...
- Sources systems may not be able to fill the canonical model
- Canonical Model is “independent” for the source models

- AP LIS

- CP LIS

- Registry

- CTMA

- Archive

- Engine

- Canonical Representation

## The Technical Challenge

- Integrate and Transform the source data to a canonical model(s)
- Map the data to multiple, independent data targets with different Vocabularies, DE, Models, Access, Messaging, Identifiers
- Manage Identification
- Discrepant and Redundant Data
- De-identification
- Versioning

- 1) CPCTR or PCABC Identifiers – When one is passing de-ID data to another systems one needs to keep track of the ID keys in the target system

- AP LIS

- CP LIS

- Registry

- CTMA

- Archive

- Engine

- Canonical Representation

- CPCTR

- Public

- De-ID

- ID

- Prostate SPORE

- Stats

- De-ID

- ID

## The Technical Challenge

- We have to handle (register) multiple metadata representations (both DE and Models) and handle (register and implement) transformations between these representations – on both a logical and application (physical) level
- We should do this in a standards based way! There needs to be a clear, unambiguous way of adding new sources or targets

- The number of data sources will inevitably increase, both new versions of core systems (i.e. AP LIS) and totally new systems (imaging, epidemiology, etc.)
- Different versions of target will also evolve (The CPCTR has three different output representations (public - general stats, de-id records, & honest broker)

- AP LIS

- CP LIS

- Registry

- CTMA

- Archive

- Engine

- CPCTR

- Public

- De-ID

- ID

- Prostate SPORE

- Stats

- De-ID

- ID

- Representations

- Transformations

- External Bindings

- External Bindings

## The Proposed Plan

## The Plan

**Choose a core (extensible) set of clinical systems**, ideally ubiquitous, useful and supporting standard data elements – Registry, AP LIS, CP LIS (CTMA, TISSUE BANK, etc). We like the Registry, AP LIS and CP LIS because they have national data standards that have been accepted by the clinical (source) community.
- Develop “**Data conveyers**” for these “source” systems that can be used to take data from any source implementation and convey it into the mapping engine’s cache.
- In the Mapping Engine:
**Register the Source Metadata** – Elements, Models and Messaging Representations (logical and physical views)
**Register Target Metadata** – Elements, Model and representations (logical and physical)
**Define and Register Mappings**
**Load Source Data**, Aggregate and Compress by Patient/Specimen, QA
**Implement the Mappings**
**Publish Data** with Mapped (Target) Metadata to data servers

- 1)

## AP LIS

- Registry

- CP LIS

- TIES

- CTMA

- Cache

- caTISSUE
- Inventory Module

- Head & Neck
- Tissue Bank

- HS TB
- Tissue Bank

- Source Data Objects

- Transformations (ISO 19763?)

- caDRS

- Canonical
- Metadata

- Download

- Download

- Tissue
- Bank
- Presentation

- Q/A Data
- Presentation

- SPORE
- Presentation

- Enterprise
- Presentation
- Tissue Res.

- CaBIG
- Presentation

- API or Reports

- XML

- Published De-identified Data

- caBIG
- GRID

- API/XML

- Published Data

- API/XML

- Data Dictionaries

- Tissue Bank
- Applications

- Source
- Applications

- Consent
- Data

- Consent
- Data

- Information Carriers &
- Conveyers

- Mapped Data Objects

- Metadata
- Dictionary

- Institutional Firewall

- Aggregate/Compress by Patient

- Source &
- Target
- Metadata

- Logical
- Mappings
- ISO 11179

- Physical
- Mappings
- ISO 20944?

- Logical
- Mappings
- ISO 11179

- Physical
- Mappings
- ISO 20944?

##  Standards Based Mapping Application

## ISO 11179 & Mapping Engines

- 11179 is a standard for a machine readable metadata repository. A standard for defining, registering and classifying meta-data
- caDSR is a implementation of 11179 for managing Data Elements
- Data mapping is a process through which data is passed between two sets of (registered) metadata

- The mapping engine must have be able to register metadata (from the source and target systems)
- The mapping engine must interact productively with the caDSR

- AP LIS

- CP LIS

- Registry

- CTMA

- Archive

- Engine

- CPCTR

- Public

- De-ID

- ID

- Prostate SPORE

- Stats

- De-ID

- ID

- Representations

- Transformations

- External Bindings

- External Bindings

## Slide 23

## ISO 11179 & Mapping Engines

- 11179 is a standard for a machine readable metadata repository. A standard for defining, registering and classifying meta-data
- caDSR is a implementation of 11179 for managing Data Elements
- Data mapping is a process through which data is passed between two sets of (registered) metadata

- The mapping engine must have be able to register metadata (from the source and target systems)
- The mapping engine must interact productively with the caDSR

- AP LIS

- CP LIS

- Registry

- CTMA

- Archive

- Engine

- CPCTR

- Public

- De-ID

- ID

- Prostate SPORE

- Stats

- De-ID

- ID

- Source context
- CPCTR context
- SPORE context

- Transformations

- External Bindings

- External Bindings

- Representations

## Context One

**Context One**

**Context Two**

**Transformation**

- The transformation (mapping) is part of the metadata
- The transformation may be complex (may be a class or a service)

## Limitations of ISO 11179 (for data mapping applications)

- Support for data models and complex transformations (mappings)
- One can extend the caDSR implementation with a set of tables, using recursive structures or by “using” classification schemes...
- ISO 19763 – a data transformation standard in development (working draft) designed to work with 11179

**The transformations (programs) are metadata!**
- Convert “date of first recurrence” to “months from diagnosis”
- Create “tumor marker history” as “Marker, Value, Months from Diagnosis” ordered by increasing “Months from Diagnosis”
**HL-7 (v3)**

- metaModel:
- MM1

- metaModel
- Transformation
- Definition

- MetaModel:
- MM2

- source

- target

- Model:
- M1

- Model
- Transformation
- Definition

- Model:
- M2

- Value:
- V1

- Value
- Transformation
- Definition

- Value:
- V2

- source

- target

- source

- target

- governing

- governing

- governing

- governing

## In 19763, models and transformations are handled within the structure of 11179

**Main Part of the ****11179**** MDR Metamodel**

**Main Part of the ****19763**** Generic Model Registry**

## Limitations of ISO 11179 (for data mapping applications)

- Bindings to physical data streams, services, API, etc.
- As a logical repository, ISO 11179 does not have to handle external bindings formally, but a mapping application does
- One can “extend” ISO 11197, but there is ISO 20944...

- What does the system expect from the input systems?
- What does the system have to write (and where) for the target services?

- Data
- Source or
- Service

- Mapping
- Application

- Data
- Target or
- Service

## Limitations of ISO 11179 (for data mapping applications)

- ISO 20944 is a proposed standard for a “generic data server” designed to work with ISO 11179 and support external bindings to sources and services
- There are other standards being proposed. NCI may be already working on some of them.

- Check out www.metadata-standards.org

- AP LIS

- CP LIS

- Registry

- CTMA

- Archive

- Engine

- CPCTR

- Public

- De-ID

- ID

- Prostate SPORE

- Stats

- De-ID

- ID

- 11179 DE
- 19763 Models

- Transformations
- (19763)

- External Bindings (20944)

- External Bindings (20944)

- Classes/Services
- (20944)

## ISO/IEC 11179

- Metadata Server
- Standard, Machine Readable
- Registry

- ISO/IEC 20944
- Generic Data Application
- Connects the metadata model
- To the “real world” data

- Application Gets/Uses
- Metadata

- Data Representation (source)

- Data Source Metadata
- Registered in Registry
- (Source Context)

- Using metadata
- Aids Data Exchange

- Figure 2: Relationship between ISO 11179,
- ISO 20944 and Data Sources in Data Mapping
- Application – after F. Farance, 2003

## ISO 20944

- Interoperability
- & Bindings
- “Generic
- Application
- Server”

- Internal and External
- Services
- JDBC
- ODBC
- HL-7

- Relationship between ISO 11179, ISO 19763 and ISO 20944

- ISO 19763
- Meta-model
- Inter-operability

##  Chronology, Identification & Security

##  Caveats & Risks

## Risks

- The project represents a very non-traditional way of handling clinical annotation in tissue banks.
- Continued...

*However, this project is envisioned as an extension to existing annotation in a tissue bank*

## Risks

- The project represents a very non-traditional way of handling clinical annotation in tissue banks.
- Standards based systems tend to have a longer development time, especially if the standards are evolving (they are) and the development team is not familiar with them (they aren’t).
- Continued...

*However, standards save money and time over the long haul...*

## Risks

- The project represents a very non-traditional way of handling clinical annotation in tissue banks.
- Standards based systems tend to have a longer development time, especially if the standards are evolving (they are) and the development team is not familiar with them (we aren’t).
- I will be leaving the University of Pittsburgh soon.

*“**The churchyards are full of indispensable men...” *
*caBIG will not succeed without multiple developers, far more than there are today.*

## Time Frame

## Timeline of Strategic Goals:

**Timeline of Strategic Goals:**
**Tissue Bank and Pathology Tools**

- Complete first iteration of caTISSUE Core / caTISSUE Lite and deploy to adopter sites for testing.
- Complete caTIES module and deploy to adopter sites for testing.
- • Complete first phase of  caTISSUE clinical annotation module and deploy to adopter sites for testing

***  ******1 – End of 2005 ***

***Strategic Goals***
***   ******by Year:***

***  ******3 – Summer 2008***

***  ******5 – Summer 2010 ***

- • Complete development cycle for caTISSUE Lite / caTISSUE Core
- • Complete & deploy presentation  / grid layer for caTISSUE
- • Further development of clinical  annotation module.
- • ‘Second party’ modules for  Billing/Shipping, Request,  Experimental annotation
- • Other caTISSUE modules  based on prioritization ranking.
- • Explore integration of caTISSUE  with other specimen banks  (e.g. EDRN, coop group, CHTN).

-  Execute test cases to  demonstrate utility of grid-  based query across centers,  and sharing of biospecimen  resources for novel   multi-institutional studies.

## Time Frame (Six Months)

- Two time frames
- Metadata Model: Define the canonical data model, data elements and recommended mappings (transformations)
- Pilot Mapping Application that:
- implements the ISO standards as “models” [developer’s application]
- allows registration of source, canonical and target models, bindings & transformations

- Pilot will be in Oracle (XML schema). Outputs will be in XML
- 4-6 months of development, then one month per source
- Need to define the nature of the “six month” prototype from NCI’s point of view

- NCI Tech Standards

- Data
-  Conveyers

- Mapping
- Application

- Synch
- W/ DSR

- Sync
- W Grid App.

##  Summary

## Summary

- Annotation is expensive and hard
- Tissue banks are not well connected to the informatics infrastructure
- A small group of clinical systems can provide a core set of annotations
- There are multiple tissue banks and user communities in a cancer center
- We need a multiple to multiple mapping
- DE, Models, Transformations, External Bindings
- Sources to Targets
- Different requirements within a target (de-id, limited data set, etc.)
- These issues go well beyond tissue banking
- A standards based approach would be the best (this is caBIG)
- ISO 11179 is a possible starting point – need guidance from NCI
- There are significant risks

## Discussion