期にわたる診療データ活 時の課題 期にわたる診療デ タ

⻑期にわたる診療デ タ活⽤時の課題
⻑期にわたる診療データ活⽤時の課題
国⽴成育医療研究センター 情報管理部 情報解析室⻑
⼭野辺裕⼆
本⽇の内容
 電⼦カルテの３原則からe⽂書法の４要件へ
 電⼦保存の４要件には優先順位がある
 病院情報システムの構成の変遷
 電⼦化された医療情報の諸問題
 蓄積データ後利⽤時の課題
蓄積デ タ後利⽤時の課題
⽋損値への対応
時間的変遷への対応
構造化の是⾮
1
電⼦保存の４要件
優先順位がある。分けて考える。
医療情報の電⼦保存を巡る
医療情報の電⼦保存を
巡る原則
原則
 電⼦カルテの３原則（1999）
保存性、真正性、⾒読性
 情報セキュリティの３要素
機密性、完全性、可⽤性
Confidentiality,Integrity,Availabilityで
CIAとも⾔う
 e-⽂書法では、
機密性、完全性、⾒読性、検索性の４つ
Visibility,Availability
2
保存性 真正性 完全性 機密性 見読性 可用性 検索性
電子カルテの
３原則
情報セキュリティの
３要素
ｅ‐文書法の
文書法の
４要件
□ □
○
□ ◇
○
□ ◇ ○
○
e-⽂書法の「⽂書の電磁的保存に関する4
⽂書法の「⽂書の電磁的保存に関する4要件」
 ⾒読性（Visibility）
 完全性（Integrity）
g y
 機密性（Confidentiality）
 検索性（Availability）
これからは電⼦カルテの４原則と呼ぶべきでは
４要件のうち、医療現場で
最も重要なのは？
 ⾒読性（Visibility）
 完全性（Integrity）
 機密性（Confidentiality）
 検索性（Availability）
3
Google Person Finder
 誰かが避難所から携帯電話で
「避難者名簿の写真」をGoogleに送る。
 ボランティアがその写真から
名前やその他の情報を⼊⼒する。
→ ⽣存者と避難所のデータベースができた
⽣存者と避難所のデ タベ スができた
４要件のうち、医療現場で
最も重要なのは？
１.⾒読性（Visibility）
３.完全性（Integrity）
４ 機密性（Confidentiality）
４.機密性（Confidentiality）
２.検索性（Availability）
4
⻘空⽂庫
 ボランティアが古典⽂学の書籍を
デジタル化する。
→ ⼩説中に「国際」が何度出現する
かなど、新たな分析が簡単 。
かなど、新たな分析が簡単に。
⻘空⽂庫（検索性の後付け）
 ボランティアが古典⽂学の書籍を
デジタル化する。
→ ⼩説中に「国際」が何度出現する
かなど 新たな分析が簡単に
かなど、新たな分析が簡単に。
5
医療情報保存の
４要件で最も重要なのは？
最も重要なのは「⾒読性」である
「完全性」はあった⽅が良い＊
「検索性」は後から付加できる
「機密性」はしばしば邪魔になる
＊医療記録の悪⽤は考えないという前提
電⼦化に伴う完全性や機密性の低下
を補う⼿段として、
電⼦署名やタイムスタンプや暗号化
がある。
しかし、
果たしてこれは必須なのか？
ここまでしなくても完全性を
保てる⼿段があるのでは？
6
不充分な完全性でも‥‥
不充分な完全性でも
‥‥
地検特捜部の検事がフロッピー
ディスクの⽇付を改ざんした際、
ディスクの⽇付を改ざんした際
犯罪⽴証の決め⼿となったのは、
改ざん前に印刷された紙だった。
電⼦署名がなく改ざん可能な
データも、複製したり印刷した
りすると完全性が向上すること
がわかった。
前半の結論
 医療情報の電⼦保存４原則の中で、
⽇常的に最重要なのは⾒読性である。
 他の３つ（完全性、機密性、検索性）
の重要性は再考の余地がある。
 検索性は後から追加できる。
7
 検索性と⾒読性の確保を同時に考えると、
データベースフィールドを紙の外⾒に
デ
タベ スフィ ルドを紙の外⾒に
マップしがち
 まずは⾒読性だけを確保しておいて、
検索性を後付けする⼿法もあるのでは？
PDFやOOXML埋め込み、M2Mクラウドでindexing
病院情報システムの構成の変遷
8
2002年の成育医療センター
2002
年の成育医療センターHIS
HIS（基幹集中型）
（基幹集中型）
部門システム
基幹電子カルテ
後利用
データベース
すべての情報は基幹電⼦
カルテに集約されていた。
施設・設備システム（照明・空調・電源・施錠）
9
施設・設備システム（照明・空調・電源・施錠）
クラウド
コンピュー
ティングで
グ
境界不明
病院情報システムの構成の変化
1. ⽇々の業務を⾏なうシステム
（部⾨システム、病院情報システム）
2. 将来へデータを残すシステム
（画像保管、⽂書保管、検索データ保管）
後世の⼈にとっては2.だけがあればよいので、
⽇々の電⼦カルテにこだわる必要はない。
10
電⼦化された医療情報の諸問題
信じ難い現実
カルテのどこにも患者の名前が書いていない
コンピュータで出せない字を持つ患者
× ⼭野辺
× ⼭野邉
× ⼭野邊
医事課では「ヤマノベ」で登録
 カルテのどこにも患者の正規の名前が
書いていない !
 ⼿書き時代にはあり得なかったこと
（書類のスキャン画像で確認する始末）
11
いつ姓が変わったのかわからない
 初診時の紹介状は旧姓で記載
 現在では結婚後の姓になっている
いつ改姓したのか？
いつまた元の姓に戻ったのか？
 履歴ログ無し
グ
 スキャン書類の表記で判断
（オーダの冗⻑な属性情報に残存）
2008〜
2008
〜 正式名欄と改姓履歴を追加
枠は作っても使ってもらえるかという問題も
12
診療科名の変更で完全
診療科名の変更で
完全性の危機
性の危機
2009年、院内の場所や組織の名称変更
デイケア室 → 外来中央処置室
⾎液科
→ ⾎液腫瘍科
⼩児腫瘍科 → 固形腫瘍科
2010年、⾎液内科が新設
単なる名称変更では、過去記載の科名も
更新されてしまう。新規に別の科を作ると
科の継続性が失われる。予算はない。
ジレンマの結末、単なる名称変更
ジレンマの
結末、単なる名称変更
2004年には存在しなかった「⾎液腫瘍科」
の記載。2008年以前は「⾎液科」と読み
替える決まりを作って運⽤するしかない。
13
蓄積データ後利⽤時の諸問題
未だ⼿探り
後年データを分析する時の対応
2008
2009
血液科
2010
血液腫瘍科
血液内科
診療科や伝票名の変遷を記録しておく必要。
年代によ て検索対象とすべき診療科が変化
年代によって検索対象とすべき診療科が変化。
2008年までは⾎液科
2009年は⾎液腫瘍科
2010年以降は⾎液腫瘍科と⾎液内科
14
教訓
1. 改姓履歴が残っておらず、冗⻑な属性
情報で当時の姓が確認できた。
2. 同じコードで診療科名を変更してしまい、
完全性が失われた。
↓
過度なコード化や正規化は良いことばか
過度なコ
ド化や正規化は良いことばか
りではない。テキスト保持、冗⻑化も考慮
する必要。
⽉間の⼿術件数
紙カルテ時代の「⼿術台帳」が無くなった
医事システム
電⼦カルテ後利⽤システム
看護管理⽇誌
‥‥
→ これらの集計値が⾷い違う
15
⽉間の⼿術件数
どこを持って「⼿術の実施」とするのか
⼿術にまつわる⽇時の例
予定⽇
11/30（基幹オーダリングシステム）
（基幹オ ダリ グシ
ム）
受付時刻
23:25（⼿術部⾨システム）
⼊室時刻
23:30（⼿術部⾨システム）
⿇酔開始時刻 23:40（⿇酔記録システム）
11⽉30⽇
執⼑時刻
0:05（⿇酔記録システム）
12⽉1⽇
終⼑時刻
0:55（⿇酔記録システム）
⿇酔終了時刻 1:15（⿇酔記録システム）
退室時刻
1:25（⼿術部⾨システム）
帰棟時刻
2:00（看護⽀援システム）
集計時に決める必要
妊娠中のHbA1c
妊娠中の
HbA1cを
を分析
分析したい
したい
 どうやって妊娠中と判定するのか？
→ 出⽣（死産）証明書が確実
開始の判定は難しい
周産期部⾨システムのレポート等
 妊娠フラグは消し忘れも
 分娩が他医になった場合は？
16
“電⼦カルテはブラックホールのようだ
電⼦カルテはブラックホールのようだ””
 患者プロファイルや⼊⼒テンプレートで、
構造化データを細かく整備しよう。
（最初から検索性もカバー）
 せっかく打ってもあとから取り出せない。
検索できない。
 ⾃由⽂⼊⼒ではゴミの⼭になるだけ。
ゴミの⼭（都市鉱⼭）から
ゴミの
⼭（都市鉱⼭）から少しずつ宝を発掘
少しずつ宝を発掘
 患者プロファイルや⼊⼒テンプレートで、
構造化データを細かく整備しよう。
→器はあってもデータを⼊れてくれない
⾃由⽂記載の中に書かれている。
 せっかく打ってもあとから取り出せない。
検索できない。
→後利⽤システムで全⽂検索可能に
 ⾃由⽂⼊⼒ではゴミの⼭になるだけ。
→⾃由⽂記載からもデータを抽出可能
17
実例
 全患者から、⼩児がんの既往のある妊婦が
いるかどうかを探索
病名オーダ、既往歴⼊⼒欄だけでなく、
カルテ⾃由記載の全⽂検索で200例を発⾒、
⽬視で 「兄が⽩⾎病」などを除外。
 「体重」の記録場所は多岐にわたる
部⾨システム経由のテキストやhtmlから
も体重を抽出
体重:23.4kg MID(体重:の次,kgの前）
使っているツール
 基幹システム（富⼠通 EGMAIN-GX）
 付属後利⽤システム（富⼠通 DWH-Plus）
DWH Plus）
 EDR(ネットマークス CDR)
 ログ解析システム（Intec LogRevi）
 ポータル、⽂書管理（Microsoft SharePoint ）
 FileMaker & Server
 Microsoft Office & SQL
18
DWH--Plus
DWH
 オーダリングシステムからの定型検索
 電⼦カルテ⽂書の⽣データの属性情報や
レポートhtmlからの⽂字列抽出（裏技）
△基幹システムデータ構造に習熟する必要
△基幹システムデ
タ構造に習熟する必要
△⼤量データでタイムアウト
△⼤量時系列データに弱点
CDR
 全⽂検索に強み
 複雑な条件、⾮定型複合検索や探索
 データ構造が決めてあれば⼼配が少ない
△応答性能に波がある
△⼤量時系列データに弱点
デ
19
快速サーチャーLogRevi
LogRevi
 ⼤量時系列データの分析
 複数データソースの統合的可視化
△静的DBのため、都度データ読み込みや
再構築が必要
△デ タの前処理が必要
△データの前処理が必要
20
SharePoint Server
⼀般利⽤者が活⽤できるグループウェア
（SQLサーバのWebフロントエンド）
（ECM、⽂書管理、全⽂検索）
部⾨・基幹システムの代替も可能？
△医療分野での応⽤経験が少ない
これから
21
どうせ電⼦化するなら、
データの仮想化も
Virtualとは「実質○○とみなせる」という意味。
「紙切れである紙幣を⾦塊とみなす」
データの仮想化
• ⾒せ⽅によっては⽂書ファイルであり、
他⽅ではデータベースのレコードである
• ⼈が読むと紹介状、機械が読むと検査歴データ
• 1枚何役にも。
PHR（Personal Health Record）
PHR（
Record）
がクラウド上に欲しい
 施設をまたがったデータの⾒読性を
施設を たが たデ タ ⾒読性を
連続的に確保
 患者主体のアクセス権管理
 各施設のデータバックアップとして
 M2Mクラウドで検索性の向上
 パブリッククラウドの活⽤
22
まとめ
 電⼦カルテの３原則からe⽂書法の４要件へ
電⼦保存の４要件には優先順位がある
４要件を分けて考えることもヒントに
 病院情報システムの構成も後利⽤重視へ
 電⼦化された医療情報の諸問題
 蓄積データ後利⽤時の課題
経験を積む必要
構造がシンプルな⽅が良いのでは
23