CARESCAPE Citrix Guide 2nd edition sw ver 3

Contents 1 About this manual ... 5 1.1 Illustrations... 5 1.2 Trademarks ... 5 2 System description ... 6 2.1 Purpose of the system ... 6 2.2 Citrix XenApp support on the monitor ... 6 2.3 Citrix XenApp in the hospital network ... 7 2.3.1 XenApp hosted applications ... 7 2.3.2 XenApp hosted shared desktops ... 8

2.4 Hospital information systems ... 8 3 Planning the configuration... 9 4 Configuring Citrix XenApp ... 11 4.1 Publishing and configuring applications ... 11 4.1.1 Using a launch script ... 11

4.2 Publishing and configuring hosted shared desktop ... 11 4.3 Disconnected sessions handling and patient information safety... 12 4.4 Number of user sessions and patient information safety ... 13 4.5 Context transfer via the command line parameters ... 13 4.5.1 Passing parameters to published applications ... 13 4.5.2 Interpreting the command line parameter in a launch script ... 14 4.5.3 Command line parameter format ... 14

5 Configuring the CARESCAPE monitor ... 16 5.1 Network connection ... 16 5.2 Configuring the screen settings ... 16 5.3 Configuring Citrix settings in the service interface for the CARESCAPE monitor ... 17 5.3.1 Selecting user or device specific Citrix credentials ... 18

2106583-004

3 (19)

1 About this manual This document contains instructions necessary to configure the Citrix application in the CARESCAPE monitor.

1.1 Illustrations This document uses illustrations as examples only. Illustrations in this manual may not necessarily reflect all system settings, features, configurations, or displayed data.

1.2 Trademarks GE, GE Monogram, and CARESCAPE are trademarks of General Electric Company. All other product and company names are the property of their respective owners.

2106583-004

5 (19)

2 System description 2.1 Purpose of the system The Citrix client on a CARESCAPE monitor provides a way to start an external Windows application or a desktop and display it on the monitor screen at the point of care. From the user’s perspective it appears as if the application was running on the monitor when it is actually running on the remote XenApp server. Refer to the monitor’s supplemental information manual for a list of monitors supporting Citrix. Typically the external application or desktop gives access to critical patient information from other systems that are installed at the hospital, for example, diagnostic images, cardiology studies, lab results, and other electronic medical record information. The following figure shows a typical system where the CARESCAPE monitor uses the built-in Citrix client to show remote Windows applications running on a XenApp server. The XenApp server provides a bridge between the point of care and the hospital network.

Figure 1 – A typical system of a monitor interfacing the hospital network using the built-in Citrix client

2.2 Citrix XenApp support on the monitor The CARESCAPE monitor contains a built-in Citrix Client (also called the Citrix Receiver) that provides the ability to show external Windows applications or desktops running on the XenApp server as if the applications were executing locally on the monitor. The user starts the Citrix session and launches the preconfigured remote application from the monitor’s main menu by selecting Data & Pages > .

2106583-004

6 (19)

The monitor’s Citrix settings define which server and which application are connected and, optionally, which Citrix user and password are used to log in. A single monitor is limited to a single hosted application or a desktop at a time. Configure the Citrix settings in the service interface when configuring the monitor for use.

2.3 Citrix XenApp in the hospital network Citrix XenApp is an application delivery solution for IT administrators. It provides the possibility to virtualize and manage any Windows application in a centralized location and deliver applications as a service to users on any device in the network. In a hospital network Citrix XenApp can deliver clinical applications and desktops to clinicians’ workstations, tablets, or smart phones. With the built-in Citrix client in the monitor, the same applications can be delivered to the monitors.

2.3.1 XenApp hosted applications A XenApp hosted application can be any windows application that installs and runs on the Windows Server. The application may be a standalone utility application like Notepad or Calculator, or in a hospital environment it is typically a clinical application.

Figure 2 - An example of a hosted application (a web browser displaying Centricity Critical Care Webstation) on the monitor screen

The clinical application on the XenApp server can be a standalone client of a hospital information system (HIS). In this case the hospital information system can be located anywhere on the hospital network and does not need to be aware of the client running in the XenApp server. Another example is a web browser that provides access to any clinical system supporting web based access.

2106583-004

7 (19)

2.3.2 XenApp hosted shared desktops The published server desktop on XenApp is commonly referred to as a “XenApp hosted shared desktop”. The user sees a familiar Windows desktop interface, even though the desktop is actually shared by all users on the server.

Figure 3 – An example of a hosted shared desktop on the monitor screen

With a XenApp hosted shared desktop users can access applications and resources through a familiar Windows style desktop. This usage is very similar to using Windows Remote Desktop from a traditional workstation. The hosted shared desktop provides access to all the installed applications on the XenApp server, whereas the published application option only provides access to the published application. NOTE: The XenApp server desktop is not the same as XenDesktop, which provides a true virtual desktop infrastructure. The XenDesktop model is commonly referred to as a hosted virtual desktop, which is a virtual machine that runs any operating system and that single users can access remotely. One user’s desktop is not affected by another user’s desktop configuration. CARESCAPE monitors do not support XenDesktop.

2.4 Hospital information systems The hospital information systems in Figure 1 represent the various information systems and services that support patient care and may be accessed through a dedicated client or standard web browser delivered to the CARESCAPE monitor via the Citrix XenApp application virtualization. Examples of hospital information systems are a patient information system (PIS), a laboratory information system (LIS), a radiology information system (RIS), or a picture archiving and communication system (PACS).

2106583-004

8 (19)

3 Planning the configuration Before you start to configure the XenApp servers and CARESCAPE monitors, find out what the clinical users want to achieve with the integration. Consider the following configuration options: •

Identifying the caregivers’ workflows: Identify first what are the caregivers’ workflows that the external application supports at the point of care. A single CARESCAPE monitor is only able to show a single hosted application or a single desktop at a time. However, each monitor can have a unique configuration for different applications or desktops. In practice, each department can choose an application or a desktop (created by the hospital IT) that best supports its workflow.

•

Choosing between a hosted application or a hosted shared desktop on XenApp: The clinical workflows should drive the decision between a hosted application and a desktop that can be used to access several applications. A hosted application can also be a launch script or a web browser providing access to all web based applications. Compared to hosted shared desktops, a hosted application is faster, requires fewer resources from the XenApp infrastructure, supports the patient context transfer from the monitor, and requires less configuration and setting up from the IT administration. The advantage of a hosted shared desktop is that it provides more flexibility as it allows the user to start multiple applications.

•

Selecting user or device specific Citrix login in the monitor: If you use device specific logins, the Windows user accounts are preconfigured on each monitor. With user specific Citrix logins, each user is prompted for their personal user credentials when they start a Citrix session. The authentication for the target applications does not depend on the Citrix login. The same logic applies, for example, when you use netbank services on your computer. First you log into the desktop with your own user account. To log into your netbank, the system will prompt you for your user name and password. When you are deciding between user and device specific Citrix credentials configuration in the monitor, consider the following aspects: o unnecessary logins o security issues o user identification o application level authentication on the XenApp server side This decision requires balancing between unnecessary logins, security, and user identification. However, you also need to consider how the application level authentication is managed on the XenApp server side. See chapter 5.3.1 for more detail.

•

Session handling in XenApp for patient information safety: The XenApp server handles the user sessions according to the configuration and policies through the XenApp server administration. The client (in this case CARESCAPE monitor) cannot force the session to close on the server. When a client starts a new session with XenApp, the client may accidentally reconnect with an old disconnected or active session from the same user instead of creating a new session. In that case, there is a risk of incorrectly displaying another patient’s information on the monitor’s screen because all previously opened applications would still be running. To avoid this, use either XenApp server’s user session handling politics and settings or, alternatively, set up a disconnecting or a reconnecting session to trigger scripting tasks that close or reset running applications to a safe state. See chapters 4.3 and 4.4 for more details on this issue and how to handle it.

•

2106583-004

Transferring patient context for a hosted application: The CARESCAPE monitor sends the current patient medical record number (MRN) or the bed location as a command-line 9 (19)

parameter for the target application. This can be interpreted in a launch script and served to the target application, for example, through a URL parameter. Note that this is only supported for hosted applications and not for the hosted shared desktop. Chapter 4.5 explains this in more detail.

2106583-004

10 (19)

4 Configuring Citrix XenApp This chapter lists the XenApp configuration tasks required for the integration with a CARESCAPE monitor. For detailed instructions on how to perform the required configuration tasks, refer to the user documentation of Citrix XenApp and Windows server.

4.1 Publishing and configuring applications Refer to the user documentation of your XenApp server version on how to publish an application. The CARESCAPE monitors only support the hosted mode where the application runs on the server. CARESCAPE monitors do not support any of the streaming to client modes. For example, in XenApp the supported mode for “Application” type is “Accessed from a server”.

4.1.1 Using a launch script Instead of publishing an application directly, you can publish a launch script. The launch script enables you to set up the application environment as needed. With a launch script, you can catch the command line parameters the monitor sends and interpret the context information in the form required by the target application (see chapter 4.5 for details on interpreting the context). A launch script can also close the already running applications if the XenApp is not forced to close disconnected sessions (see chapters 4.3 and 4.4 for details on XenApp session handling). The launch script is always run even when reconnecting with an existing session. The launch script can even be used to start multiple applications but there is no taskbar that shows the running applications as on a desktop.

4.2 Publishing and configuring hosted shared desktop Refer to the user documentation of XenApp server for detailed instructions on how to publish the server desktop. The IT administration must configure and set up the following: 1.

Set up applications and shortcuts: Install the applications that users want to run from the shared desktop. Create the desktop shortcut and start menu items. For example: Desktop shortcuts are stored in common Windows folders. There is a folder for each user and one common folder for all users. For all users: For specific user:

2106583-004

C:UsersPublicDesktop C:Users<username>Desktop

2.

Set up the user interface according to the user’s needs: Common Windows look and feel options such as modifying desktop background, desktop items, icon sizes, and menu contents are available. The desktop icons are provided by the installed applications. These are all controlled by the IT administration.

3.

Lock down the desktop: Since the desktop provides access to the server desktop, Citrix recommends locking down the server desktops to prevent user access to sensitive areas of the operating system. If you use Windows Active Directory services, you can lock down the server desktops by applying correct group policies for the users. For detailed instructions, see the user documentation of your Windows server.

4.

Manage user password and single sign-on: When a user is logged into a shared desktop, the applications started from the desktop typically require another login. Third party password management solutions can be used for implementing single sign-on (SSO) to 11 (19)

reduce double logins. Applications (such as the web browser) can also store user names and passwords. SSO and password management make more sense when the user specific Citrix credential configuration is used in the monitor and users log in to XenApp with their personal Citrix user accounts. The monitor’s device specific Citrix credential configuration should be used with caution with the hosted shared desktops. Stored passwords and SSO mechanisms pose a real security concern as it is difficult to prevent unauthorized access and identify users without carefully enforcing policies to prevent applications from storing passwords. See chapter 5.3.1 for more details.

4.3 Disconnected sessions handling and patient information safety In XenApp a user login creates a new session within the server. When the client disconnects the session, it does not automatically end but stays alive in a disconnected state until a timeout is exceeded. If a user initiates a new session when the previous session is still alive in the disconnected state, the user reconnects with the old session. All opened applications are restored to the same state as when the previous session was disconnected. This may lead into clinical misinterpretations if the applications show information related to a previous patient. The monitor client cannot force the session to end. Even restarting the Citrix client leaves the session in the disconnected state. To manage the behavior of a disconnected session, configure the XenApp server in one of the following ways: •

Option 1 – Force disconnected sessions to end immediately (XenApp 6.5: only): This is the simplest and most effective way to ensure that patient information from a previous session is never shown. This method works equally well for applications and desktops. o

For reference see the Citrix Knowledge Center article CTX127318. The ICA Listener Configuration Tool does not allow you to set the timeout to less than 1 minute for the disconnected session. To make the timeout shorter, edit the registry manually: 1. Open RegEdit. 2. Edit the following registry entry: HKLMSystemCurrentControlSetControlTerminal ServerWinStationsICA-TCP Name: MaxDisconnectionTime Type: REG_DWORD Value: 0x000003E8 This sets a 1-second timeout for the disconnect session and ensures that a new session starts out fresh every time.

2106583-004

•

Option 2 – Allow disconnected sessions and force fresh start in the launch script: If you cannot force disconnected sessions to end immediately and the target is a hosted application, you can use a launch script. The launch script always runs even when reconnecting to a disconnected session and can therefore ensure a fresh start. In the launch script, terminate all previous instances of the application for the current user before starting the application.

•

Option 3 – Allow disconnected sessions and monitor sessions to become disconnected: In XenApp you cannot create a launch script for desktops in the same way as you can for 12 (19)

published applications. You can also use this option with hosted applications instead of closing all instances in the launch script as in option 2. As an alternative solution, monitor the status of user sessions and use the disconnected state of a session as a trigger to close all running applications of the current user. You can monitor the session state by configuring a scheduled task via Group Policy and setting the task to run when a user disconnects from a session.

4.4 Number of user sessions and patient information safety With the Group Policy Editor tool of Windows Server (Windows Server 2016) you can control whether users are restricted to a single session only or allowed to have multiple sessions.

Figure 4 – Restrict each user to a single session with the Group Policy Editor

From the patient information safety perspective, it is safest to disable Restrict each user to a single session to prevent the user from connecting to a previous session of the same user. Even if it is the same user’s session, the context has changed as the user is now working from a different monitor. It is safe to enable this setting only if the device specific credentials configuration is used in the CARESCAPE monitors (refer to section 5.3.1 ) and each monitor is configured with a unique user account. With user specific credentials configuration Restrict each user to a single session must always be disabled. Otherwise, a session in one monitor may be “stolen” when the same user starts a new session on another monitor.

4.5 Context transfer via the command line parameters This feature is only available for the published applications. The XenApp hosted shared desktop does not support this. 4.5.1 Passing parameters to published applications Use the Location page in Citrix Studio (Citrix AppCenter in 6.5) to enter the command line and to pass parameters to the published applications. Alternatively, you can set them when you publish the applications.

2106583-004

13 (19)

To modify the setting from the Action menu, select Application Settings > Location. Alternatively, you can define the parameters when you add the applications to store, or when you publish the applications.

Figure 5. Enabling passing command line parameters to published applications

The Command line setting is the full path of the application's executable file or launch script. Append the symbols "%**" (percent and two star symbols enclosed in double quotation marks) to the end of the command line to act as a placeholder for client-supplied application parameters (see Figure 5). 4.5.2 Interpreting the command line parameter in a launch script It is usually impractical (and not even possible with 3rd party applications) for the application to interpret the command line directly. Thus, a launch script can be used to catch the parameter and act as an adapter that translates the context information to the form required by the target application. This can be, for example, a URL parameter for web applications, an environment variable, a file in a special place or another command line parameter in case of standalone applications. 4.5.3 Command line parameter format The command line parameter is a string that contains two key value pairs. Within each pair, the field name and value are separated by an equals sign, '='. The two pairs are separated by the ampersand, '&'. A generic example of a string: key1=value1&key2=value2 A CARESCAPE monitor sends the patient MRN ID or the location ID together with the monitor’s MAC address. Refer to the monitor’s supplemental information manual for the network compatibility.

2106583-004

14 (19)

Table 1. The command line parameter key value pairs CARESCAPE network MRN exists

patient=<url-encoded-patient-MRN>&client.mac=<client-mac>

No MRN

location=<url-encoded-location-id>&client.mac=<client-mac>

Example case: The patient MRN is 123|abc and the MAC address is 00-D0-C9-C8-AA-7F. The resulting command line parameter string: • patient=123%7Cabc&client.mac=00-D0-C9-C8-AA-7F Or if no MRN is available: • location=%7Cabc&client.mac=00-D0-C9-C8-AA-7F

2106583-004

15 (19)

5 Configuring the CARESCAPE monitor 5.1 Network connection The CARESCAPE monitor needs to be connected to the IX Network that provides the connection to the targeted Citrix XenApp server.

5.2 Configuring the screen settings To configure the screen settings of the Citrix application: 1. Select Monitor Setup > Defaults & Service > Default Setup. 2. Enter your user name and password, and select Enter. 3. Select Care Unit Settings > Screens. You can select the screen where the application is shown and configure the application size. NOTE: These options are not available for monitor configurations with only a single display. The Application Size is always Normal for single display configurations.

Figure 6 - ESP Care Unit Settings / Screens settings menu

2106583-004

16 (19)

5.3 Configuring Citrix settings in the service interface for the CARESCAPE monitor Configure the monitor’s Citrix client over the service interface: 1. 2. 3. 4.

Log in to the service interface. Select Configuration > Citrix. Select Enabled. Enter the values to the following fields:

•

Server Address 1 to 4: Enter the IP address or DNS name of the XenApp server hosting the published application or hosted desktop. You can enter up to four server addresses. The Server Address 1 is always mandatory. To add another server, select Add a server, and enter the information of the additional server. The server address consists of an IP address or a host name, followed by an optional port number, which is separated by a colon. The maximum length for a host name is 255 characters. An example of an IP address with the optional port number is 3.187.230.30:8080.

•

Initial Program: The name of the application or desktop resource exactly as published in the XenApp. For example, #MUSE. This field is mandatory. The maximum length is 128 characters.

•

Session Timeout: This is a client side timeout that only affects a normal sized application window when it is hidden behind a menu. A full screen application is never hidden behind a menu and this timeout does not affect it. Keeping the session alive allows users to quickly return to their last session but locks the Citrix license. Valid values are between 0– 99 in minutes. Select “0” to disable the timeout.

•

Username and Password: o To enable device specific Citrix credentials configuration, configure the Windows user account and password. Give the user name in the following form: “domainusername” o To enable user specific Citrix credentials configuration, leave the user name and password fields empty. The user will be prompted to log in when a Citrix session is initiated (the button is pressed). NOTE: The user name and password must be in valid Windows format. The maximum length is 128 characters. See the next chapter (5.3.1 ) for more details.

•

Encryption Level: Select the encryption level: o Basic o RC5 – 128 bit – Login Only o RC5 – 40 bit o RC5 – 56 bit o RC5 – 128 bit By default, all ICA communications are set to Basic ICA protocol encryption. The Basic setting obfuscates data but does not provide industry standard encryption. You can increase the level of SecureICA encryption up to 128 bit. The SecureICA feature encrypts the session data sent between a server running XenApp and a client. Increasing the level of ICA protocol encryption prevents session data from being sent in clear text, but it does not provide authentication of the server. Furthermore, SecureICA does not check data integrity.

2106583-004

17 (19)

•

Load Balancing: Select either Enabled or Disabled. If the Load Balancing is disabled, Citrix will connect directly to the first server address. If it is enabled, Citrix client will query the first available server which tells the client where to connect to.

Figure 7 - Citrix Configuration in the service interface tool

5.3.1 Selecting user or device specific Citrix credentials The authentication to the target applications is always a two-phase process: 1.

Citrix client on the monitor authenticates with the XenApp server using a normal Windows user account. Successful authentication allows the client to start the requested remote application or desktop.

2.

The hosted application or an application started from the desktop requires users to log in again.

5.3.1.1 Relevant concepts and terminology The following concepts are related to Citrix credentials:

2106583-004

•

Citrix Login: The Citrix login authenticates a Windows domain user with the XenApp server and grants access to the target application or desktop. This is similar to logging into a normal desktop computer running a Windows operating system and attached to a Windows domain.

•

User specific Citrix credentials in the CARESCAPE monitor: The user name and password are left blank in the CARESCAPE monitor’s service interface configuration. The XenApp server prompts the user to log in every time the Citrix session is started (whenever the button is selected).

•

Device specific Citrix credentials in the CARESCAPE monitor: The user name and password are preconfigured for each CARESCAPE monitor in the service interface configuration. 18 (19)

Citrix session is automatically logged in for a given preconfigured user when a Citrix session started (whenever the button is selected). •

External application login: At this point the Citrix login has been successful and the Windows user is logged into the Citrix XenApp and authorized to run the provided application. The targeted hosted application or applications started from the desktop typically still require the user to log in (whenever a web browser opens the login page of a web application).

•

SSO and password management at application level: In our context SSO and Identity and Access Management (IAM) cover all applications that use the currently logged in Windows user account to automatically authenticate with the target application. This includes SSO or password management software or applications that remember previous passwords (such as the browser).

5.3.1.2 Different options The following configuration options are available: •

Device specific monitor configuration and applications do not remember passwords: The user is automatically logged into XenApp with the preconfigured Windows user. The hosted application or applications started from desktop prompt the user to log in. The real user can be identified, and there is only one login for hosted applications. To implement this option in a shared desktop, IT administration must enforce strict user policies so that applications (such as web browser) do not store and remember old passwords.

•

Device specific monitor configuration and applications remember passwords (SSO): The user is automatically logged into XenApp with the preconfigured Windows user. With the SSO mechanism the user is automatically logged to the target application or applications started from desktop. This option provides ultimate convenience but a lower level of security as there is no authentication at all. The user cannot be identified nor unauthorized access prevented.

•

User specific monitor configuration and applications do not remember passwords: The user is first prompted to log into XenApp with their personal Windows account. The hosted application or applications started from the desktop prompt the user to log in again.

•

User specific monitor configuration and applications remember passwords (SSO): The user is first prompted to log into XenApp with their personal Windows account. With SSO mechanism the user is automatically logged to the target application or applications started from desktop. The user can be identified and unauthorized access prevented. On a desktop, different users andor user groups may have personalized content. Even without any real password management or SSO solution, many applications can remember previous passwords. This is safe because each user is prompted to log in.

2106583-004

19 (19)