医療機器開発の成功を導く基盤の構築

最適なメドテックソリューションの開発戦略を立てるには、エンジニアリング、ビジネス、規制対応の各側面に気を配る必要があります。その後の開発や保守、運用コストに大きな影響を及ぼすため、この戦略立案は非常に重要です。ただ、他分野の製品開発と同じく、医療機器の開発においても万能なアプローチはありません。

Starでは、規制に準拠したメドテック＆デジタルヘルスケアソリューションの開発において、当社の経験を活かしたエンドツーエンドの製品開発サポートを通じて、お客様企業が患者中心で規制に対応した、拡張性のある医療機器テクノロジーを構築できるよう支援しています。

私たちはまず、最も基本的な検討事項である「医療機器となる条件は何か？」という問いから始めます。多くの企業は、医療機器か否かの二者択一で考えがちですが、実際にはそれ以外にも選択肢があり、さまざまなアプローチが可能です。

早い段階から適切なステップを踏むことで、規制対応プロセスを効率化し、医療機器分野の全体像を俯瞰しながら、将来を見据えた製品開発やメンテナンス、および会社の未来に向けた基礎を築けます。本記事では、Starがメドテックおよびデジタルヘルスケアのソリューション開発において重視しているポイントをまとめ、その概要をお伝えします。

機器がどう分類されるが重要

多くの企業は、開発する製品全体が医療機器でなければならないと考えがちですが、実際には、より柔軟なアプローチが可能です。

最適なアプローチをとるには、プロジェクトの内容よりも、まずその企業がどのようなステージにあるかを知ることが重要です。例えば、すでに医療機器などの機器を開発・販売している会社なのか、それともこの分野で新たに製品やサービスを生み出そうとしているスタートアップ企業なのか。つまり、予算や経験、専門知識によって、とるべきアプローチが違ってくるのです。

製品戦略は、開発する機器がどう分類されるかによって変わってきます。製品が医療機器に分類されるかどうかを判断するための参考となる、FDAの承認取得プロセスの概略を以下に示します。

• 製品の「意図する目的」を記述する。
• 「意図する目的」と、対象市場における医療機器や体外診断用医療機器の定義を照らし合わせる。
• 理由を含めた規制戦略の文書化を行い、対象となる規制制度における製品の扱いについての情報収集を行う。

医療機器とみなされない製品を意図的に開発したい企業にとっては、このプロセスの機微を理解することが特に重要です。それにより、例えば、医療機器に分類されないよう機能を調整したり、患者さんと実際の処置との間に臨床医が関与するステップを加えたりといった対策を行えます。

例として、多発性硬化症の管理を支援するソリューションを開発する場合を考えてみます。多発性硬化症の治療では、多くの場合、痛みを伴う筋肉注射を毎週行う必要があり、実際にどの部位に注射を打つかが、患者さんのウェルビーイングとアドヒアランスにとって極めて重要になります。その際に使うツールとして、注射部位の履歴を表示するだけのアプリなら、医療機器とはみなされないでしょう。洗練されたUIを持つデジタル手帳のようなツールだと位置付けられるからです。

一方、注射部位を追跡し、履歴に基づいて注射すべき場所を助言するアルゴリズムを備えたアプリの場合は、医療機器とみなされるでしょう。つまり、機能が似たツールでも、注射部位を記録するだけなのか、提案を行うのかという違いによって、分類される製品カテゴリーが異なってくる可能性があります。この違いは、製品戦略、設計、開発、そして市場投入までの時間に大きな影響を及ぼすため、非常に重要です。

開発企業がとるべきアプローチとは？

Starでは、常にその企業の状況に合わせたアドバイスを行っています。規制対象となる医療機器の開発を提案することもあれば、今はそのベストタイミングではないと助言するケースもあります。また、製品中の一部の要素を医療機器とし、それ以外を非医療機器とすることをお勧めする場合もあります。実際、これがメドテックソリューションの開発で鍵となるポイントです。

Starは、革新的な医療機器を市場に送り出してきた経験から、分類を左右する具体的なポイントや、長期的な視点での最適なアプローチについて、お客様企業が理解を深められるよう支援しています。例えば、草創期の企業であれば、現状の予算等を考慮して、まずは非医療機器の開発から始めて、将来的に規制対象の医療機器を目指すといったプランが考えられます。

具体的にはヘルスケア分野に関するガイダンスの提供や、コネクテッド医療機器の開発における効果的なロードマップの策定を行っています。実際に現在進行中のあるプロジェクトで、このアプローチを実践しています。Starは、一部を医療機器とする総合的なソリューションの開発において、アイデア創出からローンチまでを支援しています。

プロジェクトは現在、製品開発の第2段階にあり、次の認証取得に向けた規制対応に取り組んでいるところです。このようにロードマップを作成し、その企業に適した戦略を探求して、最終目標を見据えたアプローチであらゆるステップを支援できることに、Starの価値があると考えています。

メドテック開発におけるモジュール化

医療機器というと物理的なハードウェアがイメージされがちです。それくらいSaMD（プログラム医療機器）の開発について、まだあまり知られていないのが現状です。

実際にはほとんどのメドテックソリューションは、ライフスパンが10年以上になります。その観点から、リリースや更新を行いやすいようなシステムの設計・構築が求められます。

製品がデジタル化されることで、より柔軟な作成、反復開発、展開、更新も可能になります。また、ソフトウェア内の構成要素を、医療機器と非医療機器に区分けすることで、以下のようなメリットがもたらされます。

• 構成要素ごとにリリースや規制対応が行えるようになる。
• バックエンドシステムよりもモバイルアプリを頻繁に更新するなど、構成要素ごとに異なる更新頻度を適用できる。
• 非医療機器要素において柔軟性が高まり、規制対応の負担を軽減できる。
• ソリューションの運用に際して、システムの部分的な更新が可能になる。
• 各要素のロジックをカプセル化して、アーキテクチャ的に独立させられる。

市場投入までの時間やコストはもちろん重要ですが、総所有コストの大部分は市場投入後に発生していることも忘れてはなりません。つまり、適切なプランニングに基づいた開発を行うことで、長い目で見たコストを抑制でき、将来の進化に必要な要素を厳選して取り入れられます。

「意図する目的」の記述に関するアプローチ

機器における「意図する目的」は、設計全体の指針となる要素です。その記述の構造を知ることで、時間とコストの両面で、より柔軟に医療機器の開発を行えるようになります。つまり、「意図する目的」の記述方法を少し工夫するだけで、承認プロセスの進展に大きな違いが生まれる可能性があるのです。

「意図する目的」の構成によって、とるべき規制対応アプローチが異なってきます。その設計で何を目指すのか、どのような販売やマーケティングを行い、長期的にどうメンテナンスしていくのか、といったことを検討する必要があり、ビジネスプランとも密接に関係してきます。

欧州医療機器規則（MDR）第2条では、「『意図する目的』とは、ラベル、使用説明書、または販促資料や声明の形でメーカーが提供するデータに基づいた、そしてメーカーが臨床評価で指定した、機器の用途を意味する」とされています。

その「意図する目的」の記述によって、製品の分類が決まります。もし使用目的が変わるようなことになれば、すべての承認プロセスをやり直さなければならない場合があります。そのため、適切なパートナーと協力して対応することが重要です。時には、こうした変更が避けられないこともあります。その際に最も時間がかかるのは臨床評価と適合性評価のプロセスですが、適切な戦略と公認機関を選ぶことで、これにかかる時間を3〜6か月に短縮できます。

Starでは、お客様企業と一緒に「意図する目的」の文書を作成する際に、通常、次の情報を確認しています。意図する使用目的の説明、主な機能、医学的適応、医学的禁忌、ユーザーグループ（プロファイルと人数を含む）、身体部位／組織の種類、意図する使用環境、機能原理、その他の意図する使用、医療機器の制限／機器の誤用。

このようにして作られたマスター文書が、設計管理、製品開発、リスク管理など、製品の市場投入に向けて必要なあらゆる事項の指針となります。

製品のアップデートと変更

コネクテッド医療機器の開発では、従来の開発では考慮する必要のなかった、新しい機会や課題が生じます。そのためソフトウェアの改良から、セキュリティの脆弱性の修正まで、あらゆる対応において製品の柔軟性が重要になります。

意図する目的の記述で、医療機器製品の定義を吟味していれば、将来変更の必要に迫られても、機器の用途を変えない限りアプリケーションを更新するだけでよく、規制当局による再承認を得る必要はないはずです。

セキュリティアップデートがその例です。また、インターフェースを変えずに、ソフトウェアの一部に関わるライブラリを更新する際も同様です。AIアルゴリズムを全面的に見直すなど、大きな変更があった場合のみ、再度の検証・承認のプロセスが必要になります。

更新は、重要な変更か否かによって3段階に分けられます。重要でない変更は、さらにバージョンリリースとホットフィックスリリースに2つに分類されます。

1. 重要な変更：医療機器の性能が大幅に変更され、新しいバージョンをリリースする場合です。通常は臨床評価プロセスをやり直し、新しいUDI-DI（機器固有識別子・機器識別子）を取得し直す必要があります。臨床評価、CEマークの取得、製品の審査などを再度行う必要が生じる場合もあります。
2. 重要でない変更：機器の性能に変更がないソフトウェアのマイナーチェンジの場合は、臨床評価プロセスをやり直す必要はありません。すでに市場に出ている製品と同等の性能を保ったままバージョン更新のみを行う場合がこれに該当します。ただ、「意図する目的」や製品要件に変更がないことを示す必要があります。このようなソフトウェア変更の方法として、次の2種類があります。
   • バージョンリリース：医療機器の性能に影響を与えない範囲での、新しい製品バージョンのリリース。全面的な検証・承認が適用されます。
   • ホットフィックスリリース：バグ修正やユーザビリティ向上関連のソフトウェア改訂。修正が行われた特定の要素に対する検証・承認が適用されます。

医療機器製品のアップデートに際して、再認証が必要かどうかの判断に役立つ、3つのパターンを以下に示します。

1. 「意図する目的」の記述内容を拡大するような新しい機能の追加は、「重要な変更」として扱われます。この場合、臨床評価プロセスをやり直し、新しいUDI-DIを割り当て、新しいソフトウェア製品識別文字列を付与します（例：バージョン1.1.0から2.0.0に引き上げる。製品識別文字列はUDI-DIとは異なることに注意）。その後、再検証を経て、再び市場に出すための承認を得る必要があります。
2. 既存製品の技術的なアップデートは、「重要でない変更」として扱われます。その際は、UDI-DIはそのままで、ソフトウェア製品識別文字列を更新（例：バージョン2.0.0から2.1.0へ）して、 新しいバージョンのリリースを行います。
3. セキュリティパッチおよび小規模な問題の修正は、「重要でない変更」のホットフィックスとしてリリースできます。UDI-DIはそのままで、ソフトウェア製品識別文字列を変更します（例：バージョン2.1.0から2.1.1へ）。

このようにSaMD（プログラム医療機器）では、各構成要素をモジュール化し、的確な情報を入手することで、規制のハードルをより容易にクリアできるだけでなく、柔軟性を獲得して、製品の更新や進化をより迅速に行えるようになります。

医療機器開発の世界は複雑だと思われるかもしれませんが、患者さんや医療提供者、ヘルスケア分野の関係者全体に価値をもたらす、可能性に満ちた分野であることは間違いないでしょう。