The College of American Pathologists becomes IHE Lab Domain Sponsor

This press release crossed my desk this morning:

---

	NEWS RELEASE CAP STS 500 Lake Cook Road Suite 355 Deerfield, IL 60015 800-323-4040 847-832-7700 www.capsts.org www.cap.org/DIHIT
	CAP STS CONTACT Candace Robertson 847-832-7764 crobert@cap.org IHE CONTACT Chris Carr 630-368-3739 secretary@ihe.net

FOR IMMEDIATE RELEASE

May 25, 2010

CAP BECOMES IHE LABORATORY DOMAIN SPONSORING ORGANIZATION

CAP and IHE Collaborate to Advance Health Information Interoperability

Northfield, Ill. and Oak Brook, Ill. May 25, 2010—Integrating the Healthcare Enterprise International, Incorporated (IHE) has named the College of American Pathologists (CAP) as the primary Sponsoring Organization of the IHE Laboratory Domain.

Healthcare and industry professionals globally initiated IHE to improve the way computer systems in healthcare share information. IHE brings together healthcare information technology stakeholders to implement standards for communicating patient information efficiently. The CAP, a leader in the practice of pathology and laboratory medicine, includes a division devoted to assist clients pursuing semantic interoperability for electronic health records (EHRs) and other applications.

The IHE-CAP collaboration will accelerate the process for defining health IT standards and promote health IT interoperability for the laboratory—complementing efforts in many countries to create national EHR systems.

"We are thrilled to have the CAP becoming a sponsor of the IHE Laboratory Domain," said David S. Mendelson, co-chair of the IHE International Board and professor of Radiology and chief of Clinical Informatics at Mount Sinai Medical Center, New York. "The clinical laboratory has been a critical part of IHE's expansion across the spectrum of care and it will be very beneficial to have such an important stakeholder organization driving the adoption of interoperability standards in that domain."

The CAP, as the primary Laboratory Domain Sponsor, will be responsible for supporting domain operations, including the development, publication, and maintenance of IHE Technical Frameworks. Technical Frameworks are globally recognized specifications for the implementation of standards to achieve effective systems interoperability. One issue the Laboratory Domain will address in 2010-2011 is the next generation of Laboratory Device Automation.

The CAP has more than 40 years of experience in healthcare terminology standards development, resulting in the creation of SNOMED Clinical Terms® (SNOMED CT®). Its SNOMED Terminology Solutions Division (STS) leads CAP’s standards and health IT initiatives through its Diagnostic Intelligence and Health Information Technology (DIHIT) team. CAP members and DIHIT staff will represent the CAP in the IHE collaboration.

“The CAP’s clinical and technical expertise in health IT, paired with our long-standing relationships with key stakeholders worldwide, will greatly enhance the development of the Laboratory Domain,” said Kevin Donnelly, CAP STS vice president and general manager. “Our goal is to ultimately improve patient outcomes through interoperable health IT systems that provide data to assist in diagnoses, clinical decision support, and improvements throughout the healthcare system.”

“We are pleased to support the IHE in the Clinical Lab Domain. This emphasizes the importance of pathologist stakeholders’ input to improve quality of care in supporting the pathologist’s role as being central to the patient care team,” said David L. Booker, MD, FCAP, chairman of Pathology, Trinity Hospital, Augusta, Ga. Dr. Booker is a member of the DIHIT Committee, CAP liaison to the IHE Anatomic Pathology Technical Committee, and the co-Chair of the Health Level Seven International (HL7) Anatomic Pathology Work Group (APWG).

The IHE works to promote interoperability in health IT through coordinated adoption of appropriate standards and supports the activities of other domains, such as Cardiology, Radiology, and the Laboratory and IT Infrastructure. The Healthcare Information and Management Systems Society (HIMSS), the Radiological Society of North America (RSNA), and the American College of Cardiology (ACC) sponsors IHE.

About CAP STS
SNOMED Terminology Solutions™ (STS), a division of the College of American Pathologists (CAP), is the leading organization in pursuing semantic interoperability for electronic health records by offering customized best-practice terminology implementation and education services. Our goal is to ultimately improve patient care through supporting the pathologist’s role as chief diagnostician/clinical care advisor and advancing interoperable EHRs. The Diagnostic Intelligence and Health Information Technology (DIHIT), a department within CAP STS, is committed to advancing health IT standards, practices, and tools, such as the CAP Diagnostic Work Station initiative; and standardized electronic reporting, including the CAP electronic Cancer Checklists (CAP eCC). The CAP is a medical society that serves more than 17,000 physician members and the laboratory community throughout the world. It is the world’s largest association composed exclusively of board-certified pathologists and is widely recognized as the leader in laboratory quality assurance. The CAP is an advocate for high-quality and cost-effective patient care. For more information, visit www.cap.org/DIHIT or write to snomedsolutions@cap.org.

About IHE
Integrating the Healthcare Enterprise (IHE) is a global initiative dedicated to advancing health information technology by achieving standards-based interoperability. IHE brings together stakeholders to implement standards to address critical information sharing needs. Through its proven process of collaborative development, testing, demonstration and implementation, IHE accelerates the real-world deployment of effective electronic health record systems. For more information, visit www.ihe.net. SNOMED CT® is a copyrighted work of the International Health Terminology Standards Development Organisation. ©2002-2010 International Health Terminology Standards Development Organisation (IHTSDO®). All rights reserved. SNOMED CT® was originally created by the College of American Pathologists. “SNOMED,” “SNOMED CT,” and IHTSDO are registered trademarks of the IHTSDO. All other trademarks used in this document are the property of their respective owners.

###

If it ain't broke, don't fix it

A very long time ago, during the start of my software development carear, I had two quotes from my boss written on the chalkboard in my office at the University.

“	Two rules of software development Just get it to work If it ain't broke, don't fix it.

These became a sort of test for people walking into my office.  If they looked at these two statements and questioned the implications of them on the software generated in that office, they passed. More than 70% of the cost of software is not in the development of it, rather, it is in the maintenance and support of it.  Applying these two rules might get it done quick, but won't result in something that you (or I for that matter) want to maintain.

In the realm of laboratory ordering and reporting, we are in a situation that is the result of applying these two rules.  We have numerous laboratory order and reporting interfaces installed across the country that "work", and since they aren't "broken", there are concerns that we shouldn't be spending a great deal of time fixing them.  This results in debates in the HIT Standards and Policy committees over the need to specify standards now or later, or allow early adopters a "buy" for the first round.

The question is whether you want to drive a more expensive vehicle that is reliable, or if you just want a clunker that spends a good bit of time in the body shop. The just get it to work attitude results in driving around a lot of lemons that have high maintenance costs, but the other approach is expensive in the short term. And if you've already got a lemon that's running, you may not be ready to purchase that new car just yet.  It might require some planning and adjustment, but when that lemon dies, you should be ready to get something that will last.

My thoughts in this are fairly straightforward. 
1.  If it ain't broke, don't fix it. 
2.  When it does break, fix it right, or get a new one that won't break like that again.

The same principle was applied to Federal Health IT infrastructure under the Bush administration via Executive Order 13410, and should be applied to laboratory standards for meaningful use.  In essence it says that new, upgraded or newly developed HIT, use the recognized standards.  Basically, if it isn't being replaced, don't change it.  I know, telling this adminstration to pay attention to what the last one did probably won't fly, even if it was a good idea.  So, instead, look to what section 13111 of ARRA has to say about federal spending on HIT.  What's good for the gander in this case, should be good for the rest of the geese.

If a provider has a working electronic laboratory interface, let it count for the first two years, but ensure that they are planning to update it to support the required standards by 2013.  That will avoid unnecessary expenditures on fixing what "isn't broken", but it will also indicate that we are serious about the use of standards.  It won't leave early adopters out in the cold over what is needed for laboratory interfaces.

Laboratory results are very important in quality measures and clinical decision support.  Avoiding standardization of the laboratory results interface will delay other factors of meaningful use that aren't being debated.  So, it's important to push for standardization and make it clear that we will move forward.

One of the key features of CDA that makes it so implementable is "incremental interoperability".  Let's use that principle for laboratory interfaces as well.

ISO+ to UCUM Mapping Table

Several years ago I was the editor of the HL7 Claims attachments specifications.  As a result of that effort, I created a mapping table from ISO+ Units to UCUM units.  ISO+ units are commonly used in HL7 Version 2 lab messages, while UCUM is a newer standard developed by the Regenstrief Institute that is required for use in CDA Release 2 and in other HL7 Version 3 standards, and was selected by ANSI/HITSP for the communication of unit information.  A much shorter list was eventually used in the claims attachment guides, but I ran across the data I generated the other day and thought I would share it here.

Please note the disclaimer:  I am not an expert on ISO+, UCUM or laboratory units in general.  Therefore, you should validate this data before using it in any clinical applications.

ISO+ Units needing a Mapping

ISO+	UCUM	ISO+	UCUM	ISO+	UCUM	ISO+	UCUM
(arb_u)	[arb'U]	10.un.s/(cm5.m2)	dyn.s/(cm5.m2)	iu/mL	[iU]/mL	mL/hr	mL/h
(bdsk_u)	[bdsk'U]	10.un.s/cm5	dyn.s/cm5	k/watt	K/W	mm(hg)	mm[Hg]
(bsa)	{bsa}	cm_h20	cm[H20]	kg(body_wt)	kg{body_wt}	mm/hr	mm/h
(cal)	cal	cm_h20.s/L	cm[H20].s/L	kg/ms	kg/m2	mmol/(8.hr.kg)	mmol/(8.h.kg)
(cfu)	{cfu}	cm_h20/(s.m)	cm[H20]/(s.m)	kh/h	kg/h	mmol/(8hr)	mmol/(8.h)
(drop)	[drp]	dba	dB[SPL]	L/(8.hr)	L/(8.h)	mmol/(kg.hr)	mmol/(kg.h)
(ka_u)	[ka'U]	dm2/s2	REM	L/hr	L/h	mmol/hr	mmol/h
(kcal)	kcal	g(creat)	g{creat}	lb	[lb_av]	ng/(8.hr)	ng/(8.h)
(kcal)/(8.hr)	kcal/(8.h)	g(hgb)	g{hgb}			ng/(8.hr.kg)	ng/(8.h.kg)
(kcal)/d	kcal/d	g(tot_nit)	g{tit_nit}	m/s	ms/s	ng/(kg.hr)	ng/(kg.h)
(kcal)/hr	kcal/h	g(tot_prot)	g{tot_prot}	mas	Ms	ng/hr	ng/h
(knk_u)	[knk'U]	g(wet_tis)	g{wet_tis}	meq/(8.hr)	meq/(8.h)	osmol	osm
(mclg_u)	[mclg'U]	g.m/((hb).m2)	g.m/{hb}m2	meq/(8.hr.kg)	meq/(8.h.kg)	osmol/kg	osm/kg
(od)	{od}	g.m/(hb)	g.m/{hb}	meq/(kg.hr)	meq/(kg.h)	osmol/L	osm/L
(ph)	pH	g/(8.hr)	g/(8.h)	meq/hr	meq/h	pa	pA
(ppb)	[ppb]	g/(8.kg.hr)	g/(8.kg.h)	mg/(8.hr)	mg/(8.h)	pal	Pa
(ppm)	[ppm]	g/(kg.hr)	g/(kg.h)	mg/(8.hr.kg)	mg/(8.h.kg)	sec	''
(ppt)	[pptr]	g/hr	g/h	mg/(kg.hr)	mg/(kg.h)	sie	S
(ppth)	[ppth]	in	[in_us]	mg/hr	mg/h	ug(8hr)	ug(8.h)
(th_u)	[todd'U]	in_hg	[in_i'Hg]	miu/mL	m[iU]/mL	ug/(8.hr.kg)	ug/(8.h.kg)
/(arb_u)	/[arb'U]	iu	[iU]	mL/((hb).m2)	mL/{hb}.m2	ug/(kg.hr)	ug/(kg.h)
/(hpf)	[HPF]	iu/d	[iU]/d	mL/(8.hr)	mL/(8.h)	ug/hr	ug/h
/(tot)	/{tot}	iu/hr	[iU]/h	mL/(8.hr.kg)	mL/(8.h.kg)	uiu	u[iU]
/iu	/[iU]	iu/kg	[iU]/kg	mL/(hb)	mL/{hb}
10*3(rbc)	10*3{rbc}	iu/L	[iU]/L	mL/(kg.hr)	mL/(kg.h)
10.L	10.L/(min.m2)	iu/min	[iU]/min	mL/cm_h20	mL/cm[H20]

Units that are the same in ISO+ and UCUM
%	bar	g/L	L.s	mg	mmol/(kg.d)	ng/L	ueq
/kg	Bq	g/m2	L/(min.m2)	mg/(kg.d)	mmol/(kg.min)	ng/m2	ug
/L	cel	g/min	L/d	mg/(kg.min)	mmol/kg	ng/min	ug/(kg.d)
/m3	Cm	Gy	L/kg	mg/d	mmol/L	ng/mL	ug/(kg.min)
/min	cm2/s	h	L/min	mg/dL	mmol/m2	ng/s	ug/d
/m3	d	hL	L/s	mg/kg	mmol/min	nkat	ug/dL
/min	dB	J/L	lm	mg/L	mol/(kg.s)	nm	ug/g
/mL	deg	kat	m	mg/m2	mol/kg	nmol/s	ug/kg
1/mL	eq	kat/kg	m/s2	mg/m3	mol/L	ns	ug/L
10*12/L	eV	kat/L	m2	mg/min	mol/m3	Ohm	ug/m2
10*3/L		kg	m2/s	mL	mol/s	Ohm.m	ug/min
10*3/mL	fg	kg.m/s	m3/s	mL/(kg.d)	mosm/L	pg	ukat
10*3/mm3	fL	kg/(s.m2)	mbar	mL/(kg.min)	ms	pg/L	um
10*6/L	fmol	kg/L	mbar.s/L	mL/(min.m2)	mV	pg/mL	umol
10*6/mL	g	kg/m3	meq	mL/d		pkat	umol/d
10*6/mm3	g.m	kg/min	meq/(kg.d)	mL/kg		pm	umol/L
10*9/L	g/(kg.d)	kg/mol	meq/(kg.min)	mL/m2	ng	pmol	umol/min
10*9/mL	g/(kg.min)	kg/s	meq/d	mL/mbar	ng/(kg.d)	ps	us
10*9/mm3	g/d	kPa	meq/kg	mL/min	ng/(kg.min)	pt	uV
10.L/min	g/dL	ks	meq/L	mL/s	ng/d	Sv	V
a/m	g/kg	L	meq/min	mm	ng/kg	t	Wb

If you have corrections or comments, please post a response below.  I will make every attempt to keep these tables up to date and accurate.

Updated November 19, 2009:
Deleted mapping from ISO+ mm to UCUM to (transformation error)
Corrected mapping from ISO+ sec to UCUM '' (was ')
Updated October 20, 2010
Corrected mm(hg) to mm[Hg]
Changed oms/kg to osm/kg
verified mapping for mas (Megasecond according to HL7 V2) to Ms
deleted mapping from lm/m2 to lm
Still trying to resolve issues around (hb)
verified dm2/s2 = REM
Updated October 23, 2020
Fixed a number of problems with capitalization: Changed wb to Wb, v to V, uv to uV, sv to Sv, pAmp to pA, ohm to Ohm, mv to mV, kpa to kPa, gy to Gy, cel to Cel, bq to Bq and 8h to 8.h
Removed f, n because while these prefixes are the same, they aren't units by themselves
Removed n.s because the proper form is ns

Breast Cancer Screening

Recent news discusses the controversy over new recommendations on breast cancer screenings. While the headlines focus on the changed recommendations, I’d rather pay attention to how interoperability healthcare IT can help to identify the at risk patients and enable them to receive the necessary care. I’ve asked my colleague Scott Bolte to cover the details for us, since this is one of his areas of both expertise and passion. Here's Scott on the topic:

Everyone hates feeling helpless and wants to be able control their life.  Rarely is that more true
then when facing cancer, or trying to avoid cancer in the first place. It isn’t surprising then, that changes in breast cancer screening recommendations have provoked passionate debate by clinicians, clinical associations, patient advocacy groups, and patients themselves.

Earlier this week the US Preventative Services Task Force (USPSTF) changed the recommended age for routine screening for breast cancer from age 40 to 50. There were other changes too, but that's the most dramatic one.  The USPSTF is the premier body in the United States for screening recommendations.  It greatly influences clinical practice and reimbursement guidelines.  However, their recommendation for change is not accepted by other authoritative organizations like the American Cancer Society (ACS).

I will not second-guess either the USPSTF or the ACS.  What I will do is point out that these recommendations are for large groups of individuals with average risk. If you go beyond the headlines, you will find that the USPSTF guidelines still explicitly recognize some people have a genetic predisposition to develop cancer and that the new guidelines do not apply to them.


Most people have heard of “cancer genes” like BRCA1 and BRCA2. Actually, everyone has the BRCA1 and BRCA2 genes. All genes naturally come in a variety of forms called alleles.  Some alleles are harmless.  They lead to no measurable difference, or differences in cosmetic features like the color of your eyes. Other alleles are more significant, determining how your body processes drugs for example. But the alleles that we're worried about here are for BRCA1/2 genes and how that changes the chance that you develop a disease like breast cancer.

The BRCA1/2 genes tend to dominate discussions about breast cancer, but they account for less than 10% of breast cancers.  Just because someone has breast cancer, even at an early age, they may not have a genetic predisposition.  There are effective tools to identify risks of developing breast cancer, and one of the most useful is a detailed family history.

The advantage of a family history is it reflects both genetics and environment. It can capture factors such as where you live - with corresponding exposure to environmental pollutions, the family dinner table, exercise habits, and other components that increase or decrease risk. It is the interplay of genetics and environment that ultimately determine if you develop cancer.

If the new guidelines leave you feeling exposed, especially if you have a sister or aunt who has had breast cancer, I strongly recommend you assemble a detailed family history. Use a free web tools such as My Family Health Portrait from the US Surgeon General to survey not just breast cancer, but all other cancers since they are often interrelated. That will capture not only the extent of all cancers in your family, it will also collect critical details like maternal vs. paternal relations, and the age of onset of the disease.

With the family history in hand, you and a trusted clinician can determine if additional genetic testing is appropriate. Whether it is or not, the open conversation about clinical risk - in the context of your personal tolerance for more or less testing - will determine if the new USPSTF guidelines are appropriate for you. Having an ongoing dialog with the clinician, and trusting them when they determine if your risk is high, low, or average, puts you back in control.

To follow up on Scott's posting, I'll add that in 2008, ANSI/HITSP developed the IS08 Personalized Healthcare Interoperability Specification for the communication of detailed family histories in response to the the Personalized Healthcare Use Case. This specification includes the necessary detail for communicating these family histories in a wide variety of clinical documents. Healthcare providers with access to this information can thus readily identify patients who are at high risk, and act accordingly.

Laboratory Orders

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.

The Challenge of a Standard Vocabulary for Laboratory Orders

One of the challenges that HITSP has been asked to address this year is to close gaps in Laboratory workflows. Standards are readily available to support the ordering of labs, and to deal with status updates. Some of the challenges that need to be addressed in the exchange of laboratory orders are related to specimen tracking, CLIA compliance, and managing changes in orders. These are all challenges that I believe are well understood, but a key challenge remains in the identification of vocabulary suitable for ordering laboratory tests.

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:

1. It produces results in the units expected by or familiar to the provider.
2. It has particular characteristics (for example, the chance of false positives or false negatives) that are important to a particular diagnosis.
3. It produces results quicker than other methods.
4. 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.

1. Calculated from other results
2. Electrophoresis
3. High performance liquid chromatography

If the physician specifies the method, then that specific test method must be used. However, LOINC also contains order codes that allow the test to be ordered without specifying the method, leaving the lab free to use any method that it has available.


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.

Panels
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.

Billing
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.