RODS Data Security and Confidentiality

I. Data Security

1.1 Data Transmission

RODS provides a secure file server') that allows data providers to upload their batch data through secure file transfer protocol (SFTP) or secure socket layer (SSL) connections. The file server is located in a demilitarized zone (DMZ.) and is protected by a firewall that consists ofrules — allowing only specific remote hosts (IPs) to reach it -- maintained by the network security group at the University of Pittsburgh. The firewall plays the role of a security guard that blocks all external unauthorized connections.

The firewall rules protecting the secure file server only permit access through a certain port (e.g., port 22) for connections from remote hosts An authorized person from a provider may request the addition of a new rule to allow an external host to connect to the secure file server. This request requires the approval of the internal change management team prior to being implemented. Once a request is reviewed and approved, it is submitted to the network group to add a firewall rule to allow the new host to connect to the server from their given IP address.

The RODS IT group issues a unique cryptographic DSA public key to all new data providers for SFTP or SSL connections during the setup stage. Each data provider lias its own unique public key to encrypt their data before sending and only the corresponding DSA private key on the RODS server can decrypt the message.

The RODS secure file server is configured with secure packages to guarantee each account on the server is quarantined to its home directory. Upon authentication each user's account is set to chroot (send) them directly to their home directory and not allow them to access or view any other directory on the server. This process protects each user's data by making the user's home directory look like the root directory, thus the user cannot see, nor can they access, any odier directory structure on the server. The process also limits access to this area to just the user and the system administrator.

L2 Data Relocation

The RODS data loading application retrieves the data files sitting in the data provider's local directory through a secure network file system (SNFS) link. The data loading process, running on the OTC database server cluster located in the database network zone, loads the data files from the file server into an Oracle data warehouse, and then moves the data files from the file server to the database server. The database server cluster resides in the same VLAN as the file server, thus ensuring that the transfer happens locally within one network segment. There is also a rule set in place between the production server cluster and the file server to allow only this traffic to pass between them and to block ail other tr affic

1.3 Data Archival

A scheduled task on the backup application server moves the raw data files on the database server to tape once a month. Once the data is archived, a RODS system engineer moves the tapes oif-site to a secure location where only a select number of authorized personnel in the RODS Laboratory can access them. At no point during tins archival and storage process does a person outside of the RODS Lab have access to the data.

II. Data Con fid entiaiity

During the period where the data files are stored on the database server, only a select list of RODS lab personnel lias access to them. These personnel are the system administrators and are responsible for maintaining the security and integrity of each machine. No other lab personnel or external parties have access to this data.

Access to the raw UPC data in a database is only limited to RODS database administrators who are responsible for database backups and maintenance. All the users who need to access aggregate OTC sales at the product level need to sign a data use agreement (see attached document). All the public health users can only retrieve aggregate data at the product category level. No individual UPC data are accessible by public health users. RODS researchers who need to study OTC sales at UPC product level will not be able to see vendoi information.

figure 34.3 National Retail Data Monitor (NRDM) data security and confidentiality.

and outbreak detection from chief complaint data when requesting emergency room chief complaints from hospitals (see Wagner et al., 2004b). Similarly, when attempting to acquire over-the-counter medications sales data from retailers, we provide decision makers with publications about the National Retail Data Monitor (NRDM) (Wagner et al., 2004a, Hogan et al., 2005). In the future, we will likely provide Chapter 22 from this book. We also develop PowerPoint presentations of the same materials when we are planning to personally present our case to data providers.

2.1.6. Provide Draft Legal Documents

Data providers must have assurances that the receiving organization will process and store the data securely. To that end, it is advisable to execute ethically optimized and legally binding documents that detail the measures you employ to safeguard the data. These documents are usually DUAs, which can also be called by other names, e.g., memorandum of understanding (in this chapter, we refer to all such documents as DUAs in order to avoid confusion). These agreements must be reviewed and approved by each organization's legal counsel—which include the data provider, the data requester, and possibly other organizations involved in processing the data, for example, biosurveillance service or data users. In addition, when such agreements involve hospitals, the hospital may choose to have its ethics committee or Health Insurance Portability and Accountability Act) HIPAA-compliance officer review the agreement. We discuss DUAs in detail shortly.

In addition to the primary agreement between the data provider and requester, a health department or other biosurveillance organization may have existing documents that it requires end-users of the biosurveillance system to sign. These documents cover the proper use of passwords and handling of data. Because these agreements are an element of the overall approach to preserving confidentiality and security of data, their existence is germane to discussions. A data requester should be prepared to discuss or provide end-user agreements to the potential data provider. We also discuss end-user agreements later in this chapter.

2.1.7. Getting to Yes

"Getting to yes" means identifying the person(s) in an organization who can make a decision or a commitment on behalf of the organization, getting their verbal agreement to participate, obtaining signatures on a DUA (or other legal contract or agreement), and finally getting to the point at which the IT work begins.

Identifying the person or persons who can make the decision may take time because a request for data for biosurveillance is outside the usual business of most organizations. More often than not, such a request will require the attention of the chief executive officer (CEO). CEOs are busy, so it may be worth suggesting that the CEO consider delegating decision making to an official lower in the chain of command. In some organizations, more than one person must give approval, and arranging a conference call to discuss a request with all decision makers may facilitate getting to yes. For certain types of data, most notably clinical data, there may be a need for more than two organizations to sign an agreement or for multiple agreements to be executed pairwise among organizations. For example, if a health department's surveillance system is not located in, or operated by, that health department but rather by another organization, there may be need for two agreements. One agreement will be between the health department and each hospital within the health department's jurisdiction that will be providing clinical data, and another will be between the health department and the organization operating the biosurveillance system being used by the health department.

The process of obtaining legal approvals on DUAs, service contracts, or other binding agreements can introduce delays or even be a reason for failure of a negotiation. Often, an organization's attorney is not fully apprised of a project and may introduce a delay, or attempt to block participation altogether, simply because he or she lacks full understanding of the project. Procrastination may be the result of a judgment about workload priorities within the legal office. A data requester can minimize such delays by maintaining regular contact with the decision maker in the organization to ascertain the status of the legal process and, if unknown, asking him/her to investigate if there is a delay.

There may be specific aspects of the required IT work that are difficult for an organization to satisfy. For example, the organization may not have specific IT infrastructure or staff required for a project. It will also be problematic if a programmer within an organization does not have enough expertise or is simply not dependable in bringing the project to fruition. In these circumstances, regular contact with the person who approved the project is valuable in bringing to his or her attention a possible internal problem that is delaying completion of the required IT work.

In summary, getting to yes requires tenacity and follow-up on the part of the data requester. He or she must maintain regular contact with the people assigned the various tasks involved in getting to yes, including the decision maker, the person assigned the task of directing the organization's steps toward participation, the legal counsel who will approve and/or sign the DUA, and the IT staff assigned to a project.

A data requester should never consider a negative reply to a request as final decision, but rather as a temporary barrier. Decision makers within an organization change positions or take positions with other organizations, legal representatives change, and IT infrastructure within organizations usually improves with time. As change occurs regularly within organizations, data requesters should make repeated attempts to change negative decisions.

2.2. Data Use Agreements

A DUA is a contractual agreement between two or more organizations, involving either a one-way or two-way exchange of data. One can also call a DUA a data use and confidentiality agreement.1 A DUA affords protection to both organizations providing the data. The DUA is a means for protecting the data

1 The term 'Data Use Agreement' has a specific technical meaning in connection with The American Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule that should not be confused with the term as we use it here. We discuss the HIPAA Privacy Rule later in this chapter.

provider's interests, including privacy, security, and liability concerns. The process of crafting it and ratifying it in both organizations will entail considerable discussion of important issues that will reduce the possibility of misunderstandings in the future.

Appendix G of this book is an example DUA for use between hospitals and health departments. We have executed this agreement many times, and it contains clauses that cover many issues that arise in such negotiations. The clauses in the agreement address the following: identification of all parties to the agreement; legal basis for providing the data; definitions used in the agreement; the data specifically requested; definition of authorized users of the data; assurances regarding security, confidentiality, and data management; and, finally, standard disclaimers, warrantees, compliance, term of agreement, and termination clauses. It may also include specific stipulations concerning audits, options to publish, options for research, right to terminate, reports, or institutional review board (IRB) approvals.

The DUA should describe the types of data that the two organizations anticipate exchanging and include specific examples of those types of data. It is wise to include types of data that the organizations anticipate exchanging in the future, even if the intent is to initially only share a subset of the data described. This approach will obviate the need to re-execute or modify the agreement. The DUA should clearly define the scope of the project

If possible, the data requester should provide a previously successful DUA as a suggested starting point. Lawyers and decision makers have previously vetted successful agreements; thus, such agreements are more likely to address satisfactorily the concerns of the present organization. The data requester should explain to the prospective data provider that the document is the result of previous negotiations with similar data providers. This approach may save considerable time as most legal counsel will be concerned with similar issues and will also value an agreement that has precedence associated with it. Data providers, however, must have the option to revise the DUA based on the input of their legal counsel. Legal counsel on both sides must approve any revisions.

Once both parties agree to the final wording of the document, the authorized representatives of both organizations should sign two copies of the document, with each organization having an original signed document. Some data providers will demand ratification of an agreement before permitting any technical work to begin. Others will allow a concurrent process; that is, they will allow the data connection and transmission work to proceed while negotiating the specific terms of the DUA.

2.3. End-User Agreements

Anyone who will see confidential data coming from any source must sign an agreement to acknowledge use of the data and for what purpose, to guarantee confidentiality of the data, and correct handling and maintenance of the data as per legally-binding clauses set forth in all DUAs with data providers. These agreements can have various names, for example, authorized access agreement, account access agreement, or acknowledgement of DUA. Titles of agreements can also indicate the specific type of data to which the user will have access. There are basically two types of "end-users" of data that must sign a "user" agreement.

2.3.1. End-Users of the Biosurveillance System or Its Data

The end-users of a biosurveillance system should sign an agreement that includes a description of the data to which they will have access. This agreement should cover the provisions of the DUAs negotiated with all data providers (end-users typically see data obtained from multiple sources). They should include the identity/title and affiliation of the individual, the reason for using the data, and any restrictions on the use of the data.

Appendix H and Appendix I provide two examples of end-user agreements.

2.3.2. Technical Developers or Operators of Biosurveillance Systems

All technical personnel who have access to the data (i.e., personnel working on maintenance of or improvements to the biosurveillance system) should sign an agreement to acknowledge data use and confidentiality requirements. Every employee (current and new) who has or will have access to the data should sign such an agreement. The document should indicate that the signer is aware of the content of DUAs with data providers, and that he or she agrees to abide by the provisions of those agreements. The agreement must require the signer to agree to the following additional provisions: that he or she may only access the data for the purposes of development of the biosurveillance system for which the data has been acquired, and that he or she will not disseminate the information to a third party. It is also advisable to include a clause stating that the user agrees to submit any publications based on the data for review and approval to ensure that no one inadvertently discloses confidential data. The agreement should include a list of all data sources and data types provided to the biosurveillance system (for an example, see Appendix J, "Acknowledgement of Data Use and Confidentiality Agreement").

It is good practice to hold an annual (or even twice yearly) internal security meeting in which employees sign this agreement yearly, and the agreement should be revised to list new data sources and types of data added that year. This practice serves to reinforce the importance of confidentiality and security

In addition, all independent contractors working on any project that uses confidential data must also sign an agreement that includes the provisions noted above. This type of agreement can be some altered form of the example given in Appendix J, which lists only those data providers whose data will become knowledge of independent contractors.

2.4. Negotiations with Healthcare Organizations

In this section, we focus on the specifics of a negotiation between a health department and a healthcare system within that health department's jurisdiction. The relationship between these two types of organizations is arguably the most important one in biosurveillance. Although health statutes require disease reporting, there are other potentially desired data and services that a health department may request from a healthcare organization that require negotiation.

In negotiating for data from a healthcare system, the key to success is education. Hospitals and healthcare systems are businesses, and they will base their decisions to participate in a project on a consideration of cost and benefit. That analysis will require input from various departments and key personnel within the organization (see subsequent paragraphs that identify departments and key personnel). Each of these departments or individuals will need to know how this new project is going to affect them, and the decision maker, in turn, may ask each of them for input on the decision.

In getting to yes, it is vital to educate each of the key personnel whom the decision maker is going to turn to for input on the decision and to tailor that education to address the concerns coming from each of those personnel or departments.

We have tried three approaches to negotiations with a healthcare system: (1) a "top down" approach, in which we first contact the CEO or president about participating in the project; (2) a "bottom up" approach, in which we first contact other key personnel within the organization to champion the project up the chain of command; and (3) a two-pronged method, in which we contact both the CEO and key personnel simultaneously. We have had successes with all three of these approaches. Choosing your method will depend on existing relationships within the hospital. If there is an enthusiastic supporter for biosurveillance of this kind at any level within the organization, you may wish to start with that contact. If you have no existing relationships and are cold calling, you may wish to opt for the two-pronged method. Whatever the approach, we have found that the key personnel and departments within a hospital or healthcare system include the following:

1. The CEO or president will be the decision maker. The CEO or president may turn to his/her chief financial officer (CFO), legal counsel or HIPAA privacy officer, IT director, and possibly others for input on how participation in the project will affect the organization. In our experience, we have seen different levels of interest and involvement by the CEO. Some CEOs, when approached directly, may be very taken with the project and direct staff to meet with you and get it implemented. Other CEOs may elect to participate in the project based solely on recommendations from within the organization (e.g., from an emergency planning director or emergency department [ED] director) and simply sign off on a DUA. However, CEOs may want input from all relevant departments before agreeing to participate. In negotiations with the CEO or president of a healthcare system or hospital, be prepared with clear, bullet-pointed answers to questions related to all areas of operation. Examples of questions you may hear include the following: How much will this cost us? How much IT work will this entail? What will legal have to say about it? What is in it for us? Your answers will need to be consistent with the answers the CEO will get if he or she asks the same questions internally. For example, if you tell the CEO the project will require 10 person-hours from the IT department, the CEO had better hear the same answer from the IT department.

2. The CFO will assess the cost to the organization. The CFO will want a cost analysis that includes person-hours, hardware, and other costs to the hospital. If the health department requires participation in the project, be prepared with information about how the health department is going to work with the hospital to cover its internal personnel, hardware, or other costs.

3. The legal counsel, who the CEO will consult about the legal ramifications of participating in the project and to approve a DUA. These discussions may also include the HIPAA privacy officer. When negotiating, be thoroughly familiar with HIPAA issues related to the data you are requesting. As with any data provider, you want to ensure the comfort level of the hospital with privacy, security, liability, and other issues. Be prepared to be flexible on language in the DUA and, as much as possible, defer to the needs of the hospital. Offer a template of a successful DUA from past implementations. Getting to yes is not possible without the approval of a hospital's legal counsel.

4. The IT director will assess feasibility for the implementation, including hardware requirements, availability of personnel, and other technical issues. You may encounter a variety of scenarios on the IT side: The hospital may not have the appropriate personnel in-house for the implementation; the hospital may outsource some or all of its IT work; the hospital's IT vendor may demand thousands of dollars to create an interface; or the IT department may claim other priorities. In some cases, the IT director may not know details of the systems his or her own department is running, and you will need to speak directly with network and interface engineers. You may also find that an IT director may say the implementation is not possible because the hospital does not meet technical requirements when, in fact, network and interface engineers will tell you there is no problem at all. If an IT director is holding up approval of the project, it will be helpful to enlist the support of the engineers who will actually do the work and who will be able to give their IT director an accurate assessment of the actual time or cost involved.

5. An ED chair or infection control practitioner, although not directly involved in an implementation, may be the biggest champion for the project. Most often ED personnel are very enthusiastic, as they understand the importance of biosurveillance. Enlist the aid of the ED chair in selling your project at all levels of the organization.

At all levels within a healthcare system or hospital, you may encounter the objection that a department has other priorities. A CEO who is well educated about the time and financial costs of the project will be better able to direct his or her departments to cooperate with the implementation.

General recommendations are the following: (1) educate the key personnel before the CEO talks to them, and their roles and the scope of the project will become clear and your implementation will move along faster if they are prepared with their support of the project when the CEO asks for their input; (2) tailor the discussion to your audience because, for example, infection control does not need an in-depth discussion of the legal issues; (3) be prepared with specifics such as the anticipated number of person-hours that will be required or precisely how much money the project will (or will not) cost the hospital; and (4) prepare brief hard-copy documents that addresses how the project will impact each department.

To illustrate more concretely some of the types of issues one might need to address, following are examples of negotiations.

2.5. Case Study

We requested chief-complaint data from two healthcare systems before the February 2002 Olympic Winter Games in Utah. Both healthcare systems were technically capable of providing the requested data in an electronic format and in real time. Together, they accounted for 19 urgent care centers, 10 EDs, and the polyclinic located in the Olympic Village.

This negotiation involved the healthcare systems, the Utah Department of Health (UDOH), six local health departments, and the University of Pittsburgh. Specific individuals included the state epidemiologist, an Olympic surveillance coordinator, a vice president for medical research, an associate CIO, a medical informatics department chair, the director of the RODS Laboratory, and lawyers representing the healthcare systems,

UDOH, and the University of Pittsburgh. The negotiation lasted seven weeks.

Several issues framed this negotiation:

• UDOH and the Salt Lake Olympics Committees had spent years planning and preparing enhanced biosurveillance systems for the 2002 Olympic Winter Games. The biosurveillance systems included daily polling of selected physicians, pharmacies, veterinarians, the poison control center staffs, and the forensic pathologists (sentinel surveillance); 24-hour batch-mode syndromic surveillance for Intermountain Health Care's urgent care facilities (an urgent care facility is a clinic that sees patients without appointments); and a manual ED syndromic surveillance system employing daily review of encounter logs and the medical records of syndromic patients. Thus, healthcare systems in Utah were already responding to a legal mandate to share data and allow intrusive chart reviews during the 2002 Winter Olympic Games.

• UDOH had established administrative rules providing the legal framework for these systems months earlier; however, the RODS system was sufficiently different in that it was not covered by the rule.2

• One health system classified RODS as a "research project" because it was not the planned-on and agreed-to surveillance methodology. Consequently, before allowing the implementation of RODS, compliance with federal privacy law (HIPAA) and the IRB approval were required. Although the HIPAA privacy rule did not go into effect until April 14, 2003, the healthcare system chose to adopt their understanding of the then current draft privacy rule. The proposed HIPAA regulations permitted disclosure for public health surveillance activities but did not specifically address the sharing of data for public health surveillance research.

For each healthcare system, our goal was to execute a trilateral DUA signed by the healthcare system, UDOH, and the University of Pittsburgh. We had used this type of agreement successfully in Pennsylvania. After a seven-week negotiation,

2 Prior to the Salt Lake Olympics, UDOH put into effect an administrative reporting rule designed to establish legal authority for syndromic surveillance. Administrative rules are statements written by state agencies that have the effect of law. Under this rule, designated emergency centers were to report syndromic information for patients from the preceding day's encounters, either by reporting it themselves or by allowing UDOH representatives to gather the data. Encounters required a report if and when diagnostic information indicated the presence of one of 11 syndromes defined by the UDOH (i.e., Respiratory Tract Infection with Fever, Gastroenteritis without Blood, Bloody Diarrhea, Febrile Illness with Rash, Suspected Viral Hepatitis, Meningitis/Encephalitis or Unexplained Acute Encephalopathy/Delirium, Sepsis or Unexplained Shock, Unexplained Death with History of Fever, Botulism-like Syndrome, Lymphadenitis with Fever, or Illicit-drug-related Episode). The report included the following protected health information: the reason for visit, chief complaint, presenting diagnosis, final diagnosis (when available), facility, date/time of visit, patient demographics (age, gender, residential zip code), the syndrome detected, admission status, and a record identifier for follow-up investigation. RODS did not quite fit this rule because the seven syndromes used in RODS were more general.

we executed one trilateral agreement and one bilateral agreement (signed by one healthcare system and the University of Pittsburgh). This outcome reflects the different views held by the health systems on sharing data with the UDOH. Because the one healthcare system received partial funding from the state, the working relationship between the two entities (at least from a data provisioning perspective) had always been strong, making data sharing for collaborative public health projects relatively commonplace and painless. The second healthcare system was a large not-for-profit healthcare organization that directly competed with the first. According to a senior vice president, it had, on occasion, borne the brunt of state mandates to provide clinical data for public health purposes because of its dominant market share and advanced data systems. In addition, its data often became property of the state. The final agreement permitted UDOH to only view aggregate time-trended and spatially displayed data (e.g., absent the free-text chief complaint and with age reported in five-year ranges) and could only receive more detailed data in the event of a public health emergency. The solution also entailed that the data were located on servers at the University of Pittsburgh.

In this project, organizational issues outweighed technical issues. The factors that increased the chances of success in this negotiation were that all of the stake-holding organizations were accustomed to working together because of the planning and preparation for the 2002 Olympic Winter Games. Our ability to customize the RODS application quickly to satisfy the needs that arose during negotiation was also helpful. We also note the potential role of serendipity. Ratification of the agreement with one of the healthcare systems may not have occurred if it were not for the decision by President Bush to visit the RODS Laboratory three days before the opening ceremony for a demonstration of the RODS system, which would have only contained data from one healthcare system without ratification.

More detail about the administrative and technical and aspects of this project is available in a pair of articles in the Journal of the American Medical Informatics Association (Gesteland et al., 2003, Tsui et al., 2003).

2.6. Negotiations with Commercial Firms

A variety of commercial firms collect data of potential or established value to biosurveillance. These firms include retail pharmacies, drug manufacturers, food producers, grocers, credit card companies, and other entities discussed in Parts II and IV of this book. Although there are some regulations that encourage their participation in biosurveillance, their willingness to provide data or services largely hinges on altruism.

To illustrate the issues that one may encounter in negotiation with commercial firms, we describe the NRDM's experience with getting to yes. The goal of this project is to collect sales data for over-the-counter medications from retail pharmacies, grocers, and mass merchandising stores (see Chapter 22). In the course of building the NRDM, we formulated a number of tactics for approaching retailers for data. These methods may be relevant to negotiations with other commercial entities and industries.

Our approach involved working with a consultant who had worked in the industry and was familiar with both management and IT in the industry. This individual was successful in recruiting two initial retailers for the NRDM based on his credibility with his contacts and also by appealing to the retailers' sense of community responsibility.

The consultant, based on the early feedback from the industry, identified the need to develop the scientific case, which we did rapidly through literature review and conducting research on historical data (Hogan et al., 2003).3 The consultant also identified the need for governmental public health to make the "ask" in the form of an official letter from an as highly placed individual as possible. We first attempted to obtain a request letter from the White House and then from Department of Health and Human Services (DHHS) and from senators. This process took considerable time and lobbying through several federal agencies, but after several months the director of the Centers for Disease Control and Prevention sent a request letter on our behalf to the CEOs of approximately 10 large retail corporations.

During this time, we also formed the NRDM Working Group, consisting of health department leaders in the Commonwealth of Pennsylvania, Ohio, New York, Georgia, and New Hampshire. The group enlisted the support of other state health departments and sent additional "ask" letters that introduced retailers and mass merchandisers to the program and requested their participation. The letters included fact sheets describing the purpose of the NRDM and current statistics about use and participation, reasons they should participate, an IT specifications document, and a data security document.

Very few retailers responded to the letters from the CDC director and the NRDM Working Group. The senior executives who received the letters often did not answer follow-up calls. Retailers receive many requests from organizations and vendors to participate in public benefit projects. We learned that it was going to take more than just a letter to get the attention of a retailer.

We researched the retailers and learned their chains of command. We started cold calling personnel in key positions at the retailers, such as vice presidents of pharmacy or operations, in an attempt to generate interest in our efforts. Often an executive shunted us from one vice president to another before we could pique someone's interest.

3 This literature review identified the existing literature on the correlation of sales of diarrhea remedies with cryptosporidium outbreaks that has now become part of the biosurveillance literature (see Chapter 22).

We marketed to the industry as a whole, enlisting the assistance of a national industry organization that gave us a speaking slot to present at their convention. We staffed a booth on the convention floor (Figure 34.4). We enlisted the assistance of one of the industries' data integrators, and we received a speaking slot at one of their industry meetings. We also kept a log on all of the people from retailers and mass merchandisers we met, including business cards, and if no card was available, we filled out a contact information sheet via our discussions with individuals.

After this meeting, we did follow-up with people we met. The issues that frequently arose were the status of the NRDM (profit, nonprofit, relationship to public health) and concerns about competitors gaining access to the data. We were sometimes able to address these concerns in person by flying to the retailer's headquarter and giving a presentation on the NRDM and a demonstration of the system. In some instances, public health officials from the headquarter city met with retailers and/or invited them to visit the local health department to show executives the system and explain how the health department used the data for the purpose of disease detection.

One of the most effective tools in our recruitment efforts was the development of the "business case" (Figure 34.2). The business case listed reasons for the retailer to participate in this project. In one page, it made a compelling case for participation, including helping to mitigate the effects of a bioterrorism attack, protecting the retailer's employees and communities, addressing multiple requests for data from health departments in a single interface, enhancing prestige with the health community, and minimizing cost of compliance with reporting legislation.

In some cases, public health officials led the follow-up effort by contacting retailers to ask for their participation. Sometimes a cold call to a retailer resulted in an agreement to participate without the assistance of public health officials.

Once a retailer verbally approved participating in the NRDM, a DUA was executed (Appendix K, "Data Use Agreement with Commercial Data Provider").

Our negotiations with retailers have not always been successful. In some cases, the necessary IT infrastructure was not in place for data collection. Many larger retailers operate multiple "banners" (i.e., smaller chains) and do not consolidate their data collection systems. In some of these cases, we will go back to the retailer after they have upgraded their systems. We were unable to make progress with another retailer because the health department in the state where the retailer had its headquarters made the request and took charge of the effort. The person at the health department with whom we were working had many other priorities and was unable to follow through on the request in a timely manner. The largest retailer simply turned down our request for data, despite our making a joint visit to their headquarters together with the health department of the state where the retailer had headquarters. There simply was no requirement for them

figure 34.4 National Retail Data Monitor Booth at the National Association of Chain Drug Stores Annual Meeting, Philadelphia, Pennsylvania, August 2003.

to provide data; they had a corporate policy of never sharing data, and they were unwilling to make an exception. They were unwilling to consider technical solutions that would allow them to analyze their data and provide deviations from expected sales that our algorithms could still combine with data from other retailers in a region to form an overall indication of anomaly.

2.7. Negotiations with Utilities

A variety of utilities collect data of potential or established value to biosurveillance, including water companies, transit authorities, and telephone companies. These utilities may be privately or government owned and are often regulated by government agencies such as the Food and Drug Administration (FDA), U.S. Department of Agriculture (USDA), and boards of public utilities. Utilities may be more motivated to provide data or services for biosurveillance than are commercial companies because of their quasi public nature. Water companies are also motivated because they have a primary biosurveillance role and can benefit directly from better public health surveillance. Deregulation in the United States has moved several types of companies such as phone companies out of public realm, although in other countries these activities continue as utilities or governmental services.

In 2005, we approached a water company as a data requester, requesting both water quality data and information about the water distribution system. As with any data negotiation, sensitivity to the needs of the data provider was paramount. The water company was interested in participating in the project but insisted on anonymity for protection of the company and its customers. This water company was motivated to participate in a biosurveillance system for several reasons: (1) possible incentives for future projects and funding from the Environmental Protection Agency (EPA), (2) its altruistic desire to participate in protecting public health, and (3) the company's desire to improve its relationship with the health department by participating in this project.

We approached the water utility in conjunction with the EPA, which regulates water quality and the local department of health. We worked with the water quality manager at the utility to get to "yes" from the CEO.

The DUA that we negotiated included a requirement for the RODS Laboratory to delete reference to the city where the water company is located in publications and reports about the project. The water company was also concerned for the security of the water distribution maps they would give us and concern that contributing daily water quality data to a biosurveillance system will cause health departments to more readily attribute public health trends to problems in the drinking water.

The RODS Laboratory's excellent record for data security gave this water company the confidence to share details of its water distribution systems with us. To address the concern for undue attention because of anomalies detected by the public health surveillance system, we agreed to develop an alerting mechanism to let the water company know when the health department receives a water quality alert from the system. That way, the water company could do its own investigation into the possible causes for the anomaly that generated the alert and be prepared for discussion with the health department and possibly allay its concerns before a more extensive public health investigation.

Was this article helpful?

0 0

Post a comment