(57)【要約】【課題】  オープンなインターネット環境に対してセキュリティを向上させ、医療データの活用を推進し、災害復旧に迅速に対応できる医療クラウドシステムを提供する。【解決手段】  集約されたグローバルＩＰアドレスが割り当てられた医療クラウドネットワーク１とオープンなインターネット１０との間に医療クラウド用ファイアウォール２を設け、医療クラウド用運用サーバ３が、医療クラウドネットワーク１におけるセキュリティポリシーを管理して設定して、災害発生時に、ＱｏＳ情報を医療クラウド用ファイアウォール１に設定して、インターネットサービスプロバイダ間を相互接続する相互接続ポイントにＱｏＳ情報をアナウンスし、設定されたセキュリティポリシーとＱｏＳ情報に基づいてネットワークを運用する医療クラウドシステムである。【選択図】        図１
2013134711.tif 000002
【特許請求の範囲】
【請求項１】
医療関連のクラウドシステムであって、
集約されたグローバルＩＰアドレスが接続するクライアント装置に割り当てられた医療クラウドネットワークと、
前記医療クラウドネットワークと外部のインターネットとの間に設けられた医療クラウド用ファイアウォールと、
前記医療クラウドネットワークにおけるセキュリティポリシーを管理して前記医療クラウド用ファイアウォールに設定し、災害発生時に、ＱｏＳ情報を前記医療クラウド用ファイアウォールに設定して、インターネットサービスプロバイダ間を相互接続する相互接続ポイントに前記ＱｏＳ情報をアナウンスし、設定された前記セキュリティポリシーと前記ＱｏＳ情報に基づいてネットワークを運用する医療クラウド用運用サーバとを有することを特徴とする医療クラウドシステム。
【請求項２】
医療クラウド用運用サーバは、災害発生時に、重要な医療データの送受信を行うことが設定されていれば、ＱｏＳ制御を実行して前記重要な医療データの送受信を行わせることを特徴とする請求項１記載の医療クラウドシステム。
【請求項３】
医療クラウド用運用サーバは、ルートに障害が発生した場合に障害のあるルートを回避できない場合に、障害箇所のルートとルータを特定し、復旧すべきルート情報として管理者宛に通知することを特徴とする請求項１又は２記載の医療クラウドシステム。
【請求項４】
医療クラウドネットワークには、医療機関用ファイアウォールが接続され、当該医療機関用ファイアウォールに接続する医療機関内のクライアント装置にはローカルアドレスが割り当てられており、前記医療機関用ファイアウォールは、ローカルアドレスから集約されたグローバルＩＰアドレスに変換を行うことを特徴とする請求項１乃至３のいずれか記載の医療クラウドシステム。
【請求項５】
医療クラウド用運用サーバは、災害発生時に、ＱｏＳ情報を医療機関用ファイアウォールに設定して、設定された前記ＱｏＳ情報に基づいてＱｏＳ制御を実行することを特徴とする請求項４記載の医療クラウドシステム。
【請求項６】
医療クラウドネットワークには、電子カルテのデータベースに接続し、クライアント装置に対して前記電子カルテのデータベースへのアクセスを制御する電子カルテ管理サーバが複数設けられ、前記各電子カルテ管理サーバに接続する前記電子カルテのデータベースに格納される医療データはバックアップとして同じデータが記憶されることを特徴とする請求項１乃至５のいずれか記載の医療クラウドシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、医療関係のネットワークシステムに係り、特に、医療データの活用を図ると共にセキュリティを向上させ、更に災害復旧に迅速に対応できる医療クラウドシステムに関する。
【背景技術】
【０００２】
［従来の技術］
［インターネットの課題］
インターネットは、様々なユーザが利用できる利便性を備えている反面、不正アクセス、サイバー攻撃等のセキュリティの問題がある。
また、ネットワーク機器には特定の通信に対して優先的に帯域を割り当てるＱｏＳ（Quality of Service）と呼ばれる機能が備えられている。しかしながら、このＱｏＳの機能をインターネットサービスプロバイダ（ＩＳＰ）間で扱うルールが制定されておらず、エンドツーエンドで帯域を確保することは困難である。
【０００３】
具体的には、ＱｏＳ制御は、ＩＳＰ間のファイアウォールの互換性や制御プロトコルの互換性によりエンドツーエンドで帯域優先制御や制御スケジューリングを行うことが困難である。
更に、ＩＰｖ４アドレスの枯渇により、ＩＳＰ間の細分化によるＩＳＰ間の経路情報交換処理の過負荷による一時的なサービス品質の低下が懸念されている。
【０００４】
［医療ネットワークの課題］
平成１７年３月に公開された「医療情報安全管理に関するガイドライン」には、医療・介護関係事業者における個人情報の適切な取り扱い、情報システム導入及びそれに伴う外部保存を行う場合の取り扱いが示されている。その後の改訂により、医療機関のネットワークを定義し、医療情報に関する安全管理基準が示されている。
【０００５】
しかしながら、上述したように、インターネットのセキュリティの問題から、インターネットを利用した医療関連のネットワーク構築が進んでおらず、電子カルテ、レセプト等の電子データの活用が十分になされていない状況にある。
また、災害時を考慮した電子データのバックアップ、迅速なる復旧対応も為されていない現状にある。
【０００６】
［関連技術］
尚、関連する従来の医療関連のネットワークに関する先行技術として、特開２００３−１９６３８６号公報「双方向通信ネットワークによる医療情報提供・取得システム及び方法並びにコンピュータプログラム」（株式会社亀田医療情報研究所）［特許文献１］、特開２００５−２６７３５８号公報「地域医療のための電子カルテ作成・管理システム及びその運営方法」（株式会社日立メディコ）［特許文献２］がある。
【０００７】
特許文献１には、医療情報集中処理センター通信装置に患者データを転送しておき、患者が承諾した場合に、他の医療機関通信装置から患者データの転送を要求し、当該データを参照可能とすることが記載されている。
【０００８】
特許文献２には、在宅患者の遠隔診療を行い、医療機関の端末装置は診察中の音声をデータとして地方医師会等のローカルエリア内に設けられた電子カルテセンターのサーバで保存・管理することが記載されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００３−１９６３８６号公報
【特許文献２】特開２００５−２６７３５８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
上述したように、インターネットにおけるセキュリティの問題、ＱｏＳ機能の活用の困難性、ＩＰｖ４アドレス枯渇によるＩＳＰ間の経路情報交換処理における過負荷等の問題点があった。
【００１１】
更に、インターネットの問題点に加えて、医療ネットワークの課題から、電子カルテ等の電子データの活用と、ネットワーク構築が進んでいないという問題点があった。
【００１２】
本発明は上記実状に鑑みて為されたもので、オープンなインターネット環境に対してセキュリティを向上させ、医療データの活用を推進し、災害復旧に迅速に対応できる医療クラウドシステムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記従来例の問題点を解決するための本発明は、医療関連のクラウドシステムであって、集約されたグローバルＩＰアドレスが接続するクライアント装置に割り当てられた医療クラウドネットワークと、医療クラウドネットワークと外部のインターネットとの間に設けられた医療クラウド用ファイアウォールと、医療クラウドネットワークにおけるセキュリティポリシーを管理して医療クラウド用ファイアウォールに設定し、災害発生時には、ＱｏＳ情報を医療クラウド用ファイアウォールに設定して、インターネットサービスプロバイダ間を相互接続する相互接続ポイントにＱｏＳ情報をアナウンスし、設定されたセキュリティポリシーとＱｏＳ情報に基づいてネットワークを運用する医療クラウド用運用サーバとを有することを特徴とする。
【００１４】
本発明は、上記医療クラウドシステムにおいて、医療クラウド用運用サーバが、災害発生時に、重要な医療データの送受信を行うことが設定されていれば、ＱｏＳ制御を実行して重要な医療データの送受信を行わせることを特徴とする。
【００１５】
本発明は、上記医療クラウドシステムにおいて、医療クラウド用運用サーバが、ルートに障害が発生した場合に障害のあるルートを回避できない場合に、障害箇所のルートとルータを特定し、復旧すべきルート情報として管理者宛に通知することを特徴とする。
【００１６】
本発明は、上記医療クラウドシステムにおいて、医療クラウドネットワークには、医療機関用ファイアウォールが接続され、当該医療機関用ファイアウォールに接続する医療機関内のクライアント装置にはローカルアドレスが割り当てられており、医療機関用ファイアウォールが、ローカルアドレスから集約されたグローバルＩＰアドレスに変換を行うことを特徴とする。
【００１７】
本発明は、上記医療クラウドシステムにおいて、医療クラウド用運用サーバが、災害発生時に、ＱｏＳ情報を医療機関用ファイアウォールに設定して、設定されたＱｏＳ情報に基づいてＱｏＳ制御を実行することを特徴とする。
【００１８】
本発明は、上記医療クラウドシステムにおいて、医療クラウドネットワークには、電子カルテのデータベースに接続し、クライアント装置に対して電子カルテのデータベースへのアクセスを制御する電子カルテ管理サーバが複数設けられ、各電子カルテ管理サーバに接続する電子カルテのデータベースに格納される医療データはバックアップとして同じデータが記憶されることを特徴とする。
【発明の効果】
【００１９】
本発明によれば、集約されたグローバルＩＰアドレスが接続するクライアント装置に割り当てられた「医療クラウドネットワーク」と、医療クラウドネットワークと外部のインターネットとの間に設けられた「医療クラウド用ファイアウォール」と、医療クラウドネットワークにおけるセキュリティポリシーを管理して医療クラウド用ファイアウォールに設定し、災害発生時に、ＱｏＳ情報を前記医療クラウド用ファイアウォールに設定して、インターネットサービスプロバイダ間を相互接続する相互接続ポイントに前記ＱｏＳ情報をアナウンスし、設定された前記セキュリティポリシーと前記ＱｏＳ情報に基づいてネットワークを運用する「医療クラウド用運用サーバ」とを有する医療クラウドシステムとしているので、インターネット環境に対してセキュリティを向上させ、医療データの活用を推進し、災害復旧に迅速に対応でき、集約されたグローバルＩＰアドレスを用いているため、ＩＳＰ間の経路情報交換処理の過負荷を低減できる効果がある。
【図面の簡単な説明】
【００２０】
【図１】本発明の実施の形態に係る医療クラウドシステムの概略図である。
【図２】医療クラウド用運用サーバにおける災害対応処理のフローチャートである。
【発明を実施するための形態】
【００２１】
本発明の実施の形態について図面を参照しながら説明する。
［（１）実施の形態の概要］
本発明の実施の形態に係る医療クラウドシステムは、集約されたグローバルＩＰアドレスが割り当てられた医療クラウドネットワークとオープンなインターネットとの間に医療クラウド用ファイアウォールを設け、医療クラウド用運用サーバが、医療クラウドネットワークにおけるセキュリティポリシーを管理し、設定して、オープンなインターネットの環境に対してセキュリティを向上させ、医療データを集中的に管理し、また、医療クラウド用運用サーバが、医療クラウドネットワーク内の全ルート情報を管理しているので、ＱｏＳ制御の実現が容易であり、大容量のデータの送受信や緊急の医療データを迅速かつ確実に送受信でき、集約されたグローバルＩＰアドレスを有するネットワークとしているので、災害時に強いネットワークの運用が可能である。
【００２２】
また、医療クラウドシステムのアプリケーションとして、電子カルテ管理サーバが、電子カルテデータベースに対するアクセス権限を管理しているので、医療情報の保護を図りつつ、電子カルテの医療データを活用できるものである。
【００２３】
［（２）医療クラウドシステムの概略：図１］
本発明の実施の形態に係る医療クラウドシステム（本医療クラウドシステム）の概略について図１を参照しながら説明する。図１は、本発明の実施の形態に係る医療クラウドシステムの概略図である。
本医療クラウドシステムは、図１に示すように、医療クラウドネットワーク１と、医療クラウドネットワーク１と一般のオープンなインターネット１０を隔てる医療クラウド用ファイアウォール（ＦＷ（１））２と、医療クラウドネットワーク１の監視・制御を行う医療クラウド用運用サーバ３と、電子カルテデータの入出力を制御する電子カルテ管理サーバ（１）４ａ，（ｎ）４ｂと、電子カルテデータを保存する電子カルテＤＢ（１）５ａ，（ｎ）５ｂと、医療クラウドネットワーク１と医療機関内クライアント７ａ，７ｂの間に設けられる医療機関ファイアウォール（ＦＷ（２Ａ））６ａ，（ＦＷ（２Ｂ））６ｂと、医療クラウドネットワーク１に直接接続する医療機関クライアント６ｃとから基本的に構成されている。
【００２４】
また、インターネット１０は、簡単に説明すると、複数のインターネットサービスプロバイダのネットワーク（ＩＳＰ：Internet Service Provider）１２と、ＩＳＰ１２を相互に接続する事業者のネットワーク（ＩＸＰ：Internet Exchange point Provider）１１と、ＩＳＰ１２に接続する複数の加入者端末１３とを一般的に有している。
【００２５】
ここで、医療クラウド用運用サーバ３と、電子カルテ管理サーバ（１）４ａ，（ｎ）４ｂと、医療機関内クライアント７ａ，７ｂと、医療機関クライアント６ｃと、加入者端末１３は、コンピュータ装置である。従って、内部に処理を実行する制御部（処理部）を備え、必要に応じて記憶部を備えている。
【００２６】
［（３）本医療クラウドシステムの各部］
［医療クラウドネットワーク１］
医療クラウドネットワーク１は、ＩＰ（Internet Protocol）アドレス領域が集約されたグローバルＩＰアドレス群（上位のアドレスブロックを共通とする特定グループに属するグローバルＩＰアドレス）が割り当てられたネットワークである。つまり、そのグループ内のグローバルＩＰアドレスは、医療クラウドネットワーク１内でのみ割り当てられ、他のネットワークには割り当てされないようにするものである。
【００２７】
［ＩＰアドレスの概略］
ＩＰアドレスのＩＰｖ４について説明すると、ＩＰアドレスは、３２ビットの数値（０，１の組み合わせの数値）として、ネットワークに参加する各端末に割り当てられるものである。
ただ、３２ビットの連続する数値では扱いづらいため、便宜上、８桁（８ｂｉｔ）毎に区切るオクテット区切りが用いられている。区切りには、「．」を挿入し、４分割される。
【００２８】
そして、４分割された区画をそれぞれ１０進数で表すようになっている。例えば、「１９２．１６８．１２３．４５」のようにＩＰアドレスを表現する。
各区画における数値は８ビットであるため、最低で「０」、最大で「２５５」の値をとることになる。
【００２９】
また、インターネットで使用されるＩＰネットワークは、様々なネットワークが繋がるネットワークの複合体であるため、ＩＰアドレスを、例えば、１番目の区画から３番目の区画までを「ネットワークアドレス」とし、４番目の区画を「ホストアドレス」として構成している。
【００３０】
つまり、あるコンピュータにメール等のパケットを送信する時、まず、ネットワークアドレス宛に送り出し、宛先のネットワークに到着してから宛先のコンピュータのホストアドレスを探してパケットを送信することになる。
【００３１】
［クラスの概念］
ＩＰアドレスには、アドレスクラスという分類方法がある。
クラスＡ（０．０．０．０〜１２７．２５５．２５５．２５５）は、最初の８ビットがネットワークアドレス、残り２４ビットがホストアドレスとなっている。但し、ネットワークアドレスの最初の１ビットは、識別のため「０」とすることが定められている。
【００３２】
クラスＢ（１２８．０．０．０〜１９１．２５５．２５５．２５５）は、最初の１６ビットがネットワークアドレス、残り１６ビットがホストアドレスとなっている。但し、ネットワークアドレスの最初の２ビットは、識別のため「１０」とすることが定められている。
【００３３】
クラスＣ（１９２．０．０．０〜２２３．２５５．２５５．２５５）は、最初の２４ビットがネットワークアドレス、残り８ビットがホストアドレスとなっている。但し、ネットワークアドレスの最初の３ビットは、識別のため「１１０」とすることが定められている。
【００３４】
クラスＤ（２２４．０．０．０〜２３９．２５５．２５５．２５５）は、クラスＡ〜Ｃのいずれのアドレスクラスにも該当しない特殊なクラスである。但し、最初の４ビットは、識別のため「１１１０」とすることが定められている。クラスＤの使用目的は、ＩＰマルチキャスト用である。
【００３５】
クラスＥ（２４０．０．０．０〜２５５．２５５．２５５．２５５）は、最初の４ビットが識別のため「１１１１」とすることが定められている。クラスＥは、実験用として予約されているが、実際に使われることがないものである。
【００３６】
但し、インターネットサービスプロバイダでは、ＩＰアドレスの割り当てを求めるのに、クラスＡでは大きすぎてクラスＣでは小さすぎるため、クラスＢに集中することになった。
クラスＢの割り当てを受けたネットワークの中にはＩＰアドレスが全て使用されることがまれで、無駄になることも多かった。そこで、現在では、アドレスクラスを使わずに、ネットワークアドレスとホストアドレスの境界を８ビット単位に固定せず、細分化するサブネットマスクやＣＩＤＥＲ（Classless Inter-Domain Routing）が一般化している。
【００３７】
ＩＰアドレスの割り当て範囲を示すために、ＩＰアドレスの末尾に「／」と共にネットワークアドレス長を付記してあれ和巣ことが多い。
例えば、ＩＰアドレスが「１２３．１００．１００．×××／２４」であるとすると、最初の２４ビットがネットワークアドレスであり、残り８ビットがホストアドレスということになる。
また、「／１８」と記述すれば、最初の１８ビットがネットワークアドレスであり、残り１４ビットがホストアドレスということになる。
【００３８】
［集約されたＩＰアドレス］
以上のように、アドレスクラス、サブネットマスク、ＣＩＤＥＲによって、ＩＰアドレスの割り当て範囲を特定してグループ化することができる。
このように、グループ化されたＩＰアドレスの集合を「集約されたグローバルＩＰアドレス」と定義する。集約されたグローバルＩＰアドレスは、ＩＰアドレスの割り当て範囲が特定され、その範囲のＩＰアドレスをグループ（群）として共通目的のために使用されるもので、他のユーザの使用を制限する。
【００３９】
集約されたグローバルＩＰアドレスでは、ＩＰアドレスが「１２３．１００．１００．×××／２４」の場合、先頭から２４ビットのネットワークアドレスを持ち、残り８ビット、つまり最後の「×××」部分がホストアドレスとなる。
従って、ネットワークアドレスを共通にするネットワークが医療クラウドシステムとして使用されるものであり、その医療クラウドシステムは、医療クラウド用ＦＷ（１）２で保護されており、医療クラウド用運用サーバ３で管理されている。
集約されたグローバルＩＰアドレスの効果は後述する。
【００４０】
［医療クラウド用ＦＷ（１）２］
医療クラウド用ＦＷ（１）２は、ファイアウォールシステムであり、オープンなインターネット１０の外部からのアクセスを制限し、医療クラウドネットワーク１から外部のオープンなインターネット１０に出力されるデータを制限し、また、外部から医療クラウドネットワーク１に送り込まれるデータも制限する。
【００４１】
医療クラウドネットワーク１内ではＩＰアドレスが集約されているため、医療クラウド用ＦＷ（１）２は、外部からのアクセス制限、データの入出力制限を容易に行うことができる。尚、アクセス制限、データの入出力制限は、医療クラウド用運用サーバ３から設定されたセキュリティポリシーに基づいて為される。
【００４２】
［医療クラウド用運用サーバ３］
医療クラウド用運用サーバ３は、医療クラウドネットワーク１内の種々の制御を行うものであり、特に、医療クラウド用ＦＷ（１）２に対するセキュリティポリシーの設定処理、ＱｏＳ機能の制御処理、災害対応処理を行う。各処理の詳細については、後述する。
【００４３】
［医療クラウドのアプリケーション］
以下に説明する電子カルテ管理サーバの処理、電子カルテＤＢの処理は、医療クラウドに組み込むことができるアプリケーションである。その他のアプリケーションとして、レセプトデータ管理サーバでの処理が考えられる。
【００４４】
［電子カルテ管理サーバ（１）４ａ，（ｎ）４ｂ］
電子カルテ管理サーバ（１）４ａ，（ｎ）４ｂは、医療クラウドネットワーク１内の認証された医療機関のクライアント（端末装置）から電子カルテの医療データを受信し、電子カルテＤＢ（１）５ａ，（ｎ）５ｂに電子カルテの医療データを格納する。
また、電子カルテ管理サーバ（１）４ａ，（ｎ）４ｂは、医療クラウドネットワーク１内の認証された医療機関のクライアントの要求により電子カルテＤＢ（１）５ａ，（ｎ）５ｂから電子カルテの医療データを読み出して提供する。
【００４５】
［電子カルテＤＢ（１）５ａ，（ｎ）５ｂ］
電子カルテＤＢ（１）５ａ，（ｎ）５ｂは、互いに離れた場所（同時に震災等に遭遇することがない程度、例えば２００ｋｍ以上に離れた場所）に設けられており、両ＤＢが同じデータを記憶している。一方が他方のバックアップとなっている。
尚、電子カルテＤＢ（１）５ａ，（ｎ）５ｂには、電子カルテの医療データに限らず、医療関連のデータを保存するようにしてもよい。
図１では、電子カルテ管理サーバを１〜ｎ、電子カルテＤＢを１〜ｎの例を示したが、医療クラウドシステムには任意の数接続可能である。
【００４６】
［医療機関ＦＷ（２Ａ）６ａ，（２Ｂ）６ｂ］
医療機関ＦＷ（２Ａ）６ａ，（２Ｂ）６ｂは、各医療機関内用のファイアウォールシステム（ファイアウォール装置）であり、医療クラウドネットワーク１と医療機関内クライアント７ａ，７ｂとの間に設けられ、グローバルＩＰアドレスとローカルアドレスの変換を行う。つまり、医療機関ＦＷ（２Ａ）６ａ，（２Ｂ）６ｂより上位のネットワーク（医療クラウドネットワーク１、オープンなインターネット１０）ではグローバルＩＰアドレスが用いられ、医療機関ＦＷ（２Ａ）６ａ，（２Ｂ）６ｂより下位のネットワークではローカルアドレスが用いられている。
また、医療機関ＦＷ（２Ａ）６ａ，（２Ｂ）６ｂは、各医療機関のセキュリティポリシーが設定されており、そのポリシーに従って、アクセス制限、データの入出力制限を行う。
【００４７】
［医療機関内クライアント７ａ，７ｂ］
医療機関内クライアント７ａ，７ｂは、大病院用のローカルアドレスで動作する端末装置であり、医療機関ＦＷ（２Ａ）６ａ，（２Ｂ）６ｂを介して医療クラウドネットワーク１に接続し、同じ医療機関内のネットワークであればローカルネットワークで相互に接続可能である。
【００４８】
［医療機関クライアント６ｃ］
医療機関クライアント６ｃは、中小病院用のグローバルＩＰアドレスを有する端末装置であり、医療クラウドネットワーク１に直接接続する。
【００４９】
［インターネット１０］
オープンなインターネット１０は、複数のＩＳＰ１２と、ＩＳＰ１２を相互に接続するＩＸＰ１１と、ＩＳＰ１２に接続する複数の加入者端末１３とを備えている。
ＩＸＰ１１は、ＩＳＰの相互接続をＩＸ（Internet Exchange point）と呼ばれる相互接続ポイントを用いて行うものである。
ＩＳＰ１２は、通信事業者のネットワークシステムで、加入者端末１３がインターネットに接続可能とするためのネットワークである。
【００５０】
［（４）医療クラウド用運用サーバ３の処理］
次に、本医療クラウドシステムにおける医療クラウド用運用サーバ３で実現される処理（セキュリティポリシーの設定処理、ＱｏＳ機能の制御処理、災害復旧対応処理）について説明する。
【００５１】
［セキュリティポリシーの設定処理］
医療クラウド用運用サーバ３は、医療クラウド用ＦＷ（１）２に対して、セキュリティポリシーの設定を行う。
医療クラウド用ＦＷ（１）２の外部からのアクセスを制御するためには、ネットワークアドレスを個々に列挙して判断して制限してもよいが、医療クラウドネットワーク１内のＩＰアドレスが集約されているため、例えば、医療クラウドネットワーク１内のグローバルＩＰアドレスが「１２３．１００．１００．×××」であるとすると、最初のＩＰアドレスブロック「１２３．０．０．０／８」を持つだけ記述することによりアクセスを制限できる。
【００５２】
また、医療クラウド用ＦＷ（１）２の内部から外部に対するアクセスを制御するためには、予め登録されたネットワークアドレス宛についてはアクセスを許可し、それ以外のネットワークアドレスへのアクセスを禁止するようにしてもよい。
このように設定すれば、ファイアウォール性能への負荷軽減、ファイアウォールを設定・運用する管理者の工数軽減に繋がるものである。
【００５３】
更に、集約されたグローバルＩＰアドレスの中で、更に特定のグループの範囲を特定し、その特定のグループに対して特別のアクセス許可、アクセス制限を行うようにしてもよい。
【００５４】
また、データの入出力制限については、ＦＴＰ（File Transfer Protocol）コマンドを含むデータは制限し、ＨＴＴＰ（Hyper Text Transfer Protocol）コマンドを含むデータは許可するよう制御することが考えられる。
【００５５】
更に、医療クラウド用運用サーバ３は、厚生労働省が「医療情報安全管理に関するガイドライン」にて提唱しているポリシーに従ったアクセス制御を一元的に管理するよう医療クラウド用ＦＷ（１）２にセキュリティポリシーを設定することが可能である。
【００５６】
［ＱｏＳ機能の制御処理］
医療クラウドネットワーク１内では、他のＩＳＰネットワークを経由する必要がないため、医療クラウド内では、ファイアウォールの互換性や制御プロトコルの互換性を考慮することなく、エンドツーエンドで帯域優先制御や制御スケジューリングを行うことができる。
【００５７】
更に、医療クラウド用運用サーバ３は、医療クラウドネットワーク１内の集約されたグローバルＩＰアドレスを全て管理しており、医療クラウドネットワーク１内に接続されるルータのルーティング情報（ルート情報）も管理しているので、特定の通信時のみＱｏＳ機能を有効にし、それ以外は無効にすることで、ハードウェアの負荷を軽減して、ＱｏＳのスケジューリングを行うことができる。特定の通信時とは、画像を参照しながらの遠隔治療を行う場合や、緊急の患者データの送信を行う場合が相当する。
【００５８】
また、医療クラウド用運用サーバ３は、ＱｏＳ機能を有効にする場合に、ＱｏＳ情報をＦＷ２，６ａ，６ｂに設定し、ＩＸＰ１１へのＱｏＳ情報のアナウンス処理を行う。この時、ＱｏＳ情報を下流のＩＳＰ１２にアナウンスする必要があるか否かを判定する。
具体的には、下流のＩＳＰ１２がＱｏＳ情報を下流にアナウンスする機能を備えているか否かを判定し、機能を備えるＩＳＰ１２であれば、そのままとし、機能を備えないＩＳＰ１２であれば、医療クラウド用運用サーバ３がＱｏＳ情報を下流のＩＳＰ１２にアナウンスする処理を行う。
【００５９】
これにより、医療機関における特定のデータを送受信する際のデータの優先順位と、確実にデータを送受信するための帯域を確保することができる。従って、画像の大容量データの送受信や緊急を要する患者データを迅速かつ確実に送受信できる。
【００６０】
［災害対応処理］
災害時に最優先で守るべき医療データが、本医療クラウドシステムの配下に一元管理されているため、災害時の通信経路のバックアップ制御が容易となる。
具体的には、医療クラウド用ＦＷ（１）２は、ＩＰアドレスの領域が集約された医療クラウドネットワーク１内において、経路処理を行う全てのルータのルート情報をＩＰアドレスブロックにて集約できるため、容易に管理できるものであり、ルータの処理に負荷を掛けることなく、簡単かつ迅速に通信経路のバックアップ制御及び復旧処理が可能である。
【００６１】
特に、通信経路の一部が災害で破損している場合に、医療クラウド用運用サーバ３及び医療クラウド用ＦＷ（１）２は、管理する全てのルート情報から破損箇所のルート及び機能していないルータを特定し、破損箇所を回避するルート情報を新たに設定構築して、運用を行うと共に、重要な医療データの送受信を行うのであれば、ＱｏＳ制御を行う。
【００６２】
更に、回避するルート情報を設定構築できない場合は、医療クラウド用運用サーバ３は、破損箇所のルートとルータを特定し、復旧すべきルートのルート情報を管理者に通知する。当該通知内容に基づいて通信経路の復旧を行うことで、通信経路の迅速な復旧を実現できる。
【００６３】
［災害対応処理フロー：図２］
次に、本医療クラウドシステムにおける医療クラウド用運用サーバ３における災害時対応の処理の一例について図２を参照しながら説明する。図２は、医療クラウド用運用サーバにおける災害対応処理のフローチャートである。
【００６４】
災害が発生すると、医療クラウド用運用サーバ３の制御部は、災害発生が自動検知されたか否かを判定し（Ｓ１）、自動検知されたなら（Ｙｅｓの場合）、処理Ｓ７に移行する。
災害の自動検知が為されなかった場合（Ｎｏの場合）、医療クラウド用運用サーバ３の制御部は、災害発生の指示入力が為されたか否かを判定する（Ｓ２）。
【００６５】
災害発生の指示入力が為されなければ（Ｎｏの場合）、判定処理Ｓ２を繰り返し、災害発生の指示入力が為されれば（Ｙｅｓの場合）、医療クラウド用運用サーバ３の制御部は、ＦＷ２，６ａ，６ｂに対してＱｏＳの設定を行う（Ｓ３）。ＱｏＳの設定は、災害発生に備えて予め記憶していた内容を用いてもよい。
【００６６】
その後、処理は、処理Ｓ４と処理Ｓ７に分岐する。
まず、医療クラウド用運用サーバ３の制御部は、ＦＷ２に対してＦＷ Policyの設定を行い（Ｓ４）、ディザスタ状況（被災状況）の確認処理を行う（Ｓ５）。
ＦＷ Policy（ＦＷ用のセキュリティポリシー）の設定も、災害発生に備えて予め記憶していた内容を用いてもよい。また、医療クラウド用運用サーバ３は、ＦＷ２だけでなく、ＦＷ６ａ，６ｂにもポリシーを設定してもよい。更に、ディザスタ状況は、各所から集計された情報に基づいて確認処理が為される。
そして、医療クラウド用運用サーバ３の制御部は、上記設定した情報でのネットワーク運用を開始する（Ｓ６）。
【００６７】
また、処理Ｓ７では、医療クラウド用運用サーバ３の制御部は、ＩＸＰへのＱｏＳ情報のアナウンス処理を行い（Ｓ７）、次に、ＱｏＳ情報を下流にアナウンス必要か否かを判定する（Ｓ８）。具体的には、ＱｏＳ情報を下流にアナウンスする機能を備えるプロバイダか否かを判定し、機能を備えるプロバイダであれば（Ｎｏの場合）、処理Ｓ１０に移行し、機能を備えないプロバイダであれば（Ｙｅｓの場合）、医療クラウド用運用サーバ３がＱｏＳ情報を下流プロバイダにアナウンスする処理を行う（Ｓ９）。
そして、医療クラウド用運用サーバ３の制御部は、ＱｏＳ情報に基づいた運用を開始する（Ｓ１０）。
【００６８】
次に、運用を開始したネットワークにおいて、通信するパケットがＱｏＳ Policyに沿ったパケットか否かをチェックし（Ｓ１１）、ＱｏＳ Policyに沿ったパケットでなければ（Ｎｏの場合）、当該非優先パケットは破棄する処理を行う（Ｓ１２）。
また、ＱｏＳ Policyに沿ったパケットであれば（Ｙｅｓの場合）、当該パケットを優先パケットとして通信を行う。
以上のように、災害発生時では処理が為される。
【００６９】
［医療クラウドシステムのアプリケーション：電子カルテ］
医療クラウドシステムでは、医療に特化したアプリケーションから一般のアプリケーションまでを組み込むことができる。以下、電子カルテの医療データを扱うアプリケーションを実現する電子カルテ管理サーバ、電子カルテＤＢについて説明する。
【００７０】
電子カルテ管理サーバ（１）４ａ，（ｎ）４ｂは、医療クラウドネットワーク１に接続する医療機関のクライアント装置に対して、電子カルテＤＢ（１）５ａ，（ｎ）５ｂへのアクセス権限を付与する。
【００７１】
電子カルテ管理サーバ（１）４ａ，（ｎ）４ｂは、付与したアクセス権限情報に従って医療機関のクライアント装置からのアクセス制御を行う。
また、電子カルテ管理サーバ（１）４ａ，（ｎ）４ｂは、アクセス権限の変更、取消も行う。
尚、電子カルテＤＢ（１）５ａ，（ｎ）５ｂへのアクセス権限の付与等は、権限のある管理者によって為される。
【００７２】
［（５）実施の形態の効果］
本医療クラウドシステムによれば、集約されたグローバルＩＰアドレスが割り当てられた医療クラウドネットワーク１とオープンなインターネット１０との間に医療クラウド用ＦＷ（１）２を設けて、セキュリティポリシーが設定されるため、インターネット１０の環境に対してセキュリティを向上させることができる効果がある。
【００７３】
また、本医療クラウドシステムによれば、電子カルテの医療データを電子カルテＤＢ（１）５ａ，（ｎ）５ｂで保存し、アクセス制御を電子カルテ管理サーバ（１）４ａ，（ｎ）４ｂで行うようにしているので、医療データの活用を推進し、災害時に緊急の医療データを利用できる効果がある。
【００７４】
また、本医療クラウドシステムによれば、医療クラウド用ＦＷ（１）２によってＱｏＳ制御を実現できるため、大容量のデータの送受信や緊急の医療データを迅速かつ確実に送受信でき、医療データを活用でき、更に災害時でも必要な送受信の帯域を確保できる効果がある。
【００７５】
また、本医療クラウドシステムによれば、医療クラウド用運用サーバ３及び医療クラウド用ＦＷ（１）２が全てのルート情報を管理しているので、障害のあるルートを回避し、必要に応じてＱｏＳ制御を行い、復旧すべきルート情報をレポートできるので、災害復旧に迅速に対応できる効果がある。
【００７６】
［ホワイトリストサイトの運用］
本医療クラウドシステムでは、ＩＰアドレスの所有者が特定されるため、クラウド内におけるウィルスやサイバー攻撃等の異常なトラフィックに対して、迅速かつ容易に対処でき、外部からのクラックやフィッシングを検知して対応することができる。
本医療クラウドシステムで使用されるＩＰアドレス領域、或いはドメイン名の認知度が向上し、公共性が高まれば、公的なサイトとして人道的な保護が受けられ、ホワイトリストサイトとしての運用が可能となる。
【００７７】
本医療クラウドシステムでは、医療クラウド内で連携する医療機関の範囲を明確にでき、医療クラウド外への外部接続する際に、厚生労働省が定めるガイドラインに則ったアクセスが可能となるため、Ｐマーク（個人情報保護マーク）の取得を容易にできる。
【００７８】
運用サーバ３は、医療機関ＦＷ（２Ａ）６ａ、（２Ｂ）６ｂ、医療機関クライアント６ｃに対して、ガイドラインに基づく具体的な運用情報を提供でき、その運用情報に基づいて各病院の担当者が容易に設定できる。
【００７９】
また、本医療クラウドシステムでは、医療クラウドネットワーク１内では、ＩＰプロトコル以外のプロトコルを用いて医療機関のコンピュータ同士が通信可能にできる。
【００８０】
［（６）その他］
また、本医療クラウドシステムでは、外部のネットワークを介さず、クローズドの医療クラウドネットワーク１の環境を構築できるため、医療機関に特化したサービスが提供可能であり、これまでセキュリティ面で使用がためらっていたアプリケーションも利用可能となる。例えば、電子レセプト、遠隔医療、その他のアプリケーションを導入し易くなる。
【産業上の利用可能性】
【００８１】
本発明は、オープンなインターネット環境に対してセキュリティを向上させ、医療データの活用を推進し、災害復旧に迅速に対応できる医療クラウドシステムに好適である。
【符号の説明】
【００８２】
１...医療クラウドネットワーク、  ２...医療クラウド用ＦＷ（１）、  ３...医療クラウド用運用サーバ、  ４ａ...電子カルテ管理サーバ（１）、  ４ｂ...電子カルテ管理サーバ（２）、  ５ａ...電子カルテＤＢ（１）、  ５ｂ...電子カルテＤＢ（２）、  ６ａ...医療機関ＦＷ（２Ａ）、  ６ｂ...医療機関ＦＷ（２Ｂ）、  ６ｃ...医療機関クライアント、  ７ａ，７ｂ...医療機関内クライアント、  １０...インターネット、  １１...ＩＸＰ、  １２...ＩＳＰ、  １３...加入者端末
【図１】
2013134711.tif 000003
【図２】
2013134711.tif 000004