病院経営ウェブマガジン“Healthcare Compass (ヘルスケア・コンパス)”

Healthcare Compass (ヘルスケア・コンパス)。病院経営ウェブマガジン。病院経営の中でも急性期病院の経営・運営に携わる人のためのメディアです。

Healthcare Compass (ヘルスケアコンパス)

電子カルテに関わる際に知っておきたいシステム開発の基本

先日、Twitterでこんなやりとりを見つけました。 

お互い良い課題なので、Twitterで情報が流れてしまうのはもったいないし、わんたかさんはまだまだ電子カルテについて語りたさそう・・・。

ということで、今回はHealthcare Compass編集部からわんたかさんこと、倉敷中央病院の医事企画課で働く元SIerの犬飼さんに、電子カルテにまつわるシステム開発について、ご執筆いただきました。

それでは、犬飼さんによるご寄稿どうぞお楽しみください!

✄----------------------------------

電子カルテに関わる際に知っておきたいシステム開発の基本

「電子カルテが使えない、IT業界が医療に追い付いていない!」

「電子カルテが、医師や看護師の仕事の効率化を阻んでる!」

 このような不満を抱いたり、意見を耳にしたりすることはありませんか?
院内の業務改善に取り組むたびに、電子カルテをはじめとする院内システムに対して「もうちょっと仕様を改善してくれたらいいのに」と私も憤りを感じることが多々あります。

一方で、私は元々NTTデータというITベンダーで働いていましたので、彼らの厳しい開発状況や判断基準などの様子に察しがつきます。最近は「確かにこれではしょうがないな」という諦めに近い感情を抱くことも多くあります。

 

こんにちは、倉敷中央病院の医事企画課で働いている犬飼です。
私の経歴については、以前寄稿したこちらの記事をご参照ください。

今回は元SIerの私が考えるシステムユーザー、つまり病院職員が理解しておいてほしいシステム開発の基本をお伝えします。

f:id:massy535:20190614234113j:plain

なぜ病院関連のシステムが「イケてない」のか。

私の結論としては
「病院側がIT企業のビジネスとシステム開発を知らなすぎる顧客だから」
です。

つまり「情報の非対称性」によって、満足度の高いサービスを享受できていないのです。(あれ?これってどこかで聞いたような…医師と患者の関係と似てますね。)

私が情報の非対称性を感じる例として、こんなものが挙げられます。

  • 要件定義はITベンダーがやるものと考えている
  • 仕様凍結後に要件追加があっても既存契約内で対応させようとする
  • 本契約に含まれていない機能追加を「簡単だから」と無償でさせようとする
  • パッケージプロダクトなのに、自院のやり方に併せてカスタマイズさせまくる

これらは全部システム開発において、ご法度とされるものです。契約上の不正行為もあれば、開発スケジュールの遅延要因になったり、今後の改良の邪魔になったり、最悪プロジェクトが頓挫してしまうレベルの危険な要求が含まれています。

システム開発の仕組みを知らなければ、「これぐらいいいじゃん」、「当院がお金を払っているのだから、やってくれて当たり前」と思ってしまうでしょう。でも、これらの要望を無理やり通したり、ITベンダーに作業を丸投げしたりしていては、システム開発プロジェクトの「炎上」リスクが跳ね上がります。そして、結果として病院、ひいては貴方が不利益を被ることになる可能性が高くなります。

システム開発は医療と同じ、非定型でカタチのないものを提供するサービス業の側面もあるのです。また、その内容が複雑であり専門性が高いもの、というのも似ています。満足度の高いシステムを作るには、発注元、つまり病院側の協力が必要不可欠です。そのためにも、ITリテラシーと開発工程に関する知識が必要です。

ここからは、ITベンダーのビジネスモデルやシステム開発の流れをお伝えします。
上手にITベンダーと付き合っていき、より「イケてる」システムを作るために必要な情報として役立てて下さい。

 

1.病院は「おいしくない顧客」

病院経営に携わっている方々が、「IT企業に病院を食いものにされる!」と仰っている姿を何度か拝見しました。確かに、電子カルテをはじめとする病院情報システムをMRIなどの大型医療機器と同等額程度の費用をかけて構築したにも関わらず、機能改善のたびに数百万円の追加費用が請求され、加えて運用保守にもお金を取られていると、そう思ってしまうのも致し方ないと思います。

しかし、大手ITベンダーにとって病院は、正直あまり「おいしくない顧客」です。理由はひとつ、「病院がお金持ちではないから」です。それはビジネス規模の広がりが限定的であり、企業の発展と成長に寄与しにくいと考えているからです。

ここで、大手ITベンダーと医療IT市場規模を比べてみたいと思います。大手ITベンダーを「総合病院向け電子カルテを開発している企業」でありかつ「医療業界以外にも顧客を有している企業」と定義すると、以下3社が該当します。

  1. 富士通(2018年度売上収益:3兆9,524億円・同営業利益:1,824億円)※1
  2. NEC (2018年度売上収益:2兆8,444億円・同営業利益: 639億円)※2
  3. 日本IBM(2018年度売上収益:  9,053億円・同営業利益: 844億円)※3

いずれも超巨大企業です。3社合わせると7.7兆円の売上高となり、これは概ねペルーの国家予算(年間歳出)と同じ規模になります。一方で、病院を含めた医療ITの日本市場総額は、調査会社ガードナーによると1,894億円※1です。

f:id:massy535:20190614234400p:plain

「富士通グループ統合レポート2018」によると、当該市場で富士通はシェア33.7%で国内1位です。つまり、富士通は2018年度に約638億円を医療業界から売り上げていることになりますが、これは売上収益の1.6%にしかなりません。仮に富士通が市場を寡占できたとしても、売上収益の4.7%程度に留まります。

つまり、日本における医療IT市場は小さな市場であり、大手のITベンダーにとっては売上収益増に貢献しにくい、つまり経営判断の際に注力する必要性が薄い市場と言えます。医療部門に力を入れるよりも、もっと売上収益や営業利益にインパクトがあると思われる金融部門(市場規模:2兆3,841億円)や産業部門(市場規模:2兆1,233億円)に注力したほうがよい、と判断するのは企業として妥当な判断だと考えます。
このことからも、大手ITベンダーは病院から利益を吸い取ろうとは考えていないのです。

 

2. パッケージソフトによる開発効率化

電子カルテのような複数の機能を有するシステムをゼロから作り上げるには莫大な時間と費用が掛かります。これでは、多くの病院が簡単には手を出せなくってしまいます。そこで、ベンダー側がある程度業務を想定して必要な機能を予め作り上げた、パッケージソフトというものを活用するのが現在の病院システム開発の主流となっています。

電子カルテをはじめとする病院関連システムの多くは、「パッケージソフト」と言われるものです。例えば、NECの「Megaoak」シリーズや富士通の「HOPE」シリーズなど、同一製品名で多くの病院に導入されているものはパッケージソフトです。

パッケージソフトを用いる大きなメリットが2つあります。「コストが安い」という点と「バージョンアップが簡単」という点です。

パッケージソフトは開発にかかった費用を導入してくれる複数の顧客から分散させて頂戴する仕組みなので、販売価格を安くすることができます。また、全病院に必要であろうと思われる機能については、ITベンダー側で独自に追加開発を行い、細かにバージョンアップ版を配信します。各病院は配信された機能のうち、自院に必要なものを適宜導入することができるので、追加開発の手間が省けます。

このように、パッケージソフトは本来「全国の病院標準製品」であり、ユーザーである病院の置かれている環境にあわせて日々更新されていく、大変便利なものであるはずなのです。

 

3.システム開発は「最初」が重要。後戻りは難しい。

では、何故こんなにも「電子カルテが使えない」「医事会計システムが不便」という意見があふれているのでしょうか。

ITベンダー側が十分に対応できていないことも原因の一端があると思います。
しかし、病院側にも原因があると思います。「どんなシステムを開発したいか」を十分に検討できていないように思えるケースが多いのです。

  • 「これは当院にぴったりのパッケージソフトだ!」と思って導入したけれど、実際に使ってみるとイマイチで、大幅なカスタマイズが必要だった。
  • いざカスタマイズしたはいいものの、望み通りの機能開発に至らなかった。

などの経験はないでしょうか。

このような事態が起こるのは、システム開発の第一歩目である「要件定義」という工程を失敗している可能性があります。そしてこの工程はユーザーである病院が行う工程であり、かつシステム開発の成否のカギを握る、重要な工程です。
ですので、病院側「どのようにシステムが作られているのか」を知っておくことはとても大切なことだと思います。

まず、システム開発の大きな流れについてお話します。システム開発の方法には大きく分けて「ウォーターフォール型」と「アジャイル型」の2つに分かれています。

ウォーターフォール型は従来より使われてきた方式で、開発をスタートすると当初の計画に従い、一気に製品を完成させることが特徴です。プロジェクト管理に関するノウハウが蓄積しているので、大規模システムなどの開発に使われることが多いです。
一方、アジャイル型はこの10年ぐらいで急速に広まった、新しい方式です。少しずつ製品を完成に向けて仕上げていくことが特徴です。(参考サイト:https://boxil.jp/mag/a3641/

電子カルテをはじめとする病院関連システムの大多数は古くから存在しており、またシステム規模も比較的大きいことから「ウォーターフォール型」で作られ、また追加開発されていると思われます。

 

ここでは、ウォーターフォール型のシステム開発方法について、説明します。

システムの開発を「要件定義」「外部設計」「内部設計」「製造(プログラミング)」「テスト」の工程に分割し、順々に行う方式です。前の工程には戻らない前提で行うため、ウォーターフォール(落水)型と言われています。

f:id:massy535:20190614234602p:plain


 前工程に戻らないことを前提とした開発方式です。ですので、システム開発が上手くいくかどうかは、最初の工程である「要件定義」がカギとなります。

 

4. 要件定義に病院の想いを込める

「どんなシステムが欲しいか」ということを知っているのはユーザーである病院だけです。そして、この要望をしっかりまとめることができるのも病院だけです。この「どんなシステムが欲しいのか」という要望をまとめる工程を「要件定義」といいます。この工程は、新しくシステム開発をする場合だけでなく、パッケージソフトを導入する場合であっても必要な工程です。自院に必要な機能を見極め、その機能を有している製品を選ばなければならないからです。

また、システム開発に関する契約のうち、要件定義のみは「準委任契約」になっています。この契約はざっくりいうと「顧客が行う要件定義を手伝う」という内容です。ITベンダー側はあくまで「お手伝い」の立場です。要件定義を行い、確定させるのは顧客の責任になっています。

要件定義では、まずどのような業務フローなのかを確認するところから始まります。診療科や病棟によって異なるやり方をしている場合は業務フローの統一が必要でしょう。その後、業務フローの中で、どこをシステム化するのか、誰がどのように使うのかを検討します。具体的なイメージができたあとに、内容がITベンダーに伝わるように、要件定義書を作り上げていきます。

要件定義を蔑ろにして、「当院にピッタリ合うシステムを作ってほしい」という要望を出すことは、ファミレスでウェイターに「私が食べたいものをください!」と言っているのと同じです。これでは本来、私が望んでいる和風おろしヒレカツ定食は出てきません。また途中で要件を変えたりすることは、ヒレカツを揚げ始めているのに「やっぱりハンバーグにしてください!」というのと同じで、お店はヒレカツを廃棄し、ハンバーグに作り直さなければなりませんし、貴方はお腹を空かしたまま、席で待っておかなければなりません。

もちろん、要件定義を十分にやったとしても、望んでいたものそのままが達成されるとは限りません。ですが、この工程は「自分たちの責任で行う工程」です。丸投げしたり、曖昧な部分が多すぎたりすることなく、丁寧に行うことが重要です。

 

5.ITベンダーとうまく付き合う

ITやシステム開発は魔法のツールではありません。確かに、医学と同じく日進月歩で進化を遂げており、IoTやAIなどのすさまじい発展により「遠い未来」と描いていたことが現実化できる時代になっています。但し、「適切な対価(お金と時間)を掛ければ」という前提条件があるのです。システムは見えない部分に沢山の労力がかかっています。ユーザーが使う操作画面の裏側には緻密に計算されたプログラムが組まれています。また、その動作を支えるデータベースが組み上げられています。更にはセキュリティや安定稼働のための仕組み、柔軟性や拡張性をどこに持たせるかといった全体設計などに多くのエンジニアが苦心しているのです。たとえば、ユーザーから見れば「ちょっとボタンをつけるだけ」であっても、どこのデータベースをリンクさせるのか、全体に影響がないのかなど検討し、場合によっては大規模な修正が必要になることもあります。そうなると、お金も時間もかかるのは言うまでもありません。

病院は性質上、収益力の弱い組織です。僅かに使えるお金の中から捻出できるシステム投資費用は少ないのが現実です。この環境で病院がITシステムを用いて効率よく業務改善を進めるために「パッケージソフトを徹底的に活用する」「カスタマイズを行う時には要件定義をしっかり行う」ことが重要です。

自分たちの業務を棚卸して、業務フローを分析し、カスタマイズが少なくて済むパッケージソフトを選定します。時にはパッケージソフトの機能をフル活用できるように、業務フローを変更することも必要でしょう。

やむを得ず、カスタマイズを行う際には要件定義の際には可能な限り精緻にまとめ上げます。新たな業務が発生した場合は業務フローを作り、作業を統一化させます。これにより無理や無駄が少ないシステム開発に繋がります。

システム開発という特殊性の高い内容であっても、ユーザーである我々病院が参画できる部分はたくさんあります。そして、病院が出来ることを最大限に行うことで目標達成率をグーンと上げることが出来ます。つまり、システム開発はITベンダーに「作らせる」ものではなく、「一緒に作り上げる」という気持ちがプロジェクトの成功のために、最も必要なのです。

参考文献
※1:富士通グループ統合レポート2018
※2:NEC統合レポート2018 2018年3月期
※3:日本IBM公式HP「損益計算書の要旨(自平成30年1月1日 至平成30年12月31日)」

--著者--
犬飼 貴壮
2009年早稲田大学理工学部卒業後、NTTデータにて政府系金融機関への営業、石油業界への商品企画に従事。2013年にUターン転職し、倉敷中央病院に入職。経営企画部にてJoint Commition International取得プロジェクトに参画。プロジェクト管理並びにケアの標準化に向けた取り組みの立上げ、運用を行う。現在、医事診療サービス部にて病床稼働率向上に向けた業務フロー改善など内部運用改善に取り組んでいる。応用情報処理技術者。

 

Healthcare Compassでは皆様からの投稿をお待ちしております。

こんなことを伝えたい、書いてみたい、という方は healthcare_ops@yahoo.co.jp にまずはお知らせ下さい。もう書いてみた、という方はそのままお送りください。編集部で頂いた内容を検討し、ご連絡します。

 

“Healthcare Compass”では過去に公開した記事をまとめて、メールで配信しています。