ConnectR Migration and Patient Linking Project … · Web viewData Auditing10 Reference...

XYZ Radiology ConnectR Migration and Patient Linking, Solution Design

Document Summary and PurposeThe purpose of this document is to capture project goals and functional design details for the XYZ Radiology ConnectR Migration and Patient Linking project. This document serves as an agreement between XYZ Radiology and Prosch designers, programmers and testers providing needed information for, development and project delivery.

Document Change Control

Version

Modified By Modified Date Change Detail

1 Darrell Gabbard 4/17/2012 Initial Creation

Table of ContentsConnectR Migration and Patient Linking Project Summary.........................................................................................2

Project Drivers.........................................................................................................................................................2

ConnectR to BizTalk Migration, Solution Design..........................................................................................................3

Solution Summary....................................................................................................................................................3

Infrastructure Design...............................................................................................................................................3

Server Architecture..............................................................................................................................................4

MS Clustering.......................................................................................................................................................5

Interface Development............................................................................................................................................6

Prosch HL7 Interface Generator...........................................................................................................................6

HL7 Message Family – Canonicals........................................................................................................................7

PCC Translation Solution......................................................................................................................................7

Prosch Patient Linking Integration.......................................................................................................................8

Interface Management and Monitoring...................................................................................................................9

Monitoring and Alerting.......................................................................................................................................9

Data Auditing.....................................................................................................................................................10

Reference Documentation.....................................................................................................................................11

1060 Lake Street Suite 201, Hanover Park, IL 60133 | (630) 701-9030 | www.proschconsulting.com

ConnectR Migration and Patient Linking Project Summary

Project DriversThe purpose of this project is to provide a scalable integration infrastructure that links XYZ Radiology Information Systems with other internal systems, local hospital systems and referring physician groups. Alongside the integration infrastructure, we will support the definition, design, build and test of a just in time patient linking (eMPI) solution. The Patient Linking, solution will start with a ‘clean’ data set and provide a process allowing XYZ to minimize duplication moving forward.

The project definition contained in this document is based on the following understanding of scope:

Build the BizTalk RIS/PACS integration infrastructure to include the following:o Design and build the Microsoft BizTalk Server 2010 environment.o Develop ADT (Demographics) including just-in-time (triggered by order requests) interfaces for

partner hospitals.o Develop Order interfaceso Develop Result interfaces o Develop Charge interfaces o Develop core ‘canonical’ to allow support for multiple EMR’s while minimizing interfaces.

Design, build, test and deploy a Patient Linking solution. Provide training for XYZ Radiology interface creation and management as well as use of the Patient

Linking solution.


ConnectR to BizTalk Migration, Solution Design

Solution SummaryFollowing are the high-level categories for the solution design we plan to implement for XYZ Radiology. This design will allow us to efficiently migrate from a ConnectR to a BizTalk 2010 infrastructure and migrate our interfaces in an efficient manner.

Infrastructure Design Interface Development Interface Management and Monitoring

Infrastructure Design Integration in any medical organization is a mission critical service that is, for the most part, invisible to the end users. It is always expected to “just work” and outages are never acceptable. To that end, we recommend that XYZ Radiology deploy a highly available BizTalk architecture with built-in failover in production.

The diagram included below outlines a scalable infrastructure design that supports this goal. In this diagram we see that multiple BizTalk groups can be deployed to both support high volume HL7 traffic and segment File/FTP/Batch traffic. Clustering with VMs across hosts and SANS is leveraged to provide high-availability. Also depicted is the need for a clearly defined code promotion process for moving interfaces from UAT into production.

Key Points

It is not believed that XYZ message loads require the need for multiple BizTalk Groups at this time. It is likely we will want to start with a combined HL7 and File Group instead of separate Groups.

We assume XYZ will be leveraging VMWare to host all BizTalk, SQL and IIS servers virtually. We assume the use of Microsoft Clustering between 2 BizTalk servers and 2 SQL servers. We assume UAT will be setup to mimic production as closely as possible. Systems Center Operation Manager (SCOM) will be leveraged for production monitoring and alerting.


Server Architecture

Note: Items displayed in grey are not currently planned for the XYZ Phase 1 deployment. They represent future options.


MS Clustering MS Clustering across SANS and data centers will be leveraged to provide needed fault-tolerance and failover. We will institute an inbound/outbound naming convention for host and host instance creation that lends itself well to establishing failover solutions with Microsoft Clustering. Consequentially, we can easily cluster all of our Inbound and Outbound Hosts using 2 IP addresses running on both servers. Should maintenance be required or we have a disaster the Inbound or Outbound Host Instances are simply transferred to the failover server in question.

Clustering Benefits:

Supports application load-balancing functions of BizTalk Allows us to easily manage processes such as Inbound vs. Outbound traffic per host. Addresses the MAC address issues where MLLP traffic can stick to single server in group. Addresses send port issue where multiple messages can be sent more than once (in a multi-server setup). Proper implementation allows failover of both processes to another server

(Disaster recovery) With clustering we can take-down individual servers for maintenance with minimal to no down time.

We will leverage BizTalk’s native ability to spread work around by not clustering our processing hosts. Orchestrations, which are usually paired with processing hosts, ran across the entire cluster.


Interface Development

Prosch HL7 Interface Generator The Prosch HL7 Interface Generator, Visual Studio add-on was created to address two primary needs:

1. Simplicity – BizTalk interface development can be complicated. We wanted to simplify the process so even a Business Analyst can create simple BizTalk hosted HL7 interfaces.

2. Platform – Over the years we have developed best practices around HL7 interface development for the BizTalk platform. We needed a way to consistently deliver our best practices across projects and clients.

Moreover, the default Visual Studio templates delivered with BizTalk only provide the basics and fail to address most of the finer points of interface development. Consequentially, we created the Prosch HL7 Interface Generator Visual Studio add-on to deliver a more usable set of templates. The sequence diagram below outlines a common one-to-many interface workflow we typically need to support.

By leveraging our templates we can quickly and easily create the publisher project (Meditech.ADT) and the subscriber projects (EPIC and Centricity) in one easy to understand Visual Studio solution. Automated logic creates the required subscriptions required by BizTalk as well as required BizTalk artifacts for deployment to BizTalk (i.e. receive and send ports). The end result is creation of a complete interface that can be deployed immediately.

We will leverage the Prosch HL7 Interface Generator to construct and organize interfaces migrated from ConnectR as well as new interfaces.


HL7 Message Family – CanonicalsOne of the challenges with creating HL7 interfaces using the BizTalk HL7 Accelerator is that a unique schema is required for every message type. The ADT message family by itself has over 60 potential message types. Consequentially, setting up an ADT interface in BizTalk can be cumbersome as developers must struggle with mapping and transformations across a lot of message types. The Prosch HL7 Interface Generator Visual Studio add-on includes a set of XML canonical schemas for HL7 Message Families. This is a single schema provided for each message family listed below:

ADT, ORU, ORM, DFT, SIU, MDM, RDE, MFN

The message family schemas work seamlessly with BizTalk and allow us to address all ADT message types as a single entity, for instance. This greatly reduces complexity around mapping and message transformations.

The message family schemas also provide us with a strongly typed canonical message that can be leveraged for publishing to a service bus. The canonical, along with any required metadata, can be posted on your service bus for subscribers to consume. This makes it possible for BizTalk to serve as a SOA on-ramp for your HL7 v2 messaging needs.

We will leverage the HL7 Message Family schemas for all interface work requiring the message families outlined above.

PCC Translation SolutionMany HL7 specific interface engines provide baked-in solutions for transforming data at run time. ConnectR, for instance, allows you to dynamically build virtual tables you can then reference in maps to translate data between 2 different systems. This is also referred to by many people as a cross-walk table.

Out of the box, BizTalk does not provide a native translation solution. It is incumbent on the interface developer to determine how they will manage this process – which is not an easy task.

The PCC Translation BizTalk add-on addresses this need allowing developers to easily translate data in the BizTalk Mapper or from c# class library code. PCC Translation consists of the following components:

SQL database for virtual table creation across any category of information Entity Framework library for easy access to translations from orchestrations or code. Web application for manual entry and editing of data

We will leverage the PCC Translation solution for migration of ConnectR interfaces to BizTalk to host translations currently managed in ConnectR.


Prosch Patient Linking IntegrationThe Prosch Patient Linking application is outside of the scope of this document. However, we will be leveraging this application from BizTalk to trigger Patient Linking requests. We will also field Patient Linking resume or restart messages at BizTalk once a Patient Linking event has been completed.

Medinformatix will be the new Radiology Information System (RIS) at XYZ Radiology where all orders, results and billing activity will ultimately end-up. To that end we will build Patient Linking into any interface that interacts with Medinformatix including:

ADT interfaces – where only results for charges are received ORM interfaces – Orders from internal partners ORU interfaces – Results from Intelerad or external partners

Patient Linking functionality will not be ready at the time initial interface testing is required. Consequentially we will create “stub” logic that will represent Patient Linking until the application is ready. Once ready, we will create a repeatable pattern that can be leveraged across all HL7 interfaces requiring Patient Linking.


Interface Management and Monitoring

Monitoring and Alerting

HL7 Dashboard The HL7 Dashboard for BizTalk add-on allows us to capture HL7 messages processed by BizTalk in SQL Server databases for advanced analysis. We capture Event Log errors and provide a solution for registering business logic errors from orchestrations as well. The dashboard also provides a platform for email notification when specific errors occur using the Dashboard. At XYZ we recommend using the Dashboard, in conjunction with SCOM, to support the following needs:

• Logging of HL7 Messages (and ACK's) to SQL • Advanced HL7 Message Analysis/Troubleshooting • Event Log Error Registration and Troubleshooting • Business Logic Error Registration and Troubleshooting • Email Error Notification

Logging and Analysis Logging HL7 Messages and ACK's to SQL Server is a simple process with the Dashboard. Once the required Pipelines are deployed we only need to activate logging on the interface in question. Once logging is enabled we can then view messages in the Dashboard for Analysis and Troubleshooting. Error Registration and TroubleshootingCapturing Event Log errors on our BizTalk Servers is a simple configuration setting done during installation. Once installed we can view Event Log errors in the Dashboard for troubleshooting. We can also establish notifications for auto alerting when a specific error condition occurs. Capturing business logic errors to the Dashboard is a little more involved but straight forward. Registering business logic errors requires a code update to existing orchestrations but is easily accomplished in our current design. Once implemented, any business logic errors we wish to capture in the interface will be stored in the Dashboard for review, troubleshooting and email notification.

SCOM – Systems Center Operations ManagerSCOM is Microsoft’s flagship datacenter management product. It provides deep visibility into the health, performance and availability of your datacenter environments – across applications, operating systems, hypervisors and hardware – through a single easy to use interface. SCOM also offers easy to use reporting and authoring capabilities to track performance against SLAs.

With the BizTalk Management Pack add-on we can monitor server level and application level stats of BizTalk. This will provide XYZ RADIOLOGY a robust solution for monitoring and alerting specific needs.(http://www.microsoft.com/en-us/server-cloud/system-center/operations-manager.aspx )

BizTalk360BizTalk360 is a new 3rd party application that provides robust monitoring and alerting capabilities. It comes with easy to configure and use proactive monitoring/alerting (email/sms) capabilities and helps avoids the sharp learning curve of setting up and using traditional monitoring systems like SCOM, HP OpenView etc.

BizTalk360 may be a good option for XYZ RADIOLOGY and is worth consideration as we move forward (http://www.biztalk360.com)


http://www.biztalk360.com/

http://www.microsoft.com/en-us/server-cloud/system-center/operations-manager.aspx

Data Auditing

HL7 Dashboard The HL7 Dashboard for BizTalk (Dashboard) includes a set of enhanced pipelines that allow us to collect raw HL7 v2 messages inbound and outbound at BizTalk. We take the raw messages and promote them to a semi-normalized data store (PCC_HL7DataMart). By default we automatically break down all of the fields in the HL7 message into separate tables and columns in the database. Tables exist for every HL7 segment type (i.e. MHS, PID, PV1, etc.) and columns for level 1 data. We also can store the entire message in its original format. This is useful for auditing purposes where it is necessary present the original unaltered messages.

We also provide XML pipelines that allow auditing of XML data (non HL7) into the database. However, XML data is not broken down into individual columns. These databases serve as the basis for our HL7 Dashboard for BizTalk allowing us to provide advanced search functions across any HL7 message that has traversed the interface engine. The databases also serve as a starting point for delivering more advanced Business Intelligence capabilities. All medical data within your environment will ultimately pass through an interface engine.

As we have already stored that data, it only becomes a matter of deciding what you would like to do with it next. Data aggregation to SQL cubes, existing data warehouses or even into Microsoft Amalga are all possible. We recommend a detailed analysis of current reporting needs at XYZ with an eye on how we can leverage this newly captured data.


Reference Documentation

Future State Diagrams - Phase 1.vsd JR BizTalk_2010_Planning_Setup_Prep.xls Interface Mapping Documents

o To Be Created


ConnectR Migration and Patient Linking Project … · Web viewData Auditing10 Reference...

Documents

Transcript of ConnectR Migration and Patient Linking Project … · Web viewData Auditing10 Reference...