JP2001525940A - System and method for monitoring and analyzing the operation of a medical processing device - Google Patents

System and method for monitoring and analyzing the operation of a medical processing device

Info

Publication number
JP2001525940A
JP2001525940A JP54583299A JP54583299A JP2001525940A JP 2001525940 A JP2001525940 A JP 2001525940A JP 54583299 A JP54583299 A JP 54583299A JP 54583299 A JP54583299 A JP 54583299A JP 2001525940 A JP2001525940 A JP 2001525940A
Authority
JP
Japan
Prior art keywords
data
file
hardware
interface
task
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP54583299A
Other languages
Japanese (ja)
Inventor
エイチ． コルク，ウィリアム
ウェバー，マーク
ケッコウスキー，ダグラス
モロウ，デイビッド
Original Assignee
バクスター インターナショナル インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by バクスター インターナショナル インコーポレイテッド filed Critical バクスター インターナショナル インコーポレイテッド
Publication of JP2001525940A publication Critical patent/JP2001525940A/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q99/00—Subject matter not provided for in other groups of this subclass
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/40—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for data related to laboratory analysis, e.g. patient specimen analysis
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/40—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management of medical equipment or devices, e.g. scheduling maintenance or upgrades
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01N—INVESTIGATING OR ANALYSING MATERIALS BY DETERMINING THEIR CHEMICAL OR PHYSICAL PROPERTIES
    • G01N33/00—Investigating or analysing materials by specific methods not covered by groups G01N1/00 - G01N31/00
    • G01N33/48—Biological material, e.g. blood, urine; Haemocytometers
    • G01N33/483—Physical analysis of biological material
    • G01N33/487—Physical analysis of biological material of liquid biological material
    • G01N33/48707—Physical analysis of biological material of liquid biological material by electrical means

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Epidemiology (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • External Artificial Organs (AREA)
  • Investigating Or Analysing Biological Materials (AREA)

Abstract

(57)【要約】 血液処理システムおよび方法は、血液処理処置中にハードウェアステータス状態をモニタする。このシステムおよび方法は、モニタされたハードウェアステータス状態に基づいて現在のシステムデータを生成する。このシステムおよび方法は、ある時間にわたって生成された現在のシステムデータの分析に基づいて、少なくとも１つの未来のハードウェアステータス状態を予測する出力（３４８）を生成する。このシステムおよび方法は、現在のシステムデータを、フラッシュメモリ記憶媒体に書き込む。このシステムおよび方法は、印刷するため、または、見るため、または、遠隔ステーションにオフロードするために、出力を処理する。 SUMMARY A blood processing system and method monitors hardware status conditions during a blood processing procedure. The systems and methods generate current system data based on monitored hardware status conditions. The system and method generate an output (348) that predicts at least one future hardware status condition based on an analysis of current system data generated over a period of time. The system and method writes current system data to a flash memory storage medium. The systems and methods process the output for printing or viewing or for offloading to a remote station.

Description

【発明の詳細な説明】 医療処理装置の動作をモニタおよび分析する システムおよび方法発明の分野 本発明は、血液処理システムなどにより実行される流体処理処置、などの流体 処理処置の過程でデータを記録するシステムおよび方法に関する。発明の背景 今日、人々は日常的に、遠心分離により、全血を、赤血球、血小板、および血 漿などの、全血の様々な治療成分に分離している。 上記およびその他の医療処理装置はしばしば、常駐プログラムソフトウェアを 備えるマイクロプロセッサを用いて制御される。マイクロプロセッサはまた、通 常、何らかのタイプのインタフェースを含み、オペレータは、このインタフェー スを介して、流体処理システムの動作に関する情報を見て把握する。 上記およびその他の医療処理装置はまた、しばしば、処置の過程で、キーとな る制御および処理パラメータを記録する能力とともに、処置の間のオペレータの 介入を追跡する能力を必要とする。これらのデータ記録機能は、例えばＧＭＰ要 求、器具の障害追跡および問題診断、ならびに器具性能評価、などをサポートす るため、有用である。データ記録機能は重要であるが、それでも、処置の全体的 な処理タスクおよび目的と競合するか、または、これらの処理タスクおよび目的 を妨害するべきではない。 そのような流体処理システムに対する動作および性能の要求がより複雑で精巧 になるに従って、データ記録機能を統合し、自動化し、そして強化することが必 要とされている。発明の要旨 本発明は、データ記録機能を処理機能と完全に統合するシステムおよび方法を 提供する。従って、処理タスクを実行する同じ器具が、アドオン外部データ記録 システムを必要とせずに、データ記録機能も果たす。 本発明はまた、必要なデータ記録機能を完全に自動化し、これらのデータ記録 機能が、オペレータがあまり介入または制御せずに、「バックグラウンドで」達 成され得るシステムおよび方法を提供する。 本発明はまた、電源異常または格納データの不正（corruption）、などの実世 界の酷使に耐えるデータ記録機能を実行する強いシステムおよび方法を提供する 。この「耐クラッシュ性」の局面は、器具の電源が任意の時間に停止され得る埋 め込み式ソフトウェアシステム環境において特に重要である。 本発明の１つの局面は、血液処理処置の間にハードウェアステータス状態をモ ニタする血液処理システムおよび方法を提供する。このシステムおよび方法は、 モニタされたハードウェアステータス状態に基づいて、現在のシステムデータを 生成する。このシステムおよび方法は、ある時間にわたって生成された現在のシ ステムデータの分析に基づいて、少なくとも１つの未来のハードウェアステータ ス状態を予測する出力を生成する。 好適な実施形態では、このシステムおよび方法は、印刷するため、または見る ため、または遠隔ステーションにオフロードするために、出力を処理する。 好適な実施形態では、このシステムおよび方法は、現在のシステムデータをフ ラッシュメモリ記憶媒体に書き込む。 本発明の特徴および利点は、以下の説明、図面および請求の範囲から明らかに なる。図面の簡単な説明 図１は、本発明の特徴を実施するコントローラを含む２針血小板収集システム の概略図である。 図２は、コントローラと、関連する器具マネージャおよびグラフィカルユーザ インタフェースとの概略フローチャート図である。 図３は、図２に示されるコントローラと、関連する器具マネージャおよびグラ フィカルユーザインタフェースとの別の概略図であり、コマンドおよびステータ スフロー階層をさらに示す。 図４は、２領域グラフィカルユーザインタフェーススクリーンの図であり、イ ンタフェーススクリーンが含むブロックおよびタッチ活性化式フィールドを示し 、また、インタフェーススクリーンの作業領域のメインメニューを示す。 図５は、２領域インタフェーススクリーンの図であり、インタフェーススクリ ーンの作業領域の処置選択サブメニューを示す。 図６Ａは、２領域インタフェーススクリーンの図であり、インタフェーススク リーンの作業領域の特殊特徴（Special Features）サブメニューを示す。 図６Ｂは、２領域インタフェーススクリーンの図であり、インタフェーススク リーンの作業領域のファイルマネージャサブメニューを示す。 図７は、コントローラおよび関連するデータインタフェースの概略フローチャ ート図である。 図８は、図７に示されるデータインタフェースの記憶装置のブロックファイル 構造の概略図である。 図９は、図８に示されるブロックファイル構造のディレクトリテーブルの概略 図である。 図１０は、図８に示されるブロックファイル構造において割り当てられる１つ のブロックファイル空間の概略図である。 図１１は、図１０に示されるブロックファイル空間へのデータの書き込みを制 御するリングファイル機能の概略図である。 図１２は、２領域インタフェーススクリーンの図であり、インタフェーススク リーンの作業領域のファイルシステム情報サブメニューを示す。 図１３は、２領域インタフェーススクリーンの図であり、インタフェーススク リーンの作業領域のファイルディレクトリサブメニューを示す。 図１４は、図７に示されるデータインタフェースが生成し得る代表的な処置レ ポートである。 図１５は、図７に示されるデータインタフェースが生成し得る代表的な事象レ ポートである。 図１６は、２領域インタフェーススクリーンの図であり、インタフェーススク リーンの作業領域の処置レポート印刷サブメニューを示す。 図１７は、２領域インタフェーススクリーンの図であり、インタフェーススク リーンの作業領域のログビューアサブメニューを示す。 図１８は、２領域インタフェーススクリーンの図であり、インタフェーススク リーンの作業領域のシステム構成サブメニューを示す。 図１９は、２領域インタフェーススクリーンの図であり、インタフェーススク リーンの作業領域の構成設定サブメニューを示す。 図２０は、データインタフェースの予測器機能の概略図である。 図２１は、データインタフェースのインポート構成機能の概略図である。 本発明は、本発明の精神または本質的な特徴から逸脱することなく、幾つかの 形で実施され得る。本発明の範囲は、添付の請求の範囲の前に示される具体的な 説明ではなく、添付の請求の範囲において規定される。従って、請求の範囲の等 価の意味および範囲内にあるすべての実施形態は、請求の範囲に含まれることが 意図される。好適な実施形態の説明 図１は、流体処理システム１０を概略的な形で示す。システム１０は、様々な 流体を処理するために使用され得る。システム１０は、全血、および、生物学的 な細胞材料の懸濁液、のような医療目的のための流体の処理に特によく適してい る。従って、示された実施形態は、この目的のために使用されるシステム１０を 示す。 Ｉ．分離システム システム１０は、耐久ハードウェアエレメントの配列を含む。ハードウェアエ レメントは、処理システムの性質およびタイプに従って変わる。全血の処理のコ ンテキストでは、ハードウェアエレメントは、遠心分離機１２を含む。遠心分離 機１２では、全血（ＷＢ）は、血小板、血漿、および赤血球（ＲＢＣ）のような 様々な治療成分に分離される。ハードウェアエレメントはまた、典型的には蠕動 ポンプである様々なポンプ（Ｐ１〜Ｐ４として示される）と、様々なインライン クランプおよびバルブ（Ｖ１〜Ｖ３として示される）と、を含む。言うまでもな く、典型的には、ソレノイド、圧力モニタ、などのような、図１には示していな いその他のタイプのハードウェアエレメントも存在する。 システム１０はまた、典型的には、ハードウェアエレメントに関連して用いら れる何らかの形の使い捨て流体処理アセンブリ１４を含む。 示された血液処理システム１０では、アセンブリ１４は、２段処理チャンバ１ ６を含む。使用時、遠心分離機１２は、処理チャンバ１６を回転させて、血液成 分を遠心分離する。 ２段処理チャンバ１６の構成を変えてもよい。例えば、処理チャンバ１６は、 Cullisらの米国特許第4,146,172号に示される処理チャンバのような、二重バッ グの形をとり得る。あるいは、処理チャンバ１６は、Brownの米国特許第5,370,8 02号に示されるバッグのような、細長い２段内部バッグの形をとり得る。 示された血液処理システム１０では、処理アセンブリ１４はまた、流体回路（ ｃｉｒｃｕｉｔ）を形成する可撓性のある管のアレイを含む。流体回路は、処理 チャンバ１６に、および、処理チャンバ１６から、液体を運ぶ。ポンプＰ１〜Ｐ ４およびバルブＶ１〜Ｖ３は、この管を係合し、流体の流れを所定の方法で支配 する。流体回路は、処理中に液体を分配し且つ受け取るための多数の容器（Ｃ１ 〜Ｃ３として示される）をさらに含む。 コントローラ１８は、様々なハードウェアエレメントの動作を支配して、アセ ンブリ１４を用いて１つ以上の処理タスクを実行する。本発明は、具体的には、 コントローラ１８の重要な属性に関する。 システム１０は、多様なタイプの血液分離プロセスを達成するように構成され 得る。図１は、自動２針血小板収集処置を実行するように構成されたシステム１ ０を示す。 収集モードでは、第１の管分岐２０および全血入口ポンプＰ２が、ＷＢを、引 き込み針２２から、処理チャンバ１６の第１の段２４に向ける。一方、補助管分 岐２６は、容器Ｃ１から抗凝血剤を計量し、抗凝血剤ポンプＰ１を介してＷＢの 流れに送る。 容器Ｃ２は、食塩溶液を保持する。別の補助管分岐２８は、この食塩溶液を、 インラインバルブＶ１を介して第１の管分岐に運び、処理が始まる前にシステム １０から空気をプライミングし（priming）且つパージする際に使用する。アセ ンブリ１４から残留成分を流し出して供血者に戻すために、食塩溶液はまた、処 理が終わった後にも導入される。 凝血阻止されたＷＢは、処理チャンバ２４の第１の段２４に入って第１の段２ ４を満たす。そこで、遠心分離機１２の回転中に発生される遠心力が、ＷＢを、 赤血球（ＲＢＣ）と、血小板の豊富な血漿（ＰＲＰ）とに分離する。 ＰＲＰポンプＰ４は、ＰＲＰを、処理チャンバ１６の第１の段２４から第２の 管分岐３０に引き込み、処理チャンバ１６の第２の段３２に輸送するように動作 する。そこで、ＰＲＰは、血小板濃縮液（platelet concentrate）（ＰＣ）と、 血小板の乏しい血漿（ＰＰＰ）とに分離される。 システム１０は、再循環管分岐３４と、関連する再循環ポンプＰ３とを含む。 処理コントローラ１８は、処理チャンバ１６の第１の段２４を出ていくＰＲＰの 部分を分流させて、処理チャンバ１６の第１の段２４に入るＷＢと再混合するよ うに、ポンプＰ３を動作させる。 ＷＢが第１のチャンバ段２４に引き込まれて分離されるとき、示される２針シ ステムは同時に、第１のチャンバ段２４からのＲＢＣを、第２のチャンバ段３２ からのＰＰＰの部分とともに、管分岐３８および４０とインラインバルブＶ２と を介して、戻し針３６により供血者に戻す。 システム１０はまた、管分岐３８および４２とインラインバルブＶ３とを介し て、容器Ｃ３のうちの幾つかの中にＰＣを集め、保管および治療に使用する。シ ステム１０はまた、同じ流体経路を介して、容器Ｃ３のうちの幾つかにＰＰＣを 集め得る。 ＩＩ．システムコントローラ コントローラ１８は、今説明したシステム１０についての全体のプロセス制御 およびモニタリング機能を実行する。 示された好適な実施形態（図２参照）では、コントローラは、メイン処理ユニ ット（ＭＰＵ）４４を含む。好適な実施形態では、ＭＰＵ４４は、Motorola Cor poration製造のタイプ６８０３０マイクロプロセッサを含むが、その他のタイプ の従来のマイクロプロセッサが使用されてもよい。 好適な実施形態では、ＭＰＵ４４は、従来のリアルタイムマルチタスキングを 使用して、ＭＰＵサイクルを処理タスクに割り当てる。周期的なタイマ割り込み （例えば、５ミリ秒おき）は、実行しているタスクに割り込み（preempts）、実 行可能な状態にある別のタスクをスケジュールする。リスケジュールが要求され ると、実行可能状態にある最も優先順位が高いタスクがスケジュールされる。そ の他の場合、リストの中で、実行可能状態にある次のタスクがスケジュールされ る。 Ａ．機能ハードウェア制御 ＭＰＵ４４は、アプリケーション制御マネージャ４６を含む。アプリケーショ ン制御マネージャ４６は、制御アプリケーション（Ａ１〜Ａ３として示される） のライブラリ４８の活性化を管理する。制御アプリケーションＡ１〜Ａ３の各々 は、所定の方法でシステムハードウェア（例えば、遠心分離機１２、ポンプＰ１ 〜Ｐ４、およびバルブＶ１〜Ｖ３）を用いて所定の機能タスクを実行するための 処置を規定する。示された好適な実施形態では、アプリケーションＡ１〜Ａ３は 、ＭＰＵ４４のＥＰＲＯＭのプロセスソフトウェアとして存在する。 アプリケーションＡ１〜Ａ３の数は、変わってもよい。示された好適な実施形 態では、ライブラリ４８は、少なくとも１つの臨床処置アプリケーションＡ１を 含む。処置アプリケーションＡ１は、１つの所定の臨床処理処置を実行するため の工程を含む。示された実施形態の例示のために、ライブラリ４８は、図１に関 して既に概して説明された２針血小板収集プロセスを実行するための処置アプリ ケーションＡ１を含む。言うまでもなく、追加の処置アプリケーションが含まれ てもよく、典型的には含まれる。例えば、ライブラリ４８は、従来の単針血小板 収集プロセスを実行するための処置アプリケーション（Ａ１’）を含んでもよい 。 示された好適な実施形態では、ライブラリ４８はまた、少なくとも１つの追加 の非処置アプリケーションを含む。非臨床処置アプリケーションは、システム構 成またはサポートユーティリティを実行するための処置を含む。示された実施形 態の例示のために、ライブラリ４８は、構成アプリケーションＡ２を含み、構成 アプリケーションＡ２は、オペレータがシステム１０のデフォルト動作パラメー タを構成することを可能にするための処置を含む。以下にもより詳細に説明され るように、ライブラリ４８はまた、メインメニューアプリケーションＡ３を含み 、このメインメニューアプリケーションＡ３は、オペレータによる様々なアプリ ケーションＡ１〜Ａ３の選択を調整する。 言うまでもなく、追加の非臨床処置アプリケーションが含まれてもよく、典型 的には含まれる。例えば、ライブラリ４８は、サービス人員がシステムの機能保 全性（functional integrity）を診断し且つ障害追跡するのを助ける処置を含む 診断アプリケーションと、システムが管理できなくなった場合またはエラー状態 から回復することができなくなった場合にシステムの完全な再起動を行うシステ ム再起動アプリケーションと、を含む。 器具マネージャ５０もまた、ＭＰＵ４４のＥＰＲＯＭのプロセスソフトウェア として存在する。器具マネージャ５０は、アプリケーション制御マネージャ４６ と通信する。器具マネージャ５０はまた、ポンプ、ソレノイド、バルブ、および システムのその他の機能ハードウェアのための低レベル周辺コントローラ５２と 通信する。 図３に示すように、アプリケーション制御マネージャ４６は、活性化されたア プリケーションＡ１〜Ａ３による呼び出しに応じて、抽象の形の特定のＰｅｒｆ ｏｒｍ＿Ｆｕｎｃｔｉｏｎ＃コマンドを、器具マネージャ５０に送る。これらの 抽象コマンドに応答して、器具マネージャ５０は、その機能を実行するための１ つまたは複数の周辺コントローラ５２を識別し、そして、ハードウェアに固有の Ｏｐｅｒａｔｅ＿Ｈａｒｄｗａｒｅ＃コマンドをコンパイルして、特定の周辺コ ントローラ５２のためのコマンドテーブルに入れる。周辺コントローラ５２は、 ハードウェアと直接通信して、器具マネージャ５０により生成されるハードウェ アに固有のコマンドを実現し、ハードウェアを特定の方法で動作させて抽象Ｐｅ ｒｆｏｒｍ＿Ｆｕｎｃｔｉｏｎ＃コマンドを実行させる。通信マネージャ５４は 、器具マネージャ５０と周辺コントローラ５２との間の低レベルのプロトコルお よび通信を管理する。 同様に図３に示すように、器具マネージャ５０はまた、処理処置の動作状態お よび機能状態に関するステータスデータを、アプリケーション制御マネージャ４ ６に戻し得る。ステータスデータは、例えば、流体流量、検知圧力、および測定 流体体積に関して表される。 アプリケーション制御マネージャ４６は、様々な方法でステータスデータを処 理し且つ使用する。１つの方法では、以下に説明されるように、アプリケーショ ン制御マネージャ４６は、選択されたステータスデータを送って、オペレータに 表示する。別の方法では、アプリケーション制御マネージャ４６は、ステータス データを用いて動作状態および機能状態をモニタし、オペレータの介入またはシ ステム運転停止を必要とする異常システム状態を検出する。 好適な実施形態（図２参照）では、ＭＰＵ４４はまた、器具マネージャ５０と 通信マネージャ５４との間のデータフロー経路に存在する状態マネージャ５６を 含む。状態マネージャ５６はまた、ステータスデータと、ハードウェアのその他 の動作状態とをモニタして、アプリケーション制御マネージャ４６により検出さ れなかったかまたは訂正されていないままにされている異常状態を検出する。そ のような異常状態を検出すると、状態マネージャ５６は、システム動作をサスペ ンドすることにより、フェールセーフ(fail‐safe)サポートを提供する。 説明された制御階層は、アプリケーション制御マネージャ４６に常駐するアプ リケーションと、システム１０のハードウェアエレメントとの間の抽象「仮想」 インタフェースを作り出す。アプリケーション制御マネージャ４６に常駐する高 レベルプロセスソフトウェアは、ハードウェアエレメントと直接通信する代わり に、器具マネージャ５０のより低いレベルの実現プロセスと通信する。このよう にして、中間器具マネージャ５０は、ハードウェアに固有のコマンドのすべてを 、アプリケーション制御マネージャ４６から隔離するまたは「隠す」。アプリケ ーションは、抽象Ｐｅｒｆｏｒｍ＿Ｆｕｎｃｔｉｏｎ＃コマンドを器具マネージ ャ５０に送り、そして器具マネージャ５０は、これらの抽象コマンドを、いずれ も処置アプリケーションＡ１〜Ａ３自体のさらなる関与を伴わずに、特定のハー ドウェアエレメント独自の具体Ｏｐｅｒａｔｅ＿Ｈａｒｄｗａｒｅ＃コマンドに 変換する。器具マネージャ５０とシステム１０のハードウェアエレメントとの間 のデータフローは、活性化されたアプリケーションＡ１〜Ａ３には見えない。 高レベルプロセスソフトウェアとハードウェアエレメントとの間の仮想インタ フェースの作成は、ハードウェア機能を制御するために高レベルアプリケーショ ンＡ１〜Ａ３のプロセスソフトウェアを追加または改変する場合に、かなりの柔 軟性を提供する。アプリケーションのための新しいまたは改変されたプロセスソ フトウェアは、仮想ハードウェアインタフェースへの即時リンクを得るために、 ハードウェアに固有でない特定の抽象Ｐｅｒｆｏｒｍ＿Ｆｕｎｃｔｉｏｎ＃コマ ンドを含んでいればよい。同様に、特定のハードウェアの追加または改変には、 器具マネージャ５０の低レベルプロセスソフトウェアへの変更しか必要でない。 仮想インタフェースのため、ハードウェアの変更は、アプリケーション制御マネ ージャ４６の高レベルソフトウェアへの最小の変更を必要とする。 上記のように、器具マネージャ５０は、アプリケーション制御マネージャ４６ が存在する同じＭＰＵの部分を形成する。あるいは、インタフェースの仮想性質 のため、器具マネージャ５０は、別個の処理ユニットに存在してもよい。 Ｂ．ユーザインタフェース制御 示された実施形態では、ＭＰＵ４４はまた、インタラクティブユーザインタフ ェース５８を含む。インタフェース５８は、オペレータがシステム１０の動作に 関する情報を見て把握することを可能にする。インタフェース５８はまた、オペ レータがアプリケーション制御マネージャ４６に存在するアプリケーションを選 択することを可能にするとともに、オペレータがシステム１０のある特定の機能 および性能基準を変えることを可能にする。 インタフェース５８は、インタフェーススクリーン６０と、好ましくはオーデ ィオ装置６２と、を含む。インタフェーススクリーン６０は、オペレータが見る ための情報を、英数字フォーマットで、グラフィック画像として表示する。オー ディオ装置６２は、オペレータの注意を得るため、または、オペレータの動作に 肯定応答するために、可聴プロンプトを提供する。 示された好適な実施形態では、インタフェーススクリーン６０はまた、入力装 置としての役割も果たす。以下に説明されるように、インタフェーススクリーン ６０は、従来のタッチ活性化によりオペレータから入力を受け取る。その代わり に、または、タッチ活性化と組み合わせて、マウスまたはキーボードが、入力装 置として用いられてもよい。 インタフェースコントローラ６４は、インタフェーススクリーン６０およびオ ーディオ装置６２と通信する。インタフェースコントローラ６４はまた、インタ フェースマネージャ６６と通信し、インタフェースマネージャ６６はまた、アプ リケーション制御マネージャ４６と通信する。インタフェースコントローラ６４ およびインタフェースマネージャ６６は、ＭＰＵ４４のＥＰＲＯＭのプロセスソ フトウェアとして存在する。 使用時、アプリケーション制御マネージャ４６は、器具マネージャ５０から受 け取った選択されたステータスデータを反映する特定のフィールド値を、インタ フェースマネージャ６６に送る。アプリケーション制御マネージャ４６はまた、 活性化されたアプリケーションにより要求される所定の抽象Ｃｒｅａｔｅ＿Ｄｉ ｓｐｌａｙ＃およびＣｒｅａｔｅ＿Ａｕｄｉｏ＃コマンドを、インタフェースマ ネージャ６６に送る。 インタフェースマネージャ６６は、これらのフィールド値と、抽象Ｃｒｅａｔ ｅ＿Ｄｉｓｐｌａｙ＃コマンドとを処理して、具体Ｆｏｒｍａｔ＿Ｄｉｓｐｌａ ｙ＃コマンドを生成する。Ｆｏｒｍａｔ＿Ｄｉｓｐｌａｙ＃コマンドは、インタ フェーススクリーン６０上の視覚表示を作成し、リフレッシュし、そして閉じる のに必要な特定のフォーマット、属性、およびプロトコルを制御する。 同様に、インタフェースマネージャ６６は、抽象Ｃｒｅａｔｅ＿Ａｕｄｉｏ＃ コマンドを処理して、具体Ｆｏｒｍａｔ＿Ａｕｄｉｏ＃コマンドを生成する。Ｆ ｏｒｍａｔ＿Ａｕｄｉｏ＃コマンドは、活性化されたアプリケーションにより要 求されるオーディオ出力のフォーマットおよび属性を指示する。 インタフェースマネージャ６６は、処理されたＦｏｒｍａｔ＿Ｄｉｓｐｌａｙ ＃およびＦｏｒｍａｔ＿Ａｕｄｉｏ＃コマンドを、インタフェースコントローラ ６４に伝える。インタフェースコントローラ６４は、ボックスやラインを描く低 レベル制御機能を提供し、テキストまたは図形のキャラクタ文字（characters） を形成し、そして、インタフェーススクリーン６０上のディスプレイの属性およ びフォーマッティングを提供する。インタフェースコントローラ６４はまた、イ ンタフェースマネージャ６６から受け取ったＦｏｒｍａｔ＿Ａｕｄｉｏ＃コマン ドに基づいてオーディオ装置６２を駆動する低レベル制御機能を提供する。 以下により詳細に説明されるように、インタフェースコントローラ６４はまた 、 インタフェーススクリーン６０のタッチ活性化により生成されるＦｉｅｌｄ＃＿ Ｓｅｌｅｃｔコマンドを受け入れる。インタフェースコントローラ６４は、この タッチ活性化された入力を、Ｔｏｕｃｈ＃＿Ｃｏｄｅｓの形でインタフェースマ ネージャ６６に送る。インタフェースマネージャ６６は、Ｔｏｕｃｈ＃＿Ｃｏｄ ｅｓを処理し、機能コードまたは変更フィールド値のいずれかとして、アプリケ ーション制御マネージャ４６に送る。アプリケーション制御マネージャ４６は、 機能コードまたは変更フィールド値を実現し、これらを器具マネージャ５０に送 る。 この制御階層はまた、インタフェース５８およびコントローラ１８の機能プロ セッサ間の抽象「仮想」インタフェースを作り出す。インタフェースマネージャ ６６の高プロセスソフトウェアは、システム１０のハードウェア機能を制御する ために用いられるアプリケーションから、インタフェース５８を作り出す際に用 いられるフォーマッティングおよびプロトコルの問題点のすべてを隔離し且つ「 隠す」。アプリケーションＡ１〜Ａ３のプロセスソフトウェアは、アプリケーシ ョン制御マネージャ４６を介して、抽象フィールド値と、抽象Ｃｒｅａｔｅ＿Ｄ ｉｓｐｌａｙ＃およびＣｒｅａｔｅ＿Ａｕｄｉｏ＃コマンドとを、インタフェー スマネージャ６６に送る。インタフェースマネージャ６６のプロセスソフトウェ アは、これらの抽象コマンドを、処置アプリケーションＡ１〜Ａ３自体のさらな る関与を伴わずに、具体コマンドに変換する。具体コマンドは、オペレータイン タフェース５８のテキストおよびグラフィックフォーマットとオーディオフォー マットとを制御する。インタフェースマネージャ６６とインタフェーススクリー ン６４との間のデータフローは、アプリケーション制御マネージャ４６と器具マ ネージャ５０との間のデータフローには見えない。 この制御階層は、ハードウェア機能を制御するためのアプリケーションを追加 または改変する場合に、さらなる柔軟性を与える。新しいまたは改変されたアプ リケーションは、オペレータインタフェースへの即時リンクを得るために、テキ ストフィールド値出力と、所定のＣｒｅａｔｅ＿Ｄｉｓｐｌａｙ＃またはＣｒｅ ａｔｅ＿Ａｕｄｉｏ＃コマンドとを含んでいればよい。 ｉ．インタフェーススクリーンフォーマット 示された好適な実施形態（図４参照）では、インタフェースマネージャ６６の Ｆｏｒｍａｔ＿Ｄｉｓｐｌａｙ＃コマンドは、インタフェーススクリーン６０上 で、ステータス領域６８および作業領域７０と呼ばれる２つの異なるビューイン グ領域に表示するために情報をフォーマットする。好ましくは、これら２つのビ ューイング領域６８および７０は、相対位置に固定され、インタフェーススクリ ーン６０上での大きさは変わらない。これは、システムの機能ハードウェアが異 なる処理モードを循環するときでも、インタフェース５８の見かけに、連続性お よび一貫性を与える。インタフェース５８の２重ビューイング領域６８および７ ０の均一性および一貫性は、オペレータの混同およびエラーの可能性を低減する 。 ステータス領域６８および作業領域７０の各々は、異なるタイプおよびレベル の情報専用にされる。それでも、これら２つの領域６８および７０は常に同時に 表示され、高レベルの「大きいピクチャ」情報および低レベルの「詳細」情報の 両方のビューをオペレータに提供する。 作業領域７０は、オペレータがシステム常駐アプリケーションＡ１〜Ａ３のい ずれか１つを選択して活性化するための手段を提供する。作業領域７０は、活性 化されたアプリケーションＡ１〜Ａ３により生成されるＣｒｅａｔｅ＿Ｄｉｓｐ ｌａｙ＃コマンドにより後に要求される、処置に依存する具体情報をすべて表示 する。作業領域７０に表示される情報のかなりの詳細は、オペレータが進行中の プロセスをリアルタイムでモニタおよび変更することを可能にする。 一方、ステータス領域６８は、より一般的で「概略」的性質の、処置に依存す る所定の情報であって、オペレータが決まって常時表示および即時アクセスを必 要とする情報を絶えず示す。オペレータが、作業領域７０を用いてプロセスのよ り詳細な局面をモニタおよび変更しているときでも、ステータス領域６８は、こ の一般情報を絶えず表示して、オペレータに、進行中のプロセスの全体的なステ ータスを評価させ続ける。示された好適な実施形態では、ステータス領域６８は また、オペレータがアラームまたは誤動作に応答する手段を提供する。 これら２つのビューイング領域６８および７０は、オペレータが、インタフェ ース５８を素早く用いて、システム動作中に詳細な処置、機能およびオプション を見つけそしてその中から選択することを可能にするか、または、オペレータが 、 進行中の処置の全体的ステータスとの接触を失うことなくオフライン機能を実行 することを可能にする。２つのビューイング領域６８および７０は、オペレータ が、実際にはマルチレベルメニュー構造であるものをナビゲートし、メニュー構 造を必ずしも上下にステップ移動する必要なく、且つ、コマンドがあり次第より 高いメニューレベルとより低いメニューレベルとの間ですぐにジャンプする能力 を失うことなく、１つのメニューレベルに関する詳細に注目することを可能にす る。 示された実施形態では、ビューイング領域６８および７０は、図形線またはキ ャラクタ文字の線７２により垂直方向に分離され、ステータス領域６８が、スク リーン６０の上３分の１を占有し、作業領域７０が、スクリーン６０の下３分の ２を占有する。ただし、ビューイング領域６８および７０が横に並んだ関係で水 平方向に分離されてもよく、スクリーン６０の異なる割合を占有してもよいこと が認識されるべきである。 ステータス領域６８および作業領域７０は、フィールドで情報を表示する。イ ンタフェースマネージャ６６が生成する、特定のディスプレイに関するＦｏｒｍ ａｔ＿Ｄｉｓｐｌａｙ＃は、そのようなフィールドのリストからなる。そのリス トは、各フィールドについて、その位置、サイズ、ならびに、そのフィールドが 含む情報のフォーマットおよび領域内でのタイプを特定する。 以下により詳細に説明されるように、フィールドは、個々のタッチ選択可能な ボタンとしてフォーマットされ得る。フィールドはまた、オペレータに選択肢の フィールドを与えるタッチ選択可能なボタンフィールドのアレイとしてフォーマ ットされ得る。 フィールドはまた、英字もしくは数字のデータストリングか、または、線で囲 まれた（line-wrapped）スクロール可能なテキストの多数の行を含むテキストデ ータか、または、グラフィック画像、を含むブロックとしてフォーマットされ得 る。フィールドはまた、数値フォーマットをグラフの形で表示する棒グラフフィ ールドになるようにフォーマットされ得る。 インタフェースマネージャ６６は、すべての表示属性のレイアウトおよびフォ ーマッティングを記述するデータを格納する一定の（ＲＯＭベースの）構造を、 ルックアップテーブルの形で含む。表示属性には、領域、フィールドタイプ、お よび領域内でのフィールド位置、などがある。インタフェースマネージャ６６は 、インタフェースディスプレイの現在の状態を記述する動的（ＲＡＭベースの） 構造を格納する。活性化されたアプリケーションから所定のＣｒｅａｔｅ＿Ｄｉ ｓｐｌａｙ＃コマンドを受け取ると、インタフェースマネージャ６６は、活性化 されたアプリケーションによる要求に応じて、ＲＯＭベースのテーブル構造およ びＲＡＭベースのステータス構造を調べ、ＲＡＭベースのステータス構造を作成 または更新する。インタフェースマネージャ６６は、スクリーン６０およびオー ディオ出力を周期的に更新するために必要とされるすべての動作を実行する時間 トリガ式タスクルーチンを含む。インタフェースマネージャ６６は、この処理さ れた情報を、インタフェースコントローラ６４に送って実現する。 インタフェースマネージャ６６はまた、インタフェースコントローラ６４から 受け取られるＴｏｕｃｈ＃＿Ｃｏｄｅにより識別される各々のタッチ選択可能な ボタンフィールドと関連するＦｕｎｃｔｉｏｎ＃＿Ｃｏｄｅを保持する。Ｆｕｎ ｃｔｉｏｎ＃＿Ｃｏｄｅｓは、Ｔｏｕｃｈ＃＿Ｃｏｄｅにより識別される、領域 とその領域内でのフィールド位置とに従って、一定の（ＲＯＭベースの）ルック アップテーブルの形で配列される。インタフェースコントローラ６４は、所定の ボタンが触れられると、その領域とフィールド位置とを登録し、この情報を、Ｔ ｏｕｃｈ＃＿Ｃｏｄｅの形でインタフェースマネージャ６６に送る。インタフェ ースマネージャ６６は、プロセスボタンユーティリティを含む。このプロセスボ タンユーティリティは、この情報を待ち、そして、ＲＯＭベースのテーブル構造 を調べて適切なＦｕｎｃｔｉｏｎ＃＿Ｃｏｄｅをアプリケーション制御マネージ ャ４６に送って実現することによりこの情報を非同期に処理する。 ステータス領域６８および作業領域７０における表示のために選択される情報 およびフォーマットを変えてもよい。 ａ．ステータス領域 示された実施形態（図４参照）では、ステータス領域６８は、活性化された臨 床処置の説明を含むメジャーモードフィールド７４と、処置ステータスの１語ま たは２語の説明を含むマイナーモードフィールド７６と、処理中に引き込みポン プＰ２を通して供血者から引き込まれた血液の量をｍｌの単位で数値的に表現し た値を含む処理ＷＢフィールド７８と、を含む。 示された実施形態（図４）では、ステータス領域６８はまた、例えばヘルプ８ ０、メインメニュー８２、処置表示８４、および一時停止／終了８６、として示 されるタッチ選択可能なボタンフィールドのアレイを含む。各フィールドが触れ られると、インタフェースマネージャ６６は、ステータス領域６８のブロックフ ィールド７４／７６／７８の情報の表示を変えることなく、アプリケーション制 御マネージャ４６による実現のための所定の機能コードを送る。 ステータス領域６８はまた、コンテキストに依存する注意／警告プロンプトボ タンフィールド８８を含む。注意／警告プロンプトボタンフィールド８８は、ア ラームまたは警告が活性であるとき、ステータス領域６８の右側の固定位置、即 ち、一番上の場所を占有する。注意／警告プロンプトボタンフィールド８８は、 アラームまたは警告が活性でないときには表示されない。ミュートボタンフィー ルド９０もまた、アラームが活性であるとき、ステータス領域６８の左側の固定 位置、即ち、一番上の場所を占有する。注意／警告ブロックフィールドもまた、 アラームが活性であるときに、ステータス領域の中央の固定位置、即ち、一番下 の場所を占有する。 ｂ．作業領域 示された好適な実施形態では、作業領域７０は、デフォルトにより、メインメ ニューアプリケーションＡ３により要求されるメインメニューディスプレイを示 す。メインメニューディスプレイは、タッチ選択可能なボタンフィールド９４お よび９６のアレイを含む。 処置選択ボタンフィールド９４に触れると、このフィールド９４は、作業領域 ７０に処置サブメニューを表示する機能を呼び出す（図５参照）。処置サブメニ ューは、アプリケーション制御マネージャ４６により管理されるすべての臨床処 置アプリケーションを、タッチ選択可能なボタンフィールド１０４および１０６ のアレイでリストする。示された実施形態では、この臨床処置アプリケーション は、２針処置アプリケーションＡ１および単針処置アプリケーションＡ１’であ る。処置アプリケーションボタンフィールドに触れると、このボタンフィールド は、アプリケーション制御マネージャ４６に、関連するアプリケーションを活性 化するよう指示する。活性化されたアプリケーションは、このアプリケーション 自体の指定されたＣｒｅａｔｅ＿Ｄｉｓｐｌａｙ＃コマンドを生成する。インタ フェースマネージャ６６は、このＣｒｅａｔｅ＿Ｄｉｓｐｌａｙ＃コマンドを実 現して、作業領域７０内の表示を変える。 特殊特徴ボタンフィールド９６に触れると、このボタンフィールド９６は、作 業領域７０に特殊特徴サブメニューを表示する機能を呼び出す（図６参照）。特 徴サブメニューは、アプリケーション制御マネージャ４６により管理される、臨 床処置に固有でない指定されたアプリケーションを、タッチ選択可能なボタンフ ィールドのアレイ２００でリストする。所定の特殊処置アプリケーションボタン に触れると、そのアプリケーションが活性化され、そして、作業領域７０内の表 示は、活性化されたアプリケーションのＣｒｅａｔｅ＿Ｄｉｓｐｌａｙ＃コマン ドに応答して変わる。フィールド２００中の特定のボタンのさらなる詳細は、以 下に提供される。 説明されるコントローラ１８およびグラフィカルユーザインタフェースマネー ジャ６６のさらなる詳細は、米国特許第5,581,687号に見ることができる。本明 細書において、上記米国特許を参考として援用する。 Ｃ．データインタフェース 示された好適な実施形態（図７参照）では、コントローラ１８はまた、データ インタフェース２０２を含む。データインタフェース２０２は、コントローラ１ ８のソフトウェアおよびハードウェアアーキテクチャの自立型（self-contained ）一体部を構成する。データインタフェース２０２は、所定の処理アプリケーシ ョンの間の、キーとなる制御および処理パラメータと、オペレータのステップと の収集、保持および操作を自動化する。データインタフェース２０２は、大容量 データ記憶装置２０４のデータ構造に、情報を保持する。大容量データ記憶装置 ２０４はまた、コントローラ１８の一体部を構成する。記憶装置２０４のデータ 構造は、情報が、不測の電源損失による不正に耐える安全な態様で格納され、取 り出され、そして操作されることを可能にする。記憶装置２０４のデータ構造は また、格納された情報が、取り出され且つフォーマットされて印刷されたレポ ートにされることを可能にする。 データインタフェース２０２はまた、望ましい場合には、１つ以上の外部コン ピュータ２０６および２０６’にリンクされてもよいが、これは、データインタ フェース２０２の動作に必ずしも必要であるわけではない。以下により詳細に説 明されるように、データインタフェース２０２は、格納された情報を、構成され た順序または任意の順序のいずれかで、コンピュータ２０６、２０６’にダウン ロードし得る。 データインタフェース２０２は、様々な方法で実現され得る。好適な実施形態 では、大容量記憶装置２０４は、例えばＰＣＭＣＩＡタイプＩＩのＰＣカードＡ ＴＡ標準ハードウェアインタフェースに適合するフラッシュメモリカード、など のフラッシュメモリカードを含む。従来、フラッシュメモリカード装置２０４は 、２〜８５メガバイトの記憶範囲をサポートし得る。典型的な実現では、記憶装 置２０４は、約８メガバイトのデータを保持し得る。 フラッシュメモリ記憶装置２０４は、従来のハードドライブ記憶媒体と比べて 、集積データインタフェース２０２とともに使用するのに向いている。フラッシ ュメモリ装置２０４は、フォーマッティングの容易さと、高速データアクセス時 間とを提供する。フラッシュメモリ装置２０４は、血液処理ハードウェアと空間 を競わない小型のコンパクトサイズを示す。フラッシュメモリ装置２０４は、機 械構成要素を有しておらず、従って、非常に信頼性が高く、繰り返しの使用によ る故障が起こりにくい。フラッシュメモリ装置２０４はまた、耐久性があり、血 液処理処置の間に遠心血液処理装置が決まって発生する振動およびその他の力に 耐える。フラッシュメモリ装置２０４はまた、オンサイトでのサービスおよび取 り替えが容易である。 データインタフェース２０２はまた、追加のハードウェア入出力装置２０８、 ２１０、２１２および３４８を含む。これらのハードウェア入出力装置は、例え ば従来のシリアルＲＳ−２３２Ｃポートリンクなどの形をとり得る。従来のパラ レルポートリンク、および、１つ以上のEthernetTM通信リンク、などの他の入出 力装置が用いられてもよい。 示された実施形態（図７参照）では、１つのポートリンク２０８が、外部バー コードスキャナ２１４と通信する。第２のポート２１０は、上述の一方の外部コ ンピュータ２０６と通信する。第３のポートリンク２１２は、外部プリンタ２１ ６と通信する。第４のポートリンク３４８は、他方の外部コンピュータ２０６’ と通信する。 データインタフェース２０２はまた、ＭＰＵ４４のＥＰＲＯＭに存在する様々 なプロセスソフトウェアモジュール２１８〜２３０を含む。プロセスソフトウェ アモジュール２１８〜２３０は、所定のデータ処理タスクを実行する。 ソフトウェアモジュール２１８〜２３０の数およびタイプを変えてもよい。示 された実施形態では、１つのモジュール２１８は、通信マネージャタスクを実現 する。通信マネージャタスクモジュール２１８は、ＲＳ−２３２Ｃポートリンク ２０８、２１０、２１２および３４８への、および、ＲＳ−２３２Ｃポートリン ク２０８、２１０、２１２および３４８からの、より低いレベルのデータ転送を 扱う。通信マネージャタスクモジュール２１８は、ＭＰＵ４４が、それぞれのＲ Ｓ−２３２Ｃポートリンク２０８、２１０、２１２および３４８によって送信さ れ得るよりも速くデータを転送することを防ぐ。 別のモジュール２２０は、バーコードタスクを実現する。バーコードタスクモ ジュール２２０は、バーコードスキャナポートリンク２０８を介して受け取られ る、バーコードスキャナ２１４からの未加工(raw)のＡＳＣＩＩデータ入力を受 け取る。バーコードタスクモジュール２２０は、スキャンされたデータを構文解 析（parses）し、それを組み立てて、以下により詳細に説明される処置ドライバ タスクモジュール２２２と呼ばれる別のモジュールと適合性のある入力にする。 処置ドライバタスクモジュール２２２はまた、スキャンされたデータがスキャン された入力を登録したことを確認し、そして、一旦確認されると、バーコードタ スクモジュール２２０は、以下に説明されるように、フィードバックメッセージ 出力２３２をフォーマットする。 データインタフェース２０２はまた、処置ドライバタスク、ファイルシステム タスク、レポートタスク、データ交換タスク、データダンプタスク、およびユー ザインタフェースタスク、をそれぞれ実現するその他のコア処理モジュールを含 む。次に、上記タスクの詳細を説明する。 ｉ．処置ドライバタスク 処置ドライバタスクモジュール２２２は、アプリケーション制御マネージャ４ ６およびバーコードタスクモジュール２２０から情報を受け取る。処置ドライバ タスクモジュール２２２は、アプリケーション制御マネージャ４６を介して、そ のとき進行中の処置に関するキーとなる指定された制御およびステータス情報と 、ポンプ、ソレノイド、バルブ、光検出器、およびシステムのその他の機能ハー ドウェアに関するキーとなる指定された制御およびステータス情報と、を登録す る。処置ドライバタスクモジュール２２２は、この登録情報を含むデータを日付 印とともに生成し、時間ベースのコンテキストを提供する。データは、構造化さ れたバイトストリームであり、これらのバイトストリームは、ファイルシステム タスクモジュール２２４によりさらに処理されて、格納、取り出し、または操作 が行われる。 処置ドライバタスクモジュール２２２が生成するデータの性質およびタイプを 変えてもよい。 ａ．処置データ（Ｐデータ） 示された実施形態では、処置ドライバタスクモジュール２２２は、スキャンさ れたバーコード入力をすべて登録する。このバーコード入力は例えば、供血者、 処理器具、および処理に用いられる使い捨て構成要素、を識別する情報を含み得 る。処置ドライバタスクモジュール２２２はまた、キーとなる処理パラメータお よび血液成分の降伏値（yield value）が初期化されるとき、および処置の過程 で更新されるときに、アプリケーション制御マネージャから、これらの処理パラ メータおよび血液成分の降伏値をすべて登録する。 処置ドライバタスクモジュール２２２はまた、すべての処理モード変更と、発 生されたすべての警告アラームとを登録する。示された実施形態では、処置ドラ イバタスクモジュール２２２はまた、例えば、針プライミングの開始および停止 、ならびに処置の一時停止および再開、などの設計された特殊処理事象を登録す る。 処置ドライバタスクモジュール２２２は、Ａｃｔ＿Ｐｒｏｃ＿Ｄａｔａ（図７ で２３４として示される）と呼ばれるランダムアクセスデータファイルを確立し 且つ維持する。Ａｃｔ＿Ｐｒｏｃ＿Ｄａｔａファイル２３４の内容は、選択され た制御および処理パラメータを含む。示された実施形態では、Ａｃｔ＿Ｐｒｏｃ ＿Ｄａｔａファイル２３４は、データを所定の順序で保持するためのテンプレー トとしてフォーマットされる固定長ファイルである。活性処置データは、Ａｃｔ ＿Ｐｒｏｃ＿Ｄａｔａファイル２３４のテンプレートの指定場所に周期的に（例 えば、１５秒おき）書き込まれる。 従って、現在のＡｃｔ＿Ｐｒｏｃ＿Ｄａｔａファイル２３４は、そのとき進行 中の処置に関する有意な制御および処理パラメータとデータとのリアルタイムス テータスを反映する。Ａｃｔ＿Ｐｒｏｃ＿Ｄａｔａファイル２３４により保持さ れるパラメータおよびデータは、例えば以下のものを含み得る。（ｉ）供血者識 別情報（例えば、割り当てられた供血者Ｉ．Ｄ．番号、供血者の性別および体重 、割り当てられた血液提供Ｉ．Ｄ．番号、ならびに選択された血液処理処置）、 （ｉｉ）処理に使用される器具および使い捨て構成要素の識別（例えば、割り当 てられた器具番号および使い捨てキットコード、ロット番号、ならびに使用期限 による）、（ｉｉｉ）得られる初期処理パラメータ値（例えば、抗凝血剤の比率 、予め計数された血小板数（platelet precounts）、全血ヘマトクリット、処理 される全血体積、収集する血漿の体積、血小板収量（yield）、平均血小板体積 、収集された血小板のための血漿の保存体積、供血者に戻されるクエン酸塩の体 積、など）、および（ｉｖ）そのときの活性処置データ（例えば、使用される抗 凝血剤および食塩水、血漿生成物（product plasma）および保存血漿に存在する 抗凝血剤および食塩水、処置の収集時間、処理されたＷＢ量、引き込まれたＷＢ の合計量、合計血漿保存量、ならびに収集された血漿生成物）。 示された実施形態では、処置の終わりに（そして、望ましい場合には、処置の 間、周期的に（例えば、１５秒おき））、処置ドライバタスクモジュール２２２ は、時刻印付き処置データ２３６を生成する。このデータ２３６は、図７では、 省略して「Ｐデータ」と呼ばれる。処置データ２３６は、そのときの現在のＡｃ ｔ＿Ｐｒｏｃ＿Ｄａｔａファイル２３４に保持される情報のスナップショットで ある。 処置データ２３６は、Ａｃｔ＿Ｐｒｏｃ＿Ｄａｔａファイル２３４のテンプレ ートに従ってフォーマットされる。現在の処置データ２３６は、キーとなる供血 者データ、器具および使い捨てデータ、目標の処置処理値、ならびに実際の処置 処理値の一覧を含む。図１４は、以下に説明されるように、代表的な処置データ ファイル２３６に含まれる情報の性質およびタイプを報告書フォーマットで例示 する。 処置ドライバは、生成された処置データ２３６を、ファイルシステムタスクモ ジュール２２４に送り、ファイルシステムタスクモジュール２２４は、このデー タを、記憶装置２０４の指定された安全なファイル構造で処理し、格納、取り出 しおよび操作を行う。ファイルシステムタスクモジュール２２４のさらなる詳細 は、以下に説明される。 ｂ．事象データ（Ｅデータ） 処置の経過中、処置ドライバタスクモジュール２２２はまた、その他の個別の タイプのデータを生成し得る。例えば、示された実施形態（図７参照）では、処 置ドライバタスクモジュール２２２は、時刻印付き事象データ２３８を周期的に 生成する。これらの時刻印付き事象データが集まって、キーとなる処理事象の時 系列（chronological）記録を作る。 図７では省略して「Ｅデータ」と呼ばれる事象データ２３８は、キーとなる事 象の発生に応答して生成され得る。キーとなる事象には、例えば、処置の開始の 記録、使い捨て構成要素の設置、処理パラメータの入力、プライミング、バーコ ードスキャナ２１４でスキャンされたデータの入力、アラーム状態およびその解 決、ならびに処置の終了、などがある。そのときの現在の処理パラメータを提供 するために、その他の事象データ２３８もまた、周期的に（例えば、１５秒おき ）生成され得る。この処理パラメータは、例えば、処理される全血の体積、全血 流量、全血入口ポンプ圧、赤血球戻しポンプ圧、などである。 処置ドライバタスクモジュール２２２は、事象データ２３８を、ファイルシス テムタスクモジュール２２４に送る。以下により詳細に説明されるように、ファ イルシステムタスクモジュール２２４は、事象データ２３８を、記憶装置２０４ の指定されたファイル構造に組み込む。格納されたシステム事象データ２３８は 、ファイル時刻印により時系列で配列される場合、有意な処置事象および状態の 時間順記録を含む。図１５は、以下に説明されるように、代表的な事象データフ ァ イル２３８をコンパイルしたものに含まれる情報の性質およびタイプを報告書フ ォーマットで例示している。 ｃ．システム状態データ（Ｓデータ） 示された実施形態（図７参照）では、システム動作の経過中、システムタスク はまた、時刻印付きシステム状態データ３３６を生成する。このデータ３３６は 、図７では、上記のように、省略して「Ｓデータ」と呼ばれる。システム状態デ ータは、器具マネージャ５０の制御下にあるポンプ、ソレノイド、バルブ、光検 出器、およびシステムのその他の機能ハードウェアに関する予め選択された状態 、ステータスまたはエラー状態を表す。 処置ドライバタスクモジュール２２２は、システム状態データ３３６を、ファ イルシステムタスクモジュール２２４に送る。以下により詳細に説明されるよう に、ファイルシステムタスクモジュール２２４は、システム状態データ３３６を 、記憶装置２０４の指定されたファイル構造に組み込む。格納されたシステム状 態データ３３６は、処置の経過中の、システムハードウェアに関する有意な状態 の時間順記録を含む。図１７は、以下に説明されるように、オペレータによって 見られるようにフォーマットされた場合に、代表的なシステム状態データ３３６ をコンパイルしたものに含まれる情報の性質およびタイプを例示する。 ｄ．ダンプセンサデータ（Ｄデータ） 示された実施形態（図７参照）では、処置ドライバタスクモジュール２２２は 、処置の経過中、周期的（例えば、５秒おき）に、個別の時刻印付きダンプセン サデータ３５０を生成する。このデータ３５０は、図７では、省略して「Ｄデー タ」と呼ばれる。ダンプセンサデータ３５０は、コントローラ１８に結合される 状態検知ハードウェアにより記録された現在の検知値のスナップショットである 。状態検知ハードウェアは、例えば、入口および出口ポンプ圧、血液収集容器の 重量、ならびに光検出器により検知された光伝送値、などをモニタし得る。 処置ドライバタスクモジュール２２２は、ダンプセンサデータ３５０を、ファ イルシステムタスクモジュール２２４に送る。以下により詳細に説明されるよう に、ファイルシステムタスクモジュール２２４は、ダンプセンサデータ３５０を 、記憶装置２０４の指定されたファイル構造に組み込む。ダンプセンサデータ３ ５ ０は、所定の処置の経過中にモニタされた検知状態の時間順記録を含む。 ｉｉ．ファイルシステムタスク ファイルシステムタスクモジュール２２４は、処置ドライバタスクモジュール ２２２、データ交換タスクモジュール２２８、およびレポートタスクモジュール ２２６に、ファイルサービスを提供する。ファイルシステムタスクモジュール２ ２４は、処置データ２３６、事象データ２３６、システム状態データ３３６、お よびダンプセンサデータ３５０の格納、取り出し、および操作のためのインタフ ェースを提供する。 図８に示すように、ファイルシステムタスクモジュール２２４は、ブロック装 置機能２４０を含む。ブロック装置機能２４０は、記憶装置２０４の媒体２４２ を、Ｎ個のブロックを有するようにフォーマットする。各ブロックは、０から始 まりＮまでの数（ただし、Ｎは含まない）によりアドレス指定可能である（図８ では、Ｎ＝４３）。フォーマット構造は、ブロック０を占有するルートノード２ ４４を、ブロック１の冗長コピー２４４Ｃとともに含む。フォーマット構造は、 ブロック２で始まる１つ以上のブロックを占有するディレクトリノード２４６を さらに含む。フォーマット構造は、Ｎまで（ただし、Ｎは含まない）の残りのブ ロックを、処置ドライバタスクモジュール２２２により生成される様々なデータ ２３６、２３８、３３６および３５０のための空間として割り当てる。 ブロック装置機能２４０は、残りのブロックを個別のファイル空間に静的に分 割する。これらのファイル空間の各々は、１つのタイプのデータ２３６、２３８ 、３３６または３５０を受け入れるように割り当てられる。図８は、例示の目的 のために、４つのタイプのデータ２３６、２３８、３３６および３５０のための ４つのファイル空間２４８、２５０、２５２および２５４をそれぞれ示す。ただ し、典型的には、これよりも多くのブロックが利用可能であり、従って、追加の ファイル空間が割り当てられ得る。 ファイル空間２４８、２５０、２５２および２５４の各々は、隣接するブロッ ク範囲を含む。示された実施形態（図８）では、ファイル空間２４８、２５０、 ２５２および２５４の各々は、例示の目的のために、１０ブロックの同じ最大サ イズを有している。ただし、データ２３６、２３８、３３６および３５０は、異 なるサイズ要求を強いてもよく、ファイル空間２４８、２５０、２５２および２ ５４は、典型的には、異なる最大サイズを有する。 ａ．ルートノード ルートノード２４４は、ファイルシステムの名前を識別し、ランタイムコード により強いられる全体的なレイアウトの幾何学的形状を記述する。ルートノード ２４４は、ファイルシステムの合計容量をブロックの単位で特定し、且つ、使用 され得る固定サイズファイルの最大数、即ち、静的に割り当てられたファイル空 間が何個存在するか（示された実施形態では、４個）、を特定する。ルートノー ド２４４はまた、処置データ２３６を作成するために処置ドライバタスクモジュ ール２２２により使用されたテンプレートのコピーを含む。このテンプレートは 、主として情報を提供する目的で、ルートノード２４４に格納される。それでも 、格納されたテンプレートは、完全な損傷が起こった場合にファイルシステムを 復元するための参照として使用されてもよい。 ルートノード２４４は、改変可能な情報を含まない。一旦ファイルシステムが 作成されると、ルートノード２４４は改変されない。ブロック０が読み出し不可 能になった場合に備えて、ルートノード２４４の同一のコピー２４４Ｃが、ブロ ック１に維持される。 ｂ．ディレクトリノード ブロック装置機能２４０により媒体２４２がフォーマットされると、媒体２４ ２は、各々が一定の所定最大サイズを有する一定数のファイル空間を収容する能 力を有する。ディレクトリノード２４６は、フォーマットされたファイル空間２ ４８、２５０、２５２および２５４のためのディレクトリテーブル２５６を含む 。 図９に例示されるように、ディレクトリテーブル２５６は、各ファイル空間の 開始ブロックアドレスおよび固定サイズをリストする。テーブル２５６は、ファ イルシステムの予め割り当てられたすべてのファイル空間のためのディレクトリ エレメント２５８または「スロット」を含む（示された実施形態では、４個ある ）。各ディレクトリエレメント２５８は、予め割り当てられたファイル空間のブ ロック番号（即ち、アドレス）と、ファイル空間の予め割り当てられたサイズを ブロックの単位で表した数値と、を含む。 本明細書において説明されるように、ディレクトリテーブル２５６に保持され るブロック番号即ちアドレスは、論理ファイルシステムブロックアドレスを指す 。論理ファイルシステムブロックアドレスは、物理媒体ブロックアドレスに対応 していてもしていなくてもよい。 ディレクトリテーブル２５６は、１つのディレクトリレベルしか含まない。即 ち、ディレクトリテーブル２５６は、階層的でない。ディレクトリテーブル２５ ６はまた、動的ではない。一旦ファイルシステムが作成されると、ディレクトリ テーブル２５６は改変されない。テーブル２５６は単に、割り当てられたファイ ル空間の場所への静的ポインタを提供する役割を果たすだけである。 ディレクトリテーブル２５６はまた、予め割り当てられたファイル空間がデー タを含んでいるのかどうか、または、利用可能であるのかどうかを示さない。動 的割り当て情報は、ファイル空間に書き込まれたバイトストリームデータ上に維 持される。即ち、データの有無自体が、ファイル空間についての割り当て情報を 提供する。 説明されたファイルシステムタスクモジュール２２４は、電源異常または記憶 装置２０４上での任意のデータ不正が起こっても、ブロックファイルシステム構 造の保全性を保持する。そのような酷使に直面しても、ファイルシステムタスク モジュール２２４は、ファイルシステムの基本ブロック構造を失わず、実行され る別個のファイルシステム回復動作を必要としない。各ファイル空間２４８、２ ５０、２５２および２５４は、一定の最大サイズを有し、ファイル空間は、より 多くのデータを収容するように大きくなることはできない。ディレクトリテーブ ル２５６と一致しないファイル空間のいかなる割り当ても、急いで固定され得る 。 ブロック装置機能２４０はまた、一旦ファイルシステムが作成されると最初の 予め割り当てられたファイル空間よりも小さいブロック番号への書き込みをさせ ないハード安全性検査を含む。ファイルシステム作成中には、若い番号のブロッ クだけが、書き込みのために活性化される。従って、ソフトウェアバグがディレ クトリブロックを破壊してしまう可能性は少ない。ディレクトリブロックが静的 であるため、ディレクトリブロックが電源異常の間に書き込みエラーにより破壊 されてしまう可能性も少ない。 ｃ．データ空間 図１０が示すように、ファイル空間２４８、２５０、２５２および２５４の各 々は、一次ノード２６０を含む。一次ノード２６０は、ファイル空間に関連する メタデータ（即ち、割り当てられたまたは自由なファイル名、作成時間、現在の サイズ、など）を含む。各ファイル空間はまた、二次ノード２６２を含む。二次 ノード２６２は、一次ノード２６０と同じ内容を有する。以下に説明されるよう に、これは、ファイルのメタデータを更新している間の「フリップフロップ」の ために用いられる。 ファイル空間２４８、２５０、２５２および２５４の各々はまた、ファイルの 予め割り当てられた物理空間２６４を含む。空間２６４は、割り当てられた処置 データ２３６、事象データ２３８、システム状態データ３３６、またはダンプセ ンサデータ３５０のデータ内容を受け入れる。 ブロック装置機能２４０は、ランダムアクセス書き込みを行わない。ブロック 装置機能２４０は、開始ブロック番号によりアドレス指定されるすべてのブロッ クの読み出しおよび書き込みか、または、ファイル空間が満たされるまで、ファ イル空間において前方向にデータを連続的に付加すること、のいずれかを可能に する。 示された実施形態で実現されるように、所定の処置の最初に、１つのファイル 空間２４８が、処置中に生成される処置データ２３６のために予約され、１つの ファイル空間２５０が、処置中に生成されるすべての事象データ２３６のために 予約される。データインタフェース２０２の最初のブートアップの際、１つのフ ァイル空間２５２は、その後のすべての処置についてのシステム状態データ３３ ６のために指定され、１つのファイル空間２５４は、その後のすべての処置につ いてのダンプセンサデータ３５０のために指定される。以下により詳細に説明さ れるように、ファイル空間２５２および２５４は、リングファイルを保持し、こ のリングファイルには、最も新しい指定データ３３６および３５０が付加され、 最も古いデータを上書きする。 （１）処置データファイル空間 予約される処置データファイル空間２４８の最大サイズは、処置データ２３６ のテンプレート全体と、バックアップコピー（以下に説明される）とを余裕をも って収容できるように選択される。代表的な実施形態では、約５．６キロバイト の最大ファイルサイズが予約される。 予約された処置データファイル空間２４８は、処置の最初に処置ドライバタス クモジュール２２２により生成される最初の処置データ２３６を受け取る。処置 の経過中に処置ドライバタスクモジュール２２２により生成されるその後の処置 データ２３６は、ファイル空間２４８の論理オフセットゼロで始まる同じ処置フ ァイル空間２４８に、ブロックとして書き込まれ、それにより、以前の処置デー タ全体を上書きする。概念的に、ファイル空間２４８の処置データ２３６は、処 置が終了するまで、処置が進むに従って周期的に「リフレッシュ」され、空間２ ４８に最後に書き込まれた処置データ２３６を残す。 （２）事象データファイル空間 予約される事象データファイル空間２５０の最大サイズは、典型的な処置の間 に生成されるすべての事象データ２３８と、バックアップコピー（以下に説明さ れる）とを余裕をもって収容するように選択される。代表的な実施形態では、約 ６６．５キロバイトの最大ファイルサイズが予約される。 予約された事象データファイル空間２５０は、論理オフセットゼロで、処置の 最初に処置ドライバタスクモジュール２２２により生成される最初の事象データ ２３８を受け取る。その次の事象データ２３８は、最初の事象データ２３８のフ ァイル（ＥＯＦ）ポイントの終わりに付加される。その後の事象データ２３８は 、物理データ空間２５０が満たされるまで、この態様で付加される。物理データ 空間２５０が満たされた後、その処置に関して、それ以上の事象データを記録す ることはできない。 万一データ空間２５０がその固定容量まで満たされてしまった場合、ファイル システムタスクモジュール２２４は、ユーザインタフェースタスクモジュール２ ３０にメッセージ出力を生成する（以下に説明される）。所定の処置の終わり近 くで事象データが失われないことを保証するために、事象データファイル空間２ ５０の最大サイズの評価は、慎重に行われるべきである。ブロック装置機能２４ ０はまた、万一典型的でない数の事象データを生成して第１の事象ファイル空間 ２５０を満たす典型的でない処置が起こった場合に第２の事象ファイル空間を指 定する機能を、バックアップとして含み得る。 （３）システム状態データファイル空間 およびダンプセンサファイル空間 （リングファイル） 同様の態様で、ブロック装置機能２４０は、システム状態データ３３６および ダンプセンサデータ３５０を、それぞれの指定された予約ファイル空間２５２お よび２５４に書き込み、そして、これらのデータ３３６および３５０を引き続き 付加する。しかし、その物理データ空間が満たされるとそれ以上のデータ入力を させないファイル空間２５０とは異なり、ブロック装置機能２４０は、それぞれ の固定ファイル空間２５２および２５４へのシステム状態データ３３６およびダ ンプセンサデータ３５０の連続的な付加を受け入れる機能２６６を含む。この機 能２６６は、これらの空間２５２および２５４の固定物理割り当て空間２６４を 、円形リングまたはリングファイル２６８（図１１参照）として扱う。リングフ ァイル２６８では、ファイル空間２６４が満たされると、最も古いデータ２７０ が、新しいデータ２７２で上書きされる。 リングファイル機能２６６は最初に、所定の処置中に処置ドライバタスクモジ ュール２２２により生成されるすべてのデータ（図１１では、例示の目的のため に、システム状態データ３３６）を、指定ファイル空間２６４に付加する。デー タ３３６が連続的に指定ファイル空間２６４に書き込まれるため、リングファイ ル２６８のサイズは、最初のデータ３３６の場合にゼロで始まり、追加のデータ ３３６が付加されるに従って、ファイル空間２６４が一杯になるまで大きくなる 。この時点（図１１参照）で、リングファイル機能２６６は、古いデータ２７０ を、ファイル空間２６４のデータに割り当てられた最初のノードで始まる（即ち 、メタデータを有する一次および二次ノード２６０および２６２の後に）新しい データ２７２で上書きすることにより、データを「覆う（wrap）」。 リングシーム２７４は、ファイル空間２６４中の最も古いデータ２７０と、フ ァイル空間２６４中の最も新しいデータ２７２とを分離する。新しいデータ２７ ２がファイル空間２６４に入ると、リングシーム２７４は、（図１１の矢印２７ ６で示されるように）予め割り当てられた空間の終わりに向かって絶えず移動す る。一旦ファイル空間２６４の終わりに達すると、リングシーム２７４は、最初 のデータノードに循環し、再び、ファイル空間２６４の終わりに向かって前方向 に移動する。 ファイル空間２６４においてデータが最初に覆われた後、リングファイル機能 ２６６は、論理リングシームポインタ２７８を維持する。リングシームポインタ ２７８は、リングシーム２７４のブロックアドレスを示す。リングファイル機能 ２６６はまた、最も新しいデータ２７２とリングシームポインタ２７８との間の 論理結合部を示すブロックアドレスに、ファイルの論理ファイル終了ポインタ２ ８０を配置する。リングシーム機能２６６はまた、最も古いデータ２７０とリン グシームポインタ２７８との間の論理結合部を示すブロックアドレスに、論理オ フセットゼロポインタ２８２を配置する。データが最初に覆われた後、リングシ ーム機能２６６は、ファイルポインタ２８０の論理終了部で始まるデータを付加 する。付加されたデータがファイル空間２６４に書き込まれると、リングシーム 機能２６６は、論理オフセットゼロポインタ２８２を、リングシームポインタ２ ７８と並べて前進させる。 システム状態データファイル空間２５２およびダンプセンサデータファイル空 間２５４の固定最大サイズは、予想される、データをコンパイルしたものと、バ ックアップコピー（以下に説明される）とを余裕をもって収容するように選択さ れる。代表的な実施形態では、システム状態データファイル空間２５２には、約 １００キロバイトの最大ファイルサイズが予約され、ダンプセンサデータファイ ル空間２５４には、約１メガバイトの最大ファイルサイズが予約される。 （４）ファイル空間保全性 ブロック装置機能２４０は、ファイル空間２４８、２５０、２５２および２５ ４にそれぞれ書き込まれたデータ２３６、２３８、３３６および３５０のバック アップコピーを自動的に作成する。さらに、割り当てられたすべてのファイル空 間のデータ構造は、１６ビットＣＲＣによりブロックごとに保護される。これは 、ブロック装置機能２４０が、ブロックの書き込みが成功したかどうか、および 、読み返されたときにブロックが有効であるかどうか、を検出することを可能に す る。ＣＲＣ不一致などのいかなる理由でもブロックが無効であることが分かれば 、ブロック装置機能２４０は、ブロックのバックアップコピーを確認する。バッ クアップコピーが有効であれば、ブロック装置機能２４０は、バックアップコピ ーのデータを用いて続行する。または、バックアップデータは、損傷したブロッ クを回復するために使用されてもよい。 ファイルシステムの最も動的な局面は、所定のファイル空間のファイルノード ２６０である。データがファイル空間に付加されるかまたはファイル空間に書き 込まれるときにはいつでも、ファイル空間のメタデータは、更新されなければな らない。最後の改変時間が、現在の時間に更新されなければならない。付加され ると、ファイルの論理サイズは、付加されたデータ量だけ増加されなければなら ない。現在の読み出しまたは書き込み場所もまた、次の読み出しまたは書き込み 動作が起こるべき場所を示すように更新されなければならない。 ファイルノード２６０が非常に頻繁に更新されるため、そして、ファイルノー ド２６０が、ファイルにアクセスするときに非常に重要であるため、ファイル空 間２４８、２５０、２５２および２５４の各々は、二次ファイルノード２６２を 含む。ファイルノード２６０および２６２の各々は、ファイル空間に新しいファ イルが作成されるとゼロで初期化される「年齢(age)」マーカを有する。ファイ ル空間のファイルノード２６０および２６２が改変されるたびに、ファイルノー ドの年齢マーカは、増分される。 ファイルのメタデータが更新されなければならないときにはいつでも、ブロッ クドライバ機能２４０は、ファイルノードの年齢マーカを登録する。年齢マーカ が偶数であれば、一次ファイルノード２６０が改変される。逆に、年齢マーカが 奇数であれば、二次ファイルノード２６２が改変される。これにより、ファイル ノード２６０および２６２への書き込みは、一次ファイルノード２６０と二次フ ァイルノード２６２との間で「フリップフロップ」される。 装置ブロック機能がファイルノードを読み出す必要がある場合、装置ブロック 機能は、一次および二次ファイルノード２６０および２６２の両方を読み出し、 最も大きい「年齢(age)」マーカを有するファイルノードを、有効であると考え る。これにより、ファイルノード更新動作（即ち、ファイルノードへの書き込 み）が、ファイルノード全体が破壊されるハードウェア障害を経験することが可 能になる。別のファイルノードは常に、より古い状態ではあるが、ファイルの一 貫した状態を含む。 酷使に耐える能力は、処置データ２３６または事象データ２３８の各々に含ま れるデータには及んでいない。処置ドライバタスクモジュール２２２およびファ イルシステムタスクモジュール２２４の責務は、データ保全性を維持することで ある。しかし、一般に、データが前方向に付加される場合、データ損失は、ファ イルの終わりで起こる。従って、万一付加動作でエラーが起こった場合、エラー は、ファイル全体のうちで比較的わずかな部分に相当する最も新しく付加された データにのみ影響を及ぼす。 ファイルシステムタスクモジュール２２４は、ジャーナリングファイルシステ ム（journalling-file systems）またはコミットロールバックトランザクション 設備（commit-rollback transaction facility）、などの従来の複雑なデータベ ース管理機能に頼らずに、ファイル保全性を維持する。フォーマットされたファ イル空間を大きくさせないことにより、ファイルシステムタスクモジュール２２ ４は、データが書き込まれるときに、ファイルシステムメタデータにわずかな改 変しか必要としない。ファイルシステムタスクモジュール２２４は、各ファイル が配置されている場所を動的に指すファイルディレクトリに頼らない。ファイル システムタスクモジュール２２４は、ファイルシステムデータを含むブロックを 移動させず、そして、これらのブロックの新しい場所を指すようにポインタを更 新しない。ファイルシステムタスクモジュール２２４は、フリープールからブロ ックを取り出してファイルに付与することにより、ファイルのサイズを動的に拡 大せず、または、ファイルのブロックをフリープールに動的に戻してファイルデ ィレクトリからファイルをアンリンクしない。ファイルシステムタスクモジュー ル２２４は、ファイルシステムが動的に変えられている時間であって、ファイル システムが電源異常による破滅的なデータ不正を受けやすい時間のウィンドウを 最小にする。この破滅的なデータ不正を受けやすい時間を最小にすることにより 、ファイルシステムタスクモジュール２２４は、万一電源異常が起こった場合に 、破滅的なデータ不正が起こる可能性を最小にする。 ｉｉｉ．ユーザインタフェースタスク（ファイルシステム タスクサポート） ユーザインタフェースタスクモジュール２３０は、ファイルシステムタスクモ ジュール２２４およびレポートタスクモジュール２２６を、以前に説明されたイ ンタフェースマネージャ６６にリンクする。ユーザインタフェースタスクモジュ ール２３０は、データインタフェース２０２をサポートするように規定された抽 象Ｃｒｅａｔｅ＿Ｄｉｓｐｌａｙ＃コマンドを、インタフェースマネージャ６６ に送る。インタフェースマネージャ６６は、データインタフェース２０２のＣｒ ｅａｔｅ＿Ｄｉｓｐｌａｙ＃コマンドを処理し、具体Ｆｏｒｍａｔ＿Ｄｉｓｐｌ ａｙ＃コマンドを生成する。以前に説明されたように、Ｆｏｒｍａｔ＿Ｄｉｓｐ ｌａｙ＃コマンドは、インタフェーススクリーン６０上の視覚表示を作成し、リ フレッシュし、そして閉じるために必要な、特定のフォーマット、属性、および プロトコルを制御する。それにより、ユーザインタフェースタスクモジュール２ ３０は、データインタフェース２０２に、グラフィカルユーザインタフェースを 提供する。 示された実施形態（図４参照）では、スクリーン６０の作業領域７０にデフォ ルトにより示されるメインメニューディスプレイは、特殊特徴ボタンフィールド ９６を含む。特殊特徴ボタンフィールド９６に触れると、このフィールド９６は 、図６Ａに示すように、作業領域７０に特殊特徴サブメニューを表示する機能を 呼び出す。特徴サブメニューは、タッチ選択可能なボタンフィールドのアレイ２ ００でリストする。特殊特徴サブメニューのボタンフィールドの１つである２８ ４は、診断として示されている。 診断ボタンフィールド２８４を押すと、ユーザインタフェースタスクモジュー ル２３０は、インタフェースマネージャ６６に、所定のＣｒｅａｔｅ＿Ｄｉｓｐ ｌａｙ＃コマンドを生成し、次にインタフェースマネージャ６６が、Ｆｏｒｍａ ｔ＿Ｄｉｓｐｌａｙ＃コマンドを生成して、図６Ｂに示すように、作業領域７０ にファイルマネージャサブメニューを表示する。ファイルマネージャサブメニュ ーは、タッチ選択可能なボタンフィールドのアレイ３５２でリストする。ボタン フィールドの１つである３５４は、ファイルシステムユーティリティとして示さ れている。 ａ．ファイルシステムユーティリティ ファイルシステムユーティリティボタンフィールド３５４を押すと、ユーザイ ンタフェースタスクモジュール２３０は、インタフェースマネージャ６６に、所 定のＣｒｅａｔｅ＿Ｄｉｓｐｌａｙ＃コマンドを生成し、次にインタフェースマ ネージャ６６が、Ｆｏｒｍａｔ＿Ｄｉｓｐｌａｙ＃コマンドを生成して、図１２ に示されるように、ファイルシステム情報サブメニューを表示する。 ファイルシステム情報サブメニューは、第１のボックス２８６を含む。第１の ボックス２８６は、データインタフェース２０２の記憶装置２０４の属性を、例 えば、ベンダ、モデル、容量により、そして、そのインストールを確認すること により、識別する。この情報は、ファイルシステムタスクモジュール２２４によ り、ユーザインタフェースタスクモジュール２３０に提供される。ファイルシス テム情報サブメニューはまた、第２のボックス２８８を含む。第２のボックス２ ８８は、例えば、インストールされるファイルシステムタスクモジュール２２４ のソフトウェアバージョンを識別し、その動作準備完了を確認し、そして、その 現在の容量をリストすることにより、ファイルシステムタスクモジュール２２４ 自体の属性を識別する。 ファイルシステム情報サブメニューはまた、ファイルマネージャとして示され る押しボタンフィールド２９０を含む。ファイルマネージャボタンフィールド２ ９０を押すと、ユーザインタフェースタスクモジュール２３０は、インタフェー スマネージャ６６に、所定のＣｒｅａｔｅ＿Ｄｉｓｐｌａｙ＃コマンドを生成し 、次にインタフェースマネージャ６６が、Ｆｏｒｍａｔ＿Ｄｉｓｐｌａｙ＃コマ ンドを生成して、図１３に示すように、ファイルディレクトリサブメニューを表 示する。 ファイルディレクトリサブメニューは、ボックスフィールド２９２を含む。ユ ーザインタフェースタスクモジュール２３０は、ファイルシステムタスクモジュ ール２２４に、割り当てられた処置ファイル空間２４８および事象ファイル空間 ２５０の各々の現在のメタデータファイルノード２６０または２６２を読み出す よう命令する。ユーザインタフェースタスクモジュール２３０は、メタデータを フォーマットしてファイルシステムデータ２９４にする。ファイルシステムデー タ２９４は、Ｅ（事象データ）またはＰ（処置データ）サフィックス（suffix） 、時刻印、および、記憶装置２０４に存在するファイルサイズにより、ボックス フィールド２９２に行でリストされる。オペレータは、制御ボタン２９６を用い て、公知の態様で行を上下にスクロールすることができる。 ファイルディレクトリサブメニューはまた、名前でソート、日付でソート、お よびサイズでソート、としてそれぞれ示されるソートオプション押しボタンフィ ールド２９８、３００および３０２を含む。ソートオプションが選択されると、 ユーザインタフェースタスクモジュール２３０は、ボックスフィールド２９２内 のリストを再フォーマットし、選択に応じて名前、日付、またはサイズによりフ ァイルの順序を構成する。 ユーザインタフェースタスクモジュール２３０は、ユーザがファイル行を選択 することを可能にするために、ファイルディレクトリサブメニューにおける強調 表示３０４の表示を命令する。ファイルディレクトリサブメニューは、削除押し ボタンフィールド３０６を含む。削除ボタンフィールド３０６を押すと、ユーザ インタフェースタスクモジュール２３０は、ファイルシステムタスクモジュール ２２４に、強調表示されたファイル空間のデータ内容を記憶装置２０４から削除 するよう命令する。これにより、このファイル空間は、別の処置に関するデータ を受け取るために開放される。 ファイルディレクトリサブメニューはまた、出口押しボタンフィールド３０８ を含む。出口ボタンフィールド３０８を押すと（または、ステータス領域６８に 見えているメインメニューボタンフィールド８２を押すといつでも）、ユーザイ ンタフェースタスクモジュール２３０は、作業領域７０のディスプレイを、図４ に示されるようなデフォルトメインメニューに戻す。 ｂ．システムログビューア ファイルマネージャサブメニューの別のボタンフィールド３６０は、システム ログビューアとして示される。システムログビューアボタンフィールド３６０を 押すと、ユーザインタフェースタスクモジュール２３０は、インタフェースマネ ージャ６６に、所定のＣｒｅａｔｅ＿Ｄｉｓｐｌａｙ＃コマンドを生成し、次に インタフェースマネージャ６６が、Ｆｏｒｍａｔ＿Ｄｉｓｐｌａｙ＃コマンドを 生成して、図１７に示されるように、ログビューアサブメニューを表示する。 ログビューアサブメニューは、ボックスフィールド３６２を含む。ユーザイン タフェースタスクモジュール２３０は、ファイルシステムタスクモジュール２２ ４に、割り当てられたリングファイル空間２５２に含まれるシステム状態データ ３３６を読み出すよう命令する。ユーザインタフェースタスクモジュール２３０ は、システム状態データ３３６をフォーマットし、その内容をボックスフィール ド３６２に時系列に行で表示する。各行は、例えば、記録された状態（state） 、状態（condition）またはエラーの時刻印付き説明と、識別用システム参照コ ードと、をリストする。データ３３６に含まれるその他の情報もまた、リストさ れ得る。オペレータは、制御ボタン３６４を用いて、公知の態様で行を上下にス クロールすることができる。 ステータス領域６８に見えているメインメニューボタンフィールド８２を押す と、ユーザインタフェースタスクモジュール２３０は、作業領域７０のディスプ レイを、図４に示されるようなデフォルトメインメニューに戻す。 ｃ．バーコードディスプレイ ユーザインタフェースタスクモジュール２３０は、スクリーン６０の作業領域 ７０を変更してファイルディレクトリ情報および機能（図１２および図１３）ま たはシステム状態事象ログ（図１７）を表示させるコマンドを発行するが、スク リーン６０のステータス領域６８は、同時にステータス領域６８の情報を示し続 ける。マイナーモードフィールド７６は、処置が収集モードであることを示し続 け、ステータス領域は、供血者から引き込まれたＷＢの体積を、絶えず処理ＷＢ フィールド７８に示す。処置が動作モードを変えるまで、その他のボタンフィー ルド８０／８２／８４／８６の場所および属性は変わらないままである。処置が 動作モードを変えると、マイナーモードフィールド７６は、このモード変更を反 映するように変わる。 ユーザインタフェースタスクモジュール２３０はまた、バーコードタスクモジ ュール２２０と通信する。ユーザインタフェースタスクモジュール２３０は、バ ーコードスキャン入力の受け入れを確認すると、バーコードタスクモジュール２ ２０により生成されるフィードバックメッセージ２３２を受け取る（図７参照） 。図１２、図１３および図２０に示すように、ユーザインタフェースタスクモジ ュール２３０は、スクリーン６０のステータス領域６８に設けられるバーコード フィールド３５８におけるフィードバックメッセージの表示を命令する。 ｉｖ．レポートタスク レポートタスクモジュール２２６は、プリンタポートリンク２１２と通信する 。レポートタスクモジュール２２６は、ファイルシステムタスクモジュール２２ ４およびユーザインタフェースタスクモジュール２３０によりサービスされる。 レポートタスクモジュール２２６は、活性であるとき、ファイルシステムタスク モジュール２２４に、そのときに記憶装置２０４に存在する指定された処置デー タ２３６および事象データ２３８の場所を特定して読み出すよう指示する。レポ ートタスクモジュール２２６は、データを所定の英数字フォーマットで与えるレ ポートを作る。図１４および図１５は、このレポートを例示している。レポート タスクモジュール２２６は、レポートをプリンタ２１６にダウンロードする。 言うまでもなく、印刷されたレポートのフォーマットおよび内容を変えてもよ い。例えば、レポートタスクモジュール２２６は、記憶装置２０４上の所定の処 置データファイル空間２４８に含まれる処置データ２３６に基づいて作られる処 置レポート３１０（図１４参照）を生成してもよい。別の実施例として、レポー トタスクモジュール２２６は、記憶装置２０４上の所定の事象データファイル空 間２５０に格納された事象データの内容を時間順にリストする事象レポート３１ ２（図１５参照）を生成してもよい。 ｖ．ユーザインタフェースタスク（レポートタスクサポート） ユーザインタフェースタスクモジュール２３０はまた、レポートタスクモジュ ール２２６を、インタフェースマネージャ６６にリンクする。示された実施形態 では、特殊特徴サブメニュー（図６Ａ参照）（図４に示されるメインメニューデ ィスプレイ上の特殊特徴ボタンフィールド９６を介してアクセスされる）上のボ タンフィールドの１つである３１４は、処置レポート印刷として示される。処置 レポート印刷ボタンフィールド３１４を押すと、ユーザインタフェースタスクモ ジュール２３０は、インタフェースマネージャ６６に、所定のＣｒｅａｔｅ＿Ｄ ｉｓｐｌａｙ＃コマンドを生成し、次にインタフェースマネージャ６６が、Ｆｏ ｒｍａｔ＿Ｄｉｓｐｌａｙ＃コマンドを生成して、図１６に示されるように、処 置レポート印刷サブメニューを表示する。 処置レポート印刷は、ボックスフィールド３１６を含む。このボックスフィー ルド３１６は、現在の処置データ２３６および事象データ２３８が記憶媒体２０ ４に存在する処置を行でリストする。オペレータは、制御ボタン３１８を用いて 、公知の態様で行を上下にスクロールすることができる。ユーザインタフェース タスクモジュール２３０は、選択するために、強調表示３２０を表示する。 処置レポート印刷サブメニューは、選択レポート印刷押しボタンフィールド３ ２２を含む。このボタンフィールド３２２を押すと、ユーザインタフェースタス クモジュール２３０は、レポートタスクモジュール２２６に、選択された処置に 関するフォーマットされたレポート（示された実施形態では、図１４に示される 処置レポート３１０および図１５に示される事象レポート３１２）をフォーマッ トして印刷するよう命令する。現在のレポートキャンセルの押しボタン３２４フ ィールドを選択することにより、ユーザは、選択されたレポートの印刷を終了す ることができる。 処置レポート印刷サブメニューはまた、プリンタステータスボックスフィール ド３２６を含む。プリンタステータスボックスフィールド３２６は、例えば、ア イドル、ビジー、エラー、などのプリンタ２１６のステータスを報告する、通信 マネージャタスクモジュール２１８からの情報を表示する。 ステータス領域６８に見えているメインメニューボタンフィールド８２を押す と、ユーザインタフェースタスクモジュール２３０は、作業領域７０のディスプ レイを、図４に示されるようなデフォルトメインメニューに戻す。 ユーザインタフェースタスクモジュール２３０はまた、オペレータが、レポー トタスクモジュール２２６を調整して、処置の終わりに処置レポート３１０およ び事象レポート３１２を自動的にコンパイルして印刷させることを可能にする。 示された実施形態（図６Ａ参照）では、特徴サブメニュー上のボタンフィールド の１つである３３０は、システム構成として示されている。システム構成ボタン フィールド３３０を押すと、ユーザインタフェースタスクモジュール２３０は、 インタフェースマネージャ６６に、所定のＣｒｅａｔｅ＿Ｄｉｓｐｌａｙ＃コマ ンドを生成し、次にインタフェースマネージャ６６が、Ｆｏｒｍａｔ＿Ｄｉｓｐ ｌａｙ＃コマンドを生成し、図１８に示されるように、システム構成サブメニュ ーを表示する。システム構成サブメニューはまた、構成設定ボタン３３２を含む 。構成設定ボタン３３２を押すと、このボタン３３２は、図１９に示されるよう に、構成設定サブメニューの表示を引き起こす。構成設定サブメニューは、「自 動印刷」押しボタンフィールド３３４を含む。このボタン３３４を押すと、ボタ ンラベルが、ターンオンとターンオフとの間でトグルされる。 ターンオフ状態（自動プリント特徴が作動される）にトグルされると、データ インタフェース２０２は、処置の終わりで処置レポート３１０および事象レポー ト３１２を自動的にコンパイルして印刷するように調整される。 Ｄ．データ交換タスク ｉ．データ転送機能 既に説明された処置ドライバタスクモジュール２２２、ファイルシステムタス クモジュール２２４、印刷タスクモジュール、およびユーザインタフェースタス クモジュール２３０の特徴のため、データインタフェース２０２は、外部コンピ ュータ２０６の使用または外部コンピュータ２０６への接続を伴わずに、データ を格納し、取り出し、そして操作するように完全に組み込まれることが認識され るべきである。 ただし、第２のポート２１０は、望ましい場合には、データインタフェース２ ０２を外部コンピュータ２０６にリンクすることを可能にする。データ交換タス クモジュール２２８は、内蔵データインタフェース２０２と外部コンピュータ２ ０６との間の通信交換インタフェースを確立するデータ共有機能３８４を含む。 １つの実施形態では、第２のポートリンク２１０に結合される外部コンピュー タ２０６は、外部コンピュータ２０６自体の常駐制御ソフトウェア３３８を含み 得る（図７参照）。ソフトウェア３３８は、データインタフェース２０２を促し て所定の処置のキーとなる制御および処理パラメータを得るようにプログラムさ れる。データ交換タスクモジュール２２８のデータ共有機能３８４は、このデー タを組み立てて、格納、取り出しまたは操作のためにコンピュータ２０６にダウ ンロードすることにより応答する。 この構成では、データ交換タスクモジュール２２８のデータ共有機能３８４は 、ランダムアクセスデータファイル３４０を生成する。このランダムアクセスデ ータファイル３４０は、図７では、Ａｃｔ２＿Ｐｒｏｃ＿Ｄａｔａとして示され る。Ａｃｔ２＿Ｐｒｏｃ＿Ｄａｔａファイル３４０は、処置ドライバタスクモジ ュール２２２によりランダムアクセスメモリに維持されるＡｃｔ＿Ｐｒｏｃ＿Ｄ ａｔａファイル２３４と同じようにフォーマットされる。所定の処置が進行中で ある間、データ共有機能３８４は、Ａｃｔ＿Ｐｒｏｃ＿Ｄａｔａファイル２３４ からのデータを周期的にＡｃｔ２＿Ｐｒｏｃ＿Ｄａｔａファイル３４０にコピー する。所定の処置が進行中である間、データ共有機能３８４はまた、記憶装置２ ０４上の現在の事象データファイル空間２５０に存在する事象データを周期的に 読み出すことができる。しかし、所定の処置が進行中である間、データ共有機能 ３８４は、記憶装置２０４上の現在の処置データファイル空間２４８を読み出す ことができない。 外部コンピュータ２０６に存在する制御ソフトウェア３３８は、処置が進むと 、プログラムされたＡＳＣＩＩ入力を、データ共有機能３８４に送る。プログラ ムされた入力に応答して、データ共有機能３８４は、Ａｃｔ２＿Ｐｒｏｃ＿Ｄａ ｔａファイル３４０から、または、記憶装置２０４上の現在の事象データファイ ル空間２５０から読み出されたデータに基づいて、所望の応答を構成する。デー タ共有機能３８４は、この応答を外部コンピュータ２０６に送り、格納、取り出 し、または操作を行う。一旦処置が終了すると、データ共有機能３８４は、記憶 装置２０４上の処置データファイル空間２４８および事象データファイル空間２ ５０の両方からデータを読み出し、外部コンピュータ２０６からの予めプログラ ムされた入力への応答を構成することができる。 示された実施形態では、データ共有機能３８４は、通信マネージャタスクモジ ュール２１８が、イネーブル制御ソフトウェア３３８を有するコンピュータ２０ ６とのポート２１０を介する通信を検知するといつでも自動的に活性化される。 ｉｉ．制御入力機能 データ交換タスクモジュール２２８はまた、データ制御機能３８６を含む。こ のデータ制御機能３８６により、プロセス制御入力３８８が、外部コンピュータ ２０６から受け取られ得る。この構成では、コンピュータ２０６の制御ソフトウ ェア３３８は、コンピュータ２０６上で、インタフェースマネージャ６６と適合 性のあるグラフィカルユーザインタフェースを確立する。データ制御機能３８６ は、プロセス制御入力３８８を、コンピュータ２０６から、ユーザインタフェー スタスクモジュール２３０を介してインタフェースマネージャ６６に送る。プロ セス制御入力３８８は、以前に説明されたスクリーン６０からの対応する入力と 同じコマンドおよび制御機能を果たす。 データ制御機能３８６は、コントローラ１８に関する処理パラメータを、遠隔 位置から確立または変更することを可能にする。 ｉｉｉ．パージ機能 示された実施形態では、データ交換タスクモジュール２２８は、パージ機能３ ４４を含む。パージ機能３４４は、ファイルシステムタスクモジュール２２４に より管理されるファイルの数についてのハウスキーピングを行う。所定の間隔で （例えば、終了時、または、各処置で）、パージ機能３４４は、ファイルシステ ムタスクモジュール２２４により維持されるメタデータファイルノード２６０／ ２６２を読み出す。パージ機能は、ファイルシステムタスクモジュール２２４に 、最も古いデータがどこに存在するかに従って、所定の数を超過する処置データ ファイル空間および事象データファイル空間からデータを削除するよう指示する 。例えば、ファイルシステムタスクモジュール２２４が、４０個の処置について ファイル空間を割り当てると（即ち、４０個の処置データファイル空間および４ ０個の事象データファイル空間）、パージ機能３１４は、最も古いデータがどこ に格納されているかに従って、それぞれ３０を超過する割り当てられた処置ファ イル空間および事象ファイル空間のデータを削除する。このようにして、データ インタフェース２０２は、３０個の最も新しい処置について、現在の処置データ ２３６および事象データ２３８を維持する。システム状態データ３３６およびダ ンプセンサデータ３５０のリングファイルの性質は、最近のデータだけが維持さ れることを自動的に保証する。 代表的な実現では、記憶装置２０４は、８メガバイトの記憶空間を有する。ブ ロック装置機能２４０は、それぞれ１００キロバイトの２つのファイル空間を割 り当てる。その一方は、システム状態データファイル空間２５２のためであり、 もう一方は、開放された余分なファイル空間である。ブロック装置機能２４０は また、それぞれ１メガバイトの２つのファイル空間を割り当てる。その一方は、 ダンプセンサデータファイル空間２５４のためであり、もう一方は、開放された 余分なファイル空間である。ブロック装置機能２４０はさらに、それぞれ５．６ キロバイトの７０個のファイル空間を処置データファイル空間２４８として割り 当て、且つ、それぞれ６６．５キロバイトの７０個のファイル空間を事象データ ファイル空間２５０として割り当てる。パージ機能３１４により制御されて、こ れらのファイル空間２４８および２５０の３０個ずつは、現在の処置データを保 持する。残りの３０個は、フリーファイル空間である。 Ｅ．ユーザインタフェースタスク（データ交換タスクサポート） ｉ．ファイル転送機能 別の実施形態では、記憶装置２０４上に存在する処置データファイルまたは事 象データファイルは、データインタフェース２０２のユーザインタフェースタス クモジュール２３０による制御に応じて、外部コンピュータ２０６上の制御ソフ トウェアをその他に必要とすることなく、いかなる任意の順序でも、第２のポー トにリンクされるいかなる適合性のある外部コンピュータ２０６にも転送または ダウンロードされ得る。 示された実施形態において実現されるように、ファイルディレクトリサブメニ ュー（図１３参照）は、転送押しボタンフィールド３４６を含む。転送ボタンフ ィールド３４６を押すと、ユーザインタフェースタスクモジュール２３０は、フ ァイルシステムタスクモジュール２２４に、強調表示されたファイルのデータを 記憶装置２０４からデータ交換タスクモジュール２２８にコピーするよう命令す る。次にデータ交換タスクモジュール２２８は、このデータを、第２のポートを 介して外部コンピュータ２０６に転送する。外部コンピュータ２０６は、内蔵デ ータ処理ソフトウェアを用いて、データの格納、取り出しおよび操作を行うこと ができる。 データインタフェース２０２の組み込まれたデータ記録機能は、外部コンピュ ータ２０６がデータ格納プロセスの間接続されることを必要としない。さらに、 いかなる外部コンピュータ２０６も、データインタフェース２０２によりデータ が格納された後に接続され得る。データインタフェース２０２はまた、処理機能 の終了後、任意の時間に任意の態様で外部コンピュータ２０６にデータをダウン ロードすることを可能にする。データインタフェース２０２により収集されたデ ータはまた、フィールドサービス人員に利用可能であり、これにより、正確なプ ログラム診断および器具性能評価が可能になる。 ｉｉ．ファイルインポート機能 示された実施形態（図２１参照）では、データ交換タスクモジュール２２８は 、インポート機能３８０を含む。インポート機能３８０は、外部コンピュータ２ ０６からコントローラ１８に追加の動作アルゴリズム３８２をインポートまたは アップロードして実現することを可能にする。 示された実現では、システム構成サブメニュー（図１８）は、インポート構成 ボタン３７８を含む。インポート構成ボタン３７８を押すと、このボタン３７８ は、入力機能３８０を活性化する。インポート機能３８０は、コントローラ１８ のＭＰＵ４４をインポートモードにブートする。このインポートモードは、ポー トリンク２１０に結合されるコンピュータ２０６の制御ソフトウェア３３８によ り支配される。コンピュータ２０６からの入力に支配されて、制御ソフトウェア ３３８は、１つ以上の追加の動作アルゴリズム３８２を、ＭＰＵ４４、具体的に は器具制御マネージャ４６、器具マネージャ５０およびインタフェースマネージ ャ６６、のＥＰＲＯＭのプロセスソフトウェアとして、インストールする。 インポートされたアルゴリズム３８２は、アプリケーション制御マネージャ４ ６により呼び出され得る１つ以上の新しいアプリケーションを確立する。インポ ートされたアルゴリズムはまた、器具マネージャ５０およびインタフェースマネ ージャ６６に実現プロセスソフトウェアをインストールする。 Ｆ．データダンプタスク 示された実施形態では、ユーザインタフェース２０２はまた、データダンプタ スクモジュール３６６を含む。データダンプタスクモジュール３６６は、ポート リンク３４８およびファイルシステムタスクモジュール２２４と通信する。デー タダンプタスク機能３６６は、ファイルシステムタスクモジュール２４４がダン プセンサデータ３５０を書き込むファイル空間（即ち、図８の空間２５４）のデ ータ内容を周期的に読み出す。データダンプタスクモジュール３６６は、現在の ダンプセンサデータ３５０を、メッセージバッファ出力３７０としてフォーマッ トし、このメッセージバッファ出力３７０は、ポートリンク３４８を介して、接 続された外部コンピュータ２０６’に送られる。 外部コンピュータ２０６’は、イネーブル制御ソフトウェア３６８を含む。ソ フトウェア３６８は、フォーマットされたメッセージバッファ出力３７０を受け 取って格納、取り出しまたは操作を行うよう、コンピュータ２０６’を調整する 。 例えば、データダンプタスクモジュール３６６は、メッセージバッファ出力３ ７０を５秒おきに自動的に組み立ててポートリンク３４８に送り、外部コンピュ ータ２０６’にダウンロードすることができる。外部コンピュータ２０６’によ り維持されるこの時系列記録は、処置全体の検知状態の正確で包括的な記述を提 供する。この記録は、システムエラーの障害追跡を行うために、サービスまたは 診断技術者により使用され得る。この記録はまた、研究開発技術者が、アプリケ ーション制御マネージャ４６のための新しい動作アルゴリズムを設計、開発およ び実現するのを助け得る。 図２０において、データダンプタスクモジュール３６６は、予測器機能３７２ を含む。予測器機能３７２は、所定の基準に従って連続的なメッセージバッファ 出力３７０の内容を分析するアルゴリズムを含む。例えば、基準は、検知状態を 、確立された動作範囲への準拠に関して評価し得る。基準は、比例解析、積分解 析、または微分解析、またはその組み合わせを用いて、検知状態の経時的な変化 を評価し得る。基準は、例えば相関技術またはファジー論理技術を用いて、検知 状態を、その他の経験的に開発された標準またはテストアルゴリズムと比較し得 る。 予測器機能３７２は、その分析に基づいて、診断出力ファイル３７４を生成す る。診断出力ファイル３７４は、システム性能傾向を示し、潜在的なシステムエ ラーまたは故障を、それが起こる前に予測する。 出力ファイル３７４は、システム状態データファイル３３６でユーザインタフ ェースタスクモジュール２３０全体を見ることに関して、例えばシステム状態デ ータファイル３３６と同じ態様で、ファイルシステムタスクモジュール２２４に より管理される。図１７は、悪い性能傾向を同定し、故障が起こる前にサービス 検査を勧める、診断出力ファイル３７４に基づく診断通知３７６の包含を示す。 その代わりに、またはそれと組み合わせて、診断出力ファイル３７４の内容は、 レポートタスクモジュール２２６を介して扱われる事象レポート３１２の項目と して含まれてもよい。 その代わりに、またはそれと組み合わせて、外部コンピュータ２０６’のイネ ーブル制御ソフトウェア３６８は、予測器機能３７２を組み込んでもよい。この 構成では、外部コンピュータ２０６’は、このコンピュータ２０６’自体の診断 通知３７６を、視覚的コピーまたはハードコピーの形で提供し得る。 説明されたデータインタフェース２０２およびグラフィカルインタフェースは 、例えば公開文献に開示されている従来のグラフィックスソフトウェアとともに WINDOWSTM開発キットにより提供されるような、例えば、MS WINDOWSTMアプリケ ーションおよび標準のWINDOWS 32 API制御を用いて実現される「Ｃ」言語プログ ラムとして実現され得る。 本発明の様々な特徴は、以下の請求の範囲に示される。A system and method for monitoring and analyzing the operation of a medical processing device Field of the invention The present invention relates to systems and methods for recording data during a fluid treatment procedure, such as a fluid treatment procedure performed by a blood treatment system or the like. Background of the Invention Today, people routinely separate whole blood by centrifugation into various therapeutic components of whole blood, such as red blood cells, platelets, and plasma. These and other medical processing devices are often controlled using a microprocessor with resident program software. Microprocessors also typically include some type of interface through which an operator sees and understands information regarding the operation of the fluid treatment system. These and other medical processing devices also often require the ability to track key control and processing parameters during the procedure, as well as the ability to track operator intervention during the procedure. These data logging features are useful, for example, to support GMP requirements, instrument troubleshooting and problem diagnosis, and instrument performance evaluation. Although the data recording function is important, it should never conflict with or interfere with the overall processing tasks and objectives of the procedure. As the operational and performance requirements for such fluid handling systems become more complex and sophisticated, there is a need to integrate, automate and enhance data recording capabilities. Summary of the Invention The present invention provides systems and methods that fully integrate data recording functions with processing functions. Thus, the same instrument that performs the processing task also performs the data recording function without the need for an add-on external data recording system. The present invention also provides systems and methods that fully automate the necessary data recording functions and that these data recording functions can be accomplished "in the background" with little operator intervention or control. The present invention also provides a robust system and method for performing data recording functions that withstand real world abuse such as power failure or corruption of stored data. This "crash-tolerant" aspect is particularly important in an embedded software system environment where power to the instrument can be turned off at any time. One aspect of the present invention provides a blood processing system and method for monitoring a hardware status condition during a blood processing procedure. The system and method generates current system data based on monitored hardware status conditions. The systems and methods generate an output that predicts at least one future hardware status condition based on an analysis of current system data generated over a period of time. In a preferred embodiment, the systems and methods process the output for printing or viewing, or for offloading to a remote station. In a preferred embodiment, the system and method writes current system data to a flash memory storage medium. Features and advantages of the invention will be apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE FIGURES FIG. 1 is a schematic diagram of a two-needle platelet collection system that includes a controller that implements features of the present invention. FIG. 2 is a schematic flow chart diagram of the controller and the associated instrument manager and graphical user interface. FIG. 3 is another schematic diagram of the controller shown in FIG. 2 and the associated instrument manager and graphical user interface, further illustrating the command and status flow hierarchy. FIG. 4 is a diagram of a two-region graphical user interface screen, showing the blocks and touch-activated fields that the interface screen contains, and showing the main menu of the work area of the interface screen. FIG. 5 is a diagram of a two-region interface screen, showing a treatment selection submenu in a work area of the interface screen. FIG. 6A is a diagram of a two-area interface screen, showing a Special Features submenu of a work area of the interface screen. FIG. 6B is a diagram of a two-area interface screen, showing the file manager submenu in the work area of the interface screen. FIG. 7 is a schematic flowchart of the controller and the associated data interface. FIG. 8 is a schematic diagram of a block file structure of the storage device of the data interface shown in FIG. FIG. 9 is a schematic diagram of a directory table having a block file structure shown in FIG. FIG. 10 is a schematic diagram of one block file space allocated in the block file structure shown in FIG. FIG. 11 is a schematic diagram of a ring file function for controlling data writing to the block file space shown in FIG. FIG. 12 is a diagram of a two-region interface screen, showing a file system information submenu in a work area of the interface screen. FIG. 13 is a diagram of the two-region interface screen, showing a file directory submenu in the work area of the interface screen. FIG. 14 is a representative treatment report that can be generated by the data interface shown in FIG. FIG. 15 is a representative event report that can be generated by the data interface shown in FIG. FIG. 16 is a diagram of the two-region interface screen, showing the treatment report print submenu in the work area of the interface screen. FIG. 17 is a diagram of the two-area interface screen, showing the log viewer submenu of the work area of the interface screen. FIG. 18 is a diagram of the two-region interface screen, showing the system configuration submenu of the work area of the interface screen. FIG. 19 is a diagram of a two-region interface screen, showing a configuration submenu for a work area on the interface screen. FIG. 20 is a schematic diagram of the predictor function of the data interface. FIG. 21 is a schematic diagram of the import configuration function of the data interface. The present invention may be embodied in several forms without departing from the spirit or essential characteristics of the invention. The scope of the invention is defined by the appended claims, rather than by the specific description set forth before the appended claims. Therefore, all embodiments that come within the equivalent meaning and scope of the claims are intended to be embraced therein. Description of the preferred embodiment FIG. 1 shows a fluid treatment system 10 in a schematic form. System 10 may be used to process various fluids. The system 10 is particularly well-suited for processing fluids for medical purposes, such as whole blood and suspensions of biological cellular material. Thus, the illustrated embodiment shows a system 10 used for this purpose. I. Separation system System 10 includes an array of durable hardware elements. Hardware elements vary according to the nature and type of processing system. In the context of whole blood processing, the hardware elements include the centrifuge 12. In the centrifuge 12, whole blood (WB) is separated into various therapeutic components such as platelets, plasma, and red blood cells (RBC). Hardware elements also include various pumps (shown as P1-P4), which are typically peristaltic pumps, and various in-line clamps and valves (shown as V1-V3). Of course, there are also typically other types of hardware elements not shown in FIG. 1, such as solenoids, pressure monitors, and the like. System 10 also typically includes some form of disposable fluid treatment assembly 14 used in connection with hardware elements. In the blood processing system 10 shown, the assembly 14 includes a two-stage processing chamber 16. In use, the centrifuge 12 rotates the processing chamber 16 to centrifuge blood components. The configuration of the two-stage processing chamber 16 may be changed. For example, processing chamber 16 may take the form of a double bag, such as the processing chamber shown in U.S. Pat. No. 4,146,172 to Cullis et al. Alternatively, the processing chamber 16 may take the form of an elongated two-stage inner bag, such as the bag shown in Brown US Pat. No. 5,370,802. In the blood processing system 10 shown, the processing assembly 14 also includes an array of flexible tubing that forms a fluid circuit. The fluid circuit carries liquid to and from the processing chamber 16. Pumps P1-P4 and valves V1-V3 engage this tubing and govern the fluid flow in a predetermined manner. The fluid circuit further includes a number of containers (shown as C1-C3) for distributing and receiving liquid during processing. The controller 18 governs the operation of the various hardware elements and performs one or more processing tasks using the assembly 14. The present invention specifically relates to important attributes of the controller 18. System 10 may be configured to accomplish various types of blood separation processes. FIG. 1 shows a system 10 configured to perform an automatic two-needle platelet collection procedure. In the collection mode, the first tube branch 20 and the whole blood inlet pump P2 direct WB from the retraction needle 22 to the first stage 24 of the processing chamber 16. On the other hand, the auxiliary pipe branch 26 meters the anticoagulant from the container C1 and sends it to the WB flow via the anticoagulant pump P1. Container C2 holds a saline solution. Another auxiliary pipe branch 28 carries this saline solution to the first pipe branch via the in-line valve V1 for use in priming and purging air from the system 10 before processing begins. A saline solution is also introduced after the treatment is over to flush residual components from the assembly 14 back to the donor. The decoagulated WB enters the first stage 24 of the processing chamber 24 and fills the first stage 24. Thus, the centrifugal force generated during rotation of the centrifuge 12 separates WB into red blood cells (RBC) and platelet-rich plasma (PRP). The PRP pump P4 operates to draw PRP from the first stage 24 of the processing chamber 16 to the second pipe branch 30 and transport it to the second stage 32 of the processing chamber 16. There, PRP is separated into platelet concentrate (PC) and platelet-poor plasma (PPP). System 10 includes a recirculation pipe branch 34 and an associated recirculation pump P3. The process controller 18 operates the pump P3 to divert a portion of the PRP exiting the first stage 24 of the processing chamber 16 and remix it with the WB entering the first stage 24 of the processing chamber 16. . When the WB is drawn into and separated from the first chamber stage 24, the two-needle system shown simultaneously removes the RBCs from the first chamber stage 24 along with the portion of the PPP from the second chamber stage 32 into a tube. The blood is returned to the donor via the return needle 36 via the branches 38 and 40 and the in-line valve V2. The system 10 also collects PCs in some of the containers C3, via the tubing branches 38 and 42 and the in-line valve V3, for storage and treatment. System 10 may also collect PPC in some of containers C3 via the same fluid path. II. System controller Controller 18 performs overall process control and monitoring functions for system 10 just described. In the preferred embodiment shown (see FIG. 2), the controller includes a main processing unit (MPU) 44. In the preferred embodiment, MPU 44 includes a Type 68030 microprocessor manufactured by Motorola Corporation, but other types of conventional microprocessors may be used. In the preferred embodiment, MPU 44 assigns MPU cycles to processing tasks using conventional real-time multitasking. Periodic timer interrupts (eg, every 5 milliseconds) preempt the running task and schedule another task that is ready to run. When rescheduling is requested, the highest priority task in the ready state is scheduled. Otherwise, the next task in the list that is ready to run is scheduled. A. Functional Hardware Control The MPU 44 includes an application control manager 46. The application control manager 46 manages the activation of the library 48 of control applications (denoted as A1-A3). Each of the control applications A1-A3 defines an action to perform a predetermined functional task using system hardware (eg, centrifuge 12, pumps P1-P4, and valves V1-V3) in a predetermined manner. I do. In the preferred embodiment shown, the applications A1-A3 exist as process software in the EPROM of the MPU 44. The number of applications A1-A3 may vary. In the preferred embodiment shown, library 48 includes at least one clinical treatment application A1. The treatment application A1 includes steps for executing one predetermined clinical treatment treatment. For illustration of the illustrated embodiment, the library 48 includes a treatment application A1 for performing the two-needle platelet collection process already described generally with respect to FIG. Of course, additional treatment applications may and will typically be included. For example, library 48 may include a treatment application (A1 ') for performing a conventional single needle platelet collection process. In the preferred embodiment shown, library 48 also includes at least one additional non-treatment application. Non-clinical procedure applications include procedures to execute system configuration or support utilities. For purposes of illustration of the illustrated embodiment, library 48 includes configuration application A2, which includes actions to allow an operator to configure default operating parameters of system 10. As will be described in more detail below, the library 48 also includes a main menu application A3, which coordinates the selection of various applications A1-A3 by the operator. Of course, additional non-clinical treatment applications may, and typically will, be included. For example, the library 48 may include a diagnostic application that includes actions to help service personnel diagnose and troubleshoot the functional integrity of the system, and may recover from an unmanageable or error condition of the system. And a system restart application that performs a complete restart of the system when it is no longer possible. The appliance manager 50 also exists as process software of the EPROM of the MPU 44. The appliance manager 50 communicates with the application control manager 46. The instrument manager 50 also communicates with a low-level peripheral controller 52 for pumps, solenoids, valves, and other functional hardware of the system. As shown in FIG. 3, the application control manager 46 sends a specific Perform_Function # command in an abstract form to the appliance manager 50 in response to a call by the activated applications A1-A3. In response to these abstract commands, the appliance manager 50 identifies one or more peripheral controllers 52 to perform its function, and compiles a hardware specific Operate_Hardware # command to Put in the command table for the peripheral controller 52. Peripheral controller 52 communicates directly with the hardware to implement hardware-specific commands generated by appliance manager 50, and causes the hardware to operate in a particular manner to execute the abstract Perform_Function # command. Communication manager 54 manages low-level protocols and communications between instrument manager 50 and peripheral controller 52. As also shown in FIG. 3, the appliance manager 50 may also return status data regarding the operational and functional states of the processing procedure to the application control manager 46. Status data is expressed, for example, with respect to fluid flow, sensed pressure, and measured fluid volume. The application control manager 46 processes and uses status data in various ways. In one method, the application control manager 46 sends the selected status data to display to the operator, as described below. Alternatively, the application control manager 46 uses the status data to monitor operating and functional states and detect abnormal system conditions that require operator intervention or system shutdown. In the preferred embodiment (see FIG. 2), the MPU 44 also includes a state manager 56 that resides in the data flow path between the appliance manager 50 and the communication manager 54. The state manager 56 also monitors status data and other operational states of the hardware to detect abnormal conditions that have not been detected or left uncorrected by the application control manager 46. Upon detecting such an abnormal condition, the state manager 56 provides fail-safe support by suspending system operation. The described control hierarchy creates an abstract “virtual” interface between the applications resident in the application control manager 46 and the hardware elements of the system 10. The high-level process software residing on the application control manager 46 communicates with the lower-level implementation processes of the instrument manager 50 instead of communicating directly with the hardware elements. In this manner, intermediate instrument manager 50 isolates or “hides” all of the hardware-specific commands from application control manager 46. The application sends an abstract Perform_Function # command to the instrument manager 50, and the instrument manager 50 sends these abstract commands, without any further involvement of the treatment applications A1-A3 itself, to a specific hardware element-specific implementation. Convert to an Operate_Hardware # command. The data flow between the appliance manager 50 and the hardware elements of the system 10 is not visible to the activated applications A1-A3. Creating a virtual interface between high-level process software and hardware elements provides considerable flexibility when adding or modifying process software for high-level applications A1-A3 to control hardware functions. . New or modified process software for the application may include a specific abstract Perform_Function # command that is not hardware specific to obtain an immediate link to the virtual hardware interface. Similarly, the addition or modification of specific hardware requires only a change to the instrument manager 50 low-level process software. Due to the virtual interface, hardware changes require minimal changes to the application control manager 46 high-level software. As mentioned above, the appliance manager 50 forms part of the same MPU where the application control manager 46 resides. Alternatively, due to the virtual nature of the interface, the appliance manager 50 may reside in a separate processing unit. B. User Interface Control In the embodiment shown, MPU 44 also includes an interactive user interface 58. Interface 58 allows an operator to view and understand information about the operation of system 10. Interface 58 also allows an operator to select an application that exists in application control manager 46 and allows the operator to change certain features and performance criteria of system 10. The interface 58 includes an interface screen 60 and, preferably, an audio device 62. The interface screen 60 displays information for the operator to view as a graphic image in an alphanumeric format. The audio device 62 provides an audible prompt to obtain the operator's attention or acknowledge the operator's actions. In the preferred embodiment shown, the interface screen 60 also serves as an input device. As described below, interface screen 60 receives input from an operator via conventional touch activation. Alternatively or in combination with touch activation, a mouse or keyboard may be used as an input device. Interface controller 64 is in communication with interface screen 60 and audio device 62. Interface controller 64 also communicates with interface manager 66, which also communicates with application control manager 46. The interface controller 64 and the interface manager 66 exist as process software of the EPROM of the MPU 44. In use, the application control manager 46 sends specific field values reflecting selected status data received from the appliance manager 50 to the interface manager 66. The application control manager 46 also sends to the interface manager 66 the predetermined Abstract Create_Display # and Create_Audio # commands required by the activated application. The interface manager 66 processes these field values and the abstract Create_Display # command to generate a specific Format_Display # command. The Format_Display # command controls the specific formats, attributes, and protocols required to create, refresh, and close the visual display on interface screen 60. Similarly, the interface manager 66 processes the abstract Create_Audio # command to generate a specific Format_Audio # command. The Format_Audio # command indicates the format and attributes of the audio output required by the activated application. The interface manager 66 transmits the processed Format_Display # and Format_Audio # commands to the interface controller 64. The interface controller 64 provides low-level control for drawing boxes and lines, forms text or graphic characters, and provides display attributes and formatting on the interface screen 60. The interface controller 64 also provides a low-level control function for driving the audio device 62 based on the Format_Audio # command received from the interface manager 66. As described in more detail below, interface controller 64 also accepts a Field # _Select command generated by touch activation of interface screen 60. The interface controller 64 sends the touch-activated input to the interface manager 66 in the form of Touch # _Codes. The interface manager 66 processes Touch # _Codes and sends them to the application control manager 46 as either function codes or change field values. The application control manager 46 implements the function codes or change field values and sends them to the instrument manager 50. This control hierarchy also creates an abstract “virtual” interface between the interface 58 and the functional processor of the controller 18. The high process software of the interface manager 66 isolates and “hides” all of the formatting and protocol issues used in creating the interface 58 from the applications used to control the hardware functions of the system 10. The process software of the applications A1 to A3 sends the abstract field value and the abstract Create_Display # and Create_Audio # commands to the interface manager 66 via the application control manager 46. The process software of the interface manager 66 converts these abstract commands into concrete commands without further involvement of the treatment applications A1 to A3 themselves. The specific commands control the text and graphic format and the audio format of the operator interface 58. The data flow between interface manager 66 and interface screen 64 is invisible to the data flow between application control manager 46 and instrument manager 50. This control hierarchy provides additional flexibility when adding or modifying applications to control hardware functions. The new or modified application may include a text field value output and a predefined Create_Display # or Create_Audio # command to get an immediate link to the operator interface. i. Interface Screen Format In the preferred embodiment shown (see FIG. 4), the Format_Display # command of the interface manager 66 displays on the interface screen 60 in two different viewing areas called status area 68 and work area 70. Format the information for Preferably, these two viewing areas 68 and 70 are fixed in relative position and remain the same size on the interface screen 60. This provides continuity and consistency in the appearance of interface 58 even when the functional hardware of the system cycles through different processing modes. The uniformity and consistency of the dual viewing areas 68 and 70 of the interface 58 reduce the likelihood of operator confusion and errors. Each of status area 68 and work area 70 is dedicated to a different type and level of information. Nevertheless, these two regions 68 and 70 are always displayed at the same time, providing the operator with both high-level "large picture" information and low-level "detail" information views. The work area 70 provides a means for the operator to select and activate any one of the system resident applications A1 to A3. The work area 70 displays all the action-dependent specific information later requested by the Create_Display # command generated by the activated applications A1 to A3. The considerable details of the information displayed in work area 70 allow an operator to monitor and change the ongoing process in real time. The status area 68, on the other hand, is a treatment-dependent predetermined information of a more general and "schematic" nature, constantly showing information that the operator routinely needs to display and access immediately. Even when the operator is using the work area 70 to monitor and change more detailed aspects of the process, the status area 68 constantly displays this general information to provide the operator with an overall view of the ongoing process. Continue to evaluate status. In the preferred embodiment shown, status area 68 also provides a means for the operator to respond to alarms or malfunctions. These two viewing areas 68 and 70 allow the operator to quickly use the interface 58 to find and select detailed procedures, functions and options during system operation, or Can perform offline functions without losing contact with the overall status of the procedure in progress. The two viewing areas 68 and 70 allow the operator to navigate through what is actually a multi-level menu structure, without having to step up and down the menu structure, and at a higher menu level as commands occur. Allows to focus on the details about one menu level without losing the ability to jump quickly between and a lower menu level. In the embodiment shown, the viewing areas 68 and 70 are vertically separated by graphic or character character lines 72, and the status area 68 occupies the upper third of the screen 60 and the work area 70 Occupy the lower two-thirds of screen 60. However, it should be appreciated that viewing areas 68 and 70 may be separated horizontally in a side-by-side relationship and may occupy different proportions of screen 60. The status area 68 and the work area 70 display information in fields. The Format_Display # for a particular display, generated by the interface manager 66, consists of a list of such fields. The list specifies, for each field, its location, size, and the format and type of information the field contains in the area. As described in more detail below, the fields may be formatted as individual touch selectable buttons. The fields can also be formatted as an array of touch-selectable button fields that give the operator a field of choice. Fields can also be formatted as blocks containing alphabetic or numeric data strings, or text data containing multiple lines of line-wrapped scrollable text, or graphic images. . The field can also be formatted to be a bar chart field that displays the numeric format in the form of a graph. The interface manager 66 contains certain (ROM-based) structures, in the form of look-up tables, that store data describing the layout and formatting of all display attributes. The display attributes include an area, a field type, and a field position in the area. The interface manager 66 stores a dynamic (RAM-based) structure that describes the current state of the interface display. Upon receiving a predetermined Create_Display # command from the activated application, the interface manager 66 examines the ROM-based table structure and the RAM-based status structure as requested by the activated application, and Create or update a structure. Interface manager 66 includes time-triggered task routines that perform all operations required to periodically update screen 60 and audio output. The interface manager 66 sends this processed information to the interface controller 64 to realize it. The interface manager 66 also maintains a Function # _Code associated with each touch selectable button field identified by the Touch # _Code received from the interface controller 64. The Function_Codes are arranged in a fixed (ROM-based) look-up table according to the region identified by Touch # _Code and the field position within the region. When a predetermined button is touched, the interface controller 64 registers the area and the field position, and sends this information to the interface manager 66 in the form of Touch # _Code. Interface manager 66 includes a process button utility. The process button utility waits for this information and processes this information asynchronously by consulting the ROM-based table structure and sending the appropriate Function # _Code to the application control manager 46 for implementation. The information and format selected for display in status area 68 and work area 70 may vary. a. Status Area In the embodiment shown (see FIG. 4), the status area 68 includes a major mode field 74 containing a description of the activated clinical procedure, and a minor mode field containing a one or two word description of the procedure status. 76 and a processing WB field 78 containing a value numerically expressing the amount of blood drawn from the donor through the drawing pump P2 during processing in ml. In the embodiment shown (FIG. 4), status area 68 also includes an array of touch-selectable button fields, shown as, for example, help 80, main menu 82, action display 84, and pause / end 86. . As each field is touched, interface manager 66 sends a predetermined function code for implementation by application control manager 46 without changing the display of information in block fields 74/76/78 of status area 68. Status area 68 also includes a context-sensitive attention / warning prompt button field 88. The attention / warning prompt button field 88 occupies a fixed position on the right side of the status area 68, ie, the topmost location, when an alarm or warning is active. The attention / warning prompt button field 88 is not displayed when an alarm or warning is not active. The mute button field 90 also occupies a fixed position on the left side of the status area 68, ie, the topmost position, when the alarm is active. The attention / warning block field also occupies a central fixed position in the status area, ie, the bottom place when the alarm is active. b. Work Area In the preferred embodiment shown, the work area 70 shows by default the main menu display required by the main menu application A3. The main menu display includes an array of touch-selectable button fields 94 and 96. When touching the treatment selection button field 94, this field 94 calls a function for displaying a treatment submenu in the work area 70 (see FIG. 5). The treatment submenu lists all clinical treatment applications managed by the application control manager 46 in an array of touch-selectable button fields 104 and 106. In the illustrated embodiment, the clinical treatment applications are a two-needle treatment application A1 and a single-needle treatment application A1 '. Touching the action application button field, this button field instructs the application control manager 46 to activate the associated application. The activated application generates a specified Create_Display # command for the application itself. The interface manager 66 implements the Create_Display # command to change the display in the work area 70. When touching the special feature button field 96, the button field 96 calls a function for displaying a special feature submenu in the work area 70 (see FIG. 6). The features submenu lists the specified applications that are managed by the application control manager 46 that are not specific to a clinical procedure, in an array 200 of touch-selectable button fields. Touching a predetermined special action application button activates the application, and the display in the work area 70 changes in response to the Create_Display # command of the activated application. Further details of the particular button in field 200 are provided below. Further details of the described controller 18 and graphical user interface manager 66 can be found in US Pat. No. 5,581,687. The above US patents are incorporated herein by reference. C. Data Interface In the preferred embodiment shown (see FIG. 7), the controller 18 also includes a data interface 202. The data interface 202 constitutes a self-contained integral part of the software and hardware architecture of the controller 18. Data interface 202 automates the collection, retention and operation of key control and processing parameters and operator steps during a given processing application. Data interface 202 holds information in the data structure of mass data storage device 204. Mass data storage 204 also forms an integral part of controller 18. The data structure of the storage device 204 allows information to be stored, retrieved, and manipulated in a secure manner to withstand fraud from accidental power loss. The data structure of the storage device 204 also allows the stored information to be retrieved and formatted into printed reports. The data interface 202 may also be linked to one or more external computers 206 and 206 'if desired, but this is not required for the operation of the data interface 202. As described in more detail below, data interface 202 may download the stored information to computers 206, 206 ', either in a configured order or in any order. Data interface 202 may be implemented in various ways. In a preferred embodiment, mass storage device 204 includes a flash memory card, such as, for example, a flash memory card conforming to the PCMCIA Type II PC Card ATA standard hardware interface. Conventionally, flash memory card device 204 may support a storage range of 2 to 85 megabytes. In a typical implementation, storage device 204 may hold approximately 8 megabytes of data. Flash memory storage device 204 is more suitable for use with integrated data interface 202 as compared to conventional hard drive storage media. The flash memory device 204 provides ease of formatting and fast data access time. The flash memory device 204 exhibits a small, compact size that does not compete with space for blood processing hardware. The flash memory device 204 has no mechanical components and is therefore very reliable and less prone to failures due to repeated use. The flash memory device 204 is also durable and withstands the vibrations and other forces that the centrifugal blood processing device generates during blood processing procedures. Flash memory device 204 is also easy to service and replace on-site. Data interface 202 also includes additional hardware input / output devices 208, 210, 212 and 348. These hardware input / output devices may take the form of, for example, a conventional serial RS-232C port link. Conventional parallel port link and one or more Ethernet TM Other input / output devices, such as communication links, may be used. In the embodiment shown (see FIG. 7), one port link 208 communicates with an external barcode scanner 214. The second port 210 communicates with one of the external computers 206 described above. Third port link 212 communicates with external printer 216. The fourth port link 348 communicates with the other external computer 206 '. Data interface 202 also includes various process software modules 218-230 that reside in the EPROM of MPU 44. The process software modules 218 to 230 execute predetermined data processing tasks. The number and type of software modules 218-230 may vary. In the embodiment shown, one module 218 implements the communication manager task. The communication manager task module 218 handles lower level data transfers to and from the RS-232C port links 208, 210, 212 and 348. The communication manager task module 218 prevents the MPU 44 from transferring data faster than can be transmitted by the respective RS-232C port links 208, 210, 212 and 348. Another module 220 implements a barcode task. Barcode task module 220 receives raw ASCII data input from barcode scanner 214, received via barcode scanner port link 208. The barcode task module 220 parses the scanned data and assembles it into inputs that are compatible with another module called the action driver task module 222 described in more detail below. The action driver task module 222 also verifies that the scanned data has registered the scanned input, and once verified, the barcode task module 220 returns a feedback message, as described below. Format the output 232. The data interface 202 also includes other core processing modules that implement the treatment driver task, file system task, report task, data exchange task, data dump task, and user interface task, respectively. Next, details of the above task will be described. i. Treatment Driver Task The treatment driver task module 222 receives information from the application control manager 46 and the barcode task module 220. The procedure driver task module 222 provides, via the application control manager 46, specified control and status information that is key to the then ongoing procedure, and other functions of the pumps, solenoids, valves, light detectors, and systems. Register the specified control and status information that is the key for the hardware. The action driver task module 222 generates data including this registration information along with a date stamp and provides a time-based context. The data is structured byte streams that are further processed by the file system task module 224 to store, retrieve, or manipulate. The nature and type of data generated by the action driver task module 222 may be changed. a. Procedure Data (P Data) In the embodiment shown, the procedure driver task module 222 registers all scanned barcode entries. The barcode entry may include, for example, information identifying the donor, the processing device, and the disposable components used for processing. The procedure driver task module 222 also provides these processing parameters from the application control manager when key processing parameters and blood component yield values are initialized and updated during the procedure. And all the yield values of blood components. The action driver task module 222 also registers any processing mode changes and any warning alarms that have occurred. In the illustrated embodiment, the treatment driver task module 222 also registers designed special treatment events, such as, for example, starting and stopping needle priming, and pausing and resuming treatment. The action driver task module 222 establishes and maintains a random access data file called Act_Proc_Data (shown as 234 in FIG. 7). The contents of the Act_Proc_Data file 234 include the selected control and processing parameters. In the embodiment shown, the Act_Proc_Data file 234 is a fixed length file that is formatted as a template to hold the data in a predetermined order. The active treatment data is periodically (for example, every 15 seconds) written to the designated location of the template in the Act_Proc_Data file 234. Thus, the current Act_Proc_Data file 234 reflects the real-time status of the significant control and processing parameters and data for the then ongoing procedure. The parameters and data maintained by the Act_Proc_Data file 234 may include, for example: (I) Donor identification information (eg, the assigned donor I.D. D. Number, donor sex and weight, assigned blood donation D. (Ii) identification of the equipment and disposable components used for processing (eg, according to the assigned equipment number and disposable kit code, lot number, and expiration date), (iii) ) Obtained initial processing parameter values (eg, anticoagulant ratio, platelet precounts, whole blood hematocrit, whole blood volume processed, volume of plasma collected, platelet yield (yield) Average platelet volume, stored volume of plasma for collected platelets, volume of citrate returned to the donor, etc.), and (iv) active treatment data (eg, anticoagulation used) Agent and saline, anticoagulant and saline present in product plasma and stored plasma, collection time of treatment, amount of WB processed, retraction The total amount of the WB, total plasma storage amount, and the collected plasma product). In the illustrated embodiment, at the end of the procedure (and, if desired, periodically (eg, every 15 seconds) during the procedure), the procedure driver task module 222 generates the time stamped procedure data 236. I do. This data 236 is abbreviated as "P data" in FIG. The treatment data 236 is a snapshot of information currently held in the Act_Proc_Data file 234 at that time. The treatment data 236 is formatted according to the template of the Act_Proc_Data file 234. Current treatment data 236 includes a list of key donor data, equipment and disposable data, target treatment values, and actual treatment values. FIG. 14 illustrates, in a report format, the nature and type of information contained in an exemplary treatment data file 236, as described below. The treatment driver sends the generated treatment data 236 to the file system task module 224, which processes the data in the specified secure file structure of the storage device 204, stores, retrieves, and stores the data. Perform the operation. Further details of the file system task module 224 are described below. b. Event Data (E Data) During the course of an action, the action driver task module 222 may also generate other discrete types of data. For example, in the illustrated embodiment (see FIG. 7), the treatment driver task module 222 generates time stamped event data 238 periodically. The time stamped event data is collected to create a chronological record of the processing event that is a key. Event data 238, abbreviated as "E data" in FIG. 7, may be generated in response to the occurrence of a key event. Key events include, for example, recording the start of treatment, installing disposable components, entering processing parameters, priming, entering data scanned by barcode scanner 214, alarm conditions and resolution, and ending treatment. ,and so on. Other event data 238 may also be generated periodically (eg, every 15 seconds) to provide the current processing parameters at that time. The processing parameters are, for example, the volume of whole blood to be processed, the whole blood flow rate, the whole blood inlet pump pressure, the red blood cell return pump pressure, and the like. The action driver task module 222 sends the event data 238 to the file system task module 224. As described in more detail below, the file system task module 224 incorporates the event data 238 into the specified file structure of the storage device 204. The stored system event data 238, when arranged in chronological order by file time stamp, includes a chronological record of significant treatment events and states. FIG. 15 illustrates, in a report format, the nature and type of information contained in a compilation of the representative event data file 238, as described below. c. System State Data (S Data) In the illustrated embodiment (see FIG. 7), during the course of system operation, the system task also generates time stamped system state data 336. This data 336 is abbreviated as “S data” in FIG. 7 as described above. The system status data represents a pre-selected status, status or error condition for pumps, solenoids, valves, light detectors, and other functional hardware of the system under the control of the appliance manager 50. The action driver task module 222 sends the system state data 336 to the file system task module 224. As described in more detail below, the file system task module 224 incorporates the system state data 336 into the specified file structure of the storage device 204. Stored system state data 336 includes a chronological record of significant states regarding system hardware during the course of the procedure. FIG. 17 illustrates the nature and type of information contained in a compilation of representative system state data 336 when formatted for viewing by an operator, as described below. d. Dump Sensor Data (D Data) In the illustrated embodiment (see FIG. 7), the treatment driver task module 222 periodically (eg, every 5 seconds) separate time stamped dump sensor data during the course of a treatment. Generate 350. This data 350 is abbreviated as "D data" in FIG. Dump sensor data 350 is a snapshot of the current sensed value recorded by state sensing hardware coupled to controller 18. Condition sensing hardware may monitor, for example, inlet and outlet pump pressures, blood collection container weights, and light transmission values detected by photodetectors. The treatment driver task module 222 sends the dump sensor data 350 to the file system task module 224. As described in more detail below, the file system task module 224 incorporates the dump sensor data 350 into a specified file structure of the storage device 204. The dump sensor data 350 includes a chronological record of the detected state monitored during the course of the predetermined treatment. ii. File System Task The file system task module 224 provides file services to the action driver task module 222, the data exchange task module 228, and the report task module 226. File system task module 224 provides an interface for storing, retrieving, and manipulating treatment data 236, event data 236, system status data 336, and dump sensor data 350. As shown in FIG. 8, the file system task module 224 includes a block device function 240. Block device function 240 formats medium 242 of storage device 204 to have N blocks. Each block is addressable by a number starting from 0 and ending with N (but not including N) (N = 43 in FIG. 8). The format structure includes a root node 244 occupying block 0, along with a redundant copy 244C of block 1. The format structure further includes a directory node 246 occupying one or more blocks beginning with block 2. The format structure allocates the remaining blocks up to, but not including, N as space for various data 236, 238, 336, and 350 generated by the procedure driver task module 222. Block device function 240 statically divides the remaining blocks into separate file spaces. Each of these file spaces is allocated to accept one type of data 236, 238, 336 or 350. FIG. 8 shows, for illustrative purposes, four file spaces 248, 250, 252 and 254 for four types of data 236, 238, 336 and 350, respectively. However, typically more blocks are available and thus additional file space may be allocated. Each of the file spaces 248, 250, 252 and 254 includes an adjacent block range. In the embodiment shown (FIG. 8), each of the file spaces 248, 250, 252 and 254 has the same maximum size of 10 blocks for illustrative purposes. However, the data 236, 238, 336 and 350 may impose different size requirements, and the file spaces 248, 250, 252 and 254 typically have different maximum sizes. a. Root Node Root node 244 identifies the name of the file system and describes the overall layout geometry imposed by the runtime code. The root node 244 specifies the total capacity of the file system in units of blocks, and specifies the maximum number of fixed-size files that can be used, that is, how many file spaces are statically allocated (as shown in FIG. In the embodiment, four) are specified. Root node 244 also includes a copy of the template used by treatment driver task module 222 to create treatment data 236. This template is stored in the root node 244 mainly for providing information. Nevertheless, the stored template may be used as a reference for restoring the file system in the event of complete damage. The root node 244 does not contain any modifiable information. Once the file system is created, root node 244 is not modified. An identical copy 244C of root node 244 is maintained in block 1 in case block 0 becomes unreadable. b. When the media 242 is formatted by the directory node blocker function 240, the media 242 is capable of accommodating a fixed number of file spaces, each having a fixed predetermined maximum size. Directory node 246 includes a directory table 256 for formatted file spaces 248, 250, 252 and 254. As illustrated in FIG. 9, directory table 256 lists the starting block address and fixed size of each file space. Table 256 includes directory elements 258 or "slots" for all pre-allocated file spaces of the file system (there are four in the embodiment shown). Each directory element 258 includes a pre-allocated block number (ie, address) of the file space and a numerical value representing the pre-allocated size of the file space in units of blocks. As described herein, the block numbers or addresses held in directory table 256 refer to logical file system block addresses. The logical file system block address may or may not correspond to a physical media block address. Directory table 256 contains only one directory level. That is, the directory table 256 is not hierarchical. Directory table 256 is also not dynamic. Once the file system is created, the directory table 256 is not modified. Table 256 merely serves to provide a static pointer to the allocated file space location. Directory table 256 also does not indicate whether the pre-allocated file space contains data or is available. Dynamic allocation information is maintained on byte stream data written to file space. That is, the presence / absence of data itself provides allocation information about the file space. The described file system task module 224 maintains the integrity of the block file system structure in the event of a power failure or any data corruption on the storage device 204. In the face of such abuse, the file system task module 224 does not lose the basic block structure of the file system and does not require a separate file system recovery operation to be performed. Each file space 248, 250, 252 and 254 has a certain maximum size, and the file space cannot be increased to accommodate more data. Any allocation of file space that does not match the directory table 256 can be fixed quickly. Block device function 240 also includes a hard security check that does not allow writing to block numbers smaller than the initial pre-allocated file space once the file system is created. During file system creation, only the lower numbered blocks are activated for writing. Therefore, there is little possibility that a software bug will destroy a directory block. Since the directory block is static, there is little possibility that the directory block will be destroyed by a write error during a power failure. c. Data Space As FIG. 10 shows, each of the file spaces 248, 250, 252 and 254 includes a primary node 260. Primary node 260 includes metadata associated with the file space (ie, assigned or free file names, creation times, current sizes, etc.). Each file space also includes a secondary node 262. Secondary node 262 has the same content as primary node 260. This is used for "flip-flops" while updating the file's metadata, as described below. Each of the file spaces 248, 250, 252 and 254 also includes a pre-allocated physical space 264 of the file. Space 264 receives the data content of assigned treatment data 236, event data 238, system state data 336, or dump sensor data 350. Block device function 240 does not perform random access writes. Block device function 240 either reads and writes all blocks addressed by the starting block number, or continuously appends data forward in file space until file space is filled. Enable. As implemented in the illustrated embodiment, at the beginning of a given procedure, one file space 248 is reserved for treatment data 236 generated during the procedure and one file space 250 is allocated during the procedure. Is reserved for all event data 236 that is generated. Upon initial boot-up of data interface 202, one file space 252 is designated for system state data 336 for all subsequent actions, and one file space 254 is reserved for all subsequent actions. Designated for dump sensor data 350. As described in more detail below, file spaces 252 and 254 hold a ring file to which the newest designated data 336 and 350 are appended, overwriting the oldest data. (1) Treatment data file space The maximum size of the treatment data file space 248 to be reserved is selected so that the entire template of the treatment data 236 and a backup copy (described below) can be accommodated with a margin. In an exemplary embodiment, about 5. A maximum file size of 6 kilobytes is reserved. The reserved treatment data file space 248 receives initial treatment data 236 generated by the treatment driver task module 222 at the beginning of the treatment. Subsequent treatment data 236 generated by the treatment driver task module 222 during the course of the treatment is written as a block to the same treatment file space 248 starting at a logical offset of zero in the file space 248, so that the entire previous treatment data Overwrite. Conceptually, the treatment data 236 in the file space 248 is periodically “refreshed” as the treatment progresses until the treatment is complete, leaving the treatment data 236 last written in the space 248. (2) Event data file space The maximum size of the event data file space 250 reserved is to allow for all event data 238 generated during a typical procedure and a backup copy (described below). Selected to accommodate. In an exemplary embodiment, about 66. A maximum file size of 5 kilobytes is reserved. The reserved event data file space 250 receives initial event data 238 generated by the action driver task module 222 at the beginning of an action at a logical offset of zero. The next event data 238 is appended to the end of the file (EOF) point of the first event data 238. Subsequent event data 238 is added in this manner until the physical data space 250 is filled. After the physical data space 250 has been filled, no further event data can be recorded for the procedure. Should the data space 250 be filled to its fixed capacity, the file system task module 224 generates a message output to the user interface task module 230 (described below). The evaluation of the maximum size of the event data file space 250 should be done with care, to ensure that event data is not lost near the end of a given action. Block device function 240 also provides the ability to generate an atypical number of event data to designate a second event file space in the event that an atypical action that fills first event file space 250 occurs. , May be included as a backup. (3) System state data file space and dump sensor file space (ring file) In a similar manner, the block device function 240 stores the system state data 336 and the dump sensor data 350 in the designated reserved file spaces 252 and 254, respectively. , And these data 336 and 350 are subsequently added. However, unlike the file space 250, which does not allow further data entry once its physical data space is filled, the block device function 240 uses the system state data 336 and dump sensor data 350 to the respective fixed file spaces 252 and 254. Includes a function 266 that accepts successive additions. This function 266 treats the fixed physical allocation space 264 of these spaces 252 and 254 as a circular ring or ring file 268 (see FIG. 11). In the ring file 268, when the file space 264 is filled, the oldest data 270 is overwritten with new data 272. The ring file function 266 first appends all data generated by the procedure driver task module 222 during a given procedure (in FIG. 11, for example purposes, system state data 336) to the designated file space 264. I do. Because data 336 is continuously written to designated file space 264, the size of ring file 268 starts at zero for the first data 336 and fills file space 264 as additional data 336 is added. Up to. At this point (see FIG. 11), the ring file function 266 begins the old data 270 with the first node assigned to the data in the file space 264 (ie, the primary and secondary nodes 260 and 262 with metadata). "Wrap" the data by overwriting it with new data 272 (later). The ring seam 274 separates the oldest data 270 in the file space 264 from the newest data 272 in the file space 264. As new data 272 enters file space 264, ring seam 274 constantly moves toward the end of the pre-allocated space (as indicated by arrow 276 in FIG. 11). Once the end of the file space 264 is reached, the ring seam 274 circulates to the first data node and again moves forward toward the end of the file space 264. After the data is first covered in file space 264, ring file function 266 maintains logical ring seam pointer 278. The ring seam pointer 278 indicates the block address of the ring seam 274. The ring file function 266 also places the logical file end pointer 280 of the file at the block address indicating the logical connection between the newest data 272 and the ring seam pointer 278. The ring seam function 266 also places a logical offset zero pointer 282 at the block address indicating the logical connection between the oldest data 270 and the ring seam pointer 278. After the data is first covered, the ring seam function 266 appends the data starting at the logical end of the file pointer 280. As the appended data is written to file space 264, ring seam function 266 advances logical offset zero pointer 282 along with ring seam pointer 278. The fixed maximum sizes of the system state data file space 252 and the dump sensor data file space 254 are chosen to accommodate the expected compiled data and backup copies (described below). . In an exemplary embodiment, the system state data file space 252 reserves a maximum file size of about 100 kilobytes, and the dump sensor data file space 254 reserves a maximum file size of about 1 megabyte. (4) File Space Integrity The block device function 240 automatically creates backup copies of the data 236, 238, 336 and 350 written to the file spaces 248, 250, 252 and 254, respectively. Further, the data structure of all allocated file spaces is protected on a block-by-block basis by a 16-bit CRC. This allows the block device function 240 to detect whether the block was successfully written and, when read back, whether the block is valid. If the block is found to be invalid for any reason, such as a CRC mismatch, the block unit function 240 checks the backup copy of the block. If the backup copy is valid, block device function 240 continues with the data in the backup copy. Alternatively, the backup data may be used to recover a damaged block. The most dynamic aspect of the file system is the file node 260 in a given file space. Whenever data is added to or written to a file space, the file space metadata must be updated. The last modification time must be updated to the current time. Once added, the logical size of the file must be increased by the amount of data added. The current read or write location must also be updated to indicate where the next read or write operation should take place. Because file node 260 is updated very frequently, and because file node 260 is so important when accessing files, each of file spaces 248, 250, 252 and 254 has a secondary file node 262. Each of the file nodes 260 and 262 has an "age" marker that is initialized to zero when a new file is created in the file space. Each time the file nodes 260 and 262 in the file space are modified, the file node's age marker is incremented. Whenever the file's metadata must be updated, the block driver function 240 registers the file node's age marker. If the age marker is even, the primary file node 260 is modified. Conversely, if the age marker is odd, the secondary file node 262 is modified. This causes writes to file nodes 260 and 262 to be “flip-flopped” between primary file node 260 and secondary file node 262. If the device block function needs to read a file node, the device block function reads both the primary and secondary file nodes 260 and 262, validating the file node with the largest "age" marker. Think. This allows the file node update operation (ie, writing to the file node) to experience a hardware failure that destroys the entire file node. Another file node always contains an older, but consistent, state of the file. The ability to withstand abuse is inferior to the data contained in each of the treatment data 236 or the event data 238. The responsibility of the action driver task module 222 and the file system task module 224 is to maintain data integrity. However, in general, if data is appended in the forward direction, data loss occurs at the end of the file. Therefore, if an error occurs in the append operation, the error affects only the most recently added data corresponding to a relatively small portion of the entire file. The file system task module 224 maintains file integrity without resorting to traditional complex database management functions such as a journaling-file systems or a commit-rollback transaction facility. . By not increasing the formatted file space, the file system task module 224 requires only minor modifications to the file system metadata when data is written. File system task module 224 does not rely on file directories to dynamically point to where each file is located. The file system task module 224 does not move blocks containing file system data and does not update pointers to point to the new locations of these blocks. The file system task module 224 removes blocks from the free pool and attaches them to the file, thereby not dynamically expanding the size of the file, or dynamically returning blocks of the file to the free pool and removing the file from the file directory. Do not unlink The file system task module 224 minimizes the window of time when the file system is being dynamically changed and the file system is susceptible to catastrophic data corruption due to power failure. By minimizing the time susceptible to catastrophic data corruption, the file system task module 224 minimizes the likelihood of catastrophic data corruption in the event of a power failure. iii. User Interface Task (File System Task Support) The user interface task module 230 links the file system task module 224 and the report task module 226 to the previously described interface manager 66. The user interface task module 230 sends an abstract Create_Display # command specified to support the data interface 202 to the interface manager 66. The interface manager 66 processes the Create_Display # command of the data interface 202 and generates a specific Format_Display # command. As previously described, the Format_Display # command controls the specific formats, attributes, and protocols required to create, refresh, and close the visual display on interface screen 60. Thereby, the user interface task module 230 provides the data interface 202 with a graphical user interface. In the embodiment shown (see FIG. 4), the main menu display, shown by default in the work area 70 of the screen 60, includes a special feature button field 96. When touching the special feature button field 96, this field 96 invokes a function to display a special feature submenu in the work area 70, as shown in FIG. 6A. The feature submenu is listed in an array 200 of touch selectable button fields. One of the button fields in the special features submenu, 284, is shown as diagnostic. Pressing the diagnostic button field 284 causes the user interface task module 230 to generate a predetermined Create_Display # command in the interface manager 66, which in turn generates a Format_Display # command, as shown in FIG. 6B. Thus, the file manager submenu is displayed in the work area 70. The file manager submenu is listed in an array 352 of touch selectable button fields. One of the button fields, 354, is shown as a file system utility. a. File System Utility When the file system utility button field 354 is pressed, the user interface task module 230 generates a predetermined Create_Display # command in the interface manager 66, and then the interface manager 66 generates a Format_Display # command. 12, a file system information submenu is displayed. The file system information submenu includes a first box 286. First box 286 identifies attributes of storage device 204 of data interface 202, for example, by vendor, model, capacity, and by confirming its installation. This information is provided to the user interface task module 230 by the file system task module 224. The file system information submenu also includes a second box 288. The second box 288, for example, identifies the software version of the file system task module 224 to be installed, confirms its readiness for operation, and lists its current capacity, thereby listing the file system task module 224. Identify its own attributes. The file system information submenu also includes a push button field 290 shown as a file manager. When the file manager button field 290 is pressed, the user interface task module 230 generates a predetermined Create_Display # command in the interface manager 66, and the interface manager 66 generates a Format_Display # command in FIG. To display the file directory submenu. The file directory submenu includes a box field 292. The user interface task module 230 instructs the file system task module 224 to read the current metadata file node 260 or 262 of each of the assigned action file space 248 and event file space 250. The user interface task module 230 formats the metadata into file system data 294. File system data 294 is listed in a row in box field 292 by E (event data) or P (treatment data) suffix, time stamp, and file size present in storage device 204. The operator can use the control buttons 296 to scroll up and down the rows in a known manner. The file directory submenu also includes sort option pushbutton fields 298, 300, and 302, respectively, shown as sort by name, sort by date, and sort by size. When a sort option is selected, the user interface task module 230 reformats the list in the box field 292 and configures the order of the files by name, date, or size according to the selection. User interface task module 230 directs the display of highlight 304 in the file directory submenu to allow the user to select a file line. The file directory submenu includes a delete push button field 306. Pressing the delete button field 306 causes the user interface task module 230 to instruct the file system task module 224 to delete the data content of the highlighted file space from the storage device 204. This frees up this file space to receive data for another action. The file directory submenu also includes an exit push button field 308. Pressing the exit button field 308 (or anytime pressing the main menu button field visible in the status area 68) causes the user interface task module 230 to display the work area 70 with the default display as shown in FIG. Return to the main menu. b. System Log Viewer Another button field 360 in the file manager submenu is shown as a system log viewer. When the system log viewer button field 360 is pressed, the user interface task module 230 generates a predetermined Create_Display # command in the interface manager 66, and then the interface manager 66 generates a Format_Display # command, as shown in FIG. Display the log viewer submenu so that The log viewer submenu includes a box field 362. The user interface task module 230 instructs the file system task module 224 to read the system state data 336 contained in the allocated ring file space 252. The user interface task module 230 formats the system state data 336 and displays the contents in a box field 362 in chronological order. Each line lists, for example, a recorded state, a time-stamped description of the condition or error, and an identifying system reference code. Other information included in data 336 may also be listed. The operator can use the control buttons 364 to scroll up and down the rows in a known manner. Pressing the main menu button field 82 visible in the status area 68 causes the user interface task module 230 to return the display of the work area 70 to the default main menu as shown in FIG. c. Barcode Display The user interface task module 230 issues a command to change the work area 70 of the screen 60 to display file directory information and functions (FIGS. 12 and 13) or a system status event log (FIG. 17). The status area 68 of the screen 60 simultaneously shows the information of the status area 68 at the same time. The minor mode field 76 continues to indicate that the procedure is in collection mode, and the status area constantly indicates the volume of WB withdrawn from the donor in the process WB field 78. The location and attributes of the other button fields 80/82/84/86 remain unchanged until the action changes the mode of operation. As the procedure changes the mode of operation, the minor mode field 76 changes to reflect this mode change. The user interface task module 230 also communicates with the barcode task module 220. Upon confirming acceptance of the barcode scan input, the user interface task module 230 receives a feedback message 232 generated by the barcode task module 220 (see FIG. 7). As shown in FIGS. 12, 13 and 20, the user interface task module 230 commands the display of a feedback message in a barcode field 358 provided in the status area 68 of the screen 60. iv. Report Task The report task module 226 communicates with the printer port link 212. The report task module 226 is serviced by the file system task module 224 and the user interface task module 230. When active, the report task module 226 directs the file system task module 224 to locate and retrieve the specified action data 236 and event data 238 that are presently present in the storage device 204. Report task module 226 creates a report that provides data in a predetermined alphanumeric format. FIGS. 14 and 15 illustrate this report. The report task module 226 downloads the report to the printer 216. Of course, the format and content of the printed report may vary. For example, the report task module 226 may generate a treatment report 310 (see FIG. 14) based on the treatment data 236 contained in the predetermined treatment data file space 248 on the storage device 204. As another example, the report task module 226 generates an event report 312 (see FIG. 15) that lists the contents of event data stored in the predetermined event data file space 250 on the storage device 204 in chronological order. Is also good. v. User Interface Task (Report Task Support) The user interface task module 230 also links the report task module 226 to the interface manager 66. In the illustrated embodiment, one of the button fields 314 on the special features submenu (see FIG. 6A) (accessed via the special features button field 96 on the main menu display shown in FIG. 4) is , Shown as a treatment report print. When the user presses the action report print button field 314, the user interface task module 230 generates a predetermined Create_Display # command in the interface manager 66, and then the interface manager 66 generates a Format_Display # command in FIG. Display the treatment report print submenu as shown in FIG. The treatment report print includes a box field 316. This box field 316 lists the actions for which the current action data 236 and the event data 238 are present on the storage medium 204 by row. The operator can use the control buttons 318 to scroll up and down the rows in a known manner. The user interface task module 230 displays a highlight 320 for selection. The Print Action Report submenu includes a Print Selected Report pushbutton field 322. Pressing this button field 322 causes the user interface task module 230 to report to the report task module 226 a formatted report for the selected treatment (in the illustrated embodiment, the treatment report 310 and FIG. 15 in FIG. 14). Command the event report 312) shown to be formatted and printed. By selecting the current report cancel push button 324 field, the user can finish printing the selected report. The print treatment report submenu also includes a printer status box field 326. Printer status box field 326 displays information from communication manager task module 218 that reports the status of printer 216, for example, idle, busy, error, and the like. Pressing the main menu button field 82 visible in the status area 68 causes the user interface task module 230 to return the display of the work area 70 to the default main menu as shown in FIG. User interface task module 230 also allows the operator to adjust report task module 226 to automatically compile and print treatment report 310 and event report 312 at the end of the treatment. In the embodiment shown (see FIG. 6A), one of the button fields 330 on the feature submenu is shown as a system configuration. Pressing the system configuration button field 330 causes the user interface task module 230 to generate a predetermined Create_Display # command in the interface manager 66, which then generates a Format_Display # command, as shown in FIG. To display the system configuration submenu. The system configuration submenu also includes a configuration button 332. When the configuration button 332 is pressed, this button 332 causes the display of a configuration submenu, as shown in FIG. The configuration submenu includes an “auto print” push button field 334. Pressing this button 334 toggles the button label between turn on and turn off. When toggled to the turn-off state (auto print feature is activated), data interface 202 is adjusted to automatically compile and print treatment report 310 and event report 312 at the end of the treatment. D. Data exchange task i. Data Transfer Function Due to the features of the action driver task module 222, file system task module 224, print task module, and user interface task module 230 already described, the data interface 202 uses the external computer 206 or connects to the external computer 206. It should be appreciated that data is fully integrated to store, retrieve, and manipulate data without a connection. However, second port 210 allows data interface 202 to be linked to external computer 206 if desired. The data exchange task module 228 includes a data sharing function 384 that establishes a communication exchange interface between the built-in data interface 202 and the external computer 206. In one embodiment, external computer 206 coupled to second port link 210 may include resident control software 338 of external computer 206 itself (see FIG. 7). Software 338 is programmed to prompt data interface 202 to obtain control and processing parameters that are key to a given procedure. The data sharing function 384 of the data exchange task module 228 responds by assembling this data and downloading it to the computer 206 for storage, retrieval or manipulation. In this configuration, the data sharing function 384 of the data exchange task module 228 generates a random access data file 340. This random access data file 340 is shown as Act2_Proc_Data in FIG. The Act2_Proc_Data file 340 is formatted the same as the Act_Proc_Data file 234 maintained in random access memory by the action driver task module 222. While a predetermined action is in progress, the data sharing function 384 periodically copies the data from the Act_Proc_Data file 234 to the Act2_Proc_Data file 340. While a given action is in progress, the data sharing function 384 can also periodically read the event data present in the current event data file space 250 on the storage device 204. However, while a predetermined procedure is in progress, the data sharing function 384 cannot read the current procedure data file space 248 on the storage device 204. Control software 338 residing on external computer 206 sends the programmed ASCII input to data sharing function 384 as the procedure proceeds. In response to the programmed input, the data sharing function 384 constructs a desired response based on data read from the Act2_Proc_Data file 340 or from the current event data file space 250 on the storage device 204. I do. Data sharing function 384 sends this response to external computer 206 for storage, retrieval, or manipulation. Once the treatment is complete, data sharing function 384 reads data from both treatment data file space 248 and event data file space 250 on storage device 204 and responds to pre-programmed inputs from external computer 206. Can be configured. In the illustrated embodiment, the data sharing function 384 is automatically activated whenever the communication manager task module 218 detects communication via the port 210 with the computer 206 having the enable control software 338. ii. Control Input Function The data exchange task module 228 also includes a data control function 386. The data control function 386 allows a process control input 388 to be received from the external computer 206. In this configuration, control software 338 of computer 206 establishes a graphical user interface on computer 206 that is compatible with interface manager 66. Data control function 386 sends process control inputs 388 from computer 206 to interface manager 66 via user interface task module 230. Process control inputs 388 perform the same command and control functions as the corresponding inputs from screen 60 described previously. Data control function 386 enables processing parameters for controller 18 to be established or changed from a remote location. iii. Purge Function In the embodiment shown, the data exchange task module 228 includes a purge function 344. The purge function 344 performs housekeeping on the number of files managed by the file system task module 224. At predetermined intervals (eg, at the end, or at each step), the purge function 344 reads the metadata file nodes 260/262 maintained by the file system task module 224. The purge function instructs the file system task module 224 to delete data from the treatment data file space and the event data file space that exceed a predetermined number according to where the oldest data is located. For example, if the file system task module 224 allocates file space for 40 actions (ie, 40 action data file spaces and 40 event data file spaces), the purge function 314 determines where the oldest data is located. Delete more than 30 assigned treatment file space and event file space data, respectively, according to whether they are stored. In this manner, data interface 202 maintains current treatment data 236 and event data 238 for the 30 most recent treatments. The nature of the ring file of system state data 336 and dump sensor data 350 automatically ensures that only recent data is maintained. In a typical implementation, storage device 204 has 8 megabytes of storage space. Block device function 240 allocates two file spaces of 100 kilobytes each. One is for the system state data file space 252 and the other is extra file space that is freed. Block device function 240 also allocates two file spaces of 1 megabyte each. One is for the dump sensor data file space 254 and the other is the extra file space that is freed. The block device function 240 further includes: 70 file spaces of 6 kilobytes are allocated as treatment data file spaces 248, and 66. 70 file spaces of 5 kilobytes are allocated as event data file space 250. Controlled by the purge function 314, each of these thirty file spaces 248 and 250 hold current treatment data. The remaining 30 are free file spaces. E. FIG. User interface tasks (data exchange task support) i. File Transfer Function In another embodiment, a treatment data file or event data file residing on storage device 204 may additionally control software on external computer 206 under the control of user interface task module 230 of data interface 202. Without need, they can be transferred or downloaded to any compatible external computer 206 linked to the second port in any arbitrary order. As implemented in the illustrated embodiment, the file directory submenu (see FIG. 13) includes a transfer pushbutton field 346. Upon pressing the transfer button field 346, the user interface task module 230 instructs the file system task module 224 to copy the data of the highlighted file from the storage device 204 to the data exchange task module 228. Next, the data exchange task module 228 transfers this data to the external computer 206 via the second port. The external computer 206 can store, retrieve, and operate data using built-in data processing software. The built-in data recording capabilities of data interface 202 do not require external computer 206 to be connected during the data storage process. Further, any external computer 206 may be connected after the data is stored by the data interface 202. The data interface 202 also allows data to be downloaded to the external computer 206 in any manner at any time after completion of the processing function. The data collected by the data interface 202 is also available to field service personnel, which allows for accurate program diagnosis and instrument performance evaluation. ii. File Import Function In the embodiment shown (see FIG. 21), the data exchange task module 228 includes an import function 380. The import function 380 allows for the import or upload of additional operational algorithms 382 from the external computer 206 to the controller 18 to be implemented. In the illustrated implementation, the system configuration submenu (FIG. 18) includes an import configuration button 378. Pressing the import configuration button 378 activates an input function 380. The import function 380 boots the MPU 44 of the controller 18 into the import mode. This import mode is governed by the control software 338 of the computer 206 coupled to the port link 210. Controlled by input from the computer 206, the control software 338 converts one or more additional operating algorithms 382 into EPROM process software for the MPU 44, specifically the appliance control manager 46, the appliance manager 50 and the interface manager 66. As, install. The imported algorithm 382 establishes one or more new applications that can be invoked by the application control manager 46. The imported algorithm also installs the implementation process software on the instrument manager 50 and interface manager 66. F. Data Dump Task In the illustrated embodiment, the user interface 202 also includes a data dump task module 366. Data dump task module 366 communicates with port link 348 and file system task module 224. The data dump task function 366 periodically reads the data content of the file space (that is, the space 254 in FIG. 8) in which the file system task module 244 writes the dump sensor data 350. The data dump task module 366 formats the current dump sensor data 350 as a message buffer output 370, which is sent via a port link 348 to the connected external computer 206 '. External computer 206 'includes enable control software 368. Software 368 coordinates computer 206 'to receive and store, retrieve, or manipulate the formatted message buffer output 370. For example, the data dump task module 366 can automatically assemble the message buffer output 370 every five seconds and send it to the port link 348 for download to the external computer 206 '. This chronological record maintained by the external computer 206 'provides an accurate and comprehensive description of the detection status of the entire procedure. This record can be used by service or diagnostic technicians to troubleshoot system errors. This record may also help R & D engineers design, develop, and implement new operational algorithms for application control manager 46. 20, the data dump task module 366 includes a predictor function 372. The predictor function 372 includes an algorithm that analyzes the contents of the continuous message buffer output 370 according to predetermined criteria. For example, a criterion may evaluate a sensing condition for compliance with an established operating range. The criterion may use a proportional, integral, or derivative analysis, or a combination thereof, to assess changes in the detected state over time. The criterion may compare the detection status to other empirically developed standards or test algorithms, for example using correlation techniques or fuzzy logic techniques. The predictor function 372 generates a diagnostic output file 374 based on the analysis. The diagnostic output file 374 indicates system performance trends and predicts potential system errors or failures before they occur. The output file 374 is managed by the file system task module 224 with respect to viewing the entire user interface task module 230 in the system state data file 336, for example, in the same manner as the system state data file 336. FIG. 17 illustrates the inclusion of a diagnostic notification 376 based on a diagnostic output file 374 that identifies bad performance trends and recommends a service check before a failure occurs. Alternatively or in combination, the contents of the diagnostic output file 374 may be included as items in an event report 312 that is handled via the report task module 226. Alternatively or in combination, enable control software 368 of external computer 206 ′ may incorporate predictor function 372. In this configuration, the external computer 206 'may provide its own diagnostic notification 376 in a visual or hard copy form. The described data interface 202 and graphical interface are compatible with WINDOWS with conventional graphics software disclosed in, for example, published literature. TM For example, MS WINDOWS, as provided by the development kit TM It can be implemented as an "C" language program implemented using applications and standard WINDOWS 32 API controls. Various features of the invention are set forth in the following claims.

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ケッコウスキー，ダグラス アメリカ合衆国 イリノイ 60031，ガー ニー，ユニバーシティ アベニュー 3876 (72)発明者 モロウ，デイビッド アメリカ合衆国 イリノイ 60614，シカ ゴ，ノース パイン グローブ 2738────────────────────────────────────────────────── ─── Continuation of front page    (72) Inventor Keckowski, Douglas             United States Illinois 60031, Gar             Knee, University Avenue 3876 (72) Inventor Morrow, David             United States Illinois 60614, Deer             Go North Pine Grove 2738

Claims (1)

【特許請求の範囲】 １．血液処理処置を実行するための処理ハードウェアを含む装置と、 該処理ハードウェアに結合され、該血液処理処置の間、ハードウェアステータ ス状態をモニタする処理マネージャと、 該処理マネージャに結合されるデータインタフェースであって、モニタされた ハードウェアステータス状態に基づいて現在のシステムデータを生成するための データジェネレータタスクと、現在のシステムデータを分析して、少なくとも１ つの未来のハードウェアステータス状態を予測する出力を生成するためのデータ 分析タスクと、を含むデータインタフェースと、 を含む、血液処理システム。 ２．前記データインタフェースが、前記装置上に存在する、請求項１に記載のシ ステム。 ３．前記データインタフェースが、現在のシステムデータをデータ記憶媒体に書 き込むためのファイルマネージャタスクを含む、請求項１に記載のシステム。 ４．前記データ記憶媒体が、前記装置上に存在する、請求項３に記載のシステム 。 ５．前記データインタフェースが、フラッシュメモリ記憶媒体を含み、 該データインタフェースが、現在のシステムデータを該フラッシュメモリ記憶 媒体に書き込むためのファイルマネージャタスクを含む、請求項１に記載のシス テム。 ６．前記データインタフェースが、前記装置上に存在する、請求項５に記載のシ ステム。 ７．前記記憶媒体が、前記現在のシステムデータのためのブロックファイルを含 む、請求項３に記載のシステム。 ８．前記ファイルマネージャタスクが、現在のシステムデータを前記ブロックフ ァイルに付加する、請求項７に記載のシステム。 ９．前記ブロックファイルが、固定最大サイズを有し、 該固定最大サイズを超えると、前記ファイルマネージャタスクが、古い現在の システムデータを新しい現在のシステムデータで上書きすることにより、現在の システムデータを該ブロックファイルに付加する、請求項７に記載のシステム。 １０．前記データジェネレータタスクがまた、モニタされたハードウェアステー タス状態に基づいて時系列データを生成し、 前記データインタフェースが、第１のファイル空間および第２のファイル空間 を含むデータ記憶媒体と、現在のシステムデータを該第１のファイル空間に書き 込み且つ時系列データを該第２のファイル空間に書き込むためのファイルマネー ジャタスクと、を含む、請求項１に記載のシステム。 １１．前記データジェネレータタスクがまた、ある時点のモニタされたハードウ ェアステータス状態に基づいて、時間に固有のデータを生成し、 前記データインタフェースが、第１のファイル空間および第２のファイル空間 を含むデータ記憶媒体と、現在のシステムデータを該第１のファイル空間に書き 込み且つ時間に固有のデータを該第２のファイル空間に書き込むためのファイル マネージャタスクと、を含む、請求項１に記載のシステム。 １２．前記データ記憶媒体が、フラッシュメモリ記憶媒体を含む、請求項１０ま たは１１に記載のシステム。 １３．前記データ分析タスクが、現在のシステムデータを、前記処理ハードウェ アに関して確立された動作範囲と比較するための手段を含む、請求項１に記載の システム。 １４．前記データ分析タスクが、現在のシステムデータを分析して、処理ハード ウェアステータス状態の経時的な変化を評価するための手段を含む、請求項１に 記載のシステム。 １５．前記データインタフェースが、前記出力をコンパイルして印刷するための 印刷タスクを含む、請求項１に記載のシステム。 １６．前記データインタフェースが、前記出力をコンパイルして見るためのビュ ータスクを含む、請求項１に記載のシステム。 １７．前記データインタフェースが、前記出力をオフロードするための交換タス クを含む、請求項１に記載のシステム。 １８．前記出力が、未来のハードウェアエラーを予測する、請求項１に記載のシ ステム。 １９．前記出力が、未来のハードウェア故障を予測する、請求項１に記載のシス テム。 ２０．前記出力が、悪いハードウェア性能傾向を同定する、請求項１に記載のシ ステム。 ２１．前記出力が、ハードウェアサービス検査を推奨する、請求項１に記載のシ ステム。 ２２．前記ハードウェアが、ポンプを含み、 前記現在のシステムデータが、該ポンプで検知された状態を含む、請求項１に 記載のシステム。 ２３．前記ハードウェアが、重量センサを含み、 前記現在のシステムデータが、該重量センサで検知された状態を含む、請求項 １に記載のシステム。 ２４．前記ハードウェアが、光検出器を含み、 前記現在のシステムデータが、該光検出器で検知された状態を含む、請求項１ に記載のシステム。 ２５．血液処理処置の間、ハードウェアステータス状態をモニタするための手段 と、 モニタされたハードウェアステータス状態に基づいて現在のシステムデータを 生成するための手段と、 ある時間にわたって生成された現在のシステムデータの分析に基づいて、少な くとも１つの未来のハードウェアステータス状態を予測する出力を生成するため の手段と、 を含む、血液処理システム。 ２６．前記出力を印刷するための手段をさらに含む、請求項２５に記載のシステ ム。 ２７．前記出力を見るための手段をさらに含む、請求項２５に記載のシステム。 ２８．前記出力をオフロードするための手段をさらに含む、請求項２５に記載の システム。 ２９．前記現在のシステムデータを記憶媒体に書き込むための手段をさらに含む 、請求項２５に記載のシステム。 ３０．前記記憶媒体が、フラッシュメモリを含む、請求項２９に記載のシステム 。 ３１．血液処理処置をモニタする方法であって、 該血液処理処置の間、ある時間にわたってハードウェアステータス状態をモニ タするステップと、 モニタされたハードウェアステータス状態に基づいて、現在のシステムデータ を生成するステップと、 ある時間にわたって生成された現在のシステムデータの分析に基づいて、少な くとも１つの未来のハードウェアステータス状態を予測する出力を生成するステ ップと、 を包含する、方法。 ３２．前記出力を印刷するステップをさらに包含する、請求項３１に記載の方法 。 ３３．前記出力を見るステップ手段をさらに包含する、請求項３１に記載の方法 。 ３４．前記出力をオフロードするステップをさらに包含する、請求項３１に記載 の方法。 ３５．前記現在のシステムデータを記憶媒体に書き込むステップをさらに包含す る、請求項３１に記載の方法。 ３６．前記書き込みステップが、前記現在のシステムデータをフラッシュメモリ に書き込むステップを包含する、請求項３５に記載の方法。[Claims] 1. An apparatus including processing hardware for performing a blood processing procedure;   A hardware stator coupled to the processing hardware during the blood processing procedure; A process manager that monitors the status of the   A data interface coupled to the processing manager, the data interface being monitored To generate current system data based on hardware status condition Analyze the current system data with the data generator task and Data to generate output predicting two future hardware status conditions A data interface including an analysis task; And a blood processing system. 2. The system of claim 1, wherein the data interface resides on the device. Stem. 3. The data interface writes current system data to a data storage medium. The system of claim 1 including a file manager task for writing. 4. The system of claim 3, wherein the data storage medium resides on the device. . 5. The data interface includes a flash memory storage medium;   The data interface stores current system data in the flash memory. The system of claim 1, including a file manager task for writing to the media. Tem. 6. The system of claim 5, wherein the data interface resides on the device. Stem. 7. The storage medium contains a block file for the current system data. The system according to claim 3. 8. The file manager task transfers the current system data to the block The system according to claim 7, wherein the file is added to a file. 9. The block file has a fixed maximum size,   When the fixed maximum size is exceeded, the file manager task By overwriting the system data with the new current system data, The system according to claim 7, wherein system data is added to the block file. 10. The data generator task also monitors the monitored hardware status. Generate time-series data based on the status   The data interface comprises a first file space and a second file space A data storage medium including the following, and writing current system data to the first file space. File money for writing time series data into the second file space The system of claim 1, comprising: 11. The data generator task also monitors the monitored hardware at some point. Generate time-specific data based on the   The data interface comprises a first file space and a second file space A data storage medium including the following, and writing current system data to the first file space. For writing embedded and time-specific data to the second file space The system of claim 1, comprising: a manager task. 12. The method of claim 10, wherein the data storage medium comprises a flash memory storage medium. Or the system according to 11. 13. The data analysis task converts current system data to the processing hardware. 2. The method according to claim 1 including means for comparing with the operating range established for the device. system. 14． The data analysis task analyzes the current system data and processes 2. The method according to claim 1, comprising means for assessing changes in wear status over time. The described system. 15. The data interface for compiling and printing the output. The system of claim 1, comprising a printing task. 16. A data interface for compiling and viewing the output; The system of claim 1, comprising a task. 17． An exchange task for offloading the output; The system of claim 1, comprising: 18. The system of claim 1, wherein the output predicts a future hardware error. Stem. 19. The system of claim 1, wherein the output predicts a future hardware failure. Tem. 20. The system of claim 1, wherein the output identifies a bad hardware performance trend. Stem. 21. The system of claim 1, wherein the output recommends a hardware service check. Stem. 22. The hardware includes a pump;   The method of claim 1, wherein the current system data includes a condition detected by the pump. The described system. 23. The hardware includes a weight sensor;   The said current system data contains the state detected by the said weight sensor. 2. The system according to 1. 24. The hardware includes a photodetector;   2. The current system data includes a condition detected by the photodetector. System. 25. Means for monitoring hardware status conditions during a blood processing procedure When,   Current system data based on monitored hardware status conditions Means for generating;   Based on an analysis of current system data generated over time, To generate output that predicts at least one future hardware status condition Means, And a blood processing system. 26. The system of claim 25, further comprising means for printing the output. M 27. The system of claim 25, further comprising means for viewing the output. 28. The method of claim 25, further comprising means for offloading the output. system. 29. A means for writing the current system data to a storage medium. 26. The system of claim 25. 30. 30. The system of claim 29, wherein the storage medium comprises a flash memory. . 31. A method of monitoring a blood treatment procedure, comprising:   During the blood processing procedure, the hardware status status is monitored for a certain period of time. Steps to perform   Current system data based on monitored hardware status conditions Generating   Based on an analysis of current system data generated over time, A step that generates an output that predicts at least one future hardware status condition. And A method comprising: 32. The method of claim 31, further comprising printing the output. . 33. The method of claim 31, further comprising the step of viewing the output. . 34. 32. The method of claim 31, further comprising offloading said output. the method of. 35. Writing the current system data to a storage medium. 32. The method of claim 31, wherein 36. The writing step stores the current system data in a flash memory; 36. The method of claim 35, comprising the step of writing to.
JP54583299A 1998-03-10 1999-02-24 System and method for monitoring and analyzing the operation of a medical processing device Pending JP2001525940A (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US3748298A 1998-03-10 1998-03-10
US09/037,482 1998-03-10
PCT/US1999/003993 WO1999046593A1 (en) 1998-03-10 1999-02-24 Systems and methods for monitoring and analyzing operation of medical processing devices

Publications (1)

Publication Number Publication Date
JP2001525940A true JP2001525940A (en) 2001-12-11

Family

ID=21894579

Family Applications (1)

Application Number Title Priority Date Filing Date
JP54583299A Pending JP2001525940A (en) 1998-03-10 1999-02-24 System and method for monitoring and analyzing the operation of a medical processing device

Country Status (4)

Country Link
EP (1) EP0995117A4 (en)
JP (1) JP2001525940A (en)
BR (1) BR9904906A (en)
WO (1) WO1999046593A1 (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2853980B1 (en) * 2003-04-16 2005-08-26 Geyser METHOD AND DEVICE FOR RECORDING THE OPERATING INCIDENTS OF MEDICAL DEVICES
CA2799526C (en) * 2003-07-02 2014-01-21 Terumo Bct, Inc. Monitoring and control system for blood processing
CN111781336B (en) * 2019-04-04 2022-10-21 江苏赛灵医疗科技有限公司 Test system and method of thrombelastogram instrument

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4827430A (en) * 1987-05-11 1989-05-02 Baxter International Inc. Flow measurement system
US5681273A (en) * 1991-12-23 1997-10-28 Baxter International Inc. Systems and methods for predicting blood processing parameters
US6319471B1 (en) * 1992-07-10 2001-11-20 Gambro, Inc. Apparatus for producing blood component products
EP0697661B1 (en) * 1994-08-04 1997-11-19 Siemens Aktiengesellschaft Apparatus for technical diagnosis of errors in a medical system, in particular a dentist's system
US5581687A (en) * 1994-11-10 1996-12-03 Baxter International Inc. Interactive control systems for medical processing devices
US5629871A (en) * 1995-06-07 1997-05-13 Cobe Laboratories, Inc. Wear trend analysis technique for components of a dialysis machine

Also Published As

Publication number Publication date
EP0995117A1 (en) 2000-04-26
EP0995117A4 (en) 2001-05-02
WO1999046593A1 (en) 1999-09-16
BR9904906A (en) 2000-07-04

Similar Documents

Publication Publication Date Title
JP2002503258A (en) System and method for storing, retrieving and manipulating data in a medical processing device
JP4081587B2 (en) Interactive control system for medical treatment equipment
JP4182406B2 (en) System and method for managing procedures in a blood component collection facility
US9348624B2 (en) Monitoring file access of java processes
US6311320B1 (en) Alterable scripting tool and method
JP4215286B2 (en) Storage device content organization system and storage device content organization method
US7434042B2 (en) Apparatus, method and recording medium for starting up data processing system
JP4731643B2 (en) Script creation system
US7152226B2 (en) Flexible horizontal stack display and editor
US8176467B2 (en) Computer program generation system and method thereof
US20040162898A1 (en) Dedicated networked device monitoring system
US6052800A (en) Method and system for updating information on an intelligent display device monitoring a computer system
JP2001525940A (en) System and method for monitoring and analyzing the operation of a medical processing device
US20240120081A1 (en) Method for tracking the status of at least one medical device in a distributed medical device system, method for retrieving the status of at least one medical device in a distributed medical device system, and medical device
JPH05334136A (en) Method for managing starting history of diagnostic program
GB2353374A (en) Control of installation of software on and/or the testing of a computer system
Indovina NIST
Jenkin et al. A user-oriented computer interface for health professionals
JPH04209040A (en) Testing method for software