病院（医療機関）の効率的運用、マネジメントに必要なシステムを整備するための取り組み杉浦技術士事務所杉浦和史１．はじめにシステムを導入すると、そのシステムがカバーする業務が効率化され、人が減る、あるいは余った要員を忙しい部門に再配置できるという期待がある。昭和 40 年代後半から 50 年代後半にかけた大型汎用コンピュータを使った黎明期のシステムでは確かにそのような目に見える量的な効果があった。それは、大量／一括／繰り返しという、コンピュータが最も得意とし、人間には不得意な単調な作業を繰り返す業務がシステム化の対象だったからだといえる。しかし、今までの仕事の仕方を見直さないまま、電子的に処理するという単純な発想で効果が出る範囲の業務は、製造業などの業種では、既にやり尽くされていると思われる。一方、医療機関には依然として残っているのが現状である。原因はさまざま考えられるが、医療業務は、人対人の対面作業が基本であり、大量一括処理の対象にならない場合が多いことが第一に挙げられる。次に、業務を整理整頓し、これをシステムに載せることによって組織の効率的運用、マネジメントに寄与させようという発想が他業種よりは希薄なことも考えられる。しかし、いまや医療機関といえども、システムなしの経営は考えられない状況にあることは論を待たず、その様な認識に至っている病院関係者は増えている。では、このシステムをどの様に整備していけばよいのか。筆者が関与したある病院では、点眼、処置など、人間ならではの業務を除く、院内すべての業務をシステム化の対象にし、病院の効率的運用、マネジメントに寄与するシステムを自主開発中である。なぜ、パッケージを採用せず、自主開発なのか、具体的にどう進めたのかなどにつき、紹介したい。２．病院向けパッケージ医事会計システム、電子カルテシステムなど病院向けのシステムはパッケージの形でベンダ（システム開発会社、SIer ともいう）から販売されており、病院では機能、導入コストなどを勘案し、適宜選択している。しかし、問題点を抱えたまま使っている場合が少なからずある。どうしてパッケージを採用しなかったのかを説明したい。（１）予備知識パッケージとは“出来合いの業務ソフトウェア”という意味で、スーツで言えばいわゆる“吊し” に相当する。スーツの吊しは、適宜選んだのち、ズボンの丈など小修正をするのが一般的で、少し待っていればできあがり、比較的安価で早く着用できる特徴がある。これに対しオーダーは、一般的に高く、着られるまでに時間を要する。パッケージは“吊し”に相当し、システム化対象業務の業務分析から始めて一から作る（スクラッチ開発）場合はオーダーに相当する。どちらがよいのか？単純に費用と時間で比較すれば前者に分があるが、着心地に相当する使い勝手という肝心な部分は、明らかに後者に軍配があがる。導入時の費用が大きく、いったん導入するとスーツのように簡単には買い換えられないシステムは、吊し（パッケージ）かオーダー（スクラッチ）かの慎重な事前検討が必要になる。電子カルテシステムのパッケージにつき、選定から稼働開始、運用、バージョンアップ・保守の導入フェーズ別の満足度推移を目にしたことがあった。パッケージが決まった段階では、満足とやや満足を併せると、５０％以上が満足と評価していた。しかし、運用してしばらく経つと、両方あわせても３０％を切るようになってくる。使い続けてバージョンアップ、保守が必要になる頃には、２０％まで下がってしまい、満足と評価するのは、わずか５％以下になるというものである。また、この頃になるとベンダ決定時にはなかった不満が増え、やや不満をあわせると４０％以上が何らかの不満を抱くようになるという。これを図にするとわかりやすいが（図１参照：次頁）、問題は、使い始めてから使いづらいことに気がつくということであり、気がついても遅いということである。 Copyright 2014 杉浦技術士事務所 All rights reserved １図１フェーズ別電子カルテ満足度推移○ C いったん導入すると、後戻りはできないので、事前に十分な検証が必要なことは既述のとおりだが、病院関係者は、一般的に評価に必要な知識経験を持ち合わせていない。導入事例を見せてもらうことも一つの方法だが、提案側は、協力的なところを紹介し、且つ、導入先も、「上手くいっている」と言わざるを得ない立場の者が説明するので、本当のところを見破れないのが実態といえる。（２）パッケージパッケージとは、該当する業務を調査し、必要な機能を洗い出し、その機能をソフトウェアで実現したものだが、できるだけ適用範囲を拡げなければならないという製品の性格的宿命がある。そのため、平均値の仕様で作らざるを得ない。結果として、帯に短しタスキに長しになり、痒いところに手が届かず、不足する部分は手作業で補い、不要な部分は使わないという、スクラッチ開発（０ベースでの開発）ではあり得ないことが起きる。その代わり、早期に導入ができ、出費も抑えられるというメリットがあると言われている。しかし、それを実感できるだろうか。前者は、パッケージの機能をそのまま使えば、メリットを感じることができるが、多かれ少なかれカスタマイズを行うのが普通である。つまり、早期とはいかない場合が多い。また、後者の出費が抑えられるという点はどうだろう。これは、パッケージの仕様を決める際、カスタマイズ可能な範囲をどこまで考えていたかで決まる。想定内であり、パラメータを変更するだけで対応可能な場合にはメリットを感じることができるかもしれない。例えば、術式の種類が追加・更新・削除できるようになっているか、新たな術式に対応するクリニカルパス、手術パスの指定が自在にできるようになっているかがこれに相当する。言われなくてもその様な構造にするのはシステム設計者の常識だが、そうなっているかをパッケージを選択する際に確認しておかなければならない。往々にして、「何ができますか」という質問と、「あれもできます、これも可能です」という会話になりがちだが、図１に示したように、 “使ってみて初めて分る使い辛さ”を事前に把握しておくためには、突っ込んだ議論が必要である。再来受付システムのデモを見たことがあるが、診察カード挿入時に表示される案内メッセージの文面の変更は、ベンダが有償で対応するという説明を受け、唖然としたことを覚えている。システム設計者は、状況に応じて病院側で自在に書き換えられるように作っておくべきだと思わなければならない。なぜなら、その要望は多いからである。このようなところまで調べておかない Copyright 2014 杉浦技術士事務所 All rights reserved ２と、安いと思っていたパッケージが運用開始後、様々な理由で出費がかさみ、高くつくことがある。その様な事例が多いことを知っておいて損はない。（３）屋上屋を重ねる全体構想があり、これに沿って順次投入されたのではなく、必要になった都度、必要になった業務をカバーする機能を屋上屋を重ねるように作ってきたのが現状のパッケージ。技術的なブレークスルーや、システムに期待されるものが質量共に大きく変化した場合には、リセット（スクラップ＆ビルド）して作り直すべきだが (図２参照)、継ぎ接ぎのバージョンアップで乗り越えてきたパッケージは多い。不具合が潜在し、運用の際に顕在化する懸念があり、避けたいところである。図２屋上屋を重ねるパッケージ○ C また、業務種類ごとにそれを得意とするベンダのパッケージを導入した場合には、狭い診察台にパッケージ対応のディスプレイが複数置かれることになる。また、異なるベンダ製のパッケージの操作性は統一されておらず、機能、情報の重複も発生し、障害発生時の対応に時間を要するなど、多くの問題を抱える懸念もある。（図３参照：次頁）図３業務毎のパッケージの寄せ集めの弊害○ C また、各システムの完成度（機能、操作性、連携、品質など）が揃っていないと、システム全体としての使い勝手は、最も低い完成度のものになってしまうことは、リービッヒの最小律、ドベネックの桶 Copyright 2014 杉浦技術士事務所 All rights reserved ３として知られている。ダムのゲートに例えると、図４のようになる。図４低いレベルに合わせられる○ C ダムの水位をシステム全体の完成度とし、放水ゲートの高さを全体システムを構成する部門システムとすると、最も完成度の低いゲートＣに合わせられてしまうことが分る。システムの中に完成度の高いものや機能があっても、低いものに合わせられ、効果が出せないことを示している。以上、パッケージの問題につき述べてきた。この結果に基づき、出回っているパッケージでは効率的運用、マネジメントに必要な機能は整備できないとして、院内業務を総合的に電子化するシステムの自主開発に踏み切った。３．院内統合情報システム（１）コンセプト医療機関向けシステムと言えば、即座に電子カルテシステムということになりがちである。しかし、病院は診察業務だけで成り立っているわけではない。出色の出来映えの電子カルテシステムがあっても、それだけでは、効率的な病院運営、マネジメントはできない。目的地まで高速道路と一般道路、農道、あぜ道などが混在しているようなもので、一部分だけ速く走れても効果は少ない（図４）。筆者の考える院内統合情報システムでは、図５に示すようにデータベースをハブにして情報交換を行うと共に、院内すべての業務が相互に連携し合うように考えられている。これによって、図６に示す狙いを実現しようとしている。図５院内統合情報システムの発想○ C 図６院内統合情報システムの狙い○ C （２）進め方一般的にベンダ（SIer）のＳＥ（systems engineer）がシステム化対象業務を分析し、仕様を書いてシステムを作ることになっている。しかし、今はパッケージが主流であり、ＳＥが行っていたこれらの作業はほぼなくなり、代わりにパッケージを如何に当てはめるかという役割に変わりつつある。筆者の関与した病院では、既述のとおりパッケージは使わないので、ＳＥのヒアリングを受け、業務を分析してもらい、仕様書を作ってもらうことになる。 Copyright 2014 杉浦技術士事務所 All rights reserved ４しかし、現場を知らず、細部に亘っての業務を知らないＳＥに、誤解なく理解してもらうのは、時間と効率、効果の点で問題があると思われた。（伝える側の表現にも問題はあるが･･･）例えば、図７に示すような請求可否の算定ルールは病院にとっては極めて重要な要素であるが、ＳＥからヒアリングを受ける程度では伝えきれない複雑さがある。糖尿病患者の手術時間と食事時間、インスリンを打つタイミングなども同様で、これをＳＥに伝えるのは至難の業といえる。誤解されたまま実装されると、医療過誤が起きる可能性もある。また、同じ尿検査でも外来患者と入院患者では検査項目が違うが、このことを外来、病棟間で共有できていないということもある。一方の看護師に聞いて仕様を作ったら現場が混乱する仕様になってしまうが、院内にはこの様な業務が枚挙に暇（いとま）がないほど存在する。図７請求ルール事例○ C 日常的に業務をこなしている外来、検査、病棟、手術、医事会計、栄養士など現場のスタッフが仕様を作れば、ＳＥからのヒアリングで時間を取られることはなく、希望することが十分伝わらないということが解消される。何より、今後益々必要になる“システムについて議論でき、要求を仕様書に纏めることができる人材”が育つという大きなメリットがある。問題は、システムに関して全くの門外漢のスタッフにそれができるかである。しかし、スタッフの向上心を刺激し、組織を活性化することにもつながるチャンスと捉え、現場スタッフを教育し、仕様を作ってもらうことにチャレンジすることにした。一方、システム構築のために必要な多岐に亘る技術は、教科書的な勉強で習得できるはずがなく、生兵法はケガの元になる可能性がある。スタッフは仕様を作るだけとし、実際にシステムを作るのは、それを専門とする SIer 任せることにした。プロトタイプを作り、院内に設けた動作確認環境を使い、仕様を作ったプロジェクト委員が、現場のスタッフに、機能、操作を説明。これによって、現状機能、操作の周知を図ると共に、現場スタッフから出される忌憚のない意見の中から、漏れていた機能の発見、作業の連携不備などの指摘を吸収し、完成度、実用度を高める（フィッティング、ブラッシュアップ）。これを繰り返し、稼働まで持って行く（スパイラルアップ）進め方を採っている（図８参照）。 Copyright 2014 杉浦技術士事務所 All rights reserved ５図８プロトタイプアプローチ、スパイラルアプローチ○ C （３）教育（現場のＳＥ化）教育は、仕様書を作る過程をとおし、①基本リテラシ○ R 、②問題発見能力、③問題分析能力、④ 問題解決能力につき、OJT（on the job training）で行った（表１参照）。具仕様を作る際に使ったのは、習熟に手間がかかり、余分な機能が多い開発支援ツールではなく、一般的な PowerPoint である。病院にみならず、化粧品メーカなど、過去これで対応してきたが、問題はなかった。＃１２３４リテラシヒアリング（聞き出す能力）ドキュメンテーション（文章で表現する能力）プレゼンテーション（分かり易く説明する能力）ネゴシエーション（利害を調整する能力）表１基本リテラシ○ R 内容忌憚のない意見、要望、疑問を漏れなく引き出せる能力。ヒアリング以降の作業の品質、成果物の完成度が左右される重要な能力。特に、当たり前だと思って言わないことを聞き出せるかどうかは大きなポイント。聞いたことや、決まったこと、意見、意志を文章で表現する能力。簡潔、正確、素早く書けることが要求される。また“読みたい”と思わせる表現力、見やすい体裁にするセンスが要求される。“ドキュメントは人がいないプレゼンテ－ション”と考え、傍にいて補足説明しなくても、伝えたいことが誤解なく伝わるかどうかを気にした文章が書ける能力が要求される。相手が専門家か非専門家か、また、経験の度合い、関心の深浅など、状況に応じて臨機応変に話し方や説明する切り口を変えられる能力とセンスが必要。プレゼンしながら相手の反応、理解度を観察し、“誤解のない理解”が得られているかをチェックしながら説明する気遣いが求められる関連部署間で矛盾する要望が出てくることはよくある。この時、各部署の事情を配慮しつつも“個々の最適化の寄せ集めは、全体の最適化にならない”ことを説明し、納得してもらう調整能力が要求される。確固たるポリシーが必要現場のＳＥ化は成功しつつあり、自部門の業務を洗い出し、作業手順を見直し、それに基づく仕様が Copyright 2014 杉浦技術士事務所 All rights reserved ６作れる薬剤師、看護師、栄養士、検査員、医事会計など現場スタッフが育っている。BPR（business process re-engineering）を行っていることが前提だが、現場の作業実態を踏まえた仕様は数千もの画面、ドキュメントとなり、成果を出している。この仕様は、機能の過不足、操作性、画面遷移の妥当性などの現場のスタッフを交えてのデザインレビューを受け、適宜修正されてから SIer に提供されている。なおレビューする過程で、技術的な実現な可能性についても専門家ほどではないものの、SIer のＳＥとの会話ができる素養も身についている。システム系の人材が揃いにくい地方にあっては、この人材育成は、医療機関のみならず、企業活動にとって重要なことといえる。仕様以外にも、自動精算機、自動受付機など、高価、且つ使用頻度の少ない余分な機能がある反面、現場作業実態に合わせた気の利いた機能がない市販機器については、欲しい機能を絞り、必要な情報をその情報を処理している機能からデータベース経由送り込んで処理する制御ソフトを作り込んで完成させた（自前）。自動精算機は１台 1000 万もするが、見映えはしないものの、実用上遜色のないものが 100 万以下の費用で実現でき、自動精算機のように紙幣を扱う特別な機械（これは購入）が必要ない自動受付機に至っては 35 万で出来上がった。現場の作業実態を踏まえた独創的な機能、操作性を盛り込んだうえに、既製品に比べて格安の費用に抑えることができているが、特別な場合を除き、やれないことはほとんどない、というのが実感といえる。以上述べてきたが、病院の効率的運用、マネジメントのためのシステムは、ベンダから示されたパッケージの中から選らぶというパラダイムを改め、主体的に関与すべきであり、場合によっては、自ら開発に参加することも可能であるというのが結論である。 Copyright 2014 杉浦技術士事務所 All rights reserved ７