Be aware that, in this type of situation, it is not possible (or maybe extremely time consuming) to be 100% sure that one reliably blocks all accesseses at all times. For example, a program that sees it is blocked from accessing its main server, can decide to fall back to another location or protocol either immediately or after a random delay. That is what makes detecting real life sophisticated data ex-filtration extremely hard and what makes blocking services with multiple fallback options (think MS Messenger in its days) such a chore for system administrators.
An eventual software update, server name or IP address change could of course also go around any measure you have implemented at any given moment in time. If Abbott decided to implement steganography to get at your data, there is very little you could do to prevent them from doing so unless you want to reverse-engineer their software and spend a lot of time on it.
Lastly, if Abbott wants to force you to connect before starting or using their software reporting, you would have no choice but to patch their program.
This being said, here is what I have confirmed to work with the initial release.
Firewall block at the local level on Windows 8.x
You'll want to go to Windows Firewall with Advanced Security (for example by typing "firewall" in the search box and then selecting the advanced option).
You'll create a TCP rule, not bothering about specific ports as you probably don't want to be in touch with that server anyway.
Firewall block at the router level
The above block will of course only work on the machine where it is active. It will not block other computers that you might use. If you are using multiple computers, you may want to block the address at your router firewall level as in the example below. Again, this does not prevent the connection of the reader to the computer and the local download/export of results but it blocks its connection attempts. This time wireshark will show repeated failed connection attempts from your computer to the Abbott Research Center server.
It is also possible to use whatever anti-virus security suite you happen to be using, or even that advanced options of the Windows firewall to prevent a specific application from having Internet access. This is "solution specific" and can't be explained.
At the moment, the process to monitor is the service Abbott installs on your computer. Note: when your reader stops being detected, this is often because that service has stopped. Restarting it will usually restore the connection to your reader.
Other options such as DNS intervention, host files, routing modifications are of course possible, but I have found some of them to be somewhat unreliable after the reader had already connected once. This could simply be because of caching issues or the logic of the Abbott connection process. So many possibilities that aren't necessarily worth investigating.