2016年12月13日火曜日
2016年12月12日月曜日
FHIR and the future of interoperability
2015/1のHealthcare IT NewsのFHIRを紹介する記事。
リソースの例として次のようなものを挙げている。
今日,LOINCなどの各種標準用語集によってデータだけでなくその意味も含めて伝達するツールを備えている。
FHIR and the future of interoperabilityFHIRとC-CDAを比較する記述がある。
And unfortunately, C-CDA is designed to transfer entire documents, rather than a single piece of data or a simple list.思っていた通りだ。CDAはドキュメント全体を伝送するように設計されているとのこと。それに対してFHIRはデータの断片や簡単な一覧を伝送するよう設計されている。
The major technology change embodied in FHIR is a fundamental move away from a document-centric approach to a data-level access approach using application programming interfaces or APIs. Specifically, FHIR features a concept called “Resources,” meaning a very basic set of structured data.FHIRはAPIを用いて"文書中心"アプローチから"データレベルアクセス"アプローチへ移行した。特に"リソース"というコンセプト(最も基本的な構造化されたデータのセット)を 特徴としている。要するにROA (Resource Oriented Architecture) ということだ。そのリソースにアクセスするためにAPIを利用する。そのAPIとはRESTfulなAPIだ。
リソースの例として次のようなものを挙げている。
- 処方一覧
- プロブレムリスト
- 検査結果
今日,LOINCなどの各種標準用語集によってデータだけでなくその意味も含めて伝達するツールを備えている。
What FHIR offers is tools for developers to assemble and present many much smaller data elements to enhance the context or meaning of the information.そのうえで,FHIRが提供するものは,開発者がコンテクストや情報の意味を増強するために多くの小さなデータ要素を組み立てたり提示したりするツールである。
なぜFHIRなのか
PHRの基盤を構築するにあたり,なぜHL7 V2やHL7 V3,あるいはCDAではなく,FHIRでなければならないのかを説明できなければならない。そのためには地域医療連携システム及びその標準であるIHE XDSと対比して考えるのがよい。
まず,標準化のためにはHL7を利用する必要があるが,PHRは基本的にモバイル端末での利用となるから軽量である必要がある。したがってHL7 V3は重すぎるので候補から外れる。次にHL7 V2はどうだろう。わが国ではSS-MIX2標準ストレージの共通フォーマットとして利用されている。しかし,HL7 V2はセマンティックスを伝達できない。単なるデータの塊に過ぎない。仮にこういったフォーマットをスマホ等のモバイル端末で扱うとしたらフラットなHL7 V2セグメントをオブジェクトに変換する必要がある。これはそこそこにオーバーヘッドである。できればオブジェクトとして外部リソースへアクセスしたい。また,CDAはトランザクションを前提にしていない。退院サマリ,診療情報提供書,特定健診データなど,ある時点での完成した情報の塊である。スマホからPHRデータを入力する都度CDAを出力するのは全く非現実的である。以上から,リソース指向でRESTfulなAPIでダイレクトにアクセスできるFHIRしか選択肢はあり得ない。
まず,標準化のためにはHL7を利用する必要があるが,PHRは基本的にモバイル端末での利用となるから軽量である必要がある。したがってHL7 V3は重すぎるので候補から外れる。次にHL7 V2はどうだろう。わが国ではSS-MIX2標準ストレージの共通フォーマットとして利用されている。しかし,HL7 V2はセマンティックスを伝達できない。単なるデータの塊に過ぎない。仮にこういったフォーマットをスマホ等のモバイル端末で扱うとしたらフラットなHL7 V2セグメントをオブジェクトに変換する必要がある。これはそこそこにオーバーヘッドである。できればオブジェクトとして外部リソースへアクセスしたい。また,CDAはトランザクションを前提にしていない。退院サマリ,診療情報提供書,特定健診データなど,ある時点での完成した情報の塊である。スマホからPHRデータを入力する都度CDAを出力するのは全く非現実的である。以上から,リソース指向でRESTfulなAPIでダイレクトにアクセスできるFHIRしか選択肢はあり得ない。
2016年12月1日木曜日
FHIR, RESTful API, ROA
HL7 FHIR は HL7 V3 の反省から考案されたものだろう。かつてのMULTIXの失敗がUNIXを誕生させたように、重装備したADA言語が今日ほとんどみられなくなったように。そしてこのFHIRはRESTful Web サービスの考え方が医療分野にもたらしたインパクトだと思う。FHIRはROAに基づいた医療モデリングの実装手法を提供するものである。この考え方は、この世はすべてリソースからできており、そのリソースへはRESTful APIを使ってアクセスできるというものである。FHIRは医療分野で用いられるリソースを提供している。だから我々は何かあるアプリケーションを構築したいと考えたら、そのシステムで扱う世界をFHIRが提供するリソースを組み合わせて表現し、RESTful APIを用いてCRUDトランザクションを実装するだけでよい。
登録:
投稿 (Atom)