Sage Intergy 6.10 Architecture Guide

Transcription

1

2 Reference Confidential This document and the information it contains are the confidential information of Sage. Neither this document nor the information it contains may be disclosed to any third party or reproduced, in whole or in part, without the express prior written consent of Sage Software Healthcare, LLC. Sage reserves the right to change, without notice, product offerings, product specifications and the information in this document. This document supersedes any prior document containing similar subject matter with regard to the descriptions of features and functionality of product offerings. You may receive supplements to this document based on changes that may occur in the product. This document may not be reproduced in any form without prior written permission from Sage Sage Software Healthcare, LLC. All rights reserved. Sage, Sage logos, and Intergy are registered trademarks or trademarks of Sage Software Healthcare, LLC or its affiliated entities. All other trademarks are the property of their respective owners. MSO # /24/2010 For more information about Sage Software Healthcare, LLC, please contact us on the Web at If you have any feedback on this document, or would like to request changes, please send an to sshd-documentationfeedback@sage.com. In your message, please include the title and date of the document (listed above) as well as any other information you feel will help with your suggestion West Boy Scout Boulevard, Suite 800 Tampa, FL Phone:

3 Table of Contents Sage Intergy 6.10 Architecture Guide How to use this document Abstract Application Workflow Sage Intergy Desktop Sage Intergy EHR Client Scalability Physical Application Workflow Client Connectivity Options Standard Sage Intergy Client Sage Intergy Terminal Services Client Sage Intergy EHR Clients Peripheral Devices Standard Server Installation Options Sage Intergy Imaging Server Sage Intergy Terminal Server Sage Practice Analytics Server Standalone AppServer Virtual Server Installation Architecture Software Compatibility and System Requirements Virtual Server Best Practices Virtualization Performance Considerations Sage Intergy Service Options Stand Alone Remote Print Server Report Server for WAN clients Stand Alone Medcin Server Standalone Document Delivery Server Practice Portal Broker Server Sage Sage Intergy 6.10 Architecture Guide i

4 Sage Intergy 6.10 Architecture Guide Sage Intergy is the premier practice management software for medical offices of all sizes. A powerful database and an intuitive user interface are combined to increase the efficiency of daily health care services. When implemented in a medical computing environment, Sage Intergy 6.10 may be installed in many different configurations. Some installations use only one server and a small number of simple client workstations. Other installations use several servers, and many different types of client workstations distributed over a wide geographic area. This document describes the different configurations of Sage Intergy and how each component is connected. This document is intended for use by Sage customers to determine what hardware and software is needed to implement or upgrade Sage Intergy 6.10 in their computing environment. As always, the components and services in this document are subject to further revision based on individual customer site requirements. How to use this document A Sage Intergy environment may be composed of many interconnected components, and not all systems and peripherals described in this document may be in use in your environment. Sage customers and Sage technicians should use this document to determine how best to install or upgrade a Sage Intergy implementation. Carefully consider the requirements and needs of the Sage customer site, and evaluate the costs and benefits of installing specific components. Sage Sage Intergy 6.10 Architecture Guide 1

5 Abstract Application Workflow The following components are present in a standard implementation of the Sage Intergy application: Sage Intergy Client Sage Intergy EHR Client AppServer Java Dispatch Framework (JDF) Progress Database Imaging Understanding how these components are installed will help Sage customers and Sage technicians determine the number and types of server devices that must be installed. Like all client/server applications, the Sage Intergy client and the Sage Intergy database server components operate as separate programs. In general, the client program does not perform database operations directly, and the server programs do not provide a user interface or other interactive services. Both the client and the server may be further divided into separate components. Operation of client programs for the Sage Intergy desktop and the Sage Intergy EHR client is slightly different. This application workflow follows these numbered steps: Sage Intergy Desktop 1. The Sage Intergy client application initiates a connection to the AppServer. 2. The AppServer processes client requests for data and routes them to the Sage Intergy database as required. 3. The Sage Intergy database responds to queries and returns data to the AppServer, which delivers this response back to the Sage Intergy client. For some functions, a direct connection between the Sage Intergy client and database may now be established. 2 Sage Intergy 6.10 Architecture Guide Sage

6 4. The Imaging system responds to queries and returns the location of a binary file to the Sage Intergy client. The Sage Intergy client then retrieves the binary file using this response and processes it for display. Sage Intergy EHR Client 1. The Sage Intergy EHR client application initiates a connection to the Java Dispatch Framework (JDF). 2. The JDF initiates a connection to the AppServer. 3. The AppServer processes client requests for data and routes them to the Sage Intergy database as required. 4. The Sage Intergy database responds to queries and returns data to the AppServer, which delivers this response back to the JDF and the Sage Intergy EHR client. 5. The Imaging system responds to queries and returns the location of a binary file to the Sage Intergy EHR client. The Sage Intergy EHR client then retrieves the binary file using this response and processes it for display. Note that for both types of clients, after authentication and requests have occurred through the AppServer, client programs may access the Sage Intergy database and the Imaging system directly. Scalability The Sage Intergy system is scalable and can support a medical computing environment of almost any size. Some Sage Intergy installations support only one doctor with one medical practice. Slightly larger systems may support a single practice with multiple doctors. The largest systems may accommodate multiple practices, each with several doctors. In the smallest Sage Intergy systems, all server components are consolidated onto one server device for the most cost-effective solution. As Sage Intergy installations grow, some of the functions of the Sage Intergy server may be installed on other servers to meet the performance and storage needs of a site with more patients to see and more records to track. Installing these components on separate servers may be required for sites with specific computing requirements as well. For example, Sage customer sites with radiology functions may require the Document Delivery Server (DDS) system to be installed on a separate server. In customer sites where more than 350 users will be connected at the same time, multiple AppServer components may be installed on several servers. This type of server is known as a Standalone AppServer, and is installed to distribute client application requests over several servers to maximize database performance. When Standalone AppServer devices are installed, the Sage Intergy installation is described as an N-tier environment, due to the multiple tiers of servers that are present. Sage Sage Intergy 6.10 Architecture Guide 3

7 Physical Application Workflow In a typical Sage Intergy implementation, client components are installed on Windows desktop workstations and all server components are installed on a single server device. However, in N-tier environments each stand alone AppServer device will have its own appserver and JDF process installed. Typically, only one database server is installed in any Sage Intergy environment, no matter how many appservers are implemented. All Sage Intergy application functions use TCP/IP network connectivity for client/server connections and any database query activity. This is true whether or not the appserver and the database are installed on the same hardware. Refer to the following chart for information on the network ports required for connectivity between different Sage Intergy services and applications. Note that all listed values are TCP port numbers unless otherwise specified. Table 1: Network port connectivity for Sage Intergy application functions Sage Intergy Client Sage Intergy EHR Client Appserver JDF Progress Database Imaging Progress Nameserver Sage Intergy Client N/A N/A 3070, 3080, 3081, 3082, N/A , (UDP) Sage Intergy EHR Client N/A N/A N/A 60001, N/A N/A Appserver 3070, 3080, 3081, 3082, N/A N/A , N/A N/A JDF N/A 60001, N/A N/A N/A N/A Progress Database , N/A , N/A N/A N/A N/A Imaging N/A N/A N/A N/A N/A Progress Nameserver 5162 (UDP) N/A N/A N/A N/A N/A N/A Note also the following TCP port usage for Internet connections: Practice Portal uses TCP port 2443 and initiates a connection between the Sage Intergy database server and a server on the Internet. Eligibility verification application services use TCP port 6861 and 6881 and initiate a connection between a Sage Intergy client workstation and a server on the Internet. When installing a new Sage Intergy site, or when troubleshooting an existing one, TCP and UDP network connectivity should be evaluated to determine if specific services or application functions are blocked. TCP/IP port blocking or filtering between different LAN switches or VLAN segments may affect the functionality of distributed Sage Intergy application functions. 4 Sage Intergy 6.10 Architecture Guide Sage

8 Client Connectivity Options In any Sage Intergy implementation, many different client components can be installed using several different hardware configurations. Some implementations require specialized hardware, network connectivity, or additional third-party components to be installed. The various possible client installation for Sage Intergy is described in this section. For Sage Intergy versions 3.50 and higher, the following client configuration options are available: Standard Sage Intergy Client Most Sage Intergy installations will include standard Sage Intergy client workstations. These workstations are desktop computers that are located on the same local area network (LAN) as the Sage Intergy database server and can have the full client application installed on the local hard drive. This type of client workstation also typically includes the Sage Intergy EHR client program. Some environments that do not use Sage Intergy EHR functions may not have the Sage Intergy EHR client installed. Sage Intergy Terminal Services Client To support the operation of thin clients and hosted solutions, workstations that operate the Microsoft Remote Desktop Client (RDC) program may access a published desktop that includes Sage Intergy client components. In the case of the Sage Intergy Appliance, Sage Intergy On Demand (IOD), or Sage Intergy 6.00 and higher, a Terminal Services client is available as a default connection option. This type of workstation may be connected to the same LAN as the Sage Intergy database server, or to the public Internet in the case of IOD. Terminal Services client computers have system requirements that differ from the standard Sage Intergy client workstation. Refer to the Sage Intergy system requirements document for the version that you are installing. Sage Sage Intergy 6.10 Architecture Guide 5

9 Sage Intergy EHR Clients Peripheral Devices The Sage Intergy EHR client program is separate from the Sage Intergy client application. This application is installed separate to support clinical functions only, for users who may not require the other functions of the main Sage Intergy client. In some cases, Sage Intergy EHR client computers may be installed outside of the customer computing environment. Usually, this will be a computer in another office that is connected to the Internet. This type of workstation is known as a Sage Intergy EHR WAN Client. One possible implementation of this type of workstation is the installation of the Sage Intergy EHR client program on a physician s home computer. Sage Intergy EHR client applications are also available for compatible portable computing devices. A Sage Intergy EHR Tablet device operates the full Sage Intergy EHR client on a computer with a touch screen and special input devices. The Sage Intergy EHR PDA is a Windows CE or Windows Mobile device that allows specific clinical functions in a handheld form factor. Portable computing devices used with Sage Intergy EHR may be installed on the same LAN as the Sage Intergy database server, or may be connected to the public Internet instead. When Sage Intergy EHR client devices are connected to the public Internet for WAN connectivity, additional registration with the Sage Remote Management System (RMS) is required for security and authorization. Some customer environments are known as Sage Intergy EHR Administration or Stand Alone Sage Intergy EHR installations. This is when the EHR clinical records product is installed to support a different practice management system other than Sage Intergy. In these cases, client computers will have only the Sage Intergy EHR client program installed. Typically, these workstations are installed on the same LAN as the Sage Intergy database server. Most Sage Intergy implementations will include scanners and printers. Scanning devices are used to record external documents into the imaging system. Printers are used for reporting purposes, to print receipts and labels, and to provide other hardcopy output. In a standard installation of Sage Intergy, scanners are connected directly to workstation computers using TWAIN drivers, and printers are installed as network devices. Note that when installing scanners in an environment where Terminal Services is implemented, additional software is required to support correct operation. Sage has certified the Remote Scan product as the approved program for imaging functions where a scanner is installed on a Sage Intergy Terminal Services client. When installing a printer in a Terminal Services environment, a default printer must be defined in the host operating system of the client computer. The Remote Desktop session defined for each Terminal Services client is already configured to print to the default printer. In some cases, additional printer drivers may need to be installed on the Sage Intergy database server or the Terminal Server to support some printer functions. 6 Sage Intergy 6.10 Architecture Guide Sage

10 Standard Server Installation Options Many Sage Intergy implementations will include multiple servers. Depending on the original version that was installed, and the number of users that must be supported, it may be necessary to split some core functions of the Sage Intergy database server into separate devices. This section describes the standard options available for all installations of Sage Intergy when more than one server is required. For a description of separate servers for Sage Intergy services, refer to the Sage Intergy Service Options section beginning on page 9. Sage Intergy Imaging Server By default, the Sage Intergy Storage Server (ISS) is installed directly on the Sage Intergy database server. This program is a separate database product used for storage of images and other large binary data associated with practice management and clinical records. To accommodate specific implementation requirements, ISS may be installed on a separate server. Also, in Sage Intergy versions 5.50 and older, the FileX imaging server product may be installed instead. Connectivity between the Sage Intergy client and a separate Imaging server must be configured using the Sage Intergy System Administration tool. Note that a separate Imaging server device must be located on the same local area network (LAN) as the Sage Intergy database server. As a best practice, both devices should operate on the same network segment. Sage Intergy Terminal Server For Sage Intergy 6.00 and higher, Microsoft Windows Terminal Services is installed by default on the Sage Intergy database server. However, this configuration does not support more than forty concurrent Remote Desktop connections. For customer sites where more than forty Sage Sage Intergy 6.10 Architecture Guide 7

11 terminal services clients must be installed, or where Sage Intergy 5.50 or older is installed, a separate Terminal Server is required. Sage Practice Analytics Server In a typical installation, Sage Intergy 6.10 and higher includes a separate server to operate Sage Practice Analytics. By default, all new installations of Sage Intergy 6.10 include Sage Practice Analytics Quality Measures Edition (QME) to support the meaningful use functions of the EHR product. When purchased separately, the full edition of Sage Practice Analytics is also deployed on a separate server to replace the QME edition of the product. In any configuration, Sage Practice Analytics operates a Microsoft SQL Server database and a requires a separate client application for operation. This database may not be installed on any server that is already operating a Sage Intergy program component. Standalone AppServer In a typical installation, a Sage Intergy database server may support up to 350 standard clients. This limitation applies to all versions of Sage Intergy. To accommodate connections from a number of clients greater than 350, additional AppServer application components must be deployed in the customer site on separate hardware. These AppServer components are intended to manage large numbers of client connection requests and distribute the load of database queries across multiple servers. This type of Sage Intergy implementation is known as an N-tier installation. Standalone AppServer devices require special configuration and database parameter settings for effective load balancing of client connections. 8 Sage Intergy 6.10 Architecture Guide Sage

12 Virtual Server Installation Architecture For Sage Intergy 6.00 and higher, one or more Sage Intergy server components may be installed as on a virtual server. In this type of configuration, virtual servers are said to be guest systems that operate as software only, and are executed on a physical server known as the host system. In a virtual server implementation, hardware components such as the CPU, memory, and network interface are emulated in software. The advantages of implementing a virtual server are the ability to operate multiple virtual servers on a single host device, and the ability to move a virtual server to a backup device or to another host system. Depending on the type of host system that has been implemented, it may be possible to use advanced load-balancing and system tools to manage the operation and reliability of the virtual server in ways that are not possible with physical hardware. However, the performance of a virtual server generally requires more storage, CPU, and memory capacity in the host system than would be required for a single physical machine. These capabilities and restrictions are described in detail in this section. Software Compatibility and System Requirements Sage Research and Development has tested and certified the use of VMWare ESX versions 3.x and 4.x for use with Sage Intergy 6.00 and higher. When implementing a virtual server for use as any part of a Sage Intergy environment, the CPU, memory, storage, and other virtual components must match or exceed the system requirements required for the same type of physical server device. Refer to the Sage Intergy 6.10 System Requirements document for detailed information on the specifications needed for physical Sage Intergy server components, and for specific information on configuration requirements for virtual servers. Sage Sage Intergy 6.10 Architecture Guide 9

13 Virtual Server Best Practices Implementation of a virtual server to operate any portion of a Sage Intergy installation requires a configuration that matches or exceeds the specifications for a physical server, as specified in the Sage Intergy system requirements. CPU resource usage and network communication capabilities must be unrestrained and not subject to any restrictions that would not also be present in a physical server device. In addition to the specific configuration requirements stated in the system requirements document, some management and operation functions of a virtual server environment may not be used when Sage Intergy is installed. Do not employ the following management practices for Sage Intergy virtual servers: Live Migration - When more than one host machine is available in the same virtual server environment, the VMWare product allows a virtual server to be moved to a different host machine. However, as a best practice, Sage Intergy systems should be shut down before they are migrated to prevent data corruption or other damage to database files. Do not use the pause feature of any virtualization product, or allow a virtual server to be migrated while it is still running. Host System Sharing - As a best practice, isolate a virtual server that is running Sage Intergy so that it is the only guest system on any one host server. Installation of multiple virtual servers on a single host may affect the performance of the virtual disk and network functions of the Sage Intergy system. Whenever possible, operate a virtual server with Sage Intergy on only one host system. Virtualization Performance Considerations Sage R&D System Engineering personnel have conducted testing on Sage Intergy virtual servers to compare their performance with comparable physical hardware. Sage engineers found that when configured with comparable specifications, virtual servers and physical servers provided an equivalent user experience when using Sage Intergy. However, the management and portability advantages of a virtual server are offset by performance disadvantages. 10 Sage Intergy 6.10 Architecture Guide Sage

14 As one example, system engineers compared the disk I/O performance of a virtual server and a physical server with comparable configurations. The results of this testing showed that on average, disk performance for both read and write operations was slower by ten percent for virtual servers as compared to a physical server. System engineers performed tests for other system performance metrics, such as network response, that showed a similar performance disadvantage for each server function. When evaluating the implementation of a virtual server host system, Sage technicians and Sage customers should weigh the advantages of manageability and portability against the cost of installing host hardware that will provide sufficient performance for any new or upgraded Sage Intergy system. Although daily operation of the Sage Intergy client is not likely to be affected, some operations that require large input and output capacity may be impacted when used on a virtual server. These impacted operations may include long reports, database maintenance functions, or external connectivity from applications such as Sage Practice Analytics. Sage Sage Intergy 6.10 Architecture Guide 11

15 Sage Intergy Service Options Although most Sage Intergy services will be installed on the database server, in some cases these services may be installed on separate hardware. This section describes the circumstances under which these types of services may be implemented on a stand alone server. Stand Alone Remote Print Server The purpose of a Sage Intergy Remote Print Server (RPS) is to manage large Sage Intergy reports and send them to a designated system printer. This reduces workload on Sage Intergy Client PC's, by permitting large Sage Intergy reports to be offloaded from the Sage Intergy Client PC so that the user's workflow is not interrupted.the Remote Print Server only affects reports that are sent directly to a Sage Intergy system printer managed by a Remote Print Server. Simply viewing a Sage Intergy report on the screen will not utilize the Remote Print Server. In most cases, an RPS is not required. It should only be considered in unique situations after conducting performance analysis if so warranted as determined by client s printing volume and workflow requirements, for example. Clients using Sage Intergy EHR PDA require a Remote Print Server running on the Sage Intergy Database Server but not necessarily as a dedicated standalone server. Sage IEHR installations that include PDA clients make use of the RPS server for prescriptions and other specialized printing functions. Make sure all Sage IEHR PDA environments include a Remote Print server. Report Server for WAN clients A report server is an application used only with configurations that include WAN clients. It builds and compresses a report before sending it to a WAN client. The compressed report data is sent back to the WAN client where it is uncompressed and processed. This reduces network traffic, because the report server communicates with the database server over the LAN to obtain the data to build the report. For configurations with WAN 12 Sage Intergy 6.10 Architecture Guide Sage

16 clients, a dedicated report server is not required. One report server is already installed by default on the database server. The network connection between the database server and the report server must be a LAN connection to fully realize the benefits of this type of configuration. If the client does not have a MS Windows Domain Controller (DC), the Sage Intergy Report Server can be upgraded to function as the client s DC. Stand Alone Medcin Server The Medcin server has a database that contains a rich knowledgebase of diagnosis and procedure codes and terminology needed by a provider for evaluation of patient care. The Medcin server provides formatting of an encounter note narrative in plain text, RTF or HTML. When a client/server session is established, the server maintains state information for the client. The state information for a session can be maintained between connections. State information may include the patient s demographics, complete medical history, and search or prompt functions in progress. The Medcin server may be installed to server hardware or to a client workstation. Sites that cannot upgrade the Sage Intergy database server s CPU or memory may experience sustained excessive CPU usage or paging, causing unacceptable performance. Customers who observe this type of issue should consider adding a standalone Medcin server. The Medcin server may also run on a computer running the Remote Print Server, Standalone AppServer, Document Delivery Server, or Report Server modules. Standalone Document Delivery Server The Document Delivery Server processes approved transcriptions and prints and/or faxes the documents to the associated referring physicians. The Document Delivery Server uses thirdparty software and hardware to fax transcriptions. The Transcription Writer and MS Word 2003 or later are prerequisite components on the machine that has the Document Delivery Server for processing inbound and outbound transcriptions via HL7. The Document Delivery Server is currently only utilized for radiology sites, or for sites using clinical correspondence and background approval functions of the encounter notes. The Document Delivery Server may run on a stand alone application server or a client workstation. Sites that cannot upgrade the Sage Intergy database server s CPU or memory, Sage Sage Intergy 6.10 Architecture Guide 13

17 and are experiencing sustained excessive CPU usage or paging, causing unacceptable performance should consider adding a standalone Document Delivery Server. The Document Delivery Server may also run on a computer running the Remote Print Server, Standalone AppServer, Medcin Server, or Report Server modules. Whenever possible, it is preferable to upgrade the Sage Intergy database server and install the Document Delivery Server on the same hardware. This is generally a more cost-effective solution, and is less complicated to configure. Practice Portal Broker Server The Practice Portal broker manages communications between the practice and remote services hosting the patients web-based user interfaces. As the patient navigates through various web pages, clinical and demographic information is supplied through the broker. The Practice Portal broker may be installed on either the Sage Intergy database server or on a separate stand alone application server. Before choosing how the broker will be installed, consider the computing environment requirements: 24x7 availability - Since the portal will not be available to patients during any sever downtime, the Practice Portal broker requires a high-availability server. Note that items that might affect server availability include hardware/os stability and the maintenance requirements of other applications running concurrently on the server. Communications server connected to a public network (i.e., Internet) - While great effort has been taken to insure broker security, some customer environments may require that sensitive data like the Sage Intergy database is not also located on the server where the Practice Portal broker is installed. In these instances technicians may be directed to exercise the option of installing Practice Portal on a separate server. NOTE: When accessing the Practice Portal website on either a client workstation or a patient s home computer, the website can be viewed on IE 6.0 or higher. The website can be viewed on Mozilla Firefox 2.0 and later as well. Internet Connection Speed - To accommodate connections to the web server from the Internet, a minimum upload speed of 720 kb/sec is required for the Practice Portal server Internet connection. 14 Sage Intergy 6.10 Architecture Guide Sage