Test Results Not Transferring to the EMR, or Tests Running Slowly
Updated August 14, 2026 · 7 min read
What's happening
If your site connects Benson to an outside occupational health EMR, the software sends each completed hearing or spirometry test to that system automatically through a database interface. When that connection is set up correctly, this is invisible — you finish a test, save it, and it appears in the EMR without any extra step. Two symptoms usually mean this connection has broken: results stop showing up in the EMR at all even though tests are completing normally in the booth, or tests that used to take a few minutes each start taking noticeably longer, sometimes two or three times as long. Both point to the same underlying cause more often than not, so work through this guide in order rather than treating them as separate problems.
The good news is that a broken EMR connection is rarely a data-loss problem. When the interface isn't reachable, the software almost always keeps the completed test results locally rather than discarding them, and once the connection setting is corrected, those buffered results typically send through on their own or with one manual step. Losing test results outright is uncommon; the far more common outcome is that they're sitting and waiting.
Try these in order
- Confirm what database interface the software is currently set to.
- If it's set to a local database instead of the EMR interface, that's almost always the cause — reset it, following the steps below.
- Check whether previously recorded tests are sitting in a transfer buffer waiting to send.
- If tests are also running slowly, check the serial COM port setting against what Device Manager actually shows.
- If the port numbers don't match, don't just change the software's setting to match the Windows number by assumption — confirm the correspondence with IT first.
Step 1 — Check the database interface setting
The software's connection to your EMR is controlled by a setting in its startup or company configuration screen, usually a dropdown for "Database Interface" or similar wording depending on your version. When this is correctly configured, it points to your EMR's connection details rather than a local database. Open that settings screen and confirm which option is currently selected before doing anything else.
Step 2 — Why this setting resets on its own
This setting is the single most common cause of "results stopped transferring" and it's rarely a deliberate change. A software upgrade, a reinstall, or a Windows update can reset the company configuration back to its default, which is typically a local database rather than your EMR connection. From the software's point of view nothing is wrong — it's saving every test successfully — but it's saving them to a local database instead of sending them out, so the EMR never sees them. If you had an EMR interface working before a recent upgrade, reinstall, or Windows change and it's not working now, check this setting first before assuming anything is broken on the EMR side.
To correct it: open the database interface setting, select the EMR/database interface option instead of the local database option, and re-enter the connection details for your EMR if the fields are blank (the specific endpoint or connection address is something we can confirm with you if you don't have it on hand). Test the connection from within the software before saving, if that option is available in your version.
Step 3 — Recovering results recorded while the interface was misconfigured
Because the software keeps completed tests locally rather than discarding them when the interface is unreachable or misconfigured, tests run during the affected window are usually still there. Check the software's transfer buffer or equivalent queue for pending results once the interface setting is corrected — most versions will send everything queued automatically the next time a good connection is confirmed, and if not, there's typically a manual "send" action for buffered results. Verify a sample of those results actually appear in the EMR afterward rather than assuming the queue cleared successfully.
Step 4 — Slow tests and the serial COM port
If tests are running much slower than usual, especially alongside transfer problems, check the serial COM port the software is using to talk to the audiometer or spirometer. This commonly breaks after a driver reinstall or a cable swap, because reinstalling a USB-to-serial driver can renumber which COM port Windows assigns to that cable, even though physically nothing else changed.
- Open Windows Device Manager and look under Ports (COM & LPT) for the port assigned to your instrument's interface cable.
- Open the software's own port setting (in its instrument or connection configuration) and compare it against what Device Manager shows.
- If they don't match, don't just change the software's setting to whatever number Device Manager shows and assume that's correct. Some versions of the software index or label ports differently than Windows does, so a software "Port 2" is not guaranteed to mean the same thing as Windows "COM2." Have your IT team confirm which physical Windows COM port corresponds to which port setting in the software before changing anything, rather than matching the numbers by assumption.
- Once IT has confirmed the correct correspondence, update the software's port setting to match and restart the software.
When to involve IT versus us
- IT: confirming which Windows COM port corresponds to which software port setting, checking whether a driver reinstall or Windows update happened recently, and network-level connectivity to the EMR (firewall, VPN, or endpoint reachability).
- Us: confirming what the database interface setting should be for your EMR, providing the correct connection details if they're missing, and help recovering buffered results that aren't sending through on their own.
When to call us
- You've confirmed the database interface setting matches your EMR configuration and results still aren't transferring.
- Buffered results aren't clearing after the interface setting is corrected.
- You're not sure whether a COM port mismatch is the cause, or IT has confirmed the ports but tests are still slow.
- You suspect any test results were actually lost rather than buffered — this is uncommon, and worth confirming with us directly rather than assuming the worst.
Call (513) 891-0868 or email service@fosterinstruments.com with what the database interface setting currently shows and whether this started after an upgrade, reinstall, or Windows change — that context speeds things up considerably.
Also search for
Still stuck?
If this didn't fix it, or the next step involves opening the case, recalibration, or anything that could affect accuracy — stop and call Foster. We'll get you sorted or schedule service.