Hospital Mergers and Cloverleaf

[Robert Milfajt]

Given the current trend in healthcare where organizations are merging or being bought out, and the need to integrate more and more systems, I’m wondering if there are any tips or tricks out there for very large Cloverleaf interface configurations.  Our current environment consists of three organiztions merged under one umbrella.  It’s pretty clear to me that putting everything in one Cloverleaf production site, is probably not a good idea because of volumes, and the risk of using a single recovery database.

In deciding how to split among different servers, sites, processes, etc., I’d like to hear how others who have faced and addressed these types of problems have responded.

Our current environment is 6.0 on AIX 6.1.  Our current thinking is to keep on single AIX virtual server and create multiple sites based on data content, i.e., ADT, results, EDI, etc., in order to reduce the risk of having everything process through a single recovery database.  This design is predicated on the fact that registration and billing will be consolodating to a single system.  Also with a pending future merger with another large healthcare organization (who also uses Cloverleaf), I’d like to position our environment to be prepared for this.

I’m also wondering the strengths and weaknesses using intersite communication vs. dedicated TCP connections via localhost.

Any guidance anyone can give will be greatly appreciated.

Thanks,

Bob

Robert Milfajt
Northwestern Medicine
Chicago, IL

Topic

[James Cobane]

Robert,

There are probably infinite ways to break things up, and really comes down to what makes sense for your organization.

[Jeff Dinsmore]

Generally, for performance, more sites are better.  Unless you have some sort of global monitor, it’s not as nice to look at, but, at some point, you will need multiple sites.

We’ve built sites based mostly on department – Lab, Cardiology, Imaging, etc.  In some cases, due to volume of interfaces, we’ll have a site dedicated to a single system – like for our Paragon EMR – due to the number of in/outbounds to that system.

For the most part, inbound threads receive messages and distribute to outbound pool threads (a term shamelessly stolen from Corepoint) via localhost connections.  All processing of messages is done in the outbound pools before sending outbound on the destination threads.

Like Mr Cobane said, there are certainly many good options – and the discussions about what’s “best” can be very spirited…  

The best for you is dependent on your environment and skill set.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Author]

Replies