Google Maps for Data Visualization

We are looking into ways to make draw data and ordering statistics more useful to our clients. Perhaps a map? Check out this excellent tutorial on how to get started: I did and was very impressed.

http://www.w3schools.com/googleAPI/default.asp

Our proof-of-concept project has the following goals:

1. a map of the catchment area
1. marker for client
2. marker for each draw station
2. pop-up for each marker
1. show the absolute activity for that location
2. show the percentage activity for that location
3. do the same thing with ordering clinicians instead of draw stations.

We are eager to see if the coolness translates into actual usefulness.

Direct Interfacing?

This looks like an interesting idea for our lab connectivity start up:

http://directproject.org/faq.php?key=faq

Random connections over the Internet, secured by x509 certificates, with the payload format unspecified. Assuming we control the certificates, we can be confident that our connections are secure from others and from the right computers.

We would use HL7 to encode the payload, of course. But this gives us a validated and accepted model for transactions in a cloud-based environment. Interesting. I feel a proof-of-concept project coming, probably built on Amazon Web Services.

This architecture also lets us circle back to this at some point down the road:
http://www.mehi.masstech.org/health-it/health-it-learning-center

Provider EHRs

When I consider this whitepaper from Athena Health, I am struck by the fact that Electronic Health Record (EHR) remains such a vague term with regard to the audience. I can't imagine talking about actual instances of EHRs, as opposed to the generic concept of EHR, without regard to the EHR user. I would say that lumping in solo practicioners, small practices and large practices is a bad idea, an example of the fallacy that "if we solve the most complex case, all other cases will work."

This is especially true for clinical lab orders: every EHR is happy to provide menus for the 20% of the catalogue which makes up 80% of the orders. But there seem to be no EHR vendors who want to support the most esoteric, harder to order labs, let alone properly store and display those complicated results.

Worse, the notion of "lifetime results" is also poorly supported; yes, it is true that some small number of years is as long as most lab results are relevant, but what about those tests whose value never goes away? Those genetic tests which we see repeated over and over again?

Someday I would like to see the following:

• Acknowledgement that one size does not fit all
• Full support for lab ordering and resulting
• Full support for lab consults:
• if I have a problem with my Amazon order, I can ask about it
• if I don't understand a lab result, I have no easy way to ask

Epic Draws

One of our clients retired our custom draw station solution in favor of Epic, but quickly found that Epic could not provide the management reports we had provided, so we were asked to somehow recreate our report package in the new environment.

After some consideration, the solution we choose was this: an extractor of data from the LIS (SoftLab) to populate the database on which the reporting package was based. So the orders come through Epic, into SoftLab and then into our database.

Once we defined and refined the business rules which let us determine which orders were collected in draw stations and which were not, the rest of the puzzle fell into place.

Along the way, we uncovered some ordering issues--misconfigured menus in Epic, out of date test definitions in SoftLab, receiving procedures not properly adjusted for the new environment--which is the first step to fixing them.

We also learned more than we wanted to about how orders are stored in the LIS, but that will be useful down the road I'm sure.

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.

Advance Beneficiary Notice (ABN) Support

Today we start upgrading our draw station app to support Advance Beneficiary Notices (ABNs).

The formatting is not a problem, because I know how to use groff and ghostscript to make PDFs which match the specs.

The calculation of benefits is being done by the LIS, not because we can't parse the same file that they do, but because the client wants a single instance of this kind of calculation, which makes sense.

Closing the loop is where we excel: we are setting up a system to capture an image of the signed (or not signed) ABN and then automatically attach that image to the draw. Furthermore, we are automatically populating a web page for the billing folks so that they can either access the image directly or see which draws do not have ABN, but should have had ABNs.

Crossing internal boundaries is essential to our success in providing automation which really works.

Here is what one of our test ABNs looks like after scanning and being automatically attached via its bar code:

Note: the image is a bit crusty because I converted the original PDF into a PNG to appease Blogger

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.