サマリー
- Code Technology は、フォームのデジタル化ベンダーとしてではなく、管理された臨床データ運用として評価されるべきである。持続的な価値は、患者報告アウトカムの証拠が、繰り返される術前、術後、報告サイクルを通じて完全で追跡可能かつ使用可能な状態に保たれるかどうかである。
- 公開情報は、アウトリーチ、適格性、EHR またはスケジューリング抽出、ダッシュボード、レジストリ報告、顧客サポートを中心に構築されたソフトウェア＋サービスモデルを支持しており、すべてのベンダーの主張を測定された顧客成果として扱うことを支持していない。
- 主なリスクは、調査リンクが一度失敗することではない。より大きなリスクは、同意、身元照合、重複アウトリーチ、未完了のアンケート、評価ロジック、エクスポートの準備状況、サポートの所有権における静かな破綻である。なぜなら、これらの失敗は、償還、認定、または臨床改善作業が記録の一貫性を必要とするときに初めて明らかになるからである。
フォームはシステムの最小部分にすぎない
Code Technology を誤解する最も簡単な方法は、デジタル質問票を見て問題が解決したと考えることだ。それはソフトウェア購入者の最も古い罠である。患者報告アウトカムプログラムは、ブラウザが質問を表示できないから失敗するのではない。誤った患者が登録されたり、手術が再スケジュールされたり、術前のウィンドウが閉じたり、患者がクリニックを去ったずっと後に術後の間隔が到来したり、電話番号が変わったり、別の部門から重複したリクエストが送られたり、エクスポートに必要なフィールドが欠けていたり、病院幹部がデータがプロジェクトを正当化した報告や改善の問いに応えられないことに気づくのが遅すぎたりするから失敗するのだ。
Code Technology の公開サービス面は、そのより厳しい運用実態を指し示している。同社は、サービス、ソフトウェア、レジストリ、専門知識を組み合わせた患者報告アウトカム指標プロバイダーとして自らを位置づけている。その売りは、単に調査をホストできるということではない。患者の特定とアウトリーチから、検証、報告、ベンチマーキング、CMS 対応準備までプログラムを管理すると述べている。その違いは重要だ。なぜなら、臨床アウトカム製品は通常のデータ入力ツールではないからだ。それは、患者、外科医、レジストリ、病院の品質チーム、財務リーダー、EHR 管理者、そして時間とともに変化するポリシールールの間に位置している。その作業は反復的だが、反復は単純ではない。
そのような環境では、自動化は運用上の約束として理解されなければならない。Code Technology は、説明するのは容易だが維持するのが難しい一連のタスクを引き受けている。適格な患者を特定し、適切な間隔で適切な指標を彼らの前に提示し、複数のチャネルを通じて参加を可能にし、連絡すべきでない人々に迷惑をかけることなく完了を追跡し、回答を手術記録と照合し、結果を臨床医や品質チームに見える形で保ち、報告やレジストリワークフローのために使用可能なエクスポートを準備する。ベンダーは、これにより作業が削減されると主張できる。実際的な問題は、最初の実装会議、最初の再スケジュールされた手術、CMS ガイダンスの最初の変更、そして臨床、IT、財務の境界を越える最初の顧客サポートの問題の後でも、その削減が真実であり続けるかどうかである。
だからこそ、受け入れられた臨床ソフトウェア記録こそが適切なテストなのである。フォームのデジタル化は最低条件だ。真剣な購入者が購入しているのはフォームではない。購入しているのは、周囲の人々やシステムが変わっても有用であり続けなければならない、機密性の高い臨床記録を取り巻く継続性、監査可能性、サポートの規律である。
Code Technology が販売しているように見えるもの
公開情報は、CODE Technology（別名 Clinical Outcomes Data and Engineering）を、患者報告アウトカムに焦点を当てた米国本社のプロバイダーとして説明している。同社のウェブサイトによれば、統合デリバリーネットワーク、学術医療センター、病院、個人診療所と協力している。Breanna Cunningham を創業者兼最高経営責任者として挙げ、サービス重視のモデルを中心としたリーダーシップチームについて説明している。また、本社はミネアポリスにあり、全国にスタッフを配置しているとも述べている。これらの識別情報は重要である。なぜなら、無関係なセクターや法域に同様の名前を持つ他の組織が存在するからである。ここで関連する Code Technology は、codetechnology.com の患者報告アウトカムプロバイダーであり、通信会社、一般的な病院管理ソフトウェア企業、または他の同様の名称の開発会社ではない。
サービスの約束には三つの部分がある。第一に、Code Technology はソフトウェアレイヤーを提示する：ダッシュボード、レポート、患者インターフェース、調査間隔、アウトリーチワークフロー、エクスポート、統合オプション。第二に、サービスレイヤー：臨床訓練を受けたアカウントマネージャー、患者コミュニケーション、プログラムメンテナンス、リマインダー、データチェック、報告に関する実践的なサポート。第三に、レジストリレイヤー：蓄積された整形外科アウトカムデータ、ベンチマーキング、外部報告や認定関連プログラムへの参加。この組み合わせが同社のポジショニングの中心である。Code Technology は、ソフトウェアのみのアプローチでは、完了率の低さ、スタッフの負担、不完全なレポートを顧客に残す可能性がある一方で、管理されたアプローチでは、繰り返し発生する作業の多くをクリニックの外に移すことができると主張する。
利用可能な製品ページと顧客リソースは、ワークフローのかなり具体的な見解を示している。患者には、電子メール、テキスト、電話で連絡できる。同社は、自宅、スマートフォン、タブレット、電話支援、QR コードの応答経路を説明している。調査疲労のモニタリング、リマインダー、設定可能なテンプレート、ログイン不要の患者インターフェースについても説明している。登録側では、Code Technology は、プログラムを開始する前に完全な統合を強制するのではなく、患者の身元情報、連絡先詳細、担当外科医、手術日または説明を含む構造化された抽出から始めることができると述べている。時間の経過とともに、統合には手術スケジューリング、患者管理、または登録システムからのメッセージが含まれる可能性があり、予約や患者詳細が変更されたときに EHR またはスケジューリングシステムが更新を送信する。
それは、基盤となるモデルについての有用な手がかりである。同社は、AI 診断製品やブラックボックスの臨床判断エンジンを提供しているのではない。運用の正確さに価値が依存するワークフローおよびデータ整合性製品を提供しているのだ。技術的な依存関係には、質問票ライブラリ、間隔ルール、患者身元照合、連絡チャネルオーケストレーション、同意とプライバシー処理、安全なデータキャプチャ、EHR またはスケジューリングフィード、ダッシュボード、エクスポート、レジストリ提出パス、報告サポート、監査証跡が含まれる。これらの要素のどれも華やかではない。しかし、そのすべてが記録を破綻させうる。
購買者の疑問は「調査を送信できるか」ではない
医療リーダーたちは、自動化と称しながら仕事を動かすだけのソフトウェアに警戒心を抱くようになっている。患者報告アウトカムシステムは、それを容易に行える。もし病院が、すべての適格な患者を手動で定義し、すべての未回答を追跡し、変更されたすべての手術を照合し、すべての抽出を検証し、すべての新しいベンダー担当者を訓練し、すべての報告パッケージを手動で準備しなければならないなら、そのソフトウェアは実際にはダッシュボードが付いたワークフロー税にすぎない。
Code Technology の商業的主張は、管理モデルがその税を引き下げるというものだ。同社は自社のサービスを、ソフトウェアのみのベンダーやクリニック内での作業、EHR ネイティブのアプローチと繰り返し対比させている。その公開ページでは、スタッフは患者に一人ずつ電話をかけたり、臨床変数を手動で入力したり、別の部門によって調査が重複していないか確認したり、提出時にレポートが使えるかどうか心配したりする時間を費やすべきではないと述べている。アカウントマネージャーとアウトリーチチームを、オプションのサポートアドオンではなく、製品の一部として位置づけている。
その主張はもっともである。なぜなら、PROMs の作業は、異常なほどにフォロースルーに依存しているからだ。患者は、手術が近く、クリニックとの関係がアクティブであるために、術前評価を完了するかもしれない。しかし、1年後の術後間隔は異なる。患者は回復していたり、引っ越していたり、電話番号を変えていたり、メールを無視していたり、興味を失っていたり、病院の調査が優先事項ではない通常の生活に戻っているかもしれない。リンクを送信できるシステムは、記録を代表的かつ報告可能にするのに十分な長期的な接触を維持できる運用モデルと同じではない。
商業的な疑問は、Code Technology が、実装、サポート、切り替え、ガバナンスのコストを正当化するのに十分なだけ顧客の作業とリスクを削減するかどうかである。それはパンフレットの数字だけでは答えられない。専門分野、量、患者の人口統計、既存の EHR 構成、報告義務、スタッフの能力、データガバナンス要件、そして顧客が実際に結果を活用するかどうかに依存する。ベンチマーキングを求めている小さな整形外科診療所は、CMS のパフォーマンス尺度の下で償還を守ろうとしている医療システムとは、サービスの異なる部分を評価するかもしれない。すでに強力なレジストリ運用を持つ病院は、正確なエクスポートの信頼性を求めるかもしれない。管理能力が限られているクリニックは、ダッシュボードよりもアウトソーシングされたアウトリーチ機能を求めるかもしれない。
ここでベンダーの主張と顧客の成果を分けるべきである。Code Technology は、Holy Cross Orthopedic Institute、McLeod Health、ORA Orthopedics、そして以前の PROM ソフトウェアの失敗を受けて移行したと伝えられる匿名の中西部医療システムを含むケーススタディと顧客事例を公開している。これらの例は、製品が実際の臨床運用で使用されてきたという考えを支持する。それ自体では、すべての展開で一様なパフォーマンスを証明するものではない。それらが示しているのは、顧客が明確な尺度、明確なサービスライン、反復可能なアウトカム管理の問題を持っている場合に、価値提案が最も具体的になるということである。
CMS ルールにより、フォローアップの失敗は財務リスクに変わる
患者報告アウトカムは、かつては主に臨床改善ツールとして議論されていた。今では、コンプライアンスと償還の問題にもなっている。THA/TKA 患者報告アウトカムパフォーマンス尺度に関する CMS と QualityNet の資料は、その理由を示している。この尺度の枠組みでは、病院は人工股関節全置換術と人工膝関節全置換術の前後で患者報告アウトカムデータを収集し、関連するリスク変数と管理請求データを尺度プロセスで使用することが求められる。そのロジックは政策面では単純であり、運用面では難しい。ケアの質には、病院が従来の合併症を回避したかどうかだけでなく、患者が痛み、機能、生活の質において意味のある改善を報告するかどうかが含まれるべきである。
ソフトウェアベンダーにとって、これは一般的な満足度収集よりも厳しいテストを生み出す。システムは、誰が適格か、術前記録の期限はいつか、術後のフォローアップ期限はいつか、どのようなサポート変数が必要か、どの調査票が許容されるか、除外はどのように処理されるか、記録がどのように手術に結び付けられるか、そして最終パッケージがどのように準備されるかを知っていなければならない。また、何が起こったかの履歴を保存しなければならない：評価が提供された時期、どのチャネルが使用されたか、患者が拒否したかどうか、症例が再スケジュールされたかどうか、手術が確認されたかどうか、不足している結果が本当に不足しているのか、それとも該当しないのか。
リスクは抽象的ではない。Code Technology 自身の CMS に焦点を当てたページは、キャプチャの閾値、報告期限、不完全な術前・術後データの結果を強調している。中西部の医療システムに関する公開ケーススタディでは、報告期間にゼロの結果を返した以前のソフトウェアツールについて説明し、顧客が適格性ロジック、データの完全性、報告の準備状況を信頼できなくなったとしている。たとえそのケースが Code Technology のマーケティングレンズを通して提示されているとしても、それは正しい故障モードを特定している。危機は、調査フォームの見た目が悪かったことではない。危機は、顧客が必要としたときに、運用記録が報告の質問に答えられなかったことである。
病院にとって、それが製品と負債の違いである。洗練されたインターフェースは、測定期間の終了まで弱いプロセス規律を隠すことができる。その時点で、スタッフは、術前のウィンドウが逃されたこと、術後のアウトリーチが一貫していなかったこと、必須フィールドが欠けていたこと、重複記録がカウントを歪めていたこと、またはエクスポートが EHR と照合できないことを知るかもしれない。管理されたサービスは、これらの問題を修正するのに十分早く検出した場合にのみ価値がある。
統合の問題は意図的に段階化されている
Code Technology の公開サポート資料の中で、より示唆に富むものの一つが統合ガイダンスである。統合をオール・オア・ナッシングの要件として提示するのではなく、同社は、顧客は診療管理、EHR、または手術スケジューリングシステムからの単純な構造化レポートから始めることができると述べている。そのレポートには、身元、連絡先詳細、外科医、手術情報という限られた一連の登録要素が必要である。収集が開始されると、Code Technology は、より深い統合パスを選択する前に、顧客の手術量、スケジューリングパターン、キャンセル行動、ワークフローを学習できると述べている。
それは実用的なアーキテクチャである。完全な EHR 統合は、遅く、高価で、政治的に困難でありうる。IT キュー、ベンダー契約、インターフェース仕様、セキュリティレビュー、テストウィンドウ、変更管理に触れる。PROMs プログラムにとって、完璧なフィードを何ヶ月も待つことは、適格な術前記録を失うことを意味する可能性がある。安全な抽出から始めることで、後で伝送を自動化するオプションを保持しつつ、早期の価値を生み出すことができる。トレードオフは、単純な抽出が一部のガバナンスリスクをプロセス設計に移すことである。誰かが、抽出が最新で、完全で、一貫してフォーマットされ、適切なプライバシーと同意の前提の下で扱われることを保証しなければならない。
段階的アプローチはまた、労働経済性も説明する。Code Technology は純粋なセルフサービス自動化を販売しているのではない。不完全な病院システムの周りに運用ラッパーを販売しているのだ。顧客の EHR がクリーンなスケジューリングと登録メッセージを送信するならば、システムはより人手がかからなくなる。顧客がアップロードから開始するならば、ベンダーのチームはフィールドの検証、欠落値の理解、再スケジュールの監視、異常の捕捉を支援しなければならない。購買者は、各成熟度レベルにおいて各側にどのような作業が残るのかを尋ねるべきである。「追加スタッフ不要」というのは魅力的なフレーズだが、実際的なバージョンはより正確である：どのスタッフがもはや電話をかけなくなるのか、どのスタッフが依然として抽出を提供するのか、誰が例外を解決するのか、誰が提出ファイルに承認を与えるのか、そしてインターフェースが変更されたときに誰が問題の所有権を持つのか。
ここでロックインが始まる。プロバイダーが何年もの PROMs 履歴、レジストリベンチマーク、報告ルーチン、エクスポート形式、アカウントマネージャーの知識を一つのシステムに持つと、ベンダーの切り替えはもはや調達の演習ではない。それはデータ移行と継続性のリスクである。Code Technology は、迅速なゴーライブと移行オプションの主張を含め、ベンダー置き換えをサポートされたパスとしてマーケティングしている。そのメッセージは両刃である。それは、同社が弱いシステムを置き換えることの痛みを理解していることを示唆する。また、成功した PROMs プラットフォームが臨床と財務のルーチンに組み込まれることを購入者に思い出させる。うまく機能すればするほど、顧客は将来の出口をより慎重に計画しなければならない。
同意とプライバシーは脚注ではない
患者報告アウトカムはデリケートな領域にある。データは伝統的な意味での診断ではないかもしれないが、痛み、機能、回復、可動性、精神状態、生活の質、識字能力、満足度、社会的文脈を明らかにする可能性がある。データは処置と臨床医にリンクされている。ケアの改善、レジストリ参加、認定、償還、支払者との議論に使用される可能性がある。そのため、同意、プライバシー、目的制限が運用記録の中心となる。
Code Technology のプライバシーページは、ウェブサイトのプライバシー通知であり、完全な技術的セキュリティホワイトペーパーではない。そこには、ウェブサイトサービスが氏名、電話番号、住所などの個人情報を収集する可能性があり、ログデータや分析ツールを使用する可能性があり、個人情報を販売しないと記載されている。また、インターネット伝送または電子ストレージの方法で完全に安全なものはないとも記載されている。それは標準的な文言だが、重要である。なぜなら、公開記録は、展開前に病院がレビューするであろう契約上、セキュリティ上、臨床データ上の管理策を完全には明らかにしていないからである。購入者は、保護対象健康情報が関与する場合のビジネスアソシエイト契約または同等の契約構造、セキュリティ文書、データ保持条件、侵害手続き、下請業者の可視性、アクセス制御設計、監査ログの利用可能性を依然として必要とするだろう。
同意の問題は、法律論的というよりも運用上のものである。患者は、なぜアンケートに答えるよう求められているのか、自分の回答がどのように使用されるのか、参加がケア、報告、研究、品質改善のいずれに関連しているのかを理解する必要がある。また、システムは、患者が拒否した場合、連絡が不適切な場合、手術が変更されたために症例がもはや適格でない場合を追跡する必要がある。Code Technology 自身の用語ページには、辞退、未完了、免除の評価カテゴリーと手術日後の処置確認が説明されている。その分類法は、同社がフォローアップ作業の実際の混乱に遭遇したことの兆候である。
未解決の公開質問は、これらのカテゴリーが展開全体でどの程度一貫して機能するかである。回答の辞退は、電話番号の欠落と同じではない。手術スケジュールの遅れは、患者の拒否と同じではない。言語の壁は、調査疲れと同じではない。これらの区別が保持されなければ、顧客はプログラムの弱点を過大評価したり、患者の負担を過小評価したり、不完全な説明をレジストリや支払者に提出する可能性がある。優れた臨床ソフトウェアは、これらの小さなラベルを正直に保たなければならない。
サポートの所有権は技術製品の一部である
エンタープライズソフトウェアでは、サポートはしばしばコストセンターとして扱われる。臨床ワークフローソフトウェアでは、サポートが信頼できる記録と脆弱な記録の違いになりうる。Code Technology はこれに傾注している。同社のページは、専任のアカウントマネージャー、臨床バックグラウンド、患者アウトリーチ、透明性のあるダッシュボード、応答性を強調している。中西部の医療システムのケーススタディでは、以前のベンダーを、サポート知識の弱さ、離職率、不明確な適格性ロジックで批判している。繰り返すが、その話はベンダーによって公開されたものだが、故障モードは信頼できる。すなわち、その尺度を説明できないサポートチームは、故障したインターフェースと同程度のリスクを生み出しうる。
サポートの所有権が重要なのは、PROMs ワークフローが職務の境界を越えるからである。レポートに患者が欠けている場合、問題はスケジューリング、抽出のタイミング、適格性ルール、患者アウトリーチ、処置確認、調査間隔ロジック、重複抑制、ダッシュボードフィルター、またはエクスポート設定にあるかもしれない。顧客はどこを見るべきか分からないかもしれない。ベンダーは顧客の運用を十分に理解しておらず、診断できないかもしれない。EHR ベンダーは、そのフィードが指定通りに機能していると言うかもしれない。臨床品質チームは期限に追われているかもしれない。管理されたサービスは、その曖昧さを吸収しなければならない。
したがって、Code Technology のモデルの最善のバージョンは、「ソフトウェア＋親切な人々」ではない。それは、繰り返し発生する臨床データワークフローのための実践的な運用デスクである。アカウントチームは尺度を知っており、顧客はエスカレーションパスを知っており、システムは記録が変更された場所を特定するのに十分な追跡証拠を生成すべきである。患者が登録され、連絡され、完了し、辞退し、免除され、または削除された場合、そのパスが見えるべきである。手術が再スケジュールされた場合、システムは元の日付がまだすべての間隔を規定しているかのように動作すべきではない。エクスポートが失敗した場合、サポートは問題がデータの欠落、マッピング、適格性、タイミング、またはファイル構築のいずれにあるかを言えるべきである。
ここで、購入者のデューデリジェンスは居心地の悪いものであるべきだ。例外レポート、サンプル実装タイムライン、データ辞書、エクスポート例、ロール権限、監査証跡ビュー、サポート応答コミットメント、更新および終了条件、ベンダーが変更された CMS 要件をどのように処理するかの証拠を求めるべきである。アカウントマネージャーが去ったときに何が起こるかを尋ねるべきである。顧客のスタッフが分母の完全性を独立して検証できるかどうかを尋ねるべきである。顧客が退出可能な形式でデータを所有しているかどうかを尋ねるべきである。Code Technology の公開ページは、これらの質問を認識していることを示唆している。公開ページがそのすべてに答えられるわけではない。
能力は信頼性と同じではない
臨床ソフトウェアの調達は、機能リストを報奨しがちである。マルチチャネルアウトリーチ、EHR に依存しない統合、ダッシュボード、ベンチマーキング、レジストリ報告、エクスポート、モバイルインターフェース、リマインダー、アクセシビリティ、電話サポートはすべて有用に聞こえる。より難しい質問は、ルーチンの変動下での信頼性である。顧客が外科医を変更したり、サービスラインを追加したり、スケジューリングワークフローを改訂したり、新しい報告プログラムを開始したり、診療所から医療システムに拡大したり、患者が年齢、言語、社会経済的グループによって異なる反応をすることを発見した場合に、製品は受け入れられた運用記録を首尾一貫して保つことができるか？
PROMs における信頼性にはいくつかの層がある。キャプチャの信頼性は、十分な数の適格な患者が適切な間隔で回答するかどうかを問う。身元の信頼性は、回答が正しい患者と処置に結び付けられているかどうかを問う。臨床的信頼性は、正しい調査票が使用され、一貫して解釈されているかどうかを問う。統合の信頼性は、上流のデータが期日通りに、期待される形で到着するかどうかを問う。エクスポートの信頼性は、下流のシステムや報告プログラムがその記録を消費できるかどうかを問う。ガバナンスの信頼性は、規制当局、認定機関、支払者、または執行委員会がその数字に異議を唱えた場合に、顧客が何が起こったかを説明できるかどうかを問う。
Code Technology の資料はこれらすべてに触れているが、公開証拠の深さは様々である。最も強力な公開証拠はワークフロー認識に関するものである：同社は、術前および術後のタイミング、アウトリーチの負担、処置確認、重複調査リスク、EHR 抽出の課題、報告プレッシャーを明確に理解している。顧客事例は、反復可能な手術エピソードが PROMs プログラムを運用上意味のあるものにする整形外科の文脈での使用を示している。より弱い公開証拠は、技術アーキテクチャ、セキュリティ管理、正式なサービスレベル、フィールドレベルの系統、独立したパフォーマンス比較に関するものである。それらは顧客契約の下で存在するかもしれないが、公開情報としては完全には見えない。
その不確実性は、Code Technology に固有の欠陥として扱われるべきではない。ほとんどの医療ソフトウェアベンダーは、アーキテクチャよりもアウトカムについて多く公開している。しかし、それは結論を形作るべきである。Code Technology の公開記録は、同社が経験豊富な管理された PROMs オペレーターであるという考えを支持している。すべての実装が同じ結果を達成するという、あるいはサービスが顧客からすべてのガバナンス作業を取り除くという、より強力な主張を支持しているわけではない。
顧客証拠はユースケースを示しており、普遍性を示しているわけではない
公開されている顧客資料には一貫したパターンがある。Holy Cross Orthopedic Institute は、Code Technology を使用して、術前、3ヶ月、1年の段階にわたって PROMs を収集し、ベンチマークと比較するものとして提示されている。McLeod Health は、月次の登録と完了した PRO ボリュームを伴う関節置換 PRO データレジストリを構築するものとして提示されている。ORA Orthopedics は、外科医の議論、共有意思決定、支払者交渉の文脈でベンチマーキングレポートを使用するものとして提示されている。中西部の医療システムのケーススタディは、CMS 報告の信頼性とサポートの所有権を中核的問題として、以前のソフトウェア障害からの回復に焦点を当てている。クライアントリソースページはまた、HonorHealth が脊椎手術の回復ベンチマークとケア改善の議論のために ODI および NDI データを使用していることを指摘している。
それは、製品が市場で動作していることを示すのに十分である。また、公開記録が筋骨格系ケア、特に整形外科、脊椎、関節置換に集中していることも示している。Code Technology は、CMS や価値ベースのプログラムが進化するにつれて、追加の専門分野への拡大について語っている。それは信頼できる戦略的方向性かもしれないが、公開証拠は、広範で専門分野に依存しない記録よりも、整形外科のユースケースにおいてより豊かである。それらの領域外の購入者は、整形外科の証明がクリーンに移転すると仮定するのではなく、専門分野固有の参照、調査票のカバレッジ、間隔ルール、報告パスウェイ、患者エンゲージメントの証拠を求めるべきである。
ケーススタディはまた、顧客の成果が注意深く読まれるべき理由を示している。公開された成功事例は、改善された完了率、軽減された負担、またはより強力なレジストリを報告できるが、ベースラインの人員配置、患者ミックス、適格基準、除外症例、契約条件、データクリーニングの努力、または顧客スタッフの正確な役割を明らかにしないかもしれない。それは、名前の付いた病院の経験や匿名の顧客の問題を説明するかもしれない。投資収益率に関するマーケティング言語を使用するかもしれない。だからといって証拠が無価値になるわけではない。それは証拠が方向性を示していることを意味する。正しい結論は「Code Technology は常にこれらの数字を達成する」ではない。それは「Code Technology には、管理された PROMs 収集が測定可能な運用上および品質上の目標に結び付けられた公開事例がある」である。
技術評価にとって、その区別は極めて重要である。市場シグナルは、病院が自身で PROMs 作業を維持するのに苦労しているため、管理されたサービスに対する需要があるということである。技術シグナルは、製品が単に孤立した調査を収集するだけでなく、長期的な臨床データ記録を維持する必要があるということである。商業シグナルは、システムが人員配置の負担を軽減し、報告の信頼性を保護できるならば、顧客は支払うであろうということである。不確実性シグナルは、購入者がこれらの主張を自身のワークフロー、量、報告範囲、ガバナンスのニーズに対して検証しなければならないということである。
データ主権と地域性は未解決の問題のままである
このプロフィールの対象地域はアジア太平洋およびインドであるが、公開されている Code Technology のサービス面は米国中心である。同社のウェブサイトは、CMS、AAOS、米国の病院、整形外科診療所、米国の品質プログラム、ミネアポリスの本社を強調している。それは、アイデンティティと地域性の境界を生み出す。読者は、別の証拠がそれを立証しない限り、同社がインドを拠点とするオペレーターであるとか、その公開展開がインドの医療制度のルールを中心に組織化されていると想定すべきではない。この記事に関連する公開エンティティは、codetechnology.com の患者報告アウトカムプロバイダーである Code Technology である。
その境界は、データ主権分析にとって重要である。PROMs ソフトウェアは、単なるフロントエンドアプリケーションではない。識別可能な健康関連情報、処置の文脈、回答データ、そして潜在的に品質報告の証拠を保持または処理する。インドまたは他のアジア太平洋市場のプロバイダーが同様の管理された PROMs モデルを検討した場合、質問は機能適合性を超えて広がる。データはどこでホストされているのか？どの法人が顧客と契約するのか？どのスタッフが患者記録にアクセスできるのか？サポートチームは国内か、国境を越えるのか？同意、保持、削除、患者アクセス権はどのように処理されるのか？ベンダーは現地の言語とアクセシビリティのニーズをサポートできるのか？エクスポートは現地のレジストリに合わせられているのか、それとも米国の報告プログラムだけなのか？患者への電話アウトリーチは、現地のプライバシーおよび通信規則の下でどのように管理されるのか？
Code Technology の公開ページは、これらの質問に完全には答えていない。マルチチャネルアウトリーチ、複数言語、プライバシーコミットメントについて議論しているが、グローバルなデータレジデンシーマトリックスや管轄固有の展開モデルを公開していない。米国の整形外科顧客にとって、それは通常のエンタープライズ契約事項かもしれない。インドやアジア太平洋の展開にとっては、それは最前線の調達問題になるだろう。Code Technology を価値あるものにしているのと同じ運用モデル、すなわち管理されたアウトリーチとサービス重視の臨床記録の取り扱いは、明確な地域性とアクセス管理の必要性も増大させる。
ここにはより広範な市場の教訓がある。医療ワークフローベンダーは、しばしば成功した臨床プロセスを反復可能な管理サービスに抽象化することによって拡大する。抽象化は決して完全ではない。患者の同意、言語、償還、レジストリ参加、臨床医の階層、データ共有規範は地域のままである。PROMs プラットフォームは、ガバナンス層がそれに伴って移動する場合にのみ移動できる。それがなければ、ベンダーは自動化の外観を輸出しつつ、顧客に最も困難な部分を自ら再構築させるリスクを冒す。
ユニットエコノミクスは回避される作業と保護される価値に依存する
Code Technology の経済的根拠は、単純な命題に基づいている：管理されたサービスを通じて患者報告アウトカムを収集・利用することは、顧客が単独でプロセスに人員を配置し管理するよう求めるよりも、コストが低いか、より防御可能な価値を生み出す。回避されるコストには、患者アウトリーチ、リマインダー管理、データクリーニング、適格性チェック、報告準備、レジストリ調整、サポートエスカレーション、失敗した実装サイクルが含まれる。生み出される価値には、償還保護、認定サポート、支払者交渉の証拠、外科医のベンチマーキング、研究準備の整ったデータセット、患者中心のケア改善が含まれうる。
この命題は信頼できる。なぜなら、作業は持続的だからである。クリニックの従業員は今週患者に電話をかけることができる。プログラムは、毎週、何年にもわたって、手術後1年に及ぶ可能性のある間隔にわたって、電話、テキスト、メール、追跡、照合、報告を行う必要がある。離職、休暇、競合する臨床優先事項、変化するルールは、手動プログラムを浸食する可能性がある。集中したサービスデスクを持つベンダーは、専門労働を顧客全体に分散させ、反復可能なツールを構築し、指標の変更により近い位置にいることができる。それがビジネスモデルの最善のバージョンである。
弱点は、ユニットエコノミクスが非常に顧客固有であることだ。顧客の手術量が少なく、報告の露出が最小限で、データを活用する計画がない場合、管理されたサービスは高価に見えるかもしれない。顧客が CMS の露出、認定への野心、支払者交渉、限られたスタッフ能力に直面している場合、同じサービスは、失敗した報告や追加雇用と比較して安価かもしれない。統合がシンプルであれば、製品はスムーズにスケールするかもしれない。上流のシステムが乱雑であれば、Code Technology のチームはより多くの例外作業を吸収し、顧客は依然として運用知識を提供しなければならない。
代替の問題もある。顧客は、EHR ネイティブの調査ツール、汎用調査プラットフォーム、レジストリ提供のワークフロー、専門分野に特化したアウトカムベンダー、内部の品質チーム、他の PROMs ベンダーを使用できる。Code Technology の差別化は、顧客がソフトウェアだけでなく、アウトソーシングされた運用機能を望む場合に最も強力である。購入者が既存の EHR 内での完全な制御を望んだり、成熟した社内レジストリチームを持っていたり、同社の最も強力な公開実績を超える専門分野のカバレッジを必要とする場合には、弱くなる。この製品は、普遍的な調査エンジンとしてではなく、管理された臨床証拠ユーティリティとして最もよく評価される。
労働への影響は現実だが魔法ではない
PROMs 自動化に関する労働の主張は、注意深い読解に値する。Code Technology は、アウトリーチ、リマインダー、データ入力、患者コミュニケーション、報告サポートを処理することにより、臨床チームと IT チームの負担を軽減できると述べている。顧客事例は、スタッフがデータを収集するのではなく、データを活用することに集中できるようになったと説明している。それが真実であれば意味がある。なぜなら、管理上の負担は PROMs プログラムが停滞する主な理由の一つだからである。
しかし、労働は消えるわけではない。所有権が変わるだけだ。Code Technology 自身のサービスモデルは人に依存している。そのアカウントマネージャー、アウトリーチチーム、サポートスタッフは、顧客の運用能力の一部になる。それは非常に良いトレードになりうる。専門化されたベンダーの労働力は、看護師、医療助手、品質アナリストに手動で患者を追跡させるよりも安価で信頼性が高い可能性がある。それはまた依存性を生み出す可能性もある。ベンダーのサポート品質が低下したり、アカウントチームが変わったり、契約が不利になったり、顧客のニーズがベンダーの標準プロセスから逸脱したりした場合、顧客はアウトソーシングした専門知識を迅速に置き換えるのが難しいことに気づくかもしれない。
顧客組織内のスタッフにとって、より良い目標は作業ゼロではない。それはより価値の高い作業だ。臨床スタッフは、外部チームが安全かつ敬意を持ってそれを行えるなら、リマインダーメッセージの送信に時間を費やすべきではない。品質チームは、システムが記録を保存できるなら、手動でレポートを組み立てるべきではない。外科医は、ベンチマークされた結果が利用可能なら、患者が改善したかどうかを推測する必要はない。しかし、顧客は依然としてプログラムの目的、患者コミュニケーション基準、データガバナンス、臨床的解釈、行動の所有権を必要とする。美しいデータを収集してもケア経路を変えない PROMs プログラムは、学習システムではなく報告演習である。
ここで、Code Technology のレジストリとベンチマーキングの言語が重要になる。製品の長期的な価値は、顧客が証拠を意思決定に活用するかどうかに依存する。ORA の公開事例は外科医の議論と支払者交渉を指摘している。McLeod の事例は革新とプロセステストを指摘している。Holy Cross はプログラムの品質検証と外科医間での診療の標準化を指摘している。それらが、作業を正当化するユースケースである。その第二段階がなければ、収集はコンプライアンスの芝居になる。
注意すべき故障モード
このカテゴリーの既知の故障モードは具体的である。同意の不一致は、患者がプログラムが期待する使用を理解または承認しなかった場合、または人物がもはや連絡されるべきでない後もアウトリーチが続く場合に発生する。重複記録は、クリニックと病院のシステムが両方とも同じ患者を登録した場合、または適切な照合なしに再スケジュールされた処置が新規エピソードとして扱われる場合に現れる。アンケートの未完了は、術前のウィンドウが逃された場合、術後のリマインダーが患者に届かない場合、またはシステムが言語、識字能力、アクセスの障壁に適応できない場合に発生する。計算ミスは、指標が誤って解釈された場合、調査票のバージョンが変更された場合、または必須のサポートフィールドが欠落している場合に発生する可能性がある。統合の遅延は、適格な患者がワークフローに入るのを妨げる可能性がある。エクスポートのギャップは、明らかに完全なデータをレジストリ、支払者、認定機関、または CMS 向けのプロセスで使用不能にする可能性がある。サポートの遅延は、小さな異常を報告の危機に変える可能性がある。
堅牢な Code Technology の展開は、これらのそれぞれに対して答えを持っているべきである。適格性がどのように定義されるか、重複がどのように防止されるか、辞退と免除の結果がどのように区別されるか、処置確認がどのように機能するか、連絡の好みがどのように処理されるか、不完全な記録がどのように表面化されるか、エクスポートがどのように検証されるか、CMS やレジストリ要件の変更がどのようにワークフローに反映されるかを示すべきである。また、顧客がサポートメールを信頼する必要なしに、症例の経路を監査できる方法も示すべきである。
これらの管理策の一部は公開情報で示唆されている。Code Technology は、発生しなかった手術に関連する術後評価のために患者に連絡することを避けるための手術後の処置確認について説明している。間隔ごとのキャプチャモニタリングについて説明している。EHR やスケジューリングデータのサポート、シンプルなアップロード開始と後の統合について説明している。ダッシュボード、エクスポート、レポートについて説明している。プログラムメンテナンスを処理するアカウントチームについて説明している。それらは有用なシグナルである。デューデリジェンスの基準は、それらのシグナルが単にマーケティングではなく、契約、実装、運用に現れるかどうかである。
戦略的見解
Code Technology は、医療が患者自身の言葉でアウトカムを証明するよう求められているために、ますます重要になっているカテゴリーで事業を展開している。その政策と市場の方向性は同社にとって有利である。患者報告アウトカムパフォーマンス尺度への CMS の注目、整形外科レジストリ活動、価値ベースのケアプログラム、認定の期待はすべて、信頼できる長期的なアウトカムデータへの需要を増大させる。かつて PROMs を研究のオーバーヘッドとして扱っていた病院や診療所は、今では収集をルーチン化するより強い理由を持っている。
同社の公開記録は、整形外科 PROMs ワークフローにおける実際の経験を持つ、集中的でサービス集約型のベンダーを示唆している。調査を送信することとプログラムを維持することの違いを理解している。公開された顧客事例、CMS 指向のコンテンツ、統合ガイダンス、レジストリポジショニング、サポート重視の商業メッセージを持っている。それだけで、そのニッチにおいて真剣なオペレーターと見なすのに十分である。
注意すべきは、そのニッチが厳しいことである。PROMs プログラムは、記録が繰り返されるワークフローの変更を通じて一貫性を保つ場合にのみ成功する。Code Technology の価値は、ダッシュボード、患者リンク、キャプチャに関するベンダーの主張の存在によって証明されるのではない。それは、顧客が同意、プライバシー、指標の完全性、サポートの所有権を保持しつつ、適格性からアウトリーチ、回答、処置確認、エクスポート、使用に至るまで患者エピソードを追跡できる場合に証明される。それはより高いハードルであり、正しいハードルである。
購入者にとって、実際的な結論は明快である。Code Technology を管理された臨床アウトカムインフラストラクチャ候補として扱うこと。機能だけでなく、例外処理を実証するよう求めること。キャンセルされた手術、変更された電話番号、重複登録、逃された術前間隔、遅延した EHR 抽出、患者の辞退、新しい CMS 要件、レジストリエクスポート、サポートの引き継ぎ、契約の終了をどのように処理するかを尋ねること。各ステップでどの顧客スタッフが責任を負い続けるかを尋ねること。データが中心的に収集されるだけでなく、ローカルでどのように使用できるかを尋ねること。
もし同社が顧客自身のワークフローにおいてこれらの質問に答えられるなら、それは実際の作業とリスクを減らすかもしれない。もし答えられなければ、顧客はサービス約束が付いた別のフォームシステムを購入していることになる。患者報告アウトカムにおいて、その違いは患者が帰宅し、報告の時計がまだ動いている後に初めて見えるようになる。そこが、Code Technology の真のテストが始まるところである。