Una fusión de hospitales no mueve todas las dependencias de correo electrónico cuando cambia el directorio o el sitio web público. Un servicio de laboratorio heredado aún puede firmar con su dominio anterior, un portal de pacientes puede usar un inquilino separado y los mensajes de referencia pueden llegar a direcciones que el nuevo equipo de marca considera obsoletas. Comience con la continuidad de estos servicios, no con una política de objetivos únicos para la marca combinada.
Construir un libro de ruta de fusión
Enumere cada dominio adquirido con su controlador legal, administrador DNS , propietario de la aplicación, propósito de envío y propósito de recepción. Luego, mapee el portal del paciente, el aviso de laboratorio, el aviso de facturación y el servicio de referencia heredado por separado. Incluir el antiguo camino de regreso, firmando selector, informe el destino y el equipo autorizado a cambiar cada uno. Una persona capaz de administrar el nuevo inquilino del hospital puede no tener autoridad sobre el inquilino proveedor del laboratorio.
Utilice pacientes de prueba y referencias de citas inventadas. Un mensaje que diga que el resultado está listo puede validar la ruta sin incluir contenido clínico. Pídale al líder de integración del laboratorio que le explique dónde se crea el mensaje, qué relé lo firma y si una puerta de enlace lo modifica. Haga que las operaciones de referencia confirmen que las direcciones entrantes antiguas aún funcionan antes de retirar cualquier infraestructura de recepción.
Distinguir el cambio de marca de la autenticación
El estado trabajado proporciona a los avisos de laboratorio un De visible de lab.care.test pero un firmante de Legacy-lab.test. Su firma está estipulada para ser aprobada pero tiene un dominio de firma no relacionado; Esta es una premisa escrita, no un resultado de verificación. Cambiar solo un nombre para mostrar no solucionaría esa discrepancia. Seleccione una identidad de envío aprobada y compatible con el servicio, configure el dominio de firma relevante y pruebe la nueva ruta antes de cambiar la marca orientada al destinatario.
Mover la propiedad del informe explícitamente. Inventario que recibe actualmente informes agregados, quién puede acceder al servicio de procesamiento y si la organización fusionada está autorizada para recibir los datos de la antigua entidad. Verifique la autorización de destino del informe externo cuando corresponda. Preservar una línea de base fechada para que los cambios en la participación en los informes no se confundan con los cambios en el volumen de comunicación con los pacientes.
Retire los dominios heredados con cautela
Un dominio puede dejar de enviar mientras sigue recibiendo referencias o respuestas. RFC 7505 define Null MX , que anuncia que el dominio no acepta correo; no es un interruptor anti-spoofing y no es apropiado para una ruta entrante que aún es necesaria. Mantenga separadas las restricciones del remitente y las decisiones de recepción. Solicite a cada propietario responsable que apruebe el retiro y conserve una ruta documentada para restaurar la última configuración aprobada si se omitió un servicio crítico.
No trate un inventario de fusión como evidencia de cumplimiento de la atención médica. Las reglas de privacidad, contratación y retención que rigen a cada entidad y sus procesadores requieren una revisión calificada. Este ejercicio utiliza dominios ficticios y no datos de pacientes; no toma ninguna determinación sobre HIPAA , la ley de salud local o las consecuencias legales de transferir un servicio de informes.
Inspeccionar el libro de ruta escrito.
Todas las filas utilizan dominios ficticios reservados, propietarios propuestos y estipulados. DKIM resultados. El selector demo1 es una etiqueta ilustrativa, no una clave instalada. SPF Se desconocen los resultados, otras firmas, el descubrimiento de políticas DNS , la recepción real y el éxito de la aplicación. No se proporcionan claves, mensajes firmados, ejecución de pruebas ni pruebas de entrega.
- Portal del paciente: desde portal.care.test; CORREO DE portal.care.prueba; DKIM d=portal.care.test, selector demo1, aprobado asumido; propietario propuesto Líder de aplicaciones clínicas. Siguiente acción: Verifique el inquilino del portal exacto y el mensaje controlado aprobado.
- Aviso de laboratorio: De lab.care.test; CORREO DESDE Legacy-lab.test; DKIM d=legacy-lab.test, selector demo1, aprobado asumido; Propietario propuesto Líder de integración del laboratorio. Siguiente acción: Confirmar la firma alineada admitida; cambiar el nombre para mostrar no es suficiente.
- Aviso de facturación: De billing.care.test; CORREO DE billing.care.test; DKIM d=billing.care.test, selector demo1, aprobado asumido; propietario propuesto Líder del ciclo de ingresos. Siguiente acción: Probar la ruta de facturación independiente.
- Referencia heredada: de Legacy-care.test; CORREO DESDE Legacy-care.test; DKIM d=legacy-care.test, selector demo1, aprobado asumido; Propietario propuesto Líder de operaciones de referencia. Siguiente acción: Verifique las referencias entrantes en curso antes de retirar MX o recibir infraestructura.
Una firma de paso supuesta cuyo d= coincide exactamente con From proporciona una ruta estrictamente alineada para ese mensaje hipotético. Un d= no relacionado no proporciona una ruta alineada desde esa firma. SPF desconocido u otras firmas impiden un veredicto de fracaso general en este último caso. Estas premisas escritas no establecen ninguna configuración en vivo ni ubicación en la bandeja de entrada.
Tome dos decisiones de jubilación por separado
Para la fusión ficticia M-01, supongamos que los avisos salientes del dominio anterior se han movido pero las operaciones de referencia aún requieren mensajes entrantes en Legacy-care.test. Mantener su necesario servicio de recepción; no publique Null MX simplemente porque finalizó la migración saliente. Por otra parte, mover informes a informes.new-care.test necesita las normas aplicables RFC 9990 Sección 4 Autorización DNS y permiso organizacional para compartir los datos de la antigua entidad. La autorización DNS no es una aprobación legal ni comercial. Si alguno de los permisos no está verificado, deje pendiente la migración del informe mientras continúa con el trabajo de inventario permitido. No se cambió ningún dominio, buzón o destino del informe.
Mantenga explícitos los límites de la evidencia
RFC 9989 Las secciones 4.4 y 5.3.5 distinguen la autenticación y alineación; La sección 5.4 deja el manejo de mensajes a la política del receptor. La sección 7.4 requiere DKIM válido en lugar de SPF solo para la publicación de dominios p=reject y advierte contra el rechazo de dominios cuyos usuarios publican en listas de correo de Internet. Los bytes canonicalizados cubiertos determinan la integridad DKIM según RFC 6376 secciones 3.4–3.7 y 6.1. Ninguno de los mecanismos valida la autoridad clínica, educativa o legal. Recopilar evidencia actual autorizada para un despliegue real; Las listas de verificación operativas aquí son recomendaciones, no una evaluación de cumplimiento específica de la jurisdicción.