Custom Requisition Support

One of my colleagues provided the client with a very nice customer requisition creator:

• a database which holds practices and maps practices to their favourite assays;
• a UI to maintain the database;
• a formatter to put the custom information onto requistion forms

The customized requisitions were a huge hit with the providers, but not with the phlebotomists: the providers get an easy way to order just what they want to order but the phlebotomists get order forms which vary widely, making entering those forms into the computer harder than they would like.

In order to better support draw station operations, I upgraded our draw station software to accept the practice ID as part of the patient greeting process. This allows the draw station app to put up a web page which matches the paper requisition in the phlebotomist's hand.

So if they want to order the test which is the fourth box on the second row on the paper, they click on the fourth box on the second row of the screen.

Since the draw station procedure is to highlight the assays with a yellow marker as the assays are entered, to ensure entry accuracy, I mimic that on the screen: when a box is checked off, that assay has a yellow background.

The feedback was immediate and positive: the users who are not that comfortable with computers were instantly comforted by the close corelation of the physical and virtual.

Homegrown LIS -> Ref Lab

Client has a homegrown LIS, but wants to have a bi-directional interface with major ref labs: ARUP and Mayo to start.

The homegrown LIS cannot be extended, so I created a piece of Middleware (MW) to bridge the gap.

On the LIS side, the MW appears to be an automated analyzer, to which orders flow and from which results come.

On the Ref Lab side, the MW appears to be an industry-standard, up-to-date LIS, speaking HL7 over TCP/IP.

It all works like a charm:

1. A user  of the homegrown LIS places an order for a send out
2. The MW detects the order as if it were an instrument
3. The MW stores the order in its database
4. The MW creates an HL7 order for the appropriate ref lab
5. The MW sends the HL7 order on its way
6. The Ref Lab interface receives the order
7. The Ref Lab interface sends a result
8. The MW receives the result and updates its database
9. The MW creates a message to tell the homegrown LIS the result
10. Any user of the homegrown LIS can see the result

The MW has three components: a database, a TCP/IP client to send orders and a TCP/IP sever to receive results.

The database allows for various automatically generated management reports and tracking of activity and back up of the received results.

Hemoglobin Analysis Report (HGB Clinapp)

Banged out another clinapp today, this one for Hemoglobin analysis. The framework is about 5 years old, but still performing like a champ.

The users also love the very high degree of consistency between the apps, which makes moving between interpretive reporting duties much easier for them.

SPEP & UPEP Clinapp

Sigh. Due to popular demand, another clinapp, hurray. This one's title is the longest yet: "immunofixation electrophoresis report"

The big wrinkle here is including the image of the gel produced by the automated analyzer: exciting for the users, but not that exciting for me since this is not very challenging in the groff context:

1. convert the instrument output to encapsulated PostScript
2. include the EPS in the report

It's a living.

Smear Clinapp

Another day, another clinapp, or so it seems some days.

Today's interpretive report to be supported with an app is the Smear section, which produces a large number of reports all of which start with a blood slide and end with a clinical comment.

Man, I had no idea when I started this code base that it would turn into a mini-career.

Science Project To Clinical Resource (ORU repository)

Today I turned an interesting science project into a treasured clinical resource, and got to take lots of credit in the process. Not a bad day!

A member of the client's computer staff had put together a fascinating science project: a collection of ORUs (HL7 result messages) in a Reiser file system on a standalone Linux box, accessible through a simple TCP/IP protocol.

The science project was fascinating:

• collecting the ORUs as an archival format because HL7 is flexible and somewhat changing
• storing the ORUs in a small text file named with the specimen ID
• adding a simple per-patient text file index to support reporting by patient
• using the Reiser file system to hold many (20 million+) small files efficiently
• using the TCP/IP protocol to make access from a web page easy
• using the interface, all historical results were output from the LIS and therefore input into this respository
• tapping into the HIS interface, this repository is kept as current as the HIS

The author's goal was to create an LIS downtime solution and a way to monitor the LIS->HIS interface, from which the ORUs come.

My goal was to create a helper app for my clinapp environment, providing supporting lab results far beyond the current set. Since my environment was created to support clinical impressions of conditions which are often observed over years, the users were thrilled with the ability to scroll back in time from current to mid-1974.

Even in its first day, the helper app has become wildly popular and has sparked interest in adding links to the repository from other web applications. Hurray for the original author, on whose shoulders I am happy to stand.

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."