Systems and methods for transferring remote context

BACKGROUND

p-0002Clinical information has become an important part of the diagnosis and treatment of a patient. In many cases, clinical information is stored and accessible in a variety of systems in a variety of locations. Currently, user login at several separate systems introduces delay and repetition that can impact performance and negatively influence the diagnosis and treatment of patients.

BRIEF SUMMARY

p-0003Certain embodiments of the present invention provide systems and methods for context transfer.

p-0004Certain examples provide a computer-implemented method for remote context transfer between user sessions with a clinical information system. The method includes accepting a user log on request for a user session at a first clinical information system; identifying one or more open sessions associated with the user; saving a context associated with one of the one or more open sessions; terminating the one or more open sessions identified as associated with the user; and transferring the saved context to the user session at the first clinical information system for use by the user in the user session.

p-0005Certain examples provide a non-transitory computer-readable storage medium having a set of instructions stored thereon which, when executed, instruct a processor to implement a method for remote context transfer between user sessions with a clinical information system. The method includes accepting a user log on request for a user session at a first clinical information system; identifying one or more open sessions associated with the user; saving a context associated with one of the one or more open sessions; terminating the one or more open sessions identified as associated with the user; and transferring the saved context to the user session at the first clinical information system for use by the user in the user session.

p-0006Certain examples provide a clinical context and session management system including a processor connected to a memory. The processor is programmed to facilitate clinical context and session management by implementing a monitor. The monitor is to identify one or more open sessions associated with a user at initiation of a user login request for a user session. The monitor is to trigger a clinical information system to save at least one of a patient context and a user context associated with one of the one or more open sessions and terminate the one or more open sessions identified as associated with the user. The monitor is to facilitate transfer of the saved at least one of a patient context and a user context to the user session for use by the user in the user session.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

p-0007<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a flow diagram for an example method for user and clinical information system interaction for remote context transfer.

p-0008<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates an example system enabling remote transfer of context and session termination with respect to one or more clinical information systems.

p-0009<figref idrefs="DRAWINGS">FIG. 3</figref> shows an example session management dashboard.

p-0010<figref idrefs="DRAWINGS">FIG. 4</figref> depicts an example sequence diagram for a process facilitating remote user session log out.

p-0011<figref idrefs="DRAWINGS">FIG. 5</figref> shows an example clinical enterprise system.

p-0012<figref idrefs="DRAWINGS">FIG. 6</figref> is a block diagram of an example processor system that may be used to implement the systems, apparatus and methods described herein.

p-0013The foregoing summary, as well as the following detailed description of certain embodiments of the present invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, certain embodiments are shown in the drawings. It should be understood, however, that the present invention is not limited to the arrangements and instrumentality shown in the attached drawings.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

p-0014Certain examples provide systems and methods for remote user session identification, termination, and context transfer. Certain examples allow a user to save a user/patient context from another open session and resume that context in a local session on a different machine. Certain examples facilitate context saving and restoration to improve user workflow.

p-0015Although the following discloses example methods, systems, articles of manufacture, and apparatus including, among other components, software executed on hardware, it should be noted that such methods and apparatus are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of these hardware and software components could be embodied exclusively in hardware, exclusively in software, exclusively in firmware, or in any combination of hardware, software, and/or firmware. Accordingly, while the following describes example methods, systems, articles of manufacture, and apparatus, the examples provided are not the only way to implement such methods, systems, articles of manufacture, and apparatus.

p-0016When any of the appended claims are read to cover a purely software and/or firmware implementation, at least one of the elements in an at least one example is hereby expressly defined to include a tangible medium such as a memory, DVD, Blu-ray, CD, flash, USB drive, etc. storing the software and/or firmware.

p-0017A web framework, such as GE's Centricity Framework™, is a framework for providing web-based healthcare applications and associated information. Using the framework, a patient and/or provider context can be shared. For example, a GE Centricity Business™ user locates a patient in a scheduling module and can then “click on” or otherwise select a link to open the patient's chart in a Centricity EMR™ application. The Electronic Medical Record (EMR) runs in the web framework as well.

p-0018Context management is a dynamic computer process that uses “subjects” or targets of data in one application to point to data resident in a separate application also containing the same subject, for example. Context Management allows users to choose a subject once in one application and have all other applications including information regarding that same subject “tune’ to the data they include, thus obviating the need to redundantly select the same subject in the varying applications.

p-0019For example, in the healthcare industry, multiple applications operating “in context” using a context manager allow a user to select a patient (e.g., the subject) in one application, and, when the user enters another application, that patient's information is already pre-fetched and presented, obviating the need to re-select the patient in the second application. That is, context management enables clinicians to select a patient's name once in an application and have their screens automatically populate with links to that patient in other applications.

p-0020A clinical context includes a set of clinical context subjects. Each subject represents a real-world entity, such as a particular patient, or concept, such as a specific encounter with a patient. By sharing context, applications are able to work together to follow a user's thoughts and actions as the user interacts with a set of applications. These applications are said to be “clinically linked”.

p-0021Context management can be used in Patient Information Aggregation Platforms (PIAP) such as Portals, for example. Context Management can be used in both HL7 Clinical Context Object Workgroup standard committee (CCOW) and non-CCOW compliant applications. CCOW has created a standardized protocol enabling applications to function in a “context aware” state. The CCOW standard helps facilitate a more robust, and near “plug-and-play” interoperability across disparate applications. Additionally, the Health Level Seven (HL7) Context Management Standard (CMS) defines a standard for automatic coordination and synchronization of disparate healthcare applications that reside on the same clinical desktop.

p-0022The CMS defines a Context Management Architecture (CMA), which provides a format for independent applications to share data that describe a common clinical context. Under the CMA, responsibility for managing the common context is centralized in a common facility that is responsible for coordinating the sharing of the context among the applications. In some examples, a set of name-value pairs represent key summary information about the common context (e.g., patient name and medical record number).

p-0023The CMA maintains a single authentic copy of the common context for each common context system. Applications can choose to cache context data and/or can access the authentic copy when needed. Applications can also selectively read or write specific context data name-value pairs. When the context changes, an application is only informed about the change and is not provided with the data that has changed. The application can selectively access the change data.

p-0024HL7 CMA subjects and associated context data items include core subjects such as patient, encounter, observation, user, and certificate, and their respective context data items. Organizations, such as healthcare provider institutions and vendors, can define their own context subjects and data items. These items are in addition to the standard subjects and the standard items defined for the standard subjects.

p-0025GE's Centricity Framework™ offers developers a way to integrate separate GE products, while consolidating sign-on and security to a single point of entry. The Centricity Framework™ provides a consistent presentation of login, navigation (e.g., menus), and patient banner. Hosted products share context information and can offer cross-product workflows, regardless of their user interface (UI) technology.

p-0026Centricity Framework 5.0 (CF 5.0) offers a choice of two client desktop solutions (both involving Microsoft .NET™ 2.0 on the client desktop). A first client desktop solution includes a traditional browser-based Web client. A second client desktop solution includes Iris, a Microsoft .NET-based client solution that does not require Internet Explorer (e.g., based on Microsoft smart client technology). The Centricity Framework 5.0 supports a single sign-on (SSO) solution and a context manager, for example.

p-0027Communications between the CF and a Web Framework (WF) server can be facilitated via XML-based service calls. Each instance of the CF exposes a certain URL (Uniform Resource Locator) as a handler for all service calls. This URL can be found in the DataURL tag in the Serverinfo.xml file which is located in the WF's main web folder, for example. CF enables the use of a security plug-in to implement an alternate authentication mechanism in place of the standard Framework username/password check. If a security plug-in is used, the plug-in performs server-side authentication of users or of authentication tokens generated on the client. The Framework provides plug-ins for Kerberos (v4.01), RSA SecurID (v5.0), CCOW userlink (v4.0), CCOW/LDAP integration (v4.03), etc.

p-0028In some examples, a system enables Web applications to be integrated into process involving concurrent operation of applications. The system specifies the rules for conveying URL data and other data between applications. The system employs a managing application and services (e.g., a session manager) to facilitate application session management. The system employs by a first (parent) application for supporting concurrent operation with other (children) applications. The system involves an entitlement processor for authorizing user access to the first (parent) application in response to validation of user identification information. The system involves a communication processor for communicating a session initiation request to a managing application to initiate generation of a session identifier particular to a user initiated session.

p-0029The session manager is used by the managed applications to reference global data that is essential to a workflow. Such global data includes user identification information, a shared key used for the encryption of URL data, and a common URL to be used for handling logoff and logon function, for example. The session manager is regularly notified of activities from the applications to prevent an inactivity timeout while a user is active in another concurrent application. The session manager employs a system protocol for passing session context information between applications via URL query or form data.

p-0030Session context information includes a session identifier (used by the managed applications to identify a user initiated session in communicating with manager), a hash value (used by the managed applications to validate that a received URL has not been corrupted), and application specific data (can be encrypted), for example. The session manager uses a unique session identifier (SID) for each new session (e.g., to protect against corruption and replay of a URL). In addition, to avoid redirection, the parent application can generate a URL link with an embedded hash value from the domain, port and file path name of the URL (e.g. using RSA MD5). Communication can occur via HTTP, TCP/IP, and/or other similar communication protocol to facilitate exchange of data between a client browser and application(s), between application(s) and the session manager, etc.

p-0031Certain examples allow a user to remotely shut down another application and take the patient and/or provider context from that application to transfer it to the new application. Remote context transfer and application shutdown provides security within context sharing, for example.

p-0032In an example Microsoft .NET™ implementation, a port is opened to allow new applications to connect to the port and issue logout requests for another executing application. For example, first, an application begins execution and opens a communication port. The application starts a listener with the .NET framework, which “listens” or monitors to detect other applications. Any further applications that are opened can send a request to the first application to log out the user of the first application. When that user is logged out, a context of a patient that the user was reviewing and/or a user context itself is saved to a database.

p-0033When the user starts a second application, the user receives a message asking whether he or she wishes to shut down the first application and retrieve its patient and/or user context. The first application receives a message indicating the pending shutdown or log out. The context (e.g., patient and/or user) is saved at application shutdown, and then the second application is allowed to take the saved context from the database and open up the patient and/or user context in its session.

p-0034To retrieve a saved patient and/or user context, a database and/or other data storage is queried to identify and retrieve the stored context. Credentials (e.g., username, password, card-based identifier, biometric identifier, etc.) can be requested to allow access to and execution of the first and/or second application. Credentials are used to identify and retrieve context for the second application. Credentials can be used to save and then retrieve context information, for example.

p-0035A context can include information such as a patient identifier, a list of previously viewed patients, a recently found list of patients (e.g., formulated as a drop-down menu for user selection), an active document being viewed at the time of context saving, a list of previously viewed documents (e.g., formulated as a drop-down menu for user selection), an active screen (e.g., not just a document per se but also, for example, a user summary screen), etc. In some examples, a context can allow a user to resume activity at a place in an application at which the user can previously stopped his or her work. In some examples, a context transfer allows a user to be brought back to a particular application. Applications can relate to any clinical information system, such as a picture archiving and communication system (PACS), a radiology information system (RIS), an electronic medical records (EMR) system, a personal health record (PHR) system, a laboratory information system (LIS), a cardiovascular information system (CVIS), a hospital information system (HIS), an imaging modality-related system, and/or other clinical information system (CIS).

p-0036In certain examples, in order to facilitate smooth on-the-fly context transfers, delay in context saving, log in and log out can be accommodated. If a delay occurs in the first application when a call to logout is issued, the patient and/or user context is saved before the second application can log in. A built in wait time can be added to allow certain phases to complete, including a check to see if the first application session has been logged out before moving forward with the second application.

p-0037Using automatic, remote context transfer can help save a user's time in having to open a new application and manually reload the context. Upon load of a new application session, initiation of the session can include a check to see if a saved context exists to be loaded.

p-0038In certain examples, the same user can be logged into one or more instances of a Clinical Information System at the same time. Users of a single Clinical Information System can move between systems (e.g., instances) and maintain contextual data, even if they have not logged out of previous system.

p-0039The definition of context can be configurable per Clinical Information System. For example, context information can include: the Patient ID being accessed, the list of previously viewed Patient IDs, the active document being view, the list of previously viewed documents, the active screen, etc.

p-0040In operation, for example, a user has logged into a system on device A, accesses patient information, and leaves herself logged into device A. She then goes to device B and wants to pick up where she left off, e.g., viewing the same patient information as on device A. She wants context information transferred from her session on device A to her session on device B.

p-0041Upon authentication into a Clinical Information System, the system 1) detects that the user has an established session (e.g., the user already logged into another system) or sessions opened and 2) allows context information associated with the “most recent” session to be transferred to the local session (e.g., transferred to the system for which the user is currently being logged in).

p-0042In certain examples, a Clinical Information System can receive requests from other systems in order to allow a remote logout of a user. When the system detects this request for a remote logout, the system saves user and/or patient context. The system can also detect that a user is logged into other system(s) and send remote logout requests to those system(s) as needed.

p-0043<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a flow diagram for an example method <b>100</b> for user and clinical information system interaction for remote context transfer. <figref idrefs="DRAWINGS">FIG. 1</figref> depicts an example flow diagram representative of processes that may be implemented using, for example, computer readable instructions that may be used to facilitate remote user logout and context transfer. The example processes of <figref idrefs="DRAWINGS">FIG. 1</figref> may be performed using a processor, a controller and/or any other suitable processing device. For example, the example processes of <figref idrefs="DRAWINGS">FIG. 1</figref> may be implemented using coded instructions (e.g., computer readable instructions) stored on a tangible computer readable medium such as a flash memory, a read-only memory (ROM), and/or a random-access memory (RAM). As used herein, the term tangible computer readable medium is expressly defined to include any type of computer readable storage and to exclude propagating signals. Additionally or alternatively, the example processes of <figref idrefs="DRAWINGS">FIG. 1</figref> may be implemented using coded instructions (e.g., computer readable instructions) stored on a non-transitory computer readable medium such as a flash memory, a read-only memory (ROM), a random-access memory (RAM), a cache, or any other storage media in which information is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable medium and to exclude propagating signals.

p-0044Alternatively, some or all of the example processes of <figref idrefs="DRAWINGS">FIG. 1</figref> may be implemented using any combination(s) of application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)), field programmable logic device(s) (FPLD(s)), discrete logic, hardware, firmware, etc. Also, some or all of the example processes of <figref idrefs="DRAWINGS">FIG. 1</figref> may be implemented manually or as any combination(s) of any of the foregoing techniques, for example, any combination of firmware, software, discrete logic and/or hardware. Further, although the example processes of <figref idrefs="DRAWINGS">FIG. 1</figref> are described with reference to the flow diagram of <figref idrefs="DRAWINGS">FIG. 1</figref>, other methods of implementing the processes of <figref idrefs="DRAWINGS">FIG. 1</figref> may be employed. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, sub-divided, or combined. Additionally, any or all of the example processes of <figref idrefs="DRAWINGS">FIG. 1</figref> may be performed sequentially and/or in parallel by, for example, separate processing threads, processors, devices, discrete logic, circuits, etc.

p-0045Referring to <figref idrefs="DRAWINGS">FIG. 1</figref>, at <b>110</b>, user is authenticated with respect to a Clinical Information System. At <b>120</b>, after a user has been successfully authenticated, user log in to other system(s) is determined by the clinical information system.

p-0046At <b>130</b>, the user is alerted to the multiple open sessions. For example, the system displays the message, “You have <# of open sessions> other sessions open. Do you want to terminate all other sessions and transfer context from the most recent session?” At <b>140</b>, user confirmation of termination and context (e.g., patient and/or user) transfer is processed.

p-0047At <b>150</b>, user and/or patient context is saved for the most recent user session (e.g., the open session with the most recent start date and time). At <b>160</b>, the user's sessions are terminated (e.g., logged out). At <b>170</b>, saved context information is used to pre-populate data on applicable screens and/or store data in memory. At <b>180</b>, the user login process is completed for the new session. At <b>190</b>, the context from a previous session is made available to the user who can continue with his/her work.

p-0048As described herein, the method <b>100</b> can be implemented using the mobile device in one or more combinations of hardware, software, and/or firmware, for example. The method <b>100</b> can operate with the mobile device in conjunction with one or more external systems (e.g., data sources, healthcare information systems (RIS, PACS, CVIS, HIS, EMR, EHR, PHR, etc.), archives, imaging modalities, etc.). One or more components of the method <b>100</b> can be reordered, eliminated, and/or repeated based on a particular implementation, for example.

p-0049Thus, certain examples help enable more efficient workflows in Clinical Information Systems by allowing a user to transfer context from the most recent remote session to the local session. Certain examples help reduce security risks caused by unwanted, opened sessions to a Clinical Information System by allowing a user to terminate his/her own remote sessions.

p-0050Certain examples provide a technical effect of enabling remote termination of opened sessions from any instance of a Clinical Information System while saving context information based on this remote termination. Certain examples provide reloading a user's context (e.g., patient and/or user context) at his/her discretion.

p-0051<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates an example system <b>200</b> enabling remote transfer of context and session termination with respect to one or more clinical information systems. The system <b>200</b> includes a first clinical information system (CIS) <b>210</b> and a second CIS <b>220</b>. The first CIS <b>210</b> includes a first user session <b>212</b> and a first context <b>214</b> within the session <b>212</b>. The context <b>214</b> can be a user and/or patient context, for example. The second CIS <b>220</b> includes a second user session <b>222</b> and a second context <b>224</b> within the session <b>222</b>. The context <b>224</b> can be a user and/or patient context, for example. A monitor <b>230</b> monitors applications executing on the first CIS <b>210</b> and second CIS <b>220</b> to identify additional instances of a user session.

p-0052When the monitor <b>230</b> detects that the first user session <b>212</b> on the first CIS <b>210</b> remains open when the second user session <b>222</b> is initiated, the monitor <b>230</b> communicates with the first CIS <b>210</b> to indicate closure of the first user session <b>212</b> and saving of the first context <b>214</b> to a data store <b>240</b>. The user can be prompted to save and/or logout, and/or the monitor <b>230</b> can facilitate an automated save and/or logout of the first context <b>214</b> and user session <b>212</b>. Once the first context <b>214</b> has been saved and the first user session <b>212</b> has been terminated, the second user session <b>222</b> identifies and retrieves the saved first context <b>214</b> from the data store <b>240</b> and provides it to the user as the second context <b>224</b>.

p-0053Using the monitor <b>230</b>, a user at the second CIS <b>220</b> and/or an administration can view logged-in user session(s) <b>212</b> and associated device(s) <b>210</b>. A user can terminate his/her own remote session <b>212</b>. An administrator can also terminate a user's remote session <b>212</b>. The user can terminate his/her own remote session <b>212</b> and transfer his/her user and/or patient context <b>214</b> from that remote session <b>212</b> to the local session <b>222</b>.

p-0054As depicted, for example, in <figref idrefs="DRAWINGS">FIG. 3</figref>, an administrator can be authorized to view and access device, session, and context information via a session management dashboard <b>300</b>, for example. A dashboard results grid can include information such as Username, Full Name, User Active, Deactivate User, Email, IP Address, Role, Session Start Time, System ID, Session State, Device ID, Device Location, Device Description, Device Active, and Deactivate Device. In certain examples, an administration can search using criteria such as Username, Full Name, IP Address, Device ID, Device Location, System ID, Role, and Session State. From the dashboard an administrator, authorized to access this functionality, can terminate one or more associated users. When the Administrator terminates remote sessions for a given user/device, the remote session context with the latest session start time is saved. In certain examples, an administrator can set a preference to provide a user with the option of terminating his/her remote session. In certain examples, a user is allowed to log in, even if the user decides not to terminate his/her remote session.

p-0055When a user is prompted to terminate his/her remote session, the user is prompted to transfer context information (e.g., patient and/or user context) from the remote session to the local session. In certain examples, a session logout can be configured to allow an automatic and/or user-selected grace period, such as one, five, or fifteen minutes, before session termination. In certain examples, if a grace period is used, the time remaining until termination is displayed in the remote user's toolbar or status bar. A user can receive one or more default and/or custom messages regarding termination and/or context transfer.

p-0056Upon log in, a user with a single session open (not including the current session) can be prompted with a message box or other dialog indicating “You have one other session open. Do you want to terminate that session?” The user can respond by selecting yes or no. Additionally, the user can be asked if he/she would like to save and/or transfer the context in which he/she was working for the remote open session. A user with multiple open sessions can be prompted to terminate one or more of the open sessions and to transfer context from one of the sessions being terminated to the current user session.

p-0057In certain examples, all sessions other than the session initiating a log out request are considered remote sessions. Thus, in those examples, event client sessions on the same/machine device other than the requesting session. In certain examples, a username can be selected to log out all remote sessions for that username, regardless of other identifier, such as system ID.

p-0058In certain examples, a context save is facilitated using a client side socket listener to handle logout requests sent via a framework server. In examples having multiple active remote sessions, one or more criteria, such as most recent start time, dictates which context is transferred from a remote session to the local session. In certain examples, a loop or delay can be executed after a context save and/or logout is initiated to make sure that the action is completed before advancing to a next portion of the process.

p-0059Certain examples support Clinical Context Object Workgroup (CCOW) context management. In some CCOW logout processing (assuming CCOW is enabled and user context is set) a logout terminates all joined sessions. Since a user may be requesting his/her sessions (on that computer/device) be logged-out, CCOW logout behavior would interfere with this process. Therefore, a CCOW logout can be skipped if the user has a settings, such as a SessionTerminateRemotely preference, set to “Terminate” or “TerminateAndTransferContext”, and decides to logout out all his/her open sessions.

p-0060<figref idrefs="DRAWINGS">FIG. 4</figref> depicts an example sequence diagram for a process <b>400</b> facilitating remote user session log out. <figref idrefs="DRAWINGS">FIG. 4</figref> depicts an example flow diagram representative of processes that may be implemented using, for example, computer readable instructions that may be used to facilitate remote user logout and context transfer. The example processes of <figref idrefs="DRAWINGS">FIG. 4</figref> may be performed using a processor, a controller and/or any other suitable processing device. For example, the example processes of <figref idrefs="DRAWINGS">FIG. 4</figref> may be implemented using coded instructions (e.g., computer readable instructions) stored on a tangible computer readable medium such as a flash memory, a read-only memory (ROM), and/or a random-access memory (RAM). As used herein, the term tangible computer readable medium is expressly defined to include any type of computer readable storage and to exclude propagating signals. Additionally or alternatively, the example processes of <figref idrefs="DRAWINGS">FIG. 4</figref> may be implemented using coded instructions (e.g., computer readable instructions) stored on a non-transitory computer readable medium such as a flash memory, a read-only memory (ROM), a random-access memory (RAM), a cache, or any other storage media in which information is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable medium and to exclude propagating signals.

p-0061Alternatively, some or all of the example processes of <figref idrefs="DRAWINGS">FIG. 4</figref> may be implemented using any combination(s) of application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)), field programmable logic device(s) (FPLD(s)), discrete logic, hardware, firmware, etc. Also, some or all of the example processes of <figref idrefs="DRAWINGS">FIG. 4</figref> may be implemented manually or as any combination(s) of any of the foregoing techniques, for example, any combination of firmware, software, discrete logic and/or hardware. Further, although the example processes of <figref idrefs="DRAWINGS">FIG. 4</figref> are described with reference to the flow diagram of <figref idrefs="DRAWINGS">FIG. 4</figref>, other methods of implementing the processes of <figref idrefs="DRAWINGS">FIG. 4</figref> may be employed. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, sub-divided, or combined. Additionally, any or all of the example processes of <figref idrefs="DRAWINGS">FIG. 4</figref> may be performed sequentially and/or in parallel by, for example, separate processing threads, processors, devices, discrete logic, circuits, etc.

p-0062Turning to <figref idrefs="DRAWINGS">FIG. 4</figref>, at <b>410</b>, a user <b>401</b> initiates a log in to a session. At <b>415</b>, a remote session handler <b>402</b> invokes a session selection service. At <b>420</b>, a network module <b>403</b> sends a request to a java service application <b>404</b> to identify open user session(s). For example, the application <b>404</b> matches the user's username to open sessions to identify those session(s) associated with the same user.

p-0063At <b>425</b>, a response identifying the user's session(s) is sent back to the network drier <b>403</b>. At <b>430</b>, the response is relayed to the remote session handler <b>402</b>. At <b>435</b>, the remote session handler <b>402</b> prompts the user <b>401</b> regarding the open session(s). For example, at <b>440</b>, the user receives a message at a new session login indicating that other session(s) remain open within the software framework. The user is asked whether he or she wishes to close the other open session(s) and transfer a user and/or patient context to the current session or lose the open context information.

p-0064At <b>445</b>, a user <b>401</b> response (e.g., yes, no, or particular item (e.g., session) selection) is provided to the remote session handler <b>402</b>. At <b>450</b>, if the response is “yes”, then a session delete service is invoked with an appropriate context transfer flag based on user response (e.g., to transfer or not to transfer context).

p-0065At <b>455</b>, the network <b>403</b> sends the session delete server request to the java service application <b>404</b>. At <b>460</b>, the application <b>404</b> generates a session delete service response. At <b>465</b>, the service response is relayed by the network <b>403</b> to the remote session handler <b>402</b>.

p-0066Systems and methods described above can be included in a clinical enterprise system, such as example clinical enterprise system <b>500</b> depicted in <figref idrefs="DRAWINGS">FIG. 5</figref>. The system <b>500</b> includes a data source <b>510</b>, an external system <b>520</b>, a network <b>530</b>, a first access device <b>540</b> with a first user interface <b>545</b>, and a second access device <b>550</b> with a second user interface <b>555</b>. In some examples, the data source <b>510</b> and the external system <b>520</b> can be implemented in a single system. In some examples multiple data sources <b>510</b> and/or external systems <b>520</b> can be in communication via the network <b>530</b>. The data source <b>510</b> and the external system <b>520</b> can communicate with one or more of the access devices <b>540</b>, <b>550</b> via the network <b>530</b>. One or more of the access devices <b>540</b>, <b>550</b> can communicate with the data source <b>510</b> and/or the external system <b>520</b> via the network <b>530</b>. In some examples, the access devices <b>540</b>, <b>550</b> can communicate with one another via the network <b>530</b> using a communication interface (e.g., a wired or wireless communications connector/connection (e.g., a card, board, cable, wire, and/or other adapter, such as Ethernet, IEEE 1394, USB, serial port, parallel port, etc.). The network <b>530</b> can be implemented by, for example, the Internet, an intranet, a private network, a wired or wireless Local Area Network, a wired or wireless Wide Area Network, a cellular network, and/or any other suitable network.

p-0067The data source <b>510</b> and/or the external system <b>520</b> can provide patient records, images, reports, scheduling, guidelines, best practices and/or other data/applications to the access devices <b>540</b>, <b>550</b>. In some examples, the data source <b>510</b> can receive information associated with a session or conference and/or other information from the access devices <b>540</b>, <b>550</b>. In some examples, the external system <b>520</b> can receive information associated with a session or conference and/or other information from the access devices <b>540</b>, <b>550</b>. The data source <b>510</b> and/or the external system <b>520</b> can be implemented using a system such as a PACS, RIS, HIS, CVIS, EMR, archive, data warehouse, imaging modality (e.g., x-ray, CT, MR, ultrasound, nuclear imaging, etc.), payer system, provider scheduling system, guideline source, hospital cost data system, and/or other healthcare system.

p-0068The access devices <b>540</b>, <b>550</b> can be implemented using a workstation (a laptop, a desktop, a tablet computer, etc.) or a mobile device, for example. Some mobile devices include smart phones (e.g., BlackBerry™, iPhone™, etc.), Mobile Internet Devices (MID), personal digital assistants, cellular phones, handheld computers, tablet computers (iPad™), etc., for example. In some examples, security standards, virtual private network access, encryption, etc., can be used to maintain a secure connection between the access devices <b>540</b>, <b>550</b>, data source <b>510</b>, and/or external system <b>520</b> via the network <b>530</b>. In some examples, one or more of the access devices <b>540</b>, <b>550</b> can be integrated with the data source <b>510</b> and/or external system <b>520</b>, and the network <b>530</b> can include wires, cables and/or other connection(s) internally and/or logically connecting the system components.

p-0069In some examples, the access device <b>540</b>, <b>550</b> can be implemented using a smart phone (e.g., BlackBerry™, iPhone™, iPad™, etc.), Mobile Internet device (MID), personal digital assistant, cellular phone, handheld computer, etc. The access device <b>540</b>, <b>550</b> includes a processor retrieving data, executing functionality, and storing data at the access device <b>540</b>, <b>550</b>, data source <b>510</b>, and/or external system <b>530</b>. The processor drives a graphical user interface (GUI) <b>545</b>, <b>555</b> providing information and functionality to a user and receiving user input to control the device <b>540</b>, <b>550</b>, edit information, etc. The GUI <b>545</b>, <b>555</b> can include a touch pad/screen integrated with and/or attached to the access device <b>540</b>, <b>550</b>, for example. The device <b>540</b>, <b>550</b> includes one or more internal memories and/or other data stores including data and tools. Data storage can include any of a variety of internal and/or external memory, disk, Bluetooth remote storage communicating with the access device <b>540</b>, <b>550</b>, etc. Alternatively or in addition to gesture-based navigation/manipulation, a detector, such as an accelerometer, position encoder (e.g., absolute, incremental, optical, analog, digital, etc.), global positioning sensor, and/or other sensor, etc., can be used to detect motion of the access device <b>540</b>, <b>550</b> (e.g., shaking, rotating or twisting, left/right turn, forward/backward motion, etc.). Detected motion can be used to affect operation and/or outcomes at the access device <b>540</b>, <b>550</b>. The access device <b>540</b>, <b>550</b> processor can include and/or communicate with a communication interface component to query, retrieve, and/or transmit data to and/or from a remote device, for example.

p-0070The access device <b>540</b>, <b>550</b> can be configured to follow standards and protocols that mandate a description or identifier for the communicating component (including but not limited to a network device MAC address, a phone number, a GSM phone serial number, an International Mobile Equipment Identifier, and/or other device identifying feature). These identifiers can fulfill a security requirement for device authentication. The identifier is used in combination with a front-end user interface component that leverages an input device such as but not limited to; Personal Identification Number, Keyword, Drawing/Writing a signature (including but not limited to; a textual drawing, drawing a symbol, drawing a pattern, performing a gesture, etc.), etc., to provide a quick, natural, and intuitive method of authentication. Feedback can be provided to the user regarding successful/unsuccessful authentication through display of animation effects on a mobile device user interface. For example, the device can produce a shaking of the screen when user authentication fails. Security standards, virtual private network access, encryption, etc., can be used to maintain a secure connection.

p-0071For example, an end user launches a secure application (including but not limited to a clinical application requiring a degree of security). The application reads the unique identifying features of the device and performs an authentication “hand-shake” with the server or data-providing system. This process is automated with no user input or interaction required. After the device has been authenticated, the user is presented with an application/user level authentication screen (including but not limited to a personal identification number (PIN), password/passcode, gesture, etc.) to identify to the application that the user is indeed a valid user. This feature functions as a method to provide device level security as well as an ability to lock the device (e.g., if the user wishes to temporary lock the device but not logout/shutdown the application), for example.

p-0072<figref idrefs="DRAWINGS">FIG. 6</figref> is a block diagram of an example processor system <b>610</b> that may be used to implement the systems, apparatus and methods described herein. As shown in <figref idrefs="DRAWINGS">FIG. 6</figref>, the processor system <b>610</b> includes a processor <b>612</b> that is coupled to an interconnection bus <b>614</b>. The processor <b>612</b> may be any suitable processor, processing unit or microprocessor. Although not shown in <figref idrefs="DRAWINGS">FIG. 6</figref>, the system <b>610</b> may be a multi-processor system and, thus, may include one or more additional processors that are identical or similar to the processor <b>612</b> and that are communicatively coupled to the interconnection bus <b>614</b>.

p-0073The processor <b>612</b> of <figref idrefs="DRAWINGS">FIG. 6</figref> is coupled to a chipset <b>618</b>, which includes a memory controller <b>620</b> and an input/output (I/O) controller <b>622</b>. As is well known, a chipset typically provides I/O and memory management functions as well as a plurality of general purpose and/or special purpose registers, timers, etc. that are accessible or used by one or more processors coupled to the chipset <b>618</b>. The memory controller <b>620</b> performs functions that enable the processor <b>612</b> (or processors if there are multiple processors) to access a system memory <b>624</b> and a mass storage memory <b>625</b>.

p-0074The system memory <b>624</b> may include any desired type of volatile and/or non-volatile memory such as, for example, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, read-only memory (ROM), etc. The mass storage memory <b>625</b> may include any desired type of mass storage device including hard disk drives, optical drives, tape storage devices, etc.

p-0075The I/O controller <b>622</b> performs functions that enable the processor <b>612</b> to communicate with peripheral input/output (I/O) devices <b>626</b> and <b>628</b> and a network interface <b>630</b> via an I/O bus <b>632</b>. The I/O devices <b>626</b> and <b>628</b> may be any desired type of I/O device such as, for example, a keyboard, a video display or monitor, a mouse, etc. The network interface <b>630</b> may be, for example, an Ethernet device, an asynchronous transfer mode (ATM) device, an 802.11 device, a DSL modem, a cable modem, a cellular modem, etc. that enables the processor system <b>610</b> to communicate with another processor system.

p-0076While the memory controller <b>620</b> and the I/O controller <b>622</b> are depicted in <figref idrefs="DRAWINGS">FIG. 6</figref> as separate blocks within the chipset <b>618</b>, the functions performed by these blocks may be integrated within a single semiconductor circuit or may be implemented using two or more separate integrated circuits.

p-0077Thus, certain examples provide an ability to track and control multiple user sessions among one or more clinical systems. Certain examples facilitate context saving and transfer (e.g., a patient context, a user context, etc.) to streamline clinician workflow and improve efficiency in diagnosis, treatment, and patient management. Remote session termination and context transfer provides a technical effect of reducing redundancy and error associated with multiple, disparate sessions and associated context and data. For example, a user can review information at a patient's bedside and pick up at the same place in the same context at a nurse's stations or radiology workstation.

p-0078Certain embodiments contemplate methods, systems and computer program products on any machine-readable media to implement functionality described above. Certain embodiments may be implemented using an existing computer processor, or by a special purpose computer processor incorporated for this or another purpose or by a hardwired and/or firmware system, for example.

p-0079One or more of the components of the systems and/or steps of the methods described above may be implemented alone or in combination in hardware, firmware, and/or as a set of instructions in software, for example. Certain embodiments may be provided as a set of instructions residing on a computer-readable medium, such as a memory, hard disk, Blu-ray, DVD, or CD, for execution on a general purpose computer or other processing device. Certain embodiments of the present invention may omit one or more of the method steps and/or perform the steps in a different order than the order listed. For example, some steps may not be performed in certain embodiments of the present invention. As a further example, certain steps may be performed in a different temporal order, including simultaneously, than listed above.

p-0080Certain embodiments include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media may be any available media that may be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such computer-readable media may comprise RAM, ROM, PROM, EPROM, EEPROM, Flash, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of computer-readable media. Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.

p-0081Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of certain methods and systems disclosed herein. The particular sequence of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in such steps.

p-0082Embodiments of the present invention may be practiced in a networked environment using logical connections to one or more remote computers having processors. Logical connections may include a local area network (LAN), a wide area network (WAN), a wireless network, a cellular phone network, etc., that are presented here by way of example and not limitation. Such networking environments are commonplace in office-wide or enterprise-wide computer networks, intranets and the Internet and may use a wide variety of different communication protocols. Those skilled in the art will appreciate that such network computing environments will typically encompass many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

p-0083An exemplary system for implementing the overall system or portions of embodiments of the invention might include a general purpose computing device in the form of a computer, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. The system memory may include read only memory (ROM) and random access memory (RAM). The computer may also include a magnetic hard disk drive for reading from and writing to a magnetic hard disk, a magnetic disk drive for reading from or writing to a removable magnetic disk, and an optical disk drive for reading from or writing to a removable optical disk such as a CD ROM or other optical media. The drives and their associated computer-readable media provide nonvolatile storage of computer-executable instructions, data structures, program modules and other data for the computer.

p-0084While the invention has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from its scope. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed, but that the invention will include all embodiments falling within the scope of the appended claims.