emis web system support — 5 fixes to try before you call

EMIS Web failing to load or throwing authentication errors stops clinical and admin work instantly. Practices regularly blame the internet when the root cause is a local workstation, an expired certificate, or an interface queue. Run these five focused checks in order and you’ll resolve most incidents without a support ticket.

Fix 1 — Single workstation login failure: confirm if it’s the PC, not EMIS

Problem: One user can’t log in, but colleagues can. That usually means the problem lives on the workstation, not in the EMIS Web servers.

Diagnosis: Try an alternate machine or ask the user to open EMIS Web in a different browser or an incognito/private window. If the alternate machine works, clear the browser cache and saved credentials on the failing PC. Check the computer’s date and time; SSL connections fail if the clock is wrong. Also test a local network drop by plugging into another network socket or using mobile tethering for a quick confirmation.

Recommended action: Reboot the workstation, remove any stale saved credentials (Windows Credential Manager), update the browser, and attempt login again. If the issue persists only for that account, reset the user’s password or check their Active Directory account state with your IT administrator.

Fix 2 — Certificate or HTTPS errors: address security warnings immediately

Problem: The browser shows “connection is not private”, certificate warnings, or the site loads but behaves oddly after a recent update. Those are classic SSL certificate or trust-chain failures.

Diagnosis: Click the padlock in the browser’s address bar and view the certificate details: is it expired, issued to a different host, or signed by an unknown authority? If many users see the same error at once, it’s likely a server-side or hosting cert problem; if it’s a single site it may be a proxy or a cached CA bundle on the client.

Recommended action: If clocks are wrong on endpoints, sync them to an NTP server and retry. For expired certificates or host-name mismatches, contact your hosting or EMIS provider so they can renew or reissue the certificate. If you see a security warning you don’t understand, follow NCSC’s guidance on IT incidents before bypassing warnings; don’t advise staff to proceed past a clear security alert.

Fix 3 — Interface queues and third‑party integrations: unblock stuck messages

Problem: Labs, prescriptions or messaging features are queuing or failing, even though users can access the main EMIS Web screens. The clinical system looks “up” but workflows are disrupted.

Diagnosis: Check integration or interface logs if you have access. Look for repeated connection timeouts or authentication failures to third-party endpoints (lab suppliers, spine, or local pathology systems). Often an upstream vendor change, expired integration certificate or a misconfigured service account will stop message exchange while leaving the main portal available.

Recommended action: Restart the specific integration service or connector (don’t restart the whole server unless necessary). If you can’t clear queue errors, gather the error codes and timestamps and contact the third‑party supplier or EMIS support with those details—this is the information they need to act quickly.

Fix 4 — Local network, DNS or proxy blocking EMIS endpoints

Problem: EMIS Web loads intermittently, or some functionality is missing for all users. That often points to a network rule, DNS problem or proxy that’s blocking specific domains or ports.

Diagnosis: Test connectivity from within the network: ping the EMIS hostname, run a traceroute, and try resolving the domain from another machine. Disable any HTTP proxy temporarily or bypass firewall rules to see if behaviour changes. If mobile tethering fixes the issue, your router, DNS or ISP likely needs attention.

Recommended action: Flush local DNS caches (ipconfig /flushdns on Windows), reboot gateway appliances, and check with your ISP for recent route changes. If you use a corporate proxy or content filter, confirm that the EMIS Web IP ranges and hostnames are whitelisted. If you don’t manage these devices in-house, gather the network test results and hand them to whoever does.

Fix 5 — Persistent outage after checks: collect evidence, then escalate with the right data

Problem: You’ve tried the local fixes and EMIS Web still won’t behave. Blindly phoning support wastes time unless you bring the right evidence.

Diagnosis: Identify scope (one user, a team, or everyone), exact error messages, timestamps, and recent changes (patches, power cycles, new hardware or vendor changes). Check whether the problem started after a scheduled update or an external event such as an ISP incident.

Recommended action: Gather screenshots of errors, export any relevant logs, note the number of affected users and the precise time the fault began. Then raise the ticket with EMIS Web support or your managed provider—include the gathered evidence. If you need specialist help, consult the practice’s healthcare IT support page for third‑line escalation and forensic collection advice; using a provider who can present logs and timelines reduces downtime and phone-tag.

Do this now: run the workstation, certificate, interface, network checks in that order and collect error screenshots before contacting external support. Quick facts on what to bring: affected usernames, exact error text, time window, and whether the issue is local or practice‑wide. That removes guesswork from the first call and often halves resolution time.

Short-term wins save money and credibility. Fix the obvious items locally, then hand clear evidence to support if the outage persists. A tidy set of facts gets you back to clinical work faster, with less cost and fewer frustrated staff.