Presents Business Case for Service Oriented Architecture

Presents Business Case for Service Oriented Architecture HL7 / OMG Technical Committee Conference December 19th, 2005 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 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 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 Service Oriented Architecture Defining Services and a Service Oriented Architecture 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  Sources for Services Public 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 Enterprise Application Custom Services COTS Services General Services Architecture Service DataBase Custom Service Web Client Public Service COTS Services Black Box COTS Service Interface Internet Enterprise Application Public Service Services Communication Services Registry Redundant Custom Service Web Client Enterprise Application Service DataBase Service Adapter Thick Client Service Adapter Legacy Application Functionality Legacy Database Legacy Applications Enterprise Applications Services Architecture Components Service Adapter Client Applications COTS Application Components 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 Web Services as a Solution ● Web Services – Advantages  ● ● ● Service Architecture based on existing “Web” technology and protocols http ftp Email Web Servers - Apache, IIS App Server – J2EE, .NET  Often implemented using standard web server technologies ● ●   ● 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 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 Universal Description, Discovery, and Integration Electronic Business using eXtensible Markup Language UDDI ● ebXML ● Service Oriented Architecture Services Satisfying Real Business Requirements 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 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 ● ● ● Software in Public Health 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 «uses» Provider Portal Core PHS3 Application «uses» «uses» Providers Services Framework «uses» og y AM to l S on Public Health Nurse Hospital «uses» se cu n «uses» Epidemiologist «uses» Electronic Laboratory Reporting Labratories ELR Analysis Application ri t y Ju rs id ic tio 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 ● ● ● 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. ● ● Business Scenario Technology Participants 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) ● ● ● ● 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 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 Business Scenarios ● Single-Sign-on / Application Portal Address Validation Electronic Lab Test Message Processing NEDSS Case Definition ● ● ● Business Scenario 1 Single 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 ● ● ● 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 ● ● Security Service Original Sign-on Request Request to Launch NEDSS application Service Request for URL Redirect Request Redirect Public Health Application User Credential Lookup PHS3 Application Access Connect via Internet VPN TUNNEL Single Sign-On/Application Gateway Security Service PHS3 Application 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. ● ● ● Business Scenario 2 Applications 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 ● 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 Address Validation Service PHS3 Surveillance Provider Portal Other Enterprise Applications 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 USPS AMS API Address Matching Service USPS Address Data 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 data Provides consistent address validation to the enterprise, where 70% of the address information across the enterprise contains some error, with missing information ● ● ● Business Scenario 3 Lab 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 ● ● ● ● ● 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 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 OntoReason provided a Jurisdiction Resolution service that translates address information into the identification of jurisdiction of record responsible for a given lab test One of the communication structures supported by the solution is the ebXML powered PhIN/MS application Lab Test information was pushed to the NEDSS application via a web service for processing  Jurisdiction Resolution ●  PHIN/MS ●  Lab Tests delivery ● ● Services implemented using SOAP, ebXML and Hessian technologies Lab Testing Processing Service Architecture PHS3 Survelliance Laboratory Analysis Local PH Lab PHIN/MS Queue Hospital ELR Message Processor Local Surveillance Systems sFTP server General Services Framework Local Independent Lab Local Surveillance Systems Jurisdiction Resolution Public Health Ontology ebXML message sFTP file drop HL/7 Batch File Simplified HTTP Push SOAP WEB Service Call CSV Batch File Single HL/7 Message 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. 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 ● ● ● Service Oriented Architecture Anatomy of a Health Care Service Business Scenario 4 Case 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 ● 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 codes using 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 ● ● Case Definition and Status PHS3 Surveillance Provider Portal ELR Message Processor ELR Test Analysis OntoReason Service Health Ontology Fact Base Knowledge base Rule Base 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 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 ● Intelligent Meta Services Broker, Services Bus, and Message Handler OntoReason Architecture Enterprise Services Intelligent Services Service Adaptors Health Ontology Code Sets Enterprise Services Layer Intelligent Service Layer Structure (HL7) Context (Org) Organisims Conditions Lab Tests Case Definition Clinical Observations Results Case Sufficiency Information Disease Plan Template Observations Defines Condition Specific Observation Set Condition Definition Enables Custom Mgmt Plan Disease Plans Instantiates Vocabulary Surveillance Manager Enterprise Services Framework Case Definitions Condition supports CDC case Definition Patient Record Collects PPP Information CDC Case Status Def. Patient Presentation Profile Checks Patient Profile for Completeness Suspect Probable Confirmed Case Status Updates Case Status for Reporting Disease Plan Template Ontological Condition Definition Representing the CDC Case Definition in the PHS3 Application The PHS3 Patient Profile Using the Service To Evaluate Patient Profile Interaction Workflow PHS3 Application OntoReason Ontology Service PHS3 Patient Profile Representation (Based on HL/7 RIM) Transform Case Into Simplified Form Service Representation of Patient Profile Convert Patient Profile into fact representation Patient Profile Represented as Facts Extract Facts and Rules from Ontology Presentation of Case Completness Information Case Completeness Represented as simplified Object Execute Rules to determine case “completness” 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 ● ● ● ● ● 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 ● Service Oriented Architecture Addressing the Value Proposition of Service Oriented Architecture 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     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. ● ● 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 New sources of disease exposure are discovered during normal surveillance Surveillance guides processes to control and contain disease outbreaks, as better understanding of a disease occurs, these processes must be adapted. Criteria for defining confirmed cases, change as our understanding grows. ● Source Detection and Discovery  ● Changing Threat to Population  ● Evolving Case Definition  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. Value Proposition for SOA Cost to economy, when the enterprise can not react quick enough Cost 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. Application/Solution Business Logic Enterprise IT Infrastructure Ontology Addressing Change Through IT Implementation Organization Business Processes Enterprise Services 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 Strategy Guidelines for SOA implementation ● Isolate legacy systems Isolate evolving standards Prepare for domain evolution Progress to enterprise vision in steps ● ● ● 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 ● ● ● ● 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 ● ● ● 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 Functionality Flexibility 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 ● ● Contact Information ● Eric Schripsema OntoReason eschrip@ontoreason.com ● Cecil Lynch MD, MS OntoReason clynch@ontoreason.com