Smooth the Path to Integration in Informatics



Joe Liscouski
05/29/2012

With an increasing emphasis on informatics and the potential to better organize and manage data / information, there is an increasing interest in integrating the sources of laboratory data with the tools used by scientists to analyze, interpret and develop reports based on experiments and instrument measurements.  Those working in labs want to tie things together to improve workflow and to aid sharing and collaboration.

For most, achieving that goal has been met with limited success, often accompanied by trading-off what scientists really want for the minimum acceptable condition of transferring some of the data without the full robust systems those working in labs would like to see: a well designed flow of laboratory data into a common laboratory library that can be accessed by whatever tools scientists choose to carry out their work without worrying about whether or not they will be able to do it. 

The reason for the current level of frustration is that the tools used were never designed with that concept in mind.  They were designed to provide a given level of capability – to do something – and once that was done, the rest is left as an exercise for the user: they gave you the data, how you integrate it with you lab’s workflow and other data is your problem.

There are a number of examples of successful systems integration that prove the idea is feasible: USB products, the telephone system, integrated office applications, computer graphics systems, applications on the internet. They all have one thing in common: they were DESIGNED with an underlying standards-based architecture that enabled and facilitated integration. 

Rather than the integration of single-vendor solutions, we need the ability to integrate your choices of products, and that is needed for at least two reasons: 

  1.  you should control the choices of products in your lab
  2. you should be able to make changes in those choices without facing a major effort in data transfer that has the potential for data loss, or compromising the integrity of intellectual property. 

There are existing efforts in standards development:

  • The ANiML standard for formatting analytical chemistry data, it has the potential for going beyond that  - http://animl.sourceforge.net/
  • SiLA – “The SiLA consortium for Standardisation in Lab Automation, develops and introduces new device and data interface standards allowing rapid integration of lab automation and data management systems.” - http://www.sila.coop/
  • The Pistoia Alliance – “The Pistoia Alliance is a global, not-for-profit, precompetitive alliance of life science companies, vendors, publishers, and academic groups that aims to lower barriers to innovation by improving the interoperability of R&D business processes.”  - http://www.pistoiaalliance.org/
     

Each of these addresses part of the problem and could provide useful components, but none of them provides the basis for the development of a robust architecture that is needed to fully address the need.

What is needed is not a piecemeal treatment of the problem, but an organized movement to drive the issue to a successful conclusion.  The elements noted above may be part of that solution, but first the development of an architecture has to be done without bias. 

The “somebody should do something about this” approach won’t work, it hasn’t for the last few decades.  What is needed is a conference organized to identify the full scope of the issue and develop a course of action and accountability to drive the progress of work.

This is a lot of effort, but it has been done before successfully.  Change “laboratory” to “graphics” and you have the state of things in the computer graphics industry in the 1970’s and 80’s.  Since that standards issue was resolved, the computer graphics industry has shown rapid development in products, ease of use, and results.  Put “clinical” in front of “laboratory” and you have the start of Total Laboratory Automation programs in that industry – perhaps a good model to work from.  The same issue and results have been seen in other applications.  This needs to start in lab automation now.

 

Have Your Say
Rate this feature and give us your feedback in the comments section below