『使えない電子カルテはどうしてできてしまうのか』の最終回です。既に1,2回目をご覧になっている方は、イントロまで飛ばし、『５．システムを作るのは誰』からお読みください。
10年以上前ですが、宮崎のシーガイヤホテルで日本看護協会の研究会が開かれ、講演したことがあります。
タイトルは『使えない電子カルテはどうしてできてしまうのか、使える電子カルテはどうすればできるのか』です。当時は黎明期のそれよりもマシになってきてはいたものの、診療科では最も検査の種類が多い眼科では、使える電子カルテは皆無でした。もちろん、使っているところはありましたが、オーダメイドではなくいわゆる出来合いのパッケージなので、帯に短したすきに長しでした。短いところは面倒な操作をし、長いところは使わないということ、要するに不具合を慣れでカバーし、使っているうちに慣れるというものです。実際、医局からローテータで来る医師は、使えるところだけ使い、機能不足はアナログでカバーして使っていると『いつの間にか慣れる』と言っていました。業者も『そのうち慣れます』が常套句でした。今日、明日の2回、講演した内容を紹介します。なお、言わんとしていることは今でも変わっていませんが！12年前の講演であることをご了解ください。
～～ イントロ ～～
電子カルテという言葉が普通に語られるようになってから、かなりの時間が経過しています。ブームが去って本当の浸透が始まると言われていますが、厚生労働省が掲げる普及率には遠くおよびません。習熟容易性、費用対効果など、幾つかの要因が考えられますが、電子カルテに限らず、パッケージ化された医療機関向けシステムが提供する機能、情報、および操作性が、現場の作業実態を反映していないことが最たる要因ではないかと考えらます。
お仕着せのパッケージ以外に選択肢はないのでしょうか？自主開発はできない？それより前に、今の仕事の仕方に無理無駄はないのか？どの様な機能が必要なのかを洗い出したか？など、システム導入に際し、解決すべき有形無形の問題が山積していることを理解しなければなりません。その状況を踏まえ、ベンダ（システムを開発する会社）の言うことを鵜呑みしたり、経営陣の鶴の一声で導入を決めてしまう愚はさけなければならません。人間ならではの業務を除き、電子カルテを含む、院内業務を包括的に処理するシステムをパッケージではなく、自主開発するに至った開発経緯を紹介し、皆さんの参考にしたいと考え、今回の発表に至りました。
５．システムを作るのは誰
一般的に、システムを作るのは、ベンダ（システムを作る会社）の専門的な教育を受けたSE（system's engineer）が担当することになっていて、そのプロセスは以下の通りです。
①企画（システム化の必然性、費用対効果を検討したのち、おおまかな機能を考える）
②仕様（作業実態に合わせ、画面設計、操作設計、画面遷移、メッセージ、ガイドなどを作る）
③実装（実際にプログラムを書く作業）
④テスト（仕様通りに出来上がっているかのチェック）
⑤運用（システムを使い始める）
⑥エンハンス（必要に応じて、機能の追加・変更）
このうち、①が最も重要であり、次に重要なのは②ですが、これらの作業を情報システムの素人である病院職員ができるか？という疑問や躊躇があるのは当然です。ベンダは『我々プロに任せなさい』と言い、一般的には彼らに任せることになります。 しかし、任せっきりにした結果が
のようになっているのはなぜかを考える必要があります。ベンダ任せにできなければどうしたらいいのでしょう。自らやればよいというのが、私の過去やってきた結論です。ただし、③の実装は具体的にプログラムを書く作業であり、付け焼き刃で臨むのは危険と判断し、餅は餅屋（ベンダ）に任せることにしてきました。④のテストは自ら作った❝どういう機能が必要なのか＝仕様❞なので、期待した結果が得られるかをチェックすることは問題なくでき、実際に各部門の担当者が自分が決めた仕様通りに動くかをチェックをしました。
⑤、⑥は自ら作った仕様通りに運用し、法改正、患者要望などの条件の変化を反映して適宜エンハンス（機能強化）する仕様を決め、ベンダに作ってもらうだけなので、問題ありません。この様に考えれば、病院主導でのスクラッチ開発はそれほど難しくはないということで、現場を育てて開発するという、今風で言えば内製化によるシステム開発を志向しました。
肝心の仕様ですがその重要な仕様を作るにはどの様な知識、経験が必要なのかを考えてみると、おおよそ以下の通りです。
①業務知識（当該業務のみならず、関連する業務を含む作業内容、方法、手順など）
②聞き出す能力（どの様な機能が必要かを観察し、適宜聞き出す）
③資料作成能力（聞き出した事実と問題点を整理し、仕様書に纏める）
④説明能力（纏めたものを分りやすく説明する）
⑤調整能力（異なる意見要望が出てきた場合の調整、経営層の意向反映など）
このうち、基本となる能力は、①の業務知識と②の業務内容を聞き出す能力ですが、現場が担当すれば、①も②も不要となり、残るは③、④、⑤です。これらは、いわゆる基本リテラシに属しますが、時間をかけてプロジェクトメンバとなった現場の看護師、薬剤師、栄養士、検査員などのスタッフ教育して実戦投入しました。彼らは、プロジェクトメンバではない他のスタッフを教えるようにし、病院全体のスキルアップを図りました。メンバには、時々理解度を把握するためにテストを行い、丁寧なフォローをするようにしました。（赤ペン先生と呼ばれていました）
また、プロジェクトメンバは部門毎に教え合い、意見交換し、情報を共有することで、プロジェクトメンバのスキルの幅と深さを広げることも行いました。
６．結論
昔、食品メーカのコマーシャルで、❝私作る人、私食べる人❞という表現が、婦人団体に糾弾されたことがあります。理由は、夫婦の役割を固定化し、主婦に負荷を押しつけるものであるとのことでした。目くじらを立てるほどのことかと思ったことがありましたが、その是非はともかく、ベンダが作り（パッケージを提供し）、顧客が使うという関係が固定化していることと似ていると感じました。本来、ベンダはより広く深く、現場の状況を観察し、顧客は現状と改善して欲しいことを説明し、相互に協力し合い、効果を実感できるシステムを整備しなければなりません。ただし、顧客が発注者であることを誇示したり、ベンダはぺこぺこするという図式では、優れたシステムをできないことを、双方共に理解する必要があります。ぺこぺこしている裏で、評価能力の少ない顧客を手玉に取るベンダもいるので注意を要します。
以上、3回に亘って役割を固定化せず、双方の得意とするところを活かす方法として、自前のスクラッチ開発という手段もあることを紹介しました。時間はかかりますが、教育されたスキルの高い人材が育ち、業務の整理整頓ができ、組織の雰囲気も高揚するという、有形無形の財産が得られるという大きなメリットは見逃せないと思います。
※質問はosugisama@gmail.comにどうぞ。
※リブログを除き、本ブログの無断転載、流用を禁じます。