(57)【要約】【課題】異なる医療施設間で診療データの効率的な共有を可能にする。【解決手段】共有サーバは、コントローラ１６と共有ＤＢ１７から構成されており、複数の医療施設と通信ネットワークで接続されている。データ登録部４１は、各医療施設から提供された診療データを共有ＤＢ１７に登録する。共有ＤＢ１７は、診療データを管理ＩＤで管理する。管理ＩＤは、共有ＤＢ１７内でそこに登録される診療データを患者単位で管理するための識別情報であり、１人の患者に１つずつ割り当てられる。データ登録部４１は、受け付けた診療データを格納する際に、共有ＤＢ１７内に同一患者の過去の診療データの登録状況を調べて、既に登録済みの場合には、その管理ＩＤの下に追加し、未登録の場合には、新規の管理ＩＤを割り当てて登録する。【選択図】図９
2008204378.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークを介して複数の医療施設が保有する診療データを複数の医療施設間で共有するための診療データ共有サーバにおいて、
前記各医療施設からアップロードされる診療データを受け付ける診療データ受付部と、
前記診療データを患者毎に割り当てた管理ＩＤに関連付けて蓄積するデータ共有ＤＢと、
前記データ共有ＤＢに格納する際に、診療データに含まれる患者特定情報に基づいて、前記データ共有ＤＢ内に同一患者の過去の診療データが既に登録済みか否かを調べる登録状況判定部と、
前記登録状況判定部によって、既に登録済みと判定された場合には、前記診療データを既に割り当て済みの管理ＩＤに関連付けて登録するとともに、未登録と判定された場合には、前記診療データを新規の管理ＩＤに関連付けて登録する診療データ登録部とを備えたことを特徴とする診療データ共有サーバ。
【請求項２】
前記患者特定情報には、患者名，性別，生年月日を含む複数の項目が含まれており、前記登録状況判定部は、それら複数の項目について、受け付けた診療データと登録済みの診療データとの照合を行って、患者の同一性を調べることを特徴とする請求項１記載の診療データ共有サーバ。
【請求項３】
前記通信ネットワークを介して前記各医療施設からの検索要求を受け付けて、前記データ共有ＤＢ内を検索し、検索したデータを要求元へ配信する配信サービスを実行する配信サービス実行部を備えたことを特徴とする請求項１又は２記載の診療データ共有サーバ。
【請求項４】
前記配信サービス実行部は、指定された患者の診療データの診療データを配信する患者指定検索サービスと、指定された条件で診療データを検索して、その条件に合致する診療データを症例データとして配信する症例検索サービスとを実行することを特徴とする請求項３記載の診療データ共有サーバ。
【請求項５】
前記症例検索サービスにおいて、前記診療データを前記各医療施設へ配信する際に、前記患者特定情報の公開の可否を表す公開可否情報を調べて、公開が不可の場合には、前記診療データに対して前記患者特定情報を秘匿する秘匿処理を施すデータ処理部を備えたことを特徴とする請求項４記載の診療データ共有サーバ。
【請求項６】
前記データ共有ＤＢ内の診療データに基づいて症例の統計を算出する症例統計算出部を備えたことを特徴とする請求項１〜５いずれか診療データ共有サーバ。
【請求項７】
通信ネットワークを介して複数の医療施設が保有する診療データを複数の医療施設間で共有する診療データ共有方法において、
前記各医療施設からアップロードされる診療データを受け付ける診療データ受付ステップと、
前記診療データに含まれる患者特定情報に基づいて、同一患者の過去の診療データが既にデータ共有ＤＢ内に登録済みか否かを調べる登録状況判定ステップと、
既に登録済みと判定された場合には、前記診療データを既に割り当て済みの管理ＩＤに関連付けて登録するとともに、未登録と判定された場合には、前記診療データを新規の管理ＩＤに関連付けて登録する診療データ登録ステップとを含むことを特徴とする診療データ共有方法。
【請求項８】
医療施設内の診療データを電子化してファイリングする診療データファイリング装置において、
前記診療データを患者毎にファイリングして格納するデータファイリング部と、
前記医療施設の外部に設置され通信ネットワークを介して複数の医療施設間で共用される共有サーバに対して、前記データ格納部内の前記診療データを提供する診療データ提供部と、
前記診療データに対して、前記共有サーバへの提供に関する可否情報を設定する可否情報設定部と、
前記可否情報の設定を促す警告部とを設けたことを特徴とする診療データファイリング装置。
【請求項９】
さらに、前記可否情報設定部は、前記提供が可とされた診療データに対して、その診療データに含まれる患者特定情報の公開に関する可否情報を設定することを特徴とする請求項８記載の診療データファイリング装置。
【請求項１０】
さらに、原稿をスキャンして電子化されたスキャン画像を受け付けて、このスキャン画像に対してＯＣＲ処理を実行して、データ検索用の索引データを作成する索引データ作成部を設けたことを特徴とする請求項８又は９記載の診療データファイリング装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、カルテデータや検査画像を含む診療データを複数の医療施設間で共有するための診療データ共有サーバ、診療データ共有方法、及び診療データファイリング装置に関するものである。
【背景技術】
【０００２】
病院や診療所などの医療施設において、カルテや検査画像を含む診療データの電子化が進んでおり、診療データをコンピュータで管理することが行われている。大規模な医療施設では、多数のコンピュータが分散して存在するので、それらを連携させて有効に活用するための統合管理医療システムも提案されている（特許文献１）。こうした統合管理医療情報システムでは、医療施設内の各診療科の診療データを蓄積し、これをデータベース化することで、検索を容易にする仕組みが実現されている。適切な診療方針や診療内容を決定するためには、過去の症例などを利用することが非常に重要であるので、上記統合管理医療情報システムによれば、症例検索などが容易になり、適切な医療支援を行うことができる。
【特許文献１】特開２００２−０５６０９３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
これに対して、診療所などの小規模の医療施設は、大規模な医療施設と比較すると、患者数が圧倒的に少なく、過去の症例データ等の蓄積も少ない。そのため、蓄積した症例を活用する以前に、症例数そのものが不足している状況にある。そこで、複数の医療施設が協力して互いの診療データを共有化して利用する方法が検討されている。
【０００４】
上記統合管理医療情報システムも、医療施設内の複数の診療科のデータを診療科間で共有する機能を備えているものの、このシステムは、１つの医療施設内で診療データを共有するものであり、異なる医療施設間での診療データを予定したものではないため、こうしたシステムをそのまま流用すると、非効率なシステムになってしまうおそれがある。
【０００５】
例えば、複数の医療施設から提供された複数の診療データを単に共有ＤＢに格納していくだけでは、異なる医療施設にそれぞれ帰属する同一患者の診療データが分散してしまうおそれがある。そうした診療データの管理方法では、同一患者のすべての診療データの検索には手間と時間がかかることが予想され、検索効率が懸念されていた。
【０００６】
また、異なる医療施設間で診療データを共有する場合には、各医療施設からの診療データの提供が不可欠である。そのため、診療データの共有をより実効性の高いものにするために、そうした診療データの収集を促進するためのしくみが望まれていた。
【０００７】
本発明は、こうした背景に鑑みてなされたものであり、異なる医療施設間の効率的な診療データの共有を可能にすることを目的とする。
【０００８】
また、こうした診療データの共有を行うに当たって、診療データの収集効率を高めることを目的とする。
【課題を解決するための手段】
【０００９】
本発明の診療データ共有サーバは、通信ネットワークを介して複数の医療施設が保有する診療データを複数の医療施設間で共有するための診療データ共有サーバにおいて、前記各医療施設からアップロードされる診療データを受け付ける診療データ受付部と、前記診療データを患者毎に割り当てた管理ＩＤに関連付けて蓄積するデータ共有ＤＢと、前記データ共有ＤＢに格納する際に、診療データに含まれる患者特定情報に基づいて、前記データ共有ＤＢ内に同一患者の過去の診療データが既に登録済みか否かを調べる登録状況判定部と、前記登録状況判定部によって、既に登録済みと判定された場合には、前記診療データを既に割り当て済みの管理ＩＤに関連付けて登録するとともに、未登録と判定された場合には、前記診療データを新規の管理ＩＤに関連付けて登録する診療データ登録部とを備えたことを特徴とする。
【００１０】
さらに、前記患者特定情報には、患者名，性別，生年月日を含む複数の項目が含まれており、前記登録状況判定部は、それら複数の項目について、受け付けた診療データと登録済みの診療データとの照合を行って、患者の同一性を調べることが好ましい。
【００１１】
さらに、前記通信ネットワークを介して前記各医療施設からの検索要求を受け付けて、前記データ共有ＤＢ内を検索し、検索したデータを要求元へ配信する配信サービスを実行する配信サービス実行部を備えることが好ましい。
【００１２】
さらに、前記配信サービス実行部は、指定された患者の診療データの診療データを配信する患者指定検索サービスと、指定された条件で診療データを検索して、その条件に合致する診療データを症例データとして配信する症例検索サービスとを実行することが好ましい。
【００１３】
さらに、前記症例検索サービスにおいて、前記診療データを前記各医療施設へ配信する際に、前記患者特定情報の公開の可否を表す公開可否情報を調べて、公開が不可の場合には、前記診療データに対して前記患者特定情報を秘匿する秘匿処理を施すデータ処理部を備えることが好ましい。
【００１４】
さらに、前記データ共有ＤＢ内の診療データに基づいて症例の統計を算出する症例統計算出部を備えることが好ましい。
【００１５】
本発明の診療データ共有方法は、通信ネットワークを介して複数の医療施設が保有する診療データを複数の医療施設間で共有する診療データ共有方法において、前記各医療施設からアップロードされる診療データを受け付ける診療データ受付ステップと、前記診療データに含まれる患者特定情報に基づいて、同一患者の過去の診療データが既にデータ共有ＤＢ内に登録済みか否かを調べる登録状況判定ステップと、既に登録済みと判定された場合には、前記診療データを既に割り当て済みの管理ＩＤに関連付けて登録するとともに、未登録と判定された場合には、前記診療データを新規の管理ＩＤに関連付けて登録する診療データ登録ステップとを含むことを特徴とする診療データ共有方法。
【００１６】
本発明の診療データファイリング装置は、医療施設内の診療データを電子化してファイリングする診療データファイリング装置において、前記診療データを患者毎にファイリングして格納するデータファイリング部と、前記医療施設の外部に設置され通信ネットワークを介して複数の医療施設間で共用される共有サーバに対して、前記データ格納部内の前記診療データを提供する診療データ提供部と、前記診療データに対して、前記共有サーバへの提供に関する可否情報を設定する可否情報設定部とを設けたことを特徴とする。
【００１７】
さらに、前記可否情報設定部は、前記提供が可とされた診療データに対して、その診療データに含まれる患者特定情報の公開に関する可否情報を設定することが好ましい。
【００１８】
さらに、原稿をスキャンして電子化されたスキャン画像を受け付けて、このスキャン画像に対してＯＣＲ処理を実行して、データ検索用の索引データを作成する索引データ作成部を設けたことが好ましい。
【発明の効果】
【００１９】
本発明によれば、複数の医療施設からアップロードされる診療データに対して、患者毎に割り当てた管理ＩＤに関連付けてデータ共有ＤＢに蓄積し、前記データ共有ＤＢに格納する際に、診療データに含まれる患者特定情報に基づいて、前記データ共有ＤＢ内に同一患者の過去の診療データが既に登録済みか否かを調べる登録状況判定し、その判定結果に基づいて、既に登録済みの患者の診療データは、割り当て済みの管理ＩＤに関連付けて登録するとともに、未登録の患者の診療データについては、新規の管理ＩＤに関連付けて登録するようにしたから、異なる医療施設間での効率的な診療データの共有を可能にすることができる。
【００２０】
また、本発明によれば、医療施設内において、診療データを患者毎にファイリングする際に、診療データに対して、共有サーバへの提供に関する可否情報を設定するとともに、その可否情報の設定を促す警告を発するようにしたから、共有サーバへの診療データの提供が促進され、データの収集効率が向上する。
【発明を実施するための最良の形態】
【００２１】
図１は、複数の医療施設１０が保有する患者の診療データを、医療施設１０同士で共有する医用ネットワークシステムの説明図である。医用ネットワークシステムは、各医療施設１０に設置された診療データファイリング装置（以下、単にファイリング装置という）１１と、各医療施設１０が共用するデータセンタ１２に設置された診療データ共有サーバ（以下、共有サーバという）１３とからなる。ファイリング装置１１と、共有サーバ１３とはＩＰ（Internet Protocol）ネットワーク１４を介して通信可能に接続されている。
【００２２】
ファイリング装置１１は、装置全体を統括的に制御するコントローラ１８と、各医療施設１０がそれぞれ保有する診療データをファイリングして蓄積する個別ＤＢ（データベース）１９とからなる。ファイリング装置１１は、個別ＤＢ１９内の診療データを共有サーバ１３へアップロードして提供する診療データ提供機能を備えている。
【００２３】
共有サーバ１３は、装置全体を統括的に制御するコントローラ１６と、このコントローラ１６に接続され、提供され診療データを格納する共有ＤＢ（データベース）１７とからなる。共有サーバ１３は、各医療施設１０から提供される診療データを蓄積し、蓄積した診療データを各医療施設１０に向けて配信するサービスを提供する。これにより、各医療施設１０は、共有サーバ１３を利用することで、各医療施設１０が保有する診療データを相互に利用することができる。
【００２４】
ＩＰネットワーク１４は、例えば、インターネットや、通信事業者が独自に提供するネットワークなど、不特定多数の利用者に開放された公衆系の通信ネットワークである。共有サーバ１３と各ファイリング装置１１の間では、これをベースにして、ＩＰｓｅｃ（Internet Protocol Security）などの暗号化技術を利用したＶＰＮ（Virtual Private Network）が構築される。
【００２５】
ＶＰＮを利用すると、共有サーバ１３と各ファイリング装置１１間では、それぞれ仮想的に専用の通信チャンネルが確立され、その通信チャンネルを通じてデータ通信が行われる。この通信チャンネルを通るデータは暗号化されるので、データの外部漏洩が防止される。公衆系の通信ネットワークは、物理的な専用回線を使用する専用ネットワークと比較してコストが安いため、ＶＰＮを利用することで、低コストで情報セキュリティを確保することができる。もちろん、通信ネットワークは、こうしたネットワークに限定されるものではなく、通信量、費用、安全性等を考慮して適宜選択される。
【００２６】
各医療施設１０及びデータセンタ１２には、ＩＰネットワーク１４に接続するための通信インタフェースであるルータ２１，２２がそれぞれ設置されており、共有サーバ１３及びファイリング装置１１は、それぞれのルータ２１，２２を通じて、ＩＰネットワーク１４に接続する。この通信インタフェースも、通信ネットワークの種類や通信プロトコルに応じて適宜選択される。
【００２７】
図２に示すように、ファイリング装置１１は、例えば、医療施設１０内に設置されるスキャナ２３や電子カルテシステム２４とＬＡＮを経由して接続されている。スキャナ２３は、カルテ用紙２６や放射線フイルム２７などの原稿２５をイメージセンサによって光電的に読み取り、手書きで記入されたカルテ情報や、放射線フイルム２７に記録された検査画像をスキャンして電子化し、このスキャン画像をファイリング装置１１に出力する。なお、原稿２５の例として、カルテ用紙２６や放射線フイルム２７を例にしているが、原稿２５には、心電図や血液検査の結果を記録した用紙なども含まれる。
【００２８】
電子カルテシステム２４は、周知のように、患者のカルテ情報を入力から管理までコンピュータを用いて行うシステムである。カルテ情報は電子的なカルテデータである電子カルテとして管理され、これをファイリング装置１１へ出力する。モダリティ２８は、ＣＲ（Computed Radiography）装置やＣＴ（Computed Tomography）装置など、検査画像をデジタルデータで取得する検査装置である。このモダリティ２８は、例えば、医用画像の標準的な規格である、ＤＩＣＯＭ（Digital Imaging and COmmunications inMedicine）規格のデジタル画像を出力する。
【００２９】
ファイリング装置１１は、ＬＡＮインタフェース２９を通じて、スキャナ２３、電子カルテシステム２４、モダリティ２８から、それぞれ、スキャン画像、電子カルテ、デジタル画像を取り込み、取り込んだデータを診療データとして患者毎に個別ＤＢ１９にファイリングする。
【００３０】
現在のところ、医療施設において医療情報の電子化は進みつつあるものの、カルテ用紙２６を使用している医療施設が多いのが実状であり、過去の診療録はカルテ用紙２６のまま保有しているケースがほとんどである。ファイリング装置１１は、電子カルテやデジタル画像に加えて、スキャン画像を取り込み、これを加工して個別ＤＢ１９へ収録する機能を備えている。これにより、カルテ用紙２６や放射線フイルム２７の形態で保存された過去の診療データの蓄積を有効に活用できるようにしている。
【００３１】
個別ＤＢ１９には、その医療施設において、患者毎に割り当てられた患者ＩＤに関連付けて診療データが格納される。患者毎の診療データは、例えば、診療単位でまとめられる。ここで、診療単位とは、ある疾患で診療を受けた場合に、その疾患に関するカルテ及び検査画像がまとめられる単位をいう。例えば、胃潰瘍で診療を受けた場合には、それに関するカルテや検査画像のデータが１件の診療データにまとめられ、肺ガンで診療を受けた場合には、それに関するデータが１件の診療データにまとめられる。したがって、１人の患者が複数の疾患で診療を受けた場合には、１人の患者につき、複数の診療データが存在する。
【００３２】
例えば、図２においては、患者ＩＤが「０００１」と「０００３」には、それぞれ１件の診療データ１が関連付けられており、患者ＩＤ「０００２」には、３件の診療データ１〜３が関連付けて格納されている。ここで、診療データの後に付した番号は、診療データの格納順序を示す番号であり、診療データ１は、１つの患者ＩＤで最初に格納されたデータであることを意味する。
【００３３】
図３は、診療データの構成例を示す説明図である。図３（Ａ）は、複数のスキャン画像からなる診療データ（診療データＭＡ）の例であり、図３（Ｂ）は、電子カルテとデジタル画像からなる診療データ（診療データＭＢ）の例である。診療データＭＡは、索引データと、複数のスキャン画像１〜Ｎからなる。スキャン画像１は、例えば、カルテ用紙２６をスキャンした画像であり、スキャン画像２は、例えば、放射線フイルム２７をスキャンした画像である。
【００３４】
索引データは、テキスト形式のデータであり、後述するように、スキャン画像を個別ＤＢ１９へ格納する際に作成される。スキャン画像は、ラスターデータであるから、これをキーワードで検索する際には、テキスト形式のデータが必要になる。索引データには、患者ＩＤ，患者名，病名，転帰，診察時期，外部提供の可否、診察日、検査日などの項目が含まれており、こうした項目でキーワード検索が可能となっている。転帰とは、診療の結果を意味し、その内訳として、治癒、死亡、中止がある。外部提供の可否は、共有サーバ１３への提供を許可するか否かの情報であり、患者の意思を確認して入力される。ここで挙げた項目以外にも、例えば、診療データに含まれるスキャン画像の内容（放射線画像、心電図、血液検査結果）や検査日など、別の項目を追加してもよい。
【００３５】
診療データＭＢは、電子カルテとデジタル画像１〜Ｎとが含まれる。電子カルテのデータには、上記索引データの項目と同様の項目がテキスト形式で含まれているので、こうした電子カルテのデータそのものが、診療データＭＢを検索するための索引データとして機能する。また、デジタル画像がＤＩＣＯＭ規格である場合には、検査日やデータの属性など種々のデータがメタデータとして含まれており、こうしたメタデータを索引データとして使用してもよい。
【００３６】
本例では、診療データの構成例として、２つの例を示したが、カルテ用紙のスキャン画像と、モダリティから取得したデジタル画像の組み合わせで構成してもよいし、電子カルテと、放射線フイルムのスキャン画像の組み合わせで構成してもよいし、それらが混在してもよい。
【００３７】
ファイリング装置１１のコントローラ１８は、ＣＰＵやメモリなどからなり、診療データファイリングプログラムを実行することで、索引データ作成部３１，可否情報設定部３２，データファイリング部３３，診療データ提供部３４として機能する。
【００３８】
索引データ作成部３１は、スキャン画像に対してＯＣＲ（Optical Character Recognition）処理を施して、スキャン画像から文字情報を抽出し、テキスト形式の索引データを作成する。索引データ作成部３１は、ＯＣＲ処理を実行した後、その処理結果を確認する確認画面をコンソール３６のモニタに出力する。図４及び図５は、それぞれ、確認画面の例であり、図４に示す確認画面３７は、カルテ用紙２６のスキャン画像（カルテ）と、そのＯＣＲ結果を表示する確認画面であり、図５に示す確認画面３８は、放射線フイルム２７のスキャン画像（検査画像）と、そのＯＣＲ結果を表示する確認画面である。
【００３９】
この確認画面で再読み取りの要否の判断や、認識した文字情報の修正などが行われる。確認画面３７，３８には、それぞれ、スキャン画像とともに、それに基づいて認識した文字情報が表示される。放射線フイルム２７には、検査画像に加えて、患者ＩＤ、患者名、検査日などが記入されたタグシールが貼付されている場合が多く、そうしたタグシールがある場合には、それらの項目が認識される。
【００４０】
手書き文字は誤認識や読み取り不能となる場合が多いので、文字の認識結果はマニュアルで修正（文字の入力や訂正）できるようになっている。修正ボタン４１や確定ボタン４２は、その修正を行うための操作ボタンであり、コンソール３６のマウスやキーボードなどによって操作される。修正ボタン４１がクリックされると、カーソル等で選択した認識結果が修正可能な状態になり、修正後、確定する場合には、確定ボタン４２がクリックされる。
【００４１】
また、ＯＣＲ処理の認識率の向上は、画像全体の中で認識すべき文字の位置が特定されている方がよい。例えば、カルテ用紙２６であれば、患者名、患者ＩＤ、傷病名、診療日などの各項目の記入欄が定められた定型のフォーマットが使用される場合が多いので、そのレイアウトを定義したレイアウトデータを予め用意して、それを参照しながら、読み取り項目の位置を特定して行うようにしてもよい。
【００４２】
また、読み取り位置を特定して、部分的にスキャンするようにすれば、スキャン画像の画面全体に対してＯＣＲ処理を施す場合に比べて、処理時間を短縮化できるなどのメリットも得られる。また、カルテ用紙２６や放射線フイルム２７など原稿２５の種別を自動的に識別できるようにしてもよい。こうすれば、上記レイアウトデータを原稿毎に用意しておけば、原稿の種別に応じてレイアウトデータの選択を自動的に行うことができるなどのメリットが得られる。
【００４３】
可否情報設定部３２は、個別ＤＢ１９に格納する診療データを外部の共有サーバ１３に提供していいかどうかの提供可否情報を設定する。共有サーバ１３に診療データが提供されると、その診療データは他の医療施設１０へ公開される。こうした診療データの取り扱いについて、患者の同意が得られた場合には、提供可とされ、同意が得られない場合には、提供不可の設定がなされる。
【００４４】
図６に示すように、コンソール３６のモニタには、診療データを個別ＤＢ１９に格納する際に、外部提供の可否を問い合わせる問い合わせメッセージ３９が表示される。患者の同意を重視する観点から、提供可否情報の初期設定は、提供不可となっており、そのため、オペレータが提供可否情報の設定をし忘れると、患者の同意を得ているにも関わらず外部提供が滞ってしまう事態が生じる。そこで、こうした問い合わせメッセージ３９を表示することで、オペレータによる提供可否情報の設定のし忘れを防止し、これにより、診療データの提供が促進されるようにしている。問い合わせメッセージ３９には、例えば、「この患者の診療データを共有サーバへ登録しますか？」というメッセージとともに、可否を選択する選択ボタン（「する」、「しない」）が表示される。この選択ボタンのクリックによって、提供可否情報の入力を受け付けて、診療データに対して、提供可否情報が設定される。
【００４５】
また、可否情報設定部３２は、提供可否情報が提供可（「する」）と選択された場合に、診療データに含まれる患者特定情報を公開する否かを表す公開可否情報を設定する。患者特定情報には、患者名、性別、住所、生年月日、連絡先（電話番号など）、保険証番号などが含まれる。患者特定情報を非公開とすれば、患者のプライバシーが確保される可能性は高い。そのため、診療データの中の患者特定情報までが公開されることを懸念して外部提供を躊躇する患者の中から、外部提供に同意する患者数が増加して、外部提供される診療データの増加が見込まれる。このように、外部提供の可否に加えて、患者特定情報の公開の可否について、患者の意思を反映する仕組みを設けることは、診療データの収集の促進につながり、診療データの収集効率（診療データのうち提供可とされる診療データの割合）が高められる。
【００４６】
診療データは過去の症例として医療レベルの質を高める貴重な情報であるから、共有可能な症例の蓄積が豊富になることで、各医療施設１０の診療レベルの質や効率の向上も期待できる。
【００４７】
公開可否情報の設定に関しては、例えば、図７に示すような問い合わせメッセージ４０を、コンソール３６に表示する。公開可否情報についても、提供可否情報と同様に、患者の同意を重視する観点から、初期設定は、公開不可となっている。そこで、こうした問い合わせメッセージ４０を表示することで、オペレータによる設定のし忘れを防止されるようにしている。問い合わせメッセージ４０には、例えば、「患者特定情報を公開しますか？」というメッセージとともに、可否を選択する選択ボタン（「する」、「しない」）が表示される。この選択ボタンのクリックによって、診療データに対して、公開可否情報が設定される。
【００４８】
なお、本実施形態では、問い合わせメッセージを表示することで、可否情報の設定を促す警告を発するようにしているが、音声等によって警告を行ってもよい。
【００４９】
データファイリング部３３は、可否情報が設定された診療データを、個別ＤＢ１９に書き込んで格納する。診療データは、患者ＩＤ毎にファイリングされる。個別ＤＢ１９に追加する診療データの患者ＩＤが、個別ＤＢ１９に存在しない場合には、データファイリング部３３は、新規に患者ＩＤを割り当てて、診療データを格納する。同じ患者ＩＤの診療データが既にある場合には、その患者ＩＤに診療データが追加される。
【００５０】
診療データ提供部３４は、個別ＤＢ１９へ格納される診療データのうち、外部提供可とされた診療データを共有サーバ１３へアップロードする。診療データ提供部３４は、個別ＤＢ１９へ診療データが格納される際に、提供可否情報を調べて、提供可の診療データをアップロードする。また、１件分の診療データを格納する度にアップロードするのではなく、所定の時間に起動して、その時点における未送信分をまとめてアップロードするようにしてもよい。こうした、タイミングや回数はデータ量やネットワークのトラフィック等を考慮して適宜選択される。もちろん、自動的にアップロードする代わりに、送信指示を与えて、アップロードするようにしてもよいし、両者を併用してもよい。
【００５１】
図８は、上述した構成による、診療データのファイリング手順を示すフローチャートである。まず、スキャン画像や電子カルテがファイリング装置１１に取り込まれると、スキャン画像か否かが判定されて、スキャン画像である場合には、索引データ作成部３１によって索引データ作成処理が実行されて索引データが作成される。索引データが作成された後、可否情報設定部３２によって可否情報設定処理が行われる。スキャン画像でない場合には、索引データ作成処理を経ずに、可否情報設定処理が行われる。
【００５２】
可否情報設定処理では、図６，７に示す問い合わせメッセージ３９，４０を表示し、外部提供可否情報の設定を促すとともに、外部提供可の診療データに対しては、公開可否情報の設定を促す。こうした問い合わせメッセージ３９，４０を表示することで、可否情報が確実に設定される。可否情報設定処理の後、データファイリング部３３は、設定された可否情報とともに、診療データを個別ＤＢ１９に格納する。そして、診療データ提供部３１は、所定時間に起動されて、個別ＤＢ１９内の診療データのうち、未送信分の診療データを共有サーバ１３へアップロードする。
【００５３】
図９は、共有サーバ１３の概略構成図である。共有サーバ１３のコントローラ１６は、サーバプログラムを実行することにより、データ登録部４１，配信サービス実行部４２として機能する。データ登録部４１は、ファイリング装置１１からの診療データの登録要求を受け付けて、データ登録処理を実行する。データ登録処理では、診療データに対して、管理ＩＤを割り当てて、割り当てた管理ＩＤと関連付けて診療データを共有ＤＢ１７に格納する。
【００５４】
管理ＩＤは、共有ＤＢ１７内でそこに登録される診療データを患者単位で管理するための識別情報であり、１人の患者に１つずつ割り当てられる。各医療施設１０は、患者に対してそれぞれの施設独自の患者ＩＤが割り当てられるので、１人の患者が共有サーバ１３に接続する複数の医療施設１０で診療を受けた場合には、同一患者が、それぞれの医療施設１０で割り当てられた複数の患者ＩＤを持つことになる。こうした患者ＩＤで診療データを管理すると、同一人の診療データが別々のＩＤで登録されることになり、例えば、１人の患者の複数の医療施設１０に渡る診療履歴を参照することが困難になるなど、不都合が生じる。管理ＩＤは、同一患者に対して各医療施設１０で割り当てられた複数の患者ＩＤに関連付けられた複数の診療データを統合するために用いられる。
【００５５】
管理ＩＤの付与方法としては、医療施設の施設ＩＤと、当該施設で付与された管理ＩＤを組み合わせたものが用いられる。例えば、施設ＩＤが「Ａ」で、その施設で付与された患者ＩＤが「０００１」であれば、管理ＩＤは、「Ａ−０００１」となり、また、施設ＩＤが「Ｂ」で、その施設で付与された患者ＩＤが「０２００」であれば、管理ＩＤは、「Ｂ−０２００」となる。同一人が複数の医療施設１０で診療を受けた場合には、それぞれの施設ＩＤと患者ＩＤの組み合わせが考えられるが、このうち、最初に登録された診療データが帰属する医療施設１０の施設ＩＤとその患者ＩＤとの組み合わせを、共有ＤＢ１７の管理ＩＤとしている。つまり、最初に登録された診療データが、施設ＩＤが「Ａ」の医療施設１０に帰属するものである場合には、管理ＩＤ「Ａ−０００１」が割り当てられ、施設ＩＤが「Ｂ」の医療施設１０に帰属するものである場合には、管理ＩＤ「Ｂ−０２００」が割り当てられる。
【００５６】
管理ＩＤ「Ａ−０００１」の下には、施設ＩＤがＡ〜Ｃの３つの医療施設１０の診療データが１件ずつ登録されており、管理ＩＤ「Ｂ−０２００」の下には、施設ＩＤが「Ｂ」の医療施設１０の１件の診療データと、施設ＩＤが「Ａ」の医療施設１０の３件の診療データからなる合計４件の診療データが登録されている。管理ＩＤ「Ａ−００３１」と「Ｃ−０３０３」の下には、それぞれ診療データが１件ずつ登録されている。
【００５７】
１つの管理ＩＤの下に登録された複数の診療データは、管理ＩＤを介して相互に関連付けられているので、検索時に管理ＩＤが分からなくても、例えば、１つの診療データに対応する患者ＩＤを検索キーとして入力すれば、他の診療データを関連データとして引き出すことができる。
【００５８】
もちろん、上記管理ＩＤの付与方法は、１例であり、共有ＤＢ１７内でユニークになる方法であれば、どのような方法でも構わない。
【００５９】
データ登録部４１には、登録状況判定部４１ａが設けられている。登録状況判定部４１ａは、登録要求のある診療データを受け付けた際に、その診療データに含まれる患者特定情報に基づいて、それと同一の患者の診療データが共有ＤＢ１７に既に登録済みか否かを判定する。
【００６０】
登録状況判定処理では、具体的には、患者特定情報に含まれる、患者名，性別，生年月日などの項目について、共有ＤＢ１７内に登録済みのすべての診療データの患者特定情報と照合して、同一の患者の診療データの有無を調べることにより、登録状況を判定する。照合に当たっては、同姓同名の患者が存在する可能性もあるので、患者名を含む複数の項目が照合され、それら複数の項目が一致した場合に同一の患者であると判定する。
【００６１】
なお、これらの照合によっても同一か否かが不確かな場合には、提供元の医療施設１０に対して問い合わせ通知を送信するなどして、患者の同一性を確認するとよい。患者特定情報としては、上記項目の他に、指紋などの生体認証（バイオメトリクス）情報を使用してもよい。さらに、自治体が発行する住民票コード（住民基本台帳番号）などが使用可能であれば、それを用いてもよい。なお、これらの項目を組み合わせて併用してもよい。
【００６２】
患者特定情報の照合に当たっては、例えば、診療データのうち、患者特定情報を予め抽出し、抽出した情報を元に、すべての診療データに関する患者特定情報の参照可能なテーブルを作成しておくとよい。こうすれば、患者特定情報を参照するために、各診療データへ順次アクセスする必要が無くなるので、照合処理の時間が大幅に短縮される。
【００６３】
図１０に示すように、データ登録部４１は、ファイリング装置１１からの診療データの登録要求を受け付けると、受け付けた診療データから患者特定情報を読み出す。そして、この患者特定情報に基づいて、共有ＤＢ１７内の登録済みの診療データを調べて、その患者が既に登録済みか否かを判定する。登録済みの患者の診療データである場合には、その管理ＩＤの下に診療データを追加登録し、未登録の場合には、新規の管理ＩＤを割り当てて、それに関連付けて診療データを登録する。登録完了後、診療データの提供元の医療施設１０に対して、登録結果を配信する。
【００６４】
さらに、登録状況判定処理の際に、患者の同一性に加えて、診療データの内容の同一性を判定するようにしてもよい。こうした内容判定を行えば、同じ診療データが重複して登録されることを防止できる。
【００６５】
配信サービス実行部４２は、検索処理部４２ａ，編集加工部４２ｂ，症例統計算出部４２ｃを備えている。配信サービス実行部４２は、クライアント端末からの配信要求を受け付けて、共有ＤＢ１７内の診療データを配信する配信サービスを提供する。この配信サービスの提供を受けるクライアント端末は、ファイリング装置１１でもよいし、ファイリング装置１１とは異なる他のパーソナルコンピュータやワークステーションでもよく、通信ネットワーク１４を通じて共有サーバ１３にアクセス可能な端末であればよい。
【００６６】
配信サービスには、例えば、患者指定検索サービス，症例検索サービス，症例統計配信サービスの３種類のサービスがある。患者指定検索サービスは、特定の患者の診療データを検索して配信するサービスである。症例検索サービスは、傷病名や患者の年齢などを検索条件として受け付けて、共有ＤＢ１７に登録済みの診療データの中から、その条件に合致する診療データを抽出して、そのデータを症例データとして配信するサービスである。症例統計参照サービスは、受け付けた算出条件に基づいて、共有ＤＢ１７内の診療データを集計して症例統計を算出し、これを配信するサービスである。
【００６７】
検索処理部４２ａは、共有ＤＢ１７を検索して、検索条件に合致する診療データを抽出する検索処理を実行する。この検索処理では、診療データに含まれるすべてのテキストデータが検索対象項目となる。例えば、カルテがスキャン画像の場合には、それに対応する索引データに含まれる項目が検索対象項目となり、電子カルテデータであれば、全文が検索対象項目となる。
【００６８】
編集加工部４２ｂは、患者特定情報が公開不可の設定になっている診療データを配信する場合に、その診療データ内の患者特定情報を秘匿して、患者特定情報が公開されないように情報秘匿処理を実行する。また、編集加工部４２ｂは、配信するデータに対して種々の編集加工処理を施す。
【００６９】
症例統計算出部４２ｃは、例えば、傷病名を算出条件として受け付けた場合には、当該傷病名が含まれる診療データの件数を集計し、その件数に基づいて年代別あるいは転帰の種類別の統計を算出したり、共有ＤＢ１７が保有する診療データの傷病別の統計を算出する。統計の表示形式は、例えば、表形式やヒストグラムの形式で行われる。
【００７０】
共有サーバ１３は、クライアント端末からの配信要求を、例えば、Ｗｅｂブラウザを通じて受け付ける。クライアント端末は、Ｗｅｂブラウザを通じて共有サーバ１３のＵＲＬ（Uniform Resource Locator）を送信するとともに、ユーザＩＤ（施設ＩＤなど）やパスワードを入力して、共有サーバ１３にログインする。コントローラ１６は、クライアント端末がログインすると、上記各配信サービスのいずれかを選択するサービス選択画面をクライアント端末へ配信する。クライアント端末は、このサービス選択画面を通じてサービスを選択し、その選択情報を共有サーバへ送信する。
【００７１】
図１１に示すように、配信サービス実行部４２は、ファイリング装置１１などのクライアント端末から配信要求を受け付けて、その要求が上記３種類のサービスのいずれであるかを判定し、その判定結果に応じて、処理を振り分ける。配信サービス実行部４２は、サービスの種類を判定すると、例えば、図１２に示すような、検索条件の入力を受け付ける検索条件受付画面４７をクライアント端末へ送信して、検索条件の問い合わせを行う。この検索条件受付画面４７には、検索キーとして入力可能な項目毎の入力欄が設けられている。
【００７２】
この入力欄は、サービスの種類に応じて変更される。例えば、患者指定検索サービスでは、患者名や患者ＩＤなどの患者特定情報が検索キーとして必須項目であるが、他のサービスでは不要であるというように、検索キーとして入力可能な項目は、サービスの種類に応じて異なり、それに応じて、検索条件受付画面４７に表示される項目が決定される。
【００７３】
また、症例検索サービスでは、例えば、検索キーとして、傷病名、転帰、症状、性別、年代等、各種の項目が入力可能となる。これにより、所望する条件に適合する症例を容易に検索することができる。また、症例統計配信サービスの場合には、この検索条件受付画面４７に、統計を算出する算出条件が入力可能となる。算出条件としては、傷病名、年齢、転帰などの他、診療時期や症状などである。
【００７４】
図１３は、患者指定検索手順を示すフローチャートである。配信サービス実行部４２が、検索条件（患者名などの患者特定情報）を受け付けると、検索処理部４２ａは、検索条件に合致する患者の診療データを検索する。検索条件に合致する診療データが無い場合には、検索を終了するか、別の検索条件の入力をするかの問い合わせを行う。
【００７５】
配信サービス実行部４２は、診療データが有る場合には、ユーザのアカウント認証処理を行う。ここで、アカウントとは、指定した患者の診療データに関する参照権限をいう。患者指定検索サービスでは、指定した患者の患者特定情報がすべて要求元のユーザに配信されることになるので、他のサービスとは異なり、共有サーバ１３へのログイン権限とは別に、その診療データに対する参照権限を有するかの認証が必要になる。参照権限は、その診療データの提供元の医療施設１０やその医療施設１０から患者の紹介を受けた医療施設１０に対して与えられる。
【００７６】
アカウント認証処理では、例えば、ユーザＩＤと、診療データの管理ＩＤに含まれる施設ＩＤとを照合して、参照権限の有無を調べる。また、患者の紹介を受けた医療施設１０の場合には、紹介を受けたことを証明する予め発行された受付番号などを調べて、参照権限の有無を調べる。
【００７７】
参照権限が無いと判定されたユーザに対しては、その旨の警告を発する。参照権限が有ると判定されたユーザに対しては、該当患者の診療データリストを配信する。この診療データリストには、患者の登録済みの診療データの一覧が時系列で表示される。各データのタイトルには、受診した医療施設名、診療時期、傷病名などが表示される。タイトルの横には、例えば、データを指定するためのチェックボックスが設けられており、このチェックボックスにチェックを入れることで指定がなされる。この指定は、複数のデータを指定することも可能であり、全データを指定することも可能である。
【００７８】
また、この診療データリストでは、病名、診察時期、医療施設など、診療データの絞り込みを行う条件を入力が可能となっている。これにより、特定の医療施設の診療データだけを指定したり、特定の傷病に関する診療データについて、異なる医療施設１０に帰属する複数の診療データを指定したりすることも可能である。これ以外にも、絞り込み条件の入力の仕方により、種々の閲覧方法を選択することができる。特に、過去の診療履歴を遡って確認することは、原因が特定されていない疾病の研究や究明に必要な場合が多い。本発明によれば、こうした遡及的な履歴の参照が容易となる。
【００７９】
配信サービス実行部４２は、入力された絞り込み条件に従って絞り込み処理を行い、処理済みの診療データリストを配信する。配信サービス実行部４２は、こうしたリストを通じて指定されたデータを配信する。本発明では、従来のように、同一の患者に関する診療データを、医療施設１０毎に分類して管理するのではく、複数の医療施設１０に帰属する同一の患者の診療データを、その患者単位で管理しているので、複数の医療施設１０に帰属する診療データを横断的に閲覧することが可能となり、従来と比べて、検索効率が向上する。
【００８０】
この診療データの配信方法としては、例えば、１件の診療データに含まれるすべてのデータ（カルテ及び検査画像）を一括して配信してもよいし、検査画像へのリンク情報を付したカルテデータのみを配信し、要求に応じて検査画像を後から配信するようにしてもよい。データを分割して配信すれば、無駄なデータ配信がなくなり、表示速度の高速化や通信トラフィックの減少などの効果も見込める。
【００８１】
また、配信前に、診療データ内に、その中の特定項目（例えば、初診時の症状、治療法、処置・処方効果など）へのリンク情報を埋め込んでおき、クライアント端末で診療データを閲覧する際に、そのデータ内の上記特定項目へジャンプできるようにしてもよい。こうすれば、確認したい項目へ素早くアクセスすることができる。診療データは、モニタ画面上で複数のページに渡って表示されることになるので、こうした機能を設けることで、例えば、スクロール量が減るなど、閲覧性が向上する。リンク情報を診療データに埋め込む処理は、検索の応答時間が遅延しないように、例えば、データ登録部４１が診療データの登録時に予め行っておくとよい。
【００８２】
また、患者指定検索サービスでは、特殊表示要求を受け付けており、その要求に応じて、編集加工部４２ｂが診療データを編集加工して、その編集結果を配信する。特殊表示処理の内容としては、例えば、複数の診療データの条件に応じた並べ替え処理や、各種医療団体が策定した診療ガイドラインと診療データの比較表示処理などであるこれにより、実際に行われた治療方針や治療内容が適正であったか否かのチェックを行うことができる。
【００８３】
図１４は、症例検索手順を示すフローチャートである。配信サービス実行部４２が、検索条件（傷病名など）を受け付けると、検索処理部４２ａは、検索条件に合致する症例データを検索する。検索条件に合致する症例データ（診療データ）が無い場合には、検索を終了するか、別の検索を行うかの問い合わせを行う。症例データが有る場合には、抽出した症例データの症例リストを作成して、これを配信する。
【００８４】
症例リストには、傷病名の他に、例えば、症状、性別、年齢、住所、転帰などの項目が表示され、患者名は表示されない。表示する項目についても、患者が特定されないように、例えば、年齢については年代（４０代、５０代など）までにとどめたり、住所については都道府県名にとどめるなど、一部を省略することにより詳細な表示を避けて、概略的に表示される。この症例リストには、入力した検索条件に合致するすべての症例の一覧が表示されるが、さらに、絞り込み条件が入力された場合には、その条件に従って絞り込み処理を行い、処理済みの症例リストを配信する。
【００８５】
編集加工部４２ｂは、症例リストを通じて指定された症例データについて、患者特定情報の公開の可否を調べる。そして、公開不可の設定がなされている場合には、その患者特定情報秘匿処理を行う。秘匿される情報は、患者特定情報のうち、少なくとも患者名と、住所や電話番号などの連絡先である。住所については、町名や番地などの一部が秘匿され、都道府県名などは公開される。もちろん、都道府県名を秘匿対象としてもよい。患者特定情報のうち、どこまでを秘匿対象とするかについては、患者が特定されない範囲で、適宜変更してもよい。
【００８６】
また、秘匿方法としては、例えば、症例データがスキャン画像の場合には、秘匿対象部分に対して塗りつぶし処理がなされ、電子カルテデータの場合には、秘匿対象部分のデータが削除される。こうして秘匿処理が施された症例データが配信される。このような処理を行うようにすれば、登録された診療データを、上記患者指定検索サービスと症例検索サービスの両方に利用できるので、それぞれのサービスに応じたデータを保有する必要がなくなり、共有ＤＢ１７の省スペース化に寄与する。また、複数の医療施設１０から収集した診療データを利用するので、豊富な症例を閲覧することが可能となる。
【００８７】
図１５は、症例統計参照手順を示すフローチャートである。配信サービス実行部４２は、算出条件を受け付けると、症例統計算出部４２ｃがその算出条件に応じて症例統計を算出する。この算出した症例統計が配信される。配信した症例統計について、表示形式などについて編集要求がある場合には、その要求に応じて編集処理を実行して、編集結果を配信する。この症例統計は、複数の医療施設１０から収集した、実際の診療データに基づくものであるので、客観性が確保される。
【００８８】
上記実施形態では、患者特定情報の公開の可否をファイリング装置で設定し、診療データの共有サーバへの登録時にその設定情報を送信するようにしているが、登録後に、設定情報の変更要求を受け付けて設定情報を更新できるようにしてもよい。
【００８９】
上記実施形態では、症例検索サービスで配信する症例データについて、患者特定情報の公開が不可とされているものについては、すべて秘匿処理が行われるようにしているが、検索要求元のユーザが当該症例データの提供元であるような場合には、秘匿処理を行わずに、公開するようにしてもよい。この場合には、共有サーバが、配信対象の症例データの帰属先（提供元）と症例検索の要求元の照合結果に応じて、秘匿処理の必要性を判定する。
【００９０】
上記実施形態では、ファイリング装置と電子カルテシステムをそれぞれ独立した装置の形態で説明しているが、電子カルテシステムにファイリング装置の機能を設けて、両者を一つの装置で構成してもよい。
【図面の簡単な説明】
【００９１】
【図１】医用ネットワークシステムの構成図である。
【図２】診療データファイリング装置の概略構成図である。
【図３】診療データの構成例を示す説明図である。
【図４】カルテ用紙をスキャンした場合の確認画面の例である。
【図５】放射線フイルムをスキャンした場合の確認画面の例である。
【図６】診療データの外部提供に関する問い合わせメッセージの例である。
【図７】患者特定情報の公開に関する問い合わせメッセージの例である。
【図８】診療データファイリング手順を示すフローチャートである。
【図９】共有サーバの概略構成図である。
【図１０】共有サーバへの診療データ登録手順を示すフローチャートである。
【図１１】配信サービス手順を示すフローチャートである。
【図１２】条件入力画面の説明図である。
【図１３】患者指定検索手順を示すフローチャートである。
【図１４】症例検索手順を示すフローチャートである。
【図１５】症例統計参照手順を示すフローチャートである。
【符号の説明】
【００９２】
１０  医療施設
１１  診療データファイリング装置
１２  データセンタ
１３  診療データ共有サーバ
１４  通信ネットワーク
１６  コントローラ（共有サーバ用）
１７  共有ＤＢ
１８  コントローラ（ファイリング装置用）
１９  個別ＤＢ
３１  索引データ作成部
３２  可否情報設定部
３３  データファイリング部
３４  診療データ提供部
４１  データ登録部
４２  配信サービス実行部
４２ａ  検索部
４２ｂ  編集加工部
４２ｃ  症例統計算出部
【図１】
2008204378.tif 000003
【図２】
2008204378.tif 000004
【図３】
2008204378.tif 000005
【図４】
2008204378.tif 000006
【図５】
2008204378.tif 000007
【図６】
2008204378.tif 000008
【図７】
2008204378.tif 000009
【図８】
2008204378.tif 000010
【図９】
2008204378.tif 000011
【図１０】
2008204378.tif 000012
【図１１】
2008204378.tif 000013
【図１２】
2008204378.tif 000014
【図１３】
2008204378.tif 000015
【図１４】
2008204378.tif 000016
【図１５】
2008204378.tif 000017