Updating to Diagram that shows vs Screenshot of

Author: msjasteppe

articles/healthcare-apis/azure-api-for-fhir/disaster-recovery.md

@@ -33,29 +33,29 @@ By default, Azure API for FHIR offers data protection through backup and restore
 
 It's worth noting that the throughput RU/s must have the same values in the primary and secondary regions.
 
-[![Screenshot of Azure Traffic Manager.](media/disaster-recovery/azure-traffic-manager.png)](media/disaster-recovery/azure-traffic-manager.png#lightbox)
+[![Diagram that shows Azure Traffic Manager.](media/disaster-recovery/azure-traffic-manager.png)](media/disaster-recovery/azure-traffic-manager.png#lightbox)
 
 ### Automatic failover
 
 During a primary region outage, the Azure API for FHIR automatically fails over to the secondary region and the same service endpoint is used. The service is expected to resume in one hour or less, and potential data loss is up to 15 minutes' worth of data. Other configuration changes may be required. For more information, see [Configuration changes in DR](#configuration-changes-in-dr).
 
-[![Screenshot of failover in disaster recovery.](media/disaster-recovery/failover-in-disaster-recovery.png)](media/disaster-recovery/failover-in-disaster-recovery.png#lightbox)
+[![Diagram that shows failover in disaster recovery.](media/disaster-recovery/failover-in-disaster-recovery.png)](media/disaster-recovery/failover-in-disaster-recovery.png#lightbox)
 
 ### Affected region recovery
 
 After the affected region recovers, it's automatically available as a secondary region and data replication restarts. You can start the data recovery process or wait until the failback step is completed.
 
-[![Screenshot of replication in disaster recovery.](media/disaster-recovery/replication-in-disaster-recovery.png)](media/disaster-recovery/replication-in-disaster-recovery.png#lightbox)
+[![Diagram that shows replication in disaster recovery.](media/disaster-recovery/replication-in-disaster-recovery.png)](media/disaster-recovery/replication-in-disaster-recovery.png#lightbox)
 
 When the compute has failed back to the recovered region and the data hasn't, there may be potential network latencies. The main reason is that the compute and the data are in two different regions. The network latencies should disappear automatically as soon as the data fails back to the recovered region through a manual trigger.
 
-[![Screenshot of network latency.](media/disaster-recovery/network-latency.png)](media/disaster-recovery/network-latency.png#lightbox)
+[![Diagram that shows network latency.](media/disaster-recovery/network-latency.png)](media/disaster-recovery/network-latency.png#lightbox)
 
 ### Manual failback
 
 The compute fails back automatically to the recovered region. The data is switched back to the recovered region manually by the Microsoft support team using the script. 
 
-[![Screenshot of failback in disaster recovery.](media/disaster-recovery/failback-in-disaster-recovery.png)](media/disaster-recovery/failback-in-disaster-recovery.png#lightbox)
+[![Diagram that shows failback in disaster recovery.](media/disaster-recovery/failback-in-disaster-recovery.png)](media/disaster-recovery/failback-in-disaster-recovery.png#lightbox)
 
 ## Configuration changes in DR