医療ミスの兆候を検索した方法

2006年、義父の頭に動脈瘤が爆発し、脳卒中が彼を襲った。 その日の夕方までに彼は冗談を言っていて、病棟を歩き回ろうとしていました。 医師の監督の下で起こった2回目の脳卒中は、彼の脳はそれに耐えることができませんでした-彼の義理の父は話し、歩き、親relativeを認識するのを止めました。 別の病院で、彼は立ち上がったが、最初の治療中の医療ミスのために、彼は永遠に言葉を失い、彼の性格は認識を超えて変化した。



彼に起こったことは院内脳卒中と呼ばれ、これは医療機関の全身性問題のマーカーの1つです（そうでなければトリガーの1つです）。 病院で予防可能な医療ミスの数を減らし、患者のケアの質を向上させるために、それらを分析する必要があります。



米国では、この問題は2000年代初頭に困惑しました。 マサチューセッツ州医療改善研究所（IHI）は、 有害事象を測定するためのIHIグローバルトリガーツールを開発しました。



2016年、私たち（SASのロシア事務所）は、ロシアのIHI方法論を使用して医療トリガーを分析するシステムを作成しようとしました。 その由来を説明します。

どこから始めましたか

まず、医療の質を分析するという考え方を共有する志を同じくする医師を探し始めました。 モスクワの複数の病院の長、欧州オフィスの同僚、デンマークの病院リレバエルトの代表者がSAS Forum Russia 2016に招待され、2015年にSAS分析プラットフォームに基づいてIHI方法論を使用してトリガー検出システムを作成しました。



デンマーク人の話はモスクワの大規模な総合病院の主治医に興味があり、医療記録を分析する実験を行うことに同意しました。 NDAの条件では、プロジェクトの詳細を明かすことはできません。そのため、私は病院を単にクリニックと呼び、その頭を主治医と呼び続けます。



2016年6月〜7月に、プロジェクトの内容と範囲についてクリニックの経営陣と話し合い、8月に参照条件を作成し、9月に作業を開始しました。 SASのチームのバックボーンは、Alexander Zhukov（ al_undefined ）とDmitry Kayatenkoで構成されていました。



IHIテクニックには51個のトリガーが含まれています。 クリニック管理と一緒に、プロジェクトのために以下を選択しました。

• 血液白血球<3,000 x 10 ^ 6 /μl（化学療法患者を除く）
• 血小板<50,000×10 ^ 6 /μl（化学療法患者を除く）
• 院内脳卒中
• 院内梗塞
• 24時間以内に集中治療室（ICU）に予定外の転送を繰り返した
• 手術後24時間以内の蘇生
• ベッド部門での蘇生対策

分析でよく起こるように、初期データの準備とそれらの重要な情報の割り当てにより、時間の大部分を占めました。

レコードが取得された方法

Clinicの医療情報システム（MIS）のデータは、複雑な構造を持つOracleデータベースに配置されました。 スキームの説明が見つからなかったため、データベースの情報とMISグラフィカルインターフェイスの情報を比較して、データ構造とエンティティの関係を復元する必要がありました。



このプロジェクトでは、次の種類の医療記録が必要でした。

• 医師の検査データ
• 診断表
• 日記エントリ
• トランザクションプロトコルと術前の概念
• 予定とパフォーマンス情報
• ステージおよび放電エピクリシス
• 翻訳されたエピクリシス
• 死後のエピクライシス

このデータ（診断のテーブルを除く）は、CLOBのXMLにあります。 ClinicにはXML構造の記述がなかったため、長い議論の間にそれらの内容を経験的に確立する必要がありました。



XML文書の中に混乱がありました。 たとえば、「一般状態」ノードには患者の苦情に関する情報が含まれ、「苦情」ノード自体は空のままでした。 多くの場合、医師は、患者に関するすべてのデータ（苦情、検査結果、薬物のさらなる治療および処方などに関する推奨事項）を1つのフィールド、たとえばコメンタリーに書き留めました。



XMLのフラットテーブルへの開発は、標準のSAS XMLマッパーによって行われました。 必要な情報がさまざまなネストレベルにある最も複雑なドキュメントは、Pythonパーサーで解析されました。 SASから起動され、SAS Enterprise Guideの単一の実行可能プロセスに統合されました。







臨床検査の結果をエピクリシスのテキストから引き出さないようにするため（ドキュメントを作成する医師の習慣を考えると、それでも喜びです）、それらのデータを検査情報システム（LIS）から取得しました。 また、XMLでラップされましたが、「分析」、「指標」、「値」という単純な形式です。

データの調査方法

医療記録を理解しやすい適切な処理形式にすると、7つのトリガーのうち、「白血球」と「血小板」の内容のみがトリガーされたことが判明しました。 これらは、しきい値と比較できる数値で表されました。



「24時間以内にICUへの予定外の転送を繰り返す」などのトリガーの分析を放棄する必要がありました。 このマーカーは日時スタンプに依存しており、神はそれが完璧であることを望んでいるため、クリニックのIIAに入力されました。数日を見逃したり、将来の日付を設定することさえできます。



院内脳卒中、心臓発作、蘇生処置は、いかなる方法でもエンコードされておらず、患者IDに関連して表に記録されていません。 それらは、エピクリシスと日記のエントリに求められるべきでした。 したがって、残りの4つのトリガーは非公式でした。つまり、非構造化テキストの分析を要求しました。



これを行うために、自然言語処理ツール-SAS Contextual Analysisを使用しました。 これは、プログラミングスキルや言語学の知識がなくてもテキスト処理モデルを作成できる視覚的なインターフェイスを備えたWebベースのソリューションです（ただし、主題分野とテキストが書かれている言語の知識なしではできません）。



今では、ニューラルネットワークを利用してこのような問題を解決することが流行になっています。 しかし、私たちは意識的にそれらを残し、言語規則のメカニズムを適用しました。

• ニューラルネットワークで良い結果が得られるのは、数万件のレコードのサンプルが医師によって事前にマークされた高品質でのみ可能ですが、その単語からはまったく得られませんでした
• ニューラルネットワークはその決定の明確な説明を与えず（解釈できない）、医師はブラックボックスを使用できません-どの症状、指標、またはアクションが有害事象を示しているかを正確に理解する必要があります

システムのトレーニング方法

リストのすべてのトリガーを処理しましたが、主な努力は院内発作と心臓発作の検出に焦点を合わせました（簡潔にするために院内感染と呼びます）。 これらは、患者の健康を損なうことに加えて、医療従事者によって宣伝されていないためひどいものである最も危険なトリガーの一部です。 そして、経営陣が問題について知らない場合、彼はそれを扱うことができません。



NSIではすべてが簡単ではありませんでした。 脳卒中または心臓発作の事実を統一された形で文書化する義務を負う標準や規制はありませんでした。 「。 時々、院内感染は処方された治療でのみ目に見えます。



基本的に、次のことができます。

1. すべての医師に、脳卒中や心臓発作の説明についてインタビューします。 しかし、何かを失うリスクがありました-一度作成されたレコードのリストと略語のディレクトリを覚えている人はいません。 そして、このテーマについて話をしたい人はほとんどいませんでした。
2. 医師と一緒に、すべてのエピクライシスを調べ、院内感染の兆候があるかどうかを分析します。 しかし、私たちも彼らもそんなに時間はありませんでした。

それ以外の場合：Contextual Analysisにテキストのコレクションをアップロードし、各エントリの重要なアイデアを強調するテーマモデルを構築しました。 文書のテキスト（たとえば、エピクライシス）に忍び寄ることなく、「ストローク」または「NMC」をテーマにしたレコードのみを選択し、VBIがテキストでどのように記述されているかを個別に調べることができました。さらに、モデル自体は、主要なアイデアを説明するための可能な定式化を提案しました。



文書をテーマごとにマークアップした後、医師と話し合い、トリガーを示すイベントを識別するための言語規則を明確にし、開発しました。 規則は、単語の文法形式、単語間の距離、単語の順序、位置（1つの文、段落、テキストの開始/終了）などを考慮しました。



そこで、蘇生法を探していました。







など-ストローク：







テキストを分析するときは、キーワードとその順序の間の距離を常に評価して、あまり多くキャプチャしないようにする必要があります。 必要な単語（「急性」、「違反」、「脳」、「血液循環」）がすべてフレーズに含まれているが、院内ストロークがそうでない場合の例を次に示します。







院内脳卒中の事実の説明を、同じキーワードが使用された以前の脳卒中の結果の説明から分離することは非常に重要でした：







除外ルール「ストロークの結果」（Remove_itemの上）：







医師と一緒に、エピクリシスにトリガーの兆候があるかどうかを判断する約30の言語規則を開発しました。 これらは、スコアリングコードの形式でコンテキスト分析からアンロードされ、SAS Enterprise Guideの実行可能レコード評価プロセスに接続されました。



しかし、院内脳卒中や心臓発作の場合、トリガーの存在に関する意思決定プロセスはそこで終わりませんでした。 患者の入院時に予測される可能性のあるケースを、トリガーの候補リストから削除する必要があります。 これを行うために、ルールを実行した結果を診断表と比較しました。



トリガーは、入院時の診断という点では予想外のイベント（患者の状態を悪化させる）であることを思い出させてください。 これは、患者の健康の悪化だけでなく、将来の合併症を排除するための体系的な対策を必要とする医療過誤または病院の問題のシグナルです。



Contextual Analysisが「院内梗塞」というラベルを何らかのレコードに割り当てたとしましょう。 診断を確認します：患者が冠状動脈性心臓病で入院した場合、心筋梗塞のリスクはすでに高かったです。 このイベントは、好意的ではありませんが、残念ながら予想されています。 レコードトリガー属性が割り当てられていません。



患者が虫垂炎で入院し、治療中に脳卒中を起こした場合、これは医療過誤である可能性があります。 例えば、彼らは圧力に従わなかったり、いくつかの薬物や行動でそれに圧力をかけなかった。 レコードは属性「トリガー」を割り当てます。



結果はビジネスプロセスです。







医師にとっては便利でした-彼らは独自にエピクリシスの分析のための言語規則を補足することができ、それはスコアリングコードにアップロードされ、分析システムによって選択されました。

データの視覚化方法

最後の段階で、SAS Visual Analyticsでレポートを設定しました。これは、視覚化およびBIタスク用のWebベースの製品です。 5分ごとに更新され、部門、医師、および患者の状況におけるトリガーの発生の統計を示しました。 責任医師（たとえば、心臓病学部門の責任者）はレポートを調べ、過去1時間、1日、1週間に検出されたトリガーを調べました。 部門で「失敗」したり、期間のトリガーのダイナミクスを確認したりできます。







記事にスクリーンショット（さらに「不鮮明」）を読み込まないために、非パーソナライズされたデータに関する小さなデモを記録しました。





また、トリガーに関する通知の自動送信を設定したいと考えていました。これは、重要なインジケーターを監視する分析システムにとって良い音色です。 さらに、メーリングリスト機能はSAS Visual Analyticsに組み込まれています。 しかし、クリニックは、外部サービスとのペアリングによるSMSメーリングの整理を拒否したように、メールサーバーへのアクセスを許可したくありませんでした。

それがすべて終わった方法

病院の管理者は、医療専門家チームによる有害事象のトリガーの手動検出の結果と、SASシステムによって実行された自動分析の結果を比較する実験を実施しました。 結果は人々に有利ではありませんでした：SASシステムは医療委員会以上のものを検出しました。 いくつかのトリガーについて-数倍：







しかし、精度の向上は、トリガー検出システムが提供する主なものではありません。 最も重要なことは、彼女が許可したこと：

1. すべての医療記録を継続的に監視するようにします。 偶然に選択されたケースや最もひどいケースではなく、時折。 四半期に一度だけでなく、リアルタイムに近いモードで。
2. 優秀な人材がコアアクティビティに従事するための時間を確保します。 実験の枠組みの中でのみ、医療スタッフは本格的な手動監査によって困惑することができました。 通常モードでは、これを行う時間はありません。医師がメモで忙しい場合、患者を治療する人はいません。

プロジェクトの成功のために重要だったのは、主治医、彼の代理人および部門長である行政の全面的な支援でした。 クリニックの長は米国で教育を受けたため、品質管理と自動データ分析に基づく管理の考え方は、彼にとって身近で明確であることが判明しました。



悲しいかな、分析システムの本格的な実装の少し前に、チーフ医師は辞任しました。 彼の後継者は率直に言って保守的であり、汚れたリネンを公の場で作ることを好まなかった。 クリニックは、有望なプロジェクトの結果を「テーブルに」書き留め、長年の実践によってテストされた作業方法に戻りました。



請求されていない製品を作るのはあまり楽しいことではありませんが、クリニックでの実験の経験は、強制医療保険システムの医療記録の監査に関する次のプロジェクトで非常に役に立ちました。 しかし、その別の時間についての詳細。