みなさん、こんにちは。
先日、プログラム医療機器（SaMD：Software as a Medical Device）に関するセミナーを受講してきました。
内容は、薬事該当性の判断から、PMDAによる審査、さらには保険適用まで、SaMDを開発するベンダーがどのように開発戦略を組み立てるべきかという、かなり実践的なものでした。
セミナー全体としては、薬事や保険制度などの法制度・手続きの話が中心だったのですが、私にとって最も強く印象に残ったのは、制度の解説そのものよりも、もっと開発の根本・思想に関わるお話でした。
それは、
「まったく同じ技術であっても、その技術を何のために使うものとして説明するかによって、医療機器になるかどうかが変わる」
ということです。
技術そのもののスペックやロジックではなく、その技術の「目的」や「役割」をどう定義するのか。今回はこの気づきについて、私自身の開発体験とも照らし合わせながら深掘りしてみたいと思います。
同じソフトウェアでも「説明（標榜）」で立ち位置が変わる
セミナーの中で、非常にわかりやすい例として挙げられていたのが「応力解析ソフトウェア」の例でした。
このソフトウェアが行っている内部処理そのものは、対象にかかる応力を計算して可視化するという、極めて純粋な工学データ処理です。
ところが、そのソフトウェアの用途をどう説明するかによって、薬事上の取り扱いが大きく変わります。
- ケースA
「応力を解析・可視化し、その結果を研究や工学的評価に利用する」と説明する場合
⇒ 医療機器には該当しません。 - ケースB
「応力解析の結果を用いて、骨粗鬆症の診断を行う」と説明する場合
⇒ 医療機器（SaMD）に該当します。
内部で動いているプログラムや解析ロジックは全く同じなのに、社会や利用者に対して「何をするものとして説明（標榜）するのか」によって、規制の対象になるかどうかの境界線が引かれるわけです。
ここで問われているのは、言葉の綾で法律をうまくかわすことではなく、製品の目的をどこまで本気で定義できているか、ということです。
「自分たちの技術を、現場の何のために使うのか」という役割を最初に決めることが、すべての開発のスタートラインになるのだと痛感しました。
改めて「技術の役割」について考えてみた
ここからは、セミナーで説明されていた制度そのものの話から少し離れて、私自身が考えたことを書いてみます。
セミナーでは、医療従事者の業務支援として、次の２つのアプローチが紹介されていました。
- このデータから特定の病変を自動的に検出・診断する
- 統計的な数値や過去の文献情報などを整理して医師に提示し、最終判断は医師に委ねる
ここで語られていたのは、あくまで「何を目的とし、どう標榜するか」という薬事該当性の話です。ただこの説明を聞きながら、私はもう一歩先の「医療現場で技術にどこまでの役割を持たせるべきか」という問いを考えていました。
医療DXでAIやソフトウェアを導入する際、技術の役割は大きく2つに分かれます。
- システムそのものに診断や判断を担わせる
- 必要な情報を集め、整理し、医療従事者が判断するための材料として提示する
この二つは、利用しているAIやデータ解析などの要素技術が近かったとしても、システムの設計思想としては大きく異なります。そして今の医療現場においては、後者のアプローチにこそ大きな可能性があると感じています。
チェスや将棋のように、AIが99%の確率でAIが人間を超える領域なら前者を任せてもよいのかもしれません。しかし、複雑な条件が絡む医療現場ではまだ十分とは言えません。
現場の医療従事者から判断の主体性を奪うのではなく、
- 必要な情報を集める
- 膨大なデータを人間が見やすい形に整理する
- 微細な変化を見つけやすく可視化する
- 過去のデータとの比較を可能にする
ここまでをテクノロジーが担う。そして、その先にある「では、どう対応するのか？」という判断は、現場の医療従事者に残す。そうした役割分担の設計に、医療DXのひとつの本質があるのではないかと考えています。
「MEGTAR」の開発と、AI・IoTに求められる役割
このようなことを考えながら、私は自分が開発を進めてきた医療機器監視システム「MEGTAR」の試行錯誤を思い出していました。
MEGTARは、病室にある医療機器のアラームや画面情報をカメラとマイクで取得し、必要な情報を医療従事者に届けるシステムです。
医療機器から発せられる情報を取得し、整理してスタッフに提示する。その情報を受け取った看護師さんや医師が、
- 「今すぐこの部屋に駆けつけるべきか」
- 「急変の兆候なのか、それとも経過観察でよいのか」
- 「他のスタッフに応援を依頼すべきか」
といった対応を判断します。MEGTAR自体が「患者さんの病状が危険かどうか」を自動で診断・判定することはありません。
「人間の代わりに判断させること」ではなく、「人間がより正しく、より迅速に判断するための材料を届けること」に役割をフォーカスしているわけです。
今回のセミナーで個別プロダクトの話が出たわけではありません。ですが、「そのプログラムは何をするものかを定義する」という話を聞いたことで、自分が医療IoTの開発現場で直面してきた「技術の役割」という問題を、改めて見つめ直すきっかけをもらいました。
そして、薬事上の「使用目的」や「標榜」という考え方と、プロダクトを設計するときの「役割を定義する」という考え方には、非常に深い共通点があると感じています。
技術を作りながら「関係」と「役割」を再設計する
医療DXのシステムを企画するとき、私たちはつい技術のスペックや機能から考え始めてしまいがちです。
- 「最新のAIを使えば、こんな解析ができます」
- 「高精度なカメラを使えば、ここまで認識できます」
- 「IoTセンサーで、こんなデータがリアルタイムで取れます」
作る側としては、どうしても技術の「できること」に目が行ってしまいます。しかし、それらをいくら詰め込んでも、現場で本当に信頼され、使われるシステムになるとは限りません。
重要なのは、
- その技術を使って、誰の、どんな仕事を、どこまで支援するのか
- そのシステムは何をして、何をしないのか
- 最後に誰が判断を下すのか
という「人間と技術の役割分担」を明確にすることです。
ただし、この役割分担は最初から机上で完璧に決まるものではありません。実際のところ、技術を現場に持ち込み、動かしながら調整を繰り返し、「関係」と「役割」を何度も再設計していくプロセスが不可欠です。
そしてSaMDとして開発する場合、もう一つ極めて重要な視点があります。それは、試行錯誤の末に固まった使用目的や仕様の範囲と、それを証明するためのエビデンスを、申請の段階で完璧に合致させておくことです。
セミナーでは、申請書で広い範囲を「できる」と主張しながらエビデンスが追いついていない状態を「白い部分」と表現していました。この白い部分を残したまま申請すると、後から使用目的を削るか、追加の臨床データを集め直すことになり、開発が1〜2年単位でストップするリスクがあります。
つまり、「できること」を広げることと、「証明できること」を広げることは全く別物です。
作れるものを作ってから使い道を考えるのではなく、現場での試行錯誤を経て「どんな役割を担う製品にするのか」を定め、その役割を過不足なく証明できるように技術とデータを揃えていく。この順序立ての重要性を、改めて痛感しました。
技術の価値は「何ができるか」だけでは決まらない
AI、IoT、そしてSaMD。
次々と新しい技術が登場する時代だからこそ、私たちは「何ができるのか」という機能面の説明に心を奪われがちです。
しかし、医療現場で本当に機能する技術を届けるためには、もっと前に考えておくべきことがあります。
- そのシステムは、現場で何を担うのか？（何をして、何をしないのか）
- 人間とシステムの役割分担をどう設計し、現場でどうすり合わせていくのか
- そのシステムが提供する価値を、どのような言葉で定義し、どうやって証明するのか
今回のセミナーは、形式上はSaMDの薬事や保険制度を学ぶ場でした。しかし私にとっては、「同じ技術でも、それを何のためのものとして定義し、説明するかによって社会的な位置づけが変わる」という、プロダクトデザインの本質を深く考える機会となりました。
医療DXにおいて本当に設計しなければならないのは、そのシステムが現場でどんな役割を担い、現場の人々とどう関わっていくのか、という「役割」と「関係性」です。
そして、その役割を泥臭くすり合わせながら言葉にし、データで証明していくこと、それこそが、これからの医療技術に関わる私たちが果たすべき「本当の役割」なのだと思います。
本日も最後までお読みいただき、ありがとうございました。
それでは、よい医療DXを！
「うちの現場でもこういう仕組みが欲しい。でも既存の機器には手を入れられない」——そんなお悩みはありませんか。
ビューローみかみでは、構想段階の壁打ちからPoC・実装・現場導入まで、医療・介護の現場で「使い続けられる」ものづくりを支援しています。
医療機器の後付けIoT化から閉域網の構築まで、現場の制約を前提に「今の体制・予算で成立する構成」を一緒に考えます。
▶ 医療・介護IoT開発サービスの詳細はこちら
気になることがあればお気軽にご相談ください。
