Sairaalan yhdistäminen ei siirrä jokaista sähköpostiriippuvuutta hakemiston tai julkisen verkkosivuston muuttuessa. Peritty laboratoriopalvelu voi silti allekirjoittaa entisellä verkkotunnuksellaan, potilasportaali voi käyttää erillistä vuokraajaa ja läheteviestit voivat saapua osoitteisiin, joita uusi brändäystiimi pitää vanhentuneina. Aloita näiden palvelujen jatkuvuudesta, älä yhdestä yhdistetyn tuotemerkin kohdepolitiikasta.
Rakenna fuusioreittikirja
Luettele jokainen hankittu verkkotunnus ja sen laillinen ohjain, DNS järjestelmänvalvoja, sovelluksen omistaja, lähetystarkoitus ja vastaanottotarkoitus. Kartoita sitten erikseen potilasportaali, laboratorioilmoitus, laskutusilmoitus ja lähetepalvelu. Sisällytä vanha paluupolku, allekirjoitus valitsin, ilmoita määränpää ja tiimi saa muuttaa kutakin. Henkilöllä, joka pystyy hallinnoimaan uutta sairaalavuokralaista, ei välttämättä ole valtaa laboratorion myyjävuokralaiseen nähden.
Käytä testipotilaita ja keksittyjä ajanvarausviitteitä. Viesti, jossa sanotaan, että tulos on valmis, voi vahvistaa reitin ilman kliinistä sisältöä. Pyydä laboratorion integraatiojohtoa selittämään, missä viesti on luotu, mikä välittäjä allekirjoittaa sen ja muuttaako yhdyskäytävä sitä. Pyydä viittaustoimintoja varmistamaan, että vanhat saapuvat osoitteet toimivat edelleen, ennen kuin poistat vastaanottavan infrastruktuurin käytöstä.
Erottele uudelleenbrändäys autentikaatiosta
Työstetty tila antaa laboratorioilmoitukset näkyvän From of lab.care.test mutta allekirjoittajan legacy-lab.test. Sen allekirjoituksen on määrä hyväksyä, mutta sillä on liitymätön allekirjoitustoimialue; tämä on kirjallinen lähtökohta, ei varmennustulos. Pelkän näyttönimen muuttaminen ei korjaa tätä ristiriitaa. Valitse palvelun tukema hyväksytty lähetysidentiteetti, määritä asianmukainen allekirjoitustoimialue ja testaa uusi reitti ennen vastaanottajalle suunnatun brändäyksen muuttamista.
Siirrä raportin omistajuus erikseen. Varasto, joka saa tällä hetkellä koontiraportit, kuka voi käyttää käsittelypalvelua ja onko yhdistetyllä organisaatiolla oikeus vastaanottaa vanhan kokonaisuuden tiedot. Tarkista tarvittaessa ulkoinen raportointikohteen valtuutus. Säilytä päivätty lähtötaso, jotta raportointiin osallistumisen muutoksia ei sekoiteta potilaiden viestinnän volyymin muutoksiin.
Poista vanhat verkkotunnukset varovasti
Verkkotunnus voi lopettaa lähettämisen, vaikka se silti vastaanottaa viittauksia tai vastauksia. RFC 7505 määrittää Null MX , joka ilmoittaa, että toimialue ei hyväksy postia; se ei ole huijauksenestokytkin, eikä se sovellu edelleen tarvittavalle tuloreitille. Pidä lähettäjärajoitukset ja vastaanottopäätökset erillään. Pyydä jokaista vastuussa olevaa omistajaa hyväksymään eläkkeelle siirtyminen ja säilyttämään dokumentoitu polku viimeisimmän hyväksytyn kokoonpanon palauttamiseksi, jos tärkeä palvelu jäi väliin.
Älä pidä fuusioluetteloa todisteena terveydenhuollon vaatimustenmukaisuudesta. Kutakin tahoa ja sen käsittelijöitä koskevat yksityisyys-, sopimus- ja säilytyssäännöt vaativat perusteellisen tarkastelun. Tämä harjoitus käyttää kuvitteellisia verkkotunnuksia eikä potilastietoja; se ei ratkaise HIPAA :ta, paikallista terveyslakia tai raportointipalvelun siirtämisen oikeudellisia seurauksia.
Tarkista kirjallinen reittikirja
Kaikki rivit käyttävät varattuja kuvitteellisia verkkotunnuksia, ehdotettuja omistajia ja määrättyjä DKIM tuloksia. Valitsin demo1 on havainnollistava tarra, ei asennettu avain. SPF tulokset, muut allekirjoitukset, DNS -käytännön etsintä, todellinen vastaanotto ja sovelluksen onnistuminen ovat tuntemattomia. Avaimia, allekirjoitettuja viestejä, testin suorittamista tai toimitustodisteita ei toimiteta.
- Potilasportaali: Portaalista portal.care.test; POSTIA LÄHETTÄJÄ portal.care.test; DKIM d=portal.care.test, valitsin esittely1, oletettu läpäisy; ehdotettu omistaja Kliiniset sovellukset johtaa. Seuraava toimenpide: Tarkista tarkka portaalin vuokraaja ja hyväksytty valvottu viesti.
- Laboratorioilmoitus: osoitteesta lab.care.test; POSTIA LÄHTEESTÄ legacy-lab.test; DKIM d=legacy-lab.test, valitsin demo1, oletettu läpäisy; ehdotettu omistaja Laboratorion integrointijohto. Seuraava toimenpide: Vahvista tuettu tasattu allekirjoitus; näyttönimen muuttaminen ei riitä.
- Laskutusilmoitus: osoitteesta billing.care.test; POSTITILASTA billing.care.test; DKIM d=billing.care.test, valitsin esittely1, oletettu läpäisy; ehdotettu omistaja Tulosyklin johto. Seuraava toimenpide: Testaa riippumaton laskutusreitti.
- Vanha viittaus: osoitteesta legacy-care.test; POSTIA LÄHTEESTÄ legacy-care.test; DKIM d=legacy-care.test, valitsin esittely1, oletettu läpäisy; ehdotettu omistaja Suositustoimintojen johto. Seuraava toimenpide: Tarkista meneillään olevat saapuvat viittaukset ennen kuin poistat MX käytöstä tai vastaanotat infrastruktuurin.
Oletettu läpäisevä allekirjoitus, jonka d= vastaa täsmälleen From, tarjoaa tiukasti kohdistetun polun tälle hypoteettiselle viestille. Liittymätön d= ei anna tasattua polkua kyseisestä allekirjoituksesta. Tuntematon SPF tai muut allekirjoitukset estävät yleisen epäonnistumispäätöksen jälkimmäisessä tapauksessa. Nämä kirjalliset tilat eivät muodosta live-kokoonpanoa tai postilaatikon sijoittelua.
Tee kaksi erillistä eläkkeelle jäämispäätöstä
Kuvitteellisessa fuusiossa M-01 oletetaan, että vanhan verkkotunnuksen lähtevät ilmoitukset ovat siirtyneet, mutta viittaustoiminnot edellyttävät edelleen saapuvia viestejä osoitteessa legacy-care.test. Säilytä tarvittava vastaanottopalvelu; Älä julkaise Null MX ää vain siksi, että lähtevä siirto on valmis. Raporttien siirtäminen osoitteeseen reports.new-care.test tarvitsee erikseen RFC 9990 Osa 4 DNS valtuutus ja organisaation lupa jakaa vanhan entiteetin tiedot. DNS valtuutus ei ole laillinen tai yrityksen hyväksyntä. Jos kumpaakaan lupaa ei ole vahvistettu, jätä raportin siirto odottamaan, kun jatkat sallittua varastotyötä. Verkkotunnusta, postilaatikkoa tai raportin kohdetta ei muutettu.
Pidä todisteiden rajat selvänä
RFC 9989 Kohdissa 4.4 ja 5.3.5 erotetaan todennus ja linjaus; Kohta 5.4 jättää viestien käsittelyn vastaanottajakäytännön tehtäväksi. Kohta 7.4 edellyttää kelvollista DKIM ää pelkän SPF n sijaan verkkotunnusten julkaisussa p=reject ja varoittaa hylkäämästä verkkotunnuksia, joiden käyttäjät lähettävät viestejä Internetin postituslistoille. Katetut kanonisoidut tavut määrittävät DKIM eheyden RFC 6376 osioiden 3.4–3.7 ja 6.1 mukaisesti. Kumpikaan mekanismi ei vahvista kliinistä, koulutusta tai laillista auktoriteettia. Kerää valtuutetut nykyiset todisteet todellista käyttöönottoa varten; Tässä olevat toiminnalliset tarkistuslistat ovat suosituksia, eivät lainkäyttöaluekohtaisia vaatimustenmukaisuuden arviointia.