JP5525635B1 - 情報処理装置およびその方法、ならびにプログラム - Google Patents

Abstract

【課題】ユーザにとって有用なタグを選出する。
【解決手段】本発明の実施形態としての情報処理装置は、つぶやきメッセージの複数のタグの中から、ユーザの端末画面に前記つぶやきメッセージへのリンクとともに表示するタグを選出する情報処理装置であって、コンテキスト取得部と、タグ利得算出部と、タグ選出部とを備える。前記コンテキスト取得部は、前記ユーザの端末から、前記端末の画面のコンテキスト情報を取得する。 前記タグ利得算出部は、前記コンテキスト情報に基づき、前記複数のタグのそれぞれについて、タグ利得を算出する。前記タグ選出部は、前記タグ利得に基づき、前記複数のタグから少なくとも１つのタグを選出する。
【選択図】図１

Description

この発明の実施形態は、情報処理装置およびその方法、ならびにプログラムに関する。

複数職種の複数職員が分散・非同期に業務を実施する医療現場、とくに地域医療などの現場においては、職員間で、患者についての観察結果や気付き、連絡事項などの情報を共有する必要がある。

職員は一般的に、電子カルテシステムへの入力や、電話やＦＡＸといった手段を用いて情報共有を行っているが、音声メッセージを用いた情報共有システムがある（以降、音声つぶやきシステムと呼ぶ）。

音声つぶやきシステムでは、職員がスマートフォンを用いて音声メッセージを登録すると、サーバで音声認識し、音声に含まれるキーワードを抽出する。同時に、メッセージの対象患者IDや発話者の職員ID、発話時刻、発話場所、推定業務などの情報、メッセージの重要度や種類（以降、これらをタグと呼ぶ）をメッセージに自動添付もしくはユーザが添付した上で、必要な範囲の職員に配信する。このような音声メッセージとタグ（付随情報）からなる情報を、以降、音声つぶやきと呼ぶ。

職員は、受信した音声つぶやき、あるいはサーバに蓄積された音声つぶやきを、携帯端末２００やパソコンで閲覧あるいは視聴する。その際、携帯端末２００やパソコンの画面上に一覧表示された各つぶやきへのリンクをクリックしてつぶやきの音声を聞いたり、音声認識結果のテキストを読んだりしなくても、タグを見るだけで、つぶやき内容の概要を把握することができる。これにより、閲覧者は、複数の未読のつぶやきのうち、どれかを今読む（もしくは聞く）か、どれを後で読む（もしくは聞く）かを選択することができる。

特許第3827704号 特許第3817378号

各つぶやきについて、一般には、さまざまな種類のタグが複数個付随する。例えば、患者観察内容に関する看護師によるつぶやきとして、「顔色はあまりよくないが、意識ははっきりしており、体温、血圧、ＳＰＯ２は異常なし」といったつぶやきの場合、観察項目についてのタグとして“顔色”、“意識”、“体温”、“血圧”、“ＳＰＯ２”があり、状態についてのキーワードタグとして“あまりよくない”、“はっきり”、“異常なし”、といったキーワードタグがある。この他、発話者の看護師ＩＤ、話題の対象である患者ＩＤ、発話時刻、発話場所、といったタグがある。

しかしスマートフォンやＰＣのブラウザといった限られた大きさの画面上で、タグだけで、つぶやきの大意を伝えるためには、うまく表示するタグを絞り込み、表示順序を制御しなければならない。例えばスマートフォンの画面では３個程度のタグしか表示できない、あるいは音声再生時には、２個以上のタグを再生しても聞き手が覚えられず時間も消費してしまう、などの制約がある。またＷｅｂ上でタイムラインで多数のつぶやきがならぶ場合も、つぶやきごとに多数のタグが表示されていると、かえって流れがつかみにくい。

本発明の実施形態は、つぶやきメッセージへのリンクとともに表示するタグを選出する情報処理装置およびその方法、ならびにプログラムを提供する。

本発明の実施形態としての情報処理装置は、つぶやきメッセージの複数のタグの中から、ユーザの端末画面に前記つぶやきメッセージへのリンクとともに表示するタグを選出する情報処理装置であって、コンテキスト取得部と、タグ利得算出部と、タグ選出部とを備える。

前記コンテキスト取得部は、前記ユーザの端末から、前記端末の画面のコンテキスト情報を取得する。

前記タグ利得算出部は、前記コンテキスト情報に基づき、前記複数のタグのそれぞれについて、タグ利得を算出する。

前記タグ選出部は、前記タグ利得に基づき、前記複数のタグから少なくとも１つのタグを選出する。

本発明の実施例に係る表示タグ選出装置を備えたつぶやき閲覧システムのブロック図。 閲覧コンテキスト取得部の詳細ブロック図。 タグ利得算出部の詳細ブロック図。 表示タグ選出装置がタグを選出する処理のフローチャート。 タグ定義情報の例を示す図。 キーワード（タグ）の出現頻度表を示す図。 キーワードの組の出現頻度表を示す図。 診断・処方と、タグとを対応づけた表を示す図。 つぶやきメッセージの新着案内方法を職員の位置およびタグ利得に応じた分類した表を示す図。 つぶやき一覧の例を示す図。 つぶやき一覧の別の例を示す図。

以下、図面を参照しながら、本実施例を説明する。

［１］全体構成
図１に、本発明の実施例に係る表示タグ選出装置１００を備えたつぶやき閲覧システムのブロック図を示す。

本システムは、表示タグ選出装置１００と、ユーザの端末２００と、つぶやきデータ保持部３００と、病院情報システム４００を備える。つぶやきデータ保持部３００はサーバに設けられ、表示タグ選出装置１００からアクセス可能である。表示タグ選出装置１００は、サーバに設けられてもよいし、端末２００内に設けることも可能である。サーバに設けられる場合、表示タグ選出装置１００は、つぶやきデータ保持部３００と異なるサーバに設けられても良いし、同じサーバに設けられてもよい。表示タグ選出装置１００は、ネットワークを介して、病院情報システム４００と接続可能である。

つぶやきデータ保持部３００は、つぶやきデータを保持する。つぶやきデータは、つぶやきＩＤ、つぶやきの発話者職員ＩＤ、発話時刻、発話場所、つぶやき音声データのＵＲＬ（ファイルパス）、つぶやきの音声認識結果のテキスト、音声認識結果に含まれるキーワードを含む。つぶやきＩＤ以外は、つぶやきのタグである。つぶやき音声データは、つぶやきデータ保持部３００内に保持されていても良いし、別のサーバに保持されていてもよい。

表示タグ選出装置１００は、閲覧コンテキスト取得部１０１、タグ利得算出部１０２、表示タグ選出部１０３、タグ定義情報保持部１０４を備える。表示タグ選出装置１００は、つぶやきデータ保持部３００からつぶやきデータを抽出して、端末２００に閲覧可能に提供する。その際、端末の画面につぶやき音声データへのリンクとともに表示するタグを選出する。なお、端末へは、選出されたタグのみならず、選出されなかったタグも送信されてよい。端末では、つぶやき音声データへのリンクとともに選出されたタグを表示する。選出されたタグは、大きいサイズや太字など、強調して表示されてもよい。選出されたなかったタグは、ユーザの別途の操作により別の画面で確認できるようにしてもよい。

閲覧コンテキスト取得部１０１は、つぶやきを閲覧するユーザの端末２００から、コンテキスト情報を取得する。コンテキスト情報は、［１．１］に後述するように、閲覧ユーザの属性や、つぶやきを一覧表示する画面の属性、端末機種の種類（スマートフォン、ＰＣなど）、その他各種の情報を含んでいる。

タグ定義情報保持部１０４は、つぶやきに含まれる可能性があるタグ（キーワード、場所など）の定義情報を保持する。例えば“顔色”といったキーワードタグの場合、定義情報は、ＩＤ、タグの種類（この場合“キーワード”）、タグの詳細種類（“患者観察項目”）、タグの値（“顔色”という表記（表層））の組を含む。タグの種類と、タグの詳細種類は、階層関係を有し、前者が上位層、後者が中位層に相当する。さらに下位層が存在してもよい。詳細は、後述する。

タグ利得算出部１０２は、端末２００に一覧表示するつぶやきデータのそれぞれについて、付随する各タグの利得を算出する。ここで利得とは、閲覧するユーザにとって、今、閲覧している画面において、あるつぶやきのタグを見る場合の当該ユーザにとっての有用性を数値化したものである。利得は、実数、整数、真偽（0、1）など、いずれの形式も可能である。利得は、ベクトルの形式を有してもよい。

表示タグ選出部１０３は、上記のとおり算出された利得に基づいて、つぶやきごとに、表示するタグを選出する。選出の方法は、任意の方法が可能である。たとえば、設定した閾値以上の利得を有するタグを表示する、利得が“真”（1）であるタグを表示する、といった方法がある。ベクトルの場合は、最も高い値と、閾値を比較することで表示の有無を決定してもよい。端末の画面におけるタグの表示箇所は、その種類（キーワード、位置など）に応じたあらかじめ定められた箇所に表示されてもよい。複数のキーワード（タグ）が選出されているときは、利得の大きい順に並べて表示してもよいし、別途定められた優先順位で表示されてもよい。

病院情報システム４００は、職員情報保持部４０１と、診療予定保持部（業務予定保持部）４０２と、患者情報保持部４０３を備える。職員情報保持部４０１には、職員ＩＤ、職種、所属医療機関等の組を含む職員情報が保持されている。診療予定保持部４０２には、ユーザ（医師、看護師、薬剤師、介護士など）ごとの診療予定に関する情報が格納されている。患者情報保持部４０３には、患者ごとの詳細情報が格納されている。たとえば、病名やアセスメント結果（認知状態、転倒リスクなど）の情報等が格納されている。

なお、本実施例では医療現場を想定するが、本発明の適用先は医療現場に限定されず、幅広く適用可能である。医療現場以外で複数職種の複数職員が分散・非同期に業務を実施する現場に適用可能なのはもちろんのこと、各ユーザのつぶやきメッセージを共有して閲覧可能なプラットフォームであれば適用可能である。

ユーザの端末２００は、つぶやき閲覧画面２０３と、位置センサー２０１と、加速度センサー２０２を備える。位置センサー２０１は、ユーザの位置を特定するために必要な情報を計測するセンサーであり、たとえば、ＧＰＳがある。加速度センサー２０２は、ユーザの行動（歩行中、車で移動中、静止など）を推定するための加速度を計測する。つぶやき閲覧画面２０３は、つぶやき一覧を表示する。

図１０につぶやき一覧の例を示す。この例では全患者についての全発話者によるつぶやき一覧が示されている。一番上のつぶやきに、発話者Ｔ１、発話日時Ｔ２、発話位置Ｔ３、キーワード（タグの値）Ｔ４、音声認識結果テキストＴ５、生音声へのリンクボタンＴ６が含まれている。他のつぶやきにも同様の項目が含まれている。評価のための「イイネ」ボタン等も設けられている。キーワードＴ４は本実施形態によって複数のタグの中から選出されたタグである。選出されたタグは、大きく強調表示されている。選出されたタグを見ることで、生音声を聴いたり、音声認識結果テキストを読んだりしなくても、つぶやきの概要あるいは要点を予測できる。リンクボタンＴ６をクリックすることで、生音声が再生される。生音声はクリック時に外部のサーバからダウンロードされてもよいし、端末内部につぶやきメッセージをダウンロードした時に同時にダウンロードして格納してもよい。一番下のつぶやきには、対象患者Ｔ７も含まれている。画面の右上に、ユーザ名Ｔ１０が記載されている。画面の左下のフィルターで、表示するつぶやきの期間を指定できる。なお、音声認識結果テキストＴ５には誤認識の結果も含まれる可能性があるため、正確なつぶやき内容を知るためには生音声を聞くことが必要となる。

図１１につぶやき一覧の別の例を示す。この例では、特定の患者についての全発話者によるつぶやき一覧が示されている。メニューの中で、話題の対象が患者であることがＴ２１により示され、患者名がＴ２２により示される。Ｔ２２により示される患者名（個人名）は、この画面の主題の１つであるといえる。

なお、本実施例で扱うつぶやきデータは、音声データのみならず、音声と映像のデータの場合も可能である。また、音声または映像を含まない、テキストまたは画像またはこれらの両方からなるデータ（後述するセンサーデータもこの場合に該当する）の場合も可能である。

［１．１］コンテキストの取得
閲覧コンテキスト取得部１０１は、端末２００から閲覧コンテキスト情報として、画面コンテキスト、対象患者コンテキスト、閲覧状態コンテキストを取得する。このため、閲覧コンテキスト取得部１０１は、図２に示すように、画面コンテキストを取得する画面コンテキスト取得部１１２、対象患者コンテキストを取得する対象患者コンテキスト取得部１１１、閲覧状態コンテキストを取得する閲覧状態コンテキスト取得部１１３を備える。

・画面コンテキスト
画面コンテキストは、端末２００のつぶやき閲覧画面２０３から得られるもので、どんなユーザが、どんな端末で、どんな表示タイプでつぶやき一覧を閲覧するか、を示すものである。つぶやき閲覧画面２０３がＷｅｂブラウザの場合、画面コンテキストは、つぶやき一覧表示を要求するURLや、プロトコル内のPOSTやGETの属性などから得ることができる。

ユーザに関するコンテキストしては、閲覧ユーザのID、職種がある。職種は、ユーザIDを用いて、医療情報システム４００に問い合わせることで、得ることができる。医療情報システムは、ユーザID（職員ID）に対応する職種を職員情報から特定して、閲覧コンテキスト取得部１０１に返す。

端末に関するコンテキストとしては、端末の機種（ＰＣ、スマートフォン、フィーチャーフォンなど）がある。

表示タイプとしては、過去の特定の期間（今日、今週、今月、今年、指定した月、期間指定なし、など）の全てのつぶやきを時間順に表示するタイムラインや、特定の患者に限定したタイムライン、自分の担当患者に限定したタイムライン、特定の発話者によるつぶやきのタイムライン、指定した月におけるこれらのつぶやきのカレンダー表示、指定した日あるいは閲覧当日のこれらのつぶやきの一覧表示を識別する情報がある。

また、つぶやきは、キーワードタグによって、キーワードに関連する患者のアセスメント内容（転倒、認知状態など）や診断内容に応じて分類されている。このため、表示タイプとしては、アセスメント内容ごとや診断内容ごとの分類表形式での一覧表示を識別する情報がある。

また、つぶやき登録時に、つぶやきの内容によってつぶやきの種類を指定している場合もある。種類としては例えば、処方に関するつぶやきや、申し送りに関するつぶやき、一般連絡に関するつぶやきなどがある。このため、表示タイプとして、つぶやきの種類による分類表形式での一覧表示を識別する情報がある。

・対象患者コンテキスト
各つぶやきには、患者ＩＤが付随している場合がある。患者ＩＤは、発話者によりつぶやき登録時に指定される場合や、つぶやきに含まれる患者名キーワードから推定された場合がある。この患者ＩＤを用いて、対象患者コンテキストとして、各つぶやきの患者ＩＤタグごとに、病院情報システム４００から当該患者についての病名やアセスメント結果（認知状態、転倒リスクなど）を得ることができる。

また、一覧表示対象の全つぶやき、あるいは閲覧日時から一定日時前までの全つぶやきにおける、患者ＩＤごとの各キーワードの頻度を一覧にしたキーワード頻度表（別途算出しておく）を、対象患者コンテキストとして得ることができる。

さらに患者ごとのキーワード頻度表における頻度の高いキーワードを用いて別途推定された、当該患者の病名やアセスメント状態の（推定病名、推定アセスメント結果）を、対象患者コンテキストとして得ることができる。

・閲覧状態コンテキスト
閲覧状態コンテキストは、閲覧者（端末の保持者）が現在どのような状態にあるかを示す。スマートフォンに搭載されている位置センサー２０１（ＧＰＳ，ＷｉＦｉやＢｌｕｅｔｏｏｔｈ信号のＳＳＩＤと信号受信強度（ＲＳＳＩ）計測センサー）の計測結果から、位置推定エンジン５０１が、ユーザの位置を別途推定する。位置推定エンジン５０１は、ユーザの端末２００（スマートフォンなど）、あるいはサーバ上に搭載されている。

またスマートフォンに搭載されている加速度センサー２０２の計測結果から、行動推定エンジン５０２が、ユーザの行動（歩行中、車で移動中、静止など）を推定する。行動推定エンジン５０２は、ユーザの端末２００、あるいはサーバ上に搭載されている。また、業務推定エンジン５０３が、上記の位置、加速度、行動推定結果、さらに、医療情報システム４００の診療予定保持部４０２に保持された診療予定などから、ユーザの現在の業務を推定する。

閲覧状態コンテキスト取得部１１３は、これらの推定エンジン５０１〜５０３に問い合わせることにより、もしくはこれらの推定エンジン５０１〜５０３による定期的な出力結果から、閲覧者コンテキストとして、閲覧者の現在の推定位置、推定行動、推定業務を得ることができる。

［１．２］タグの利得算出
タグ利得算出部１０２は、上記の閲覧コンテキスト情報（画面コンテキスト、対象患者コンテキスト、閲覧状態コンテキスト）を用いて、表示対象のつぶやきのタグの利得を算出する。

タグの利得の構成要素としては、関係度、表示度、話題合致度、閲覧状態適合度がある。このため、タグ利得算出部１０２は、図３に示すように、関係度を算出する関係度算出部１２２と、表示度を算出する表示度算出部１２３、話題合致度を算出する話題合致度算出部１２１、閲覧状態適合度を算出する閲覧状態適合度１２４を備える。

タグ利得算出部１０２は、これら関係度、表示度、話題合致度、閲覧状態適合度の少なくとも１つに基づいて、タグ利得を算出する。タグ利得の計算としては、これらの値の重み付け合計等の演算により１つの数値を算出してもよいし、関係度、表示度、話題合致度、閲覧状態適合度のうちの少なくとも１つ以上の項目の値を要素とするベクトルとしてもよい。あるいは、話題合致度または閲覧状態適合度を、関係度または表示度の値を調整する係数として用いる構成も可能である。

・関係度
タグが閲覧者にとってどの程度、関連があるかを示す。たとえば、閲覧者の職種とタグ間で利得をあらかじめ定義しておき、この利得を関係度として取得できる。この詳細は、［２．１］の実施例で後述する。

・表示度
タグが閲覧端末２００の表示画面において、どの程度ユーザにとって表示する情報量が高いかを示す。たとえば、端末に表示されている画面の主題・画面の種類や、閲覧画面の端末機種などから算出される。詳細は、［２．２］の実施例で後述する。

・話題合致度
タグが、つぶやき対象患者の話題にどの程度関連するかを示す。つぶやき対象患者の話題は、たとえば、つぶやきの対象患者の病名やアセスメント結果、キーワードの頻度分布、およびキーワードの頻度分布から推定される推定病名や推定アセスメント結果、の少なくともいずれかを含む。詳細は、［４］の実施例で後述する。

・閲覧状態適合度
ある職員により登録されたつぶやきが他職員の端末に配信される場合、閲覧者としての他職員の現在の業務遂行状態によっては、つぶやきの閲覧ができない、あるいは新着時につぶやきの内容を音声で再生されては困る、といった場合がある。閲覧者が、新規に配信されたつぶやきを閲覧しやすい状態にあるかどうかを示す数値もしくはベクトルを閲覧状態適合度と呼ぶ。閲覧状態適合度は、上述の閲覧者の現在の推定位置、推定行動、推定業務から算出される。詳細は、［７．１］の実施例で後述する。

［２］第１の実施例（基本機能）
図４に、表示タグ選出装置１００が、一覧対象の各つぶやきについて、閲覧者と画面に応じて、表示するタグを選出する処理のフローチャートを示す。

ステップＳ１０１では、表示タグ選出装置１００が、ユーザの端末２００のつぶやき一覧を表示するアプリケーションから、上述のコンテキスト（画面コンテキスト、対象患者コンテキスト、閲覧状態コンテキスト）を取得する。

ステップＳ１０２では、タグ利得算出部１０２が、表示対象の全つぶやきデータについて、付随する各タグの利得を算出する。算出方法の例は後述する。

ステップＳ１０３では、タグの利得に応じて、各つぶやきについて閲覧画面に表示するタグを選出する。選出方法としては、以下の例がある。

・閾値以上の利得を有するタグを表示対象として選出する。

・利得が“真”（数値としては1）を表示、“偽”（数値としては0）を非表示とする。

・利得が高い上位の所定個数のタグを表示対象として選出する。

利得がベクトルの形式を有するときは、ベクトルの要素のうち最大値を用いて同様の処理を行うことができる。最大値の代わりに、平均値、中央値等を用いても良い。

以下、タグの利得の構成要素の算出方法の例を示す。

［２．１］関係度の算出
タグ利得算出部１０２は、つぶやきの各タグについて、タグ定義情報に基づき、閲覧者の属性に応じたデフォルトの利得としての関係度を取得する。

タグ定義情報の例を図 5に示す。各種タグが定義されている。各種タグは、ＩＤにより識別され、複数層の上位概念（図 5では上位層と中位層の2階層）がある。キーワードや位置といった上位層を有する各種タグについて、閲覧者の職種に応じて、整数値により、関係度が定義されている。

キーワードや位置（発話時の）といったタグと異なり、発話者や発話年月日、発話時刻といったタグは、つぶやきに内容によらず、全てのつぶやきに常に付随するものである。このようなタグは、端末アプリケーション側で自動添付され、システムタグと呼ぶ。システムタグの関係度は、タグの値によらず（図 5では“ANY”としている）一定の値を定義している。

図 5ではさまざまな種類のタグを一つの定義情報の中で定義しているが、タグの種類ごとに（たとえば上位概念ごとに）、別のマスタ（定義情報）で定義してもよい。

［２．２］表示度の算出
画面の属性に応じたデフォルトの利得としての表示度の算出方法を示す。

・画面の主題に応じたタグの利得（表示度）の算出
表示タイプで特定される画面の主題と重なる値のタグは、つぶやきの一覧表示において、閲覧者に与える情報量は小さい。

例えば、画面の主題が“患者Ａについてのつぶやき”である場合、上位層が“キーワード”で、中位層が“患者名”のタグであって、値が“Ａ”のタグは、つぶやきの一覧画面において、個別のつぶやきに、患者名“Ａ”というタグが表示される必要はない。これは、閲覧者は画面の主題が“患者Ａであることが分かっているからである。このように画面の主題と重なるタグについては、表示度を小さくする、あるいは“偽”（0）にする。具体的な表示度の決定方法として、たとえば、あらかじめ表示度のデフォルト値を与えておき、主題と重ならないタグについては、デフォルト値のままにし、重なるタグについては、一定係数を乗じるか、一定値を減算するなどにより、表示度を小さくする。

画面の主題が“特定の職員Ｂによるつぶやき”である場合も同様に、上位層が“キーワード”で、中位層が“職員名”のタグであって、値が“Ｂ”のタグは、表示度を小さくする。

またシステムタグの中で、中位層が“発話者”のタグの表示度を小さくする。発話者がデフォルトでつぶやきごとに画面に表示される場合、“発話者”のタグは、閲覧者に与える情報量が小さいためである。

・画面の種類に応じたタグの利得（表示度）の算出
表示タイプで特定される画面の種類が“カレンダー”で、月内の各日のマスにつぶやき一覧を表示する場合、個別のつぶやきの“タグ”発話日時の中の“年月日”は、閲覧者に与える情報量は小さい。また画面の種類が“日内つぶやき一覧”の場合、やはり“年月日” は閲覧者に与える情報量は小さい。このように画面の種類に応じて、閲覧者に与える情報量の小さいタグの表示度を小さくすることができる。表示度の計算方法は、上記の例を用いればよい。

画面の主題の表示度、画面の種類の表示度をそれぞれ別個に算出し、大きい方の値を採用してもよい。あるいは、これらの表示度の重み付け合計を最終的な表示度として採用してもよい。画面の主題・種類以外の項目で表示度が定義出来る場合も同様にすればよい。

なお、上述したように、話題合致度は［４］の実施例で、閲覧状態適合度は［７］の実施例で、詳細を説明する。

［３］第２の実施例（タグ選出においてタグの階層構造を用いる機能）
本実施例では、同一の上位概念に属する利得の小さい複数個のタグの集約について説明する。

第１の実施例に示したタグの利得の算出後に、さらに以下の方法を適用することができる。

あるつぶやきに、同一の上位概念に属する利得の小さい（利得が閾値以下の）タグが複数個ある場合、これらのタグを上位概念に集約して、“上位タグ”を生成する。上位タグの利得は、これらのタグの利得の重み付け合計を利得とする。この上位タグを、つぶやきに添付し、他のタグと併せて、表示タグ選出部１０３において選出することができる。

たとえば、図５のタグ定義情報において、閲覧者の職種が介護士で、タグに、同一の中位層に属するタグ“ロキソニン”、“ロキソプロフェン”、“ワーファリン”が存在する場合、これらを１つに集約して、上位タグ“薬剤”を生成する。上位タグの利得は、これらのタグの利得がそれぞれ２であるため、これらの和をとって６とする。この場合、それぞれのタグの重みを１としている。

［４］第３の実施例（話題合致度の算出）
ある患者について、のどの具合や血圧についての話題など、特定の関心事についてのつぶやきが一定期間続くことがある。この場合、のどの具合や血圧といった一連の話題に関連するキーワードが頻出する。新規に発生したつぶやきに、最近頻出しているキーワードがあれば、それを選出して表示することで、閲覧者は、その新規のつぶやきを、当該患者について最近連続して発生している話題のつぶやきとして認識することができる。これにより、例えば、その話題が重要な話題であれば、閲覧者が、多数患者についてのつぶやきの一覧の中で優先的に閲覧するなどの、閲覧順序の選択をすることができる。これは次の方法で実現できる。

［４．１］キーワード頻度表
つぶやきの発生ごとに、あるいは一定の間隔ごとに、患者ごとに、当該患者についてのつぶやきに含まれる各キーワードの出現頻度を別途集計しておく（キーワード頻度表）。その際、キーワードの含まれるつぶやきの発話日時から閲覧日時の経過時間に応じて逓減する値で出現頻度に重み付けを行って集計してもよい。集計結果は図６のような出現頻度表で保持できる。新規つぶやきの発生ごとに、新規つぶやきを含む全つぶやき、あるいは一定の日時以降の全つぶやきについて、キーワードごとの、出現頻度をカウントすればよい。

その際、あるつぶやきiに含まれる各キーワード（タグID=jとする）の重みw_ijを次のように計算する。

また、患者pについての、重みを考慮したタグID＝jのキーワードの出現頻度f_pjを次のように計算する。

ここで、tは上記出現頻度f_pjの算出する日時（現在日時）、s_iは、つぶやきデータiにふくまれる発話日時、αは負の定数もしくは0である。0にすれば時間逓減率を0にでき、発話日時よらず、重み1で出現頻度を加算することになる。現在日時から一定時間前以降に発せられたつぶやきのみを対象として、頻度を算出することもできる。また出現頻度は、全つぶやき個数に対する相対頻度でもよい。頻度もしくは相対頻度が一定値以下のキーワードについては表から除外してもよい。

患者pについてのつぶやきかどうかは、つぶやきiに、タグの種類が患者名であるキーワード（図 5のタグ定義情報の場合、中位層：患者名）があるかどうかで判定でき、患者pについてのつぶやきを抽出できる。

あるいは、キーワード以外のシステムタグ等を利用して患者名を判定してもよい。すなわち、つぶやきの登録時に、携帯端末２００のアプリケーション上で明示的に患者の選択をしている場合や、バーコード、RFIDなどで明示的に患者を選択している場合がある。この場合は、キーワードではなく、アプリケーションの入力やセンサー情報といった種類のタグとして、患者IDが特定されているので、これを用いて、患者pについてのつぶやきを抽出できる。

［４．２］頻出キーワードの利得（話題合致度）
頻度が多いほど、話題一致度を大きく、頻度が少ないほど、話題一致度を小さくすることができる。たとえば、頻度が閾値以上のキーワードについては、話題合致度を第１の値とし、あるいは“真”にし、そうでないキーワードについては、話題合致度を第１の値より小さい第２の値とする、あるいは“偽”にする。下記［４．４］、［４．５］、［４．６］の実施例でも話題合致度を計算するが、これらの話題合致度を重み付け合計したものを最終的な話題合致度としてもよいし、最も大きな値の話題合致度を選択してもよい。その他の方法を用いてもよい。

［４．３］特異キーワードの利得（特異度）
［４．２］とは逆に、これまでのつぶやきの蓄積において、出現頻度の小さい（たとえば所定値未満の）キーワードが、表示対象のつぶやきに現れた場合に、そのキーワードの利得を大きくすることができる。この利得を特異度として、話題合致度と別の値として算出してもよい。この場合、この特異度も、利得の算出に加えればよい。

［４．４］タグの組み合わせ・順列の頻度による利得（話題合致度）
ある患者について、のどの具合や血圧についての話題など、特定の関心事についてのつぶやきが一定期間続く場合、一つのつぶやきの中で、あるいは近い日時に発せられた当該患者についての別のつぶやきの中で、異なる複数個のキーワードの組が頻出することがある。

このような複数個のキーワードの組の出現頻度を、別途集計しておく。2個のキーワードの組の場合の出現頻度は、図 7のような頻度表で保持できる。出現頻度は、全つぶやき個数に対する相対頻度でもよい。頻度もしくは相対頻度が一定値以下の組については、表から除外してもよい。また、キーワードの組の出現頻度を、患者ごとに保持してもよい。

この頻度表を参照し、ある患者についてつぶやきが発せられた場合に、最近頻出しているキーワードと組みになっているキーワード（関連キーワード）の話題合致度を大きくすることができる。そのような関連キーワードは、最近頻出していなくても、今後頻度する可能性がある重要なキーワードかもしれないからである。

具体的な動作として、まず、図 6に例示した出現頻度表を参照して、当該患者について、一定期間前以降の頻出しているキーワードの一覧を取得する。続いて、図 7のキーワードの組の出現頻度表を参照し、前記キーワードの一覧に含まれる各キーワードについて、関連キーワードと組みの出現頻度の一覧を取得する。続いて、関連キーワードが、表示対象の各つぶやきに含まれる場合は、その話題合致度として第１の値を採用し、含まれない場合は、第１の値より小さい第２の値を採用する。あるいは、関連キーワードが、表示対象の各つぶやきに含まれる場合は、［４．２］の実施例で計算された話題合致度に、第１の係数を乗じ、含まれない場合は、第１の係数より小さい第２の係数を乗じることで、当該話題合致度を調整してもよい。

［４．５］病名や処方、アセスメントと関連のあるつぶやきのタグの利得（話題合致度）
介護士やケアマネージャなどによる患者・被介護者の観察項目に関するキーワードなど、介護士にとっては高い利得が設定されているものの、医師や歯科医師にとっては低いデフォルト利得が設定されているタグがある。そのようなタグについて、ある患者・被介護者に特定の病名や処方が出されている場合には、その患者についてのつぶやきにおいては、話題合致度を高くして、タグが選出されるようにする。

例えば、介護士により、ある患者について“目が見えにくい”、“寝つきが悪い”、“夜、トイレで目が覚める”、“しびれがある”といったつぶやきがあると、“目”、“見えにくい”、“寝つき”、“悪い”、“トイレ”、“目が覚める”、といったキーワードが抽出される。この患者に、高血圧の疑いの診断が出されている場合は、これらのキーワードは高血圧の自覚症状を示す可能性がある。このため、医師がこのつぶやきを閲覧する場合には、これらのキーワードの話題合致度を高くして、キーワードが表示されようにすることで、医師による状態の把握を支援する。

つぶやきの登録時に、携帯端末２００のアプリケーション上で明示的に患者の選択をしている場合や、バーコード、RFIDなどで明示的に患者を選択している場合は、キーワードではなく、アプリケーションの入力やセンサー情報といった種類のタグとして患者IDが特定されている。この患者IDを用いて、本システムと接続可能な医療情報システム４００の患者情報保持部４０３から、現在、当該患者に出されている病名や処方の一覧を抽出できる。

つぶやきに、アプリケーションの入力やセンサー情報による患者IDタグが無い場合でも、つぶやきに含まれる患者氏名についてのキーワードからも、医療情報システムの患者情報保持部４０３内の患者マスタから患者IDを推定できる。このため、この患者IDを用いて、当該患者に出されている病名や処方の一覧を抽出できる。

病名や処方、アセスメント内容に関連のあるタグは、図 8のように、病名・処方・アセスメント内容に関連するタグを、表形式で定義することもでき、また 逆に、図 5のタグ定義情報に、タグに関連する病名や処方、アセスメント内容を列挙してもよい。バイタルセンサーの装着有無も、処方の一種である。SPO2計測のためのパルスオキシメーターについては、例えば食事における誤嚥に関するキーワードが、関連タグとして定義される。

具体的な動作として、医療情報システム４００から、つぶやきの対象患者の病名や処方、アセスメン内容の一覧を取得する。次に、タグ定義情報もしくは図 8の表に基づいて、抽出された病名や処方、アセスメン内容に関連するタグの話題合致度を高い値として算出する。病名や処方、アセスメン内容が空、もしくは病名や処方、アセスメン内容に関するタグがつぶやきに含まれない場合は、本例の話題合致度は算出されないか、０にする。病名や処方が空の場合は、本例の話題合致度の算出をスキップしてもよい。

［４．６］推定病名、推定アセスメント結果に関連のあるタグの利得（話題合致度）
図 6に示した、患者ごとのキーワードの頻度表において、一定の頻度以上のキーワードを抽出し、図 8の病名・処方と関連のあるタグの定義表から、これらのキーワードが関連付けられた病名、処方、アセスメント内容を、推定病名、推定処方、推定アセスメント内容として抽出できる。［４．５］と同様に、推定病名、推定処方、推定アセスメント内容に関連のあるキーワードについて、その話題合致度を算出できる。

［５］第４の実施例（患者に装着したセンサーデータによる対象患者コンテキスト、利得）
［５．１］センサーデータをつぶやきと見做し、タグを表示
患者に装着した、血圧計、心電計、血中酸素濃度計などのバイタルセンサーからのバイタル信号や、センサーの装着状態や動作状態についての警告信号を、患者宅に設置した通信端末や、患者の保持する携帯端末２００を介して、センサーを発話者とするつぶやきデータとして、サーバ（つぶやきデータ保持部３００）に保持することができる。

バイタル信号として、バイタル信号の数値、一定期間の数値の平均値や分散、これらの変化率、あるいはこれらを自然言語に変換したもの（“大きい”、“問題なし”など）がある。警告信号の例としては、 “センサーが体から外れています”、“バッテリーが消耗しています”などがある。

さらに上記の各種数値や、対応する自然言語を、タグとして、このつぶやきに添付できる。センサーによるセンシング時刻や警告信号の発生時刻、平均値・分散等の計算時刻、あるいはサーバへの送信時刻が、つぶやきの発話時刻となる。上記のセンサーデータのタグについても、キーワード等と同様に、タグ定義情報において、職種に応じデフォルトの利得を定義でき、閲覧コンテキストに応じた表示ができる。

［５．２］センサーデータの傾向による対象患者コンテキスト
患者に装着した、血圧計、心電計、血中酸素濃度計などのバイタルセンサーからのバイタル信号について、現在から一定期間前（過去1時間前以降など）までの値の平均値の大きさや、移動平均値（各日時t1について、そのΔt後までの平均を算出したものの列）の変化率の大きさを、対象患者コンテキストとすることができる。閲覧コンテキスト取得部１０１は、患者のセンサーからセンサー信号を取得し、上記の平均値や変化率の情報を計算してもよいし、センサーから上記の平均値や変化率の情報を直接取得してもよい。

例えば、過去1時間前以降の血圧の値の平均値を患者コンテキストとし、これが一定値以上を超えている場合は、上記のセンサーデータ（血圧だけでなく、体温、SOP2なども）に関するタグの利得を、医師、看護師である閲覧者については大きくする。

あるいはSPO2の移動平均の変化率から、SOP2が上昇傾向にあるか、下降傾向にあるかが分かるので、これによりSOP2が下降傾向にある場合は、医師、看護師である閲覧者については同じくセンサーデータに関するタグの利得を、医師、看護師である閲覧者については大きくする。たとえば、上記の職種に応じたデフォルトの利得に対し、一定係数を乗じることで、または一定値を加算することで、大きくしてもよい。

［６］第５の実施例（閲覧ユーザのタグ表示への応答による利得算出の学習）
閲覧ユーザは、つぶやき閲覧画面２０３上で、本システムにより選出されたタグが表示されたつぶやきに対し、「イイね」や「イマイチ」といった評価をすることができる。

あるいは、閲覧ユーザによるつぶやき閲覧画面２０３上での操作履歴を収集することもできる。たとえば閲覧ユーザがタグだけでは理解ができない場合に、つぶやきの音声認識結果を閲覧した場合に、つぶやきの音声認識結果を閲覧したとの操作履歴を収集することがある。

上述のタグ評価や操作履歴といった応答を取得し、その蓄積結果（タグ表示評価結果）を用いて、利得算出方法の改善の学習を行うことができる。

具体的には、つぶやき閲覧画面２０３上に配置された「イイね」ボタン（図１０、図１１参照）と、「イマイチ」ボタンといった評価ボタンを使って、閲覧ユーザが表示されたタグの適否を評価する。この評価結果が、タグ表示評価結果として、
ユーザＩＤ、タグ、コンテキスト、利得、評価結果（イイね、イマイチ、操作）
という組みで保存される。

タグの評価としては、「イイね」、「イマイチ」だけでなく、適切と不適切の各ボタン、有用と不要の各ボタンといった、別の種類のボタンによる評価も可能である。

特定の職種による評価の蓄積において、「イマイチ」など低い評価のタグ表示評価結果に共通に蓄積されている利得の低いタグについては、その利得を大きく算出するようにタグ定義表を更新する。あるいは、その利得を大きく算出するように、利得算出関数を更新してもよい。このように、ユーザのタグに関する評価を利用して、当該評価されたタグの利得の算出方法を変更する
逆に、特定の職種による評価の蓄積において、「イマイチ」など低い評価のタグ表示評価結果に共通に蓄積されている利得の高いタグについては、その利得を小さく算出するようにタグ定義表を更新する。あるいは、その利得を小さく算出するように、利得算出関数を更新してもよい。

［７］第６の実施例（タグと、閲覧ユーザの状態および属性に応じた、つぶやきの通知・表示制御機能）
つぶやきが新規につぶやきデータ保持部３００に登録された場合に、サーバは、他職員の携帯する端末２００に、新着のつぶやきデータを送信することができる。その際、新着のつぶやきについて、サーバもしくは携帯端末２００上で、タグの利得を算出し、タグの利得と、受信者（ユーザ）の属性や状態に応じて、新着案内の方法を変更することができる。

受信者の属性としては、職種、および当該つぶやきの対象患者の担当か否かがある。

状態としては、携帯端末２００の加速度センサー２０２で推定できる当該職員の行動状態（歩行中、静止中、車で移動中など）、同じく携帯端末２００の位置センサー２０１（GPSセンサーなど）で推定できる当該職員の位置（病院内、患者宅など）がある。

携帯端末２００上で動作する状態推定アプリケーションが、定期的にこれらのセンサーデータを収集し、位置推定エンジン５０１および行動推定エンジン５０２が状態推定（位置推定、行動推定）を行い、推定結果を適当なデータ保持手段に保持しておく。これにより、つぶやきの受信時に、つぶやき閲覧アプリケーションは、随時、状態推定結果を参照することができる。

新着案内の方法としては、
・端末上の新着アイコン表示（新着案内方法ID：A1）
・端末上の新着アイコン表示＋新着音再生（新着案内方法ID：A2）
・端末上の新着アイコン表示＋新着音再生＋タグの内容の音声合成再生（新着案内方法ID：A3）
などがある。

それぞれの新着案内方法には、ID（上記A1など）が付与されている。タグの利得と職員の属性に応じて、上記のどの新着案内方法が選択されるかは、図 10のような新着案内方法定義表により設定できる。

図 10では、職員の属性として、受信者職員位置推定結果を挙げているが、他の例として、職種、推定行動、推定業務、または、つぶやきの対象患者の担当か否か（真、偽）を加えた定義もできる。つぶやきの対象患者の担当か否かは、つぶやきに付与された患者IDタグと、本システムと接続可能な医療情報システム４００の職員情報保持部４０１に保持されている職員の日別の担当患者リストを用いて判定できる。つぶやきには一般に複数タグが添付されるので、タグ間での利得の最大値を求め、その値と、職員の属性に応じて、新着案内方法を選択する。

さらに図 10の新着案内方法定義表において、タグの種類（上位概念）に応じた新着案内方法を定義することもできる。例えば、センサーの装着状態に関する警告タグについては、通常のつぶやきの新着案内音とは異なる再生音で案内するように定義することができる。
［７．１］閲覧状態適合度による新着案内方法選出の例
上述したように、閲覧者が、新規に配信されたつぶやきを閲覧しやすい状態にあるかどうかを示す数値（数値が大きい方が閲覧しやすい）もしくはベクトルを閲覧状態適合度とする。この閲覧状態適合度と、つぶやきの利得の比較から、新着案内方法を選出することもできる。なお、本実施例では、閲覧状態適合度は、新着案内方法選出のために計算するが、算出した閲覧状態適合度は、関係度や表示度、話題合致度とともに、タグの利得算出に用いてもよい。

以下、閲覧状態適合度の算出例を示す。

例えば、次のようなIF-THENルールで、閲覧状態適合度を算出できる。

・推定位置を用いた閲覧状態適合度の算出例
IF（推定位置 ＝いずれかの患者の患者宅）THEN閲覧状態適合度＝1
ELSE閲覧状態適合度＝3

・推定業務を用いた閲覧状態適合度の算出例
IF（推定業務 ＝いずれかの病室での患者への直接看護）THEN閲覧状態適合度＝1
ELSE閲覧状態適合度＝3

・推定行動と推定位置を用いた閲覧状態適合度の算出例
IF（推定行動 ＝ 歩行 OR 推定行動 ＝ 車で移動）THEN閲覧状態適合度＝3
ELSE IF（推定行動 ＝ 静止 AND 推定位置 ＝いずれかの患者の患者宅）THEN閲覧状態適合度＝1
ELSE閲覧状態適合度＝2

閲覧状態適合度と、つぶやきの利得（つぶやきに付随するタグの利得の最大値）の比較により、以下のように新着案内方法を選出できる。

・新着案内方法の選出
IF 閲覧状態適合度 > つぶやきの利得 THEN新着案内方法＝A1
ELSE IF閲覧状態適合度 = つぶやきの利得THEN新着案内方法＝A2
ELSE 新着案内方法＝A3

閲覧状態適合度は、上記のような数値ではなく、推定位置に関する閲覧状態適合度、推定行動に関する閲覧状態適合度、推定業務に関する閲覧状態適合度といったように、複数の観点での適合度の組からなるベクトルとすることもできる。

その場合の新着案内方法の選出は、以下のように行う。推定位置に関する閲覧状態適合度とつぶやきの利得の比較、推定業務に関する閲覧状態適合度とつぶやきの利得の比較、推定行動に関する閲覧状態適合度とつぶやきの利得の比較の、それぞれを行う。いずれの比較においてもつぶやきの利得の方が大きい場合（いずれの観点でもつぶやきを積極的に案内したほうがよい）は、新着案内方法A3を選択する。いずれかの比較において、つぶやきの利得の方が小さい場合（いずれか観点でつぶやきの案内を差し控えた方がよい）は、新着案内方法A1を選択する。いずれの比較においてもつぶやきの利得と閲覧状態適合度が等しい場合は、新着案内方法A2を選択する。ここで述べた以外の選択方法を用いてもかまわない。

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

Claims (15)

1. つぶやきメッセージの複数のタグの中から、ユーザの端末画面に前記つぶやきメッセージへのリンクとともに表示するタグを選出する情報処理装置であって、
   前記ユーザの端末から、前記端末の画面のコンテキスト情報を取得するコンテキスト取得部と、
   前記コンテキスト情報に基づき、前記複数のタグのそれぞれについて、タグ利得を算出するタグ利得算出部と、
   前記タグ利得に基づき、前記複数のタグから少なくとも１つのタグを選出するタグ選出部と、
   を備えた情報処理装置。
2. 前記コンテキスト情報は、前記端末のユーザ情報を含み、
   前記タグ利得算出部は、ユーザと職種とを対応づけた職員情報と、前記ユーザ情報とに基づき、前記端末のユーザの職種を特定し、特定した職種に基づき、前記タグのタグ利得を算出する
   請求項１に記載の情報処理装置。
3. 前記コンテキスト情報は、前記端末の画面の主題および種類のうち少なくとも一方に関する情報を含む、
   請求項１または２に記載の情報処理装置。
4. 前記タグ利得算出部は、タグの値とタグの概念とを対応づけた情報に基づき、同一の概念に属し、かつ、利得が閾値以下の複数の異なる値のタグを統合して、上位タグを生成し、前記上位タグの値を、前記同一の概念に応じた値に設定し、前記上位タグのタグ利得を、統合前の各タグのタグ利得に基づいて算出する
   請求項１ないし３のいずれか一項に記載の情報処理装置。
5. 前記タグ利得算出部は、キーワードの出現頻度分布を表す第１情報に基づき、前記タグの示す値に一致するキーワードの発生頻度に応じて、前記タグのタグ利得を算出する
   請求項１ないし４のいずれか一項に記載の情報処理装置。
6. 前記タグ利得算出部は、キーワードの組の出現頻度分布を表す第２情報に基づき、前記第１情報において一定値以上の出現頻度を有するキーワードと組まれたキーワードを特定し、特定したキーワードと同じ値を示すタグのタグ利得を、これらのキーワードの組の出現頻度に応じて算出する
   請求項５に記載の情報処理装置。
7. 前記キーワードの出現頻度分布は、過去のつぶやきメッセージから抽出されたキーワードに基づいて生成されたものである
   請求項５または６に記載の情報処理装置。
8. 前記つぶやきメッセージは医療関係の人物によるメッセージであり、
   前記タグ利得算出部は、前記つぶやきメッセージの話題の対象である人物に対し行われた診断または処方の情報に基づいて、前記タグのタグ利得を算出する
   請求項１ないし７のいずれか一項に記載の情報処理装置。
9. 前記タグ選出部によって選出されたタグに関するユーザの評価を前記端末から収集し、前記評価に基づき、前記評価されたタグの利得の算出方法を変更する
   請求項１ないし８のいずれか一項に記載の情報処理装置。
10. 新たなつぶやきメッセージが登録されたことを示す情報を前記ユーザに通知し
    前記端末に搭載された位置センサーに基づき推定されるユーザの位置と、前記つぶやきメッセージの各タグの利得に基づき、前記つぶやきメッセージの通知方法を決定する
    請求項１ないし９のいずれか一項に記載の情報処理装置。
11. 新たなつぶやきメッセージの登録を前記ユーザに通知し、
    前記端末に搭載された加速度センサーに基づき推定されるユーザの行動と、前記つぶやきメッセージの各タグの利得に基づき、前記つぶやきメッセージの通知方法を決定する
    請求項１ないし１０のいずれか一項に記載の情報処理装置。
12. 新たなつぶやきメッセージの登録を前記ユーザに通知し、
    ユーザの業務予定情報に基づき、前記ユーザが行っている業務を推定し、推定した業務と、前記つぶやきメッセージの各タグの利得に基づき、前記つぶやきメッセージの通知方法を決定する
    請求項１ないし１１のいずれか一項に記載の情報処理装置。
13. 前記タグ利得算出部は、前記つぶやきメッセージの話題の対象となる人物に装着されたセンサーから取得されたセンサーデータに基づいて、前記タグのタグ利得を算出する
    請求項１ないし１２のいずれか一項に記載の情報処理装置。
14. つぶやきメッセージの複数のタグの中から、ユーザの端末画面に前記つぶやきメッセージへのリンクとともに表示するタグを選出する装置の情報処理方法であって、
    前記ユーザの端末から、前記端末の画面のコンテキスト情報を取得するコンテキスト取得ステップと、
    前記コンテキスト情報に基づき、前記複数のタグのそれぞれについて、タグ利得を算出するタグ利得算出ステップと、
    前記タグ利得に基づき、前記複数のタグから少なくとも１つのタグを選出するタグ選出ステップと、
    を備えた情報処理方法。
15. つぶやきメッセージの複数のタグの中から、ユーザの端末画面に前記つぶやきメッセージへのリンクとともに表示するタグを選出するためのプログラムであって、
    前記ユーザの端末から、前記端末の画面のコンテキスト情報を取得するコンテキスト取得ステップと、
    前記コンテキスト情報に基づき、前記複数のタグのそれぞれについて、タグ利得を算出するタグ利得算出ステップと、
    前記タグ利得に基づき、前記複数のタグから少なくとも１つのタグを選出するタグ選出ステップと、
    をコンピュータに実行させるためのプログラム。

Images