JP2010015562A - 診療記録に対するウェブベースのアクセス - Google Patents

Abstract

【課題】インターネットを介して診療データに対するアクセスを提供するためのシステム及び方法を提供すること。
【解決手段】本システムは、サーバーと、前記サーバーに接続されたデータベースとを備える。前記データベースは診療データセットを格納する。本システムは、更に、シン・クライアントと、前記サーバーとインターネットとの間の通信リンクと、前記シン・クライアントとインターネットのとの間の通信リンクとを備える。前記サーバー上で稼動するソフトウェアは、１又は２以上の診療データセットに対するリクエストを受信し、前記リクエストされた診療データセットを取得し、そして、前記診療データセットを前記シン・クライアントに送信する。
【選択図】図１

Description

本発明は、診療データ(clinical data)のアクセスに関する。詳細には、本発明は、シン・クライアント(thin client)を用いてウェブを介して診療データ(clinical data)または診療記録(clinical records)をアクセスするためのシステム及び方法に関する。

（関連出願の相互参照）
本願は、２００８年６月３０日に出願された米国仮出願第６１／０７７，１５９号の合衆国法典第３５巻(35 U.S.C.)に基づく利益を主張するものであり、それは参照することにより本願に組み込まれる。

本願は、２００８年２月２４日に出願された「Drill Down Clinical Information Dashboard」と題された出願番号１２／０３６，２８１を有する米国特許出願と関連するものである。その出願は参照することにより本願に組み込まれる。

本願は、２００８年２月２４日に出願された「Intelligent Dashboard」と題された出願番号１２／０３６，２８７を有する米国特許出願と関連するものである。その出願は参照することにより本願に組み込まれる。

病院または他の医療施設における診療データは、多くの場合、その施設の現場に配置された複数のサーバーのセットまたはセントラルサーバーに格納される。セントラルサーバーは、主として、その施設のコンピュータ端末を介してアクセスされる。これらのコンピュータ端末は、シック・クライアント(thick clients)と称され、なぜなら、セントラルサーバーから読み取ったデータがそのコンピュータ端末上で処理されるからである。このシステムに格納されたデータは、例えば、病院の情報システム、請求システム、および他の更に特化されたデータ格納手段(repository)のような、複数のソースから取得される。

このような既知のシステムの欠点は、病院で働く医師や他の医療スタッフが、診療データを閲覧するために現場のコンピュータにログオンしなければならないので、セントラルサーバーまたは複数のサーバーに格納された診療データをアクセスするのに不便であるということである。

このような既知のシステムの他の欠点は、診療データを受信して処理するためのソフトウェアが、各現場のコンピュータ端末上で稼動することである。このようなシステムは、維持するのに高いコストがかかる。なぜなら、各コンピュータ端末は、個々にアドレス指定する必要があるからである。

このような既知のシステムの他の欠点は、それらは、医療スタッフ以外の人間が、システムに格納された診療データをアクセスすることを可能にしないことである。例えば、患者は、かれら自身の診療データをアクセスすることはできない。

このような既知のシステムの他の欠点は、それらは、病院（患者のデータが格納されている）にその患者を委託した医師が、システム上に格納されたそのデータをアクセスすることを可能としないことである。

従って、上述の従来技術の制約を克服する、診療データに対するアクセスを提供するためのシステム及び方法に対する要請が存在する。

従って、本発明の目的は、上述の従来技術の制約を克服するシステム及び方法を提供することである。

本発明の他の目的は、医療スタッフ及び医師に、インターネットまたは他のネットワークに接続された任意の電子装置から医療データへのアクセスを提供するシステム及び方法を提供することである。

更に本発明の他の目的は、病院サーバー上に配された医療データの外部閲覧を可能にするウェブベースのクライアントを提供することである。

本発明の他の目的は、患者に、インターネットまたは他のネットワークに接続された任意の電子装置から診療データへのアクセスを提供するシステム及び方法を提供することである。本発明の或る実施形態では、患者に関連する医療データへの患者自身のアクセスが制限される。

更に本発明の他の目的は、医師、例えば委託医師が、病院サーバー上に格納された診療データをアクセスすることを可能にするシステム及び方法を提供することであり、これにより、そのシステムに対する広範なアクセスを提供する。本発明の或る実施形態では、医師の１又は２以上の患者に関連する診療データに対するその医師のアクセスは制限される。

更に本発明の他の実施形態は、患者の許可に基づく個々の患者または患者のグループに対する仮編成済み(tailored)のアクセスの制限および制約を導入することである。このような実施形態では、セントラルデータサーバーは、もはや、患者も委託医師もアクセスしない隔絶した建物内の閉システム(closed system)ではない。

更に本発明の他の目的は、セントラル病院サーバー上に格納された診療データをシン・クライアント（例えば、デスクトップ、ノートブック、タブレットＰＣ、ハンドヘルド機器など）に表示させるシステム及び方法を提供することである。或る実施形態におけるシン・クライアントは、主として、入力（例えば、ユーザとの情報のやり取り）と出力（例えば、表示）を処理する装置であり、データ処理は、このシン・クライアントから離れたところにある別個のサーバー上で実施される。これは、シック・クライアントとは対照的であり、シック・クライアントでは、処理はシック・クライアント自体で実施される。上述の装置の幾つか（例えば、デスクトップ、ノートブックなど）はシック・クライアントとして作動することもできるが、或る実施形態では、これらの装置は、シン・クライアントとして作動する。

更に本発明の他の目的は、中央格納(centrally stored)された診療データに対するアクセスのためのシステム及び方法を提供することであり、ここで、データ処理ソフトウェアのメンテナンスは、サーバー上で稼動するソフトウェア上で実施される必要があるのみである。

更に本発明の他の目的は、セントラル病院サーバー上に格納された診療データをシン・クライアント上のブラウザ上に表示するためのシステム及び方法を提供することであり、ここで、上記ブラウザ内のインターフェイスは、上記ブラウザ内に個別にサイズ化されて個別に配置され得る複数のウィンドウまたは枠(pane)の作成を可能とする。或る実施形態では、個別の枠の数は、１または２から８またはそれ以上まで変化し得る。この枠は、或る実施形態ではサイズが可変であり、複数のウィンドウが異なるサイズを有することができる。

更に本発明の他の目的は、複数の地理的な位置における複数の病院のために稼動するセントラルサーバー設備を提供することであり、これにより、サーバーメンテナンスおよびアップグレーディングと、サーバーレベル及びクライアントレベルの両方でのアプリケーションアップグレーディングの効率を改善する。

更に本発明の他の目的は、病院がハードウェア導入および現場でのメンテナンスの高コストに先行する(forego)ことを可能にする予約加入ベース(subscription basis)で病院にリモートホスティングを導入することである。

本発明のこれら及び他の目的は、サーバーと、上記サーバーに通信で接続されたデータベースとを含む、診療データに対するウェブアクセスを提供するためのシステム及び方法によって達成され、上記データベースは複数の診療データセットを備える。本システムは、更に、シン・クライアント、サーバーとインターネットとの間の通信リンク、および上記シン・クライアントとインターネットとの間の通信リンクを備える。上記サーバー上で稼動するソフトウェアは、１又は２以上の診療データセットに対するリクエストを受信し、上記リクエストされた診療データセットを取得し、そして上記診療データセットを上記シン・クライアントに伝送する。

本発明の或る実施形態では、サーバー上で稼動するソフトウェアは、シン・クライアント上での表示のためのダッシュボード(dashboard)を生成する。このダッシュボードは、シン・クライアント上に診療データセットを表示するための１又は２以上のウィンドウ枠を備える。

或る実施形態では、シン・クライアントに提供されるアプリケーションはサーバー上で稼動するので、上記アプリケーションに対する修正は、各シン・クライアント上よりも、セントラルの位置(central location)で実施されれば十分である。このことは、アプリケーションの更新及びメンテナンスを簡略化する。或る実施形態は、シン・クライアント上の任意のデータのキャッシングを許容しない。他の実施形態は、典型的なウェブアプリケーションに関連すると共にファイアフォックス(Firefox)やエクスプローラ(Explorer)のような標準的なウェブブラウザによって可能とされる普通の種類のキャッシングを許容するのみである。

或る実施形態では、ウェブベースのアプリケーションは、患者が自身のコンピュータ上にソフトウェアをダウンロードすることを要求されることなく、彼ら自身の記録を閲覧することを可能にする。このような実施形態は、患者（病院または他の施設に関連する医療従事者とは対照的）は、かれら自身の医療記録(medical record)に対するアクセスのみを有し、病院の患者の全リストに対するアクセスを有しない。或る実施形態は、特定の患者のパスワードをその特定の患者の医療記録と関連付け、そしてその患者がその特定の記録を閲覧することのみを許容する。このような実施形態では、患者は、その施設内の他の医療記録を閲覧することはできない。このセキュリティステップは、プライバシおよびＨＩＰＡＡ(Health Insurance Portability and Accountability Act)コンプライアンスのために重要である。

或る実施形態では、ウェブアクセスは、同様に、病院の現場にいない委託医師または病院の医療スタッフによる患者記録の検証(review)を容易化する。このような医師は、彼らが病院に委託した患者の記録を容易にアクセスすることを欲するかもしれない。或る実施形態は、特定の医師のアクセスを、その特定の医師が患者の記録を閲覧する許可が与えられたその患者に対するもののみに制限する。従って、このような実施形態では、医療スタッフではない医師は、医師が記録を閲覧することを許可した患者の記録を除いては、自由に施設内の医療記録の全てを閲覧することはできない。病院システム内の患者医療記録を容易に閲覧するための患者と委託医師の能力は、広くアクセス可能であることにいっそう近いステップを健康管理インフラ(healthcare infrastructure)にもたらすシステムの延長線上にある。

或る実施形態では、ウェブベースのアプリケーションを稼動させるサーバーは、病院に組み込まれるよりも、むしろ、遠隔でホスティングされる。このような実施形態では、必要なものは、セントラルサーバー設備とクライアント病院との間のネットワーク（例えば、インターネット）リンクだけであり、それは、地理的に遠く離れていてもよい。或る実施形態では、セントラルサーバーは、複数の地理的な位置における複数の病院のために稼動し、これにより、サーバーメンテナンスおよびアップグレーディングと、サーバーレベルおよびクライアントレベルの両方でのアプリケーションアップグレーディングの効率を改善する。リモートホスティングを採用する或る実施形態は、病院がハードウェア導入および現場でのメンテナンスの高コストに先立つことを可能にする予約加入ベースで病院にモートホスティングを提供する。

或る実施形態は、患者および委託医師が、患者病院記録を閲覧することを可能にし、これにより、システムに広範なアクセスを提供する。或る実施形態は、患者の許可に基づく個々の患者または患者のグループに対し仮編成済みの制限または制約を導入する。このような実施形態では、セントラルデータサーバーは、もはや、患者も委託医師もアクセスしない隔絶した建物内の閉システム(closed system)ではない。

本発明のこれら又は他の目的および利点は、添付の図面を参照して考察された後述の詳細な説明からいっそう明らかになるであろう。

本発明の一実施形態による診療記録へ対するウェブベースのアクセスを提供するためのシステム及び方法を例示する図である。 本発明の一実施形態による診療記録に対するウェブベースのアクセスを提供するシステムを例示する図である。 本発明の一実施形態による方法を例示する図である。 本発明の一実施形態による診療既得に対するウェブベースのアクセスを提供するためのシステムを例示する図であり、ここで、セントラルサーバーは、このサーバーから遠くに離れた地理的位置にある１又は２以上の病院にインターネットを介した診療データアクセスを提供する。 本発明の一実施形態によるシン・クライアント上への表示のためのダッシュボードを例示する図である。 本発明の一実施形態によるシン・クライアント上への表示のためのダッシュボードを例示する図である。 本発明の一実施形態によるシン・クライアント上での表示のためのダッシュボードを例示する図である。 本発明の一実施形態によるシン・クライアント上での表示のためのダッシュボードを例示する図である。

図１は、本発明の一実施形態によるネットワークを介した診療データに対するアクセスを提供するためのシステム１０を示す。システム１０は、通信ネットワーク３０を介して１又は２以上のシン・クライアント５０によりアクセス可能なサーバー２０を備える。或る実施形態では、サーバー２０は、１又は２以上のシン・クライアント５０によって（通信ネットワーク３０を介して、または直接的に）アクセス可能なパーソナルコンピュータであってもよい。他の実施形態では、サーバー２０は、互いに接続された複数のサーバー２０であってもよい。或る実施形態では、通信ネットワーク３０は、インターネットを介した通信リンクであり、他の実施形態では、通信ネットワーク３０は、私設または閉ネットワークを介した通信リンクであってもよい。

システム１０は、更に、診療データを格納するための１又は２以上のデータベース１２を備える。診療データは、患者の治療(treatment)および介護(care)に関する任意のデータ、例えば、患者の容態に関するデータ、請求及び支払い履歴、患者の医療履歴などのデータを含む。本願の目的上、診療データは、また、重症度スコア(severity score)と、１又は２以上の患者をモニタし診断するために計算されたデータ傾向を指す。診療データは、種々のシステムおよび方法を通じて収集され、そしてサーバー２０と接続されたデータベース１２に格納される。データベース１２は、システム１０に多くの患者の診療データを提供する。

図２を参照すると、本発明の実施形態が示されている。シン・クライアント５０は、デスクトップコンピュータ１５２、ノートブックコンピュータ１６４、タブレットコンピュータ１５４、ＰＤＡ(Personal Digital Assistant)１６２、および携帯電話１６６を備えるが、これに限定されない。或る実施形態におけるシン・クライアント５０は、主として、入力（例えば、ユーザーとの情報のやり取り）と出力（例えば、表示）を取り扱う装置であり、処理は別のサーバー上で実施される。これは、シック・クライアントとは対照的であり、シック・クライアントでは、処理はクライアント装置自体で実施される。上述の装置（デスクトップ、ノードブックなど）の或る物は、シック・クライアントとしても機能することができるが、或る実施形態では、これらの装置はシン・クライアント５０として機能する。シン・クライアント１５２，１５４は、それぞれ、通信ネットワーク１３２，１３４を介してサーバー１２０と接続して通信する。シン・クライアント１６２，１６４，１６６は、それぞれ、公衆通信ネットワーク１４２，１４４，１４６、例えばインターネット、を介してサーバー１２０と接続して通信する。

図１に示される実施形態を更に参照すると、シン・クライアント５０は、通信ネットワーク３０を介してサーバー２０と接続して通信する。或る実施形態では、シン・クライアント５０は、通信リンクを介してインターネットと接続される。シン・クライアント５０は、上記通信ネットワーク３０を介して上記サーバー２０と通信するためにウェブブラウザを備えてもよい。本発明の或る実施形態では、シン・クライアント５０は、私設ネットワークを介してサーバー２０と接続して通信することが理解される。更に、本発明の或る実施形態では、１又は２以上のシン・クライアント５０が無線ネットワークを介してサーバー２０と接続して通信することが理解される。

サーバー２０は、データベース１２に格納された診療データを処理するためのソフトウェアを備える。図１を参照すると、サーバー２０上で稼動するソフトウェアは、医療データ管理アプリケーション(Medical Data Manager Application)２２と呼ばれる。医療データ管理アプリケーション２２は、データベース１２に格納された診療データを処理するための複数のソフトウェアモジュールを含み、この医療データ管理アプリケーション２２は、本明細書の全体を通じてソフトウェア２２として記述される。

図１を更に参照すると、サーバー２０上で稼動するソフトウェア２２は、上記シン・クライアント５０からコマンド４２を受信する。図１に示される実施形態では、コマンド４２は、診療データ４４に対するリクエストである。サーバー２０は、多くの異なるコマンド、例えば、診療データを処理するためのコマンド、または、別の様式で診療データを表示するためのコマンドなどのコマンドを受信してもよい。サーバー２０上で稼動するソフトウェア２２は、コマンド４２に応答して、データベース１２から上記リクエストされた診療データ４４を取得する。サーバー２０上で稼動するソフトウェア２２は、上記リクエストされた診療データ４４を、ネットワーク通信リンク３０を介してシン・クライアント５０に送信する。上記リクエストされた診療データ４４は、シン・クライアント５０上のユーザインターフェイス上に表示される。

本発明の或る実施形態では、本システムは、ユーザインターフェイス（またはダッシュボード）を生成するための、サーバー２０上で稼動するソフトウェア２２を備える。図５Ａ−図５Ｄを参照すると、ユーザダッシュボード５００，６００，７００，８００の種々の例が示されている。シン・クライアント５０は、サーバー２０上で稼動するソフトウェア２２によって生成されたダッシュボード５００を表示する。ダッシュボード５００は、典型的には、シン・クライアント５０のユーザインターフェイスの中に表示される。例えば、ダッシュボード５００は、シン・クライアント５０上で稼動するウェブブラウザ内に表示されてもよい。各ダッシュボード５００，６００，７００，８００は、図５Ａにおけるダッシュボード５００上に示されるウィンドウ枠５１０，５２０，５３０，５４０のような複数のウィンドウ枠を含む。ダッシュボードの種々のウィンドウ枠は診療データを表示する。例えば、ウィンドウ枠５２０は、第１の患者に関する診療データを示す。

或る実施形態では、ダッシュボードは、ダッシュボード５００の患者リストウィンドウ５４０のような、患者リストウィンドウを含む。患者リストウィンドウ５４０は、患者のリスト、各患者に関する記録された診療データ、患者診療データから生成された計算スコア、および、上記記録されたデータと上記生成されたスコアに関連する傾向を提供する。或る実施形態では、患者リストウィンドウ５４０は、編集可能であり、または選択可能であり、クリック可能である。

図５Ａに示された実施形態を参照すると、ダッシュボード５００はメニューバー５５０を更に備える。メニューバー５５０は、１又は２以上のメニューオプション、例えば、バイタル(vitals)、スキャン(scans)、ラボ(labs)、ナーシング(nursing)などのメニューオプションを有する。メニューバーオプションが選択されると（シン・クライアント５０上の適切な入力を介して）、メニューが“プルダウン(pulls down)”して、メニュー項目またはオプションを提示(reveal)する。これらのオプションは、ユーザがダッシュボード内の種々のアクションを実施することを可能とすると共に、ユーザが１又は２以上の診療データセットをリクエストすることを可能にする。或る実施形態では、ユーザはダッシュボード５００を設定(configure)することができる。例えば、ユーザは、１又は２以上のウィンドウ枠(pane)のサイズ、ウィンドウ枠の数、およびウィンドウ枠に表示されるデータのタイプを設定することができる。システム１０は、更に、後の使用のためにダッシュボード設定を保存することができる。

図１を参照すると、サーバー２０上で稼動するソフトウェア２２は、第１の複数のウィンドウ枠５１０，５２０，５３０，５４０を有する第１のダッシュボード５００を生成する。サーバー２０上で稼動するソフトウェア２２は、第１のダッシュボード５００を、シン・クライアント５０上での表示のためにシン・クライアント５０に送信する。或る実施形態では、サーバー２０上の本発明のソフトウェア２２は、第１のダッシュボード５００の１又は２以上の第１の複数のウィンドウ枠５２０に診療データ４４を表示させる。例えば、図５Ａを参照すると、システム１０は、シン・クライアント５０上にダッシュボード５００を表示する。シン・クライアント５０のユーザは、例えば、患者リストウィンドウ枠５４０上の患者名を選択することにより診療データをリクエストしてもよい。サーバー２０上で稼動するソフトウェア２２は、診療データに対するリクエスト４２を受信し、上記リクエストされた診療データ４４をデータベース１２から取得し、そして、上記リクエストされた診療データを、ダッシュボード５００のウィンドウ枠５２０へ表示させるためにシン・クライアント５０に送信する。

本発明の或る実施形態では、サーバー２０上で稼動するソフトウェア２２によって生成される第１のダッシュボード５００は、シン・クライアント５０上に表示される。シン・クライアント５０のユーザは、第１のダッシュボード５００上の入力を介して診療データをリクエストする。サーバー２０上で稼動するソフトウェア２２は上記リクエストを受信し、そして上記リクエストされた診療データ４４を取得する。そして、サーバー２０上で稼動するソフトウェア２２は、第２の複数のウィンドウ枠を有する第２のダッシュボード６００を生成し、そしてこの第２のダッシュボード６００を、シン・クライアント５０上での表示のためにシン・クライアント５０に送信する。或る実施形態では、第１のダッシュボード５００は、例えば、患者リストウィンドウ枠５４０における患者名など、リンク５４２を含む。例えばシン・クライアント５０でのユーザ入力により、リンク５４２が活性化されると、サーバー２０上で稼動するソフトウェア２２は、第２のダッシュボード６００を生成し、そして第２のダッシュボード６００上の１又は２以上のウィンドウ枠に診療データ４４を含め、ここで、診療データ４４は、リンク５４２と関連する患者に関するものである。このようにして、シン・クライアント５０のユーザは、複数の患者に関する診療情報が表示されるジェネラル・ダッシュボード５００を、追加の患者固有の診療情報が表示される更に特化されたダッシュボード６００に切り替える(toggle)ことができる。

本発明の他の実施形態では、ウィンドウの第１のセットを有する第１のダッシュボードは、例えば患者に関連する概略的な診療データ(general clinic data)など、患者の第１の様相(aspect)に関する診療データの第１のセットを表示する。複数のウィンドウの第２のセットを有する第２のダッシュボードは、例えば医療スタッフが処置しようとする特定の状況に関する診療データなど、患者の第２の様相に関する診療データを表示する。或る実施形態では、第１および第２のダッシュボードは、同一の診療データを表示してもよいが、他の実施形態では、第１および第２のダッシュボードは、異なる診療データを表示する。

或る実施形態では、サーバー２０上で稼動するソフトウェアは、ダッシュボード５００のウィンドウ枠５３０にウェブブラウザを提供する。シン・クライアント５０のユーザは、ウィンドウ枠５３０に備えられたブラウザを通じてＷＷＷ(World Wide Web)をアクセスすることができる。例えば、私設ネットワークまたは閉ネットワークに接続されたシン・クライアント５０を通じてシステムをアクセスするユーザは、ブラウザウィンドウ枠５３０を介してＷＷＷ(World Wide Web)をアクセスすることができる。

或る実施形態では、ウェブベースのアプリケーションは、医者、患者、および病院の外部に位置する他の個人が、システム上に格納された診療データセットをアクセスすることを可能にする。このような実施形態では、診療データに対するアクセスは、このような診療データをアクセスするための承認を有する人に制限されることが好ましい。例えば、患者は、自身の診療データをアクセスするために承認されるが、他人の診療データのアクセスを制限される。このような実施形態は、患者（病院に関連する医療従事者とは対照的）が自身の個人診療データのみに対するアクセスを有するが、病院の患者の全リストに対するアクセスを有しない。他の実施形態では、委託医師は、その医師の患者のみに対するアクセスを有する。このセキュリティステップは、プライバシおよびＨＩＰＡＡ(Health Insurance Portability and Accountability Act)コンプライアンスには重要である。

図３を参照すると、診療データに対するアクセスを制限するための方法が例示されている。先ず、サーバーは、シン・クライアント２０２から診療データリクエストを受信する。各診療データリクエストは、上記リクエストが作成された１又は２以上のシン・クライアント、または、シン・クライアントを通じて上記リクエストを作成するユーザに関するユニークな識別子と関連づけられる。また、データベース１２に格納された診療データは、１又は２以上の識別子と関連づけられる。サーバー２０上で稼動するソフトウェア２２は、シン・クライアントから診療データリクエストを受信する。サーバー２０上で稼動するソフトウェア２２は、１又は２以上のシン・クライアント５０およびシン・クライアントユーザが、１又は２以上のユニークな識別子に基づきリクエストされた診療データをアクセスすることが承認されているかどうかを判定する。もし、それが承認されているリクエストであるとシステムが判定すれば、サーバー上で稼動するソフトウェアは、上記リクエストされたデータ２１２を取得し、そして、診療データをシン・クライアント２１４に送信する。もし、それが承認されていないリクエストであるとシステムが判定すれば、サーバー上で稼動するソフトウェアは、未承認リクエストの通知を生成して、この未承認リクエストの通知をシン・クライアント２１０に送信し、そして、上記リクエストされたデータに対するアクセスをブロックする。当然ながら、診療データアクセスの多くの異なる種々の判定が可能であり、上述の説明は例示目的のみを意図したものである。例えば、データ承認プロトコルは、システム、ユーザの数、ユーザのタイプ、とりわけユーザの位置に依存して変わってもよい。

図４を参照すると、本発明の別の実施形態が例示されており、ここで、ウェブベースのアプリケーションを稼動(run)させるサーバーは、１又は２以上の医療施設から遠く離れた地理上の位置に存在している。例えば、上記サーバーは、異なる市、郡、州、または国に存在してもよい。この実施形態では、サーバー３２０は、病院３５４，３４４，３３４から離れた地理上の位置に配置されている。サーバー３２０および関連データベース３１２は、複数の病院のためのデータ格納と処理を遂行する。病院にいるユーザは、サーバー上に格納されたデータをアクセスする。サーバーは、そのデータを処理し、そのデータを病院に送信する。或る実施形態では、病院は、また、ローカルネットワークを維持してもよい。リモートホスティングを採用する或る実施形態は、病院がハードウェア導入および現場でのメンテナンスの高コストに先行する(forego)ことを可能にする予約加入ベース(subscription basis)で病院にリモートホスティングを提供する。

本発明は、特定のパーツの構成や特徴などを参照して説明されたが、これらは可能性のある特徴の構成の全てを示したものではなく、当業者であれば、多くの修正および変形が解明可能である。

１０ システム
１２ データベース
２０ サーバー
２２ 医療データ管理アプリケーション
３０ 通信ネットワーク
４２ コマンド
４４ 診療データ
５０ クライアント

Claims (22)

1. 診療データに対するアクセスを提供するためのシステムであって、
   サーバーと、
   複数の診療データセットを含み、前記サーバーと接続されて通信する少なくとも一つのデータベースと、
   クライアントと、
   前記サーバーとインターネットとの間の通信リンクと、
   前記クライアントとインターネットとの間の通信リンクと、
   前記サーバー上で稼動し、１又は２以上の診療データセットに対するリクエストを受信するためのソフトウェアと、
   前記サーバー上で稼動し、前記リクエストに応答して、前記１又は２以上の診療データセットを取得するためのソフトウェアと、
   前記サーバー上で稼動し、前記１又は２以上の診療データセットを前記クライアントに送信するためのソフトウェアと
   を備えたシステム。
2. 前記サーバー上で稼動し、第１の複数のウィンドウ枠からなる第１のインターフェイスを生成するためのソフトウェアと、
   前記サーバー上で稼動し、前記第１のインターフェイスを、前記クライアント上での表示のために前記クライアントに送信するためのソフトウェアと
   を更に備えた請求項１記載のシステム。
3. 前記第１の複数のウィンドウ枠のうちの少なくとも一つは、前記１又は２以上の応答の診療データセットを表示する請求項２記載のシステム。
4. 前記サーバー上で稼動し、第２の複数のウィンドウ枠からなる第２のインターフェイスを生成するためのソフトウェアと、
   前記サーバー上で稼動し、前記第２のインターフェイスを、前記クライアント上での表示のために前記クライアントに送信するためのソフトウェアと
   を更に備え、
   前記第１のインターフェイスは、リンクを更に備え、前記リンクは、前記第１の複数のウィンドウ枠の少なくとも一つにおいて項目が選択された場合に、前記クライアント上に前記第２のインターフェイスを表示させる請求項３記載のシステム。
5. 前記第１の複数のウィンドウは、患者の第１の様相に関する第１の診療データセットを表示し、前記第２の複数のウィンドウは、前記患者の第２の様相に関する第２の診療データセットを表示し、
   前記第１の様相および前記第２の様相は異なる請求項４記載のシステム。
6. 前記サーバー上で稼動し、ウィンドウ枠のサイズ、ウィンドウ枠の数、ウィンドウ枠に表示されるデータのタイプのうちの１又は２以上を調整することにより前記第１のインターフェイスを再構成するためのソフトウェアを更に備えた請求項３記載のシステム。
7. 前記サーバー上で稼動し、前記再構成された第１のインターフェイスを格納するためのソフトウェアを更に備えた請求項６記載のシステム。
8. 前記第１のインターフェイスは、前記クライアントから受信されるコマンドに応答して再構成される請求項７記載のシステム。
9. 前記第１の複数のウィンドウ枠のうちの少なくとも一つは、複数の患者からなるリストを表示する請求項２記載のシステム。
10. 前記ソフトウェアは、前記複数の患者のうちの少なくとも一人の患者に関する１又は２以上の診療データセットに対するリクエストを受信する請求項９記載のシステム。
11. 前記サーバー上で稼動し、前記第１の複数のウィンドウ枠のうちの一つにおける表示のためのウェブブラウザを提供するためのソフトウェアを更に備え、
    前記クライアントのユーザは、前記ウェブブラウザを通じてＷＷＷ(World Wide Web)をアクセスすることができる請求項２記載のシステム。
12. インターネットを介して診療データに対するアクセスを提供するためのシステムであって、
    サーバーと、
    複数の診療データセットを含み、前記サーバーと接続されて通信する少なくとも一つのデータベースと、
    クライアントと、
    前記サーバーとインターネットとの間の通信リンクと、
    前記クライアントとインターネットとの間の通信リンクと、
    前記サーバー上で稼動し、第１の診療データセットに対するリクエストを受信するためのソフトウェアと、
    前記サーバー上で稼動し、前記リクエストに応答して、前記第１の診療データセットを取得するためのソフトウェアと、
    前記サーバー上で稼動し、前記クライアント上での表示のために第１の複数のウィンドウ枠からなる第１のインターフェイスを生成するためのソフトウェアと、
    前記サーバー上で稼動し、前記第１のインターフェイスを前記クライアントに送信するためのソフトウェアとを備え、
    前記第１の診療データセットは、前記第１の複数のウィンドウ枠のうちの一つのウィンドウ枠に表示されるシステム。
13. 前記サーバー上で稼動し、前記複数のウィンドウ枠のうちの第２のウィンドウ枠における表示のためのウェブブラウザを提供するためのソフトウェアを更に備え、
    前記クライアントのユーザは、前記ウェブブラウザを通じてＷＷＷ(World Wide Web)をアクセスすることができる請求項１２記載のシステム。
14. 前記サーバー上で稼動し、第２の複数のウィンドウ枠からなる第２のインターフェイスを生成するためのソフトウェアと、
    前記サーバー上で稼動し、前記第２のインターフェイスを、前記クライアント上での表示のために前記クライアントに送信するためのソフトウェアと
    を更に備え、
    前記第１のインターフェイスは、リンクを更に備え、前記リンクは、前記第１の複数のウィンドウ枠の少なくとも一つにおいて項目が選択された場合に、前記クライアント上に前記第２のインターフェイスを表示させる請求項１２記載のシステム。
15. 前記第１の複数のウィンドウは、患者の第１の様相に関する第１の診療データセットを表示し、前記第２の複数のウィンドウは、前記患者の第２の様相に関する第２の診療データセットを表示し、前記第１の様相および前記第２の様相は異なる請求項１４記載のシステム。
16. 前記サーバー上で稼動し、前記クライアントのユーザが、前記第１の診療データセットをアクセスすることが承認されているかどうかを判定するためのソフトウェアと、
    前記サーバー上で稼動し、前記クライアントが前記第１の診療データセットをアクセスすることが承認されているかどうかの前記判定に応答して、前記ユーザに承認状態通知を送信するためのソフトウェアと
    を更に備えた請求項記載のシステム。
17. インターネットを介して診療データに対するアクセスを提供するための方法であって、当該方法は、
    サーバーを提供するステップと、
    複数の診療データセットを含み、前記サーバーと接続されて通信する少なくとも一つのデータベースを提供するステップと、
    クライアントを提供するステップと、
    前記サーバーとインターネットとの間の通信リンクを提供するステップと、
    前記クライアントとインターネットとの間の通信リンクを提供するステップと、
    第１の診療データセットに対するリクエストを受信するステップと、
    前記リクエストに応答して、前記第１の診療データセットを取得するステップと、
    前記クライアント上での表示のために第１の複数のウィンドウ枠からなるインターフェイスを生成するステップと、
    前記インターフェイスを前記クライアントに送信するステップと、
    前記第１の診療データセットを、前記複数のウィンドウ枠のうちの一つのウィンドウ枠に表示させるステップと
    を含む方法。
18. 前記複数のウィンドウ枠のうちの第２のウィンドウ枠における表示のためのウェブブラウザを提供するステップを更に含み、
    前記クライアントのユーザは、前記ウェブブラウザを介してＷＷＷ(World Wide Web)をアクセスすることができる請求項１７記載の方法。
19. 第２のウィンドウ枠に複数の患者のリストを提供するステップと、
    前記複数の患者のうちの一人に関する診療データセットを取得するステップと
    を更に含む請求項１７記載の方法。
20. 前記ユーザの識別子に基づいて、前記クライアントの前記ユーザが、前記リクエストされた第１の診療データセットをアクセスすることが承認されているかどうかを判定するステップを更に含む請求項１７記載の方法。
21. １又は２以上の病院に診療データに対するウェブアクセスを提供する方法であって、
    １又は２以上のサーバーを備えたセントラルサーバー設備を提供するステップと、
    前記サーバー設備と接続されて通信し、複数の診療データセットを含む少なくとも一つのデータベースを提供するステップと、
    前記サーバー設備と１又は２以上の病院ネットワークとの間のネットワーク通信を提供するステップと、
    前記１又は２以上の病院ネットワークからのリクエストに応答して、前記サーバー設備で前記１又は２以上の診療データセットを処理するステップと、
    前記処理された診療データセットを前記１又は２以上の病院ネットワークに送信するステップとを含む方法。
22. インターネットを介して診療記録に対するウェブベースのアクセスを提供するために予約加入ベースで１又は２以上の病院に課金するステップを更に含む請求項２１記載の方法。