NPI: No Office = Bad For Lab

Yesterday a sadly familiar issue landed on my desk: how to make NPIs work for lab results.

NPIs were brought to you by CMS, so they have to be good.

To quote from The National Provider Identifier (NPI): What You Need to Know

How Many NPIs Can a Sole Proprietor Have?
A sole proprietor is eligible for only one NPI, just like any other individual. For example, if a physician is a sole proprietor, the physician is eligible for only one NPI (the individual’s NPI), regardless of the number of different office locations the physician may have, whether the sole proprietorship has employees, and whether the Internal Revenue Service (IRS) has issued an EIN to the sole proprietorship so the employees’ W-2 forms can reflect the EIN instead of the sole proprietorship’s Taxpayer Identification Number (which is the sole proprietor’s SSN).

This is logical, but it is very bad for clinical laboratories. Physicians practicing medicine do not fit the model of citizens paying taxes: if I have seven offices, which I visit in rotation, I want the labs for patients who live in Shoretown to go to my office in Shoretown: sending them to any of my other offices creates work and runs the risk of me not having them where and when I need them. But sending them to all my offices creates a blizzard of faxes and a mountain of filing.

Unless, of course, my practice has invested in and correctly configured a centralized, distributed Electronic Medical Record with a real-time, bidirectional Lab interface. Which, very likely, is not the case. At least not from what I see in the field. At least not yet.

So here I am, stuck in the real world, creating yet another mapping from internal LIS ordering ID (which is office-specific) to NPI (which is not office-specific but which is required by many legal agreements).

The good news is that NPI excels at figuring out which providers merit a fruit basket for all their business: I can analyze the ordering patterns by practice pretty easily by associating NPIs together into a practice. I just can't help you with where to send that fruit basket. Or those lab results.

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