Health-care facility evacuations are complex situations involving multiple disciplines with varied corporate and professional cultures. They require the movement of “numerous patients, each with unique resource needs while dealing with conflicting terminology, a limited understanding of each other’s resource capabilities, fluctuating resource availability, and limited visibility on the needs of the entire patient cohort.” Reference Ventura1-Reference Taaffe, Johnson and Steinmann4 When one considers that nonurgent patient movements require significant collaboration with local emergency medical services (EMS) and both sets of medical professionals, an urgent evacuation under duress with a significant number of patients with vast amounts of critical patient data will very likely overwhelm even the best decision-maker. Reference Ventura1,Reference Weiner and Slepski5 Various attempts have been made to address this health informatics challenge, but none have successfully identified how to classify individual patient information that can be used to determine the most appropriate transportation and surge bed resource to be assigned. Reference Taaffe, Johnson and Steinmann4,Reference Rothman, Hsu and Kahn6-Reference Lin, Taylor and Cohen11 This research objective focused on a system that could work with the unique details for each patient’s care needs and the necessary resources that would directly affect their evacuation.
The Patient Evacuation Resource Classification (PERC) system was developed through dissertation research from 2012 to 2017 with the hope that it would improve and facilitate residential health-care facility evacuations and add a new patient classification lexicon. This decision-making system is a translational research effort that could determine the costs associated with evacuation, identify staffing requirements or issues, and better define the risks associated with evacuating each patient. Reference Ventura1,Reference Moher, Shamseer and Clarke12 The PERC system operating approach is also designed to provide better transparency with resource availability, and to generate strategies that incorporate internal staff and inventory to mitigate resource shortfalls. The PERC system has the potential to provide the necessary data to support Certificate-of-Need proposals, a process used by health-care providers to justify the construction of a new hospital or the expansion of an existing one.
METHODS
This research is unique “for its use of Systems Engineering and Engineering Management (EMSE) tools in innovative ways to develop an objective, context-specific descriptions and a relational framework that provides real-time decision-support.” Reference Ventura1 Applying EMSE fundamentals allowed for the research to “conduct an in-depth analysis of a complex event identifying important system functions and relationships, which supported the creations of a new comprehensive construct and system architecture.” Reference Ventura1,13 This methodology is not new to disaster research, but “was distinctive for this area of study, (and the research) benefited from well-established conceptual guidelines.” Reference Ventura1
Systems Engineering methodology is more commonly used for software design. Well-known British computer scientist C.A.R Hoare has a memorable quote on the 2 ways to construct software design, explaining that one could “make it so simple that there are obviously no deficiencies” or “make it so complicated that there are no obvious deficiencies” noting that the first approach was more difficult. Reference Hoare14 Five phases were developed, as shown in Figure 1, to achieve the former objective. This manuscript will only focus on Phases 1-3. Phases 4 and 5 will be addressed in a future effort.
FIGURE 1 Five Methodological Phases
Phase 1: Identify Key Patient Issues (Functional Analysis and Allocation)
The first phase used a functional analysis to identify patient evacuation protocols that impacted the individual patient’s evacuation. A functional analysis requires a thorough examination of all resource materials collected and databases used with the intent of building a list of key functional events from “all protocols, guidelines, and other relevant documents.” Reference Ventura1,13 It is a “top–down process” that translates complicated and large scale subjects/events into “detailed functional and performance design criteria.” 13 This includes sub functions, interfaces, groupings, and functional characteristics. 13 Finally, a functional analysis defines the process and data flows, which is critical information for defining the mechanics of a residential health-care facility evacuation. 13
The sources and databases used for the first phase functional analysis were numerous and can be found in the literature review of the cited dissertation. They ranged from personal interviews with medical personnel that had experienced a hospital evacuation under duress to journal articles and books by those that researched and had first-hand knowledge of the evacuations. Sources and databases included George Washington University’s Gelman Library with all associated databases and associated Inter Library Loan (ILL) network, George Washington University’s Himmelfarb Health Sciences Library with all associated databases, Google Scholar, the Joint Commission, the D.C. Healthcare Coalition, the Northern Virginia Healthcare Coalition, the US Department of Health & Human Services, the National Hospital Preparedness Program (NHPP), the Federal Emergency Management Agency, the Uniformed Services University, and many others. From all of these sources and databases, the functional analysis defined 3 main constituencies: patients, transportation, and destination. Under each constituency, there are multiple events, data requirements, communication requirements, and decision points.
Engineering Functional Decomposition
An engineered functional decomposition identifies “functional, performance, and interface design requirements” to include functional partitioning, which “identifies logical grouping of functions.” 13 A functional engineering decomposition was conducted on each constituency, which, in turn, identified 3 high-level requirements that were either not efficient or inadequate: Hospital Availability Bed (HAvBED) classifications, inter-facility communication protocols, and the use of communication technology.
HAvBED Classifications
Communicating surge bed availability and identifying the patient using HAvBED’s classifications, which focuses on just the hospital bed and related equipment, created confusion with the destination staff’s expectations and preparations for the inbound patient. Because the same “bed” could be used in multiple wards, the destination staff was unsure of the patient’s specific medical care needs. Inversely, destination availability based on HAvBED challenged releasing staff as no amplification was provided as to the bed’s location (ie, ward or clinic) within the destination facility. These lapses required extensive discussions before each patient was evacuated, complicating time management efforts.
Inter-facility Communication Protocols
The research focused on DC’s Healthcare Coalition protocols incorporating observations from their evacuation drills, attendance at their conference and seminars, and their organizational documents including their annex dedicated to evacuations. Reference Weiner and Slepski5 Even under duress, the annex called for a negotiated pairing between an evacuating patient’s facility and a destination facility. This negotiation required voice communication to discuss the patient. When applied to an entire ward/clinic or facility, the time necessary to complete the evacuation was notably impacted. The documented protocols also allowed for up to 30 min for medical personnel to be contacted by a coalition duty representative after the emergency was declared relying on voice or fax exchanges regarding each patient.
Communication Technology
The use of health-care coalitions has notably improved coordination between local facilities when experiencing an evacuation of 1 of their members. Reference Higdon, Shin and Stoto15 However, the review noted a need to identify more reliable and expeditious means or methods to improve how patient information was exchanged. Current technology practices rely heavily on cell phones, limited intra-coalition databases, and even paper faxes. Incorporation of newer technology and the appropriate related protocols would facilitate and even enhance the patient evacuation process. 16
The decomposition of these 3 high-level requirements “identified dependent functions that (also needed) to be addressed: patient health-care needs, EMS transportation resource capabilities, and destination resource capabilities, along with the list of low-level functions that supported them.” Reference Ventura1 These dependent functions were identified as potential performance issues and can be found in Table 1.
TABLE 1 Potential Performance Issues Identified
The research focused on potential performance issues 1, 3, and 4, as they directly impacted the evacuation of the patient, and were used to guide the subsequent case study series. During the functional analysis, 3 significant events were chosen for the case study series for the amount of detailed information documented: Hurricanes Katrina (2005), Rita (2005), and Superstorm Sandy (2012).
The analysis discovered that each event shared multiple complications and experiences to include staging area shortfalls and facility limitations, but the case study noted that most references for Hurricane Rita were very focused on pediatric patient concerns, while those for Hurricane Katrina and Superstorm Sandy highlighted procedural impediments (expedited reviews of medical records, identification of destination facilities, and trying to gain greater situational awareness of limited resources). An examination of the potential performance issues and the case study series noted 2 issues that consistently arose as areas of concern: criteria focused on the individual patient medical issues (sometimes referred to as agent-based) and resource limitations (see Table 2).
TABLE 2 Potential Performance Issues That Consistently Arose
The literature review for the research includes an extensive section on modeling to include agent-based or individual focused criteria modeling. This review included comprehensive modeling focused on hospital evacuations and general population evacuations. Reference Rothman, Hsu and Kahn6-Reference Rozenfeld, Reynolds and Ewing10,Reference Santos and Aguirre17,Reference Thompson, Wu and Marchant18 The completion of the functional analysis enabled the development of a functional architecture. A functional architecture shows the functions that have to be performed to include the “logical sequencing of the functions and the performance requirements associated with the functions.” 13 The functional architecture is the development of the health-care facility evacuation concept, which is defined as a working theory with multiple conceptual elements, also referred to as a construct.
Phase 2: PERC Construct and Conceptual Model (Functional Architecture)
The creation of the PERC construct highlighted relationships “among key low-level functions” using functional partitioning, which “is the process of grouping functions that logically fit with the components likely used.” Reference Ventura1,13 This effort included the use of expert elicitation and resulted in the development of an extensive low function process for consideration. Table 3 displays a partial list that includes specific equipment, unique wards, and other criteria that impacted the evacuation of patients.
TABLE 3 Expert Elicitation and Extensive Low Function Processes
From this draft, a list of attributes was organized, identifying a general attribute category containing individual relevant attribute types. An example of this organization can be seen later in Figure 6.
PERC Construct Principles
The process of creating the PERC construct identified important guiding principles and assumptions for the functional architecture. They included:
-
Identification of patient medical conditions using an electronic health-care record (EHR) scan.
-
Creation of a patient resource requirements profile translatable to safe transportation resource and destination resource capabilities.
-
Categorization/standardization of transport and destination resource capabilities so they can be assessed against patient resource requirements.
-
Identification of the role of staff skills (paramedic, intensive care unit [ICU] nurse, etc.) and their relationship to equipment availability, as well as how they influence resource capability reporting.
-
Development of flex resource standardization including the required staffing to support key material resources (ventilator + paramedic or nurse).
-
Defining “patient safe” resources and resources that could be augmented to become “patient safe.”
-
Provide improved situational awareness when considering the usage of a scarce resource by presenting the potential need for that resource by the remaining patient cohort.
-
Provide an efficiency rating for a resource assignment by comparing the patient profile against each available “patient safe” resource.
-
Maintain a record of resource allocations and adjust the remaining resource availability for each successive patient.
These guiding principles and assumptions identified the need for new terminology, definitions, and a different approach to determining a patient’s care needs during an evacuation. Specific terms had to be defined from the onset to help guide the process. For example, “for the purpose of this research, a patient’s health-care needs were defined by the list of designated resources that were required by the releasing facility to maintain the patient stable before the evacuation.” Reference Ventura1 That list would be used to determine the appropriate transportation options and destination facilities capable of supporting that list of resources, thus meeting the “patient safe” minimum requirement. This is contrary to current practices that focus on the patient’s medical diagnosis as determined by medical professionals at the evacuating facility, whereas PERC focuses on the “identified resources and protocols that were successfully keeping the patient medically safe and stable.” Reference Ventura1
Defining Patient Safe
For an available transportation option or destination facility to be identified as “patient safe” for the specific patient processed for evacuation, the capabilities recognized for each must meet all the patient resource requirements identified (see Figure 2). If the patient was on a ventilator, then the transportation resource needed to have a ventilator onboard, ensuring not only the required material resource but also the related staff skillsets able to use that equipment. A supplemental or “flex” resources feature was included in the PERC design to identify which inherent resources from the evacuation facility or coalition emergency support supplies could be “added” to a transportation option and/or destination facility to qualify them as “patient safe.” This feature would help expand options for the decision-maker and improve usage efficiencies for the entire patient cohort.
FIGURE 2 Defining “Patient Safe”
Standardization and Characterization
The PERC functional architecture required some “ground rules” incorporating industry standards that defined generic transportation options and destination facilities. “EMS transportation resources were characterized based on the standardized federal specifications for capabilities, equipment, and personnel certifications.” Reference Ventura1,30,31 In a live deployment, PERC would require an inventory audit and assessment of these transportation options (during preparedness) to “generate transportation PERC profiles for each transport vehicle in a fleet, based upon the capabilities of the resource, including the inventory of equipment required on board for a given certification (eg, basic life support [BLS], advanced life support [ALS], critical care truck [CCT], the medications each is required to carry, and the skill sets of the EMS personnel assigned).” Reference Ventura1 As a whole, these transportation capability responses created PERC profiles for transportation resources that would be matched against a specific patient’s PERC profile. For example, a bariatric-capable ALS ambulance has a positive response (YES) or a check (√) for bariatric weight and all other medical attributes related to this medical intervention and, thus, was a likely contender for a bariatric intensive care patient or a post-operative bariatric patient who presented those patient resource needs.
In turn, the same characterization was implemented for destination facilities based on “resource availability at a coalition hospital identified through their census reporting.” Reference Ventura1 They were “defined by their in-hospital locations (ward/specialty care), their specific capabilities (eg, bariatric-capable beds and restraints), the equipment and logistics available to that location (ventilators, medical gases, bariatric winch, etc.), and the medical professionals available to that ward (ICU, cardiac, oncology, etc.).” Reference Ventura1 As with the transportation PERC profile, the destination PERC profile was compared with PERC profiles of each evacuating patient. Case in point, “a Neonatal Intensive Care Unit space at a coalition hospital had a destination resource PERC profile reflecting positive responses (Yes) or a check (√) next to the relative pediatric attribute types and most intensive care unit attribute types; thus a Neonatal ICU patient from the evacuating hospital was considered for this space since they [covered] those patient resource needs.” Reference Ventura1 Given that each patient transfer “placed each individual at greater risk of injury and medical complications, the logic for building a destination resource table was to help decision-makers find the right place capable of continuing patient safe care and minimize the need for a second transfer to another facility.” Reference Ventura1 Combining this decision process with the transportation allocation also promoted improved use of all available flex resources (ie, those staged and ready for use) for that specific patient movement, as in a flex resource sent with a transportation option and then also designated for use at the destination facility.
Phase 3: PERC Prototype and Dispatching Protocols
Through design synthesis, the PERC construct was transformed into a PERC conceptual model. 13 The conceptual model required the creation of “original algorithms, data tables, system output protocols, and decision-support displays that would later result in the creation of PERC prototype” through the physical architecture process. Reference Ventura1 Design synthesis defines the proposed product taking into consideration potential hardware and software elements, the physical architecture process establishes the specifications and baselines, and system architecture identifies “the process necessary for development, production/construction, deployment, operations, support, (etc.).” 13
The PERC model was the organizational translation or flow chart of the PERC construct. As displayed in Figure 3, once the patient’s resource needs are defined, then it is compared against all available transportation capabilities (to include those upgraded by flex resources), then it is compared against all available destination facility capabilities (to also include those upgraded by flex resources). As an enhancement for efficiency, the transportation and destination choices are also compared to find those that require the same flex resources, providing the decision-maker with the choice of maximizing those flex resource allocations.
FIGURE 3 PERC Model Process
To create the PERC prototype, physical and system architecture principles were applied to develop the protocols, terminology, logic paths, and conceptual user guidelines developed by the functional architecture and necessary to create a testable PERC prototype. In short, the synthesized data developed by this research along with the dichotomous tables and a host of original algorithms needed to be organized into a system, and the system needed to be vetted by using industry best practices and protocols.
PERC Model and Dichotomous Tables
With the PERC construct and decision-support tool concept developed, design synthesis was used to create a PERC model that “contains four attribute tables (Patient, Transportation, Destination, and Flex Resources), along with originally designed algorithms that accurately match a set of patient attributes to available patient-safe transportation and patient-safe destinations, including flex resources adapted to provide patient safe” options. Reference Ventura1 These attribute tables were originally created dichotomous tables specifically developed for this research through an innovative concept based on Gower’s principles for dichotomous files. This new dichotomous table concept allowed key criteria necessary to represent each patient’s medical information, to be translated to a form where it could be matched to available patient safe transportation options and patient-safe destination facilities, including flex resources. In short, the new dichotomous table concept allowed for the comparison of specific requirements against all available capabilities. This will be explained further with Figure 4.
FIGURE 4 PERC Adaptation of Gower Principle
Best Practices and Current Protocols
The PERC profile for transportation resources or a capabilities table for transportation resources was vetted against actual best practices for transportation dispatching protocols, issues with vehicle staffing, and the identification and use of logistical resources during a patient movement. This research conducted informal field interviews with the Director, EMS Relations, at Chippenham Hospital in Richmond, Virginia, and with the Chief Operating Officer of the Richmond Ambulance Authority. As a part of the interview, a copy of their patient transfer guidelines and information request forms were received and reviewed. These forms, coupled with the federal guidelines already referenced on EMS standardized equipment, were used to refine the PERC profile for transportation options enhancing the effective representation of capability tables. This table was then used to cross-reference and refine the PERC profile for patients enhancing the effective representation of requirement tables. The individual attributes (or line items) for each table had to be “dual-phase” such that they could represent both a requirement and a capability enabling the system to translate between the 2 dichotomous tables. With this capability developed, the PERC profiles for destination and flex resources were also completed. These 4 PERC attribute tables, based on the new dichotomous table principles, were the first of 2 core components of the PERC system.
The second core component is comprised of the PERC values and expressions created for each original algorithm developed by this research to organize the data output from the capabilities and requirements comparison. These algorithms distinguished between each comparison using “scoring algorithms based on Gower’s principles to calculate scores and validity of dichotomous characters, as shown in Figure 4.” The PERC system adaptation displays how 3 important values can be tabulated: (1) benchmark record value, (2) match value, and (3) response value.
A benchmark record value is derived from a PERC profile, a dichotomous table representation of a given patient or resource. Positive check marks or affirmative responses to the individual attributes within the dichotomous table create a standardized PERC profile that can be used for comparison. Typically, a patient PERC profile is set as the benchmark, and all transportation and destination PERC profiles are compared against it. Occasionally, a transportation option or destination facility PERC profile is set as the benchmark to find the most appropriate patient. For example, a high value/low availability transportation option, such as a pediatric CCT (PCCT) set as the benchmark could be revealed as the only patient safe option for several patients within the patient cohort, including those patients still in a vertical evacuation. A decision-maker may hold that PCCT for those patients instead of assigning it to a patient in the loading area.
A match value and response value using original algorithms identify the level of efficiency for the proposed matching profiles (including flex resources) against the benchmark profile. The combination of flex resources with a transportation option or destination facility normally lowers the efficiency value; however, the decision-maker may be able to use more abundant capability resources to transport or transfer a patient (ie, BLS or general care nontelemetry bed).
Adequacy and Efficiency
Once the values are derived, the prototype applies 2 separate analyses: adequacy and efficiency. An adequacy analysis determines if the comparison matched a transportation option or destination facility where the minimum met all of the same attribute values reflected on a given patient PERC profile. The adequacy analysis results in a safety score that reflects if a capability option is patient safe for that match. An efficiency analysis determines how close to an exact match is discovered during that comparison and identifies the excess (or unused capabilities) for each option considered. The efficiency analysis results in an efficiency score.
As seen in Figure 5, the safety score categorizes options that meet ALL of the patient’s requirements as patient safe (GREEN), identifies upgradeable options with the use of flex resources (YELLOW), and identifies nonupgradeable options (RED). Efficiency scores rank available capability options and are used to enhance decision-support with the hope of improving the efficiency of the overall evacuation. Once the choices are made, PERC records these decisions to provide a patient cohort evacuation analysis identifying potential meta-data for post-event review and also develops use guidance providing level-3 situational awareness for resource options under consideration. Level-3 situational awareness is considered the highest level of situational awareness and is associated with the ability to understand the impact of a decision on the whole evolution of an event even anticipating future requirements or status.
FIGURE 5 Adequacy and Efficiency
An example of the comparison can be seen in Figure 6 using a generic patient named Smith, J. The PERC profile for the patient is the benchmark profile with a benchmark record value of 10. Using the legend created in Figure 5, the CCT and the ALS–bariatric (ALS-B) capable ambulance are coded GREEN and are considered inherently patient safe (their match value is equal to the patient response value) with efficiency ratings of 31.25% and 33.30%, respectively (the match value divided by the response value for the transportation profile). The BLS ambulance is coded YELLOW, indicating that it is not inherently patient safe (match value was less than the patient response value) but could be upgraded to GREEN if flex resources F-12 (cardiac care staff), F-23 (ventilator), F-31 (IV fluids), F-33 (IV medications), and F-89 (advanced medications) are added to the BLS. Note that F-12, a staffing resource, is required to enable the other flex resources. Because a BLS ambulance does not normally have a paramedic assigned, there is no one qualified to operate the additional equipment added; thus, the system adds the cardiac care nurse (F-12). (Note: Flex resource PERC profiles are standardized representations of available logistical and staffing resources that identify how to “fill in the blanks” to meet patient resource needs. The flex resource codes used are administratively assigned to allow for quick table analysis of the required capability (as in F-12 in lieu of cardiac care nurse, etc.) when reviewing the resource comparison results. As in most cases, the flex resource(s) available (and most qualified) are those that the patient was already using for ongoing care at the evacuating hospital (ie, an ICU nurse, ventilator, bariatric bed, etc.).
FIGURE 6 PERC Analysis Results
The BLS efficiency score of 58.80% and coded YELLOW with inherent capabilities is moot given that it is not inherently patient safe. The important efficiency score is the 45.50% that includes the noted flex resources required to make it patient safe. Finally, the private transportation vehicle (PTV) is coded RED as it is unable to support a patient that is nonambulatory and is in supine/prone position. Note that the BLS would be coded RED as well if none of the required flex resources were available.
CONCLUSIONS
The development of the PERC prototype was essential to determine whether the PERC concept would be able to generate a statistically notable improvement to current practices. The prototype would enable the observation, measurements, and collection of the necessary data to test the PERC construct and model originated by this research. This prototype would be tested using a Solomon four-group simulation, the details, and relevant findings of which will be submitted in a separate manuscript at a later date.
Conceptually, the most critical value in the PERC design is its ability to be scaled as a region requires. Requirement/capability tables can be easily edited to incorporate new equipment or enhanced staff skills. It can be expanded to included multi-modal consideration if other forms of transportation are considered, such as air transport (medical or traditional), trains, commuter rail, or other mass transit infrastructure. It can also be expanded to include multi-nodal considerations if a patient needs to move from the evacuating facility to a transport hub before their final movement to a destination resource. As an original system designed to compare requirements against available capabilities, PERC has multiple potential applications inside and outside the health-care industry. With the appropriate systems engineering approach, the PERC system could be an effective system for a variety of transportation or logistics challenges.
