電子カルテ文書の秘密分散外部保存の検討

1-B-3-5 シンポジウム/1-B-3:S2
電子カルテ文書の秘密分散外部保存の検討
松村 泰志
大阪大学大学院医学系研究科医療情報学
Designing of External Medical Record Documents Reposition System
using Secret Share Scheme
Matsumura Yasushi
Medical Informatics, Osaka University Graduate School of Medicine
We implemented Document Archiving and Communication System in our hospital in which all the medical record
documents generated by the several systems were converted to PDF or DocuWorks formats and stored into a repository. The
system that stores the copies of the documents in an external repository can be a medical record backup. Although security is
quite significant for the external repository of medical record, the cost of it should be kept low. For solution of this problem,
we adopted secret share scheme. The outward deliverer selects the document that should be sent to the external repository
and sends the documents with their metadata written in XML. The external metadata repository parses the XML and makes
directories in the server where the file which records the path of the document in the secret shared server is saved. At the
same time, it sends the documents to secret shared server. In this system scheme, personal information is stored only in the
external metadata repository, whose data size is so small that the data can be stored in a compact server. The data size of
document bodies, on the other hand, is large but they are not any longer personal information, thus they can be stored in
servers in low costs.
Keywords: backup, business continuity plan, electronic health record, seacret share, document archiving
and communicatiion system
1. はじめに
震災やテロで病院の診療録が失われることになると、
一時的に病院が機能不全に陥るだけでなく、患者の
治療に大きな影響を及ぼすこととなる。紙で診療録が
管理されている場合、診療録管理庫を守るしか方法が
ないが、電子カルテで管理されている場合には、簡単
にコピーを作成することができ、コピーを遠隔に保存
することが技術的には可能となる。こうした対策がとれ
れば、電子カルテは紙カルテよりもはるかに頑健な記
録保存が可能となる。
電子カルテシステムは、通常の運用でもバックアップ
は取られており、ハードウェアが故障した場合には、
バックアップからデータを戻して復旧させている。この
バックアップデータを、サーバの近傍ではなく、遠隔に
置くことにより、災害等によるデータ消失を防ぐことが
できる。テロでサーバ室が爆破された場合などでは、
近傍の バック アップデー タは失わ れる結 果になるが、
遠隔に保存したバックアップデータを使って、元通りに
復旧 させ ること ができる。一 方、 病院 機能 自体 が 失 わ
れるほどの大災害に遭遇した場合、診療を行う場は、
もはや元の場所ではなく、サーバを元通りに再構築で
きたとしても、診療を継続できることにはならない。ま
た、システムの再構築に時間が必要となり、その間は、
過去の診療データが閲覧できない状態のまま、診療を
継続することになる。
この問題を解決するためには、サーバのバックアップ
を保存するのではなく、個々の診療録を別の形で保存
し、 病 院 外 か ら閲 覧可能とす るこ とで 解決 できる 。 こう
したシステムが構築できれば、大災害に遭遇した際
に、直ぐに診療を継続できるようになるだけでなく、平
時においても、複数施設が連携して行う連携医療にお
いて役に立てることができる。
110 第33回医療情報学連合大会 33rd JCMI(Nov.,2013)
大規模病院では、電子カルテシステムを構築する上
で、マルチベンダー構成は避けられない。現状では、
Web技術を駆使し、実態としてそれぞれのベンダーの
システムにデータを保存しておきながらも、電子カルテ
画面上から統合的に閲覧できることで、電子カルテシ
ステムを実現している場合が多い。この構成の場合、
同じ文書種でも、異なるシステムで記録された場合に
は、別のViewerから閲覧しなければならず、情報を見
落とす原因となる。また、提供ベンダーが将来変わる
場合、過去の記録が閲覧できなくなる。こうした問題を
解決するために、我々は、DACSと名付けた統合文書
管理の概念を打ち立て、大阪大学医学部附属病院に
おいて実現させた。DACSでは、全ての文書をPDFま
た は DocuWorks に 変 換 し 、 一 つ の サ ー バ で 保 存 す
る 。DACSの 仕 組 み が で き る と 、 文 書 の コ ピ ー を 保 存
する文書アーカイブサーバを病院外に置き、外部から
閲覧可能とすることができるはずである。
本研 究 で は 、 院内にDACSの 仕組み が あ る こ とを 前
提とし、診療文書のコピーを外部のサーバに保存し
て、外部から閲覧可能とするためのシステムについて
検討する。こうした外部保存を実施する場合、保存対
象が個人の機微な情報であり、セキュリティーの確保
が重要である。一方、災害時対策が目的の場合、シス
テムの維持に大きな費用をかけることができない。これ
らの問題を解決するために、秘密分散法の導入を検
討した。現在、この実証システムの構築過程にあるが、
文書保存時間に関する実現可能性試験を行ったので
その結果についても報告する。
2. 文書の外部向けの送信の仕組み
DACSでは、電子カルテシステムを含め各文書生成
システムから、診療記録文書を文書単位でPDFまたは
DocuWorksに 変 換 し 、XMLに 記 録 し た 文 書 メ タ 情 報
1-B-3-5 シンポジウム/1-B-3:S2
と と も に 、 FTP ま た は SOAP で Deliverer に 送 信 し 、
Delivererから文書アーカイブサーバに登録する仕組
みとなっている。文書を外部向けに送信する場合、
Delivererまたは、文書アーカイブサーバから文書のコ
ピーを取得し、外部サーバに向けて送信する(図1、
図2)。
こ の 際、 外 部 送信 用文 書の メタ 情 報は、 外 部用 のメ
タ情報に変換する必要がある。外部保存が単に当該
施設のバックアップの目的だけであれば、院内用の
コードをそのまま使っても問題はない。しかし、地域連
携でも利用し、複数施設が共同して一つのサーバに
記録を保存することを想定する場合には、統一コード
に変換する必要がある。メタ情報として必須である情
報は、文書生成した施設を表すコード、患者を特定す
るコード、文書種を表すコード、イベント日、文書を生
成した診療科を表すコードである。施設コードは固定
であり、イベント日は変換が不要であるが、患者を特定
するコードは、地域連携用に変換が必要である。もし、
マイナンバー等の番号が利用できるようになれば、こ
の番号が良いが、現状では、施設コード+施設内患
者IDで ユ ニ ー ク 性 を 保 証 し 、 可 能 な 場 合 に は 、 別 の
コードで同一者を表すコードを付けることとなる。文書
種コードについては現状では標準コードが定められて
いないが、標準的な文書分類体系を作成し、これに
従った標準文書種コードを定めるべきである。
災害対策を目的とした場合には、全ての文書を外部
に向けて保存するのが望ましいと思われるが、平時で
地域医療連携を目的とした場合には、患者から同意
が必要であり、患者、文書種、診療科などで外部保存
する文書を選択できる機能が必要となる。
外部送信用 サーバは、外部に送信する文書を取得
して、文書メタ情報を外部用に変換し、外部の文書管
理サーバに向けてSFTPで送信する。
3. 文書の外部管理サーバの機能
外部の文書管理サーバは、ゲートウェイ機能とディレ
クトリを管理する文書メタ情報管理サーバと、秘密分散
法 で 文 書 の 実 体 を 保 存 す る サ ー バ 群 ( SecretShare
サーバ)で構成される。
秘密分散法は、ファイル情報をビットレベルでN個に
分 割 し 、K個 を 取 得 す る こ と で 元 の 情 報 に 復 元 さ せ 、
K-1 で は 復 元 不 可 能 と す る 技 術 で あ る 。 分 割 さ れ た
個々のファイルは情報としての意味を持たないため、
個々のファイルを預かっている組織は、個人情報を預
かったことにはならない。
外部文書管理サーバのゲートウェイ機能は、受け
取った文書メタ情報XMLをパースし、患者ID、文書種
グループ、文書種の階層のディレクトリ構造を作成し、
文 書 メ タ 情 報XMLフ ァ イ ル と 、SecretShare内 の 格 納
先パス情報を記録したファイルを保存し、SecretShare
に向けて、文書ファイルを送信する。SecretShare格納
処理ステータス監視機能は、SecretShareへのファイル
転送におけるステータス(転送成功・失敗・実行中な
ど)に応じてリトライ処理や転送中止処理を行う。
外部文書管理サーバの文書情報参照機能は、他施
設 PC か ら の 文 書 参 照 要 求 を 受 け 付 け る と 、
SecretShareでの格納先パスを参照し、SecretShareが
保持する診療記録ファイルを取得してファイルに復元
して表示する。
本外部文書管理サーバは、文書管理ソフトウェア
DocuShare CPX6.6をベースとして開発した(図1、図
2)。
4. 保存時間に関する実現可能性試験の結果
DACSに保存されている診療記録文書のコピーを病
院の外部のサーバにも保存するためには、ある時点
で、それまで保存された文書を取り出して保存し、その
後は、日々追加される文書を逐次保存することが必要
となる。
現在、DACSに保存されている文書の2012年9月~
12月 分 の 登 録 状 況 を 調 査 し た と こ ろ 、 月 平 均32,142
人の患者分の文書が登録され、登録文書数は月平均
219,445、日平均7,197、ウィークデイ1日平均8,202で
あった。
文書外部送信用サーバで、4人の患者の文書ファイ
ルをDACSのアーカイブサーバから取り出し、文書メタ
情報管理サーバ用に移す実験を行った。文書外部送
信 用 サ ー バ が1患 者 平 均263.8の 文 書 をDACSか ら ダ
ウンロードして文書メタ情報管理サーバに文書メタ情
報を保存するまでの時間は平均266秒であった。これ
より、1文書を登録するのに要する時間は、1.01秒と計
算される。
図1 処理時間
1日 に 追 加 さ れ る 文 書 の コ ピ ー を 移 送 す る 方 法 に
は、文書が保存される度にコピーを作成し送信する方
法 、1日 の 夜 に バ ッ チ 的 に 送 信 す る 方 法 が 考 え ら れ
る。地域連携システムで利用する場合は、リアルタイム
性が要求され、前者の方式が必要となるが、バックアッ
プを目的とした場合は後者の方式でも可となる。日中
は、サーバは大量の文書の保存のためにコンピュータ
の資源を使っているので、後者の方式の方が安全で
あ る 。 ウ ィ ー ク デ イ に1日8,202件 の 文 書 が 発 生 す る と
仮定すると、1文書の保存に要した時間を単純に文書
数の比を掛けて算出すると、1日分の文書を作成する
のに2時間18分を要する計算となる。2010年以後の全
文書を移行させるためには、120万秒が必要と計算さ
れ、フルタイムで稼働させて約140日が必要となる。処
理の手順を工夫することにより、更に処理時間を短縮
することは可能である一方、処理する時間を夜間に限
定することなどを考慮する必要もある。これらのことを
含めても、実現可能な範囲と考えられる。
DACSでは全データが管理されているが、このうち管
理的な情報(例えば、入院診療計画書、栄養管理計
画書、同意書・説明書等)については、被災中には殆
ど意味は無い。実際の医療では、退院時サマリ、検査
レポート、経過記録などが診療をする上で重要であ
る。データ量が過重となる場合には、診療をする上で
必要とされる情報に限定して外部に保存すると、運用
は軽くなり、より運用しやすくなる。
バックアップデータを保存する場合、全データをまと
めて送付するため、かなりの帯域のネットワークの回線
が必要となる。しかし、本方式の場合は、小さなファイ
医療情報学 33(Suppl.),2013 111
1-B-3-5 シンポジウム/1-B-3:S2
ル単位で送信することになるので、それほど広い帯域
の確保は不要と推測している。
5. 考察
院内にDACSの仕組みが導入されている場合、診療
記録文書を院外で保存する仕組みを作ることは、比較
的容易である。ただし、複数施設の診療記録文書を統
合して保存し閲覧させる場合には、文書メタ情報の各
データを標準コードに変換する必要がある。
院内文書を外部に保存する場合、セキュリティーの
確保が重要となる。外部からアクセス可能としながら情
報漏洩リスクを限りなくゼロに近づけるためには、かな
りしっかりしたデータセンターに預けることが前提とな
る。こうしたデータセンターでデータを預けるために
は、データボリュームに応じて費用が高くなるのが通
常である。通常の方式であれば、病院内で発生する診
療記録文書の全てを預けることになると、かなり大きな
保存スペースが必要となり、相応の費用がかかることと
なる。一方、現在は、クラウドビジネスが広まり、低価格
の保存スペースが供給されるようになっている。これら
の保存スペースでも、ある程度のセキュリティーは確保
されているが、個人情報を預けるレベルにはないのが
一般的である。本方式では、文書メタ情報管理サーバ
は、セキュアなデータセンターに預ける必要があるもの
の、そのボリュームは大きくはない。一方、文書本体を
保存するスペースは、秘密分散法で分割されたファイ
ルを預けるので、一般の保存スペースに預けても問題
とならない。もし、一つのサーバが障害で消失した場
合でも、他のデータで復元可能となるので頑健性も確
保される。
本実証システムでは、文書メタ情報は、病院のDMZ
セグメント内の外部参照サーバ用のセグメントに配置
した。このサーバが、患者個人情報を管理していると
見なすことができるため、これを外部保存するために
は、諸手続きが必要であり、今回の実証実験ではそこ
までは実施しなかった。本来のBCP対応のためには、
112 第33回医療情報学連合大会 33rd JCMI(Nov.,2013)
このサーバのリプリケーションを外部のセキュアな場所
に保存する等の対応が必要である。
本方式では、復元にどの程度の時間を要するかが鍵
となる。もし、使用に耐えないほどの時間がかかる場合
には、プリフェッチの考え方を導入し、事前に閲覧する
患者を指定することで、秘密分散サーバから当該患者
のファイルを全て取り出し、キャッシュ上に復元ファイ
ルを保存しておくことで対応できるはずである。
本実 証 シ ステ ム では、各 ユ ーザ に対し て、 ど の患者
の診療記録の閲覧を許可するかを指定する機能まで
は開発できていない。院内では、アクセスログは記録
してはいるが、医師であれば、院内の全ての患者の診
療記録が閲覧可能となっている。しかし、複数施設の
患者の診療記録を集約させる場合には、何らかの現
実的な制限をかけるべきであり、更なる検討が必要で
ある。
今回は、テキストデータを中心とする診療記録の外
部保存を対象としたが、医用画像については、保存ス
ペースとそのコストの問題については、より切実な課題
で あ る 。 画 像に つ いて も 、 秘 密分散 法 を 利 用し て、 画
像実体情報をクラウド上の一般の保存スペースに分散
して保管できれば、画像保存のコストをかなり逓減でき
ると期待できる。
参考文献
[1] 黒田 知宏, 木村 映善, 松村 泰志, 山下 芳範, 平松 治彦, 粂
直人. 秘密分散技術を用いたHISバックアップクラウド環境の
検討. 医療情報学32(Suppl). 2012:474-7.
[2] Tomohiro Kuroda, Eizen Kimura, Yasushi Matsumura,
Yoshinori Yamashita, Haruhiko Hiramatsu, Naoto Kume.
Simulating Cloud Environment for HIS backup using Secret
Sharing. Medinfo 2013, 171-174.
[3] Tomohiro Kuroda, Eizen Kimura, Yasushi Matsumura,
Yoshinori Yamashita, Haruhiko Hiramatsu, Naoto Kume,
Atsushi Sato. Applying Secret Sharing for HIS Backup
Exchange. IEEE EMBC 2013.
1-B-3-5 シンポジウム/1-B-3:S2
図1 システム構成とドキュメントのフローの概要
図2 プログラム構成の概要
医療情報学 33(Suppl.),2013 113