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.” ¹³ This includes sub functions, interfaces, groupings, and functional characteristics. ¹³ 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. ¹³

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.” ¹³ 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. ¹⁶

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.” ¹³ 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. ¹³ 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.).” ¹³

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.