トピック1.0 — デジタルヘルス・ケアにおける仕事の進め方

一文で言うと： *仕事の進め方（ways of working）*とは、チームの編成、意思決定、リスク管理、価値の提供といった、意図的に共有された習慣のことであり、それによって医療・ケア組織は、意図を、患者と市民にとって安全で公平でエビデンスに基づく成果へと変えられます。

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

どの組織にも仕事の進め方はあります。選んだものであれ、受け継いだものであれ。デジタルヘルス・ケアでは、受け継いだ進め方はたいてい仕事に合っていません。それらは、範囲が固定された建設型のプロジェクトのために作られたもので、臨床安全、法定義務、公費に関わる適応的なサービスのためのものではないからです。これを正しく整えることは、バックオフィスの気配りではありません。臨床家が信頼する共有ケア記録と、使われないまま放置される共有ケア記録とを分ける違いです。

医療・ケアには、本書のあらゆるプラクティスを形づくる特徴があります。安全は譲れません。デジタルサービスの欠陥は患者を傷つけうるため、臨床リスクマネジメント（トピック1.6 — 臨床安全とリスクマネジメント参照）は後付けではなく、デリバリー全体に織り込まれます。公平性が重要なのは、デジタルに自信のある人にしか使えないサービスは健康格差を広げるからです。Core20PLUS5の集団やデジタル環境の限られた人々は、設計から外すのではなく、設計の対象にしなければなりません。法定義務、つまり包括的ケアへのNHSの約束、データ保護法、守秘義務は、データでできることと、協議の進め方を制約します。公費は、適切な支出管理と、実証可能な価値を求めます。そして、ほとんどのものは一つの組織だけで提供されることはありません。統合ケアシステム（ICS）、地方自治体、社会的ケア提供者、サプライヤーをまたぐパートナーシップが、通常の運用条件です。

この4つの圧力、つまり安全、公平性、義務、資金があるからこそ、消費者向けテクノロジーの手法をそのまま写すことはできません。アジャイルかつ説明可能、迅速かつ安全、ユーザー中心かつ集団として公正な仕事の進め方が必要です。

中核概念#

仕事の進め方は3つのレベルで働きます。チームレベルでは、日々のプラクティスです。スタンドアップ、ユーザーリサーチ、反復的デリバリー、ペアリングなどです。組織レベルでは運用モデルであり、戦略がバリューストリーム、ケイパビリティ、資金、意思決定権へとどう変わるかを指します（トピック1.1 — 運用モデル参照）。システムレベルでは、独立した組織がどう足並みをそろえるかであり、ICS全体での共通標準、相互運用性、共通のガバナンスです。本書は意図的にこの3つすべてを横断します。

**ユーザー中心設計**とは、想定した解決策からではなく、サービスを使う人々（患者、介護者、臨床家、事務担当者）のニーズから出発することです。英国のGovernment Digital Service（GDS）とNHSは、これをサービス標準として成文化しました。作る前にユーザーとそのニーズを理解し、その後も実際のユーザーでテストし続けます。

**アジャイルで反復的なデリバリー**とは、動くサービスを早い段階で実際のユーザーの前に出し、学び、適応することです。すべてを最初に仕様化するのとは対照的です。NHSデジタルサービスマニュアルは、アジャイルでユーザー中心の仕事の進め方が、誤ったものを作るリスクを下げると明記しています。ここでのアジャイルは、デリバリー手法であると同時にリスクマネジメントの戦略でもあります。

**多職種チーム（MDT）**は、サービスに必要なスキルの組み合わせを、一つの権限を持つチームに集めます。プロダクトとデリバリーの管理、ユーザーリサーチとデザイン、エンジニアリング、臨床と情報ガバナンスの専門性、運用の知識です。NHSのサービス標準は、多職種のスキルと視点を含むチームを求めており、そこには臨床、法務、政策の専門的助言へのアクセスも含まれます。MDTはデジタルデリバリーの原子であり、失敗の多くは、食卓に欠けていた専門分野にさかのぼれます。

プロジェクトよりプロダクト。 プロジェクトには始まりと終わりと引き継ぎがあります。一方プロダクトは、ライフサイクル全体にわたって資金が付き、育てられます。プロジェクト思考からプロダクト思考への転換（トピック1.1およびトピック5.0 — プロダクト主導の仕事参照）は、資金、チーム、説明責任を変えます。長寿で継続的に進化する医療サービスには、単発のプロジェクトよりはるかに適しています。

ベストプラクティス#

1. リサーチで裏づけられたユーザーのニーズから始める。 構築を決める前に、ユーザーが誰で、何をしようとしていて、現在のサービスのどこで行き詰まっているかを理解します。ディスカバリー（トピック3.4 — ディスカバリーフェーズ参照）に資金を出し、「〜と想定した」は危険信号として扱います。内部の好みではなく、ユーザーのニーズが、その後のあらゆる判断の錨になります。

2. 多職種で、権限を持ち、安定したチームをつくる。 臨床安全と情報ガバナンスを含む、スキルの組み合わせ全体を集め、明確なガードレールの中で決定する権限をチームに与えます。プロジェクトの区切りごとに解散するのではなく、サービスを軸にチームを保ちます。安定したチームは、医療サービスが求める領域知識と安全知識を蓄積します。

3. オープンに働き、小さな歩みで反復する。 薄いスライスを出荷し、測定し、調整します。小さく頻繁なリリースは、ビッグバン型のローンチより安全です。問題が小さいうちに表面化し、臨床安全と情報ガバナンスのレビューが、最後の関門になるのではなく変化に歩調を合わせられるからです。

4. 安全と公平性を初日から第一級に扱う。 臨床リスクマネジメント（DCB0129/DCB0160）と、平等・健康格差の分析を、最終段階の承認ではなく、デリバリーと並行して実施します。誰が排除されたり害を受けたりしうるかを早期に問い、最も困難なケースを想定して設計します。支援付きデジタルの経路、アクセシビリティ（WCAG）、オフラインの代替手段などです。

5. エビデンスで決め、決定を記録する。 臨床エビデンス（効果があり安全か）とデリバリーのエビデンス（うまく作れていて、使われているか）を区別し、担当者が入れ替わっても根拠が残るよう、軽量な意思決定ログを保ちます（トピック1.3 — エビデンスに基づく意思決定参照）。エビデンスは、最も報酬の高い人の意見に勝ります。

6. 相互運用性と再利用のために設計する。 医療・ケアのデータは、組織間で安全に流れなければなりません。オープン標準（HL7 FHIR、SNOMED CT）で構築し、プラットフォームを作り直さずに再利用します（トピック1.1の「実用最小限のプラットフォーム」と、トピック4.3 — 相互運用性とデータ標準を参照）。データを共有できないサービスは、リスクになるのを待つサイロです。

7. 比例的にガバナンスを効かせる。 アシュアランスの重さを、リスクの水準に合わせます。高リスクの臨床変更には深い精査が必要です。低リスクのコンテンツ変更が、委員会のために数週間待つべきではありません。比例的なガバナンスは、安全と速さの両方を保ちます。

8. オープンに働く。 計画、意思決定、ロードマップ、そして安全な場合はコードを共有し、パートナー、臨床家、市民が、選択がどのように、なぜなされるかを見られるようにします。オープンさは信頼を築き、分断されたシステム全体での重複を減らし、誤りが稼働中のサービスに固まる前に異議を呼び込みます。医療・ケアでは、サービスがデータで何をするか、なぜそうするかを透明にすること自体が、信頼と安全の実践です。

9. 長期と引き継ぎのために設計する。 医療のデジタルサービスは、それを作るチームや契約より長く続きます。したがって決定を記録し、文書化されていない「ヒーロー」の知識を避け、何年もサービスを運用し変更する人々のために設計します（トピック10.3 — ナレッジマネジメントとドキュメンテーション参照）。チーム、技術、資金モデルの持続可能性は、後回しにせず、第一級の制約として扱ってください。

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

1. 私たちの現在の仕事の進め方のうち、選んだものではなく受け継いだものはどこで、その受け継いだ習慣のうち、安全、公平性、無駄な支出の面で最もコストがかかっているのはどれか。 この問いは、誰も決めていないのに全員が従っている慣行、つまり範囲固定のプログラム資金、解散と再編を繰り返すプロジェクトチーム、稼働直前にだけ意見を聞くガバナンスを、正直に点検させます。受け継いだ習慣は、名前を付けるまで見えないのが普通であり、医療・ケアでは実際のコストを伴うため、これが重要です。臨床家が信頼しない共有記録、Core20PLUS5の集団を排除するサービス、公費で同じログイン基盤を作り直すことなどです。議論すべき緊張は、受け継いだやり方は、なじみがあり監査しやすいからこそ安全に感じられ、そのため廃止がリスクの除去ではなくリスクの引き受けに見えることです。意見の応酬ではなく、具体的な成果物に根ざして議論してください。直近3件のビジネスケース、プロジェクト間のチームの離職、臨床安全が最初に関与した時期を見ます。良い答えは、コストを示す証拠とともに一つか二つの具体的な習慣を挙げ、残す価値のあるものと成果を積極的に損なっているものを区別し、上級リーダーが責任を負う変更にコミットします。

2. 私たちのチームは、臨床安全と情報ガバナンスを含む、多職種のスキル構成の全体を本当にチームの内側に持っているのか、それとも、それらの専門分野はまだ最終段階の関門として後付けされているのか。 本トピックは、MDTがデジタルデリバリーの原子であり、失敗の多くは食卓に欠けていた専門分野にさかのぼれると論じます。この問いは、その原則が組織で現実のものなのか、願望にとどまるのかを試します。稼働直前にしか関与しない臨床安全責任者やCaldicott Guardianは、手戻りか危険な近道のどちらかを強いますが、初週から組み込まれていれば、デリバリーのペースを決める生きたハザードログを維持できます。浮き彫りにすべきトレードオフは、コストと希少性です。臨床、法務、IGの専門家の時間は実際に限られているため、「全員をすべてのチームに組み込む」は現実の資源制約とぶつかり、チームは、兼務や共有の役割が許容される場所とされない場所を決めなければなりません。現行のサービスを取り上げて、常設チームに実際にいる人と、外部の承認として相談を受ける人を対応づけ、チームにガードレール内で決定する権限があるのか、絶えずエスカレーションしなければならないのかを確かめます。誠実で良い答えは、どの専門分野が欠けている、または借り物なのかを具体的に述べ、資源の緊張を率直に認め、希少性を否定せずに穴を埋める具体的なモデル（常勤、兼務、待機）を提案します。

3. デジタルサービスを、ライフサイクル全体にわたって育てるプロダクトではなく、引き継ぎ付きのプロジェクトとして扱ったのはいつで、それによって領域知識と安全知識をどれだけ失ったか。 プロダクトをプロジェクトより優先することは、本トピックの柱となる転換の一つであり、この問いは、継続ではなく終結のために資金を付け人を配置している場所に、チームを向き合わせます。医療サービスは長寿で継続的に進化するため、これが重要です。プロジェクトの区切りで解散したチームは、サービスを安全に保つまさにその蓄積された臨床・運用知識を持ち去り、「パイロット煉獄」がその繰り返し現れる症状です。本当の緊張は財務と構造にあります。プロダクトへの資金は常設の予算を要し、財務とガバナンスが前提とする年次入札と期間限定のモデルに挑戦するため、これはデリバリーと同じくらい、資金と説明責任をめぐる会話です。引き継ぎを経た具体的なサービスを一つ取り上げ、そのハザードログ、ユーザーリサーチ、チームに何が起きたかをたどり、プロダクト資金が求める規律と比べてください。良い答えは、具体的な事例を挙げ、失われた知識を定量化するか、少なくとも特徴づけ、常設のプロダクトチームを標準にするためにどの組織的障壁（資金サイクル、リソース規則、ガバナンス構造）が動かなければならないかを率直に述べます。

4. 私たちが作るサービスから最も排除されたり害を受けたりしやすいのは誰か、そして、その人々のために最後ではなく最初に設計した箇所を示せるか。 本トピックは、公平性は譲れないものであり、デジタルに自信のある人にしか機能しないサービスは健康格差を広げると主張します。この問いは、「最も困難なケースを想定して設計する」が生きた実践なのかスローガンなのかを試します。医療・ケアでの排除は不便ではなく、安全とアクセスへの害だからです。Core20PLUS5の集団、デジタル環境の限られた人、ヘルスリテラシーの低い人、スマートフォンのない人は、まさにニーズが最も大きい人々であり、彼らを設計から外すサービスは、最も負担できない場所に害を集中させます。浮き彫りにすべき緊張は、周縁のために設計することは、前もって時間と費用がかかるということです。支援付きデジタルの経路、WCAG準拠のアクセシビリティ、オフラインや非デジタルの代替手段、翻訳です。納期が迫り、自信のある多数派がすでに使えるときには、これらのコストは先送りしやすいものです。実際のサービスを見て、そのユーザーリサーチのサンプルに誰が含まれているか、平等・健康格差の分析が実際に設計上の判断を形づくったか、オンラインに行けない、または行かない人に何が起きるかを問います。誠実な答えは、このサービスで危険にさらされる具体的な集団を挙げ、その人々のためになされた具体的な設計上の選択を少なくとも一つ示し、圧力の下でインクルージョンを手放した箇所と、次回それをどう擁護するかを率直に述べます。

5. すでに存在する基盤を作り直している箇所はどこで、オープン標準での構築と共有プラットフォームの再利用は、実際に私たちが出荷するものをどこで変えるか。 相互運用性と再利用のための設計は、本トピックのベストプラクティスの一つであり、この問いは、再利用ではなく特注で作ろうとする引力にチームを向き合わせます。ログイン、通知、記録統合といった、ほかの十数チームも作ってきたものです。分断されたシステムでは、作り直されるすべての部品は公費の二重払いであり、データを安全に交換できない新たなサイロなので、これが重要です。逆に、HL7 FHIRやSNOMED CTで構築し、実用最小限のプラットフォームを再利用することこそが、サービスが調達を通過し、ICS全体でデータを共有できるようにします。真のトレードオフは、再利用は依存を意味することです。共有プラットフォームは遅く、個別対応が少なく、他者のロードマップに支配されるかもしれず、チームは共有部品の抵抗を、特注サイロの長期的なコストとリスクと比べなければなりません。現在の構築物を調べ、本当に新しいものと、既存のプラットフォーム、標準、オープンな部品と重複するものを列挙し、「それは再利用できない」が証拠に基づく制約なのか、検証されていない思い込みなのかを確かめます。良い答えは、作る価値のある部分と再利用する価値のある部分を区別し、提供されているプラットフォームの成熟度とガバナンスについて正直であり、データ交換が必要なものにはオープン標準を約束します。

6. ガバナンスの重さをリスクの水準にどう合わせているか、そして現在、アシュアランスが低リスクの変更に対して重すぎる、または高リスクの変更に対して軽すぎる箇所はどこか。 比例的なガバナンスは本トピックの柱となる考え方です。高リスクの臨床変更には深い精査が必要で、低リスクのコンテンツ変更が委員会のために数週間待つべきではありません。この問いは、組織がアシュアランスをリスクに合わせて調整しているか、すべてに一つの鈍いプロセスを当てているかを試します。誤って設定されたガバナンスは、両方向に害を及ぼすため、これが重要です。一律で重い関門は、チームに変更をまとめさせ、サービスを安全に保つまさにその反復を遅くします。一様に軽い対応は、本当に高リスクの臨床変更を、必要な臨床安全と情報ガバナンスの精査なしに通してしまいます。緊張は、比例性には判断が必要であり、リスク階層化された経路より単一の必須チェックリストの方が弁護しやすいと感じる取締役会や監査人にとって、判断は居心地が悪いことです。直近の十数件の変更がどうアシュアランスされたかを見て、実際の臨床・データリスクで並べ替え、費やされた労力がリスクに従ったのか、カレンダーに従ったのかを確かめてください。誠実な答えは、過剰なガバナンスと不足したガバナンスの両方の具体例を挙げ、リスクで変更を階層化する明確な基準を提案し、階層を決める権限と、その責任を負う人を特定します。

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

ある統合ケアシステムが、3つの急性期トラスト、コミュニティサービス、地方自治体の社会的ケアの臨床家に共有ケア記録を提供したいと考えています。従来のやり方なら、範囲固定のプログラムを発注し、すべての画面を最初に仕様化し、統合を最後に行うでしょう。

代わりにICSは多職種チームを編成します。プロダクトマネージャー、デリバリーマネージャー、ユーザーリサーチャー、インタラクションデザイナー、エンジニア2名、臨床安全責任者、情報ガバナンスリードに加え、Caldicott Guardianと社会的ケアの実務者にもアクセスできます。彼らは8週間のディスカバリーを行い、地域看護師、救急外来の専門医、ソーシャルワーカーが、現在どのように情報を探そうとしているかを観察します。そして、本当の痛みは「データがない」ことではなく、「データの鮮度を信頼できない」ことだと気づきます。

チームは絞り込んだアルファ版を出荷します。一つの臨床経路について、アレルギー、薬剤、現在のケアプランの状況への閲覧専用アクセスで、見える形の「最終更新」の表示を付けます。臨床安全は並行して進み、ハザードログは初週から維持されます。臨床家が情報の確認のために他チームへ電話をかけなくなるかどうかを測定します。この薄いスライスが価値があり安全であると証明されて初めて、記録を広げます。閉じたプロジェクトではなく、継続的なプロダクトとして資金を付けて。

セクター別の視点#

同じ4つの圧力、つまり安全、公平性、義務、資金は、あらゆる組織に及びますが、それに答える仕事の進め方は、規模、資金、説明責任に応じて変わります。

スタートアップ#

小さなデジタルヘルス企業は、フォーカスで生き死にが決まるため、その仕事の進め方は必然的に無駄がありません。一つの多職種チーム、フラットな意思決定、ユーザーとの日々の接触です。制約は人員の規則ではなくランウェイなので、ディスカバリーは週単位で測り、エビデンスは安価に集めます。数件の臨床インタビュー、クリック可能なプロトタイプ、兼務の臨床安全責任者が付ける誠実なハザードログです。危険なのは、投資家向けのマイルストーンに間に合わせるために、安全と情報ガバナンスの厳密さを飛ばすことです。精査に耐える規律とは、DCB0129とデータ保護影響評価を、トラストに求められるまで先送りする書類仕事ではなく、パイロットの参入条件として扱うことです。初日からの相互運用性（FHIR、SNOMED CT）も商業上の資産です。データを交換できないスタートアップはNHSの調達を通過できないからです。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設や訪問介護事業所、単独拠点のクリニック、プレ収益段階を過ぎた小規模なヘルステックのサプライヤーは、大きなトラストと同じ安全、公平性、義務、資金の圧力を、その何分の一かの能力で負っています。ここでの仕事の進め方は、徹底して比例的でなければなりません。専任のデジタルやIGのチームはまずなく、「多職種チーム」は、いくつもの役割を兼ねる数人に、共有または外部委託の臨床安全・データ保護のリソースを加えたものになります。罠は、法定義務が組織の規模に合わせて縮小すると思い込むことです。縮小しません。DCB0129/DCB0160の臨床安全、データ保護影響評価、アクセシビリティは、一人の診療所マネージャーがすべてに責任を負うときでも、完全に適用されます。実務上の規律は、作るのではなく再利用に強く頼ることです。認定された既製システムを採用し、サプライヤーにDTACとオープン標準（FHIR、SNOMED CT）を満たすよう求め、国やICSが提供するプラットフォームを使って、安全、相互運用性、情報ガバナンスが、乏しい予算で作り直すのではなく継承されるようにします。

大企業#

NHSトラストやICSは、逆の問題を抱えています。プロセスが豊富で、所有が分断されているのです。ここでの仕事の進め方は、新しい実践の採用と同じくらい、学び捨てにかかっています。範囲固定のプログラムの習慣を手放し、解散と再編を繰り返すプロジェクトチームをやめることです。説明責任は公式かつ個人的であり（上級責任者、Caldicott Guardian、取締役会レベルの臨床安全承認）、したがって成果は、それらの役割を関門として後付けするのではなく、デリバリーチームの内側に組み込むことにあります。大規模なヘルステックや製薬のサプライヤーは鏡像の問題に直面します。エンジニアリングの成熟度は高いが、臨床の現場の現実から距離があることです。実際の臨床家の時間を持つ多職種チームは、それを埋めるために存在します。

政府#

NHS England、DHSC、UKHSA、地方自治体といった国または地方の公的機関は、他のすべての人が従う標準を定めるため、その仕事の進め方は外へ波及します。その説明責任は議会と国民に対するものであり、透明性、支出管理、公平性の水準を引き上げます。サービス標準、公表されたアシュアランスの経路、Core20PLUS5の責務は、その説明責任の道具であり、任意の付け足しではありません。この規模でのリスクは、存在しない平均的な市民のために中央で設計し、地域のニーズを理解する前に解決策を義務づけることです。是正策は、他の場所と同じユーザー中心で反復的な規律であり、連合した組織が上に築けるオープン標準と再利用可能なプラットフォームを定めることを重視して適用します。サービスを提供するだけでなく、システムを統治するのです。

よくある失敗パターン#

• 解決策ありきのデリバリー。 ニーズを理解する前に、特定のプロダクトにコミットする。対策：ディスカバリーに資金を出し、ユーザーのニーズを構築の入り口基準にする。
• 遅い関門としてのガバナンス。 臨床安全と情報ガバナンスに稼働直前にしか相談せず、手戻りや危険な近道を強いる。対策：初日から両方をチームに組み込む。
• プロジェクトの入れ替わり。 チームを立ち上げては解体し、苦労して得た領域知識と安全知識を失う。対策：プロダクト資金と常設チーム。
• パイロット煉獄。 導入、研修、業務変革に資源が割かれなかったために、拡大しない終わりなきパイロット（トピック8.1 — 変更管理参照）。対策：パイロットの前に、拡大への道筋を計画する。
• 後回しの公平性。 自信のある多数派のために設計し、最もケアを必要とする人々を排除する。対策：最も困難なケースを先に想定して設計する。

成熟度モデル#

チェックリスト#

• すべてのサービスに、臨床安全と情報ガバナンスのスキルを備えた、名前の付いた安定した多職種チームがある。
• ディスカバリーで裏づけられたユーザーのニーズなしに、構築は始まらない。
• 臨床リスクマネジメント（DCB0129/DCB0160）が初日から、生きたハザードログとともに動いている。
• 公平性・健康格差の分析が行われ、支援付きデジタルの経路が存在する。
• デリバリーは、小さく頻繁で測定可能なスライスで進む。
• 意思決定は記録され、臨床のエビデンスとデリバリーのエビデンスが区別されている。
• サービスはオープンな相互運用性標準で構築され、共有プラットフォームを再利用している。
• ガバナンスの重さはリスクに合わせられ、チームに知られている。
• 研修と変革を含む、パイロットから拡大までの資金の付いた道筋がある。

主要な情報源#

• NHS digital service manual — NHS service standardとその各項目。「Use agile ways of working」と「Create a team that includes multidisciplinary skills and perspectives」を含む（service-manual.nhs.uk）。
• GOV.UK Service ManualとGovernment Service Standard — Government Digital Service（gov.uk/service-manual）。
• NHS England / NHSX — Digital Technology Assessment Criteria (DTAC)。
• 臨床安全標準DCB0129とDCB0160（NHS England / 旧NHS Digital）。
• NICE — Evidence Standards Framework for digital health technologies（nice.org.uk）。
• NHS England — 健康格差を縮小するためのCore20PLUS5アプローチ。

参考文献#

1. User-centered design — Wikipedia — https://en.wikipedia.org/wiki/User-centered_design
2. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Iterative and incremental development — Wikipedia — https://en.wikipedia.org/wiki/Iterative_and_incremental_development
5. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
6. Product management — Wikipedia — https://en.wikipedia.org/wiki/Product_management
7. Health equity — Wikipedia — https://en.wikipedia.org/wiki/Health_equity
8. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
9. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Government Service Standard — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/service-standard
13. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
14. Clinical Risk Management: DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
15. Evidence Standards Framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
16. Core20PLUS5 — NHS England — https://www.england.nhs.uk/about/equality/equality-hub/national-healthcare-inequalities-improvement-programme/core20plus5/