Engineering Papers⌕ Search

Engineering topics

D. Levin

Publications and source records attributed to D. Levin.

Preliminary Medical Risk Estimates and Clinical Capability Needs for Late Artemis Missions

BACKGROUND Human exploration spaceflight missions to the Moon and Mars present unprecedented challenges for in- mission medical care. Compared with the ISS, the greater distance from Earth will mean increased mission durations, communication delays, limited to no resupply opportunities, and significant limitations on the evacuation of ill or injured crew. Spacecraft mass, volume, and power will be curtailed while higher demands will be placed on the crew’s knowledge, skills, and abilities. In this higher risk environment, it is important to: a) quantitatively estimate human system risk attributable to medical conditions, a process known as Probabilistic Risk Analysis, and b) use these estimates to inform medical system design. IMPACT (Informing Mission Planning via Analysis of Complex Tradespaces) is a PRA and medical trade space analysis tool developed by NASA to advance exploration mission medical system design. IMPACT v1.0 improves upon and will soon replace NASA’s existing tool, the Integrated Medical Model, with: a novel evidence base baselined to exploration environments; an expanded list of 119 medical conditions; a significant increase in the number of medical resources that can be utilized and in the flexibility of their use; and the modelling of time lost performing mission-specific tasks due to medical conditions. METHODOLOGY: This abstract will present IMPACT estimates of medical system risk and clinical capability needs for the Artemis IV mission. Artemis IV is currently scheduled for 2026 and will visit the Gateway space station in lunar orbit prior to the second lunar landing of the Artemis program. The baseline Artemis IV mission that was modeled was 28 days in duration with phases including Orion outbound, 4 days on the Gateway space station in lunar orbit, 2 crew on the surface of the Moon for approximately one week, an additional 5 days on Gateway, and then return to Earth. This baseline was compared to two alternative 34-day design reference missions (DRMs) that shifted the lunar sortie earlier or later in the mission profile. Assumptions included 2 female and 2 male crew and a notional medical system mass of 25 kg. Medical system risk estimates include loss of crew life (LOCL), consideration of medical evacuation (known as return to definitive care – RTDC), and an estimate of crew time lost due to medical conditions (Task Time Lost – TTL). The presentation will also describe the medical conditions that are the greatest drivers of risk as well as the clinical capabilities and resources that have the largest effect on risk. RESULTS: All three DRMs had very low probability of LOCL from medical conditions, primarily due to short duration. RTDC was also similar across the DRMs. In contrast, TTL was higher in the early lunar sortie DRM due to earlier occurrence of EVA-related medical conditions. Taken as a whole, there was no clinically significant difference in medical risk across the three missions. Results for clinical capabilities and an example medical equipment list will be discussed but were similar across DRMs.

D. Hilmers↗

Candidate Formulary Development for Exploration Missions

An interdisciplinary team of clinician, pharmacist, and system engineer subject matter experts (SMEs) collaborated to match pharmaceutical resources to the medical conditions anticipated to occur during exploration class missions. This effort began by using a SME generated Exploration Medical Conditions List and the associated medical system capabilities necessary to treat them. Using the systems engineering software MagicDraw™ and knowledge of pharmaceutical use and efficacy in spaceflight, the team traced appropriate medications to the medical conditions. These traces were used to pilot the process for generating a candidate formulary for level of care 4 and level of care 5 medical systems. This presentation will discuss the collaborative efforts of the team as they developed the content, detail the challenges of utilizing systems engineering software to describe clinical resources, and provide an overview of how the candidate medication formulary for exploration class missions was developed. It will also discuss how the lessons learned from this pilot effort can be applied to streamline future work.

S. Kurian↗

CLINICAL DECISION SUPPORT: PATH TO FUNCTIONAL REQUIREMENTS

Long-duration, deep-space exploration missions present significant challenges to crew health and performance. These challenges include the individual and combined effects of microgravity, radiation exposure, isolation, limited resources (mass, volume, power, data and crew time), limited options for evacuation and those associated with delayed or constrained communications, all of which demand greater crew autonomy. Specifically, as the communication delays intensify the further we explore space, the unqualified need for Earth-independent medical operations focused on autonomous diagnosis, treatment and prevention will be key to mission continuation and success. To augment the requisite knowledge, skills and abilities (KSAs) of a time-constrained crew operating under stressful conditions, combatting fatigue, and facing a potential medical crisis, a robust clinical decision support system (CDSS) is a probable solution that would facilitate, guide and inform Earth-independent medical operations, while assisting crewmembers through various clinical presentations. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) is expanding the boundaries of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit. ExMC is actively identifying and testing next-generation medical care and crew health maintenance technologies. The Clinical Decision Support (CDS) project addresses gap Medical-701 within the Inflight Medical Conditions risk: “Enhance medical capabilities within an exploration medical system.” Though mass, volume, and power will face increasing constraints, the projected computational capabilities of spacecraft systems will increase exponentially as information technology continues to advance this decade and beyond. Hence, data, software and computational resources will play an essential and synergistic role in maintaining crew health, wellness and performance in deep space missions. The focus of the CDS project is to develop recommended requirements for an in-vehicle CDSS that acts as a ‘virtual assistant’ for delivering optimal health, performance and medical care during exploration missions. The CDSS is envisioned as an integrated, software-based tool deployed on a laptop computer or handheld device. The CDSS will assist the crew and ground support when interacting with knowledge/databases (e.g. records, pharmacy, schedule), instrumentation (e.g. imaging, physiological monitoring devices), and habitat (e.g. wellness system, task performance system) and vehicle systems (e.g. environmental system, communication system). In addition, the human interface will employ a context-based approach that accounts for the crew’s situation. Thus, extraneous and clinically/operationally non-relevant information are reduced to avoid an increase in cognitive load. The framework of an ideal spaceflight CDSS is to include core and advanced analytical features that incorporate work from collaborators yet maintain a flexible platform for integrating new technology in the future. In fiscal year 2021 (FY21), the CDS project identified requirements through two primary mechanisms: (i) the development of software implementation prototypes and (ii) the application of systems engineering processes. The CDS project developed and tested a series of increasingly complex system prototypes that were based on use cases derived from the CDSS concept of operations (ConOps). These software implementations yielded insights on CDSS functionality as well as lessons learned that provided the initial requirements for CDSS capability. By applying a systems engineering (SE) approach, medical scenarios provided in the ConOps and the use cases for software implementation underwent functional decomposition to identify CDSS functionality. Also, systems-based modeling language (SysML) tools such as activity diagrams were developed from the same ConOps and use cases to identify CDSS functionality. The lessons learned from software implementation defined both specific requirements and broad areas of requirements. Within these defined broad requirement areas, further analysis of the SE products identified specific capability that resulted in the final functional requirements. In summary, the software prototypes, functional decomposition of the ConOps and use cases, and SysML diagrams provided the basis for the CDSS requirements developed in FY21. In the upcoming year, these requirements will be refined for their final ExMC baseline review in latter FY22.

clinical decision support↗

Root Cause Analysis of the Data Refinement Process – Medical Conditions Capability Resource Tables

The medical system for spaceflight thus far has been designed to support missions in low earth orbit (LEO). Crew capabilities are limited and heavily dependent on the team of medical support staff at Mission Control Center (MCC) to guide diagnosis and management. However, missions to the Moon and Mars will suffer from several constraints that will make this ground support focused approach to care ineffective. In order to update and modify medical system design, NASA has relied on Probabilistic Risk Assessment (PRA) modeling to mitigate medical risk through trade space analysis. Specifically, capability resource tables (CRT’s) were developed to create a dataset of resources required to manage a list of accepted medical conditions significant in exploration spaceflight. With 120 conditions, this dataset contained hundreds of capabilities and thousands of resources with tens of thousands of cells of data. Initially these tables were built in excel for high throughput during development, but ultimately had to be transferred, managed, and modified into the Evidence Library database for modeling purposes. The process of collating and reviewing the Evidence Library revealed numerous errors in the dataset that had to be corrected through iterative changes. Several error types emerged during this process and can be broken into specific classifications defined as “input”, “transcription”, “structural”, “branching”, and “information”. In reviewing these error types through the root cause analysis (RCA) approach, we were able to identify the contributors to these errors which included single data review points, changing product end goals, limited software selection, time constraints and several others. By reviewing and evaluating the underlying causes we can provide possible system improvements that can be implemented for current and future data management in PRA model inputs.

A. Anderson↗