U.S. patent application number 15/844808 was filed with the patent office on 2018-04-19 for market measures and outcomes for app prescribing.
This patent application is currently assigned to Quintiles IMS Incorporated. The applicant listed for this patent is Quintiles IMS Incorporated. Invention is credited to Glenn Connery, John MacCarthy, Seth Reid, Brad Ryan.
Application Number | 20180108438 15/844808 |
Document ID | / |
Family ID | 52133406 |
Filed Date | 2018-04-19 |
United States Patent
Application |
20180108438 |
Kind Code |
A1 |
Ryan; Brad ; et al. |
April 19, 2018 |
Market Measures and Outcomes for App Prescribing
Abstract
The disclosure generally describes computer-implemented methods,
software, and systems for receiving and aggregating anonymized data
reports about when prescribers provide wireless device applications
to patients. The disclosure discusses ways of analyzing the data
reports in combination with other electronic medical information to
generate useful conclusions about scenarios in the health care
process.
Inventors: |
Ryan; Brad; (Chicago,
IL) ; MacCarthy; John; (Bourne End, GB) ;
Connery; Glenn; (Warminster, PA) ; Reid; Seth;
(London, GB) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Quintiles IMS Incorporated |
Danbury |
CT |
US |
|
|
Assignee: |
Quintiles IMS Incorporated
Danbury
CT
|
Family ID: |
52133406 |
Appl. No.: |
15/844808 |
Filed: |
December 18, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13933405 |
Jul 2, 2013 |
9910963 |
|
|
15844808 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 50/22 20130101;
G16H 40/20 20180101; G06Q 10/10 20130101; G16H 20/70 20180101; G16H
15/00 20180101; G16H 10/60 20180101; G16H 40/67 20180101; H04W 4/60
20180201; G16H 50/50 20180101; G06F 19/00 20130101 |
International
Class: |
G06Q 50/22 20120101
G06Q050/22; G06Q 10/10 20120101 G06Q010/10 |
Claims
1. A method comprising: identifying, by an analytics server, a
first wireless device application that has been prescribed to aid
in the treatment of a medical condition and configured to track
physiological parameters of a first group of recipient patients;
identifying, by the analytics server, a second wireless device
application that has been prescribed to aid in the treatment of the
medical condition and configured to track physiological parameters
of a second group of recipient patients; decoding, by the analytics
server, a set of data reports from the first and second wireless
device applications, each data report encoding (i) an anonymized
patient identifier that identifies a patient in the first or second
group of recipient patients, and (ii) a wireless device application
identifier that identifies either the first or the second wireless
device application; processing, by the analytics server, the
decoded data reports to generate a first and a second data sets
based, at least in part, on patient population information
retrieved solely using the anonymized patient identifiers from the
decoded data reports such that the first data set is associated
with the first wireless device application and the second data set
is associated with the second wireless device application, wherein:
the patient population information comprises electronic medical
information associated with the first and second group of recipient
patients; comparing, by the analytics server, the first wireless
device application with the second wireless device application in
terms of an improved adherence to the regular treatment by the
respective group of recipient patients who received the
corresponding wireless device application and the regular
treatment; and presenting results of comparison between the first
and second wireless device applications to a user investigating
effects of the first and second wireless device applications.
2. The method of claim 1, further comprising: in response to
determining that the improved adherence to the regular treatment
from the first group of recipient patients is higher than the
improved adherence to the regular treatment from the second group
of recipient patients, flagging the first wireless device
application as improving the adherence more than the second
wireless device application; and in response to determining that
the improved adherence to the regular treatment from the second
group of recipient patients is higher than the improved adherence
to the regular treatment from the first group of recipient
patients, flagging the second wireless device application as more
superior than the first wireless device application.
3. The method of claim 1, further comprising: identifying, by the
analytics server, a third wireless device application that has been
prescribed to aid in the treatment of the medical condition and
configured to track physiological parameters of a third group of
recipient patients; decoding, by the analytics server, another set
of data reports from the third wireless device application, each
data report encoding (i) an anonymized patient identifier that
identifies a patient in the third group of recipient patients, and
(ii) a wireless device application identifier that identifies the
third wireless device application; and processing, by the analytics
server, the decoded data reports to further generates a third data
set based, at least in part, on patient population information
retrieved solely using the anonymized patient identifiers from the
decoded data reports such that the third data set is associated
with the third wireless device application, wherein: the patient
population information further comprises electronic medical
information associated with the third group of recipient patients;
ranking, by the analytics server, the first wireless device
application, the second wireless device application and the third
wireless device application in terms of the the improved adherence
to the regular treatment by the respective group of recipient
patients who received the corresponding wireless device application
and the regular treatment.
4. The method of claim 1, wherein processing the decoded data
reports to generate the first and second data sets comprises:
processing the decoded data reports to generate the first and
second data sets based, at least in part, on patient population
information comprising electronic medical information from patients
with comparable demographic variables.
5. The method of claim 1, wherein comparing the first wireless
device application with the second wireless device application in
terms of the improved adherence to the regular treatment by the
respective group of recipient patients further comprises: comparing
the improved adherence to the regular treatment by the respective
group of recipient patients during more than one contemporaneous
periods after the respective group has received the corresponding
wireless device application and the regular treatment.
6. The method of claim 5, wherein presenting results of comparison
between the first and second wireless device applications to a user
further comprises: displaying the results of comparison between the
first and second wireless device applications during each of the
more than one contemporaneous periods after the respective group
has received the corresponding wireless device application and the
regular treatment.
7. A method comprising: identifying, by an analytics server, a
first wireless device application that has been prescribed to aid
in the treatment of a medical condition and configured to track
physiological parameters of a first group of recipient patients;
identifying, by the analytics server, a second wireless device
application that has been prescribed to aid in the treatment of the
medical condition and configured to track physiological parameters
of a second group of recipient patients; decoding, by the analytics
server, a set of data reports from the first and second wireless
device applications, each data report encoding (i) an anonymized
patient identifier that identifies a patient in the first or second
group of recipient patients, and (ii) a wireless device application
identifier that identifies either the first or the second wireless
device application; processing, by the analytics server, the
decoded data reports to generate a first and a second data sets
based, at least in part, on patient population information
retrieved solely using the anonymized patient identifiers from the
decoded data reports such that the first data set is associated
with the first wireless device application and the second data set
is associated with the second wireless device application, wherein:
the patient population information comprises electronic medical
information associated with the first and second group of recipient
patients; comparing, by the analytics server, the first wireless
device application with the second wireless device application in
terms of a number of emergency room (ER) visits by the respective
group of recipient patients who received the corresponding wireless
device application and the regular treatment; and presenting
results of comparison between the first and second wireless device
applications to a user investigating effects of the first and
second wireless device applications.
8. The method of claim 7, further comprising: in response to
determining that the number of ER visits by the first group of
recipient patients is lower than the number of ER visits by the
second group of recipient patients, flagging the first wireless
device application as more superior than the second wireless device
application; and in response to determining that the number of ER
visits by the second group of recipient patients is lower than the
number of ER visits by the first group of recipient patients,
flagging the second wireless device application as more superior
than the first wireless device application.
9. The method of claim 7, further comprising: identifying, by the
analytics server, a third wireless device application that has been
prescribed to aid in the treatment of the medical condition and
configured to track physiological parameters of a third group of
recipient patients; decoding, by an analytics server, another set
of data reports from the third wireless device application, each
data report encoding (i) an anonymized patient identifier that
identifies a patient in the third group of recipient patients, and
(ii) a wireless device application identifier that identifies the
third wireless device application; and processing, by the analytics
server, the decoded data reports to further generates a third data
set based, at least in part, on patient population information
retrieved solely using the anonymized patient identifiers from the
decoded data reports such that the third data set is associated
with the third wireless device application, wherein: the patient
population information further comprises electronic medical
information associated with the third group of recipient patients;
ranking, by the analytics server, the first wireless device
application, the second wireless device application and the third
wireless device application in terms of a number of ER visits by
the respective group of recipient patients who received the
corresponding wireless device application and the regular
treatment.
10. The method of claim 7, wherein processing the decoded data
reports to generate the first and second data sets comprises:
processing the decoded data reports to generate the first and
second data sets based, at least in part, on patient population
information comprising electronic medical information from patients
with comparable demographic variables.
11. The method of claim 10, wherein presenting results of
comparison between the first and second wireless device
applications to a user further comprises: dynamically displaying
the results of comparison between the first and second wireless
device applications as the demographic variables are adjusted.
12. The method of claim 7, wherein comparing the first wireless
device application with the second wireless device application in
terms of the number of emergency room (ER) visits by the respective
group of recipient patients further comprises: comparing the number
of emergency room (ER) visits by the respective group of recipient
patients during more than one contemporaneous periods after the
respective group has received the corresponding wireless device
application and the regular treatment.
13. The method of claim 12, wherein presenting results of
comparison between the first and second wireless device
applications to a user further comprises: displaying the results of
comparison between the first and second wireless device
applications during each of the more than one contemporaneous
periods after the respective group has received the corresponding
wireless device application and the regular treatment.
14. A method comprising: identifying, by an analytics server, a
first wireless device application that has been prescribed to aid
in the treatment of a medical condition and configured to track
physiological parameters of a first group of recipient patients;
identifying, by the analytics server, a second wireless device
application that has been prescribed to aid in the treatment of the
medical condition and configured to track physiological parameters
of a second group of recipient patients; decoding, by the analytics
server, a set of data reports from the first and second wireless
device applications, each data report encoding (i) an anonymized
patient identifier that identifies a patient in the first or second
group of recipient patients, and (ii) a wireless device application
identifier that identifies either the first or the second wireless
device application; processing, by the analytics server, the
decoded data reports to generate a first and a second data sets
based, at least in part, on patient population information
retrieved solely using the anonymized patient identifiers from the
decoded data reports such that the first data set is associated
with the first wireless device application and the second data set
is associated with the second wireless device application, wherein:
the patient population information comprises electronic medical
information associated with the first and second group of recipient
patients; comparing, by the analytics server, the first wireless
device application with the second wireless device application in
terms of a treatment cost incurred by the respective group of
recipient patients who received the corresponding wireless device
application and the regular treatment; and presenting results of
comparison between the first and second wireless device
applications to a user investigating effects of the first and
second wireless device applications.
15. The method of claim 14, further comprising: in response to
determining that the treatment cost incurred by the first group of
recipient patients is lower than the treatment cost incurred by the
second group of recipient patients, flagging the first wireless
device application as more superior than the second wireless device
application; and in response to determining that the treatment cost
incurred by the second group of recipient patients is lower than
the treatment cost incurred by the first group of recipient
patients, flagging the second wireless device application as more
superior than the first wireless device application.
16. The method of claim 14, further comprising: identifying, by the
analytics server, a third wireless device application that has been
prescribed to aid in the treatment of the medical condition and
configured to track physiological parameters of a third group of
recipient patients; decoding, by an analytics server, a set of data
reports from the third wireless device application, each data
report encoding (i) an anonymized patient identifier that
identifies a patient in the third group of recipient patients, and
(ii) a wireless device application identifier that identifies the
third wireless device application; and processing, by the analytics
server, the decoded data reports to further generates a third data
set based, at least in part, on patient population information
retrieved solely using the anonymized patient identifiers from the
decoded data reports such that the third data set is associated
with the third wireless device application, wherein: the patient
population information further comprises electronic medical
information associated with the third group of recipient patients;
ranking, by the analytics server, the first wireless device
application, the second wireless device application and the third
wireless device application in terms of the treatment cost incurred
by the respective group of recipient patients who received the
corresponding wireless device application and the regular
treatment.
17. The method of claim 14, wherein processing the decoded data
reports to generate the first and second data sets comprises:
processing the decoded data reports to generate the first and
second data sets based, at least in part, on patient population
information comprising electronic medical information from patients
with comparable demographic variables.
18. The method of claim 17, wherein presenting results of
comparison between the first and second wireless device
applications to a user further comprises: dynamically displaying
the results of comparison between the first and second wireless
device applications as the demographic variables are adjusted.
19. The method of claim 14, wherein comparing the first wireless
device application with the second wireless device application in
terms of the treatment cost incurred by the respective group of
recipient patients further comprises: comparing the treatment cost
incurred by the respective group of recipient patients during more
than one contemporaneous periods after the respective group has
received the corresponding wireless device application and the
regular treatment.
20. The method of claim 19, wherein presenting results of
comparison between the first and second wireless device
applications to a user further comprises: displaying the results of
comparison between the first and second wireless device
applications during each of the more than one contemporaneous
periods after the respective group has received the corresponding
wireless device application and the regular treatment.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation application of and claims
priority to U.S. application Ser. No. 13/933,405, filed on Jul. 2,
2013.
BACKGROUND
[0002] As part of the health care process, physicians or other
medical care providers may suggest, request, or "prescribe"
patients use a health, wellness, or disease management application
as part of the patient's medical treatment. For example, such an
application may be a mobile or web application.
OVERVIEW
[0003] The present disclosure relates to computer-implemented
methods, software, and systems for gathering information about when
patients are prescribed applications, such as wireless device
applications, to help treat medical conditions. By gathering and
analyzing application prescription data, implementations can
measure, track, and link the application prescription data to
outcomes, such as treatment outcomes or economic outcomes. The
present disclosure explains how the wireless device application
prescription information can be gathered and then subsequently used
in a manner that provides helpful conclusions to participants in
the health care process.
[0004] One computer-implemented method includes receiving via a
communications network, by an analytic server, one or more data
reports from one or more wireless device application providers that
provide wireless device applications to patients, each data report
comprising an anonymized patient identifier that identifies the
patient associated with the data report, and a wireless device
application identifier that identifies the wireless device
application associated with the data report, wherein the wireless
device application is provided to aid in the treatment of one or
more medical conditions of the patient; retrieving via the
communications network, by the analytic server, patient population
information, comprising electronic medical information associated
with a patient population to whom wireless device applications were
provided, using the anonymized patient identifiers associated with
each data report; organizing data reports into different data sets
for analysis based on their wireless device application identifier,
wherein data reports in a data set are associated with the same
wireless device application identifier; analyzing the data sets and
the patient population information to generate a conclusion about
the impact of a wireless device application on a particular
scenario; and reporting the conclusion.
[0005] Other implementations include corresponding computer
systems, apparatus, and computer programs recorded on one or more
computer storage devices, each configured to perform the actions of
the method. A system of one or more computers can be configured to
perform particular operations or actions by virtue of having
software, firmware, hardware, or a combination of software,
firmware, or hardware installed on the system that in operation
cause or causes the system to perform the actions. One or more
computer programs can be configured to perform particular
operations or actions by virtue of including instructions that,
when executed by a data processing apparatus, cause the apparatus
to perform the actions.
[0006] The foregoing and other implementations can each optionally
include one or more of the following features. In some
implementations, generating the conclusion includes generating
quantitative information about the impact of a wireless device
application on a particular scenario. In some implementations, the
analyzing may comprise comparing a characteristic of a data set in
which the wireless device application was provided to a
characteristic of a control set that includes members of the
patient population that were not using the wireless device
application. In some implementations, receiving the one or more
data reports may further comprise receiving for each data report a
corresponding provider identifier that identifies the wireless
device application provider associated with the data report, the
retrieving further retrieves provider information associated with
each data report using the corresponding provider identifier
associated with the data report, and the analyzing further uses the
provider information to generate a conclusion about the effects of
providing a given wireless device application. In some
implementations, retrieving the patient information may include
retrieving information about treatment outcomes for the medical
conditions of the patient, and the analyzing may generate a
conclusion about the effects of the wireless device application on
the treatment outcomes of the one or more medical conditions. In
some implementations, retrieving the patient information may
include retrieving information about treatment outcomes for the
medical conditions of the patient and a drug, medical device, or
other therapy prescribed to the patient, and the analyzing may
generate a conclusion about the effects of coadminstruction of the
wireless device application the drug, medical device, or other
therapy on the treatment outcomes of the one or more medical
conditions. In some implementations, retrieving the patient
information may include retrieving information about treatment
costs for the medical conditions of the patient, and the analyzing
may generate a conclusion about the effects of the wireless device
application on the treatment costs of the one or more diseases. In
some implementations, retrieving the patient population information
may include: tracking usage information of a reconciled regiment of
wireless applications by the patient population; and retrieving the
tracked usage information. Tracking the usage information of a
reconciled regiment of wireless device applications may include
tracking the usage information of wireless device applications from
more than one wireless device application providers. In some
implementations, retrieving the patient population information may
include retrieving reimbursement information for a particular
wireless application prescribed to the patient, the reimbursement
information including a payor identifier that identifies a party
reimbursing the patient, as well as an extent of the reimbursement.
In some implementations, organizing the data reports may further
comprise filtering patients from the patent population in one or
more data sets based on one or more sets of demographic attributes,
and wherein the analyzing the data sets may comprise comparing a
data set including patients with a first set of demographic
attributes to a data set including patients with a second set of
demographic attributes to generate a conclusion about the different
effects of providing a given wireless device application to
patients with the first set of demographic attributes and the
patients with the second set of demographic attributes. Some
implementations may further comprise presenting the conclusion to a
physician for use in making a treatment or clinical decision for an
individual patient seeking such treatment or clinical decision from
the physician. Some implementations may further comprise presenting
the conclusion to a payor, insurance provider or a pharmaceutical
sales representative for use in making an economic, marketing, or
financial decision.
[0007] The details of one or more implementations of the subject
matter of this specification are set forth in the accompanying
drawings and the description below. Other features, aspects, and
advantages of the subject matter will become apparent from the
description, the drawings, and the claims.
DESCRIPTION OF DRAWINGS
[0008] FIG. 1 is a screen shot of a user interface that allows
patient selection for wireless device application distribution.
[0009] FIG. 2 is a screen shot of a user interface that allows
prescriber selection for wireless device application
distribution.
[0010] FIG. 3 is a screen shot of a user interface that allows a
prescriber to select wireless device applications for
distribution.
[0011] FIG. 4 is a screen shot of a user interface that allows a
patient to be alerted that he or she has been prescribed a wireless
device application.
[0012] FIG. 5 is a screen shot of a user interface that shows a
claim summary for wireless device application distribution.
[0013] FIG. 6 is a screen shot of a user interface that shows a
record of medical treatments provided to a specific patient.
[0014] FIG. 7 is a screen shot of a user interface that draws
conclusions based on wireless device application distribution for a
prescriber.
[0015] FIG. 8 is a screen shot of a user interface that draws
quantitative conclusions based on wireless device application
distribution for a prescriber.
[0016] FIG. 9 is a screen shot of a user interface in which a
pharmaceutical provider can determine what sort of analysis to
perform based on wireless device application distribution data.
[0017] FIG. 10 is a screen shot of a user interface that draws
conclusions based on wireless device application distribution for a
pharmaceutical provider.
[0018] FIG. 11 is a screen shot of a user interface in which an
insurance provider can determine what sort of analysis to perform
based on wireless device application distribution data.
[0019] FIG. 12 is a screen shot of a user interface that draws
conclusions based on wireless device application distribution for
an insurance provider.
[0020] FIG. 13 is a block diagram illustrating an example system
for gathering and analyzing information about distribution of
wireless device applications.
[0021] FIG. 14 is a flowchart of a process for gathering and
analyzing information about distribution of wireless device
applications.
DETAILED DESCRIPTION
[0022] This disclosure generally describes a mechanism for
capturing information on the prescribing of mobile health and web
applications that physicians use in patient care. Such applications
may provide a patient with the ability to track medical data, may
make treatment recommendations, and so on to aid in the medical
care process. Thus, such applications are therapeutic interventions
and have a meaningful role in the health care process.
Implementations described in this application provide a variety of
ways that gathering data about how such applications are
administered and prescribed can lead to useful conclusions, such as
to aid in medical treatment of a patient or in making economic
decisions related to the medical care progress. Gathering and using
application prescription data is a new approach that offers the
possibility of deriving many useful conclusions that were not
previously available.
[0023] Many of the applications that are available for wireless
phones and similar mobile computing devices are medical or
health-related applications. Such applications may have many types
of functionality that address medical or health-related problems.
Using medical and health-related applications can have a wide
variety of benefits for users. Users may include people or entities
involved in the healthcare deployment process, and different
applications might be intended for different groups of users. A
medical doctor might use an application to manage medication that
stores a database of drug interactions, while a patient might use
an application that records and organizes information about that
patient's blood sugar levels. Pharmaceutical manufacturers may
distribute applications related to the medications the
pharmaceutical manufacturers sell. A pharmaceutical company that
sells hypertension drugs might provide an application that tracks
blood pressure measurements.
[0024] When an application is prescribed to a patient at a cost
being paid by a party other than the patient, a "claim" is
generated and associated information is transmitted to the
provider, the patient, and other relevant entities (e.g., payer,
employer). The creation of a claim causes a data report with
information about the prescription having taken place to be
subsequently sent to an analytic infrastructure for further
processing. For example, data reports corresponding to claims may
be aggregated and used for market measures, outcomes research, app
effectiveness ratings, and potentially reimbursement.
[0025] Applications, in general, include sets of instructions that
are executed by a computing device that provide functionality.
However, applications may take various forms. Some applications may
be exclusively local applications that are run by a computing
device and request resources from a desktop operating system.
However, other applications may be executed by a mobile operating
system. Yet other applications may be provided through web
browsers, such as by scripting, plug-ins, or other browser
extensions and add-ons that allow browsers to provide hosting
capability for applications. Sometimes applications are
distributed, so that their functionality is provided by multiple
machines, for example in a client-server or peer-to-peer
distributed architecture. Distributed functionality may be
especially important in implementations in which clients are mobile
devices that individual users employ to interact with an analytic
platform that runs on one or more servers.
[0026] Application is a general term that refers to instructions on
any computing platform to accomplish a given task. However, this
specification uses the terminology "wireless device application"
and "app" to refer specifically to applications that run on a
mobile operating system. Often such "apps" are obtained from a
centralized store. However, while this specification refers to
"wireless device applications" and "apps" as being used in certain
implementations, the techniques presented in this specification are
generally relevant to other types of applications, as well. While
many example implementations presented in the specification are
directed to applications that are in fact wireless device
applications, or apps, implementations can also operate in
scenarios in which the applications are meant to run on a desktop
or laptop PC, or are provided by web browsers.
[0027] While the approach taken to gathering such information might
differ slightly, the data will essentially be useful in similar
ways. For example, if a patient is prescribed access to an asthma
tracking application, the significant information is that the
patient now has access to that program, regardless of how the
application is accessed. On the other hand, it may be especially
valuable to track information about the distribution of
applications that are actually wireless device applications because
wireless device applications, such as those running on a smartphone
or tablet, are portable and convenient to use to assist in a wide
range of settings. Thus, hereinafter the specification will refer
to "wireless device applications" or "apps" to denote the programs
prescribed to patients to treat health conditions, but these terms
do not generally exclude gathering and analyzing data about health
care applications and health care-related applications that are run
on other computing platforms.
[0028] Examples of prescribed apps discussed in this specification
may include apps that are prescribed by a physician or other
treatment provider to take care of an illness of a patient.
However, sometimes health care apps may be prescribed by parties
who do not directly provide treatment, as discussed above.
Additionally, while the examples presented in this application are
chiefly directed to situations where patients are prescribed
applications, implementations may track the provision of other
medical applications and draw conclusions. For example, an insurer
might provide an app that provides drug interaction information to
a physician. The insurance company could then track data about
physicians who use the drug interaction application as compared to
physicians that do not use the dug interaction application, and
draw economic conclusions about whether the application leads to a
cost savings, and if so, how much of a savings.
[0029] When physicians suggest, request, or "prescribe" that
patients use a health, wellness, or disease management app, this
prescription information may be recorded in an EMR or physician
note. It is possible to capture these events and bring data
together with other information about the app or patient. By doing
so, the data may be measured, tracked, and linked to outcomes. The
ability to measure the prescribing and reimbursement of health apps
and the apps' impact on patient health is important because apps
are expected to become a key element of patient treatment in the
same way that drugs, devices and diagnostics are today.
[0030] Healthcare participants including health insurers and
provider organizations may benefit from being able to measure
wireless device application prescribing for their members and/or
patients segmented by factors including patient's medical condition
and demographic factors. Such parties may also want to be able to
compare and/or benchmark use in their patient populations by
comparison to use in other health plans and institutions.
[0031] Pharmaceutical and diagnostic companies and mobile health
app publishers also may want to measure their mobile health
initiatives to understand their performance as compared to that of
competitors and measure the return on investment (ROI) of
investments.
[0032] All of these organizations would benefit from information to
assess the real world impact of mobile health initiatives in
improving health outcomes and cost effectiveness. A helpful
approach to providing such analytically useful evidence is the
ability to capture and integrate both wireless device application
prescribing information and longitudinal prescription and medical
record and claims data for significant numbers of patients.
Implementations may enable users to capture and analyze such
evidence and information. Such analysis supports developing health
economic evaluations to aid in decision-making by all healthcare
organizations on investments in mobile health.
[0033] Implementations have value in that the implementations
enable the integration of app prescribing data at the most granular
level, such as prescribed app, patient, prescriber and payor, with
information about drug prescriptions and other prescribed
therapies, claims and health record data for the same patients.
Having the analytic information means, for example, that
implementations may evaluate whether patients prescribed a
particular diabetes tracking app actually exhibit improved
adherence with their medications. Similarly, implementations may
evaluate whether a cohort of patients prescribed fitness or diet
apps actually have a reduced cost to the healthcare system when
compared to a matched control group. While this comparative data
analysis may not be able to establish causation, implementations
may perform statistical analysis on appropriate data to establish
correlations and patterns that are highly useful conclusions.
[0034] Implementations provide an IT-enabled process which captures
information on the prescription of mobile health applications by
physicians for their patients in a way that enables that
information to be integrated with longitudinal records about
prescription and other therapies, treatment and outcomes data for
analytics to determine app effectiveness and ROI.
[0035] At a high level, implementations may operate as follows.
When a patient registers as a user of a wireless device app
provider, a specific set of information is collected which
generates a unique anonymized identifier (or ID) which is identical
to the one generated when Rx or other treatment data is anonymized
for the same patient. Physician registration similarly generates an
identifier that enables linkage between their drug and app
prescribing activity. Apps in the application catalogue may be
coded using a proprietary coding model that enables their linkage
to disease codes. These disease codes may be helpful because
implementations may be able to establish which apps are relevant to
which other therapies. For example, an app that tracks dietary
cholesterol could be identified as being related to being
prescribed a statin, or results from a lipid panel diagnostic.
[0036] When an application prescription is generated, information
on the patient, prescribing physician, prescribed application and
claims reimbursement is captured using various processes, which may
differ based on how the application is provided and prescribed, as
well as how much the application costs and who pays for the
application.
[0037] As discussed above, generally the application environment
includes a wireless device or tablet that may be used by a consumer
or user. In addition there may be an application that also has a
desktop or laptop component. It may be noted that the "wireless"
aspect of a computing device in an implementation is not intended
as limiting, and computing devices that are not easily portable may
be used where appropriate and devices that are portable may
communicate with some of the other portions of an implementation by
using a wired connection. In general, the relevance of this aspect
of the design is that the portal is hosted at a device for a user,
and that the device communicates with centralized infrastructure
that stores and manages information for subsequent usage and
analysis.
[0038] The functionality across user devices may vary with their
dimensions. There may be a limited subset of data in a mobile
computing device while a more expansive subset is available across
a desktop environment. Such division of functionality may be due to
greater computing resources at a desktop machine than a mobile
computing device due to the space, physical interface, and power
limitations of the mobile computing device. In addition, the
application may utilize certain authentication, confidence and/or
security measures that are available through a wireless device. For
example, a wireless device may be designated as belonging to a
particular user. However, individual users may be associated with
specific accounts that are further associated with privacy
settings.
[0039] Because a developer may know that a wireless handset
consumer with an account with a particular national wireless
carrier may have a line of credit, that determination may be used
to provide an assurance level that is not necessarily be available
across other platforms, such as desktops. These confidence measures
may be used to offer an expansive array of products and services.
However, other security means such as a password, which may be a
one-time password, biometrics, a pattern and so forth may be
required in an implementation to establish the identity of a user
before the user is given access privileges such as the ability to
make a purchase of a medical application.
[0040] The authentication is relevant because it may be necessary
for a payment to take place before the patient is allowed access to
the app that the physician prescribed to the patient. These
security measures may also be especially important because medical
data can be quite sensitive and it may be important to protect the
privacy and confidentiality of participants in the healthcare
process. While it is necessary for private information to be
available where such private information is needed, it is of
paramount importance that only parties who are entitled to access
private information have access to it, so as to comply with legal
standards and so that parties who should not have access to private
information are unable to exploit the information to the detriment
of patients or other holders of private information.
[0041] Access to the apps and information related to the apps may
be secured depending on a patient's condition. As discussed briefly
above, the wireless devices and other participating devices may
provide other technologies that are designed to safeguard personal
identifiable information and shield the inadvertent release of
personally identifiable and sensitive information, particularly in
those circumstances where there is a stigmatic condition or issue
involved. The app may be addressed to a particular condition or
treatment regimen, such as a pharmaceutical compound or treatment
regimen. Alternatively, the app may include a diagnostic component
and/or interface with a Bluetooth diagnostic component that may
produce diagnostic measurement information, such as blood sugar and
other parameters. It may be noted that Bluetooth is only one type
of interface for diagnostic components and other approaches are
possible.
[0042] FIG. 1 is a screen shot of a user interface that allows
patient selection for wireless device application distribution. The
screen shot 100 shows a patient identification control 110 that
allows a prescriber or other application provider to enter an ID of
a patient who should receive the wireless device application. In
general, the wireless device application provider will be
characterized as a physician throughout the illustrative examples,
but as will be discussed later other parties can provide wireless
device applications and tracking data can provide in a similar
manner. For example, the ID may be an anonymized numerical or
alphanumerical ID of the patient. It is generally important that
the ID be anonymized, so as to protect private health information
related to the user. As an alternative, patient selection control
120 allows the prescriber to select one of several potential
patients to send the wireless device application to. The prescriber
can then click on the select button 130 in order to select the
patient identified by patient identification control 110 or patient
selection control 120. While screen shot 100 shows an
implementation in which one patient is selected at a time and
receives one wireless device application at a time, other
implementations may allow multiple patients to be selected
simultaneously or multiple wireless device applications to be
selected simultaneously.
[0043] Additionally, implementations may build in additional
security and authentication. In addition to the patient
identification process illustrated in FIG. 1, implementations may
require authentication information such as a password, biometric
identification or other security information in order to allow a
physician the authority to prescribe wireless device applications
to a user.
[0044] FIG. 2 is a screen shot of a user interface that allows
prescriber selection for wireless device application distribution.
FIG. 2 has similar parts to FIG. 1, but the parts allow a
prescriber to identify himself or herself to an implementation,
rather than a patient. Thus physician identification control 210
and physician selection control 220 are analogous to patient
identification control 110 and patient selection control 120,
except that physician identification control 210 and physician
selection control 220 allow an implementation to identify a
physician rather than a patient. Similarly, the user may use select
button 230 to accept the choice of physician. It may also be noted
that physician selection may require some sort of authentication as
noted in connection with FIG. 1. The authentication may be
especially important in the case of the physician, because not all
physicians may be authorized to prescribe all apps.
[0045] FIG. 3 is a screen shot of a user interface that allows a
prescriber to select wireless device applications for distribution.
Title 310 informs the prescriber to select a choice of which
application to provide. Caption 320 indicates that the page lists
patient conditions. The conditions shown are diabetes 330,
hypertension 340, and asthma 350. The wireless device application
provider suggests two wireless device applications for each
condition, including diabetes management apps 332A-332B,
hypertension management apps 342A-342B, and asthma management apps
352A-352B. Additionally, there is a button 360 to find other apps.
Button 360 allows a prescriber to send other applications, which
are not already shown, to a patient. If the prescriber invokes
button 360, the prescriber will be taken to an interface in which
the prescriber can identify other applications that might be
appropriate to prescribe to the patient, and then prescribe the
applications. For example, if a patient has high cholesterol, a
prescriber might want to prescribe a hypertension treatment
application even if there has not been a formal diagnosis.
Additionally, prescribe app button 370 allows a prescriber to
prescribe the selected application to the patient.
[0046] FIG. 4 is a screen shot of a user interface that allows a
patient to be alerted that he or she has been prescribed a wireless
device application. Screen shot 400 depicts a message that alerts a
user that he or she has been prescribed a wireless device
application. The alert message includes a caption 410 indicating
that the prescriber has prescribed an app. FIG. 4 is meant as a
quick summary of a prescription decision, and more information may
be provided as well. Link 420 indicates that the wireless device
application that was prescribed is hypertension management app #2.
By selecting link 420, the patient indicates that he or she would
like to accept and access the app. The patient may either be
provided the app for download by an application store, or the link
may allow access to an application via the web. An aspect of
purchasing an app is that there may be a charge involved. An app is
assumed to be free unless the alert message specifically notifies
the patient that there may be a charge involved.
[0047] FIG. 5 is a screen shot of a user interface that shows a
claim summary for wireless device application distribution. FIG. 5
will generally be presented to the patient after the patient has
accepted the prescribed wireless device application, such as in
FIG. 4. Caption 510 indicates that the patient is being provided a
claim summary. Claim information 520 is a listing of detailed
information about the prescription of the wireless device
application. As shown, claim information 520 includes information
such as the ID of the prescriber, the name of the prescribed
application, the name of the patient, a timestamp, a cost value,
and an anonymized ID of the insurer. Claim information 520 is only
an example, and claim information 520 may include additional
information about health transactions or omit certain information
included in FIG. 5 as being part of claim information 520.
[0048] FIG. 6 is a screen shot of a user interface that shows a
record of medical treatments provided to a specific patient. Screen
shot 600 includes a patient identifier 610. It also includes a list
of prescribed medications 620, a list of prescribed devices 630, a
list of prescribed diagnostics 640, and a list of prescribed
applications 650. In some implementations, screen shot 600 may only
include a list of prescribed applications 650. While patient
identifier 610 is anonymous, FIG. 6 is an example of a presentation
that show which types of treatments are co-administered. While
implementations can also analyze medical treatment prescription in
the aggregate, FIG. 6 organizes different therapies provided to a
single patient so the prescriber can observe examples of the
relationship between various therapies. For example, it might be
helpful to a physician to realize that patient prescribed a certain
diabetes application is also prescribed metformin rather than
insulin shots. However, because the data shown in FIG. 6 is not
aggregated, it is important to establish that the party viewing the
consolidated information is entitled to access all of the
information. For example, even if an endocrinologist treats a
patient for diabetes, it may not be appropriate for the
endocrinologist to know that the patient is also a user of an IUD.
However, if the medical data is appropriately aggregated and
anonymized, privacy is not jeopardized because conclusions do not
interfere with the privacy of individual patients.
[0049] FIG. 7 is a screen shot of a user interface that draws
conclusions based on wireless device application distribution for a
prescriber. Whereas FIG. 6 aggregates information on a patient by
patient basis, FIG. 7 aggregates information across information
gathered for a population of patients treated by a prescriber, as
previously defined. Screen shot 700 presents a prescriber
identifier 710 and a caption 720 that indicates that screen shot
700 presents aggregated patient care conclusions for the
prescriber. FIG. 7 shows three example qualitative conclusions
722A-722C that are drawn based on the prescriber identifier. For
example, conclusion 722A specifies that patients prescribed
hypertension app #2 showed improved blood pressure. Conclusion 722B
specifies that patients prescribed diabetes app #3 were also
frequently prescribed blood pressure medication #2. Conclusion 722C
specifies that patients prescribed asthma app #2 showed a greater
benefit from inhaler #2 than inhaler #1. Additionally, button 730
allows quantitative analysis. Quantitative analysis, as will be
discussed in FIG. 8 takes a qualitative conclusion about a scenario
and performs statistical and mathematical analysis on the data, so
that not only general conclusions are available, but a numerical
categorization can also become available.
[0050] However, even with qualitative conclusions, such as those
shown in FIG. 7, it is important to understand the basis of the
conclusions that implementations derive. For example, conclusion
722A specifies that patients prescribed hypertension app #2 showed
improved blood pressure. As will be discussed with respect to FIG.
8, such a conclusion can lead to quantitative measures. However, in
order for even qualitative conclusion to be meaningful, it is
necessary to specify conditions, such as which group or group of
patients are being considered, what time frame is being considered,
and so on. For example, conclusion 722A, that patients prescribed
hypertension app #2 showed improved blood pressure, would indicate
different things if a different group of patients are under
consideration, or a different timeframe is under consideration.
Thus, a large part of ensuring that conclusions are meaningful is
that implementations need to allow parties that review the results
can specify the conditions that lead to conclusions so that the
conclusions are meaningful and clear.
[0051] FIG. 8 is a screen shot of a user interface that draws
quantitative conclusions based on wireless device application
distribution for a prescriber. Screen shot 800 includes a caption
810 to indicate that quantitative analysis is being performed. The
qualitative conclusion 820 that is being quantified is presented in
screen shot 800. For example, in FIG. 8, qualitative conclusion 820
specifies that patients prescribed hypertension app #2 showed
improved blood pressure. The set of quantitative metrics 830
provides examples about how these qualitative conclusions can be
transformed into numerical metrics. For example, the mean blood
pressure of patients in a given population, which may be the group
of patients subsequently provided wireless device application for
hypertension, taken before their receipt of the wireless device
application, may be 150/115 mmHg, which indicates that the patients
are experiencing moderately severe hypertension. Subsequently, the
mean blood pressure for the patient group, one month after
receiving the application may decrease to 115/70 mmHg, which is
within the normal range. Quantitative metrics 830 further
establishes that this constitutes systolic improvement of -35 mmHg
and diastolic improvement of -30 mmHg. Thus, quantitative metrics
830 provide information about clinical results that correlate to
prescription of the application.
[0052] Additionally, change timeframe button 840 is an example of a
control that helps establish conditions, as discussed above with
respect to FIG. 7. By providing controls that change conditions
leading up to the derivation of conclusion, more advanced analysis,
which will be discussed subsequently, becomes possible. For
example, FIG. 8 indicates that there a was a drop in blood pressure
for patients prescribed a hypertension application, one month after
receiving the application. However, there may have been a factor
besides the hypertension application that accounts for this
treatment outcome, such as a co-administered medication. It is
possible to perform further analysis that imposes this condition on
the analysis to establish more advanced correlations and suggest
causations, as will now be discussed.
[0053] FIG. 8 illustrates that certain conclusions reported by
implementations can be quantified, and quantifying the conclusions
can make the conclusions even more meaningful. For example, with
respect to conclusion 722B, other quantitative measures related to
conclusion 722B may be generated. For example, conclusion 722B
specifies that patients prescribed diabetes app #3 were also
frequently prescribed blood sugar medication #2. Quantitative
measures related to conclusion 722B might specify a specific
percentage, for example, that 66% of patients prescribed diabetes
app #3 were also prescribed blood sugar medication #2. Thus, rather
than a qualitative measure, which includes stating that these
treatments "frequently" accompany one another, quantitative
analysis provides a numerical measure of the conclusion.
Additionally, implementations may make it possible to provide
further analysis based on the quantitative conclusions. For
example, it may be possible to compare treatment outcomes for the
66% of patients who were prescribed blood sugar medication #2 along
with diabetes app #3 to the 34% of patients who were not prescribed
blood sugar medication #2 along with diabetes #3. By performing
such analysis, it can become possible to provide conclusions that
further take advantage of the data to draw helpful conclusions. For
example, an implementation may analyze how fasting blood sugar
levels in two patient populations change. For example, suppose that
there is a group of patients with diabetes, some of whom are being
treated with blood sugar medication #2 and some of whom are not
being treated with blood sugar medication #2. As in the example of
FIG. 8, it is possible to differentiate between groups of patient
outcomes that are separated between before and after being
prescribed the app. Based on the previously discussed data, it
becomes possible to isolate impacts of individual variables on
outcome. For example, by isolating groups of patients where all
members of the group were prescribed the wireless device
application, but some of the patients were also on a medication and
some were not, it becomes possible to draw inferences about which
parts of the treatment outcomes are likely due to the use of the
medical application and which parts of the treatment outcomes are
likely due simply to the effects of the medication on
treatment.
[0054] FIG. 9 is a screen shot of a user interface in which a
pharmaceutical provider can determine what sort of analysis to
perform based on wireless device application distribution data.
Screen shot 900 includes a caption 910 that indicates that the
implementation is directed to use by a pharmaceutical provider.
Prompt 920 requests that the pharmaceutical provider choose an app
from a group of apps 930 and a drug from a group of drugs 940.
While the approach in FIG. 9 is shown as being directed towards
analyzing relationships between the prescription of apps 930 and
drugs 940, other implementations may perform a similar analysis
between prescribed apps 930 and other therapies, such as a medical
device or a diagnostic or treatment procedure. FIG. 9 shows an
interface where the pharmaceutical provider can select an app and a
drug to infer relationships between. In the interface depicted, the
pharmaceutical provider selects an app from the group of apps 930
and a drug from the group of drugs 940 and then selects the assess
button 950 to draw conclusions about the data available for the
selected app and how the selected app relates to the selected drug.
While FIG. 9 only shows the selection of one app and its
relationship to one drug, multiple approaches are possible, and
some implementations may provide the ability to compare multiple
apps with multiple drugs to draw even more complicated inferences
and conclusions.
[0055] FIG. 10 is a screen shot of a user interface that draws
conclusions based on wireless device application distribution for a
pharmaceutical provider. Screen shot 1000 includes a caption 1010
that indicates that the implementation is for the use of a
pharmaceutical provider. Caption 1020 identifies that the analysis
is the relationship between a first therapy 1022A, App #2, and a
second therapy 1022B, Drug #3. FIG. 10 then presents a series of
inferences as inferences 1030. As discussed before, inferences 1030
include several qualitative conclusions, including "patients
prescribed app #2 were like to have good outcomes on drug #3,"
"patients prescribed app #2 were more like to be prescribed drug #3
by a specialist than a G.P.," and "patients prescribed App #2 were
more likely to be prescribed a relatively small dose of drug #3."
As noted before, these conclusions may be drawn by performing
appropriate statistical analyses of patient populations and the
medical data associated with the patient populations. Additionally,
as shown in FIG. 8, some of these conclusions can be considered
based on their quantitative effects. For example, "patients
prescribed App #2 were more likely to be prescribed a relatively
small dose of drug #3" may also be expressed as the quantitative
conclusion that patients prescribed drug #3 without being
prescribed app #2 may have an average daily dose of drug #3 of 200
mg, while patients prescribed drug #3 along with app #2 might have
an average daily dose of 100 mg.
[0056] FIG. 11 is a screen shot of a user interface in which an
insurance provider can determine what sort of analysis to perform
based on wireless device application distribution data. Screen shot
1100 in FIG. 11 has a caption 1110 that shows that the
implementation is designed to help an insurance provider. Label
1120 indicates that the implementation is designed to assess the
impact of one of a set of apps 1130 on two populations, population
#1 1140 and population #2 1150. The populations are groups produced
by placing demographic filters on an overall population. For
example, the overall population might include patients insured by a
given insurance provider. For example, population #1 includes
female African-Americans, who are 40-49 years of age that reside in
the Southwest U.S. Population #2 includes male Hispanic
individuals, who are 21-39 years of age, who reside in the
Mid-Atlantic U.S. There is a change filters button 1160 that
enables the user who wishes to perform demographic analysis, such
as the insurance provider, to change the filters to determine which
members of the overall population to include in the subpopulation.
When the user invokes the assess button 1170, implementations are
able to draw conclusions about the effects of the apps based on
populations that are chosen based on demographic variables.
[0057] FIG. 12 is a screen shot of a user interface that draws
conclusions based on wireless device application distribution for
an insurance provider. Screen shot 1200 shows a caption 1210 that
identifies that the implementation is being used by an insurance
provider. Caption 1220 indicates that conclusions 1230 are
conclusions that compare the impact of App #3 on Population #1 vs.
Population #2, as indicated in FIG. 11. Conclusions 1230 are
conclusions that stem from comparing the health data associated
with demographic populations to one another. For example, three
conclusions provided in FIG. 12 are that both populations showed a
decrease in ER visits for the condition associated with the app
after begin prescribed app. This conclusion is an example of a
conclusion that might be drawn on a common effect of the app for
both populations. For example, a dietary app that helps users
manage cholesterol consumption in their diets might minimize ER
visits for both populations. As noted previously, it may be
appropriate to quantify the impact of the app. The dietary app just
discussed might result in a 15% decrease in ER visits for one
population, and a 40% decrease in ER visits for another population.
Indeed, the resulting conclusions from comparing populations may be
quite complicated and require sophisticated analysis of the
available data. For example, population #1 might show a 15%
decrease after one month, followed by a 25% decrease after two
months, while population #2 might have a 10% decrease after the
first month, followed by a 30% decrease after two months.
[0058] FIG. 12 also includes additional conclusions that might be
derived from comparing the populations from FIG. 11. For example,
FIG. 12 illustrates a comparative conclusion, which is that
population #1 was more likely to be prescribed only one medication
for the condition associated with the app than population #2. Of
course, there may be a wide range of causes and effects related to
this conclusion, but such a correlation may be useful to an
insurance provider that is trying to understand how best to pay for
prescription drug coverage for its clients. However, it may be
desirable to associate such conclusions with other information to
draw conclusions to make decisions. For example, it may be helpful
to know that while population #1 is more likely than population #2
to be treated with only one medication, it may also be helpful to
gather information which specific medications are prescribed, or
specific costs associated with the different medication regiments
from each population.
[0059] FIG. 12 also includes the conclusion that population #1
showed a 15% decrease in overall costs during 6 months after
receiving app #3, while population #2 showed an 11% decrease in
overall costs. This is a simple quantitative conclusion that is
very helpful to a party such as an insurance provider. It shows
that not only is distributing an application is likely to help
manage costs, but provides a quantitative measure of how much, and
which demographic might obtain the best results from being
prescribed a given application.
[0060] FIGS. 1-12 are screenshots of a sample user interface for an
example system for gathering and analyzing information about
distribution of wireless device applications. However, it should be
remembered that these are just samples of ways in which information
related to distributing the wireless device applications may be
utilized. As discussed throughout this specification,
implementations track and gather information about individual
transactions, in which wireless device application providers give
access to individual patients so that the patients are able to use
the applications to help manage health problems. The information
should be anonymized, so as to protect the privacy and
confidentiality of participants in the health care process.
[0061] However, as discussed with respect to the above examples, a
wealth of conclusions may be drawing by analyzing the new data of
tracking wireless device application transactions and combining the
transaction data with other information that is already included in
EMR systems. For example, as discussed above, there may be a large
amount of information stored electronically about patients,
physicians and health care providers, pharmaceutical companies,
insurance companies, treatment outcomes, medication records,
diagnostics, medical devices, etc. By performing analytics that
combine the new data related to wireless device applications with
other information to draw conclusions about different scenarios,
implementations offer many powerful features. Scenarios, as used
herein, may refer to any combination of clinical conditions. The
clinical conditions may include patient characteristics such as
age, gender, race, family history, occupational risk, prior
history, etc, The clinical conditions may also include treatment
parameters such as dosing, physical therapy, wellness training,
etc. After analyzing the data, implementations can reports that
allow users to review the conclusions to help understanding and
decision-making as part of the medical care process.
[0062] Additionally, in some implementations, the reports generated
may be either dynamic or static. The reporting may generate a
report that includes data presented in one or more static formats
(e.g., a chart, a graph, or a table) without providing any
mechanism for altering the format and/or manipulating the data
presented in the report. In such an implementation, the data
presentation is generated and saved without incorporating
functionality to update the data presentation. In some
implementations, the reporting provides a static report in a PDF,
spreadsheet, or XML format. Such a format generally provides an
understanding of the report as textual data or a visualization, but
other forms of presenting conclusions such as audio, video, or an
animation are not excluded as potential results.
[0063] Additionally or alternatively, the reporting may generate a
report that includes controls allowing a user to alter and/or
manipulate the report itself interactively. For example, the
reporting system may provide a dynamic report in the form of an
HTML document that itself includes controls for filtering,
manipulating, and/or ordering the data displayed in the report.
Moreover, a dynamic report may include the capability of switching
between numerous visual representations of the information included
in the dynamic report. Additionally, users may request a static or
dynamic report to organize the data to meet their data needs, as
discussed.
[0064] FIG. 13 is a block diagram illustrating an example system
for gathering and analyzing information about distribution of
wireless device applications. FIG. 13 shows a computing system 1300
that includes other systems that provide the functionality of
implementations. For example, mobile app prescription service 1310
performs many of the functions of implementations. Mobile app
prescription service 1310 includes claims database 1320 and
evaluation module 1330. Mobile app prescription service 1310
interacts with other systems through network 1340. The other
systems may include a medical app store 1350, a payor device 1360,
a patient device 1370, a prescriber device 1380, and a patient
population database 1390. These machines interact to provide the
functionality presented earlier in connection with FIG. 12 and as
will be now discussed in connection with the process illustrated in
FIG. 14. However, overall transactions are initiated when
prescriber device 1380 indicates to medical app store 1350 that it
is appropriate to provide a patient with access to a wireless
device application at patient device 1370. As illustrated in FIG.
4, the patient is given access to the app from medical app store
1350. Additionally, a payor device 1360 may participate in the
transaction to help manage the billing process.
[0065] After an app is successfully prescribed, information about
the claim, such as that illustrated in FIG. 5, may be transmitted
via network 1340 to mobile app prescription service 1310, which can
store the claim information in claims database 1320. Subsequently,
evaluation module 1330 processes data from claims database 1320 and
also accesses patient population database 1390. Patient population
database 1390 includes other information about patients, as
discussed above, that may be used in conjunction with the claims
from claims database 1320 to draw useful conclusions based on the
application prescription data as well as other information related
to the patient population. In FIG. 13, patient population database
1390 is portrayed as a centralized database on the cloud that
evaluation module 1330 of mobile app prescription service 1310 is
able to access through network 1340. However, the information in
patient population database 1390 may also be stored and/or
aggregated locally within mobile app prescription service 1310.
[0066] Thus, evaluation module 1330 accesses information about
claims in combination with other data about the patient population,
allowing evaluation module 1330 to derive meaningful, helpful
conclusions by analysis, as discussed above.
[0067] FIG. 14 is a flowchart of a process for gathering and
analyzing information about distribution of wireless device
applications.
[0068] At block 1410, data reports are received. More specifically,
one or more data reports are received via a communications network,
by an analytic server, from one or more wireless device application
providers that provide wireless device applications to patients,
each request comprising an anonymized patient identifier that
identifies the patient associated with the data report, and a
wireless device application identifier that identifies the wireless
device application associated with the data report, wherein the
wireless device application is provided to aid in the treatment of
one or more medical conditions of the patient. In the context of
FIG. 13, mobile app prescription service 1310 may receive such a
data report form medical app store 1350 and store information about
the data report in claims database 1320. The data reports may be
generated when prescriber device 1380 prescribes a wireless device
application to patient device 1370. Additionally, payor device 1360
may participate by contributing funds to facilitate the performance
of the transaction. In some situations, payor device 1360 may be
patient device 1370, if the patient pays for his or her own
application, or there may no payor device 1360 if the application
is free. Often payor device 1360 will be an insurance company.
[0069] At block 1420, patient population information is retrieved.
More specifically, patient population information is retrieved via
the communications network, by the analytic server, comprising
electronic medical information associated with a patient population
to whom wireless device applications were provided, using the
anonymized patient identifiers associated with each data report. In
the context of FIG. 13, evaluation module 1330 of mobile app
prescription service 1310 determines from claims database 1320
patient identifiers that were provided applications. Based on this
set of identifiers, evaluation module 1330 can access additional
information about patients prescribed applications from patient
population database 1390. As discussed previously, the accessed
information might include, for example, information about treatment
outcomes for patients that are prescribed applications. However,
the patient population information that is retrieved need not be
limited only to patients that are specifically provided wireless
device applications. For example, it may be desirable to retrieve
additional patient population information from patient population
database 1390 to use for comparison when analyzing the data. For
example, implementations may retrieve information about diabetics
who were prescribed a blood sugar tracking app to determine the
effects of the app on their treatment. However, implementations may
also retrieve information about diabetics who were not prescribed
the app in order to use as a control group for comparison purposes.
In general, the type of patient population information retrieved
from patient population database 1390 will vary based on the type
of conclusions and analysis a user would like to do.
[0070] At block 1430, data reports are organized into data sets.
More specifically, data reports are organized into different data
sets for analysis based on their wireless device application
identifier, wherein data reports in a data set are associated with
the same wireless device application identifier. In the context of
FIG. 13, evaluation module 1330 may perform the organization on the
data reports in claims database 1320. By grouping the data reports
in to data sets based on application identifier, the data for each
application is aggregated together. Because the data is aggregated,
it becomes possible to draw conclusions about the effects of
wireless device applications across a population without
jeopardizing the privacy of individual users. Furthermore,
additional organization of the data reports may occur. For example,
the data reports may be further organized prior to analysis based
up related information, such as demographics of the patients who
received apps, or other information such as co-administered
medications or treatment outcomes.
[0071] At block 1440, the data sets are analyzed. More
specifically, the data sets and the patient population information
are analyzed to generate a conclusion about the impact of a
wireless device application on a particular scenario. Many examples
of analysis have been presented in connection with FIGS. 1-12. As
noted previously, these conclusions may be quantitative or
qualitative. Additional aspects of what conclusions may be
generated are discussed below. In general, the analysis itself is
performed at evaluation module 1330 of mobile app prescription
service 1310.
[0072] At block 1450, the conclusion is reported. For example, the
conclusion may be displayed at a device of a participant in the
medical care process. Examples of reporting the conclusion are
shown in FIGS. 7, 8, 10 and 12.
[0073] Additionally, various implementations include a variety of
optional features and functionality. As discussed, in some
implementations, generating the conclusion includes generating
quantitative information about the impact of a wireless device
application on a particular scenario. In such implementations, the
mathematical and statistical analysis performed on the analyzed
data yield specific numerical results that provide specific metrics
of relationships between the information handled by
implementations.
[0074] In some implementations, the analyzing comprises comparing a
characteristic of a data set in which the wireless device
application was provided to a characteristic of a control set that
includes members of the patient population that were not using the
wireless device application. By comparing a data set that was
provided the application to a control data set that was not
provided the application, it is possible to help isolate and
identify effects on outcomes that stemmed from the prescription of
the application, as opposed to other effects. Examples of this
feature have been provided previously. For example, the
characteristic may be an average change in blood pressure, for
patient populations with and without a blood pressure tracking
app.
[0075] In some implementations, receiving the one or more data
reports further comprises receiving for each data report an
anonymized provider identifier that identifies the wireless device
application provider associated with the data report, the
retrieving further retrieves provider information associated with
each data report using the anonymized provider identifier
associated with the data report, and the analyzing further uses the
provider information to generate a conclusion about the effects of
providing a given wireless device application. For example, this
feature might entail gathering a group of patients prescribed an
app by one doctor, and another group of patients prescribed an app
by another doctor. Comparing the information for these groups may
lead to conclusions that one doctor is making better use of an
application than another, or more generalized conclusions, like
that the application provides better treatment outcomes when
provided by a specialist rather than a general practitioner, or
causes greater cost savings when provided by an in-network
physician than an out-of-network doctor.
[0076] In some implementations, retrieving the patient information
includes retrieving information about treatment outcomes for the
medical conditions of the patient, and the analyzing generates a
conclusion about the effects of the wireless device application on
the treatment outcomes of the one or more medical conditions.
Examples of this feature are provided above, such as the effects of
an app on hypertension. In some implementations, retrieving the
patient information includes retrieving information about treatment
outcomes for the medical conditions of the patient and a drug,
medical device, or other therapy prescribed to the patient, and the
analyzing generates a conclusion about the effects of
coadministration of the wireless device application the drug,
medical device, or other therapy on the treatment outcomes of the
one or more medical conditions. Examples of this feature are
provided above, such as the effects of an app in combination with a
certain medication. In some implementations, retrieving the patient
information includes retrieving information about treatment costs
for the medical conditions of the patient, and the analyzing
generates a conclusion about the effects of the wireless device
application on the treatment costs of the one or more diseases.
Examples of this feature are provided above, such as analyses for
an insurance company in FIG. 12 about the effects of providing an
app on treatment costs. In some implementations, organizing the
data reports further comprises filtering patients from the patent
population in one or more data sets based on one or more sets of
demographic attributes, and wherein the analyzing the data sets
comprises comparing a data set including patients with a first set
of demographic attributes to a data set including patients with a
second set of demographic attributes to generate a conclusion about
the different effects of providing a given wireless device
application to patients with the first set of demographic
attributes and the patients with the second set of demographic
attributes. FIGS. 11-12 provide an example of this feature. Some
implementations further comprise presenting the conclusion to a
physician for use in making a treatment or clinical decision. For
example, the conclusion may indicate that a patient with epilepsy
who is also prescribed one anticonvulsant should be prescribed one
epilepsy management app, while a patient with epilepsy who is
prescribed another anticonvulsant should be prescribed another
epilepsy management app. Some implementations further comprise
presenting the conclusion to a payor, insurance provider or a
pharmaceutical sales representative for use in making an economic,
marketing, or financial decision. For example, observing patterns
in how an acne management app is prescribed may suggest that a
pharmaceutical sales representative might want to market an acne
management drug to a dermatologist rather than a general
practitioner.
[0077] Implementations may use the medical data for a wide variety
of purposes, and the use of the medical data need not be
exclusively limited simply to providing diagnoses or treatment
recommendations. Indeed, as has been discussed extensively
throughout this application, the medical data may be used by an
application such as the second medical application to take
advantage of many helpful conclusions that can be derived from the
medical data, both with respect to that specific user and with
respect to larger populations to which the user belongs. For
example, such conclusions may be used to help make business
decisions.
[0078] Thus, while privacy concerns need to be respected, medical
data about individual users can be used not only for treatment, but
also for other purposes including medical and pharmaceutical
research, and also other applications ranging from law enforcement
to marketing. Additionally, it is possible to compare medical data
for individual users to medical data that has been aggregated for
groups of users. While this approach has been discussed above, it
is possible to aggregate data for populations of users, and obtain
statistics such as various averages or other metrics about the
population, and derive conclusions based on such comparisons.
Examples of such uses of the data have been discussed above. In
general, while implementations may use the medical data and its
context to improve medical care recommendations and outcomes, that
is not the only use of the medical data and implementations should
be understood to include any use of the medical data that is
helpful to a participant in the health care process, that may be
provided by the operation of the second medical application on the
medical data.
[0079] Implementations of the subject matter and the functional
operations described in this specification can be implemented in
digital electronic circuitry, in tangibly-implemented computer
software or firmware, in computer hardware, including the
structures disclosed in this specification and their structural
equivalents, or in combinations of one or more of them.
Implementations of the subject matter described in this
specification can be implemented as one or more computer programs,
i.e., one or more modules of computer program instructions encoded
on a tangible non-transitory program carrier for execution by, or
to control the operation of, data processing apparatus. The
computer storage medium can be a machine-readable storage device, a
machine-readable storage substrate, a random or serial access
memory device, or a combination of one or more of them.
[0080] The term "data processing apparatus" refers to data
processing hardware and encompasses all kinds of apparatus,
devices, and machines for processing data, including, by way of
example, a programmable processor, a computer, or multiple
processors or computers. The apparatus can also be or further
include special purpose logic circuitry, e.g., a central processing
unit (CPU), a FPGA (field programmable gate array), or an ASIC
(application-specific integrated circuit). In some implementations,
the data processing apparatus and/or special purpose logic
circuitry may be hardware-based and/or software-based. The
apparatus can optionally include code that creates an execution
environment for computer programs, e.g., code that constitutes
processor firmware, a protocol stack, a database management system,
an operating system, or a combination of one or more of them. The
present disclosure contemplates the use of data processing
apparatuses with or without conventional operating systems, for
example Linux, UNIX, Windows, Mac OS, Android, iOS or any other
suitable conventional operating system.
[0081] A computer program, which may also be referred to or
described as a program, software, a software application, a module,
a software module, a script, or code, can be written in any form of
programming language, including compiled or interpreted languages,
or declarative or procedural languages, and it can be deployed in
any form, including as a stand-alone program or as a module,
component, subroutine, or other unit suitable for use in a
computing environment. A computer program may, but need not,
correspond to a file in a file system. A program can be stored in a
portion of a file that holds other programs or data, e.g., one or
more scripts stored in a markup language document, in a single file
dedicated to the program in question, or in multiple coordinated
files, e.g., files that store one or more modules, sub-programs, or
portions of code. A computer program can be deployed to be executed
on one computer or on multiple computers that are located at one
site or distributed across multiple sites and interconnected by a
communication network. While portions of the programs illustrated
in the various figures are shown as individual modules that
implement the various features and functionality through various
objects, methods, or other processes, the programs may instead
include a number of sub-modules, third party services, components,
libraries, and such, as appropriate. Conversely, the features and
functionality of various components can be combined into single
components as appropriate.
[0082] The processes and logic flows described in this
specification can be performed by one or more programmable
computers executing one or more computer programs to perform
functions by operating on input data and generating output. The
processes and logic flows can also be performed by, and apparatus
can also be implemented as, special purpose logic circuitry, e.g.,
a central processing unit (CPU), a FPGA (field programmable gate
array), or an ASIC (application-specific integrated circuit).
[0083] Computers suitable for the execution of a computer program
include, by way of example, can be based on general or special
purpose microprocessors or both, or any other kind of central
processing unit. Generally, a central processing unit will receive
instructions and data from a read-only memory or a random access
memory or both. The essential elements of a computer are a central
processing unit for performing or executing instructions and one or
more memory devices for storing instructions and data. Generally, a
computer will also include, or be operatively coupled to receive
data from or transfer data to, or both, one or more mass storage
devices for storing data, e.g., magnetic, magneto-optical disks, or
optical disks. However, a computer need not have such devices.
Moreover, a computer can be embedded in another device, e.g., a
mobile telephone, a personal digital assistant (PDA), a mobile
audio or video player, a game console, a Global Positioning System
(GPS) receiver, or a portable storage device, e.g., a universal
serial bus (USB) flash drive, to name just a few.
[0084] Computer-readable media (transitory or non-transitory, as
appropriate) suitable for storing computer program instructions and
data include all forms of non-volatile memory, media and memory
devices, including by way of example semiconductor memory devices,
e.g., EPROM, EEPROM, and flash memory devices; magnetic disks,
e.g., internal hard disks or removable disks; magneto-optical
disks; and CD-ROM and DVD-ROM disks. The memory may store various
objects or data, including caches, classes, frameworks,
applications, backup data, jobs, web pages, web page templates,
database tables, repositories storing business and/or dynamic
information, and any other appropriate information including any
parameters, variables, algorithms, instructions, rules,
constraints, or references thereto. Additionally, the memory may
include any other appropriate data, such as logs, policies,
security or access data, reporting files, as well as others. The
processor and the memory can be supplemented by, or incorporated
in, special purpose logic circuitry.
[0085] To provide for interaction with a user, implementations of
the subject matter described in this specification can be
implemented on a computer having a display device, e.g., a CRT
(cathode ray tube), LCD (liquid crystal display), or plasma
monitor, for displaying information to the user and a keyboard and
a pointing device, e.g., a mouse or a trackball, by which the user
can provide input to the computer. Other kinds of devices can be
used to provide for interaction with a user as well; for example,
feedback provided to the user can be any form of sensory feedback,
e.g., visual feedback, auditory feedback, or tactile feedback; and
input from the user can be received in any form, including
acoustic, speech, or tactile input. In addition, a computer can
interact with a user by sending documents to and receiving
documents from a device that is used by the user; for example, by
sending web pages to a web browser on a user's client device in
response to requests received from the web browser.
[0086] The term "graphical user interface," or GUI, may be used in
the singular or the plural to describe one or more graphical user
interfaces and each of the displays of a particular graphical user
interface. Therefore, a GUI may represent any graphical user
interface, including but not limited to, a web browser, a touch
screen, or a command line interface (CLI) that processes
information and efficiently presents the information results to the
user. In general, a GUI may include a plurality of user interface
(UI) elements, some or all associated with a web browser, such as
interactive fields, pull-down lists, and buttons operable by the
business suite user. These and other UI elements may be related to
or represent the functions of the web browser.
[0087] Implementations of the subject matter described in this
specification can be implemented in a computing system that
includes a back-end component, e.g., as a data server, or that
includes a middleware component, e.g., an application server, or
that includes a front-end component, e.g., a client computer having
a graphical user interface or a Web browser through which a user
can interact with an implementation of the subject matter described
in this specification, or any combination of one or more such
back-end, middleware, or front-end components. The components of
the system can be interconnected by any form or medium of digital
data communication, e.g., a communication network. Examples of
communication networks include a local area network (LAN), a wide
area network (WAN), e.g., the Internet, and a wireless local area
network (WLAN).
[0088] The computing system can include clients and servers. A
client and server are generally remote from each other and
typically interact through a communication network. The
relationship of client and server arises by virtue of computer
programs running on the respective computers and having a
client-server relationship to each other.
[0089] While this specification contains many specific
implementation details, these should not be construed as
limitations on the scope of any invention or on the scope of what
may be claimed, but rather as descriptions of features that may be
specific to particular implementations of particular inventions.
Certain features that are described in this specification in the
context of separate implementations can also be implemented in
combination in a single implementation. Conversely, various
features that are described in the context of a single
implementation can also be implemented in multiple implementations
separately or in any suitable sub-combination. Moreover, although
features may be described above as acting in certain combinations
and even initially claimed as such, one or more features from a
claimed combination can in some cases be excised from the
combination, and the claimed combination may be directed to a
sub-combination or variation of a sub-combinations.
[0090] Similarly, while operations are depicted in the drawings in
a particular order, this should not be understood as requiring that
such operations be performed in the particular order shown or in
sequential order, or that all illustrated operations be performed,
to achieve desirable results. In certain circumstances,
multitasking and parallel processing may be helpful. Moreover, the
separation of various system modules and components in the
implementations described above should not be understood as
requiring such separation in all implementations, and it should be
understood that the described program components and systems can
generally be integrated together in a single software product or
packaged into multiple software products.
[0091] Particular implementations of the subject matter have been
described. Other implementations, alterations, and permutations of
the described implementations are within the scope of the following
claims as will be apparent to those skilled in the art. For
example, the actions recited in the claims can be performed in a
different order and still achieve desirable results.
[0092] Accordingly, the above description of example
implementations does not define or constrain this disclosure. Other
changes, substitutions, and alterations are also possible without
departing from the spirit and scope of this disclosure.
* * * * *