MRN形式の断片化問題
アメリカ合衆国には約6,100の病院があり、それぞれが独自の医療記録システムを運営しており、独自の医療記録番号形式を持っています。全国的なMRN標準は存在しません。医療機関を認定する合同委員会は、MRNがシステム内で患者を一意に特定する必要があると規定していますが、形式については指定していません。
その結果、実際のMRN形式には7桁の整数、8桁の整数、さまざまな長さの英数字の文字列、接頭辞コード（HOSP-、MRN-、PT-、PAT-）を含む形式化された文字列、前置された機関コード（SVHS-、CHOP-、MDACC-）、および登録年が番号に埋め込まれた日付エンコード形式が含まれます。
HIPAAのセーフハーバーの非識別化方法は、医療記録番号を削除する必要がある18の識別子のカテゴリー8としてリストしています（45 CFR Section 164.514(b)(2)）。この要件は形式によって制約されておらず、組織が使用するすべてのMRN形式を検出して削除する必要があります。特定のMRN形式を検出せずに臨床ノートを処理する組織は、他の識別子が削除されていてもHIPAAセーフハーバーの非識別化を達成していません。
コーディングの障壁
カスタムMRN形式を非識別化パイプラインに追加する標準的なアプローチは、Presidioのカスタム認識フレームワークに形式を実装することを必要とします。これには以下が含まれます：
Pythonクラスを作成してEntityRecognizerを拡張し、特定のMRN形式のregexパターンを定義し、パターンを適用するanalyze()メソッドを実装し、認識器をPresidioレジストリに追加し、代表的なサンプルに対して実装をテストし、形式が進化するにつれて実装を維持します。
Pythonの専門知識を持たない臨床情報学チームにとって、これはすべての形式変更に対してエンジニアリングチームへの依存を生み出します。医療機関のエンジニアリングリソースは通常、EHR統合や臨床意思決定支援に割り当てられ、コンプライアンスツールの構成には割り当てられません。
AIパターンヘルパー
AI支援のパターン作成アプローチは、コーディングワークフローをガイド付きインターフェースに置き換えます：
臨床情報学チームは、Webアプリケーションでカスタムエンティティクリエーターを開きます。彼らはシステムから5つのサンプルMRN値（SVHS-0012345、SVHS-0987654、SVHS-1122334、SVHS-4455667、SVHS-8899001）を提供します。彼らは「パターン生成」をクリックします。AIはサンプル構造を分析し、提供された例に一致するパターンSVHS-d{7}を返します；信頼レベルは高い；提案されたエンティティ名：HOSPITAL-MRN；提案された置換： [MRN]；追加のサンプルに対してテストして検証します。
チームは5つの追加テストサンプルを提供します。パターンは正しく検証されます。カスタムエンティティはHIPAAコンプライアンスプリセットに保存されます。以降のすべての非識別化セッション — Webアプリケーション、Officeアドイン、デスクトップアプリ、API — は、標準のPHI検出パスの一部としてSVHS形式のMRNを自動的に検出します。
GDPRの第89条に基づく研究免除は、研究データセットに対する擬似匿名化とデータ最小化を要求します。カスタムエンティティの作成は、機関特有の識別子が擬似匿名化の範囲に含まれることを保証し、一般的なツールが独自の形式に対して開いているカバレッジギャップを埋めます。
出典: