Method and computer-readable recording medium for updating data in medical monitoring device using self-description module

Abstract

A method and computer-readable recording medium for updating data in a medical monitoring device using a self-description module. The self-description module includes a metadata block (MDB) that includes at least identification (ID) data and corresponding configuration data. A medical monitoring device includes a plurality of subsystems. The ID data from the MDB is associated with ID data of a plurality of subsystems of the medical monitoring device, and then configuration data of at least one subsystem is updated with configuration data in the MDB based on a result of the association.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 62 / 654,218, filed April 6, 2018, the entire contents of which are fully incorporated herein by reference. Technical Field

[0002] The presently disclosed subject matter generally relates to updating data in a medical monitoring device. Background Art

[0003] Conventional models for interfacing a patient front end with a medical device create software on the medical device that is specifically designed to handle data from the front end. However, these conventional models also introduce problems that need to be solved. One problem is that it is difficult to add new parameters to the front end without also updating the software on the medical device, because the medical device must have the ability to handle the new parameters. In addition, since both the parameters and the software in the medical device are updated together, they are also tested and released as a system. In addition, the new version of the software may be incompatible with the previously released medical device at the customer location.

[0004] Therefore, it would be advantageous and an improvement in the related art to provide a method for a self-describing module to efficiently and easily update data in a medical monitoring device. Summary of the invention

[0005] Embodiments described in the present disclosure provide a method for implementing a self-describing module for updating data in a medical monitoring device. The method includes using a communication interface to transmit a metadata block (MDB) from a self-describing module to a medical monitoring device, the MDB including at least identification (ID) data and corresponding configuration data; optionally, storing the MDB as an instance of MDB data in a memory of the medical monitoring device; associating the ID data from the MDB with the ID data of multiple subsystems of the medical monitoring device; and based on the result of the association between the ID data from the MDB and the ID data of the multiple subsystems, updating the configuration data of at least one subsystem of the medical monitoring device with the configuration data in the MDB.

[0006] The embodiments described in the present disclosure provide a non-transitory computer-readable recording medium in a self-describing module for updating data in a medical monitoring device. The non-transitory computer-readable recording medium stores one or more programs that, when executed by a processor, perform the steps of the method described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In the drawings, like reference numbers generally indicate identical, functionally similar, and / or structurally similar elements.

[0008] Figure 1is a schematic diagram of a system for updating data in a medical monitoring device using a self-describing module according to an embodiment of the present disclosure; Figure 2 The use of an embodiment according to the present disclosure is illustrated Figure 1 A method of updating data in a medical monitoring device using a self-describing module; Figure 3 FIG. 1 illustrates a method for updating a user using a self-describing module performed by a medical monitoring device according to an embodiment of the present disclosure. Figure 1 Method for monitoring data in a medical device in a system; Figure 4 The use of an embodiment according to the present disclosure is illustrated Figure 1 A method for implementing a self-describing module for updating data in a medical monitoring device in a system; Figure 5 A method for updating data in a medical monitoring device using a self-describing module according to an embodiment of the present disclosure is illustrated; Figure 6 is a schematic diagram of an exemplary self-describing module according to an embodiment of the present disclosure; Figure 7 is a schematic diagram of an exemplary medical monitoring device according to an embodiment of the present disclosure; Figure 8 is a schematic diagram of an exemplary monitoring device stand according to an embodiment of the present disclosure; and Fig. 9 is a schematic diagram of an exemplary server according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0009] Figure 1 FIG. 1 is a schematic diagram of a system for updating data in a medical monitoring device using a self-describing module. Figure 1 As shown in , the system comprises a self-describing module 1 , a medical monitoring device 2 , an optional monitoring device stand 3 and one or more servers 4 .

[0010] Will be in Figures 6 to 9 The discussion provides Figure 1 , an explanation of exemplary internal components of the self-describing module 1, medical monitoring device 2, optional monitoring device holder 3, and one or more servers 4 shown in . However, in general, the present disclosure contemplates that the self-describing module 1, medical monitoring device 2, optional monitoring device holder 3, and one or more servers 4 include electronic components or electronic computing devices that are operable to receive, transmit, process, store and / or manage data and information associated with the system, including any suitable processing device suitable for performing computing tasks consistent with the execution of computer-readable instructions stored in a memory or computer-readable recording medium.

[0011] In addition, any, all or some of the computing devices of the self-describing module 1, the medical monitoring device 2, the optional monitoring device bracket 3 and the one or more servers 4 can be suitable for executing any operating system, including Linux, UNIX, Windows Server, etc., as well as virtual machines suitable for virtualizing the execution of specific operating systems (including customized and proprietary operating systems). The self-describing module 1, the medical monitoring device 2, the optional monitoring device bracket 3 and the one or more servers 4 are further equipped with components for facilitating communication with other computing devices through one or more connections 5, 6, 7, 8, 9, 10. Connections 5, 6, 7, 8, 9, 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 in the system. In addition, the present disclosure also contemplates that connections 5, 6, 7, 8, 9, 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, wireless connections or other serial transmission connections and any combination thereof.

[0012] exist Figure 1 In the figure, a self-describing module 1, a medical monitoring device 2, an optional monitoring device holder 3, and one or more servers 4 connected by network connections 5, 6, 7, 8, 9, 10 are shown. Depending on the desired configuration, each of these components can include one or more computing devices. The self-describing module 1, the medical monitoring device 2, the optional monitoring device holder 3, and the one or more servers 4 may include one or more programmable data processors and a memory or memory location for storing software components. In the self-describing module 1, the memory includes a metadata block (MDB) 14, which will be further discussed below. 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).

[0013] In some embodiments, the self-describing module 1 is a patient monitoring module or a docking patient front-end module, which is configured to acquire and process data generated by at least one physiological sensor configured to monitor the physiological parameters of the patient. Process data generated by sensors (such as ECG electrodes, SPO2 sensors, blood pressure cuffs, apnea detection sensors, ventilators, and the like), which measure physiological parameters such as blood pressure, heart-related information, pulse oximetry, respiratory information, and the like. MDB 14 includes settings required by the physiological algorithm of the self-describing module 1. These include patient categories such as neonates, pediatrics, adults, etc. MDB 14 includes, for example, self-describing module 1 settings required by the physiological algorithm, such as user-changeable filter settings. User-changeable filter settings can include values ​​for limits set for alarms and the like. Having these values ​​in the self-describing module 1 allows updates and the like to occur through the self-describing module 1 (e.g., updates such as version revisions).

[0014] The self-describing module 1 can provide flexibility in several ways to take advantage of new functionality. Customers can adopt the latest algorithms, features, and software updates for parameter measurement devices without waiting for the release of new versions from the medical monitoring device 2. Users can configure the number and type of parameter measurement devices to meet different and changing clinical needs. The service method can be more unified than the currently provided service method, where versions, logs, self-tests, settings, history, and measurements of all parameter measurement devices are accessed remotely via the Internet.

[0015] MDB 14 may include data or information for communicating the self-describing configuration of self-describing module 1 to consumers such as medical monitoring device 2. MDB 14 may inform medical monitoring device 2 about what data is generated and additional attributes for various subsystems and display elements within medical monitoring device 2. MDB 14 may include multiple plug-ins, which are software interfaces for allowing communication of data of corresponding subsystems. Each plug-in may engage with medical monitoring device 2. Each plug-in may be implemented for each consumer of self-describing module 1 data. In addition, MDB 14 may include information about how to use the data generated by self-describing module 1, how to format the data, how often to update the data, how to display the data, and how to mark the data.

[0016] The MDB 14 may 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 may be included in the MDB 14 in the form of metrics. In addition, the MDB 14 supports at least one or more of the following: alarms, remote control of the self-describing module 1, service-related data retrieval, including device metadata, logs, 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.

[0017] The MDB 14 may also include a subset of the medical device communication standard that describes and communicates the status of the self-describing module 1. A nomenclature and encoding system from a standard such as IEEE 11073-10207 (Standard for Domain Information and Service Models for Service-Oriented Point-of-Care Medical Device Communications) may provide information about the status of the self-describing module 1. The MDB 14 may include a Medical Data Information Base (MDIB), which is a collection of data objects provided by a specific medical device, including description and status information.

[0018] In some embodiments, the medical monitoring device 2 is a patient monitor used to monitor various physiological parameters for a patient. The medical monitoring device 2 can be portable and travel with the patient to provide continuous monitoring during care. The medical monitoring device 2 is connected to one or more sensors such as ECG electrodes, SPO2 sensors, blood pressure cuffs, apnea detection sensors, respirators, and the like via a wired and / or wireless interface, and the sensors measure physiological parameters associated with the patient, such as blood pressure, heart-related information, pulse oximetry, respiratory information, and the like. Additional types of information can be transmitted by the medical monitoring device 2. The medical monitoring device 2 can process and / or display analog data derived from the patient.

[0019] The medical monitoring device 2 includes a plurality of subsystems 12. The plurality of subsystems 12 may include a subsystem for at least one graphical user interface (GUI) for trends, alarms, reports, networks, and the like. In this embodiment or another embodiment, the medical monitoring device 2 may include at least one metadata plug-in interface (MPI). Each of the plurality of subsystems 12 may include one of the MPIs, and each MPI may have a version associated with it. The MPI is engaged with the MDB 14 so that the plug-in of the MDB 14 may be associated with the MPI of the subsystem 12. Each of the MPIs may be updated with a new interface while leaving the interface already in place unchanged. The MDB 14 of the self-describing module 1 may include a plurality of plug-ins connected to the MPI. The medical monitoring device 2 may be connected to at least one patient sensor 11, such as an ECG electrode, an SPO2 sensor, a blood pressure cuff, an apnea detection sensor, a ventilator, and the like, which provides patient data to the medical monitoring device 2.

[0020] The MDB 14 may provide information to a consumer or user of the medical monitoring device 2 regarding what data and properties are being provided for the various subsystems, as well as enable display of elements within the medical monitoring device 2. The MDB 14 includes identification (ID) data for the various subsystems 12 in the medical monitoring device 2 and corresponding configuration data.

[0021] The monitoring device holder 3 may be an optional component. The monitoring device holder 3 may provide physical support, power, and conduits to one or more computer networks. In some embodiments, the monitoring device holder 3 may be connected when the medical monitoring device 2 is not being used when transporting a patient. The present disclosure contemplates that in some embodiments, the medical monitoring device 2 may be connected (e.g., connection 6) to the monitoring device holder 3. In these embodiments, the self-describing module 1 is connected to the monitoring device holder 3, and communications from the self-describing module 1 to the medical monitoring device 2 are established through the monitoring device holder 3 (e.g., connection 10). The following embodiments describe in more detail exemplary communications from and to the self-describing module 1 and the medical monitoring device 2 through the monitoring device holder 3.

[0022] Figure 2 A method for updating data in a medical monitoring device 2 using a self-describing module 1 is illustrated. In step S1, the self-describing module 1 transmits an MDB 14 to the medical monitoring device 2. The information provided in the MDB 14 includes a description of the metrics supported by the self-describing module 1. Figure 3 Steps S2-S4 describe the process performed by the medical monitoring device 2 after receiving the MDB 14. In step S2, the medical monitoring device 2 stores the MDB data as an instance of the MDB data 13 in the memory of the medical monitoring device 2. Figure 414. The medical monitoring device 2 is described in more detail in . Then, in step S3, the instance of MDB data 13 is used to associate the ID data from MDB 14 with the ID data of the plurality of subsystems 12. When the ID data is unknown to the medical monitoring device 2, the ID data can be ignored. In step S4, based on the result of the association between the two ID data, the configuration data in the instance of MDB 13 is used to perform an update of the configuration data for at least one of the plurality of subsystems 12. At runtime, the state of the measurement is changed in MDB 14 and received by the medical monitoring device 2. In some embodiments, step S2 is not necessary, and the medical monitoring device 2 transmits the information from MDB 14 over the network via one or more of the network connections 5, 6, 7, 8, 9, 10, instead of storing the MDB data as an instance in the memory of the medical monitoring device 2. Then in a subsequent step S3, in step S3, MDB data 14 is then used to associate the ID data from MDB 14 with the ID data of the plurality of subsystems 12.

[0023] In some cases, the user may wish to adjust the data provided by the MDB 14 and the self-describing module 1. An example of a change made by the user would be to adjust the limits of the alarm for a particular department. The medical monitoring device 2 includes a user interface for facilitating communication between the medical monitoring device 2 and the user. The user interface allows the user to input changes to the data. Return to Figure 2 The user can use the user interface to transmit updated subsystem data modifications made in the medical monitoring device 2 to the self-describing module 1, as shown in step S5. The updated subsystem modifications can be transmitted from the medical monitoring device 2 to the self-describing module 1, for example, with reference to physiological sensors monitoring the patient.

[0024] Figure 4 and Figure 5 The communication between the self-describing module 1 and the medical monitoring device 2 is shown. Figure 4 In the embodiment of the present invention, steps S6 to S8 are shown as potential initial steps in the communication process. First, communication can be established between the self-describing module 1 and the medical monitoring device 2 through a connection (e.g., connection 7) in step S6. Examples of connections include a USB port, an SPI port, an Ethernet port, or other similar connections. Once connected, the medical monitoring device 2 can then detect the self-describing module 1 in step S7. For example, the self-describing module 1 can have a universal driver associated with the self-describing module 1, and the driver can enable the medical monitoring device 2 to detect the self-describing module 1.

[0025] In step S8, each of the plurality of subsystems 12 in the medical monitoring device 2 may identify a readiness within each of the subsystems 12 for processing data. The identification of the readiness may occur based on a notification transmitted from each of the subsystems 12 of the medical monitoring device 2. The notification may be a ready signal transmitted from the medical monitoring device 2 to the self-describing module 1 once all of the plurality of subsystems 12 are activated and ready to communicate.

[0026] Figure 5 The diagram illustrates when the self-describing module 1 is disconnected from the medical monitoring device 2. Once there is a disconnection between the self-describing module 1 and the medical monitoring device 2, as in step S9, in an embodiment where an instance of the MDB 13 is stored, the instance of the MDB 13 stored in the medical monitoring device 2 is removed from the memory of the medical monitoring device 2. Removing the instance of the MDB 13 when there is a disconnection is a way to ensure that the medical monitoring device 2 always operates with the correct, up-to-date version of the MDB 14. Each time the self-describing module 1 is connected, the MDB 14 is transmitted to the medical monitoring device 2 by the self-describing module 1. Once the self-describing module 1 is reconnected to the medical monitoring device 2, the method as described herein is repeated.

[0027] For various reasons, the self-describing module 1 may be removed from the medical monitoring device 2. Examples of reasons for disconnection include, but are not limited to, updating the self-describing module 1 with a new version, new parameters, new algorithms, features or software. Updates to the medical monitoring device 2 may also be handled by updates to the self-describing module 1.

[0028] When new parameters are added to the self-describing module 1 within the MDB 14, updates are required in multiple subsystems in the medical monitoring device 2. Once the self-describing module 1 is reconnected or connected to the medical monitoring device 2 for the first time, all parameters present in the MDB 14 are provided in the MDB instance 13 stored in the medical monitoring device 2. Therefore, there is no need to replace or remove the medical monitoring device 2. In some embodiments, the medical monitoring device 2 can be placed in a service mode that is protected while new versions of the MDB 14 and MPI are being uploaded. In addition, in some embodiments where the MDB instance 13 is not stored, all parameters present in the MDB 14 are provided by the medical monitoring device 2 when transmitted.

[0029] The ID data from each plugin may include a namespace identifier for associating with the MPI of a particular subsystem 12 that supports a particular namespace. When a namespace is unknown to the medical monitoring device 2, the namespace may be ignored.

[0030] The self-describing module 1 can communicate with the user through the medical monitoring device 2 and the user interface of the medical monitoring device 2. In addition, as mentioned above, the self-describing module 1 communicates with the medical monitoring device 2 in various ways, such as but not limited to how to format the data, how often the data is updated, how the data should be displayed, and / or how the data should be labeled. A common set of connectors can be used between the self-describing module 1 and the medical monitoring device 2, which can reduce or eliminate the need for different variants for each monitor. In addition, the latest clinical measurement technology can be introduced in a timely manner through the update of the self-describing module 1, and the medical monitoring device 2 receives the self-describing module 1 through the method described in this article.

[0031] Figure 6 is a schematic diagram of an exemplary self-describing module according to an embodiment of the present disclosure. The present disclosure contemplates that the self-describing module 1 comprises an electronic component or electronic computing device operable to receive, transmit, process, store and / or manage data and information associated with the previously described systems and methods, including any suitable processing device adapted to perform computing tasks consistent with the execution of computer-readable instructions stored in a memory or computer-readable recording medium.

[0032] like Figure 6 As shown in , the exemplary self-describing module 1 includes one or more memories or memory locations, including a main memory 30, as well as an I / O interface 32, a user interface 33, a communication interface 34, one or more processors 35, and an optional power supply 31. The main memory 30 can be a random access memory (RAM), a memory buffer, a hard drive, a database, an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a read-only memory (ROM), flash memory, a hard disk, or any other various layers of memory hierarchy.

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

[0034] An optional power source 31 may be used to power various components of the self-describing module 1. The power source 31 may be self-contained, such as a battery pack, and / or the power source 31 may include an interface to be powered through an electrical outlet (either directly or through the medical monitoring device 2 and / or the monitoring device holder 3). In some embodiments, the self-describing module 1 may be powered and render information only when it is secured or otherwise connected to one or more of the medical monitoring device 2 and the monitoring device holder 3.

[0035] The I / O interface 32 may be an interface for enabling information to be passed between the self-describing module 1 and an external device such as a medical monitoring device 2 or an optional monitoring device stand 3 that requires a special communication link for interfacing with one or more processors 35. The I / O interface 32 may be implemented to accommodate a variety of connections to the self-describing module 1, including but not limited to a Universal Serial Bus (USB) connection, a Serial Peripheral Interface (SPI) connection, an Ethernet connection, a coaxial connection, a wireless connection, a High Definition Multimedia Interface (HDMI) connection, or other serial transmission connection or other known connections in the art for connecting to external devices.

[0036] The user interface 33 is implemented to allow communication between the user and the self-describing module 1. The user interface 33 includes, but is not limited to, a liquid crystal display (LCD), a cathode ray tube (CRT), a thin film transistor (TFT), a light emitting diode (LED), a high definition (HD), or other similar display devices with touch screen capabilities. Other types of input devices may also be used to provide interaction with the user. For example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback through a speaker, or tactile feedback), and input from the user may be received in any form, including acoustic, voice, or tactile input. The input device and microphone may be coupled to the internal bus 36 via the input device interface and transmit information via the internal bus 36. The speaker may be coupled to the internal bus 36 via the speaker interface and receive information via the internal bus 36. The self-describing module 1 may omit one or more of the display, display interface, input device, microphone, speaker, input device interface, and speaker interface. The communication interface 34 is implemented to communicate with the user via the communication interface 34. Figure 1 The present disclosure contemplates that the communication interface 34 includes software and / or hardware interface circuitry for establishing a communication connection with the rest of the system using both wired and wireless connections to establish connections to, for example, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a personal area network (PAN), and a wireless local area network (WLAN), a system area network (SAN), and other similar networks.

[0037] One or more processors 35 are used to control the general operation of the self-describing module 1. Each or 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. An internal bus 36 is used to establish communications between the components (e.g., 30-35) of the self-describing module 1.

[0038] Figure 7 is a schematic diagram of an exemplary medical monitoring device according to an embodiment of the present disclosure. The present disclosure contemplates that the medical monitoring device 2 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, including any suitable processing device adapted to perform computing tasks consistent with the execution of computer-readable instructions stored in a memory or computer-readable recording medium.

[0039] like Figure 7 As shown in , the exemplary medical monitoring device 2 includes one or more memories or memory locations, including a main memory 40, as well as an I / O interface 42, a user interface 43, a communication interface 44, one or more processors 45, and an optional power supply 41. The main memory 40 can be a random access memory (RAM), a memory buffer, a hard drive, a database, an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a read-only memory (ROM), flash memory, a hard disk, or any other various layers of memory hierarchy.

[0040] The main memory 40 can be used to store any type of instructions associated with algorithms, processes or operations for controlling the general functions of the medical monitoring device 2 (including the operation of multiple subsystems 12, storage of the MDB 13) and any operating system, such as Linux, UNIX, Windows Server or other custom and proprietary operating systems.

[0041] An optional power supply 41 may be used to power various components of the medical monitoring device 2. The power supply 41 may be self-contained, such as a battery pack, and / or the power supply 41 may include an interface to be powered by an electrical outlet (either directly or through the monitoring device stand 3).

[0042] The I / O interface 42 may be an interface for enabling information to be transferred between the medical monitoring device 2 and an external device such as a sensor or medical device for monitoring physiological parameters for a patient, or the self-describing module 1 or optional monitoring device holder 3, which requires a special communication link for interfacing with the one or more processors 45. The I / O interface 42 may be implemented to accommodate a variety of wired and / or wireless connections to the medical monitoring device 2, including but not limited to ECG electrodes, SPO2 sensors, blood pressure cuffs, apnea detection sensors, ventilators, and the like or a universal serial bus (USB) connection, a parallel connection, a serial connection, a coaxial connection, a wireless connection, a high-definition multimedia interface (HDMI) connection, an SPI connection, other serial transmission connections, or other known connections in the art for connecting to external devices.

[0043] The user interface 43 is implemented to allow communication between the user and the medical monitoring device 2. The user interface 43 includes, but is not limited to, a liquid crystal display (LCD), a cathode ray tube (CRT), a thin film transistor (TFT), a light emitting diode (LED), a high definition (HD), or other similar display devices with touch screen capabilities. Other types of input devices may also be used to provide interaction with the user. For example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback through a speaker, or tactile feedback), and input from the user may be received in any form, including acoustic, voice, or tactile input. The input device and microphone may be coupled to the internal bus 46 via the input device interface and transmit information via the internal bus 46. The speaker may be coupled to the internal bus 46 via the speaker interface and receive information via the internal bus 46. The medical monitoring device 2 may omit one or more of the display, display interface, input device, microphone, speaker, input device interface, and speaker interface. The communication interface 44 is implemented to directly or indirectly communicate via the internal bus 46. Figure 1 The monitoring device holder 3 in the system described in the foregoing is a software and / or hardware interface for establishing a connection between the medical monitoring device 2 and the server 4. The present disclosure contemplates that the communication interface 44 includes software and / or hardware interface circuitry for establishing a communication connection with the rest of the system using both wired and wireless connections to establish a connection to, for example, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a personal area network (PAN) and a wireless local area network (WLAN), a system area network (SAN) and other similar networks.

[0044] One or more processors 45 are used to control the general operation of the medical monitoring device 2. Each or one or more processors 45 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 device capable of executing any type of instructions, algorithms, or software for controlling the operation of the medical monitoring device 2. An internal bus 46 is used to establish communications between the components (e.g., 40-45) of the medical monitoring device 2.

[0045] Figure 8 is a schematic diagram of an exemplary monitoring device rack according to an embodiment of the present disclosure. The present disclosure contemplates that the monitoring device rack 3 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, including any suitable processing device adapted to perform computing tasks consistent with the execution of computer-readable instructions stored in a memory or computer-readable recording medium.

[0046] like Figure 8 As shown in , the exemplary monitoring device rack 3 optionally includes one or more memories or memory locations, including a main memory 50 as well as an I / O interface 52, a communication interface 53, optionally one or more processors 54, and an optional power supply 51. The main memory 50 can be a random access memory (RAM), a memory buffer, a hard drive, a database, an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a read-only memory (ROM), flash memory, a hard disk, or any other various layers of memory hierarchy.

[0047] The main memory 50 can be used to store any type of instructions associated with algorithms, processes or operations for controlling the general functions of the monitoring device rack 3 (including the operation of the monitoring device rack 3) and any operating system, such as Linux, UNIX, Windows Server or other custom and proprietary operating systems.

[0048] An optional power supply 51 may be used to power the monitoring device holder 3 and / or the various components of the medical monitoring device 2 and the self-describing module 1. The power supply 51 may be self-contained, such as a battery pack, and / or the power supply 51 may include an interface to be powered by an electrical outlet.

[0049] The I / O interface 52 may be an interface for enabling information to be passed between the monitoring device holder 3 and an external device such as a medical monitoring device 2 or a self-describing module 1 that requires a special communication link for interfacing with one or more processors 54. The I / O interface 52 may be implemented to accommodate a variety of connections to the monitoring device holder 3, including but not limited to a universal serial bus (USB) connection, a parallel connection, a serial connection, a coaxial connection, a wireless connection, a high-definition multimedia interface (HDMI) connection, an SPI connection, other serial transmission connections, or other known connections in the art for connecting to external devices.

[0050] The communication interface 53 is implemented to Figure 1 The present disclosure contemplates that the communication interface 53 includes software and / or hardware interface circuitry for establishing a communication connection with the rest of the system using both wired and wireless connections to establish a connection to, for example, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a personal area network (PAN), and a wireless local area network (WLAN), a system area network (SAN), and other similar networks.

[0051] An optional processor or processors 54 are used to control the general operation of the monitoring device rack 3. Each or the processor or processors 54 may be, but are 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 device capable of executing any type of instructions, algorithms, or software for controlling the operation of the monitoring device rack 3. An internal bus 55 is used to establish communications between the components (e.g., 50-54) of the self-describing module 1.

[0052] Fig. 9 is a schematic diagram of an exemplary system server according to an embodiment. Figure 8 The server 60 shown in FIG. Figure 1 The present disclosure also contemplates that the server 60 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, including any suitable processing device adapted to perform computing tasks consistent with the execution of computer-readable instructions stored in a memory or computer-readable recording medium.

[0053] like Fig. 9As shown in FIG, an exemplary server 60 includes a main memory 61, an I / O interface 62, a user interface 63, a network interface 64, and one or more processors 65. The main memory 61 can be a random access memory (RAM), a memory buffer, a hard drive, a database, an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a read-only memory (ROM), a flash memory, a hard disk, or any other various layers of memory hierarchy.

[0054] The main memory 61 may be used to store any type of instructions associated with algorithms, processes, or operations for controlling the general functionality of the server 60, as well as any operating system such as Linux, UNIX, Windows Server, or other custom and proprietary operating systems. The I / O interface 62 may be an interface for enabling information to be passed between the server 60 and external devices such as peripheral devices connected to the server 60 that require a special communication link for interfacing with the one or more processors 65. The I / O interface 62 may be implemented to accommodate a variety of connections to the server 60, including, but not limited to, a universal serial bus (USB) connection, a parallel connection, a serial connection, a coaxial connection, a wireless connection, a high-definition multimedia interface (HDMI) connection, an SPI connection, other serial transmission connections, or other known connections in the art for connecting to external devices.

[0055] The user interface 63 is implemented to allow communication between the user and the server 60. The user interface 63 includes, but is not limited to, a mouse, a keyboard, a liquid crystal display (LCD), a cathode ray tube (CRT), a thin film transistor (TFT), a light emitting diode (LED), a high definition (HD) or other similar display device with touch screen capability. Other types of input devices may also be used to provide interaction with the user. For example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback through a speaker, or tactile feedback), and input from the user may be received in any form, including acoustic, voice, or tactile input. The input device and microphone may be coupled to the internal bus 66 via the input device interface and transmit information via the internal bus 66. The speaker may be coupled to the internal bus 66 via the speaker interface and receive information via the internal bus 66. The exemplary server 60 may omit one or more of the display, display interface, input device, microphone, speaker, input device interface, and speaker interface. The network interface 64 is a software and / or hardware interface implemented to establish a connection between the server 60 and other servers in the system and also with the self-describing module 1, the medical monitoring device 2, the optional monitoring device bracket 3, such as Figure 1The present disclosure contemplates that the network interface 64 includes software and / or hardware interface circuitry for establishing a communication connection with the rest of the system using both wired and wireless connections to establish connections to, for example, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a personal area network (PAN), and wireless local area networks (WLAN), system area networks (SAN), and other similar networks.

[0056] One or more processors 65 are used to control the general operation of the server 60. Each or one or more processors 65 can be, but are 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, the medical monitoring device 2, and the optional monitoring device stand 3. An internal bus 66 is used to establish communication between the components (e.g., 61-65) of the server 60.

[0057] The present disclosure may be implemented as any combination of an apparatus, a system, an integrated circuit, and a computer program on a non-transitory computer-readable recording medium. One or more processors may be implemented as an integrated circuit (IC), an application specific integrated circuit (ASIC), or a large-scale integrated circuit (LSI), a system LSI, a super LSI, or a super LSI component that performs part or all of the functions of a secure conditional access architecture.

[0058] The present disclosure includes the use of a computer program or algorithm. The program or algorithm may be stored on a non-transitory computer readable medium for causing a computer such as one or more processors to execute Figure 1-5 For example, one or more memories store software or algorithms with executable instructions, and one or more processors can execute a set of instructions of the software or algorithms associated with executing the generation and processing of provisioning requests and provisioning messages, such as Figure 1-5 As described in .

[0059] 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 may be implemented in a high-level procedural language, an object-oriented programming language, a functional programming language, a logic programming language, or an assembly language or a machine language. The term computer-readable recording medium refers to any computer program product, apparatus or device for providing machine instructions or data to a programmable data processor, such as a magnetic disk, an optical disk, a solid-state storage device, a memory, and a programmable logic device (PLD), including a computer-readable recording medium that receives machine instructions as a computer-readable signal.

[0060] 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 may be used to carry or store desired computer readable program codes and any other medium that can be accessed by a general or special computer or a general or special processor in the form of instructions or data structures. Disks or discs as used herein include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks and blue discs, wherein disks usually reproduce data magnetically, and discs reproduce data optically with lasers. The above combinations are also included in the scope of computer readable media.

[0061] In one or more embodiments, use of the phrases "can," "capable," "operable to," or "configured to" refers to some device, logic, hardware, and / or element being designed in such a manner that the device, logic, hardware, and / or element can be used in a specified manner.

[0062] The subject matter of the present disclosure is provided as an example of a method and program for implementing features of a secure conditional access architecture. However, in addition to the features described above, additional features or variations are also contemplated. It is contemplated that implementation of the components and functionality of the present disclosure may be accomplished with any emerging technology, which may replace any of the technologies implemented above.

[0063] In addition, the above description provides examples and does not limit the scope, applicability or configuration set forth in the claims. Without departing from the spirit and scope of the present disclosure, changes may be made in the functions and arrangements of the elements discussed. Various embodiments may appropriately omit, replace or add various processes or components. For example, features described with respect to certain embodiments may be combined in other embodiments.

[0064] Various modifications to the 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 the disclosure. Throughout the disclosure, the terms "example," "example(s)" or "exemplary" indicate an example or instance, and do not imply or require any preference for the indicated example. Therefore, the disclosure is not limited to the examples and designs described herein, but is to be consistent with the widest scope consistent with the principles and novel features disclosed.

Claims

1. A method for updating data in a monitoring device support using a self-describing module, the method comprising: transmitting a metadata block (MDB) from the self-describing module to the monitoring device bracket using the communication interface, the MDB including at least identification (ID) data and configuration data; correlating the ID data from the MDB with the ID data of the plurality of subsystems of the monitoring equipment rack; as well as Based on the result of the association between the ID data from the MDB and the ID data of the plurality of subsystems, the configuration data of at least one subsystem of the monitoring device rack is updated with the configuration data in the MDB. The method of claim 1 , wherein the monitoring device holder is connected to at least one sensor.

3. The method according to claim 1, further comprising: The MDB is stored as an instance of MDB data in a memory of the monitoring device rack before the ID data from the MDB is associated with the ID data of the plurality of subsystems of the monitoring device rack.

4. The method according to claim 1, wherein: The monitoring device scaffold includes one or more metadata plugin interfaces (MPIs), and the MDB of the self-describing module includes a plurality of plugins connected to the MPIs. The method of claim 4 , wherein each MPI is part of a subsystem of the plurality of subsystems.

6. The method of claim 4, wherein the ID data comprises a namespace identifier for associating with an MPI of a subsystem supporting a particular namespace.

7. The method according to claim 1, further comprising: Before the MDB is transmitted from the self-describing module to the monitoring device support, communication is established between the self-describing module and the monitoring device support via the communication interface.

8. The method according to claim 1, further comprising: A self-describing module is detected which is connected to a monitoring device bracket via a communication interface.

9. The method according to claim 1, further comprising: A readiness status of each subsystem for processing data is identified based on a notification transmitted from each subsystem of the monitoring equipment rack.

10. The method according to claim 9, wherein: The notification is a ready signal transmitted from the monitoring device bracket to the self-describing module once all subsystems of the plurality of subsystems are ready to transmit.

11. The method according to claim 4, further comprising: The monitoring device rack is placed into service mode secured to enable uploading of new versions of the MDB and MPI.

12. The method according to claim 3, wherein: In response to the self-describing module being disconnected from the monitoring device rack, the instance of the MDB data from the self-describing module is removed from the memory of the monitoring device rack, and in response to the self-describing module being reconnected to the monitoring device rack, the method is repeated.

13. The method according to claim 12, wherein: At least algorithms, features and software are updated in the MDB of the self-describing module and reconnected to the monitoring device rack for updating the updated data from the MDB into at least one of the subsystems of the monitoring device rack.

14. The method according to claim 1, wherein: New parameters are added to the MDB and updated to multiple subsystems of the monitoring equipment rack.

15. The method according to claim 1, wherein: The MDB of a self-describing module includes a subset of the medical device communication standard to describe and communicate the status of the self-describing module.

16. The method of claim 1, wherein the self-describing module is a patient monitoring module configured to acquire and process data generated by at least one physiological sensor configured to monitor a physiological parameter of a patient.

17. The method according to claim 16, further comprising: Updated subsystem modifications in the monitoring device cradle from user input are transmitted to the self-describing module with reference to parameters of physiological sensors monitoring the patient.

18. A non-transitory computer-readable recording medium in each of a self-describing module and a monitoring device rack for updating data in a monitoring device rack, each non-transitory computer-readable recording medium storing one or more programs which, when executed by a corresponding processor, perform the method according to claim 1.

19. The method of claim 1, wherein: The ID data of the MDB determined to be associated with the ID of the subsystem of the monitoring device rack causes the subsystem to be updated with the corresponding configuration data, and ID data of an MDB that is determined not to be associated with any ID of the plurality of subsystems of the monitoring equipment rack causes the ID data and its corresponding configuration data to be ignored by the monitoring equipment rack.

20. The method of claim 1, wherein the ID data comprises a plurality of IDs, each ID having corresponding configuration data for updating a different one of the plurality of subsystems.

21. The method of claim 1, wherein the corresponding configuration data includes at least one setting that configures a physiological algorithm according to a user-changeable filter setting.

22. The method of claim 21, wherein the user-changeable filter settings are settings adjusted according to the patient's age demographics.

Images