a case study in interoperability


Standardizing Medical Test Names

A hypothetical example of overcoming barriers to interoperability is valuable for architectural planning.

Our scenario is one of two different healthcare provider companies, A and B, which are going to merge and will construct and run a hospital together. They are merging because they think it will save money in the long run. They both now own their own facilities such as hospitals and clinics, employ their own doctors and nurses, and handle all the usual healthcare IT functions. On the surface, these two providers do the same things. They serve patients, manage facilities, employ people, order medical tests, diagnose patients, have clinical support systems, enter patient records, and store patient records. But inside A and B's Information Technology systems, their EHR data files and reference data files are vastly different. Their terminology is also different. Oh, they may use the same exact words, but the same word means different things to A and B. This is a case of "what you don't know will hurt you." The problem is that no one knows both A's and B's systems in fine enough detail to sort these issues out in advance. It is up to the IT requirements analysts to discover these issues and propose solutions.

Right now when doctors in company A order laboratory tests they use different terminology than the doctors in company B. They also send their samples to two different laboratories, Lab A and Lab B. Sometimes provider A and provider B even use the same words for a medical test, such as a CHEM 5 panel, but this one name means different things to the two different laboratories. When the test "CHEM 5" is actually done by Lab A or Lab B a different result is sent back to the doctor.

The challenge is to merge the two different sets of clinical test names so that the new joint hospital can use a common set. There are over 10,000 laboratory tests which can be run. In order to merge the clinical procedures into one common list, all of these test names must be reviewed by a team of doctors, lab techs, and IT people from both A and B so that mapping can be done from the old one to the joint one. Ideally a joint list of new official names should be drawn up but since the facility will be opening in 9 months, there is not enough time to review 10,000 tests. If both A and B had moved to an international data standard before they merged, they would have avoided the terminology nightmare of analyzing whose codes to use and what they mean.

Applying our research

  • Components of Success: both the structure and the meaning of the data (architecture and semantics) being shared is clear and accurate. All issues have been discovered and resolved. Staff has been trained on the new joint procedures.
  • There are many types of people who are consumers of the products of Healthcare IT. CIO's need it to plan workflows for their organization. Nurses need it to ensure quality care for patients enabled by accurate and timely patient data. Doctors need it to order tests. Billing people need it to properly code diagnoses and create invoices.
  • Data standards and common terminologies are a part of the choreography which enables the dance of interoperability. Agreed upon common reference data tables in the form of terminologies are crucial for communication between enterprises. The biggest part of interoperability is the behavioral standards of the software systems.
  • Real world problems: let's examine how HIT requirements analysis can be a challenging process.
  • Where are the standards for Medical Test Names?
    The LOINC standard contains clinical test names.
  • Common terminologies