Open Dental eConnector: A Continuity Checklist

Open Dental instructs practices to install the eConnector on one machine, typically the server. Its documentation describes a workstation alternative when the server platform is not suitable, with additional configuration that may require technical support. The host must stay on and awake for eServices to work. Recheck the current vendor instructions before moving or reinstalling it.

Record the actual computer name, location, service identity, responsible administrator, and support contact in the practice's system map. Ask whether shutdown or sleep habits could interrupt it. Do not label a front-desk computer as disposable until you know which background services it runs. If the current host is being replaced, include that dependency in the project plan before removing the old machine.

Describe the affected business task: a portal interaction, scheduling function, communication workflow, or another eService the practice actually uses. Record when it stopped working and whether the problem affects one user, one feature, or the whole office. Separate a failure in a local application from a failure in the online workflow. These are proposed support observations, not a diagnosis.

Provide the host name, recent maintenance, displayed service status, and the exact error message through the approved support route. Use synthetic examples when demonstrating the issue so screenshots do not expose patient data. Avoid collecting database passwords or full patient records in an ordinary ticket. A focused description lets the IT provider and vendor decide which layer to investigate without guessing from a generic report that the software is down.

The vendor's eConnector window reports status, which is an important technical observation. For acceptance, add a separate check of the approved business workflow. A process that is running on the host does not by itself prove the practice can complete every dependent task. Ask the vendor which test is appropriate for the installed configuration and use an authorized test account or supported nonpatient example.

Write the acceptance result in business terms: the authorized user completed the intended action, the expected destination received it, and the responsible staff reviewed any delayed work. Do not send real reminders or create real appointments just to test an integration without authorization. If a test creates a side effect, agree on its scope and cleanup first. Mark partial recovery clearly so staff know which functions remain unavailable.

Before a host reboot, replacement, network change, or Open Dental update, identify the affected eServices and notify the business owner. Ask the vendor about the supported installation and update process for the current environment. Create a pre-change note with the starting service status, approved window, recovery contact, and the workflow test required before the practice resumes normal use.

Coordinate power and availability settings as part of that review. A staff workstation used as a service host needs a different operational plan from a laptop that is routinely closed at the end of the day. Avoid making a universal hardware or service-account recommendation from a generic checklist. Confirm what the vendor supports and document the practice's chosen arrangement, including who responds when the host is unavailable.

Use the current vendor's ports and troubleshooting guidance for the specific deployment. A connector issue is not a reason to disable the firewall, expose the database, or create an unrestricted exception for the whole network. Record any authorized rule change, its business purpose, and the verification result. Keep the ability to return to the approved baseline.

If the problem follows a network or security change, give both support parties the change record so they can compare the expected path with the actual behavior. Preserve a distinction between host availability, service status, network connectivity, vendor availability, and application-level errors. The practice should not need to choose a technical explanation from a vague symptom; the support process should gather evidence and identify the responsible layer.

Prepare a concise package with the practice's authorized support contact, installed software context, connector host, error text, relevant timestamps, and steps already taken. Include the expected workflow and the actual result. If Open Dental requests logs, use the vendor-approved transfer method and review them for sensitive information rather than attaching everything to a broad internal message.

Identify who can approve a restart, reinstall, configuration change, or update, and when those actions can occur. Keep a record of vendor instructions and the person who performed them. A request for administrative access should go through the practice's approved access procedure. Dental IT supports the surrounding host, network, and availability issues while coordinating application-specific repairs with Open Dental.

Repeat the agreed acceptance tests and confirm the affected staff can use the restored workflows. Review queued or delayed tasks with the business owner rather than assuming all activity resumed automatically. Record what was repaired, what remains uncertain, and whether follow-up monitoring or a planned replacement is needed.

Update the system map if the connector host, owner, or configuration changed. A completed ticket should leave the next technician with a clear starting point, not just a note that it works now. Include the eConnector dependency in future workstation retirement and server projects. This modest documentation step makes continuity planning specific to the practice's actual online services without inventing a recovery-time promise.

Keep a short handoff sheet with the host name, service owner, dependent eServices, vendor contact, approved maintenance window, starting status, and acceptance test. Include where authorized support can obtain configuration details without placing credentials on the sheet. Ask staff to identify the business task that would fail if the host were unavailable, so the sheet connects infrastructure with office operations.

Test the handoff using a fictional scenario in which the host is scheduled for replacement. The project owner should locate the connector dependency before equipment is removed and arrange vendor coordination where needed. The support team should name the post-change test and the person who accepts its result. Record unresolved questions as project prerequisites rather than assuming the installation will transfer with the rest of the workstation.