「SDMコンソーシアムの役割とその社会的な背景」(PDF形式 3365KB)

SDMコンソーシアムの役割と
その社会的な背景
岐阜大学大学院医学系研究科
医療情報学分野
紀ノ定保臣
100(%) Manufactures
Integration of IT

Business Services
(Banks, etc.)

インターネットの登場
高速通信回線の低廉化
一般家庭への普及
モバイル網の高速化と多様化
スマートフォンの浸透
クラウド技術の発展
膨大で多様なデータの活用
(ビッグデータ)

1980

Public Services
(Health, etc.)
1990
2000
2010
IT as gadget

Trojan horse networks

Final full integration of ICT in Business (Re-Engineering, Law, ...)
医療の質向上に向けたビッグデータの活用
A)
「医療の質向上に向けたビッグデータの活用」を因数分解する
→ 「医療の質」、「質の向上」、「ビッグデータ」、「活用」
①
「医療の質」の定義:
「構造(ストラクチャー)」
「過程(プロセス)」
「成果(アウトカム)」
A. Donabedianが提唱(1966年)
②
質を向上させるための手法
→
「構造・過程・成果」の改善
③
特に「過程(プロセス)」が重要

マネジメントが必要
④
「過程(プロセス)」の改善

ビッグデータの活用
ビッグデータとは
1.既存の技術では管理することが困難なデータ
+ Value:価値
2.管理することが困難になる要因 : 3V
・ Volume : データの量が大きいこと
・ Variety :データの種類が多様である
診療記録のテキストデータ,検査の数値データ,画像など
(non-structured data)
(structured data)
・ Velocity: データの発生頻度(速度)や更新の頻度が速いこと
3.データの特性と技術について
・ 3Vの面で管理が困難なデータ(データの特性)
・ それらのデータを蓄積・処理・分析するための技術
・ それらのデータを分析し,有用な意味や洞察を引き出せる人材や組織
4.ビッグデータを蓄積・処理・分析するための技術
・ 大規模データを効率よく,高速に処理する基盤技術(例:Hadoop)
・ 柔軟で拡張性に優れたデータベース技術(例:KeyーValue,NoSQL)
・ 機械学習
・ 統計解析
5.データサイエンティスト
・ データを分析し,有用な意味や洞察を引き出せる人材や組織
バランス・スコアカードの視点から見た
医療ビックデータ活用型リアルタイム・ダッシュボード・システム
Balanced
Scorecard
Clinical Data
Repository
EMR
Real Time
Dashboard
Finance (財務)
Outcome(成果)
Process (過程)
Structure(構造)
View
病院全体として・・・
地域全体を見ながら
経営
医療の質
オーダー・実施内容は?
外来・病棟機能は?
患者プロファイルは?
患者ADL?,医療コスト?
患者
スタッフ
診療情報
クリニカルパス
分析力が競争力となる時代の到来
・ データ分析に基づく意思決定
・ サービスの開発力
・ 経営判断
・ サービスの設計
など
ビッグデータの課題
・ 統計・データ分析の専門家不足
・ プログラミングの高度化・多様化
・ セキュリティ・マネジメントに対する懸念
【ビッグデータ時代の要素技術:Hadoop】
・HDFS(Hadoop Distributed File System)
:分散ファイルシステム
・MapReduce : 分散処理フレームワーク
・大量に,深く,素早くを支える
【次世代のBIツール】
・大規模リアルタイムデータ分析基盤(リアルタイムDWH)
医療の質向上に向けたビッグデータの活用
B)
「医療の質向上に向けたビッグデータの活用」を因数分解する
→ 「医療の質」、「質の向上」、「ビッグデータ」、「活用」
①
「医療の質」の定義:
「構造(ストラクチャー)」
「過程(プロセス)」
「成果(アウトカム)」
②
質を向上させるための手法
③
特に「過程(プロセス)」が重要

マネジメントが重要
④
「過程(プロセス)」の改善

ビッグデータの活用
⑤
活用するための手法
→
→
「構造・過程・成果」の改善
「価値(Value)ある情報」を取り出すこと
診療現場にマネジメントを導入する
Management
Process(過程)
・管理
・Administrative Process(管理過程)
・経営
・Clinical Process(診療過程)
医療の質向上
診療過程の可視化・分析・課題の発見・改善
収益の向上に貢献
保険診療のルールを理解
診療録の記載
診療録の保存
診療録管理
診療情報管理
※看護記録・その他諸記録を含む
診療過程の可視化・分析・課題の発見・改善
(プロセス改善型アプローチ)
診療過程の可視化
医事会計システム/オーダエントリ-システム/電子カルテシステム
分析
DWH(データウェアハウス)/Dash Board(ダッシュボード)
課題の発見
データ・サイエンティスト/診療情報管理士
改善
PDCA/病院長のリーダシップ
医療ビッグデータ
・診療データの活用
・医療の質向上
・患者満足度の向上
データサイエンス
・統計科学
・データマイニング
・プロセス改善
データマイニング
・分類分析
・クラスタ分析
・アソシエーション分析
診療過程の可視化・分析・課題の発見・改善
(仮説アプローチ)
課題の明確化
仮説のアプローチ(課題解決の目的・仮説・検証・分析/手段)
データの収集
医事会計システム/オーダエントリ-システム/電子カルテシステム
どのようなデータが必要か
分析
DWH(データウェアハウス)/Dash Board(ダッシュボード)
改善
PDCA/病院長のリーダシップ
ロジックツリーの活用
・目的:課題の解決
・仮説:仮説の検証
・手段:分析
何を明らかにすれば良いのか
データサイエンス
・統計科学
・データマイニング
・プロセス改善
データマイニング
・分類分析
・クラスタ分析
・アソシエーション分析
データを分析するシステムの概要
ETL
DWH
データマート
E: データの抽出
T: 変換
L: 移行
データウェアハウス
使用頻度の多い
データセット群
関連システム
ER図の作成
医事会計
各種データマート群
オーダ
エントリ
電子カルテ
変換・加工処理
データの抽出
薬剤部門
ファイル転送
文書管理
検査部門
放射線部門
:
:
看護部門
手術部門
その他
:
:
:
BI・分析
ツール
OLAP, ピボットテーブル
岐阜大学医学部附属病院における医療情報システムの概要等について
医療情報システムの沿革について
1.2004年6月1日 病院の開院,電子カルテシステムの運用開始
2.2010年1月1日 第2期電子カルテシステムの運用開始(機能に変更なし)
電子カルテシステム<IBM/CIS>を中心としたマルチベンダー方式
特徴
・電子カルテ端末は光ファイバーネットワーク網に直結している
・ネットワークシステムは院内で閉じており,
保守用のネットワークシステムを除いて,外部接続は認めていない
説明事項
・医療情報システム(ハード・ソフトウェアシステム)の全体概要
・電子保存に係る三基準(真正性,見読性,保存性)の説明
・ID管理と利用者権限について
新規採用者の場合:職員番号を人事係から入手,指静脈パターンを登録
(指静脈が故障した場合に備え,パスワードも登録)
継続職員の場合 :誕生月毎に,資格の確認と更新
職員が移動した場合 :職員マスターのフラグを使って失効管理をしている
・パスワードの更新について
当院では「指静脈認証」を利用しており,更新はなし
地域医療連携・介護・保健
医療連携センター
総合医療相談
岐阜大学医学部附属病院・病院情報システム概念図
地域医療連携
システム
(細菌検査含む)
輸血管理部門
システム
薬剤部門システム
(調剤・注射支援)
手術部門
システム
麻酔記録
システム
周産期部門
人工腎部門
眼科部門
耳鼻科部門
口腔外科科部門
放射線部門
レポートビュー
SOAP・ROS
クリニカル
コックピット
オープンビュー
システム
(画像管理含む)
光学医療診療
案内表示板
自動再来受付シ
ステム
自動入金システム
電子カルテシステム
病理検査部門
システム
支援DWH
基幹システム
診療支援(部門)システム
検査部門
患者サービス
臨床研究・治験
診療支援DWH
看護情報
クリニカルパス
インフォームド
コンセント
ドキュメント
ビュー
経営管理・物流
医事会計システム
共通機能
部門システム
病院経営管理システム
物品管理/物流管理システム
オーダリングシステム
ICU /HCU
システム
ERシステム
看護情報支援
システム
・内服処方(入外)オーダ ・内視鏡検査オーダ
・放射線検査オーダ
・注射処方オーダ
・標準病名・術式オーダ
・処方オーダ
・リハビリオーダ
・検体検査オーダ
・生理検査オーダ
・病理検査オーダ
・輸血オーダ
・血液浄化オーダ
・再診予約オーダ
・入院予約オーダ
・物品オーダ
・手術オーダ
・食事・栄養指導オーダ
病院内ネットワークシステム
リハビリ部門
システム
人事・労務
人事管理
給与管理
認証
病棟
蓄尿システム
栄養部門
システム
インシデント管理システム
治験・感染管理
院内メール
患者モニタリングシステム
ナースコールシステム
13
電子カルテシステム等における時刻同期の仕組みについて
POMRに基づいたカルテ記載方法
POMR (Problem Oriented Medical Record)は,次の5つの作業段階:基礎データ,
問題リスト,初期計画,経過記録,退院時要約・要約記録から構成される。
ア:基礎データ(data base)
•
主訴,現病歴,既往歴,家族歴など
•
生活像,診察所見,検査成績
イ:問題リスト(problem list)
•
ナンバーとタイトルを付ける
•
activeとinactiveの区別を付ける
ウ:初期計画(initial plan)
•
診断的計画(diagnostic plan)
•
治療的計画(therapeutic plan)
•
教育的計画(educational plan)
エ:経過記録(progress note)
• 叙述的記録(narrative note)
S(subjective data): 主観的データ(患者の訴え)
O(objective data) : 客観的データ(診察所見,検査成績)
A(assessment)
: 評価(医師の判断,考察)
P(plan)
: 計画
• 経過一覧表(flow sheet)
オ:退院時要約,要約記録
(discharge summary, summary note)
診療録等について
POMR(Problem Oriented Medical Record)形式の
診療録を採用した電子カルテシステム(IBM社製)
NAMDA-I(問題リスト)-NOC(計画と成果)-NIC(介入計画)
を基本とする看護支援システム(フィリップス社製)
部門システム群からのその他諸記録(多ベンダー)
看護記録構成要素とクリニカルパス
患 者 基 礎 情 報
問題リスト
計 画
医学診断
治療計画
看護診断
看護計画
経過記録
退院サマリー
(ナーシングチャート)
(ナーシングチャート)
クリニカルパス
*記録の構成要素を、看護の専門性の観点から、日本看護協会が提唱している記録の
5構成要素で表現する。 ( 岐阜大学医学部附属病院 看護部 )
*健康保険法・診療報酬にかかわる看護記録の構成要素は3構成要素である
入院基本料算定要件
1. 入院診療計画
– 医師、看護師等の共同により入院診療計画を
策定し、患者に説明し、文書で同意を得る
– 総合的な入院診療計画であること
2. 院内感染防止対策
3. 医療安全管理
4. 褥瘡対策
5. 栄養管理体制
傷病名
看護
症状
治療計画
検査内容及び日程
手術内容及び日程
推定される入院期間
特別な栄養管理の必要性
医師
看護師
管理栄養士
栄養
19
入院診療計画書から期待されること
入院時
入院中
退院時
傷病名
傷病名
傷病名
症状
症状
症状
治療計画
治療(実施)
治療(結果)
検査計画
比較可能
検査(実施)
比較可能
検査(結果)
手術計画
手術(実施)
手術(結果)
入院日数
入院日数(実際)
入院日数(結果)
栄養管理
栄養管理(実施)
栄養管理(結果)
入院診療計画書を作成する能力とエビデンスが求められる
入院時
入院中
退院時
傷病名
傷病名
傷病名
症状
症状
症状
治療計画
治療(実施)
治療(結果)
検査計画
比較可能
検査(実施)
比較可能
検査(結果)
手術計画
手術(実施)
手術(結果)
入院日数
入院日数(実際)
入院日数(結果)
栄養管理
栄養管理(実施)
栄養管理(結果)
電子カルテデータに基づく質指標から見た外来看護の変化
-外来看護必要度のデータと看護ケアデータの経年変化から見た報告-
【看護の変化】外来での手術オリエンテーション、入院の準備の説明など、外来看護師の役割
の増加
【在院日数の短縮】在宅療養に必要な自己管理のための指導の増加
【患者の高齢化】↑
【入院中にセルフケア能力の確立が出来ない】看護計画立案件数の増加、看護計画説
明件数の増加
【継続看護が必要な患者】↑
【医療依存度の高い患者の増加】ドレーン留置、在宅酸素、人工呼吸器装置、輸液ポンプ、
心電図モニターの使用等、その他の医療機器、医療用品、循環コントロール、呼吸コントロール、
呼吸ケアの必要性が増加
【転倒・転落防止の予防、移動時の介助、見守りの必要な外来患者】↑
安全ケア、移動ケアの増加
【看護師の予防意識】↑
意思決定支援
→
カンファレンスの実施 →
看護計画の立案・説明 →
用語の定義の再確認
看護の質向上
質評価の提示
データが活用できる病院になるためには
1) データが取り出せるシステムが必要
① 取り出せるデータを普段から作っておく
② DWH と ダッシュボード
2) データを分析することができるシステムと人材が必要
① データ分析ツール
② データ分析ツールを使いこなせる人材(データサイエンティスト)
3)
データを分析し,分析結果を知識にする組織文化が必要
① 組織戦略としての取り組みが不可欠
② 継続性が必要であり,組織の文化にすることが重要
4) 分析結果に基づいた病院運営のマネジメントが必要
① データを活用することにより,人材が育ち,ツールが充実する
② 「マネジメント」を正しく理解し,実践する組織力は強くなる
5) そのような取り組みが,成功しなければならない
① マネジメント運営が成功しなければ,職員はついてこない
② 「マネジメント」を理解している職員を増やすことが重要
診療データの効果的な活用と医療の質報告書へ
Data
Capture
Export
(データの
取り出し)
(データの
キャプチャー)
Patient data
Patient data
患者データ
(決められた
ルールで計算)
Individual
Quality
Report
Calculating
Engine
患者個々について
医療の質のレポート
医療の質についての
統計的計算
EHR
Patient data
Calculate
e-measure
Information
患者個々について
医療の質の評価基準
Report
(報告書
の作成)
Aggregate
Quality
Report
組織としての
医療の質に関する
報告書
Quality Reporting Standards (in USA)
HLA : CDA (CCD, CDA, QRDA)
eMessage : NQF(National Quality Forum), QDM(Quality Data Model)
http://www.qualityforum.org/QualityDataModel.aspx
Meaningful Stage 2 :
HL7 consolidated CDA implementation guide (www.hl7.org)
手術部門におけるValue Chain
1.手術室の効率的な運用
2.周術期の効果的な管理
3.病棟における適切な退院時期の決定
数値データが精度良く取得できる環境の整備
手術室の問題点
1.患者が手術室に在室中,責任区分が明確でない時間帯が存在する
2.予定手術時間を大きく超過する手術例が存在する
手術室における時間区分の定義の厳格化
時間区分の定義
麻酔準備完了時刻
:
麻酔導入およびライン確保等が終了し,体位確保、麻酔器の移動
などを開始する時刻
手術予定在室時間
硬膜外麻酔時間
:
:
外科系診療科医師が手術申込時に申告する手術室在室予定時間
患者入室から硬膜外麻酔終了まで
麻酔準備時間
:
患者入室から麻酔準備終了時刻まで
手術準備時間
:
麻酔準備終了時刻から手術開始まで
診療科時間
:
麻酔準備終了から手術終了まで
手術終了から麻酔終了まで
在室時間
:
手術室入室から退室まで
(保険請求上の)
手術時間
手術室退室
:
手術
準備時間
麻酔終了
覚醒時間
麻酔
準備時間
抜管
手術終了から抜管まで
線
X撮影
:
手術終了
抜管時間
(保険請求上の)麻酔時間
手術開始
麻酔開始から麻酔終了まで
体位確保
:
麻酔準備終了
麻酔時間
在室時間
麻酔開始
手術開始から手術終了まで
硬膜外麻酔
:
手術室入室
手術時間
3時間ルール
• 目的
– 正確な術前評価や綿密な準備により,予定手術時間を正確に申告
し,手術の質を向上させる。また医療資源の効率利用も促す。
• 手術
– 予定申告時間よりも3時間以上延長(短縮)した場合に,
その理由を手術室に提出する
• 麻酔
– 90分以上麻酔導入に要した場合に,理由を提出する
• 平成18年9月より施行した
3時間ルールの導入効果
400
150
300
100
Gap
200
50
100
2007. 2Q
2006. 4Q
2006. 2Q
2005. 4Q
2005. 2Q
2004. 4Q
0
2004. 2Q
0
在室時間
麻酔時間
手術時間
予定
麻酔準備
手術準備
延長率
Reproducible Research
SDMとは
Semantic Data Modeling
意味を考慮したデータモデリング
セマンティックス
データモデル


意味
データの構造
現状のDWHの問題点
• 複数のシステムのデータが統合されていないため、それぞれのデータ抽出の負荷
が大きい
• 項目名と定義、構造が統一されていないため、抽出したデータが関係づけられ
ない
• テーブルごとに粒度と頻度がまちまちであるため、指標を算出することができない
• 検索ツール側で加工されており、特定の検索ツールを用いないとデータを抽出
することができないため、非定型の検索ができない
• 独立したデータベースとサーバーを持っていないため、抽出元のシステムが停止
すると検索ができない
• モデリングされたデータ構造を持っていないため、検索に時間がかかるうえ全文
検索ができない
• セマンティックスを意識していないため、意味が違う項目が並んでいて、ユーザー
が選択と並べ替えをする必要がある
SDMの特徴:可視化データベース
日付など、定義が必要なものは定義という項目
を作り、データに定義の内容を記入する。
(例)検査日定義:検体採取日
アプリケーション層
ETL
項目名(タグ)と内容を一致させる
(例)項目1→血糖値
データウエアハウス層
ビジネス
インテリジェンス層
SDM
データウエアハ
ウス
ベンダー固有
データベース
構造がCSV=可視化
列に項目(タグ)、行に履歴(データ)
コードデータは文字データへマスター変換
(例)病名コード:C349 → 肺癌
2値、1,0を、+,-へ変換
(例)そばアレルギー:+
データモデリングにより高速化
身体計測
アレルギー
感染症
CASE_ID
プロファイル
CASE_ID
血液検査
生化学検査
RECORD_ID
TRANSACTION_ID
細菌検査
免疫・血清検査
RECORD_ID
TRANSACTION_ID
病理検査
腫瘍マーカー
RECORD_ID
TRANSACTION_ID
内視鏡検査
レポート
RECORD_ID
TRANSACTION_ID
DPC様式1
RECORD_ID
TRANSACTION_ID
注射
レジメン
RECORD_ID
TRANSACTION_ID
記事
RECORD_ID
TRANSACTION_ID
基本情報
CASE_ID
個人情報
CASE_ID
生理検査
RECORD_ID
TRANSACTION_ID
放射線検査
核医学検査
RECORD_ID
TRANSACTION_ID
透析
輸血
処置
RECORD_ID
TRANSACTION_ID
病歴
DPC・Eファイル
紹介
DPC・Fファイル
DPC・Dファイル
予約受診
RECORD_ID
RECORD_ID
RECORD_ID
RECORD_ID
RECORD_ID
RECORD_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
処方
注射
指導
RECORD_ID
TRANSACTION_ID
手術
放射線治療
リハビリ
RECORD_ID
TRANSACTION_ID
看護度
看護計画
看護必要度
看護記事
RECORD_ID
RECORD_ID
RECORD_ID
TRANSACTION_ID
TRANSACTION_ID TRANSACTION_ID
トランザクション
インデックス
TRANSACTION_ID
診断
RECORD_ID
TRANSACTION_ID
病名
RECORD_ID
TRANSACTION_ID
サマリー
RECORD_ID
TRANSACTION_ID
入院
移動
カレンダー
RECORD_ID
TRANSACTION_ID
所見
RECORD_ID
TRANSACTION_ID
クリニカルパス
RECORD_ID
TRANSACTION_ID
インフォームド
コンセント
RECORD_ID
TRANSACTION_ID
個人情報テーブル
利用は可能、
出力は不可
セカンド
オピニオン
RECORD_ID
TRANSACTION_ID
文書
RECORD_ID
TRANSACTION_ID
コミュニケーション
RECORD_ID
TRANSACTION_ID
看護日誌
看護サマリー
バイタル
看護指示
経過記録
ワークシート
材料
RECORD_ID
RECORD_ID
RECORD_ID
看護指示受け
経時記録
RECORD_ID
RECORD_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
RECORD_ID
RECORD_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
検索速度向上のための設計ルール
• 全体を1つのER図で表現する
• トランザクションインデックスは
各テーブルのサブセット
• 階層を減らす
• 処方のレシピ(RP)は薬品のテーブルへ記
載してRPテーブルを削減
• マスターは変換した結果を記載して削減
• 列数の多いテーブルは垂直分割をする
• プロフィールなどはグループで分割
(アレルギー、感染症など)
• 行数の多いテーブルは水平分割する
• 記事、文書系など、意味が違うものを別
テーブルにする
• カレンダーテーブル(日次)を作成する
• 周術期における相対日、入院期間における
相対日などの計算を簡素化する
• キー日時(KEY_DATE)を各テーブルに設置し、
高速インデックスに設定する
• 検索は期間を絞り込むのが一般的であるた
め
• 集計の軸になる項目はあらかじめインデックス
を付与する
• 症例ID、病棟、診療科など集計の単位に
なる項目のインデックス化
データモデリングにより高速化
身体計測
アレルギー
感染症
CASE_ID
プロファイル
CASE_ID
血液検査
生化学検査
RECORD_ID
TRANSACTION_ID
細菌検査
免疫・血清検査
RECORD_ID
TRANSACTION_ID
病理検査
腫瘍マーカー
RECORD_ID
TRANSACTION_ID
内視鏡検査
レポート
RECORD_ID
TRANSACTION_ID
DPC様式1
RECORD_ID
TRANSACTION_ID
注射
レジメン
RECORD_ID
TRANSACTION_ID
記事
RECORD_ID
TRANSACTION_ID
基本情報
CASE_ID
個人情報
CASE_ID
処方
注射
指導
RECORD_ID
TRANSACTION_ID
手術
放射線治療
リハビリ
RECORD_ID
TRANSACTION_ID
看護度
看護計画
看護必要度
看護記事
RECORD_ID
RECORD_ID
RECORD_ID
TRANSACTION_ID
TRANSACTION_ID TRANSACTION_ID
トランザクション
インデックス
TRANSACTION_ID
サマリー
RECORD_ID
TRANSACTION_ID
入院
移動
カレンダー
RECORD_ID
TRANSACTION_ID
診断
RECORD_ID
TRANSACTION_ID
病名
RECORD_ID
TRANSACTION_ID
生理検査
RECORD_ID
TRANSACTION_ID
放射線検査
核医学検査
RECORD_ID
TRANSACTION_ID
透析
輸血
処置
RECORD_ID
TRANSACTION_ID
病歴
DPC・Eファイル
紹介
DPC・Fファイル
DPC・Dファイル
予約受診
RECORD_ID
RECORD_ID
RECORD_ID
RECORD_ID
RECORD_ID
RECORD_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
所見
RECORD_ID
TRANSACTION_ID
クリニカルパス
RECORD_ID
TRANSACTION_ID
インフォームド
コンセント
RECORD_ID
TRANSACTION_ID
個人情報テーブル
利用は可能、
出力は不可
セカンド
オピニオン
RECORD_ID
TRANSACTION_ID
文書
RECORD_ID
TRANSACTION_ID
コミュニケーション
RECORD_ID
TRANSACTION_ID
看護日誌
看護サマリー
バイタル
看護指示
経過記録
ワークシート
材料
RECORD_ID
RECORD_ID
RECORD_ID
看護指示受け
経時記録
RECORD_ID
RECORD_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
RECORD_ID
RECORD_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
TRANSACTION_ID
テーブル定義のルール
• 項目(タグ)名はデータの内容を表す表現と
する
• 例:○ GENERAL_ANESTHESIA 、
•
× MASUI_1
• コードの場合マスター変換の結果とともに記
録する
• 例:DISEASE_CODE C349 DISEASE
肺癌
• フラグの場合テキストに変換する
• 例:○ CLINCAL_OUTCOME 軽快
•
× 5
• 2値の場合+-で表現する
• 例:○ FOOD_ALLERGY +
•
× 食物アレルギー 1
• あいまいな項目名の場合、その定義をデータ
として記録する
• 例: KEY_DATE_DEF 検体採取日
• 各レコードには必ずオーナーを記録する
• 2次利用における稟議規定には必須
• キーは抽出元を特定するキー、テーブルの行
を特定するキー、上位階層のテーブルのキー
を記録する
• 全テーブルのリレーションが表現できる
モデルの実現のため
SDMの基礎
Fundamentals of Semantic Data Model for Healthcare
SDMによる課題解決
• 項目名と定義、構造が統一されているため、複数のシステム
からのデータを統合でき、ユーザー負担を劇的に軽減できる
• すべてのテーブルが一つのER図で関連付けられているので、
検索ツールに依存することがなく、非定型検索が可能となる
• 独立したデータベースとサーバーを持つため、カルテ停止時
においても診療情報を検索することができる
• データモデリングの手法を用いているため、データベースの
能力に頼らずに、高速な全文検索をすることができる
• 項目名と定義、構造が統一されていて検索ツールに依存しな
いため、ユーザー間で分析手法の交換が可能となる
• セマンティックスモデルを用いているため、必要な項目だけ
が簡単に抽出できる
SDMコンソーシアムの役割
• SDM-DWH利用者の情報交換を推進
•
•
•
•
•
セミナーの主催
イベントへの参加
ユーザー会の主催
会員への情報発信
知識データベースの作成と運営
• SDM-DWHを用いた情報利用技術者の育成
•
•
•
•
勉強会の主催
研修の設置と運営
資格認定
プロジェクト斡旋
SDM設計
• 共通項目
•
•
•
•
•
キーと階層
個人IDと名寄せID
キー日時
コードとフラグ
オーナーの概念
• 項目の特徴
• 履歴の表現方法
• 固定項目と可変項目
• 縦持ちと横持ち
• テーブルの特徴
•
•
•
•
•
•
•
•
•
個人情報テーブル
オーダー共通テーブル
カレンダーテーブル
レポートテーブル
患者系テーブル
オーダー系テーブル
カルテ系テーブル
看護系テーブル
部門系テーブル
診療情報DWHを実現するSDM
SDM データウエアハウス
Semantic Data Model Data Warehouse
アプリケーション・データ
層
研究データ
部門データ
医事データ
固有データ
共有領域
ODBCインターフェース、CSVファイルインターフェース
データウエアハウス
層
レプリカ
研究データ
診療データ
レプリカ
部門データ
レプリカ
診療データ
レプリカ
医事データ
マッピング
SDM
診療データウエアハウス
ODBCインターフェース、CSVファイルインターフェース
ビジネスインテリジェンス層
レポート
分析
ストラクチャー
クォリティー
プロセス
アウトカム
指標
研究
レプリカ
固有データ
SDM データウエアハウス
Semantic Data Model Data Warehouse
アプリケーション・データ
層
臨床試験
診療
健診
データウエアハウス
層
レプリカ
臨床試験
介護
精神科
共有領域
ODBCインターフェース、CSVファイルインターフェース
レプリカ
診療
レプリカ
健診
レプリカ
介護
マッピング・名寄せ
SDM
データウエアハウス
ODBCインターフェース、CSVファイルインターフェース
ビジネスインテリジェンス層
災害・障害対
策
研究・分析
ストラクチャー
クォリティー
プロセス
アウトカム
臨床試験
地域医療
レプリカ
精神科
SDMを利用した原本機能
システム更新における原本保存の方法(PDF方式)
新カルテで必要な項目のみ移行
旧カルテ
新カルテ
PDF保存
電子サイン
外部認証局
システム更新における原本保存の方法(参照カルテ方式)
新カルテで必要な項目のみ移行
旧カルテ
参照カルテ
新カルテ
システム更新における原本保存の方法(SDM)
旧カルテ
①
②
SDM
新カルテ
③
電子キー
④
①旧カルテの全データのレプリカを作成し、ETLにより診療情報をSDMとして保存
②SDMから新カルテで必要な項目のみを移行
③診療データ単位で、データそのものから電子キーを生成し、別テーブルに保存
④原本出力の際に再度電子キーを作成し、保存してあるキーと一致することを証明
SDMを利用した名寄せ機能
症例ID、名寄せIDを用いることにより、複数の施設の症例情報を一元管理することが可能
健診施設
医療機関
介護施設
マッピング
マッピング
マッピング
目的別レポート作成
【施設単位】→施設内IDで集計
SDM
施設IDと施設内IDからユニークな症例IDを生成
個人情報を用いた同一症例の特定→名寄せID
【行為単位】→症例IDで集計
【疾病単位】→名寄せIDで集計
SDMの個人情報保護と名寄せ方式
A施設
③
①
SDM
症例ID、名寄せ
ID
B施設
③
②
①
SDM個人情報
アクセス権により管理
出力不可
施設ID、個人ID
名前、生年月日
性別、社会保険ID
血液型、住所
緯度経度
①個人を特定する情報をセキュアなテーブルへ登録
②症例ID、名寄せIDを生成
③個人情報を除いたETL(症例ID、名寄せIDで管理)
社会保
険ID
一致
同一人
不一致
生年月
日
不一致
別人
一致
緯度経
度
一致
同一人
不一致
目視
一致
同一人
SDM 臨床試験データウエアハウス
Semantic Data Model Clinical Trial
アプリケーション・データ
層
臨床試験
データ
部門データ
診療データ
被験者
データ
医事データ
臨床試験運用層
⑤
ETL
①
ETL
SDM
臨床試験DWH
④オーダー
処方・注射
GCP
SOP
DBT
IRB
治験プロトコル
意思確認
適格判定
同意取得
被験者選定
③
被験者登録
⑥
検索
⑦
CDISK
②スクリーニング
適格・除外
症例報告
eCRF
⑧
マイニング
臨床試験利用層
治験
臨床研究
医療機器
Translation
Research