cabig clinical information suite project overview n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
caBIG® Clinical Information Suite Project Overview PowerPoint Presentation
Download Presentation
caBIG® Clinical Information Suite Project Overview

Loading in 2 Seconds...

play fullscreen
1 / 114

caBIG® Clinical Information Suite Project Overview - PowerPoint PPT Presentation


  • 156 Views
  • Uploaded on

caBIG® Clinical Information Suite Project Overview . Varian Medical Systems Meeting February 9-10, 2011. caBIG® Clinical Information Suite. Introductions & Meeting Objectives Presenter: Corinne Blair. Agenda. Participant Introductions caBIG® Clinical Information Suite (caCIS) Team

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'caBIG® Clinical Information Suite Project Overview' - nyoko


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
cabig clinical information suite project overview

caBIG® Clinical Information Suite Project Overview

Varian Medical Systems Meeting

February 9-10, 2011

agenda
Agenda
  • Participant Introductions
    • caBIG® Clinical Information Suite (caCIS) Team
    • Varian Team
  • Meeting Purpose & Objectives
  • caBIG® caCIS Project
    • Project Overview
    • Business Capability Overview
    • Technical Overview
    • Integration Strategy Overview
  • End of day recap, action items or discussion
cabig clinical information suite team
caBIG® Clinical Information Suite Team
  • NCI Representative – John Speakman

Associate Director for Clinical Products and Programs, Center for Biomedical Informatics and Information Technology, National Cancer Institute

  • SAIC-F Contracting Officer Technical Rep – Nancy Roche
  • caCIS Chief and Lead Architects – John Koisch and Paul Boyes
  • caCIS Analysis Lead – Marti Velezis
  • caCIS Deployment Lead – Phil Gelda
  • caCIS Stakeholder Manager – Corinne Blair
meeting purpose objectives
Meeting Purpose & Objectives

Open dialog and engagement with software vendors in the oncology market space is a key part of our project’s mission …

  • Our NCCCP partners and the broader Cancer Care Community are supported by a large vendor community
  • We are striving to assist the Cancer Care Community in providing more highly focused care to cancer patients through IT enabled translational medicine
  • NCI is not a software vendor and can only succeed in this mission when vendors adopt and/or interoperate with caBIG® specifications and solution components
meeting purpose objectives1
Meeting Purpose & Objectives

Ideal targeted outcomes from this meeting and any follow-up dialog include …

  • Near term
    • Clear feedback regarding the this project and the deliverables it is targeted to produce
    • Establishment of a collaborative relationship to help support our shared NCCCP stakeholders
  • Medium to Longer Term
    • Progressive incorporation of caBIG® caCIS based specifications and standards / capabilities into the applicable product life-cycles
meeting purpose objectives2
Meeting Purpose & Objectives

Proposed objectives for this meeting …

  • Provision of Context
    • Overview of the caCIS project goals, benefits, business capabilities and caCIS technical architecture and specifications
  • Getting to Specifics
    • Provision of specific details about selected capabilities to stimulate meaningful dialog
  • Open Discussion
    • Enabling an interactive and open dialogue to validate assumptions and seek feedback
building a smarter health system
Building a Smarter Health System
  • Preparation for 21st Century Biomedicine, Meaningful Use for Electronic Health Records, and Outcomes Management
  • Integration with various silos of clinical information sources (e.g., clinical, administrative and research) to provide additional value to the ambulatory oncology communities by using the information for extended business capabilities
  • Aim for meaningful interoperability between Health IT solutions and organizations for improved patient care
business problem opportunity
Business Problem & Opportunity
  • System Wide Challenges
    • Isolated information “islands”
    • Siloed health information infrastructure
    • Significant expectations for increased useof health record technology through HITECH Act stage 1, 2, and 3 targets and ensuing standards
    • A need for more modular, interoperable softwaresolutions to meet the needs of diverse clinical settings
  • Ambulatory Oncology Sector Challenges
    • Limited availability of EHR solutions focused on the unique needs of the ambulatory oncology sector which are ready for the emerging demands of 21st century biomedicine
  • Go-Forward Opportunities
    • Significant progress from ASCO & NCI collaborative efforts to document clear ambulatory oncology EHR functional requirements
    • ARRA funding to address technology gaps
    • A willing array of NCI Community Cancer Centers Program (NCCCP) implementation partners
cabig clinical information suite a collaborative national effort
caBIG® Clinical Information Suite: A collaborative national effort

American Society of Clinical Oncology (ASCO)

Began evaluating issue, involving end users

Engaged the vendor community through its EHR lab, utilizing unique case scenarios

Developed high level requirements document/white paper outlining the issue

cancer Biomedical Informatics Grid (caBIG®)

Vendor technology evaluation

Problem assessment

Technical Specification

NCI Community Cancer Centers Program (NCCCP)

Oncology EHR Laboratory

Other domain experts

oncology extended ehr clinical information suite
Oncology-Extended EHR Clinical Information Suite

The National Cancer Institute (NCI), through its Cancer Biomedical Informatics Grid (caBIG®) program, is leveraging the nation’s $44 billion investment in Healthcare Information Technology to fuel research in the following way:

NCI has collaborated with the American Society of Clinical Oncology (ASCO) and other professional societies to develop specifications for an “oncology-extended Electronic Health Record” to fill a gap in existing Electronic Health Record (EHR) functionality for practicing ambulatory oncologists

This NCI/ASCO project is called Clinical Oncology Requirements for the Electronic Health Record (CORE)

project scope
Project Scope
  • NCI is developing a series of software modules (referred to as “capabilities”) collectively known as the caBIG® Clinical Information Suite:
    • Modules are based on the CORE specifications and the expressed needs of the NCI community
    • They will integrate with EHRs to deliver functionality and interoperability useful to the practicing oncologist
    • They will support the specific oncology-related data collection needs of practicing oncologists, and build the “bridge” between clinical care and research
    • They will leverage NCI’s investment in a scalable services-based infrastructure
    • They will include both clinical (collecting data) and administrative (managing the trial) functionality, all available under a non-viral license for use by vendors and others in the community
project purpose
Project Purpose

To support the ambulatory oncology clinical care communities and open-source and commercial software vendors by delivering a series of highly configurable modular business capabilities and specifications while meeting the ARRA/HITECH meaningful use requirements.

These capabilities will-

  • Be highly modular and configurable to address a wide range of clinical settings via workflow, user interface and semantics
  • Provide key ambulatory oncology functionality and standards-based health information exchange
  • Position users for effective integration with other clinical, administrative and research systems
  • Leverage existing HIT standards and extend these standards from an oncology perspective where appropriate
  • Be released with a full set of specifications that can be used by vendors and implementers to leverage all or portions of the project deliverables
cabig clinical information suite goals

Target Goals

(One or more of these goals by close of project)

Architectural Adoption by Industry

Software solution vendor(s) consumption of platform independent caBIG® Clinical Information Suite specifications in the development/extensionof the product suite(s).

        • Measure of success: At least 1 service specification being utilized by industry to develop production viable functionality within a product.
  • Solution Adoption through the Open Health Tools (OHT) Community
  • Business capability and/or reference implementation consumption by the OHT community to integrate and/or repackage for the health IT market.
      • Measure of success: At least 1 fully specified and developed business capability consumed by the open source community and/or being implemented as a production implementation by the open source community vendors.

Clinical Community Adoption

One or more business capabilities and/or the full reference implementation being used in a daily production manner at ‘in scope’ early adopter site(s).

Measure of success: At least 1 fully specified and developed business capability in production use in a clinical care setting in 1 or more National Community Cancer Center Program (NCCCP) sites.

caBIG® CLINICAL Information Suite Goals
cabig clinical information suite
caBIG® Clinical Information Suite

The caBIG® Clinical Information Suite modules can be used (as either specifications or software) in conjunction with an EHR platform (proprietary or open source) to extend and/or compliment an EHR that enables ambulatory oncology

NCI has selected Tolven, as a representation open-source EHR platform that has met our technical requirements (HL7 V3 RIM based, ISO 21090 data types, etc.) to integrate the caBIG® Clinical Information Suite and thus deliver an end-to-end, deployable EHR as a Reference Implementation

cabig clinical information suite deliverables
caBIG® Clinical Information Suite Deliverables

Deliverables are expected to include:

A detailed, industry-validated requirements document (CORE, developed with ASCO)

An HL7 (Health Level 7) validated functional profile for ambulatory oncology based on the ASCO/NCI CORE requirements document and the HL7 EHR functional model

A set of structured use cases and application/service specifications documents, usable to guide development

A number of capabilities, i.e., software modules including both clinical (collecting data) and administrative (managing the trial) functionality, all available under a non-viral license for use by vendors and others in the community

cabig clinical information suite iteration and release process
caBIG® Clinical Information Suite Iteration and Release Process

Development iterative and incremental project where feedback is essential

Establishing formal focused review and feedback of project outputs from the iteration and release cycles

New and updated modules with increased functionality will be released, iteratively and incrementally, over the lifecycle of the project

Spans all project deliverables

Membership to include, but not limited to key representatives from NCI Divisions/Centers, NCCCP project 18 sites and their supporting vendors, project team, and DE/SME’s

aim for meaningful and working interoperability
Aim for Meaningful and Working Interoperability
  • Exchange data accurately, effectively, and consistently, using the information that has been exchanged
  • Data is exchanged and/or merged across the continuum of care, shared with the patient and used for reporting requirements
  • Adoption of services to allow computable data exchange between clinicians, researchers and patients
  • Advance NCI’s objective of interoperability in, and between, research and patient care
  • Deploy and use standards that enable computer systems to exchange information in a way that promotes patient safety and is secure and reliable.
nci cbitt strategic position questions
NCI CBITT Strategic PositionQuestions?

Consume/Contribute

Validate

Inform

  • CBIIT consumes and developsconformant standards-based specifications to resolve business problems
  • CBIIT validates the applicability of specifications via reference implementations
  • CBIIT informs the commercial and open-source vendor communities of the “state of the art” by deploying/handing off its reference implementations.
topics for discussion
Topics for Discussion
  • Sources of Requirements
  • Overview of Business Capabilities
    • High-Value Business Capabilities
  • Detailed Business Capability Definitions
    • Administrative
    • Diagnostic
    • Therapeutic
    • Disease Response
  • Confirm the appropriateness of the proposed capabilities
  • Identify missing capabilities
sources for business capabilities
Sources for Business Capabilities
  • caBIG® Clinical Information Suite domain experts
  • HL7 Ambulatory Oncology Functional Profile
  • American Society of Clinical Oncology (ASCO) Oncology EHR Functional Requirements
  • Requirements developed by St. Joseph Hospital Orange County, California
  • These business capabilities are also aligned with the Meaningful Use criteria as published in the January 13, 2010 Federal Register
hl7 functional model
HL7 Functional Model
  • The HL7 EHR System Functional Model (EHR-S FM) provides a reference list of functions that may be present in an Electronic Health Record System.
  • The function list enables consistent expression of system functionality. This EHR-S Model, through the creation of Functional Profiles, enables a standardized description and common
  • The EHR-S FM lists the set of all functions that COULD be present in various EHR systems.
  • This subset of functions characterizes the type of system being defined and is referred to as a “functional profile”.
  • The AOFP is one such functional profile.
ambulatory oncology functional profile ao fp
Ambulatory Oncology Functional Profile (AO-FP)
  • Provide one overall view of the needs of oncology care providers with respect to electronic patient records for both direct care, supportive and infrastructure functions.
  • Encourage EHR vendors to incorporate functions into their products that are necessary to support the unique requirements of the ambulatory oncology setting.
business capability categorization
Business Capability Categorization
  • Primary, High-Value Oncology Business Capabilities– this includes business capabilities that will address the specific business needs of the ambulatory oncology community, such that the use of EHR information can be leveraged to optimize an existing activity or enable the clinician or patient to conduct a new activity.
  • Supporting Business Capabilities– this includes business capabilities that will enable retrieval or exchange of information to support one or more of the high-value Oncology Business capabilities.
  • Commodity Business Capabilities– this includes business capabilities that are expected to be provided by the EHR platform(s) that will exist at the deployment sites (note: this may include one or many systems that make up such a platform – e.g., patient management system and patient scheduling system).

Note: EHR Platform is defined in this context as one or more systems that make up the commodity (i.e., readily available, commercial solutions) services and/or systems to meet the basic business capabilities of a research and/or clinical care setting.

business capability by type
Business Capability by Type

caBIG® Clinical Information Suite will design and build

Capabilities Well understood in Industry

(Built by others)

caBIG® Clinical Information Suite will interface

primary high value oncology business capabilities
Primary, High-Value Oncology Business Capabilities
  • Oncology Business Capabilities are considered high-value because they focus on the key opportunities that will demonstrate some of the benefits of 21st Century Biomedicine including, but not limited to:
    • improving the survival rate for cancer patients through better utilization of healthcare and research information
    • integrating information from the research and healthcare communities
    • providing the infrastructure to improve the availability and usefulness of the information collected that is simply not available in existing systems.
supporting business capabilities
Supporting Business Capabilities
  • Supporting Capabilities are those that caCIS will need to have interfaces to
  • Most likely these capabilities are developed by others or in collaboration with others
commodity capabilities
Commodity Capabilities
  • Commodity Capabilities are those well understood by Industry
  • Most likely these capabilities are provided or built by others
high value business capabilities
High-Value Business Capabilities
  • Each of the High-Value business capabilities fits into one of the following categories or dimensions of information:
      • Administrative
      • Diagnostic
      • Therapeutic
      • Disease Response
  • Each of the dimensions are required to prepare for the measurement of outcomes for individual patients as well as patient populations.
administrative capabilities
Administrative Capabilities
  • Business capabilities that have been identified as providing essential improvement in the ambulatory oncology community
  • As much as possible, the unique needs of ambulatory oncology has been considered – even within the administrative capabilities
diagnostic capabilities
Diagnostic Capabilities
  • The dimension of diagnostic capabilities requires several supporting capabilities of retrieving information from the surgeon, pathologist or radiologist to assess the diagnosis of a patient and one High-Value oncology business capability – Cancer Staging.
therapeutic capabilities
Therapeutic Capabilities
  • The dimension of therapeutic capabilities includes the use of therapeutic information in the ambulatory oncology setting, including:
    • Chemotherapy Management
    • Treatment Plan Management
    • Patient Trial Finder
disease response to treatment capabilities
Disease Response to Treatment Capabilities
  • Disease Response to Treatment
    • Response Evaluation Criteria in Solid Tumors (RECIST)
    • Tumor Burden
    • Functional Assessment/Performance Scales
      • ECOG
      • Karnofsky
    • Survival
    • Death Information
administrative capabilities referral management
Administrative Capabilities: Referral Management
  • Describes the referral process for accepting patients into the ambulatory oncology care system and ensuring the proper transfer of care
  • Create, send, receive, and approve referrals
  • Obtain the electronic documents associated with the referrals
  • The ability to electronically create, send, receive, and approve referrals and maintain the electronic documents associated with the referrals.
administrative capabilities referral management cont
Administrative Capabilities: Referral Management (cont.)
  • The ability to review all referred patients to determine if the patient meets the criteria for the practice, identify any additional clinical information that is required via a request for additional information.
  • The ability to exchange relevant information between providers to help reduce the duplication of data collection or diagnostic test(s)
  • The electronic referral includes all of the pertinent demographic, clinical, and financial information.
administrative capabilities chemotherapy reimbursement costing
Administrative Capabilities:Chemotherapy Reimbursement &Costing
  • Chemotherapy Reimbursement and costing
    • Ambulatory Oncology offices may require direct procurement of chemotherapy medications
  • Cost and availability may have an affect on chemotherapy scheduling Provide the requisite administrative components of managing the ordering of chemotherapy for administration to patients, while containing costs for the practice.
  • Identifying the costs and obtain adequate supplies of chemotherapy and related medicines administered by the oncologist.
diagnostic capabilities2
Diagnostic Capabilities
  • Cancer Staging
    • Based on the American Joint Committee on Cancer (AJCC) guidelines
    • Capture of Clinical and Pathologic Stage
    • Availability of guidelines for T,M,N and by cancer type
    • Ability to associate supporting clinical documents to the cancer stage
diagnostic capabilities cancer staging
Diagnostic CapabilitiesCancer Staging
  • Solid Tumor cancer staging describes the severity of a person’s cancer based on the extent of the original (primary) tumor and whether or not cancer has spread in the body.
  • Cancer staging, depending on the cancer disease, consists of an anatomic stage (TNM) and may include prognostic factors.
diagnostic capabilities cancer staging cont
Diagnostic CapabilitiesCancer Staging (cont.)
  • Staging helps the doctor plan the appropriate cancer care treatments. All clinical practice guidelines for the management of cancer use the assessment of the extent of the disease and the cancer stage at diagnosis to guide appropriate treatment recommendations.
  • The cancer stage can be used to estimate the patient’s prognosis.
  • The cancer stage is important in identifying clinical trials that may be suitable for a particular patient.
therapeutic capabilities2
Therapeutic Capabilities
  • Chemotherapy Management
    • Schedule Patient for Chemotherapy appointment (e.g., medication, resources, staff, etc.)
    • Plan, Order, Prepare (e.g., mix), and Administer Chemotherapy medications, Order Sets and flow sheets
    • Document patient tolerance
    • Manage and Document response to chemotherapy treatment (e.g., adverse reactions)
    • Manage administration of Anti-cancer drugs
therapeutic capabilities chemotherapy management business needs
Therapeutic CapabilitiesChemotherapy Management Business Needs
  • Providers and payers require processes to make chemotherapy management more efficient and cost-effective
  • Aim to minimize dosing errors and treatment complications
  • Ability to track important factors such as total cumulative doses, patient tolerance of previous medications/regimens
  • Provide improved uniformity in data captured and reported from the ordering, administration, and results of chemotherapy and other cancer therapies can help identify additional factors impacting outcomes
therapeutic capabilities cont
Therapeutic Capabilities (cont.)
  • Treatment Plan Management
    • Generate, Modify and Close or Discontinue Treatment Plans for patients based on known treatment regimens
    • Document use of standard or best practice guidelines
    • Document adherence with treatment plans based on patient’s response to treatment
treatment planning business need
Treatment Planning Business Need
  • Enable the availability of treatment plans across a multi-disciplinary clinical care delivery team
  • Provide a patient’s clinical data in a consolidated, single view for a health care provider
  • Foster coordinated planning, in an effort to result in improving patient’s safety and the effectiveness of the treatments
  • Improve Patient communication about their treatment(s)
therapeutic capabilities cont1
Therapeutic Capabilities (cont.)
  • Patient Trial Finder
    • Search for trials based on patient’s profile (i.e., inclusion/exclusion criteria)
    • Connect to protocol repository to conduct search
patient trial finder business need
Patient Trial FinderBusiness Need
  • Practices can aid trial recruitment by linking patient’s to potential local clinical trials (i.e., those sponsored by the practice with PI participation in clinical and pharmaceutical trials)
  • For certain patients, physicians need a mechanism to select from all registered clinical trials and narrow to those available regionally
patient trial finder criteria
Patient Trial Finder Criteria
  • A characterization of the patient in terms of medical status (both non-disease and disease specific traits) for the purpose of comparison with trial inclusion/exclusion criteria
  • A characterization of the patient in terms of personal preferences for trial participation, such as length of study, location of sites, duration of study, and other commitments or obligations of participation
  • Information for all local trials (e.g., sponsored trials) and all currently registered trials
    • Example: www.ClinicalTrials.gov
supporting business capabilities1
Supporting Business Capabilities

These are supporting and enabling business capabilities needed in order to retrieve and/or exchange information for the patient

questions
Questions?

Outcomes

slide57

Overview

  • The Role of NCI in a Vendor’s Architecture
  • Business Services, Technical Services, and Implementation
  • Conformance
  • The Value Proposition of the Architecture
  • Examples
  • Feedback
  • Vendor Scenarios
slide58

NCI and Vendors

How?

  • Key question:
    • How is NCI going to work in the same space as a vendor?
  • A helpful model is Commercial Development in a Municipality
    • The Skyscraper forms one community that exists within the other
    • There is some functionality that the building itself brings (HVAC, Security, Mail Access, Phone / Data Access, Plumbing, People Movers)
    • People come to the building for who is in the offices (doctors, dentists, accountants, architects, software companies).
      • The buildings services are incidental, but define the fulfillment patterns of the occupants’ delivery
    • The NCI’s building systems support the cancer center (the skyscraper) with vendor systems (the office suites)
slide59

NCI and Vendors

Partnership

  • Three models for NCI functionality to work with a vendor’s systems
    • Native Functionality – adding functionality to systems using native code, patterns, components (using the building’s security system for your bank vault)
    • Side-by-side Functionality – Use NCI’s code and applications to provide functionality that Vendors typically may not cover (HVAC, Security)
    • Middle Out– Take scenarios that involve multiple systems and show value in the interoperability (Steam plant recycling, Phone / data access are the nearest corollaries)
  • Each of these takes some coordination and planning
slide60

NCI partnering with Vendors

  • The NCI has focusing on two areas now (not just one), and all three models are applicable
    • Clinical Interoperability
    • Research Interoperability
  • The problem for the architecture is that – even in these examples – where you integrate to provide interoperability is variable
slide61

NCI partnering with Sites

  • The skyscraper and the metropolitan area have several different aspects to their relationship
    • Geographic – The landscape is different, an address is filled
    • Governance – The Metropolitan area may have ordinances and policies that need to be adopted, and those may change because of the existence of the skyscraper or new systems
    • Community Impact – Who is in the building impacts the immediate community
  • Three models of interaction between NCI and the community partners
    • Specifications Only – What the skyscraper looks like and what systems it must support
    • Components + Design – What businesses need to be in which rooms in the building + some system functionality (HVAC, for example)
    • Complete – The building and all that is in it
slide63

NCI partnering with Vendors

Example: i-SPY2

  • TRANSCEND – caCIS v 0.5 – integrating research and clinical care
  • Functional Requirements
    • Manage the patient registration lifecycle
    • Manage eligibility determination
    • Randomize patients
    • Track study participants
    • Manage bio-specimens
    • Capture clinical data at the point of care and render CRFs using automated methods
    • Provide traditional web-based CRFs
    • Manage patient and treatment planning calendars
    • Initiate the adverse event lifecycle
    • Storage and retrieval of trial data for each participant or in aggregate
  • All of these were done as SIDE-BY-SIDE or MIDDLE OUT solutions because of the nature of the vendor systems at UCSF
    • Shows a flexible strategy on the part of UCSF to adapt their native systems to meet changing science, clinical practice, and demands of research
  • Slides from www.hogarth.org
slide65

NCI partnering with Vendors

  • Transcend shows us one way to put these things together
    • Points the way for a more comprehensive approach that allows real information and intelligence to be accessible to researchers and clinicians
  • Our architectural strategy started with an idealization of how these fit together
    • Build systems for vendors, developers, and organizations
    • Define behavior and information quality standards that allow a NATIVE, SIDE BY SIDE, or MIDDLE OUT strategy to be identified by the implementer, NOT by NCI
      • Of course, this is sometimes easier said than done
  • From our take on the vendor perspective ….
    • Long term increase in interoperability
    • Intermediate term reduction in cost of integration with other systems
    • Short term strategies to identify additional consumers of information and to provide a layered architecture that is pluggable to NCI’s
slide66

SERVices + Components

  • Our Architecture is predicated on defining the MIDDLE OUT landscape
    • Green Field
    • Standards Based
    • Where we can set the bar for interoperability
  • Our Specifications combine a Services + Component model, as well as an RM-ODP Specification Approach
    • Allows us to define information and behavior that can be bound late to jurisdictions, provenance, and authority boundaries
    • Specifications that provide a layered, “opt in” conformance model
  • Architectural Approach
    • Setting standards for Information quality
    • Facilitating iterative and incremental prioritization of use cases based on good design
    • Setting standards for behavior at interfaces
    • Setting standards for behavior between systems
    • Drawing boxes around systems, jurisdictions, and information provenance
slide67

Business Services and Technical Services

  • The Architecture is pragmatic – We need to support all three models for the community, rather than mandate unappetizing adoption
  • The combination of Services and Conformance helps
    • Categorize legacy systems into communities
    • Build new systems and communities of systems to add functionality
    • Loosely Couple (1) Business and Technical Implementations
      • Business changes, and local implementations of business is variable
      • IT needs to be able to describe their component development as investments
        • “These components that we built yesterday to satisfy X use case can be reused today to satisfy Y”
        • “No, you cannot deprecate that service … it is used in A, B, and C Communities”
    • Loosely Couple (2) Allow systems to participate in these communities without sharing components, languages, etc.
slide68

Business Services and Technical Services

  • We use the SAIF Framework
    • Everything in healthcare is about interoperability between systems characterized by information and behavior
    • Defines standards for this interoperability
    • Defines different levels of conformance for interoperability
    • Defines Business Services
      • including communities and roles
    • Defines Technical Services and Interoperability Specifications, as realizations of business services
      • Includes interfaces and information models, as well as suggested component encapsulations
slide69

Inventory

  • PLACEHOLDER Here is our list of Services
  • PLACEHOLDER Here is our list of Interoperability Specs
  • PLACEHOLDER Here is what we are enabling
slide70

Conformance

Systems, Services, Roles, Communities

  • Systems take on Community Roles by virtue of the interfaces they expose
    • Where Roles and Communities are pre-defined to provide value, this means that many legacy systems can be adapted to fit these requirements
    • Where Roles and Communities are NOT defined or insufficiently defined, these interfaces allow behavior to be defined and organized
    • Roles and Communities have a many to many relationship
  • Service Specifications define their own communities
    • Every consumer is the same
    • One System may expose multiple Services
  • Interoperability Specifications define communities that are important to achieve some goal beyond that of a single service
slide71

Conformance

LEVELS

  • The caCIS Architecture defines the interoperability levels and the places where integration can happen
    • Organizations and Vendors can build to that
    • Vendors are in the drivers seat in terms of managing this
    • Conformance is a touchstone against which we measure everything else
  • Where a vendor or organization controls all parts of a system, conformance can be made mandatory or ignored
    • The more likely scenario is where there are multiple systems, organizational boundaries, trading partners, etc.
    • Our architecture allows Trading Partners to variably conform
      • May mean using an adapter strategy to achieve interoperability
slide72

Conformance

Conceptual Specifications

  • Conceptual Specifications provide a binding point between real or implied business analysis and a solution
  • Follows the ODP Viewpoints (Enterprise, Information, Computational, Engineering)
  • Conformance to a Conceptual Specification is a starting point …
    • Not enough for inter-organizational (or inter-system) interoperability usually
    • Instead, defines an endpoint, and allows classification of behavior and information
slide73

Conformance

Conceptual Specifications - Info

slide74

Conformance

Conceptual Spec - Behavior

slide75

Conformance

Logical Specifications

  • Logical Specifications begin to be more implementable by themselves
    • They exhibit some of the design decisions that NCI has made (HL7 V3, 21090)
    • They exhibit design decisions that the architectural team has made (MEPs, parameter decomposition, granularity decisions, service composition)
    • Serve as a solid foundation to implementation
  • Logical Specifications may include
    • Multiple information types (Allergy List, Concern, and Negation)
    • Strict bindings to datatype localizations (21090)
    • Bindings to contract patterns (response envelopes, exception handling)
slide76

Conformance

Logical Specifications - Info

slide77

Conformance

Logical Specifications - Info

slide78

Conformance

Logical Specifications - Info

slide79

Conformance

Logical Spec - Behavior

slide80

Conformance

Logical Specifications - WSDL

  • The WSDL reflects the architectural, design, and messaging patterns that we are using
slide81

Conformance

Platform Specifications

slide82

Conformance

Interoperability Specifications

  • It is one thing to think of an architecture as a set of reusable components (services). It is another to think about putting these together into solutions
  • Interoperability Specifications
    • Provide solution sets composed of existing components (services)
    • Conformance Statements including
      • Conformance Levels of dependent services
      • Choreography and Shared State
      • Binding complex community contracts (including roles and responsibilities) to technical solutions
slide86

Architecture - Other

  • There are other pieces of the architecture, design, and development that are worth noting ….
    • RIM-based db
    • Exception Handling
    • Contract Binding
    • Choreography engines + Configurations
    • Document Exchange
    • Virtual E H R Scaffold
    • ISO 21090 localized datatype specification
    • Service and Information Specifications, patterns and practices
      • HL7 + SOA
      • Identification
      • RLUS
      • Orders
      • Document Management
slide87

Architecture and Value

Summaries

  • We are defining levels of interoperability between systems
    • Providing integration points that enable interoperability
    • Groups must build up to those
    • This is a central tenet of our architecture … these points of interoperability allow for great extensibility and future usage
  • Vendors can pick their efficiencies, components, and differentiating factors
    • Barriers to entry are pretty low
  • It is a chance to build communities of systems that reduce the barriers to provision of care
    • This can be based on a vendor model while still being pluggable to NCI’s core architecture
slide88

Architecture and Value

Revisiting Transcend

slide89

Vendor Scenarios

Where things fit?

  • Vendors, organizations, and the NCI co-exist in a solution space
    • We are striving to allow organizations to make this more tractable
    • The consequences of choosing one integration path over another should
      • Be clear
      • Possibly be remediated
    • Functionality should not suffer
slide91

Service Spec Examples

  • PLACEHOLDER
    • We should have addendums / handouts with specific cases
ncccp project 18 overview
In 2011, practitioners will receive incentives for adoption of EHRs per the American Recovery and Reinvestment Act (ARRA)

NCI National Community Cancer Center Program (NCCCP) sites have made significant progress with electronic health infrastructure, however, the majority of community-based oncologist’s offices do not have access to patient EHRs

due to lack of suitable oncology-based EHRs in the marketplace

cost of acquisition

NCCCP Project 18 Overview
ncccp project 18 overview1
NCCCP Project 18, in conjunction with the caBIG® Clinical Information Suite, will provide oncology-specific EHR solutions

NCI is working with the American Society of Clinical Oncology (ASCO) to define / refine the requirements and use cases for oncology extension services for EHRs

defining and curating the relevant data elements in order to standardize the requirements

engaging in moving development forward through a variety of proposed projects

including commercial and open source vendor solutions

NCCCP Project 18 Overview
ncccp project 18 overview2
NCI is working with the Certification Commission for Healthcare Information Technology (CCHIT) to add oncology EHR requirements to the ambulatory EHR roadmap

various vendors will be engaged

services will be standards-based and designed to be interoperable with all major clinical system platforms

standards-based certifications are key to ARRA requirements for reimbursement for EHR adoption

NCCCP sites were given an opportunity to accelerate this progress through targeted funds to enhance oncology extended EHR deployment

NCCCP Project 18 Overview
ncccp site participants
The following NCCCP sites are participating in Project 18 and the caBIG® Clinical Information Suite effort:

The Helen and Harry Gray Cancer Center, Hartford Hospital, Hartford, CT

The Cancer Institute at St. Joseph Medical Center, Towson, MD

Billings Clinic Cancer Center, Billings, MT

The Center for Cancer Prevention and Treatment at St. Joseph Hospital, Orange, CA

Christiana Care Helen F. Graham Cancer Center, Newark, DE

NCCCP Site Participants
ncccp project 18 scope
NCI will offer the caBIG® Clinical Information Suite as software as a service (SaaS) that collects patient-reported, physician-practice, and hospital-based health information

The NCCCP sites may choose to implement the caBIG® developed solution or may opt to work with vendors to develop/acquire an EHR–compliant solution

This initiative provides dedicated staff support for NCCCP sites or approved commercial vendorswho utilize the caBIG® Clinical Information Suite EHR solutions to collect and appropriately share data

The NCCCP sites shall provide the necessary qualified personnel, leadership support, organizational change management, equipment, and facilities

NCCCP Project 18 SCOPE
ncccp project 18 goals
By the end of the funding period, the NCCCP sites and approved vendors will deploy or utilize the caBIG®Clinical Information Suite for information management, including the collection of patient-reported data, outpatient oncology physician-practice data, and/or hospital-based health information

The NCCCP sites and vendorswill share data within and between organizations, as appropriate, as determined and documented through the caBIG® Data Sharing and Security Framework

NCCCP Project 18 Goals
cabig clinical information suite goals1

Target Goals

(One or more of these goals by close of project)

Architectural Adoption by Industry

Software solution vendor(s) consumption of platform independent caBIG® Clinical Information Suite specifications in the development/extensionof the product suite(s).

        • Measure of success: At least 1 service specification being utilized by industry to develop production viable functionality within a product.
  • Solution Adoption through the Open Health Tools (OHT) Community
  • Business capability and/or reference implementation consumption by the OHT community to integrate and/or repackage for the health IT market.
      • Measure of success: At least 1 fully specified and developed business capability consumed by the open source community and/or being implemented as a production implementation by the open source community vendors.

Clinical Community Adoption

One or more business capabilities and/or the full reference implementation being used in a daily production manner at ‘in scope’ early adopter site(s).

Measure of success: At least 1 fully specified and developed business capability in production use in a clinical care setting in 1 or more National Community Cancer Center Program (NCCCP) sites.

caBIG® CLINICAL Information Suite Goals
integration strategies
Service implementation and integration is possible on multiple levels. Three distinct and anticipated approaches are:

Service Integration: Direct EHR Implementation through specification adoption/adaptation.

Container Integration: Decoupled interface messaging between caCIS implemented services and provider EHR. With and without caCIS provided GUI.

Container Adsorption: Native EHR implementation of caCIS service implementations.

Each of these implementation strategies has associated benefits and complexities.

Integration Strategies
integration strategies service integration
As presented by earlier, the service specifications exist on multiple levels of detail and would ideally be implemented at a Platform Specific level:

Conceptual Functional Service Specification

Platform Independent Model and Service Specification

Platform Specific Model and Service Specification

Additional Architecture Documents to be provided as requested based on availability

Integration Strategies: Service Integration
integration strategies container integration
The full caCIS container and associated persistence layer, semantic bus, ESB, etc. is integrated into an existing system via the use of the various integration interfaces (aka Semantic Adapters or SAs) supplied by the caCIS team. Integration Strategies: Container Integration
integration strategies container integration1
Container Integration can have two unique implementations:

Including GUI – caCIS provided service implementations utilize caCIS provided user interfaces to facilitate service operation.

Excluding GUI – caCIS provided service implementations act as a separate logical and physical component which provides data to the host desktop via published caCIS service interfaces.

Integration Strategies: Container Integration
integration strategies container integration2
Semantic Adapters provide decoupled HL7 interface to Business Capability

HL7 V3 RIM Messaging

Direct Messaging with minimal code set translation

Translated HL7 V3 CDA Messaging

Translated Messaging with format and code set translation

Translated HL7 V2/V3 Messaging

Translated Messaging with significant many to many message translations including a variety of message formats and code sets

Integration Strategies: Container Integration
integration strategies container integration3

Interoperability Messaging Levels

Direct Web Service Interface between EHR and caCIS Business Capabilities

With direct and exact messaging, integration becomes most simplistic

Complexity falls on the Sending and Receiving Applications

Integration Strategies: Container Integration

HL7 RIM Messaging

HL7 V2/V3 Translation Messaging

HL7 V3 CDA

integration strategies container integration4

Interoperability Messaging Levels

Message translation between HL7 V3 CDA and the caCIS Business Capability native HL7 RIM Messaging

Translation can be complex, however semantically interoperable messages simplify the effort

Some complexity falls on the EHR to create valid CDA Documents

Integration Strategies: Container Integration

HL7 RIM Messaging

HL7 V2/V3 Translation Messaging

HL7 V3 CDA

integration strategies container integration5

Interoperability Messaging Levels

  • Message translation between HL7 V2 and the caCIS Business Capability native HL7 RIM Messaging
  • Translation is very complex and only possible based on semantic needs of each business capability
  • Complexity falls on the data integration and interoperability resources
Integration Strategies: Container Integration

HL7 V2/V3 Translation Messaging

HL7 RIM Messaging

HL7 V3 CDA

integration strategies container adsorption
Using the full collection of caCIS service specifications and service implementations, an existing EHR integrates all caCIS functionality into its existing system.

NOTE: in order to accomplish this, the existing system must have a RIM-aware persistence framework (e.g., RIMBAA-compliant) and an overlying OWL-based reasoning layer with access to the RIM layer. A likely implementation will utilize WS-I Compliant Web Service Interaction.

Integration Strategies: Container Adsorption
integration strategies container adsorption1

EHR

caCIS Capability

EHR Business Function

Service Requestor

Service Provider

WS-I Compliant Web Service Interaction

Integration Strategies: Container Adsorption
integration strategies wrap up
Diverse software platforms and varying complexity highlight the importance of sound integration strategies and their implementation.

Follow up Q&A

Integration Strategies: Wrap Up
and that would be all
and that would be all….

“ In a time of drastic change it is the learners who inherit the future. The learned usually find themselves equipped to live in a world that no longer exists. “ Eric Hoffer

cacis session wrap up1
caCIS Session Wrap Up
  • Thank-you for your valued time!
  • Follow up, action items and next steps
  • Tomorrow’s Agenda
cacis contact information
caCIS Contact Information
  • NCI caCIS Project Team
    • NCIcaCIS@mail.nih.gov
  • Comments & Reviews Welcome
    • Anything we want to share? WIKI?