DOCUMENTATION, DEVELOPMENT, AND PROGRESS
The AMP was initially being developed as part the Advanced Integrated Clinical System (AICS)-Guided Medical Procedure System for the Constellation Program. The Exploration Medical Capability (ExMC) team generated an OpsCon document and, subsequently, a set of functional and technical requirements. All of these documents were reviewed and approved by the Johnson Space Center (JSC) Space Medicine Configuration Control Board in 2009 and 2010, respectively. These documents were then archived when the Constellation Program was canceled in 2010.
Fiscal Year 2012 (FY12) brought the start of the EMSD project and the initial development of the AMP. The Exploration Medical Capabilities (ExMC) element generated a new OpsCon document for the AMP to reflect how it would be used for the EMSD. This document was approved by the ExMC Advisory Board and then used to generate functional and technical requirements. These requirements were reviewed by the ExMC Advisory Board and during the EMSD’s System Requirements Review in March 2012. The ExMC Team then used the finalized requirements to conduct a thorough market survey and Request for Proposal (RFP) process.
Upon completion of the RFP process, the EMSD project team determined that no CDS solution existed that adequately satisfied the project requirements within budget constraints. Although CDS is an important aspect of the long term vision of the EMSD project, this class of software is still in the early stages of commercial development and the lack of solution within the project’s budget dictated that the requirement for this capability be removed from the project. The EMSD project team proposed this removal and ExMC management approved it. However, the system infrastructure of the EMSD, including the AMP, has been designed to support the integration of CDS software if, or when, a viable option exists.
Completion of the RFP process also resulted in the EMSD project team electing to pursue the modification and use of WebPD, a procedure viewer created by S&K Aerospace within the JSC-Engineering (ER) group. WebPD satisfied all core requirements of the AMP component as specified in the Statement of Work and the AMP System Requirements Document (SRD). The EMSD team adopted WebPD for the AMP with the knowledge that custom development would be required for full integration into the overall EMSD system. In addition, WebPD had no initial procurement cost and developers with the JSC-ER group were available to assist in development of the system to meet the needs of the EMSD project, including AMP development.
The approach for modifying and integrating the AMP into the EMSD was finalized during the EMSD Preliminary Design Review in June 2013. Following the EMSD’s Critical Design Review in January 2014, the EMSD project team and Exploration Medical Capability (ExMC) Element Management concluded that the Flight Demonstration would not provide any unique opportunities for meeting project objectives nor would it present a justifiable return on investment. Accordingly, the project team recommended that the Flight Demonstration objective be removed from the project. ExMC Management, with concurrence from the NASA Human Research Program (HRP), removed the requirement for a Flight Demonstration and agreed that all verification and validation of the EMSD, including the AMP, would occur on the ground.
The AMP user interface serves as the primary method for user interaction with the EMSD system. The project team reduced development time by modifying the existing WebPD graphical user interface to meet the needs of the EMSD system. The primary elements that make up the AMP user interface include a combination of text and numeric data fields, buttons, and list boxes for manual data entry, command execution and display; rich content fields for image and real-time media data capture, playback and display; and various windows areas for allowing user navigation.
The AMP was designed to present an initial screen that requires users to enter their unique user identification and password credentials before granting access to any EMSD data and system functions. This allows the AMP to meet the various security requirements for the privacy and confidentiality of medical information captured by the EMSD, as well as allows user interface elements and screens to be tailored to the specific needs of each user.
Once users have been authenticated, the AMP then allows users to continue on to only those AMP screens and system functions allowed based on the user’s role. This allows, for example, a user assigned to the CMO role to see more detailed medical information on multiple patients, as opposed to a user assigned to a patient role that may only see patient information specific to their own records.
The AMP was designed to present a secondary screen that requires the user to select a patient on which to perform an exam. All patients displayed are pulled directly from the Open Electronic Medical Record (EMR) database, which contains each crew member’s identify and role. The AMP allows for the user and the patient to be the same crew member, as some exams may be self-administered.
In addition to handling simple alphanumeric information, the AMP was designed to accommodate rich media content such as images, audio/video files, real time video input, and other proprietary device data and document files. A rich media area was incorporated into the AMP user interface which captures and displays rich media content. This rich media area can also be hidden and resized dynamically by the user, per user preference.
Following the selection of a patient by the user/CMO, the AMP displays the Patient History screen, which presents a subset of patient medical history data that is pulled from the EMR. The type of data presented on this screen is determined by the ground medical support team and is configured pre-flight. Data that may be included on this screen includes, but is not limited to, patient vitals, medical history, medications, and allergies.
The procedure selection screen of the AMP provides a list of all published procedures available to the user determined by his/her role within the EMR (e.g., physician CMO vs. non-physician CMO). This functionality allows for users to have access to procedures tailored to individual skill level and medical knowledge.
Upon selecting a procedure for execution, the user is presented with multiple viewing areas, with the primary area containing the procedure execution steps. This procedure area displays each step in the procedure, along with fields for data entry, rich media links, and mechanisms for system command execution. The user also has the ability to skip to another step in the procedure, both before and after the current step.
The AMP Graphic User Interface (GUI) displays and captures rich media content such as images, audio/video, and potentially other proprietary device data and document files. One of the AMP windows has been designed as the main EMSD application navigation menu, displaying user and patient metadata and allowing the user to navigate through various other AMP application screens. The AMP GUI also displays a tree view of all procedure steps and a list of completed procedure steps.
The AMP GUI has the ability to nest a procedure within another. For example, a step within the Periodic Health Evaluation (PHE) procedure directs the user to collect ECG data. If the user proceeds with this step, the AMP automatically launches the ECG procedure. When the ECG procedure is complete, the AMP automatically brings the user back to the original PHE procedure.
In general, at any point during a procedure execution, the user can start another procedure from the procedure selection screen on the AMP GUI. Also, manual data entry with the AMP is provided via free text fields, pull downs, and button selections. The inputs are stored locally within the AMP system and transmitted to the EMR upon completion of the procedure.
Commanding is initiated via the AMP GUI. For example, to initiate ECG collection the AMP issues a command to start the ECG companion software. Upon completion of the ECG, the system initiates another command, resulting in a published message that triggers the transfer of the completed ECG data file. This commanding functionality could be used to initiate any compatible peripheral device software integrated into the system.
Any text input or data read from a peripheral device by the EMSD is considered telemetry. This telemetry can be evaluated by the AMP system as collected to assist in the logical execution of the procedure. For example, pulse telemetry captured from a vitals device could be compared by the AMP system to a pre-set threshold value. If the vitals measurement exceeded that threshold, the procedure would prompt the user to perform an ECG. At the end of the procedure, the telemetry is submitted by the AMP to the EMR to update the patient’s medical visit within the EMR database.
EMSD procedure authoring was initially performed using the Procedure Integrated Development Environment (PrIDE) software (originally developed by S&K Aerospace for NASA-Space Medicine). PrIDE was eventually replaced with the Electronic Procedure Authoring Tool (EPAT). Both PrIDE and EPAT were developed within the JSC-ER group. EPAT provided the procedure author with the ability to:
-Display a text instruction
-Gather input from the user
-Invoke a formal system function, e.g., capture an image, show an image, or show a video
-Issue a system command
-Verify that a system state is in a specified target, e.g., ECG status or video recording status
In February 2015, the EMSD system was demonstrated at the NASA-Johnson Space Center to project stakeholders, including representatives of Human Research Program (HRP) management, Flight Analogs Project (FAP), the Behavioral Health and Performance (BHP) Group, the Astronaut Office, NASA-Flight Surgeons, and the Station Operations Data File (SODF) procedure standards group. Each demonstration consisted of an EMSD overview presentation to familiarize the attendees with the history and goals of the EMSD project followed by the “hands on” demonstration of the software system. Using the AMP Interface, attendees were walked through the log in, patient selection, procedure selection, and procedure execution aspects of the EMSD system. The information presented was well received by all attendees.
CONCLUSION
The work by the EMSD project team over the past three years has enabled ExMC to (1) identify and modify a software system to become the AMP system for the EMSD and (2) complete work that immediately addresses CPR Risks #17 and enables ExMC to better address CPR Risks #20, #22, and #23 in the coming years.
FUTURE WORK
The EMSD project serves as a proof-of-concept for an integrated medical data management system to be flown on an exploration mission. The EMSD system, including the AMP, is an illustration of the integrated medical data system concept and are meant to highlight potential functionality and uses of such a system. As expected, EMSD only gave a glimpse of what was possible, serving as a platform for those who experienced it to wonder what it could be made to do next.
Many of the ideas collected and questions fielded point to a future EMSD (and AMP) design that is more than just a stand-alone medical data management system. In fact, it is clear that the future of in-flight medical care will require the integration of data collected from all vehicular and habitat systems. Future exploration crews will require intelligent data management systems capable of providing mission guidance through the thorough analysis of environmental, vehicular, behavioral, and medical data. Only through this comprehensive view of what each crew member is experiencing can efficient medical care be provided by the CMO and ground medical support.
The commercial medical technology demonstrated in the EMSD (and AMP) is nascent but evolving rapidly. However, this technology is generally best suited for ground-based medicine, provided by a clinician, and in a clinical setting. It will be prudent for NASA to continue pursuing this technology and learning what modifications are necessary to provide future crewmembers with a medical system that best suits the needs of future missions.
|