症状チェッカーからスマートチャットボットへ：AIが果たすバーチャルケアにおける役割
本文の状態
日本語全文を表示中
詳細モードで約46分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
InfoQ
アンドレ・リベイロ氏が、Healthily社のAI症状チェッカーのアーキテクチャについて説明し、ベイズ推定とRAGモデルが医療的知見と患者の確信ある行動を結びつける方法を解説した。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
InfoQ ホームページ
プレゼンテーション
症状チェッカーからスマートチャットボットへ：バーチャルケアにおける AI の役割
プレゼンテーションを見る
所要時間：48:28
概要
アンドレ・リベイロは、Healthily の AI による症状チェッカーのアーキテクチャについて解説します。彼は、ベイズ推論（Bayesian inference）と RAG モデルが、医療的洞察と確信を持って行動する患者との間のギャップをどのように埋めるかを説明します。
Bio
アンドレ・リベリオは、データエンジニアリング分野で 10 年以上の経験を持ち、現在イギリスの Healthily で最高技術責任者（CTO）を務めています。インペリアル・カレッジ・ロンドンで神経画像処理に関する博士号を取得し、リスボン大学では生物医学工学および生体物理学の修士号を保有しています。彼の専門分野は、多様な領域における現実世界の課題解決のために高度な技術を応用することです。
About the conference
ソフトウェアが世界を変えています。QCon London は、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発を強化します。実践者主導の会議である QCon は、チーム内でイノベーションに影響を与える技術チームリーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャーを対象に設計されています。
INFOQ EVENTS
2026 年 5 月 12 日 午後 1:30（EDT）
アジェンティック AI のためのデータレイヤー設計：スケールにおける状態、メモリ、調整のパターン
登壇者：Karthik Ranganathan - YugabyteDB 共同 CEO & 共同創業者、および Aditi Gupta - AWS GTM Data and AI シニア GenAI/ML スペシャリスト ソリューションアーキテクト
2026 年 5 月 21 日 正午（EDT）
設計によるポータビリティ：マルチクラウドシステムのためのデータ移動性と回復のパターン
発表者：Liore Shai - Eon のソリューションアーキテクト
2026 年 5 月 28 日 午後 1 時 EDT（東部夏時間）
AI の時代における配送システムの再考：より迅速な配送と、より多くの破壊
発表者：Eric Minick - Harness の DevOps ソリューション担当シニアディレクター、および Aaron Newcomb - Harness のシニアプロダクトマーケティングマネージャー
転記内容
Andre Riberio: Healthily に関する内容、すなわち症状チェッカーからスマートチャットボットへの移行についてご説明いたします。まずは物語から始めましょう。午前 2 時、7 歳の男の子が頭痛と発熱で目を覚ましました。救急（A&E）の状況には見えないものの、両親は依然として心配しています。彼らは Google で検索し始めます。すると不安が増幅し、 Meningitis（髄膜炎）だと信じ込みます。これは Google で検索した際に表示される上位結果の一つです。10 分後、彼らはそれを確認しようと救急部（A&E）へ向かいます。しかしすぐに、これは自宅で自己治療が可能な副鼻腔炎だったと気づきます。
彼らは時間を失い、ストレスを抱え、自分自身の判断に対する信頼を失いました。これはある一つの家族の話に過ぎません。もう一つの事例を見てみましょう。68 歳の男性が娘に電話をかけ、言葉につまっています。彼は少し混乱していましたが、突然正常な状態に戻りました。彼は娘に自分は問題ないし、おそらく単なるストレスのせいだろうと、本当に心配することはないと言いました。娘はオンラインで検索しましたが、特定の理由を見つけられず、二人とも朝まで待つことにしました。父親が経験したのは一過性脳虚血発作（TIA）または微小脳卒中でした。これは基本的に、今後 48 時間以内に本格的な脳卒中が発生する可能性を示す警告サインであり、恒久的な状態や最悪の場合の死を避けるために、直ちに行動を起こす必要があります。
これらは表裏一体の二つの側面です。一方には、救急外来（A&E）受診につながったセルフケアのシナリオがあり、これが NHS のコスト増、ストレス、そして自信の喪失をもたらしました。他方では、父親と娘の両者によって見落とされた緊急事態があり、それが長期的な影響を招く可能性がありました。これらのケースにおける問いは常に同じです。「私は何をすべきか？」「私の特定の状況において、今すぐ何をすべきか？」これは決して特殊な問題ではありません。この二つの事例に限った話でもありません。英国だけでも年間約 5,000 万件の健康関連検索が行われており、すべての年齢層で増加傾向にあります。
オンライン上で健康に関する質問を検索する人が増えています。ここで本当に問われているのは何でしょうか？情報を得ること自体の問題なのか、それともどう行動すべきかという問題なのでしょうか。私たちが実際に解決しようとしているのは、人々を潜在的な結果から、実際に行動に移せる状態へと導く方法です。ユーザーの視点から全体の流れを追ってみましょう。ユーザーは症状から始めます。それはユーザー自身が報告した症状でもあれば、別の人物で観察された症状でも構いません。頭痛や発熱、あるいは言葉が不明瞭になることなどが該当します。
次に、それが何である可能性があるのかを特定します。髄膜炎かもしれないし、副鼻腔炎かもしれないし、単なるストレスかもしれません。しかし、自分たちが取るべき行動はまだ分かりません。何が起きる可能性があり、複数のバリエーションがあることは分かっていますが、具体的にどう行動すべきかは不明です。これが現在の状況です。これは私にとって今すぐ何を意味するのか、私の特定のシナリオにおいて何が必要なのか。それが知りたいことです。それを実現したいのです。彼らが本当に求めているのは、自信を持って行動できる能力です。洞察から行動へと最後の一段階を踏み出しましょう。ユーザーの質問は「私は何をすべきか」でした。これはもちろん非常に重要なニーズに基づいているだけでなく、利用可能な医療へのアクセスや自分が対象となる制度に基づいて equally 決定されるべきものです。例えば、イギリスにいる場合とアメリカにいる場合では、対応が異なります。これらすべてを考慮に入れる必要があります。これが私たちが現在健康保険会社と提携し、彼らが持っているものと実際にできることの間の欠けているリンクを作成しようとしている理由の一つです。
背景
私はアンドレ・リベリオです。AI および機械学習システムにおいて10 年以上の経験があります。医療分野だけでなく、アート分析などの他の分野でも活動してきました。生物医学工学を専攻し、その後インペリアル・カレッジで臨床医学研究の博士号を取得しました。現在はヘルスリー（Healthily）の最高技術責任者（CTO）として、これからご紹介するシステムの全体統括を担当しています。
理想的なシナリオ
問題についてお話ししましたが、今度は解決策についてもう少し詳しくお話しましょう。この特定のケース、つまりこの娘さんの場合における理想的なシナリオとは何でしょうか？彼女が真に望んでいるのは、正確にアドバイスし、人間のミスを減らすシステムです。彼女は刺激から行動に至るまでの時間を最小限に抑えたいと考えており、それによって対応時間の短縮を図っています。また、このケースでは脳卒中という完全な発症という将来のリスクを最小化したいと考えています。さらに、自分が取っている行動が正しいものであるという安心感も得たいのです。ヘルスリーではこれをどのように実現しているのでしょうか？
ヘルスリーでは、まずスマート症状チェッカーの作成から始めました。このスマート症状チェッカーは、臨床医、すなわち医師によってゼロから開発されたツールに基づいています。これは当社が自社で構築した医療データベースに基づくものであり、臨床的に検証済みであり、AI ツールでもあります。さて、ここで疑問が生じるかもしれません。「では、AI ツールの精度をどう保証するのか？」と。その点については後ほど詳しく説明しますが、基本的にはベイズモデルと呼ばれる手法に依存しています。これは数学や統計学に深く根ざしたものです。最後に、先ほどお話しした通り、私たちは医療保険会社と連携し、この欠けていたリンクを作成しました。
システムアーキテクチャ
背後で何が行われているのかを把握していただくために、システムのアーキテクチャについて少し概説させていただきます。他のすべてのアプリケーションと同様に、私たちはユーザーインターフェース、Web アプリ、API、あるいはその他の要素から始めます。今回の場合、ユーザーは自然言語処理（Natural Language Processing）からスタートします。「体調が悪い」「熱があるし腹痛もある」といった表現で入力できます。このシステムは、私たちが「自然言語処理およびチャットエンジン」と呼ぶ部分を経て処理されます。このエンジンは、3 つの異なる他のシステムへとルーティングします。すなわち、臨床推論エンジン（Clinical Reasoning Engine）、セマンティック検索エンジン（Semantic Retrieval Engine）、そしてフロー駆動型臨床ロジックです。最初の「臨床推論エンジン」は、特に基本ロジックを処理し、評価のケースの大部分を担当するものです。
2 つ目は、ユーザーが情報を検索している場合です。これは後ほど詳しく説明しますが、BM25 と密なエンコーディング（dense encoding）を活用して機能します。要するに、ユーザーとデータベース間のすべての意味的な関係を処理する役割を担います。
3 つ目は、どの症状チェッカーでも対応できないケースです。これらは自殺念慮など、ユーザーが陥りかねない危険な状況に該当します。これらのケースはすべて、個別のケアガイダンスとして統合されます。基本的には、医療保険と連携し、ユーザーが必要とするサービスを提供します。これはまさにその人のニーズに特化したものです。
単に「医師を受診してください」と伝えるのではなく、「MSK パスウェイ（MSK pathway）を利用してください」「24 時間対応の看護師に連絡してください」など、具体的な行動を指示します。これが真にユーザーが求めていることです。彼らが知りたいのは、現在の症状や課題に基づいて、どのような行動を取るべきかという点です。
自然言語処理とチャットエンジン
システム自体を詳しく見ていきましょう。自然言語処理（NLP）とチャットエンジンについて掘り下めます。これは主に 3 つのマイクロサービスから構築されています。実際にはもう少し複雑な要素もありますが、要約すればこのようになります。
最初のモデルは意図検出モデルです。ユーザーが情報を求めているのか、評価を求めているのか、あるいは何を求めているのか不明確なのかを検出するモデルです。
次に「ワークアラウンド分類器」と呼ぶものがあります。これは危険なトピックに関連するトピックと整合性を取るモデルで、ユーザーが「自殺願望がある」のような発言をしているかどうかを特定します。通常の症状チェッカーでは対応できず、非常に特定のフローに従う必要があります。
また、症状エンティティ抽出も行います。ユーザーの生のクエリ（例：「頭痛と発熱があります」）に対して、この場合であれば「頭痛」と「発熱」を検出し、これらを他のサービスへ引き渡す潜在的な症状として扱います。
最後に、このシステムは評価が可能かどうかを検出するために用いられ、これによって次に取るべきステップを決定します。私がここで伝えたい核心は、これが医療製品であり、現在クラス I 医療機器に分類されている点です。私たちは各システムの安全性と制御に非常に注力しています。マイクロサービスとして設計され、独立して動作するのは、適切に検証可能にするためです。
特に意図検出モデルは、前年に手動でラベル付けされたデータを用いて訓練されました。前年にはそのデータセットを見直し、それが情報提供、評価、あるいはその両方ではないかを判断しました。
その後、インターフェースには動的なボタンを追加し、ユーザーが情報提供を望むか評価を望むかも選択できるようにしました。私たちはこの二つの情報を組み合わせて独自のトランスフォーマーモデルを微調整し、意図検出機能を実現しています。
一方、ワークアラウンド分類器は、双子型ニューラルネットワーク（Siamese Neural Network）を用いて訓練されました。このネットワークは、ユーザーのクエリとシードクエリの埋め込みベクトルを比較します。シードクエリはトピックに関するものであり、自殺念慮のようなメンタルヘルスの状況や火傷、あるいは異なるシナリオなどが含まれます。
これら二つの埋め込みベクトルに基づいてコサイン類似度（cosine similarity）を算出します。これは本質的に、これらの埋め込みベクトル間の類似度を意味しており、それによって閾値を設定することが可能になります。
当社の臨床チームは、各トピックの精度と正確性をバランスさせ、閾値を定義しました。また明確にしておきたいのは、モデルを構築するだけでなく、そのようなモデルのガバナンスや規制についても重要だということです。我々には、初期から終末まで検証し、レビューし、さらに継続的にモデルを見直して精度を保証するための一連のプロセスが備わっています。
次に紹介するのは、UQML モデルの最終段階である症状エンティティ抽出です。実際にはこれを「Mediterm モデル」と呼んでいますが、若干の違いはあれど同じ領域に属するものです。このモデルは Stanford CoreNLP を基盤としており、独自のデータセットによって強化されています。我々は独自の中医学概念と類義語を追加して拡張しており、これらは機密情報です。このシステムには2 つの主要なポイントがあります。1 つ目はラベルベースの概念活性化です。例えば「頭痛」から始めると、「頭」という概念と「痛み」という異なる概念の 2 つが同時に活性化されます。
これら 2 つは特定のシナリオにおける頭痛という単一の概念に統合されます。システムは単なる単語や複数の単語を拾い上げるだけでなく、それらをより高次レベルの症状へと組み合わせることが可能です。
2 点目は階層的な症状伝播です。私たちは足の裏の痛みから始め、これを一つの概念として特定しましたが、その親概念である「足の痛み」も同時に活性化させることができます。なぜ这样做するのかというと、論理的に考えて、足の裏に痛みがあれば当然足全体にも痛みがあるためであり、これにより症状チェッカーの信頼性と網羅性が向上するからです。これは後ほど詳しく説明します。
臨床推論エンジン
NLP の部分については説明しました。すべてを解説するわけではありませんが、上位 2 つについてのみ説明します。この NLP は、これら 3 つのシステムへルーティングするためのエンジンであり、モデルである臨床推論エンジンが使用する症状を提供するエンジンでもあります。このエンジンとは何かというと、先ほど説明した通り、ベイズ推論、安全性ルール、そしてレッドフラグ（危険信号）を取り込み、これらをすべて組み合わせることで、最終的にユーザーに次に質問すべき一連の問いを提示します。NLP モデルによって提供された構造化された症状入力を受け取り、それをベイズ推論、安全性ルール、レッドフラグへと渡します。実際に着手するのはまずレッドフラグからです。例えば、ユーザーが胸痛を報告したケースを考えてみましょう。これはレッドフラグ症状です。なぜなら、多くのレッドフラグに関連する病態と結びついており、それらは危険だからです。したがって、システムは直接「最近の怪我」について質問します。その理由は、胸痛と関連する複数の病態が存在し、かつ最近の怪我も関与している可能性があるからです。
もし直近の怪我を除外できれば、したがって特に危険な状態も除外できることになります。これが私たちがまず行うことです。私たちは安全なトリアージに非常に焦点を当てようと努めます。その後、ベイズ推論部分が担う大規模モデルへと移行します。これらは2つの簡略化された数式ですが、基本的に必要な情報はすべてここに含まれています。仕組みとしては、次の質問ラウンドで得られる情報を最大化しようとするものです。ユーザーは胸痛があると言いました。また混乱しているとも伝えてきました。今、私たちはシステムの不確実性を減らすために、彼らに尋ねるべき最適な症状のセットは何なのかを問う必要があります。これはベイズ推論を通じて、特定の症状セットが与えられた場合の病気の確率を計算し、さらにその確率分布も算出することで実現します。エントロピーを計算し、それを最小化することにより、エントロピー最小化の観点から尋ねるべき上位の症状セットを特定します。
したがって、複数の質問ラウンドを行うことができます。システムの前向きな確率を継続的に改善し、システムが保有する知識と、特定の病態である可能性に対する自信度を高めていきます。これにより、あらゆる時点で可能な病態のリストを順位付けし、関連するトリアージレベルも提示できます。
このようにできるため、各病態の後向き確率（事後確率）を計算することが可能です。これは前述と同じ数式です。ここで重要なのは、特定の閾値が設定されている点です。複数の質問を跨いで行うことで、それが潜在的な病態であるという確信は次第に高まります。
医療チームはこの閾値を90%と定義しました。これは少なくとも12ラウンド（質問のやり取り）を通じて達成されるものであり、システムが結果を提供して完了するのに十分な自信を持っていると判断する基準となります。後ほど示す病態は、この特定の閾値だけでなく、ユーザーとの関連性の度合いにも依存します。
症状からその結果に至るまで、すべてを説明します。しかし、これは私がこのカンファレンスの冒頭から言いたいこととは異なります。重要なのは、推奨されるトリアージと実行可能な次のステップです。私は何をすべきか？ここが健康保険との連携において非常に重要な点となります。これにより、彼らが何ができるのかという具体的なリンクが得られるのです。
これは単なる例ですが、ユーザーは腰痛から始めました。これは筋骨格系（MSK）のシナリオであり、理学療法パスウェイを推奨するに至りました。この場合、保険会社は直接紹介を行う手段を持っています。医師と直接話すことを飛び越え、必要な場所に直接つながるのです。
あるいは不安の場合、メンタルヘルスへと導かれます。自己ケアで済む場合もあれば、システムがセラピストの必要性を判断する場合もあります。その際、保険会社がカウンセリングアプリをカバーしている可能性もあります。
胸痛の場合は緊急性が高いです。これは救急（A&E）シナリオである可能性を検知したため、直接 999 に電話するよう案内します。あるいは、保険会社にオプションがある場合は、保険会社にも連絡するよう案内します。
最も一般的なケースとして、通常の一般開業医（GP）への相談があります。これはあらゆる症状チェッカーで目にする典型的なシナリオです。状況に応じて、ビデオ通話による GP 受診や対面での受診を案内することもできます。これもまた、保険会社と直接予約できる仕組みとなっています。
デモ - Healthily のスマート症状チェッカー
これは、医療提供者と現在トライアル中の非常に簡単な例です。ユーザーには保険関連情報に関する多くのナビゲーションツールが表示されています。彼らは症状チェッカーに入ることにしました。年齢と性別を入力し、安全に症状チェッカーを利用できないような稀な疾患は持っていないことを確認します。そして、当初の訴えである「言葉が不明瞭になる」という症状を伝えます。システムはその情報を基に判断し、実際にその症状があるかどうかを確認する質問を行います。これは非常に重要です。私がここで伝えたい本質的な点は、常に確実性を確保したいという点です。承認ポイント（ratification point）は、私たちが検出した内容が実際に正しいことを保証するため、極めて重要なポイントとなります。その後、評価を継続することを選択します。その症状は数時間だけ続いたと述べています。高血圧があり、肥満でも喫煙者でもありません。わずかな混乱があり、それは新しい状態の混乱でした。怪我はありませんでしたが、言語や発話に若干の困難があるとのことです。
その後、システムは異なる質問セットを繰り返し提示します。先ほど説明した通り、これはトリアージ（選別）や危険信号の検出、そして患者が抱えている可能性のある病態に関連するものです。このプロセスは数ラウンド行われますが、あまり長くならないことを願っています。これにより、現在の状況についてかなり正確な理解を得ることができます。また、確率モデルを用いる際、イエスと答えたことだけでなく、ノーと答えたことも同様に重要であることを覚えておいてください。なぜなら、それによって特定の病態を除外したり、その発生確率を下げたりできるからです。
システムが十分な自信を持てるまでには数セットの質問が必要ですが、その段階でレポートを提供します。
このケースでは、救急車が必要な状況であるため 999（緊急通報番号）を推奨しました。なぜそうなるのかは後ほど詳しく説明します。これらは除外された事象です。最も可能性が高いのは、ここに直接示されている一過性脳虚血発作（TIA）と、脳卒中を意味する虚血性障害です。また、ユーザーが他の選択肢を選択することも可能です。これらの推奨を行いますが、医師の診察を受けたい場合はもちろんそうすることもできると伝え、111（非緊急医療相談番号）へ電話することも案内します。さらに、ユーザーが入力した内容に関する情報も提供し、自分の症状が正確に反映されているか確認できるようにしています。これらすべてを説明しており、症状から病態、そして具体的な行動指針に至るまで解説しています。
対話型チャットボットへの進化
次に皆さんにお見せするのは何でしょうか？まだカバーしきれていない、欠けているものがあります。それは、ユーザーが単なる質問から始める場合があるということです。彼らはまだ明確な症状を持っていないか、あるいは症状はあるものの、どこに向かうべきか本当に分かっていないこともあります。最初は単純な健康に関する質問からです。これをどう扱うべきでしょうか？また、こうした人々にもターゲットを絞ってアプローチできることをどう保証すればよいのでしょうか？そこで私たちは、会話型チャットボットの活用、つまり症状チェックから完全な会話型チャットボットへの移行を検討し始めました。では、具体的に何をするのかというと、ここでは詳細に立ち入るつもりはありません。これは現在構築中の全く新しい製品ですが、その仕組みを正確にご説明します。このシステムは RAG（Retrieval-Augmented Generation：検索拡張生成）モデルに基づいています。私は、これが医療分野においてどのように適用されるかについて解説いたします。
まず、質問意識型トランスフォーマー（question aware transformer）から始めます。これは、ユーザーが「COVIDとは何か」と問いかけ、続いて「症状は何か」と尋ねた場合、「COVID の症状は何ですか？」という質問を生成できることを意味しています。これにより、過去の文脈を統合した質問意識型のトランスフォーマーによる質問を作成します。なぜこれが重要なのかというと、この質問を使って、英国で最大級の健康データベースを検索するからです。データはリトリーバーモデル（retriever model）によってチャンク化されエンコードされた上で、ユーザーの問い合わせに対して検索が行われます。さらに精度を高めるために、「リーダーモデル」（reader model）と呼ばれる技術も活用します。これは各チャンクを確認し、問い合わせに最も一致するスニペットを抽出するとともに、それらのランク付けも行います。これらのすべてのモデル、つまりこの2つと以前のモデルは、すべて独自の独自データを用いてファインチューニングされています。これは、当社のシナリオにおいて可能な限り高い性能を発揮させるためです。また、各機能を個別に制御し、どこで失敗が発生するかを把握できるようにするため、これらは特定のマイクロサービスとして実装されています。
そして最後に、誰もがそうするように、LLM（大規模言語モデル）の世界における回答生成へと進みます。ここでは商用利用可能なモデルを使用しています。また、以前と同様に、独自のファインチューニング済みモデルの開発にも取り組んでいます。状況は非常に急速に進化しており、言語モデルの性能も著しく向上しています。私たちは、可能な限り最良のソリューションを提供できるよう努めています。現在、入手可能な中で最も優れたモデルを採用していますが、単に LLM を採用してそのまま使うだけではありません。実際には、システムが安全であることを確保するために、多くのガードレール（安全装置）を構築する作業を進めています。
RAG（検索拡張生成）モデルに基づき、制限された知識領域への対応を検討しています。つまり、モデルが回答するのは健康に関連し、かつ当社のデータに基づく質問のみとするよう保証します。事実確認を行い、LLM が提供する回答が実際に与えられたコンテンツに基づいていることを確認します。不確実性の推定も重要です。これは本当にハルシネーション（幻覚）を起こしているのか、それとも正しい答えなのか？そして安全なのか？おそらくこれが最も重要な点で、いかに安全であるかが問われます。例えば、「アレルギーに対して抗ヒスタミン薬を服用しても大丈夫ですか？」とユーザーが尋ねた場合、単に「はい、全く問題ありません」と答えることはできません。なぜなら、妊娠中の場合は特定の抗アレルギー薬を服用できない可能性があるからです。文脈がないため、これは直接的に安全ではない回答となります。現在、私たちはまさにこの課題に取り組んでいます。もちろん膨大な作業が必要ですが、安全なチャットボットの構築を目指しています。
デモ - Healthily のチャットボット
非常に速い例を一つご紹介しましょう。これは現時点では製品化されていません。現在、トライアルを実施中ですが、この内容の多くは変更される予定です。ここでは、先ほどお話しした内容とどのように連携するかを具体的に示します。
この場合、ユーザーは頭痛と発熱について質問しました。システムはそれに関する情報を提供し、さらに今回の場合は、私たちが提供するコンテンツである特定の URL についても案内しています。
その後、ユーザーは「なるほど、実はこれが娘の症状に似ている」と考えました（例では息子でしたが、ここでは娘として説明します）。彼らは髄膜炎ではないかと疑っています。この時点から、モデルは UQML モデル、あるいは私たちの意図検出モデルを自動的に認識し、直接症状チェッカーへ誘導します。
最後に確認できる内容は、以前ご紹介した症状チェッカーと同等の安全性を保証しています。質問の内容は依然としてベイズネットワークに基づいており、安全性を最優先に設計されています。ただ、対話型チャットボットという全く異なるシナリオで提示されている点が異なります。
今後の取り組み：症状チェッカーとチャットボットの連携
ここからどこへ向かうべきでしょうか。やるべきことはたくさんあります。例えば、症状チェッカーについては現在、クラス II 医療機器の認定を取得する取り組みを進めています。これは、当社のシステムに対する信頼性と臨床的な信頼性を確保するためです。すでにクラス I の医療機器として認定されています。チャットボットの側では、規制ガイドラインとの整合性を確保し、すべてのガードレールを構築しています。これにより、ある程度の安全性が保証されることを明確に言えるようになります。モデルの改善は継続しており、症状チェッカーおよびチャットボットの両方において行っています。
アーキテクチャについては、データの質向上に取り組んでいます。また、症状チェッカーがそのデータをどのように活用するかについても改善を進めています。これを実現するためのさまざまなプロジェクトを進行中です。一方、チャットボットでは、モデルの検索機能をより良くし、過去の発言内容をより意識させるよう努めています。さらに、症状チェッカーから得られる結果やレポートをチャットボットに直接組み込み、ユーザーがそれらについて質問できるようにすることを目指しています。
最後に透明性です。オンライン上で閲覧可能な透明性文書を用意しており、そこで私たちが何を行っているかすべてを確認できます。私たちは常にこの方針を堅持し、毎回そのように努めています。症状チェッカーの根拠（rationale）の改善にも取り組んでおり、なぜ特定の症状について質問するのかを明確にしています。チャットボットの側では、ハルシネーション（幻覚的生成）の低減、安全性の向上、出典の明示化に取り組んでいます。
要約
Healthily では、エンドツーエンドのシステム構築を目指しています。ユーザーからの質問や症状から始まり、最終的にその情報に基づいて実際に何ができるかというアクションに至るまでをカバーします。可能な限り会話形式で、自然な対話を実現することに取り組んでいます。ここがチャットボットの登場する理由です。確率モデルと安全性を意識したトリアージを用いた推論知能によって、システムを可能な限り安全かつ信頼性の高いものにするよう努めています。また、医療提供者や保険会社との連携を通じて、提供されるサービスが実際に適用可能で現実的なものであることを保証しています。ガードレールの作成やシステムの検証・監査可能性の向上により、臨床現場に可能な限り適合したシステムを目指しています。究極的には、私たちは人々のためにこのシステムを構築しており、ユーザーがより自信を持ち、適切なタイミングで行動できるよう誠実に支援することを目指しています。
質疑応答
クレインダー医師：これは大規模言語モデルが重要な役割を果たす主要な領域の一つです。クリック可能なリンクを経由するのではなく、実際に適切にチャットできるような保険適用可能なクラス II 製品が実現するのは、いつ頃になるとお考えですか？
アンドレ・リベリオ：私たちはまさにそれを探っています。もちろん、症状チェッカーについてはクラス II 医療機器から始めます。それが最初の部分です。それを基に段階的に構築しています。最後に示した対話型 UI は、ユーザーがその対話形式に徐々に慣れるための手段を提供します。規制当局に対して、「これは依然として同じ質問を全く同じ方法で行っているため、単なるフォーマットの違いであり、クラス II 医療機器であり続ける」と主張するのは容易です。
次に、そこから適切な自然言語へと移行できることを証明する必要があります。すでに、私たちはそれができるとお伝えできます。例えば、自然言語を使用することも可能です。私たちの NLP モデル（自然言語処理モデル）を使って、「これはあなたが言ったことですか？これはあなたが言ったことですか？」と繰り返し質問することもできます。ユーザー体験としては必ずしも最適ではないかもしれませんが、機能します。なぜなら、私たちが特定した内容に対してユーザーが「はい」または「いいえ」と回答し続ける限り、それは安全だからです。彼らが私たちの質問を確認していることになるからです。
目指すべきは、ある一定の確率（X 量）で安全であると確信できる点に到達することです。その X の値が具体的に何であるかはまだ不明ですが、私たちが許容でき安全だと判断できる数値です。それが目標となるポイントです。私たちは現在、症状チェッカーをクラス II 医療機器として扱っています。また、保険会社と連携してこれらのチャットボットを構築しており、人々がそれらを必要としているか、実際に利用しているかを検証しています。
そこから先は、境界線を押し広げ、さらに進んでいくことになります。そして、最終的にはクラス II の認定を目指すのです。
Dr. Kreindler: チャットとボタンをクリックすることの間に、使いやすさの違いに関する研究はすでに実施されていますか？
Andre Riberio: 最近、チャットボットの使いやすさを理解し、人々がそれを好むかどうかを明らかにする研究を行いました。例えば、評価の最後に統合される機能について、より古典的なアプローチであるフォームベースのアプローチと比較して、どちらを好むのかを検討しました。人々は、チャット形式が質問に組み込まれており、システムとの対話がより自然な方法のように感じられるため、チャット形式を好む傾向があるようです。
Dr. Kreindler: 公式見解ではありませんが、直感的にお考えください。臨床医としての私たちにとって、声のイントネーションやものの視覚的外観といった多様な情報（multimodal）を評価することは、どれほど重要でしょうか。「息切れしているようですが、声に少し喘鳴があり、それ以外は元気で明るく、頬も赤らんでいて健康そうに見えますね。おそらく、これは最悪の種類の息切れではないでしょう」。このような多角的な評価は、あなたのシステムのようなものにおいて、今後どの程度不可欠なものになるとお考えですか？
アンドレ・リベリオ：はい、もちろん。いずれその方向に進む必要があります。現時点では、例えばユーザーが皮膚の悩みを伝える場合、それについて質問することはできます。「赤いですか？」「均一ですか？」と尋ねることもでき、対応を試みることは可能ですが、依然として焦点はユーザーが何を知っているか、そしてどのように回答できるかに置かれています。その問題点は、システムがまだ画像を取得し、「これはこれである」と自信を持って断定する精度に達していないことです。そのため、この領域はまだ難しいのですが、いずれ確実にそこへ到達することになるでしょう。再び考えられるのは、画像から直接理解を試み、その後ユーザーの承認を得て、見ているものが一致しているかどうかを確認するようなシナリオです。現状とこれらのシナリオの間にはまだギャップがありますが、確かにそのようなケースが生まれることになります。
クレインドラー医師：少なくとも、その情報を収集し、テキストベースの情報よりも多くのデータを含む紹介状を提示することは可能です。それは今日でも実現できます。
アンドレ・リベリオ：はい。
参加者 1：承認（ratification）について言及されましたが、データ品質に関するさらなる課題や、それに対してどのような対策を講じたかについてお伺いしたいです。
アンドレ・リベリオ：承認のことですか？
参加者 1：はい、その件についてです。他にご存知のものはありますか？
アンドレ・リベリオ：はい。いくつかの制御システムがあります。承認（ratification）はその一つで、先ほどお話ししたものです。これはまさに、ユーザーからテキストによる質問があり、それを症状に変換する時点からのプロセスです。私たちは常に確認を求めます。ある時点で、「90% の確信があればそれでよい」という方針も検討しましたが、採用しませんでした。この特定のシナリオにおいては、少なくとも現時点では、常に「これが私たちが特定した正しい内容ですか？」と確認することが最善であると判断しました。また、システムは継続的に学習しており、データが蓄積され続けています。現在の数値に関する統計資料は手元にありませんが、将来の展望を示すスライドを最後に用意しており、現在の大規模言語モデル（LLM）と比較して、実際にどれほど優れているかを検証しようとしています。現在、データセットは整備されていますので、これから分析を進めていきます。もう一つの制御ポイントとして、「確認（clarification）」という仕組みがあります。これは、ユーザーが提示した症状が複数の意味を持つ可能性がある場合に用いられます。
ユーザーが複数の意味を持つ特定の症状を尋ねた場合、その中からどの症状を指しているのかを質問し、単なる確認だけでは不十分となるよう対応します。なぜなら、ユーザーは「はい」と答える可能性があり、それが異なる意味を持つことになるからです。私たちは別の選択肢のセットを提供し、ユーザーがそれを選択して進めることができます。これが制御ポイントです。これにより、私たちが行うすべてのテキストが、ユーザーの知識に基づいて正確であることを保証しています。その後、私たちが質問するすべての質問は、症状チェッカーで生成されたものではなく、私たちのデータセットから非常に具体的なものとなっています。これらは完全に管理されています。最後に、ユーザーに彼らが言ったことを正確に記したレポートを提供し、何か見落とされていないか常に検証できるようにします。実際には見落としがあってはなりませんが、もし見落としがあった場合でも、ユーザーがそれに気づくか、あるいは医師が気づくようにしています。なぜなら、私たちはそのレポートを医師にも提供できるからです。これらが制御ポイントです。
参加者 2: 複数の症状がある場合はどう対応しますか？例えば、足の痛みと頭痛があります。
アンドレ・リベリオ：はい。いいえ、確かに複数の症状を検出できます。存在するすべての症状を検出可能です。単一単語や複数単語の両方に対応しています。ただし、それらが非常に近接している場合、異なる概念を指す場合に混同することがあります。これは一般的ではありません。通常、裏側では、主要な概念とその関連する類義語を手動で作成したデータセットを使用しています。例えば、「頭痛」の場合、「頭蓋痛」「頭部疼痛」などが該当します。これらそれぞれが独自の概念となります。「頭蓋」は「頭」の類義語であり、「頭」は何らかの概念の類義語です。ユーザーが選択する任意の組み合わせでも、最終的に「頭痛」として認識されます。この仕組みは検索機能にも適用されており、どの組み合わせでも正しく動作します。いいえ、同じクエリ内での複数の症状や、各症状における複数単語にも対応しています。
参加者 2：それらは別々のものとして扱われるのでしょうか？
アンドレ・リベリオ：はい。
参加者 2：もしそれらが同一の問題の一部であれば、正しく認識できない可能性がありますか？
アンドレ・リベリオ：先ほどの例では、頭痛と発熱が別々の症状として検出されます。私たちが行うのは、これら両方を組み合わせて一つの病状を説明することです。実はここで指摘すべき点があり、それはユーザーが多すぎる症状を報告していないかということです。実際には持っていない症状や、自分が気づいていない症状を報告してしまい、適切な評価につながらないケースがあるかもしれません。なぜなら、私たちが評価を行うためにはこれらの症状が必要だと判断しているからです。実際には、私たちは複数の取り組みを行っています。これまでの観察では、ユーザーは通常、最初のクエリで1.5個程度の症状を入力することが多いことが分かっています。
一般的に、評価は常に可能ですが、稀に5〜10個もの症状を入力してしまうケースや、逆に頭痛だけを最初から最後まで報告してしまい、真の評価を提供できないケースもあります。そのような場合は、ユーザーをいくつかのフォールバック（代替手段）へ誘導します。具体的には、「頭痛についてのみお話しいただいた場合、これは信頼できる評価とは言えません。原因は様々考えられます」といった情報を提供し、説明を行います。ご指摘の通り、私たちはこれらを別々の症状として扱いますが、それらすべてを一つの病状として統合して説明するように努めています。
参加者3：もしユーザーがワークフローを完了できない場合、どうなるのでしょうか？例えば、ワークフローを進めている最中に腕にしびれを感じて、スマホを落としてしまったとします。
クレインドラー医師：その場合は意識を失います。
参加者3：その通りです。電話の向こう側に人間がいれば、何かおかしいと気づくでしょう。ユーザーが軌道から外れたことに気がつくはずです。どうやってバリデーターを信頼すればよいのでしょうか？また、そのバリデーターが実際には予後への適切なガイドラインとなっていることを、どのように確認できるのでしょうか？
アンドレ・リベロ：ユーザーが途中で止めてしまった場合、どうなるのでしょうか？現時点では、何も起こりません。私たちは健康保険提供者と連携しています。必ずしも手続きを進めるという決定は下されていません。進めることも可能ですが、タイマー機能を持っていますし、相談が中断された時刻も把握しています。また、ユーザーの身元も特定可能です。ただし、匿名データで運営している当社の「Healthily」ではなく、健康提供者側が把握しています。潜在的には、何かが発生したことを伝え、追跡させることも可能ですが、現時点ではそのような計画はありません。
どうやってバリデーターを信頼すればよいのでしょうか？あなたが仰るバリデーターとは、私たちの臨床医のことですか、それともモデルのことでしょうか？
参加者3：即座に回答を提供するモデルのことです。
アンドレ・リベリオ：それには2つの側面があります。1つはQ&A機能であり、これはチャットボットがモデルを使用して検証を行うものです。はい、私たちはこれらを継続的に改善しています。臨床データを用いてこれらのモデルをさらに向上させ、前述したように、第II類医療機器として認定されるレベルに到達することを期待しています。
症状チェッカーについては、さまざまなテストを実施しています。モンテカルロ法と呼ばれる一連のテストがあります。モンテカルロ法をご存知の方も多いかと思いますが、これは基本的に、対象とする疾患に基づいて症状のサンプルを生成する手法です。私たちはその組み合わせを100通り作成し、それらをチェッカーに通して、どのような結果が得られるかを確認します。その後、医療チームがその結果を検証します。
これに加えて、医師によって手動で定義された症例（ビネット）も用意されています。合計2,200の症例が作成されており、そのうち460は中核となるものです。これらすべてに合格する必要があります。これはつまり、特定の症状セットに対して、該当する疾患が存在していなければならないことを意味します。もし不合格となった場合、システム内で何らかの変更が行われたことを示し、修正が必要となります。あるいは、本来そうあるべきではないことが証明された場合は、症例自体を修正します。
テストにはいくつかの種類があります。実行される手動による症例テスト、モンテカルロ法に基づく自動テスト、さらにUI体験に関する手動テスト（ボタンが存在しているか、そしてそれらが意図する対象を正しくターゲットとしているかの確認など）もあります。私たちは包括的なテストのセットを持っています。
クリンドラー医師：患者のトリアージを行う者にとって、最も恐ろしいことのひとつは、ある症状を抱えた患者に対して「帰宅して大丈夫です」と言えるかどうかです。常に、「あの判断で本当に良かったのか？」という疑問が付きまといます。他の情報や血液検査の結果などを持っていても同様です。誰に対しても何らかのことで「問題ありません」と伝えることは、決して簡単なことではありません。
参加者 4：あなたのシステムを利用した場合と、実際に医師に診てもらう場合を比較したデータはありますか？何か数値やパフォーマンスに関する具体的な情報はありますか？
アンドレ・リベリオ：以前、インペリアル・カレッジ（Imperial College）から得たデータがあります。他社製品との比較における当社のパフォーマンスについてもご説明できます。他の競合他社と比較しても、当社が提供するツールは最も安全なものでした。誤解しないでください。私が言いたいのは、私たちを含めすべての競合他社は、過剰にトリアージを行っているという点です。また、ジャック氏の指摘された点にも通じます。私たちは常に最善の選択肢を提供することに注力しており、それが精度を若干下げる結果になっても構わないと考えています。これが私たちの最大の焦点です。「自己ケアで十分です」とお伝えするときは、確かに自己ケアであると確信していますし、その逆も同様です。例えば、緊急事態と判断されたケースが実際には一般開業医（GP）の診察で済むものだったとしても、私たちは正確性を確保するためにそう判断します。そのため、多くの警戒すべき兆候（red flags）を設けています。安全性においては当社が最も優れています。精度については、一部の競合他社よりもわずかに低い結果となりました。医師との比較も非常に興味深い点があります。医師 3 人を集めても、彼らが全員一致するとは限らないからです。
クレインドラー博士：4 つの意見を得ることができます。
アンデレ・リベリオ：まさにその通りです。この数値を取得するのは非常に難しいですが、現在その方向に向けて取り組んでいます。当社の医療チームは、健康保険パートナーの一つを通じて送付したデータのいくつかを検証しています。デジタル GP を確認するために誰がアクセスしクリックしたかという情報から、そこからどのような結果が得られたかまで、すべて把握しています。現在はこれらを検討中であり、正確性がどの程度であるか、またどのように改善できるかについて全体像を把握しようとしています。
通訳付きの他のプレゼンテーションを見る
録画日時：
2026 年 3 月 11 日
原文を表示
InfoQ Homepage
Presentations
From Symptom Checkers to Smart Chatbots: the Role of AI in Virtual Care
View Presentation
Speed:
48:28
Summary
Andre Ribeiro discusses the architecture of Healthily’s AI symptom checker. He explains how Bayesian inference and RAG models bridge the gap between medical insights and confident patient action.
Bio
Andre Riberio has over a decade of experience in data engineering, and currently serves as the Chief Technology Officer at Healthily, UK. He holds a PhD in Neuroimaging from Imperial College London and a master’s degree in Biomedical Engineering and Biophysics from the University of Lisbon. His focus is on applying advanced techniques to solve real-world problems across diverse domains.
About the conference
Software is changing the world. QCon London empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
INFOQ EVENTS
May 12th, 2026, 1:30 PM EDT
Designing Data Layers for Agentic AI: Patterns for State, Memory, and Coordination at Scale
Presented by: Karthik Ranganathan - Co-CEO & Co-Founder at YugabyteDB, and Aditi Gupta - Snr. GenAI/ML Specialist Solutions Architect | GTM Data and AI at AWS
May 21st, 2026, 12 PM EDT
Portable by Design: Data Mobility & Recovery Patterns for Multi-Cloud Systems
Presented by: Liore Shai - Solutions Architect at Eon
May 28th, 2026, 1 PM EDT
Shipping Faster, Breaking More: Rethinking Delivery Systems in the Age of AI
Presented by: Eric Minick - Sr. Director of DevOps Solutions at Harness, and Aaron Newcomb - Senior Product Marketing Manager at Harness
Transcript
Andre Riberio: I want to give you a walk through on Healthily stuff, from symptom checkers to smart chatbots. Let's start with a story. It was 2 a.m. A 7-year-old boy woke up with a headache and with fever. It doesn't feel like it's an A&E situation, but the parents are still worried. They go and search on Google. Then they start spiraling. They believe it's meningitis, which is one of the top results when you find it on Google. In 10 minutes, they head to A&E to try to get that checked. Just to soon realize it was a sinus infection that could have been self-treated at home.
They lost time, they stressed, and they lost confidence in their own judgment. This is just one family. Let's take just a second case. A 68-year-old man calls his daughter and stumbles over his own words. He's slightly confused, but suddenly he snaps back to normal. He tells his daughter that he's fine and probably it was just stress and nothing really to worry about. The daughter searches online, couldn't find any particular reason, and so they both waited until morning. What the father had was a transient ischemic attack or TIA or microstroke. This basically means it's a warning sign that a full stroke can happen in the next 48 hours, so immediate action needs to be taken to avoid a permanent situation or even death.
These are two sides of the same coin. On one hand, we have a self-care scenario that led to an A&E visit, which raises NHS costs, leads to stress and to a loss of confidence. On the other one, we had an emergency scenario that was missed by both the father and the daughter that could potentially lead to long-term effects. The question on both of these is always the same, what should I do? What should I do now in my specific case? This is not really a niche problem. It's not just these two cases. In just the UK alone, we have around 50 million health-related searches, and it's increasing across all age groups.
More and more people are searching online for health-related questions. What is the real issue here? Is it about finding the information, or is it about how to act? What we're really trying to solve is how to take people from outcomes, from what potentially they can have to act. Let me take you through the whole journey from a user perspective. The user started with symptoms. Either it's the user reported symptoms or observed symptoms in a different person. That could be a headache, could be fever, could be slurred speech.
Then they find out what potentially it could be. They may have some ideas, whether it's meningitis, whether it's a sinus infection, whether it's just stress. They still don't know what they should be doing. They know what potentially could be, there's multiple variations. There's a lot of information, but they don't exactly know how to act. That's where we are. What does this mean for me right now, for my particular scenario? That's what I want to know. That's what I want to be able to do. What they really want is the ability to act with confidence. Let's take just this last step from insights to actions. The user question was, what should I do? This is not just based on what they need, which is obviously very important, but it's equally based on what access to health they have available and what they're eligible for. For example, if you are in the UK or if you are in the U.S., that would become different things. We need to take all of this into account. This is one of the reasons why we are partnering now with health insurance companies to create this missing link between what they have and what they can potentially do.
BackgroundI'm Andre Riberio. I have over a decade of experience in AI and ML systems. I've been working in healthcare, but also other areas such as art analytics. I studied biomedical engineering and then pursued a PhD in clinical medicine research at Imperial College. I'm currently working as Chief Technology Officer at Healthily, and overviewing the systems which I'm going to show you.The Ideal Scenario
We talked about the problem. Let's talk a little bit more about the solution now. What is the ideal scenario for this particular case, for this daughter? The daughter, what she truly wants is a system which advises her accurately and reduces the human error. She wants something which takes from the stimulus to the action the least amount of time, so it improves the response time. She wants to minimize future risks, which in this case is a full-blown stroke. She wants reassurance that the action she's taking is the right action. How do we do it at Healthily?
At Healthily, we started by creating a smart symptom checker. This smart symptom checker is based on a ground-up tool that was developed by clinicians, by medical doctors. It's based on a medical database that we built in-house. It's clinically validated, and it's an AI tool. Now you ask, so AI tools, how can you make sure that AI tools are accurate? I will explain that in a bit, but basically it goes around what is called a Bayesian model, which is very rooted in math and in statistics. Finally, like I was explaining as well, we partnered with healthcare insurers to create that missing link.
System Architecture
Let me give you a little bit of an overview of the system architecture, so you get a pretty good idea of what is going on behind the scenes. As every other app, we start with a user interface, a web app, an API, or something else. In this case, the user starts with the natural language processing. They can start with, I feel sick, I have fever and stomach pain. That system gets past what we call our natural language processing and chat engine. This engine routes to three different other systems, the clinical reasoning engine, our semantic retrieval engine, and our flow-driven clinical logic. The first one is specifically the one that handles the base logic, the one that handles most of the cases of the assessment.
The second one is when the user is looking for information, which I will explain in a bit, and it works with BM25 and dense encoding. Basically, it just takes care of all of the semantic relationship between the user and our database. The final one is the cases which cannot be handled by any symptom checker. These are dangerous cases which the user may be falling into, such as suicidal thoughts. All of these get combined into a personal care guidance. Basically, we align with the healthcare insurance to provide them the service which they need, which is specifically for their need. Instead of telling you, go to see a doctor, I'm going to tell you go to your MSK pathway, go to see your 24-hour nurse, and so on. That's really what they care about. What they care about is what action should they be taking given the symptoms, given the issues they have right now.
The NLP and Chat Engine
Let's look in depth on the systems themselves. Let's look into the NLP and chat engine. This is built from three main microservices. There's a little bit more to it, but that's about it in a nutshell. The first model is an intent detection model. It's a model that detects whether a user wants information, wants an assessment, or is it not really clear about what they want. Then we have what we call a workaround classifier. That is a model that aligns with the topics, dangerous topics. It identifies whether the user is saying something as, I'm having suicidal feelings, and you cannot take a symptom checker normally, but you'll have to go on a very specific flow. It also does symptom entity extraction. Given the raw query that the user had, I have a headache and fever, it will detect headache and fever in this particular case as the potential symptoms which we will be moving to the other services.
Just finally, we take this system to detect whether an assessment is possible, and this will be used to inform what step we are going to take next. I'll go a little bit more deep on how they were trained, because the whole point which I'm trying to give you here is that this is a health product. This is a class I medical device at the moment. We are very much into the safety and control of each system. The reason why they are microservices and they work in independent ways is such that we can validate them properly. The intent detection model particularly was trained on manually labeled data from the year before. On the year before, we went over that dataset and we decided whether it was information or assessment or neither.
Then we further provided on the interface a dynamic button which allowed the user to also say whether they wanted information or assessment, and we use both of that information to fine-tune our own transformer model, which allows us to create this intent detection. The workaround classifier, on the other hand, was trained using a Siamese Neural Network. This network basically compares the embedding from the user query and seed queries, which are about the topics, which can be a mental health situation such as suicidal, it can be a burn, or it can be different scenarios. Given those two, then we can create the cosine similarity between them, which basically just means the similarity between these embeddings, and therefore we can assign a threshold.
Our clinical team balanced the precision and accuracy of each one of these topics and defined what the threshold should be. What I want also to make clear is it's not just about building the models, it's about the governance of such models, the regulation. We have a whole process from making sure we validate them, review them, and so on, from the beginning to the end, and the models need to be constantly revised to make sure they are accurate.
Then the final one of these UQML models is the symptom entity extraction. In fact, this is what we call the Mediterm model, which is slightly different, but it's still within the same realm. This model is based on the Stanford CoreNLP, and it's enhanced by our own dataset. We increase this with our medical concepts and synonyms, which are proprietary. There are two main points to this system. The first one is a label-based concept activation. What you start with, which would be in this case head pain, will activate two different concepts, which is head, which is a concept, and pain, which is a different concept.
Both of these get combined into a single concept, which is headache in that particular scenario. The system is able not just to pick a single word or multi-words, but to combine them into a higher and higher level of symptoms. The second point is hierarchical symptom propagation. We started from a pain in the bottom of the foot, which was identified as a concept, but we can also activate its parent, which is pain in foot. Why do we do this? Because logically, if you have pain in the bottom of the foot, you therefore have pain in the foot, and that increases the reliability and coverage of our symptom checker, which we will be explaining.
The Clinical Reasoning Engine
We explained the NLP part. I'm not going to explain all of this, I'm just going to explain the top two. The NLP is the engine that routes into these three systems, and the engine which provides the symptoms which the model, the clinical reasoning engine will use. What is this engine? This engine again, like I explained, takes Bayesian inference, takes safety rules, and takes red flags, combines all of these and then eventually provides you what are the next set of questions that we should ask the user. Taking that structured symptom input, which was provided by our NLP model, then we give all of that to our Bayesian inference, safety rules, and red flags. What we truly start with is the red flags. Let's take this case, the user reported chest pain. That's a red flag symptom, because this is associated with many conditions that are red flags, and they are dangerous. Given that, then the system directly asks recent injury, and the reason for that is because there are multiple conditions which are associated with chest pain and recent injury.
If we can rule out recent injury, therefore we can rule out that particularly dangerous condition. That's the first thing we do. We try to focus very much on safe triage. Then it becomes the big model, which is the Bayesian inference part. These are two simplified formulas, but they basically give you everything you need to know. The way it works is we try to maximize the information we can get over the next round of questions. The user told us that they have chest pain. They told us they have confusion. Now we need to ask them what is the best set of symptoms we should ask them that will reduce the uncertainty of the system. We do that through Bayesian inference to calculate the probability of a condition given a set of symptoms, and we do also the distribution of those probabilities. We calculate the entropy and we minimize that entropy, and therefore we take out what is the top set of symptoms to ask given entropy minimization.
Given that, then we can ask multiple rounds of questions. We keep improving the prior of the system. We keep improving the knowledge that the system has and how confident it will be about what is the probable condition. We can then therefore rank the list of possible conditions at any point and also associated triage level. Given that we can do that, then we can obviously compute the posterior of each condition. That's the same formula as before. The only thing we are saying here is that we have a threshold identified there. Over a cross of multiple questions, then we become more and more certain that it can be a potential condition. The medical team also defined what this threshold should be, which was 90% over across at least 12 rounds, and that decides that the system is confident enough to finish and provide the outcome. The conditions that we will later be showing will be dependent on how relevant they are to the user, not just based on this particular threshold.
We explain everything from the symptoms to the outcomes, what they may have. This is not really what I want, since I started in the beginning of this conference. It's more about the recommended triage, the actionable next steps. What should I do? That's where the partnership with health insurance is really important. That provides us that exact link, what they can do. This is just a simple example where the user started with back pain. It was an MSK scenario that led us to recommend physiotherapy pathway, which the insurer directly have a way to do a direct referral. It bypasses directly speaking with the doctor and goes directly where they need to be. Or anxiety, which led to mental health. Maybe there can be self-care, or maybe the system will decide whether a therapist may be needed. Again, the insurer may cover a counseling app. Chest pain, urgent. We detected that that may be an A&E scenario, so call directly 999. Or if the insurer has an option, then inform the insurer as well. Or the very common case of a routine GP, which is a typical scenario that you will see in every symptom checker. We can also tell you go do a video GP or an in-person, depending on that, which again, you can just book directly with the insurer.
Demo - Healthily's Smart Symptom Checker
This is just a very quick example, which we are trialing with a health provider. The user is being shown a lot of navigation tools regarding insurance related information. They decided to go into the symptom checker. They are adding their age and gender. They are going through and saying they don't have any rare medical condition, which does not allow them to use the symptom checker safely. They say they have slurred speech, which is what they started with. The system decides and asks them if they do have slurred speech. This is important. Basically, the point I'm trying to make there is that we always want to be sure. The ratification point is a very important point for us because it makes sure that what we're detecting is actually correct. They decide to continue with the assessment. They said they had this for a few hours only. They have high blood pressure. They are not overweight. They are not a smoker. They have some slight confusion, and it was a new confusion. They did not have an injury, but they have some difficulty in language or speaking.
Then the system keeps asking for a different set of questions, which again, like I explained, is related with triage, is related with red flags, and is related with the possible conditions that you have. It's going to do this for a few rounds, which hopefully is not too much. You get a pretty good feeling of what is going on. Also, remember that for the probabilistic model we are doing, it's not just about what you said yes to, but what you said no to is equally important because it will exclude conditions or make them less probable. When the system is confident enough, which takes a few set of questions, then it will provide you a report.
In this case, it recommended 999 because it's an ambulance scenario, and we'll understand exactly why. Those were ruled out situations. These are the most likely, which we have TIA directly there, and also ischemic disorder, which is stroke. We also allow the user to select other options. We do recommend them these, but we tell them if you do want to see your doctor, you can obviously do so, or call 111. We also give them information about what they type, so they can confirm that what they have is correct. We explain all of this. We explain from symptoms to conditions to actionable results.
The Evolution to Conversational Chatbots
What am I going to show you next? There is still a missing thing, which we didn't cover, which is, sometimes the user starts with just a question. They don't really have yet the symptom, or they may, but they may not really know where they want to go. They start with a simple health question. How can we address this? How can we make sure that we can also target these people? That's where we started looking into conversational chatbots, or moving from symptom checkers to fully conversational chatbots. What do we do? I'm not going to go over in too much detail here. This is a completely new product we are building, but I will give you exactly how it works. It's based on a RAG, Retrieval-Augmented Generation model. I'm just going to explain how this is applicable in the healthcare sector.
First of all, we start with a question aware transformer. This is simply saying that if the user started asking about what is COVID, and then asked about what are the symptoms, we can generate a question which is, what are the symptoms of COVID? It combines the previous context into a question aware transformer question. Why is this relevant? Because then we use that question to search on our health database, which is one of the largest in the UK. We use a retriever model to chunk our data, to encode that data, and then we search that against the user query. To make this even better, then we use what is called the reader model. It goes over these chunks and extracts the snippets which best matches the query, and re-rank them as well. All of these models, these two and the previous model, are fine-tuned using our own proprietary data. We did this to make sure that this is as good as possible for our scenarios. They are also done in specific microservices, again, such that we can control each one of them. We can know where each one of them fails.
Then, finally, as everyone does, we go into the LLM world of answer generation. Here we do use a commercially available model. We are moving towards our own fine-tuned model as well, the same way that we have been doing for before. Things are evolving really fast. Language models are getting really good, and we want to be able to provide the best possible solutions as well. We are currently using what is out there as the best possible models. We're not just doing that. We're not, just take an LLM and go with it. In fact, we are working towards building a lot of guardrails to make sure that the systems we have are safe.
Given our RAG model, we're looking into restrictive knowledge, so making sure that the model only answers to the questions which are health-related and based on our data. Factual checking, making sure that the answer the LLM provides is truly based on the content that it was given. Uncertainty estimation, is it truly hallucinating or is the answer correct? Is it safe? This is probably the biggest one, how safe it is. If the user asks, can I take an antihistamine for my allergy? You could just say yes, totally fine. It is incorrect because if you are pregnant, you cannot take certain anti-allergy medications. That would be directly an unsafe answer by not having context. That's what we are working on right now. This is obviously a lot of work, but we're building towards a safe chatbot.
Demo - Healthily's Chatbot
I'm going to show you one which is very quick. This is not a product as of now. We are trialing this out at the moment, but most of this is going to change. I'm just going to show you exactly how this links with what we were saying before. In this case, the user just asked a question about headache and fever. The system does provide information about it and also provides, in this case, about just that particular URL, which is our own content.
Then they went over and like, ok, in fact, this feels like it's what my daughter has, which was our son's example, not daughter. They believe it's meningitis. From this point onwards, then the model already picked up the UQML models or our intent detection model and drives them directly to a symptom checker. What you saw there by the end is exactly as safe as the symptom checker we had before. The questions it's going to ask is still based on the Bayesian network. It's still based on the safety. It's just shown in a completely different scenario, which is a conversational chatbot.
Future Work - Symptom Checker and Chatbot
Where do we want to take from here? There's a lot to do. For example, on the symptom checker, we are pursuing class II medical device right now. This is to ensure reliability and clinical trust on our systems. We are already a medical device class I. On the chatbot side, we're ensuring alignment with regulated guidance and building all of these guardrails, which will allow us to say that something is safe to a certain level. We keep doing model improvements, both on the symptom checker as well on the chatbot. Regarding our architecture, we're improving the data. We're improving how the symptom checker uses that data. We have various different projects to do that. While on the chatbot, we're trying to make the model retrievals to be better, to be more aware of what it has said before, trying to incorporate also the outcome, the report that you can get from the symptom checker directly into the chatbot, being able for a user to ask questions about that.
Finally, transparency. We have a transparent document online, which you can look into which should tell you everything that we do, and we are always on that. We attempt to do that every single time. We're trying to improve the rationale of the symptom checker, so why are we asking you that particular symptom. We are, on the chatbot side, trying to improve the hallucination, improve the safety, improve the source attribution.
SummaryOn Healthily, we're trying to make a system which is end-to-end. It starts from the user question, from their symptoms, all the way into the actions, what they can truly do with that information. We're trying to be conversational as much as possible, as natural as we can potentially be. That's where the chatbot came in. We try to make it as safe and as reliable as you can potentially be, which is the intelligence reasoning using the probabilistic model and safety-aware triage. We are integrating with healthcare providers, insurances, to be able that our systems do give them services which are applicable and real to them. We're trying to be as clinically aligned as we can potentially be by creating guardrails, by improving validation and auditability on our systems. At the end of the day, we're building this for people. We are trying to honestly help users have more confidence and act when they should act.Questions and Answers
Dr. Kreindler: This is one of the key areas where the large language models are playing an important role. At what point do you feel there will be an insurable class II product that you can genuinely have a proper chat with rather than go through clickable links?
Andre Riberio: We're literally looking into that. We're obviously starting with a class II medical device on our symptom checker. That's the first part of it. We're building step by step on that. The conversational UI, which I was showing at the end, provides the user a way to start getting used to that conversational format. It's easier to go to regulation and say, this can still be a class II medical device because it's still the same questions in the exact same way, just in a different format.
Then it's proving that you can go from that point into proper natural language. I could already tell you we could. We could, for example, use natural language. We could use our NLP model to keep asking them, is this what you said? Is this what you said? Probably not a great user experience, but it would work because if they keep saying yes or no to what we identify, it would be equally safe because they are ratifying our questions. What we want to go is a point where we can be certain to X amount, where that X amount, I don't know what that number is, which we are ok and safe. That will be the point. We are working through a class II medical device on the symptom checker. We're building these chatbots now with insurances as well to validate whether people want them, whether they engage with them. Then going from there, yes, we're pushing and pushing the boundaries and trying to get into class II.
Dr. Kreindler: Have you done any research yet on the usability difference between having a chat versus clicking buttons?
Andre Riberio: We've done recently a study, it has been exactly showing the chatbot and trying to understand what is the usability, whether people would like that. For example, the integration at the end of the assessment, whether they would prefer that versus the more classical approach, which is the other one, the form-based approach. People do seem to prefer the chat nature because it's incorporated into the questions and it just feels a more normal way to interact with the system.
Dr. Kreindler: Not official party line, but in terms of your intuition, how much do you think the multimodal assessment of us as clinicians, in terms of intonation of voice, visual appearance of things, just that kind of, you might be short of breath, but you've got a bit of a wheeze in your voice and you otherwise look nice and bright and shiny and got red cheeks. It's probably not the worst kind of shortness of breath. How much do you think multimodal is destined to become part of systems like yours?
Andre Riberio: Yes, for sure. It has to move that way at some point, because at this point, yes, if the user tells you, for example, a skin concern, you can ask questions about it. You can ask, is it red? Is it uniform? You can try to address it, but you are still very much focused on what the user knows and how he can reply. The problem with that is that the systems are not accurate yet to take a picture and say with confidence what this should be. That's why that realm is still hard, but it will eventually go there for sure. Again, we can start thinking about situations where you could try to understand directly from the picture and then again get it ratified by the user, trying to understand whether what you're seeing is what seems to be matching. There is still a gap between where we are to those scenarios, but for sure that will be a case.
Dr. Kreindler: I suppose at very least you can collect that and present a referral note with more data than just text-based things. You could even do that today.
Andre Riberio: Yes.
Participant 1: You mentioned about the ratification. I was just wondering if you had any further data quality challenges and what you've done about them.
Andre Riberio: The ratification?
Participant 1: Yes, you mentioned that one. Do you have any others?
Andre Riberio: Yes. We have a few control systems. The ratification is one of them, so the one we were talking about. That's exactly from the point where there is a text question from the user and we convert it to symptoms. We always ask. We thought about at some point to say, if you're confident 90% of the time it's fine, we decided not to. We decided it's always better in this particular scenario, at least now, to always ask, is this what we identified correct? We're also training the system. It keeps adding to the data. I don't have the statistics right now on what the numbers look like. I think I had the slide at the end on the future, which we are in fact trying to compare that with current LLMs and see how good truly they are. We do have the dataset right now. We just have to work through it. We do have another control point, which is called clarification instead of ratification. That's when the user gives you a symptom that can mean multiple things.
If the user asks for a particular symptom that can mean multiple things, we ask them which one of those things do they point to such that a simple ratification wouldn't work because they would say yes to, and it would mean a different thing. We give them a different set of options which they select and they can pursue. That's that, those control points. That makes sure that all text that we are doing is correct up to the user knowledge, obviously. All of the questions that we ask after, they are not generated in any way on the symptom checker, they are very specific from our dataset. Those are fully controlled. At the end, we further give the user the report on exactly what they said, so they can always validate that something was missed, which it shouldn't. Just saying that if something was missed, then the user is aware of that, or the doctor, because we can provide those reports to the doctor as well, would be aware. Those are the control points.
Participant 2: How does it deal with multiple symptoms? Like I've got a pain in the foot and a sore head.
Andre Riberio: Yes. No, it can definitely detect multiple symptoms. It can detect as many symptoms as there are there. It works with single word and multiple word. Sometimes it does mix them up if they are too close together and they would refer to different concepts. It's not that common. What we usually have behind the scenes is a dataset which we manually created with the primary concept and its associated synonyms. For example, for headache, we have things such as cranial pain, head pain. Each one of these are also their own concepts. Cranial is a synonym of head, which is a synonym of something. Any combination the user selects will still lead to headache. We also use that on our retrieval as well. Any combination will still work. No, it does work for multiple symptoms within the same query and multiple words per symptom as well.
Participant 2: Would it view them as two separate things?
Andre Riberio: Yes.
Participant 2: If they're part of the same problem, then it may not get it correct then?
Andre Riberio: The example I had there as I have a headache and fever, they are detected as two different symptoms. What we do is we take them both as to explain a condition. In fact, there is a point there to be made, which is, is the user reporting too many symptoms? Symptoms they may not truly have or maybe they don't really know about and not leading to an assessment? Because we do take them as necessary for an assessment to be possible. There are multiple things we are working there, in fact. What we have been seeing is that users usually type around 1.5 symptoms per query, initial query.
Typically, the assessments are always possible. There are a few scenarios where they may type 5 to 10 symptoms, which is not. Or they may type so few, which they start with a headache from the beginning to the end of the assessment, which we cannot provide truly an assessment. There we redirect the user to a few fallbacks, such as providing them information and saying, this is not reliable in the sense that you just told us about headaches. It can be many different things. Yes, to your point, we do take them as different symptoms, but we do try to explain all of them together into a single condition.
Participant 3: What would happen if the user can't complete the workflow? I'm going through a workflow and I lose feelings in my arm and I drop the phone.
Dr. Kreindler: You fall unconscious.
Participant 3: Exactly. If I have a human at the other end of the phone, they could realize, something's not quite right, the user has fallen off the track. How do you trust your validators? How do you know that your validators are actually a good guiderail to the prognosis, basically?
Andre Riberio: What happens if the user stops in between? At the moment, nothing, truly. We are aligned with health insurance providers. The decision was not to necessarily proceed. We could do, because we do have timers. We do know when they stop the consultation. We do know who they are, not we Healthily, because we do work with anonymous data, but the health provider does. We could potentially give them and tell them that something happened and for them to pursue. At the moment, no, it's not on the plans to do.
How do I trust the validators? The validators, you mean our clinicians, you mean our models?
Participant 3: Your models that are the immediate response.
Andre Riberio: There's two pieces to that. There's the Q&A piece, which is the chatbot, which uses models to validate. Those, yes, we keep improving them. We are using clinical data to better improve those models and hopefully reach a point where, like we said, it can be a class II medical device. On the symptom checker, we have many different tests. We have a set of tests which are Monte Carlo tests. If you know Monte Carlo, basically it means that we generate samples of symptoms, which are based on the condition we're trying to target. We do a hundred different combinations of those, and we run them through the checker and we make sure to see what the outcome would be. Then the medical team will validate that.
Besides that, we also have manually defined vignettes by doctors. They created 2,200 vignettes, which 460 is core, and those all need to pass. It basically means that for that set of symptoms, you have to have that condition. If it doesn't work, it means that we changed something in the system and we have to fix it. Or, we prove that it shouldn't be that, and then they fix the vignette. There are a few sets of tests. There's manual vignette tests, which run. There's automated tests, which are the Monte Carlo ones. There's even manual tests on UI experience, on making sure that the buttons exist and they target the things they should be targeting. We have a whole fedora of tests.
Dr. Kreindler: One of the scariest things as someone who's triaging someone, the scariest thing when someone's got some symptom, is to be able to say, it's ok to go home. There is always a degree of, was that the right thing to do? Always, even when you've got other information about them, blood tests and other things. It's non-trivial to give anyone the all clear on anything.
Participant 4: Do you have an idea of how it compares using your system compared to going to an actual doctor? Would you have any numbers or performance maybe?
Andre Riberio: We do have data from Imperial College some time ago. I can tell you how it performed against other competitors as well. It was the safest tool out there compared with any competitor. Don't get me wrong. What I mean with this is that all of us, all competitors, including us, we are over-triaging, and also goes to the point of Jack. We want to make sure that we always give the safest option, even if that reduces our accuracy. That's our primary focus. If I'm telling you that it's self-care, I'm pretty sure that it should be self-care, and the other way around, even if something which was emergency was in fact just a GP consultation, because we want to make sure that we are correct. We have a lot of red flags to try to make that. We are the safest. Accuracy-wise, we did go slightly lower than some of our competitors. Compared with doctors, it's also really interesting because if you put three doctors together, they will not agree.
Dr. Kreindler: You'll get four opinions.
Andre Riberio: Exactly. It's very hard also to get that number, although we are working towards that now. Our medical team is validating some of the data we sent through one of our health insurance partners. We do have everything from who went and clicked to see their digital GP. We also know exactly what came out of that. We're trying to look into that now and try to get the full picture on how accurate it is and how better you can get.
See more presentations with transcripts
Recorded at:
Mar 11, 2026
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み