FAQ » 履歴 » リビジョン 11
リビジョン 10 (KOBAYASHI Shinji, 2011/09/09 17:30) → リビジョン 11/13 (KOBAYASHI Shinji, 2011/09/13 09:18)
h1. よくある質問と回答
このページには今まであちこちでうけた質問とそれに対する回答を書いていきます。個人的見解を含みますので、ご注意ください。
h2. Q.HL7やMMLとはどう違いますか？
h2. A.メッセージと記録の違いです。
HL-7はシステム間でやりとりするメッセージを標準化する目的で策定され、MMLは施設間連携、地域医療情報共有を目指して策定された規格です。一方で、ISO13606は各システムに記録される診療情報、健康に関する情報を標準化する目的で策定されました。標準化されたメッセージを作成するためには、元となるデータがきちんとした粒度で保存されている必要がありますので、お互いに補完するものであり対立する概念ではありません。
h2. Q.Archetypeはよく考えられているが、手間がかかりすぎる。忙しい日本には向かないのではないか。
h2. A.忙しいからこそ、Archetypeで基盤づくりをすることが重要です。
日本の医療現場は過剰労働によって成り立っていることは承知しています。その現場を支えるために、日本では医療の電子化が進められ、電子カルテシステムというのが開発されてきました。医療の電子化が進めば現場の省力化や効率化が達成されるという期待のもとに、現在も普及拡大が続いております。これについては様々な議論もありますが、一定の役には立っていると思います。現場重視でなくてはいけないという意見はよくわかりますし、まず第一に考えなければならないことでしょう。
しかしながら、既存のシステムには以下のような問題があります。
* データの再利用性（相互運用性）が乏しい
* データの内部構造がベンダ依存になっているために、データを利用するためにはベンダの協力が必須であり、システムに不満があっても変更することが難しい
* 各種統計にデータを再利用することがなかなか困難である
* 標準規格に則ってメッセージを作成しようとしてもなかなかデータを出すことができない
* 現場の要求により新しいシステムを構築しようとしたときに既存のデータを活かすことがなかなかできない
これらの問題を解決するためには、データそのものの相互運用性を向上させるというのが遠回りに見えて本質的な解決につながります。そして、それは忙しい現場の要求に機動的に対応するシステム構築を支えるものとなる可能性があります。Archetypeを採用するかどうかについては、最初から否定するのではなくいろいろな条件や他の手法と比較した上で判断すべきとは思います。現状ある問題についてどのように解決していくのか。あるいはしないのか。解決するとしたらArchetype以外にどのような方策を取っていくのか。少なくとも医療情報学に携わるのであれば、前向きに進む議論をすべきであると私は考えます。
h2. Q.公開されているArchetypeが少ない。日本向けではない
h2. A.ないものは作りましょう。
Archetypeを作成することはそんなに難しいことではありません。公開されているアーキタイプエディタを使えば、誰でもArchetypeを作成することができます。アーキタイプエディタにはいくつかありますが、その多くは無償でopen source softwareとして提供されています。しかし、そのArchetypeの設計が妥当なものであるかについては、多くの議論を重ねる必要があります。"Clinical Knowledge Manager":http://www.openehr.org/knowledge/ には多くの議論を積み重ねられてヨーロッパやオーストラリアで実用されているarchetypeが約250個公開されています。しかし、これだけでは不十分であり、(日本に対応した)Archetypeをもっともっと創っていく必要があります。
日本独自で作成されたarchetypeを含めて、翻訳したものや、いかにも未成熟で使い物にならなさそうなのまで含めて、大々的に公開して共有するリポジトリを構築するように今、本家に働きかけているところです。比較的ゆるい条件で利用することができるようにしていくつもりです。他のオープンソースソフトウェアプロジェクトと同様に、共有して共同して開発することで質の向上と量的な拡大を狙えると思っています。99%はJunkでも1%のdiamondが発掘出来れば成功であると思っていますし、試行錯誤はあって当然だと思います。
ないからといって不平を言うだけでは前には進みませんが、もし、その足りない部分を新たに作って公開すれば世界中で再利用されて感謝されることになります。ノウハウや経験はやりながら身につくものなので、お気軽にどうぞ。本家とはライセンスについて協議しており、決着がついたらアナウンスします。
h2. Q.Archetypeの概念がわかりにくい
h2. A.技術者としてArchetypeを利用したEHRを開発するのであれば、情報学、情報工学の素養が必要です。臨床家であればわからなくてかまいません。
Archetypeのベースとなる考えは、オブジェクト志向やデザインパターンに基づいています。これらのベースとなる知識がなければ、Archetypeを理解することは難しいと言えます。しかし、これらの知識は特殊なものではなく、現代のIT技術に関連するものであれば必須の教養です。
技術者としてopenEHR、archetypeに取り組むのではなく、臨床家として概念モデルの設計を主にするというのであれば、必ずしも上記の知識は必須ではありません。Archetypeとは診療概念の単位を定義するものであるということだけ理解すればOKです。
h2. Q.費用負担はどれくらいか。
h2. A.原則として無償で使えますが、全てではありません。やる気次第です。
Archetypeやtemplateを設計するために必要なツール類や仕様は無償で入手することができますし、サンプルも入手可能です。JavaあるいはC#, Eiffelでの実装もOSSで手に入ります。GastOSやOperrefaといったサンプルアプリケーションもOSSで公開されています。ArchetypeベースのEHRをすべてOSSを組み合わせて構築することも不可能ではありません。あとは開発ツールやDBに商用のものを使うのかどうか、開発するにあたって有償のコンサルタントをうけるかどうかによってコストが変わります。
h2. Q.ADLのような特殊な文法が必要となるのは問題ではないか
h2. A.ADLをあまり意識する必要はありません。
ADL(Archetype Definition Language)はArchetypeを記述するために作られたDSL(Domain Specific Language)です。ADLのパーサやシリアライザを書くのでなければ、直接読み書きすることはありません。直接開発する人でも、既に公開されているパーサやシリアライザがあるので、それを利用すればいいでしょう。ユーザーや臨床家にとって、MS-Wordがどのような形式で保存されているかまったく知らなくていいのと同じくらいに、ADLについての知識は必要アリアmせん。ADLのようなDSLはあちこちでみかけますし、特に変わったものではありません。XMLで記述することもできますので、XMLでないといけない用途にはXMLを利用してもかまいません。
h2. Q.