For Biosurveillance

This section describes how an architect might approach the design of an information system that interoperates with many organizations that have information systems with little or no native ability to interoperate. When constructing pan-enterprise systems, multiple technical construction teams may be located in different organizations (e.g., hospitals, laboratories, governmental public health, water companies). In both industry and biosurveillance, these teams may be difficult to coordinate unless the architectural style allows them to work relatively independently.

An appropriate architectural style for a system that requires interoperability between organizations but maintains their independence is a service-oriented architecture (SOA). We will discuss SOA, how Amazon.com used SOA to handle more than 10 million computer-to-computer exchanges of data per day with the computer systems of independent organizations in under three years (Roush, 2005), and how SOA could accelerate the development of worldwide biosurveillance systems.

figure 33.3 There are four layers in this enterprise architecture for biosurveillance—a presentation layer,a business layer,a data layer,and a security layer. The presentation layer accesses the business layer. The business layer accesses the data layer. All layers access the security layer. The presentation layer comprises the user interface component and notification components. The business layer comprises the detection and characterization components. The data layer comprises the data collection, storage, and directory components.

figure 33.3 There are four layers in this enterprise architecture for biosurveillance—a presentation layer,a business layer,a data layer,and a security layer. The presentation layer accesses the business layer. The business layer accesses the data layer. All layers access the security layer. The presentation layer comprises the user interface component and notification components. The business layer comprises the detection and characterization components. The data layer comprises the data collection, storage, and directory components.

The architectural principles of SOA start with those of clientserver architecture (i.e., client components make requests to server components that return appropriate responses) but add additional principles that facilitate independent construction of the system's components. It is these rules that make SOA ideal for a pan-enterprise architecture for biosurveillance.

Services are the equivalent of components in other architectures (e.g., a database is a common component in a client-server layered architecture). When designing a pan-enterprise system in the SOA style, the building blocks that an architect thinks about are the services that systems owned by different organizations will provide to each other. According to Erl, (2005) services in an SOA adhere to the following principles:

• Loose coupling—Services maintain a relationship that minimizes dependencies and only requires that they retain an awareness of each other.

• Service contract—Services adhere to a communications agreement, as defined collectively by one or more service descriptions and related documents.

• Autonomy—Services have control over the logic they encapsulate.

• Abstraction—Beyond what is described in the service contract, services hide logic from the outside world.

• Reusability—Logic is divided into services with the intention of promoting reuse.

• Composability—Collections of services can be coordinated and assembled to form composite services.

• Statelessness—Services minimize retaining information specific to an activity.

• Discoverability—Services are designed to be outwardly descriptive so that they can be found and assessed via available delivery mechanisms.

The most important principles for interoperability between organizations are the principles of loose coupling, service contracts, and discoverability. Loose coupling allows organizations to build services independently. Service contracts are a set of documents that completely describe how to access the service. Service providers usually write service contracts by using a language that a computer can understand, such as XML (e.g., the Web Service Description Language [WSDL]). Discoverability allows organizations that need to interoperate to find required services easily via a registry (e.g., white pages for a computer).

5.2. The Example of Amazon.com

Amazon.com is an instructive case study of SOA, especially for biosurveillance, because it is a company that depends on real-time interoperation with the information systems of other organizations (enterprises).

In 2002, Amazon.com had a problem. Their sales associates (organizations that sell Amazon.com products through their own Web sites) had a need for real-time, up-to-date product information in order to market and sell Amazon.com products. According to Amazon.com's director of web services, Jeff Barr:

For a long, long time people have been asking for a more structured way to access our data and, in fact, for many years people have been writing robots that would go to our site and download various kinds of information. And we were generally actually pretty friendly to robots, allowing them to proceed whereas a lot of other sites would just kind of block them off. But we talked to these folks, kind of, trying to understand what they wanted, and we tried to give them something a bit better. (Kaye, 2003)

Before coming up with a solution to the preceding problem, Amazon.com took the time to understand the needs of their sales associates and their capabilities. The sales associates needed a way for their information systems to query the Amazon.com database for specific product information (Figure 33.4). The solution, known as Amazon.com's E-commerce service (ECS), was the first service in Amazon's SOA. As we will see, the ECS had benefits that have gone beyond the initial needs of their sales associates.

A key benefit to SOA is the speed at which a large number of organizations can begin to interoperate. In the three years since Amazon.com launched its ECS, more than 140,000 organizations (or individuals) have signed up for the service, and experts estimate that these organizations make more than 10 million requests for data each day (Roush, 2005). In contrast, in the four years since the anthrax postal attacks in fall 2001, only a small fraction of the 3,000 health departments, 160,000 laboratories, 7,000 hospitals, and myriad other organizations with roles in biosurveillance in the United States have begun to interoperate at the computer-to-computer level in an effective manner.

An unexpected result (and benefit to Amazon.com) was novel applications that developers created by using the ECS. Examples of these applications include a program that lets students order textbooks from Amazon.com directly from an academic course management Web site (http://www.concord-usa.com/amzcourseiteminfo.htm), comparison engines that let sellers compare their prices with the prices of other sellers (http://www.monsoonworks.com/mw.main/index.asp), and a

figure 33.4 By use of the Amazon.com Web services,the Web sites of sales associates have access to product information,an electronic shopping cart, inventory information, and billing services.

program that lets users browse through books, music, and movies as an interactive "pile of books'' (http://amaztype.tha.jp/).

ECS was the beginning of Amazon.com's investment in SOA. They view it as a fundamental aspect of the company's IT strategy. Since the launch of the service in 2002,Amazon.com has continued to develop their Web-service capability, producing four revisions of the ECS and adding additional complementary services, including the Amazon.com Historical Pricing Service (three years of historical pricing information for all of Amazon.com's products), Alexa Web Information Service (a Web search engine), and the Amazon.com Simple Queue Service (an electronic version of a message box that enables separate computer applications to interact asynchronously). They also plan to utilize Web services to interact with their other partners, such as the retailer Target (Puget Sound Business Journal, 2003).

Amazon.com is not alone in focusing on SOA. A 2004 survey of 473 enterprise buyers by the Yankee Group of Boston revealed that in the next 12 months, 75% plan on investing in the technology and staffing necessary to create a SOA. Seventy-one percent of health-related companies intend on using SOAs (The Yankee Group, 2005).

5.3. Applying SOA to Biosurveillance

We now show how an architect could apply the principles of SOA to facilitate pan-enterprise biosurveillance. First, we describe an extremely simple, but real and functioning biosurveillance service. Then, we build on this example to discuss the design of a more comprehensive system.

5.3.1. The National Retail Data Monitor Web Service

The Web service offered by the National Retail Data Monitor (NRDM) is an example of a service in a biosurveillance SOA. The NRDM (discussed in Chapter 32) is a system that collects sales data for selected OTC healthcare products.

Before the NRDM created a Web service, it transmitted its data to public health departments either through its own user interface or by daily file transfer. The latter approach met the needs of health departments that wished to incorporate the data into their own biosurveillance systems. But, the file transfer approach had several limitations for both the NRDM and the health departments, which led the NRDM to develop a Web service (Figure 33.5).5

In the Web-services method of data distribution, computers in health departments query the NRDM for data whenever they need the data (Figure 33.6). For example, a computer in a health department might send a request to the NRDM Web

figure 33.5 National Retail Data Monitor (NRDM) Web Service. Similar to the Amazon.com Web services, the NRDM Web Service provides access to the sales information of approximately 20,000 retail locations. This example is an extremely simple example of the use of Web services by two organizations that wish to exchange data or services.

figure 33.5 National Retail Data Monitor (NRDM) Web Service. Similar to the Amazon.com Web services, the NRDM Web Service provides access to the sales information of approximately 20,000 retail locations. This example is an extremely simple example of the use of Web services by two organizations that wish to exchange data or services.

figure 33.6 Future RODS Data Services.In the future,RODS laboratory will provide biosurveillance data via Web services to health departments and other biosurveillance applications. Presently, these Web services include the National Retail Data Monitor (NRDM) Web service,which distributes over-the-counter medication sales data. In the future, the RODS Laboratory will have chief complaint Web service for distributing chief complaint data.

figure 33.6 Future RODS Data Services.In the future,RODS laboratory will provide biosurveillance data via Web services to health departments and other biosurveillance applications. Presently, these Web services include the National Retail Data Monitor (NRDM) Web service,which distributes over-the-counter medication sales data. In the future, the RODS Laboratory will have chief complaint Web service for distributing chief complaint data.

5 These limitations included: (1) a health department had to store a local copy of the NRDM data, which are voluminous, (2) the health department needed to create processes that parse the data files and update the data. (3) even though the NRDM continually processes OTC sales data received from retailers and makes it available via a Web-based user interface, the local public health department receives updates on OTC sales only once a day.

service to "send me the daily sales of diarrhea remedies for zip code 70808 between August 1 and September 1 and the number of stores in that zip code that are reporting these sales.''

The work required by the RODS Laboratory to create the NRDM Web Service was not extensive. Because the NRDM already made OTC data available via a user interface, it already had the needed query capability to the NRDM data storage component. The RODS Laboratory IT staff exposed this query capability as a Web service that adhered to SOA principles.

The NRDM Web Service is just one of potentially thousands or hundreds of thousands of services that could exist in a biosurveillance SOA. Biosurveillance will realize the full potential of SOA when more organizations offer services to each other.

Figure 33.7 illustrates the set of organizations that might inter-operate during an aerosol release of anthrax in a large city such as Dallas or Fort Worth. In this figure we consider the needs of just one of the "business" partners—the health department— and we assume that the health department is responsible for coordinating the overall health response to the event, including assessment of risk, promulgating guidelines for prophylactic treatment, and declaring areas of the city unsafe for inhabitation. As in the 2001 postal attacks, such a scenario would generate an enormous volume of laboratory testing. Investigators would presumably distribute the specimens and requests for tests to the local hospital laboratories and the laboratory networks discussed in Chapter 8 (and depicted in Figure 33.7 either individually or via their participation in laboratory networks).

figure 33.7 Pan-enterprise architecture from the perspective of a health department. Dotted arrows denote nonautomated access to data. Solid unidirectional arrows denote automated one-way reporting that does not support data requests. The bidirectional arrow between the National Retail Data Monitor (NRDM) and North Texas Advanced Practice Center denote support for data requests. LRN indicates Laboratory Response Network; NAHLN, National Animal Health Laboratory Network; FERN, Food Emergency Response Network, eLRN, Environmental Laboratory Response Network; and USAMRIID, United States Army Medical Research Institute for Infectious Diseases.

figure 33.7 Pan-enterprise architecture from the perspective of a health department. Dotted arrows denote nonautomated access to data. Solid unidirectional arrows denote automated one-way reporting that does not support data requests. The bidirectional arrow between the National Retail Data Monitor (NRDM) and North Texas Advanced Practice Center denote support for data requests. LRN indicates Laboratory Response Network; NAHLN, National Animal Health Laboratory Network; FERN, Food Emergency Response Network, eLRN, Environmental Laboratory Response Network; and USAMRIID, United States Army Medical Research Institute for Infectious Diseases.

We assume that the health department will require access to individual results (e.g., the result of testing a clinical sample taken from patient P or the environmental samples taken from building X 2 days ago) and that these samples may have been processed at any of the organizations depicted in the figure. If each of these laboratories or networks shared data via a service, the investigation process would be more efficient.

At present, the level of direct computer-to-computer exchange of data between the health department and these myriad organizations is low, as depicted by dotted lines between entities.Where exchange of data does exist, it is often a one-way flow of information (e.g., electronic laboratory reporting) that does not support data queries. Although it is true that some of the laboratory networks provide a Web site that public health entities may access, they involve different passwords and data formats, and the end-user must have considerable knowledge of where a specimen was processed or likely to have been processed in order to find it. You may recall from earlier chapters that an essential part of the biosurveillance process is the collection of additional data. Services in an SOA that distribute biosurveillance data through a query mechanism (e.g., the NRDM Web Service) support the collection of additional data.

SOA has considerable potential to accelerate progress toward the goal of interoperability among organizations involved in biosurveillance because it allows each organization to articulate its needs in terms of data and services and negotiate with other organizations to provide those services. These negotiations— when framed in terms of data and services—are eminently understandable to the chief executive officers, who must decide matters of cost and prioritization of effort. Once the parties agree on the terms of a service, IT staff can take these service terms and work independently to externalize the organization's existing capabilities by using available tools and standard technologies for building a service.

5.3.2. Adding Web Services to an Existing Information System

In this section, we show how to add a Web services component to an organization's existing information systems. Adding services to an existing architecture is not as difficult as previous technology upgrades, such as the movement from mainframes to personal computers. The Yankee Group acknowledges that "embracing SOA is cheaper than other types of IT overhauls because the technology is based on the Web. That's interesting to a lot of large enterprises, especially the ones involved with numerous partners and acquisitions'' (Stansberry, 2005).

Services externalize the existing capabilities and resources of an organization. For example, a typical health department collects surveillance data, such as notifiable disease reports and possibly patient chief complaints, from emergency departments for its region. The health department can externalize part of these data for the benefit of health departments in adjacent jurisdictions (or anywhere in the world) by adding a service as

Presentation Layer

0 0

Post a comment