U.S. patent application number 16/154760 was filed with the patent office on 2019-05-16 for systems and methods for clinical decision-making.
This patent application is currently assigned to WellDoc, Inc.. The applicant listed for this patent is WellDoc, Inc.. Invention is credited to Mansur SHOMALI, Bharath SUDHARSAN.
Application Number | 20190147995 16/154760 |
Document ID | / |
Family ID | 52116464 |
Filed Date | 2019-05-16 |
United States Patent
Application |
20190147995 |
Kind Code |
A1 |
SUDHARSAN; Bharath ; et
al. |
May 16, 2019 |
SYSTEMS AND METHODS FOR CLINICAL DECISION-MAKING
Abstract
Computer implemented methods are disclosed. The methods may
include receiving historical data comprising at least one of
provider data and patient data, and processing, using a processor,
the historical data to identify one or more patterns. The method
also may include generating one or more decision models from the
historical data and the decision patterns, and providing one or
more recommendations based on the one or more decision models.
Inventors: |
SUDHARSAN; Bharath;
(Baltimore, MD) ; SHOMALI; Mansur; (Ellicott City,
MD) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
WellDoc, Inc. |
Columbia |
MD |
US |
|
|
Assignee: |
WellDoc, Inc.
Columbia
MD
|
Family ID: |
52116464 |
Appl. No.: |
16/154760 |
Filed: |
October 9, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14311736 |
Jun 23, 2014 |
|
|
|
16154760 |
|
|
|
|
61839528 |
Jun 26, 2013 |
|
|
|
Current U.S.
Class: |
705/2 |
Current CPC
Class: |
G06N 5/048 20130101;
G16H 40/63 20180101; G16H 50/20 20180101; G06F 19/328 20130101;
G16H 40/20 20180101; G16H 50/50 20180101; G16H 50/70 20180101; G16H
20/10 20180101; G06N 5/04 20130101; G06F 19/3456 20130101; G16H
40/67 20180101 |
International
Class: |
G16H 20/10 20060101
G16H020/10; G16H 50/20 20060101 G16H050/20; G16H 50/70 20060101
G16H050/70; G06N 5/04 20060101 G06N005/04; G16H 50/50 20060101
G16H050/50 |
Claims
1. A computer-implemented method for automatically providing a
treatment recommendation, the method comprising: receiving
historical data comprising at least one of provider data and
patient data; processing, using a processor, the historical data to
identify one or more patterns; generating one or more decision
models from the historical data and the decision patterns; and
providing one or more recommendations based on the one or more
decision models.
2. The computer-implemented method of claim 1, further comprising
receiving electronic feedback on at least one of the one or more
recommendations.
3. The computer-implemented method of 2, further comprising storing
the electronic feedback as historical data.
4. The computer-implemented method of 2, further comprising
exchanging the electronic feedback with a third party.
5. The computer-implemented method of claim 1, further comprising
receiving real-time data comprising at least one of provider data
and patient data.
6. The computer-implemented method of claim 5, wherein the
historical data comprises treatment instructions and the real-time
data comprises compliance with the treatment instructions.
7. The computer-implemented method of claim 5, wherein the
real-time data is received from a patient's electronic device.
8. The computer-implemented method of claim 1, further comprising
extracting metadata from the historical data.
9. The computer-implemented method of claim 8, further comprising
biasing the historical data based on the metadata.
10. The computer-implemented method of claim 1, wherein the
processor uses one or more machine learning algorithms.
11. The computer-implemented method of claim 1, wherein the
generating one or more decision models comprises importing models
from a library of models.
12. The computer-implemented method of claim 1, further comprising
accessing one or more medical records and parsing the historical
data from the one or more medical records.
13. The computer-implemented method of claim 1, further comprising
presenting the one or more identified patterns to a provider.
14. The computer-implemented method of claim 1, further comprising
receiving instructions to modify the one or more decision
models.
15. The computer-implemented method of claim 1, further comprising
providing a comparison between the one or more recommendations, a
recommendation based on standard guidelines, and a recommendation
based on external data.
16. The computer-implemented method of claim 1, wherein one of the
patient data and provider data comprises demographic
information.
17. An information processing device for providing a treatment
recommendation, the device comprising: a processor for processing a
set of instructions; and a computer-readable storage medium for
storing the set of instructions, wherein the instructions, when
executed by the processor, perform a method comprising: receiving
historical data comprising at least one of provider data and
patient data; processing, using a processor, the historical data to
identify one or more patterns; generating one or more decision
models from the historical data and the decision patterns; and
providing one or more recommendations based on the one or more
decision models.
18. The information processing device of claim 17, the method
further comprising receiving electronic feedback on at least one of
the one or more recommendations.
19. The information processing device of claim 17, the method
further comprising further comprising receiving real-time data
comprising at least one of provider data and patient data.
20. A non-transitory computer-readable medium storing a set of
instructions that, when executed by a processor, perform a method
of providing a treatment recommendation, the method comprising:
receiving historical data comprising at least one of provider data
and patient data; processing, using a processor, the historical
data to identify one or more patterns; generating one or more
decision models from the historical data and the decision patterns;
and providing one or more recommendations based on the one or more
decision models.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This Application claims the benefit of U.S. Provisional
Application No. 61/839,528, entitled "Systems and Methods for
Managing Patient Conditions", filed Jun. 26, 2013, the disclosure
of which is incorporated herein by reference in its entirety.
TECHNICAL FIELD
[0002] The present disclosure relates generally to providing
recommendations based on receiving and processing historical data.
More specifically, the present disclosure relates to systems and
methods for learning decision-making and providing recommendations
based on the learned decision-making. In some embodiments, the
recommendation may be made automatically.
BACKGROUND
[0003] Increased healthcare costs have limited patient access to
appropriate care. At the same time, healthcare companies have
increased provider workloads and limited physician-patient
interactions. This in turn may lead to improper patient assessments
and treatment. In an attempt to increase physician productivity and
improve the accuracy of patient assessments, methods have been
attempted to implement clinical rules and validated
mathematical/statistical models based on patient diagnostic
information. Some conventional methods provide patient assessment
reports prior to a patient's next physician visit. These reports
include data submitted by patients, such as daily blood glucose
levels, dietary intake, etc. However, such methods do not provide
an analysis of the data and/or or recommendations tailored to the
patient and/or based on the healthcare provider's characteristics
and preferences.
[0004] Thus, a need exists for improved systems and methods for
increasing healthcare provider productivity, accurately assessing a
patient, and providing patient treatment consistent with the
healthcare provider's treatment style and/or decision-making
characteristics.
SUMMARY
[0005] Embodiments of the present disclosure relate to, among other
things, methods and systems for providing a treatment
recommendation. Each of the embodiments disclosed herein may
include one or more of the features described in connection with
any of the other disclosed embodiments.
[0006] According to certain embodiments, computer-implemented
methods are disclosed for automatically providing a treatment
recommendation, the method may include receiving historical data
comprising at least one of provider data and patient data;
processing, using a processor, the historical data to identify one
or more patterns; generating one or more decision models from the
historical data and the decision patterns; and providing one or
more recommendations based on the one or more decision models.
[0007] Aspects of the method may include one or more of the
following: further comprising receiving electronic feedback on at
least one of the one or more recommendations; further comprising
storing the electronic feedback as historical data; further
comprising exchanging the electronic feedback with a third party;
further comprising receiving real-time data comprising at least one
of provider data and patient data; wherein the historical data
comprises treatment instructions and the real-time data comprises
compliance with the treatment instructions; wherein the real-time
data is received from a patient's electronic device; further
comprising extracting metadata from the historical data; further
comprising biasing the historical data based on the metadata;
wherein the processor uses one or more machine learning algorithms;
wherein the generating one or more decision models comprises
importing models from a library of models; further comprising
accessing one or more medical records and parsing the historical
data from the one or more medical records; further comprising
presenting the one or more identified patterns to a provider;
further comprising receiving instructions to modify the one or more
decision models; further comprising providing a comparison between
the one or more recommendations, a recommendation based on standard
guidelines, and a recommendation based on external data; and
wherein one of the patient data and provider data comprises
demographic information.
[0008] In another aspect, disclosed is an information processing
device for providing a treatment recommendation, the device may
include a processor for processing a set of instructions, and a
computer-readable storage medium for storing the set of
instructions, wherein the instructions, when executed by the
processor, perform a method comprising receiving historical data
comprising at least one of provider data and patient data;
processing, using a processor, the historical data to identify one
or more patterns; generating one or more decision models from the
historical data and the decision patterns; and providing one or
more recommendations based on the one or more decision models.
[0009] The processing device may include one or more of the
following features: the method further comprising receiving
electronic feedback on at least one of the one or more
recommendations; and the method further comprising further
comprising receiving real-time data comprising at least one of
provider data and patient data.
[0010] In another aspect, disclosed is a non-transitory
computer-readable medium storing a set of instructions that, when
executed by a processor, may perform a method of providing a
treatment recommendation, the method may include receiving
historical data comprising at least one of provider data and
patient data; processing, using a processor, the historical data to
identify one or more patterns; generating one or more decision
models from the historical data and the decision patterns; and
providing one or more recommendations based on the one or more
decision models.
[0011] It may be understood that both the foregoing general
description and the following detailed description are exemplary
and explanatory only and are not restrictive of the invention, as
claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The accompanying drawings, which are incorporated in and
constitute a part of this specification, illustrate exemplary
embodiments of the present disclosure and together with the
description, serve to explain the principles of the disclosure.
[0013] FIG. 1 is flow diagram of an exemplary method for clinical
decision-making, according to an exemplary embodiment of the
present disclosure;
[0014] FIG. 2 is a flow diagram of an exemplary method for data
collection, according to an exemplary embodiment of the present
disclosure;
[0015] FIG. 3 is a flow diagram of an exemplary method for
extracting and identifying metadata, according to an exemplary
embodiment of the present disclosure;
[0016] FIG. 4 is a flow diagram of an exemplary method for
selecting and applying algorithms to data, according to an
exemplary embodiment of the present disclosure;
[0017] FIG. 5 is a flow diagram of an exemplary method for
evaluating and modifying a recommendation, according to an
exemplary embodiment of the present disclosure;
[0018] FIG. 6 is a flow diagram of an exemplary method for
collecting data, according to an exemplary embodiment of the
present disclosure;
[0019] FIG. 7A is flow diagram an exemplary method for
electronically selecting a recommendation, according to an
exemplary embodiment of the present disclosure;
[0020] FIG. 7B is a flow a flow diagram of an exemplary method for
electronically presenting a clinical decision, model to a provider
and a patient, according to an exemplary embodiment of the present
disclosure;
[0021] FIG. 8 is a schematic diagram of an arrangement by which a
clinical decision may be generated, according to an exemplary
embodiment of the present disclosure; and
[0022] FIG. 9 is a simplified functional block diagram of a
computer that may be configured as a host server, for example, to
function as healthcare provider decision-making server, according
to an exemplary embodiment of the present disclosure.
DESCRIPTION OF THE EMBODIMENTS
Overview
[0023] The present disclosure is drawn to systems and methods for
providing recommendations based on analyzing past decisions. More
specifically, the present disclosure relates to systems and methods
for analyzing historical data to learn provider decision-making,
applying machine learning algorithms to generate decision models,
and providing (e.g. automatically) recommendations on subsequent
scenarios based on the learned decision-making.
EXEMPLARY EMBODIMENTS
[0024] FIG. 1 is a flow diagram of an exemplary method for
providing a treatment recommendation 100. In some embodiments, the
depicted method 100 may be used for automatic clinical
decision-making. As shown in FIG. 1, a healthcare provider (the
provider), such as a physician, dentist, physical therapist,
psychologist, and/or other healthcare professional may register
with a service provider to receive automatic recommendations for
treating a patient 102 in any suitable manner. For example, the
healthcare provider may electronically communicate with a service
providing clinical recommendations (the service) to indicate
interest in receiving clinical recommendations. The electronic
communication may be via an internal or external network, such as
via the Internet and/or any other electronic network. In some
embodiments, the electronic communication may be via a wired or a
wireless network (e.g. Wi-Fi, Blue Tooth, and/or near field
communication). During registration, the provider may provide
relevant information to the service, such as billing information,
type of healthcare practice (e.g. pediatric, psychiatry, internal
medicine, and/or surgical), and/or information about the provider's
practice and preferences (e.g. proponent of surgical intervention,
proponent of alternative medical therapies such as yoga and
meditation). In some examples, the service may provide confirmation
of registration and/or request further information from the
provider to complete registration in any suitable manner. The
service also may provide the provider with materials to access its
services, for example by providing a software application (such as
a mobile application) having a graphical user interface (GUI)
and/or codes to access restricted web-sites. In some examples, the
software application may allow the provider to view, transmit, and
receive information to and from the service via the GUI. The
provider may designate any preferences to the service during the
registration step 102 and/or any other time. For example, the
provider may indicate, via the GUI, that the service should only be
used for patients who have a blood glucose level above, e.g. 130
mg/dL. In some examples, the service may provide programming, such
as software applications, that may be integrated with existing
provider programming. For example, the programming (e.g. a software
application) provided by the service may be integrated/compatible
or otherwise able to communicate with the provider's programming
for electronic medical records, electronic billing, and electronic
scheduling. The provider also may instruct that the service to
provide selective access to patient's. For example, during
registration 102 or at any other time, the provider may allow a
patient to selectively view information provided by the service and
allow the patient to submit relevant patient data to the service,
either selectively or automatically (e.g. via automatic updates
from a patient's electronic device). In one embodiment, the
provider may allow a patient to download the service's software
application to the patients electronic device and allow the patient
to submit data to the service via the electronic device (e.g. a
mobile device which may have a built in blood glucose monitor or
heart rate monitor) either through wired of wireless
communication.
[0025] Historical health data may be received by the service that
is relevant to the provider and the provider's patients. This data
may be electronically transmitted by the provider and/or the
patient and received by the service at step 104. The data may be
electronically transmitted and received by the service at step 104
in any suitable manner. For example, the provider may access the
software application or secure server and send or drop electronic
data files via a network, e.g. the Internet so that the files may
be accessed by the service. In some examples, the provider may
allow the service limited access in compliance with any healthcare
privacy regulations and other applicable regulations, to any
electronic medical records, patient prescription records, referral
records, etc., and the service may electronically retrieve
healthcare data from such electronic records (e.g. automatically).
In other examples, patient data may be electronically transmitted
by a patient and may be electronically received by the service in
any suitable manner. The patient data may be actively submitted by
the patient via a software application and/or may be automatically
electronically retrieved by the service from an electronic device
of the patient (FIG. 2) that may measure patient health values,
such as heart rate, blood glucose, blood oxygen, blood pressure,
activity, stress, mood, and/or sleep either periodically or
continuously.
[0026] The historical data received at step 104 may include any
relevant historical data, including a clinical profile of the
patient such as diseases, significant medical events (e.g. heart
attack, stroke, head trauma, transplant), disease stage, lab
values, patient self-reported clinical, behavioral and
psycho-social data, patient's demographics, medical history,
provider characteristics such as age, years of clinical practice
experience, size of practice, specialty, demographics, context of a
patient's visit such as date, day, time, location, duration of
visit, and/or a decision which includes medication change,
psycho-therapy, dose change, lifestyle modification (diet,
exercise, weight loss), recommendation for lab test(s), education,
and may include the reasoning behind the provider's
decision(s).
[0027] The historical data received by the service at step 104 may
be stored in a database at step 106 such as a server, cloud, or any
other digital memory device. The data may be accessed at any time
by the service and may be displayed, printed, or updated in any
suitable manner. The stored data may be organized and accessed in
any suitable manner. In some examples, the data may be
electronically tagged with various identifiers, such as age,
gender, clinical condition, etc. In another example, metadata may
be extracted from the stored data (FIG. 3).
[0028] In addition, the data stored in the database at step 106 may
be electronically processed in any suitable manner. In step 108,
for example, various algorithms may be applied to the data to learn
from/be trained by analyzing the data. In some examples, machine
learning algorithms and/or other higher-level algorithms (e.g.
supervised and unsupervised learning algorithms) may be applied to
the data to learn and otherwise extract information from the data,
such as for use in learning provider decision-making patterns and
behaviors and/or patient behavioral patterns. Examples of such
machine learning algorithms may include artificial neural networks,
Bayesian statistics, case-based reason, decision trees, inductive
logic processing, Gaussian process regression, Gene expression
programming, Logistic model trees, stochastic modeling, statistical
modeling (e.g. Bayesian networks, Markov models, ANOVA, etc.),
and/or any other suitable algorithm or combinations of algorithms.
For example, at step 108, machine-learning algorithms may be
applied to the data to learn the characteristics of patients for
which the provider has prescribed or modified use of a drug,
provided a referral to another provider, recommended a lifestyle
change (e.g. exercise, diet, and/or stress management).
[0029] The machine learning algorithms applied at step 108 may
detect any patterns, idiosyncrasies, or any other significant
associations that may be used in generating a decision model that
mimics or attempts to understand the decision-making of the
provider and/or predicted behavior of the patient. In another
example, the machine-learning algorithm may identify a patient
cohort for whom components of a treatment plan may be effective,
ineffective, or partially effective, such as a cholesterol-lowering
drug that is ineffective for patients with neuropathy. In some
embodiments, any patterns identified in step 108 may be presented
to the provider to improve the provider's clinical knowledge. For
example, it may be determined at step 108 that 83% of the
provider's diabetes patients between ages 65-75 for whom the
provider prescribed dementia drug X suffered headaches, and only 3%
of the provider's patients adhered to a diet change. Based on these
patterns the provider may stop prescribing drug X to patients
between ages 65-75 and stop recommending a diet change to patients
ages 18-35. In another embodiments, the machine learning algorithm
applied at step 108 may detect patient compliance with the
provider's treatment plan, for example, it may be determined that
90% of the provider's patients over the age of 85 did not adhere to
taking dementia drug X.
[0030] The application of the one or more machine learning
algorithms at step 108 may be processed to generate clinical
decision models at step 110. The models may be based on any
patterns or other information learned by the machine learning
algorithms. The models may be generated using one or more
processors and may be tested with sample data that may be reviewed
and automatically validated. In some embodiments, existing models
may be imported from databases or libraries, processed, and applied
to the data processed at step 108. In some embodiments, at step
110, the service may send the provider a notification that it is
ready to provide clinical recommendations. The notification may be
sent when it is determined sufficient data has been collected to
provide an accurate recommendation. In some embodiments, the
notification may be sent after a day, a week, a month, three
months, or any other period of time. The notification may be in any
suitable form, e.g. an electronic message, alert, and/or phone
call.
[0031] The service may receive information in connection with a
clinical scenario at 112, for example, from the provider, in any
suitable manner (e.g. via a software application over the
Internet). In some embodiments, the clinical scenario may be
associated with an upcoming patient appointment, a current patient
appointment, or a past patient visit. The service may process the
information received in connection with the clinical scenario in
any suitable manner. The clinical scenario may be submitted to the
service directly by the provider or a proxy of the provider. For
example, a patient may visit a physician's office and provide a
nurse with information regarding the patient's reason for the
visit, (e.g. onset of frequent migraines), and the nurse may record
the patient's diagnostic information (e.g. weight, blood pressure,
blood glucose level, and heart rate), and submit a recommendation
request to the service on behalf of the physician.
[0032] Real-time data may be received at 118 after generating the
decision models 110 or any time during method 100. The real-time
data may include any relevant patient and/or provider information
that may be used to generate the decision model or to improve the
decision model. In some embodiments, real-time data may include
behavioral data, demographic data, and financial data. The
real-time data may be selectively collected or continuously
collected from the provider and patients. The real-time data also
may be obtained that is non-specific to the provider and/or the
patient, such as weather conditions, current events, date, and/or
season. This non-specific real-time data may be used to improve the
accuracy the recommendation, for example, if the real-time data
indicates that the temperatures for the last ten days where the
patient lives have been below -10 degrees Fahrenheit, the service
may not recommend that a patient start exercising outside as it may
be too cold to exercise outside. In some examples, if the service
is unable to complete a decision model, real-time data may be
requested to complete or improve the decision model.
[0033] In some examples, step 114 may include automatically or upon
provider selection, applying one or more of the decision models to
the clinical scenario received at step 112 and/or extracting
discrete data values from the clinical scenario and applying the
decision models to each data value separately, and then combining
the decision models. For example, the clinical scenario may include
a patient who is a 67-year old male smoker that has type-2
diabetes, and has previously suffered a stroke. The patient may
visit the provider complaining of shortness of breath. In addition,
the patient may be receptive to lifestyle changes and the provider
may indicate resistance to trying new drug therapies. One or more
models may be applied to each the clinical scenario data values
(e.g., patient age, diagnostic information, behavioral values,
provider characteristics). In addition, or alternatively, all of
the clinical scenario data values may be treated together and one
or more models may be applied to all or subgroups of the data
values. The results of applying the decision models may be further
processed to detect any inconsistencies and/or errors and may be
presented to the provider as a recommendation in any suitable
manner for evaluation. For example, the recommendation may include
a recommendation based on applying the machine learning data
algorithms at step 108 to learn the provider's decision-making
characteristics and application of the decision models. In
addition, the recommendations may include recommendations based on
other provider decision-making characteristics, recommendations
based on standard guidelines (e.g. according to the American
Diabetes Association, American Medical Association, etc.), and/or
any other sources. The service may provide a comparison of each of
the recommendations and also may suggest any changes in the
provider's decision-making to improve patient treatment, reduce
healthcare costs, etc. In some embodiments, the service may provide
a rationale for each recommendation.
[0034] At step 116, the service may receive electronic feedback on
the recommendation. The feedback may be in the form of an
evaluation by the provider and/or the patient on the
recommendation. In some examples, an evaluation form soliciting
feedback on the recommendation may be sent by the service for
completion by the provider and/or patient. The evaluation may
include an indication of whether or not the recommendation was
followed, a rating of the recommendation, an explanation of the why
the recommendation was followed or why it was not followed. In this
manner, the patient may receive a treatment plan that is tailored
to the patient and the provider may quickly and easily provide a
treatment plan that is in line with provider's standard of care and
philosophy.
[0035] The provider's decision may be recorded at step 120 and may
be stored as historical data for use in subsequent recommendations.
At step 122, the provider's recommendation may be presented to the
user in any suitable manner. In some embodiments the results of the
provider's decision and/or other provider decision's may be saved
and exchanged (e.g. sold and/or exchanged for other data) to a
third party without including any patient identifying data. For
example, a pharmaceutical company may purchase data from the
service on provider decisions in order to improve marketing and
research and development efforts. In another example, health
insurance companies may be interested in the provider decision data
to improve healthcare services and reduce costs. The provider
decision data also may be provided to improve standard treatment
guidelines and evaluate provider adherence to standard guidelines
and recommendations.
[0036] FIG. 2 shows a flow diagram of an exemplary method 200 for
data collection including automatic data collection. The method 200
may be used to gather and transmit health data from a provider
and/or patient to a service, as shown in step 104 of FIG. 1.
Historical health data may be retrieved that is relevant to a
provider and the provider's patients (202). At step 204, historical
health data that is relevant to the provider may be gathered. Such
data may include various provider characteristics including, but
not limited to, the provider's type of practice, specialty, age,
years of experience, size of practice, location of practice, access
to referrals, gender, education, type of training, access to
treatments, and/or expertise. Historical health data that may be
relevant to a patient also may be gathered at step 206. Such data
may be retrieved or extracted by parsing patient electronic medical
records using a processor. Such parsing may include parsing of
clinical data and/or psychological data. A patient's personal
information (e.g. age, gender, and education), social information,
and or lifestyle characteristics (e.g. diet, and exercise regimen)
also may be retrieved. The historical data gathered at step 204 and
step 206 may be organized in any suitable manner at step 208 may be
stored in a database at step 210.
[0037] FIG. 3 is a flow diagram of an exemplary method 300 for
extracting and identifying metadata. In some examples, the metadata
is extracted from the collected historical data and/or real-time
data in order to rate the value of the data. The metadata may be
used in step 108 of applying machine-learning algorithms. As shown
in FIG. 3, metadata may be extracted in various manners. For
example, descriptive statistics 302 may be used, which may include
the mean, standard deviation, and/or the variance. Another type of
metadata extraction method may include determining the availability
of the historical data at step 304. For example, it may be
determined that a patient's self-monitoring blood glucose (SMBG)
levels are only available on a weekly basis; whereas a patient's
continuous glucose data is available (CGM) only on Thursdays. The
metadata based on the type of data may be extracted at step 306,
such as location specific models, and weather specific models. In
addition, metadata based on the category type may be determined at
step 308, such as clinical, behavioral, and/or personal. For
example, the location where a patient's blood glucose measurement
was taken may be extracted and this category of metadata (location)
may be used in the decision-making model. In this example,
different decision models may be used to process the measurement if
the measurement was taken at the patient's home versus if the
measurement was taken was at a restaurant. Based on the appropriate
data category (such as a patient's location) certain
decision-support/recommendation may be useful. Hence an appropriate
model for such a decision-making may be selected.
[0038] The source of the data also may be extracted at step 310 and
the relationship/influence of the source may be determined. For
example, it may be determined that the source of a first blood
glucose level measurement was a highly accurate hospital device,
and the source of a second blood glucose level measurement was a
less accurate patient device, and therefore, the first measurement
may be designated as having a greater value/be more reliable than
the second measurement.
[0039] The type of metadata may be identified at step 312 in any
suitable manner, such as by parsing the metadata, and/or a rules
engine to the metadata. The parsing/rules engine may use
appropriate algorithms, such as logic based algorithms, to match
data against a reference knowledge base to identify the category of
the data. For example, if the data is latitude and longitude
coordinates, the parsing/rules engine may be used to match the data
against a category called `location`. In another example, if the
data is had a burger and fries at noon, the parsing/rules engine
may be used to match the data against a category called `diet`
and/or a category called `time`.
[0040] FIG. 4 is a flow diagram of an exemplary method 400 for
selecting and applying algorithms to data such as historical data,
metadata, and/or real-time data. The method 400 may be used in any
suitable method, for example, method 100. As shown in FIG. 4,
metadata type may be discovered at step 402 in any suitable manner,
for example, using the method 300 shown in FIG. 3. Processing rules
may be imported from databases and/or libraries at step 404 in any
suitable manner. For example, logic processing rules (414), which
may include simple logic, algorithmic logic, machine learning
models, and/or mathematical models, may be imported. At step 406,
the applicable processing rules for data conversion based on the
discovered metadata type may be determined. The data may be
processed at step 408. Based on the processing rules, one or more
models may be imported from the logic library at step 410. The
logic library 416 may include various models, such as
category/response models, and/or stochastic models. One or more
models may be chose for application to the processed data at step
412 and model combinator rules may be imported from a database 420.
For example, the database may include model combinator rules 418,
which may include secondary sources and data on multiple diseases.
The models may be chosen based on the model combinator 422 rules
and a recommendation maybe generated from the data 424.
[0041] FIG. 5 is a flow diagram of an exemplary method 500 for
evaluating and modifying an automatic recommendation. The method
500 may be used with any suitable method, for example, with method
100. In method 500, a provider may interact with a computer
software application (502) to evaluate and provide electronic
feedback on a recommended presented to the provider by the service
at step 504. The recommendation may include a rationale for the
recommendation. The provider may provider corrective adjustments of
the recommendation and/or the rationale at step 508. For example,
the recommendation provided to the provider at step 504 may be that
the patient have hip surgery and this may be based on rationale
that the patient is not a good candidate for pain medication due to
a severe allergic reaction to the medication. In this example, the
provider may provide corrective adjustments to the rationale, such
as providing that the patient should have hip surgery because the
amount of pain the patient is suffering cannot be managed by drugs
alone. In some aspects, the provider may be presented with a course
of action based on an external model that is not based on
processing of the provider healthcare data at step 506. For
example, the service may recommend that the provider prescribe a
new cocktail drug therapy that a recent study showed to be
effective in 90% of all patients. At step 510, the provider
decision and/or corrective adjustments may be stored in memory.
[0042] FIG. 6 is a flow diagram of an exemplary method 600 for
automatically electronically collecting data in real-time. The
method may include health data received in real-time from the
provider 602. For example, provider prescription data 604, which
may include newly prescribed, changed medication, and/or halted
prescription data. The real-time health data also may include data
regarding the provider rationale (606) for making his/her decision,
such as the provider's rationale for prescribing the medication,
the provider's perception of the medication, the provider's
perception of the patient's lifestyle, the provider's perception of
the patient's lifestyle, the provider's perception the patient's
adherence to the prescription, the provider's perception of the
patient's education or understanding of the prescription, the
provider's perception of the patient's demographics. At the same
time or any other time, real-time health data from the patient may
be received at step 610. For example, updates of medical records
(612) (clinical data and prescription data) and patient lifestyle
information 614 from various electronic monitoring devices, and/or
the patient's psychosocial well-being data (616) such as the
patient's outlook, feelings, and/or financial data. In addition,
information regarding the provider patient interaction setting 608
maybe received (e.g. hospital setting or at home setting) The
real-time data may be inputted and/or automatically sent via a
software application via the Internet 618 and the data may be
stored in digital memory 620.
[0043] FIG. 7A is a flow diagram of an exemplary method 700 for
electronically receiving patient evaluations of decision models.
The method 700 may be used in any suitable manner, for example,
with method 100 for automatic clinical decision-making. Method 700
may be used to improve the breadth, customization, and significance
of decision models, for example, the decision models generated in
method 100.
[0044] As shown in FIG. 7A, a patient evaluation of one or more
decision models may be received at step 702. The evaluation may be
received from a patient, such as a self-help patient by the patient
interacting with a computer software application presenting
clinical decision models at step 704. For example in step 706, the
patient may be presented with likely courses of action and a
rationale for each action. Examples of such presentations may
include a medication course of action and rationale for why the
medication was recommended, a lifestyle course of action and
rationale for why it was recommended, and an education course of
action and rationale for why it was recommended. The self-help
patient may then make a selection at step 708 from one of the
recommendations. The selection may be electronically stored in
memory at step 712 and real-time data may be received from the
self-help patient at step 710. The real-time data and stored
decision may be processed, for example, as shown in method 100, to
improve the models and model selections. In some embodiments, a
treatment plan may be generated for the self-help patient at step
714 for on-going heath-management.
[0045] FIG. 7B is a flow a flow diagram of an exemplary method 750
for electronically presenting clinical decision model to a provider
and a patient. As shown in FIG. 7B, a clinical decision model may
be generated at step 754 in any suitable manner, such as in the
manner described in step 110. The provider may be presented with a
clinical scenario at step 756 (e.g. a patient with high
cholesterol). The provider may communicate the scenario, such as a
clinical scenario to the service at step 758. The provider may
receive a recommendation from the service at step 760 along with a
rationale for the recommendation. The recommendation may be
generated in any suitable manner, such as in the manner described
in step 114. The provider may evaluate the recommendations at 762
and send the evaluation to the service.
[0046] In addition, or alternatively, a self-help patient may be
presented with a clinical scenario or symptoms (e.g., a diabetes
patient may have symptoms of fatigue and headaches) and may
communicate such symptoms to the service. The self-help patient may
receive a recommendation and rationales for the recommendations
from the service for evaluation. The patient may select one of the
recommendations and may provide an evaluation of the recommendation
at step 766.
Example 1
[0047] An internal medicine physician may register with a web-based
provider of clinical recommendations. During registration, the
physician may provide her personal information, such as:
TABLE-US-00001 Age: 43 No. of patients: 150 Ages: 18-35: 40 36-50:
50 51-75: 40 75+: 20 Gender: Female Specialized Training:
Fellowship in endocrinology; acupuncture training Years of
Practice: 18 Location: New York City Practice type: Academic
Hospital
The service provider may store this data and continuously receive
physician data and the physician's patient's data over a period of
time, thereby collecting and storing historical data on the
provider's practice. The historical data may be continuously
processed using algorithms, such as machine learning algorithms, to
determine any patterns. The service may notify the provider that
she has prescribed antibiotics to 40% of her patient's in the last
week. This may indicate to the provider that there is a bacterial
infection outbreak in her patient population and that she should
recommend all her patients to take preventative measures to avoid
being infected. The decision models may be generated based on the
processed data and real-time data may be continuously received
(e.g. the date, temperature, and physician workload). The service
may indicate to the physician that it has obtained a sufficient
amount of historical data to provide a clinical recommendation by
sending her an email notification. The physician may then decide to
receive a recommendation from the service and submit a clinical
scenario to the service of a patient--
Patient A. Smith
Age: 57
Height: 5'10''
[0048] Weight: 200 pounds Random Blood glucose levels: High
Blood Pressure: High
[0049] The service may retrieve historical data on the patient
indicating that he has a family history of diabetes and heart
disease, is taking cholesterol medication, suffered a stroke 4
years ago, has a high-stress lifestyle, and eats cake the first
Friday of every month. The service also may receive real-time data
on the patient indicating that the patient exercises regularly,
eats a healthy diet, but has minimal social interaction and
receives less than five hours of sleep every night, and has been
late in making his credit card payments three months in a row. The
service also may identify patterns in the provider's historical
data indicating that she rarely prescribes blood pressure
medication and often instructs patients in the patient's age range
to change their diet and exercise. Data also may be received from
external sources that indicates that patients who are 50-60 and who
live in New York City have a 90% adherence rate to blood pressure
lowering medication. The service also may receive real-time data
from the provider indicating that she has recently authored a
research article on the benefits of avoiding carbohydrates for
diabetes patients. The service may process the historical and
real-time data and provide the physician a recommendation and its
rationale based on what is determined to be the physician's likely
recommendation:
Recommendation:
[0050] Prescribe blood pressure medication and diabetes medication
and modify diet to reduce carbohydrate intake.
Rationale:
[0051] The patient has a family history of heart disease and
diabetes and already exercises and has a healthy diet, therefore
lifestyle change may not be effective. In addition, the service may
provide a recommendation based on the American Medical Association,
and a recommendation based on all other data sources. The physician
may select the recommendation and/or provide feedback on the
recommendations that may be saved by the service as historical
data.
Example 2
[0052] The physician of Example 1 may receive a patient report on
the patient of Example 1 prior to the patient's next visit. Prior
to the visit the service may provide a report to the physician and
a recommendation based on historical and real-time data:
Recommendation:
[0053] Reduce strength of prescription of medication, prescribe
antibiotics, and muscle relaxers.
Rationale:
[0054] The patient's blood glucose and blood pressure levels have
decreased. The patient changed his diet, increased his exercise
regime, and has moved to the beach. In addition, the patient has
been coughing, and sneezing and has back pain. In addition, the
service may provide a recommendation based on the American Medical
Association, and a recommendation based on all other data sources.
The physician may decide to follow the recommendation in part, but
halt the medication and provide feedback on the recommendations
that may be saved by the service as historical data.
[0055] FIG. 8 is a schematic diagram of an arrangement of a system
800 by which a clinical decision may be automatically generated,
according to an exemplary embodiment of the present disclosure. For
example, the system 800 may access decision models stored on a
decision model database 870 via a network 805, such as the
Internet. The retrieved decision models may be used for display
and/or processing by one or more provider and/or patient devices
810, such as a mobile device 815 (e.g., mobile phone, personal
digital assistant, tablet computer), tablet device 820, a computer
(laptop, desktop) 425, kiosk 830 (e.g. kiosk at pharmacy, clinic or
hospital having medical and/or prescription information), and/or
any device connected to a network 805, such as the Internet,
according to an exemplary embodiment of the present disclosure.
[0056] In the example shown in FIG. 8, mobile electronic device 815
may be a smartphone, a personal digital assistant ("PDA"), medical
diagnostic device, or other type of mobile computing device, such
as a device having a touchscreen display. Mobile device 815, tablet
820, and computer 825 each may be equipped with or include, for
example, a GPS receiver for obtaining and reporting location
information, e.g., GPS data, via network 805 to and from any of
servers 835 and/or one or more GPS satellites 855.
[0057] However, it should be noted that each of user devices 810,
including mobile device 815, tablet device 820, computer 825,
and/or kiosk 830, may be implemented using any type of electronic
device configured to send and receive data (e.g. clinical
information) to and from a system of servers 835 over network 805.
The user input device(s) may include any type or combination of
input/output devices, such as a display monitor, touchpad,
touchscreen, microphone, camera, keyboard, and/or mouse.
[0058] The various user devices 810 may also communicate with each
other by any suitable means (e.g., via Wi-Fi, radio frequency (RF),
infrared (IR), Bluetooth, Near Field Communication, or any other
suitable means) to send and receive location and other information.
For example, a mobile device 815 may communicate with tablet device
820 or kiosk 830.
[0059] The user device 810 may receive information, such clinical
data via the network 805 from the system of servers 835, having one
or more servers such as clinical data servers 840, algorithm
servers 845, user interface servers 850, and/or any other suitable
servers. Each server may access the decision model database 870 to
retrieve decision models. Each server may include memory, a
processor, and/or a database. For example, the clinical data server
840 may have a processor configured to retrieve clinical data from
a provider's database and/or a patient's electronic medical record.
The algorithm server 845 may have a database that includes various
algorithms, and a processor configured to process the clinical
data. The user interface server 850 may be configured to receive
and process user input, such as clinical decision preferences. The
satellite 855 may be configured to send and receive information to
the server system 835 and user devices 810.
[0060] The clinical data server 840 may receive clinical data, such
as data regarding the provider and the patient from the user device
810 via the network 805 or indirectly via the user interface server
850. The clinical data server 840 may save the information in
memory, such as a computer readable memory.
[0061] The clinical data server 840 also may be in communication
with one or more other servers, such as the algorithm server 845
and/or external servers such as servers of providers 860 and/or
patients 865 (e.g. medical records servers). The servers may
include data about provider preferences, and/or patient health
history. In addition, the clinical data server 860 may include data
from other providers and/or patients. The algorithm server 845 may
include machine learning, and/or other suitable algorithms. The
algorithm server 845 may be in communication with other external
servers and may be updated as desired. For example, the algorithm
server 845 may be updated with new algorithms, more powerful
programming, and/or more data. The clinical data server 840 and/or
the algorithm server 845 may process the information and transmit
data to the model server 870 for processing.
[0062] Each server in the system of servers 835, including clinical
data server 840, algorithm server 845, and UI server 850 may each
represent any of various types of servers including, but not
limited to a web server, an application server, a proxy server, a
network server, or a server farm. Each server in the system of
servers 835 may be implemented using, for example, any
general-purpose computer capable of serving data to other computing
devices including, but not limited to, user devices 810 or any
other computing device (not shown) via network 805. Such a
general-purpose computer can include, but is not limited to, a
server device having a processor and memory for executing and
storing instructions. The memory may include any type of random
access memory (RAM) or read-only memory (ROM) embodied in a
physical storage medium, such as magnetic storage including floppy
disk, hard disk, or magnetic tape; semiconductor storage such as
solid-state disk (SSD) or flash memory; optical disc storage; or
magneto-optical disc storage. Software may include one or more
applications and an operating system. Hardware can include, but is
not limited to, a processor, memory, and graphical user interface
display. Each server also may have multiple processors and multiple
shared or separate memory components that are configured to
function together within, for example, a clustered computing
environment or server farm.
[0063] FIG. 9 is a simplified functional block diagram of a
computer that may be configured as a host server, for example, to
function as healthcare provider decision-making server. FIG. 9
illustrates a network or host computer platform 900, as may
typically be used to implement a server like the clinical decision
model server 870. It is believed that those skilled in the art are
familiar with the structure, programming, and general operation of
such computer equipment and as a result, the drawings should be
self-explanatory.
[0064] A platform for a server 900 or the like, for example, may
include a data communication interface for packet data
communication 960. The platform also may include a central
processing unit (CPU) 920, in the form of one or more processors,
for executing program instructions. The platform typically includes
an internal communication bus 910, program storage, and data
storage for various data files to be processed and/or communicated
by the platform such as ROM 930 and RAM 940 or the like. The
hardware elements, operating systems, and programming languages of
such equipment are conventional in nature, and it is presumed that
those skilled in the art are adequately familiar therewith. The
server 900 also may include input and output ports 950 to connect
with input and output devices such as keyboards, mice,
touchscreens, monitors, displays, etc., and communication ports
960. Of course, the various server functions may be implemented in
a distributed fashion on a number of similar platforms to
distribute the processing load. Alternatively, the servers may be
implemented by appropriate programming of one computer hardware
platform.
[0065] Program aspects of the technology may be thought of as
"products" or "articles of manufacture" typically in the form of
executable code and/or associated data that is carried on or
embodied in a type of machine-readable medium. "Storage" type media
include any or all of the tangible memory of the computers,
processors or the like, or associated modules thereof, such as
various semiconductor memories, tape drives, disk drives and the
like, which may provide non-transitory storage at any time for the
software programming. All or portions of the software may at times
be communicated through the Internet or various other
telecommunication networks. Such communications, for example, may
enable loading of the software from one computer or processor into
another, for example, from a management server or host computer of
the mobile communication network into the computer platform of a
server and/or from a server to the mobile device. Thus, another
type of media that may bear the software elements includes optical,
electrical and electromagnetic waves, such as used across physical
interfaces between local devices, through wired and optical
landline networks and over various air-links. The physical elements
that carry such waves, such as wired or wireless links, optical
links, or the like, also may be considered as media bearing the
software. As used herein, unless restricted to non-transitory,
tangible "storage" media, terms such as computer or machine
"readable medium" refer to any medium that participates in
providing instructions to a processor for execution.
[0066] The many features and advantages of the disclosure are
apparent from the detailed specification, and thus, it is intended
by the appended claims to cover all such features and advantages of
the disclosure which fall within the true spirit and scope of the
disclosure. Further, since numerous modifications and variations
will readily occur to those skilled in the art, it is not desired
to limit the disclosure to the exact construction and operation
illustrated and described, and accordingly.
[0067] Other embodiments of the disclosure will be apparent to
those skilled in the art from consideration of the specification
and practice of the invention disclosed herein. It is intended that
the specification and examples be considered as exemplary only,
with a true scope and spirit of the invention being indicated by
the following claims.
* * * * *