とうとう米国はイラクへ戦争の火ぶたを切ってしてしまいました 。今回、戦争をやりたがっているのは石油の利権が欲しいブッシュ 大統領だけではないかという感じですが、果たしてこのツケはどん な形で回ってくるのでしょうか。今回の戦争でイラク国民の米国に 対する憎しみはさらに増しているようですし、このようなものこそ がニューヨークのビルへ旅客機によるテロ攻撃を産む最大の要因と 思います。「北風と太陽」の話を思い出しますね。
10年ほど前の湾岸戦争当時よりさらにハイテクが進み、米国はハ イテクと物量で一気にイラクを制圧するつもりだったようですが、 やや思惑がはずれたようです。しかし今朝の新聞では米英軍が国際 空港を制覇し、いよいよ首都バグラット包囲にかかったようですか ら、この4月中にはほぼ作戦終了するのかも知れません。
イラク戦争と直接関係ありませんが、大統領といえば今回の大統 領選でブッシュと争い、もう一歩のところでブッシュに座を譲った ゴア元副大統領が Apple 社の役員の一員となったのも面白いニュー スでした。ゴア副大統領といえば、あの「情報ハイウエイ」なる 言葉から日本でもあの時期をきっかけに世の中の IT 化がど んどん進みました。Apple へそしてコンピュータ業界へどのような 良い効果があるのか、楽しみです。
ハイテクが進んでもすべてが思惑道理にいかないというのは、私 がいつも経験することでもあります。昨年後半はどうもプログラミ ングに集中力がなくなってきた気がして、そろそろ私のプログラミ ング人生にもヤキが回ってきたかと思っていたのですが、開発環境 を WebObjects に変更してから、枯れかかっていた草木が水を得た ようにまた勢いよく開発を進めることができるようになりました。
うーん WebObjects は、こんな私にとってまさに起死回生のツー ルだったようです。当初の WebObjects は使用言語として Objecti ve-C が使われていましたが、最近は Java になっているのも丁度私 の開発言語シフトに同期していて（というより、たまたま私が同期 したというのが正しい）うまい具合でした。
電子カルテ NOA の一部である受付用アプリケーションの WebObj ects へのインプリメントは比較的容易で、2週間ほどで終わりまし た。受け付け業務のほとんどはデータベースを素直に扱う部分なの で、このようなアプリケーションは WebObjects を使うととても簡 単にサクっと出来上がります。当然、仕様変更も簡単です。
さていよいよ電子カルテ NOA 本体のインプリにかかることにしま した。こちらはちょっとフンドシを締め直してかからねばなりませ ん。電子カルテ WINE 時代からのきめ細かいユーザインタフェース の作り込みが WebObjects でどの程度できるのか、かなり疑問を持 っていました。しかしやってみると、これは結構いけそうです。 もちろんインタフェースとして Web browser を使うことによる制 約はかなりあるのですが、発想をかえてそれなりのインタフェース を作り上げることができそうです。
そして、電子カルテの開発を思い立った18年前にイメージしてい たものにむしろ近づける部分もあったのは、意外な成果でした。最 初イメージしていたのは、紙とペンを使った自然なイメージで、テ キストエデイター Emacs で実現した初代 WINE の持っていた良さも 復活することができました。 入力作業の面では、痒いところに手が届く Cocoa 版 NOA の域に はまだ達することができませんが、閲覧に関しては WebObjects 版 の方が快適そうです。
Cocoa アプリケーションとしての従来の NOA が持っていた階層型 メニューの機能は Web browser への表現型として基本的にはないの で、これをどう実現するか、そして果たして実現できるのかという 不安も正直あったのですが、これも実現できました。
このメニュー用コンポーネントの実現には1週間ほどかかってしま いました。最初の取り組みとして、従来の NOA でやっていたように メニュー内容を NSDictionary として保持し、テキストデータとし て DB へ保存する形式で実現してみました。しかしWebObjectsがこ んなに快適なら、メニューも DB に対応した形で保存した方が大量 のメニューを扱ってもパフォーマンスが上がり、柔軟性も増えるだ ろうと考え、まったく新たに作り直したからです。 結果としてメニュー用コンポーネントは、従来のものより使い勝 手のよいものに仕上げることができました。
このようにテキストデータとしての保存機能は没になったのです が、NSDictionary を XML に変換するという技術を、Java の機能で 実現する方法を会得したのは大きな収穫でした。今までこの部分は 自分で作った変換ツールによったのですが、今後 NOA のデータと MML との相互変換が大いに楽になるはずです。
ある程度基本的機能の実装ができたら現場で使うのが改良への一 番の早道と考えています。あとは複数の項目を一括入力するグルー プメニューと、計算サーバとの接続ができれば、現場投入が可能に なるでしょう。後者はいずれ ORCA などとの接続も考慮にいれてい るので、じっくり本腰を入れる必要がありそうです。
いよいよ明後日の3月請求分から、正式に ORCA で出力したレセプ トを基金へ提出することになりました。今回、私は一切手をださず 一般のユーザの導入と同じように、事務員がサポート業者の助言を 得ながら独力で使い始めました。 本格稼働までにはかなり苦労が必要で2，3ヶ月は使い物にならな いかも知れないと覚悟していたのですが、うちのスタッフはほんの 2週間ほどで使い方を呑み込み、1ヶ月のうちにほぼ完璧なレセプト を出力できるようになりました。
ユーザインタフェースのダサいことは相変わらずなのですが、機 能としては既存のレセコンのレベルにほぼ達したと言ってよいでし ょう。 私としては、これを電子カルテの診療費計算エンジンとして使い たいので、その接続作業が今後の大きな課題です。しかし、前述の ように現在は NOA の WebObjects 化に注力しているので、接続作業 はまだ少し先になりそうです。また今年の夏ごろには ORCA のjava 化の話しもあるようなので、それ待ちということもあります。