24
Hubble
患者の医療記録を代行取得する連携基盤
競合あり/空白あり国内に複数の電子カルテから患者記録を取得しAPIで提供する同型事業者は確認できない。
事業概要
- プロダクト
- 顧客企業は患者の同意情報と氏名・生年月日をAPIに送信する。
- 対象の医療機関や保険者を特定し、記録取得の手続きを開始する。
- AIエージェントが電子カルテの画面を人が操作する形で巡回し記録を取得する。
- 取得した記録を項目ごとに名寄せし、共通の形式に変換する。
- 整形済みの記録を単一のAPI応答として開発者に返す。
- 取得状況と欠損項目を一覧で返し、再取得の指示を受け付ける。
- 技術アーキテクチャ(推定)
- 取得元は数千規模の電子カルテと保険者のシステムとみられる。
- 公開APIが乏しいため、画面操作を再現する端末エージェントで取得すると推定。
- 顧客から渡る患者識別情報を基に、対象施設と記録種別を照合する。
- 取得した文書は項目抽出と名寄せを行い、共通スキーマに正規化するとみられる。
- 処理済みデータはAPI経由で返し、原本は監査用に保管すると推定される。
- 利用量と取得成功率を計測し、課金と品質管理に用いるとみられる。
- 収益モデル
- 記録取得を必要とする企業が利用量に応じて支払う従量制。
- 課金単位は取得件数またはAPI呼び出し回数とみられるが、単価は非公開。
- 導入支援や接続構築の対価を別途設けるかは未確認。
- 差別化
- 取得先ごとの手続きと画面操作の知見を蓄積している点。
- 記録形式の差異を吸収する正規化の実装資産。
- 創業者が大規模患者基盤のAI運用を担った実務経験。
- 医療記録取得の法的手続きを組み込んだ運用設計。
- 日本展開時のリスク
- 要配慮個人情報の取得には本人同意と目的明示が欠かせない。
- 医療機関ごとに異なるシステム仕様が取得の網羅性を制約する。
- 3省2ガイドラインに沿った安全管理措置の説明が求められる。
- 国内の電子カルテはベンダー閉鎖性が強く外部連携が難しい。
- 導入先が限られ、単価と利用量の積み上げが読みにくい。
日本での競合
- 国内の医療情報連携は施設間ネットワークの整備が中心だ。
- エムスリーやメドレーは医療者向けサービスで顧客基盤を持つ。
- 電子カルテのベンダー系列が強く、外部連携は限定的だ。
- 患者記録をAPIで外販する同型事業者は確認できない。
- カケハシなど薬局・診療所向け基盤はあるが用途が異なる。
- 参入には同意取得と安全管理の説明が事実上の前提になる。
主要プレイヤー
| 比較軸 | Hubble | メドレー | エムスリー | カケハシ |
|---|---|---|---|---|
| 主な用途 | 患者記録の取得とAPI提供 | 医療支援 | 医療情報 | 薬局支援 |
| 提供範囲 | 取得から整形まで一括 | 医療機関 | 医療従事者 | 調剤薬局 |
| 課金 | 利用量に応じた従量制 | 月額課金 | 広告課金 | 月額課金 |
| 強み | 取得先の運用知見と正規化 | 医療特化 | 会員網 | 薬局特化 |
出典:Y Combinator / Hubble / メドレー / エムスリー / カケハシ。技術アーキテクチャは公開情報からの推定。