eClinicalWorks support and practice-side IT support serve different parts of the same clinical workflow. The EMR vendor understands its application, supported configuration, and product-specific behavior. An IT partner manages the environment around that application, including devices, connectivity, printing, security, and any hosting responsibilities assigned to it. A practice needs both roles to be clear, especially when staff describe every interruption as “eCW is down.”
The useful question is not whether the vendor or IT provider is better. It is who owns the failing layer, who gathers evidence, and who coordinates restoration. Practices searching for eCW support or eCW hosting should begin with their exact deployment model and service agreements. A cloud subscription, a local installation, and a privately hosted environment distribute responsibilities differently even when clinicians see a familiar application.
What eClinicalWorks support covers
The vendor is the appropriate authority for supported application behavior, product defects, configuration guidance, release requirements, and proprietary data or integration procedures. The available service scope depends on the practice's products and agreement. Do not assume a particular support commitment or hosting feature applies to every customer simply because it appears in a product description.
A useful vendor ticket contains the application version, exact workflow, observed error, affected users, timing, and checks already performed. If a problem is reproducible in the application, that evidence helps the vendor distinguish a defect from an environmental issue. The practice should provide patient information only through approved support channels and only to the extent needed for the investigation.
Vendor support does not automatically manage every printer, scanner, Wi-Fi connection, endpoint, or office firewall. Even where the vendor hosts the application, local workflows still depend on equipment and connectivity. That is a boundary to plan for, not a criticism of the vendor. The EMR support hub explains how application support and healthcare infrastructure support work together.
Start by identifying the deployment model
A practice should record where its application and database operate, who administers the environment, how users connect, and which agreements cover support and recovery. Confirm the exact product version and supported arrangement with eClinicalWorks. Avoid using “cloud” as shorthand for a complete responsibility model. A system accessed over the internet can still leave significant administration with the practice or a hosting partner.
Include surrounding services: identity, interfaces, document capture, printing, remote access, backups, and clinical peripherals. Some may be vendor-hosted while others remain local. A change to one part can affect the others. An accurate architecture record allows the IT partner to investigate the environment without accidentally altering a vendor-managed service or unsupported component.
Vendor cloud: less local server work, not no IT work
In an eClinicalWorks cloud arrangement, the vendor provides the hosted application environment according to its service scope. Its published cloud model describes server maintenance and platform responsibilities that reduce the practice's need to operate local application servers. Verify the contracted backup, recovery, upgrade, access, and availability arrangements rather than translating that description into an unlimited promise.
The practice still needs dependable internet access, secure endpoints, supported browsers or access clients, user administration, printers, scanners, and appropriate security policies. A clinician cannot use a healthy hosted application from a computer with a broken network connection. Local troubleshooting should establish whether the issue affects one device, one office, or users connecting through different networks.
Ask how cloud incidents are reported and how the practice receives updates. Clarify data access and export arrangements, recovery expectations, and dependencies involving third-party interfaces. Keep clinical downtime procedures available even if server maintenance is outsourced. A hosting agreement can allocate technical duties, but it cannot replace the practice's decisions about patient care during an interruption.
Self-hosted: infrastructure belongs in the support plan
Where a practice operates a supported local eCW environment, its infrastructure team must maintain the assigned servers, operating systems, storage, network, security, and backup processes. Application-specific maintenance and upgrades should follow vendor requirements. Confirm the actual arrangement instead of applying an old installation guide to a newer product or version.
Monitor both infrastructure and application dependencies. A server can be powered on while a required service is unavailable or storage performance is inadequate. Inventory interfaces, scheduled tasks, service identities, certificates, and external connections. These dependencies should be included in backup and recovery planning so restoring the main application does not leave laboratory exchange or document workflows incomplete.
Separate responsibility for database and application changes from ordinary infrastructure maintenance. The IT provider should not perform unsupported proprietary repairs simply because it manages the server. Establish when eClinicalWorks must be involved, what access is authorized, and how changes are approved. A clear division protects both data integrity and the vendor's ability to support the environment afterward.
Private hosting: define the middle ground
A private-hosted arrangement places the practice's supported environment with a hosting partner rather than in the office. Its acceptability depends on the application's supported deployment requirements and the agreements involved. Confirm vendor approval where needed before committing. A provider offering virtual machines has not necessarily accepted responsibility for application upgrades, interfaces, monitoring, or clinical troubleshooting.
The contract should name the owner of each layer: physical infrastructure, virtualization, guest operating systems, application services, backups, identity, access security, and end-user support. Define recovery procedures and how the hosting partner coordinates with eClinicalWorks. Identify the appropriate BAA relationships for organizations maintaining or accessing ePHI. Avoid gaps where two providers each assume the other is protecting the data.
Test access from the actual offices and remote work locations. Some client and database arrangements are sensitive to network latency. A hosted desktop or another supported delivery method may be needed to keep application components appropriately located. The solution should be validated with printing, scanning, interfaces, and reconnect behavior, not only a demonstration of successful login.
Printing problems often begin outside the EMR
A failed print task can involve the selected device, local driver, print queue, operating-system permissions, network reachability, browser settings, or a remote-session redirection rule. First establish whether other applications can print and whether the problem affects one user or every workstation. Record the exact document type and printer rather than treating all printing symptoms as identical.
The IT partner normally investigates the supported local printing path and any infrastructure it manages. The vendor should address application-specific output, supported print behavior, or reproducible formatting defects. Some problems cross both layers. Coordinate the evidence rather than repeatedly reinstalling drivers while the application is sending a different output or using an unsupported configuration.
Specialized labels, forms, or clinical documents deserve representative testing after changes. A generic test page does not establish that the practice's actual output is usable. Keep privacy in mind when collecting examples and clear failed queues securely. A document containing patient information should not be left on a shared device or sent through an unapproved support channel.
Scanning and document workflows need end-to-end testing
A scanner may require a compatible driver, capture application, browser integration, or supported document-import process. The workflow also depends on where files are staged, how staff select a patient, and how documents are associated with the record. A scanner producing a PDF proves acquisition, not successful clinical filing.
IT should maintain the supported local device and storage path. eClinicalWorks should guide supported application import, document handling, and product-specific configuration. Test acquisition, selection of the correct patient, upload or import, and later retrieval. If staff must temporarily stage files, define a controlled location and cleanup process so scanned PHI does not accumulate across local desktops.
Interfaces can fail while the chart still opens
Laboratory, prescribing, billing, and other connections may have dependencies separate from the core application. An interface can rely on credentials, certificates, addresses, message routing, or third-party services. Identify which organization owns each connection and how failures become visible. The front desk seeing a normal login screen does not establish that messages are reaching the intended destination.
Infrastructure checks can establish connectivity and the health of locally managed services. Application vendors and interface partners should validate message behavior, mapping, and supported configuration. Preserve logs and avoid resending transactions without understanding duplication risks. Reconciliation belongs in the recovery process so restored connectivity does not conceal missing or repeated messages.
Slowness requires evidence, not a blanket diagnosis
Ask what is slow: login, opening a chart, saving, searching, printing, or retrieving a document. Compare affected users and locations, time of occurrence, connection methods, and recent changes. On a hosted system, local internet or device behavior may be relevant. In a self-hosted system, storage, memory, network, and required services may also need examination.
The IT partner should collect environmental measurements within its scope, while the vendor evaluates application behavior and supported requirements. Do not assume a larger server, faster internet plan, or security exclusion will fix every symptom. Change one supported variable at a time where practical and retain evidence. The result should explain the bottleneck rather than simply declare that performance improved during one test.
Migration and upgrades need a shared acceptance plan
Begin a hosting migration or material upgrade with discovery, vendor-supported destination requirements, protected backups, and a tested recovery method. Inventory documents, interfaces, printing, scanning, identities, and third-party connections. Establish who approves clinical acceptance and who can authorize rollback. Moving the database is not the same as moving the practice's complete workflow.
Use controlled testing with appropriate data protection. Validate representative clinical and administrative tasks, and prevent duplicate live messages from a test environment. Coordinate any required downtime and final synchronization with the vendor and hosting provider. Do not promise zero interruption merely because a conversion or export process is available.
After cutover, confirm backup operation, monitoring, security, user access, and interface reconciliation. Document the new environment and close temporary access paths. The eCW-specific service page connects infrastructure support with this coordination. For other platforms, the Greenway, AdvancedMD, and Kareo support guide applies the same responsibility-based approach.
Questions before choosing eCW hosting
Ask whether the proposed arrangement is supported for the exact version and workflow. Request the responsibility matrix, BAA chain, upgrade process, backup scope, restoration method, and incident escalation path. Clarify who supports printers and scanners and which third-party interfaces are included. An attractive hosting label is not a substitute for those answers.
Ask how capacity and connectivity will be validated from the actual practice, how service changes are communicated, and how data is returned if the relationship ends. Review recovery expectations and evidence of testing. The contract should explain what the practice must still manage and who coordinates with the vendor when the cause is unclear.
Keep a clinical continuity plan independent of the hosting arrangement. The EHR downtime plan guide covers staff responsibilities, controlled documentation, and reconciliation. Hosting can change the technical failure boundary, but staff still need a usable plan when access to patient records is interrupted.
Frequently asked questions
eClinicalWorks is the authority for its supported application, product behavior, and proprietary procedures within the agreement. The IT provider manages assigned infrastructure and local workflows. Printing, scanning, networking, and hosting incidents may require both teams, so establish an escalation coordinator.
No. Hosted application services still depend on secure devices, connectivity, supported access software, printers, scanners, and user processes. Confirm the vendor's contracted responsibilities and identify the local duties that remain with the practice and IT partner.
That depends on the exact product, version, supported arrangement, and agreements. Obtain appropriate vendor confirmation before committing. Define who manages infrastructure, application changes, interfaces, backups, access, and recovery rather than assuming a virtual server completes the service.
A local device, connection, access-client setting, or user configuration may be involved, but investigation is necessary. Compare workflows and a working device, record recent changes, and gather environmental evidence. Application-specific behavior may still require vendor review.
IT normally checks supported devices, drivers, connectivity, permissions, and local or hosted infrastructure within its scope. The vendor addresses supported application output and document handling. Coordinate testing through the full workflow rather than stopping at a successful device test.
Confirm vendor support, responsibility assignments, BAA relationships, backup and restoration scope, interface handling, clinical testing, cutover, and rollback. Ask how data can be returned and how downtime is communicated. Require acceptance of real workflows, not just server availability.