Abstract: A system and method for communicating patient monitor data with priority in a clinical network is disclosed herewith. The method of comprises: classifying patient monitor data based on the nature of the data and obtaining an initial priority information by a patient monitor, based on at least the unit type including the unit name from where the patient monitor is being operated. The method further comprises: broadcasting an alarm generated by the patent monitor and communicating dynamic priority information to the patient monitor by a server, the dynamic priority information being calculated based on the nature of the alarm and the unit type from where the patient monitor is being operated. Further comprises: configuring the patient monitor with the dynamic priority information; and sending the data by the patient monitor configured with the dynamic priority information.
FIELD OF INVENTION
[0001] This invention relates generally to communication methods and systems in a clinical network and more specifically to communicating patient data in a clinical network with priority.
BACKGROUND OF INVENTION
[0002] Consider a hospital where the communication infrastructure is serving the network connectivity for different business applications not limiting to healthcare related information. The network infrastructure in the hospitals might be used by the Finance Department, Human Resource Department, House Keeping Department, General Internet browsing, and primarily for the clinical information. The clinical information on the network infrastructure may be used to view the real time clinical waveforms, parameters and alarms; archived trends and alarms, diagnostic images, patient demographic information, clinical print data, etc.
[0003] In a hospital, a patient may be monitored at different phases of recovery. Based on the condition of the patient, he would be admitted/relocated in different units/wards within the hospital. Those units could be General ward, Intensive care Unit (ICU), Critical Care Unit (CCU), Operation Theatre, Post Surgery Units, Pre-Surgery Units, etc. It is essential that, a patient admitted in ICU or CCU must be attained with special care compared to a patient in the General ward. This is only one such example, there could be different priorities of Units / Wards within a hospital. Further, a patient with critical alarms on physiological parameters like ECG, Invasive Blood Pressure, Non-Invasive Blood Pressure, Sp02, Cardiac Output, Respiration, Sv02, End-Tidal C02, ICG, EEG, BIS parameters must also be attained with a special care, as compared to a patient with no critical alarms. As a result, the data sent over the network from such patient monitors is much more critical as compared to the other patients.
[0004] Generally patient monitors are used in hospital to monitor various patients and the patient monitors are networked in the clinical network. The patient monitors communicates the alarm generated based on patient's condition and these alarms are communicated using the clinical network. The data from the patient monitor needs to be sent with priority compared to other data in the network. Especially critical information such as any critical alarm for a clinically very relevant parameter needs to be communicated with priority than the data from an HR department. The patient monitors or any commutating device sends the data with an IP header, that facilitates marking the data with priority. Generally patient monitors are assigned with a priority and the data from the patient monitor is being sent with that priority. However depending on the situation such as occurrence of a critical alarm, the priority of the patient monitor needs to be changed. However currently the patient monitors use pre-defined static priority values for the sending the data, irrespective of how critical the patient data is at different scenarios. For example, whenever the network is getting flooded with the high priority data, the packet queue in the communicating network equipments might get congested and even the high priority packets are dropped. Thus it will be useful to send the data with dynamic priority. Further, whenever the network is flooded with the low priority packets, it shows in-efficient usage of high priority queues of the communication equipment.
[0005] It means that the data on the network, from a patient in high priority unit and with critical alarms, have to be treated with highest priority when sent over the clinical network.
[0006] Thus there exist a need to have a method and system for communicating clinical information of a patient in a clinical network with priority.
SUMMARY OF INVENTION
[0007] The above-mentioned shortcomings, disadvantages and problems are addressed herein which will be understood by reading and understanding the following specification.
[0008] One embodiment of the present invention provides a method of communicating patient monitor data with priority in a clinical network. The method comprises: classifying patient monitor data based on the nature of the data; obtaining an initial priority information by a patient monitor, based on at least the unit type including the unit name from where the patient monitor is being operated; broadcasting an alarm generated by the patent monitor; communicating dynamic priority information to the patient monitor by a server, the dynamic priority information being calculated based on the nature of the alarm and the unit type from where the patient monitor is being operated; configuring the patient monitor with the dynamic priority information; and sending the data by the patient monitor configured with the dynamic priority information.
[0009] In another embodiment, a healthcare communication system is disclosed. The system comprises: plurality of patient monitors networked in a clinical network; a server networked in the clinical network, wherein the patient monitors and the server follow a client server model relation and are configured to dynamically prioritize patient monitor data based on the clinical relevance before communicating the same through the network; at least one patient interface module associated with the patient monitor configured to: communicate an initial priority information request packet having unit name and bed name information and broadcasting an alarm generated by the patient monitor; and communicate the patient monitor data in the network using dynamic priority information based on the nature of the patient data; at least one server interface module associated with the server, configured to: communicate the initial priority information packet with priority information corresponding to nature of data and type of unit to which the patient monitor is associated; dynamically generate dynamic priority information packet based on unit type and nature of the alarm and communicate the dynamic priority information ; and a communication channel through which the information packets are communicated.
[0010] Various other features, objects, and advantages of the invention will be made apparent to those skilled in the art from the accompanying drawings and detailed description thereof.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] FIG.1 is a schematic of a clinical network as described in various embodiments of the invention;
[0012] FIG.2 shows an IP header used in a patient monitor data communication described in various embodiments of the invention;
[0013] FIG. 3 is a state diagram indicating the stages involved in a patient monitor data communication as described in an embodiment of the invention;
[0014] FIG. 4 is a flowchart illustrating a method of communicating patient related information with priority, as described in an embodiment of the invention;
[0015] FIG. 5 is a flowchart illustrating a method of obtaining the initial priority information by the patient monitor, as described in an embodiment of the invention;
[0016] FIG. 6 is a sequence diagram for obtaining the initial priority information by the patient monitor, as described in an embodiment of the invention;
[0017] FIG. 7 is a flowchart illustrating a method of communicating dynamic priority information by the server, as described in an embodiment of the invention;
[0018] FIG. 8 is a sequence diagram for communicating dynamic priority information by the server, as described in an embodiment of the invention;
[0019] FIG. 9 is a block diagram of healthcare communication system, as described in an embodiment of the invention;
[0020] FIG. 10 shows structure of an initial priority information request packet as described in an embodiment of the invention;
[0021] FIG. 11 shows structure of a dynamic priority information packet described in an embodiment of the invention;
[0022] FIG. 12 shows initial priority mapping table as described in an embodiment of the invention;
[0023] FIG. 13 shows priority status table as described in an embodiment of the invention; and
[0024] FIG. 14 shows dynamic priority mapping table as described in an embodiment of the invention.
DETAILED DESCRIPTION OF INVENTION
[0025] In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific embodiments that may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the embodiments, and it is to be understood that other embodiments may be utilized and that logical, mechanical, electrical and other changes may be made without departing from the scope of the embodiments. The following detailed description is, therefore, not to be taken as limiting the scope of the invention. To the extent that the figures illustrate diagrams of the functional blocks of various embodiments, the functional blocks are not necessarily indicative of the division between hardware circuitry. Thus, for example, one or more of the functional blocks (e.g., processors or memories) may be implemented in a single piece of hardware (e.g., a general purpose signal processor or a block of random access memory, hard disk, or the like). Similarly, the programs may be stand alone programs, may be incorporated as subroutines in an operating system, may be functions in an installed software package, and the like. It should be understood that the various embodiments are not limited to the arrangements and instrumentality shown in the drawings.
[0026] Embodiments of the present invention provide a method and system for communicating clinical relevant patient information with priority in a clinical network. The method and system provides a solution to identify priority required for patient related
information to be sent on a clinical network based on a unit type to which the patient is currently admitted. The method also suggests dynamically changing the priority required to send patient information, based on the nature of the alarm generated based on the patient's physiological conditions.
[0027] The expressions clinical relevant information, patient related information, patient monitor data etc indicate any data that's related to the patient. The patient monitor may monitor various clinical relevant parameters and generate an alarm based on the monitored parameter. Generally, the patient monitor could be any device that is used in a clinical network to gather patient information and communicate the same in the network. The tern client refers to patient monitor that are having client application and the server refers to any computer system used to run server application, thus patient monitor and server working in a client-server model. Central stations are the best suited where server application may be run.
[0028] FIG.1 is a schematic of a clinical network 100 described in various embodiments of the invention. The clinical network 100 includes plurality of patient monitors 115 networked. A hospital can have different units 110 such as General ward, ICU, CCU, Operation Theatre, Post Surgery Units, Pre-Surgery Units. Patient information sent from patient monitors associated to various units 110 have to be prioritized based on their name or type. For example, unit type ICU has to be prioritized over unit type General ward and if there are multiple ICUs such as ICU1 and ICU2 in a hospital, these units 110 need to be prioritized based on the relevance of the units 110. Patient monitors 115 may be configured to measure various patient parameters such as ECG, Invasive Blood Pressure, Non-Invasive Blood Pressure, Sp02, Cardiac Output, Respiration, Sv02, End-Tidal C02, ICG, EEG, BIS. Some of the parameters may be clinically very relevant and critical and hence the data communication needs to be prioritized based on the clinical relevance of the parameter. All the patient monitors 115 that are located at different units 110 in a hospital are monitored by central station 120 such as Nurse station. Each central station 120 may act as a server 125 which is capable of providing the dynamic priority settings and initial priority settings or information to the patient monitors as described in various embodiments below. The patient monitors 115 needs to communicate with the central station 120 very often. The patient monitors 115 and the central stations 120 communicate in a client server model. The patient monitors 115 operate-as a client and the central station 120 behave as the server 125.
[0029] For example, if a patent monitor 115 in an ICU unit 110 is monitoring the ECG waveforms, based on the variations in the waveform the patient monitor 115 will be generating alarms and communicating the same to the central station 120 through a communication channel 130. The communication channel 130 could include wirelesses or wired network including Ethernet, Internet, LAN, WAN such as LAN, WLAN etc. however the communication channel need not be limited to these. The communication channel 130 and the patient and the various units are linked through digital communicating equipments 135 such as switches and routers. These communicating equipments 135 identify the priority setting of the data before communicating the same in the network 100.
[0030] FIG.2 shows an IP header used in a patient monitor data communication described in various embodiments of the invention. The data is sent in the form of data packets in a clinical network 100 (shown in FIG.1). The data packet 200 sent by a patient monitor 115 (shown in FIG.1) in the clinical network 100 (shown in FIG.1) has to be recognized with priority, by the data communicating equipments 135 (shown in FIG.1). Generally a six bit Differentiated Service Code Point (DSCP) field 215 of an IP header 210 is used to indicate the priority values or settings of the data packet 200. The higher the DSCP 215 value for the data packet 200, higher is the security feat the possibility of data packet 200 reaching to its destination with minimal data loss and delay. Each data packet 200 is sent with the IP header 210 and the IP header 210 has the 6 bit DSCP field 215 indicating the priority of the data packet 200.
[0031] In an embodiment, the patient monitor 115 (shown in FIG.1) is configured to send the patient data on the clinical network 100 (shown in FIG.1) with the dynamically varying DSCP field 215 values. The DSCP field 215 values are used by the DCE equipments 135 (shown in FIG.1) like switches and routers for prioritizing the data packets 200 while forwarding. The DSCP field 215 values dynamically changes the priority of the data packet 200 based on the nature of the alarm generated relating to the patient condition and unit type.
[0032] FIG. 3 is a state diagram indicating the stages involved in a patient monitor data communication as described in an embodiment of the invention. Consider the Idle state, 310 of patient monitor 115 (shown in FIG.1). This state is when no patients are associated with the patient monitor 115. Once a patient is admitted in a particular unit, a patient monitor 115 (shown in FIG.1) will be initialized and associated with the patient and a unit. Thus the patient monitor 115 (shown in FIG.1) will be linked to a bed name and unit name or type. When the patient monitor is initialized or whenever unit type of patient monitor is changed, it moves to stage 1 indicated by reference number 320. At Stage 1, the patient monitor 115 requests for an initial priority setting. The initial priority request is raised when the patient monitor 115 is initialized or when there is a change in the type of unit to which the patient monitor 115 is associated. Stage 2 is initiated when an alarm is raised by the patient monitor 115. In Stage 2, the dynamic priority setting for the patient monitor is a computed and communicated to the patient monitor. Once the patient gets discharged, the patient monitor returns to Idle stage 310.
[0033] FIG. 4 is a flowchart illustrating a method of communicating patient related information with priority, as described in an embodiment of the invention. At step 410, patient monitor data is classified based on the nature of the data. The patient monitor data includes the data being sent to and from the patient monitor to any system in the clinical network. The examples of the patient monitor data includes ECG, Invasive Blood Pressure, Non-Invasive Blood Pressure, Sp02, Cardiac Output, Respiration, Sv02, End-Tidal C02, ICG, EEG, BIS parameters. The patient monitor data is classified based on the nature of the data. The nature of the data includes the frequency, timing and the clinical relevance of the patent monitor data. The frequency of the data includes the interval by which the patient monitor monitors a clinical parameter and the timing of the data includes whether the data is real time data or not. The clinical relevance of the data includes the severity or clinical relevance of the parameter being monitored by the patient monitor. For example, there are certain parmaters, which are of high clinical relevance. In an example, the patient monitor data is may be classified as Clinical Real Time Data (CRTD), Clinical Non Real Time Data (CNRTD) and Non Clinical Non-real Time Data (NCNRTD).
[0034] At step 420, initial priority information is obtained by a patient monitor from a server. The initial priority information is sent to the patient monitor by the server based on the unit type from where the patient monitor is being operated. Initial priority information is communicated corresponding to each data classification done based on dynamic nature of the patient monitor data as in step 410. The unit type indicates the unit name from where the patient monitor is operated and patient monitor is assigned with a priority based on the nature of the patient admitted or by any other predefined criteria. This step is explained in detail with reference to FIG. 5. In an embodiment, only patient monitors that obtain the initial priority information are eligible for the dynamic priority information from the server. At step 430, the patient monitor is configured with the initial priority information and as and when an alarm is generated by the patient monitor, the patient monitor broadcasts the alarm into the clinical network.
[0035] At step 440, the server determines dynamic priority information upon receipt of the alarm by the patient monitor. The server determines the dynamic priority information based on the alarm condition and the unit type and the priority information is communicated to the patient monitor. This step is explained in detail with reference to FIG. 7. At step 450, the patient monitor is configured with the dynamic priority information and the data is sent by the patient monitor, which is configured with the dynamic priority information, as at step 460.
[0036] FIG. 5 is a flowchart illustrating a method of obtaining the initial priority information by the patient monitor, as described in an embodiment of the invention. At
step 510, a patient is associated or admitted in a unit and is associated with a patient monitor. The unit may be selected based on the patient's condition and the suitable patient monitor is connected with the patient to monitor different parameters of the patient. At step 520, the patient monitor is initiated and the patient monitor communicates an initial priority requirement to the server. The patient monitor communicates the unit type to which the patient monitor is associated to the server. The initial priority requirement is sent in the form of data packet through the clinical network. At step 530, the patient monitor awaits the initial priority information from the server. The patient monitor waits for a predefined time for the initial priority information from the server and check is made continuously for the initial priority information as at step 540. If the server is not responding or if the patient monitor fails to obtain the initial priority information from the server as at step 550, the patient monitor uses the default priority setting and raises an alert or a warning message indicating the same. At step 560, the patient monitor obtains the initial priority information from the server. The server communicates the initial priority information based on the unit type. Also the server will be communicating the priority information corresponding to the dynamic nature of the patient monitor data. The patient monitor is configured with the initial priority information received from the server, as in step 570. Whenever there a change in the unit type as at step 580, it sends initial priority requirement to the server. For example, a portable patient monitor may be transferred from a high priority unit to a low priority unit. If there is a change in the unit type, the patient monitor obtains the initial priority information again through the steps 520 to 570. Once the patient monitor is configured with the initial priority information and if there is no change in the unit type, the process ends as at step 590.
[0037] FIG. 6 is a sequence diagram for obtaining the initial priority information by the patient monitor, as described in an embodiment of the invention. A patient monitor 610 initiates the process and sends an initial priority request 615 to a server 620. The initial priority request 615 includes the unit type as well. The server 620 provides the initial priority information 625 based on the unit type and the dynamic nature of the patient monitor data. The server 620 maintains an initial priority mapping table indicating the unit type and priority values corresponding to dynamic nature of the patient monitor data. The server 620 provides the initial priority information 625 from the initial priority mapping table and the table will be described with reference to FIG. 12.
[0038] FIG. 7 is a flowchart illustrating a method of communicating dynamic priority information by the server, as described in an embodiment of the invention. At step 710, the server receives an alarm broadcasted by a patient monitor. The patient monitor generates alarm based on the patient parameter being monitored. At step 720, the server determines dynamic priority information. In an embodiment, the dynamic priority information is determined based on the nature of the alarm and the unit type. At step 730, the determined dynamic priority information is compared with existing priority information available in the priority status table. The priority status table indicates the current priority values assigned to bed name and unit type. The priority status table is explained with reference to FIG. 13. Any change in the priority information is identified at step 740 and based on the same the method further identifies the steps to be followed. If there is change in the determined dynamic priority information from the existing priority information in the priority status table, the priority status table is updated as in step 750. At step 760, the server maintains a dynamic priority mapping table with the dynamic priority information. The dynamic priority mapping table is explained with reference to FIG. 14. At step 780, the determined dynamic priority information is communicated to the patient monitor. At step 790, a check is performed to identify any pending request from the patient monitor for any update on the priority values. One such request is, if there are any changes made in the dynamic priority mapping table locally in the server, the same will be communicated to patient monitor. If there is a difference between the If there is any pending request, the dynamic priority information is computed through steps 720 to 770. If there are pending request or there is no changes made in the dynamic priority mapping table from the existing settings of priority information in the patient monitor, the method ends the process of computing and communicating the dynamic priority information to the patient monitor, as at step 795.
[0039] FIG. 8 is a sequence diagram for communicating dynamic priority information by the server, as described in an embodiment of the invention. The patient monitor 810 initiates the process and broadcasts an alarm in the network 815. The server 820 upon receipt of the alarm from the patient monitor 810, determines the dynamic priority information for the patient monitor based on the nature of the alarm and the unit type. The server 820 further updates the Priority Status Table. The server 820 communicates the dynamic priority information to the patient monitor 825. Further the patient monitor 810 could request for additional priority updates 818 one such example is mentioned in 0038 and the server 820 may communicate the dynamic priority information as per the request by the Patent monitor 810.
[0040] FIG. 9 is a block diagram of healthcare communication system 900, as described in an embodiment of the invention. The healthcare communication system 900 is configured to communicate patient monitor data with priority in a clinical network 940. Patient monitor 910 includes plurality of patient monitors assigned to various patients or beds names at various unit types. All the patient monitors are networked in the clinical network 940. The patient monitor 910 communicates to a server 920 through communication channel 930. The server 920 is also networked in the clinical network 940 and could be part of a central station. The communication channel 930 could be wireless or wire networking channels to facilitate communication among various patient monitors 910 and server 920 networked in the clinical network 940.
[0041] The patient monitors 910 are provided with a patient interface module 915. The patient interface module 915 is configured to communicate an initial priority information request packet having unit name and bed name information to the server 920 and is further configured to broadcast an alarm generated by the patient monitor 910. The patient interface module 915 further receives the dynamic and initial priority information from the server 920 and configures the patient monitor 910 with the appropriate priority information. The patient interface module 915 primarily facilitates the communication between the patient monitor 910 and the server 920.
[0042] The server 920 is further provided with a server interface module 925, the server interface module 925 interacts with the patient interface module 915 to facilitate communication between the patient monitor 910 and the server system 920. The server interface module 925 is configured to communicate the initial priority information packet with priority information corresponding to nature of data and type of unit to which the patient monitor 910 is associated. For this, the server interface module 925 accesses the initial priority mapping table and selects the priority values corresponding to the unit type. In an embodiment, the server interface module 925 is configured to maintain a initial priority mapping table storing priority values corresponding to the dynamic nature of the patient monitor data for each unit name and is configured to provide the initial priority information packet from the table upon receipt of the initial priority information request packet from the patient monitor 910. The server interface module 925 is configured to update the priority status table based on the initial priority information.
[0043] The server interface module 925 is further configured to dynamically generate dynamic priority information packet based on unit type and nature of the alarm and communicate the dynamic priority information to the patient monitor 910. The server interface module 925 is configured to compare the dynamic priority information with the priority information in the patient status table, before communicating the same to the patient monitor 910. The server interface module 925 is further configured to maintain a dynamic priority mapping table. The server interface module 925 is configured to update the priority status table based on the dynamic priority information. If there is a difference in the newly computed dynamic priority information and priority status table, only then updates priority status table and communicates the same to patient monitor.
[0044] Both patient interface module 915 and the server interface module 925 could be associated with a processor of the patient monitor and server respectively (not shown).
[0045] Embodiments of the present invention can comprise software or firmware instructing a computer or an embedded system to perform certain actions. Some embodiments of the present invention, patient monitor comprise stand-alone system that
includes memory, a display, and processor subsystems along with the patient monitoring subsystems 910. Whether a stand-alone system or a healthcare communication system is used, software and/or firmware (hereinafter referred to generically as "software") can be used to instruct the computer to perform the inventive combination of actions described herein. Portions of the software may have specific functions, and these portions are herein referred to as "modules". However, in some embodiments, these modules may comprise one or more electronic hardware components or special-purpose hardware components that may be configured to perform the same purpose as the software module or to aid in the performance of the software module. Thus, a "module" may also refer to hardware or a combination of hardware and software performing a function.
[0046] The modules may include dedicated hardware, software and/or firmware for performing information processing, or a combination of dedicated hardware and software, or software in combination with a general purpose processor, or a digital signal processor. Once the requirements for such software and/or hardware and/or dedicated hardware are gained from an understanding of the descriptions of embodiments of the invention contained herein, the choice of any particular implementation may be left to a hardware engineer and/or software engineer.
[0047] In an embodiment, the server 920 and the patient monitor 910 may be associated with a memory (not shown). The memory in the server is used to store the initial priority mapping table, priority status table and dynamic priority mapping table. The memory may include, for example, random access memory (RAM), flash memory, or read-only memory. For purposes of simplicity, devices that can read and/or write media on which computer programs are recorded are also included within the scope of the term "memory."
[0048] FIG. 10 shows structure of an initial priority information request packet 1000 as described in an embodiment of the invention. The patient monitor 115 (shown in FIG.1) communicates an initial priority request packet 1000 to a server 125 (shown in FIG.1). The request is communicated in the form of data packets 1000 and includes Payload
1010, User Datagram Protocol (UDP) Header 1020 and Internet Protocol (IP) header 1030. The Payload 1010 includes unique Identification Number (ID), bed name, unit type, type of packet. Using the information in Payload 1010 the server 125 identifies the unit name and based on the same, the server 125 provides the initial priority information. The UDP header 1020 includes the source and destination port information for the packet 1000 and the IP header 1030 includes the IP address for the patient monitor and the broadcast IP address.
[0049] FIG. 11 shows structure of a priority information response packet 1100 described in an embodiment of the invention. The priority information packet could be initial priority information packet or the dynamic information priority packet. In both cases, the packet consists similar information. The priority information packet comprises Payload 1110, UDP Header 1120 and the IP Header 1130. The Payload includes the unique Identification Number (ID), bed name, unit name, type of packet and these are received by the server from the initial priority information request packet. In addition to this information, the Payload further includes, priority values corresponding to various types of patient monitor data. In case of dynamic priority information packet, the priority values will be based on the alarm condition and the unit type. Wherein the priority values for an initial priority information data packet will be based only on the unit type. The UDP header includes the source and destination information and the IP header includes the IP address for source and destination.
[0050] FIG. 12 shows an initial priority mapping table 1200 as described in an embodiment of the invention. The initial priority mapping table 1200 includes unit name 1210 and corresponding priority values 1220 based on the dynamic nature of the patient monitor data. As explained earlier, the patient data is classified into CRTD, CNRTD and NCNRTD based on the frequency, timing and clinical relevance of the patient monitor data. The clinician defines priority values to be used by each unit type/ name 1210 and the server maintains this table. If there is a need to change the priority requirement of any unit type, the clinician must update the initial priority mapping table. Thus the initial priority table 1200 is maintained in the server and administered by the clinician. The initial priority table 1200 has unit type 1210 or the unit name and corresponding to each data types 1230, certain priority values 1220 are provided in the table 1200. Upon receiving the initial priority request, the sever obtains the initial priority information from the initial priority mapping table 1200 and sends to the patient monitor in the form of data packet. The server obtains the initial priority information by picking priority values 1220 against unit name 1210 from the initial priority mapping table 1200.
[0051] FIG. 13 shows priority status table 1300 as described in an embodiment of the invention. The priority status table 1300 is administered and maintained by the server 125 (shown in FIG.1). The server 125 the priority status table 1300 maintaining current priority value assigned against each bed name 1340 and unit name/type 1310. The priority status table 1300 will indicate the current priority values 1320 for a patent monitor 115 (shown in FIG.1) corresponding to various data types 1330 of the patient monitor data. Each time the dynamic priority information is generated by the server 125, the information is compared with the priority values in the priority status table 1300. The server 125 communicates the dynamic priority information to the patient monitor 115, only if the computed dynamic priority information varies from the existing values in the priority status table 1300. The priority status table 1300 is updated by the server 125, whenever the dynamic priority information is sent to the patient monitor 115. Thus the priority status table 1300 gives the currently priority information for the patient monitor 115.
[0052] FIG. 14 shows dynamic priority mapping table 1400 as described in an embodiment of the invention. The dynamic priority information is determined based on the alarms at the moment and the unit type to which the patient monitor is associated. The clinician maintains dynamic priority mapping table in the server 1400. The table 1400 comprises unit name 1410, computed priority values 1420 corresponding to dynamic nature of the patient monitor data 1430. The table 1400 further includes possible alarm conditions 1440, different clinical relevant parameter 1450 and the severity of the alarm
1460 and. The priority values 1420 are determined based on the nature of the alarm including severity of alarm for a parameter and clinical relevance of the parameter being monitored. Optionally, the dynamic priority mapping table 1400 includes the bed name.
[0053] The advantages of the system and method comprises that the clinicians would be able to view the patient waveforms and other physiological parameters at central stations or other patient monitors without break in waveforms or loss in data. Essential and vital alarms might not be missed out to be viewed or to be archived at the central stations. Further, a clinician can assign different priorities to the patients based on the ward / unit where the patient is admitted. The method assures remote bed view with minimal data loss at the critical conditions of the patients.
[0054] Further, adaptive prioritizing the patient data packets would prioritize the packets based on the need. And thus it would effectively minimize the packet drops and delays for the Patient data requiring critical care. The caretakers, clinicians, doctors, nurses view the real time patient physiological data at different locations in hospitals. The real time data needs to be available at the viewed points without packet drops and delays. This technique would balance the data into different priorities in the traffic, avoiding traffic congestion in a particular queue of the communication equipments
[0055] Thus various embodiments of the invention describe a method and system for communicating patient monitor data with priority in a clinical network.
[0056] As used herein, an element or step recited in the singular and proceeded with the word "a" or "an" should be understood as not excluding plural elements or steps, unless such exclusion is explicitly stated. Furthermore, references to "one embodiment" of the present invention are not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the recited features. Moreover, unless explicitly stated to the contrary, embodiments "comprising" or "having" an element or a plurality of elements having a particular property may include additional such elements not having that property. Moreover, the terms "computer" and "processor" are used
interchangeably herein to refer to either specialized hardware to perform digital signal processing, control, data manipulation, and/or calculations, or a general purpose computer that can be programmed to perform the same functions and/or adapted to interface with external digital signals.
[0057] Exemplary embodiments are described above in detail. The assemblies and methods are not limited to the specific embodiments described herein, but rather, components of each assembly and/or method may be utilized independently and separately from other components described herein. Further the steps involved in the workflow need not follow the sequence in which there are illustrated in figures and all the steps in the work flow need not be performed necessarily to complete the method.
[0058] While the invention has been described with reference to preferred embodiments, those skilled in the art will appreciate that certain substitutions, alterations and omissions may be made to the embodiments without departing from the spirit of the invention. Accordingly, the foregoing description is meant to be exemplary only, and should not limit the scope of the invention as set forth in the following claims.
I Claim:
1. A method of communicating patient monitor data with priority in a clinical
network comprising:
classifying patient monitor data based on the nature of the data;
obtaining an initial priority information by a patient monitor, based on at least the unit type including the unit name from where the patient monitor is being operated;
broadcasting an alarm generated by the patent monitor;
communicating dynamic priority information to the patient monitor by a server, the dynamic priority information being calculated based on the nature of the alarm and the unit type from where the patient monitor is being operated;
configuring the patient monitor with the dynamic priority information; and
sending the data by the patient monitor configured with the dynamic priority information.
2. The method as claimed in claim 1, wherein the patient monitor data includes data
generated and received by the patient monitor and the nature of the data includes
frequency rate, timing and clinical relevance of the data.
3. The method as claimed in claim 1, wherein the step of obtaining the initial
priority information by the patient monitor comprises:
communicating an initial priority requirement by the patient monitor to the server upon initiating the patient monitor;
communicating the unit type from where the patient monitor is being operated to the server;
obtaining the initial priority information corresponding to different types of data from the server, the server provides the initial priority information based on the unit type; and
configuring the patient monitor based on the initial priority information.
4. The method as claimed in claim 1, wherein the method further comprises: maintaining an initial priority mapping table by the server indicating the unit type and priority values corresponding to dynamic nature of the patient monitor data.
5. The method as claimed in claim 1, wherein the step of broadcasting an alarm comprises:
generating an alarm by the patient monitor based on patient condition; and broadcasting alarm condition in the network.
6. The method as claimed in claim1, wherein the step of communicating dynamic
priority information to the patient monitor by the server comprises:
receiving the alarm broadcasted by the patient monitor;
computing dynamic priority information based on the alarm condition and the unit type ; and
checking dynamic priority information with current priority information; and
communicating the dynamic priority information to the patient monitor.
7. The method as claimed in claim 6, further comprises updating a priority status table with dynamic priority information corresponding to the unit type and the bed name in the unit type.
8. The method as claimed in claim 6, further comprises maintaining a dynamic priority mapping table having unit name, different clinical relevant parameter, possible alarm conditions, and computed priority information corresponding to dynamic nature of the patient monitor data, the priority information being computed based on the nature of the alarm including severity of alarm for a parameter and clinical relevance of the parameter being monitored.
9. The method as claimed in claim 8, wherein the dynamic priority mapping table further comprises: priority values corresponding to bed name in a unit type for different nature of alarms.
10. A healthcare communication system comprises:
plurality of patient monitors networked in a clinical network;
a server networked in the clinical network, wherein the patient monitors and the server follow a client server model relation and are configured to dynamically prioritize patient monitor data based on the clinical relevance before communicating the same through the network;
at least one patient interface module associated with the patient monitor configured to:
communicate an initial priority information request packet having unit name and bed name information and broadcasting an alarm generated by the patient monitor; and
communicate the patient monitor data in the network using dynamic priority information based on the nature of the patient data;
at least one server interface module associated with the server, configured to:
communicate the initial priority information packet with priority information corresponding to nature of data and type of unit to which the patient monitor is associated;
dynamically generate dynamic priority information packet based on unit type and nature of the alarm and communicate the dynamic priority information; and
a communication channel through which the information packets are communicated.
11. The system as claimed in claim 10, wherein the initial priority information packet is a function of the unit name and the dynamic priority information packet is a function of nature of the alarm generated at that moment and the unit name.
12. The system as claimed in claim 10, wherein the initial priority information request packet includes bed name, unit type, type of packet and a header information and the initial and dynamic priority information packet includes bed name, unit name, type of packet and priority values corresponding to dynamic nature of the patient monitor data.
13. The system as claimed in claim 10, wherein the patient interface module is configured to receive dynamic priority information packet from the server; and configure the patient monitor using the dynamic priority information packet.
14. The system as claimed in claim 13, wherein the patient interface module is further configured to use default initial priority information if the server is not available to provide the initial priority information packet.
15. The system as claimed in claim 14, wherein the server interface module is configured to maintain a initial priority mapping table storing priority values corresponding to the dynamic nature of the patient monitor data for each unit name and is configured to provide the initial priority information packet from the table upon receipt of the initial priority information request packet from the patient monitor.
16. The system as claimed in claim 15, wherein the server interface module is further configured to maintain a priority status table at the server indicating the current priority information corresponding to each bed name in each unit and corresponding to the dynamic nature of the patient monitor data.
17. The system as claimed in claim 15, wherein the server interface module is configured to check dynamic priority information generated based on the nature of the alarm with the existing information in the priority status table and to update the priority status table with the current priority information.
18. The system as claimed in claim 17, wherein the server interface module is configured to communicate the dynamic priority information packet to the patient monitor whenever the dynamic priority information changes from the existing information in the priority status table.
19. The system as claimed in claim 10, wherein the server interface module is further configured to communicate initial priority information packet to the patient monitor whenever unit name changes.
20. The system as claimed in claim 16, wherein the server interface module is further configured to maintain a dynamic priority mapping table having unit name, different clinical relevant parameter, possible alarm conditions, and computed priority information corresponding to dynamic nature of the patient monitor data, the priority information being computed based on the nature of the alarm including severity of alarm for a parameter and clinical relevance of the parameter being monitored.
| Section | Controller | Decision Date |
|---|---|---|
| # | Name | Date |
|---|---|---|
| 1 | 3857-che-2010 drawings 16-12-2010.pdf | 2010-12-16 |
| 1 | 3857-CHE-2010-Annexure (Optional) [23-09-2019(online)].pdf | 2019-09-23 |
| 2 | 3857-che-2010 claims 16-12-2010.pdf | 2010-12-16 |
| 2 | 3857-CHE-2010-Written submissions and relevant documents (MANDATORY) [23-09-2019(online)].pdf | 2019-09-23 |
| 3 | 3857-CHE-2010-HearingNoticeLetter17-09-2019.pdf | 2019-09-17 |
| 3 | 3857-che-2010 description(complete) 16-12-2010.pdf | 2010-12-16 |
| 4 | 3857-CHE-2010-FORM-26 [06-12-2018(online)].pdf | 2018-12-06 |
| 4 | 3857-che-2010 correspondence others 16-12-2010.pdf | 2010-12-16 |
| 5 | abstract 3857-CHE-2010.jpg | 2017-09-28 |
| 5 | 3857-che-2010 abstract 16-12-2010.pdf | 2010-12-16 |
| 6 | Correspondence by Agent_Power Of Attorney_20-09-2017.pdf | 2017-09-20 |
| 6 | 3857-che-2010 form-5 16-12-2010.pdf | 2010-12-16 |
| 7 | 3857-CHE-2010-ABSTRACT [15-09-2017(online)].pdf | 2017-09-15 |
| 7 | 3857-che-2010 form-3 16-12-2010.pdf | 2010-12-16 |
| 8 | 3857-CHE-2010-CLAIMS [15-09-2017(online)].pdf | 2017-09-15 |
| 8 | 3857-che-2010 form-2 16-12-2010.pdf | 2010-12-16 |
| 9 | 3857-che-2010 form-18 16-12-2010.pdf | 2010-12-16 |
| 9 | 3857-CHE-2010-COMPLETE SPECIFICATION [15-09-2017(online)].pdf | 2017-09-15 |
| 10 | 3857-che-2010 form-1 16-12-2010.pdf | 2010-12-16 |
| 10 | 3857-CHE-2010-CORRESPONDENCE [15-09-2017(online)].pdf | 2017-09-15 |
| 11 | 3857-CHE-2010-FER.pdf | 2017-03-16 |
| 11 | 3857-CHE-2010-FER_SER_REPLY [15-09-2017(online)].pdf | 2017-09-15 |
| 12 | 3857-CHE-2010-FORM-26 [15-09-2017(online)].pdf | 2017-09-15 |
| 12 | 3857-CHE-2010-OTHERS [15-09-2017(online)].pdf | 2017-09-15 |
| 13 | 3857-CHE-2010-FORM-26 [15-09-2017(online)].pdf | 2017-09-15 |
| 13 | 3857-CHE-2010-OTHERS [15-09-2017(online)].pdf | 2017-09-15 |
| 14 | 3857-CHE-2010-FER.pdf | 2017-03-16 |
| 14 | 3857-CHE-2010-FER_SER_REPLY [15-09-2017(online)].pdf | 2017-09-15 |
| 15 | 3857-che-2010 form-1 16-12-2010.pdf | 2010-12-16 |
| 15 | 3857-CHE-2010-CORRESPONDENCE [15-09-2017(online)].pdf | 2017-09-15 |
| 16 | 3857-che-2010 form-18 16-12-2010.pdf | 2010-12-16 |
| 16 | 3857-CHE-2010-COMPLETE SPECIFICATION [15-09-2017(online)].pdf | 2017-09-15 |
| 17 | 3857-CHE-2010-CLAIMS [15-09-2017(online)].pdf | 2017-09-15 |
| 17 | 3857-che-2010 form-2 16-12-2010.pdf | 2010-12-16 |
| 18 | 3857-CHE-2010-ABSTRACT [15-09-2017(online)].pdf | 2017-09-15 |
| 18 | 3857-che-2010 form-3 16-12-2010.pdf | 2010-12-16 |
| 19 | Correspondence by Agent_Power Of Attorney_20-09-2017.pdf | 2017-09-20 |
| 19 | 3857-che-2010 form-5 16-12-2010.pdf | 2010-12-16 |
| 20 | abstract 3857-CHE-2010.jpg | 2017-09-28 |
| 20 | 3857-che-2010 abstract 16-12-2010.pdf | 2010-12-16 |
| 21 | 3857-CHE-2010-FORM-26 [06-12-2018(online)].pdf | 2018-12-06 |
| 21 | 3857-che-2010 correspondence others 16-12-2010.pdf | 2010-12-16 |
| 22 | 3857-CHE-2010-HearingNoticeLetter17-09-2019.pdf | 2019-09-17 |
| 22 | 3857-che-2010 description(complete) 16-12-2010.pdf | 2010-12-16 |
| 23 | 3857-CHE-2010-Written submissions and relevant documents (MANDATORY) [23-09-2019(online)].pdf | 2019-09-23 |
| 23 | 3857-che-2010 claims 16-12-2010.pdf | 2010-12-16 |
| 24 | 3857-CHE-2010-Annexure (Optional) [23-09-2019(online)].pdf | 2019-09-23 |
| 24 | 3857-che-2010 drawings 16-12-2010.pdf | 2010-12-16 |
| 1 | 3857che2010-Sheet1_27-01-2017.pdf |