WO2025212743A1 - System and method for simulating a medical examination - Google Patents

Abstract

The system allows for extremely versatile simulation of a medical examination. A physiological model of a patient features monitoring points with associated monitoring sensors. A processor connected to the model allows various simulation files to be played to a user based their interaction with the monitoring points and sensors. Different simulation files for different conditions may be easily swapped out to allow for multiple simulations with the same physiological model.

Description

SYSTEM AND METHOD FOR SIMULATING A MEDICAL EXAMINATION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of prior-filed, co-pending U.S. Provisional Patent Application No. 63/573,167, filed on April 2, 2024, the contents of which are incorporated herein by reference in their entirety.

BACKGROUND OF THE INVENTION

[0002] The present application is directed to the field of simulation. More specifically, the present application is directed to the field of simulating a medical examination on a patient.

[0003] Practical healthcare student training in physiological medical examination, both on human and veterinary patients, provides numerous obstacles for effective and reproducible results. Placement of examination equipment, such as a stethoscope, may not be properly reproduced by a student. Patient movement or changes in physiological conditions may result in differing readings as successive students examine the patient. Absent specialized equipment, an instructor cannot detect the exact same readings to ensure that the student is properly examining the patient. Specific types of patients, particularly different species in the veterinary field, or patients with specific conditions may not be available for examination on demand. Certain patients, such as large or aggressive animals, may be dangerous for inexperienced students.

[0004] Medical simulation models have therefore become crucial for training healthcare professionals in various medical procedures and scenarios, offering a safe and realistic environment for skill development. However, many such models are expensive, elaborate, and highly specialized, reducing both their utility and the ability for educational institutions to obtain sufficient numbers to allow classes to train effectively. Simulation models can be locked into specific simulations and conditions, unable to simulate a wide variety of patients and/or conditions. Models can also lack the ability to provide a gradated response based on the accuracy of a student’s examination, only providing the simulated readings under perfect or near-perfect examination conditions that do not facilitate learning. Conversely, models may be overly permissive, providing the same feedback regardless of examination accuracy.

[0005] It is therefore the object of this application to provide a system and method for simulating a medical examination which is uncomplicated and versatile, capable of simulating a variety of patient conditions and providing effective feedback as to the accuracy of an examination.

BRIEF SUMMARY OF THE INVENTION

[0006] The present method simulates a medical examination. The method includes the steps of: receiving at least one assignment value linking at least one simulation file stored in at least one storage component to at least one monitoring sensor located at at least one monitoring point on at least one physiological model; receiving at least one volume value for at least one simulation file; receiving at least one sensor floor value, at least one sensor minimum value, and at least one sensor maximum value for the at least one monitoring sensor; receiving at least one transceiver ID value for at least one transceiver in the at least one physiological model; placing at least one medical device model having a sensor trigger in proximity to the physiological model; receiving at least one raw data output from at least one monitoring sensor, the at least one raw data output comprising at least one sensor identifier and at least one sensor input value; storing the at least one raw data output in the at least one storage component; setting at least one normalized sensor value to 0.0 if the at least one sensor input value is less than the at least one sensor floor value; calculating the at least one normalized sensor value for each of the at least one sensor input values if the at least one sensor input value is greater than the at least one sensor floor value; selecting a largest normalized sensor value and setting all other normalized sensor values to 0.0; setting an output volume value at the largest normalized sensor value multiplied by the volume value; and playing the simulation file associated with the monitoring point having the largest normalized sensor value at an output volume corresponding to the output volume value.

[0007] A system for simulating a medical examination includes at least one physiological model having at least one monitoring sensor located at at least one monitoring point on the at least one physiological model, at least one medical device model having a sensor trigger, a memory comprising computer readable instructions, a processor operably connected to the at least one physiological model. The processor is configured to read the computer readable instructions. When executed, the computer readable instructions cause the system to perform the above method for simulating a medical examination.

[0008] A non-transitory computer readable medium comprises computer readable code to simulate a medical examination on a system. When executed, the computer readable code causes the system to perform the above method for simulating a medical examination. [0009] The objects and advantages will appear more fully from the following detailed description made in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0010] Fig. 1 a illustrates an example of a simulation system for simulating a medical examination according to certain embodiments. Figs. 1 b through 1 f depict examples of a model system, a processing component, a storage component, a user interface, and a simulation output, respectively, used in the simulation system, according to certain embodiments. Figs. 1g through 1 i illustrate various views of an example of a physiological model with monitoring points according to certain embodiments.

[0011] Figs. 2a through 2c illustrate a flowchart of an example of a method for simulating a medical examination using a simulation system according to certain embodiments.

[0012] Fig. 3 depicts an example diagram of a computer system that may include the kinds of software programs, data stores, hardware, and interfaces that can implement a simulation system as disclosed herein and according to certain embodiments.

[0013] It should be understood that, for clarity, not all elements are labeled in all drawings. Lack of labeling in a figure should not be interpreted as lack of a feature.

DETAILED DESCRIPTION OF THE INVENTION

[0014] In the present description, certain terms have been used for brevity, clearness and understanding. No unnecessary limitations are to be applied therefrom beyond the requirement of the prior art because such terms are used for descriptive purposes only and are intended to be broadly construed. The different systems and methods described herein may be used alone or in combination with other systems and methods. Dimensions and materials identified in the drawings and applications are by way of example only and are not intended to limit the scope of the claimed invention. Any other dimensions and materials not consistent with the purpose of the present application can also be used. Various equivalents, alternatives and modifications are possible within the scope of the appended claims. Each limitation in the appended claims is intended to invoke interpretation under 35 U.S.C. §112, sixth paragraph, only if the terms “means for” or “step for” are explicitly recited in the respective limitation.

[0015] The present invention includes a system for a simple, versatile way of simulating a medical examination of a human or animal patient, such as may be used in training a student. A physical model of the patient includes sensors embedded at points of the patient model where a medical professional would take physiological readings of a patient, such as, but not limited to, heart, gut, and breath sounds. A user may use a medical device model to simulate a medical examination by placing the medical device model within the proximity of the embedded sensors of the patient model. Depending on the proximity of the medical device model to the sensors embedded in the patient model, the sensors embedded in the patient model transmit proximity data relating to the medical device model to a processing system. The processing system uses the sensor proximity data to determine the simulated physiological reading provided to the student, as well as the volume. Accordingly, rather than simply playing back pre-recorded sounds, the system links both the sound and volume to where and how accurately the user is placing the medical device model relative to the physical model of the patient, providing feedback during the simulation.

[0016] By way of non-limiting example, if a student places a stethoscope model on or near a patient model in sufficient proximity to a sensor at an auscultation point used for heart sounds, the system will play back sounds of a patient’s heartbeat. The closer the stethoscope model comes to the sensor, the louder the heartbeat sounds will be. The further the stethoscope model goes from the sensor, the softer the heartbeat sounds will be. Once the stethoscope model reaches the optimum auscultation point directly above the sensor, the playback will be at maximum volume, indicating that the optimum point had been reached. Different auscultation points can utilize different files, allowing a student to know what a heartbeat will sound like from multiple auscultation points, or what respiration and heartbeat will sound like at different points in the same model.

[0017] Because the system has the ability to link any sound file to any sensor, the system is highly versatile. Different physiological conditions may be simulated throughout numerous different physical model representations simply by linking different sets of files to the various sensors on any variety of physical model representations. By way of nonlimiting example, one set of simulation files for a canine model comprises cardiovascular auscultation audio recordings from a large-breed, obese canine with no injury or illness while another set of simulation files comprises cardiovascular auscultation audio recordings from a large-breed, healthy-weight canine with no injury or illness. By way of non-limiting example, one set of simulation files for an equine model comprises cardiopulmonary auscultation audio recordings from a horse with pneumothorax injury while another set of simulation files comprises cardiopulmonary auscultation audio recordings from a horse without injury. By way of non-limiting example, one set of simulation files for a bovine model comprises gastrointestinal auscultation audio recordings from a dairy cow with parasitic infection, while a second set of simulation files comprises gastrointestinal auscultation audio recordings from a dairy cow with gastric volvulus, and a third set of simulation files comprises gastrointestinal auscultation audio recordings from a dairy cow with dysentery. By way of non-limiting example, one set of simulation files for a feline model comprises obstetrical auscultation audio recordings from a pregnant domestic cat. By way of non-limiting example, one set of simulation files for a human model comprises cardiopulmonary auscultation audio recordings from an adult male with no injury or illness while another set of simulation files comprises cardiopulmonary auscultation audio recordings from an adult male with a mitral valve defect and pneumonia.

[0018] A student may make simulated examinations of dozens, if not hundreds, of different patient conditions using the same model. A student such as a veterinary student may make simulated examinations of numerous different species, as the modularity of the system allow it to be easily adapted to different species simply by ensuring the correct number and placement of sensors in the model, and the assignment of the correct files to the correct model, e.g. canine sounds to a canine model and feline sounds to a feline model.

System

[0019] Fig. 1 a depicts an example of a simulation system 100 for simulating a medical examination, according to certain embodiments. Figs. 1 b through 1 f depict examples of a model system 1 10, a processing component 140, a storage component 150, a user interface 160, and a simulation output 170, respectively, used in the simulation system 100, according to certain embodiments. Figs. 1 g through 1 i depict different exterior views of an example of a physiological model 1 1 1 with monitoring points 1 12 according to certain embodiments.

[0020] Referring to Fig. 1 a, in an embodiment, the present simulation system 100 includes at least one model system 1 10 removably and interchangeably connected to at least one processing system 130. In various embodiments, multiple model systems 1 10 may be connected to a single processing system 130, multiple model systems 1 10 may be connected to multiple processing systems 130, a single model system 1 10 may be connected to a single processing system 130, or a single model system 1 10 may be connected to multiple processing systems 130.

[0021] The model system 1 10 includes a physiological model 11 1 of a patient having at least one monitoring point 1 12 The monitoring point 1 12 corresponds to a point on a patient where a healthcare professional would take a reading or otherwise examine a patient. At least one monitoring sensor 113 is placed at each monitoring point 1 12. The monitoring sensor 113 interacts with a medical device model 116 to determine how the simulation system 100 responds to the user’s actions. At least one model controller 114 is connected to the monitoring sensor 113 and a transceiver 1 15. The transceiver 1 15 provides a wired or wireless connection to a processing system 130.

[0022] The physiological model 11 1 is a physical representation of at least part of a human or animal patient, not a virtual representation. In various embodiments, the physiological model 11 1 may be a pet-type animal such as, but not limited to, a dog, a cat, a bird, a rodent, or a reptile. In various embodiments, the physiological model 1 11 may be a stock-type animal such as, but not limited to, cattle, a horse, poultry, camelids, a pig, a goat, or a sheep. In various embodiments, the physiological model 1 1 1 may be a representation of a specific breed of any of the aforementioned animals. In various embodiments, the physiological model 111 may be a representation having only rudimentary conformation to the surface appearance and physiology of the patient, a representation having significant conformation to the surface appearance and physiology of the patient, or a representation having very realistic conformation to the surface appearance and physiology of the patient. In various embodiments, the physiological model 11 1 may be a partial representation or a complete representation of the patient. The physiological model 111 may be a hollow shell containing other elements of the simulation system 100. The physiological model 111 may be a polymer shell.

[0023] Referring to Figs. 1 g through 1 i, in an embodiment, the monitoring points 1 12 are points on an exterior side of the physiological model 1 11 corresponding to sites for obtaining vital signs during a physical examination. The vital signs may be a type obtained through auscultation. In one embodiment, the monitoring points 112 correspond to sites for cardiac examination, pulmonary examination, obstetrical examination, gastrointestinal examination, and any combination thereof. In the embodiment shown, the physiological model 11 1 is a model of a dog, and the monitoring points 112 are sites for cardiopulmonary auscultation.

[0024] Referring to Fig. 1 a, in an embodiment, the monitoring sensors 1 13 may include analog proximity sensors such as, but not limited to, capacitive, inductive, and magnetic sensors. The monitoring sensors 1 13 are mounted to an interior of the physiological model 111 on a side opposite the corresponding monitoring points 1 12. In one embodiment, the monitoring sensors 113 are Hall effect sensors. The medical device model 1 16 includes a sensor trigger 117 configured to trigger the monitoring sensors 1 13. By way of non-limiting example, the Hall effect monitoring sensors 113 would be triggered by a magnet. The appearance of the medical device model 1 16 may be conformed to an appropriate medical device that would be used to obtain vital signs during the physical examination. In one embodiment, the medical device model 1 16 is a stethoscope head and the sensor trigger 117 is an embedded magnet.

[0025] Sensor input 118 from the monitoring sensors 113 is transmitted by a wired or wireless connection to the model controller 1 14. In certain embodiments, the model controller 114 is a circuit board microcontroller. In one embodiment, the model controller 1 14 is an Arduino microcontroller. The model controller 114 is programmed to constantly loop across all monitoring sensors 1 13 and compile the sensor input 118 into a raw data output 120. The raw data output 120 includes a paired sensor identifier 121 and sensor input value 122. By way of non-limiting example, a model system 1 10 with n number of Hall effect monitoring sensors 113 could have a raw data output 120 in the form of:

[00:541.3] [01 :605.0] [02:550.0]... [n:543.2]

[0026] The raw data output 120 is transmitted via the transceiver 1 15 into the processing system 130. In various embodiments, the transceiver 1 15 is a wireless Bluetooth transceiver or a wired USB port.

[0027] In an embodiment, the processing system 130 includes at least one processing component 140, at least one storage component 150, at least one user interface 160, and at least one simulation output 170. [0028] The processing component 140 performs multiple processing procedures, described further below, on the raw data output 120 to generate output volume value 171 and select a simulation file 151 for playback. In an embodiment, the processing component 140 may be a processor or a combination of a processing system and a storage system with a software component and optional storage.

[0029] The storage component 150 stores at least one simulation file 151 for retrieval by the processing component 140. Each simulation file 151 is a recorded or artificially generated audio file of a physiological reading made at a single monitoring point 1 12 for a particular condition in a particular species. In certain embodiments, the storage component 150 stores additional simulation files 151 , allowing simulation of multiple medical conditions and/or physiologies using the same physiological model 1 11.

[0030] Optionally, raw data outputs 120, sensor identifiers 121 , sensor input values 122, sensor floor values 141 , sensor minimum values 142, sensor maximum values 143, parameter templates 152, raw data output sets 153, assignment values 161 , volume values 162, error messages 163, shutdown values 164, and/or output volume values 171 may be stored in the storage component 150 for later use.

[0031] The simulation system 100 also includes the user interface 160 for displaying and/or receiving sensor inputs 118, transceiver ID values 119, raw data outputs 120, sensor identifiers 121 , sensor input values 122, sensor floor values 141 , sensor minimum values 142, sensor maximum values 143, simulation files 151 , parameter templates 152, raw data output sets 153, assignment values 161 , volume values 162, error messages 163, shutdown values 164, and output volume values 171. The user interface 160 allows users to interact with and modify the processes of the simulation system 100.

[0032] The simulation output 170 is operably connected to the processing component 140 to permit the playing of simulation files 151 as selected by processing component 140 as discussed below. Playback volume for simulation files 151 is controlled by proximity of the sensor trigger 117 of the medical device model 116 as discussed below. The simulation output 170 may be any device capable of playing a sound, such as, but not limited to, a speaker, earbud, or set of headphones.

[0033] In using the simulation system 100, a user begins by connecting the physiological model 1 11 to the processing system 130, then using the user interface 160 to assign desired simulation files 151 to monitoring points 112, set global sensor values such as sensor floor value 141 , sensor minimum value 142, sensor maximum value 143, and volume value 162, and select the transceiver 1 15 being used by the physiological model 1 1 1. The user may optionally save a parameter template 152 which will contain all of these settings, or load a previously saved template 152 to avoid having to enter these settings individually.

[0034] Once this setup is complete, the processing component 140 starts a loop which repeatedly evaluates the raw data output 120 received from the transceiver 1 15. The raw data output 120 includes the sensor identifier 121 as well as the sensor input value 122 generated by the interaction between the monitoring sensors 1 13 and the sensor trigger 1 17 in the monitoring device model 1 16. Once enough data has been received such that the processing component 140 has a value for each of the monitoring sensors 113, it can store those values as a raw data output set 153 in the storage component 150 for analysis.

[0035] Each time a new raw data output set 153 is stored, the processing component 140 normalizes the provided values to a given scale, using the global sensor values set in the user interface 160. The processing component 140 examines each normalized sensor value 144, finding the largest value. The other sensor values 144 are all then set to 0.0. The result of this is a single normalized sensor value 144 out of the original set, continuously updated with the sensor values provided by the monitoring sensors 1 13 in the physiological model 1 11.

[0036] Once the processing component 140 is receiving and processing sensor input values 122 as described above, the processing component 140 runs an additional function dependent on each completed round of sensor analysis. This function plays the simulation file 151 assigned to any sensor 113 that has a non-zero normalized sensor value 144 on a loop, with the output volume value 171 for the simulation output 170 corresponding to that normalized sensor value 144. This is updated for each completed round of sensor analysis, resulting in a simulation file 151 being played at a dynamically updating volume level as the user moves the sensor trigger 117 relative to the sensor 1 13. The processing component 140 can also switch to playing a different simulation file 151 as different sensors 1 13 report the strongest normalized sensor value 144.

[0037] The system 100 will continue to play the simulation file 151 until the user ends the program loop. Once the loop has been stopped, the user can change settings as desired, or load a new parameter template 152, as desired, and potentially start the loop again with a different basis for the simulation, such as a simulation of a healthy patient instead of an injured one.

Method

[0038] Figs. 2a through 2c depict a flowchart of an example of a method 200 for simulating a medical examination using a simulation system 100 according to certain embodiments, where the simulation system 100 includes a model system 1 10 and a processing system 130. Blocks 202 through 212 comprise an initial setup of the processing system 130. Blocks 214 through 234 comprise use of the simulation system 100 to simulate the medical examination. The numbering and sequencing of the blocks are for reference only; blocks or sequences of blocks may be performed out of order or repeated.

[0039] In block 202, the processing system 130 receives at least one assignment value 161 linking at least one simulation file 151 stored in storage component 150 to at least one monitoring sensor 113 located at at least one monitoring point 112 on at least one physiological model 111. This block connects a specific simulation file 151 to a specific monitoring point 1 12 to ensure that a user will hear what they would have heard at that particular location on an actual patient. In certain embodiments, the individual assignment values 161 are received from a user via a user interface 160. In certain embodiments, the assignment values 161 are part of a parameter template 152 selected by the user via the user interface 160 and retrieved from the storage component 150.

[0040] In block 204, the processing system 130 receives at least one volume value 162 for at least one simulation file 151. This block sets a maximum value for playback of a simulation file 151 , the maximum volume that would be heard at that particular location on an actual patient. The volume value 162 is a maximum volume for playing the simulation file 151 . In certain embodiments, the individual volume values 162 are received from the user via the user interface 160. In certain embodiments, the volume values 162 are part of a parameter template 152 selected by the user via the user interface 160 and retrieved from the storage component 150.

[0041 ] In block 206, the processing system 130 receives at least one sensor floor value 141 , at least one sensor minimum value 142, and at least one sensor maximum value 143 for at least one monitoring sensor 113. This block sets thresholds for sensitivity of the sensors 1 13, which are later used to create normalized sensor values 144 from raw data output 120. In certain embodiments, the sensor floor value 141 , sensor minimum value 142, and sensor maximum value 143 are received from the user via the user interface 160. In certain embodiments, the sensor floor value 141 , sensor minimum value 142, and sensor maximum value 143 are part of a parameter template 152 selected by the user via the user interface 160 and retrieved from the storage component 150.

[0042] In block 208, the processing system 130 receives at least one transceiver ID value 119 for at least one transceiver 1 15 in the physiological model 11 1. This block ensures that the physiological model 111 is connected for use. In certain embodiments, the transceiver ID value 119 is received from the user via the user interface 160. In certain embodiments, the transceiver ID value 119 is discovered via the processing system 130 pinging each physiological model 11 1 in the simulation system 100.

[0043] In optional block 210, the processing system 130 outputs an error message 163 through the user interface 160. This block serves to notify a user that the physiological model 11 1 is not connected for use. In one embodiment, the error message 163 is an indication that no transceiver ID value 1 19 has been discovered or received by the processing system 130. In one embodiment, the error message 163 is an indication that a particular value has not been received.

[0044] In optional block 212, the processing system 130 stores a new parameter template 152 in the storage component 150. This block allows a user to create a template 152 for quick use, so that they do not have to manually input all previously discussed values every time the system 100 is used in a simulation. The new parameter template 152 may include at least one previously entered value for sensor floor value 141 , sensor minimum value 142, sensor maximum value 143, assignment values 161 , or volume value 162.

[0045] In block 214, a secondary user places at least one medical device model 1 16 including a sensor trigger 117 in proximity to the physiological model 111. This interaction between the sensor trigger 117 and the sensor 113 will, in the subsequent block, cause the sensor 113 to output a value for a sensor input value 122 within a specified range of numbers corresponding to the strength of interaction between the sensor trigger 1 17 and the sensor 113. Closer interaction will lead to higher numbers, while more distant interactions will lead to lower numbers.

[0046] In block 216, the processing system 130 receives at least one raw data output 120 from at least one monitoring sensor 1 13. This block transmits the raw sensor input value(s) 122 generated in the previous block for processing.

[0047] In optional block 218, the processing system 130 repeats block 216 until at least one raw data output 120 has been received from each monitoring sensor 113 in model system 1 10. This is particularly necessary when a plurality of monitoring sensors 1 13 are used in the model system 1 10.

[0048] In block 220, the processing system 130 stores each received raw data output 120 from block 216 in the storage component 150 as a raw data output set 153.

[0049] In blocks 222 through 224, the processing system 130 normalizes the n sensor input values (S_n) 122 of the raw data output set 153, using the sensor floor value (St) 141 , sensor minimum value (Smin) 142, and sensor maximum value (Smax) 143. In various embodiments, the sensor input values 122 are normalized to a scale extending from 0.0 to the volume value 162. In one embodiment, the sensor input values 122 are normalized to a 0.0 to 10.0 scale.

[0050] In block 222, the processing system 130 sets the normalized sensor value 144 to 0.0 if the sensor input value 122 is less than the sensor floor value 141 . This block ensures that if a sensor 113 is too distal from the sensor trigger 1 17, it will not be considered.

[0051 ] In block 224, the processing system 130 calculates the normalized sensor value (N_n) 144 if the sensor input value 122 is greater than the sensor floor value 141. In one embodiment, the normalization equation is: where N_n is set to 0.0 if less than 0.0 and to 1 .0 if larger than 1 .0. This block both normalizes the sensor input value 122, no matter what type of sensor 1 13 is used, and ensures that an output volume value 171 cannot exceed the volume value 162.

[0052] In block 226, the processing system 130 selects the largest normalized sensor value 144 and sets all other normalized sensor values 144 to 0.0. This block ensures that only the normalized sensor value 144 for most proximal sensor 113 to the sensor trigger 117 is used.

[0053] In block 228, the processing system 130 calculates an output volume value 171 at the largest normalized sensor value 144 multiplied by the volume value 162. This block ensures that the output volume value 171 is inversely proportional to the distance between the sensor 113 and the sensor trigger 117. The closer the sensor trigger 1 17, the higher the volume the simulation file 151 will play at. The highest volume will play when the sensor trigger 117 is directly over the sensor 1 13.

[0054] In block 230, the processing system 130 plays the simulation file 151 associated with the monitoring point 1 12 having the largest normalized sensor value 144. The simulation file 151 is played through the simulation output 170.

[0055] In optional block 232, the secondary user moves the at least one medical device model 116 and sensor trigger 1 17 relative to the physiological model 111. This block and the block subsequent allow for simulation using multiple monitoring points 112 and/or changing distances between the sensor 113 and the sensor trigger 1 17. This may result in a change in at least one raw data output 120 from at least one monitoring sensor 1 13.

[0056] In optional block 234, the processing system 130 returns to block 216 to receive at least one new raw data output 120 from at least one monitoring sensor 113.

[0057] In optional block 236, the processing system 130 returns to block 202 to restart the method 200 using at least one different simulation file 151. This block allows for simulation of numerous physiological conditions by repeating the simulation using different simulation files 151 as discussed above. [0058] In optional block 238, the processing system 130 receives at least one shutdown value 164 from the user interface 160. The shutdown value 164 may end method 200 or may end the play of simulation file 151 . Computer System

[0059] Fig. 3 depicts an example diagram of a computer system 300 that may include the kinds of software programs, data stores, hardware, and interfaces that can implement a processing system 130 as disclosed herein and according to certain embodiments. The computing system 300 may be used to implement embodiments of portions of the processing system 130 or in carrying out portions of embodiments of method 200. The computing system 300 may be part of or connected to an overarching simulation system 100, which may also include model system 110.

[0060] As shown, the computer system 300 includes, without limitation, a memory 302, a storage 304, a central processing unit (CPU) 306, and a network interface 308, each connected to a bus 316. The computing system 300 may also include an input/output (I/O) device interface 310 connecting I/O devices 312 (e.g., keyboard, display, and mouse devices) and/or a network interface 308 to the computing system 300. Further, the computing elements shown in computer system 300 may correspond to a physical computing system (e.g., a system in a data center), a virtual computing instance executing within a computing cloud, and/or several physical computing systems located in several physical locations connected through any combination of networks and/or computing clouds.

[0061] Computing system 300 is a specialized system specifically designed to perform the steps and actions necessary to execute method 200 and simulation system 100. While some of the component options for computing system 300 may include components prevalent in other computing systems, computing system 300 is a specialized computing system specifically capable of performing the steps and processes described herein.

[0062] The CPU 306 retrieves, loads, and executes programming instructions stored in memory 302. The bus 316 is used to transmit programming instructions and application data between the CPU 306, I/O interface 310, network interface 308, and memory 302. Note, the CPU 306 can comprise a microprocessor and other circuitry that retrieves and executes programming instructions from memory 302. CPU 306 can be implemented within a single processing element (which may include multiple processing cores) but can also be distributed across multiple processing elements (with or without multiple processing cores) or sub-systems that cooperate in existing program instructions. Examples of CPUs 306 include central processing units, application-specific processors, and logic devices, as well as any other type of processing device, a combination of processing devices, or variations thereof. While there are a number of processing devices available to compromise the CPU 306, the processing devices used for the CPU 306 are particular to this system and are specifically capable of performing the processing necessary to execute method 200 and simulation system 100.

[0063] The memory 302 can comprise any memory media readable by CPU 306 that is capable of storing programming instructions and able to meet the needs of the computing system 300 and execute the programming instructions required for method 200 and simulation system 100. Memory 302 is generally included to be representative of a random-access memory. In addition, memory 302 may include volatile and non- volatile, removable, and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions or program components. The memory 302 may be implemented as a single memory device but may also be implemented across multiple memory devices or sub-systems. The memory 302 can further include additional elements, such as a controller capable of communicating with the CPU 306.

[0064] Illustratively, the memory 302 includes multiple sets of programming instructions for performing the functions of the simulation system 100 and method 200, including, but not limited to, processing component 140 and storage component 150, which is discussed in greater detail herein. Illustratively, the memory 302 may also include a receiving component 328, an obtaining component 330, a transmitting component 332, a generating component 334, a building component 336, an applying component 340, and a comparing component 342. Although memory 302, as depicted in Fig. 3 includes eleven sets of programming instruction components in the present example, it should be understood that one or more components could perform single- or multi-component functions. It is also contemplated that these components of computing system 300 may be operating in a number of physical locations.

[0065] The storage 304 can comprise any storage media readable by CPU 306 and is capable of storing data that is able to meet the needs of computing system 300 and store the data required for method 200 and simulation system 100. The storage 304 may be a disk drive or flash storage device. The storage 304 may include volatile and non-volatile, removable, and non-removable media implemented in any method or technology for storage of information. Although shown as a single unit, the storage 304 may be a combination of fixed and/or removable storage devices, such as fixed disc drives, removable memory cards, optical storage, network-attached storage (NAS), or a storage area-network (SAN). The storage 304 can further include additional elements, such as a controller capable of communicating with the CPU 306.

[0066] Illustratively, the storage 304 may store data such as but not limited to sensor inputs 1 18, transceiver ID values 119, raw data outputs 120, sensor identifiers 121 , sensor input values 122, sensor floor values 141 , sensor minimum values 142, sensor maximum values 143, normalized sensor values 144, simulation files 151 , parameter templates 152, raw data output sets 153, assignment values 161 , volume values 162, error messages 163, shutdown values 164, and output volume values 171 , all of which are also discussed in greater detail herein.

[0067] Examples of memory and storage media include random access memory, read-only memory, magnetic discs, optical discs, flash memory, virtual memory, and nonvirtual memory, magnetic sets, magnetic tape, magnetic disc storage, or other magnetic storage devices, or any other medium which can be used to store the desired software components or information that may be accessed by an instruction execution system, as well as any combination or variation thereof, or any other type of storage medium. In some implementations, one or both of the memory and storage media can be a non- transitory memory and storage media. In some implementations, at least a portion of the memory and storage media may be transitory. Memory and storage media may be incorporated into computing system 300. While many types of memory and storage media may be incorporated into computing system 300, the memory and storage media used is capable of executing the storage requirements of method 200 and simulation system 100 as described herein.

[0068] The I/O interface 310 allows computing system 300 to interface with I/O devices 312. I/O devices 312 can include model system 110, one or more monitoring sensors 1 13 or transceivers 1 15, user interfaces 160, graphical user interfaces, desktops, a speaker, a mouse, a keyboard, a voice input device, a touch input device for receiving a gesture from a user, a motion input device for detecting non-touch gestures and other motions by a user, and other comparable I/O devices and associated processing elements capable of receiving input. The I/O devices 312 through the user interfaces 160 are also integrated into the system allowing users to access a telephone system, internet system, and a text communications system, among other systems. I/O devices 312 can also include devices such as a video display or graphical display and other comparable I/O devices and associated processing elements capable of providing output. Speakers, printers, haptic devices, or other types of output devices may also be included in the I/O device 312.

[0069] A user can communicate with computing system 300 through the I/O device 312 in order to view sensor inputs 118, transceiver ID values 119, raw data outputs 120, sensor identifiers 121 , sensor input values 122, sensor floor values 141 , sensor minimum values 142, sensor maximum values 143, normalized sensor values 144, simulation files 151 , parameter templates 152, raw data output sets 153, assignment values 161 , volume values 162, error messages 163, shutdown values 164, and output volume values 171 , or complete any number of other tasks the user may want to complete with computing system 300. I/O devices 312 can receive and output data such as but not limited to sensor inputs 1 18, transceiver ID values 1 19, raw data outputs 120, sensor identifiers 121 , sensor input values 122, sensor floor values 141 , sensor minimum values 142, sensor maximum values 143, normalized sensor values 144, simulation files 151 , parameter templates 152, raw data output sets 153, assignment values 161 , volume values 162, error messages 163, shutdown values 164, and output volume values 171.

[0070] As described in further detail herein, computing system 300 may receive and transmit data from and to the network interface 308. In embodiments, the network interface 308 operates to send and/or receive data, such as but not limited to, sensor inputs 1 18, transceiver ID values 119, raw data outputs 120, sensor identifiers 121 , sensor input values 122, sensor floor values 141 , sensor minimum values 142, sensor maximum values 143, normalized sensor values 144, simulation files 151 , parameter templates 152, raw data output sets 153, assignment values 161 , volume values 162, error messages 163, shutdown values 164, and output volume values 171 to/from other devices and/or systems to which computing system 300 is communicatively connected, and to receive and process interactions as described in greater detail above.

[0071] It should be understood that the various techniques described herein may be implemented in connection with hardware components or software components or, where appropriate, with a combination of both. Illustrative types of hardware components that can be used include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on- a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc. The methods and apparatus of the presently disclosed subject matter, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine- readable storage medium where, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the presently disclosed subject matter.

[0072] Although certain implementations may refer to utilizing aspects of the presently disclosed subject matter in the context of one or more stand-alone computer systems, the subject matter is not so limited but rather may be implemented in connection with any computing environment, such as a network or distributed computing environment. Still further, aspects of the presently disclosed subject matter may be implemented in or across a plurality of processing chips or devices, and storage may similarly be affected across a plurality of devices. Such devices might include personal computers, network servers, and handheld devices, for example.

[0073] Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

[0074] In the foregoing description, certain terms have been used for brevity, clearness, and understanding. No unnecessary limitations are to be inferred therefrom beyond the requirement of the prior art because such terms are used for descriptive purposes and are intended to be broadly construed. The different configurations, systems, and method steps described herein may be used alone or in combination with other configurations, systems, and method steps. It is to be expected that various equivalents, alternatives, and modifications are possible within the scope of the foregoing description.

Claims

CLAIMS What is claimed is:

1 . A method for simulating a medical examination, comprising: receiving in a processing system at least one assignment value linking at least one simulation file stored in at least one storage component to at least one monitoring sensor located at at least one monitoring point on at least one physiological model, wherein the physiological model is a physical model containing the at least one monitoring sensor; receiving in the processing system at least one volume value for at least one simulation file; receiving in the processing system at least one sensor floor value, at least one sensor minimum value, and at least one sensor maximum value for the at least one monitoring sensor; receiving in the processing system at least one transceiver ID value for at least one transceiver in the at least one physiological model; placing at least one medical device model having a sensor trigger in proximity to the physiological model; receiving in the processing system from the physiological model at least one raw data output from at least one monitoring sensor, the at least one raw data output comprising at least one sensor identifier and at least one sensor input value; storing the at least one raw data output in the at least one storage component; setting at least one normalized sensor value to 0.0 in the processing system if the at least one sensor input value is less than the at least one sensor floor value; calculating in the processing system the at least one normalized sensor value for each of the at least one sensor input values if the at least one sensor input value is greater than the at least one sensor floor value; selecting a largest normalized sensor value and setting all other normalized sensor values to 0.0 in the processing system; setting an output volume value at the largest normalized sensor value multiplied by the volume value in the processing system; and playing through the simulation output the simulation file associated with the monitoring point having the largest normalized sensor value at an output volume corresponding to the output volume value.

2. The method of claim 1 , wherein at least one of the at least one assignment value, at least one volume value, at least one sensor floor value, at least one sensor minimum value, at least one sensor maximum value, and the at least one transceiver ID value is received from the user via a user interface.

3. The method of claim 1 , wherein at least one of the at least one assignment value, at least one volume value, at least one sensor floor value, at least one sensor minimum value, at least one sensor maximum value, and the at least one transceiver ID value is part of a parameter template selected by the user via a user interface and retrieved from the storage component.

4. The method of claim 1 , wherein an equation for calculating the at least one normalized sensor value (Nn) is: where S_n is an nth sensor input value, St is the at least one sensor floor value, Smin is the at least one sensor minimum value, and Smax is the at least one sensor maximum value.

5. The method of claim 4, wherein the at least one normalized sensor value is set to 0.0 if less than 0.0 and to 1 .0 if larger than 1 .0.

6. The method of claim 1 , further comprising outputting at least one error message through the at least one user interface.

7. The method of claim 6, wherein the error message is an indication that a particular value has not been received.

8. The method of claim 1 , further comprising storing a new parameter template in the storage component.

9. The method of claim 8, wherein the new parameter template comprises at least one previously entered value for sensor floor value, sensor minimum value, sensor maximum value, assignment values, or volume value.

10. The method of claim 1 , further comprising receiving at least one raw data output from at least one monitoring sensor until at least one raw data output has been received from a plurality of monitoring sensors located on the at least one physiological model.

1 1 . The method of claim 1 , further comprising moving the at least one medical device model and the sensor trigger relative to the at least one physiological model.

12. The method of claim 1 , further comprising receiving at least one new raw data output from at least one monitoring sensor.

13. The method of claim 1 , further comprising repeating the method using at least one different simulation file.

14. The method of claim 1 , further comprising receiving at least one shutdown value from the at least one user interface.

15. A system for simulating a medical examination, comprising: at least one physiological model having at least one monitoring sensor located at at least one monitoring point on the at least one physiological model, wherein the physiological model is a physical model; at least one medical device model having a sensor trigger; a memory comprising computer readable instructions; a processor operably connected to the at least one physiological model, wherein the processor is configured to read the computer readable instructions that when executed causes the system to: receive in the processor at least one assignment value linking at least one simulation file stored in at least one storage component to at least one monitoring sensor located at at least one monitoring point on at least one physiological model; receive in the processor at least one volume value for at least one simulation file; receive in the processor at least one sensor floor value, at least one sensor minimum value, and at least one sensor maximum value for the at least one monitoring sensor; receive in the processor at least one transceiver ID value for at least one transceiver in the at least one physiological model; receive in the processor from the physiological model at least one raw data output from at least one monitoring sensor, the at least one raw data output comprising at least one sensor identifier and at least one sensor input value; store the at least one raw data output in the at least one storage component; set at least one normalized sensor value to 0.0 in the processor if the at least one sensor input value is less than the at least one sensor floor value; calculate in the processor the at least one normalized sensor value for each of the at least one sensor input values if the at least one sensor input value is greater than the at least one sensor floor value; select a largest normalized sensor value and setting all other normalized sensor values to 0.0 in the processor; set an output volume value at the largest normalized sensor value multiplied by the volume value in the processor; and play through a simulation output the simulation file associated with the monitoring point having the largest normalized sensor value at an output volume corresponding to the output volume value.

16. The system of claim 15, wherein the at least one physiological model is a representation of at least part of a human body or an animal body.

17. The system of claim 15, wherein the at least one physiological model is hollow, having at least one monitoring sensor mounted to an interior of the at least one physiological model.

18. The system of claim 15, wherein the at least one monitoring sensor is an analog proximity sensor.

19. The system of claim 15, wherein the sensor trigger is a magnet.

20. A non-transitory computer readable medium comprising computer readable code to simulate a medical examination on a system that when executed by a processor, causes the system to: receive in the processor at least one assignment value linking at least one simulation file stored in at least one storage component to at least one monitoring sensor located at at least one monitoring point on at least one physiological model; receive in the processor at least one volume value for at least one simulation file; receive in the processor at least one sensor floor value, at least one sensor minimum value, and at least one sensor maximum value for the at least one monitoring sensor; receive in the processor at least one transceiver ID value for at least one transceiver in the at least one physiological model; receive in the processor from the physiological model at least one raw data output from at least one monitoring sensor, the at least one raw data output comprising at least one sensor identifier and at least one sensor input value; store the at least one raw data output in the at least one storage component; set at least one normalized sensor value to 0.0 in the processor if the at least one sensor input value is less than the at least one sensor floor value; calculate in the processor the at least one normalized sensor value for each of the at least one sensor input values if the at least one sensor input value is greater than the at least one sensor floor value; select a largest normalized sensor value and setting all other normalized sensor values to 0.0 in the processor; set an output volume value at the largest normalized sensor value multiplied by the volume value in the processor; and play through a simulation output the simulation file associated with the monitoring point having the largest normalized sensor value at an output volume corresponding to the output volume value.