Computing system for inter-application communication

A computing system for inter-application communication between a client emitter application and a client consumer application executing on a mobile computing device is disclosed herein. The client emitter application receives an indication of a programmatic task to be performed by the client consumer application. The client emitter application transmits data to a server emitter application executing on a first server computing device causing a session token to be generated, the session token indicating that a server consumer application executing on a second server computing device has authenticated the client emitter application. The server emitter application forwards the session token to the client emitter application. The client emitter application includes the session token in a call indicative of the programmatic task to the client consumer application. The client consumer application and the server consumer application authenticate the client emitter application and the client consumer application, respectively, based on the session token. The client consumer application then performs the programmatic task.

BACKGROUND

Electronic health records applications (EHRs) are robust applications that are utilized in medical facilities across a variety of aspects of a medical practice. EHRs are configured with functionality pertaining to patient intake, patient billing, insurance billing, prescription generation, maintaining a record of patient care over time, etc. EHRs are often used by healthcare workers at the point of care (i.e., at a time when the healthcare worker is providing care to a patient). For example, a client EHR executing on a mobile computing device may receive input from a healthcare worker that causes a server-side EHR to retrieve data from a patient record and present the data to the healthcare worker.

A conventional EHR is often configured with modules dedicated to certain functions which enable the EHR to perform the functions. For instance, a conventional EHR may include a module for generating an electronic prescription, a module for obtaining authorization for the electronic prescription from an insurance company, a module for transmitting the electronic prescription to a pharmacy, etc.

Recently, new EHRs have been developed with new architectures that differ significantly from conventional EHR architectures. These new architectures tend to preclude the inclusion of modules into the EHR. Thus, in order to enable a new EHR to have the same functionality as a conventional EHR, the new EHR (or new client EHR) may have to exchange sensitive data (e.g., patient health data) with an application that is external to the new EHR (or new client EHR). For example, a new client EHR executing on a mobile computing device may have to exchange sensitive data (e.g., protected patient health data) with another application also executing on the mobile computing device.

Exchanging data between applications executing on a mobile computing device can come with security risks. For example, a malicious application may be inadvertently installed on the mobile computing device which can intercept data transferred between the applications. In another example, a malicious application can access functionality of an application by performing an unauthorized programmatic call to the application.

Conventionally, there are three approaches used to transfer data between applications executing on a mobile computing device. In a first approach, a third-party application (sometimes referred to as a “broker”) tasked with providing secure transfer of data between applications may be installed on the mobile computing device. The broker application acts as an intermediary between applications and provides for exchange of data between the applications. While broker applications are commonly used, it is highly undesirable to install a third-party application on the mobile computing device and to expose patient health data to the third-party application. In a second approach, the applications may employ a common security subsystem using a common set of keys for encryption and decryption between applications. However, this approach requires that the applications be developed in tandem by a common developer which is often not practical. In a third approach, the applications may both utilize a shared, secured storage area of the operating system of the mobile computing device to store access credentials. This approach is also problematic as it requires exposing patient health data to the operating system of the mobile computing device. Thus, none of these approaches provide sufficient security for transferring patient health data between applications executing on a mobile computing device.

SUMMARY

Described herein are various technologies related to inter-application communication between applications executing on a mobile computing device. More specifically, the technologies described herein enable a client emitter application executing on a mobile computing device to securely transfer data to a client consumer application also executing on the mobile computing device.

The client emitter application executing on the mobile computing device receives an indication of a programmatic task to be performed by the client consumer application that also executes on the mobile computing device. Responsive to receiving the indication, the client emitter application transmits an emitter-device identifier and user metadata to a server emitter application executing on a first server computing device that is in network communication with the mobile computing device. The emitter-device identifier identifies the mobile computing device executing the client emitter application and the user metadata is a set of attributes for a user of the mobile computing device identifying the user in an organization.

The server emitter application causes a session token to be generated based upon the emitter-device identifier and the user metadata. The session token indicates that the emitter-application has been authenticated by a server consumer application executing on a second server computing device that is in network communication with the mobile computing device. The first server computing device and the second server computing device are also in network communication. The server emitter application additionally causes the first server computing device to transmit the session token to the mobile computing device, whereupon the session token is received by the client emitter application.

Responsive to receiving the session token from the server emitter application, the client emitter application performs a call to the client consumer application. The call comprises the session token and is indicative of the programmatic task. The call may also comprise patient data for a patient (e.g., protected patient health data). The client consumer application then authenticates the client emitter application based on the session token. Responsive to the client consumer application authenticating the client emitter application, the server consumer application authenticates the client consumer application based on the session token. Responsive to authentication of the client consumer application by the server consumer application, the client consumer application performs the programmatic task.

The above-described technologies enable the client emitter application to securely exchange data (e.g., patient data) with the client consumer application. Moreover, the above-described technologies do not require the use of a third-party application (broker), the use of a common security subsystem, or exposing the data itself to an operating system of a mobile computing device. Thus, the above-described technologies are well-suited for securely transferring protected patient health data between applications executing on the mobile computing device.

DETAILED DESCRIPTION

With reference toFIG. 1, an exemplary computing system100that facilitates inter-application communication is illustrated. The computing system100includes a mobile computing device102. In a non-limiting example, the mobile computing device102can be a tablet computing device or a smartphone. The mobile computing device102comprises a processor104and memory106, wherein the memory106has a client emitter application108and a client consumer application110loaded therein. In an example, the client emitter application108can be a client EHR application and the client consumer application110can be a prescription generation application. The mobile computing device102may also include a display112, wherein graphical features114can be presented thereon. The mobile computing device102may also include components suitable for data input (not shown), such as a touchscreen, mouse, keyboard, microphone, camera, video camera, etc.

The computing system100may further include a first server computing device118and a second server computing device122. The first server computing device118, the second server computing device122, and the mobile computing device102are in communication by way of a network116(e.g., the Internet, intranet, etc.). The first server computing device118comprises a processor and memory (not shown), wherein the memory includes a server emitter application120for the client emitter application108. The second server computing device122comprises a processor and memory (not shown), wherein the memory includes a server consumer application124for the client consumer application110. The first server computing device118and the second server computing device122may also comprise data stores (not shown). The server emitter application120is tasked with communicating with the client emitter application108and the server consumer application124. The server consumer application124is tasked with communicating with the client consumer application110and the server emitter application120.

While the server emitter application120and the server consumer application124have been described as executing on separate server computing devices, it is understood that in some embodiments the server emitter application120and the server consumer application124may execute on the same computing server computing device.

The computing system100may also include a shared authorization subsystem126in communication with the first server computing device118and the second server computing device122by way of the network116. The shared authorization subsystem126may aid in the authenticating process described below by supporting authorization and authentication operations such as via Security Assertion Markup Language (SAML) or OAuth. It is to be understood that the shared authorization subsystem126is optional and that the functionality described herein can be accomplished without the use of the shared authorization subsystem126.

FIGS. 2 and 3are control flow diagrams that illustrate operation of the computing system100. While the control flow diagrams are shown and described as being a series of steps that are performed in a sequence, it is to be understood and appreciated that the operation of the computing system100is not limited by the order of the sequence. For example, some steps can occur in a different order than what is described herein. In addition, a step can occur concurrently with another act. Further, in some instances, not all steps may be required in the operation of the computing system100described herein.

Referring now toFIG. 2, an exemplary control flow diagram200for registering the client emitter application108and the client consumer application110is illustrated. At202, the client emitter application108may receive input via a user interface of the client emitter application108causing the client emitter application108to transmit an emitter-device identifier and user metadata for a user to the server emitter application120. The emitter-device identifier identifies the mobile computing device102executing the client emitter application108. The user metadata is a set of attributes that identifies a user of the mobile computing device102within an organization. For instance, the user metadata may include an identifier for an organization of the user, an identifier for a vendor of the client emitter application108and/or the client consumer application110, an identifier for a practice group of a user within an organization, etc. The client emitter application108may also transmit a callback to the server emitter application120along with the emitter-device identifier. The callback is a string that is indicative of a programmatic task to be performed by the client consumer application110after the client consumer application110performs another programmatic task. For instance, the callback may be executed by the client consumer application110causing program control to be returned to the client emitter application108.

Responsive to receiving the emitter-device identifier and the user metadata (and optionally, the callback), the server emitter application120may retrieve an emitter-application identifier from a third server computing device (not shown) that is configured to retain identifier for applications that are able to be installed on mobile computing devices. In an embodiment, the emitter-application identifier may already be present in a data store of the first server computing device118and hence the server emitter application120need not retrieve the emitter-application identifier. The emitter-application identifier identifies the client emitter application108and is a different identifier than the emitter-device identifier. In an embodiment, the emitter-application identifier may be provided by an operating system of the mobile computing device102. At204, the server emitter application120then transmits the emitter-device identifier, the emitter-application identifier, the user metadata, and optionally the callback to the server consumer application124(collectively referred to as “the registration attributes”). The server consumer application124may verify that the client emitter application108has not already been registered using the registration attributes by executing a search over registration attributes for a plurality of mobile devices based on the emitter-device identifier. In the event that the search indicates that client emitter application108is already registered, the server consumer application124will transmit a message to the server emitter application indicating that registration has already been completed. The server emitter application120may then forward the message to the client emitter application108and the registration process will terminate.

After verifying that the client emitter application108does not have a valid registration, the server consumer application124stores the registration attributes in a data store accessible to the server consumer application124. The server consumer application124also generates a registration key based on at least a portion of the registration attributes. The registration key may comprise a public portion and a private portion. The public portion of the registration key may include the emitter-application identifier. The private portion of the registration key may include an encrypted version of the emitter-application identifier (an “encrypted emitter-application identifier”) that has been encrypted by the server consumer application124. The private portion of the registration key may also include a pointer to a location in the data store where the registration attributes are stored.

At206, the server consumer application124transmits the registration key to the server emitter application120. At208, the server consumer application124forwards the registration key to the client emitter application108. At210, the client emitter application108performs a registration call to the client consumer application110. The registration call includes the registration key and the emitter-application identifier. The client consumer application110then validates the client emitter application108by confirming that the emitter-application identifier in the call and the emitter-application identifier in the public portion of the registration key match.

At212, responsive to validating the client emitter application108, the client consumer application110transmits the registration key and a consumer-device identifier to the server consumer application124. The consumer-device identifier identifies the mobile computing device102executing the client consumer application110. Responsive to receiving the registration key and the consumer-device identifier, the server consumer application124validates the registration key by comparing the public and private portions of the registration key to the registration attributes stored in the data store (described above). Responsive to validating the registration key, the server consumer application124stores the consumer-device identifier along with the registration attributes in the data store such that the consumer-device identifier is now included in the registration attributes in the data store. The server consumer application124may also generate a salt to be included and stored with the registration attributes.

The server consumer application124may then generate secret data from the registration attributes using a cryptographic function. The secret data itself is not stored in the data store. However, since the registration attributes are stored in the data store, the server consumer application124can regenerate the secret data from the registration attributes stored in the data store at a later time using the cryptographic function. At214, the server consumer application124transmits the secret data to the client consumer application110. The client consumer application110stores the secret data in a secure memory location on the mobile computing device102. The secret data may be indexed by the emitter-application identifier such that the client consumer application110may retrieve the secret data based on the emitter-application identifier. The client consumer application110may then present a message to a user of the mobile computing device102that the client emitter application108and the client consumer application110have been registered.

Registration of the client emitter application108and the client consumer application110may be valid for 10 to 180 days. For instance, the registration may be valid for 20 to 150 days, 40 to 110 days, or 90 to 100 days. After registration expires, the above-described process can be repeated in order to re-register the client emitter application108and the client consumer application110. Thus, it is to be understood that the registration attributes may also include a time range for which the registration is valid. Furthermore, it is to be understood that the registration key may be single-use.

Turning now toFIG. 3, an exemplary control flow diagram300for inter-application communication after the client emitter application108and the client consumer application110are registered (described above in the description ofFIG. 2) is illustrated. At302, responsive to receiving an indication of a programmatic task to be performed by the client consumer application110, the client emitter application108transmits the emitter-device identifier and the user metadata (described above) to the server emitter application120. As used herein, the term “programmatic task” refers to one or more computer-executable instructions that are executed by a processor of a computing device that cause the processor perform one or more actions. In an example, the programmatic task may include the client consumer application110generating an electronic prescription using patient health data received from the client emitter application108. The client emitter application108may also transmit patient data for a patient along with the emitter-device identifier. For instance, the patient data may include protected patient health information for the patient. Responsive to receiving the emitter-device identifier and the user metadata, the server application120then retrieves the emitter-application identifier (described above).

Steps304-316cause a session token to be generated and received by the client emitter application108. At304, the server emitter application120transmits a request for an emitter token to the shared authorization subsystem126. The request includes the user metadata and a data context. The data context may include a token (e.g., a Security Assertion Markup Language (SAML) token) generated by the server emitter application120in an embodiment where the shared authorization subsystem is configured to receive tokens generated by the server emitter application120. Responsive to receiving the request, the shared authorization subsystem126generates an emitter token. The emitter token may include assertions, the user metadata, and the data context. The assertions may be used by the server consumer application124in order to verify the identity of the user. At306, the shared authorization subsystem126transmits the emitter token to the server emitter application120.

In an embodiment, the server emitter application120may generate the emitter token without the use of the shared authorization subsystem126. For instance, the server emitter application120may utilize a local identity provider (local idP) and/or a trusted certificate in order to generate the emitter token. More specifically, the server emitter application120can generate the emitter token using the local idP and sign the emitter token using the trusted certificate. The server consumer application124can then be configured to trust the trusted certificate used to generate the emitter token. Thus, it can be ascertained that steps304and306are optional.

At308, responsive to receiving (or generating) the emitter token, the server emitter application120transmits the emitter token, the user metadata, the emitter-device identifier, and the emitter-application identifier to the server consumer application124. In an embodiment, the emitter token, the user metadata, the emitter-device identifier, and the emitter-application identifier may be transmitted in SAML format. Responsive to receiving the emitter token, the user metadata, the emitter-device identifier, and the emitter-application identifier, the server consumer application124validates the emitter-device identifier and the emitter-application identifier against the emitter-device identifier and the emitter-application identifier stored in the data store (as part of the registration data, described above). The server consumer application124may also verify that the registration for the client emitter application108has not expired by reading a time range included in the registration data. In the event that registration for the client emitter application108has expired, the server consumer application124will transmit a message to the server emitter application120indicating that re-registration of the client emitter application108is required. The server emitter application120will then forward the message to the client emitter application108, and the client emitter application108can begin the registration process described above inFIG. 2. The server consumer application124also validates the assertions in the emitter token using the user metadata.

At310, the server consumer application124may transmit the emitter token to the shared authorization subsystem126. The shared authorization subsystem126then authenticates the emitter token. At312, responsive to authenticating the emitter token, the shared authorization subsystem126transmits the emitter token back to the server consumer application124. As mentioned previously, use of the shared authorization subsystem126is optional. Thus, it can be ascertained that steps310and312are optional.

Responsive to receiving (authenticated) emitter token from the shared authorization subsystem126, the server consumer application124regenerates the secret data using the registration attributes stored in the data store by applying the same cryptographic function to the registration attributes used in the registration process described above. The server consumer application124then generates a session token comprising a public portion and a private portion. The public portion includes the emitter-application identifier. The private portion includes an encrypted version of the emitter-application identifier that is encrypted by the server consumer application124using the secret data. The session token may additionally include a signature from the server consumer application124, wherein the signature identifies the server consumer application124. In an embodiment, the session token may be wrapped in Extensible Markup Language (XML). The session token may be valid for a relatively short time range, such as 1 to 5 minutes. For example, the session token may be valid for 1.5 to 4.5 minutes, 2 to 4 minutes, or 3 to 3.5 minutes. In the event that the session token is not used by the client emitter application108and/or the client consumer application110(described below) within the time range, steps302-316may be repeated in order to regenerate the session token.

At314, responsive to generating the session token, the server consumer application124transmits the session token to the server emitter application120. At316, the server emitter application120then forwards the session token to the client emitter application108.

At318, responsive to receiving the session token, the client emitter application108performs a programmatic call indicative of the programmatic task to the client consumer application110. The call includes the session token. The call may also include the emitter-application identifier (separate from the emitter-application identifier in the public portion of the session token). In an embodiment, the call may also include patient data for a patient. Responsive to receiving the call, the client consumer application110validates the public portion of the session token (i.e., the emitter-application identifier) against the (separate) emitter-application identifier also included in the call. After validating the public portion of the session token, the client consumer application110retrieves the secret data from the secure memory location using the public portion of the session token (i.e., the emitter-application identifier). As the private portion of the session token was previously encrypted by the server consumer application124using the secret data, the client consumer application110may decrypt the private portion of the session token using the secret data stored in the secure memory location in order to generate a decrypted session token. Responsive to decrypting the private portion of the session token, the client consumer application110validates the emitter-application identifier in the public part of the session token against the emitter-application identifier in the now decrypted private portion of the session token. The client consumer application110may also validate the signature of the server consumer application124in the decrypted session token using the secret data. For instance, in an embodiment, the client consumer application110may validate the signature against an arbitrary security certificate that is accessible to the client consumer application110.

At320, the client consumer application110requests a session access token from the server consumer application124by transmitting the decrypted session token, the emitter-device identifier, and the emitter-application identifier to the server consumer application124. The server consumer application124then validates the registration attributes stored during the registration process (described above) against at least the emitter-device identifier and the emitter-application identifier. The server consumer application124also validates the signature of the server consumer application124in the decrypted session token using the registration attributes. Responsive to validating the registration attributes and the signature, the server consumer application124then generates a session access token. The session access token indicates that the server consumer application124has authenticated the client consumer application110as well as the client emitter application108. The session access token may be valid for a short time range, such as 5 to 30 minutes. For example, the session access token may be valid from 7.5 to 25 minutes, 10 to 20 minutes, or 13 to 15 minutes. In the event that the session access token is not used by the client consumer application110within the time range, steps302-316may be repeated in order to regenerate the session access token. At322, the server consumer application124transmits the session access token to the client consumer application110. Responsive to receiving the session access token, the client consumer application110then performs the programmatic task indicated by the call. At324, the client consumer application110executes the callback which causes the client consumer application110to perform the programmatic task indicated by the callback.

It is to be understood that the emitter token, the session token, and the session access token described above may be valid only for a single use. More specifically, once a token is used in one the previously mentioned steps, one or more of the applications described above may mark the token as being used, and the same token may not be used again in a step that has previously been performed. For example, after the client consumer application110performs the programmatic task responsive to receiving the session access token from the server consumer application124, the client consumer application110may not perform the programmatic task a second time using the same session access token. Instead, in order for the client consumer application110to perform the programmatic task a second time, a new session access token will need to be generated by the computing system100using the above-described processes.

The technologies described herein present various advantages over conventional technologies used to transfer data between applications executing on a mobile computing device. First, the technologies described herein do not require the use of a third-party application (broker) executing on the mobile computing device. Second, as the technologies described herein do not require the use of a shared authorization subsystem, inter-application communication may be achieved between mobile applications using different security schemes. Third, the technologies described above do not expose patient data to an operating system of the mobile computing device.

Referring now toFIG. 4, a methodology400performed by a client emitter application executing on a mobile computing device that registers the client emitter application and a client consumer application for inter-application communication on the mobile computing device is illustrated. The methodology400begins at402, and at404the client emitter application receives a registration command indicating that the client emitter application and the client consumer application are to be registered. At406, responsive to receiving the registration command, the client emitter application transmits an emitter-device identifier to a server emitter application executing on a first server computing device that is in network communication with the mobile computing device, wherein the emitter-device identifier identifies the mobile computing device executing the client emitter application. The server emitter application causes a registration key to be received by the client emitter application. The registration key indicates that the client emitter application has been registered with a server consumer application executing on a second server computing device that is in network communication with the mobile computing device and the first server computing device.

At408, responsive to receiving the registration key, the client emitter application performs a registration call to the client consumer application. The registration call comprises the registration key and causes the client consumer application to register the client emitter application. The registration call also causes the server consumer application to register the client consumer application. The methodology400concludes at410.

With reference now toFIG. 5, a methodology500performed by a client emitter application executing on a mobile computing device that facilitates inter-application communication is illustrated. The methodology500begins at502, and at504the client emitter application receives an indication of a programmatic task to be performed by a client consumer application also executing on the mobile computing device. At506, responsive to receiving the indication, the client emitter application transmits an emitter-device identifier and user metadata to a server emitter application executing on a first server computing device that is in network communication with the mobile computing device. The server emitter application causes a session token to be generated based upon the emitter-device identifier and the user metadata. The session token indicates that the client emitter application has been authenticated by a server consumer application executing on a second server computing device that is in network communication with the mobile computing device and the first server computing device. Furthermore, the server emitter application causes the session token to be received by the client emitter application.

At508, the client emitter application receives the session token from the server emitter application. At510, responsive to receiving the session token, the client emitter application performs a call indicative of the programmatic task to the client consumer application. The call comprises the session token. The call causes the client consumer application to authenticate the client emitter application based upon the session token. Additionally, the call causes the server consumer application to authenticate the client consumer application based upon the session token. Responsive to authentication of the client emitter application by the client consumer application and the authentication of the client consumer application by the server consumer application, the client consumer application performs the programmatic task. The methodology500concludes at512.

Referring now toFIG. 6, a high-level illustration of an exemplary computing device600that can be used in accordance with the systems and methodologies disclosed herein is illustrated. For instance, the computing device600may be used in a system that registers a client emitter application and a client consumer application. By way of another example, the computing device600can be used in a system that facilitates inter-application communication between a client emitter application and a client consumer application. The computing device600includes at least one processor602that executes instructions that are stored in a memory604. The instructions may be, for instance, instructions for implementing functionality described as being carried out by one or more components discussed above or instructions for implementing one or more of the methods described above. The processor602may access the memory604by way of a system bus606. In addition to storing executable instructions, the memory604may also store data for patients, tokens, etc.

The computing device600additionally includes a data store608that is accessible by the processor602by way of the system bus606. The data store608may include executable instructions, data for patients, tokens, etc. The computing device600also includes an input interface610that allows external devices to communicate with the computing device600. For instance, the input interface610may be used to receive instructions from an external computer device, from a user, etc. The computing device600also includes an output interface612that interfaces the computing device600with one or more external devices. For example, the computing device600may display text, images, etc. by way of the output interface612.