JP2014120094A

JP2014120094A - 医療情報検索システム及び医療情報検索装置

Info

Publication number: JP2014120094A
Application number: JP2012276574A
Authority: JP
Inventors: Sayaka Takahashi; 紗佳高橋
Original assignee: Toshiba Corp; Toshiba Medical Systems Corp
Current assignee: Toshiba Corp; Canon Medical Systems Corp
Priority date: 2012-12-19
Filing date: 2012-12-19
Publication date: 2014-06-30

Abstract

【課題】利用者による医療情報の検索処理の効率化、迅速な取得、容易な把握を可能とする医療情報検索システム及び医療情報検索装置を提供する。
【解決手段】患者の検査データを閲覧するクライアント端末と、医療機関から送信される検査データを登録、管理するとともに、クライアント端末からの要求に基づいて検査データを特定のグループごとに表示させるサーバ装置と、を備える医療情報検索システムであって、サーバ装置は、登録された検査データに対して症例ＩＤを付与する症例ＩＤ付与部と、症例ＩＤが付与された検査データを、同じ症例ＩＤが付与された検査データごとにグループとしてまとめて管理する症例データ管理部とを備える。
【選択図】図３

Description

本発明の実施の形態は、医療情報検索システム及び医療情報検索装置に関する。

現在の医療制度の下では、ある医療機関を受診した際の検査や診療の情報は、当該医療機関にのみ保管されることが基本となっている。従って、医療機関の間で検査や診療の情報がやり取りされることはまれであり、例えば、同じ検査であっても異なる医療機関で重ねて受診することになってしまうこともあって無駄である。

患者にしても、症状、状態に合わせて、例えば、診察を受ける医療機関、手術を受ける医療機関、術後（リハビリ等）に受診する医療機関、というように複数の医療機関に掛かることも珍しいことではない。このような状況の下、患者の医療情報を各医療機関で個別に保有しているのでは利用しにくい。

一方、近年患者の内部情報を医用画像等の医療情報を取得する、例えば、Ｘ線ＣＴ装置（computed tomography：コンピュータ断層撮影装置）や、磁気共鳴診断装置（ＭＲＩ：magnetic resonance imaging）医用画像診断装置の技術が進展している。取得された医療情報は電子的に保管することができるため、例えば、インターネット等の公衆回線等を利用することにより、当該医療情報を簡単にやり取りすることが可能とされている。

さらには、医療情報を単数、或いは、複数の医療機関で共同して保管する試みもなされている（例えば、以下の特許文献１参照）。

このように各医療機関がそれぞれで管理していた患者の医療情報を、例えば地域でまとめて管理することで、複数の医療機関の間で当該医療情報の共有が可能となる。従って、例えば、ある医療機関を受診していた患者に関する医療情報に対して他の医療機関からアクセスすることもできる。

特開２０１０−０７９７１２号公報

しかしながら、他の医療機関を受診した患者の医療情報にアクセスして検査データを取得しても、個々の検査データの取得に止まることが多い。例えば、ある検査データに関連する他の検査に関する情報や、当該検査データ自体の過去の検査データを取得することが非常に困難である。もちろん完全に不可能なわけではないが、関連する検査データを網羅的に把握するには、手間、時間が掛かりすぎる。

これは、例えば、複数の医療機関から送られてくる非常に膨大な１つ１つの検査データが、それぞれバラバラにまとまりなく管理されていることもその一因であるとも考えられる。

本発明は上記課題を解決するためになされたものであり、本発明の目的は、患者の疾病について関連する一連の医療情報をまとめて管理することにより、利用者による医療情報の検索処理の効率化、迅速な取得、容易な把握を可能とする医療情報検索システム及び医療情報検索装置を提供することにある。

請求項１に記載の発明の特徴は、患者の検査データを閲覧するクライアント端末と、医療機関から送信される検査データを登録、管理するとともに、クライアント端末からの要求に基づいて検査データを特定のグループごとに表示させるサーバ装置と、を備える医療情報検索システムであって、サーバ装置は、登録された検査データに対して症例ＩＤを付与する症例ＩＤ付与部と、症例ＩＤが付与された検査データを、同じ症例ＩＤが付与された検査データごとにグループとしてまとめて管理する症例データ管理部とを備える。

請求項６に記載の発明の特徴は、医療情報検索装置において、患者の検査データを登録する検査データ登録部と、登録された検査データに対して症例ＩＤを付与する症例ＩＤ付与部と、症例ＩＤが付与された検査データを、同じ症例ＩＤが付与された検査データごとにグループとしてまとめて管理する症例データ管理部とを備える。

実施の形態における医療情報検索システムの全体構成を示すブロック図である。第１の実施の形態におけるサーバ装置の内部構成を示すブロック図である。実施の形態における検査データの保存、管理の流れを示すフローチャートである。実施の形態における検査データに対して症例ＩＤを付与する流れを示すフローチャートである。実施の形態における症例ＩＤ付与部の内部構成を示すブロック図である。実施の形態における検査データが新規に登録された状態を示すテーブルの一例である。実施の形態におけるクライアント端末の表示部での表示態様の一例を示す画面例である。実施の形態におけるクライアント端末の表示部での表示態様の一例を示す画面例である。実施の形態における病名編集の大まかな流れを示すフローチャートである。実施の形態における病名編集の詳細な流れを示すフローチャートである。実施の形態における病名編集部の内部構成を示すブロック図である。実施の形態におけるクライアント端末の表示部での病名編集中の表示態様の一例を示す画面例である。実施の形態におけるクライアント端末の表示部での病名編集中の表示態様の一例を示す画面例である。実施の形態における病名と症例ＩＤとの関係を示すテーブルの一例である。実施の形態における病名編集の詳細な流れを示すフローチャートである。実施の形態における病名の入力の際（関連症例ＩＤの付与を行う際）に表示されるクライアント端末の表示部での表示態様の一例を示す画面例である。実施の形態における病名とキーとの関係を示すテーブルの一例である。実施の形態における関連症例ＩＤ付与の状態を示すテーブルの一例である。実施の形態における関連症例ＩＤ付与の状態を示すテーブルの一例である。実施の形態における選択されたグループとともに同じ関連症例ＩＤが付与されているグループをも表示させる場合の流れを示すフローチャートである。実施の形態におけるクライアント端末の表示部での表示態様の一例を示す画面例である。実施の形態におけるクライアント端末の表示部での表示態様の一例を示す画面例である。実施の形態における症例結合・分離部の内部構成を示すブロック図である。実施の形態における検査データの結合、或いは、分離の流れを示すフローチャートである。実施の形態における症例の結合を行う際のクライアント端末の表示部での表示態様の一例を示す画面例である。実施の形態における症例の結合を行う際のクライアント端末の表示部での表示態様の一例を示す画面例である。第２の実施の形態における医療情報検装置の内部構成を示すブロック図である。第２の実施の形態における医療情報検部の内部構成を示すブロック図である。

以下、本発明の実施の形態について図面を参照して詳細に説明する。

（第１の実施の形態）
図１は、実施の形態における医療情報検索システムＳの全体構成を示すブロック図である。医療情報検索システムＳは、複数の医療機関Ｈ１ないしＨ３（以下、これら複数の医療機関Ｈ１ないしＨ３をまとめて適宜「医療機関Ｈ」と表わす）と、当該医療機関Ｈにおいて実施された検査データを保管するデータセンタＤＣと、これらを互いに接続する通信ネットワークＮから構成される。

図１において破線で示される医療機関Ｈ内には、医師や技師といった医療従事者が必要に応じて患者の検査データを閲覧する際に利用するクライアント端末１が設けられている。また、患者に対して検査を行う際に、例えば、図示しない医用画像診断装置において得られた患者の内部情報等の検査データを記憶しておくデータベース２も設けられている。

なお、ここでは説明の便宜上、各医療機関Ｈ内に設けられている各種機器のうち、特にクライアント端末１とデータベース２のみを示しているが、これらの他にも様々な機器が設けられていても良い。また、例えば、病院情報管理システム（ＨＩＳ：Hospital Information System）、放射線部門情報管理システム（ＲＩＳ：Radiological Information System）、医用画像管理システム（ＰＡＣＳ：Picture Archiving Communication System）といった各種管理システムが各医療機関Ｈ内に構築されていても良い。

クライアント端末１は、医療従事者が医用画像等の各種検査データを利用して患者の診察を行ったり、或いは、検査データの整理等を行う際に使用されるワークステーション等である。従って、図１には図示していないが、クライアント端末１は、少なくとも、キーボード等の入力装置、検査データを表示する表示装置といったワークステーションが備えている各種装置を備えている。またその処理能力に関しても、サーバ装置３から送信されるサーバ装置３において管理される検査データを最低限表示することができれば足りる。

データベース２は、医療機関Ｈにおいて行われる各種検査の結果（検査データ）を一時的に記憶しておく。データベース２に記憶された検査データは、適宜データセンタＤＣに設けられているデータベース４に送信される。

各医療機関Ｈが検査データとしていずれのデータをデータセンタＤＣへと送信するかは、各医療機関Ｈ内での取り決め、或いは、データセンタＤＣとの間の取り決めによって自由に設定することができる。また、どのようなタイミングで各医療機関ＨからデータセンタＤＣへ検査データが送信されるかについても任意に設定することができる。

なお、図１に示す医療情報検索システムＳでは、医療機関Ｈとして３つ（３カ所）の医療機関Ｈ１ないしＨ３が後述する通信ネットワークＮに接続されているが、通信ネットワークＮに接続される医療機関Ｈの数は単数、或いは複数のいずれでも良く、その数は任意である。但し、ある地域において中核となるデータセンタＤＣに当該地域に設けられている医療機関Ｈの検査データを送り、医療機関Ｈが共同してまとめて検査データを管理する場合には、医療機関Ｈは複数通信ネットワークＮに接続されることになる。

データセンタＤＣは、通信ネットワークＮを介して接続される医療機関Ｈから送信される検査データを保管、管理する装置、或いは、施設である。図１において一点鎖線で示されるデータセンタＤＣ内には、クライアント端末１からの要求に基づいて保管、管理している検査データを検索し、検査データをクライアント端末１の表示部に表示させるサーバ装置３と、各医療機関Ｈから送られてくる検査データを保管するデータベース４とが設けられている。従って、クライアント端末１とサーバ装置３との関係は、シンクライアントの関係であっても良い。

なお、ここでは説明の便宜上、データセンタＤＣ内に設けられている各種機器のうち、特にサーバ装置３とデータベース４のみを示しているが、これらの他にも様々な機器が設けられていても良い。

通信ネットワークＮは、各医療機関ＨとデータセンタＤＣとをそれぞれつなぎ、互いの間で、検査データのやりとりを可能とする。通信ネットワークＮの例としては、ＬＡＮ（Local Area Network）やインターネット等のネットワークを挙げることができる。また、この通信ネットワークＮで使用される通信規格は、ＤＩＣＯＭ（Digital Imaging and Communication in Medicine）等、いずれの規格であっても良い。

図２は、第１の実施の形態におけるサーバ装置３の内部構成を示すブロック図である。サーバ装置３は、ＣＰＵ（Central Processing Unit）３ａと、ＲＯＭ(Read Only Memory)３ｂと、ＲＡＭ（Random Access Memory）３ｃと、通信制御部３ｄと、記憶部３ｅ及び入出力インターフェイス３ｆがバス３ｇを介して接続されている。入出力インターフェイス３ｆには、検査データ登録部３ｈと、症例ＩＤ付与部３ｉと、症例データ管理部３ｊと、病名編集部３ｋと、症例結合・分離部３ｌと、症例ＩＤ更新部３ｍとが接続されている。

ＣＰＵ３ａは、例えばクライアント端末１からの入力信号に基づいてＲＯＭ３ｂからサーバ装置３を起動するためのブートプログラムを読み出して実行し、記憶部３ｅに格納されている各種オペレーティングシステムを読み出す。またＣＰＵ３ａは、入出力インターフェイス３ｆを介して、図２において図示していないその他の外部機器からの入力信号に基づいて各種装置の制御を行う。さらにＣＰＵ３ａは、ＲＡＭ３ｃや記憶部３ｅ等に記憶されたプログラム及びデータを読み出してＲＡＭ３ｃにロードするとともに、ＲＡＭ３ｃから読み出されたプログラムのコマンドに基づいて、検査データの登録のための処理やデータの計算、加工等、一連の処理を実現する処理装置である。

通信制御部３ｄは、ＬＡＮカードやモデム等の手段であり、サーバ装置３をインターネットやＬＡＮ等の通信ネットワークＮに接続することを可能とする手段である。通信制御部３ｄを介して通信ネットワークＮと送受信したデータは入力信号または出力信号として、入出力インターフェイス３ｆ及びバス３ｇを介してＣＰＵ３ａに送受信される。

記憶部３ｅは、半導体や磁気ディスクで構成されており、ＣＰＵ３ａで実行されるプログラムやデータが記憶されている。

なお、サーバ装置３に設けられている検査データ登録部３ｈ、症例ＩＤ付与部３ｉ、症例データ管理部３ｊ、病名編集部３ｋ、症例結合・分離部３ｌ、症例ＩＤ更新部３ｍについての機能、働きについては、後述する検査データの保存、管理の流れを説明する際に併せて説明する。

そこで、まず、新規に医療機関Ｈから送られてきた検査データに対して管理をする上で必要な「症例ＩＤ」を付与した上で、症例ＩＤごとにグループで保存、管理する流れについて説明する。

図３は、実施の形態における検査データの保存、管理の流れを示すフローチャートである。また、図４は、図３に示すフローチャートの中で、特に検査データに対して症例ＩＤを付与する流れを示すフローチャートである。また、適宜、図５ないし図８も利用しながら以下、検査データの保存、管理の流れを説明する。

まず、データセンタＤＣにおけるサーバ装置３の検査データ登録部３ｈは、通信ネットワークＮと接続されている各医療機関Ｈから、それぞれの医療機関Ｈにおいて実施された患者に対する検査の結果（検査データ）の受信の有無を判断する（図３のＳＴ１）。医療機関Ｈは、新たな検査データが発生した場合には、これら検査データをまとめて登録、管理する役割を持つデータセンタＤＣへと送信する。但し、送信は、例えば、医療機関Ｈにおける全ての検査が終了された後、等、予め定められた任意のタイミングで行われることになる。

医療機関Ｈからから新規の検査データが送信されたか否かの判断によって、検査データ登録部３ｈが新規の検査データを受信していないと判断した場合には（ＳＴ１のＮＯ）、そのまま待機となる。

一方、新規の検査データが送信されて来た場合には（ＳＴ１のＹＥＳ）、まず受信した新規の検査データをひとまず登録する（ＳＴ２）。登録先は、データベース４であっても、例えば、後述する症例ＩＤが付与されるまでは一時的にサーバ装置３の記憶部３ｅに登録（記憶）されるようにしても良い。

次に、登録された新規の検査データをグループで管理することを可能とするために、当該検査データに対して症例ＩＤを付与する（ＳＴ３）。ここで、「症例ＩＤ」とは、検査データが表わす「症例に関する病名」ごとに付与されるＩＤのことであり、医療情報を検索する際に用いられる。従って、同じ症例ＩＤが付与された検査データであれば、それらは互いに同じ病名を持つ疾病に関する検査データであり、同じグループに含まれる検査データであることが明らかとなる。

症例ＩＤの付与は、サーバ装置３に設けられている症例ＩＤ付与部３ｉにおいて行われる。図５は、実施の形態における症例ＩＤ付与部３ｉの内部構成を示すブロック図である。症例ＩＤ付与部３ｉは、受信部１１と、検査データ取得部１２と、判断部１３と、比較部１４と、ＩＤ付与部１５と、症例ＩＤが付与された検査データをデータベース４において保存、管理するために送信する送信部１６とから構成される。

なお、これら症例ＩＤ付与部３ｉを構成する各部の機能、働きについては、以下に説明する検査データの保存、管理の流れの中で適宜説明する。また、適宜具体例を挙げて説明を行うことが理解に資する。そこで、図６に示すテーブルに表わされている検査データを例に挙げることとする。

図６は、実施の形態における検査データが新規に登録された状態を示すテーブルの一例である。当該テーブルは、データベース４内に設けられるものであり、各医療機関Ｈから送信された検査データに対して最終的に症例ＩＤが付与された検査データが患者ごとに登録されている。従って、当該テーブルには、ある患者がこれまで受診してきた検査の結果がまとめて保存、管理されていることになる。

当該テーブルの最上段に示されているように、登録される検査データを示す項目として、左から「治療／検査／投薬」、「病院」、「実施日」、「結果／所見」、及び「症例ＩＤ」といった５つの項目が設けられている。１つの検査データは、これらの項目をもって特定され登録されている。すなわち、図６に示すテーブルでは、全てがある患者が受診してきた結果の検査データではあるが、１行１行が異なる１つずつの検査データを示していることになる。

例えば、項目の行を除き上から６つ目に示されている検査データは、「臨床化学検査（治療／検査／投薬）」であり、当該検査は、「Ｂ病院」において「２０１０年１１月１４日」に行われており、当該検査結果に対する医療従事者の「結果／所見」は、「血清カリウム値上昇」とのことである。また、この検査データに対して付与された症例ＩＤは、「１０２」である。本発明の実施の形態におけるデータセンタＤＣでは、このようなテーブルを用いて検査データを保存、管理している。

ところで症例ＩＤの付与は、以下の流れに沿って行われる。図４は上述したように、検査データに対して症例ＩＤを付与する流れを示すフローチャートである。ここではまず、検査データ取得部１２において、一旦登録された新規の検査データを取得する（ＳＴ１１）。これは、症例ＩＤを付与するに当たって必要な情報を取得するためであり、また、症例ＩＤを新たな情報として付加するためである。

ここでは、図６のテーブルに示されている検査データのうち、上２つの行にそれぞれ示されている「インターフェロン」と「血液検査」という２つの検査データを例に挙げて検査データの保存、管理の流れについて説明する。これら説明のために例として挙げる「インターフェロン」と「血液検査」という２つの検査データは、いずれも「Ｄ病院」で同じ実施日（２０１１年０２月０８日）に行われた検査の結果である。

なお、ここで症例ＩＤの付与は、検査データごとに行われる処理である。従って、まず、「インターフェロン」と示されている検査データに対する症例ＩＤの付与について説明する。

新規に登録された検査データが検査データ取得部１２において取得されると、取得された新規な検査データが判断部１３へと送信される。ここでの「新規な検査データ」とは、同一の患者に関する、上述した「インターフェロン」である。判断部１３では、検査データ取得部１２において取得された「新規な検査データ（インターフェロン）」を確認し、当該新規な検査データと同じ検査データが既に登録されているか否かを確認する（ＳＴ１２）。

判断部１３が図６に示すテーブルに登録されている検査データを検索して既登録の有無を判断する。ここでは、新規な検査データである「インターフェロン」と同じ検査データである「インターフェロン」という検査データが該当する同一患者について既に登録されているか否かが判断される（ＳＴ１３）。その結果、「登録済みの検査データ」がある場合には（ＳＴ１３のＹＥＳ）、当該登録済みの検査データを取得して以下に説明する比較を行う。ここで新規な検査データと同じ検査データで登録済みのものが複数ある場合には、これら全ての検査データを取得する。

判断部１３は、取得した登録済みの検査データの中で最も実施日が新しい検査データの当該実施日に関する情報を把握する。同時に新規な検査データの実施日に関する情報も把握する（ＳＴ１４）。

具体的には、上述したようにここでは新規な検査データが「インターフェロン」である。図６に示すテーブルの一例では、この新規な検査データは、項目の欄を除き上から２行目、色つきの下側に示されている。なおこの新規な検査データである「インターフェロン」については、症例ＩＤが示されているが、これは図６に示すテーブルの一例が症例ＩＤが付与された後の状態を示しているからであり、現段階ではまだ症例ＩＤが付与されていないので、当該欄は空欄となる。また、「インターフェロン」の上に示されている「血液検査」の検査データについても同様である。

登録済みの検査データとして取得された検査データは、新規な検査データと同様「インターフェロン」に関する検査データである。図６のテーブルでは、項目の欄を除き上から４行目、及び、１１行目に示されている。４行目の「インターフェロン」という検査データによると、当該検査データは、「Ｄ病院」で「２０１０年１２月１３日」に実施された検査に関するデータであり、「副作用無」との「結果／所見」が示されている。一方、１１行目の「インターフェロン」という検査データによると、当該検査データは、「Ａ病院」で「２０１０年０８月２９日」に実施された検査に関するデータであり、「副作用（発熱）有」との「結果／所見」が示されている。

判断部１３では、新規な検査データの実施日である「２０１１年０２月０８日」を便宜上、「実施日α」として把握する。一方、同じ検査データで登録済みの「インターフェロン」のうち、当該実施日αに近い日に行われた既に登録済みの検査データの実施日、つまり、既に登録済みの検査データの中で最も新しい検査データの実施日を「実施日β」として把握する（ＳＴ１４）。ここでは、「実施日β」は、Ｄ病院で行われた４行目の検査データの実施日である「２０１０年１２月１３日」となる。

比較部１４では、判断部１３から当該実施日に関する情報を受信して、比較を行う（ＳＴ１５）。ここでは、新規な検査データの「実施日α」と既に登録済みの検査データのうち最新の実施日である「実施日β」とを比較する。実施日αである「２０１１年０２月０８日」は実施日βである「２０１０年１２月１３日」から数えて３０日以内ではない。従って、この場合（ＳＴ１５のＮＯ）は、比較部１４は、この結果を判断部１３へと送る。

ここで両実施日の間が「３０日」離れているか否かを判断の条件とするのは、一般的に、所定の期間内に複数の検査がなされていれば、これらの検査は同じ疾病（症例）について行われ、患者も再診として医療機関に当該疾病の治療に来ているものと考えることができるからである。なお、この「３０日」という期間については、任意に設定することができる。また、患者の症例を基に患者ごとに設定しても良い。

判断部１３では、さらに、当該検査データについて、同じ医療機関Ｈからまとめて送られてきた他の検査データの有無、すなわち当該検査データよりも前に症例ＩＤが付与された他の検査データがないか否かを判断する（ＳＴ１６）。このような判断を行うのは、同じ医療機関Ｈからまとめて送られてくる検査データは、当該患者に対してまとめて行われた検査の結果である可能性が高いからである。判断部１３では、例えば、医療機関Ｈから送られてきた日付けを基に当該患者に関する他の検査データがないか判断する。

まとめて送信されて来た検査データのうち、症例ＩＤが最初に付与される検査データについては、当該検査データ以前に症例ＩＤが付与された検査データは存在しない（ＳＴ１６のＮＯ）。判断部１３ではＩＤ付与部１５に当該新規な検査データに対して新規の症例ＩＤを付与するように指示する（ＳＴ１７）。図６に示すテーブルに明らかなように、これまで付与されてきた症例ＩＤは「１０３」であるので、今回は「１０４」という症例ＩＤが付与される。

次に、図６のテーブルに新規な検査データとして示されているもう１つの検査データ（血液検査）についても症例ＩＤの付与に当たっての上述した処理が行われる。「血液検査」に関する検査データも登録済みの検査データが存在する（図６参照）。ここでは、項目の欄を除き上から３行目、及び、１９行目（最下段）に示されている。３行目の「血液検査」の検査データによると、当該検査データは、「Ｄ病院」で「２０１０年１２月１３日」に実施された検査に関するデータであり、「正常」との「結果／所見」が示されている。一方、１９行目の「血液検査」の検査データによると、当該検査データは、「Ａ病院」で「２０１０年０８月２４日」に実施された検査に関するデータであり、「異常有」との「結果／所見」が示されている。

まず、新規の検査データの実施日（α）と、当該実施日に最も近い実施日（β）とが把握された後（ＳＴ１４）、比較部１４において両者が比較される（ＳＴ１５）。ここでは、実施日αは実施日βから３０日以内ではないので（ＳＴ１５のＮＯ）、判断部１３がさらに、当該新規の検査データの他にひとまとめの他の検査データがあるか否か、判断を行う（ＳＴ１６）。

この場合、上述したように、既にひとまとめで医療機関Ｈから送信されて来た他の検査データ（インターフェロンの検査データ）があることから、この他の検査データに対して付与された（直近に付与された）症例ＩＤを付与する（ＳＴ１８）。ここでは症例ＩＤとして「１０４」が付与される。

これで図６に示すテーブルに新規な検査データとして表わされた検査データに対して症例ＩＤが付与される処理について説明した。ただ、実施日の比較において、最も遠い実施日をもつ検査データとの比較については、上述した例では説明できないので、改めて以下において説明する。

ここで例に挙げるのは、「点滴」に関する検査データである。図６に示すテーブルでは、項目の欄を除き上から１３行目、１５行目、及び、１８行目に示されている。１３行目の「点滴」の検査データによると、当該検査データは、「Ａ病院」で「２０１０年０８月２７日」に実施された検査に関するデータであり、「食欲不振のため」との「結果／所見」が示されている。また、１５行目の「点滴」の検査データによると、当該検査データは、同じく「Ａ病院」で「２０１０年０８月２６日」に実施された検査に関するデータであり、「食欲不振のため」との「結果／所見」が示されている。一方、１８行目の「点滴」の検査データによると、当該検査データは、「２０１０年０８月２４日」に実施された検査に関するデータであり、「病院」及び「結果／所見」は、上述の８月２６日の検査データと同じ内容である。

最も古い検査データは、１８行目の「点滴」の検査データである。そこで、図４に示すフローチャートに従って、上述したように症例ＩＤの付与に関する処理が行われる。ここでは、まず、判断部１３が登録済みの検査データがあるか否かを判断する（ＳＴ１３）。図６のテーブルに示すように、当該血液検査に関する検査データに関して登録済みの検査データはない（ＳＴ１３のＮＯ）。そこで判断部１３はさらに、ひとまとめの他の検査データの有無について判断を行うが、当然のことながらひとまとめに送信されて来た検査データの中で当該検査データの前に症例ＩＤが付与された検査データはないので（ＳＴ１６のＮＯ）、新規な症例ＩＤが付与される（ＳＴ１７）。ここでは、「１０１」という症例ＩＤが付与される。

次の「点滴」に関する検査データは、「２０１０年０８月２６日」に実施されたデータである。この実施日が実施日αとなる。一方、実施日βとなるのは、上述した既に症例ＩＤが付与された「点滴」に関する検査データが行われた「２０１０年０８月２４日」である。判断部１３がこれらの実施日に関する情報を取得して、比較部１４に送信する（ＳＴ１４）。比較部１４では、それぞれの実施日を比較する（ＳＴ１５）。

両者の実施日は２日しか異ならないため、「３０日以内」との条件に該当する（ＳＴ１５のＹＥＳ）。従って、今度は、検査データに関して最も古い実施日となる日に行われた検査データの実施日γを取得する（ＳＴ１９）。但し、この場合は、対象となる実施日αの前に実施された「点滴」に関する検査データは上述した実施日βに行われたデータしかないので、当該実施日βの実施日が実施日γとなる。従って、実施日γは「２０１０年０８月２４日」であり、実施日αと比較しても３０日以内である（ＳＴ２０のＹＥＳ）。

そこで、判断部１３は、比較部１４の比較結果に基づいて「２０１０年０８月２６日」に実施された点滴の検査データに対して、登録済みの検査データ（「２０１０年０８月２４日」実施）に付与されている症例ＩＤを付与する（ＳＴ２１）。ここでは、「１０１」という症例ＩＤが付与される。

さらに、「２０１０年０８月２７日」に実施された点滴についての検査データに対する症例ＩＤの付与に関する処理の流れを説明する。この実施日が実施日αとなる。一方、実施日βとなるのは、上述した既に症例ＩＤが付与された「点滴」に関する検査データが行われた「２０１０年０８月２６日」である。判断部１３がこれらの実施日に関する情報を取得して、比較部１４に送信する（ＳＴ１４）。比較部１４では、それぞれの実施日を比較する（ＳＴ１５）。

両者の実施日は１日しか異ならないため、「３０日以内」との条件に該当する（ＳＴ１５のＹＥＳ）。従って、今度は、検査データに関して最も古い実施日となる日に行われた検査データの実施日γを取得する（ＳＴ１９）。該当する検査データは、「２０１０年０８月２４日」に実施された検査データであり、当該日にちが実施日γとなる。実施日αと実施日γとを比較すると、両者の実施日は３日しか異ならないため、「３０日以内」との条件に該当する（ＳＴ２０のＹＥＳ）。

そこで、判断部１３は、比較部１４の比較結果に基づいて「２０１０年０８月２７日」に実施された点滴の検査データに対して、登録済みの検査データ（「２０１０年０８月２４日」実施）に付与されている症例ＩＤを付与する（ＳＴ２１）。ここでは、「１０１」という症例ＩＤが付与される。

以上説明した流れに沿って、新規の症例ＩＤが付与される。症例ＩＤが付与されると、同じ症例ＩＤが付与された検査データは症例データ管理部３ｊによって１つのグループにまとめられる（図３のＳＴ４）。上述した症例ＩＤの付与に関する処理の流れからすれば、同じ疾病に対して行われた検査データに対して同じ症例ＩＤが付与される、ということになる。従って、同じ症例ＩＤが付与された検査データを１つのグループにまとめて管理する（ＳＴ５）ことで、今後医療従事者がとある疾病に関して行われた検査データを参照する際、同じ疾病に関する別の関連性の強い検査データをもまとめて閲覧することが可能になる。

図７、図８は、実施の形態におけるクライアント端末１の表示部での表示態様の一例を示す画面例である。当該画面例には、特定の患者に対する「病名」及び、この病名に関連する様々な項目に関して検査データの「実施日（期間）」でまとめた内容が表示されている。例えば、図７では、カーソルを表わす矢印が「胃潰瘍」でまとめられた項目の上に示されており、医療従事者によって、太枠で囲まれる胃潰瘍に関する検査データの閲覧が選択されたことが示されている。

なお、図７及び図８のいずれにおいても最も右側の欄に「症例ＩＤ」の欄が設けられている。これは、本発明の実施の形態における理解のために示した欄であり、同じ症例ＩＤごとにまとめてグループで管理していることを明らかにしたものである。従って、医療従事者が見るクライアント端末１における表示部には表示されない項目である。図７及び図８においては、このことを明示するために、表示される内容については太枠の内部に示している。「症例ＩＤ」の項目については、太枠の外側に示されているので、これら「症例ＩＤ」について、医療従事者は画面上見ることができない。

図８は、図７において選択された「胃潰瘍」に関してまとめて管理されている検査データを展開して表示させた状態を示す画面例である。ここでは、検査データに関するダイジェストとなる内容が表示されている。

また、反対に表示はされていないが、「症例ＩＤ」の欄をみると、これらの検査データに付与されている症例ＩＤはいずれも「１０２」であり、医療情報検索システムＳにおいて、これらの検査データを１つのグループとしてまとめて管理していることがわかる。

なお、ここでは図８に示すように、各検査データのダイジェストについては上述した図６のテーブルに記憶されている内容が示されている。但し表示内容については、このようにテーブルに記憶されている内容をそのまま表示させても、或いは、適宜項目を取捨選択して表示させること、さらには、検査データを選択することで、選択された検査データの詳細を表示させることとしても良い。

次に、新規に症例ＩＤが付与された検査データに対して病名をつける（付与する）処理について説明する。上述した図７、或いは、図８に示す画面例においても項目を除く上２つの欄には病名が示されていなかった。ここでは症例ＩＤが付与される処理の後に行われる、このような検査データに対して病名を付与する処理を説明する。

図９は、実施の形態における病名の編集の大まかな流れを示すフローチャートである。症例ＩＤが付与された検査データは、症例データ管理部３ｊにおいて管理されている。従って、クライアント端末１を操作する医療従事者から新規の検査データについての表示要求があった場合には（ＳＴ５１のＹＥＳ）、該当する患者の該当する検査データを表示させることになる（ＳＴ５２）。なお、表示要求がなければ、症例データ管理部３ｊにおける表示処理は待機となる（ＳＴ５１のＮＯ）。

このように表示要求が出された場合において、さらに病名の編集があるか否かが判断される（ＳＴ５３）。

ここで病名の編集の有無については、例えば、表示された検査データの病名欄にカーソルが合わせられて入力の準備がなされたことをもって症例データ管理部３ｊが判断する。或いは、例えば、別途病名の編集を行うためのボタンを画面上表示させておき、当該ボタンがクリックされたことをもって病名編集のトリガーとしても良い。

なお、ここで「病名の編集」とあるのは、まだ病名が付与されていない場合に、新たに医療従事者によって病名が付けられる（入力される）こと、或いは、既に入力されている病名を変更することのいずれも含む。また、実際にいずれの病名を入力するかについての判断は、クライアント端末１を利用して画面を参照している医療従事者が決定する。

病名の編集の処理が要求された場合には（ＳＴ５３のＹＥＳ）、病名の編集が行われる（ＳＴ５４）。図１０は、実施の形態における病名編集の詳細な流れを示すフローチャートであって、病名が直接入力される場合である。図１１は、実施の形態における病名編集部３Ｋの内部構成を示すブロック図である。また、図１２及び図１３は、実施の形態におけるクライアント端末１の表示部での病名編集中の表示態様の一例を示す画面例である。

病名編集部３ｋは、受信部２１と、病名入力確認部２２と、病名未入力グループ把握部２３と、キー検索部２４と、関連症例ＩＤ付与部２５と、送信部２６とから構成される。病名編集部３ｋを構成するこれら各部の詳細な機能、働きについては、以下に説明する病名の提示処理の流れを説明する際に併せて説明する。

医療従事者が病名を直接入力して新たな病名を入力する、或いは、入力されていた病名を変更する場合、まず、病名編集部１３ｋが対象となる検査データに対して病名が直接入力されるか否かが判断される（ＳＴ６１）。具合的には、病名入力確認部２２がクライアント端末１からの入力情報を受信部２１を介して受信したことをもって判断される。病名が直接入力されず病名編集部３ｋによる病名の推定がなされる場合については（ＳＴ６１のＮＯ）、後述する。

病名が直接入力される場合には、入力の対象となる検査データの病名の欄にカーソルが合わせられることで入力の準備が整う。図１２、或いは、図１３に示される画面例では、すでに「胃潰瘍」という病名が入力された状態が示されている。なお、病名の入力は、図１２に示すように検査データの詳細が分からない状態の画面例であっても、或いは、図１３に示すように検査データの詳細が示されている状態の画面例であっても可能である。

次に、入力される病名が新規なものであるか、或いは、既に入力されている病名を変更するのかが確認される（ＳＴ６２）。特に病名が変更される場合には（ＳＴ６２のＮＯ）、病名の変更に伴ってこれまで変更前の病名に付与されていた症例ＩＤも変更しなければならないため対応が必要となる。

病名が変更されて入力されると、病名入力確認部２２において入力された病名が把握される。その上で、当該把握された病名が過去に登録、管理されているか否か確認する（ＳＴ６３）。これは、患者が同じであれば疾病の再発、ということも考えられ、病名が変更された検査データは過去に患った疾病と同じ疾病に関する検査データかもしれないからである。病名入力確認部２２が確認した結果、過去に一致する病名がない場合には（ＳＴ６３のＮＯ）、症例ＩＤ更新部３ｍにおいて病名に合わせて症例ＩＤを変更する。この場合には、改めて新規な症例ＩＤが付与されても良い。

一方、変更された病名に関して、過去に同じ病名が付与された検査データが存在する場合には、当該病名に付与されている症例ＩＤをさらに付与する（ＳＴ３６）。

その上で、病名と症例ＩＤとが関連付けられて症例データ管理部３ｊにおいて管理される（図９のＳＴ５５）。

また、入力された病名が新規である場合には、既に付与されている症例ＩＤと関連付けて当該病名が症例データ管理部３ｊにおいて管理される（ＳＴ５５）。なお、病名と症例ＩＤとの関係は、別途症例データ管理部３ｊによって例えば、テーブル等に保管、管理されることになる。

図１４は、実施の形態における病名と症例ＩＤとの関係を示すテーブルの一例である。症例ＩＤが付与され、病名も付与される（入力される）と、両者は互いに紐づけられて保管、管理される。図１４に示すテーブルでは、患者「東芝太郎」についての「病名」と「症例ＩＤ」との関連を示している。ここでは、「Ｂ型肝炎」は「１０１」という症例ＩＤが付与され、「胃潰瘍」には「１０２」という症例ＩＤが付与されていることが示されている。新規な検査データに対して新たな症例ＩＤが付与され、さらに病名も入力されると、両者はこのテーブルに記憶され管理される。

次に、病名が医療従事者によって直接入力されない場合（ＳＴ６１のＮＯ）については、さらに図１５に示すフローチャートを基に説明する。

図１５は、実施の形態における病名編集の詳細な流れを示すフローチャートである。特にここでは、病名が入力されておらず病名の欄が空欄になっている場合に、当該検査データを含む症例データのグループにおける情報を既に登録されている症例データの情報と比較し、似た情報がある場合に両者を関連付ける処理を行うものである。その結果として，病名が入力される、或いは、後述するように病名を同じくするグループと結合する処理も行うことが可能となる。

なお、ここで「症例データ」とは、検査データと当該検査データが得られるに至った検査を行う必要が生じた疾病の名前（病名）とをまとめた概念である。従って、１つの症例データ（病名）の下に単数、或いは、複数の検査データが含まれる。

まず病名が直接入力されないところから処理が開始される。すなわち、医療従事者が病名が空欄となっている症例データのグループに対して病名を入力するに当たって、検査データを見ることで当該検査データがどの疾病の治療のために行われた検査に関する結果なのかがすぐに理解できる場合には、上述したように直接病名が入力される可能性が高い。

一方で、例えば、図１６に示すクライアント端末１の表示部に表示される画面例のように、各グループが展開されずこのままの表示ではどのような疾病に関する検査データなのかが不明な場合には、過去の登録、管理の例を基にサーバ装置３が関連する症例の推定を行うことで、よりスムーズに病名の入力を行うことができる。

図１６は、実施の形態における病名の入力の際（関連症例ＩＤの付与を行う際）に表示されるクライアント端末の表示部での表示態様の一例を示す画面例である。ここでは、症例ＩＤとして、「１０３」が付与されているグループと、「１０４」が付与されているグループとが色が付された状態で示されている。このことは、これら２つのグループが選択されたことを示している。

まず、症例ＩＤとして「１０３」が付与されているグループに対して関係する症例データの有無、すなわち、病名の入力に資する情報の有無が確認される。病名が未入力の症例データのグループが選択されると、病名編集部３ｋ内の病名未入力グループ把握部２３において、当該グループに含まれる検査データの治療等の内容、及び症例ＩＤが把握される（図１５のＳＴ７１）。図６に示した通り検査データには、「治療／検査／投薬」や「結果／所見」に関する情報が含まれていることから、これらの情報を基に関連する症例データの有無を検索することになる。そこで、病名未入力グループ把握部２３は、キー検索部２４に指示し、既に病名が入力されているグループの症例データに定義付けられているキーの検索を行わせる（ＳＴ７２）。

図１７は、実施の形態における病名とキーとの関係を示すテーブルの一例である。当該テーブルは、例えば、２つの項目から構成されており、「病名」と「キー」である。「キー」は、当該病名に関係する様々な語句が、いわばキーワードとして「病名」に関連付けられるものである。例えば、病名が「Ｂ型肝炎」である場合の「キー」として登録されている内容は、例えば、「血液検査結果：ＨＢｓ抗原が陽性（＋）」や「ウィルスマーカー：Ｂ型肝炎ウィルス（ＨＢＶ）に感染」といったものになる。

当該テーブルは、例えば、データベース４内に記憶されている。また、病名、或いは、キーはそれぞれキー検索部２４を介して追加が可能であり、その追加は、医療従事者による入力、或いは、表示される情報から自動的に行われるといった方法を採用することができる。

病名未入力グループ把握部２３は、キー検索部２４からの情報に基づいて、キーと合致する検査データがあるか否か、判断を行う（ＳＴ７３）。

図１８は、実施の形態における検査データごとに付与される関連症例ＩＤ付与の状態を示すテーブルの一例である。このテーブルには、「治療／検査／投薬」、「病院」、「実施日」、「結果／所見」、及び「症例ＩＤ」といった上述の図６に示されるテーブルに示される項目の他、新たに「関連症例ＩＤ」に関する項目が設けられている。

各検査データには、病名の付与の有無を問わず、症例ＩＤが付与される。一方、複数の疾病に共通した検査が存在し、その結果である当該検査データについては、複数の疾病に関する検査の結果として取り扱われることも考えられる。従ってこの場合には、検査データに症例ＩＤが付与される一方で、併せて他の疾病に関する検査の結果として付与される別の症例ＩＤが「関連症例ＩＤ」として付与されることもある。

例えば、図１８のテーブルに示すように、項目の欄を除く太枠でその一部が囲まれた４行目には、「インターフェロン」の検査データが示されている。この検査データに対しては、症例ＩＤとして「１０３」が付与されている。この症例ＩＤの付与に関する処理の方法については、上述した通りである。この「インターフェロン」という「治療／検査／投薬」については、キー検索部２４が図１７に示す「病名」と「キー」との関係を示すテーブルで確認すると、「Ｂ型肝炎」の「キ−」の１つとして規定されていることが検索される。これで「インターフェロン」という「キー」を基にして「Ｂ型肝炎」という「病名」が把握できる。

さらに病名未入力グループ把握部２３によって、この「Ｂ型肝炎」に対しては、図１４に示すテーブルから「１０１」という症例ＩＤが付与されていることが把握される（ＳＴ７４）。そこで、当該情報に基づいて、関連症例ＩＤ付与部２５は、図１８のテーブルの４行目に示されている検査データに対して、「１０１」という関連症例ＩＤを付与する（ＳＴ７５）。

すなわち、症例ＩＤとして「１０３」が付与されている検査データ「インターフェロン」は、未だ病名が付与されていないものの、既に病名が付与されている検査データのうち「Ｂ型肝炎」という疾病に関係する検査データであることがわかる。関連症例ＩＤが付与されることによって、関連症例ＩＤとして付与されるＩＤを症例ＩＤとして備える疾病と当該検査データが関連づけられることになる。

図１９は、実施の形態における検査データごとに付与される関連症例ＩＤ付与の状態を示すテーブルの一例である。このテーブルは図１８に示すテーブルと同じものであるが、項目を除く３行目、４行目、すなわち、症例ＩＤとして「１０３」が付与されている検査データに対しては、いずれも関連症例ＩＤとして「１０１」が付与された状態が示されている。つまりこれら２つの検査データは、「Ｂ型肝炎」と関連する症例に関する検査データである、ということである。

さらに、図１９のテーブルでは、項目を除く２行目の一部に太線が示されており、当該症例ＩＤとして「１０４」が付与されている検査データに対する関連症例ＩＤの付与の処理が行われていることが示されている。但し、これら症例ＩＤ「１０４」の検査データについては、「インターフェロン」と「血液検査」であるので、「１０３」の症例ＩＤが付与された検査データと同様、関連症例ＩＤとして「１０１」が付与される可能性が高いものと考える。

さらに上述したように、１つの検査データにおいて複数の関連症例ＩＤが付与される可能性がある。そこで病名未入力グループ把握部２３は、他に合致する検査データの有無を判断し、合致するキーがある場合には（ＳＴ７６のＹＥＳ）、該当する病名に付与されている症例ＩＤを関連症例ＩＤとして付与する。

一方、キーと合致する語句を備えた検査データがない場合には（ＳＴ７３のＮＯ）、関連症例ＩＤは付与されない。

この関連症例ＩＤは、検査データごとに付与される。従って、複数の検査データを含む症例データについて病名が未入力の場合、これら複数の検査データごとに関連症例ＩＤの付与の処理が行われる。但し、症例データとして検査データはまとめて１つのグループとして管理されていることから、ある検査データに対して付与された関連症例ＩＤは、同じグループに属する他の検査データにも付与されることになる。

以上説明した通り、この関連症例ＩＤの付与によって、病名が未入力な症例データが既に病名が入力されている症例データと関連づけられることになる。従って、この時点で未入力の病名の入力を医療従事者に促すために、関連症例ＩＤを症例ＩＤとして付与されている症例データに付与されている病名を入力候補の病名として提示することもできる。病名が未入力のままである状態は決して好ましい状態ではないことから、入力候補の病名が提示されることによって医療従事者に対して病名の入力を促すことは必要である。

或いは、次に説明するように、病名が入力された検査データが表示される場合に併せて関連症例ＩＤが付与された検査データも表示させることによって、医療従事者の閲覧の便宜に資するとともに、病名の入力を促すことにつなげることもできる。

図２０は、実施の形態における選択されたグループとともに同じ関連症例ＩＤが付与されているグループも表示させる場合の流れを示すフローチャートである。また、図２１、図２２は、実施の形態におけるクライアント端末１の表示部での表示態様の一例を示す画面例である。

医療従事者がクライアント端末１からサーバ装置３に対してある疾病に関する症例データの表示要求がなされた場合、通常は選択された症例データのみを表示させることで足りる。但し、上述したように、症例データに対して関連症例ＩＤが付与されている場合には、選択された疾病に関する症例データのみならず、当該疾病に対して付与されている症例データと同じ関連症例ＩＤが付与された症例データも併せて表示させれば、医療従事者はある疾病に対して行われた検査等の結果である検査データを漏れなく閲覧することができる。

症例データ管理部３ｊは、クライアント端末１からの表示要求の対象となるグループが選択されたか否か確認をする（ＳＴ８１）。つまりはクライアント端末１からの表示要求を受信したか否かである。クライアント端末１からの表示要求があった場合には（ＳＴ８１のＹＥＳ）、症例データ管理部３ｊは、表示対象となるグループを確認する（ＳＴ８２）。図２１の画面例で言えば、症例データ管理部３ｊは、クライアント端末１の表示部に表示されている患者の病名を含む症例データの中から「Ｂ型肝炎」が選択されたことを確認する。

なお、上述したように、画面上表示されるのは、太枠内の「患者名」、「病名」、及び「期間」のみであって、太枠の外にある「症例ＩＤ」及び「関連症例ＩＤ」の欄については表示されない。

さらに症例データ管理部３ｊは、表示対象となるグループの症例ＩＤと同じ関連症例ＩＤが付与されているグループを特定する（ＳＴ８３）。図２１に示すように、「Ｂ型肝炎」のグループに関する表示が要求されている。この「Ｂ型肝炎」に付与されている症例ＩＤは、「１０１」である。従って、当該「１０１」という関連症例ＩＤが付与されているグループを特定することになる。

ここでは、病名の欄が空欄の２つのグループ、症例ＩＤとして「１０３」或いは、「１０４」が付与されているグループに対してそれぞれ「１０１」という関連症例ＩＤが付与されていることがわかる。

そこで、症例データ管理部３ｊは、表示対象となるグループの検査データ及び、関連症例ＩＤが付与されているグループの検査データを併せて表示させる（ＳＴ８４）。図２２の画面例を見ると、選択された「Ｂ型肝炎」に関する症例データが展開されて、検査データの詳細が表示されている。それとともに、「Ｂ型肝炎」の症例ＩＤである「１０１」と同じＩＤが関連症例ＩＤとして付与されているグループに関する検査データの詳細も展開されて表示されている。

以上のような表示処理を行うことによって、直接の表示対象となるグループ以外に関連症例ＩＤが付与されているグループについても併せて表示されることになるため、たとえ病名が未入力で直接的にはその関連性が不明であっても「関連症例ＩＤ」が付与されていることで該当する症例データのグループ（及びこのグループに含まれる検査データ）が漏れなく表示されることになる。従って、閲覧を希望する医療従事者にとっての利便性向上に資するとともに、病名が未入力となっているグループに対して病名の入力を促すきっかけともなる。

次に、症例データの結合、或いは、分離の処理について説明する。図２３は、症例結合・分離部３ｌの内部構成を示すブロック図である。症例結合・分離部３ｌは、受信部３１と、変更グループ確認部３２と、症例データ結合部３３と、症例データ分離部３４と、送信部３５とから構成されている。なお、症例結合・分離部３ｌを構成する各部の機能、働きについては、以下の症例データの結合、或いは、分離の処理の流れを説明する際、適宜併せて説明する。

図２４は、実施の形態における検査データの結合、或いは、分離の流れを示すフローチャートである。なお、結合、或いは、分離の処理は、基本的に症例データのグループを単位として行われる。これはそもそも関連性の強い検査データをひとまとめにして症例データのグループが作成されていることから、結合、或いは、分離の処理の単位もグループごととしたものである。但し、設定により検査データ単独の結合、或いは、分離の処理が認められないわけではない。

まず症例データのグループについてグループの変更があるか否か、及び選択されたグループがいずれであるかを変更グループ確認部３２が確認する（ＳＴ９１、ＳＴ９２）。実際には、この時点ではまだクライアント端末１の画面上で医療従事者が変更を希望するグループを選択したに過ぎない。その上で、さらに結合処理が行われたか否かが判断される（ＳＴ９３）。これは、次に説明するように、例えば、選択された症例データのグループがドラッグアンドドロップによって結合先となるグループに移動させられたか否かによって判断される。

具体的な結合の処理は、症例データ結合部３３において行われる（ＳＴ９４）。図２５、及び図２６は、実施の形態における症例の結合を行う際のクライアント端末１の表示部での表示態様の一例を示す画面例である。図２５に示されているように、病名の入力がなされていない２つの症例データのグループが選択され、「Ｂ型肝炎」の症例データにドラッグアンドドロップされている。

すなわち、図２２において示したが、とある症例データのグループが展開されて検査データが表示される際には、関連症例ＩＤが付与されている他のグループの検査データについてもまとめて表示される。従って、たとえ病名の入力がされていないグループであっても病名が付与されているグループと併せて展開されて表示されることによって、当該病名が付与されているグループに関連あるグループであることが明らかになる。そこで、病名の入力がなされていないグループを病名が付与されている新たなグループに結合させることによって、新たに病名が付与されたのと同じ状態を作出することができる。

病名の入力がなされていないグループが病名が付与されている新たなグループに結合されると、元々付与されている症例ＩＤも変更しなければならない。そのため、症例データ結合部３３において症例データの結合が行われると、その旨、送信部３５を介して症例ＩＤ更新部３ｍに送信される。

以下、症例ＩＤの更新の処理について、例えば、図２５に示している病名の入力がなされていない、例えば、症例ＩＤとして「１０４」が付与されている「血液検査」及び「インターフェロン」の２つの検査データを含む症例データをＢ型肝炎の欄に結合させる場合を例に挙げて説明する。

上述したように、「血液検査」及び「インターフェロン」の２つの検査データを含む症例データに対しては、症例ＩＤとして「１０４」が付与されている。このような症例ＩＤが付与されている症例データを症例ＩＤとして「１０１」が付与されている症例データのグループに結合させる。その際には、症例ＩＤ更新部３ｍにおいて結合の対象となる症例データに付与されている症例ＩＤを結合先の症例データに付与されている症例ＩＤに合わせて更新（変更）する（ＳＴ９５）。つまり、「血液検査」及び「インターフェロン」の２つの検査データを含む症例データに対して付与されている「１０４」という症例ＩＤを、「Ｂ型肝炎」に付与されている「１０１」という症例ＩＤへと変更する。

次に、元々「血液検査」及び「インターフェロン」の２つの検査データを含む症例データに対して付与されていて変更されてしまった「１０４」という症例ＩＤの取り扱いである。当該症例ＩＤは、いわば、結合の対象となった症例データの履歴を物語るＩＤであると言える。そこで、症例ＩＤ更新部３ｍは、新たに結合の処理が行われることによって変更された元々の症例ＩＤを「症例ＩＤ履歴」として記憶するよう、症例データ管理部３ｊに指示する（ＳＴ９６）。症例データ管理部３ｊでは、当該「症例ＩＤ履歴」とともに、結合処理によって更新（変更）された症例ＩＤも併せて管理する。

より具体的には図２５及び図２６の画面例を例に挙げる。図２５は結合処理の前の状態を示している。ここでは項目の欄を除く１行目、２行目に病名の入力がなされていない「血液検査」及び「インターフェロン」の２つの検査データを含む症例データが示されている。これらの検査データに対しては、それぞれ症例ＩＤとして「１０４」が、また、関連症例ＩＤとして「１０１」が付与されている。

この検査データ（症例データ）が「Ｂ型肝炎」の症例データと結合されると（図２５の矢印でＢ型肝炎の欄に移動させられている）、結合された症例データも併せてＢ型肝炎の欄に表示される。そして、症例ＩＤ更新部３ｍにおいて、元々付与されていた症例ＩＤである「１０４」がＢ型肝炎に付与されている症例ＩＤである「１０１」に変更される。この変更により、結合された「血液検査」及び「インターフェロン」の２つの検査データを含む症例データの症例ＩＤは「１０１」となる。一方、元々付与されていた「１０４」という症例ＩＤは、「症例ＩＤ履歴」として記憶される。

同じように結合された症例ＩＤとして「１０３」が付与されていた「血液検査」及び「インターフェロン」の２つの検査データを含む症例データについても、症例ＩＤは「１０３」から「１０１」へと変更され、「症例ＩＤ履歴」として「１０３」のＩＤが症例データ管理部３ｊによって登録される。

なお、複数回症例ＩＤが更新（変更）された場合には、その都度症例ＩＤ履歴として登録され、その全ての履歴が保管、管理されることになる。

結合とは反対に、元々ひとまとまりのグループに属していた検査データを分離する処理も考えられる。この場合には、分離の対象として選択された症例データを元々のグループから症例データ分離部３４によって分離処理される（ＳＴ９７）。

その上で、当該検査データに付与（表示）されていた病名を削除する（ＳＴ９８）。これは、検査データを元々の症例データから分離するということは、この検査データは、当該症例データに付与されていた病名とは異なる病名の疾病に関する検査データである、と考えられるからである。

さらに、症例データ分離部３４は、当該検査データに対して症例ＩＤ履歴が登録されているか否か確認する（ＳＴ９９）。症例ＩＤ履歴が登録されていた場合には（ＳＴ９９のＹＥＳ）、症例ＩＤ更新部３ｍは、当該症例ＩＤ履歴として登録されていたＩＤを症例ＩＤとして再度登録する（ＳＴ１００）。一方、症例ＩＤ履歴が登録されていない場合には（ＳＴ９９のＮＯ）、症例ＩＤ更新部３ｍは、付与されていた症例ＩＤを破棄して新たな症例ＩＤを付与する（ＳＴ１０１）。

以上説明した通り、患者の検査データに対して症例ＩＤを付与し、場合によって他のグループとの関連性を明らかにする関連症例ＩＤも付与する。その上で同じ症例ＩＤをもつ検査データをグループにまとめ、患者の疾病について関連する一連の医療情報をまとめて管理することにより、利用者による医療情報の検索処理の効率化、迅速な取得、容易な把握を可能とする医療情報検索システム及び医療情報検索装置を提供することができる。

すなわち、医師等の医療従事者からすると、検査が複数回行われていたり、或いは、過去の症例等がある可能性が高い場合に、医療従事者としては、まず、当該患者の症例に関する全体像を把握したい、と考えることが多いものと思われる。このような場合に、上述した医療情報検索システムを利用することで、個々の検査の詳細な内容よりも症例に関係する検査等、症例データを漏れなく閲覧、把握することが可能となる。ことのことは特に元々の症例データが複数の医療機関において保管、管理されている場合と比較してメリットが大きいものと考える。

（第２の実施の形態）
次に本発明における第２の実施の形態について説明する。なお、第２の実施の形態において、上述の第１の実施の形態において説明した構成要素と同一の構成要素には同一の符号を付し、同一の構成要素の説明は重複するので省略する。

第２の実施の形態においては、第１の実施の形態においてサーバ装置３が担っていた役割を医療従事者が使用する端末が担う点に特徴がある。すなわち、第１の実施の形態では、医療情報の検索を行う仕組みとして、いわゆるシンクライアントシステムを利用した医療情報検索システムＳを挙げて説明したが、第２の実施の形態においては、医療情報の検索を行う医療情報検索装置５について説明する。

図２７は、医療情報検索装置５の内部構成を示すブロック図である。医療情報検索装置５は、ＣＰＵ（Central Processing Unit）５ａと、ＲＯＭ(Read Only Memory)５ｂと、ＲＡＭ（Random Access Memory）５ｃ及び入出力インターフェイス５ｄがバス５ｅを介して接続されている。入出力インターフェイス５ｄには、入力部５ｆと、表示部５ｇと、通信制御部５ｈと、記憶部５ｉと、リムーバブルディスク５ｊとが接続されている。さらには、医療情報を検索するための医療情報検索部５０も入出力インターフェイス５ｄに接続されている。

ＣＰＵ５ａは、入力部５ｆからの入力信号に基づいてＲＯＭ５ｂから医療情報検索装置５を起動するためのブートプログラムを読み出して実行し、記憶部５ｉに格納されている各種オペレーティングシステムを読み出す。またＣＰＵ５ａは、入力部５ｆや入出力インターフェイス５ｄを介して、図２７において図示していないその他の外部機器からの入力信号に基づいて各種装置の制御を行う。さらにＣＰＵ５ａは、ＲＡＭ５ｃや記憶部５ｉ等に記憶されたプログラム及びデータを読み出してＲＡＭ５ｃにロードするとともに、ＲＡＭ５ｃから読み出されたプログラムのコマンドに基づいて、検査データ等の医療情報を検索する処理やデータの計算、加工等、一連の処理を実現する処理装置である。

入力部５ｆは、医療情報検索装置５の操作者（例えば、医師や検査技師といった医療従事者）が各種の操作を入力するキーボード、ダイヤル等の入力デバイスにより構成されている。医療従事者の操作に基づいて入力信号を作成しバス５ｅを介してＣＰＵ５ａに送信される。

表示部５ｇは、例えば液晶ディスプレイである。この表示部５ｇは、ＣＰＵ５ａからバス５ｅを介して出力信号を受信し、例えばある患者の検査データを含む症例データを検索するに当たっての条件設定に必要な画像等、或いはＣＰＵ５ａの処理結果等を表示する。

通信制御部５ｈは、ＬＡＮカードやモデム等の手段であり、医療情報検索装置５をインターネットやＬＡＮ等の通信ネットワークに接続することを可能とする手段である。通信制御部５ｈを介して通信ネットワークと送受信したデータは入力信号または出力信号として、入出力インターフェイス５ｄ及びバス５ｅを介してＣＰＵ５ａに送受信される。

記憶部５ｉは、半導体や磁気ディスクで構成されており、ＣＰＵ５ａで実行されるプログラムやデータが記憶されている。

リムーバブルディスク５ｊは、光ディスクやフレキシブルディスクのことであり、ディスクドライブによって読み書きされた信号は、入出力インターフェイス５ｄ及びバス５ｅを介してＣＰＵ５ａに送受信される。

医療情報検索部５０は、自身の記憶部５ｉ或いは、医療情報検索装置５が接続される通信ネットワークに接続されている医療情報が記憶されているサーバ装置等のデータベースに接続して、医療従事者が必要とする医療情報を検索する。本発明の実施の形態においては、医療情報検索装置５の一構成要素（ハードウェア）として医療情報検索部５０を設けた場合を例に挙げて説明を行う。但し、記憶部５ｉ、或いは、リムーバブルディスク５ｊ内に記憶されている、例えば、医療情報検索プログラムを実行させることによって、医療情報検索装置５のＣＰＵ５ａに医療情報検索部５０と同様の機能を備える医療情報検索手段が実装されるようにしても良い。

医療情報検索装置５は、例えば、病院情報管理システム（ＨＩＳ：Hospital Information System）、放射線部門情報管理システム（ＲＩＳ：Radiological Information System）、医用画像管理システム（ＰＡＣＳ：Picture Archiving Communication System）といった医療機関内に構築された各種管理システムの一部を構成する装置として設けられていても良い。

図２８は、医療情報検索部５０の内部構成を示すブロック図である。医療情報検索部５０は、受信部５１と、検査データ登録部５２と、症例ＩＤ付与部５３と、症例データ管理部５４と、病名編集部５５と、症例結合・分離部５６と、症例ＩＤ更新部５７と、送信部５８とから構成されている。これら各部の機能、働きは、第１の実施の形態において説明した通りであることから、ここではその説明を省略する。

医療情報検索装置５は、医療従事者が患者の検査データを検索する際に用いる装置である。また、検査データ自体は、上述したように、症例ＩＤが付与されて同じ症例ＩＤが付与された検査データを症例データとしてまとめて登録、管理している。また、検索結果として表示部５ｇに検査データを表示させる際にも、選択された検査データのみならず、当該検査データを含む症例データに付与されている症例ＩＤと同じＩＤを関連症例ＩＤとして付与されている症例データも併せて表示される。このような表示処理が行われることによって、ある疾病に関する検査データを漏れなく閲覧、把握することが可能となる。

本発明の実施形態を説明したが、この実施形態は、例として提示したものであり、発明の範囲を限定することを意図していない。この実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。この実施形態やその変形は、発明の範囲や要旨に含まれると共に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１クライアント端末
２データベース
３サーバ装置
４データベース
３ａＣＰＵ
３ｂＲＯＭ
３ｃＲＡＭ
３ｄ通信制御部
３ｅ記憶部
３ｆ入出力インターフェイス
３ｇバス
３ｈ検査データ登録部
３ｉ症例ＩＤ付与部
３ｊ症例データ管理部
３ｋ病名編集部
３ｌ症例結合・分離部
３ｍ症例ＩＤ更新部

Claims

患者の検査データを閲覧するクライアント端末と、
医療機関から送信される前記検査データを登録、管理するとともに、前記クライアント端末からの要求に基づいて前記検査データを特定のグループごとに表示させるサーバ装置と、を備える医療情報検索システムであって、
前記サーバ装置は、
登録された前記検査データに対して症例ＩＤを付与する症例ＩＤ付与部と、
前記症例ＩＤが付与された前記検査データを、同じ前記症例ＩＤが付与された前記検査データごとにグループとしてまとめて管理する症例データ管理部と、
を備えることを特徴とする医療情報検索システム。
前記症例ＩＤ付与部は、
前記症例ＩＤの付与の対象となる前記検査データが既に登録された検査データであるか否かを判断する判断部と、
前記症例ＩＤの付与の対象となる前記検査データの実施日と、既に登録された前記検査データの実施日とを比較する比較部と、
前記比較部による比較結果に基づいて、新規な症例ＩＤ、或いは、既に登録された前記検査データに対して付与されている症例ＩＤを付与するＩＤ付与部と、
を備えることを特徴とする請求項１に記載の医療情報検索システム。
前記サーバ装置は、
グループで管理される前記検査データに対して病名が未入力な前記グループを把握するとともに、病名が未入力な前記グループに関する各種情報を把握する病名未入力グループ把握部と、
前記各種情報を基に既に前記病名が付与されているグループに定義付けられているキーを検索し、前記キーをその情報として含む前記各種情報を備える前記検査データを特定するキー検索部と、
前記病名未入力グループ把握部において把握された前記各種情報を備える前記検査データに対して付与されている症例ＩＤと紐付けられる、病名が未入力な前記グループに対して関連症例ＩＤを付与する関連症例ＩＤ付与部と、
からなる病名編集部を備えることを特徴とする請求項１または請求項２に記載の医療情報検索システム。
前記症例データ管理部は、第１のグループに含まれる前記検査データが表示対象として選択された場合に、前記第１のグループの前記検査データの症例ＩＤと同じ関連症例ＩＤが付与されている検査データを含む第２のグループを特定するとともに、前記第１のグループの検査データを表示する際、併せて前記第２のグループの検査データも表示することを特徴とする請求項１ないし請求項３のいずれかに記載の医療情報検索システム。
前記サーバ装置は、
症例ＩＤごとにまとめられている前記検査データのグループを変更する際に当たって、変更対象となる前記グループに病名が付与されているか否かを確認する変更グループ確認部と、
前記病名が付与されている場合に、前記グループを既に登録されているグループから分離する症例データ分離部と、
分離された前記グループに付与されている関連症例ＩＤを元々付与されている症例ＩＤへと変更する分離症例ＩＤ変更部と、
前記病名が付与されていない場合に、前記グループを既に登録されているグループへと結合する症例データ結合部と、
結合された前記グループに付与されている関連症例ＩＤを症例ＩＤへと変更するとともに、前記グループに付与されていた元々の前記症例ＩＤを症例ＩＤ履歴として変更する結合症例ＩＤ変更部と、
変更された新たな症例ＩＤを登録する症例ＩＤ登録部と、
からなる症例結合・分離部を備えることを特徴とする請求項１ないし請求項４のいずれかに記載の医療情報検索システム。
患者の検査データを登録する検査データ登録部と、
登録された前記検査データに対して症例ＩＤを付与する症例ＩＤ付与部と、
前記症例ＩＤが付与された前記検査データを、同じ前記症例ＩＤが付与された前記検査データごとにグループとしてまとめて管理する症例データ管理部と、
を備えることを特徴とする医療情報検索装置。
前記グループに対し病名を付与、或いは、既に付与されている病名を変更する病名編集部を備えることを特徴とする請求項６に記載の医療情報検索装置。
前記グループを既に登録されているグループに結合し、或いは、分離する症例結合・分離部を備えることを特徴とする請求項６または請求項７に記載の医療情報検索装置。