A Win/Win for the Public's Health When Administrative and Clinical Data Standards Merge – A New York Case Study for an Integrated Emergency Department Data Collection System

By Robert Davis (February 11, 2003)

Apart from the terrible images of the airplanes flying into the World Trade Center Towers on September 11, 2001 my most vivid image from that day was the sea of dust that chased fleeing people down the streets of lower Manhattan. To health professionals that sea of dust would be the direct cause of health issues in the people unlucky enough to be in that vicinity. That same sea of dust would also be a trigger for pre-existing health conditions. In both scenarios the effects could last for years to come. Both institution-based and office-based health providers would be faced with the challenge of treating the short- and long-term effects of that sea of dust. Public health professionals would be faced with the challenge of determining the short and long term risks created by that same sea of dust as part of developing effective health policy.

Both the health care clinicians and the public health officials would share a common need for data to effectively do their jobs. Timely data would be critical for the clinicians to determine whether the sea of dust was a trigger for an asthmatic attack or the cause of some other health problem. The quality of the care given would be directly proportional to the availability of data at the point of care. Timely data would also be critical for the public health officials to assess the potential of an immediate public health threat as well as being a necessary ingredient in developing long-term health policy. For both the clinicians and the public health professionals any events, such as 9/11, generates a wide range of intriguing questions that beg to be answered in the continuum of time between when care is first needed and public health policy is implemented.

Some of the data needed by the clinicians and public health would be the same. Some of the data would be different because of the different functions each of these health professionals. Some of the data would be needed in the moments after the event and some of the data would be needed in the months and years to come. The challenge for all of health care is to anticipate the data needs caused by such extraordinary events and to have such systems in place prior to any future events. The purpose of this white paper is to describe how the events of the fall of 2001 started a journey to react to the health issues caused amongst other things by that sea of dust as well as to be better prepared if and when there is a next time.

Overview

The development of an integrated emergency department data collection system in New York State is an evolving story describing two separate journeys along two parallel paths that at several key junctures would simultaneously cross. Both journeys started with a need defined by events outside the New York State Department of Health. One got its energy from a dedicated physician who needed to better understand the chronic diseases affecting his population of patients. His efforts were the driving force to get state legislation proposed and passed to mandate collection of the administrative emergency department data. The energy source for the other came from the tragic events that occurred during the fall of 2001, which established the need for data to better manage resource utilization and potential threats in times of crisis. The complexity of our world today makes it no longer possible to answer all the critical questions using a single data collection system. For that reason alone it is necessary that we design an integrated system to best serve the needs of New York State.

What I have briefly described is the beginning of the Administrative and Clinical components of an integrated New York State Department of Health emergency department data collection system. An alignment of stars and circumstances has resulted in a still evolving integrated system for collecting the necessary data from hospital emergency departments in New York State. The basic concept used in the design of both components has been a concerted effort to balance the needs of the data users with the needs of the data suppliers. It is on this concept that the foundation for a win/win scenario is built. Describing the evolution of that win/win scenario for the administrative and clinical components along with the many overlapping circumstances is the purpose of this paper.

Keys to Success

The needs that provided the energy sources for the administrative and clinical components of an integrated emergency department data collection system were each different. Because of that there will be basic differences in the design and the implementation of each separate component. There were also many similarities that created the potential to integrate the two components into a single logically connected system. It is these similarities that are our keys to success.

Communication:

The number one key to success has been the strong lines of communication that have been established with the many stakeholders for each component. Coincidence or fate opened up the lines of communication between the developer of the administrative component and the developer of the clinical component within the New York State Department of Health. There was already an existing relationship between the individuals who were given the responsibility to develop each component. Even more important than that existing relationship, the two individuals shared a common philosophy about balancing the system needs with the user capability. That meant from the very beginning there would need to be outreach to the affected providers. It is significant to note that though the developers of the administrative and clinical components of this system were different, the providers of the data were the same for the administrative and clinical components of the system. The source of the data for both components would be the emergency departments of New York State. It was critical that the lines of communication with those stakeholders in those emergency departments be well established. It was critical that these providers understood the different needs of each component to enhance their participation in the development process.

Establishing these lines of communications between the data users and the data suppliers is critical in establishing the trust of the provider community for this project. That trust will ultimately determine the success or failure of this project or any future projects. Providers historically have had to bear the added expense when there is no effort made to integrate public health systems that require data from the same source. In a time when resources are limited for both data users and data suppliers it is important that all efforts be made to eliminate redundant requirements placed on provider systems. Experience has taught us that this single act does more to establish a bond of trust between the developers and the providers than any other single action. This is only possible by opening lines of communication that do not typically exist.

From the very beginning of each project design initiative, there has been a concerted effort to identify and involve the various stakeholders for emergency department data. As a result there have been meetings, conference calls, and presentations around the state related to the collection of emergency department data. From the very first contacts the Department of Health had with outside stakeholders the vision of an integrated system design has been put forth. The developers of each component have actively participated in the other’s outreach initiatives. Presentations made to stakeholders inside and outside the Department of Health have highlighted the necessity of an integrated system design. From the onset, input for how to design an integrated public health system has been solicited, because we have limited experience with such systems.

Standards Based System Designs:

A key design feature of the administrative and clinical components was that both use national data standards appropriate for the type of data being collected. The hospital associations in New York State made it very clear prior to the legislation being passed by each branch of the legislature that it would not support the collection of the administrative component of emergency data unless national standards were used. They commented that implementing any proprietary data content or format would not be work force neutral, which means it would not be sustainable. For the clinical component, the Electronic Clinical Laboratory Reporting System (ECLRS) would serve as a model. This system was already a pilot for a New York State implementation of a National Electronic Disease Surveillance System (NEDSS) using Health Level 7 (HL7) messaging standards.

Implicit in the concept of developing an integrated system is the commitment by the developers of each component to collect only the amount of data that was necessary to answer the intended questions by that data collection. The integrated system design would allow each component to include unduplicated and necessary data for the questions to be answered.

Linkage:

For any integrated design involving two separate data collection vehicles to succeed it is necessary to develop reliable linkage routines. Because both the administrative and clinical components of the emergency department data collection systems are being modeled after existing systems, various linkage routines have already been successfully tested. The ability to link these two data systems is being factored into the selection of data elements in both systems. The reliability of these routines will be validated once more test data arrives at the Department later in 2003.

The precedent for collecting linkage variables in the New York State administrative data system was established back in 1995, when the hospital industry approved the collection of a unique personal identifier that was derived from part of the patient’s name and part of his/her social security number. This identifier is now mandated on all data being submitted to the administrative system. There is a long history of trust between the state and the health care industry that led to approval of this data element. Since the unique personal identifier has been collected, that trust remains in tact. The clinical system used for a model for the emergency department surveillance system also was collecting enough information about the patient to allow linkage with the administrative system.

Key to continued use of these linkage variables to integrate the administrative and clinical components of this system will be appropriate disclosure and use of the data. The integrated data system is necessary to provide for the public good, the fifth principle of the recommendations made by the Secretary of Health and Human Services on the Confidentiality of Individually Identifiable Health Information, which is quoted below.(1)

"Public Responsibility. Individuals' claims to privacy must be balanced by their public responsibility to contribute to the common good, through use of their information for important, socially useful purposes, with the understanding that their information will be used with respect and care and will be legally protected. Federal law should identify those limited arenas in which our public responsibilities warrant authorization of access to our medical information, and should sharply limit the uses and disclosure of information in those contexts."

The second and most important reason for careful and appropriate use of linked data is to maintain the trust of the health care industry.

Connectivity and Software Compatibility:

A reoccurring message from the provider community, which is the principal data source for both administrative and clinical data collection vehicles, is that reporting systems need to be work force neutral. Work force neutral solutions would not require additional data source staff be added to support the necessary data requirements. For system designers, that was interpreted to mean that electronic connectivity needed to be implemented. The Health Insurance Portability and Accountability Act (HIPAA) legislation certainly has sensitized everyone about the importance of patient confidentiality and the necessary steps to ensure the privacy and security of that data. The New York State Department of Health has developed infrastructure and protocols to use Secure Socket Layer technology with 128 Bit encryption for the Department’s applications where such security is necessary. In particular the administrative and clinical components are developing their respective applications to use this same technology. The old model of creating data tapes for transport is not work force neutral enough. Those tapes need to be created and mailed on one end. On the other end those tapes need to be received and processed. Both ends of the process require a significant amount of human intervention.

The Department’s infrastructure to transmit secured data works extremely well for the reporting of the administrative data. Typically a data supplier would sign on to the secured network and upload a file to be processed. The current DOH infrastructure allows for a secured two-way pathway for data and reports. These features of the secured network have been operational for several years, which have given interested hospitals amble opportunity to migrate away from sending data tapes to the Department. For most hospitals in New York State electronic submission of data is not new functionality. In the interesting fact category, hospitals sending the Department data tapes have a 2-3 week turnaround from time data are submitted until the resulting reports are returned. Those hospitals using the electronic solution have a 2-3 hour turnaround. Any of the current DOH clinical systems use the same secured network to send and receive secure data to and from Department systems. Connectivity compatibility allows providers a single tool set to learn rather than the multitude possible if each collection vehicle had an idiosyncratic data submission strategy.

Because the clinical data for emergency department surveillance are needed in "real time", the connectivity solution becomes more complex. Emergency room surveillance data are needed in "real time". In order to develop a system that is work force neutral "real time" connectivity solutions will need to support business-to-business data transfer. It would not be acceptable to the hospital associations to require staff resources be allocated to send data to the Department every day twice a day. The security issues associated with a business-to-business model leave this solution still in the development stage, but an important item on the New York State "to do" list.

The administrative component of the New York State Emergency Department data collection system is being designed to use HIPAA compatible standards. The clinical component of the same system is being designed to use Health Level 7 standards. Each of these messaging standards requires the use of mapping software to translate concise data streams into application friendly files. Because of the integration activities, the Department has been able to purchase software that meets the needs of both components at a considerable cost savings.

Joint Education and Outreach:

As we mentioned earlier it is critical that intended data suppliers support the system design and implementation plan. By making the decision to integrate the administrative and clinical components of the emergency department data collection system in the early cycles of system development, it has been possible to hold joint education and outreach to the provider community. Because of past experience with many idiosyncratic public health systems that strain hospital resources, hospitals expressed concern that the administrative and clinical systems did not replicate their respective data needs. By holding joint meetings, conference calls, and discussions providers could be reassured that their message was being heard by both development teams. This also provided hospitals a more complete picture of the Department’s data needs.

Administrative Component Design Specifics

Background:

The hospital discharge system in New York State, the Statewide Planning and Research Cooperative System (SPARCS), first received statutory authority to collect inpatient data in the late 1970’s. As the health care delivery system changed, the state legislature authorized SPARCS to also collect data on outpatient ambulatory surgery visits in the middle 1980’s. Authorization to collect data about other health care services did not change again until September 4, 2001. That is when the governor signed legislation that was passed unanimously by both houses of the state legislature authorizing collection of data on all emergency department visits in hospitals regulated by the state. This legislation specifically names the SPARCS program as the entity to collect the data. With that comes the assumption that coded "what’s wrong with you" and coded "how much does it cost" data would be collected. That is typical of what all state discharge systems across the country collect.

It is important to note the driving force for the passage of this legislation was a coalition led by an emergency department physician in New York City who was concerned about the growing number of cases of asthma in minority youth populations. An important factor in any research done on this problem would be treatment data in emergency departments. The problem was that there was no centralized source of that information. The only available source prior to the passage of this legislation was to request that each hospital voluntarily release their emergency department information for the research. That was not a workable solution for either the hospitals or the researchers. For the hospital they faced the prospect of constantly being asked for data for each new research request. For the researchers the prospect of having to do the data collection and the necessary data cleansing would detract from the available resources to do the intended analysis. Everyone knew this was a lose/lose situation that would produce questionable results. The win/win scenario was to have the state be the centralized data collector.

Though it was clear that researchers within the state department of health would benefit greatly from the availability of a centralized emergency department database, the unanimous support by legislators for passage of this legislation was because of the strength of the outside coalition. Groups that might have opposed this legislation were trying to frame the scope of this initiative in ways they could be supportive. This is particularly true of the state hospital associations. They understood the value of the data, but were understandably concerned about any additional burden on their member hospitals that would be the data source. To gain their support the need for the data would have to be balanced against capabilities of the hospitals to supply it.

In addition to broad-based support within New York State, it was also true that other states were developing emergency department data collection systems or already had such systems in place. This was significant because New York State legislators understood the national significance of their actions. This will further be emphasized when we speak more about the impact of 9/11/2001 on all data collection efforts. The fact is, though, the New York State legislature and the governor saw the need for this data before the events of 9/11 and the anthrax treat. This truly was an idea whose time had come.

Development Activities:

After authority to centralize collection of emergency department data had been secured, the next task was to develop a system that met the broad-based needs of the supporting and growing coalition. The system design would also have to be mindful of the capabilities of the data sources so as not to be unnecessarily burdensome. As they always say with any development project, "the devil is in the details." How would it be possible to build a system that balances needs to use the data with the capability of those supplying the data? A related and equally important question was how to keep the supporting coalition intact? Though the verdict will not be known until the data starts rolling in later in 2003, the path taken so far in the development of the administrative component of the emergency department data collection system is a win/win on its own and is worth further explanation. To maintain that broad-based support the developers have been very cognizant that balancing needs versus capabilities would factor in all decisions made in the system design. The following steps were taken to achieve that balance.

System Design Specifics:

The first step was a limited outreach to a medical records department and a billing department contact in an upstate and down state hospital. Each of these hospital departments were asked to list the data elements their particular systems already supported for patients being treated in their emergency departments. Coincidently the two separate lists of data elements were very similar and surprisingly robust. Those lists of data elements would become the starting point for internal department of health discussions.

The next step was a broad outreach within the department of health to identify all bureaus that would potentially be using these data for their programs. Those bureaus expressing interest in use of these data were asked to send a representative to a newly formed work group that was charged by the department’s executive staff with creating the proposed system design for the emergency department data collection system as authorized by the state law. It was made clear that programs with needs for these data would have to participate in this work group in order to incorporate those needs into the system design. The primary deliverables for this work group would be a proposed set of data specifications along with supporting materials. These materials would serve as the discussion documents for planned broad-based industry outreach. This design would have to stand up to a wide range of comments by data users and data suppliers from all corners of the state. For that reason, the work group also had to "buy in" to the concept of balancing needs with capabilities before it could earnestly begin its work.

The hospital associations made it clear that minimizing the burden on their members meant that any system that collected coded "what’s wrong with you" and coded "how much does it cost" data would need to be HIPAA compatible. The HIPAA legislation was a federal mandate that would significantly affect these same billing and medical record systems. Any new state mandates that impacted those same systems would need to use the same standards. The hospital associations made it very clear that they would only support a system design for the administrative component of the emergency department data collection if it used the same standards already in effect at their member hospitals (i.e., HIPAA). Not coincidently, the Health Care Service: Data Reporting implementation guide was developed on that very principle. This guide is available on the Washington Publishing Web Site, www.wpc-edi.com, and is referenced as the 004050X156 guide. The reporting guide is meant to establish a national standard for collecting data typically collected by state discharge systems. The first ground rule one for the departmental work group had been established. The Health Care Service: Data Reporting guide would be used in the design of the New York State system.

From the limited outreach done to get a list of supported data elements from the medical records department and the billing department together with the national outreach necessary to develop the Health Care Service: Data Reporting guide the capabilities of the providers was well established. The next issue was to consider the needs of the potential users of the data. It is important to note that the HIPAA standard that would be used, Health Care Claim (ANSI ASC X12N 837), is a very robust standard that also provides enough flexibility to accommodate some specialized state needs. The challenge for the work group would be to find a way to quantify the data needs. To do so, the work group decided that each participating program would develop a set of questions to be answered by the data. Those questions were then used to generate a matrix that was cross-referenced with the data elements from the HIPAA standard that were necessary to answer each question. The decision was made to only include those data elements needed to answer a question into the final specifications. This matrix became the principal document used to justify data elements included in the final specifications. Any program that did not get its questions into the matrix would not have its data needs incorporated into the system design. For this reason the work group was very representative of the broad set of needs within the department. For a data element to be included in the final specifications two things needed to be true. The data element needed to be supported in the HIPAA standard, and there needed to be a use question that justified the need for that data element. The purpose of this question-based methodology is to design a system that meets the needs of the potential users of the data by collecting just the right amount of data.

At this point I want to again remind everyone that the HIPAA standard is a robust standard that did support most of the questions that were being asked by department programs. There was, however, significant discussion in the work group about data needs that were not supported by the HIPAA standard. It was clear from the onset that the final specifications would not be able to satisfy all potential uses for the data. The challenge for the work group was to prioritize those needs. Potential gridlock within the work group was broken by the following analogy by one of the work group members. "Currently emergency department data are like going into a dark room. We can only guess what is causing the problems. It is better that when we first enter the dark room we do so with a flashlight. With that flashlight we can better determine how to light the room in the future." Our first iteration of an emergency department data collection system will be that "flashlight" so that future enhancements can also be useful and supportable. There was work group consensus that it was more important to maintain the support of the hospital associations than to require data elements that may be beneficial, but potentially burdensome to collect with current hospital information systems.

Statewide Outreach Initiatives:

The work of the department’s work group was completed and the deliverables were posted on a public web site (www.health.state.ny.us/nysdoh/sparcs/eddoc.htm). The next step was to seek industry approval for the proposed system design. This was achieved by contacting member organizations of the coalition that was built to get the legislation passed. The two state hospital associations were contacted to sponsor a series of statewide outreach meetings. The hospital associations agreed to publicize the meetings and to provide meeting sites. In attendance at these meetings were physicians, nurses, administrators, information technology staff, medical records and billing coders, as well as vendors. There were seven meetings held at cities across the state. At each of these meetings department of health work group members presented the proposed emergency department data collection system. The legislation was going to mandate the collection of the data, but exactly what data elements would be required and how the data would be submitted were open for comment. In another understanding with the hospital associations, differences in opinions between hospital representatives would be resolved by the hospital associations and would then present that consensus solution to the state. The hospital associations welcomed this role to be a key player in the consensus process representing their member hospitals. This agreement also worked well for the state work group, because this further opened up lines of communication with the industry.

For example as a direct result of these outreach meetings, the hospitals made it clear that it would be very burdensome for their information systems to separate emergency department data from other outpatient services. In addition for those patients that were subsequently admitted for inpatient services, the emergency department data would need to be reported as part of an inpatient submission. This same message was heard loud and clear at each of the seven meetings. The proposed system design would need to accommodate these provider system limitations.

The work group also presented the proposed system design to New York State Chapter of the American College of Emergency Department Physicians. It was important that a wide variety of affected groups have the opportunity to question and comment on the purpose for each data element that would be collected. The data element justifications based on questions to be answered made it much easier to defend the data elements that would be included in the final specifications document. More importantly the data element definitions were refined for those elements that were to be included in the final specifications document.

The other important group that needed to be included in this outreach represented those who would be using the data. In particular, groups focused on asthma research were interested in the progress and direction of the initiative. Because the legislation was passed largely due to the efforts of asthma groups around the state, it was critical that the asthma researchers buy into the final design. This could only be accomplished by making them a stakeholder in the development process. In what will be discussed in more depth later, the group responsible for developing the emergency department "real time" surveillance system (the clinical component) wanted to be apprised of the progress and have input into the design.

The end result of this outreach was the creation and public posting of the final data specifications document. The last thing to describe is the implementation plan for this system.

Implementation Plan:

As indicated earlier, the authorizing legislation was signed by the governor into law on September 4, 2001. The legislation gave the state two years to implement the system. That meant the deadline for hospitals to start submitting coded "what is wrong with you" and coded "how much does it cost" data to the department was September 2003. The supporting regulations for this legislation are currently working their way through the approval process. These regulations reflect the combined input of the provider community and the potential users of the data. Approval for these regulations is expected before the summer of 2003.

As mentioned earlier, the hospitals made it clear that emergency department data would be submitted in two separate submissions. For those inpatients transferred from a hospitals emergency department, that data would be submitted along with the other inpatient data. For SPARCS this represents no change in the current system. The current SPARCS inpatient system already collects all the necessary data elements to answer the questions used to justify the final design. For patients that only receive outpatient emergency services the current SPARCS outpatient data collection for ambulatory surgery services would not be adequate to answer the questions. Because hospitals would be sending data outpatient data files with both types of services reported on the same file, it was necessary to make some changes to the ambulatory surgery data collection system. Hospitals fully supported these changes, because it would have been more problematic to separate the different types of outpatient services for the mandated reporting. The main change to the ambulatory surgery system was the additional data elements that could be used to identify the different types of services being provided. It was at the outreach meetings that the hospitals helped define the most reliable data elements for this purpose. Therefore the change request to add those elements to the SPARCS outpatient reporting requirements was universally supported by the hospital industry.

Because the system design is based on the HIPAA mandates, hospital information systems were already being changed to support the additional data elements that were being requested. These changes represented minimal changes to the provider systems.

Historically, all significant changes to the SPARCS system occurred for discharges in beginning of a new year. To enable the collection of outpatient emergency department data to the SPARCS in 2003, changes to the ambulatory surgery system were due for discharges beginning January 1, 2003. The testing for that change began in October 2002. Changes to the ambulatory surgery system are an incremental step toward compliance with the mandate to collect the administrative component of the emergency department data. The next and final step in the implementation plan will be to incorporate edits specific to emergency room visits into the processing of outpatient submissions. It has been announced that the testing for submission of emergency department submissions would begin in March 2003. It should be noted that again from the feedback at the outreach meetings, the September 2003 implementation deadline in the state emergency department enabling legislation is perilously close to HIPAA transactions and codes implementation deadline of October 16, 2003. Hospitals indicated that because the SPARCS requirements are consistent with existing hospital capabilities, it is realistic to move the testing to a date earlier in the year.

These implementation plans have been posted on the SPARCS public web site (www.health.state.ny.us/nysdoh/sparcs/sparcs.htm) in a series of published information bulletins. In addition SPARCS staff has presented at a series of meetings sponsored by the hospital associations and the New York Health Information Management Association. The sole purpose of these meetings has been to discuss the specific implementation plan and associated time lines. SPARCS has also continued to communicate system development to the asthma groups, with the New York Association of Counties Health Organizations, and others that show interest in using the data. Part of the implementation plan must be that potential users of the data become actual users of the data soon after the emergency data start being submitted to the SPARCS. It is from this use that the circle of trust with the users and the suppliers of the data will be completed. It is through this use that the quality of the data will be given the opportunity to meet the high expectations for value of this initiative. It is through this trust that the right amount of data will be requested to be used in a meaningful way. This is the formula for a win/win scenario in the development of the administrative component.

Clinical Component Design Specifics

Background:

The New York State Department of Health has an equally long history of collecting clinical data to do disease surveillance. Like many states the early history of state reporting of disease specific information to the Centers for Disease Control (CDC) was done in separate "stove pipe" systems. In the late 1990’s the CDC initiated the development of the National Electronic Disease Surveillance System (NEDSS). The intent of this system was to offer a standards-based solution for the many surveillance activities done at the state and national levels. New York State was one of the pilot states that participated in this project. In New York State the first such NEDSS system has been the Electronic Clinical Laboratory Reporting System (ECLRS). This system was designed to collect data electronically and provide timely alerts about threatening events.

Bio-terrorism has long been considered a threat, but after 9/11 and the anthrax incidents there was no doubt about the urgency for action. The old surveillance systems as well as the administrative data systems would only be able to provide information to invoke a reactive response to an event. A reactive response to any form of terrorism was not going to be acceptable to local, county, state, or national health officials. It was also true that the public wanted a proactive response, which is reflected in the large influx of dollars to address this problem. Any new surveillance system would need to collect data electronically and in particular those systems used to generate alerts of possible events needed to collect data in "real time." All definitions of "real time" were in some increment of hours rather than days, weeks, or months.

In the days after 9/11, the center of data collection attention was in New York City’s emergency departments. There were many authorities (the state, the city, the county) wanting to know what was happening in the emergency departments. There was a great need to know about the capacity of these emergency rooms to handle an expected flood of patients. There was a need to know what type of treatments were being applied to patients first entering the health care system. This became even more urgent after the first case of anthrax was first confirmed. The need for timely accurate data was obvious. At issue was the capability of the current hospital information systems to provide these data. During the critical first moments of the 9/11 and anthrax events, the need was so great for information that many person-intensive solutions were put in place. That meant hospitals in New York City and throughout the state were getting requests for occupancy and syndromic data from city, county, and state health authorities. These requests started out as a series of phone calls and eventually evolved to some form of electronic messaging system. Though the information sought was the same, there was no standard by which the questions were being asked or the data delivered. The hospitals did not question the need for the data and did find ways to provide the necessary information. Providing this information, though, was a very resource intensive activity for the hospitals. Out of the need and the lack of adequate systems to respond to those needs grew the initiative to create the clinical component of the emergency department data collection system. To satisfy the need for "real time" data this system would have to be electronic. To reduce the burden placed on hospitals during the crisis moments during the fall of 2001 a single standards-based solution would have to be designed and implemented. The urgency of the moments of events of the fall of 2001 have subsided, but the memory of those events is still very vivid. The health care industry and the American public are of one mind. We need to be better prepared to handle these threats in the future. It is this mindset that is the principal driver for changes in our clinical reporting systems.

Development Activities:

The aftermath of both the events immediately following 9/11 and the first confirmed case of Anthrax made it crystal clear that data availability issues were a significant issue. Below are examples of some of the solutions implemented in lieu of adequate data from established systems. All of these solutions shared one common characteristic. They were all very resource intensive.

• In the early hours of 9/11, the CDC dispatched staff to all of the hospital emergency departments in the area surrounding the World Trade Centers. These staff collected information on paper forms and the subsequently entered the recorded information. This system went on for a limited period of time with good coverage of ED admissions. After the CDC staff ceased performing this task the emergency department physicians were asked to continue this process. Not surprisingly within a few days compliance had dropped to below 20 percent.

• In Albany and Erie Counties, staff was assigned to contact emergency department’s to get a daily utilization census. Criteria were established to alerts for increased use above a defined norm. There were two problems with this system. Because data were not collected on weekends they were not always timely, and the criteria used to trigger an alert was too sensitive.

• In New York City, a system was developed to gather syndromic data from 35 hospitals. This system required allocation of a full time staff to monitor the results as well as hospital staff to enter data on a daily basis. The purpose of this system was to retrospectively respond to any event.

Each of these interim solutions provided important lessons that could be applied to a more enduring solution. Any system monitoring emergency department services would have to be automated and plug into the normal "electronic" workflow. With this lesson in hand, solutions for "workforce neutral" solution have been the primary focus. The New York City solution that collected syndromic data has also proved to be more sustainable and useful than those systems collecting only census information.

Just as was done with the development of the administrative component of this system, a departmental work group was formed to develop an appropriate set of questions to be answered through this data collection system. It was not difficult for the work group to decide that an emergency department surveillance system would need to differentiate between a mass outbreak (1,000+ cases), a limited outbreak (15-1,000 cases), and a small outbreak (1-15 cases). For each outbreak it would be necessary to determine acceptable response times. Once it was decided a response was necessary, it would be necessary to determine who should be notified and how that notification should occur.

In developing these questions, there was work group consensus to consult with the industry to determine what were the hospital capabilities for the various "real time" response requirements. Local Health Units represented by the New York State Association of County Health Organizations, emergency department physicians, the Healthcare Association of New York State, the Greater New York Hospital Association, and the New York City Department of Health were consulted.

As a result of the process to identify the relevant questions to be answered from this data collection system, the work group decided that it would be necessary to conduct a pilot study to determine if available electronic data on hospital systems within hours of the event would be sufficient to answer the questions.

Statewide Outreach:

To aid in the design of the pilot system another series of outreach meetings was held. Coincidently, at the time feedback from the hospital industry was necessary to design the pilot system a round of outreach meetings was being held around the state to solicit comment about the proposed administrative component. Part of the agenda at these meetings included information about the activities of the clinical component work group and a survey co-authored by the Greater New York Hospital Association was distributed. The purpose of this survey was to identify hospitals with sufficient electronic capability to report emergency department data within hours of the service. There was another question on the survey asking for whether the hospital was willing to volunteer to participate in the pilot. Hospitals were selected to participate based on both of those factors. At all outreach meetings, the provider community voiced support for solutions that were sustainable and work force neutral.

This was going to be more difficult to achieve for the clinical component for the system because of the variability of hospital information systems in their ability to provide "real time" data electronically. Even amongst the hospitals that volunteered to participate in the pilot, which presumably had the most sophisticated systems, there were marked differences in system capabilities.

Pilot System Design Specifics:

The first design decision was influenced by the New York City emergency department surveillance system described above. The clinical component of the emergency department data collection system would collect syndromic data rather than just census data. From an analysis point of view, it would be better to collect coded diagnosis data from both the patient and the physician. None of the pilot sites have the current capability to report that coded information within the "real time" time frames. Common amongst these pilot sites was the ability to electronically report a text version of the patient’s chief complaint. In addition in a collaborative agreement, it was agreed that the following data elements (medical record number, age / birth date (when available), gender, race, hospital identifier, and patient’s chief complaint) would be necessary to answer the emergency department surveillance questions and were available electronically on provider system at the time of the "real time" reporting. These data elements are all currently supported in the NEDSS-based Electronic Clinical Laboratory Reporting System. Because that system was already tested and operational, it was decided that the ECLRS system would serve as a model for the development of the pilot clinical system. It is important to note that the combination of these data elements would be sufficient to link with the administrative component to empower the integrated design.

Because coded diagnosis data would not be available to meet "real time " needs, part of the pilot design work would be to analyze incoming chief complaint data to determine if that textural data could be reliably translated to coded syndromes. Without codified data analysis of the data received would necessarily be very limited and of questionable value. The next and most challenging goal of the pilot system design would to determine if the data available in "real time" through analysis could be used to reliably detect an "alertable" event.

Again because of the need for "real time" information, the pilot hospitals agreed that a business-to-business connectivity solution needed to be developed. Any design that required human intervention would not satisfy the sustainable and workforce neutral criteria. This too would be a challenge because of the security concerns surrounding a business-to-business data exchange.

Pilot System Implementation Plan:

The pilot hospitals were asked to provide the state the textual patient’s chief complaint data. All of the pilot hospitals cooperated in providing this data. The first part of the pilot system implementation plan was to determine the reliability of software that would map the textual patient’s chief complaint data with coded ICD-9-CM diagnostic codes. This part of the implementation plan has gone more successfully than anticipated. Based on several measures, the mapping appears to be very reliable. Though more tests need to be conducted, these results certainly warrant moving ahead with the development of the pilot system.

The plan is for the pilot system to continue at least until the other two design dilemmas are overcome. Network and security staff at the New York State Department of health are working to develop an acceptable business-to-business connectivity solution. It is unknown when that capability will be established and adequately tested. The remaining $64,000 question is whether the data available in "real time" is sufficient to reliably predict that an "alertable" event has occurred.

A workable clinical emergency department surveillance system must be able to regularly poll for data without human intervention, textual syndromic data must be codified, and the analysis techniques must be sensitive enough to detect "alertable" events. The purpose of the pilot system is to resolve all these issues before a statewide system is implemented. If these issues are not resolved successfully, the pilot will still be considered a success. The purpose of the pilot is to determine what is possible from the data available in "real time" before significant resources are committed to building a statewide system. Based on the pilot it will be possible to determine what questions can be answered with the data available. These questions may be different than what the pilot was originally designed to answer. If that is the case, the resulting system will be able to align the needs of the users with the capabilities of the providers. The system expectations will be established through a collaborative trusting building process. In other words a win/win scenario for both sides in the development of the clinical component.

Summary

The intent of this paper has been to describe the early stages of a process to develop an integrated emergency department data collection system. At this point neither the administrative nor the clinical components have completed development, but the process to date is full of lessons learned that are worthy of being shared.

Lessons Learned:

Think out of the box to reach all the stakeholders. The two components share a common data source (New York State hospital emergency departments), but each system has completely different objectives. The differences make it impossible to consider development of only one super system. It was the similarities, though, that brought the two developers together. This expanded view caused each developer to engage a wider range of stakeholders in the development process. This broader view provided greater opportunities for critical review of each stage of development that has occurred to date for both components. It is not surprising that good ideas came from unexpected places. Stakeholders for each component were informed and engaged in development decisions for both systems. Now these same stakeholders better understand the purpose of each collection vehicle, which we anticipate will translate in more comprehensive and meaningful use of each system as they are fully implemented over time.

Personnel responsible for the information in the data source are a very important stakeholder that can make or break your system. Center stage for the stakeholders was the emergency department staff, including the physicians, the nurses, and the data folks. The stakeholders constantly reminded the developers that the main reason to develop an emergency department system was to improve patient care through data analysis without an unnecessary data collection burden. To accomplish this everyone would be expected to contribute to the final product. Data folks would need to be committed to providing quality data. Care givers would need to share their clinical experience to develop the pertinent questions, whose answers will lead to better care.

Any new development effort needs to use national standards to minimize the cost and enable use across our state lines. In a time where budget deficits are the rule and the threat of the unknown a national agenda item, it is important that systems put in place to prepare for those threats be done in an affordable way. It is not surprising that the CDC has become a major stakeholder for systems developed in the states to prepare for dealing with the litany of potential threats. It is also true that the Department of Health and Human Services is charged with implementing the HIPAA standards. Because the threats are national the data will need to be analyzed nationally. The HIPAA law mandates the use of national standards in our administrative systems. The clinical systems are being pushed into the use of national standards because of the collection and analysis burden caused by the typical "siloed" clinical surveillance system common today.

Everybody wins if you collect just the right amount of data at the appropriate time. By developing an integrated system with linkage capabilities, it is easier to control the scope of a project. The clinicians and the researchers can each be made to understand that they do not need all their data needs put into one super file that is hard to maintain and burdensome to support. Our times do not give us the luxury to collect data that will be of limited value. We need to collect what is appropriate to in a time frame necessary to make short- and long-term decisions that will lead to better patient care.

The most important skill in system development is listening. To create both the administrative and clinical components of the system, it has been necessary to engage a wide spectrum of stakeholders. To keep those stakeholders engaged in the process it has been necessary to cast aside all preconceived notions. The expectations of the data users could not be allowed to exceed the capability of the data. To manage those expectations the development of meaningful questions together with relevant answers was necessary. That required a collaborative process where stakeholders were viewed as equals.

People make the difference between success and failure, not technology. From the germination of the idea to collect emergency room data, to the persistence to get legislation passed and signed, to the decision to collaborate with the design of the clinical and administrative components, to embracing of the initiative by the industry (in particular the hospital associations) to the technical staff that was charged with the heavy burden of implementation with limited resources there was always one factor in common. In each case there were individuals that were committed and passionate about wanting this project to succeed. It was these individuals that were persistent when necessary, were compromising when necessary, and were ingenious when necessary.

When you work together, everybody wins. When asked to identify the key element in any development project, the answer is the formation of trusting relationships amongst all the stakeholders. It is through those relationships that the political and technical issues can be resolved. It is all about the idea that the data suppliers will trust that the system caretakers will collect only what is necessary and use it appropriately. It is all about the idea that the data system caretakers will trust that the data suppliers will make all efforts to collect accurate and timely information.

(1) Donna Shalala, "Confidentiality of Individually Identifiable Health Information", Web posting, http://aspe.os.dhhs.gov/admnsimp/pvcrec0.htm, September 11, 1997