トピック 5.4 — ソフトウェア工学健康経済学

なぜ健康経済学において重要か

現代のあらゆる医療組織は、それを認めるかどうかにかかわらず、ソフトウェアの運用者である。患者記録、処方、予約、検査結果、支払い請求、人口サーベイランスはすべてコードの上で動いている——販売業者から買われ、社内で構築され、前任者から受け継がれ、あるいはその三つすべてにわたってつぎはぎされている。関わる資金は大きく反復的である。国の電子健康記録プログラムは数十億ドルの公的資金を消費してきており、ソフトウェアの運用費用——維持管理、統合、アップグレード、セキュリティ——は通常、元の事業計画に現れた価格を矮小化する。しかし、ほとんどの健康経済学の訓練はソフトウェアが経済資産としてどう振る舞うかについて何も語らず、ほとんどのソフトウェア工学の訓練は看護師と医薬品も買う制度における機会費用について何も語らない。

その隔たりが重要なのは、ソフトウェアが通常の調達の反射では捉えられない特有の方法で経済的に失敗するからである。システムはその購入価格とデモ機能に基づいて買われる。統合、データ移行、維持管理の負担は後になって、一度も相談されなかった予算に降りかかる。販売業者との関係は依存へと硬化し、更新のたびに弱い立場から交渉することになる。締め切りの圧力の下で取られた近道は目に見えないまま蓄積し、やがて病院を動かすシステムがもはや安全に変更できなくなる——その時点で組織は一度も計画しておらず延期もできない近代化の請求書に直面する。なぜならそのソフトウェアは今や臨床的リスクを担っているからである。イギリスの国民保健サービスの国家ITプログラム(2011年に約100億ポンドの費用の後解体された)を含む大規模な医療IT プログラムの歴史は、この力学の国家規模での歴史である。

指導者にとって、その利害は三重である。第一に資金である。ソフトウェアは全生涯にわたるコミットメントであり、購入時の安価な選択肢は10年にわたってしばしば高価な選択肢になる。第二に安全性である。臨床の現場では、停止、データエラー、あるいは維持できないシステムは不便さではなく危険であり、その費用はトピック3.11——質と安全性の経済学に降りかかる。第三に主権である。構築と購入の間、独自システムとオープンシステムの間、標準インターフェースとあつらえのインターフェースの間の選択は、組織が5年後にどれほどの行動の自由を持つかを決定する——そして行動の自由は、この本を通じて論じられているように、経済資産である。

中核概念

ソフトウェア工学は、ソフトウェアの規律ある設計、構築、維持管理であり、維持管理という言葉がその経済学の大部分を担う。建物とは異なり、ソフトウェアは決して完成しない。要件は変化し、規制は変わり、依存関係は古くなり、セキュリティの脅威は進化する。ソフトウェア保守——サービス中のシステムに対する是正的、適応的、予防的な作業——は通常、システムの生涯費用の大部分を吸収する。したがって経済分析の単位は決して購入ではない。それは総保有コストである。取得に加えて統合、データ移行、訓練、ホスティング、サポート、アップグレード、セキュリティ、そしてシステムの現実的な生涯にわたる最終的な廃止である。

二番目の概念は技術的負債である。今、健全な設計の代わりに便宜的な設計を選ぶことの暗黙の将来費用である。その比喩は財務の会議で使えるほど正確である。負債は本質的に悪いものではない——必要な機能をより早く出荷する意図的な近道は合理的な借り入れでありうる——しかしそれは利子を発生させる。システムへの将来のすべての変更はそれのためにより多くの費用がかかり、管理されない負債は変更が法外に高価あるいは危険になるまで複利で増える。自らの技術的負債を見ることができない医療組織は、まるで記録されていない借り入れを持っているかのように、帳簿に載らない負債を担っている。

第三にレガシーシステムである。経済的に維持できる時点を過ぎてもサービスに残るソフトウェアであり、しばしばそれが機能し、誰もがそれに依存し、置き換えることが恐ろしいからである。レガシーは組織規模の技術的負債であり、真の評点の問題を提示する。それを維持する費用(上昇する維持管理費、セキュリティへの露出、もはや雇えない職員、他所でブロックされた改善)は拡散し漸進的である一方、置き換えの費用は集中し、可視的で、政治的にリスクがある。世界中の医療制度がまさにこの理由で何十年も前のソフトウェアで重要なサービスを稼働させている。

第四に依存である。ベンダーロックインは、供給業者から離れることが、データ移行、再訓練、再統合、臨床的混乱において非常に多くの費用がかかり、買い手が実効的な交渉力を失ってしまう状態である。医療においてそれはデータによって悪化させられる。独自のフォーマットで保持された10年分の患者記録は人質である。ロックインは事故ではない。それは価格戦略であり、それに価格をつける時は署名前であって更新時ではない。対抗手段は契約上(データエクスポート権、エスクロー、離脱支援)と建築的——何よりも標準である。

第五に相互運用性である。システムが情報を交換し、交換されたものを使う能力である。その経済学はネットワーク効果の経済学である——共通の標準を話す各システムは、そうする他のあらゆるシステムの価値を上げる——これが相互運用性が市場によって慢性的に過少供給される理由である。便益はシステム全体に発生する一方、費用は各販売業者と買い手に降りかかり、既存業者は相互運用しないことから利益を得られる。高速医療相互運用性リソース(FHIR)のような標準、それが属するHL7ファミリー、そしてopenEHRは、これらの交換費用を下げるために存在し、規制当局——例えば米国は21世紀治療法の情報ブロッキング規則を通じて、欧州連合は欧州医療データ空間を通じて——市場が届けなかったものを義務づけ始めている。

第六に、オープンソースソフトウェア——ソースコードが自由に使用可能で改変可能なソフトウェア——を含む作るか買うかのスペクトラムである。オープンソースは無料ではない。ライセンス費用は消えるが、実装、ホスティング、管理責任は残り、誰かがコードを維持しなければならない。その経済的な区別は異なる。それはロックインのプレミアムを取り除き、ソフトウェアを多くの買い手が共同資金提供できる共通財に変える。これがDHIS2やOpenMRSのようなプラットフォームが低中所得国の保健情報の負荷の多くを担っている理由である。構築対購入の決定も同様に、技術の好みではなくポートフォリオの問いである。能力が差別化要因であり組織がエンジニアリングチームを維持できる場合は構築せよ。必要がコモディティである場合は買え。そして維持できないものは決して構築するな。

最後に、経済量としての信頼性である。臨床ソフトウェアはダウンタイムが健康の費用を持つサービスを稼働させるため、システムを信頼できるものに保つ工学的な規律——明示的な目標と許容可能な失敗のための予算に照らして信頼性を管理するサイト信頼性エンジニアリングを含む——は、その保険料が工学的な努力である保険を買うこととして最もよく理解される。臨床現場が必要とするものを超える信頼性は浪費であり、それを下回れば、その不足分はインシデントの中で支払われる。これらすべての評点機構は依然としてトピック2.1——経済評価とトピック2.5——予算影響と負担可能性の負担可能性の規律にある。このトピックはそれらの方法が与えられなければならないソフトウェア特有の費用構造を供給する。デジタル道具を健康介入として評価すること——アプリや遠隔医療サービスが許容できる費用でアウトカムを改善するか——はトピック5.2——デジタルヘルス経済学に属する。AIモデルの経済学は具体的にはトピック5.3——AI健康経済学にある。

ベストプラクティス

購入価格ではなく、システムの現実的な生涯にわたる総保有コストを評点せよ。 すべてのソフトウェア事業計画に、通常は10年以上の述べられた時間軸にわたって、取得、統合、データ移行、訓練、ホスティング、サポート、セキュリティ、アップグレード、廃止を費用計上し、どの予算が各反復的な項目を担うかを名指すよう要求せよ。何とも比較されないライセンス料は事業計画ではない。それはコミットメントの目に見える先端にすぎない。
技術的負債を帳簿に載せよ。 エンジニアリングの指導者に、各々が課している利子——より遅い変更、より高いインシデントのリスク、ブロックされた改善——の正直な見積もりとともに、施設内の重要な近道と古くなった構成要素の登録簿を維持させよ。それを財務的負債と同じ真剣さで見直し、それを返済するためにエンジニアリング能力の常設の分け前(通常5分の1から3分の1)を予算化せよ。なぜなら延期された負債の返済は複利で増える負債だからである。
初日から維持管理を運用費用として財源化せよ。 「完成した」ソフトウェアは劣化しているソフトウェアである。依存関係は古くなり、脅威は進化し、規制は変わる。維持管理の流れを元の評点と反復的な予算に組み込み、維持管理の項目がない提案を不完全として扱え。資金はどちらにせよ使われる。唯一の問いはそれが計画されたか、危機によって引き出されたかである。
署名前にロックインに価格をつけよ。更新時ではなく。 すべての主要な購入について、まだ代替案があるうちに離脱を費用計上せよ。誰がデータを所有するか、どのフォーマットでそれをエクスポートできるか、販売業者がどんな離脱支援を提供しなければならないか、移行がもっともらしくどれほどの費用がかかるか。データエクスポート権とオープンインターフェースを契約に交渉せよ。それらへの販売業者の抵抗を、来るべき更新交渉についての情報として扱え。
市場がそれを過少供給するため、意図的に相互運用性を買え。 オープン標準——FHIRとその仲間——のサポートを購入の条件として要求し、パンフレットではなくあなたの実際のデータフローに対して主張されたコンプライアンスを検証し、標準のものが存在する場合はあつらえのインターフェースを拒否せよ。あなたが受け入れるすべての独自インターフェースは、あなたが販売業者に寄付した切り替え費用であり、将来のあらゆる統合への税である。
構築対購入を、あなたのエンジニアリング能力に一致するポートフォリオとして決定せよ。 その能力があなたのサービスを差別化し、あなたが構築するものを維持するチームを現実的に採用し、保持し、資金提供できる場合にのみ構築せよ——持続的なチームのない社内システムは、余分な手順のあるレガシーシステムである。コモディティの必要を買え。コミュニティあるいは公的コンソーシアムがそれを維持する場合はオープンソースプラットフォームを検討せよ。そしてどちらの道に進むにせよ、維持の計画を決定に書き込め。
オープンソースを無料としてではなく独自の費用構造を持つ調達の選択肢として扱え。 それを総保有コストで比較せよ。ライセンス料はないが、実装、ホスティング、サポート、管理責任の本物の費用は、社内で担われるにせよサポート供給業者を通じて担われるにせよ残る。その特有の便益——ロックインのプレミアムがない、検査可能なコード、他の医療機関と共通財を共同資金提供する能力——とその特有の義務——それに依存するなら、それを維持することに貢献する——を比較検討せよ。
臨床的な帰結から信頼性の目標を設定し、その目標に向けて支出せよ。 サービスごとに、ダウンタイムの1時間が実際に何を犠牲にするか——遅延したケア、安全でない回避策、失われた信頼——を決定し、それに応じて可用性と回復の目標を設定せよ。次に、両側からその目標にエンジニアリング支出を保て。クリニックが必要とするより少ない信頼性に支払うことはインシデントを買い、必要以上に支払うことは金メッキを買うことである。
強制される前にレガシーの置き換えを計画せよ。 重要なシステムの年齢と保守可能性をサイクルごとに見直し、既存のものがまだ機能しているうちに置き換えを始めよ——失敗の下で実行される移行は最も高くつく種類である。ビッグバン移行よりも段階的な移行(古いシステムをインターフェースごとに絞め殺す)を優先せよ。その失敗モードは医療においてはキャンセルされたクリニックと失われた記録として測られる。
データ移行をすべての評点における第一級の項目にせよ。 患者データはそれを保持するあらゆるシステムより長生きし、それを移動すること——クリーンに、完全に、臨床的安全性が保証された状態で——は、どんな移行においても通常、最大で最も過小評価される費用の一つである。それを明示的に費用計上し、実際の記録でそれを早期に試験し、システムの生涯を通じてあなたのデータをエクスポート可能な形式で保持せよ。それにより移行が去っていく販売業者の人質になることは決してない。
臨床安全性工学を経済学の内側に保て。 医療ソフトウェアは安全性に関連するソフトウェアである。変更には試験が必要であり、リリースにはロールバックの経路が必要であり、インシデントには調査が必要であり、管轄区域はますます医療ITに正式な臨床リスク基準を課している。これらの規律はエンジニアリング時間を要し事業計画に属する。それらを省く「より安価な」提供は、費用をリスクとして患者に移転していることになる(害の費用はトピック3.11——質と安全性の経済学にある)。
ソフトウェアの決定を、他のあらゆる健康投資と同じ価値の精査に通せ。 ソフトウェアプログラムは医薬品と職員と同じ制約のある予算を競うため、同じ規律を負う。述べられた便益、本物の比較対象(「持っているものを改善する」を含む)、時間にわたる負担可能性のプロファイル、そして立てられた約束に照らした実装後のレビューである(機構はトピック2.1——経済評価とトピック2.5——予算影響と負担可能性にあり、購買の技法はトピック3.10——戦略的購買と委託にある)。

チームと議論すべき問い

私たちのソフトウェア施設は実際に年間いくらかかっているのか、そしてそのうちどれほどを私たちは計画していたのか。 ほとんどの組織はライセンス料を名指せるが、組織全体の運用予算と職員の時間の中に隠れている統合、維持管理、セキュリティ、回避策の費用は名指せない。チームに主要な少数のシステムの真の年間数字をまとめ、元の事業計画が約束したものと比較するよう求めよ。緊張関係は、拡散した費用には単一の所有者がおらず、したがってその成長に誰も責任を負わないということであり、購入を承認した人々はめったに維持費を払う人々ではない。誠実な答えは全生涯の数字を生み出し、どの予算がそれを担うかを名指し、支出が計画されていないところを認める——なぜなら毎年遅れて発見する費用は管理できない費用だからである。
私たちの技術的負債はどこにあり、私たちはそれにどんな利子を払っているのか。 エンジニアリングチームは通常、負債がどこにあるかを正確に知っている——誰も触れる勇気のないモジュール、手作業の手順で持ちこたえているインターフェース、セキュリティサポートで2バージョン遅れているプラットフォーム——しかし、その知識はめったに経済的な言語で理事会に届かない。登録簿を求めよ。重要な負債、それぞれが何を遅らせるか危険にさらすか、そしてそれを返済することにどれほどの費用がかかるか。緊張関係は、負債の返済が目に見える新機能と競争し、常に見栄えで負けるということであり、これはまさに負債が複利で増える方法である。誠実な答えは利子(より遅い提供、インシデントへの露出、ブロックされたプロジェクト)を数量化し、削減のために常設の能力の分け前をコミットし、いくらかの負債は知っていれば担うことが合理的であると認める。
私たちが3年で主要なシステム販売業者を去らなければならないとしたら、去れるか——そしてそれはいくらかかるか。 この問いは、それを減らす時間がまだあるうちにロックインを表面化させる。誰がデータを所有し、どのフォーマットでそれが去れるか、契約が離脱支援について何を言っているか、何個のあつらえのインターフェースが再構築を必要とするか、そして移行がどんな再訓練と臨床的混乱を課すかを追及せよ。緊張関係は、誰もが離脱を行使することを決して望んでいないため、誰もそれを開いたままにしておくために支払いたくないということである——しかし不可能な離脱はすでに負けた更新交渉である。誠実な答えは離脱に価格をつけ、それを安くするであろう2つか3つの行動(データエクスポート権、標準インターフェース、文書化)を特定し、その価格を組織が積極的に維持する交渉上の立場として扱う。
どのシステムを構築すべきで、どれを買うべきか、そして私たちのエンジニアリング能力はその答えに一致しているか。 構築対購入の分割は、多くの組織が選択によってではなく積み重ねによって行うポートフォリオの決定であり、結局コモディティを構築し差別化するものを買うことになる。あなたのシステムのどれが真にあなたのサービスに特有な何かを体現し、どれが市場あるいはオープンソースコミュニティがすでにサービスしているコモディティの必要であるかを問え。次に能力の主張を試験せよ。社内で構築されたすべてについて、それを作ったプロジェクトだけでなくその生涯にわたってそれを維持することにコミットした資金提供され採用可能なチームがあるか。緊張関係は、構築が野心を喜ばせ、購入が慎重さを喜ばせるということであり、どちらの本能も分析ではない。誠実な答えは差別化要因を名指し、過去の構築のどこが退役あるいは標準製品に置き換えられるべきかを認め、維持管理の資金がないいかなる構築も始めることを拒否する。
私たちの最も重要なシステムにおけるダウンタイムの1時間は実際に何を犠牲にするのか、そして私たちの信頼性支出はそれに一致しているか。 信頼性の決定はしばしば臨床費用の情報なしにエンジニアによって、あるいはエンジニアリング費用の情報なしに理事会によって行われ、したがって支出は帰結ではなく習慣に一致する。具体的なシナリオを検討せよ。電子記録が忙しい一日中ダウンしている——何が遅延するか、どんな安全でない回避策が現れるか、もっともらしくどんな害が続くか、回復には何がかかるか。次にそれを、あなたが回復力、バックアップ、フェイルオーバー、インシデント対応に支出しているものと比較せよ。緊張関係は両方向に走る。過小な支出はインシデントを買うが、低い利害のシステムの金メッキは別のサービスが必要とする資金を浪費する。誠実な答えは、臨床的な帰結から導かれた重要なサービスごとの明示的な可用性と回復の目標を設定し、それに一致するエンジニアリング支出——多くも少なくもなく——を示すことができる。
誰もが触れることを恐れているレガシーシステムのために私たちの計画は何か。 成熟したあらゆる医療組織はそれらを持っている。経済的な保守可能性を過ぎたが、機能しており置き換えが恐ろしいために生かされているシステムである。あなたのものを名指せ。それぞれが何をブロックしているか——構築されていない統合、行われていない改善、担われているセキュリティへの露出——そして置き換えの経路は何か、段階的な移行か、全面的な置き換えか、それとも制御されたリスクを伴う意図的な計画された保持かを問え。緊張関係は時間的である。レガシーを保つ費用は拡散し年間であるのに対し、それを置き換える費用は集中しキャリアにおいて可視的であり、したがって合理的に見える延期が、失敗が最悪の価格で問題を強制するまでデフォルトになる。誠実な答えは、既存のものがまだ機能しているうちに置き換えを予定し、ビッグバンの切り替えよりも絞め殺し型の段階的な移行を優先し、「来年決める」をそれが実際にそうであるところの決定として扱う。

実践例:健康経済学の一例

架空の東アフリカの国の保健省は更新の決定に直面している。9年間、その地域の病院は海外の販売業者が供給する独自の病院情報システムを稼働させてきた。そのシステムは機能しているが、更新の見積もりは急激に上昇しており、新しいインターフェースはすべて——国の保険制度への、検査室ネットワークへの——あつらえの、販売業者が価格をつけるプロジェクトであり、契約はデータのエクスポートについて沈黙している。一方、省の地区保健事務所はすでに国の保健統計に用いられるオープンソースプラットフォームであるDHIS2を稼働させており、隣国は地域のサポートコンソーシアムを伴うオープンソースの医療記録プラットフォームを実装している。

省の健康経済学ユニットは、その決定を「更新するかしないか」から、10年にわたる3つの選択肢の全生涯比較に再枠づけする。既存のものを更新する、離脱権を構築しながら短期的に更新する、あるいはオープンソースプラットフォームへ段階的に移行する。選択肢を費用計上することで真の経済学が露呈する。既存のもののライセンスは、あつらえのインターフェース、義務的なアップグレードプロジェクト、海外のサポートの出張が数えられれば、その真の年間費用のわずか3分の1にすぎない。オープンソースの選択肢はライセンスを担わないが、省が国のサポートチーム、地域のホスティング、プラットフォームのコミュニティへの貢献に資金提供することを要求する——「無料ソフトウェア」の言説が隠していた本物の反復的な資金である。しかし決定的な項目はこれらのどちらでもない。それはデータ移行である。9年分の患者記録が独自のスキーマに座っており、抽出支援のための販売業者の価格は、実質的に、去ることの価格である。

そのユニットはとにかく離脱に価格をつけ、その数字が交渉を変える。費用計上された代替案を武器に、省は、文書化されたフォーマットでの契約上のデータエクスポートと、保険制度と検査室ネットワークへの標準FHIRインターフェースを含む、より低い価格での2年間の更新を交渉する——経済的な用語では、トピック3.12——パンデミックと緊急事態への備えの経済学が将来の行動の自由に関するあらゆるオプションを評価するのと同じ方法で評価される、より安価な将来の離脱に対するオプションとして買われる。その2年間の間に、パイロットは3つの地区病院をオープンソースプラットフォームへ移行させ、サポートコンソーシアム、データ移行ツール、そして決定的に、トピック3.6——医療従事者と労働市場の労働力経済学に基づいて、省がそのプラットフォームが必要とするエンジニアを採用し保持できるかどうかを試験する。

パイロットは2つの病院で成功し、3番目では苦戦する。そこでは人員不足がすべてのインシデントを危機に変える——能力についての警告であって、ソフトウェアについてではない。省は5年にわたる段階的な国家的移行を進め、病院ごとに、各サイトのデータが検証されるまで既存のものを並行して稼働させ続ける。最終評価はその教訓を明示的にする。勝因はオープンソースを独自のものより選んだことではなく、各選択肢の全生涯に価格をつけ、依存がさらに硬化する前に離脱権を買い、エンジニアリングのコミットメントを省が実際に持続できるものに一致させたことだった。

4つのセクターレンズ

スタートアップ

医療ソフトウェアのスタートアップは、このトピックの経済学を売る側から生きている。その評価額は出荷の速さに報い、それはまさに技術的負債が蓄積する方法であり、その収益モデルは顧客が抵抗すべきロックインに静かに依存しているかもしれない。その規律は、負債を意図的に取る——決定的な顧客を勝ち取る近道は合理的でありうる——一方で登録簿と返済計画を保つことである。なぜなら変更できないコードベースはピボットできない会社だからである。相互運用性はコンプライアンスではなく戦略である。標準インターフェース(何よりもFHIR)は、小さな製品が既存業者が支配する施設の中に場所を得る方法である。そして臨床安全性工学は規模になるまで延期できる官僚主義ではない。臨床現場での一つのデータ完全性のインシデントが若い会社を終わらせうる。

中小企業

クリニックグループ、薬局チェーン、診断検査室といった小規模だが確立した提供者は、そのソフトウェアのほぼすべてを買い、悪い購入を補う社内のエンジニアリング職員を持たない。したがってその経済学は依存の経済学である。総保有コストと離脱権はここでは他のどこよりも重要である。なぜなら誤って価格をつけられたシステムは予算の比例的により大きな分け前であり、失敗した移行は事業を停止させうるからである。賢明な姿勢は標準化である。主流の製品、オープン標準のインターフェース、自前で運営するサーバーではなくホストされたサービス、そして価格の前にデータエクスポート条項について読まれる契約である。その特有のリスクは静かなレガシーである——供給業者が畳むまでその場で古くなる診療管理システムである——したがって小規模な買い手でさえ、毎年、それが依存する各システムから去るのにいくらかかるかを知るべきである。

大企業

大規模な病院グループあるいは保険者は何百ものシステムを稼働させており、したがってその問題はポートフォリオである。異なる部門によって買われた重複する製品、誰も完全には地図化していない統合の網、そして一つのチームが見るには大きすぎる施設全体に分散した技術的負債である。成熟した大企業は、その施設を投資ポートフォリオのように管理する——所有者、全生涯の費用、負債とリスクの評点、計画された置き換えの時間軸を伴うシステムの目録——そして、すべての改善を入札されるべきプロジェクトとして扱うのではなく、統合、信頼性、返済のための常設のエンジニアリング能力に資金を提供する。規模はまた、より小さな買い手が欠く購買力も与える。それは標準インターフェース、データエクスポート権、エスクローを参入の条件として要求でき、その建築上の選択は販売業者を統制する、その逆ではない。

政府

省庁あるいは国の支払者は、他の全員のためにこれらの経済学を形づくる。それは市場が開放性に報いるか罰するかを決定する相互運用性の規則を設定する——米国が21世紀治療法の情報ブロッキング条項で、欧州連合が欧州医療データ空間で行ったように——そしてその自らの調達は買い手が何を許容するかを販売業者に教える。その特有の失敗モードは国家的なメガプログラムである。中央集権化され、ビッグバンで、政治的にスケジュールされたソフトウェア提供であり、その崩壊は数十億で測られる。イギリスの国家ITプログラムが実証したようにである。その規律は逆の姿勢である。標準とプラットフォームは中央集権的に、提供は段階的に、商業市場が薄いところでは真剣に検討されるオープンソースと地元で維持可能な選択肢を伴う(政策の機構はトピック3.2——医療政策にあり、購買の技法はトピック3.10——戦略的購買と委託にある)。

よくある失敗パターン

ライセンスを買い、生涯を買わないこと。 統合、移行、維持管理、離脱が費用計上されないまま、購入価格でソフトウェアを承認すること。対策: すべての事業計画で、すべての反復的な項目のための名指された予算とともに全生涯の総保有コストを要求する。
複利になるまで見えない負債。 施設が安全に変更できなくなるまで、技術的負債を記録されないまま蓄積させること。対策: 負債の登録簿を保ち、経済的な用語で報告し、返済に常設の能力をコミットする。
ロックインへと夢遊病のように入っていくこと。 離脱が手頃でなくなり更新が指示されるまで、独自のフォーマットとあつらえのインターフェースを受け入れること。対策: 購入時にデータエクスポート権と標準インターフェースを交渉し、毎年離脱に価格をつける。
維持できないものを構築すること。 その全生涯のための資金提供されたチームなしに社内システムを委託すること。対策: 維持の計画なしに構築しない。能力が薄いところではオープンソースプラットフォームを買うか採用する。
オープンソースを無料として扱うこと。 ホスティング、サポート、管理責任に資金提供せずにコミュニティプラットフォームを採用すること。対策: オープンソースを総保有コストで評点し、それが必要とする維持のために予算を組む。
希望による信頼性。 停止が実際にダウンタイムの臨床費用を明らかにするまで、可用性の目標を設定しないままにしておくこと。対策: 臨床的帰結から重要なサービスごとの可用性と回復の目標を設定し、目標に支出を一致させる。
窮地でのビッグバンのレガシー置き換え。 失敗が急いだ全面的な切り替えを強制するまで近代化を延期すること。対策: 既存のものが機能しているうちに置き換えを計画し、並行稼働と検証されたデータを伴って段階的に移行する。
価値の規律の外にあるソフトウェア。 ITプログラムが医薬品とサービスに適用される精査をスキップすることを許すこと。対策: 同じ規則——述べられた便益、本物の比較対象、負担可能性のプロファイル、実装後のレビュー。

成熟度モデル

次元	初期	発展	標準化	管理	統合
全生涯の費用計上	ソフトウェアがライセンス価格で買われる。運用費用は遅れて発見される	主要な購入が数年にわたって費用計上される。反復的な項目が部分的に特定される	すべての事業計画でシステム生涯にわたる総保有コストが名指された予算とともに要求される	施設全体の費用が予測に照らして追跡され、乖離が調査され、予測が再較正される	全生涯の経済学がポートフォリオを導く。投資、更新、退役が継続的に再調整される
技術的負債	見えない。インシデントを通じて発見される	エンジニアによって非公式に知られている。共有された記録がない	負債の登録簿が維持され経済的な用語で報告される。常設の返済能力	負債の傾向が限度と優先順位で管理される。利子が提供速度とインシデントへの露出で測定される	負債が戦略として意図的に取られ退役させられ、すべての提供の決定に価格づけされる
販売業者と離脱	提示された条件が受け入れられる。離脱は価格づけされない	ロックインが認識される。いくらかのエクスポート条項が求められる	データエクスポート権と標準インターフェースが原則として契約上のものである。離脱が購入時に費用計上される	離脱の立場が維持され予行演習される。更新が生きた代替案に対して交渉される	供給業者ポートフォリオが時間をかけて形づくられる。依存は選択され価格づけされた立場であり、決して事故ではない
相互運用性	あつらえのインターフェースが事例ごとに積み重なる	都合の良いところでオープン標準が好まれる	標準への準拠(例:FHIR)が検証された購入条件である	統合施設が地図化され管理される。独自インターフェースが計画通りに退役する	組織がパートナーと市場全体にわたって標準の採用を形づくる
信頼性と安全性	ダウンタイムの費用が不明。回復は即興で行われる	バックアップとインシデント対応が存在する。目標は暗黙的である	可用性と回復の目標が臨床的帰結から重要なサービスごとに設定される	信頼性が目標に照らして工学的に設計され測定される。インシデントが経済的に調査される	回復力が施設と供給業者全体にわたって統合され、予行演習され継続的に改善される

チェックリスト

すべてのソフトウェアの決定を、各反復的な項目のための名指された予算とともに、現実的な生涯にわたる総保有コストで評点している。
技術的負債の登録簿を維持し、経済的な用語で報告し、返済のために常設のエンジニアリング能力をコミットしている。
元の事業計画から一貫して維持管理を計画された運用費用として財源化している。
購入時にデータエクスポート権、標準インターフェース、離脱支援を契約に交渉している。
各主要なシステムからの離脱に毎年価格をつけ、更新の前に費用計上された代替案を生かしている。
購入の条件として検証されたオープン標準への準拠(例:FHIR)を要求している。
構築対購入をポートフォリオとして決定し、資金提供された全生涯の維持計画なしにはいかなる構築も始めない。
ホスティング、サポート、管理責任を予算化して、オープンソースの選択肢を総保有コストで評点している。
臨床的帰結から重要なサービスごとの可用性と回復の目標を設定し、それに支出を一致させている。
既存のものがまだ機能しているうちにレガシーの置き換えを予定し、ビッグバンの切り替えよりも段階的な移行を優先している。
データ移行を早期に費用計上し試験し、各システムの生涯を通じて患者データをエクスポート可能に保っている。
ソフトウェアプログラムを、実装後のレビューを伴う他のあらゆる健康投資と同じ価値の精査に通している。

Key sources

WHO, Global Strategy on Digital Health 2020–2025 — the World Health Organization's frame for digital health investment, including sustainability and interoperability principles.
HL7 International — the FHIR (Fast Healthcare Interoperability Resources) standard, the dominant open standard for health-data exchange.
openEHR, DHIS2, and OpenMRS — open-source health-information platforms and specifications widely deployed worldwide, exemplars of community-sustained health software.
U.S. Office of the National Coordinator for Health IT (now ASTP) — 21st Century Cures Act information-blocking and interoperability rules, a regulatory response to under-supplied interoperability.
DORA, Accelerate State of DevOps reports — long-running research linking software delivery and reliability practices to organizational performance.
UK National Audit Office — reports on the National Programme for IT in the NHS, the canonical case study of large-scale health-IT programme failure.

References

Software engineering — Wikipedia — https://en.wikipedia.org/wiki/Software_engineering
Software maintenance — Wikipedia — https://en.wikipedia.org/wiki/Software_maintenance
Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
Network effect — Wikipedia — https://en.wikipedia.org/wiki/Network_effect
Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
World Health Organization — Global Strategy on Digital Health 2020–2025 — https://www.who.int/publications/i/item/9789240020924
HL7 International — FHIR specification — https://hl7.org/fhir/
National Audit Office — The National Programme for IT in the NHS: an update on the delivery of detailed care records systems — https://www.nao.org.uk/reports/the-national-programme-for-it-in-the-nhs-an-update-on-the-delivery-of-detailed-care-records-systems/
National Programme for IT — Wikipedia — https://en.wikipedia.org/wiki/National_Programme_for_IT