[-> Archives of Dr. mn's Research Works]

原著:医療情報学 / Japanese Journal of Medical Informatics 10(1), 1990: 3-14


医療情報システムのユーザーインターフェース

― ユーザーフレンドリーな病院情報システムの構築を目指して ―

西堀眞弘  椎名晋一

東京医科歯科大学医学部臨床検査医学
〒113 東京都文京区湯島1-5-45

Developing the Ideal User Interface
for
the Medical Information System

- An Approach toward User-Friendly Hospital Information Systems -

Masahiro NISHIBORI Shin-ichi SHIINA
Department of Laboratory Medicine, Tokyo Medical and Dental University, Medical School
1-5-45, Yushima, Bunkyo-ku, Tokyo 113, Japan

published edition<Received June 2, 1989; Accepted September 17, 1989>


最近多くの施設で発生源入力方式の病院情報システムが構築されているが、医師や看護婦はシステムの利用に困難を感じていることが多く、導入当初の医療現場ではむしろ生産性が低下していることが多い。このような問題が発生する原因は、医療情報システムのユーザーはコンピュータに不慣れなうえ、システムを使用するための時間的余裕が殆どないので、そのユーザーインターフェースには他のシステムよりはるかに高い性能が要求されるにもかかわらず、実際にはそれが全く満たされていないためである。そこで我々は、この問題を解決し、ユーザーフレンドリーなシステムを開発するため、入念なシステム分析とユーザーインターフェース部分のプロトタイピングを柱とした開発指針を考案した。そしてそれを同じ問題を抱えている検査部システムに適用してみた結果、操作性と性能の向上および開発期間の短縮という著明な効果が得られた。
(キーワード:ユーザーインターフェース、医療情報システム、病院情報システム、システム開発、プロトタイプ)

Although the hospital information systems developed in Japan have greatly reduced medical administration tasks, medical staff using such systems to input or retrieve data indispensable for their work often have difficulty learning and using these systems to the detriment of productivity. The cause of this problem is suggested to be the inadequacy of the user interface for these systems, which is of much more importance than in other information systems because many users know little about computer systems and have little time to learn and to use them. To solve this problem, a new method for developing user-friendly computer systems is reported. Its essential feature is an intensive system analysis based on sufficient evidence from users who were shown many versions of prototypes. This method was applied to the development of on-line computer systems used by medical staff, and resulted in a decrease of difficulty in using the systems, an improvement in the performance of the systems, and a decrease in the time needed for developing the systems.
(Keywords: user interface, medical information, hospital information system, development, prototype)


Contents

1 はじめに
2 問題点の分析
 2.1 医療情報システムに生じている問題点
 2.2 問題が生じる原因
3 優れたユーザーインターフェースの開発指針
 3.1 ユーザーニーズのヒアリングにおける指針
 3.2 システム設計における指針
 3.3 システムの性能評価における指針
4 検査部システムへの開発指針の適用
 4.1 検査部システムとオンラインシステムの概要
 4.2 オンラインシステムの独自開発に至った経緯
 4.3 開発作業の概要
 4.4 システム分析
 4.5 システム設計
 4.6 結果
  4.6.1 開発作業
  4.6.2 開発されたシステムの評価
 4.7 結論
5 考察
6 将来計画
 謝辞
 引用文献


1 はじめに

 最近多くの施設で発生源入力方式の病院情報システムが構築されつつあり、医療事務の省力化、人為的ミスの減少あるいは患者の待ち時間の減少などの点では成功している場合が多い。しかし、各々のシステムのユーザーインターフェースの機能や操作性に注目すると、医師や看護婦をはじめとする医療専門家のニーズが十分には満たされておらず、医療現場では依然として根強い不満が残っていることが多い[1-5]。
 このような状態のままでは、医療の質および生産性の真の向上は得られないうえに、今後実用化が期待される電子カルテシステム、診断支援システム、医学知識データベースシステムなどの医療情報システムの普及にとって、大きな障害となる可能性が高い。本学にも医学部付属病院を含めたトータルシステムの開発計画があり、切実な問題となっている。ところが、優れたユーザーインターフェースを備えたシステムを開発する方法は、現在のところほとんど確立されていない。
 我々の運営する検査部システムも、基本的にはこれと同じ問題を抱えており、年々検査部業務の効率化が迫られるにつれ、解決方法が強く求められている。そこで我々は、6年間にわたる検査部システムの運営や改良から得た知識と経験をもとに、コンピュータの操作性を改善するためのさまざまなアイデア[6-7]を取り入れ、優れたユーザーインターフェースを実現するための開発指針を独自に考案した。この論文ではその開発指針の内容と、それを検査部のオンラインシステムの開発に適用し、実際に得られた効果について報告する。


2 問題点の分析

2.1 医療情報システムに生じている問題点
 さまざまな病院情報システムの開発事例や、我々の検査部システムにおける経験を整理すると、それらに生じている問題点は次のようまとめられる。なお、ここでいうユーザーとは、システムを直接利用する医師、看護婦、臨床検査技師などの医療専門家を意味する。
(1)十分時間をかけて仕様を打ち合わせたにもかかわらず、本稼働後にユーザーから「同じことをするのにかえって手間が増えた」、「予め説明のなかった手間を押し付けられた」、「期待通りに便利にはならなかった」、「実際に使ってみたら予想外の機能が必要になった」などの苦情や要望が数多く出される。著しい場合には、そのためにシステムが利用できず、完成してもなかなか本稼働に移れないことがある。
(2)ユーザーから出された苦情や要望が、なかなか取り入れられない。取り入れられても、著しく時間がかかる。
(3)そして多くの苦情や要望がうまく解決されないまま、結局ユーザーにそのしわよせが押し付けられてしまう。

2.2 問題が生じる原因
 個々の事例をシステム開発の面から分析したところ、上記の問題はユーザーインターフェース部分に集中して発生していた。そしてそのほとんどが、医療情報システムのもつ特殊性を配慮せずに、従来から一般に行われている開発方法をそのまま適用していることが原因であると考えられた。
 一般に行われているシステム開発は、次のような手順で進められる[8]。
(1)システム開発者が、ユーザーからのヒアリングなどによって、システムに要求されているニーズを調査する。
(2)システム開発者が、調査結果をもとにシステムに関係する要素をもれなく把握し、システム分析を行う。
(3)システム開発者が、システム分析に基づいてシステム設計を行い、設計仕様書などの文書を作成する。
(4)システム開発者が設計仕様書などの文書を提示し、ユーザーはそれによってシステムの仕様を確認のうえ承認する。
(5)システム開発者が設計仕様書に従ってアプリケーションを開発し、単体テストや結合テストを経てプログラムミスを修正する。
(6)システム開発者が、システムに関する最終的な仕様書や操作説明書を作成する。
(7)ユーザーが操作トレーニングを受けて本稼働に移行する。
 一方、医療情報システムには次にあげる共通の特殊性がある。
(a)医療情報システムのユーザーのなかで、医師、看護婦、臨床検査技師などの医療専門家の多くは、コンピュータに関する予備知識が乏しいので、キーボードなどの操作経験が十分ではないうえ、コンピュータに過大な期待をしやすく、開発後のシステムの仕様変更を容易なものと考えやすい。またその職業柄、自分の業務や業務に関する苦情、要望を客観的かつ正確に説明する訓練を受けておらず、その必要性も十分に認識していない。
(b)医療情報システムの対象業務は、その性格上さまざまな意志決定および例外処理を必要とするので、ユーザーはそれらをもれなく処理できるようなきめの細かい機能を、当然のこととして期待する。例えば、外来や病棟における検査、処方の選択および変更、検査業務において精度管理に不可欠な再検操作などである。
(c)医療情報システムの対象業務は、企業会計などと異なり、外来業務、病棟業務、検査業務など専門的かつ多様な業務の集まりである。しかも医療専門家の多くは、情報処理技術に関しては素人なので、自分の仕事の中で情報処理にかかわる部分を特に区別せず、日常的な言葉で大ざっぱに表現する傾向にある。そのため、システム開発の専門家は、ヒアリングにおけるユーザーの要求はもとより、本稼働後に出される苦情や要望についても、その内容を誤って理解してしまうことが多い。
(d)医師、看護婦などの医療専門家は、医療の基本である患者に接する仕事を抱えているので、医療情報システムの利用によって効率化できる業務はごく一部に過ぎない。したがって、医療情報システムを使うために多くの時間を割くことはできず、ましてその導入によって余計な手間が増えることは原則として許されない。
 本稼働後にユーザーから苦情や要望が数多く出る第1の原因は、(a)、(b)および(c)から明らかなように、そもそも設計の段階でシステム開発者がシステムの満たすべき機能を完全に把握できないにもかかわらず、ユーザーとシステム開発者のどちらもが、その重大な事実に気付きにくいことである。第2の原因は、(a)および(d)の理由により、医療専門家のニーズを満たすためには、他のシステムよりもはるかに優れた操作性が必要であるにもかかわらず、従来のシステム開発方法では、システム開発者が操作性に対するユーザーのニーズを調査する手段が事実上ないということである。なぜなら、ユーザーが設計仕様書などの専門的な文書を見ても、操作性の良否は良くわからないからである。
 現実には、病院情報システムの導入によって、事務処理の著しい効率化という大きなメリットが得られるので、はじめから以上のような配慮を諦めてしまい、医療現場で引き起こされる生産性の低下を、医療専門家の努力で克服させようとする圧力も強い。しかし(d)から明らかなように、導入する医療情報システムのユーザーインターフェースが医療専門家のニーズを満たさず、同じことをするのにより多くの時間がかかるようになると、患者に対する医療サービスが低下せざるを得ない。例えば事務処理の効率化に著しく貢献する発生源入力方式にしても、医療事務担当者の負担を医療現場に転嫁するという側面を本質的に含んでいるので、医療専門家の負担をできるだけ軽減し、合わせて他のメリットを還元しなければ、わざわざ高いコストをかけて医療サービスの低下を招いただけという結果になりかねない。


3 優れたユーザーインターフェース開発の指針

3.1 ユーザーニーズのヒアリングにおける指針
(1)システム開発の専門家が、システムの対象業務について前もって十分に理解しておき、そのうえでニーズを調査する。あるいは、システムの対象業務の性格上それが困難な場合には、ユーザーとシステム開発の専門家との間に立つ組織を設け、その構成員が両者の業務内容を十分に理解し、両者の正確なコミュニケーションを図る役割を果たしていく。
(2)システム開発の専門家が、おおよそのシステム分析を終えた段階で、ユーザーインターフェース部分のプロトタイプを作成し、それをユーザーに操作してもらうことによって、要求仕様に関する両者の誤解を検出し、プロトタイプを修正することによって解消していく。

3.2 システム設計における指針
 システム開発の専門家が、ユーザーインターフェース機能の重要性を十分に認識し、積極的に性能の向上を図る。現在ではさまざまな方面からユーザーインターフェースの検討がなされており[6]、次のような性能向上の方法が実用化されている[7]。
(1)頻繁に用いる機能ほど実行に必要な操作を少なくする。
(2)操作するときに覚えていなければならないことを最小限に絞る。例えば、操作に必要な情報を常に表示する、操作が行われたらその反応を直ちに表示に反映する、操作方法を規格化し、対象の選択とそれに対する指示の反復だけにする、などの原則を設ける。
(3)コンピュータの事情によってユーザーが受ける操作上の制限を最小限に絞る。例えば、できるだけ「モード」を用いないようにする。
(4)コマンド入力による従来の言語的インターフェースを廃し、高分解能グラフィクス、マウス、タッチスクリーンなどを活用した視覚的インターフェースを採用する。この方法は、すでに一般的に用いられている道具、例えばプッシュボタン、チェック欄、スライド式つまみ、ノートのページなどの概念を模倣することにより、ユーザーがコンピュータに独特の専門的概念や操作法を覚えなくて済むという特長がある。また、アイコン、プルダウンメニュー、マルチウインドウなどの手段を用いれば、より直達的な操作が可能になる。

3.3 システムの性能評価における指針
 システムの開発自体が膨大な作業量になる場合には、開発後に改めてシステムの性能評価を行うことが徹底せず、改善を要する点がなおざりにされてしまうことが多い。特に、ユーザーインターフェースの性能を評価する方法は、現在のところほとんど確立されていない。これでは開発方法の優劣が瞹昧になってしまうので、次の項目を指標にして科学的な評価を試みる[6]。
(1)使い方を覚えるのに必要な時間
(2)1度覚えた操作法を忘れずにいられる期間
(3)ある機能を実行するのに必要な時間
(4)誤操作の発生率
(5)ユーザーの満足度


4 検査部システムへの開発指針の適用

4.1 検査部システムとオンラインシステムの概要(Fig. 1)
 我々が検査業務の迅速化・省力化・効率化などを目的として現在運営している検査部システムは、検査依頼情報の収集、ワークシートの作成、自動分析装置や用手法によって測定されたデータの収集、精度管理計算、報告書の作成、各種統計表の作成などの機能を果たしている。この検査部システムのなかで、各々の分析装置とホストコンピュータを結び付け、測定データを自動的に収集するシステムをオンラインシステムと称する。オンラインシステムにはインテリジェントターミナル(図中ITC)が備えられており、それぞれの分析装置の担当者は、そのCRTとキーボードあるいはマウスなどの入力装置を用いてオンラインシステムを操作する。

Fig. 1 Overview of the laboratory information system.

4.2 オンラインシステムの独自開発に至った経緯
 我々は、1987年3月に新規導入した自動分析装置に用いるオンラインシステムの開発に当たり、システム開発の専門業者に対し、我々の考案した指針の適用を要望した。しかし、工数の不確定化などを理由に満足できる回答が得られなかったため、我々は自ら開発に着手し、考案した指針を適用してみることにした。一方、その業者には従来の方法によるシステム開発を同時に開始させ、我々と業者が別々に開発したシステムを完成後に比較し、我々の指針の効果を検証することにした。

4.3 開発作業の概要
 我々の開発作業を担当したのは、筆頭著者と検査部情報管理室所属の臨床検査技師2名である。筆頭著者は、プロジェクトリーダーとしてシステム開発技術を習得すると共に、新規に導入する自動分析装置とそれにかかわる業務内容を徹底的に調査し、システム分析およびシステム設計を行った。アプリケーション開発は、必要性の高いものから3人で分担して行い、業務に最低限必要な機能が実現された時点で、測定担当者を対象にプロトタイピングを開始した。残りのアプリケーションは、プロトタイピングと並行して開発した。ホストコンピュータの開発言語には、従来のシステムに従ってデータベース管理機能に優れたMUMPSを用い、インテリジェントターミナルの開発言語には、画面と通信の制御機能に優れたBASICを用いた。

4.4 システム分析
 我々のシステム分析の結果、今回開発したオンラインシステムに要求される機能は次の通りであった。
(1)分析装置から送られる測定値を取り込み、一時的なバックアップファイルを作成し、適切なフォーマットに変換したうえでホストコンピュータの報告用ファイルに格納すること。
(2)測定担当者が測定値をひとつひとつ確認し、正常に測定されなかった検体や測定可能域をはずれた検体など、再測定を必要とする検体を検出し、再測定の結果に従って測定値の修正ができること。
 また、このオンラインシステムのユーザーインターフェースに要求される性能は次の通りであった。
(a)測定担当者の誤操作を減らし、作業効率を高くするためには、操作するときに覚えていなければならないことを最小限に絞り、操作方法をできるだけ簡単にすることが望ましい。
(b)測定担当者が測定値を確認または修正するときには、著しく短いレスポンスタイムが要求される。

4.5 システム設計
 プロトタイピングの結果、我々は4.4の(a)を満たすため、ユーザーインターフェース部分に次のような工夫を組み込んだ。
(1)コマンドメニューの階層構造を、使用頻度の高い機能ほど少ない操作で実行できるように組み立てた。
(2)コマンドメニューの選択方法を、各オプションの先頭に数字を表示してユーザーにその数字を選ばせるのではなく、オプションのなかの1つだけを反転表示にして選択されていることを示すようにし、ユーザーは矢印キーを用いて反転表示されるオプションを順番に代えることにより、実行したいオプションを直接選べるようにした。
(3)どの画面にも、そのときに実行できる機能は何か、どうすればそれが実行できるか、あるいはその機能を実行することによって起こりうる問題は何かなどの情報を適切なタイミングで表示するようにした。
(4)測定値の確認や修正を行う画面には、見にくくならない範囲でできるだけ多くのデータを表示し、表示画面を切り替える手間を減らした。
(5)測定値の修正を行う画面において、修正される測定値の選択方法を、各測定値の先頭に数字を表示し、ユーザーにその数字を選ばせるのではなく、測定値のなかの1つだけを反転表示にして選択されていることを示し、ユーザーは矢印キーを用いて反転表示される測定値を順番に代えることにより、修正したい測定値を直接的に選べるようにした。
(6)測定値の修正を行う画面において、ユーザーがキーボードから入力した測定値を、修正される測定値とは別の場所に表示するのではなく、同じ場所に重ねて表示することにより、直接的に測定値の修正ができるようにした。
 また我々は、4.4の(b)を満たすため、測定値の表示や修正に用いる1次データファイルを、インテリジェントターミナルのフレキシブルディスクに置くのではなく、ホストコンピュータのハードディスクに置くことにした。これにより、データベースの検索などのデータ処理をすべてホストコンピュータのCPUに行わせ、その結果表示に必要な情報だけをインテリジェントターミナルに転送することができるため、端末機能のエミュレートによって増す処理時間を差し引いても、レスポンスタイムの著しい改善が期待できる。

4.6 結果
4.6.1 開発作業
 我々のシステム開発作業は、ドキュメンテーションを除き、各々の通常業務に支障をきたすことなく3か月以内に完了した。またドキュメンテーションに必要な作業量は予想外に多かったが、各人が分担して必要性の高いものから暇を見て作成したので、通常業務に支障をきたすことはなかった。一方業者による開発作業は、設計仕様書の作成だけで4か月を費やしたため、その時点で中止させた。この業者が今回の作業に配分した人数が正確に分からないので、定量的な比較はできないが、我々の作業の方がはるかに効率的であった。

4.6.2 開発されたシステムの評価
 今回我々が開発したオンラインシステムの画面例をFig. 2(a)〜(h)に示す。(a)、(b)、(c)および(d)の順に画面が移行する。使用頻度に応じて機能を集約し、使用頻度の高い画面ほど下の階層に配置してあり、画面間の移行を要する頻度を最小限にした。そして選択する対象がメニュー、日付、項目および修正したい測定値のいずれの場合でも、反転表示させて選択肢を選ぶという操作方法を一貫させた。また(e)、(f)、(g)および(h)の例に示すように、さまざまな状況に対し、適切なタイミングで親切なメッセージを表示し、誤操作が起こりにくいようにした。(c)では反転表示されている測定値が修正の対象となり、キーボードから入力した値が同じ場所に直ちに上書きされるようにし、誤操作が起こりにくいようにした。

Fig. 2 User interface of the on-line system developed by our method.
(a)

(b)

(c)

(d)

(e)

(f)

(g)

(h)

 ユーザーである測定担当者には大変好評で、定量的な比較は困難であるにしても、機能の充足度、使い方を覚えるのに必要な時間、一度覚えた操作法を忘れずにいられる期間、誤操作の発生率、満足度などの点について、今回業者が設計したシステムより優れているだけでなく、従来から使用しているどのオンラインシステムよりもはるかに優れており、要求を十分に満たしていると評価された。ただし、従来のオンラインシステムは、ホストコンピュータに用意されている1種類のアプリケーションを共用するように規格化されていたが、今回我々が開発した規格外のアプリケーションを組み込んだために、システム全体の運営や管理が繁雑になり、ユーザーにとっては操作法の統一を著しく欠く結果となった。
 なお、比較のために、一般的な方法を用いて開発された従来のオンラインシステムの画面例を示す。Fig. 3(a)はメニュー画面であるが、いずれの機能についても、使用頻度や使用順序に関係なく階層化されたメニューから、対応する番号を選ばなくてはならない。Fig. 3(b)はデータ確認修正画面であるが、修正するデータの表示位置に関係なく、最下行に修正内容が表示されるので、入力の確認がしにくい。一度に表示されるデータ数も不十分であり、画面の広さを無駄にしている。

Fig. 3 User interface of the on-line system developed by a conventional method.
(a) main menu

(b) data editor

4.7 結論
 以上のように、我々の指針はオンラインシステムの操作性と性能の向上および開発期間の短縮という著明な効果をもたらした。なお、今回報告した事例の成功に促され、その後も2例の開発を試みたが、やはり期待通りの効果が得られている。その中の1例として、別の業者と協同開発したシステムの画面例をFig. 4に示す。命令の入力にマウスオペレーションを採用し、ほとんどの機能は、マウスを操作して矢印型のカーソルを選択肢の表示位置に移動させ、マウスのボタンを押すという操作だけで実行できるようにした。実際の画面はカラー表示され、美しく非常に見やすい。

Fig. 4 Mouse-driven user interface of the on-line system developed by our method.


5 考察

 我々がシステム開発にプロトタイピング手法を採用したのは、次のような効果が期待できるからである。
(1)システム全体からみると、ユーザーインターフェースはその一要素でしかないが、システムのユーザーにとっては、ユーザーインターフェースはシステムのすべてを意味する。したがって、ユーザーインターフェースだけをいわゆる「はりぼて」の形で再現したプロトタイプを操作すれば、ユーザーは実際のシステムに接するのと同じ体験ができる。このため、ユーザーからの要求もれが少なくなり、例外処理および意志決定入力機能をきめ細かく正確に吸収することができる。
(2)ユーザーと開発担当者は、全く異なる予備知識を持って打ち合わせに望むことが多いので、ユーザーインターフェース機能を文書で表現すると、両者の間にさまざまな誤解が生じやすい。そこでプロトタイプによって機能を具現化すれば、そのような誤解をはるかに少なくすることができる。
(3)ユーザーが設計仕様書などの専門的な文書を読んで操作性の良否を判断するのは困難であるが、プロトタイプを操作すれば容易に判断できる。したがって開発担当者は、ヒアリングの時点でユーザーの求めている操作性、例えば操作手順やレスポンスタイムを正確に調査できる。 (4)プロトタイプとして作成するアプリケーションを実際のシステムに組み込めるように設計しておけば、仕様打ち合わせとユーザーインターフェース部分のアプリケーション開発およびデバッグを同時に進められるので、開発期間を著しく短縮できる。
 ところが、システム開発業者は工数の不確定化に伴うコスト増を恐れ、プロトタイピング手法を敬遠して従来の開発方法に固執することが多い。しかし実際には、多くの病院情報システムが続出するユーザーの苦情や要望に対応するため、修正作業を延々と続けている。一方我々の経験では、プロトタイピング手法を採用すれば、本稼働後に出るバグやユーザーから苦情が著しく減少するので、それらに対処するための修正作業がほとんど不要である。システムが完成した後で機能を修正するためには、アプリケーションの修正だけでなく、修正したアプリケーションの単体テスト、結合テストおよびシステム全体のテストをやり直すために、膨大な工数が必要になる。それに比べると、プロトタイプをユーザーの要求に合わせて改善していく工数の方がはるかに少なくて済むので、我々の開発方法は工数が確定できないとは言え、むしろ開発コストの軽減をもたらすことが期待できる。


6 将来計画

 我々は、今までに得られた成果をさらに発展させ、検査部システムだけではなく、本学の病院情報システムをはじめさまざまな医療情報システムの開発にこの指針を適用し、有効性を検証していきたいと考えている。そのためには、次の点が今後の検討課題である。
(1)我々の指針は、ユーザーが臨床検査技師の場合には有効であることが実証されたが、他のユーザー、例えば医師や看護婦の場合についても検証する必要がある。
(2)個々のユーザーの特殊性にきめ細かく対応して性能向上を図ろうとすると、規格化されたシステムの中に規格外の要素が入り込んでしまい、その数が増すにつれシステムの運営や管理が繁雑になる。この問題を解消するためには、あらかじめ幅広い機能が用意された、より高いレベルでの規格化が必要であると考えられる。
(3)我々の開発指針を病院情報システムなどの巨大なシステムに適用するためには、アプリケーションの開発、修正、テストランが容易に反復でき、高分解能グラフィクス、マウス、タッチスクリーンなどの制御が容易なだけでなく、データベースの検索や編集のスピードが十分に速く、セキュリティの保持が容易な開発環境が必要となる。しかし、これらの条件をすべて満たすような開発環境はまだ一般的には提供されていない。今回用いたMUMPSも、インタープリタ型言語なので実行速度に限界があること、高分解能グラフィクスやマウスの制御が不可能なことなどの欠点がある。したがって、実際に我々の開発指針を適用するためには、現在利用できるハードウエアと開発言語をうまく組み合わせて、理想的な開発環境を作り上げることから始めなければならない。


謝辞

 オンラインシステムの開発に参画していただいた東京医科歯科大学医学部付属病院検査部の萩原三千男技官と草野隆美技官のご尽力に感謝いたします。
 マウスオペレーションを採用したオンラインシステムの開発に協力していただいたスタットコンピュータ(株)の松崎博至氏のご尽力に感謝いたします。


引用文献

1.
加藤五十六、他:静岡県立総合病院における病院情報システム、第6回医療情報学連合大会論文集、265-268(1986).
2.
宇都由美子、他:看護職員の受け入れ態度によるシステムの評価、第6回医療情報学連合大会論文集、489-492(1986).
3.
大宮東生、他:北里大学東病院情報トータルシステムの現状と評価、第7回医療情報学連合大会論文集、7-10(1987).
4.
安藤裕、他:処方、検体検査、診療予約オーダーシステムの特長と評価、第8回医療情報学連合大会論文集、41-44(1988).
5.
酒井順哉、他:オーダリングシステム導入4年間経過後のシステム利用に関する意識調査、第8回医療情報学連合大会論文集、849-852(1988).
6.
Ben Shneiderman:ユーザーインターフェースの設計、日経BP社(1987).
7.
Apple Computer, Inc.:Inside Macintosh Volume I, Addison-Wesley Publishing Company, Inc.、27-70(1986).
8.
日野弘、他:情報システムの計画・設計実務, 日経BP社(1987).

[-> Archives of Dr. mn's Research Works]