特開 2022-117933 管理サーバーと医療施設との間で共有される医療情報の削除

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022117933

(43)【公開日】2022-08-12

(54)【発明の名称】管理サーバーと医療施設との間で共有される医療情報の削除

(51)【国際特許分類】

   G16H 10/00 20180101AFI20220804BHJP

【ＦＩ】

G16H10/00

【審査請求】未請求

【請求項の数】15

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2021198646

(22)【出願日】2021-12-07

(31)【優先権主張番号】17/163,933

(32)【優先日】2021-02-01

(33)【優先権主張国・地域又は機関】US

(71)【出願人】

【識別番号】518032971

【氏名又は名称】コニカ ミノルタ ヘルスケア アメリカズ， インコーポレイテッド

(74)【代理人】

【識別番号】110001254

【氏名又は名称】特許業務法人光陽国際特許事務所

(72)【発明者】

【氏名】石川 貴之

【テーマコード（参考）】

5L099

【Ｆターム（参考）】

5L099AA21

(57)【要約】      （修正有）

【課題】管理サーバーと管理サーバーに接続される医療施設とで共有される医療情報の削除を制御するための管理サーバー、方法及び非一時的なコンピュータ読取り可能な媒体（ＣＲＭ）を提供する。
【解決手段】患者身元特定情報を含む医療情報を保存する記憶部と記憶部に接続されたプロセッサとを備える管理サーバーによる方法は、死亡患者の患者身元特定情報を受信し、死亡患者医療情報を取得し、死亡患者医療情報が死亡患者の病状を特定する所定情報を含むかどうか判断し、死亡患者医療情報が所定情報を含まないと判断すると、死亡患者医療情報を記憶部から削除し、死亡患者医療情報が所定情報を含むと判断すると、死亡患者医療情報から所定情報を死亡患者の患者身元特定情報とともに抽出し、抽出した死亡患者の所定情報及び患者身元特定情報を病状情報として記憶部に別々に保存し、病状情報の抽出及び保存後に死亡患者医療情報を削除する。
【選択図】図１０

【特許請求の範囲】

【請求項1】

医療施設と通信を行う管理サーバーは、
患者身元特定情報を含む医療情報を保存する記憶部と、
前記記憶部に接続されたプロセッサと、を備え、
前記プロセッサは、
死亡患者の患者身元特定情報を受信し、
前記死亡患者の患者身元特定情報を用いて、前記記憶部内の前記医療情報から死亡患者医療情報を取得し、
前記死亡患者医療情報が前記死亡患者の病状を特定する所定情報を含むかどうか判断し、
前記死亡患者医療情報が前記所定情報を含まないと判断すると、前記死亡患者医療情報を前記記憶部から削除し、
前記死亡患者医療情報が前記所定情報を含むと判断すると、前記死亡患者医療情報から前記所定情報を前記死亡患者の患者身元特定情報とともに抽出し、抽出した前記所定情報及び前記死亡患者の患者身元特定情報を病状情報として前記記憶部に別々に保存し、前記病状情報の抽出及び保存後に前記死亡患者医療情報を削除し、
前記医療施設から病状情報取得要求を受信すると、前記病状情報を前記医療施設に送信して前記医療施設の表示装置に表示されるようにする
管理サーバー。

【請求項2】

前記プロセッサは更に、
前記死亡患者の死因を含む死亡情報を受信したかどうか判断し、
前記死亡情報を受信したと判断すると、前記死亡情報を前記記憶部に保存し、
前記死亡情報は受信していないが、前記管理サーバー内に記録されている各患者が死亡しているか生存しているかを示す現状情報は受信したと判断すると、前記現状情報を前記記憶部に保存する
請求項１に記載の管理サーバー。

【請求項3】

前記プロセッサは更に、
前記死亡患者医療情報が前記所定情報を含むと判断すると、所定時間が経過したかどうか判断し、
所定時間が経過したと判断すると、前記所定情報が抽出されたかどうかに関わらず前記死亡患者医療情報を削除する
請求項１に記載の管理サーバー。

【請求項4】

前記プロセッサは更に、
前記死亡患者医療情報が前記所定情報を含むと判断すると、前記所定情報が特定のアイテムを含むかどうか判断し、
前記所定情報が前記特定のアイテムを含むと判断すると、前記所定情報から前記特定のアイテムを抽出し、前記特定のアイテムを前記所定情報の代わりに前記病状情報として保存する
請求項１に記載の管理サーバー。

【請求項5】

前記患者身元特定情報は、患者名及び生年月日を含み、
前記プロセッサは、前記患者名を死亡日に置き換えるか、前記生年月日を予め選択された日付に置き換えるか、又はその両方によって前記患者身元特定情報を匿名化する
請求項１に記載の管理サーバー。

【請求項6】

医療施設と通信を行う管理サーバーの記憶部からの医療情報の削除を制御する方法であって、前記記憶部は患者身元特定情報を含む医療情報を保存し、前記方法は以下を含む：
死亡患者の患者身元特定情報を受信する工程、
前記死亡患者の患者身元特定情報を用いて、前記記憶部内の前記医療情報から死亡患者医療情報を取得する工程、
前記死亡患者医療情報が前記死亡患者の病状を特定する所定情報を含むかどうか判断する工程、
前記死亡患者医療情報が前記所定情報を含まないと判断すると、前記死亡患者医療情報を前記記憶部から削除する工程、
前記死亡患者医療情報が前記所定情報を含むと判断すると、前記死亡患者医療情報から前記所定情報を前記死亡患者の患者身元特定情報とともに抽出し、抽出した前記所定情報及び前記死亡患者の患者身元特定情報を病状情報として前記記憶部に別々に保存し、前記病状情報の抽出及び保存後に前記死亡患者医療情報を削除する工程、及び
前記医療施設から病状情報取得要求を受信すると、前記病状情報を前記医療施設に送信して前記医療施設の表示装置に表示されるようにする工程。

【請求項7】

請求項６に記載の方法であって、更に以下を含む：
前記死亡患者の死因を含む死亡情報を受信したかどうか判断する工程、
前記死亡情報を受信したと判断すると、前記死亡情報を前記記憶部に保存する工程、及び
前記死亡情報は受信していないが、前記管理サーバー内に記録されている各患者が死亡しているか生存しているかを示す現状情報は受信したと判断すると、前記現状情報を前記記憶部に保存する工程。

【請求項8】

請求項６に記載の方法であって、更に以下を含む：
前記死亡患者医療情報が前記所定情報を含むと判断すると、更に所定時間が経過したかどうか判断する工程、及び
所定時間が経過したと判断すると、前記所定情報が抽出されたかどうかに関わらず前記死亡患者医療情報を削除する工程。

【請求項9】

請求項６に記載の方法であって、更に以下を含む：
前記死亡患者医療情報が前記所定情報を含むと判断すると、前記所定情報が特定のアイテムを含むかどうか判断する工程、及び
前記所定情報が前記特定のアイテムを含むと判断すると、前記所定情報から前記特定のアイテムを抽出し、前記特定のアイテムを前記所定情報の代わりに前記病状情報として保存する工程。

【請求項10】

請求項６に記載の方法であって、
前記患者身元特定情報は、患者名及び生年月日を含み、
前記方法は更に、前記患者名を死亡日に置き換えるか、前記生年月日を予め選択された日付に置き換えるか、又はその両方によって前記患者身元特定情報を匿名化する工程を含む。

【請求項11】

医療施設と通信を行う管理サーバーの記憶部からの医療情報の削除を制御する指示を格納した、非一時的なコンピュータ読取り可能な媒体（ＣＲＭ）であって、
前記記憶部は患者身元特定情報を含む医療情報を保存し、
前記指示は、管理サーバーに以下を実行させる：
死亡患者の患者身元特定情報を受信し、
前記死亡患者の患者身元特定情報を用いて、前記記憶部内の前記医療情報から死亡患者医療情報を取得し、
前記死亡患者医療情報が前記死亡患者の病状を特定する所定情報を含むかどうか判断し、
前記死亡患者医療情報が前記所定情報を含まないと判断すると、前記死亡患者医療情報を前記記憶部から削除し、
前記死亡患者医療情報が前記所定情報を含むと判断すると、前記死亡患者医療情報から前記所定情報を前記死亡患者の患者身元特定情報とともに抽出し、抽出した前記所定情報及び前記死亡患者の患者身元特定情報を病状情報として前記記憶部に別々に保存し、前記病状情報の抽出及び保存後に前記死亡患者医療情報を削除し、
前記医療施設から病状情報取得要求を受信すると、前記病状情報を前記医療施設に送信して前記医療施設の表示装置に表示されるようにする。

【請求項12】

請求項１１に記載のＣＲＭであって、前記指示は更に、管理サーバーに以下を実行させる：
前記死亡患者の死因を含む死亡情報を受信したかどうか判断し、
前記死亡情報を受信したと判断すると、前記死亡情報を前記記憶部に保存し、
前記死亡情報を受信していないが、前記管理サーバー内に記録されている各患者が死亡しているか生存しているかを示す現状情報は受信したと判断すると、前記現状情報を前記記憶部に保存する。

【請求項13】

請求項１１に記載のＣＲＭであって、前記指示は更に、管理サーバーに以下を実行させる：
前記死亡患者医療情報が前記所定情報を含むと判断すると、所定時間が経過したかどうか判断し、
所定時間が経過したと判断すると、前記所定情報が抽出されたかどうかに関わらず死亡患者医療情報を削除する。

【請求項14】

請求項１１に記載のＣＲＭであって、前記指示は更に、管理サーバーに以下を実行させる：
前記死亡患者医療情報が前記所定情報を含むと判断すると、前記所定情報が特定のアイテムを含むかどうか判断し、
前記所定情報が前記特定のアイテムを含むと判断すると、前記所定情報から前記特定のアイテムを抽出し、前記特定のアイテムを前記所定情報の代わりに病状情報として保存する。

【請求項15】

請求項１１に記載のＣＲＭであって、
前記患者身元特定情報は、患者名及び生年月日を含み、
前記指示は更に、管理サーバーに以下を実行させる：
前記患者名を死亡日に置き換えるか、前記生年月日を予め選択された日付に置き換えるか、又はその両方によって前記患者身元特定情報を匿名化する。

【発明の詳細な説明】

【技術分野】

【0001】

医療画像及び医療データ（ここでは集合的に「医療情報」と呼ぶ）は、医療従事者が患者を診断するにあたって重要な役目を果たしている。これらの医療情報を電子的に保存する有益性は、医療施設（例：病院）にも認識されてきた。医療情報のデジタル化により、医療従事者が医療情報に容易にアクセスできるだけでなく、複数の医療施設の間でコンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、及びユニバーサル・シリアル・バス（ＵＳＢ）フラッシュドライブといった物理的媒体を用いて医療情報を容易に共有することも可能となる。

【0002】

近年では、効率性と情報へのアクセシビリティを向上させる手段として、クラウドベースの記憶システムが登場している。一般的に、「クラウド」はオンラインのストレージシステムであって、各地のコンピュータやデバイスが必要に応じ、コンピューティング資源（計算資源）やデータにインターネットを介してリモートにアクセスできるようにするものと理解される。クラウドベースのストレージはベンダー（提供元）により提供されうる。ベンダーは様々な場所（遠隔地や現場と異なる場所）にあるデータセンターを用いて医療画像等のデータを保存する。また、クラウドベースの保存場所を提供するベンダーは、共通のビューイングシステム（「ユニバーサルビューア」）を提供する。ユニバーサルビューアによって、クラウドネットワーク内の医療施設は、クラウドネットワーク内の他の医療施設にある患者の医療情報一式を一度の要求で取得することができる。

【発明の概要】

【発明が解決しようとする課題】

【0003】

しかし、これらのデジタル化された医療情報は通常、患者が死亡して一定期間が経過すると自動的に削除されるよう設定されている。例えば死亡した患者の医療情報は、患者の死去から一定時間が経過した後に削除されるため、その後活用することは不可能である。

【課題を解決するための手段】

【0004】

本発明の一以上の実施形態は、管理サーバーと管理サーバーに接続される医療施設とで共有される医療情報の削除を制御するための管理サーバー、方法及び非一時的なコンピュータ読取り可能な媒体（ＣＲＭ）を提供する。

【0005】

一以上の実施形態は、医療施設と通信を行う管理サーバーを提供する。管理サーバーは、患者身元特定情報を含む医療情報を保存する記憶部と、前記記憶部に接続されたプロセッサと、を備え、前記プロセッサは、死亡患者の患者身元特定情報を受信し、前記死亡患者の患者身元特定情報を用いて、前記記憶部内の前記医療情報において死亡患者医療情報を検索し、前記死亡患者医療情報が前記死亡患者の病状を特定する所定情報を含むかどうか判断し、前記死亡患者医療情報が前記所定情報を含まないと判断すると、前記死亡患者医療情報を前記記憶部から削除し、前記死亡患者医療情報が前記所定情報を含むと判断すると、前記死亡患者医療情報から前記所定情報を前記死亡患者の患者身元特定情報とともに抽出し、抽出した前記所定情報及び前記死亡患者の患者身元特定情報を病状情報として前記記憶部に別々に保存し、前記病状情報の抽出及び保存後に前記死亡患者医療情報を削除し、前記医療施設から病状情報取得要求を受信すると、前記病状情報を前記医療施設に送信して前記医療施設の表示装置に表示されるようにする。

【0006】

一以上の実施形態は、医療施設と通信を行う管理サーバーの記憶部からの医療情報の削除を制御する方法を提供する。前記記憶部は患者身元特定情報を含む医療情報を保存し、前記方法は以下を含む：死亡患者の患者身元特定情報を受信する工程、前記死亡患者の患者身元特定情報を用いて、前記記憶部内の前記医療情報から死亡患者医療情報を検索する工程、前記死亡患者医療情報が前記死亡患者の病状を特定する所定情報を含むかどうか判断する工程、前記死亡患者医療情報が前記所定情報を含まないと判断すると、前記死亡患者医療情報を前記記憶部から削除する工程、前記死亡患者医療情報が前記所定情報を含むと判断すると、前記死亡患者医療情報から前記所定情報を前記死亡患者の患者身元特定情報とともに抽出し、抽出した前記所定情報及び前記死亡患者の患者身元特定情報を病状情報として前記記憶部に別々に保存し、前記病状情報の抽出及び保存後に前記死亡患者医療情報を削除する工程、及び前記医療施設から病状情報取得要求を受信すると、前記病状情報を前記医療施設に送信して前記医療施設の表示装置に表示されるようにする工程。

【0007】

一以上の実施形態は、医療施設と通信を行う管理サーバーの記憶部からの医療情報の削除を制御する指示を格納した、非一時的なコンピュータ読取り可能な媒体（ＣＲＭ）を提供する。前記記憶部は患者身元特定情報を含む医療情報を保存し、前記指示は、管理サーバーに以下を実行させる：死亡患者の患者身元特定情報を受信し、前記死亡患者の患者身元特定情報を用いて前記記憶部内の前記医療情報から死亡患者医療情報を検索し、前記死亡患者医療情報が前記死亡患者の病状を特定する所定情報を含むかどうか判断し、前記死亡患者医療情報が前記所定情報を含まないと判断すると、前記死亡患者医療情報を前記記憶部から削除し、前記死亡患者医療情報が前記所定情報を含むと判断すると、前記死亡患者医療情報から前記所定情報を前記死亡患者の患者身元特定情報とともに抽出し、抽出した前記所定情報及び前記死亡患者の患者身元特定情報を病状情報として前記記憶部に別々に保存し、前記病状情報の抽出及び保存後に前記死亡患者医療情報を削除し、前記医療施設から病状情報取得要求を受信すると、前記病状情報を前記医療施設に送信して前記医療施設の表示装置に表示されるようにする。

【0008】

本発明のその他の側面及び利点は、以下の説明及び添付の特許請求の範囲から明らかとなるであろう。

【図面の簡単な説明】

【0009】

【図1】一以上の実施形態にかかるシステムを示す。

【図2】一以上の実施形態にかかる、管理サーバーに保存されるデータベースのテーブルを示す。

【図3】一以上の実施形態にかかる、管理サーバーに保存されるデータベースの他のテーブルを示す。

【図4】一以上の実施形態にかかる、管理サーバーに保存されるデータベースの他のテーブルを示す。

【図5】一以上の実施形態にかかる、管理サーバーに保存されるデータベースの他のテーブルを示す。

【図6】一以上の実施形態にかかる、管理サーバーに保存されるデータベースの他のテーブルを示す。

【図7】図７Ａ～図７Ｆは、一以上の実施形態にかかるシステムのスクリーンの例を示す。

【図8】図８Ａ～図８Ｅは、一以上の実施形態にかかるシステムのスクリーンの他の例を示す。

【図9】一以上の実施形態にかかる、管理サーバーに保存されるデータベースの他のテーブルを示す。

【図10】一以上の実施形態にかかるフローチャートを示す。

【図11】一以上の実施形態にかかるコンピューティングシステムを示す。

【発明を実施するための形態】

【0010】

ここで、添付の図面を参照しながら具体的な実施形態を詳細に説明する。一貫性を保つため、各図面における類似の要素には類似の参照番号を付す。簡略化のため、類似の要素の参照番号は全図面に付されていない場合がある。

【0011】

本開示における実施形態の以下の詳細な説明では、本開示についての十分な理解を促すために具体的な詳細を数多く記載している。しかし当業者にとっては、これらの具体的な詳細が無くとも本発明が実施可能であることは明らかであろう。また、説明が不必要に複雑にならないよう、周知の特徴については詳細に記載していない。

【0012】

本出願の全体において、序数（例えば、第１、第２、第３等）は、要素（すなわち、本出願内のあらゆる名詞）の形容詞として用いられることがある。序数の使用は、例えば「前」、「後」、「単数の」やその他の用語を使用して明確に開示されていない限り、要素の特定の序列を示唆するものでも、要素に特定の序列をつけるものでもなく、いずれの要素をも単一の要素のみに限定するものでもない。むしろ、序数の使用は要素同士を区別するものである。例えば、第１の要素は第２の要素と区別され、また第１の要素は２つ以上の要素を含むことがあり、また要素の順序付けにおいて、第１の要素は第２の要素に後続（又は先行）することがある。

【0013】

単数形の「ａ」、「ａｎ」及び「ｔｈｅ」は、文脈上明らかにそうでないと示されない限り、複数も対象として含むと理解されるものとする。従って、例えば「水平な梁（ａ ｈｏｒｉｚｏｎｔａｌ ｂｅａｍ）」との記載は、そのような梁が１つ以上あることを含む。

【0014】

「およそ」、「実質的に」等の用語は、記載される特徴、パラメーター又は値が正確に達成される必要がないが、例えば許容誤差、測定誤差、測定の精度限界及び当業者の知るその他要因を含むずれや変動が、その特徴により得られるとされる効果を妨げない程度で起こりうることを意味する。

【0015】

多項従属の請求項は用いられていないが、一以上の実施形態にかかる従属クレームの主題が他の従属クレームと組み合わせ可能であることは、当業者には明らかであろう。

【0016】

［システムの概要］
概して、本発明の一以上の実施形態は、管理サーバー、方法及び非一時的なコンピュータ読み取り可能な媒体（ＣＲＭ）を提供する。これら管理サーバー、方法及びＣＲＭは、医療情報共有システム（例：ユニバーサルビューア）を通じて接続された管理サーバー（例：クラウドサーバー）と医療施設との間で共有される医療情報の削除を制御するためのものである。

【0017】

管理サーバーは、ユニバーサルビューアアプリがインストールされたユニバーサルビューアコンピューティング装置を備える。ユニバーサルビューアコンピューティング装置は、以下を含む工業用コンピュータであってよい：一以上のコンピュータプロセッサ、関連メモリ（例：ランダムアクセスメモリ（ＲＡＭ）、キャッシュメモリ、フラッシュメモリ等）、一以上の記憶装置（例：ハードディスク、コンパクトディスク（ＣＤ）やデジタル多用途ディスク（ＤＶＤ）といった光学ドライブ、フラッシュメモリスティック等）、その他多くの構成要素及び機能。ユニバーサルビューアコンピューティング装置は、クラウドベースのＰＡＣＳのサービスを提供するベンダーによって管理されうる。

【0018】

管理サーバーは、医療施設で行われた診断及び検査（例：コンピュータ断層撮影（ＣＴ）、磁気共鳴画像法（ＭＲＩ）等）から得られた患者の医療情報を統括的に管理する。管理サーバーはいずれかの医療施設から取得要求を受け取ると、医療情報を要求元の医療施設に送信し、当該医療情報が要求元の医療施設においてユーザーに表示されるようにする。ユーザーは患者の診察や治療の際、当該医療情報を視認し用いることができる。「ユーザー」はあらゆる医療従事者であってよく、例えば医師、看護師、医療スタッフ、医療技術者等である。

【0019】

一以上の実施形態において、管理サーバー及び医療施設は、同じ又は異なるベンダーによるクラウドベースの記憶システム、医療用画像管理システム（ＰＡＣＳ）及びクラウドベースのＰＡＣＳのうちいずれか一つと関連付けられうる。

【0020】

一以上の実施形態において、患者の医療画像は、Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ（ＤＩＣＯＭ）規格の画像として保存されうる。ＤＩＣＯＭ規格の画像は、患者の医療データをメタデータ形式で保存しうる。患者の医療データは、患者身元特定情報（例：患者ＩＤ、患者名、患者の生年月日（ＤＯＢ）、患者性別等）及び検査特定情報（例：検査日、各医療画像の受け入れ番号、検査に用いられたモダリティのタイプ等）を含みうる。また、患者の医療データは、電子文書の形式（例：ＯＯＸＭＬドキュメント、ＰＤＦドキュメント等）で別途保存されてもよい。

【0021】

［システム構造］
図１は、一以上の実施形態にかかるシステム（１０００）を示す。図示のように、システム（１０００）は、管理サーバー（１００）及び施設Ａ～Ｃ（すなわち、医療施設）を含む。施設Ａ～Ｃはインターネット等のネットワークを介して相互接続される。施設Ａ～Ｃは、医療を提供するいかなる種類の施設であってよい（例：公立病院、私立病院、診療所、歯科医院、緊急車両（例：救急車）、可動式医療車両等）。一以上の実施形態において、医療施設の数は図１の３つに限られない。管理サーバー（１００）を介して相互接続される医療施設はいくつあってもよい。

【0022】

［管理サーバー］
管理サーバー（１００）は、クラウドサーバーや、施設Ａ～Ｃのいずれかにインストールされたローカルサーバーであってよい。管理サーバー（１００）は、施設Ａ～Ｃから送信された医療情報を統括的に管理する。本開示では、死亡した患者の医療情報を別途、死亡患者医療情報と呼ぶ。管理サーバー（１００）は、死亡患者医療情報の中から、所定情報及び患者身元特定情報を抽出する、所定情報は死亡患者の病状を記す。患者身元特定情報は死亡患者医療情報の中から死亡患者の身元を特定する。管理サーバー（１００）はさらに、抽出した所定情報及び患者身元特定情報を、死亡患者の病状情報として別々に保存する。施設Ａ～Ｃのいずれかから病状情報取得要求を受信すると、管理サーバー（１００）は要求された病状情報を要求元に送信し、病状情報がこれらの施設で表示・使用できるようにする。

【0023】

所定情報は、死亡患者の具体的死因に関する情報及び／又は病歴情報である。所定情報については、図８Ａ、８Ｂを参照して詳しく後述する。さらに所定情報は、死亡患者の診断レポート、疾患に関連した医療画像及び／又は薬歴といった特定のアイテムを一以上含みうる。これらについても、図８Ａ、８Ｂを参照して詳しく後述する。

【0024】

図１に示すように、管理サーバー（１００）はプロセッサ（１１０）、記憶部（１２０）及びＩ／Ｏインターフェース（１３０）を備える。管理サーバー（１００）はまた、クラウドゲートウェイ（ＧＷ）装置を備えてもよい。クラウドＧＷ装置は、管理サーバー（１００）が物理的に配置される施設内のハブやローカルエリアネットワーク（ＬＡＮ）であってよい。クラウドＧＷ装置は、管理サーバー（１００）と施設Ａ～Ｃとの間の中継点として構成されうる。中継点は、各施設Ａ～Ｃが管理サーバー（１００）と通信して医療情報を共有できるようにする。

【0025】

プロセッサ（１１０）は、ユニバーサルビューアコンピューティング装置のためのウェブクライアントアプリを備えうる。ウェブクライアントにより、施設Ａ～Ｃは、ウェブブラウザを通じてユニバーサルビューアアプリにアクセスすることができる。例えば、ユニバーサルビューアアプリはウェブページとしてアクセスされてよい。アクセスは、ウェブクライアントと関連付けられた一定のユニフォームリソースロケータ（ＵＲＬ）（例：ウェブアドレス）をウェブブラウザの検索バーに入力することで行われる。

【0026】

さらに、プロセッサ（１１０）はデータ管理機能、データ抽出／削除機能、データ匿名化機能及びデータ送信機能を備える。これらの機能については後述する。ウェブクライアント及びこれらの機能は、プロセッサ（１１０）によって実行されるよう構成されたアプリやプログラムであってよい。

【0027】

記憶部（１２０）は、データベースを管理サーバー（１００）にリモートに保存する医療用リモートリポジトリとして構成される。例えば、医療用リモートリポジトリは、インターネットを通じてリモートにアクセスされる仮想データルーム（ＶＤＲ）やデータベース（又は一群のデータベース）であってよい。

【0028】

記憶部（１２０）のデータベースは医療情報を保存する。医療情報は、Ｉ／Ｏインターフェース（１３０）を通じてユーザーから入力されるか、又は施設Ａ～Ｃから送信されうる。

【0029】

データベースはまた、医療情報の一部として、患者の現状情報（ここでは「現状情報」と呼ぶ）及び死亡患者の死亡情報（ここでは「死亡情報」と呼ぶ）を保存する。現状情報及び死亡情報は、Ｉ／Ｏインターフェース（１３０）を通じてユーザーから入力されるか、又は施設Ａ～Ｃから送信されてもよい。現状情報は、管理サーバー（１００）に記録のある患者が生存しているか死亡しているかを示す。死亡情報は、死亡患者の死亡についての情報（例：死亡日、死因、死亡者の名前、死亡場所等）を提供する死亡診断書又はそれに似た種類の情報であってよい。

【0030】

一以上の実施形態において、Ｉ／Ｏインターフェース（１３０）は、タッチスクリーン、キーボード、マウス、マイク、タッチパッド、電子ペン又はその他の種類の入力装置といった入力装置を備えうる。またＩ／Ｏインターフェース（１３０）は、スクリーン（例えば、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、タッチスクリーン、ブラウン管（ＣＲＴ）モニター、プロジェクター又はその他の表示装置）、プリンター、外部記憶装置、又はその他の出力装置といった出力装置を備えてよい。

【0031】

［医療施設］

【0032】

図１に示すように、システム（１０００）はさらに施設Ａ～Ｃにおいて、ローカルコンピューティング装置（ローカルコンピュータ）（２００Ａ～２００Ｃ）を備える。各ローカルコンピューティング装置（２００Ａ～２００Ｃ）は、パーソナルコンピュータ（ＰＣ）、ラップトップ、モバイルコンピューティング装置（例：タブレットＰＣ、スマートフォン等）、サーバー、汎用コンピュータ、キオスク等に相当するものであってよい。施設Ａ～Ｃにおけるローカルコンピューティング装置（２００Ａ～２００Ｃ）の構造は類似しているため、簡略化し、施設Ａのローカルコンピューティング装置（２００Ａ）のみを説明する。

【0033】

ローカルコンピューティング装置（２００Ａ）はプロセッサ（２１０Ａ）、記憶部（２２０Ａ）及びＩ／Ｏインターフェース（２３０Ａ）を備える。ローカルコンピューティング装置（２００Ａ）はさらに、ローカルＧＷデバイス（非図示）を備える。ローカルＧＷデバイスは、ローカルに管理され保存されているデータを管理サーバー（１００）と同期させる。ローカルコンピューティング装置（２００Ａ）はまた、ユニバーサルビューアクライアントアプリ（非図示）を備える。ユニバーサルビューアクライアントアプリは、当アプリに関連した内容をＩ／Ｏインターフェース（２３０Ａ）に表示させ、入力されたコマンドをＩ／Ｏインターフェース（２３０Ａ）から受信する。

【0034】

プロセッサ（２１０Ａ）は、医療情報を記憶部（２２０Ａ）において管理する。さらにプロセッサ（２１０Ａ）は、Ｉ／Ｏインターフェース（２３０Ａ）を通じて入力されたユーザーの入力に基づき、病状情報取得要求を管理サーバー（１００）に送信する。病状情報取得要求は、検索要求キーを含みうる。検索要求キーは、医療情報が要求されている患者を特定する患者身元特定情報を含む。

【0035】

要求した病状情報を管理サーバー（１００）から受信すると、プロセッサ（２１０Ａ）は病状情報を記憶部（２２０Ａ）に保存し、及び／又は病状情報をＩ／Ｏインターフェース（２３０Ａ）に表示させる。

【0036】

一以上の実施形態において、記憶部（２２０Ａ）は、施設Ａで行われた検査及び／又は診断から得られた医療情報と、管理サーバー（１００）から受信した病状情報を記憶する。さらに、Ｉ／Ｏインターフェース（２３０Ａ）は、Ｉ／Ｏインターフェース（１３０）と類似の機能及び構造を持つ。

【0037】

図２～６は、一以上の実施形態において記憶部（１２０）に記憶されている医療情報データベースの表の例を示す。

【0038】

図２は、一以上の実施形態において表示される医療情報の表の１つのフォーマットを示す。図示のように、各医療情報は、患者ＩＤ、患者名、性別及び生年月日といった患者身元特定情報を含む。

【0039】

医療情報はまた、現状情報（例：ライフフラグ）及び病歴情報（例：病歴フラグ）を含んでもよい。病歴情報は、ある患者が以前に病歴上深刻な疾患を患っていたかどうかを示すものである。もしくは、医療情報は、病歴フラグの代わりに、具体的死因に関する情報が入手可能かどうかを示す列を備えてもよい。

【0040】

図２に示す例において、ライフフラグの行における「１」は患者が生存していることを示し、「２」は患者が死亡していることを示す。加えて、病歴フラグの行における「１」は患者が以前深刻な疾患を患っていたことを示し、「２」は患者がこれまで深刻な疾患を患っていないことを示す。一以上の実施形態において、「１」の病歴フラグは、医療情報が所定情報を含むことを示す。

【0041】

図３は、一以上の実施形態において表示される医療情報の表の他のフォーマットを示す。図示のように、各医療情報は一以上の医療画像（「ＤＩＣＯＭ１」、「ＤＩＣＯＭ２」、「ＤＩＣＯＭ３」等）及び一以上の報告データ（「報告１」、「報告２」、「報告３」等）を含む。各医療画像及び報告データは、検査ＩＤ（「１１１」、「２２２」、「３３３」等）及び患者ＩＤ（「患者１」、「患者２」、「患者３」等）と関連付けられている。

【0042】

図４は、一以上の実施形態において表示される医療情報の表のさらに他のフォーマットを示す。図示のように、各医療情報は検査特定情報を含んでよい。検査特定情報は、検査ＩＤ（「１１１」、「２２２」、「３３３」等）、検査オーダーＩＤ（「オーダー１」、「オーダー２」、「オーダー３」等）、検査日（「０４／１６／２０１５」、「０７／０６／２０１６」、「０９／２６／２０１７」等）、検査部位（「脳」、「肺」、「心臓」等）、検査を行った医師（「Ｍ．Ｓｍｉｔｈ」、「Ｍ．Ｓｍｉｔｈ」、「Ｋ．Ｍｉｃｈａｅｌ」等）などである。

【0043】

図５は、一以上の実施形態において表示される医療情報の表のさらに他のフォーマットを示す。図５に示すフォーマットは、患者ＩＤと、図２を参照して説明したライフフラグのみを含んでいる。

【0044】

図６は、一以上の実施形態において表示される医療情報の表のさらに他のフォーマットを示す。図６に示すフォーマットは、患者ＩＤと、図２を参照して説明した病歴フラグのみを含んでいる。一以上の実施形態において、深刻な疾患に関する情報は、Ｉ／Ｏインターフェース（１３０）を通じて前もって設定され記憶部（１２０）に記憶されてよい。

【0045】

一以上の実施形態において、図２～６に示すフォーマットを組み合わせてもよく、フォーマットは各図に示される情報のみに限られるものではない。例えば、医療情報を表示する表は、図２～６のフォーマットを任意に組み合わせてそこから任意の行を１つ（又は２つ以上）除いたものでもよい。

【0046】

［システム機能］
次に、システム（１０００）の機能について、図７Ａ～７Ｆ、図８Ａ～８Ｅを参照して説明する。以下では、管理サーバー（１００）が死亡患者医療情報から病状情報を抽出し、抽出した病状情報を施設Ａのローカルコンピューティング装置（２００Ａ）からの病状情報取得要求に応じて送信する方法の一例を説明する。図７Ａ～７Ｆ及び図８Ａ～８Ｅに例示するスクリーンは、管理サーバー（１００）のＩ／Ｏインターフェース（１３０）上に表示される。ローカルコンピューティング装置（２００Ａ）のＩ／Ｏインターフェース（２３０Ａ）に表示されるスクリーンにおいても、ネットワークを通じて類似の動作が行われてよい。

【0047】

施設Ａのユーザーは、患者の家族に尋ねる又はその他様々な方法を通じて患者の死亡を確認しうる。ユーザーは、図７Ａに示すログインスクリーンの所定欄にユーザーＩＤとパスワードを入力することにより、ローカルコンピューティング装置（２００Ａ）を通じて管理サーバー（１００）にログインする。ログインすると、ユーザーは図７Ｂに示すメニュースクリーンに導かれる。

【0048】

図７Ｂのメニュースクリーン上でユーザーが患者ボタンをクリックすると、ユーザーは図７Ｃに示す患者情報スクリーンに導かれる。患者情報スクリーンは、患者身元特定情報の欄を含む。患者身元特定情報の欄は、姓、名、患者ＩＤ、生年月日（ＤＯＢ）、社会保障番号（ＳＳＮ）、電話番号、住所及びｚｉｐコードを含む。図７Ｃの患者情報スクリーンが表示されると、ユーザーは死亡患者の患者身元特定情報を入力する。

【0049】

ローカルコンピューティング装置（２００Ａ）から死亡患者の患者身元特定情報を受信すると、管理サーバー（１００）のプロセッサ（１１０）は、患者身元特定情報をキーとして用いて記憶部（１２０）内で死亡患者医療情報を検索し、死亡患者医療情報をユーザーに表示する。例えば、ユーザーが「Ｓｍｉｔｈ」といった患者身元特定情報を姓の欄に入力し、検索ボタンをクリックすると、検索要求がローカルコンピューティング装置（２００Ａ）からサーバー（１００）に送信される。それに応じて、図７Ｄに示すように、姓が「Ｓｍｉｔｈ」である患者の医療情報が箇条書きで一覧表示される。ユーザーが１つのファイル（例：「Ｓｍｉｔｈ，Ｔｏｄｄ」のファイル）をクリックすると、図７Ｅに示すように、「Ｓｍｉｔｈ，Ｔｏｄｄ」の死亡患者医療情報が編集スクリーンに表示される。

【0050】

図７Ｅに示すように、編集スクリーンは、施設、アカウント番号、名前、生年月日、喫煙状況、人種／民族、医師、自宅住所、現状（死亡／生存）、性別、身長、体重、及び言語といった入力欄を有する。各入力欄は、死亡患者の患者身元特定情報に対応する。加えて、ユーザーが入力欄を編集してもよい。

【0051】

図７Ｆに示すように、ユーザーが編集スクリーン上で所定のボタン（例：ＥｎｔｅｒボタンやＥｘｉｔボタン）をクリックすると、死亡情報を登録するかを問うポップアップメニューが表示される。もしキャンセルボタンをクリックすると、ユーザーは編集スクリーンに戻される。もしＮＯボタンをクリックすると、プロセッサ（１１０）は既存の現状情報のみを記憶部（１２０）に登録し、ユーザーは図８Ａに示す抽出スクリーンに導かれる。もしＹＥＳボタンをクリックすると、入力スクリーンが別途表示され（非図示）、ユーザーはそこで死亡情報を入力することができる。入力された死亡情報を受信すると、プロセッサ（１１０）は死亡情報を記憶部（１２０）に保存し、死亡情報を抽出スクリーンに表示する。これにより、死亡情報を、死亡患者医療情報の一部として利用することが可能となる。死亡情報が入力されなかった場合でも、少なくとも既存の現状情報は登録される。これにより、医療情報の中から死亡患者医療情報を検索することが可能となる。

【0052】

図８Ａの抽出スクリーンが表示されると、プロセッサ（１１０）は、死亡患者医療情報が所定情報を含むかどうか判断する処理を開始する。所定情報は、死亡患者の病状を特定するために用いることができる。プロセッサは、ユーザーから開始コマンドを受信した後にこの判断処理を開始してもよい。例えば、プロセッサ（１１０）は、ユーザーが図８Ａの具体的要因ボタン又は図８Ｂの病歴ボタンを押した後に判断処理を開始してもよい。あるいは、プロセッサは、患者が死亡した旨の情報を受信したら（例：図７Ｆの入力スクリーンで入力された死亡情報を受信したら）自動的に判断処理を開始してもよい。

【0053】

図１を参照して説明したように、一以上の実施形態において、所定情報は、死亡患者の具体的死因についての情報及び／又は病歴情報を含みうる。具体的死因は、例えば、患者の死亡の起因として特定された疾患、患者が死亡する直前まで患っていた疾患、患者が死亡するまで一定期間（例：３カ月）患っていた疾患、患者が巻き込まれた事故、自殺等の情報でありうる。病歴情報は、疾患部位、疾患に関連した医療画像、診断レポート、患者の手術歴、患者の治療期間・記録、患者の薬歴等を含みうる。

【0054】

プロセッサ（１１０）は、死亡患者医療情報が所定情報を含むかどうか判断する。判断は、一以上の特定の疾患名（例：大動脈閉塞による脳梗塞）及び／又は特定の疾患コード（例：特定の文字や数字の組み合わせであって、それぞれ死因となりうる疾患を特定するもの（例：癌、心臓疾患、脳血管障害（ＣＶＤ）等）を死亡患者医療情報内で検索することにより判断される。特定の疾患名及び特定の疾患コードは、医療情報の所定の欄に保存されている。

【0055】

死亡患者医療情報が所定情報を含まないと判断した場合、プロセッサ（１１０）は、死亡患者医療情報を記憶部（１２０）から削除する。これにより、システム（１０００）内のメモリ空間を都合良く確保することができる。患者が死亡した後、ユーザー（例：医師）はこのような死亡患者医療情報を必要としないためである。

【0056】

反対に、死亡患者医療情報が所定情報を含むと判断した場合、プロセッサ（１１０）は、死亡患者医療情報から所定情報及び死亡患者の患者身元特定情報を抽出する。抽出を終了すると、プロセッサ（１１０）は、抽出した所定情報と患者身元特定情報を抽出スクリーンに表示する。プロセッサ（１１０）は次に、抽出した所定情報と患者身元特定情報を、死亡患者の病状情報として記憶部（１２０）に別々に記憶し、残りの死亡患者医療情報を削除する。

【0057】

さらに、死亡患者医療情報が所定情報を含むと判断した後、プロセッサ（１１０）はタイマーを開始し、タイマーの開始から所定時間が経過したかどうか判断する。所定時間は、Ｉ／Ｏインターフェース（１３０）を通じて設定され記憶部（１２０）に記憶されていてよい。所定時間が経過すると、プロセッサ（１１０）は、この死亡患者医療情報を医療検査や治療に必要とされない比較的有用でない情報として類別し、所定情報が抽出されたかどうかに関わらず、死亡患者医療情報を削除する。これにより、ユーザーにとって有用と思われる情報のみを保持することとなり、システム（１０００）内のメモリ空間を都合良く確保することができる。特に、所定のアイテムは死亡患者の病状を特定するものであるが、これは死亡患者の家族に対する治療や診断に有用となりうる（例：死亡患者の病状が遺伝する場合に家族の状態を判断する等）。

【0058】

一以上の実施形態において、図１を参照して上述したように、所定情報は、診断レポート、疾患に関連した医療画像及び／又は薬歴といった特定のアイテムを含みうる。診断レポートは、医師によって作成された既存の医療レポートであり、死亡患者が患っていた疾患の状況を含むものである。疾患は、死亡患者が生涯患っていた疾患でありうるが、患者の死因となった疾患に限られない。医療画像は、一枚の医療画像又は一セットの複数枚の医療画像であり、診断レポートに記載の各疾患に関して撮影されたものであってよい。薬歴は、診断レポートに記載の疾患に関して患者に施された医薬及び服薬指導の記録（例：投薬レポート）であってよい。

【0059】

一以上の実施形態において、プロセッサ（１００）は、特定のアイテムを探すための入力をユーザーから受信してもよい。図８Ａに示す抽出スクリーンは、ユーザーが抽出時に特定のアイテムを探せるようにするための選択肢を備える（例：具体的要因ボタン及び病歴ボタン）。さらに抽出スクリーンは、ユーザーが所定情報の中から探すべき特定のアイテムの種類を選択するための選択肢を備える。例えば図８Ａに示すように、抽出スクリーンは、医療レポートの一覧を表示するレポートタブを備える。レポートタブ下の医療レポートは、特定のアイテムとして適切な診断レポートの例である。さらに、図８Ａにおいて、ユーザーはレポートタブ下の全ての医療レポートを選択している。その結果、プロセッサ（１１０）は、所定のアイテムにおいてこれら選択された医療レポートを探し、見つかった場合は医療レポートを抽出する。他の例として、ユーザーは図８Ｂの抽出スクリーン上の画像タブをクリックし、所定情報内で探すべき特定の医療画像を選択してもよい。さらに他の例として、ユーザーは図８Ｂの医薬タブをクリックし、死亡した患者の薬歴に関する特定の情報（例：投薬レポート）を所定情報内で探してもよい。一以上の実施形態においては、選択された医療レポート、医療画像及び薬歴のみを探して所定情報から抽出する。プロセッサ（１００）が抽出を完了すると、選択されなかったアイテムは全て死亡患者医療情報とともに削除される。これにより、ユーザーが将来の治療や診断に有用と考える特定の情報（例：ユーザーが選択した特定のアイテム）のみを保持しつつ、システム（１０００）内のメモリ空間を都合良く確保することができる。特に、特定のアイテムは死亡患者の病状を特定するものであるが、これは死亡患者の家族に対する治療や診断に有用となりうる（例：死亡患者の病状が遺伝する場合に家族の状態を判断する等）。

【0060】

一以上の実施形態において、レポートタブ、画像タブ及び医薬タブの下に表示されるアイテムは、具体的要因ボタンと病歴ボタンのいずれが選択されているかに応じて変化する。例えば、図８Ａに示すように具体的要因ボタンのみが選択されている場合、レポート、画像及び医薬タブの下には、死亡患者の具体的死因に関連するものとして予め分類されたアイテムのみが表示される。他方で、図８Ｂに示すように病歴ボタンのみが選択されている場合、死亡患者の病歴全体に含まれる全てのアイテムが特定される。ここでは、死亡患者の具体的死因に関連するものとして事前に分類されたアイテムも含まれる。しかしながら、具体的要因ボタンを選択しなければ、ユーザーはどのアイテムが死亡患者の具体的死因に対応するものなのか知ることがない。一以上の実施形態において、具体的要因ボタン及び病歴ボタンは同時に有効とすることができる。

【0061】

一以上の実施形態において、抽出が完了すると、プロセッサ（１１０）は図８Ｃに示すポップアップスクリーンを表示する。ポップアップスクリーンは、病状情報を保存・匿名化するかどうかユーザーに尋ねるものである。ユーザーがキャンセルボタンをクリックすると、処理は、抽出された病状情報を保存したり死亡患者医療情報を削除することなく、抽出スクリーンに戻る。ユーザーがＯＫボタンをクリックすると、プロセッサ（１１０）は抽出された病状情報を別途記憶部（１２０）に保存し、残りの死亡患者医療情報を記憶部（１２０）から削除する。

【0062】

一以上の実施形態において、ユーザーが図８Ｃのポップアップスクリーン上でＯＫボタンをクリックすると、プロセッサ（１１０）は病状情報を匿名化する。図８Ｅに示すように、病状情報は、患者名を死亡日に置き換えることで匿名化されうる。また、病状情報は、生年月日のうち月と日を予め選択された日付（例：１月１日）に置き換えつつ、年を誕生年のままとしておく（例）：１９ＸＸ）ことで匿名化されてもよい。誕生年を保持することで、誕生した月と日を隠しつつ、死亡患者のおおよその年齢を特定することができる。病状情報の匿名化により、病状情報の利用を可能にしつつ死亡患者のプライバシーを保護することができる。

【0063】

一以上の実施形態において、プロセッサ（１１０）は、病状情報の保存と残りの死亡患者医療情報の削除とを別のタイミングで行ってもよい。言い換えれば、残りの死亡患者医療情報は、プロセッサ（１１０）が病状情報の抽出と別途保存を終えた後、ただちに自動的に削除されない。一以上の実施形態において、残りの死亡患者医療情報は抽出完了後ただちに自動的に削除されないが、この場合、残りの死亡患者医療情報はユーザーが手動で削除してもよい。例えば、ユーザーは図８Ａ、８Ｂに示す全削除ボタンをクリックして、残りの死亡患者医療情報を手動で削除してもよい。この例において、ユーザーは図８Ａ～８Ｃに示す匿名化ボタンを手動でクリックし、病状情報を匿名化してもよい。あるいは、図８Ｃに示すポップアップスクリーンは、ユーザーに対して病状情報を匿名化するかどうかを尋ねるオプションのみを含む。

【0064】

病状情報を保存し匿名化した後、病状情報取得要求をローカルコンピューティング装置（２００Ａ）から受信すると、プロセッサ（１１０）は匿名化された病状情報を取得する。一以上の実施形態において、図８Ｄの検索スクリーンは「死亡患者の情報を含む」というチェックボックスを備える。病状情報の検索前にユーザーがチェックボックスをオンにすると、匿名化された病状情報も取得されて検索スクリーンに表示される。具体的には、匿名化された病状情報は、チェックボックスが有効である（オンである）場合のみ取得される。ユーザーが診察／治療を行いつつ、表示されている匿名化された病状情報の１つをクリックすると、図８Ｅに示すように、選択された匿名化された病状情報が編集スクリーンに表示される。

【0065】

一以上の実施形態において、図７Ａ～７Ｆ及び図８Ａ～８Ｅのスクリーンはどの言語で表示されてもよい（例：日本語、ドイツ語、英語等）。記憶部（１２０）に保存される医療情報もまた、どの言語で保存されてもよい。プロセッサ（１００）は、ユーザーが入力した検索キーワードを自動翻訳し、対応する医療情報をデータベース内で見つけてもよい。

【0066】

図９は、記憶部（１２０）のデータベースに保存されている表が提示する匿名化された病状情報の一例である。図９は図２の表に対応するものであるが、ライフフラグの行と病歴フラグの行が削除され、新たに医療画像の行が追加されている。図２における患者２の元々の医療情報は、図９では、患者２の匿名化された病状情報に置き換えられている。具体的には、患者名の行の元々のデータ（すなわち図２の「Ｔｉｍ」）は、患者２の死亡日となっている。加えて、患者の元々の生年月日は、患者２の実際の誕生年及び事前に選択された日付（１／１）となっている。新たに追加された医療画像の行は、所定情報又は特定のアイテムとしての医療画像を含む。医療画像は、患者２の死亡患者医療情報から抽出されたものである。

【0067】

図９はまた、死亡患者の医療情報が完全に削除された例も示す。図２を見ると、患者３（Ｊｅｎｎｙ）は死亡しており（ライフフラグの値が「２」）、以前に深刻な疾患は患っていない（病歴フラグの値が「２」）。さらに、病状情報抽出処理の間、所定情報は見つからなかった。従って、患者３の医療情報は全て記憶部（１２０）から削除される。

【0068】

［削除の制御方法］
図１０は、一以上の実施形態にかかるフローチャートを示す。図１０内の１つ以上のステップは、図１を参照して説明したシステム（１０００）の構成要素によって実行されうる。一以上の実施形態において、図１０の１つ以上のステップを省略、反復、及び／又は図１０に示される順序と異なる順序で実行してもよい。従って、本発明の範囲は、図１０に示される具体的なステップの並びに限定されるものではない。

【0069】

ステップＳ１００１において、プロセッサ（１１０）は死亡患者の患者身元特定情報を検索要求として受信し、患者身元特定情報をキーとして、記憶部（１２０）内で死亡患者医療情報を探す（ステップＳ１００１）。一以上の実施形態において、取得された死亡患者医療情報はＩ／Ｏインターフェース（１３０）にも表示される。

【0070】

ステップＳ１００２において、プロセッサ（１１０）は死亡情報を受信したか判断する。同時に、プロセッサ（１１０）は現状情報を受信したか判断する。死亡情報を受信すると（ステップＳ１００２：ＹＥＳ）、プロセッサ（１１０）は死亡情報を記憶部（１２０）に保存する（ステップＳ１００３）。死亡情報は受信しなかったが現状情報は受信した場合（ステップＳ１００２：ＮＯ）、プロセッサ（１００）は、現状情報のみを記憶部（１２０）に保存する（ステップＳ１００４）。

【0071】

ステップＳ１００５において、プロセッサ（１１０）は、死亡患者医療情報が所定情報を含むかどうか判断する。一以上の実施形態において、プロセッサ（１１０）は、ユーザーから開始コマンドを受信した後でステップＳ１００５の判断を開始する。例えば、プロセッサ（１１０）は、ユーザーが図８Ａの具体的要因ボタン又は図８Ｂの病歴ボタンを押した後に判断処理を開始してもよい。あるいは、プロセッサは、患者が死亡した旨の情報を受信したら（例：図７Ｆの入力スクリーンで入力された死亡情報を受信したら）、自動的に判断処理を開始してもよい。

【0072】

死亡患者医療情報が所定情報を含まない場合（ステップＳ１００５：ＮＯ）、プロセッサ（１１０）は、死亡患者医療情報を記憶部（１２０）から削除する（ステップＳ１００６）。

【0073】

死亡患者医療情報が所定情報を含む場合（ステップＳ１００５：ＹＥＳ）、プロセッサ（１１０）はタイマーを開始し、タイマー開始から所定時間が経過したかどうか判断する（ステップＳ１００７）。所定時間が経過した場合（ステップＳ１００７：ＹＥＳ）、プロセッサ（１１０）は、所定情報が抽出されたかどうかに関わらず死亡患者医療情報を削除する（ステップＳ１００６）。

【0074】

所定時間が経過していない場合（ステップＳ１００７：ＮＯ）、プロセッサ（１１０）は、死亡患者医療情報から所定情報及び死亡患者の患者身元特定情報を抽出し、抽出した所定情報及び患者身元特定情報を病状情報としてＩ／Ｏインターフェース（１３０）に表示する（ステップＳ１００８）。

【0075】

ステップＳ１００９において、特定のアイテムの入力をユーザーから受信すると、プロセッサ（１１０）は、所定情報が特定のアイテムを含むかどうか判断する。所定情報が特定のアイテムを含まない場合（ステップＳ１００９：ＮＯ）、処理はステップＳ１０１１に進む。所定情報が特定のアイテムを含む場合（ステップＳ１００９：ＹＥＳ）、プロセッサ（１１０）は、所定情報から特定のアイテムを抽出し、抽出した特定のアイテムを所定情報の代わりに病状情報として表示する（ステップＳ１０１０）。

【0076】

ステップＳ１０１１において、プロセッサ（１１０）は、Ｉ／Ｏインターフェース（１３０）を通じたユーザー入力に基づき、病状情報を保存及び匿名化するかどうか判断する。病状情報を保存及び匿名化しないと判断した場合（ステップＳ１０１１：ＮＯ）、プロセッサ（１１０）は処理を終了する。

【0077】

病状情報を保存及び匿名化すると判断した場合（ステップＳ１０１１：ＹＥＳ）、プロセッサ（１１０）は（ステップＳ１０１２にいて）病状情報を保存及び匿名化し、残りの死亡患者医療情報を記憶部（１２０）から削除する。

【0078】

病状情報を保存・匿名化した後、ステップＳ１０１３において、プロセッサ（１１０）は、ローカルコンピューティング装置（２００Ａ）から病状情報取得要求を受信したかどうか判断する（ステップＳ１０１３）。病状情報取得要求を受信していないと判断した場合（ステップＳ１０１３：ＮＯ）、プロセッサ（１１０）は処理を終了する。病状情報取得要求を受信したと判断した場合（ステップＳ１０１３：ＹＥＳ）、プロセッサ（１１０）はステップＳ１０１４において、匿名化された病状情報をローカルコンピューティング装置（２００Ａ）に送信する。一以上の実施形態において、ローカルコンピューティング装置（２００Ａ）のプロセッサ（２１０Ａ）は、ローカルコンピューティング装置（２００Ａ）のＩ／Ｏインターフェース（２３０Ａ）上に、受信した匿名化された病状情報を表示する。

【0079】

本発明の実施形態は、使用するプラットフォームにかかわらず、ほぼあらゆる種類のコンピューティングシステムに実装できる。例えば、コンピューティングシステムは、一つ以上の可搬装置（例えば、ノート型コンピュータ、スマートフォン、パーソナルデジタルアシスタント、タブレット型コンピュータ又はその他の可搬装置）、デスクトップコンピュータ、サーバー、サーバーシャーシにおけるブレード、又は一つ以上の実施形態を実施するための最低限の処理能力、メモリ及び入出力装置を少なくとも備えるその他の種類の一つ以上のコンピューティング装置であってよい。例えば図１１に示すように、コンピューティングシステム（１１０１）は、一つ以上のコンピュータプロセッサ（１１０２）、関連するメモリ（１１０３）（例：ランダムアクセスメモリ（ＲＡＭ）、キャッシュメモリ、フラッシュメモリ等）、一つ以上の記憶装置（１１０４）（例えば、ハードディスク、コンパクトディスク（ＣＤ）ドライブやデジタル多用途ディスク（ＤＶＤ）ドライブといった光ドライブ、フラッシュメモリスティック等）、その他多くの構成要素及び機能を有してよい。コンピュータプロセッサ（１１０２）は、指示を処理するための集積回路でもよい。例えば、コンピュータプロセッサは、一つ以上のコア又はプロセッサのマイクロコアでもよい。また、コンピューティングシステム（１１０１）は、タッチスクリーン、キーボード、マウス、マイク、タッチパッド、電子ペン、又はその他の種類の入力装置といった入力装置（１１０６）を一つ以上備えてよい。また、コンピューティングシステム（１１０１）は、スクリーン（例えば、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、タッチスクリーン、ブラウン管（ＣＲＴ）モニター、プロジェクター、又はその他の表示装置）、プリンター、外部記憶装置、又はその他の出力装置といった出力装置（１１０５）を一つ以上備えてよい。出力装置のうち一つ以上が入力装置と同じであっても良いし、異なってもよい。コンピューティングシステム（１１０１）は、ネットワークインターフェース接続（図示なし）を介してネットワーク（１１０７）（例えば、ローカルエリアネットワーク（ＬＡＮ）、インターネット等の広域ネットワーク（ＷＡＮ）、モバイルネットワーク、又はその他の種類のネットワーク）に接続されてよい。入力装置及び出力装置は、ローカルに又はリモートに（例えば、ネットワーク（１１０７）を介して）コンピュータプロセッサ（１１０２）、メモリ（１１０３）及び記憶装置（１１０４）に接続されてよい。コンピューティングシステムには多くの様々な種類があり、前述の入力装置及び出力装置は他の形態をとってもよい。

【0080】

本発明の実施形態を実施するためのコンピュータ読取り可能なプログラムコードの形態をとるソフトウェア指示は、全て又は一部が、一時的に又は恒久的に、ＣＤ、ＤＶＤ、記憶装置、ディスケット、テープ、フラッシュメモリ、物理メモリ、又はその他のコンピュータ読取り可能な記憶媒体といった非一時的なコンピュータ読取り可能な媒体に記憶されてよい。具体的には、ソフトウェア指示は、プロセッサによって実行された際に本発明の実施形態を実施するように構成された、コンピュータ読取り可能なプログラムコードに相当し得る。

【0081】

更に、前述のコンピューティングシステム（１１０１）の構成要素は、そのうち一つ以上が遠隔に配され、ネットワーク（１１０７）を介してその他の構成要素と接続されてもよい。更に、本発明の一つ以上の実施形態は、複数のノードを有する分散システムに実装されてもよく、本発明の各部は、分散システム内の異なるノード上に配置されてもよい。本発明の一実施形態では、ノードは別個のコンピューティング装置に相当する。あるいは、ノードは関連する物理メモリを有するコンピュータプロセッサに相当し得る。あるいは、ノードは、共有メモリ及び／又は情報源を有するコンピュータプロセッサ又はコンピュータプロセッサのマイクロコアに相当し得る。

【0082】

一以上の実施形態における管理サーバー、方法及び非一時的なコンピュータ読み取り可能な媒体は、医療分野の情報管理技術を様々な形で向上させる。

【0083】

例えば、患者が死亡した後、死亡患者医療情報から医師にとって有用な情報（例：死因に関する情報及び／又は病歴情報）を抽出した後で、死亡患者医療情報を削除することにより、医療情報を保存するクラウドサーバー及び／又はローカルサーバーのメモリ空間を都合よく確保することができる。

【0084】

また、死因に関する情報及び／又は病歴情報のみを保持することにより、死亡患者の主な治療医師及び／又は死亡患者の記録を確認する他の医師が、死亡患者医療情報を確認する時間を向上させることができる。

【0085】

さらに、患者の死亡後、こうした情報を残しつつ他の残りの情報を削除することにより、死亡患者の家族に対する診断時間や診断効果を向上させることができる。例えば、死亡患者の家族の治療を担当する医師は、死亡患者の死因及び病歴を参照することによって、死亡患者の家族が抱える病気／疾患を適時に正確に特定することができる（例：高血圧、糖尿病、ＨＩＶ等）。さらに、抽出した情報を匿名化することにより、抽出した情報の利用を可能としつつ死亡患者のプライバシーを保護することができる。

【0086】

限られた数の実施形態を参照して本発明を説明したが、本開示の恩恵に浴する当業者であれば、ここで開示された本発明の範囲から逸脱しない他の実施形態が考案可能であると分かるだろう。したがって、本発明の範囲は、添付の特許請求の範囲によってのみ限定されるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図7C】

【図7D】

【図7E】

【図7F】

【図8A】

【図8B】

【図8C】

【図8D】

【図8E】

【図9】

【図10】

【図11】

【外国語明細書】