SYSTEM AND METHOD FOR RECEIVING COMMUNICATIONS AND PROVIDING ALERTS

Abstract

A messaging platform is configured to communicate with a messaging client installed on a mobile communication device via a compact dedicated device (CDD). Messages that are intended for the mobile communication device are first transmitted to the CDD via a paging system instead of directly to the mobile communication device. The CDD is configured to forward the messages to the mobile communication device while providing alerts to the caregiver associated with the mobile communication device.

Description

RELATED APPLICATIONS

The present application is a continuation application of U.S. application Ser. No. 14/658,093, filed Mar. 13, 2015, which claims priority to U.S. Provisional Patent Application No. 61/952,144 filed Mar. 13, 2014, U.S. Provisional Patent Application No. 61/984,852 filed Apr. 27, 2014, U.S. Provisional Patent Application No. 61/986,748, filed Apr. 30, 2014, U.S. Provisional Patent Application No. 62/009,920 filed Jun. 10, 2014, and U.S. Provisional Patent Application No. 62/009,921 filed Jun. 10, 2014, each of which is incorporated by reference herein in its entirety.

BACKGROUND

Today we are connected by ever more powerful devices with ever increasing communication capabilities. Moreover, more and more physical objects or “things” are embedded with electronics, software, sensors and connectivity to enable them to achieve greater value and service by exchanging data. As the amount of information and data being exchanged by communication and other devices increases, the ability to ensure privacy and security of the information and data is becoming harder and harder. For business and other entities looking to take advantage of modern communication and device capability to gather and use data, the difficulty in ensuring privacy and security of the data can lead to liability. A prime example of this is in the health care arena where patient health information is being gathered and exchanged.

The Health Insurance Portability and Accountability Act (HIPAA) of 1996 imposes specific requirements on the management of Protected Health Information (PHI) and Electronic Protected Health Information (EPHI) by covered entities (e.g., physicians, hospitals, and insurance providers) as well as their business associates. The Act engendered a regulatory framework that includes the HIPAA Security Rule and HIPAA Privacy Rule (“HIPAA Rules”). Specifically, the HIPAA Security Rule mandates the use of specific physical, technical and administrative safeguards in information technology (IT) systems that store or transact with Electronic Protected Health Information (EPHI). Meanwhile, the HIPAA Privacy Rule sets protocols with respect to the correction, disclosure, and notification of PHI and EPHI.

One of the most salient aspects of the HIPAA Rules, and the related acts and regulations is that covered entities are held accountable for the security and management of the PHI and EPHI under their control. In practice, each item of PHI or EPHI is treated as being owned by at least one covered entity. This ownership paradigm avoids ambiguity about liability in the event of a security breach.

In addition to the formal medical records that are traditionally maintained for each patient, healthcare providers also routinely engage in ad hoc communication in order to coordinate and facilitate treatment for individual patients. Ad hoc communication can convey PHI and EPHI, and is therefore subject to the same HIPAA Rules as formal patient records. Nevertheless, healthcare providers must rely on legacy communication technologies (e.g., facsimile, paging, and email) to conduct ad hoc communication. Conventional modes of communication are generally insecure and cannot be readily adapted to comply with HIPAA rules.

SUMMARY

According to various embodiments, there is provided a HIPAA-compliant system and method for communicating electronic health information. In one exemplary embodiment, message data that include at least some EPHI can be composed, transmitted, and/or received on a messaging client (e.g., Medigram smartphone or web application). The exchange of message data over a network is mediated by a messaging platform (e.g., Medigram server(s)) that imposes HIPAA-compliant ownership and access control.

In various embodiments, the messaging client can be installed on a caregiver's mobile communication device (e.g., smartphone, laptop, tablet personal computer (PC)). In some embodiments, message data is transmitted directly between the messaging platform and the messaging client. In other embodiments, the messaging platform and the messaging client can communicate through a compact dedicated device (CDD). In one exemplary embodiment, the CDD can act as an intermediary recipient. As such, the CDD can be configured to receive message data from the messaging platform and then forward the message data to the messaging client. In addition, the CDD can also act as an alert agent. In this capacity, the CDD can be configured to respond to incoming message data by providing one or more alerts to the caregiver.

In various embodiments, a first caregiver can use the messaging client and initiate and conduct a conversation with at least a second caregiver. For example, the first caregiver can exchange message data with the second caregiver. The conversation can be patient-centered and the corresponding message data can include at least some EPHI regarding a specific patient. Alternately, the conversation can be a professional conversation that does not relate to any particular patient.

In various embodiments, the messaging platform can attribute ownership of the conversation to one or more covered entities based on the respective affiliations of the caregivers participating in the conversation. Accordingly, the messaging platform can further associate data corresponding to the conversation with the covered entity. In one exemplary embodiment, data associated with different covered entities can be stored separately.

In various embodiments, the messaging platform can restrict participation in and access to the conversation to those caregivers who are actively affiliated with at least one of the covered entities that own the conversation. Thus, a caregiver can be added to a conversation owned by a covered entity if the caregiver is actively associated with the covered entity. Furthermore, a caregiver participating in a conversation can lose access to the conversation in the event that the affiliation between the caregiver and the covered entity owning the conversation is disabled.

In various embodiments, a single caregiver can be affiliated with multiple covered entities. Accordingly, in one exemplary embodiment, the messaging platform can allow a caregiver to participate in and access conversations owned by a first covered entity and conversations owned by a second covered entity. Meanwhile, the caregiver interacts with a single instance of the messaging client but is able to participate in and access conversations owned by different covered entities.

In various embodiments, the affiliation between a caregiver and a covered entity can be linked with privileges and/or restrictions. For example, as between one particular caregiver and the covered entity that the caregiver is actively affiliated with, the caregiver can have privileges that include, for example, but not limited to, affiliations administrator privilege, professional conversation initiator privilege, patient linking privilege, conversation sharing privilege, and conversation transfer privilege.

In various embodiments, ownership of a conversation can be shared amongst different covered entities. Accordingly, in one exemplary embodiment, the messaging platform allows a first caregiver who is affiliated with a first covered entity and having the requisite conversation sharing privilege to add at least a second caregiver who is affiliated with a second covered entity as a participant in an existing patient-centered conversation. In doing so, the messaging platform can further attribute ownership of the conversation to the second covered entity in addition to the first covered entity.

In various embodiments, ownership of a conversation can be transferred from one covered entity to another covered entity. For example, in one exemplary embodiment, a first caregiver who is associated with a first covered entity and whose association with the first covered entity is linked with a requisite conversation transfer privilege can transfer the ownership of an existing patient-centered conversation from the first covered entity to a second covered entity. In other embodiments, the first caregiver having the requisite conversation transfer privilege can remove as participants from an existing patient-centered conversation all caregivers who are actively affiliated with one or more covered entities. In doing so, the messaging platform can attribute ownership of the conversation to one or more covered entities having actively affiliated caregivers who remain as participants in the conversation.

Other features and advantages of the present invention will become more readily apparent to those of ordinary skill in the art after reviewing the following detailed description and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The structure and operation of the present invention will be understood from a review of the following detailed description and the accompanying drawings in which like reference numerals refer to like parts and in which:

FIG. 1 is a system diagram illustrating a network environment for various embodiments;

FIG. 2A is a block diagram illustrating a CDD according to various embodiments;

FIG. 2B is a system diagram illustrating a network environment for various embodiments;

FIG. 2C is a block diagram illustrating production servers according to various embodiments;

FIG. 2D is a block diagram illustrating production and backup databases according to various embodiments;

FIG. 3 is a flow diagram illustrating a process for conducting a conversation according to various embodiments;

FIG. 4 is a flow diagram illustrating a process for conducting a professional conversation according to various embodiments;

FIG. 5 is a flow diagram illustrating a process for sharing a conversation according to various embodiments;

FIG. 6 is a flow diagram illustrating a process for transferring a conversation according to various embodiments; and

FIG. 7A illustrates a screen display according to various embodiments;

FIG. 7B illustrates a screen display according to various embodiments;

FIG. 8 is a block diagram illustrating a device according to various embodiments.

DETAILED DESCRIPTION

Various embodiments of the systems and methods disclosed herein provide for communicating electronic health information. In the systems and methods disclosed, users can communicate through a simple, unified solution that not only provides privacy and security, but also helps the users and the organizations they are associated with manage the privacy and security using automated, but flexible tools. Many of the embodiments describe herein are related, e.g., to covered entities that must comply with HIPAA. One challenge for caregivers associated with such entities is the ability to communicate in an easy, convenient fashion, using modern communication technology, while still ensuring that any PHI or EPHI is tracked and maintained in a secure fashion.

The systems and methods described herein allow caregivers affiliated with the same or different covered entities to engage in both patient-centered and professional conversations. In various embodiments, a messaging platform can mediate the exchange of message data between caregivers engaged in conversation. In one exemplary embodiment, the messaging platform manages ownership and access to individual conversations according to HIPAA mandates. Thus, each conversation may be owned by at least one covered entity and may be accessed by caregivers with active affiliations with that covered entity.

After reading this description it will become apparent to one skilled in the art how to implement the systems and methods described herein in various alternative embodiments and alternative applications. However, although various embodiments will be described herein, it is understood that these embodiments are presented by way of example only, and not limitation. As such, this detailed description of various alternative embodiments should not be construed to limit the scope or breadth of appended claims.

FIG. 1 is a system diagram illustrating a network environment 100 configured in accordance with one example embodiment of the systems and methods described herein. Referring to FIG. 1, a messaging platform 120 can include one or more servers 122 and databases 124. In various embodiments, the servers 122 can provide messaging functionalities built on Extensible Messaging and Presence Protocol (XMPP).

According to one exemplary embodiment, the messaging platform 120 is configured to transact (e.g., receive, transmit, store) message data, which can include information that is associated with various privacy and security needs or requirements. For example, the message data can include at least some EPHI that is covered by HIPAA security and privacy mandates. As such, in addition to imposing HIPAA-compliant ownership and access control, as described in more detail below, the messaging platform 120 can also be configured to encrypt at least a portion of the message data stored in the databases 124. Moreover, the messaging platform 120 can be configured to store one or more redundant copies of the message data. For example, the servers 122 and databases 124 can include for example, but not limited to, primary production server(s) and database(s), and standby disaster recovery server(s) and database(s). The primary production database server can be configured to replicate production data in real time to the standby disaster recovery database server, which can be located in a different geographical region.

In various embodiments, the messaging platform 120 can communicate over a network 110 with a plurality of messaging clients, including a first messaging client 150, a second messaging client 160, and a third messaging client 170. The network 110 may be a wired or wireless network.

In the example of FIG. 1, each of the first messaging client 150, the second messaging client 160, and the third messaging client 170 can be installed on a respective mobile communication device (e.g., smartphone, laptop, tablet PC). For example, the first messaging client 150 may be an iOS client using the XMPP Framework while the second messaging client 160 may be an Android client using the Smack XMPP library. Meanwhile, the third messaging client 170 may be a web client. Thus, according to some embodiments, the web messaging client may be a Ruby on Rails application that uses the Ember and Jquery Javascript frameworks with the Strophe.js library for XMPP.

In various embodiments, each of the first messaging client 150, the second messaging client 160, and the third messaging client 170 can be configured to compose, transmit, and receive message data. Moreover, the first messaging client 150, the second messaging client 160, and the third messaging client 170 can store and provide access to a local cache of message data. In at least one exemplary embodiment, the first messaging client 150, the second messaging client 160, and the third messaging client 170 can be configured to encrypt the corresponding local cache of message data.

Referring again to FIG. 1, each of the first messaging client 150, the second messaging client 160, and the third messaging client 170 can be associated with an individual user. In one exemplary embodiment, each messaging client may be associated with a particular caregiver (e.g., physician, nurse). For example, as shown in FIG. 1, the first messaging client 150 is associated with a Caregiver A, the second messaging client 160 is associated with a Caregiver B, and the third messaging client 170 is associated with a Caregiver C.

In various embodiments, each of Caregiver A, Caregiver B, and Caregiver C can be affiliated with one or more covered entities. For example, a physician may be affiliated with one or more hospitals. As shown in FIG. 1, Caregiver A is affiliated with a Covered Entity A and a Covered Entity B. Meanwhile, Caregiver B is affiliated with Covered Entity A and Caregiver C is associated with Covered Entity B. As described in detail below, Caregivers A, B and C can use their devices 150, 160, and 170, respectively, to communicate information with each other that may include PHI. Messaging platform 120 can, however, impose HIPAA-compliant ownership and access control.

As described above, devices 150, 160, and 170 generally comprise standard, or off the shelf communication devices, such as smartphones, tablets, or laptops. In certain instances, the use of such devices may not be possible. For example, often in a hospital setting, such devices cannot be used because of a lack of proper network access or other restrictions. As such, in certain embodiments, a specialized device may be needed to enable the communication of information and data described herein. Such a device is described with respect to FIGS. 2A and 2B.

Compact Dedicated Device (CDD)

FIG. 2A is a block diagram illustrating an CDD 200 according to various embodiments. As shown in FIGS. 2A and 2B, CDD 200 can include a control unit 210, a first communication unit 220, a second communication unit 230, a first antenna 225, a second antenna 235, a storage unit 240, an alert module 250, and a battery 260.

In various embodiments, the CDD 200 can be a device that is capable of long- and short-range wireless communication. Thus, in one exemplary embodiment, the first communication unit 220 can include a radio frequency (RF) chain that is configured to receive message data that is broadcast by the messaging platform 120 via a paging system. Meanwhile, the second communication unit 230 can include a RF chain that is configured to communicate with a mobile communication device via one or more wireless personal area network (PAN) technologies. For example, the CDD 200 can be paired with a mobile communication device using Bluetooth® technology. Alternately or in addition, the CDD 200 can communicate with a mobile communication device via near field communication (NFC). A person having ordinary skill in the art can appreciate that the first communication unit 220 and the second communication unit 230 can be configured to communicate using different wireless technologies as well.

In various embodiments, the control unit 210 can be configured to control the overall operation of the CDD 200 including controlling the functions of the first communication unit 220, the second communication unit 230, the storage unit 240, and the alert module 250. In various embodiments, the control unit 210 can be, for example, but not limited to, a microprocessor or a microcontroller.

In various embodiments, the storage unit 240 can include writable non-volatile memory to store one or more pager identifiers, paring information for a wireless PAN network, and message data received from the messaging platform 120. The storage unit 240 can further include non-volatile program memory. In various embodiments, at least some of the application programs stored at the storage unit 240 can be executed by the control unit 210 for the operation of the CDD 200.

In various embodiments, the alert module 250 can include one or more types of hardware including, for example, but not limited to, a vibrator capable of generating tactile alerts, a speaker capable of generating audible alerts, and a display capable of generating visual alerts (e.g., light-emitting diode (LED)).

In various embodiments, the storage unit 240 can be configured to store application programs, application data, and user data. In various embodiments, at least some of the application programs stored at the storage unit 240 can be executed by the control unit 210 for the operation of the mobile communication device 200.

In various embodiments, the CDD 200 can be powered in full or in part by the battery 260. According to one exemplary embodiment, firmware on the CDD 200 monitors the charge state of the battery 260. In some embodiments, the CDD 200 can be configured to provide an alert using the alert module 250 when the battery 260 approaches a discharged state. The CDD 200 can be further configured to transmit the charge state of the battery 260 to a corresponding messaging client installed on a mobile communication device that is paired with the CDD 200.

Although not shown in FIG. 2A, the CDD 200 can also be powered in full or in part through an audio connector. In one exemplary embodiment, the battery 260 of the CDD 200 can be charged by connecting the CDD 200 via the audio connector to a mobile communication device that is paired or otherwise associated with the CDD 200.

Although not shown in FIG. 2A, according to one exemplary embodiment, the CDD 200 can also be charged using a bulk charging station. The bulk charging station is capable of simultaneously charging multiple CDDs. In various embodiments, connecting the CDD 200 to a bulk charging station can cause firmware on the CDD 200 to wipe at least a portion of the non-volatile memory that is included in the storage unit 240. For example, connecting the CDD 200 to a bulk charging station can cause firmware on the CDD 200 to wipe data including, for example, but not limited to, the pager identifier associated with the CDD 200, paring information for the wireless PAN network, and message data received from the messaging platform 120.

FIG. 2B is a system diagram illustrating a network environment 205 that can support or integrate a CDD 200 in accordance with one example embodiment. Referring to FIGS. 1-2B, the messaging platform 120 can communicate with the CDD 200 instead of directly with a mobile communication device 270 of Caregiver A.

According to one exemplary embodiment, the first messaging client 150 installed on the mobile communication device 270 can be configured to communicate with the CDD 200 over via a PAN 260 using the second communication unit 230. In various embodiments, the CDD 200 is also configured to communicate with the messaging platform 120 over the network 110 using the first communication unit 220.

In some embodiments, the messaging platform 120 can transmit message data to the mobile communication device 270 over the network 110. At the same time, the messaging platform 120 can broadcast, via a paging system, notifications that alerts Caregiver A to the availability of message data. According to one exemplary embodiment, the messaging platform 120, the paging system and the CDD 200 may be configured to implement a general purpose mobile push notification service. Thus, the CDD 200 is configured to receive the notifications but not message data over the paging system from the messaging platform 120. The CDD 200 can be configured to forward the notification to the mobile communication device 270 in response to receiving the notifications from the messaging platform 120. Moreover, the CDD 200 can be configured to generate an alert using the alert module 250. As such, Caregiver A may be made aware of the availability of message data at the mobile communication device 270 but the message data is not transmitted over an insecure paging system to the CDD 200. In some embodiments, the general purpose mobile push notification service is made available to other mobile application or service providers, including zero or more competitive messaging platforms. Thus the messaging platform 120, the paging system and the CDD 200 provide a general purpose mobile push notification service that can alert Caregiver A of the availability of data when mobile communication device 270 is unable to communicate directly over network 110.

In another exemplary embodiment, the CDD 200 can be configured to receive message data from the messaging platform 120 over a paging system or the network 110, and then forward the message data to the first messaging client 150 via the PAN 260.

According to one exemplary embodiment, the CDD 200 is associated with a unique pager identifier. The messaging platform 120 can be configured to store a device list that correlates the pager identifier of the CDD 200 with the mobile communication device 270. Thus, when the messaging platform 120 receives message data that is intended for the mobile communication device 270 of Caregiver A, the messaging platform can use the device list to determine the pager identifier of the CDD 200. In various embodiments, the messaging platform 120 can be configured to broadcast the pager identifier of the CDD 200 along with the message data intended for the mobile communication device 270. Meanwhile, the CDD 200 can determine whether message data is intended for the mobile communication device 270 based on the pager identifier that is transmitted with the message data. The CDD 200 can transmit message data that is intended for the mobile communication device 270 to the mobile communication device 270 using. Alternately, the CDD 200 can disregard and not transmit message data that is not intended for the mobile communication device 270.

In one exemplary embodiment, in response to receiving message data from the messaging platform 120, the CDD 200 can generate an alert using the alert module 250. In various embodiments, the CDD 200 generates alerts based on one or more alert rules. For example, the CDD 200 can be configured to generate an alert if the message data is not successfully forwarded to the first messaging client 150 within a predetermined amount of time. Alternately, the CDD 200 can be configured to always or never generate an alert, regardless of whether the message data received from the messaging platform 120 is successfully forward to the first messaging client 150.

In one exemplary embodiment, the message data that is communicated between the messaging platform 120, the CDD 200, and the first messaging client 150 installed on the mobile communication device 270 is encrypted. For example, the messaging platform 120 can encrypt the message data prior to transmitting the message data to the CDD 200. In various embodiments, the CDD 200 is not provisioned with a key to decrypt the message data. Thus, in various embodiments, the CDD 200 does not decrypt the message data. Instead, the CDD 200 can be configured to forward the still encrypted message data to the first messaging client 150. Meanwhile, in various embodiments, the first messaging client 150 can be provisioned with the key required for decrypting the message data. Thus, in various embodiments, the message data is not decrypted until it is received at the mobile communication device 270. Thus, in various embodiments, loss of the CDD 200 or compromise of the data stored on the CDD 200 does not constitute a breach of EPHI.

FIG. 2C is a block diagram illustrating production servers 215 according to various embodiments. Referring to FIGS. 1 and 2C, in various embodiments, the production servers 215 may implement the servers 122 of the messaging platform 120.

In various embodiments, the messaging platform 120 can be implemented using a hybrid cloud infrastructure that includes virtual cloud servers for applications and services as well as physical servers for database storage.

FIG. 2D is a block diagram illustrating production and backup databases 255 according to various embodiments. Referring to FIGS. 1 and 2D, in various embodiments, the production and backup databases 255 can implement the databases 124 of the messaging platform 120.

Again referring to FIGS. 1 and 2D, according to one exemplary embodiment, a primary production database can be hosted on a dedicated physical server located in one geographic region (e.g., Chicago, Ill.). In various embodiments, production data is replicated in real time from the primary database server to a standby disaster recovery database located in a different geographical region (e.g., Dallas, Tex.).

In order to restrict access to the EPHI contained in the production and backup databases 255, there can be three instances of the production database. For example, the instances of the production database can include a primary production instance, a warm disaster recovery instance that receives continuous updates from the primary production instances, and a production-test instance used for pre-release quality assurance testing. According to one exemplary embodiment, daily backups are maintained offline on the disaster recovery database server.

HIPAA-Compliant Ownership and Access Control

As noted above, the systems shown in FIGS. 1 and 2B can implement workflow processes that maintain privacy and security for, e.g., ad hoc communications. FIG. 3 is a flow diagram illustrating a process 300 for conducting a conversation according to various embodiments. Referring to FIGS. 1 and 3, in various embodiments, the process 300 can be performed by the messaging platform 120.

The messaging platform 120 can be configured to receive an indication initiate a conversation from a messaging client associated with a first caregiver actively affiliated with a first covered entity and a second covered entity (302). For example, Caregiver A can use the first messaging client 150 to start a new conversation. As will be described in more detail below, the conversation can be a patient-centered conversation or a professional conversation that does not relate to a specific patient.

In response to receiving the indication, the messaging platform 120 can be configured to identify a second caregiver actively affiliated with the first covered entity and a third caregiver actively affiliated with the second covered entity as authorized participants in the conversation based on a respective active affiliations of the first caregiver, the second caregiver, and the third caregiver (304). For example, Caregiver A is actively affiliated with Covered Entity A and Covered Entity B. As such, HIPAA mandates permit Caregiver A to conduct conversations (e.g., patient-centered) with both Caregiver B and Caregiver C. The messaging platform 120 can be configured to cause the first messaging client 150 to indicate to Caregiver A that Caregiver B and Caregiver C are authorized participants that may be added to the conversation. A person having ordinary skill in the art can appreciate that the first messaging client 150 can indicate many additional authorized participants based on the active affiliations between various caregivers and at least Covered Entity A and Covered Entity B.

Continuing with the example shown in FIG. 3, the messaging platform 120 can be configured to receive an indication from the first caregiver to include at least one of the second caregiver and the third caregiver in the conversation (306). For example, Caregiver A can add Caregiver B to the conversation since both Caregiver A and Caregiver B are actively affiliated with at least one common covered entity (e.g., Covered Entity A). Alternately, Caregiver A can add Caregiver C to the conversation as both Caregiver A and Caregiver C are actively affiliated with Covered Entity B.

In response to the indication to include at least one of the second caregiver and the third caregiver in the conversation, the messaging platform 120 can be configured to determine a number of common covered entities having active affiliations with every participant in the conversation (308). For example, Caregiver A and Caregiver B can be actively affiliated with a single covered entity (e.g., Covered Entity A). Alternately, Caregiver A and Caregiver B can both be actively affiliated with more than one common covered entity. For instance, Caregiver A and Caregiver B can be affiliated with both Covered Entity A and Covered Entity B.

If the messaging platform 120 determines that the number of common covered entities having active affiliations with every participant in the conversation is greater than one (309-Y), the messaging platform 120 can be configured to select at least one of the common covered entities (310) and attribute ownership of the conversation to the selected covered entity (312). For example, the messaging platform 120 can be configured to select at least one of the common covered entities based on input from one of Caregiver A, Caregiver B, or any other appropriate personnel from Covered Entity A and/or Covered Entity B. Thus, if Caregiver A and Caregiver B are actively associated with both Covered Entity A and Covered Entity B, Caregiver A or Caregiver B can indicate to the messaging platform 120 that ownership of the conversation should be attributed to Covered Entity A and/or Covered Entity B.

Moreover, the messaging platform 120 can associate data corresponding to the conversation with the selected covered entity. As such, a caregiver who is not actively affiliated with the selected covered entity cannot access data corresponding to the conversation.

In addition, the messaging platform 120 can be configured to exclude one or more caregivers not actively affiliated with the selected covered entity as authorized participants in the conversation (314). For example, based on input from Caregiver A and/or Caregiver B, the messaging platform 120 can attribute ownership of the conversation to Covered Entity A. Meanwhile, Caregiver C is not actively affiliated with Covered Entity A. As such, the messaging platform 120 can be configured to exclude Caregiver C as an authorized participant in the conversation owned by Covered Entity A.

Otherwise, if the messaging platform 120 determines that the number of common covered entities having active affiliations with every participant in the conversation is not greater than one (309-N), the messaging platform 120 can be configured to attribute ownership of the conversation to the common covered entity (316). For example, the messaging platform 120 can attribute ownership of the conversation to Covered Entity A since Caregiver A and Caregiver B are both actively affiliated with only Covered Entity A. The messaging platform 120 can associated data corresponding to the conversation with Covered Entity A and prevent caregivers not actively affiliated with Covered Entity A from accessing the data.

Moreover, the messaging platform 120 can be configured to exclude one or more caregivers not actively affiliated with the common covered entity as authorized participants in the conversation (318). For example, Caregiver C is actively affiliated with Covered Entity B but not with Covered Entity A. Thus such, the messaging platform 120 can be configured to exclude Caregiver C as an authorized participant in the conversation owned by Covered Entity A.

In this manner, in various embodiments, the messaging platform 120 can be configured to implement HIPAA-compliant access control to the conversation. Thus, a caregiver can participate in and/or otherwise have access to a conversation if the caregiver has and maintains an active affiliation with at least one of the covered entities owning the conversation. For example, both Caregiver A and Caregiver B can participate in and access a patient-centered conversation owned by Covered Entity A. However, if the affiliation between Caregiver A and Covered Entity A is deactivated, then Caregiver A can no longer participate in or have access to the conversation owned by Covered Entity A.

Now that the conversation has been generated and assigned to a specific covered entity, the message data that is associated with that conversation can be stored, e.g., in the databases 124. For example, the messaging platform 120 can include records associated with and maintained for each of the associated covered entities, in this case Covered Entities A and B. The messages being communicated between, e.g., Caregiver A and Caregiver B can be passed through platform 120 under the control of the corresponding messaging clients (e.g., the first messaging client 150 and the second messaging client 160). In this manner, the messages can be captured and kept as a record associated with the correct covered entity.

In certain embodiments, the records maintained by system 120 can be exported as electronic medical records (EMRs) maintained by a particular covered entity.

Patient-Centered Conversation and Professional Conversation

The messaging platform 120 permits caregivers to engage in different types of conversations. In various embodiments, the messaging platform 120 can be configured to support patient-centered conversations. A patient-centered conversation relates to a specific patient. As will be described in more detail below, a patient can be associated with one or more covered entities (e.g., Covered Entity A and/or Covered Entity B). In one exemplary embodiment, the messaging platform 120 can be configured to restrict ownership of a patient-centered conversation regarding a patient to the one or more covered entities that are associated with the patient.

In various embodiments, the messaging platform 120 can be configured to also support professional conversations. A professional conversation is suitable for non-patient-centered professional communication and can take place between two caregivers who do not have active affiliations with at least one common covered entity. For example, Caregiver B and Caregiver C can engage in a professional conversation via the messaging platform 120. Caregivers engaged in a professional conversation disclose health information that does not meet the criteria for PHI or EPHI. Nevertheless, for reasons of caution and convenience, professional conversations can be conducted via the messaging platform 120 and in accordance with HIPAA mandates.

In various embodiments, the messaging platform 120 can be configured to attribute ownership of a professional conversation to at least one covered entity even though PHI or EPHI would not be disclosed during the professional conversation. As such, the messaging platform 120 maintains accountability in the event that health information disclosed within a professional conversation is later determined to have been improperly disclosed and to meet the legal standard for PHI or EPHI.

In various embodiments, a caregiver can be required to have the requisite privilege with respect to a particular covered entity to initiate a professional conversation (e.g., professional conversation initiator privilege). For example, the affiliation between Caregiver B and Covered Entity A can be linked with a professional conversation initiator privilege. Thus, in order to for Caregiver B who is actively affiliated with Covered Entity A to initiate a professional conversation with Caregiver C who is affiliated with a Covered Entity B, the messaging platform 120 can be configured to determine whether Caregiver B has the requisite professional conversation initiator privilege.

FIG. 4 is a flow diagram illustrating a process 400 for conducting a professional conversation according to various embodiments. Referring to FIGS. 1 and 4, the process 400 can be performed by the messaging platform 120.

In various embodiments, the messaging platform 120 can be configured to receive an indication from a messaging client associated with a first caregiver actively affiliated with a first covered entity to initiate a professional conversation with a second caregiver (402). The first caregiver and the second caregiver can both be actively affiliated with the same first covered entities. For example, Caregiver A can use the first messaging client 150 to initiate a professional conversation with either Caregiver B or Caregiver C. However, the messaging platform 120 can also support professional conversations between caregivers who are not actively affiliated with the same covered entities. For example, Caregiver B can use the second messaging client 160 to initiate a professional conversation with Caregiver C. Using the first messaging client 150, Caregiver A can also initiate a professional conversation that includes both Caregiver B and Caregiver C.

In response to the indication, the messaging platform 120 can determine whether the affiliation between the first caregiver and the first covered entity is linked with a privilege to initiate a professional conversation (403). For example, Caregiver A can have the requisite professional conversation initiator privilege with respect to Covered Entity A, which allows Caregiver A to initiate a professional conversation with caregivers who are and who are not actively affiliated with Covered Entity A.

If the messaging platform 120 determines that the affiliation between the first caregiver and the first covered entity is linked with the privilege to initiate a professional conversation (403-Y), then the messaging platform 120 can be configured to include the first caregiver and the second caregiver as participants in a professional conversation (404). Furthermore, the messaging platform 120 can be configured to attribute ownership of the professional conversation to the first covered entity (406).

On the other hand, the messaging platform 120 can determine that the affiliation between the first caregiver and the first covered entity is not linked with the privilege to initiate a professional conversation (403-N). As such, the messaging platform 120 can cause a messaging client associated with the first caregiver to notify the first caregiver that the first caregiver does not have professional conversation initiator privilege for the first covered entity (408).

HIPAA-Compliant Ownership Sharing

In various embodiments, the messaging platform 120 can be configured to attribute ownership of a conversation to more than one covered entity. In particular, the messaging platform 120 is configured to maintain HIPAA compliance while sharing ownership of a patient-centered conversation amongst multiple covered entities. As such, caregivers actively affiliated with different covered entities are able to participate in and access the same patient-centered conversation.

For example, Caregiver A can have the requisite conversation sharing privilege with respect to Covered Entity A and/or Covered Entity B. Thus, Caregiver A can add Caregiver C to the conversation owned by Covered Entity A even though Caregiver C is actively affiliated with Covered Entity B and not Covered Entity A. In doing so, the messaging platform 120 can attribute ownership of the conversation to both Covered Entity A and Covered Entity B.

FIG. 5 is a flow diagram illustrating a process 500 for sharing a conversation according to various embodiments. Referring to FIGS. 1 and 5, in various embodiments, the process 500 can be performed by the messaging platform 120.

In various embodiments, the messaging platform 120 can be configured to receive an indication from a messaging client associated with a first caregiver actively affiliated with the first covered entity to include a second caregiver actively affiliated with a second covered entity in a conversation owned by the first covered entity (502). For example, Caregiver B, who is actively affiliated with Covered Entity A, may be engaged in a conversation that is owned by Covered Entity A. Caregiver B can use the first messaging client 150 to indicate to the messaging platform 120 to include Caregiver C in the conversation. Caregiver C, however, is actively affiliated with Covered Entity B and not Covered Entity A. Thus, in some embodiments, the indication from Caregiver B can include a selection of the Covered Entity B as a new covered entity. In response to the selection of the Covered Entity B, the messaging platform 120 can provide, via the first messaging client 150, one or more caregivers who are actively affiliated with Covered Entity B. Caregiver B can then select Caregiver C from the one or more caregivers actively affiliated with Covered Entity B.

Alternately, in other embodiments, the indication from Caregiver B can include a request to specifically include Caregiver C as a new caregiver in the conversation. For example, in some embodiments, Caregiver B can provide a unique communication enabling personal identifier (e.g., email address, mobile phone number) for Caregiver C.

In response to the indication from the first caregiver, the messaging platform 120 can determine whether the affiliation between the first caregiver and the first covered entity is linked with a privilege to share the conversation (503). For example, Caregiver A can have the requisite conversation sharing privilege with respect to Covered Entity A, which allows Caregiver A to share conversations owned by Covered Entity A in which Caregiver A is a participant.

If the messaging platform 120 determines that the affiliation between the first caregiver and the first covered entity is linked with the privilege to share the conversation (503-Y), then the messaging platform 120 can be configured to include the second caregiver in the conversation owned by the first covered entity (504). Furthermore, the messaging platform 120 can be configured to attribute ownership of the conversation to the first covered entity and the second covered entity (506). As such, more than one covered entities (e.g., both Covered Entity A and Covered Entity B) can have accountability in the event that health information disclosed within the conversation is breached.

In some embodiments, prior to including Caregiver C in the conversation, the messaging platform 120 can be configured to obtain a legally binding digital signature from Caregiver C. For example, the messaging platform 120 can be configured to request, via the third messaging client 170, confirmation that Caregiver C has received HIPAA training in accordance with HIPAA regulations, and agrees to comply with HIPAA regulations for transmission and access to message data that is exchanged via the messaging platform 120. The messaging platform 120 can further obtain confirmation that Caregiver C is engaged in the direct care of a patient that is the subject of the shared patient-centered conversation.

In some embodiments, the messaging platform 120 can be configured to receive an indication from a messaging client associated with a first caregiver actively affiliated with a first covered entity to include a second caregiver D (not shown), who is not yet a user of the messaging platform 120. For example, in some embodiments, Caregiver B can provide a unique communication enabling personal identifier such as an email address or mobile phone number for Caregiver D to the messaging platform 120. The messaging platform 120 can be configured to make use of the unique communication enabling personal identifier to transmit an invitation to Caregiver D to become a user of the messaging platform 120. In some embodiments, prior to including Caregiver D in the conversation, the messaging platform 120 can be configured to obtain a legally binding digital signature from Caregiver D as described above.

On the other hand, the messaging platform 120 can determine that the affiliation between the first caregiver and the first covered entity is not linked with the privilege to share the conversation (503-N). For example, Caregiver A can have conversation sharing privilege with respect to Covered Entity B but not Covered Entity A. As such, the messaging platform 120 can be configured to exclude the second caregiver as an authorized participant in the conversation owned by the first covered entity (508).

In various embodiments, the messaging platform 120 can be configured to attribute ownership of the conversation to the first covered entity and not the second covered entity (510). Additionally, in some embodiments, the messaging platform 120 can cause a messaging client associated with the first caregiver to notify the first caregiver that the first caregiver does not have conversation sharing privilege for the first covered entity (512).

HIPAA-Compliant Ownership Transfer

In various embodiments, the messaging platform 120 can be configured to transfer ownership of a conversation from one covered entity to another. For instance, a patient may be transferred from one facility (e.g., hospital) to another facility (e.g., rehabilitation center). Thus, a patient-centered conversation can initially include caregivers having active affiliations with both Covered Entity A and Covered Entity B. For example, Caregiver A, Caregiver B, and Caregiver C can all be engaged in a patient-centered conversation that is initially owned by both Covered Entity A and Covered Entity B.

As the patient's care is gradually transferred from Covered Entity A to Covered Entity B, the patient-centered conversation can eventually include only caregivers who are actively affiliated with Covered Entity B (e.g., Caregiver A and Caregiver C). For example, Caregiver A and/or Caregiver B can have the requisite conversation transfer privilege with respect to Covered Entity A. The Caregiver A or Caregiver B can transfer ownership of the conversation from Covered Entity A to Covered Entity B. In response to this transfer of ownership, the messaging platform 120 can remove caregivers who are actively affiliated with Covered Entity A but not Covered Entity B as participants from the conversation. As a result, Caregiver B will no longer be able to participate in and access the conversation.

FIG. 6 is a flow diagram illustrating a process 600 for transferring a conversation according to various embodiments. Referring to FIGS. 1 and 6, in various embodiments, the process 600 can be performed by the messaging platform 120.

In various embodiments, the messaging platform 120 can be configured to receive an indication from a messaging client associated with a first caregiver actively affiliated with a first covered entity to transfer ownership of a conversation from the first covered entity to a second covered entity (602). According to one exemplary embodiment, the messaging platform 120 can be configured to allow a caregiver to transfer ownership of a conversation whether or not the caregiver is a participant in the conversation. Alternately, the messaging platform can be configured to allow caregivers who are participants in a conversation to transfer ownership of the conversation.

In response to receiving the indication, the messaging platform 120 can be configured to determine whether the affiliation between the first caregiver and the first covered entity is linked with a privilege to transfer the conversation (603).

The messaging platform 120 can determine that the affiliation between the first caregiver and the first covered entity is linked with the privilege to transfer the conversation (603-Y). As such, the messaging platform 120 can be configured to attribute ownership of the conversation to the second covered entity and not the first covered entity (604). Transferring ownership of a conversation from one covered entity from another also transfers accountability from one covered entity to anther in the event that health information disclosed within the conversation is breached. For example, Covered Entity B instead of Covered Entity A can be held responsible for breaches of any PHI or EPHI contained within the conversation.

In addition, the messaging platform 120 can be configured to remove as participants in the conversation one or more caregivers who are not actively affiliated with the second covered entity (606). For example, Caregiver B is actively affiliated with only Covered Entity A. Thus, once the ownership of the conversation is transferred from Covered Entity A to Covered Entity B, the messaging platform 120 can be configured to remove Caregiver B as a participant from the conversation. Consequently, Caregiver B can no longer participate in or access the conversation.

Alternately, the messaging platform 120 can determine that the affiliation between the first caregiver and the first covered entity is not linked with the privilege to transfer the conversation (603-N). Accordingly, the messaging platform 120 can be configured to continue attributing the ownership of the conversation to the first covered entity (608). Moreover, the messaging platform 120 can be configured to cause a messaging client associated with the first caregiver to notify the first caregiver that the first caregiver does not have conversation transfer privilege for the first covered entity (610).

Patient-Covered Entity Associations

According to one exemplary embodiment, the messaging platform 120 can be configured to maintain a patient list that includes identification attributes including, for example, but not limited to, patient name, birthdate, contact information, and social security number. In various embodiments, the messaging platform 120 can be configured to maintain associations between a patient and one or more covered entities. For example, a patient can be associated with Covered Entity A and/or Covered Entity B.

In various embodiments, the affiliation between a covered entity and a caregiver can be linked with a privilege to link a patient in the patient list to a conversation owned by one or more covered entities. For example, Caregiver A can have patient linking privilege with respect to Covered Entity A and/or Covered Entity B.

In some embodiments, ownership of a patient-centered conversation regarding a specific patient can be restricted to the one or more covered entities that are associated with the patient. Thus, in various embodiments, in response to an indication from Caregiver A to link a conversation owned by Covered Entity A to a patient, the messaging platform 120 can be configured to determine whether the patient is associated with Covered Entity A.

Caregiver-Covered Entity Affiliations and Privileges

In various embodiments, the messaging platform 120 can be configured to update, track, and store affiliations between caregivers and covered entities. To ensure compliance with HIPAA mandates, the messaging platform 120 can be configured to restrict participation in and access to conversations owned by a covered entity to caregivers having active affiliations with the covered entity.

For example, while Caregiver A and Caregiver B are both actively affiliated with Covered Entity A, both Caregiver A and Caregiver B can be engaged in a conversation. The conversation can be a patient-centered conversation or a professional conversation that does not relate to any specific patient. In various embodiments, the messaging platform 120 can be configured to attribute ownership of the conversation between Caregiver A and Caregiver B to Covered Entity A.

In various embodiments, the affiliation between Caregiver A and Covered Entity A can be suspended temporarily or be terminated permanently. Consequently, Caregiver A is no longer actively affiliated with Covered Entity A. As such, the messaging platform 120 can be configured to remove Caregiver A as a participant in the conversation between Caregiver A and Caregiver B. Moreover, the messaging platform 120 can be configured to prohibit Caregiver A from accessing the conversation. In addition, when another caregiver who is actively affiliated with Covered Entity A (e.g., Caregiver B) initiates a patient-centered conversation owned by Covered Entity A, the messaging platform 120 can be configured to not identify Caregiver A as an authorized participant in the conversation.

In various embodiments, the affiliation between a caregiver and a covered entity can be linked with a privilege to administrate affiliations. For example, the affiliation between Caregiver A and Covered Entity A can be linked with an affiliation administrator privilege. According to one exemplary embodiment, a caregiver having affiliation administrator privilege for a covered entity is able add, activate, or reactivate an affiliation between another caregiver and the covered entity temporarily, permanently, and/or on a probationary basis. Alternately or in addition, the caregiver is able to deactivate or remove an affiliation between another caregiver and the covered entity temporary, permanently, and/or on a probationary basis.

FIG. 7A illustrates a screen display 700 according to various embodiments. Referring to FIGS. 1 and 7A, the screen display 700 can be part of the graphic user interface (GUI) provided by a messaging client (e.g., the first messaging client 150). As shown in FIG. 7A, the screen display 700 can show one or more conversations that a caregiver is engaged in. In one exemplary embodiment, the messaging client can be configured to display list enumerating the topic of each conversation. For example, Caregiver A can be engaged in multiple conversations including, for example, but not limited to, a patient-centered conversation regarding “Patient-John Doe.”

FIG. 7B illustrates a screen display 750 according to various embodiments. Referring to FIGS. 1 and 7B, the screen display 750 can also be a part of the GUI provided by the messaging client (e.g., the first messaging client 150). As shown in FIG. 7B, the messaging client can be configured to display a specific conversation, including messages (e.g., text, photographs) that have been exchanged during the course of the conversation. For example, as shown in FIG. 7B, a caregiver is engaged in a patient-centered conversation regarding “Patient-James Hafner.”

FIG. 8 illustrates a device 800 that is suitable for use in some embodiments of the systems and methods described herein. In some embodiments, the device 800 can be used to implement any of Devices 131-133 described with respect to FIGS. 1 and 2. In various embodiments, the device 800 can be used as is or in conjunction with one or more of the mechanisms or processes described above, and can represent components of server(s), user system(s), and/or other devices described herein. The device 800 can be a server or any conventional personal computer, or any other processor-enabled device that is capable of wired or wireless data communication. Other computer systems and/or architectures can be also used, as will be clear to those skilled in the art.

The device 800 preferably includes one or more processors, such as a processor 810. Additional processors can be provided, such as an auxiliary processor to manage input/output, an auxiliary processor to perform floating point mathematical operations, a special-purpose microprocessor having an architecture suitable for fast execution of signal processing algorithms (e.g., digital signal processor), a slave processor subordinate to the main processing system (e.g., back-end processor), an additional microprocessor or controller for dual or multiple processor systems, or a coprocessor. Such auxiliary processors can be discrete processors or can be integrated with the processor 810. Examples of processors which can be used with the device 800 include, without limitation, the Pentium® processor, Core i7® processor, and Xeon® processor, all of which are available from Intel Corporation of Santa Clara, Calif.

The processor 810 is preferably connected to a communication bus 870. The communication bus 870 can include a data channel for facilitating information transfer between storage and other peripheral components of the device 800. The communication bus 870 further can provide a set of signals used for communication with the processor 810, including a data bus, address bus, and control bus (not shown). The communication bus 870 can comprise any standard or non-standard bus architecture such as, for example, bus architectures compliant with industry standard architecture (ISA), extended industry standard architecture (EISA), Micro Channel Architecture (MCA), peripheral component interconnect (PCI) local bus, or standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE) including IEEE 488 general-purpose interface bus (GPIB), IEEE 696/S-100, and the like.

The device 800 preferably includes a main memory 820 and can also include a secondary memory 830. The main memory 820 provides storage of instructions and data for programs executing on the processor 810, such as one or more of the functions and/or modules discussed above. It should be understood that programs stored in the memory and executed by the processor 810 can be written and/or compiled according to any suitable language, including without limitation C/C++, Java, JavaScript, Pearl, Visual Basic, .NET, and the like. The main memory 820 is typically semiconductor-based memory such as dynamic random access memory (DRAM) and/or static random access memory (SRAM). Other semiconductor-based memory types include, for example, synchronous dynamic random access memory (SDRAM), Rambus dynamic random access memory (RDRAM), ferroelectric random access memory (FRAM), and the like, including read only memory (ROM). Attorney Docket No. 122745-003CT1

The secondary memory 830 can optionally include an internal memory 832 and/or a removable storage medium 430, for example a floppy disk drive, a magnetic tape drive, a compact disc (CD) drive, a digital versatile disc (DVD) drive, other optical drive, a flash memory drive, etc. The removable storage medium 430 is read from and/or written to in a well-known manner. The removable storage medium 430 can be, for example, a floppy disk, magnetic tape, CD, DVD, SD card, etc.

The removable storage medium 430 can be a non-transitory computer-readable medium having stored thereon computer executable code (i.e., software) and/or data (e.g., for implementing at least a portion of the subject matter described herein). The computer software or data stored on the removable storage medium 430 is read into the device 800 for execution by the processor 810.

In alternative embodiments, the secondary memory 830 can include other similar means for allowing computer programs or other data or instructions to be loaded into the device 800. Such means can include, for example, an external storage medium 445 and an interface 440. Examples of the external storage medium 445 can include, for example, but not limited to, an external hard disk drive or an external optical drive, or and external magneto-optical drive.

Other examples of the secondary memory 830 can include semiconductor-based memory such as programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), or flash memory (block oriented memory similar to EEPROM). Also included are a removable storage media 430 and a communication interface 850, which allow software and data to be transferred from an external medium 856 to the device 800.

The device 800 can include a communication interface 850. The communication interface 850 allows software and data to be transferred between the device 800 and various external devices (e.g. printers), networks, or information sources. For example, computer software or executable code can be transferred to the device 800 from a network server via the communication interface 850. Examples of the communication interface 850 include a built-in network adapter, network interface card (NIC), Personal Computer Memory Card International Association (PCMCIA) network card, card bus network adapter, wireless network adapter, Universal Serial Bus (USB) network adapter, modem, a network interface card (NIC), a wireless data card, a communications port, an infrared interface, an IEEE 1394 fire-wire, or any other device capable of interfacing the device 800 with a network or another computing device.

The communication interface 850 preferably implements industry promulgated protocol standards including, for example, but not limited to Ethernet IEEE 802 standards, Fiber Channel, digital subscriber line (DSL), asynchronous digital subscriber line (ADSL), frame relay, asynchronous transfer mode (ATM), integrated digital services network (ISDN), personal communications services (PCS), transmission control protocol/Internet protocol (TCP/IP), serial line Internet protocol/point to point protocol (SLIP/PPP), and so on, but can also implement customized or non-standard interface protocols as well.

Software and data transferred via Communication Interface 440 are generally in the form of electrical communication signals 852. The electrical communication signals 852 are preferably provided to the communication interface 850 via a communication channel 854. In one embodiment, the communication channel 854 can be a wired or wireless network, or any variety of other communication links. The communication channel 854 carries the electrical communication signals 852 and can be implemented using a variety of wired or wireless communication means including, for example, but not limited to, wire or cable, fiber optics, conventional phone line, cellular phone link, wireless data communication link, radio frequency (“RF”) link, or infrared link, just to name a few.

Computer executable code (i.e., computer programs or software) is stored in the main memory 820 and/or the secondary memory 830. Computer programs can also be received via the communication interface 850 and stored in the main memory 820 and/or the secondary memory 830. Such computer programs, when executed, enable the device 800 to perform the various functions, such as those described herein.

In this description, the term “computer readable medium” is used to refer to any non-transitory computer readable storage media used to provide computer executable code (e.g., software and computer programs) to the device 800. Examples of these media include the main memory 820, the secondary memory 830 (including the internal memory 832, the removable medium 834, and the external storage medium 445), and any peripheral device communicatively coupled with the communication interface 850 (including a network information server or other network device). These non-transitory computer readable mediums are means for providing executable code, programming instructions, and software to the device 800.

In an embodiment that is implemented using software, the software can be stored on a computer readable medium and loaded into the device 800 by way of the removable medium 834, the I/O interface 840, or the communication interface 850. In such an embodiment, the software is loaded into the device 800 in the form of the electrical communication signals 852. The software, when executed by the processor 810, preferably causes the processor 810 to perform the inventive features and functions previously described herein.

In an embodiment, the I/O interface 840 provides an interface between one or more components of the device 800 and one or more input and/or output devices. Example input devices include, without limitation, keyboards, touch screens or other touch-sensitive devices, biometric sensing devices, computer mice, trackballs, pen-based pointing devices, camera, microphone, and the like. Examples of output devices include, without limitation, cathode ray tubes (CRTs), plasma displays, light-emitting diode (LED) displays, liquid crystal displays (LCDs), printers, vacuum florescent displays (VFDs), surface-conduction electron-emitter displays (SEDs), field emission displays (FEDs), and the like.

The device 800 also includes optional wireless communication components that facilitate wireless communication over a voice and over a data network. The wireless communication components can comprise an antenna system 864, a radio system 862, a baseband system 860, or any combination thereof. In the device 800, radio frequency (RF) signals are transmitted and received over the air by the antenna system 864 under the management of the radio system 862.

In one embodiment, the antenna system 864 can comprise one or more antennae and one or more multiplexors (not shown) that perform a switching function to provide the antenna system 864 with transmit and receive signal paths. In the receive path, received RF signals can be coupled from a multiplexor to a low noise amplifier (not shown) that amplifies the received RF signal and sends the amplified signal to the radio system 862.

In alternative embodiments, the radio system 862 can comprise one or more radios that are configured to communicate over various frequencies. In one embodiment, the radio system 862 can combine a demodulator (not shown) and modulator (not shown) in one integrated circuit (IC). The demodulator and modulator can also be separate components. In the incoming path, the demodulator strips away the RF carrier signal leaving a baseband receive audio signal, which is sent from the radio system 862 to the baseband system 860.

If the received signal contains audio information, the baseband system 860 decodes the signal and converts it to an analog signal. Then the signal is amplified and sent to a speaker. The baseband system 860 also receives analog audio signals from a microphone. These analog audio signals are converted to digital signals and encoded by the baseband system 860. The baseband system 860 also codes the digital signals for transmission and generates a baseband transmit audio signal that is routed to the modulator portion of the radio system 862. The modulator mixes the baseband transmit audio signal with an RF carrier signal generating an RF transmit signal that is routed to the antenna system and can pass through a power amplifier (not shown). The power amplifier amplifies the RF transmit signal and routes it to the antenna system 864 where the signal is switched to the antenna port for transmission.

The baseband system 860 is also communicatively coupled with the processor 810. The processor 810 has access to the main memory 820 and the secondary memory 830. The processor 810 is preferably configured to execute instructions (i.e., computer programs or software) that can be stored in the main memory 820 or the secondary memory 830. Computer programs can also be received from the baseband processor 460 and stored in the main memory 820 or in the secondary memory 830, or executed upon receipt. Such computer programs, when executed, enable the device 800 to perform the various functions, such as those described herein. For example, the main memory 820 and the secondary memory 830 can each include various software modules (not shown).

Various embodiments may also be implemented primarily in hardware using, for example, components such as application specific integrated circuits (ASICs), or field programmable gate arrays (FPGAs). Implementation of a hardware state machine capable of performing the functions described herein will also be apparent to those skilled in the relevant art. Various embodiments may also be implemented using a combination of both hardware and software.

Furthermore, those of skill in the art will appreciate that the various illustrative logical blocks, modules, circuits, and method steps described in connection with the above described figures and the embodiments disclosed herein can often be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled persons can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the invention. In addition, the grouping of functions within a module, block, circuit or step is for ease of description. Specific functions or steps can be moved from one module, block or circuit to another without departing from the invention.

Moreover, the various illustrative logical blocks, modules, functions, and methods described in connection with the embodiments disclosed herein can be implemented or performed with a general purpose processor, a digital signal processor (DSP), an ASIC, FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor can be a microprocessor, but in the alternative, the processor can be any processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

Additionally, the steps of a method or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium including a network storage medium. An exemplary storage medium can be coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can also reside in an ASIC.

In situations in which the systems discussed here collect personal information about users, or can make use of personal information, the users can be provided with an opportunity to control whether programs or features collect user information (e.g., information about a user's social network, social actions or activities, profession, a user's preferences, or a user's current location), or to control whether and/or how to receive content from the content server that can be more relevant to the user. In addition, certain data can be treated in one or more ways before it is stored or used, so that personally identifiable information is removed. For example, a user's identity can be treated so that no personally identifiable information can be determined for the user, or a user's geographic location can be generalized where location information is obtained (such as to a city, ZIP code, or state level), so that a particular location of a user cannot be determined. Thus, the user can have control over how information is collected about the user and used by a content server.

Any of the software components described herein may take a variety of forms. For example, a component may be a stand-alone software package, or it may be a software package incorporated as a “tool” in a larger software product. It may be downloadable from a network, for example, a website, as a stand-alone product or as an add-in package for installation in an existing software application. It may also be available as a client-server software application, as a web-enabled software application, and/or as a mobile application.

Although a few example implementations have been shown and described, these example implementations are provided to convey the subject matter described herein to people who are familiar with this field. It should be understood that the subject matter described herein may be implemented in various forms without being limited to the described example implementations. The subject matter described herein can be practiced without those specifically defined or described matters or with other or different elements or matters not described. It will be appreciated by those familiar with this field that changes can be made in these example implementations without departing from the subject matter described herein as defined in the appended claims and their equivalents.

Various embodiments may also be implemented primarily in hardware using, for example, components such as application specific integrated circuits (ASICs), or field programmable gate arrays (FPGAs). Implementation of a hardware state machine capable of performing the functions described herein will also be apparent to those skilled in the relevant art. Various embodiments may also be implemented using a combination of both hardware and software.

Furthermore, those of skill in the art will appreciate that the various illustrative logical blocks, modules, circuits, and method steps described in connection with the above described figures and the embodiments disclosed herein can often be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled persons can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the invention. In addition, the grouping of functions within a module, block, circuit or step is for ease of description. Specific functions or steps can be moved from one module, block or circuit to another without departing from the invention.

Moreover, the various illustrative logical blocks, modules, functions, and methods described in connection with the embodiments disclosed herein can be implemented or performed with a general purpose processor, a digital signal processor (DSP), an ASIC, FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor can be a microprocessor, but in the alternative, the processor can be any processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

Additionally, the steps of a method or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium including a network storage medium. An exemplary storage medium can be coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can also reside in an ASIC.

While certain embodiments have been described above, it will be understood that the embodiments described are by way of example only. Accordingly, the systems and methods described herein should not be limited based on the described embodiments. Rather, the systems and methods described herein should only be limited in light of the claims that follow when taken in conjunction with the above description and accompanying drawings.

Claims

1. A system, comprising:

a messaging platform comprising at least one application server and configured to: receive a first message generated for a first device of a first caregiver; and broadcast the first message over a paging system;

a first dedicated compact device (CDD) associated with the first device of the first caregiver, wherein the first CDD comprises a long range radio frequency (RF) system and a short range RF system, and is configured to: receive, using the long range RF system, the first message broadcast by the messaging platform over the paging system; transmit, using the short range RF system, the first message to the first device of the first caregiver; and provide an alert to the first caregiver based on an alert rule; and

a first messaging client associated with the first caregiver and is installed on the first device of the first caregiver, wherein the first messaging client is configured to: receive the first message from the first CDD; and provide at least a portion of the first message to the first caregiver.

2. The system as recited in claim 1, wherein the first CDD is associated with a first pager identifier.

3. The system as recited in claim 1, wherein the messaging platform is further configured to:

store a device map correlating a first pager identifier of the first CDD to the first device of the first caregiver, and a second pager identifier of a second CDD to a second device of a second caregiver;

determine, based at least in part on the device map, that the first pager identifier corresponds to the first device that is a intended target device of the message; and

broadcast the first message with the first pager identifier of the first CDD.

4. The system as recited in claim 3, wherein the first CDD is configured to transmit the first message to the first device of the first caregiver in response to a determination that the first message is transmitted with the first pager identifier.

5. The system as recited in claim 3, wherein the first CDD is configured to:

receive, using the long range RF system, a second message broadcast by the messaging platform over the paging system;

determine that the second message is transmitted with a second pager identifier that does not match the first pager identifier associated with the first CDD; and

in response to the determination that the second message is transmitted with the second pager identifier, disregard the second message.

6. The system as recited in claim 1, wherein the alert rule is configured by the first caregiver.

7. The system as recited in claim 1, wherein the alert rule includes always providing an alert to the first caregiver in response to receiving a message from the messaging platform.

8. The system as recited in claim 1, wherein the alert rule includes providing an alert to the first caregiver in response to detecting that the message is not successfully transmitted to the first device of the first caregiver within a predetermined amount of time.

9. The system as recited in claim 1, wherein the alert rule includes transmitting the message to the first device of the first caregiver instead of providing an alert to the first caregiver.

10. The system as recited in claim 1, wherein the short range RF system comprises a near field communication (NFC) system.

11. The system as recited in claim 1, wherein the short range RF system comprises a Bluetooth system.

12. The system as recited in claim 1, wherein the CDD further comprises an audio connector and is configured to connect to the first device of the first caregiver via the audio connector.

13. The system as recited in claim 1, wherein the CDD is further configured to store the first message prior to transmitting the first message to the first device of the first caregiver.

14. The system as recited in claim 1, wherein the CDD is further configured to delete the first message in response to successfully transmitting the first message to the first device of the first caregiver.

15. The system as recited in claim 1, wherein the alert comprises at least one of the following: an audio alert, a tactile alert, and a visual alert.

16. The system as recited in claim 1, wherein the messaging platform is further configured to encrypt the first message.

17. The system as recited in claim 16, wherein the CDD is configured to transmit the encrypted first message to the first device of the first caregiver.

18. The system as recited in claim 16, wherein the first messaging client is provisioned with a key to decrypt the first message and the first CDD is not provisioned with the key to decrypt the first message.

19. The system as recited in claim 18, wherein the first messaging client is configured to use the key to decrypt the encrypted first message received from the first CDD.

20. A system, comprising:

a messaging platform comprising at least one application server and configured to: receive a first message intended for a first device of a first caregiver; transmit the first message; and broadcast a notification corresponding to the first message over a paging system;

a first dedicated compact device (CDD) associated with the first device of the first caregiver, wherein the first CDD comprises a long range radio frequency (RF) system and a short range RF system, and is configured to: receive, using the long range RF system, the notification corresponding to the first message broadcast by the messaging platform over the paging system; and provide an alert to the first caregiver in response to the receiving the notification; and

a first messaging client associated with the first caregiver and is installed on the first device of the first caregiver, wherein the first messaging client is configured to: receive the first message from the messaging platform; and provide at least a portion of the first message to the first caregiver.

21. The system as recited in claim 20, wherein the messaging platform is further configured to encrypt the first message prior to transmitting the first message.

22. The system as recited in claim 21, wherein the first messaging client is provisioned with a key to decrypt the first message.

23. The system as recited in claim 22, wherein the first messaging client is further configured to use the key to decrypt the encrypted first message received from the messaging platform.

24. A method comprising

receiving, using a long range RF system, a first message broadcast by a messaging platform over a paging system, wherein the first message is generated for the first device of a first caregiver, the first message sent via a broadcast over a paging system from an application server, wherein the long range RF system is associated with a first dedicated compact device (CDD) associated with the first device of the first caregiver, wherein the first CDD further comprises a short range RF system;

encrypting the first message;

transmitting, using the short range RF system, the encrypted first message to the first device of the first caregiver; and

providing an alert to the first caregiver based on an alert rule, wherein a first messaging client is associated with the first device of the first caregiver to receive the encrypted first message from the first CDD, decrypt the first message, and provide at least a portion of the first message to the first caregiver.

25. The method of claim 24, wherein the first messaging client is provisioned with a key to decrypt the first message and the first CDD is not provisioned with the key to decrypt the first message.

26. The method of claim 25, wherein the first messaging client is configured to use the key to decrypt the encrypted first message received from the first CDD.

27. A non-transitory computer-readable medium comprising instructions, that when executed by one or more processing devices cause the processing device to:

receive, via a long range RF system, a first message broadcast by a messaging platform, wherein the first message is generated for the first device of a first caregiver, wherein the long range RF system is associated with a first dedicated compact device (CDD) associated with the first device of the first caregiver, wherein the first CDD further comprises a short range RF system;

transmit, via the short range RF system, the first message to the first device of the first caregiver; and

providing an alert to the first caregiver based on an alert rule, wherein a first messaging client is associated with the first device of the first caregiver to receive the first message from the first CDD, and provide at least a portion of the first message to the first caregiver.