1989.06 日常診療に電子カルテ稼働す

わーくすてーしょんのあるくらし (30)

1989-06 大橋克洋

< 1989.05 HyperCard と Emacs | 1989.07 WS をめぐるイベント（日本UNIXユーザ会） >

先月号で、Ｅｍａｃｓ上に電子カルテを作り始めた話を書いたが、その後事情により急遽本腰を入れて実用化せざるを得ないことになった。

○ ＵＸ－３００ついにダウン

外来診療でメインに使っていたＵＸ－３００が５月末に、ついに完全にダウンしてしまったのである。そもそも、このマシーンでＵＮＩＸを勉強し、Ｃを勉強して６年間使ってきた。修理すればまだ使えるとは思うのだが来月再リース契約を更新するかどうかという時期でもあり、この辺でＵＸ－３００にはご勇退ねがって、いよいよメインの業務もＳＵＮへ移行することに決めた。

ＵＸ－３００も今となってはＳｙｓｔｅｍＩＩＩであり、何より困るのは当時のＨＤの性能によるのだろうがスピードがメチャ遅いのである。ＵＮＩＸのコマンドを入れてもレスポンスが返ってくるのにいらいらしてしまうし、コンパイルもベラボーに時間がかかる。当時はかなり大容量と思っていたＨＤもたった３０Ｍと、今ではパソコン以下となってしまった。

しかし、このマシーンも６年間２４時間の間まったくと言ってよいほど電源を落とさず、こき使ってきたが殆ど故障もなく本当によく働いてくれた。大体の業務は既にＳＵＮへ移行していたのだが、妊婦さんの経過観察のプログラムだとか、診療費の計算業務などがまだＵＸ－３００で動いていた。

○ 機械化を無視した健康保険診療費の算定方式

診療費計算業務のＳＵＮへの移行が最後になったのは、これが最もややこしい業務だからである。というのも、元はと言えば健康保険の算定方式のせいで、これは機械化を全く無視したアルゴリズムになっている。一定法則による処理であれば、機械化は極めて簡単だが、健康保険診療費の算定方式は例外のかたまりである。

算定基準を読んでみるとよくわかるが、思いつきでつぎはぎしたような例外が、ありとあらゆるところに散りばめられ、しかもそれらに全くといって一貫性がなく、整理されていない。これに費やされる医療機関ならびに、それを審査する健康保険基金でのマンパワーすなわち人件費が医療費の中に占める割合はかなりのものになるはずである。

何故このような無駄をするのか私には全く理解できないのだが、聞いたところによると、その理由はお役人と健康保険基金のお偉いさん達のメンツを含めた事情によるらしい。よくある話ではあるが、国民の総医療費が高騰しているという記事を読むたびに、どうしてこのような無駄を指摘しないのか、何とかならないものかとつくづく思う。今や人件費ほど高いものはないから、これをスッキリするだけで総医療費はかなり低下するはずである。月末は一般の開業医にとってはそれこそ徹夜ものの現状なのである。

更に始末の悪いことには、これが一年か二年に一回位改訂される。診療費計算専用機をレセプト発行コンピューターすなわち「レセコン」と称するが、多くのレセコンはコボルあたりで書かれているから、レセコン屋さんは診療報酬算定式の改訂があると一ケ月位は徹夜になるらしい。

○ 可変部分はプログラムの外に

このようなアプリケーションでは、算定式はアプリケーションの内部に持たせるべきでなく、外部ファイルにしておいて、改訂時はここを書き直すようにするべきである。算定式の記述部分は人間が読んでそのまま理解できるようなドキュメント性を持たせたファイルとしておけば何かと便利ではないかと考えている。

ちょっと前までハードウエア上の制約から、記憶容量は極力きりつめなければならず、人間が理解できるよりも機械に理解できることを優先せざるを得なかったのでこのようなことは到底無理だったが、今や記憶領域はジャブジャブ使ってでも人間に理解できる形に持つ方が絶対に正しいと思う。従って診療費計算のようなケッタイなものはドーンと大記憶のメモリーにもってきて、とにかく力仕事でやってしまうのが良かろう。おそらくＰｒｏｌｏｇあたりに向いたアプリケーションではないかと思われる。

話は元にもどるが、ＵＸ－３００では自分の診療に関係する部分だけを姑息的に処理していた。どうせＳＵＮに移植するなら根本的に作りなおそうと思い伸び伸びになっていた訳である。

なまじ日常の作業をコンピュータ化してしまうと一旦それがダウンした時は大変である。何の前ぶれもなく、或る朝、仕事を始めようとしたらＵＸ－３００がプッツンしていて、それから数日はまさに火を吹く思いで外来診療を行うことになった。今までコンピュータが処理していたので事務員は算定の仕方がよくわからない。一人診療を終えるごとに私が薬価表とにらめっこしながら、このややこしい計算を電卓片手にやるというありさまである。

○ 開発時間を大幅にショートカット

今度は嫌おうなしにＳＵＮに診療費の計算業務を載せなければならなくなった。これをＣで書くとなると、やっつけの間に合わせでも１週間以上はかかる。そこで、ちょうど開発を始めていたＥｍａｃｓ上の電子カルテに診療費計算も組み込むことにした。こうすれば、従来の診療費の計算だけでなく、診療した所見なども含めて一貫処理することが出来る。すなわち本当の電子カルテという訳である。

とりかかってみると、これは大正解だった。従来Ｃで大変な時間をかけてデバッグを繰り返し、構築していたものが、ｌｉｓｐで書くと本当にちょちょいのちょいで出来てしまう。

とりあえず最低限の診療費計算部分が２、３日で稼働するようになった。それから約半月ちょっとを経た現在では、処方箋の発行だとか色々な台帳管理へのリンクも出来上がり、いよいよ電子化のメリットを発揮しつつある。従来使っていた自分の日程表や住所録なども、診療環境の中から直接扱えるので大変便利である。

こうなると、ちょっとしたアプリケーションはＣで書く気がしなくなってきた。Ｃではハードウエアに直結した部分は勿論、かなり低レベルの動作まで常に頭の中に入れてプログラムを書かなければならないが、Ｅｍａｃｓののｌｉｓｐではこういった「しもじものこと」は知らなくていい。

ただ「ああやれ」、「こうやれ」とブラックボックス化されたモジュールに命令を与えてやれば、「しもじものこと」は勝手に面倒みてくれるから、ラクチン、ラクチンということになる。ｌｉｓｐという言語の特性によるところも大きいが、それに加えてその利点を十分発揮できるように作られたＥｍａｃｓの出来の良さには本当に感激してしまう。

○ これからの開発環境

このあたりは先月も書いたように、ＨｙｐｅｒＣａｒｄの言語「ＨｙｐｅｒＴａｌｋ」でも同じで、少なくも稼働させて大体のアウトラインがフィックスするまで、アプリケーション開発には絶対にこのようなものを使うべきだとつくづく思う。

現在使っている電子カルテシステムは実用化の域に入ったとはいえ、まだまだ未熟なシステムだが、これと同じものをＣで書くとしたら、下手をすると１年近くかかるのではないかと思われる。おそらくＳｍａｌｌＴａｌｋなどを使えば、この作業行程は更に短縮できるのではなかろうか。いつの日かＮｅＸＴのようなマシーンの上でオブジェクト指向のプログラミングを書く時が来よう。

< 1989.05 HyperCard と Emacs | 1989.07 WS をめぐるイベント（日本UNIXユーザ会） >