病院の合併によって、ディレクトリや公開 Web サイトが変更されたときに、すべての電子メールの依存関係が移動するわけではありません。継承された検査サービスは依然として以前のドメインで署名する可能性があり、患者ポータルは別のテナントを使用する可能性があり、紹介メッセージは新しいブランディング チームが時代遅れとみなしたアドレスに届く可能性があります。統合されたブランドの単一の目標ポリシーではなく、これらのサービスの継続性から始めます。
合併ルート台帳を作成する
取得した各ドメインを、法的管理者、 DNS管理者、アプリケーション所有者、送信目的、受信目的とともにリストします。次に、患者ポータル、検査室通知、請求通知、従来の紹介サービスを個別にマッピングします。古いリターンパスと署名を含める セレクタ、レポート先とチームはそれぞれ変更できます。新しい病院のテナントを管理できる人は、検査室のベンダー テナントに対する権限を持たない可能性があります。
テスト患者を使用し、予約基準を作成します。結果が準備できたことを示すメッセージは、臨床内容を含めずにルートを検証できます。研究所の統合責任者に、メッセージがどこで作成されるか、リレーがメッセージに署名するか、ゲートウェイがメッセージを変更するかどうかについて説明してもらいます。受信インフラストラクチャを廃止する前に、参照操作で古い受信アドレスがまだ機能していることを確認します。
リブランディングと認証を区別する
作業された不動産は、ラボ通知に lab.care.test の可視の From を与えますが、legacy-lab.test の署名者になります。その署名は通過するように規定されていますが、無関係な署名ドメインが含まれています。これは文書化された前提であり、検証結果ではありません。表示名のみを変更しても、この不一致は修正されません。サービスでサポートされている承認済みの送信 ID を選択し、関連する署名ドメインを構成して、受信者側のブランドを変更する前に新しいルートをテストします。
レポートの所有権を明示的に移動します。現在受け取っている在庫 集計レポート、誰が処理サービスにアクセスできるか、および合併後の組織が古いエンティティのデータを受け取る権限を持っているかどうか。該当する場合は、外部レポート宛先の承認を確認します。報告への参加の変化が患者のコミュニケーション量の変化と混同されないように、日付のベースラインを保存してください。
従来のドメインを慎重に廃止する
ドメインは、紹介または返信を受信したまま送信を停止することができます。 RFC 7505 Null MXを定義します。これは、ドメインがメールを受け入れないことを通知します。これはスプーフィング防止スイッチではないため、依然として必要な受信ルートには不適切です。送信者の制限と受信の決定を分けてください。責任ある各所有者に廃止を承認するよう依頼し、重要なサービスが利用できなかった場合に最後に承認された構成を復元するための文書化されたパスを保持してください。
合併目録を医療コンプライアンスの証拠として扱わないでください。各事業体とその処理者を管理するプライバシー、契約、および保持の規則には、資格のあるレビューが必要です。この演習では架空のドメインを使用し、患者データは使用しません。 HIPAA 、現地の保健法、または報告サービスの譲渡による法的影響については決定しません。
書かれたルート台帳を検査する
すべての行は、予約された架空のドメイン、提案された所有者、および規定されたドメインを使用します。 DKIM 結果。セレクターデモ 1 は、インストールされたキーではなく、例示的なラベルです。 SPF 結果、その他の署名、 DNSポリシーの検出、実際の受信、およびアプリケーションの成功は不明です。キー、署名されたメッセージ、テストの実行、または配信の証拠は提供されません。
- 患者ポータル: portal.care.test より。 メール送信元 ポータル.ケア.テスト; DKIM d=portal.care.test,セレクターdemo1、パスとみなされます。提案された所有者 臨床応用のリーダー。次のアクション: 正確なポータル テナントと承認された制御メッセージを確認します。
- 研究室からの通知: lab.care.test より。 Legacy-lab.test からのメール; DKIM d=legacy-lab.test,セレクターdemo1、パスとみなされます。提案された所有者 研究室統合リーダー。次のアクション: サポートされているアライメント署名を確認します。表示名の変更だけでは不十分です。
- 請求に関する通知: billing.care.test より。 billing.care.test からのメール; DKIM d=billing.care.test,セレクターdemo1、パスとみなされます。提案された所有者 収益サイクルのリード。次のアクション: 独立した請求ルートをテストします。
- 従来の紹介:legacy-care.test より。 Legacy-care.test からのメール; DKIM d=legacy-care.test,セレクターdemo1、パスとみなします。提案された所有者紹介業務のリーダー。次のアクション: MXまたは受信インフラストラクチャを廃止する前に、進行中のインバウンド紹介を確認します。
d= が From と正確に一致する仮定された受け渡し署名は、その仮定のメッセージに厳密に調整されたパスを提供します。無関係な d= は、その署名からの位置合わせされたパスを提供しません。不明なSPFまたはその他の署名により、後者の場合の全体的な失敗の判定が妨げられます。これらの書面による前提では、ライブ構成や受信ボックスの配置は確立されません。
2 つの別々の退職決定を行う
架空の合併 M-01 の場合、古いドメインのアウトバウンド通知は移動したが、紹介操作には依然として Legacy-care.test でのインバウンド メッセージが必要であると仮定します。必要な受信サービスを維持します。アウトバウンド移行が完了したからといって、Null MXを公開しないでください。これとは別に、レポートを reports.new-care.test に移動するには、該当する RFC 9990 セクション 4 DNS認証と、古いエンティティのデータを共有するための組織の許可。 DNS認証は法的な承認や企業の承認ではありません。どちらかの権限が検証されていない場合は、許可されているインベントリ作業を続行しながら、レポートの移行を保留のままにしておきます。ドメイン、メールボックス、レポートの宛先は変更されませんでした。
証拠の境界を明確に保つ
RFC 9989 セクション 4.4 と 5.3.5 では、認証と アライメント;セクション 5.4 では、メッセージの処理を受信側のポリシーに任せています。セクション 7.4 では、ドメイン公開にはSPF単独ではなく有効なDKIMが必要です p=reject また、ユーザーがインターネット メーリング リストに投稿するドメインを拒否しないように警告します。対象となる正規化バイトはRFC 6376セクション 3.4 ～ 3.7 および 6.1 に基づいてDKIM整合性を決定します。どちらのメカニズムも、臨床、教育、または法的権威を検証するものではありません。実際の展開のために承認された現在の証拠を収集します。ここでの運用チェックリストは推奨事項であり、管轄区域固有のコンプライアンス評価ではありません。