「医療情報学/医療情報システムの第2世代」ということで、浜松医大の木村先生にご講演をお願いしたいと思います。恒例ですので、講演に先立って木村先生をご紹介申し上げます。情報工学修士を、86年には併せて阪大医学部をご卒業です。教授をしておられます。標準化委員長としてご活躍中です。本日は、「医療情報学/医療情報システムの第2世代」ということでご講演をお願い致します。はじめに最初にこの講演のご依頼をいただいた時に、今までどういう方々がご講演なさったか伺いましたところ、本当に錚々たる先生方が講演をなさっておられ、私ごときではちょっと荷が重いと思ったのですが、業界団体の集まりの後、懇親会の前ということで、余興という位置づけで聞き流していただければとお引受けしました。タイトルで「第2世代」と書かせていただいたのですが、私は今日、里村先生と高橋先生がいらっしゃるとは思いも寄りませんで......、ご免なさい。先ほどご紹介いただきましたように、私は今年40歳になりますが、15年くらい前から、この分野で少しずつ発表させていただいております。当時はまさに第一世代のパイオニアの先生方がいろいろご努力なさっておられましたが、この分野で今、業界団体からこれだけ活発な報告があり、それぞれに実際に即した活動を行っておられるということは、15年前には想像できないことでした。我々の世代と申しますか、我々はその良い伝統を引き継いで、より以上に発展させていく必要があるわけで、その際に、今までに私がどのようなことを思ったかということを中心にお話申し上げたいと思います。<図2>今日は、病院情報システムということに関して、どのような経緯で今まで発展してきたかということを申し上げ、次に標準化について一言お話させていただきます。オブジェクト指向についても少し触れさせていただいて、次に電子カルテ、私は「電子化診療録」という言葉を使いますが、これについても触れます。このような各論を通して、病院情報システムを普通のシステムにして欲しいということを申し上げます。分野そのものはスペシィフィックな分野ですから、それぞれの特殊性はあっていいのですが、その一部の特殊性を理由に、すべてを特殊にしてきたのではないかということ、それがまた、標準化の遅れとか、高コスト体質といったことにつながったのではないかということも、ずっと考えておりました。それについて述べさせていただいて、もちろんメーカ側の皆さん、そして我々側と、問題点は両方にあるように思いますので、それについて少し挙げさせていただきます。この分野は我々だけで物が作れるわけではありません。この「我々」というのは、私の世代の学者側ということですが、結局、いくら我々がメーカを厳しく叱ったりしても、作るのはメーカの皆さんですから、メーカの同じ世代の方々にメッセージが伝わらなければと思います。いう意味で今日は、私が思っていた以上に若い皆さんが会場に来てくださっていることを非常にうれしく思うと共に、そういう方々の考課表をお書きになるような立場の方々がたくさんいらっしゃるということも、そういう方々に非常に仕事をしやすい環境を作っていただくという点でも有意義なことではないかと......。業界団体の集まりということですから、そういったことも意識してお聞きいただければ幸いです。病院情報システムの来し方さて、15年くらい前に医事会計システムというものが登場して、保険請求の電算化、EDPSといった言葉がありましたが、そういう時代がありました。引き続いて、検体検査のデジタル化がありました。当時は、応用人工知能でいろいろなことができるのではないかということで、通産省の大きいプロジェクトもありましたし、ちょうどこの会場で11年前に医療の人工知能の国際シンポジウムがあったことを覚えております。これはやはり先ほどの報告でも着実に増えていることが示されておりました。医療情報の分野でできたものにしては、着実に市場を広げているということはすばらしい成果ではないかと考えておりますし、この分野について私はあまり詳しくない部分でもあるのですが、当時の先生方及びメーカの方々に敬意を表する部分でもあります。画像システムがそろそろ使えるという状況になって、その頃に、画像と共に第1期の電子カルテというものが出現しました。今では盛んに電子カルテと言われるところですが、実は7、8年前にもそういうことを少し言った時期がありました。鹿霈そうこうしている間に阪神大震災とか薬害エイズ問題といったことがあって、会計から始まって病院の業務についての情報システムが業務範囲を広げるにつれて、医療の分野そのものが社会から何か求められる時に、我々も他人ごとでは済まなくなっているということを痛感しました。おタクの遊びでは済まなくなったということです。次に、インターネット・マニアですが、このマニアというのは人間の好事家という意味ではなくて、インターネット熱病とでも言いますか、躁病とでも言うべきものです。いうものがきて、現在もう1回電子カルテがちょっと形を変えてという状況に至っているのではないかと思います。鹿霈<図4>さて、一つずつ説明させていただきます。「医事会計システムの登場」は、大体1975年から80年くらいではないかと思います。その利点はどういうところにあったか、いきなり総括させていただくようなことになりますが、何よりも計算事務の迅速化、そして単純な卓上計算器のような作業からとりあえず人間を解放して、省力化が進んだということです。大きな大学病院クラスですと、当時はとても無理と考えられていた同月請求も実施されるようになったわけです。普通の商売から考えれば、運転資金の1カ月の支払サイトの差というのは死活問題なのですが、それで経営の健全性の確保がなされたことは申すまでもございません。(1983-86あたり)でよく行われた議論というのは、会計システムを入れればそのデータからいろいろと経営につながるデータが取れて、経営の指針づくりに役立つという推進派の先生に対して、どちらかというと京都のほうの先生は、「いやいや、あんなデータは丸まってはいるし、入っていないものもあるし、とてもではないがいきなりすごく有効な経営分析の情報が得られるというものではない」というような議論が毎回行われておりました。結局、時代を越えても、丸めはその後更に進んで包括も進みました。オーダエントリが普及していろいろデータが入るようになったものの、それに引きつれて、先ほど西山さんからもご指摘がありましたが、よりたくさんの情報を入れなくてはいけなくなってしまっていて、結局医事システムの、つまり帳票としてレセプト処理後のデータから分析情報をというのでは、やはりあまりクレデビリティの高い情報は得られないのではないかと思っております。一方で、先ほどからご議論、ご報告がありましたが、いろいろな意味でのマスタの標準化というのは進んでおりませんでした。先ほどは、主に医事行為のコードということで標準化の推進というものが議論されていましたが、そもそも病名、それから薬剤のコードもあまりすっきりしたものはなかったのです。薬剤については、いろんな種類のコードが厚生省の中にもありましたし、検査もさまざまなコードがありました。先ほど川真田さんのご紹介で、臨床病理学会のコードを使うという方針がやっと出てきたということでしたが、さまざまなマスタの標準化が出来ていないという状況でした。鹿霈それがやっと最近、そういうものが基本であるという意識を皆さんに持っていただけるようになったことは、私は日本医療情報学会の標準化委員長として非常にうれしく思っております。それで、私は学校の先生ですからそれぞれの項目に評価の点を付けさせていただくと、業務の点では非常に利益を産み出しておりますが、あまりスマートな回答ではなかったなという感じがあって、80点くらいにさせていただきました。鹿霈<図5>次に「検体検査の自動化」。これは病院の規模にもよりますが、80年代の初めくらいから起こって、より大規模化してきました。これは当然ながら、検査部の圧倒的な省力化になりました。いう大規模なものを短時間に処理する機器によって、まさにスケールメリットが追求できます。病院の中でこの分野は、アウトソーシングという概念が結構早いうちから進んでいて、それはある意味では検査の質の向上にも貢献している部分もあります。これはもちろん情報分野が誉めていただける部分だけではないのですが、検査機器メーカさんの勲章です。一方で、当然ながら「数値結果をデータベース化」し、ドクターやナースが検索して表示するというシステムは、オーダエントリより少し前くらいから、検査結果は端末で見えますというような形で出てきていたように思います。これは、医者にも看護婦にも非常に歓迎されたということが言えると思います。鹿霈それに対して何が十分でなかったかというと、無理もないのですが、波形データとか、構造のあるような結果とかがなかなか扱いにくかったことです。それは、一つにはそういうことに使われた計算機のデータ構造といった面にも原因があるかと思います。医療情報としては何といっても無駄な検査が行われないように、例えば、施設が変われば、あるいは同じ施設内で、また、大きな病院の中では科が違うだけでも非常に重複検査が多い、というようなことにまで目を向けてシステムが作られただろうかという点が疑問に思えています。鹿霈とはいうものの、この点はやはりそう大きいマイナス点ではなく、主に他人さんのアチーブメントということもありますが、A、優の点である、90点を付けさせていただきました。<図6>「人工知能の夢」。これは、まさに私がこのステージで申し上げるべきことだと思います。85年から90年頃に、知識工学と呼ばれた分野ですが、知識をシンボリックに表現して、それに推論を使って人間のエキスパートの推論、特に医療であれば診断といったことを機械にやらせることができるのではないかというような夢がありました。結局、今何が残っているかというと、教育システムに少し動いているものとして残っているものがあるかという程度ではないかというように評価せざるを得ません。鹿霈とはいうものの、基本的データ構造がどうあるべきかというような点、そのセマンティックスをどう表現するかという点に関して、あの時代にいろいろな人がタックルした内容は、完成品としては実現してはいませんが、いろいろな良い部分品を輩出したという点で決して無駄ではなかったと思います。鹿霈というのも結局、画像規格DICOMの構造もあのような構造化された表現をとっておりますし、HL7のバージョン3もそういう方向へ行きますし、そして他のいろいろな項目コードに関して、例えばSNOMEDコードにしても、ああいう構造化された表現で書くべきである、つまり、マスタとか用語というのは、一次元で、ペッタンコのリストを作るものではないというようなことは、この時代の研究成果から得られた知識ではないかと思います。結局、当時のそういう夢は、用語やコードが全然標準化されていない点、従って一つの所で作ったものが他で使えない、また、検査結果から推論するシステムを作っても、検査結果を自動的にそのシステムに呼び込めるようにしておかないと、とても臨床の場で使えるものではないという点、そこがこの実装と実験のギャップという点にあったと思います。当時は、メインフレームの上で動くCOBOLで書かれたオーダ系、あるいは検査結果等の参照系に対して、COBOLで書かれたそういうものからどのようにデータを取るかは、非常に困難を極めてなかなか実現することができませんでした。これは我々に対する評価も含めて、やはり合格点は与えられないだろうということです。鹿霈11年前このテーブルで、ドイツ、フランス、アメリカから人を呼んで行って国際シンポジウムで提唱されたことは、結局そのままでは実現していません。ここで私が申し上げたいのは、今や標準化は進み、やっと他の施設からのデータも収集できるようになり出しました。それで、いろいろな部門システム、例えば検査システムとか、処方の内容とかそういったものは、オープンシステム化して、つまりCOBOLの命令を書いて吐き出させることなく取れるようになってきています。このことは、私が10何年前にやろうとしたことは、今や標準化が進んで実は実現可能な土壌になってきたという意味です。それで、非常に忙しくなってしまったのでどうやってやろうかなと......。やらないと、この30点の追試を10年越しに受けなければならないと、私は思っております。結局こういったコードとか用語の標準化、そしてそのオープンシステム化が進んでいないというのが、私が8年くらい前に問題点と考えたことです。この分野の基盤整備は、当時から見れば、どうもあと30年くらいかかりそうに見えました。単年度の予算でプロジェクトを作るように、例えば「沼地だけれども、すぐに家を建てろ」と言われたら、それは高床式の家を長い杭でも打って、水面から湿気が上がってこないように建てると思いますが、30年やると思えばとりあえず土質の改善からやろうという気分になるわけです。鹿霈ですから、そういう高床式の家を建てて、とりあえず何かシステムができた、さあ、そのシステム間で、つまり家の間で行き来してみてくれないか、システム間でデータのやり取りをしてくれないかということですが、そんな器用なことはできるわけがありません。それをちゃんとやるためには、しっかりと土壌を改善して、道路等のインフラを整備して普通の家を建てるというのが、30年を考えた戦略だと私は考えており、やっと標準化という点でインフラが整備されてきたというところだと思います。オープン化というのは、医療情報の分野だけではなくて、インフォメーション・テクノロジー全体で叫ばれ出し、それと共にやっと実現できる時がきたので、そろそろ2000年に向けて再試験の受験を考えようという気分です。<図7>1990年頃には、「医者にキーボードを触らせるの?」という驚きがこの業界にはありました。オーダエントリ、つまり発生源入力、医者に検査や処方の指示内容を入れていただくということです。それで、オーダ種によっては確かに待ち時間は短縮しました。オーダ種によっては、医者や看護婦の作業の効率化は成りました。鹿霈Do処方は簡単で好評です。検査の予約をあらかじめ入れてもらうと、いちいち診療科で受付けなくても直接検査室に行ってもらえます。ここでもう一つ強調したいのは、受け部門が手書きの伝票から解放されたということが非常に重要なことだったということです。土屋先生が「何にせよ、あの汚い処方箋を読まなくて済むようになったことで、薬剤師は大変喜んでいる」とおっしゃっておられたことが強く印象に残っております。「オーダ種によって」というのは、処方とか検査といったものに関しては、ほぼユーザ、つまり医療従事者側も患者の側も、そして管理サイドにもそれぞれにメリットがある、つまり、待ち時間は減るしDo処方はしやすいし、予約は入れやすい、それで情報がちゃんと得られて、受け部門には情報が飛んでくるということです。オーダの種類によっては、圧倒的にどこかの部門の負担が大きいというようなことがあったりして、スムーズにはいかないことが多いようです。そのオーダエントリによっては、あまり業務の効率化が図れないということです。いうオーダ種とは、例外の多いものとか、あるいはたくさん細かい入力事項を必要とするものです。医者や看護婦がいやがるのは、オーダさせておいてもう1回カルテに書かさないでくれという点です。これは当たり前のことで、嫌がるのも無理はないと思います。医療情報部の管理サイドが非常にプレッシャーを受けるようになったのは、何といっても今まで会計が止まれば会計のところだけちょっとドタバタするという状況でしたが、オーダエントリが落ちると、検査はできない、診療はできない、会計もできないという状況になってしまうということです。これも先ほど申し上げたように、それだけ我々も役目が増えたわけですからそれだけ任務も多くなり、したがって責任も多くなるということで、当然のことといえば当然のことです。評価としては75点、こんなものでしょう。鹿霈オーダで何もかもできる、何もかもオーダすればいいという管理サイドの夢というのは実現しません。いうものの、先ほどの工業統計の報告でも、着実にオーダエントリのインストール件数は増えています。国立大学病院のような特殊な所だけではなくて、普通のユーザがあってこそ数字の伸びがあるでしょうから。現実に、国立大学や国立病院のようなコスト意識の少ない所でも、そうでない所でも導入されているということなのでしょう。評価はこのあたりではないかということです。鹿霈<図8>「PACSと第1期の電子カルテ」。あの北大のPACSは1989年ですね。当時あれほどの大容量データを扱うということは、他ではとても出来ていなかったことです。したがって北海道大学のあのPACSは、やはりミュージアムクオリティものだと思います。やって見せた、できなかったことを実現したということは、すばらしいことだと思います。今、落ち着いて考えてみると、CRT読影が可能な画種、検査種はもちろんありますが、単純写真の検査にフィルムレスという姿勢で最初からアタックすると、やはりこれで(CRTで)読めるかというような話になって難しいのです。CT、MRみたいなものであれば、こういう技術的な問題は少ないと思います。何よりも、私が一部参加させていただいて誇りに思い、また他の努力された方々を賞賛したいのは、やはり画像の部門が標準化に関して一番優等生という状況ではなかったかということです。画像における標準化は1986年ごろからずっと言われ続けていました。これは、例えば日本のメーカも、アメリカやヨーロッパにCTを売っているし、ヨーロッパやアメリカのメーカのものも日本で買えるということで、この状態では画像規格は一つのものにしてくれというような求心力が、自然に世界的に起こった非常に良い例だと思います。しようと思った時、CTのデータは、ほとんどそれぞれ別のメーカごとの、そしてメーカの中でも機種ごとに全く違うMTのデータ形式になっているという状況で、どうも他の画像処理をやる放射線科も、みんなそれに悩んでいるということを聞き、これは泥沼だなと皆辟易していた状態でおり、ニーズとシーズがぴったりしたプロジェクトという、標準化の進展でもありました。鹿霈さて、それではフィルムレスはいつになるのかという質問をされて、答えることができないのです。先ほどの永井さんのご発表でも、「フィルムからの呪縛が解かれる部分」、つまり「健診等では」という話がありました。「フィルムからの」というのは、正確に言うとフィルム代というお金を当てにした根性からの解放という意味ではないでしょうか。健診であれば、もうフィルムに焼こうが焼くまいが関係ありませんから、無くさず、効率よくちゃんと画像を見ればいいという、市場原理に基づきやすい分野であるわけです。これに関してもいろんな議論がありますが、ここでその議論をしているときりがないので、先へ行きます。次は「画像は誰のもの」。診断の医者たちは、危機感をもっていて、画像がどんどん流れていくというのはどうしたものか、困るという考え方をしています。それに対して、付加価値のあるレポートを出すことによってと考える診断の医者もいれば、いやいやそれは勝手に見てもらったら困るという医者もいます。それはまた、放射線部ができた経緯がその病院によって違い、脳外科は先に持っていっていいことになっているとか、頭のCTは読まないとか、それぞれの大学病院、大病院によって運用が違うのです。鹿霈そうしている間に、病院情報システムのクライアント端末のレベルでも、ある程度のものが見える、つまり、病院の中にネットワークの非常に速いものがだんだん普及してくると、そういうことも可能となってきます。PACSが放射線部の中から外に飛び出す時期がきた時に、さあこれをどう決着させるか。回答は特にありません。それぞれの施設の経緯などもありますから。技術の進展によって、次のそういう検討項目が出てきたというふうに考えられます。結局のところ、フィルムレスという部分が達成出来たかどうかというのは、ちょっと難しく、60点か65点くらいでいいかと思いますが、やはりフィルムレスという姿勢で最初に入ってしまったので、それを言われると合格やっとという程度になるのではないかと思います。「第1期電子カルテ」というのは、当時、画像情報が扱える、つまり光ディスクといったものが整備されてきて、カルテを画像としてファィリングするという時期がありました。それを電子カルテと称する時期もあったのですが、当然ながら、内容に関する検索ができません。これはどの病気かくらいはタグを付けてもいいのでしょうけれども、それも別途付けないと付きません。文章の内容に対する検索というのは当然できないので、ちょっと電子カルテと電子化診療録というものとは言えないのではないかという議論が当時あったように思います。鹿霈<図9>さて、そうしている間に阪神・淡路大震災があって、電気が来ていても水があっても、相手に届いているかどうかわからないオーダなどというのは、逆に状況を混乱させるばかりということで、まず電気や水は検査機器、それもスタンドアローンでできるものに廻し、水がなくてフィルムが現像できなければ、それこそ上部消化管のモニターで骨折を診るというような状況になったわけです。結局、その時に我々は、病院情報システムの基盤の脆弱性ということを身に沁みて知ったわけですし、それに関する先ほどの可用性検討ワーキングの報告もありました。一言申し上げたいのは、ハードウェアの対策というのは非常に取りやすいし、予算化もしやすい。それに付随してソフトウェア的なこともできるでしょうけれども、結局、運用の部分というのが非常に重要になってくるということを一言申し添えます。病院情報システムに関する例ではありませんが、電話が輻輳して全然かからなかったという状況になって、電話はかかるようにしなければならないからいろいろな電話を用意しようということで、いろいろな表技、裏技がたくさん出ています。出てきましたが、そういうものがたくさんあります。鹿霈ところが、もしも電話が輻輳していなかったとして、あの状況でどうなっていたかというと、病院にかかってくる「担ぎ込まれたうちのおばあちゃん、どうなっていますか?」「入院しているうちのお父さん、どうなっていますか?」といった、あまたくる電話の中に埋もれて来る他の病院からの「ちょっと透析5人やってくれないか」というような重要な電話をちゃんと確実に取れたかどうか。電話がかからなかったことによって、電話の運用、つまり代表番号にばかりかかっていては、当然交換台はパンクしたであろうこと、さらには電話がかかっても医者に出る暇がなかった(あたりまえですが)ということなどがわからなくなっています。隠し番号を作っておくといった運用面の検討が必要であることが、ハードウェアの障害によって陰蔽されてしまっているのではないかというふうに、この件を仔細に検討して思いました。鹿霈もう一つ申し上げるなら、我々は医療情報システムを扱う立場ではなくて医療情報をお預りする立場であると考えていますので、災害時には紙の診療録としてどういうものが必要かということも検討すべきであろうというようなことを考えて、救急部の全国的な組織と相談をしています。次に「薬害エイズ」の話ですが、10何年前の加熱製剤の投与歴を探せという話があって、もちろん廃棄の期間を過ぎているものが大半なので法律的には見つからなくてもいいのですが、大多数の病院は倉庫からカルテを出して来て繰ったと思います。はと聞かれて、それがちゃんとシステムで調べられた病院がどれだけあったでしょうか。社会から見て、機種更新とかベンダー変更というのは理由にはなりません。我々は、こんなに大事な情報をお預かりしても、大事に扱っていなかったということを強く反省させられた事件でした。いうデータの扱い方をしていると、「ああそうか、単なるその場での事務処理のシステムなんだね」と言われてしまい、じゃあOA機器だ、売上げの1%とか、もうちょっと叩いて0.何%で十分だというふうにマネージャは考えるでしょう。ない、それ以上の情報の付加価値ということを考えなければならないと思います。点数は20点、不合格ですね。鹿霈<図10>「インターネットマニア」。ユーザの裾野の拡大、ハードウェアの低廉化などは、大変結構なことです。TCP−IPとか、SMTPメールのプロトコル、文書のプロトコルではHTMLなら、確かに標準化されて広く使われるようになりました。非常に結構なことです。そのSMTPもHTMLも、あのブラウザでは読めるけれども、あっちではちょっととかいう話が少し聞こえて来ました。鹿霈どうも標準化に関する考え方に間違ったものがあるのではないかというふうに思います。マナーの低下はいうまでもありません。このマナーも、もちろんクラッカーとかいうレベルの話ではなくて、標準的なものを使っているということに関するマナーです。言えば、電子メールアドレスを名刺に書けば、多分、SMTPプロトコルで送られてくる普通のメールはもちろん読めますよという意味だと思いますが、その人が添付文書を読めるかどうか、つまりMIMEに対応しているシステムを持っているかどうか、ましてや、特定のワープロのソフトを持っているかどうかなどということは、全然わからないことです。それを相手に聞きもせずに、いきなり何か特定のワープロの文章を添付文書で送るなどということがごく平気に行われて、それを無礼なこととも知らずにやっている人が多いということを非常に憂えておりまして、これはどうしたものかと思います。当初は非常にいいものであったと思いますが、今やひょっとしたらインフォメーションテクノロジーというのは、プラスマイナス相殺すれば、社会から要らないと言われる時期も来るのではないかという気もしております。<図11>最後は、「電子カルテの最近」についてですが、コンポーネントの分散化及び標準化は加速しておりまして、非常にうれしいことです。これがケアマップとか、あるいはいろんな診療、診断、治療のプロセスを見やすくする形で記載して、それぞれに関してその根拠を示すという、エビデンス・ベース・メディシンという考え方というか、運動というのが今あるのですが、その基礎となるかどうかがポイントで、ならなければ紙のカルテの電子化にすぎないと言われるでしょう。それは実現されるかと思いますが、一方、当然ながらよくなされる議論で、ユーザインターフェイスは不満足なまま、要するに手書きの方がずっと速いという点です。先ほどのいろんなスタディでも、成功例としてご訪問になっておられることが多いようですが、あまり詳しくない事務系の方が過度な期待をされて、「うちの病院は、次は電子カルテだから病棟にカルテスペースを作らなくていいんですよ。」と平気で考えているという、寒い設計の話を結構聞きました。その反動が非常に怖いです。私はまだ40点くらいしか付ける気になりません。標準化論さて、「標準化」についてちょっと語らせてください。UNICODEを例にとって、間違った考え方とはどういうことかということを、しっかり申し上げたいと思います。<図13>「UNICODE」というのは、今ISOの10646になりました。これは世界万国の文字を同時に均一に扱うための、2バイトの文字コードのセットです。漢字を入れていると溢れてしまいます。Ideographicsということで、同じ様に見える文字は同じコードを持たせるというふうに統合されてしまいました。鹿霈ところが、中国は簡体文字にする際に、骨というのは一画少なくなるという理由でこういうふう(日本の「骨」の左右対称の鏡像)にしてしまったのです。乱暴なことに、これは同じだということで、9AA8というコードがどちらにも付いています。これと日本の「骨」が同じだというなら、NとИ、これはロシア語のIですね。それとRとЯ、これはロシア語のヤー、これは同じだろう、これを代わりに使ってくれと私は言いたいのです。鹿霈ではこれに対応して、日本でUNICODEを使う時には、こっちの左側が出るというようにしようという、「このドキュメントは何語で書かれています」という言語情報を使えばいいではないかということが言われていますが、「日本語で書かれた中国語の教科書」といったものは、非常に書きにくくなります。同じように、例えば、在日韓国人が自分の名前を正しく書いて欲しいけれども、しかし住所などはもちろん、日本語で書かれた漢字、というサービスを我々は要求されると思います。UNICODEではこれらに対応できません。UNICODEはすべて2バイトなのですが、アスキーの文字だけを使う人たちが、それはいやだと思って、7ビットのアスキーを1バイトのままに保って、ほかのものを畳み込む写像方法というのが、ユニコード・トランスファー・フォーマットの一つであるUTF—8というものです。これによるとアスキーコード、つまり7ビットのアルファベット数字等は1バイトで、元のままです。ウムラウトのあるドイツ語、アクサンのあるフランス語、ロシア語、ギリシャ語、ハングル、片仮名、他のあまたある表音文字たちは2バイトでいいのですが、漢字は3バイトになってしまいます。このUNICODEをそのまま英数字にも2バイトで使うというなら、バカ平等というやつでいいのですが、これを使うべきだという人たち、つまり特にアングロサクソンの人たちは、自分たちには痛みがないくせに、他人の犠牲のもとにこれはグローバルだと主張しているのです。いう想像力のない考え方が、最も大きな標準化の敵であると私は考えています。2022方式を用いるべきなのです。これですべての言語的問題が解決出来るかというと疑問であり、右から左に書く文字はどうしようとか、例えばモンゴル語みたいに縦に書くものとか、あるいはタイ語とかヒンズー語みたいに、前の文字によって次の文字の形が大きく変わる筆記体みたいなものしかない文字というのもあって、我々は十分考えているだろうかと思います。鹿霈つまり標準化というのは、どういう場面で使われるかを想像力巧みに考えて作らなければいけない。グローバル、ISOとかいう美名で人の足を踏んづけて威張っているというのは最もいけないということです。ご理解いただければ幸いです。<図15>さて、「標準化の規格」についてちょっと申し上げます。規格が使いものになるためには、規格は大きすぎても使いものにならないし、小さすぎても駄目です。時期が早すぎても遅すぎても、すべて使いものになりません。標準化が必要だ必要だとおっしゃいますが、標準規格を作るというのは非常に難しいのです。それで後で説明しますが、意図されない使われ方をしてしまうことがあります。当然のことですが非常にメンテナンスが重要です。規格の上にまだ必要な取り決めをローカルにする必要があることが多いということを申し上げます。<図16>「大きすぎた例」は、ACR−NEMAのバージョン1。これは1985年発表された医用画像の伝送規格で、ISO−OSIの全7層全部の定義が、一番上は患者のデータ形式から、一番下は50ピンのコネクタまでありました。当然ながら、50ピンコネクタのネットワークというのはすぐ陳腐になってしまって、下はTCP−IP、上はACR−NEMAのバージョン1データ形式というのが横行しました。私は当時東大にいて、下位層まで50ピンでやったのですが、それを発表にアメリカに行くとみんな結局ずるいことをやっているということがよくわかりました。いい勉強になりました。ビットシリアルインタフェース。1986年検査機器から情報を取りたいということで、学会からメーカまでの大議論の結果定められたのは、データはSTXとETXでくくるということだけというものでした。データ内容も、ハンドシェイクの方法も定義はされていません。これらはすべてローカルに決めようと書いてあります。当時はデータなんかプリンタポートから取ってくれというような暴論もあった時代ですから、それよりはましだったのかもしれません。規格としてのサイズが小さすぎて、使われているといえば使われるのですが、有用ではない。いうか、標準化によってメリットが与えられたとはちょっと言いにくいのです。鹿霈<図18>「早すぎた例」。medixという、規格というかグループがありました。90年初期に、IEEE(電子工業協会)のワーキンググループで、医療情報全体のデータ形式を構造的に規定するという、アンビシャスなものをやっていました。medixは去年解散しました。当時でもDICOM、つまりACR−NEMAの新しい版は、画像検査関連で構造化にも結局成功しました。これは、データ表現形式は同じ様なものでありながら、ユースケースを画像検査に絞ったということで成功したと言えるでしょう。私もDICOMが最初にオブジェクトで構造的にやると言った時に、本当にうまくいくかなと思ったものですが、結局うまくいったので関係者及び実装した人々に頭を下げるばかりです。HL7も、次の版バージョン3は構造化するということになっています。鹿霈<図19>先ほどちょっと川真田さんも触れられた、臨床検査データ交換規約暫定版。私も里村先生も関与したのですが、MEDIS−DCで94年に定められた固定長の文字列です。当然ながら波形データは使えませんし、構造化された値、例えばマトリックス上の数値とかも記述できなくて、結構使われている施設は多いが、今は足かせになっているということを聞いています。菌培養結果や、遺伝子診断結果などが扱いにくいのです。鹿霈これで、このことで得た教訓を、先ほど川真田さんが報告なさった、HL7を採用する形で改善されたということになったのではないかと思います。これは94年だからすぐに陳腐になってしまったのであって、その5年前であれば基盤となった可能性はあるのではないかと思います。当時は波形データを送るとか、構造的な数値を送るということは、皆夢にも思わなかったのではないかと思いますので、ちょっと遅かったですね。私もちょっと陳腐だと当時主張したのですが残念です。その後、川真田さんのグループで、先ほどご紹介があったように、実装できる良いものを策定されましたので大変結構かと思います。ICDはもともとWHOの死因統計のためのコードですから、臨床的な研究とか医事の目的とかで使われますが、死なない病気の記述は少ないですし、慢性疾患の病態とか、そういう記述には全然向きません。直接の死因にはなりにくいからです。ICDがそういう病名マスタに向いていないというのはおかしく、そういう目的で使っているほうが悪いと思うべきです。ACR−NEMAのバージョン1も、実は規格書の最初に「ポイントツーポイントの規格であって、ネットワークで用いられるものではない」と書いてありましたが、そのとおり遵守したら機器とネットワークの間に必ずゲートウェイが要るので、PACSを求めていた世間のニーズとずれてしまい、先ほど申し上げたように下のほうは好き放題というインプリメンテーションが横行したということです。鹿霈<図21>さて、「データベース間に情報を交換する」ということはどういうことかというと、これはγ−GTP=120というデータをシステムからシステムへ送る例です。人間なら、γ−GTP=120とか書いてあれば、γがギリシャ文字であろうが、アルファベットでGAMMAと書いてあろうが読めるのですが、データベース間で情報を交換するにはコードが必要です。左側が「病理学会コード」、右側が「LOINC」というコードですね、こういうテーブルがあるとして、次にデータ文法としてはHL7を使うと決めます、それでデータ形式はDOSフォーマットのフロッピーになっています、データの転送方法はフロッピーで渡す、あるいはFTPで取りますというようなこと全部に関して双方で合意していないと、相手のデータベースの中にまでデータが入りません。人間が読むことはできます。見るだけのブラウザを作るのは簡単なのですが、データベースに情報を渡すことは非常に難しいのです。<図22>「さらに必要なもの」は何かということをHL7を例にして説明します。先ほど川真田さんのご紹介にもありましたが、人名は漢字、ローマ字、全角カナ、全部使えます。ところが恥ずかしくも、半角カナしか持っていないシステムもまだあるでしょう。さあ、そのシステムが他のシステムにデータを渡すとして、どこまで歩み寄るべきかというのはその場で決めることです。これを規格で書くべきかというと、ちょっと問題があります。受け手のシステムが、その後漢字を使う気でいるシステムなのか、全角カナを主にしたいのかわかりませんので、規格にはできません。この部分を決めないと現実に実装は進みません。いうコンフォーマンスという部分を正確に把握しないと、つまりその場でさらに決めることがたくさんあるということを理解しないと、しっかりとしたシステムの接続はできません。鹿霈よくあることなのですが、規格を作る時につい、何でもできる、これも送れる、これも入る規格というものを作ってしまうのです。それは、受け手側の立場に立ったらものすごく辛いことで、システムはどんなものが来るかわからない、この範囲ならどれがくるかわからないというものに準備するというのは非常に大変なことです。私も情報系の工学部の出身ですが、一度言語のコンパイラを書いたりすると、文法に則ったものは何でも受けられるようにするというのは、ものすごく大変なことだということを経験出来て、そういう教育を受けたことはやはり重要だったなと自分でも思っています。MERIT−9という話、今回この話は全然しないのですが、この規格でMMLとHL7を組み合わせて紹介状を作ることはできます。紹介状といっても相手がどういう人かによって用いる用語や略語が当然変わります。外来の内科のお医者さんの紹介状なのか、それとも、例えば専門の脳外科病院が放射線科のCTに依頼するのかによって、全然その紹介状の内容というか、用いる用語、病態の記述などが変わってくるわけです。これも規格で書くことでありません。鹿霈ですから、どんなふうに使われるかということを意識せずに規格というのは実装しにくい、つまり規格で書かれていること以上の取り決めが必要で、それをインプリシッドにし続けると全然ノウハウは溜まらないし、移転ができません。「オブジェクト指向」の話をちょっとだけします。この話は今や流行の話で、オブジェクト指向のメリットは、オブジェクト分析によって業務が見えやすくなることや、マルチメディアに対応できるデータ構造をさまざまに取れるといったことです。<図24>お示しした資料の中に入れてあるのはDICOMのオブジェクト分析図ですが、上から見て「患者が来院」というイベントがまず作成されます。次に「来院」というイベントから「検査」というイベントが起こります。「検査」というイベントの中には「結果」というのがあって、シリーズの中には画像そのものがあってという構造です。これは、実態のDICOMの画像検査モデルです。「オブジェクト分析により業務内容が見えやすくなる」。病院によって異なる各職種の役割とか、オーダと医事間の役割分担の切り分けのことです。先ほど西山さんが主張しておられた、「あんな『何日から』などという情報をちゃんと入れてくれるんでしょうね」ということ、おっしゃるとおりだと思います。誰が入れるのでしょうか。行政というのはデータを収集するのは、何か1枚通知を出せばドンと集まると......。データを集めるコストの大変さというものをあまり理解していなくて、新しい項目を使って判定の基準にしようとすぐおっしゃるのですが、それを見ると、「えっ、このタグ、また新しく作らんといかん。あのデータベースにそういう情報を入れるところが要る」というふうにメーカは驚きます。西山さんが訴えられたことの理由の一つは、そういう情報はすぐ得られるだろうという行政の姿勢にあるのではないかという様に思います。各職種の役割というのも問題を起こします。見てきましたが、看護婦さんのやっている役割も違えば、検査技師のやっている役割も全然違います。国立大学でもこんなに違うのです。私は開業医の息子なのですが、我が家では、大病院では看護婦が入力している様なことも、兄がちゃんとキーボードを使って入れているというような状況です。ユースケースをしっかり定義しないと、これが相当施設によってバラバラということがわかってきました。オブジェクト分析すれば、それはそのまま他に移転すると絶対思わないようにしてください。鹿霈さて、「帳票ベースによる現状の移行か、新しい方法によるものか」というようなことも考えたりするわけですが、これはよくオブジェクト指向のセミナーなどでも言われるとおりです。<図26>「マルチメディアに対応できる」。これも大したことではありません。どれもがどれにでも対応できるハード構成にはできませんから、これも当然コンフォーマンスが必要になってくるわけです。プラットホームをどう考えるか、ソフト開発工数の減を取るか、ハードの適正で最適構成を考えるか、これも設計者が判断しなければならないことであり、マルチメディアを扱いますというだけではメリットは出ないわけです。<図27>「データ構造をさまざまに取れる」と言っても、親から子供が10人で、それぞれの子供が10人という病名みたいな構造だと、やはり複雑な検索をさせると組み合わせ的爆発をすぐ起こします。浜松医大で、オブジェクトデータベースで非常にインテリジェントな検索を実験しているのですが、やはりそういうことが起こってしまうのです。鹿霈こういう技術そのものは、10年前からあまり進歩しているようには思えません。いう点はちょっと寒く感じるところです。それを何とかしなければならないでしょう。申し上げますが、なぜ数値データもろくに交換できないうちに、カルテを交換しようなどという発想が起こるのか、はっきり言って私は疑問に思います。いうものの、カルテを交換するための技術の研究は必要です。その実装の実験も必要です。それが実装できると考えて、そういう前提でプロジェクトを起こすのは不思議です。あることをやろうというのが、MERIT−9と称して、MMLやHL7などを使うという発想になるわけです。紹介状を電子化しようということです。手書きとスピードを争っている間は、敵ではないというか、手書きにかなうはずがないのです。これはユーザインタフェースのことですが、内容に対する検索が可能となって初めて手書きを越えられます。患者さんが来た時に、類似症例はどういうものでというふうなことをすぐに、今までこのケースは何人来ていますが、うちではこれだけ手術して、これだけ手術せずにこうなりましたということを示し、そのためには、どの病気でどういう処置をして、どういう予後であったかという情報が検索できる形で電子化されていないと駄目なのです。これはなかなか遠いことで、すぐにできることではありません。これがエビデンスベースメディスンの目指すところです。鹿霈これをやって初めて手書きカルテを越えることができるのであって、電子化診療録のメリットがあるという様にいえるわけです。先ほどちょっと申し上げましたが、まず他人に読ませるために書かれていると思われる各種報告書、文書というのは、やはり普通のカルテ内容とは全然違います。鹿霈DICOMの構造化レポートなどという、非常に構造の良いものが出てきました。これは単に画像の報告書だけではなく、いろいろな手術の報告書の場合にも使えそうに思います。いったものをまず交換することから始めるべきだと思います。システムは普通の情報システムではないのか。普通ではないと私は思います。何が普通ではないのか。完成度が工業製品と言えるものを本当に出していますか。金を払っていませんから私も心苦しいですよ。工業製品と言えるレベルのものは、あまり見たことがありません。そもそもこの10年から15年くらい前からソフトウェアの世界で言われた、信頼性工学だの構造化プログラミングといった基本は、ちゃんと取り入れましたか?。これは私が目にしている一メーカだけではありませんが、何という労働生産性の低い仕事をされることか。部品の共有化というのは可能なのでしょうか。これを目指して、いろいろオープン化、モジュール化を進めておられるでしょう。鹿霈そもそも皆さん、ソフトで儲けたいのですか、ハードで儲けたいのですか。保守やインストールで儲けたいのか。これがわからないのです。これからハードは駄目なのだろう、ではソフトで儲けるということをどう考えるかです。保守、インストール、これらはしっかり儲けてほしいと私は思っています。その重要性を訴え続けられることは非常にいいことだと思います。この辺をもうちょっとしっかりと打ち出されることが必要ではないかと思います。鹿霈そもそも、マーケティングをしてシステムを作っていますかということを私は言いたいのです。<図30>しかし、あなた達ばかりを非難するものではありません。そもそも、システムインテグレーションというのは誰の仕事なのでしょうか。システムインテグレーションをすることこそ医療情報サイドではないのでしょうか。バイヤーのサイドではないでしょうか。システムインテグレーションが外注して価値のあることなら、やはり金を出して使うべきでしょう。他で動いているものを使うということは恥とするような考え方が、やはり医療にはあります。医療情報では減って来ていると思いますが、どうもこれは結局そのコストに対する意識のなさから来るものだと思います。「要望に一貫性があるか」。私自身も自信はありません。各メーカさんは、北の方の病院で言われることと全く拮抗することを南の方の病院で言われることがあると思います。「過去の誤ちを繰り返そうとしていないか」。先ほどちょっと申し上げた、医事の処理済みのデータから経営分析がしにくいということを、もう一回蒸し返すようなことをしていませんか、ということです。過去に決着済みというものはあるのです。この分野には、バイヤーズガイドみたいなものがありませんね。展示会等でいろいろご努力しておられるでしょうけれども、本当に素人の方がエントリーする際に助けとなる、キャンデッドなレビューというか、要するに例えばアメリカのコンシューマーズレポートの様な車のテストを実際にやってみたという様な、そういうバイヤーズガイドの様なものがこの分野にはありません。鹿霈そもそも、我々は仕様書を自分で書いているだろうかというようなことを思うと、何も先ほどの画面でメーカの皆さんを非難するばかりが問題点ではないという様に思います。第2世代の伴走者達へ最後に、我々と共に歩いて下さるメーカの若い方及びその若い方を管理する立場の皆さんに「貧乏に慣れよ」と申し上げます。これはどういう意味かというと、別に儲けるなと言っているわけではありません。医療の分野でたまに聞くような、とんでもないボロ儲けというのはもうないと思って下さいということです。あともう一つ、例えば、フィルム代の代わりに電子保存で点が付くか付かないかということを議論しているうちに、インフォメーションテクノロジーのおかげで、非常に安く画像がとりあえず見えるということが実装できるなら、そういう議論を吹っ飛ばして安く作ってしまうことができるかも知れません。この分野というのは、この技術の進歩が非常に早いのです。いう議論をしている間に、これで金をもらわなくて結構だというような勇気のあるサイト及び勇気のあるベンダーが出てくるのではないか。私どもはそれを考えて、なるべく安く画像のブラウザの様なものができればいいなと思っています。鹿霈つまり、金を付けてもらわなければ何も動かないという考え方は、必ずしも、実際に医療に貢献するに当たって前提とする必要はないのではないかということです。それは程度問題で、全然収入のないところでがんばってカスミで食っていけというわけではありません。この分野は技術革新が非常に早いので、メディアもどんどん安くなっていて、それこそ数ギガのものが非常に安くなるわけですから、点数が付く付かないといったようなレベル、またそのロビー、必ずしもこういったものに引きずられて我々がいつまでも待っている必要はないのではないかと思います。いうことを若い方に理解していただくと、私としては非常にうれしいです。「プログラム能力をつけよ」。プログラムを書いていますか。組み合わせばかりしていませんか。最近強く思うのですが、10年、15年前は、みんなプログラムを書いていました。里村先生も書いておられました。メーカの方々もスクラッチで書いておられました。今本当に書いていますか?。外注しているだけと違いますか?。組み合わせているだけと違いますか?。外注をちゃんとコントロールすることは大事です。プログラムというのは書かないと......。プログラムを書ける人というのが本当に減ってきたように思います。OSの標準化が進んで、何かディファクトスタンダードと称するものが増えたおかげで、これが起こっているように思います。非常に強い危機感を私は感じています。「医療以外の分野からも学んでください」。先ほどちょっと申し上げたように、やはり、物流から学ぶトランザクションの厳しさ、それから、接客業から学ぶ心尽くしのユーザインタフェース、そして、多分製造業から学ぶダウン時のプレッシャーなどといったことも、是非学んでいただきたい。医療だけのSEというのは、若い方々には特に潰しが効かなくなってかわいそうとまで言いたいと思います。「自社製品以外も、是非勉強してほしい」。これこそ管理者に言いたいのですが、要するに、仕事時間の2割くらいは充電の側に向けてやってほしいと思います。非常に優秀な方が、だんだんすり切れていくのをたくさん見てきましたが、見るに堪えません。SEをカットオーバーで全部派遣するというのは、来年の種モミを食べるようなことです。「自信を持って、是非我々の間違いを正してください」。いうか、我々の間違いを正すほどの自信が持てるほど勉強していただきたい。最後に、その「内容は是非報告していただきたい」。鹿霈10年くらい前は、医療情報学会もメーカの方々の発表がたくさんありました。最近、連合大会の演題数が増えてきていいのですが、どうもそういうものが減ってきたように思います。確かに私も、いろいろ怖い顔をしました。分野と共に、その技術を使ったその技術の分野で発表していただきたい。データベースを工夫したら、データベースの分野で発表していただきたい。オブジェクトを使ったら、その分野でです。何回も申し上げますが、私たちだけでものが出来るわけはなく、結局作っていただくのは皆さんなのです。さっき「貧乏に慣れよ」と言いましたが、これで撤退されてしまったら、医療情報は儲からないからどんどん引くと言われたら、困るのは結局我々になります。それは是非避けたいのです。適正な利潤はもちろん取っていただいいて結構です。それに対して、短期的な回答としては苦い薬ばかりかもしれません。私も長期展望を考えて、ここは標準化だな、まず基盤の整備だなと思って、この10年間の戦略を考えて今にきたわけです。徐々に体質を改善されて、是非利益を上げて、十分に我々に大きい顔ができるという自信のある、我々と同世代エンジニアの方々の顔を、是非私に見せてください。これが今回のお願いです。先生、本当にありがとうございました。病院情報システムの来し方、特に点数なども示していただいて非常にわかりやすく、しかも多彩な標準化論、オブジェクト指向、21世紀を目指しての今後の動向、あり方、電子カルテ、そして我々メーカへの助言、非常に示唆に富んだ、これはやはり我々メーカはそういうものを生かしながら、特に工業会、黷侭ぢ集合体としての工業会として、このお話を受けてこれからも励んでまいりたいと思っております。