caBIG Overview

1
caBIG Compatibility Guidelines
Tuesday, May 03, 2005
TBPT Face-to-Face Meeting
2
caBIG Compatibility Guidelines - Purpose

• The purpose of this document is to provide the
  cancer Biomedical Informatics GridTM (caBIGTM)
  community with compatibility guidelines for
  creating software systems that are syntactically
  and semantically interoperable.
• The guidance contained herein is intended to
  support the evaluation of existing systems and to
  inform the designs of new systems. This document
  focuses on issues related to the representation
  of, access to, and exchange
• This document focuses on issues related to the
  representation of, access to, and exchange
  between biomedical informatics resources.
  Requirements for integration and use of the caBIG
  standards management infrastructure
• Requirements for integration and use of the caBIG
  standards management infrastructure are also
  addressed. However, with few exceptions, a
  particular technology implementation of a given
  system or tool is not specified.

3
caBIG Principles and Implications for
Interoperability

• The caBIG program has defined several principles
  that have implications for interoperability and
  for the creation and dissemination of the
  compatibility guidelines themselves
• Open Source/Open Access Products that are funded
  by NCI in connection with the caBIG initiative
  must be made available under licenses that permit
  unrestricted use and redistribution by any party,
  whether commercial, academic, or non-profit.
  Therefore, these compatibility guidelines and any
  resources or specifications related to caBIG
  interoperability standards must also be
  distributed according to these terms.
• Open Development caBIG funded activities must be
  conducted in open forums, with opportunity for
  observation, comment, and contribution by any
  interested member of the community. Therefore,
  the process by which these guidelines and any
  related interoperability standards are created
  must provide for public involvement, comment and
  review.
• Federated The caBIG program envisions a
  federation of cancer biomedical informatics
  resources, not a single repository or hosting
  center. Therefore, these compatibility guidelines
  must be sufficiently rigorous to enable
  developers of independently managed information
  resources and tools to achieve system
  interoperability with systems not under their
  direct control.

4
caBIG Compatibility Guidelines

• How do they differ from caBIG Principles
• The caBIG Principles do not provide the
  guidelines for Applications to become caBIG
  compliant
• The caBIG Principles are the core values of the
  program, and apply to projects which are funded
  by NCICB
• Unfunded or vendor projects can be caBIG
  compliant (by following the Compatibility
  Guidelines) without following all the caBIG
  Principles
• Both are important parts of a functioning,
  community-wide caBIG

5
Levels of Maturity

• The caBIG community has recognized there can be
  differing degrees of interoperability between
  systems, and that these can be qualified in terms
  of maturity level. The caBIG Compatibility
  Guidelines are thus organized into four levels of
  maturity Legacy, Bronze, Silver, and Gold.
• Legacy Implies no interoperability with an
  external system or resource. A system that was
  designed either without awareness or prior to the
  availability of these compatibility guidelines,
  and which does not meet any of the requirements
  for interoperability.
• Bronze Classifies the minimum requirements that
  must be met to achieve a basic degree of
  interoperability.
• Silver A rigorous set of requirements that, when
  met, significantly reduce the barrier to use of a
  resource by a remote party who was not involved
  in the development of that resource.
• Gold Currently being defined by the caBIG
  participants. Is expected to provide for a
  formalized grid architecture and data standards
  that will enable standardized advertising,
  discovery, and use of all federated caBIG
  resources.

6
caBIG Compatibility Guidelines Old-Matrix
7
caBIG Compatibility Guidelines New-Matrix
8
Changes since last version

• Revision 1 of this document included a number of
  example system architecture diagrams that were
  intended to illustrate possible ways to deploy
  caBIG-compatible systems. These diagrams proved
  confusing, and distracted from the main theme of
  syntactic and semantic interoperability, and thus
  have been removed.
• "Interface Integration" has been renamed
  "Programming and Messaging Interfaces" to improve
  the clarity and precision of this label.
• Use of Common Data Elements registered in the
  caDSR is now required for Silver-level
  compatibility.
• Data Elements with sufficient definitional
  information to enable a subject matter expert to
  unambiguously interpret the the contents of the
  resource are now required for Bronze-level
  compatibility.
• Explanatory information has been revised and
  reorganized according to the four areas of
  compatibility rather than by Bronze-Silver-Gold
  classification.
• Initial features of the anticipated grid
  service-oriented Gold-level architecture are
  described.

9
caBIG Architecture Workspace caGrid Phase II
Tuesday, May 03, 2005
10
caGrid Phase II - Time Line
11
Reference Implementation Projects

• Several applications will be implemented as
  reference implementations using the caGrid
  architecture
• caBIO 3.0
• caArray at NCICB and at Georgetown
• rProteomics
• caTIES ltltltltltltltltltltltltltltltlt TBPT
• PIR
• The caGrid team will work with the developers of
  these applications
• to ensure any extensions and modifications to the
  applications are compliant with caGrid
  infrastructure
• to guide the application developers through the
  process of advertising their data sources and
  analytical services.

12
Deliverables

• Requirements and Use case analysis document.
• Architecture
• Design documentation.
• Grid infrastructure GT3, OGSA-DAI 5 Implement
  Advertisement, Discovery, Query, Invocation and
  security as described in use case prioritization
• Service description and semantics caDSR and EVS
  as caGrid components, Mobius to support schema
  management.
• Process for virtualizing services.
• Outline and document the process to set up a
  service and advertise it in caBIG.
• Test-bed caBIG grid infrastructure.
• Implement 3 data services and 2 analytical
  services to test the grid infrastructure
• Set up a multi-site testbed for development,
  deployment, and debugging of the infrastructure.
• This test bed will include machines at NCICB,
  OSU, Panther Informatics, and machines at
  institutions (e.g., Georgetown, Duke) doing
  reference implementation applications.
• Implement a testing plan.
• Middleware API and GUI.
• Web interface to use the grid and API to build
  applications
• caBIG reference implementations.
• Prototype application implementations on caGrid
• Testing.

13
Iteration I

• Core Infrastructure and Business Process
• Installed GT3.2, OGSA-DAI 5.0 in NCICB, Panthers
  and OSU, tested interoperability among sites.
• Implemented the basic functionality for
  advertisement, discovery, query and invocation.
• Minor toolkit extensions.
• Hardcoded in some areas Create manually the
  local caDSR instance.
• Design
• Identify the extensions, Design the extensions in
  the Client and Service sides.
• Design caGrid installation component.
• Portal/GUI/API
• Extend GT3.2 and OGSA-DAI client API to support
  advertisement, discovery, query and invocation.
• Design Portal, Design GUI (Mock up), implement
  basic functionality.
• Test and Documentation
• Test the process implemented.
• caGrid installation Documentation.

14
Iteration I cont.

• Advertisement, Discovery, Schema Management
• Design and implement metadata for Data and
  Analytical tools services.
• Evaluate GME as schema management component.
• caDSR / EVS design for integration
  (advertisement, discovery, query) in caGrid
  framework.
• Isolated testing of Globus Index services.
• Implement caCORE SDK for data source service
  advertisement.
• Security
• Authentication (Globus GSI, different CAs)
• Authorization (Globus GSI, OGSA-DAI, Common
  Authorization Services).
• Isolated testing.
• Invocation
• Support for installation and creation of services
  (GT3 core).
• Isolated testing of GRAM/Index Services.
• Query
• Query single data source.

15
Iteration II

• Core Infrastructure and Business Process
• Full caGrid Phase II business process
  implementation (advertisement, discovery, query,
  invocation).
• Implement caGrid installation.
• Design
• Design semantic grid services.
• Portal/GUI/API
• Complete implementation of GUI
• Test and Documentation
• Test the process implemented.
• Documentation of completed components and the
  process implemented.

16
Iteration II cont.

• Advertisement, Discovery, Schema Management
• Integrate GME in caGrid framework.
• Integrate Index services in the framework.
• Test caCORE SDK with reference implementations.
• Security
• Integrate GSI services in caGrid framework.
• Test myProxy, Permis, Virtual organizations.
• Invocation
• Integrate GRAM in the caGrid framework
• Query
• Integrate single and multiple source query
  implementation in the framework
• Preliminary testing for federation.

17
Iteration III

• Core Infrastructure and Business Process
• Implement Semantic proof-of-concept grid
  services.
• Service metadata definitions in RDF schemas, OWL
  ontologies.
• Portal/GUI/API
• Complete implementation of Portal
• Test and Documentation
• Update caGrid system architecture document.
• Document process to advertise caGrid services.
• Document installation process.
• Test the process implemented adding new data /
  application resources.
• Fix bugs
• Advertisement, Discovery, Schema Management
• Advertisement, Discovery for semantic services
• Test caCORE SDK with reference implementations.
• Security
• Integrate MyProxy, CAS, Permis in caGrid

18
Beyond this phase

• Refactoring for production level deployment.
• Implementation of a test suite.
• Federated query implementation
• Evaluation and migration to GT4
• Support for distributed semantic queries
• Ontology-based data integration
• Implementation of basic reasoning-enabled query
  capability
• Enhanced support for security and access control
• Distributed/organizational attribute management
• Distributed, hierarchical credential management
• Fine grain access control.
• Workflow support
• Creation and execution of data analysis workflows
• Additional applications.
• Full deployment process.
• Blue print for porting of applications, tools,
  and data sources to caGrid.

19
caBIG Architecture Workspace Regulated
Information Exchange SIG
Tuesday, May 03, 2005
20
Outline

• Introduction / Mission Statement
• Infrastructure to Support Regulated Information
  Exchange and Management
• Next Steps
• Contact Info

21
Regulated Information Support SIG Goals

• The Regulated Information Exchange SIG will
• Explicitly address issues associated with the
  exchange and retention of information that falls
  under one or more federal regulations.
• Provide recommendations regarding the
  infrastructure required to support the exchange
  of regulated data , with an initial focus on
  elements regulated under Title 21 CFR Part 11 and
  HIPAA. Some of the topics to be addressed
  include how those data elements can be exchanged
  (either within an institution or between
  institutions), requirements with respect to data
  retention and data distribution policies, and how
  these policies may be impacted by
  inter-institutional agreements, and in turn what
  infrastructure is necessary to support these
  requirements.

22
Regulated Information Exchange SIG
Responsibilities

• Requirements gathering session
• In Conjunction with
• TBPT Workspace
• CTMS Workspace
• Lab Interfaces SIG
• CTMS/CDUS Reporting SIG
• Use the Recommendations White Paper
• Financial Billing SIG
• Adverse Events SIG
• NCI-FDA Inter-Agency Operational Task Force
  (IOTF)
• CRIX (Private-Public Collaboration)
• DSIC working group
• Evaluation/survey of technologies / current
  solutions
• Mapping the requirements to the technologies
• Recommend an infrastructure to handle the
  exchange and management of regulated information

23
Key Requirements for Infrastructure

• All applicable patient privacy and security
  regulations and policies including, but not
  limited to, HIPAA
• All applicable regulations with regard to
  handling and management of clinical, protocol and
  other data submitted to the FDA including, but
  not limited to, CFR 21 Part 11
• All additional requirements for protection of
  Intellectual Capital, as identified by the Data
  Sharing and Intellectual Capital (DSIC) of caBIG

24
Next Steps

• Identify priorities and initial focus for SIG
• Gather requirements
• Research the available set of tools/technologies
• Identify a prototypical application
• Self Subscribe to the Listserv
• cabig_arch_rie-l

25
Contacts

• Arch. WS - Regulated Information Exchange SIG
• NCICB Arch. WS Facilitator Shanbhag Krishnakant
  (Avinash)
• Regulated Information Exchange SIG Lead Warren
  Kibbe
• NCICB Regulated Information Exchange SIG
  Facilitator Christo Andonyadis
• caBIG Arch. WS Lead Arumani Manisundaram

26
Infrastructure to Support Regulated Information
Exchange and Management

• Example ebXML integration hub within walls of
  site with very secure transmission of
  de-identified data between sites

27
CTMS-Lab System ebXML Messaging Service Components
4
Application Handler
CTMS System
Messages
Database
1
3
ebMS Server (Messaging Server)
Proxy Submission Service Provider
Content Validation
2
CPA Validation
Audit
CPA instances
CPA management Web Forms
ebXML Registry Server
Lab System
28
Step 1

• Step1 Sender uses the Messaging Server stub or a
  lightweight client to connect to its own ebMS
  Server and instructs it to deliver the message to
  the specified recipient.
• The lightweight client essentially registers some
  key information (source party Id, destination
  party Id, destination URL, message Type, action
  etc.) with the ebMS server before it starts
  sending messages.
• The lightweight client typically polls the ebXML
  Messaging server for incoming messages or
  responses from the recipient.

29
Step 2

• Step 2 Recipient ebMS Server receives the ebXML
  message (delivered via HTTP or SMTP). The
  Messaging server then contacts the Registry
  server and validates the incoming message against
  the CPA (Collaboration Protocol Agreement)
  established between the two parties.
• The CPA validates the agreement between the two
  involved parties and ensures the parties are
  allowed to act on the action specified in the
  message.
• The CPA also mandates what confirmation messages
  can be sent back to the sender.

30
Step 3

• Step 3 Once the CPA is validated, the recipient
  messaging server utilizes JCAM (Java Content
  Assembly Mechanism) to validate the massage
  against basic business rules (as an example, if
  the actionbuy, sender must specify a valid
  price which is a number greater than zero. )
• If an error is detected in step 3 or 4, the
  recipient messaging server sends back an error
  message to the sender messaging server. The
  sender ebMS will queue the message until the
  client picks it up and processes it.

31
Step 4

• Step 4 The validated message at this point is
  converted to a standard SOAP message and passed
  back to the target application. A plug-in module
  is implemented to work as the glue between the
  backend system and the ebMS server.

32
QA