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:
- 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.
- 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:
- 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.
- 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
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:
- Natural interaction: Spatial, visual, and physical engagement with the Web
- Continuity: Seamless, consistent Web and browser experience across devices
- Multi-user applications: The Web as a space for collaboration, sharing, and remixing
- 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.