![見出し画像](https://assets.st-note.com/production/uploads/images/108136948/rectangle_large_type_2_ae536450b70dad8633bc056cf4471574.png?width=1200)
【医療機器開発プロセス】 第1章 開発研究編①:開発コンセプトを立てよう!
「『誰』に対して『どんな製品』を提供することで、『どんな利益』をもたらすのか」という製品の開発コンセプトを立てることで、どこを向かって開発をすればいいかが明確になります。
言ってみれば、開発コンセプトを立てることは、目的地の設定です。
医療機器では、診療ガイドライン、薬事、保険といった特有の事情を考慮して、コンセプトを立てる必要があります。
このコラムでは、医療機器の開発コンセプトの整理に便利なフレームワークであるPICOをもちいて、どのようにコンセプトを明確にしていくかをお話しします。
製品コンセプトをPICOで整理しよう!
製品コンセプトを決めるとは、「『誰』に対して『どんな製品』を提供することで、『どんな利益』をもたらすのか」を明確にするということです。
恐らく、この定義は、医療機器以外でも同じかと思います。医療機器の場合には(医薬品も同様ですが)、病気ごとの診療ガイドラインや、薬事や保険に合わせたコンセプトの整理の仕方が必要になります。
医療機器の製品コンセプトの整理に有用なのが、PICOというフレームワークです。
PICOとは、Patient(患者)、Intervention(介入)、Comparison(比較対象)、Outcome(成果)の頭文字をとったものです。
それぞれの観点で言語化することで、医療機器のコンセプトが明確になってきます。
![](https://assets.st-note.com/img/1671970144322-lotBxp8LGP.jpg?width=1200)
以下では、P、I、 C、O、のそれぞれでどのようなことを考えればよいのかをお話いたします。
P(Patient)は対象患者のこと。
疾患ごとの病期や重症度、受けている治療などで定義
Patientの項では、その医療機器が『誰』に対して利益をもたらすかを定義します。
一般的な商品では、マーケティングの中で、属性(性別、年齢、地域など)やライフスタイルなどで、ターゲット顧客を定義しますが、それ以外の人も購入し使うことを制限するものではありません。
それに対して、医療機器の場合は、診療ガイドラインや、薬事・保険といった規制の中で、その医療機器が使われる患者さんが特定され、そこで特定された患者さん以外には原則使われません。
診療ガイドラインや薬事・保険では、まず、疾患で患者群が分かれ、その中で病期や重症度で分かれていきます。さらに、ある重症度の患者の内、1次治療を受けている患者、1次治療が効かずに2次治療を受けている患者というように細分化されていきます。
こうした疾患ごとの病気や重症度、治療状況などの軸で分類して、対象患者を特定していくことが、医療機器においては重要といえます。
![](https://assets.st-note.com/img/1671970317659-XLPsZWzi89.jpg?width=1200)
I(Intervention)は開発製品のこと。
製品の仕様だけでなく、治療/診断アルゴリズムにおける位置づけも明確に。
Interventionは直訳すると介入ですが、要は開発製品の概要です。
開発製品が、どのような原理なのか、どのような構造、性能なのか、どこでどのように使われるのか、などの開発製品の概要をまとめます。
開発製品自体の概要に加えて、もう一つ重要なのは、対象疾患における治療/診断アルゴリズムにおける開発製品の位置づけです。
診療ガイドラインなどでは、患者さんに治療/診断をする標準的なフローが決められていることが多いです。この疾患のこの病期の人には、最初にこの治療を行い(1次治療)、その治療が効かない場合には別の治療をする(2次治療)、というような感じです。
こういったフローを治療/診断アルゴリズムといい、下記のようなフロー図であらわされることが多いです。
![](https://assets.st-note.com/img/1671970329495-4h6GB8t6bO.jpg?width=1200)
このフローの中に、新しく開発する製品をどのように位置づけるのか、を明確にすることが重要です。それにより、対象とする患者やライバルとなる既存技術がより明確になります。
それらが明確になることで、その開発製品が、既存技術よりも、対象とする患者に対して、どのような利益をもたらすのかがクリアになります。
C(Comparison)はライバルとなる既存技術のこと。既存技術の課題も知っておこう。
Comparisonは比較対象、すなわち、ライバルとなる既存技術についてです。
ここでいうライバルは、技術的な類似性よりも、同じ対象患者に対して同じ利益をもたらすものです。がんの早期診断ということであれば、超音波エコー、MRI、X線CTなどがライバルとなりますし、がんの治療ということなら、手術、抗がん剤、放射線治療がライバルとなるでしょう。
実際には、Interventionの項でお話ししたように、治療/診断ガイドラインやアルゴリズムの中でより細分化した患者群に対して、どの治療をするかが決まっています。
アルゴリズムの中で、開発製品を位置づけた場所に並列にある技術が最大のライバルとなります。下記の図ですと、開発品のライバルは治療Dになります。
![](https://assets.st-note.com/img/1671970345139-Tjq6aSRAGi.jpg?width=1200)
ライバルとなる技術の概要を示すとともに、認識している問題点を明確に示すことが重要です。この問題点が、患者や医師にとって致命的であり、それを開発製品が解決できるものであれば、対象患者や医療を提供する医師は開発製品を選んでくれるでしょう。
O(Outcome)は開発製品が対象患者にもたらす利益のこと。
有効性、安全性、経済性などの観点で、ライバルに対してどこが優れるのかを表現しよう。
Outcomeは開発製品が対象患者にもたらす利益です。当然、初期段階では本当に実現できるかはわかりませんので、開発目標として定義することになります。
医療の場合、利益とは、有効性、安全性、経済性といった観点で見ることが一般的でしょう。これらは、必ず、Comparisonの項で特定したライバルとの比較によって語られるべきです。比較対象がなかったり、別の対象患者に使われている技術と比べてしまったりすると、対象患者に本当にもたらす利益とは言えません。
![](https://assets.st-note.com/img/1671970356223-fxi4MDOEOn.jpg)
ライバル技術よりも優れる点が、本当の意味で対象患者にもたらす利益に繋がり、開発製品の訴求ポイントとなります。
ただ、実際には、有効性、安全性、経済性のすべてでライバル技術よりも優れるということは稀ですので、トータルとしての判断となります。
どの項目が重視されるかは、疾患の特性(生死に関わる疾患かどうかなど)や重症度などによっても変わりますが、一般的には、有効性、安全性は経済性よりも優先度が高いです。
医療は社会保障の一面もありますので、安いからという理由で有効性や安全性に劣る医療が優先されては治る人も治らず、副作用も増えて社会としては良い状態とは言えません。有効性・安全性について審議される薬事承認が先にあり、その後に経済性の議論がされる保険適用があることも、そういった優先順位を反映しているのだと思います。
有効性、安全性、経済性について、開発製品の優位性を示す際には、具体的な指標で表現する必要があります。開発製品を使用することでライバル技術に比べ、対象患者さんの生存期間が〇〇か月伸びる(有効性)とか、副作用の発生率が〇〇%低くなる(安全性)とか、医療費が〇〇万円下がる(経済性)といった具合です。有効性、安全性に関しては、臨床試験で使われる評価指標で示すことが多いです。
患者にもたらす利益がライバル技術より上回る場合は、ライバル技術より優先的に使われるようになっていくことが多いです。下記の図で言うと、病期IVの患者さんには開発品が1次治療になり、治療Dは2次治療になっていきます。ライバル技術の方が患者の利益が高い場合は、位置づけは逆転します。
![](https://assets.st-note.com/img/1671970368142-TDLv1SoWYP.jpg?width=1200)
病期IVの中である特定の患者群には開発品の利益が高い場合には、そちらの群にのみ開発品が使われるようになったりもします。
![](https://assets.st-note.com/img/1671970382237-us8CeqT5Cx.jpg?width=1200)
こういった詳細な位置づけは、初期段階では情報が不足していて明確にできないことも多いので、開発を進めていく中で、コンセプトを見直していくことが重要です。
まとめ
医療機器の開発研究を始めるときに、製品コンセプトをまとめておくことが大事です。そのための便利なフレームワークとしてPICOを使用するとまとめやすくなります。
もちろん、開発の初期段階では、決まっていないことも多いと思いますし、開発している間に、色々なことが分かってきて、最初に決めたものが途中で変わることもあります。
ですが、いくつかの仮定が入っていても、目標として言語化し明確化することで、目指すべき道がクリアになると思いますので、ぜひ開発コンセプトをまとめてみてください。
※ PDF版(有料)をご用意いたしました。社内、学内等の勉強会等でご活用いただければと思います。記事を購入いただくとダウンロードできます。内容は記事と一緒です。
ここから先は
この記事が気に入ったらチップで応援してみませんか?