SlideShare a Scribd company logo
1 of 35
Download to read offline
国立病院機構本部
IT推進部 医療情報データベース企画室長
堀口 裕正
※第36回医療情報学連合大会 COI開示
開示すべきCOIはありません。
国立病院機構における
電子カルテデータ標準化について
0
• 平成26年6月24日に閣議決定された「世界最先端IT国家創造宣言」では、
地域を越えた国民への医療サービスの提供等を可能とする医療情報利
活用基盤の構築を目指し、医療情報連携ネットワークについては、電子カ
ルテを含めたデータやシステム仕様の標準化等を行い、平成30年度まで
に全国への普及・展開を図ることとされている。
• しかしながら、電子カルテについては、ベンダー毎で開発が行われ、各病
院が使いやすいようにカスタマイズされるなど、電子カルテデータの形式
が標準化されないまま普及したことから、電子カルテ上で使用されている
病名や医薬品等のコードがベンダーや病院で異なり、標準化の課題と
なっている。
• 今回の『電子カルテデータ標準化等のためのIT基盤構築事業(13.0億
円)』は、このような問題を解消するため、各病院の電子カルテデータを厚
生労働省の定める標準コードに紐付けするデータマッピングを行い、SS
-MIX2規格(標準化ストレージ機能)を用いて電子カルテデータの標準
化を実施し、その工程を示したドキュメント(手順書)を作成・公開すること
を目的としている。
補助金事業の事業背景
ドキュメント(手順書)の作成
S社電子カルテ T社電子カルテ U社電子カルテ
病院間でばらつきのある電子カルテデータを標準化させるため
国立病院機構本部が中心となってデータマッピングを実施
主要なベンダーや多くの疾病領域について対応可能な精度の高いドキュメント
を作成するために、41病院で電子カルテデータ標準化事業を行う。
SS-MIX2標準化ストレージ
標準的なデータ形式で保存
事業内容
補助金事業の概要 (課題・目的等)
2
事業の成果(標準化の普及促進関係)
• 最新のSS-MIX2Ver1.2cに完全準拠しているモジュールが41病院に
導入
• SS-MIX2 Ver1.2cモジュールの導入
• SS-MIX2に完全準拠しているモジュール
• HOTコード・JLAC10・ICD10など標準コードを全面的に導入・活用
• 従前のモジュールで課題となっていたベンダー毎の表記ゆれ等の問
題が解決され、データ形式の標準化が可能となります
• 本モジュールは6ベンダーから他の医療機関にも(有償にて)提供可
能です。
• 他の医療機関が厚生労働省標準規格に準拠(SS-MIX2・標準コード
等)したシステムを導入するに当たり、当該事業で作成したドキュメン
ト(手順書)を活用することにより、専門的な知識を要することなく、簡
便に導入することが可能となります。
3
事業の成果(標準コード及び標準化団体)
• 標準規格が持つ課題を標準化団体とともに解決
• HOTコード・・・一般名処方用や持参薬用のコードの整備を
MEDISに依頼
• JLAC10コード・・・体温等の検査コードの採番依頼
• SS-MIX・・・各種規約の矛盾や、解釈について整理をJAMIに依
頼
4
今回のプロジェクトのコンセプト
• 補助金事業として13ヶ月という短納期で仕上げる必要が
ある。
• 標準化の普及促進に資することを目標とする
以上の条件から以下のコンセプトで事業を実施した
• 検証環境での十分なテスト/検証を行い病院別の開発
を極力行わない
• 病院における医療提供に係るユーザーインターフェイス
は一切変更しない
5
主な作業区分 内容
①マッピング作業(出⼒データ内
容の標準化)
対象41病院を選定し、データマッピング作業を実施
する
②病院側SS-MIX2出⼒様式の正規
化(拡張部分を含む)
全てのSS-MIX機能(メッセージ)に対応できるよう、
モジュールを各ベンダで正規化(⼊⼒値の正規化・フ
ルセット化等)する。併せて標準仕様以外の拡張デー
タ(バイタル等)が出⼒できるようにする
③病院側SS-MIX2モジュールの導
⼊
①で選定した対象病院に②で作成したSS-MIX2モ
ジュールを導⼊する
④本部診療情報データベースシス
テム構築
データを収集する仕組みを検討し、外部データセン
ターにデータベースを構築する
⑤作業⼿順書の作成 本プロジェクト終了後、各病院がSS-MIX2を効率的に
導⼊できるよう、SS-MIX2モジュールを導⼊するベン
ダが作業⼿順書を作成する(⼿順書は公開予定)
⑥データ利⽤に係る検討(ユー
ザーWG)
システム機能とユーザーの要望について調整する
データベースの利⽤に係る規定(プロセスやルール)
や具体的なデータ利⽤⽅法を検討する
方 針
国立病院機構のDB事業概要 (プロジェクト概要)
6
各病院の電子カルテマスタを標準マスタと紐付けする作業
ストレージ
データベース
SS-MIX2を用いた診療情報データベース構築プロジェクト 作業区分①~⑥
データセンター(DC)
病院が正しいデータを出力するた
めの詳細手順書を作成
(公開)
拡張
ストレージ
標準化
ストレージ
アプリケーション
研究用に必要な情報を収集
(病院から本部までの回線は既存
HOSPnet回線を利用)
拡張
ストレージ
標準化
ストレージ
拡張
ストレージ
標準化
ストレージ
②病院側SS-MIX2出力様式の正規化
(拡張部分を含む)
各病院の入力データを
そのまま保存
マッピング作業チェック (標
準マスタ化、検査値等標準
化)
処理速度向上のためイン
デックス整理
病院の電子カルテマスタ 標準マスタ
対応
※病名、薬品名、検体検査等々、各病院での運用形態
を考慮した上での膨大なマッピング作業が必要。
S社電子カルテ
T社電子カルテ
U社電子カルテ
①マッピング作業(出力データ内容の標準化)
A病院 γ-GTP
B病院 Gamma-GTP
3B090000002327101
γ-GT(γ-GTP)(可視吸光光度法
3B090000002399901
γ-GT(γ-GTP)(その他)
④本部診療情報
データベース構築
⑤病院側作業手順書
の作成
匿名化、
抽出して
提供
研究
診療情報分析 経営情報分析
⑥データの利用に係る検討
(ユーザーWG)
・データ利用に係る運用方法
(対象者、利用手続き、データの提供方法等)
・データ利用の方法
③病院側SS-MIX2モジュールの
導入
7
本部(各部門)
病院(研究者等)
・ 患者基本情報、担当医、
病名、受診科、検査情報等
・ 退院サマリ(医師)、
看護サマリ、バイタル等
○IT基盤の構築における技術的課題及びその対応策を明示
○標準化技術活用などによる費用低廉化モデルとして提示
⇒データ標準化の普及促進
本事業に期待される効果
7
HOSPnet
8
IT基盤構築の仕組み (標準化、IT基盤とは)
n 本事業では、各病院の電子カルテシステムのデータをSS-MIX2 Ver.1.2c形式に変換(標準化)
し、診療情報データベースに収集する仕組み(IT基盤)を構築します。
n このIT基盤は、各病院に導入するSS-MIX2サーバと、機構本部(データセンター)に導入する本
部診療情報データベースシステムから構成されます。
機構病院
SS-MIX2モジュール
電⼦カルテシステムに⼊⼒された
⽇々の診療情報をSS-MIX2
Ver.1.2c形式に変換して蓄積・
保存
電⼦カルテシステム
診療⽇時、診察内容、処置内容、
検査内容など、様々な診療情報
を蓄積・管理
機構本部
(データセンター)
本部診療情報
データベース
41病院分のデータを
収集・蓄積・保存・加⼯・分析
9
SS-MIX2を⽤いたIT基盤構築事業参加病院⼀覧
500床以上 350〜499床 349床以下 複合(その他) 障害病床中⼼ 総計
富⼠通
6病院
⾦沢医療,名古屋医療,
⼤阪医療,九州医療,
⻑崎医療,熊本医療
5病院
横浜医療,相模原,
千葉医療,⼩倉医
療,別府医療
1病院
南和歌⼭医療
6病院
北海道医療,⻄群
⾺,東京,⻑良医療,
村⼭医療,福岡東
医療
4病院
東埼⽟,医王,
三重,広島⻄
医療
22
⽇本電気
2病院
北海道がん,埼⽟
3病院
旭川医療、帯広、
⾼知
1病院
仙台⻄多賀 7
ソフトウェ
ア・サービス
5病院
⾼崎総合,四国が
ん,九州がん,嬉野
医療,⿅児島医療
1病院
⽶⼦医療
1病院
⾼松医療
7
⻲⽥医療情報
2病院
⻄新潟中央、
敦賀医療
2
SBS
1病院
静岡医療
1病院
天⻯
2
⽇本IBM
1病院
仙台医療
1
総計 7 13 3 11 7 41
ベンダ・病院種別分布
北海道東北 関東信越 東海北陸 近畿 中国・四国 九州 総計
6病院 11病院 7病院 3病院 5病院 9病院 41病院
地域毎
101010
n 院内コードと標準コードを紐付ける対応表を作成します(マッピング作業)。
n 病院毎に異なる院内コードを、標準コードに変換することにより、他病院と連携した診療情報
の分析等が可能になります。
院内コード ⇔ 標準コード
112233 ⇔ 無し
A病院 A社電子カルテ
院内コード ⇔ 標準コード
A0101 ⇔ 無し
B病院 B社電子カルテ
院内コード ⇔ 標準コード
9900 ⇔ A111
C病院 C社電子カルテ
出力データ
出力データ
出力データ
現状(イメー
ジ)
院内コード ⇔ 標準コード
112233 ⇔ A111
A病院 A社電子カルテ
院内コード ⇔ 標準コード
A0101 ⇔ A111
B病院 B社電子カルテ
院内コード ⇔ 標準コード
9900 ⇔ A111
C病院 C社電子カルテ
出力データ
出力データ
出力データ
マッピング後(イメー
ジ)
病院個別の運用 ⇒ ○
他病院との情報連携 ⇒ ○
情報連携による研究、分析 ⇒ ○
病院個別の運用 ⇒ ○
他病院との情報連携 ⇒ ×
情報連携による研究、分析 ⇒ ×
院内コード
標準コード
どちらも連携不可
標準コードで
他病院との
情報連携可能
病院におけるマッピング作業
名称 院内コード 標準コード 単位 ID 日付 院内コード 値
γGTP 602347 3B090000002327101 IU/ℓ 98002 150128 602347 45
標準コード 院内コード 名称 値 単位
3B090000002327101	 602347 γGTP 45 IU/ℓ
電子カルテ
データ標準化のイメージ(SS-MIX2出力)
マスターテーブル 結果テーブル
SS-MIX2データ
SS-MIX2出力データ
①フォーマット変換②正規化フィルター
③固有要因
プログラム
標準化
プログラム
マッピング作業:
JLAC10コードを入力。ここ
が空欄になっているのを
埋める作業を実施
マスターテーブル 結果テーブル
(検体検査)
(細菌検査)
(生理検査)
SS-MIX2出力デー
タ
…
…
①フォーマット変換:電子カルテのフォーマットをSS-MIX2フォーマットに変換する
②正規化フィルター:例えば、同一検査で単位が混在している場合、標準とされる単位に変換する(白血球検査で「個/μℓ」と「×10²個/μℓ」が混在している
場合、標準の単位が「個/μℓ」であれば、院内電子カルテ上で「×10²個/μℓ」の単位にて表されている「値」については、×100してSS-
MIX2出力データとする)。他には、使用している文字コードが違う場合、標準とされる方にあわせて変換する、など。
③固有要因プログラム:病院独自の検査表示など実施している場合、出力時に標準に合うように変換する。
マスターテーブル 結果テーブル
マスターテーブル 結果テーブル
①②は標準化プログラムとして電子カルテ6ベンダーにて開発。
③は各病院における電子カルテ導入業者が開発。
電子カルテデータからSS-MIX2データへ変換する際、対象とな
るカテゴリーは(検体検査)など数十個存在。
すべてのカテゴリーを変換する標準化プログラムについて、確
認・検証する必要がある。
…
…
白血球 602560 2A010000001966201 ×10²個/μℓ 98002 150128 602560 49 2A010000001966201 602560 白血球 4900 個/μℓ
標準化
外部委託検査項目(検査会社にコード
情報を依頼)
紐付ける標準コードに選択の余地のな
い検査項目
検査技師に定型質問をし、標準コード
を判別する検査項目
検査技師に非定型質問をし、標準コー
ドを判別する検査項目
検査項目2000~3000件/病院
うち、SEが機械的に入力できる項目50%
標準コード(JLAC10コード:17桁)うち、最初の5
桁は「分析物コード」を示し、検査種別を表して
いる。
マッピング作業内容別検査項目類型
11
③固有要因
プログラム
名称 院内コード 標準コード ID 院内コード 値
ムンプスウイルスIgG 13610 5F432143102302304 98002 13610	 4.0(+)
標準コード 院内コード 値
5F432143102302304	 13610 4.0
5F432143102302311 - (+)
電子カルテ
SS-MIX2変換プログラムの構成
マスターテーブル 結果テーブル
SS-MIX2データ
SS-MIX2出力データ
①標準・フォーマット変換②正規化フィルター
単位・文字等を標準型に変換
標準化
プログラム
(ベンダ標準)
標準化
12
A病院
B医療センター
C医療センター
名称 院内コード 標準コード ID 院内コード 値
ムンプスウイルスIgG 001590 5F432143102302304 20056 001590 0.6 (-)
標準コード 院内コード 値
5F432143102302304	 001590 0.6
5F432143102302311 - (-)
SS-MIX2出力データ
名称 院内コード 標準コード ID 院内コード 値 クラス値
ムンプスウイルスIgG 3113 5F432143102302304 446 3113 2.0(±)
標準コード 院内コード 値
5F432143102302304	 3113 2.0
5F432143102302311 - (+-)
SS-MIX2出力データ
差分吸収プログラムで、4.0と(+)を分ける
差分吸収プログラムで、2.0と(±)を分ける
既に値とクラス値が分かれてテーブルにあるため、
差分吸収プログラムは不要
n ①②の標準化プログラムは他の施設でも使用する汎用的なもの。
n ③の固有要因プログラムについては病院固有のもの。
ベンダー側が構築する標準化プログラム①②に固有要因プログラム③の機能が含まれていると、その病院でしか使用できない(汎用化されてい
ない)ことになり、普及促進を図る手順書としての品質は不可。
→複数病院で標準化プログラムを運用して、それが汎用的なものであること(病院固有の変換機能が入っていないこと)を確認する必要がある。
※①②③のプログラムの著作権はベンダーにあるため、コード等中身を見ることができない。よってNHOが結果により確認する必要がある。
値の表記が、病院独自[例‥値+クラス値が一体化]となっているため、差分吸収プログラムで別々に表
示する。(※クラス値‥ある項目において、基準値をもとに値を規定(例えば、ムンプスウイルスIgGでは、
2.0未満は(-)、2.0~3.9は(±)、4.0以上は(+))。
固
有
要
因
吸
収
プ
ロ
グ
ラ
ム
固
有
要
因
吸
収
プ
ロ
グ
ラ
ム
検査結果の表記揺れについて
病院の部門システム等から発生する検査結果表記に関しては以下のような揺れが
あります。今回、病院のモジュールでその揺れを標準的記法に統一しました。
1.検出限界超の値 [> 100(半角の>,スペース,100)]
2.検出限界以上の値 [>= 200(半角の>,半角の=,スペース,200)]
3.定性値(−)[ -(スペース2つ,半角の-)]
4.半定量値 [ 1 +(スペース,1,スペース,半角の+)]
13
100< 100 < 100< 100 < >100 > 100 >100 > 100
200≦ 200 ≦ 200<= 200 <= 200=< 200 =< 200<= 200 <=
200=< 200 =< 200以上 200 以上 ≧200 ≧ 200 >=200 >= 200
=>200 => 200 >=200 >= 200 =>200 => 200 200~ 200↑
- (-) フケンシユツ インセイ 陰性 検出せず 検出セズ
- (-) フケンシュツ ミケンシュツ ミケンシユツ ケンシユツセズ ケンシュツセズ
1+ (2+) (4+) 5+ (++) +++ (++++) +++++
検査結果の変換について
検査
分離前
JLAC10
検査値のパ
ターン
検査結果の
例
分離後
JLAC10-1
分離後
JLAC10-2
検査結果
1
検査結果
2
麻疹ウイル
ス ウイルス
抗体IgG
5F4311431023
02304
数値(記
号)[文字列]
2.0(-)未満
5F43114310230
2304
5F4311431023
02311
数値[+文
字列]
記号
鼻汁好
酸球
2A300000
006360411
(記号)数
値
(2+)60%
2A3000000
06360411
2A3000000
06360402
記号 数値
14
検査項目(参考) JLAC10 単位
尿量 1A005000000192001 mL
末梢血液一般検査 - 赤血球数 2A990000001930951 .10*4/uL
末梢血液一般検査 - 白血球数 2A990000001930952 /uL
各JLAC10においてどのような検査値をどのような単位で記載すべきか、どのように表記すべ
きかについて、マスターを提供・公表しました。
検査結果の変換について
15
• 検査結果をどう変換すればよいのか、その考え方と、マスターをホ
ームページや手順書内で公表しています。
• これらの実装が各ベンダーのモジュールとして病院依存せず、きち
んと機能するかどうかについてはNHO本部において検証環境を構
築して病院に依存せずに確認をしております。
検証環境におけるテスト
• 今回の事業を実施するため、本部に6ベンダーの電子カ
ルテシステムをレンタルして各種検証を行った。
• すべての電子カルテに同じ処方オーダーを登録すると、
そのデータがどう扱われて、SS-MIXデータに変換あされ
るのかについて、電子カルテの画面入力からスタートす
るテストを行って、各社の違いを確認した上で開発調整を
行っている。
• これにより、NHO41病院に限らず、汎用的に使えるモジュ
ールになるように開発を行った。
16
病院側の負担について
• 昨年3月の病院募集時において試算したところ、病院へ
のモジュールの導入費用900万〜1000万、翌年度以降の
(保守・利用料等の)病院負担額は年額100万円以内と設
定
• 初期投資についてはベンダー側初期提案額から1〜2割
の低減を行った。(平均700万円)
• 本事業内で低廉化について調整したところ全病院年額20
万円台で運用できることで調整がついた
• 電子カルテ更新時のコストについては今後とも交渉を行
っていくが、さらなる低廉化がはかれるよう努力していく。
17
データベースについて
【国立病院機構 診療情報集積基盤】
(コクリツビョウインキコウ シンリョウジョウホウシュウセキキバン)
英文表記 NHO Clinical Data Archives
省略形の記載法 「NCDA」
省略形の呼称 「クリニカルアーカイブス」
41病院で来院患者ベース 94万人/年 17,800床のデータベース
18
19
0
100,000
200,000
300,000
400,000
500,000
600,000
700,000
800,000
900,000
1,000,000
1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
来院患者数(実数)の推移
NCDAシステムフロー
各病院は標準化(拡張)ストレージ/標準化(拡張)トランザクションス
トレージ/インデックスDBの5つを作成
通常時、前日のTRストレージを本部システムが取りに行き、エラーチェ
ックして本部DBに取り込む
不定期に本部のDB内のデータと病院の標準化(拡張)ストレージに齟
齬が無いかバリデーションを行う(患者単位で実行可)
TRストレージでのデータ転送により大量の小さいファイルを転送せず
に済み、通信コストが大幅に減る
1日〜2日遅れでの取り込みとなり、リアルタイム性は望めない
SS-MIX2 標準化ストレージの構造
21
(出典)SS-MIX2 標準化ストレージ構成の説明と構築カ◌゙イト◌゙ライン
トランザクションストレージ
3.3 3.3.1
トランザクションストレージとは
「標準化ストレージ」は患者(患者 ID)を特定してから、当該患者の診療情報を検
索するこ とに特化した物理構造を採用している。しかし、
n 1 何らかの理由で標準化ストレージ再作成しなければならない場合
n 2 災害発生時への対策や地域医療連携の基盤として、外部接続回線を用いてデータセ
ンター等の当該医療施設外に標準化ストレージの複製を作成する場合
n 3 標準化ストレージ以外のシステムにおいて、本ガイドラインで定めた病院情報システム
からの伝送データが再利用できると考えられる場合
上記のようなケースでは、診療情報がトランザクションとして標準化ストレージに記
録された日時(以下「トランザクション発生日時」という)に着目して診療情報を参照
することが必要であると考えられる。 したがって、ここでは、病院情報システムか
ら送出される標準化された診療情報そのもの をデータソースとして再利用するこ
とによる便宜を考慮して、トランザクション発生日時により診療情報を参照するこ
とに特化したストレージとして、トランザクションストレージを規定する。
22
(出典)SS-MIX2 標準化ストレージ構成の説明と構築ガイドライン
トランザクションストレージ
23
(出典)SS-MIX2 標準化ストレージ構成の説明と構築カ◌゙イト◌゙ライン
NCDAにおけるエラーチェック
データ転送後、DB取り込み前に行うエラーチェックは大きく以下の2つ
構文エラー
n SS-MIX2の仕様を満たしているかチェック
n 型は正しいか、必須項目抜けは無いか、行の順番は合ってるか、項目毎のLengthは守
られているか etc
n NHOの要求した仕様を満たしているかのチェック
n 標準コードは入っているか
n SN型にあった記載がされているか
毎日チェックした上でエラーを画面に報告、対処を行う
NHOのエラーについては、無視してDBに取り込むことが可能
NCDA本部DBでのデータ修正
基本SS-MIX2の使用に則って、DEL及びINSのSS-MIX(HL7)メッセージを作って登録
することでエラー修正を行う。
これにより保存されているファイルからデータベースが再現可能となる
各種成果ドキュメント
https://github.com/nhoHQ/SSMIX2_support_documents
にて公表
26
DB設計の際に考慮したこと
HL7要素がすべて格納されること
→オブジェクト型のDBを利用する
検査結果が抽出可能であること
→検査結果を単一の値では無く範囲で持つ
いつ抽出作業を行っても同じ結果が出るようにすること
→すべてのデータにデータ利用可能状態を示す情報に時
間範囲を持たせることで実現
抽出処理を行う際にSQL言語が使えること
参考)postgreSQLにおける範囲型
2013年に組み込みの型としてリリース
(23,34]と記載すると23より大きく34以下という意味となる
中の値としては数値型とtimestamp型が利用可能
‘(3,7)’::int4rangeもしくはnumrange(1.0, 14.0, ‘(]’)と書く
併せて専用の関数が定義されている。
参考)postgreSQLにおける範囲関数
演算
子
説明 例 結果
= 等しい int4range(1,5) = '[1,4]'::int4range t
<> 等しくない numrange(1.1,2.2) <> numrange(1.1,2.3) t
< 未満 int4range(1,10) < int4range(2,3) t
> より大きい int4range(1,10) > int4range(1,5) t
<= 以下 numrange(1.1,2.2) <= numrange(1.1,2.2) t
>= 以上 numrange(1.1,2.2) >= numrange(1.1,2.0) t
@> 範囲を包含する int4range(2,4) @> int4range(2,3) t
@> 要素を包含する
'[2011-01-01,2011-03-01)'::tsrange @>
'2011-01-10'::timestamp
t
<@ ・により範囲が包含される int4range(2,4) <@ int4range(1,7) t
<@ ・により要素が包含される 42 <@ int4range(1,7) f
&& 重複する(共通点を持つ) int8range(3,7) && int8range(4,12) t
<< 厳密に左に位置する int8range(1,10) << int8range(100,110) t
>> 厳密に右に位置する int8range(50,60) >> int8range(20,30) t
&< 右側を越えない int8range(1,20) &< int8range(18,20) t
&> 左側を越えない int8range(7,20) &> int8range(5,10) t
-|- 隣接 numrange(1.1,2.2) -|- numrange(2.2,3.3) t
+ 結合範囲 numrange(5,15) + numrange(10,20) [5,20)
* 交差範囲 int8range(5,15) * int8range(10,20) [10,15)
- 差分範囲 int8range(5,15) - int8range(10,20) [5,10)
関数 戻り値型 説明 例 結果
lower(anyrange)
範囲の要素
の型
範囲の下
限
lower(numrange(1.1,
2.2))
1.1
upper(anyrange)
範囲の要素
の型
範囲の上
限
upper(numrange(1.1,
2.2))
2.2
isempty(anyrange) boolean
空の範囲
か?
isempty(numrange(1.
1,2.2))
false
lower_inc(anyrange
)
boolean
下限は内
包されてい
るか?
lower_inc(numrange(
1.1,2.2))
true
upper_inc(anyrang
e)
boolean
上限は内
包されてい
るか?
upper_inc(numrange(
1.1,2.2))
false
lower_inf(anyrange
)
boolean
下限は無
限大か?
lower_inf('(,)'::dateran
ge)
true
upper_inf(anyrange
)
boolean
上限は無
限大か?
upper_inf('(,)'::dateran
ge)
true
病院におけるSS-MIX2のデータ精度について
• NHO内の研究チームにおいて本事業の開始「前」から導入さ
れているSS-MIX2モジュールでのデータ精度を調査
• 電子カルテや検査部門システムに残っている検査結果のデ
ータとSS-MIXのストレージ内のデータに齟齬が無いか調査
• 4病院で、それぞれランダムに100人選んでカルテレビュー調
査をおこなった。
• 結果、データの一致率は98%を超えた
• NHOとしてのデータ精度の結論
• データは、間違い無く記載されている。表記の統一がきちんとさ
れているかは別の話。
• データを受け取るデータベースシステムがきちんと解釈できるか
どうかの問題。
• 上記2点をなるべく汎用的に解決することに取り組むべき
30
診療情報集積基盤における個人情報取り扱い
1.患者同意
n病院に掲示されている「個人情報の利用目的」に「国立病院機構
診療情報分析基盤での利用」を追加。(平成27年12月中に41病院
で実施済み)
n併せて,ポスター・ちらしでの周知を開始
n患者の利用不可の申出には対応できるシステムとなっている
2.法令対応
n個人情報保護法・独立行政法人における個人情報保護法が来年
施行見込みであり、今後出てくる政令・ガイドライン等に適切に対
応していく
n研究の倫理指針の見直しがとりまとめられる方向なので、適切に
対応していく
n医療等ID/代理機関等の法令改正が行われた場合にも適切に対
応していく
31
診療情報集積基盤における利活用
• 患者に明示した個人情報の利用目的の範囲内で利活用
を進める
• 利活用に際しては「利活用要項」を定め、それに従って利
用を行う
• 利活用要項の骨子は以下の通り
• データベース利用審査委員会を設置。データ利用ついて審
議。
• 利活用は匿名化後が原則
• 研究における利用
• 本要綱を遵守するとともに、倫理規定等の研究に関連する法令やル
ールを遵守する
32
今後の方向性について
• 本事業の成果が他の医療機関での導入がなされるよう
普及促進を図っていくとともに、本事業で集積されたデー
タを「国立病院機構診療情報集積基盤(NCDA:NHO
Clinical Data Archives)」として整備し運用するなかで、我
が国の医療の質向上に資する各種コンテンツ(臨床評価
指標の開発、研究の推進、経営改善のための各種分析
等)としての利活用を進めていきたいと考えています。
33
現在までの成果
• 本事業の先行プロジェクト
においてSS-MIXデータを
使用した論文が平成27年
度、1本掲載されている。
• SS-MIXデータのバリデー
ションについて(前述)の論
文がAccept済、印刷待ち
• 今後も確実に成果を上げ
ていきたい。
34
Original Article
Comparison of Procedure-Based and Diagnosis-Based
Identifications of Severe Sepsis and Disseminated
Intravascular Coagulation in Administrative Data
Hayato Yamana1,2
, Hiromasa Horiguchi2
, Kiyohide Fushimi2,3
, and Hideo Yasunaga1
1
Department of Clinical Epidemiology and Health Economics, School of Public Health, The University of Tokyo, Tokyo, Japan
2
Department of Clinical Data Management and Research, Clinical Research Center, National Hospital Organization Headquarters, Tokyo, Japan
3
Department of Health Policy and Informatics, Tokyo Medical and Dental University Graduate School of Medicine, Tokyo, Japan
Received October 13, 2015; accepted November 15, 2015; released online April 9, 2016
Copyright © 2016 Hayato Yamana et al. This is an open access article distributed under the terms of Creative Commons Attribution License, which
permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.
ABSTRACT
Background: Diagnoses recorded in administrative databases have limited utility for accurate identification of
severe sepsis and disseminated intravascular coagulation (DIC). We evaluated the performance of alternative
identification methods that use procedure records.
Methods: We obtained data for adult patients admitted to intensive care units in three hospitals during a 1-year
period. Severe sepsis and DIC were identified by three means: laboratory data, diagnoses, and procedures. Using
laboratory data as a reference, the sensitivity and specificity of procedure-based methods and diagnosis-based
methods were compared.
Results: Of 595 intensive care unit admissions, 212 (35.6%) and 81 (13.6%) were identified as severe sepsis and
DIC, respectively, using laboratory data. The sensitivity of procedure-based methods for identifying severe sepsis
was 64.2%, and the specificity was 65.3%. Two diagnosis-based methods —the Angus and Martin algorithms—
exhibited sensitivities of 21.7% and 14.6% and specificities of 98.7% and 99.5%, respectively, for severe sepsis. For
DIC, the sensitivity of procedure-based methods was 55.6%, and the specificity was 67.1%, and the sensitivity and
specificity of diagnosis-based methods were 35.8% and 98.2%, respectively.
Conclusions: Procedure-based methods were more sensitive and less specific than diagnosis-based methods in
identifying severe sepsis and DIC. Procedure records could improve disease identification in administrative
databases.
Key words: administrative data; procedure record; severe sepsis; disseminated intravascular coagulation
INTRODUCTION
Severe sepsis and disseminated intravascular coagulation
(DIC) are two critical conditions associated with high
mortality.1–4
Sepsis is defined as a systemic inflammatory
response to an infection, with the term “severe sepsis” used
to describe sepsis complicated by acute organ dysfunction.4
DIC is characterized by the widespread activation of
coagulation, which results in intravascular formation of
fibrin and ultimately thrombotic occlusion of vessels.2,3
Scoring systems using clinical laboratory tests to diagnose
DIC have been proposed and validated.5–8
In addition to
clinical studies, large administrative databases have been used
to investigate the epidemiology of severe sepsis and DIC.9–15
Despite the widespread use of administrative databases,
there are no established methods that can accurately identify
severe sepsis and DIC in databases. Validation studies
have indicated that extraction of recorded diagnoses from
administrative databases has low sensitivity in identifying
severe sepsis.16–18
Further, previous reports have found
substantial variability in the incidence and severity of severe
sepsis across different extraction methods.19–22
For DIC, no
studies have evaluated the validity of recorded diagnoses.
Some administrative databases record performed procedures
in addition to diagnoses and patient demographics.23,24
Using
this additional information, more accurate identification of
severe sepsis and DIC may be possible. However, there have
been no reports of such methods.
Address for correspondence. Hayato Yamana, MD, MPH, Department of Clinical Epidemiology and Health Economics, School of Public Health, The University
of Tokyo, 7-3-1 Hongo, Bunkyo-ku, Tokyo 113-0033, Japan (e-mail: yamana-tky@umin.ac.jp).
J Epidemiol 2016
doi:10.2188/jea.JE20150286
Advance Publication by J-STAGEAdvance Publication by J-STAGE
JE20150286-1

More Related Content

Similar to 20161121日本医療情報学連合大会 チュートリアル 国立病院機構における電子カルテデータ標準化について

富士市及び富士宮市共同電算化事業 ~ 自治体クラウドの導入 ~
富士市及び富士宮市共同電算化事業 ~ 自治体クラウドの導入 ~富士市及び富士宮市共同電算化事業 ~ 自治体クラウドの導入 ~
富士市及び富士宮市共同電算化事業 ~ 自治体クラウドの導入 ~Yasunobu Fukasawa
 
富士市役所のデスクトップ仮想化 2015年4月版 ~ゼロクライアントとICカード認証の導入~
富士市役所のデスクトップ仮想化 2015年4月版 ~ゼロクライアントとICカード認証の導入~富士市役所のデスクトップ仮想化 2015年4月版 ~ゼロクライアントとICカード認証の導入~
富士市役所のデスクトップ仮想化 2015年4月版 ~ゼロクライアントとICカード認証の導入~Yasunobu Fukasawa
 
富士市役所のクライアント仮想化への取り組み ~ノート型ゼロクライアントとICカードログオン~
富士市役所のクライアント仮想化への取り組み ~ノート型ゼロクライアントとICカードログオン~富士市役所のクライアント仮想化への取り組み ~ノート型ゼロクライアントとICカードログオン~
富士市役所のクライアント仮想化への取り組み ~ノート型ゼロクライアントとICカードログオン~Yasunobu Fukasawa
 
富士市役所におけるCitrix仮想化ソリューション導入成功のポイント ~ノート型ゼロクライアントとICカードログオンの採用~
富士市役所におけるCitrix仮想化ソリューション導入成功のポイント ~ノート型ゼロクライアントとICカードログオンの採用~富士市役所におけるCitrix仮想化ソリューション導入成功のポイント ~ノート型ゼロクライアントとICカードログオンの採用~
富士市役所におけるCitrix仮想化ソリューション導入成功のポイント ~ノート型ゼロクライアントとICカードログオンの採用~Yasunobu Fukasawa
 
介護施設向け管理システム
介護施設向け管理システム介護施設向け管理システム
介護施設向け管理システム修平 大野
 
Azure Office365 Live ID ALLDEAD
Azure Office365 Live ID ALLDEADAzure Office365 Live ID ALLDEAD
Azure Office365 Live ID ALLDEADJuntarou Doi
 
自治体公衆無線LANの防災利用に関する考察
自治体公衆無線LANの防災利用に関する考察自治体公衆無線LANの防災利用に関する考察
自治体公衆無線LANの防災利用に関する考察Toshiya Jitsuzumi
 
介護医療業界におけるマイクロソフトテクノロジー動向
介護医療業界におけるマイクロソフトテクノロジー動向介護医療業界におけるマイクロソフトテクノロジー動向
介護医療業界におけるマイクロソフトテクノロジー動向Daisuke Masubuchi
 
アプリケーションの仮想化で実現した最適なシステム環境(2015/10)
アプリケーションの仮想化で実現した最適なシステム環境(2015/10)アプリケーションの仮想化で実現した最適なシステム環境(2015/10)
アプリケーションの仮想化で実現した最適なシステム環境(2015/10)Yasunobu Fukasawa
 

Similar to 20161121日本医療情報学連合大会 チュートリアル 国立病院機構における電子カルテデータ標準化について (10)

富士市及び富士宮市共同電算化事業 ~ 自治体クラウドの導入 ~
富士市及び富士宮市共同電算化事業 ~ 自治体クラウドの導入 ~富士市及び富士宮市共同電算化事業 ~ 自治体クラウドの導入 ~
富士市及び富士宮市共同電算化事業 ~ 自治体クラウドの導入 ~
 
富士市役所のデスクトップ仮想化 2015年4月版 ~ゼロクライアントとICカード認証の導入~
富士市役所のデスクトップ仮想化 2015年4月版 ~ゼロクライアントとICカード認証の導入~富士市役所のデスクトップ仮想化 2015年4月版 ~ゼロクライアントとICカード認証の導入~
富士市役所のデスクトップ仮想化 2015年4月版 ~ゼロクライアントとICカード認証の導入~
 
富士市役所のクライアント仮想化への取り組み ~ノート型ゼロクライアントとICカードログオン~
富士市役所のクライアント仮想化への取り組み ~ノート型ゼロクライアントとICカードログオン~富士市役所のクライアント仮想化への取り組み ~ノート型ゼロクライアントとICカードログオン~
富士市役所のクライアント仮想化への取り組み ~ノート型ゼロクライアントとICカードログオン~
 
富士市役所におけるCitrix仮想化ソリューション導入成功のポイント ~ノート型ゼロクライアントとICカードログオンの採用~
富士市役所におけるCitrix仮想化ソリューション導入成功のポイント ~ノート型ゼロクライアントとICカードログオンの採用~富士市役所におけるCitrix仮想化ソリューション導入成功のポイント ~ノート型ゼロクライアントとICカードログオンの採用~
富士市役所におけるCitrix仮想化ソリューション導入成功のポイント ~ノート型ゼロクライアントとICカードログオンの採用~
 
介護施設向け管理システム
介護施設向け管理システム介護施設向け管理システム
介護施設向け管理システム
 
【ソフトバンク_II病理研究所】次世代病理システムマイパソ
【ソフトバンク_II病理研究所】次世代病理システムマイパソ【ソフトバンク_II病理研究所】次世代病理システムマイパソ
【ソフトバンク_II病理研究所】次世代病理システムマイパソ
 
Azure Office365 Live ID ALLDEAD
Azure Office365 Live ID ALLDEADAzure Office365 Live ID ALLDEAD
Azure Office365 Live ID ALLDEAD
 
自治体公衆無線LANの防災利用に関する考察
自治体公衆無線LANの防災利用に関する考察自治体公衆無線LANの防災利用に関する考察
自治体公衆無線LANの防災利用に関する考察
 
介護医療業界におけるマイクロソフトテクノロジー動向
介護医療業界におけるマイクロソフトテクノロジー動向介護医療業界におけるマイクロソフトテクノロジー動向
介護医療業界におけるマイクロソフトテクノロジー動向
 
アプリケーションの仮想化で実現した最適なシステム環境(2015/10)
アプリケーションの仮想化で実現した最適なシステム環境(2015/10)アプリケーションの仮想化で実現した最適なシステム環境(2015/10)
アプリケーションの仮想化で実現した最適なシステム環境(2015/10)
 

20161121日本医療情報学連合大会 チュートリアル 国立病院機構における電子カルテデータ標準化について