WIXLIB

GAPS IntegrationArchitectural StudyJanuary 1st, 2016Prepared for:New World Health

New World Health – GAPS Integration Architectural StudyGalen Healthcare Solutions, Inc.1120 BuckinghamGrosse Pointe Park, MI 48230Phone: 888.GALEN.44www.galenhealthcare.comPublished by:Galen Healthcare Solutions, Inc.Statement of ConfidentialityThe information in this analysis is confidential and proprietary. It has been madeavailable to New World Health solely for its consideration and evaluation of this analysis.In no event shall all or any portion of this proposal be disclosed or disseminated by NewWorld Health without the express written permission of Galen Healthcare Solutions, Inc.Copyright 2016 Galen Healthcare Solutions, Inc.2

New World Health – GAPS Integration Architectural StudyExecutive SummaryThe Executive Summary is a high level overview of the intent, findings and conclusion ofthe Galen Architectural Planning Survey (GAPS) study conducted for New WorldHealth.This document will provide recommendations regarding the migration from the currenteight integration engines: JCaps, OpenLink, eGate and SeeBeyond to the RhapsodyIntegration Engine. These recommendations will include estimates based on the existinginterface configurations, suggested architecture, implementation conventions, withoperations and support procedures as considerations.BackgroundThe purposed of the GAPS document is to compile the results of the on-site analysis andprovide direction for the migration from the current integration platform to the RhapsodyIntegration Engine. The challenge, as with any migration, is to plan a migration path thatwill leverage as much of the existing development while taking advantage of the features,functionalities, and efficiencies of the new integration platform. To accomplish this, thecurrent eGate, JCaps, SeeBeyond, and OpenLink configurations were analyzed todetermine how the current interface/business logic translates to the Rhapsody paradigm.It has been noted when, if any, current interfaces might present a problem duringimplementation. Due to the complex and custom nature of most integrationenvironments, there is no automatic or generic migration to Rhapsody. However, thereare certain objects and principles that translate and it is the goal of the GAPS process tohighlight, whenever possible, the physical and logical components that do translate insome form or fashion.Given the complexity and non-traditional nature of data structure and storage within theeCW database, Galen has performed an analysis on the source database to confirm theability to extract the different types of structured and non-structured clinical datacomponents from the database. The goal of this analysis is to provide confirmation ofdata integrity as well as yield a clearer scope definition allowing for New World Healthto make more informed decisions regarding which clinical data types are feasible topursue for conversion. Below you will find a high-level summary of the feasibility ofeach data component.FindingsThe following general findings were the result of the analysis of the current integrationenvironment in no particular order:Copyright 2016 Galen Healthcare Solutions, Inc.3

New World Health – GAPS Integration Architectural Study The primary use of HL7 messaging creates a more simplified migration andRhapsody implementation due to the support of this standard in the Rhapsodymessage definition and mapping components.As the New World Health environment is large and complex, each team did theirpart to flag easy, medium, and hard translations.The publication and subscription model in place does not create any significantchallenges for the migration to the “push” model of passing messages directlyfrom object to object in Rhapsody.The current naming standards, while different across each engine, follow a similarapproach. The conventions designed for New World Health follow the familiarapproach, optimized to enhance the management, support, and design of theRhapsody product.As with any migration project, designing a thorough approach will ensure theoverall success of the project. With eight interface engines to be migrated, theproject can be subdivided into 4 simultaneous projects that have been chosenbased on the current message flow and business divisions.ConclusionsThe interface logic itself does not create any technological migration hurdles and thereappears to be no logic which is not directly supported in Rhapsody. Therefore theconversion of the current interfaces can proceed without any significant architectureservices or product enhancement required. However, many of the interfaces in theJCAPS and SeeBeyond 5.12 environment have complex coding standards. This iscompounded by interspersing using the message parser to perform modifications to themessage and calling JAVA functions to manually manipulate the entire message as astring. This unbundling of logic will add significant upfront time to the migration.Current State AssessmentThe following is a comprehensive view of the integration architecture and the technologysupport as they exist today. The part of the assessment focused on the review of existingartifacts, configurations and meetings with the extended New World Health interfaceteam(s).OverviewBased on the review of the current environment, there appears to be no non-standard orcomplex implementation of the technology that would create significant barriers inmigrating to Rhapsody.Copyright 2016 Galen Healthcare Solutions, Inc.4

New World Health – GAPS Integration Architectural StudyHowever, due to the current piecemeal complexity consisting of 8 separate interfaceengines, the migration to a single instance of Rhapsody will require coordination and athorough project plan. While the use of non-standard functionality is not prevalent,because some messages have the potential to be manipulated in multiple engines, theupfront effort to document the end-to-end configuration requirement is significant.Key Technology and Architectural ComponentsThe following eGate technology and logical components were analyzed for complexityand to determine the level of effort required to migrate to the Rhapsody integrationplatform.Message ManipulationIt was noted that in both the NWH SeeBeyond and NWH JCAPS engines had complexlogic to translate messages. This is to be expected for a minority and it is important notto start with these before becoming comfortable with the abilities of Rhapsody.The proprietary Monk programming language is the primary coding language in for theinterface collaborations. The majority of the collaboration code copies data from theinput message structure to the output message structure. Although the Monk languagecan perform complex logic and string manipulation there is no significant use of thesefunctionalities here.Analysis of the variables in the code showed no use of the dynamic casting capabilities ofMonk and should provide no challenges in translating the logical code blocks into aRhapsody map definition.Message ParsingThe majority of messages processed at New World Health are HL7 v2 message types.The Symphonia (Rhapsody) message definition library supports the HL7 v2 messagestandard. Recreating the message definitions to match the existing event type definitionsis a straightforward build process and requires basic Rhapsody skills. This process canbe time consuming if the messages significantly deviate from the HL7 standard. TheAdapt to Messages feature in the Rhapsody IDE will seed up this process and provide amethod for verifying the message definitions against a cache of production messages toensure that the existing messages can be parsed correctly by the new Rhapsody messagedefinitions. A conservative estimate is that a difficult definition can take up to 1 day tocomplete (build and test).Two items to note:1. The Rhapsody message parser follows the HL7 standard in all aspects. The HL7 standarddictates that if a composite field is null then the lower level delimiters are not placed inthe message. Some other engines, such as eGate do not follow this convention.Copyright 2016 Galen Healthcare Solutions, Inc.5

New World Health – GAPS Integration Architectural StudyThis is only an issue when the receiving system(s) interface has been programmed toexpect the lower level delimiters and will experience an error when receiving a messagewithout the lower level delimiters. If this should occur there are two general courses ofaction. 1) Reprogram the receiving system to no longer require the delimiters in themessage. 2) Configure the Rhapsody interface to add the delimiters to the outputmessages (this would need to be done manually with code as this is not a setting oroption).2. It was noted during the GAPS analysis that many manipulations within JCAPS /SeeBeyond were being accomplished by manipulating the entire message as a string.This was method was utilized because of both the comfort of the programmers and thedifficulty in creating message definitions with the current product(s).Galen highly recommends using the features and functionality built into Rhapsody toaccomplish message manipulation. This means parsing the message and accessingsegments and fields directly. It is by far the most efficient and recommended approachto take. Since most filters and routes in Rhapsody are designed to parse the messageimmediately, a filter such as the mapper will not function correctly if it cannot parse theentire message. Therefore, it is vital to have solid message definitions for each systemyou will be interacting with. If there is reason to need to manipulate a message withoutparsing it, a javascript filter would likely be the easiest method. Setting any var equal toinput[0].text will return the message body as a string. One example of a valid reason todo this would be to prepend or append some characters to the entire message. It is notrecommended to use this feature to manually split the message by “ ”.Publication and Subscription ModelThe current integration platform employs a publication and subscription model forpassing messages from the input connectors through the translation layer and to theoutput connectors. This implementation utilizes a JMS queuing layer that lies betweenthe publisher and subscriber and effectively decouples all the components. In some casesthis can present a problem when migrating to the Rhapsody “push” model wheremessages are passed directly from component to component creating a more holistic viewof the lifecycle of the message as it passes through the interface.The results of this analysis yielded no significant use of the complex capabilities of thepublication and subscription model or direct use of the standard JMS queue technology toroute messages. This straightforward implementation will present no migration issueswhen deploying the routing of messages in the Rhapsody environment.Copyright 2016 Galen Healthcare Solutions, Inc.6