1. Supporting interoperability by leveraging message systems in health informatics environments
Public Health Information Network
Annual Meeting Atlanta, GA
R. Mark Adams, Ph.D.
NCI caBIG Program Manager
Booz Allen Hamilton

2. Goal and Agenda
Training Overview:
The caBIG project has developed a range of scenarios which can provide Grid interoperability for legacy applications. We will go through an example of one such application, and the open source tools used in the process.
Agenda:
caGrid as a data exchange infrastructure
Some approaches to Adaptation of legacy systems
An example of Adapting a system to Grid compatibility
Resources

3. What is caBIG?
Common, distributed infrastructure that permits the research community to focus on innovation
Shared, harmonized set of terminology, data elements, and data models that facilitate information exchange
Collection of interoperable applications developed to common standards
Cancer research data available for mining and integration 3

4. What is caGrid?
A grid based software infrastructure consisting of services, toolkits, APIs, and applications
A production grid deployment of the core services provided by that infrastructure
A community of developers leveraging that grid and infrastructure to provide applications and services to the cancer research community
caGrid (or the “Grid”) provides the core infrastructure and tooling needed to connect to the Grid in a distributed manner - this is the ultimate target of the compatibility process.

5. Getting on the Grid
“Getting something on the Grid” – or “establishing a Grid node” - means meeting requirements for interoperability (through adoption or adaptation), and then connecting that interoperable data or analytical service to the production Grid.
Grid services are “advertised” through an index service, which is part of the production grid infrastructure. You can also connect to the index service to “discover” services provided by others.

6. History of caGrid Developed as the Grid toolkit for caBIG, 2004
caGrid 1.0 was a revolutionary release of the caGrid infrastructure, replacing the 0.5.x test bed stream
The last stable release of caGrid was version 1.2, released mid March 2008 6

7. caGrid Production Environment
Ultimately, the Grid consists of a collection of applications and services, connected to each other through a secure infrastructure
Source: 7

8. caGrid Community Involvement
caGrid itself provides no real “data” or “analysis” to caBIG™; it is the enabling infrastructure which allows the community to do so
Community members add value to the grid as applications, services, and processes (for example: shared workflows)
caGrid provides the necessary core services, APIs, and tooling
The real value of the grid comes from bringing this information to the end user
Community members develop end user applications which consume of the resources provided by the grid 8

9. Design Pattern Overview
The following slides outline SIX different approaches for adapting a tool to be caBIG™-compatible. These are conceptual models – foundational strategies - for shaping an adaptation roadmap. This is neither an exhaustive nor mandated list – they are simply examples that we believe can facilitate adaptation based on experience to date.
Understanding Design Patterns
The six approaches offered here are based in the concept of design patterns, which Wikipedia defines as “a general reusable solution to a commonly occurring problem in software design.”
Design patterns are essentially templates: standardized conceptual solutions that can be applied to many different situations. Based on caBIG™ experiences, there have been six standard ways to approach the software design problems presented by the adapt path identified. These are presented in the following slides.

10. Some Design Patterns for providing caGrid Interoperability for Legacy Applications
1: Wrapper
2: Direct Data Access
3: Message Broker
Existing Tool
Database
API
caBIG™ Compatible API UI
caGrid
Existing Tools
Database
API UI
caBIG™ Tool
caGrid
Message broker hub
(caXchange)
Existing Tool
Database
API UI
caBIG™ Tool
caGrid Or
4: Data Warehouse
5: Clone and Own
6: Generate an API
Existing Tool
Database
API UI
caBIG™ Tool
caGrid
ETL Script
Warehouse
SQL Script
Existing Tool
Database
caBIG™ API
caGrid UI
Existing Tool
Database
API
caGrid UI

11. Some Assumptions
The deploying institution has a need to share data related to a clinical trial with appropriately authorized collaborators, and has chosed the caGrid as the means to do so.
The data resides within clinical systems that are not readily available for direct access to the database and do not expose usable or accessible APIs.
The Institution deploying this adaptation strategy has the ability to generate either HL7v2.x messages or *.csv- formatted reports containing the information of interest.
The CTODS has data elements that correspond to the elements that will be shared
The deploying institution has either staff or contractors who understand the data elements to be shared well enough to map them to the appropriate HL7v3 format

12. Design Patterns Translated into Practice
caGrid
caBIG™ Tool
Existing Tools
API
API
API
Database
Database
Database UI UI UI
In order to accommodate the capabilities, limitations and needs of a given site, each implementation will necessarily differ
As an illustration of what is possible with the caBIG™ tools to facilitate getting clinical data on the caGrid, we will examine the development of an implementation based on Design Pattern #3, “Message Broker”
Message broker hub
(caXchange)

13. 3: Message Broker
Use Scenario: The existing tool already uses standardized messages, such as HL7, to facilitate dynamic information exchange between diverse tools.
Description: A “messaging hub,” such as caXchange, brokers the transfer of messages from the existing tools, and feeds into a caBIG™ tool, then out to the Grid. This same concept can be used with other file formats like CSV or tab-delimited ASCII. caAdapter facilitates the mapping into caBIG™ standard elements.
If tools already send messages (e.g., HL7), this may be the most effective way to transmit data from existing tools to caBIG™ grid.
caGrid
caBIG™ Tool
Existing Tools
API
API
API
Database
Database
Database UI UI UI
Message broker hub
(caXchange) 13

14. Cancer Center Hub Client
Component Details
The proposed solution makes use of several components:
CTODS
Viewer
CTODs
Database
API UI
A local caGrid Installation
caGrid
Viewer UI for examining CTODS Data
An HL7v2.x
Or *.csv format
Message/file
Contains the data to be shared
CTODS
Database
CTODS Persistence
Grid Service
CTODS
Grid Service
GUI for mapping data elements
caAdapter
Message Processor
Grid Service
Message transfer agent
caXchange Request
Processor
Cancer Center Hub Client

15. How Everything Fits Together
Clinical Data
System
A Subject Matter Expert maps the data elements between messages
Mapping file
to HL7v3
An HL7v2.x
Or *.csv format
Message/file
caAdapter
Either a HL7v2.x message is identified
or *.csv report generated with the data
elements of interest. The data elements from this can be extracted and mapped to those used in CTODS with the help of a GUI tool for that purpose, caAdapter.

16. caAdapter in Action

17. How Everything Fits Together
Clinical Data
System
CCHC transforms the data using caAdapter APIs and submits it to the grid
An HL7v2.x
Or *.csv format
Message/file
Generated on- demand, or automatically via triggers or a batch process
Cancer Center Hub Client
Mapping File
to HL7v3
HL7v3
Message
When the Clinical Data System emits a message, the Cancer Center Hub Client
(CCHC) uses the Mapping File to map the data into an HL7v3 message

18. CCHC in Action

19. How Everything Fits Together
Automatically manages appropriate messages or files that appear
This service receives the messages from the grid, and adds the data to the CTODS database
HL7v3
Message
CTODS Persistence
Grid Service
caXchange Request
Processor
caGrid
CTODS
Database
API UI
CTODS
Viewer
The HL7v3 message is then submitted to the caXchange Request Processor, that then routes the message via caGrid to the designated CTODS Persistence Grid Service, which then adds the data to the CTODS database for subsequent query, viewing and analysis
The data can then be queried and viewed by the user

20. CTODS Lab Viewer in Action

21. What is Needed?
The software components described. All are Open Source and freely available.
The ability to configure and deploy the tools
Cooperation with and access to the data management resources, so the required data reports/messaged can be used
Expert mapping of the data elements from the message/report to those used by caBIG/CTODS (HL7v3). This is potentially the most challenging part.
If the messages being mapped correspond to those already in the tools, this is sufficient, but the tools may need some additional configuration/modification
An operational and configured caGrid node

22. Acknowledgements John Speakman (NCI) Christo Andonyadis (NCI)
Derek Walker (Booz Allen)
Beth DiGuilian (Booz Allen)
Malcom James (Sapient)
Sichen Liu (NCI)
Anand Basu(NCI)
Charles Yaghmour(ScenPro)
Eugene Wang(NCI)
Denise Warzel(NCI)
Michael Holck (ScenPro)
Jennifer Brush(ScenPro)
Kalpesh Patel(Ekagra)
Peter Yan (SAIC)
Jennifer Thomas(SAIC)
…And many others!

23. Project Resources & Communication
caGrid Community Wiki
Download Software
Documentation
Tutorials
Technical Paper and Presentations
FAQs
caGrid GForge Home (project website)
Feature Requests
Bug Reports
Downloads / Source Repository
caGrid Users Mailing List
caGrid Portal (web portal) 23

24. Where to go next Reference Link CTODS
caXchange
HL7 / BRIDG Information
caCORE Software Development Kit (SDK)
caDSR Tooling (Semantic Integration Workbench, CDE Browser, UML Model Browser)
caCORE Curriculum

25. Questions?