Keywords

1 Introduction

Recent events such as the grounding of the Navy’s T-45 training squadron [2] have motivated a renewed interest in studying aviation-based physiological events. One of the more commonly reported physiological events is hypoxia [1]. In order to better understand hypoxia, the researchers investigated the relationship between physiological and subjective indicators of hypoxia. The research design included tracking and recording 21 commonly experienced symptoms of hypoxia, symptom severity, self-report data, continuous physiological data, and various system data (see Table 1 for a detailed list). Data were collected from participants going through hypoxia awareness and mitigation training at various Aviation Survival Training Centers (ASTCs). The researchers observed and recorded symptoms as they occurred during a normal training session. Trainees were also asked to wear physiological data monitors for the duration of the training event.

Table 1. List of variables tracked during research
Full size table

Researching hypoxia symptomology in an applied context such as during aviation survival training presents unique time-related challenges. Traditional data collection methods can be slow and time consuming (e.g., written surveys, video recording, hand written notes). When conducting research in an applied setting where there is less control than in a laboratory setting, these previous approaches to collecting data can be inconvenient and detrimental to the internal validity of the study. To address some of the practical concerns associated with traditional data collection methods, the researcher has the choice to collect fewer variables, run fewer participants at a time, or risk the accuracy and completeness of the data. The training done at the ASTCs is considered critical to the safety of the military’s future and current pilots and aircrew. Thus, the impact of our study to the training had to be minimal in that we would have to find a way to collect data without adding or taking away from the training in a significant way.

Environment aside, the challenge of tracking, recording, and synchronizing multiple variables had to be addressed. In the current research, trainees were encouraged to describe symptoms they were experiencing as they became aware of them. Additionally, instructors were asked to probe the trainees for their symptoms to ensure sufficient data collection. Using a traditional method, the researcher would be responsible for recording symptoms as they occur along with the reported severity, time of occurrence, time elapsed, et. In the event that multiple symptoms were being reported or observed the researcher would be hard pressed to capture every data-point. When collecting both subjective data via observation and physiological data via automatic monitors, timing is crucial to ensure the data can be appropriately synchronized after collection. In order to efficiently and accurately collect data in a time sensitive environment where multiple variables are being collected and monitored at the same time, it is essential to have a tool that enables the user to streamline this process. Simply put, traditional paper-based approaches to collecting data are impractical and reduce the amount and accuracy of data collected.

The solution presented by the authors is the creation of the Hypoxia Assessment and Recording Program (HARP) application. The HARP app was developed to enable researchers to track, streamline, and organize data for analysis. The HARP app is a dynamic web-based application designed to help track both subjective and physiological data related to aviation-based physiological events. It is expected that HARP will help facilitate data collection in both applied and laboratory settings while increasing efficiency and accuracy of the data collected. HARP’s utility goes beyond this one study. HARP can be used to tackle one of the issues facing cross-disciplinary research, namely threats to internal validity (i.e., instrumentation). HARP provides a way to enable collection of synced-up objective and subjective data while strengthening internal validity of the data.

2 Methods

2.1 Front-End (User) Design

A web-based interface ensured the application’s deployability on any platform capable of running a web browser or web view. Hardware required that DoD Windows 10 baseline serve as the host operating system in the current iteration. A single executable program launches a Chrome browser, which connects to a locally hosted Express server. When opened, the initial screen provides two toggle switches to choose from (i.e., slow or dynamic profile). Toggle buttons were chosen for ease of access and to let researchers be sure of which profile was chosen. The initial screen also contains a box to enter the participant identification number and proceed to data collection. After entering the participant data, the user is navigated to the main symptom recording screen. This main data collection screen of the application contains 21 selectable boxes for each symptom of hypoxia (i.e. air hunger, apprehension, belligerence, blurred vision, cold flashes, confusion, cyanosis, difficulty concentrating, difficulty speaking, dizziness, euphoria, fatigue, headache, hot flashes, lack of coordination, nausea, numbness, pressure in face, stress, tingling, twitching) four selectable boxes for each symptom severity levels, cancel, submit, and end boxes, a notes section, and a button to advance to the next stage in the profile. A dialogue box was placed at the bottom of the app that displays the current elapsed time, the last symptom and severity selected, and the time, altitude, and O2 level when the symptom occurred. The main collection screen is used first by the researcher to collect symptomology data during a training event. At the conclusion of the event, the researcher ends the session and begins the recovery period. During the recovery period the screen opens a dialogue box informing the researcher the recovery period has begun and initiates a stopwatch function that is displayed for the user. Once the participant has recovered, as indicated by two thumbs up to the instructor, the user must click to end the recovery period and HARP will navigate back to the main collection screen where the participant will enter any symptoms they can recall.

2.2 Back-End Design

When running, HARP is capable of logging 21 unique symptoms while simultaneously tracking incoming data from a running profile. Two different profiles were programmed into HARP; slow and dynamic. The profiles come directly from the Reduced Oxygen Breathing Device (ROBD) used in hypoxia training. The slow profile gradually brings trainees up to a simulated altitude of 25k ft. over the course of ten minutes. The dynamic profile is programmed to bring trainees up to a simulated high altitude within two minutes and then hold them at that altitude. Training profile data in the data collection application is time stamped to be synchronous with the ROBD program. Changes in simulated O2 and altitude levels are reflected to the second. When designing how the exported data would appear, it was important to keep in mind the end-user (i.e., the researcher) of the data. All data reports were converted to.csv files to allow use in excel and formatted in two distinct ways. First, the data file was formatted to import in order of recorded symptom, severity of that symptom, simulate O2 level, time (elapsed seconds), and altitude at which the symptom occurred, any notes entered, and the actual time the symptom occurred. The first formatted data file displays as a list type and allows the user to have a broad overview of all symptoms that occurred for the participant. The second data file that is generated is formatted to match the database that was created for the specific statistical analysis software used in the research. By auto populating the data to match the created database, the time required to enter data into the statistics software is drastically reduced. All variables collected using HARP for a given training event are populated in rows versus columns so all the user needs to do is copy and paste the data into the statistical software database.

2.3 Design Methodology

The HARP team applied a top down design. The application needed to capture and export observed symptom data synchronized with the ROBD data in a CSV format. A touch-enabled interface was developed for ease of use and ubiquity of available platforms. Node, with its robust collection of middleware and uncomplicated deployment was a natural choice to handle the back-end web service and data processing. Once these systems were in place, stepwise refinement of each system contributed to the success of HARP.

3 Results

Creating HARP was a process whereby the engineer and end-user worked hand-in-hand during the creation and refinement processes. In lieu of a survey-based usability evaluation of HARP, the design team took an iterative approach to development. End-user feedback was integrated into each phase of development and refinement. The users relied on past literature [3,4,5] to formulate a heuristic guide for facilitating adequate usability. The heuristics used to guide development include graphic design and aesthetics, effectiveness of developmental characters, user efficiency, and consistency. The principles discussed here were considered in each iteration of HARP to simplify and coordinate the data being collected. The following describes each phase and the changes that were made as a result of user-based evaluations.

3.1 Phase 1

The original requirements for the program were to build a digital survey capable of tracking 21 symptoms of hypoxia (e.g., air hunger, dizziness, nausea, light-headedness) and associated severity of those symptoms on a four-point scale. Output from the survey were designed to be provided on a spreadsheet in tabular form. That is, symptom categories and severity would make up the columns of the spreadsheet making it easier to integrate and analyze later on. A mockup of the initial design of the program (See Fig. 1) was provided to the software engineer in order to start building the basic architecture of the program while the same mockup was also provided to the broader aviation physiological episode research community to attain functional and usability feedback. The community recommended the application also account for training profile (e.g., slow and dynamic), time, altitude and oxygen concentration. These same variables were also added to the spreadsheet.

Fig. 1.
figure 1

Initial HARP configuration

Full size image

3.2 Phase 2

After the completion of the initial application, HARPs functionality and usability were tested during a pilot event. A second mockup (See Fig. 2) was provided to the software engineer based on feedback from the broader research community and information collected during the pilot testing. This second iteration of the software focused mainly on functionality enhancements and less on usability. The aforementioned additional variables (i.e., profile type, time, altitude, oxygen concentration) were requested. These additions would enable the complete and accurate synchronization of variables of interest, which was crucial for guaranteeing the internal validity of the research.

Fig. 2.
figure 2

Secondary HARP mockup

Full size image

3.3 Phase 3

The addition of the new variables had very specific implications for data exporting into the tabular spreadsheet. After the phase two iteration of the software the new variables were simply added to the spreadsheet in a specific order. For the purposes of the research it was crucial that symptoms were grouped by profile type, when they occur in the session, what altitude was being simulated, and what O2 concentration the trainee was breathing. Ordering the data in this manner further improved the ability of the application to ensure the synchronization. In addition to improving synchronization, this feature also streamlined analysis. Organizing data output in such a manner enabled the researchers to match the format of the destination statistical software.

4 Discussion

The iterative process used for the development of HARP increased the likelihood that it would meet the objectives to complete our cross-disciplinary research on hypoxia. The resulting application’s architecture could easily be adapted to any context in which there is a need to easily integrate and synchronize data. The outcome of this effort helped inform the design of a graphic-user interface used in a next generation hypoxia trainer. These trainers use many of HARP’s design features and capabilities, which result in a richer, more meaningful debrief after training.

Human research is notoriously challenging. This is exacerbated when data are collected in applied settings. While the digitization of subjective survey-based data is not new, the need to collect that data and synchronize it with other variables (e.g., time, altitude, simulated O2 level, profile) is of interest to researchers studying physiology and psychology simultaneously. The HARP application addresses a unique need. Research communities are increasingly understanding the importance of cross-disciplinary research [7]. Approaching a problem from multiple perspectives increases the probability of developing a comprehensive understanding of that problem. However, there are challenges specific to this approach that make it difficult to ensure internal validity. Software applications such as HARP are intended to alleviate some of these issues by providing a means for the easy integration, synchronization, and import/exportability of data. In the existing research, HARP helped us easily integrate and then understand what was happening in the environment (e.g., altitude, simulated O2 level, time), what the physiological response of the body was (e.g., heartrate, breath rate, temperature) and what subjective psychological experience the trainee was having (e.g., dizziness, confusion, color blindness, tingling). The application was the first of its kind for researchers studying unexplained aviation-based physiological episodes. The methodology and data collection techniques used in this study are essential for building a causal model. These models provide the basis of algorithms meant to build future alert systems and automation intended to help keep aviators safe and to allow them to focus solely on their mission. Cross-disciplinary research is logistically challenging. Hence, the large-scale execution of this type of research is yet to happen. Capabilities such as HARP can overcome some of the logistical challenges of this research making it more likely to occur in the future.