Home » Readers Write » Currently Reading:

Readers Write 9/3/08

September 3, 2008 Readers Write 3 Comments

Submit your article of up to 500 words in length, subject to editing for clarity and brevity. Use your real or phony name (your choice). Submissions are subject to approval and become the property of HIStalk. Thanks for your thoughts!

Lab Integration: Feds Mandate HITSP
By Product Management Guru

I probably won’t be the only one to point this out, but Interoperability Spec #1 from the federal HIT standards group is lab. This standard is ‘recognized’ by the government, meaning the Fed won’t purchase a product for lab EHR unless it complies. Of course, the standards are complex and most don’t mandate compliance. But, Fed now does.

The purpose of this Interoperability Specification is to describe the top-level specification for the HITSP EHR Use Case. This Use Case comprises two scenarios that describe the entities and interactions that would be needed to implement an electronic EHR or other clinical data system with a laboratory interface. The goals supported by this Interoperability Specification are stated in the EHR Use Case:

  • Transmission of complete, preliminary, final and updated laboratory results to the EHR system (local or remote) of the ordering clinician
  • Transmission of complete, preliminary, final and updated laboratory result (or notification of laboratory result) to the EHR system (local or remote) or other clinical data system of designated providers of care (with respect to a specific patient)

Many labs don’t care about the Fed and meeting the recognized standard. Or, the existing healthcare standards have plenty of gray areas to squeeze into. I think a lot of people do support the standards like HL7, ANSI, etc., but while the standards provide help for transport and app layers, they often leave mismatched coded values and other vagueness.

So, the two sides still need to spend a lot of time talking about what they place in the transactions. Plenty of people say that some vendor-specific format is less work then figuring out a standard. This seems to be the history of healthcare integration.

HITSP, specifically for the federal use cases identified by the Office of the National Coordinator, is trying to complete the picture by stating ‘use this spec’ as well as ‘use it like this.’ As a major purchaser, the Fed will influence vendor decisions. Early adopters are emerging already.

I noticed John Halamka coincidentally writes about lab values in his blog today (he is also chairman of HITSP). I’ve heard Dr. Halamka talk about how standards have knocked integration projects from $100K-200K to $10K-20K. HITSP is trying to knock them down to $1K-2K (paraphrasing – he may use different numbers). In the interest of disclosure, I have been volunteering time (or my company’s time) on some HITSP committees.

Lab Integration: Labs are Blocking the Plan
By Lab Dude

I think the labs agree this needs to happen, but just don’t want to invest in it. It is very painful to get a lab interface up and running. Each lab has multiple regions that act differently, have their own compendiums, etc. Because there is no standard test code, all the codes are proprietary. Testing is required for each and every one.

The EHRVA had a lab summit meeting in July and brought together the major players in lab (reference labs, EHR vendors, American College of Pathologists, HL-7, CCHIT, etc.) The goal was to create a three-year plan for faster adoption. We decided to create a use case to send to ONC, spent around six calls on it, then wrote it. All along, the labs were involved.

Recently a lobbyist for the labs sent a letter claiming the jointly developed use case goes too far and the labs can’t possibly do it. So, it looks like the labs are banding together to block the plan. It’s very frustrating. How are we going to get better?

Lab Integration: ELINCS Initiative
By e-Practice Management Chief

With respect to your request for comments about lab standards, there actually has been a great deal of work done in recent years in an attempt to establish a standard. While the HL-7 specifications are typically used for results communications, the individual lab providers themselves have different terminologies/codification of results within that specification. The ELINCS initiative attempts to set this straight by:

  1. Establishing a more standard construct for the HL-7 specification so that there is less variance in where different pieces of data are placed (e.g. last and first names which are critical for matching). HL-7 adopted the standard in 2006.
  2. Using LOINC codes as a standardized nomenclature for observations/results instead of "local" codes designed by different Lab Information System (LIS) providers, which result in variances between systems for the same concept.

One of the barriers right now is a normal one for our industry: the existence of entrenched systems which would be very costly to change. Since there are many regions with just one or two dominant lab players who control their local markets, there isn’t a great deal of momentum to make the changes happen very fast. However, the ELINCS standard definitely has traction with major players such as the Markle Foundation, CMS, HL-7, etc. and it is also the standard for results for CCHIT certification which is obviously a major force.

The California HealthCare Foundation has managed this work, including pilots. Sujansky & Associates was contracted for technical consulting and other management. They have also provided an excellent and free testing tool (EDGE) which we use whenever we have to interface to a new LIS and do testing of those third party results files. Most of the time we seem to get cooperation, but there are some cases where a particular system and its technicians are not familiar with the standard and have problems with making changes.

This link provides good information about ELINCS.

With respect to the ordering process, there is enormous variation with very few true bi-directional interfaces available. Some clearinghouse operations are attempting to act as middlemen, but it is very challenging. Most of the demonstrations still show a manual entry process at the clinic side because they are not used to getting true orders which are typically expressed by doctors using billing terminologies (CPT).

We find that most labs are stuck on legacy systems and held hostage to the LIS vendor’s willingness to make changes. We don’t require that they meet the specs 100%, but we do refer them to ELINCS as optimal specs. Our interface developers think that maybe half of the vendors actually go to the ELINCS site to at least look at the specs. Because changes may have to be made anyway, labs have to invest some time and money changing their format, to some degree. This is also a reason why some entities like hospitals often contract to third parties like Iatric. They can keep their existing system and have the middleware keep up with other changes.


Lab Integration: Nobody Dislikes Standards
By Bob Nadler

You asked, "Are lab standards an issue one of the various work groups is addressing? Are the labs on board?"

When you say lab, what you’re really talking about is the large number of medical devices commonly found in both hospitals and private practice offices. As you note, the need for interfaces to these devices is so the data they generate can be associated with the proper patient record in the EMR. This not only allows a physician to have a more complete picture of the patients’ status, but the efficiency of the entire clinical staff is vastly improved when they don’t have to gather all of this information from multiple sources.

The answer to your second question is yes: many labs — medical device companies — are actively in involved in the development of interoperability standards. The EMR companies are also major participants. There are two fundamental problems with standards, though:

  • A standard is always a compromise
  • A standard is always evolving

By their very design, the use of a standard will require the implementer to jump though at least a few hoops (some of which may be on fire). Also, the device-to-EMR interface you complete today will probably not work for the same device and EMR in a year from now. One or both will be implementing the next-generation standard by then.

Nobody dislikes standards. Interoperability is usually good for business. There are two primary reasons why a company might not embrace communications standards:

  1. The compromise may be too costly, either from a performance or resources point of view, so a company will just do it their own way.
  2. You build a propriety system in order to explicitly lock out other players. This is a tactic used by large companies that provide end-to-end systems.

The standards problem is not just a healthcare interoperability issue. The IT within every industry struggles with this. The complexity of healthcare IT and its multi-faceted evolutionary path has just exacerbated the situation.

So, the answer is that everyone is working very hard to resolve these tough interoperability issues. Unfortunately, the nature of beast is such that it’s going to take a long time for the solutions to become satisfactory.

Lab Integration: The Thorny Problem of Semantic Interoperability
By Huckleberry

I work with hospitals sending data to physicians’ ambulatory EMRs. I had to say "thank goodness I’m not alone" when reading your comments.

I’ve been to many conferences (TEPR, HIMSS, World Health Congress, etc.), and nobody seems to be able to tackle the thorny problem of semantic interoperability. Everyone can speak HL7, but that’s only half the problem. There are so many different entities that need to agree on what each of those data elements MUST ACTUALLY MEAN that I’m not sure we’ll ever see a solution.

I heard one speaker say something like, "We can send a man to the moon, but we can’t exchange healthcare data." His point was that it might take that type of governmental effort (and mandate) to make this happen. I cringe thinking about it based on what’s happened so far on the governmental front with the NHIN, CCHIT, etc., but he may be right.

Something hilarious. Check the box at the top of the Wikipedia definition of semantic interoperabilty. Well, that’s it in a nutshell, isn’t it?!


Open Software Review -  Aurora by Adaptive Path
By The PACS Designer

Aurora is a concept video presenting one possible future user experience for the Web, created by Adaptive Path as part of the Mozilla Labs concept browser series. Aurora explores new ways people could interact with the Web in the future based on projected technological trends and real-world scenarios.

Through the development and release of Aurora, Adaptive Path, a research and development practice, will contribute its design expertise to support Mozilla’s efforts to inspire and engage a global community in an open design process to spur improvements.

The increasing ubiquity and importance of the web browser made it an excellent candidate for an R&D project. Mozilla Labs and its efforts to scale its open design process offered Adaptive Path an opportunity to contribute to the community and help Mozilla reach out to designers as well as developers. Adaptive Path’s emphasis on collaboration and openness was a good match for the culture and values of the Mozilla community.

The key components of Aurora are:

  1. Natural interaction: Spatial, visual, and physical engagement with the Web
  2. Continuity: Seamless, consistent Web and browser experience across devices
  3. Multi-user applications: The Web as a space for collaboration, sharing, and remixing
  4. Context awareness: Products that know where you are and what you’re doing, both physically and virtually

There’s a video of the Aurora solution.

While Aurora is possibly a Web 3.0 solution, it is a good example of what developers are focusing on to make the web experience more interactive and informative.

View/Print Text Only View/Print Text Only

HIStalk Featured Sponsors


Currently there are "3 comments" on this Article:

  1. Interoperability Spec #1 from the federal HIT standards group is lab. This standard is ‘recognized’ by the government

    Ok lets take a look. Hmm, thats a lot of analysis and uses case but I am still missing the semantic interoperability (a red herring if there ever was one).

    Here is my summary of the first two specs (magazines?)

    Specification: Electronic Health Record Laboratory Results Reporting

    Distilled Detail: Please use HL7

    Specification: HITSP View Laboratory Results from a Web Application Transaction

    Distilled Detail: Please use HTTPS

    I think I will wait until our hospital is forced to use them… or the next administration changes them.

  2. Everytime I see “EHRVA” involved in setting standards, I think of CCHIT and e-prescribing, which are standards that were made not to forward medicine but to line the pockets of the “enterprise” EMR vendors that control this group. This group was formed to heavily lobby Congress and to force HIT onto all physicians in a manner in which they are being forced to use these costly CCHIT-certified “EHR” systems for very little payback.

    Whatever happened to the old venerable ODBC connection that came free with MS Office? It was free, easy to set up, and completely functional. Another standard not associated with EHRVA, and FREE, was CMS/Medicare’s “National Standard Format” that for years was the way that any EMR could log in and bill Medicare. Of course, EHRVA wouldn’t profit at all from intiatives such as these, so they don’t want to upgrade and promote softwares such as these.

    If I were a lab I wouldn’t sign on until we know more about:

    1) costs
    2) true interoperability
    3) ease of use.

    By reading the above article, ELINCS fails in # 3 with the lab entities that have to use it, and until that’s fixed, it’ll be another standard that will fail.

  3. This conversation is a joke. The government wants to standardize a small piece of healthcare that one vendor or possibly two may care about based on winning the governments business at some point. So instead of developing great systems, lets worry about interfacing to government specs. Give me a break, work on standardizing interfaces in general without Z segments throughout the organizations. What a joke and a fairly Democratic thing to do…..

Subscribe to Updates



Text Ads

Report News and Rumors

No title

Anonymous online form
Rumor line: 801.HIT.NEWS



Founding Sponsors


Platinum Sponsors






























































Gold Sponsors
















Reader Comments

  • MA/MBA Grad: I have both an MBA and an MBA in Hospital & Health Administration. These were done together through a dual-dual prog...
  • richie: I don't think it's legal to whip a horse these days without mentioning blockchain. And I'd add "innovative", "interopera...
  • Publius: Your Bingo board is missing "Machine Learning"...
  • Ex-Epic: Re: MHA v. MBA I think if you are 100% down the health systems path, you could probably consider MHA or MBA (but woul...
  • The trip: I agree with you. I have an MHA but think an MBA with a concentration in healthcare is the way to go. My RN IT boss in t...
  • David Butler: I absolutely love this article! I'm fairly new to following HIStalk and Dr. Jayne (and the various portions of the site...
  • MiroslavB: Great insights - Thanks Ed !...
  • SteveS: I’d like to hear more from Ed about his perspective on the current state of “Professional Organizations” – in te...
  • Brian Too: Nice to hear from a small hospital for a change. We hear lots from the large players and consolidation has meant that b...
  • Sam Lawrence: Except in this case, coding = medical billing, not development. Though the same warning may be true...

Sponsor Quick Links