Pages

Monday, September 22, 2014

Last weekend, in a supposedly social situation, I happened to run into a clinical pathologist and talk turned naturally to clinical lab informatics. (Yes, the rest of the table was pretty uninterested.)

This CP mentioned that his organization is in the early stages of processing clinical lab orders. This is a great idea, but depressingly infrequent. This is a great idea because:

There are some orders which cannot be done (incorrect collection, eg) or will not be done (policy violation, eg) and the sooner you tell the ordering clinician that, the sooner they can do whatever makes sense.

The earlier you flag a doomed order, the cheaper and easier it is to handle it. Why waste precious human attention in the lab if a rule set can do the job so much faster and just as effectively?

I have lots of free advice--worth every penny, as they say--to offer on the tchnical implementation of these kinds of schemes. However, we were not able to cover the implementation advice in a social setting, much to every one else's undoubted relief. So instead I thought that I would pound out this blog post and send him a link.

What exactly are we talking about? Let us consider the usual life-cycle of the lab order:

We are talking about adding a step to item 2 (Order interface) in between 2.1 and 2.2. Let us call this step "validate order". In practical terms we are talking about a relatively simple piece of software which applies rules to the HIS order to ensure that the order can be processed.

Conceptually, this software is *VERY* similar to the typical auto-verification module which applies rules to the raw lab result to ensure that the result can be reported.

When an order fails the pass the rules, it is cancelled and a comment added "Cancelled per lab policy: {explanation or link to explanation}".

Since a "hard stop" on clinician's practice of medicine makes everybody nervous, we usually start with the encoding lab policy in the rule set: if the lab is not going to the test anyway, there can be no harm in rejecting the order.

Since implementation is never flawless, we start out with "advisory mode': the module flags orders it _would_ cancel, so a lab tech can confirm that the logic is working. It is a good idea to have an advisory period for every new rule and to audit some percentage on an on-going basis.

So the enhanced model looks like this:

HIS

clinician logs into an HIS

clinician identifies a patient

clinician specifies one or more lab tests

clinician submits the order to the LIS

HIS generates a lab order

Order Interface

accepts order from HIS

validate order

order OK: sends HIS order to the LIS

order failed: cancel with explanation

LIS

LIS receives the order

specimen is collected

lab receives the specimen

specimen is prepped if need be

assay is run

result is verified & posts to the LIS

result leaves the LIS, en route to HIS

Result Interface

accepts result from LIS

sends result to the HIS

HIS (full circle:

clinician sees result, is enlightened

Done correctly, this technique saves the lab time, it gives the clinician feedback that is both speedy and educational and avoids unneeded collection events.

"Correctly" probably requires knowing the leading causes of cancellation and tracking causes of cancellation and confirming that as you add rules, you cut down on the manual cancellations.

There it is: how best to roll out this kind of thing, in my experience.