1 / 39

INT406: Healthcare Integration: Building a community EMR

INT406: Healthcare Integration: Building a community EMR. James Russell Senior Systems Analyst jrussell@mhc.net August 15-19, 2004. Introduction. James Russell (Senior Systems Analyst) Munson Healthcare Information Systems Clinical Applications Department

keelia
Download Presentation

INT406: Healthcare Integration: Building a community EMR

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. INT406: Healthcare Integration: Building a community EMR James Russell Senior Systems Analyst jrussell@mhc.net August 15-19, 2004

  2. Introduction • James Russell (Senior Systems Analyst) • Munson Healthcare Information Systems • Clinical Applications Department • Member of Munson IS Interface Team since 1998. • Senior member of Interface Team. • Lead implementation teams for multiple interfaces projects. • Currently Implementing bi-directional PFT interface to Munson EMR • Munson IS Interface Team (Impact 5.4 Migration Team) • Migration design by Jim Bailey and Jim Whall at Munson Medical Center. • Implementation by Jim Bailey, Jim Whall, James Russell, Jim Hsu and Justin Willoughby at Munson Medical Center.

  3. Introduction • Munson Healthcare • A regional healthcare provider serving 24 counties of northwest lower Michigan and the eastern Upper Peninsula of Michigan. • Operating 6 community hospitals, with management agreements and partnerships with many others. • 460 Acute care beds in the system.

  4. Community

  5. Introduction • Patients • 26,000 Inpatients visits per year • 40,000 Emergency visits per year • 1,900 Births per year • 17,800 Surgeries per year • 160,000 Outpatient services (Radiology, Cardiology etc…) • 1.8 Million laboratory services

  6. Introduction • Accolades • Munson Medical Center has been named a Distinguished Hospital, ranking it in the top 3.4% for overall Clinical Excellence (HealthGrades 2004). • Munson Medical Center's cardiac program is rated as the #1 heart program in Michigan for 2004 (HealthGrades). Munson received top five-star ratings in every category of Cardiac Care. The ratings are based on evaluations of actual patient outcomes. • Munson Healthcare was awarded with the 2003 Public Health Partnership Award from the Michigan Association for Local Public Health (MALPH). • Named one of the nation’s Top 100 Hospitals in recognition of superior clinical and operational performance in 1993, 1997, 1998, 1999, 2000, and 2001. • Munson Medical Center is the only hospital in Michigan to be honored as a Top 100 Hospital six times – a distinction it shares with only eight other hospitals in the country. • Named one of the nation’s Top 100 Cardiovascular Hospitals for superior clinical and operational performance in 1998, 1999, and 2000. • Sole recipient of the National Quality Health Care Award for 2000. • Named one of the nation’s Top 100 Orthopedic Hospitals for superior clinical and operational performance in 2000. • As a result of a consistent record of excellence, Munson was presented Solucient’s 100 Top Hospitals: Benchmarks for Success Award – the Best of the Benchmark Hospitals. This award is reserved for hospitals that have set national benchmarks for overall performance in their respective hospital categories four or more times.

  7. Munson Healthcare EMR • Munson Healthcare has chosen to meet the challenge of serving the healthcare needs of people that are geographically separated by hundreds of miles by building a regional healthcare record in which hospitals, clinics, laboratories and private practice physicians share clinical data to improve patient outcomes and improve the overall healthcare delivery to the community.

  8. Munson Healthcare EMR Integration

  9. Integration Design • Integration Environment • Cluster/SFM Design Criteria • Alerts and Triggers • Standardization • Flexibility

  10. Integration Environment • Using Sybase Impact 5.4 • Running on 2 HPUX (RP5470) servers • Process 450,000 HL7 messages a day (production only) • Messages are received from 27 endpoints • Messages are delivered to 39 endpoints • 10 Clusters in production • 13 SFM’s in production • 5 Clusters with remote controller delivery to another cluster • 10 Test Clusters with 15 SFM’s

  11. Integration Environment

  12. Integration Environment • Server Resource monitoring

  13. Integration Cluster Design • Criteria for Cluster design • Interface groupings • Business use • Volume of transactions • Transaction Type (ADT, Results, Orders) • Level of priority • Modularity/Isolation • Example: • Currently routing ADT transactions to 18 separate applications through six different SFMs using a routing cluster.

  14. Integration Cluster Design • Defined Clusters • Cluster 1 – ADT Router • Cluster 2 – Powerchart ADT • Cluster 3 – Lab • Cluster 4 – Radiology • Cluster 5 – Miscellaneous Powerchart Feeds (Transcription) • Cluster 6 – Scheduling/Pharmacy • Cluster 7 – Miscellaneous ADT Destinations • Cluster 8 – Charges/Misc • Cluster 9 – Send to SFM • Cluster 10 – INet

  15. Integration Cluster Design • Cluster1-“Router” • We use Cluster 1 as a “router” cluster. • Takes ADT messages from a high volume HL7 version 2.2 source and distributes them to various SFMs using remote controllers. • Isolates delivery so maintenance on one ADT delivery does not effect other deliveries.

  16. Integration Cluster Design • Cluster2-”High Volume” • Cluster 2 is a high volume, high priority, critical delivery. • Receives ADT from the router and delivers to the hospital EMR (Cerner’s Powerchart).

  17. Integration Cluster Design • Cluster3-”Lab” • Cluster 3 handles most of the lab transactions. • ADT from the router. • Orders to/from Powerchart and Sunquest Lab. • Results to Powerchart. • Charges to HBOC/Star • Results to SFM8_1_Other • Test remote controller when needed.

  18. Integration Cluster Design • Cluster4-”Radiology” • Cluster 4 handles radiology messages. • Orders to/from Star Radiology and Powerchart • Results to Powerchart • Results to SFM8_1_Other • Results to test if needed

  19. Integration Cluster Design • Cluster5-”OCFMisc” • Cluster 5 handles miscellaneous messages for Powerchart • EKG, transcription, post-op reports, labs and ADT from various systems are delivered to Powerchart. • Test remote controller if needed

  20. Integration Cluster Design • Cluster6 • Cluster 6 has Encompass Scheduling and Pyxis messages • ADT and scheduling messages to/from HBOC Star/Encompass • ADT and orders to Pyxis • Charges from Pyxis to HBOC Star

  21. Integration Design • Cluster7 • Cluster 7 is a miscellaneous ADT cluster • ADT to TV billing, switchboard, OB, OR scheduling, Mercy Pharmacy and the State of Michigan • ADT to 4 different transcription systems and Urgent Care Rx system • ADT to Occ Health, Nurse scheduling, Patient tracking, non-Invasive Cardiology and to Brooks rehab

  22. Integration Cluster Design • Cluster8 • Cluster 8 handles “other” and charge messages • ADT, Mammography results, Rad results and Lab results to Crystal Lake Clinic and Mitra (PACS) and HBOC Star • Charges from Powerchart, OR, Pyxis, Mercy Pharmacy and Lab to HBOC Star

  23. Integration Cluster Design • Cluster9 • Cluster 9 is used by Interface Analysts to send or re-send messages manually • Has Acq Aims to parse flat files for delivery to any SFM • Provides utility for doing history loads to applications.

  24. Integration Cluster Design • Cluster10-”INET” • Cluster 10 handles all BMDI messages from the critical care beds • Bedside medical device messages are send to Powerchart every minute for patients in ICU, CCU, CTU and NICU

  25. Integration Triggers and Alerts

  26. Integration Triggers/Alerts • Communication Triggers • Loss of Connection • Timeout on ACK • Inactivity Monitoring • Connection reestablishment • Error in transaction processing • Production Object Triggers • Missing Information • Changed Data • Badly formatted transactions • Incorrect Information • Transaction Type

  27. AIM Design • Standard aim templates. • AIM.cfg File • Configure alert triggers based on needs • Inactivity timers • Loss of communication • Transaction errors • Configure type of Communication • E-Mail • Paging • Error logging • The configuration file allows flexibility in aim performance.

  28. Common AIM parameters static string Send_Email = "n"; static string Send_Page = "n"; static string Email_Address = "iegroup"; static string Pager_Number = "3182817"; static string System_Name = "Sunquest Inbound ADT and Orders";

  29. Common Acq AIM Parameters static int Listen_Timeout =120; static int Retry_Delay = 20; static string Inactivity_Monitoring = "n"; static int Inactivity_Interval = 300; static string Route_Type = "route_veng"; static int Flav = 1003; static string Tran_ID = "sunquest_to_all"; static int Max_Unrouteables = 20; static string Send_NAK = "n";

  30. Common Del AIM Parameters static int Startup_Connection_Retry_Interval = 30; static int Startup_No_Connection_Alert_Trigger = 10; static int Connection_Retry_Interval = 30; static int Connection_Retry_Alert_Trigger = 10; static int Response_Timeout = 25; static int Response_Timeout_Alert_Trigger = 3; static string Send_Email_AR_Ack = "y"; static string Send_Page_AR_Ack = "y"; static string Send_Email_AE_Ack = "y"; static string Send_Page_AE_Ack = "y";

  31. Inactivity Monitoring static int wkdaymon[24] = { 15, 30, 30, 30, 45, 30, 15, 10, 5, 3, 3, 3, 3, 3, 3, 3, 3, 5, 10, 10, 15, 15, 15, 15}; /* ---------------------------------------------------------------------------------------------- 00| 01| 02| 03| 04| 05| 06| 07| 08| 09| 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23| -----------------------------------------Weekday Hours ----------------------------------------*/ * Weekend in minutes - Do not enter leading zeros * static int wkendmon[24] = { 30, 60, 60, 60, 60, 60, 45, 30, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 30, 30, 30, 30, 30, 30}; /* ---------------------------------------------------------------------------------------------- 00| 01| 02| 03| 04| 05| 06| 07| 08| 09| 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23| ---------------------------------------- Weekend Hours ----------------------------------------*/

  32. Standardization • AIM Design • All development begins with or uses the same template. • Email Alerts • Who wants an alert? • Tables • Source of truth? • Transcribed Reports Format • Output driven • Rtf format • Message Type • What event code do we send?

  33. Flexibility • Custom AIMs • TCP/IP connections • FTP connections • Production Objects • Conversion of single transaction into multiple transactions • (Example: Star ADT to Sunquest A36 trxn converted to A36,A31,A08) • Capture A17 transactions and convert to two A02 transactions. • Email MPI coordinator if a transcribed report is moved to a different patient. • Convert flat file fixed field data to HL7 format. • “route_veng”

  34. Challenges • Integrating nine transcription feeds • We have nine source feeds for transcribed results. • Radiology, EKG, microbiology, mammography, transcription. • Transcription • One source location uses both MS-DOS and windows as the transcription app. • Two others are for the Mercy Hospital locations (one for has only in-house transcription, and the other uses a outsourced service as well as in-house transcription). • All four source locations transmit reports differently. • All four need to have a consistent look & feel and interface in a standard way to the EMR. • Converting HL7 format to .Rtf. • Retrieving documents via ftp. • Banner Messages • Medical Records Publishing • Changes everything. • Outside ADT Sources. • Non compliant HL7 interface applications

  35. Challenges • Communications Challenges • As we have multiple facilities, many of the interface servers are not located with the application they are interfacing, or if they are located with the application they are not located near our data center. • T1/T3/G3 issues often interfere with communications (outside of our control). • “Off-site” interface boxes are at risk from remote network issues, uncontrolled vendor access and site maintenance. • We also have many interfaces that communicate vi VPN for security reasons. Sometimes this can cause troubleshooting problems a the VPNs are not under our control. • Interdepartmental Systems • Some departments (radiology and laboratory) refuse to fold their systems into IS and therefore administer their own systems, sometimes causing issues with maintenance, downtime and communications with regard to change control.

  36. Challenges (Change Control) Usage: clcontrol [-s|-k|-r] -n [Cluster Name] (-b [cluster cfg location]) Usage: clcontrol -d ([deploy directory]) -n [Cluster Name] (-b [cluster cfg location]) Usage: clcontrol -h ([harvest directory]) -n [Cluster Name] (-b [cluster cfg location]) Version: 2.0.0 - 04/19/2004 -s Start Cluster -k Kill/Stop Cluster -r Restart Cluster (stop & start Cluster) -d Deploy Cluster -h Harvest Cluster -n Cluster Name is the name of the Cluster e.g. Cluster2, Clustera, etc. Optional: -? Help -v Verbose Output -f When stopping (killing) the cluster, do not prompt for confirmation -b Base Location of Cluster Configuration Files Relative to /ifpkg/iftest/Impact if different than clusters/ -d [dir] Base Location to deploy cluster Configuration Files from Relative to /ifpkg/iftest/Impact if different than deploy/ -h [dir] Base Location to put harvest Configuration Files Relative /ifpkg/iftest/Impact to if different than harvest/ • Always Harvest and Deploy. • Clcontrol Script. • Cannot Harvest without Deploying first • Archive directories

  37. Conclusion • It works • Sybase Impact 5.3/5.4 gives us the flexibility and power we need to integrate several geographically and technically diverse systems into a regional community health record for our community. • To power to handle large volume feeds. • The flexibility to customize feeds to meet the diverse needs and “standardize” messages across multiple vendors. • Robust alerting and error trapping abilities to address interface and not interface issues, before they impact the user community.

  38. Future Goals • Collapse Alert Paths • A single delivery/acquisition AIM • Improves SFM to SFM using Del/Acq AIM • Citrix Metaframe implementation • Holiday Inactivity Monitoring • Message Count Analysis • Windows Application for Sending Transactions

  39. Questions?

More Related