· Jan 24, 2017

LUT table maintenance impacts HL7 message processing

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

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.

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?

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.