Pages

Monday, November 2, 2009

Today several members of HITSP Care Management and Health Records TC met at the National Library of Medicine to discuss the development of a value set for creating an interoperable set of laboratory order codes. Present at this meeting was an unprecedented collaboration of people representing healthcare providers, laboratory vendors, HIT Vendors, HIE developers and payors. Many of those participating were also involved in testimony before HIT Policy Committee's information exchange workgroup, and are experts in the field. You can read some of that testimony on the HIT Policy committee meetings web site. One of the common themes of that meeting was the need to make it easier to deliver a working laboratory interface with a delivered EMR system, and the desire to work with standardized codes.

This meeting was put together by Dr. Clem McDonald and his staff as a result of his work for HITSP a couple of months ago. Using data from several sources, including the Indiania HIE, United Healthcare and a few other sources, Clem and his team were able to identify a set of about 300 LOINC order codes that cover about 98 - 99% of the most common laboratory orders.

We are fairly close to a resolution based on the results of the meeting today. At this stage, it appears that the significant discussions are no longer about whether there is a need for common laboratory orders, but rather, how to maintain such a set, and what should be included in it. I attribute the success we've had thus far to an appropriate scoping of the problem. Some of the more complex topics are panels, reflex testing, and custom laboratory order codes.

We've addressed these complexities in several ways:

1. The approach is intended to address common laboratory orders, rather than to boil the ocean. My own success criteria is being able to address 80% of the most common orders. This reduces the laboratory interfacing problem to mapping order codes for the 20% remaing in the tail. This could readily reduce the implementation effort for laboratory interfaces to 1/3 or less of the current effort. Certainly in this era of healthcare interoperability, there are more valuable things to be doing than mapping codes.

2. We've scoped out certain levels of complexity, so that if we cannot address a particular topic (e.g., complex panels or reflex testing), we'll remove them from the problem space we are trying to address. This simplifies the problem and gives us something to work on later as we gain experience with the simpler solutions. We can see what works and later try to address the more complicated issues.

3. Finally, the solution is not intended to replace existing functional interfaces, replace the ability of providers and laboratories to develop codes for custom orders, or agree on codes for tests not in the value set. We want systems that support the laboratory order capability to demonstrate the ability to deal with this code set without forcing change on what already works (if it ain't broke, don't fix it).

In reporting these results of this meeting to the HITSP leadership this afternoon, we recieved several accolades for having addressed what has been a long standing problem in laboratory orders. The problem isn't solved yet, but I will agree that we've made significant progress. In the coming weeks, ANSI/HITSP will be publishing the initial value set of laboratory order codes in the HITSP C80 Clinical Document and Message Vocabulary specification, as well as specifications of laboratory messages (HITSP C163 Lab Order Message) and a new capability (HITSP Capability 99 Laboratory Orders) that is intended to address some of these issues.

The important next steps coming out of this meeting are:
1. Reviewing the work of HITSP during the 30 day public comment period.
2. Development of standards to support the exchange of an order compendium between a laboratory and HIT system. The American Clinical Laboratory Association is presently working on a framework to support this effort.
3. Establishing a home for this value set, and a model of governance to maintain it.

This is phenomenal progress, and I'd like to thank everyone who has participated. We may not always see eye to eye, but at this point, we are all looking at the same problem, and working to develop a consensus on how to resolve it.

2 comments:

This is a big advance. I would also like to see a standard for the updates to the code set that will occur from time to time. As an implementer, I find this to be a continual problem, and I can't see how our code sets can survive in the long term without some solution.