Une fusion d'hôpital ne modifie pas toutes les dépendances en matière de courrier électronique lorsque l'annuaire ou le site Web public change. Un service de laboratoire hérité peut toujours signer avec son ancien domaine, un portail patient peut utiliser un locataire distinct et les messages de référence peuvent arriver à des adresses que la nouvelle équipe de branding considère comme obsolètes. Commencez par la continuité de ces services, et non par une politique d'objectif unique pour la marque combinée.
Créer un grand livre d'itinéraires de fusion
Répertoriez chaque domaine acquis avec son contrôleur légal, son administrateur DNS , son propriétaire d'application, son objectif d'envoi et son objectif de réception. Mappez ensuite séparément le portail patient, l’avis de laboratoire, l’avis de facturation et l’ancien service de référence. Inclure l'ancien chemin de retour, en signant sélecteur, signalez la destination et l'équipe est autorisée à modifier chacune d'entre elles. Une personne capable d'administrer le nouveau locataire de l'hôpital peut n'avoir aucune autorité sur le locataire vendeur du laboratoire.
Utilisez des patients testés et des références de rendez-vous inventées. Un message indiquant qu'un résultat est prêt peut valider le parcours sans inclure de contenu clinique. Demandez au responsable intégration du laboratoire d'expliquer où le message est créé, quel relais le signe et si une passerelle le modifie. Demandez aux opérations de référencement de confirmer que les anciennes adresses entrantes fonctionnent toujours avant de retirer toute infrastructure de réception.
Distinguer le rebranding de l’authentification
Le domaine travaillé donne aux avis de laboratoire un De visible de lab.care.test mais un signataire de Legacy-lab.test. Sa signature est stipulée pour être transmise mais possède un domaine de signature sans rapport ; il s'agit d'une prémisse écrite, pas d'un résultat de vérification. Changer uniquement un nom d’affichage ne résoudrait pas cette inadéquation. Sélectionnez une identité d'envoi approuvée prise en charge par le service, configurez le domaine de signature approprié et testez la nouvelle route avant de modifier la marque destinée au destinataire.
Déplacez explicitement la propriété du rapport. Inventaire qui reçoit actuellement rapports agrégés, qui peut accéder au service de traitement et si l'organisation fusionnée est autorisée à recevoir les données de l'ancienne entité. Vérifiez l’autorisation externe de destination du rapport, le cas échéant. Conservez une base de référence datée afin que les changements dans la participation aux rapports ne soient pas confondus avec les changements dans le volume de communication avec les patients.
Retirez prudemment les domaines existants
Un domaine peut cesser d'envoyer tout en recevant des références ou des réponses. RFC 7505 définit Null MX , qui annonce que le domaine n'accepte aucun courrier ; ce n'est pas un commutateur anti-usurpation d'identité et il est inapproprié pour une route entrante encore nécessaire. Séparez les restrictions de l’expéditeur et les décisions de réception. Demandez à chaque propriétaire responsable d'approuver le retrait et conservez un chemin documenté pour restaurer la dernière configuration approuvée si un service critique a été manqué.
Ne considérez pas un inventaire de fusion comme une preuve de conformité aux soins de santé. Les règles de confidentialité, de passation de contrats et de conservation régissant chaque entité et ses sous-traitants nécessitent un examen qualifié. Cet exercice utilise des domaines fictifs et aucune donnée sur les patients ; il ne prend aucune décision sur HIPAA , la loi locale sur la santé ou les conséquences juridiques du transfert d'un service de reporting.
Inspecter le grand livre de route écrit
Toutes les lignes utilisent des domaines fictifs réservés, des propriétaires proposés et stipulés DKIM résultats. Le sélecteur demo1 est une étiquette illustrative, pas une clé installée. SPF les résultats, les autres signatures, la découverte de la politique DNS , la réception réelle et le succès de l'application sont inconnus. Aucune clé, message signé, exécution de test ou preuve de livraison n'est fourni.
- Portail patient : depuis portal.care.test ; COURRIER DE portail.care.test ; DKIM d=portal.care.test, sélecteur demo1, réussite supposée ; propriétaire proposé Responsable des applications cliniques. Action suivante : Vérifiez le locataire exact du portail et le message contrôlé approuvé.
- Avis de laboratoire : Tiré de lab.care.test ; MAIL DE Legacy-lab.test ; DKIM d=legacy-lab.test, sélecteur demo1, réussite supposée ; propriétaire proposé Responsable de l'intégration du laboratoire. Action suivante : Confirmez la signature alignée prise en charge ; changer le nom d’affichage est insuffisant.
- Avis de facturation : provenant de billing.care.test ; MAIL DE billing.care.test ; DKIM d=billing.care.test, sélecteur demo1, réussite supposée ; propriétaire proposé Responsable du cycle de revenus. Action suivante : Testez la voie de facturation indépendante.
- Référence héritée : depuis Legacy-care.test ; MAIL DE Legacy-care.test ; DKIM d=legacy-care.test, sélecteur demo1, réussite supposée ; Propriétaire proposé Responsable des opérations de référencement. Action suivante : vérifiez les références entrantes en cours avant de retirer MX ou de recevoir l'infrastructure.
Une signature de passage supposée dont d= correspond exactement à From fournit un chemin strictement aligné pour ce message hypothétique. Un d= sans rapport ne fournit aucun chemin aligné à partir de cette signature. SPF inconnu ou d'autres signatures empêchent un verdict d'échec global dans ce dernier cas. Ces prémisses écrites n’établissent aucune configuration en direct ni placement dans la boîte de réception.
Prendre deux décisions distinctes en matière de retraite
Pour la fusion fictive M-01, supposons que les avis sortants de l'ancien domaine ont été déplacés, mais que les opérations de référence nécessitent toujours des messages entrants sur Legacy-care.test. Conserver son service de réception nécessaire ; ne publiez pas Null MX simplement parce que la migration sortante est terminée. Séparément, le déplacement des rapports vers reports.new-care.test nécessite le RFC 9990 Section 4 Autorisation DNS et autorisation organisationnelle pour partager les données de l'ancienne entité. L'autorisation DNS ne constitue pas une approbation légale ou commerciale. Si l’une ou l’autre des autorisations n’est pas vérifiée, laissez la migration du rapport en attente tout en poursuivant le travail d’inventaire autorisé. Aucun domaine, boîte aux lettres ou destination de rapport n'a été modifié.
Gardez les limites des preuves explicites
RFC 9989 Les sections 4.4 et 5.3.5 distinguent l'authentification et alignement; La section 5.4 laisse la gestion des messages à la politique du destinataire. La section 7.4 nécessite DKIM valide plutôt que SPF uniquement pour la publication de domaines p=reject et met en garde contre le rejet des domaines dont les utilisateurs publient sur des listes de diffusion Internet. Les octets canonisés couverts déterminent l’intégrité DKIM selon les sections 3.4 à 3.7 et 6.1 de RFC 6376 . Aucun des deux mécanismes ne valide l’autorité clinique, éducative ou juridique. Recueillir des preuves actuelles autorisées pour un déploiement réel ; les listes de contrôle opérationnelles présentées ici sont des recommandations et non une évaluation de la conformité spécifique à une juridiction.