Comments
Description
Transcript
EHR PHR構築事例
EHR PHR PHR構築事例 構築事例 慶應義塾大学 森川富昭 AGENDA PHRの取り組み EHRの取り組み 2 ICTを用いた糖尿病対策 ICTを用いた糖尿病対策 PHR(Personal Health Record) 一般・患者が利用する データの見える化による行動変容 個人の健康意識の向上 EHR(Electronic Health Record) 医療従事者間で利用する 医療の質を上げるための病診・病病連携 データに基づく疾病管理 3 医療システムの設計ポリシー システム設計ポリシー ダッシュボードを装備 標準化されたデータを活用 システムの継続価値を考慮 業務として必要なデータ集計・分析を自動化し業務内 容の見える化に貢献 全体把握 入力を最小限に 標準化された既に存在するデータを活用 INPUTを極力さける 4 ＥＨＲ、ＰＨＲの位置づけと標準化 EHR 標準化データ 医 療 利点 • レセプト電算処理システム （診療報酬明細書） • DICOM （医用画像） +オーダ・検査結果 •患者情報のシームレ SS-MIX（処方・検査・画像・記事） スな連携が可能 PHR 標準化規格 健 診 事業主検診 なし 人間ドック なし 特定健診 あり ISO/IEEE 11073 健 康 • 各医療機関で情報 を交換することが可 能 ※ 業界団体：Continua Health Allianceによる規 格・ガイドライン策定が進ん でいる • 検査結果を送信、 参照することが容易 • 医療機関への情報 提供、連携が可能 問題点 • 各医療機関ごとに異なるデータ仕様 → 標準化データに変換するゲート ウェイを設置する必要 • 医療機関間の接続に多大なコスト必要 • 特定健診のみ標準化されている →労働安全衛生法に基づく検診 や一般的な人間ドックは標 準化されていない • 測定結果を収集し、 •測定機器からの収集については標 一元的な管理が容易 準化されている → サービス提供者、団体ごと • 個人の健康管理 に別々の仕様であり収集は • 医療機関への情報 できるが共有が困難 提供 医療・健康情報の電子的な管理・活用にはデータ仕様の標準化・個人IDの共通化が必須 個 人 を 特 定 す る 共 通 I D が 無 い レセプト電算・SS レセプト電算・ SS--MIXデータ項目 MIXデータ項目 レセプト電算 SS-MIX 10.患者基本 ○ ○ 20.投薬（処方） ○ ○ 30.注射 ○ 40.処置 ○ × 50.手術・麻酔 ○ × 診療区分/オーダ種 70.画像 80.リハビリ（その他） △ ※値はなし △ ○ ※値を含む ○ ※画像はなし ※画像含む ○ × SS-MIX(Standardized Structured Medical record Information eXchage) 診 療 情 報 連 携 ー 60.検体検査 ○ ※実施情報は含まない 組 み 合 わ せ る こ と で 全 て の 項 目 を 網 羅 デ タ 分 析 6 ＥＨＲ、ＰＨＲにおける標準化データの活用 標準化 PHR 健康 （Personal Health Record） 個人データ 健康データ 蓄積データベース 健診 特定健診 EHR （Electronic Health Record） Disease Management 地域連携・病病連携 分 析 医療 レセプト レセプト 疾病の予測 疾病予防・管理 治療 医療の質 医療費削減 重症化予防 EHRアーキテクチャー EHRアーキテクチャー EHR情報システム基盤 補助的データ＆サービス マスター情報 住民 マスター 環境データ EHRデータレポジトリ 共有健康情報 データウェアハウス 医薬品情報 ＊１ 利用者 マスター 施設 マスター ﾋﾞｼﾞﾈｽﾙｰﾙ コードマスター EHRｲﾝﾃﾞｯｸｽ ﾒｯｾｰｼﾞ構造 検査 疫学データ ＊１ 正規化ﾙｰﾙ 生涯記録（LRS） 個人情報ﾃﾞｰﾀ 個人情報ﾃﾞｰﾀ 個人情報ﾃﾞｰﾀ ｾｷｭﾘﾃｨ管理ﾃﾞｰﾀｺﾝﾌｨｸﾞﾚｰｼｮﾝ ＊１ 共通サービス 標準化 地域中核病院 診断画像 ＊１ 地域医療連携基盤 診療所 クリニック 調剤薬局 健診センター 在宅 地域中核病院 におけるｻｰﾋﾞｽ 電子カルテ 診療所・ｸﾘﾆｯｸ におけるｻｰﾋﾞｽ 医事会計 EHRビューア 画面ツール 医師/医療提供者 介護提供者 カナダのInforway（blueprint)を参考に 医師/ 医療提供者 医師/ 医療提供者 システム構成 電子カルテ SS-MIXデータ データ投入・名寄せ ファイル投入API レセプトアップ ロード画面 データ テーブル群 各種 パーサー 大学病院 レセプトアップ ロード画面 共有 DISK 検査結果アップ ロード画面 XML 各種 XML データ 取込エンジン 転置イン デックス テーブル群 参 照 転置インデッ クス生成 更 新 hadoopバッチ 処理 名寄せエンジン レセ電 ファイル 診療所用 画面群 診療所 コホートデータベース Servlet/Tomcat エクスポート バッチ 特定健診アップ ロード画面 保健指導アップ ロード画面 保健指導 画面群 保健センター IIS/SQLServer Cassandra/hadoop 名寄せデータベース 検索 リアルタイム検索 AP側 データ ベース 研究分析 名寄せ データ ベース バッチ検索 MySQL 結果 XML 検索 エンジン 9 データの流れ MySQL レセプト 「疫学研究に関する倫理指針」※準 拠のため物理的に分離し異なる データベースへ保存 データ投入・名寄せ SS-MIX 名寄せ情報 医療情報 （保険番号、医療機関コード等） 個人情報 （氏名、生年月日等） 患者個人情報 Cassandra/hadoop 検体検査 特定健診 各コード 数値 標準コードから検索用 のコードを付加 名寄せID レセプト コード ICD10 コード 病名 名寄せID 検査コード 検査コード 検査コード 結果値 結果値 結果値 名寄せID 健診コード 健診コード 健診コード 結果値 結果値 結果値 確定データのため基本的に蓄積するのみ ※ http://www.mhlw.go.jp/general/seido/kousei/i-kenkyu/sisin2.html 10 例）病名データの流れ方 Cassandra 糖尿病管理システム レセプトデータ 元病名 データ 2014 左側 2014 左側 糖尿病性 白内障 2504006 糖尿病性 白内障 2014 左側 2504006 2504006 糖尿病性 白内障 E143 ICD-10コードを付加 検索用病名 傷病名マスタ 修飾語マスタ 除外マスタ レセ電 レセ電 レセ電 マスタ 2504006 糖尿病性 白内障 2014 左側 2014 左側 2504006 糖尿病性 白内障 E143 E143 対応するICD-10コード レセプトデータから病名マスタ、修飾語マスタを参照し、検索に必要な ICDコードを付与し、除外マスタにより不要な修飾語を取り除いている 11 コードマスタ参照一覧 レセプト /SSMIX 主たる行為 元データ 診療行為情 診療行為コード 報 医薬品情報 医薬品コード レセプトデータ 傷病名情報 傷病名コード 保険情報 DPC情報 診断群分類コード 病院独自 薬剤情報 HOT9コード 検査結果情 JLAC10コード 報 SSMIX 病名情報 MEDISコード 保険情報 - 入退院歴情 病棟コード 報 来院情報 診療科コード 参考資料保管場所 変換参照データ サイト：診療情報提供サービス 資料名：オンライン又は光ディスク等による請求に 医科診療行為マスタ 係る記録条件仕様（医科用）内の診療行為レコー ドの４番目の診療行為コード（資料P１８内） 医薬品マスタ サイト：診療情報提供サービス 資料名：オンライン又は光ディスク等による請求に 医薬品HOTコードマスタ 係る記録条件仕様（医科用）内の医薬品レコード の４番目の医薬品コード（資料P２０内） サイト：診療情報提供サービス 資料名：オンライン又は光ディスク等による請求に 傷病名マスタ 係る記録条件仕様（医科用）内の傷病名レコード の２番目の傷病名コード（資料P１７内） × × × × 医薬品マスタ 静岡県版電子カルテ情報ゲートウェイデータ交換 医薬品HOTコードマスタ 仕様書第１版内の薬剤/処置オーダ定義（P４０内） 静岡県版電子カルテ情報ゲートウェイデータ交換 仕様書第１版内の検査結果セグメント定義（P２６ × 内） 静岡県版電子カルテ情報ゲートウェイデータ交換 仕様書第１版内の患者病名情報セグメント定義（P 傷病名マスタ ２６内） 静岡県版電子カルテ情報ゲートウェイデータ交換 × 仕様書第１版内の保険セグメント定義（P８内） 静岡県版電子カルテ情報ゲートウェイデータ交換 仕様書第１版内の患者来院情報セグメント定義（P × ２０内） 静岡県版電子カルテ情報ゲートウェイデータ交換 仕様書第１版内の患者来院情報セグメント定義（P × ２０内） 診療情報提供サービスhttp://www.iryohoken.go.jp/shinryohoshu/downloadMenu/ MEDIShttp://www2.medis.or.jp/hcode/ 提供元 サイト：診療情報提供サービス 資料名：医科診療行為マスター内の３番目の診療行為 コード サイト：診療情報提供サービス 資料名：医薬品マスター内の３番目の医薬品コード サイト：MEDIS標準マスター 資料名：医薬品HOTコードマスターのMEDIS西暦 _HOT9.TXT内の９番目のレセプト電算コード サイト：診療情報提供サービス 資料名：傷病名マスター内の３番目の傷病名コード × × サイト：診療情報提供サービス 資料名：医薬品マスター内の３番目の医薬品コード サイト：MEDIS標準マスター 資料名：医薬品HOTコードマスターのMEDIS西暦 _HOT9.TXT内の９番目のレセプト電算コード × サイト：診療情報提供サービス 資料名：傷病名マスター内の３番目の傷病名コード × × × 採用技術と特徴 コホート分析に必要な要件 大量データの集積が高速である 増大するデータに対しスケールアウト可能なデータス トアが必要である 経年に渡るデータの保全性が必要 大量データの高速処理が必要 経年に渡る保守費等が発生しない（オープンソースの 利用） キーバリューストアである Cassandraの採用 並列処理フレームワーク hadoop Map/Reduceの採用 13 PHRの取り組み PHR の取り組み 14 データの標準化 健康 健診 医療 介護 標準規格 ・ISO/IEEE 11073 ・特定健診 CHAによりガイドライン策定 ・事業主健診は検査項目 のみ定められている。 ・レセプト電算 ・SS-MIX ・DICOM （対象者によって変動） 体組成計 血圧計 健診情報 歩数計 介護記録 血糖測定 特定健診 データ 医療 データ データ PHR(Personal Health Record) 個人自らの健康管理 疾病予防 疾病管理 CHA(Continua Health Alliance) : 健康機器や医療機器のデジタル化促進と通信規格の統一を目標とした業界団体 SS-MIX : 医療情報の電子化・標準化を推進する事業であり、その事業で採用された標準方式 DICOM : CT・MRI等の画像フォーマットと、医用画像機器間の通信を定めた標準規格 15 健康管理システム概要 健康管理実施 体組成計 計測 健康管理画面 血圧計 ICT健康管理 システム 計測 閲覧 データ登録 各企業参加 歩数計のフェリカを 用いて個人認証 歩数計 利用者登録 企業管理者 PCと各健康 機器を接続、 サーバへ計 測データを 送信 16 PC スマートフォン 16 データ登録の流れ データ登録 の流れ 個人認証 歩数登録 体組成計測定 血圧計測定 測定項目 測定項目 測定項目 歩数 体重 最高血圧 距離 体脂肪率 最低血圧 時間 脂肪量 脈拍数 消費カロ リー 除脂肪量 筋肉量 体水分量 ＢＭＩ フェリカ認証 推定骨量 歩数送信 データ送信 データ送信 17 血糖管理 血糖値の一元管理 外来 自宅 入院 自宅 HIS端末 血糖測定 FeliCa取込 血糖測定 記録確認 血糖測定 インスリン種類、投与量確認 記録確認 血糖管理サーバ 血糖値データの出力 電子カルテとの連携 自宅PCで登録・閲覧 18 画面イメージ 自分の行動を共有することで、意識付け、行動変容を加速させる Twitter、Facebook、mixとの連携 19 EHRの取り組み EHR の取り組み 20 従来の情報連携 従来は紙（紹介状）に よる情報連携 紙 保健センター （特定健診） 病院 （急性期） 診療所 管理 ・有所見者管理 ・保健指導 ・適切に診療所へ紹介 予防 紙 管理 管理 ・糖尿病患者管理 ・重症化予防 ・適切に病院へ紹介 ・重症化予防 ・診療情報連携 増悪率を 下げる 各セクターごとの管理・治療 横のつながり（情報連携）は充分でない 21 システム概念図 利用機関：１０病院 ９診療所 １保健センター ○○小児科 診療所から病院への紹介 ○○産婦人科 ○○内科 VPN ルータ VPNルータ 1患者の処方・処 置・検査データを 時系列で参照 VPN ルータ ○○眼科 ○○医院 VPNルータ 診療所データ を参照可能 プライベートクラウドでデータ送信 診療所 データ VPNルータ 診療所 検査結果（検査会社） 処置データ（レセプト） 処方データ（レセプト） 紹介状 病院 データ VPNルータ プライベートクラウド ○○内科 VPNルータ VPN ルータ VPNルータ 保健センター・町役場 VPNルータ A大学病院 診療所 VPN ルータ 病院から診療所へ プライベートクラウドでのデータ提供 検査結果（検査会社） 処置データ（レセプト） 処方データ（レセプト） 紹介状 診療所データ ＋ 徳大病院データ 診療所データ に加えて徳大 病院のデータを 参照可能 22 ICT ICTを活用した情報連携（事業開始後） を活用した情報連携（事業開始後） クラウドサービスにより横のつながりを強化 保健センター （特定健診） 病院 （急性期） 診療所 クラウドサービス 名寄せ 名寄せ ※保健センターの管理する 被保険者と 診療所の患者を紐付ける ※診療所の患者と 病院の患者を紐付ける アプリケーション データベース 23 各セクターの役割とクラウドサービス ■各セクターの役割 診療所、病院間のコミュニケーション ＋ 人材教育 保健センター （特定健診） 病院 （急性期） 診療所 管理 ・有所見者管理 ・保健指導 ・適切に診療所へ紹介 管理 管理 ・糖尿病患者管理 ・重症化予防 ・適切に病院へ紹介 ・重症化予防 ・診療情報連携 増悪率を 下げる 予防 ■業務システム（クラウドサービス）によるサポート ・医療へ送る人のピックアップ ・健診・指導内容の管理 ・病院へ送る人のピックアップ ・病院との情報連携 ・検査・処方内容の管理 ・診療所との情報連携 ＩＣＴテクノロジ（アーキテクト、ネットワークセキュリティ）の利活用 24 各セクター間の連携画面イメージ 保健センター （特定健診） 病院 （急性期） 診療所 ・ 検査結果 ・ 処方 ・ 処置 ・ 特定健診結果 ・ 検査結果 ・ 注射 ・ 処方 ・ （画像） ・ 処置 患者紹介 医療機関受診 特定健診データ 逆紹介 診療所データ 大学病院データ 25 ３．コホートデータベース 26 ３．コホートデータベース 紹介・逆紹介 A大学病院 地域連携室 患者IDの登録 紹介患者の名寄せ 地域医療連携センター 患者IDの登録 紹介患者の名寄せ SS-MIX データ 健康保険B病院 病病連携システム（ID-Link） 紹介患者は病病連携システムで 手動名寄せされた結果を取り込み コホートデータベース レセプト データ レセプト データ 紹介患者以外はシステムが自動名寄せ 名寄せ項目：氏名・性別・生年月日・保険情報 27 ３．コホートデータベース 2010.4 ・・・ 2010.9 ・・・ 2011.4 ・・・ 2011.9 ・・・ 2012.4 ・・・ レセプト 各患者のレセプトを時系列で突合 ・・・・・ SS-MIX LDL-C HDL-C HbA1C Alb レセプトとSS-MIXを各患者毎に突合 レセプト電算・SS-MIXのデータを名寄せによる突合で期間、多項目間の分析が可能 28 ３．１．名寄せ機能 名寄せ処理開始 ＩＤ－Ｌｉｎｋ側に名寄せ情報の確認を実施 データ有 ＩＤ－Ｌｉｎｋ側の名寄せ情報は、人が 介在して登録している情報 データ無 名寄せ処理の実施 コンピュータによる自動名寄せ処理 名寄せキー項目： コホート側名寄せ情報の更新 ・ 個人番号（特定健診） ・ 医療機関ID、患者ID ・ カナ氏名、性別、生年月日、保険者番 号、被保険者番号・記号 29 ３．１．名寄せ処理のデータの流れ方 開始 特定健診 データの 場合のみ 個人番号がある Ｎｏ 医療機関ＩＤと 患者ＩＤがある Ｎｏ Ｙｅｓ 医療機関ＩＤが 一致 Ｙｅｓ 過去名寄せされた保険情報も 履歴として保持 更新前の保険も遡って突合 Ｎｏ Ｙｅｓ 患者ＩＤが 一致 個人番号が一致 Ｎｏ 保険者番号と 被保険者番号がある Ｎｏ Ｙｅｓ 保険情報一致判定 （履歴） 過去名寄せされた氏名 も履歴として保持 結婚等で姓が変わった 場合も遡って突合 Ｙｅｓ Ｎｏ 一致 Ｙｅｓ Ｙｅｓ Ｙｅｓ 一致 新規 一致 生年月日が一致 カナ氏名が一致 （履歴） Ｎｏ 一致 不一 致 新規 Ｎｏ 新規 新規 新規 ３．１．名寄せ処理項目 強 名寄せキー 個人番号 医療機関ID 患者ＩＤ 保険者番号 被保険者記号 被保険者番号 生年月日 性別 カナ氏名 弱 利用メリット 藍住町内で有効な一 意のＩＤ 同一医療機関であれ ば一意で患者ＩＤで 管理されており、名 寄せに有効 履歴による管理あり デメリット 藍住町民以外は付番 されないため無効 他医療機関の場合は 履歴がないと判別で きない 対象 備考 健診データ保健センターのデータのみ有効 レセプト 個人ごとに過去受診した医療機関、患 検査結果 者ＩＤの履歴管理を実施 被保険者番号と組合 せることにより個人 を特定できる 履歴による管理あり 扶養家族がいる場合 は同一被保険者記号、 レセプト 被保険者番号となり 検査結果 一意として識別でき ない 同一保険証内で個人 双子の場合は識別で を特定するために有 きない レセプト 効 同一保険証内で個人 双子（一卵性双生 を特定するために有 児）の場合は識別で 効 きない 同一保険証内で双子 ー の場合に特定するた めに有効 履歴による管理あり レセプト 同じ保険証情報を持っている場合に、 レセプト 同じ生年月日の場合の区別に使用（双 子など） ３．２．例）名寄せ処理の流れ方 Cassandra 糖尿病管理システムよりレセプトデータ投入 レセプトデータ 患者IDが既に存在する場合 患者IDと医療機関が一致 名寄せデータベース 99990001 患者番号 A大学 医療機関 カナ名称 レセ タロウ カナ名称 5301 保険者番号 5301 保険者番号 性別 1 性別 1 性別 生年月日 3540201 生年月日 3540201 生年月日 99990001 患者番号 99990001 患者番号 A大学 医療機関 A大学 医療機関 レセ タロウ カナ名称 レセ タロウ 5301 保険者番号 1 3540201 レセプトデータ 別医療機関の 同一人物のレセプト 名寄せ後 カナ氏名、保険者番号 性別、生年月日一致 A大学の名寄せデータがある 場合 名寄せデータベース 11110001 患者番号 B病院 医療機関 レセ タロウ カナ名称 5301 保険者番号 1 性別 3540201 生年月日 99990001 患者番号 A大学 医療機関 レセ タロウ カナ名称 5301 保険者番号 1 性別 3540201 生年月日 名寄せ後 99990001 患者番号 A大学 医療機関 11110001 患者番号 B病院 医療機関 レセ タロウ カナ名称 5301 保険者番号 1 性別 3540201 生年月日 32 ３．１．名寄せ結果の手修正 患者氏名、生年月日 保険者番号、性別など 検索したい条件を入力 ＜名寄せ検索指示画面＞ ＜名寄せ照会画面の手順＞ ①主導名寄せ対象データの検索・ 参照を行う ②現在のデータ状況の確認を行う ③主導名寄せ画面より、修正情報 の入力を行う ＜名寄せ照会結果画面＞ 検索条件にHITした 内容が表示される。 ④修正された名寄せ情報に基づいて、 疫学データサーバ上のデータの洗 い変えが行われる 名寄せ先と名寄せ対象 のデータを入力し、手動 名寄せを行う ＜手動名寄せ画面＞ 33 ３．１．コホート参加拒否 施設単位での 提供拒否 名寄せサーバ 左の画面にてこの部分への データ提供を拒否している ＜Ⅰコホート提供拒否 施設用＞ 患者単位での 提供拒否 個人情報 サーバ 疫学データ サーバ ＜コホート提供拒否の手順＞ ①各施設からレセプトデータなどの各種データを受け取る。 ②コホート提供拒否の患者または。施設の場合は、疫学データ サーバへのデータﾛｰﾄﾞを行わない 提供拒否するための画面 Ⅰのコホート提供拒否施設用 Ⅱのコホート提供拒否患者用 を用意している。 ＜Ⅱコホート提供拒否 患者用＞ ③すでに疫学データサーバにデータがある患者または、施設の 提供拒否の申し入れがあった場合、疫学データサーバから データを削除する 34 ３．２ システム構成 電子カルテ SS-MIXデータ データ投入・名寄せ ファイル投入API レセプトアップ ロード画面 データ テーブル群 各種 パーサー 大学病院 レセプトアップ ロード画面 共有 DISK 検査結果アップ ロード画面 XML 各種 XML データ 取込エンジン 転置イン デックス テーブル群 参 照 転置インデッ クス生成 更 新 hadoopバッチ 処理 名寄せエンジン レセ電 ファイル 診療所用 画面群 診療所 コホートデータベース Servlet/Tomcat エクスポート バッチ 特定健診アップ ロード画面 保健指導アップ ロード画面 保健指導 画面群 保健センター IIS/SQLServer Cassandra/hadoop 名寄せデータベース 検索 リアルタイム検索 AP側 データ ベース 研究分析 名寄せ データ ベース バッチ検索 MySQL 結果 XML 検索 エンジン 35 ３．２．データの流れ MySQL レセプト 「疫学研究に関する倫理指針」※準 拠のため物理的に分離し異なる データベースへ保存 データ投入・名寄せ SS-MIX 名寄せ情報 医療情報 （保険番号、医療機関コード等） 個人情報 （氏名、生年月日等） 患者個人情報 Cassandra/hadoop 検体検査 特定健診 各コード 数値 標準コードから検索用 のコードを付加 名寄せID レセプト コード ICD10 コード 病名 名寄せID 検査コード 検査コード 検査コード 結果値 結果値 結果値 名寄せID 健診コード 健診コード 健診コード 結果値 結果値 結果値 確定データのため基本的に蓄積するのみ ※ http://www.mhlw.go.jp/general/seido/kousei/i-kenkyu/sisin2.html 36 ３．２．例）病名データの流れ方 Cassandra 糖尿病管理システム レセプトデータ 元病名 データ 2014 左側 2014 左側 糖尿病性 白内障 2504006 糖尿病性 白内障 2014 左側 2504006 2504006 糖尿病性 白内障 E143 ICD-10コードを付加 検索用病名 傷病名マスタ 修飾語マスタ 除外マスタ レセ電 レセ電 レセ電 マスタ 2504006 糖尿病性 白内障 2014 左側 2014 左側 2504006 糖尿病性 白内障 E143 E143 対応するICD-10コード レセプトデータから病名マスタ、修飾語マスタを参照し、検索に必要な ICDコードを付与し、除外マスタにより不要な修飾語を取り除いている 37 コードマスタ参照一覧 レセプト /SSMIX 主たる行為 元データ 診療行為情 診療行為コード 報 医薬品情報 医薬品コード レセプトデータ 傷病名情報 傷病名コード 保険情報 DPC情報 診断群分類コード 病院独自 薬剤情報 HOT9コード 検査結果情 JLAC10コード 報 SSMIX 病名情報 MEDISコード 保険情報 - 入退院歴情 病棟コード 報 来院情報 診療科コード 参考資料保管場所 変換参照データ サイト：診療情報提供サービス 資料名：オンライン又は光ディスク等による請求に 医科診療行為マスタ 係る記録条件仕様（医科用）内の診療行為レコー ドの４番目の診療行為コード（資料P１８内） 医薬品マスタ サイト：診療情報提供サービス 資料名：オンライン又は光ディスク等による請求に 医薬品HOTコードマスタ 係る記録条件仕様（医科用）内の医薬品レコード の４番目の医薬品コード（資料P２０内） サイト：診療情報提供サービス 資料名：オンライン又は光ディスク等による請求に 傷病名マスタ 係る記録条件仕様（医科用）内の傷病名レコード の２番目の傷病名コード（資料P１７内） × × × × 医薬品マスタ 静岡県版電子カルテ情報ゲートウェイデータ交換 医薬品HOTコードマスタ 仕様書第１版内の薬剤/処置オーダ定義（P４０内） 静岡県版電子カルテ情報ゲートウェイデータ交換 仕様書第１版内の検査結果セグメント定義（P２６ × 内） 静岡県版電子カルテ情報ゲートウェイデータ交換 仕様書第１版内の患者病名情報セグメント定義（P 傷病名マスタ ２６内） 静岡県版電子カルテ情報ゲートウェイデータ交換 × 仕様書第１版内の保険セグメント定義（P８内） 静岡県版電子カルテ情報ゲートウェイデータ交換 仕様書第１版内の患者来院情報セグメント定義（P × ２０内） 静岡県版電子カルテ情報ゲートウェイデータ交換 仕様書第１版内の患者来院情報セグメント定義（P × ２０内） 診療情報提供サービスhttp://www.iryohoken.go.jp/shinryohoshu/downloadMenu/ MEDIShttp://www2.medis.or.jp/hcode/ 提供元 サイト：診療情報提供サービス 資料名：医科診療行為マスター内の３番目の診療行為 コード サイト：診療情報提供サービス 資料名：医薬品マスター内の３番目の医薬品コード サイト：MEDIS標準マスター 資料名：医薬品HOTコードマスターのMEDIS西暦 _HOT9.TXT内の９番目のレセプト電算コード サイト：診療情報提供サービス 資料名：傷病名マスター内の３番目の傷病名コード × × サイト：診療情報提供サービス 資料名：医薬品マスター内の３番目の医薬品コード サイト：MEDIS標準マスター 資料名：医薬品HOTコードマスターのMEDIS西暦 _HOT9.TXT内の９番目のレセプト電算コード × サイト：診療情報提供サービス 資料名：傷病名マスター内の３番目の傷病名コード × × × ３．３．採用技術と特徴 コホート分析に必要な要件 大量データの集積が高速である 増大するデータに対しスケールアウト可能なデータス トアが必要である 経年に渡るデータの保全性が必要 大量データの高速処理が必要 経年に渡る保守費等が発生しない（オープンソースの 利用） キーバリューストアである Cassandraの採用 並列処理フレームワーク hadoop Map/Reduceの採用 39 ３．３．Hadoop ３．３． Hadoop と Cassandra の採用 Hadoop（分散並列バッチ処理基盤）の特徴 • 実績ある大量データの並列処理フレームワーク • 大量データ処理の効率化 • 小規模から開始可能 Cassandra（分散型データストア）の特徴 • • • • • サーバー追加による処理能力および保存容量の増強 小規模（可用性に合わせて1～3台）から開始可能 高い可用性 基本的なデータベース機能（カラム型） Hadoopと連携可能 医療情報・システム分野では先行して導入（2011/06/21現在） 40 ３．３．Cassandra ３．３． Cassandraについて について データの保全性 レプリケーション 単一障害点のない P2P 方式 耐障害性と負荷分散の確保ためにデータのレプリカ を保持する 大量データのバックアップ運用の軽減 クラス ター 負荷分散 41 ３．３．従来のRDBMS ３．３．従来の RDBMSと とKVS KVSの比較 の比較 分類 大量データ 処理 分散型 Key-Valueストア リレーショナルデータベース 複数ノード（サーバ）に分散し保持するた め大量データを扱うことが可能 ハイスペックなマシン及びストレージが必要かつ 設計、設定が個別に必要となる 負荷分散 複数ノードに分散したデータに対し平行処 理が可能 スケールアップで対応、もしくはパーティション、ク ラスタ等の対策が必要。 拡張性 ノードを追加することによりスケールアウト が容易に可能 一般的にスケールアウトは不可能 可用性 ノード間で複製を持ち合うことで可能 ノード追加のみのため低コストである クラスタ構成で実現可能であるが高コストである トランザク ション データ完全性（ACID）の保障がRDBMSよ りも緩い、アプリケーション側で考慮する 必要あり RDBの仕組みとして保障されている 検索・集計 柔軟な検索は不可、集計などの処理もア プリケーション側で考慮する必要がある 複雑な検索及び集計についてはSQLを使用し 可能 42 ３．３．Apache ３．３． Apache Hadoopについて Hadoopについて データ処理を複数のサーバーで分散させ、並列に 実行 処理はMapReduceパターンに則って実装 大量データのデータ処理時間を短縮 分散データストアと組み合わせて使用 言語にはJavaを使用 Google の MapReduce フレームワークのOSS （Open Source Software）クローン OSS の分散並列処理のデファクトスタンダード 43 ３．３．Cassandra/ ３．３． Cassandra/Hadoop Hadoopの の コホートデータベースへの活用 病院・診療所 診療データ収集 検査データ収集 数年間で数億件 分析データストア 抽出条件指定 抽出用クエリ ファイル 抽出クエリ ファイル生成 抽出処理 Cassandra 抽出結果 XML BIツール 分析サーバ 研究機関 Cassandra 増大するデータを格納するた めにスケールアウト可能な可 用性を持ったデータストア hadoop hadoop データ抽出に必要なIndexを hadoopを使用して生成し抽出 44 ３．３．Hadoop ３．３． Hadoop・・Cassandraを用いた分散構成 Cassandraを用いた分散構成 MapReduce バッチ処理 Internet 必要に応じて RDBMS と連携 分散データストア Web/AP サーバー クラスター クラスター ［Cassandra］ ［Apache、Tomcat、 （Hadoop も同居） IIS、ASP.NET］ RDBMS / DWS 45 ３．３．分散処理・拡張性の高い データベースシステム hadoop 部分 JobTracker Cassandra 部分 サーバ追加後 レプリケーション開始 分散処理によりデータ処理の高速化を実現 TaskTracker TaskTracker TaskTracker TaskTracker Cassandra Cassandra Cassandra Cassandra … コホートデータベース サーバを追加することによりデータ 領域拡張性を確保 46 ３．３．分散処理・拡張性の高い データベースシステム コホートデータベース ・・・ 参加医療機関が増えた 健康保険B病院 場合容易にサーバ追加 ＋ レセプト電算 複数のサーバが連携して1つのシステムとして稼働 匿名化 複数のサーバが処理を分担して処理 名寄せデータベース ・・・ SS-MIX レセプト電算 新規参加病院 ＋ 診療情報データベース A大学病院 SS-MIX 参加医療機関が増えた 場合容量を増やす必要 レセプト電算 47 ３．３．サーバ追加 コホートデータベースサーバ追加の判断 扱うデータ（レセプトデータ、SS-MIX）のサイズ A大学病院の実測結果（レセプト3年分及び1ヶ月あた りのSS-MIXデータ）⇒5年100GBを想定 作業領域を考慮すると大学病院5施設追加でサーバ を増加する必要がある。 名寄せサーバのストレージ追加 DBMSのストレージリソース監視により判断 現状容量は300GB⇒数千万人までは問題ない容量 48 ３．３．データ数と検索時間の比較 検索時間（秒） ＜検索条件＞ レセプトデータから、一意のDPCコード（14桁）をキーにしてレコードを抽出。 ※ 抽出したレコードの容量は、1件あたり839ｂｙｔｅ ＜予測値の計算方法＞ 3ヵ月分のデータ容量に対して、検索を実施した時間を基準値（3秒）とします。 データ容量の増加分（12か月分、36か月分）の比率を基準値に乗じて、検索時間の予測値としています。 40 35 30 25 20 15 10 5 0 36 12 7.9 3 ３ヵ月分 １２ヶ月分 レセプトデータ容量 13 実測値 予測値 データ量の増大に対し検索時 間はあまり増えていない ３６ヶ月分 データ量が増えても検索速度が落ちにくいデータベースシステム 49 ３．４．コホートデータ分析 重症化・合併症化モデル 生活習慣病 血管病変 重症化・合併症 1次予防 糖尿病 2次予防 糖尿病性血管障害 糖尿病性網膜症 網膜光凝固術 硝子体手術 糖尿病性腎症 人工透析 蛋白尿期 腎不全期 非透析期 透析期 糖尿病性 神経障害 壊疽・潰瘍 閉塞性末梢動脈 疾患 脳血管疾患 急性期 術後 虚血性心疾患 急性期 術後 がん 50 Ａ．１．ICTふるさと元気事業と Ａ．１．ICT ふるさと元気事業と 地域ICT 地域 ICT利活用広域連携事業の位置づけ 利活用広域連携事業の位置づけ ICTふるさと元気事業 ICTふるさと元気事業 予防 糖尿病 合併症 ICT利活用広域連携事業 ICT 利活用広域連携事業 壊疽・網膜症・腎症 等 がん 併存症 脳卒中 心筋梗塞 51 保健センターでの活用方法 52 保健センター 保健センター 国保連合会 特定保健指導支援 • 健診データ分析 • 指導記録の保管 特定保健指導の業務支援と健診結 果のデータ分析を行う 健康指導 管理 データ ベース データ ベース 特定健診 データ 目的・役割 時系列/カレンダー表示 特定健診 医療機関 • 職員の健康情報の管理 • 健診データ分析 • 職員への健康指導・管理 受診・治療 ITシステムの活用 • ダッシュボード • コールセンター 特定保健指導 健康指導 患者・健診者 指導対象患者の抽出画面 特定保健指導書類作成画面 53 保健センター 保健センター システムを用いた業務フロー 特定健診 ①指導対象者抽出 ②対象者情報参照 ・階層、検査値等を指定して抽出 ・特定健診の結果を参照 ・過去の保健指導内容を参照 将来的には 医療機関の検査・ 処方も表示する ③指導書類印刷 保健指導 ④指導書類保存 ・指導書類を印刷（現在８つ） ・宛名印刷も可能 ・書類をシステムに保存 ・どの対象者の書類かを システムが自動判別 54 保健センター 保健センター 指導対象者抽出 階層化の 結果別に抽出 宛名印刷 ②クリックして 抽出実行 階層化の 結果を色分け 検査結果の 異常値を赤表示 ④指導対象者をクリックして参照画面へ ① 抽 出 条 件 を 入 力 ③ 抽 出 結 果 の 一 覧 が 表 示 さ れ る 55 保健センター 保健センター 対象者情報参照 ～ 時系列表示 ～ 時系列で表示 ３月１７日に保健指導を実施 昨年９月９日に特定健診を実施 ３月２１日に講習会あり クリックして指導書類の印刷画面へ クリックして参照画面へ 56 保健センター 対象者情報参照 ～ カレンダー表示 ～ 時系列表示とカレンダー画面を切り替え可能 57 保健センター 保健センター 指導書類印刷 ①クリックして文書を選択 ・初回アンケート用紙 ・栄養相談記録用紙 ・ケース記録表 ・経年表（定期健康診断結果） ・運動習慣がつく教室同意書 ・運動チェック表 ・運動実施記録 ・健康のもと食生活を考えよう 相談同意書 ②ボタンをクリックして印刷 58 保健センター 保健センター 指導書類保存 ①スキャナで書類を取込み、 デスクトップ等に一時保存 バーコード ※書類の種類や対象 者を選択しなくても バーコードより自動で判 別される。 ②一時保存した ファイルを選択 ③選択した書類が 表示される ④補足説明を 入力可能 ⑤ボタンをクリックして保存 59 診療所での活用方法 60 診療所 検査結果、処方内容の管理 ①．検査結果とレセプトをシステムに取り込む 検査結果 ウイルス チェック レセプト ②．検査結果の一覧、処方内容の一覧を参照す る。 プライベートクラウド ダッシュボード グラフ 診療所より自院の診療データを閲覧 61 診療所 検査結果、処方内容の 検査 結果、処方内容の管理 管理 ～ダッシュボード～ 指定した条件に一致する患者を表示しま す。画面の初期条件は設定で変更できるよ うにします。 ヘッダーをクリックすると、 その項目でソートします。 患者情報をクリックして、検査結果 のグラフ表示画面に移動します。 検査結果の詳細画面へ移動しま す。 紹介状作成のための文書管理シス テムを起動します。 62 診療所 検査結果、処方内容の 検査 結果、処方内容の管理 管理 ～グラフ～ 検査結果簡易画面 患者編集 検査結果時系列表示 検査結果グラフ印刷 グラフは基準値から の相対値で描画 ※１検査結果一覧でチェックを付けた項目が対象 63 診療所 検査結果、処方内容の管理 処方のアイコンをクリックすると この画面が表示されます。 処方・処置の内容は1ヶ月分が毎月末日の 日付でまとめで表示 ※ レセプトから処方・処置内容を取り込むため 64 診療所 文書管理（紹介状、診断書作成） A大学病院 ①．様式を元に文書を作成 （患者基本情報はシステムが自動補完） 文書 様式取込 PDFで保存 ②．作成した文書を参照・印刷・管理 文書管理 文書 65 診療所 文書管理（定型文書） ～ 作成画面 ～ 入力完了した文 書はPDFで保存 できます。 青色の欄は自由入力 黄色の欄は病院情報シス テムとの連携による自動入 力可能 66 ２．診療所 ２．２．文書管理（定型文書）） ２．２．文書管理（定型文書 ～ 現在運用中の文書 ～ 高度画像診断センターFAX予約票 医療センター紹介状 FAX予約票 PET/CT検査依頼票 B病院紹介状 C病院紹介状 D病院紹介状 E病院紹介状 F病院FAX予約票 G眼科紹介状 H小児科紹介状 67 診療所 病院データ 病院 データ閲覧 閲覧 ～ポータル画面～ 処方アイコンをクリック 注射アイコンをクリック 検査アイコン をクリック 68 診療所 病院データ 病院 データ閲覧 閲覧 ～文書・画像参照～ 病院側 W 診療所側 X P エクセル、ワード、PDF等の文書を日付を 指定して登録可能 JPEGの画像も登録可能 添付された文書・画像はPDFで参照可能 ファイルはZip形式でダウンロード可能 69 コホートデータ分析 重症化・合併症化モデル 生活習慣病 血管病変 重症化・合併症 1次予防 糖尿病 2次予防 糖尿病性血管障害 糖尿病性網膜症 網膜光凝固術 硝子体手術 糖尿病性腎症 人工透析 蛋白尿期 腎不全期 非透析期 透析期 糖尿病性 神経障害 壊疽・潰瘍 閉塞性末梢動脈 疾患 脳血管疾患 急性期 術後 虚血性心疾患 急性期 術後 がん 70 分析モデル 検査 糖尿病患者 継続受診 合併症なし HbA1c アルブミン タンパク尿 合併症 12-10ヶ月前に 糖尿病受診あり 網膜症 腎症 神経障害 閉塞性末梢動脈疾患 合併症あり 合併症新規 脳血管疾患 当月に合併症あり 過去12ヶ月に 合併症なし 虚血性心疾患 癌 眼科手術 透析 壊疽・潰瘍 12-10ヶ月前に 糖尿病受診なし 合併症既存 投薬 新規受診 インスリン 経口 当月に合併症あり 過去12ヶ月に 合併症あり 71 まとめ EHR,PHRを運営するための組織ガバナンスが 必要である コミュニティにおける行政・民間病院・公的病院の役割 個人情報の取り扱いルール システム設計 PHR EHRのシステムアーキテクチャ 医療情報の標準化データを意識した設計 72