ヘルスケア メールは、患者ポータル、臨床アプリケーション、紹介ワークフロー、または一般オフィスのテナントから発信される可能性があります。正常なオフィスメール構成では、それらすべてが検証されるわけではありません。広範なトラブルシューティングのコレクションから患者情報を除外しながら、各通知のサービスと結果から始めます。
各アプリケーションをそのメール ID まで追跡します
患者ポータルの場合、通知を生成するシステムと、患者が基礎となる情報を表示するための承認されたパスを特定します。臨床システム通知の場合、臨床ワークフローと、人がメッセージに対応する必要があるかどうかを特定します。管理メールの場合は、単一の共有ルートを想定するのではなく、スケジュール、請求、またはオフィス アプリケーションを特定します。
ビジネスオーナー、技術オペレーター、プロバイダーテナント、From ドメイン、 封筒の差出人, DKIM 署名ドメインと セレクタ。承認された受信者の人数とエスカレーションの連絡先を追加します。ソフトウェア ベンダーは、異なるアウトバウンド構成で複数のサービスを運用できるため、ベンダー名だけでなく、実際のモジュールとテナントを確認してください。
臨床的権限をメール ID から切り離しておくこと
認証されたメッセージは、臨床オーダーが有効であること、結果が対象の患者のものであること、または受信者がそれを閲覧する権限を持っていることを確立するものではありません。これらのコントロールは、臨床システムおよびアイデンティティ システムに属します。このガイドでは、緊急の臨床決定に通常の電子メールを使用したり、既存の臨床コミュニケーション ポリシーを変更したりすることは推奨していません。
どの通知の失敗がケアに影響を与える可能性があるか、およびどの承認されたエスカレーション プロセスが適用されるかを臨床所有者と同意します。患者に電話したり、個人のメールボックスを通じて情報を再送信したりするなどの代替策を考え出さないでください。メール管理者は、臨床スタッフが適切なサービス対応を決定する間、観察された欠陥を必要最小限の詳細でエスカレーションする必要があります。
患者記録を収集せずに検査する
指定されたテスト環境で、承認された架空の患者と合成ワークフロー データを使用します。代表的なポータル、臨床システム、および管理メッセージをトリガーします。最終バイトと信頼できる受信者の認証結果を検査し、テストケースと送信ルートを区別するために必要な識別子のみを記録します。
メッセージは、件名で多くの情報を開示している場合や、間違ったアドレスに到達している場合でも、正常に認証されることがあります。したがって、コンテンツの最小化と受信者の検証には独自のチェックが必要です。編集されたヘッダーまたは管理された標本で十分な場合は、完全な臨床メッセージを認証チケットにコピーすることは避けてください。患者情報のアクセス、保持、および外部への開示には、組織の適切なプライバシー プロセスが必要です。
ルート固有のリリースゲートを設定する
ポリシーを変更する前に、重要なフローごとに特定された所有者、検証された構成、代表的なテスト、および承認された回復アクションが必要です。頻度が少ない紹介や結果の通知は、量が少ない場合でも明示的に取り上げる価値があります。合計の合格率は、臨床的に関連するすべてのルートが実行されたことを示すことはできません。
以下の架空の行政標本は、有効ではあるが調整されていないDKIM署名者を想定しています。これは調査すべき技術的なギャップを示しており、病院やサプライヤーに関する主張ではありません。実際のサービスに別の調整された認証パスがあるかどうかを確認してから、そのサービスを判断する DMARC 結果。所有権や患者への影響が不明瞭な場合は、停止してエスカレーションします。
臨床システムのアップグレード、ポータルの交換、買収およびベンダー ホスティングの変更後にルート マップを更新します。正確にテストされた構成とその日付の証拠を保持します。適用される医療プライバシー、セキュリティ、および記録管理の義務は、組織と管轄区域によって異なります。これらのプロトコル テストは、準拠性評価を構成するものではありません。
書かれたルート台帳を検査する
すべての行は、予約された架空のドメイン、提案された所有者、および規定されたDKIM結果を使用します。セレクターデモ 1 は、インストールされたキーではなく、例示的なラベルです。 SPF 結果、その他の署名、 DNSポリシーの検出、実際の受信、およびアプリケーションの成功は不明です。キー、署名されたメッセージ、テストの実行、または配信の証拠は提供されません。
- 患者ポータル: portal.health.exampleより;未知のメールからのメール。 DKIM d=portal.health.example,セレクターdemo1、パスを想定。提案された所有者 患者ポータルの所有者。次のアクション: このテナントでサポートされている署名パスとその個別のアプリケーション受け入れ基準を確認します。
- 臨床システム通知: clinical.health.exampleより。未知のメールからのメール。 DKIM d=clinical.health.example,セレクターdemo1、パスを想定。提案された所有者 臨床情報学の所有者。次のアクション: このテナントでサポートされている署名パスとその個別のアプリケーション受け入れ基準を確認します。
- 管理メール: admin.health.exampleから;未知のメールからのメール。 DKIM d=provider.example.net,セレクターdemo1、パスとみなされます。提案された所有者 管理所有者。次のアクション: このテナントでサポートされている署名パスとその個別のアプリケーション受け入れ基準を確認します。
d= が From と正確に一致する仮定された受け渡し署名は、その仮定のメッセージに厳密に調整されたパスを提供します。無関係な d= は、その署名からの位置合わせされたパスを提供しません。不明なSPFまたはその他の署名により、後者の場合の全体的な失敗の判定が妨げられます。これらの書面による前提では、ライブ構成や受信ボックスの配置は確立されません。
臨床方針を変更せずに失敗を解決する
架空のケース H-01 の場合、ポータル通知は調整されたDKIMを通過しますが、その受信者のマッピングが間違ったテスト アカウントを指していると規定します。メール ID チェックではその欠陥は解決されません。影響を受けるロールアウトを停止し、承認された臨床/プライバシー プロセスを通じてマッピングの問題をエスカレーションします。登録またはアイデンティティの所有者は、受信者のマッピングを検証します。医療関連の対応は臨床業務によって決定されます。共有診断では、診断、結果、実際の患者の住所ではなく、H-01 とルート識別子が保持されます。臨床的な緊急性が存在する場合は、メール チームが提案する電子メールによる回避策ではなく、既存の承認済みの臨床エスカレーション プロセスを使用してください。ここには患者や臨床上の決定は関与しませんでした。
証拠の境界を明確に保つ
RFC 9989 セクション 4.4 と 5.3.5 では、認証と アライメント;セクション 5.4 では、メッセージの処理を受信側のポリシーに任せています。セクション 7.4 では、ドメイン公開にはSPF単独ではなく有効なDKIMが必要です p=reject また、ユーザーがインターネット メーリング リストに投稿するドメインを拒否しないように警告します。対象となる正規化バイトはRFC 6376セクション 3.4 ～ 3.7 および 6.1 に基づいてDKIM整合性を決定します。どちらのメカニズムも、臨床、教育、または法的権威を検証するものではありません。実際の展開のために承認された現在の証拠を収集します。ここでの運用チェックリストは推奨事項であり、管轄区域固有のコンプライアンス評価ではありません。