Secure healthcare communication exchange platform

Methods and systems for providing a secure healthcare communication exchange platform. The methods and systems perform operations comprising: accessing a collection of data records from a plurality of sources, the collection of data records corresponding to a given entity; generating, based on the collection of data records, an aggregated representation of one or more conditions associated with the given entity; determining, based on the aggregated representation, that a given condition of the one or more conditions satisfies an outreach parameter; in response to determining that the given condition satisfies the outreach parameter, triggering an outreach event to communicate with the given entity; generating status information in the aggregated representation, the status information corresponding to the outreach event; and tracking the status information to establish a relationship between the given condition and the outreach parameter.

BACKGROUND

Modern day healthcare systems are fragmented and complicated. A patient receives a prescription and fills the prescription at a local pharmacy. Once the patient receives their medication, there are very limited resources available to the prescribing physicians and pharmacy to follow up with the patient on their medication. Also, the pharmacy and physician have a very limited and individualized view as to the patient's medications and treatment.

DETAILED DESCRIPTION

Example methods and systems for a secure healthcare platform system are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be evident, however, to one of ordinary skill in the art that embodiments of the invention may be practiced without these specific details.

Healthcare systems allow physicians to prescribe treatment or medication to a patient, or refer a patient for treatment by another care provider. The patient ultimately receives the prescribed treatment or medication from another source. However, there is a lack of coordination and communication of the prescribed treatment or medication the patient receives back to the physician or between caregivers. Also, after dispensing a given drug to a patient, the pharmacy has minimal resources to ensure the patient is adhering to the prescribed medication. Typical healthcare systems lack a common infrastructure that allows the physicians, clinicians, caregivers and pharmacies to have a common holistic view of treatment being received by a particular patient. For example, the pharmacy lacks resources to see what other medications a patient may be receiving and how well or poorly the patient is adhering to or responding to such medication. Because of this, various outreach opportunities to connect with the patients to address issues pertaining to treatment they receive are missed which adversely impacts patient care. The adverse care can be due to the lack of a central repository for communications between healthcare providers, which can ensure that the referral receiving healthcare provider receives a complete referral with all required information fields from the referring healthcare provider and that the referral receiving healthcare provider confirms acceptance of the referral.

Even still, when a pharmacist or physician identifies an outreach opportunity to connect with a given patient, such opportunities are addressed in a way that puts the given patient's secure information at risk. For example, the pharmacist or physician sends an unsecured email or message to someone else or between each other to contact the given patient. The unsecured email or message contains personal and health information associated with the given patient and can potentially be exposed to unauthorized individuals.

Some disclosed embodiments provide a secure healthcare communication exchange platform. The disclosed secure healthcare communication exchange platform allows patient-based referrals to be generated and tracked securely without placing the patient's information at risk of exposure to unauthorized individuals. Patient-based referrals can include a communication coordinating care, such as supplementary care outside of a physician's office, for a particular patient from one entity to another. As an example, the secure healthcare communication exchange platform receives a collection of data about a patient from various external and internal sources, including biometric information, prescription or pharmacy information, medical information and laboratory information. The secure healthcare communication exchange platform can detect that a patient has been recently diagnosed with a given condition and can trigger an outreach event to coordinate additional care to address the given condition.

In an embodiment, the secure healthcare communication exchange platform provides a holistic view of the care being received and provided to a patient and can identify gaps in care that is provided to the patient (e.g., missed doses of a drug, non-adherence to medication, supplementary care that is not being provided, acceptance at a referral receiving caregiver's system and the like). The secure healthcare communication exchange platform can direct or refer another individual, such as a clinician or patient support entity that has access to the secure healthcare communication exchange platform, to communicate with the patient to address the gaps in care. In one example, the secure healthcare communication exchange platform can determine that the collection of data about the patient indicates that the patient has a question about a medication. In response, the secure healthcare communication exchange platform transmits a message or communication to a pharmacist who has access to the secure healthcare communication exchange platform to perform an outreach event, such as contacting the patient to discuss the medication.

In some embodiments, the disclosed methods and systems access a collection of data records from a plurality of sources, the collection of data records corresponding to a given entity and generate, based on the collection of data records, an aggregated representation of one or more conditions associated with the given entity. The disclosed embodiments determine that a given condition of the one or more conditions satisfies an outreach parameter and, in response, trigger an outreach event to communicate with the given entity. The disclosed embodiments generate status information in the aggregated representation corresponding to the outreach event and track the status information to establish a relationship between the given condition and the outreach parameter.

In some embodiments, the presently disclosed systems and methods store a plurality of roles and assign these roles to individuals associated with specific machines or individual machines accesses data in the system related to referrals. The roles have different levels of access to information and communications within the system. This assists with securing the information and the communications. A first role has no access to referral workflow or referral data. A second role is a population health manager, which has access to data relating to patient data and accumulated health data. A third role is an external user that has access to the referral workflow and data relating to referrals. A fourth role is an internal user that has access to the referral workflow and data relating to referrals. A fifth role is a patient care consultant that has access to the referral workflow and data relating to referrals. A fifth role can be a third party vendor that has access to summary data, e.g., overview tables, but not any individual identifying data. The roles can be expanded to include other authorized roles that allow access to patient information and other non-authorized roles that do not allow access to patient information.

FIG.1is a block diagram showing an example system100according to various exemplary embodiments. The system100includes one or more client devices110, one or more healthcare provider devices120, a secure healthcare communication exchange platform150, and one or more healthcare data source(s) that are communicatively coupled over a network130(e.g., Internet, telephony network).

As used herein, the term “client device” may refer to any machine that interfaces to a communications network (such as network130) to access the secure healthcare communication exchange platform150. The client device110may be, but is not limited to, a mobile phone, desktop computer, laptop, portable digital assistants (PDAs), smart phones, a wearable device (e.g., a smart watch), tablets, ultrabooks, netbooks, laptops, multi-processor systems, microprocessor-based or programmable consumer electronics, game consoles, set-top boxes, or any other communication device that a user may use to access a network or the secure healthcare communication exchange platform150. The client device110is a device dedicated to interacting with the secure healthcare communication exchange platform150with the client device110being loaded with instructions related to the secure healthcare communication exchange platform150.

In some cases, the secure healthcare communication exchange platform150is accessible over a global communication system, e.g., the Internet or world wide web. In such instances, the secure healthcare communication exchange platform150hosts a website that is accessible to the client devices110. Upon accessing the website, the client devices110provide secure login credentials, which are used to access a profile associated with the login credentials. One or more user interfaces associated with the secure healthcare communication exchange platform150(such as the user interfaces discussed in connection withFIGS.3-11) are provided over the Internet via the website to the client devices110.

The client devices110may be associated with respective patients. As an example, the client devices110may include health monitoring equipment that is connected over the Internet to the secure healthcare communication exchange platform150. Such health monitoring equipment can include remote blood pressure monitoring devices, glucose monitoring devices, heart monitoring devices, and the like. These health monitoring devices can periodically transmit information that identifies a given patient and provides health related information to the secure healthcare communication exchange platform150. The secure healthcare communication exchange platform150receives such information and stores the information as biometric data associated with the given patient. The client devices110, when used by a given patient to access the secure healthcare communication exchange platform150can view only records that contain information for the particular patient and some but not all portions of the notes associated with the particular patient.

Healthcare provider devices120can include the same or similar functionality as client devices110for accessing the secure healthcare communication exchange platform150. In some cases, the healthcare provider devices120are used by “internal” users. Internal users are personnel, such as physicians, clinicians, healthcare providers, health-related coaches or the like that are associated with or employed by an organization that provides the secure healthcare communication exchange platform150. In some cases, the healthcare provider devices120are used by “external” users. External users are personnel, such as physicians, clinicians, and health-related coaches that are associated with or employed by a different (external) organization than that which provides the secure healthcare communication exchange platform150.

The healthcare provider devices120, when used by internal or external users, to access the secure healthcare communication exchange platform150can view many records associated with many different patients. Different levels of authorization can be associated with different internal and different external users to control which records the internal and external users have access. In some instances, only records associated with those patients to which a given internal or external user is referred, are made accessible and available to the given internal or external user device. Sometimes, a first internal or external user can refer a patient or records associated with the patient to a second internal or external user. In such circumstances, the second internal or external user becomes automatically authorized to access and view the patient's records that were referred by the first internal or external user. In an example embodiment, a referral flag can be set in a patient record in the database at the secure healthcare communication exchange platform150. The referral flag can cause the platform to check an access authorization table that stores access authorization rights to the patient information fields in the database152.

The healthcare data sources140provide data records that include healthcare related information for one or more patients. The data records can include multiple hundreds of terabytes of data, which cannot be processed by hand with enough speed for modern healthcare services. The secure healthcare communication exchange platform150aggregates the data records received from the healthcare data sources140into a collection of data records for each individual patient. Namely, each data record may be tagged with a unique patient identifier (that may or may not include the patient's name). The secure healthcare communication exchange platform150collects all the records with the same patient identifier into a single collection associated with the patient. The secure healthcare communication exchange platform150stores the collected records in the database152as a collection of data records220. The collection of data records220indexes various patient records that have been collected to enable quick and efficient searching and analysis of the patient records.

As an example, one of the healthcare data sources140may include pharmacy claims associated with the patent (e.g., the given entity), stored in records. In this case, the secure healthcare communication exchange platform150communicates with multiple pharmacies or pharmacy servers to collect pharmacy claims that indicate medication a given patient receives. This way, if the patient fills prescriptions at many different pharmacies, the secure healthcare communication exchange platform150can collect all the claims from the various pharmacies into a single location. A clinician or internal or external user can use a healthcare provider device120to access the patient record and view all the medications the patient has filled even though they were filled at many different pharmacies. In another implementation, the secure healthcare communication exchange platform150communicates with a health insurance carrier associated with the given patient as the healthcare data source140. The health insurance carrier may securely provide all of the pharmacy related claims that include medication names and doses a given patient was prescribed. The secure healthcare communication exchange platform150collects all the medication information into a single record associated with the patient that is made accessible to one or more internal and external users via their respective healthcare provider devices120.

As another example, one of the healthcare data sources140may include medical data associated with the given entity. In this case, the secure healthcare communication exchange platform150communicates with multiple physician offices and/or hospitals to collect health services a given patient receives. A clinician, an internal user, or an external user can use a healthcare provider device120to access the patient record and view all the health services the patient has received. In another implementation, the secure healthcare communication exchange platform150communicates with a health insurance carrier associated with the given patient as the healthcare data source140. The health insurance carrier may securely provide all of the health services related claims that include physician types or medical services the patient receives (e.g., physical therapy services, hospital visits, and the like). The secure healthcare communication exchange platform150collects all the health services information, from various servers, into a single record associated with the patient that is made accessible to one or more internal and external users via their respective healthcare provider devices120.

As another example, one of the healthcare data sources140may include laboratory information associated with the given entity. In this case, the secure healthcare communication exchange platform150communicates with multiple laboratory servers to collect laboratory claims that indicate lab results a given patient receives. A clinician or internal or external user can use a healthcare provider device120to access the patient record and view all the laboratory results associated with the patient. In another implementation, the secure healthcare communication exchange platform150communicates with a health insurance carrier server associated with the given patient as the healthcare data source140. The health insurance carrier server may securely provide all of the laboratory related claims that include laboratory results for a given patient. The secure healthcare communication exchange platform150collects all the laboratory information into a single record associated with the patient that is made accessible to one or more internal and external users via their respective healthcare provider devices120.

As another example, one of the healthcare data sources140or the client devices110may include or provide biometric data associated with the given entity. Specifically, the secure healthcare communication exchange platform150may receive a first type of biometric data (e.g., blood pressure information) of a given patient directly from the client device110associated with the given patient. In such cases, the healthcare data source140does not provide the first type of biometric data for the given patient. In another example, the secure healthcare communication exchange platform150may receive a second type of biometric data (e.g., blood glucose levels) from the healthcare data source140and not from the client device110. Namely, a given patient may be in possession of a remote blood pressure monitoring devices but may not be in possession of a glucometer. As such, the secure healthcare communication exchange platform150receives the first type of biometric data directly from the client device110of the patient and receives the second type of biometric data from the healthcare data source140. In one implementation, the patient visits a site that has a glucometer and that provides the glucometer reading to the healthcare data source140. The healthcare data source140then routes the glucometer reading to the secure healthcare communication exchange platform150using a patient identifier of the patient.

The healthcare provider device120can be associated with external providers, who can be assigned roles within communication exchange platform150. The platform150can assign external users to rights to access certain data based on a role assigned to that user. Multiple external users may have access to the same or overlapping data for a patient or a patient population. In an example embodiment, external users can assign/reassign to patient health information to other internal users or external users with the data remaining in the platform150, e.g., in the database152. In order to assign or reassign the patient health information, the users share a same client population. Internal users are able to assign/re-assign patient health information, e.g., tasks to other internal users or to other external users. The internal users have access to a client population, a book of business or other subgroupings of patient information in order to be assigned or reassigned a patient information or task. Likewise, an internal user assigning or reassign can assign or reassign to an external user, the external user must have access to the client population. Internal users can also intercede and take action on referral regardless if they are the user assign the action or receiving the action. This allows the internal user intercede in a task to keep a task on schedule or correct errors. Additionally, if a task is assigned to an external user who does not take action, the internal user can reassign the task to a new external user or request information from the external user who has not taken action in a timely manner.

FIG.2is an example database152that may be deployed within the system ofFIG.1, according to some embodiments. As shown, the database152includes one or more outreach parameter(s)210and a collection of data records220.

The one or more outreach parameter(s)210may include criteria that specifies when a given condition or set of conditions of a patient indicate that an outreach to the patient is needed (e.g., an outreach event) to connect with the patient about the conditions. For example, the outreach parameter can include a maximum amount of time allowable for not filling a medication or a threshold amount of late fill period for a given medication or set of medications. The outreach parameter can, additionally or alternatively, include a set of conditions (e.g., patient recently diagnosed with a chronic condition or has recently been discharged from the hospital). When the set of conditions is detected in combination, the outreach parameter is satisfied. The outreach parameter can, additionally or alternatively, include a maximum spend on medications such that when a patient spends more than a threshold amount on the medications, an outreach event is triggered.

In some embodiments, an internal user or an external user can access the secure healthcare communication exchange platform150using the healthcare provider device120to view one or more patient records. The secure healthcare communication exchange platform150can provide an aggregated representation of one or more conditions associated with one or more patients. As an example, the secure healthcare communication exchange platform150can present to the internal or external user a graphical user interface shown inFIG.3. The graphical user interface300(which can be output onto a display screen) may be provided after the internal or external user is authenticated by logging in using their respective secure credentials. The user interface300allows the internal or external user to select an outreach parameter. For example, the user can select adherence metrics and/or omission of care metrics and/or care optimization metrics. In response to receiving a user selection of an option to view adherence metrics as the outreach parameter, a list of adherence criteria is presented, as shown in user interface300. In response to receiving a user selection of an option to view care optimization metrics as the outreach parameter, a list of care optimization criteria is presented, as shown in graphical user interface400(FIG.4).

The graphical user interfaces300,400ofFIGS.3and4can be presented to the user on the healthcare provider device120of the internal or external user, here shown as internal user1. The healthcare provider device120can receive a user selection of one of the criteria shown inFIG.3or4. As an example, a user input may be received that selects the diabetes adherence criterion of the adherence metrics shown inFIG.3. In response, a graphical user interface500(FIG.5) is presented to the user on the healthcare provider device120. Specifically, the secure healthcare communication exchange platform150can automatically analyze all of the records stored in the collection of data records220to generate a statistical measure of adherence. This statistical measure is provided in the graphical user interface500. In one example, the secure healthcare communication exchange platform150applies one or more trained machine learning models (e.g., a convolutional neural network) to derive relationships between the data stored in the collection of data records220to generate predictions as to adherence or other outreach parameters shown inFIG.3.

The statistical measure can include a first metric510representing a quantity or percentage of all patients who are classified as non-adherent to their medications. The statistical measure can include a second metric512representing a quantity or percentage of all patients who are classified as being adherent to their medications. The statistical measure can include a third metric514representing a quantity or percentage of all patients who have not met the selected diabetes adherence criterion. The user can select one of the statistical measures presented in the user interface500to access the population associated with the metric. For example, in response to receiving a user selection of the first metric, a view population option520is presented. In response to receiving a user selection of the view population option520, a list of all patients who were classified as non-adherent can be presented. In some cases, the list of all patients who were classified as non-adherent can be sorted and ranked based on risk categories. Namely, patients who are at greatest risk of having adverse health reactions because they are non-adherent can be automatically identified and presented at the top of the list.

In response to receiving a user selection of a given patient from the presented list, the collection of data records220associated with the given patient is retrieved. The collection of data records220associated with the given patient is aggregated into a representation shown in graphical user interface600(FIG.6). The user interface600includes various regions including a patient information region610and a condition related region620. The patient information region610includes a first plurality of fields that identify the given patient (entity). For example, the first plurality of fields includes a patient name, date of birth, age, gender, risk score, and the like. The condition related region620includes a second plurality of fields associated with the one or more conditions. The second plurality of field, for example, includes an outreach field, an opportunities field, a referrals field, a medications field, a conditions field, an allergies field, a lab data field, and/or a remote monitoring field. Each field of the second plurality of fields may include data that has been collected from the healthcare data sources140and/or from the client device110of the given patient or entity.

As an example, input is received that selects the medications field of the second plurality of fields from the condition related region620. In response, the secure healthcare communication exchange platform150obtains a list of medications that the patient is currently prescribed and medications that the patient has been prescribed in the past. Information about each medication is presented that includes a medication name/strength, manner of supply, quantity, fill date, late to fill period, days supply, prescriber identifier and pharmacy identifier. Based on the list of medications, the user can determine that a given condition of the one or more conditions satisfies an outreach parameter. For example, if the late fill period indicating how late the patient was at re-filling the medication exceeds a threshold time period, the user can determine that an outreach parameter is met. In this case, the outreach parameter is a parameter that indicates the patient may be having trouble accessing the pharmacy on time or lacks resources to obtain their prescriptions timely. In some cases, the secure healthcare communication exchange platform150automatically highlights or visually identifies a given medication that satisfies an outreach parameter. The user can select the medication to generate a referral request.

As another example, input is received that selects the lab data field of the second plurality of fields from the condition related region620. In response, the secure healthcare communication exchange platform150obtains a list of current and past laboratory results associated with the patient and presents the laboratory results in user interface700(FIG.7). Information about each laboratory result is presented that includes a name of the lab test, a date the lab test was reported or collected, the result of the lab test, a threshold high and low range, a units, a code for the test and the identifier of who ordered the laboratory test. Based on the list of laboratory results, the user can determine that a given condition of the one or more conditions satisfies an outreach parameter. For example, if a threshold number of laboratory tests exceed the maximum (high) range or are below the low or minimum range by more than a threshold amount or value, the user can determine that an outreach parameter is met. In this case, the outreach parameter is a parameter that indicates the patient may be suffering from a chronic condition. In some cases, the secure healthcare communication exchange platform150automatically highlights or visually identifies a given one or more laboratory results that satisfy an outreach parameter. The user can select the laboratory results to generate a referral request.

As another example, input is received that selects the opportunities field of the second plurality of fields from the condition related region620. In response, the secure healthcare communication exchange platform150obtains a list of conditions associated with the patient that satisfy one or more outreach parameters and presents such conditions in user interface800(FIG.8). For example, the secure healthcare communication exchange platform150can routinely, periodically or continuously process healthcare data associated with patients to detect patterns of behavior or health conditions that can be address with an outreach event (e.g., by communicating with the patient directly about the conditions). Namely, the secure healthcare communication exchange platform150can automatically identify medications that have not been re-filled within a threshold amount of time and list such medications among the opportunities presented in user interface800. The opportunities presented in user interface800include a description of the condition (e.g., adherence or lack thereof to a particular medication or other social or economic related condition). As an example, the secure healthcare communication exchange platform150can apply various machine learning techniques to the collection of data associated with a given patient to identify an opportunity or condition that satisfies the outreach event. The user can select an opportunity presented in user interface800to generate a referral request.

In response to determining that the outreach parameter has been met, the user can start a referral to connect with the given patient. For example, the user can use the healthcare provider device120to instruct the secure healthcare communication exchange platform150to trigger an outreach event to communicate with the patient. In one example, the secure healthcare communication exchange platform150receives a user selection of the referrals field and presents a graphical user interface900(FIG.9) that allows the user to input various information for creating a new referral. Specifically, the user can identify a second internal or external user (e.g., by inputting a particular organization and/or identifier of the second internal or external user). The user can also input one or more reasons for the referral in a description field (e.g., patient support, pharmacy support, practitioner support, healthcare support, pharmaceutical support, need for medicine disposal equipment, need for a remote monitoring device, and the like). Once the user completes the referral, the second internal or external user identified in the referral is notified to act on the outreach event to connect with the patient. The secure healthcare communication exchange platform150tracks and maintains the status of the outreach event until the outreach event is closed.

The second internal or external user is provided with authorization to access the aggregated information for the patient identified by the first user. The second user can log into the secure healthcare communication exchange platform150via the Internet using the healthcare provider device120associated with the second user. In response, the secure healthcare communication exchange platform150presents the second user with a full list of pending referrals and their respective status, such as in a graphical user interface1000(FIG.10). For example, graphical user interface1000provided by the secure healthcare communication exchange platform150presents a total number of pending referrals that have not yet been completed, a total number of completed referrals and a total number of canceled or re-routed referrals. These total numbers are representative of referrals that have been directed to the second user. The total number of canceled referrals represents referrals that the second user has initiated based on analyzing various patient conditions and that the second user has ultimately canceled. The total number of re-routed referrals represents a total number of referrals that the second user has received and has re-directed to an alternate user.

The second user can sort or filter the full list of referrals by who made the referral (e.g., the first user or organization of the first user), reason for the referral (e.g., patient support, pharmacy support, practitioner support, and the like), date, patient name, and/or any combination thereof. The second user can select an option to access the pending referrals. In response, the list of pending referrals including patient names and reasons for the referrals is presented. The second user can sort or filter the pending list of referrals by who made the referral (e.g., the first user or organization of the first user), reason for the referral (e.g., patient support, pharmacy support, practitioner support, and the like), date, patient name, and/or any combination thereof. In response to the secure healthcare communication exchange platform150receiving input from the second user that selects a given patient referral, the secure healthcare communication exchange platform150presents graphical user interface1100(FIG.11) to the second user.

The user interface1100provides various information about the patient and various information about the conditions that led to the referral (e.g., the reasons specified by the first user). The second user can review this information and contact the patient. For example, the second user can call, email, fax, text, or otherwise contact the patient, such as by transmitting a notification to the client device110of the patient. Once contact with the patient has been established by the second user, details about the communication with the patient can be entered by the second user into the referral of the aggregated information associated with the patient maintained by the secure healthcare communication exchange platform150. Specifically, the second user can select a log outreach option1010. In response, a window is presented that allows the user to enter the time, date and comments received from the patient during the outreach event. In some cases, as a result of the outreach event, the second user can determine that the patient is in need of a health monitoring device. In response, the second user can select a request item option1120to select from a list of available health monitoring equipment to send to the patient. Such health monitoring equipment can enable the secure healthcare communication exchange platform150to obtain health related information and measurements directly from the patient.

In some cases, the second user can determine that an alternate user is better suited to handle a given referral that has been assigned to the second user. In such circumstances, the second user can select the re-assign referral option1130. In response, the secure healthcare communication exchange platform150allows the second user to specify the identifying information for the alternate internal or external user and the secure healthcare communication exchange platform150notifies the selected alternate user to conduct or complete the outreach event. Once the referral has been re-assigned by the second user to the alternate user, access to the given patient's information and data record collection is disabled and the second user becomes de-authorized from accessing the patient record information. Namely, access for the second user becomes disabled preventing the second user from accessing the patient records after the second user re-assigns the referral to the alternate user.

The first user who initiated the referral to the second user can continue to log into the secure healthcare communication exchange platform150to access a list of referrals that the first user has made. The secure healthcare communication exchange platform150presents to the first user the current status of each referral the first user has made. This allows the first user to continue to track the referrals and their respective status. The first user can also modify or cancel any referral the first user has made. In response to canceling the referral, access previously granted to the second user and/or alternate user is restricted or denied and the referral is added to a list of canceled referrals provided to the first user. The secure healthcare communication exchange platform150can also notify the first user when a given referral has been completed (e.g., when an outreach event has been conducted, such as when a log outreach option1110has been selected). The secure healthcare communication exchange platform150can monitor the patient records overtime, such as after 90 days, to determine whether the same condition that has resulted in the outreach event to be triggered has been resolved. For example, the secure healthcare communication exchange platform150can determine whether adherence of the patient to a given medication has increased or whether the patient time for refilling a given medication has been decreased since the outreach even was conducted.

FIG.12is a flowchart illustrating example operations of the secure healthcare communication exchange platform in performing process1200, according to example embodiments. The process1200may be embodied in computer-readable instructions for execution by one or more processors such that the operations of the process1200may be performed in part or in whole by the functional components of the system100; accordingly, the process1200is described below by way of example with reference thereto. However, in other embodiments, at least some of the operations of the process1200may be deployed on various other hardware configurations. Some or all of the operations of process1200can be in parallel, out of order, or entirely omitted.

At operation1201, the secure healthcare communication exchange platform150receives an external user selection of a patient to create a referral. For example, the secure healthcare communication exchange platform150receives input from a first user that selects a referral request for a given patient.

At operation1202, the secure healthcare communication exchange platform150receives an external user selection of an internal user and a reason for referral. For example, the secure healthcare communication exchange platform150presents graphical user interface900(FIG.9) allowing a first user to specify a second user and a reason for referral.

At operation1203, the secure healthcare communication exchange platform150triggers an outreach event by routing the referral to the internal user. For example, the secure healthcare communication exchange platform150notifies the second user, such as by adding the referral made by the first user to a list of pending referrals presented to the second user in graphical user interface1000(FIG.10).

At operation1204, the secure healthcare communication exchange platform150provides referral status to the external user. For example, the secure healthcare communication exchange platform150allows the first user to log in and view the current status of referrals made by the first user.

At operation1205, the secure healthcare communication exchange platform150allows the external user to cancel/comment on the referral.

At operation1206, the secure healthcare communication exchange platform150receives input from the internal user assigning an alternate user to complete the outreach event. For example, the second user can select an option from user interface1100to route the referral to an alternate user.

At operation1207, the secure healthcare communication exchange platform150authenticates or authorizes the internal user to access the patient information. For example, the second user becomes authorized to access the patient records of the patient identified by the first user.

At operation1208, the secure healthcare communication exchange platform150receives input from the internal user updating the referral status information. For example, the second user inputs when and how the patient was contacted and any additional information obtained from the patient during the contact.

At operation1209, the secure healthcare communication exchange platform150performs an outreach event. For example, the second user initiates contact or communication with the patient, such as by phone call, email, text, fax, in person, or otherwise.

At operation1210, the secure healthcare communication exchange platform150logs the outreach status. For example, the second selects a log outreach option in user interface1100indicating that contact has been established with the patient.

FIG.13is a flowchart illustrating example operations of the secure healthcare communication exchange platform in performing process1300, according to example embodiments. The process1300may be embodied in computer-readable instructions for execution by one or more processors such that the operations of the process1300may be performed in part or in whole by the functional components of the system100; accordingly, the process1300is described below by way of example with reference thereto. However, in other embodiments, at least some of the operations of the process1300may be deployed on various other hardware configurations. Some or all of the operations of process1300can be in parallel, out of order, or entirely omitted.

At operation1301, the secure healthcare communication exchange platform150accesses a collection of data records from a plurality of sources that correspond to a given entity. For example, the secure healthcare communication exchange platform150accesses data from the healthcare data sources140that includes various medical information corresponding to one or more patients (FIG.1).

At operation1302, the secure healthcare communication exchange platform150generates, based on the collection of data records, an aggregated representation of one or more conditions associated with the given entity. For example, the secure healthcare communication exchange platform150aggregates the information received from the sources140into a graphical user interface, such as the graphical user interface600(FIG.6) for a given patient.

At operation1303, the secure healthcare communication exchange platform150determines, based on the aggregated representation, that a given condition of the one or more conditions satisfies an outreach parameter. For example, the secure healthcare communication exchange platform150identifies medications that are not being filled timely or within a threshold time period.

At operation1304, the secure healthcare communication exchange platform150triggers an outreach event to communicate with the given entity in response to determining that the given condition satisfies the outreach parameter. For example, the secure healthcare communication exchange platform150allows an internal or external user to generate a referral, such as via the graphical user interface900(FIG.9).

At operation1305, the secure healthcare communication exchange platform150generates status information in the aggregated representation that corresponds to the outreach event. For example, the internal or external user can access the secure healthcare communication exchange platform150to view the current status of referrals, such as whether the patient has been contacted and any comments received from the patient.

At operation1306, the secure healthcare communication exchange platform150tracks the status information to establish a relationship between the given condition and the outreach parameter. For example, the secure healthcare communication exchange platform150can determine whether the patient at a later time refills the medication timely.

FIG.14is a block diagram illustrating an example software architecture1406, which may be used in conjunction with various hardware architectures herein described.FIG.14is a non-limiting example of a software architecture and it will be appreciated that many other architectures may be implemented to facilitate the functionality described herein. The software architecture1406may execute on hardware such as machine1500ofFIG.15that includes, among other things, processors1504, memory1514, and input/output (I/O) components1518. A representative hardware layer1452is illustrated and can represent, for example, the machine1500ofFIG.15. The representative hardware layer1452includes a processing unit1454having associated executable instructions1404. Executable instructions1404represent the executable instructions of the software architecture1406, including implementation of the methods, components, and so forth described herein. The hardware layer1452also includes memory and/or storage devices memory/storage1456, which also have executable instructions1404. The hardware layer1452may also comprise other hardware1458. The software architecture1406may be deployed in any one or more of the components shown inFIG.1or2. The software architecture1406can be utilized to aggregate health-related information for many patients and determine whether outreach parameters are satisfied by conditions identified in the health-related information. The software architecture1406allows internal or external users to generate and trigger outreach events to contact a patient for which the conditions satisfy the outreach parameters and to track such outreach events.

In the example architecture ofFIG.14, the software architecture1406may be conceptualized as a stack of layers where each layer provides particular functionality. For example, the software architecture1406may include layers such as an operating system1402, libraries1420, frameworks/middleware1418, applications1416, and a presentation layer1414. Operationally, the applications1416and/or other components within the layers may invoke API calls1408through the software stack and receive messages1412in response to the API calls1408. The layers illustrated are representative in nature and not all software architectures have all layers. For example, some mobile or special purpose operating systems may not provide a frameworks/middleware1418, while others may provide such a layer. Other software architectures may include additional or different layers.

The operating system1402may manage hardware resources and provide common services. The operating system1402may include, for example, a kernel1422, services1424, and drivers1426. The kernel1422may act as an abstraction layer between the hardware and the other software layers. For example, the kernel1422may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and so on. The services1424may provide other common services for the other software layers. The drivers1426are responsible for controlling or interfacing with the underlying hardware. For instance, the drivers1426include display drivers, camera drivers, Bluetooth® drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, audio drivers, power management drivers, and so forth depending on the hardware configuration.

The libraries1420provide a common infrastructure that is used by the applications1416and/or other components and/or layers. The libraries1420provide functionality that allows other software components to perform tasks in an easier fashion than to interface directly with the underlying operating system1402functionality (e.g., kernel1422, services1424and/or drivers1426). The libraries1420may include system libraries1444(e.g., C standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematical functions, and the like. In addition, the libraries1420may include API libraries1446such as media libraries (e.g., libraries to support presentation and manipulation of various media format such as MPREG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g., an OpenGL framework that may be used to render two-dimensional and three-dimensional in a graphic content on a display), database libraries (e.g., SQLite that may provide various relational database functions), web libraries (e.g., WebKit that may provide web browsing functionality), and the like. The libraries1420may also include a wide variety of other libraries1448to provide many other APIs to the applications1416and other software components/devices.

The frameworks/middleware1418(also sometimes referred to as middleware) provide a higher-level common infrastructure that may be used by the applications1416and/or other software components/devices. For example, the frameworks/middleware1418may provide various graphic user interface functions, high-level resource management, high-level location services, and so forth. The frameworks/middleware1418may provide a broad spectrum of other APIs that may be utilized by the applications1416and/or other software components/devices, some of which may be specific to a particular operating system1402or platform.

The applications1416include built-in applications1438and/or third-party applications1440. Examples of representative built-in applications1438may include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and/or a game application. Third-party applications1440may include an application developed using the ANDROID™ or IOS™ software development kit (SDK) by an entity other than the vendor of the particular platform, and may be mobile software running on a mobile operating system such as IOS™, ANDROID™, WINDOWS® Phone, or other mobile operating systems. The third-party applications1440may invoke the API calls1408provided by the mobile operating system (such as operating system1402) to facilitate functionality described herein.

The applications1416may use built-in operating system functions (e.g., kernel1422, services1424, and/or drivers1426), libraries1420, and frameworks/middleware1418to create UIs to interact with users of the system. Alternatively, or additionally, in some systems, interactions with a user may occur through a presentation layer, such as presentation layer1414. In these systems, the application/component “logic” can be separated from the aspects of the application/component that interact with a user.

FIG.15is a block diagram illustrating components of a machine1500, according to some example embodiments, able to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically,FIG.15shows a diagrammatic representation of the machine1500in the example form of a computer system, within which instructions1510(e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine1500to perform any one or more of the methodologies discussed herein may be executed. For example, the instructions1510may be executed by the secure healthcare communication exchange platform150to manage and conduct outreach events.

As such, the instructions1510may be used to implement devices or components described herein. The instructions1510transform the general, non-programmed machine1500into a particular machine1500programmed to carry out the described and illustrated functions in the manner described. In alternative embodiments, the machine1500operates as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine1500may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine1500may comprise, but not be limited to, electronic delivery detection140, perishable item delivery server105, smart home service provider server107, device132a, device133a, device134a, device132b, device133b, device134b, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a STB, a PDA, an entertainment media system, a cellular telephone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the instructions1510, sequentially or otherwise, that specify actions to be taken by machine1500. Further, while only a single machine1500is illustrated, the term “machine” shall also be taken to include a collection of machines that individually or jointly execute the instructions1510to perform any one or more of the methodologies discussed herein. When the instructions1510are loaded, the machine1500is a dedicated machine for performing the processes described herein.

The machine1500may include processors1504, memory/storage1506, and I/O components1518, which may be configured to communicate with each other such as via a bus1502. In an example embodiment, the processors1504(e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor1508and a processor1512that may execute the instructions1510. The term “processor” is intended to include multi-core processors1504that may comprise two or more independent processors (sometimes referred to as “cores”) that may execute instructions contemporaneously. AlthoughFIG.15shows multiple processors1504, the machine1500may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

The memory/storage1506may include a memory1514, such as a main memory, or other memory storage, database110, and a storage unit1516, both accessible to the processors1504such as via the bus1502. The storage unit1516and memory1514store the instructions1510embodying any one or more of the methodologies or functions described herein. The instructions1510may also reside, completely or partially, within the memory1514, within the storage unit1516, within at least one of the processors1504(e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine1500. Accordingly, the memory1514, the storage unit1516, and the memory of processors1504are examples of machine-readable media.

Communication may be implemented using a wide variety of technologies. The I/O components1518may include communication components1540operable to couple the machine1500to a network1537or devices1529via coupling1524and coupling1522, respectively. For example, the communication components1540may include a network interface component or other suitable device to interface with the network1537. In further examples, communication components1540may include wired communication components, wireless communication components, cellular communication components, Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components to provide communication via other modalities. The devices1529may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a USB).

“CARRIER SIGNAL” in this context refers to any intangible medium that is capable of storing, encoding, or carrying transitory or non-transitory instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such instructions. Instructions may be transmitted or received over the network using a transitory or non-transitory transmission medium via a network interface device and using any one of a number of well-known transfer protocols.

“CLIENT DEVICE” in this context refers to any machine that interfaces to a communications network to obtain resources from one or more server systems or other client devices. A client device may be, but is not limited to, a mobile phone, desktop computer, laptop, PDA, smart phone, tablet, ultra book, netbook, laptop, multi-processor system, microprocessor-based or programmable consumer electronics, game console, set-top box, or any other communication device that a user may use to access a network.

“COMPONENT” in this context refers to a device, physical entity, or logic having boundaries defined by function or subroutine calls, branch points, APIs, or other technologies that provide for the partitioning or modularization of particular processing or control functions. Components may be combined via their interfaces with other components to carry out a machine process. A component may be a packaged functional hardware unit designed for use with other components and a part of a program that usually performs a particular function of related functions. Components may constitute either software components (e.g., code embodied on a machine-readable medium) or hardware components. A “hardware component” is a tangible unit capable of performing certain operations and may be configured or arranged in a certain physical manner. In various example embodiments, one or more computer systems (e.g., a standalone computer system, a client computer system, or a server computer system) or one or more hardware components of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware component that operates to perform certain operations as described herein.

A hardware component may also be implemented mechanically, electronically, or any suitable combination thereof. For example, a hardware component may include dedicated circuitry or logic that is permanently configured to perform certain operations. A hardware component may be a special-purpose processor, such as a Field-Programmable Gate Array (FPGA) or an ASIC. A hardware component may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations. For example, a hardware component may include software executed by a general-purpose processor or other programmable processor. Once configured by such software, hardware components become specific machines (or specific components of a machine) uniquely tailored to perform the configured functions and are no longer general-purpose processors. It will be appreciated that the decision to implement a hardware component mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations. Accordingly, the phrase “hardware component” (or “hardware-implemented component”) should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering embodiments in which hardware components are temporarily configured (e.g., programmed), each of the hardware components need not be configured or instantiated at any one instance in time. For example, where a hardware component comprises a general-purpose processor configured by software to become a special-purpose processor, the general-purpose processor may be configured as respectively different special-purpose processors (e.g., comprising different hardware components) at different times. Software accordingly configures a particular processor or processors, for example, to constitute a particular hardware component at one instance of time and to constitute a different hardware component at a different instance of time.

“PROCESSOR” in this context refers to any circuit or virtual circuit (a physical circuit emulated by logic executing on an actual processor) that manipulates data values according to control signals (e.g., “commands,” “op codes,” “machine code,” etc.) and which produces corresponding output signals that are applied to operate a machine. A processor may, for example, be a CPU, a RISC processor, a CISC processor, a GPU, a DSP, an ASIC, a RFIC, or any combination thereof. A processor may further be a multi-core processor having two or more independent processors (sometimes referred to as “cores”) that may execute instructions contemporaneously.