(57)【要約】【課題】医療装置用の少なくとも１つのマシン読取り可能ファイルを作成するための優れたコンピュータシステム及び方法を提供する。【解決手段】本発明は、少なくとも１つのパラメータセットを提供するためのデータベースと、医療装置のフロー振舞いに関するデータをパラメータセットとして入力するための入力デバイス（１４）と、入力されたデータを考慮に入れてフロー定義出力ファイル（２０）を作成し出力するための出力デバイス（１６）と、少なくともパラメータセットを使用して記憶媒体内に少なくとも１つのマシン読取り可能ファイル（５２、５４）又はマシン読取り可能データを作成するための変換デバイス（２２）とを備える、医療装置用の少なくとも１つのマシン読取り可能ファイルを作成するためのコンピュータシステムを提案する。さらに、対応する方法、データ媒体及び医療装置が指定される。【選択図】図３
2012524922.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのパラメータセット、特に治療固有のパラメータセットを提供するためのデータベース（１２）、を有する、医療装置用の記憶媒体内に存在する少なくとも１つのマシン読取り可能ファイル又はマシン読取り可能データ（５２、５４）を作成するためのコンピュータシステム（１０）であって、
前記医療装置のフロー振舞いに関するデータをパラメータセットとして入力するための入力デバイス（１４）と、
入力されたデータを考慮に入れてフロー定義出力ファイル（２０）を作成し出力するための出力デバイス（１６）と、
前記パラメータセット、前記入力されたデータおよび前記フロー定義出力ファイル（２０）のうち少なくとも１つを使用して、記憶媒体内の少なくとも１つのマシン読取り可能ファイル又はマシン読取り可能データ（５２、５４）を作成するための変換デバイス（２２）と、
を有することを特徴とするコンピュータシステム（１０）。
【請求項２】
前記出力デバイス（１６）が、いくつかの行といくつかの列のうち両方又は一方を有する少なくとも１つのスプレッドシートを有するフロー定義出力ファイル（２０）を出力する準備ができている、請求項１に記載のコンピュータシステム（１０）。
【請求項３】
前記フロー定義出力ファイル（２０）の前記スプレッドシートが、少なくとも検出状況、配布リスト、プロセスブロック、システム状況ブロック及び反応ブロックを包含するグループからの少なくとも情報のための行及び列を備えるユニットへとさらに分割される、請求項１又は２に記載のコンピュータシステム（１０）。
【請求項４】
前記フロー定義出力ファイル（２０）がアラーム定義スプレッドシートを包含する、請求項１〜３の何れか一項に記載のコンピュータシステム（１０）。
【請求項５】
請求項１〜４の何れか一項に記載のコンピュータシステム（１０）によって作成された少なくとも１つのマシン読取り可能ファイル、又は、こうしたコンピュータシステム（１０）によって作成され記憶媒体内に存在するマシン読取り可能データ、を有することを特徴とする、データ媒体。
【請求項６】
請求項１〜４の何れか一項に記載のコンピュータシステム（１０）によって作成された多数のマシン読取り可能ファイル、又は、記憶媒体内に存在するマシン読取り可能データセット（５２、５４）を有し、前記多数のマシン読取り可能ファイル又は前記記憶媒体内に存在するマシン読取り可能データ（５２、５４）からの、少なくとも２つのファイル又はセットが互いに異なる、請求項５に記載のデータ媒体。
【請求項７】
請求項１〜４の何れか一項に記載のコンピュータシステム（１０）によって作成された少なくとも１つのマシン読取り可能ファイル、又は、記憶媒体内に存在するマシン読取り可能データ（５２、５４）を有することを特徴とする、医療装置（５０）。
【請求項８】
請求項１〜４の何れか一項に記載のコンピュータシステム（１０）によって作成された前記マシン読取り可能ファイル、又は、記憶媒体内に存在するマシン読取り可能データ（５２、５４）が、ファイルされる記憶装置、特にＲＯＭを有する、請求項７に記載の医療装置（５０）。
【請求項９】
フロー追跡装置（５６）を有する、請求項７又は８に記載の医療装置（５０）。
【請求項１０】
アラーム状況追跡装置がＲＯＭにファイルされる、請求項７〜９の何れか一項に記載の医療装置（５０）。
【請求項１１】
透析装置として具現化される、請求項７〜１０の何れか一項に記載の医療装置（５０）。
【請求項１２】
コンピュータシステムによって、医療装置用の記憶媒体内に存在する少なくとも１つのマシン読取り可能ファイル又はマシン読取り可能データ（５２、５４）を作成するための方法であり、前記コンピュータシステム内に少なくとも１つの特に治療特有のパラメータセットを提供するステップ、を有している当該方法であって、
入力デバイス（１４）によって設定されたパラメータセットとして前記医療装置のフロー振舞いに関するデータを入力するステップと、
出力デバイス（１６）によって、入力されたデータを考慮に入れてフロー定義出力ファイル（２０）を出力するステップと、
前記パラメータセット、前記入力されたデータおよび前記フロー定義出力ファイル（２０）のうち少なくとも１つを使用し、特に変換して、記憶媒体内に存在する少なくとも１つのマシン読取り可能ファイル又はマシン読取り可能データ（５２、５４）を作成するステップと、
を有することを特徴とする方法。
【請求項１３】
いくつかの行といくつかの列のうち両方又は一方を備えた少なくとも１つのスプレッドシートを有するフロー定義出力ファイル（２０）を出力するステップ、
を有する、請求項１２に記載の方法。
【請求項１４】
前記スプレッドシートが、少なくとも検出状況、配布リスト、プロセスブロック、システム状況ブロック及び反応ブロックを包含するグループからの情報のための少なくとも行又は列を備えるユニットを備えるように、前記フロー定義出力ファイル（２０）の前記スプレッドシートを作成するステップ、
を有する、請求項１２又は１３に記載の方法。
【請求項１５】
前記フロー定義出力ファイル（２０）が、アラーム定義スプレッドシートとして作成される、請求項１２〜１４の何れか一項に記載の方法。
【請求項１６】
請求項１２〜１５の何れか一項に記載の方法が実行されるように、プログラマブルコンピュータシステムと対話できる電子的に読取り可能な制御信号を備える、とりわけ取外し可能な媒体であるデジタル記憶媒体。
【請求項１７】
コンピュータプログラム製品であって、
当該コンピュータプログラム製品がコンピュータ上で実行されるとき、請求項１２〜１５の何れか一項に記載の方法を実行するためのマシン読取り可能な搬送波上に保存されたプログラムコード、を備える、当該コンピュータプログラム製品。
【請求項１８】
コンピュータプログラムであって、
当該コンピュータプログラムがコンピュータ上で実行されるとき、請求項１２〜１５の何れか一項に記載の方法を実行するためのプログラムコード、を備える、当該コンピュータプログラム。
【請求項１９】
請求項１６に記載のデジタル記憶媒体、請求項１７に記載のコンピュータプログラム製品、又は、請求項１８に記載のコンピュータプログラム、を備える医療装置（５０）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、請求項１のプリアンブルの特徴を有するコンピュータシステムに関する。本発明はさらに、請求項５のプリアンブルに記載のデータ媒体、及び請求項７のプリアンブル又は請求項１９に記載の医療装置に関する。さらに、本発明は、請求項１２のプリアンブルの特徴を有する方法、請求項１６に記載のデジタル記憶媒体、請求項１７に記載のコンピュータプログラム製品、及び請求項１８に記載のコンピュータプログラムに関する。
【背景技術】
【０００２】
例えば透析装置のような医療装置は、通常精巧なファームウェアによって制御又は調整される。このソフトウェアは、直観的にアクセスできないＣ＋＋などのプログラミング言語で前もって規則的にプログラムされる数千のプログラム行をしばしば包含する。こうしたソフトウェアがベースとしているソースコードは通常、ソフトウェア更新ごとに、また新しいソフトウェアバージョンごとにより精巧に、しばしばより複雑になる。したがって、例えば更新に必要な修正など、ソフトウェアへの修正は、高い技能を有するプログラマによって入力されなければならない。ソフトウェアの作成は依然として極めて個人的な作業なので、既存のプログラム設計又はスタイルのために別のプログラマを訓練する追加の労力及び経費を回避すべきならば、さらに前のソフトウェアバージョンを既にプログラムしたのと同じプログラマによって修正を行わなければならない場合が多い。しかし、ソフトウェアへの必要な修正を行う労力は、どんな場合にも非常に大きい。同じことが、ソフトウェアの修正に関連する経費にも当てはまる。
【０００３】
ソフトウェアで操作される医療装置のプロセスの要件変更によるソフトウェアの修正は、各修正の後、装置が完全に機能することを検証するために、修正された機能だけでなく、装置全体のすべての従来機能をも認定し（ｑｕａｌｉｆｙ）又は承認することを必要とする。これは、例えば透析装置など、より複雑なシステムでは、しばしば膨大の数のケースがテストでされ、労力が付随することになり得る。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ソフトウェアを最新に修正することによってフロー又はプロセスの振舞いを変更するにはプログラミングスキルが必要なので、ソフトウェア開発者だけが、ファームウェアのフローの振舞いを修正することができる。しかし、通常はソフトウェア専門家ではないプロセス開発者は、たとえ治療法を最もよく知っており、対応する装置のフロー振舞いの修正又は変更のために特によく訓練されているとしても、それらの修正を行うことができない場合が多い。また、この事実によって、プログラマとプロセス開発者の間で調整が必要であるために労力及び費用が生じることになる。さらに、コミュニケーションがうまく行われないために、作業の誤りの確率が高まる。
【課題を解決するための手段】
【０００５】
本発明は、ソフトウェア修正の実行を簡単にし、又はファームウェアによる影響を受ける医療装置のフローパターンを再プログラミングするためのコンピュータシステムを提案する目的に基づく。さらに、データ媒体及び医療装置が指定される。さらに、対応する方法が示される。
【０００６】
本発明による目的は、請求項１の特徴の組合せによって達成される。これによって、本発明によるコンピュータシステム（略してシステム）は、医療装置用（特に透析装置用）の少なくとも１つのマシン読取り可能ファイルを作成し、特に装置を操作し、制御し又は調整するための少なくとも１つのメモリ又は１つのデータベースを特に包含する。本発明によるコンピュータシステムは、本発明による特定の実施形態では、上記を作成するために、意図され、及び／又は、構成され、及び／又は、使用される。
【０００７】
データベースは、当業者に知られているＳＱＬデータベースであってもよいし、他の適切なデータベースであってもよい。
【０００８】
メモリ又はデータベース内で医療装置の操作に関連するデータは、一時的に（メモリ又はデータベースに電流又は電力が供給されている間だけ）、又は永続的に（電流又は電源が切断された後も）保存され、任意選択により供給されてもよい。
【０００９】
保存されたデータは好ましくは、医療装置の操作に関連するすべてのデータの一部又は全体であることも、それを包含することもある。
【００１０】
保存されたデータは好ましくは、固有のプログラムセクションで符号化される治療に特有のフローのパラメータ化に使用されてもよい。
【００１１】
このデータは、少なくとも１つの第１のプログラミング言語の１つ又は複数のパラメータセット又はソースコードの形で存在してもよい。このデータは、第１のプログラミング言語のこうしたパラメータセット又はソースコードから生成されたファイルの形、或いはそこから生成されたプログラム、特にマシン読取り不可能プログラムの形で存在することもできる。
【００１２】
単一のコンピュータ、或いはいくつかのデバイス、コンピュータ又は他の装置の組合せによって表されてもよいこのシステムは、少なくとも１つの入力デバイスをさらに備える。
【００１３】
入力デバイスは、インターフェースソフトウェアを包含してもよいし、インターフェースソフトウェアであってもよい。
【００１４】
入力デバイスは、キーボード、コンピュータマウス、スティックなど、データ手動入力用に設計されてもよい。しかし、入力デバイスは、本発明による目的のために当業者によく知られている他の何れかの方法で設計することもできる。
【００１５】
入力デバイスは、ユーザが特別なプログラミングスキルなしに入力を行うことができる、入力を容易にし、誤った入力を防止するよう備えた用意されたフォームを有することができ、また任意選択でシステムによって、医療装置のプロセスにおいてどこが修正又は新しいルーチンを反映しているか導かれる。
【００１６】
インターフェース又はフォームは、一般に分かりやすいように構造化されてもよい。インターフェース又はフォームは、ユーザ補助を備えてもよい。
【００１７】
これによって、入力は、論理、及び他の入力又は知られている残りのデータとの互換性について、システムによってチェックされてもよい。これによって認識された異常が、ユーザに伝えられてもよい。
【００１８】
入力デバイス、又は入力デバイス用に提供されたフォームの入力は、したがって、高い技能をもつソフトウェア開発者の補助を必要とせず、それらの入力は、例えばプロセス開発者自身によって実行することができる。
【００１９】
データベース及び入力デバイスは、プロセス開発者のホスト又はワークステーション上にあってもよい。したがって、データベース及び入力デバイスは、医療装置の存在とは関係なく操作することができる。
【００２０】
医療装置のフロー振舞いに関連する入力デバイスによって入力されるデータは、これによって、少なくとも１つのパラメータセット及び／又は第１のプログラミング言語ではないプログラミング言語の形式、及び／又はプログラミング言語から生じるファイル形式などに対応する形式で入力されてもよい。
【００２１】
入力データは、データベース内に保存され、任意選択で供給されてもよい。
【００２２】
このシステムは、例えばフロー（又はプロセス）定義出力ファイルを作成し出力するための、例えばモニタ、プリンタなどの形の少なくとも１つの出力デバイスをさらに備える。本発明による出力デバイスは、本発明による特定の実施形態では、上記を作成及び出力するために、提供され、及び／又は、構成され、及び／又は、使用される。
【００２３】
フロー定義出力ファイルは、「＊．ｃｓｖ」（文字区切り値）形式のテキストファイルであってもよい。
【００２４】
フロー定義出力ファイルでは、プロセス開発者が理解でき、それに応じて任意選択により準備された必要なすべての詳細を好ましくは有する、すべての関連するフロー、及び／又は変更されるフロー、及び／又は新たに入力されるプロセス若しくはルーチンがリストされてもよい。
【００２５】
したがって、入力デバイスによって入力されたデータのチェックは、例えば入力誤りを防止し、又はより容易に突き止めるために、フロー定義出力ファイルを用いて明確に透過的に実施することができる。したがって、それは、プログラミングにおける誤り率の減少に有利に寄与する。
【００２６】
フロー定義出力ファイルは、これによって、モニタ上に提示することができるが、紙に出力することもできる。後者は、読みやすさを向上させ、したがって有利にはファイル又は定義されるプロセス内の誤りを見逃すリスク減少させるのに役立ち得る。さらに、他の任意の適切な再現方法も使用することができる。
【００２７】
システムは、少なくとも１つの変換デバイスをさらに備え、変換デバイスは、記憶媒体内に存在する少なくとも１つのマシン読取り可能ファイル又はマシン読取り可能データを、第１のプログラムセクション及び／又はパラメータセット及び／又はフロー定義出力ファイル、或いはそれぞれその中に表された入力データ（すなわち入力されたデータ）に基づいて作成するためのコンピュータ、コンピュータのデバイス及び／又はコンピュータプログラムであってもよい。変換デバイスは、本発明による特定の実施形態では、上記を作成するために、意図され、及び／又は、構成され、及び／又は、使用される。
【００２８】
別の（インターフェース）ソフトウェアが、変換デバイスで使用されてもよい。
【００２９】
変換デバイスによって、フロー定義出力ファイルは、例えばいわゆるヘッダファイル（「＊．ｈｐｐ」）に変換される。
【００３０】
変換が行われる変換先のファイルの形式は、コンパイラによって使用されるプログラミング言語で好ましくは処理されてもよい。例えば、これらは、Ｃ＋＋用の「＊．ｈｐｐ」ヘッダファイルであってもよい。
【００３１】
変換デバイスによって、マシン読取り可能ファイル、特に需要を満たしており、コードファイルとも呼ばれるマシン読取り可能ファイル、又はマシン読取り可能データが作成されてもよい。記憶媒体内のマシン読取り可能ファイル又はマシン読取り可能データ（直前に言及した２つの用語は、本発明では区別なく用いられる）は、これによって、１つの単一のファイルとして、接続され又は相互作用するファイルのグループとして、さらには少なくとも１つのサブファイルを備えた少なくとも１つのファイルとして理解することもできる。
【００３２】
本発明による変換は特に、フロー定義出力ファイル、又はフロー定義出力ファイル内に含まれたデータをマシン読取り可能フォームにする形式変換として理解されもよい。好ましくは、データベース又はフロー定義出力ファイルの情報以上のさらなる情報は、このプロセスでは現在も将来も追加、変換又は保存されない。特に、医療装置の操作に関連する情報は好ましくは、追加、変換又は保存されない。
【００３３】
本発明によるシステムは、上記に言及されたように、プロセス開発者のコンピュータ上で実行されてもよい。その結果（例えば生成されたヘッダファイル）は、コンパイラを使用して、デバイス及び対応するフロー追跡デバイスのオペレーティングプログラムと共に、例えば医療装置のメモリ内でファイルされ実行されるプログラムコードへと修正されてもよい。
【００３４】
本発明の有利な実施形態は、従属クレームの各主題である。
【００３５】
例えば、好ましい実施形態では、出力デバイスは、行と列とを有する少なくとも１つのスプレッドシートを備えたフロー定義出力ファイルの出力に適しており、そうするように準備されることが提案される。
【００３６】
こうした出力形式は、列、行、セル及びスプレッドシート領域のその構造化により、入力デバイスによって入力されたフロー定義の特に有益で明瞭な表現に適している。したがって、この表現は、入力誤りを見逃すリスクの減少に貢献する。
【００３７】
さらなる好ましい実施形態では、本発明によるシステムは、ユニットへとさらに分割されるフロー定義出力ファイルのスプレッドシートを出力する出力デバイスを備える。これによって、スプレッドシートは、１つの検出状況、配布リスト、プロセスブロック、システム状況ブロック及び反応ブロックを包含するグループからの少なくとも情報を備える。この情報は、それに応じて行及び／又は列に整えられてもよい。これによって、反応ブロックは、事前定義された情報を含んでもよく、この情報によって、例えば、操作される医療装置のアクチュエータがアラームによりアクティブ化されることになり、本発明によるシステム（クランプ、バルブ、ポンプの駆動など）がもたらされる。
【００３８】
ユニットはそれぞれ、所定の、又は動的に若しくは別のやり方で変化する数の列及び／又は行をカバーしてもよい。それぞれのセルはこれによって、例えば、状況が（１）を適用するか、そうでない（０）かに応じて、入力１又は０を有してもよい。これによって、入力された値のチェックが容易になる。本発明によれば、例えばマクロソフトエクセル（Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｅｌ）（登録商標）など、市販の表計算ソフトプログラムを使用してフロー定義出力ファイルを実行することが可能であり、この表計算ソフトプログラムでは、ワークシートのセルが、知られているやり方で列と行の形式の入力によって占有される。これによってすべてのユニットに重複する行はそれぞれ、プロセスオプション及びシステム状況の組合せ可能性により、考えられるフロー状況及びフロー反応のうちの１つを示し得る。
【００３９】
特に好ましい実施形態では、フロー定義出力ファイルは、アラーム定義スプレッドシート（略してＡＤＴ）を包含してもよい。表形式は、例えばアラーム状況などのフロー及びコヒーレンスを単純な直観的方法で示すことができる特に明確な表示形式である。
【００４０】
本発明による目的は、本発明によるシステムによって作成された記憶媒体内の少なくとも１つのマシン読取り可能ファイル或いはマシン読取り可能データを有する好ましくはデジタルのデータ媒体によっても遂行される。有利な実施形態又は開発は、やはり従属クレームの主題である。
【００４１】
さらなる好ましい実施形態で提案されるように、データ媒体は、本発明によるシステムによって作成された多数のマシン読取り可能ファイル又はマシン読取り可能データを備えてもよく、多数のマシン読取り可能ファイル又はマシン読取り可能データのセットからの少なくとも２つのファイルが互いに異なる。医療装置が、そのうちの少なくとも２つのＣＰＵが医療装置の操作中にそれぞれ異なる情報を必要とする多くのＣＰＵを備える場合、それぞれ異なるマシン読取り可能ファイルを提供することは、特に有用で有利である。
【００４２】
データ媒体はこれによって、共有のメモリ又はメモリデバイスであってもよい。データ媒体は、一時的に保存してもよいが、データ媒体は、永続的なメモリとすることもできる。データ媒体は、固定のメモリであってもよいし、主として可搬のデータメモリであってもよい。
【００４３】
本発明による目的は、特に、例えばＨＤ（ｈｅｍｏｄｉａｌｙｓｉｓ：血液透析）、ＨＤＦ（ｈｅｍｏｄｉａｆｉｌｔｒａｔｉｏｎ：血液濾過透析）、ＣＶＶＨ（Ｃｏｎｔｉｎｕｏｕｓ  Ｖｅｎｏｕｓ  Ｖｅｎｏｕｓ  Ｈｅｍｏｆｉｌｔｒａｔｉｏｎ：持続的静脈−静脈血液濾過）、ＣＶＶＨＤ（Ｃｏｎｔｉｎｕｏｕｓ  Ｖｅｎｏｕｓ  Ｖｅｎｏｕｓ  Ｈｅｍｏｄｉａｌｙｓｉｓ：持続的静脈−静脈血液透析）、ＣＶＶＨＤＦ（Ｃｏｎｔｉｎｕｏｕｓ  Ｖｅｎｏｕｓ  Ｖｅｎｏｕｓ  ＨｅｍｏＤｉａＦｉｌｔｒａｔｉｏｎ：持続的静脈−静脈血液透析濾過）又は他の治療法を実施するための透析装置として設計されてもよい請求項７の特徴を有する医療装置によってさらに遂行される。
【００４４】
医療装置の有利な実施形態又は開発は、やはり従属クレームの主題である。例えば、医療装置は、好ましい実施形態ではＲＯＭを備え、このＲＯＭでは、本発明によるシステムによって作成されたマシン読取り可能ファイル、又はこうしたファイルを備えるデータ媒体がファイルされ、又は保存される。さらなる好ましい実施形態では、医療装置は、フロー追跡装置を備える。やはりさらなる好ましい実施形態では、医療装置は、アラーム状況追跡装置又はアラームハンドラコードがファイルされるＲＯＭを備える。
【００４５】
さらに、本発明による目的は、請求項１２の特徴を有する方法、及び請求項１６〜１９の主題によって遂行される。この方法の有利な実施形態は、やはり従属クレームの主題である。
【００４６】
本発明によって（すなわちシステム、データ媒体、医療装置及びプロセスによって同様に）、フロー定義を集中的な方法で決定し、保存し、必要に応じて変更することが有利には可能である。例えばアラーム定義であってもよいフロー定義、すなわちアラーム状況の定義は、本発明によって、医療装置を操作するのに使用されたソフトウェアのソースコードから基本的には「抽出」されてもよい。これについて、供給が容易であるモジュール構造が提案され、このモジュール構造では、システム振舞いを示すのに必要なすべての情報が、１つの単一の位置で管理され、非プログラマ、例えばプロセス開発者によっても入力することができ、例えば制御目的のために確実に読み出すことができるフォームで示されてもよい。したがって、ファームウェアの認定又は承認は、入力された詳細及び構造の制御に、また任意選択でファームウェアの修正後のデバイス振舞いのランダムテストへと減少される。
【００４７】
本発明によるシステムの別の利点は、入力された修正又は補足の初期認定又は承認の後に、さらなる修正のための労力が、当技術分野の状況から知られた方法又はシステムと比べて著しく減少されるということである。そこで、承認の労力は、それぞれのさらなる修正と共に著しく増加する。
【００４８】
本発明によるシステムのさらなる利点、及びそれに基づく方法は、透明的で、容易なプログラミングである。これは、プロセス又はソースコード内の誤りの有効な減少、さらには防止につながる。
【００４９】
したがって、本発明に従って提案された手法は有利には、中央位置でシステム振舞いを示し、ソフトウェア開発者でない人にも「判読可能な」フォームでシステム振舞いを表すことに必要なすべての情報を管理することを可能にする。
【００５０】
したがって、本発明によれば、例えば透析装置など医療装置のファームウェア又はその一部の「再プログラミング」又は更新は、ほとんど労力を伴わずに、ほぼプログラミングスキルなしで確実に行われることができる。
【００５１】
下記では、本発明について、添付の図面を用いて例示的に詳細に説明される。図の説明では、図の説明のためだけに、下記に有効に定義される用語が用いられる。それは、下記の通りである。
【００５２】
ＡＣＧは、「拡張型コード発生器」、補助プログラムを表し、この補助プログラムは、ＡＤＴ（ＣＳＶ形式）のデータを、その後にコンパイラ又は変換デバイスによって読取り可能な内部形式に変換する。
【００５３】
ＡＤＴは、「アラーム定義スプレッドシート」を表す。これは、アラームの処理に必要なすべての情報がすべて含まれているＣＳＶ形式の少なくとも１つのファイルである。ＡＤＴは、前処理スプレッドシート、検出スプレッドシート及び関連性スプレッドシートへとさらに分割される。
【００５４】
「アラームハンドラ」又はアラームハンドラコードは、ファームウェアの一部を表し、アラームハンドラは、ＡＤＴから取得（及びＡＣＧで変換）された情報を処理して、ＡＤＴに定義された反応を開始するコードの一部を表す。
【００５５】
「ＡＷＩ」は、メッセージ（アラーム、警告、情報）の取扱いに関係するプレフィックスを表す。
【００５６】
「ＡＷＩ−ＩＤ」は、メッセージ割当て及び指定のための有限数を表す。
【００５７】
治療プロセスは、医療、例えばＣＶＶＨＤＦ、ＳＣＵＦ、ＨＤプロセス、ＨＤＦプロセスのフロー定義として理解される。ファームウェアでは、異なる治療プロセスを実施するオプションが、通常実装される。現在実施すべき治療プロセスは、ユーザによって決定される。
【００５８】
「コンパイラ」は、それぞれのマイクロプロセッサによって処理される（プログラミング言語で書かれた）ソースコードからバイナリコード（プログラムコード）を作成する市販のプログラムを表す。
【００５９】
ＣＰＵは、マイクロプロセッサの同意語であり、デバイス又は装置は、全体的なタスクを共有するいくつかのＣＰＵを含んでもよい。
【００６０】
「ＣＳＶ形式」は、「文字区切り値」、テキストベースの交換形式を表し、この交換形式は、電子データ処理の分野では一般的であり、例えばマイクロソフトエクセル（登録商標）を用いて構造化された方法で視覚化することができる。
【００６１】
「Ｅｎａｂｌｅ列」は、検出スプレッドシートの一部であり、Ｅｎａｂｌｅ列では、条件定義がこの行で開始するかどうか、又は前のスプレッドシート行とのＡＮＤ論理積が存在するかどうか判定される。
【００６２】
「検出スプレッドシート」では、（変数及び／又は定数の）値は、条件とリンクされ、又は条件に帰するものとされる。論理積の結果は、「検出状況」である。
【００６３】
「検出状況」は、ブール演算の比較結果を表す。検出状況は、基礎となる条件が満たされるかどうかに依存する論理状況（真又は偽）を表す。
【００６４】
「ファームウェア」は、コンパイラによってプログラムコードで実装されるすべてのモジュール（データモジュール及びプログラムモジュール）を包含する。デバイス内でいくつかのマイクロプロセッサが使用される場合又はとき、ファームウェアは、すべてのプロセッサのすべてのモジュールを包含する。
【００６５】
「デバイス状況」は、例えば「クランプ１が開いている」、「圧力Ａが＜ｖａｌｕｅ＞より大きい」など、１つ又は複数のデバイスコンポーネントの状況である。
【００６６】
Ｃ／Ｃ＋＋コンパイラの例を用いると、「内部形式」は、ヘッダファイル内のデータの構成（例えば「＊．Ｈ」や「＊．ＨＰＰ」）を意味する。
【００６７】
「プログラムコード」（バイナリコードでもある）は、デバイスのメモリ内にあり、対応するプロセッサによってデバイスの操作中に処理される。
【００６８】
「システム状況」は、治療プロセスの間、デバイスが「初期テスト」、「デバイステスト」、「設定」、「準備」、「充填」、「すすぎ」、「治療」、「誤り」、「スイッチオフ」など、様々な状況にあり得ることを知らせる。
【００６９】
「センサ値」は、関連するセンサ値の値を示す変数である。これらは、例えば圧力、電圧、フロー値などである。
【００７０】
「サブプロセス」は、治療プロセスの間の代替又はオプションの付加物又は補足物であると理解される。例えば、血液の抗凝固は、各プロセスの間に、サブプロセスの一例としてヘパリン化又はクエン酸塩／カルシウムの投与による補助を受けることがある。
【００７１】
「システム反応」は、特定のデバイス状況のデバイスの振舞いを定義する。システム反応は、コンポーネントベース（ポンプ、クランプなど）のものである。すべてのシステム反応全体が、基本的にシステムの振舞いである。
【００７２】
「システム振舞い」は、デバイスがどのように値及び状況を取り扱うべきか決定する。システム振舞いは、プログラミング（ファームウェア）によって実現化される。
【００７３】
「プロセス状況」は、いくつかのコンポーネントに関するデバイスの特別の状況であり、例えば、下記を定義することができる。
ＳＺ＿ｂｌｏｏｄ  血液システム停止
ＳＺ＿ｂａｌａｎｃｅ  平衡化停止
ＳＺ＿ＦＰＳＡ  ＦＰＳＡ停止
ＳＺ＿ＣｉＣａ  ＣｉＣａ停止
ＳＺ＿ｈｅｐａｒｉｎ  ヘパリン停止
ＳＺ＿ＰａｔＤｉｓｃｏｎｎ  患者分離。
【００７４】
用語「前処理スプレッドシート」は、ＡＤＴの小区分を表し、個々のセンサ値及び状態値が前処理されるかどうか、またどのように前処理されるか定義する。
【００７５】
前処理は、例えばアーティファクトのための算術平均、検出アルゴリズム及び消去アルゴリズムなどである。
【００７６】
図面では、同じ参照符号は、同じ又は同一の構造を指す。それは、下記の通りである。
【図面の簡単な説明】
【００７７】
【図１】本発明による医療装置との対話における、本発明によるシステムの概略的構成を示す図である。
【図２】結果が陽性のとき又は場合、対応して事前定義された医療装置の反応を開始するために本発明による関連性を評価することの一例を示す図である。
【図３】処理の際の本発明によるデータ構造及びプログラムの構造をフローチャートの形で示す図である。
【図４】前処理のパラメータを有する本発明によるスプレッドシートを再現する図である。
【図５ａ】本発明による検出スプレッドシートを再現する図である。
【図５ｂ】本発明による検出スプレッドシートを再現する図である。
【図６ａ】本発明による関連性スプレッドシートを再現する図である。
【図６ｂ】本発明による関連性スプレッドシートを再現する図である。
【図６ｃ】本発明による関連性スプレッドシートを再現する図である。
【図６ｄ】本発明による関連性スプレッドシートを再現する図である。
【図６ｅ】本発明による関連性スプレッドシートを再現する図である。
【図６ｆ】本発明による関連性スプレッドシートを再現する図である。
【発明を実施するための形態】
【００７８】
図１は、本発明よるシステム１０、並びに図１の例では透析装置として具現化される医療装置５０の部分を示している。これによって、システム１０は、医療装置５０の外部に構成され、医療装置５０とは独立している。例えばプロセス開発者の外部コンピュータ上に存在するシステム１０は、とりわけ、医療装置５０の操作に関連するデータを保存／格納及び管理するためのＳＱＬデータベース１２を備える。
【００７９】
システム１０内への、特にデータベース１２内へのファイルの入出力は、別個のツール、すなわち入力デバイス１４によって行われ、入力デバイス１４は、図１の例では、同時に出力デバイス１６として使用される。このツールは、実際に下記のケースのように、システムがアラームを決定する働きをするケースでは、アラームデータベースインターフェース（ＡＤＩ：Ａｌａｒｍ  Ｄａｔａｂａｓｅ  Ｉｎｔｅｒｆａｃｅ）として示すことができる。ツール１４、１６では、ソフトウェア開発者とプロセス開発者の両方によって使用されるフォームシートが、入力のために使用される。フォームシート又はテンプレートによる入力は有利には、デバイスの反応への修正が望まれる場合、例えばマシンがアラームを聴覚的にだけではなく、さらに光学的にも示すべきアラームである場合、ソフトウェアエンジニアは、新しいソースコードをもはや策定する必要はないが、プロセス開発者１８は、関連する入力を行い、したがって入力デバイス１４の入力フォームによって別個の作業場のマシンの新しいアラーム振舞いを定義又は指定しなければならない。
【００８０】
すべての検出状況、又は修正に必要なすべてのデータが入力される場合、出力デバイス又はＡＤＩツール１６は、図１の例ではスプレッドシートのフォームのテキストファイル（＊．ｃｓｖ）、いわゆる「アラーム定義スプレッドシート」すなわちＡＤＴ  ２０であるフロー定義出力ファイルを生成する。このフロー定義出力ファイル又はＡＤＴ  ２０では、すべての関連した、又はさらに考えられるアラーム状況及びアラーム反応が、表形式でリストされる。このフォームでは、入力されたデータは、チェックすべき上述の又は異なる開発チーム１８にとって容易なものである。これは、例えば紙レビューによって実施されてもよい。フロー定義出力ファイル２０の変更が必要であるならば、それらは、入力デバイス１４の入力フォームによって、ＳＱＬデータベース１２内に再びファイルされ、簡略化され、表形式のテキストファイルとして出力される。
【００８１】
これによって、任意の数のレビューステップを実施することができる。しかし、前バージョンと比較して変更だけをチェックしなければならない何れかの場合と同様に、追加のフロー定義又は、それに応じて変更されたアラーム振舞いのためのアラーム定義及び命令を、多くの労力なしに追加することができる。
【００８２】
フロー振舞い又はアラーム振舞いがテキストファイルに最後に記述又はファイルされ、承認又はチェックされる場合又はとき、フロー定義出力ファイル又はＡＤＴ  ２０は、図１の例ではいわゆるアラームコード発生器（略してＡＣＧ）として具現化される変換デバイス２２によって、図１ではいわゆるヘッダファイル（＊．ｈｐｐ）として具現化される、記憶媒体内に存在するマシン読取り可能ファイル又はデータ５２、５４へと変換される。
【００８３】
図１に示された医療装置５０の部分では、アラームハンドラコード５６の形のフロー追跡デバイスが提供され、このアラームハンドラコード５６によって、一般的に言うと保存されたマシン読取り可能データでもあり得るマシン読取り可能ファイル５２及び５４が、読取り可能になる。
【００８４】
変換デバイス２２によって、医療装置のそれぞれ異なるＣＰＵが考慮に入れられてもよい。すなわち、同一の構造のマシン読取り可能コードが常に生成されるが、マシン読取り可能コードは、医療装置５０の様々なＣＰＵのそれぞれ異なる機能及び要件に個々に適応される。例えば、モニタ５８の操作ＣＰＵは、プロセス制御の保護ＣＰＵ  ６４が、例えば静脈クランプを閉じるために受け取る情報を正確に受け取る必要はない。マシン読取り可能ファイル５２、５４内に存在する変換された、又はコンパイルされたコードは、医療装置５０の生産中に、例えば納入される医療装置５０のＲＯＭメモリ内に焼き付けられてもよく、したがって変更不可能である。しかし、マシン読取り可能ファイル５２及び５４は、医療装置５０をユーザに納入した後、更新の一部として後に治療装置５０に後に組み込むこともできる。フロー定義を処理するための命令は、アラームハンドラコード５６内の同一の各ＣＰＵ上にある。
【００８５】
したがって、プロセスのフローに使用されたすべてのデータは、治療装置５０のＲＯＭ内に保存される。フロー定義出力ファイル２０のマシン読取り可能コンテンツ、並びにこれらのデータをどのように取り扱うべきかについての命令もまた、ＲＯＭ内にある。これらの固定されたデータは、調整値、センサ値、環境パラメータなど、フロー及び監視からの動的に生成され、変更可能なデータで補われる。これらの変更可能な値は、フロー追跡デバイス５６に作用する。
【００８６】
ここではさらには論じられない上記に名前が挙げられた、さらなるコンポーネントに加えて、図１の治療装置５０は、とりわけ、治療法が行われる治療装置５０の治療セクション５９のための第１の操作システム６０と、モニタ５８のための第２の操作システム６２とを備える。治療装置５０は、治療装置５０の治療セクション５９のための第１の保護システム６４と、モニタ５８のための第２の保護システム６６とをさらに備える。治療装置５０の保存又は格納プロセスフロー又は操作フローのための第１のデバイス６８、及びモニタ５８のための第２の同様のデバイス７０は、それぞれ二重に存在している。治療装置５０は、セキュリティのため、必須の構成要素が二重になっている。図１の例では、治療装置５０は、４つのＣＰＵを備え、そのうちの２つは、医療プロセスの操作のため（１つのＣＰＵは操作システム用、もう一方は保護システム用）に提供されており、それとは別に２つの他のＣＰＵが、治療プロセスへの遡及効果をもたない表示領域（モニタ５８）のために提供される。
【００８７】
図１の例は、アラーム状況の決定を目的とする。しかし、本発明は、これに限定されないが、医療装置の任意のフロー及びプロセスを目的としてもよい。
【００８８】
図２は、永続的センサ監視の例を用いて、結果が陽性の場合に、対応して事前に定義された医療装置の反応を開始するために関連性を評価することを示している。センサによって測定された値の上限（例えば動脈圧ウィンドウの上限）に達する場合又はとき、これはアラームをまだ必要としないが、検出状況を表すにすぎない。次に、この検出された状況が関連性があるか、したがってアラームを与えるべきかどうか決定される。フロー追跡装置５６（図２の例では、アラーム状況追跡デバイス又はアラームハンドラコードであり、以下、アラーム状況などとも呼ばれる）は、１行ずつ、図２に示されたアラーム定義スプレッドシートの内容を永続的に読み出し、列「割り当てられた検出状況」８１Ｘ内に、定義された検出状況８１への参照を受け取り、この定義された検出状況８１は、例えば７３又は７３Ａで参照されるように、動脈圧の上限域を超えたことを表す。割り当てられた検出状況の実際の状況８１Ｙ（現在のデバイス状況）は、行の関連性を定義する。「１」は、行を編集しなければならないことを意味する。簡略化された用語、１行ずつの処理は、３つのブロック、すなわちプロセスブロック７７、システム状況ブロック７９、及び図２に示されていない反応ブロックを通過する。
【００８９】
図２に示された例では、すべての検出状況が、第１の列８１によって簡略化された方法で示された図２にある第１のブロック内に表されている。したがって、図２の各行の第１の列では、検出状況が再現されており、その各１つは、例えば「血液ポンプ停止」、「動脈圧の限界ウィンドウの逸脱」、「血液ポンプ回転せず」又は「動脈圧の限界域の逸脱」などと呼ばれた、一般に理解できるプレーンテキストである。
【００９０】
定義された検出状況８１は、列「割り当てられた検出状況」８１Ｘのいくつかの行７３Ａにリストされてもよく、任意のプロセス、及び任意のシステム状況に関連する。
【００９１】
プロセスブロック７７は、いくつかの列を包含し、列Ｖ１，…，Ｖｘの医療デバイスの考えられるすべてのプロセス又はサブプロセスを示す。したがって、プロセスブロック７７の１つの列は、それぞれの知られている、又は可能な治療法に割り当てられる。そのセル内で、検出状況が列の各プロセスに関連しているか（「１」）、それとも関連しないか（「０」）に応じて「１」又は「０」の入力が行われる。アラームハンドラコードは、行を入力した場合又はとき、例えば「単一針のプロセス」又は「ＨＤプロセス」を表すプロセスＶ１については「０」を、またプロセスＶ４及びＶ５それぞれに「１」を検出する。したがって、検出状況は、２つのプロセスにおいて関連性がある。しかし、アラームハンドラコードは、医療装置が現在どのプロセス又は治療にあるかの情報を必要とする。アラームハンドラコードは、フロー又はプロセス監視からの動的なデータによってこの情報を受け取る。これらは、治療装置の現状状況を再現する。結果は、図２のスプレッドシートの最上行、行７１に「０」又は「１」としてリストされる。したがって、図２の例では、Ｖ４に一貫性があり、Ｖ５には一貫性がない。しかし、既に１つの単一の一貫性が関連しているので、アラームハンドラコードは、その行を右へとさらに通過する。
【００９２】
アラームハンドラコード又はアラームハンドラは、次にシステム状況ブロック７９に進む。そこで、「ファイル」、「治療」、「格下げ」などの医療プロセスのすべての可能なシステム状況、又はすべての可能な若しくは関連する時間相が、行に記録される。上記のプロセスブロック７７と同様に、状況又は状況組合せの可能性は、「０」及び「１」でマーキングされる。したがって、図２の例では、システム状況Ｓ１及びＳ５は関連性があることがあり、現在のシステム状況の動的なデータについて考慮すると、Ｓ１との一致、したがって関連状況だけが存在する。プロセスブロック７７及びシステム状況ブロック７９の関連性の評価の結果は、それぞれ「１」である。したがって、全体的又は一般的な関連性が与えられる。系統的にスプレッドシートはこの場合では、右に同一の構造を有しており、次いで、すべてのさらなるシステム反応が、そこにリストされる。単に図を単純にするために、これは図２に示されていない。
【００９３】
１行ずつの処理の間、行内のある点で、関連性がないと判定される場合、この行の残りの部分はスキップされ、スプレッドシート又は配布リストの次の行が同じ方法で処理される。
【００９４】
したがって、医療装置のＲＯＭ内にソフトウェアとしてファイルされてもよいアラームハンドラコードのタスクは、アラーム定義スプレッドシートのブール演算子の非常に単純で、標準化された処理に限定される。このために、アラームハンドラコードは有利には、正確さのチェック又は承認が容易であり、また他の多くの場所でも同じ方法で使用可能である。
【００９５】
本発明によれば、フロー定義出力ファイルに表形式を使用する場合、医療装置の追加の状況又は反応を定義することが容易に可能となる。これは、それぞれのユニットにさらなる列及び／又は行を含めることだけを必要とする。こうした包含は、入力デバイスによって、自動化された方法で行うことができる。
【００９６】
フロー定義出力ファイル用のスプレッドシートは、セルをさらに備えることもでき、このセルは、関連する医療装置の操作の間、フロー監視に基づいて動的にカバーされ、その操作の間に医療装置の実際の状況を再現する。
【００９７】
１つの定義スプレッドシート（ＡＤＴ＝アラーム定義スプレッドシート）内のすべての情報の組合せは、とりわけ以下の利点をもつ。
・システム振舞いに関連するすべての情報が、集中化される。
・情報は、ソフトウェア開発者でない人々にとっても判読可能なフォームで存在する（特定のプログラミング言語の特別のノウハウは必要ない）。
・システム振舞いの実現化について、コードの一部だけが、ファームウェア（アラームハンドラとも呼ばれる）用に生成され、このファームウェアは、情報に目を通し、評価し、関連する反応を開始する。
・スプレッドシート情報を、アラームハンドラが処理できるフォームに変換することは、変換プログラム又は変換デバイス（ＡＣＧ＝拡張型コード発生器）で実行され、自動化された実装物により、誤りは最小限に抑えられる。
・システム振舞いの仕様の変更は、スプレッドシート情報の修正を通じて排他的に行われる（あり得る例外：新しい「特徴」がスプレッドシートに組み込まれ、次いで、アラームハンドラの修正も必要となる）。
・追加又は修正が、他のファームウェアのフローを損なわずに単純な方法で行われてもよい。
・スプレッドシートは同時に、ドキュメンテーションを表し、ドキュメンテーションを別に生成又は供給する必要はもはやない。
【００９８】
図３は、本発明による方法でアラーム状況を決定する例を用いて、プロセスフロー内のデータ構造及びプログラム構造をフローチャートの形で示す図である。図３の矩形領域は、データオブジェクトを表し、楕円領域は、プログラムを及びプログラム部分を表している。アラーム定義スプレッドシートＡＤＴ  ２０（ＣＳＶ形式）は、入力デバイス並びに出力デバイス（それぞれ参照符号１４、１６）として、例えばマイクロソフトエクセル（登録商標）、（若しくは比較可能なスプレッドシート計算プログラム）又は単純なテキストエディタなどを用いて処理される。その後、アラーム定義スプレッドシートＡＤＴ  ２０は、ツールＡＣＧで、使用されたコンパイラ又は変換コードに使用可能なフォーム「内部形式」に変換される。コンパイラ又は変換コードは、アラームハンドラ５６及び残りのデバイスプログラムのコード部分と共に、ＡＤＴ  ２０のデータから実際のマシン読取り可能プログラムコードを生成する。
【００９９】
フロー定義出力ファイルの情報は、３つのテーブル、「前処理」、「検出」、「関連性」に保存される。
【０１００】
図４に示されたものなど、前処理の間に、「生の測定値」が、平均化、スケーリング、フィルタリングなど数学的変換を経るかどうか、また恐らく生の測定値が、どの数学的変換を経るか決定される。さらなるフィルタリング方法として、例えば平均、多項式の計算などが考えられる。
【０１０１】
第１の列ブロック（「ＣＰＵ」）では、前処理を行うべきマイクロプロセッサがマーキングされる。第２の列ブロック（「前処理パラメータ（複数可）」）では、どのタイプのどの生データ（変数）がどの方法で数学的に変換されるか決定される。上記の例では、生の圧力「Ｐｒｅｓｓｕｒｅ＿ＰＳ＿０１＿ＣａｌｃＶａｌｕｅ」（圧力センサＰＳ１のセンサ値）が、次元６の中間フィルタを通して送られる。出力値として、既にその名前にある使用されたフィルタについての情報を含む変数「Ｐｒｅｓｓｕｒｅ＿ＰＳ＿０１＿ＣａｌｃＶａｌｕｅ＿ＡＶＧＡ＿６」が定義される。出力変数は、数式を提供することによってツールチェーンによって自動的に生成されるが、出力変数は、手動で上書きすることもできる。自動生成は、二重入力によって同一の変数名が生成され、最終変換プロセス又は最後のコンパイルプロセスの間にエラーメッセージがもたらされるという利点を有する。
【０１０２】
図５ａ及び図５ｂに示されたようにスプレッドシート「検出」では、値は、結果として論理値（ｙｅｓ／ｎｏ、真／偽）を受け取るために条件にリンクされる。結果として生じる論理値は、検出状況と呼ばれる。論理値は、デバイス又はコンポーネントの現在の状況、例えば「クランプＡが開いている」又は「圧力Ｂが限界値より高い」と表す。
【０１０３】
（また前処理スプレッドシートとしての）検出スプレッドシートは、完全に循環され、すなわち各実行の後、検出状況において現在値が使用可能である。
【０１０４】
１行ごとに、比較操作が行われてもよい。典型的な操作は、「ＥＱ」（等しい）、「ＬＴ」（より小さい）、「ＧＴ」（より大きい）であるが、「ＤＧＴ」（より大きい差）もある。例えばいくつかのスプレッドシート行を連続して接続することによって、より複雑な複合条件が実現される。これは、論理「ＡＮＤ」論理積をもたらす。「ＯＲ」論理積は、別個のスプレッドシート行によって実現される。
【０１０５】
これについて、まず一般的に説明される。具体的な例は、より後に下記に説明される。
【０１０６】
図５ａのスプレッドシートでは、それぞれの行はこの場合も、ターゲットＣＰＵの表示から開始する。
【０１０７】
その後、ＡＮＤ論理積に使用されるｅｎａｂｌｅ列が続く。ここで、行に「１」がある場合、条件定義が開始する行である。
【０１０８】
その後に、変数名、比較操作及び第２の値からなる条件の指定が行われる。この第２の値は、やはり変数であってもよいし、定数（リテラル）であってもよい。
【０１０９】
次いで、定式化された条件の結果は、（変数として実現化された）指定された検出状況でファイルされる。検出状態変数の識別は、前処理の間と同様に自動的に行われ、これによって明確な仕様が生成される。
【０１１０】
具体的な例では、これは、以下のようになることがあり、例は、圧力監視の抜粋である。第２列では、変数「Ｔ０＿Ｐａｒｔ＿ＵｓｅｒＬｏｗｅｒＴｈｒｅｓｈｏｌｄＩｎａｃｔｉｖｅ＿Ｃｏｕｎｔｅｒ」の値（一定時間の間、圧力ウィンドウを非アクティブ化する働きをする）が、０に等しいかどうかチェックされる。結果は、検出状況「Ｔ０＿Ｐａｒｔ＿ＵｓｅｒＬｏｗｅｒＴｈｒｅｓｈｏｌｄＩｎａｃｔｉｖｅ＿Ｃｏｕｎｔｅｒ＿ＥＱ０」でファイルされる。検出状況は、動脈圧を非アクティブ化するための時間メータが０までカウントダウンしたとき、値「ｙｅｓ」となる。上記の例の行８では、この検出状況は、Ｅｎａｂｌｅとして、すなわちＡＮＤ論理積の生成のために使用される。ＡＮＤ論理積の第２の部分で、前処理「Ｐｒｅｓｓｕｒｅ＿ＰＳ＿０１＿ＣａｌｃＶａｌｕｅ＿ＡＶＧＡ＿６」から知られた平均された圧力が、変数「ＣＰＵ１＿ＵＳＥＲ＿Ｐｒｅｓｓｕｒｅ＿Ａｒｔ＿ＬｏｗｅｒＷｉｎｄｏｗＬｉｍｉｔ」（すなわちユーザによって設定された値）の値より小さい（ＬＴ）かどうかについてチェックされる。次いで、全面的な条件の論理結果が、検出状況「Ｔ０＿Ｐａｒｔ＿ＵｓｅｒＬｏｗｅｒＴｈｒｅｓｈｏｌｄＩｎａｃｔｉｖｅ＿Ｃｏｕｎｔｅｒ＿ＥＱ０＿Ｐｒｅｓｓｕｒｅ＿ＰＳ＿０１＿ＣａｌｃＶａｌｕｅ＿ＡＶＧＡ＿６＿ＬＴ＿ＣＰＵ１＿ＵＳＥＲ＿Ｐｒｅｓｓｕｒｅ＿Ａｒｔ＿ＬｏｗｅｒＷｉｎｄｏｗＬｉｍｉｔ」でファイルされる。
【０１１１】
このように、散文で定式化された条件「デッドタイムが終了して、動脈圧が、ユーザにより設定された下限より低くなると」が、検出スプレッドシート内に表される。明らかに、これには特別のプログラミングスキルは必要ない。
【０１１２】
同じように、列１３、１４に示された条件は、「圧力ブロック１を開始すべきであるが、使用可能な圧力が１２０［ｍｍＨｇ］より大きい場合には、．．．」＜さもなければチューブシステムが損傷を受けるので、これを防止しなければならない＞と解釈することができる。ここでは情報として追加されたこの結果は、検出スプレッドシートの一部ではないが、図６ａ〜図６ｆの下記の関連性スプレッドシートで再現されてもよい。
【０１１３】
ここまでの２ステップで、生データが前処理され、デバイス状態が（複雑）条件によって検出される。このステップ「関連性」（図６ａ〜図６ｆ参照）で、これらの状況の評価及び各々の「ｔｈｅｎ」アクションの定式化が行われる。
【０１１４】
基礎となる概念によれば、アラームハンドラは、ファームウェアの実行時間の間、１行ごとに関連性スプレッドシート行の内容をチェックする。これによって、定義された条件が有効な限り、チェックが行われるにすぎない。例えば、治療プロセスＨＤプロセスがアクティブであるが、列ＨＤプロセス内の処理された行がマーキングされない場合、行の処理はこの時点で中断され、次の行で継続される。
【０１１５】
行内のすべての条件が完全に（かつ肯定的に）処理される場合又はとき、アラームハンドラは、その後、システム反応につながる入力に進む。ここで、定義された条件によりどのアクションを行わなければならないか決定される。
【０１１６】
図６ａ〜図６ｆの関連性スプレッドシートの構造について、下記に例を用いて説明される。
【０１１７】
図６ａでは、システム反応を開始すべきＣＰＵがこの場合も、最初に決定される。後に、図５ａ、図５ｂの検出スプレッドシートから得られる検出状況が定義される。
【０１１８】
図６ｂの次の３つの列ユニットでは、現在の治療プロセス、現在のサブプロセスについて、又は現在のシステム状況で、この検出状況を考慮すべきか（すなわち関連するか）どうか定義される。
【０１１９】
図に名前が挙げられた例示的なプロセスは、「ＨＤプロセス」から「ＨＤＦプロセス」を通って「プロセスＸ」まであるが、しかし、プロセスの実際の範囲は、本発明に従って変更可能であり、「Ｃｏｒａｆｆｉｎ」、「ＳＣＵＦ」などプロセスも包含してもよい。列に「１」が入力される場合、及び現在選ばれている治療プロセスが、この列で名前が挙げられたプロセスに一致する場合は、この行で定義された検出状況は、アラームハンドラによってさらに考慮される。それぞれのセルがマーキングされない場合、アラームハンドラは、この行が現在のプロセスに関連しないので、この行の評価を中断してもよい。
【０１２０】
サブプロセス（例えば抗凝血ヘパリン、ＣｉＣａ及びＦＰＳＡ）について、拡張された定義が適用され、それぞれの列に「１」が入力される場合は、この行は、アクティブなサブプロセスに関連する。しかし、「ｘ」が入力される場合は、この行は、それぞれのサブプロセスがアクティブかどうかに関係なく、関連性がある。入力なし（又は「０」）は、この行が、所与のサブプロセスに関連しないことを意味する。
【０１２１】
プログラム状況（システム状況とも呼ばれる）の評価は、同じように行われる。図６ｂのスプレッドシートでは、定義された各プログラム状況ごとに列が存在する。これらは代表的には、列「デバイス開始」から「停止」である。本発明によるスプレッドシートベースのアラーム取扱いについては、この場合も、プログラム状況の意味も数も重要ではない。しかし、医療装置が現在どのシステム状況にあるかについて区別することが重要である。それぞれの行／列組合せで「１」は、現在のプログラム状況が、列内に名前が挙げられたものに一致するとき又は場合は、定義された行が関連性があることを意味する。
【０１２２】
これは、スプレッドシートによってサポートされた定義の利点のうちの１つを再び示している。例えば別の方法について、（検出スプレッドシートに定義されており、検出状況をもたらす）監視をアクティブ化すべき場合、行列の単純な入力で十分である。（例えば、圧力検出が「治療」だけでなく「すすぎ」でもアクティブになるべきとき）同じことがプログラム状況にも当てはまる。追加のアクティブ化だけが行われるとき、ファームウェアの他のプログラム部分に関する反応がないことも保証され得るが、既存のアクティブ化はこれによって変更されない。
【０１２３】
図６ｂの次の２つの列ユニットは、例外を表している。列「プロセス状況に関連しない」では、反応が行われないままであるべきかどうか定義されてもよい。システムが定義された安全な状況（例えばＳＺ＿ｂｌｏｏｄ）に既にある場合、例えば圧力問題は、安全な状況が既に達成されているので、無視されたままであってもよい。これらの列は、複数のシステム反応及び誤解しやすい後のメッセージを防止する働きをしてもよい。次の列ブロック「プロセス状況の後、当面、関連しない」では、例えばプロセス状況「ＳＺ＿ｂｌｏｏｄ」の後、例えばこの期間にシステムがまず安定しなければならないので、特定の検出状況について一定時間の間、考慮すべきでないと決定される。したがって、基本的にこれらの列は、停止されたプロセスのこの再開の間、監視を一時的に少し「より寛容に」するために使用される。
【０１２４】
図６ｂの最後のブロックは、「ＡＷＩパラメータ」を包含し、「優先度」は、この行にリンクされたメッセージの重要性を指定する。この行にリンクされたシステム反応は優先順位付けされず、どんな場合も実行される。
【０１２５】
さらに、関連性スプレッドシートの行は、グループへとさらに分割することができる。したがって、アクティブであり、同じグループに割り当てられ、同じ又は低い優先度を有するすべてのさらなるスプレッドシート行は、ユーザによって確認されるメッセージによって同時に自動的に確認することができる。一般に、この情報は、後のアラームの取扱いのためにも使用される。
【０１２６】
最後の列、システム変更許可状況は、関連すると検出された行でシステム状況を変更することが許されるかどうか定義する。何らかの点で、このデバイス振舞いを阻止することが有用である。これは、例えばスプレッドシート行で、それによればフィルタが完全には充填されない検出状況が定義されるときのケースであり得る。この条件が与えられる限り、装置は、充填を終了することができない。
【０１２７】
図６ｃ、図６ｄ及び図６ｅの列は、表示反応又はユーザへのインターフェースの詳細な仕様を表している。メッセージテキスト、画面上の色及び形式、光信号、音響反射、ナースコールなどが含まれる。
【０１２８】
図６ｄ及び図６ｅで、画面のメッセージ例について述べられる。これによって、下記の通りである。
・ＡＷＩテキストＩＤ  メッセージテキストを定義する有限数であり、実際のテキストは、この数を有するリストから得られる。
・ＡＷＩテキストインデックス  ＡＷＩテキストＩＤの複製であってもよい。
・埋込みアラームオブジェクト  メッセージウィンドウ内にある。追加のオブジェクトが、テキストに加えて示される。例：圧力アラームが発行されるとき、アラームの重要性をさらに強調すべき注意記号が、メッセージウィンドウに埋め込まれる。
・テキストパラメータ１〜５  メッセージテキストは、メッセージテキストへの現在値の埋込みのためのフォーマッティングを含んでもよい。例：「圧力が＜ｐ１＞ｍｍＨｇを超過」。この点で、テキストパラメータ１の値が表示される。現在、最大５つの使用可能なパラメータがある。変数の名前が入力される。
・ヘルプテキストＩＤ  ヘルプテキストを定義する明示的な数であり、実際のテキストは、この数を有するリストから得られ、また定義されないこともあり、この場合、このメッセージに役立たない。
・補助ピクチャ  ヘルプウィンドウ内にある。ここで指定されるグラフ又は図が、任意選択でテキストに加えて示されてもよい。
・フレーム色  メッセージウィンドウが指定された色で描かれる。オプションは、灰色、黄色、赤色である。さらなる色及び／又はフレームプロパティの特性の追加が、本発明によって可能である。
・音響信号  このメッセージが現れるとき、どのオーディオ信号が生成されるか決定する。
・光信号  このメッセージが現れるとき、ライトがどの色／色組合せを示すか決定する。
・ナースコール  このメッセージが現れるとき、ナースコールをアクティブ化しなければならないかどうか判定する。
・応答オプション位置  メッセージウィンドウ内に確認キーがどの順序で現れるか決定し、ここでは、中心揃え、左揃え、右揃え、距離などのようなオプションがある。
・応答オプション１  デバイス内で第１の確認キーが押下されるときにトリガされる信号
・応答オプション１テキストＩＤ  第１の確認キーのラベル
・応答オプション２  上記参照
・応答オプション２テキストＩＤ  上記参照
・応答オプション３  上記参照
・応答オプション３テキストＩＤ  上記参照
・表示はモーダルである  表示オプション；表示に、画面上の他のオブジェクトが重なり合うことがある。
【０１２９】
見出しメッセージテキストを有する図６ｆの次の列ブロックは、最初に４つの列から開始し、この４つの列は、本出願人による開発目的のためだけに使用され、実際には、メッセージ定義の「ミニコピー」を含む。次の列ブロックは、システム反応を含む。次のコンポーネントベースのシステム反応が、例示的に定義される。
・ＳＲ＿ＡｒｔＣｌａｍｐＣｌｏｓｅｄ  動脈クランプを閉じる。
・ＳＲ＿ＶｅｎＣｌａｍｐＣｌｏｓｅｄ  静脈クランプを閉じる。
・ＳＲ＿ＶｅｎＣｌａｍｐＯｐｅｎｅｄ  静脈クランプを開く（例えば圧力解放）。
・ＳＲ＿ＢｌｏｏｄＰｕｍｐＳｔｏｐ  血液ポンプを止める。
【０１３０】
以下のシステム反応など、さらなるコンポーネントベースのシステム反応、並びにさらなるシステム反応がこの場合も、もちろん定義されてもよい。
・ＳＲ＿ＤｉａｌｙｓａｔｅＰｕｍｐＳｔｏｐ  透析液ポンプを止める。
・ＳＲ＿ＳｕｂｓｔｉｔｕａｔｅＰｕｍｐＳｔｏｐ  代替ポンプを止める。
・ＳＲ＿ＦｉｌｔｒａｔｅＰｕｍｐＳｔｏｐ  濾過水ポンプを止める。
・ＳＲ＿ＦＰＳＡＣｌａｍｐＣｌｏｓｅｄ  ＦＰＳＡクランプを閉じる。
・ＳＲ＿ＦＰＳＡＣｌａｍｐＯｐｅｎｅｄ  ＦＰＳＡクランプを開く。
・ＳＲ＿ＦＰＳＡＰｕｍｐＳｔｏｐ  ＦＰＳＡポンプを止める。
・ＳＲ＿ＨｅａｔｉｎｇＯｆｆ  ヒータ（複数可）のスイッチを切る。
・ＳＲ＿ＣｉＰｕｍｐＳｔｏｐ  クエン酸塩ポンプを止める。
・ＳＲ＿ＣａＰｕｍｐＳｔｏｐ  カルシウムポンプを止める。
・ＳＲ＿ＨｅｐＰｕｍｐＳｔｏｐ  ヘパリンポンプを止める。
・ＳＲ＿２４Ｖ＿Ｏｆｆ  ２４Ｖの電源を切る（非常スイッチオフ）。
・ＳＲ＿ＰｏｗｅｒＯｆｆ  全体のスイッチを切る（さらなる非常スイッチオフ）。
・ＳＲ＿ＰＧＭ＿Ｅｒｒｏｒ  エラー状況への遷移、治療の継続は不可能である。
【０１３１】
アラーム取扱いの実施については、これによって、どの特別のシステム反応が定義されるかは関連性がない。これは、デバイスの構成要素の機器又は治療法のタイプに応じて行われる。何らかの方法で治療法に影響を及ぼし得るすべてのアクチュエータがリストされ、システム反応と共に考慮に入れられることがかなり重要である。
【０１３２】
図６ｂの上記の議論で、プロセス状況に関する例外は、既に指摘されている。次の列ブロック「Ｓ／Ｒクラス」内で、まさにこのプロセス状況が定義され、すなわち、プロセス状況は、コンポーネントベースの単一のシステム反応となり、次いで、このシステム反応は、さらなる関連性の評価のために使用される。最後の列ブロックは、生成されたメッセージの削除をもたらし得るオプションを含む。
【０１３３】
自動削除メッセージでは、メッセージは、検出状況が「偽」に変化するとき削除される。自動削除システム反応では、開始されたシステム反応は、検出状況が「偽」に変化するとき逆にされる。「ＯＫ」の後のデッドタイムによって、メッセージが「ＯＫ」で確認されるとき、どのくらいの間、検出状況を考慮に入れないか指定することができる。「無視」の後のデッドタイムによって、メッセージが「無視」で確認されるとき、どのくらいの間、検出状況が非アクティブ化されるか指定することができる。
【図１】
2012524922.tif 000003
【図２】
2012524922.tif 000004
【図３】
2012524922.tif 000005
【図４】
2012524922.tif 000006
【図５ａ】
2012524922.tif 000007
【図５ｂ】
2012524922.tif 000008
【図６ａ】
2012524922.tif 000009
【図６ｂ】
2012524922.tif 000010
【図６ｃ】
2012524922.tif 000011
【図６ｄ】
2012524922.tif 000012
【図６ｅ】
2012524922.tif 000013
【図６ｆ】
2012524922.tif 000014
【国際調査報告】
2012524922.tif 000015
2012524922.tif 000016
2012524922.tif 000017
2012524922.tif 000018