U.S. patent application number 17/681570 was filed with the patent office on 2022-09-01 for unified data interface and system.
The applicant listed for this patent is Palantir Technologies Inc.. Invention is credited to Chris Burchhardt, Tayler Cox, Kyle McLain, Harsh Pandey, Lekan Wang, Michael Winlo.
Application Number | 20220277816 17/681570 |
Document ID | / |
Family ID | 1000006333814 |
Filed Date | 2022-09-01 |
United States Patent
Application |
20220277816 |
Kind Code |
A1 |
Winlo; Michael ; et
al. |
September 1, 2022 |
UNIFIED DATA INTERFACE AND SYSTEM
Abstract
Various systems and methods are provided that aggregate,
analyze, and display health data for users. The system aggregates
data stored in various databases. For example, the system retrieves
data from these databases, maps the data to a set of common terms
based on an ontology, and displays such information to an entity
accessing the system. Rather than converting the data stored in the
databases into a standardized format, the system includes a set of
ontologies that provide a correlation between a first set of fields
and a second set of fields. The system determines a correlation
between a first field in the first set of fields and a second field
in the second set of fields using the ontology, stores data
retrieved from the database in a second database in association
with the second field, and displays the data associated with the
first field under the second field.
Inventors: |
Winlo; Michael; (Palo Alto,
CA) ; Burchhardt; Chris; (Palo Alto, CA) ;
McLain; Kyle; (Palo Alto, CA) ; Pandey; Harsh;
(Menlo Park, CA) ; Cox; Tayler; (Los Altos Hills,
CA) ; Wang; Lekan; (Palo Alto, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Palantir Technologies Inc. |
Denver |
CO |
US |
|
|
Family ID: |
1000006333814 |
Appl. No.: |
17/681570 |
Filed: |
February 25, 2022 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14975215 |
Dec 18, 2015 |
11302426 |
|
|
17681570 |
|
|
|
|
62099321 |
Jan 2, 2015 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G16H 40/20 20180101;
G16H 10/60 20180101 |
International
Class: |
G16H 10/60 20060101
G16H010/60; G16H 40/20 20060101 G16H040/20 |
Claims
1. A computing system comprising: one or more computer processors;
a database that organizes data in a plurality of first columns; a
computer readable storage medium storing program instructions
configured for execution by the one or more computer processor in
order to cause the computing system to: for a second database,
access a dataset stored in the second database, wherein the
accessed dataset comprises data for a plurality of users organized
in a plurality of second columns; determine a mapping between a
name of a second column in the plurality of second columns and a
name of a first column in the plurality of first columns; and cause
display of an unmodified version of the data in the accessed
dataset corresponding to the name of the second column in a user
interface under the name of the first column; receive a request to
access the computing system; determine an identity of a user
associated with the request to access the computing system;
retrieve, from the first database, user health data that is
associated with the determined user; retrieve, from a third
database, health claims data associated with the determined user;
categorize the determined user into a first group based on the
health claims data; train one or more models using the health
claims data and health claims data associated with one or more
other users to produce a set of feature weights associated with the
determined user, wherein each of the one or more models corresponds
to a state transition from the first group to another group in one
or more groups; determine a likelihood that the determined user
will transition from the first group into one of the one or more
other groups within a threshold time period using the set of
feature weights; translate the likelihood into a risk score; and
generate user interface data for rendering the user interface on a
computing device, wherein the user interface comprises an
indication of the risk score.
2. The computing system of claim 1, wherein the user interface
includes a first container that comprises an identification of at
least one third column in the plurality of first columns, wherein
the first container further comprises the retrieved user health
data that corresponds with the at least one third column.
3. The computing system of claim 1, wherein the retrieved health
claims data comprises medical claims submitted on behalf of the
determined user, and wherein the computer readable storage medium
further stores program instructions that cause the computing system
to generate a summary of a health history of the determined user
based on the medical claims.
4. The computing system of claim 1, wherein the retrieved user
health data comprises prescription data.
5. The computing system of claim 1, wherein the risk score is based
on at least one of a number of missing services associated with the
user, a priority of each missing service associated with the user,
a likelihood that the user seeks medical services without
intervention, or a number of times the user does not comply with a
recommended care plan.
6. The computing system of claim 1, wherein the mapping between the
name of the second column and the name of the first column is
determined based on an ontology.
7. The computing system of claim 1, wherein the user interface
further includes a first container that comprises a first alert
associated with a team member and a second alert associated with
the team member, wherein the first alert corresponds with the user,
and wherein the second alert corresponds with a second user.
8. The computing system of claim 1, wherein the computer readable
storage medium further stores program instructions that cause the
computing system to: receive text and a selection of a second team
member from a first team member; and transmit a message to an
account associated with the second team member, wherein the message
comprises the text, and wherein the second team member can view the
message when accessing the computing system.
9. The computing system of claim 8, wherein the first team member
is one of a primary care physician, a pharmacist, a government
agency employee, a guardian, or the user.
10. A computer-implemented method comprising: as implemented by one
or more computer systems comprising computer hardware and memory,
the one or more computer systems configured with specific
executable instructions, retrieving a dataset stored in a first
database, wherein the retrieved dataset comprises data for a
plurality of users organized in a plurality of second columns;
determining a mapping between a name of a second column in the
plurality of second columns and a name of a first column in a
plurality of first columns; causing display of an unmodified
version of the data in the retrieved dataset corresponding to the
name of the second column in a user interface under the name of the
first column; receiving a request to access the one or more
computer systems; determining an identity of a user associated with
the request to access the one or more computer systems; retrieving,
from the first database, user health data that is associated with
the determined user; retrieving, from a second database, health
claims data associated with the determined user; categorizing the
determined user into a first group based on the health claims data;
training one or more models using the health claims data and health
claims data associated with one or more other users to produce a
set of feature weights associated with the determined user, wherein
each of the one or more models corresponds to a state transition
from the first group to another group in one or more groups;
determining a likelihood that the determined user will transition
from the first group into one of the one or more other groups
within a threshold time period using the set of feature weights;
translating the likelihood into a risk score; and generating user
interface data for rendering the user interface on a computing
device, wherein the user interface comprises an indication of the
risk score.
11. The computer-implemented method of claim 10, wherein the user
interface includes a first container that comprises an
identification of at least one third column in the plurality of
first columns, wherein the first container further comprises the
retrieved user health data that corresponds with the at least one
third column.
12. The computer-implemented method of claim 11, further comprising
generating a summary of a health history of the determined user
based on the retrieved user health data, wherein the first
container further comprises the generated summary of the health
history of the determined user.
13. The computer-implemented method of claim 12, wherein the
retrieved health claims data comprises medical claims submitted on
behalf of the determined user, and wherein the computer-implemented
method further comprises generating the summary of the health
history of the determined user based on the medical claims.
14. The computer-implemented method of claim 10, wherein the
retrieved health claims data comprises prescription data.
15. The computer-implemented method of claim 10, further
comprising: receiving text and a selection of a second team member
from a first team member; and transmitting a message to an account
associated with the second team member, wherein the message
comprises the text, and wherein the second team member can view the
message when accessing the computing system.
16. The computer-implemented method of claim 15, wherein the first
team member is one of a primary care physician, a pharmacist, a
government agency employee, a guardian, or the user.
17. A non-transitory computer-readable storage medium including
computer-executable instructions that, when executed by a
processor, configure the processor to: retrieve a dataset stored in
a first database, wherein the retrieved dataset comprises data for
a plurality of users organized in a plurality of second columns;
determine a mapping between a name of a second column in the
plurality of second columns and a name of a first column in a
plurality of first columns; cause display of an unmodified version
of the data in the retrieved dataset corresponding to the name of
the second column in a user interface under the name of the first
column; receive a request to access one or more computer systems;
determine an identity of a user associated with the request to
access the one or more computer systems; retrieve, from the first
database, user health data that is associated with the determined
user; retrieve, from a second database, health claims data
associated with the determined user; categorize the determined user
into a first group based on the health claims data; train one or
more models using the health claims data and health claims data
associated with one or more other users to produce a set of feature
weights associated with the determined user, wherein each of the
one or more models corresponds to a state transition from the first
group to another group in one or more groups; determine a
likelihood that the determined user will transition from the first
group into one of the one or more other groups within a threshold
time period using the set of feature weights; translate the
likelihood into a risk score; and generate user interface data for
rendering the user interface on a computing device, wherein the
user interface comprises an indication of the risk score.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 14/975,215, filed on Dec. 18, 2015, which
claims priority under 35 U.S.C. .sctn. 119(e) to U.S. Provisional
Application No. 62/099,321, filed on Jan. 2, 2015, which are hereby
incorporated by reference in their entireties.
TECHNICAL FIELD
[0002] The present disclosure relates to systems and techniques for
data integration, analysis, and visualization.
BACKGROUND
[0003] Physical institutions are available to help vulnerable
populations, such as foster children, institutionalized patients,
those with behavioral health concerns, the homeless, and/or the
like. For example, the foster care system provides various wards,
group homes, and/or private homes for minors who can no longer live
with their biological parents or guardians. As another example,
homeless shelters and soup kitchens offer temporary housing and
food for those in need. Often, minors in the foster care system may
be placed in multiple foster homes within a short period of time
(e.g., less than a year) before they find a permanent residence.
Similarly, the homeless may pass between different homeless
shelters within a short period of time. The same may be true for
members of other vulnerable populations as well. Thus, information
about a member of a vulnerable population may be lost during this
transitory period.
SUMMARY
[0004] The systems, methods, and devices described herein each have
several aspects, no single one of which is solely responsible for
its desirable attributes. Without limiting the scope of this
disclosure, several non-limiting features will now be discussed
briefly.
[0005] As described above, members of vulnerable populations may
transition between different locations. As these members transition
between locations, important information about the member may be
lost. For example, a minor's medical history, hobbies, interests,
and/or the like may be lost if the information is not relayed to
the guardians of a new foster home. For the medical history in
particular, healthcare providers (e.g., physicians, specialists,
pharmacists, etc.) often keep detailed records about a patient.
However, if the minor transitions from one foster home in a first
geographic area to a second foster home in a second geographic
area, one or more of the minor's healthcare providers may change.
Even if the minor's healthcare records are transferred from an old
healthcare provider to a new healthcare provider, such transfers
may leave out important information that another healthcare
provider knows about the minor. For example, health information
related to the minor may be stored in separate databases (e.g., a
claims history may be stored in one database, prescription
information may be stored in another database, etc.). The separate
databases may not be linked or integrated in any way to allow
communication of this information among various healthcare
providers. Thus, a minor's old pharmacist may be aware of certain
medication that the minor is taking, but this information may not
be relayed to a new primary care physician. Likewise, information
that is helpful for building rapport between a minor and new health
professionals (e.g., hobbies, interests and other social factors)
is not often captured or preserved. In addition, sharing this
information amongst health professionals, foster parents, and the
minor can be difficult due to the fact that each of these groups of
people should only see the information relevant to their role.
[0006] Accordingly, the systems and methods described herein
provide an integrated health interface system that collects,
aggregates, analyzes, and displays health data for one or more
users. For example, the integrated health interface system may
collect, aggregate, analyze, and display health data for minors
that are a part of the foster care system and/or for any other
minor or adult patient. The integrated health interface system may
aggregate data stored in various databases. For example, one or
more of the various entities may be associated with one or more
databases that include information related to the healthcare of a
patient. The integrated health interface system may retrieve data
from these databases, map the data to a set of common terms based
on an ontology, and display such information to an entity accessing
the system. In one embodiment, instead of converting data received
from each of several sources into a standardized format, the
integrated health interface system may include a set of ontologies
that provide a correlation between fields of data from the various
sources and that contain common data types. For example, the
integrated health interface system may determine a correlation
between a first column header in a first set of fields from a first
data source and a second column header in a second set of fields
from a second data source using the ontology, store data retrieved
from the second data source in a second, local database in
association with the second column header, and then may display in
a user interface the data associated with the first column header
under the second column header (without modifying the actual
data).
[0007] The health interface system also provides input options so
that clinicians, foster parents, guardians, the minor, and/or
others can add detail and/or information to the one or more
databases.
[0008] One aspect of the disclosure provides a computing system
configured to access one or more databases in substantially
real-time in order to aggregate patient health information and
provide the aggregated information to a user in an interactive user
interface. The computing system comprises one or more computer
processors. The computing system further comprises a plurality of
databases each storing respective datasets. The computing system
further comprises a second database comprising retrieved datasets
organized in a plurality of first fields. The computing system
further comprises a computer readable storage medium storing
program instructions configured for execution by the one or more
computer processor in order to cause the computing system to: for
each database in the plurality of databases, access the dataset
stored in the respective database, where the accessed dataset
comprises data for a plurality of users, and where each data in the
retrieved dataset is associated with a second field in a plurality
of second fields; identify a name for each second field in the
retrieved dataset; determine a mapping between each identified
second field name and a name of a first field in the plurality of
first fields; and store the accessed dataset in the second database
such that each data in the accessed dataset is stored in
association with the first field that maps to the second field that
the respective data is associated with; receive a request to access
the computing system; determine an identity of a user associated
with the request to access the computing system; retrieve from the
second database user health data that is associated with the
determined user; generate a summary of a medical history of the
determined user based on the retrieved user health data; and
generate user interface data for rendering the interactive user
interface on a computing device.
[0009] The computing system of the preceding paragraph can have any
sub-combination of the following features: where the interactive
user interface includes a first container that comprises an
identification of at least one first field in the plurality of
first fields, where the first container further comprises the
retrieved user health data that corresponds with the at least one
first field and the generated summary of the medical history of the
determined user; where the retrieved user health data comprises
medical claims submitted on behalf of the determined user, and
where the computer readable storage medium further stores program
instructions that cause the computing system to generate the
summary of the medical history of the determined user based on the
medical claims; where the computer readable storage medium further
stores program instructions that cause the computing system to
generate an alert associated with the team member based on the
retrieved user health data, where the first container comprises the
generated alert; where the computer readable storage medium further
stores program instructions that cause the computing system to:
receive an indication that the generated alert is selected via the
interactive user interface, where the generated alert indicates
that the user missed an appointment, and update the user interface
data such that the interactive user interface includes a second
container comprising a list of selectable appointment times that
can be reserved for the user; where the computer readable storage
medium further stores program instructions that cause the computing
system to: receive an indication that the generated alert is
selected via the interactive user interface, where the generated
alert indicates that the user is missing a lab test, and update the
user interface data such that the interactive user interface
includes a second container comprising a map that graphically
displays a location of one or more lab facilities located near the
user where the lab test can be performed; where the retrieved user
health data comprises prescription data, where the team member is a
primary care physician, and where the alert is generated based on
the prescription data; where the computer readable storage medium
further stores program instructions that cause the computing system
to generate a risk score associated with the user, where the risk
score is generated based on the retrieved user health data; where
the risk score is generated based on at least one of a number of
missing services associated with the user, a priority of each
missing service associated with the user, a likelihood that the
user seeks medical services without intervention, or a number of
times the user does not comply with a recommended care plan; where
the mapping between each identified second field name and a name of
a first field in the plurality of first fields is determined based
on an ontology; where the interactive user interface further
includes a second container that comprises a first alert associated
with the team member and a second alert associated with the team
member, where the first alert corresponds with the user, and where
the second alert corresponds with a second user; where the computer
readable storage medium further stores program instructions that
cause the computing system to: receive text and a selection of a
second team member from the team member, and transmit a message to
an account associated with the second team member, where the
message comprises the text, and where the second team member can
view the message when accessing the computing system; where the
team member is one of a primary care physician, a pharmacist, a
government agency employee, a guardian, or the user.
[0010] Another aspect of the disclosure provides a
computer-implemented method of accessing one or more databases in
substantially real-time in order to aggregate patient health
information and provide the aggregated information to a user in an
interactive user interface. The computer-implemented method
comprises, as implemented by one or more computer systems
comprising computer hardware and memory, the one or more computer
systems configured with specific executable instructions,
retrieving dataset stored in a first database, where the retrieved
dataset comprises data for a plurality of users, and where each
data in the retrieved dataset is associated with a second field in
a plurality of second fields; identifying a name for each second
field in the retrieved dataset; determining a mapping between each
identified second field name and a name of a first field in a
plurality of first fields; storing the retrieved dataset in a
second database such that each data in the retrieved dataset is
stored in association with the first field that maps to the second
field that the respective data is associated with; receiving a
request to access the one or more computer systems; determining an
identity of a user associated with the request to access the
computing system; retrieving from the second database user health
data that is associated with the determined user; and generating
user interface data for rendering the interactive user interface on
a computing device, the interactive user interface including a
first container that comprises an identification of at least one
first field in the plurality of first fields, where the first
container further comprises the retrieved user health data that
corresponds with the at least one first field.
[0011] The computer-implemented method of the preceding paragraph
can have any sub-combination of the following features: where the
interactive user interface includes a first container that
comprises an identification of at least one first field in the
plurality of first fields, where the first container further
comprises the retrieved user health data that corresponds with the
at least one first field; where the method further comprises
generating a summary of a medical history of the determined user
based on the retrieved user health data, where the first container
further comprises the generated summary of the medical history of
the determined user; where the retrieved user health data comprises
medical claims submitted on behalf of the determined user, and
where the computer-implemented method further comprises generating
the summary of the medical history of the determined user based on
the medical claim; where the method further comprises generating an
alert associated with the team member based on the retrieved user
health data, where the first container comprises the generated
alert; where the method further comprises receiving an indication
that the generated alert is selected via the interactive user
interface, where the generated alert indicates that the user missed
an appointment, and updating the user interface data such that the
interactive user interface includes a second container comprising a
list of selectable appointment times that can be reserved for the
user; where the method further comprises receiving an indication
that the generated alert is selected via the interactive user
interface, where the generated alert indicates that the user is
missing a lab test, and updating the user interface data such that
the interactive user interface includes a second container
comprising a map that graphically displays a location of one or
more lab facilities located near the user where the lab test can be
performed; where the retrieved user health data comprises
prescription data, where the team member is a primary care
physician, and where the alert is generated based on the
prescription data; and where the method further comprises
generating a risk score associated with the user, where the risk
score is generated based on the retrieved user health data.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] FIG. 1 illustrates a block diagram of a system for
aggregating, analyzing, and displaying health data.
[0013] FIG. 2 illustrates a user interface displaying an ability to
search for patients.
[0014] FIG. 3 illustrates a user interface displaying a patient
profile.
[0015] FIG. 4 illustrates a user interface displaying a patient
medical history.
[0016] FIG. 5 illustrates a user interface displaying a patient
care plan.
[0017] FIG. 6 illustrates a user interface displaying a patient
health assessment.
[0018] FIG. 7 illustrates a user interface displaying a patient
clinical evaluation.
[0019] FIG. 8 illustrates a user interface displaying alerts and
messages for a care team member.
[0020] FIG. 9 illustrates a user interface displaying a breakdown
of remaining member visits by county.
[0021] FIG. 10 illustrates a user interface displaying a breakdown
of claims, visits, and costs by diagnoses and facilities.
[0022] FIG. 11 illustrates a user interface displaying a graph of
weighted care ratio by healthcare provider.
[0023] FIGS. 12A-12B illustrate user interfaces displaying a
location of care team members.
[0024] FIG. 13 illustrates a user interface displaying a location
of healthcare providers.
[0025] FIG. 14 is a flowchart depicting an illustrative operation
of aggregating, analyzing, and displaying health data.
[0026] FIG. 15 illustrates a computer system with which certain
methods discussed herein may be implemented.
DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS
Overview
[0027] As described above, minors in the foster care system may
often be placed in multiple foster homes. As a minor transitions
from one foster home to another, important information about the
minor may be lost. For example, the minor's medical history,
hobbies, interests, and/or the like may be lost if the information
is not relayed to the guardians of the new foster home. For the
medical history in particular, healthcare providers (e.g.,
physicians, specialists, pharmacists, etc.) often keep detailed
records about a patient. However, if the minor transitions from one
foster home in a first geographic area to a second foster home in a
second geographic area, one or more of the minor's healthcare
providers may change. Even if the minor's healthcare records are
transferred from an old healthcare provider to a new healthcare
provider, such transfers may leave out important information that
another healthcare provider knows about the minor. For example,
health information related to the minor may be stored in separate
databases (e.g., a claims history may be stored in one database,
prescription information may be stored in another database, etc.).
The separate databases may not be linked or integrated in any way
to allow communication of this information among various healthcare
providers. Thus, a minor's old pharmacist may be aware of certain
medication that the minor is taking, but this information may not
be relayed to a new primary care physician.
[0028] In some cases, a care team may manage the healthcare of a
minor. For example, the care team may include a care team leader
and one or more care team members who monitor whether a minor is
receiving proper healthcare. The care team may interact with the
minor, the minor's guardians, the minor's physician(s), the minor's
specialist(s), the minor's pharmacist, and/or government agencies
(e.g., state child welfare agencies). However, each of these
entities may store different data related to the minor in
different, disparate databases, as described above. Thus, the
members of the care team may have trouble finding the appropriate
health data to ensure that the minor is receiving proper
healthcare.
[0029] Accordingly, the systems and methods are described herein
provide an integrated health interface system that aggregates,
analyzes, and displays health data for one or more users. For
example, the integrated health interface system may aggregate,
analyze, and display health data for minors that are a part of the
foster care system. However, this is not meant to be limiting. The
integrated health interface system described herein may aggregate,
analyze, and display health data for any patient.
[0030] The integrated health interface system may be accessible by
a plurality of entities. For example, physicians, specialists,
pharmacists, patients, guardians, government agencies, and/or the
like may access the integrated health interface system. Each of the
various entities may be associated with an access level such that a
respective entity can only view data that has been authorized for
viewing by the respective entity. Alternatively or in addition, the
integrated health interface system can support discover permissions
where a physician, specialist, pharmacist, patient, guardian,
government agencies, and/or another such user can discover that a
piece of data is available, but be notified that the respective
user does not have permission to view the available data and must
gain special permission in order to view the available data.
[0031] The integrated health interface system may aggregate data
stored in various databases. For example, one or more of the
various entities may be associated with one or more databases that
include information related to the healthcare of a patient. The
integrated health interface system may retrieve data from these
databases, map the data to a set of common terms based on an
ontology, and display such information to an entity accessing the
system. For example, instead of converting the data stored in the
databases into a standardized format, the integrated health
interface system may include a set of ontologies that provide a
correlation between a first set of fields and a second set of
fields. The first set of fields may be column headers in a
database. The second set of fields may be a list of common column
headers that may be included in the displayed information. The
integrated health interface system may determine a correlation
between a first column header in the first set of fields and a
second column header in the second set of fields using the
ontology, store data retrieved from the database in a second, local
database in association with the second column header, and then may
display in a user interface the data associated with the first
column header under the second column header (without modifying the
actual data). In this way, new databases can be seamlessly linked
to the integrated health interface system such that the integrated
health interface system can populate a user interface with data
from the new database without having to modify the data to fit a
standard format.
[0032] In an embodiment, the integrated health interface system
generates alerts and/or notifications that are associated with
specific entities. For example, the alerts and/or notifications may
indicate that a task needs to be performed, a task has already been
performed, an appointment was missed, lab results are missing, a
prescription was not filled or refilled at the proper time, and/or
the like. These alerts and/or notifications may be derived from the
data stored in the various databases. In addition, an alert and/or
notification directed at one entity may be derived from data stored
in a database associated with another entity. When logged into the
integrated health interface system, an entity (via a device used to
log into the integrated health interface system) may also be able
to view alerts and/or notifications that are directed to other
entities.
[0033] In a further embodiment, the integrated health interface
system provides actionable services via a generated user interface.
For example, the integrated health interface system may generate a
user interface that is then rendered by a device operated by an
entity when the entity logs into the integrated health interface
system. The integrated health interface system can further generate
an alert and/or notification to be displayed in the user interface
in response to one of the conditions described herein occurring.
The alert and/or notification can indicate to a care team member
that a patient missed an appointment, that a patient has a missing
lab result, and/or the like. In response to a notification that a
patient missing an appointment, the user interface may include an
option to view available appointment times and schedule a new
appointment. As another example, in response to a notification that
a patient has a missing lab result, the user interface may include
an option to view the locations of nearby facilities that can
perform the relevant lab tests and/or to schedule an
appointment.
[0034] In some embodiments, the alert and/or notification is
automatically transmitted to the device operated by the entity
associated with the alert and/or notification. The alert and/or
notification can be transmitted at the time that the alert and/or
notification is generated or at some determined time after
generation of the alert and/or notification. When received by the
device, the alert and/or notification can cause the device to
display the alert and/or notification via the activation of an
application on the device (e.g., a browser, a mobile application,
etc.). For example, receipt of the alert and/or notification may
automatically activate an application on the device, such as a
messaging application (e.g., SMS or MMS messaging application), a
standalone application (e.g., a health data monitoring
application), or a browser, for example, and display information
included in the alert and/or notification. If the device is offline
when the alert and/or notification is transmitted, the application
may be automatically activated when the device is online such that
the alert and/or notification is displayed. As another example,
receipt of the alert and/or notification may cause a browser to
open and be redirected to a login page generated by the integrated
health interface system so that the entity can log in to the
integrated health interface system and view the alert and/or
notification. Alternatively, the alert and/or notification may
include a URL of a webpage (or other online information) associated
with the alert and/or notification, such that when the device
(e.g., a mobile device) receives the alert, a browser (or other
application) is automatically activated and the URL included in the
alert and/or notification is accessed via the Internet.
Health Interface System Overview
[0035] FIG. 1 illustrates a block diagram of a system 100 for
aggregating, analyzing, and displaying health data. The system 100
comprises one or more primary care provider devices 110A, one or
more specialist provider devices 110B, one or more other provider
devices 110N, a care team device 130, a patient device 150, a
foster parent device 160, a pharmacist device 170, a government
device 180, a health interface system 140, and/or a network
120.
[0036] In the embodiment illustrated in FIG. 1, the one or more
primary care provider devices 110A (e.g., operated by a doctor,
nurse, hospital or clinic staff, etc.), the one or more specialist
provider devices 110B (e.g., operated by a specialist, a
specialist's staff, etc.), the one or more other provider devices
110N, the care team device 130 (e.g., operated by a care team
member or leader), the patient device 150 (e.g., operated by a
patient), the foster parent device 160 (e.g., operated by the
guardians of a patient), the pharmacist device 170 (e.g., operated
by a pharmacist), and the government device 180 (e.g., operated by
a member of a government agency, such as a state child welfare
agency), which may each be implemented by one or more first
physical computing devices, are communicatively connected to the
health interface system 140, which may be implemented by one or
more second physical computing devices, over the network 120. In
some embodiments, each such physical computing device may be
implemented as a computer system including some or all of the
components illustrated in the example computing system 1500 of FIG.
15. For example, the one or more primary care provider devices
110A, the one or more specialist provider devices 110B, the one or
more other provider devices 110N, the care team device 130, the
patient device 150, the foster parent device 160, the pharmacist
device 170, and the government device 180 may be implemented in a
computer system as a set of program instructions recorded on a
machine-readable storage medium.
[0037] The one or more primary care provider devices 110A, the one
or more specialist provider devices 110B, the one or more other
provider devices 110N, the care team device 130, the patient device
150, the foster parent device 160, the pharmacist device 170, and
the government device 180 may communicate with the health interface
system 140 to access health information related to one or more
patients. Each of the various entities may be associated with an
access level such that a respective entity can only access and view
data that has been authorized for viewing by the respective entity.
Alternatively or in addition, the health interface system 140 can
support discover permissions where an entity can discover that a
piece of data is available, but be notified that the respective
entity does not have permission to view the available data and must
gain special permission in order to view the available data.
[0038] One or more of the primary care provider devices 110A, the
specialist provider devices 110B, the other provider devices 110N,
the care team device 130, the patient device 150, the foster parent
device 160, the pharmacist device 170, and the government device
180 may be associated with one or more databases.
[0039] For example, the one or more databases may be associated
with and/or maintained by various entities. Such entities may
include a health maintenance organization (HMO), a social services
or other government agency, and/or a data integration system. The
HMO database can include medical claims, pharmacy claims, health
risk assessments (e.g., GAIN-SS, PCS-17, etc.), electronic medical
records, lab results, vitals (e.g., blood pressure, heart rate,
etc.), care plan data (e.g., a patients' primary care and/or
treating physicians, current medications, allergies, and/or other
clinically relevant information), immunization records, prior
authorization information, case management system data, and/or the
like. The government agency database can include details about
patients' foster parents, guardians, and/or primary care givers,
criminal records, school records, and/or the like. The data
integration system database can include enriched metrics (e.g.,
metrics derived from combining data stored in one or more
databases). Enriched metrics can include average medical
expenditure per month, average pharmacy expenditure per month,
average total expenditure (e.g., medical and pharmacy) per month,
predicted medical, pharmacy, and/or total expenditure per month, a
patient's deviation from expected costs per month, a number of
unique prescribers, a number of unique medications (used by one
patient or patients in the aggregate), a number of Schedule 2 drugs
(as defined by the United States Controlled Substances Act) used by
one patient or patients in the aggregate, a costliest diagnosis, an
average emergency room utilization rate, an average primary care
physician visit rate, a distance to an assigned primary care
physician for one or more patients, an average in-patient rate,
geo-spatial data about patients, care teams, and/or health
facilities, health risk scores, a number of missing medical
services for which patients are eligible, and/or the like.
[0040] The one or more of the primary care provider devices 110A,
the specialist provider devices 110B, the other provider devices
110N, the care team device 130, the patient device 150, the foster
parent device 160, the pharmacist device 170, and/or the government
device 180 may receive data from the one or more databases via an
application programming interface (API) or adaptor, a connection
interface, and/or other access point to a transactional or data
warehouse system maintained by the HMO and/or government agency.
Data can also be stored at a central location (e.g., a server) and
delivered to the various entities via a network. Data can also be
stored locally on a storage medium (e.g., a hard disk, optical
disk, solid state drive, memory, etc.).
[0041] The health interface system 140 may aggregate data stored in
the various databases. For example, the health interface system 140
may retrieve data from these databases, map the data to a set of
common terms based on an ontology, and generate one or more user
interfaces to display such information to an entity accessing the
health interface system 140, as described in greater detail below.
Rather than converting the data stored in the databases into a
standardized format, the health interface system 140 may include a
set of ontologies that provide a correlation between a first set of
fields and a second set of fields. For example, the first set of
fields may be column headers in a database and the second set of
fields may be a list of common column headers that may be included
in the generated user interface. The health interface system 140
may determine a correlation between a first field in the first set
of fields and a second field in the second set of fields using the
ontology, store data retrieved from the database in a second, local
database (e.g., local to the health interface system 140) in
association with the second field, and then may display in a user
interface the data associated with the first field under the second
field (without modifying the actual data). In this way, new
databases can be seamlessly linked to the health interface system
140 such that the health interface system 140 can populate a user
interface with data from the new database without having to modify
the data to fit a standard format.
[0042] When executed by one or more processors of the computer
system, logic in the health interface system 140 is operable to
aggregate, analyze, and display health data according to the
techniques described herein. In one embodiment, the health
interface system 140 may be implemented in a Java Virtual Machine
(JVM) that is executing in a distributed or non-distributed
computer system. In other embodiments, the health interface system
140 may be implemented as a combination of programming instructions
written in any programming language (e.g. C++ or Visual Basic) and
hardware components (e.g., memory, CPU time) that have been
allocated for executing the program instructions.
[0043] In an embodiment, the network 120 includes any
communications network, such as the Internet. The network 120 may
be a wired network, a wireless network, or a combination of the
two. For example, network 120 may be a local area network (LAN)
and/or a wireless area network (WAN).
Example User Interfaces
[0044] FIG. 2 illustrates a user interface 200 displaying an
ability to search for patients. The interface 200 may be generated
by the health interface system 140 and viewable on any of the
entities in communication with the health interface system 140. As
illustrated in FIG. 2, the interface 200 includes a pane 202. The
pane 202 may display data according to a button selected by the
user. For example, the user may have selected search button 212.
Thus, the pane 202 may include a search box 204 that allows a user
to search for a patient. The user may search for a patient by
providing the patient's name, identification, social security
number, or any other unique identifier. Searching for a patient may
bring up information about the patient, such as the patient's
profile, which is described below with respect to FIG. 3.
[0045] FIG. 3 illustrates a user interface 300 displaying a patient
profile. The interface 300 may be generated by the health interface
system 140 and viewable on any of the entities in communication
with the health interface system 140. As illustrated in FIG. 3, the
user has selected profile button 214. Thus, the pane 202 may
include various data derived from the linked databases, such as
biographical data about the patient, the hobbies and/or interests
of the patient, some fun facts about the patient, and/or health
data associated with the patient. Some of the data may be retrieved
directly from a database and displayed in the pane 202 (after the
ontology is used to determine a correlation or mapping between
database fields and common fields).
[0046] Other data may be generated and displayed based on an
analysis of the data retrieved from one or more databases. For
example, information displayed in the medical snapshot section may
be derived from medical and/or pharmaceutical claims data. Medical
claims may include claims that are submitted to insurance companies
to receive payment for medical services administered by the
healthcare provider. Likewise, pharmaceutical claims may include
claims that are submitted to insurance companies to receive payment
for drugs distributed by the healthcare provider. Similarly,
information related to the most seen primary care provider (PCP) or
the last seen specialist in the contacts section may be derived
from the medical and/or pharmaceutical claims.
[0047] As another example, information displayed in the medical
snapshot section may include a map that shows the location of a
patient relative to a location of one or more providers and/or
health facilities involved in the care of the patient, an average
distance traveled by a patient to receive care (e.g., to measure
health access friction), a current deviation of a patient's
expected or predicted costs, a current deviation from expected
costs as a number of standard deviations from a population average,
a propensity score predicting the likelihood that a patient's
medical costs may deviate by a threshold value in the future, one
or more top medical conditions that contribute the most to patient
costs (e.g., from aggregated medical claims data), suspected
conditions (e.g., conditions suspected to be suffered by a patient
based on a mapping of diagnosis codes to conditions assigned to
and/or associated with the patient), a number of missing services
for which a patient is eligible (e.g., if asthmatic, a
determination can be made whether the patient has received a
prescription for a preventer medication in the calendar year), a
sum of possibly preventable emergency room expenditures (e.g., for
emergency room admissions, diagnoses can be assigned a probability
that that condition could have been treated in an alternative
facility or avoided. The sum of the probability multiplied by the
actual treatment expenditure can provide a possibly preventable
expenditure value), and/or the like.
[0048] In an embodiment, a user can generate a report that includes
some or all of the displayed health data in the pane 202 by
selecting report button 302. The generated report may be made
available to other entities that access the health interface system
140 (e.g., accessible when the other entities log in to the health
interface system 140).
[0049] The user interface 300 may also provide actionable services.
As described above, the health interface system 140 can generate
alerts and/or notifications to be displayed in the user interface
300 in response to a determination that a task needs to be
performed, a task has already been performed, an appointment was
missed, lab results are missing, a prescription was not filled or
refilled at the proper time, and/or the like. The generated alerts
and/or notifications can be displayed in the user interface 300.
For example, the notifications/alerts section in the user interface
300 indicates that the patient missed a service. Other actionable
services that can be depicted in the user interface 300 include
allowing a user to schedule an appointment if a notification
indicates that an appointment was missed, assigning a patient to a
specific health intervention (e.g., health coaching) so as to tag
the patient and transmit the patient's information to a team for
outreach, sending a secure message to any individual of the
patient's care team, re-assigning the patient's PCP to another
provider (e.g., someone closer to the patient, a provided
experienced in the particular condition(s) of the patient, etc.),
exporting a summary and/or full report of the patient's medical
history (including all patient information) for the purposes of
facilitating a hand-off to another provider, sending a reminder for
an appointment and/or prescription collection to the patient or a
person associated with the patient (e.g., the patient's foster
parent, parent, guardian, care giver, etc.), issuing a new patient
ID card to a patient if the patient lost one, re-assigning a
patient to a new case manager or any other health care provider,
and/or the like. Accordingly, the user may select the notification
or otherwise indicate that the user would like to schedule an
appointment for the patient so that the patient receives the
service. In response to a selection of the notification or an
indication that the user would like to schedule an appointment, the
user interface 300 may display a list of available appointment
times to see the relevant provider. In addition, the user interface
300 may display a map to show the geographic location of one or
more providers so that the user can choose, for example, the
provider nearest to the patient.
[0050] In some embodiments, the alert and/or notification is
automatically transmitted to an entity in communication with the
health interface system 140. The alert and/or notification can be
transmitted by the health interface system 140 at the time that the
alert and/or notification is generated or at some determined time
after generation of the alert and/or notification. When received by
the entity, the alert and/or notification can cause the entity to
display the alert and/or notification via the activation of an
application on the entity (e.g., a browser, a mobile application,
etc.). For example, receipt of the alert and/or notification may
cause a mobile application to generate a push notification that is
displayed. As another example, receipt of the alert and/or
notification may cause a browser to open and be redirected to a
login page generated by the health interface system 140 so that the
entity can log in to the health interface system 140 and view the
alert and/or notification via the user interface 300.
[0051] FIG. 4 illustrates a user interface 400 displaying a patient
medical history. The interface 400 may be generated by the health
interface system 140 and viewable on any of the entities in
communication with the health interface system 140. As illustrated
in FIG. 4, the user has selected medical history button 216. Thus,
the pane 202 may include various data derived from the linked
databases related to the medical history of the patient, such as
past lab results, medications taken by the patient, allergies of
the patient, the last visits to see a provider by the patient,
and/or the like. For example, the medications data may be derived
from the database that stores pharmaceutical claims.
[0052] The pane 202 may further include a risk score in the medical
profile section. The risk score may represent a propensity for
observed medical costs associated with a patient to deviate
significantly (e.g., more than a threshold value) from expected
medical costs within a time period (e.g., 12 months). The risk
score may be based on claims data (e.g., medical and pharmaceutical
claims data), coverage data (e.g., patient coverage/eligibility
information), patient demographic data, a number of missing
services associated with the patient, a priority of each missing
service associated with the patient, a likelihood that the patient
seeks medical services without intervention, a number of times the
patient does not comply with a recommended care plan, a sum of
amounts paid on medical claims for a patient (e.g., over a period
of time, such as 12 months), an average amount paid on medical
claims for a patient (e.g., over a period of time, such as 12
months), a per patient per month medical cost (e.g., over a period
of time, such as 12 months), a sum of amounts paid on
pharmaceutical claims for a patient (e.g., over a period of time,
such as 12 months), an average amount paid on pharmaceutical claims
for a patient (e.g., over a period of time, such as 12 months), a
per patient per month pharmaceutical cost (e.g., over a period of
time, such as 12 months), a per patient per month combined medical
and pharmaceutical cost (e.g., over a period of time, such as 12
months), a sum of amounts paid on medical and pharmaceutical claims
for a patient (e.g., over a period of time, such as 12 months), a
difference between expected cost (e.g., a capitation rate given a
set of Hierarchical Condition Categories (HCCs) adjusted for
medical loss ratio) and observed cost (e.g., over a period of time,
such as 12 months), a population average difference between
expected cost and observed cost (e.g., over a period of time, such
as 12 months), a population standard deviation of difference
between expected cost and observed cost (e.g., over a period of
time, such as 12 months), a per-patient deviation from expected
costs (e.g., in standard deviations) from the population average
(e.g., over a period of time, such as 12 months), a sum of a
patient's HCC coefficients (e.g., over a period of time, such as 12
months), a capitation rate given a set of HCCs and a Centers for
Medicare and Medicaid Services (CMS) plan rating of at least three
and a half stars (e.g., over a period of time, such as 12 months),
a capitation rate given a set of HCCs adjusted for medical loss
ratio (e.g., over a period of time, such as 12 months), a sum of
emergency room encounters (e.g., over a period of time, such as 12
months), a sum of possibly preventable emergency room costs (e.g.,
over a period of time, such as 12 months), a sum of in-patient
encounters (e.g., over a period of time, such as 12 months), a list
of unique national drug code (NDC) codes for drugs prescribed
(e.g., over a period of time, such as 12 months), a list of unique
drug names for drugs prescribed (e.g., over a period of time, such
as 12 months), a list of unique pharmacological classes for drugs
prescribed (e.g., over a period of time, such as 12 months), a list
of unique Drug Enforcement Agency (DEA) Schedules for drugs
prescribed (e.g., over a period of time, such as 12 months), a
count of unique drugs prescribed (e.g., over a period of time, such
as 12 months), flags for different condition categories based on a
proprietary mapping of ICD-9, CPT, and HCPCS codes to suspected
conditions (e.g., over a period of time, such as 12 months), flags
for different HCCs based on CMS mapping of ICD-9 codes to chronic
conditions (e.g., over a period of time, such as 12 months), and/or
the like. For example, the expected medical costs may be a cost
that would be expected given a patient's disease burden and
calculated by assigning HCCs to members, summing the capitation
premium for those HCCs, and adjusting for medical loss ratio.
Observed medical costs can be calculated as per patient per medical
costs over eligible months during the relevant time period. The
deviation from expected medical costs is then calculated by
subtracting observed medical costs from expected medical costs.
[0053] The risk factors may be weighted to generate the risk score.
For example, some patients may have experienced an acute incident
in their recent past that has caused their cost and utilization to
spike temporarily. The medical costs associated with these patients
may regress to the cost and/or utilization mean and may not benefit
significantly from care management resources (as the chronically
ill or poorly managed patients would). To address the possibility
of regressing to the cost and/or utilization mean, the health
interface system 140 can categorize a patient into one of three
groups: high-deviation (e.g., observed average monthly medical
costs exceed expected average monthly medical costs by a threshold
value), chronic (e.g., a patient that has one or more high risk
chronic conditions, as suggested by the patient's claim history,
but whose observed average monthly medical costs do not exceed
expected average monthly medical costs by the threshold value), or
non-chronic low-deviation (e.g., a patient that does not have one
or more high risk chronic conditions, as suggested by the patient's
claim history, and whose observed average monthly medical costs do
not exceed the expected average monthly medical costs by the
threshold value). Once categorized, the health interface system 140
can train nine different logistic regression models, one for each
of the following state transitions: high-deviation to
high-deviation, high-deviation to chronic, high-deviation to
non-chronic low-deviation, chronic to high-deviation, chronic to
chronic, chronic to non-chronic low-deviation, non-chronic
low-deviation to high-deviation, non-chronic low-deviation to
chronic, and non-chronic low-deviation to non-chronic
low-deviation. The training set for each model may include a sample
of all eligible patients. The model training can use L1
regularization to address the collinearity between several of the
cost metrics by inducing sparseness on the model. For each patient,
the health interface system 140 can generate features for a period
of time (e.g., 12 months) before and a period of time (e.g., 12
months) after a selected split date. The output of each model
training cycle can be a set of feature weights (e.g., coefficients
in a logistic regression model) that can be used to compute
propensity scores for each of the state transitions listed
above.
[0054] Once trained, the health interface system 140 can calculate
propensity scores (e.g., a likelihood that a patient will move in
to or remain in a given state for a period of time, such as 12
months) for a patient for each of the patient's three possible
state transitions (e.g., there are three possible state transitions
because the patient has already been categorized as starting in one
of three categories). For each state transition, features can be
weighted according to a trained model. The health interface system
140 can rank some or all patients by a propensity score associated
with the transition to a high-deviation state, and the ranking of a
patient can be translated into a risk score. In some embodiments,
the user interface 400 may provide the option to the user to
customize the weighting employed to generate the risk score (e.g.,
the factors used to generate the risk score, the threshold value
that determines whether a patient is categorized as high-deviation,
etc.).
[0055] The user may select care plan button 402 to view a patient's
care plan, as described below with respect to FIG. 5, and the user
may select health assessment button 404 to view a patient's health
assessment, as described below with respect to FIG. 6.
[0056] FIG. 5 illustrates a user interface 500 displaying a patient
care plan 502. The interface 500 may be generated by the health
interface system 140 and viewable on any of the entities in
communication with the health interface system 140. As illustrated
in FIG. 5, the user has selected care plan button 218. Thus, the
pane 202 displays the care plan 502. The care plan 502 may allow
all authorized members of the care team to view the current and
past care plans for the patient. Centralized storage of this data
via the health interface system 140 may allow care team members and
patient's providers access to baseline data in order to gauge the
effectiveness and/or progress that a patient has made in any given
care plan. The availability of care plans may also allow some or
all of the various entities the ability to collaborate on current
care plan goals and/or monitor progress.
[0057] In some embodiments, the care plan 502 is interactive. For
example, the health interface system 140 can receive the care plan
via an API such that one or more fields are editable (by an entity
with sufficient permissions) when displayed in the user interface
500. The user interface 500 can display relevant input options
showing the editable fields when an editable field is selected. If
a field is edited, the health interface system 140 can synch the
updated care plan 502 with the health plan's case management
system. In other embodiments, the care plan 502 is static (e.g.,
received as a PDF)
[0058] FIG. 6 illustrates a user interface 600 displaying a patient
health assessment. The interface 600 may be generated by the health
interface system 140 and viewable on any of the entities in
communication with the health interface system 140. As illustrated
in FIG. 6, the user has selected health assessment button 220.
Thus, the pane 202 displays a patient health assessment. The health
assessment may allow all authorized members of the care team to
view the current and/or past health assessments that have been
conducted for the patient. The availability of these assessments
may enable some or all members of the care team to access
information that is critical in addressing each patient's specific
needs. In addition to allowing a historical starting measure of the
patient, assessment information may also allow the care team to
determine when new assessments should be generated.
[0059] FIG. 7 illustrates a user interface 700 displaying a patient
clinical evaluation. The interface 700 may be generated by the
health interface system 140 and viewable on any of the entities in
communication with the health interface system 140. As illustrated
in FIG. 7, the user has selected vitals button 222. Thus, the pane
202 displays a set of clinical evaluations for the patient. The
clinical evaluations may include date-specific recorded vitals
signs, such as temperature, pulse, blood pressure, and/or
respiratory rate. These vitals may allow providers to view a
summary of the patient's health vitals and determine whether it is
necessary to determine changes in a health status observed by
different providers. Each instance of vitals may allow entities to
enter notes regarding dated entries and observations.
[0060] FIG. 8 illustrates a user interface 800 displaying alerts
and messages for a care team member. The interface 800 may be
generated by the health interface system 140 and viewable on any of
the entities in communication with the health interface system 140.
As illustrated in FIG. 8, the user has selected alert button 224.
Thus, the pane 202 displays alerts and/or notifications. The alerts
and/or notifications may be for one or more patients that the
viewing entity provides services for. The alerts and/or
notifications may be derived from data stored in the databases.
Example alerts and/or notifications can include a close appointment
alert (e.g., a patient has an appointment coming up in the next
week, day, hour, etc.), a missed appointment alert (e.g., if a
patient missing an appointment), a propensity score shift (e.g., if
a patients' propensity or risk score status changes, and the health
provider can also be alerted), a recent admission to an emergency
room (or a pre-authorization request from a health provider), a
recent in-patient event (or pre-authorization request from a health
provider), no interaction by the patient with the health interface
system 140 for a period of time (e.g., 6 months), reminders for
scheduled check-ins with a patient, and/or the like, In some cases,
the alerts and/or notifications may be generated based on data
associated with an entity that is different than the entity that
has logged into the health interface system 140. For example, a
pharmacist may have logged into the health interface system 140 and
an alert may have been generated for the pharmacist based on data
stored in a database associated with a primary care provider.
[0061] The notifications may inform an entity of what tasks have
been accomplished and what tasks still need to be accomplished. The
notifications and/or alerts may be color-coded to indicate an
entity associated with the notification and/or alert and/or to
indicate an importance of the notification and/or alert (e.g.,
green may mean the notification and/or alert is not vital, whereas
red may mean the notification and/or alert is urgent).
[0062] In an embodiment, entities can communicate with each other
via the health interface system 140. For example, one entity can
send a message to another entity via the health interface system
140. Any messages sent via the health interface system 140 may be
viewable in the user interface 800 in the messages section.
Example User Interfaces Depicting Additional Analytics
[0063] In some cases, the health interface system 140 can analyze
health data at a macro level to, for example, provide insight on
the features of a patient population as a whole in a given
geographic region. FIG. 9 illustrates a user interface 900
displaying a breakdown of remaining member visits by county. The
interface 900 may be generated by the health interface system 140
and viewable on any of the entities in communication with the
health interface system 140. As illustrated in FIG. 9, a map 902
indicates a location, by county, of patients that may require a
visit (e.g., a well-child visit) within a given period of time
(e.g., 90 days). The map 902 may include shading to indicate
counties that have a high number of required visits and a low
number of required visits. The pane 202 may include a numerical
breakdown of the number of required visits by county, medical
group, and/or provider.
[0064] FIG. 10 illustrates a user interface 1000 displaying a
breakdown of claims, visits, and costs by diagnoses and facilities.
The interface 1000 may be generated by the health interface system
140 and viewable on any of the entities in communication with the
health interface system 140. As illustrated in FIG. 10, the pane
202 includes a list of the top diagnoses by cost associated with
emergency room visits for a given patient population.
[0065] FIG. 11 illustrates a user interface 1100 displaying a graph
1102 of weighted care ratio by healthcare provider. The interface
1100 may be generated by the health interface system 140 and
viewable on any of the entities in communication with the health
interface system 140. As illustrated in FIG. 11, the pane 202
includes the graph 1102 and a table that display a provider network
as assessed by their care ratio (e.g., the percentage of associated
patients who actually received the medical services for which they
were eligible), which can be determined by the health interface
system 140. The care ratio and the weighted care ratio allow
entities to evaluate the character of the provider network when it
comes to identifying which providers are best suited to caring for
a patient in the patient population.
[0066] In an embodiment, a care ratio is a measure of compliance,
applicable to providers, and can be specific to a particular
medical service. A care ratio can be a percentage of how many
patients eligible for a particular service have actually received
that service. For example, if a provider has 100 diabetics
associated with them, and there is an interest in knowing how many
of these diabetics have had an HbA1c test in the last 12 months,
the health interface system 140 would take the number of diabetics
receiving this test and divide that by the total number of eligible
patients. If the number of diabetics receiving this test is 60 and
the total number of eligible patients is 100, the provider's care
ratio would therefore be 60%.
[0067] In an embodiment, a weighted care ratio is a measure of how
well a provider is addressing a particular missing service for
their assigned patients for the purposes of comparing providers.
The weighted care ratio is weighted because the ratio takes into
account the number of patients that are assigned to a provider. The
care ratios of providers with more patients may contribute
proportionally more to the population average for all providers.
Providers with very few patients may typically be assigned the
average for the population rather than their true care ratio. The
weighted care ratio can avoid overemphasizing the care ratio of a
provider that has just a few patients. For example, if the care
ratio is "percent of membership receiving an HbA1c test in last 12
months" (e.g., a measure applicable to diabetics only), and a
provider only has one patient with diabetes and that patient has
not had that service, then that provider's care ratio would be 0%.
Instead, applying the logic of the weighted care ratio, that
provider would receive the average care ratio for the population
(e.g., 60%). Thus, this can prevent over-indexing on providers
assigned to small populations of patients.
Example User Interfaces Depicting Actionable Services
[0068] FIGS. 12A-12B illustrate user interfaces 1200 displaying a
location of care team members. The interface 1200 may be generated
by the health interface system 140 and viewable on any of the
entities in communication with the health interface system 140. As
illustrated in FIG. 12A, the location of various care team members
in one or more care teams is displayed. For example, the care team
members may be shaded to indicate what team the care team member is
a member of. The interface 1200 may also an entity to contact a
care team member that is selected. For example, care team member
John Gold is selected and thus may be contacted via phone or
electronic message (e.g., text message).
[0069] As illustrated in FIG. 12B, a filter 1202 can be selected
such that one or more care team members can be hidden. For example,
the entity may select one or more care teams, and those care team
members that are not a member of the selected care team may
disappear from the interface 1200.
[0070] FIG. 13 illustrates a user interface 1300 displaying a
location of healthcare providers. The interface 1300 may be
generated by the health interface system 140 and viewable on any of
the entities in communication with the health interface system 140.
As illustrated in FIG. 13, the location of various providers is
displayed. For example, the providers nearest to a patient may be
displayed. The interface 1300 may also an entity to contact a
provider that is selected and/or to schedule an appointment with a
selected provider. For example, provider 2 is selected. An entity
may contact provider 2 via the phone or may be redirected to a page
that allows the entity to schedule an appointment with the
provider.
Example Process Flow
[0071] FIG. 14 is a flowchart 1400 depicting an illustrative
operation of aggregating, analyzing, and displaying health data.
Depending on the embodiment, the method of FIG. 14 may be performed
by various computing devices, such as by the health interface
system 140. Depending on the embodiment, the method of FIG. 14 may
include fewer and/or additional blocks and the blocks may be
performed in an order different than illustrated.
[0072] In block 1402, a health dataset stored in a database is
retrieved. For example, the health dataset may include medical
and/or pharmaceutical claims data. The health dataset may include a
set of second fields (e.g., columns).
[0073] In block 1404, a name for each second field in the retrieved
health dataset is identified. In block 1406, a mapping between each
identified second field name and a name of a first field in a
plurality of first fields is determined. The plurality of first
fields may include common terms.
[0074] In block 1408, the retrieved health dataset is stored in a
second database such that each data in the retrieved health dataset
is stored in associated with the first field that maps to the
second field that the respective data is associated with. For
example, the data may be unchanged, however the column headers for
the data may be modified.
[0075] In block 1410, an identity of a patient for which records
are requested is determined. For example, a care team member may
desire to view the records of a specific patient.
[0076] In block 1412, user interface data is generated for
rendering an interactive user interface on a computing device that
includes data stored in the second database that is associated with
the patient. The interactive user interface may display an
identification of the first fields in association with the
data.
Implementation Mechanisms
[0077] According to one embodiment, the techniques described herein
are implemented by one or more special-purpose computing devices.
The special-purpose computing devices may be hard-wired to perform
the techniques, or may include digital electronic devices such as
one or more application-specific integrated circuits (ASICs) or
field programmable gate arrays (FPGAs) that are persistently
programmed to perform the techniques, or may include one or more
general purpose hardware processors programmed to perform the
techniques pursuant to program instructions in firmware, memory,
other storage, or a combination. Such special-purpose computing
devices may also combine custom hard-wired logic, ASICs, or FPGAs
with custom programming to accomplish the techniques. The
special-purpose computing devices may be desktop computer systems,
server computer systems, portable computer systems, handheld
devices, networking devices or any other device or combination of
devices that incorporate hard-wired and/or program logic to
implement the techniques.
[0078] Computing device(s) are generally controlled and coordinated
by operating system software, such as iOS, Android, Chrome OS,
Windows XP, Windows Vista, Windows 7, Windows 8, Windows Server,
Windows CE, Unix, Linux, SunOS, Solaris, iOS, Blackberry OS,
VxWorks, or other compatible operating systems. In other
embodiments, the computing device may be controlled by a
proprietary operating system. Conventional operating systems
control and schedule computer processes for execution, perform
memory management, provide file system, networking, I/O services,
and provide a user interface functionality, such as a graphical
user interface ("GUI"), among other things.
[0079] For example, FIG. 15 is a block diagram that illustrates a
computer system 1500 upon which an embodiment may be implemented.
For example, any of the computing devices discussed herein, such as
the one or more primary care provider devices 110A, the one or more
specialist provider devices 110B, the one or more other provider
devices 110N, the care team device 130, the patient device 150, the
foster parent device 160, the pharmacist device 170, the government
device 180, and/or the health interface system 140 may include some
or all of the components and/or functionality of the computer
system 1500.
[0080] Computer system 1500 includes a bus 1502 or other
communication mechanism for communicating information, and a
hardware processor, or multiple processors, 1504 coupled with bus
1502 for processing information. Hardware processor(s) 1504 may be,
for example, one or more general purpose microprocessors.
[0081] Computer system 1500 also includes a main memory 1506, such
as a random access memory (RAM), cache and/or other dynamic storage
devices, coupled to bus 1502 for storing information and
instructions to be executed by processor 1504. Main memory 1506
also may be used for storing temporary variables or other
intermediate information during execution of instructions to be
executed by processor 1504. Such instructions, when stored in
storage media accessible to processor 1504, render computer system
1500 into a special-purpose machine that is customized to perform
the operations specified in the instructions.
[0082] Computer system 1500 further includes a read only memory
(ROM) 1508 or other static storage device coupled to bus 1502 for
storing static information and instructions for processor 1504. A
storage device 1510, such as a magnetic disk, optical disk, or USB
thumb drive (Flash drive), etc., is provided and coupled to bus
1502 for storing information and instructions.
[0083] Computer system 1500 may be coupled via bus 1502 to a
display 1512, such as a cathode ray tube (CRT) or LCD display (or
touch screen), for displaying information to a computer user. An
input device 1514, including alphanumeric and other keys, is
coupled to bus 1502 for communicating information and command
selections to processor 1504. Another type of user input device is
cursor control 1516, such as a mouse, a trackball, or cursor
direction keys for communicating direction information and command
selections to processor 804 and for controlling cursor movement on
display 1512. This input device typically has two degrees of
freedom in two axes, a first axis (e.g., x) and a second axis
(e.g., y), that allows the device to specify positions in a plane.
In some embodiments, the same direction information and command
selections as cursor control may be implemented via receiving
touches on a touch screen without a cursor.
[0084] Computing system 1500 may include a user interface module to
implement a GUI that may be stored in a mass storage device as
executable software codes that are executed by the computing
device(s). This and other modules may include, by way of example,
components, such as software components, object-oriented software
components, class components and task components, processes,
functions, attributes, procedures, subroutines, segments of program
code, drivers, firmware, microcode, circuitry, data, databases,
data structures, tables, arrays, and variables.
[0085] In general, the word "module," as used herein, refers to
logic embodied in hardware or firmware, or to a collection of
software instructions, possibly having entry and exit points,
written in a programming language, such as, for example, Java, Lua,
C or C++. A software module may be compiled and linked into an
executable program, installed in a dynamic link library, or may be
written in an interpreted programming language such as, for
example, BASIC, Perl, or Python. It will be appreciated that
software modules may be callable from other modules or from
themselves, and/or may be invoked in response to detected events or
interrupts. Software modules configured for execution on computing
devices may be provided on a computer readable medium, such as a
compact disc, digital video disc, flash drive, magnetic disc, or
any other tangible medium, or as a digital download (and may be
originally stored in a compressed or installable format that
requires installation, decompression or decryption prior to
execution). Such software code may be stored, partially or fully,
on a memory device of the executing computing device, for execution
by the computing device. Software instructions may be embedded in
firmware, such as an EPROM. It will be further appreciated that
hardware modules may be comprised of connected logic units, such as
gates and flip-flops, and/or may be comprised of programmable
units, such as programmable gate arrays or processors. The modules
or computing device functionality described herein are preferably
implemented as software modules, but may be represented in hardware
or firmware. Generally, the modules described herein refer to
logical modules that may be combined with other modules or divided
into sub-modules despite their physical organization or storage
[0086] Computer system 1500 may implement the techniques described
herein using customized hard-wired logic, one or more ASICs or
FPGAs, firmware and/or program logic which in combination with the
computer system causes or programs computer system 1500 to be a
special-purpose machine. According to one embodiment, the
techniques herein are performed by computer system 1500 in response
to processor(s) 1504 executing one or more sequences of one or more
instructions contained in main memory 1506. Such instructions may
be read into main memory 1506 from another storage medium, such as
storage device 1510. Execution of the sequences of instructions
contained in main memory 1506 causes processor(s) 1504 to perform
the process steps described herein. In alternative embodiments,
hard-wired circuitry may be used in place of or in combination with
software instructions.
[0087] The term "non-transitory media," and similar terms, as used
herein refers to any media that store data and/or instructions that
cause a machine to operate in a specific fashion. Such
non-transitory media may comprise non-volatile media and/or
volatile media. Non-volatile media includes, for example, optical
or magnetic disks, such as storage device 1510. Volatile media
includes dynamic memory, such as main memory 1506. Common forms of
non-transitory media include, for example, a floppy disk, a
flexible disk, hard disk, solid state drive, magnetic tape, or any
other magnetic data storage medium, a CD-ROM, any other optical
data storage medium, any physical medium with patterns of holes, a
RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip
or cartridge, and networked versions of the same.
[0088] Non-transitory media is distinct from but may be used in
conjunction with transmission media. Transmission media
participates in transferring information between nontransitory
media. For example, transmission media includes coaxial cables,
copper wire and fiber optics, including the wires that comprise bus
802. Transmission media can also take the form of acoustic or light
waves, such as those generated during radio-wave and infra-red data
communications.
[0089] Various forms of media may be involved in carrying one or
more sequences of one or more instructions to processor 804 for
execution. For example, the instructions may initially be carried
on a magnetic disk or solid state drive of a remote computer. The
remote computer can load the instructions into its dynamic memory
and send the instructions over a telephone line using a modem. A
modem local to computer system 1500 can receive the data on the
telephone line and use an infra-red transmitter to convert the data
to an infra-red signal. An infra-red detector can receive the data
carried in the infra-red signal and appropriate circuitry can place
the data on bus 1502. Bus 1502 carries the data to main memory
1506, from which processor 1504 retrieves and executes the
instructions. The instructions received by main memory 1506 may
retrieve and execute the instructions. The instructions received by
main memory 1506 may optionally be stored on storage device 1510
either before or after execution by processor 1504.
[0090] Computer system 1500 also includes a communication interface
1518 coupled to bus 1502. Communication interface 1518 provides a
two-way data communication coupling to a network link 1520 that is
connected to a local network 1522. For example, communication
interface 1518 may be an integrated services digital network (ISDN)
card, cable modem, satellite modem, or a modem to provide a data
communication connection to a corresponding type of telephone line.
As another example, communication interface 1518 may be a local
area network (LAN) card to provide a data communication connection
to a compatible LAN (or WAN component to communicated with a WAN).
Wireless links may also be implemented. In any such implementation,
communication interface 1518 sends and receives electrical,
electromagnetic or optical signals that carry digital data streams
representing various types of information.
[0091] Network link 1520 typically provides data communication
through one or more networks to other data devices. For example,
network link 1520 may provide a connection through local network
1522 to a host computer 1524 or to data equipment operated by an
Internet Service Provider (ISP) 1526. ISP 1526 in turn provides
data communication services through the world wide packet data
communication network now commonly referred to as the "Internet"
1528. Local network 1522 and Internet 1528 both use electrical,
electromagnetic or optical signals that carry digital data streams.
The signals through the various networks and the signals on network
link 1520 and through communication interface 1518, which carry the
digital data to and from computer system 1500, are example forms of
transmission media.
[0092] Computer system 1500 can send messages and receive data,
including program code, through the network(s), network link 1520
and communication interface 1518. In the Internet example, a server
1530 might transmit a requested code for an application program
through Internet 1528, ISP 1526, local network 1522 and
communication interface 1518.
[0093] The received code may be executed by processor 1504 as it is
received, and/or stored in storage device 1510, or other
non-volatile storage for later execution.
Terminology
[0094] Each of the processes, methods, and algorithms described in
the preceding sections may be embodied in, and fully or partially
automated by, code modules executed by one or more computer systems
or computer processors comprising computer hardware. The processes
and algorithms may be implemented partially or wholly in
application-specific circuitry.
[0095] The various features and processes described above may be
used independently of one another, or may be combined in various
ways. All possible combinations and subcombinations are intended to
fall within the scope of this disclosure. In addition, certain
method or process blocks may be omitted in some implementations.
The methods and processes described herein are also not limited to
any particular sequence, and the blocks or states relating thereto
can be performed in other sequences that are appropriate. For
example, described blocks or states may be performed in an order
other than that specifically disclosed, or multiple blocks or
states may be combined in a single block or state. The example
blocks or states may be performed in serial, in parallel, or in
some other manner. Blocks or states may be added to or removed from
the disclosed example embodiments. The example systems and
components described herein may be configured differently than
described. For example, elements may be added to, removed from, or
rearranged compared to the disclosed example embodiments.
[0096] Conditional language, such as, among others, "can," "could,"
"might," or "may," unless specifically stated otherwise, or
otherwise understood within the context as used, is generally
intended to convey that certain embodiments include, while other
embodiments do not include, certain features, elements and/or
steps. Thus, such conditional language is not generally intended to
imply that features, elements and/or steps are in any way required
for one or more embodiments or that one or more embodiments
necessarily include logic for deciding, with or without user input
or prompting, whether these features, elements and/or steps are
included or are to be performed in any particular embodiment.
[0097] Any process descriptions, elements, or blocks in the flow
diagrams described herein and/or depicted in the attached figures
should be understood as potentially representing modules, segments,
or portions of code which include one or more executable
instructions for implementing specific logical functions or steps
in the process. Alternate implementations are included within the
scope of the embodiments described herein in which elements or
functions may be deleted, executed out of order from that shown or
discussed, including substantially concurrently or in reverse
order, depending on the functionality involved, as would be
understood by those skilled in the art.
[0098] The term "a" as used herein should be given an inclusive
rather than exclusive interpretation. For example, unless
specifically noted, the term "a" should not be understood to mean
"exactly one" or "one and only one"; instead, the term "a" means
"one or more" or "at least one," whether used in the claims or
elsewhere in the specification and regardless of uses of
quantifiers such as "at least one," "one or more," or "a plurality"
elsewhere in the claims or specification.
[0099] The term "comprising" as used herein should be given an
inclusive rather than exclusive interpretation. For example, a
general purpose computer comprising one or more processors should
not be interpreted as excluding other computer components, and may
possibly include such components as memory, input/output devices,
and/or network interfaces, among others.
[0100] It should be emphasized that many variations and
modifications may be made to the above-described embodiments, the
elements of which are to be understood as being among other
acceptable examples. All such modifications and variations are
intended to be included herein within the scope of this disclosure.
The foregoing description details certain embodiments of the
invention. It will be appreciated, however, that no matter how
detailed the foregoing appears in text, the invention can be
practiced in many ways. As is also stated above, it should be noted
that the use of particular terminology when describing certain
features or aspects of the invention should not be taken to imply
that the terminology is being re-defined herein to be restricted to
including any specific characteristics of the features or aspects
of the invention with which that terminology is associated. The
scope of the invention should therefore be construed in accordance
with the appended claims and any equivalents thereof.
* * * * *