Presents Business Case for Service Oriented Architecture

1
Presents Business Case for Service Oriented
Architecture

• HL7 / OMG
• Technical Committee Conference
• December 19th, 2005

2
Presenters

• Eric Schripsema
• Founding Member of OntoReason
• Product Manager and Chief Architect
• Cecil Lynch MD, MS
• Founding Member of OntoReason
• Member HL7
• Health Ontology Author

3
Discussion Outline

• Introductions
• Service Oriented Architecture Definition
• What and Why
• Technical Overview
• Basic technology definitions
• Business Case Scenarios
• Deployment Examples
• Value of Service Implementation
• Discussion of the OntoReason Service
  implementation
• Defining a Services Strategy
• Moving Forward
• Discussion

4
Who is OntoReason

• OntoReason LLC is a partnership of IT and Health
  professionals formed to create state of the art
  tools for use in Health Care Information Systems
• OntoReason LLC product line includes
• Chi Standards-based Public Health Ontology
• Forward and Backward chaining Reasoning Engine
• Standard Services-based API
• Initial Product Features Include
• Code Set Translation/Standardization
• Concept Generalization/Specialization
• Differential Diagnosis
• Standard Differentiation Questions to Narrow
  Diagnosis
• Case Definition and Status Determination
• Next Generation Product Features Include
• HL7 V3 Message Segment Creation
• Vocabulary Management

5
Service Oriented Architecture

• Defining Services and a Service Oriented
  Architecture

6
Services Oriented Architecture Definition
A service-oriented architecture is a collection
of services designed to work together to support
multiple application functions, and perhaps
multiple applications.

• To understand SOA you must understand what a
  service is
• Services are not a new thing. Technologies such
  as DCOM and CORBA have been used to support
  services for quite some time
• A service is a self-contained system that
  provides an independent application function to
  clients

7
Sources for Services
Public Services are services which are free for
general consumption, and provide generic services
which may be of value to a given application
Custom Services are services which are designed
and built within the applications organization
COTS Services are licensed services that can be
integrated into application structures
8
General Services Architecture
9
Service Technology

• Common Service Architectures
• DCOM
• Corba
• EJB
• Web Services
• Architecture Limitations
• Some are Platform Specific
• Some are Language Specific
• Some are Complex/Difficult to implement

10
Web Services as a Solution

• Web Services Advantages
• Service Architecture based on existing Web
  technology and protocols
• http
• ftp
• Email
• Often implemented using standard web server
  technologies
• Web Servers - Apache, IIS
• App Server J2EE, .NET
• Web Services deployed on almost all platforms and
  languages
• Works within common network configurations
• Some potential Web Service Limitations
• Un-optimized message structure
• Use of common protocols may exposed otherwise
  secured systems

11
Web Services

• What is a web service
• A web service is a service technology that
  utilizes standard Internet protocols for
  communication
• Web Service Technologies
• SOAP
• Simple Object Application Protocol
• WSDL
• Web Service Description Language
• UDDI
• Universal Description, Discovery, and Integration
• ebXML
• Electronic Business using eXtensible Markup
  Language

12
Service Oriented Architecture

• Services Satisfying Real Business Requirements

13
Understanding the Public Health Domain

• Local Health Departments have dual role of
  interaction with providers and state to insure
  proper reporting, while protecting privacy and
  insuring proper treatment protocols
• Community health testing and treatment
• Health awareness programs
• Monitor trends and implement corrective measures
  to improve community health
• State Health Departments provide the core
  population surveillance and management. State
  Health Departments are often segmented into
  various program areas and are responsible for
  specific disease families.
• Derives its authority from state legislative
  branches and federal reporting requirements.
• Relationship between state and local departments
  varies from state to state
• CDC is the federal representative of Public
  Health and provide the basic set of requirements
  for reporting public health outcomes
• NEDSS National Electronic Disease Surveillance
  System
• PHIN Public Health Information Network
• Monitors macro trends and initiates studies to
  improve data collection and response
• Input to public policy on health related issues
  that effect national and regional interests
  with increasing emphasis on international issues
  

14
NEDSS, PHIN and the CDC

• The National Electronic Disease Surveillance
  System (NEDSS) is an initiative that promotes the
  use of data and information system standards to
  advance the development of efficient, integrated,
  and interoperable surveillance systems at
  federal, state and local levels.  It is a major
  component of the Public Health Information
  Network (PHIN).
• This broad initiative is designed to
• To detect outbreaks rapidly and to monitor the
  health of the nation
• Facilitate the electronic transfer of appropriate
  information from clinical information systems in
  the health care system to public health
  departments
• Reduce provider burden in the provision of
  information
• Enhance both the timeliness and quality of
  information provided

From the CDC NEDSS web site http//www.cdc.gov/ned
ss
15
How Public Health Views Itself

• The emphasis in Public Health is on Health
• Public Health participants provide health care to
  communities as a whole as well as provide support
  to providers
• Represents the link between government
  bureaucracies and providers and their patients
• Participant in homeland security efforts as the
  repository of local, state, and national
  information used to identify health concerns such
  as disease outbreaks and bio-terrorism

16
Software in Public Health
17
PHS3 Application

• PHS3 is a NEDSS compliant solution
• In deployment in California (State and some local
  PHD), Hawaii, and Utah
• In addition to basic NEDSS functionality PHS3
  provides dynamic disease management solution with
  a focus to local and state environments, and
  investigation process

18
Objectives for Service Implementation

• Provide consistency of function between
  applications in an enterprise
• Provide a platform to leverage existing
  functionality in additional applications
• Provide cross platform functionality with
  different operating systems and languages
• Reduce overall implementation costs when compared
  to implementing features within existing
  applications

19
Business Scenario Review

• The scenarios reviewed were selected from the
  current Public Health Surveillance application
• Specific scenarios were selected to demonstrate
  the value of utilizing Service Oriented
  Architectures are part of an Enterprise level
  application
• Scenarios demonstrate the use of services for
  integration of applications from different
  vendors, internal service implementations for
  shared functionality, and the use of COTS
  services.

20
Business Scenario

• Technology Participants

21
Applications Information Technology
International, Inc.

• The PHS3 application was used for the
  implementation of a NEDSS compliant application.
• The PHS3 application provided application
  function for
• Electronic Lab Test Processing
• Public Health Case management for Local Health
  departments
• Local to State reporting of qualifying Public
  Health Cases
• Preparation and processing of Public Health Cases
  for reporting to the CDC
• The PHS3 application suite is a J2EE based set of
  applications and services
• The PHS3 SOA is based on Web Services designed to
  function within a Intranet/Internet environment
• PHS3 utilizes SOAP and Hessian (Java native web
  service framework)

22
Applications OntoReason

• OntoReason provided Public Health information
  resources and services
• The OntoReason Health Ontology provided the
  following functions
• Vocabulary Services of standard code systems used
  for Lab Tests, Micro Organisms and Condition
  Identification
• Code translation services to help perform
  translations from legacy code values to
  standardized code systems
• Reasoning Intelligence for identifying case
  reporting requirements

23
Applications Other

• Additional enterprise functionality was provided
  by other vendors
• Application functions include
• Single Sign-On Intranet Solution
• Application Portal Gateway
• Alerting and Notification system

24
Business Scenarios

• Single-Sign-on / Application Portal
• Address Validation
• Electronic Lab Test Message Processing
• NEDSS Case Definition

25
Business Scenario 1Single Sign-On/Application
Portal

• Customer had a Single Sign-On system for web
  based applications that was limited to supporting
  applications within the local network domain
• Single Sign-On system could not support full
  request proxy, requiring client applications to
  directly access each application directly
• All state wide applications used by public health
  are required to use this service
• Security information gathered by the original
  sign-on needed to be passed to supporting
  application
• Implementation of additional infrastructure was
  outside of both project time table and budget

26
Scenario Solution Using A Service

• Customer provided a limited bandwidth connection
  directly between the portal network and the
  application network.
• A VPN was created between these two networks
  using existing technology (Microsoft VPN
  solution)
• A Service was created that provided to the
  sign-on applicaton a function that would accept
  user credentials (primarily the userId) and
  returned the URL of the surveillance application
  to be secured. Embedded in the URL was a key.
• The Single Signo-On application called the
  service whenever the user selected the
  surveillance application from the application
  menu, then called the service, and sent a
  redirect to the URL location to the users
  browser.
• The Surveillance processes the request, and
  isolates the key. It then calls the original
  service providing the key, and the service
  returned the user credentials. Those credentials
  are then checked against the application users,
  and if found, the application allows access

27
Security Service
28
Value of Solution to Customer

• Solution did not require any additional
  infrastructure other then the limited network
  connectivity and the VPN. This connection is
  provided over the Internet
• Software development costs were fairly low, and
  promised to not add significant long term
  recurring costs.
• Solution used a SOAP based interface which made
  it simple to implement in an environment where
  the portal application was written using
  Microsoft Technologies, and the Surveillance
  application was written in Java.
• Solution was flexible enough to be reused in
  additional situations with configuration
  changes.
• Reduces administrative support requirements for
  all state surveillance application (2-3 support
  engineers)
• Reduces complexity of 1000 users needing user
  names and passwords for more than one system,
  plus enables two factor security to be implement
  state wide.

29
Business Scenario 2Applications Requiring
Address Validation

• Various applications required a function that
  would validate addresses entered by users and
  received from outside sources
• Address Matching System from USPS provided a
  solution for this function. The AMS system
  provided an API for performing validation
• Data and API are updated by USPS 6 times a year,
  with licensed code that required update to
  continue working
• Cost of multiple implementations, along with
  associated maintenance costs suggested that a
  service could be used

30
Solution Using a Service

• The USPS Application provides a native API
  callable within various application platforms,
  written in C
• Since multiple applications required this
  function, a service was built that provided a
  simplified API via SOAP and Hessian
• Applications can call this service with an
  address record to be tested, the service returns
  a corrected (normalized terms and corrects)
  address or a collection of possible corrected
  address

31
Address Validation Service
By utilizing a service to integrate a non-service
application function, the functionality is
accessible to multiple applications, and requires
only one point when the data gets updated
32
Value of Service to Customer

• The USPS database is provided on CD and must be
  installed every two months
• Applications must be updated, as the software and
  database expire
• With the service, multiple applications can be
  maintained from a single location, with down time
  only being for the installation of the new
  version of data.
• Customer receives both tangible savings in time
  for both implementation and support, as well as
  consistency of operational dataProvides
  consistent address validation to the enterprise,
  where 70 of the address information across the
  enterprise contains some error, with missing
  information

33
Business Scenario 3Lab Test Processing

• Customer implementation of an Electronic Lab Test
  processing system had state wide reporting of lab
  tests to a single location in the state.
• Lab tests sent from various facilities in various
  HL/7 formats (2.3, 2.3.1, 2.3.z, 2.4) and non
  HL/7 formats (fixed length formats and comma
  separated value format)
• Lab Test information needed to be standardized to
  a single HL/7 format
• Messages need to standardize on coding systems
  for lab information (LOINC and SNOMED)
• Messages need to be distributed to various
  locations based on location and related
  condition
• Information is utilized by different applications
  in different networks

34
Lab Test Processing

• Lab Test Providers
• Local and State Public Health Labs
• Hospital Labs
• State and National Commercial Laboratories
• Information consumers State and Local Public
  Health
• Laboratory information analysis
• Public Health Case reporting
• Technical issues
• Inconsistent message structures
• Inconsistent vocabulary usage
• Variable delivery methodologies
• Regulatory Responsibilities
• The state legislators required that information
  be reported, but did not specify standards, and
  the public health department is unable to enforce
• All communication is done with the cooperation of
  all participants

35
Solution Using Services

• The solution to this problem involves a number of
  supporting services provided by OntoReason and
  the CDC
• Public Health Ontology
• The Public Health Ontology was used to provide
  vocabulary services for translation of various
  standard codes systems to SNOMED and LOINC
• Service was also used to identify conditions and
  condition groups to help determine routing
  information for messages
• Jurisdiction Resolution
• OntoReason provided a Jurisdiction Resolution
  service that translates address information into
  the identification of jurisdiction of record
  responsible for a given lab test
• PHIN/MS
• One of the communication structures supported by
  the solution is the ebXML powered PhIN/MS
  application
• Lab Tests delivery
• Lab Test information was pushed to the NEDSS
  application via a web service for processing
• Services implemented using SOAP, ebXML and
  Hessian technologies

36
Lab Testing Processing Service Architecture
37
Value to the Customer

• Overall implementation coordinated applications
  so each implementation was simple and specific to
  the problems that were solved
• Service Reuse
• Jurisdiction Resolution The jurisdiction
  resolution service is utilized by other
  applications within the enterprise.
  Specifically, the main NEDSS application and an
  Internet facing Provider Portal uses the function
  to properly identify case responsibility within
  the state.
• Public Health Ontology The vocabulary service
  is used by the NEDSS application to provide valid
  conditions, tests and organism values for
  processing
• Implementation costs
• Utilizing existing services and COTS solutions,
  overall cost for implementation was minimized and
  shared between projects
• Time to implement
• New organizational structures can be implemented
  within a few hours, allowing regional studies,
  new reporting jurisdictions, and the
  implementation of a new organization within a
  week.
• New and emerging conditions can be added to our
  surveillance management solution within a few
  hours. Changes and modification of existing
  condition management can be done in minutes.

38
Illustrations from the Real World

• Because there is no centralized control,
  participation often occurs with different levels
  of technology and cooperation
• In Public Health, solutions often require
  integration of various communication standards
  across large number of participants
• Redesign of the entire enterprise is often a
  lofty goal but with no real support due to costs,
  time, and scope.
• Solutions must often come in the form of
  transition technology allowing some aspects of
  the application to use the latest technology
  while supporting many legacy systems

39
Service Oriented Architecture

• Anatomy of a Health Care Service

40
Business Scenario 4Case Definition and Status

• Various components of a NEDSS implementation
  require proper case definition information
• Reporting requirements must be analyzed to insure
  that all case information is enter correctly
• Constancy of data within the application and
  communication with other components
• Vocabulary information for coding data within the
  application

41
Solution Using Services

• Implementation of the OntoReason Public Health
  Ontology as a service
• The Ontology provided the necessary vocabulary
  information for presenting both lab test
  information and organism codesusing recognized
  coding standards for code systems and data types
• Condition definitions organized valid tests and
  organism so that proper processing within the
  NEDSS application could be performed
• Case Definition information provides
  informational content about certain conditions
• Business rules derived from Ontology used to
  insure that case information is properly completed

42
Case Definition and Status
43
Defining a Health Ontology
Ontology An explicit formal specification of
how to represent the objects, concepts and other
entities that are assumed to exist in some area
of interest and the relationships that hold
among them.

• The OntoReason ontology represents various
  components of the public health in HL/7 terms and
  data types
• General Coding Systems
• Lab Test Information
• Micro-Organism
• Related Signs and Symptoms
• Abstractions of the ontology are be combined with
  rule based inference engines to provide logical
  processing

44
OntoReason Architecture

• The OntoReason tool set is generic and can be
  applied to many different problem sets within the
  health industry. Public health has been our
  initial target and this is reflective in the
  initial set of features. It is anticipated that
  a much broader set of services will be provided
  as the product matures.
• Core Ontology Services
• Vocabulary Management
• Message Segment Creation
• Code Set Translation
• Concept Generalization
• Concept Specialization
• Case Definition
• Core Reasoning Services
• Data Association and Correlation
• Differential Diagnosis
• Investigative Reasoning, Data Collection
  Requirement Definition, and Task Prioritization
• Contextual Reasoning within an Organizational
  Scope
• Case Status Definition
• Cluster, Outbreak, and Pandemic Indicators
• Core Enterprise Services

45
OntoReason Architecture
46
Information
47
Disease Plan Template
48
Ontological Condition Definition
49
Representing the CDC Case Definition in the PHS3
Application
50
The PHS3 Patient Profile
51
Using the Service To Evaluate Patient Profile
Interaction Workflow
52
Value to Customer

• The use of the OntoReason ontology provides a
  flexible extensible solution to enhance core
  behaviors
• Use of standards help insure compliance
• Standardization of applications within the
  enterprise structure
• Enables changes to the business logic without
  modifying software
• Enables the separation of complex business logic
  from core application. This allows specialized
  logic to be implemented as a service that can be
  used across the enterprise. For instance the
  surveillance module and the Lab Reporting
  module.
• Cost of implementing change in system is
  minimized, as chances can centralized, where if
  these features were embedded and used in multiple
  applications each application would require
  change.
• Minimize cost of expanding total system
• Separates complexity of domain model from core
  application

53
Using Ontology Based Services to Solve the NEDSS
business Problems

• PHS3 implements the NEDSS architecture which
  demands adherence to key business requirements
• Standardization of coding systems
• Standardization of information representation
• Standardization of communication
• The Ontological view of the public health
  information in the OntoReason knowledge system
  provides PHS3 with significant support in
  satisfying these goals
• By not requiring the PHS3 vender to develop and
  expand this information independently, the vendor
  and its customers have saved both in general
  implementation costs, and information accuracy

54
Service Oriented Architecture

• Addressing the Value Proposition of Service
  Oriented Architecture

55
SOA Value Proposition

• By addressing these problems with services, we
  have realized the following advantages
• Services improve the ability to respond to a
  changing landscape of both IT and business
  problems
• Services give single point of change to reduce
  costs when updates are required
• Services can extend the value of existing legacy
  data and systems
• Services can provide integration between third
  party applications to build enterprise wide
  solutions
• Services provide for enterprise standardization
  of both data and processing function

56
Change is the Key

• Change imposes the greatest risk to
  maintainability and cost effective solutions
• If a given business process anticipates change,
  then applications in that domain must be able to
  respond to change quickly and cost effectively
• Changing standards create a moving target for
  enterprise solutions as we plan the next
  generation of health care systems.

57
Components of Change in the Public Health
Enterprise

• Emerging Conditions
• Situations that effect the public health often
  occur as diseases are imported from other regions
  of the world, or are detected for the first time
• Due to lack of experience with given disease,
  initial procedures are often defined on the fly
• Issues such as transmission mode, incubation
  period, and clinical manifestation are discovered
  during the initial phases of an outbreak or
  cluster
• Isolated Risk Factors
• Sometimes as surveillance occurs, new risk
  factors are discovered, and actions must be taken
  to mitigate those issue
• Source Detection and Discovery
• New sources of disease exposure are discovered
  during normal surveillance
• Changing Threat to Population
• Surveillance guides processes to control and
  contain disease outbreaks, as better
  understanding of a disease occurs, these
  processes must be adapted.
• Evolving Case Definition
• Criteria for defining confirmed cases, change as
  our understanding grows.

Being able to respond to these situations is the
mission of any public health surveillance system.
How an application responds to these
requirements has a direct relationship to its
over all cost and value.
58
Value Proposition for SOA
In public health, inability to respond to
emerging conditions can create costs outside of
the public health organization, and have a direct
cost to a communities economy. Examples include
response to SARS, West Nile and Avian
Flu. Countries have paid the price in lost
tourism, agriculture devastation, and excessive
public monitoring.
59
Real solutions address real problems

• Limited budget of time and resources
• Timelines dictated by third party interests
• Monitory budgets defined with limited
  understanding of final requirements
• Staff not educated in technology or business
  domain
• Limited or Evolving standards
• Standards are a moving target
• Standards not fully understood
• Tools only partially fit requirements, resulting
  in more traditional development

60
Strategy Guidelines for SOA implementation

• Isolate legacy systems
• Isolate evolving standards
• Prepare for domain evolution
• Progress to enterprise vision in steps

61
Isolate Legacy Systems

• Identify the legacy applications that must be
  maintained and their value to the overall
  enterprise
• Identify legacy data as a enterprise data soure
• Determine if there are existing integration
  methodologies, even if they do not support
  standards that you wanting to implement
• Consider building an service interface wall
  around legacy systems instead of perform costly
  data conversion
• Provide a meta data registry so client
  applications can find where information is
  available in these services

62
Isolate Evolving Standards

• Identify those standards that you want to
  implement that are not yet at a level of adoption
  that is comfortable for your organization
• Use of internal code systems and data models will
  be necessary, and efforts should be made to
  reflect this information into standards via
  services
• Use framework integration techniques so as your
  service API evolves, current service code can
  easily be adapted
• Avoid dependencies on vendor proprietary
  solutions, and if you must, isolate the vendor
  solutions as well

63
Prepare for Domain Evolution

• Build services that do not require discreet and
  limited data definition
• Use template driven models that can be populated
  from domain knowledge systems, avoid static
  representation of attributes and behavior

64
Progress By Steps

• Because enterprise application have long delivery
  cycles, the vision will change over the
  development life cycle
• Because of the scope and complexity of the
  domain, incremental steps towards specific
  smaller solutions have a higher likelihood of
  success
• Service component implementations will help prove
  viability, refine enterprise vision, and insure
  forward progress, and reduce risk

65
Contact Information

• Eric Schripsema
• OntoReason
• eschrip_at_ontoreason.com
• Cecil Lynch MD, MS
• OntoReason
• clynch_at_ontoreason.com