Patent Application
20250010045
The present disclosure relates generally to external ventricular drains, and, more particularly, to a digital external ventricular drain device that monitors and regulates intracranial pressure and cerebral spinal fluid flow.
It is well-established that accurate intracranial pressure (ICP) monitoring is essential in the evaluation and treatment of traumatic brain injury (TBI), with further evidence that ICP monitoring after primary decompressive craniectomy for TBI patients may significantly decrease in-hospital mortality as well. Furthermore, the use of external ventricular drains (EVDs) in patients with these injuries may also improve survival. During the golden hours (i.e., the time period following traumatic injury during which is the highest likelihood that prompt medical treatment will prevent death), and especially in rapidly changing environments with limited resources, such as during patient transport or in field hospitals, the ability to not only measure ICP but also regulate intracranial pressure while quantifying and regulating the flow of cerebral spinal fluid (CSF) digitally, in real time, with changing patient conditions and position would be invaluable, and this benefit would also extend to the ICU environment in both military and civilian settings. Current EVD systems in clinical use cannot do this as they have no capability to make digital measurements and require manual adjustments by a caregiver for any change in patient position, condition or CSF flow.
The paper, Jay A. Johannigman, USAF M C, et al., Reducing Secondary Insults in Traumatic Brain Injury, Military Medicine, Volume 180, Issue suppl_3, Mar. 1, 2015, Pages 50-55, highlighted the challenges in treating TBI patients during rapidly changing clinical settings and throughout multiple echelons of care. It reported that although cared for by an Air Force Critical Care Air Transport Team (CCATT), more than half of the TBI patients who were undergoing air transport had an ICP >20 mm Hg recorded at some point during the flight, with all but one individual showing instances of ICP that were +/−50% of their baseline ICP. The conclusion was that patient movement resulted in changes in ICP from external stimuli and from acceleration/deceleration forces, and that CCATTs should prioritize monitoring, including venting of an intraventricular catheter in real-time if ICP increased above a critical threshold.
A digital external ventricular drain (DEVD) device that measures and responds to ICP (i.e., opening the EVD flow when pressure meets a predefined threshold) while also quantifying CSF flow rate in real time, and performing both functions concurrently. The DEVD makes adjustments automatically, and in real time, and may alert the caregiver to these changes and make a record of any events occurring, while also transferring this data to a central location as well as to the next team caring for the TBI patient. However, while a digital EVD with basic functional capability exists, this technology is advanced with the disclosed DEVD by including flow regulation for targeting or limiting CSF drainage and by providing backpressure regulation of the DEVD for use when decisions must be made about patient tolerance for removing or internalizing an EVD currently in place. In addition, appropriate closed loop feedback and programming algorithms are provided to enable the pressure and flow valves and sensors to work both together and independently as needed, and include sensors for identifying changes in patient position that the DEVD will be responsive to in real time while also alerting caregivers of these changes.
Furthermore, there is a clear need for the integration of data analytics and predictive modeling in the treatment of TBI from the point of injury through all echelons of care in order to improve outcomes and reduce secondary brain injury, especially as new treatments and interventions become available. The present disclosure responds to this need by not only advancing the capabilities of the DEVD device, but enabling the DEVD to interface with a sensor server that will allow the rich digital data streaming from the DEVD (including ICP and CSF flowrate waveform and graphical data) to be utilized in performing data analytics, including the potential for predictive modeling, for advanced TBI diagnosis and treatment in all phases of care. The sensor server will allow data to be securely delivered from the DEVD to a Big Data Platform and will be developed based on best practices, open messaging architecture and open standards. This sensor server will also allow the data from the DEVD to be associated with other waveform and clinical information harvested by the Big Data Platform, such as ECG, arterial pressure waveforms, pulse oximetry, and other clinical information. In this way, as the DEVD is prepared for use in the clinical space, it will also have a ready platform by which the rich digital data it produces can be used in advanced TBI care, and this digital data can then follow the TBI patient from point of injury through the entirety of his/her treatment course.
Referring to
Referring to
The DEVD 10 enables automatic adjustments with real-time changes in patient position, including immediate EVD venting and increased EVD drainage as required to keep ICP below a critical threshold, and also increases situational awareness of caregivers. This includes alerting caregivers in a busy field hospital or ICU if ICP is increasing and/or if CSF flow is increasing/decreasing as well, and this may help reduce the risk for secondary insults (also referred to as secondary brain injuries) in patients with TBI. Furthermore, the DEVD 10 also addresses a current gap in the medical care of patients who are transitioning between phases of care. Specifically, it enables caregivers in each phase of care to have immediate access to all information prior to that point, whether the events were prior to transport or prior to arrival in the unit or hospital, including historical data regarding ICP and CSF flow. This data also includes documentation of critical time points when pressure and/or flow were outside the range of desired parameters, and enables continuous monitoring and reporting of complex physiological data, such as pressure reactivity index (PrX), via interface with the sensor server that enables integration of DEVD data with other physiologic/monitor data and medical record information. In this way each care team will have the best available information at hand, and may be more aware of the patient's current state and clinical needs, which could improve their ability to care for the patient and potentially reduce morbidity and secondary brain injury.
Further, the DEVD has the ability to: monitor ICP while allowing continuous EVD drainage and monitoring CSF flow rate: set a baseline pressure as defined by the user through a digital interface; identify changes in patient head position that could impact patient care; automatically and in real time adjust the EVD system to maintain the desired EVD pressure and CSF output as necessary based on changes in patient head position and condition, including backpressure if desired; and link wirelessly to caregivers and to a sensor server capable of pushing DEVD data to big data platforms, analytics platforms, and user interfaces, including the ability to call up historical data on demand. The DEVD also alerts the caregiver when pressure or flow is in excess of desired limits set for that patient and automatically adjusts CSF drainage via the DEVD based on patient needs. The DEVD is further integrated with a sensor server to push this data to the platforms described above.
The DEVD includes closed loop controls of pressure and flow parameters (both independently and dependently) based on user input, including the application of system backpressure as needed. Components of the DEVD system include advanced pressure and flow sensors working both in tandem and independently with the ability to monitor ICP during EVD drainage; monitor, quantify, and regulate CSF flow and pressure in a precise manner; and apply EVD system backpressure when desired through programming algorithms run via a programmable interface circuit board and single-board minicomputer.
Therefore, the digital EVD system 10 with integrated ICP monitor and CSF flow monitor/pressure regulator has the ability to:
The DEVD includes connections compatible with the tubing size and material used in current EVD systems and will include a wireless digital interface display (
Referring to
Referring to
Briefly, referring to
Referring to
Referring to
The DEVD 10 enables automatic adjustments with real-time changes in patient position, including immediate EVD venting and increased EVD drainage as required to keep ICP below a critical threshold, and also increases situational awareness of caregivers
There are several hardware and software components that work together to make the Digital EVD a complete solution and enable sensor server integration with open architecture. Briefly described below are the components of both the DEVD 10 and the sensor server that make this integration possible and manage the transfer of DEVD data to big data and advanced analytic platforms throughout all echelons of care.
Referring to
The sensor server 604 receives data from any device, aggregates it, and sends it off to the proper storage or analytics mechanism. The sensor server 604 includes a tuned real-time data stream subscription process 608, such as the Kafka™ Consumer, that subscribes to messages from any of the DEVDs 10 that are monitoring patients. The subscription process 608 can then route messages to any end point within a Big Data Platform 610. Data from the DEVDs may also be routed to a time-series database 612 (e.g., InfluxDB). However, data could also be routed to other storage systems like Hadoop® by Apache™, Netezza® by IMBR, a regular file system, or even sent into an Analytics Engine 614. In this way, the DEVD data can be integrated with other physiologic and medical record data in order to perform advanced analytics that may improve diagnostic capabilities and identify pending clinical deterioration well before they occur. In addition, a visualization dashboard 616, an example of which is shown in
The DEVD 10 with sensor server 604 integration also allows scaling throughout the hospital or other medical facility. In addition, it enables the capability to monitor a TBI patient's progress throughout all transitions of care, from either a central location, via remote access, and/or wirelessly between transitions of care in which care givers must have vital clinical information at hand.
The voltage values are received by the single-board computer 400, such as the Raspberry Pi computer of
In addition to reading pressure and fluid flow values from the DEVD, the closed loop control may maintain the pressure and flow at a constant set point value for cranial pressure and spinal fluid flow at blocks 832-838. In one embodiment, backpressure may be measured in order to test the patient for reaction to shunt removal. In particular, the backpressure cannot be measured accurately while there is flow, so control is provided to the pressure/flow regulator valve to stop fluid flow at block 832. This may be done periodically (e.g., every 5 seconds), which may be changed based on clinical needs. Then the absolute cranial pressure may be read at block 834, a voltage value calibrated to the absolute pressure measurement at block 836, similar to the calibration disclosed above, and a serial write made to the single-board computer 400 at block 838 for transmission to, for example, the mobile computing device at blocks 840-846.
The DEVD 10 establishes communication with a sensor server 604 capable of providing real-time retrieval of historical data and transmission of DEVD data to big data platforms 610, advanced analytic engines 614, and wireless interactive displays 616. In order to truly advance the capabilities of the DEVD 10, communication between the DEVD 10 and a sensor server 604 capable of pushing all data is established, including graphical and waveform data, to the big data platform 610, advanced analytics platform 614, and to a user interface 616 that will enable visualization of this data remotely and wirelessly while allowing caregiver input to define the pressure and flow parameters required for each individual wounded warrior or TBI patient. This system also allows for transfer of vital patient data between transitions and through all echelons of care from the field hospital or outside facility, through transport, and to a definitive care facility. As noted above, this will include the integration of the publication process 602 within the single-board minicomputer 400 that will link with the subscription process 608 residing on the sensor server 604. This subscription process 608 is programmed to route messages (data) to any end point within the Big Data Platform 610. Additionally, data is routed from the DEVD 10 to a time-series database 612 (e.g., InfluxDB) for further delivery to a user interface display 616 (e.g., Grafana®). This data will also be considered for routing to other storage systems including Hadoop®. Netezza®, or a regular file system. Finally, a pathway is established for this data to be sent into the Analytics Engine 614 so that this vital patient data can be combined with other physiologic and clinical data for future work in developing predictive analytics and advanced diagnostic capabilities to support future precision medicine approaches.
After completing bench testing and initial sensor server integration, the DEVD may be tested in realistic clinical conditions via an established model of swine traumatic brain injury. In this model, traumatic brain injury is simulated by introducing an expanding fluid filled balloon into one cerebral hemisphere which mimics an expanding hematoma on that side. A standard ICP monitor is placed and ICP is recorded throughout the experiment, along with continuous physiologic monitoring and laboratory measures, including blood gas measurements. Cerebral perfusion pressures will be calculated and recorded as well. The DEVD will be integrated with an intraventricular catheter placed by the animal laboratory technicians, and ICP, as well as CSF flow rate and EVD system pressure, will be monitored by the DEVD as ICP increases and the TBI model progresses. In addition. Digital EVD target pressure and flow parameters will be adjusted and observed for appropriate effect, including the application of backpressure from the DEVD. Intracranial pressure measurements via the DEVD will be compared with the current standardized ICP monitor used for the swine TBI model, and flow/volume measurements will be confirmed via direct measurements of volume and flow rate of CSF obtained in the collecting reservoir of the system.
This solution provides caregivers from the field hospital, to the ICU, to the rehab facility, the ability to quantify, regulate, and monitor ICP and CSF drainage remotely in a manner that was previous unavailable as well as link vital patient data regarding ICP and CSF flow to visual interfaces and data storage that can be accessed at any time and provide platforms for advanced analytics and precision medicine. Given the importance of both ICP monitoring and EVD use in TBI, this DEVD system provides a safety net for caregivers who are operating with limited resources or caring for multiple patients, and would also improve the accuracy of pressure and flow measurements obtained via EVDs. Furthermore, this system alerts the caregiver to changes in ICP or CSF flow and keep a historical record of these changes, while having the capability to create backpressure, automatically respond to changing patient conditions, and regulate flow in a precise manner to ensure excessive CSF loss does not inadvertently occur. This is especially important in cases where large swings in CSF drainage and ICP can lead to clinical deterioration, electrolyte disturbances, and increased adverse outcomes such as secondary brain injury.
The DEVD device may be utilized in any environment in which ICP monitoring is being conducted and/or CSF drainage is being tracked, quantified, or evaluated. The device may be used immediately after insertion of an EVD or intraventricular catheter, and given that it offers real-time measurements and adjustments in EVD pressure and flow parameters with changing patient position and condition, the device could have a significant impact on the ability of providers to care for these patients, including a decrease in caregiver workload while increasing situational awareness. Because the device can be used immediately after EVD/catheter placement, it could be utilized early in patient care, from the field hospital to the civilian ICU, as well as during the transport of brain injured patients with an EVD, ICP monitor, or catheter in place. Furthermore, with the integrated open source architecture for data transfer and its ability to link up with a sensor server, critical patient data regarding ICP and CSF flow could be communicated across all echelons of care, with each new caregiver having immediate access to historical data and graphical information regarding vital clinical information, from the field hospital or outside institution, through transport, to level IV or higher definitive care and tertiary/quaternary care centers. In addition, the use of the DEVD could extend to other patients as well, such as those who require externalization of a shunt for hydrocephalus in which fine adjustments in EVD system pressure are required and continuous quantification and measurement of CSF drainage is essential, with clinical progression tracked, monitored, and recorded via sensor server integration.
Given the multiple settings in which the DEVD can be used, users would include nurses, mid-level providers, and physicians involved in the care of the brain injured patient as well as paramedics, combat medics, and others who are involved in patient transport.
In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
Accordingly, the term “hardware module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.
Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple of such hardware modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connects the hardware modules. In embodiments in which multiple hardware modules are configured or instantiated at different times, communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware modules have access. For example, one hardware module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
The various operations of the example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.
Similarly, the methods or routines described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented hardware modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but also deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.
The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but also deployed across a number of machines. In some example embodiments, the one or more processors or processor-implemented modules may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other example embodiments, the one or more processors or processor-implemented modules may be distributed across a number of geographic locations.
Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.
As used herein any reference to “one embodiment” or “an embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
Some embodiments may be described using the expression “coupled” and “connected” along with their derivatives. For example, some embodiments may be described using the term “coupled” to indicate that two or more elements are in direct physical or electrical contact. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. The embodiments are not limited in this context.
As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).
In addition, use of the “a” or “an” are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the description. This description, and the claims that follow, should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.
This detailed description is to be construed as an example only and does not describe every possible embodiment, as describing every possible embodiment would be impractical, if not impossible. One could implement numerous alternate embodiments, using either current technology or technology developed after the filing date of this application.
| Number | Date | Country | |
|---|---|---|---|
| 62588548 | Nov 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16765618 | May 2020 | US |
| Child | 18890252 | US |
