Terveydenhuollon sähköpostit voivat olla peräisin potilasportaalista, kliinisestä sovelluksesta, lähetetyönkulusta tai yleisestä toimistovuokraajalta. Terveet toimistosähköpostiasetukset eivät vahvista niitä kaikkia. Aloita jokaisen ilmoituksen palvelusta ja seurauksista pitäen samalla potilastiedot poissa laajoista vianetsintäkokoelmista.
Jäljitä jokainen sovellus sen sähköpostiidentiteettiin
Määritä potilasportaalia varten järjestelmä, joka luo ilmoituksen, ja hyväksytty polku, jolla potilas voi tarkastella taustatietoja. Tunnista kliinisen järjestelmän ilmoituksia varten kliinisen työnkulku ja se, onko henkilön toimittava viestin perusteella. Tunnista hallinnollisen postin ajoitus-, laskutus- tai toimistosovellus sen sijaan, että otat yhden jaetun reitin.
Tallenna yrityksen omistaja, tekninen toimija, palveluntarjoajan vuokraaja, verkkotunnuksesta, kirjekuoren lähettäjä, DKIM verkkotunnuksen allekirjoittaminen ja valitsin. Lisää hyväksytty vastaanottajajoukko ja eskalointiyhteyshenkilö. Ohjelmistotoimittaja voi käyttää useita palveluita eri lähtevien kokoonpanojen kanssa, joten tarkista todellinen moduuli ja vuokralainen, ei vain toimittajan nimeä.
Pidä kliiniset auktoriteetit erillään postin henkilöllisyydestä
Todennettu viesti ei vahvista, että kliininen tilaus on kelvollinen, että tulos kuuluu aiotulle potilaalle tai että vastaanottajalla on lupa tarkastella sitä. Nämä kontrollit kuuluvat kliinisiin ja identiteettijärjestelmiin. Oppaassa ei suositella tavallisen sähköpostin käyttöä kiireellisiin kliinisiin päätöksiin tai olemassa olevan kliinisen viestintäpolitiikan muuttamiseen.
Sovi kliinisen omistajan kanssa, mitkä ilmoitushäiriöt voivat vaikuttaa hoitoon ja mitä hyväksyttyä eskalointiprosessia sovelletaan. Älä keksi varavaihtoehtoa, kuten potilaiden soittamista tai tietojen lähettämistä uudelleen henkilökohtaisen postilaatikon kautta. Postin ylläpitäjien tulee esitellä havaittu vika mahdollisimman pienillä tarvittavilla yksityiskohdilla, kun taas kliininen henkilökunta päättää asianmukaisesta palvelusta.
Testaa keräämättä potilastietoja
Käytä hyväksyttyjä kuvitteellisia potilaita ja synteettisiä työnkulkutietoja määritetyssä testiympäristössä. Käynnistä edustajaportaali, kliininen järjestelmä ja hallinnolliset viestit. Tarkista lopulliset tavut ja luotettavat vastaanottimen todennustulokset ja tallenna vain ne tunnisteet, jotka ovat tarpeen testitapauksen ja lähetysreitin erottamiseksi.
Viesti voi todentaa onnistuneesti, kun se paljastaa liikaa sen aiheessa tai saavuttaa väärän osoitteen. Sisällön minimointi ja vastaanottajan vahvistus tarvitsevat siksi omat tarkistuksensa. Vältä täydellisten kliinisten viestien kopioimista todennuslippuun, kun redaktoitu otsikko tai kontrolloitu näyte riittää. Potilastietojen käyttö, säilyttäminen ja ulkoinen paljastaminen edellyttävät organisaation sovellettavaa tietosuojaprosessia.
Aseta reittikohtainen vapautusportti
Ennen kuin muutat käytäntöä, vaadi tunnistettu omistaja, varmennettu kokoonpano, edustava testi ja hyväksytty palautustoiminto jokaiselle kriittiselle vuolle. Harvinaiset viittaukset tai tulosilmoitukset ansaitsevat selkeän kattavuuden, vaikka niiden määrä on pieni. Aggregoitu läpäisyprosentti ei voi osoittaa, että jokaista kliinisesti merkityksellistä reittiä on harjoitettu.
Alla olevassa kuvitteellisessa hallinnollisessa mallissa oletetaan kelvollista, mutta kohdistamatonta DKIM allekirjoitusta. Tämä kuvaa teknistä puutetta tutkittavaksi, ei väitettä mistään sairaalasta tai toimittajasta. Tarkista, onko todellisella palvelulla toinen kohdistettu todennuspolku, ennen kuin arvioit sen DMARC tulos. Pysäytä ja eskaloi, kun omistajuus tai potilasvaikutus on epäselvä.
Päivitä reittikartta kliinisen järjestelmäpäivitysten, portaalin vaihdon, hankintojen ja toimittajan isännöintiin liittyvien muutosten jälkeen. Säilytä todisteet tarkasta testatusta kokoonpanosta ja sen päivämäärästä. Sovellettavat terveydenhuollon yksityisyyttä, turvallisuutta ja kirjanpitovelvollisuudet riippuvat organisaatiosta ja lainkäyttöalueesta; nämä protokollatestit eivät ole vaatimustenmukaisuuden arviointia.
Tarkista kirjallinen reittikirja
Kaikilla riveillä käytetään 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: From portal.health.example ; POSTIT tuntematon; DKIM d=portal.health.example, valitsin esittely1, oletettu läpäisy; ehdotettu omistaja Potilasportaalin omistaja. Seuraava toimenpide: Tarkista tämän vuokralaisen tuettu allekirjoituspolku ja sen erilliset hakemuksen hyväksymisehdot.
- kliinisen järjestelmän huomautus: From clinical.health.example ; POSTIT tuntematon; DKIM d=clinical.health.example, valitsin esittely1, oletettu läpäisy; ehdotettu omistaja Kliinisen informatiikan omistaja. Seuraava toimenpide: Tarkista tämän vuokralaisen tuettu allekirjoituspolku ja sen erilliset hakemuksen hyväksymisehdot.
- hallinnollinen sähköposti: osoitteesta admin.health.example ; POSTIT tuntematon; DKIM d=provider.example.net, valitsin demo1, oletettu läpäisy; ehdotettu omistaja Hallintoomistaja. Seuraava toimenpide: Tarkista tämän vuokralaisen tuettu allekirjoituspolku ja sen erilliset hakemuksen hyväksymisehdot.
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.
Ratkaise vika muuttamatta kliinistä käytäntöä
Kuvitteellisessa tapauksessa H-01 edellytä, että portaalin ilmoitus välittää kohdistetun DKIM , mutta sen vastaanottajan yhdistäminen osoittaa väärälle testitilille. Postin henkilöllisyyden tarkistus ei korjaa tätä vikaa. Pysäytä ongelmallinen käyttöönotto ja eskaloi kartoitusongelma hyväksytyn kliinisen/tietosuojaprosessin kautta. Rekisteröinnin tai henkilöllisyyden omistaja varmistaa vastaanottajakartoituksen; kliiniset leikkaukset ratkaisevat kaikki hoitoon liittyvät vasteet. Jaettu diagnostiikka säilyttää H-01:n ja reitin tunnisteen, ei diagnoosia, tulosta tai todellista potilaan osoitetta. Jos kliininen kiire on olemassa, käytä olemassa olevaa hyväksyttyä kliinistä eskalointiprosessia, älä sähköpostitiimin ehdottamaa sähköpostikiertotapaa. Tässä ei ollut mukana potilasta tai kliinistä päätöstä.
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.