情報管理
Online ISSN : 1347-1597
Print ISSN : 0021-7298
記事
千年カルテプロジェクト:本格的日本版EHRと医療データの2次利用に向けて
吉原 博幸
著者情報
ジャーナル フリー HTML

60 巻 (2017) 11 号 p. 767-778

詳細
PDFをダウンロード (3178K) 発行機関連絡先
著者抄録

EHR(Electronic Health Record)の始まりは1995年の医療情報共通規格(MML: Medical Markup Language)の検討開始にさかのぼることができる。2001年に,MMLをデータベース構造としたEHRが開発され,熊本,宮崎,東京,京都へ拡大していった(Dolphin Project)。その後,国家レベルでの医療情報管理の必要性が認識され,医療情報の2次利用のニーズとも相まって,2015年にDolphin Projectの国レベル版である「千年カルテプロジェクト」が始まった。2018年度までの4年間で接続病院を十分に増やし,2019年度から始まる医療情報の2次利用に備える。2次利用の収益による補助金に依存しないEHR部門も含めた独立採算を目指している。

1. はじめに

2014年3月に次世代医療ICTタスクフォース(内閣官房)注1)が設置され,主として医療情報の2次利用に関する検討が開始された。2015年4月2日に第1回の次世代医療ICT基盤協議会注2)(以下,協議会)が開催された。これは,内閣総理大臣を本部長とする「健康・医療戦略推進本部」の下部組織の一つである。協議会のプロジェクトの一つとして「千年カルテプロジェクト」が立ち上がり「大規模健康・診療データの収集・利活用」注3)をテーマとした。

2015年9月,日本医療研究開発機構(AMED: Japan Agency for Medical Research and Development)研究公募事業に正式採択決定(研究題目:全国共同利用型国際標準化健康・医療情報の収集および利活用に関する研究)。本研究は,2019年度からの事業化を目指し,すでに2002年以来,別々に稼働していた九州,東京,京都等のEHR(Electronic Health Record)注4)サイト(Dolphin Project)を,新しく開発・設置する共同利用型EHRセンターに集約し,その他の地域からも多数の医療機関等の参加を得てこのデータセンターを共同利用することで,データの安全性と運営費の低減を目指す。医療機関から出力されるデータ規格はさまざまであるが,最終的にはデータセンターでISO13606注5)に集約している。また,これらのデータを法律にのっとって公正・安全に2次利用し,その収益でEHRを運営し,事業の継続性を担保する(脱補助金,脱研究費)(1)。

2018年度に施行される予定の「次世代医療基盤法」(医療分野の研究開発に資するための匿名加工医療情報に関する法律)に沿って2つの事業体(一次利用EHR運営機関,認定匿名加工医療情報作成事業者)が新設・運営される予定である。本プロジェクトで1990年代からの懸案だった診療データベースの本格的運用とデータの2次利用により,連携医療,臨床研究,創薬,公衆衛生,行政等への活用が期待される。本稿では,千年カルテプロジェクトのシステムから法的問題を含めた今後の課題を概観する。

図1 千年カルテの概念

2. 日本におけるEHRの歴史

2.1 Dolphin Project

1993年にインターネットの民間利用が可能となった。当時,医療情報の若手研究者,企業人が集まり,将来電子カルテはどのような機能をもつべきかの検討が始まった。1995年に,宮崎で最初の集まりが開かれ,開催場所にちなんで「Seagaia Meeting」と命名され,現在まで毎年開催されている注6)

電子カルテのあるべき姿は「つながる」ことだ。患者が新規の病院を受診した場合でも,過去の病歴すべてが電子カルテに表示されることが望まれる。異なるベンダーの電子カルテの混在環境で,それを実現するための課題は3つ。「データの所在」「データの互換性」「アクセス制御」である(2)。

以上の課題を1990年代に解決し,2001年に経済産業省の研究補助金を得て,MML(Medical Markup Language)注7)1)をデータベース構造としたEHR(ここでは医療情報連携基盤)を開発し運用を開始した(Dolphin Project)2),3),4)。Dolphin Projectは,地域ごとに患者の診療データを管理する地域医療情報データセンター(以下,データセンター)を設置し,これをハブとして,連携医療や電子的カルテ開示を行う仕組みである(3)。

Dolphin Projectの目的は,「地域の異なる病院情報システムを効率的に相互接続することのできる基盤を提供すること」である。センターサーバーに蓄積された診療データを一定のセキュリティーの下に統合保管し,医療従事者は,診療契約関係にある患者の診療データを一元的に閲覧することが可能となり,これにより「連携医療」が可能となる他,患者は,自身の診療データを閲覧し(「電子的カルテ開示」),症状などを自分のカルテに記録することも可能になる。

これを実現するために,データセンターを設置し,これにクリニック,病院,検査センター,薬局,訪問看護ステーションなどを接続する。経過記録,検査結果,紹介状,退院時サマリーなどを送り,患者ごとに統合的に蓄積する。この情報は,地域での診療データ共有に利用する他,各医療機関のカルテデータのバックアップとしても使われる。

図2 EHR運用に必要な技術要素
図3 Dolphin Projectの基本概念

2.2 データセンターと電子カルテを結ぶ仕組み

データセンターは,データを受け取るインターフェースをもち,MMLやHL7(Health Level 7)などの形式で記述された診療データを受け取ることができる。各医療機関の電子カルテは,診療データをMMLなどに変換してデータセンターに送信し,データセンターは,これを受け取りデータベースに格納する。医療機関,患者などは,これを参照できる。

地域ごとにデータセンターを設置し,順次運営を開始した。2001年に熊本(ひご・メド),2002年に宮崎(はにわネット),2003年に東京(HOT Project),2006年に京都(まいこネット)が稼働し,2017年現在,宮崎と京都が運用を継続している。

2.3 データセンター統合の機運

地域データセンター運営は地域プロジェクトにより異なるが,大学病院などでの設置,大手データセンターへのポスティングなど,サーバーの購入,管理,5~6年ごとの機器更新など,人的にも,財務的にも大変大きな負担を強いられる。そこで,国内に大規模データセンターを造り,EHRサービスをSaaS(Software as a Service)注8)化して地域のサーバーを収容し,コストダウンを図るだけでなく,運用負担を軽減するというアイデアが生まれた。これが2014年頃から始まる,政府の次世代医療ICT基盤整備計画の下で,国レベルのEHR基盤構築につながっていくことになる。

3. 千年カルテプロジェクト

前章で述べたように,Dolphin Projectが抱えていた,地域ごとのデータセンター運営の重い負担を軽減するため,千年カルテプロジェクトでは,データセンターをEHRセンター1か所に集中させ,各地域でネット越しに機能を分割利用できるように設計した(1)。

初年度(2015年度)は,EHRセンター(データベース等)の基盤構築。同時に,すでに京都,宮崎で旧EHRに接続されている病院(11施設)をEHRセンターに接続した。

2016年度は,接続病院を増やし23病院が接続され,2017年度は40以上の病院が新たに接続される予定で,調整が続けられている。AMED研究期間の最終年度となる2018年度も40施設以上の病院,薬局等の接続を予定している。最終目標は基幹病院クラスで150ほどの予定である(4)。

5に示したように,千年カルテプロジェクトでは,図中央のEHRシステムをまず構築し(~2018年度),EHRサービスの実施を先行する。2018年の次世代医療基盤法の施行を受けて,新しく認定匿名加工医療情報作成事業者が運営される予定である。一次利用EHR運営機関は,現存のNPO日本医療ネットワーク協会が引き続きこれを担当する。

図4 千年カルテの展開計画
図5 千年カルテプロジェクトの概要

3.1 データベース

3.1.1 データベース(エンジン)

千年カルテのデータベースエンジンには,オープンソースの大規模分散ファイルシステムであるHadoopエコシステムをベースとして採用している。以下にHadoopエコシステムを構成する技術要素のうち,今回採用している主な技術要素(6)について述べる。

図6 千年カルテのデータフローと各技術要素の関係

(1) Hadoop

千年カルテには,参画している全国の医療機関から電子カルテデータが送信されてくる。格納すべきデータは参画数に応じて増加するため,データの処理能力および格納容量について柔軟な対応が求められる。一般的にデータの処理能力・格納容量の増強には「スケールアップ」と「スケールアウト」注9)という2種類のアプローチが存在する。Apache Hadoopはスケールアウトによる拡張を可能としており,かつ,サービスを継続したままの増強が可能となっている。また,複数サーバーでデータをレプリケーション注10)して保持することにより,高い耐障害性を実現している。

(2) Hive

各医療機関から送信されてくるカルテデータはMedXMLコンソーシアムが策定したMML形式で送信され,千年カルテ内部でJSONと呼ばれる形式に変換した後,格納される。データは各医療機関から随時送信されてくるため,膨大なデータ件数を処理する仕組みが必要となる。

Apache HiveはRDB(Relational Data Base)では取り扱いの難しい大規模データに対応したDWH(データウェアハウス)プロダクトであり,Hiveを通して実行した処理はYARNと呼ばれる分散処理フレームワークに沿って処理が変換され,分散実行される。

(3) HBase

千年カルテの内部では上記のMML形式以外にもISO13606形式でデータを格納している。ISO13606は,アーキタイプによる柔軟なデータモデル構造が特徴であり,同特徴と親和性の高い格納方式が必要となる。HBaseはオープンソースの大規模分散ストレージシステムであり,データ構造としてKVS(Key-Value-Store)方式を採用している。一般的なRDBはデータ構造に関する細かい定義(スキーマ)が必要であるが,HBaseではスキーマが不要(スキーマレス)となっており,柔軟なデータ運用が可能となっている。

(4) Impala

通常のEHRは自医療機関のみ,地域EHRも特定エリアの医療機関のみを対象としているが,千年カルテは全国の医療機関のデータを対象としており,そのデータ量は膨大である。千年カルテでは,Web画面を通して患者・医療スタッフがカルテデータを閲覧できるようになっており,オンラインでの検索パフォーマンスについて特別な考慮が必要となってくる。

Impalaはオープンソースの分散SQLクエリエンジンであり,HDFS上に格納されたデータを高速に検索することが可能となっている。また,前述のHiveとデータの共有が可能なため,千年カルテではバッチ処理はHive,オンライン処理はImpalaといった形で各技術特性を生かす形で適用している。

3.1.2 データベース(論理構造)

上記のような経緯により,千年カルテプロジェクトのデータソースは旧EHRへ出力されていたMML Version 2および3によるデータをまず対象とした。さらに接続病院数を増やし,対象とするデータ種別を増やすためには,MMLだけではなくHL7あるいは病院やベンダー独自の形式にも対応する必要があったため,データベース内部の論理構造を柔軟で検索性に優れたISO13606, openEHR注11)によるアーキタイプモデルを採用した。アーキタイプモデルを利用することで,複数のデータソースを柔軟に取り込みつつも,横断的にデータ検索を行うことを可能とした。

さらに,既存のMMLとの後方互換性を維持しつつ開発上の利便性を高め,バイタルサイン,体温表,内服処方箋,注射実施記録の各モジュールを追加してMML Version 4としてリリースし,本プロジェクトでのインターフェースの一つとし,対応する論理モデルを設計し,マッピングテーブルを整備した5)

健診では日本HL7協会が定義したHL7 CDA Rel2準拠のデータ形式6)が広く普及しているため,そのスキーマを基に,同様にアーキタイプを利用して論理モデルを設計し,健診施設からもデータを取り込むことができるようにした。

HL7やMMLの開発に慣れていないベンダーのために,MMLを簡略化したJSONや独自フォーマットに対応したアップローダーも用意した。これらのデータも対応する論理モデルにデータが取り込まれることとしている。

3.2 アクセス制御

従来,どの患者のデータを誰に見せるかという厳格な1対1のアクセス制御が設計されてきたが,運用上病院の負荷が大きく実際にはほとんど利用されてこなかった。本プロジェクトでは,自施設,連携病院,患者の3者をステークホルダーとして定義する。

(1) 医療機関による開示ポリシーの設定

医療機関が診療情報の共有範囲,アクセス権を設定する。

一般に,アクセス制御対象とする診療情報は,診療科単位,医師単位,文書種別単位,項目単位で分類される。本プロジェクトでは,個別の医師の制御,項目ごとの制御は行わず,文書種別単位,診療科単位でのアクセス権設定を前提とする。MML標準規約で定義された18文書を単位としてそれぞれ患者,連携施設へのアクセスを許すかどうかを設定できる(7)。

図7 医療機関ごとに設定する,医療文書,診療科ごとのアクセス制御

(2) 患者によるオプトアウト

患者が医療機関受診歴の中から,診療情報を共有したくない医療機関を選択する。

患者が共有を拒否した医療機関の情報は,たとえ当該医療機関が連携病院への共有を許可していたとしても患者の意志が優先され共有されない。

(3) 共同診療のルール

診療情報を生成した医療機関,当該医療機関を受診した患者の双方が許可した診療情報のみが,患者の受診歴のある連携病院に対してのみ共有される。たとえ本プロジェクトに参加している病院であっても,当該患者の受診がない病院に対して情報は共有されない。

3.3 サービス機能

千年カルテプロジェクトでは,医療機関,患者等へのサービスを「ゼロ次利用(診療結果データの遠隔バックアップ)」「1次利用(共同診療のための情報共有,患者への開示)」「1.5次利用(EHRにおいて診療リスクなどを自動的に発見する」「2次利用(匿名,顕名での医療情報の研究利用)」に分類している。

3.3.1 データのゼロ次利用

医療機関の災害対策は先の震災を期に対策が進んでいる。本プロジェクトの理念は個人の生涯医療記録を永久に保存し人類の資産とすることだが,医療機関が常に最新の診療情報を保持し続ける仕組みであるともいえる。EHRは,電子カルテが災害から復旧するまでの間,最新の患者情報を提供する。

電子カルテのバックアップ(診療結果データの他,オーダー,医事データなどの業務データを含むすべてのデータ)からのデータの復旧には電源,通信,現地ハードウェア,運用再立ち上げのため,障害発生直後にリカバリーを実施することは困難である。一方,EHRセンターでは電源,通信さえ確立すれば診療情報の提供が即刻可能で,災害直後に最も必要とされる直近の検査結果,処方などの情報を迅速に提供できる。また,EHRを通じて患者に情報を提供しておくことで,災害時に患者個人が持ち出したスマートフォンの情報を参照して診療を継続することも可能である。

3.3.2 データの1次利用

EHRに集積された情報の1次利用として,データ閲覧,Electronic Data Capture(EDC:電子的データ収集),アラートシステム,経営指標分析の4つが挙げられる。

(1) データ閲覧:患者,医療スタッフ向けビューアー

利用者向けビューアーは,PC用(Webブラウザ),スマートフォンアプリケーション(iOS,Android)が用意されている。8は,PC用アプリケーション画面を示す。ID,パスワードでログインの後,左側ウィンドウ(8)に検査,処方,報告書等の医療記録項目が時系列でリストされる(一番上が最新)。クリックすると右側に内容が表示され,検査結果などでは,項目を複数クリックすると折れ線グラフが描画される。詳しくはYoutubeを参照のこと注12)

9は,スマートフォン用のアプリケーションを示す。医師用はなく,患者用のみ。iOS用,Android用がそれぞれ用意されており,Apple Storeなどから無料でダウンロードできる。

ID,passwordでログインすると,最初は患者の全病歴がダウンロードされる。病歴数にもよるが,4,000件を25分ほどでダウンロードできる。PCの場合は,閲覧を終了するとデータは消えるが,スマートフォンの場合は,データはそのまま記録される。次回のアクセスで新しいデータのみダウンロードしてくる。つまり,すべての病歴がスマートフォンに残っている。大災害の際,停電,ネットの停止はつきものであるが,スマートフォンを持っていれば,最新処方,検査などを参照可能である。

図8 千年カルテのWebインターフェース
図9 スマートフォン用のアプリケーション「千年カルテ」(向かって左2つがiOS,右がAndroid)。

(2) Electronic Data Capture(EDC)

EDCでの利用に関しては,一部電子カルテのテンプレート入力に合わせてデータをEHRセンターに送出する仕組みを有している。

特定のプロジェクトで電子カルテ記載よりも詳細なデータ項目を記録する場合に,わざわざゼロからEDCシステムを導入することなく,簡便にデータの収集を可能とすることを目的としている。EHRセンターと医療機関間の専用線と同様の経路を利用して医療機関相互のデータ連携を行うため,プロジェクトごとに安全な経路を確保する必要もなくなる。

(3) アラートシステム,経営指標分析

1.5次利用(後述)のデータ分析の結果を診療情報提示画面に統合し,特定の患者の特異な検査値の推移などを検知しアラートを表示する機能の実装を予定している。特に慢性疾患で継続的に検査受診する患者や,突発的な異常値の変化をあらかじめ分析し,医師にフィードバックすることで臨床の安全性を格段に高める。従来,これらのアラートシステムは院内電子カルテに実装されている例もあるが,電子カルテベンダーや病院の運用部門の負荷が大きかった。本プロジェクトでは,これらのデータ分析とアラート作成をEHRセンター側で一元的に実施することで,医療機関に個別の負荷をかけることもなく医療圏全体でのコスト削減ができる。

さらに,医事データ提供医療機関に対しては経営陣向けのポートフォリオ,ベンチマークといった情報も還元していく予定である。

3.3.3 データの1.5次利用

EHRの構築目的の一つとして,集められたデータを基に診療支援を行うことがある注13)。本プロジェクトでは医療機関および患者に提供するデータ利用を1次利用と位置づけ,データを利用して診療支援を行うことを1.5次利用として位置づけている。

すでに,EHRデータにAIを応用して急性腎障害を早期に検出することで,予後を改善したという報告がある7)。本プロジェクトにおいても実施が可能であるか調査検討を行っている。

スウェーデンでは本プロジェクトと同様にアーキタイプを内部論理モデルとして採用したEHRのデータから,心房細動患者にガイドラインに準拠した抗凝固療法を医師に促したところ,コンプライアンスの改善が見られたという報告がある8)。この論文で紹介されたEHRからさらに診療支援に役立てていく機構は,オープンソースソフトウェアとして公開されており本プロジェクトでも活用していく方針である。

3.3.4 データの2次利用

従来困難であったデータの2次利用が,次世代医療基盤法の施行により可能となった。この法律の下に,認定匿名加工医療情報作成事業者の国家認定を行う。この機関は,EHR機関,病院等から実名データを受け取ることができる。基本的に患者の個別同意なしに名寄せを行い,匿名加工を行う(Opt-Out)。これらのデータを医学研究目的で研究者に提供できる(有償)。実名で名寄せを行ったうえで匿名化するので,匿名IDでの個人のトレースが可能となった。臨床研究,市販後調査などへの活発な利用が期待される。

4. 解決すべき課題

4.1 データの共通化・標準化

異なるベンダーのデータを単一データベースに収容する場合,データの共通化が必須条件となる。1990年代以降,世界各国・地域で医療情報の共通規格が開発され,米国(HL7: Health Level Seven International注14)),欧州(openEHR, openEHR foundation),日本(MML: MedXML コンソーシアム注15))など,それぞれの国に対応した規格が使われている。実際は,日本国内でも海外でもさまざまな規格が乱立しており,これらを変換(mapping)して,一つのデータベースに収容する方法がとられている。mapper専門の企業(オリオンヘルス社:https://orionhealth.com/など)が世界を席巻している現状からも「唯一の規格」が現実的ではないことがわかる。

2010年代に入り,ヨーロッパのopenEHRの流れを組む規格がISO13606として認定された。既存のHL7,MMLとの関係を調査したところ,ISO13606に対してmappingが可能であることが確認されたので,千年カルテプロジェクトでは,病院,薬局,健診センター,検体検査会社等から出されるさまざまな規格(MML,HL7,業界標準独自規格……)をISO13606にmappingして収容している。

4.2 電子カルテデータの構造化が不十分

電子カルテから出されるデータは,HL7,MML,業界独自規格CSVなどさまざまであるが,これはmappingを用いれば統合が可能である。ところが,データがサブシステム上にとどまっており,そもそもデータ出力のできないものが多い。辛うじて電子カルテ本体にデータが送られていても,構造をもたないPDFやJPEG等だったりする。これではhuman readableではあってもmachine readableではなく,2次利用ができない。また,共通形式でのデータ出力機能を標準で装備しているパッケージも皆無で,政府の大きな目標であるデータの2次利用を達成するためには,業界レベルで電子カルテにおけるデータの扱いそのものを再検討する必要がある。

4.3 法的問題

2017年5月に施行された改正個人情報保護法は一般法であるため,医学の特殊性が考慮されていない。このため,極端な異常値などが機微情報に属してしまい,これを除外せざるをえなくなっている。これは医学研究においては致命的な障壁となる。また,多施設と共同研究を行う際,診療データを集める場合,病院単位で匿名処理を施す必要があり,結果として複数の医療機関を受診した同一人物のデータは別人として取り扱わざるをえなかった。つまり,匿名化されたデータで,個人をトレースすることはできなかった。また,地方自治体で制定されている条例は,医療情報を個人情報保護法を上回る機密レベルで取り扱うこととしている場合が多く,これもEHRや2次利用の大きな障害となっている(2000個問題)注16)

2018年5月に施行予定の次世代医療基盤法は,これらの問題を上書きする法律として位置づけられている。10に示したように,新たに認定される機関は,EHR機関,病院等から「実名データを受け取る」ことができる。患者の個別同意なし(Opt-Out)に名寄せを行い,匿名加工を行うことができ,実名で名寄せを行ったうえで匿名化するので,匿名IDでの個人のトレースが可能となった。この法律の制定によって,医学研究の飛躍的な発展が期待できる。

図10 次世代医療基盤法の下での,医療情報の取り扱い

4.4 諸外国と比較したEHRの推進体制

われわれがEHR研究に着手したのが1995年。その結果を基にEHRを社会システムとして実装したのが2001年。その時点ではトップランナーだった日本が,この約15年の間に,諸外国の後塵(こうじん)を拝することとなった。先進諸外国(ヨーロッパ,カナダ,オセアニア等)でのEHRは,例外なく国の主導で行われている。使われている予算も,共通して国民1人当たり約50ドル(約5,000円)である。日本の人口で計算すると7,000億~8,000億円である。振り返って,わが国がEHRに投下した予算は,はるかにこれに及ばないし,使い方も散漫で効率が悪い。今回のプロジェクトでも,それほどの予算は使われておらず,将来を見据えた本格的な計画を策定すべきと痛感する。EHRが全医療機関をカバーした場合の多重検査,多重処方などの節減効果は5%程度見込めるので,それだけでも2兆円が節減でき,より有効な医療投資(設備投資など)に使うことができる。行政,政治の決断に期待したい。

5. おわりに

日本におけるEHRの歴史と現在の取り組みについて俯瞰(ふかん)した。この3年間の日本の取り組みは,大変意欲的で結果の期待できる動きである。失われた15年を取り戻すべく,全力でEHRと2次利用の仕組みの構築と展開に力を尽くす所存である。

謝辞

本稿の作成にあたり,尽力いただいた千年カルテプロジェクトメンバーの粂直人氏,小林慎治氏(京都大学大学院医学研究科 EHR共同研究講座),末吉真雄氏(Stellaplace, Inc.)に感謝します。

執筆者略歴

  • 吉原 博幸(よしはら ひろゆき) hiroyuki.yoshihara@gmail.com

1973年大阪大学基礎工学部合成化学を卒業後,企業を経て宮崎医科大学へ進む。卒業後1995年まで外科,その後医療情報学分野へ。1995年宮崎医科大学,2000年熊本大学,2003年京都大学で教授(医療情報学)を通算18年務め,2013年3月退官。2013年4月京都大学EHR共同研究講座スタート。2014年4月~2016年3月宮崎大学理事・病院長。2016年4月より京都大学/宮崎大学(京都大学EHR共同研究講座ディレクター,宮崎大学病院 EHR利用推進センター特別教授)を兼任。京都大学・宮崎大学名誉教授。EHR & Medical DBがライフワーク。

本文の注
注1)  次世代医療ICTタスクフォース:http://www.kantei.go.jp/jp/singi/kenkouiryou/jisedai/kaisai.html

注3)  千年カルテプロジェクト:www.gehr.jp

注4)  日本におけるEHRは,地域,国などのレベルでの電子カルテ(EMR: Electronic Medical Record)のデータの集合を意味する。PHR(Personal Health Record)は,病院由来のデータで構成されるEHRに,病院以外(個人,職場など)で発生したデータ(体重,血圧,歩行距離,職場検診など)を加えたもの。日本医療ネットワーク協会のWebサイト(http://www.ehr.or.jp/)には,Dolphin Projectや千年カルテプロジェクト(http://www.gehr.jp/)のリンクもある。

注5)  ISO 13606-1:2008 Health informatics -- Electronic health record communication -- Part 1: Reference model。https://www.iso.org/standard/40784.html

注6)  Seagaia Meeting:http://www.seagaia.org/

注7)  MML:異なる医療機関(電子カルテシステム)の間で,診療データを正しく交換する為に考えられた規格。MedXMLコンソーシアム(http://medxml.net/?page_id=9)より引用。

注8)  SaaS:インターネットなどを通じて,必要な機能を,必要なときに,必要な分だけサービスとして利用できるようにしたソフトウェア,もしくはその提供形態をいう。

注9)  スケールアップ,スケールアウト:スケールアップとは,サーバーやメモリーなどハードウェアの能力を上げ,処理性能を上げる方法。スケールアウトとは,サーバー数を増加させることで,処理性能を上げる方法である。

注10)  レプリケーション:サーバー内や遠隔地にデータをリアルタイムでコピーすること。

注11)  The openEHR Foundation:http://www.openehr.org。日本openEHR協会:http://www.openehr.jp/

注12)  1000年カルテ 患者用カルテ参照サービス:https://youtu.be/ShKchgsnD7Q

注13)  Health informatics -- Requirements for an electronic health record architecture, ISO 18308:2011。https://www.iso.org/standard/52823.html

注14)  Health Level Seven International:http://www.hl7.org/

注15)  MedXMLコンソーシアム:http://medxml.net/

注16)  2000個問題:全国の自治体に存在する条例が2,000個あり,それぞれに過剰な個人情報保護をうたっている,という問題。新法は,この条例の保護規定を「上書き」する立場。

参考文献
 
© 2018 Japan Science and Technology Agency
feedback
Top