Download presentation
Presentation is loading. Please wait.
Published byとき ひでやま Modified 約 7 年前
1
日本版医療クラウド 株式会社エヌアイエスプラス 松尾 正治 ただ今ご紹介をいただきました、株式会社エヌアイエスプラスの松尾でございます。
松尾 正治 ただ今ご紹介をいただきました、株式会社エヌアイエスプラスの松尾でございます。 本日は先月のJAMINA(日本医療情報ネットワーク協会)セミナーにて発表させていただきました 「日本版医療クラウド」についてお話させて頂きます。
2
1 なぜJAMINAがクラウドなのか JAMINAにおいては1997年から医療専用ネットワーク構想を掲げてきた。
他の医療機関との高速、安全、安定した通信 研究・学術ネット参加機関との Accessible User Policy(AUP)に違反しない通信 FIREWALLによる外部からの防御 情報提供サーバのアクセス度、安全性、安定性の向上 Cacheによる遠隔サイトでの高速なアクセス情報提供代理サーバの利用 DeleGateサーバによる各種情報の中継 Closed なNewsサーバの運用全国におけるアクセスポイントの構築(FIREWALL内・外選択可) 衛星によるバックアップ通信 認証サーバによる安全な情報 暗号ルータによるインターネットを介したSecureな通信 APAN/ATMによる海外のMDXとの連携 ※日経メディカル 1997年6月号掲載 しかしながらネットワークインフラ環境が医療専用ネットワークを実現できるレベルに はなかった。 近年、ネットワークインフラ環境等がめざましく進展し現実にむけた施策が可能となる。 個別のネットワーク JAMINA は 医療情報ネットワーク相互接続研究会として 1997年に発足いたしましたが、その当時から医療専用ネットワーク構想を掲げておりました。 アメリカのゴア副大統領が、「情報ハイウェイ構想」を提唱していた97年代、日本も「情報ハイウエイが流行し、個別のネットワークが構築されていました。 このスライドの青枠にかかれているのは、その当時、医療情報ネットワーク相互接続研究会で行われておりました「ネットワーク実験」の一例になりますが、この内容が 厚労省のガイドラインに対応しているところがわかります。 しかしながらネットワークインフラ環境が医療専用ネットワークを実現できうるレベルにはありませんでした。 スライド下部の図でご覧いただいておりますように、インターネットが普及していない、情報ハイウェイの時代には、個別のネットワークが構築されました。 インターネットが普及すると、医療機関が接続され、医療連携が行われるようになりました。 そしてナローバンドからブロードバンドへ、携帯電話の普及、スマートホンの普及により、国民が参加するようになりました。 クラウドにおいても 同じ流れがおこると考えます。 インターネットの普及で医療連携が行われていますが、クラウドの浸透により、医療機関のクラウド化がすすみます。 そして クラウド間連携がすすんで、業界としてのクラウドが構築されることにより国民が参加してくるようになると考えております。 したがいまして、目指すところは「国民のための医療サービス」を実現していくということになります。 医療機関連携 国民の参加 インターネット黎明期 インターネット普及 ブロードバンド化 医療連携 医療機関のクラウド化 国民の参加 インターネット普及 クラウド 業界クラウド
3
このスライドは、ご参考までにですが、97年当時 医療専用のネットワーク(医療情報ハイウェイ)について紹介されました記事です。
97年当時も医療専用NWを作るにあってのメリットや検討課題が紹介されておりました。
4
2 JAMINA 日本版医療クラウドの全体像 国民が必要とするサービスを複数のクラウド利用を意識させないで利用可能とする
インターネット 医療専用ネットワーク 日本版 医療 クラウド クラウドサービスC レセプト 診療所向け電子カルテ 地域連携アプリケーション 利用者ノード クラウドサービスB レセプト 診療所向け電子カルテ 地域連携アプリケーション クラウドサービスA アプリケーション レセプト 診療所向け電子カルテ 地域連携アプリケーション 広域レベル 連携 県内 専門病院 県内 大学病院 医療圏 連携 基盤機能 ◇認証 ◇課金 ◇地域連携VPN ◇データ連携・保存 ◇分散バックアップ では、JAMINAではどのような「日本版医療クラウド」を考えているのか? その全体像がごらんいただいておりますスライドの図になります。 昨年の東日本大震災の時のことを教訓に、 我々国民のための、災害につよい、 つまり災害対策が考慮された医療サービスを実現するということを念頭に入れ構成しております。 その特徴として、 1 国民はインターネットへ接続する環境が与えられている。 2 医療ネットワークはインターネットと独立した専用のネットワークである。 3 インターネットと医療ネットワークは FWで接続され 医療ネットワーク側は保護されている。 4 医療機関は 医療ネットワーク内に存在する。 5 各社の医療クラウドサービスが 医療クラウド内で提供されている。 6 各社の医療クラウドサービスの違いを吸収する仕組みが 日本版医療クラウドとして構築されている。 利用者からみて一元性のある医療クラウドであること。 つまり、クラウド間を連携する仕組みがあり、利用者側に複数のクラウドを意識させないということです。 7 基盤機能としてアプリケーションベンダーに提供する機能がある。 8 災害時にまもるべきネットワーク環境が明確になっている 9 災害時に国民が医療サービスをうけるための、ネットワーク機能を提供できる つまり医療クラウドを構築するに当たっては、国民へのサービスを意識することが必要で、国民へのサービスを考えた場合 災害を想定した構造を検討しておく事が重要です。 。 A医療圏中核病院 B医療圏中核病院 生活圏 連携 医院 診療所 在宅
5
3 日本版医療クラウドと一般クラウドとの比較1
3 日本版医療クラウドと一般クラウドとの比較1 一般的なクラウドサービスとの相違点、優位性を以下に示します。 日本版医療クラウド 一般的なクラウド クラウドベンダ依存性 サービス提供範囲が特化していない 情報形式に特化せず多くの情報を収集 キャリア依存しない ベンダ特有の形式での情報保有 SS-MIX等の標準化データに特化ベンダ変更時の移行が困難 キャリア依存する 業界特化 専用ノードでの構築 検討開始されはじめた クラウド網 グローバルアドレスブロック アドレスが明確であることから安心して利用できる 既存のイントラネットと重複しないため移行が容易 自律ノードとしてインターネットからの不正アクセスに対するフィルタリングやノード内の使用帯域を一括管理 ユーザ環境を含めたネットワーク構成が必要 では日本版医療クラウドは 一般的なクラウドとどのような違いがあるかについて、ご説明してまいりますが、 一般的なクラウドに対して、 日本版医療クラウド側から このような構成、またはこのような機能を検討してきてほしいという要望がかかれていると解釈してください。 ここでの視点も、災害時に対応するためには ということを念頭において考えられた項目です。 具体的内容については割愛させていただきますが、いくつかの項目についてご説明していきます。 まず1点目は、クラウドベンダーに依存しないという事です。 たとえば、宮城にすまれていた方が、福島に移動したら違うクラウドサービスだったので せっかくのデータも利用できないということでは 意味がありません。 そのため クラウドベンダーへの依存性をなくしていくことが重要になります。 2点目は 業界に特化していることです。 業界に特化したサービスであるからこそ、国民に対して安心してサービスを提供できるもので あると考えます。 災害発生時に 守るべき対象が明確になっていることで、対応策がとりやすくなります 3点目は クラウド網の構築方法です。 東日本大震災の時にも有効であったTWITTERやFACEBOOKなどの情報は インターネット網から利用されます。そこに接続している医療ネットワークが グローバルアドレスを使って、災害時に優先的に接続できるようにします。
6
4 日本版医療クラウドと一般クラウドとの比較2
4 日本版医療クラウドと一般クラウドとの比較2 日本版医療クラウド 一般的なクラウド 災害時の接続性 自立ノードとして被災地からのアクセスを優先する制御が可能 災害時のユーザからのアクセス網の制御は考慮していない 厚労省ガイドライン準拠 ネットワーク インターネットに対しクラウド網自体がファイアウォールで保護されているため、クラウド内を一つのポリシーで運用される単一の組織と見なす事が可能 ノード内であれば医療機関相互接続が可能 医療機関相互接続において個別に確立する必要がある キャリア非依存の VPN網 キャリアに依存しないVPN網として構築するため、県境を跨ぐ地域連携の構築が可能 複数の地域連携に参加可能 ユーザ環境は想定していない キャリアのVPNサービスを利用する 県境(サービスエリア)を跨ぐ地域連携の構築は困難 災害発生時の接続性ですが、この内容については当然あるべきことなので割愛します。 さらに5点目として、 厚労省のガイドラインに準拠していることです。 日本版医療クラウドでは、インターネットからみた場合に、ファイアウォールで保護され、 かつ閉じたネットワークで構成されています。 医療クラウド自体が 厚労省のガイドラインに準拠する構成をとってあげることにより、 参加する医療機関での情報システム構築、および運用の負荷を軽減することができます。 6点目は キャリア非依存でのVPN網になるということです。
7
5 医療クラウドサービスにより恩恵をうけるのは
5 医療クラウドサービスにより恩恵をうけるのは JAMINA日本版医療クラウドにおいては国民視点に立ったクラウド サービスの構築を目指します。 異なるサービスを利用者に意識させる事なく医療アプリケーション を提供可能とする事で、医療機関における情報共有・連携・活用 のみならず、以下を対象として医療クラウドと定義しています。 国民 医療機関 アプリケーションベンダー 災害発生時のネットワーク つぎに 日本版医療クラウドにより恩恵をうけるのは だれか ということも意識する必要があります。 現在いわれております「医療クラウド」は 医療機関に向けたサービスと、とらわれやすく、国民にむけては 何の利点があるかが わかりにくいという状況であろうかと思います。 日本版医療クラウドでは、国民の視点にたったサービスはどのように実現されるべきであるかを考え構築を目指しております。 国民へのいいサービスという視点では、関係する医療機関、アプリケーションベンダーにむけてもいい環境を提供しないと実現しません。 つまり日本版医療クラウドでは 1 国民 2 医療機関 3 アプリケーションベンダー にむけてのメリットを明確にしていきます。 また 先ほども述べましたが、 東日本大震災の時にもインターネットが有効だった実例より、 災害時のネットワークについても考慮すべきです。
8
6 医療クラウドでのサービス -1- 提供機能 想定されるメリット 国民 カルテ情報の共有 地域連携 生涯健康データの 蓄積と提供
6 医療クラウドでのサービス -1- 日本版医療クラウドによる国民に対するメリットは以下のとおりです。 提供機能 想定されるメリット 国民 カルテ情報の共有 地域連携 生涯健康データの 蓄積と提供 質の高い、効率的な医療 サービスの授受 生涯健康データの保有と参照 タイムリーな情報利用 どこからでも利用可能 医療費節減への貢献 国民にとってのメリットとしては、 カルテ情報の共有 地域連携 生涯健康データの提供 等がありますが、これらのデータが 医療クラウド上にしっかり保管されていて、 どこにいても、いつでも、また災害時にでも 確実に利用できるというメリットをだしていく必要があります。
9
7 医療クラウドでのサービス -2- 提供機能 想定されるメリット 医療機関 クラウド環境CPU ストレージの提供 認証機能の提供
7 医療クラウドでのサービス -2- 日本版医療クラウドによる医療機関に対するメリットは以下のとおりです。 提供機能 想定されるメリット 医療機関 クラウド環境CPU ストレージの提供 認証機能の提供 課金機能の提供 各種アプリケーション 初期投資費用の削減 運用コストの削減 災害対策(BCP) システム移行(選択) の柔軟性 医療機関にとってのメリットは クラウド環境CPUとして災害があったとしても いつでも必ず動いているアプリケーション環境 そして ストレージの提供として 確実にバックアップがとれていることがあげられます。
10
8 医療クラウドでのサービス -3- 提供機能 想定されるメリット アプリケーションベンダ クラウド環境CPU ストレージの提供
8 医療クラウドでのサービス -3- 日本版医療クラウドによるアプリケーションベンダーに対するメリットは以下のとおりです。 提供機能 想定されるメリット アプリケーションベンダ クラウド環境CPU ストレージの提供 認証機能の提供 課金機能の提供 製品拡販 低コストでの提供 アプリケーションベンダーにとってのメリットは いままではアプリケーションベンダーが クラスター化など独自に障害対策を行ってきていると思いますが、災害対策を考慮したCPU環境をプラットフォームとして提供してもらえるということにあります。 また、ストレージについても同様で データベースのレプリケーションなど独自に障害対策を行ってきていると思いますが、クラウド環境でストレージの保証をしてもらうことにより、災害対策まで含めたアプリケーションを容易に構築できるようになる。といった点を上げる事ができます。
11
9 医療クラウドでのサービス -4- 提供機能 災害時のアクセス インターネット側からの仮想医療ネット ワークの接続
9 医療クラウドでのサービス -4- 日本版医療クラウドにおける災害時のアクセス対応としての機能は以下のとおりです。 提供機能 災害時のアクセス インターネット側からの仮想医療ネット ワークの接続 医療クラウドに向けてのQOS 仮想ネットワークはVGNにて実現 そして 災害発生時にも、国民へのサービスを提供する仕組みを構築しておくことが最大のメリットとなります
12
10 提供するクラウドサービス API アプリケーションサービス 基盤サービス
10 提供するクラウドサービス 日本版医療クラウドにおけるネットワークベーシック(基盤)サービスは、利用セグメントでの業務運用の基盤となるネットワーク運用、監視、分散データ保有、バックアップ、アクセス認証、情報連携基盤等の基盤機能の提供。 基盤サービスをベースとして医療業界向けの各種アプリケーションを提供する。 アプリケーションサービス 基盤サービス 利用サイト 監視サービス 追加機能(利用目的別) 中核病院 運用サービス 企業ネットワーク(情報共有) 患者データ保存 医師会 薬剤師会など 遠隔診断支援 ディスクサービス API 電子カルテ、レセプト 診療所 調剤薬局 認証基盤(HPKI,SAML)ID連携 EHR・PHR(情報共有) 提供するクラウドサービスにおいては、 国民のための災害対策を意識すると 「アプリケーションサービス」とは別に 「基盤サービス」を考える必要があります。 基盤サービスにおいては、 国がインフラとして提供してもいいものと考えます。 たとえば 共通番号制度法案 で出されているような国民ひとりひとりの唯一の管理番号を用い認証する基盤や、地域連携のプラットフォームがあるのが理想です。 アプリケーションサービスは アプリケーションベンダーが、基盤サービスを意識する必要なく、それぞれのアプリケーションに特化した形でAPIを利用して構築していくべきと考えます。 共通セキュリティポリシー 地域連携・病診連携 国民 課金 地域医療プラットホーム
13
11 実現にむけてのスケジュール 日本版医療クラウドの実現に向けて次の項目について実現を図っていく予定です。 実現化項目 サービス面
11 実現にむけてのスケジュール 日本版医療クラウドの実現に向けて次の項目について実現を図っていく予定です。 実現化項目 サービス面 ポータルサイト 2012年9月頃を目標にポータルサイトを立ち上げる リファレンスモデル構築 第一段階のリファレンスモデルとして以下の基本アプリケーションを稼動 ・診療所向け電子カルテ ・レセプト ・地域連携アプリケーション APIの提供 アプリケーションベンダー向けにAPIを提供 実現にむけてのスケジュールですが、 まずは、ポータルサイトを立ち上げ、利用イメージをつかんでいただけるようにしてまいります。 次に リファレンスモデルとなるアプリケーションをサンプル実装し、実証実験していく予定です。 リファレンスモデルで使用するアプリケーションは、例えばApple Storeのイメージで、それぞれの医療機関が個々に必要なアプリケーションをポータルサイトより選択して 使用していくようなモデルを考えています。 さらに、リファレンスモデルを運用して、 アプリケーションベンダ−様に提供するAPIを確定していきます。
14
12 リファレンスモデルのイメージ 日本版医療クラウド
12 リファレンスモデルのイメージ 今年度に目標とする日本版医療クラウドのリファレンスモデルの利用イメージは以下のとおりです。 日本版医療クラウド XXX病院 日本版医療クラウド YYY病院 XXX病院 サービスメニュー サービスメニュー YYY病院 地域医療連携 サービス機能1 地域医療連携 サービス機能1 地域医療連携 サービス機能2 地域医療連携 サービス機能2 日本版医療クラウド XXX病院 サービスメニュー 1 電子カルテ 2 レセプト (2)選択したサービスを利用登録する事で利用した実績にて課金される 3 地域医療連携 (1)医療クラウドサービスメューより、利用したいサービスを選択する事でサービスを利用できる 医療機関向けポータルサイトのイメージです。 Apple Storeのイメージでポータルサイトから使いたいアプリケーションをクリックすると翌日からサービスをうけれるような連携機能を持ったものを考えております。 日本版医療クラウド 地域医療連携 電子カルテ レセプト
15
13 おわりに ご清聴ありがとうございました。 以上、本日は
13 おわりに ご清聴ありがとうございました。 以上、本日は 「日本版医療クラウド」の主眼は「国民」。我々、国民に対してのサービス実現を目指す。 「国民」のことを考えたら「災害対策」が重要である。 という点をポイントにJAMINAセミナーにて発表せていただきました内容をご報告させていただきました。 どうもありがとうございました。
Similar presentations
© 2024 slidesplayer.net Inc.
All rights reserved.