プログラマとユーザーの仁義なき戦い

わが研修病院にも電子カルテが導入されてはや3週間。
未だ、医師・看護師をはじめスタッフの間にもまだまだ混乱はある。

電子カルテは紙カルテに勝てるのか

結論から言えば、現時点では少なくともわが病院では「No」だ。紙カルテは構造は単純だが「全てを時系列順に同一面に配置する」ということに、長い時間をかけて究極にチューンアップされている。そのため（もちろん医師側の慣れもあるだろうが）例え入退院を繰り返し厚さが数センチに及ぶ分厚いカルテの患者さんでも、数分でかなりの情報を仕入れることが出来る。紙カルテは基本的にプラットホームが無い。いわば、完全自己カスタムな情報帳なのだ。自分のお作法を守っていれば一つのローカルルールの適応で全ての情報が引き出せる。

現場を知らない人間の作るプログラムの不完全さ

一方、電子カルテはもちろん病院勤務の現役医師からの提案を基に作られて入るのだが、UI自体はプログラマの裁量によるものだ。所謂「SOAP方式」（患者さんの抱える様々な問題点を挙げ、それについて「Subjective：患者さんが主観的に同感じているのか」「Objective：医師が客観的に患者さんを見てどうなのか」「Assessment：SとOを踏まえてどのような評価をするか」「Plan：評価を踏まえ、今後はどのような方針にするのか」）で経過記録を記載するだけならば問題は無い。＜S＞、＜O＞、＜A＞、＜P＞と書かれたテンプレートがあるだけで、他は全くの自由帳だからだ。記載するのは＜S＞と＜O＞だけでもいいし、＜O＞と＜A＞と＜P＞でもよい。問題なのは、今まで紙カルテで行われてきた医師-看護師-コメディカルの繋がりに関わる部分である。このインターフェースがあまりにも弱い。「オーダーさえ飛べばいい」「制限時間さえ守ればいい」「規定量さえ守ればいい」……実際に日常診療がどのように行われるかを見学したとはいいがたいシステムの数々が、そこに繰り広げられる。

分類の不透明さと統一感の無さが、使いにくさに拍車をかける

明らかにWindowsというのはGUIに向かない。DOSやExplorerの概念自体が、GUIにマッチしにくい。物事は必ずしもツリー構造のみで分類されるものではないし、それはかつての生物学が形而上学として発展しかけた後に挫折したこととよく似ている。属、科、目……それだけでは分類しきれないのだ。それはまたはてなのタグ付けが証明している。全てのはてブやはてなダイアリーがタグひとつで管理できている人は居るだろうか？そういう人はかなりまれなんじゃないかと思う。その点、Macは根本からしてGUI-likeだ。MacのGUIの強みは、なんといってもその統一感だ。folderによるツリー構造をとらない分、より直感的な分類が可能になっている。そして全体として保たれたUIによって、大方目的地にたどり着くことが出来る。それらができないプログラムは、どんなに高性能でも「使いにくい」

プログラマとユーザーの間の大いなる壁

ひとつのネットワークを完全に支配するシステムを構築するのにどれだけの苦労がかかるのか、推し量る事は出来ても具体的にはわからない自分には、プログラマの苦労はほんのひとかけらしか実感できないのだろう。そしてユーザーは文句と無理難題ばかりを言い、プログラマは苛酷な環境でそれに必死に耐える。そんな構図が、看護師さんから「先生、この指示を出してくれないと処置の受付が出来ません」といわれる度に「なにこのｸｿシステム……」と思う自分の脳内で繰り広げられる。プログラマ心、ユーザー知らず。ユーザー心、プログラマ知らず。そして、全て割を食うのは病院に駐在しているサポートデスク……なのかもしれない。自分もある程度のあいだ電子畑を歩んで来た身として、この構図は甚だ苦しい物がある。それでも、ここにそびえる大いなる壁は、今も昔も崩れない。

解決策は？

結局、お互いが「相手に何が必要か」がわからないと、この問題は決着しない。ユーザーが「現行のシステムではプログラマに何が出来て何が出来ないのか」がわからないと無理難題を押し付けることになるし、プログラマが「ユーザーが実際にどのようにシステムを運用するか」を知らないと、てんでバラバラに作った個々のプログラムを寄せ集めてひとつのシステムとしてしまう。しかし、この作業をプログラマやユーザーに求めるのはあまりにも酷だ。お互い、目の前の仕事で手一杯なのに、わざわざ歩み寄るために別の分野にまで手を出す余裕は無いだろう。これから先はシステムの総設計者として、両者の架け橋となる人財、いわばネゴシエーターたる存在の登場が待ち遠しい。そのような人財を配置した会社は、必ずや業績を上昇させると思うのだがいかがなものだろうか。