わーくすてーしょんのあるくらし (30)
1989-06 大橋克洋
< 1989.05 HyperCard と Emacs | 1989.07 WS をめぐるイベント（日本UNIXユーザ会） >
先月号で、Ｅｍａｃｓ上に電子カルテを作り始めた話を書いたが、その後事 情により急遽本腰を入れて実用化せざるを得ないことになった。
外来診療でメインに使っていたＵＸ－３００が５月末に、ついに完全にダウ ンしてしまったのである。そもそも、このマシーンでＵＮＩＸを勉強し、Ｃを 勉強して６年間使ってきた。 修理すればまだ使えるとは思うのだが来月再リース契約を更新するかどうか という時期でもあり、この辺でＵＸ－３００にはご勇退ねがって、いよいよメ インの業務もＳＵＮへ移行することに決めた。
ＵＸ－３００も今となってはＳｙｓｔｅｍ ＩＩＩであり、何より困るのは 当時のＨＤの性能によるのだろうがスピードがメチャ遅いのである。ＵＮＩＸ のコマンドを入れてもレスポンスが返ってくるのにいらいらしてしまうし、コ ンパイルもベラボーに時間がかかる。当時はかなり大容量と思っていたＨＤも たった３０Ｍと、今ではパソコン以下となってしまった。
しかし、このマシーンも６年間２４時間の間まったくと言ってよいほど電源 を落とさず、こき使ってきたが殆ど故障もなく本当によく働いてくれた。 大体の業務は既にＳＵＮへ移行していたのだが、妊婦さんの経過観察のプロ グラムだとか、診療費の計算業務などがまだＵＸ－３００で動いていた。
○ 機械化を無視した健康保険診療費の算定方式
診療費計算業務のＳＵＮへの移行が最後になったのは、これが最もややこし い業務だからである。というのも、元はと言えば健康保険の算定方式のせいで、 これは機械化を全く無視したアルゴリズムになっている。 一定法則による処理であれば、機械化は極めて簡単だが、健康保険診療費の 算定方式は例外のかたまりである。
算定基準を読んでみるとよくわかるが、思いつきでつぎはぎしたような例外 が、ありとあらゆるところに散りばめられ、しかもそれらに全くといって一貫 性がなく、整理されていない。 これに費やされる医療機関ならびに、それを審査する健康保険基金でのマン パワーすなわち人件費が医療費の中に占める割合はかなりのものになるはずで ある。
何故このような無駄をするのか私には全く理解できないのだが、聞いたとこ ろによると、その理由はお役人と健康保険基金のお偉いさん達のメンツを含め た事情によるらしい。よくある話ではあるが、国民の総医療費が高騰している という記事を読むたびに、どうしてこのような無駄を指摘しないのか、何とか ならないものかとつくづく思う。 今や人件費ほど高いものはないから、これをスッキリするだけで総医療費は かなり低下するはずである。月末は一般の開業医にとってはそれこそ徹夜もの の現状なのである。
更に始末の悪いことには、これが一年か二年に一回位改訂される。 診療費計算専用機をレセプト発行コンピューターすなわち「レセコン」と称 するが、多くのレセコンはコボルあたりで書かれているから、レセコン屋さん は診療報酬算定式の改訂があると一ケ月位は徹夜になるらしい。
このようなアプリケーションでは、算定式はアプリケーションの内部に持た せるべきでなく、外部ファイルにしておいて、改訂時はここを書き直すように するべきである。 算定式の記述部分は人間が読んでそのまま理解できるようなドキュメント性 を持たせたファイルとしておけば何かと便利ではないかと考えている。
ちょっと前までハードウエア上の制約から、記憶容量は極力きりつめなけれ ばならず、人間が理解できるよりも機械に理解できることを優先せざるを得な かったのでこのようなことは到底無理だったが、今や記憶領域はジャブジャブ 使ってでも人間に理解できる形に持つ方が絶対に正しいと思う。 従って診療費計算のようなケッタイなものはドーンと大記憶のメモリーにもっ てきて、とにかく力仕事でやってしまうのが良かろう。おそらくＰｒｏｌｏｇ あたりに向いたアプリケーションではないかと思われる。
話は元にもどるが、ＵＸ－３００では自分の診療に関係する部分だけを姑息 的に処理していた。どうせＳＵＮに移植するなら根本的に作りなおそうと思い 伸び伸びになっていた訳である。
なまじ日常の作業をコンピュータ化してしまうと一旦それがダウンした時は 大変である。何の前ぶれもなく、或る朝、仕事を始めようとしたらＵＸ－３０ ０がプッツンしていて、それから数日はまさに火を吹く思いで外来診療を行う ことになった。 今までコンピュータが処理していたので事務員は算定の仕方がよくわからな い。一人診療を終えるごとに私が薬価表とにらめっこしながら、このややこし い計算を電卓片手にやるというありさまである。
今度は嫌おうなしにＳＵＮに診療費の計算業務を載せなければならなくなっ た。これをＣで書くとなると、やっつけの間に合わせでも１週間以上はかかる。 そこで、ちょうど開発を始めていたＥｍａｃｓ上の電子カルテに診療費計算も 組み込むことにした。こうすれば、従来の診療費の計算だけでなく、診療した 所見なども含めて一貫処理することが出来る。すなわち本当の電子カルテとい う訳である。
とりかかってみると、これは大正解だった。従来Ｃで大変な時間をかけてデ バッグを繰り返し、構築していたものが、ｌｉｓｐで書くと本当にちょちょい のちょいで出来てしまう。
とりあえず最低限の診療費計算部分が２、３日で稼働するようになった。そ れから約半月ちょっとを経た現在では、処方箋の発行だとか色々な台帳管理へ のリンクも出来上がり、いよいよ電子化のメリットを発揮しつつある。 従来使っていた自分の日程表や住所録なども、診療環境の中から直接扱える ので大変便利である。
こうなると、ちょっとしたアプリケーションはＣで書く気がしなくなってき た。Ｃではハードウエアに直結した部分は勿論、かなり低レベルの動作まで常 に頭の中に入れてプログラムを書かなければならないが、Ｅｍａｃｓののｌｉ ｓｐではこういった「しもじものこと」は知らなくていい。
ただ「ああやれ」、「こうやれ」とブラックボックス化されたモジュールに 命令を与えてやれば、「しもじものこと」は勝手に面倒みてくれるから、ラク チン、ラクチンということになる。ｌｉｓｐという言語の特性によるところも 大きいが、それに加えてその利点を十分発揮できるように作られたＥｍａｃｓ の出来の良さには本当に感激してしまう。
このあたりは先月も書いたように、ＨｙｐｅｒＣａｒｄの言語「Ｈｙｐｅｒ Ｔａｌｋ」でも同じで、少なくも稼働させて大体のアウトラインがフィックス するまで、アプリケーション開発には絶対にこのようなものを使うべきだとつ くづく思う。
現在使っている電子カルテシステムは実用化の域に入ったとはいえ、まだま だ未熟なシステムだが、これと同じものをＣで書くとしたら、下手をすると１ 年近くかかるのではないかと思われる。おそらくＳｍａｌｌＴａｌｋなどを使 えば、この作業行程は更に短縮できるのではなかろうか。 いつの日かＮｅＸＴのようなマシーンの上でオブジェクト指向のプログラミ ングを書く時が来よう。
< 1989.05 HyperCard と Emacs | 1989.07 WS をめぐるイベント（日本UNIXユーザ会） >