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