HL7 Real Time Integration with Oracle SOA for Healthcare 12c

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. |

ORACLE SOA INTEGRATION FOR HEALTHCARE – 12C HL7 real time integration – A Case Study

Lonneke Dikmans


PROGRAM AGENDA

The Use Case

Solution Architecture

Deployment Architecture

Exceeding Expectations

Future Challenges

Oracle SSHI12.2.1 – What’s New?

2

3

4

5

3

6

1


INTRODUCTION

• Aboutme– CountrymanagerateProseedNL– OracleAceDirector,workingwithOracletoolingsince1998– AuthorofSOAMadeSimple

• AbouteProseed– HQinLuxemburg– Localofficesinseveralpartsoftheworld– AwardwinningOraclepartner

4


THE USE CASE

5


CHILDREN’S HOSPITAL OF PHILADELPHIA

•  Founded in 1855 • Ranked one of the best Hospitals in US •  First hospital in US devoted exclusively to pediatric medicine •  Full Oracle Stack – Exadata – Database – FMW – Could Control

6


SSHI COMMON CUSTOMER’S CHALLENGES

•  Integration across HC information silos • Modernize based new market trends: – Message Standard evolution (HL7 v3, CDA, CCD) – Moving from a Hub and Spoke to a SOA Centric platform – Introduction of various integration standards and patterns (webservices, etc)

• Service Oriented Architecture (SOA) integration introduction •  Improved cross system visibility

7


CHOP’S CHALLENGES

• Migration from Sun Java CAPS / SeeBeyond eGate to Oracle SOA Healthcare • Tightly-coupled, limited concurrency, exception handling • Reduced Configurability •  Long development cycles and difficult to scale – point to point, do not scale and difficult to maintain

• High cost of ownership

8


•  Build an HL7 ADT message broker

•  Connect > 200 Healthcare Applications

•  Process 3 M Msg/Day •  100.000 Inbound -> Fan – Out millions

•  Reduce time-to-market for application integration

•  Frequent routing rules update

•  Empower of business users to configure routing and transformation rules

THE UBER USE CASE


•  ADT Messages Exchange •  Scheduling, •  Admissions, •  Transfers •  Discharges, •  Etc.

•  HL7 ADT A05 Pre– Admission

•  HL7 ADT A01 Patient Admission

•  HL7 ADT A04 Patient Registration

•  HL7 ADT A03 Patient Discharged

•  HL7 Acknowledge Reply

A TYPICAL UBER USE CASE

Laboratory

Radiology

Pharmacy

Cardiology

Urgency


• ADT Message Processing – Parsing and Construct – Validation

•  > 50 ADT Event Types • HL7 Acknowledge • ADT Message Sequencing • MLLP Protocol • Message Enrichment

• Content based message routing – Department – ADT Event Type

• Message Filtering Rules – Event Type – Department Confidentiality – Any other content information

• Enhanced configurability experience

11

UBER USE CASE REQUIREMENTS


• Demanding Performance – 3M/day – Max Processing time 3 sec – Peak Time – 40% - 4h –  65 Mps - Avg

• Maximum Reliability – 0 message loss

•  Large Document Processing

•  System Availability – Up-time Goal - 99.99% - 24/7

•  Monitoring – Endpoint Disconnection – Message End-to-End Tracking – Alerts

12

UBER USE CASE REQUIREMENTS


SOLUTION ARCHITECTURE

13

Copyright © 2014, eProseed and/or its affiliates. All rights reserved. | 14

10 REASONS . WHY SSHI

1 Pit Stop for Healthcare System Endpoints, Document

2 Multiple Document Protocol Support including native support of HL7

4 Document Definition Tools Available

7 Multiple Transport Protocols Support

3 Document Translation, Validation and Construction

6 Oracle Fusion Middleware integration platform

10 E2E Message Monitoring and Auditing

8 Supports Sequencing

5 Native MLLP support

9 Proactive and reactive fault handling


WHAT ABOUT ORACLE SOA SUITE – SCA/OSB?

• Composite layer for: – Integration with SSHI (HC Adapter JMS Binding & In Memory) – Orchestration – Dynamic Routing and Transformation Rules by content – Mapping for message normalization – Enrichment – Result Caching – Integration with legacy systems – Exception Handling

15


DESIGN PRINCIPLES (1)

1.  Extensibility – Add message types, – Add or replace downstream applications – Change the existing routing, filtering and transformation rules

2.  Configurability – Existing routing rules, transformations and filters should be configurable – Change parameters of filters without having to change code or redeploy the solution

3.  Reliability – High Availability – Store and Forward – Disaster Recovery – Zero Message Loss

16


DESIGN PRINCIPLES (2)

4.  Performance – Demanding performance without decorating reliability

5.  Maintainability – The solution should be easy to maintain – New FMW developers should be able to understand the UBER solution quickly – Best Practices and Governance principles

17


IMPLEMENTATION (1)

1.  Internal Canonical Model (based in ADT Canonical) – Reduced translations – Dynamic transformations

2.  Sequencing – Interface Sequencing – HC API discarding

3.  Message Validation – Protects Uber and Downstream Apps from invalid messages

18


IMPLEMENTATION (2)

4.  Exception Handling – Central and cross architecture exception handling (HC + SOA) – Sequencing Management (No Routing, Exception, Filtering, etc.) – Configurability (Notifications, etc.)

5.  Healthcare Adapter – OOB standard Integration (no boiler plate) – Cross domain integration

6.  Caching – OOB OSB caching for Message Enrichment (Department Table)

19


IMPLEMENTATION (3)

7.  Unique Inbound Composite – Serves all Inbound Composite

8.  Generic vs Specific Outbound – Generic: configurable – Specific: extendible

9.  Oracle Business Rules – Covers all (Routing, Handling, Exception) rules – Standard and OOB – Excel Import/Export – Run time rules editor

20


HIGH LEVEL CONTEXT


COMPONENT ARCHITECTURE


INBOUND PROCESSING

• Use of a single generic inbound composite – Flexibility – no new inbound composites for new ADT messages – Enabled by opaque and internal delivery channel

• Healthcare Adapter • Uber Internal Canonical – Mapping (Dynamic XSLT on MDS)

23


MEDIATION AND DYNAMIC ROUTING


UBER RULES ENGINE

• Routing Rules – Which endpoints will receive the messages – Specific vs Generic – Specific transformation in generic cases

• Handling Rules – Specific Outbound Composites with additional steps

• Exception Rules – Actions configured based on exception details

25


OUTBOUND PROCESSING

• Generic Outbound Processing – Default Scenario applied to the majority of cases – Standard sequence of steps – Standard of flexible transformations and mappings

• Specific Outbound Processing – Alternative scenarios particular to a specific downstream – Message Enrichment (i.e. Department Data) – Handling Rules (Filtering)

26


GENERIC OUTBOUND


SPECIFIC OUTBOUND


DEPLOYMENT ARCHITECTURE

29


DEPLOYMENT ARCHITECTURE DESIGN (DOMAIN TOPOLOGY)

PRD primary DC

Healthcare Domain Admin Server

port 7001

HC Cluster (Active - Active)

Healthcare Server 1

port 7011

Node Manager

port 5556

Healthcare Server 2

port 7011 Node M

anager

port 5556

Soa Domain Admin Server

port 8001

SOACluster (Active - Active)

Soa Server 1

port 8011

Soa Server 2

port 8011

OSB Cluster (Active - Active)

Osb Server 1

port 9011

Osb Server 2

port 9011

Node Manager

port 5556

Node Manager

port 5556 RAC DB

Node n

Node 1

Node . .

30

NFS Hitachi 4080 NAS


DEPLOYMENT ARCHITECTURE DESIGN

•  Usage of shared storage for all pinned services –  TLOGs of servers, configured using File persist-stores –  JMS services, configured on migratable targets and using File persist-stores –  Performance gains vs JDBC

•  Local storage usage for reducing I/O on the shared storage –  Log files –  Nodemanager

•  Usage of Healthcare Adapter configured using JMS for integration between domains •  Disaster Recovery – Passive DataCenter available

31

General Considerations


HA AND DR CONSIDERATIONS High Availability

– Cluster domain setup (Active-Active) of 2 servers on separate hosts – All TLogs and Persist stores are on shared storage – All JMS services are targeted to migratable targets – Distributed Queues – Gridlink Data-Sources – B2B/HC HA Configurations •  b2b.HAInstance •  b2b.AcquiredStatePollingInterval •  b2b.MLLP_HA_Mode •  b2b.HAHeartBeatPing

• MLLP Load balancing and failover 32


EXCEEDING EXPECTATIONS

33


RELIABILITY, ACHIEVED

• Maximized reliability obtained by: – Message persistence •  HC/B2B Tables •  Internal delivery queues

– JMS persistence – Adequate B2B/SOA configuration – Suitable exception handling – Accurate purging and archiving strategy in place – Reliable monitoring and alerting – Continuous Integration strategy

34


• Composites – OneWayDelivery = Sync

• OSB Result Cache •  Interface Sequencing • Threads configuration – B2B, JMS Pooling, Inbound Composite

• SOA Work Managers Configuration • Weblogic tuning for production

•  B2B/HC Configurations – B2B.NIO = True •  Improved performance and scalability using

NIO Async API Protocol with MLLP

– b2b.docPluginList (HL7) – The order matters – Others….

•  JMS – File Store Persistence - Direct-Write-

With-Cache (all) – Tuned Connection Pools

•  JVM Tuning 35

PERFORMANCE, ACHIEVED


EXCEEDING EXPECTATIONS

•  Standardization of messages and integration approach lead to reduction of costs •  Flexibility with outbound generic and specific integration •  Agility adding new endpoints and ADT event types • Normalization of messages eliminated point-to-point costly conversions • Performance requirements overcome with 75Mps (~6,5M msg/d.) • Productivity enhanced using OOTB features as Business Rules


FUTURE CHALLENGES

37


CHOP’S CHALLENGES

• Decommission JCaps • Smart Beds (IoT) • Engaging patients • Improved cross system visibility

38


SSHI 12.2.1 – WHAT’S NEW

40


• Performance Improvements –  In memory sequencing –  DB Load reduction (50% reduction) –  Reduced Memory footprint – Multiplexed IO –  Coherence Caching usage maximized

• PGP Encryption –  Encrip/Decript Callouts

• New message patterns –  Synchronous Request/Reply over MLLP –  Custom ACKs for non-HL7 messaging over

MLLP

• Alta UI and Mobile Enablement • Endpoint Cloning

41

ORACLE SSHI 12.2.1 – WHAT’S NEW

Date post:	01-Jan-2017
Category:	Documents
Upload:	vanquynh
View:	224 times
Download:	1 times

HL7 Real Time Integration with Oracle SOA for Healthcare 12c

Documents