(57)【要約】【課題】  電子カルテなどに入力された情報を適切に表示する。【解決手段】  少なくとも一つの入力項目を有する入力テンプレートを介して電子カルテに入力された情報を取得する情報取得手段と、前記入力テンプレートが有する前記入力項目の属性を取得する属性取得手段と、前記属性取得手段により取得された前記属性に応じて、前記情報取得手段により取得された情報が表示される表示領域の大きさを決定する決定手段と、前記決定手段により決定された大きさの表示領域に前記情報取得手段により取得された情報を表示する表示手段と、を有する。【選択図】  図１
2019032760.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも一つの入力項目を有する入力テンプレートを介して電子カルテに入力された情報を取得する情報取得手段と、
前記入力テンプレートが有する前記入力項目の属性を取得する属性取得手段と、
前記属性取得手段により取得された前記属性に応じて、前記情報取得手段により取得された情報が表示される表示領域の大きさを決定する決定手段と、
前記決定手段により決定された大きさの表示領域に前記情報取得手段により取得された情報を表示する表示手段と、
を有することを特徴とする医療支援システム。
【請求項２】
前記属性は、前記入力項目の種類であることを特徴とする請求項１に記載の医療支援システム。
【請求項３】
前記入力項目の種類に対して、前記入力項目に対して予め定められた１行当りの文字数および前記入力項目に対して予め定められた最大文字数が対応付けられた情報を保持する保持手段を更に備え、
前記決定手段は、前記入力項目の種類および前記保持手段に記憶された前記情報に基づいて、前記情報取得手段により取得された情報が表示される表示領域の大きさを決定することを特徴とする請求項２に記載の医療支援システム。
【請求項４】
前記決定手段は、前記最大文字数を前記１行当りの文字数で除することで、前記情報取得手段により取得された情報が表示される表示領域の大きさを決定することを特徴とする請求項３に記載の医療支援システム。
【請求項５】
前記決定手段は、前記属性取得手段により取得された前記属性に応じて、前記表示手段に前記情報取得手段により取得された情報を表示する際に前記情報取得手段により取得された情報の末尾の表示を省略可能か否か決定し、
前記決定手段により前記末尾の表示を省略可能と決定した場合、前記表示手段は、前記情報取得手段により取得された情報を末尾の表示を省略して表示することを特徴とする請求項１乃至４のいずれか１項に記載の医療支援システム。
【請求項６】
前記表示手段は、前記情報取得手段により取得された情報と、前記情報取得手段により取得された情報に対応する患者の識別情報とを並べて表示することを特徴とする請求項１乃至５のいずれか１項に記載の医療支援システム。
【請求項７】
電子カルテに情報を入力するためのテンプレートであり、複数の入力項目を有する入力テンプレートを複数種類保持する保持手段と、
前記電子カルテに情報を入力するために用いられた前記入力テンプレートの種類に応じて、前記複数の入力項目を介して前記電子カルテに入力された複数の情報が表示される複数の表示領域の配置を決定する決定手段と、
前記決定手段により決定された複数の表示領域に前記複数の情報を表示する表示手段と、
を備えることを特徴とする医療支援システム。
【請求項８】
少なくとも一つの入力項目を有する入力テンプレートを介して電子カルテに入力された情報を取得する情報取得工程と、
前記入力テンプレートが有する前記入力項目の属性を取得する属性取得工程と、
前記属性取得工程において取得された前記属性に応じて、前記情報取得工程において取得された情報が表示される表示領域の大きさを決定する決定工程と、
前記決定工程において決定された大きさの表示領域に前記情報取得工程において取得された情報を表示する表示工程と、
を有することを特徴とする医療支援方法。
【請求項９】
請求項８に記載の医療支援方法の各工程をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書に開示の技術は、医療支援システム、医療支援方法およびプログラムに関する。
【背景技術】
【０００２】
電子カルテに入力された情報を表示手段が表示する場合、情報によっては文字数が表示領域に対して多いために表示領域に収まらない場合があった。
【０００３】
なお、表示領域に対して文字数が多い場合、文字自体を縮小して表示する技術が知られている（特許文献１）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１５−１６２１９０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記の技術では、文字自体が小さくなるため文字の視認性が下がるという問題点があった。すなわち、上記の技術では、情報を適切に表示できないという問題点があった。
【０００６】
本明細書に開示の技術は、電子カルテなどに入力された情報を適切に表示することを目的の１つとする。
【０００７】
なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本件の他の目的の１つとして位置付けることができる。
【課題を解決するための手段】
【０００８】
本明細書に開示の医療支援システムは、少なくとも一つの入力項目を有する入力テンプレートを介して電子カルテに入力された情報を取得する情報取得手段と、前記入力テンプレートが有する前記入力項目の属性を取得する属性取得手段と、前記属性取得手段により取得された前記属性に応じて、前記情報取得手段により取得された情報が表示される表示領域の大きさを決定する決定手段と、前記決定手段により決定された大きさの表示領域に前記情報取得手段により取得された情報を表示する表示手段と、を有する。
【発明の効果】
【０００９】
開示の技術によれば、電子カルテなどに入力された情報を適切に表示することが可能となる。
【図面の簡単な説明】
【００１０】
【図１】カンファレンス支援システムの全体構成の一例を示す図である。
【図２】情報処理装置の内部構成の一例を示す図である。
【図３】カンファレンス支援アプリケーションの画面の一例を示す図である。
【図４】リハビリ計画書テンプレートの一例を示す図である。
【図５】栄養指導テンプレートの一例を示す図である。
【図６】検体発送テンプレートの一例を示す図である。
【図７】データタイプ定義表の一例を示す図である。
【図８】カルテ記事表の一例を示す図である。
【図９】患者情報表とスタッフ情報表の一例を示す図である。
【図１０】会議対象患者表の一例を示す図である。
【図１１】会議情報表と会議体情報表の一例を示す図である。
【図１２】フローチャートで使われる表記の一例を示す図である。
【図１３】患者一覧部分のＨＴＭＬ用ＤＯＭを作成する処理の一例を示すフローチャートである。
【図１４】患者行部分のＨＴＭＬ用ＤＯＭを作成する処理の一例を示すフローチャートである。
【図１５】患者備考部分のＨＴＭＬ用ＤＯＭを作成する処理の一例を示すフローチャートである。
【図１６】備考項目部分のＨＴＭＬ用ＤＯＭを作成する処理の一例を示すフローチャートである。
【図１７】ＴＥＸＴＡＲＥＡの場合のＨＴＭＬ用ＤＯＭを作成する処理の一例を示すフローチャートである。
【図１８】その他の場合のＨＴＭＬ用ＤＯＭを作成する処理の一例を示すフローチャートである。
【図１９】リハビリ計画書テンプレートの場合の患者行の例を示す図である。
【図２０】栄養指導テンプレートの場合の患者行の例を示す図である。
【図２１】検体発送テンプレートの場合の患者行の例を示す図である。
【図２２】ソート条件を変更する場合のフローチャートとソート条件の例を示す図である。
【図２３】個人情報保護機能を有する場合の処理手順の一例を示すフローチャートである。
【図２４】個人情報保護機能を有する場合の患者行の例を示す図である。
【図２５】サーバ機能を１つのサーバに統合した場合の全体構成の一例を示す図である。
【発明を実施するための形態】
【００１１】
以下、添付の図面を参照して、本実施形態に係る医療支援システムを説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は以下の実施形態に限定されるものではない。なお、本実施形態では、医療支援システムの一例としてカンファレンス支援システムを例としているがこれに限るものではない。
【００１２】
＜実施形態１＞
図１に本実施形態におけるカンファレンス支援システムの全体構成の一例を示す。なお、図１に示すカンファレンス支援システムは医療支援システムの一例に相当する。カンファレンス支援システムは、電子カルテサーバ１、カンファレンス支援サーバ２、複数台のクライアント３（１〜Ｎ）および院内ネットワーク４を含む。ここで、電子カルテサーバ１、カンファレンス支援サーバ２および複数台のクライアント３（１〜Ｎ）は院内ネットワーク４を介して互いに通信可能に接続されている。なお、図１においてクライアント３は複数台としているが１台であってもよい。
【００１３】
電子カルテサーバ１はデータ用記憶領域１１として機能するメモリを有する。なお、データ用記憶領域１１は、情報を記憶できればよく例えばＨＤＤまたはＳＳＤであってもよい。また、データ用記憶領域１１を複数のメモリ等で実現することとしてもよい。データ用記憶領域１１はカルテ記事表１１１、データタイプ定義表１１２、患者情報表１１３、スタッフ情報表１１４、入力テンプレートＨＴＭＬ１１５を記憶している。本実施例においてはデータ用記憶領域１１は入力テンプレートＨＴＭＬを複数種類保持している。
【００１４】
カルテ記事表１１１の一例を図８に示す。カルテ記事表１１１には電子カルテに関する情報が含まれている。具体的には、カルテ記事表１１１は、記事ＩＤ、患者ＩＤ、カルテの入力日時、カルテの内容（記事内容）、カルテの入力に用いたテンプレート名（入力テンプレート名）および入力テンプレートが有する少なくとも一つの入力項目に入力されたデータ（ＤＡＴＡ１−６）が対応付けられた情報を含む。なお、カルテ記事表１１１は図８の形式に限定されるわけではない。
【００１５】
データタイプ定義表１１２の一例を図７に示す。データタイプ定義表１１２には、入力テンプレートが有する入力項目に関する属性情報が含まれている。具体的には、データタイプ定義表１１２は、入力項目の種類（ｄａｔａ  Ｔｙｐｅ名）、入力項目に入力された情報を表示する際に末尾を省略可能か否かを示す情報、入力項目に入力された情報が個人情報であるか否かを示す情報、プレースホルダーの文字列（入力項目に対してユーザーが未入力の際に表示される文字列）、入力項目の最大文字数および入力項目に入力可能な１行あたりの文字数が対応付けられた情報を含む。なお、データタイプ定義表１１１は、入力項目に入力された情報を表示する際に末尾を省略可能か否かを示す情報、入力項目に入力された情報が個人情報であるか否かを示す情報およびプレースホルダーの文字列の少なくとも１つを含まないこととしてもよい。すなわち、データタイプ定義表１１２は図７の形式に限定されるわけではない。なお、データタイプ定義表１１１に示す数値等は例示であり、他の数値等とすることとしてもよい。
【００１６】
患者情報表１１３の一例を図９（ａ）に示す。患者情報表１１３は、患者ＩＤ、患者名、性別および生年月日が対応付けられた情報を含む。すなわち、患者情報表１１３は患者の識別情報を含む。なお、患者情報表１１３は例示であり、他の情報を含むこととしてもよいし、一部の情報を省略することとしてもよい。すなわち、患者情報表１１３は図９（ａ）の形式に限定されるわけではない。
【００１７】
スタッフ情報表１１４の一例を図９（ｂ）に示す。スタッフ情報表１１４は、スタッフＩＤ、スタッフ名、スタッフの職業が対応付けられた情報を含む。なお、スタッフ情報表１１４は図９（ｂ）の形式に限定されるわけではない。
【００１８】
入力テンプレートＨＴＭＬ１１５の例を図４（ｂ）、図５（ｂ）および図６（ｂ）に示す。入力テンプレートＨＴＭＬ１１５は、電子カルテへの入力を行うためのテンプレートである。各入力テンプレートＨＴＭＬをプロセッサが処理することで、表示画面には図４（ａ）、図５（ａ）および図６（ａ）に示す入力テンプレートが表示される。ここで、図４（ｂ）、図５（ｂ）および図６（ｂ）はそれぞれ、リハビリ計画書用の入力テンプレート、栄養指導用の入力テンプレートおよび検体発送用のテンプレートである。なお、入力テンプレートＨＴＭＬ１１５は上記の３つに限定されるものではなく、他の入力テンプレートＨＴＭＬを含むこととしてもよい。なお、入力テンプレートＨＴＭＬ１１５の内容は図４（ｂ）、図５（ｂ）および図６（ｂ）に限定されるわけではない。
【００１９】
カンファレンス支援サーバ２はデータ用記憶領域１２として機能するメモリを有する。なお、データ用記憶領域１２は、情報を記憶できればよく例えばＨＤＤまたはＳＳＤであってもよい。また、データ用記憶領域１２を複数のメモリ等で実現することとしてもよい。
【００２０】
データ用記憶領域１２は、会議対象患者表１２１、会議情報表１２２、会議体情報１２３、データタイプ定義表１２４、患者情報表１２５、スタッフ情報表１２６および入力テンプレートＨＴＭＬ１２７を記憶している。なお、データタイプ定義表１２４、患者情報表１２５、スタッフ情報表１２６および入力テンプレートＨＴＭＬ１２７は、電子カルテサーバ１が保持するデータタイプ定義表１１２、患者情報表１１３、スタッフ情報表１１４および入力テンプレートＨＴＭＬ１１５の複製である。
【００２１】
会議対象患者表１２１の一例を図１０に示す。会議対象患者表１２１には各カンファレンスで対象とする患者の情報が会議ＩＤに紐づけられて記録されている。会議対象患者表１２１は、会議ＩＤ、患者ＩＤ、入力テンプレート名および入力テンプレートへ入力されたデータを示すＤＡＴＡ１−６が対応付けられた表である。
【００２２】
会議情報表１２２の一例を図１１（ａ）に示す。会議情報表１２２は、会議ＩＤ、会議体ＩＤ、会議の開催日時、抽出日時および会議参加者が対応付けられた情報を含む。なお、会議情報表１２２は図１１（ａ）の形式に限定されるわけではない。
【００２３】
会議体情報表１２３の一例を図１１（ｂ）に示す。会議体情報表１２３は、会議体ＩＤ、カンファレンス名、定期開催日時および患者の抽出条件が対応付けられた情報を含む。なお、会議体情報表１２３は図１１（ｂ）の形式に限定されるわけではない。
【００２４】
ここで、電子カルテサーバ１、カンファレンス支援サーバ２およびクライアント３（１〜Ｎ）のそれぞれは、例えば、図２に示す情報処理装置１００により実現される。図２に示す情報処理装置１００は、ＵＩデバイス１０１、ＣＰＵ１０２、ＲＡＭ１０３、通信ＩＦ１０４、ＵＩ表示部１０５、プログラム用記憶領域１０６およびデータ用記憶領域１０７を含む。
【００２５】
ＵＩデバイス１０１は、マウス、キーボードおよび指等がタッチした位置を検出するタッチセンサー等の少なくとも一つを含む。なお、ＵＩデバイス１０１は、情報処理装置１００にユーザーの指示を入力するために用いられるものであれば、上記のマウス等のデバイスに限定されるものではない。
【００２６】
ＣＰＵ１０２は、プログラム用記憶領域１０６から読み出したプログラムをＲＡＭ  １０３に展開することで各種の機能を実現する。例えばプログラムをＣＰＵ１０２によって実行することによって装置内の各種制御や計算、ＵＩの表示が可能である。なおＣＰＵを２以上備えてもよいし、ＣＰＵに替えて若しくは併用してＧＰＵを用いることとしてもよい。すなわち、１以上のプロセッサによりプログラムを実行することで各種の機能を実現する。
【００２７】
通信ＩＦ１０４は、院内ネットワーク４に繋がっており、電子カルテサーバ１やカンファレンス支援サーバ２から情報を取得する際に用いる通信インタフェースである。ＵＩ
表示部１０５は装置の状態や処理内容を表示するＬＥＤ（Ｌｉｇｈｔ  Ｅｍｉｔｔｉｎｇ  Ｄｉｏｄｅ）や液晶パネル等である。
【００２８】
プログラム用記憶領域１０６とデータ用記憶領域１０７とは、ハードディスクやフラッシュメモリなどにより実現されるが、特定の記憶媒体に依存するものではない。
【００２９】
ユーザーは、情報表示クライアント３（１〜Ｎ）を用いて電子カルテサーバ１にアクセスすることで、電子カルテ・アプリケーションを表示・操作することが可能である。同様に、カンファレンス支援サーバ２にアクセスすることで、カンファレンス支援アプリケーションを表示・操作することが可能である。
【００３０】
次に、情報処理装置１００のＵＩ表示部１０５に表示されるカンファレンス支援アプリケーションの画面構成の一例を、図３を用いて説明する。本実施例ではアプリケーション画面の表示レイアウトをＨＴＭＬ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）によって記述しているが、表示レイアウト記述言語はＨＴＭＬに限定されるものではない。すなわち、ＸＡＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）等の他の表示レイアウト記述言語でも属性名や要素名を読み替えることで本実施例を実施することが可能である。
【００３１】
図３において、アプリケーションウィンドウ２００の内部には、患者一覧２０１が存在し、さらに患者一覧２０１の内部には、患者行２０２（１，２，…）が存在する。患者一覧２０１の上部には、カンファレンス名２０３、開催日時２０４、抽出日時２０５、会議参加者２０６が存在する。これらの画面表示は、ＣＰＵ１０２が画面のビューに対応したＨＴＭＬ用ＤＯＭ（Ｄｏｃｕｍｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ）を書き換えることで変更することが可能である。
【００３２】
情報処理装置１００のＵＩ表示部１０５には、電子カルテ・アプリケーションが有している各種入力テンプレートを表示することが可能である。本システムを利用する医師は、この入力テンプレートを用いて定型のカルテ記事を手間無く入力することが可能である。本実施例では入力テンプレートの表示レイアウトをＨＴＭＬによって記述しているが、本発明は表示レイアウト記述言語をＨＴＭＬに限定している訳ではない。
【００３３】
図４から図７を用いて、入力テンプレートの一例を説明する。
【００３４】
図４にリハビリ計画書テンプレートの場合の画面表示と対応するＨＴＭＬを示す。図４（ｂ）に示す入力テンプレートＨＴＭＬの１４，１７，１８，２１，２２，２５行目に示すように、入力項目（ｉｎｐｕｔ要素）にはｎａｍｅ属性やｄａｔａ−ｔｙｐｅ属性やｄａｔａ−ｒｅｑｕｉｒｅｄ属性のように各種の項目属性が付いている。
【００３５】
ここで、ｎａｍｅ属性はＤＡＴＡ１〜ＤＡＴＡ６までの値を取り、入力された情報を区別するために使われる。本実施例ではｎａｍｅ属性の値は６種類としたが、これに限定されるものではない。
【００３６】
ｄａｔａ−ｔｙｐｅ属性は当該入力項目にどのような種類の情報が入力されるかを指定するために使われる。ｄａｔａ−ｔｙｐｅ属性には図７のデータタイプ定義表１１２で定義されたｄａｔａＴｙｐｅ名が指定される。ＣＰＵ１０２は、入力テンプレートをＵＩ表示部１０５に表示させようとする際にｄａｔａ−ｔｙｐｅ属性を検出すると図７のデータタイプ定義表１１２を参照して各種入力項目の表示属性を設定する。例えば図４（ｂ）に示す入力テンプレートＨＴＭＬの１４行名のように、ｄａｔａＴｙｐｅ名が”ＤｉｓｅａｓｅＮａｍｅ”ならば、ＣＰＵ１０２は、図７のデータタイプ定義表１１２の最大文字数を参照し、ｉｎｐｕｔ要素のｓｉｚｅ属性やｍａｘｌｅｎｇｔｈ属性の値を１０に設定する。
【００３７】
ｄａｔａ−ｒｅｑｕｉｒｅｄ属性は“ｔｒｕｅ”もしくは“ｆａｌｓｅ”の値を取り、当該入力項目が入力必須項目なのか否かを指定するために使われる。ＣＰＵ１０２は、この入力テンプレートをＵＩ表示部１０５に表示させようとする際にｄａｔａ−ｒｅｑｕｉｒｅｄ属性を検出すると、属性値が“ｔｒｕｅ”ならば入力項目の背景色を変更するなどして入力必須項目であることを明示する。また、ＣＰＵ１０２は、カルテ記事登録時には入力必須項目の情報が全て入力されているかどうかのチェックを行う。
【００３８】
図５に栄養指導テンプレートの場合の画面表示と対応するＨＴＭＬを示す。図５（ｂ）に示す入力テンプレートＨＴＭＬの１４行目のように、明示的にｓｉｚｅ属性やｍａｘｌｅｎｇｔｈ属性が記述されている場合は、図７のデータタイプ定義表の最大文字数よりも明示的記述が優先される。
【００３９】
図６に検体発送テンプレートの場合の画面表示と対応するＨＴＭＬを示す。図６（ｂ）の入力テンプレートＨＴＭＬの１４行目のように、入力項目がｔｅｘｔａｒｅａ要素の場合には、ＣＰＵ１０２は、図７のデータタイプ定義表の１行当り文字数を参照して、要素の横幅（ｃｏｌｓ属性）を設定する。
【００４０】
次に、図１０，１１を参照してカンファレンスの準備過程を説明する。図１１（ｂ）に示す会議体情報表１２３において会議体ＩＤが１０１の「リハビリ計画カンファ」を例として、カンファレンスの準備過程を説明する。まず、会議体情報表１２３の定期開催日時に従って、図１１（ａ）に示す会議情報表１２２に会議ＩＤが１の会議（２０１６／０４／１８  １０：００開催）が作成される。次に、開催日時の３０分前になると会議体情報表１２３の患者抽出条件に従って、ＣＰＵ１０２は、図８のカルテ記事表１１１を参照し条件に合致する患者を抽出する。今回は「１週間以内に”リハビリ計画書”テンプレートで入力したカルテ記事を持つ患者」という抽出条件なので、患者ＩＤが”１２３４５６７８”の患者が抽出される。また、ＣＰＵ１０２は、そのときのカルテ記事（記事ＩＤが１０１）に記録されている入力テンプレート名やＤＡＴＡ１〜ＤＡＴＡ６も抽出し、図１０の会議対象患者表１２１に記録する。同様な処理で患者ＩＤが”２３４５６７８９”の患者（図８には不図示）も抽出されて、会議ＩＤが１の会議の準備が完了する。
【００４１】
図１１（ａ）に示す会議情報表１２２の抽出日時には、上記の患者抽出を行った日時が記録される。上記の例では会議開催３０分前に１回だけ抽出が行われたが、複数回抽出を行うように構成しても構わない。この場合には、最後に抽出した際の抽出日時を記録する。
【００４２】
図１１（ａ）に示す会議情報表１２２の会議参加者には会議当日に参加したスタッフのスタッフＩＤが記録される。スタッフＩＤの収集は、会議室の入口に設けたカードリーダー等を用いてスタッフのＩＤカードを読み取る等の手段で実施可能である。
【００４３】
図１３から図１８までのフローチャートを用いて、ＣＰＵ１０２が、図３の患者一覧２０１部分のＨＴＭＬ用ＤＯＭを作成する過程を説明する。図１２にフローチャートで使われる表記の凡例を示す。これらのＨＴＭＬ用ＤＯＭ作成過程は、図１のカンファレンス支援サーバ２に対応する図２の情報処理装置１００によって実行される。具体的には、プログラム用記憶領域１０６に格納されているプログラムに従って、データ用記憶領域１０７に格納されている各種データをＣＰＵ１０２がＲＡＭ１０３に読出し、各種演算処理を行った結果をＵＩ表示部１０５やデータ用記憶領域１０７に出力することで実行される。
【００４４】
図１３のＳ１００で「患者一覧ＨｔｍｌＤｏｍ作成」が開始される。そしてＳ１０１で「今回の会議ＩＤ」をＣＰＵ１０１が取得する。まず、Ｓ１０２で土台となるｄｉｖ要素が作られ、ＤＯＭツリー「＄患者一覧ＨｔｍｌＤｏｍ」に代入される。Ｓ１０３では、Ｓ１０４で患者をセレクトする際のソート条件として「患者ＩＤ」を取得する。Ｓ１０４では、ＣＰＵ１０２が、図１０の会議対象患者表１２１からＳ１０１で取得した「今回の会議ＩＤ」に基づいて今回の会議の対象患者をセレクトする。そして、セレクトした対象患者をソート条件である「患者ＩＤ」でソートされた状態でリスト「今回の会議対象患者一覧」に代入される。Ｓ１０５では、ＣＰＵ１０２は、「今回の会議対象患者一覧」の中の個々のオブジェクト「会議対象患者行」に対して、Ｓ１０６の処理を繰り返す。Ｓ１０６では、ＣＰＵ１０２は、「会議対象患者行」を引数として図１４で説明する「患者行ＨｔｍｌＤｏｍ作成」の処理を呼出し、その結果を「＄患者一覧ＨｔｍｌＤｏｍ」に追加する。最終的にＳ１０７でＣＰＵ１０２は、「＄患者一覧ＨｔｍｌＤｏｍ」を出力し、図３の患者一覧２０１が書き換わる。
【００４５】
「患者行ＨｔｍｌＤｏｍ作成」の処理を図１４を用いて説明する。図１４のＳ２００で「患者行ＨｔｍｌＤｏｍ作成」が開始される。そして、ＣＰＵ１０２は、図１３の「会議対象患者行」を取得する。まず、Ｓ２０３で土台となるｔａｂｌｅ要素が作られ、ＤＯＭツリー「＄患者行ＨｔｍｌＤｏｍ」に代入される。Ｓ２０４では、患者ＩＤを記したテキストノードが「＄患者行ＨｔｍｌＤｏｍ」に追加される。Ｓ２０４は、図１９（ａ）に示す患者行３００の項目３０１を生成することに対応する。Ｓ２０５では、ＣＰＵ１０２は「会議対象患者行」に無い情報である患者名、性別、生年月日を図９（ａ）に示す患者情報表１２５から患者ＩＤをキーとして取得する。そしてＣＰＵ１０２は取得した情報を「＄患者行ＨｔｍｌＤｏｍ」に追加に追加する。これは、患者行３００の項目３０２〜３０４を生成することに対応する。Ｓ２０６では、ＣＰＵ１０２は「会議対象患者行」を引数として図１５で説明する「患者備考ＨｔｍｌＤｏｍ作成」の処理を呼出し、その結果を「＄患者行ＨｔｍｌＤｏｍ」に追加する。最終的にＳ２０７でＣＰＵ１０２は「＄患者行ＨｔｍｌＤｏｍ」を出力し、図１３のＳ１０７において「＄患者一覧ＨｔｍｌＤｏｍ」に追加される。
【００４６】
ここで、図１９は入力テンプレート名が「リハビリ計画書」の場合に作成される患者行であったが、図２０，２１に入力テンプレート名が「栄養指導」、「検体発送」の場合に作成される患者行の例を示す。
【００４７】
次に、図１９の備考３０５に含まれる備考項目３１１−３１６を作成する手順について図１５を参照して説明する。図１５のＳ３００で「患者備考ＨｔｍｌＤｏｍ作成」が開始される。Ｓ３０１で、ＣＰＵ１０２はオブジェクト「会議対象患者行」を取得する。また、Ｓ３０２において、連想配列「数字マーク」への数字マーク文字列の代入や、定数「備考データ最大数」の設定や定数「１行当りの最大項目数」の設定が行われる。なお、これらの定数値を変更しても本実施形態は実施可能である。「備考データ最大数」および「１行当りの最大項目数」は、例えばユーザーにより予め設定されている。次に、Ｓ３０３では、ＣＰＵ１０２は、「会議対象患者行」の「入力テンプレート名」を用いて、図１の入力テンプレートＨＴＭＬ１２７から入力テンプレートのＨＴＭＬファイルを読み込む。次に、ＣＰＵ１０２は、入力テンプレートのＨＴＭＬファイルをパース（表示可能なデータ構造に変換）してＤＯＭツリー「＄入力テンプレートＨｔｍｌＤｏｍ」に代入する。Ｓ３０４では、ＣＰＵ１０２は、「備考データ数」を入力テンプレート内の「ｎａｍｅ＝ＤＡＴＡ＊」属性（「＊」は整数）の個数から算出する。具体例としては、図４のリハビリ計画書テンプレートや図５の栄養指導テンプレートならば「備考データ数」は６であり、図６の検体発送テンプレートならば「備考データ数」は２である。Ｓ３０５では、土台となるｔａｂｌｅ要素が作られ、ＤＯＭツリー「＄患者備考ＨｔｍｌＤｏｍ」に代入される。Ｓ３０４の処理は、図１９（ａ）の備考３０５の生成に対応する。Ｓ３０６では、ＣＰＵ１０２は、変数ｉを１から「備考データ数」まで増加させながら、Ｓ３０７とＳ３０８の処理を実行する。Ｓ３０７では、ＣＰＵ１０２は、「１行当りの最大項目数」に応じて「＄患者備考ＨｔｍｌＤｏｍ」に改行を入れている。Ｓ３０８では、ＣＰＵ１０２は、数字マークを「＄患者備考ＨｔｍｌＤｏｍ」に追加したのち、「会議対象患者行」と備考項目インデックス「ｉ」を引数として図１６で説明する「備考項目ＨｔｍｌＤｏｍ作成」の処理を呼出し、その結果を「＄患者備考ＨｔｍｌＤｏｍ」に追加する。最終的にＳ３０９でＣＰＵ１０２は、「＄患者備考ＨｔｍｌＤｏｍ」を出力し、図１４の「＄患者行ＨｔｍｌＤｏｍ」に追加する。
【００４８】
図１６のＳ４００で「備考項目ＨｔｍｌＤｏｍ作成」の処理が開始される。ＣＰＵ１０２は、図１５のＳ３０８で示したように入力としてオブジェクト「会議対象患者行」と備考項目インデックス「ｉ」を取得する。Ｓ４０２では、ＤＯＭツリー「＄ｅｌｅｍ」に入力テンプレート内の当該入力項目要素が代入され、文字列「備考項目文字列」に「会議対象患者行」の当該項目データ（ＤＡＴＡ１−６）が代入される。ＣＰＵ１０２は、Ｓ４００において、入力テンプレートの各入力項目に入力された情報を取得する。すなわち、ＣＰＵ１０２は入力項目を有する入力テンプレートを介して電子カルテに入力された情報を取得する情報取得手段の一例に相当する。
【００４９】
Ｓ４０３では、入力テンプレート内の入力項目要素がｔｅｘｔａｒｅａ要素なのか、その他の要素なのかに応じてＳ４０４とＳ４０５に処理を分岐させる。Ｓ４０４やＳ４０５の内部では、図１７や図１８で説明するようにＣＰＵ１０２は、ＤＯＭツリー「＄備考項目ＨｔｍｌＤｏｍ」を作成する。そして、ＣＰＵ１０２は最終的にＳ４０６でＤＯＭツリー「＄備考項目ＨｔｍｌＤｏｍ」を出力し、図１５の「＄患者備考ＨｔｍｌＤｏｍ」に追加する。
【００５０】
図１７のＳ５００で「ＴＥＸＴＡＲＥＡの場合の備考項目ＨｔｍｌＤｏｍ作成」が開始される。Ｓ５０１では、ＣＰＵ１０２は、入力テンプレート内の入力項目要素から最大文字数を表すｍａｘｌｅｎｇｔｈ属性の取得を試みる。しかし、ｍａｘｌｅｎｇｔｈ属性が入力テンプレート内に定義されていないならばｄａｔａＴｙｐｅ名に応じたデフォルトの「最大文字数」を図７に示すデータタイプ定義表１１２から取得し、ｍａｘｌｅｎｇｔｈ値として用いる。
【００５１】
Ｓ５０２では、ＣＰＵ１０２は、入力テンプレート内の入力項目要素からカラム数を表すｃｏｌｓ属性の取得を試みる。しかし、ｃｏｌｓ属性が定義されていないならばｄａｔａＴｙｐｅ名に応じたデフォルトの「１行当り文字数」を図７に示すデータタイプ定義表１１２から取得し、ｃｏｌｓ値として用いる。すなわち、ＣＰＵ１０２は、「最大文字数」または「１行当り文字数」という属性を取得する属性取得手段の一例に相当する。
【００５２】
Ｓ５０３では、ＣＰＵ１０２は、入力テンプレート内の入力項目要素から行数を表すｒｏｗｓ属性の取得を試みる。しかし、ｒｏｗｓ属性が定義されていないならば、ｍａｘｌｅｎｇｔｈ値とｃｏｌｓ値から算出した値をｒｏｗｓ値として用いる。例えばＣＰＵ１０２は、ｍａｘｌｅｎｇｔｈ値をｃｏｌｓ値で除した値をｒｏｗｓ値とする。Ｓ５０４では、ＣＰＵ１０２は、「備考項目文字列」を表示するためのｔｅｘｔａｒｅａ要素をＤＯＭツリー「＄備考項目ＨｔｍｌＤｏｍ」に代入する。Ｓ５０５では、ＣＰＵ１０２は、ｃｏｌｓ値に応じて備考項目の幅を設定する。しかし、ｃｏｌｓ値が未定義ならば患者行の幅に合うように自動調整した幅を設定する。Ｓ５０６では、ＣＰＵ１０２は、ｒｏｗｓ値に応じて備考項目の高さを設定する。しかし、ＣＰＵ１０２は、ｒｏｗｓ値が未定義ならば患者行の高さに合うように自動調整した高さを設定する。このようにＳ５０５，５０６でＣＰＵ１０２は備考項目の表示領域の大きさを決定する。すなわち、ＣＰＵ１０２は、情報が表示される表示領域の大きさを決定する決定手段の一例に相当する。
【００５３】
Ｓ５０７では、ＣＰＵ１０２は、図７に示すデータタイプ定義表１１２から入力テンプレート内の入力項目要素が末尾省略可能に設定されているか否かを取得し、末尾省略可能と設定されている場合には、備考項目にスクロールバーを出す設定を行う。具体的には、図２１（ａ）のスクロールバー３１８のように表示される。末尾省略可能に設定されていない場合には、ＣＰＵ１０２は、備考項目にスクロールバーを表示しないように設定する。例えば、ＣＰＵ１０２は、備考項目からスクロールバーを消す設定を行う。
【００５４】
図１８のＳ６００で「その他の場合の備考項目ＨｔｍｌＤｏｍ作成」の処理が開始される。Ｓ６０１では、ＣＰＵ１０２は、入力テンプレート内の入力項目要素から最大文字数を表すｍａｘｌｅｎｇｔｈ属性の取得を試みる。しかし、ｍａｘｌｅｎｇｔｈ属性が定義されていないならば、ＣＰＵ１０２は、ｄａｔａＴｙｐｅ名に応じたデフォルトの最大文字数を図７に示すデータタイプ定義表１１２から取得し、ｍａｘｌｅｎｇｔｈ値として用いる。Ｓ６０２では、ＣＰＵ１０２は、入力テンプレート内の入力項目要素のカラム数を表すｓｉｚｅ属性の取得を試みる。しかし、ｓｉｚｅ属性が定義されていないならば、ＣＰＵ１０２は、ｍａｘｌｅｎｇｔｈ値をｓｉｚｅ値として用いる。Ｓ６０３では、ＣＰＵ１０２は、「備考項目文字列」を表示するためのｉｎｐｕｔ要素をＤＯＭツリー「＄備考項目ＨｔｍｌＤｏｍ」に代入する。Ｓ６０４では、ＣＰＵ１０２は、ｓｉｚｅ値に応じて備考項目の幅を設定する。しかし、ｓｉｚｅ値が未定義ならば、ＣＰＵ１０２は、患者行の幅に合うように自動調整した幅を設定する。Ｓ６０５では、入力テンプレート内の入力項目要素が末尾省略可能に設定されている場合には、ＣＰＵ１０２は、備考項目に末尾省略記号「…」を出す設定を行う。具体的には、図２０（ａ）の末尾省略記号３１７のように表示される。
【００５５】
以上の処理により備考３０５に含まれる備考項目３１１−３１６が生成され、結果として図１９（ａ）に示すような患者行が生成される。図１９（ｂ）は上記の処理により生成された患者行に対応するＨＴＭＬである。また、上記の処理により図２０（ａ）、図２１（ａ）に示す患者行も作成される。ここで、図２０（ｂ）、図２１（ｂ）に示すＨＴＭＬは図２０（ａ）、図２１（ａ）に示す患者行に対応するＨＴＭＬである。図１９（ａ）、図２０（ａ）、図２１（ａ）を比較するとわかるように、入力テンプレートの種類に応じて、備考が表示される複数の表示領域の配置が決定されている。  このように本実施形態では、カルテ入力時に用いる入力テンプレート内の入力項目要素の各種属性に応じて、カンファレンス時に表示する患者一覧の表示レイアウトを変更している。具体的には患者行の備考項目数や備考項目レイアウトを変更している。これによって、重要な情報が書かれた文字列が途中で欠けたり、文字が見づらくなったりすることを防ぐことが可能である。具体的には、図７に示すデータタイプ定義表１１２において入力される情報の種類に応じて末尾省略不可と設定されているため重要な情報が書かれた文字列が途中で欠けることを防ぐことができる。
【００５６】
また、入力テンプレートが増えたとしても、患者一覧の表示レイアウトは自動的に生成されるためユーザーの手間が増えることはない。
【００５７】
＜実施形態２＞
別の実施形態としては、患者一覧のソート条件を入力テンプレートに応じて変更するために、図１３のＳ１０３を図２２（ａ）のＳ１０３＿０〜Ｓ１０３＿４に置き変えた形態がある。このように置き変えることで、入力テンプレート内の入力項目の「ｄａｔａ−ｒｅｑｕｉｒｅｄ」属性に応じてソート条件を変更することが可能である。
【００５８】
具体的には、図２２（ｂ）のように入力テンプレートごとに異なるソート条件になる。
【００５９】
図２２（ａ）のＳ１０３＿１では、ＣＰＵ１０２は、今回の会議で表示する全ての患者行の入力テンプレート名をセレクトし、重複を省いたものを「入力テンプレート名配列」に代入する。次にＳ１０３＿２では、ＣＰＵ１０２は、使われている入力テンプレートが１つだけであるかどうかを判定している。１つだけではなかった場合は「いいえ」に進み、Ｓ１０３＿０で、ＣＰＵ１０２は、実施形態１と同じく「ソート条件」に「患者ＩＤ」を代入する。一方、使われた入力テンプレートが１つだけだった場合は、ソート条件を入力テンプレートに応じて変更できるため「はい」に進む。Ｓ１０３＿３では、ＣＰＵ１０２は、「入力テンプレート名配列［０］」を用いて、図１の入力テンプレートＨＴＭＬ１２７から入力テンプレートのＨＴＭＬファイルを読み込む。次に、ＣＰＵ１０２は、入力テンプレートのＨＴＭＬファイルをパースしてＤＯＭツリー「＄入力テンプレートＨｔｍｌＤｏｍ」に代入する。Ｓ１０３＿４では、ＣＰＵ１０２は、まず入力テンプレート内から「ｄａｔａ−ｒｅｑｕｉｒｅｄ＝ｔｒｕｅ」である入力項目要素をセレクトし、その要素のｎａｍｅ属性値を「項目名配列」に代入する。次に、ＣＰＵ１０２は、「項目名配列」内の重複項目を省き、最終ソート条件として「患者ＩＤ」を追加する。患者ＩＤは全て異なるため、ソート順番が不定にならないようにする目的でソート条件の最後に追加している。
【００６０】
一般に医療カンファレンスにおいては、入力が必須となっている項目で患者をソートして順番に会議を進めていくことが多いため、自動的に必須項目でソートすることで効率的に会議を進めることが可能である。
【００６１】
＜実施形態３＞
さらに別の実施形態としては、図１６のＳ４０２とＳ４０３の間に個人情報保護のための処理を入れて、図２３のように変更した形態がある。新しく追加された処理Ｓ７０３では、ＣＰＵ１０２は、データタイプ定義表１１２のｄａｔａＴｙｐｅ名および個人情報のカラムを参照することで当該データ項目が個人情報に該当するのかどうかを判定する。さらに、個人情報であった場合は、会議参加者に学生が参加しているかどうかを判定する。そして、ＣＰＵ１０２は、学生が参加している場合には備考項目文字列を「＊」でマスクする。これにより個人情報が表示されることを防ぐことが可能である。なお、マスクする方法として使用する文字は上記の例に限定されるものではない。また、情報を秘匿化できる方法であれば他の方法を用いることとしてもよい。
【００６２】
例えば、図１１（ａ）に示す会議情報表１２２の会議ＩＤが１１の会議参加者には、スタッフＩＤが”９８７６”の学生が含まれている。この会議は会議体ＩＤが１０１のリハビリ計画カンファなので、リハビリ計画テンプレートを使用した場合に生成される患者行の例を図２４に示す。図７のデータタイプ定義表１１２において、ｄａｔａＴｙｐｅ名が”ＰｅｒｓｏｎＮａｍｅ”のデータ項目は個人情報と定義されているため、図２４（ａ）画面表示において、患者名や協力親族名は「＊」でマスクされている。
【００６３】
この実施形態では学生が参加しているかどうかで判断したが、これ以外の職業で判断するように構成しても実施可能である。また、「＊」でマスクする以外にも、備考項目文字列を空にすることで個人情報が表示されることを防ぐことも可能である。
【００６４】
＜実施形態４＞
別の実施形態としては、図２５に示すように電子カルテサーバにカンファレンス支援機能を載せて、１つのサーバに統合する形態がある。この場合、データタイプ定義表５１５や患者基本情報表５１６やスタッフ基本情報表５１７や入力テンプレートＨＴＭＬ  ５１８を複製して別に保持する必要がなくなる。
【００６５】
＜その他の実施形態＞
以上、実施形態例を詳述したが、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体（記憶媒体）等としての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インタフェース機器、撮像装置、Ｗｅｂアプリケーション等）から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【００６６】
また、本発明の目的は、以下のようにすることによって達成されることはいうまでもない。即ち、前述した実施形態の機能を実現するソフトウェアのプログラムコード（コンピュータプログラム）を記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給する。係る記憶媒体は言うまでもなく、コンピュータ読み取り可能な記憶媒体である。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行する。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。
【００６７】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図１】
2019032760.tif 000003
【図２】
2019032760.tif 000004
【図３】
2019032760.tif 000005
【図４】
2019032760.tif 000006
【図５】
2019032760.tif 000007
【図６】
2019032760.tif 000008
【図７】
2019032760.tif 000009
【図８】
2019032760.tif 000010
【図９】
2019032760.tif 000011
【図１０】
2019032760.tif 000012
【図１１】
2019032760.tif 000013
【図１２】
2019032760.tif 000014
【図１３】
2019032760.tif 000015
【図１４】
2019032760.tif 000016
【図１５】
2019032760.tif 000017
【図１６】
2019032760.tif 000018
【図１７】
2019032760.tif 000019
【図１８】
2019032760.tif 000020
【図１９】
2019032760.tif 000021
【図２０】
2019032760.tif 000022
【図２１】
2019032760.tif 000023
【図２２】
2019032760.tif 000024
【図２３】
2019032760.tif 000025
【図２４】
2019032760.tif 000026
【図２５】
2019032760.tif 000027