While The Desire to Standardize Data Systems is Strong, Entrenched Obstacles Remain

The effort to create an “integrated lab” just means that we want to get everything in the lab working together. Additionally, there is a desire to make it easier to make things all work together than has previously been possible. With the various brands of software and equipment, sometimes on different platforms, often with different data sources, the challenge remains—well—a challenge.

Is it “the same old, same old”?

Laboratory integration would be easier if we created more data standards. Recently, Waters put out a press release containing these comments: “One of the most important challenges laboratory scientists and information technology managers face today is the need for data management standardization. Many of our customers are forced to support multiple laboratory software and informatics platforms amongst their many labs.”¹ What is notable about this is that many in our industry have been saying this for many years now. The desire to standardize data systems has been strong, but has not been realized in more than a few areas. So, when we go back 10 years, 20 years, probably longer, we find groups that talk about and/or start such standardization efforts and fail, for the exact same types of standards, and that each time fail to learn from or make progress from previous groups’ efforts. Thus, why I say it is “many” years.

Consider these two other quotes from the same press release, as well: “Specifically, customer benefits of CDS standardization include reduced training efforts and support resources needed to maintain a single platform” and “… a standardized CDS can facilitate more consistent regulatory compliance through easier software validation and streamlined review/sign off of results.”² Here, while Waters specifically mentions CDS (Chromatography Data System), these comments are true of all informatics systems.

Can we move forward?

If standardization is such a key element to integration, if it has so many benefits, if it is so highly desired, and if the industry has been so interested in it for so long, one might ask, “Why don’t we have these standards in place?” My answer when asked that question is usually, “Because it’s really, really hard!” Then, if that answer doesn’t annoy the person who asked to the point that he or she walks off in a huff, we often end up having a dialogue about how many things have to happen to create these standards. Politics is a major factor of any undertaking. Also, if you’ve looked under the hood of your systems, you know how complicated they are. It’s common to have several systems with huge databases of many tables and fields controlled by even more complex programs, and each one can be almost entirely different than the others.

All this is compounded by the fact that those users have spent quite a lot of money to implement a system and do not necessarily want it to change, and the software vendors trying to deliver new features and technology don’t necessarily want to change their focus toward retroactively changing their software. By now, most customers and software vendors in our industry realize that the “seamless upgrade path” is never as easy as it sounds. Another issue is that software and hardware continue to change; therefore, our focus remains more on what is up-and- coming and whether it is a better solution, than on forcing a path for these solutions to take.

Once again, let me point out that it is not because of a lack of desire. If you ask anyone whether standards are good to have and worthwhile to work on and whether they want them, it is almost certain they will respond positively to all of that.

With all that said, there have actually been some pockets of standardization. One notable effort has been HL7 (Health Level 7 International, http://www.hl7.org/ ), which is an effort to standardize health information technology.³ HL7 has created standards for items such as electronic health records.

So, if HL7 can do it, we should wonder why we can’t do it with everything else. I don’t know the answer to that, but here are a few facts I’d like to mention:

• Specificity: Health information is a specific area. By targeting a single industry/area in this manner, the problem is smaller and better-defined than the usual “let’s try to standardize all laboratory informatics” plan of attack.
   
• Outside Influence: There is some governmental influence and some amount of public desire to standardize health records.
   
• Volume: The sheer volume of clinical data is much larger than the data involved in many other types of “studies” (e.g., stability studies).
   
• Breaking Down Silo Mentality: HL7 seems to have worked to involve factions from all over its industry, from software vendors, to consultants, to the companies actually involved in healthcare. Additionally, they seem to be working with other standards organizations that have expertise related to their efforts. So, while some past standards efforts have included too narrow a group of people to ensure that the potential standards are practical, the willingness to involve others in the process is important for buy-in and practicality.

I had been talking to someone who was involved with both HL7 and previous similar efforts. His main point was that past efforts didn’t get enough people involved who had hands-on experience with the actual data, and that HL7 was addressing that very issue. Thus, while these factors I just listed might not tell the entire story of HL7’s ability to move its efforts forward where others have failed, they are factors worth considering.

The Pistoia Alliance

A fairly new and notable standards effort is that of the Pistoia Alliance (http://www.pistoiaalliance.org/), a consortium created by several large pharmaceutical companies that has grown to include a number of other companies as members. They endeavor to “provide an open foundation of data standards, ontologies and services to streamline the Pharmaceutical Drug Discovery workflow (Chemistry, Biological Screening, Logistics).”⁴ The observer wonders whether it is a worthwhile activity and what is its chance of success. However, until there is either a specific output from this group’s efforts, or quite some time has gone by with a lack of such, it is difficult to tell whether their efforts are going to be any better than the multitudes that have come before them. Typically, if groups like this don’t make some type of continuous progress, they lose momentum and, ultimately, fail.

What should new projects expect?

After many years of integration and standards efforts, your lab shouldn’t count on any particular standard being in place during the course of any given upcoming project. Even if there is some specific date given for the release and adoption of the standard, dates can change, and adoption by the industry as a whole doesn’t necessarily mean all software vendors have yet had a chance to comply.

Additionally, we’re always hearing about “great” new tools that are “easy to use” and all we have to do is “drag and drop” and we’re done, making integration a piece of cake. It’s never that easy. If it were that easy, you wouldn’t be reading this article and this topic wouldn’t have so much web space devoted to it, with TheIntegratedLab. com, a site devoted to any aspect of integration of the lab,5 being just one example (http://theintegratedlab. com/). Because then it wouldn’t be an issue any longer—it would be old news and we’d be talking about something else.

References
1. Dr. Robit Khana, Vice President of Marketing for Waters Division, from the November 30, 2010 Waters Corporation Press Release, “Waters Empower 3 Answers Call for a Standardized Chromatography Data System at Enterprise-Level.”
2. Ibid.
3. Retrieved from http://www.hl7.org/ on December 21, 2010.
4. Retrieved from http://www.pistoiaalliance.org/ on December 21, 2010.
5. Retrieved from http://theintegratedlab.com/ on December 21, 2010.