Self-describing protocol translation device

Abstract

An apparatus and system using the apparatus that enables non-native devices to become self-describing modules or communicate in the same protocol as the system protocol used to update data in a medical device and a system describing the medical device. In one embodiment, the translation apparatus described herein includes a processor that translates non-self-describing protocol (SDP) data into an SDP communication standard and connects to other components within a rack, medical device, multi-function medical device, or medical system.

Description

Technical Field

[0001] The subject matter of this disclosure generally relates to devices for updating data in medical monitoring or treatment systems. More specifically, this document describes a device that allows non-local devices or non-self-describing protocol devices to operate as advanced self-describing devices and connect to multifunctional medical devices. Background Technology

[0002] Conventional models for docking patient physiological sensors to medical devices employ software specifically designed to process data from particular sensors and report values ​​to medical devices (such as patient monitors) programmed to receive and display data from specific sensor types. However, these conventional models introduce limitations that need to be addressed. One issue is the difficulty in adding the ability to use new parameters without updating the software on the medical device, as the device must possess specific capabilities to process these new parameters. Additionally, since both the parameters and software in the medical device are updated together, they are also tested and released as a system. Furthermore, new versions of the software may be incompatible with previously released medical devices at the customer's location. Moreover, the medical device may not be able to process data from sensor device types other than those specifically programmed for it, or may use data / communication protocols different from those used by the particular sensor, thus limiting its ability to process or otherwise handle data from the sensor device (if any). Furthermore, the sensor device may not be a self-describing device. Again, this limits the medical device's ability to process or otherwise handle data from the sensor device (if any). Therefore, given the many different types of sensor devices and the many different types of data / communication protocols, a device that interfaces between sensor devices and medical devices to ensure that the medical devices can handle or otherwise process data from the sensor devices may be desirable. Summary of the Invention

[0003] It would be advantageous to provide a device (such as a cable, connector, interface, rack-mount device, etc.) to perform one or more tasks, such as transmitting, acquiring, describing, formatting, or transporting data or combinations thereof from one or more non-self-describing physiological patient parameter sensors or devices to multifunctional medical devices (such as patient monitors, medical devices, therapeutic devices, or other components in a medical monitoring system), and therefore without using a self-describing protocol (SDP) for data handling and communication. An SDP is a set of rules for transmitting and understanding a limited number of types of information using data structures, transmission formats, and defined codes, enabling the receiver of the information to use, report, or retransmit the information without prior characterization of the specific information to be received. It includes any established SDP and annexes to established protocols. Therefore, a device configured with an SDP (including handling, generating, and / or processing data in SDP format) may be referred to herein as an SDP device or a local device, and a non-describing device not configured with an SDP for handling, generating, and / or processing data in SDP format may be referred herein as a non-SDP (NSDP) device or a non-local device. Such a non-describing device may be, for example, a physiological patient parameter sensor, but is not limited thereto.

[0004] These non-SDP devices perform one or more tasks, such as transmitting, acquiring, describing, formatting, or transferring data, or combinations thereof, using communication protocols different from those used by the monitoring system's SDP. Therefore, it would be advantageous to provide a method for efficiently and easily representing data received from non-SDP devices as SDP using a structure that allows SDP devices (such as multifunctional medical devices) to process the data without prior information about the data or its source, wherein processing means analysis, storage, presentation, manipulation, transmission, or any combination thereof.

[0005] It would be further advantageous to provide a means for reporting processed or unprocessed data from a non-SDP device to an SDP device on a communication network, the SDP device not having prior information about the data or its source. Furthermore, it would be advantageous to provide a device, method, or system for describing the information it will transmit to the medical SDP device, rather than relying at least in part on pre-established information or data structures specific to the non-SDP device.

[0006] The devices, methods, and systems described herein provide at least one or more of the aforementioned advantages by allowing non-SDP devices to perform one or more tasks, such as transmitting, acquiring, describing, formatting, or transferring data to SDP devices or other system components via the same system protocol as that of self-describing devices that provide physiological information.

[0007] The embodiments described in this disclosure provide methods, apparatus, or both for implementing a self-describing module for performing one or more tasks, such as transmitting data from physiological parameter sensors in a medical monitoring system, acquiring data, describing data, formatting data, transmitting data, or (one or more) combinations thereof. In one aspect, the methods and apparatus described herein include devices capable of: communicating with a non-SDP device via logical, analytical, data formatting, or other means; transmitting a metadata block (MDB) from the self-describing module to the medical device using a communication interface, the MDB including at least identification (ID) data and corresponding configuration data; optionally storing the MDB as an instance of MDB data in the memory of the medical device; associating ID data from the MDB with ID data of multiple subsystems of the medical device; and updating configuration data of at least one subsystem of the medical device with configuration data from the MDB based on the association results between the ID data from the MDB and the ID data of the subsystems.

[0008] The embodiments described in this disclosure provide a non-transitory computer-readable recording medium in a self-describing module for updating data in a medical device. The non-transitory computer-readable recording medium stores one or more programs that, when executed by a processor or other component, perform the steps of the methods described herein. In one particular embodiment, the non-transitory computer-readable recording medium includes a conversion device that converts output from a non-SDP device, such as a patient sensing device having a first communication protocol, into a self-describing communication protocol.

[0009] In some embodiments, the system includes one or more non-local devices that include one or more physiological patient parameters or sensors. In these embodiments, the non-local device can communicate with at least one of a self-describing module, a multifunctional medical device, a system, or a combination thereof using a conversion device, such as, but not limited to, a converter cable, a converter adapter, a converter rack, or a converter bracket. The conversion device includes a processor that communicates with the non-local device using an appropriate protocol and then converts the non-SDP device data into a self-describing communication protocol (i.e., SDP format). The conversion device can be a cable or connector, such as, but not limited to, a conversion cable containing a conversion board, or alternatively, a conversion device such as a rack or device housing containing components that perform the conversion from the non-local device to the self-describing protocol, such as, but not limited to, a processor. Thus, the conversion device converts or otherwise converts data from a non-SDP format to SDP format, enabling the multifunctional medical device to use or process the data without prior characterization of specific receiving information. Attached Figure Description

[0010] In the accompanying drawings, the same reference numerals generally indicate the same, functionally similar and / or structurally similar elements.

[0011] Figure 1 This is a schematic diagram of a system using a self-describing module for updating data in a medical device, according to an embodiment of the present disclosure.

[0012] Figure 2 The illustrations depict systems and methods for using a self-describing module for updating data in a medical device, according to one or more embodiments.

[0013] Figure 3 The illustration depicts a method performed by a medical device according to one or more embodiments, using a self-describing module for updating data in the medical device, the method employing... Figure 1 and Figure 2 The system in the middle.

[0014] Figure 4 It is a schematic diagram of a self-describing module according to one or more embodiments.

[0015] Figure 5 This is a schematic diagram of a system according to one or more embodiments, the system including a self-describing module for providing parameter data from a patient to a medical device and further to one or more system components, such as a network of medical computing devices.

[0016] Figure 6 The illustration shows a schematic block diagram of a system according to one or more embodiments, wherein a self-describing protocol (SDP) conversion device (such as an SDP conversion cable) transmits data between non-SDP devices (such as non-local patient sensor devices) and SDP medical devices and other SDP system components.

[0017] Figure 7A This is a schematic block diagram illustrating communication between an SDP conversion device and a non-SDP patient sensor device according to one or more embodiments.

[0018] Figure 7B It is a schematic block diagram of a system according to one or more embodiments.

[0019] Figure 7C Depicting according to one or more embodiments Figure 7B Another schematic view of the system shown.

[0020] Figure 8 The illustration shows a system according to one or more embodiments, which includes an SDP conversion device in the form of a cable and inserted between a medical device and a non-SDP patient sensor device.

[0021] Figure 9A and Figure 9BBoth block diagrams and schematic diagrams illustrate a system according to one or more embodiments, the system including a conversion device in a mounting rack and communicating with a non-SDP patient sensor device.

[0022] Figure 9C An example of a medical device according to one or more embodiments is shown.

[0023] Figure 10 These are schematic diagrams of various embodiments of self-describing modules or local description SDPs with single-width and double-width, mounting racks for self-describing modules, and tethered modules that do not reside in the mounting rack but are connected to the rack via cables.

[0024] Figure 11A-11D Various types of SDP conversion devices according to one or more embodiments are illustrated. Figure 11 A provides an embodiment of a conversion device such as a conversion cable, Figure 11 B provides an embodiment of a self-describing module with a double width, Figure 11 C provides an embodiment of a self-describing module with a single width, and Figure 11 D provides an embodiment of a tethered module or compartment that does not reside in a mounting rack and is connected to the rack via cable.

[0025] Figure 12 An embodiment of a conversion device for measuring the end flow CO2 gas of inhaled and exhaled gases is provided.

[0026] Figure 13 Examples of conversion devices are provided, which include a conversion module integrated into a cable solution for blood oxygenation or SpO2 (e.g., a self-describing protocol (SDP) internal converter cable).

[0027] Figure 14 Examples of invasive blood pressure (IBP) hemodynamic devices are provided, which become self-describing devices when using an SDP conversion device according to one or more embodiments.

[0028] Figure 15 More detailed block diagrams are provided for embodiments of the SDP conversion device and the device for measuring certain physiological parameters.

[0029] Figure 16A , 16B Figure 16C illustrates various types of SDP converter cables according to one or more embodiments.

[0030] Figure 17 This is an illustrative embodiment of an SDP conversion device according to one or more embodiments, which includes an SDP conversion cable or an SDP processor board within an SDP compartment, the SDP conversion cable or SDP compartment further including conversion software within the SDP processor board.

[0031] Figure 18 This is an illustrative embodiment of an SDP conversion device, which includes an SDP conversion cable or an SDP processor board within an SDP compartment, the SDP conversion cable or SDP compartment further including conversion software on a third-party, OEM, or non-native processor board.

[0032] Figure 19 A schematic block diagram of an SDP conversion cable for SpO2 patient parameters is provided according to one or more embodiments.

[0033] Figure 20A and 20B Assembly and exploded views of an embodiment of an SDP conversion cable for a hemodynamic sensor device are provided.

[0034] Figure 21 This is a block diagram illustrating the functions performed by the software on the conversion device.

[0035] Figure 22-25 This is a schematic diagram of an SDP conversion processor board, which is used for non-isolated serial connection with OEM equipment, isolated serial connection with OEM equipment, isolated serial communication connection for a non-self-describing hemodynamic chamber, and hemodynamic measurement device with a serial port for isolated pressure and temperature measurement and for communication with independent devices that perform other measurement functions on the patient, and is referred to herein as board-1, board-2, board-3 and board-4.

[0036] Figure 26A and Figure 26B A schematic block diagram of an SDP conversion device for a hemodynamic sensor device is provided, which may be an SDP converter cable.

[0037] Figure 27 A schematic block diagram of an SDP conversion board for an SDP conversion device according to one or more embodiments is provided.

[0038] Figure 28 A schematic block diagram of an embodiment of an SDP conversion device for use with a non-SDP SpO2 device, according to one or more embodiments, is provided.

[0039] Figure 29A and 29B Embodiments of a female connector and a cable for an SDP conversion device including a cable are provided according to one or more embodiments.

[0040] Figure 30A and 30B Embodiments of male and female connectors for an SDP conversion device including a cable are provided according to one or more embodiments.

[0041] Figure 31 Detailed illustrations of exemplary module connectors and pin connections according to one or more embodiments are provided.

[0042] Figure 32 Exemplary flexible cable assemblies according to one or more embodiments are provided.

[0043] Figure 33 An SDP adapter cable according to one or more embodiments is provided, which can be used to allow modules to be connected to system components without a rack. Detailed Implementation

[0044] Figure 1 This is a schematic diagram of a system using a self-describing module for updating data in medical devices. For example... Figure 1 As shown, the system includes a self-describing module 1, a medical device 2, an optional monitoring device bracket 3, and one or more servers 4.

[0045] In one particular embodiment, the self-describing module 1, the medical device 2, the optional monitoring device bracket 3, and one or more servers 4 include electronic components or electronic computing devices operable to receive, transmit, process, store, and / or manage associated data and information within the system, encompassing any suitable processing device adapted to perform computing tasks consistent with the execution of computer-readable instructions stored in memory or a computer-readable recording medium.

[0046] Furthermore, any, all, or some of the computing devices in the self-describing module 1, medical device 2, optional monitoring device bracket 3, and one or more servers 4 may be adapted to run any operating system (including Linux, UNIX, Windows Server, etc.) and virtual machines adapted to virtualize the execution of a specific operating system (including custom and proprietary operating systems). The self-describing module 1, medical device 2, optional monitoring device bracket 3, and one or more servers 4 are further equipped with components that facilitate communication with other computing devices via one or more connections 5, 6, 7, 8, 9, and 10. Connections 5, 6, 7, 8, 9, and 10 include connections to local area networks and wide area networks, wireless and wired networks, public and private networks, and any other communication networks that enable communication within the system. Additionally, this disclosure also contemplates that connections 5, 6, 7, 8, 9, and 10 may include, but are not limited to, Universal Serial Bus (USB) connections, Serial Peripheral Interface (SPI) connections, Ethernet connections, coaxial connections, wireless connections, High Definition Multimedia Interface (HDMI) connections, or other serial transmission connections, and any combinations thereof.

[0047] exist Figure 1In this configuration, the self-describing module 1, the medical device 2, the optional monitoring device bracket 3, and one or more servers 4 may include one or more programmable data processors and memory or memory locations for storing software components. In the self-describing module 1, the memory includes a metadata block (MDB). The one or more memories in the self-describing module 1 include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), read-only memory (ROM), logic blocks of a field-programmable gate array (FPGA), erasable programmable read-only memory (EPROM), and electrically erasable programmable ROM (EEPROM).

[0048] refer to Figure 2 The self-describing module 1 is a patient monitoring module or self-describing protocol (SDP) module, configured to acquire and process data generated by at least one physiological sensor configured to monitor the patient's physiological parameters. Process data generated by sensors such as, but not limited to, electrocardiogram (ECG) electrodes, oxygen saturation (SpO2) sensors, blood pressure cuffs, apnea detection sensors, and ventilators measures physiological parameters such as blood pressure, cardiac-related information, pulse oximetry, and respiratory information.

[0049] As noted above, an SDP is a set of rules for transmitting and understanding a limited number of types of information using data structures, transport formats, and defined codes, enabling information receivers to use, report, or retransmit information without prior representation of the specific information being received. It includes any established SDP along with an appendix to the established protocol.

[0050] Such as Figure 2 The MDB shown is illustrated, and its transmission is represented in step S1. The MDB includes settings required by the physiological algorithms of the self-describing module 1. These include patient categories such as neonates, pediatricians, or adults. The MDB includes, for example, self-describing module settings required by the physiological algorithms of the self-describing module 1, such as user-changeable filter settings. User-changeable filter settings may include values ​​related to alert settings and other clinical care protocol limitations. User-changeable filter settings are patient-configurable and may vary from user to user (e.g., clinician to clinician) and / or from patient to patient. Having these values ​​in the self-describing module 1 allows updates to occur through the self-describing module 1, such as software version revisions, updates, fixes, batch updates, etc.

[0051] To add new functionality or for customization, the self-describing module 1 offers flexibility in several ways. Users can adopt the latest algorithms, features, and software updates from the parametric measurement device without waiting for a new version release from medical device 2. For example... Figure 2As shown in S5, users can configure the number and type of parameter measurement devices to meet different and changing clinical needs. The service approach can be more uniform than currently offered, with remote access to the versions, logs, self-tests, settings, history, and measurements of all parameter measurement devices via the Internet or other means.

[0052] The MDB may include data or information for delivering the self-describing configuration of the self-describing module 1 to a client such as a medical device 2. The MDB may inform the medical device 2 about what data is generated and additional properties of the various subsystems and display elements within the medical device 2. The MDB may include multiple plug-ins, which are software interfaces that allow data communication between the respective subsystems. Each plug-in can interface with the medical device 2. Each plug-in can be implemented for each client's data from the self-describing module 1. Additionally, the MDB may include information about how to use the data generated by the self-describing module 1, how to format the data, how often to update the data, how the data should be displayed, and how the data should be labeled.

[0053] The MDB can include device identification (ID) data, such as data type, update rate, alarm limits, settings, and other characteristics. For example, reports of physiological measurements and settings including waveforms can be included in the MDB as metrics. Additionally, the MDB supports at least one or more of the following: alarms; remote control of the self-describing module 1; retrieval of service-related data including device metadata, logs, and software updates; and localized text strings with a localized database. The localized text strings include metrics, alarms, and remote control elements supported by the self-describing module 1.

[0054] The MDB may also include a subset of data described in medical device communication standards, which describes and transmits the state of the self-describing module 1. Naming and encoding systems from standards such as IEEE 11073-10207 (Domain Information and Service Model Standard for Service-Oriented Point-of-Care Medical Device Communication) and 11073-101 (Health Informatics – Point-of-Care Medical Device Communication – Part 10101: Naming) can provide the status of the self-describing module 1. The MDB may include a Medical Data Information Base (MDIB), which is a collection of data objects provided by a specific medical device, including descriptive and status information.

[0055] In some embodiments, the medical device 2 may be a medical monitoring device for monitoring various physiological parameters of a patient. A medical monitoring device represents a type of multifunctional medical device that uses SDP to receive and transmit data and is configured to dispose of or otherwise process data in SDP format. The medical monitoring device 2 may be portable and travel with the patient to provide continuous monitoring during care. The medical monitoring device 2 is connected via wired and / or wireless interfaces to one or more sensors, such as ECG electrodes, SpO2 sensors, blood pressure cuffs, apnea detection sensors, ventilators, etc., which measure physiological parameters associated with the patient, such as blood pressure, cardiac-related information, pulse oximetry, respiratory information, etc. Additional types of information may be transmitted through the medical monitoring device 2. The medical monitoring device 2 may process and / or display analog data derived from the patient.

[0056] Medical device 2 includes multiple subsystems. As an example, three distinct subsystems are shown: subsystem 2a, subsystem 2b, and subsystem 2c, each associated with a unique ID stored at medical device 2. The multiple subsystems may include subsystems for at least one graphical user interface (GUI), subsystems for trends, alerts, reports, networking, etc. In this or another embodiment, medical device 2 may include at least one metadata plugin interface (MPI). Each of the multiple subsystems 2a-2c may include one of the MPIs, and each MPI may have a version associated with it. The MPI interacts with an MDB such that plugins of the MDB can be associated with the MPI of the subsystem. Each MPI can be updated with a new interface while keeping existing interfaces unchanged. The MDB of self-describing module 1 may include multiple plugins connected to the MPIs. Medical device 2 may connect to at least one patient sensor, such as an ECG electrode, SpO2 sensor, blood pressure cuff, apnea detection sensor, ventilator, etc., which provides patient data to medical device 2.

[0057] The MDB can provide customers or users of medical device 2 with information about what data is being provided and the nature of various subsystems, as well as enabling the display of components within medical device 2. The MDB includes ID data and corresponding configuration data for various subsystems in medical device 2.

[0058] The monitoring device bracket 3 may be an optional component. The monitoring device bracket 3 can provide physical support, power supply, and conduit to one or more computer networks. In some embodiments, the monitoring device bracket 3 can be connected when the medical device 2 is not used for patient transport. This disclosure contemplates that, in some embodiments, the medical device 2 can be connected (e.g., connection 6) to the monitoring device bracket 3. In these embodiments, the self-describing module 1 is connected to the monitoring device bracket 3, and communication from the self-describing module 1 to the medical device 2 is established through the monitoring device bracket 3 (e.g., connection 10).

[0059] Figure 2 The illustration shows a system 200 and method according to one or more embodiments for using a self-describing module 1 to update data in a medical device 2. (In conjunction with...) Figure 3 Describe the method, Figure 3 Additional steps of the method are illustrated. In step S1, the self-describing module 1 transmits the MDB to the medical device 2. The information provided in the MDB includes descriptions of the metrics supported by the self-describing module 1. (Reference) Figure 3 Steps S2-S4 describe the process performed by medical device 2 after receiving the MDB. In step S2, medical device 2 stores the MDB data as an instance of MDB data in its memory. Then, in step S3, the instance of MDB data is used to associate ID data from the MDB with ID data of multiple subsystems 2a-2c of medical device 2. When medical device 2 does not know the ID data, it can ignore the ID data. In other words, when the ID from the MDB does not match the ID of one of subsystems 2a-2c, medical device 2 can ignore the ID data associated with that ID from the MDB. In step S4, based on the association result between the two ID data (i.e., the ID data from the MDB matches the ID data of one of subsystems 2a-2c), the configuration data of at least one of the multiple subsystems 2a-2c is updated using the configuration data in the MDB instance. In other words, the configuration data associated with the ID of the MDB that matches the ID of the corresponding subsystem 2a-2c is used to configure, reconfigure, or otherwise update the configuration data of the corresponding subsystem 2a-2c. During runtime, the state of the metric changes in the MDB and is received by medical device 2. In some embodiments, step S2 is not performed, and instead of storing the MDB data as an instance in the memory of medical device 2, medical device 2 transmits the information from the MDB over the network via one or more of connections 5, 6, 7, 8, 9, and 10. Then, in the following step S3, the MDB data is used to associate the ID data from the MDB with the ID data of multiple subsystems.

[0060] In some situations, users may want to adjust the data provided by the MDB and self-describing module 1. An example of changes made by the user would be adjusting alarm limits for a specific intensive care unit. Medical device 2 includes a user interface to facilitate communication between medical device 2 and the user. The user interface allows the user to input changes to the data. Back Figure 2 As shown in step S5, the user can use the user interface to transmit updated subsystem data modifications made in the medical device 2 to the self-describing module 1. Referring to the physiological sensors monitoring the patient, the updated subsystem modifications can, for example, be transmitted from the medical device 2 to the self-describing module 1.

[0061] Further description of the self-describing module and its communication with medical device 2 and / or other components of the system described herein is provided in pending PCT application publication number WO 2019 / 193211 entitled Self-Describing Device, which is incorporated herein by reference in its entirety.

[0062] Communication between the self-describing module 1 and the medical device 2 can occur in several ways. It can begin with a physical connection (e.g., Figure 1 Connection 7) shown establishes communication between the self-describing module 1 and the medical device 2. Examples of the connection include a USB port, SPI port, Ethernet port, or other similar connections. Once connected, the medical device 2 can then detect the self-describing module 1. In some embodiments, the self-describing module 1 may have a driver associated with it, which serves as a low-level communication interface. This driver enables the medical device 2 to detect the self-describing module 1.

[0063] Figure 4 This is a schematic diagram of an example self-describing module 1 according to one or more embodiments. This disclosure contemplates that the self-describing module 1 includes electronic components or electronic computing devices operable to receive, transmit, process, store, and / or manage data and information associated with the previously described systems and methods, encompassing any suitable processing device adapted to perform computational tasks consistent with the execution of computer-readable instructions stored in memory or a computer-readable recording medium.

[0064] refer to Figure 4Example self-describing module 1 includes one or more memories or memory locations, including main memory 30, as well as I / O interface 32, user interface 33, communication interface 34, one or more processors 35, and optional power supply 31. Main memory 30 may be random access memory (RAM), memory buffer, hard disk drive, database, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), read-only memory (ROM), flash memory, hard disk, or any other memory hierarchy of various types.

[0065] The main memory 30 can be used to store any type of instructions associated with algorithms, processes, or operations for controlling the general functions of the self-describing module 1, including the MDB and the operation of any operating system, such as Linux, UNIX, Windows Server, or other custom and proprietary operating systems.

[0066] Optional power supply 31 can be used to power various components of the self-describing module 1. Power supply 31 can be standalone (such as a battery pack), and / or power supply 31 can include an interface for powering via an electrical outlet (directly or via the medical device 2 and / or monitoring device holder 3). In some embodiments, the self-describing module 1 can only be powered and present information when it is fixed or otherwise connected to one or more of the medical device 2 and monitoring device holder 3.

[0067] I / O interface 32 can be an interface for communicating information between self-describing module 1 and external devices (such as medical device 2 or optional monitoring device bracket 3), which require special communication links to interface with one or more processors 35. I / O interface 32 can be implemented to accommodate various connections to self-describing module 1, including but not limited to USB connections, SPI connections, Ethernet connections, coaxial connections, wireless connections, HDMI connections or other serial transmission connections or other known connections in the art for connecting to external devices.

[0068] User interface 33 is implemented to allow communication between the user and self-describing module 1. User interface 33 includes, but is not limited to, liquid crystal displays (LCDs), cathode ray tubes (CRTs), thin-film transistors (TFTs), light-emitting diodes (LEDs), high-definition (HD) displays, or other similar display devices with touchscreen capabilities. Other types of input devices may also be used to provide interaction with the user. For example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback via a speaker, or tactile feedback), and input from the user can be received in any form, including auditory, voice, or tactile input. Input devices and microphones can be coupled to and transmit information via internal bus 36 through an input device interface. Speakers can be coupled to and receive information via internal bus 36 through a speaker interface. Self-describing module 1 may omit one or more of the display, display interface, input device, microphone, speaker, input device interface, and speaker interface. Communication interface 34 is a software and / or hardware interface implemented to... Figure 1 The system described herein establishes a connection between the self-describing module 1 and the server 4. This disclosure envisions that the communication interface 34 includes software and / or hardware interface circuitry for establishing communication connections with the rest of the system using both wired and wireless connections, for establishing connections to, for example, local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), personal area networks (PANs), wireless local area networks (WLANs), system area networks (SANs), and combinations thereof.

[0069] One or more processors 35 are used to control the general operation of the self-describing module 1. Each of the one or more processors 35 may be, but is not limited to, a central processing unit (CPU), a hardware microprocessor, a multi-core processor, a single-core processor, a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a digital signal processor (DSP), or other similar processing devices capable of executing any type of instructions, algorithms, or software for controlling the operation of the self-describing module 1. Communication between the components of the self-describing module 1 (e.g., components 30-35) is established using an internal bus 36.

[0070] Figure 5This is a schematic diagram of an example medical system 500 according to one or more embodiments. This disclosure contemplates that the medical device 2 includes electronic components or electronic computing devices operable to receive, transmit, process, store, and / or manage data and information associated with the aforementioned systems and methods, encompassing any suitable processing device suitable for performing computational tasks consistent with the execution of computer-readable instructions stored in memory or a computer-readable recording medium. The medical device 2 is in electrical communication with a self-describing module 1 via connection 105, and the self-describing module 1 is in electrical communication with a patient 11 via connection 106. The medical device 2 is in electrical communication with a network of medical computing devices, shown as 104, via connection 107.

[0071] exist Figure 5 In this disclosure, the self-describing module 1, medical device 2, medical computing device network 104, and patient 11 include components that facilitate communication with other computing devices via one or more connections 105, 106, and 107 (e.g., electrical communication). Connections 105, 106, and 107 include connections to local area networks and wide area networks, wireless and wired networks, public and private networks, and any other communication networks that enable communication within the system. Additionally, this disclosure also contemplates that connections 105, 106, and 107 may include, but are not limited to, USB connections, SPI connections, Ethernet connections, coaxial connections, wireless connections, HDMI connections, or other serial transmission connections, and any combinations thereof.

[0072] Figure 6 This is a schematic block diagram of a medical system 600 according to one or more embodiments. System 600 includes non-SDP (NSDP) devices (i.e., non-local devices), such as a non-SDP (NSDP) patient sensor device 100, which uses a different communication protocol (e.g., a non-SDP communication protocol or NSDPCOM) or a different system protocol than medical device 2 and medical computing device network 104. In other words, medical device 2 and medical computing device network 104 are configured to handle or otherwise process data according to the SDP communication protocol (SDPCOM), while the non-SDP patient sensor device 100 is not configured to handle or otherwise process data according to the SDP communication protocol. Due to the mismatch in data protocols, medical device 2, as an SDP processing device, cannot process non-SDP (NSDP) data, or may only be able to process a portion of the non-SDP data.

[0073] System 600 further includes an SDP conversion device 109 (i.e., an SDP converter) communicatively coupled between the medical device 2 (i.e., the SDP device) and the non-SDP patient sensor device 100. Therefore, the SDP conversion device 109 acts as an interface between the non-SDP device and the SDP device, allowing the SDP device to use data generated by the non-SDP device, as well as other data (e.g., supplemental data, augmentation data, etc.) generated by the SDP conversion device 109, without prior characterization of specific receiving information. The data generated by the non-SDP device may include sensor data generated by one or more sensors connected to the patient 11, which measure one or more physiological parameters of the patient 11.

[0074] Medical device 2 and medical computing device network 104 can communicate using SDP, and thus can form an SDP communication network. SDP is a system protocol used by medical computing device network 104, medical device 2, and local patient sensor devices (such as self-describing module 1).

[0075] As previously explained, non-SDP devices (i.e., non-local devices), such as non-SDP patient sensor device 100, are devices that do not use SDP to format their data or conduct data communication. Instead, non-SDP devices use protocols different from SDP for their data formatting and data communication. These non-SDP devices perform one or more tasks, such as transmitting, acquiring, describing, formatting, or transferring data, or combinations thereof, using protocols different from SDP (i.e., the SDP system protocol). As a result, devices that use SDP for their data formatting and communication (such as medical device 2) cannot properly receive, process, and / or display data received from non-SDP devices.

[0076] SDP conversion device 109 includes at least one processor configured to convert or otherwise convert non-SDP data received from non-SDP patient sensor device 100 into SDP format, and to transmit SDP-formatted data to medical device 2 according to the SDP communication protocol. Medical device 2 is merely one example of a multifunctional medical device for receiving sensor data from non-SDP patient sensor device 100.

[0077] Since the non-SDP patient sensor device 100 does not use SDP (i.e., SDPCOM) to communicate with at least one of the medical device 2 or the medical computing device network 104, a conversion device (such as SDP conversion device 109) is used to convert data from the non-local patient sensor device 100, which is formatted in the non-SDP communication protocol (NSDPCOM), into the data format in the SDP communication protocol (SDPCOM).

[0078] For reference Figure 5Similarly described, medical device 2 includes electronic components or electronic computing devices operable to receive, transmit, process, store, and / or manage data and information associated with the aforementioned systems and methods, encompassing any suitable processing device suitable for performing computational tasks consistent with the execution of computer-readable instructions stored in memory or a computer-readable recording medium. Medical device 2, SDP conversion device 109, non-local patient sensor device 100, medical computing device network 104, and patient 11 include one or more connections 105, 106, 107, 108, and 111 to facilitate communication between one or more network or system components.

[0079] Self-describing module 1 uses SDP to communicate with medical device 2 and other devices and components within the system (e.g., medical computing device network 104). However, in some embodiments, the system described herein includes one or more non-SDP physiological patient parameter sensors or devices that do not express the same SDP communication protocol as self-describing module 1, medical device 2, medical computing device network 104, or all the aforementioned devices within the system disclosed herein.

[0080] In these embodiments, SDP conversion device 109—such as, but not limited to, SDP conversion cables or modules—allows healthcare providers to communicate with medical device 2 or other components within the system (e.g., one or more of medical computing devices or medical computing device networks 104) using non-SDP, non-local, or OEM devices within the system. In these embodiments, converter cables, converter connectors, converter interfaces, converter modules, converter processors, converter microcontrollers, etc.—each referred to herein as a conversion device—are used between the non-SDP devices and the input node 113 of the SDP system to allow non-SDP devices in the system to perform similarly and communicate via the same protocol or SDP as the self-describing module(s). In this example, the input node 113 of the SDP system is located at the input of medical device 2, but is not limited thereto. The input node 113 is located at the initial point of contact with the SDP communication network. It is the entry point of the SDP communication network, enabling all SDP devices to use SDP-formatted data that has been converted, transformed, or otherwise reformatted by the SDP conversion device 109.

[0081] In some embodiments, software operating on a processor within the SDP conversion device 109 performs one or more of the following functions: converting data from the non-SDP patient sensor device 100 into a form that can be placed in the MDB; calibration procedures; logic for alarm conditions (e.g., alarm status identification); user interaction (UI), such as settings menus and alarm limits; data analysis algorithms; and / or selecting strings from an index, with details referring to... Figure 6 and7A -7C is used for description.

[0082] In these or other embodiments, depending on the design of the sensing device connected to the patient, the SDP conversion device 109 may further include electrical isolation features.

[0083] SDP conversion device 109 is configured to allow healthcare providers with non-SDP communication devices to connect them to SDP communication medical devices, systems, or networks. In one embodiment, SDP conversion device 109 allows older versions of products described in a non-SDP communication protocol (e.g., sensor devices for physiological parameter detection) to communicate with newer versions of medical devices (e.g., patient monitoring devices and treatment devices), systems, or networks described in an SDP communication protocol. In another embodiment, SDP conversion device 109 allows OEM devices described in a non-SDP communication protocol (NSDPCOM) to communicate with medical devices, systems, or networks described in an SDP communication protocol (SDPCOM). This allows users to easily adapt existing products (e.g., sensor devices) or products from other manufacturers that describe non-SDP communication protocols while the medical devices describe SDP communication protocols.

[0084] Figure 7A A schematic block diagram is provided of a non-SDP patient sensor device 100 that communicates electrically with an SDP conversion device 109 via a wired or wireless connection 108 according to one or more embodiments. The non-SDP patient sensor device 100 includes sensing electronics 127 that support the measurement of physiological parameters of a patient, and communication components or dedicated communication components 124 (e.g., communication circuitry such as a transmitter or transceiver) that express or provide communication output in a communication protocol different from that of the system or SDP.

[0085] SDP conversion device 109 includes a processor 126 and a dedicated communication component 123 (e.g., communication circuitry such as a receiver or transceiver) to enable communication with a non-local patient sensor device 100 via its dedicated communication component 124 or other components (not shown). SDP conversion device 109 further includes a memory 125 storing an SDP library accessed and read by the processor 126. In some cases, memory 125 may be embedded within the processor 126.

[0086] The SDP library contains a directory of non-SDP (NSDP) protocols that can be converted to SDP communication protocols (e.g., non-SDP communication protocols). In other words, the NSDP directory includes mappings of one or more different communication protocols to SDP. Using the NSDP directory, processor 126 can identify the non-SDP communication protocol used by the non-SDP patient sensor device 100 and extract the mapping information. Processor 126 then uses the mapping information extracted from the SDP library to convert the received non-SDP data into SDP format for transmission to input node 113. In other words, SDP conversion device 109 is configured to identify the non-SDP sensor data as non-SDP, select an NSDP to SDP conversion algorithm from a directory or set of NSDP to SDP conversion algorithms provided by the SDP library based on the identified NSDPCOM, and convert the non-SDP sensor data into SDP sensor data using the selected NSDP to SDP conversion algorithm. Figure 17 and 21 The conversion software illustrated in the image is used to perform conversions in conjunction with the SDP library. Figure 7A In one particular embodiment, dedicated communication components 123 and 124 in the SDP conversion device 109 and the off-site patient sensor device 100 include electronic subsystems, such as, but not limited to, microprocessors or field-programmable gate arrays (FPGAs). Dedicated communication components 123 and 124 may be the same electronic subsystem or different electronic subsystems. Dedicated communication component 123 exchanges information with the electronic processor 126 in the SDP conversion device 109.

[0087] Electronic processor 126 is a device (such as a microprocessor) capable of executing instructions to implement conversion functions using the SDP library. Dedicated communication components 123 and 124 electronically exchange information using connection 108, which may be a bidirectional serial link NSDPCOM. Dedicated communication component 124 receives information about physiological measurements (e.g., physiological sensor data) from sensing electronics 127 in the non-local patient sensor device 100 via various methods (such as, but not limited to, digitizing analog signals or sensing digital signals or similar methods). Dedicated communication component 124 is capable of controlling the operation of sensing electronics 127 using digital or electronic signals.

[0088] Examples of parameters that can be measured on a patient using off-site or OEM devices, converted to SDP using the SDP conversion device described herein, and analyzed and displayed on the medical devices and systems described herein in a random or continuous measurement manner include the following: arterial hemoglobin oxygen saturation (SpO2) (e.g., measuring the fractional oxygen saturation from the absorption of different wavelengths of light as it passes through a finger), perfusion index (PI), pulse rate, carboxyhemoglobin saturation (SpCO), methemoglobin (SpMet), total hemoglobin (SpHb), patient volume index (PVI), and total oxygen content (S). anesthetic status is measured using the following methods: pOC (particle-induced oxygen), neuromuscular conduction (NMT, which measures anesthetic status by electrically stimulating nerves in the hand and measuring the motor response at the fingertips using an accelerometer), brain electrical index (BIS, which measures anesthetic status from induced electrical potentials in the brain), electroencephalography (EEG), end-expiratory CO2 of lateral or main airflow (e.g., measuring CO2 in a sample of the patient's exhaled or main expiratory airflow using infrared spectroscopy), anesthetic gas monitoring (e.g., measuring oxygen and anesthetic concentrations in the patient's inhaled airflow), measurement of cardiac output from invasive blood pressure and temperature measurements, and measurement of blood oxygen saturation from an optical sensor coupled to the catheter tip via an optical fiber; measurement of blood properties (e.g., measuring invasive blood pressure and cardiac output) using absorption of light at different wavelengths and blood or hemodynamic modules, copies (e.g., dual SpO2 or IBP), or any combination thereof. In a non-limiting manner, some parameters that can be measured on a patient using a non-SDP sensor device and further converted into an SDP communication protocol using the SDP conversion device described herein may further include continuous non-invasive arterial pressure, transcutaneous oxygen saturation (TcPO2), transcutaneous CO2 (TcCO2), cardiac impedance cardiography (ICG), glucose monitoring (e.g., continuous glucose monitoring), pupillography, and indirect calorimetry.

[0089] SDP conversion device 109 is intended for use in all hospital nursing areas, during transport between nursing areas, and in ambulances. In some embodiments, SDP conversion device 109 operates under one or more of the following conditions: an ambient temperature range from about 0 to about 40°C; an ambient relative humidity range from about 10% to about 95% (without condensation); and / or an ambient pressure range from about 620 hPa to 1100 hPa.

[0090] In one embodiment, when the SDP conversion device 109 is connected to a medical device expressing an SDP (e.g., medical device 2, patient monitor, anesthesia machine, treatment device, ventilator), the SDP conversion device 109 can receive localized settings of the medical device from the medical device expressing the SDP. Localized settings may include atmospheric conditions (e.g., temperature and pressure), location settings (e.g., geographic location, specific clinic location, or care area). For example, when the SDP conversion device 109 is connected to a patient monitor located in a pediatric unit, the SDP conversion device 109 can adjust alarm limits and other configuration settings accordingly upon receiving localized settings for the pediatric unit. Some non-SDP sensor devices (e.g., gas detection sensors) require calibration processes or adjustments based on the temperature and / or pressure of the current location. When these non-SDP sensor devices are connected to medical device 2 via the SDP conversion device 109, medical device 2 can use its internal sensors to measure atmospheric pressure and provide this information to other non-SDP sensor devices via the SDP conversion device 109, or as part of contextual data to other devices (e.g., medical computing device network 104).

[0091] Alternatively or additionally, when the SDP conversion device 109 adjusts its settings, it may request user input (e.g., notify or request the user to accept the configuration change) via the user interface of the medical device representing the SDP.

[0092] Figure 7B This is a schematic block diagram of system 700 according to one or more embodiments. System 700 is similar to system 600, but shows the non-SDP patient sensor device 100 and SDP conversion device 109 in more detail. Sensors 11s are attached to, docked with, or otherwise engaged with patient 11 to obtain measurements of patient parameters and transmit analog electronic signals representing the measurements to the non-SDP patient sensor device 100.

[0093] The electronics of the non-SDP patient sensor device 100 (e.g., processing circuitry including analog-to-digital converters and signal processing circuitry) perform signal measurements and basic parameter calculations to generate digital sensor data in a non-SDP format. The non-SDP patient sensor device 100 uses a non-SDP communication protocol to transmit the digital sensor data (e.g., physiological parameters) to the SDP conversion device 109. The transmission of the digital sensor data can be via wired or wireless communication links.

[0094] Figure 7BThe transmission and amplification of physiological measurement data between sensors 11s on a patient and a multifunctional medical device 2 (e.g., a patient monitor) are illustrated. The sensors 11s on the patient generate electronic measurements detected by signal measurement electronics in a non-SDP medical device 100. The processing circuitry (e.g., a microprocessor and / or DSP) of the non-SDP medical device 100 uses software to perform basic parameter calculations on the measured signal data to generate clinically relevant quantities (e.g., digital sensor data such as patient physiological data), which are reported by electronic components, such as digital serial signals transmitted via wired or wireless means to an SDP conversion device 109.

[0095] SDP conversion device 109 enhances the value of clinically relevant quantities, for example, by executing functions via processor 126, such as: NSDP to SDP conversion function; and control limit testing of clinically relevant quantities and generating indicative alarms and / or additional alarm event signaling information that can be used by medical device 2 to generate alarms to draw the attention of caregivers; changing the unit of measurement of the quantity to a unit that is most meaningful to caregivers and most useful for medical device 2 to handle and process it; providing descriptive text strings to characterize the quantity in one or more languages ​​(e.g., English, German, Chinese, etc.); providing settings that allow changes to how medical device 2 processes the quantity, and providing access to those settings by communicating with one or more devices external to SDP conversion device 109; further processing of the quantity by an algorithm that uses features such as time-varying or mathematical calculations involving at least one of the quantity and other values, such as other quantities received from non-SDP medical device 100 or quantities obtained by SDP conversion device 109 from sources internal or external to SDP conversion device 109; or other enhancements to increase the clinical utility of the quantity, or multiple such enhancements. This appendix information, including additional signaling information, measurement unit information, descriptive text strings, setting information, access information, etc., can be attached to or transmitted together with the converted SDP sensor data (e.g., in the same data structure, such as MDB) transmitted from the SDP conversion device 109 to the medical monitoring device 2.

[0096] SDP conversion device 109 uses characteristic codes defined within the SDP to arrange quantities and other information in enhanced form, which are generated from enhancements in data structures defined within the SDP and may include data structure elements or operational characteristics representing SDP conversion device 109 or non-SDP medical device 100. SDP conversion device 109 transmits data structures to another device, such as medical device 2, in a manner specified by the SDP, and may report all or part of changes to the data structures at regular or irregular time intervals. SDP conversion device 109 may receive transmissions of specified changes to the data structures from another device, such as medical device 2, in a manner specified by the SDP, and may receive all or part of the specified changes to the data structures at regular or irregular time intervals. Figure 7C Another schematic view of a system 700 according to one or more embodiments is depicted. Here, the SDP conversion device 109 also provides electrical isolation between the medical device 2 (e.g., a patient monitor) and the non-SDP patient sensor device 100 to protect the patient. For example, the medical device 2 supplies power to the SDP conversion device 109, and the SDP conversion device 109 supplies power to the non-SDP patient sensor device 100.

[0097] For example, the SDP conversion device 109 may include a power controller 128 that receives power from the medical device 2 and controls its distribution to the processor 126 and the non-SDP patient sensor device 100. Specifically, the power controller 128 may include a voltage regulator that generates a supply voltage for the non-SDP patient sensor device 100 that is the same as or different from the voltage supplied to the SDP conversion device 109 and its processor 126.

[0098] SDP conversion device 109 may further include an electrical isolation barrier providing isolation between two different electrical domains (which may be different voltage domains). For example, processor 126 may reside in the first electrical domain, and non-SDP patient sensor device 100 and sensor 11s may reside in the second electrical domain. Thus, the electrical isolation barrier can protect both non-SDP patient sensor device 100 and patient 11s. Alternatively, processor 126 may reside in the second electrical domain, electrically isolated from medical device 2.

[0099] The power controller 128 can also limit the amount of current supplied to the non-SDP patient sensor device 100 and is configured to turn the power to the non-SDP patient sensor device 100 on or off.

[0100] Figure 8An example of a system 800 including an SDP conversion device 109 according to one or more embodiments is shown. In this example, the SDP conversion device 109 is illustrated as an SDP conversion cable that communicates with a non-local device, such as a non-SDP patient sensor device 100. The system 800 further includes attached sensors 11s that convert physiological quantities measured at the patient into electronic signals. The system 800 further includes a medical device 2 as an input node of the SDP communication network. The SDP conversion device 109 includes an SDP converter 54 that houses a dedicated communication component 123, a processor 126, and any associated memory 125. The SDP converter 54 is configured to convert or transform data from a non-SDP communication protocol to the SDP communication protocol (i.e., SDP) using an SDP library.

[0101] SDP conversion device 109 further includes optional cables 52 and 53, wherein cable 52 is configured to connect SDP conversion device 109 to medical device 2, and cable 53 is configured to connect SDP conversion device 109 to non-SDP patient sensor device 100. Additionally, SDP converter cable 109 may include connector 55 configured to connect to and establish a communication connection with medical device 2. Therefore, in this example, SDP conversion device 109 communicates with non-SDP patient sensor device 100 and medical device 2 via cables 52 and 53.

[0102] Figure 9A and 9B A rack-based embodiment of the converter system 900A is illustrated. In this embodiment, the SDP conversion device is a rack-mounted self-describing conversion device 63 encapsulated in a rack module 62, which connects the conversion device 63 to an embodiment of a medical device 2. Figure 9A and 9B The patient is depicted as a patient monitoring device 60. A non-SDP patient sensor device 100 is also connected to the patient 11, for example, via one or more sensors. Figure 9A and 9B The various components communicate electrically with each other. The rack-mounted self-describing conversion device 63 performs all the same functions described above with respect to the SDP conversion device 109. For example, the rack-mounted self-describing conversion device 63 converts data from non-SDP protocols to SDP protocols and provides data enhancement functions, such as... Figure 7B As shown in the image.

[0103] Figure 9CAn example of a medical device 900B according to one or more embodiments is shown. The medical device 900B includes a housing (i.e., a enclosure) and at least one non-SDP medical device 100 disposed within the housing. The medical device 900B optionally includes one or more self-describing modules 902 and 903 (e.g., self-describing patient sensor devices) disposed within the housing, each module configured to provide data according to an SDP. The medical device 900B further includes at least one SDP conversion device 109 (e.g., an SDP conversion board) that provides a means of transmitting data between the non-SDP medical device 100 and another device, such as medical device 2, which requires the connected device to employ a defined SDP. Data from all devices can be provided to medical device 2 from one or more devices contained within housing 901, either together or in segments.

[0104] For example, self-describing medical devices 902 and 903 can directly communicate with medical device 2 and exchange SDP data via communication interface 904. In contrast, non-SDP medical device 100 can only communicate with medical device 2 and exchange data via SDP conversion device 109. SDP conversion device 109 receives non-SDP data from non-SDP medical device 100, converts the non-SDP data into SDP data, and transmits the SDP data to medical device 2.

[0105] Figure 10 This is a schematic diagram of a mounting rack 1003 configured to accommodate one or more devices according to one or more embodiments. The mounting rack 1003 is similar to medical device 900B because it has a housing configured to accommodate one or more self-describing modules 1001 and 1002 transmitting data in SDP format. Self-describing module 1001 has a single-width form factor, and self-describing module 1002 has a double-width form factor. Therefore, self-describing or SDP local representation modules can be mounted within the rack 1003, such as… Figure 10 As shown in the image.

[0106] In one embodiment, the SDP conversion module 1009 is implemented as an SDP conversion device and can be inserted into a corresponding slot or volume of the SDP rack 1003. The SDP conversion module 1009 may be a sensor device with SDP conversion functionality, or it may be connected to or otherwise interface with a non-SDP medical device 100, which itself may be inserted into the rack 1003 or disposed outside the rack 1003.

[0107] The SDP conversion module 1009 is provided and therefore includes a software development kit (SDK) containing an SDP library. This SDP library can be used on an embedded processor, which may be part of an existing interface board 1006 from a third party (which has already received the SDK and pre-uploaded the SDP library), or it may be located on... Figure 17 and 21 On the separate SDP processor board shown, or such as Figure 7A The dedicated communication component 123 shown is illustrated.

[0108] SDP processor board 1006 may further include a USB interface 1008 for SDP communication with a host, and a serial interface for communicating with OEM parameter board 1007 using its existing command set for measuring physiological parameters. SDP processor board 1006 has an interface and transmits its measurements upon request via a proprietary command set. By connecting the port of a non-SDP patient sensor device to SDP conversion device 109, the product can be converted into an SDP device. SDP conversion device 109 connects to the SDP processor board 1006 of the non-SDP patient sensor device (such as...). Figure 7A The dedicated communication component 124 communicates to obtain measurements, perform additional processing, test alarm limits (if appropriate), send data to medical devices via the SDP library, or a combination thereof.

[0109] Figure 11A-11D Various types of SDP conversion devices 109a, 109b, 109c, 109d and 109e according to one or more embodiments are shown. Figure 11A The SDP conversion device 109a described herein is an SDP converter cable. Figure 11B The SDP conversion equipment 109b depicted is an SDP double-width rack bay. Figure 11C The SDP conversion device 109c depicted in Figure 11 is an SDP single-width rack compartment, and the SDP conversion devices 109d and 109e depicted in Figure 11 D are tethered compartments with cables for connecting to patient monitors, such as modules with input amplifiers, which require cables with limited impedance.

[0110] Figure 12 and 13 The illustration shows a non-SDP sensor device for measuring gas concentration in respiratory airflow, where each sensor device is combined with an SDP conversion device. Figure 12 The illustration shows a carbon dioxide monitoring sensor device 1200 with an airway 1201 for detecting end-tidal CO2 using infrared spectroscopy. The sensor device 1200 is configured to connect to an SDP conversion cable 109. Figure 13The illustration shows an SpO2 sensor 1300 for measuring oxygen saturation, wherein the SpO2 sensor is configured to connect to an SDP converter cable 109.

[0111] like Figure 12 As illustrated, sensor device 1200 is connected to or includes an SDP conversion device (e.g., SDP converter cable 109). SDP converter cable 109 includes module 54, within which an SDP conversion serial board is located. SDP converter cable 109 may further include connector 55 configured to connect to and establish a communicative connection with medical device 2. Without limiting the scope of this disclosure, SDP conversion devices connected to or included in sensor devices may have different sizes and / or forms than those described above.

[0112] It should also be noted that the illustration is applied to the main airflow CO2 sensor used in the primary expiratory airflow. Figure 12 For illustrative purposes only. The type of non-SDP gas detection sensor that is communicatively coupled to the SDP conversion device should not be limited herein. For example, a micro-flow CO2 sensor that extracts a small fraction of the flow and measures it at a location remote from the patient can also be combined with the SDP conversion device according to this disclosure. Alternatively, in addition to the sensor and electronics, the micro-flow CO2 device may further include a pump to drive the extraction of the sample flow. The micro-flow CO2 sensor minimizes the hardware size present around the patient's face, but this is a preferred method for carbon dioxide smography of infants because their main airflow rate is very low.

[0113] In another embodiment, other types of non-SDP gas detection sensors can also be connected to medical device 2 via an SDP conversion device. For example, the gas detection sensor may include an infrared sensing unit that measures the concentration of an anesthetic agent (e.g., isoflurane, desflurane, halothane, sevoflurane, and enflurane) in a gas mixture, which an anesthesiologist can use to maintain safe and effective anesthetic conditions for the patient during surgery. Alternatively, the gas detection sensor may incorporate a magnetic sensor to detect oxygen, wherein a magnetic field is generated by a set of coils within the sensor to measure the oxygen concentration in the gas stream. It utilizes the paramagnetism of oxygen to alter the thermal behavior of the gas, and then measures the thermal behavior by electronically detecting temperature changes near a heating element.

[0114] The aforementioned non-SDP gas detection sensors can be connected to or contained within an SDP conversion device (e.g., an SDP converter cable or an SDP conversion device of different sizes and / or forms). In this way, these sensors are allowed to be communicatively coupled to medical devices, even if these medical devices are expressed using a different communication protocol than the sensors.

[0115] In the case of CO2 equipment 1200 including an SDP converter board, the SDP converter board can be housed in a double-width enclosure of SDP racks 1003, 62. In one particular embodiment, the CO2 equipment will draw up to 16W within 5 minutes during its preheating phase and requires 7W thereafter. SDP racks 1003, 62 and monitoring equipment brackets will provide 24V (24W) at up to 1A and 5V at up to 1A for SDP-compatible equipment. The equipment will be powered by a 24V supply. To eliminate the need for a 24V / 5V converter on the SDP converter serial board, the converter will be powered by a 5V supply. Some gas measurements require atmospheric pressure values ​​to properly reduce their data.

[0116] Figure 13 Illustrations are provided of non-SDP devices (e.g., OEM devices) used to measure the fraction of oxygen-carrying hemoglobin in blood, expressed as saturation pressure or SpO2. Specifically, a non-SDP SpO2 device 1300 is shown. The SpO2 device 1300 is connected to or includes a conversion device (e.g., SDP converter cable 109) and comprises a module 54 having an SDP conversion serial board within the cable 109.

[0117] Measurements are made by passing red and infrared light through the tissue of interest. Oxyhemoglobin and deoxyhemoglobin absorb red and infrared light differently (that is, hemoglobin changes color when it binds with oxygen). Measurements can be taken in transmission mode by placing the light source and detector on opposite sides of the tissue sample (e.g., a sensor gently clipped to a finger as illustrated), or in reflection mode, where light penetrates the tissue and is reflected back, passing through the tissue sample in both directions. This measurement is primarily used to measure respiratory function.

[0118] Figure 14 An example embodiment of a hemodynamic device 1400 is provided, which becomes a self-describing device when using an SDP conversion device (such as SDP conversion device 109). The hemodynamic device 1400 may include an internal SDP converter device or cable for protocol conversion. The hemodynamic device 1400 further provides space within its housing for up to four invasive blood pressure (IBP) sensors and displays information corresponding to each IBP sensor. The SDP hemodynamic device measures invasive blood pressure and cardiac output. Invasive pressure is measured via a pressure transducer connected to a catheter; the other end of the catheter is placed at the measurement point. Cardiac output is measured via thermodilution—a process in which cold saline is injected into the blood and the temperature at another point is used to assess blood transport.

[0119] From the various embodiments described herein, it will be readily apparent that the SDP conversion device 109 can be implemented in a variety of ways, including integration with the non-SDP patient sensor device 100 within the same housing as the non-SDP medical sensor electronics and the non-SDP processor. Here, the SDP conversion board can be incorporated into or otherwise inserted into the non-SDP patient sensor device 100, serving as an interface between the non-SDP electronics of the non-SDP patient sensor device 100 and the multifunctional medical device representing SDP. The SDP conversion board receives non-SDP sensor data, converts the sensor data into an SDP format with rich data, and the non-SDP patient sensor device 100 transmits the SDP-formatted data to the multifunctional medical device (e.g., medical device 2) with the assistance of the SDP conversion board. Alternatively, the SDP conversion device 109 can be provided externally to the SDP patient sensor device 100 in the form of an SDP conversion module, an SDP converter cable, etc. Regardless of the implementation method, the SDP conversion device 109 performs a similar function because it interfaces between the non-SDP patient sensor device 100 or its non-SDP circuitry and the SDP multifunctional medical device to convert non-SDP sensor data into an SDP format that can be optimized for and used by the SDP multifunctional medical device.

[0120] Figure 15 A block diagram of a hemodynamic device integrated with an SDP conversion device 109 is shown. This device further utilizes accessories to measure cardiac output (pulmonary artery catheter, temperature probe, and Y-shaped temperature cable). In the illustrated embodiment, the analog section (isolator, signal conditioner, and A / D converter) is identical to the temperature / IBP section of the analog front end of a medical device.

[0121] As previously mentioned, the SDP conversion device 109 further includes a connector 55, which allows it to connect to other components within the medical device 2, module, or system. In this embodiment, the connector 55 is integrated with an SDP converter 54 that includes an SDP processor 126 (microprocessor) and an SDP library. As a result, the cable 52 is not present. The connector 55 can be male or female. At the end of the SDP conversion device 109 opposite to the connector 55, a non-SDP sensor 100 can be connected to provide non-SDP sensor data to the SDP conversion device 109.

[0122] Figure 16A , 16BFigures 109f, 109g, and 109h illustrate various types of SDP converter cables 109f, 109g, and 109h according to one or more embodiments. Each of the SDP converter cables 109f, 109g, and 109h includes an SDP converter module 54, which includes an SDP microprocessor μP configured to convert non-SDP data into SDP data (e.g., an SDP library stored in memory 125 (not shown) via software and cross-references) according to the disclosure provided herein. The converter cables 109f, 109g, and 109h further include a second connector 57 configured to connect to a non-SDP patient sensor device 100 for receiving non-SDP sensor data from it and optionally powering the non-SDP patient sensor device 100 via one or more connector pins. Connector 57 is female on one side for connection to a non-local device and male on the other side at connector 55. However, connectors 55 and 57 can be either male or female.

[0123] In one example Figures 16A-16C The SDP conversion devices 109f, 109g, and 109h described herein will be connected to non-SDP sensor devices to measure end-tidal CO2, SpO2, and blood or hemodynamic modules, respectively. Figures 16A-16C In the embodiments shown, SDP conversion devices 109a, 109b and 109c include an SDP processor (e.g., a microprocessor μP), and the SDP conversion device for a hemodynamic device may further include a field-programmable gate array 129.

[0124] Figure 17 and Figure 18 Provides usage such as Figure 17 The illustrations depict different embodiments of a serial protocol for SDP communication on an SDP processing board or OEM board, wherein the OEM board has conversion software installed in the OEM software and an SDP library also installed in memory. Each embodiment has device-specific instrumentation electronics and software, an SDP communication (SDP-COM) interface library, or simply the SDP library, and intermediate software units for creating and maintaining descriptions and state structures in the MDIB by calling SDP-COM interface library functions.

[0125] exist Figure 17The diagram illustrates a schematic of an SDP bay 1700 as an example of an SDP conversion device. The SDP bay 1700 includes an OEM instrumentation device 1701 that interfaces with one or more sensors 11s. The OEM instrumentation device 1701 transmits physiological measurements, sensor data, etc., to the I / O universal asynchronous receiver-transmitter (UART) 1703 of the SDP converter 1702 in the form of serial communication data 1708. The SDP converter 1702 may be an SDP serial board including an SDP processor 1704 configured similarly to the converter module 54 and performing similar functions to those described above for the reference processor 126 and dedicated communication component 123. Therefore, the SDP processor 1704 includes SDP conversion software 1705 and an SDP library 1706, both stored in memory. The SDP processor 1704 (i.e., the processor board) is connected to existing non-SDP devices (i.e., non-local devices) via a serial interface.

[0126] SDP processor 1704 is configured to execute conversion software 1705 and SDP library 1706 to convert communication data 1708 (e.g., non-SDP digital sensor data) from its non-SDP (non-local) communication protocol (NSDPCOM) to the SDP communication protocol (SDPCOM). Specifically, SDP processor 1704 uses conversion software 1705 and SDP library 1706 to identify the type of non-local, non-SDP communication protocol used for communication data 1708, determines the NSDP-to-SDP conversion algorithm in SDP library 1706 based on the identified non-SDP communication protocol mapping, and converts the non-SDP data to SDP based on the determined NSDP-to-SDP conversion algorithm SDP. The assembly of SDP bay 1700 can be housed in an SDP rack unit or in another form factor.

[0127] exist Figure 18The diagram illustrates an SDP bay 1800 as an example of an SDP conversion device. The SDP bay 1800 has SDP software integrated on a single board with OEM instrument electronics and OEM software 1802. OEM board 1801 is a processing board, and the OEM software is combined with conversion software (e.g., conversion software 1705). Therefore, the processor of OEM board 1801 is configured to execute the OEM software and additionally execute the conversion software of reference SDP library 1803 to convert communication data (e.g., non-SDP digital sensor data) from its non-SDP communication protocol (NSDPCOM) to the SDP communication protocol (SDPCOM). Specifically, the OEM processor uses the conversion software to identify the type of non-SDP communication protocol used for the communication data, determines the conversion algorithm in SDP library 1803 based on the identified non-SDP communication protocol mapping, and converts the non-SDP communication data to SDP SDP based on the determined conversion algorithm.

[0128] The choice of configuration depends on a variety of factors, such as the nature of the cabin, whether the onboard processor has the ability to support instrument software and SDP communication operations, and whether the SDP-specific board design is feasible.

[0129] SDP Library 1803 is designed to be platform-independent and / or, if development is performed on a board that includes a microprocessor, as shown in the figure.

[0130] Figure 19 A functional block diagram of a conversion device for converting non-SDP sensor data derived from an SpO2 sensor (i.e., sensor 11s) is provided. The SpO2 sensor measures the fraction of oxygen-carrying hemoglobin in blood. This fraction is expressed as a saturation percentage or SpO2. Measurement is performed by passing red and infrared light through the tissue of interest. Oxygenated and deoxygenated hemoglobin absorb red and infrared light differently (i.e., hemoglobin changes color when it binds with oxygen). Measurements can be performed in transmission mode or reflection mode, where light penetrates the tissue and is reflected back, passing through the tissue sample in both directions, by placing the light source and detector on opposite sides of the tissue sample (e.g., a finger).

[0131] In these embodiments, the use of existing accessories (such as finger sensors) is unaffected by the use of the SDP conversion device 109. (See reference...) Figure 19The SDP conversion device 109 includes: a microprocessor (such as an SDP serial board 1702) programmed to communicate with one or more system components in the non-SDP patient sensing device 100; an SpO2 sensor to acquire data measurements and change settings, and to format these measurements according to the SDP (i.e., different communication protocols) of the medical device and system used for the SDP configuration described herein. In those embodiments using the SDP converter cable 109, power to the cable 109 can be turned on or off by the SDP serial board 1702 via a power controller integrated thereon. In some embodiments, the current can also be limited to a pre-configured amount, such as no more than 500 mA.

[0132] In some embodiments, a single SDP conversion device will support any type of commercially available SpO2 sensor. However, different SpO2 sensor products may use certain communication speeds, protocols, or other attributes. During operation, the SDP conversion device 109 will cycle power to reset the NSDP sensor device (e.g., the SpO2 sensor) and then attempt to communicate with it using a different protocol or a different communication speed to interact within one or more NSDP sensor devices. The SDP conversion device 109 includes a medical-grade USB cable, one or more connectors, an SDP serial board, indicator lights (such as LEDs) showing whether power is on, and a housing.

[0133] In some embodiments, the SDP conversion device 109 provides electrical isolation for signals and power, as described above. Figure 7C The processor itself may not be isolated from the medical device 2. That is, they can be on the same side of the electrical isolation barrier, such as... Figure 7C As shown in the diagram. When using this product, the patient may be defibrillated, therefore the SDP conversion device 109 must be defibrillation-proof as a Type F device. By placing the processor on the SDP side of the conversion device 109, and thus electrically isolating it from the defibrillator connected to the NSDP side of the conversion device 109, the processor can be protected from power surges.

[0134] Figure 20A and 20B An illustration is provided of an SDP conversion device configured to connect to a hemodynamic sensor device.

[0135] refer to Figure 20A and 20B Both conversion devices consist of converter electronics, a housing 54 or enclosure housing the SDP serial communication board, and two cables with a molded strain release feature. Red / green LEDs indicating applied power and connection status are visible through the housing surrounding the SDP serial communication board.

[0136] Figure 21A schematic diagram of the communication link between a non-SDP device 100 and an SDP conversion device 109 is provided, including conversion software 1705 and an SDP library 1706. In the illustrated embodiment, SDP uses USB, such as USB 2.0, to implement a lower network layer. USB provides a hub structure, detection of attached devices, and components for controlling power to each module or device. The USB 2.0 protocol allows for transmission at multiple speeds, including high-speed (480 Mbps) and full-speed (12 Mbps). The SDP conversion device 109 allows the use of non-SDP devices at both speeds.

[0137] Microprocessor board 1704 generates SDP-compliant MDB. Microprocessor board 1704 achieves this by converting non-SDP communication data (i.e., sensor data) received from non-SDP device 100 into SDP via reference SDP library 1706 and by applying a selected conversion algorithm.

[0138] In one particular embodiment, the SDPSDP conversion device 109 includes a microprocessor board 1702 with the following configurable features: a 180MHz processor (2 MB flash memory and 256KB SRAM); a serial interface (logic level and RS232); 16MB SDRAM; 8 MB flash memory; and high-speed USB 2.0. Figure 21 The software 1705 running on the processor 1704 shown can perform one or more of the following tasks: converting data received from non-SDP devices in non-SDP communication into SDP that can be placed into the MDIB; providing logic for alarm conditions, including user interface preferences (such as settings menus and alarm limits); providing algorithms to perform data analysis; and selecting text strings from the index. The SDP software library shown includes a set of tools that enable the microprocessor board 1702 to perform operations on the MDB, including constructing MDB elements and updating them with new data. Figure 21 The functionality described can vary depending on the non-SDP or OEM devices used in the system. Due to the variation in the boards running OEM software, SDP-COM is not tied to any particular operating system or architecture, and is therefore independent of it—it can interface with any OEM software. Figure 21 The OEM software module identified in the code specifies the portion of software code that is specific to the particular non-SDP device with which the conversion device is communicating.

[0139] The SDP conversion apparatus described herein may include any one or more conversion processing boards. Examples of embodiments of the conversion processing board are provided in... Figures 22 to 25The following are shown (e.g., named Board-1, Board-2, Board-3, and Board-4). Some embodiments of the processor board provide basic serial communication, with or without isolation. On any of these boards, the serial output voltage level can be logic level (UART) or RS-232. Using any of the above-described conversion processor boards, virtually any OEM bay can be made SDP compliant. One particular embodiment of the conversion processor board is equipped with isolation and an FPGA to implement SDP. Adapter cables for conventional, non-local, OEM, or non-SDP-represented devices can also use this conversion processor board. Yet another embodiment of the conversion processor board can be configured to accept input from four IBP sensors, such as... Figure 25 As shown in the illustration. In this embodiment, the conversion processor board can also receive additional OEM or third-party boards that provide the electronics for the sensor device. Figure 24 In this process, the NSDPCOM Complex Programmable Logic Device (CPLD) interfaces between the OEM board and the conversion processor board (board 3).

[0140] The cabins can be shared and combined. Figure 14 Many of the aforementioned characteristics. Both will be housed in a housing that provides space for up to four IBP sensors. A display on each pressure sensor will indicate the label assigned to the pressure by the user via the monitor's user interface. The number of characters and display technology (e.g., LCD, LED, etc.) for each display can be selected during the detailed design of the chamber. Both chambers will support disposable pressure sensors (200-3000). (Sensitivity is 5 uV / V / mmHg). Both chambers can be used. Figure 25 The SDP processor board 4 shown is used to implement this.

[0141] The SDP blood converter cable allows users to connect to the SDP port, which is shown in [the diagram]. Figure 26A and Figure 26B In China, it is used in hemodynamic sensor devices.

[0142] Figure 26A and 26B This shows how the two chambers 100 are connected to the blood converter cable. Existing connectors 55 can be used. Figure 26A The hemodynamic sensor device shown is inserted into medical device 2. The connector 55 is mounted at the end of cable 52 extending from the blood conversion cable. Using the SDP conversion device does not affect the use of existing accessories (pressure sensor, cardiac output).

[0143] The SDP conversion device will include a microprocessor programmed to communicate with the non-SDP patient sensor device 100 described herein to acquire measurements and change settings, and to format these measurements according to the SDP of the medical device 2. The SDP concept removes functions such as alarm detection, providing text strings in the local language, and data unit conversion (traditionally performed within the monitor) from the monitor and places these responsibilities within the SDP device. Because non-SDP devices are not designed to be self-describing, the SDP conversion device 109 must perform these functions.

[0144] In one particular embodiment, the conversion device includes a converter cable that provides electrical isolation for signals and power. In this or other embodiments, the conversion device will be isolated according to IEC 60601-2-49. The processor itself is not isolated from the medical device 2. Signal isolation occurs between the FPGA and the NSDPCOM transceiver. In this example, 6400VDC isolation is provided for the signal and power pins on the NSDPCOM connector.

[0145] SDP communication uses USB 2.0 to implement a lower network layer. USB provides the hub structure, attached device detection, and power control for each SDP communication device. The USB 2.0 protocol allows for multiple transmission speeds, including high-speed (480 Mbps) and full-speed (12 Mbps). SDP allows for the use of devices at both speeds. Blood transfusion converter cables can be designed using SDPNSDPCOM.

[0146] Figure 27 A block diagram of another example of the SDP conversion board 1702 is shown. Like other SDP conversion boards described herein, the NSDPCOM or serial communication design features the following configurable characteristics: a 180MHz processor (2 MB Flash, 256 KBS RAM); a serial interface (logic level and RS232) up to 115 kbps; 16 MB SDRAM; 8 MB Flash; and high-speed USB 2.0. Of course, these features are non-limiting and can be fully configured according to design options.

[0147] As used herein, NSDPCOM is a synchronous bidirectional serial interface used between NSDP sensor device 100 and SDP conversion device 109, and is used by SDP conversion device 109 to communicate with NSDP sensor device 100, for example, to obtain physiological patient parameters (i.e., NSDP sensor data). This protocol is used with hemodynamic sensor devices. In the SDP conversion device, this feature is implemented in an FPGA, but is not limited thereto. An SPI interface between the microprocessor and the FPGA allows the microcontroller to send and receive on the NSDPCOM communication channel.

[0148] High-sensitivity monitors, similar to those described in this article, provide a cardiac synchronous output that can be used to drive an intra-aortic balloon pump or defibrillator. The analog output signal must represent the waveform from the invasive pressure sensor with relatively low latency (e.g., no more than 25 milliseconds (ms)). Depending on the parameters being measured, the SDP communication interface is not designed to guarantee low-latency delivery. Therefore, the medical device will provide an additional serial line dedicated to transmitting a single pressure signal from the IBP device to the analog subsystem of the SSPPM, thus bypassing the SDP.

[0149] If the SDP conversion device is attached to a monitor on a serviceable network, it can be updated remotely. This service functionality will be implemented in all SDP communication or self-describing devices within the system as described herein.

[0150] In some embodiments, system components and equipment should be made of materials suitable for proper cleaning, disinfection, and sterilization in a hospital environment. When cleaned with medically approved cleaning agents, system components and equipment should maintain basic safety and basic performance for the expected service life.

[0151] Figure 28 Embodiments of processor boards for use in SDP conversion devices, such as SDP converter cables that convert non-SDP SpO2 sensor data into SDP communication protocols, are provided for communication with multifunctional medical devices such as patient monitors, treatment devices, or medical devices. The depicted embodiments include, in particular, a microprocessor board, a thermistor, a power indicator, a 3.3-volt regulator, a current-limiting switch, a 64 Mbit flash drive, a 120 Mbit SDRAM, an EEPROM, a universal asynchronous receiver-transmitter (UART), and dual light-emitting diode (LED) lights for test / debugging.

[0152] Figure 29A and 29B Examples of cables and multi-pin connectors for SDP conversion devices, and more specifically SDP converter cables as described herein, are provided. Figure 29B The power pins (GND and V+) and data pins are identified. For example, a multi-pin connector can be implemented as connector 55 and / or 57 in the aforementioned examples. Furthermore, the connector may include shielding around the connector pins.

[0153] Figure 30A and 30B Examples of multi-pin male and female connectors for SDP conversion devices, and more specifically for SDP converter cables described herein, are provided.

[0154] Figure 31Detailed illustrations of exemplary module connectors and pin connections are provided.

[0155] Figure 32 An exemplary flexible cable assembly is provided.

[0156] Figure 33 An exemplary SDP adapter cable is provided, which can be used to allow modules to connect to system components without a rack.

[0157] This invention can be implemented as any combination of a device, system, integrated circuit, and computer program on a non-transitory computer-readable recording medium. One or more processors can be implemented as integrated circuits (ICs), application-specific integrated circuits (ASICs), or large-scale integrated circuits (LSIs), system LSIs, super LSIs, or ultra-LSI components that perform some or all of the functions of a secure conditional access architecture.

[0158] This invention includes the use of computer programs or algorithms. The programs or algorithms may be stored on a non-transitory computer-readable medium for causing a computer (such as one or more processors) to execute them. Figure 2-3 The steps described herein. For example, one or more memories store software or algorithms with executable instructions, and one or more processors can execute a set of instructions associated with generating, processing supply requests and supply messages, such as... Figure 2-3 As described in [the text].

[0159] A computer program—which may also be referred to as a program, software, software application, application, component, or code—includes machine instructions for a programmable processor and can be implemented in a high-level programming language, an object-oriented programming language, a functional programming language, a logic programming language, or an assembly language or machine language. The term computer-readable recording medium refers to any computer program product, apparatus, or device (such as magnetic disks, optical disks, solid-state storage devices, memories, and programmable logic devices (PLDs)) used to provide machine instructions or data to a programmable data processor, including computer-readable recording media that receive machine instructions as computer-readable signals.

[0160] For example, computer-readable media may include DRAM, RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to carry or store desired computer-readable program code in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer or a general-purpose or special-purpose processor. As used herein, disks or optical discs include compact optical discs (CDs), laser optical discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. Combinations of the above are also included within the scope of computer-readable media.

[0161] In one or more embodiments, the phrases “capable,” “can,” “operable,” or “configured to” refer to a device, logic, hardware, and / or element designed in such a way that it is possible to use the device, logic, hardware, and / or element in a particular manner.

[0162] The subject matter of this disclosure is provided as an example of methods and procedures for implementing features of a secure conditional access architecture. However, in addition to the features described above, other features or variations are contemplated. It is envisioned that the implementation of the components and functions of this disclosure can be accomplished using any emerging technologies that can replace any of the technologies implemented above.

[0163] Additionally, the above description provides examples and does not limit the scope, applicability, or configuration set forth in the claims. Changes may be made in the function and arrangement of the elements discussed without departing from the spirit and scope of this disclosure. Various processes or components may be appropriately omitted, substituted, or added in various embodiments. For example, features described with respect to certain embodiments may be combined in other embodiments.

[0164] Various modifications to this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the spirit or scope of this disclosure. Throughout this disclosure, the terms “an example,” “multiple examples,” or “example” indicate an example or instance and do not imply or require any preference for the examples indicated. Therefore, this disclosure will not be limited to the examples and designs described herein, but will be accorded the widest scope consistent with the principles and novel features of the disclosure.

Claims

1. A communication protocol conversion system, comprising: A non-self-describing protocol (NSDP) sensor device is configured to receive electrical signals from at least one sensor and generate NSDP sensor data based on the received electrical signals according to NSDP. A multi-functional medical device configured to receive and process SDP data formatted according to the Self-Description Protocol (SDP); as well as An SDP conversion device is interposed between and communicates with an NSDP sensor device and a multifunctional medical device, wherein the SDP conversion device is configured to receive NSDP sensor data, generate SDP data based on the NSDP sensor data and an NSDP to SDP conversion algorithm, and transmit the SDP data to the multifunctional medical device. The SDP conversion device includes a memory that stores a catalog of NSDP to SDP conversion algorithms, and The SDP conversion device is configured to identify NSDP sensor data as NSDP, select an NSDP to SDP conversion algorithm from the NSDP to SDP conversion algorithm catalog based on the identified NSDP, and use the selected NSDP to SDP conversion algorithm to convert the NSDP sensor data into SDP sensor data.

2. The communication protocol conversion system according to claim 1, wherein, The SDP conversion device is configured to convert NSDP sensor data into SDP sensor data to generate SDP data.

3. The communication protocol conversion system according to claim 2, wherein: The SDP conversion device is configured to, while converting NSDP sensor data into SDP sensor data, test at least one clinically relevant quantity of the NSDP sensor data against at least one limitation, and generate additional SDP signaling information if the at least one clinically relevant quantity is outside one of the at least one limitation.

4. The communication protocol conversion system according to claim 2, wherein: The SDP conversion device is configured to convert NSDP sensor data into SDP sensor data while simultaneously converting a first unit of measurement of at least one clinically relevant quantity of the NSDP sensor data into a second unit of measurement different from the first unit of measurement. The SDP sensor data provides at least one clinically relevant quantity conforming to a second unit of measurement.

5. The communication protocol conversion system according to claim 2, wherein: The SDP conversion device is configured to generate a descriptive text string that is provided along with the SDP sensor data while converting NSDP sensor data into SDP sensor data, wherein the descriptive text string represents at least one clinically relevant quantity of the SDP sensor data in one or more languages.

6. The communication protocol conversion system according to claim 2, wherein: The SDP conversion device is configured to generate setup information along with the SDP sensor data while converting NSDP sensor data into SDP sensor data. This setup information allows many functional medical devices to change at least one clinically relevant quantity in how the SDP sensor data is processed.

7. The communication protocol conversion system according to claim 2, wherein: The SDP conversion device is configured to time-modify at least one clinically relevant quantity of the NSDP sensor data while converting NSDP sensor data into SDP sensor data.

8. The communication protocol conversion system according to claim 2, wherein: The SDP conversion device is configured to enhance the clinical utility of at least one clinically relevant quantity of NSDP sensor data while converting NSDP sensor data into SDP sensor data.

9. The communication protocol conversion system according to claim 1, wherein, The SDP is a set of rules for using data structures, transmission formats, and defined codes to transmit and understand a limited number of types of information, enabling the multifunctional medical device to use, report, or retransmit the information without prior representation of the SDP data.

10. The communication protocol conversion system according to claim 1, wherein, The SDP conversion device includes a power circuit configured to receive power from a multifunctional medical device and distribute a portion of the received power to the NSDP sensor device.

11. The communication protocol conversion system according to claim 10, wherein, SDP conversion equipment includes: In the first area, SDP data is transmitted from the first area to the multifunctional medical device, wherein the first area is in electrical contact with the multifunctional medical device and is configured to receive power from the multifunctional medical device; A second region in electrical contact with the NSDP sensor device, for receiving NSDP data therefrom, and a portion of the received power is distributed from there to the NSDP sensor device; and An isolation barrier that electrically isolates the first region from the second region.

12. The communication protocol conversion system according to claim 11, wherein, SDP conversion equipment includes: The processing circuit is configured to generate SDP data based on NSDP sensor data and an NSDP-to-SDP conversion algorithm, wherein the processor circuit is located in the first region.

13. The communication protocol conversion system according to claim 12, wherein, The power circuit is located in the second region and is configured to distribute an additional portion of the received power across the isolation barrier to the processing circuit.

14. The communication protocol conversion system according to claim 1, wherein, The at least one sensor is attached to a person and configured to generate an electrical signal based on measuring at least one physiological parameter of the person.

15. The communication protocol conversion system according to claim 1, wherein, Multifunctional medical devices cannot process at least a portion of the NSDP sensor data generated by NSDP sensor devices.

16. A method for converting data between different communication protocols, the method comprising: The device receives non-self-describing protocol (NSDP) sensor data via the first communication interface of the self-describing protocol (SDP) conversion device. The processor of the SDP conversion device generates SDP data based on NSDP sensor data by applying the NSDP to SDP conversion algorithm to the NSDP sensor data. The processor selects the NSDP to SDP conversion algorithm from the NSDP to SDP conversion algorithm catalog by identifying the NSDP of the NSDP sensor data and selecting the NSDP to SDP conversion algorithm from the NSDP to SDP conversion algorithm catalog based on the identified NSDP. as well as The SDP data is transmitted to the SDP processing device via the second communication interface of the SDP conversion device.

17. The method according to claim 16, wherein, Generating SDP data involves converting NSDP sensor data into SDP sensor data to generate SDP data.

18. A self-describing protocol (SDP) conversion device, comprising: The first communication interface is configured to receive non-self-describing protocol (NSDP) sensor data; At least one processor is configured to generate SDP data by applying an NSDP to self-describing protocol (SDP) conversion algorithm to NSDP sensor data; as well as The second communication interface is configured to transmit SDP data to the SDP processing device. A memory for storing the SDP library, which includes a directory of NSDP to SDP conversion algorithms. The processor is configured to identify NSDP sensor data, select an NSDP to SDP conversion algorithm from the catalog of NSDP to SDP conversion algorithms based on the identified NSDP, convert the NSDP sensor data into SDP sensor data using the selected NSDP to SDP conversion algorithm, and transmit the SDP data to the SDP processing device via a second communication interface.

19. The Self-Description Protocol (SDP) conversion device according to claim 18, wherein: The at least one processor is configured to convert NSDP sensor data into SDP sensor data to generate SDP data.

20. The self-describing protocol (SDP) conversion device according to claim 18, further comprising: The power circuit is configured to receive power from the SDP processing device and distribute a portion of the received power to the NSDP sensor device that receives NSDP sensor data from it.

21. The self-describing protocol (SDP) conversion device according to claim 20, further comprising: In the first area, SDP data is transmitted from the first area to the SDP processing device, wherein the first area is in electrical contact with the SDP processing device and is configured to receive power from the SDP processing device. A second region that is in electrical contact with the NSDP sensor device for receiving NSDP data therefrom, and a portion of the received power is distributed from there to the NSDP sensor device. as well as An isolation barrier that electrically isolates the first region from the second region.

22. The self-describing protocol (SDP) conversion device according to claim 21, wherein, The at least one processor is located in the first region.

23. The self-describing protocol (SDP) conversion device according to claim 22, wherein, The power circuit is located in the second region and is configured to distribute an additional portion of the received power across the isolation barrier to the at least one processor.

Images