Bone Marrow Clinapp

Just completed another clinapp, this one for Bone Marrow interpretation.

It is gratifying how the basic framework continues to provide such good service, seven years after the first app was done.

Like its siblings, this app provides:

• a work list of tech to-do (orders awaiting results)
• a work list of resident to-do (results awaiting preliminary interpretation)
• a work list of attending to-do (prelim interps awaiting review)
• same-screen access to relevant current lab results
• links to related clinapps reports for this patient
• context-sensitive access to the historical repository of lab results
• printable report PDF creation
• faxing support
• LIS interface

This app is using by attending from other departments, so I have validation that the UI works in more than one user context.

Tube Tracking

Our draw station software roll-out went swimmingly, but as with so much of life, it was a case of "what have you done for me...lately?"

The draw station app connects the labs and the draw stations. We had expected that the new requirement would all be on the draw station side, because  we understood the lab side: we were integrating into the existing inpatient specimen handling procedure.

Except for drop-offs: the lab folks decided that they would trust the phlebotomists to handle drop-offs via our app because the phlebotomists quickly demonstrated proficiency with our app. So suddenly every draw station was a potential drop-off point.

This greatly increased the tube traffic from the draw stations. Then the issue of tracking reared its ugly head as disputes arose between the three parties:

1. the draw stations (origin)
2. the courier (transit)
3. the lab (accepting delivery)

We were not eager to create a tube-tracking module, but the pressure became sufficient that we did it:

• the ability to batch draws into shipments (the draw station app knows how to map orders into tubes)
• the ability to create a barcoded shipping manifest
• the ability to mark a shipment as delivered

We discovered that all three parties were motivated to use the upgrade because each group blamed the others for the sometimes delays, rarely lost tubes. Once we provided a common context for a conversation, the problem dropped dramatically: the draw stations were more careful about packaging, the couriers had confidence about what they were carrying and the labs could look up individual orders to know that they were not delayed or lost, despite what the patient or doctor might claim, the tubes were safely in transit.

Phlebotomy Support

The client is a large hospital lab, recently given responsibility for Phlebotomy. Their problem is that the draw stations not only  are not on the LIS, the draw stations are not computerized at all.

Their problem is compounded by the fact that their LIS is not off-the-shelf but is rather long in the tooth.

Worse, the lab is entirely focused on inpatient specimens: their processes and procedures all assume an electronic order in the LIS followed by a tube labelled with an LIS collection label.

All we can count on at the draw stations is a secure network connection.

We bridge that gap in under two months:

• custom Linux-based thin clients to provide
• dependable known web browser
• barcode label printing and report printing
• a web app to
• greet the patient, establishing a start for wait time
• identify the patient using an up-to-date patient index
• support finding and using existing electronic orders (clinics)
• support turning a paper order into an electronic order
• UI of assays
• interface to LIS to place order as if from the HIS
• print a collection label compatible with the legacy LIS
• provide history of activity by draw station or across draw stations
• support drop-offs
• support clinical trials
• support ordering synonyms to match community ordering habits

We roll out our app to their completely computer illiterate user base, many of whom have never used a mouse.

We provide management metrics for wait times and patient visits and a link to the Lab Man database so that the phlebotomists have up-to-date collection instructions. (More on that original Lab Man here.)

Mon Dec 1 13:35:10 EST 2008
Major release:

• support EKG scheduling
• support Accession Issues to link front bench and draw stations
• support for Cc physicians
• support ordering web page matching custom requisitions

Sat Jun 27 06:26:44 EDT 2009
Major release:

• scanned req support: barcode and tracking and viewing
• tube tracking
• support cancelled code substitution
• support lab protocol order changing automatically

Sat Dec 12 06:33:47 EST 2009
Major release:

• support the new incoming LIS, SoftLab

Wed Feb 23 10:11:14 EST 2011
Major release:

• support ABNs: UI to accept the data, process to generate the forms
  

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.