Holding a message

[Scott Rush]

Has anyone ever had a situation where the disposition of the current message is predicated on the next message?

The Epic tech wants me to put logic in such that if the next message ORC-1 is NW, then both messages should be killed.

I’m not sure the best way to tackle this problem.

Any ideas are welcome.

Topic

[William Rowley]

This probably not the exact help you’re looking for but…

I would sit down with the two vendors and show/explain the way an HL7 order conversation should work per the standard. Then send them back to their desks to correct their interface so the engine does not need to base the handling of an asynchronous message on the values/contents of another asychronous message (that may never come) or refund the money paid for the non-compliant interface.

But that’s just my opinion – I could be wrong.

[Scott Rush]

No argument here, but Epic can’t prevent this from happening in their system.

I guess moving to Epic did not solve ALL our problems.  😉

(Sarcasm)

[Jeff Dinsmore]

It’s definitely possible to hold messages and process them based on other messages – put them in a DB or file and process them later – but I would also wonder why.

Can you explain the case you’re talking about in more detail?  If we know more, perhaps we can offer some solutions.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Mark Thompson]

Scott,

I have seen this done at least 3 ways depending on the impact of loosing the message and the skill sets of the implementer.  A moderate level of Tcl skill is required for all of them.

1. Copy the message to global (or namespace) memory and clear it when the next message comes through.  Pros: Very fast and effecient.  Cons: Message disappears if you crash the engine process.  Potential for memory leaks if not well coded.

2. Save the message in a database.  Pros: Moderately fast.  Cons: Message may disappear if you corrupt the database.

3. Save the message in a file.  Pros: Message is as secure as your operating system’s file system processing.  May be able to use fileset/local threads to reduce Tcl coding.  Cons: Slowest of the options considered.  Messasge may disappear if your file system gets corrupted, but at that point loosing 1 message won’t be your biggest concern.

I’m sure others can expand the list of pros and cons for any of these options.  I have personally implemented #1 & #3.  Option #2 seems to be the most common choice among CloverTechies during recent discussions.

Your best option is always to push vendors to follow standard HL7 functionality.  If they get the acceptance sign-off there is little incentive to go back and make it work correctly.  If they fix it now, it will also work correctly for their future clients – who could be one of us.

- Mark Thompson
HealthPartners

[Kevin Kinnell]

Scott —

You can also push a little higher into the Epic interface technical support.  A lot of newer interface TS’s don’t really get it, and their programming experience is limited to what is essentially a MUMPS networked database.

The higher level understands that an engine doesn’t automatically save messages for future use.  They aren’t astonished by it, and usually have some experience with other solutions.

[Scott Rush]

Thanks everyone!

I did it via a file yesterday.

Epic is good at presenting to upper management before pulling me or any of our techs in so there is no questioning of their solutions when there is high visibility and a gap.

I just do it rather than try and change the direction when it has gotten so far down the rails … and Epic knows it.

I hear ya about some of these Epic kids.

I wonder if their mamas know they are “playing” adult.  😉

The turn over at Epic is astonishing!

Epic doesn’t solve everything.

It is not the end all, be all.

Ha ha  … just had to say that to a forum where people would understand.

[Brandon Grudt]

Scott Rush wrote:

Epic doesn’t solve everything.

It is not the end all, be all.

Ha ha

[Kevin Kinnell]

😈

[Mike Strout]

I am dealing with a similar issue with Epic message flow, where I need to kill a message based on the contents of the previous message. I thought about throwing the message into a file and just comparing it to the subsequent message, but this would cause about 24,000 file reads and about 16,000 file writes to this file daily. It seems it would be way more efficient to just throw this file in memory.

I don’t care if I lose what is in memory on a process or server shutdown. The script is just for optimizing the ADT feed. Worst case is a few messages would go through that didn’t need to.

Does someone have a code snippet that would demonstrate how to write and read global variables? There isn’t much in the Cloverleaf docs.

[Kevin Kinnell]

Mike,

Set up your globals when the process starts and access them during the run phase.  I don’t have any code left anymore, but I used to do this in 5.3 with a small list.  It was essentially a very short list of provider ids I needed to screen out of a thread, but I couldn’t justify loading it every time the proc was run, small or not.

How big a chunk of memory are you talking about?  If you are screening ADT based on duplication, Epic can be set to kill duplicates that are sent in a short time span.

[Steve Pringle]

Mike – (with apologies to all if I’m hijacking this thread) –

I’m curious as to why you need to go to such lengths to optimize the ADT feed.  We just finished implementing Epic Ambulatory and we’re starting to implement Epic Enterprise.  We didn’t run into any ADT issues with Epic Ambulatory.

On another note, and perhaps we’re the exception, but our Epic interface counterparts have been top notch technically.

thanks,

Steve

[Terry Kellum]

Slightly different situation, but I have an issue where “John Doe” registrations suddenly become the real person at a point after initial registration.  The downstream system that I support has safety built into the process where if 2 or more demographic elements change, it drops the transaction and doesn’t apply the changes.  This is a good thing, with the exception of the “John/Jane Doe” situation.

I’ve solved this use case by logging the John or Jane into an SQLite database table.  Every time John or Jane hits, it’s checked against that table.  Every trans is checked against the patient account number.  If the patient account number hits, the process feeds multiple A08s, each changing a single demographic element, until the full “correct” record has been transmitted, with removal of the John Doe record from the table.

The nice thing about Cloverleaf is that you control both the horizontal and the vertical.  That then leaves you with the pure dilemma to decide if you SHOULD do “a thing”.

[Author]

Replies