JP4897057B2

JP4897057B2 - コンピュータ化された医療アドバイスシステム

Info

Publication number: JP4897057B2
Application number: JP2010004094A
Authority: JP
Inventors: イリフ，エドウィン，シー
Original assignee: クリニカルディシジョンサポート，エルエルシー
Priority date: 1997-03-14
Filing date: 2010-01-12
Publication date: 2012-03-14
Anticipated expiration: 2018-03-13
Also published as: JP2010134946A; JP2008210399A

Description

本発明はおおむね医学知識システムに関し、特に患者の疾患のコンピュータ化された長期管理システムに関する。

健康は我々が生活を送る根拠である。医学は診断と治療から構成されている。診断手段は患者の問題の原因を見いだし、治療は利用できる最良の療法の適用である。しかし、すべての疾患が治療によって完全に平癒できるわけではない。

喘息および糖尿病のような疾患は、患者の生涯にわたって療法と呼ばれる規則的なスケジュールの治療を必要とするかもしれない。この場合には、疾患は治療されるというよりは管理される。疾患管理とは、多大の費用を要する医療の介入を排除し、また患者の幸福を促進するように、患者を教育する意図をもって既知の診断で患者を管理すること、および疾患の症状の突然で激しい発現を予防するように監視することと定義されてもよい。同じ治療、たとえば、ある薬に対して患者は異なる反応をするかもしれないので、疾患管理の療法部分は、特定の患者の反応に合わせて個別に行われなければならない。

疾患管理は社会に再発経費を創り出すので、費用の低減に対する強い要望がある。目標が実現するに値する理由を理解するためには、極端に均一な料金制の医療制度を理解しなくてはならない。完全に均一な料金システムの主唱者は、誰もがうまくゆくと主張する。極論すれば、誰も病気にはならず、患者がいないので、医者は診療しない患者に対する支払を受けるであろう。完全に均一な料金制においては、世界中のすべての人は、その唯一の目的が人を健康な状態に保つことである健康維持組織に毎月１人当たり所定の金額を支払う。これは称賛に値する目標であるが、実現は不可能である。しかし、実現可能な目標は疾患が管理される方法を自動化することである。

疾患管理の全体の概念は、極論すれば、１日２４時間患者について回っている医者を視覚化することである。当然ながら、これは多くの場合に実行できない解決策である。費用を低減するためには、医者の知識が一般大衆に広められなくてはならない。また１つの解決方法は患者のいる場所に医者の物理的な存在を必要としないことであろう。

医学の多くはアルゴリズム的である。すなわち、診断の後には問題の原因を分離する段階の連続が続く。高度心臓生命維持療法（ＡＣＩＳ）および高度外傷生命維持療法（ＡＴＬＳ）は、標準を設定することによって、いかに多くの介護が改良できるかを示した。いくつかの標準は医薬アルゴリズムに翻訳されてもよく、それは介護の標準を医者のために設定するのに役立つことができる。電話健康診断の概念は全国的な毒物コントロール・センタによって証明されている。また医者、特に小児科医は、電話が発明されたときから、電話を介した療法を実行している。実際に、電話で口に出された最初の言葉は助けを求める呼び掛けであった。１８７６年３月７日、アレクサンダー・グラハム・ベルは、電話用の電池の液をこぼして、「ワトソン君来てくれ、私は君を必要とする。」と叫んだ。今日のいわゆるテレメディスンは１対１の関係のままである。テレメディスン現象は、医療の一定の実施をするのに役立つ最良の実施ガイドラインに部分的に依存している。

疾患管理は医療の実施の再設計以下のものではない。医療における課題は主として情報の１つとその情報の組合わせ方であった。パーソナル・コンピュータと標準の発達のために、今や疾患管理の進歩が可能となった。過去においては、医者とは医学情報の倉庫であり、医学情報が臨床的な意味を有するように医学情報を整理するものであった。けれども、今ではこれらの機能は電気通信およびコンピュータ技術の手段を用いて自動化された方法で実行できる。

疾患管理は、出生から死までの全体のヘルスケアの連続を通じて、患者に対する介護の調整を含むことができる。疾患管理は、予防、診断、治療およびリハビリテーションを含む万人の生命のすべての部分で利用できるプログラムを有する。このプロセスは、特定の疾患を有する患者のみではなく、健康な患者の管理も含んでいる。しばしば、供給者は疾患の症状の激しい発現を有する患者へ集中的で多大の費用を要するサービスを提供することに集中する。全集団の健康を改善するために、疾患管理は予防的、総合的な介護に大きな焦点を置くことを主張する。ある意味では、疾患管理は、医療の実施を医者の手から取り上げて、患者の手の中に置くようにしている。

ほとんどすべての「知識ベースの」臨床的推論は、コンピュータによって、より良く能力を発揮し、より信頼が置ける。技術は医療の民主化を推進する。特に疾患管理において、医療の実施を自動化できるシステムで、医療上のヘルスケアにおける主要で有益な役割を演ずるために患者を激励し訓練するシステムが強く望まれている。このようなシステムは、均一料金制のヘルスケア市場において、維持可能な、実質的な、著しい競合上の利点を与えるべきである。このようなシステムは、介入が臨床的に、経済的にまた人道的に最大限に活用されるように、どのような疾患プロセスにおいても、非常に重大な時期を自動的に識別することが可能であるべきである。

既知の医学的疾患を有する特定の患者に対応する患者の医療記録をメモリから検索することと、前記患者の健康を評価することであって、自動的に前記患者に質問をすることと、健康データを得るために前記患者から自動的に回答を受信することと、前記得られた健康データを前記患者の医療記録の中に自動的に蓄積することと、前記患者の医療記録の１部に対応する特有の健康パラメータを自動的に選択することと、健康パラメータによって示された前記患者の健康状態の前の疾患管理セッションからの変化を自動的に計算することと、前記健康状態の変化を前記医学的疾患に対する疾患の特有の変化と自動的に比較することと、前記得られた健康データと前記比較にもとづいて、前記特定の患者のための疾患療法の調整を示すデータを自動的に出力することを含む前記患者の健康を評価することを含むコンピュータ化された疾患管理方法
医療情報を特定の患者に自動的に提供することができる医療アドバイス・モジュールと、複数の患者の各々に対する前記医療情報に許されるアクセス可能性のレベルを示す認可情報を有する認可データベースであって、前記認可情報は前記特定の患者に対する認可レベルを有する認可データベースを有するコンピュータ化された医療アドバイスシステム。

本発明の一実施態様に、疾患を有する患者の健康を評価することと、前記患者の健康評価に基づいて疾患の療法を最適化することを含むコンピュータ化された疾患管理方法がある。

本発明の他の実施態様に、特定の患者に対応する電子的医療記録の中に主観的な健康測定を備えることと、前記電子的医療記録の中に客観的な健康測定を備えることと、前記主観的な健康測定と前記客観的健康測定にもとづいて測定基準を計算すること、を含むコンピュータ化された相関アセスメント方法がある。

本発明のさらに他の実施態様に、特定の疾患に対する臨界カーブを備えることと、前記特定の疾患を有する特定の患者に対応する電子的医療記録の中に複数の健康パラメータを備えることと、健康アセスメント情報を得るために少なくとも１つの前記健康パラメータを前記臨界カーブと比較すること、を含むコンピュータ化された臨界カーブ・アセスメント方法がある。

本発明のさらに他の実施態様に、健康アセスメントと疾患を有する患者のための療法情報を自動的に提供することができる疾患管理モジュールと、健康アセスメントと療法情報に許容されたアクセス可能性のレベルを示す認可情報を有する認可データベースを有する疾患管理システムがある。

本発明のさらに他の実施態様に、患者に医療情報を提供できる医療アドバイス・モジュールと、前記医療アドバイス・モジュールと組み合わされた認可レベルを有するコンピュータ化された医療助言システムがある。

本発明のさらに他の実施態様に、特定の疾患を有する特定の患者に対する客観的健康測定および主観的健康測定の利用可能性を決定することと、利用できる客観的健康測定にもとづいて前記患者に対する療法を調整すること、あるいは利用できない客観的健康測定および利用できる主観的健康測定にもとづいて前記患者に対する療法を調整することを含む療法最適化のコンピュータ化された方法がある。

本発明のさらに他の実施態様に、患者の健康を評価することを示す複数の質問の群であって、各群が言語レベルの理解に関する患者の健康を評価することを示す複数の質問の群を提供することと、特定の患者の前記言語レベルの理解を識別することと、前記識別された言語レベルにもとづいて前記質問の群の１つを選択することと、前記選択された群から前記患者に質問することを含むコンピュータ化された質問説明方法がある。

本発明のさらに他の実施態様に、患者の主観的な痛みの知覚を苦痛コードに符号化することと、疾患のデータベースに前記苦痛コードで索引を付けることによって疾患を診断することを含むコンピュータ化された医療の診断方法がある。

本発明のさらに他の実施態様に、特定の疾患を有する特定の患者に対応する治療変更認可レベルを提供することと、前記患者に対する療法調整を自動的に決定することと、前記治療変更認可レベルによって許容されるように前記患者に前記療法調整を勧告することを含むコンピュータ化された治療の変更方法がある。

本発明のさらに他の実施態様に、医療スクリプトに対してプレビュー・モードを設定することと、患者の健康に関する質問をすることと、前記質問に答えた結果に関する情報を受け取ることを前記患者に許容することと、前記質問に答がなかったかのように前記医療スクリプトをリセットすることを含むコンピュータ化されたプレビュー・モード方法がある。

本発明のさらに他の実施態様に、複数のパラメータを提供することと、医療スクリプトからの選択された質問をすることと、前記質問への反応に対してあらかじめ設定した時間だけ待つことと、前記あらかじめ設定した時間が応答なしに終了した後に、前記パラメータにもとづいてアクションを実行することを含むコンピュータ化された無応答方法がある。

本発明のさらに他の実施態様に、特定の疾患を有する特定の患者の重大な症状をフィルターすることと、前記患者が以前に評価されていなければ、初期の健康測定値を前記患者から取得し蓄積することと、前記患者が以前に評価されていれば、その後の健康測定値を前記患者から取得し蓄積することを含むコンピュータ化された健康アセスメント方法がある。

本発明の最後の実施態様に、特定の疾患を有する特定の患者から得られた重大な症状の重大度を決定することと、前記重大度レベルが十分に低ければ、前記患者の前記健康を評価することと、前記重大度レベルが十分に高ければ、所定のアクションをとることを含むコンピュータ化された重大症状フィルタリング方法がある。

本発明による自動化された医療診断、治療、疾患管理および情報システムのブロック図である。図１に示すシステムの構成装置の配置の略図である。図１および図２Ａに示すサーバー・コンピュータの構成装置の配置の略図である。図１のシステムによって使用されるプロセスおよびデータベース・ファイルの１部分のブロック図である。図１のシステムによって実行されるトップレベル・プロセスのフローチャートである。図１のシステムによって実行されるトップレベル・プロセスのフローチャートである。図１のシステムによって実行されるトップレベル・プロセスのフローチャートである。図１のシステムによって実行されるトップレベル・プロセスのフローチャートである。図４Ｄに示され、図１のシステムによって実行される疾患管理モジュール・プロセスのフローチャートである。図５に示すオープンセッション・プロセスのフローチャートである。図５に示す健康アセスメント・プロセスのフローチャートである。図７に示す重大症状フィルター・プロセスのフローチャートである。図８に示す重大度アセスメント機能のフローチャートである。図７に示す初期健康アセスメント・プロセスのフローチャートである。図７に示す現状健康アセスメント・プロセスのフローチャートである。図１１に示す相関アセスメント機能のフローチャートである。図１１に示す臨界カーブ・アセスメント・プロセスのフローチャートである。図１１に示す臨界カーブ・アセスメント・プロセスのフローチャートである。図５に示す療法最適化プロセスのフローチャートである。図１４に示す療法調整健康データ・プロセスのフローチャートである。図１４に示す療法調整健康データ・プロセスのフローチャートである。図１４に示す客観的健康データ・プロセスにもとづく療法調整のフローチャートである。図１４に示す客観的健康データ・プロセスにもとづく療法調整のフローチャートである。図１５および図１６に示す患者同意レベル機能のフローチャートである。図５に示すクローズ・セッション・プロセスのフローチャートである。図１および図５に示す疾患管理モジュール・プロセスによって利用される質問バージョン・フィーチャーのフローチャートである。図１および図５に示す疾患管理モジュール・プロセスによって利用される質問バージョン・フィーチャーのフローチャートである。図１および図５に示す疾患管理モジュール・プロセスによって利用されるプレビュー・モード・フィーチャーのフローチャートである。図１および図５に示す疾患管理モジュール・プロセスによって利用される無応答フィーチャーのフローチャートである。図４ｄおよび図５に示す疾患管理モジュール・プロセス、および／または図４Ｄに示す患者に対するＰＱＲＳＴ（苦痛コード）配列入力の生成における診断プロセスによって利用される機能のフローチャートである。図２２Ａにおいて患者に対して蓄積されたＰＱＲＳＴ（苦痛コード）配列入力を使用した診断の検索における、図４ｄに示す診断プロセスによって利用される機能のフローチャートである。特定の疾患に対して時間的にプロットした健康測定値の代表的な臨界カーブのグラフである。

本推奨実施例の以下の詳細説明は、請求の範囲の理解を助けるために、ある具体的な実施例について説明する。しかし、請求の範囲によって規定され保護されるように、本発明は多数の異なる方法で具体化できる。図面を参照して説明する。図面の全体にわたって類似の数字は類似の部品を示す。

詳細説明は次の項目で構成されている。

システム概観
システム・プロセスおよびデータベース
トップレベル・システム・プロセス・フロー
疾患管理概観
疾患管理モジュール
オープン・セッション
健康アセスメント
重大症状フィルター
重大度アセスメント
初期健康アセスメント
現在健康アセスメント
相関アセスメント
臨界カーブ・アセスメント
療法最適化
療法調整（主観的）
療法調整（客観的）
患者同意レベル
クローズ・セッション
質問バージョン
プレビュー・モード・フィーチャー
無応答フィーチャー
ＰＱＲＳＴ配列
疾患管理オーダー（ＤＭＯ）
認可データベース
規制認可
シェアリング認可
治療改変認可レベル（ＴＡＰＩ）
メタ構造
メタ機能
疾患管理の利益
システム概観
図１を参照して、コンピュータ化された知識ベース医療管理システム１００を説明する。疾患管理モジュール（ＤＭＭ）８０および数個の他の高レベル・サービス・モジュール８２が、医療管理システム１００の利用者に対する自動化された医療サービスを実行する。サービス・モジュール８２は、診断、治療テーブル、自動化された需要管理、オーディオ／ビジュアル／画像ライブラリおよびオーサー・アクセスを有してもよい。ＤＭＭ８０は疾患管理（ＤＭ）と組み合わされたタスクを処理する。その主要な目標は、患者の福祉を促進し、患者を教育し、多大の費用を要する医療の介入を低減することである。その使用者は患者１１４あるいは患者のためのアシスタントであってもよい。本明細書を通じて、用語「使用者」および「患者」は区別無く同じ意味で使用されている。しかし、使用者が患者のために代理人として利用してもよいことは理解されよう。もしこの場合には、使用者は患者のためのアシスタントとして登録される。以下に説明するように、患者あるいはアシスタントのいずれに対しても、適切な登録およびログイン・プロセスがシステム１００によって使われる。

モジュール８０および８２は、埋め込みコンピュータ・ハードウェア・プラットホーム１１０の、オペレーティング・システムおよびサポート・ソフトウェア８８によって、多数のデータベース８４によって、また計算環境９０によってサポートされている。全体のコンピュータ・ハードウェア−ソフトウェア−通信複合体は、サポート・スタッフによって運営され、保守されている。ＤＭＭ８０のすべてのアプリケーション・タスクは完全に自動化されている。患者、医者、診療所、薬局、研究室等の外部（総合して９２）とＤＭＭとの接触は、計算環境９０の適切なメディアおよび方法を用いて、対話型の音声応答（ＩＶＲ）、「モデムとモデム」の直接のアクセスあるいはインターネット１０２を介してのアクセスのような自動化された通信システムによって処理される。患者１１４は、システム・コンピュータ・プラットホーム１１０と通信するために、コンピュータ１１６およびモニタ１１８、電話機１２４、あるいはその他の構成要素を使用する。構成要素の１部は図２ａと関連して以下に説明される。

図２ａを参照して、医療管理システム１００の１実施例のブロック図を説明する。システム１００はネットワーク１０２を有する。ネットワーク１０２は、ローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、インターネットあるいは他の接続サービスを表しているかもしれない。

システム・プログラムおよびデータベースは、ＬＡＮ１０６およびゲートウェイ１０４によってネットワーク１０２と相互接続されていることが望ましい１群のサーバー１０８に常駐していてもよい。あるいは、システム・プログラムおよびデータベースは、ネットワーク・インタフェース・ハードウェアおよびソフトウェア１１２を利用する１つのサーバー１１０に常駐していてもよい。システム・サーバー１０８／１１０は、モジュール８０および８２（図１）を蓄積する。

ネットワーク１０２は、たとえばモデムを使用して、あるいはネットワーク・インタフェース・カードを使用して、使用者コンピュータ１１６に接続していてもよい。システム・プログラムに遠隔からアクセスするために、コンピュータ１１６の使用者１１４は、キーボードおよび／またはポインティング・デバイスおよびモニタ１１８のような表示装置を用いて、ブラウザ１２０を利用してもよい。あるいは、システム・プログラムがコンピュータ１１６のうえでローカル・モードで実行されるときは、ブラウザ１２０は利用されない。目に見える症状あるいは徴候のような視覚入力を提供するために、ビデオカメラ１２２がコンピュータ１１６にオプションとして接続されてもよい。さらに、臨床的な音をビデオカメラあるいは別なマイクロホン（図示せず）によってとらえることもできる。

システム・サーバー１０８／１１０との通信のためにさまざまな他の装置が用いられてもよい。もしサーバーが音声認識あるいはＤＴＭＦハードウェアを備えていれば、使用者は電話機１２４を使用してシステム・プログラムと通信することができる。電話による実施例は、「コンピュータ化された医療診断および治療アドバイス・システム」と題する１９９３年１２月２９日付けの本出願人による米国特許出願第０８／１７６，０４１号、現在米国特許第５，６６０，１７６号、に説明されている。システム・サーバー１０８／１１０と通信するための他の接続装置には、モデムあるいは無線接続インタフェースを有する携帯用のパーソナル・コンピュータ、表示装置１３０に接続されたケーブル・インタフェース装置１２８、あるいは衛星受信器１３４およびテレビジョン１３６に接続された衛星受信アンテナ１３２を含む。使用者１１４とシステム・サーバー１０８／１１０の間の通信を行う他の方法も考えられる。

図２ｂを参照すると、サーバー・コンピュータ１１０の１実施例の略図は、ネットワークとのいくつかの可能な相互接続を示している。スクリプトを実行するためには、スクリプト・エンジンと呼ばれる特別のプログラムが使用される。スクリプト・エンジンは医療診断スクリプト・ファイルを読み取り、患者に質問を出力し答えを入力するようなインタビュー動作を行うために、そのコードを使用する。さらに、スクリプトは、患者からの回答を集め、その回答を評価し、診断を出し、その患者の医療記録を更新してもよい。またスクリプト・エンジンは使用者のコンピュータ１１６（図２ａ）に常駐してもよい。スクリプト・エンジンは、ハード・ドライブあるいはＣＤ−ＲＯＭに蓄積されてもよく、実行のためにメインメモリあるいはキャッシュにロードされる。

本発明によるコンピュータ化された医療システム１００の現在望ましいサーバー・コンピュータ１１０の構成要素を図２ｂに示す。サーバー・コンピュータ１１０はきょう体の中に複数の構成要素を有する。電話線１５６は、公衆電話ネットワーク１５８をモデム１６０を介してコンピュータ１１０に接続する。電話ネットワーク１５８は、ネットワーク１０２に接続してもよく、ネットワーク１０２はシステム・サーバー１０８／１１０との接続を有する。あるいは、コンピュータ１１０は、ネットワーク・インタフェース・カード１６４を使用してネットワーク１０２に接続してもよい。

ハードウェアおよびシステム・ソフトウェアは２つの基本概念、すなわち、他のオペレーティング・システムへのポータビリティおよび業界標準部品の使用に留意して組み立てられている。このようにして、本システムはより柔軟であり、絶えず製品を改善するために自由市場における競争を可能にし、同時にコストを低減している。特有のハードウェアおよびソフトウェアが参照されているが、本システムでは異なる構成要素も使用できることは理解されよう。

コンピュータ１１０は、インテル・ペンティアム・マイクロプロセッサ１７０を有するパーソナル・コンピュータであることが望ましい。アップル・マッキントッシュ、アミガ、ディジタル・エキップメント・コーポレーションのＶＡＸ、あるいはＩＢＭメインフレームのような、他のコンピュータを利用することもできる。モデム１６０あるいはネットワーク・インタフェース・カード１６４は、ＩＳＡあるいはＰＣＩバス１６２に接続されている。バス１６２は、マイクロプロセッサ１７０をコントローラ回路（チップあるいは基板）を介して複数の周辺機器と相互接続している。

コンピュータ・バス１６２は、アダプタあるいはコントローラを介して接続された複数の周辺機器を有する。ＳＶＧＡあるいはより良い解像度が望ましいビデオ・アダプタ基板１７２は、ビデオモニタ１１８に相互接続されている。シリアル通信回路１７６は、マウス１７８のようなポインティング・デバイスに接続されている。他の実施例においては、パラレル通信回路が回路１７６の代わりに使用されてもよい。キーボード・コントローラ回路１８０は、キーボード１８２に接続されている。５００Ｍｂ以上のハード・ディスク・ドライブ１８４およびオプションのＣＤ−ＲＯＭ駆動装置１８６がバス１６２に接続されていることが望ましい。ハードディスク１８４は、患者ファイル、ＤＭファイル、他のシステム・ファイルおよびバイナリ・サポート・ファイルのようなデータベース・ファイルを蓄積する。ＣＤ−ＲＯＭドライブ１８６も、データベース・ファイルおよびバイナリ・サポート・ファイルを蓄積する。

主メモリ１９０はマイクロプロセッサ１７０に接続されている。１つの実施例においては、コンピュータ１１０は、ウインドウズ９５オペレーティング・システム１９２の下で動作してもよい。メモリ１９０は、診断スクリプト・エンジン（図示せず）および疾患管理モジュール（ＤＭＭ）プロセス２２０を実行する。疾患管理モジュール・プロセス・ソフトウェアのある部分は、ボーランド・デルファイのＰａｓｃａｌ、バージョンＩＩで記述されてもよく、また他の部分はマイクロソフトＣ、バージョン７．０で記述されてもよい。さらに、１つの実施例においては、データベースは、マイクロソフトＦｏｘｐｒｏ、あるいはＳＱＬコンパチブルのリレーショナル・データベース・プログラムのような他のデータベース・プログラムで具体化される。

システムプロセスおよびデータベース
図３を参照して、医療管理システム１００によって使用されるプロセス、ファイルおよびデータベースの１部分を説明する。ＤＭＭプロセス、認可データベース、イメージング・モダリティー・データベース、研究室試験データベース、疾患データベースおよび以下に説明する他のＤＭ特有のデータベースを除いて、これらのプロセス、ファイルおよびデータベースは、本出願人による「コンピュータ化された医療診断および治療アドバイス・システム」と題する米国特許第５，６６０，１７６号に説明されている。

医療管理システム１００は、いくつかの主要なプロセスおよび関連するデータベースを使用している。一組の患者／アシスタント・ログイン・プロセス２００、２１０および２１２は、以前にシステムに登録されたことがある患者を、３つの方法の１つで識別するために、システム１００によって使用される。１）プロセス２００で患者識別番号（ＰＩＮ）を要求する。２）プロセス２１０でアシスタント識別番号（ＡＩＮ）を要求することによって、以前システムに登録されたことがあるアシスタントを識別する。あるいは３）プロセス２１２で患者識別番号を要求することによって、以前システムに登録されたことがあるアシスタントを有する患者を識別する。一組のプロセス２０２、２１４あるいは２１６の１つが、患者あるいはアシスタントを登録するために使用される。もし使用者が患者であれば、新患すなわち初めての患者を登録するためにプロセス２００において、患者登録プロセスがシステムによって使用される。もし使用者が患者でなければ、新しいすなわち初めてのアシスタントを登録するためにプロセス２１４において、アシスタント登録プロセスがシステムによって使用される。次に、もし患者がすでに登録されていなければ、患者を登録するためにプロセス２１６において被支援患者登録プロセスがシステムによって使用される。

使用者がログインあるいは登録されると、システムはプロセスの選択を与える。本実施例に関する主要なプロセスは、疾患すなわち患者の状態ＩＤを管理するＤＭＭプロセス２２０である。ＤＭＭプロセス２２０は、疾患管理の間に研究室試験選択データベース２６０あるいはイメージング・モダリティー選択データベース２５８にアクセスしてもよく、また特定の疾患あるいは診断に対する現在の治療情報を得るために治療テーブル２５０にアクセスしてもよい。患者およびアシスタント登録データベース２４０、コンサルテーション・ヒストリー・データベース２４２、患者応答データベース２４４、病歴オブジェクト・データベース２４６、患者薬物療法データベース２４８、処理中のデータベース２５２および患者病歴データベース２５４が、これらのプロセスと組み合わされている。これらのデータベースは、医療システム１００に登録されている各患者の電子的医療記録を有する。電子的医療記録は各患者についてのすべての情報を含んでいる。認可データベース２５６、疾患データベース２６２および他のＤＭ特有のデータベース２６４については以下に説明する。他の実施例においては、他の医療情報プロセスにアクセスするために、他の選択が追加される。

トップレベル・システム・プロセス・フロー
図４ａ、４ｂ、４ｃおよび４ｄを参照して、医療管理システム・ソフトウェアのトップレベル・フロー３００を説明する。電話を介してシステム１００にアクセスするために使用される電話番号は、システムのさまざまな実施例で変わるかもしれない。もし後援機関あるいは病院が、発呼者に費用を負担させずに医療管理システム１００にアクセスを提供することを望むなら、無料（たとえば、８００、８８８あるいは他の番号）サービス番号が使用できる。もし後援機関あるいは病院がシステム１００の運営経費を発呼者から回収することを望めば、有料通話、あるいはプレミアム課金番号（たとえば、９００サービス）を使用するかもしれない。電話コンサルテーションに対する第３者の支払人に説明し請求書を送るのに、「現手続き用語」（ＣＰＴ−４）コードが利用できる。現手続き用語コードは記述的な用語のリストであり、医療サービスの報告と手続きのためのコードを識別する。ＣＰＴ−４コードは医療サービスを保険会社に報告するための最も広く認められた名称である。もしインターネットあるいは他のネットワークを介してシステム１００にアクセスされれば、適切なウエブ・アドレスが使用者に提供される。

スタート状態３０２において、医療アドバイスを望む使用者１１４（図１）は電話機１２４（図２ａ）からシステム１００の電話番号にダイヤルする。使用者は患者であってもよく、あるいは患者を手伝っている「アシスタント」たとえば親、親類あるいは友人であってもよい。あるいは、使用者は前述のようにインターネットを介して使用者コンピュータ１１６からシステム１００にアクセスしてもよい。状態３０４に転じて、システム１００は自動的に呼に応答し、Ｄｉａｌｏｇｉｃ製の０／４１０のような音声合成基板を用いて、システムのハード・ドライブに蓄積された会話ファイルを再生することによって、前置きの挨拶メッセージで発呼者１１４を歓迎する。あるいは、もし使用者がブラウザ１２０（図２ａ）あるいはインターネット１０２上の他のユーザー・インタフエースを使用していれば、挨拶メッセージは表示装置１１８上で使用者に表示される。上に述べたように、システム１００は電話によってあるいは表示装置上に表示されたメッセージによって使用者１１４と通信する。プロセスあるいは機能フローチャートの次の段階は、説明を簡潔にするために、使用者との通信の１つの形式のみを説明する。

状態３０６で、システム１００はシステムを呼び出している各患者に一連の「初期選別質問」をする。これらの質問は重態の患者を識別するように設計されていて、患者の課題を識別するためには設計されていない。初期選別質問は、直ちに医療を必要とする患者をシステムが篩い分けできるようにする。

意志決定状態３０８に転じて、重態であると判明した患者は、状態３０９において緊急応答電話番号「９１１」に電話するよう指示されるか、あるいは患者の地域の最も近くの緊急医療サービスシステムに自動的に接続される。そのセッションは状態３１０においてプロセス３００によって終了する。次は初期選別質問の例である。

・緊急の医療か？
・呼吸困難？
・胸に激しい痛みあるいは圧迫を感じるか？
もしシステムがその患者が緊急の医療を要すると決定すれば、状態３１１においてシステムは患者に緊急医療の手続きのメニューを提供するかもしれない。患者あるいは患者の代わりの発呼者が最も近くの緊急援助から遠く離れている場合には、たとえば田園環境であれば、使用者はただちに緊急手続きを開始する必要があるかもしれない。緊急医療手続きのメニューは使用者にいくつかの選択肢を提供する。もし使用者がタッチトーンキーの「１」を押すか、あるいは電話機の送話器に「１」と話せば、プロセス３００は状態３１２に分岐し、公知のＣＰＲ（心肺蘇生法）情報が説明される。もし使用者が電話機１２４と組み合わされたスピーカフォン機能を持っていれば、使用者は電話機から離れて手を使わずにその説明を聞き、システム１００によって与えられる指示を行うことが可能かもしれない。もし発呼者がタッチトーンキー「２」を押すか、あるいは電話機の送話器に「２」と話せば、プロセス３００は状態３１３に分岐し、公知の息詰まりに対するＨｅｉｍｌｉｃｈＨｕｇ情報が説明される。状態３１２あるいは状態３１３が完了すると、そのセッションは状態３１４で終了する。

状態３０８においてもし患者が緊急医療を要しないと決定されれば、すなわち、ただちに生命にかかわる条件が無いことにシステム１００が満足すれば、使用者が実際の患者であるかどうかを決定するために、プロセス３００は意志決定状態３１５に移る。もしそうであれば、プロセス３００は、患者が以前に登録しているか、あるいはシステム１００に相談したことがあるかを決定するために、すなわち、患者が新患ではないか、あるいは初めての発呼者ではないかを決定するために意志決定状態３１６に進む。もしそうであれば、ログインプロセス２００において、システム１００は患者の識別を検証し患者の医療の記録を検索する。プロセス２００が完了すると、プロセス３００はページ間接続記号Ｃ３１７を介して状態３４４に（図４ｄ）に進む。意志決定状態３１６において決定されるように、もし患者が登録されていなければ、システム１００は新患者に対する患者登録プロセス２０２に進む。プロセス２０２が完了すると、プロセス３００はページ間接続記号Ｃ３１７を介して図４ｄの状態３４４に進む。

状態３１５で決定したように、もし使用者が患者でなければ、プロセス３００はページ間接続記号Ａ３１８を介して図４ｂの意志決定状態３２０に進む。たとえば、傷害、虚弱あるいは意識変容状態によって患者が直接システム１００を使用できないかもしれない時がある。これらの場合、「アシスタント」が患者のためにシステムと対話してもよい。

アシスタントは、アシスタント登録プロセス２１４を介してシステムに登録する。アシスタント登録記録は、構造上患者登録記録とまったく同じであるが、ＡＳＳＴ＿ＰＥＲＭ、ＡＳＳＴ＿ＥＸＰおよびＲＥＬＡＴＩＯＮＳの３つのフィールドはアシスタントに対して特別な意味を有する。ＡＳＳＴ＿ＰＥＲＭフィールドは、患者とアシスタントの間に関係があることを別な手段を通じて確認したシステム管理者によってのみ、真にオフラインで設定できるブール・フラグである。その関係は１対多数である、すなわち、１人の患者が１人以上のアシスタントを有してもよく、また１人のアシスタントが２人以上の患者に関係してもよい。ＡＳＳＴ＿ＰＥＲＭフラグは、さらにＡＳＳＴ＿ＥＸＰフィールドによって限定されるかもしれない。ＡＳＳＴ＿ＥＸＰフィールドは、ＡＳＳＴ＿ＰＥＲＭ属性の有効期限のためのタイムスタンプを含んでいる。ＡＳＳＴ＿ＰＥＲＭフラグが真であれば、次にＲＥＬＡＴＩＯＮＳポインタはこのアシスタントが「永久のアシスタント」である１人以上の患者記録に設定する、そうでなければＲＥＬＡＴＩＯＮＳフィールドは空である。

もし次の３条件が満足されれば、支援されたコンサルテーションの間に集められた医療情報は、患者医療記録に書き込まれる。

（ａ）アシスタントのＡＳＳＴ＿ＰＥＲＭフラグが真である。

（ｂ）ＡＳＳＴ＿ＥＸＰタイムスタンプには到達していない。

（ｃ）アシスタントは患者記録への関係ポインタを有する。これらの条件の１つでも満たされないと、この患者について集められた新しい医療情報は、システム管理者によるオフラインの検証のために、ペンディング・ファイル２５２（図３）に退避される。

状態３１５において、システム１００は使用者が患者であるか、あるいはアシスタントであるかを確認する。もし使用者が患者でなければ、次にシステムは使用者がアシスタントであると断定し、意志決定状態３２０において、アシスタントが登録されているかどうか確認する。もしアシスタントがシステムにすでに登録されていなければ、システムは新しいアシスタントをアシスタント登録プロセス２１４で登録する。もしアシスタントがシステム１００にすでに登録されていれば、プロセス３００はアシスタント・ログイン・プロセス２１０を実行する。プロセス２１４あるいはプロセス２１０が完了すると、プロセス３００は意志決定状態３２１に進む。

意志決定状態３２１において決定されたように、もし患者がシステム１００にすでに登録されていなければ、次にシステムはアシスタントに被支援患者登録プロセス２１６において新しい患者を登録することを許容する。しかし、状態３２１で決定されたように、もし患者がシステム１００にすでに登録されていれば、プロセス３００は被支援患者ログインプロセス２１２を実行する。プロセス２１６あるいはプロセス２１２が完了すると、プロセス３００は、ページ間接続記号Ｂ３２７を介して、図４ｃの意志決定状態３３４に進む。

意志決定状態３３４において、プロセス３００は患者の生年月日が患者の医療記録にあるかどうかを確認する。もしあれば、プロセス３００は、ページ間接続記号Ｃ３１７を介して、図４ｄの状態３４４に進む。もしなければ、システム１００は患者の生年月日を得ようと試みる。状態３３５に転じて、システム１００はアシスタントに患者の生年月日を知っているか尋ねる。もし知っていれば、患者の生年月日を要求するために、プロセス３００は状態３３６に進む。状態３３７において、システム１００は状態３３６で得た患者の生年月日を復唱する。意志決定状態３３８において、アシスタントはシステム１００によって復唱された生年月日が正しいかを確認する。もし正しくなければ、再び患者の生年月日を求めるために、プロセス３００は状態３３６にループバックする。状態３３８で確認された患者の生年月日が正しければ、患者の医療記録に退避させるために、状態３３９においてプロセス３００は生年月日にフラグを付け、図４ｄの状態３４４に進む。

状態３３５において確認されたように、もし患者の生年月日が判らなければ、プロセス３００は状態３４０に進み、システムは患者の大体の年齢を示すようにアシスタントに要請する。患者の年齢は、ＤＭＭプロセス２２０、診断モジュールおよび治療テーブル２５０によって使用される重要なパラメータである。状態３４１において、システム１００は状態３４０において得られた患者の大体の年齢を復唱する。意志決定状態３４２において、システム１００によって復唱された年齢が正しいかをアシスタントは確認する。もし正しくなければ、プロセス３００は、患者の大体の年齢を再び要請するために、状態３４０にループバックする。状態３４２において確認された患者の大体の年齢が正しければ、状態３４３において、次のコンサルテーションの前に患者の実際の生年月日を用意しておくことをシステム１００はアシスタントに助言し、図４ｄの状態３４４に進む。システム１００は診断モジュールと治療テーブル２５０の間のセッションの中で大体の年齢を使用する。

図４ｄの状態３４４において、システム１００は使用者にシステム選択メニューを提示する。さて、発呼者は次に説明する６つの選択肢、すなわち、診断システム、治療テーブル、疾患管理、オーディオ／ビジュアル／画像ライブラリ、自動化された需要管理、あるいはエンド・セッションから選択するように要請される。

Ａ．診断システム：システムは評価プロセス２８０をメニューで始める。メニューにおいてシステムは患者に病気の正体の確認を始めるように要請する。

Ｂ．治療テーブル：システムはメニューにおいて患者を治療テーブル・プロセス２５０に導く。メニューにおいて、システムは患者に治療選択方法を選択するように要請する。

Ｃ．疾患管理：システムはＤＭＭプロセス２２０を開始し、患者が以前に疾患管理モジュールを使用したことがあるかをシステムは最初に確認する。このプロセスを以下に詳細に説明する。

Ｄ．オーディオ／ビジュアル／画像ライブラリ：システムは、患者に健康診断音を聞かせ、健康診断ビデオを見せ、あるいは健康診断用の写真あるいは他の画像を見せるオーディオ／ビジュアル／画像ライブラリ・プロセス２８２を始める。

Ｅ．自動化された需要管理：医者がいたほうがよいか、もしそうならば、誰がいたほうがよいか、医者がいつ訪れるべきかを患者が判断することを手助けするために、システムは自動化された需要管理プロセス２８４を開始する。

Ｆ．エンド・セッション：システムはいくつかの段階を実行し、セッションを終了させる。

評価プロセス２８０の終了点において、他の病気を選択する選択肢をシステム１００は患者に与える。治療テーブル・プロセス２５０の終了と共に、他の治療を選択する選択肢をシステムは患者に与える。オーディオ／ビジュアル／画像ライブラリ・プロセス２８２の終了と共に、他のオーディオ・クリップ、ビデオ、あるいは画像を選択する選択肢をシステム１００は患者に与える。自動化された需要プロセス２８４の終了と共に、他の問題のための助言を受ける選択肢をシステム１００は患者に与える。

評価プロセス２８０、治療テーブル・プロセス２５０、疾患管理モジュール・プロセス２２０、オーディオ／ビジュアル／画像ライブラリ・プロセス２８２、あるいは自動化された需要管理プロセス２８４の完了と共に、システム１００は状態３４４にループバックし使用者にシステム選択メニューを再び提供する。もし使用者が状態３４４においてエンド・セッション選択を選択すれば、システム１００は意志決定状態３４５に移る。意志決定状態３４５において、システム１００は、プロセス２８０、プロセス２５０、プロセス２２０、あるいはプロセス２８４が情報モードにおいて発生しなかったかを判断する。すなわち、リアル・モードあるいはペンディング・モードで発生しなかったかを判断し、設定メモリ変数のどれかが、患者の病歴ファイルに退避させる必要がある過去の病歴条件ではないかを確認するために、現在の患者に対応する記号表を調べる。状態３４５において両方の条件が真であれば、コンサルテーションがリアル・モードで行われているかを確認するために、システム１００は意志決定状態３４６に進む。もしそうでなければ、コンサルテーションはペンディング・モードで行われていて、次にシステム１００は、コンサルテーションの間に得た新しい患者情報を状態３４７においてペンディング・ファイル２５２に書き込む。

意志決定状態３４６が真であれば、すなわちリアル・モードであれば、退避する必要がある過去の健康状態のおのおのに対して、データが正しいことを確認するために、患者の病歴ファイルにデータを退避することを許可するように、状態３４８においてシステム１００は患者に要請する。たとえば、喘息のためのコンサルテーションの間に、患者がＨＩＶ陽性であると診断されていることをシステム１００が知ったかもしれない。「あなたのＨＩＶ診断についての情報をあなたの医療記録に記録してもよいですか？」と、システム１００は質問するであろう。もし患者が「はい」と答えれば、次にシステム１００は、「ＨＩＶに対するあなたの診断は陽性であったことを確かめてください、これは正しいですね」と質問するであろう。もし患者が「はい」と答えれば、次にシステム１００は、診断とシステムの正確度を示すスコアを患者の病歴ファイルに書き込む。確認の後、各データ項目は患者病歴データベースで２５４（図３）内の患者のファイルに蓄積される。

状態３４８における患者病歴データベース２５４の更新あるいは状態３４５が偽と判明のいずれかの完了と共に、あるいは状態３４７の完了と共に、プロセス３００は意志決定状態３４９に移る。システム１００が患者とのコンサルテーションを終了する前に、システム１００は与えたすべての助言の概要を提示する。電話によるセッションにおいて、患者は要点を書き留め、繰り返すことを要請される。次にシステム１００は、コンサルテーション・セッションの概要およびシステムによって提供される特効のある勧告を、ファクシミリ、電子メール（Ｅメール）あるいは、第１種郵便物のような郵便サービスを介して受け取る選択肢を患者に与える。もしファクスあるいはＥメールが希望であれば、概要と勧告を送るための情報をシステムが利用できるかを確認するために、プロセス３００は意志決定状態３５０へ進む。もしそうでなければ、プロセス３００は、情報、たとえば、ファクスの番号、電子メールアドレスあるいは郵便の住所を、状態３５２において、患者に尋ねる。患者もまたコンサルテーションの概要を患者の健康管理プロバイダーあるいは専門家に送らせる選択肢を有する。状態３５１に進んで、プロセス３００は現在の電話セッションの写しを、次の伝送のために、必要に応じてファクス待ち行列あるいは電子メール待ち行列に追加する。状態３５１の完了と共に、あるいは状態３４９においてプロセス３００がセッションの写しが送信されるべきではないと決定すれば、セッションは状態３５３において終了する。

疾患管理概観
本発明は疾患管理モジュール（ＤＭＭ）と呼ばれるコンピュータ・プログラムを有する。疾患管理モジュールは医療管理システム１００の使用者に対して自動化された医療サービスを行ういくつかの高レベル・サービス・モジュールの１つである。これに関連して、疾患管理（ＤＭ）とは疾患と呼ばれる指定された健康問題を有すると診断されている患者の継続的治療を意味する。ＤＤＭは患者の生涯を通じて治療を継続するかもしれない。ＤＭＭは、患者の疾患の進行を評価し査定し、療法を再検討し最適なレベルに調整し、治療を施し疾患の症状の突然で激しい発現に対処するための医療上の助言を患者に与えるために、患者から健康状態の測定結果を得るように患者との周期的な対話を用いて、完全に自動化された方法で疾患管理を行う。疾患管理モジュールの目標は、多大の費用を要する医療の介入を減らすような自動化された方法で患者の健康を促進することである。

ＤＭＭソフトウェアのさまざまな特徴は、疾患の管理が個々の場合によって適合できるように、患者特有の情報を蓄積し使用するために特に設計されていることである。モジュールが長い期間にわたって１人の患者を管理するにつれて、モジュールは患者とＤＭＭの接触の頻度と理由、疾患についての患者の主観的理解、さまざまな治療に対する患者の客観的反応、および治療についての患者の好みの形式でその症例についてのプロファイルを構築する。モジュールは次に、内部手続きを調整するためにその知識を使用するので、モジュールはよりいっそう個々の患者に適応する。

患者が最初にＤＭに登録された時、ＤＭＭは患者の病歴を検証する登録手続きを実行し、患者の疾患についての初期療法を初期化し、患者との接触のためにスケジュールを設定する。すべての登録されたＤＭ患者に対して、ＤＭＭは患者との周期的な自動化されたセッションを行う。各セッションの間に、ＤＭＭは最新の健康測定結果と共に患者の病歴を取得し更新し、必要に応じて患者の健康を分析し評価し、必要に応じて療法を調整し、患者に適切な医療上の助言を与える。各セッションの終了と共に、ＤＭＭは次のセッションを予定する。最終的には、人間の医者による医療、医療システムの診断モジュールによる介護、あるいは適切なフォローアップ健康診断を伴う正常な健康状態のような他の状態へ患者を移すことによって、ＤＭＭは患者を疾患管理状態から解放する。

全体的な前後関係の中で特徴を説明するために、ＤＭＭモジュールの総合的な特徴をここで要約する。各々の特徴を以下に説明する。

患者とのすべての接触において、ＤＭＭは多数の許可、同意およびさまざまな機関によって与えられた認可を遵守していることを保証しなくてはならない。ＤＭＭはこれらの規制データを管理するために認可データベースを使用している。

患者（あるいはその代理人）とのオンライン対話型の会話を行うために、ＤＭＭはスクリプトを使用している。スクリプトは、患者にテキストと質問を出力し、患者からの応答を待ち、応答を記録し、その応答に基づいて次の動作をすることができる特別なコンピュータプログラムである。スクリプトの開発と利用法は、「リストベースの処理を含むコンピュータ化された医療診断および治療助言システム」と題する１９９７年７月１１日出願の米国特許出願第０８／８９３，４０２号および「ネットワークアクセスを含むコンピュータ化された医療診断および治療助言システム」と題する１９９７年７月１１日出願の米国特許出願第０８／８９３，９１２号にもとづいて優先権主張しているＰＣＴ出願において説明されている。

患者との標準的なオンラインの会話は、スクリプトによる一連の質問と患者による回答の一般的な形式をしている。スクリプトが実行されるにつれて、スクリプトは患者の現状を考慮し、質問を選択し、患者に質問を提示する。患者は回答し、スクリプトは回答を分析し、他の質問を選択する。この過程はセッションが正常に終了するまで実行される。

ＤＭＭのためのスクリプト・プレビュー・モードは、形式的に回答を選択せずに、回答の結果がどうなるかを知るために、「ルックアヘッド」モードで患者が質問に答えることを許容する。異常なスクリプトの終了は、無応答機能を用いてインテリジェントな事前対応型の方法でＤＭＭによって処理できる。会話の途中で突然に患者が回答に失敗すれば、この機能は患者についての既知のすべて、すなわち、患者の所在および事前対応的に応答するように管理されている疾患、必要ならば患者の最も近くの緊急支援施設と連絡を取るか、あるいは患者のために９１１に電話をする能力を含めて、を使用することができる。

ＤＭＭは疾患管理セッションの形式で患者とのすべての接触を行う。疾患管理セッションは規則的に予定された患者とのオンラインの会話である。ＤＭセッションは、患者が医療システムを呼ぶ（内向き）、あるいはシステムが患者を呼ぶ（外向き）のいずれによっても開始できる。すべてのＤＭセッションは、オープンセッション、健康アセスメント、療法最適化およびクローズ・セッションの順序で行われる４つの主要なタスクから成る。

オープンセッション・タスクはデータを初期化し、患者を登録する。オープンセッション・タスクは、患者の健康歴および関連する閾値、限界、範囲および臨界値を含めて測定され追跡されるべきアセスメント健康パラメータを確立するために、管理されている疾患を使用する。またオープンセッション・タスクは、どのように症状を観察し、健康測定を行ない、患者の健康を評価し、患者の疾患の将来をみとおすかの指示を患者に与える。

最後のセッションからの期間に対する健康測定値を患者から得て、健康アセスメント・タスクはＰＱＲＳＴ配列を用いて症状の説明を符号化し、さまざまな関連する健康度数、パターンおよび傾向を計算する。健康アセスメント・タスクは、相関アセスメント機能および臨界カーブ・アセスメント機能を用いて健康状態を分析する。相関アセスメント機能は、主観的データに基づいて患者の健康を評価するために、ある患者がどれだけ上手に自分自身の疾患状態と進行を評価できるかの統計的評価基準である主観的客観的相関ファクター（ＳＯＣＦ）を使用する。ＰＱＲＳＴ配列は、痛みの症状の主観的な説明をＤＭＭ規模のディジタル化された苦痛コードに変換するために使用される符号化案である。臨界カーブは、患者の健康の急速な劣化を検出あるいは予測するために、ＤＭＭが標準の臨界カーブと比較することができる指定された健康パラメータの時間的プロットである。

最後に、健康アセスメントタスクは、人間による医療を求めるために患者をシステムから専門医にまわす、あるいは新しい症状の診断のために診断モジュール・プロセスに患者をまわす、あるいは患者に対する次の療法段階を決定するために次のタスクに進む等のどの処置を患者に対して採るべきかを決定する。

ＤＭセッションの第３のタスクは療法最適化である。療法最適化の明確な目標は、危険と利益のバランスをとる方法で療法を段階的に調整することであり、有効性を最大にし、有害な副作用を最小限度に抑え、長期にわたってこの患者に対する最適の療法に集中させる。このタスクは、治療テーブルからいくつかの可能な療法の１つを選択し、患者同意レベル機能によって制御される小さい段階で投薬を調節し、危険と利益を患者に提示し、患者に勧告を受け入れさせるか、あるいは拒否させる。患者が拒否すれば、認可データベースに蓄積されている限界に到達するまで、タスクは次々に最良の療法を計算する。そのすべての作業において、自動的に療法を修正するためにどれだけの権限を有するかを決定するために、タスクは治療改変認可レベル（ＴＡＰＬ）を調べる。もしタスクが療法を勧告するにはあまりにもわずかの権限しか有しなければ、あるいはもし患者が療法の提案をすべて拒否すれば、タスクは人間の専門医に患者をまわす。

ＤＭセッション、クローズ・セッションの最後のタスクは、アセスメント測定値、パラメータおよび決定要因のすべてを患者の病歴データベースに蓄積する。またタスクは、患者が受け入れた療法の変更を処理し、患者に関連する説明を発行し、最終的に次のセッションのために患者のスケジュールを変更する。次にタスクは、セッションの間に求められたさまざまなセッションログと報告書を出力するプロセスを開始し、最後にＤＭＭは関連するデータを退避し、現在のＤＭセッションを終了させる。次のセッションがプロセスを繰り返すまで、ＤＭＭはこの患者については終了している。

疾患管理モジュール
図５を参照して、プロセス２２０を説明する。プロセス２２０は、疾患管理モジュール（ＤＭＭ）の実行可能部分を構成する。疾患管理モジュールは、患者の既知の疾患を管理するために患者とオンラインの対話型の会話を行う。プロセス２２０は、４つのプロセス４０４、４０６、４０８および４１０から成る。ＤＭセッションは、スタートノード４０２においてプログラム２２０に制御が渡されたときに始まる。スタートノード４０２から、プロセス２２０はプロセス４０４を呼び出す。図６を参照して以下に説明するように、プロセス４０４は、初期化、ファイルのオープニングおよび登録機能を実行する。プロセス４０４がプロセス２２０に制御を戻すと、プロセス２２０は次にプロセス４０６を呼び出す。プロセス４０６は患者からの健康測定値を入力し、それを分析し、患者の現在の健康状態を評価する。プロセス４０６がプロセス２２０に制御を戻すと、プロセス２２０は次にプロセス４０８を呼び出す。プロセス４０８は患者によって受け入れられた最適な次の療法段階を計算する。プロセス４０８がプロセス２２０に制御を戻すと、プロセス２２０は次にプロセス４１０を呼び出す。プロセス４１０はさまざまな報告を出力し、セッション・データを退避し、作業用ファイルを閉じる。プロセス４１０がプロセス２２０に制御を戻すと、プロセス２２０は段階４１２に制御を渡す。段階４１２は、ノード４０２においてプロセス２２０を呼び出したプロセスに制御を戻す。

オープン・セッション
図６を参照して、プロセス４０４を説明する。プロセス４０４はＤＭセッションを実行するために必要なデータを確認する。プロセス４０４はＤＭＭにとって新規の患者を登録し、以前にＤＭセッションで実行されたことのある患者の既存のデータをロードする。最後に、プロセス４０４は疾患管理オーダー（ＤＭＯ）記録を作る。このＤＭセッションの間にＤＭＭによってなされた累積的な決定が疾患管理オーダー記録の中に蓄積される。ＤＭＯは疾患管理オーダーの章でさらに説明される。プロセス４０４はスタートノード４３０において制御を受け取る。次にプロセス２２０は決定４３２に制御を渡す。決定４３２は、患者が登録されているか、すなわち、以前にＤＭセッションを実行したことがあるかを知るために患者の識別をＤＭレジスタで調べる。もし患者が登録されていなければ、プロセス４０４は段階４３４に制御を渡し、患者が登録されていれば段階４５２に制御を渡す、段階４５２はこの章で後に説明される。

段階４３４は、患者を疾患管理のために登録する７つの連続した段階４３４、４３６、４３８、４４０、４４２、４４４、４４６の第１の段階である。段階４３４は、患者を歓迎し、患者がＤＭのための登録を始めようとしているということを患者に知らせるメッセージを出力する。次に、段階４３６は管理される疾患の名前を入力する。次に、段階４３８は、患者を代弁することができる代理人の名前、患者の医者の名前と所在、患者の近くの緊急施設の名前と電話、等を含む疾患管理を実行するために必要なデータを入力するために、患者にインタビューする。次に、段階４４０はＤＭレジストリの中に新しい患者の記録を作る。次に、段階４４２は患者を登録されたＤＭ患者として確認する。次に、段階４４４は患者のデータベースの中のＤＭＭによって使用されるための新しいデータ記録を作る。次に、段階４４６はセッション・データベースの中のセッション・データのための新しいデータ記録を作る。段階４４６は新しいＤＭ患者として患者の登録を完了する。段階４４６の後に、制御は段階４４８に進む。段階４４８は新しい疾患管理オーダー（ＤＭＯ）記録を作り、その中にこのＤＭセッションの間にＤＭＭによってなされた累積的な決定が蓄積される。患者が新たに登録されたＤＭ患者であり、初期健康アセスメントを必要とすることを示すために、段階４４８はＤＭＯを初期化する。段階４４８の後に、プロセス４０４は段階４５０に制御を渡し、段階４５０はプロセス４０４を呼び出したプロセスに制御を戻す。

さて段階４５２におけるプロセス４０４の説明を続ける。段階４５２は患者データベースから患者の医療記録を検索する。段階４５２の後に、制御は段階４５４に渡り、段階４５４はこの患者に対する最後のＤＭセッション・データをセッション・データベースからロードする。段階４５４の後に、制御は段階４５６に渡り、段階４５６は最後のセッションが正常に終了したことを確認し、正常に終了していなければ適切な制御データを設定する。段階４５６の後に、制御は段階４５８に渡り、この患者が次の処理で現在の健康アセスメントを必要とすることを示すために、段階４５８はＤＭＯを初期化する。段階４５８の後に、制御は段階４５０に渡り、段階４５０はプロセス４０４を呼び出したプロセスに制御を戻す。

健康アセスメント
図７を参照して、プロセス４０６を説明する。プロセス４０６はＤＭセッションのために健康アセスメントを実行する。プロセス４０６は基本的に患者の健康アセスメントを実行する他のプロセスを呼び出すステージング・プロセスである。プロセス４０６はスタートノード４８０において制御を受け取る。ノード４８０の後で、プロセス４０６はプロセス４８２を呼び出し、プロセス４８２は、重大症状フィルターと命名され、図８に関連して以下に説明される。プロセス４８２が制御を戻すと、プロセス４０６は試験４８４に制御を渡す、試験４８４は、この患者が新しいＤＭ登録者であるか、あるいは再診ＤＭ患者であるかを決定するために、ＤＭＯ記録コードをテストする。新しい患者に対しては、プロセス４０６はノード４８８を呼び出す。ノード４８８は新たに登録された患者の健康を評価する。ノード４８８は図１０を参照して以下に説明される。現在の患者に対しては、プロセス４０６はノード４９０を呼び出す。ノード４９０は再診ＤＭ患者に対して健康アセスメントを実行する。ノード４９０は図１１を参照して以下に説明される。新しい患者あるいは再診患者に対する健康アセスメントが完了した後、プロセス４０６はノード４９２において制御を戻す。

重大症状フィルター
図８を参照して、プロセス４８２を説明する。プロセス４８２は、患者の現在の健康状態を分類し、特有のアセスメントの必要性とその理由を決定し、このアセスメントを次のＤＭプロセスに転送するために、いくつかのテストを患者の現在の症状に適用する。これらの必要性は患者のＤＭＯに退避される、患者のＤＭＯは次のＤＭＭルーチンによって処理される。ＤＭＯ記録は疾患管理オーダーの章で後に説明される。

プロセス４８２はスタートノード５１０において制御を受け取る。そこから、プロセス４８２はテストノード５１２に制御を渡す。テストノード５１２は、患者が現時点で重大な症状を有するかどうかを尋ねることによる第１のフィルターを表す。もし患者が重大な症状を有していなければ、患者は自動化された手段によって評価されることができ、したがってプロセス４８２は段階５４４に制御を渡す。この患者の健康が次のルーチンによってさらに評価される必要があることを示すための、ＤＭＯ記録コードを設定する段階５４４。制御はノード５２６を介して戻る。

もし、ノード５１２において、患者が現在重大な症状を有するなら、プロセス４８２は、患者が現在管理されている疾患に関係する症状を有するかどうかを決定する必要がある。これを行うために、プロセス４８２は第１に段階５１４に制御を渡し、段階５１４は患者から症状を入力し、関連する症状のテーブルでそれを調べる。プロセス４８２は次にテスト５１６に制御を渡し、もしその症状が現在管理されている疾患に関連していれば、テスト５１６はノード５２０に分岐する。症状が現在管理されている疾患に関連していなければ、プロセス４８２はノード５３０に分岐する。これは第２のフィルターを完了する。第２のフィルターは、ここで重大な関連する症状を有する患者と、有しない患者を識別する。

もし、ノード５１６において、患者が関連する症状を有するなら、プロセス４８２は、関連する症状が軽いか、重大かをさらに分類するために、重大度アセスメント機能５２０を呼び出す。重大な関連する症状を有する患者に対して、プロセス４８２は段階５２２に制御を渡し、段階５２２はこれまでの調査結果を示すためにＤＭＯ記録を設定する。段階５２２から制御はノード５２６を介して戻る。しかしテスト５２０において症状が軽いと判定されれば、プロセス４８２はノード５２４に制御を渡し、ノード５２４は、標準的な健康アセスメントの必要性を示すために、ＤＭＯ記録を設定する。ノード５２４から、プロセス４８２はノード５２６を介して制御を戻す。

もし、ノード５１６において、患者が関連する症状を有しなければ、プロセス４８２は患者の現在の療法に関連する副作用を患者が持っているか否かを決定する必要がある。これを行うために、プロセス４８２は第１に段階５３０に制御を渡し、段階５３０は現在の療法の副作用のテーブルの中で患者の症状を調べる。プロセス４８２は、次にテスト５３２に制御を渡す、テスト５３２は副作用症状を決定するフィルターである。もし患者の症状が副作用であれば、プロセス４８２は、副作用が軽いか、あるいは重大であるかを分類するために、重大度アセスメント機能５２０を呼び出す。軽い副作用に対しては、プロセス４８２はノード５３６に制御を渡し、ノード５３６は次の処理によって評価されるＤＭＯ記録を設定する。重大な副作用に対しては、プロセス４８２は第１に制御を段階５３４に渡し、段階５３４は患者をシステムから人間の医者にまわすためにＤＭＯ記録を記録し、次にノード５２６を介して呼び出しているプロセスに戻る。

もし、試験５３２において、患者の症状が副作用ではなければ、その症状は、現在管理されている疾患、あるいは適用されている療法のいずれにも無関係な重大な症状である。プロセス４８２は、その症状が軽いか、あるいは重大かを分類するために、重大度アセスメント機能５２０を呼び出す。軽い症状に対しては、プロセス４８２はノード５４２に制御を渡し、すべてのＤＭ処理が行われた後に患者との特別な論議を意図的に行うために、ノード５４２はＤＭＯ記録フラグを設定し、また論議の理由を記録する。次にプロセス４８２は、次の健康アセスメントを強制するためにＤＭＯ記録を設定するノード５４４にまず制御を渡し、次にノード５２６に制御を渡す、ノード５２６はプロセス４８２を呼び出したプロセスに戻る。重大で関連の無い症状に対しては、プロセス４８２は段階５４０に第１に制御を渡す。段階５４０は、患者をシステムから人間の医者にまわすためにＤＭＯ記録を記録し、次にノード５２６を介して呼び出したプロセスに戻る。

重大度アセスメント
図９を参照して、重大度アセスメント機能５２０を説明する。この機能は、所定の症状をＤＭアセスメントに対して軽いと考えるか重大と考えるかを決定するために、多数の基準を用いる。機能５２０はスタートノード５６０において制御を受け取る。スタートノード５６０において機能５２０は、一連の６つの連続した段階を開始し、次に計算結果を返す。第１に、機能５２０はノード５６２に制御を渡す。ノード５６２は症状の重大度を０から１０までの尺度上で評価するように患者に質問する。次に機能５２０はノード５６４に制御に渡す。ノード５６４は症状データベースから症状自身の絶対重大度尺度を得る。異なる症状は異なる重大度尺度を有し、患者の評価はここで症状の評価と照合される。その結果、次に、機能５２０はノード５６６に制御を渡す。ノード５６６は、患者の評価を症状の重大度尺度で表現されるように正規化する。次に、機能５２０はノード５６８に制御を渡す。ノード５６８は、ＤＭＭの現在の感度設定によって正規化された重大度尺度を上または下へ調整するために、感度ファクター・セットを用いる。上に述べたように、感度が高いほど、システムのアセスメントは控えめになる。最も低い感度設定においては、すべての症状の重大度尺度は軽いと考えられる。次に、機能５２０はノード５７０に制御を渡す。ノード５７０は最終調整尺度を軽いか、重いかの２つの分類に変換する。この最終段階が、他の状況においては、最終の尺度を任意の数の等級に分類できることを指摘することは重要である。しかし現在のアセスメントの目的のためには、症状は軽いか、重いかに分類されなければならない。次に、機能５２０はノード５７２に制御を渡す。ノード５７２は呼び出しているプロセスに「軽症」あるいは「重症」のいずれかに対するコードを返す。

初期健康アセスメント
図１０を参照して、プロセス４８８を説明する。このプロセスは、誰が患者の最初の疾患管理セッションをするのか、患者に対して健康アセスメントを実行する。プロセス４８８はノード６００において制御を受け取る。次にプロセス４８８はノード６０２に制御を渡す。ノード６０２は管理されようとしている疾患に対する健康アセスメント仕様書を疾患データベースからロードする。これらの仕様書は、患者説明、治療の選択肢、必要とされる認可等のような、疾患管理セッションで使用されるさまざまなパラメータを有する。これらの値が得られた後に、プロセス４８８はノード６０４に制御を渡す。ノード６０４は患者の病歴とセッション・データベースの中のＤＭセッション部分を初期化する。次に、プロセス４８８はノード６０６に制御を渡す。現在の健康の主観的な評価、患者が持っているかもしれない客観的健康測定値、既存の療法あるいは副作用等、について患者に質問するために、ノード６０６は初期健康インタビューを実行する。次にプロセス４８８はノード６０８に制御を渡す。ノード６０８は呼びだしているプロセスに制御を返す。

現在の健康アセスメント
図１１を参照して、プロセス４９０を説明する。このプロセスは患者から現在の健康データを、主観的（すなわち、患者が認知しているか、感じている）、客観的（すなわち、患者が測定している、通常計測器具で）、患者が気付いている副作用の３つの形式で得る。これらの健康測定値は現在の健康状態を分析するために次に使用される。プロセス４９０はノード６２０において制御を受け取る。ノード６２０からプロセス４９０はテスト６２２に制御を渡す。テスト６２２は、どんな処理がなされたか、何をする必要があるかを決定するために、患者の現在のＤＭＯ記録を調べる。ＤＭＯ記録コードが健康アセスメントが必要であることを示さなければ、プロセス４９０はノード６３４に制御を渡し、ノード６３４は呼び出しているプロセスに制御を返す。健康アセスメントが必要であれば、プロセス４９０はさまざまな健康アセスメントを得る一連の５つの段階に制御を渡す。第１に、プロセス４９０は段階６２４に制御を渡す。段階６２４は患者の現在の健康状態の主観的な評価を患者に求める。次に、プロセス４９０は段階６２６に制御を渡す。段階６２６は患者の現在の健康状態の客観的健康測定値を患者に求める。次に、プロセス４９０は段階６２８に制御を渡す。段階６２８は現在の副作用を患者に求める。次に、プロセス４９０は相関アセスメント機能６３０を呼び出す。この機能は図１２と関連して説明される。次に、プロセス４９０は臨界カーブ・アセスメント機能６４０を呼び出す。この機能は図１３と関連して説明される。次にプロセス４９０は段階６３２に制御を渡す。段階６３２は呼び出しているプロセスに制御を返す。

相関アセスメント
図１２を参照して、プロセス６３０を説明する。

この機能は、最近追加されたデータに対してＳＯＣＦを計算し標準化し、他のアセスメント・パラメータおよび統計値を計算し、患者の病歴を更新する。最後に、この機能は、この前のセッションからの間のデータのギャップを埋めるために、健康アセスメント機能を再び呼び出す。

プロセス６３０はスタートノード６５０において制御を受け取る。次にプロセス６３０は制御を段階６５２に渡す。段階６５２はこの前のＤＭセッションから患者の病歴に追加されている新しい健康データを得る。次にプロセス６３０は段階６５４に制御を渡す。段階６５４は、同じ時間の間の主観的測定値対客観的測定値の比をとることによって、未処理のＳＯＣＦ時間プロット上の新しい点を計算し、未処理のＳＯＣＦ時間プロット配列を新しい点で更新する。次にプロセス６３０は段階６５６に制御を渡す。段階６５６は、未処理のＳＯＣＦ点を正規化し、１つの現在のＳＯＣＦを得るために、標準の統計的正規化技法および曲線あてはめ技法を適用する。このＳＯＣＦは、患者の主観的なアセスメントが客観的健康測定値に適合する傾向のある患者では高く、患者の主観的なアセスメントが客観的健康測定値に比較して不正確な傾向のある患者では低い。段階６５６はさらに、直近の３つのデータポイントに対する傾斜および傾斜の傾向および、患者の測定と標準的な測定の間の差のような、ＤＭセッションの残りの部分で使用される他のパラメータを計算する。段階６５６はさらに、患者の健康データに、インターバル・アセスメントによって、さかのぼって満たされる必要がある大きなギャップがあるかどうかを決定する。段階６５６は、他のアセスメントを呼び出すために、適切にＤＭＯコードを設定する。次にプロセス６３０は段階６５８に制御を渡す。段階６５８は計算されたアセスメント・パラメータで患者の病歴を更新する。次にプロセス６３０はテスト６６０に制御を渡す。テスト６６０は、欠けている中間のデータに対して患者の健康を再評価するべきかどうかを決定する。テスト６６０がさらにアセスメントの必要はないと決定すれば、プロセス６３０はターミナル・ノード６６２に制御を渡す。ターミナル・ノード６６２は呼び出しているプロセスに制御を返す。テスト６６０がもう一度健康アセスメントが必要であると決定すれば、プロセス６３０はテスト６６４に制御を渡す。テスト６６４はインターバルに対して再評価すべきデータの形式を決定する。テスト６６４が客観的データが利用できると決定すれば、プロセス６３０は健康アセスメント・プロセス４９０を呼び出し、インターバルに対して評価すべき主観的および客観的な患者の健康データの両方を求めるパラメータを渡す。次にプロセス６３０はターミナル・ノード６７４に制御を渡す。ターミナル・ノード６７４は呼び出しているプロセスに制御を返す。テスト６６４が客観的データが利用できないと決定すれば、プロセス６３０は、健康アセスメント・プロセス４９０を呼び出し、インターバルに対して求めるべき主観的な患者の健康アセスメントのみを求めるパラメータを渡す。ただ主観的な患者健康アセスメントのみがそのインターバルのために得られることを求めるパラメータを渡して、次にプロセス６３０はターミナル・ノード６７２に制御を渡す。ターミナル・ノード６７２は呼び出しているプロセスに制御を返す。

臨界カーブ・アセスメント
臨界カーブ・アセスメントは重大な悪化に対して患者の健康を監視するＤＭＭプロセスである。臨界カーブは、健康状態の重大な変化を識別するために使用される、時間に対する健康測定値のプロットとして定義される。臨界カーブ・アセスメント・プロセスは、疾患特有および患者特有の健康パラメータを選択し、臨界カーブとしてそれをプロットし、継続的なＤＭセッションの標準的な部分として臨界カーブを更新し、患者の臨界カーブが特有の臨界点、傾斜、および傾斜の傾向を示せば特有の動作をする。このプロセスは患者の臨界カーブを標準の疾患特有の臨界カーブと比較することに基づいて行なわれる。一定の、高い縦座標値は良い健康を示し、低下しているカーブは低下している健康を示し、カーブの急激な低下は健康の危機を示す。カーブ上の「クリティカル・ポイント」は健康の重大な低下を予測する点である。

一般的な臨界カーブの例を図２３に示す、図には「クリティカル・ポイント」として囲まれた点が示されている。図２３を参照すると、クリティカル・ポイントにおいて、カーブの傾斜（すなわちクリティカル・ポイントにおけるカーブに対する接線）は急激に低下していることに気付くであろう。これは次の健康測定値がクリティカル・ポイントより低いであろうことを予測している。さらに、クリティカル・ポイントにおいて、傾斜変化の率も負であるかもしれず、これはカーブの傾斜がさらに減少していることを示し、傾斜変化の率は急速に悪化している健康状態を予測している。簡単のために、これらの３つの臨界試験項目は、通常ＤＭＭプロセスにおいて、クリティカル・ポイント、傾斜および傾向と呼ばれている。それらは最近の３つの健康測定ポイントを用いて計算される。十分なデータポイントを有する臨界カーブに対しては、曲線あてはめ技法を使用することもできる。

ＤＭＭは、さまざまな疾患、患者集団および健康パラメータに対する標準の臨界カーブが入っている疾患データベース２６２（図３）を有する。臨界カーブ・アセスメント・プロセスは、適切な疾患データセットを抽出し、使用すべき適切な健康パラメータを選択し、それを現在の患者に対して適用し、現在の患者に対する標準のカーブとして患者の病歴２５４（図３）に退避する。ＤＭＭが周期的に患者と対話するにつれて、臨界カーブ・アセスメント・プロセスは、患者から現在のデータを得て、患者の臨界カーブ上にそれをプロットし、患者の実際のＣＣを患者の標準のＣＣと比較するために曲線あてはめ技法およびパターン照合技法を使用する。この比較は、重大な切迫した健康の衰えを予測する「クリティカル・ポイント」のような、患者のカーブのキーポイントと傾向をＤＭＭが検出することを可能にする。カーブがこのクリティカル・ポイントに接近しているとき、臨界カーブ・アセスメント方法は予測される悪化を防止する療法に変更を命じるか、あるいは患者を健康管理プロバイダーに差し向けるようにフラグを設定する。特に主観的・客観的相関ファクター（ＳＯＣＦ）が高ければ、（これは、患者の疾患プロセスが良く、ＤＭＭが患者の応答にますます頼ることができることを、患者が知っていることを意味する）ＣＣをプロットするために客観的および主観的健康データが共に使用される。

ホメオスタシス
クロード・バーナードによって説明されたホメオスタシスの概念は、臨界カーブおよびその分析の背景にある概念を理解する助けになる。簡単に言えば、ホメオスタシスとは体の機能的な平衡の状態である。この平衡は、一定のシステム・パラメータを所望の範囲に留めることを強制するさまざまな内部の制御機構によって維持されている。これらのホメオスタシス機構を用いて、身体は疾患を一定の点まで許容することが可能であり、またその時において疾患の進行が加速し始める。これの良い例が：
・血液のｐＨを維持するための重炭酸塩バッファリング・システム、
・オキシヘモグロビン分離カーブ、および
・慢性閉塞性肺疾患を持つ患者の悪化である。

臨界カーブ
臨界カーブ（ＣＣ）は、疾患の発作の間の患者の健康状態を説明する。臨界カーブは、時間に対する患者の健康状態をプロットし、健康の（高い）標準的な状態から始まり、疾患が進行するにしたがって、低い健康状態に低下する。

正常で、疾患の無い患者は、高い健康レベルでかなり安定したプロットを有するであろう。予備能力と内部の防衛機構を用いることによって、しばしば健康な身体はしばらくの間疾患を抑えることができるから、カーブの初期の部分は標準的な健康に漸近的である。初期フェーズの後に、予備能力を使い果たし、疾患が発見され２次的効果を生ずるにつれて、健康カーブは険しい角度で下降し始める。一定の臨界点において、カーブは非常に劇的に急勾配になるので、患者の状態は速く悪化するかもしれない。

多くの生理学的パラメータは、ある点までは補償が可能であり、次に疾患の進行の中での小さい変化に対する信号の発見において非常に大きい変化で応答するという、変化に対する特徴的な応答を有する。この患者の疾患の発現が加速しようとしているならば、重大な介入が必要であるから、患者が臨界カーブ上のどこにいるかを知ることは非常に重要である。患者の状態が健康カーブの険しい領域に接近しているという徴候あるいはその疑いがあるときは、ＤＭＭは療法の変更あるいは患者の介護人とのコンサルテーションを勧告することができる。健康状態の変化の確認が必要であれば、勧告を行う前に、ＤＭＭの再入特徴がＤＭＭシステムに仮説の確認を許容する。

臨界カーブ分析
適当な維持療法で家庭において疾患を管理している既知の疾患を有する患者に対しては、ＤＭＭは患者の周期的な接触と健康状態の報告を監視する。傾向ラインが患者の健康カーブがクリティカル・ポイントに到達しつつあることを示すと、ＤＭＭは療法を変更するか、および／または患者の医者に通知することができる。患者は何カ月間も成功裏に疾患を管理して行くことができるから、このカーブ分析方法はかなりの数の不必要な医者の訪問を省くことができ、その上に健康状態の変化がクリティカル・ポイントが接近しつつあることを示すときに、医者と患者に同時に通知することができる。

明らかに、容易に定量化可能なパラメータを、このカーブを具体化するための当該の疾患の進行に対するマーカーとして用いることが最良であるが、所定の患者において主観的・客観的相関が高ければ、患者の主観的な評価は同じことを達成することができる。

本システムは１回呼吸量とピーク流量を長時間にわたって測定する。もし１回呼吸量のわずかな変化が、患者の印象において患者の疾患の重大度の大きい差となることが判明すれば、（この患者の以前の変化と比較して）、患者はカーブの険しい部分にいる。フラグが設定され、重大な介入が必要である。

治療改変認可レベルが低く設定されていれば、患者は彼の医者にまわされ、患者の医者は報告、頻繁にファクス、電子メールを受け取るか、あるいは新しい展開についてダウンロードする。治療改変レベルが高く設定されていれば、患者が医者に会う前に、治療の最適化が起こるかもしれない。報告がその医者に送られ、患者に会う必要はあるかもしれないが、ないかもしれない。

健康状態の「カーブ」分析を構成するものは、この分析であり、この関係の認識である。

例：慢性閉塞性肺疾患
例として慢性閉塞性肺疾患について述べる。慢性閉塞性肺疾患はゆっくりと肺組織を破壊する。前述のように、多くの生理学的パラメータは変化に対して同じ反応を有し、ある点までは補償が可能であって、予備能力がなくなった後は、疾患状態の非常に小さい変化が、患者の初期フェーズでは疾患の進行の発現の非常に大きい変化を生ずる。慢性閉塞性肺疾患を有する患者は予備の肺容量のみを失うので、静止している健康状態に重大な変化はない。予備の組織が破壊された後では閾値に達しており、それから先はますます少ない時間差（と疾患プロセスの進行）が、二酸化炭素を吐き出し血液に酸素を送り込む患者の能力にますます多くの重大な悪化を招く。究極的には、慢性閉塞性肺疾患の非常に小さな変化でさえ呼吸器の機能不全をもたらす。

時間に対してプロットされた肺機能のますます大きい減少が見え始めたとき、患者はカーブの臨界部分に到達しつつある。重大な介入が必要であり、可能な限り早急に開始されるべきである。

臨界カーブ・アセスメント・プロセスは次の理由でＤＭＭ設定に特に有効である。
・ＤＭＭは完全に自動化されている。
・ＤＭＭは患者の健康を、時間を追って追跡している。
・ＤＭＭは患者との接触を追跡し相関関係を算定するさまざまなモジュールを有する。
・ＤＭＭは患者（病歴、主観的・客観的相関要素）を知っている。
・ＤＭＭは医療知識のデータベースにアクセスを有する。
・ＤＭＭは数学的傾向変動分析を用いて、疾患の進行を分析できる。
・ＤＭＭは状態の変化に応じて代わりの療法を選択できる。

図１３を参照して、臨界カーブ・アセスメント機能６４０を説明する。この機能は２つのフェーズを有する。第１のフェーズ（ノード７０２から始まる）は、直前の臨界カーブ・アセスメント以来の患者の病歴に、健康測定値を追加して、患者の臨界カーブを更新する。第２のフェーズ（ノード７１２から始まる）は、患者の実際の臨界カーブをこの患者に対して使用される標準の臨界カーブと比較する。患者がカーブの臨界部分にあれば（あるいは接近しつつあれば）、これは管理されている疾患の急速な悪化の可能性を示唆しており、患者はコンサルテーションのために人間の医者にまわされる。

プロセス６４０はスタートノード７００において制御を受け取る。次にプロセス６４０は段階７０２に制御を渡す。段階７０２は新しい健康測定値で患者の実際の臨界のカーブを更新する。次に、プロセス６４０は段階７０４に制御を渡す。段階７０４は、最新の臨界カーブポイント、傾斜および３点傾向を得るために、患者の更新された臨界カーブを分析する。次にプロセス６４０は段階７０６に制御を渡す。段階７０６は患者の臨界カーブのデータを患者の病歴に退避する。次に、プロセス６４０はテスト７０８に制御を渡す。テスト７０８は、患者の臨界点が評価されるべきかどうかを知るために、ＤＭＯ記録コードを調べる。患者の臨界点が評価されるべきでなければ、プロセス６４０はターミナル・ノード７１０に制御を渡す。ターミナル・ノード７１０は呼び出しているプロセスに制御を返す。テスト７０８が健康アセスメントが必要であることを示すなら、プロセス６４０は段階７１２に制御を渡す。

段階７１２はプロセス６４０のアセスメント・フェーズを開始する。段階７１２は、患者の健康を評価するために、臨界カーブを使用するために必要な作業データを検索、あるいは計算する。作業データは、患者の最近の実際の健康ポイントおよび傾斜、患者の標準の臨界カーブ上の整合点と傾斜、および各セットに対して臨界であると患者を指導するために使用された閾値を有する。段階７１２がこれらの作業データを計算すると、プロセス６４０はテスト７１４に制御を渡す。

テスト７１４は患者のクリティカル・ポイントを調べる一連の段階を開始する。テスト７１４が患者の最近の健康ポイントが利用できないか、あるいは標準のカーブに整合することができないことを知れば、プロセス６４０はターミナル・ノード７１６に制御を渡し、ターミナル・ノード７１６は呼び出しているプロセスに制御を渡す。テスト７１４が最近の健康ポイントが利用できると決定すれば、次にプロセス６４０は段階７１８に制御を渡す。段階７１８は実際と標準の臨界健康点の間の差を比較する。次にプロセス６４０はテスト７２０に制御を渡す。テスト７２０が、患者がクリティカル・ポイント閾値に達しているか、あるいは越えていることを知れば、プロセス６４０は段階７２２に制御を渡す。段階７２２は、患者をコンサルテーションのために人間の医者にまわすために、ＤＭＯ記録を設定する。次にプロセス６４０はターミナル・ノード７２４に制御を渡す。ターミナル・ノード７２４は呼び出しているプロセスに制御を返す。テスト７２０が患者がクリティカル・ポイント閾値に達していないことを知れば、プロセス６４０はテスト７２６に制御を渡す。

テスト７２６は患者の臨界の傾斜を調べる一連の段階を開始する。テスト７２６が臨界の傾斜が利用できないと決定すれば、プロセス６４０はターミナル・ノード７２４に制御を渡す。ターミナル・ノード７２４は呼び出しているプロセスに制御を返す。テスト７２６が実際の傾斜が利用できると決定すれば、プロセス６４０は７２８に制御を渡す。７２８は実際と標準の臨界の傾斜の間の差を比較する。次にプロセス６４０はテスト７３０に制御を渡す。テスト７３０が患者が臨界の傾斜閾値の下にいると決定すれば、プロセス６４０はノード７２４に制御を渡す。ノード７２４は呼び出しているプロセスに制御を返す。テスト７３０が患者が臨界の傾斜閾値に達しているか、あるいは越えていると決定すれば、プロセス６４０はノード７３２に制御を渡す。ノード７３２は、患者をコンサルテーションのために人間の医者にまわすために、ＤＭＯ記録を設定する。次にプロセス６４０はノード７２４に制御を渡す。ノード７２４は呼び出しているプロセスに制御を返す。

療法最適化
療法最適化は、セッションからセッションへと、有効性を最大にし、有害な副作用を最小限度に抑える長期目標で患者療法を評価し調整し、また患者の協力と勧告された療法の受け入れを維持する一組のプロセスから成る。療法最適化プロセスは、医療治療表から療法パラメータを選択し、主観的および客観的な患者の健康データをセッションからセッションへと評価することによって患者特有の有効性を追跡する。療法最適化プロセスは複数の治療から選択する。療法最適化プロセスは、患者に代わりの療法の選択を提供することによって、また患者が適切な快適さを見いだすまで療法投薬レベルを調整することによって、副作用を最小限度に抑えようと努める。ＤＭＭと患者の間の意見の相違は、対面コンサルテーションと助言のために患者を人間の医者にまわすことによって、解決される。療法最適化は、ＤＭＭが療法を変更しなければならない自律性の量を指定するＤＭＭ全体にわたる変動要因である、療法最適化認可レベル（ＴＡＰＬ）によって案内され制御される。ＴＡＰＬは以下の別な章で説明される。

患者の健康状態が評価された後に、療法最適化プロセスは、正常な健康の回復の総合的な目標のいくつかの副目標の最良の組み合わせを実現するために、（ＴＡＰＬが許容する程度まで）患者の治療を評価し調整する。療法最適化プロセスはさらに治療の副作用を最小限度に抑えようと努める。現在のＴＡＰＬ設定によって許容される程度に、ＤＭＭは薬物療法の服用量を、利益／副作用比率が最大になるまで、徐々に滴定する。その総合的な理念は所望の生理学的変化を最少の副作用で実現することである。初期の治療は疾患、年齢および性別に基づいて治療テーブルから選択される。治療に対する反応が患者によって広範囲にわたるため、所定の疾患に対してひとたび薬が療法として選択されると、異なる処方、服用量、管理方法およびタイミングは、結果において、特定の患者に対しては試行錯誤の問題である。療法を再検討するために、療法最適化タスクは、差を検出し分析するために、患者の現在の療法を治療テーブルと比較する。もし新しい治療が利用できれば、患者と介護人に通知され、療法はＴＡＰＬによっては変えられるかもしれない。治療の結果を最大にし副作用を最小限度に抑えるために、機能は、初期の療法を選択し、患者の現在の療法を再検討し、療法のさまざまなパラメータを調整し、これらの変化の効果を監視することができる。

変更できる療法パラメータは、薬のクラス、形式、銘柄、服用量、ルート、薬の管理モード、処方、タイミングおよび頻度を含む。これらのそれぞれが修正されるにつれて、療法の現在の修正が患者をより良くするかどうか等を知るために、患者の健康データおよび副作用が確認される。療法パラメータの総合的な最良の組み合わせを発見するために、各療法パラメータは試行錯誤ベースで連続的に変えられる。ＤＭＭが患者の療法を調整するとき、通常は療法あるいは服用量の少数の繰り返しのうちにシステムに再び入るように患者に指示して、ＤＭＭはＤＭセッション・スケジュールを適切に調整する。

副作用の最小化は療法最適化プロセスの特別な目標であり、療法の望ましくない副作用を低減しようと努める。このタスクは、療法最適化特徴に対してＤＭＭによって使用された複雑な試行錯誤方法を明らかにする。例１：がん患者において、化学療法を受けている患者が副作用は疾患の進行を遅くする価値を持っていないと決心する点がある。その時点で、これ以上の増加は無益であると知って、１人は「引き下がる」（量を減少させる）。もし複数の薬が必要とされれば、プロセスはより複雑になる、しかし同じ関係が持続する。例２：アルブテロールを計量供給されている服用量吸入麻酔器は、ぜんそく患者がゼーゼー息をするのを助ける、しかしある一定の患者特有の服用量において、副作用が悪化し患者が許容できなくなる。その時点で、有効性対副作用の最良の比率を得るために服用量は小刻みに引き下げられる。

図１４を参照して、療法最適化プロセス４０８を説明する。プロセス４０８はＤＭセッションの療法フェーズを実行する。このフェーズは、２つの主要な従属的プロセスおよび患者がその中の１つを受け入れるまでさまざまな治療を試みるループを用いて、患者に受け入れられる次善の療法段階を計算する。プロセス４０８の一般的な目標は、有効性を最大にし、副作用を最小限度に抑え、患者の快適度レベルを満たすように、療法の形式とモダリティーを調整することによって、長期にわたって療法を最適化する方法で療法段階を選択することである。プロセス４０８はスタートノード７６０において制御を受け取る。次に、プロセス４０８はテスト７６２に制御を渡す。テスト７６２は、このＤＭセッションの初期の部分の間に、患者が現在の客観的健康測定値を提供したかどうかをテストする。テスト７６２が患者が現在の客観的健康データを提供しなかったことを知れば、プロセス４０８はテスト７８２に制御を渡す。テスト７８２は患者がＤＭセッションの初期の部分の間に患者の健康の主観的な評価を入力したかどうかをテストする。テスト７８２が患者が主観的な健康アセスメントを提供したことを知れば、プロセス４０８はプロセス７９０を呼び出す。プロセス７９０は現在の主観的な健康データに基づいて療法を調整する。図１５と関連して以下にプロセス７９０について詳述する。プロセス７９０が制御を返すと、プロセス４０８はターミナル・ノード７９２に制御を渡す。ターミナル・ノード７９２は呼び出しているプロセスに制御を返す。テスト７８２が患者が現在の主観的な健康アセスメントを提供していないことを知れば、プロセス４０８は７８４に制御を渡す。７８４はコンサルテーションのために患者を人間の医者にまわすために、ＤＭＯ記録を設定する。次に、プロセス４０８はターミナル・ノード７８６に制御を渡す。ターミナル・ノード７８６は呼び出しているプロセスに制御を返す。

テスト７６２が患者が現在の客観的健康データを提供していることを知れば、プロセス４０８は段階７６４に制御を渡す。段階７６４は、患者がその中の１つを受け入れるまで、あるいは、リトライの数が使い尽くされるまでのいずれかまで、さまざまな治療を試みるループを初期化する。段階７６４は、この患者に対する認可データベースから、許容される療法の最大数を得る。次に、プロセス４０８はプロセス７７０を呼び出す。プロセス７７０は、この患者に対する治療テーブルから次善の療法を選択し、それを患者に提供する。患者はそれを受け入れるか、あるいは修正するか、あるいは拒否することができる。プロセス７７０を図１６と関連して以下にさらに説明する。プロセス７７０が制御を返すと、プロセス４０８はテスト７７２に制御を渡す。テスト７７２が勧告された療法を患者が受け入れたと決定すれば、プロセス４０８はターミナル・ノード７８０に制御を渡す。ターミナル・ノード７８０は呼び出しているプロセスに制御を返す。

テスト７７２が勧告された療法を患者が拒否したと決定すれば、プロセス４０８はテスト７７４に制御を渡す。テスト７７４がループ・リトライ度数が１より大きいと決定すれば、プロセス４０８は段階７７６に制御を渡す。段階７７６はループ・リトライ度数を１だけ減算し、次に、ループをもう１度繰り返すために、プロセス４０８はプロセス７７０を再び呼び出す。テスト７７４がリトライ度数が１であると決定すれば、次にプロセス４０８は段階７７８に制御を渡す。段階７７８は、コンサルテーションのために患者を人間の医者にまわすために、ＤＭＯ記録を設定する。次に、プロセス４０８はターミナル・ノード７８０に制御を渡す。ターミナル・ノード７８０は呼び出しているプロセスに制御を返す。

療法調整（主観的）
図１５を参照して、プロセス７９０を説明する。プロセス７９０は、この患者の健康の患者の主観的な評価にのみ基づいて、この患者に対する次善の療法を計算する。プロセス７９０は、主観的・客観的相関ファクターの章で以下に説明される主観的・客観的相関ファクター（ＳＯＣＦ）を用いる。ＳＯＣＦは、患者自身の疾患を主観的に評価することにおいて、この患者がどれぐらい信頼性が高いかを示し、プロセス７９０は次の療法段階を計算するのに、ＳＯＣＦに依存している。

プロセス７９０はスタートノード８１０において制御を受け取る。次に、プロセス７９０はテスト８１２に制御を渡す。テスト８１２が患者が療法調整を必要としないと決定すれば、すなわちこの患者のＤＭＯ記録は認められた療法に対してすでに完了していれば、プロセス７９０はターミナル・ノード８１４に制御を渡す。ターミナル・ノード８１４は呼び出しているプロセスに制御を返す。テスト８１２が、この患者が療法最適化を要すると決定すれば、プロセス７９０はテスト８１６に制御を渡す。テスト８１６は現在患者が症状を有するかどうかを決定する（患者が質問されたことがあるかを、患者に尋ねることによって、あるいは患者の退避されている回答を得ることによって）。テスト８１６がその患者に症状がないことを知れば、プロセス７９０はテスト８１８に制御を渡す。テスト８１８が現在のＤＭＭ・ＴＡＰＬ設定が療法調整を許容しないと決定すれば、プロセス７９０はノード８２６に制御を渡す。ノード８２６は同じ療法、たとえば、薬ベースの療法の場合には同じ服用量、を維持するためにＤＭＯ記録を設定する。次に、プロセス７９０はターミナル・ノード８２４に制御を渡す。ターミナル・ノード８２４は呼び出しているプロセスに制御を返す。

テスト８１８が、現在のＴＡＰＬ設定が療法調整を許容すると決定すれば、プロセス７９０はテスト８２０に制御を渡す。テスト８２０が、患者は服用量を減少しようとすることを望まないと決定すれば、プロセス７９０は段階８２６に制御を渡す。段階８２６は、同じ療法を維持するためにＤＭＯ記録を設定する。次に、プロセス７９０はターミナル・ノード８２４に制御を渡す。ターミナル・ノード８２４は呼び出しているプロセスに制御を返す。テスト８２０が患者は服用量を減少することを望んでいると決定すれば、プロセス７９０は段階８２２に制御を渡す。段階８２２は次に低い服用レベルを治療テーブルで検索し、服用量を減少させるためにＤＭＯ記録を設定する。次に、プロセス７９０はターミナル・ノード８２４に制御を渡す。ターミナル・ノード８２４は呼び出しているプロセスに制御を返す。

テスト８１６が現在患者が症状を有することを知れば、プロセス７９０はテスト８３０に制御を渡す。テスト８３０がＴＡＰＬが療法の変化を許容しないことを知れば、プロセス７９０は段階８３２に制御を渡す。段階８３２は、コンサルテーションのために患者を人間の医者にまわすためにＤＭＯ記録を設定する。次に、プロセス７９０はターミナル・ノード８３３に制御を渡す。ターミナル・ノード８３３は呼び出しているプロセスに制御を返す。テスト８３０がＴＡＰＬが療法の変化を許容すると知れば、プロセス７９０は段階８３４に制御を渡す。

段階８３４は、プロセス７９０のうち、症状を有する患者に対して次の療法段階を計算するフェーズを開始するが、現在の主観的健康アセスメントのみを報告している。段階８３４は、患者の病歴から現在のＳＯＣＦを使用し、この患者に対して使用されている感度にそれを調整するために、現在の感度ファクター・セットによってそれを修正し、次に患者の現在のＳＯＣＦを「高」あるいは「低」にいつでも使えるように分類する。テスト８３４が患者のＳＯＣＦを「高」と分類すれば、その患者の主観的な健康アセスメントは信頼性が高く、プロセス７９０は段階８３８に制御を渡す。段階８３８は、高いＳＯＣＦの患者に対して療法（すなわち、例では服用量）をどれぐらい増加できるかと、対応する利点と危険が何であるかを治療テーブルで調べる。次に、プロセス７９０は機能８４０を呼び出す。あるいは、テスト８３４がＳＯＣＦを「低」とみなせば、プロセス７９０は段階８３６に制御を渡す。段階８３６は服用量と信頼できない患者に対する危険／利益ファクターを得る。どの場合にも、プロセス７９０は、機能８４０を呼び出すことによって、継続する。

患者同意レベル機能８４０は、勧告された療法を患者に与え、勧告された療法あるいはその若干の変化に対して患者の同意を得る。患者は勧告された療法を完全に拒否することもできる。機能８４０を図１７と関連して以下に説明する。

機能８４０が制御を返すとき、機能８４０が患者が増加した服用量に同意するという結果を返せば、プロセス７９０は段階８４２に制御を渡す。段階８４２は、増加した服用量と、より早いＤＭセッションに対するスケジュールの適切な変更で次の療法を示すためにＤＭＯ記録を設定する。次に、プロセス７９０はターミナル・ノード８４４に制御を渡す。ターミナル・ノード８４４は呼び出しているプロセスに制御を返す。

機能８４０は制御を返すとき、機能８４０が、患者が同じ服用量で療法を続行することに同意するという結果を返せば、プロセス７９０は段階８４６に制御を渡す。段階８４６は、同じ療法が継続されることを示すために、ＤＭＯ記録を設定する。次に、プロセス７９０はターミナル・ノード８４４に制御を渡す。ターミナル・ノード８４４は呼び出しているプロセスに制御を返す。

機能８４０が制御を返すとき、機能８４０が患者が服用量の減少に同意するという結果を返せば、プロセス７９０は段階８４８に制御を渡す。段階８４８は、服用量の減少した次の療法を示すために、ＤＭＯ記録を設定する。次に、プロセス７９０はターミナル・ノード８４４に制御を渡す。ターミナル・ノード８４４は呼び出しているプロセスに制御を返す。

機能８４０が制御を返すとき、患者がいかなるレベルにおいても勧告された療法を拒否するという結果を機能８４０が返せば、プロセス７９０はテスト８５０に制御を渡す。テスト８５０は、プロセス７９０が次善の療法を試みるべきか、あるいは患者を人間の医者にまわすべきかを知るために、現在の感度ファクター・セットを調べる。テスト８５０が、他の治療が試みられてもよいと決定すれば、プロセス７９０はノード８５２に制御を渡す。ノード８５２は、患者が勧告された療法を拒否したことを示すために、ＤＭＯ記録を設定する。次に、プロセス７９０はターミナル・ノード８４４に制御を渡す。ターミナル・ノード８４４は呼び出しているプロセスに制御を返す。テスト８５０が、患者は専門医にまわされるべきであると決定すれば、プロセス７９０はノード８５４に制御を渡す。ノード８５４は、患者を人間の医者にまわすためにＤＭＯ記録を設定する。次に、プロセス７９０はターミナル・ノード８４４に制御を渡す。ターミナル・ノード８４４は呼び出しているプロセスに制御を返す。

療法調整（客観的）
図１６を参照して、プロセス７７０を説明する。プロセス７７０は患者の現在の客観的健康測定に基づいてこの患者に対する次善の療法を計算する。プロセス７７０はスタートノード８７０において制御を受け取る。次に、プロセス７７０はテスト８７２に制御を渡す。テスト８７２は、患者の客観的健康データがさまざまな閾値を満たすかあるいは超えるかを決定するために、健康アセスメント・パラメータを比較する。テスト８７２は第１に、測定そのものが許容範囲にあるかどうかを見るために、患者の現在の健康測定値をその測定に対する絶対閾値と比較する。テスト８７２は、患者の健康が閾値を超える速度で悪化しているかどうかを見るために、次に最後の２つの健康測定値の傾斜を比較する。テスト８７２は、患者の健康の変化率がますます急速に悪化しているかどうかを見るために、次に最後の３つの測定値の傾斜における変化を比較する。これらの閾値の１つが満たされているか、あるいは超えられていれば、プロセス７７０は段階８７４に制御を渡す。段階８７４は、患者を人間の医者にまわすために、ＤＭＯを設定する。次に、プロセス７７０はターミナル・ノード８７６に制御を渡す。ターミナル・ノード８７６は呼び出しているプロセスに制御を返す。

テスト８７２が患者の現在の健康統計値のすべてが閾値の下にあると決定すれば、プロセス７７０はテスト８７８に制御を渡す。テスト８７８は、この患者に対するその次に勧告される療法を計算するプロセス７７０のフェーズを開始する。テスト８７８は、次の療法段階を計算する目的で、患者の健康状態の変化を「より良い、同じ、あるいは、より悪い」と分類するために、現在の患者の健康測定値を以前のＤＭセッションの値と比較する。

テスト８７８が、患者がこの前の時より悪いと決定すれば、プロセス７７０はテスト８８０に制御を渡す。テスト８８０は（治療テーブルから）現在の療法の服用量を増やせるかどうかを決定する。テスト８８０が服用量を増やせると決定すれば、プロセス７７０はノード８８２に制御を渡す。ノード８８２は服用量を増やすためにＤＭＯを設定する。次に、プロセス７７０はテスト８９６に制御を渡す。テスト８８０が服用量を増やすことはできないと決定すれば、プロセス７７０はノード８８４に制御を渡す。ノード８８４は同じ服用量で療法を続けるためにＤＭＯを設定する。次に、プロセス７７０はテスト８９６に制御を渡す。

テスト８７８が、患者がこの前の時と比べて同じ健康状態であると決定すれば、プロセス７７０はテスト８９２に制御を渡す。テスト８９２は患者の現在の健康測定値が正常な限界にあるかどうかを決定する。テスト８９２が患者の現在の健康データが正常であると決定すれば、プロセス７７０は段階８９０に制御を渡す。段階８９０はＤＭＯを設定し、服用量を減らす。次にプロセス７７０は８９６に制御を渡す。テスト８９２が患者の現在の健康データが正常な限界の外にあると決定すれば、プロセス７７０はテスト８８０に制御を渡す。テスト８８０はプロセス７７０に対して、以上で説明された。

テスト８７８が、患者がこの前の時より良いと決定すれば、プロセス７７０はテスト８８６に制御を渡す。テスト８８６が（治療テーブルを調べることによって）現在の服用量を減らすことができると決定すれば、プロセス７７０は段階８９０に制御を渡す。段階８９０はプロセス７７０に対して、以上で説明された。テスト８８６が現在の服用量を減らすことはできないと決定すれば、プロセス７７０は段階８８８に制御を渡す。段階８８８はＤＭＯを設定し、同じ服用量で療法を続ける。次に、プロセス７７０はテスト８９６に制御を渡す。

この患者に対するＴＡＰＬ設定が、プロセス７７０によってこれまでに計算されたＤＭＯを許容するかどうかを、テスト８９６は決定する。テスト８９６がＴＡＰＬは書き込まれているＤＭＯを許容すると決定すれば、プロセス８７０は患者同意レベル機能８４０を呼び出す。患者同意レベル機能８４０は、患者に勧告された療法を示し、勧告通りに、あるいは若干の修正を付けて療法に対する患者の同意を得る。患者は勧告された療法を完全に拒否してもよい。機能８４０を図１７と関連して以下に説明する。患者が勧告された療法を受け入れる（多分いくらか修正されて）という結果を機能８４０が返せば、プロセス７７０はターミナル・ノード８９８に制御を渡す。ターミナル・ノード８９８は呼び出しているプロセスに制御を返す。患者が勧告された療法を完全に拒否するという結果を機能８４０が返せば、プロセス７７０はテスト９００に制御を渡す。プロセス７７０が次善の療法を試みるべきか、あるいは患者を人間の医者にまわすべきかを知るために、テスト９００は現在の感度ファクター・セットを調べる。テスト９００が他の治療が試みられてもよいと決定すれば、プロセス７７０はノード９０２に制御を渡す。ノード９０２はＤＭＯ記録を設定し、患者が勧告された療法を拒否したことを示す。次に、プロセス７７０はターミナル・ノード９０４に制御を渡す。ターミナル・ノード９０４は呼び出しているプロセスに制御を返す。テスト９００が患者は医者に相談するべきであると決定すれば、プロセス７７０はノード９０６に制御を渡す。ノード９０６はＤＭＯ記録を設定し、患者を人間の医者にまわす。次に、プロセス７７０はターミナル・ノード９０４に制御を渡す。ターミナル・ノード９０４は呼び出しているプロセスに制御を返す。

ＴＡＰＬが勧告された療法を許容しないとテスト８９６が決定すれば、プロセス７７０は段階９０８に制御を渡す。段階９０８はＤＭＯ記録を設定し、患者を人間の医者にまわす。次に、プロセス７７０はターミナル・ノード９０４に制御を渡す。ターミナル・ノード９０４は呼び出しているプロセスに制御を返す。

患者同意レベル
図１７を参照して、患者同意レベル機能８４０を説明する。機能８４０は勧告された療法を患者に示し、ＤＭＭによって勧告されたとおりの、あるいは患者の反応に基づいて若干療法を変更して、療法に対する患者の同意を得る。患者は勧告された療法を完全に拒絶してもよい。開始ノード９２０において、機能８４０は制御を受け取る。次にプロセス８４０は段階９２２に制御を渡す。段階９２２はＤＭＯで勧告された療法を患者に出力する。次に、プロセス８４０は段階９２４に制御を渡す。段階９２４は患者に危険と利益を示す。次に、プロセス８４０は段階９２６に制御を渡す。段階９２６は他の療法の選択肢を患者に示す。次に、プロセス８４０は段階９２８に制御を渡す。段階９２８は勧告された療法、あるいは療法のあるバージョンへの同意を患者に求める。次に、プロセス８４０は段階９３０に制御を渡す。段階９３０は、提供された選択肢、与えられた警告、および受け取った同意レベルを、適切な日付および時間の記録と共に記録するために、ＤＭＯを更新する。次に、プロセス８４０は段階９３２に制御を渡す。段階９３２は呼び出しプロセスに返すべき機能の結果を計算する。患者によって許された同意レベルはいくつかの値を有するかもしれない。フローチャートで使用される４つの値は薬物療法を想定しており、それらは次のとおりである。（１）投薬量を増やす。（２）同じレベルの投薬量を保つ。（３）投薬量を減らす。（４）この療法を拒否する。次に、プロセス８４０はターミナル・ノード９３４に制御を渡す。ノード９３４は呼び出しプロセスに制御を返す。

クローズ・セッション
図１８を参照して、クローズ・セッション・プロセス４１０を説明する。プロセス４１０はすべてのＤＭセッションに対し実行される最後のプロセスである。それは疾患管理オーダー（ＤＭＯ）を処理することに対して特に責任があり、ＤＭＯは行われた試験およびその理由、勧告された次ぎの療法の段階、患者によって与えられた同意、および処方箋の患者の薬局へのファクシミリによる送付、研究室からの試験の依頼、患者の医者への報告の準備、患者への印刷した指示書の送付、等のような種々の関連したオーダーの完全なセットを含んでいる。ＤＭＯの詳細の実行とは別に、プロセス４１０は、ＤＭセッションの間に起きたすべてのイベントの記録、すべての関連データの蓄積、すべての適用可能なファイルの終了、次ぎのＤＭセッションの計画作成、そして最後に現在のＤＭセッションが終了したことを示すために患者に別れを告げること、に対して全体として責任がある。

プロセス４１０はスタートノード９５０において制御を受け取る。次に、プロセス４１０はテスト９５２に制御を渡す。テスト９５２は患者の病歴にＤＭＯによって指令された療法を記録する。次にプロセス４１０はテスト９５４に制御を渡す。テスト９５４はＤＭＯが処理すべき特別のオーダーを含むかどうかを決定する。テスト９５４がＤＭＯは特別の療法のオーダーを有しないと判断する場合、プロセス４１０は段階９７２に制御を渡す。段階９７２は、患者の現在の療法スケジュールで指定されるように、次のＤＭセッションを予定する。次に、プロセス４１０はノード９６２に制御を渡す。ノード９６２からの処理はプロセス４１０に対して下記に説明される。テスト９５４がＤＭＯが特別なオーダーを有すると判断する場合、プロセス４１０は段階９５６に制御を渡す。段階９５６はＤＭＯによって指定されるように次のＤＭセッションを予定する。次に、プロセス４１０は段階９５８に制御を渡す。段階９５８は種々の通知やレポートを準備して送り、種々の連絡先に報告する。これらの通知およびそれらを受け取る連絡先は、認可データベース内で維持されている規制、分担およびその他の認証フィールドによって制御される。次に、プロセス４１０は段階９６０に制御を渡し、段階９６０は次の療法の段階について患者に知らせ、ＤＭＯによって指示され認可データベースによって許可されている指示を患者に与える。次に、プロセス４１０は段階９６２に制御を渡す。

段階９６２はＤＭセッションおよびＤＭＭによって指令された療法について患者の医者に情報を与える。患者の医者は常に患者に対して発生したすべての情報を受けることができるので、医者は送るべき通知および報告すべき詳細を指定することができる。医者の現在の要求条件および通知のための制約事項は認可データベースに蓄積されており、ＤＭＭの外部のプロセスを使用して医者によって修正することができる。次に、プロセス４１０は段階９６４に制御を渡す。段階９６４は、認可データベースで許容された範囲内で、ＤＭＭソフトウェアによってとられた動作について患者に情報を与える。この段階はシステムが何をしているか、および何故、どちらが患者の確信を得ることができ、将来のセッションにおいて、より良い決定を行うために患者を助けることができるかを、システムが患者に示すことを可能にする。このフィードバックは本発明の特徴の１つである長期の療法の最適化の重要な要素である。段階９６４はさらに新しい症状を患者と話すために設定されているすべての特別なフラグを再検討する。次に、プロセス４１０は段階９６６に制御を渡す。段階９６６は種々の適当な主およびバックアップの記憶装置の中にすべての関連するデータを蓄積する。次に、プロセス４１０は段階９６８に制御を渡す。段階９６８はすべての適用可能なデータファイルの参照を終了させ、ＤＭセッションに割り当てられたすべての一時的な計算システムの資源を解放する。次に、プロセス４１０はターミナル・ノード９７０に制御を渡す。ノード９７０は呼び出しプロセスに制御を返す。

質問バージョン
ＤＭＭの質問バージョンの機能は、同じ質問の数個の異なるバージョンをスクリプトの中に書き込むことを許容し、どのバージョンを使用するかの決定は実行時間まで遅らせる。その機能は実行時間にそのスクリプトから質問の所望のバージョンを選択するために質問バージョン・インデックス（ＱＶＩ）と呼ばれる全体のデータ項目を用いる。

質問バージョン・フィーチャーは、各面に異なる質問バージョンの１つが書かれた多面の筒であり、「質問ローラ」として視覚化することができる。質問をするために、その筒は所望の質問テキストを収容する面を表示するために回転される。一組の各質問が別々の筒に書かれ、全体の制御要素によって指定されるように、すべての筒が同じ面を示すようにいっせいに回転する場合、スクリプトの全部の質問セットは調整されるか、あるいは、１つのユニットとして、「回転する」ことができる。これによって、スクリプトは全体として異なるレベルにおいて、質問の異なるバージョンを聞くために調節あるいは微調整することができる。

質問バージョン・フィーチャーの１つの使用法は、言語の感度を調整するＤＭＭ全体のＱＶＩを使用して、全体のＤＭＭによって使用される言語の感度および選択性を全体的に調整できることである。このようにして、質問の感度あるいは選択性を変更することが必要な場合は、質問ローラは感度を増加するためには一方に回し、あるいは歩進させ、選択性を増加させるためには反対方向に回し、あるいは歩進させる。この使用法に対して、各質問バージョンは言いまわしと感度が少しだけ異なっている。ある場合には、唯一の相違は音声のコンマ（休止）あるいはイントネーションである。その例を次に示す。

・これは誰かが持っているとあなたが想像できる絶対に最悪の頭痛ですか？
・これは誰かが持っているとあなたが想像できる最悪の頭痛ですか？
・これは今までにあなたが経験した最悪の頭痛ですか？
・これはあなたの最悪の頭痛の一つですか？
質問バージョン・フィーチャーの他の使用法は、患者の教育、知性、病気の理解、あるいは医学の専門知識の異なるレベルを目的とするスクリプトの質問を書くことである。たとえば、ＤＭＭは同じ質問を、３年生に対して、高校生に対して、大学卒業生に対して、あるいは医療従事者に対して書かれた種々の形式で質問することができる。したがって、ＤＭＭは患者の通信の必要性に対し適切な出力を採ることができる。その必要性は、どんな自然言語を使用するか、理解のレベルはどうであるか、どんな文法を使用するか（たとえば、我々は患者に対して、患者の親類に対して、あるいは患者の医者に対して話しているのか)、およびどんな医学の詳細を開示するのかのような、患者について現在既知である事項に基づいた決定の広い範囲を含むことができる。患者が理解できる言語、教育、および知性のレベルを知るために、ＤＭＭは患者の病歴を調べることができる。指標がない場合には、ミニ言語ＩＱ試験の結果を、患者に対して使用するためのＱＶＩを確立するために、初期健康アセスメント・タスクの一部として使用することができる。

質問バージョン・フィーチャーのさらに他の使用法は、患者の応答あるいは要求に基づいて質問のレベルの動的な調節を可能にすることである。したがって、困惑あるいは我を失っている患者は、質問にどのように応答するかについてより詳細な指示を与えるようにＤＭＭに尋ねることができる。ＤＭＭはより適切な質問バージョンを選択するためにＱＶＩを変更することによって反応することができる。他方、患者はセッションの間に勉強するので、後では患者はより少ない指示およびより早い通信モードを要求することができる。さらに、そのＱＶＩを調整することによって、ＤＭＭは適切に応答することができる。この方法で、ＤＭＭは患者の現在および過去のＤＭＭの使用について学び、患者の自然言語、教育、医学知識、および必要な医学的な感度に適合させるようにＤＭＭ自身を変更することができる。

質問バージョンの機能は、スクリプトの作成者が質問の異なるバージョンを「バージョン・グループ」に集めるのを可能にすることによってソフトウェアで実現され、そのグループにおいては質問の各バージョンは異なるＱＶＩに対応している。実行時に、すべてのスクリプトによって現在の患者に使用すべき現在の質問バージョンを規定するのに全体のＱＶＩを確立するため、ＤＭＭは感度ファクター・セットを使用する。（スクリプト・エンジンのような）ＤＭＭプロセスが質問を出力する必要がある時、それはスクリプト質問グループから希望の質問を見出し、それを取り出すために全体のＱＶＩを用いる。異なるバージョンを必要としない質問は、１つの質問のみを持つバージョン・グループとして書き込まれ、その質問はデフォルトの質問として働く。現在の全体のＱＶＩに対するバージョン・グループに質問がない時は、このデフォルトの質問が同様に使用される。

この質問バージョンの設計は、各ＱＶＩに対しバージョンを書くことなく、広範囲のＱＶＩに対して質問バージョンを書くことを許容する。簡単なスクリプトがちょうど１つの質問バージョンを持つことができ、スクリプトが改善されると、追加の付加的な質問バージョンが加えられる。たとえば、第１のスクリプトは、英語で書き込まれるかもしれない、そして各質問のスペイン語のバージョンを追加するために後で改良されるかも知れない。

質問バージョンの機能は、質問バージョン・インデックスおよび２つの別な機能セットのＱＶＩおよび質問選択の形で実現される。第１９ａ図および第１９ｂ図において、これらの要素が下記のように示される。

・全体バージョン・インデックス（ＱＶＩ）はデータ項目１０２０である。

・セットＱＶＩはプロセス１０００である。

・質問選択プロセスはプロセス１００１として示される。

全体バージョン・インデックス１０２０の現在の設定は、いくつかの異なる質問バージョンのどれか１つが選択され、患者に出力されるかを決定する。データ要素１０２０は許可データベース２５６（図３）の制御フィールドとして蓄積され、プロセス１０００によって変えられ、プロセス１００１によって使用される。

プロセス１０００は周期的にデータ要素１０２０を設定し、更新するＤＭＭ全体のシステム・サービス・ルーチンである。プロセス１０００は開始ノード１００２において制御を受け取る。次にプロセス１０００は段階１００４に制御を渡す。段階１００４はデータ要素１０２０が設定されるべきである患者を識別する。次にプロセス１０００は段階１００６に制御を渡す。段階１００６は患者のデータ要素１０２０の現在の値を取り出す。次にプロセス１０００は段階１００８に制御を渡す。段階１００８はデータ要素１０２０の新しい値を計算する。段階は現在の感度ファクター・セットから所望の感度のレベルを取得し、患者の病歴から患者の教育レベル、理解される言語のレベル、および過去のＤＭセッションで用いられたＱＶＩ設定のような他のパラメータを取得する。段階１００８が新しいＱＶＩ値を計算した後、プロセス１０００は段階１０１０に制御を渡す。段階１０１０は患者のデータ要素１０２０に新しい値を蓄積する。これで患者のデータ要素１０２０を更新する動作を完了する。次にプロセス１０００はターミナル・ノード１０１２に制御を渡す。ターミナル・ノード１０１２は呼び出しプロセスに制御を返す。

プロセス１００１は質問のセットから１つの質問を選択するために、全体のバージョン・インデックス１０２０を用いるＤＭＭ全体のルーチンである。プロセス１００１は開始ノード１０２２において制御を受け取る。次にプロセス１００１は段階１０２４に制御を渡す。段階１０２４は現在のスクリプト・データ領域に適用可能な質問のセットをロードする。次にプロセス１００１は段階１０２６に制御を渡す。段階１０２６は患者の認可ファイルから質問バージョン・インデックス１０２０の現在の値を取得する。次にプロセス１００１はテスト１０２８に制御を渡す。テスト１０２８は、ＱＶＩによって選択された質問バージョンが段階１０２４で得た質問のセットの中にあるかを決定する。テスト１０２８が所望のバージョンが質問のセットにあると決定した場合は、プロセス１００１は段階１０３０に制御を渡す。段階１０３０はそのセットから所望の質問レベルを持つ質問を取り出す。次にプロセス１００１は段階１０３４に制御を渡す。段階１０３４は発信者に対して機能の結果としてそのセットから選択された質問を返す。次にプロセス１００１はターミナル・ノード１０３６に制御を渡す。ターミナル・ノード１０３６は呼出しプロセスに制御を返す。テスト１０２８が所望のバージョンが質問セットの中にないと決定した場合は、プロセス１００１は段階１０３２に制御を渡す。段階１０３２はそのセットからデフォルトの質問を取り出す。次にプロセス１００１は段階１０３４に制御を渡す。段階１０３４は発信者に対して機能の結果としてそのセットから選択された質問を返す。次にプロセス１００１はターミナル・ノード１０３６に制御を渡す。ターミナル・ノード１０３６は呼び出しプロセスに制御を返す。

プレビュー・モード
プレビュー・モードは、患者に「公式な」応答を与える前に、応答の結果を調べるための、「前を考える」ことを可能にするＤＭＭスクリプトの実行時のモードである。結果として、患者は−スクリプト内の任意の点において−「この応答がどんな結果になるかを私に見せてください」と言うことができる。プレビュー・モードの１つの用途は、患者に進行中の会話を、懸案の質問が何を意味しているかを知るために、保留させることである。応答の結果を知ることは、質問の衝撃あるいは焦点を明確にする助けになる。したがって、印刷されたフローチャートあるいは手順において、最善の道を見出す１つの良い方法は、ある方法で質問に回答することがどんな結果（あるいは勧告）になるかを知るために前を見ることである。プレビュー・モードの他の用途は、スクリプトに対し特定の質問が重要な結果を伴うことを明示的に患者に警告し、プレビュー・モードを使用することは患者が各回答の結果を考えることを可能にすることである。たとえば、１つの回答が患者の医者と連絡を取らせるか、あるいは患者を緊急の施設へ移す動作を始めるかもしれない。スクリプトがこの結果について患者に警告することができれば、患者はこれらの応答を、それらを起動すること無しにプレビューすることができ、スクリプトの会話の指示を変更することができる。

図２０を参照して、プロセス１０６０を説明する。このプロセスはただ、患者に質問しその応答を処理する段階に含まれているプレビュー・モード・フィーチャーを扱うＤＭセッションの段階を示している。プレビュー・モードで関係しないＤＭセッションの他の段階は説明を明快にするために除かれている。プロセス１０６０はスタートノード１０６２において制御を受け取る。次にプロセス１０６０はテスト１０６４に制御を渡す。テスト１０６４がさらに質問すべき事項がないと判断する場合は、プロセス１０６０はターミナル・ノード１０６６に制御を渡す。ターミナル・ノード１０６６はプレビュー・モードを終了させる。テスト１０６４が質問すべき事項があると判断する場合は、プロセス１０６０は段階１０６８に制御を渡す。段階１０６８は患者への質問を出力する。次にプロセス１０６０は段階１０７０に制御を渡す。段階１０７０は患者に対する回答のセットを出力する。次にプロセス１０６０は段階１０７２に制御を渡す。段階１０７２は、患者がこの応答に対するスクリプトの動作をプレビューすることを希望するあるいは希望しない表示子と共に、患者からの応答を入力する。次にプロセス１０６０はテスト１０７４に制御を渡す。テスト１０７４が患者が設定されたプレビューの表示子を持って応答したことを知った場合は、プロセス１０６０は段階１０７６に制御を渡す。段階１０７６はスクリプトの中にコード化されているプレビュー情報を（標準の質問および応答のテキストの一部として）取り出し、選択された応答が「実際」のモードの中で何をするかの説明を視聴するように、患者に出力する。たとえば、プレビューテキストがその患者に「ＹＥＳ応答はその次の２週間の毎日の薬物療法の量を増やすであろう」と告げるかもしれない。プレビューテキストが患者に出力された後、プロセス１０６０は段階１０６８に制御を渡す。段階１０６８に対してすでに述べたように、段階１０６８は再び同じ質問をする。しかし、患者がプレビューの指示子無しに応答したことをテスト１０７４が知っている場合は、プロセス１０６０は段階１０７８に制御を渡す。段階１０７８は与えられた応答に対し通常記述されている動作を実行し、その後プロセス１０６０はテスト１０６４へ制御を渡す。テスト１０６４は、テスト１０６４に対して上述したように質問すべき次ぎの質問があるかどうかを決定する。

無応答フィーチャー
患者とのすべてのＤＭＭ対話はスクリプトによって制御される。標準的なセッションの間に、スクリプトは質問を選択し、それを患者に出力し、患者は応答を入力する。スクリプトは応答を分析し、もう１つの質問を選択し、それを患者に出力する。この質問−応答−質問−応答の会話は、セッションが正常に終了するまで継続する。しかし、患者が会話中に期待に反して応答できない場合は、すべてのスクリプトは無応答（ＮＲ）フィーチャーを呼び出すように設計され、無応答フィーチャーはスクリプトに対し適当な継続の動作を取る責任がある。ＮＲフィーチャーはタイムアウト条件がオペレーティング・システムによって表示された時に起動されるＤＭＭソフトウェア機構である。このＮＲ機構はスクリプトによって予め決められているいくつかの動作を取ることができ、スクリプトの運用にしたがって変更することができる。ＮＲ動作はＤＭセッション記録の静かな入り口からずっと患者の病歴、患者の責任ある隣人、あるいは近くの緊急の応答施設に接触した病気のデータベースからの薬物療法および症状のデータからの健康データの使用に至ることができる。

ＮＲ機能の１つの使用法は、患者が応答できないことの医学的な病気特有の、および患者特有の評価を行うことである。明らかに、ある病気を持つ患者では（たとえば、心臓の問題、頭部障害、糖尿病）、通常の会話中に患者が突然応答できなくなることはいくつかの可能性を示すかもしれない。このＮＲフィーチャーは前のセッションからの患者に関する詳細な医学情報を持っているＤＭＭの内容およびＦＯ支持システムの内容の特別な価値であり、支持システムは、世界中の地理的な位置によってインデックスを付けられた広範囲の関連するデータベース（たとえば、緊急治療室、９１１機関、医療補助員）を有する。システムが患者について知っていることのために、ＮＲＦは非常に状況特有の動作をすることができる。非常に簡単な例は、胸痛のために相談している６０歳の男性であろう。質問の回答への突然の失敗は、心拍停止を示唆し、患者の地域の９１１機関を呼ぶことを含めて緊急の動作を開始するであろう。

図２１を参照して、プロセス１１００を説明する。プロセス１１００は、無応答フィーチャーに関係のあるスクリプトの段階の部分のみを示すことに、注意を要する。スクリプトの他の段階は簡単のために除かれている。プロセス１１００はスタートノード１１０２において制御を受け取る。スタートノード１１０２はスクリプトの一般的なスタートノードを表す。次にプロセス１１００は段階グループ１１０４に制御を渡す。段階グループ１１０４は、無応答フィーチャーに関係しないスクリプト動作のすべてを表す。スクリプトがこれらの段階の１つの一部として終了した場合は、プロセス１１００はターミナル・ノード１１０６に制御を渡す。ターミナル・ノード１１０６はスクリプトを終了させる。段階グループ１１０４の段階の一つが患者へ質問することを希望する場合は、プロセス１１００は段階１１０８に制御を渡す。患者が応答するのに失敗すれば、段階１１０８は後で必要とされるＮＲパラメータを設定する。これらのパラメータのソースは、患者の病歴２５４であり、それには患者の病気、健康状態、とられている薬物療法、医者、最も近い緊急施設等のような、患者が応答に失敗した場合に使用すべき関連の情報を含む。段階１１０８はデータセット２６４としてＮＲパラメータを蓄積する。次にプロセス１１００は段階１１１２に制御を渡す。段階１１１２は患者へ実際の質問を出力する。次にプロセス１１００はテスト１１１４に制御を渡す。段階１１１４の細部はオペレーティング・システムとハードウェア・プラットホームで変化する。しかし、その典型的な動作は、指定された待ち時間に対するタイムアウト・フラグを設定し、オペレーティング・システムへの制御を獲得し、オペレーティング・システムが応答に戻った、あるいは待ち時間が経過した時、制御を再び獲得することである。テスト１１１４が応答を受け取った時、プロセス１１００は段階グループ１１０４に制御を渡し、そこで通常のスクリプトの動作が継続する。もしテスト１１１４がタイムアウトを受け取ったら、プロセス１１００は段階１１１６に制御を渡す。段階１１１６は患者、病気、および位置に固有のＮＲデータをデータセット２６４および２５４から取り出し、要求されているＮＲ動作を行う。段階１１１６がＮＲ動作を行ったら、プロセス１１００はターミナル・ノード１１１６に制御を渡す。それはタイムアウトによるスクリプトの一般的な終了を表す。

ＰＱＲＳＴ配列
トーマス・ルイス卿は、苦痛は「経験によって我々に知られ、図によって説明される」と言った。苦痛の主観的な経験を標準的で繰り返し可能な形式でコード化する能力は、自動化された医学のいかなるシステムにとっても基本的な資産である。多くの診断のセッションは、患者がある種の苦痛を医者に主な苦情の形で報告することで始まる。苦痛の徹底的な説明は、多くの診断をなくし、テーブル参照あるいはデータベース・アクセス機構の使用をなくすと共に早期に病気を示唆することができる。

ＰＯＲＳＴ配列フィーチャーは、患者の苦痛の説明を、整数の特別にフォーマットされた配列である「苦痛コード」にコード化するために共に働くソフトウェア・プロセスおよびデータのセットを説明する。コード化することは、その主観的な情報を維持する方法で行われるので、配列の整数を使用して苦痛コードを復号することは可能であり、苦痛を説明するために使用される元の言葉に回復する。

苦痛コードはサブコードで構成される。各サブコードは位置、感覚、頻度等のような苦痛の経験の１つのよく規定された詳細な様相を識別する。苦痛のサブコードは、苦痛コードを操るすべてのソフトウェア・プロセスに知られている特有の順序あるいはフォーマットで配置される。様相をコード化するのに使用される順序は、それ自身、順序番号として番号付けが行われ、その結果配列の最初の様相は常に配列のために使用されるコード化計画を識別する。種々のコード化計画を種々の必要を満たすために使用することができるので、これはＰＱＲＳＴ配列を柔軟で拡大可能とする。将来ＰＱＲＳＴを復号する必要があるソフトウェア・プロセスは、簡単に最初の様相コードを検査し、様相の残りに対してどんな復号化計画を使用すべきかをその値から知る。

ＰＱＲＳＴ配列のフィーチャーは患者の苦痛の報告をソフトウェア・プロセスに適しているディジタル形式にコード化することを可能にする。たとえば、「私が右腕を曲げる、あるいは手首を回転する時、軽度ではあるが、ひじの領域が本当に悪く傷つき、ある種のじゃりじゃりする、あるいはすり砕く音がする、しかし出血はしない」という患者の苦情も、患者に標準の説明用語（たとえば、じゃりじゃりする、きつい、感覚がない）から選ばせ、そして選択された用語を（７，２，３，８，５，９７０６１２，２，１３）のようなそれに近いある整数の配列に変換することによって、コード化することができる。この配列は、場所、繰返し性、品質、あるいは９７０６１２の日付のような、苦痛の種々な様相を数値で表す。任意の与えられた様相に対して、その数値は苦痛の程度あるいは説明を表す。したがって、第４の様相の番号が動きに関連した音を表すならば、サブコード値８は「関節の動きに関連したじゃりじゃりする／すり砕くノイズ」を表すことができる。

「ＰＱＲＳＴ」ラベルは、苦痛の基本的な様相に対して、医学生によって用いられた古典的な覚え易い名称から採用された、Ｐ−刺激／緩和（それをもたらし、悪化し、あるいは良くする）、Ｑ−特性（鋭い、あるいは鈍い）、Ｒ−領域（頭あるいは胸など）、Ｓ−重大度（軽いから苦痛）、および、Ｔ−タイミング（いつ苦痛が始まったか）。これらの様相は、ＰＱＲＳＴ配列の起点を表し、原因（感染、外傷）、質量（モル、かたまり）、寸法（指先、ゴルフボール）、感覚（くすぐる、パルスを出す）、および客観的な関連（色、匂い、解放）のような、苦痛に関連した多くの付加的な様相と共に、他の有用な病気の主観的な記述を含むように拡張できる。

苦痛の説明を苦痛コードにコード化するために、プロセスは下記のように動作する：
・予め規定された１組の苦痛の様相を使用する（すなわち、小さな面、要素、寸法）。

・各様相に対し規定された予め決められた１組の様相の用語を使用する。

・患者から適用可能な様相の用語を得る。

・すべての様相用語をサブコードにコード化する。

・サブコードを物理的なデータ項目（ＰＱＲＳＴ配列）としてフォーマットする。

・ＰＱＲＳＴ配列をメモリあるいはディスク上に蓄積する。

・蓄積場所のアドレスをポインタとして使用する。

苦痛コードを全体として取り扱うために、プログラムは下記の動作を行う。

・ポインタをＰＱＲＳＴ配列に渡す。

・必要ならば、ＰＱＲＳＴ配列をアクセスするためにポインタを使用する。

苦痛コードを復号するために、プログラムはコード化プロセスの逆を行う。

・メモリあるいは記憶装置のＰＱＲＳＴ配列を探すためにそのポインタを使用する。

・メモリあるいはディスクからＰＱＲＳＴ配列を検索する。

・各サブコードを検索する。

・各サブコードを主観的な様相の用語に復号する。

・主観的な説明としてその様相の用語を出力する。

第２２ａ図を参照して、プロセス１１４０を説明する。プロセス１１４０は患者の苦痛の主観的な説明のディジタル化された形を表すＰＱＲＳＴ配列を作るために必要とする段階を構成する。プロセス１１４０は、患者がオンラインであり、プロセス１１４０によって促された時は、主観的な苦痛の説明の詳細に会話的に入ることができるように仮定して説明されている。プロセス１１４０はスタート段階１１４２で呼び出しプロセスから制御を受け取る。段階１１４２は患者によって入力された苦痛の様相を苦痛のサブコードに適合するセットにコード化するループの始点である。段階１１４２は、サブコードを収容するＰＱＲＳＴ配列にスペースを割り当てる。次に、プロセス１１４０は、段階１１４４に制御を渡す。段階１１４４はコード化される次の苦痛の様相を確立する。次に、プロセス１１４０は段階１１４６に制御を渡す。、段階１１４６はデータベース１１５０から標準の様相の用語のリストを検索し、それらをピックリストのフォーマットで、患者に出力する。すなわち、それは患者が調べることができ、それから患者が様相の用語の一つを選ぶことができるリストである。次に、プロセス１１４０は段階１１５２に制御を渡す。段階１１５２は患者にピックリストからコード化される苦痛の様相に対する患者の主観的な説明に最もよく適合する様相の用語を選択するように依頼する。次に、プロセス１１４０は段階１１５４に制御を渡す。段階１１５４は患者によって選択された様相の用語をその様相の用語を識別する整数に変換する。この整数は現在の様相に対するサブコードである。それはただ選択された様相の用語のピックリストでのインデックスの位置であるにすぎない。次に、プロセス１１４０は段階１１５６に制御を渡す。段階１１５６はサブコードの整数を、ＰＱＲＳＴ配列の中に、コード化される様相を表すインデックスの位置に挿入する。次に、プロセス１１４０はテスト１１５８に制御を渡す。テスト１１５８はさらに多くの様相をコード化すべきであるかどうかを決定する。テスト１１５８がコード化されるべきもっと多くの様相があると判断した場合は、今説明したループをさらに繰り返すことを始めるために、プロセス１１４０は段階１１４４へ制御を渡す。テスト１１５８がさらにコード化される様相はないと判断した場合は、次にプロセス１１４０は段階１１６０に制御を渡す。段階１１６０はＰＱＲＳＴ配列を患者の病歴２５４のような適当なデータセットに蓄積あるいはコピーする。次に、プロセス１１４０は段階１１６２に制御を渡す。段階１１６２は呼び出しプロセスに制御を返す。

第２２ｂ図を参照して、プロセス１１７０を説明する。プロセス１１７０は、病気のテーブルから特定の診断を検索するのにＰＱＲＳＴ配列をインデックスとして用いるのに必要とする段階の一例である。この例は病気のリスト（あるいは、ある与えられた苦痛コードに対して２つ以上の病気がある場合の、病気の組み合わせ）が苦痛コードによって索引され、病気のデータベース２６２に蓄積されることを仮定している。この例はさらに、アクセスキーが与えられた時、データベースの要素を検索することができるデータベースをアクセスするためのソフトウェア・プロセスがあることを仮定している。このようなデータベース・アクセス機構の１つの明白な例は、適切に定様式の構造化検索言語（ＳＱＬ）宣言であり、他の例は各要素のインデックスの位置を使用してアクセスされる病気の名称あるいはポインタの簡単な配列である。プロセス１１７０はスタートノード１１７２において制御を受け取る。次にプロセス１１７０は段階１１７４に制御を渡す。段階１１７４はデータベース２６２から診断を選択するために使用されるＰＱＲＳＴ配列のコピーをロードする。次に、プロセス１１７０は段階１１７６に制御を渡す。段階１１７６はＤＭＭ苦痛コードをデータベース２６２にアクセスするプロセスによって要求されるように定様式のアクセスキーに変換する。次に、プロセス１１７０は段階１１７８に制御を渡す。段階１１７８はデータベース２６２からその苦痛コードに適合している記録を引き出すためにそのアクセスキーを使用する。次に、プロセス１１７０はターミナル・ノード１１８０に制御を渡す。ターミナル・ノード１１８０は呼び出しプロセスに制御を返す。

疾患管理オーダー（ＤＭＯ）
疾患管理オーダーは、ＤＭセッションの始めに、患者に付けられるデータ記録であり、プロセスからプロセスまでその患者と共に動き、そのセッションの間に種々のプロセスによって発行された決定およびオーダーをまとめるために、セッションの最後に（セッション終了プロセスによって）使用される。ＤＭＯ記録は多くのフィールドを含んでおり、ＤＭ特有のデータベース２６４（図３）のセッション領域に蓄積される。「コード」と名付けられたＤＭＯの１つのキーフィールドは、通常患者のために行われるべき次の処理を記録している。

ＤＭＯの１つの用途は患者のために必要とされる特別な処理の信号を出すことである。たとえば、１回の必要条件が初期のインタビューを行うのに新しい患者にフラグを付けるために、そのオープン・セッション・プロセスはＤＭＯコードフィールドを「初期の健康を算定しなさい」（図６、ノード４４８）にセットする。ＤＭセッション・プロセスはその後健康アセスメントに継続し、それはＤＭＯコードを調べて、患者を初期健康アセスメント・プロセス４８８（図７）に向ける。

ＤＭＯの他の用途は必要に応じてプロセスを繰り返すことである。たとえば、相関アセスメント・プロセスがセッションの間に付加的な健康データを必要とする場合は、それは不足しているデータを得るために再び健康アセスメントを呼ぶことができる（図１２、ノード６６０）。プロセスが十分なデータを持っている場合は、ＤＭＯコードを「療法を最適化する」に設定し、その患者はアセスメント・サイクルから外に出される。

ＤＭＯの他の用途は、行われた決定に対する種々の理由を追跡することであり、それは患者に関してＤＭプロセスが何を学んだかの詳細な報告を発行するために終了セッションのプロセスで使用することができる。たとえば、療法調整プロセスは異なる理由に対し患者を医者に参照することができる（図１４、ノード７７８および７８４；図１５、ノード８３２，８５４）。それぞれの場合に、ＤＭＯコードは「ＭＤを参照」に設定されているが、しかしＤＭＯの理由フィールドは異なる理由を示すように設定されている。

最後に、ＤＭＯの肝心な用途は「医者のオーダー」を示すこと、すなわちセッション中に発行されたオーダーのすべてを蓄積することである。それによってセッションが終了した時にそれらのオーダーを実施することができる（図１８、ノード９５６）。

認可データベース
認可データベース２５６（図３）はＤＭＭプロセスによって取られたＤＭＭデータおよび動作へのアクセスを制御するソフトウェア要素のすべての集積である。このデータベースは、パスワード、アクセス権、知る必要および知る権利のクリアランス、公開の認可、同意、制約条件、限界、閾値、等の形で、ＤＭＭの安全、保護、信頼性、制御、および管理機能を支援する。この認可データベースは、医学およびソフトウェアの専門家の人間のスタッフがそれを通してどんな自動的な動作をＤＭＭが行うことができるか、そしてできないかを規定し制御するインタフェースである。認可がすべてのＤＭＭプロセスの動作を管理するので、認可データベースは、ＤＭＭが行うべきすべての詳細な段階に対して許可を求めなくてはならないところで、「完全に自動的に」から「全体では自動的でない」までに及ぶ種々のモードで動作するようにシステムを動的に構成するのに使用することができる。後者のモードは、実験的、試験、問題の追跡、あるいはシステムの監査の用途に対して特に有用である。

認可データベースの３つの表が上記のＤＭＭプロセスの動作に関連し、それらは下記の夫々のセクションの見出しの下で説明されている。それらは規制認可、シェアリング認可、および療法の改変認可レベル（ＴＡＰＬ）である。

規制認可
規制認可は、それが活動する分野でのすべての適用可能な規定、免許、および法律上の必要条件と制約にＤＭＭが適合することを保証するデータセットである。規制認可データセットは、司法権によって構成され、各管轄区域に対して規定され、そのデータフィールドは政府機間に対して開示することができる。規制認可の機能は、他の自動化された医学システムでは通常無視される、すなわちこのようなシステムが制御している管轄区域内および国際的な境界を越えた管轄区域にわたる実用的な医学と見なされ、したがって非常に多くの種々の医学の実用的な制約および認可の規定に適合しなければならない非常に複雑な問題を述べている。この機能はＤＭＭがその動作および患者、医者、健康管理組織、政府機間、等との接触で法律に適合することを可能にする。

規制認可はＤＭＭ全体であり、それらが適用可能なところで使用することができる。１つの例はクローズ・セッション・プロセス（図１８、ノード９５８−９６４）であり、それはＤＭセッションあるいは患者に関する通知、指示および報告の配布の前の、秘密の医学データの開示に関しては法律上の必要条件および禁止事項を考慮しなくてはならない。

シェアリング認可
シェアリング認可は個別の医学データ項目の開示を処理するために使用される。患者の病歴の各データフィールドは、医学データの項目を患者、種々の代理人あるいは機間、および特別のアクセスの認可を持っている他のソフトウェアのオブジェクトに開示できるかどうかを規定するアクセス制御フィールドに関連している。シェアリング認可はどんな医学のデータの項目をそのメッセージおよび報告において、患者、患者の代理人、医者、研究室、薬局、健康管理機間、あるいは政府機関に開示できるかどうかを（すなわち、「シェアされる」）決めるためにＤＭＭクローズ・セッション・プロセス（図１８、節９５８、９６０）によって使用される。

シェアリング認可の他の用途は、開示することが不適当な場合に、診断結果を患者に開示するのを防ぐことである（図１８、ノード９６４）。

療法の改変認可レベル（ＴＡＰＬ）
療法の改変認可レベル（ＴＡＰＬ）はＤＭＭが患者療法の変さらに持っている権限の種々のレベルを指定するデータセットである。ＴＡＰＬはＤＭＭが事前にその人の承認なしに患者の病気を処理するために持っている権限の度合いである。患者病歴データの項目が、たとえば行政機関あるいは保険会社によって求められた時は、ＤＭＭはどんなシェアリング認可レベルがそれに対して要求されているかを知るためにそのデータ項目のアクセス制御フィールドを調べる。次にＤＭＭはその要求している機関が指定されたレベルのアクセスの認可を持っていることを確かめるために認可データベースを調べる。

その最も制限的なレベルにおいては、ＤＭＭデータベースが療法の変さらによって患者が便益を得ることができることを決定した時は、医者に通知すること、そしてどんな場合でも療法を調整する前に許可を得ることを、ＴＡＰＬはＤＭＭに要求する。最も制約の少ないＴＡＰＬ設定は、ＤＭＭが人での介入無しに患者の治療を自動的に変更することを許可する。これらの両極端の間のＴＡＰＬ設定は、異なる治療の介入のために事前の通知および承認の種々の度合いを要求する。ＴＡＰＬは患者の療法を変更し、あるいはその効果に対し助言を与えるすべてのＤＭＭ機能によって使用される（図１５、ノード８３０；図１６、ノード８９６）。

メタ構造
メタデータ配列
医学の管理システムのメタ機能を論じる目的のために、医学的な問題を記録し、追跡し、分析し、そして報告するために使用されるシステムデータ構造は、メタデータ配列と呼ばれる２次元の格子あるいは配列として可視化される。この配列は、「原因」としてのラベルで１次元（横座標すなわちｘ軸）に沿った病気の原因（たとえば、外傷、伝染病、アレルギー）を列挙し、そして「解剖」としてのラベルで第２の次元（縦座標すなわちｙ軸）に沿った病気によって侵される解剖学的システムあるいは器官を列挙する。ある与えられた病気は適用可能な「原因」および「解剖」の次元の交点にあるメタデータ配列のセルとして知ることができる。

具体化例で、「原因」および「解剖」両方とも、当然広範囲に細分化される。したがって、たとえば、伝染病の原因はバクテリアおよびウィルスで細分化され、バクテリアはグラムポジティブとグラムネガティブに分けられる。グラムポジティブはさらにシステムが「髄膜炎菌グラムネガティブバクテリア感染」のような究極の原因を識別できる点まで連鎖球菌、等に分けられる。解剖学の次元は明らかにさらに器官構造、器官、組織、セル、そのほかに細分されることができる。

メタデータ立方体
医学管理システムはある患者に対し多くの接触を持っているので、付加的な患者のデータはメタデータ立方体を構成するために時間次元に沿ってメタデータ配列を拡張する。時間軸はさらにその「Ｚ」軸として参照される。

メタデータ立方体は種々のメタ機能を支援する内部データ構造である。その細部は、どの医学システム・モジュールが、メタ分析のどの種類を実行するかによって変化するが、下記の例のすべてが適用される。

・同じ苦情の数個の症状の発現（頻度メタ）
・異なる解剖システムでの数個の感染（原因メタ）
・同じ解剖システムでの異なる病気（解剖メタ）
・長期の患者の履歴、たとえば３５年を超える喫煙習慣（容積測定メタ）
・慢性病の履歴、たとえば、５年のぜんそくあるいはマラリアの病気
・短期の病気の進行、たとえば３日間の胃腸の苦痛、頭痛、嘔吐
メタ機能
メタ機能は、全体の医学管理システムおよびその種々のモジュールの全体レベルで活動する医学的なソフトウェアのオブジェクトである。それらは、下記の目的のために、システムに対する患者の相互作用を観察し、記録し、分析する。

患者のシステムの利用を評価する。

問題を示すかもしれないパターンあるいは関係を探索する。

患者のシステムとの全体の相互作用を探索するために「戻る」。

過去のセッションの内容で患者の現在のセッションを分析する。

メタ機能は、全体的な、複雑なバイオメカニズムとして患者を見る人間である医者の観点は、誤った判断をし、ある時間間隔で修正手段を必要とすることを自動化する。それらはＤＭＭに全体として患者の健康を分析し、長期的な医学診断、治療、助言、および管理戦術を開発するための強力な能力を与える。

頻度メタ機能は同じ病気に関して相談の頻度を分析するために順次集計メタ機能を使用する。解剖メタ機能は関係する解剖の器官システムに基づいて患者の苦情を分析する。原因効果連結メタ機能は病気を原因に戻って分析し、その後他の病気に対し分析する。領域メタ機能および容積測定メタ機能は長時間にわたって病気パラメータの変化を分析する。限界カーブメタ機能は著しい劣化に対して患者の健康を、管理されている病気に対する標準のカーブと比較して監視する。間隔メタは同じ疾患に対する相談の時間間隔を評価する。信頼性メタはデータの信頼性および正常性の確立を算定する。

疾患管理に対して説明したメタ機能は、本出願人の特許「コンピュータ化された医学的診断および治療助言システム」と題する米国特許第５，６６０，１７６号で説明したのと同じ「メタデータ立方体」データ構造を使用している。しかし、ＤＭは異なる目標を有するので、それは異なる座標軸に沿って立方体の異なるデータ要素を調べる。

用語「メタ」はこれらの機能の全体の性質を指している。それは健康のデータを、詳細なレベルではなく、長期の傾向、全体のパターン、統計的な分布および他の要約された関係のレベルで扱うことに焦点を置いている。ここでは用語「機能」は、使われているさまざまな計算技法および解析的な技法を指している。計算技法および解析的な技法は、古典的論理およびファジー論理、算数、幾何学、三角法、解析幾何学、微積分法、統計学、確率、ドメイン・マッピング、変換（ラプラス、フーリエ）、ヒューリスティックス、漸化式、等を使用している。

メタ機能は、データベース、テーブル、配列、モジュール、オブジェクト、スクリプト、リスト、サブルーチン、手順、機能、等のような適当なデータおよびプロセス構造の形で実現され具体化される。

・順次集計メタ
順次集計（ＳＳ）メタ機能は、診断モジュールとＤＭＭのような全体の医療管理システムの別々のモジュールにアクセスする１人の患者の結果を検出し集計する。これは別々のセッションが組み合わされた時著しい変化を表し、あるいは患者の状態を悪化させることがあるかも知れないからである。ＳＳメタ機能は、別々なモジュールの結合された効果を分析し、この全体的な分析に基づいて勧告を出すことができるかも知れない。

ＳＳメタは合計されるシステム・モジュールの異なる組み合わせに対して予め設定された閾値を使用する。この閾値は、医療の診断＋疾患管理、医療の診断＋医学のオーディオ／ビデオ／画像ライブラリ、医療の診断＋治療テーブル・コンサルテーション、等モジュールの組み合わせのすべてを列挙している内部テーブルに含まれている。

たとえば、もし、ぜいぜい息をすることに対して、医学の診断モジュールが参照され、ぜんそくとして診断され、ＤＭモジュールが後でぜんそく管理のために用いられ、医学のオーディオ／ビデオ／画像ライブラリ・モジュールが予め記録されたぜんそくのメッセージに対して数回参照された場合、ＳＳメタ機能は、特別な勧告を起動する閾値を計算するために医療の診断＋疾患管理＋ぜんそくのための医学のオーディオ／ビデオ／画像ライブラリのテーブルからその適切な値を用いるであろう。したがって、閾値が任意の１つのモジュールで得られなかったとしても、診断、疾患管理、およびオーディオ／ビデオ／画像ライブラリのコンサルテーションで、ぜんそくに対するコンサルテーションが組み合わされ、一緒に考慮され、閾値が求められる。

・頻度メタ
頻度メタ機能は患者がシステムに相談する回数を調査し、相談の頻度に基づいて勧告を作成する。この機能は同じ苦情あるいは病気に対して患者が何回システム、医学のオーディオ・テキスト・コンサルテーションあるいは治療テーブル・コンサルタントに相談したかを計算し、コンサルテーションの結合した効果を分析するために順次集計メタ機能を使用し、この全体的な分析に基づいて勧告を作成することができる。

患者が管理されている各病気に対して医学管理システムに対して認められている時は、時間のある単位に対してコンサルテーション数（外部に対すると同様に、内部に対しても）に対する閾値が確立されている。閾値は各病気に対して異なっており、そして感度ファクター・セットによって修正される。この閾値に到達したら、頻度メタ機能は勧告を行う。すなわち、患者がある種類の兆候の発生がある回数あったという事実のみで、頻度メタ機能からの勧告を起動することができる。

・間隔メタ
間隔メタ機能は問題を示すかも知れない傾向を検出するために、同じ病気に対する各相互作用の間の時間間隔を分析する。たとえば、患者のシステムとの相互作用が非常に近接して一緒に発生していることをその機能が発見しようとしている時は、その機能はこの事実のみに基づいて勧告を行うことができる。

順次集計シリーズの方法が使用される。コンサルテーションの間隔が図に描かれ、間隔がだんだん短くなるようならばメタ勧告が行われる。

・原因メタ
原因メタ機能は根本の原因を識別するのに役立つかもしれない病気あるいは原因のパターンを探すＤＭ背景タスクである。その機能は種々のシステム・モジュールの患者の使用を監視し、分析する。

原因メタ機能は、医学診断、疾患管理、医療オーディオ・テキスト・ライブラリー、治療テーブル・コンサルテーションおよびそれらのすべての組み合わせの間の順次集計シリーズを、減少する時間間隔で、検出する。たとえば、ある患者が身体の異なる部分を明示する苦情をいくつかの機会にシステムに相談したこと、および各セッションの間に医療の診断モジュールが別々の各問題を感染による原因であることに（適正に）帰したと仮定する。原因メタ機能はこのような一連のコンサルテーションを検出し、それらが予め設定された単位時間当りの閾値に達したら、根本の原因は患者の免疫システムにあるかもしれないという警報を出す。システムが外傷の複数の原因で患者を治療していれば、原因メタ機能は患者は薬あるいはアルコールを乱用している可能性を考慮するシステムを助けるであろう。

・解剖メタ
解剖メタ機能は、単一の器官あるいは身体の解剖的なシステムの観点から患者の医学的なシステムとの接触を分析する。この機能は同じ解剖的なシステムに影響を与えるかもしれない処理されている異なる病気を探す。この機能は−異なる病気のすべてが同じ器官に影響を与える時−その器官の機能を監視し、頻繁に測定するために、頻繁に基本的なＤＭの様相を自動化する。

たとえば、患者が腹部の苦痛、嘔吐、および下痢の３つの異なる場合に医学の診断モジュールに相談した場合、解剖メタ機能はこれらの問題はすべて消化管に関係していることを認識し、追加の情報に基づいてシステムに勧告を調整させることができる。

たとえば、糖尿病および高血圧の両方が遅いが進行する腎臓機能の劣化を起こす。解剖メタ機能はこのような特別の監視の必要性を検出する。ある内部的な予め設定された閾値に基づいて解剖メタ分析は疾患管理システムに影響を受けた器官の機能の評価を勧告させることができる。上記の例において、糖尿病および高血圧のために管理されている患者に対して解剖メタ分析は医学管理システムに血清クレアチン、腎臓機能の検査を勧告させることができる。

・原因対解剖メタ
原因対解剖メタ機能は原因メタと解剖メタ機能の間の相互作用を調整する。原因メタと解剖メタ機能の間にはより密接な相互作用があるので、それらの相互作用はここで説明される。

患者は長期間にわたって医学管理システムを用いるので、原因／解剖セルは時間すなわちＺ軸に沿って積み重ねられ、それらは原因と解剖システムの相互作用の時点を追跡する、すなわち患者に実際に起こったのを診断する。

メタデータ立方体は長時間にわたるシステムに対する患者の相互作用の加算を表す。患者の過去の履歴の多くはＩＣＤ−９−ＣＭコードを使用して蓄積されているが、患者の医療記録の分野における従来のテキスト伝票と同様に、この技術は非常に有用な分析を行うことを可能にする。

システムは、関係している解剖のシステムを知ること無しに問題の原因を指定できること、およびシステムは患者の問題の原因を知ること無しに、どんな器官あるいはシステムが関係しているかを示すことができることに留意することが重要である。たとえば、筋肉の苦痛、頭痛、鼻水が出る鼻、および合同の苦痛の苦情を言う６歳の子供は最も多いのはビールスの感染であるが、しかし侵されている特定の器官のシステムを述べることは難しい。

興味深い事に、診断のモジュールの中で、複数の問題が同じモジュールの中で生じている間に、異なるパターンが病気の管理で作成される。たとえば、糖尿病が内分泌物と血管のシステムの相互作用によって、あるいはその場所で表されることがありうる。しかし、糖尿病で病気のプロセスを可視化する他の方法はさらに一段階進めることである。医学管理システムが（糖尿病のような）他の病気のプロセスが欠陥のシステムに影響しているときは必ず、そのときはさらに病気の原因として「血管」が探索される。

・原因連鎖メタ
連鎖メタ機能はある病気が身体の他の器官で病的な変化を作成するという医学的事実の分析を自動化し、これは病気は他の病気の原因になり、他の病気が原因となることを意味している。たとえば、連鎖メタ機能は、原因および結果としてある与えられた病気を調査し、ある与えられた病気Ｄに対して３つの分析を行う。

１．Ｄの根本の原因を見出す。

２．Ｄが原因となる他の病気を見出す。

３．他の根本の原因およびＤが原因となる他の病気を見出すために段階１および２を再帰的に繰り返す。

したがって、連鎖メタ分析は身体に対する病気のすべての影響を追跡する。再帰的に遠隔の目的および病気を見出すために、それは原因メタ機能を使用する（その機能は苦情あるいは病気の直接的な１つの原因を検出するために使用される）。始めの病気が与えられたら、連鎖メタ分析は、分析を患者の他の可能性のある原因連鎖を逆に戻って分析させるパターンを検出するためにメタデータ立方体を利用する。したがって、それは遠く隠され、あるいはまだ表面に出ていない関連の問題を検出するために必要とされる分析を行う。

原因効果メタ機能によって使用される内部原因効果テーブルは解剖システム、それらの関係、それらの病気および病気の原因の鎖の基本的な医学知識を含んでいる。このテーブルは根本の原因および２次的な病気を探求するために必要なパターンを識別する。原因の鎖の処理を制御するのに使用される第２のテーブルは、発生の確率、２次的な病気の重要性、および起こり得る治療のウインドウのような他のデータを含んでいる。

連鎖メタ計算の結果は現在の患者で検証し、監視する病気のリストである。これらの結果は下記において有用である。

・病気の副作用が脱落しないことを保証している。

・患者を安定させるために必要な疾患管理療法を見落とさない。

・他の効果（頭痛は盲腸炎と一貫している）を確かめることによって、原因を確証する。

・所要の効果を見出さないことによって、原因を否定する（血液中にマラリア原虫がいないことでマラリアを否定する）。

・領域メタ
領域メタの例は、時間に対する苦痛あるいは不快さを図に描き、その時苦痛を蒙っているあるいは不快の総量を見出すために、カーブの下の領域を積算することによって説明することができる。多くの患者、特に末期ガンの患者のような不治の病気を持つ患者は、連続した苦痛を持っているが、しかし彼らは孤立していて、規則的に彼らの医者に診てもらわない、あるいは彼らの医者はどれぐらい患者が苦しんでいるかを評価しないから、これは重要である。彼らは「苦痛を追う」傾向があり、決して苦痛を捕らえようとはしない。ここで、ひとたび苦しみの閾値に出会ったならば、患者は麻酔性の鎮痛剤を得るか、あるいはそれらの服用量を増加させるであろう。

・容積測定メタ
容積測定メタ機能は病気×解剖×時間の（３次元の）積に基づいて分析を実行し、予め決められた閾値に基づいて勧告を行う。用語「容積測定」は、使用されるメタデータ立方体の解析法を参照しており、その中で喫煙の履歴は３つの軸Ｐ（毒）、Ｒ（呼吸器のシステム）およびＺ（時間）によって囲まれた容積として現れる。たとえば、３０年間毎日２箱の煙草を喫煙した患者は、呼吸器のシステムに影響を与えている６０箱−年の歴史を持っていると見なされる。

容積測定の分析は多くの病気のプロセスで重要である。このように、６０箱−年の喫煙容量を持つ患者は呼吸器システムに著しい被害を集積している。これがより長く続けば、より大きな容積となり、より多くの毒が呼吸器システムの機能に影響を与え、そして多分より多くの診断および治療となるであろう。

もう１つの容量測定の分析の例は、糖尿病が微小血管の循環で起こす長期の被害である。

容積測定メタ機能のソフトウェアの具体化は、種々の病気に対する容積測定の積を、それらの閾値パラメータと同様に、リストした内部疾患管理テーブルを含んでいる。これらの閾値（感度ファクター・セットによって動的に修正された値）は、特別な動作およびシステムの解析を制御する。適用可能な閾値に到達した場合は、システムは特別な分析を実行し、その時内部警報を発行し、適用可能な器官のシステムになされた被害の可能な証拠を探索し、患者に対する特別の勧告を行う。

・信頼性メタ
信頼性メタ機能は患者の世話が不充分であるかどうかを見るために患者のデータ項目のすべての信頼性を調査する。もしこの機能が（分離されたあるいは組み合わされた）診断の確率が（感度ファクター・セットによって修正された）信頼性の閾値の下であることを見出した場合、この機能は患者の再評価を勧告することができる。

この機能は、すべてのデータ項目と組み合わされた内部信頼性表示子を使用し、それはデータ項目がそれが記録されている時間の患者の実際の健康を反映する確率を追跡する。これらの信頼性表示子は、医学管理システムの各データ項目に対しそれが最初に確立した時に、確立され、システムにおいてその寿命を通じてそれに対応して維持される。

たとえば、患者がシステムに彼が偏頭痛の頭痛の履歴を有すると告げた場合は、システムは患者に次のように尋ねることができる。

・誰が偏頭痛の診断をしたか？（患者、友人、看護婦、医者、あるいは神経科医）
・何の試験が、誰によって、何の組織上で、行われ、どんな結果であったか？
・誰が試験を、どのように、どんな関係で確認したか？
その理念は、勿論頭痛の専門家が、脳の影像撮影（ＭＲＩ）、腰椎穿刺、ＥＥＧを含む、充分で完全な精密検査の後に診断を行ったならば、診断が正しい確率は非常に高いと言うことである。これは信頼性表示子に記録され、診断のデータ項目と組み合わされるであろう。信頼性があまりにも低い場合は、より高いレベルあるいは標準の保護の再評価が計画されるであろう、それはより多くの精密で完全な質問を呼び出すであろう。

疾患管理の利益
医療管理システムおよび疾患管理モジュールの利益は次の通りである。

患者に対する利益
・より速い、より容易な、より安い医療サービス
・必要な時には、家庭から時間外にアクセス可能な医療サービス
・遠隔地、貧困社会でアクセス可能な医療のサービス
・最新、最良、テスト済み、更新された医療サービス
・患者はゆっくり時間をかけ、セッションを繰り返し、ブラウズすることができる
・患者は完全な病歴ファイルを有する
医療従事者に対する利益
・些細な、不適当な、無用な患者との接触を減らす
・医者の診断技術／経験を磨く
・医者は自分の意見を他人と比較できる
・繰り返し患者はより良い、連続した医療記録を提供する
・医療従事者は多くの医療データリソースにアクセスできる
・統計値へのアクセス、データベース、意志決定、スケジューリングをコンピュータがサポート
・セッションと疾患のヒストリーが利用できる
・医療従事者は記録された反応にもとづいて助言／アクションを正当化できる
・患者を集団の中で比較できる
・大きい事例データベースを有する
ヘルスケア・マネージャーに対する利益
・些細な接触の費用を節約する
・接触を追跡する
・統計的情報と計画
・医者／病院の仕事の輪郭を描き出す
・セッション・ログは法的義務と危険性を減らす
・政策の遵守を保証する
・助言と治療を標準化する
ヘルスケア取り締まり人に対する利益
・ＨＭＯ、医者のアクションを吟味し、評価できる
・医療記録は批評のために利用できる
・規則の遵守を検証できる
ヘルスケア教師に対する利益
・医療の仕事は大きい患者集団でシミュレートできる
・医学の研究を助ける
・事例研究の比較ができる
・事例の取り扱いを変化しつつ繰り返しできる
以上の詳細説明は本発明の基本的な新規な特徴を、さまざまな実施例に適用し、示し、説明し、指摘したが、説明された本システムの形式と細部にさまざまな省略、置き換え、および変更が、本発明の範囲から逸脱することなく、当業者によって加えうることは理解できよう。

Claims

コンピュータ化された医療アドバイスシステムであって、
既知のまたは推定された医学的疾患または病状を有する特定の患者（１１４）に対応する患者医療記録と、患者識別子と、前記患者の健康歴を表す前記患者医療記録中の健康パラメータとを保存するためのメモリ（１８４）と、
前記患者の医学的疾患または病状を含む様々な医学的疾患または病状および患者集団に対する複数の臨界カーブを保存するための疾患データベース（２６２）と、
コンピュータを、前記メモリ（１８４）から、既知のまたは推定された医学的疾患または病状を有する前記特定の患者（１１４）に対応する前記患者医療記録を前記患者識別子によって検索するための手段（４５２−４５８）と、前記患者の健康を評価するための手段（４０６）として機能させるためのコンピュータプログラムを備えたコンピュータと、
を備え、
前記患者の健康を評価するための手段（４０６）は、
前記患者（１１４）に自動的に質問をするための手段（４８８、４９０、６０６、６２４、６２６、６２８）と、
前記患者（１１４）に関する主観的健康測定値（６２４）および客観的健康測定値（６２６）の少なくとも１つを含む健康データを得るために前記患者からの応答を自動的に受信するための手段と、
得られた健康データを前記患者医療記録の中に自動的に蓄積するための手段（９６６）と、
前記患者医療記録の一部に対応する特定の健康パラメータを自動的に選択するための手段（６５２、７０２）であって、前記選択は少なくとも前記患者の医学的疾患または病状に基づく、手段と、
前記健康パラメータによって示された、前記患者の健康データの、疾患または病状の以前の管理セッションからの変化を自動的に計算するための手段（６５６、７０４）と、
前記患者の医学的疾患または病状、前記患者集団、および前記特定の健康パラメータに基づいて前記疾患データベース（２６２）から臨界カーブを自動的に選択するための手段と、
前記患者の健康データの変化に基づいて患者の臨界カーブを示すパラメトリックデータを得るための手段（７０６）であって、前記変化は傾向分析を前記健康パラメータに当てはめることにより示される、手段と、
前記パラメトリックデータにより表される通りの変化を、前記疾患データベース（２６２）からの前記医学的疾患または病状に対する選択された臨界カーブから抽出されるパラメトリックデータと自動的に比較するための手段（７１２）と、
を備え、
前記コンピュータプログラムは、前記コンピュータを、
前記得られた健康データと前記比較の結果に基づいて、前記特定の患者（１１４）のための、疾患または病状の療法、介入または教育プロセスの調整手段（７７０、７９０）を備える手段（４０８）であって、疾患または病状の療法、介入または教育プロセスの前記調整手段は、薬の処方、服薬、投薬方法、または治療のタイミングの内の少なくとも１つを調整することにより疾患療法を最適化する、手段と、
前記特定の患者（１１４）のための、疾患または病状の療法、介入または教育プロセスの前記調整手段（７７０、７９０）を示すデータを自動的に出力するための手段（９５８、９６０）と、
としてさらに機能させ、
前記医療アドバイスシステムは、
前記得られた健康データと、疾患または病状の療法、介入または教育プロセスの前記調整手段が、複数の患者の各々に対して行うことができる調整の複数のレベルのうち１つを示すデータとにアクセスすることが許されるかどうかのレベルを示す、前記特定の患者に対する認可レベルを有する認可情報を記憶するための認可データベース（２５６）と、
前記メモリ（１８４）中のデータへのアクセスおよび前記医療アドバイスシステムの動作を制御するように前記認可データベース（２５６）と通信するためのインタフェース手段と、
前記疾患療法を前記特定の患者に提示する手段であって、前記認可データベースは、人間の介入なしに直接かつ自動的に変更される療法の情報をさらに含み、前記認可データベースと前記インタフェース手段は、前記特定の患者に対する疾患療法の調整に影響を与えるように動作する、手段と、
をさらに備える、システム。
前記認可情報は特定のエージェント、エージェンシーまたはソフトウェア・エンティティーによってアクセスすることが許されるかどうかに関する、請求項１に記載のシステム。
前記認可情報は法的規制にもとづきアクセスすることが許されるかどうかに関する、請求項１に記載のシステム。
前記疾患または病状の療法、介入または教育プロセスの調整を示すデータは療法処方せんまたは療法調整を有する、請求項１に記載のシステム。
前記認可レベルは、前記患者に医療情報を提供するための前記コンピュータプログラムの自動性を示す、請求項１に記載のシステム。
前記認可レベルは前記コンピュータプログラムと関連する医療情報にアクセスすることができるかどうかを示す、請求項１に記載のシステム。
コンピュータ化された治療変更システムであって、
既知のまたは推定された医学的疾患または病状を有する特定の患者（１１４）に対応する患者医療記録と、患者識別子と、患者の健康歴を表す前記患者医療記録中の健康パラメータとを保存するためのメモリ（１８４）と、
患者の医学的疾患または病状を含む様々な医学的疾患または病状および患者集団に対する、複数の標準の臨界カーブを保存するための疾患データベース（２６２）と、
前記メモリ（１８４）から、推定された医学的疾患または病状を有する前記特定の患者（１１４）に対応する患者医療記録を、前記患者識別子によって検索するための手段（４５２−４５８）と、
前記患者の健康を評価する手段（４０６）と、
として機能するためのコンピュータプログラムを備えたコンピュータと、
を備え、
前記患者の健康を評価する手段（４０６）は、
前記患者（１１４）に自動的に質問をするための手段（４８８、４９０、６０６、６２４、６２６、６２８）と、
健康データを得るために前記患者から応答を自動的に受信するための手段であって、前記得られた健康データは、前記患者（１１４）に関する主観的健康測定（６２４）および客観的健康測定（６２６）の少なくとも１つを含む、手段と、
前記得られた健康データを前記患者医療記録の中に自動的に蓄積するための手段（９６６）と、
少なくとも前記患者の医学的疾患または病状に基づいて、前記患者医療記録の一部に対応する特定の健康パラメータを自動的に選択するための手段（６５２、７０２）と、
前記患者の医学的疾患または病状、前記患者集団、および前記特定の健康パラメータに基づいて、前記データベースから標準の臨界カーブを自動的に選択するための方法と、
前記健康パラメータによって示された、前記患者健康データ中の以前の疾患または病状の管理セッションからの変化を自動的に計算するための手段（６５６、７０４）と、
前記受信された応答に基づいて、患者の臨界カーブを自動的に作成するための手段と、
前記患者の健康データの変化に基づいて前記患者の臨界カーブを示すパラメトリックデータを得るための手段（７０６）であって、前記変化は傾向分析を前記健康パラメータに当てはめることにより示される、手段と、
前記患者の臨界カーブを、前記疾患データベース（２６２）からの前記選択された標準の臨界カーブに対して自動的に比較する手段（７１２）と、
を備え、
前記コンピュータプログラムは、
疾患療法を最適化するための手段（４０８）であって、前記療法を最適化するための手段（４０８）は、前記得られた健康データと比較結果に基づいて、前記特定の患者（１１４）のための疾患または病状の療法、介入または教育プロセスを調整するための手段（７７０、７９０）を備え、前記疾患または病状の療法、介入または教育プロセスを調整する手段は、薬の処方、服薬、投薬方法、または治療のタイミングの内の少なくとも１つを調整する、手段と、
前記特定の患者（１１４）のための、疾患または病状の療法、介入または教育プロセスの調整（７７０、７９０）を示すデータを自動的に出力するための手段（９５８、９６０）と、
としてさらに機能し、
前記コンピュータプログラムは、
前記特定の患者に対応する治療変更認可レベルを提供するための手段と、
前記治療変更認可レベルによって許容された、前記疾患または病状の療法、介入または教育プロセスの調整を示すデータを前記患者に提示するための手段であって、前記治療変更認可レベルは自動的な療法の変更が前記特定の患者に割り当てられるかどうかを示し、前記療法の変更が前記特定の患者に割り当てられる場合、前記治療変更許可レベルは、服用量の任意の増加が前記特定の患者に割り当てられるかどうかと、服用量の任意の減少が前記特定の患者に割り当てられるかどうかとをさらに示す、手段と、
としてさらに機能させる、システム。
前記疾患または病状の療法、介入または教育プロセスの調整を示すデータは新しい療法の開始を含む、請求項７に記載のシステム。
前記疾患または病状の療法、介入または教育プロセスの調整を示すデータは既存の療法の中断を含む、請求項７に記載のシステム。
前記疾患または病状の療法、介入または教育プロセスの調整を示すデータは既存の療法への新しい療法の追加を含む、請求項７に記載のシステム。
前記パラメトリックデータがカーブポイントおよび傾斜を含む、請求項１に記載のシステム。
前記パラメトリックデータがカーブポイントおよび傾斜を含む、請求項７に記載のシステム。