En sjukhusfusion flyttar inte varje e-postberoende när katalogen eller den offentliga webbplatsen ändras. En ärvd laboratorietjänst kan fortfarande signera med sin tidigare domän, en patientportal kan använda en separat hyresgäst, och remissmeddelanden kan komma till adresser som det nya varumärkesteamet anser vara föråldrade. Börja med kontinuitet för dessa tjänster, inte en enda målpolicy för det kombinerade varumärket.
Bygg en sammanslagningsvägbok
Lista varje förvärvad domän med dess juridiska registeransvarige, DNS administratör, applikationsägare, sändningsändamål och mottagningsändamål. Kartlägg sedan patientportal, laboratorieavisering, faktureringsavisering och äldre remisstjänst separat. Inkludera den gamla returvägen, signering väljare, rapportera destination och teamet får ändra var och en. En person som kan administrera den nya sjukhushyresgästen kanske inte har någon auktoritet över laboratoriets säljare.
Använd testpatienter och påhittade mötesreferenser. Ett meddelande som säger att ett resultat är klart kan validera rutten utan att inkludera kliniskt innehåll. Be laboratorieintegrationsledningen förklara var meddelandet skapas, vilket relä som signerar det och om en gateway ändrar det. Låt hänvisningsverksamheten bekräfta att gamla inkommande adresser fortfarande fungerar innan eventuell mottagande infrastruktur avvecklas.
Skilj om varumärke från autentisering
Den arbetade dödsboet ger laboratoriemeddelanden en synlig Från av lab.care.test men en undertecknare av legacy-lab.test. Dess signatur är förutsatt att godkännas men har en icke-relaterad signeringsdomän; detta är en skriftlig premiss, inte ett verifieringsresultat. Att bara ändra ett visningsnamn skulle inte fixa den oöverensstämmelsen. Välj en godkänd sändningsidentitet som stöds av tjänsten, konfigurera den relevanta signeringsdomänen och testa den nya rutten innan du ändrar mottagarens varumärke.
Flytta rapportägande uttryckligen. Inventering som för närvarande tar emot samlade rapporter, vem som kan komma åt bearbetningstjänsten och om den sammanslagna organisationen är behörig att ta emot den gamla enhetens uppgifter. Verifiera extern rapport-destinationsauktorisering där så är tillämpligt. Bevara en daterad baslinje så att förändringar i rapporteringsdeltagande inte förväxlas med förändringar i patientkommunikationsvolym.
Ta bort äldre domäner försiktigt
En domän kan sluta skicka medan den fortfarande tar emot hänvisningar eller svar. RFC 7505 definierar Null MX , som meddelar att domänen inte accepterar e-post; det är inte en anti-spoofing-switch och är olämplig för en inkommande rutt som fortfarande behövs. Håll avsändarbegränsningar och mottagningsbeslut åtskilda. Be varje ansvarig ägare att godkänna pensionering och behålla en dokumenterad väg för att återställa den senast godkända konfigurationen om en kritisk tjänst missades.
Behandla inte en sammanslagningsinventering som bevis på efterlevnad av sjukvården. Integritets-, avtals- och lagringsreglerna som styr varje enhet och dess processorer kräver kvalificerad granskning. Den här övningen använder fiktiva domäner och inga patientdata; den fattar inget beslut om HIPAA , lokal hälsolagstiftning eller de juridiska konsekvenserna av att överföra en rapporteringstjänst.
Inspektera den skriftliga ruttboken
Alla rader använder reserverade fiktiva domäner, föreslagna ägare och stipulerade DKIM resultat. Selector demo1 är en illustrativ etikett, inte en installerad nyckel. SPF resultat, andra signaturer, upptäckt av DNS policy, faktiska mottagandet och applikationsframgång är okända. Inga nycklar, signerade meddelanden, testutförande eller leveransbevis tillhandahålls.
- Patientportal: Från portal.care.test; MAIL FRÅN portal.care.test; DKIM d=portal.care.test, selector demo1, antaget godkänt; föreslagen ägare Kliniska ansökningar leda. Nästa åtgärd: Verifiera den exakta portalhyresgästen och godkänt kontrollerat meddelande.
- Laboratoriemeddelande: Från lab.care.test; MAIL FRÅN legacy-lab.test; DKIM d=legacy-lab.test, selector demo1, antagen godkänd; föreslagen ägare Laboratorieintegrationsled. Nästa åtgärd: Bekräfta anpassad signering som stöds; Det räcker inte att ändra visningsnamnet.
- Faktureringsmeddelande: Från billing.care.test; MAIL FRÅN billing.care.test; DKIM d=billing.care.test, selector demo1, antaget godkänt; föreslagen ägare Intäktscykelledare. Nästa åtgärd: Testa den oberoende faktureringsvägen.
- Legacy remiss: Från legacy-care.test; MAIL FRÅN legacy-care.test; DKIM d=legacy-care.test, selector demo1, antaget godkänt; föreslagen ägare Remissverksamhet leder. Nästa åtgärd: Verifiera pågående inkommande hänvisningar innan du avbryter MX eller tar emot infrastruktur.
En antagen passerande signatur vars d= exakt matchar From tillhandahåller en strikt anpassad väg för det hypotetiska meddelandet. En icke-relaterad d= tillhandahåller ingen justerad väg från den signaturen. Okänd SPF eller andra signaturer förhindrar ett övergripande misslyckande för det senare fallet. Dessa skrivna lokaler upprättar ingen live-konfiguration eller inkorgsplacering.
Ta två separata pensionsbeslut
För påhittad sammanslagning M-01, anta att utgående meddelanden från gamla domäner har flyttats men hänvisningsåtgärder kräver fortfarande inkommande meddelanden på legacy-care.test. Behåll den nödvändiga mottagningstjänsten; publicera inte Null MX bara för att utgående migrering är klar. Separat behöver flytta rapporter till reports.new-care.test det tillämpliga RFC 9990 4 § DNS behörighet och organisationstillstånd att dela den gamla enhetens data. DNS auktorisering är inte juridiskt eller affärsmässigt godkännande. Med endera behörigheten overifierad, lämna rapportmigreringen väntande medan du fortsätter med tillåtet inventeringsarbete. Ingen domän, postlåda eller rapportdestination ändrades.
Håll bevisgränserna tydliga
RFC 9989 Avsnitt 4.4 och 5.3.5 särskiljer autentisering och inriktning; Avsnitt 5.4 överlåter meddelandehantering till mottagarpolicy. Avsnitt 7.4 kräver giltig DKIM snarare än SPF enbart för domänpublicering p=reject och varnar för avvisande för domäner vars användare skickar till Internet-e-postlistor. Täckta kanoniserade bytes bestämmer DKIM integriteten enligt RFC 6376 avsnitt 3.4–3.7 och 6.1. Ingen av mekanismerna validerar klinisk, utbildningsmässig eller juridisk auktoritet. Samla in auktoriserade aktuella bevis för en faktisk implementering; de operativa checklistorna här är rekommendationer, inte en jurisdiktionsspecifik efterlevnadsbedömning.