医療情報システム
【課題】 異なるシステム間での情報のやり取り、異なるシステムに係る複数情報の一元的な取り扱いを可能とする医療情報システム等を提供すること。
【解決手段】 コンピュータに、種々のソフトウェア・コンポーネントを構造的に制御させ、医療情報システム上の端末において種々の医療情報を統括的に表示する統括画面を表示する医療情報表示プログラム等である。何れかの端末において所定の医療情報に変更指示が入力された場合、当該変更指示が入力された医療情報を表示するコンポーネントに、変更指示を送信する。一方、変更指示に対応しないコンポーネントは、新たな実行時の引数によって再始動される。
【解決手段】 コンピュータに、種々のソフトウェア・コンポーネントを構造的に制御させ、医療情報システム上の端末において種々の医療情報を統括的に表示する統括画面を表示する医療情報表示プログラム等である。何れかの端末において所定の医療情報に変更指示が入力された場合、当該変更指示が入力された医療情報を表示するコンポーネントに、変更指示を送信する。一方、変更指示に対応しないコンポーネントは、新たな実行時の引数によって再始動される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、医療情報システムに関する。
【背景技術】
【０００２】
従来の医療情報システムでは、種々のプログラム表示コントロールシステムが、単一の表示/モニター（仮想又はリアル）上の若干のプログラム表示を調整するために使用されている。例えば、X Windows（登録商標）環境では、そのようなコントロールシステムは、ウィンドウマネージャーと呼ばれる。既知のウィンドウマネージャーの例としては、FVWM、FVWM９５、TWM/VTWM、MWM、CTWM、OLWM/OLVWM、wm２/wmx、AfterStep、AmiWM、Enlightment、WindowMaker、SCWM、IceWM、SawFish及びBlackboxが挙げられる。例えば、X Windows（登録商標）ウィンドウマネージャーの下で走らせるアプリケーション用の構成ファイルを使用すれば、ウィンドウ処理パラメータ（例えば、ウィンドウの場所及び色）をアプリケーションの起動時に設定できる。
【０００３】
X Windows（登録商標）では、様々な再使用可能なコンポーネントのライブラリが、GUI内の様々なコンポーネントの見た目と感触を標準化するために作成されている。そのようなライブラリには、OpenLook及びMotifが含まれ、様々な機能（例えば、ボタン及びメニュー）を持つ「ウィジェット」を処理する。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、医療産業の参加者のコンソーシアムは、結束してClinical Context Object Workgroup（CCOW）を組織した。これは、１９９８年の白書によれば、「ユースポイントで独立してオーサリングされた医療アプリケーション中の、共同的な対話を視覚的に統合化する規格を公表する」というものである。更に白書は、「バージョン１の規格（１９９９年４月に批准された）であるPatient Linkは、選択された患者のアプリケーションの同期化をサポートする」と述べている。アプリケーションのユーザが、選択される患者を変更すると、ワークステーション上の他のアプリケーションも追随して変更される。その共同によって、ユーザは、二つ以上のアプリケーションにおいてアクションを繰り返すという単調さから解放される。その後、バージョン１.１及び１.２が、２０００年の１月及び５月にそれぞれ批准されている。
【０００５】
一方、医療の現場では、RIS、HIS、PACS、電子カルテ等の種々の情報システムが導入されている。これらは、それぞれ異なるプロトコルを使用しており、異なるシステム間での情報のやり取り、異なるシステムに係る複数情報の一元的な取り扱いには、多くの制限がある。
【０００６】
また、医療情報システムは、診療科毎の医師、医療技師、薬剤師、医療事務員等の種々の専門分野に渡るユーザによって使用される。従って、例えばユーザに、異なるシステムに係る複数情報を一元的に提供する場合には、ユーザ毎にカスタマイズ可能な構成であることが好ましい。
【０００７】
本発明は、上記事情を鑑みてなされたもので、異なるシステム間での情報のやり取り、及び異なるシステムに係る複数情報の一元的な取り扱いを可能とする医療情報システムを提供することを目的としている。
【課題を解決するための手段】
【０００８】
本発明は、上記目的を達成するため、次のような手段を講じている。
【０００９】
請求項１に記載の発明は、所定の属性毎に分類された医療情報を管理する前記各属性毎のコンポーネントによって共有される医療情報システムであって、ユーザからの所定の指示に応答して、ネットワーク上の少なくとも一つの端末に、複数の属性のそれぞれに対応する医療情報を統合的に表示するための統合画面のレイアウト情報を、操作者毎に管理する情報管理サーバと、入力される操作者情報に基づいて、前記情報管理サーバから所定の操作者に関するレイアウト情報を取得するレイアウト情報取得手段と、前記レイアウト情報の取得に連動して、前記統合画面に含める医療情報を、複数の前記コンポーネントから取得する医療情報取得手段と、前記レイアウト情報及び前記医療情報が取得されると、前記レイアウト情報を用いて前記医療情報を属性毎に分類した前記統合画面を生成し表示する表示手段と、を具備することを特徴とする医療情報システムである。
【発明の効果】
【００１０】
以上本発明によれば、異なるシステム間での情報のやり取り、及び異なるシステムに係る複数情報の一元的な取り扱いを可能とする医療情報システムを実現することができる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施形態を図面に従って説明する。なお、以下の説明において、略同一の機能及び構成を有する構成要素については、同一符号を付し、重複説明は必要な場合にのみ行う。
【００１２】
図１は、コンピュータ１００a、１００b、及び１００cのネットワークシステムの図解である。このネットワークには、情報化統合ツール及びインターフェースを介してアクセスでき、領域固有のインターフェースを、より迅速に一貫して実現できる。図１に示すシステムでは、各情報保存システム（PACS, HIS, RIS, 事務系の情報システム、薬局等の情報システム等）の各データベース２１０が共有される。各データベース２１０は、情報統合ツール及び／又はアプリケーションプログラムインタフェース（API）２００を介してアクセスされる。コンピュータ１００a、１００b及び１００cのDSUI（Domain-Specific-User-interface）として、それぞれ、a）整形外科表示、（b）集中治療室（ICU）表示及び（c）内科表示が例示してある。他のDSUIも、医療の領域及び他の領域の両方で可能である。各ＤＳＵＩでは、多くコンポーネントの表示が、（１）それらの独立のウィンドウ内で、又は（２）単一の統合ウィンドウの境界内で、同期を保つ必要がある。
【００１３】
複合システム、例えば、DSUIの役割をする患者情報システムでは、データは、多くのソースによって生成され、情報保存システム２１０内で様々なフォーマットで保存される。例えば、放射線データは、第１データベースに画像として保存され、他の患者情報（例えば、心電図トレース又は病理検査の結果）は、第２データベースに少なくとも１枚の画像及びテキストとして保存される。人口動態的な情報は、同じか又は異なるデータベースに保存され、他の患者情報と関連付けられる。
【００１４】
更に、各コンピュータ１００a、１００b及び１００cからサーバ２００を介した情報保存システム２１０のデータへの読み書きのアクセスは、少なくとも一つのコンポーネントによって可能であることが好ましい。データも、様々なフォーマット（例えば、DICOM、HL７）で伝達されることが好ましい。そこではコンポーネントによる使用を直接容易にする表現が最も好ましい。
【００１５】
例えば、XML（eXtensible markup language）は、データ表現と交換のために、簡単で頑健、かつ拡張可能な規格を提供する。XMLファイルは、それ自身の記述で分散されるので、統合された情報オブジェクトを生成することができる。従って、XMLにより構造化及び拡張が可能となり、妥当性確認が提供される。また、XMLによって、情報（例えば、医療のコンテキスト中では患者情報、又は犯罪のコンテキスト中では容疑者/犯人情報）を保存し識別する構造が得られる。情報は、ソフトウェア設計のオブジェクトと全く同様に、階層的に構造化される。新情報が入手可能になると、XML構造は拡張できる。XMLによれば、データ妥当性を確実にするメカニズムを提供し、XMLSQLのような照会言語ツールを使用して直接検索することができる。
【００１６】
図２は、例えばウェブブラウザ又は他のGUIインターフェースを使用した場合の、人々と各エージェント（確認エージェント２００ａ、表示エージェント２００ｂ、統合エージェント２００ｃ）、又は各エージェント間での情報フローを示すデータフローモデルである。なお、各エージェントは、場面に応じて意図を理解し、自立的な判断に基づいた処理を実行する機能であり、サーバ２００内で実行される。また、モデルは、いくつかのハイレベルのステップを含んでいる。これらのステップは、追加のサブステップかオプショナルなステップで実施され、（１）ログイン、（２）オブジェクト選択（例えば、患者選択）、（３）情報表示及び（４）ユーザ選考管理を含んでいる。
【００１７】
確認エージェント２００ａ、表示エージェント２００ｂ、統合エージェント２００ｃの機能は、例えば次のようである。
【００１８】
一般に、確認エージェント２００ａは、ユーザとデータとの間で門衛の役割をする。ユーザログインの情報は、任意の方式で確認できる。具体的方式としては、NT確認又はCORBA（登録商標）セキュリティサービス等が挙げられる。本実施形態では、ユーザは、確認プロセスによってカスタマイズ可能なDSUIの特徴に関するユーザ選考にアクセスできる。ここで重要な点は、一旦確認されると、ユーザは、システムによって認可されたアクセス権に相当するアクセスのタイプ及び有効範囲を与えられることである。例えば、一部のユーザは、読み出し専用アクセスを持ち、一方他のユーザは、読出書込みアクセスを持つ。更に、すべてのユーザが、システムのデータをすべて見ることができるとは限らない。例えば、病院経営者は、患者の訪問に関して請求情報を見ることができる一方、実際の放射線又は診断の情報は入手できない。従って、確認エージェント２００ａは、患者記録を選択する過程の間に連続のブローカーの役割をする。このような選択は、例えば、番号、場所等によって多くのメカニズムを通じて行われる。医療環境では、確認エージェント２００ａは、患者記録選択情報を統合エージェント２００ｃのもとへ送る。
【００１９】
統合エージェント２００ｃは、この選択情報に基づいて患者情報を表示のために構築し、かつユーザに返す。
【００２０】
表示エージェント２００ｂは、ユーザが表示インターフェースの一部をカストマイズしている場合には、表示される結果を適切にフォーマットするためにそのカスタマイゼーション情報にアクセスする。以下詳しく論じるように、標準インターフェースのユーザは、ユーザ選考に適するためにそのインターフェースを並べ替えてもよい。そのような並べ替えは、左から右でなく右から左へ読む言語を受け入れるようにインターフェースを国際化することを含んでいる。
【００２１】
図３は、サーバ２００内において、種々のロケーションから読み出されたデータが、いかに組み合わされ、要求されたデータとともに最終的に与えられるレイアウトを生成するかを示す。
【００２２】
一般に、統合エージェント２００ｃは、少なくとも一つのソースから情報患者記述データブロックを（好ましくはXMLを使用して）を構築するために、情報にアクセスする。各データソースにそれ自身のネーティブな基準でアクセスするためのインターフェースは、個別のモジュールとして、又は単一モジュール内で実施される。しかし、この好ましくは、そのような実施選択は、データの物理的な場所さえも隠すデータベース抽象化の後ろに隠される。実施例の一つとして、このエージェントは、既知の水平コンポーネントサービス（例えば、CORBA（登録商標）Medにより提供される患者同定サービス）を利用することができる。他の実施例としては、レポジトリーか又は他の集中型データストアが（データベースシステムかファイルベースシステムの片方か又は両方を含んで）利用される。
【００２３】
表示エージェント２００ｂは、例えば、XMLフォーマットにて、レイアウト構造のローカルストアにアクセスする。これらの構造は、後述するレイアウトエディターによって開発され（図１５参照）、表示制約に対応するデータベースの一部中で保管される。
【００２４】
最終的に、データ及びレイアウトは、表現コンポーネントによって結合される（つまり表現される）。このプロセスは、検索された患者情報をレイアウト情報と組み合わせる。表現コンポーネントは、完全な報告書をユーザへ転送する前に、表示される情報（例えば、患者記録）に関するコンテキスト情報を利用する。
【００２５】
実施形態としては、単一の統合化ウィンドウは、ウェブベースのアーキテクチャ内におけるコンポーネントベースのアプリケーションとして使用されることが好ましい。一般に、システム開発者は、コンポーネントのアーキテクチャによって、特定のオブジェクトのために設計される再使用可能なポータブルソフトウェアコンポーネントを生成できる。それらのコンポーネントは小さく、理解し維持することが容易であり、より大きなアプリケーション内の狭い機能を果たすことが好ましい。アプリケーション開発者は、ソフトウェアコンポーネント中の機能をカプセル化することによって、アプリケーションを迅速に構築するために使用できる共通のコンポーネントのライブラリを持つことができる。コンポーネントの機能を狭く保つことによって、個々のコンポーネントを多くのアプリケーションで使用（又は再使用）できる。また生じるコンポーネントウェアを迅速に開発し移植性を持たせることができる。
【００２６】
再使用を容易にするために、一連の標準インターフェース及びコンポーネントの技術が、好んで使用される。入手可能な多くの技術があり、それらは、システム実現詳細をソフトウェアの開発から抽象化する。システムは、ウェブパラダイムを使用して、プラットフォームO/S（例えば、Windows（登録商標）９X、Mac、UNIX（登録商標）、Windows（登録商標） NT）にかかわらず通信する。ウェブサーバーは、実施の詳細を依頼者から隠す。サーバーは、HTMLフォーマットで結果を表すために、共通のゲートウェイインターフェース（CGI）及びアクティブなサーバーページ（ASP）のような技術を利用できる。しかしながら、HTMLは、XMLのリッチネス及び自己記述性質を欠く。更に、サーバーサイドコンポーネント（例えば、CGIスクリプト及びプログラム）は、多くの場合機械に依存する。従って、CGIはプラットフォーム独立性に近づくことに役立つが、移植性の欠点を持っている。Java（登録商標）仮想マシン及びバイトコードの使用によって、多数のオペレーティングシステム及び種々の開発言語の環境中で、コンポーネントベースのソフトウェアシステムの移植性が増加する。下位レベルコンポーネントをシステムのビルディングブロックとして使用することに加えて、高位レベルコンポーネント（又はアプリケーション）は、下位レベルコンポーネントの表現及び統合を管理する。
【００２７】
また、クロスプラットフォーム移植性は、様々な補足的な技術、例えば、Java（登録商標）、Enterprise Java（登録商標） Beans（EJB）及びCORBA（登録商標）によって向上させられる。さらに、他のオブジェクトモデル（例えば、DCOM）も、コンポーネントの操作がコンテキストの枠組みの機能から分けられる限り、使用できる。それら技術の一部の関係は、図４で示される。CORBA（登録商標）は、異種のシステム中にコンポーネントを分散するメカニズムを提供する。更に、CORBA（登録商標）は、サービス（例えば、安全保護、命名、トランザクション処理）を提供し、コンポーネントの実施詳細からアプリケーションを更に分離する。EJBは、ウェブオペレーティングシステムの役割をするコンテナの提供により、CORBA （登録商標）より更に一歩先を行く。コンテナは、アプリケーションに抽象の追加層を提供して、実施詳細を維持する。
【００２８】
上述のコンポーネント技術を使用することによって、アプレットの役割をする様々なDSUIを生成できる。更に、図１７等を利用して後述するように、非アプレットベースの技術が可能である。
【００２９】
図５は、このようなDSUIの一例として、肺専門医インターフェースを示している。このインタフェースによって、患者のテキスト及びグラフィックの情報が調整される。図５に示すように、DSUIは、様々な表示コントロールを提供する。例えば、六つのタブ２５０、六つのパネル２６０及び情報状態バー２７０である。六つのタブ２５０の各々は、ページを選ぶことに相当し、あたかも箱からタブのついた索引カードを選ぶことに酷似している。六つのパネル２６０の各々は、状態バー２７０に含まれる情報と同期を保つ。その逆もまた真である。
【００３０】
従って、肺専門医インターフェースのユーザが、一つの表示コントロールを使用して、異なるユーザに入れ替わった場合を想定する。この入れ替わりのための操作は、訪問リストから新しい訪問を選ぶこと等の選択、例えばテキストリスト、プルダウンボックス、スクロールリスト及び１組のラジオボタンのうちいずれかとして実施される。この場合、残りの表示コントロールは、全てユーザの入れ替わりに従って変化するように、例えば、下記のメッセージングを使用してコントロールされる。
【００３１】
図６は、調整画像及びデータ表示を提供するコンピュータシステム１００を示した図であり、図１の各端末１００ａ、１００ｂ、１００ｃの具体例である。コンピュータ１００では、本実施形態に係るシステムに従って、上述した表示系が提供される。
【００３２】
コンピュータハウジング１０２は、マザーボード１０４を収容する。マザーボードは、CPU １０６、メモリ１０８（例えば、DRAM、ROM、EPROM、EEPROM、SDRAM、SDRAM及びフラッシュRAM）及び他のオプショナルな専用論理デバイス（例えば、ASIC）又は構成可能な論理機構（例えば、GAL及び再プログラム可能なFPGA）を含んでいる。
【００３３】
コンピュータ１００は、更に複数の入力装置（例えば、キーボード１２２及びマウス１２４）及びモニター１２０をコントロールする表示カード１１０を含んでいる。更に、コンピュータシステム１００は、フロッピー（登録商標）ディスクドライブ１１４、取外し可能な媒体デバイス（例えば、コンパクトディスク１１９、テープ及び取外し可能な光磁気媒体（図示せず）、ハードディスク１１２、又は適切なデバイスバスの使用により接続された他の固定の高密度媒体ドライブ（例えば、SCSIバス、拡張IDEバス、又はUltra DMAバス）も含んでいる。
【００３４】
更に、コンピュータ１００は、同じデバイスバス又は別のデバイスバスに接続され、コンパクトディスクリーダ１１８、コンパクトディスクリーダ/ライタユニット（図示せず）又はコンパクトディスクジュークボックス（図示せず）を追加して含んでいる。コンパクトディスク１１９は、CDキャディーで示されるが、コンパクトディスク１１９は、キャディーを要求しないCD ROMドライブへ直接挿入できる。更に、プリンタ（図示せず）は、調整表示からの報告書の印字されたリストも提供する。
【００３５】
上述のように、コンピュータシステム１００は、少なくとも一つのコンピュータ読み取り可能な媒体を含んでいる。コンピュータ読み取り可能な媒体の例は、コンパクトディスク１１９、ハードディスク１１２、フロッピー（登録商標）ディスク、テープ、光磁気ディスク、PROM（EPROM、EEPROM、フラッシュEPROM）、DRAM、SDRAM、SDRAMなどである。本実施形態に係るソフトウェアは、コンピュータ読み取り可能な媒体の一つ又はそれらの組合せ上に保存され、コンピュータ１００の両方のハードウェアをコントロールし、コンピュータ１００が人間のユーザと対話することを可能にする。このようなソフトウェアは、デバイスドライバー、オペレーティングシステム及びユーザアプリケーション、例えば開発ツールを含んでいるが、これらに限らない。このようなコンピュータ読み取り可能な媒体は、表示コントロール又はコンポーネントの調整コントロールを提供する本発明のコンピュータプログラム製品をも含んでいる。
【００３６】
ここに記述されるように、本実施形態に係るコンピュータコードデバイスは、解釈され実行可能なコードメカニズムのいずれでもあり得る。そして、それはスクリプト（CGIスクリプトを含む）、インタープリタ、ダイナミックリンクライブラリ、Java（登録商標）class、Java （登録商標）beans、Active X controls、CCOW準拠コントロール及び完全な実行可能プログラムを含んでいる。しかしながら、これらに限定する趣旨ではない。また、コンピュータコードデバイスは、コンピュータネットワークアダプタからダイナミックにダウンロードでき、コンピュータネットワークアダプタは、コンピュータ読み取り可能な媒体の等価物として働いている。更に、単一のコンピュータコードデバイスによって実施されるコンポーネントの数、又は単一のコンポーネントを構築するために要求されるコンピュータコードデバイスの数は、コンポーネントによって異なることがある。以下、コンポーネントについて説明する。
【００３７】
コンポーネントの階層セットを提供することによって、コンポーネントは機能によって分類できる。例示的な分業は、（１）既存の病院システムにアクセスし情報を保存するコンポーネント、（２）XMLメタ構造を使用して情報を構成するコンポーネント及び（３）データ表現（例えば、グラフ作成コンポーネント、画像を様々なフォーマット、すなわちTIFF、GIF、JPEG、ビットマップ等で表示する画像コンポーネント）を含んでいる。
【００３８】
このようなコンポーネントのセットによって、更に安全保護を別々に扱うことができる。少なくとも二つの汎用のアプローチが、安全保護にとって可能である。第一に、コンポーネントそれ自体の中で実施された安全保護特長が使用できる。基本的に、これは、安全保護がシステム全体の問題ではなく、むしろシステムによって利用されたコンポーネントの問題であることを意味する。コンポーネントの安全保護能力が進化するとともに、システムは、これらのコンポーネントを自動的に取り入れる。
【００３９】
第二のアプローチは、「安全保護コンポーネント」を使用するか、又は、CORBA（登録商標）によって提供される水平サービスのうちの一つを使用する。そのようなコンポーネントは、ユーザアクセスを確認する責任を持ち、安全保護方針が強化されることを保証するためにコンポーネントによる通信を仲裁することができる。このアプローチは、より大きな安全保護レベルを提供するが、他のコンポーネントが更に協力する必要がある。そのような安全保護コンポーネント及びCORBA（登録商標）サービスの使用は、標準化される必要があり、それによって第三者コンポーネントを利用する能力を減らす必要がある。
【００４０】
階層コンポーネントの組織は、更に専門化アクセス及び表示プログラミングを局所化する。アクセス規格が整備されていない場合、独占情報へのアクセスは、扱いやすい場所で分離することができる。XMLは、表示のための情報を表現するメカニズム（例えば、CSS、XSLT、XSL）を提供する。それらのメカニズムによって、ユーザ及びタスクに依存して、同じ情報を異なる表示特性に関連付けることができる。例えば、患者は年齢によって、ある特性又は疾患に関しては低リスクグループに分類される。しかし別の特性又は疾患に関しては高リスクグループに分類される。
【００４１】
XMLベースの文書オブジェクトモデル中の名前付き要素タグを介して、データにアクセスすることによって、コンポーネントは、間接指定の追加レベルで構成され得る。必要な情報を含んでいるタグの名前（つまりプログラム変数）は、前もって知られている。これによって、一般化ラッパーコンポーネントを実施できる。それを使用して、既存のソフトウェア（例えば、Algotec MediSurf Viewer）は、患者コンテキストコンポーネントに統合され得る。
【００４２】
例えば、MediSurfをhttp：//medisurf/start? study_display（１.２２３４.４４３４.３４５５.３４５６５４）のようなStudyInstanceUIDで起動する必要がある場合に、外部仕様（layoutXMLレイアウト内の）が、StudyInstanceUIDのコンテンツを名前付きのアプリケーションに送信するために生成される。同じ方法を使用すると、ソフトウェアへのパラメータが患者記述言語（例えば、XMLベースのDTD）に含まれている限り、他のソフトウェアはラップされ得る。間接指定のこの追加レベルのゆえに、ソフトウェアは、タグ付きパラメータのすべてのインスタンスをソフトウェアコンポーネントに送信できる。コンポーネントは、タグ付き要素の最新のもの、２番目に最新のもの、又は他のインスタンスを外部コンポーネントへ送信するようにプログラムされ得る。
【００４３】
本実施形態に係るシステム内のコンポーネントは、「振る舞いが良い」と見なされる。従って、そのようなコンポーネントは、データの完全性（例えば、同時性管理）を強化し、確認（例えば、患者及び検査情報のためのユーザレベル確認）を利用し、相違するコンポーネントタイプ（CORBA（登録商標）、EJB及びDCOM）と協力する。振る舞いが良いと考えられないコンポーネント、又はシステム想定を強化しないと分かるコンポーネントについては、それらのコンポーネントは、データ変質などを防ぐために他のコンポーネントから分離される。
【００４４】
例えば図５に示した画面例にあるように、領域特定情報（例えば、患者情報）、レイアウト情報及びコンテキスト情報は、例示的なDSUIを形成するために結合される。
【００４５】
図７、図５は、患者記述言語用の例示的な構造を示している。各図に示すように、患者情報を保持するために、XM及びDOMを使用することによって、名前付きタグでコンポーネントと関連付けることができる。
【００４６】
図５のDSUIを使用して、タブ２５０は、六つの異なる情報ビューを表す：（１）肺専門医：要約情報、（２）薬品：患者の薬物適用のリスティング、（３）気管支鏡検査：気管支の可視光線画像、（４）CR：CR画像のビュー、（５）CT： CT画像のビュー、及び（６）心電図： スキャンされた心電図画像のビューである。むしろ、それらのタブの各々は、少なくとも部分的に構成され得る。例えば、名前タブ、ビューの順序及びビューのコンテンツを構成することができる。
【００４７】
エンドユーザが情報と対話するにつれて、DSUIのコンテキストは、タブ付きページ全部の情報の一貫したビューを提供する。医療環境では、コンテキストは、変数、例えば、Active Visit, Active CRStudy, Active Seriesなどを含んでいる。コンポーネントは、コンテキスト変数を追跡するために（又はそれと一貫性を保つために）構成され得る。図５の例を利用して、１/１１/９９訪問に関連する情報が表示される。レイアウトの第１ビュー、つまり肺専門医ビューは、訪問リストコンポーネント、訪問要約コンポーネント、検査リストコンポーネント及び二つの画像表示コンポーネントを含んでいる。それらのコンポーネントの各々は、１/１１/９９訪問に関連する情報を表示する。更に、患者に関連する状態バーの情報を表示する人口動態コンポーネントがある。そのコンポーネントは、訪問とともに変化しない情報を含んでいる。追加のビュー（示されていない）、例えば、CRビューも１/１１/９９訪問に関連する情報を含んでいる。
【００４８】
ユーザが肺専門医ビューの訪問リストコンポーネントから、そのあと１０/３/９９訪問を選ぶ場合、そのビューは変わり、訪問に関するコンポーネントも変わる（例えば、訪問要約コンポーネントは、１０/３/９９訪問に関する情報を提供する。検査リストコンポーネントは、１０/３/９９訪問の検査リストを表示する。表示されている検査と一致するように画像が変わる。アクティブな訪問に関係する他のビューも変わる）。更に、他のページ上のビューも同様に更新される。例えば、CRビュー（第４のタブ）は、変更後の１０/３/９９訪問に関係する情報を含んでいる肺専門医ビュー（第１のタブ）と一致している。しかし、上述のように、いくつかの表示要素は、情報を変更しない。例えば、人口動態情報は、同一人が何回訪問しても変化しない。また、図示の例では変化するべきでない。
【００４９】
コンテキスト変数に従うアクティブコンポーネントを生成する機能が、構成され得る。コンポーネントは、コンテキスト変数を追跡するか又は静止ビューへ設定された状態を保つように構成され得る。例えば、上記のCR検査ビューアーは、アクティブな訪問を追跡する。同じコンポーネントが、最新のCR検査だけを表示するように構成され得る。従って、ユーザがアクティブな訪問を変更するとき、最新のCR検査が常に表示される。
【００５０】
むしろ、コンテキスト変数の構造も、階層構造に保存される（例えば、患者記述言語に似ている構造）。コンテキスト構造は、患者の木構造の各枝に対して変数を含んでいる。これをすることによって、患者情報のアクティブな部分が追跡され得る。
【００５１】
図９の例示的なエンティティー関係図で示すように、コンポーネントは、プロパティの形で保存された三つのタイプの情報を含んでいるビュー、状態及び実施のプロパティである。一般に、このコンポーネントのモデルは、コンポーネントから独立してデータを保存する実施（上記のように）又はコンポーネントと一緒にデータを保存する実施に、例えば、Java （登録商標）Beanの構成をBean自体の中に保存することによって適用され得る。
【００５２】
ビュープロパティは、コンポーネントがどのように表示されるべきか示唆する。しかし、layoutController、すなわち患者コンテキストコンポーネント中のドライビングコンポーネントは、コンポーネントがその最終表現でどのように見えるかコントロールする。図９で示すように、例示的なプロパティは次のものを含んでいる。すなわち、その中でコンポーネントが表示されるべき最小の高さMinHeight及び幅MinWidth並びに最適の背景色BGColorである。
【００５３】
同様に、コンポーネントのStatusPropertiesは、コンポーネントがアプリケーションのコンテキスト中でどのように振る舞うべきか記述する。例示的なプロパティは、コンポーネントがどのように起動されるか指定する初期処理を参照する。状態変数は、患者記述言語の要素タグ（例えば、図７の中の訪問）に相当する。数値は、事前に定義した意味を含んでいる。例えば、０＝最新、１＝最新の一つ前、２＝最新の二つ前などである。他の状態プロパティは、ユーザが介入するときコンポーネントがどのように振る舞うか記述する。その振る舞いは、全体的なシステムの状態の変更、例えば、新しいアクティブな訪問をVisitListコンポーネントから選ぶことによる変更を含んでいる。
【００５４】
アクティブなプロパティは、ブール式である。すなわち、コンポーネントがアクティブな状態とともに変化するべきか、セッション期間を通じて初期設定の状態を保つべきかを記述する。例えば、「はい」の状態は、コンポーネントが他のコンポーネントの設定に追随するために、変化するべきことを示す。「いいえ」の状態は、コンポーネントが初期設定の状態を保つべきことを示す。
【００５５】
TagToFollowプロパティは、状態階層で最低のレベルタグを示し、それはコンポーネントの状態をモディファイするために使用されるべきである。例えば、CRImageViewerは、状態タグCRStudyを追跡する。異なるCRStudyをユーザが選択するとき（つまり、CRStudyの状態が変わるとき）は常に、CRImageViewerは、CRStudyの値を追跡するために変わる。
【００５６】
実施プロパティは、コンポーネントの実際の実施を記述する。それによって、システムは、実際の実行時間コンポーネントを適切なパラメータで起動するラッパーを生成できる。BuilderClassプロパティは、コンポーネントのタイプを記述する。上記にように、多数のタイプ（例えば、Java（登録商標）Classes）の実施技術が、本発明に従って使用され得る。パスプロパティは、実行されるソフトウェアの場所を記述する。パラメータプロパティは、StatusProperties. InitialSettings変数中で指定されないすべての追加始動パラメータ、例えば、ユーザ登録名及びパスワードを提供する。
【００５７】
他の構造又はフォーマットが、図９に関して上述のプロパティを記述するために使用できるが、実施例では、プロパティは、XMLベースの文法を使用して記述されている。図１０では、図９のビュープロパティ及び状況プロパティは、CR及び皮膚の検査に関する情報を表示する検査リストコンポーネントに対する例示的な値で指定される。コンポーネントの最小の高さ及び幅は、１８０及び３２０の画素点としてそれぞれ指定される。背景色は黒として指定される。訪問及び検査は両方とも最新の値（つまり、それぞれ最新の訪問及び検査）を利用する。更に、コンポーネントはアクティブであり、訪問変数に追随することにより他のコンポーネントの変化を追跡する。
【００５８】
最高水準の記述言語は、患者の識別情報を含んでいる。それによって、人口動態及び訪問情報が、そこから拡張され得る。患者記述言語は、「リアルワールド」のDICOMビューから本質的に得られる。それは患者情報を訪問に結び付ける。訪問を使用して、特に病院のセッティング中でケアエピソードを意味のある群にグループ分けする。外来患者か診療所のセッティング中で、より有用なグループ分けは、診断コード又は他の情報であって、患者情報をケアのエピソードへグループ分けするものである。例えば、それは脚の骨折に関する情報を一括して、その情報を心臓の状態に関する情報から論理的に分離する。
【００５９】
この情報は、別の規格のフォーマット、例えば、HL７ RIMモデルに保存され得る。しかし、この情報は、その構造がタスクをサポートする限り、データベースにおいて構造化されるのと同じフォーマットで構造化される必要はない。
【００６０】
アプリケーション内のコンテキスト変数は、患者の木構造の分岐点で維持される。木の枝が、各タイプの検査（例えば、CRStudy、DermStudy、CTStudy）に対して維持される場合、コンテキスト情報は、これらの変数に対して維持され得る。なぜなら、どの検査がどの時間にアクティブか、例えば、どんなグループ検査に訪問が対応するか、どんな薬物が利用され処方されたか、が知られているからである。
【００６１】
CRStudyは、CRモダリティ情報だけを含んでいる。それは、検査及び一つ以上のシリーズ要素に関する一般情報を含んでいる。実際の画像は、シリーズレベルに含まれている。
【００６２】
ECGStudy要素のフォーマットは、CRStudyに準じている。再び、最高水準は、検査に関する一般情報を含んでいる。そして一つ以上のシリーズ要素がある。画像は、シリーズレベルに含まれている。
【００６３】
一実施例では、再利用を更に容易にするために、モダリティ固有のコンポーネントは、モダリティ独立のコンポーネントから分離される。モダリティ固有のコンポーネントは、一般に、与えられたモダリティに固有の物理ハードウェアプロセスをコントロールするコンポーネントである。「最下部」インターフェースでは、これらのコンポーネントは、トランスデューサ又はデジタル入出力インターフェースをコントロールするが、これらは、放射線の発生、機械的動作又は他のハードウェア活動をコントロールするために必要である。「最上部」では、これらのコンポーネントは、モダリティに依存しない抽象の隣の層に共通のインターフェースを提供するように設計されるべきである。モダリティ独立のソフトウェアは、DICOM通信及びフォーマットソフトウェアコンポーネント、ファイル管理コンポーネント、システム管理及び保守ツール、DICOMモダリティワークリストコンポーネント、DICOM MPPSコンポーネントなどを含んでいる（図１１を参照）。
【００６４】
そのような実施によって、DSUIを汎用目的に定義できる。これは、個々のニーズにカストマイズされるモダリティ用のユーザインターフェースの「レイアウト」を通じて行われる（例えば、病院の現場又は個々の医療専門家（例えば、医師、看護婦及び医療管理者））。特注レイアウトの設計、作成及び修正は、エンドユーザが、レイアウトエディターツールを使用して行う。新しいレイアウト、又は管理/保守レイアウトは、標準ウェブ通信プロトコルを使用してダウンロードする。保守レイアウトは、エンドユーザレイアウトがアクセスできない特殊コンポーネントにアクセスする。
【００６５】
レイアウトの単一ページは、パネルの再帰的ネスティングを含んでいる階層構造によって記述される。これによって、レイアウトは、そのレイアウトに透明なサブレイアウトになる。「高位」レイアウト中でそのレイアウトに言及するだけでよい。各レベルでは、パネルは、レイアウトをコントロール支援しレファレンスする表示プロパティを持っている。例示的なプロパティを図１３に示す。
【００６６】
タイトルプロパティは、オプショナルなプロパティであって、これを使用して、表示される名前を特定レイアウトの一部として関連付ける。モデルプロパティを使用して、コンポーネントに割り当てられた領域を細分化するかどうか決める。例示的なタイプのモデルパラメタは、次のものを含んでいる。
【００６７】
FULL： コンポーネントはパネル全体を取り上げる。
【００６８】
HHALF（水平の半分）：パネルは、二つのパネルに水平に分割される。
【００６９】
VHALF（垂直の半分）：パネルは、二つのパネルに垂直に分割される。
【００７０】
HTHIRD（水平の第三）：パネルは、三つのパネルに水平に分割される。
【００７１】
VTHIRD（垂直の第三）：パネルは、三つのパネルに垂直に分割される。
【００７２】
しかし、評価されるように、追加の分割は可能で、本発明の範囲内に包含される。
【００７３】
ロケーションプロパティは、方向座標、例えば、北、南、東及び西を含むことができる。これらは、どのパネルがプロパティ内で引用されるか示す。
【００７４】
図１６A-９Dで示すように、様々なパネル（これらはサブパネルを取り入れてもよい）が、様々な機能のために指定され得る。FULLモデルは画像表示のために使用する。水平二分割モデルは、２枚の比較画像を表示するために使用する。垂直三分割モデルは、検査リスト及び２枚の画像を表示するために使用する。
【００７５】
しかし、４枚の画像が図１６Dで示すスクリーン上に表示されることになっていた場合、その機能を直接提供するには、上記のどのコンポーネントも使用できない。従って、コンポーネントは、希望する振る舞いを模擬するために階層的に使用される。例えば、水平二分割モデルの各パネルが、垂直二分割モデルを含んでいれば、希望する四分割ができる。図１６Dの４パネル表示を達成する例示的なXMLベースの記述を図１４に示す。その後、そのようなレイアウトは、レイアウトのライブラリに保存され、後日再利用できる。
【００７６】
新しいレイアウトをすべて手入力により生成するよりむしろ、図１５に示すようなレイアウトエディターを利用したほうが好ましい。レイアウトエディターは、コンポーネント情報を使用する（例えば、ローカルのデータソース中に保存されている）。むしろ、レイアウトを記述するコンポーネント情報は、上述のXML構造で保存される。パネルは、パネルをコンポーネントとして含むことができるので、レイアウトはかなり速く生成できる。レイアウト（手入力又はレイアウトエディターによって生成された）を記述する例示的な文法を図１６で示す。そのような文法は、反復又はオプショナルな要素も含んで、レイアウトの要素及び要素が現れる順番を記述する。
【００７７】
上記は、図４で示すアプレットを使用する実施に注目したが、アプレットに基づかない他の実施技術も可能であり、確かに望ましい。アプレットを利用することによる一つの欠点は、アプレットが他のソフトウェアモジュールと表示画面を共有できない点である（例えば、ActiveX Controls、他のアプレット）。この制約は、第三者ソフトウェアを単一表示環境に統合することに反する。
【００７８】
アプレットに基づかない実施手法の第一の代替法は、ネイティブウィンドウアプリケーションを含んでいる。ソフトウェアの基本構造は同じである。しかし、コンテナが、アプレットからアプリケーションに変わる。アプレットに基づかない実施手法の第二の代替法は、図１７で示すように薄い依頼者を含んでいる。この代替法について以下詳述する。このような手法はservlets、DHTML、CSS及びCOMを利用する。
【００７９】
そのような実施は両方とも、第三者ソフトウェアを含むアプリケーションが、変化できる共通のコンテキスト（例えば、アクティブな患者又は訪問に関する情報）を共有することを可能にするために拡張される。そのような共用メッセージを明らかに処理するように書かれたアプリケーションは、以下「コンテキストを知る」アプリケーションという。しかし、統合される共用は、入力装置（例えば、キーボード及びマウス）以外のソースからのイベント又は通信を予期するように書かれなかったアプリケーションによって、妨害される。そのようなアプリケーションは、以下「コンテキストを知らない」アプリケーションという。そのようなコンテキストを知らないアプリケーションについては、共用は、コンテキスト又は表示マネージャ（CDM）を利用することにより達成できる。CDMは、コンテキストを知らないアプリケーションを終了し、適切なパラメータでそれらを再開する。上述の様に、コンテキストを知るアプリケーションに使用できる一つのメッセージ基準は、上述のようにCCOWである。またツール（例えば、Sentillionから）は、そのようなCCOWベースのアプリケーションの生成を容易にする。Sentillion開発パッケージは、次のものを含んでいる。
【００８０】
・コンテキスト参加者：アプリケーション内に埋込まれ得るすべてのDLLであって、それはCCOW基準に定義されたほとんどのコンテキスト参加者アプリケーションの振る舞いを実施する。
【００８１】
コンテキスト管理者：・コンテキスト管理者の開発専用版。コンテキスト管理者は、臨床アプリケーションを共通の臨床コンテキストのまわりで同期させることができる。コンテキスト管理者は、サーバープロセスとして走り、CCOWメッセージのブローカーの役割をする。ここでは、臨床コンテキストという。
【００８２】
図１７は、薄い依頼者アーキテクチャを使用する概念的モデルを示す。この例は、サービスを依頼者（例えば、ブラウザーを依頼者インターフェースとして使用）と少なくとも一つのサーバーと間で、サービスを分散する。第一の実施例では、一連のHTMLページが使用される。これは、ユーザを確認し患者を決定するために、サーバー（例えば、ログインServletを使用）と対話するページの第１組を含んでいる。ページの第２組は、複数のフレーム（例えば、三つのフレーム）を含んでいる。本実施形態によって生成された例示的なページは、図５に関して上述した。各々のフレームは、サーバーと対話する（例えばservletsを使用）。そのような環境では、コンテキスト情報は、依頼者内に保たれ、メツセージングプロトコルに基づく（例えば、CCOW）。依頼者コンテキストは、依頼者上でコンテキストサーバー内に維持される。また、コンポーネントは、依頼者コンテキストと直接対話する。
【００８３】
むしろ、薄い依頼者は、２段階初期化プロセスで構築される。初期化の第１段階は、DSUIで使用されるべきコンポーネントのレイアウト（例えば、HTMLページを使用）を作る。そして第２段階で、依頼者はそれのコンポーネントをアクチベートする。操作中に、ユーザは、コントロールコンポーネントの各々と対話できる（例えば、図５のタブバーからタブを選ぶことによって）。これによって、表示されている情報のページを変える。ユーザは、直接コンポーネントと対話もできる。これらのコンポーネントは、コンテキスト管理者か又はコンテキストブジェクトと直接通信する。
【００８４】
図１８は、コンポーネントページの構造のシーケンス図を示す。ほとんどの活動は、サーバー上で起こる。依頼者インターフェースは、ページの最初の作成においてアクティブである必要がある依頼者上のただ一つのソフトウェアコンポーネントである。依頼者インターフェースは、ログイン情報（例えば、（１）確認コード又は（２）ユーザid及びパスワード）をユーザから要求する。サーバーログイン（例えば、servletを使用する）は、ユーザを確認し、患者選択リスト及び表示レイアウト を返す（それは、サーバー上の構造化表示リストファイル（例えば、XMLファイル）を参照する）。ユーザは患者を選ぶ。そして、ActivePatientレファレンス及び表示レイアウトが、サーバーへ送られる（例えば、フレームServlet）。サーバーは、Active Patientレファレンスを使用し患者情報を患者記述言語で作る。その後、サーバーは、表示レイアウト及びActivePatientに一致するページレイアウトコントロールを生成する（例えば、１組のフレーム）。そして、ページの骨組みを依頼者インターフェースに返す。ページの骨組みのページレイアウトコントロールは、必要なパラメータ情報と共に、ページレイアウトコントロールエリアを埋めるservletsへのレファレンスを含んでいる。
【００８５】
図１８の例示的な実施例において、三つのフレーム（つまり、セレクタパネルフレーム、コンポーネントパネルフレーム及びデモパネルフレーム）は、ページレイアウトコントロールとして使用される。セレクタパネルフレームは、表示レイアウトパラメータでセレクタパネルServletを参照することを含んでいる。セレクタパネルServletは、インターフェースの一番上のタブバーを生成するコントロールレイアウト（ラベルされたセレクタパネルHTML）を送り返す。むしろ、タブバーはDHTMLで実施される。それゆえタブバーの視覚的変化はすべて依頼者上で起きる（例えば、タブは、カーソルがタブの上を動くと色が変わる）。
【００８６】
コンポーネントパネルフレームは、コンポーネントパネルServletへのレファレンスを含んでいる。依頼者インターフェースは、ActivePatient及び表示レイアウト情報でコンポーネントパネルServletレファレンスをアクチベートする。コンポーネントパネル は、更にその表示領域を細分して、指定レイアウトに一致させる。例えば、垂直若しくは水平の二分割、又は、垂直若しくは水平の三分割等である。その後、コンポーネントパネルServletは、十分に資格のあるレファレンスをコンポーネント（例えば、ActiveXコンポーネント）へ、それが生成した各フレーム中で挿入する。このコンポーネントパネルHTMLとラベルされたコントロールレイアウトは、依頼者インターフェースへ返され表示される。
【００８７】
デモパネルフレームは、デモパネルServletへのレファレンスを含んでいる。依頼者インターフェースは、ActivePatientパラメータを備えたデモパネルServletレファレンスをアクチベートする。デモパネルServletは、患者記述言語構造から患者人口動態表示を生成する。
【００８８】
三つのservletsは、別々に処理し、表示ページ（例えば、HTML）を出力として生産する。出力である表示ページを変更することにより薄い依頼者の外観を変更することは、非常に簡単である。例えば、タブパネルの最下段への移動、フォントと背景の色の容易な変更、フレームとフォントサイズの修正が、単にスタイルシートを変更することにより可能である。
【００８９】
図１９は、アクチベーション段階の第２部分を示すシーケンス図である。この段階では、依頼者インターフェースが、それらのページレイアウトレファレンス中で指定されるパラメータでコンポーネントをアクチベートする。その後、コンテキストアウエアコンポーネントは、共通のコンテキストを連結する。これによって、コンポーネントは、後のコンテキスト最新版メッセージを受け取り、現在のコンテキストを要求できる。コンテキストは、一連の名前のペアとして返される。
【００９０】
図５のユーザインターフェースに戻ると、ユーザは、例えば、タブバーからタブを選ぶことによって、表示ページを変更できる。又はコンポーネントパネルフレームのコンポーネントエリアフレームの一つで表示されているアプリケーションと直接対話する。図２０及び１７は、変更及び対話で使用されるステップのシーケンスをそれぞれ示す。
【００９１】
本発明の一実施例では、セレクタパネルServlet及びセレクタパネルフレームが、CIMR表示でタブバーの最初の表示を生成する。そのような実施例では、フレームがダイナミックコントロール（例えば、DHTML）を含んでいる。そしてすべてのカーソル移動及び表示最新版がスクリプト（例えば、Java（登録商標）ScriptベースDHTML）を通って表示内に生じる。一実施例では、タブの各々が、「ボタンを提出する」であり、ユーザによって選択されたとき、メッセージをServletに送信する。初期化では、セレクタパネルServletが、表示レイアウトのどのページが各タブに対応するか決める。表示レイアウト ページの識別は、タブ表示に関連する「ボタンを提出する」に対応するダイナミックなコントロールレファレンスへ差し込まれる。従って、ダイナミックコントロールは、表示の変更を取扱う。例えば、カーソルがタブの上を動くとタブが強調表示される。選択されたタブが他のタブの前に表示される。そしてセレクタパネル表示は、コンポーネントパネルServletに直接対応する。
【００９２】
依頼者インターフェースは、「ボタンを提出する」レファレンス内に含まれている情報で、コンポーネントパネルServletをアクチベートする。コントロールレイアウトは初期化で行ったように、その表示エリアを細分しアクティブなページに対応する（例えば、垂直又は水平に二分割、垂直又は水平に三分割）。その後、コンポーネントパネルServletは、それが生成したコントロールの各々のコンポーネントへ、十分に資格のあるレファレンスを挿入する。このコントロールレイアウトは、依頼者インターフェースに返され、例えば、HTMLページとして表示される。
【００９３】
一旦管理レイアウトがブラウザーに返されると、依頼者インターフェースは、図１９に記述されるのと同じ方法で、関連コンポーネントをアクチベートする。コンポーネントの各々はアクティブなコンテキストを連結し、アクティブなコンテキストを臨床コンテキストブジェクトから得る。
【００９４】
第２タイプのユーザ対話は、コンポーネントと直接対話するユーザを含んでいる。ユーザではなくコンポーネントが、共有環境と対話する。これは、コンテキスト情報をコンテキスト管理者又はコンテキストブジェクトから送受信することにより行う。一実施例では、コンテキスト変更対話が、サーバーサイドと通信せずに完全に依頼者上で生じる。他の実施例では、コンテキスト交換は、サーバーへの通信で生じる。例えば、いつコンポーネントが対話されたか記録する。
【００９５】
図２１は、コンテキスト管理者/オブジェクトを使用して成功したコンテキスト変更のシーケンス図を示す。ユーザがコンポーネント中の新しいコンテキスト変数を選択すると、シーケンスが始まる。この場合、コンテキスト変数は訪問である。その後、コンテキストアウエアコンポーネントはプロトコルを始めるが、これはコンテキストを同時に変更できるアプリケーションを一つに限定し、変更が一つも失われないことを保証するためである。コンテキストアウエアコンポーネントは、StartChangesメッセージをコンテキスト管理者/オブジェクトに送信する。これによって、他のアプリケーションをロックしコンテキスト変更を始めないようにして、開始アプリケーションにブランクのコンテキストエリアを与える。その後、そのアプリケーションは、新しいコンテキスト変数を設定する一連のメッセージを送信し、最後にEndChangesメッセージを送信する。EndChangesメッセージが受取られると、コンテキスト管理者/オブジェクトは、メッセージ変更の他の要請を自由に受け入れることができる。その後、コンテキスト管理者/オブジェクトは、コンテキストのメンバーである（つまり、コンテキストに加わった）他のすべてのアプリケーションにメッセージを送信し、新しいコンテキストがペンディングであると伝える。図２１の例示的な実施例では、アプリケーションが、すべて新しいコンテキストを受理する。もっとも、他の応答も可能である。アプリケーションの全部が新しいコンテキストを受理する場合、コンテキスト管理者/オブジェクトは、メッセージを開始コンポーネントに送り、アプリケーションがすべて受理したことを伝える。開始コンポーネントは、メッセージを臨床コンテキストに送信する。これは現在のコンテキストを、受理されたコンテキストと取り替えるためである。臨床コンテキストは、コンテキストのすべてのメンバーに、新しいコンテキストは今アクティブであることを発信する。その後、アプリケーションは新しいコンテキストを要求し、必要な変更を加える。
【００９６】
すべてのコンポーネントが受理されるとは限らない。従って、他の応答も、以下のように、有効である。例示的な反応（「受理」でないもの）には、次のものが含まれる。
【００９７】
・条件付き受理：ユーザがタスクを終了しなければ、タスクの途中でワークが失われる。変更が公表されると、タスクを終了し、コンテキストデータ変更を受理し、それに従って内部状態を変更する。そのあと変更が公表されると、アプリケーションは、その内部状態の変更を、ある程度の時間まで延期できる。例えば、それがユーザ入力のためのフォーカスを回復するとき等である。しかし、それは、新しいコンテキストと同期していないことを示すビジュアルキューを出さなければならない。例えば、それはデータ表示を消すか、又はそれ自体を最小限にする。
【００９８】
・終了：アプリケーションが、最初に臨床コンテキストに通知せずに終了した。これはコンテキスト変更に影響を与えない。アプリケーションはコンテキストから取り除かれる。
【００９９】
・ビジー：コンテキスト管理者は、アプリケーションがまだ実行中であるが、答えられないことを決めた場合である。例えば、アプリケーションはシングルスレッドであり、モード対話は開放されている。アプリケーションが使用中の場合、開始コンポーネントは、使用中のアプリケーションすべての簡潔であるが有益な記述（名前を含んで）を与えられる。この情報は、これらのアプリケーションの代わりに臨床コンテキストによって提供される。なぜなら、これらのアプリケーションは、そうすることができないからである。開始アプリケーションは、ユーザへの通報メッセージを表示するように選ぶことができる。
【０１００】
情報損失を回避するために、コンテキストチェンジャーは、何か変更を加えるためにトークンを利用する。変更を加えているコンテキスト参加者は、ビジーの参加者を取扱うことができなければならない。アプリケーションは、コンテキスト変更を進めるべきか決定するコード、又はコンテキスト変更を進めるかどうかユーザを催促するコードを含んでいなければならない。概念的に、システム決定にユーザを関与させないことが望ましい。例えば、表示プログラムがビジーのとき、アクティブな訪問の変更を希望するかどうか疑問である。しかし自動的に決定するコードは、実際的ではない。
【０１０１】
以上述べた構成によれば、異なるシステム間での情報のやり取り、異なるシステムに係る複数情報の一元的な取り扱いを可能とする医療情報システムを実現することができる。
【０１０２】
以上、本発明を実施形態に基づき説明したが、本発明の思想の範疇において、当業者であれば、各種の変更例及び修正例に想到し得るものであり、それら変形例及び修正例についても本発明の範囲に属するものと了解される。
【０１０３】
また、各実施形態は可能な限り適宜組み合わせて実施してもよく、その場合組合わせた効果が得られる。さらに、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果の欄で述べられている効果の少なくとも１つが得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【産業上の利用可能性】
【０１０４】
以上本発明によれば、異なるシステム間での情報のやり取り、異なるシステムに係る複数情報の一元的な取り扱いを可能とする医療情報システムを実現できる。
【図面の簡単な説明】
【０１０５】
【図１】図１は、共通の情報保存システムを共有する、コンピュータのネットワークのブロック図である。
【図２】図２は、例えばウェブブラウザ又は他のGUIインターフェースを使用した場合の、人々と各エージェント、又は各エージェント間での情報フローを示すデータフローモデルである
【図３】図３は、サーバ２００内において、種々のロケーションから読み出されたデータが、いかに組み合わされ、要求されたデータとともに最終的に与えられるレイアウトを生成するかを示す概念図である。
【図４】図４は、本実施形態に係る表示を実行するための、例示的なアプレットベースの実施技法の、コンポーネント図である。
【図５】図５は、例示的な医療用アプリケーションのために生成された例示的なユーザインターフェースである。
【図６】図６は、図１のユーザ表示の一つとして使用されるコンピュータシステムの図解である。
【図７】図７は、様々な依頼者情報間の関係を表す例示的な患者記述文法である。
【図８】図８は、様々な依頼者情報間の関係を表す例示的な患者記述文法である。
【図９】図９は、システム内の様々なレイアウトコンポーネント間の関係を表すエンティティー関係図である。
【図１０】図１０は、図９のエンティティー関係図に適合するプロパティの例示的なセットである。
【図１１】図１１は、ハードウェア固有又はモダリティ固有のコンポーネントを、ハードウェア独立又はモダリティ独立のコンポーネントからイネーブルするインターフェースの分割のブロック図である。
【図１２】図１２は、情報をレイアウトするために使用する種々のパネル例を示した図である。
【図１３】図１３は、パネル上のレイアウトをコントロール支援しレファレンスする表示プロパティを示した図である。
【図１４】図１４は、個別の水平パネル及び垂直パネルから、４パネルウィンドウを形成するためのコンポーネントの、例示的なXMLベースの階層組合せである。図１３は、階層上のパネルを定義するための、文法の図式記述である。
【図１５】図１５は、パネルの階層を定義するための、例示的なレイアウトエディターである。
【図１６】図１６は、システム内の様々なレイアウトコンポーネント間の関係を表す例示的なコンポーネントレイアウト文法である。
【図１７】図１７は、アプレットを使用せずに、本実施形態に係るDSUIを実施するための、エンティティー関係図である。
【図１８】図１８は、本実施形態において、薄い依頼者実施の初期化を示すメッセージシーケンス図である。
【図１９】図１９は、コンポーネントのコンテキスト情報を得るための登録を示すメッセージシーケンス図である。
【図２０】図２０は、コンポーネントのインターフェースの構築を示すメッセージシーケンス図である。
【図２１】図２１は、コンテキスト情報を変更する過程を示すメッセージシーケンス図である。
【符号の説明】
【０１０６】
１００…コンピュータシステム
１００ａ．１００ｂ…端末
１０２…コンピュータハウジング
１０４…マザーボード
１０８…メモリ
１１０…表示カード
１１２…ハードディスク
１１４…フロッピー（登録商標）ディスクドライブ
１１８…コンパクトディスクリーダ
１１９…コンパクトディスク
１２０…モニター
２００…サーバ
２００ａ…確認エージェント
２００ｂ…表示エージェント
２００ｃ…統合エージェント
２１０…データベース
２１０…情報保存システム
２５０…タブ
２６０…パネル
２７０…情報状態バー
【技術分野】
【０００１】
本発明は、医療情報システムに関する。
【背景技術】
【０００２】
従来の医療情報システムでは、種々のプログラム表示コントロールシステムが、単一の表示/モニター（仮想又はリアル）上の若干のプログラム表示を調整するために使用されている。例えば、X Windows（登録商標）環境では、そのようなコントロールシステムは、ウィンドウマネージャーと呼ばれる。既知のウィンドウマネージャーの例としては、FVWM、FVWM９５、TWM/VTWM、MWM、CTWM、OLWM/OLVWM、wm２/wmx、AfterStep、AmiWM、Enlightment、WindowMaker、SCWM、IceWM、SawFish及びBlackboxが挙げられる。例えば、X Windows（登録商標）ウィンドウマネージャーの下で走らせるアプリケーション用の構成ファイルを使用すれば、ウィンドウ処理パラメータ（例えば、ウィンドウの場所及び色）をアプリケーションの起動時に設定できる。
【０００３】
X Windows（登録商標）では、様々な再使用可能なコンポーネントのライブラリが、GUI内の様々なコンポーネントの見た目と感触を標準化するために作成されている。そのようなライブラリには、OpenLook及びMotifが含まれ、様々な機能（例えば、ボタン及びメニュー）を持つ「ウィジェット」を処理する。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、医療産業の参加者のコンソーシアムは、結束してClinical Context Object Workgroup（CCOW）を組織した。これは、１９９８年の白書によれば、「ユースポイントで独立してオーサリングされた医療アプリケーション中の、共同的な対話を視覚的に統合化する規格を公表する」というものである。更に白書は、「バージョン１の規格（１９９９年４月に批准された）であるPatient Linkは、選択された患者のアプリケーションの同期化をサポートする」と述べている。アプリケーションのユーザが、選択される患者を変更すると、ワークステーション上の他のアプリケーションも追随して変更される。その共同によって、ユーザは、二つ以上のアプリケーションにおいてアクションを繰り返すという単調さから解放される。その後、バージョン１.１及び１.２が、２０００年の１月及び５月にそれぞれ批准されている。
【０００５】
一方、医療の現場では、RIS、HIS、PACS、電子カルテ等の種々の情報システムが導入されている。これらは、それぞれ異なるプロトコルを使用しており、異なるシステム間での情報のやり取り、異なるシステムに係る複数情報の一元的な取り扱いには、多くの制限がある。
【０００６】
また、医療情報システムは、診療科毎の医師、医療技師、薬剤師、医療事務員等の種々の専門分野に渡るユーザによって使用される。従って、例えばユーザに、異なるシステムに係る複数情報を一元的に提供する場合には、ユーザ毎にカスタマイズ可能な構成であることが好ましい。
【０００７】
本発明は、上記事情を鑑みてなされたもので、異なるシステム間での情報のやり取り、及び異なるシステムに係る複数情報の一元的な取り扱いを可能とする医療情報システムを提供することを目的としている。
【課題を解決するための手段】
【０００８】
本発明は、上記目的を達成するため、次のような手段を講じている。
【０００９】
請求項１に記載の発明は、所定の属性毎に分類された医療情報を管理する前記各属性毎のコンポーネントによって共有される医療情報システムであって、ユーザからの所定の指示に応答して、ネットワーク上の少なくとも一つの端末に、複数の属性のそれぞれに対応する医療情報を統合的に表示するための統合画面のレイアウト情報を、操作者毎に管理する情報管理サーバと、入力される操作者情報に基づいて、前記情報管理サーバから所定の操作者に関するレイアウト情報を取得するレイアウト情報取得手段と、前記レイアウト情報の取得に連動して、前記統合画面に含める医療情報を、複数の前記コンポーネントから取得する医療情報取得手段と、前記レイアウト情報及び前記医療情報が取得されると、前記レイアウト情報を用いて前記医療情報を属性毎に分類した前記統合画面を生成し表示する表示手段と、を具備することを特徴とする医療情報システムである。
【発明の効果】
【００１０】
以上本発明によれば、異なるシステム間での情報のやり取り、及び異なるシステムに係る複数情報の一元的な取り扱いを可能とする医療情報システムを実現することができる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施形態を図面に従って説明する。なお、以下の説明において、略同一の機能及び構成を有する構成要素については、同一符号を付し、重複説明は必要な場合にのみ行う。
【００１２】
図１は、コンピュータ１００a、１００b、及び１００cのネットワークシステムの図解である。このネットワークには、情報化統合ツール及びインターフェースを介してアクセスでき、領域固有のインターフェースを、より迅速に一貫して実現できる。図１に示すシステムでは、各情報保存システム（PACS, HIS, RIS, 事務系の情報システム、薬局等の情報システム等）の各データベース２１０が共有される。各データベース２１０は、情報統合ツール及び／又はアプリケーションプログラムインタフェース（API）２００を介してアクセスされる。コンピュータ１００a、１００b及び１００cのDSUI（Domain-Specific-User-interface）として、それぞれ、a）整形外科表示、（b）集中治療室（ICU）表示及び（c）内科表示が例示してある。他のDSUIも、医療の領域及び他の領域の両方で可能である。各ＤＳＵＩでは、多くコンポーネントの表示が、（１）それらの独立のウィンドウ内で、又は（２）単一の統合ウィンドウの境界内で、同期を保つ必要がある。
【００１３】
複合システム、例えば、DSUIの役割をする患者情報システムでは、データは、多くのソースによって生成され、情報保存システム２１０内で様々なフォーマットで保存される。例えば、放射線データは、第１データベースに画像として保存され、他の患者情報（例えば、心電図トレース又は病理検査の結果）は、第２データベースに少なくとも１枚の画像及びテキストとして保存される。人口動態的な情報は、同じか又は異なるデータベースに保存され、他の患者情報と関連付けられる。
【００１４】
更に、各コンピュータ１００a、１００b及び１００cからサーバ２００を介した情報保存システム２１０のデータへの読み書きのアクセスは、少なくとも一つのコンポーネントによって可能であることが好ましい。データも、様々なフォーマット（例えば、DICOM、HL７）で伝達されることが好ましい。そこではコンポーネントによる使用を直接容易にする表現が最も好ましい。
【００１５】
例えば、XML（eXtensible markup language）は、データ表現と交換のために、簡単で頑健、かつ拡張可能な規格を提供する。XMLファイルは、それ自身の記述で分散されるので、統合された情報オブジェクトを生成することができる。従って、XMLにより構造化及び拡張が可能となり、妥当性確認が提供される。また、XMLによって、情報（例えば、医療のコンテキスト中では患者情報、又は犯罪のコンテキスト中では容疑者/犯人情報）を保存し識別する構造が得られる。情報は、ソフトウェア設計のオブジェクトと全く同様に、階層的に構造化される。新情報が入手可能になると、XML構造は拡張できる。XMLによれば、データ妥当性を確実にするメカニズムを提供し、XMLSQLのような照会言語ツールを使用して直接検索することができる。
【００１６】
図２は、例えばウェブブラウザ又は他のGUIインターフェースを使用した場合の、人々と各エージェント（確認エージェント２００ａ、表示エージェント２００ｂ、統合エージェント２００ｃ）、又は各エージェント間での情報フローを示すデータフローモデルである。なお、各エージェントは、場面に応じて意図を理解し、自立的な判断に基づいた処理を実行する機能であり、サーバ２００内で実行される。また、モデルは、いくつかのハイレベルのステップを含んでいる。これらのステップは、追加のサブステップかオプショナルなステップで実施され、（１）ログイン、（２）オブジェクト選択（例えば、患者選択）、（３）情報表示及び（４）ユーザ選考管理を含んでいる。
【００１７】
確認エージェント２００ａ、表示エージェント２００ｂ、統合エージェント２００ｃの機能は、例えば次のようである。
【００１８】
一般に、確認エージェント２００ａは、ユーザとデータとの間で門衛の役割をする。ユーザログインの情報は、任意の方式で確認できる。具体的方式としては、NT確認又はCORBA（登録商標）セキュリティサービス等が挙げられる。本実施形態では、ユーザは、確認プロセスによってカスタマイズ可能なDSUIの特徴に関するユーザ選考にアクセスできる。ここで重要な点は、一旦確認されると、ユーザは、システムによって認可されたアクセス権に相当するアクセスのタイプ及び有効範囲を与えられることである。例えば、一部のユーザは、読み出し専用アクセスを持ち、一方他のユーザは、読出書込みアクセスを持つ。更に、すべてのユーザが、システムのデータをすべて見ることができるとは限らない。例えば、病院経営者は、患者の訪問に関して請求情報を見ることができる一方、実際の放射線又は診断の情報は入手できない。従って、確認エージェント２００ａは、患者記録を選択する過程の間に連続のブローカーの役割をする。このような選択は、例えば、番号、場所等によって多くのメカニズムを通じて行われる。医療環境では、確認エージェント２００ａは、患者記録選択情報を統合エージェント２００ｃのもとへ送る。
【００１９】
統合エージェント２００ｃは、この選択情報に基づいて患者情報を表示のために構築し、かつユーザに返す。
【００２０】
表示エージェント２００ｂは、ユーザが表示インターフェースの一部をカストマイズしている場合には、表示される結果を適切にフォーマットするためにそのカスタマイゼーション情報にアクセスする。以下詳しく論じるように、標準インターフェースのユーザは、ユーザ選考に適するためにそのインターフェースを並べ替えてもよい。そのような並べ替えは、左から右でなく右から左へ読む言語を受け入れるようにインターフェースを国際化することを含んでいる。
【００２１】
図３は、サーバ２００内において、種々のロケーションから読み出されたデータが、いかに組み合わされ、要求されたデータとともに最終的に与えられるレイアウトを生成するかを示す。
【００２２】
一般に、統合エージェント２００ｃは、少なくとも一つのソースから情報患者記述データブロックを（好ましくはXMLを使用して）を構築するために、情報にアクセスする。各データソースにそれ自身のネーティブな基準でアクセスするためのインターフェースは、個別のモジュールとして、又は単一モジュール内で実施される。しかし、この好ましくは、そのような実施選択は、データの物理的な場所さえも隠すデータベース抽象化の後ろに隠される。実施例の一つとして、このエージェントは、既知の水平コンポーネントサービス（例えば、CORBA（登録商標）Medにより提供される患者同定サービス）を利用することができる。他の実施例としては、レポジトリーか又は他の集中型データストアが（データベースシステムかファイルベースシステムの片方か又は両方を含んで）利用される。
【００２３】
表示エージェント２００ｂは、例えば、XMLフォーマットにて、レイアウト構造のローカルストアにアクセスする。これらの構造は、後述するレイアウトエディターによって開発され（図１５参照）、表示制約に対応するデータベースの一部中で保管される。
【００２４】
最終的に、データ及びレイアウトは、表現コンポーネントによって結合される（つまり表現される）。このプロセスは、検索された患者情報をレイアウト情報と組み合わせる。表現コンポーネントは、完全な報告書をユーザへ転送する前に、表示される情報（例えば、患者記録）に関するコンテキスト情報を利用する。
【００２５】
実施形態としては、単一の統合化ウィンドウは、ウェブベースのアーキテクチャ内におけるコンポーネントベースのアプリケーションとして使用されることが好ましい。一般に、システム開発者は、コンポーネントのアーキテクチャによって、特定のオブジェクトのために設計される再使用可能なポータブルソフトウェアコンポーネントを生成できる。それらのコンポーネントは小さく、理解し維持することが容易であり、より大きなアプリケーション内の狭い機能を果たすことが好ましい。アプリケーション開発者は、ソフトウェアコンポーネント中の機能をカプセル化することによって、アプリケーションを迅速に構築するために使用できる共通のコンポーネントのライブラリを持つことができる。コンポーネントの機能を狭く保つことによって、個々のコンポーネントを多くのアプリケーションで使用（又は再使用）できる。また生じるコンポーネントウェアを迅速に開発し移植性を持たせることができる。
【００２６】
再使用を容易にするために、一連の標準インターフェース及びコンポーネントの技術が、好んで使用される。入手可能な多くの技術があり、それらは、システム実現詳細をソフトウェアの開発から抽象化する。システムは、ウェブパラダイムを使用して、プラットフォームO/S（例えば、Windows（登録商標）９X、Mac、UNIX（登録商標）、Windows（登録商標） NT）にかかわらず通信する。ウェブサーバーは、実施の詳細を依頼者から隠す。サーバーは、HTMLフォーマットで結果を表すために、共通のゲートウェイインターフェース（CGI）及びアクティブなサーバーページ（ASP）のような技術を利用できる。しかしながら、HTMLは、XMLのリッチネス及び自己記述性質を欠く。更に、サーバーサイドコンポーネント（例えば、CGIスクリプト及びプログラム）は、多くの場合機械に依存する。従って、CGIはプラットフォーム独立性に近づくことに役立つが、移植性の欠点を持っている。Java（登録商標）仮想マシン及びバイトコードの使用によって、多数のオペレーティングシステム及び種々の開発言語の環境中で、コンポーネントベースのソフトウェアシステムの移植性が増加する。下位レベルコンポーネントをシステムのビルディングブロックとして使用することに加えて、高位レベルコンポーネント（又はアプリケーション）は、下位レベルコンポーネントの表現及び統合を管理する。
【００２７】
また、クロスプラットフォーム移植性は、様々な補足的な技術、例えば、Java（登録商標）、Enterprise Java（登録商標） Beans（EJB）及びCORBA（登録商標）によって向上させられる。さらに、他のオブジェクトモデル（例えば、DCOM）も、コンポーネントの操作がコンテキストの枠組みの機能から分けられる限り、使用できる。それら技術の一部の関係は、図４で示される。CORBA（登録商標）は、異種のシステム中にコンポーネントを分散するメカニズムを提供する。更に、CORBA（登録商標）は、サービス（例えば、安全保護、命名、トランザクション処理）を提供し、コンポーネントの実施詳細からアプリケーションを更に分離する。EJBは、ウェブオペレーティングシステムの役割をするコンテナの提供により、CORBA （登録商標）より更に一歩先を行く。コンテナは、アプリケーションに抽象の追加層を提供して、実施詳細を維持する。
【００２８】
上述のコンポーネント技術を使用することによって、アプレットの役割をする様々なDSUIを生成できる。更に、図１７等を利用して後述するように、非アプレットベースの技術が可能である。
【００２９】
図５は、このようなDSUIの一例として、肺専門医インターフェースを示している。このインタフェースによって、患者のテキスト及びグラフィックの情報が調整される。図５に示すように、DSUIは、様々な表示コントロールを提供する。例えば、六つのタブ２５０、六つのパネル２６０及び情報状態バー２７０である。六つのタブ２５０の各々は、ページを選ぶことに相当し、あたかも箱からタブのついた索引カードを選ぶことに酷似している。六つのパネル２６０の各々は、状態バー２７０に含まれる情報と同期を保つ。その逆もまた真である。
【００３０】
従って、肺専門医インターフェースのユーザが、一つの表示コントロールを使用して、異なるユーザに入れ替わった場合を想定する。この入れ替わりのための操作は、訪問リストから新しい訪問を選ぶこと等の選択、例えばテキストリスト、プルダウンボックス、スクロールリスト及び１組のラジオボタンのうちいずれかとして実施される。この場合、残りの表示コントロールは、全てユーザの入れ替わりに従って変化するように、例えば、下記のメッセージングを使用してコントロールされる。
【００３１】
図６は、調整画像及びデータ表示を提供するコンピュータシステム１００を示した図であり、図１の各端末１００ａ、１００ｂ、１００ｃの具体例である。コンピュータ１００では、本実施形態に係るシステムに従って、上述した表示系が提供される。
【００３２】
コンピュータハウジング１０２は、マザーボード１０４を収容する。マザーボードは、CPU １０６、メモリ１０８（例えば、DRAM、ROM、EPROM、EEPROM、SDRAM、SDRAM及びフラッシュRAM）及び他のオプショナルな専用論理デバイス（例えば、ASIC）又は構成可能な論理機構（例えば、GAL及び再プログラム可能なFPGA）を含んでいる。
【００３３】
コンピュータ１００は、更に複数の入力装置（例えば、キーボード１２２及びマウス１２４）及びモニター１２０をコントロールする表示カード１１０を含んでいる。更に、コンピュータシステム１００は、フロッピー（登録商標）ディスクドライブ１１４、取外し可能な媒体デバイス（例えば、コンパクトディスク１１９、テープ及び取外し可能な光磁気媒体（図示せず）、ハードディスク１１２、又は適切なデバイスバスの使用により接続された他の固定の高密度媒体ドライブ（例えば、SCSIバス、拡張IDEバス、又はUltra DMAバス）も含んでいる。
【００３４】
更に、コンピュータ１００は、同じデバイスバス又は別のデバイスバスに接続され、コンパクトディスクリーダ１１８、コンパクトディスクリーダ/ライタユニット（図示せず）又はコンパクトディスクジュークボックス（図示せず）を追加して含んでいる。コンパクトディスク１１９は、CDキャディーで示されるが、コンパクトディスク１１９は、キャディーを要求しないCD ROMドライブへ直接挿入できる。更に、プリンタ（図示せず）は、調整表示からの報告書の印字されたリストも提供する。
【００３５】
上述のように、コンピュータシステム１００は、少なくとも一つのコンピュータ読み取り可能な媒体を含んでいる。コンピュータ読み取り可能な媒体の例は、コンパクトディスク１１９、ハードディスク１１２、フロッピー（登録商標）ディスク、テープ、光磁気ディスク、PROM（EPROM、EEPROM、フラッシュEPROM）、DRAM、SDRAM、SDRAMなどである。本実施形態に係るソフトウェアは、コンピュータ読み取り可能な媒体の一つ又はそれらの組合せ上に保存され、コンピュータ１００の両方のハードウェアをコントロールし、コンピュータ１００が人間のユーザと対話することを可能にする。このようなソフトウェアは、デバイスドライバー、オペレーティングシステム及びユーザアプリケーション、例えば開発ツールを含んでいるが、これらに限らない。このようなコンピュータ読み取り可能な媒体は、表示コントロール又はコンポーネントの調整コントロールを提供する本発明のコンピュータプログラム製品をも含んでいる。
【００３６】
ここに記述されるように、本実施形態に係るコンピュータコードデバイスは、解釈され実行可能なコードメカニズムのいずれでもあり得る。そして、それはスクリプト（CGIスクリプトを含む）、インタープリタ、ダイナミックリンクライブラリ、Java（登録商標）class、Java （登録商標）beans、Active X controls、CCOW準拠コントロール及び完全な実行可能プログラムを含んでいる。しかしながら、これらに限定する趣旨ではない。また、コンピュータコードデバイスは、コンピュータネットワークアダプタからダイナミックにダウンロードでき、コンピュータネットワークアダプタは、コンピュータ読み取り可能な媒体の等価物として働いている。更に、単一のコンピュータコードデバイスによって実施されるコンポーネントの数、又は単一のコンポーネントを構築するために要求されるコンピュータコードデバイスの数は、コンポーネントによって異なることがある。以下、コンポーネントについて説明する。
【００３７】
コンポーネントの階層セットを提供することによって、コンポーネントは機能によって分類できる。例示的な分業は、（１）既存の病院システムにアクセスし情報を保存するコンポーネント、（２）XMLメタ構造を使用して情報を構成するコンポーネント及び（３）データ表現（例えば、グラフ作成コンポーネント、画像を様々なフォーマット、すなわちTIFF、GIF、JPEG、ビットマップ等で表示する画像コンポーネント）を含んでいる。
【００３８】
このようなコンポーネントのセットによって、更に安全保護を別々に扱うことができる。少なくとも二つの汎用のアプローチが、安全保護にとって可能である。第一に、コンポーネントそれ自体の中で実施された安全保護特長が使用できる。基本的に、これは、安全保護がシステム全体の問題ではなく、むしろシステムによって利用されたコンポーネントの問題であることを意味する。コンポーネントの安全保護能力が進化するとともに、システムは、これらのコンポーネントを自動的に取り入れる。
【００３９】
第二のアプローチは、「安全保護コンポーネント」を使用するか、又は、CORBA（登録商標）によって提供される水平サービスのうちの一つを使用する。そのようなコンポーネントは、ユーザアクセスを確認する責任を持ち、安全保護方針が強化されることを保証するためにコンポーネントによる通信を仲裁することができる。このアプローチは、より大きな安全保護レベルを提供するが、他のコンポーネントが更に協力する必要がある。そのような安全保護コンポーネント及びCORBA（登録商標）サービスの使用は、標準化される必要があり、それによって第三者コンポーネントを利用する能力を減らす必要がある。
【００４０】
階層コンポーネントの組織は、更に専門化アクセス及び表示プログラミングを局所化する。アクセス規格が整備されていない場合、独占情報へのアクセスは、扱いやすい場所で分離することができる。XMLは、表示のための情報を表現するメカニズム（例えば、CSS、XSLT、XSL）を提供する。それらのメカニズムによって、ユーザ及びタスクに依存して、同じ情報を異なる表示特性に関連付けることができる。例えば、患者は年齢によって、ある特性又は疾患に関しては低リスクグループに分類される。しかし別の特性又は疾患に関しては高リスクグループに分類される。
【００４１】
XMLベースの文書オブジェクトモデル中の名前付き要素タグを介して、データにアクセスすることによって、コンポーネントは、間接指定の追加レベルで構成され得る。必要な情報を含んでいるタグの名前（つまりプログラム変数）は、前もって知られている。これによって、一般化ラッパーコンポーネントを実施できる。それを使用して、既存のソフトウェア（例えば、Algotec MediSurf Viewer）は、患者コンテキストコンポーネントに統合され得る。
【００４２】
例えば、MediSurfをhttp：//medisurf/start? study_display（１.２２３４.４４３４.３４５５.３４５６５４）のようなStudyInstanceUIDで起動する必要がある場合に、外部仕様（layoutXMLレイアウト内の）が、StudyInstanceUIDのコンテンツを名前付きのアプリケーションに送信するために生成される。同じ方法を使用すると、ソフトウェアへのパラメータが患者記述言語（例えば、XMLベースのDTD）に含まれている限り、他のソフトウェアはラップされ得る。間接指定のこの追加レベルのゆえに、ソフトウェアは、タグ付きパラメータのすべてのインスタンスをソフトウェアコンポーネントに送信できる。コンポーネントは、タグ付き要素の最新のもの、２番目に最新のもの、又は他のインスタンスを外部コンポーネントへ送信するようにプログラムされ得る。
【００４３】
本実施形態に係るシステム内のコンポーネントは、「振る舞いが良い」と見なされる。従って、そのようなコンポーネントは、データの完全性（例えば、同時性管理）を強化し、確認（例えば、患者及び検査情報のためのユーザレベル確認）を利用し、相違するコンポーネントタイプ（CORBA（登録商標）、EJB及びDCOM）と協力する。振る舞いが良いと考えられないコンポーネント、又はシステム想定を強化しないと分かるコンポーネントについては、それらのコンポーネントは、データ変質などを防ぐために他のコンポーネントから分離される。
【００４４】
例えば図５に示した画面例にあるように、領域特定情報（例えば、患者情報）、レイアウト情報及びコンテキスト情報は、例示的なDSUIを形成するために結合される。
【００４５】
図７、図５は、患者記述言語用の例示的な構造を示している。各図に示すように、患者情報を保持するために、XM及びDOMを使用することによって、名前付きタグでコンポーネントと関連付けることができる。
【００４６】
図５のDSUIを使用して、タブ２５０は、六つの異なる情報ビューを表す：（１）肺専門医：要約情報、（２）薬品：患者の薬物適用のリスティング、（３）気管支鏡検査：気管支の可視光線画像、（４）CR：CR画像のビュー、（５）CT： CT画像のビュー、及び（６）心電図： スキャンされた心電図画像のビューである。むしろ、それらのタブの各々は、少なくとも部分的に構成され得る。例えば、名前タブ、ビューの順序及びビューのコンテンツを構成することができる。
【００４７】
エンドユーザが情報と対話するにつれて、DSUIのコンテキストは、タブ付きページ全部の情報の一貫したビューを提供する。医療環境では、コンテキストは、変数、例えば、Active Visit, Active CRStudy, Active Seriesなどを含んでいる。コンポーネントは、コンテキスト変数を追跡するために（又はそれと一貫性を保つために）構成され得る。図５の例を利用して、１/１１/９９訪問に関連する情報が表示される。レイアウトの第１ビュー、つまり肺専門医ビューは、訪問リストコンポーネント、訪問要約コンポーネント、検査リストコンポーネント及び二つの画像表示コンポーネントを含んでいる。それらのコンポーネントの各々は、１/１１/９９訪問に関連する情報を表示する。更に、患者に関連する状態バーの情報を表示する人口動態コンポーネントがある。そのコンポーネントは、訪問とともに変化しない情報を含んでいる。追加のビュー（示されていない）、例えば、CRビューも１/１１/９９訪問に関連する情報を含んでいる。
【００４８】
ユーザが肺専門医ビューの訪問リストコンポーネントから、そのあと１０/３/９９訪問を選ぶ場合、そのビューは変わり、訪問に関するコンポーネントも変わる（例えば、訪問要約コンポーネントは、１０/３/９９訪問に関する情報を提供する。検査リストコンポーネントは、１０/３/９９訪問の検査リストを表示する。表示されている検査と一致するように画像が変わる。アクティブな訪問に関係する他のビューも変わる）。更に、他のページ上のビューも同様に更新される。例えば、CRビュー（第４のタブ）は、変更後の１０/３/９９訪問に関係する情報を含んでいる肺専門医ビュー（第１のタブ）と一致している。しかし、上述のように、いくつかの表示要素は、情報を変更しない。例えば、人口動態情報は、同一人が何回訪問しても変化しない。また、図示の例では変化するべきでない。
【００４９】
コンテキスト変数に従うアクティブコンポーネントを生成する機能が、構成され得る。コンポーネントは、コンテキスト変数を追跡するか又は静止ビューへ設定された状態を保つように構成され得る。例えば、上記のCR検査ビューアーは、アクティブな訪問を追跡する。同じコンポーネントが、最新のCR検査だけを表示するように構成され得る。従って、ユーザがアクティブな訪問を変更するとき、最新のCR検査が常に表示される。
【００５０】
むしろ、コンテキスト変数の構造も、階層構造に保存される（例えば、患者記述言語に似ている構造）。コンテキスト構造は、患者の木構造の各枝に対して変数を含んでいる。これをすることによって、患者情報のアクティブな部分が追跡され得る。
【００５１】
図９の例示的なエンティティー関係図で示すように、コンポーネントは、プロパティの形で保存された三つのタイプの情報を含んでいるビュー、状態及び実施のプロパティである。一般に、このコンポーネントのモデルは、コンポーネントから独立してデータを保存する実施（上記のように）又はコンポーネントと一緒にデータを保存する実施に、例えば、Java （登録商標）Beanの構成をBean自体の中に保存することによって適用され得る。
【００５２】
ビュープロパティは、コンポーネントがどのように表示されるべきか示唆する。しかし、layoutController、すなわち患者コンテキストコンポーネント中のドライビングコンポーネントは、コンポーネントがその最終表現でどのように見えるかコントロールする。図９で示すように、例示的なプロパティは次のものを含んでいる。すなわち、その中でコンポーネントが表示されるべき最小の高さMinHeight及び幅MinWidth並びに最適の背景色BGColorである。
【００５３】
同様に、コンポーネントのStatusPropertiesは、コンポーネントがアプリケーションのコンテキスト中でどのように振る舞うべきか記述する。例示的なプロパティは、コンポーネントがどのように起動されるか指定する初期処理を参照する。状態変数は、患者記述言語の要素タグ（例えば、図７の中の訪問）に相当する。数値は、事前に定義した意味を含んでいる。例えば、０＝最新、１＝最新の一つ前、２＝最新の二つ前などである。他の状態プロパティは、ユーザが介入するときコンポーネントがどのように振る舞うか記述する。その振る舞いは、全体的なシステムの状態の変更、例えば、新しいアクティブな訪問をVisitListコンポーネントから選ぶことによる変更を含んでいる。
【００５４】
アクティブなプロパティは、ブール式である。すなわち、コンポーネントがアクティブな状態とともに変化するべきか、セッション期間を通じて初期設定の状態を保つべきかを記述する。例えば、「はい」の状態は、コンポーネントが他のコンポーネントの設定に追随するために、変化するべきことを示す。「いいえ」の状態は、コンポーネントが初期設定の状態を保つべきことを示す。
【００５５】
TagToFollowプロパティは、状態階層で最低のレベルタグを示し、それはコンポーネントの状態をモディファイするために使用されるべきである。例えば、CRImageViewerは、状態タグCRStudyを追跡する。異なるCRStudyをユーザが選択するとき（つまり、CRStudyの状態が変わるとき）は常に、CRImageViewerは、CRStudyの値を追跡するために変わる。
【００５６】
実施プロパティは、コンポーネントの実際の実施を記述する。それによって、システムは、実際の実行時間コンポーネントを適切なパラメータで起動するラッパーを生成できる。BuilderClassプロパティは、コンポーネントのタイプを記述する。上記にように、多数のタイプ（例えば、Java（登録商標）Classes）の実施技術が、本発明に従って使用され得る。パスプロパティは、実行されるソフトウェアの場所を記述する。パラメータプロパティは、StatusProperties. InitialSettings変数中で指定されないすべての追加始動パラメータ、例えば、ユーザ登録名及びパスワードを提供する。
【００５７】
他の構造又はフォーマットが、図９に関して上述のプロパティを記述するために使用できるが、実施例では、プロパティは、XMLベースの文法を使用して記述されている。図１０では、図９のビュープロパティ及び状況プロパティは、CR及び皮膚の検査に関する情報を表示する検査リストコンポーネントに対する例示的な値で指定される。コンポーネントの最小の高さ及び幅は、１８０及び３２０の画素点としてそれぞれ指定される。背景色は黒として指定される。訪問及び検査は両方とも最新の値（つまり、それぞれ最新の訪問及び検査）を利用する。更に、コンポーネントはアクティブであり、訪問変数に追随することにより他のコンポーネントの変化を追跡する。
【００５８】
最高水準の記述言語は、患者の識別情報を含んでいる。それによって、人口動態及び訪問情報が、そこから拡張され得る。患者記述言語は、「リアルワールド」のDICOMビューから本質的に得られる。それは患者情報を訪問に結び付ける。訪問を使用して、特に病院のセッティング中でケアエピソードを意味のある群にグループ分けする。外来患者か診療所のセッティング中で、より有用なグループ分けは、診断コード又は他の情報であって、患者情報をケアのエピソードへグループ分けするものである。例えば、それは脚の骨折に関する情報を一括して、その情報を心臓の状態に関する情報から論理的に分離する。
【００５９】
この情報は、別の規格のフォーマット、例えば、HL７ RIMモデルに保存され得る。しかし、この情報は、その構造がタスクをサポートする限り、データベースにおいて構造化されるのと同じフォーマットで構造化される必要はない。
【００６０】
アプリケーション内のコンテキスト変数は、患者の木構造の分岐点で維持される。木の枝が、各タイプの検査（例えば、CRStudy、DermStudy、CTStudy）に対して維持される場合、コンテキスト情報は、これらの変数に対して維持され得る。なぜなら、どの検査がどの時間にアクティブか、例えば、どんなグループ検査に訪問が対応するか、どんな薬物が利用され処方されたか、が知られているからである。
【００６１】
CRStudyは、CRモダリティ情報だけを含んでいる。それは、検査及び一つ以上のシリーズ要素に関する一般情報を含んでいる。実際の画像は、シリーズレベルに含まれている。
【００６２】
ECGStudy要素のフォーマットは、CRStudyに準じている。再び、最高水準は、検査に関する一般情報を含んでいる。そして一つ以上のシリーズ要素がある。画像は、シリーズレベルに含まれている。
【００６３】
一実施例では、再利用を更に容易にするために、モダリティ固有のコンポーネントは、モダリティ独立のコンポーネントから分離される。モダリティ固有のコンポーネントは、一般に、与えられたモダリティに固有の物理ハードウェアプロセスをコントロールするコンポーネントである。「最下部」インターフェースでは、これらのコンポーネントは、トランスデューサ又はデジタル入出力インターフェースをコントロールするが、これらは、放射線の発生、機械的動作又は他のハードウェア活動をコントロールするために必要である。「最上部」では、これらのコンポーネントは、モダリティに依存しない抽象の隣の層に共通のインターフェースを提供するように設計されるべきである。モダリティ独立のソフトウェアは、DICOM通信及びフォーマットソフトウェアコンポーネント、ファイル管理コンポーネント、システム管理及び保守ツール、DICOMモダリティワークリストコンポーネント、DICOM MPPSコンポーネントなどを含んでいる（図１１を参照）。
【００６４】
そのような実施によって、DSUIを汎用目的に定義できる。これは、個々のニーズにカストマイズされるモダリティ用のユーザインターフェースの「レイアウト」を通じて行われる（例えば、病院の現場又は個々の医療専門家（例えば、医師、看護婦及び医療管理者））。特注レイアウトの設計、作成及び修正は、エンドユーザが、レイアウトエディターツールを使用して行う。新しいレイアウト、又は管理/保守レイアウトは、標準ウェブ通信プロトコルを使用してダウンロードする。保守レイアウトは、エンドユーザレイアウトがアクセスできない特殊コンポーネントにアクセスする。
【００６５】
レイアウトの単一ページは、パネルの再帰的ネスティングを含んでいる階層構造によって記述される。これによって、レイアウトは、そのレイアウトに透明なサブレイアウトになる。「高位」レイアウト中でそのレイアウトに言及するだけでよい。各レベルでは、パネルは、レイアウトをコントロール支援しレファレンスする表示プロパティを持っている。例示的なプロパティを図１３に示す。
【００６６】
タイトルプロパティは、オプショナルなプロパティであって、これを使用して、表示される名前を特定レイアウトの一部として関連付ける。モデルプロパティを使用して、コンポーネントに割り当てられた領域を細分化するかどうか決める。例示的なタイプのモデルパラメタは、次のものを含んでいる。
【００６７】
FULL： コンポーネントはパネル全体を取り上げる。
【００６８】
HHALF（水平の半分）：パネルは、二つのパネルに水平に分割される。
【００６９】
VHALF（垂直の半分）：パネルは、二つのパネルに垂直に分割される。
【００７０】
HTHIRD（水平の第三）：パネルは、三つのパネルに水平に分割される。
【００７１】
VTHIRD（垂直の第三）：パネルは、三つのパネルに垂直に分割される。
【００７２】
しかし、評価されるように、追加の分割は可能で、本発明の範囲内に包含される。
【００７３】
ロケーションプロパティは、方向座標、例えば、北、南、東及び西を含むことができる。これらは、どのパネルがプロパティ内で引用されるか示す。
【００７４】
図１６A-９Dで示すように、様々なパネル（これらはサブパネルを取り入れてもよい）が、様々な機能のために指定され得る。FULLモデルは画像表示のために使用する。水平二分割モデルは、２枚の比較画像を表示するために使用する。垂直三分割モデルは、検査リスト及び２枚の画像を表示するために使用する。
【００７５】
しかし、４枚の画像が図１６Dで示すスクリーン上に表示されることになっていた場合、その機能を直接提供するには、上記のどのコンポーネントも使用できない。従って、コンポーネントは、希望する振る舞いを模擬するために階層的に使用される。例えば、水平二分割モデルの各パネルが、垂直二分割モデルを含んでいれば、希望する四分割ができる。図１６Dの４パネル表示を達成する例示的なXMLベースの記述を図１４に示す。その後、そのようなレイアウトは、レイアウトのライブラリに保存され、後日再利用できる。
【００７６】
新しいレイアウトをすべて手入力により生成するよりむしろ、図１５に示すようなレイアウトエディターを利用したほうが好ましい。レイアウトエディターは、コンポーネント情報を使用する（例えば、ローカルのデータソース中に保存されている）。むしろ、レイアウトを記述するコンポーネント情報は、上述のXML構造で保存される。パネルは、パネルをコンポーネントとして含むことができるので、レイアウトはかなり速く生成できる。レイアウト（手入力又はレイアウトエディターによって生成された）を記述する例示的な文法を図１６で示す。そのような文法は、反復又はオプショナルな要素も含んで、レイアウトの要素及び要素が現れる順番を記述する。
【００７７】
上記は、図４で示すアプレットを使用する実施に注目したが、アプレットに基づかない他の実施技術も可能であり、確かに望ましい。アプレットを利用することによる一つの欠点は、アプレットが他のソフトウェアモジュールと表示画面を共有できない点である（例えば、ActiveX Controls、他のアプレット）。この制約は、第三者ソフトウェアを単一表示環境に統合することに反する。
【００７８】
アプレットに基づかない実施手法の第一の代替法は、ネイティブウィンドウアプリケーションを含んでいる。ソフトウェアの基本構造は同じである。しかし、コンテナが、アプレットからアプリケーションに変わる。アプレットに基づかない実施手法の第二の代替法は、図１７で示すように薄い依頼者を含んでいる。この代替法について以下詳述する。このような手法はservlets、DHTML、CSS及びCOMを利用する。
【００７９】
そのような実施は両方とも、第三者ソフトウェアを含むアプリケーションが、変化できる共通のコンテキスト（例えば、アクティブな患者又は訪問に関する情報）を共有することを可能にするために拡張される。そのような共用メッセージを明らかに処理するように書かれたアプリケーションは、以下「コンテキストを知る」アプリケーションという。しかし、統合される共用は、入力装置（例えば、キーボード及びマウス）以外のソースからのイベント又は通信を予期するように書かれなかったアプリケーションによって、妨害される。そのようなアプリケーションは、以下「コンテキストを知らない」アプリケーションという。そのようなコンテキストを知らないアプリケーションについては、共用は、コンテキスト又は表示マネージャ（CDM）を利用することにより達成できる。CDMは、コンテキストを知らないアプリケーションを終了し、適切なパラメータでそれらを再開する。上述の様に、コンテキストを知るアプリケーションに使用できる一つのメッセージ基準は、上述のようにCCOWである。またツール（例えば、Sentillionから）は、そのようなCCOWベースのアプリケーションの生成を容易にする。Sentillion開発パッケージは、次のものを含んでいる。
【００８０】
・コンテキスト参加者：アプリケーション内に埋込まれ得るすべてのDLLであって、それはCCOW基準に定義されたほとんどのコンテキスト参加者アプリケーションの振る舞いを実施する。
【００８１】
コンテキスト管理者：・コンテキスト管理者の開発専用版。コンテキスト管理者は、臨床アプリケーションを共通の臨床コンテキストのまわりで同期させることができる。コンテキスト管理者は、サーバープロセスとして走り、CCOWメッセージのブローカーの役割をする。ここでは、臨床コンテキストという。
【００８２】
図１７は、薄い依頼者アーキテクチャを使用する概念的モデルを示す。この例は、サービスを依頼者（例えば、ブラウザーを依頼者インターフェースとして使用）と少なくとも一つのサーバーと間で、サービスを分散する。第一の実施例では、一連のHTMLページが使用される。これは、ユーザを確認し患者を決定するために、サーバー（例えば、ログインServletを使用）と対話するページの第１組を含んでいる。ページの第２組は、複数のフレーム（例えば、三つのフレーム）を含んでいる。本実施形態によって生成された例示的なページは、図５に関して上述した。各々のフレームは、サーバーと対話する（例えばservletsを使用）。そのような環境では、コンテキスト情報は、依頼者内に保たれ、メツセージングプロトコルに基づく（例えば、CCOW）。依頼者コンテキストは、依頼者上でコンテキストサーバー内に維持される。また、コンポーネントは、依頼者コンテキストと直接対話する。
【００８３】
むしろ、薄い依頼者は、２段階初期化プロセスで構築される。初期化の第１段階は、DSUIで使用されるべきコンポーネントのレイアウト（例えば、HTMLページを使用）を作る。そして第２段階で、依頼者はそれのコンポーネントをアクチベートする。操作中に、ユーザは、コントロールコンポーネントの各々と対話できる（例えば、図５のタブバーからタブを選ぶことによって）。これによって、表示されている情報のページを変える。ユーザは、直接コンポーネントと対話もできる。これらのコンポーネントは、コンテキスト管理者か又はコンテキストブジェクトと直接通信する。
【００８４】
図１８は、コンポーネントページの構造のシーケンス図を示す。ほとんどの活動は、サーバー上で起こる。依頼者インターフェースは、ページの最初の作成においてアクティブである必要がある依頼者上のただ一つのソフトウェアコンポーネントである。依頼者インターフェースは、ログイン情報（例えば、（１）確認コード又は（２）ユーザid及びパスワード）をユーザから要求する。サーバーログイン（例えば、servletを使用する）は、ユーザを確認し、患者選択リスト及び表示レイアウト を返す（それは、サーバー上の構造化表示リストファイル（例えば、XMLファイル）を参照する）。ユーザは患者を選ぶ。そして、ActivePatientレファレンス及び表示レイアウトが、サーバーへ送られる（例えば、フレームServlet）。サーバーは、Active Patientレファレンスを使用し患者情報を患者記述言語で作る。その後、サーバーは、表示レイアウト及びActivePatientに一致するページレイアウトコントロールを生成する（例えば、１組のフレーム）。そして、ページの骨組みを依頼者インターフェースに返す。ページの骨組みのページレイアウトコントロールは、必要なパラメータ情報と共に、ページレイアウトコントロールエリアを埋めるservletsへのレファレンスを含んでいる。
【００８５】
図１８の例示的な実施例において、三つのフレーム（つまり、セレクタパネルフレーム、コンポーネントパネルフレーム及びデモパネルフレーム）は、ページレイアウトコントロールとして使用される。セレクタパネルフレームは、表示レイアウトパラメータでセレクタパネルServletを参照することを含んでいる。セレクタパネルServletは、インターフェースの一番上のタブバーを生成するコントロールレイアウト（ラベルされたセレクタパネルHTML）を送り返す。むしろ、タブバーはDHTMLで実施される。それゆえタブバーの視覚的変化はすべて依頼者上で起きる（例えば、タブは、カーソルがタブの上を動くと色が変わる）。
【００８６】
コンポーネントパネルフレームは、コンポーネントパネルServletへのレファレンスを含んでいる。依頼者インターフェースは、ActivePatient及び表示レイアウト情報でコンポーネントパネルServletレファレンスをアクチベートする。コンポーネントパネル は、更にその表示領域を細分して、指定レイアウトに一致させる。例えば、垂直若しくは水平の二分割、又は、垂直若しくは水平の三分割等である。その後、コンポーネントパネルServletは、十分に資格のあるレファレンスをコンポーネント（例えば、ActiveXコンポーネント）へ、それが生成した各フレーム中で挿入する。このコンポーネントパネルHTMLとラベルされたコントロールレイアウトは、依頼者インターフェースへ返され表示される。
【００８７】
デモパネルフレームは、デモパネルServletへのレファレンスを含んでいる。依頼者インターフェースは、ActivePatientパラメータを備えたデモパネルServletレファレンスをアクチベートする。デモパネルServletは、患者記述言語構造から患者人口動態表示を生成する。
【００８８】
三つのservletsは、別々に処理し、表示ページ（例えば、HTML）を出力として生産する。出力である表示ページを変更することにより薄い依頼者の外観を変更することは、非常に簡単である。例えば、タブパネルの最下段への移動、フォントと背景の色の容易な変更、フレームとフォントサイズの修正が、単にスタイルシートを変更することにより可能である。
【００８９】
図１９は、アクチベーション段階の第２部分を示すシーケンス図である。この段階では、依頼者インターフェースが、それらのページレイアウトレファレンス中で指定されるパラメータでコンポーネントをアクチベートする。その後、コンテキストアウエアコンポーネントは、共通のコンテキストを連結する。これによって、コンポーネントは、後のコンテキスト最新版メッセージを受け取り、現在のコンテキストを要求できる。コンテキストは、一連の名前のペアとして返される。
【００９０】
図５のユーザインターフェースに戻ると、ユーザは、例えば、タブバーからタブを選ぶことによって、表示ページを変更できる。又はコンポーネントパネルフレームのコンポーネントエリアフレームの一つで表示されているアプリケーションと直接対話する。図２０及び１７は、変更及び対話で使用されるステップのシーケンスをそれぞれ示す。
【００９１】
本発明の一実施例では、セレクタパネルServlet及びセレクタパネルフレームが、CIMR表示でタブバーの最初の表示を生成する。そのような実施例では、フレームがダイナミックコントロール（例えば、DHTML）を含んでいる。そしてすべてのカーソル移動及び表示最新版がスクリプト（例えば、Java（登録商標）ScriptベースDHTML）を通って表示内に生じる。一実施例では、タブの各々が、「ボタンを提出する」であり、ユーザによって選択されたとき、メッセージをServletに送信する。初期化では、セレクタパネルServletが、表示レイアウトのどのページが各タブに対応するか決める。表示レイアウト ページの識別は、タブ表示に関連する「ボタンを提出する」に対応するダイナミックなコントロールレファレンスへ差し込まれる。従って、ダイナミックコントロールは、表示の変更を取扱う。例えば、カーソルがタブの上を動くとタブが強調表示される。選択されたタブが他のタブの前に表示される。そしてセレクタパネル表示は、コンポーネントパネルServletに直接対応する。
【００９２】
依頼者インターフェースは、「ボタンを提出する」レファレンス内に含まれている情報で、コンポーネントパネルServletをアクチベートする。コントロールレイアウトは初期化で行ったように、その表示エリアを細分しアクティブなページに対応する（例えば、垂直又は水平に二分割、垂直又は水平に三分割）。その後、コンポーネントパネルServletは、それが生成したコントロールの各々のコンポーネントへ、十分に資格のあるレファレンスを挿入する。このコントロールレイアウトは、依頼者インターフェースに返され、例えば、HTMLページとして表示される。
【００９３】
一旦管理レイアウトがブラウザーに返されると、依頼者インターフェースは、図１９に記述されるのと同じ方法で、関連コンポーネントをアクチベートする。コンポーネントの各々はアクティブなコンテキストを連結し、アクティブなコンテキストを臨床コンテキストブジェクトから得る。
【００９４】
第２タイプのユーザ対話は、コンポーネントと直接対話するユーザを含んでいる。ユーザではなくコンポーネントが、共有環境と対話する。これは、コンテキスト情報をコンテキスト管理者又はコンテキストブジェクトから送受信することにより行う。一実施例では、コンテキスト変更対話が、サーバーサイドと通信せずに完全に依頼者上で生じる。他の実施例では、コンテキスト交換は、サーバーへの通信で生じる。例えば、いつコンポーネントが対話されたか記録する。
【００９５】
図２１は、コンテキスト管理者/オブジェクトを使用して成功したコンテキスト変更のシーケンス図を示す。ユーザがコンポーネント中の新しいコンテキスト変数を選択すると、シーケンスが始まる。この場合、コンテキスト変数は訪問である。その後、コンテキストアウエアコンポーネントはプロトコルを始めるが、これはコンテキストを同時に変更できるアプリケーションを一つに限定し、変更が一つも失われないことを保証するためである。コンテキストアウエアコンポーネントは、StartChangesメッセージをコンテキスト管理者/オブジェクトに送信する。これによって、他のアプリケーションをロックしコンテキスト変更を始めないようにして、開始アプリケーションにブランクのコンテキストエリアを与える。その後、そのアプリケーションは、新しいコンテキスト変数を設定する一連のメッセージを送信し、最後にEndChangesメッセージを送信する。EndChangesメッセージが受取られると、コンテキスト管理者/オブジェクトは、メッセージ変更の他の要請を自由に受け入れることができる。その後、コンテキスト管理者/オブジェクトは、コンテキストのメンバーである（つまり、コンテキストに加わった）他のすべてのアプリケーションにメッセージを送信し、新しいコンテキストがペンディングであると伝える。図２１の例示的な実施例では、アプリケーションが、すべて新しいコンテキストを受理する。もっとも、他の応答も可能である。アプリケーションの全部が新しいコンテキストを受理する場合、コンテキスト管理者/オブジェクトは、メッセージを開始コンポーネントに送り、アプリケーションがすべて受理したことを伝える。開始コンポーネントは、メッセージを臨床コンテキストに送信する。これは現在のコンテキストを、受理されたコンテキストと取り替えるためである。臨床コンテキストは、コンテキストのすべてのメンバーに、新しいコンテキストは今アクティブであることを発信する。その後、アプリケーションは新しいコンテキストを要求し、必要な変更を加える。
【００９６】
すべてのコンポーネントが受理されるとは限らない。従って、他の応答も、以下のように、有効である。例示的な反応（「受理」でないもの）には、次のものが含まれる。
【００９７】
・条件付き受理：ユーザがタスクを終了しなければ、タスクの途中でワークが失われる。変更が公表されると、タスクを終了し、コンテキストデータ変更を受理し、それに従って内部状態を変更する。そのあと変更が公表されると、アプリケーションは、その内部状態の変更を、ある程度の時間まで延期できる。例えば、それがユーザ入力のためのフォーカスを回復するとき等である。しかし、それは、新しいコンテキストと同期していないことを示すビジュアルキューを出さなければならない。例えば、それはデータ表示を消すか、又はそれ自体を最小限にする。
【００９８】
・終了：アプリケーションが、最初に臨床コンテキストに通知せずに終了した。これはコンテキスト変更に影響を与えない。アプリケーションはコンテキストから取り除かれる。
【００９９】
・ビジー：コンテキスト管理者は、アプリケーションがまだ実行中であるが、答えられないことを決めた場合である。例えば、アプリケーションはシングルスレッドであり、モード対話は開放されている。アプリケーションが使用中の場合、開始コンポーネントは、使用中のアプリケーションすべての簡潔であるが有益な記述（名前を含んで）を与えられる。この情報は、これらのアプリケーションの代わりに臨床コンテキストによって提供される。なぜなら、これらのアプリケーションは、そうすることができないからである。開始アプリケーションは、ユーザへの通報メッセージを表示するように選ぶことができる。
【０１００】
情報損失を回避するために、コンテキストチェンジャーは、何か変更を加えるためにトークンを利用する。変更を加えているコンテキスト参加者は、ビジーの参加者を取扱うことができなければならない。アプリケーションは、コンテキスト変更を進めるべきか決定するコード、又はコンテキスト変更を進めるかどうかユーザを催促するコードを含んでいなければならない。概念的に、システム決定にユーザを関与させないことが望ましい。例えば、表示プログラムがビジーのとき、アクティブな訪問の変更を希望するかどうか疑問である。しかし自動的に決定するコードは、実際的ではない。
【０１０１】
以上述べた構成によれば、異なるシステム間での情報のやり取り、異なるシステムに係る複数情報の一元的な取り扱いを可能とする医療情報システムを実現することができる。
【０１０２】
以上、本発明を実施形態に基づき説明したが、本発明の思想の範疇において、当業者であれば、各種の変更例及び修正例に想到し得るものであり、それら変形例及び修正例についても本発明の範囲に属するものと了解される。
【０１０３】
また、各実施形態は可能な限り適宜組み合わせて実施してもよく、その場合組合わせた効果が得られる。さらに、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果の欄で述べられている効果の少なくとも１つが得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【産業上の利用可能性】
【０１０４】
以上本発明によれば、異なるシステム間での情報のやり取り、異なるシステムに係る複数情報の一元的な取り扱いを可能とする医療情報システムを実現できる。
【図面の簡単な説明】
【０１０５】
【図１】図１は、共通の情報保存システムを共有する、コンピュータのネットワークのブロック図である。
【図２】図２は、例えばウェブブラウザ又は他のGUIインターフェースを使用した場合の、人々と各エージェント、又は各エージェント間での情報フローを示すデータフローモデルである
【図３】図３は、サーバ２００内において、種々のロケーションから読み出されたデータが、いかに組み合わされ、要求されたデータとともに最終的に与えられるレイアウトを生成するかを示す概念図である。
【図４】図４は、本実施形態に係る表示を実行するための、例示的なアプレットベースの実施技法の、コンポーネント図である。
【図５】図５は、例示的な医療用アプリケーションのために生成された例示的なユーザインターフェースである。
【図６】図６は、図１のユーザ表示の一つとして使用されるコンピュータシステムの図解である。
【図７】図７は、様々な依頼者情報間の関係を表す例示的な患者記述文法である。
【図８】図８は、様々な依頼者情報間の関係を表す例示的な患者記述文法である。
【図９】図９は、システム内の様々なレイアウトコンポーネント間の関係を表すエンティティー関係図である。
【図１０】図１０は、図９のエンティティー関係図に適合するプロパティの例示的なセットである。
【図１１】図１１は、ハードウェア固有又はモダリティ固有のコンポーネントを、ハードウェア独立又はモダリティ独立のコンポーネントからイネーブルするインターフェースの分割のブロック図である。
【図１２】図１２は、情報をレイアウトするために使用する種々のパネル例を示した図である。
【図１３】図１３は、パネル上のレイアウトをコントロール支援しレファレンスする表示プロパティを示した図である。
【図１４】図１４は、個別の水平パネル及び垂直パネルから、４パネルウィンドウを形成するためのコンポーネントの、例示的なXMLベースの階層組合せである。図１３は、階層上のパネルを定義するための、文法の図式記述である。
【図１５】図１５は、パネルの階層を定義するための、例示的なレイアウトエディターである。
【図１６】図１６は、システム内の様々なレイアウトコンポーネント間の関係を表す例示的なコンポーネントレイアウト文法である。
【図１７】図１７は、アプレットを使用せずに、本実施形態に係るDSUIを実施するための、エンティティー関係図である。
【図１８】図１８は、本実施形態において、薄い依頼者実施の初期化を示すメッセージシーケンス図である。
【図１９】図１９は、コンポーネントのコンテキスト情報を得るための登録を示すメッセージシーケンス図である。
【図２０】図２０は、コンポーネントのインターフェースの構築を示すメッセージシーケンス図である。
【図２１】図２１は、コンテキスト情報を変更する過程を示すメッセージシーケンス図である。
【符号の説明】
【０１０６】
１００…コンピュータシステム
１００ａ．１００ｂ…端末
１０２…コンピュータハウジング
１０４…マザーボード
１０８…メモリ
１１０…表示カード
１１２…ハードディスク
１１４…フロッピー（登録商標）ディスクドライブ
１１８…コンパクトディスクリーダ
１１９…コンパクトディスク
１２０…モニター
２００…サーバ
２００ａ…確認エージェント
２００ｂ…表示エージェント
２００ｃ…統合エージェント
２１０…データベース
２１０…情報保存システム
２５０…タブ
２６０…パネル
２７０…情報状態バー
【特許請求の範囲】
【請求項１】
所定の属性毎に分類された医療情報を管理する前記各属性毎のコンポーネントによって共有される医療情報システムであって、
ユーザからの所定の指示に応答して、ネットワーク上の少なくとも一つの端末に、複数の属性のそれぞれに対応する医療情報を統合的に表示するための統合画面のレイアウト情報を、操作者毎に管理する情報管理サーバと、
入力される操作者情報に基づいて、前記情報管理サーバから所定の操作者に関するレイアウト情報を取得するレイアウト情報取得手段と、
前記レイアウト情報の取得に連動して、前記統合画面に含める医療情報を、複数の前記コンポーネントから取得する医療情報取得手段と、
前記レイアウト情報及び前記医療情報が取得されると、前記レイアウト情報を用いて前記医療情報を属性毎に分類した前記統合画面を生成し表示する表示手段と、
を具備することを特徴とする医療情報システム。
【請求項２】
前記レイアウト情報取得手段は、他の操作者への変更指示が入力された場合には、当該変更指示に応答して、前記情報管理サーバから前記他の操作者に関するレイアウト情報を取得し、
前記医療情報取得手段は、当該他の操作者に関するレイアウトに関する情報の取得に連動して、前記統合画面に含める医療情報を、複数の前記コンポーネントから取得し、
前記表示手段は、前記他の操作者に関するレイアウト情報及び前記医療情報が取得されると、当該レイアウト情報を用いて前記医療情報を属性毎に分類した前記統合画面を生成し表示すること、
を特徴とする請求項１記載の医療情報システム。
【請求項３】
前記レイアウト情報取得手段は、他の操作者への変更指示が入力された場合には、当該変更指示に応答して、前記情報管理サーバから前記他の操作者に関するレイアウト情報を取得し、
前記医療情報取得手段は、当該他の操作者に関するレイアウトに関する情報の取得に連動して、前記統合画面に含める医療情報を、複数の前記コンポーネントから取得し、
前記他の操作者に関するレイアウト情報及び前記医療情報が取得されると、当該レイアウト情報を用いて前記医療情報を属性毎に分類した前記統合画面を生成し表示する他の表示手段をさらに具備すること、
を特徴とする請求項１記載の医療情報システム。
【請求項４】
前記情報管理サーバは、操作者からの入力に従って、当該操作者に関する前記統合画面のレイアウトに関する情報を変更することを特徴とする請求項１乃至３のうちいずれか一項記載の医療情報システム。
【請求項１】
所定の属性毎に分類された医療情報を管理する前記各属性毎のコンポーネントによって共有される医療情報システムであって、
ユーザからの所定の指示に応答して、ネットワーク上の少なくとも一つの端末に、複数の属性のそれぞれに対応する医療情報を統合的に表示するための統合画面のレイアウト情報を、操作者毎に管理する情報管理サーバと、
入力される操作者情報に基づいて、前記情報管理サーバから所定の操作者に関するレイアウト情報を取得するレイアウト情報取得手段と、
前記レイアウト情報の取得に連動して、前記統合画面に含める医療情報を、複数の前記コンポーネントから取得する医療情報取得手段と、
前記レイアウト情報及び前記医療情報が取得されると、前記レイアウト情報を用いて前記医療情報を属性毎に分類した前記統合画面を生成し表示する表示手段と、
を具備することを特徴とする医療情報システム。
【請求項２】
前記レイアウト情報取得手段は、他の操作者への変更指示が入力された場合には、当該変更指示に応答して、前記情報管理サーバから前記他の操作者に関するレイアウト情報を取得し、
前記医療情報取得手段は、当該他の操作者に関するレイアウトに関する情報の取得に連動して、前記統合画面に含める医療情報を、複数の前記コンポーネントから取得し、
前記表示手段は、前記他の操作者に関するレイアウト情報及び前記医療情報が取得されると、当該レイアウト情報を用いて前記医療情報を属性毎に分類した前記統合画面を生成し表示すること、
を特徴とする請求項１記載の医療情報システム。
【請求項３】
前記レイアウト情報取得手段は、他の操作者への変更指示が入力された場合には、当該変更指示に応答して、前記情報管理サーバから前記他の操作者に関するレイアウト情報を取得し、
前記医療情報取得手段は、当該他の操作者に関するレイアウトに関する情報の取得に連動して、前記統合画面に含める医療情報を、複数の前記コンポーネントから取得し、
前記他の操作者に関するレイアウト情報及び前記医療情報が取得されると、当該レイアウト情報を用いて前記医療情報を属性毎に分類した前記統合画面を生成し表示する他の表示手段をさらに具備すること、
を特徴とする請求項１記載の医療情報システム。
【請求項４】
前記情報管理サーバは、操作者からの入力に従って、当該操作者に関する前記統合画面のレイアウトに関する情報を変更することを特徴とする請求項１乃至３のうちいずれか一項記載の医療情報システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２００８−２０４４７８（Ｐ２００８−２０４４７８Ａ）
【公開日】平成２０年９月４日（２００８．９．４）
【国際特許分類】
【出願番号】特願２００８−１０７１７１（Ｐ２００８−１０７１７１）
【出願日】平成２０年４月１６日（２００８．４．１６）
【分割の表示】特願２００２−５７９０３（Ｐ２００２−５７９０３）の分割
【原出願日】平成１４年３月４日（２００２．３．４）
【出願人】（５９１２４７２２６）ユニヴァーシティー オブ アリゾナ (1)
【Ｆターム（参考）】
【公開日】平成２０年９月４日（２００８．９．４）
【国際特許分類】
【出願日】平成２０年４月１６日（２００８．４．１６）
【分割の表示】特願２００２−５７９０３（Ｐ２００２−５７９０３）の分割
【原出願日】平成１４年３月４日（２００２．３．４）
【出願人】（５９１２４７２２６）ユニヴァーシティー オブ アリゾナ (1)
【Ｆターム（参考）】
[ Back to top ]