第14回医療情報連合大会 (デモ・セッション) 抄録 Object oriented Electronic Chart オブジェクト指向で開発された「電子カルテ」 大橋 克洋 大橋産科婦人科 高橋 究 佐藤病院 Keywords : object oriented, electronic chart, server client, NEXTSTEP, network 1．はじめに 当院で電子カルテの日常外来診療での運用を始めてから5年半を経た。 最初は Sun ワークステーション上で、文字だけを扱うシステムとして稼働し ていたが、約2年前これを NEXTSTEP に移植すことにより、完全なオブジェク ト指向、絵や写真、音声なども扱えるマルチメデイア対応のシステムとなった。 最も大きな相違点は「操作性の向上」で、マウスを駆使した GUI により、初 めてのスタッフでも容易に扱え、熟練者はそれなりに便利に使えるようになっ たことである。電子カルテを使うようになってから、患者の細かいエピソード など手書きの頃よりもこまめに記述するようになった。手書きよりずっと快適 だからである。 2．システムと動作環境 2.1 ソフトウエア システムはNEXTSTEP上で動く。これはMach という UNIXコンパチOSの 上に完全なオブジェクト指向環境を載せたもので、Macintoshを開発したSteve Jobs らにより開発された。一言でいうなら UNIX の上で動く極めてパワフル な Macintosh である。 そこには InterfaceBuilder という大変効率的な GUI 開発ツールと、 処理言語として Objective-C が装備される。それは C++ よりもむしろ SmallTalk に近く、NEXTSTEP の Objective-C は C++ の文法をも解釈してく れる。 NEXTSTEP の開発環境で最もすぐれているのは、標準装備のクラス・ラ イブラリーで極めて充実しており、大変良質のソフトウエアを完全なオブジェ クト指向で生産できる。 1989年に発表された当初から、トータルなオブジェクト指向環境、完 全なマルチメデイア対応の先進的なシステムとして登場したが、昨年 NeXT 社 はハードウエアの生産をやめ、NEXTSTEP を提供するソフトウエア会社へ転身 した。現在 NEXTSTEP はIBM AT互換機上で動き、 Sun、 HP、DEC などのワー クステーションにも openStep という名称で採用され、より広いプラットフォー ム上で使えるようになりつつある。Sun の採用理由は「現状で最も運用実績の あるオブジェクト指向開発環境」ということである。 本格的な電子カルテの開発に当たり、いろいろなマシーンや OS を検 討した結果、われわれの考えるものを実現するには NEXTSTEP しかないという 結論に至った。実際にその開発・運用を経験した感想では、これは極めて正し い選択であったと考えている。ここに実現された電子カルテを他の処理系で実 現しようとすれば、その数倍の時間と労力を要することは間違いない。 2.2 ハードウエアとネットワーク構成 当院では3台のNEXTSTEPマシーンと2台の Sun、その他多数の Macintosh などをEthernet で接続したネットワーク環境で、診療所内だけで なく自宅とも結び、サーバ・クライアント・システムとして運用している(図 1)。受付には、NeXTcube が設置され、当日の受診者の受付、新患登録、会計 業務などを行う。 ドクターの机上では電子カルテが使用されている。マシーンはショッ プブランドの AT互換機で、CPUは Intel 486、Memory は48MB、 1.25GB のハー ドデスクを備え、OS は NEXTSTEP 3.2J である。 いずれ外来看護婦用にラップトップ型のものを増設予定である。 重要なファイル類は深夜の間に、病棟の WS へネットワーク経由で自 動的にバックアップされる。分散環境なので、どこかのマシーンが壊れても別 のマシーンで代替が効く。業務に使うには大切なことである。 GUI の劣る SPARCstation はデイスプレイに点灯することなく、このようにネットワーク 上のサーバとして動いている。 自宅で患者さんからの電話を受け、NeXT station turbo で電子カル テを見ながら対応することができる。また診療所のコンピュータが受信した FAXを、ネットワーク越しに自宅の画面で見て返事を書き、再び診療所の FAX モデムから返送できる。 3．サーバ・クライアント・システム 「電子カルテ」はネットワーク上のクライアントとして動き、「患者 情報サーバ」「会計情報サーバ」「検査情報サーバ」が裏でそれを支援する。 クライアントが立ち上がった時、ネットワーク上のどこかにいるサーバを捜し てメッセージを交わし自動的に接続を完了してくれるので、サーバはどこにい ても構わない。高速なネットワークさえ引かれていれば、サーバが地球の裏側 にあっても同じである(図2)。 電子カルテの内容そのものを管理する「患者サーバ」は、もっとも大 量の情報を処理しなければならないので、現在はひとりの患者にひとつのサー バを立てるようにしている。常時多数のカルテが飛びかう大学病院のような施 設で、ひとつのサーバに多数のカルテを受け持たせることは、大きな負荷の一 点集中によりスループットが極端に落ちてしまう。メインフレームによる従来 のシステムではこれを力任せに行っていたが、ネットワークと WS による水平 な分散環境ではこのようなことをする必要はない。 サーバを分散して複数の WS 上で稼働させれば、負荷の分散と平行処 理ができ、スループットが上がり、トラブルの危険性も減少する。しかし、あ まり多数のサーバを立てることはネットワーク上のトラフィックを増やすので、 大規模施設などではいくつかのサーバをまとめる必要もあろう。 患者情報などデータをサーバに持たせるメリットは沢山ある。 ・ネットワークを介し、複数のユーザが同じ情報を共有できる。 ・ひとつの情報を複数で同時に利用する場合の管理がしやすい。 ・サーバとクライアントを別の CPU で動かすことにより平行処理ができる。 ・データとアプリケーションを切り離せるので、メインテナンスしやすい。 ・色々な部署でのデータの分散管理ができる。 要するに、分散処理による負荷減少・平行処理と、それにともなう 良質のサービスが可能になることであろう。 4．オブジェクト指向によるデータ管理 従来からの観念によれば、データを扱おうとする時、一定のフォーマッ トにあてはめて管理しようとしがちである。しかし、電子カルテを自然に使い こなそうとすると、一定のフォーマットにはあてはまらない情報が出てくるこ とに気付く。本来、自然に存在するデータはまったく無秩序に存在するが、そ れを一律に枠の中へに当てはめようとするための矛盾である。 無秩序に存在するデータを、必要に応じ自分の使いやすい関連づけを して扱えれば良い。関連づけには、臨機応変に対応できる自由度が必要で、こ のようなものを実現するのが「オブジェクト指向型データベース (OODBMS)」 である。 4.1 データ自身が知識を持つ 理想的な OODBMS では、ひとつひとつのデータ・オブジェクトが、自 分に与えられたメッセージに自分はどのように反応をするかを知っており、関 連するオブジェクト逹とメッセージを交わすことができる。 例えば何かを検索したい時、OODBMS では従来のデータベースのよう に、検索システム自身がデータをスキャンし処理する必要はない。親データ・ オブジェクトに検索条件を与えてやれば、親は子データ・オブジェクト逹を指 揮して検索し、結果を返してくれる。オブジェクトは自分の持つ知識をもとに、 関連するオブジェクト逹と協力しながら検索作業を遂行するのである。 しかし現状では全てのデータに知識を持たせるところまでは行ってい ない。オブジェクト指向環境ではデータや知識などの全てをメモリー上に展開 するので、巨大な記憶容量を消費する仕事は実用的でないからである。 UNIX などの OS では仮想記憶により、ハードウエアの許す限り無限 に近いメモリー容量を提供できるが、ある程度のメモリーを使ってしまうと頻 繁に swap (メモリー上の情報を一旦ハードデイスク上に退避する)が起こるよ うになり、実際の効率は大きく低下する。 これらの問題はハードウエアの価格低下やCPU速度・容量などのめざ ましい進歩から、いずれ時間が解決してくれるが、とりあえず現状では従来か らのデータ管理様式と OODBMS との折衷案をとるのが良いと考えている。 4.2 データ同士の自由な結合 現在、電子カルテ内のデータは(図3)のようなデータ同士のリンクで 構成されている。ひとつひとつのデータはオブジェクトであり、自分自身が保 持するデータ内容とともに自分の子データへのポインターを持っている。子デー タがどこに存在しようと構わないが、そのポインターをたぐって子データを得 ることができる。いずれ Internet 上のデータの接続も可能にしたい。 非定型のデータが出現した場合でも、そのデータへポインターを繋ぐ だけで自由にデータを接続できる(図3の臨時データ)。データは文字情報だけ とは限らない、絵でも写真でも音声でも何でもよい。場合によっては複数のファ イルをしまったフォルダーや、アプリケーションかも知れない。 ポインターの先はネットワークの彼方のサーバの中にあってもよいが、 あまり多用するとネットワークのオーバーヘッドでレスポンスが落ちる。また、 ネットワーク越しのリンクの多用は、情報の欠落の可能性を増すリスクもある。 5 電子カルテ機能の概要 (図4)は NEXTSTEP における実際の画面である。当院のネットワーク は Internet へ IP 接続しているので、電子カルテで診療をしながら Internet 上の情報を利用することもできる。 5.1 画面構成 電子カルテ上部はページを少しずつずらしたように見える。マウスで その一行を選ぶとグレー表示され、そのページが手前に開く。与えた検索キー にマッチしたページだけを捜し出して、リストアップすることもできる。 5.2 フリーフォーマットとマルチメデイア対応 限られた画面を有効に使うため、記入欄の上下幅は、記入行数の増減 に連動して自動的に伸縮する。記入欄の項目は、ユーザによりあらかじめ自由 に設定できる。このような柔軟性は医療に使うには重要なことである。カルテ は文字のパターン、サイズ、色を変えたり、絵や写真、音声などを貼り付けら れる完全なマルチメデイア対応である。 5.3 メニューによるテンプレート入力 よく使われるものについてはメニューとして表示される。例えば主訴 の欄でメニューから「不正出血」を選ぶと、主訴欄に不正出血の文字が入力さ れ、同時に所見・治療欄にも不正出血に関連してよく使われる内容が転記され る。これを編集したり削除することにより、大きな省力化をはかった。自分の 診療パターンを随時電子カルテに記憶させることができ、学習機能をもってい て使用頻度の高いものから順にメニューに表示される。 5.4 オーダエントリーと検査結果の自動転記 「検査」リストから検査名を選択すると、その検査伝票がカルテに貼 り付き、検査依頼がネットワーク経由で「検査サーバ」に送られる。後日カル テを開いた時、カルテオブジェクトは「検査サーバ」に問い合わせ、検査台帳 に結果が記入されていれば、それをカルテに自動挿入する。 5.5 処方箋発行 メニューから選択し作成された処方は市販の処方箋へ印刷され、同時 に電子カルテへ転記される。ネットワークによる薬局への転送も可能である。 5.6 定型文書の自動作成 診断書や紹介状など好みの書式を登録しておけば、カルテの日付や氏 名などを埋め込んで、定型文書がワンタッチで自動作成される。出来上がった ものをさらに編集することも自由である。忙しい外来診療中の文書作成には極 めて重宝する。 5.7 関連情報の提供による診療支援 薬品や疾病など関連情報を参照できる。カラーの図譜なども表示でき、 患者説明にも大変有用である。将来は、CD-ROM 化された書物や、インターネッ トによるリアルタイムな情報なども参照できるようにしたい。 5.8 診療記述の解析による診療費自動計算 「治療欄」に記入された内容を、ワンタッチで自動解析して診療費を 算出、結果は最終行に挿入される。レセコンとはまったく逆の、ドクター側か らの発想である。 5.9 会計業務 「診療終了」ボタンを押すと、「会計サーバ」を介して会計事務にあ る画面(図5)に診療費が転送され、直ちに会計ができる。NEXTSTEP では distributed object という機能が提供され、サーバ・クライアント機能を何 の苦もなく構築できる。 5.10 アプリケーション間通信によるサービス NEXTSTEP にはサービス機能というものがある。あるアプリケーショ ンの中で文字列を選択しておき、サービスを依頼すると別のアプリケーション がその文字列オブジェクトに一定の処理をし返送してくれるものである。例え ば電子カルテ中の最終月経をマウスで選択し、妊娠歴アプリケーションにサー ビスを依頼すると、現在の妊娠週数と分娩予定日を算出して電子カルテへ返し てくれる。電卓アプリで四則計算した結果を返すこともできる。これを使えば、 電子カルテ自体を拡張せずにいろいろな機能を付加することができる。 6 おわりに 大学のように大きな予算と多くの優秀なスタッフに恵まれない個人の 力で、どこまで理想的なものが追求できるかが目的のひとつであるが、現状で はほぼ考えたものが達成されたと考えている。 電子カルテのプラットフォームとなった NEXTSTEP は、医療における アプリケーション開発だけでなく、エンドユーザにとっても極めてすぐれた操 作環境を提供する。比較的安価な IBM AT 互換機や Sun などの本格的 WS を 多数接続したネットワークによる水平分散システムは、従来のメインフレーム による垂直集中システムに比べ、比較的安価で極めて柔軟な使いやすいシステ ムを提供する。 ネットワークを駆使した今後の医療情報処理のより広い普及のため、 多くの施設で追試が行われる事を期待するものである。柔軟な OODBMS の考え 方で作られたものであれば、セキュリテイーなどに支障のない限り、今後ネッ トワークを介し、いろいろな施設で情報を共有することが可能になる。そのよ うなステップに備え、ネットワーク・ワイドな互換性を考慮した電子カルテの 構造を考える事は重要であろう。そのためには基本データを拘束する条件はな るべく少なく、シンプルで柔軟な構造にすることが肝要と考える。