院内の安全管理委員を務めていることもあり、さまざまなインシデントについて検討する機会がある。電子化の有無は別として、最近ではほとんどの病院でインシデントレポートを実施している。種別ごとのインシデント発生頻度の傾向は病院間、あるいは経年的にもあまり変化がない。集計数の3分の1が「投薬に関するもの」、3分の1が「転倒・転落」や「チューブ管理」など、3分の1が「その他」といった割合だろう。

　インシデントは「明らかなうっかりミス」から「どう注意していても防ぎようがない事象」まで、実にさまざまだ。また、患者や医療従事者の「人的要因」、設備などの「環境要因」、電子カルテの「システム要因」などが関わり合って発生する。特に、電子カルテの操作ミスによるインシデントには「操作性の問題」が少なからず関係しているように思われる。

　加藤先生が「誤りは人の常」の章で述べられているように常識的にやってはならないことは、システム側でできないように制御されるべきだと思う。しかし、そのようなリスクの多くが現場の運用でカバーされているのが実情である。こうしたベンダー（システム）側の都合について、加藤先生はエッセイで以下のように指摘している。

何か具合の悪い事が起きてしまったら「不注意だった当事者が悪い」と責任を免れる時の合言葉が「運用でカバーする」なのだ。本当に常に、当事者が悪いのだろうか。

　例えば、ある電子カルテで消炎鎮痛剤の「ロキソプロフェン」が何錠まで処方できるのかを確認してみた。すると、1日当たりの最大処方量は「99,999錠」、最大服用日数は「999日分」まで入力が可能だった。しかし、「100,000錠」と入力すると「使用量の値が不正です」という警告が、「1,000日分」とすると「入力は1～999までの数値です」という警告が表示された。

　同様に、睡眠導入薬の「ハルシオン」を入力してみたところ、1回の処方量は「99,999錠」が上限であったが、投与法として「1日1回：寝る前」を選択すると「1回警告量超過、要注意　ハルシオン錠0.25mg」という“何とも穏やかな”警告メッセージが表示された。また、日数については「30日」を超える処方入力では「薬剤マスター最大投与日数超過　ハルシオン錠0.25mg ＝ 30」という“ちょっとロボット的”な警告メッセージが表示された。

　もちろん、このような処方を意図的に入力する医師はいないし、仮に処方されたとしても薬局からの疑義照会があり、処方ミスが発覚することは目に見えているので患者の皆さんには安心してもらいたい。だが、それでも疑問は残る。そもそも99,999錠は可で、100,000錠は不可となる根拠は一体どこにあるのだろうか。

　「実際に使う人がどのように使いたいのか」というユーザーの気持ちになって設計されていない医療システムには、「ユーザーによる運用でカバー」せざるを得ないリスクが多数存在していることをまず念頭に置いておきたい。こうした環境下で起こった医療ミスの全ての原因が、ミスを犯した人間の不注意だと言い切れるのだろうか？

　仮に、処方された錠数を自動的に自分が飲まされるという仕様であったとしたら、システムを開発するシステムエンジニア（SE）はこのようなシステムを設計しただろうか？　やはり他人ごとなのだと言わざるを得ない。幸い、私が知っているSEには、ユーザーの視点でシステム設計を考え、そのユーザーの喜ぶ顔を見たいという熱意のみなぎるユーザーメイドの心を持つ方もいる。このようなSEの台頭に期待したい。

インシデントレポートのインシデントレポートが必要？

　私は、2007年に開催された「第27回 医療情報学連合大会」のワークショップ「現況の医療情報システムに対して医療者作成のソフトウェアが訴えるもの」において、「市販汎用データベースソフトによるヒヤリハット報告システム～独自開発のメリットとデメリット～」と題した発表を行ったことがある。このワークショップでは、ヒヤリハット報告のオンライン化を目的として、データベースアプリケーション開発ソフト「FileMaker Pro」で独自開発したシステムをベンダー製の病院情報システム（HIS）導入時にリプレースした事例を発表した。このリプレースにまつわる教訓を皆さんと共有したい。

　電子化によるさまざまな業務効率化が進められる中、当院では2005年1月、それまで紙媒体で運用していた「ヒヤリハット報告書」（インシデントレポート）の電子化計画が持ち上がった。しかし、業者に委託して導入した場合、100万円以上も費用が掛かり、また導入してもコスト回収のできない電子化事業として予算が付かないことが分かった。

　以前の勤務先では、現場の要望に応えてFileMaker Proを用いた業務支援ソリューションを作成した経験があり、このスキルを使う好機を伺っていた。既に、別の小規模なデータベースを作成する目的で購入されていたFileMaker Proのライセンスを保有していたこともあり、私はヒヤリハット報告書をデータベース化することを提案し、検討委員会で正式に承認され、FileMaker Proで開発したツールをトップダウンで使用することになった。

　ツールの開発や導入、運用までを非常に短期間でスムーズに行うことができた。患者の個人情報や報告者の個人情報などを扱うツールであるため、アクセス権についてはレコードごとに異なるアクセス権を細かく設定した。また、報告書の作成方法などの教育を簡便化するため、全レイアウト上の定位置に「？」ボタンを配置し、使用法が分からないときでもその画面で必要なマニュアルを参照できるように工夫した。それが功を奏し、運用開始からツールの使用法に関する問い合わせや入力トラブルなどはほとんど無かった。また、「転倒・転落報告」に特化した集計画面がリアルタイムに表示されるなど、転倒転落委員会の会議で使用する報告資料作成などでも好評を得ていた。

　通常であれば、このように問題なく実運用されているヒヤリハット報告システムをリプレースする必要性はないように思われる。ところが電子カルテの導入に伴い、その調達予算で包括される病院情報システムの一部にヒヤリハット報告システムが含まれることになり、必然的にリプレースが決定した。

　当時は「ユーザーメイド＝信頼度が低い」といった評価が多勢を占めており、医療従事者によるユーザーメイドシステムは肩身の狭い思いをしている時代だったため、やむを得ない決定であろう。しばらくするとベンダー製システムの導入が決定し、運用が開始された。しかし、導入直後からさまざまな問題が出てきた。

• 「転倒・転落」の入力操作の流れが前後して使いづらくなった
• 入力画面に関係のない項目も多く含まれるレイアウトとなり、画面をスクロールしながら該当項目を探さなければならなくなった
• 特定の患者が対象ではないトラブル管理ができない
• 画面操作や入力に関するヘルプ機能が提供されない

　これらの使い勝手については、仕様書には表しにくい部分であったのだろう。しかし、導入から2カ月後、看過できない問題が発覚した。実は新システムを運用開始後、急に転倒・転落事例の割合が減っていた。当時、転倒転落委員会が転倒・転落を防止するためにさまざまな取り組みを行っており、それらの効果が出てきているのかと喜ばしく考えていた。ところが、実報告数がさほど減っている印象もないため、その集計数に疑問を持ち調査を行った。

　すると、転倒・転落の集計結果画面に正確な件数が表示されていないことが分かった。このシステムでは「転倒・転落」の集計対象として登録するためには、利用者はベンダーが指定する箇所に都度チェックを入れる仕様を取っていた。インシデントの種類が「転倒・転落」であっても、自動的には集計対象とならない仕組みであったのだ。

ユーザーメイドシステムで何が悪い!?

　上記のようなトラブルの場合、利用者が注意して入力すれば、確かに問題ないのかもしれない。だが、使用開始から多くの利用者がベンダーの期待通りに入力できず、集計結果が実際の数とは異なっていた。いわゆる「運用でカバー」するシステムだったのだ。ちなみにその問題はベンダーと話し合われて解決したが、その補修には数カ月の期間を要した。

　果たしてベンダー製システムはユーザーメイドのものより信頼性が高いといえるのか。決してそんなことはないと思う。一見すると何でもないように稼働しているベンダーから提供された「信頼できる」システムであっても、「入力したデータが本当に期待された通りに処理されているのか」を人任せにせず自ら確認し、疑問に思う点は迷わず分析する心を忘れてはならない。