Why Is Merging Test Catalogs So Hard?

It is FAQ Wednesday, when I take a FAQ off the pile and address it.

Today's frequently asked question is "why is merging test catalogs so hard?"

This question fits O'Flaherty's first law of applied technology: "It is usually not the technology that takes the time."

This question arises in a number of contexts:

• Lab Manuals across organization (eg hospital systems)
• Lab Manuals across labs (eg main lab and satellite lab)
• Ref lab interfaces (order from one catalog, process from another)
• Historical data archives (showing results from a previous catalog)

The answer is always the same: assumptions and comparisons.

When considering a lab result, there is a huge amount of assumed context:

1. the collection method sometimes matters, sometimes does not;
2. the methodology sometimes matters, sometimes does not;
3. the actual value sometimes matters, sometime only the High / Normal / Low flag;
4. having a basis of comparison to prior results sometimes matters and sometimes does not

Take Vitamin D levels for example: there are a couple of ways to measure it (methodology) which vary in exactly what they measure and how accurately they measure it. If you are a specialist, these differences may be very important. If you are a generalist, these differences may be meaningless to you. If you are trying to provide historical context by evaluating a series of these results, you almost certainly assume that the methodology was constant, which ever methodology was used.

The problem arises when catalog A only has "Vitamin D" and catolog B has "Vitamin D (the cool one)" and "Vitamin D (the usual one)". How do work across the catalogs?

There is always renaming to enforce consistency, but that is not straightforward and it is often politically charged: someone wins and someone loses. Furthermore, changing the name of a test is problematic: should the clinician infer that the assay has changed somehow? If so, how?

There is add new tests to enforce consistency, but is also a qualified success: what if the new test is essentially the same as the old one? How does the clinician know that, how does the software which displays the results know that these two "different" tests are the same lab assay?

Worse, making these decisions requires many different skill sets: clinical, lab and data modelling. So why is merging test catalogs so hard: because there is so much to it and so much of it is not immediately apparent. Hello, Titantic, meet Ice Berg.

"Lab Man" Is Too Vague

We recently were asked to fix a specific instance of a general Lab Man issue. Again.

The specific instance was providing phlebotomists with collection information.

The general issue is trying to make a "Lab Man" that is all things to all people.

I say that "Lab Man" is too vague because according to my observation, it refers to any of these options:

A Test Menu, from which clinicians select clinical tests to be done. This is all about ordering, so it includes helping a clinician figure out which tests to order, in addition to simply what code to use.

A Collection Manual, which gives the phelbotomist or nurse or lab tech information about how to collect, store and transport the specimen.

A Processing Manual, which gives a bench tech guidance about how to prepare and processing the specimen.

A Result Interpretation Reference to which clinicians can turn for help in understanding the clinical significance of a given result.

Sadly, many of our clients feel that this model "makes things too complicated" and that a single format will somehow handle all these functions. "Why do you make things complicated by having different formats and different documents?" we often hear from the Lab Man Committee. But to the Medical Director, "Lab Man" means one thing, to the Lab Manager "Lab Man" means another thing and to Outreach Coordinator "Lab Man" means yet another thing.

Strangely, few members of the committee dispute that clinicians don't want to wade through collection instructions when trying to figure out the significance of a result. Drawers don't want to browse a catalogue, they just want to go straight to the pre-selected assay on the order. Bench techs only rarely care about the clinical research supporting the use of a particular assay for a particular medical history; instead, they want the preparation and processing instructions as quickly as possible.

One of our clients has a fab new HIS (Epic) which they want to use as much as possible outside the lab. They did not want to complicate things, so their Lab Man is a Test Menu/Result Interpretation Reference hybrid. This hybrid format works for doctors. But it does not work for drawers (nurses and PAs and phlebotomists) who are also "outside the lab." No Collection Manual for them.

Collecting without a Collection Manual is not working out very well, so I proposed the following: let the web site choose the format based on the incoming user ID. Or based on the IP (we can tell internal from external and we can tell which external IPs are actually draw stations.)

Context is everything, and these days context-sensitivity is often pretty easy to provide, so why not take advantage?

Update Thursday, December 5, 2013
Client has decided to go with a hard-to-find second link on their HIS, in the hope that (a) drawers can find the Collection Manual link and (b) clinicians cannot find the Collection Manual link. Good luck to them, say I.

Ordering Off The Menu

Today we start implementing our solution for a universal lab problem: ordering off the menu. In other words, supporting orders for tests which your lab can either do, or send out, but which are not common enough to merit a test definition and/or an entry in your Lab Manual.

(In the trenches, we know that the explosion of possible assays will likely always outstrip the ability of labs to define tests and to maintain their Lab Manual, but the "not common enough" party line is so much more palatable to management that we use it as a courtesy to our clients.)

A truly useful test definition has the following aspects:

1. an LIS definition to facilitate processing
2. documentation, ideally in the external Lab Man
1. what the test is called
2. how to order it
3. why order it
4. when it is done
3. documentation, hopefully in an internal Lab Man
1. collection instructions
2. handling & preparation instructions
3. processing instructions 
4. a billing definition to facilitate billing

An uncommon or new test might have to do without item 1 above for a while, because LIS test definitions are often complicated to do, difficult to validate and scarey to release.

More awkwardly, it is usually difficult to collaborate on test definitions in an LIS, although the ordering information make come from a Medical Director, the collection & handling instruction from the Front Bench and the processing instructions from the Lab Supervisor. Usually the LIS only provides good tools for the processing instructions since those are near and dear to LIS developers' hearts.

But when the lab falls too far behind in documenting new or uncommon assays, they make work for themselves when orders for these tests arrive. And this work is at every stop along the way: Customer Service to answer questions about ordering, the Front Bench to deal with miscollected or mishandled specimens, the Processing Bench to try to do the assay on whatever was collected, etc.

So we are providing a technological stepping-stone: what we call a pre-LIS test definition. We created a system to do the following:

• attach different names to the MISC code
• these looks like different tests to the users for ordering & processing
• but these look like a MISC to the LIS for reporting
• allow different users to enter different parts of the pre-LIS
• include that information in the internal Lab Man
• include that information in the external Lab Man
• when the pre-LIS test definition is ready
• automatically create an internal Lab task to build the test definition
• automatically send information to Billing to request billing codes, etc

We feel that this is the best of both worlds: a rapid, easy-to-edit visible test definition that supports, rather than usurps, building LIS test definitions.

Laboratory Manual for SoftLab

The client has a shiny new SoftLab installation from SCC. What they do not have is an automatically generated Laboratory Manual (LM) to go with their new test definitions.

They want to use their SoftLab test definitions, so far as they go, because the LIS's test definitions are what is actually in use.

But they need more attributes to create a fully features LM and they do not want to create this HTML document by hand or with a Content Management System because they want the LIS test attributes refreshed automatically every night and new LM generated early every morning.

Furthermore, they want an internal version, containing internal processing notes and procedures, and an external version, without internal material and including contact information, etc.

I defined some terms to help them understand their problem:

• core test attributes--the SoftLab test definitions
• extended test attributes--the addition ones needed for the manual

Our solution for them has the following pieces:

• a database into which to put these attributes
• a SoftLab interface to get the core attributes
• a desktop app to provide a rich UI for maintaining extended attributes
• a template-driven HTML document creator which runs automatically
• an interactive search tool to provide users with a way to search

 The system understands the differences between internal tests, orderable-only tests, resultable-ony tests, orderable & resultable tests and groups. Groups are automatically expanded as appropriate. The format and contents of the internal and external manuals varies as appropriate.

As part of getting this up and running, we provided tools for debugging the SoftLab definitions and validating the groups, especially with respect to groups of groups.

LabTerm--Proof Is the Product, Not the Programming

Today is the final release of our LabTerm unit.

This release finished a rather unsavoury assignment which yielded a rather good result: a custom lab bench computer or, as we say now, "thin client."

The goal was simple: to create a supportable computer which would do all that a lab tech needs to do:

• provide a full-screen terminal to their homegrown HP MPE LIS (!)
• provide rapid access to their on-line Lab Manual
• provide a web browser for the growing number of web-based UIs
• provide a full-screen terminal to their homegrown order handler

In order to accomplish all of these goals, we decided on the following implementation:

1. a Linux image to run on old (discarded!) former Windows 95 boxes
2. a simple X-windows windows manager, "Rat Poison" (kill the mouse)
3. a custom app to provide a full-screen UI to their Lab Man data
4. a customized version of the MiniCom terminal emulator
1. support for MPE line-handling
2. split-screen support to share the screen (Lab Man or order handler)
3. scroll-back buffer
4. copy-and-paste
5. screen history for each session
5.  automatic updating for all these components, including the Lab Man
6. remote viewing of terminal session history
1. this turned out to be fantastic for providing LIS support

I may have done the last dumb ASCII terminal mankind will ever know, and God knows we didn't break any new ground here, but we produced a product that met the customer's needs. By keeping our eyes on that prize, we succeeded even without the cool factor. And support old hardware meant that we could take cast-off computers from within the organization, so we actually went live with enough hardware to do the job properly.

Engineering can be beautiful, but life often demands ugly and our motto is "beauty is in the eye of the user--not the engineer."

Laboratory Manual for Homegrown LIS

The client is a large hospital-based clinical lab with a homegrown LIS--the only LIS they have ever known.

Since the LIS was designed in the mid-1970s, it lacks some modern amenities, such as support for exporting test definitions to an HIS, let alone the several (!) HISes in use by the parent academic medical center.

The client developed a standalone test definitions database using an MS-DOS database management system; our first job was to port that schema to MySQL under Linux.

The client developed a library of export formats so our next job was to catalogue, document and implement exports for these formats. We did the document on-line, as a web site, for ease of use.

Since the process was laborious and manual and involved inventory (printed documents), the client was used to producing their Lab Manual only when pressure to do so became intolerable. We made the Lab Manual creation process push-button and greatly extended the range of supported formats:

• Letter-sized paper for bench use
• Pocket-sized paper for clinicians who are married to paper
• HTML for both public and internal formats
• Palm PDA format for that user base
• Palm or PocketPC format using the Castle development environment

We helped them migrate off of paper, although I keep a pocket manual on my desk to remind me of why computers are a good idea for this kind of thing.