A standard is a specification devised to facilitate construction of complex systems from component parts. In the field of biosurveillance, the component parts of particular interest are information systems owned and operated by the myriad organizations that participate in biosurveillance.
The role of standards in information technology is identical to their role in more mundane fields, such as bicycle manufacturing or house plumbing. Standards allow the building of bicycles and plumbing systems ("complex systems'') from components, such as nuts, bolts, and pipes. Standards ensure that the parts fit. In these fields, it is a sure sign that standards have fallen short of ideal when you find yourself driving around town looking for the right "adaptor.''
Thousands of information technology standards exist. Standards are at every level of an information system, from microchips through graphical user interfaces. National or international bodies endorse some standards, and others are de facto standards that have emerged based on usage and acceptance. Standardization has made it possible to create something as complex as the World Wide Web.
Fortunately, if you are building a biosurveillance system, you need to know about only a fraction of the vast number of existing information technology standards (although biosurveillance benefits from virtually all of them). The standards that are most relevant to your task are those required for components, such as hospital information systems and computers in health departments, to exchange data using "the same language.'' We define what we mean by language below.
In this chapter, we first highlight the importance of standards by describing several biosurveillance projects, which varied in the extent to which language standards facilitated or inhibited their construction. We then review existing language standards and other standards that you will need to be familiar with in your work. Finally, we discuss organized efforts to promote adoption of standards. Standards are a prerequisite for building the kinds of systems that you will ultimately need to meet the existing threats. It may be necessary for a biosurveillance organization to act strategically over a prolonged period to bring needed standards into existence and use.
Whether you are building a bicycle or a biosurveillance system, the greater the number of nonstandard components that you must assemble, the harder it will be. To emphasize the difference that standards can make, we discuss three systems. The first is the National Retail Data Monitor (NRDM; the Good). The second is a biosurveillance system for electronic laboratory reporting (ELR) from hospitals (the Bad). The third is a hypothetical biosurveillance system that is more comprehensive than are systems currently being built (the Ugly).
2.1. The National Retail Data Monitor (the Good)
In Chapter 22, we described the NRDM project in detail. Briefly, this project connects data warehouses owned by large retail corporations to a biosurveillance system. The retailers' data warehouses collect and store sales data from their individual stores in a central location. The retailers' systems that enable this centralized collection are complex. They include optical scanners in stores, network connections from each store to the data warehouse, and the central data warehouse itself.
The construction of the NRDM was facilitated by a standard—the global trade item number (GTIN), which is perhaps more familiar to readers by its former name the universal product code (UPC). Retailers use GTINs to identify products. For example, the GTIN 00030045044943 stands for the 50-caplet bottle of extra-strength Tylenol, and the GTIN for the 100-caplet bottle is 00030045044972. Product manufacturers print the GTIN on the outside of each product as a barcode. Checkout scanners read the bar-coded GTIN optically.
Because, in large part, of the widespread use of the GTIN standard, a small team built the initial version of the NRDM in two months. The initial version collected data from 3,000 stores. Two years into the project, the NRDM collects data from 20,000 stores. The project team's effort to build the NRDM was limited to negotiating with retailers for permission to obtain the data and building a system that could store and analyze the data.
Note that the entire NRDM system, if viewed by aliens visiting from space, would appear to be a network that connects hundreds of thousands of optical scanners in stores
Handbook of Biosurveillance ISBN 0-12-369378-0
into a single biosurveillance system. Fortunately, the retail industry had already made 200,000 (20,000 stores times approximately 10 optical scanners per store) of the 200,008 connections1, otherwise the NRDM project would have required significantly more work. The GTIN standard enabled the initial 200,000 connections as well as the final 8.
2.2. Hospital-Based ELR (the Bad)
In 2000, the same team began building an ELR system. At the onset, the team's goal was to connect 20 hospitals in Allegheny County, Pennsylvania to a biosurveillance system. There were no legal barriers. The hospitals already stored data in electronic form, and there were very good reasons (and still are) to create such connections: the benefits of ELR are dramatic in terms of completeness and timeliness of reporting (Effler et al., 1999; Overhage et al., 2001; Panackal et al., 2001).
Unlike the retail industry, however, hospital laboratories do not use GTIN or any uniform method to identify their "products,'' which are the results of laboratory tests. Standards exist, but very few hospitals use them. Instead, hospitals invent their own ways to identify the tests that they conduct and the results of those tests. They use proprietary codes or free text to identify the laboratory test, specimen type, organism, and other results of a test.
The same team that created NRDM in a few months has been working on the ELR project for five years. At present, the ELR project receives data from just 10 hospitals, all owned by a single health system that had integrated its laboratory information systems before the beginning of the ELR project. These 10 hospitals all used the same "vocabulary" of codes internally for microbiology cultures, organisms, and specimen source, but they do not use SNOMED or LOINC, which are current standards for biosurveillance. The team, therefore, had to create a custom adaptor to convert these codes to standard SNOMED and LOINC codes.
In addition to the custom adaptor that translates nonstandard hospital codes to standard ones, the team also had to build an adaptor that allows the biosurveillance system to interpret accurately the results coming from the laboratory information system. Although the hospitals used the HL7 standard to transmit microbiology results, the HL7 standard, unfortunately, is not strict. It allows optionality, permitting data elements to appear in different locations in messages. In addition, the laboratories update microbiology results by using a series of HL7 messages that are not standardized. The adaptor has to remember the entire sequence of laboratory messages about a specific specimen (sometimes spanning weeks) to correctly interpret the latest message. Creating this adaptor was the most time-consuming task, requiring several person-months of effort.
If the same team were to attempt to develop a comprehensive biosurveillance system—one capable of satisfying requirements for early detection and rapid characterization of many types of outbreaks as discussed in Chapter 4—or a biosurveillance system that could meet those requirements for outbreaks that cross national borders, they would encounter "the Ugly.'' It would be impossible to connect that many incompatible systems without first standardizing them.
Was this article helpful?