Medical monitoring system
41 claims: 20 independent, 21 dependent
- 11人以上の医療患者に関連付けられた情報を表示する医療患者監視装置であって、少なくとも1人の患者に関連付けられた情報を受信するように構成されたインタフェースと、 前記情報を表示するように構成されたディスプレイと、 前記ディスプレイに表示される前記情報を制御するように構成されたプロセッサと、 前記医療患者監視装置の近傍の検出範囲内において、臨床担当者が誰であるかを表す臨床担当者トークンの物理的存在を検出する検出器と、を備え、 前記プロセッサはさらに、前記臨床担当者トークンが検出されたことに対する応答として、第1の所定のアクションを実行するように構成されており、前記第1の所定のアクションは、前記臨床担当者が誰かという情報に関連付けられており、 前記検出器は、設定可能な近傍時間閾値を超える時間にわたり、設定可能な信号強度閾値を超える強度の無線信号を、前記臨床担当者トークンから受信した後のみ、前記臨床担当者トークンの検出を認識するように構成されている、医療患者監視装置。
- 2前記第1の所定のアクションは、前記ディスプレイに表示される前記情報を変更することを含む、請求項1に記載の医療患者監視装置。
- 3前記第1の所定のアクションは、前記臨床担当者が担当する1人以上の患者に関連付けられた情報を表示することを含む、請求項1に記載の医療患者監視装置。
- 4前記検出器は、前記臨床担当者がトークンアクチュエータを起動したことに対する応答として、前記臨床担当者トークンから信号を受信するように構成された、請求項1に記載の医療患者監視装置。
- 5前記信号は識別コードを含み、前記プロセッサはさらに、前記コードをデータベースに伝達して前記第1の所定のアクションを識別するように構成された、請求項4に記載の医療患者監視装置。
- 6前記検出器は、前記臨床担当者が何もしなくても、前記医療患者監視装置の近傍の前記検出範囲内において前記臨床担当者トークンの物理的存在を自動的に検出する、請求項1に記載の医療患者監視装置。
- 7生理学的情報を監視する医療患者監視装置であって、少なくとも1人の患者に関連付けられた生理学的情報を受信するように構成されたインタフェースと、 前記生理学的情報に基づいて患者の生理学的パラメータを求めるように構成されたプロセッサと、 前記医療患者監視装置の近傍の検出範囲内において、臨床担当者が誰であるかを表す臨床担当者トークンの物理的存在を検出する検出器と、を備え、 前記プロセッサはさらに、前記臨床担当者トークンが検出されたことに対する応答として、第1の所定のアクションを実行するように構成されており、前記第1の所定のアクションは、前記臨床担当者が誰かという情報に関連付けられており、 前記検出器は、設定可能な近傍時間閾値を超える時間にわたり、設定可能な信号強度閾値を超える強度の無線信号を、前記臨床担当者トークンから受信した後のみ、前記臨床担当者トークンの検出を認識するように構成されている、医療患者監視装置。
- 8前記所定のアクションは、前記臨床担当者を前記医療患者監視装置にログインさせることを含む、請求項7に記載の医療患者監視装置。
- 9前記所定のアクションは、前記医療患者監視装置の構成を設定することを含む、請求項7に記載の医療患者監視装置。
- 10前記所定のアクションは、前記医療患者監視装置によって提供される機能を有効にすることを含む、請求項7に記載の医療患者監視装置。
- 11前記所定のアクションは、前記医療患者監視装置によって表示される情報の実体を変更することを含む、請求項7に記載の医療患者監視装置。
- 12前記所定のアクションは、前記医療患者監視装置によって表示される情報のフォーマッティングを変更することを含む、請求項7に記載の医療患者監視装置。
- 13前記所定のアクションは、生理学的情報をリモート装置に送信することを含む、請求項7に記載の医療患者監視装置。
- 14前記所定のアクションは、患者監視オプションを設定することを含む、請求項7に記載の医療患者監視装置。
- 15前記プロセッサはさらに、前記臨床担当者トークンの存在が検出されなくなった時点で第2の所定のアクションを実行するように構成された、請求項7に記載の医療患者監視装置。
- 16前記第2の所定のアクションは、前記第1の所定のアクションを逆にする、請求項15に記載の医療患者監視装置。
- 17前記検出器は、前記医療患者監視装置と前記臨床担当者トークンとの間に物理的接触がなくても、前記臨床担当者トークンの物理的存在を検出するように構成された、請求項7に記載の医療患者監視装置。
- 18前記臨床担当者トークンは、民生用電子装置を備えており、前記民生用電子装置は、臨床担当者識別コードを自身に関連付ける登録処理がなされている、請求項7に記載の医療患者監視装置。
- 19前記臨床担当者トークンは、Bluetooth(登録商標)対応装置を備える、請求項7に記載の医療患者監視装置。
- 20前記臨床担当者トークンは、RFIDタグを備える、請求項7に記載の医療患者監視装置。
- 21前記臨床担当者トークンの物理的存在は、分散配置された複数のアクセスポイントを用いる、前記臨床担当者トークンの位置の三角測量に基づいて検出される、請求項7に記載の医療患者監視装置。
- 22前記検出器が前記検出範囲内で複数の臨床担当者トークンの存在を検出した場合には、前記複数の臨床担当者トークンに関連付けられた複数の優先度インジケータを用いて、どの臨床担当者が前記第1の所定のアクションを実行すべきかに基づいて、臨床担当者トークンを選択する論理をさらに備える、請求項7に記載の医療患者監視装置。
- 23臨床担当者が前記医療患者監視装置と物理的に対話して、前記医療患者監視装置によって提供される一連のアクションのうちのいずれか1つを前記医療患者監視装置に実行させることを可能にするユーザインタフェースをさらに備え、前記一連のアクションは、前記第1の所定のアクションを含む、請求項7に記載の医療患者監視装置。
- 24前記生理学的情報を検知する医療パラメータセンサと通信可能に結合される入力ポートを有するベッドサイド患者監視器を備える、請求項7に記載の医療患者監視装置。
- 25複数のベッドサイド患者監視器と通信可能に結合されて、複数の患者からの生理学的情報を前記複数のベッドサイド患者監視器から受信するように構成された中央監視装置を備える、請求項7に記載の医療患者監視装置。
- 26近傍表示の近傍にいるユーザに関連付けられた表示環境設定に従って、1人以上の医療患者に関連付けられた生理学的パラメータを画面に表示するように構成された前記近傍表示監視器であって、 患者から得られた光センサ信号に対する応答として生理学的パラメータを求めるように構成された生理学的監視器と、 前記生理学的監視器に組み込まれ、前記生理学的パラメータを治療担当者の閲覧用として提示するように構成されたディスプレイと、 前記監視器に組み込まれ、前記治療担当者が携帯する送信機から受信した、前記治療担当者に関連付けられた識別信号に応答する送受信機と、を備え、前記ディスプレイは、前記識別信号で示された前記治療担当者に関連付けられた表示環境設定に従って、前記生理学的パラメータを前記ディスプレイに表示するように構成されており、 前記送受信機は、設定可能な近傍時間閾値を超える時間にわたり、設定可能な信号強度閾値を前記識別信号の強度が超えた後のみ、前記識別信号の検出を認識するように構成されている、近傍表示監視器。
- 27前記監視器が前記治療担当者から前記識別信号を受信し、前記治療担当者が前記監視器の近傍にいることを了解したことを、前記ディスプレイ上で前記治療担当者にフィードバックする画面機能をさらに備える、請求項 26 に記載の近傍表示監視器。
- 28前記画面機能は、ディスプレイ上に表された、切り替わる多面固体が、治療担当者が近傍にいることに対する応答として、第1の面に表示された前の画面から、第2の面に表示された好ましい画面へ回転する機能である、請求項 27 に記載の近傍表示監視器。
- 29前記多面提示は、3つの面を有する、回転する三角形状固体として前記ディスプレイに表示され、最初の画面は、前記3つの面のうちの第1の面に表示され、前記好ましい画面は、前記3つの面のうちの第2の面に表示される、請求項 28 に記載の近傍表示監視器。
- 30前記多面提示は、4つの面を有する、回転する立方体形状固体として前記ディスプレイに表示され、最初の画面は、前記4つの面のうちの第1の面に表示され、前記好ましい画面は、前記4つの面のうちの第2の面に表示される、請求項 28 に記載の近傍表示監視器。
- 31前記多面提示は、2つの面を有する、回転する平面固体として前記ディスプレイに表示され、最初の画面は、前記2つの面のうちの第1の面に表示され、前記好ましい画面は、前記2つの面のうちの第2の面に表示される、請求項 28 に記載の近傍表示監視器。
- 32ディスプレイおよび無線送受信機を有する監視器であって、 前記無線送受信機は、複数のユーザのうちのいずれかが前記監視器の近傍にいることを示す識別信号に応答する、前記監視器と、 前記複数のユーザに対応する、複数の表示環境設定と、 前記表示環境設定に従って生理学的パラメータを前記ディスプレイに提示する、複数の好ましい画面とを備えており、 前記送受信機は、設定可能な近傍時間閾値を超える時間にわたり、設定可能な信号強度閾値を前記識別信号の強度が超えた後のみ、前記識別信号のうちの一つの検出を認識するように構成されている、近傍表示監視器。
- 33前記複数のユーザに関連付けられた、複数の無線送信機をさらに備え、 前記複数の無線送信機は、前記識別信号を前記無線送受信機に送信し、 前記識別信号は、前記複数のユーザに対応し、 前記複数のユーザは、各自の識別情報および表示環境設定の、前記監視器への入力を完了している、請求項 32 に記載の近傍表示監視器。
- 34前記監視器内の前記識別情報および表示環境設定に関連付けられた、複数のコードをさらに備え、 前記識別信号は、前記コードを収容する、請求項 33 に記載の近傍表示監視器。
- 35前記監視器内に格納されたルックアップテーブルをさらに備え、 前記ルックアップテーブルは、前記コードならびに対応する識別情報および表示環境設定を格納し、 前記監視器は、前記識別信号内の前記コードを利用して、前記対応する表示環境設定を前記ルックアップテーブルから取り出す、請求項 34 に記載の近傍表示監視器。
- 36前記複数のユーザに関連付けられた、複数の優先度を前記ルックアップテーブル内にさらに備え、 前記優先度は、複数のユーザが前記監視器の近傍に存在する場合に、前記好ましい画面のうちのどの画面を前記ディスプレイに提示するかを決定する、請求項 35 に記載の近傍表示。
- 37前記識別信号の送信を開始することと、前記優先度を無効にすることと、のうちの少なくとも一方を行うために、複数のユーザがそれぞれの対応する無線送信機から送信する確認応答信号をさらに備える、請求項 36 に記載の近傍表示。
- 38肉組織部位内に送信された光放射から生成され、前記組織部位内での拍動血流による減衰を経て検出されたセンサ信号に応答するプロセッサであって、前記拍動血流の各成分を表す複数の生理学的パラメータを計算するように構成された前記プロセッサと、 近傍ユーザの閲覧用として、前記生理学的パラメータ値の視覚的表現を提供するディスプレイと、 近傍ユーザが誰であるかを決定する無線通信手段であって、前記無線通信手段は、設定可能な近傍時間閾値を超える時間にわたり、前記ユーザからの無線信号の強度が、設定可能な信号強度閾値を超えた後のみ、前記近傍ユーザのうちの一人の検出を認識するように構成されている、無線通信手段と、 前記生理学的パラメータを前記ディスプレイに提示するための、複数の画面環境設定手段と、 ユーザが誰かという前記情報を前記画面環境設定に関連付けるルックアップテーブル手段と、を備える近傍表示監視器。
- 39識別されている近傍ユーザの少なくとも1人に視覚的フィードバックを与えるために、前記ディスプレイに与えられたアニメーション手段をさらに備える、請求項 38 に記載の近傍表示。
- 40前記画面環境設定手段のどれを前記ディスプレイに与えるかを決定する優先度手段をさらに備える、請求項 39 に記載の近傍表示。
- 41前記優先度手段を無効にする、ユーザ初期化手段をさらに備える、請求項 40 に記載の近傍表示。
Independent claims41
361 paragraphs, as filed
0001Cross-reference of related applications U.S. Patent Application No. 61/209147 (subject "PROXIMITY DISPLAY MONITOR"), filed March 4, 2009, and 2010, the entire contents of which are incorporated herein by reference. It claims the priority benefit of US Patent Provisional Application No. 61/296439 (subject "MEDICAL MONITORING SYSTEM") filed on January 19, 2014.
0002The present disclosure relates to, for example, systems, devices, and methods having applications in hospitals and other patient treatment facilities. For example, the systems, devices, and methods described herein describe the acquisition of physiological information from a patient, the analysis of that physiological information, and the physiological information to clinicians and other systems or devices. Can be used for transmission.
0003Hospitals, long-term care facilities, and other patient care facilities typically have one or more bedside patient monitoring devices within the facility. Patient monitoring devices generally include sensors, processing devices, and displays for acquiring and analyzing physiological parameters of medical patients. There are many physiological parameters, such as respiratory rate and SpO.<sub>2</sub>Level, pulse, blood pressure, etc. Clinical personnel, including doctors, nurses, and certain other healthcare professionals, use physiological parameters obtained from medical patients to diagnose and prescribe treatment for the disease. Clinicians also use physiological parameters to monitor patients in a variety of clinical situations and decide whether to increase the level of treatment for them.
0004SpO in addition to detailed parameters such as HbCO, HbMet, total hemoglobin (Hbt), etc.<sub>2</sub>A description of a patient monitor capable of measuring pulse oximetry parameters such as and pulse rate, as well as corresponding multiple wavelength optical sensors, is at least filed March 1, 2006, US Patent Application No. 11/367013. These are made in the specification (subject "Multiple Wavelength Sensor Emitters") and in US Patent Application No. 11/366208 (subject "Noninvasive Multi-Parameter Patient Monitor") filed on March 1, 2006. Have been transferred to Masimo Laboratories, Irvine, CA (Masimo Labs), both of which are incorporated herein by reference. Furthermore, among various parameters, especially SpO<sub>2</sub>Non-invasive blood parameter monitor for measuring pulse rate, perfusion index, signal quality, HbCO, and HbMet and corresponding multiple wavelength optical sensors (Rainbow Adhesive Reusable Sensor and RAD-57 ( (Trademarks) and Radical-7 observers, etc.) are available from Masimo Corporation, Irvine, CA (Masimo).
0005Advanced physiological monitoring systems, for example, in just a few cases, calculate and display other blood parameters such as carbon monoxide hemoglobin (HbCO), methemoglobin (HbMet), and total hemoglobin (Hbt). In addition to the detailed functions for, it is possible to incorporate pulse oximetry. SpO<sub>2</sub>In addition, a description of an advanced physiological monitor and corresponding multi-wavelength optical sensors capable of measuring parameters such as HbCO, HbMet, and Hbt was filed at least March 1, 2006 in a U.S. patent application. In Specification 11/367013 (subject "Multiple Wavelength Sensor Emitters") and in US Patent Application No. 11/366208 (subject "Noninvasive Multi-Parameter Patient Monitor") filed March 1, 2006. These have been transferred to Masimo Labs and are incorporated herein by reference. Furthermore, among various parameters, especially SpO<sub>2</sub>, Pulse rate, perfusion index (PI), signal quality (SiQ), pulsation variability index (PVI), HbCO, and non-invasive blood parameter monitor for measuring HbMet and corresponding multiple wavelength optical sensors (Rainbow) Adhesive reusable sensors (such as RAD-57 and Radical-7 observers) are available from Masimo.
<p num="0006"><patcit num="1"><text>U.S. Patent Application No. 11/367013</text></patcit><patcit num="2"><text>U.S. Patent Application No. 11/366208</text></patcit></p>
<p num="0007"> This specification describes various medical monitoring devices, systems, and methods.</p>
<p num="0008"> In some embodiments, the medical monitoring device or system can detect the presence of a clinical person and, for example, take some action in response to the detection of the presence of a clinical person. In some embodiments, the medical surveillance system is capable of detecting the location of some medical devices, some clinicians, and / or some patients in a hospital or other patient care facility. Then, using the detected position, it is possible to perform some action based on the position, for example, a configuration change of the medical device.</p><p num="0009"> This specification describes various devices, systems, and methods that facilitate communication between medical monitoring devices (or systems) using medical communication protocol converters. It is possible to configure medical communication protocol converters to facilitate communication between medical devices programmed to communicate in different protocol formats. The medical communication protocol converter receives an input message formatted according to the first protocol format from the first medical device, and is supported by the second medical device using the conversion rule set. It is possible to output an output message formatted according to the protocol format of. For example, a medical communication protocol converter receives an input message formatted according to the first HL7 protocol format from the hospital information system and formats it according to the second HL7 protocol format based on comparison with the conversion rule set. It is possible to output the output message.</p><p num="0010"> In some embodiments, a medical monitoring device or system collects physiological parameter data from some patients and uses this data to simulate various alarm condition detection conditions and / or alarm notification delay times. It is possible. By analyzing and using these simulated alarm condition detection conditions and / or alarm notification delay times, the actual alarm condition detection conditions and / or alarm notification delays (for example, used in bedside patient monitoring devices) It is possible to change the time.</p><p num="0011"> In certain embodiments, a medical patient monitoring device that monitors physiological information comprises an interface configured to receive physiological information from at least one patient. The device can further include a processor configured to perform clinically useful tasks based on physiological information. The device may also include a detector that detects the physical presence of a clinician token that represents who the clinician is within the detection range in the vicinity of the medical patient monitoring device. In addition, the processor can be configured to perform a first predetermined action in response to the detection of a clinician token, the first predetermined action being information about who the clinician is. Associated with.</p><p num="0012"> In a particular embodiment, a clinical system that identifies the physical location of a plurality of medical devices comprises a plurality of medical patient monitoring devices capable of collecting physiological information from the plurality of patients. The clinical system can further include a distributed network of detectors capable of detecting radio signals from medical patient monitoring devices. The clinical system may also include a location monitoring server communicatively coupled to the detector that can estimate the physical location of the medical patient monitoring device based on the radio signal detected by the detector. It is possible.</p><p num="0013"> In various embodiments, a method of facilitating communication between a first and second medical device within a medical information network is a first input message generated according to the first communication protocol to the first medical device. Includes steps to receive from. The input message can identify the second medical device as the intended receiver of the input message. The method can further include the step of applying one or more conversion rules to convert an input message into an output message. The method can also include the step of delivering an output message to a second medical device, which is configured to receive and process the output message.</p><p num="0014"> In a particular embodiment, a medical device message converter configured to facilitate communication between a first and second medical device within a medical information network sends a first input message according to a first communication protocol. It includes a communication interface module configured to receive a first input message from the generated first medical device. The input message can identify the second medical device as the intended receiver of the input message. The converter also applies a rule module configured to store one or more predetermined conversion rules and one or more conversion rules retrieved from the rule module to convert the input message to an output message. It is possible to include a configured conversion module. The second medical device can be configured to receive and process the output message.</p><p num="0015"> In various embodiments, a method of transforming a message transmitted between multiple medical devices and a hospital information system or clinical information system comprises receiving an input message from a hospital information system with electronic patient medical records. , The content of the input message is formatted according to the first formatting rule set allowed by the medical electronic communication protocol. The method can further include a step of comparing the input message with the conversion rule set and a step of generating the output message, the content of the output message being the second allowed by the medical electronic communication protocol. Reformatted according to the formatting ruleset. Translation rules can control the reformatting of the content of the output message to comply with a second set of formatting rules. The method can also include the step of outputting an output message to a medical device.</p><p num="0016"> In various embodiments, a method of performing on-site customizable conversion of input and output medical messages belonging to a common medical electronic communication protocol but in different formats is an input message from the first medical device. The content of the input message is formatted according to the first formatting rule set, including the step of receiving. The method can further include identifying the intended receiving medical device from the input message. The method also reflects a second formatting rule set expected by the intended receiving medical device, based on the steps of comparing the input message with the translation rule set and the comparison of the input message with the translation rule set. It is possible to include, and so on, to change the formatting of the input message. Further, the method can also include a step of generating an output message whose contents are formatted according to a second formatting rule set, and a step of outputting the output message to the intended receiving medical device. Is.</p><p num="0017"> In a particular embodiment, a hospital information system having an electronic medical record database configured such that a system facilitating the transmission of medical messages between the hospital information system and a patient monitor stores electronic medical records of multiple patients. To be equipped. The system can further include a patient monitor configured to monitor at least one physiological condition of the patient. The system can also include a conversion module configured to be communicably coupled between the hospital information system and the patient monitor. The conversion module receives an input message whose contents are formatted according to the first formatting ruleset from either the hospital information system or the patient monitor, and compares the input message with the conversion ruleset, and outputs it. In the step of generating the message, the content of the output message is reformatted according to the second formatting ruleset, and the conversion rules make the reformatting of the contents of the output message conform to the second formatting ruleset. It can be configured to perform a step of generating an output message, and so on.</p><p num="0018"> In a particular embodiment, a system that facilitates the transmission of medical messages between medical devices over a network is a first medical device configured to send and receive medical messages and is communicably coupled to the network. It is equipped with a first medical device configured to be such. The system may further include a second medical device configured to send and receive medical messages, which is configured to be communicably coupled to a network. .. The system may also include a conversion module configured to be communicably coupled between the first medical device and the second medical device. The conversion module can be configured to perform a step of receiving an input message whose contents are formatted according to the first formatting rule set from the first medical device and a step of comparing the input message with the conversion rule set. .. The conversion module can also be configured to generate an output message whose contents have been reformatted according to a second formatting ruleset, and the conversion rules reformat the contents of the output message to a second formatting ruleset. Control to comply with. In addition, the conversion module can be configured to output the output message to a second medical device.</p><p num="0019"> In various embodiments, the method of defining medical communication formatting according to the medical electronic communication protocol is the step of compiling the format conversion software, the step of installing the format conversion software, and the user without recompiling the format conversion software. Includes steps to update the conversion ruleset in the configurable file.</p><p num="0020"> In certain embodiments, the method of analyzing physiological parameter monitoring data comprises receiving physiological parameter data from multiple patients. The method can further include receiving first physiological parameter alarm data from the plurality of patients, which is detected based on the first alarm condition and represents an alarm state that has occurred in the plurality of patients. Is. The method can also include the step of using a processor to generate a second physiological parameter alarm data representing a simulated alarm state detected based on the second alarm condition. .. In addition, the method can include the step of comparing the first and second physiological parameter alarm data using a processor. In a particular embodiment, the computer-readable medium comprises instructions to cause the computer to execute this method of analyzing physiological parameter monitoring data when read by the computer.</p><p num="0021"> In various embodiments, the method of analyzing physiological parameter monitoring data comprises receiving physiological parameter data from multiple patients. The method can further include receiving first physiological parameter alarm notification data representing physiological parameter alarm notifications generated based on the first alarm notification delay time. The method also uses a processor to generate second physiologic parameter alarm notification data that represents a simulated physiologic parameter alarm notification that is generated based on the second alarm notification delay time. Can be included. In addition, the method can include the step of comparing the first and second physiological parameter alarm notification data.</p><p num="0022"> Hereinafter, various embodiments will be described with reference to the accompanying drawings. These embodiments are illustrated and described only by way of example and do not limit the scope of the present disclosure.</p>
0023<figref num="1">It is an exemplary block diagram showing a physiological monitoring system according to one embodiment of the present invention.</figref><figref num="2">It is an exemplary block diagram showing another embodiment of a physiological monitoring system.</figref><figref num="3">It is an exemplary block diagram which shows the network interface module by one Embodiment of this invention.</figref><figref num="4">It is an exemplary flowchart showing a method of transmitting physiological information based on a situation according to one embodiment of the present invention.</figref><figref num="5">It is an exemplary block diagram which shows the alarm notification system by one Embodiment of this invention.</figref><figref num="6">It is a block diagram which shows one Embodiment of a clinical network environment.</figref><figref num="7">It is a block diagram which shows the more detailed embodiment of the clinical network environment of FIG.</figref><figref num="8A">It is a flowchart which shows one Embodiment of the method of journalizing a medical event to a journal database.</figref><figref num="8B">It is a flowchart which shows one Embodiment of the method of correlating the data from a journal database and a round-robin database with each other.</figref><figref num="9">It is a screen shot of an example of a user interface for monitoring a patient in the clinical network environment of FIG.</figref><figref num="10">It is a perspective view of an advanced patient monitoring system.</figref><figref num="11">It is a figure which shows the neighborhood display in a multi-user environment.</figref><figref num="12">It is the whole block diagram of the neighborhood display monitor.</figref><figref num="13">It is a figure which shows the user display environment setting screen.</figref><figref num="14">It is a schematic diagram of a patient monitoring device that can automatically detect the presence of a clinician token.</figref><figref num="15">It is a flowchart which shows the detection method which detects the existence of a clinician token within the detection range of a patient monitoring apparatus.</figref><figref num="16">It is a figure which shows an example of the graphical user interface of a nurse station or a central patient monitoring apparatus.</figref><figref num="17">FIG. 6 is a flow chart showing how to determine when to disable a clinician-specific action that has already been enabled by the patient monitoring device based on the detection of the presence of the clinician.</figref><figref num="18">FIG. 5 is a schematic diagram of a system that enables a patient monitoring device to automatically detect the presence of a clinician token.</figref><figref num="19">It is a schematic diagram of a patient monitoring device network having a clinician neighborhood recognition function.</figref><figref num="20">It is a schematic diagram of a hospital floor where WiFi access points are dispersed, and it is possible to estimate the physical positions of medical devices, patients, and clinical personnel by using WiFi access points.</figref><figref num="21">It is a figure which shows the neighborhood display embodiment which feeds back advantageously that a user is in a neighborhood.</figref><figref num="22">It is a figure which shows the neighborhood display embodiment which feeds back advantageously that a user is in a neighborhood.</figref><figref num="23">It is a figure which shows the neighborhood display embodiment which feeds back advantageously that a user is in a neighborhood.</figref><figref num="21A">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the vicinity using a virtual rotating triangle solid.</figref><figref num="21B">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the vicinity using a virtual rotating triangle solid.</figref><figref num="21C">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the vicinity using a virtual rotating triangle solid.</figref><figref num="21D">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the vicinity using a virtual rotating triangle solid.</figref><figref num="21E">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the vicinity using a virtual rotating triangle solid.</figref><figref num="21F">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the vicinity using a virtual rotating triangle solid.</figref><figref num="22A">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the neighborhood using a virtual rotating cube.</figref><figref num="22B">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the neighborhood using a virtual rotating cube.</figref><figref num="22C">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the neighborhood using a virtual rotating cube.</figref><figref num="22D">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the neighborhood using a virtual rotating cube.</figref><figref num="22E">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the neighborhood using a virtual rotating cube.</figref><figref num="23A">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the vicinity using a virtual rotation plane solid.</figref><figref num="23B">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the vicinity using a virtual rotation plane solid.</figref><figref num="23C">It is a figure which shows the neighborhood display embodiment which feeds back the fact that it is in the vicinity using a virtual rotation plane solid.</figref><figref num="24A">It is a figure which shows the mode that the 1st medical device and the 2nd medical device communicate with each other via a conversion module.</figref><figref num="24B">It is a figure which shows the mode that the 1st medical device and the 2nd medical device communicate with each other via a conversion module and a communication bus.</figref><figref num="25A">It is a figure which shows an example of the input message received by a conversion module.</figref><figref num="25B">It is a figure which shows the message header segment parsed as a field of the input message of FIG. 19A.</figref><figref num="25C">FIG. 25B is a diagram showing an encoded version of the parsed message header segment.</figref><figref num="25D">It is a figure which shows an example of the output message of a conversion module based on the input message of FIG. 25A.</figref><figref num="26">FIG. 5 shows a conversion process that produces an output message based on a comparison of an input message with a conversion rule associated with a conversion module.</figref><figref num="27A">A diagram showing a conversion process in which a conversion module facilitates the transmission of an HL7 message from a hospital information system (HIS) with a first HL7 format to an intended receiving medical device with a second HL7 format. is there.</figref><figref num="27B">FIG. 5 shows a conversion process in which a conversion module facilitates the transmission of an HL7 message from a medical device having a first HL7 format to a HIS having a second HL7 format.</figref><figref num="28">It is a figure which shows the example of the screen shot from the messaging implementation software tool which manually configures the conversion rule used in the conversion module.</figref><figref num="29A">It is a figure which shows the automatic rule composition process executed by a conversion module.</figref><figref num="29B">It is a figure which shows the automatic rule composition process executed by a conversion module.</figref><figref num="29C">It is a figure which shows the automatic rule composition process executed by the conversion module for the message which uses the HL7 protocol.</figref><figref num="29D">It is a figure which shows the automatic rule composition process executed by the conversion module for the message which uses the HL7 protocol.</figref><figref num="30">It is a graph example of the distribution of alarm events for a given physiological parameter as a function of the alarm limit.</figref><figref num="31">It is a flowchart which shows the method of examining the change of the identified alarm state which is the result of the change of the alarm condition.</figref><figref num="32">It is a figure which shows the report example by the table which shows the influence which the simulated alarm condition has on an alarm detection event.</figref><figref num="33">It is a flowchart which shows another method to examine the change of the identified alarm state which occurs as a result of the change of the alarm condition.</figref><figref num="34">It is a figure which shows the report example by the table which shows the influence which the simulated alarm condition has on the number of alarm detection events, and the influence which this simulated alarm condition has on false negative and false positive, for example.</figref><figref num="35">It is a flowchart which shows the method of examining the change of the alarm notification event that occurs as a result of the change of the alarm notification delay time.</figref><figref num="36A">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="36B">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="37A">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="37B">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="37C">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="37D">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="37E">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="37F">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="38A">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="38B">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="39A">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="39B">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="40A">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="40B">It is a figure which shows the neighborhood display which provides an advantageous function in a multi-user patient monitoring environment.</figref><figref num="36A">It is a figure which shows the display which has a plurality of layout zones.</figref><figref num="36B">It is a figure which shows the display which has a plurality of layout zones.</figref><figref num="37A">It is a figure which shows the display which changes the layout and font size according to the number of installed parameters.</figref><figref num="37B">It is a figure which shows the display which changes the layout and font size according to the number of installed parameters.</figref><figref num="37C">It is a figure which shows the display which changes the layout and font size according to the number of installed parameters.</figref><figref num="37D">It is a figure which shows the display which changes the layout and font size according to the number of installed parameters.</figref><figref num="37E">It is a figure which shows the display which changes the layout and font size according to the number of installed parameters.</figref><figref num="37F">It is a figure which shows the display which changes the layout and font size according to the number of installed parameters.</figref><figref num="38A">It is a figure which shows the display which has a parameter well.</figref><figref num="38B">It is a figure which shows the display which has a parameter well.</figref><figref num="39A">It is a figure which shows the display which enlarges the parameter which is issuing an alarm.</figref><figref num="39B">It is a figure which shows the display which enlarges the parameter which is issuing an alarm.</figref><figref num="40A">It is a figure which shows the display of the trend graph which has a colored alarm zone.</figref><figref num="40B">It is a figure which shows the display of the trend graph which has a colored alarm zone.</figref><figref num="41">It is a figure which shows the display which combined the black-and-white inversion of an arrow key and a cursor.</figref><figref num="42">It is a figure which shows the display which has a jump screen which a user can select.</figref><figref num="43A">It is a figure which shows the display of the trend graph.</figref><figref num="43B">It is a figure which shows the display of the trend graph.</figref>
0024In various embodiments, a physiological monitoring system is a system that monitors a physiological signal generated by a medical patient and processes the signal to determine any of the patient's various physiological parameters. For example, in some cases, a physiological monitoring system can determine any of the patient's various physiological parameters, such as respiratory rate, inspiratory time, expiratory time, I: E ratio (eg,). , Inspiratory time / expiratory time ratio), inspiratory flow, expiratory airflow, tidal volume, minute / hour output, duration of abstinence, breathing sound, rales, water bubbles, pant, changes in breathing sound (decrease in air flow rate) Or changes in airflow, etc.). In addition, in some cases, physiological monitoring systems monitor other physiological sounds, which help detect probe-off heart sounds, heart sounds (eg, S1, S2, S3, S4, and heart murmurs), heart sounds. (For example, a change from a normal sound to a heart murmur, or a split heart sound indicating an excess of body fluid). In addition, physiological monitoring systems can use a second probe on the chest to better detect heart sounds, minimizing user input (eg, input height only). And Health Level Demography can be entered automatically using the 7 (HL7) interface.
0025The physiological monitoring system of a particular embodiment includes one or more patient monitoring devices connected to a shared network using an open architecture communication standard. These specific embodiments of the patient monitoring device include a physiological monitoring device combined with a network interface module. Physiological monitors include one or more sensors and a sensor processing module that processes the signals from the sensors. The network interface module receives physiological information from the sensor processing module and sends this information to the shared network. The network interface module can be connected to a variety of physiological monitors. In addition, various implementations of network interface modules are portable bedside devices that are exclusively assigned to a single medical patient.
0026In certain embodiments, the network interface module facilitates the establishment of a direct network connection with the end user over the shared network. These end users include doctors, nurses, and other hospital staff, and network interface modules on electronic devices (eg, pagers, PDAs, laptops, computers, mobile computers (COWs), etc.) It is possible to receive physiological information, alarms, and alerts from.
0027FIG. 1 shows a particular embodiment of a physiological monitoring system 100 (eg, an alarm notification system), which includes an open network architecture using "off-the-shelf" hardware and communication protocols. This architecture in various implementations is a shared (open) network, including multiple patient monitoring devices 110, network bus 120 (eg Ethernet® backbone), and hospital WLAN 126. In addition, this shared network can further include a connection 122 to the Internet 150, a connection 122 to the end user device 152 via the Internet 150, and a connection 122 to the end user device 128 via the hospital WLAN 126. is there. Therefore, the physiologic monitoring system 100 of a particular embodiment is an enterprise system that cost-effectively replaces currently available patient monitoring systems.
0028The physiological monitoring system 100 includes a plurality of bedside devices, for example, a patient monitoring device 110. The patient monitoring device 110 of various embodiments includes a plurality of sensors 102, one or more sensor processing modules 104, and a communication module, for example, a network interface module 106. In the illustrated embodiment, two patient monitoring devices 110 are shown. One patient monitoring device includes a set of sensors 102, a sensor processing module 104, and a network interface module 106. The other patient monitoring device 110 includes two sets of sensors 102, two sensor processing modules 104, and one network interface module 106.
0029In certain embodiments, each patient monitoring device 110 is used by one medical patient. These patient monitoring devices 110 form a network of patient monitoring devices 110, and each patient monitoring device 110 is in charge of clinical practice via a shared network including a hospital network 126 and a network interface to the Internet 150. It is possible to communicate with people and other end users.
0030One or more sensors 102 of the patient monitoring device 110 are worn on the medical patient. These sensors 102 may be ECG sensors, acoustic sensors, pulse oximeters, or other types of sensors. The sensor 102 obtains physiological information from the medical patient and transmits this information to the sensor processing module 104 via a cable 103 or a wireless connection (not shown). In certain embodiments, the physiological information comprises one or more physiological parameters or values and waveforms corresponding to those physiological parameters.
0031The sensor processing module 104 receives physiological information from the sensor 102. The sensor processing module 104 of the specific embodiment includes a circuit having a processor, an input port for receiving physiological information, software for processing physiological information in the processor, an optional display, and an optional input device (for example,). Keyboard) and is included. Further, the sensor processing module 104 includes one or more output ports (such as a serial port). For example, the sensor processing module 104 can include an RS232, RS423, or Autobo RS232 (serial interface standard) port, or a universal serial bus (USB) port.
0032In a particular embodiment, the sensor processing module 104 generates a waveform from the signal received from the sensor 102. The sensor processing module 104 can also analyze trends in single or multiple parameters and give early warning alerts to clinicians prior to alarm events. In addition, the sensor processing module 104 in the particular embodiment raises an alarm in response to a physiological parameter exceeding a particular safety threshold.
0033Examples of alerts include the inability to communicate with the pulse oximeter, the alarm not sounding on the pulse oximeter side, the low battery level of the instrument (pulse oximeter), and the low battery level of the transmitter. As an example of an alarm, SpO<sub>2</sub>Levels and alarms, high and low SpO<sub>2</sub>, High and low PR, HbCO level and alarm, HbMET level and alarm, pulse rate and alarm, no sensor, sensor off patient, sensor error, low perfusion index, low signal quality, HbCO, HbMET, PI trends There are alarms of, and alarms of saturation decrease index.
0034The network interface module 106 in the illustrated embodiment is connected to one or more sensor processing modules 104 via one or more connectors 108, the connector 108 corresponding to the serial port of the sensor processing module 104. It may be a serial connector. The dashed line of connector 108 indicates that the connection between the network interface module 106 of the particular embodiment and the sensor processing module 104 is not permanent. However, in an alternative embodiment (not shown), the network interface module 106 is housed within the sensor processing module 104.
0035In various implementations, the network interface module 106 includes a processor, an input port (such as a standard RS232 serial port), a network output port (such as an Ethernet® port), and a network interface module 106 that supports network communication. Includes software that allows it to operate as a device. Further, the network interface module 106 includes a storage device 114, which may be included within the network interface module 106 and may be connected independently of the network interface module 106. ..
0036The network interface module 106 manages the connection overhead to initiate and maintain connections with end-user devices over the shared network. In a particular embodiment, the network interface module 106 manages the connection by acting as a microserver or web server. In such a case, the network interface module 106 is a network connection compatible device. As a web server, the network interface module 106 establishes a direct connection to the Internet 150 so that end users can access web pages stored in the storage device 114 of the network interface module 106. Therefore, in one embodiment, the network interface module 106 does not require a separate server to connect to the Internet 150. In one embodiment, the network interface module 106 connects directly to the Internet 150 via a modem, with connection 122 including a modem. The network interface module 106 may perform security management functions such as user authentication when managing connections over a shared network.
0037In certain embodiments, network interface module 106 transmits data over a shared network via access point 124, or other wireless or wired transmitter. Alternatively, the network interface module 106 can convey physiological information directly to the end user via the Internet 150. End users, such as clinicians, who carry notification devices (eg, end user devices 128, 152 connected to hospital WLAN 126) are on-demand or at the time of an alarm or alert event of physiological patient parameters and waveforms. It is possible to receive a real-time display. In certain embodiments, transmitting physiological information in real time or with a slight delay is the Joint Commission on Accreditation of Healthcare for effective alarm response. It conforms to the alarm waiting time standard that complies with the Organizations (JCAHO) standard. Therefore, the network interface module 106 of the specific embodiment adds functionality equivalent to that of the central nurse station.
0038In a particular embodiment, network interface module 106 performs status management. In one embodiment, status management involves associating status information with physiological information to form a status data package. The status information can include several categories of information, such as status information related to network interface module 106, status information related to medical patients, and related to the use of network interface module 106. It is possible to include information in each category: status information to be done and status information related to network connections. In one or more of these status categories, status information can include patient name, patient's unique in-hospital identification number, patient location, network interface module 106 identification number, and physiology. Time stamps of events that occurred within the monitoring system 100, environmental conditions (such as changes in network state and usage statistics for network interface module 106), and identification information that corresponds to the network link (for example, the network connection is WiFi or Ethernet). (Registered trademark) or). In one embodiment, the status information in the status data package may include status information from one or more of the above information categories to all status information or a subset of status information.
0039The status information received by the network interface module 106 is, for example, information that the nurse inputs to the network interface module 106 or information from the server 136. In one embodiment, the network interface module 106 will be exclusively assigned to the medical patient by receiving this information (including, for example, the patient's identification number and location). The network interface module 106 transmits or communicates the status data package to the clinician during the occurrence of an alarm or alert, at the request of the clinician, or according to a schedule. In addition, the network interface module 106 is capable of transmitting a continuous stream of physiological information to the clinician.
0040In certain embodiments, the network interface module 106 can optionally associate patient status information and other status information with the plurality of sensor processing modules 104 by connecting to the plurality of sensor processing modules 104. This makes it possible to create a situation for one or more sensor processing modules 104 in addition to creating a situation for the network interface module 106.
0041In addition to transmitting the status data package, the network interface module 106 in one embodiment stores the status data package in the storage device 114. The storage device 114 may be a flash memory, a hard disk drive, or other form of non-volatile or volatile memory. In a particular embodiment, the storage device 114 operates as a flow control buffer. The network interface module 106 uses a storage device 114 that operates as a flow control buffer to perform flow control during communication. This will be described in detail later with reference to FIG.
0042Depending on the implementation, Server 136 can optionally be included in Physiological Monitoring System 100. The server 136 in such an implementation is generally a computing device such as a blade server. In a particular embodiment, server 136 is an appliance server housed in a data closet. In another embodiment, the server 136 is a server, such as a workstation server, installed in a central nurse station.
0043The server 136 receives the status data package from the plurality of network interface modules 106 and stores the status data package in the storage device 138. Therefore, in certain embodiments, this storage device 138 archives long-term patient data. This patient data can be maintained after the patient is discharged. Server 136 can act as an interface between the shared network and an external electronic medical record (EMR) system when storing patient data.
0044Server 136 can also store data about user-system interactions and system performance metrics. The server 136 of the specific embodiment incorporates a journal database. The journal database stores all alerts and alarms or a subset of alerts and alarms, as well as human dialogue, much like an aircraft "black box" records cockpit activity. Journals are usually inaccessible to clinical end users and cannot be tampered with without technical approval. In addition, server 136 can perform internal journaling of system performance indicators such as system-wide uptime.
0045In one embodiment, the journaling function of server 136 constitutes a transaction-based architecture. By journaling a particular transaction in the Physiological Monitoring System 100, it is possible to later reconstruct the timeline of recorded events to assess the quality of treatment given. These transactions include physiological information from patient monitoring device 100, patient monitoring device 110, hospital WLAN 126 connectivity, user manipulation, and state changes related to system behavior. Journaling related to physiological information received from a physiological monitor in one embodiment includes recording the physiological information itself, recording changes in the physiological information, or both.
0046The server 136 in a particular embodiment provides a logical and management tool that maintains a connection between the network interface module 106, a clinical notification device (such as a PDA or pager), and an external system (such as an EMR). providing. Further provided by the server 136 of the particular embodiment is the installation (provisioning) of software associated with the physiological monitoring system 100 to add new equipment to the system and to notify alarms at the start and end of shifts. A web-based interface that allows you to assign notification devices (such as PDA and pager) to each clinical person for use, an escalation algorithm when the primary caregiver does not respond to an alarm, alarm occurrence and response time. Interfaces that provide management reports on, location management, internal journaling of system performance indicators (such as system-wide uptime), etc. (see, for example, Figure 5 and related descriptions).
0047Server 136 in a particular embodiment also provides a platform for advanced rule engines and signal processing algorithms that anticipate clinical alarms and give early alerts. The operating system of server 136 in one embodiment is Linux® based for cost reasons, but Microsoft based or other operating systems can also be used. In addition, server 136 is extensible to include data storage and system redundancy features such as RAID (random array of independent disks) options and high availability options.
0048In another embodiment (not shown), end-user devices 128, 152 include a two-line display unidirectional POCSAG pager, which has audible and vibrating modes and is a common floor arrangement in hospitals. It has a size and durability suitable for the harsh mechanical environment that is common in Japan. In yet another embodiment, end-user devices 128, 152 include a bidirectional paging system such as a Motorola Flex pager and a WLAN pager. One advantage of bidirectional paging is the ability to confirm message reception and the ability to remotely silence alarms. The end user can also use the wireless PDA based on the robustness and acceptable form factor determined by the end user. An example of such a device is the Symbol Technology MC50 PDA / Barcode Scanner.
0049FIG. 2 shows a physiological monitoring system 200 according to another embodiment of the present invention. The physiological monitoring system 200 includes a network communication compatible device 210. The network communication compatible device 210 is directly connected to the hospital network 220 via a wireless connection. In a particular embodiment, the network communication capable device 210 includes a sensor and a sensor processing module similar to the sensor 102 and the sensor processing module 104 of FIG. Some of these network communication capable devices 210 are bedside devices and others are handheld or other patient-worn devices that can be used by walkable (movable) patients.
0050The hospital network 220 transmits physiological and status information to clinician notification devices, including pagers 240, PDAs 230, and the like. In a particular embodiment, the hospital network 220 utilizes the server 250 to transmit a status data package to the page transmitter 242, which further transmits the data to the unidirectional wireless pager 240. It is possible to combine the external interface 280 with the server 250. The external interface 280 can include one or more of enterprise paging, nurse calling systems, wide area paging systems, enterprise clinical / patient information systems, and third party surveillance and supervision systems.
0051Some other devices 260 (such as some patient monitoring device) are not network communication capable devices. That is, these other devices 260 cannot connect to the network without assistance. In the illustrated physiological monitoring system 200, a device example 260 that does not support network communication is connected to the network interface module 270. The network interface module 270 is connected to another device 260 that does not support network communication with an RS232 cable 264. Such a connection is a standardized serial connection found in many devices. Since the network interface module 270 has an RS232 port, it is possible to enable a patient monitoring device that does not support network communication to connect directly to the hospital network 220 and even to the Internet.
0052Further, in some embodiments, the network interface module 270 may associate patient status information and other status information with one or more other devices 260 by connecting to one or more other devices 260. It is possible. Therefore, in addition to creating a situation for the network interface module 270, it is possible to create a situation for one or more other devices 260.
0053FIG. 3 shows a network interface module 300 according to a specific embodiment of the present invention. The network interface module 300 in the illustrated embodiment includes an input port 302, which in the particular embodiment is a serial port that facilitates connection with the sensor processing module. The network interface module 300 also includes a network interface 304, which may be a wired interface (eg, Ethernet®) or a wireless interface (WiFi, Bluetooth®, etc.). Alternatively, the network interface module 104 can communicate over a cable TV interface or other type of interface. Such a CTV interface provides a subcarrier bidirectional communication function that coexists with the video format.
0054The network interface module 300 also communicates with the storage device 350. In the illustrated embodiment, the storage device 350 is shown to be separate from the network interface module 300, but in some implementations, the storage device 350 is included in the network interface module 300. Further, although not shown, the network interface module 300 can include a processor that implements the communication program code. Similarly, although not shown, the network interface module 300 can include an input device for nurses to enter status information and a display that receives output from the network interface module 300. is there.
0055The network interface module 300 can be integrated into a handheld, portable, or stationary patient monitoring platform or instrument and is housed in an accessory package with RS232 input as a general purpose interface to such equipment. It is possible to do. In another embodiment, the active RFID tag function (not shown) is included in the network interface module 106, the clinician device (eg, the notification device), or both, when an event occurs. , Or, upon request, it will be possible to locate the patient or clinician. Also, when operating in a shared network, the network interface module 106 provides open architecture communication standards such as IEEE 802.IX (Security and Authorization), IEEE 802.3 (Ethernet®), and WiFi (IEEE 802.11a, b, g, e, i wireless protocol) compliant.
0056The status management module 310 in the network interface module 300 manages status data. In one embodiment, the status management module 310 receives status information such as the status information described above with respect to FIG. In one embodiment, when a patient is hospitalized or assigned a particular bed in the hospital, a nurse or other clinician can keyboard or use status information (patient name, identification number, location, etc.). Input to the network interface module 300 from another input device (not shown). In another embodiment, the status management module 310 receives status information from a server such as server 136 in FIG.
0057The status management module 310 associates status information with the physiological information received from the sensor processing module. In a particular embodiment, the status management module 310 executes this association when an alarm condition occurs. In such a case, the situation management module 310 can create a situation data package that summarizes snapshots of historical physiological information and situation information. In another embodiment, the status management module 310 continuously performs the association and the network interface module 300 sends a continuous or scheduled status data package to the end user. In addition, the status management module 310 or other module within the network interface module 300 stores the status data package in storage 350.
0058The communication module 320 communicates with the network using the network interface 304. In a particular embodiment, the communication module 320 possesses the functionality of a Web server. The communication module 320, as a Web server, allows the network interface module 300 to communicate directly with the hospital network and the Internet without using a server. Therefore, other devices such as physiological monitoring devices that do not support network connection can be connected to the network interface module to make them network compatible. The network interface module 300 manages the connection overhead to initiate and maintain the connection, manages status information (for example, one of the status information previously described with respect to FIG. 1), and patient information on a web-enabled device. Provides a web server for displaying. In one embodiment, a communication protocol based on XML technology allows bedside devices to work with multiple target end-user platforms (PDAs, mobile computers (COWs), tablet PCs, IP mobile phones (smartphones), fixed PCs, etc.). It becomes possible to interface.
0059In a particular embodiment, the communication module 320 communicates with the network using standard communication protocols. Examples of standard communication protocols include Ethernet (registered trademark), WiFi (WLAN), and Bluetooth (registered trademark). The communication module 320 can send and receive data via a shared network or an open network architecture by using a standard communication protocol. However, the communication module 320 can also be used in a proprietary network that uses a proprietary protocol.
0060In an embodiment in which the network interface module 300 communicates via a shared network rather than its own network, the network interface module 300 shares network resources with other devices on the network. Large network traffic can affect the reliability of network communications. Therefore, the network interface module 300 of a specific implementation includes a flow control module 330. The flow control module 330 confirms that the transmitted data has been received by the end user. If the end user does not receive the data, the flow control module 330 retransmits the data stored in the storage device 350. Therefore, in a particular embodiment, the storage device 350 operates as a flow control buffer.
0061The security module 340 manages user access to the network interface device 300 as well as user access to the data stored in the storage device 350. In certain embodiments, the security module 340 determines if the user attempting to connect to the network interface module 300 is allowed to do so. In one implementation, security module 340 manages authentication using standard IEEE.802.IX network access control protocols. The network interface module 106 in a particular embodiment provides security and encryption that meets the requirements of the Health Insurance Portability and Accountability Act (HIPAA).
0062In certain embodiments, the network interface module 300 incorporates all or part of the functionality specified by the IEEE 1073 standard and the latest updates to the IEEE 1073 standard, namely the IEEE 11703 standard (IEEE 1073). And 11703 standards are both incorporated herein by reference). In certain embodiments, the status management module 310, the communication module 320, the flow control module 330, and the security module 340 also incorporate the functionality specified by the IEEE 1073 and 11703 standards. By using the standard protocol, it is possible to make a wide variety of physiological monitoring devices compatible with network communication by using the network interface module 300.
0063FIG. 4 shows a situation-based method of transmitting physiological information 400 according to an embodiment of the present invention. In a particular embodiment, method 400 is performed by any of the network interface modules described above with respect to FIGS. 1-3. In addition, method 400 in a particular embodiment can be performed by any of the physiological monitoring systems described with respect to FIGS. 1, 2, and 5.
0064In method 400, first, status information is received at 402. In one embodiment, a device such as a network interface module receives status information once (eg, in an initialization step). Method 400 then receives a physiological information at 404. In certain embodiments, Method 400 continues to receive physiological information throughout the remaining steps of Method 400. Alternatively, method 400 may receive physiological information 400 as part of method 400.
0065At 405, method 400 determines if an alarm condition or alert has occurred. If there is an alarm condition or alert, Method 400 goes to 406. On the other hand, if there is no alarm condition or alert, Method 400 returns to 404. In one embodiment, returning to 404 for method 400 means that the network interface module continuously receives physiological information until an alarm condition or alert occurs. In certain embodiments (not shown), Method 400 may continue to receive physiological information even when an alarm condition or alert occurs.
0066At 406, method 400 prepares a status data package. The status data package can include status information and snapshots of physiological information. In one embodiment, the snapshot of physiological information includes the physiological information that triggered the alarm or alert. In one embodiment, the snapshot of physiological information includes information before and after the occurrence of an alarm or alert. The status data package is 408 and is stored in the flow control buffer.
0067At 410, method 400 establishes a network connection. In one embodiment, establishing a network connection at 410 comprises connecting a network interface module to an end-user device (eg, a notification device assigned to a nurse during a work shift). Method 400 then determines in 412 whether the user of the end-user device (eg, a nurse) has been authenticated. If the user is not authenticated, method 400 proceeds to 420. On the other hand, if the user is authenticated, method 400 proceeds to 414.
0068Method 400 communicates the status data package to the user at 414. At 416, method 400 determines if a status data package has been received. If a status data package is received, method 400 proceeds to 420. If not received, method 400 proceeds to 418, where 418 accesses the data stored in the flow control buffer. In one embodiment, the data accessed by method 400 is equivalent or nearly equivalent to the status data package communicated to the user in 414.
0069Method 400 then returns to 414, where 414 conveys the status data package to the user (eg, resends), and then 416 rechecks if the package was received. Method 400, depending on the implementation, continues the loop between steps 414, 416, and 418 until a status data package is received. Therefore, steps 414, 416, and 418 in the particular embodiment constitute flow control performed by method 400. These flow control steps allow Method 400 to overcome possible network transmission errors in the shared network.
0070If a status data package is received, Method 400 evaluates at 420 whether to continue monitoring physiological information. If it decides to continue monitoring, method 400 returns to 404 and at 404 continues to receive physiological information. On the other hand, if it decides not to continue monitoring, Method 400 ends.
0071In various embodiments of Method 400, only status data packages or physiological information is transmitted to the user, even in the absence of alarm conditions. In yet another embodiment, fewer steps than all of the steps may be performed, or the steps may be performed in a different order. For example, method 400 performs the step of receiving physiological information at 404, the step of preparing a status data package at 406, the step of establishing a network connection at 410, and the status data package at 414. You may just perform the steps to communicate to the user.
0072FIG. 5 shows an alarm notification system 500 according to a specific embodiment of the present invention. The clinical subsystem 510 defines the key software components of the alarm notification system 500, which include the clinical assignment module 512, the bedside device initialization module 514, the notification and display module 516, the escalation rule module 518, Includes clinical reporting module 520 and clinical data storage module 522. Mobile computing devices that comply with HIPAA and hospital IT policies have built-in authentication capabilities.
0073The clinical allocation module 512 has an allocation function. The Nursing Supervisor assigns individual nurses to specific patients at the beginning of each shift and at the time of admission of a new patient. Shift assignments are made in shift changes during the "reporting" transition activity, where individual nurses and nursing supervisors from the previous shift "take over" the patient to the next shift. This report may be formal or informal, attended by all nurses, depending on the hospital's nursing service policy and procedures. The clinical assignment module 512 provides an intuitive interface that allows individual patients to be assigned to a list of assignable nurses. The main users of this module are ward clerks appointed by nursing supervisors. A nurse can be assigned to one or more patients, or all patients. An alternative workflow is self-assignment. This is where each nurse assigns a patient to himself, in which case the nurse acts as a ward clerk. In the self-assignment model, the default embodiment is that if there is an unassigned patient, that patient is assigned to all nurses or nursing supervisors.
0074The bedside device initialization module 514 is a bedside device such as the network interface module described above and may be set up by a nursing assistant. When a nurse performs this task, the nurse will act as a nursing assistant. The workflow includes installing the device at the bedside, installing sensors, initializing the device, and setting patient status such as name, ID, and location.
0075The notification and display module 516 assigns a wireless notification device (unidirectional pager, PDA, IP phone, COW, or tablet) to individual nurses. This device is associated with each nurse. Based on the clinical assignment module 512, the alarm is routed towards the notification device. Non-dedicated notification device solutions, such as when a hospital-owned paging system is provided to nurses, have unknown latency characteristics. On the server, a general-purpose interface is available that waits less than 1 second after receiving from the bedside device, and this general-purpose interface is time-stamped when presented to the server external interface, and the time stamp is in the server. Stored in the journaling system. By adding interfaces for mobile computing platforms such as PDAs, COWS and tablets, it will be possible to view current and trend data for individual patients.
0076The escalation rule module 518 has a rule engine that invokes the escalation policy defined by the hospital. Escalation Rule Module 518 is an alarm replacement for alternatives and additional clinical users if there is no alarm response or if the alarm persists for a predefined time (for example, by policy). Set the route. The escalation rule module 518 in the specific embodiment routes the alarm to the emergency response team.
0077The clinical reporting module 520 reports in a predefined format for clinical data that can be used to determine physiological status and / or progression. Two or more reports are possible as needed by the end user. The report is not a time-critical display of the individual patient, but has the privileges of the alarm notification system 500 and can be viewed from a distance by a clinician certified by the alarm notification system 500. These reports are web browser displays that allow clinicians to set display parameters such as time and parameter measures and alarm redisplay.
0078The clinical data storage module 522 provides data storage and database resources for storing information, as known to those skilled in the art.
0079Figure 5 further shows the technical support subsystem 530, which is isolated from the HIPAA compliant clinical subsystem 510 and therefore cannot view any patient information except risk reporting module 538. , Inaccessible. The technical support subsystem 530 includes a provisioning module 532, a management module, a service module 536, a risk reporting module 538, and a technical data storage module 540.
0080The provisioning module 532 provides provisioning, i.e., the initial installation of the system and the customer's first use. The main user of provisioning module 532 is the field installer. The provisioning module 532 contains all the startup scripts and system configuration to take the system out of the shipping packaging and complete the functionality of the alarm notification system 500. Provisioning involves configuring individual devices at the customer's site, notification devices such as pagers, PDAs, COWs, tables, and IP phones, preferably by wireless means (eg, Bluetooth®).
0081Management Module 534 provides user setup, policy settings for various role-based privileges (such as allowing nursing assistants to set or change alarms), identification of allowed device connections, and other common IT systems. Provides a system interface for application administrators to set up system management tasks.
0082Service module 536 provides an interface for various technical support personnel such as remote services, IT services, and biomedical services. Each of these personnel may perform each other's roles. Service personnel can access system performance data using interfaces to access performance, such as data traffic, connected equipment assets, software version control, CPU loading, network loading, and more. It also enables remote technical service procedures such as resetting printer queues, repartitioning disks, and uploading software patches. Service Module 536 includes full journaling capabilities that store all user interactions or some user actions that can be captured by the system, especially changes to default values and alarm settings.
0083Risk Reporting Module 538 provides clinical from alarm occurrence, alarm duration, and alarm to determine the overall effectiveness of a clinical response to an alarm in the light of the requirements of JCAHO, other regulatory bodies, and the Internal Quality Assurance Commission. Provide a summary report on time to response and other statistical data.
0084The technical data storage module 540 has the same characteristics as the clinical data storage module 522, except that it is used for technical data. The technical data storage module 540 may or may not share the same physical and logical entities as the clinical data storage module 522.
0085Figure 5 further shows the external interface subsystem 550, which provides interfaces with bedside devices and external systems, such as electronic medical records, hospitalization and discharge transfer systems, POCSAG pager systems, middleware. It provides an interface with engines (Emergin, etc.) and Web / XML-compatible devices (wireless PDAs, COWs, tablet PCs, etc.). The external interface subsystem 550 has an HL7 interface 552, a pager interface 554, an XML / Web interface 556, and a device interface 558.
0086The HL7 interface 552 provides a bidirectional interface to electronic medical records (EMR) and supports both push and pull models. The push model is when a bedside nurse activates data transfer. The pull model is when the EMR system polls the alarm notification system 500 server. Pager interface 554 provides output to an external paging system. Message latency is end-user specific for any user-owned paging solution. This same output can be used for middleware alarm notification systems such as Emergin. The XML / Web interface 556 provides a bidirectional interface with mobile computing platforms such as wireless PDAs, COWs, tables, and web-enabled IP phones. The mobile computing platform supports XML applications in web browsers. The device interface 558 provides a bidirectional interface to bedside devices and other devices corresponding to communication modules or accessories. An option for interfacing other bedside devices is the Application Programmer Interface (API) feature.
0087The main end-users of the Alarm Notification System 500 system (not shown or listed for brevity) include hospital electronic medical records, admissions and discharges, dispensing, pharmacy, clinical information, patient flow tracking, and more. Each person (for example, a user of the alarm notification system 500) includes a clinical person and a technical support person. Clinical personnel include nursing supervisors, ward clerks, nursing assistants, nurses, response teams, and respiratory therapists.
0088The Nursing Supervisor assigns individual nurses to specific patients at the beginning of each shift. Shifts can vary depending on the hospital's staffing policy. The ward clerk receives instructions from the nursing supervisor, typically enters assignments into the system and monitors the entire system. The ward clerk does not have to wait for all shifts. The nursing assistant is assigned by a nurse or nursing supervisor and typically wears a bedside device sensor, initializes the bedside device, and sets the alarm to the default value. The nurse is primarily responsible for caring for the individual patient and for the initial response to the alarm. The nursing supervisor assigns two or more patients to the nurse, depending on the skill of the nurse and the needs of the patient. Nurses are not always assigned the same patient. Nursing assistants are not available in every hospital.
0089The readiness team responds to clinical emergencies triggered by bedside nurses or nursing supervisors. The readiness team supports more than one treatment room and has one or more members depending on the shift. Response teams do not have to be deployed at all hospitals. Respiratory therapists are responsible for managing respiratory treatment for two or more patients, and usually in two or more treatment rooms. Some international environments do not have a respiratory therapist.
0090The work replacement of clinical personnel allows highly competent personnel to assume the role of other personnel. The alarm notification system 500 enables a mechanism to do such a thing. For example, a nursing supervisor can act as a ward clerk, nursing assistant, nurse, and response team. Nurses can act as ward clerks, nursing assistants, and readiness teams. In some international markets, nurses can act as respiratory therapists.
0091Technical support personnel include field installers, application administrators, remote services, IT engineers, biomedical engineers, and risk managers. The field installer provisions the system for initial installation, installs each component, and verifies that the installation and configuration meet the purchase agreement. The application administrator sets up and maintains user accounts and systems by default. Remote services provide remote diagnostics and system maintenance over remote links such as dial-up and VPN. IT engineers provide network support services when the system is integrated with the hospital IT network. Biomedical technicians provide primary services for bedside and systems. Risk managers scrutinize reports for quality and risk mitigation. The technical support person may take the place of another person. For example, an IT technician, biomedical technician, or remote service can also act as an application administrator. IT engineers or biomedical engineers can also play a role in each other.
0092Specific embodiments provide systems and methods for rapidly storing and retrieving physiological trend data. For example, physiological information obtained from medical patients can be stored in a round-robin database. The round-robin database can store physiological information in the form of a series of records that are evenly spaced in time. Parameter descriptors can be used to identify parameter values in a record. It is possible to dynamically update the parameter values by changing the parameter descriptor, which makes the database flexible. Furthermore, the size of the file used for the database can be dynamically adjusted according to the patient's condition.
0093In addition, in certain embodiments, medical data obtained from physiological monitors in clinical networks can be stored or journaled in a journal database. This medical data can include device events that occur in response to a dialogue between the clinician and one or more medical devices. The medical event data can also include events (such as alarms) triggered by the device. Medical data stored in journal databases can be analyzed to derive statistics or indicators that can be used to improve the work outcomes of clinicians and / or hospitals.
0094As used herein, the terms "round-robin database" and "RRDB" may refer to an improved database structure with the unique properties and characteristics disclosed herein, in addition to their original meaning. .. These structures may also be referred to herein as dynamic RRDBs or adaptive RRDBs.
0095FIG. 6 shows an embodiment of the clinical network environment 600. The clinical network environment 600 includes one or more patient monitor 640, a nurse station system 630, and a multi-patient monitoring system (MMS) 620 that communicates with the clinician device 650 via network 610. In certain embodiments, the MMS 620 provides physiological data obtained from the patient monitor 640 to the nurse station system 630 and / or the clinician device 650. In addition, in certain embodiments, the MMS 620 stores physiological and medical event information for later analysis.
0096Network 610 of the clinical network environment 600 is a network used in any hospital, care facility, patient care center, or other clinical facility of any type, LAN or WAN, wireless LAN (WLAN), or other type. You can. For ease of explanation, the rest of the specification describes the clinical environment in the context of a hospital, but the features described herein can also be used in other clinical facilities or settings. Please understand that. Depending on the implementation, the network 610 can be interconnected with devices in multiple hospitals or clinical facilities, which may be separated from each other via the Internet, leased lines, and so on. Similarly, the various devices 620, 630, 640, and 650 in the clinical network environment 100 may be geographically dispersed (eg, in multiple hospitals) or in the same location (eg, within a single hospital). There may be.
0097The patient monitor 640 may be a point of care (POC) instrument or the like that monitors a physiological signal detected by a sensor coupled to the medical patient. The patient monitor 640 can process the signal to determine any of a variety of physiological parameters. As an example of physiological parameters, blood oxygen saturation (SpO)<sub>2</sub>). Other examples of physiological parameters will be described later with reference to FIG.
0098The patient monitor 640 is capable of providing physiological information to the MMS 620. The patient monitor 640 can also provide the MMS 620 with information about medical events, such as alarms. The alarm can be triggered, for example, in response to a physiological parameter deviating from the normal range. The alarm can also include alerts about equipment failures, such as probe-off conditions where the sensor has dropped out of the patient. Later, another example of a medical event will be described with reference to FIG.
0099In various embodiments, the patient monitor 640 provides physiological information and medical events to the MMS 620. The MMS 620 will be described in detail later. Depending on the implementation, the patient monitor 640 can provide at least a portion of this information directly to the nurse station system 630 and the clinician device 650.
0100The nurse station system 630 may be a desktop computer, laptop, workstation, etc. located in the nurse station. It is possible to place one or more nurse station computers 630 in the nurse station. The nurse station computer 630 can receive and display physiological information and alarm data from the MMS 620 (or monitor 640). In certain embodiments, the nurse station computer 630 uses a graphical user interface (GUI) that provides physiological and medical information in a streamlined, at-a-glance view. An example of this GUI will be described later with reference to FIG.
0101The clinician device 650 may be any of a variety of devices used by clinicians, such as pagers, cell phones, smartphones, personal digital assistants (PDAs), laptops, tablet PCs, personal computers, etc. It may be. In some embodiments, the clinician device 650 is capable of receiving physiological information and alarms from the MMS 620 (or monitor 640). Physiological and alarm data can be provided to a particular clinician device 650, eg, as a response to an alarm. Optionally, the clinician device 650 is capable of receiving values and waveforms of physiological parameters.
0102The MMS 620 in a particular embodiment includes one or more physical computing devices (such as a server) having hardware and / or software for managing network traffic within the network 610. This hardware and / or software can be logically and / or physically divided into several different servers 620 by function, such as communication servers, web servers, database servers, application servers, files. Servers, proxy servers, etc.
0103The MMS 620 can communicate with the patient monitor 640, the nurse station computer 630, and the clinician device 650 using standardized protocols (such as TCP / IP) or proprietary protocols. In one embodiment, if the patient monitor 640 seeks a connection with the MMS 620, the MMS 620 authenticates the patient monitor 640 and provides patient status information coupled to the patient monitor 640. It is possible to provide to. Situational information may include a variety of, but in particular, patient demography, patient alarm settings, and clinical staff assignments to patients. Examples of status information are provided herein. The MMS 620 can obtain this status information from the nurse station system 630 or other hospital computer system where the patient's hospitalization information is given.
0104The MMS 620 is capable of receiving physiological information and medical events from the patient monitor 640 as soon as it is connected to the patient monitor 640. The MMS 620 is capable of providing at least some of those physiological information and medical events to the nurse station system 630 and / or the clinician device 650. For example, the MMS 620 can provide physiological data and alarms for multiple patient monitor 640s to the nurse station system 630, where the nurse evaluates the data and / or alarms. It is possible to determine how to treat the patient. Similarly, the MMS 620 can provide physiologic data and alarms to clinicians by sending wireless pages, emails, instant messages, etc. to the clinician device 650.
0105Advantageously, in certain embodiments, the MMS 620 is capable of storing physiological information obtained from the patient monitor 640 in a round-robin database (RRDB) 624. The RRDB 622 in various embodiments has a streamlined database structure that facilitates the rapid storage and retrieval of patient data. Therefore, in certain embodiments, the RRDB 622 can be used to rapidly provide physiological trend data to the nurse station 630 and the clinician device 650. So, for example, if a clinician wants to see the patient's physiological trends over a specific time period (eg, the last hour), the clinician can use the nurse station computer 630 or the clinician device 650 to see the MMS 620. It is possible to contact. The MMS 620 can then obtain the physiological information corresponding to the desired time zone from the RRDB 622. Advantageously, RRDB Since the 622 can acquire trend data more quickly, it is possible to use the relational database currently used in hospital monitoring systems. Further usage and optimization of RRDB 622 will be described later.
0106In certain embodiments, the MMS 620 also archives or stores information about medical events in the journal database 624. Medical events can include events recorded by devices such as patient monitor 640, nurse station system 630, and clinician device 650. Specifically, the medical event can include a device event that occurs in response to a dialogue between the clinician and the device (eg, an alarm outage at the direction of the clinician). Medical events can also include device events that occur without interaction between the clinician and the device (eg, the alarm itself). Further examples of medical events will be described later with reference to FIG.
0107The MMS 620 can analyze medical event information stored in the journal database 624 to derive statistics about medical events. For example, the MMS 620 can analyze alarm events and alarm outage events to determine the time between alarm and clinical response. The MMS 620 can use these statistics to generate reports on the work outcomes of clinicians and / or hospitals. Advantageously, in certain embodiments, these statistics and reports can be used to improve the work outcomes of clinicians and hospitals.
0108For example, in certain situations, these reports can help hospitals find the cause of the problem with the patient monitor 640. The following example scenarios can show the potential benefits of such a report. SpO<sub>2</sub>Alarm levels tend to be different for adults and newborns. However, this may not be known to some clinicians and is a newborn SpO.<sub>2</sub>Changes may be made to include adult alarm levels in the monitor. Such changes can lead to frequent false alarms, which can frustrate clinicians and avoid the use of patient monitor 640. Journaling medical events such as alarm changes by clinicians and analyzing the journaled data could reveal that clinicians were improperly adjusting alarm settings on neonatal monitors. There is. In that case, the hospital can use this information to take corrective action (eg, fix alarm limits and train clinical personnel).
0109Although not shown, it is possible to provide a management device within the clinical network environment 600. The management device can include a computing device operated by a hospital manager, an IT person, or the like. For example, IT personnel can use management devices to inform multiple patient observers 640, nurse station system 630, and MMS 620 of changes. The management device also allows IT personnel to interface third-party systems (eg, electronic medical record (EMR) systems) with the MMS 620. For example, by using a third-party system, it is possible to change the alarm settings of a plurality of monitors from the management device. In general, actions taken by administrators, IT personnel, and management equipment can also be journaled to journal database 624.
0110FIG. 7 shows a more detailed embodiment of the clinical network environment 700. The clinical network environment 700 includes a network 710, a patient monitor 740, a nurse station system 730, an MMS 720, an RRDB 722, and a journal database 724. These components may include all of the functionality described above with respect to FIG. For simplicity, the observer 740 and the nurse station system 730 are shown one by one. Further, although not shown, the clinical personnel device 750 described above can also be included in the clinical network environment 700.
0111The illustrated embodiment of the patient monitor 740 includes a monitoring module 742, an RRDB module 744, and a journal module 746. Each of these modules may include hardware and / or software. Other components (such as communication modules) are not shown, but may be included in the patient monitor 740 in various implementations.
0112The monitoring module 742 is capable of monitoring physiological signals generated by one or more sensors attached to the patient. The monitoring module 742 can process the signal to determine any of a variety of physiological parameters. For example, the monitoring module 742 can obtain physiological parameters such as pulse rate, plethysmograph waveform data, perfusion index, and blood component values in body tissues, and the blood component values include, for example, arterial blood. Carbon monoxide saturation (HbCO), methemoglobin saturation (HbMet), total hemoglobin (HbT or SpHb), arterial oxygen saturation (SpO)<sub>2</sub>"), Arterial oxygen saturation fraction ("SpaO<sub>2</sub>"), Oxygen content ("CaO<sub>2</sub>")and so on.
0113In addition, the monitoring module 742 is capable of obtaining physiological information from acoustic sensors, which include respiratory rate, inspiratory time, expiratory time, inspiratory time expiratory time ratio, inspiratory flow, expiratory airflow, and tidal volume. , Minute volume, duration of aspiration, breathing sound, rales, bubbling sound, pant, change in breathing sound (decrease in air flow or change in air flow, etc.). In addition, in some cases, the monitoring module 742 monitors other physiological sounds, such as heart rate, heart sounds (eg, S1, S2, S3, S4, and heart murmurs) (useful for probe-off detection). ), Changes in heart sounds (for example, changes from normal sounds to heart murmurs, and split heart sounds that indicate excess body fluids). In addition, the monitoring module 742 can monitor the electrical activity of the patient's heart by electrocardiography (ECG) and monitor various other physiological parameters.
0114Depending on the implementation, the patient monitor 740 may also be able to obtain a variety of data reliability indicators, eg, US Pat. No. 7,024,233, which is incorporated herein by reference in its entirety. It is also possible to obtain the data reliability index described in "Pulse oximetry data confidence indicator"). The patient monitor 740 can also determine the perfusion index, eg, in US Pat. No. 7,292,883 (subject "Physiological assessment system"), the entire disclosure of which is incorporated herein by reference. It is also possible to determine the listed perfusion index. In addition, the patient monitor 740 can also determine the plethysmograph variability index (PVI), eg, US Patent Application Publication No. 2008/0188760, which is incorporated herein by reference in its entirety. Subject "Plethysmograph variability It is also possible to obtain the PVI described in "processor"). Each parameter described herein is merely an example, and various other parameters can be used in the specific embodiment.
0115In a particular embodiment, the RRDB module 744 receives physiological information from the monitoring module 742 and transmits this physiological information to the MMS 720 via network 710. In response, the MMS 220 is capable of storing physiological information in the RRDB 722. Advantageously, in certain embodiments, the RRDB module 744 associates physiological information with a parameter descriptor before sending it to the MMS 720. The parameter descriptor may be an identifier that the RRDB module 744 associates with each measurement of the physiological parameter. The MMS 720 can use these parameter descriptors to identify the type of measurement parameter received from the RRDB module 744.
0116The parameter descriptor may be a descriptor generated according to a markup language specification, eg, an extensible markup language (XML) specification. Therefore, the parameter descriptor can include a tag that encloses the measured physiological value. These tags may be machine readable or human readable. For example, a tag can be a numeric identifier (for example, "0017") or a descriptive identifier ("SPO").<sub>2</sub>, "SPHB", etc.) may be included. SpO associated with the parameter descriptor<sub>2</sub>Examples of simplified streams of physiological information from sensors and SpHb sensors are, for example, <SPO2> 96 </ SPO2> <SPHB> 14.1 </ SPHB> <SPO2> 97 </ SPO2> <SPHB> 14.0 </ strong>. SPHB> (and so on).
0117In one embodiment, the RRDB module 744 can store a set of predefined parameter descriptors (eg, as a data file) available on the patient monitor 740. These parameter descriptors can correspond to the expected parameters that can be measured by the patient monitor 740. The parameter descriptor sent by the RRDB module 744 may depend on a particular subset of the parameters measured by the patient monitor 740.
0118If the patient monitor 740 continuously measures additional (or other) parameters, the RRDB module 740 may dynamically update the parameter descriptor sent to the MMS 720. Similarly, if the patient monitor 740 discontinues the measurement of any parameter, the RRDB module 744 may discontinue sending the corresponding parameter descriptor to the MMS 720.
0119In the illustrated embodiment, the patient monitor 740 also includes a journal module 746. The journal module 740 is capable of recording medical events related to the patient monitor 740. These medical events can include events triggered by clinical personnel, such as alarm settings (eg, maximum and minimum allowed parameter values), monitored parameter types, and connected to patient monitor 740. It is possible to include changing the type of sensor, etc. The journal module 746 is capable of recording these events, for example by acting as a keylogger that records button presses by clinicians. The journal module 746 can also include a current sensing circuit that detects when a sensor or cable is connected to the patient monitor 740. Medical events may also include events triggered by non-clinical personnel (such as alarms and alerts). Medical events may also include events from management devices (not shown), such as EMR updates of alarm settings throughout network 710 .
0120The journal module 746 can log these events locally on the patient monitor 740. Journal module 746 can, in addition to, or instead, log events locally, send information about these events to the MMS 720. The MMS 720 can then store this event information in the journal database 724.
0121The nurse station system 730 was shown to have a patient monitoring client 732 in the illustrated embodiment. The patient monitoring client 732 can enable the nurse station system 730 to receive and display physiological and alarm information. The patient monitoring client 732 includes a user interface module 734. The user interface module 734 can include, for example, software that displays physiological information, patient information, and medical event information about multiple patient monitor 740s. The user interface module 734 can also allow clinical personnel to perform patient admissions and discharges, remote changes to device alarm limits, and so on. An example of a user interface that can be generated by the user interface module 734 will be described later with reference to FIG.
0122The patient monitoring client 732 also includes a journal module 736. The journal module 736 can include software that records medical events related to the patient monitoring client 732. For example, journal module 736 can record which clinical personnel logged in and logged off of the patient monitoring client 732, as well as when these events occurred, and can record hospitalization and discharge events. It is possible to record other clinical personnel keystrokes, mouse clicks, and interactions with the patient monitoring client 732. The journal module 736 can log this event information locally to the nurse station system 730 and / or send it to the MMS 720.
0123As illustrated, the MMS 720 can include a network management module 721, an RRDB management module 723, and a journal management module 725, each of which can contain one or more software components. In one embodiment, the network management module 721 receives a message containing physiological information and medical event data from the patient monitor 740. The network management module 721 is capable of providing at least a portion of this data to the nurse station system 730 and the clinician device 650 of FIG. The network management module 721 can also provide physiological information to the RRDB management module 723 and medical event data to the journal management module 725.
0124In a particular embodiment, the RRDB management module 723 stores the physiological information received from the patient monitor 740 in the RRDB 722. When the patient monitor 740 first connects to the MMS 720, or at another time, the RRDB management module 723 can create one or more RRDB files in the RRDB 722 that correspond to the patient monitor 740. Is. The contents of this one or more files may depend on the type of patient monitor 740 and can be defined by the patient monitor 740 serial number, model number, vendor identifier, combination thereof, and the like. Specific examples of the structure and content of the RRDB file are described in US Patent Application Publication No. 2009/0119330, which is incorporated herein by reference in its entirety.
0125The RRDB management module 723 also provides the physiologic trend data stored in the RRDB to the network management module 721 for transmission to the monitor 740, the nurse station system 730, and / or the clinician device. Is also possible. The RRDB management module 723 can also provide the physiological data in the RRDB 722 to the journal management module 725 for the purposes described below with respect to FIG. 8B.
0126The journal management module 725 is capable of receiving medical event data from the observer 740 and the nurse station system 730 and storing this data in the journal database 724 in certain implementations. In one embodiment, the journal database 724 is a relational database, but other structures can be used. Each entry in the event data can have a corresponding time stamp indicating when the event occurred. This time stamp can be given by the journal module 746 or 736, or the journal management module 725. The journal management module 725 can also store an event counter in the journal database 724 that reflects the number of medical event occurrences. For example, it is possible to store a counter that counts the number of alarms that occur during a given time period and the number of times a clinician logs on or off a network device.
0127Advantageously, the journal management module 725, in certain embodiments, can analyze medical data in the journal database 724 to obtain statistics or indicators of work outcomes for clinicians and / or hospitals. The journal management module 725 can provide an interface for accessing these statistics to the user of the nurse station system 730 or another computing device. In one exemplary embodiment, the journal management module 725 can analyze alarm events and alarm outage events to determine the time it takes for a clinician to respond to an alarm. The Journal Management Module 725 can also determine the time to time for the clinician to respond during the nurse's daytime and nighttime shifts. The journal management module 725 can generate reports of these statistics so that hospital managers can, for example, determine which shifts work outcomes are better than others.
0128More generally, the journal management module 725 can analyze various statistics derived from the data in the journal database 724 to generate reports on the work outcomes of clinicians and / or hospitals. .. An example of a report is a surveillance reporting card, which compares a given hospital to other hospitals (or a given nurse station to other nursing, at least in part based on derived statistics. It is a rating (compared to a nurse's office, etc.). Advantageously, hospital managers, clinicians, etc. can use these statistics and reports to improve the work outcomes of clinicians and hospitals.
0129Some or all of the functions of the clinical network environment 700 are adaptable to specific embodiments. For example, either or both of journal modules 746 and 736 can perform some or all of the functions of journal management module 725. Similarly, one or more journal databases 724 can be stored in the patient monitor 740 and / or the nurse workstation 730. Similarly, the RRDB module 724 can perform some or all of the functions of the RRDB management module 723, and the RRDB 722 can be stored in the patient monitor 740. In addition, depending on the implementation, the clinician device 650 of FIG. 6 can also have an RRDB module and / or a journal module. In other embodiments, various other adaptations, configurations, and combinations are possible. Additional information regarding embodiments of RRDM is provided in US Patent Application Publication No. 2009/0119330.
0130FIG. 8A shows an embodiment of Method 800A for journaling medical events into a journal database. In one embodiment, Method 800A can be implemented by any of the MMS described above (eg, MMS 620 or 720). Specifically, Method 800A can be implemented by the journal management module 725. Alternatively, at least some blocks can be implemented by journal modules 736, 746. Advantageously, in certain embodiments, Method 800A facilitates the generation of reports based on journaled data.
0131Block 802 journals medical events into the journal database. In response to a reporting request from a user (eg, a clinical person), block 804 retrieves statistics about medical events from the journal database. This statistic can include the type, frequency, and duration of a medical event, information about who the clinician or patient is associated with this event, time to respond to an alarm, a combination of these, and more. ..
0132At block 806, generate a report on this medical event statistics. At block 808, this report is used to identify areas where hospital work may be improved. For example, this report may be a "monitoring report card" that assigns scores to hospitals or hospital clinicians based on work outcomes.
0133FIG. 8B shows an embodiment of method 800B that correlates data in the journal database and RRDB. In one embodiment, Method 800B can be implemented by any of the MMS described above (eg, MMS 620 or 720). Specifically, Method 800B can be implemented by RRDB module 723 and journal management module 725. Alternatively, at least some blocks can be implemented by the RRDB module 744 and the journal modules 736, 746. Advantageously, in certain embodiments, Method 800B allows the physiological information in the RRDB to correlate medical events with respect to time. Such event and physiological data reconstruction can be similar to aircraft "black box" technology, allowing users to recreate clinical procedures leading up to medical incidents. Will be possible.
0134Block 812 receives a request from the user to review the journaled and physiological data corresponding to a time zone. The user may be a clinical person, hospital manager, or the like who wants to identify the cause of a problem in treating a patient. For example, the user can see the patient's SpO<sub>2</sub>You may want to identify the cause of the clinician's failure to respond when
0135Block 814 retrieves the journaled data for the specified time period from the journal database. This block can be executed by the journal management module 725. At block 816, physiological data for the specified time zone is retrieved from the RRDB. This block can be executed by the RRDB management module 723. Block 818 correlates journal data with physiological data in terms of time. This correlation can include reconstructing the time series of medical events for the values of physiological parameters (including optionally waveforms) given in the correct time order on the time series. .. In some embodiments, the time stamps of the databases 722, 724 can be synchronized when the data is stored in order to facilitate this coordination between the RRDB management module 723 and the journal management module 725.
0136In block 820, the data associated with each other is output for presenting to the user. This output can include, for example, a graphical display of physiological information (eg, waveforms) overlaid with medical events. Various display formats are available for this interrelated data.
0137FIG. 9 shows an example of a graphical user interface (GUI) 900 for patient monitoring. The GUI 900 can be installed in a nurse station system or the like. The GUI 900 can also be displayed on the clinician's device.
0138The GUI 900 has several display areas. In the illustrated embodiment, the GUI 900 includes a patient status display area 910. The patient status display area 910 indicates the status of a plurality of patients in a hospital or other clinical facility. In one embodiment, the patient status display area 910 indicates the patient status of a plurality of patients in one department of a hospital. Advantageously, in certain embodiments, the patient status display area 910 provides a "at-a-glance" view of the health status of multiple patients.
0139The patient status display area 910 includes a plurality of patient status modules 912. Each patient status module 912 can accommodate a patient monitor that can be coupled to a medical patient. Each patient status module 912 is capable of displaying a graphical status indicator 914. Screen 900 shows an example of a graphical status indicator 914 with a reduced image patient monitor icon. The graphical status indicator 914 can selectively display one of several statuses of the patient monitor. In one embodiment, the four states that the patient monitor can indicate can be displayed by the graphical state indicator 914. These four states are alarm state, no alarm state, patient status information state, and connection state.
0140In various implementations, the graphical status indicator 914 indicates one of the different patient monitor states by changing color, shape, etc. For example, if an alarm condition is present, the graphical status indicator 914 can be red to indicate the alarm. If no status information is available for the patient (see Figure 1), the graphical status indicator 914 can be yellow. If the device is not connected to a patient or network, the graphical status indicator 914 can be grayed out. The graphical status indicator 914 can be green if there is no alarm status, status information is available, and the patient monitor is connected to the patient and network. Various other colors, symbols, and / or states can be used in place of or in combination with the embodiments described above.
0141Advantageously, the graphical status indicator 914 shows the status of the patient monitor at a glance. Thus, in the patient status display area 910, several graphical status indicators 914 corresponding to some patients display a glimpse of the patient monitor corresponding to these patients. Therefore, clinicians can easily understand the patient's needs for alarms, connectivity, and status information.
0142Many of the currently available graphical user interfaces for nurse stations computers display multiple waveforms or numerical values of changing physiological parameters for each patient. This method of displaying patient information can be cluttered, confusing, confusing, and even drowsy. For example, a nurse working on a night shift may find it difficult to focus on an alarm when the numbers, waveforms, etc. of other patient indicators on the display are changing. On the other hand, in the graphical interface described in the present specification, when the graphical status indicator 914 indicates an alarm status, the alarm status can be made conspicuous, and the clinical staff can immediately recognize the alarm status. ..
0143In addition, the graphical status indicator 914 simplifies the first level of analysis expected by nurses. With currently available equipment, nurses often have to analyze waveforms at the nurse station to determine the patient's health. In contrast, with screen 900, nurses do not need to interpret the patient's waveform or changing parameters altogether, instead relying on the graphical status indicator 914 to indicate the presence of an alarm. Is.
0144In a particular embodiment, the patient status module 912 can be selected by a single mouse click or the like. In one embodiment, the patient status module 912 can be selected to display the patient monitor view area 920. The patient monitor view area 920 displays a view of the patient monitor corresponding to the selected patient state module 912. In certain implementations, the patient monitor view area 920 is capable of displaying a screen view of the actual patient monitor at the patient's bedside. Therefore, the clinician can easily recognize the patient's physiological parameters in a generally familiar format. The patient monitor view area 920 is still receiving physiological information from the patient.
0145In certain implementations, the history view area 930 is capable of displaying medical event data corresponding to the selected patient monitor status module 912. This medical event data can be retrieved from the journal database for inclusion in GUI 900. History view 930 can display, for example, when the sensor was connected to or disconnected from the patient, when the alarm was active, and when the patient was admitted to the hospital or department. Is. Although not shown, the history view area 930 can also be configured to display trend data retrieved from the RRDB in place of or in addition to the journaled data. Sending patient information to a remote device
0146In some embodiments, the patient monitoring devices described herein are capable of transmitting patient information to one or more remote devices for scrutiny by clinical personnel. Such remote devices include, for example, remote computers, smartphones, PDAs and the like. It is useful to send patient information to a remote device because it enhances the clinician's ability to remotely monitor the patient's condition. For example, clinicians can effectively monitor a patient's condition without being at the patient's bedside or even at a patient care facility such as a hospital.
0147In some embodiments, it is possible to transmit any of the information collected by the patient monitoring device (eg, the patient monitoring device described herein) to the remote device. Such information can include, for example, values of medical parameters (eg, blood oxygen saturation, pulse rate, respiratory rate, etc.), trend data, and the like. It is also possible to include patient footage and / or patient and / or room audio. For example, a video camera and / or microphone can be installed in the hospital room. In some embodiments, the video camera and / or microphone can be incorporated, for example, into a medical surveillance device as described herein. A video camera can image a patient with visible light if the ambient light in the hospital room is sufficiently bright. The video camera can also detect, for example, infrared light when the room is too dark to obtain an image of acceptable quality with visible light. The video camera can also include an infrared light source to illuminate the patient and / or the patient's surroundings. In some embodiments, the camcorder includes an ambient light sensor that can be used to automatically switch the camcorder to infrared mode when the brightness of the ambient light falls below some threshold. The optical sensor can also be used to turn on the infrared light source if it is included.
0148The transmission of patient information (eg, medical parameter data, patient video / audio, etc.) is, for example, one or more communication networks (eg, computer networks such as LAN, WLAN, Internet, etc., telephone networks, etc.). It can be done using. In some embodiments, one or more communication networks are available that are physically or partially located in a hospital or other patient care center. In some embodiments, it is possible to communicate with remote devices around the world using an external communication network. Therefore, clinicians can remotely obtain vast amounts of information about the condition of their patients, wherever they are. In some embodiments, the clinician can also communicate directly with the patient. For example, a patient monitoring device can include a speaker that conveys audio from a clinical person's remote device to the patient. Similarly, the patient monitoring device can include a display (eg, for video conferencing) that displays images from the clinician's remote device. By exchanging information in both directions in this way, the clinician can directly interact with the patient. Hospital system that knows the location of equipment and clinical personnel
0149Advanced surveillance systems can display many different physiological parameters in many different formats. One of the weaknesses in this rich executive function and display flexibility is that the information presented to the therapist using these systems may be excessive. These therapists are, for example, doctors, respiratory therapists, registered nurses, and other clinical personnel, and the use of their respective monitoring systems usually involves obtaining vital signs and diagnosing complex physiologic conditions. And treatments, clinical studies and data collection.
0150Patient monitoring devices such as those described herein can include keyboards, touch screens, and other input devices that allow the clinician to interact with the device. By using such a user interface device, a clinical person can input login information such as a user name and a password, for example. In some cases, the patient monitoring device may require a clinician to log in to the device, for example, before granting access to one or more of the features provided by the device and /. Or, before granting access to specific information available on the device. The nurse station system (central monitoring system) described herein is an example of a monitoring device that may be required to log in when used by clinical personnel. For bedside patient monitors, clinicians may be required to log in before initializing new patient monitoring. Even if you are not required to log in before using the patient monitoring device, the clinician will have some with the input device to perform a particular action out of the set of available actions provided by the patient monitoring device. You may be asked for a type of dialogue.
0151For example, user input may be required when configuring the patient monitoring device in a desired fashion. In some embodiments, the clinician can use the input device to modify the content presented on the display of the patient monitoring device, or the formatting of that content, to suit the clinician's environmental settings. .. In some cases, a nurse may use an input device to provide a central monitoring device, for example, only patient monitoring information assigned to that particular nurse (rather than displaying all patients on the entire floor). It can be manually configured to display. Clinicians can also use input devices to change patient monitoring settings, such as physiological parameter values, raw data, alarm types, physiological parameter alarm limits (eg, alarm thresholds), etc. It is possible to change the options calculated from.
0152Due to the time constraints of clinical personnel in busy hospitals, this process of manually interacting with patient monitoring devices (eg, by physically manipulating input devices) is especially throughout the day. If it needs to be repeated many times, it can be a heavy burden. In some cases, the time required to manually interact with a patient monitoring device to access a particular function or configure the device can even threaten the patient's health, especially in imminent situations. For at least the reasons mentioned above, hospital equipment, such as bedside patient monitors, central monitoring devices, has the ability to automatically detect the presence of a clinical person, and, for example, the clinical person whose presence has been detected. It would be advantageous to have the ability to take some given action based on the information about who the person is.
0153In some embodiments, a neighborhood display observer adapts the display to the current observer (eg, according to preferences, priorities, or user consent) to provide an advanced monitoring system with different needs and preferences of the user. Adapt to your advantage. Therefore, the parameters and formats displayed can be selected by default according to a predefined user class or customized for a particular individual or individual group. One way to identify a person in the vicinity of a neighborhood indicator is by ID tag or other token. The ID tag can transmit the presence of the user to the proximity display monitor by, for example, radio frequency identification (RFID) or wireless transmission. When there are a plurality of users within the neighborhood range of the neighborhood display monitor, it is possible to determine which user is supported by the priority method or the user's consent.
0154In some embodiments, the proximity indicator has a monitor and an interconnected sensor that transmits light radiation to the tissue site and is attenuated by pulsatile blood flow within the tissue site. Generates a sensor signal that responds to radiation. The monitor calculates the physiological parameters that respond to the sensor signal and uses the neighborhood display to display the physiological parameters on the screen according to the display preferences associated with the user in the vicinity of the monitor. It is possible. A display can be incorporated into the monitor to present the physiological parameters for viewing by the therapist. It is possible to incorporate a transmitter / receiver in the monitor, and the transmitter / receiver can respond to the identification signal. This identification signal can be made to correspond to the person in charge of treatment. The transmitter carried by the therapist can transmit the identification signal within a range corresponding to the distance from the monitor, for example, so that the display can be seen reasonably. Physiological parameters can be presented to the display on a screen with preferred settings according to the display environment settings associated with the therapist indicated by the identification signal.
0155In some embodiments, the proximity display monitor comprises a monitor having a display and a wireless transmitter / receiver. The wireless transmitter / receiver can respond to an identification signal indicating that any user, each of whom has a unique display environment setting, is in the vicinity of the monitor. Physiological parameters can be presented to the display on a screen with preferred settings according to the display preferences.
0156In some embodiments, the proximity display monitor has an optical sensor attached to the meat tissue site. The sensor signal can respond to the light radiation transmitted from this sensor, and the sensor signal can be detected by the sensor after being absorbed by the pulsatile blood flow in the tissue site. This sensor signal can be transmitted to the monitor, which processes the sensor signal to derive physiological parameters that respond to each component of pulsatile blood flow. Information about who the user is in the vicinity of the monitor can be transmitted to the monitor via a wireless signal. Screen preferences can be determined, for example, from information about who the user is, which can be used to display physiological parameters on the monitor display.
0157In some embodiments, the proximity display monitor includes a processor and a display. The processor is capable of responding to sensor signals that are generated from light radiation transmitted within the meat tissue site and are detected through attenuation by pulsatile blood flow within the meat tissue site. The processor can be configured to calculate multiple physiological parameters that represent each component of pulsatile blood flow. The display can provide a visual representation of the physiological parameter values for viewing by nearby users. Information about who is a nearby user can be obtained by wireless communication means. Physiological parameters can be presented on the display by screen environment setting means. Information about who the user is can be associated with screen preferences by look-up table means.
0158FIG. 10 shows a physiological measurement system with a non-invasive sensor 1010 mounted on tissue site 1000, a patient monitor 1020, and an interface cable 1030 interconnecting the monitor 1020 and the sensor 1010. Includes. This physiologic monitoring system provides advanced features such as multi-wavelength sensors, and (other than or in addition to the physiological parameters of pulse oximetry) carbon monoxide hemoglobin, methemoglobin, and total hemoglobin, to name a few. In addition to the advanced process of finding physiological parameters such as, pulse oximetry can be incorporated. The patient monitor 1020 has a proximity display 1021, which presents measurements of selected physiological parameters and alerts the therapist if these parameters exceed a predetermined limit. Provide a visible and audible alarm mechanism. The patient monitor 1020 also features key 1022, which controls display and alarm functions, among other items. The neighborhood display 1021 and key 1022 provide a user interface that organizes and displays many parameters so that the therapist can easily grasp the patient's condition (eg, using a portable handheld device).
0159FIG. 11 shows various screens 1150 of neighborhood display 1021 (FIG. 10) configured to accommodate the presence of a particular user 1130 and the display preferences of that user. Each user may be one of a variety of therapists, such as a treating physician or an attendant nurse. In one embodiment, neighborhood display 1021 (FIG. 10) can also accommodate any user of a particular group of users.
0160Whether a particular user or user group exists or is in close proximity to the monitor 1020 (FIG. 10), as described later with reference to FIG. 13, is a user-worn RFID (radio frequency identification) tag or other. It can be located by wireless communication. Then, one or more specific screens can be displayed on the display according to a predetermined display environment setting associated with the user. In this way, the neighborhood display 1021 (FIG. 10) is adapted to the monitor user's environment settings. An "RFID tag" (or simply a "tag") includes any wireless communication device that can remotely identify a user in the vicinity of a monitor. Included in tags are devices such as, but not limited to, badges, tags, clips, bracelets, pens, etc. that contain RFID chips or other wireless communication components. Tags also include mobile computing devices with wireless communication capabilities, such as smartphones, PDAs, and pocket PCs.
0161As shown in FIG. 11, for example, when an anesthesiologist 1131 near the monitor is identified, the display changes to screen 1110 showing pulse rate trends. When nurse 1132 enters the vicinity of the monitor, the display changes to screen 1120 showing pulse oximetry parameters, plethysmograph, and alarm limits. As the respiratory therapist 1133 enters the vicinity of the monitor, the display changes to screen 1140 showing pulse oximetry, abnormal hemoglobin, and perfusion index.
0162In some embodiments, the neighborhood display monitor automatically dims the display to a dimming setting in response when all neighbors exit the neighborhood. This feature is beneficially intended to keep the patient out of the way during sleep or when falling asleep. In some embodiments, the neighborhood indicator automatically suppresses pulse "beep" and other non-essential sounds in response when there are no nearby users.
0163FIG. 12 shows a neighborhood display monitor 1200 that responds to the neighborhood user 1280 to display the calculated parameters according to the user's display environment settings. As shown in FIG. 12, the proximity display monitor 1200 has, in some embodiments, a front end 1210 that interfaces with an optical sensor (not shown). The optical sensor generates a sensor signal in response to the pulsatile blood flow of the patient's tissue site. Optical sensors are described in the above-mentioned US Patent Application No. 11/367013 (subject "Multiple Wavelength Sensor Emitters"). The front end 1210 adjusts and digitizes the sensor signal 1212 and inputs it to the digital signal processor (DSP) 1220. DSP The 1220 derives the physiological parameter 1222 according to the sensor signal 1212. The calculated parameter values are transmitted to the display driver 1230, which presents those parameters on the display 1270 according to a predetermined format. Monitors with front-ends and DSPs are described above in US Patent Application No. 11/366208 (subject "Noninvasive Multi-Parameter Patient Monitor").
0164As further shown in FIG. 12, the neighborhood display monitor 1200 has a transmitter / receiver or receiver 1240, a look-up table 1250, and a display environment setting 1258. The user 1280 has an ID tag 1260 that identifies the user 1280 to the transmitter / receiver 1240. When the user 1280 is in the vicinity of the neighborhood display monitor 1200, the ID tag 1260 can communicate with the transmitter / receiver 1240 to identify the user 1280. In one embodiment, the transmitter / receiver 1240 is an RFID reader, and the ID tag 1260 has an RFID chip containing a user code 1252 embedded therein. In another embodiment, the transmitter / receiver 1240 complies with one or more short-range wireless communication standards, such as Bluetooth®. User 1280 can activate communication with the neighborhood display observer 1200 (for example, by operating a button on ID tag 1260 or similar activation means), and user code 1252 sends to transmitter / receiver 1240. Will be done. The transmitter / receiver 1240 transmits the user code 1252 to the DSP 1220. DSP The 1220 can access the look-up table 1250 to derive the display preference 1258 from the received user code 1252. Display preference 1258 indicates display parameters 1222 and screen format 1224, which are transmitted to the display driver 1230.
0165As further shown in FIG. 12, in some embodiments, the lookup table 1250 associates user code 1252 with the caregiver ID 1256 and priority 1254. When a plurality of users come in the vicinity of the neighborhood display monitor 1200, which display environment setting 1258 is used to configure the display 1270 is determined by the priority 1254.
0166FIG. 13 shows the display preference screen 1300, which provides information to a specific row in the lookup table 1250 (FIG. 12). The setup or registration process allows the user to specify one or more profiles, which, for example, have various options for setting display preferences, calculating parameters, and triggering alarms. including.
0167FIG. 14 is a schematic diagram of the patient monitoring device 1400 capable of automatically detecting the presence of the clinician token 1410. In some embodiments, the clinician token 1410 is, for example, a portable item intended to be worn or carried by the clinician throughout the day. The patient monitoring device 1400 can recognize the presence of the clinician based on the presence of the clinician token.
0168Patient monitoring device 1400 includes a detector (eg, such as communication module 1402). The patient monitoring device 1400 also includes a display 1404 and a processor 1406. Using processor 1406, for example, clinically useful tasks based on physiological information collected from one or more patients (eg, calculating physiological parameter values, identifying alarm conditions, from a clinician user interface). It is possible to output physiological information, notify clinicians of alarm status, etc.). The patient monitoring device 1400 also facilitates interaction with clinical personnel, as described herein, with other modules that assist in patient monitoring (eg, an interface that receives physiological information from a medical sensor or computer network). It is also possible to include a user interface, etc.). In some embodiments, the communication module 1402 is a transmitter, receiver, or transmitter / receiver. Other types of communication modules can also be used. In some embodiments, the communication module 1402 is a short-range transmitter / receiver. The short-range transmitter / receiver may be, for example, a Bluetooth (registered trademark) compatible transmitter / receiver. Bluetooth® is a wireless protocol for exchanging data between devices over relatively short distances. Communication module 1402 may also be an infrared transmitter / receiver, RFID tag, or any other means of communication (eg, short-range communication).
0169Depending on the embodiment, the communication module 1402 can detect a signal from the remote device within the detection range 1420. The size of the detection range 1420 can be determined, for example, by the strength of the communication signal from the communication module 1402. The size of the detection range 1420 can also be affected by the surroundings of the patient monitoring device 1400. In some embodiments, the detection range 1420 is configured to have a radius of 30 feet or less. In some embodiments, the radius of the detection range 1420 is 20 feet or less. In some embodiments, the radius is 10 feet or less, and in some embodiments, the radius is 5 feet or less, or 3 feet or less.
0170The clinician token 1410 also includes a communication module 1412, which may be, for example, a transmitter, receiver, or transmitter / receiver, but other types of communication modules may also be used. As in the case of the patient monitoring device 1400, the communication module 1412 included in the clinician token 1410 may be a short-range transmitter / receiver, such as a Bluetooth® transmitter / receiver. The patient monitoring device 1400 is capable of detecting the presence of a clinician, which is possible, for example, based on the recognition of one or more communication signals from the clinician token 1410. The communication signal from the clinician token 1410 can come, for example, as a response to a communication activated by the patient monitoring device 1400, or the communication signal from the clinician token 1410 can be the clinician token itself. Can be invoked by. For example, many different methods can be used to initiate wireless communication between remote devices.
0171The clinician token 1410 can also carry information, for example, in memory. This memory may be, for example, a volatile memory or a non-volatile memory. The information may be hard-wired to the clinician token 1410 and may be programmable. In some embodiments, the clinician token 1410 comprises a clinician ID 1414 specific to the clinician to whom the clinician token 1410 is assigned. The clinician token 1410 can also contain other information, for example, when the clinician's login information (eg, username and password) or the presence of the clinician is recognized. Code or other indicators that trigger certain actions to be taken by patient monitoring device 1400, such as logging in a clinical person, setting configuration preferences for patient monitoring device 1400, enabling features, and so on. And so on.
0172The clinician token 1410 can also include an input module 1416, which the clinician can use to force the communication module 1412 to perform remote communication with which the remote communication partner is. , For example, the patient monitoring device 1400, or any other device that is part of the hospital's patient monitoring network. For example, the input module 1416 can include one or more buttons, or other input devices, which clinical personnel can use to make the patient monitoring device 1400 aware of the clinical personnel's presence. , It is possible to activate communication with the patient monitoring device 1400. In addition, clinicians can use the input module 1416 to call an emergency response team, for example, when they discover that a particular patient needs emergency response, or to silence surveillance alarms. Is. The input module 1416 can also be used for other purposes, depending on the application.
0173In some embodiments, the clinician token 1410 may be a mobile phone, notebook computer, PDA device, headset, etc., any of which may be Bluetooth® capable, for example. In some embodiments, the clinician token 1410 is a pager or other notification device that notifies the clinician of a physiological parameter alarm state as described herein. In some embodiments, the clinician token 1410 is an active or passive RFID tag. The active RFID may be, for example, WiFi-enabled. In some embodiments, the clinician token 1410 is a barcode (eg, two-dimensional or three-dimensional). In some embodiments, the clinician token 1410 is part of the clinician's body. For example, the clinician token 1410 may be a fingerprint, retina, clinician's face, and so on. In such an embodiment, the clinical person ID 1414 is, in fact, a unique biometric signature of the clinician. Communication module 1402 can be selected based on the type of clinician token 1410 with which it communicates. For example, the communication module 1402 in the patient monitoring device 1400 may be an RFID interrogator, a barcode scanner, a fingerprint scanner, a retinal scanner, a face recognition device, or the like.
0174In some embodiments, the Clinic Agent Token 1410 can advantageously be registered with the Patient Monitoring Device 1400, but has previously been with, for example, the Patient Monitoring Device 1400, Patient Monitoring System, Hospital, etc. A consumer device that is not connected or related. For example, the clinician token 1410 is a non-specialized consumer device that communicates with the patient monitoring device 1400, or any other device configured to detect the presence of the clinician token. You can. For example, many clinicians already have a personal cell phone and wear it all day long. In some embodiments, the clinician's personal electronic device can function as the clinician token 1414 (eg, after the registration process described herein later). This can be advantageous in that each clinician is given a dedicated clinician token 1410 without requiring investment on the part of the treatment facility such as a hospital. On the other hand, in some embodiments, the clinician token 1410 is, for example, a dedicated device given to the clinician primarily to operate on a patient monitoring device (eg, 1400) that has presence detection capabilities. is there.
0175In some embodiments, the clinician token 1410 can respond, for example, to a question from a patient monitoring device only with a routine response signal (eg, clinician ID 1414). However, in some embodiments, the clinician token 1410 is capable of transmitting multiple (and / or variable) signals and information to the patient monitoring device 1400. The Clinic Token 1410 can include a processor, for example, a processor that runs a software application that provides the Clinic Token 1410 with the functionality of various intelligent communications with the patient monitoring device 1400. is there.
0176In some embodiments, the presence detection feature is implemented by using the clinician token 1410 with the patient monitoring device 1400 after completing the registration process. For example, during the registration process, a unique clinician ID 1414 assigned to a particular clinician can be given to the clinician token 1410. This clinician ID can be stored, for example, in a database accessible from the patient monitoring device 1400, which allows the patient monitoring device 1400 to be stored in the clinician token 1410. It is possible to identify the clinician based on. The clinician ID 1414 can also be associated in the database with, for example, the login information assigned to that clinician to access the patient monitoring device 1400.
0177The database can also store instructions for one or more desired actions of a clinician when a particular patient monitoring device detects the presence of the clinician. The database can store the clinical person's configuration environment settings for the patient monitoring device. For example, certain physiological parameters and other monitoring information displayed on display 1404 of patient monitoring device 1400 may be configurable. For example, in the case of a bedside patient monitor, the display 1404 is a numerical indicator of a particular physiological parameter, a graphical indicator of that physiological parameter, a visual alarm, multiple physiological parameters at the same time, a physiological parameter signal from the patient sensor. It may be possible to display the signal quality of. The clinician's configuration preferences can instruct the patient monitoring device 1400 what type of information to display and how to format the displayed information. Clinician configuration preferences for the patient monitoring device 1400 can also include patient monitoring settings (eg, physiological parameter alarm limits, etc.).
0178For example, in the case of a central monitoring system such as the type described herein, the clinician's configuration preferences also include the physiological parameters (or other) displayed on the central monitoring system for each patient being monitored. It is possible to include the type and display format of the monitoring information). In addition, the clinician's configuration preferences can include a fixed or dynamic list of rooms (or patient names) displayed on the patient monitoring device. These rooms (or patients) may be, for example, the rooms (or patients) currently assigned to that particular clinician. However, in general, the clinician's configuration preferences associated with the clinician ID 1414 can include any configurable feature, aspect, or function of the patient monitoring device 1400.
0179The database can associate a specific action of the patient monitoring device 1400 that the clinician wants to activate when entering the detection range 1420 of the patient monitoring device 1400 with the clinician ID 1414. Examples of such actions that can be triggered automatically when the presence of a clinician is detected are described herein. In addition, in some embodiments, the database can also associate a priority level with clinician ID 1414. The priority level can indicate which clinician should be given priority access to the medical monitoring device 1400 (for example, if multiple clinicians are detected simultaneously within the detection range 1420). ..
0180In some embodiments, login information assigned to the clinician, monitoring device configuration preferences, a list of actions that are automatically triggered when the clinician's presence is recognized, priority levels, and / or other information. , Can be stored in the clinician token 1410 itself. In such an embodiment, this information can be transmitted directly from the clinician token 1410 to the patient monitoring device 1400, in which the patient monitoring device 1400 is stored in the token 1410. This is in contrast to retrieving information from the database using ID 1414. Using other methods, for example, certain actions (eg, login, reconfiguration, etc.) that the clinician wants the patient monitoring device 1400 to perform when it enters the detection range 1420 of the patient monitoring device 1400. It is possible to associate clinician ID 1414 with.
0181In some embodiments, the patient monitoring device 1400 will be able to detect the presence of a particular clinician based on that clinician's token 1410 after the enrollment process is complete. Based on the recognition of the presence of a clinician, it becomes possible to take actions specific to that clinician. In some embodiments, the processor 1406 of the patient monitoring device 1400 is configured to execute the detection logic 1408 that determines when the clinician token 1410 is present and when it is not present in the detection range 1420 of the patient monitoring device 1400. .. In some embodiments, the detection logic 1408 must be met to determine that the clinician token 1410 is present in the detection range 1420, or to perform some clinician-specific action or other. Is a set of conditions.
0182FIG. 15 is a flowchart showing a detection method 1500 for detecting the presence of a clinician token (eg, 1410) within the detection range of the patient monitoring device. Detection method 1500 begins, for example, in standby state 1502, at which point patient monitoring device 1400 has not detected the presence of a clinician. In standby state 1502, for example, it is possible to manually access the functions and information that can be provided by patient monitoring device 1400. The standby state 1502 also allows the clinician to manually configure the patient monitoring device or interact with the patient monitoring device using an input device such as a keyboard, mouse, or touch screen. Thus, in standby state 1502, it is advantageous for clinicians who have not been assigned the clinician token 1410 to be able to use and interact with the patient monitoring device 1400.
0183In decision block 1504, processor 1406 executes detection logic 1408 to determine if a signal from clinician token 1410 has been detected. For example, in some embodiments, the communication module 1402 of the patient monitoring device 1400 is capable of transmitting a clinician token discovery signal, eg, continuously or periodically. In decision block 1504, processor 1406 is capable of determining whether a response from the clinician token 1410 has been received for the discovery signal of the patient monitoring device. Alternatively or additionally, the clinician token 1410 can be configured to transmit discovery signals that the patient monitoring device 1400 can detect, eg, continuously or periodically. The response signal from the clinician token 1410 is, for example, the clinician ID. It can contain 1414 or other information. If no signal from the clinician token 1410 is detected, detection method 1500 returns to standby state 1502. On the other hand, if the signal from the clinician token 1410 is detected, the detection method 1500 can proceed to the next decision block 1506.
0184In decision block 1506, processor 1406 executes detection logic 1408 to determine if the detected signal from the clinician token 1410 has exceeded the signal strength threshold. This test can serve, for example, as an estimate of the physical distance between the clinician token 1410 and the patient monitoring device 1400. For example, whether the patient monitoring device 1400 has a detection event and / or whether it takes a specific predetermined action when the clinician detects it is the physical between the clinician and the patient monitoring device 1400. It can be configured to depend on an estimated distance. This can be useful, for example, when there is a central monitoring system near a busy area where many clinicians often pass by. In such situations, the signal strength threshold used for decision block 1506 is at a relatively high level in order to limit the clinician detection event to situations where the clinician is relatively short distance from the central monitoring system. It is advantageous to set to. Thus, the signal strength threshold may be configurable, for example, based on the desired physical distance from the clinician token 1410 such that the clinician presence detection event is not recognized. If the detected amplitude intensity of the signal from the clinician token 1410 falls below the signal intensity threshold used in determination block 1506, detection method 1500 returns to standby state 1502. On the other hand, when the signal strength exceeds the threshold value, the detection method 1500 can proceed to the next determination block 1508.
0185In detection block 1508, processor 1406 executes detection logic 1408 to determine if the signal strength of the signal from the clinician token 1410 exceeds the signal strength threshold over a nearby time longer than a time threshold. Although the test was passed by a clinician near the patient monitoring device 1400, it was only transient and did not stay in the detection range 1420 for a long time worthy of a clinician presence detection event. In some cases, it can help to avoid recognizing the presence detection event of the clinician. This test also helps prevent false occurrences of clinician presence detection events in busy areas around the patient monitoring device 1400, which many different clinicians often pass by on a daily basis. there is a possibility. The neighborhood time threshold used in determination block 1508 may be configurable. In some embodiments, the neighborhood time threshold can be set to, for example, 1 second, 2 seconds, or 5 seconds. However, other neighborhood times are also available. If the neighborhood time of the detected clinician token 1410 does not exceed the neighborhood time threshold used in decision block 1508, detection method 1500 returns, for example, to standby state 1502. On the other hand, if the neighborhood time of the clinician token 1410 exceeds the neighborhood time threshold, detection method 1500 can proceed to block 1510.
0186At block 1510, the clinician presence detection event is recognized. In this case, the patient monitoring device 1400 can, for example, enable or activate some predetermined action based on the clinician's identity associated with the recognized clinician token 1410. For example, the patient monitoring device 1400 may log in a clinician, change configuration settings, or allow some action or function that would normally be restricted in the absence of the clinician. Is possible. In the detection method 1500 shown in FIG. 15, whether or not the clinician presence detection event has occurred depends on the signal strength of the signal from the clinician token 1410 and the signal from the clinician token 1410 exceeding the signal strength threshold. It depends on the length of time you spend. However, in some embodiments, the clinician presence detection event may be recognized solely based on the signal strength of the signal from the clinician token 1410, or the signal from the clinician token 1410 is detected. It may be recognized based only on the length of time it is.
0187In some embodiments, the detection logic 1408 may include other factors, whether based on the signal strength of the signal from the clinician token 1410 and the neighborhood time, respectively, or a combination thereof. It is possible. For example, recognition of a clinician presence detection event can be at least partially based on information about who the clinician is (depending on the patient monitoring device 1400, only certain clinicians may have access to it. Because). In addition, recognition of clinician presence detection events can be based on priorities assigned to clinicians. For example, assigning a nursing supervisor a higher priority than other shift nurses, the presence of a nursing supervisor, even if the presence of a non-nursing supervisor is already recognized by the patient monitoring device 1400. Can be recognized by the patient monitoring device 1400. In the opposite situation, on the other hand, it is possible to prevent a new clinician presence detection event. That is, it is possible to prevent the detection of a low-priority clinical person from becoming a detection event when the presence of a high-priority clinical person is already recognized by the patient monitoring device 1400. The priority level is an example of an unbalanced condition that can be used in detection logic 1408 when multiple clinician tokens meet other requirements for triggering a clinician detection event at the same time. .. Other conditions can be used as conditions for breaking this equilibrium.
0188It should be understood that the detection logic 1408 can include a wide variety of factors, depending on the hospital, the type of medical device involved (eg, patient monitoring device, or some other type of medical device). .. Furthermore, such factors can be considered in various ways in the detection logic 1408. For example, the detection logic 1408 tells when the threshold was exceeded, when the Boolean expression became true or false, when the fuzzy formula became true or false, when the mathematical equation was met or not met. , When compound word rules were met or not, and so on.
0189If the clinician detection event is recognized, for example, according to detection method 1500, the patient monitoring device 1400 can respond in a variety of ways. For example, the patient monitoring device 1400 can trigger a predetermined action based on the information of who is the clinician with the token detected in the vicinity of the patient monitoring device 1400. In some embodiments, the predetermined action is for the patient monitoring device 1400 to automatically log in the clinician, in which case the clinician is required to, for example, physically interact with the input device. Absent. This process saves clinicians time and, in some cases, saves the patient's life. As described herein, the clinician login information can be sent from the clinician token 1410 to the patient monitoring device 1400 and retrieved from the database using the clinician ID 1414 from token 1410. It is also possible.
0190In some embodiments, the patient monitoring device enables or disables a particular function based on the detection content of the clinician token 1410. For example, patient monitoring devices can enable / disable menus and buttons (eg, alarm limit menus, alarm silence, all mute, etc.) based on detected clinical personnel credentials. In some embodiments, the patient monitoring device 1400 initiates transmission of patient monitoring information to the remote device as soon as it detects the presence of a clinician. For example, a bedside patient monitor that can capture a patient's breath sounds can automatically initiate transmission of that breath sound to a clinician's Bluetooth® headset (this). The Bluetooth® headset can also act as a clinician token 1410). In other embodiments, the patient monitoring device 1400 can initiate transmission of any type of monitoring information (eg, via the Internet) to the remote device as soon as it detects the presence of a particular clinical person. Is. For example, the patient monitoring device 1400 can transmit patient oxygen saturation trend data to a clinician's computer for later analysis and diagnosis. The patient monitoring device 1400 also includes any other type of patient information (eg, medical parameter values and / or trend data, in response to the detection of the presence of a particular clinician in the vicinity of the patient monitoring device 1400. Video and / or audio from the room) can be transmitted, for example, to the clinician's computer or some other device.
0191In some embodiments, the patient monitoring device can automatically update its configuration based on the detected configuration environment settings of the clinician. For example, the patient monitoring device 1400 can change the content of the information to be displayed or the format of the information to be displayed. Such configuration changes can be made based on the settings instructed by the clinician during the registration process of the clinician token 1410. An example of such an embodiment is shown in FIG. In some embodiments, the patient monitoring device modifies the layout of the display screen (eg, the number of parameters to display, the waveforms to display, trends, and other screen controls). The display layout can be selected from predefined layouts, or the clinician can create a custom layout. The same applies to other configuration settings. Configuration settings can be associated with clinicians at the individual user or group level. It is possible to establish a hierarchy of layout modes in case of layout conflicts.
0192The patient monitoring device 1400 can also update other configuration settings based on the clinician's registered preferences. These can include, for example, physiological parameters alarm limits, alarm silence, all mute, averaging times, algorithm modes, and so on. In addition, the patient monitoring device 1400 can automatically generate some type of report (eg, a report of all alarm conditions registered by the monitor over a given time period).
0193In addition, it is possible to modify the alarm notification and behavior in response to a clinician neighborhood detection event. For example, if a clinician is approaching a bedside patient monitoring device 1400 that is currently registering an alarm state, the alarm will automatically trigger when the clinician recognizes that the patient has entered a specific radius of the patient monitoring device 1400. It is possible to be quiet. In some embodiments, the method by which the patient monitoring device 1400 notifies the alarm condition may depend on the physical location of the clinician. For example, if the patient monitoring device 1400 detects an alarm condition while the clinician is already in the vicinity of the patient monitoring device 1400, the patient monitoring device 1400 should not issue an audible alarm or issue a low volume audible alarm. Is possible. The volume of the alarm can be adjusted in other ways based on the detection of the presence of a clinician. Similarly, in such a scenario, the patient monitoring device 1400 can be configured not to send an alarm to the central monitoring device. In some embodiments, the medical monitoring device does not notify or paging other clinical personnel if a clinical person is already present at the time of the alarm. The alarm notification operation of the medical monitoring device can be changed in various ways based on the detection of the presence of a clinical person. A medical monitoring device having a clinical person neighborhood recognition function can enable a detected clinical person to confirm his / her presence. As long as the presence of a clinician is detected, it is possible to change the length to the end of the alarm (eg, it can be extended).
0194In some embodiments, the patient monitoring device 1400 switches the language of the textual information displayed by the monitoring device in response to the detection of the presence of the clinician, according to the clinical person's language environment settings. In some embodiments, the patient monitoring device identifies and performs on-device confirmation that may be required for risk management based on the detection of one or more clinical personnel in the vicinity of the monitoring device. To do. In some embodiments, the patient monitoring device provides the number of clinician visits to the patient's bedside, the time of each visit, the length of each clinician visit, and the time it takes for the clinician to respond to the alarm. , Others are logged. Clinicians can be allowed to chart parameters measured by a monitoring device, for example, electronic medical care with credentials based on the results of detecting who the clinician is. It is possible to be allowed to chart into records. Various other types of actions and / or configuration changes, or combinations thereof, described herein are also automatically invoked based on the fact that a clinician was detected in the vicinity of patient monitoring device 1400. Can be directed to.
0195FIG. 16 shows an example of a graphical user interface 1600 for a nurse station or central patient monitoring device. The graphical user interface 1600 has the same functions as the graphical user interface described with reference to FIG. For example, the graphical user interface 1600 includes a patient status display area 1610. The patient status display area 1610 includes a plurality of patient status modules 1612, each of which has a graphical status indicator 1614. The graphical user interface 1600 also includes a patient monitor view area 1620 and a history view area 1630.
0196As shown in FIG. 9, the central patient monitoring device includes several patient status display areas, each displaying monitoring information from different patients. However, unlike Figure 9, which shows the status of more patients than one nurse can handle individually, Figure 16 shows only the patients assigned to a particular clinician. doing. The display of the central patient monitoring device can be automatically updated from the display of FIG. 9 to, for example, the display of FIG. 16 when the presence of a clinical person is recognized. In this way, the clinician can quickly and quickly see the condition of each patient assigned to him by simply approaching the central patient monitor without actually having a physical dialogue with the central patient monitor. It is possible to check conveniently. In addition, the neighborhood detection features described herein can be used to facilitate the assignment of clinical personnel to patients at nurse stations. For example, it is possible to have a patient automatically added to the view of FIG. 16 if a clinician is detected near the patient's bedside monitor during a given time period.
0197FIG. 17 is a flowchart showing a method 1700 for determining when to disable a clinician-specific action that has already been enabled by the patient monitoring device 1400 based on the detection of the presence of a clinician. Is. In Method 1700, first, in block 1702, some action specific to the clinician has already been enabled, as described herein. Method 1700 then proceeds to decision block 1704 and decision block 1708. For example, Method 1700 detects if an already detected clinician remains in the vicinity of the patient monitor, while at the same time a higher priority clinician arrives in the vicinity of the patient monitor. It is possible to detect and include. For example, the process shown in decision block 1708 can generate an interrupt signal when the presence of a higher priority clinician is detected.
0198In decision block 1704, processor 1406 executes detection logic 1408 to determine if the strength of the signal from the clinician token 1410 has fallen below a signal threshold. This threshold may be the same as the threshold used in the determination block 1506 of FIG. Alternatively, these two thresholds may differ in order to give the detection system some degree of hysteresis. This hysteresis causes the clinician token 1410 to repeatedly switch between presence and absence at short intervals when the signal strength from the clinician token 1410 happens to be approximately equal to the selected threshold. Given for protection against potentially perceived situations. If the strength of the signal from the clinician token 1410 does not fall below the signal threshold, method 1700 returns to block 1702 and continues to enable clinician-specific actions. On the other hand, if the strength of the signal from the clinician token 1410 falls below the threshold used in judgment block 1704, method 1700 proceeds to judgment block 1706.
0199In detection block 1706, processor 1406 executes detection logic 1408 to determine if the strength of the signal from the clinician token 1410 is below the signal threshold corresponding to the absence time longer than a certain time threshold. Therefore, the combination of decision blocks 1704 and 1706 would determine if the clinician token was outside a particular range for a particular length of time. In some embodiments, this time threshold may be variable, for example, depending on the content of the information displayed by the medical monitoring device 1400. For example, if the patient monitoring device 1400 displays sensitive personal information, the time threshold can be relatively short to protect patient privacy.
0200If the absence time does not exceed the time threshold used in Judgment Block 1706, Method 1700 returns to Block 1702 and continues to enable clinician-specific actions. On the other hand, if the absence time exceeds the time threshold, method 1700 proceeds to block 1710. In block 1710, the clinician is recognized as no longer in the vicinity of patient monitoring device 1400. Therefore, the previously enabled actions specific to the clinician are disabled. In such a case, the patient monitoring device 1400 can return to a state similar to the standby state 1502 described with reference to FIG. In some embodiments, the actions performed by the patient monitoring device 1400 in block 1710 may be substantially the opposite of the actions performed by the monitoring device in block 1510 of FIG. For example, if the presence of a clinician is first detected and the clinician automatically logs in to the patient monitoring device 1400, block 1710 can log out this clinician. Similarly, if the configuration of patient monitoring device 1400 is changed based on the detected clinician's preferences, block 1710 can restore those configuration changes to, for example, the default state. ..
0201With reference to decision block 1708 here, processor 1406 executes detection logic 1408 to determine if the presence of a higher priority clinician has been detected. Detection of such clinicians can proceed, for example, according to the detection method 1500 described with respect to FIG. As described herein, a priority value that can act as an unbalanced condition to determine which clinician should be aware of when more than one clinician is detected. , Can be assigned to each clinical person. If no higher priority clinician is detected in decision block 1708, method 1700 returns to block 1702. On the other hand, if a higher priority clinician is detected in judgment block 1708, method 1700 can proceed to block 1710. Block 1710 negates the already detected awareness of the presence of a clinician and recognizes the presence of a newly detected, higher priority clinician.
0202FIG. 18 is a schematic diagram of a system that enables the patient monitoring device 1800 to automatically detect the presence of the clinician token 1810. Patient monitoring device 1800 and clinician token 1810 are considered to be similar to, for example, patient monitoring device 1400 and clinician token 1410 described with respect to FIG. 14 herein, except as indicated by differences. Good. In the embodiment shown in FIG. 18, patient monitoring device 1800 detects the presence of clinician token 1810, for example, with the assistance of one or more WiFi access points 1830-1832. WiFi access points 1830-1832 can be advantageously distributed throughout the patient care environment in which patient monitoring is performed. WiFi access points 1830-1832 can operate based on, for example, the IEEE 802.11 standard.
0203The communication module 1802 of the patient monitoring device 1800 may be, for example, a WiFi-enabled radio for communicating with the WiFi access points 1830-1832. In some embodiments, the clinician token 1810 is a WiFi-enabled RFID tag. By communicating with WiFi access points 1830 to 1832, the patient monitoring device 1800 can triangulate its position with reference to those WiFi access points. Similarly, the position of the clinician token 1810 can be triangulated. Thus, for example, the patient monitoring device 1800 can determine the approximate position of the clinician token 1810 with respect to the patient monitoring device 1800 by using distributed WiFi access points 1830-1832. In some embodiments, the patient monitoring device 1800 can also enhance the position approximation performed, for example, using distributed WiFi access points 1830-1832, by communicating directly with the clinician token 1810.
0204FIG. 19 is a schematic view of a patient monitoring device network 1900 having a clinical staff neighborhood recognition function. The patient monitoring device network 1900 may be, for example, similar to that shown in FIGS. 1, 2, 6, and 7. The patient monitoring device network 1900 includes multiple bedside patient monitoring devices 1902, 1912, 1922 that monitor multiple patients 1906, 1916, 1926. In some embodiments, the bedside patient monitors 1902, 1912, and 1922 are similar to those shown, for example, in FIGS. 14 (1400) and 18 (1800), respectively. Bedside patient monitors 1902, 1912, 1922 are capable of detecting the presence of a clinician based on the clinician tokens 1904, 1914, 1924. The clinician tokens 1904, 1914, 1924 may be, for example, similar to those shown in FIGS. 14 (1410) and 18 (1810).
0205The Patient Monitoring Device Network 1900 also includes a nurse station system 1932 that remotely monitors each of the patients 1906, 1916, and 1926. The nurse station system (or central monitoring system) 1932 may be similar to that described herein. The patient monitoring device network 1900 can also include a registration database 1942. As described herein, the enrollment database 1942 has unique clinician IDs (eg, 1414, 1814) held by clinician tokens 1904, 1914, 1924, 1934, which tokens patient monitor. It can be associated with information that controls the devices 1902, 1912, 1922, 1932 in the presence of those patient monitoring devices. For example, the enrollment database 1942 can associate each unique clinician ID with login information, configuration preferences, and certain actions to be taken after the monitoring device recognizes the presence of the clinician.
0206In the illustrated patient monitoring device network 1900, each of the patient monitoring devices 1902, 1912, 1922, and 1932 can communicate with each other via the network 1950. In some embodiments, the network 1950 uses an open source communication standard to facilitate communication between various medical devices. Although not shown, the patient monitoring device network 1900 can also include WiFi access points, paging transmitters, pagers, and other devices described herein.
0207FIG. 20 is a schematic diagram of the hospital floor 2000 in which WiFi access points 2030 to 2034 are dispersed. By using WiFi access points 2030-2034, it is possible to estimate the physical location of medical devices 2002, 2004, patients 2010, 2012, and clinicians 2014, 2016. WiFi access points 2030-2034, or other detectors, can be distributed across the hospital floor or other physical area to provide WiFi coverage across the patient treatment area. In some embodiments, the respective coverage areas 2040-2044 of the WiFi access points 2030-2034 overlap each other. In some embodiments, WiFi access points 2030-2034 are located on almost every part of the hospital floor where it is necessary to track the location of medical devices 2002, 2004, patients 2010, 2012, and clinicians 2014, 2016. , WiFi access points At least three of the 2030-2034 coverage areas 2040-2044 are dense enough to overlap. Access points 2030-2034 can be mounted, for example, on the surface or interior of a wall, on the surface or interior of a ceiling, or otherwise.
0208Medical devices 2002, 2004 may be similar to those described herein. For example, in some embodiments, medical devices 2002, 2004 are patient monitoring devices. In some embodiments, medical devices 2002, 2004 are fitted with tracking tags or tokens 2006, 2008. Follow-up tags 2006, 2008 may be similar to the clinician tokens described herein. In some embodiments, the tracking tags 2006, 2008 are WiFi-enabled RFID tags, but other types of tracking tags may also be suitable. Each tracking tag 2006, 2008 may include a device ID.
0209As already mentioned herein, clinicians 2014, 2016 can carry clinician tokens 2022, 2024. The clinician tokens 2022, 2024 may be similar to those described herein. For example, in some embodiments, the clinician tokens 2014, 2016 are WiFi-enabled RFID tags. Depending on the embodiment, patient tokens 2018 and 2020 can also be attached to each patient 2010 and 2012. Patient tokens 2018, 2020 may be similar to the clinician tokens described herein. In some embodiments, Patient Tokens 2018, 2020 are WiFi-enabled RFID tags. These can be worn on the patient by bracelet or other suitable method. Each patient token 2018, 2020 may include a patient ID.
0210These tags and tokens within Hospital 2000 by communicating with medical device tracking tags 2006, 2008, clinician tokens 2022, 2024, and patient tokens 2018, 2020 using a distributed network of WiFi access points 2030-2034. It is possible to estimate the physical position of each of them. For example, WiFi access points 2030-2034 can be used to triangulate the location of each tag or token.
0211Figure 20 shows a distributed network of WiFi access points 2030-2034 that can be used to locate tracking tags 2006, 2008, clinician tokens 2022, 2024, and patient tokens 2018, 2020, but others. The device can be used for the same purpose. For example, in some embodiments, WiFi access points 2030-2034 are disabled and medical devices 2002, 2004, or other detectors with short-range transmitters and receivers are used to form ad hoc networks at those locations. .. Each medical device 2002, 2004 can operate as a node in an ad hoc network, and each node can share information about, for example, patients 2010, 2012, and clinicians 2014, 2016 surrounding each node. is there. Depending on the embodiment, the medical devices 2002 and 2004 are compatible with Bluetooth®, but other short-range wireless communication standards can also be used.
0212If the hospital floor 2000 contains several medical devices that are densely arranged, distributed medical devices 2002, 2004 may be, for example, Bluetooth®-enabled medical device tracking tags 2006, 2008, It can act as a network for tracking the location of patient tokens 2018, 2020, and clinician tokens 2022, 2024. In such embodiments, the physical location of each tracking tag or token may only be identifiable if it is within the range of a Bluetooth®-enabled medical device. Moreover, in some embodiments, the physical location of each tracking tag or token may not be accurately identifiable. This is because each Bluetooth®-enabled medical device may only be able to locate the tracking tag or token somewhere within the detection range of the medical device. Nevertheless, this level of tracking resolution is often sufficient.
0213In the embodiment shown in FIG. 20, it is possible to connect the location monitoring server to the WiFi access points 2030 and 2034 so as to be communicable. The location monitoring server can be configured to track the estimated location of each medical device 2002, 2004, each patient 2010, 2012, and each clinician 2014, 2016. The location monitoring server may include a display that displays this location information. In addition, a location monitoring server, or any other device, is capable of executing logic that can help enhance the serving capabilities of the patient monitoring system described herein. The location monitoring server can also be communicatively coupled with medical devices 2002, 2004.
0214The system shown in FIG. 20 can be used, for example, to enhance the patient monitoring system described herein. As mentioned above, the patient monitoring systems described herein are described, for example, in the physiological parameters of the monitored patient (eg, SpO).<sub>2</sub>, Respiratory rate, etc.) can notify clinicians when an alarm is triggered. In some embodiments, the clinical personnel assigned to monitor the patient are initially notified, for example, by paging, email, textual messages, and the like. If the first notified clinician does not respond within a given amount of time, the patient monitoring system can be configured to run an escalation algorithm that notifies one or more clinicians of the patient's alarm status. is there. In some embodiments, the clinician notifications sent in the presence of an alarm condition can be controlled, at least in part, using location-based rules. For example, position-based rules determine which clinical personnel should be notified of the alarm condition first, and which one or more clinical personnel should be notified if escalation is required. Is possible. Location-based rules can receive as input information from the system shown in FIG. 20 regarding their physical location (eg, patients 2010, 2012, and / or clinicians 2014, 2016).
0215Position-based rules may depend on, for example, the absolute or relative position of patients 2010, 2012, and / or clinicians 2014, 2016. For example, if patient 2010 goes into an alarm state, the clinician may be notified first if the patient is already assigned a clinician on the same floor (or some other area) of the hospital. It is possible. In some embodiments, it is possible to notify the clinician closest to the patient in the alarm condition, regardless of whether the clinician has already been assigned to the patient. In some embodiments, it is possible to notify the closest clinician to a patient who is in an alarmed state only if the clinician who has been properly assigned does not respond within a predetermined time. is there. In some embodiments, the nearby nurse is notified of the alarm status if the alarm status is particularly urgent and requires immediate attention. Various other position-based rules can be implemented.
0216It is also possible to control whether or not to allow the clinician to stop the alarm with a position-based rule. As disclosed herein, clinician tokens 2022, 2024 can include input modules (eg, 1416). One use of this input module is to remotely disable an alarm when a clinician is notified of the alarm and heads for the patient. However, in some embodiments, a position-based rule is implemented that can prevent the clinician from remotely disabling the alarm, for example, if the clinician is more than a certain threshold distance from the patient. It is possible.
0217It also uses the location information provided by the system shown in FIG. 20 to alert clinicians when patients 2010, 2012 are more than a certain threshold distance from the monitoring device assigned to the patient. Is possible. Although some examples of location-based rules have been described in the context of patient monitoring systems, the information provided by the system shown in Figure 20 can be used to implement different location-based rules for many different medical devices. It is possible. For example, to determine whether to perform an action if the selected action depends entirely (or partially) on the device, the clinician, and / or the estimated physical distance of the patient. The rule of is one such position-based rule.
0218In some embodiments, location-based rules can also be provided when configuring medical devices 2002, 2004 (eg, when configuring patient monitoring settings). For example, a patient monitoring device of the type described herein may be configured with different physiological parameter alarm limits for each ward in which the patient monitoring device is located. For example, the alarm limit for neonatal pulse rate should generally be set differently than for adult pulse rate. Therefore, it may be desirable to notify the clinician if an attempt is made to monitor a patient outside the neonatal room using a monitoring device with an alarm limit for the newborn. This is possible because the system shown in FIG. 20 can detect the location of the medical device. Other monitoring device configuration settings can be recommended to the clinician or set automatically based on the physical location of the monitoring device. In some embodiments, the configuration settings and techniques disclosed in US Patent Application Publication No. 2009/0275844, the entire contents of which are incorporated herein by reference, are described herein in a location-based rule. It is possible to control using.
021921 to 23 show neighborhood displays 2100, 2200, and 2300 having a multi-faceted animation function that is displayed so as to rotate from the first screen to a preferable screen as a response to the user being in the vicinity. Advantageously, this function feeds back to the user that the monitor has received the above-mentioned identification signal from the user and recognized the existence of the user. For example, the multifaceted presentation may be any of a triangular solid, a cubic solid, or a planar solid having multiple facets and two or more of those facets having different screen preferences. As will be appreciated by those skilled in the art, various other rotating geometries, including non-faceted shapes such as spheres and cylinders, can provide similar user feedback. In the following, these multifaceted presentations will be described in detail.
022021A-F show an embodiment of the neighborhood display 2100, which utilizes a rotating triangular solid 2105 to accommodate various display environment settings for multiple monitor users entering and exiting the vicinity of the monitor. Represents the switching of multiple screens. Specifically, the triangular solid 2105 has a first surface 2101, a second surface 2102, and a third surface 2103, each of which responds to the user being in the vicinity of the display. It is configured to display patient monitoring information in various user environment settings. In addition, the triangular solid 2105 appears to rotate as it switches between surfaces 2101, 2102, and 2103 to give feedback to nearby users.
0221As shown in FIG. 21A, the first surface 2101 associated with the first user is displayed on the display 2110. As shown in FIG. 21B, when the second user enters the vicinity of the display, the observer identifies the second user and assigns the triangular solid 2105 to the first surface 2101 as described later with respect to FIG. Virtually rotate from to the second surface 2102. Then, as shown in FIG. 21C, the display 2110 displays a second surface 2102 that corresponds to the display environment settings of the second user. As shown in Figure 21D, when a third user enters the vicinity of the observer, the observer identifies the third user and virtualizes the triangular solid 2105 from the second surface 2102 to the third surface 2103. Rotate to. Then, as shown in FIG. 21E, the display 2110 displays a third surface 2103 corresponding to the display environment setting of the third user. As shown in FIG. 21F, when the first user is identified again, the display 2110 virtually rotates the triangular solid back into the first surface 2101. In this way, the faces 2101, 2102, 2102 of the triangular solid 2105 are selectively displayed on the display 2110 according to various user preferences and based on whether the user is in the vicinity of the monitor. As described with respect to FIG. 13, when a plurality of users are present in the vicinity of the monitor at the same time, the priority method or the understanding method is used to determine which screen is to be displayed.
0222Figures 22A-E show an embodiment of the neighborhood display 2200, which utilizes a rotating cube 2205 to accommodate various display environment settings for multiple monitor users entering and exiting the vicinity of the monitor. Represents switching between multiple screens. Specifically, cube 2205 has a first surface 2201, a second surface 2202, and a third surface 2203, each of which serves as a response to the user being in the vicinity of the display. , It is configured to display patient monitoring information in various user environment settings. In addition, the cube 2205 appears to rotate as it switches between surfaces 2201, 2202, 2203 to give feedback to nearby users. This is done in the same manner as previously detailed for FIGS. 21A-F.
0223Figures 23A-C show an embodiment of the neighborhood display 2300, which utilizes a rotating planar solid 2305 to accommodate various display environment settings for multiple monitor users entering and exiting the vicinity of the monitor. Represents the switching of multiple screens. Specifically, the planar solid 2305 has a first surface 2301 and a second surface 2302, each of which has a variety of user environments in response to the user being in the vicinity of the display. It is configured to display patient monitoring information in the settings. In addition, the planar solid 2305 appears to rotate as it switches between surfaces 2301 and 2302 to give feedback to nearby users. This is done in the same manner as previously detailed for FIGS. 21A-F and 22A-E.
0224Although this specification describes some features of the bedside monitor, the neighborhood display can be located at any location, be it bedside or at a central monitoring location (such as a nurse station), for medical use. It can be applied to any monitoring device, be it for non-medical use. In addition, neighborhood display is applicable for physiological data acquisition or other monitoring applications (eg, scrutinizing historical data, setting and checking alarm limits, installing software updates by healthcare personnel or equipment maintenance personnel, etc.). is there. Conversion of medical communication protocols to facilitate communication between devices and systems
0225Medical costs continue to rise, and there is a growing demand for affordable, high-quality patient care. Medical costs can be reduced by increasing the effectiveness of hospital information systems. One of the factors that can affect the effectiveness of medical institutions is how much various clinical computer systems used in medical institutions can interact with each other and exchange information.
0226Hospitals, patient care facilities, and healthcare providers typically have a wide variety of clinical computer systems for the management of electronic medical information. Within the IT or management infrastructure as a whole, each clinical computer system can help meet a particular category or aspect of the patient treatment process. For example, hospitals may have patient monitoring systems, medical documentation and / or imaging systems, patient management systems, electronic medical recording systems, electronic business management systems, operating finance systems (such as dispensing and billing). ), And / or communication systems, etc.
0227In order to improve the quality of treatment in hospitals or other patient care facilities, it will be necessary for each of the different clinical computer systems to be able to effectively communicate with each other throughout the IT infrastructure. It would then be possible to exchange patient data collected by one clinical computer system with another clinical computer system that could benefit from such patient data. For example, this would allow decisions about patient treatment to be taken and actions to be taken based on a complete analysis of all available information.
0228In current operation, individual clinical computer systems can be sourced from different vendors, often as such. As a result, individual clinical computer systems can be implemented using their own network or communication infrastructure, their own communication protocols, etc., so the various clinical computer systems used in hospitals are not always effective. Not able to communicate with each other.
0229Medical device and medical system vendors are effective with other vendors' medical devices and systems to increase their market share and sell additional products, systems, and / or upgrades to healthcare suppliers. We may develop our own system that cannot communicate. Therefore, healthcare providers are forced to make business-wide or system-wide purchasing decisions rather than choosing the best available technology for each type of individual clinical computer system they operate.
0230One example of this happening is in the area of lifesaving technology available for patient monitoring. For example, many different bedside devices that monitor different physiological parameters are available from different vendors and suppliers. One such supplier proposes a best-in-class device for monitoring one particular physiological parameter, while another such supplier proposes a best-in-class device for another physiological parameter. In some cases. Therefore, hospitals may want to be free to use monitoring devices from multiple manufacturers in some circumstances, but if devices from different manufacturers cannot interface or exchange patient information. You wouldn't have that kind of freedom. Therefore, it may not be possible to provide reasonable and high quality patient treatment. In addition, each hospital or patient care facility may also implement its own communication protocol in its clinical computer network environment, which may further impede information exchange.
0231The Health Level Seven (HL7) protocol was developed to provide a messaging framework for clinical message transmission between medical computer systems and devices. The HL7 communication protocol specifies several standards, guidelines, and methodologies that can be used by various HL7 compliant clinical computer systems to communicate with each other.
0232The HL7 communication protocol has been adopted by many medical device manufacturers. However, the HL7 standard is extremely flexible and only provides a framework for guidance (eg, high-level logical structure of messages). Therefore, each medical device or medical system manufacturer or vendor can implement the HL7 protocol slightly differently while maintaining HL7 compliance. For example, the format of HL7 messages may vary from implementation to implementation. This will be described in detail herein. In some cases, one implementation's HL7 message may contain information content that is not included in messages that follow another HL7 implementation. Therefore, even if all medical devices or clinical computer systems are HL7 compliant, they may still not be able to communicate with each other.
0233Therefore, what is needed is the ability to improve the transmission of medical messages between medical devices or systems using separate, permissible implementations of established communication protocols (eg, HL7). , It is a module that can integrate multiple clinical computer systems to improve the quality of patient care.
0234FIG. 24A shows how the first medical device 2405 and the second medical device 2410 communicate with each other via the conversion module 2415. The first medical device 2405 is configured to send and receive messages according to the first acceptable format or implementation of a recognized electronic medical communication protocol, and the second medical device 2410 is the electronic. It is configured to send and receive messages according to the second acceptable format or implementation of the medical communication protocol. In some embodiments, the first and second protocol formats are separate implementations of the HL7 communication protocol. Electronic medical communication protocols other than HL7 can also be used.
0235The conversion module 2415 receives an input message having the first protocol format from the first medical device 2405, generates an output message having the second protocol format, and sends it to the second medical device 2410. The conversion module 2415 also receives an input message having a second protocol format from the second medical device 2410, generates an output message having the first protocol format, and sends it to the first medical device 2405. Therefore, the conversion module 2415 allows the first and second medical devices 2405, 2410 to communicate effectively and seamlessly with each other, in which case the communication device or protocol implemented by each device. It is not always necessary to fix it.
0236In certain embodiments, the conversion module 2415 contains a database that stores the protocol format expected by the intended receiver of the input message, eg, based on the information in the input message, or the protocol format used by various devices. Refer to and identify and generate output messages based on the protocol format used by the intended receiving device or system. The output message can be generated based on a comparison with the conversion rule set 2420 accessible from the conversion module 2415 (and based on the application of the conversion rule set 2420).
0237Translation rule 2420 can include rules that control how to deal with inconsistent formatting implementations, which can be within a common protocol. Examples of non-uniform formatting implementations of electronic medical communication protocols are the delimiters or separators used to separate data fields, whether specific fields are required or optional, and the repeatability of each part of the message. (For example, segment, field, component, subcomponent), sequence of each part of the message (for example, order of fields or components), whether a particular part of the message is included, length of each part of the message or message , Data types used for various parts of the message, etc.
0238In certain embodiments, conversion rule 2420 must be executed to "convert" an input message that conforms to the first HL7 implementation into an output message that conforms to the second HL7 implementation. Defines deletes, exchanges, and / or modifications. The output message can, for example, have a different formatting than the input message while preserving all (or part) of the substance or content of the input message.
0239The conversion module 2415 performs conversion between different implementations of a common electronic medical communication protocol (for example, different formatting of HL7 messages), as well as between input and output messages that comply with different communication protocols. It can also be configured to perform the conversion of. In some embodiments, the conversion module 2415 can, for example, respond to a message in one medical communication protocol and convert it into a message in another medical communication protocol. For example, the conversion module 2415 can facilitate communication between messages transmitted according to the HL7 protocol, ISO 11073 protocol, other open protocols, and / or proprietary protocols. Therefore, it is possible to translate an input message sent according to the HL7 protocol into an output message according to another protocol, and vice versa.
0240The operation of the conversion module 2415 and the conversion rule 2420 will be described in detail below. Here, various embodiments of the system architecture including the conversion module 2415 will be described.
0241In a particular embodiment, the first medical device 2405, the second medical device 2410, and the conversion module 2415 are communicably coupled via a connection to a common communication network. In some embodiments, the conversion module 2415 (with or without a communication network) so that all messages between the first medical device 2405 and the second medical device 2410 are transmitted through the conversion module 2415. Regardless, it is possible to communicatively couple between the first medical device 2405 and the second medical device 2410. Other architectures are possible.
0242The first and second medical devices 2405, 2410 and conversion module 2415 can be included, for example, as part of the physiological monitoring system 200 of FIG. 2 or the clinical network environment 600 of FIG. 6 described above. In certain embodiments, a portion of the physiological monitoring system 200 includes a portion of the physiological monitoring system 200's messaging subsystem that supports the exchange of data between various clinical computer systems used in hospitals.
0243In certain embodiments, the conversion module 2415 is capable of facilitating communication across multiple networks within a hospital environment. In other embodiments, the conversion module 2415 is capable of facilitating message communication across one or more networks extending outside the hospital (or clinical) network environment. For example, the conversion module 2415 can provide a communication interface with financial institutions, insurance companies, government agencies, out-of-hospital pharmacies, other hospitals, long-term care facilities, or patient care facilities, doctor's offices, and the like.
0244In some embodiments, the conversion module 2415 of FIG. 24 may be, for example, a component of the patient monitoring system 200 described herein. For example, the conversion module 2415 can be communicatively coupled to the hospital network 220 shown in FIG. In such an embodiment, the conversion module 2415 provides patient monitoring information such as, for example, physiological parameter measurements, physiological parameter trend information, physiological parameter alarm status, bedside medical monitoring device, nurse station monitoring system, etc. It is possible to facilitate exchange between hospital or clinical information systems (which can store electronic medical records) and / or many other medical devices and systems. The conversion module 2415 can enable seamless communication between different medical devices and systems, each of which is in a clinical (or hospital) network environment, such as the HL7 communication protocol. Different implementations of electronic medical communication protocols may be used.
0245In certain embodiments, the conversion module 2415 is between a first medical device that is part of the patient monitoring subsystem and a second medical device that is not (or is external to) part of the patient monitoring system 200. It is also possible to promote communication. Therefore, the conversion module 2415 responds to externally generated medical messages (eg, patient information update messages from HIS or CIS, status query messages, etc.), as well as external reporting messages (eg, patient observers or nurses). It may be possible to generate event report messages, alarm notification messages, etc. from the station monitoring system.
0246In another embodiment, the first and second medical devices 2405, 2410 communicate with each other via the communication bus 2421. The communication bus 2421 may include any one or more of the communication networks, systems, and methods described above, including the Internet, hospital WLANs, LANs, personal area networks, and the like. For example, one of the networks described above with respect to FIGS. 1, 2, 6, 7, 19, etc. is used to facilitate communication between multiple medical devices including the first and second medical devices 2405, 2410 described above. It is possible. One such embodiment is shown in FIG. 24B.
0247In FIG. 24B, the first medical device 2405 supplies a message to the communication bus 2421. This message is intended to be received by the second medical device 2410, but because the first and second medical devices 2405 and 2410 are communicating according to different communication protocol formats, the second medical device Device 2410 is unable to process the message.
0248Conversion module 2415 monitors communication bus 2421 for such messages. The conversion module receives the message and knows that the first medical device 2405 is trying to communicate with the second medical device 2410. The conversion module 2415 determines that the message conversion facilitates communication between the first medical device 2405 and the second medical device 2410. Therefore, the conversion module 2415 uses the appropriate conversion rule stored in the conversion module 2420. The conversion module 2420 can include memory, i.e. EPROM, RAM, ROM, etc.
0249The conversion module 2415 converts the message from the first medical device 2405 according to any of the methods described herein. After conversion, the conversion module 2415 delivers the converted message to the communication bus 2421. The second medical device 2410 receives the translated message and makes an appropriate response. For example, the second medical device 2410 will perform some function and / or will attempt to communicate with the first medical device 2405. The conversion module 2415 also facilitates communication from the second medical device 2410 to the first medical device 2405.
0250The first medical device 2405 and the second medical device 2410 may be, for example, any medical device or system communicatively coupled to the hospital network 222 shown in FIG. These medical devices or systems include, for example, point-of-care devices (such as bedside patient monitors), data storage or patient record databases, hospital (or clinical) information systems, central monitoring devices (such as nurse station monitoring systems). , And / or clinical devices (pagers, mobile phones, smartphones, personal digital assistants (PDAs), laptops, tablet PCs, personal computers, pods, etc.) and the like.
0251In some embodiments, the first medical device 2405 is a patient monitor communicatively coupled to the patient to track physiological parameters (eg, oxygen saturation, pulse rate, blood pressure, etc.). The medical device 2410 of 2 is a hospital information system (HIS) or a clinical information system (CIS). In some embodiments, the patient monitor maintains physiological parameter measurements, physiological parameter alarms, or other physiological parameter measurement information generated during patient monitoring by the HIS or CIS, patient. Communicate to HIS or CIS for inclusion in electronic medical records.
0252In some embodiments, the first medical device 2405 is HIS or CIS and the second medical device 2410 is the nurse station monitoring system described herein. However, the conversion module 2415 can facilitate communication between a wide variety of medical devices and systems used in hospitals or other patient care facilities. For example, the conversion module 2415 can facilitate communication between patient physiological parameter monitoring devices, communication between the monitoring device and the nurse station monitoring system, and the like.
0253Patient monitoring subsystems, such as the patient monitoring subsystem described herein (eg, Physiological Monitoring System 200), use conversion module 2415 to allow HIS to implement another implementation of the HL7 protocol, or some other electronic device. It is possible to push data to and pull data from the HIS even when using the medical communication protocol.
0254In certain embodiments, the patient monitoring subsystem can be configured to push / pull data at predetermined intervals . For example, a patient monitor or clinician station monitoring system automatically downloads patient data from HIS at periodic intervals so that patient data is already available when the patient is connected to the patient monitor. It is possible to do. Patient data transmitted by HIS can include admission / discharge / transfer ([ADT]) information received at the time of patient enrollment. ADT messages can be invoked by the hospital information system, for example, a patient has been hospitalized, discharged, transferred, or enrolled, or patient information has been updated or merged, or transferred or transferred. This is done to notify the auxiliary system that the discharge has been cancelled.
0255In other embodiments, the patient monitoring subsystem can be configured to push or pull data from the HIS only when requested by the HIS. For example, a clinician can request information stored in a patient's electronic medical record on HIS.
0256In yet another embodiment, the patient monitoring subsystem can be configured to push or pull data from HIS in response to unsolicited events. For example, the physiologic parameters of the patient being monitored can enter an alarm state, which can be automatically sent to HIS for storage in the patient's electronic medical record. .. In yet another embodiment, any combination of the above methods or alternative methods can be used to determine when to exchange messages with HIS.
0257A system architecture example and a trigger example for message transmission using the conversion module 2415 have been described. Next, the operation of the conversion module will be described. Figures 25A-25D show examples of medical messages at various phases or steps of the conversion process. Details of this conversion process will be described later with reference to FIGS. 26, 27A, and 27B.
0258Figure 25A shows example ADT input message 2505 received by conversion module 2415 from HIS. ADT input message 2505 is implemented according to the HL7 communication protocol and contains information related to patient admission. ADT input message 2505 contains multiple segments, which include message header segment 2506, event segment, patient identification segment, patient consultation segment, role segment, diagnostic segment, and multiple custom segments. ..
0259In some embodiments, the message header (MSH) segment 2506 defines how the message is sent, field delimiters and encode characters, message type, sender and receiver, and more. The first symbol or character after the MSH string can define a field delimiter or separator (the "caret" symbol in this message). The following four symbols or characters can define encoded characters. The first symbol defines the component delimiter ("~"). The second symbol defines a repeat delimiter ("|"). The third symbol defines the escape delimiter ("\"). The fourth symbol defines the subcomponent delimiter ("&"). All of these delimiters may not be uniform across multiple HL7 implementations.
0260In some embodiments, header segment example 2506 also includes a sending application (VAFC PIMS), a receiving application (NPTF-508), a date / time of the message (20091120104609-0600), and a message type (20091120104609-0600). Includes ADT-A01 "), Message Control ID ("58103 "), Processing ID ("P "), and Country Code ("USA "). The header segment also contains multiple blank fields, as represented by consecutive caret symbols.
0261Figure 25B shows the message header segment 2506 parsed as a field or element based on the identified field delimiter (caret symbol). In certain embodiments, the parsed input message includes an XML message that is configured to be translated according to Extendable Style Sheet Language Transformation (XSLT) rules.
0262In certain embodiments, the parsed input message can be encoded. Figure 25C shows the parsed message header segment of the input message after it has been encoded (eg, using the Unicode conversion format 8 (UTF-8) encoding scheme).
0263The encoded message header segment indicates some of the various data types available in the message. For example, the sending application for the third parsed field (VAFC PIMS) and the receiving application for the fifth parsed field (NPTF-508) have a hierarchical digitator (HD) name data type. Expressed using. The date / time field (7th parsed field) is represented using the timestamp ("TS") data type. The processing ID field (11th parsed field) is represented using the processing type ("PT") data type. Fields that do not contain a data type identifier are represented using a string ("ST") data type. Other possible data types include, for example, coded elements, structured numbers, timing quantities, textual data, dates, entry identifiers, coded values, numbers, sequence identification, and the like. The data types used for the various fields and attributes of these segments may not be uniform across multiple formatting implementations.
0264FIG. 25D shows an example output message 2510 from the conversion module 2415, based on the example input message 2505 of FIG. 25A. Output message 2510 includes message receipt confirmation segment 2512.
0265Regarding the operation of the conversion module, the conversion module 2415 can create, generate, or generate an output message that reflects the input message, for example, based on the application of the conversion rule set 2420. In some embodiments, the transformation module 2415 translates, transforms, transforms, reformates, configures, modifies, rearranges input messages, for example, based on comparison with transformation rule set 2420 (and application of transformation rule set 2420). , Modification, adaptation, modification, or adjustment can be made to form an output message. In some embodiments, the conversion module 2415 has, for example, an output message with a new formatting implementation based on a comparison (and application of the conversion rule set 2420) of the input message with the conversion rule set 2420 while retaining the content of the input message. Can be replaced or replaced with.
0266FIG. 26 shows a conversion process 2600 that produces an output message based on a comparison of the input message with the conversion rule set 2420 associated with the conversion module 2415. In the conversion process 2600, first, at block 2602, the conversion module 2415 receives an input message from the first medical device.
0267In block 2604, the conversion module 2415 determines the formatting implementation of the input message and the formatting implementation used for the output message. In certain embodiments, the input message can include one or more identifiers that represent a formatting implementation. In some embodiments, the determination of the formatting implementation can be made, for example, by parsing the message itself, which parsing the delimiter or encode character used, the order of the fields, the segment, the field, or the repetition of the component. This is done by identifying the nature, the data type of the field, or other implementation variant. In certain embodiments, the conversion module 2415 is capable of separating or parsing the formatting from the content of the message (as shown in FIG. 25B) to assist in determining the formatting implementation. In some embodiments, the conversion module 2415 references a database containing the implementations used by each device configured to interface with the conversion module 2415 in order to determine the formatting implementation of the input message.
0268In a particular embodiment, the determination of the formatting implementation required for the output message can also be determined from the input message. For example, the input message can include fields that identify the intended receiving application, equipment, system, equipment, and / or destination. Alternatively, the input message can include a field that identifies the type of message sent (eg, an ADT message), and the conversion module 2415 can include the type of message sent and / or the sending application, device. , Or from the system, it is possible to determine the appropriate receiver. The conversion module 2415 can then determine the formatting implementation required for the intended receiver of the input message.
0269In decision block 2605, conversion module 2415 determines whether the ruleset is configured for conversion from the identified formatting implementation of the input message to the identified formatting implementation used for the output message. This ruleset may be manually configured prior to the installation of the conversion module software, or it may be automatically configured prior to receiving the input message. If the ruleset is already configured, conversion process 2600 proceeds to block 2606. If the ruleset is not configured, configure the ruleset in block 2607. The ruleset can be configured as described below for FIGS. 28 and 29A-29D. The conversion process 2600 then proceeds to block 2608.
0270In block 2606, the transformation module 2415 identifies a preconfigured rule from the transformation rule set 2420 that controls the transformation between the determined formatting implementation of the input message and the formatting implementation of the output message. In some embodiments, the identification of preconfigured rules can be done manually.
0271In block 2608, conversion module 2415 produces output messages based on one or more configured rulesets for conversion rule 2420. In certain embodiments, the output message retains all (or at least a portion) of the content of the input message, but the format is expected and supported by the intended receiver of the input message.
0272Transformation rule 2420 can include, for example, unidirectional and / or bidirectional rules. The unidirectional rule is applicable, for example, in the case of a message from a first medical device (eg 2405) to a second medical device (eg 2410), but from a second medical device to a first. This rule does not apply to messages to medical devices. For example, unidirectional rules can address the differences in the delimiters used between the fields of two different formatting implementations (for example, in the HL7 communication protocol). Conversion module 2415 can apply field delimiters rules to determine if field delimiters are supported by the intended receiver of the input message. If the field delimiter in the input message is not supported by the intended receiver, the field delimiter rule replaces the field delimiter in the input message with a field delimiter supported by the intended receiver. Is possible.
0273For example, an input message from an input medical device may contain a formatting implementation that uses the "caret" symbol ("^") as a field delimiter or separator. In contrast, formatting implementations recognized by the intended receiving medical device may use the "pipe" symbol ("|") as the field delimiter. The conversion module 2415 identifies the field delimiter used in the formatting implementation recognized by the intended receiving medical device from the conversion rule set 2420 and is an output message based on the input message that is used in the input message. It is possible to generate an output message that uses the "pipe" field delimiter instead of the "caret" field delimiter. In this case, the rule of replacing the caret symbol with a pipe symbol applies only to messages sent to the receiving device that recognizes the pipe symbol as a field delimiter. This rule can be accompanied by a supplemental rule that directs the replacement of the pipe symbol with a caret symbol in the case of a message addressed to a receiving device that is known to recognize the caret symbol as a field delimiter. ..
0274Another unidirectional rule can address the presence or absence of specific fields between different formatting implementations. For example, an input message from an input medical device may contain fields that are not recognized by the intended receiving medical device. Conversion module 2415 is capable of producing output messages that do not contain this unrecognized (or unsupported) field. Enter a field expected by the intended receiving medical device If the message does not contain a message, the conversion rule set 2420 inserts a null entry or a blank "" string in the field expected by the intended receiving medical device. It is possible to include rules and / or rules that alert the receiving device to missing expected fields. The conversion module 2415 can also notify the transmitting device that the receiving device does not support a particular part of the message.
0275Other unidirectional rules are, for example, one data type to another (for example, a string ("ST") to text data ("TX"), or a structured number ("SN") to number ("SN"). It can be easily converted (to "NM")) and the length of various parts of the message can be increased or decreased. Also, unidirectional rules can deal with non-uniform repetition of each part of the message. For example, transformation module 2415 applies field repetition rules to repeating instances of a segment, field, component, or subcomponent of a message to determine and support how many such repeating instances are supported by the receiving device. If so, it is possible to delete or add several iterative instances as needed. For example, the phone number field in the patient identification segment may be a repeatable field so that you can enter your home, work, and mobile phone numbers.
0276Two-way rules are also available. Bidirectional rules are uniformly applicable to messages between first and second medical devices (eg, 2405, 2410), regardless of which device is the sender and which device is the receiver. Bidirectional rules can, for example, deal with changes in the sequence. In certain implementations, the input message from the input medical device can contain one or more patient name fields, in which case the first name component is displayed before the last name component. In contrast, the intended receiving medical device may anticipate an implementation in which the last name component appears before the first name component. Therefore, the translation rule set 2420 can include bidirectional rules that swap the order of the first name component and the last name component when communicating between two medical devices or between two formatting implementations. In general, it is possible to apply field ordering rules to determine if the order of fields, components, or subcomponents is correct for the intended receiver and rearrange them as needed. It is also possible to include another bidirectional rule to address, for example, other order variability or other types of variability between formatting implementations.
0277Conversion rule 2420 may include compound rules. For example, a compound rule can contain if-then sequences of multiple rules, and one rule can depend on the results of another. Depending on the conversion rule 2420, it is also possible to use computation and logic (eg, Boolean logic or fuzzy logic), and more.
0278As mentioned above, messages transmitted over hospital-based communication networks can use the HL7 protocol. Figures 27A and 27B show conversion processes 2700A, 2700B that transmit HL7 messages between HIS and medical devices via hospital-based communication or clinical networks. The conversion processes 2700A and 2700B will be described on the assumption that the rules for controlling "conversion" between the first and second HL7 formats have already been configured.
0279In the conversion process 2700A shown in Figure 27A, the conversion module 2415 is from the HIS with the first HL7 format to the intended receiving medical device with the second HL7 format (eg, patient monitor or clinician). Facilitate the transmission of HL7 messages (eg, the ADT message in Figure 25A) to the station monitoring system).
0280In the conversion process 2700A, first, at block 2701, the conversion module 2415 receives an input message with the first HL7 format from HIS. In certain embodiments, the input message includes, for example, information about patient admission and / or patient identification, or patient medical history information in an electronic medical record database.
0281In block 2703, the conversion module 2415 determines the formatting implementation of the input message and the formatting implementation used for the output message. These decisions can be made in the same manner as the decisions described above for block 2604 in FIG.
0282In block 2705, the conversion module 2415 identifies a rule that controls the conversion between the determined HL7 format of the input message and the HL7 format of the output message, and based on the identified rule, an output with a second HL7 format. Generate a message. In certain embodiments, the output message retains the content of the input message sent by HIS, but its format is expected and supported by the intended receiver of the input message.
0283In block 2707, the conversion module 2415 can output the output message to the intended receiver via a hospital-based communication network. In a particular embodiment, the intended receiver can return an acknowledgment message to the hospital information system to acknowledge normal reception or report that an error has occurred.
0284In the conversion process 2700B shown in Figure 27B, the conversion module 2415 facilitates the transmission of HL7 messages from a medical device with a first HL7 format (eg, a patient monitor) to HIS with a second HL7 format. .. For example, a patient monitor can send reported event data m (eg, patient alarm data) to HIS for storage in the patient's electronic medical record.
0285In the conversion process 2700B, first, at block 2702, the conversion module 2415 receives an input message with the first HL7 format from the medical device. In certain embodiments, the input message includes patient monitoring or alarm data for one or more physiological parameters of the monitored patient for recording in an electronic medical record database associated with HIS.
0286In block 2704, the conversion module 2415 determines the formatting implementation of the input message and the formatting implementation used for the output message. These decisions can be made in the same manner as the decisions described above for block 2604 in FIG.
0287In block 2706, the conversion module 2415 identifies a rule that controls the conversion between the determined HL7 format of the input message and the HL7 format of the output message, and based on the identified rule, an output with a second HL7 format. Generate a message. In certain embodiments, the output message retains the content of the input message sent by the medical device, but its format is expected and supported by HIS.
0288In block 2708, the conversion module 2415 is capable of outputting output messages to the hospital information system via a hospital-based communication network. In certain embodiments, the HIS can acknowledge normal reception or report that an error has occurred by returning an acknowledgment message to the medical device.
0289In FIGS. 26, 27A, and 27B, the operation of the conversion module 2415 has been described. 28 and 29A to 29D describe the configuration of conversion rule 2420.
0290Conversion rule 2420 can be implemented as one or more style sheets, history-related data structures, tables, lists, other data structures, combinations thereof, and so on. In certain embodiments, the conversion rule 2420 can be stored in local memory within the conversion module 2415. In another embodiment, the conversion rule 2420 can be stored in an external memory or data storage device communicatively coupled with the conversion module 2415.
0291The transformation module 2415 can contain a single ruleset or multiple rulesets. For example, the conversion module 2415 is separate for each medical device / system and / or for each network-coupled (or network-bound) and potentially communicable medical device / system pair. It is possible to include a ruleset. In some embodiments, the conversion module 2415 may include a separate ruleset for each possible pair of formatting implementations allowed under a medical communication protocol (eg, HL7 protocol).
0292In certain embodiments, the conversion rule 2420 can be entered manually using, for example, the messaging implementation software tool 2800 shown in FIG. For example, software developers involved in a particular hospital network investigate the devices and / or protocol message formats used by the devices that are (or may be) connected to the hospital network and those devices. It is possible to manually enter rules that facilitate "conversion" between various protocol message formats supported or recognized by the system and / or the system.
0293Figure 28 shows an example screenshot from the messaging implementation software tool 2800 that manually configures the conversion rule 2420 used by the conversion module 2415. This screen shot from the messaging implementation software tool 2800 shows various parameters that can vary between formatting implementations of electronic medical communication protocols (eg, HL7). This screen shot also includes an area where the user can enter information that defines (or is used to define) conversion rules for conversions between different HL7 implementations. In some embodiments, the messaging implementation software tool 2800 stores, for example, various preconfigured rulesets based on known communication protocol implementations of various medical devices. In such an embodiment, the user can configure one or more conversion rules 2420 used for communication using such a device by inputting identification information such as the manufacturer, model number, etc. of the device. Is. Based on this identification information, the messaging implementation tool 2800 can identify a preconfigured conversion rule set to be used for communication with the device.
0294In other embodiments, conversion rule 2420 can be automatically generated. For example, the automatic generation of a new ruleset (or rulesets) can be triggered by the detection of a newly recognized "communication" medical device or system on the network. In certain embodiments, the automatic generation of a new rule set or multiple rulesets occurs when the first message is received (or to the medical device or system) from a new "communication" medical device or system coupled to the network. It is possible to do it at the time of sending the message of 1. In yet another embodiment, the automatic generation of rulesets involves updating or dynamically modifying existing rulesets.
0295The automatic generation of conversion rule sets can be performed in a variety of ways. For example, in some embodiments, the conversion module 2415 may automatically initiate the use of a preconfigured set of conversion rules 2420, for example, based on the manufacturer and model of the new device recognized on the network. Is. In a particular embodiment, the conversion module 2415 requests one or more messages from a new device or system, parses those messages, and implements the type of formatting, as shown in the automated rule configuration process 2900A in Figure 29A. It is possible to determine. In automatic rule configuration process 2900A, at block 2901, conversion module 2415 first receives one or more messages from medical devices or systems detected on the network. These messages can be received when sent to the intended receiving medical device or system, or in response to a query sent by the conversion module 2415 or another medical device or system coupled to the network. is there.
0296In block 2903, the conversion module 2415 determines the protocol for one or more received messages. This is done, for example, by parsing these messages or by querying a database that shows what communication protocols / formats are implemented by each medical device or system on the network. In certain embodiments, the conversion module 2415 is configured to process medical messages implemented using a single common protocol (eg, HL7). Therefore, if it determines that the received message is implemented using an unsupported (or unrecognized) protocol, the conversion module ignores the message received from the detected medical device or system. , It is possible to output an alert or warning, or allow the message to be sent untranslated.
0297In block 2905, the conversion module 2415 determines the formatting implementation of one or more received messages. In certain embodiments, the received message can include one or more identifiers that represent a formatting implementation. In other embodiments, the formatting implementation decision can be made by parsing the message itself, for example by checking the field order, the delimiters or encoded characters used, or the variability of other implementations. is there. In certain embodiments, the transformation module 2415 is capable of separating or parsing formatting from the content of the message to assist in determining the formatting implementation.
0298In block 2907, the conversion module 2415 constitutes one or more rules or rulesets that process messages received from detected medical devices or systems and / or messages sent to these medical devices or systems. In certain embodiments, configuring a rule involves creating or generating a new rule. In other embodiments, configuring a rule involves modifying or updating an existing rule. The configured rule or ruleset can be included in translation rule 2420. If a ruleset for the formatting implementation used in the new device or system already exists, it is not necessary to configure the new conversion rules. Instead, existing conversion rules can be associated with the new device or system and used for communications involving the device or system. In other embodiments, the conversion module 2415 is capable of creating new rulesets specific to new equipment or systems, or based on tiny differences in identified formatting. It can be modified.
0299In other embodiments, the conversion module 2415 is capable of generating one or more test messages that may be useful in identifying the communication protocol and implementation used in the device or system. For example, the conversion module generates a test message that causes a newly discovered device or system to take a specific action (for example, storing information) and provides information about the action taken by that newly discovered device. You can inquire to see if the test message was understood or how it was understood. This will be described in the automatic rule configuration process 2900B of FIG. 29B.
0300In automatic rule configuration process 2900B, at block 2902, conversion module 2415 first sends one or more test (or initialization) messages to remote devices or systems found on the network. The test message can be configured, for example, to instruct the remote device or system to take certain actions (eg, storing patient information). In certain embodiments, the test message can be configured to generate a response that represents the type of formatting recognized or supported by the remote device or system. In other embodiments, the test message can be configured so that only a device or system that supports a particular formatting implementation understands the test message and follows the test message correctly.
0301In block 2904, the conversion module 2415 queries the remote device or system to receive information about the actions taken based on the test message sent to the remote device or system and determine if the test message was understood. To do. For example, if a test message tells a remote device or system to store patient information in a particular location, the conversion module 2415 asks for information from that location to see if the test message was understood. Can be determined. If the test message is not understood, the conversion module 2415 can continue to send test messages for known formatting implementations, for example, until it is determined that the test message is understood.
0302In block 2906, the conversion module 2415 determines the protocol and formatting implementation based on the information received. As an example, in certain embodiments, the test message can include an instruction to store patient name information. The test message can include a patient name field with a last name component after the first name component. The conversion module 2415 can then query the remote device or system to return the patient's last name. This query can help determine information about the order of fields in the formatting implementation used by the remote device or system, depending on whether the patient's last name is returned or the first name is returned. is there. As another example, a test message can instruct a detected device or system to store a repeating instance of a component. The conversion module 2415 can then query the device or system to repeatedly return instances to find out which instance, if any, was stored. According to this repeatability information, whether the formatting implementation used in the remote device or system allows repetition of a particular field, and if so, how many repeating instances are allowed. It is also possible to know.
0303In block 2908, conversion module 2415 constitutes one or more rules that process messages received from detected medical devices or systems and / or messages sent to these medical devices or systems. For example, this rule can translate a message from the message format used in the first medical device to the message format used in the second medical device, as described herein. Is. In certain embodiments, configuring a rule involves creating or generating a new rule. In other embodiments, configuring a rule involves modifying or updating an existing rule. If a ruleset for the formatting implementation used in the new device or system already exists, it is not necessary to configure the new conversion rules. Instead, existing conversion rules can be associated with the new device or system and used for communications involving the device or system.
0304Figures 29C and 29D show the automatic rule configuration process performed by the conversion module 2415 for messages that utilize the HL7 protocol. The HL7 protocol can be used, for example, to convey electronic messages to support administrative, logistics, financial, and clinical processes. For example, HL7 messages can include patient management messages (eg, ADT messages) that are used to exchange patient demographic and medical information between various medical systems.
0305The automatic rule configuration process 2900C shown in Figure 29C is similar to the process 2900A shown in Figure 29A. At block 2911, the conversion module 2415 receives one or more messages from the HL7 medical device. In block 2915, the conversion module 2415 determines the formatting implementation of its HL7 medical device from one or more messages received. As mentioned above, formatting implementation decisions can be made, for example, by checking the order or sequence of fields, field delimiters, repeatability, cardinal numbers, and variability in other HL7 implementations.
0306In block 2917, the conversion module 2415 constitutes one or more rules for processing messages received from the HL7 medical device and / or messages sent to the HL7 medical device. In certain embodiments, configuring a rule involves creating or generating a new rule for the detected formatting implementation. In other embodiments, configuring a rule involves dynamically modifying or updating an existing rule. If a ruleset for the formatting implementation used in the new HL7 medical device already exists, it is not necessary to configure the new conversion rules. Instead, existing conversion rules can be associated with the new HL7 medical device and used for communications involving the device.
0307The automatic rule configuration process 2900D shown in FIG. 29D is similar to the process 2900B shown in FIG. 29B. In block 2912, the conversion module 2415 sends one or more test (or dummy, or initialization) messages to the HL7 medical device. In other embodiments, the conversion module 2415 is capable of transmitting one or more test messages from another HL7 medical device to the new HL7 medical device. As mentioned above, the test message can include a known HL7 format and include a message configured to check if the HL device understands the test message. The test message can include, for example, a test ADT message.
0308In block 2914, the conversion module 2415 queries the HL medical device to receive information about the action taken or stored information in response to the test message. In block 2916, the conversion module 2415 determines the formatting implementation of its HL7 device based on the information received. In certain embodiments, the conversion module 2415 can analyze the received information to determine if one or more test messages have been correctly understood. In the absence of a properly understood test message, the conversion module 2415 can send additional test messages with other known HL7 formats and repeat blocks 2914 and 2916.
0309In block 2918, the conversion module 2415 constitutes one or more conversion rules that process messages received from the detected HL7 medical device and / or messages sent to the detected HL7 medical device. In certain embodiments, configuring a conversion rule involves creating or generating a new conversion rule. In other embodiments, configuring a rule involves modifying or updating an existing rule. If a conversion rule set for the formatting implementation used in the new HL7 medical device already exists, it is not necessary to configure the new conversion rule. Instead, existing conversion rules can be associated with the new HL7 medical device and used for communications involving the HL7 medical device.
0310The automatic rule configuration process described above can be triggered by the detection of a network device or system by the conversion module 2415. The medical device referenced in FIGS. 29A-29D may include any of the devices or systems shown in FIG. 2 and described above.
0311In some embodiments, the automatic generation of conversion rules can be advantageous after installation and compilation of the messaging subsystem software that includes the conversion module 2415. In certain embodiments, the automatic generation or dynamic modification of conversion rule 2420 can be done without the need to recompile or rebuild the conversion module software. This feature can be advantageous in efficiently complying with US Food and Drug Administration (FDA) requirements for validation of software used in the medical environment.
0312For example, a medical device manufacturer may use the conversion module 2415 to install a specific medical device or system (eg, the patient monitoring system described herein) in a hospital or other patient care facility. Consider a situation where you plan to facilitate communication with other devices or systems already installed (eg, HIS or CIS). Any software required to operate the new medical device to be installed, regarding FDA compliance before being installed in the hospital (for example, even if the HL7 implementation of other existing devices or systems in the hospital remains unknown) It is possible to perform validation at least in part. For example, if a pre-installation validation receives a scheduled message format for any aspect of software for a new medical device that relies on receiving messages from other devices in the hospital. It is possible to confirm that it can operate completely and normally. Then, when the new medical device is installed in the hospital, the conversion module 2415 validates the software by showing that it is possible to send a message in the planned format to the newly installed device. Is possible to complete. In this way, the FDA validation work can be done to a large extent in the pre-installation time frame. Before installation, the work can be done in a more controlled and easier way than it is in the field.
0313In addition, for example, if you plan to install medical equipment or systems in separate hospitals, and the existing equipment in each hospital uses, for example, different implementations of the HL7 protocol, the conversion module. The 2415 can further help streamline FDA validation. Normally, in these situations, each hospital would have to fully validate the full functionality of the software for the new medical device. In contrast, if the conversion module 2415 interfaces between a new medical device and an existing device in a hospital, as explained earlier, a significant portion of the software's functionality is a single pre-installation inspection. It is possible to confirm the validity with. Then, by confirming that the correct message format is received from the conversion module at the time of installation in each hospital, it is possible to complete the software validation of the medical device (the conversion rule of the conversion module is: On-site customization is possible). As a result, it is possible to significantly improve the efficiency of field validation procedures, which favors more efficient FDA-compliant work and allows field-customizable conversion rules. Its use makes it possible to introduce life-saving medical technology to patients more quickly. Patient monitoring report
0314This specification describes devices and methods for monitoring blood oxygen saturation, pulse rate, blood pressure, and many other physiological parameters. Such medical surveillance devices are often programmed with alarm limits. The alarm limit is for automatically detecting when the value of a particular physiological parameter deviates, for example, from a range of values considered safe or healthy. Depending on the embodiment, it is possible to perform various actions when such an alarm state is detected. For example, a bedside medical monitor can issue an audible or visible alarm. In addition, in some cases, after the alarm condition has persisted for a set length of time (eg, 5 seconds), the alarm condition is displayed on the central patient monitoring device, eg, as described herein. It is possible. In addition, if the alarm condition persists for a set length of time (eg, 10 seconds), the clinician assigned to treat the patient with the alarm condition, for example, a pager or other It is possible to notify with a notification device.
0315The number of alarm states detected depends, of course, on the setting of alarm conditions that indicate the alarm states. In some embodiments, such alarm conditions can include a threshold, which indicates the value of a physiological parameter that is considered safe or normal and the medical condition that the clinician should address. It is possible to indicate the boundary with the value of the physiological parameter considered to be. It is expected that the closer the setting of such an alarm threshold is to the general value of the physiological parameter in healthy people under normal circumstances, the greater the number of alarm events detected. In general, the closer the value that satisfies the alarm condition is to the normal range of given physiological parameters, the more the patient will have some type of medical intervention (eg, medication, CPR, mechanical ventilation, etc.). It is more likely to detect deviations from the normal range of values, which indicates that it is needed. This is desirable because it reduces the likelihood that the patient will not be triggered by the alarm (which would be a false negative) in the event of medical distress.
0316However, reducing false negatives is costly. That is, physiologic parameter alarm conditions that succeed in reducing false negatives may also increase the rate of false positives. False positives refer to a condition in which an alarm condition is detected even if the patient does not have any clinically significant medical distress. False positives that occur too often can be an intolerable burden for clinicians. This is because the clinician must scrutinize the alarm state, reset the monitoring device from the alarm state, and so on. In addition, frequent false positives can put patients at risk by diminishing the importance of alarm events to clinicians, whether conscious or unconscious. Therefore, alarm conditions for medical surveillance applications should be determined to achieve a good balance of false negatives at a reasonable rate without excessively increasing false positive alarm events. In some cases, false positives may still be preferable to false negatives. This is especially true in situations where false negative results can be serious for the patient. As such, it is possible to reflect in the selection of alarm limit conditions that it is preferable to keep the occurrence of false negatives at a relatively low rate. However, false positives are not always preferable to false negatives. Moreover, alarm conditions that are satisfactory for one type of patient may be inadequate for another type of patient. The proper balance between false positives and false negatives can vary from medical surveillance application to medical surveillance application.
0317For example, when monitoring blood oxygen saturation, the typical SpO of a healthy person<sub>2</sub>Values will fall in the range of 95-100%. Therefore, the patient monitoring device, SpO<sub>2</sub>If the alarm threshold is configured as 94%, the number of false positive alarm events can be relatively large. On the other hand, SpO<sub>2</sub>Setting the alarm threshold to 92% is likely to reduce the number of false positives, but the number of false negatives can increase above a satisfactory level in some medical surveillance applications. Therefore, devices and methods that provide data to assist in the selection of alarm thresholds that reduce false positives while keeping false negatives below satisfactory levels would be very useful. By using such devices and methods, it is possible to establish alarm conditions for a wide variety of physiological parameters.
0318FIG. 30 is a graph example 3000 of the distribution of alarm events relative to alarm limits for a given physiological parameter. Graph 3000 is a plot of the number of alarm states detected for various alarm limits. Graph 3000 shows, for example, physiological parameters from a statistically significant number of specific types of patients (eg, patients with heart disease) over a statistically significant length of time, using a wide variety of alarm limits. It reflects the hypothetical situation of collecting alarm data. Of course, the distribution of alarm events as a function of alarm limits generally varies from physiological parameter to physiological parameter.
0319Graph 3000 shows a series of alarm limits that increase linearly on the x-axis. On the y-axis, the number of detected alarm states corresponding to each alarm limit is plotted. As illustrated, for this particular physiological parameter, the number of alarm states detected generally decreases as the alarm limit increases. Each bar in Graph 3000 represents, for example, a combination of false positive alarm events and correctly detected alarm events (eg, detection of alarm events when the patient really seeks medical assistance).
0320The vertical dashed line 3002 represents one possible alarm limit threshold. For example, if the physiological parameter value exceeds the threshold value indicated by the vertical dashed line 3002, the alarm state is detected, and if the physiological parameter value falls below this threshold value, the alarm state is not detected. The vertical dashed line 3004 represents another possible alarm limit.
0321As shown in Graph 3000, there are only two values on the x-axis between the illustrated alarm limits 3002 and 3004. However, the number of alarms detected using each of the two alarm thresholds 3002 and 3004 shown in the figure is almost halved from the first alarm threshold 3002 to the second alarm threshold 3004. Therefore, in this case, the number of alarm thresholds is non-linearly related to changes in the alarm limit. This can have a completely different effect on the number of alarms and false positives detected by hospitals or other patient care facilities with relatively small changes in the alarm conditions used to monitor physiological parameters. Indicates that it may be given. In some cases, for example, reducing the number of false positives without necessarily increasing the risk of clinically significant false negatives could significantly reduce the number of alarms detected. However, even if relatively small adjustments to alarm conditions (eg, alarm thresholds) could not significantly change the number of false positives, the methods described herein can, in some circumstances, reduce the number of false positives. It can be useful for safe and gradual reduction. Of course, changes in alarm conditions used to monitor patients should not be taken lightly. In general, any changes to the alarm conditions require approval by the hospital administrator or other responsible person.
0322In some embodiments, a device and / or system for collecting medical surveillance information from a patient in the patient treatment domain is provided. For example, this medical surveillance information can be collected from a clinically significant number of patients over a clinically significant length of time. In some embodiments, the patient treatment domain is a group of similar types of patients, i.e., a group of patients who can be expected to have similar reasons for monitoring alarm conditions due to similar medical characteristics, conditions, defects, etc. Is. For example, a patient treatment domain may consist of a group of heart disease patients on a hospital floor or the like.
0323In some embodiments, several bedside patient monitors are used to collect physiological signals from the patient. Raw physiological signals can be processed by a bedside patient monitor. For example, a bedside patient monitor can perform low signal averaging, filtering, and more. Bedside patient monitors can also perform operations that calculate the values of physiological parameters. And the bedside patient monitor has physiological parameter values (eg SpO<sub>2</sub>, Pulse rate, blood pressure, etc.) and its temporal trend can be output. Physiological information about each patient (eg, raw physiological signals, processed physiological signals, and / or calculated values of physiological parameters) can then be sent and stored, for example, in a central repository. is there. In some embodiments, this information is stored in a networked database (eg, the round-robin database 722 described herein). In some embodiments, a central repository can store patient medical surveillance information in a particular domain (eg, ward) for a length of time (eg, a week, or a month). ..
0324At the beginning of monitoring, one or more algorithms were applied to the calculated values of raw physiological signals, processed physiological signals, and / or physiological parameters to detect whether the first set of alarm conditions was met. It is possible to apply. This can be done, for example, by each bedside patient monitor for each patient in the patient treatment domain. The first alarm condition set is, for example, a condition implemented in a patient monitoring device that executes a real-time monitoring function and detects an alarm state. When this alarm condition is met, it is possible to generate an alarm as described herein. It is also possible to record the occurrence of alarm conditions for each patient using a central repository.
0325In some embodiments, when a statistically significant amount of patient monitoring data is collected in a central repository, a reporting module accesses the central repository and uses these data to monitor patients within the patient treatment domain. However, it is possible to simulate an alarm event that would have been detected if an alarm condition set different from the one actually used during monitoring was used.
0326In some embodiments, the reporting module is used in conjunction with the patient monitoring system described herein (eg, the patient monitoring system shown in FIGS. 1, 2, 6, 7, 19, etc.). In some embodiments, the reporting module is a server or other computing device communicatively coupled with a network of bedside patient monitoring devices, central monitoring devices, databases, and other devices that can form a patient monitoring system. is there. The reporting module can include a processor that analyzes patient monitoring data. The reporting module can also include, for example, electronic memory for storing patient monitoring data.
0327In some embodiments, if the central repository contains, for example, per-patient physiological parameter trend data, the reporting module may have access to this trend data, for example, alarm conditions may be met. It can be reanalyzed using one or more of the same algorithms used in bedside patient monitoring devices to detect the presence or absence. However, in this case, a second alarm condition that differs from the first alarm condition that was used to detect the alarm condition (for example, in real time when patient monitoring data was actually collected). It is possible to use. In some embodiments, the reporting module reanalyzes the stored patient monitoring data with a number of different new alarm conditions. Therefore, the reporting module can generate information indicating how the number of detected alarms changes as a function of changes in alarm conditions.
0328FIG. 31 is a flowchart showing a method 3100 for examining a change in the identified alarm state, which is the result of a change in the alarm condition. Method 3100 first collects physiological parameter data from a group of patients in the patient treatment domain at block 3102. For example, physiological parameter data can be collected by several different bedside patient monitoring devices distributed throughout the patient treatment facility. The collected physiologic parameter data can include, for example, any type of information associated with the monitored physiologic parameters and the patient for whom the physiologic parameter data is being collected. Again, examples of collectable physiological parameter data include raw physiological signals, processed physiological signals, and calculated values of physiological parameters.
0329Block 3104 analyzes physiological parameter data to identify alarm conditions based on a first set of alarm conditions. The alarm condition may be configured to modify the physiological condition that triggers the alarm. In some embodiments, the analysis of physiological parameter data is performed in near real time (eg, by a bedside patient monitor to detect an alarm condition when it occurs). Alarm conditions generally vary for each individual physiological parameter monitored. In some embodiments, the alarm condition is a single threshold. In some embodiments, the alarm condition comprises a plurality of thresholds (eg, defining a safe or normal occlusion range of physiological parameters). Other types of alarm conditions are also available.
0330In block 3106, physiological parameter data is stored, for example, in a central repository (eg, round-robin database 722). In some embodiments, the central repository stores all (or almost all) of the physiological parameter data collected in block 3102. For example, a central repository can store physiological information, which can be, for example, a raw physiological signal from each patient, or already processed or modified to some extent (eg, by a bedside patient monitor). It is a physiological signal that has been used. In addition, the central repository can store information about all alarm states detected on a per-patient basis in block 3104. For example, a central repository can store the timing and type of each alarm condition for each patient.
0331In block 3108, it is possible to analyze the already stored physiological parameter data to identify the alarm state based on a second alarm condition that is different from the first condition used in block 3104. This analysis can be performed, for example, by the reporting module described herein. For example, in the case of blood oxygen saturation monitoring, if the detected pulse oximetry signal was analyzed at the time of actual monitoring using the 94% oxygen saturation alarm threshold, then in block 3108, this pulse oximetry signal The metric signal can be reanalyzed at 93% oxygen saturation, or 92% oxygen saturation, or any other alarm threshold. In this way, by analyzing the physiological parameter data already collected, it is possible to simulate the effect of another alarm threshold in a risk-free manner. This is because the patient can continue to be monitored, for example, in blocks 3102, 3104, with alarm conditions that have already been tolerated and validated. Thus, being able to simulate the effect of changing the alarm condition on the alarm condition identified from the physiological data, for the hospital or other patient treatment facility, sets the alarm condition to that hospital or patient treatment facility. It is advantageous as a means of adjusting to individually adapt to. It is advantageous to adapt the alarm conditions individually. This is because alarm conditions that work well in one hospital (or for one type of patient) are not always guaranteed to work well in another hospital (or for another type of patient). is there. Possible causes include different types of monitoring equipment used, different numbers of patients, different types of treatment provided, and different medical procedures performed by clinicians. And so on.
0332In some embodiments, in block 3108, one or more algorithms applied by the reporting module to the collected physiological parameter data were applied during monitoring to detect alarm conditions in real time. Same (or almost equivalent) to the above algorithm. However, this does not have to be essential in all embodiments. In addition, in some embodiments, the physiological parameter data stored in the central repository is the same (or nearly) the physiological parameter data to which the alarm detection algorithm has been applied (eg, by a bedside patient monitor when collecting the data). Equivalent). In this way, various alarm conditions can be simulated as if they were actually used when collecting physiological parameter data to detect real-time alarm conditions.
0333At block 3110, the reporting module can analyze the effect of simulated alarm conditions on detected alarm conditions. For example, the reporting module can analyze any changes in the number of alarm states detected using the new simulated alarm conditions. This information can be given, for example, by patient and / or about a collection of patients. In addition, the reporting module can analyze the difference in timing when an alarm condition is detected. In general, the reporting module uses the first alarm condition applied during monitoring to determine the number, type, timing, duration, etc. of alarm states detected using the second alarm condition. If there is a change, it is possible to analyze the change by comparing it with the detected alarm state.
0334At block 3112, the reporting module can output a report that identifies, describes, summarizes, or otherwise describes the effect of a simulated alarm condition. This report can be useful, for example, to help hospital managers determine if any changes to alarm conditions (eg, used in bedside patient monitors) are allowed. For example, as described herein, in some circumstances the alarm conditions can be modified to reduce the number of false positives detected. The reporting module can provide information about the effects that would have been achieved if such changes had already been implemented, thus enhancing the ability of hospital managers to make the above decisions. In general, hospital managers have the ultimate responsibility to determine if it is possible to safely make changes to alarm conditions (for example, to reduce false positives without unacceptably increasing false negatives). ..
0335Figure 32 shows an example reported by Table 3200 showing the effect of simulated alarm conditions on alarm detection events. Table 3200 contains row entries for five different simulated alarm conditions, but any number of new alarm conditions can be simulated. Table 3200 contains column entries for the number of alarms detected using each of the simulated alarm conditions. The number of alarms can be, for example, categorized by patient or listed as a sum of alarms detected in all patients for whom physiological parameter data has been collected.
0336Table 3200 also compared the number of alarms detected using each of the simulated alarm conditions to the number of alarms detected using the actual alarm conditions applied when collecting physiological parameter data. Contains column entries for changes. This change can be shown as a difference in the number of alarms, a percentage difference, and so on.
0337There are many other types of information and information formats for reporting the effects of simulated alarm conditions. Figure 32 is just an example of a report that the reporting module can generate based on simulated alarm conditions. Such reports can include a wide variety of information about the effects of simulated alarm conditions to help hospital managers make decisions about whether to change alarm conditions. Please understand that. In addition, such reports can be presented in a wide variety of formats, including tables, charts, graphs, lists, spreadsheets and more.
0338FIG. 33 is a flow chart illustrating another method 3300 for examining the identified change in alarm state as a result of a change in alarm condition. Method 3300 is similar to Method 3100 shown in FIG. 31, but Method 3300 further comprises investigating the expected effect of simulated alarm limits on, for example, false positive and false negative alarms. ..
0339Method 3300 can proceed as described above for methods 3100 and blocks 3102, 3104 shown in FIG. 31 for blocks 3302 and 3304. In contrast, in block 3306, method 3300 further comprises collecting medical intervention data. The medical intervention data can include, for example, a record of whether the patient required some type of medical intervention at any point during the monitoring of physiological parameters. Such medical interventions include, for example, drug management, physician or nurse response (eg, symptomatic response), response team response, treatment or treatment management, and the like. The medical intervention data can also include any relevant information about the medical intervention, such as the type, time, and duration of the medical intervention, the medical cause that required the medical intervention, and the relationship with the alarm detection event. is there.
0340In some embodiments, using the medical intervention data collected in block 3306, if there was a false positive alarm among the alarm states detected in block 3304, which and / or medical distress. Find out which alarm was the correct sign. Then, using this information, for example, if there were various simulated alarm conditions, whether any of the identified false positive alarms were not identified, or in those simulated alarm conditions. If so, it is possible to find out if, as a result, any of the alarms that actually indicated the need for medical intervention was not detected (for example, if the result was a false negative). is there. In addition, medical intervention data can be used to identify false negatives and, if the alarm conditions were simulated, to determine if such false negatives were detected as a result. .. By analyzing this information and presenting it in the report, the hospital administrator modifies the alarm conditions used in the patient monitoring device based on the simulated alarm conditions, as described herein. It is possible to further assist in making a decision as to whether or not it should be done.
0341Medical intervention data can be obtained in a variety of ways. For example, medical intervention data can be recorded by clinicians when medical intervention is needed. You can then manually import these records into a central repository. The central repository also stores the collected physiological parameter data. Medical intervention data can also be automatically imported into a central repository from patient electronic medical records (eg, stored in hospital or clinical information systems). In some embodiments, the bedside patient monitoring device can be configured to prompt the clinician to enter medical intervention data (eg, after the alarm has been disabled). Other methods of obtaining records of medical interventions are also available.
0342If the record of medical interventions performed on the patient is, for example, temporally related to the timing of the detected alarm state (eg, the interval between the record of medical intervention and the detected alarm state is a predetermined threshold). For some time length less than), this record can be considered to represent a correctly detected alarm condition. For example, if medical intervention is performed within a relatively short period of time after a detected alarm condition, the alarm condition may have required medical attention. On the other hand, if the record of medical interventions performed was not temporally related to the timing of any alarm condition detected for the patient, then the medical condition requiring medical intervention did not trigger the alarm. , This record is considered to represent a false negative. In the second half of Method 3300, after various new alarm conditions were simulated, whether such simulated conditions detected false negatives, or alarm conditions that were properly set during monitoring. It is possible to determine whether an alarm condition correctly detected by is detected even under the new simulated conditions.
0343In some embodiments, the medical intervention data can include an automatic estimation of whether a medical intervention has been performed on a given patient. An estimate of whether medical intervention was required after the alarm detection event (for example, the length of time the clinician was with the patient after responding to the alarm event, or some from the detected alarm event). It can be done automatically (based on whether the doctor came and examined the patient within the time limit). This information can be collected using the clinician proximity detectors and systems described herein. For example, in some embodiments, the patient monitoring device may activate a timer after an alarm detection event has occurred. If the presence of a doctor is detected within some time (eg, identified by a clinician token, as described herein), that doctor's visit was made in response to an alarm event. It is possible to estimate. Therefore, the doctor's visit can be identified as a medical intervention. Similarly, a patient monitoring device can track the length of time a clinician (eg, a nurse) has been in the vicinity of a patient after the alarm has been silenced. If the length of time spent at the patient exceeds a certain threshold, it can be inferred that some type of medical intervention was needed in response to the alarm event.
0344In addition, an estimate of whether medical intervention was required (eg, after an alarm event) can be determined by analyzing the physiological data collected for that patient. For example, the reporting module can analyze trend values for physiological parameters to determine if the physiological parameters continue to deteriorate after the detection of an alarm event. In some embodiments, the reporting module analyzes trend data to determine if the patient's condition, indicated by trend values for physiological parameters, deteriorated 1 minute after the alarm detection event and / or 5 minutes later. It is possible to determine if it did and / or if it deteriorated after 10 minutes. Of course, other time limits are also available. If such an analysis indicates that the patient's condition has deteriorated after the detection of the alarm event, this indicates that the patient was in medical distress and that the alarm was not a false positive. It can be regarded as a manifestation of what was actually represented.
0345As just described, the medical intervention data used in Method 3300 can be obtained from the actual records of medical interventions performed. Alternatively or additionally, the medical intervention data used in Method 3300 may be, for example, the length of time the clinician has been with the patient as a result of the alarm event being detected, or after the alarm event has been detected. It can be estimated based on factors such as the behavior of physiological parameters within some reasonable time. Other factors and methods for estimating the implementation of medical interventions are also available. Although medical intervention data from actual clinical personnel records are more accurate and reliable, the implementation of such medical interventions may not be reported. Estimated medical intervention data can be useful because it requires less reliance on clinicians to maintain accurate records, but estimates are somewhat less reliable than actual clinician records. There is.
0346Block 3308 allows the collected physiological parameter data and medical intervention data to be stored, for example, in a central repository (eg, Round Robin Database 722) for later analysis by the reporting module. The reporting module can include logic that correlates the collected medical intervention data with the detected alarm events. For example, this logic can include rules or conditions that determine whether a given medical intervention for a patient was associated with an alarm condition that occurred for that patient. For example, when medical intervention data is actually obtained from clinical personnel records, the interval between the implementation of a particular medical intervention for a patient and the occurrence of alarm events detected for that patient is for a particular length of time. Within the range, the medical intervention can be correlated with the alarm event that occurred. Alternatively, it is possible to match the medical intervention data with the corresponding detected alarm event that may have been associated with the medical intervention. For example, such interrelationships can be based on the type of medical intervention performed and the type of physiological parameter for which monitoring data was obtained. It is possible to view some medical interventions as those that are particularly likely to be associated with a particular physiological parameter. In such cases, the logic of the reporting module can be configured so that such medical interventions are more likely to be marked as interrelated with alarm events triggered by their physiological parameters. ..
0347At block 3310, the reporting module analyzes physiological parameter data using a second alarm condition (eg, described with respect to FIG. 31 (eg, block 3108)). In block 3312, the reporting module can analyze the difference between the alarm state identified using the first alarm condition and the alarm state identified using the simulated second alarm condition. It is possible. The reporting module, for example, identifies the alarm state that would have been detected if it were the second alarm condition, and then uses the first alarm condition to identify the true alarm state that was correctly identified during the actual monitoring. It is possible to determine how much of the alarm conditions were detected, even if they were implemented instead. It is desirable that such true alarm conditions be detected as well so that the number of false negatives does not increase. Therefore, to assist in deciding whether to adopt the proposed alarm condition changes, we provide information on the number of true alarm states that would not be detected under a given simulated alarm condition. , Can be provided to hospital managers.
0348In addition, the reporting module can analyze the effect of simulated alarm conditions on all identified false negatives based on medical intervention data. In some embodiments, the reporting module has detected any false negatives that were not identified in the first alarm condition actually used in the patient monitoring device, if they were in the simulated alarm condition. Can be determined. This determination is designed to determine, for example, whether any alarm condition detected using simulated alarm conditions correlates with an already identified false negative event in time. It is possible by executing the logic that is done. For example, if the alarm state identified under the simulated alarm condition precedes the identified false-negative timing for some time shorter than a given threshold, then the alarm state is false-negative. It can be regarded as representing what would have been a manifestation of. Other logical tests can be applied to correlate the identified alarm conditions with the identified false negatives based on medical intervention data, which is detected under simulated alarm conditions. ..
0349In block 3314, the reporting module outputs a report that identifies, describes, summarizes, or otherwise describes the effect of the simulated alarm condition. In some embodiments, this report may have been detected if the simulated alarm condition was, for example, a simulated alarm condition, as well as for the number of alarm events detected. It is possible to show the expected effect on certain, previously undetected number, percentage, ratio, etc. of false negatives. The report should also show, for example, the number, percentage, percentage, etc. of actual alarm conditions that were correctly identified under the first alarm condition and might not have been identified under the second alarm condition. Is also possible. This report may include other information as well.
0350FIG. 34 shows an example reported by Table 3400 showing the effect of simulated alarm conditions on the total number of alarm detection events and the effect of this simulated alarm condition on, for example, false negatives and false positives. .. Table 3400 is similar to Table 3200 shown in Figure 32 and contains row entries for five different simulated alarm conditions. Table 3400 contains column entries for the number of alarms detected using each of the simulated alarm conditions. Table 3200 also compared the number of alarms detected using each of the simulated alarm conditions to the number of alarms detected using the actual alarm conditions applied when collecting physiological parameter data. Contains column entries for changes.
0351In addition, Table 3400 contains column entries for the estimated number or percentage of false negatives that were not previously detected but would have been detected under certain simulated alarm conditions. Table 3400 is also correctly identified by the first alarm condition, but by the true alarm state (ie, the simulated alarm condition) that would not have been identified if it were a specific simulated alarm condition. Contains column entries for the estimated number or percentage of newly introduced false negatives). These values can be calculated or estimated by the reporting module as described herein. Table 3400 could also contain information about changes in the number of false positives, for example, it would have been detected under the first alarm condition but not under the simulated alarm condition. It is also possible to include information about the number of false positives, or the number of false positives that were not detected under the first alarm condition but would have been detected under the simulated alarm condition.
0352Figure 34 is also just an example of a report that the reporting module can generate based on simulated alarm conditions. It should be understood that such reports can contain a wide variety of information to assist hospital managers in making decisions about whether alarm conditions should be changed. In addition, such reports can be presented in a wide variety of formats, including tables, charts, graphs, lists, spreadsheets and more.
0353In addition to simulating alarm conditions as described herein, the reporting module can also simulate the effects of other configuration changes to the bedside patient monitor and / or the central patient monitor. is there. For example, the reporting module can simulate the effects of various alarm notification delay times. As described herein, in some embodiments, the bedside patient monitor waits until a predetermined alarm notification delay time elapses when an alarm condition is detected, and then notifies the alarm event. Can be configured to be sent to a clinician or central monitoring device. In addition, the central monitoring device likewise waits for a given alarm notification delay time to elapse and then actually sends the detected alarm notification to the clinician (eg, by paging or other notification method). It can be configured to do so.
0354These notification delay times can help reduce the frequency of false positive alarm notification events when the alarm condition lasts only temporarily. Such a temporary alarm state may be caused, for example, by sudden movements or emotions. The reporting module can help simulate the effect of changing the notification delay time for alarm notification events. This can be useful, for example, because a relatively small change in notification delay time can lead to a significant reduction in the number of false positives that clinicians must address.
0355FIG. 35 is a flowchart showing a method 3500 for examining a change in an alarm notification event that occurs as a result of a change in the alarm notification delay time. In method 3500, first, at block 3502, the patient is monitored for physiological parameter alarm events, as described herein.
0356Method 3500 proceeds to block 3504, where it identifies the alarm notification event based on the first alarm notification delay time. For example, the alarm notification event may be an alarm status notification from the bedside patient monitor to the central monitoring device. In this case, the first alarm notification delay time can be measured as the elapsed time between the time when the bedside monitor detects the alarm state and the time when the notification of this alarm is sent to the central monitoring device. .. Further, the alarm notification event may be a notification of the alarm status from the patient monitoring device to the clinical staff. In this case, the first alarm notification delay time can be measured as the elapsed time between the time when the alarm condition is detected and the time when the clinician is notified.
0357In the early stages of monitoring, one or more algorithms were applied to low physiology signals, processed physiology signals, and / or physiology to detect if the alarm condition persisted for the duration of the first alarm notification delay. It can be applied to the calculated value of the target parameter. This can be done, for example, by each bedside patient monitor for each patient in the patient treatment domain. If the alarm state persists for the duration of the first alarm notification delay time, it is possible to recognize the alarm notification event.
0358In block 3506, physiological parameter data is collected and stored, for example, in a central repository as described herein (eg, round-robin database 722). In block 3508, the physiological parameter data is reanalyzed. This is done, for example, in a reporting module that uses a second alarm notification delay time that is different from the first alarm notification delay time. For example, if the first alarm notification delay time used by the patient monitoring device in block 3504 was 5 seconds, then the alarm notification delay time was set to, for example, 6 seconds or 7 seconds, and the physiological parameter data was reissued. It is possible to analyze. It can be simulated with a shorter delay time.
0359In some cases, if the alarm state is only temporary in nature, a slightly longer alarm notification delay may result in the alarm state ending before the alarm notification event is generated. By adjusting the alarm notification delay time in this way, it is possible to potentially safely reduce the number of alarm notification events that the clinician must respond to. This allows clinicians to spend more time responding to non-temporary alarm events, increasing the effectiveness of patient care. Of course, in general, any change in the alarm notification delay time requires the approval of the hospital administrator or other responsible person. This is because, for example, by increasing the alarm notification delay time, the elapsed time between alarm detection and the arrival of the clinician is increased so that the patient is not at unacceptable risk. Is.
0360By analyzing the physiological parameter data already collected in the reporting module, it is possible to simulate the effect of another alarm notification delay time in a risk-free manner. This is because patients can continue to be monitored with, for example, blocks 3502, 3504, with a delay time that has already been tolerated and validated. Thus, being able to simulate the effects that those alarm notification delays would have, without necessarily actually implementing different alarm notification delays, is an alarm notification delay for hospitals or other patient care facilities. It is advantageous as a means of adjusting the time to be individually adapted to the hospital or patient care facility in question. As described herein with respect to alarm conditions, varying alarm notification delay times can result in a significant reduction in the number of alarm notification events, not necessarily increasing patient risk.
0361In block 3510, the reporting module has the number of clinician notification events detected using the first alarm notification delay and the number of clinician notification events detected using the second alarm notification delay. It is possible to analyze the difference with. For example, the reporting module can determine whether the total number of alarm notification events will decrease or increase in response to a change in the alarm notification delay time, and calculate how much it will decrease or increase. By presenting this information to the hospital administrator in the form of tables, charts, spreadsheets, etc., the hospital administrator can determine whether the change in alarm notification delay time performed by the patient monitoring device is advantageous. It is possible to support.
0362It is also possible to collect and store data on the time to response of clinical personnel for analysis by the reporting module. The time to respond to the clinician is, for example, when the clinician is notified of the alarm status and when the clinician arrives in the hospital room to turn off the alarm and check the patient's condition. It can be measured as the elapsed time between. This elapsed time can be measured, for example, by a bedside patient monitor and sent to a central data repository. The time to respond to a clinician can be stored for each clinician and / or for the entire group of clinicians. As a result, the reporting module can output information about the maximum, minimum, and average response times for each clinician and / or the entire group of clinicians, for example. .. This data can be useful to hospital managers as an indicator of how individual clinicians, or groups of clinicians, can respond immediately to surveillance alarms. Display function
0363Figures 36A-B show a display with multiple layout zones, including parameters 3610, plethysmograph 3620, prompt window 3630, patient information 3640, monitor settings 3650, monitor status 3660, user profile 3670, Includes parameters well 3680, pulse-to-pulse signal quality bar 3690, and zones for softkey menu 3695. Advantageously, each zone is dynamically scaled with information so that the parameters most important to nearby users are easy to read. The prompt window 3630 also uses a superposed message display that temporarily overlays less important parts of the display. In addition, the parameter well 3680 houses parameters selected by nearby users so that they are minimized until they raise an alarm. In the following, these and other display efficiency improvement functions will be described.
0364Figures 37A-F show a display that changes the layout and font size depending on the number of installed parameters. The figure shows 8 parameters (Fig. 37A), 7 parameters (Fig. 37B), 6 parameters (Fig. 37C), 5 parameters (Fig. 37D), 4 parameters (Fig. 37E), and 3 The horizontal and vertical display formats for displaying individual parameters (Fig. 37F) are shown. Advantageously, the font size increases with fewer installed parameters. In addition, the parameter layout varies according to the number of lines and spacing depending on the number of installed parameters. The plethysmograph display also increases in size when there are few installed parameters. In addition, the font size of the text information is scaled according to the amount of information displayed. For example, the font for displaying patient names becomes smaller as date and time information is added.
036538A-B show a display 3800 with parameter well 3810. Specifically, the parameter value is displayed in either the main display portion or the parameter well. Parameters are minimized to parameter wells by user profiles that are invoked through menu selection or when the user is in the vicinity. Advantageously, one or more parameters are displayed in a relatively small font within the parameter well. On the other hand, when the minimized parameter raises an alarm, the parameter is removed from the parameter well and returns to the main display in a relatively large font.
0366Figures 39A to 39B show enlarged parameter displays 3900 and 3901 in which the font size of the parameter issuing the alarm is increased. Under normal conditions, all parameters are displayed in the same size font. When an alarm occurs, the actual and limit values of the over-limit parameter are displayed in a large font and then blink to remind you that the parameter has exceeded the limit. In another embodiment, if all parameters are displayed in the maximum or near maximum size font, the size of the alarming parameter will be slightly larger and the size of all other parameters will be smaller. .. As a result, the parameter that is issuing the alarm is enlarged. In one embodiment, the background color is also soft (eg, red background color) when a single parameter is alarming (Fig. 39A) or all parameters are alarming (Fig. 39B). Blinks at the same frequency (with the red background color) to contrast with the blinking font.
0367FIGS. 40-43 show other display embodiments with various advantageous features. FIGS. 40A-B show a trend indicator 4000 with a colored alarm zone 4010 colored so that the user can easily identify the history of the severity of the patient condition that triggered the alarm. FIG. 41 shows a display in which the arrow keys and the black-and-white inversion of the cursor are combined. Figures 43A-B show the trend display and the corresponding setup screen.
0368FIG. 42 shows a display with a jump screen that the user can select. Specifically, the user can select one of a plurality of jump screens (for example, the seven options shown) accessible from the home page through the menu option choices. In one embodiment, the default behavior of this button is the "Trend Toggle" button 4231. Other buttons are "Alarm Limit" 4232, "Compressed Waveform Display or PI and PVI Trend Overlay" 4233, "Mode Sensitivity" 4234, "Patient Assessment" 4235, "Parameter Detail Toggle" 4236, and "User Profile Login" 4237. Is.
0369The information and signals described herein can be expressed using any of a variety of techniques and techniques. For example, the data, instructions, commands, information, signals, bits, symbols, and chips that can be referenced through the above description are by voltage, current, electromagnetic waves, magnetic or magnetic particles, light fields or optical particles, or any combination thereof. It can be expressed.
0370The various exemplary logical blocks, modules, circuits, and algorithmic steps described with respect to the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination thereof. To demonstrate this hardware and software compatibility, various exemplary components, blocks, modules, circuits, and steps have been generally described in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. Those skilled in the art can implement the described functionality in various ways depending on the specific application, but such implementation decisions will cause deviations from the scope of the invention. It should not be interpreted.
0371According to embodiments, any particular action, event, or function of any of the methods described herein can be performed in various sequences, with no additions or combinations. It is also possible (for example, not all actions or events described are essential to the practice of this method). Further, in certain embodiments, it is possible to perform multiple actions or events in parallel (eg, by multithreading, interrupt handling, or multiple processors) rather than sequentially.
0372The various exemplary logic blocks, modules, and circuits described with respect to the embodiments disclosed herein include general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), and field programmable gate arrays (FPGAs). ) Or other programmable logic elements, discrete gate logic or transistor logic, discrete hardware components, or any combination of these designed to perform the functions described herein. is there. The general purpose processor may be a microprocessor, a conventional processor, a controller, a microcontroller, a state machine, or the like. Processors can also be implemented as a combination of computing devices, such as a combination of DSP and microprocessor, multiple microprocessors, a combination of one or more microprocessors and a DSP core, or any other such combination. It can be implemented as a configuration. Furthermore, the term "processing" is a broad term intended to include multiple meanings, which include, for example, implementing program code, executing instructions, and manipulating signals. , Filtering, performing arithmetic operations, etc.
0373Each step of the method or algorithm described with respect to the embodiments disclosed herein can be performed directly in hardware, in a software module running on a processor, or in combination of both. Software modules can be stored in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, DVDs, or any other format known in the art. May exist. The storage medium is coupled to the processor, which allows the processor to read information from the storage medium and write information to the storage medium. Alternatively, the storage medium may be integrated with the processor. The processor and storage medium may reside within the ASIC. The ASIC may exist in the user terminal. Alternatively, the processor and storage medium may exist as discrete components within the user terminal.
0374Modules are software object-oriented software components, class and task components, processes, methods, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables. It may include, but is not limited to, software or hardware components such as, arrays, or variables.
0375Further, although the present invention has been disclosed in the context of certain preferred embodiments, certain advantages, features, and embodiments of the systems, devices, and methods of the invention are feasible in various other embodiments. I want you to understand. Moreover, the various aspects and features described herein can be implemented individually, in combination, or interchangeably with each other, and various combinations and subcombinations of those features and aspects are possible. It should be understood that they also fall within the scope of the present invention. Moreover, the systems and devices described above need not include all of the modules and functions described in the preferred embodiments.
64 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25 Sheet 26 Sheet 27 Sheet 28 Sheet 29 Sheet 30 Sheet 31 Sheet 32 Sheet 33 Sheet 34 Sheet 35 Sheet 36 Sheet 37 Sheet 38 Sheet 39 Sheet 40 Sheet 41 Sheet 42 Sheet 43 Sheet 44 Sheet 45 Sheet 46 Sheet 47 Sheet 48 Sheet 49 Sheet 50 Sheet 51 Sheet 52 Sheet 53 Sheet 54 Sheet 55 Sheet 56 Sheet 57 Sheet 58 Sheet 59 Sheet 60 Sheet 61 Sheet 62 Sheet 63 Sheet 64
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2005514078A | Cites | Japan |
| JP2008036005A | Cites | Japan |
| JP05053605U | Cites | Japan |
| US20111605A1 | Cites | United States of America |
63 members in 4 offices
Members63
| Document | Office | Kind | |
|---|---|---|---|
| WO2009049254A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US2009119330A1 | United States of America | A1 | |
| WO2009049254A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP2208158A2 | European Patent Office (EPO) | A2 | |
| WO2010102069A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2009049254A9 | World Intellectual Property Organization (WIPO) | A9 | |
| JP2011501274A | Japan | A | |
| US2011001605A1 | United States of America | A1 | |
| US2011105854A1 | United States of America | A1 | |
| US2011169644A1 | United States of America | A1 | |
| EP2404253A1 | European Patent Office (EPO) | A1 | |
| JP2012519547A | Japan | A | |
| US8274360B2 | United States of America | B2 | |
| US8310336B2 | United States of America | B2 | |
| US2013045685A1 | United States of America | A1 | |
| US2013096936A1 | United States of America | A1 | |
| US2013162433A1 | United States of America | A1 | |
| US2014135588A1 | United States of America | A1 | |
| JP5749658B2This record | Japan | B2 | |
| US9142117B2 | United States of America | B2 | |
| JP2015198941A | Japan | A | |
| US9218454B2 | United States of America | B2 | |
| US9323894B2 | United States of America | B2 | |
| US2016283665A1 | United States of America | A1 | |
| US2016314260A1 | United States of America | A1 | |
| JP2017200587A | Japan | A | |
| US2018174679A1 | United States of America | A1 | |
| US2018174680A1 | United States of America | A1 | |
| US10007758B2 | United States of America | B2 | |
| US2018182484A1 | United States of America | A1 | |
| US10032002B2 | United States of America | B2 | |
| US10255994B2 | United States of America | B2 | |
| US2019122762A1 | United States of America | A1 | |
| US2019122763A1 | United States of America | A1 | |
| US10325681B2 | United States of America | B2 | |
| US10366787B2 | United States of America | B2 | |
| JP6568143B2 | Japan | B2 | |
| EP2404253B1 | European Patent Office (EPO) | B1 | |
| US2019304601A1 | United States of America | A1 | |
| JP2020004422A | Japan | A | |
| EP3605550A1 | European Patent Office (EPO) | A1 | |
| US11087875B2 | United States of America | B2 | |
| US11133105B2 | United States of America | B2 | |
| US11145408B2 | United States of America | B2 | |
| US11158421B2 | United States of America | B2 | |
| US11176801B2 | United States of America | B2 | |
| JP6974400B2 | Japan | B2 | |
| JP2022020743A | Japan | A | |
| US2022108795A1 | United States of America | A1 | |
| US2022157443A1 | United States of America | A1 | |
| US2022157447A1 | United States of America | A1 | |
| US2022215944A1 | United States of America | A1 | |
| US2022262230A1 | United States of America | A1 | |
| US11816973B2 | United States of America | B2 | |
| US11923080B2 | United States of America | B2 | |
| JP7444832B2 | Japan | B2 | |
| US2024177591A1 | United States of America | A1 | |
| US2024203578A1 | United States of America | A1 | |
| US12057222B2 | United States of America | B2 | |
| US12057222B2 | United States of America | B2 | |
| US12062439B2 | United States of America | B2 | |
| US2025046440A1 | United States of America | A1 | |
| US2025046441A1 | United States of America | A1 |
24 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 5749658
- Application
- 2011553097
Titles2
- Japanese
- 医療監視システム
- English
- Medical surveillance system
Classification
- CPC, 9
- G16H40/40
- G16H40/63
- G16H40/20
- G16H50/50
- G16H30/20
- G16H40/67
- G06F3/0482
- G16H10/60
- G16H40/00
- IPC, 4
- A61B5 00
- G06Q50 22
- A61G12 00
- G16H10 60
