Patent Description:
Healthcare providers such as clinicians use a number of different software tools in the course of providing healthcare. Different software applications may be used for different aspects of a user's clinical practice, such as accounting software applications, electronic medical record (EMR) applications, medical image viewing applications, clinical reporting applications and so on. A user may interact with multiple software applications in the course of providing care to individual patients, even within a single patient interaction. For instance, a user may interact with separate applications to reviewing medical images, generate clinical reports, and manage billing for a single patient visit.

Using multiple software applications to record and report different aspects of healthcare tasks can be time-consuming and inefficient. In many cases, a user may enter the same information into each application, wasting time and effort that could be better spent treating patients.

The software applications used by clinicians can be provided in different forms. For instance, some software applications may be entirely cloud or web-based while others may be installed locally on a user's device or workstation. To enable integrations between different applications, a user workstation may be provided with pre-installed copies of the different software applications that will be required, along with plug-ins and additional integration components installed on the workstation to allow communication between the different software applications.

However, this approach can be inflexible, as a clinician may be limited to using only those applications installed on a given workstation. This approach also requires the workstation to have significant memory resources, particularly when workstations are used by different clinicians. Ensuring that the clinician workstations are continually upgraded to provide the current applications and application versions required by clinicians on an ongoing basis further involves additional time and expense. <CIT> discloses a bridge based communication channel between a web application and a process outside a browser. However, said document fails to discloses the following features of the present invention: the host is launched on demand from both the first healthcare application and from the second healthcare application, the host being launchable in response to determining, by the first health application or the second healthcare application, that communication is to be provided between the first healthcare application and the second healthcare application. Moreover, said document fails to disclose that the host application is configured to generate, after being launched, a local communication server on the healthcare integration device, wherein the local communication server is uninstantiated prior to being generated by the host application.

In a broad aspect of this disclosure, systems and methods for integrating a plurality of healthcare software applications may be provided. A user may initiate one or more software applications required to perform different parts of a healthcare task. The software applications can include both a local application installed on the user's device and a web-based application accessed through a browser. A third host application can be launched in order to facilitate local two-way communication between the local application and the web-based application. This may allow a user to easily and efficiently perform multiple parts of the healthcare tasks. This may also allow different healthcare software applications to be integrated without requiring any plug-ins or other integration components to be installed on the user's device or workstation.

The host application may be launched on demand from the web-based or local application. The host application can dynamically configure a local web server to enable and facilitate two-way communication between the web-based application and the local application directly on the user's device.

In accordance with an aspect of an embodiment of the invention, there is provided a healthcare integration system comprising a host application operating locally on a user computer device; and a first healthcare application, wherein the first healthcare application is accessible through a web-browser application operating on the user computer device; where the host application is launchable on-demand to operate a local communication server on the user computing device, and the host application defines a host application domain for the local communication server; and the local communication server enables two-way communication between the first healthcare application and a second healthcare application that operates locally on the user computing device, where the two-way communication occurs directly on the user computing device.

In the present invention, the first healthcare application includes a host reference that identifies the host application domain of the local communication server, where the host reference is defined in the code of the first healthcare application.

In some embodiments, the host reference further specifies that the host application domain is safe for communication for the first healthcare application.

In the present invention, the host application is launchable from the first healthcare application.

In the present invention, the host application is launchable from the second healthcare application.

In some embodiments, the first healthcare application omits the need for any plug-ins or components that are installed locally on the user computing device.

In some embodiments, the first healthcare application omits any plug-ins or components specific to the second healthcare application.

In some embodiments, the host application is built using a Java stack.

In some embodiments, the host application is configured to determine the ports usable for the host application domain of the local communication server dynamically in response to being launched.

In accordance with an embodiment of the invention, there is provided a method of integrating healthcare applications, the method comprising: operating a first healthcare reporting application through a web-browser application operating on a user computing device; operating a second healthcare reporting application that is installed locally on the user computing device; launching a host application to operate on the user computing device; generating, by the host application, a local communication server operating on the user computing device; defining a host application domain for the local communication server; and operating the local communication server to enable two-way communication between the first healthcare reporting application and the second healthcare reporting application directly on the user computing device.

In some embodiments, the first healthcare reporting application includes a host reference that identifies the host application domain of the local communication server, where the host reference is defined in the code of the first healthcare reporting application.

In some embodiments, the host reference further specifies that the host application domain is safe for communication for the first healthcare reporting application.

In the present invention, the method includes launching the host application in response to a prompt from the first healthcare reporting application.

In the present invention, the method includes launching the host application in response to a prompt from the second healthcare reporting application.

In some embodiments, the first healthcare reporting application omits any plugins or components that are installed locally on the user computing device.

In some embodiments, the first healthcare reporting application omits any plugins or components specific to the second healthcare reporting application.

In some embodiments, the method includes determining, by the host application, the ports usable for the host application domain of the local communication server in real-time in response to being launched.

These and other aspects and features of various embodiments will be described in greater detail below.

For a better understanding of the embodiments described herein and to show more clearly how they may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings which show at least one exemplary embodiment, and in which:.

The drawings, described below, are provided for purposes of illustration, and not of limitation, of the aspects and features of various examples of embodiments described herein. For simplicity and clarity of illustration, elements shown in the drawings have not necessarily been drawn to scale. The dimensions of some of the elements may be exaggerated relative to other elements for clarity.

Various systems or methods will be described below to provide an example of an embodiment of the claimed subject matter. No embodiment described below limits any claimed subject matter and any claimed subject matter may cover methods or systems that differ from those described below. The claimed subject matter is not limited to systems or methods having all of the features of any one system or method described below or to features common to multiple or all of the apparatuses or methods described below. It is possible that a system or method described below is not an embodiment that is recited in any claimed subject matter. Any subject matter disclosed in a system or method described below that is not claimed in this document may be the subject matter of another protective instrument, for example, a continuing patent application, and the applicants, inventors or owners do not intend to abandon, disclaim or dedicate to the public any such subject matter by its disclosure in this document.

Furthermore, it will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments described herein. Also, the description is not to be considered as limiting the scope of the embodiments described herein.

It should also be noted that the terms "coupled" or "coupling" as used herein can have several different meanings depending in the context in which these terms are used. For example, the terms coupled or coupling may be used to indicate that an element or device can electrically, optically, or wirelessly send data to another element or device as well as receive data from another element or device. As used herein, two or more components are said to be "coupled", or "connected" where the parts are joined or operate together either directly or indirectly (i.e., through one or more intermediate components), so long as a link occurs. As used herein and in the claims, two or more parts are said to be "directly coupled", or "directly connected", where the parts are joined or operate together without intervening intermediate components.

It should be noted that terms of degree such as "substantially", "about" and "approximately" as used herein mean a reasonable amount of deviation of the modified term such that the end result is not significantly changed. These terms of degree may also be construed as including a deviation of the modified term if this deviation would not negate the meaning of the term it modifies.

Furthermore, any recitation of numerical ranges by endpoints herein includes all numbers and fractions subsumed within that range (e.g. <NUM> to <NUM> includes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>). It is also to be understood that all numbers and fractions thereof are presumed to be modified by the term "about" which means a variation of up to a certain amount of the number to which reference is being made if the end result is not significantly changed.

The embodiments of the systems and methods described herein may be implemented in hardware or software, or a combination of both. However, preferably, these embodiments are implemented in computer programs executing on programmable computers each comprising at least one module component which comprises at least one processor (e.g. a microprocessor), a data storage system (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. For example and without limitation, the programmable computers (referred to below as computing devices) may be a personal computer, laptop, personal data assistant, and cellular telephone, smart-phone device, tablet computer, and/or wireless device. Program code is applied to input data to perform the functions described herein and generate output information. The output information is applied to one or more output devices, in known fashion.

Each program is preferably implemented in a high level procedural or object oriented programming and/or scripting language to communicate with a computer system. However, the programs can be implemented in assembly or machine language, if desired. Each such computer program is preferably stored on a storage media or a device (e.g. ROM or magnetic diskette) readable by a general or special purpose programmable computer, for configuring and operating the computer when the storage media or device is read by the computer to perform the procedures described herein. The subject system may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner to perform the functions described herein.

Furthermore, the system, processes and methods of the described embodiments are capable of being distributed in a computer program product comprising a computer readable medium that bears computer usable instructions for one or more processors. The medium may be provided in various forms, including one or more diskettes, compact disks, tapes, chips, wireline transmissions, satellite transmissions, internet transmission or downloadings, magnetic and electronic storage media, digital and analog signals, and the like. The computer useable instructions may also be in various forms, including compiled and non-compiled code.

Further, although process steps, method steps, algorithms or the like may be described (in the disclosure and / or in the claims) in a sequential order, such processes, methods and algorithms may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order that is practical. Further, some steps may be performed simultaneously.

When a single device or article is described herein, it will be readily apparent that more than one device / article (whether or not they cooperate) may be used in place of a single device / article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be readily apparent that a single device / article may be used in place of the more than one device or article.

The embodiments described herein provide systems, methods and computer program products for integrating healthcare software application. The term "software application" or "application" refers to computer-executable instructions, particularly computer-executable instructions stored in a non-transitory medium, such as a non-volatile memory, and executed by a computer processor. The computer processor, when executing the instructions, may receive inputs and transmit outputs to any of a variety of input or output devices to which it is coupled. Software applications may include mobile applications or "apps" for use on mobile devices such as smartphones and tablets or other "smart" devices.

A software application can be, for example, a monolithic software application, built in-house by the organization and possibly running on custom hardware; a set of interconnected modular subsystems running on similar or diverse hardware; a software-as-a-service application operated remotely by a third party; third party software running on outsourced infrastructure, etc. In some cases, a software application also may be less formal, or constructed in ad hoc fashion, such as a programmable spreadsheet document that has been modified to perform computations for the organization's needs.

Some software applications may be deployed to and installed on a computing device on which it is to operate. Depending on the nature of the operating system and/or platform of the computing device, an application may be deployed directly to the computing device, and/or the application may be downloaded from an application marketplace. As used herein, software applications that are installed on a computing device prior to use may be referred to as "local" or "native" applications.

Some software applications may be accessed remotely, using other programs that are installed locally on a computing device. For example, some software applications may be accessed through a website or online portal using a browser application that operates locally on a computing device. These "web-based" applications may provide an application environment that operates within the browser application that used to access the corresponding website or portal. In some cases, these web-based applications may require the use of a specific browser application (e.g. Internet Explorer® or Firefox) in order for the web-based application environment to be implemented.

Embodiments described herein can provide systems and methods that allow for integration between a web-based application and a native application on a user's computing device. Embodiments described herein may enable local, two-way communication between the web-based application and the native application without requiring any plug-ins or locally installed components for the web application. The communications between the local application and web application can be facilitated directly on a user's computing device without requiring pre-installation of any software components or plug-ins to provide the two-way communication.

A user may access a first user application in the form of a web-based application through a web-browser application that is installed on the user's computing device. The web-based application may operate entirely within the web-browser application. The web-based application may generate an application environment that is operates contained within the web-browser application used to access the web-based application. In general, the web-based application need not require pre-installation of any plug-ins or components on the user's computing device. Thus, the computing device may omit any plugins or components that are installed locally for the web-based application.

A user may also access a second user application in the form of a local or native application that is installed locally on the user's computing device. The local application may provide a local application environment that operates within the operating systems of the user's computing device. The local application may involve one or more associated processes operating on the computing device that are specific to the local application. The local application environment may be provided by the local user application without requiring any intermediary applications, such as a web browser.

The first user application and the second user application may provide functionality associated with various tasks involved in providing healthcare. The first user application and second user application may each be configured to provide functionality that relates to different aspects of the same patient interaction, such as different types of healthcare reporting tasks (e.g. medical accounting vs. clinical report generation). A user, such as a clinician, may interact with both the first user application and the second user application to perform different tasks involved in the same patient interaction, such as using the local user application to review medical images and generate a report and using the web-based application to record patient interaction data required for accounting reports and tracking.

In some cases, the first user application and the second user application may use and/or require the same information to be input. Accordingly, a user may be required to provide the same information to each application. If a user were required to separately enter the same data in each application, additional time would be required to repeat data entry that otherwise might be used for patient care or analysis of acquired medical images. This may also lead to additional errors in transcription or data entry.

In other cases, data generated by one of the user applications may be usable by the other user application. For instance, the results from analysis performed in an image viewing application may be usable in a reporting or recording application. If a user were required to manually transcribe data between the applications, the time required and the risk of data transcription errors would both increase.

Embodiments described herein may facilitate integrations between different applications used by healthcare providers such as clinicians. In embodiments described herein, communication between a first web-based application and a second locally installed application may be enabled directly on the user's computing device. This direct, local communication may be implemented without the use of plug-ins, which may require additional installation time and memory capacity.

A host application can be configured to operate locally on the user computing device. In some cases, the host application may be installed locally on the computing device. For example, the host application may operate continuously as a background application.

In some cases, the host application may be launched by one of the first user application and the second user application. For example, the user application may include an integration launch input or button in the user interface provided to a user of the computing device. The user may then select the launch button to initiate operation of the host application.

The host application can be configured to generate a local communication server on the computing device. The host application can define a host application domain for the local communication server.

The host application can be configured to communicate with the web-based application and the local application. The web application and local application can communicate with the local communication server through the host application domain. The host application may operate as a local relay between the web-based application and the local application.

The host application may provide two-way communication between the web-based application and the local application directly on the user's computing device (i.e. without requiring transmission through a remote web server and in some embodiments without requiring a plug-in for the web-based application). This can allow data on the first user application and second user application to be synchronized locally and in real-time.

The web-based application can be configured to include a host reference corresponding to the host application. The host reference can identify the host application domain on the user's computing device and specify that the host application domain is safe or approved for communication. The host reference can permit the web-based application to communicate locally with the host application through the local communication server.

In some cases, the host reference may be defined in the code of the web-based application. The code of the web-based application may include a code segment identifying the host reference for the web application. For example, the web-based application may include a reference to the host application in JavaScript.

In some cases, the web-based application may determine the host reference dynamically. For example, the web-based application may determine the host reference using the Internet Protocol (IP) address of the computing device that initiated operation of the web-based application through the browser application. The web-based application can then use the IP address of the requesting computing device to define the host reference for a session of communication between the web-based application and the host application. Depending on the network used by the computing device, the IP address may be an external network address or the IP address may be internal to an organizational network.

Referring now to <FIG>, shown therein is a block diagram of a system <NUM> for providing integrated healthcare applications. System <NUM> includes an application server <NUM> and a user workstation in the form of computing device <NUM>. The workstation <NUM> and server <NUM> can be coupled over a network, such as the Internet. In some cases, the computing device <NUM> and server <NUM> may be connected over an internal organizational network, such as a network configured within a hospital or other healthcare clinic.

The network may be constructed from one or more computer network technologies, such as IEEE <NUM> (Ethernet), IEEE <NUM> and similar technologies. Typically, the connections between computing device <NUM>, server <NUM> and the Internet may be made via a firewall server (not shown).

Computers and computing devices such as device <NUM> and server <NUM> may be connected to the network or a portion thereof via suitable network interfaces. In some cases, the workstation <NUM> and server <NUM> may be located remotely from one another and the workstation <NUM> may connect to server <NUM> via the Internet and/or using networks such as a telecommunications network.

The computing device <NUM> may be a computer such as a smart phone, desktop or laptop computer, which can connect to a network via a wired Ethernet connection or a wireless connection. The computing device <NUM> has a processor <NUM>, a memory <NUM> that may include volatile memory and non-volatile storage, at least one communication interface <NUM>, input devices <NUM> such as a keyboard and trackpad, output devices such as a display device <NUM> and speakers, and various other input/output devices as will be appreciated.

Processor <NUM> is a computer processor, such as a general purpose microprocessor. In some other cases, processor <NUM> may be a field programmable gate array, application specific integrated circuit, microcontroller, or other suitable computer processor.

Processor <NUM> is coupled to display device <NUM>, which is a suitable display for outputting information and data as needed by various computer programs. In particular, display device <NUM> may display graphical user interfaces (GUI) that include application environments with which a clinician may interact. The clinician device <NUM> may execute an operating system, such as Apple iOS™, Microsoft Windows™, GNU/Linux, or other suitable operating system.

Communication interface <NUM> is one or more data network interface, such as an IEEE <NUM> or IEEE <NUM> interface, for communication over a network.

Processor <NUM> is coupled, via a computer data bus, to memory <NUM>. Memory <NUM> may include both volatile and non-volatile memory. Non-volatile memory stores computer programs consisting of computer-executable instructions, which may be loaded into volatile memory for execution by processor <NUM> as needed. It will be understood by those of skill in the art that references herein to workstation <NUM> as carrying out a function or acting in a particular way imply that processor <NUM> is executing instructions (e.g., a software program/application) stored in memory <NUM> and possibly transmitting or receiving inputs and outputs via one or more interface. Memory <NUM> may also store data input to, or output from, processor <NUM> in the course of executing the computer-executable instructions.

Computing device <NUM> may have a number of applications installed locally thereon. Although shown as separate elements, it will be understood that local application <NUM>, browser application <NUM> and host application <NUM> may be stored in memory <NUM>.

The server <NUM> may be a computer such as a desktop or server computer, which can connect to a network via a wired connection (e.g. an Ethernet connection) or a wireless connection. The server <NUM> has a processor <NUM>, a memory <NUM> that may include volatile memory and non-volatile storage, at least one communication interface <NUM>, and a web application <NUM>. The processor <NUM>, memory <NUM>, and communication interface <NUM> may be implemented in generally the same manner as with processor <NUM>, memory <NUM>, and communication interface <NUM> respectively.

Although shown as separate elements, it will be understood that web application <NUM> may be stored in memory <NUM>. Optionally, server <NUM> may include additional input or output devices, although this is not required. As with all devices shown in system <NUM>, there may be multiple servers <NUM>, although not all are shown. In some cases, server <NUM> may be distributed over a plurality of computing devices, for instance operating as a cloud server providing the web application <NUM> as a software as a service (SaaS) application. As with clinician device <NUM>, references to acts or functions by server <NUM> imply that processor <NUM> is executing computer-executable instructions (e.g. a software program) stored in memory <NUM>.

Memory <NUM> may also store a database. In some example embodiments, the database may be a relational database. In other embodiments, the database may be a non-relational database, such as a key-value database, NoSQL database, a graph database, or the like. The database can be used to store data usable by the computing device <NUM>, including medical imaging data such as breast images and associated breast image data and characteristics. The medical imaging data may be stored as a plurality of medical imaging records, which may include medical imaging records for one or more patients. The medical imaging data may be stored in various formats, such as using a DICOM (Digital Imaging and Communications in Medicine) image format. The medical imaging data may be generated by radiological and other imaging procedures (e.g. ultrasound images, CT scans, MRIs X-rays etc.), and may also include markers and/or standardized codes such as codified markers defined using national/international standards (e.g. HL7, DICOM).

As noted above, a browser application <NUM> may be stored on the workstation <NUM>. Although shown separately from memory <NUM>, it will be understood that browser application <NUM> may be stored in memory <NUM>. In general, browser application <NUM> may be implemented using any software application that enables a user to access websites over a network such as the Internet. The browser application <NUM> may also be used to access sites and applications that are internal to an organizational network such as sites provided on an intranet. In general, the browser application <NUM> can be configured to enable a user of computing device <NUM> to access and launch web application <NUM> through an internal network such as an organizational intranet or an external network such as the Internet.

For example, browser application <NUM> may be implemented using browser applications such as Internet Explorer®, Mozilla Firefox, Google Chrome®. In some cases, a particular browser application (e.g. Internet Explorer®) may be required to access a given web application <NUM>. Although only one browser application <NUM> is shown, it will be understood that two or more browser applications <NUM> may be installed and operable on the computing device <NUM>. When browser application <NUM> is launched, an instance of a browser application process may be instantiated on computing device <NUM>. The number of instances of browser application processes that are instantiated for a given browsing session may vary depending on the browser application (e.g. some browser application may instantiate separate processes for each browser tab, while other browser application may instantiate only a single browser process even for multiple browser tabs).

A local user application <NUM> may also be stored on the workstation <NUM>. Although shown separately from memory <NUM>, it will be understood that local application <NUM> may be stored in memory <NUM>. The local user application <NUM> generally refers to an application that is pre-installed in memory <NUM> and can operate locally on the workstation <NUM>. A user may launch the local user application <NUM> without an intermediary application, such as a browser. Launching local user application <NUM> may also involve instantiating an instance of a local application process on the computing device <NUM>. The local user application <NUM> may then provide the user with an interaction environment configured to provide functionality related to an aspect of a healthcare task being performed.

The local user application <NUM> may be configured to provide various functions associated with healthcare operations and tasks. For example, the local user application <NUM> may be configured to provide functionality associated with healthcare reporting, image viewing, artificial intelligence processing and so forth. In some cases, there may be a plurality of local user applications <NUM> installed on device <NUM>. Each of the local user applications may be configured with different functionality to enable a user to perform various different tasks by selecting the appropriate local user application. This may also allow different users to perform tasks associated with their particular area of practice, which may allow clinicians having different specialties to share workstation <NUM>.

As one example, the local user application <NUM> may be an image viewing application. An image viewing application may provide a user of the workstation <NUM> with user interfaces for managing and reviewing medical image data stored in memory <NUM> and retrieved from a remote imaging server and/or archive database. The image viewing application may communicate with a remote imaging server (e.g. an imaging database stored in memory <NUM> on server <NUM>) to request and receive medical image data from the server. A user may interact with an image viewing application to review medical images acquired from a patient or patients. In some cases, the user may annotate the medical images or define notes or other data associated with the reviewed medical images.

As another example, the local user application <NUM> may be a healthcare reporting application. For instance, the local user application <NUM> may be a PowerScribe application. A user may interact with the PowerScribe application on the computing device <NUM> to perform radiology reporting tasks. The reporting application may be configured to enable a user to input data collected from a patient, and/or review data (e.g. studies) associated with a patient, in order to generate a report regarding the patient interaction or prognosis for example.

The data generated by the local user application <NUM> may be stored using defined communication protocols. For instance, medical imaging data used by an image viewing application may be stored as a plurality of medical imaging records, which may include medical imaging records for one or more patients. The medical imaging data may be stored in various formats, such as using a DICOM (Digital Imaging and Communications in Medicine) image format. The medical imaging data may be generated by radiological and other imaging procedures (e.g. ultrasound images, CT scans, MRls X-rays etc.), and may also include markers and/or standardized codes such as codified markers defined using national/international standards (e.g. HL7, DICOM).

As noted above, web application <NUM> may be provided by an application server <NUM>. The web application <NUM> may be provided as a cloud application accessible to the workstation <NUM> over an internal organizational network or through an external network such as the Internet. Various different types of software applications used in healthcare may be provided as cloud applications or Software-as-a-Service (SaaS).

A user can interact with browser application <NUM> operating on computing device <NUM> to navigate to a website or portal associated with the web application <NUM>. The user may then select or launch the web application <NUM> within the browser application <NUM>. The web application <NUM> can then provide an interactive user environment to the user through browser application <NUM>. The web application <NUM> may depend on the browser application <NUM> to enable the interactive user environment of web application <NUM> to be provided. The web application <NUM> can operate as a transient application on computing device <NUM>. The web application <NUM> may not require any application instructions to be stored in non-volatile memory of memory <NUM>. This may allow a clinician user of computing device <NUM> to initiate operation of web application <NUM> without requiring administrator privileges and/or pre-installed of web application <NUM> or associated components.

The web application <NUM> can be configured to provide functionality associated with a healthcare tasks or tasks that is different from the functionality provided by local application <NUM>. For example, the web application <NUM> may be an accounting application such as Xero. A user may interact with the accounting application to track tasks performed in respect of a patient and facilitate billing.

In some cases, it may be desirable for the local application <NUM> and the web-based application <NUM> to share and/or synchronize date. For example, an application such as an accounting application may use data from a clinical reporting application to determine the tasks that need to be billed. In other cases, a reporting application may share data with an image viewing application to perform functions such as identifying and tracking pathologies and/or monitoring treatment plans.

In some cases, real-time synchronization between the web application and the local application may be provided. Real-time synchronization may be useful to ensure that measurements on images are identified correctly. Real-time data synchronization may also be important to ensure that the user is reviewing the correct study and/or report. For example, where one of the applications is a report application and the other application is an image viewing application, and a user changes the study being reviewed in the image application a notification may be provided to indicate that that the report and images are no longer synchronized. In some cases, real-time synchronization may also ensure that the local application and web application perform certain functions in tandem to avoid loss of synchronization (e.g. updates, close report, report complete, next image operations).

In order to ensure that the local application <NUM> and web-based application <NUM> can share and/or synchronize data, the system <NUM> can include a host application <NUM>. The host application <NUM> can operate on the computing device <NUM> to facilitate communication between the local application <NUM> and web-based application <NUM>. The host application <NUM> may enable communication between the local application <NUM> and web-based application <NUM> without requiring the communications to be routed through a remote web server. The host application <NUM> may also enable communication between the local application <NUM> and web-based application <NUM> without requiring a plug-in for the web-based application <NUM>.

In some embodiments, the computing device <NUM> may include a plug-in related to the web-based application, that is nonetheless unrelated to communication between the web-based application <NUM> and the local application <NUM> (and also unrelated to the host application <NUM>). For example, java applets may be used to allow the web-based application <NUM> to operate by supporting operation of web-based application <NUM> (as well as other java applications). In general, however, the embodiments described herein enable an instance of a host application <NUM> to be initiated from the web-based application <NUM> without a plug-in or other locally installed component being used or called by the web-based application <NUM>. The embodiments described herein also enable two-way communication between the web-based application <NUM> and local application <NUM> without any plug-ins or other installed components of the web-based application <NUM> specific to the local application <NUM>.

The host application <NUM> can be configured to generate a local communication server. The local communication server can be generated to operate locally on the computing device <NUM>. The local communication server can enable two-way communication between the local application <NUM> and web-based application <NUM> directly on the computing device <NUM>.

The web-based application <NUM> can be configured to communicate with the local communication server. Similarly, the local application <NUM> can be configured to communicate with the local communication server. Communications between the web-based application <NUM> and the local application <NUM> can be routed through the local communication server. This may allow two-way communication between web application <NUM> and local application <NUM> without requiring data transmissions to remote servers, e.g. without requiring data transmissions to server <NUM>.

Running host application <NUM> on computing device <NUM> may involve launching a separate process on the computing device <NUM>. This can ensure that the host application <NUM> is locally addressable on computing device <NUM>. The locally running host process may provide a local server address that can be communicated directly using http calls to the address defined by the process (e.g. http://localhost:port).

As shown, the host application <NUM> may be installed on computing device <NUM>. Thus, the host application <NUM> can be instantiated directly on computing device <NUM>. For instance, the host application <NUM> may operate as a background application on computing device <NUM>. When operating as a background application, the host application <NUM> may determine that a session of web-based application <NUM> has been initiated that may require communication/synchronization with a local application <NUM>. The host application <NUM> may then generate a local server to enable communication between the web-based application <NUM> and the local application <NUM>. The web-based application <NUM> and local application <NUM> may transmit and receive data via the local server that allows for data and/or actions to be synchronized between the web-based application <NUM> and local application <NUM>.

In some embodiments, host application <NUM> may not be pre-installed on computing device <NUM>. For example, host application <NUM> may be launched by the web-based application <NUM>. Additionally or alternatively, the host application <NUM> may be launched by the local application <NUM>.

One or both of the web-based application <NUM> and the local application <NUM> may include a selectable user interface icon that allows a user to manually initiate operation of the host application <NUM>. The host application <NUM> may be launched on-demand in response to a user selecting the launch button in the user interface of either the web-based application <NUM> or the local application <NUM>.

In some embodiments, the web-based application <NUM> may be configured to automatically launch the host application <NUM>. For instance, web-based application <NUM> may determine that synchronization with local application <NUM> is desired based on user interactions within the web-based application <NUM>. The web-based application <NUM> may then launch the host application <NUM> to facilitate synchronization. Additionally or alternatively, the local application <NUM> may be configured to automatically launch the host application <NUM>. This may allow the local communication server to be instantiated on-demand as needed to provide communication or synchronization between local application <NUM> and web application <NUM>.

The local communication server need not be installed or persistent on local computing device <NUM> prior to being instantiated. For example, host application <NUM> may operate the local communication server as a transient application on computing device <NUM>. This may facilitate activation of the local communication server by a clinician user that may not have elevated privileges on computing devices <NUM> (e.g. administrator access that may otherwise be required to install a new application on device <NUM>). Operating the local communication server as a transient application may also allow the application to be instantiated on computing device <NUM> rapidly. This may facilitate initiating a synchronization process as well as re-loading the local communication server in case of a crash.

In some cases, the web-based application <NUM> may be configured to cause the local application <NUM> to be launched. For example, a user may select a synchronization icon within the environment of the web-based application <NUM>. The web-based application <NUM> may then communicate with, or launch, host application <NUM> to determine whether the local application <NUM> is operating on the computing device <NUM>. If an instance of the local application <NUM> is currently operational, the host application <NUM> may then provide communication between the web-based application <NUM> and local application <NUM>. If an instance of the local application <NUM> is not currently operational, the host application <NUM> may initiate an instance of local application <NUM>. The host application <NUM> may then facilitate communications and synchronization once local application <NUM> is running.

The host application <NUM> can define a host application domain for the local communication server. The local application <NUM> and web application <NUM> can be configured to identify the address space of the host application domain as suitable for communication.

The web application <NUM> can include a host reference identifying the host application domain of the local communication server. In some cases, the host reference may be defined in the code of the web application <NUM>. In other cases, the host reference may be defined dynamically. For instance, the web application <NUM> may include a script that, when run, can be used to define the host reference identifying the host application domain. This host reference script can specify that the host application domain is safe for the web application <NUM> to interact with.

For example, the host reference script in web application <NUM> may rely on device address data from computing device (such as the internal or external IP address and/or hostname of the end user's workstation <NUM>) when identifying the host application domain of the local communication server. The device address data may be used or provided by computing device <NUM> when accessing web application <NUM> through browser application <NUM>.

In some cases, the host application <NUM> may determine the ports usable for the host application domain of the local communication server once the host application <NUM>. The usable ports may be determined dynamically by the host application <NUM> in response to being launched. In other cases, a specified port or ports may be reserved for the local communication server e.g. where the host application <NUM> operates as a background application on computing device <NUM>.

The host application <NUM> may also be configured to facilitate communications between applications regardless of the operating system that is implemented on computing device <NUM>. The host application <NUM> can be configured to use platform neutral or platform independent communication protocols to allow two-way communication between the web application <NUM> and a local application <NUM> that is installed on computing device <NUM>, in various different operating systems. This may facilitate operation of the host application <NUM> without requiring specific plug-ins or extensions to be installed on computing device <NUM>.

For example, the host application <NUM> configure the local communication server to communicate using the Hypertext Transfer Protocol (HTTP). Since most if not all implementations of browser applications <NUM> are configured to support HTTP communication, this may ensure that web application <NUM> can communicate with the local communication server regardless of the specific browser that is operating on computing device <NUM>. This may also support communications with older computing device, and facilitate integrations without requiring updates to the hardware or operating system of computing device <NUM>.

The local communication server may also be configured to communicate with the local application <NUM> using HTTP. This may ensure that host application <NUM> can be effectively implemented on computing device <NUM>, for instance where host application <NUM> is launched in response to a trigger from web application <NUM>.

In some embodiments, the host application <NUM> may be configured using a Java stack. This may facilitate operation of host application <NUM> on various different operating systems for computing device <NUM> (e.g. Windows, Macintosh, Linux etc.) without requiring specific plug-ins or extensions to be installed on computing device <NUM>. This may also facilitate operation of host application <NUM> on legacy systems that may use older operating systems.

In other cases, the host application <NUM> may be configured using different software frameworks or programming languages, such as the. NET framework. In some such cases, the host application <NUM> may be specifically defined for an operating system that is running on computing device <NUM>.

The application server <NUM> and clinician device <NUM> may have various additional components not shown in <FIG>. For example, additional input or output devices (e.g., keyboard, pointing device, etc.) may be included beyond those shown in <FIG>.

It should be understood that the system <NUM> may be implemented in hardware or software or a combination of both. Specifically, various modules of medical system <NUM> are preferably implemented in computer programs executing on programmable computers, each comprising at least one processor, a data storage system, at least one input device and at least one output device. Without limitation, the programmable computers may be a mainframe computer, server, personal computer, laptop, personal data assistant, cellular telephone, smartphone or tablet device.

Referring now to <FIG>, shown therein is a flowchart illustrating an example method <NUM> for providing integration between healthcare software applications. Method <NUM> is an example of a method that may be performed by a healthcare integration system such as system <NUM>.

At <NUM>, a first healthcare application can be operated on the computing device <NUM>. The first healthcare application may be a web-based application that operates through a web-browser application that is operating on the user device <NUM>. A user of computing device <NUM> may interact with the web-browser application to access the first healthcare application. The first healthcare application may then provide a web-based user environment within the browser application.

The first healthcare application may provide functionality associated with one or more tasks to be performed in relation to providing healthcare. For instance, the first healthcare application may provide a clinician with functionality related to recording or tracking patient interactions, such as reviewing patient records and/or conducting billing for patient interactions and other tasks.

The first healthcare application may operate within the browser application without requiring any plug-ins or locally installed components. In some cases, the computing device <NUM> may not include any plug-ins, locally installed components, extensions, and so forth specific to the first healthcare application.

At <NUM>, a second healthcare application can be operated on the computing device <NUM>. The second healthcare application may be a local or native application that is installed on the user device <NUM>. A user of computing device <NUM> may instantiate the second healthcare application by selecting an icon or other link within the operating system environment of the computing device <NUM>.

The second healthcare application may also provide functionality associated with one or more tasks to be performed in relation to providing healthcare. For instance, the second healthcare application may provide a clinician with functionality related to reviewing medical images or tracking patient interactions, such as reviewing patient records and/or generating clinical reports and other tasks. Typically, the functionality provided by the second healthcare application will differ from the functionality provided by the healthcare application. That is, the second healthcare application may provide functionality related to a different aspect of a healthcare interaction or task.

At <NUM>, a host application can be launched on the user computing device <NUM>. In some cases, a user may launch the host application through the first healthcare application or second healthcare application by selecting an interface item within the environment of the healthcare application. In other cases, the host application may be launched automatically by the first healthcare application or second healthcare application when the respective healthcare application determines that synchronization between the first and second healthcare application is desirable or required.

For example, the host application may be defined using Java. The first healthcare application may include a java network launch protocol corresponding to the host application (netboot. The launch protocol may be associated with a launch icon selectable by a user, or with trigger conditions defined in the first healthcare application specifying when the host application is to be launched. The JNLP protocol can then be used to launch the host application on the computing device <NUM> from the first software application operating in the browser application on computing device <NUM>. The host application may then operate as a local or native application running on computing device <NUM>.

In some cases, the host application may operate continuously as a background application on computing device <NUM>. The host application may then be activated in response to a trigger (manual or automatic) from the first healthcare application or second healthcare application.

The host application can operate locally on the computing device <NUM>. A host application process may be instantiated on computing device <NUM> when the host application is launched.

In some cases, a user of the computing device <NUM> may launch the second healthcare application through interaction with the first healthcare application. For example, a user may select a synchronization function corresponding to the second healthcare application within the environment of the first healthcare application. The first healthcare application may then communicate with the host application (and in some cases also launch the host application) to initiate the second healthcare application locally on the computing device <NUM>.

In response to a request from the first healthcare application, the host application may determine whether the second healthcare application is currently operating on the computing device <NUM>. If the second healthcare application is not yet active, the host application may launch the second healthcare application on computing device <NUM>.

At <NUM>, the host application can generate a local communication server. The local communication server can be configured to operate locally on the computing device <NUM>. The local communication server can provide an intermediary with which both the first and second healthcare applications can communicate in order to provide two-way communication between the first and second healthcare applications locally on the computing device <NUM>. This may provide direct communication between a local application and web-based application without requiring plug-ins or extensions or transmissions to remote application servers.

At <NUM>, a host application domain can be defined for the local communication server. The host application domain can be defined by the host application when the local communication server is initially configured.

In some cases, when generating the local communication server, the host application may determine the ports usable by the local communication server. The usable ports may be determined dynamically, and in real-time, in response to the host application being activated to generate the local communication server.

In some cases, the usable ports may be pre-defined or reserved for the local communication server. For instance, where the host application operates continuously as a background application on the computing device <NUM> the ports usable by the local communication server may be reserved.

The first healthcare application can be configured to communicate with the host application domain of the local communication server. For example, the first healthcare application may include a host reference that is defined in code that identifies the host application domain. The host reference may further specify that the first healthcare application is permitted to communication with the host application domain. For instance, the host reference may be defined in JavaScript in the first healthcare application.

In some cases, the host reference in the first healthcare application may identify the host application domain dynamically. For example, the host reference may include a script usable to identify the host application domain that is generated for the local communication server. The web application may use the IP address (internal or external) of the computing device <NUM> that accessed the web application through the browser in order to determine the host application domain. For example, the web application may use Cross-Origin Resource Sharing (CORS) to dynamically identify the host application domain.

At <NUM>, the local communication server can operate to enable two-way communication between the first healthcare application and the second healthcare application. The local communication server may allow the first healthcare application and the second healthcare application to transmit and receive data from on another directly on the computing device <NUM>. This may facilitate real-time updates and synchronization between the first healthcare application and the second healthcare application.

The local communication server may be configured to transmit data to each of the first healthcare application and the second healthcare application using platform-independent communication protocols. For example, the local communication server may use the Hypertext Transfer Protocol (HTTP) to transmit data to and from each of the first healthcare application and the second healthcare application. This may allow the web application and local application to synchronize while operating on various different browser applications and operating systems.

Referring now to <FIG>, shown therein is an example system <NUM> illustrating data flow between a user interface <NUM>, a web application <NUM>, a host application <NUM> and a local application <NUM>. The system <NUM> illustrates an example of data flow that occurs when application integration between a web-based application <NUM> and a local application <NUM> is launched from the web-based application <NUM>.

The web application <NUM>, host application <NUM> and local application <NUM> may generally correspond to the web application <NUM>, the host application <NUM> and the local application <NUM>. The user interface <NUM> may be provided in various forms by the computing device <NUM> and may include the display <NUM>, input device <NUM> and various other types of input and/or output devices.

As shown in system <NUM>, an integration request <NUM> may be sent from user interface <NUM> to web application <NUM>. The integration request <NUM> may be sent in response to a user selecting an integration icon within the environment of the web application <NUM> that is displayed in a browser application <NUM> operating on the computing device <NUM>. The integration request <NUM> may specify to the web application <NUM> that integration with a specified local application <NUM> should be initiated.

The web application <NUM> may then transmit a host launch message <NUM> to user interface <NUM> (i.e. to computing device <NUM>). In some cases, the host launch message <NUM> may instruct the computing device <NUM> to activate a host application <NUM> that is already installed on computing device <NUM>.

In other cases, however, the host launch message may include host application data that can be downloaded to the computing device <NUM>. The computing device <NUM> may use the host application data to instantiate an instance of the host application <NUM>. For example, the host launch message may include a java network launch protocol usable to instantiate the host application <NUM> as a temporary application on computing device <NUM>. The host application <NUM> may then generate a local communication server that operates on computing device <NUM>.

The web application <NUM> can also transmit a host reference message <NUM> to the host application <NUM>. The host reference message <NUM> may specify that the host application <NUM> is included as a "safe" Javascript provider for the host application <NUM>.

The host application <NUM> can also determine whether the local application <NUM> is operational on the computing device <NUM>. If the local application <NUM> is not currently operational (i.e. there is no instance of local application <NUM> currently running on the computing device <NUM>), the host application <NUM> may transmit a launch and authenticate message <NUM> to the local application <NUM>. The launch and authenticate message <NUM> may configure computing device <NUM> to launch an instance of local application <NUM>, and to authenticate the local application <NUM> with the local communication server. The local communication server may then provide communication between local application <NUM> and web application <NUM>, an example of which is shown in <FIG> and described herein below.

Table <NUM>, below, provides an example of pseudo-code that may be used to provide the data transmissions shown in <FIG>.

Referring now to <FIG>, shown therein is another example system <NUM> illustrating data flow between a user interface <NUM>, a web application <NUM>, a host application <NUM> and a local application <NUM>.

The system <NUM> illustrates an example of data flow that occurs when application integration between a web-based application <NUM> and a local application <NUM> is occurring on an on-going basis. System <NUM> illustrates an example of application integration between a web-based application <NUM> used to review medical images and a local application <NUM> used to generate clinical reports. The data flow shown in system <NUM> may occur repeatedly while a user is interacting with web application <NUM> and local application <NUM>. For example, the data flow shown in system <NUM> may occur once for each synchronization action, such as once for each patient study that is being reported.

A study request message 351a can be transmitted from the user interface <NUM> to the web application <NUM>. For instance, a user may select a study for which the user will generate a report. The study request message 351a can include identifying data associated with the requested study, such as patient identifier data, image type, image date and so forth. The user may select an icon corresponding to that study within the interface of the web application <NUM>.

The web application <NUM> can then transmit a relayed study request message 351b to the local communication server generated by host application <NUM>. The relayed study request message 351b can also include the identifying data associated with the requested study. The host application <NUM> can then transmit a further relayed study request message 351c to the local application <NUM>. The study request message 351c also includes study identifying data associated with the requested study.

In response to receiving the study request message 351a, the web application <NUM> can access study data at 353a that corresponds to the requested study. The web application <NUM> can open or access the study data within the environment of the web application <NUM> for review by a user.

Similarly, the local application <NUM> can also access study data at 353b that corresponds to the requested study in response to receiving the relayed study request message 351c. The local application <NUM> can open or access the study data within the environment of the local application <NUM> for review by a user. The study data accessed, used, or displayed by local application <NUM> and web application <NUM> may differ.

For instance, the web application <NUM> may present medical images associated with a study while the local application <NUM> may present patient data and related medical history. The web application <NUM> and local application <NUM> may also provide different interactive functionality. For instance, web application <NUM> may allow a user to review, navigate and annotate medical images associated with the requested study. The local application <NUM> may provide an interactive reporting template that the user can complete in order to generate a clinical report.

In some cases, the user's interactions with web application <NUM> (e.g. annotations or markings in the medical images) may be synchronized with the local application <NUM> (or vice versa). For instance, where a user identifies margins within a medical image in the web application <NUM>, the system <NUM> may be configured to automatically synchronize the evaluated size of the margin with a corresponding field in the interactive template within local application <NUM> via the local communication server provided by host application <NUM>. As will be appreciated, various other types of data synchronization may be performed between the web application <NUM> and local application <NUM>.

The user may interact with both the web application <NUM> and local application <NUM> in order to review medical images and prepare a report. When the user has completed the report, the user may input a finalization message <NUM> to the local application <NUM>. The finalization message <NUM> can indicate to local application <NUM> that the report is complete. In response to the finalization message, the local application <NUM> may store and/or transmit the completed report.

The local application <NUM> can also transmit a report complete message 357a to the local communication server generated by host application <NUM>. The report complete message 357a may include identifying data corresponding to the study selected at <NUM> and to the report that was completed by the local application <NUM>. The communication server can then transmit a relayed completed message 357b to the web application <NUM>.

At <NUM>, the web application <NUM> may refresh the data associated with the study. In some cases, at <NUM>, the web application <NUM> may access a subsequent study. For instance, the user at 351a may indicate a series of studies to be reviewed. In such cases, the web application <NUM> may then access data associated with the subsequent study and transmit a relayed request message 351b related to the subsequent study. The process shown in <FIG> may then be repeated. In other cases, a user may input a separate study request message to select a new or different study to be reviewed and reported.

In response to completion of the report, the local application <NUM> and web application <NUM> may release the data associated with the study. This may allow the study data to be accessed by other clinicians, e.g. where the computing device <NUM> is used in a networked environment.

Claim 1:
A healthcare integration device comprising:
a processor; and
a non-volatile memory coupled to the processor, the non-volatile memory storing instructions executable by the processor to provide one or more applications;
wherein the processor is configured by the instructions to:
operate a host application locally on the healthcare integration device; and
operate a first healthcare application through a web-browser application operating on the healthcare integration device; and
operate a second healthcare application locally on the healthcare integration device and outside the web-browser application environment;
wherein
the host application is launchable on-demand from both the first healthcare application and from the second healthcare application, the host application being launchable in response to determining, by the first healthcare application or the second healthcare application, that communication is to be provided between the first healthcare application and the second healthcare application,
the host application is configured to generate, after being launched, a local communication server on the healthcare integration device, wherein the local communication server is uninstantiated prior to being generated by the host application;
the host application operates outside the web-browser application environment;
the host application defines a host application domain for the local communication server; and
the local communication server enables two-way communication between the first healthcare application and the second healthcare application, wherein the two-way communication occurs directly on the healthcare integration device and
wherein the first healthcare application includes a host reference that identifies the host application domain of the local communication server, wherein the host reference is defined in the code of the first healthcare application.