I've enumerated some of the challenges on order codes below:
Specifying the Method of the Test
Laboratories must perform the tests that a physician orders, not something else. Additional negotiations are needed between physicians and labs when the test that they've specified isn't available. This wastes time and effort on the part of both parties. Allowing a physician to specify the method is necessary for various reasons:
- It produces results in the units expected by or familiar to the provider.
- It has particular characteristics (for example, the chance of false positives or false negatives) that are important to a particular diagnosis.
- It produces results quicker than other methods.
- It is more cost effective than other methods.
For example a physician could order a test in a variety of ways to measure the concentration of Hemoglobin A1C (a test commonly used to test for, or check the control of diabetes). There are three different methods listed in LOINC that can be used to calculate the % of Hemoglobin A1C in blood.
- Calculated from other results
- High performance liquid chromatography
Additional Services (Reflex Testing)
Many times a lab will automatically initiate additional testing based on the outcome of a laboratory test. For example, in micro, the results of a culture could be tested for microbial sensitivity to drug treatments, or the identification of a Type A Influenza could result in additional typing testing to determine the virus subtype (e.g., Avian Flu H5N1 or Novel Flu H1N1), or a urinalysis with abnormal results could reflex to include microscopic examination. Different tests may be performed depending upon the outcome of the original test. In Microbiology tests, the collection of drugs which may be reflex tested could depend on what is cultured.
The collection of rules with respect to what is actually performed in the reflex testing are traditionally identified by the service (order) code. LOINC codes do not currently include common test orders which include reflex testing.
LOINC contains numerous panels defines for common requests, e.g., Blood Chemistry, Complete Blood Count, Urinalysis Panel, Lipids, Metabolic Panels, et cetera. While these panels have been defined in LOINC, it isn't clear that there is industry agreement on what is required and optional within these panels. Some panels include results reported using a specific method which have their own challenges.
In some cases, it may be necessary to associate a different code for the same test depending upon the purpose for which it is used. This apparently is because there are different billing requirements for the different tests. I have to admit this is one area I least understand, and if true, one I least appreciate. If it's the same test, why aren't we paying the same price for it, regardless of what it is used for.
The Way Forward
There have been efforts in the past to resolve some of these issues, but none appears to have been successful yet. I honestly believe that one reason these efforts haven't been successful is because the scope was to broad.
I am certain that HITSP can identify a set of order codes dealing with commonly ordered lab tests if the scope is restricted to avoid some of the complexities identified above. I believe that we can, working with other standards organizations, identify a value set of from 50 to 100 common laboratory orders that could be the start of a solution. We needn't boil the ocean here or eat an elephant in one gulp. There are likely a good set of codes that could cover 50% or even more of commonly ordered labs.
What would the benefit of having this value set be? If we can accomplish the goal of standardizing 50% of labor orders, we should be able to reduce the time spent by healthcare professionals and their staff addressing issues around those tests, freeing them up to perform other tasks.
Another benefit would be that EMR systems could be installed using that default set of order codes, and supporting the standards for placing and updating the orders. If this were to happen, the time and resources needed to implement a basic laboratory interface between a healthcare provider and a lab could be cut dramatically.
The end result might very well increase competition among the providing labs for these commonly ordered services, which is the elephant presently standing in the room. I certainly understand the challenges brought about by commoditization of a marketplace, having experienced it several times in my own career. However, I see competition as an incentive for labs to find faster, cheaper, better ways to provide these commonly ordered services.
Many years ago, I was a service manager in a computer store. Due to the commoditization of the computer market, I saw eroding margins eat away at the profitability of that store. It eventually closed, and we see few computer stores organized the way the used to any more. Today you can go online and purchase a computer system for less than $500 that would outperform the $3500 model I was selling and servicing 15 years ago. Wouldn't we love to see that sort of erosion in healthcare costs over the next 15 years?
I realize that not all labs, test methods, or collections services are created equal. I'm certain many providers are happy with the services that they are getting. I don't think that it is necessary to require labs or providers to stop using existing code sets. I simply think that providers should have the option to use a standardized set and get the same level of service as if they used proprietary ones.
Removing interoperability barriers from the cost equation provides more choices for providers, payers, and in the end patients. More choices may mean that there are winners and losers in the market. We should also wind up with a more efficient and cost effective healthcare system. In the end, that result best serves me, who is just one more consumer of healthcare.