トピック4.1 — プラットフォームと共有サービス

医療・ケアでは、共有プラットフォームはコスト削減のための便宜ではなく、安全、公平性、信頼を再現可能にする方法です。すべてのチームが、しばしばお粗末に再発明する代わりに、それらを引き継げるようにするのです。

医療・ケアにおいてなぜ重要か#

医療・ケアのシステム全体でデジタルのデリバリーを運営していると、同じケイパビリティが何度も作り直されていることに、すぐ気づきます。あらゆるサービスが、患者の認証、人口統計記録の照会、通知の送信、監査証跡の記録、臨床家の役割の確認を望みます。放っておけば、各チームが自前の版を作ります。十数のログイン画面、患者のIDを扱う十数通りの方法、品質がまちまちな十数の監査ログ、そして安全上の欠陥が隠れうる十数か所ができあがります。

この重複は高くつきますが、より深い問題は、それが危険で不公平であることです。医療・ケアでは、配管が臨床リスクを運びます。あるチームの患者照合のロジックが別のチームのものより弱ければ、患者に誤った記録が与えられえます。あるサービスのアクセシビリティが劣っていれば、一部の人々が静かに排除されます。監査証跡が異なれば、情報ガバナンスの調査が止まります。共有プラットフォームは、ケイパビリティを、臨床安全とアクセシビリティの仕事をきちんと行って、高い水準で一度作り、多くのチームが、それぞれが単独で正しくできるかに賭けるのではなく、その水準を引き継げるようにします。

プラットフォームは、システム全体のペースも形づくります。優れたプラットフォームは、難しく汎用的な部分がすでに存在するため、新しいサービスが何年もではなく何週間で患者に届くことを意味します。悪い、あるいは不在のプラットフォームは、すべてのチームが、インフラの全重量を担い、デリバリーが、最も資源の乏しいチームの速さまで遅くなることを意味します。持続的な財政と人員の圧力の下にあるセクターで、同じ国と地域のケイパビリティを何百もの組織が必要とするなか、プラットフォームを正しく整えることは、下せる最もレバレッジの高い決定の一つです。本トピックは、それらをうまく構築し運営する方法についてです。誰も愛さない義務づけられたインフラではなく、実際のユーザーを持つプロダクトとして。

中核概念#

この文脈でのプラットフォームは、他のチームが自前で作るのではなく、その上に構築するケイパビリティの集合です。最も有用な現代的な枠組みは、プラットフォームは、社内のユーザーを持つプロダクトだということです。その顧客は、自組織の開発者、デリバリーのチーム、パートナー組織であり、その成功は、あらゆるプロダクトと同じように測られます。採用、それを使う人々の体験、それが可能にする成果によって。

その下には、いくつかの関連する考え方があります。共有サービスは、ケイパビリティを、それぞれに重複させるのではなく、組織の多くの部分のために一度だけ提供するという、古い組織のパターンです。デジタル公共インフラは、これを社会全体のレベルに拡張したもので、公共サービスと民間サービスが上に築かれる、共有され、再利用可能で、相互運用可能な構成要素（ID、決済、データ交換）です。Tim O'Reillyが作り出し、世界中のデジタル政府のチームが取り上げた「プラットフォームとしての政府（Government as a Platform）」という言葉は、同じ論理を国家に適用します。政府が共通の部品を提供し、各省庁は、それぞれが完全なスタックを構築するのではなく、それらからサービスを組み立てます。

技術的には、プラットフォームは、あるシステムが内部を知らなくても別のシステムのケイパビリティを使える、定義された契約であるアプリケーションプログラミングインターフェース（API）を通じて、そのケイパビリティを提供することがよくあります。クラウドのサービスとしてのプラットフォーム（PaaS）のモデルにしばしば依拠し、共有の国のプラットフォームは、通常、一つのインスタンスが多くの組織に、データと設定を分離したまま仕えるマルチテナンシーに依存します。

プラットフォームが助けになるか害になるかを決める、三つの概念があります。一つ目は認知負荷です。優れたプラットフォームは、デリバリーのチームが頭に保持しなければならない量を減らし、チームが、解決するために存在する臨床やケアの問題に集中できるようにします。二つ目は「舗装された道（paved road）」または「ゴールデンパス」、つまり、門番を通じてではなくセルフサービスで提供される、従うより避けるほうが難しい、よく支えられた、意見のある、一般的なタスクの既定の方法です。三つ目はベンダーロックインの回避であり、組織が法外な乗り換えコストなしにサプライヤー間を移れるよう、プラットフォームはオープン標準の上に構築されるべき理由です。

医療では特に、国の共有サービスがすでに景観の一部です。NHS Connecting for Healthのような過去のプログラムは、Personal Demographics Serviceのような中核データを運ぶ、国のサービスの集合であるNHS Spineを確立しました。現代の同等物には、国のAPI、市民の認証のためのNHS login、メッセージングのためのNHS Notifyがあり、個々のサービスがそれらを作り直さなくてよいよう提供されるケイパビリティです。プラットフォームが、誰かが誰であるかを証明する共通の方法を提供するところでは、臨床家が繰り返さず一度認証すれば済むよう、シングルサインオンを提供することがよくあります。本トピックは、そうしたプラットフォームの構築と運営についてです。自分が誰で、何をしてよいかの詳細はトピック4.2 — IDとアクセスの管理に、システムがデータを交換できるようにする標準はトピック4.3 — 相互運用性とデータ標準に属します。

ベストプラクティス#

1. プラットフォームを、プロジェクトではなくプロダクトとして扱う。 プラットフォームには、終了日と引き継ぎではなく、ロードマップ、プロダクトマネージャー、継続的な資金、満足度を測定するユーザーがいます。プロジェクトは終わって劣化しますが、チームがそれに依存するようになるため、プラットフォームは無期限に運営しなければなりません。それに応じて資金を出し、人員を配置し、これが意味する運用の規律については、トピック5.0 — プロダクト主導の仕事を参照してください。

2. 実用最小限のプラットフォームから始める。 チームを本当に楽にする、共有ケイパビリティの最小の集合を構築し、本物の需要と本物の痛みが正当化するときにのみ、さらに追加します。トピック1.1 — 運用モデルで紹介した、この「実用最小限のプラットフォーム」の考え方は、最もありふれた失敗、つまりすべてをしようとし、遅れて届き、誰にも合わない野心的な中央のプラットフォームを防ぎます。プラットフォームを、アーキテクチャ上の願望からではなく、使われているエビデンスから成長させてください。

3. 舗装された道を、簡単な道にする。 プラットフォームは、セルフサービスのオンボーディング、明確なドキュメント、サンドボックス、臨床安全とアクセシビリティを組み込んだ適切な既定値によって、サポートされた道を、自前で作るより速く簡単にすることで、採用を勝ち取ります。プラットフォームを使うほうが、迂回するより遅く、苦痛なら、チームは迂回し、ボトルネックを作るためにお金を使ったことになります。開発者の最初の1時間と、最悪の日のために設計してください。

4. 存在ではなく、採用とユーザー体験で成功を測る。 正しい指標は、何チームが自ら進んでプラットフォームを使っているか、オンボーディングにどれだけかかるか、プラットフォームがどれだけ頻繁に利用可能か、ユーザーがその体験をどう評価するかです。デプロイされたサービスの数のような虚栄の指標は、チームが助けられているかどうかについて、何も語りません。プラットフォームを計装し、その上に築くチームと定期的にリサーチを行い、下降または停滞する採用曲線を、強制すべきコンプライアンスの問題ではなく、直すべきプロダクトの問題として扱ってください。

5. オープン標準の上に構築し、撤退を安く保つ。 あなた自身も、プラットフォーム上のチームも閉じ込められないよう、オープンで広く採用された標準とインターフェースを優先します。チームがどう離れるかを文書化し、実際に離れられるようにします。逆説的ですが、離れやすくすることこそが、チームを安心して来させ、捕らわれに頼らずその場所を勝ち取らなければならないため、プラットフォームを誠実に保ちます。これは、トピック4.0 — 技術アーキテクチャ、クラウド、レガシーシステムで議論した、より広い環境全体でのベンダーロックインを直接減らします。

6. 誰が払い、誰が決めるかについて明示的にする。 共有プラットフォームには、最初に合意された資金のモデルとガバナンスのモデルが必要です。中央で資金が出るのか、利用者に課金されるのか、ハイブリッドか、そして競合するテナントの間で、ロードマップがどう優先順位づけられるか。ここでの曖昧さこそが、プラットフォームを政治の戦場に変えます。モデルを公表し、ユーザーにロードマップへの本物の発言権を与え、プラットフォームの成長に合わせて見直してください。

7. プラットフォームチームを、明確な責任と境界で運営する。 トピック7.0 — チーム構造、役割、責任のTeam Topologiesのパターンで説明するように、セルフサービスを通じてストリームアラインドなデリバリーチームを可能にすることが仕事の、専任のプラットフォームチームを軸に組織します。プラットフォームと利用者の間のインターフェース、つまりプラットフォームが約束すること、約束しないこと、サポートの得方を明示的に保ち、プラットフォームが門番をするのではなく、可能にするようにします。

8. 最初から、マルチテナンシー、分離、安全のために設計する。 多くの組織が一つのプラットフォームを共有するなら、そのデータ、設定、障害の範囲の分離は、後の機能ではなく、土台となる要件です。医療・ケアでは、これは情報ガバナンスと臨床安全の要件でもあります。一つのテナントのインシデントが、別のテナントの患者を露出させたり危険にさらしたりしてはなりません。分離、テナントごとの観測可能性、プラットフォーム自体のDCB0129に基づく臨床安全性ケースを組み込みます。

チームで話し合うための問い#

1. 私たちのチームを本当に楽にする、最も薄いプラットフォームは何か。そして、構築したくなるが、すべきでないものは何か。 ホワイトボードの上で広大なプラットフォームを設計するのは易しく、チームが愛するものを出荷するのは難しいものです。デリバリーのチームが今日感じている本物の、繰り返される痛み、つまり3つ以上のチームがそれぞれ作り直しているケイパビリティから始め、一つのチームしか必要としない、あるいはまだ誰も頼んでいないものを追加する誘惑に抵抗してください。どのケイパビリティが本当に共通で、どれが遠くからは似て見えるが、臨床的に重要な細部が異なるだけかを問います。間違えたときのコストを考えてください。チームが回避しなければならない、時期尚早な共有ケイパビリティは、プラットフォームがまったくないより悪いものです。プラットフォームが今所有するものと、意図的に先送りするものの明示的な線に合意します。その線を予定に沿って見直し、需要と痛みが示されたときにのみ、項目を移します。規律とは、まだその場所を勝ち取っていない良いアイデアに、ノーと言うことです。

2. テナントの意見が分かれたとき、プラットフォームにどう資金を出し、ロードマップをどう決めるのか。 プラットフォームは、競合する優先事項を持つ多くのチームに仕え、二つの重要なテナントが両立しないものを望んだ瞬間に、ガバナンスが試されます。プラットフォームが、中央で資金が出るのか、利用者に課金されるのか、ハイブリッドなのかを今決め、それぞれのモデルが生む誘因について正直になってください。課金は採用を抑え、中央の資金は、プラットフォームをユーザーのニーズから切り離しかねません。誰がロードマップを握り、テナントがどう影響を与え、大規模な組織の緊急のニーズと小規模な組織の基本的なニーズの間をどう裁定するかを決めます。課金モデルは、より小さく貧しい組織を、共有の安全ケイパビリティから値段で締め出しうるため、公平性を明示的に考慮してください。ほかのテナントが望まない機能に資金を出したいテナントを、どう扱うかに合意します。モデルを書き出して公表し、決定がえこひいきではなくガバナンスに感じられるようにします。そして、プラットフォームとそのユーザー基盤が成長するなかで、それを見直すことにコミットしてください。

3. プラットフォームが義務づけられているだけでなく愛されていることを、どうやって知るのか。そして、そうでなければ何をするのか。 プラットフォームは、技術的に健全で、公式に必須で、静かに嫌われていることがありえます。義務づけられたが愛されていないプラットフォームは、回避策、影のシステム、恨みを蓄積します。何のシグナルが真実を教えてくれるかを、あらかじめ決めてください。チームに選択肢があるところでの自発的な採用、新しいチームが最初の成功に至るまでの時間、可用性とインシデントの履歴、それを使う開発者からの直接のフィードバック。ユーザーに対して権力も握っているとき、誠実なフィードバックをどう集めるかを話し合います。人々は、使うことを求められているプラットフォームを批判したがらないからです。健全な採用曲線がどう見えるか、どんな閾値が真剣な再考を引き起こすかに合意します。エビデンスが求めるなら、プラットフォームを廃止したり置き換えたりする意思があるかを決めます。自分のプラットフォームが機能していないと聞く意思こそが、それを機能させ続けます。代替案は、大きなサービスがあなたを迂回したときに初めて真実を発見することです。

4. 撤退をどう安く保つか。そして、必要なら、私たちのプラットフォーム上のチームは実際に離れられるか。 オープン標準の上に構築されていると主張するのは易しく、チームが法外な書き直しなしに立ち去れることを証明するのは、別のことです。ロックインが忍び寄る箇所、つまり独自仕様のインターフェース、文書化されていないデータ形式、代替のない国への依存について、そして離れるコストが、時間とともに静かに上がっていないかを、正直に話してください。撤退の経路が存在すると想定するのではなく、それを文書化し、定期的にテストする責任者を決めます。医療・ケアでは、ロックインのリスクが複利で積み上がることを考えてください。捕らわれの上に築かれた国のプラットフォームは、システム全体を一世代にわたって閉じ込めえ、乗り換えのコストを最も吸収しにくいのは、通常、最も小さな提供者です。誠実な答えは、解きほぐすのに苦労する具体的な依存関係を挙げ、少なくとも一つの実際のテナントのための具体的な撤退を説明し、移植性を、繰り返すスローガンではなく、維持する機能として扱います。離れやすくすることが、しばしば、チームを安心して来させることを思い出してください。

5. プラットフォームは自らの臨床安全性ケースを持っているか。そして、一つのテナントの失敗が別のテナントの患者を害するのを、どう防ぐか。 多くの組織が一つのプラットフォームを共有するとき、その配管は、その上に築かれたすべてのサービスのために臨床リスクを運ぶため、患者照合の欠陥やテナント間の漏えいは、一つのチームの問題ではなく、全員の問題です。プラットフォームが、利用するチームが本当に頼れる、自前のDCB0129の安全性ケースを持っているのか、それとも各サービスが、同じ共有のリスクを静かに再評価しているのかを決めてください。テナントのデータ、設定、障害の範囲をどう分離し、その分離が破られたとしたらどうやって知るかを議論します。テナントごとの観測可能性が、インシデントを封じ込めることと、遅れて発見することの違いです。情報ガバナンス上の帰結も考えます。一つのテナントについての調査が、別のテナントの記録を露出させることを要してはなりません。誠実な答えは、維持された安全性ケース、テスト済みの分離の境界、そしてプラットフォームが安全について約束することと、各サービスの責任として残ることの明確な説明を示せます。安全と分離を、後の機能ではなく土台として扱うことが、チームが、アシュアランスに賭けるのではなく、引き継げるようにします。

6. プラットフォームチームと、それが仕えるチームの間の線はどこにあるか。そして、プラットフォームがボトルネックになるのをどう防ぐか。 共有プラットフォームは、すべてのチームを加速することも、すべてを一つの中央のキューの速さまで遅くすることもでき、その違いは、プラットフォームと利用者の間のインターフェースを、どれだけ鋭く引いたかにあります。プラットフォームが所有し約束すること、明示的に約束しないこと、そして日常の仕事でチケットを待たずにチームがサポートを得る方法を決めます。セルフサービスを既定として話し合ってください。オンボーディング、プロビジョニング、一般的な変更のすべてに、プラットフォームチームが手作業で動く必要があるなら、舗装された道ではなく、関門を作ったことになります。優れたプラットフォームの核心にある、認知負荷の取引を考えます。デリバリーのチームが頭に保持しなければならないものを減らして臨床の問題に集中させるべきで、交渉すべき新たな層を加えるべきではありません。誠実な答えは、ボトルネックとしてまだプラットフォームチームを通る仕事を挙げ、それらをセルフサービスにする方向を定め、プラットフォームが可能にしている箇所と、門番をしている箇所について率直です。

実践例：医療・ケアの事例#

複数のNHSトラスト、コミュニティの提供者、県議会の成人社会的ケアサービスをカバーする統合ケアシステム（ICS）は、同じ壁に何度もぶつかります。新しいデジタルサービス、つまりバーチャルウォード、コミュニティ理学療法の自己紹介フォーム、介護施設の監督ツールは、どれも最初の3か月を、患者が誰かの証明、専門職の役割の確認、SMSリマインダーの送信、監査証跡の記録という、同じ土台の作り直しに費やします。バーチャルウォードチームの患者照合は、理学療法チームのものより弱いことがわかり、リマインダーが誤った人に送られるヒヤリハットが起きます。ICSのデジタルリーダーシップは、そのパターンを認識します。一度だけ存在すべきケイパビリティのために、何倍も払っており、そのばらつきは安全上のリスクです。

壮大なICSプラットフォームを発注するのではなく、彼らは薄く始めます。一つのことをうまく行う単一の共有サービスを立ち上げます。NHS loginと国のPersonal Demographics Serviceを、サンドボックス付きの、きれいで文書化されたAPIの背後に包み、どのチームでも、一つのサポートされた経路を通じて、市民のIDを検証し、確認済みの人口統計記録を取得できるようにします。5人の小さなプラットフォームチームが、それをプロダクトとして扱います。舗装された道のガイドを公開し、セルフサービスのオンボーディングを提供し、新しいチームが1日以内に最初の成功した呼び出しを行うべきという目標を設定します。決定的に、義務づけません。最も簡単な選択肢にし、バーチャルウォードチームに、最初の自発的な採用者になってもらいます。

資金のモデルは、オープンに合意されます。ICSは、課金による採用の抑制を避けるため、最初の2年間、プラットフォームの中核に中央で資金を出し、18か月でレビューします。議会を含む、提供者をまたぐグループがロードマップを握り、毎月会合します。次に理学療法チームが通知のケイパビリティを求めたとき、プラットフォームチームは、メッセージングをゼロから構築するのではなく、NHS Notifyを包む薄いラッパーを追加します。一度作って、多くが使う。1年以内に6チームがIDサービスを自発的に採用し、オンボーディングは数か月から数日に短縮され、プラットフォームチームは、可用性と採用の数字をオープンに公表します。あるトラストの特注システムがプラットフォームを迂回したとき、チームはそれを反抗ではなくリサーチとして扱い、その判断を促した摩擦を学び、直します。チームが選ぶからプラットフォームは成長し、ICSは、リスクのある一般的なことを行う、単一の、よくテストされ、アクセスしやすい方法を引き継ぎます。

セクター別の視点#

スタートアップ#

ヘルステックのスタートアップが、他者のためのプラットフォームを作ることはまれで、その上に構築します。その梃子は、国とクラウドのプラットフォーム、つまりNHS login、国のAPI、クラウドプロバイダーのマネージドサービスを利用することから生まれ、小さなチームは、IDやメッセージングを再発明するのではなく、臨床の問題にエネルギーを使えます。それでもロックインに注意してください。オープン標準を選び、データを移植可能に保ちます。今日安く借りているケイパビリティが、明日あなたを縛る依存関係になりえるからです。社内では、自前の「プラットフォーム」を、ほとんど見えないほどに薄く保ちます。2人のチームにゴールデンパスの抽象化は必要なく、出荷することが必要です。規律とは、共有の社内ケイパビリティを切り出す価値があるほど成長したときを知ることです。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、単独拠点のクリニックは、ほとんど常に、自前のデジタル能力がほとんど、あるいはまったくない、プラットフォームの利用者であり、そのため、依存するプラットフォームが、事実上、その安全と公平性の床を決めます。実務上の仕事は、人員を配置も維持もできない特注の構築より、サポートされた共有サービスを選ぶことです。単独では決して資金を出せない、アクセシビリティと臨床安全の仕事をすでに担っている、NHS login、人口統計の照会、NHS Notifyといった国のケイパビリティを優先します。エスカレーションできるプラットフォームチームがなく、長い連携プロジェクトを負担できないため、本物のセルフサービスのオンボーディングと明確なドキュメントにこだわってください。資金のモデルを注意深く見ます。課金制のプラットフォームは、小規模な提供者を、最も必要とするまさにその安全ケイパビリティから値段で締め出しうるため、公平なアクセスを求め、届くあらゆるロードマップのガバナンスで、それを提起してください。撤退にも目を配ります。独自のサプライヤーへのロックインは、移行を担う社内の技術職員がいないとき、最も抜け出しにくいからです。得られるのは、優れた共有プラットフォームが、自分では築けない標準を引き継がせてくれ、大規模な組織と同じ義務を、その資源なしに満たせることです。

大企業#

大規模なトラストや国の機関は、本物のプラットフォームを正当化できる規模と、それを台無しにしうる官僚制を持っています。リスクは、象牙の塔になる中央のプラットフォームチームです。アーキテクチャとしては優雅だが、応答が遅く、仕えるはずのデリバリーのチームから切り離されています。これに対抗するには、プラットフォームを、独自のロードマップとユーザーリサーチを持つ長寿のプロダクトとして資金を出し、義務の遵守ではなく、採用と開発者体験で測定します。マルチテナンシー、分離、プラットフォーム自体の臨床安全性ケースは、この規模では不可欠です。得られるものは巨大です。高い水準で一度作られ、数十のサービスが引き継ぐケイパビリティが、組織全体の床を引き上げます。

政府#

国とシステムのレベルでは、枠組みはデジタル公共インフラとプラットフォームとしての政府です。ID、通知、人口統計の照会、データ交換といった、何百もの組織がサービスへと組み立てる共通の部品を構築します。ここでは、独自仕様のロックインの上に築かれた国のプラットフォームが、医療システム全体を一世代にわたって閉じ込めうるため、オープンさの利害が最も高くなります。ガバナンスと資金は、共有プラットフォームが部分的にそれを守るために存在する、より小さく貧しい組織に本物の影響力を持たせて、オープンに練り上げなければなりません。義務づけたい誘惑は、このレベルで最も強く、最も危険です。義務づけられているが愛されていない国のプラットフォームは、全国に影のシステムを生みます。品質とサポートを通じて採用を勝ち取り、あらゆる回避策を、改善すべきシグナルとして扱ってください。

よくある失敗パターン#

• ボトルネック。 すべてのチームが、何かをするのに中央のプラットフォームチームを待たなければならず、プラットフォームがデリバリーを加速するのではなく遅くする。対策はセルフサービス。チームが、チケットなしにオンボードし、行動できるようにする。
• 象牙の塔。 プラットフォームが、デリバリーから遠い人々によって設計され、技術的には立派だが、どの実際のチームのニーズにも合わない。対策は、継続的なユーザーリサーチを伴うプロダクトとして運営すること。
• 義務づけられたが愛されていない。 プラットフォームが方針で求められるが、実際には迂回され、影のシステムと恨みを蓄積する。対策は、品質を通じて採用を勝ち取り、チームがあなたを迂回したときに耳を傾けること。
• 何でもありのプラットフォーム。 野心的すぎる範囲が、プラットフォームを遅れて届け、やりすぎて、何もうまくできなくする。対策は、需要のエビデンスから成長させた、実用最小限のプラットフォーム。
• こっそりのロックイン。 プラットフォームがチームを独自のサプライヤーやインターフェースに静かに結びつけ、離れるコストが法外になる。対策は、オープン標準と、文書化されテストされた撤退の経路。
• 資金の曖昧さ。 誰が払い、誰が決めるかを誰も合意せず、プラットフォームが飢えるか、政治の戦場になる。対策は、明示的で公表された資金とガバナンスのモデル。
• 後回しの安全。 プラットフォームに自前の臨床安全性ケースがなく、利用するすべてのサービスが、評価されていないリスクを引き継ぐ。対策は、プラットフォームのDCB0129の安全性ケースを、土台として扱うこと。

成熟度モデル#

チェックリスト#

• プラットフォームに、名前のあるプロダクトマネージャー、ロードマップ、（プロジェクトではなく）継続的な資金がある。
• 実用最小限のプラットフォームから始め、意図的に先送りしたものを挙げられる。
• サポートされた道が、チームが自前で作るより、本当に速く簡単である。
• 新しいチームが、サンドボックスと明確なドキュメントを備えた、セルフサービスでオンボードできる。
• 採用、最初の成功までの時間、可用性、開発者体験を測定している。
• 資金のモデル（中央、課金、ハイブリッド）が合意され、公表されている。
• ロードマップのガバナンスが、より小さな組織を含むテナントに、本物の発言権を与えている。
• プラットフォームがオープン標準の上に構築され、文書化された撤退の経路がある。
• マルチテナントのデータと障害の分離が、後付けではなく設計に組み込まれている。
• プラットフォームに、利用するチームが頼れる、自前の臨床安全性ケース（DCB0129）がある。
• プラットフォームを迂回するチームを、反抗ではなくリサーチとして扱っている。

主要な情報源#

• GOV.UK Service Manualと、プラットフォームとしての政府と共通部品についてのGovernment Digital Serviceの文章。
• Matthew SkeltonとManuel Pais, Team Topologies — プラットフォームチーム、実用最小限のプラットフォーム、認知負荷。
• NHS Englandの開発者向けとAPIのガイダンス（NHS login、NHS Notify、国のAPI、Spineサービス）。
• 医療ITシステムのための、DCB0129とDCB0160の臨床リスクマネジメント標準。
• デジタル公共インフラと再利用可能な公共の構成要素についての、世界銀行と国連の文書。
• Tim O'Reilly, 「Government as a Platform」, Open Government (O'Reilly Media)所収。

参考文献#

1. Digital public infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — Wikipedia — https://en.wikipedia.org/wiki/API
4. Platform as a service — Wikipedia — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — Wikipedia — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — Wikipedia — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation