SICE-ICASE International Joint Conference 2006 Oct. 18-21, 2006 in Bexco, Busan, Korea
Standardization of data flow for laboratory automation software based on XML technology Ki Tak Ahn1 , Wan Kyun Chung2 1
Pohang institute of Intelligence RObotics(PIRO),Pohang,Korea (Tel : +82-54-279-0183; E-mail:
[email protected]) 2 Robotics & Bio-mechatronics Lab., Department of Mechanical Engineering, Pohang University of Science and Technology(POSTECH),Pohang, Korea (Tel : +82-54-279-2172; E-mail:
[email protected]) Abstract: Analytical Information Markup Language(AnIML) is the developing XML standard for analytical chemistry data. It is a combination of a highly flexible AnIML Core Schema that defines XML tagging for any kind of analytical information and a set of Analytical Technique Instance Documents (ATID) XML files, one per analytical technique, applying tight constraints to the flexible core and which in turn are defined by the Technique Schema which can be extended for vendor-specific and institutional-specific parameters. This open-source development platform for a new standard can be applied to the lab automation systems. This paper introduces AnIML as a software platforms in the aspect of interchanging data between analytical chemistry instruments, computer applications, and databases with XML (eXtensible Markup Language) base. Especially focusing the movement of standardization in the area of lab automation, AnIML deserves to be watched as a new way to interchange and store spectroscopy and chromatography data based on XML. This article presents an overview of AnIML and will look into efforts that have been gaining momentum to develop a new all-embracing data standard for analytical data based on XML applicable to the clinical laboratory. Keywords: XML, standardization, data exchange
1. INTRODUCTION Clinical laboratory operations depend fundamentally on automated analyzers. The various types of analyzer– whether used for clinical chemistry, hematology, immunoassay analysis, or measurement of coagulation or blood gas–share common aspects. We can classify an analyzer into the five subsystems that generally make up an analytical laboratory instrument: the user interface, transport fluidics and robotics, processing elements, control and communications, and supporting electronics (figure (1)). Each of these subsystems plays a vital role in delivering reliable, accurate, and precise results to the laboratorian in a cost-effective and timely manner. There might be lots of data transfer and the format of each data set can be shared between subsystems. From the view of users or operators, these critical data must be preserved in its entirety and OS independent. In this paper critical data means clinical test data. It must be human readable (not binary or proprietary formats) and must be usable today. But there has been many analyzer systems from different manufacturers and there has been many TNF (Technology Neutral File) formats in most areas and they bring some problems: maintenance and versioning nightmare for developers, new application must support all previous formats, and “My format is best” syndrome [1]. Data standards serve multiple functions; in the past the focus was on a format for information exchanges between data systems; more recently there is a push from the pharmaceutical sector to preserve data for long-periods (3060 years) to meet FDA (Food and Drug Administration, USA) requirements, so we need data standards serving
Fig. 1 Interactions among the clinical laboratory systems
as long-term data repositories that can outlive the vendor software as well as the hardware; finally, in the future we may hope for vendor-independent processing or viewing of analytical instrument data. Some of the required properties that have been identified so far include: flexible; strongly-constrained; simple to understand; extensible; long-lived; not only quickly machine readable but also human readable; capable of being verified and validated; capable of handling complex analysis contexts (metadata); capable of being stored in or restored from databases; supports conversion from
prior standards (especially ANSI and JACMP – mentioned more in section 2); hardware, operating system, vendor, and software-independence; supports encoding raw or processed data. One of the aspects that make the task of creating analytical information standards difficult is the constant evolution of analytical techniques. As a result, it is important that technique-constrained software must be able to read their technique sections of the standard without failing when encountering any possible extensions.[2] The AnIML project was begun in ASTM Committee E13 on Molecular Spectroscopy and Chromatography to provide a standard, web-aware mechanism for interchanging and storing spectroscopy and chromatography data based on XML (Extensible Markup Language). Markup languages are used in information technology to describe complex aspects of entities. For example, the Hypertext Markup Language (HTML–the language that enables the Internet) describes how entities on a computer screen are to be laid out and displayed by incorporating descriptive tags with each data entity. XML is similar, but more general, in that it is used to describe data–delineating not only what the data are, but also how they can be used, displayed, converted, etc. HTML describes how data look, while XML describes what data are. Unlike HTML, there are no predefined tags in XML. The tags are made up for each application and are formally defined in the XML application’s schema or document type definition. Many folks have used XML likely without ever knowing it, because XML is heavily used on the web to enable ecommerce among other things. AnIML is discussed in many conferences for laboratory automation and chemical instrument manufacturing because it is not on the finished but on the developing stage. Here in this article we mainly refer the discussion at the recent Pittcon2006 (Pittsburgh conference on analytical chemistry and applied spectroscopy) : the world’s largest, most comprehensive conference and exposition for laboratory science.
2. DEFINITION OF TERMS 2.1 Laboratory Devices Because of current confusion about the proper definitions of automated laboratory devices, the following definitions have been suggested[3]. Total laboratory automation is a system that integrates pre-analytical and analytical automation. Modular automation consists of integrated modules, including pre-analytical and analytical modules that function as a total laboratory automation system. Workcells are multifunctional automated systems that often combine several functions within one device (eg, the combination of chemistry and immunoassay and sample preparation in one automated system). A workstation is an automated device with a more limited menu of functions in a single unit, such as a preanalytical workstation (eg, the Tecan GENESIS FE500 that performs the following functions: centrifuges, decaps, aliquots, relabels, and sorts.
Laboratories now have many options for automating preanalytical and analytical processes. The best options for small laboratories are consolidated instruments and pre-analytical workstations. Medium-sized hospitals should use pre-analytical workstations, analytical workcells, or modular systems. Finally, large laboratories can purchase modular pre-analytical or analytical systems or total laboratory automation (TLA). One popular form of laboratory automation is the Total Laboratory Automation popularized by Dr Masahide Sasaki, formerly at the Kochi Medical School in Nankoku City, Japan. There are already 190 systems installed in Japan, >40 in North America, and >5 in Europe. The most recent trend in laboratory automation is the preanalytical workstation. Many small to medium sized laboratories have purchased these devices to provide automated specimen accessioning, aliquotting, labeling, and sorting. Among the benefits of using this technology are the following. A workstation allows optimal space utilization, reduces installation time, reduces training, improves quality and safety, and increases productivity. A workstation should be operable with one full-time or even part-time employee, can be installed in
