New post
Question
· Jan 24, 2017

LUT table maintenance impacts HL7 message processing

#HL7 #HealthShare

Performing LUT table maintenance through Portal impacted Business Service HL7 message processing for one of our inbound feeds causing a message to fail.  We are on Healthshare 2014.1.3.  Is this a known issue, or is there a right way to modify table?

Discussion (3)1
Log in or sign up to continue
John Murray · Jan 26, 2017

What is the nature of the failure?

Perhaps when you save your LUT changes there's a small time window during which no LUT entries exist. This is pure speculation on my part, as I haven't investigated. But if it's true then I can imagine this could cause problems in the production. In which case, perhaps you need to suspend at least the relevant parts while you save the change.

0 0
Sandy Dessecker · Feb 6, 2017

The nature of the failure is thru a Business Routing rule that executes custom code to check if an HL7 field is in a Lookup table ( if ##class(Ens.Util.FunctionSet).Exists("Client",tHL7FieldValue)) - the value was there but it could not find it.  At the same time, I was accessing that same table and deleting non-related entries thru the Portal via Ensemble > Lookup Tables.  I would assume the Exists function should be able to do a read on the table even if there is a lock on it due to maintenance.  Is that not how Lookup table behave?

0 0
John Murray · Feb 7, 2017

Based on my reading of 2014.1 code the Exists method in Ens.Util.FunctionSet doesn't check locks when testing for the existence of the entry.

I think the Save button from Portal leads to the SaveLookupTable method of EnsPortal.LookupSettings. That method obtains an exclusive lock on the subtree of ^Ens.LookupTable where the LUT gets stored. It then kills the entire LUT and re-files each entry one by one. Once finished it releases the lock.

All of that is protected by a TSTART / TCOMMIT but this is not sufficient to prevent another process momentarily detecting the absence of an entry that would normally exist.

0 0