site design

[David Ma]

We are implementing Epic in our hospitals and we are going to redesign our sites in Cloverleaf Engine.

we are thinking about two options:

1. Site by applications such as Radiology site, Cardiology Site, Lab ste….

2. Site by message type such as Order Site, Results site, …..

What do you have now and what are your suggestions?

Thanks!

David

Topic

[Jim Kosloskey]

David,

We have a basic distribution/delivery site architecture.

So for say a given system or type of message set (nothing says you acn’t have a mix) we would have a ‘distribution’ site. That site simply raw routes everything to other sites (‘delivery’ sites) where the messags ar filterred, Xlated, etc. and then delivered to destinations. There is more to it than that but for the sake of brevity that should give you a sense.

We have found this architecture to be very useful for a number of reasons not the least of which is to balance the workload out as needed.

Also (and I think this could be important with Epic – we may find out soon) the messages do not queue up in the site that receives the messages from the sending system. Thus the danger of backing up the sending system is relieved.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Peter Heggie]

We are moving to this type of configuration as well, for the same reasons, especially to prevent backing up the sending side if the Cloverleaf side is down for any reason. If we are updating translators, filters, etc., we want to be able to recycle our main input process without affecting the sending HIS system. By putting the ‘HIS receiver threads’ in a separate site, and then connecting them via tcp/ip to a ‘distribution site’ thread, we can feel free to recycle our distribution site processes, to roll in changes, without impacting the HIS.

Also, and this is not related to EPIC, our HIS is a mainframe system (Invision) and there is EBCDIC to ASCII conversion and application protocol conversion and handshaking that must take place. We will be doing these activities in the ‘receiving site’, and then can send ‘normal’ ASCII messages to our distribution side.

Our current configuration has our main HIS receive thread also functioning as the main distribution thread, with about 80 route detail entries going to all our ancillaries. This receive thread has SNA protocol and the above mentioned tcls to do the handshaking and application protocols.

We currently have an unresolved issue where we cannot use the Smat file or NetMonitor resend function for this thread. The resend seems to work and we see the message in the process log, but no messages are sent. We think it is because of the encoding of the message in the smat file or file created from the Error DB is not what is expected by the resend function, combined with the inbound proc tcls that perform some of the conversion and application handshaking.

So by separating the handshaking and conversion stuff into a ‘receiving site’ and keeping the distribution and normal translation activities into a ‘distribution’ site, we simplify maintenance, communication and are able to use the resend function normally in the distribution site.

Peter Heggie

[Author]

Replies