Monday, September 22, 2014

Advice For Pre-processing Lab Orders

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:

(HIS=Hospital Information System; EMR=Electronic Medical Record; LIS=Laboratory Information System)

  1. HIS
    1. clinician logs into an HIS
    2. clinician identifies a patient
    3. clinician specifies one or more lab tests
    4. clinician submits the order to the LIS
    5. HIS generates a lab order
  2. Order Interface
    1. accepts order from HIS
    2. sends HIS order to the LIS
  3. LIS
    1. LIS receives the order
    2. specimen is collected
    3. lab receives the specimen
    4. specimen is prepped if need be
    5. assay is run
    6. result is verified & posts to the LIS
    7. result leaves the LIS, en route to HIS
  4. Result Interface
    1. accepts result from LIS
    2. sends result to the HIS
  5. HIS (full circle:
    1. clinician sees result, is enlightened
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:

  1. HIS
    1. clinician logs into an HIS
    2. clinician identifies a patient
    3. clinician specifies one or more lab tests
    4. clinician submits the order to the LIS
    5. HIS generates a lab order
  2. Order Interface
    1. accepts order from HIS
    2. validate order
      1. order OK: sends HIS order to the LIS
      2. order failed: cancel with explanation
  3. LIS
    1. LIS receives the order
    2. specimen is collected
    3. lab receives the specimen
    4. specimen is prepped if need be
    5. assay is run
    6. result is verified & posts to the LIS
    7. result leaves the LIS, en route to HIS
  4. Result Interface
    1. accepts result from LIS
    2. sends result to the HIS
  5. HIS (full circle:
    1. 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.

No comments:

Post a Comment