デジタルヘルスガイド

トピック1.6 — 臨床安全とリスクマネジメント

一文で言うと： 臨床安全とは、デジタル技術が患者を傷つけうる経路を見つけ、その危険が誰かに届く前に統制するという、規律あるエビデンスに基づく実践です。最初のスケッチから設計に組み込まれる安全であり、稼働直前に付け足すものではありません。

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

多くのセクターでは、ソフトウェアの欠陥は不便にすぎません。ページが読み込まれない、注文が二重になる、レポートが遅れる。医療・ケアでは、同じ種類の欠陥が人を死なせることがあります。小数点を切り捨てる投薬のフィールド、誤った患者を表示する結果画面、ある症状にフラグを立てるのを静かにやめるトリアージのアルゴリズム、アレルギー記録を黙って落とす連携。それぞれがソフトウェアのバグであり、同時に、重い害や死を引き起こしうる臨床上のハザードでもあります。臨床安全が、優れたエンジニアリングの上に重ねられる品質の気配りではなく、独自の標準、役割、エビデンスを持つ、別個の規制された規律であるのは、このためです。

リスクは非対称であり、しばしば目に見えません。デジタルシステムが機能しているとき、防がれた害を見る人はいません。失敗したとき、害は壊滅的で、遅れて現れ、誰かがパターンに気づく前に何千人もの患者に広がりうるのです。この組み合わせ、つまり結果が重大で、可視性が低く、影響範囲が広いという性質は、問題を見つけてくれるユーザーや、すべてを教えてくれるインシデントに頼れないことを意味します。害について、展開の前に積極的に推論し、システムが稼働している間も推論し続けなければなりません。英国では、この積極的な推論は任意ではありません。NHSの組織とそのサプライヤーは、契約上も専門職としても、国の臨床リスクマネジメント標準を適用し、その作業過程を示せることが期待されています。これを正しく行うことは、エビデンス（トピック1.3 — エビデンスに基づく意思決定参照）、情報ガバナンスとサイバーセキュリティ（トピック1.7 — 情報ガバナンス、データ保護、サイバーセキュリティ参照）、そして稼働後のサービスの運用の仕方（トピック3.8 — サービスマネジメントとライブ運用参照）と切り離せません。

中核概念#

患者安全とリスクマネジメント。 患者安全とは、ケアによる患者への害の予防、低減、報告、分析です。臨床リスクマネジメントは、リスクを特定し、評価し、優先順位づけし、統制するというリスクマネジメントの一般的な規律を、医療ITシステムが患者への害にどう寄与しうるかという具体的な問いに適用します。イングランドでこれを規定する二つの国の標準が、DCB0129とDCB0160です（DCBはData Coordination Boardの略で、これらは、2012年保健社会福祉法に基づいて義務づけられた、Standardization Committee for Care Information / SCCI標準です）。DCB0129は医療ITシステムの製造者または供給者に義務を課し、DCB0160はそれを導入し使用する医療組織に義務を課します。両者は補完的です。サプライヤーのきれいな安全性ケースは、導入するトラストが、自らの構成、ワークフロー、文脈によって持ち込まれるハザードを評価する義務を果たしたことにはなりません。

臨床安全責任者（CSO）。 どちらの標準も、名前のある、適切な資格と経験を持つ臨床安全責任者、つまり、認知された臨床安全の研修を修了した、登録された現役の臨床家が、臨床リスクマネジメントの活動を所有し、安全性ケースを個人的に承認することを求めます。CSOは、手の空いている誰かに割り当てられる役職名ではなく、能力の要件です。CSOは、ハザードが特定され、許容できる水準まで統制されたことを承認します。それは、専門職としての説明責任を伴う専門的な判断です。

臨床リスクマネジメントの成果物。 3つの文書がこの規律の錨となります。臨床リスクマネジメントファイルは、システムのすべての安全エビデンスの入れ物です。ハザードログは、特定されたすべてのハザード、その原因、結果、リスク評価、統制、残存リスクを記録する生きた台帳です。臨床安全性ケースは、システムが意図した文脈での意図した用途に対して、許容できる程度に安全であるという、エビデンスに裏づけられた構造化された論証であり、承認のために論証を要約した安全性ケース報告書が付きます。これらは、書類仕事のための書類仕事ではありません。安全についての推論を、明示的で、レビュー可能で、持続的なものにする手段です。

ハザード分析：特定、分析、評価、統制。 中核となるループは次のとおりです。ハザードの特定（ワークショップ、臨床的なウォークスルー、故障モード分析を通じて、システムがどう害に寄与しうるかを体系的に想像する）、リスク分析（害の重大度と発生する可能性を見積もる）、リスク評価（見積もったリスクを許容基準と比較する）、リスクの統制（設計変更、アラート、研修、手順といった措置を導入して許容できないリスクを低減し、そのあと残存リスクを再評価する）。リスクは、合理的に実行可能な限り低く（ALARP）低減されます。得られる利益に対して、さらなる低減が著しく不釣り合いになるまで、統制を続けます。

医療機器の規制、MHRA、医療機器としてのソフトウェア（SaMD）。 デジタルヘルス技術の一部は、規制された医療機器です。診断、予防、モニタリング、予測、治療といった医療目的を持つソフトウェアは、それ自体が医療機器、つまり医療機器としてのソフトウェア（SaMD）になりえます。英国では、Medicines and Healthcare products Regulatory Agency（MHRA）がSaMDを含む医療機器を規制し、ソフトウェアのライフサイクル標準IEC 62304が、そうしたソフトウェアをどう開発しなければならないかを規定します。自分たちの技術が規制対象の機器かどうかを決めることは、大きな帰結を伴う入り口の問いであり、DCB0129/0160の臨床リスクマネジメントとは別のものです（並んで存在します）。

Digital Technology Assessment Criteria（DTAC）。 DTACは、NHSと社会的ケアの組織が、調達の前にデジタル製品を評価するために使う国の基準線で、臨床安全（DCB0129への準拠のエビデンス）、データ保護、技術的セキュリティ、相互運用性、使いやすさをカバーします。臨床リスクマネジメントを代替するものではなく、サプライヤーがそれを実施したかを確認するものです。

ヒューマンファクターと安全文化。 ヒューマンファクター（人間工学）は、疲労、中断、認知負荷、アラート疲れといった現実の条件の下で、人がシステムとどう相互作用するかについての科学的研究です。デジタルによる害の多くは、コードが「間違っている」ことからではなく、安全な行動を難しくし、危険な行動を容易にする設計から生じます。安全文化は、非難なしに、リスクを表に出し、報告し、そこから学ぶという組織のコミットメントです。ヒヤリハットを隠すチームと、改善のためにそれを掘り起こすチームの違いです。

インシデントの報告と学習。 イングランドでは、**Learn from Patient Safety Events（LFPSE）**が患者安全イベントを記録する国のサービスであり、**Patient Safety Incident Response Framework（PSIRF）**は、NHSの組織がインシデントにどう対応し、そこから学ぶかを定め、非難よりも、比例的でシステムに基づく根本原因分析を重視します。稼働中のシステムは新たなハザードを生むため、臨床安全は、インシデントのフィードバックをハザードログに反映することで、稼働後も続きます。

ベストプラクティス#

  1. 有能な臨床安全責任者を任命し、実際の権限を与える。 対象となるすべてのシステムについて、認知された臨床安全の研修を受けた、登録された現役の臨床家をCSOに指名し、そのサインオフが、稼働前日に得られる形式的な承認ではなく、本物の関門であることを確保します。CSOは「まだです」と言え、それが聞き入れられなければなりません。つまり、その時間、独立性、プログラム委員会での立場を守ることを意味します。デリバリーの圧力に覆されるCSOは、ガバナンスという虚構です。

  2. ハザードの特定は早期に、臨床家を同席させて行う。 ハザードのワークショップは、稼働直前ではなく、ディスカバリーと設計で始めます。最も安く最も効果的な統制は、何かが作られる前に行う設計変更だからです（トピック3.5 — デリバリーライフサイクル参照）。アナリストだけでなく最前線の臨床家を招いてください。彼らは仕事が実際にどう行われるか、つまり中断、回避策、午前3時に画面がどう読まれるかを知っているからです。現実的な臨床シナリオを順に確認し、容赦なく問います。「このシステムは、患者が害を受けることにどう寄与しうるか」。

  3. 稼働当日の文書ではなく、生きたハザードログを保つ。 ハザードログを、ディスカバリーで開かれ、システムが稼働している間は決して閉じられない、持続的な台帳として扱います。各ハザードは、その原因、潜在的な害、初期のリスク評価、適用された統制、統制後の残存リスクを記録します。インシデント、変更、ヒヤリハットが新たなハザードを明らかにしたら、それはログに入り、同じループで対処されます。ログは、安全についての推論の記憶です。

  4. 準拠したサプライヤーがいても、導入する組織がDCB0160を所有する。 サプライヤーのDCB0129の安全性ケースは、製造された製品を対象としますが、それをどう構成するか、その周りにどのワークフローを組むか、どの集団が使うかまでは対象にできません。地域のハザード、つまり他システムとの連携、データ品質、臨床経路について、自前のDCB0160の評価を実施し、自前のハザードログを持ってください。サプライヤーのアシュアランスが自分たちの文脈を覆うと考えるのは、ありふれた危険な近道です。

  5. リスクの統制を比例的にし、警告より設計を優先する。 統制は、その強さで順位づけます。ハザードを設計で取り除くこと（制約、デフォルト、強制機能）は、画面上のアラートに勝り、それは研修マニュアルの一行に勝ります。最も重いアシュアランスは、最も結果の重いハザードのために取っておき、本当に低リスクの変更には、より軽く速いプロセスを適用してください。比例性こそが、安全をデリバリーと歩調を合わせさせます。リスクをALARPまで低減し、残存リスクが許容できる理由を記録します。

  6. ヒューマンファクターのために設計し、アラート疲れを尊重する。 ユーザーは忙しく、中断され、パターン認識で動くと仮定し、安全な行動が、簡単で、デフォルトの行動になるよう設計します。アラートの過負荷に備えてください。頻繁に発せられるアラートは無視され、追加される警告はすべて、存在に値することを示さなければ、重要なものの価値を下げます。現実的な条件でのユーザビリティテストは、設計の気配りではなく、臨床安全の活動です。

  7. 規制上の位置づけを意図的に判断する。 ソフトウェアが医療機器やSaMDの定義に当てはまるかを早期に問い、当てはまるなら、義務を遅れて発見するのではなく、最初からMHRAの要件とIEC 62304に取り組みます。分類の誤りは、どちらの方向でも高くつきます。未登録の機器は法的かつ安全上の失敗であり、単純なツールを過大に分類すれば、希少なアシュアランスの能力を浪費します。迷ったら規制の助言を求め、その理由を文書化してください。

  8. DTACを、ゴールではなく床として使う。 Digital Technology Assessment Criteriaを、調達されるあらゆるデジタル製品の最低限の入り口のチェックとして扱い、臨床安全、データ保護、セキュリティ、相互運用性、使いやすさが取り扱われたことを確認します。DTACを通過することは、サプライヤーが作業を行ったことを意味するだけで、製品が自分たちの文脈で安全であることは意味しません。したがって、自前のDCB0160の評価と稼働中のモニタリングを組み合わせてください。

  9. 稼働中のインシデントから、ハザードログへのループを閉じる。 インシデントの報告、つまりLFPSEへの提出、PSIRFの調査、地域のヒヤリハット報告を、臨床リスクマネジメントへ結びつけ直し、現実の害とヒヤリハットが、ハザードと統制を更新するようにします。稼働後に一度も見直されない安全性ケースは腐ります。稼働中のシステム、連携、臨床の実践はすべてドリフトするからです（トピック3.8 — サービスマネジメントとライブ運用参照）。学びはシステムに基づき、非難を意識したもので、罰する相手を探すことではありません。

  10. 公正で、報告を促す安全文化を築く。 ヒヤリハットを報告することと、安全を理由に稼働に異議を唱えることを、安全で当然のこととしてください。耳に入らないハザードは、統制できないハザードだからです。リーダーは、悪い知らせに非難ではなく好奇心と改善で応え、CSOの慎重さを、妨害ではなく価値あるものとして扱うことで、その基調を作ります。文化は、ここにある他のすべての実践が依拠する基盤です。

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

  1. 現在のポートフォリオのどこで、実際には私たち自身が所有すべきリスクを、サプライヤーの安全アシュアランスに頼って賄っているか。 この問いは、チームが日常的に曖昧にしているDCB0129とDCB0160の分担を探ります。サプライヤーのDCB0129の安全性ケースは、製造された製品を扱いますが、それを構成し、他のシステムにつなぎ、地域のワークフローを周りに組み、特定の患者集団に向けた瞬間に、サプライヤーが評価しておらず、評価もできなかったハザードを持ち込みます。率直な緊張は、自前のDCB0160の評価を実施するには、希少な臨床と分析の時間がかかり、サプライヤーのきれいなアシュアランスとDTACの合格を、十分だとみなしたくなることです。稼働中または間近の導入を取り上げ、具体的に問ってください。その導入について名前付きのCSOは誰か、自前のハザードログがあるか、製品そのものではなく、純粋に私たちの地域の文脈から生じるハザードはどれか。良い答えは、地域の評価が薄い具体的なシステムを挙げ、製品のハザードと導入のハザードを区別し、後者を、カバーされていると想定するのではなく、自ら所有することを約束します。

  2. 私たちの臨床安全のプロセスはどれほど比例的か。低リスクの変更を書類に埋もれさせる一方で、結果の重い変更が勢いに乗って通り抜けていないか。 本トピックは、アシュアランスは臨床リスクに応じて拡大縮小すべきだと論じます。結果が最も重いハザードには最も重い精査を、リスクが本当に低いところにはより軽く速いプロセスを。この問いは、組織が実際に調整しているのか、一つの鈍い設定を適用しているのかを試します。どちらの失敗の方向も現実で、コストがかかります。一律に重いプロセスは、臨床安全を官僚的な税と見なし、それを迂回するようチームを訓練し、一律に軽いプロセスは、投薬量計算の変更を、ヘルプページの変更と同じ労力で通過させます。より微妙な危険は、精査を決めるのがリスクではなく勢いであることです。経営層の注目を集める主力プログラムは、不可避性のオーラをまとい、CSOが「まだです」と言うのをためらわせることがあります。明らかにリスクの異なる最近の変更を二、三検討し、費やされた労力が害の可能性に見合っていたか、そして注目度の高いものを遅らせられると感じた人がいたかを問います。誠実な答えは、プロセスがどちらかの方向に誤って調整されている箇所を認め、比例性を、反射ではなく、説明可能で明示的な判断として扱います。

  3. デジタルシステムで危うく問題が起きそうになったとき、実際にその後何が起きたか。そして最前線の臨床家は、それを声に出しても安全だったと言うだろうか。 この問いは、安全文化とインシデントから学ぶループ、つまり、表明されたコミットメントが現実と出会う場所を点検します。臨床安全は、ヒヤリハットが耳に入るかどうかに左右されますが、人々が報告するのは、報告が安全で意味のあるものと感じられ、非難ではなく変化につながるのを見たときだけです。緊張は、デリバリーと評判のプレッシャーの下では、ヒヤリハットを言い訳して片づけ、素早くクローズして先へ進みたくなる本能が働くことです。特に、完全に表面化させればローンチが遅れたり、上級スポンサーが恥をかいたりする場合はそうです。PSIRFの、システムに基づき非難を意識したアプローチは、まさに、個人に落ち度を探すことが、必要な報告を抑え、本当の、システム上の原因を見逃すからこそ存在します。具体的な最近のヒヤリハットやインシデントで議論を根づかせてください。記録されたか、ハザードログに届いたか、比例的な調査が行われたか、実際に何か変わったか。良い答えは、報告が安全に感じられたかについて率直であり、本物の学びと、書類上のクローズを区別し、次にハザードに気づいた人が声を上げられるよう、リーダーが採る具体的な行動を挙げます。

  4. 自社のどの製品が規制された医療機器かを正直に判断したか。そして、その決定に責任を負うのは誰か。 規制上の位置づけは、不釣り合いに大きな結果を伴う入り口の問いであり、答えるのが不都合なため、答えないままにしやすいものです。診断、予測、モニタリング、治療を行うソフトウェアは、それ自体が医療機器としてのソフトウェアであり、MHRAの義務とIEC 62304のライフサイクル標準を引き込みうるもので、DCB0129/0160の臨床リスクマネジメントとは別の、追加のものです。緊張は両方向に走ります。過小な分類は、未登録の機器を出荷することになり、大規模に壊滅的に表面化しうる法的かつ安全上の失敗です。単純な事務ツールを過大に分類すれば、ほかで必要だった希少なアシュアランスの能力を燃やします。危険なのは、分類が役割の間に落ちることです。臨床家はエンジニアが決めたと思い、エンジニアは規制や営業のチームが決めたと思い、誰も実際には推論を書き出していません。ポートフォリオの中で、境界線に最も近い製品、つまりトリアージのルール、リスクスコア、アラートのアルゴリズムを持つものを具体的に見て、誰が、何を根拠に機器の判断をしたか、それが文書化され、機能の変更に合わせて見直されているかを問います。誠実な答えは、境界上の製品を挙げ、それぞれに記録された説明可能な根拠を示し、決定が実際には行われていなかった箇所について率直です。

  5. 私たちはハザードを設計で取り除いているのか、それとも臨床家がすでに無視することを学んでしまったアラートと警告を静かに積み上げているのか。 本トピックは、統制をその強さで順位づけます。ハザードを設計で取り除くことは、画面上のアラートに勝り、それは研修マニュアルの一行に勝ります。それでもアラートは最も抵抗の少ない道です。警告の追加は速く、責任ある行動に感じられる一方、ワークフローの再設計は遅く、異論が出るからです。時間とともに、この偏りは、アラート疲れとして積もります。あまりに多くの警告が発せられ、臨床家は、重要なものも含めてすべてを、パターン認識で素通りするため、新しいアラートが一つ増えるたびに、実際には安全性が下がりえます。本当の緊張は、不要なアラートのすべてに、何らかのインシデントのあとに善意で追加したスポンサーがいるため、システムを劣化させていても、警告を取り除くことが政治的に難しいことです。ここで重要なのはヒューマンファクターです。忙しく、中断され、午前3時に画面を読むユーザーにとって、安全な行動が簡単なデフォルトの行動になるよう設計することであり、現実的な条件でのユーザビリティテストは、設計の気配りではなく、臨床安全の活動です。チームが実際に使っているシステムを調べ、典型的なタスクで臨床家が出会うアラートがいくつあるか、そのうちどれが実際に行動を変えるか、強制機能やより良いデフォルトが警告を完全に置き換えられたのはどこかを問います。良い答えは、もう一つアラートを足す反射に抵抗し、アラートの負荷を、それ自体が測定可能なハザードとして扱い、もはやその存在に値しない警告を取り除く意思があります。

  6. 稼働中のシステム、連携、臨床経路が時間とともにドリフトするなかで、安全性ケースがまだ成り立っていることを、どうやって知るのか。 臨床安全は稼働で終わりません。稼働中のシステムは新たなハザードを生み、システムを取り巻く世界は動き続けます。上流の連携がデータを変え、臨床経路が再設計され、サプライヤーが更新を出荷し、新しい患者コホートがツールを使い始めます。二年前に承認された安全性ケースは、もはや存在しないかもしれないシステムと文脈を記述しているため、問いは、ハザードログが生きた台帳なのか、一度署名されて放置され腐っていく文書なのか（トピック3.8 — サービスマネジメントとライブ運用参照）です。緊張は、ローンチ後の安全についての推論の維持が、新しいデリバリーと、同じ希少なCSOと臨床の時間を奪い合うこと、そしてドリフトは緩やかで目に見えず、何かが失敗するまで注意を集めることがまれなことです。具体的な切り口は、構成や連携が変わったときにハザード評価を再び起動する変更管理、最も結果の重いハザードの定期的な見直し、統制が静かに劣化していることを実際に検知できるモニタリングです。一年以上稼働しているシステムを選び、そのハザードが最後にいつ見直されたか、承認以降に下で何が変わったか、重要な統制が働かなくなったら誰が気づくかを問います。誠実な答えは、本物の継続的な安全管理があるシステムと、古い安全性ケースで惰性で走っているものを区別し、カレンダーだけではなく、実際の変更に結びついた比例的な見直しのリズムを約束します。

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

ある統合ケアシステム（ICS）が、一般診療医がコミュニティサービスへ患者を直接紹介できる共有の電子紹介ツールを導入しようとしています。緊急の症例をより速い待ち行列に振り分ける、組み込みのトリアージルールセットを備えています。デリバリー重視のアプローチなら、サプライヤーのDCB0129の安全性ケースを受け取り、DTACを通過し、取締役会に約束された日付に間に合わせて稼働するでしょう。

その代わりにプログラムは、臨床安全の研修を受けた現役の一般診療医を臨床安全責任者に任命し、設計の開始時に臨床リスクマネジメントファイルとハザードログを開きます。一般診療医、地域看護師、事務担当者との早期のハザードワークショップは、サプライヤーの製品レベルのケースが一度も触れなかった、すべて地域での導入から生じるいくつかのハザードを浮かび上がらせます。最悪のものはこうです。トリアージルールはICS独自のサービス定義に対して構成されており、マッピングの誤りによって、緊急の皮膚がんの紹介が、数週間待ちの通常の皮膚科の待ち行列に振り分けられうるのです。このハザードは、重大度が高く、可能性がありうると評価されます。

リスク統制のループを回しながら、チームは警告より設計を選びます。ルーティングのロジックによって、緊急の臨床フラグが黙って上書きされることがないよう強制機能を追加し、臨床家が毎日確認する突合レポートを作り、階層で最も低いものとして、研修のメモを付けます。残存リスクは再評価され、許容できかつALARPであると判断され、CSOがその理由を記録します。ツールは振り分けるだけで、自ら診断はしないため、チームはそれがSaMDの閾値を満たさないと評価し、その理由を文書化し、保管します。ヒューマンファクターのテストは別の問題を見つけます。意欲が過剰な「重複紹介」のアラートがあまりにも頻繁に発せられ、一般診療医はすでにそれを無視しているため、本当の重複のときだけ発せられるよう再設計されます。

稼働時には、DCB0160の安全性ケースは、プログラムディレクターではなくCSOによって承認されます。3週間後、LFPSEの報告と、受付担当者が指摘したヒヤリハットが、新たなハザードを明らかにします。ルーティングが決して見ない、緊急情報を紛れ込ませるために、自由記述のフィールドが使われていたのです。PSIRFの下で、比例的でシステムに基づく見直しが行われ、ハザードはログに入り、設計変更が予定され、暫定的な統制がその週のうちに周知されます。安全性ケースは生きた論証であり、記録は、各ハザードについてどう推論されたかを正確に示します。これは、検査官、検視官、あるいは二年後の新しいCSOが必要とするものです。

セクター別の視点#

臨床リスクを統制する義務は誰にとっても同じですが、仕組み、誘因、圧力は、組織によって大きく異なります。

スタートアップ#

デジタルヘルスのスタートアップは、臨床安全を調達の関門として初めて知ることが多いものです。NHSの購入者がDTACとDCB0129の安全性ケースを求め、駆け込みが起きます。勝ち筋は、最初のスプリントから臨床リスクマネジメントを組み込むことです。バックログと並んだハザードログ、アクセスしやすい臨床安全責任者（雇用ではなく契約であることが多いものの、本当に有能で権限を与えられている）です。完成した製品に安全性ケースを後付けするのは、遅く、高価で、説得力に欠けるからです。創業者はまた、SaMDの問いに早期に誠実に向き合わなければなりません。規模拡大の途中で、製品が未登録の医療機器だったと発見することは、存続に関わる法的かつ安全上のリスクだからです。うまく行えば、成熟した臨床安全の成果物は、NHSの営業サイクルを短縮する商業上の資産になります。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、訪問介護事業所、単独拠点のクリニック、収益前の段階を過ぎた小規模なヘルステックのサプライヤーは、デジタルシステムを導入し構成するとき、大きなトラストと同じDCB0160の義務を負いますが、それを果たす余力はまったくありません。専任のCSOや安全アナリストが給与名簿に載っていることはまれなので、実務的な道は、有能な現役の臨床家を契約ベースで買い入れ、義務が適用されないふりをするのではなく、無駄はないが本物のハザードログを持つことです。最も鋭い地域のハザードは、通常、構成とワークフローに関するものです。共有記録がどう設定されているか、緊急フラグがどう扱われるか、パートタイムの事務担当者一人の回避策が、どうルーティングのリスクになるか。まさにサプライヤーのDCB0129のケースが決して扱わないハザードです。比例性は、ここで小規模な提供者の味方です。わずかなアシュアランスの時間を、最も結果の重いハザードに集中させ、製品を選ぶ際の床として、DTACとサプライヤーの安全性ケースを使い、装置全体を一人で作ろうとせず、ICSの臨床安全支援のような共有リソースに頼ってください。

大企業#

NHSトラストやICSは、二重の説明責任を負います。他者のシステムをDCB0160の下で導入し、しばしば自前のものをDCB0129の下で構築したり、大幅に構成したりします。典型的な失敗は組織的なものです。稼働日が政治的な重みを持つ主力の電子患者記録プログラムで、CSOの慎重さが、静かに障害として扱われます。対策は構造的です。CSOに独立性と本物の拒否権を与え、稼働当日の文書の棚ではなく、環境全体にわたる生きたハザードログを保ち、LFPSEとPSIRFからの学びを、常設のプロセスとして臨床リスクマネジメントに結びつけ直します。大規模では、最大のハザードは連携と構成のハザードであり、どのサプライヤーのアシュアランスも扱わないため、地域が所有することは交渉の余地がありません。

政府#

NHS England、MHRA、DHSC、NICEといった国の機関は、他者が満たすべき標準を定めるため、その仕事の進め方がシステム全体を形づくります。DCB0129/0160、DTAC、SaMDの規制は、国民規模の安全の道具です。ここでの決定は、規制、議会、国民の精査を集め、国が義務づけた、潜在的なハザードを抱えるシステムは、誰かがパターンを見る前に、何百万人にその害を広げます。義務は、公表された標準の中で比例性を明示すること、残存リスクについての透明性、そして技術、特にAIが追い越すにつれて、規制の枠組みを最新に保つことです（トピック8.4 — AIと新興技術のガバナンス参照）。この規模に特有のリスクはシステミックなものです。薄い安全エビデンスで、環境全体に技術を義務づければ、ハザードを同時にあらゆる場所に固定化します。

よくある失敗パターン#

  • 最後に付け足される安全。 関門を満たすために、稼働の一週間前に安全性ケースを作る。対策：ディスカバリーでハザードログを開き、最大のハザードを設計で取り除く。
  • サプライヤーのアシュアランスを、地域の安全と取り違える。 DCB0129のケースとDTACの合格が、自分たちの導入をカバーすると扱う。対策：自前のDCB0160の評価と地域のハザードログを所有する。
  • 形式的な承認者としてのCSO。 「まだです」と言う時間、独立性、権限のない臨床安全責任者。対策：役割を守り、サインオフを本物の関門にする。
  • 死んだハザードログ。 一度書かれ、ローンチ後に見直されない文書。対策：生きたものに保ち、インシデントと変更をそこに流し込む。
  • アラートの過負荷。 臨床家が、重要なものも含めてすべてを無視するほど多くの警告。対策：ヒューマンファクターの設計。すべてのアラートが存在に値しなければならない。
  • 非難の文化。 ヒヤリハットで個人を罰し、報告が枯れる。対策：PSIRFに沿った、公正でシステムに基づく文化。
  • 見逃された規制の閾値。 規制対象の機器だと認識せずにSaMDを出荷する。対策：医療機器としての位置づけを早期に評価し、文書化する。

成熟度モデル#

観点 着手 発展 標準化 管理 統合
臨床安全ガバナンス CSOなし、場当たり的 CSOは指名されているが権限が弱い 本物の拒否権を持つ有能なCSO。サインオフは関門 CSOのサインオフがすべてのリリースについて追跡され、独立性と決定が保証され、取締役会に報告される CSOの独立性と権限が組み込まれ、安全がデリバリーを導く
ハザード管理 ハザードログなし ローンチ用にログが書かれ、その後は静的 ディスカバリーで開かれ、統制のループを通して対処される生きたログ ハザードが測定される。残存リスクの傾向、統制の状況、期限超過の対応が追跡され、目標に対して管理される インシデント、変更、ヒヤリハットからログが継続的に更新される
DCB0129 / DCB0160 どちらも適用されていない サプライヤーのケースで十分と受け入れられる 両方の標準が適用され、地域のハザードが所有される コンプライアンスが積極的に管理される。評価がKPIに対して保証され、ギャップが追跡され、期日どおりに解消される 比例的で、日常的で、デリバリーのライフサイクルに統合される
ヒューマンファクターと設計 警告と研修のみ 一部でユーザビリティテスト 設計による除去が優先され、アラートは負荷に応じて選別される アラート負荷とユーザビリティの成果が目標に対して測定され、アラート疲れが定量化され管理される 現実的なヒューマンファクターのテストが組み込まれ、アラート疲れが監視される
インシデントからの学習と文化 非難。ヒヤリハットが隠される インシデントは記録されるが、フィードバックされない LFPSE/PSIRFの学びがハザードログを更新する 報告と学習が測定される。ヒヤリハットの件数、対応時間、対応の完了が追跡され、ガバナンスされる 公正な文化。ヒヤリハットが改善のために積極的に掘り起こされる

チェックリスト#

  • 各システムについて、有能で、現役で、研修を受けた臨床安全責任者が指名されており、「まだです」と言う時間と権限を持つ。
  • 対象となる各システムについて、臨床リスクマネジメントファイル、生きたハザードログ、臨床安全性ケースが存在する。
  • ハザードの特定がディスカバリーで始まり、最前線の臨床家が同席していた。
  • 導入する組織が、サプライヤーのDCB0129のケースを受け入れるだけでなく、自前のDCB0160の評価を実施している。
  • リスクの統制は、設計による除去、アラート、研修の順に優先し、残存リスクをALARPまで低減し、正当化している。
  • 医療機器/SaMDとしての位置づけが評価・文書化され、関連する場合にMHRAとIEC 62304の義務に取り組んでいる。
  • DTACが床として完了し、地域の臨床リスクマネジメントと組み合わされている。
  • 現実的な条件でのヒューマンファクターとユーザビリティのテストが行われ、アラートの負荷が統制されている。
  • 稼働中のインシデント（LFPSE）とPSIRFの学びが、常設のプロセスとしてハザードログにフィードバックされる。
  • ヒヤリハットを報告し、安全を理由にローンチに異議を唱えることが、目に見える形で安全で当然のこととされている。

主要な情報源#

  • NHS England — DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems。
  • NHS England — DCB0160: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems。
  • NHS England — Clinical Safety Officer trainingと臨床リスクマネジメントのガイダンス。
  • NHS England — Digital Technology Assessment Criteria (DTAC)。
  • MHRA — Software and Artificial Intelligence (AI) as a Medical Deviceガイダンス。
  • IEC — IEC 62304: Medical device software — software life cycle processes。
  • ISO — ISO 14971: Application of risk management to medical devices。
  • NHS England — *Learn from Patient Safety Events (LFPSE)*サービス。
  • NHS England — Patient Safety Incident Response Framework (PSIRF)。
  • 世界保健機関 — Global Patient Safety Action Plan 2021–2030。

参考文献#

  1. Patient safety — Wikipedia — https://en.wikipedia.org/wiki/Patient_safety
  2. Risk management — Wikipedia — https://en.wikipedia.org/wiki/Risk_management
  3. Hazard analysis — Wikipedia — https://en.wikipedia.org/wiki/Hazard_analysis
  4. Safety case — Wikipedia — https://en.wikipedia.org/wiki/Safety_case
  5. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
  6. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
  7. Ergonomics (human factors) — Wikipedia — https://en.wikipedia.org/wiki/Ergonomics
  8. Safety culture — Wikipedia — https://en.wikipedia.org/wiki/Safety_culture
  9. As low as reasonably practicable (ALARP) — Wikipedia — https://en.wikipedia.org/wiki/As_low_as_reasonably_practicable
  10. Root-cause analysis — Wikipedia — https://en.wikipedia.org/wiki/Root-cause_analysis
  11. IEC 62304 — Wikipedia — https://en.wikipedia.org/wiki/IEC_62304
  12. DCB0129: Clinical Risk Management in the Manufacture of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
  13. DCB0160: Clinical Risk Management in the Deployment and Use of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
  14. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
  15. Software and Artificial Intelligence (AI) as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
  16. IEC 62304: Medical device software — software life cycle processes — International Electrotechnical Commission — https://www.iso.org/standard/38421.html
  17. ISO 14971: Application of risk management to medical devices — International Organization for Standardization — https://www.iso.org/standard/72704.html
  18. Learn from Patient Safety Events (LFPSE) service — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/learning-from-patient-safety-events/
  19. Patient Safety Incident Response Framework (PSIRF) — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/incident-response-framework/
  20. Global Patient Safety Action Plan 2021–2030 — World Health Organization — https://www.who.int/teams/integrated-health-services/patient-safety/policy/global-patient-safety-action-plan

GitHubでこのページを編集 — 本書が信頼できる唯一の情報源であり、このサイトはそれを表示するだけです。