東京医科歯科大学医学部臨床検査医学
〒113 東京都文京区湯島1-5-45
published edition<Received June 2, 1989; Accepted September 17, 1989>
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 将来計画
謝辞
引用文献
2.2 問題が生じる原因
個々の事例をシステム開発の面から分析したところ、上記の問題はユーザーインターフェース部分に集中して発生していた。そしてそのほとんどが、医療情報システムのもつ特殊性を配慮せずに、従来から一般に行われている開発方法をそのまま適用していることが原因であると考えられた。
一般に行われているシステム開発は、次のような手順で進められる[8]。
(1)システム開発者が、ユーザーからのヒアリングなどによって、システムに要求されているニーズを調査する。
(2)システム開発者が、調査結果をもとにシステムに関係する要素をもれなく把握し、システム分析を行う。
(3)システム開発者が、システム分析に基づいてシステム設計を行い、設計仕様書などの文書を作成する。
(4)システム開発者が設計仕様書などの文書を提示し、ユーザーはそれによってシステムの仕様を確認のうえ承認する。
(5)システム開発者が設計仕様書に従ってアプリケーションを開発し、単体テストや結合テストを経てプログラムミスを修正する。
(6)システム開発者が、システムに関する最終的な仕様書や操作説明書を作成する。
(7)ユーザーが操作トレーニングを受けて本稼働に移行する。
一方、医療情報システムには次にあげる共通の特殊性がある。
(a)医療情報システムのユーザーのなかで、医師、看護婦、臨床検査技師などの医療専門家の多くは、コンピュータに関する予備知識が乏しいので、キーボードなどの操作経験が十分ではないうえ、コンピュータに過大な期待をしやすく、開発後のシステムの仕様変更を容易なものと考えやすい。またその職業柄、自分の業務や業務に関する苦情、要望を客観的かつ正確に説明する訓練を受けておらず、その必要性も十分に認識していない。
(b)医療情報システムの対象業務は、その性格上さまざまな意志決定および例外処理を必要とするので、ユーザーはそれらをもれなく処理できるようなきめの細かい機能を、当然のこととして期待する。例えば、外来や病棟における検査、処方の選択および変更、検査業務において精度管理に不可欠な再検操作などである。
(c)医療情報システムの対象業務は、企業会計などと異なり、外来業務、病棟業務、検査業務など専門的かつ多様な業務の集まりである。しかも医療専門家の多くは、情報処理技術に関しては素人なので、自分の仕事の中で情報処理にかかわる部分を特に区別せず、日常的な言葉で大ざっぱに表現する傾向にある。そのため、システム開発の専門家は、ヒアリングにおけるユーザーの要求はもとより、本稼働後に出される苦情や要望についても、その内容を誤って理解してしまうことが多い。
(d)医師、看護婦などの医療専門家は、医療の基本である患者に接する仕事を抱えているので、医療情報システムの利用によって効率化できる業務はごく一部に過ぎない。したがって、医療情報システムを使うために多くの時間を割くことはできず、ましてその導入によって余計な手間が増えることは原則として許されない。
本稼働後にユーザーから苦情や要望が数多く出る第1の原因は、(a)、(b)および(c)から明らかなように、そもそも設計の段階でシステム開発者がシステムの満たすべき機能を完全に把握できないにもかかわらず、ユーザーとシステム開発者のどちらもが、その重大な事実に気付きにくいことである。第2の原因は、(a)および(d)の理由により、医療専門家のニーズを満たすためには、他のシステムよりもはるかに優れた操作性が必要であるにもかかわらず、従来のシステム開発方法では、システム開発者が操作性に対するユーザーのニーズを調査する手段が事実上ないということである。なぜなら、ユーザーが設計仕様書などの専門的な文書を見ても、操作性の良否は良くわからないからである。
現実には、病院情報システムの導入によって、事務処理の著しい効率化という大きなメリットが得られるので、はじめから以上のような配慮を諦めてしまい、医療現場で引き起こされる生産性の低下を、医療専門家の努力で克服させようとする圧力も強い。しかし(d)から明らかなように、導入する医療情報システムのユーザーインターフェースが医療専門家のニーズを満たさず、同じことをするのにより多くの時間がかかるようになると、患者に対する医療サービスが低下せざるを得ない。例えば事務処理の効率化に著しく貢献する発生源入力方式にしても、医療事務担当者の負担を医療現場に転嫁するという側面を本質的に含んでいるので、医療専門家の負担をできるだけ軽減し、合わせて他のメリットを還元しなければ、わざわざ高いコストをかけて医療サービスの低下を招いただけという結果になりかねない。
3.2 システム設計における指針
システム開発の専門家が、ユーザーインターフェース機能の重要性を十分に認識し、積極的に性能の向上を図る。現在ではさまざまな方面からユーザーインターフェースの検討がなされており[6]、次のような性能向上の方法が実用化されている[7]。
(1)頻繁に用いる機能ほど実行に必要な操作を少なくする。
(2)操作するときに覚えていなければならないことを最小限に絞る。例えば、操作に必要な情報を常に表示する、操作が行われたらその反応を直ちに表示に反映する、操作方法を規格化し、対象の選択とそれに対する指示の反復だけにする、などの原則を設ける。
(3)コンピュータの事情によってユーザーが受ける操作上の制限を最小限に絞る。例えば、できるだけ「モード」を用いないようにする。
(4)コマンド入力による従来の言語的インターフェースを廃し、高分解能グラフィクス、マウス、タッチスクリーンなどを活用した視覚的インターフェースを採用する。この方法は、すでに一般的に用いられている道具、例えばプッシュボタン、チェック欄、スライド式つまみ、ノートのページなどの概念を模倣することにより、ユーザーがコンピュータに独特の専門的概念や操作法を覚えなくて済むという特長がある。また、アイコン、プルダウンメニュー、マルチウインドウなどの手段を用いれば、より直達的な操作が可能になる。
3.3 システムの性能評価における指針
システムの開発自体が膨大な作業量になる場合には、開発後に改めてシステムの性能評価を行うことが徹底せず、改善を要する点がなおざりにされてしまうことが多い。特に、ユーザーインターフェースの性能を評価する方法は、現在のところほとんど確立されていない。これでは開発方法の優劣が瞹昧になってしまうので、次の項目を指標にして科学的な評価を試みる[6]。
(1)使い方を覚えるのに必要な時間
(2)1度覚えた操作法を忘れずにいられる期間
(3)ある機能を実行するのに必要な時間
(4)誤操作の発生率
(5)ユーザーの満足度
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)では反転表示されている測定値が修正の対象となり、キーボードから入力した値が同じ場所に直ちに上書きされるようにし、誤操作が起こりにくいようにした。
(b)
(c)
(d)
(e)
(f)
(g)
(h)
ユーザーである測定担当者には大変好評で、定量的な比較は困難であるにしても、機能の充足度、使い方を覚えるのに必要な時間、一度覚えた操作法を忘れずにいられる期間、誤操作の発生率、満足度などの点について、今回業者が設計したシステムより優れているだけでなく、従来から使用しているどのオンラインシステムよりもはるかに優れており、要求を十分に満たしていると評価された。ただし、従来のオンラインシステムは、ホストコンピュータに用意されている1種類のアプリケーションを共用するように規格化されていたが、今回我々が開発した規格外のアプリケーションを組み込んだために、システム全体の運営や管理が繁雑になり、ユーザーにとっては操作法の統一を著しく欠く結果となった。
なお、比較のために、一般的な方法を用いて開発された従来のオンラインシステムの画面例を示す。Fig. 3(a)はメニュー画面であるが、いずれの機能についても、使用頻度や使用順序に関係なく階層化されたメニューから、対応する番号を選ばなくてはならない。Fig. 3(b)はデータ確認修正画面であるが、修正するデータの表示位置に関係なく、最下行に修正内容が表示されるので、入力の確認がしにくい。一度に表示されるデータ数も不十分であり、画面の広さを無駄にしている。
(b) data editor
4.7 結論
以上のように、我々の指針はオンラインシステムの操作性と性能の向上および開発期間の短縮という著明な効果をもたらした。なお、今回報告した事例の成功に促され、その後も2例の開発を試みたが、やはり期待通りの効果が得られている。その中の1例として、別の業者と協同開発したシステムの画面例をFig. 4に示す。命令の入力にマウスオペレーションを採用し、ほとんどの機能は、マウスを操作して矢印型のカーソルを選択肢の表示位置に移動させ、マウスのボタンを押すという操作だけで実行できるようにした。実際の画面はカラー表示され、美しく非常に見やすい。