(57)【要約】【課題】手技療法ワークフロー・システムが、医療手技に関連するデータを収集し、ワークフローを組織化し、かかる手技について統計を収集することを可能にする。【解決手段】このシステムは、データ管理サブシステム、手技スパン・サブシステム、作業組織化サブシステム、及び実務管理サブシステムを含んでいる。このシステムは、共通語彙を介して異質なソースからの情報を用いることを可能にする。この手技療法ワークフロー・システムは、データ管理サブシステムと、手技スパン・サブシステムと、作業組織化サブシステムと、実務管理サブシステムとを含んでいる。データ管理サブシステムは一つの診療科の範囲内で患者治療を実行し、管理して測定するのに必要なデータを獲得する。【選択図】図１
2008522283.tif 000002
【特許請求の範囲】
【請求項１】
医療手技に対応するデータを獲得するように構成されているデータ管理サブシステムと、
前記医療手技の選択された部分に対応する情報を獲得して追跡するように構成されている手技スパン・サブシステムと、
前記データ管理サブシステム及び前記手技スパン・サブシステムに結合されており、前記手技を実行するために適当なリソースを選択して、該選択されたリソースが前記手技を実行するための必要に応じて該選択されたリソースに対して前記獲得されたデータの部分集合を提示するように構成されている作業組織化サブシステムと、
該作業組織化サブシステムに結合されており、前記リソース及び前記手技の実務的側面及び患者治療的側面を監視するように構成されている実務管理サブシステムと、
を備えた手技療法ワークフロー・システム。
【請求項２】
前記データ管理サブシステムは、ディジタル医用撮像装置から前記データの一部を受け取る、請求項１に記載のシステム。
【請求項３】
前記データ管理サブシステムは、放射線撮像装置から前記データの一部を受け取る、請求項１に記載のシステム。
【請求項４】
前記データ管理サブシステムは、心臓撮像装置から前記データの一部を受け取る、請求項１に記載のシステム。
【請求項５】
前記データ管理サブシステムは、多数の撮像構成要素から前記データを受け取る、請求項１に記載のシステム。
【請求項６】
前記データ管理サブシステムは、医用装置、電子カルテ、走査書類、データベース・ウェブ・サービス及び収集された構造的臨床データの部分集合から前記データを統合する、請求項１に記載のシステム。
【請求項７】
前記手技スパン・サブシステムにより獲得されて追跡される前記情報は、保険情報、医療指示、医療履歴、予定及び追跡情報の少なくとも一つを含んでいる、請求項１に記載のシステム。
【請求項８】
前記作業組織化サブシステムは、前記リソースの一つへの提示のための前記データを、前記手技のコンテクストにおいて前記一つのリソースに関連する前記データの一部のみが提示されるようにフィルタ処理するようにさらに構成されている、請求項１に記載のシステム。
【請求項９】
手技療法ワークフロー・システムにより実行される方法であって、
医療手技に対応するデータを獲得するステップと、
前記手技の選択された部分に対応する情報を獲得して追跡するステップと、
前記手技を実行するために適当なリソースを選択して、該選択されたリソースが前記手技を実行するための必要に応じて該選択されたリソースに対して前記データの部分集合を提示するステップと、
前記リソース及び前記手技の実務的側面及び患者治療的側面を監視するステップと、
を備えた方法。
【請求項１０】
前記データを獲得するステップは、ディジタル医用撮像装置からデータを得るステップをさらに含んでいる、請求項９に記載の方法。
【請求項１１】
前記データを獲得するステップは、放射線撮像装置からデータを得るステップをさらに含んでいる、請求項９に記載の方法。
【請求項１２】
前記データを獲得するステップは、心臓撮像装置からデータを得るステップをさらに含んでいる、請求項９に記載の方法。
【請求項１３】
前記データを獲得するステップは、多数の撮像構成要素からデータを得るステップを含んでいる、請求項９に記載の方法。
【請求項１４】
前記データを獲得するステップは、医用装置、電子カルテ、走査書類、データベース・ウェブ・サービス及び収集された構造的臨床データの部分集合からデータを統合するステップをさらに含んでいる、請求項９に記載の方法。
【請求項１５】
前記獲得されて追跡される情報は、保険情報、医療指示、医療履歴、予定及び追跡情報の少なくとも一つを含んでいる、請求項９に記載の方法。
【請求項１６】
前記リソースの一つへの提示のための前記データを、前記手技のコンテクストにおいて前記一つのリソースに関連する前記データの一部のみが提示されるようにフィルタ処理するステップをさらに含んでいる請求項９に記載の方法。
【請求項１７】
手技別ワークフロー管理を実行するために、
医療手技に対応するデータを獲得し、
前記手技の選択された部分に対応する情報を獲得して追跡し、
前記手技を実行するために適当なリソースを選択し、該選択されたリソースが前記手技を実行するための必要に応じて該選択されたリソースに対して前記データの部分集合を提示して、
前記リソース及び前記手技の実務的側面及び患者治療的側面を監視する
ように構成されているコンピュータ・プログラム・コードを内部に実装したコンピュータ読み取り可能な媒体を備えたコンピュータ・プログラム・プロダクト。
【請求項１８】
患者関連データを含む複数の医療記録を蓄積するように構成されている登録データベースと、
患者関連データを受け取って、該患者関連データを前記医療データベース・システムにより利用される表現に写像するように構成されている写像モジュールと、
該写像モジュールに結合されており、前記写像された患者関連データを受け取って、該写像された患者関連データが、前記登録データベースに記憶されている医療記録に一致するか否かを判定するように構成されている比較モジュールと、
前記写像モジュール及び前記比較モジュールに結合されて通信し、１又は複数の医療記録を生成し、前記患者関連データが前記登録データベースに記憶されている前記医療記録に一致しないことに応答して、前記１又は複数の医療記録を前記受け取った患者関連データで埋めるように構成されている自動生成モジュールと、
を備えた手技療法ワークフロー・システム。
【請求項１９】
手技療法ワークフロー・システムにより実行される方法であって、
患者関連データを含む複数の医療記録を記憶するステップと、
前記患者関連データを受け取って、該患者関連データを医療データベース・システムにより用いられる表現に写像するステップと、
前記写像された患者関連データを受け取って、該写像された患者関連データが、記憶された医療記録に一致するか否かを判定するステップと、
１又は複数の医療記録を生成して、前記患者関連データが前記記憶された医療記録に一致しないことに応答して、前記１又は複数の医療記録を前記受け取った患者関連データで埋めるステップと、
を備えた方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般的には、健康管理情報の管理の分野に関し、さらに具体的には、撮像に基づく手技を用いる業務系統の効率の最適化に必要な情報の管理及び統合に関する。
【背景技術】
【０００２】
手技に基づく療法の利用が拡大するにつれて、専門診療科の効率及び治療成果を改善する必要はさらに明らかになっている。多くの健康管理施設は依然として、書類に基づいたシステム又は統合的でない電子的システムを用いて作業を管理している。このことから、臨床スタッフが、患者の治療を提供する過程で必要とされる情報又は画像の位置を突き止める必要が絶えず生じている。医療手技に依存した患者の治療を大幅に改善するために、専門分野横断的な患者の単一の把握像と、各々の専門分野の範囲内での「深化された」把握像とを提供することが必要とされる。
【０００３】
手技に基づく療法、例えば心臓病学、腫瘍学、胃腸病学及び一般的な外科手術は、プライマリー・ケア療法、例えば家族医療、小児科学、老人病学及び一般的な内科学とは多くの重要な側面において異なっている。後者、典型的にはより一般的な診療は、予防的な身体検査乃至疾患管理から一般的な怪我の治療に到る極めて広範囲の行為を包含する。診療範囲がこのように広いため、診療の実効性を高めるためのシステムは、様々な電子カルテ（又は電子医療記録、ＥＭＲ）システム及び病院情報システム（ＨＩＳ）に見受けられるような患者中心型の観点によるワークフローに基づくものとなっている。この患者中心型の観点は、例えば「患者記録データベース…」を有する「患者カルテ・システム」を記載したClark等の米国特許第５，９７４，３８９号「Medical Record Management System and Process with Improved Workflow Features」で明らかである。患者中心型ワークフローは、殆どの医療業務が患者の病床で担当医及び他の看護者によって行なわれていたときには有意義であった。
【０００４】
近年、益々多くの健康管理が手技に基づく療法を介して提供されるようになっている。この形式の健康管理は、一般的な診療に見受けられていたものよりも厳密に定義された行為によって特徴付けられ、かかる診療での行為の大半が患者との実時間的な相互作用を含まない場合がある。例えば、典型的な放射線診療での行為の大半は実際の患者との相互作用時には行なわれず、患者の来診の準備時（例えば他の健康管理提供者からの報告に基づく準備）又は患者の来診時に得られた画像の後の分析時に行なわれる。かかる放射線診療には主に、診療の診断撮像の側面の大半を構成する５種のモダリティとして、従来のＸ線撮像、計算機式断層写真法（ＣＴ）三次元走査、超音波手技、マンモグラム及び磁気共鳴撮像走査が含まれ得る。同様に、診療の侵襲的な側面を構成する相対的に少数の手技も存在し得る。典型的な診断撮像診療については、各々の形式の撮像の職務は、患者の受け入れから診断及び報告に至るまでかなり十分に定義されている。これらの手技には予測される制約があり、また患者との実時間相互作用を含む手技の部分は限定されているので、患者中心型ワークフロー・システムの利用は、手技自体に中心を置くシステムよりも効率が低くなる場合がある。
【０００５】
米国バーモント州South Burlington所在のIDX Systems Corporationによって提供されているもののような公知の健康管理情報システム及び関連する解決策は、医療試験結果から保険情報にわたる情報の管理を扱っている。一つの特定的な例に注目すると、現代の医用画像管理システムは典型的には、放射線情報システム（ＲＩＳ）にインタフェイスを介して結合された画像保管及び通信システム（ＰＡＣＳ）から成っている。ＰＡＣＳシステムは一般的には、患者についての人口統計的データ、指示（オーダ）データ、及び結果データが単一のＲＩＳによって管理されているようにして具現化されている。インタフェイスは、ＰＡＣＳがＲＩＳによって送信される未承諾（unsolicited）インタフェイス・トランザクションを介して患者についての人口統計的データ、検査指示データ、及び検査結果データを受け取るように構成されている。この具現化形態は、下記の予期される標準的なワークフローを扱うように設計されている。
【０００６】
・利用者が患者についての人口統計的データをＲＩＳに入力する。患者についての人口統計的データの必須部分は、患者を識別するのに用いられる一意の患者ＩＤである。
【０００７】
・ＲＩＳは、患者ＩＤを含めて患者についての人口統計的データを含むインタフェイス・トランザクションをＰＡＣＳへ送る。
【０００８】
・ＰＡＣＳは、ＲＩＳからトランザクションを受け取って、患者についての人口統計的データをＰＡＣＳデータベースに記憶させる。
【０００９】
・利用者は、ＲＩＳにおいてこの患者についての検査を指示し又は予定する。ＲＩＳは、検査を一意に識別するのに用いられる受付番号を作成する。
【００１０】
・ＲＩＳは、患者ＩＤを含めた患者についての人口統計的データと受付番号を含めた検査指示情報との両方を含むインタフェイス・トランザクションをＰＡＣＳへ送る。
【００１１】
・ＰＡＣＳは、ＲＩＳからトランザクションを受け取って、検査指示情報をＰＡＣＳデータベースに記憶させる。ＰＡＣＳは、インタフェイス・トランザクションに与えられている患者ＩＤを用いて、この検査を正しい患者に結び付ける。
【００１２】
・利用者は、撮像モダリティを用いて患者の検査を実行する。撮像モダリティが患者及び検査についての人口統計的データのダウンロードのための方法をサポートしている場合には、モダリティはＲＩＳから直接人口統計的データを受け取る。他の場合には、利用者は、少なくとも患者ＩＤ及び受付番号を含む患者についての人口統計的データ及び検査データを、撮像モダリティによって与えられているユーザ・インタフェイスに入力する。
【００１３】
・撮像モダリティは医用画像を取得して、検査内容（すなわち画像及び関連情報）に患者についての人口統計的データ及び検査データを添えてＰＡＣＳへ送る。
【００１４】
・ＰＡＣＳは検査内容を受け取って、画像ヘッダから患者についての人口統計的情報及び検査情報を抽出し、患者ＩＤ及び受付番号を用いて、検査内容をＰＡＣＳデータベースに予めファイルされている情報と突き合わせる。ＰＡＣＳの利用者はこの時点で、この検査についての画像を見ることができる。検査内容（study）は検査（exam）と照合されているため、利用者はこの正確な情報を用いて患者の記録にアクセスすることができる。
【００１５】
・利用者は、検査が行なわれたことを示すために情報をＲＩＳに手入力する。ＲＩＳの利用者はこの時点で、この患者についての検査が実行されて完了したことを知ることができる。ＲＩＳにおける検査のステータスは、検査の解釈の準備ができたことを反映したものとなる。
【特許文献１】米国特許第５，９７４，３８９号
【発明の開示】
【発明が解決しようとする課題】
【００１６】
しばしば、ＰＡＣＳ及び他の医用画像管理システムを有する実世界の健康管理施設は、内部ソース及び外部ソースの両方からデータを受け取る。内部データ・ソースは、医用画像管理システムを運用している健康管理施設によって所有され且つ／又は管理されているＲＩＳ及び他の情報システムを含む。外部データ・ソースは一般的には、異なる健康管理施設によって所有され且つ／又は管理されている撮像設備及び他の情報システムを含む。一般的には、異なる健康管理施設は患者及び検査を識別するために異なる番号付け方式を用いる。従って、外部ソースから受け取ったデータは一般的には、内部ソースによって与えられるデータに直接には対応しない。
【００１７】
例えば、患者は、地域の医療センターで行なわれている幾つかの放射線検査を受けることができ、このセンターの医師が検査を解釈する。医療センターにある医用画像管理システムは、この患者についての人口統計的情報、検査情報、及び医用画像の全てを有している。患者が引き続き、上述の医療センター以外の実体によって所有され且つ／又は管理されている町の診療所で行なわれている放射線検査を受けたが上述の医療センターの放射線科医によって画像を解釈してもらうことを必要とする場合には、画像は医療センターに電子的に転送される。画像が診療所の画像管理システムから医療センターの画像管理システムへ転送されるときに、画像における患者の識別子及び検査情報が医療センターの画像管理システム内のデータに対応しないことがありがちである。従って、画像が関連している患者を決定することは困難であり、センターの画像管理システムに誤りが混入する虞がある。
【００１８】
この論点に対する一つの既存のアプローチは、センター側のシステムが、ソースを問わず画像を無差別的に受け入れて、全てのデータを有効であるものとして提示するものである。これにより、問題の目立ち易さは解消する。しかしながら、この方式では、システムの利用者に十分な知識がなく利用者は全てのデータが有効であると想定するか、又はデータが不正確であるかも知れないことを利用者が理解している場合には利用者は全てのデータを疑わしいと想定してこのことを確認するのに余分な時間を取られるかのいずれかとなるため、問題を生ずる。全てのデータが有効であると利用者が想定するという最初の例では、医療ミスの危険性が大きくなる。最悪の例のシナリオでは、一組の画像についてＰＡＣＳにおいて不正確な情報が表示されると、診断の遅れ又は場合によっては正しい患者の診断及び治療の欠如が生じ得る。データが正確であることを照合して確認するために利用者が余分な時間を取られる第二の例では、患者治療の遅れが生ずる。
【００１９】
上述の論点に対処する第二のアプローチは、ＰＡＣＳに到着した画像の組でＰＡＣＳデータベースにおいて患者及び／又は検査と照合の取れないものがあったら、かかる画像の組を全て「壊れた」検査内容として扱うものである。ＰＡＣＳは一般的には、ある検査内容をＰＡＣＳデータベースに既に存在する患者及び検査と突き合わせるか、又は患者レコード及び検査レコードを手動で作成し、次いで、検査内容を新たに作成された検査と照合するかのいずれかにより、これらの「壊れた」検査内容を修繕するシステム管理者のための機能を供給している。この場合には、人間の利用者がシステムと対話して一致を確認するので、第一のアプローチよりも不正確なデータを生ずる危険性が遥かに少ない。しかしながら、「壊れた」検査内容を解消する工程は通常の工程とは切り離されているため、生産性が低下し、また「壊れた」検査内容を有する患者の診断の遅れ及び必要治療の遅れが生ずる。ここでも、最悪の場合には、この遅れによって患者の死亡を招く可能性がある。
【００２０】
上述の論点に対処する第三のアプローチは、ＰＡＣＳが、自身が接続されているＲＩＳによって管理されている既知のソースからの画像を専ら受け取るように制限されるようなＰＡＣＳを具現化するものである。顧客が、ＰＡＣＳには接続されていないＲＩＳによって管理されるソースから画像を取得することを望む場合には、顧客はこの新たなソースから顧客のＲＩＳへデータを変換するか、又は両方の情報システムにデータを手入力するかのいずれかを行なわなければならない。この解決策は、最も正確な患者情報を提供するが、実用的でなく、変換を行なう場合には極めて高経費である。
【００２１】
健康管理情報システムは多くの場合にはスタンド・アロン型でなく好ましくは相互接続されていることを認めた上で、一方のシステムから他方のシステムへの情報の転送を容易にする幾つかの試みが為されている。例えば、１９８７年に、Health Level Seven（ＨＬ７）として知られる試みが始められて、健康管理環境での電子的情報の交換のための一連の標準を結果として得た。ＨＬ７プロトコルは、病院情報システム、臨床研究所システム、及び薬局のような多様な利用者が各々にとって最も有用な態様で情報を交換することを可能にする。
【００２２】
しかしながら、上述のように、外部ソースから、又は可能性としては内部ソースからでも、施設に到着する全ての情報がＨＬ７又は他の標準に準拠している訳ではない。これらの状況では、一つのソースからの患者データがもう一つのソースからの患者データと完全には一致しないような場合に後の利用に備えて情報を適宜照合することは、困難でもあり時間浪費的でもある。この問題に対する従来の解決策は、完全に手動であるか何らかの電子的な簡便的手法を用いるかを問わず、かかる「壊れた検査内容」の例外処理、又はかかる検査内容を特殊なインタフェイス又は照合の仕組みに回送する類似の手法を含むものであった。例えば、AGFAが販売しているPACS Broker製品は、ＰＡＣＳ情報を放射線情報システム（ＲＩＳ）の情報にリンクする仕組みを含んでいる。患者情報の不一致は本質的には、壊れた検査内容用の特別な「バケツ」にファイルされる。
【００２３】
この一つの例のみについて説明を続けると、現在公知のシステムのいずれも、多様なソースからの患者情報の冗長性を十分に活用するようにかかる壊れた検査内容を適当に処理することができないため、非効率が生じている。従って、この例では、既存の相互交換規格に全てが準拠している訳ではないような多様な非標準的ソースからの電子的な患者情報の交換をより実効的に扱う方法が必要とされている。
【００２４】
さらに一般的には、行なわれている医療手技に最も関連の深い角度からワークフローを扱うことにより、施療者の生産性を高める必要がある。幾つかの例では、患者中心型ワークフロー分析を維持する方が依然として好ましい場合もある。しかしながら、手技療法は一般的になりつつあるため、特定の患者についての情報の視点ではなく、行なわれるべき手技に関連する情報の視点に基づいてワークフローを扱う方が一般的になるであろう。
【００２５】
幾つかの公知の解決策は、全ワークフローのうち一つの手技に関連する小部分を扱うものであって、例えば米国フロリダ州Melbourne所在のWitt Biomedical Corporation及び米国コネチカット州Fairfield所在のGeneral Electric (GE) Corporationから販売されている血流力学システム等がある。
【００２６】
Witt Biomedical Corporation及びGE Corporationは、心臓手技の検査室内（in-lab）部分を扱っているが、検査室前（pre-lab）及び検査室後（post-lab）の手技ステップは扱っていない。しかしながら、全体的な手技療法ワークフロー生産性を高める試み、又は特定の手技に関連するワークフロー要素の集合を包括的に扱う試みを行なっている解決策も知られていない。例えば、患者中心型である公知のシステムは典型的には、手技の最終的な結果にのみ着目して、手技自体には着目しておらず、従って、手技から利用可能になるデータ全てを獲得する訳ではない。これらのシステムは、患者人口の全体にわたって手技を監視することにより利用可能となるデータ・マイニングも、結果として生成され得る傾向統計も扱わない。これらのシステムは、手技特定的な医師及びスタッフの効率を典型的に扱っている訳ではない。というのは、やはりこれらのような論点は大抵、例えば診察室から病院側で生成された手技関連情報へのアクセスを容易にするという論点のように単一患者のデータを遥かに超えて広がっているからである。
【００２７】
施療経費を削減しつつ同時に臨床的治療成果を改善するという目標のために、医療提供者施設の大半は、幾つかの核となる臨床システムすなわちＣＰＯＥ、薬学、医療指針／決定支援、多診療科にわたる文書化、並びに取られる全ての行為及び関連する結果の集中保管のための臨床情報の貯蔵庫を具現化することに注目している。制御された医療語彙や、またある程度までは文書撮像も、これら核となるシステムを横断してさらに広範でシームレスな把握像を可能にする支援技術となる。現状の考え方では、差し当たり何かを購入する施設は、ＡＤＴ及びマスタ人名索引能力を含めたこれら核となるシステムを単一のベンダーから購買する。
【００２８】
経費を削減しつつ治療成果を改善するという目標を達成するために、例えば所与の患者人口について広範で長期的な臨床履歴（胎児期から死ぬまでの）を提供し得るようにする等のように、これら核となるシステムを本質的に「企業化」することが有利である。この目的のために、これらのシステムは、極めて広範な基盤を持ち、あらゆる医学的な専門的特性（スペシャルティ）に対応し、施設の実質的にあらゆる点からアクセス可能であるべきである。これら核となるシステムは、入院患者との接触及び外来患者との接触の両方をカバーすることができ、範囲外の非所有の実体への業務を提供するときには組織境界横断的であるべきである（企業間取引能力）。これらの「企業的」システムを開発して配備することは、ベンダー及び消費者の双方にとって重要な仕事である。
【００２９】
健康管理施設がこれらの全包含的な「企業的」解決策を具現化しようと試みるのと同時に、手技に基づく療法の成長も爆発的になっている。この手技療法の成長は、医療技術の進歩、専門のさらなる細分化の進行、並びに世界的な人口成長及び「アメリカのたそがれ（graying of America）」による需要の高まりによって拍車がかかっている。医療技術の発展は、新たな診断用手技及び／又は侵襲型手技の数の増大を齎した。殆ど全ての手技に基づく療法は医用撮像に大きく頼っており、この領域での効率の必要性が強調されている。
【課題を解決するための手段】
【００３０】
本発明によれば、手技療法ワークフロー・システムが、医療手技の各々の段階に必要な医療データを収集し、フィルタ処理して、適当な施療者に対して適当な時刻に配布する。
【００３１】
この手技療法ワークフロー・システムは、データ管理サブシステムと、手技スパン・サブシステムと、作業組織化サブシステムと、実務管理サブシステムとを含んでいる。データ管理サブシステムは一つの診療科の範囲内で患者治療を実行し、管理して測定するのに必要なデータを獲得する。
【００３２】
手技スパン・サブシステムは、特定の医療手技のライフサイクルの全体の管理をカバーする構成要素を含んでいる。手技スパン・サブシステムは、保険情報、医療指示及び履歴を獲得して、最終的には診察室に結果を返す。
【００３３】
作業組織化サブシステムは、専門医及びスタッフの特定の必要に応えるように異質なソースから収集されたデータを特別調整することにより、一つの手技の全体にわたって様々な専門医及びスタッフの様々な必要に対処する。作業組織化サブシステムは、データ管理サブシステムからデータの部分集合を採取して、手技の適当な点において、この時刻にかかるデータを必要とする専門医に最も適した態様でデータを提示する。
【００３４】
実務管理サブシステムは、スループット及び患者の診療成果の両方の最適化を容易にするように、特定の手技に対応する専門診療科の実務的側面及び患者治療的側面を監視して測定する構成要素を含んでいる。
【００３５】
本発明によれば、手技療法ワークフロー・システムは、リソースの継続的な監視及び再割り当てを介して手技型診療科のスループットを最適化し、手技型診療科の効率を管理する。
【００３６】
さらに、本発明によれば、手技療法ワークフローは、自身の構成要素を管理して、多数の専門的特性による診療環境を横断して、様々なワークフローのためにかかる構成要素の再利用を容易にする。
【００３７】
この概要及び下記の詳細な説明に記載した特徴及び利点は全包含である訳ではない。多くの付加的な特徴及び利点は、図面、明細書、及び特許請求の範囲を考慮すれば当業者には明らかとなろう。さらに、本開示において用いられる言語は主に、読み易さ及び教示の目的で選択されており、発明の主題を限定したり画定したりするために選択されたものではなく、かかる発明の主題を決定するためには特許請求の範囲を頼る必要があることを特記しておく。
【発明を実施するための最良の形態】
【００３８】
各図面は、説明のみの目的で本発明の一実施形態を図示している。当業者は、以下の記載から、本書に記載した本発明の原理から逸脱することなく、本書に示す構造及び方法の代替的な実施形態を採用し得ることを容易に認められよう。
【００３９】
好適実施形態と関連して本発明を説明するが、本発明をこれらの実施形態に限定することを意図しないものと理解されたい。反対に、特許請求の範囲によって画定される本発明の要旨及び範囲内に含まれ得る全ての代替構成、改変及び均等構成を網羅するものとする。
【００４０】
図１は、本発明の一実施形態による手技療法ワークフロー・システム１００を示す高レベル・ブロック図である。システム１００は、病院業務系統の臨床的治療成果及び実務効率を監視して改善する単一の機構を与えるウェブ型ソフトウェア・システムとして具現化される。以下の議論は、放射線医学に焦点を当てるが、当業者には類似のアプローチが他の手技療法診療分野に同等に適用可能であることが認められよう。
【００４１】
システム１００では、ワークフローを「手技中心型」の視点から扱うため、手技を実行するのに必要とされる様々なリソースにとって、手技が必要とされる時刻にリソースが必要とする情報が直ちに利用可能になる。
【００４２】
本発明の一実施形態によれば、システム１００の主な機能的構成要素は、データ管理サブシステム１０１、手技スパン・サブシステム１０２、作業組織化サブシステム１０３、及び実務管理サブシステム１０４である。
【００４３】
データ管理サブシステム１０１は、一つの診療科の範囲内で患者治療を実行し、管理して測定するのに必要とされる詳細なデータを獲得する。一実施形態では、サブシステム１０１は、ディジタル画像取得及び表示、医用装置統合、電子カルテ統合、走査書類、並びに構造化型臨床データ収集を含んでいる。これらの構成要素の各々からのデータは、従来と同様に収集されて、サブシステム１０１によって後述するようにして管理される。
【００４４】
手技スパン・サブシステム１０２は、特定の医療手技のライフサイクルの全体の管理をカバーする構成要素を含んでいる。一実施形態では、このカバー範囲は、保険、指示及び履歴のような情報に関わる診察室からのデータ獲得を含み、予定及び追跡のような診療科内部での効率化に続き、最終的には診察室に結果を返す。
【００４５】
作業組織化サブシステム１０３は、専門医及びスタッフの特定の必要に応えるように異質なソースから収集されたデータを特別調整することにより、一つの手技の全体にわたって様々な専門医及びスタッフの様々な必要に対処する。このように、このサブシステムは、データ管理サブシステム１０１からデータの部分集合を採取して、手技の適当な点において、この時刻にかかるデータを必要とする専門医に最も適した態様でデータを提示する。
【００４６】
実務管理サブシステム１０４は、スループット及び患者の治療成果の両方の最適化を容易にするように、特定の手技に対応する専門診療科の実務的側面及び患者治療的側面を監視して測定する構成要素を含んでいる。
【００４７】
本発明の一実施形態によれば、システム１００は医用装置１１０及び外部情報システム１１１と統合されている。好適実施形態では、IDX Systems Corporationによって提供されている業務（サービス）指向型アーキテクチャ（ＳＯＡ）技術のように異質なアプリケーション間での通信を可能にする一組の標準的なウェブ・サービスを用いてこの統合を達成する。代替的な実施形態では、システム１００と共に用いられる他の統合機構としては、関係する特定の手技及びかかる手技について普及している健康管理業界標準に依存して、ＤＩＣＯＭ、ＨＬ７、ＨＴＴＰ及びＸ１２のようなメッセージ交換標準等がある。
【００４８】
図２を参照して述べると、一実施形態によれば、システム１００は、ウェブ型アプリケーション構造２１０をｎ階層のアーキテクチャとして用いて具現化される。明確に述べると、アプリケーション構造２１０は、５種の撮像関連の専門的特性すなわちＲＩＳ（放射線診療）２２０、ＣＶＩＳ（心臓診療）２３０、ＰＡＣＳ（画像保管）２４０、Imaging Suite（米国バーモント州South Burlington所在のIDX Systems Corporationから販売されている医用撮像管理システム）２５０、及び「専門的特性Ｃ」（病院又は他の診療によって必要とされ得るような将来の専門的特性のための付加的な側面に対する総称的参照）２６０を扱う。これらの専門的特性の各々が自身の特化構成要素（２２１、２３１、２４１、２５１及び２６１）並びに拡張部（２２２、２３２、２４２、２５２及び２６２）を有している。例えば、構成要素２２１はマンモグラフィ手技についての追跡及び報告のための機能を含んでおり、これらの機能は、他の専門的特性によって用いられることはない。構成要素２３２は、心カテ室（心臓カテーテル室）の認証に特定的に必要とされるデータ要素を獲得する機能を含んでいる。構成要素２２２は、アンジオグラフィ検査のために類似のデータ収集方法論を用いる。当業者は、構成要素２２２のデータ要素自体が専門的特性に特定的であることを理解されよう。
【００４９】
これらの専門的特性の全てに共有されているのが共通ワークフローの発行であり、ワークフロー・イネーブラ２７０によって扱われる。好適実施形態では、これらのワークフロー・イネーブラ２７０としては、手技予定のような共通実務構成要素２７１、実務構成要素によって用いられるデータ・スキーマである共通実務実体２７２、並びにシステム１００内のセキュリティ及びナビゲーションのような大域的なタスクを扱う構成要素２７３がある。一つの特定的な例として、患者中心型システムは典型的には、組織レベルでロール・ベース型（役割に基づく）セキュリティをサポートしている（例えばシステムを用いて実行されるべき様々なタスクのための許可を与える）。しかしながら、多数の専門的特性が同じ情報システムを用いている場合には、かかるセキュリティは十分にきめ細かい（granular）とは言えない。例えば、心臓カテーテル室の技師にマンモグラフィ検査に関連するデータを編集する能力がある必要はない。好適実施形態では、構成要素２７３はかかるロール・ベース型セキュリティを提供する。
【００５０】
図２には示していない他のイネーブラ２７０も、共通ワークフロー構成要素すなわち一つの手技のために開発されたものであるが他の手技についてのワークフローでも再利用され得る構成要素や、ワークフロー管理用の「ツールキット」として提供されている基本構成要素である基礎実務／ワークフロー構成要素、並びに本書に記載しているような様々なロール（役割）、組織及び人々の間での対応を確立するのに用いられる共通統合構成要素を含んでいる。
【００５１】
ワークフロー・イネーブラ２７０は、様々なデータ・ソース２８０と連絡しており、これらのデータ・ソース２８０は、既存のデータベース２８１、ファイル・システム・データ２８２、並びに他のシステムに接続するウェブ・サービス及び外部システムへの他形式のインタフェイスのような外部ソース２８３に分類され得る。
【００５２】
図３に移り、同図には本発明による手技中心型ワークフロー管理の一例が示されている。この例は、専門医３３０、電子カルテ（ＥＭＲ）又は他の外部患者情報システム３３１、紹介医３３２、地方の健康管理施設３３３、及び関心のある特定の手技に対応する適当な装置３３４（例えばモダリティ）を含むワークフローを管理している。この例では、専門医のワークフローは、患者履歴を獲得／閲覧すること３１１を含んでおり、この獲得／閲覧３１１自体が、以前の手技を閲覧し３１２、以前のディジタル画像を閲覧し３１３、ＥＭＲ３３１と連絡して問題リストを閲覧し３１４、ＥＭＲ３３１と連絡して患者の身体的情報及び履歴情報を獲得／閲覧し、ＥＭＲ３３１と連絡して検査室の結果を閲覧することを伴っている。このワークフローはさらに、ＥＭＲ３３１と連絡して追跡調査指示を獲得すること３１７を含んでいる。加えて、このワークフローはまた、手技結果３１９及び手技の間に得られた対応するデータ３２０を獲得すること、並びに紹介医３３２及び地方の施設３３３と連絡してかかるデータを配布すること３２１を含んでいる。最後に、外部装置３３４と連絡して、専門医３３０は手技からの獲得データを受け取り３１９、ディジタル画像を閲覧／解釈する３２０。本書に記載するようなワークフロー管理は、異なるタイプの施療者であるか又は異なるタイプの患者であるかを問わず、ワークフローに関わる人々の様々な役割の認識を含んでいる。このように、管理されている全範囲のワークフローが増大しても、利用者は、利用者の現在の必要性のコンテクストとは無関係な情報については提示されない。例えば、ストレス・エコーを読み取っている心エコー医は、侵襲型心臓診療の特徴については、かかる特徴が利用可能であったとしても提示される必要がない場合がある。
【００５３】
好適実施形態では、システム１００は、幾つかの異なるモードでの動作について構成設定自在である。システム１００は、スタンド・アロン型診療科別システムとしての利用のために構成設定自在である。また、システム１００は、例えば病院の方針を、この病院において手技を実行している医師グループの方針と共に考慮に入れることを可能にし、又は病院内部の異なる専門的特性の方針を扱うことを可能にするような第三者ポータル及びフレームワークに統合された診療科別システムとしての利用のためにも構成設定自在である。システム１００の一つの具現化形態では、診断報告及び専門医の請求書に、手技が実行された病院のみに必ずしも限らず担当医が所属している医療提供者グループのロゴ及び住所を反映させる。かかる統合は、多数の健康管理業務系統をカバーする第三者ポータル及びフレームワークにまでさらに拡張することができる。システム１００のもう一つの構成は、多数の健康管理業務系統をカバーするスタンド・アロン型の企業型アプリケーションのようなものである。
【００５４】
システム１００は「手技」を従来の「検査」と区別するように構成されていることを特記しておく。公知のシステムは後者に焦点を合わせており、主に、実行されている単一の試験を結果の報告を従えつつ含んでいる。一方、手技はさらに一般化されており、病気を治療し又は診断するために生じ、次いで多数の結果を生成することができる一連のステップを含んでいる。従って、検査は、単一のステップのみを有する手技の最も単純なものであると看做され得る。本書に記載しているようなさらに一般化された手技をサポートすることにより、例えば放射線診療及び心臓診療ＩＨＥプロファイル、ＳＰＳ／ＭＰＳＳ及び専門的特性の予定（スタッフ及びリソースの予定）に関する典型的なワークフローをさらに完全に扱うことができる。
【００５５】
単純な手技でも患者来診の概念とは異なっている。例えば、患者が侵襲型心臓カテーテル法を受けており、且つ血管内超音波を実行する必要がある場合には、いずれの診療科がこの設備を所有しているかに応じて、また担当医の信任に応じて、心臓カテーテル法とは別個に超音波の結果を出して超音波の請求をする必要がある場合がある。システム１００は、かかる超音波を従来の態様のように新たな患者来診として別個に扱うのではなく、治療の一こまと看做してカテーテル法と関連付けた状態に保つように構成されている。かかる関連付けを保つことにより、システム１００は無関係に見えるが実際には関係している情報の冗長な蓄積を回避する。システム１００は、各手技での対応を保つことにより、利用者が、特定の患者について特定の手技に投入された全てのステップについて他所参照を行ない詳細を得ることを可能にする。さらに、かかる関連付けを記帳することにより、システム１００は、対応するリソースが一つの診療グループからのものであるか又は複数の異なる診療グループからのものであるかを問わず、手技の任意の所要部分についてドラッグ・アンド・ドロップ方式で予定及び職務割り当てを行なうことができる。
【００５６】
図４には、システム１００が如何に動作して異質な報告ツール４２０、４３０、４４０を医用画像管理システム（例えば米国バーモント州South Burlington所在のIDX Systems Corporationによって提供されているImagecastシステム）４５０に統合するかを示す機能ブロック図が掲げられている。心臓医４１１、放射線科医４１２又は他の専門医４１３のような専門医療提供者が全て、患者の初期担当医４１４と連絡して、患者治療を提供する。様々な専門的特性は典型的には、手技所見を獲得して対応する報告を作成する専門的特性自体の報告ツール、例えば４２０、４３０及び４４０を有する。本書に記載しているように、システム１００は、利用者（この例では医師４１４）が患者又は手技を識別し４５１、画像管理システム４５０を介してかかる様々な報告ツール４２０、４３０及び４４０を結合して協働させることを可能にする。明確に述べると、システム１００は画像管理システム４５０を介して、ツール４２０、４３０、４４０によって作成された報告書を、共通語彙に写像（マッピング）し４５３、共通語彙を管理者４１５によって管理する（必要に応じて更新し又は改訂する）４５２ことを可能にし、請求コード及び手技コードの割り当て４５４を容易にし、品質又は実務分析者４１６が、臨床的治療成果についての報告（例えば傾向報告、効率報告）について作業してかかる報告を生成する４５５ことを可能にして、患者手技の全体的な改善を図る。
【００５７】
図５を参照して述べると、同図には、本発明によるワークフロー処理のための処理系列が示されている。この例では、二人の施療者すなわち医師５１１及び分析者５１２が関わっている。図５では、前述の各実体が最上部を横断して列挙されている。各々の実体の下方では、縦線が時間の経過を表わしている。縦線の間の横向きの矢印は、関連する実体同士の間のトランザクションを表わしている。尚、全てのトランザクションが図５に示されている訳ではないことを特記しておく。本発明の他の実施形態では、トランザクションの順序は変化してよい。
【００５８】
段階５２０では、システム１００は、医師５１１が関心のある患者／手技を識別して５３１、臨床所見の入力又は編集を開始する５３４ことを可能にする。段階５２２では、患者又は手技が識別されたら、システム１００は手技調査５１３を引き受け、この調査５１３に基づいて患者情報と連絡して５３２既存の所見を要求する５３３。段階５２３では、患者情報にアクセスして臨床所見が入力／編集されたら、報告ツール５１４は所見の通信を開始する。段階５２４では、所見の要求が処理されて５２３所見が連絡された５３５後に、語彙写像器５１５がツール特定的な所見を報告ツール５１４に返す。一旦、語彙写像器５１５は、自分が必要とする情報を有したら、既存の所見を検索して５３６、所見を共通語彙としてデータ記憶庫５１６に記憶させる５３７。段階５２１に戻り、分析者５１２はデータ分析報告を要求し５３８、段階５２６では、データ分析ツール５１７がデータ記憶庫５１６からかかる情報を要求することができ５４３、共通所見データが返され５３９、書式を整えたデータ報告が分析者５１２に返される５４４。
【００５９】
システム１００は、従来のＰＡＣＳのものに幾分類似したグラフィック・ユーザ・インタフェイスを設けているが、画像に専ら関連した利用者選択に限定されているのではなく、利用者は、特定の手技の様々な側面を選択することができ、例えば特定の患者についての手技の一部の詳細について「掘り下げる」ことができる。ここで図１４を参照すると、同図は、システム１００の利用者に対し、利用者自身のワークリストを構成設定して所望に応じて情報をフィルタ処理する能力を与えるユーザ・インタフェイスを設けている。図１４に示すように、利用者は、検査ステータス１４１０、報告ステータス１４２０、医療提供者１４３０、患者ステータス１４４０、組織１４５０、検査コード１４６０、リソース１４７０、及び検査範疇１４８０の各選択規準を選択することができる。例えば、図１４では、利用者がワークリスト「心カテ室」１４０５を構成設定している。このワークリストでは、利用者は、全検査ステータス１４１０、全報告ステータス１４２０、組織１４５０として「心臓センター」、並びに検査範疇１４８０について「カテ」、「末梢カテ」及び「成人カテ」を選択している。
【００６０】
図１５に移ると、ワークリストに表示される欄を利用者が選択することを可能にするユーザ・インタフェイスが示されている。図１５では、利用者は、患者氏名１５１０、受付番号１５２０、検査説明１５３０、検査日時１５４０、要求者１５５０、検査ステータス１５６０、及び組織１５７０を表示したい欄として選択している。
【００６１】
一旦、利用者が自分の選択規準を与えたら、システム１００はワークリストを生成する。図１６には、例えば２００５年１０月１９日から２００５年１１月１７日までの期間の心カテ室での行為の全報告を利用者が見ることを可能にする利用者作成のワークリストが掲げられている。このワークリストは、利用者によって選択された選択規準に基づいて作成されている。
【００６２】
システム１００は利用者に対し、チェックリスト、評価及びログ生成等を含めたインタフェイスを、所与の手技について要求されるように提供する。このインタフェイスはさらに、専門医が本日何の作業を行なうかを示しており、ここでも各々の選択がシステム１００からの詳細との対応を含んでいる。
【００６３】
以下では、システム１００の動作のさらに特定的な例に移り、システム１００の機能の幾つかの範疇について説明する。
《ワークフロー管理》
上で述べたように、システム１００の動作の基本的な側面は、手技療法に関連したワークフローの管理にある。任意の所与の医療手技において実行されるべき下位職務は手技間で異なっているが、以下に列挙する例は一般的な手技の多くの典型的な下位職務を扱っている。
（診断報告／文書所見を作成する）
手技療法において最も一般的な職務の一つは、手技の内容の文書化、並びに手技の出力（例えば画像）が診断及び／又は治療的視点から何を示しているかの解釈である。システム１００を用いた典型的なシナリオでは、システムは先ず、既に収集されている手技に関連する任意のデータを表示する。次いで、利用者は手技を実行することに関わるデータを入力する（手動で又は関連する医用装置との接続を介して）と共に修正して、システム１００が新たなデータを記録する。次いで、利用者はデータの要約又は解釈を入力し（ここでもキーボード入力から音声認識に到る任意の好都合な態様で）、これをシステムが記録する。次いで、良好な臨床診療に応じて、利用者は要約／解釈を確認し（例えばサインする）、システム１００が要約／解釈のテキスト表現を適宜配布する。
（口述を獲得する）
一般に、医師及び他の施療者は、手書きのメモ又はキーボード入力よりも口述によって患者情報を入力する方が遥かに簡便であると思っている。好適実施形態では、システム１００は、手技の内容及び手技時に取得された画像の解釈を口述を介して獲得すると施療者の現在のワークフロー診療に対して殆ど変更がない。利用者は先ず、たった今行なわれた手技又は利用者が画像で見ている手技を識別する。システム１００は応答して患者情報を確認する。すると、利用者は従来のディジタル記録サーキットリ及びソフトウェア（図示されていない）に話しかけることにより解釈及び所見を記録する。そして、システムは記録された情報を記憶して、後の検索及び認識／筆記に備える。代替的な実施形態では、システム１００は実時間で発話をテキストへ変換し、利用者が生成されたテキストの閲覧、修正及び確認を直ちに実行し得るようにテキストを表示し、この時点でシステム１００は元の音声録音に加えて又はその代わりに、生成されたテキストを記憶する。
（テキスト型所見を記録する）
幾つかの例では、良好な臨床診療は、施療者が口述でよりもテキスト形態で情報を入力することを必要とする。これらの状況では、システム１００は、手技の内容及び手技時に取得された画像の解釈をテキスト入力したものを獲得する。先ず、利用者は、解釈を与えている手技を識別する。システム１００は応答して患者情報を確認する。次いで、利用者はタイピングを介して解釈／所見を入力し、システム１００はかかる情報を記憶して後の検索に備える。利用者が施療者の口述の手動筆記を行なう筆記者であるような代替的な実施形態では、利用者は対応する音声ファイルを聴いて、この音声ファイルに基づいて適当な書写テキストを入力する。
（構造化型要素を入力／編集する）
一般に、施療者にとっては、コード化されたデータ集合を用いて手技の内容及び画像の解釈を記録することが望ましい。コード化されたデータを用いると実務生産性の向上が促され、経時的に、また一定範囲の施療者にわたって、報告の一貫性が得られるため、患者治療のレベルが向上する。システム１００はこの側面で、コード化された要素からのテキスト型報告の自動生成を介してワークフローを管理する。明確に述べると、利用者は、たった今行なわれた手技又は利用者が画像で見ている手技を識別する。システム１００は応答して患者画像を確認する。利用者は、コード化されたデータ要素に対して「ポイント・アンド・クリック」入力を用いて解釈／所見を記録する。システム１００は、コード化された要素を記憶して後の検索に備えると共に、選択された要素に基づいてテキスト型報告を生成する。
（診断報告／所見を配布する）
手技療法ワークフローにおいてもう一つの近普遍的職務は、要求を発した又は照会を求めている医療提供者に対する手技の結果（すなわち所見、解釈）の配布である。典型的には、この医療提供者はこれらの結果を用いてさらに詳細な診断を行なう。システム１００は、一旦、結果が判明したら、照会を求めている医療提供者を識別し、この医療提供者の報告受領の好ましい方法を決定し（例えば電子メール、印刷した報告書）、この好ましい方法によって報告を送信することにより、診断報告の配布を管理する。一旦、医療提供者が診断報告を読んだら、医療提供者は患者の治療の次の道筋を決定し（例えば追跡調査の予約を予定に入れる）、システム１００を介してこの事象をワークフローに入力することができる。
（やるべき作業を管理する（筆記））
多くの健康管理施設で蔓延している非効率性には、リソースが利用可能になったら作業を扱うことができるように、行なわれる必要がある作業を識別することが関わっている。一例として、典型的には、施設全体で手空きの筆記者の員数は限られており、この員数の効率は、筆記者が、自分がやるべき作業がある場所を知る簡便な方法が存在すれば最大化される。システム１００は、まだ筆記されていない音声ファイルの一覧を自動的に保つことにより、かかる効率性を促す。明確に述べると、システム１００は、テキスト型報告を有しない口述の一覧を表示する。利用者（すなわち筆記者）は、着手すべきこれらの口述から一つを選択する。すると、システム１００は、この項目が他の筆記者によって選択され得ないように、該当項目を使用中と標識する。次いで、システムは、関連する音声ファイルを再生して、上で「テキスト型報告を記録する」のワークフローの説明で述べたようにして筆記する。
《報告フレームワーク》
ワークフロー管理に加えて、システム１００は、医療手技に一般的に関連する様々な報告を容易にする報告フレームワークを提供している。以下、好適実施形態の幾つかの例について説明する。
（患者／手技を識別する）
考え得る実質的にあらゆる医療手技のためのワークフローは、関係する患者及び実行すべき特定の手技の両方を識別することを必要とする。好適実施形態では、システム１００は、利用者がさらに詳細なデータ入力又は情報閲覧の目的でかかる情報を効率的に呼び出すことを可能にする。以前の非計算機式システムでは、この行為は典型的には、患者ファイルの位置を突き止めて、これらのファイルを業務の適当な要求と結び付けることを求めていた。好適実施形態では、利用者、例えば医師が任意の利用可能な識別情報を入力し、システム１００が応答して可能な一致の一覧を与える。かかる識別情報としては、患者識別情報、手技情報（例えば当日の全ての未決のＭＲＩ要求の一覧）、及び特定の患者又は手技を識別するために利用可能なデータベースの内部をソートする助けになり得るその他情報がある。図６〜図１３に関して、患者情報のかかる自動生成のさらなる詳細を下記に掲げる。次いで、医師は、システム１００によって提示された一覧から適当な項目を選択し、システム１００は、選択された患者又は手技に関連する情報を表示することにより応答する。
（報告を作成する／所見を獲得する）
既存のシステムでは、当時点で必要とされている診断に関連する手技の結果のみを保持することが一般的である。例えば、心臓診療の目的での撮像は、心臓を巡る血流に関わる結果を生成することを意図されており、この結果が、手技の結果として報告される全情報であってよい。しかしながら、かかる撮像手技はまた、後の病気の診断のために将来用いられ得る他の詳細を付随的に獲得する場合がある。加えて、医療過誤の苦情に関わる懸念から、手技の結果のみに留まらず手技自体についてのさらに多くの情報を獲得することが望ましい場合がある。従って、システム１００は、手技結果及び手技内容の両方を獲得して連絡することを容易にする。好適実施形態では、特定の手技の効率及び施療者の選択設定に基づいてこの情報を獲得するための様々な機構が利用可能にされている。このように、利用者に最大の生産性を提供するツールを用いて、利用者は状況に応じて手技時に観察された所見又は手技時に取得された画像の解釈を獲得し、また治療のための推奨の要約を獲得する。一好適実施形態では、システム１００は利用者に対し、手技に関する現在の情報、例えば手技時に獲得された画像を提示する。利用者はこれらの画像を見て、システムは獲得され得る所見の構造オプションの数、撮像された血管の数、見出された閉塞の数、並びに各々の閉塞の大きさ及び重症度等を与える。次いで、利用者は、画像において識別された所見の解釈を獲得し、行為の計画に対する示唆を獲得する。ここで、この行為の計画は、追加の撮像手技を含んで、患者の問題をさらに詳細に定義してもよいし、又は薬剤のような手技方式以外の治療をさらに定義してもよい。これに応じて、システム１００は獲得されたデータをデータ管理サブシステム１０１へ連絡して、所望のワークフローに従って、照会を求めている医師に対する示唆される行為の計画の連絡、又は外部システム１１１での調剤指示の開始等を含めたさらなる処理に供する。手技が進行している間に用いられる代替的な実施形態では、利用者は、記憶及びさらなる連絡のために手技の様々な中間的ステップを獲得する。例えば、放射線科医は、マンモグラフィ又は超音波撮像の間に撮像の様々な段階を獲得して、身体の様々な部分が、これらの部分に病気が見つからなくても実際に撮像されていたことを証明することができる。もう一つの代替的な実施形態では、この獲得はまた、手技時に与えられる鎮静剤治療のような手技時に与えられる口頭指示に対する利用者による承認を含んでいる。
（共通語彙に写像する）
健康管理施設は健康管理関連情報を収集する様々な装置及びシステムを含むのが典型的である。残念ながら、かかる情報を共通のフォーマットで保持する普遍的な標準は現在用いられていない。一つの普及型標準に準拠した装置もあれば他の標準に準拠した装置もあり、またデータをベンダー専有のフォーマットで保持する装置もある。従って、共通ワークフロー動作は、異質な非互換的ソースから収集されたデータを採取して、かかるデータを共通フォーマットへ変換する。好適実施形態では、システム１００は、所見データを連絡するような様々な報告ツールからデータを受け取って、かかるデータを、システム１００の全体で直接利用可能な一組の共通データ要素へ変換する。
（臨床的治療成果を報告する）
健康管理施設は、扱う手技について収集された臨床データを分析することにより、患者治療のレベル及び治療の全体的な効率の両方を高めることができる。この情報は、籍の登録、患者治療分析、傾向分析、組織の信用形成、及び他の研究のような様々な目的に利用することができる。好適実施形態では、システム１００は利用者（例えば品質分析者又は実務分析者）に対し、選択されるべき可能なデータ要素を表示する。次いで、利用者は、内容ばかりでなく提示のスタイル及び出力の書式も含めて所望の出力を整形する。次いで、システム１００は所望の内容についての必要に応じてデータ及び統計を編集し、次いで印刷し、又は他の場合には要求に応じてデータを提示する。
（請求コード／手技コードを割り当てる）
健康管理施設での料金請求過程を自動化し、またかかる施設での行為に対応するように手技コードを用いる多くのシステムが存在している。健康管理施設が幾つかのかかるシステムを動作させていることが一般的であり、手技によっては１よりも多いかかるシステムへの入力及びここからの出力を必要とする場合がある。従って、好適実施形態では、システム１００は、異質なシステムの間で請求コード獲得及び手技コード獲得を協働させて、請求コード及び手技コードの共通語彙への割り当てを容易にする。結果として、いずれのサブシステムが構造化型テキストを生成するかを問わず、一旦、任意の専有的データ要素が共通語彙に写像されたら、請求コード及び手技コードは透過的態様で手技と統合される。好適実施形態では、写像は、所望に応じて個々の共通語彙のデータ要素に対して行なわれるか、又は共通語彙のデータ要素の特定の組み合わせに対して行なわれる。特定的な一例として、システム１００は、一組の所見のいずれの共通データ要素に請求コード／手技コードが割り当てられているかを決定する。一実施形態では、システム１００は、収集されたデータ要素を、共通語彙モジュールによって構成設定されているデータ要素／請求コードの組み合わせと比較する。次いで、システム１００は、所見に存在する共通データ要素のいずれの組み合わせに請求コード／手技コードが割り当てられているかを判定する。次いで、システム１００は、割り当てられている請求コード／手技コードを手技の文書化に含める。
（共通語彙を管理する）
データ要素に共通語彙が望まれる場合、特に専有的臨床データ要素から共通語彙データ要素へ写像が行なわれる場合に、折に触れて健康管理施設は写像を更新する必要がある。システム１００は、構造化型報告ツールにおける専有的要素と共通語彙における要素との間の関係を定義し、共通語彙データ要素又は場合によっては要素集合と、請求コード及び手技コードとの間の関係を定義することにより、一つのワークフロー内で必要に応じて写像の変更を可能にする態様で上述のような更新を促進する。好適実施形態では、システム１００は、専有的データ要素及び共通語彙要素を表示して、利用者が、従来のグラフィック・ユーザ・インタフェイス機構を用いて対応する要素を共に結び付けることを可能にする。次いで、システム１００は、利用者が各々の共通の要素又は要素集合について手技コード又は請求コードを選択し、これらを共に結び付けることを可能にする。次いで、システム１００は、選択された結び付き／関係を上述の写像での利用のために記憶させる。好適実施形態では、管理者がシステム１００を白紙の状態から構成設定し始めるのではなく、必要に応じて単にシステム１００を修正すればよくするために、事前にシステム１００が既定の写像の集合の確立を可能にすることにより効率を達成する。代替的な実施形態では、専有的データ要素が写像器に送られて共通データ要素とは現在結び付けられていないときに、暫定的な関係を動的に作成する。この場合には、システム１００は利用者に対して写像されていない値を表示して、値が関係している共通データ要素を確認し又は選択するように利用者に促す。このときに、この関係は記憶されて後の照会に備える。この態様で、その場で関係を構築することができ、事前に管理する必要がなくなる。
【００６４】
構造化型データの写像のさらに詳細な説明に移る。現在、健康管理情報システムでは、構造化型臨床報告を行なう多くのベンダー及びツールが市場に存在している。各々のベンダーは一組の構造化型データ要素を開発しており、これらのデータ要素を用いて診断又は治療の結果を文書化することができる。幾つかの医療管理体は、特定の専門的特性についてのデータ要素の標準化に向かって努力している。しかしながら、この方法はしばしば、極めて時間浪費的である場合があり、また一つの専門的特性の内部でも衝突がある場合もあり、しかも専門的特性を横断して標準化を行ない合意を得る努力が必要とされる。従って、異質な構造化型臨床報告システムを横断してデータ及び医療結果を比較することを可能にするという問題は、予見可能な将来には論点となろう。
【００６５】
システム１００は、病院のスタッフが一定範囲の臨床報告ツールを利用し、しかも報告ツールを問わず臨床的治療成果を比較する能力を有することを可能にする。これにより、末端利用者が臨床領域及び／又は末端利用者のワークフローに最もよく適合する臨床報告ツールを選択することが可能になり、従って、利用者生産性及び患者治療が向上する。
【００６６】
システム１００は、同じ医療専門的特性の内部の異なる報告ツールからのデータ要素若しくは専門的特性に跨がる各ツールからのデータ要素、又はこれら両方を写像するように構成設定自在である。
【００６７】
市場に現在出回っている既存の構造化型臨床報告ツールの幾つかは、各ツールの専有的データ要素の包括型のコード集合への写像（例えばＳＮＯＭＥＤ）を提供している。これらのシステムは、最も細かいレベルで論点を解消することのみを期しており、健康管理施設によっては多数の構造化型臨床報告システムを有するとの事実を考慮していない。このシナリオでは、潜在的に同じ専門的特性の内部であっても互いに比較することができないような施設内部で収集された臨床データが依然存在することになる。
【００６８】
好適実施形態では、当業者には明らかなように、上述の機能の殆どは従来の態様で具現化されている。しかしながら、従来は具現化されていなかった一つの領域は、上述の患者関連データの自動生成である。従って、以下、この領域の好ましい具現化形態を詳細に説明する。明確に述べると、図６には、医用データベース・システム６００の好適実施形態を示す高レベル・ブロック図が示されている。システム６００は、様々なソースから様々な患者関連データを入力として取り入れる。単純化して分かり易くするために、本書では内部ソース６０１と呼ぶ幾つかのソースは、患者関連データを公知の標準化されたフォーマットで提供する。一例として、米国バーモント州South Burlington所在のIDX Systems Corporationによって製造されているIDXrad製品は、ＨＬ７  ＡＤＴプロトコルに準拠しており医用データベース・システム６００に用いられているものとネイティブで一致する患者データ・フィールドを含む患者識別情報を提供する。内部ソース６０１からの患者関連情報については、医用データベース・システム６００は、内部ソース６０１によって与えられたデータに関連する患者を直ちに且つ無条件に識別して、患者の記録、及び医用データベース・システムによって記憶されている他の関連情報を更新することができる。
【００６９】
医用データベース・システム６００はまた、医用データベース・システム６００に用いられているものと完全に一致する形態でかかるデータを提供することのできないような他のソースからの患者関連データも入力として受け入れるように構成されている。単純化して分かり易くするために、かかるソースを本書では外部ソース６０２と呼ぶ。一般に、外部ソース６０２からのデータは、何らかの患者関連データを含んでいるが、これらのデータは医用データベース・システム６００によって用いられる形態と完全に一致した形態になく、また患者の即座の何らかの識別を可能にするのに十分に完全でない場合がある。
【００７０】
医用データベース・システム６００にアクセスする健康管理人員にとって最も効率的なワークフローを提供するために、システムは、システムに既に存在する患者と一致し得ない外部ソース６０２から受け取ったデータに応答して患者関連データを自動的に生成するように構成されている。システム６００は好ましくは、能力の及ぶ限りで外部ソース６０２によって提供されたデータを解釈し、外部ソースから受け取ったデータに結び付けられる関連レコード及びフィールドを可能な範囲で自動生成して埋める。
【００７１】
一実施形態では、医用データベース・システム６００は、従来のコンピュータ・システムで実行される。図７は、一実施形態による医用データベース・システム６００として用いられるコンピュータ・システムの高レベル・ブロック図である。バス７０４に結合されている少なくとも１台のプロセッサ７０２が図示されている。また、バス７０４には、メモリ７０６、記憶装置７０８、キーボード７１０、グラフィックス・アダプタ７１２、ポインティング・デバイス７１４、及びネットワーク・アダプタ７１６が結合されている。また、グラフィックス・アダプタ７１２に表示器７１８が結合されている。
【００７２】
少なくとも１台のプロセッサ７０２は、INTELｘ８６又はPower PC互換型の中央処理ユニット（ＣＰＵ）のような任意の特定目的プロセッサ又は汎用プロセッサであってよい。記憶装置７０８は、多量のデータを保持することが可能な任意の装置であってよく、ハード・ドライブ、コンパクト・ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、ＤＶＤ、又は他の何らかの形態の固定型若しくは着脱自在型の記憶装置のようなものであってよい。メモリ７０６は、プロセッサ７０２によって用いられる命令及びデータを保持している。ポインティング・デバイス７１４は、マウス、トラック・ボール、ライト・ペン、指触型表示器、又は他の形式のポインティング・デバイスであってよく、キーボード７１０と共に用いられてコンピュータ・システム７００にデータを入力する。
【００７３】
ネットワーク・アダプタ７１６は、コンピュータ・システム７００を内部ソース６０１及び外部ソース６０２に結合する。一実施形態では、ネットワーク・アダプタ７１６はコンピュータ・システム７００を構内網及び／又は広域網に接続し、これらの網が次に内部ソース６０１及び／又は外部ソース６０２に接続する。ネットワーク・アダプタ７１６及びネットワークは、Ethernet（商標）、ＴＣＰ／ＩＰ、ＨＴＴＰ等のようなソース６０１、６０２と通信する任意の従来のネットワーク形成技術であってよい。もう一つの実施形態では、内部ソース６０１及び／又は外部ソース６０２は、ＩＥＥＥ１３９４FireWire接続、ユニバーサル・シリアル・バス（ＵＳＢ）接続、シリアル接続及び／又はパラレル接続のような様々な通信技術を介してコンピュータ・システム７００に接続される。さらにもう一つの実施形態では、ソース６０１、６０２と、医用データベース・システム６００として動作するコンピュータ・システム７００との間に直接的な通信が存在しない。その代わり、ソース６０１、６０２からのデータを、フレキシブル・ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、又は他の磁気メモリ、光学メモリ若しくは半導体メモリのような記憶媒体上で符号化して、次いで、物理的に輸送してコンピュータ・システム７００に挿入する。
【００７４】
医用データベース・システム６００に帰属される機能を提供するプログラム・モジュール７２０は好ましくは、記憶装置７０８に記憶され、メモリ６０６にロードされて、プロセッサ７０２によって実行される。代替的には、ハードウェア・モジュール又はソフトウェア・モジュールが、コンピュータ・システム７００内の他の場所に内蔵されていてもよい。本書で用いられる「モジュール」との用語は、モジュールに帰属される機能を提供するのに用いられるコンピュータ・プログラム・ロジックを指すものとする。
【００７５】
コンピュータ・システム７００の内部のハードウェア及びソフトウェアの形式は、医用データベース・システム６００の具現化形態に依存して様々であってよい。例えば、大容量型環境で動作する医用データベース・システム６００は、高い処理スループットを提供するためには多数のプロセッサ及びハード・ドライブ・サブシステムを有していてよく、また多数の同時的な利用者をサポートするためには多数の表示器及びキーボードを有していてよい。同様に、幾つかの実施形態が、システムの特定の能力に依存して、表示器７１８、キーボード７１０、及び／又はネットワーク・アダプタ７１６のような幾つかの構成要素を省略していてもよい。加えて、コンピュータ・システム７００は、画像を多様なフォーマットで表示する、利用者がシステム６００に安全にログ・インし得るようにする、及び管理能力をサポートする等のように本書に詳細には記載していない付加的な従来の機能をサポートしていてもよい。
【００７６】
図６に戻り、一実施形態では、医用データベース・システム６００は、外部ソース６０２から受け取った患者関連データを抽出する機能を果たす様々なサブシステムを含んでいる。これらのサブシステムとしては、比較サブシステム６０４、写像ツール・サブシステム６０６、自動生成サブシステム６０８、辞書サブシステム６１０、及び患者登録サブシステム６１２がある。一実施形態では、これらのサブシステムは、コンピュータ・システム７００上のモジュールとして具現化されている。
【００７７】
写像ツール・サブシステム６０６は、外部ソースからデータを受け取って、このデータを解釈し、写像して、変換し、次いで、比較サブシステム６０４及び自動生成サブシステム６０８を呼び出して、医用データベース・システム６００にデータを記憶させる。比較サブシステム６０４は、外部ソースからのデータに対応するレコードが既に存在しているか否かを判定して、存在しているならばレコードにデータを結び付ける。対応するレコードがまだ存在していない場合には、自動生成サブシステム６０８がレコードを生成して、受け取ったデータ及び他の既知の情報でデータ・フィールドを埋める。
【００７８】
一実施形態では、内部ソース６０１及び外部ソース６０２から供給されたデータは、病院情報システム（ＨＩＳ）、放射線情報システム（ＲＩＳ）、画像保管び通信システム（ＰＡＣＳ）、又は他のかかるシステムによって供給されるディジタル化された放射線画像を含んでいる。システム６００の他の実施形態は、放射線画像の代わりに又は放射線画像に加えて、他の医療関連データ（又は医療関連でないデータも）を受け入れることもできる。
【００７９】
一実施形態では、これらの画像は、画像のコンテクストを記述する付加的なディジタル・データを含み且つ／又はかかるデータを伴っている。一実施形態では、付加的なデータには、患者識別情報、医療提供者識別情報、及び／又は検査内容識別情報がある。これらのデータは、医療におけるディジタル通信（ＤＩＣＯＭ）プロトコル、Health Level Seven（ＨＬ７）プロトコル等を含めた多様なフォーマット及びプロトコルの１又は複数で符号化されていてよい。このデータはまた、入院／退院／転院（ＡＤＴ）メッセージ、指示（オーダ）メッセージ（ＯＲＭ）、結果メッセージ（ＯＲＵ）等を含めたＨＬ７又は他のプロトコルの１又は複数のメッセージを含んでいてもよい。分かり易くする目的で、これらの形態のデータの全てを本書では「患者関連データ」又は単に「患者データ」とも呼ぶ。尚、医用データベース・システム６００の機能は、任意の形式のデータに適用され得ることを理解されたい。このように、「患者関連データ」及び「患者データ」は、所載の機能が適用可能である任意の形式のデータを包含するものとする。
【００８０】
図８は、医用データベース・システム６００の一実施形態による写像ツール・サブシステム６０６の動作を示す流れ図である。当業者は、システム６００の代替的な実施形態が、図示のステップを異なる順序で実行したり、付加的なステップを実行したり、又は幾つかのステップを省いたりしてもよいことを認められよう。好適実施形態では、IDX Systems Corporationによって提供されているConnectR製品を用いて写像ツール・サブシステム６０６を具現化する。
【００８１】
写像ツール・サブシステム６０６は、外部ソース６０２からデータを受け取る８１０。一実施形態では、データは患者、医療提供者、及び／又は検査内容に関するものである。写像ツール・サブシステム６０６は一実施形態では、患者関連データが写像に着手するのに十分な情報を含んでいる否かについての閾値判定を行なう。含んでいない場合には、写像ツール・サブシステム６０６の一実施形態は、データを拒絶して例外を発生する（このステップは図示されていない）。写像ツール・サブシステム６０６は、入力データから患者、医療提供者、及び／又は検査内容に関連するデータを解釈し８１２、このデータを医用データベース・システム６００によって用いられる表現に写像する。一実施形態では、写像ツール・サブシステム６０６は、多様な表現及びフォーマットの多様な外部ソースからのデータを解釈し、写像して、変換する規則及びロジックを含む解釈エンジン６０７を含んでいる。解釈エンジン１０７は、これらの規則及びロジックを用いて、受け取ったデータを解釈し、次いで、このデータをシステム６００によって用いられる適当なレコード、フィールド、又は範疇に写像する。
【００８２】
解釈エンジン６０７はまた好ましくは、必要に応じてデータを受け取ったフォーマットからシステム６００によって用いられるフォーマットへ変換する８１２。例えば、外部ソース６０２からのデータが性別を整数値として表わしており（例えば０＝男、１＝女、２＝不明）、患者登録サブシステム６１２が性別を英数文字として表わしている（例えばｍ＝男、ｆ＝女、ｕ＝不明）場合には、写像ツール・サブシステム６０６はデータを第一のフォーマットから第二のフォーマットへ変換する。
【００８３】
写像ツール・サブシステム６０６は好ましくは、解釈、写像及び変換を施したデータに基づいて比較サブシステム６０４に対するアプリケーション・プログラミング・インタフェイス（ＡＰＩ）呼び出しを行なう８１４。一般的には、ＡＰＩ呼び出しは、辞書サブシステム６１０及び／又は患者登録６１２サブシステムの特性を、受け取ったデータを反映するように設定する。例えば、受け取ったデータが患者を記述している場合には、写像ツール・サブシステム１０６は比較サブシステム６０４に対してＡＰＩ呼び出しを行なって、受け取ったデータに応答して辞書サブシステム６１０及び／又は患者登録サブシステム６１２にレコード及び／又はフィールドを作成させ又は更新させる。一実施形態では、後の説明で比較サブシステム６０４及び自動生成サブシステム６０８に帰属されるロジックは、写像ツール・サブシステム６０６によって生成されるＡＰＩ呼び出しによって実行される。換言すると、写像ツール・サブシステム６０６はＡＰＩ呼び出しを行なって、比較サブシステム６０４及び自動生成サブシステム６０８に方法の各ステップ及び後述のその他ロジックを実行させる。
【００８４】
図６に示すように、比較サブシステムは好ましくは、三つのモジュール６１４、６１６、６１８を含んでいる。患者一致判定モジュール（ＰＭＭ）６１４は好ましくは、写像ツール・サブシステム６０６からＡＰＩ呼び出しにおいて受け取ったデータを患者登録サブシステム６１２における患者と一致させることを試みるために、患者識別情報を用いる。医療提供者一致判定モジュール（ＰＲＭＭ）６１６は好ましくは、ＡＰＩ呼び出しにおいて受け取ったデータを辞書サブシステム６１０において識別される医療提供者と一致させることを試みるために、医療提供者識別情報を用いる。検査内容一致判定モジュール（ＳＭＭ）６１８は好ましくは、ＡＰＩ呼び出しにおいて受け取ったデータを患者登録サブシステム６１２に記憶されている検査と一致させるために、検査内容識別情報を用いる。モジュール６１４、６１６、６１８が患者、医療提供者又は検査を識別することができれば、これらのモジュールはかかる項目をＡＰＩ呼び出しにおいて受け取ったデータで更新する。モジュール６１４、６１６、６１８が患者、医療提供者又は検査を識別することができなければ、これらのモジュールは好ましくは、自動生成サブシステム６０８を呼び出して、適当なレコードを作成して、新たな患者、医療提供者又は検査について辞書及び／又は患者登録サブシステム６１２のフィールドを埋める。
【００８５】
ここでＰＭＭ６１４に移ると、ＰＭＭ６１４は、受け取ったデータを検査してデータが患者登録サブシステム６１２によって識別される既存の患者に関係しているか否かを判定する。データが既存の患者に関係しているならば、比較サブシステム６０４は好ましくは、患者登録サブシステム６１２の患者のレコードを新たに受け取ったデータで更新する。他の場合には、比較サブシステム６０４は好ましくは、患者登録サブシステム６１２に新たな患者レコードを作成し、患者レコードを新たに受け取ったデータ及び決定され得るような追加情報で埋める。
【００８６】
図９は、外部ソース６０２からデータを受け取ったことに応答した医用データベース・システム６００の一実施形態による比較サブシステム６０４のＰＭＭ６１４の動作を示す流れ図である。当業者は、システム６００の代替的な実施形態が、図示のステップを異なる順序で実行したり、付加的なステップを実行したり、又は幾つかのステップを省いたりしてもよいことを認められよう。
【００８７】
ＰＭＭ６１４は好ましくは先ず、受け取ったデータが一致判定工程をサポートするのに十分な情報を含んでいる否かを判定する９１０。一実施形態では、受け取ったデータは、カルテ番号（ＭＲＮ）、診療科番号、マスタ患者索引（ＭＰＩ）番号、及び姓名の対の少なくとも一つを含んでいなければならない。他の場合には、ＰＭＭ６１４はデータを拒絶し９１２、データを患者と一致させる試みを行なわない。
【００８８】
データが比較工程を支援するのに十分な情報を含んでいる場合には、ＰＭＭ６１４は、ＭＲＮが指定されているか否か（すなわちＭＲＮフィールドが空白でないか）を判定する９１４。ＭＲＮが指定されていない場合には、ＰＭＭ６１４は、ＭＲＮを有する患者が患者登録サブシステム６１２に見出されるか否かを判定する９１６。単一の一致患者が登録サブシステム６１２に見出されたら９１８、ＰＭＭ６１４は登録サブシステム６１２の患者レコードをこのデータで更新する９２０。多数の一致患者が登録サブシステム６１２に見出されたら９１８、ＰＭＭ６１４は好ましくは、新たな患者レコードを作成する９２２。ＰＭＭ６１４はまた好ましくは、新たな患者レコード及び多数の一致患者を含む「マージ候補」リストを作成する９２２。
【００８９】
ＰＭＭ６１４が患者登録サブシステム６１２においてＭＲＮに一致する患者を見出さなかった場合９１６には、ＰＭＭ６１４は好ましくは、診療科番号がデータに指定されているか否かを判定する９１７。診療科番号が指定されている（すなわち診療科番号フィールドが空白でない）場合９１７には、ＰＭＭ６１４は、この診療科番号を有する患者が患者登録サブシステム６１２に見出されるか否かを判定する９１９。登録サブシステム６１２に単一の一致患者が見出されたら９２４、ＰＭＭ６１４はこの患者についてＭＲＮが存在するか否かを判定する９２６。この患者についてＭＲＮが存在していない場合９２６には、ＰＭＭ６１４は好ましくは、登録サブシステムの患者レコードを外部ソースから受け取ったデータで更新する９２０。多数の一致患者が登録サブシステム６１２に見出された場合９２４、又は単一の一致患者についてＭＲＮが既に存在していた場合９２６には、ＰＭＭ６１４は好ましくは、新たな患者レコードを作成する９２２。ＰＭＭ６１４はまた好ましくは、上で述べたように、新たな患者レコード及び他の一致患者レコードを含む「マージ候補」リストを作成する９２２。
【００９０】
ＰＭＭ６１４が診療科番号を用いた患者を見出さなかった場合９１９には、ＰＭＭ６１４は好ましくは、新たな患者レコードを作成する９３０。このように、ＭＲＮ及び診療科が両方とも指定されているがＰＭＭ６１４が患者登録サブシステム６１２に一致レコードを識別することができない場合には、ＰＭＭはこの患者について新たなレコードを作成する。
【００９１】
しかしながら、ＭＲＮが指定されているが患者に一致せず、且つ診療科番号フィールドが空白である場合９１７には、ＰＭＭ６１４は好ましくは、一致判定規準を用いて一致を検査する９３２。一実施形態では、ＰＭＭ６１４は、姓、名、生年月日（ＤＯＢ）、社会保障番号（ＳＳＮ）、ＭＲＮ、及び他の識別情報を患者登録サブシステム内の情報と比較することにより一致を検査する９３２。これらの構成要素の各々は下記のように加重される。
【００９２】
姓＝０．５
名＝０．２５
ＤＯＢ＝１．０
ＳＳＮ＝１．０
ＭＲＮ＝３．０
他のＩＤ＝３．０
ＰＭＭ６１４は、あらゆる一致データの加重の合計が３．７５以上になった場合には一致を宣言する９３４。１又は複数の一致患者が見出された場合９３４には、ＰＭＭ６１４のフローは好ましくは、ステップ９２４へ移る。ＰＭＭ６１４が一致患者を見出さなかった場合には、ＰＭＭは好ましくは、新たな患者レコードを作成する９３０。
【００９３】
ステップ９１４に戻り、ＭＲＮフィールドが空白である場合には、ＰＭＭ６１４は好ましくは、診療科番号フィールドも空白であるか否かを判定する９３６。診療科番号が空白である場合９３６には、ＰＭＭ６１４は好ましくは、新たな患者レコードを作成する９３０。ＭＲＮフィールドが空白であるがデータが診療科番号を含んでいる場合９３６には、ＰＭＭ６１４は診療科番号を有する患者が患者登録サブシステム６１２に見出されるか否かを判定する３３８。一致患者が見出されない場合９３８には、ＰＭＭ６１４は新たな患者レコードを作成する９３０。一致する診療科番号を有する単一の患者のみが見出された場合９４０には、ＰＭＭ６１４は好ましくは、登録サブシステム内の患者レコードを外部ソースから受け取ったデータで更新する９２０。多数の一致患者が登録サブシステム６１２に見出された場合９４０には、ＰＭＭ６１４は好ましくは、ステップ９２２に戻り、新たな患者レコードを作成する。ＰＭＭ６１４はまた好ましくは、新たな患者レコード及び他の一致患者レコードを含む「マージ候補」リストを作成する９２２。
【００９４】
図９に記載した工程が終わると、ＰＭＭ６１４は、患者レコードを更新した９２０か、新たな患者レコードを作成した９３０か、又は新たな患者レコードを作成して潜在的マージ候補のリストに追加した９２２かのいずれかを行なっている。後者の場合には、マージ候補リストは好ましくは再び取り上げられて、新たな患者レコードをマージ候補の一つにマージすることができるか否かを判定する。一実施形態では、この判定は、患者レコードを閲覧している利用者によって行なわれる。
【００９５】
前述のように、ＰＲＭＭ６１６は好ましくは、受け取ったデータを辞書サブシステム６１０において識別される医療提供者と一致させることを試みるために、医療提供者識別情報を用いる。本書で用いられる「医療提供者」との用語は、医師又は他の健康管理提供者を指す。但し、当業者は、ＰＲＭＭ６１６によって提供される機能を用いてデータを医療提供者以外の実体と突き合わせてもよいことを認められよう。従って、「医療提供者」との用語は、ＰＲＭＭ６１６の機能が適用可能であるようなその他任意の実体を含むように解釈されるものとする。
【００９６】
外部ソース６０２から写像ツール・サブシステム６０６によって受け取られる医療提供者データは、ＨＬ７のＡＤＴメッセージ、ＯＲＭメッセージ又はＯＲＵメッセージとして供給されてよい。医療提供者データがＨＬ７メッセージとして供給される場合には、ＡＰＩ呼び出しを介してＰＲＭＭ６１６へ供給されるこのデータは好ましくは、複合名（ＣＮ）データ型として供給される。ＨＬ７  ＣＮデータ型は、医療提供者に関連する次の構成要素を提供する：医療提供者ＩＤ（「医療提供者番号」とも呼ぶ）、医療提供者姓、医療提供者名、医療提供者中間名、医療提供者接尾名、医療提供者接頭名、及び医療提供者肩書。医療提供者ＩＤは、医療提供者及び医療提供者が関連している組織の両方を識別することができる。医療提供者データはまた、ＨＬ７  ＭＦＵ又は類似のマスタ・ファイル／辞書管理メッセージとしてＰＲＭＭ６１６に提供され得る。加えて、医療提供者データはまた、好ましくは個人名（ＰＮ）値表現を用いてＤＩＣＯＭヘッダ情報として供給されていてもよい。ＤＩＣＯＭ  ＰＮ値表現は、次の構成要素を供給する：医療提供者姓、医療提供者名、医療提供者中間名、医療提供者接尾名、医療提供者接頭名、及び医療提供者肩書。
【００９７】
図１０は、比較サブシステム６０４の一実施形態に従って医療提供者一致判定処理を実行するときにＰＲＭＭ６１６モジュールによって実行されるステップを示す流れ図である。一般的には、写像ツール・サブシステム６０６からのＡＰＩ呼び出しにおいて受け取ったデータが既存の医療提供者に関係している場合には、ＰＲＭＭ６１６は好ましくは、辞書サブシステム６１０の医療提供者のレコードを新たに受け取ったデータで更新する。他の場合には、ＰＲＭＭ６１６は好ましくは、辞書サブシステム６１０に新たな医療提供者を作成して、医療提供者レコードを新たに受け取ったデータ及び決定され得るような追加情報で埋める。当業者は、サブシステム６０４の代替的な実施形態が、図示のステップを異なる順序で実行したり、付加的なステップを実行したり、又は幾つかのステップを省いたりしてもよいことを認められよう。
【００９８】
最初に、ＰＲＭＭ６１６は、データが医療提供者番号を含んでいるか否かを判定する１０１０。データが医療提供者番号を指定している場合１０１０には、ＰＲＭＭ６１６は辞書サブシステム６１０において医療提供者番号を調査して１０１２、この辞書サブシステム６１０が、一致する医療提供者を含んでいるか否かを判定する１０１４。辞書サブシステムが医療提供者番号に一致する単一の医療提供者を含んでいる場合１０１６には、ＰＲＭＭ６１６は、辞書サブシステム６１０の医療提供者及び／又は組織レコードを新たなデータによって指定されるように更新する１０１８。
【００９９】
医療提供者番号が指定されていない場合１０１０、医療提供者番号は指定されているがＰＲＭＭ６１６が辞書サブシステム６１０に医療提供者を見出さない場合１０１４、又はＰＲＭＭ６１６が辞書サブシステムに多数の一致する医療提供者を見出す場合１０１６には、ＰＲＭＭ６１６は好ましくは、医療提供者名を用いて辞書サブシステム６１０において医療提供者を調査する１０２０。ＰＲＭＭ６１６が辞書サブシステム６１０において一致する名を有する医療提供者を見出さない場合１０２２には、ＰＲＭＭは医療提供者を辞書サブシステムに追加する１０２４。ＰＲＭＭ６１６が単一の一致する医療提供者を見出す場合１０２６には、ＰＲＭＭは好ましくは、辞書サブシステム６１０において医療提供者及び／又は組織レコードを新たなデータによって指定されるように更新する１０１８。
【０１００】
ＰＲＭＭ６１６が多数の一致する医療提供者を見出す場合１０２６には、ＰＲＭＭは好ましくは、一致リストを医療提供者番号（利用可能である場合）に基づいてフィルタ処理する１０２８。フィルタ処理によって単一の医療提供者が生成されない場合１０３０には、ＰＲＭＭ６１６は好ましくは、医療提供者を辞書サブシステム１０２４に追加する１０２４。フィルタ処理によって単一の医療提供者が生成される場合１０３０には、ＰＲＭＭは好ましくは、新たなデータによって指定されるように辞書サブシステム６１０において医療提供者及び／又は組織レコードを更新する１０１８。
【０１０１】
前述のように、ＳＭＭ６１８は好ましくは、検査内容識別情報を用いて、受け取ったデータを患者登録サブシステム６１２に記憶されている検査内容と突き合わせる。本書で用いられる「検査内容（study）」とは、検査（exam）の一部として患者に対して行なわれる手技である。単一の検査に多数の検査内容が関連付けられていてよい。例えば、一つの検査に多数の画像、幾つかの検査室報告、及び一組のコメントが関連付けられていてよい。各々の画像又は画像群、検査室報告等が「検査内容」を構成し得る。
【０１０２】
写像ツール・サブシステム６０６によってＳＭＭ６１８へ提供される検査内容データは一実施形態では、ＤＩＣＯＭヘッダから抽出されたものである。これらのデータは好ましくは、次のフィールドの１又は複数を指定している：ＭＲＮのような患者識別番号、診療科番号、又はＭＰＩ番号；組織コード；受付番号；予定日時；及び検査コード。受付番号及び／又は予定日時が与えられていない場合には、これらのデータは好ましくは、ＳＭＭ６１８によって生成される。データはまた、姓名、生年月日、ＳＳＮ等のような患者についての情報を指定していてもよい。一般的には、検査内容に対応する検査が存在している場合には、ＳＭＭ６１８は検査を新たな検査内容で更新する。検査内容に対応する検査が存在していない場合には、ＳＭＭ６１８は新たな検査を作成してこの検査に検査内容を関連付ける。
【０１０３】
図１１は、比較サブシステム６０４の一実施形態に従って検査内容一致判定処理を実行するときにＳＭＭ６１８モジュールによって実行されるステップを示す流れ図である。当業者は、サブシステム６０４の代替的な実施形態が、図示のステップを異なる順序で実行したり、付加的なステップを実行したり、又は幾つかのステップを省いたりしてもよいことを認められよう。最初に、ＳＭＭ６１８は、データが受付番号を指定しているか否かを判定する１１１０。データが受付番号を指定している場合には、ＳＭＭ６１８は患者登録サブシステム６１２内のいずれかの検査レコードが受付番号に一致しているか否かを判定する１１１２。
【０１０４】
患者登録サブシステム６１２内の単一の検査レコードが受付番号に一致しており、またＭＲＮにも一致している場合１１１４には、ＳＭＭ６１８は検査レコードを外部ソース６０２から受け取った検査内容データで更新する１１１６。患者登録サブシステム６１２内の単一の検査レコードが受付番号に一致しており、また診療科番号にも一致している場合１１１８には、ＳＭＭ６１８は検査レコードを検査内容データで更新する１１１６。
【０１０５】
ステップ１１１４及び１１１８で一致を生成するのに失敗したら、ＳＭＭ６１８は好ましくは、患者登録サブシステム６１２内の単一の検査レコードが受付番号に一致し、また患者一致判定規準に従って一致しているか否かを判定する１１２０。一実施形態では、患者一致判定規準は患者情報に下記のような加重を関連付けている。
【０１０６】
姓＝０．５
名＝０．２５
ＤＯＢ＝１．０
ＳＳＮ＝１．０
一実施形態では、外部ソース６０２から受け取った患者情報を、受付番号を有する検査レコード内の患者情報と比較して、一致するフィールドの加重を合計する。和が１．７５以上である場合に一致を宣言する。システム６００の代替的な実施形態は、この一致判定を異なったように行なってよい。一致が存在した場合１１２０には、ＳＭＭ６１８は検査レコードを検査内容データで更新する１１１６。
【０１０７】
受付番号が供給されていない１１１０か、又は前述のステップで受付番号は供給されているが一致するレコードが見出されない場合には、ＳＭＭ６１８は好ましくは、患者一致判定規準、モダリティ形式、及び検査内容の日付を考慮することにより、一致する検査レコードが患者登録サブシステム６１２に見出され得るか否かを判定する１１２２。一致が存在する場合１１２２には、ＳＭＭ６１８は検査レコードを検査内容データで更新する１１１６。他の場合には、ＳＭＭ６１８は検査を作成して１１２４、この検査に検査内容を関連付ける。
【０１０８】
比較サブシステム６０４の上述の動作から分かるように、このサブシステムは本質的に、二つのモードで動作する。第一のモードは、外部ソース６０２から受け取ったデータがＨＬ７標準に従うときに生ずる。この場合には、比較サブシステム６０４は、ＭＲＮ、又は診療科番号のような他の信頼できる一意の識別子に基づいて、患者、医療提供者又は検査を見出す。この情報に基づいて患者、医療提供者又は検査が見出されたら、他の一致は要求されず、関連するデータベース・レコードを外部ソース６０２からのデータに含まれる任意の新たな情報で更新する。
【０１０９】
第二のモードは、データがＨＬ７準拠型ソースからのものでない場合に生ずる。この場合には、比較サブシステム６０４は名称、ＤＯＢ、ＳＳＮ、ＭＲＮ等のような幾つかのフィールドに加重を割り当てることにより患者、医療提供者又は検査を見出す。このように、第二のモードでは、比較サブシステム６０４は幾分曖昧な情報に基づいて一致するレコードを識別することが可能である。
【０１１０】
写像ツール・サブシステム６０６は好ましくは、自動生成サブシステム６０８を呼び出して、辞書サブシステム６１０及び患者登録サブシステム６１２内のレコード及びフィールドを自動生成して埋める。一実施形態では、自動生成サブシステム６０８は、比較サブシステム６０４が１又は複数のレコード又はフィールドを更新するか又は作成した処理状態に達したことに応答して実行される。これらの処理状態には、図９の「患者を更新する」ステップ９２０及び「新たな患者を作成する」ステップ９３０、図９の「医療提供者を更新して組織に加える」ステップ９１８及び「新たな医療提供者を加える」ステップ９２４、並びに図１０の「検査を更新する」ステップ１０１６及び「検査を作成する」ステップ１０２４が含まれる。
【０１１１】
図１２は、医用データベース・システム６００の一実施形態による自動生成サブシステム６０８の動作を示す流れ図である。当業者は、サブシステム６０８の代替的な実施形態が、図示のステップを異なる順序で実行したり、付加的なステップを実行したり、又は幾つかのステップを省いたりしてもよいことを認められよう。自動生成サブシステム６０８は、写像ツール・サブシステム１２０６から、新たなレコード又はフィールド（１若しくは複数）を作成すること又は既存のレコード若しくはフィールド（１若しくは複数）を更新することを示すデータ及び／又は命令を含むＡＰＩ呼び出しを受け取る１２１０。もう一つの実施形態では、自動生成サブシステム１２０８は、比較サブシステム１２０４からＡＰＩ呼び出しを受け取る。
【０１１２】
自動生成サブシステム６０８は、辞書サブシステム６１０及び／又は患者登録サブシステム６１２にレコード及び／又はフィールドを生成する１２１２。一般的には、辞書サブシステム６１０及び患者登録サブシステム６１２の各々のレコードは、当該レコードに関連するデータを記憶する一組の関連するフィールドを有している。一実施形態では、各々のレコードにおけるこの一組のフィールドはレコードの形式に依存している。他の実施形態では、他の因子又は情報が、各々のレコードに関連するフィールドの数及び形式を制御することもできる。各々のフィールドは、数値情報、テキスト情報及び／若しくは二値情報、並びに／又はデータベースにおいて記憶向けに構成されたその他任意のデータ型の形態でデータを保持することができる。例えば、フィールドは、氏名、年齢、及び患者に関連する医療提供者を示すことができる。加えて、フィールドは、患者に関連する放射線画像又は他の画像を記憶することもできる。
【０１１３】
写像ツール・サブシステム６０６は好ましくは、自動生成サブシステム６０８に対し、適当なフィールドを適当なデータで埋める１２１４ように指令する。写像ツール・サブシステム６０６は好ましくは、自動生成サブシステム６０８に対し、外部ソース６０２からの解釈、写像及び／又は変換を施したデータを適当なフィールド（１又は複数）に配置することを行なわせる。自動生成サブシステム６０８はまた好ましくは、幾つかのフィールドを、辞書サブシステム６１０及び／又は患者登録サブシステム６１２内の他のフィールドから導かれたデータで埋める１２１４。例えば、外部ソースから受け取ったデータ６０２は、辞書サブシステム６１０及び／又は患者登録サブシステム６１２内のデータと関係を有していたり、かかるデータに基づく何らかの依存関係のきっかけを与えたりしている場合があり、これにより、他の幾つかのフィールドに幾つかの値が当て嵌められる。加えて、自動生成サブシステム６０８は好ましくは、幾つかのフィールドを既定の値で埋める１２１４。これらのフィールドについては後にあらためて詳述し、これらのフィールドのあらゆるものが、システム６００の実施形態に依存して既定値又は他の値で埋められ得る。このステップは、限定されたデータの受領に応答して実質的に完全なレコードを作成するため有利である。
【０１１４】
図１３は、辞書サブシステム６１０のさらに詳細な把握像を示すブロック図である。一実施形態では、辞書サブシステム６１０は、従来のデータベース技術を通じて具現化される。好適実施形態では、辞書サブシステムは、９個の論理的に別個の辞書を含んでいる。すなわち組織辞書１３１０、検査辞書１３１２、検査修飾子辞書１３１４、リソース／リソース・グループ辞書１３１６（本書では「リソース」辞書とも呼ぶ）、設備辞書１３１８、患者位置辞書１３２０、身体部位辞書１３２２、下位専門的特性辞書１３２４、及び医療提供者辞書１３２６である。サブシステム６１０の代替的な実施形態は、これらの辞書の１又は複数を省き、且つ／又は他の辞書を含んでいる。
【０１１５】
一実施形態では、組織辞書１３１０の各々のレコードは、組織コード及び説明のためのフィールドを含んでいる。組織コードは、エントリに関連した情報を提供した組織を示す。説明フィールドは組織を説明するものである。一実施形態では、組織コードが必須フィールドであり、このコードが判明しない限り組織辞書レコードは生成されない。
【０１１６】
検査辞書１３１２の各々のレコードは好ましくは、組織コード、検査コード、説明、モダリティ形式、身体部位、及び下位専門的特性のためのフィールドを含んでいる。一実施形態では、組織コード及び検査コードが必須フィールドであり、これらのコードが判明しない限り検査辞書レコードは生成されない。
【０１１７】
検査修飾子辞書１３１４の各々のレコードは好ましくは、組織コード、検査修飾子コード、説明、モダリティ形式、身体部位及び下位専門的特性のためのフィールドを含んでいる。一実施形態では、組織コード及び検査修飾子コードが必須フィールドであり、これらのコードが判明しない限り検査修飾子辞書レコードは生成されない。
【０１１８】
リソース辞書１３１６の各々のレコードは好ましくは、組織コード、リソース・コード、説明、及びモダリティ形式のためのフィールドを含んでいる。一実施形態では、組織コード及びリソース・コードが必須フィールドであり、これらのコードが判明しない限りリソース辞書レコードは生成されない。
【０１１９】
設備辞書１３１８の各々のレコードは好ましくは、組織コード、設備コード、設備形式コード、説明、及びモダリティ形式のためのフィールドを含んでいる。一実施形態では、組織コード、設備コード、及び設備形式コードが必須フィールドであり、これらのコードが判明しない限り設備辞書レコードは生成されない。
【０１２０】
患者位置辞書１３２０の各々のレコードは好ましくは、患者位置コード及び説明のためのフィールドを含んでいる。一実施形態では、患者位置コードが必須フィールドであり、このコードが判明しない限り患者位置辞書レコードは生成されない。
【０１２１】
身体部位辞書１３２２の各々のレコードは好ましくは、身体部位コード及び説明のためのフィールドを含んでいる。一実施形態では、身体部位コードが必須フィールドであり、このコードが判明しない限り身体部位辞書レコードは生成されない。
【０１２２】
下位専門的特性辞書１３２４の各々のレコードは好ましくは、下位専門的特性コード及び説明のためのフィールドを含んでいる。一実施形態では、下位専門的特性コードが必須フィールドであり、このコードが判明しない限り下位専門的特性辞書レコードは生成されない。
【０１２３】
医療提供者辞書１３２６の各々のレコードは好ましくは、組織コード、医療提供者番号、医療提供者姓、医療提供者名、医療提供者中間名、医療提供者接尾名、医療提供者肩書、「解釈可能」フラグ、及び「技士」フラグのためのフィールドを含んでいる。一実施形態では、組織コード、医療提供者姓、及び医療提供者名が必須フィールドであり、これらのデータが判明しない限り医療提供者辞書レコードは生成されない。
【０１２４】
辞書サブシステム６１０の場合と同様に、患者登録サブシステム６１２は好ましくは、従来のデータベース技術を通じて具現化される。一実施形態では、患者登録サブシステム６１２は、患者、検査及び検査内容についての情報を記憶している。このようなものとして、患者登録サブシステム６１２は、辞書サブシステム６１０に記憶されている情報を補完し又はかかる情報と重なる情報を含んでいてよい。一実施形態では、患者登録サブシステム６１２及び辞書サブシステム６１０は、単一のデータベース・システム内の論理的に別個のモジュールである。
【０１２５】
以上の記載は好適実施形態の動作を説明するために含められており、本発明の範囲を制限するものではない。上の議論から、当業者には本発明の要旨及び範囲によって依然包含される多くの変形が明らかとなろう。
【図面の簡単な説明】
【０１２６】
【図１】本発明の一実施形態による手技療法ワークフロー・システムを示す高レベル・ブロック図である。
【図２】一実施形態によるアプリケーション構造を示す図である。
【図３】図１のシステムによって管理される手技中心型ワークフローを示す図である。
【図４】図１のシステムによる報告ツールの統合を示す図である。
【図５】図１のシステムの様々な構成要素によって実行される処理系列を示す図である。
【図６】本発明の一実施形態による患者情報の自動生成能力を備えた医用データベース・システムを示す高レベル・ブロック図である。
【図７】一実施形態に従って図６の医用データベース・システムとして用いられるコンピュータ・システムの高レベル・ブロック図である。
【図８】医用データベース・システムの比較サブシステムの患者一致判定モジュールの動作を示す流れ図である。
【図９】比較サブシステムの一実施形態に従って医療提供者一致判定処理を実行するときに医療提供者一致判定モジュールによって実行されるステップを示す流れ図である。
【図１０】比較サブシステムの一実施形態に従って検査内容一致判定処理を実行するときに検査内容一致判定モジュールによって実行されるステップを示す流れ図である。
【図１１】医用データベース・システムの一実施形態による自動生成サブシステムの動作を示す流れ図である。
【図１２】医用データベース・システムの一実施形態による写像ツール・サブシステムの動作を示す流れ図である。
【図１３】辞書サブシステムのさらに詳細な把握像を示すブロック図である。
【図１４】本発明の一実施形態に従って利用者がワークリストを構成設定することを可能にするユーザ・インタフェイスの図である。
【図１５】利用者がワークリストに表示したい欄を選択することを可能にするユーザ・インタフェイスの図である。
【図１６】利用者によって作成されるワークリストを示す図である。
【符号の説明】
【０１２７】
６０７  解釈エンジン
６１４  患者一致判定モジュール（ＰＭＭ）
６１６  医療提供者一致判定モジュール（ＰＲＭＭ）
６１８  検査内容一致判定モジュール（ＳＭＭ）
７００  コンピュータ・システム
７０４  バス
７２０  プログラム・モジュール
【図１】
2008522283.tif 000003
【図２】
2008522283.tif 000004
【図３】
2008522283.tif 000005
【図４】
2008522283.tif 000006
【図５】
2008522283.tif 000007
【図６】
2008522283.tif 000008
【図７】
2008522283.tif 000009
【図８】
2008522283.tif 000010
【図９】
2008522283.tif 000011
【図１０】
2008522283.tif 000012
【図１１】
2008522283.tif 000013
【図１２】
2008522283.tif 000014
【図１３】
2008522283.tif 000015
【図１４】
2008522283.tif 000016
【図１５】
2008522283.tif 000017
【図１６】
2008522283.tif 000018
【国際調査報告】
2008522283.tif 000019