JP6573686B2 - 複数のユーザにアクセスされるデータを処理する情報管理システム、情報管理方法、およびプログラム - Google Patents

Description

本発明は、複数のユーザにアクセスされるデータ、例えば、電子カルテのようなデータを処理する情報管理システム、情報管理方法、およびプログラムに関するものである。

一般的に、データアクセスされるシステムは、一時的に必要性の高いデータが、複数のユーザに同時アクセスされる場合がある。例えば、電子カルテのデータがそのような同時アクセスされうるデータとなる。このような電子カルテの従来技術について説明する。医療機関においては、コンピュータを用いて患者情報、診察情報、処方情報等を電子的に管理する電子カルテと呼ばれるシステムが用いられている（特許文献１、特許文献２参照）。

特開２００２−３０４４６６号公報 特開２０１７−１１１６６５号公報

上記の特許文献１には、ディスプレイ装置上において当該患者の過去の診察履歴の一瞥表示や詳細表示を行う技術が記載されている。また、特許文献２には、患者のプライバシーの侵害となる電子カルテの閲覧を抑止するために、利用者のアカウント情報を、閲覧対象患者に関連付けて記憶する技術が記載されている。

上述のように、一般に、電子カルテシステムでは、患者が医療機関を受診する際、受付、診察、検査、会計等のそれぞれの段階において、受付担当者、医師、看護師、診察助手、検査技師、会計担当者等の複数のユーザによって、患者に対するデータ入力が短期間に行われる。その際、他のユーザのデータ入力待ちによる遅延を防ぎ、業務効率を高めるためには、同一患者に対するデータ入力が、複数人で並行して行えることが望ましい。

しかしながら、従来の電子カルテシステムでは、患者のデータを複数のユーザによって並行して編集することが考慮されておらず、そのため、たとえば検査技師が開いているドキュメントＡを更新した場合に、すでに医師が開いているドキュメントＢに反映されないというデータの不整合を生じさせる恐れがある。あるいは、看護師がドキュメントＣを開いている間は、他のユーザはドキュメントＣに関連するデータの更新を行えず、最新の状況を共有できなかったり、待ち時間が生じたりという、作業効率の悪化を招く恐れがある。

そこで、電子カルテシステムで、患者のデータに対する同時アクセスを可能とし、なおかつユーザ間のデータの不整合を防ぐためには、あるデータの更新が行われた際に、複数のユーザがそれぞれの端末で開いているドキュメントを全て更新しなければならない。その際、従来の方法では、データの処理量が大きい場合に更新の遅延が発生したり、並行して複数のユーザが更新を行った場合に競合が起こったりする恐れがあり、データの同時アクセスを実現することは難しい。

この課題に対して、本発明者らは、患者のデータを管理する方法に着目した。各ユーザが開くドキュメント毎に患者のデータを管理するのではなく、ドキュメントに含まれる項目毎に管理し、各ドキュメントは、それぞれデータを参照する。そのデータは、変更や複数のドキュメントに対する更新が容易となるよう、最小サイズのオブジェクトとして格納する。また、最小単位のオブジェクトのままでは、過去の履歴を参照する際に処理効率が悪いので、一定時間の経過後には、オブジェクトを結合する。

本発明は、複数のユーザにアクセスされるデータを処理するシステムにおいて、データに対する同時アクセスを可能とし、なおかつユーザ間のデータの不整合を防ぐ情報管理システム、情報管理方法、およびプログラムを提供することを目的とする。

本発明では、以下のような解決手段を提供する。

第１の特徴に係る発明は、
複数のユーザに同時にアクセスされるデータを処理し、一度に参照可能なデータのまとまりをオブジェクトとして扱う情報管理システムにおいて、
前記オブジェクトのデータを参照して前記複数のユーザ各々に編集可能なドキュメントを表示するドキュメント編集手段と、
前記ドキュメントの項目に対して、データの入力を受け付けるデータ入力受付手段と、
前記入力されたデータをオブジェクト毎に格納するデータ格納手段と、
一定時間経過後に、前記オブジェクトを結合することでサイズを拡大するサイズ変更手段と、
を備えることを特徴とする情報管理システムを提供する。

第１の特徴に係る発明によれば、複数のユーザに同時にアクセスされるデータを処理し、一度に参照可能なデータのまとまりをオブジェクトとして扱う情報管理システムにおいて、前記オブジェクトのデータを参照して前記複数のユーザ各々に編集可能なドキュメントを表示するドキュメント編集手段と、前記ドキュメントの項目に対して、データの入力を受け付けるデータ入力受付手段と、前記入力されたデータをオブジェクト毎に格納するデータ格納手段と、一定時間経過後に、前記オブジェクトを結合することでサイズを拡大するサイズ変更手段と、を備える。

第１の特徴に係る発明は、情報管理システムのカテゴリであるが、情報管理方法、およびプログラムであっても同様の作用、効果を奏する。

第２の特徴に係る発明は、第１の特徴に係る発明である情報管理システムであって、
前記データ格納手段は、前記入力されたデータを前記ドキュメントの項目毎に独立したオブジェクトとして格納し、
前記サイズ変更手段は、一定時間経過後に、前記入力済みの複数のオブジェクトを一つのオブジェクトとして統合し、オブジェクトのサイズを拡大することを特徴とする情報管理システムを提供する。

第２の特徴に係る発明によれば、第１の特徴に係る発明である情報管理システムにおいて、前記データ格納手段は、前記入力されたデータを前記ドキュメントの項目毎に独立したオブジェクトとして格納し、前記サイズ変更手段は、一定時間経過後に、前記入力済みの複数のオブジェクトを一つのオブジェクトとして統合し、オブジェクトのサイズを拡大する。

第３の特徴に係る発明は、第１の特徴又は第２の特徴に係る発明である情報管理システムであって、
前記受け付けた項目毎のデータにアクセスしているユーザ全てに更新されたかどうかを確認するデータ更新確認手段と、
前記データ更新確認手段により項目毎のデータが更新されたことが検出された場合に、前記ドキュメントが参照するオブジェクトのうち更新が必要な最小サイズのオブジェクトのみ、データを更新するドキュメント更新手段をさらに備えたことを特徴とする情報管理システムを提供する。

第３の特徴に係る発明によれば、第１の特徴又は第２の特徴に係る発明である情報管理システムにおいて、前記受け付けた項目毎のデータにアクセスしているユーザ全てに更新されたかどうかを確認するデータ更新確認手段と、前記データ更新確認手段により項目毎のデータが更新されたことが検出された場合に、前記ドキュメントが参照するオブジェクトのうち更新が必要な最小サイズのオブジェクトのみ、データを更新するドキュメント更新手段をさらに備える。

第４の特徴に係る発明は、第１の特徴から第３の特徴のいずれかに係る発明である情報管理システムであって、
前記一定時間経過後とは、前記ドキュメント作成日の翌日の所定の時刻又は前記ドキュメントの確定処理を行った翌日の所定の時刻であることを特徴とする情報管理システムを提供する。

第４の特徴に係る発明によれば、第１の特徴から第３の特徴のいずれかに係る発明である情報管理システムにおいて、前記一定時間経過後とは、前記ドキュメント作成日の翌日の所定の時刻又は前記ドキュメントの確定処理を行った翌日の所定の時刻である。

第５の特徴に係る発明は、第１の特徴から第４の特徴のいずれかに係る発明である情報管理システムであって、
前記データが、電子カルテに入力されるデータであることを特徴とする情報管理システムを提供する。

第５の特徴に係る発明によれば、第１の特徴から第４の特徴のいずれかに係る発明である情報管理システムにおいて、前記データが、電子カルテに入力されるデータである。

第６の特徴に係る発明は、
複数のユーザに同時にアクセスされるデータを処理し、一度に参照可能なデータのまとまりをオブジェクトとして扱う情報管理方法において、
前記オブジェクトのデータを参照して前記複数のユーザ各々に編集可能なドキュメントを表示するステップと、
前記ドキュメントの項目に対して、データの入力を受け付けるステップと、
前記入力されたデータをオブジェクト毎に格納するステップと、
一定時間経過後に、前記オブジェクトを結合することでサイズを拡大するステップと、
を備える情報管理方法を提供する。

第７の特徴に係る発明は、
複数のユーザに同時にアクセスされるデータを処理し、一度に参照可能なデータのまとまりをオブジェクトとして扱う情報管理システムに、
前記オブジェクトのデータを参照して前記複数のユーザ各々に編集可能なドキュメントを表示するステップ、
前記ドキュメントの項目に対して、データの入力を受け付けるステップ、
前記入力されたデータをオブジェクト毎に格納するステップ、
一定時間経過後に、前記オブジェクトを結合することでサイズを拡大するステップ、
を実行させるためのプログラムを提供する。

本発明によれば、複数のユーザにアクセスされるデータを処理するシステムにおいて、患者のデータに対する同時アクセスを可能とし、なおかつユーザ間のデータの不整合を防ぐ情報管理システム、情報管理方法、およびプログラムを提供することが可能となる。

図１は、本発明の好適な実施形態の概要図である。 図２は、端末１００とサーバ２００の機能ブロックと各機能の関係を示す図である。 図３は、端末１００とサーバ２００のフローチャート図である。 図４は、データの更新によるドキュメント更新処理を行う場合の、端末１００とサーバ２００の機能ブロックと各機能の関係を示す図である。 図５は、データの更新によるドキュメント更新処理を行う場合の、端末１００Ａと端末１００Ｂとサーバ２００のフローチャート図である。 図６は、本発明における端末１００とサーバ２００間のデータの流れの模式図である。 図７は、端末１００に患者Ｘのバイタル情報を表示する場合の画面例である。 図８は、端末１００に患者のバイタル情報一覧を表示する場合の画面例である。 図９は、本発明でリアルタイム編集を行うために、データを最小サイズのオブジェクトとして扱う際の模式図である。 図１０は、本発明で一定時間が経過しリアルタイム編集が必要でなくなった場合に、データを結合してオブジェクトのサイズを拡大した際の模式図である。 図１１は、従来の手法でデータの更新を行った場合の模式図である。 図１２は、本発明による電子カルテシステムの画面表示の一例である。 図１３は、本発明による電子カルテシステムにおいて、各オブジェクトがもつ特性情報を示す模式図である。 図１４は、本発明による電子カルテシステムにおいて、各オブジェクトがもつ特性情報に基づいて作成されたドキュメントの画面表示の一例である。

以下、本発明を実施するための最良の形態について図を参照しながら説明する。なお、これはあくまでも一例であって、本発明の技術的範囲はこれに限られるものではない。

［情報管理システムの概要］
図１は、本発明の好適な実施形態の概要図である。この図１に基づいて、本発明の概要を説明する。情報管理システムは、端末１００、サーバ２００、通信網３００から構成される。また、ここでは電子カルテのデータを取り扱う情報管理システムを例として説明するが、取り扱うデータは、電子カルテに限定されることはない。

なお、図１において、端末１００の数およびサーバ２００の数は一つに限らず複数であってもよい。また、サーバ２００は、実在する装置に限らず、仮想的な装置であってもよい。ここでは、デスクトップコンピュータの端末１００Ａと、タブレットの端末１００Ｂを図示している。端末１００Ａは、ユーザ４００Ａが操作し、端末１００Ｂは、ユーザ４００Ｂが操作するものとする。

端末１００Ａおよび端末１００Ｂは、図２に示すように、制御部１１０、通信部１２０、記憶部１３０、入出力部１４０から構成される。入出力部１４０は、制御部１１０、通信部１２０、記憶部１３０と協働してドキュメント編集モジュール１４１を実現する。また、入出力部１４０は、制御部１１０、記憶部１３０と協働してデータ入力受付モジュール１４２を実現する。サーバ２００は、同じく図２に示すように、制御部２１０、通信部２２０、記憶部２３０、入出力部２４０、から構成される。制御部２１０は、通信部２２０、記憶部２３０と協働してデータ格納モジュール２１１を実現する。また、制御部２１０は、記憶部２３０と協働してサイズ変更モジュール２１２を実現する。通信網３００は、インターネット等の公衆通信網でも専用通信網でもよく、端末１００とサーバ２００間の通信を可能とする。

端末１００は、情報管理システムを使用するユーザ４００が所持する端末装置である。端末１００は、例えば、携帯電話、携帯情報端末、タブレット端末、パーソナルコンピュータに加え、ネットブック端末、スレート端末、電子書籍端末、携帯型音楽プレーヤ等の電化製品や、スマートグラス、ヘッドマウントディスプレイ等のウェアラブル端末や、その他の物品である。端末１００Ａとして図示しているデスクトップコンピュータと端末１００Ｂとして図示しているタブレット端末は、その一例にすぎない。ここでのユーザ４００としては、医師、看護師、介護士、作業療法士、理学療法士、診療助手、受付担当者、支払い担当者、等、医療機関に関連して電子カルテの情報処理システムで管理するドキュメントを使用する人物を想定している。

図１の情報管理システムにおいて、はじめに、端末１００Ａのドキュメント編集モジュール１４１は、ユーザ４００Ａに、情報を表示したい患者とドキュメントの種類を選択させ、選択内容をサーバ２００に通知する（ステップＳ０１）。患者の選択では、受付を行った患者を氏名やＩＤにより一覧表示から選択させてもよいし、新規の患者の場合は、氏名やＩＤ、生年月日、性別、保険証の番号等、必要な情報を入力して新規登録してもよい。また、表示するドキュメントの選択では、患者個人のバイタル情報や患者のバイタル情報一覧等、ユーザが入力や参照を行いたいドキュメントの種類を選択可能な構成とする。バイタル情報の他にも、診療記録、手術、麻酔、処方、注射、看護記録、助産記録、処置、手術、画像、検査結果、リハビリ、健診、問診、説明同意書、看護要約、リハビリ計画書、各種証明書、等、電子カルテシステムで必要と思われるドキュメントを選択できてよい。また、ドキュメント内の項目としても、病名、主要症状、治療方法、診療の年月日、患者の基本情報（氏名・年齢・性別・住所・保険証番号等）、主訴、現病歴、既往歴、家族歴、社会歴、嗜好、アレルギー、現症・身体所見、血液検査・画像検査等各種の検査結果、予約の状況、入院後経過、看護記録、治療方針、治療の目的、等の幅広い内容を取り扱うものとする。ここでは、患者Ｘのバイタル情報（体温、血圧（上）、血圧（下）、脈拍）ドキュメントを選択したものとする。

図７は、端末１００に患者Ｘのバイタル情報を表示する場合の画面例である。図７では、タブレットの入出力部１４０にバイタル情報を表示する例を示しているが、これはあくまで一例であり、端末の種類は問わないものとする。患者Ｘのバイタル情報を表示する場合の例として、ウインドウ７０１に項目名として、患者名７１０、体温７２０、血圧（上）７３０、血圧（下）７４０、脈拍７５０を表示する。また、患者名表示７１１として、選択した患者の氏名を表示する。又は、ＩＤ等患者を特定できる表示で代用してもよいし、両方を併記してもよい。また、コンボボックス７２１には体温の値を、コンボボックス７３１には血圧（上）の値を、コンボボックス７４１には血圧（下）の値を、コンボボックス７５１には脈拍の値を、入力又は表示するものとする。ここで、コンボボックス７２１、７３１、７４１、７５１は、必ずしもコンボボックスである必要はなく、それぞれのデータの値の入力、変更、表示が可能であればよいものとする。また、サーバ２００から、必要なデータの取得ができなかった場合には、未入力の項目であると考えられるため、空欄のまま表示してもよいし、未入力であることが分かるように＜未入力＞等の表示を行ってもよい。また、更新情報表示７６０のように、誰がいつバイタル情報を更新したか、日時とユーザ名を表示してもよい。

図１に戻り、端末１００Ａからの患者とドキュメント選択の通知を受けて、サーバ２００のデータ格納モジュール２１１は、患者Ｘのバイタル情報ドキュメント表示に必要なデータの検索を行う（ステップＳ０２）。ここでは、すでに記憶部２３０に、患者Ｘの体温、血圧（上）、血圧（下）が記憶されているものとする。

データ格納モジュール２１１は、ステップＳ０２で検索した患者Ｘのバイタル情報（体温、血圧（上）、血圧（下））を、データとして端末１００Ａに送信する（ステップＳ０３）。ここで、患者Ｘのバイタル情報のうち、脈拍はデータとして記憶されていないことを、あわせて送信してもよい。

次に、端末１００Ａのドキュメント編集モジュール１４１は、患者Ｘのバイタル情報（体温、血圧（上）、血圧（下））をデータとして受信する（ステップＳ０４）。患者Ｘのバイタル情報のうち、脈拍はデータとして記憶されていないことがサーバ２００から送信された場合は、これもあわせて受信するものとする。

ステップＳ０３のデータ格納モジュール２１１によるデータの送信と、ステップＳ０４のドキュメント編集モジュール１４１によるデータの受信は、ドキュメントの表示に必要な項目分、データをまとめて送受信してもよいし、項目毎にデータを分けて、ステップＳ０３とステップＳ０４を繰り返してもよいものとする。

ドキュメント編集モジュール１４１は、ステップＳ０４で受信したデータをもとに、患者Ｘのバイタルデータをドキュメントとして表示する（ステップＳ０５）。この段階では、脈拍のデータがないので、図７のコンボボックス７５１は空欄で表示するか、＜未入力＞等の表示を行う。

次に、データ入力受付モジュール１４２は、ユーザ４００Ａからのデータ入力を受け付ける（ステップＳ０６）。ここでは、ユーザ４００Ａは、端末１００Ａの入出力部１４０を介して、患者Ｘの脈拍が７１回／分であることを入力したものとする。

そして、データ入力受付モジュール１４２は、患者Ｘの脈拍が７１回／分であるという入力データを、サーバ２００に送信する（ステップＳ０７）。入力データとあわせて、入力日時とユーザ４００Ａの情報を送信してもよい。

サーバ２００のデータ格納モジュール２１１は、端末１００Ａから入力データを受信する（ステップＳ０８）。ここでは、患者Ｘの脈拍が７１回／分であることを受信する。端末１００Ａから、入力日時とユーザの情報が送信された場合には、あわせて受信する。

データ格納モジュール２１１は、受信した入力データを記憶部２３０のオブジェクトに格納する（ステップＳ０９）。ここで、患者Ｘの脈拍が７１回／分であるということをあらわすデータを記憶部２３０の最小サイズのオブジェクトに格納する。入力日時とユーザの情報をあわせて受信した場合には、その情報もあわせて格納してもよいし、別オブジェクトとして格納してもよい。ここで、記憶部２３０には、患者Ｘのバイタルデータとして、体温、血圧（上）、血圧（下）、脈拍が記憶されたため、例えば、この後にユーザ４００Ｂが端末１００Ｂで患者Ｘのバイタル情報を表示させた場合には、図７のコンボボックス７５１には、脈拍が７１回／分であることを表示することができる。

ここでの、オブジェクトとは、一度に参照可能なデータのまとまりのことである。オブジェクトのサイズが小さいと、変更時のデータ通信に要する時間がほとんどかからないという利点がある。そのため、変更時のデータ通信に要する時間が数ミリ秒の遅延の範囲内ですみ、複数人でのリアルタイム性のある並行した編集が可能となる。逆に、オブジェクトのサイズが大きいと、データ通信に要する時間は長くなるが、一度のデータアクセスでまとめてデータを取得できるという利点がある。

図９は、本発明でリアルタイム編集を行うために、データを最小サイズのオブジェクトとして扱う際の模式図である。端末１００の記憶部２３０を模式的に示しており、左側がリアルタイム編集可能な、最小単位のオブジェクトに分割されたデータである。右側は、リアルタイム編集対象外の、まとめられたオブジェクトである。ここで、左側に示す通り、患者Ｘの体温データ、患者Ｘの血圧（上）データ、患者Ｘの血圧（下）データ、患者Ｘの脈拍データ、はそれぞれが１つのオブジェクトである。また、患者Ｘの受付情報データも、独立したオブジェクトとする。同じように、患者Ｙの体温データ、患者Ｙの血圧（上）データ、患者Ｙの血圧（下）データ、患者Ｙの脈拍データ、患者Ｙの受付情報データも、それぞれが独立したオブジェクトである。

図１に戻り、一定時間の経過後、サーバ２００のサイズ変更モジュール２１２は、オブジェクトのサイズ変更を行う（ステップＳ１０）。ここでのサイズ変更とは、入力済みの複数のオブジェクトを一つのオブジェクトとして統合し、オブジェクトのサイズを拡大することである。また、ここで、一定時間経過後とは、ドキュメント作成日の翌日の所定の時刻、又は、ドキュメントの確定処理を行った翌日の所定の時刻であることが望ましい。なぜかというと、電子カルテのシステムを考えた場合、診察情報は、基本的に診察の翌日以降の編集を行わないため、データを最小サイズのオブジェクトのままにしておき、リアルタイムに編集できる構成を維持する必要が無いためである。運用の例としては、患者のカルテは作成日の翌日の所定の時刻を一定時間経過後とし、その他の文書データのドキュメントは、確定処理を行った翌日の所定の時刻を一定時間経過後とすることが考えられる。ここでの確定処理とは、ドキュメントの保存処理または、ドキュメントのクローズ処理等、システムに応じて設定可能とする。

図１０は、本発明で一定時間が経過しリアルタイム編集が必要でなくなった場合に、データを結合してオブジェクトのサイズを拡大した際の模式図である。端末１００の記憶部２３０を模式的に示しており、右側は、リアルタイム編集対象外の、まとめられたオブジェクトである。ここで、患者Ｘのバイタル情報として、患者Ｘの体温データ、血圧（上）データ、血圧（下）データ、脈拍データと、患者Ｘの受付情報データをまとめて、１つのオブジェクトとする。また、同じように、患者Ｙのバイタル情報として、患者Ｙの体温データ、血圧（上）データ、血圧（下）データ、脈拍データと、患者Ｙの受付情報データをまとめて、１つのオブジェクトとする。さらに、患者バイタル情報一覧として、患者Ｘの受付情報データ、体温データ、血圧（上）データ、血圧（下）データ、脈拍データと患者Ｙの受付情報データ、体温データ、血圧（上）データ、血圧（下）データ、脈拍データをまとめて、１つのオブジェクトとする。このほかに、患者Ｘの体温データとして過去のデータに今回のデータを加えたものを１つのオブジェクト、患者Ｘの血圧（上）データとして過去のデータに今回のデータを加えたものを１つのオブジェクト、患者Ｘの血圧（下）データとして過去のデータに今回のデータを加えたものを１つのオブジェクト、患者Ｘの脈拍データとして過去のデータに今回のデータを加えたものを１つのオブジェクト、として更新する。今回が初診で過去のデータがない患者Ｙについては、患者Ｘの体温データとして今回のデータを初回としたものを１つのオブジェクト、患者Ｘの血圧（上）データとして今回のデータを初回としたものを１つのオブジェクト、患者Ｘの血圧（下）データとして今回のデータを初回としたものを１つのオブジェクト、患者Ｘの脈拍データとして今回のデータを初回としたものを１つのオブジェクト、として新規に作成する。このように、リアルタイム編集が必要なくなったデータをまとめることで、例えば、患者Ｘの体温データをまとめたオブジェクトにアクセスすると、記憶部２３０に対して一回のアクセスで過去の体温データ全てを取得することが可能となり、システムのパフォーマンスに与える影響が小さくてすむ。リアルタイム編集可能な、最小サイズのオブジェクトのままだと、過去の体温データの数と同じ回数だけ、それぞれのオブジェクトにアクセスしなければならない。

このように、複数人でのリアルタイム性のある並行した編集が必要な段階では、オブジェクトのサイズを小さくして変更時のデータ通信に要する時間をごく短く抑え、各ユーザが行った更新を即時反映することで、ユーザ間のデータの不整合を防ぐことが可能である。また、一定時間の経過後は、オブジェクトのサイズを拡大して、一度のデータアクセスでまとめてデータを取得することでシステムのパフォーマンスに与える影響を小さく抑えることが可能となる。

以上のように、本発明によれば、複数のユーザにアクセスされるデータを処理する電子カルテシステムにおいて、患者のデータに対する同時アクセスを可能とし、なおかつユーザ間のデータの不整合を防ぐことができ、パフォーマンス性の高い情報管理システム、情報管理方法、およびプログラムを提供することが可能となる。

［各機能の説明］
図２は、端末１００とサーバ２００の機能ブロックと各機能の関係を示す図である。端末１００は、制御部１１０、通信部１２０、記憶部１３０、入出力部１４０から構成される。入出力部１４０は、制御部１１０、通信部１２０、記憶部１３０と協働してドキュメント編集モジュール１４１を実現する。また、入出力部１４０は、制御部１１０、記憶部１３０と協働してデータ入力受付モジュール１４２を実現する。サーバ２００は、制御部２１０、通信部２２０、記憶部２３０、入出力部２４０、から構成される。制御部２１０は、通信部２２０、記憶部２３０と協働してデータ格納モジュール２１１を実現する。また、制御部２１０は、記憶部２３０と協働してサイズ変更モジュール２１２を実現する。通信網３００は、インターネット等の公衆通信網でも専用通信網でもよく、端末１００とサーバ２００間の通信を可能とする。なお、図２において、端末１００の数およびサーバ２００の数は一つに限らず複数であってもよい。ここでは、デスクトップコンピュータの端末１００Ａと、タブレットの端末１００Ｂを図示しているが、端末１００Ａも端末１００Ｂも、端末１００の機能ブロックを備えるものとする。

端末１００は、情報管理システムを使用するユーザ４００が所持する端末装置である。端末１００は、例えば、携帯電話、携帯情報端末、タブレット端末、パーソナルコンピュータに加え、ネットブック端末、スレート端末、電子書籍端末、携帯型音楽プレーヤ等の電化製品や、スマートグラス、ヘッドマウントディスプレイ等のウェアラブル端末や、その他の物品である。端末１００Ａとして図示しているデスクトップコンピュータと端末１００Ｂとして図示しているタブレット端末は、その一例にすぎない。ここでのユーザ４００としては、医師、看護師、介護士、作業療法士、理学療法士、診療助手、受付担当者、支払い担当者、等、医療機関に関連して電子カルテの情報処理システムで管理するドキュメントを使用する人物を想定している。

端末１００は、制御部１１０として、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等を備える。

通信部１２０として、他の機器と通信可能にするためのデバイス、例えば、有線によるＬＡＮ接続や、ＩＥＥＥ８０２．１１に準拠したＷｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）対応デバイス又はＩＭＴ−２０００規格に準拠した無線デバイス等を備える。

記憶部１３０として、ハードディスクや半導体メモリによる、データのストレージ部を備える。

入出力部１４０は、ユーザ４００が電子カルテの情報管理システムを利用するために必要な機能を備えるものとする。入出力部１４０は、制御部１１０、通信部１２０、記憶部１３０と協働してドキュメント編集モジュール１４１を実現する。また、入出力部１４０は、制御部１１０、記憶部１３０と協働してデータ入力受付モジュール１４２を実現する。入力を実現するための例として、タッチパネル機能を実現する液晶ディスプレイ、キーボード、マウス、ペンタブレット、装置上のハードウェアボタン、音声認識を行うためのマイク等を備えることが可能である。出力を実現するための例として、液晶ディスプレイ、ＰＣのディスプレイ、プロジェクターへの投影等の表示と音声出力等の形態が考えられる。入出力方法により、本発明は特に機能を限定されるものではない。

サーバ２００は、後述の機能を備える、一般的な計算機であってよい。また、実在する装置に限らず、仮想的な装置であってもよい。

サーバ２００は、制御部２１０として、ＣＰＵ、ＲＡＭ、ＲＯＭ等を備える。制御部２１０は、通信部２２０、記憶部２３０と協働してデータ格納モジュール２１１を実現する。また、制御部２１０は、記憶部２３０と協働してサイズ変更モジュール２１２を実現する。

通信部２２０として、他の機器と通信可能にするためのデバイス、例えば、有線によるＬＡＮ接続や、ＩＥＥＥ８０２．１１に準拠したＷｉ−Ｆｉ対応デバイス又はＩＭＴ−２０００規格に準拠した無線デバイス等を備える。

記憶部２３０として、ハードディスクや半導体メモリによる、データのストレージ部を備える。

入出力部２４０には、入力を実現するための例として、タッチパネル機能を実現する液晶ディスプレイ、キーボード、マウス、ペンタブレット、装置上のハードウェアボタン、音声認識を行うためのマイク等を備えることが可能である。出力を実現するための例として、液晶ディスプレイ、ＰＣのディスプレイ、プロジェクターへの投影等の表示と音声出力等の形態が考えられる。

［電子カルテの情報管理処理］
図３は、端末１００とサーバ２００のフローチャート図である。ここでの端末１００は、図２の端末１００Ａ又は端末１００Ｂのいずれかとする。端末１００は、ユーザ４００が使用しているものとし、上述した各モジュールが実行する処理について、本処理にあわせて説明する。

はじめに、端末１００を使用するユーザ４００は、電子カルテの情報管理システムへのログイン処理を行う（ステップＳ３０１）。ここで、ログイン処理を行うことで、端末１００を使用するユーザ４００を特定することができる。ログインするために必要なアカウント情報と認証情報を、ログイン要求とあわせてサーバ２００に送信するものとする。アカウント情報とは、氏名やニックネームやＩＤ等であり、認証情報とは、パスワードやパスフレーズ、指紋や虹彩、等であるものとする。

次に、端末１００のドキュメント編集モジュール１４１は、ユーザ４００に、情報を表示したい患者とドキュメントの種類を選択させ、選択内容をサーバ２００に通知する（ステップＳ３０２）。患者の選択では、受付を行った患者を氏名やＩＤにより一覧表示から選択させてもよいし、新規の患者の場合は、氏名やＩＤ、生年月日、性別、保険証の番号等、必要な情報を入力して新規登録してもよい。また、表示するドキュメントの選択では、患者個人のバイタル情報や患者のバイタル情報一覧等、ユーザが入力や参照を行いたいドキュメントの種類を選択可能な構成とする。バイタル情報の他にも、診療記録、手術、麻酔、処方、注射、看護記録、助産記録、処置、手術、画像、検査結果、リハビリ、健診、問診、説明同意書、看護要約、リハビリ計画書、各種証明書、等、電子カルテシステムで必要と思われるドキュメントを選択できてよい。また、ドキュメント内の項目としても、病名、主要症状、治療方法、診療の年月日、患者の基本情報（氏名・年齢・性別・住所・保険証番号等）、主訴、現病歴、既往歴、家族歴、社会歴、嗜好、アレルギー、現症・身体所見、血液検査・画像検査等各種の検査結果、予約の状況、入院後経過、看護記録、治療方針、治療の目的、等の幅広い内容を取り扱うものとする。ここでは、患者Ｘのバイタル情報（体温、血圧（上）、血圧（下）、脈拍）ドキュメントを選択したものとする。

図７は、端末１００に患者Ｘのバイタル情報を表示する場合の画面例である。図７では、タブレットの入出力部１４０にバイタル情報を表示する例を示しているが、これはあくまで一例であり、端末の種類は問わないものとする。患者Ｘのバイタル情報を表示する場合の例として、ウインドウ７０１に項目名として、患者名７１０、体温７２０、血圧（上）７３０、血圧（下）７４０、脈拍７５０を表示する。また、患者名表示７１１として、選択した患者の氏名を表示する。又は、ＩＤ等患者を特定できる表示で代用してもよいし、両方を併記してもよい。また、コンボボックス７２１には体温の値を、コンボボックス７３１には血圧（上）の値を、コンボボックス７４１には血圧（下）の値を、コンボボックス７５１には脈拍の値を、入力又は表示するものとする。ここで、コンボボックス７２１、７３１、７４１、７５１は、必ずしもコンボボックスである必要はなく、それぞれのデータの値の入力、変更、表示が可能であればよいものとする。また、サーバ２００から、必要なデータの取得ができなかった場合には、未入力の項目であると考えられるため、空欄のまま表示してもよいし、未入力であることが分かるように＜未入力＞等の表示を行ってもよい。また、更新情報表示７６０のように、誰がいつバイタル情報を更新したか、日時とユーザ名を表示してもよい。

図３に戻り、端末１００からの患者とドキュメント選択の通知を受けて、サーバ２００のデータ格納モジュール２１１は、患者Ｘのバイタル情報ドキュメント表示に必要なデータの検索を行う（ステップＳ３０３）。ここでは、すでに記憶部２３０に、患者Ｘの体温、血圧（上）、血圧（下）が記憶されているものとする。

データ格納モジュール２１１は、ステップＳ３０３で検索した患者Ｘのバイタル情報（体温、血圧（上）、血圧（下））を、データとして端末１００に送信する（ステップＳ３０４）。ここで、患者Ｘのバイタル情報のうち、脈拍はデータとして記憶されていないことを、あわせて送信してもよい。

次に、端末１００のドキュメント編集モジュール１４１は、患者Ｘのバイタル情報（体温、血圧（上）、血圧（下））をデータとして受信する（ステップＳ３０５）。患者Ｘのバイタル情報のうち、脈拍はデータとして記憶されていないことがサーバ２００から送信された場合は、これもあわせて受信するものとする。

ステップＳ３０４のデータ格納モジュール２１１によるデータの送信と、ステップＳ３０５のドキュメント編集モジュール１４１によるデータの受信は、ドキュメントの表示に必要な項目分、データをまとめて送受信してもよいし、項目毎にデータを分けて、ステップＳ３０４とステップＳ３０５を繰り返してもよいものとする。

ドキュメント編集モジュール１４１は、ステップＳ３０５で受信したデータをもとに、患者Ｘのバイタルデータをドキュメントとして表示する（ステップＳ３０６）。この段階では、脈拍のデータがないので、図７のコンボボックス７５１は空欄で表示するか、＜未入力＞等の表示を行う。

次に、データ入力受付モジュール１４２は、ユーザ４００からのデータ入力を受け付ける（ステップＳ３０７）。ここでは、ユーザ４００は、端末１００の入出力部１４０を介して、患者Ｘの脈拍が７１回／分であることを入力したものとする。

そして、データ入力受付モジュール１４２は、患者Ｘの脈拍が７１回／分であるという入力データを、サーバ２００に送信する（ステップＳ３０８）。入力データとあわせて、入力日時とユーザ４００の情報を送信してもよい。

サーバ２００のデータ格納モジュール２１１は、端末１００から入力データを受信する（ステップＳ３０９）。ここでは、患者Ｘの脈拍が７１回／分であることを受信する。端末１００から、入力日時とユーザの情報が送信された場合には、あわせて受信する。

データ格納モジュール２１１は、受信した入力データを記憶部２３０のオブジェクトに格納する（ステップＳ３１０）。ここで、患者Ｘの脈拍が７１回／分であるということをあらわすデータを記憶部２３０の最小サイズのオブジェクトに格納する。入力日時とユーザの情報をあわせて受信した場合には、その情報もあわせて格納してもよいし、別オブジェクトとして格納してもよい。ここで、記憶部２３０には、患者Ｘのバイタルデータとして、体温、血圧（上）、血圧（下）、脈拍が記憶されたため、例えば、この後にユーザ４００Ｂが端末１００Ｂで患者Ｘのバイタル情報を表示させた場合には、図７のコンボボックス７５１には、脈拍が７１回／分であることを表示することができる。

ここでの、オブジェクトとは、一度に参照可能なデータのまとまりのことである。オブジェクトのサイズが小さいと、変更時のデータ通信に要する時間がほとんどかからないという利点がある。そのため、変更時のデータ通信に要する時間が数ミリ秒の遅延の範囲内ですみ、複数人でのリアルタイム性のある並行した編集が可能となる。逆に、オブジェクトのサイズが大きいと、データ通信に要する時間は長くなるが、一度のデータアクセスでまとめてデータを取得できるという利点がある。

図９は、本発明でリアルタイム編集を行うために、データを最小サイズのオブジェクトとして扱う際の模式図である。端末１００の記憶部２３０を模式的に示しており、左側がリアルタイム編集可能な、最小単位のオブジェクトに分割されたデータである。右側は、リアルタイム編集対象外の、まとめられたオブジェクトである。ここで、左側に示す通り、患者Ｘの体温データ、患者Ｘの血圧（上）データ、患者Ｘの血圧（下）データ、患者Ｘの脈拍データ、はそれぞれが１つのオブジェクトである。また、患者Ｘの受付情報データも、独立したオブジェクトとする。同じように、患者Ｙの体温データ、患者Ｙの血圧（上）データ、患者Ｙの血圧（下）データ、患者Ｙの脈拍データ、患者Ｙの受付情報データも、それぞれが独立したオブジェクトである。

図３に戻り、データの参照や編集の必要がなくなった場合、ユーザ４００はログアウト要求をサーバ２００に送信し、電子カルテの情報管理システムからログアウトする（ステップＳ３１１）。

また、一定時間の経過後、サーバ２００のサイズ変更モジュール２１２は、オブジェクトのサイズ変更を行う（ステップＳ３１２）。ここでのサイズ変更とは、入力済みの複数のオブジェクトを一つのオブジェクトとして統合し、オブジェクトのサイズを拡大することである。また、ここで、一定時間経過後とは、ドキュメント作成日の翌日の所定の時刻、又は、ドキュメントの確定処理を行った翌日の所定の時刻であることが望ましい。なぜかというと、電子カルテのシステムを考えた場合、診察情報は、基本的に診察の翌日以降の編集を行わないため、データを最小サイズのオブジェクトのままにしておき、リアルタイムに編集できる構成を維持する必要が無いためである。運用の例としては、患者のカルテは作成日の翌日の所定の時刻を一定時間経過後とし、その他の文書データのドキュメントは、確定処理を行った翌日の所定の時刻を一定時間経過後とすることが考えられる。ここでの確定処理とは、ドキュメントの保存処理または、ドキュメントのクローズ処理等、システムに応じて設定可能とする。

図１０は、本発明で一定時間が経過しリアルタイム編集が必要でなくなった場合に、データを結合してオブジェクトのサイズを拡大した際の模式図である。端末１００の記憶部２３０を模式的に示しており、右側は、リアルタイム編集対象外の、まとめられたオブジェクトである。ここで、患者Ｘのバイタル情報として、患者Ｘの体温データ、血圧（上）データ、血圧（下）データ、脈拍データと、患者Ｘの受付情報データをまとめて、１つのオブジェクトとする。また、同じように、患者Ｙのバイタル情報として、患者Ｙの体温データ、血圧（上）データ、血圧（下）データ、脈拍データと、患者Ｙの受付情報データをまとめて、１つのオブジェクトとする。さらに、患者バイタル情報一覧として、患者Ｘの受付情報データ、体温データ、血圧（上）データ、血圧（下）データ、脈拍データと患者Ｙの受付情報データ、体温データ、血圧（上）データ、血圧（下）データ、脈拍データをまとめて、１つのオブジェクトとする。このほかに、患者Ｘの体温データとして過去のデータに今回のデータを加えたものを１つのオブジェクト、患者Ｘの血圧（上）データとして過去のデータに今回のデータを加えたものを１つのオブジェクト、患者Ｘの血圧（下）データとして過去のデータに今回のデータを加えたものを１つのオブジェクト、患者Ｘの脈拍データとして過去のデータに今回のデータを加えたものを１つのオブジェクト、として更新する。今回が初診で過去のデータがない患者Ｙについては、患者Ｘの体温データとして今回のデータを初回としたものを１つのオブジェクト、患者Ｘの血圧（上）データとして今回のデータを初回としたものを１つのオブジェクト、患者Ｘの血圧（下）データとして今回のデータを初回としたものを１つのオブジェクト、患者Ｘの脈拍データとして今回のデータを初回としたものを１つのオブジェクト、として新規に作成する。このように、リアルタイム編集が必要なくなったデータをまとめることで、例えば、患者Ｘの体温データをまとめたオブジェクトにアクセスすると、記憶部２３０に対して一回のアクセスで過去の体温データ全てを取得することが可能となり、システムのパフォーマンスに与える影響が小さくてすむ。リアルタイム編集可能な、最小サイズのオブジェクトのままだと、過去の体温データの数と同じ回数だけ、それぞれのオブジェクトにアクセスしなければならない。

図１１は、従来の手法でデータの更新を行った場合の模式図である。従来の手法では、ドキュメント毎にデータを保持する。図１１では、患者Ｘの体温をデータとして含むドキュメントの種類として、患者毎のバイタル情報、患者バイタル情報一覧、ドキュメントＺがある場合を示している。ここで、患者Ｘのバイタル情報ドキュメントの体温データが更新された場合、あわせて、患者バイタル情報一覧ドキュメントの患者Ｘの体温データと、ドキュメントＺの患者Ｘの体温データを更新する必要がある。また、端末１００に患者バイタル情報一覧ドキュメントを表示している場合には、患者バイタル情報一覧に含まれる全データ、「患者Ｘの受付情報データ、体温データ、血圧（上）データ、血圧（下）データ、脈拍データ、患者Ｙの受付情報データ、体温データ、血圧（上）データ、血圧（下）データ、脈拍データ」を端末１００で再読み込みしなければならない。このように、１つのドキュメント内のある項目を変更すると、不整合を生じないために、同項目を含む全てのドキュメントのデータを更新する必要がある。また、各端末１００に表示しているドキュメントのデータを更新するために、ドキュメント全体のデータを再読み込みする必要がある。このように、従来方式では、処理が複雑になり、かつ、データの通信量が増大するため、リアルタイムな並行した編集は困難である。

以上のように、本発明によれば、複数のユーザにアクセスされるデータを処理する電子カルテシステムにおいて、患者のデータに対する同時アクセスを可能とし、なおかつユーザ間のデータの不整合を防ぐことができ、パフォーマンス性の高い情報管理システム、情報管理方法、およびプログラムを提供することが可能となる。

［ドキュメント更新処理］
図４は、データの更新によるドキュメント更新処理を行う場合の、端末１００とサーバ２００の機能ブロックと各機能の関係を示す図である。端末１００の構成は、図２の構成に加えて、入出力部１４０が、制御部１１０、通信部１２０、記憶部１３０と協働してドキュメント更新モジュール１４３を実現する。また、サーバ２００の構成は、図２の構成に加えて、制御部２１０が、記憶部２３０と協働してデータ更新確認モジュール２１３を実現する。通信網３００は、インターネット等の公衆通信網でも専用通信網でもよく、端末１００とサーバ２００間の通信を可能とする。図４において、端末１００の数およびサーバ２００の数は一つに限らず複数であってもよい。ここでは、デスクトップコンピュータの端末１００Ａと、タブレットの端末１００Ｂを図示しているが、端末１００Ａも端末１００Ｂも、端末１００の機能ブロックを備えるものとする。

図５は、データの更新によるドキュメント更新処理を行う場合の、端末１００Ａと端末１００Ｂとサーバ２００のフローチャート図である。上述した各装置のモジュールが実行する処理について、本処理にあわせて説明する。

はじめに、端末１００Ｂのドキュメント編集モジュール１４１は、患者のドキュメントを表示する（ステップＳ５０１）。簡略化のためフローチャートに表示していないが、ユーザ４００Ｂの使用する端末１００Ｂは、電子カルテの情報管理システムへのログイン処理を行ったものとする。また、ここでは、患者Ｘのバイタル情報（体温、血圧（上）、血圧（下）、脈拍）ドキュメントを選択し、患者Ｘの必要なデータを受信した後に、患者Ｘのバイタル情報ドキュメントを表示したものとする。ここのタイミングでは、データを取得した患者Ｘの体温、血圧（上）、血圧（下）を表示し、データが存在しない脈拍は値を表示しないものとする。

端末１００Ａのドキュメント編集モジュール１４１は、ユーザ４００Ａに、情報を表示したい患者とドキュメントの種類を選択させ、選択内容をサーバ２００に通知する（ステップＳ５０２）。簡略化のためフローチャートに表示していないが、ステップＳ５０２は、ユーザ４００Ａの使用する端末１００Ａが、電子カルテの情報管理システムへのログイン処理を行ったあとであるとする。また、ここでは、患者Ｘのバイタル情報（体温、血圧（上）、血圧（下）、脈拍）ドキュメントを選択したものとする。

端末１００Ａからの患者とドキュメント選択の通知を受けて、サーバ２００のデータ格納モジュール２１１は、患者Ｘのバイタル情報ドキュメント表示に必要なデータの検索を行う（ステップＳ５０３）。ここでは、すでに記憶部２３０に、患者Ｘの体温、血圧（上）、血圧（下）が記憶されているものとする。

データ格納モジュール２１１は、ステップＳ５０３で検索した患者Ｘのバイタル情報（体温、血圧（上）、血圧（下））を、データとして端末１００に送信する（ステップＳ５０４）。ここで、患者Ｘのバイタル情報のうち、脈拍はデータとして記憶されていないことを、あわせて送信してもよい。

次に、端末１００Ａのドキュメント編集モジュール１４１は、患者Ｘのバイタル情報（体温、血圧（上）、血圧（下））をデータとして受信する（ステップＳ５０５）。患者Ｘのバイタル情報のうち、脈拍はデータとして記憶されていないことがサーバ２００から送信された場合は、これもあわせて受信するものとする。

ステップＳ５０４のデータ格納モジュール２１１によるデータの送信と、ステップＳ５０５のドキュメント編集モジュール１４１によるデータの受信は、ドキュメントの表示に必要な項目分、データをまとめて送受信してもよいし、項目毎にデータを分けて、ステップＳ５０４とステップＳ５０５を繰り返してもよいものとする。

ドキュメント編集モジュール１４１は、ステップＳ５０５で受信したデータをもとに、患者Ｘのバイタルデータをドキュメントとして表示する（ステップＳ５０６）。この段階では、脈拍のデータがないので、脈拍は値を表示しないものとする。

次に、データ入力受付モジュール１４２は、ユーザ４００Ａからのデータ入力を受け付ける（ステップＳ５０７）。ここでは、ユーザ４００Ａは、端末１００Ａの入出力部１４０を介して、患者Ｘの脈拍が７１回／分であることを入力したものとする。

そして、データ入力受付モジュール１４２は、患者Ｘの脈拍が７１回／分であるという入力データを、サーバ２００に送信する（ステップＳ５０８）。入力データとあわせて、入力日時とユーザ４００の情報を送信してもよい。

サーバ２００のデータ格納モジュール２１１は、端末１００Ａから入力データを受信する（ステップＳ５０９）。ここでは、患者Ｘの脈拍が７１回／分であることを受信する。端末１００から、入力日時とユーザの情報が送信された場合には、あわせて受信する。

データ格納モジュール２１１は、受信した入力データを記憶部２３０のオブジェクトに格納する（ステップＳ５１０）。ここで、患者Ｘの脈拍が７１回／分であるということをあらわすデータを記憶部２３０の最小サイズのオブジェクトに格納する。入力日時とユーザの情報をあわせて受信した場合には、その情報もあわせて格納してもよいし、別オブジェクトとして格納してもよい。

次に、サーバ２００のデータ更新確認モジュール２１３は、患者Ｘのバイタル情報をドキュメントとして表示している端末１００Ａと端末１００Ｂに、それぞれ更新された患者Ｘの脈拍データを送信する（ステップＳ５１０）。

端末１００Ａのドキュメント更新モジュール１４３と、端末１００Ｂのドキュメント更新モジュール１４３は、患者Ｘの脈拍データを更新データとして受信する（ステップＳ５１１）。

端末１００Ａのドキュメント更新モジュール１４３と、端末１００Ｂのドキュメント更新モジュール１４３は、それぞれステップＳ５１１で受信したデータをもとに、患者Ｘのバイタル情報ドキュメントを更新する（ステップＳ５１２）。端末１００Ｂも、患者Ｘの脈拍データを受信したので、ちょうど図７の表示のように、コンボボックス７５１にも脈拍の値が表示される。

一定時間の経過後、サーバ２００のサイズ変更モジュール２１２は、オブジェクトのサイズ変更を行う（ステップＳ５１３）。ここでのサイズ変更とは、入力済みの複数のオブジェクトを一つのオブジェクトとして統合し、オブジェクトのサイズを拡大することである。ここで、一定時間とは、最初のデータ入力受付又は最後のデータ入力受付から２４時間以上であることが望ましい。なぜかというと、電子カルテのシステムを考えた場合、診察情報は、基本的に診察の翌日以降の編集を行わないため、データを最小サイズのオブジェクトのままにしておき、リアルタイムに編集できる構成を維持する必要が無いためである。

以上のように、本発明によれば、複数のユーザにアクセスされるデータを処理する電子カルテシステムにおいて、患者のデータに対する同時アクセスを可能とし、なおかつユーザ間のデータの不整合を防ぐことができ、パフォーマンス性の高い情報管理システム、情報管理方法、およびプログラムを提供することが可能となる。

［リアルタイム編集時のデータの流れ］
図６は、本発明における端末１００とサーバ２００の記憶部２３０間のデータの流れの模式図である。図７は、端末１００に患者Ｘのバイタル情報を表示する場合の画面例である。図８は、端末１００に患者のバイタル情報一覧を表示する場合の画面例である。これらの図に基づいて、本発明において、複数のユーザ４００がそれぞれの端末１００でドキュメントを編集する場合の、データの流れについて説明する。

図６では、医師であるユーザ４００Ａがデスクトップコンピュータの端末１００Ａを使用して、患者Ｘのバイタル情報を表示している。また、診療助手であるユーザ４００Ｂもタブレットの端末１００Ｂを使用して、患者Ｘのバイタル情報を表示している。医師であるユーザ４００Ｃは、デスクトップコンピュータである端末１００Ｃ１とタブレットである端末１００Ｃ２を同時に使用して、それぞれに患者Ｙのバイタル情報を表示している。看護師であるユーザ４００Ｄはタブレット端末１００Ｄを使用して、患者バイタル情報一覧を表示している。同じく看護師であるユーザ４００Ｅもタブレット端末１００Ｅを使用して、患者情報一覧を表示している。ここで、ユーザ４００Ｃのように、一人のユーザが端末を複数利用する場合には、一方の端末で選択した患者を、他方の端末でも自動的に選択してもよい。また、複数の端末の使い道としては、例えば、タブレット端末１００Ｃ２で写真をとり、デスクトップコンピュータ１００Ｃ１で入力を行う、等が考えられる。各ユーザ４００が、ドキュメントを選択すると、それぞれの端末１００のドキュメント編集モジュール１４１が、ドキュメントを構成する項目とユーザ４００との関連付けを行う。ユーザはそれぞれ別のドキュメントを表示していても、そのドキュメントを構成する項目のデータは、サーバ２００の記憶部２３０内の同一オブジェクトである。

図７は、前述のとおり、端末１００に患者Ｘのバイタル情報を表示する場合の画面例である。図７では、タブレットの入出力部１４０にバイタル情報を表示する例を示しているが、これはあくまで一例であり、端末の種類は問わないものとする。患者Ｘのバイタル情報を表示する場合の例として、ウインドウ７０１に項目名として、患者名７１０、体温７２０、血圧（上）７３０、血圧（下）７４０、脈拍７５０を表示する。また、患者名表示７１１として、選択した患者の氏名を表示する。又は、ＩＤ等患者を特定できる表示で代用してもよいし、両方を併記してもよい。また、コンボボックス７２１には体温の値を、コンボボックス７３１には血圧（上）の値を、コンボボックス７４１には血圧（下）の値を、コンボボックス７５１には脈拍の値を、入力又は表示するものとする。ここで、コンボボックス７２１、７３１、７４１、７５１は、必ずしもコンボボックスである必要はなく、それぞれのデータの値の入力、変更、表示が可能であればよいものとする。また、サーバ２００から、必要なデータの取得ができなかった場合には、未入力の項目であると考えられるため、空欄のまま表示してもよいし、未入力であることが分かるように＜未入力＞等の表示を行ってもよい。また、更新情報表示７６０のように、誰がいつバイタル情報を更新したか、日時とユーザ名を表示してもよい。

図８は、端末１００に患者のバイタル情報一覧を表示する場合の画面例である。図８では、タブレットの入出力部１４０にバイタル情報を表示する例を示しているが、これはあくまで一例であり、端末の種類は問わないものとする。患者のバイタル情報を表示する場合の例として、ウインドウ８０１に表８０２として、患者名、体温、血圧（上）、血圧（下）、脈拍を表示する。ここでは、患者Ｘと患者Ｙのデータのみを表示しているが、患者の人数にあわせて、すべての情報を表示してもよいし、表示する情報数を選択できるようにしてもよい。また、サーバ２００から、必要なデータの取得ができなかった場合には、未入力の項目であると考えられるため、空欄のまま表示してもよいし、未入力であることが分かるように＜未入力＞等の表示を行ってもよい。

まず、ユーザ４００Ｄが端末１００Ｄを使用して、患者Ｘの体温を更新する場合を考える。この場合、ユーザ４００Ｄは、図８に示す端末１００Ｄの入出力部１４０を使用して、表８０２の患者Ｘの体温（℃）のデータを更新する。端末１００Ｄのデータ入力受付モジュール１４２は、ユーザ４００Ｄによるデータ入力を受け付け、入力されたデータをサーバ２００に送信する。サーバ２００のデータ格納モジュールは、患者Ｘの体温データをオブジェクトに格納する。その後、データ更新確認モジュール１４３は、患者Ｘの体温データの項目と関連付けられたユーザ４００に対して、更新したデータの同時送信を行う。更新したデータの送信は、データの更新をおこなったユーザ自身にも行うものとする。ここでは、患者Ｘのバイタル情報を表示しているユーザ４００Ａの端末１００Ａと、患者Ｘのバイタル情報を表示しているユーザ４００Ｂの端末１００Ｂと、患者バイタル情報一覧を表示しているユーザ４００Ｄの端末１００Ｄと、患者バイタル情報一覧を表示しているユーザ４００Ｅの端末１００Ｅに更新したデータの送信を行う。各端末１００のドキュメント更新モジュール１４３は、更新されたデータを受信して、ドキュメントの更新を行う。

次に、ユーザ４００Ｃが端末１００Ｃ２を使用して、患者Ｙの脈拍を更新する場合を考える。図７は患者Ｘのバイタル情報を表示した例を示しているが、この場合、ユーザ４００Ｃは、端末１００Ｃ２の画面に表示された、患者Ｙのバイタル情報を更新する。端末１００Ｃ２の入出力部１４０を使用して、コンボボックス７５１に相当する箇所の患者Ｙの脈拍（回／分）のデータを更新する。端末１００Ｃ２のデータ入力受付モジュール１４２は、ユーザ４００Ｃによるデータ入力を受け付け、入力されたデータをサーバ２００に送信する。サーバ２００のデータ格納モジュールは、患者Ｙの脈拍データをオブジェクトに格納する。その後、データ更新確認モジュール１４３は、患者Ｙの脈拍データの項目と関連付けられたユーザ４００に対して、更新したデータの同時送信を行う。更新したデータの送信は、データの更新をおこなったユーザ自身にも行うものとする。ここでは、患者Ｙのバイタル情報を表示しているユーザ４００Ｃの端末１００Ｃ１、端末１００Ｃ２と、患者バイタル情報一覧を表示しているユーザ４００Ｄの端末１００Ｄと、患者バイタル情報一覧を表示しているユーザ４００Ｅの端末１００Ｅに更新したデータの送信を行う。各端末１００のドキュメント更新モジュール１４３は、更新されたデータを受信して、ドキュメントの更新を行う。

このように、各端末１００のドキュメントを更新すると、更新した項目のサーバ２００内のオブジェクト自体のデータを更新し、その更新内容を項目に関連するドキュメントを表示している端末１００に送信して、各ドキュメントの更新を行う。オブジェクトを最小サイズに分割しているため、更新したデータの送信は、数ミリ秒の範囲内に収まり、その結果、複数人でのリアルタイムな並行した編集が可能となる。

［電子カルテシステムの画面表示例］
図１２は、本発明による電子カルテシステムの画面表示の一例である。端末１００の入出力部１４０に、入院患者の検査画像を表示している。ここでは、画面上部に患者のデータを表示し、画面左部に受付リストとして外来や入院等の患者の分類等を表示し、画面中央部に患者の検査画像を表示し、画面右部に患者の診察履歴を表示する例を示している。このように、電子カルテシステムでは、前述したような数値によるデータのみではなく、内視鏡画像、レントゲン画像、ＣＴ（Ｃｏｍｐｕｔｅｄ Ｔｏｍｏｇｒａｐｈｙ）画像、等の検査画像の取り扱いも行う。この場合、画像データも同じようにオブジェクトに格納するものとする。

また、図１２で画面右部に表示しているような、患者の診察履歴のドキュメントを作成する場合、前述したサイズ変更モジュール２１２によるオブジェクトのサイズ変更で、オブジェクトをまとめる処理が有効である。患者の履歴が多い場合にも、オブジェクトがまとめてあるため、端末１００からサーバ２００に対して少ないアクセス回数で、必要なデータを取得することが可能となる。このように、リアルタイム編集による利便性と、過去の履歴を参照する際のパフォーマンスとを、両立させることが可能である。

これ以外にも、電子カルテシステムでは、診療記録、処方、注射、看護記録、処置、手術、画像、検査結果、リハビリ、健診、問診、説明同意書、看護要約、リハビリ計画書、各種証明書、等、様々なドキュメントを扱うが、本手法では、データをオブジェクトとして取り扱うため、必要な項目のデータのみを容易に抽出することができ、時系列でのデータ表示や項目を組み合わせてのデータ表示等、様々な形態のドキュメントを表示することが可能となるという利点がある。また、ドキュメント毎にデータの管理を行わないため、ドキュメントの様式変更があった場合や、項目の種類変更があった場合等にも、容易に対応することができる。

［オブジェクトの特性情報］
図１３は、本発明による電子カルテシステムにおいて、各オブジェクトがもつ特性情報を示す模式図である。ドキュメントαは、図１３の上部に示すように、Ａ項目オブジェクト、Ｂ項目オブジェクト、Ｃ項目オブジェクト、Ｄ項目オブジェクト、Ｅ項目オブジェクト、Ｆ項目オブジェクトの６つのオブジェクトからなるものとする。図１３の下部に示すように、これら、それぞれのオブジェクトが、「数値フィールド、ラジオボタン、チェックボタン、数字チェックボタン、コンボボックス、セレクトボックス、日付フィールド、時間フィールド、画像、カメラ、署名コントロール、ラインコントロール、図形コントロール、検索フィールド、郵便番号フィールド、住所フィールド、薬剤フィールド、薬剤コメントフィールド、用法フィールド」等の特性情報を備える。電子カルテシステムは、各オブジェクトのこれらの特性情報を利用して、ドキュメントαを表示する。

図１４は、本発明による電子カルテシステムにおいて、各オブジェクトがもつ特性情報に基づいて作成されたドキュメントの画面表示の一例である。図１４に示すドキュメントβでは、診断名、家族構成、氏名、生年月日、住所、ＴＥＬ、入院日、退院日、等の各項目が、各オブジェクトに相当する。ドキュメントβの各項目の範囲に限らず、オブジェクトは、ユーザがドキュメントとして取り扱いたい範囲を網羅しなければならないため、広範囲のデータに対応するものとする。例として前述した数値によるバイタルデータの他にも、家系図（図形データ）や、医師による説明画像（手書き画像）、手術中の映像（動画）等も取り扱いデータとして対応することで、幅広いドキュメントを扱うことが可能となる。

以上のように、本発明によれば、複数のユーザにアクセスされるデータを処理する電子カルテシステムにおいて、患者のデータに対する同時アクセスを可能とし、なおかつユーザ間のデータの不整合を防ぐことができ、パフォーマンス性の高い情報管理システム、情報管理方法、およびプログラムを提供することが可能となる。

上述した手段、機能は、コンピュータが、所定のプログラムを読み込んで、実行することによって実現される。プログラムは、例えば、コンピュータからネットワーク経由で提供される形態であってもよいし、フレキシブルディスク、ＣＤ、ＤＶＤ、コンパクトメモリ等のコンピュータ読取可能な記録媒体に記録された形態で提供される形態であってもよい。この場合、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置又は外部記憶装置に転送し記憶して実行する。また、そのプログラムを、例えば、磁気ディスク、光ディスク、光磁気ディスク等の記憶装置に予め記録しておき、その記憶装置から通信回線を介してコンピュータに提供するようにしてもよい。

以上、本発明の実施形態について説明したが、本発明は上述したこれらの実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態に記載されたものに限定されるものではない。

１００ 端末、２００ サーバ、３００ 通信網、４００ ユーザ

Claims (7)

1. 複数のユーザに同時にアクセスされるデータを処理し、一度に参照可能なデータのまとまりをオブジェクトとして扱う情報管理システムにおいて、
   前記オブジェクトのデータを参照して前記複数のユーザ各々に編集可能なドキュメントを表示するドキュメント編集手段と、
   前記ドキュメントの項目に対して、データの入力を受け付けるデータ入力受付手段と、
   前記入力されたデータをオブジェクト毎に格納するデータ格納手段と、
   一定時間経過後に、前記オブジェクトを結合することでサイズを拡大するサイズ変更手段と、
   を備えることを特徴とする情報管理システム。
2. 前記データ格納手段は、前記入力されたデータを前記ドキュメントの項目毎に独立したオブジェクトとして格納し、
   前記サイズ変更手段は、一定時間経過後に、前記入力済みの複数のオブジェクトを一つのオブジェクトとして統合し、オブジェクトのサイズを拡大することを特徴とする請求項１に記載の情報管理システム。
3. 前記受け付けた項目毎のデータにアクセスしているユーザ全てに更新されたかどうかを確認するデータ更新確認手段と、
   前記データ更新確認手段により項目毎のデータが更新されたことが検出された場合に、前記ドキュメントが参照するオブジェクトのうち更新が必要な最小サイズのオブジェクトのみ、データを更新するドキュメント更新手段をさらに備えたことを特徴とする請求項１又は請求項２に記載の情報管理システム。
4. 前記一定時間経過後とは、前記ドキュメント作成日の翌日の所定の時刻又は前記ドキュメントの確定処理を行った翌日の所定の時刻であることを特徴とする請求項１から請求項３のいずれか一項に記載の情報管理システム。
5. 前記データが、電子カルテに入力されるデータであることを特徴とする請求項１から請求項４のいずれか一項に記載の情報管理システム。
6. 複数のユーザに同時にアクセスされるデータを処理し、一度に参照可能なデータのまとまりをオブジェクトとして扱う情報管理方法において、
   前記オブジェクトのデータを参照して前記複数のユーザ各々に編集可能なドキュメントを表示するステップと、
   前記ドキュメントの項目に対して、データの入力を受け付けるステップと、
   前記入力されたデータをオブジェクト毎に格納するステップと、
   一定時間経過後に、前記オブジェクトを結合することでサイズを拡大するステップと、
   を備えることを特徴とする情報管理方法。
7. 複数のユーザに同時にアクセスされるデータを処理し、一度に参照可能なデータのまとまりをオブジェクトとして扱う情報管理システムに、
   前記オブジェクトのデータを参照して前記複数のユーザ各々に編集可能なドキュメントを表示するステップ、
   前記ドキュメントの項目に対して、データの入力を受け付けるステップ、
   前記入力されたデータをオブジェクト毎に格納するステップ、
   一定時間経過後に、前記オブジェクトを結合することでサイズを拡大するステップ、
   を実行させるためのプログラム。