USRE49853E1 - System and method for timely notification of treatment - Google Patents
System and method for timely notification of treatment Download PDFInfo
- Publication number
- USRE49853E1 USRE49853E1 US17/892,830 US202217892830A USRE49853E US RE49853 E1 USRE49853 E1 US RE49853E1 US 202217892830 A US202217892830 A US 202217892830A US RE49853 E USRE49853 E US RE49853E
- Authority
- US
- United States
- Prior art keywords
- notification
- notifications
- received
- treatment
- patient
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active, expires
Links
- 238000011282 treatment Methods 0.000 title claims abstract description 244
- 238000000034 method Methods 0.000 title claims abstract description 39
- 230000006870 function Effects 0.000 claims description 14
- 230000004083 survival effect Effects 0.000 claims description 7
- 230000004931 aggregating effect Effects 0.000 claims description 3
- 230000003467 diminishing effect Effects 0.000 claims description 3
- 238000005457 optimization Methods 0.000 description 13
- 239000003814 drug Substances 0.000 description 12
- 229940079593 drug Drugs 0.000 description 12
- 238000012545 processing Methods 0.000 description 12
- 238000004590 computer program Methods 0.000 description 10
- 230000004044 response Effects 0.000 description 8
- 238000013500 data storage Methods 0.000 description 7
- 238000004891 communication Methods 0.000 description 6
- 230000000694 effects Effects 0.000 description 5
- 238000010801 machine learning Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 5
- 230000004075 alteration Effects 0.000 description 3
- 230000007423 decrease Effects 0.000 description 3
- 238000003745 diagnosis Methods 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 230000001105 regulatory effect Effects 0.000 description 3
- 206010020772 Hypertension Diseases 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 230000001154 acute effect Effects 0.000 description 2
- 238000013503 de-identification Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000036541 health Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 239000000825 pharmaceutical preparation Substances 0.000 description 2
- 229940127557 pharmaceutical product Drugs 0.000 description 2
- 239000000955 prescription drug Substances 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 238000013515 script Methods 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000012517 data analytics Methods 0.000 description 1
- 238000001647 drug administration Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000001953 sensory effect Effects 0.000 description 1
- 230000007480 spreading Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 239000000758 substrate Substances 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000011269 treatment regimen Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
- G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N20/00—Machine learning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N20/00—Machine learning
- G06N20/20—Ensemble learning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/01—Dynamic search techniques; Heuristics; Dynamic trees; Branch-and-bound
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
- G16H50/70—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for mining of medical data, e.g. analysing previous cases of other patients
Definitions
- Medical patients may receive various treatments.
- a medical patient may be prescribed medication by a healthcare professional.
- some implementations provide a computer-implemented method that includes: receiving, from one or more database systems each comprising non-volatile data storage devices, de-identified longitudinal medical records, each de-identified longitudinal medical record representing a record of a different anonymized patient and encoding information identifying a treatment received by the anonymized patient, information identifying a time the treatment was received, and an identifier that uniquely distinguishes the anonymized patient from other anonymized patients, the records devoid of information identifying the patients; receiving, from one or more database systems each comprising non-volatile data storage devices, notification data including notification records, each notification record encoding information identifying a type of notification provided, information identifying a time the notification was received, and information referring to a recipient that received the notification; identifying, from the de-identified longitudinal medical records, anonymized patients that received the treatment; identifying, from the notification data, notifications for the treatment that were received by the recipients; determining, for each of the identified notifications that were received by the recipients, whether the recipient is an anonymized patient
- Determining, for each of the identified notifications for the treatment determined to be received by a recipient that is an anonymized patient identified as having received the treatment, a time relationship between the time when the treatment was received by the anonymized patient and the time that the notification was received by the recipient that is the anonymized patient may include determining a time when a treatment was received by a particular anonymized patient, determining a time when a notification for the treatment was received by a particular recipient corresponding to the particular anonymized patient, and determining a time relationship that represents a time length between the time when the treatment was received by the particular anonymized patient and the time when the notification for the treatment was received by the particular recipient corresponding to the particular anonymized patient.
- Determining, for each of the anonymized patients that received the treatment, associations between one or more time relationships for notifications received by the patient may include determining for a particular patient that a first notification for the treatment was received by the particular patient and a second notification for the treatment was received by the particular patient.
- Generating, using machine learning, an impact model representing an impact of a notification on a treatment being received based on the determined associations between the time relationships may include generating the impact model using a random survival forest analysis with the determined associations between the time relationships.
- the impact model may represent an impact of a notification on a treatment being received exponentially decayed from time when the notification was initially provided to a patient to a time the treatment was received by the patient.
- the method may further include determining, for each of the notifications, an impact of the notification on a treatment being received based on the impact model and the determined time relationships, determining a forecast model based on the impacts determined for the notifications, where the forecast model stores, for each type of notification, a notification type label that is indicative of a relationship between a number of patients receiving a treatment and a number of recipients receiving notifications for the treatment and scheduling notifications based on the forecast model. Implementations may include one or more of the following features.
- Determining a forecast model based on the impacts determined for the notifications, where the forecast model stores, for each type of notification, a notification type label that is indicative of a relationship between a number of a patients receiving a treatment and a number of recipients receiving notifications for the treatment may include determining, for each type of notification, a curve fitting a number of patients that previously received the treatment with a number of notifications previously provided to notification recipients.
- Determining a forecast model based on the impacts determined for the notifications, where the forecast model stores, for each type of notification, a notification type label that is indicative of a relationship between a number of a patients receiving a treatment and a number of recipients receiving notifications for the treatment may include determining the forecast model as a sigmoid function considering the diminishing effect of number of notifications received by recipients on number of patients that receive a treatment.
- Determining a forecast model based on the impacts determined for the notifications, where the forecast model stores, for each type of notification, a notification type label that is indicative of a relationship between a number of a patients receiving a treatment and a number of recipients receiving notifications for the treatment may include determining an initial forecast model for model patients based on the impacts determined for the notifications and projecting the initial forecast model to potential patients.
- An anonymized patient may be a patient for which the patient's identity cannot be determined but is distinguishable from other anonymized patients.
- some implementations provide a computer system comprising one or more processors, configured to perform the operations of: receiving, from one or more database systems each comprising non-volatile data storage devices, de-identified longitudinal medical records, each de-identified longitudinal medical record representing a record of a different anonymized patient and encoding information identifying a treatment received by the anonymized patient, information identifying a time the treatment was received, and an identifier that uniquely distinguishes the anonymized patient from other anonymized patients, the records devoid of information identifying the patients; receiving, from one or more database systems each comprising non-volatile data storage devices, notification data including notification records, each notification record encoding information identifying a type of notification provided, information identifying a time the notification was received, and information referring to a recipient that received the notification; identifying, from the de-identified longitudinal medical records, anonymized patients that received the treatment; identifying, from the notification data, notifications for the treatment that were received by the recipients; determining, for each of the identified notifications that were received by the recipients,
- some implementations provide a computer-readable medium, comprising software instructions, which when executed by a processor of a computer, causes the computer to perform the operations of: receiving, from one or more database systems each comprising non-volatile data storage devices, de-identified longitudinal medical records, each de-identified longitudinal medical record representing a record of a different anonymized patient and encoding information identifying a treatment received by the anonymized patient, information identifying a time the treatment was received, and an identifier that uniquely distinguishes the anonymized patient from other anonymized patients, the records devoid of information identifying the patients; receiving, from one or more database systems each comprising non-volatile data storage devices, notification data including notification records, each notification record encoding information identifying a type of notification provided, information identifying a time the notification was received, and information referring to a recipient that received the notification; identifying, from the de-identified longitudinal medical records, anonymized patients that received the treatment; identifying, from the notification data, notifications for the treatment that were received by the recipients;
- FIG. 1 A illustrates an example of a system for deriving de-identified longitudinal medical data from various data supplier sites.
- FIG. 1 B illustrates an example of a system for aggregating medical data from data servers at medical service providers longitudinally tracking the treatment pattern of human patients.
- FIG. 1 C illustrates an example of linking medical data of the patients.
- FIG. 2 illustrates an example of a block diagram of a system for providing timely notification of treatments.
- FIG. 3 illustrates an example of a flow chart for providing timely notifications of treatments.
- FIG. 4 illustrates an example timeline of notifications being provided and a treatment being received.
- FIG. 5 illustrates an example graph of an impact of a notification with a time relationship between a notification and treatment.
- FIG. 6 illustrates a timeline of notifications and impacts.
- FIG. 7 illustrates an example graph output of a forecast model.
- FIG. 8 illustrates an example user interface for receiving notification constraints for determining a plan for timely providing notifications.
- FIGS. 9 and 10 illustrate example plans for timely providing notifications.
- the problem is particularly acute where longitudinal data associated with a de-identified label is reconciled between two different data sources with two different time sequences that describe different and sometimes unrelated activity.
- the data In order to perform the requisite correlation between the two different data sources, the data must be formatted in a manner that facilitates ready comparison of two different data points from each of the data sources.
- an organization such as a Patient Safety Organization (PSO) can act in reliance upon the identified correlations and work to address the correlations and derived identifications.
- PSO Patient Safety Organization
- one such correlation may be associated with a breach in the desired activity (e.g., a standard of care).
- a medical administrator then may work to identify these deviations as fault or alarm conditions and take corrective action in real-time.
- the deviations need not formally be relative to some regulatory standard (e.g., the standard of care). Instead, the deviation may exist relative to desired behavior (e.g., an internal hospital policy).
- this disclosure generally describes a system and a method for timely providing notifications of treatments to a patient population, and the reaction to notifications.
- this disclosure generally describes a system and a method for timely providing notifications of treatments to a patient population, and the reaction to notifications.
- treatments generally do not immediately follow notifications of treatments. For example, a patient may not get a prescription without a doctor, the doctor may recommend other lifestyle changes, other treatments, order tests, etc. before prescribing the patient a drug, the patient then may need to go to the pharmacy to get the prescribed drug.
- treatment may refer to medical events such as seeing a doctor, receiving a prescription, receiving prescribed drugs from a pharmacy or undergoing an operation.
- de-identified longitudinal medical records may be collected from data servers at medical service providers that record filled prescription information, medical operations, doctor visits, or other medical events for patients.
- the information may generally include records of different anonymized patients, where each record identifies one or more treatments received by the anonymized patient, the one or more times the treatments were received by the anonymized patient, and an identifier that uniquely distinguishes the anonymized patient from other anonymized patients.
- the identifier may refer to a de-identified patient, which may also be referred to as an anonymized patient.
- the de-identification means no identity information, such as name, address, birth date, or social security information, is available in the recorded information. Instead, each patient is referenced by an anonymous tag that is specific to the patient.
- an anonymized patient may be a patient for which the patient's identity cannot be determined but is distinguishable from other anonymized patients.
- the anonymous tag is doubly encrypted using a key specific to a data supplier (such as a data server at a pharmacy) and another key specific to a longitudinal database.
- notification data may be collected from data servers of notification providers that record notifications provided to recipients.
- a notification may include text, one or more images, one or more videos, or one or more audio identifying a treatment.
- the notifications may be placed in various locations, e.g., on websites or in mobile applications. For example, a first type of notification may be provided with an image on a first website, and a second type of notification may be provided with text on a second website.
- the notification data may include notification records that each identify a type of notification provided, a time the notification was received, and the recipient of the notification.
- relationships between the patients of the medical data and recipients of the notification data may be identified and time relationships between when patients received a treatment and when the patients received a notification regarding the treatment may be determined. The time relationships may then be used to determine impacts of the notifications on the patients receiving the treatment.
- the impacts of the notifications may be used to forecast a future effect of various types of notification, and a plan for providing notifications in the feature may be determined based on the forecast.
- FIG. 1 A illustrates an example system 100 for obtaining de-identified longitudinal medical records.
- the medical records may include treatment data in the form of prescription data.
- the prescription may include a pharmaceutical product such as a prescription drug approved by a regulatory agency, such as the Federal Drug Administration (FDA), the European Medicines Agency (EMA), the Medicines and Healthcare products Regulatory Agency (MHRA).
- the pharmaceutical product can also include approved medical devices.
- the prescriptions may be filled at multiple sites, such as pharmacies 104 A to 104 G. These sites can cover a geographic region, for example, a region in a particular country. These sites may also be located globally, for example, the North American continent, or the European Union.
- Prescription data for each participant patient may be collected from each pharmacy store.
- a pharmacy database may collect prescription data from all pharmacy stores on a daily basis.
- the pharmacy database includes non-volatile data storage devices.
- Each pharmacy store may house its own data server in communication with the pharmacy database to transfer prescription data on a daily basis.
- the prescription data records the information about a particular prescription when the prescription was filled.
- the prescription data for each participant patient, as recorded at the pharmacy store at the time of filling is de-identified such that the data does not include information capable of identifying the particular participant patient. Examples of such identifying information include: patient's name, patient's insurance identification number, patient's Medicare/Medicaid identification number, patient's social security number, patient driver's license number, etc.
- such identifying information may be converted by a one-way hash-function to generate an alpha-numerical string.
- the alpha-numerical string conceals the identity of the individual participant patient, thereby maintaining confidentiality of the data as the data is being reported, for example, daily from the sites 104 A to 104 G to the central server 102 .
- data corresponding to the same participant patient may be linked by virtue of the matching alpha-numerical string.
- data for the same participant patient may be longitudinally tracked for each individual, without compromising confidentiality of the individual patients, even though the patient can fill the prescription at various stores and the patient can receive a prescription for a healthcare product from various healthcare professionals.
- the de-identified longitudinal medical records may include other forms of data.
- the de-identified longitudinal medical records may include data describing operations performed on a patient and when the operations were performed, when a patient made a visit to a particular doctor, when a doctor performed a diagnosis on a patient, and other events.
- the sites may be medical service providers that include pharmacy stores and other types of medical service providers, e.g., doctor's offices or hospitals.
- FIG. 1 B illustrates an example work flow 110 for collecting data of patient recipients from data servers at various medical service providers and longitudinally tracking the medical record of each individual patient recipient over time.
- Data 114 A- 114 G may correspond to prescription data reported from each pharmacy store.
- data 114 - 114 G may be reported from data servers at each pharmacy store on a daily basis, for example, at the end of business data local time.
- Data 114 A- 114 G remain de-identified to preserve confidentiality, as disclosed herein.
- each pharmacy store may employ the same one-way hashing function to anonymize data records of each patient.
- reported prescription data 114 A- 114 G include the same de-anonymized key for prescription records from the same patient, even if the patient may move to another pharmacy store, another healthcare professional, or another healthcare provider (e.g., health insurance carrier, pharmacy insurance carrier).
- the central server 102 may match prescription data records from the same patient recipient to update database 112 , which contains data records reported earlier for the same patient recipient.
- the de-identified data may be further encrypted before the data is reported to central server 102 to update database 112 .
- data 114 A- 114 G may be encrypted using a symmetric encryption key specific to each pharmacy store.
- the symmetric encryption key may only be known to the pharmacy store and central server 102 .
- a public-key infrastructure PKI
- the central server 102 and pharmacies 104 A- 104 G may exchange messages using the PKI to establish an agreed-on symmetric key.
- the data 114 A- 114 G may correspond to other data besides prescription data.
- the data 114 A- 114 G may describe operations performed on a patient and when the operations were performed, when a patient made a visit to a particular doctor, when a doctor performed a diagnosis on a patient, and other events received from medical service providers that include pharmacy stores and other types of medical service providers, e.g., doctor's offices or hospitals.
- FIG. 1 C illustrates an example linkage of daily reported medical data for the patient recipients based on matching anonymized tags.
- the daily received prescription data for example, data 114 B from pharmacy 104 B
- the de-identification process allows such prescription data to remain anonymous.
- the de-identified data from the same patient may be linked at central server 102 .
- data are received on different days for the patient recipients. For example, on time point N, de-identified prescription data 121 A to 121 C may be received. Likewise, on time point N+1, de-identified prescription data 122 A to 122 C are received. Similarly, on time point N+2, de-identified data 123 A to 123 C may be received.
- de-identified prescription data correspond to different patient recipients.
- the de-identified prescription data from each patient recipient may be linked and hence the prescription activity of a particular patient recipient can be longitudinally tracked.
- the matching tags may include graphic representations as well as alpha-numerical strings. The graphic representations are also de-identified to remove personally identifiable information of the participant patient.
- the alpha-numerical strings or graphical representations may be tags to the actual prescription data record, which may be referred to as part of the metadata. In other instances, the alpha-numerical strings or graphical representations may be embedded to the actual prescription data record itself.
- the alpha-numerical strings or graphical representations may be part of the metadata and embedded in the actual prescription data record.
- the implementations of both the tag and the embedding may further deter alterations or modifications of the data records being reported from each participant site.
- database 112 may be updated.
- the updated database may allow a variety of data analytics to be generated, revealing the interesting insights of prescription usage pattern for each patient recipient as well as the statistical prescription pattern of each healthcare professional, as discussed below.
- the de-identified prescription data 121 A to 121 C may correspond to other de-identified data besides prescription data.
- the de-identified data may describe operations performed on a patient and when the operations were performed, when a patient made a visit to a particular doctor, when a doctor performed a diagnosis on a patient, and other events.
- FIG. 2 illustrates an example of a block diagram of a system 200 for providing timely notification of treatments.
- the system 200 may include a relationship identifier 230 that identifies relationships between de-identified longitudinal medical records and notification data, a time decay model generator 240 that determines an impact model based on the relationships, a treatment impact attribution engine 250 that determines an impact of notifications on a treatment being received, a treatment trend prediction engine 260 that determines an initial forecast for the anonymized patients based on the determined impacts, a projection engine 270 that determines a projected forecast for potential patients from the initial forecast, and an optimization engine 280 that determines a notification plan based on the projected forecast.
- the relationship identifier 230 may identify relationships between patients anonymously identified by the de-identified longitudinal medical records 210 and recipients of identified by the notification data 220 .
- the de-identified longitudinal medical records 210 may be collected from data servers at medical service providers that record filled prescription information, medical operations, doctor visits, or other medical events for patients.
- the information may generally include records of different anonymized patients, where each record identifies one or more treatments received by the anonymized patient, the one or more times the treatments were received by the anonymized patient, and an identifier that uniquely distinguishes the anonymized patient from other anonymized patients.
- the notification data 220 may be collected from data servers of notification providers that record notifications provided to recipients.
- the notification data may include notification records that each identify a type of notification provided, a time the notification was received, and the recipient of the notification.
- the relationship identifier 230 may obtain the de-identified longitudinal medical records 210 and the notification data 220 , and identify relationships between anonymized patients and recipients based on identifying, from the de-identified longitudinal medical records, anonymized patients that received the treatment, identifying, from the notification data, notifications for the treatment that were received by the recipients, and determining, for each of the identified notifications that were received by the recipients, whether the recipient is an anonymized patient identified as having received the treatment.
- the relationship identifier 230 may identify from a medical record that an anonymized patient identified as “ad978zfvd3426oiu90” received a particular treatment, identify from the notification data that a recipient identified as “ad978zfvd3426oiu90” received a notification for the particular treatment, and that the identifiers both have the value “ad978zfvd3426oiu90.”
- the relationship identifier 230 may, one or more of, determine whether notification records are for notifications for other treatments and determine to ignore those notifications or determine whether treatments indicated by the medical records are for other treatments and determine to ignore those indications in the medical records. Additionally or alternatively, the relationship identifier 230 may determine that the identifiers match.
- the relationship identifier 230 may determine that the identifier of an anonymized patient in a medical record indicates demographics of the anonymized patient, that are insufficiently detailed to identify the anonymized patient, match demographics indicated by the identifier of a recipient in a notification record.
- the time decay model generator 240 may determine an impact model based on the relationships determined by the relationship identifier 230 .
- the impact model may represent an impact of a notification on a treatment being received based on a time relationship between when a treatment was received by a patient and a notification was received by a recipient corresponding to the patient.
- the time decay model generator 240 may determine an impact model that models an impact of 66% for a notification received fifteen days before a treatment is received and an impact of 33% for a notification received thirty days before a treatment is received.
- the impact model may include a model that is exponentially decayed from time when the notification was initially provided to a patient to a time the treatment was received by the patient.
- the time decay model generator 240 may determine coefficients for an exponential function that receives as an input a time relationship and outputs an impact.
- the impact model may be specific to notification type.
- the time decay model generator 240 may generate an impact model that provides different impacts for the same time relationship for notifications of different types.
- the impact model may not be specific to notification type.
- the time decay model generator 240 may generate an impact model that provides the same impact for the same time relationship for notifications of the same type.
- the time decay model generator 240 may determine the impact model based on determining time relationships between times when treatments were received by anonymized patients and times when notifications were received by recipients corresponding to the anonymized patients, determining associations between one or more time relationships for notifications received by the anonymized patients, and determining the impact model from the determined associations between the time relationships. For example, the time decay model generator 240 may determine from the medical records 210 that anonymized patient “ad978zfvd3426oiu90” fulfilled a prescription for “Drug X” on Jul. 23, 2015, from the notification data 220 that a recipient determined to correspond to anonymized patient “ad978zfvd3426oiu90” received a notification regarding “Drug X” on Jul.
- the time decay model generator 240 may determine from the medical records 210 that anonymized patient “oinj32o908twvc2” fulfilled a prescription for “Drug X” on Jul. 1, 2015 and from the notification data 220 and determined relationships that a recipient corresponding to anonymized patient “oinj32o908twvc2” received a notification regarding “Drug X” on Jun. 1, 2015, and as result, determine a time relationship of thirty days.
- the time decay model generator 240 may determine the impact model. For example, the time decay model generator 240 may use machine-learning, e.g., Least Absolute Shrinkage and Selection Operator (LASSO), Cox Proportional Hazard (CPH) model, ensemble learning by random survival forest (RSF), with the de-identified longitudinal medical records 210 , the notification data 220 , and the determined time relationships to determine coefficients of an exponential function.
- machine-learning e.g., Least Absolute Shrinkage and Selection Operator (LASSO), Cox Proportional Hazard (CPH) model, ensemble learning by random survival forest (RSF), with the de-identified longitudinal medical records 210 , the notification data 220 , and the determined time relationships to determine coefficients of an exponential function.
- LASSO Least Absolute Shrinkage and Selection Operator
- CPH Cox Proportional Hazard
- RSF random survival forest
- the time decay model generator 240 may use random survival forest by randomly under sampling patients indicated by the medical records 210 that were not treated with the particular treatment, combine the under sampled data with the data of anonymized patients indicated by the medical records 210 that were treated with the particular treatment, apply random survival forest to derive an impact of a notification each day to the treatment being received, e.g., scores of impact of a notification each day to treatment being received may be generated, repeating these steps, e.g., for 50,000, 100,000 or some other number of times, and average the impacts, and then fitting a curve to impact decay over time based on the averaged impacts.
- the treatment impact attribution engine 250 may determine an impact of notifications on a treatment being received based on the impact model determined by the time decay model generator 240 .
- the treatment impact attribution engine 250 may attribute an impact of different types of notifications indicated by the notification data 220 over all anonymized patients identified by the medical records 210 and time based on the impact model. For example for each type of notification, the treatment impact attribution engine 250 may sum an impact of the type of notification on each anonymized patient indicated by the medical records 210 receiving the treatment based on the impact model. From the attribution, the treatment impact attribution engine 250 may determine different impacts of different types of notifications. For example, the treatment impact attribution engine 250 may determine that a particular type of notification has twice as much impact as another type of notification, i.e., results in twice as many patients receiving a treatment.
- the treatment trend prediction engine 260 may determine an initial forecast model based on the impacts determined by the treatment impact attribution engine. For example, the treatment trend prediction engine 260 may determine an initial forecast model that models a number of patients identified in the medical records 210 that would receive a treatment based on a number of each type of notification provided.
- a forecast model may store, for each type of notification, a notification type label that is indicative of a relationship between a number of patients receiving a treatment and a number of recipients receiving notifications for the treatment.
- a first notification type label for a first type of notification may reflect how a number of patients estimated to receive a treatment increases as a number of recipients of a notification of the first type of notification for that treatment increases and a second notification type label for a second type of notification may reflect how a number of patients estimated to receive a treatment increases as a number of recipients of a notification of the second type of notification for that treatment increases.
- the treatment trend prediction engine 260 may determine the initial forecast model based on fitting the model to the number of treatments received indicated by the medical records 210 and the notifications provided indicated by the notification data 220 . For example, the treatment trend prediction engine 260 may determine an initial forecast model that scales an impact of notifications of all types by an amount so that a number of patients forecasted to receive a treatment best matches the number of patients that actually received the treatment as indicated by the medical records 210 and the notification records 220 . The treatment trend prediction engine 260 may determine the initial forecast model as a sigmoid function considering the diminishing effect of number of notifications received by recipients on number of patients that receive a treatment.
- the treatment trend prediction engine 260 may generate more accurate initial forecast models as the amount of data increases across time. For example, at nine weeks data up to 100,000 notifications may be available, at thirteen weeks, data up to 150,000 notifications may be available, and at eighteen weeks data up to 200,000 notifications may be available, and the treatment trend prediction engine 260 may fit the initial forecast model to match the data.
- the projection engine 270 may determine a projected forecast for potential patients from the initial forecast determined by the treatment trend prediction engine 260 . For example, the projection engine 270 may project an initial forecast determined from a subset of patients with indicated by the medical records 210 to a set of all patients indicated by the medical records 210 , then project from the set of all patients indicated by the medical records 210 to all recipients of notifications indicated by the notification data 220 , and then project from all recipients of the notifications indicated by the notification data 220 to all potential recipients of the notification.
- the subset of patients of the initial forecast may be patients that have prescription drug activity within a predetermined number of months, e.g., the last three, six, twelve, or another number of months.
- the projection engine 270 may project forecasts from a first group to a second group based on scaling on characteristics of the groups. For example, the projection engine 270 may determine that the initial forecast is prepared for a set of one hundred patients where 40% have high blood pressure, and that the medical records 210 for all one thousand patients have 20% with high blood pressure, and in response, modify the initial forecast by a factor of five.
- the optimization engine 280 may determine a notification plan based on the projected forecast. For example, the optimization engine 280 may determine to provide one million of a particular type of notification and two million of another type of notification to increase a forecasted number of treatments. The optimization engine 280 may determine the notification plan based on notification constraints 290 .
- the notification constraints 290 may include specifications of one or more of a budget, notification types available, notifications provided so far, notifications allocated, a minimum number of notifications for each type, a maximum number of notifications of each type, a remaining number of notifications to provide for each type, a cost for each type of notification, an available budget for each type of notification, or a total budget for a type of notification.
- the notification constraints 290 may specify that a total of one million is available for notifications, three types of notifications are available, a first type of notification costs fourteen dollars per million provided, a second type of notification costs eighteen dollars per million provided, and a third type of notification costs sixteen dollars per million provided, and in response, based on the projected forecast model, the optimization engine 280 may determine to allocate two hundred thousand dollars to the first type of notification, five hundred thousand dollars to the second type of notification, and three hundred thousand dollars to the third type of notification.
- the optimization engine 280 may receive the notification constraints from a user.
- the optimization engine 280 may provide a graphical user interface for a user to input the notification constraints and change the notification constraints, and in response may update the notification plan and display the updated notification plan to the user through the graphical user interface.
- the optimization engine 280 may receive indications of events and in response update a notification plan. For example, the optimization engine 280 may receive an indication that a flu epidemic is spreading, and in response, may determine to increase a number of allocations of a particular type of notification and decrease a number of allocations of another type of notification.
- the optimization engine 280 may then schedule the notifications based on the forecast model. For example, the optimization engine 280 may cause the system 100 to provide notifications to recipients based on the notification plan. In another example, the optimization engine 280 may provide the notification plan to a notification provider for the notification provider to provide notifications in accordance with the notification plan.
- FIG. 3 illustrates an example of a flow chart 300 for providing timely notifications of treatments.
- de-identified longitudinal medical records are received ( 310 ).
- the relationship identifier 230 may receive de-identified longitudinal medical records from a database of a medical server provider.
- notification data is received ( 320 ).
- the relationship identifier 230 may receive notification data from a database of a notification provider.
- relationships between the medical records and the notification data may be identified ( 330 ).
- the relationships identifier 230 may determine that a particular medical record indicates that an anonymized patient received a particular treatment, determine that a particular notification record indicates that a recipient received a notification for the particular treatment, and determine that the particular medical record has an identifier, that refers to an anonymized patient, that is the same identifier representing a recipient that is associated with the particular notification record.
- time relationships between when treatments were received and notification were received may be determined ( 340 ).
- the time decay model generator 240 may determine that sixty days based between when a recipient received a notification of a treatment and an anonymized patient corresponding to the recipient received the treatment.
- associations between one or more time relationships may be determined ( 350 ).
- the time decay model generator 240 may determine the time relationships that are notifications for treatments provided to the same recipient before the recipient received the treatment.
- an impact model representing an impact of a notification on a treatment being received based on the determined associations between the time relationships may be generated ( 360 ).
- the time decay model generator 240 may generate the impact model that is exponentially decayed from time when the notification was initially provided to a patient to a time the treatment was received by the patient.
- the impact of notifications on the treatments being received may be determined based on the impact model and the determined time relationships ( 370 ).
- the treatment impact attribution engine 250 may determine the impact that a notification received sixty days before a treatment had on the treatment being received based on the impact model and that the notification was received sixty days before the treatment was received.
- a forecast model may be determined based on the impacts ( 380 ).
- the treatment trend prediction engine 260 may determine an initial forecast model for a set of patients based on the impacts and the projection engine 270 may project the initial forecast model to all potential notification recipients.
- a plan for timely notifying may be determined based on the forecast model ( 390 ).
- the optimization engine 280 may receive the forecast model and notification constraints specified by a user indicating types of notifications available and constraints on providing the notifications, and in response, determine a notification plan indicating how many of each type of notification should be provided.
- FIG. 4 illustrates an example timeline 400 of notifications being provided and a treatment being received.
- the timeline 400 may show time passing from left to right versus impact.
- the timeline 400 shows how as notifications are provided earlier from when a treatment is received, an impact of the notification decreases.
- notification type A is provided most earliest from when a treatment is received and is associated with a lowest impact
- notification type B is provided second most earliest from when a treatment is received and is associated with a second lowest impact
- notification type C is provided third most earliest from when a treatment is received and is associated with a third lowest impact
- notification type D is provided least earliest from when a treatment is received and is associated with a highest impact.
- FIG. 5 illustrates an example graph 500 of an impact of a notification with a time relationship between a notification and treatment.
- the x-axis represents a time relationship that increases from left to right and the y-axis represents an impact that increases from bottom to top.
- the impact decreases as the time relationship between when a notification is provided and a treatment is received increases.
- FIG. 6 illustrates a timeline 600 of notifications and impacts.
- the timeline 600 shows how lower impacts are associated with notifications with greater time relationships. For example, notification type A that has the greatest time relationship is associated with an impact of 5%, notification type B which has a second greatest time relationship is associated with an impact of 15%, notification type C which has a third greatest time relationship is associated with an impact of 30%, and notification type D which has a least time relationship is associated with an impact of 50%.
- FIG. 7 illustrates an example graph 700 output of forecast model of number of treatments with number of notifications.
- the forecast model may be generated so that the graph 700 is fitted to numbers of notification provided indicated by notification data and numbers of treatments received indicated by the medical records.
- FIG. 8 illustrates an example user interface for receiving notification constraints for determining a plan for timely providing notifications.
- the user interface may enable users to view and specify types of notifications differentiated by channel, e.g., display, audio, video, or some other channel, site providing the notification, e.g., publishers A-E, and placement of the notification, e.g., where on a site the notification may be provided.
- the user interface may further enable users to view and specify budgets for each type of notification, a total budget, minimum and maximum notifications to provide for each type of notification, and cost for each type of notification.
- FIGS. 9 and 10 illustrate example plans 900 , 1000 for timely providing notifications.
- the plans may indicate a number of each type of notification to provide to increase a number of patients receiving a treatment.
- the plans may further indicate an estimated budget used, an estimated number of notifications that will be used, and an estimated number of treatments that will be received, and differences from a previous plan.
- Implementations of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly-implemented computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them.
- Implementations of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible non-transitory program carrier for execution by, or to control the operation of, data processing apparatus.
- the computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.
- data processing apparatus refers to data processing hardware and encompasses all kinds of apparatus, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, or multiple processors or computers.
- the apparatus can also be or further include special purpose logic circuitry, e.g., a central processing unit (CPU), a FPGA (field programmable gate array), or an ASIC (application-specific integrated circuit).
- the data processing apparatus and/or special purpose logic circuitry may be hardware-based and/or software-based.
- the apparatus can optionally include code that creates an execution environment for computer programs, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.
- the present disclosure contemplates the use of data processing apparatuses with or without conventional operating systems, for example Linux, UNIX, Windows, Mac OS, Android, iOS or any other suitable conventional operating system.
- a computer program which may also be referred to or described as a program, software, a software application, a module, a software module, a script, or code, can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
- a computer program may, but need not, correspond to a file in a file system.
- a program can be stored in a portion of a file that holds other programs or data, e.g., one or more scripts stored in a markup language document, in a single file dedicated to the program in question, or in multiple coordinated files, e.g., files that store one or more modules, sub-programs, or portions of code.
- a computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network. While portions of the programs illustrated in the various figures are shown as individual modules that implement the various features and functionality through various objects, methods, or other processes, the programs may instead include a number of sub-modules, third party services, components, libraries, and such, as appropriate. Conversely, the features and functionality of various components can be combined into single components as appropriate.
- the processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output.
- the processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., a central processing unit (CPU), a FPGA (field programmable gate array), or an ASIC (application-specific integrated circuit).
- CPU central processing unit
- FPGA field programmable gate array
- ASIC application-specific integrated circuit
- Computers suitable for the execution of a computer program include, by way of example, can be based on general or special purpose microprocessors or both, or any other kind of central processing unit.
- a central processing unit will receive instructions and data from a read-only memory or a random access memory or both.
- the essential elements of a computer are a central processing unit for performing or executing instructions and one or more memory devices for storing instructions and data.
- a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks.
- mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks.
- a computer need not have such devices.
- a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device, e.g., a universal serial bus (USB) flash drive, to name just a few.
- PDA personal digital assistant
- GPS Global Positioning System
- USB universal serial bus
- Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
- the memory may store various objects or data, including caches, classes, frameworks, applications, backup data, jobs, web pages, web page templates, database tables, repositories storing business and/or dynamic information, and any other appropriate information including any parameters, variables, algorithms, instructions, rules, constraints, or references thereto. Additionally, the memory may include any other appropriate data, such as logs, policies, security or access data, reporting files, as well as others.
- the processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
- implementations of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube), LCD (liquid crystal display), or plasma monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer.
- a display device e.g., a CRT (cathode ray tube), LCD (liquid crystal display), or plasma monitor
- a keyboard and a pointing device e.g., a mouse or a trackball
- Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
- a computer can interact with a user by sending documents to and receiving documents from a
- GUI graphical user interface
- GUI may be used in the singular or the plural to describe one or more graphical user interfaces and each of the displays of a particular graphical user interface. Therefore, a GUI may represent any graphical user interface, including but not limited to, a web browser, a touch screen, or a command line interface (CLI) that processes information and efficiently presents the information results to the user.
- a GUI may include a plurality of user interface (UI) elements, some or all associated with a web browser, such as interactive fields, pull-down lists, and buttons operable by the business suite user. These and other UI elements may be related to or represent the functions of the web browser.
- UI user interface
- Implementations of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back-end, middleware, or front-end components.
- the components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN), a wide area network (WAN), e.g., the Internet, and a wireless local area network (WLAN).
- LAN local area network
- WAN wide area network
- WLAN wireless local area network
- the computing system can include clients and servers.
- a client and server are generally remote from each other and typically interact through a communication network.
- the relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
Abstract
Description
Claims (37)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/892,830 USRE49853E1 (en) | 2015-07-31 | 2022-08-22 | System and method for timely notification of treatment |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/815,025 US10755812B1 (en) | 2015-07-31 | 2015-07-31 | System and method for timely notification of treatment |
US17/892,830 USRE49853E1 (en) | 2015-07-31 | 2022-08-22 | System and method for timely notification of treatment |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/815,025 Reissue US10755812B1 (en) | 2015-07-31 | 2015-07-31 | System and method for timely notification of treatment |
Publications (1)
Publication Number | Publication Date |
---|---|
USRE49853E1 true USRE49853E1 (en) | 2024-02-27 |
Family
ID=72140845
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/815,025 Ceased US10755812B1 (en) | 2015-07-31 | 2015-07-31 | System and method for timely notification of treatment |
US17/892,830 Active 2038-10-21 USRE49853E1 (en) | 2015-07-31 | 2022-08-22 | System and method for timely notification of treatment |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/815,025 Ceased US10755812B1 (en) | 2015-07-31 | 2015-07-31 | System and method for timely notification of treatment |
Country Status (1)
Country | Link |
---|---|
US (2) | US10755812B1 (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11552785B2 (en) * | 2020-04-02 | 2023-01-10 | Epidaurus Health, Inc. | Methods and systems for a synchronized distributed data structure for federated machine learning |
Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040059599A1 (en) * | 2002-09-25 | 2004-03-25 | Mcivor Michael E. | Patient management system |
US20070204066A1 (en) * | 2004-09-09 | 2007-08-30 | Universite De Bourgogne | Method of identifying data relating to individuals in order to chain said data |
US20090287837A1 (en) * | 2000-07-06 | 2009-11-19 | David Paul Felsher | Information record infrastructure, system and method |
US20130159021A1 (en) * | 2000-07-06 | 2013-06-20 | David Paul Felsher | Information record infrastructure, system and method |
US20140052475A1 (en) * | 2012-08-16 | 2014-02-20 | Ginger.io, Inc. | Method for modeling behavior and health changes |
US20140081669A1 (en) * | 2007-07-03 | 2014-03-20 | Eingot Llc | Records Access and Management |
US20140357961A1 (en) * | 2013-06-04 | 2014-12-04 | Purdue Pharma L.P. | System and method for supporting health management services |
US20150007249A1 (en) * | 2013-06-26 | 2015-01-01 | Sap Ag | Method and system for on-the-fly anonymization on in-memory databases |
US20150046192A1 (en) * | 2007-07-03 | 2015-02-12 | Elngot Llc | Records access and management |
US20150134346A1 (en) * | 2013-11-14 | 2015-05-14 | Elwha LLC, a limited liability company of the State of Delaware | Devices, systems, and methods for automated medical product or service delivery |
US20150235240A1 (en) * | 2014-02-18 | 2015-08-20 | 24/7 Customer, Inc. | Method and apparatus for improving customer interaction experiences |
US20150244687A1 (en) * | 2014-02-24 | 2015-08-27 | HCA Holdings, Inc. | Providing notifications to authorized users |
US20150269355A1 (en) * | 2014-03-19 | 2015-09-24 | Peach Intellihealth, Inc. | Managing allocation of health-related expertise and resources |
US20170161439A1 (en) * | 2007-07-03 | 2017-06-08 | Eingot Llc | Records access and management |
-
2015
- 2015-07-31 US US14/815,025 patent/US10755812B1/en not_active Ceased
-
2022
- 2022-08-22 US US17/892,830 patent/USRE49853E1/en active Active
Patent Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090287837A1 (en) * | 2000-07-06 | 2009-11-19 | David Paul Felsher | Information record infrastructure, system and method |
US20130159021A1 (en) * | 2000-07-06 | 2013-06-20 | David Paul Felsher | Information record infrastructure, system and method |
US20040059599A1 (en) * | 2002-09-25 | 2004-03-25 | Mcivor Michael E. | Patient management system |
US20070204066A1 (en) * | 2004-09-09 | 2007-08-30 | Universite De Bourgogne | Method of identifying data relating to individuals in order to chain said data |
US20150046192A1 (en) * | 2007-07-03 | 2015-02-12 | Elngot Llc | Records access and management |
US20140081669A1 (en) * | 2007-07-03 | 2014-03-20 | Eingot Llc | Records Access and Management |
US20170161439A1 (en) * | 2007-07-03 | 2017-06-08 | Eingot Llc | Records access and management |
US20140052475A1 (en) * | 2012-08-16 | 2014-02-20 | Ginger.io, Inc. | Method for modeling behavior and health changes |
US20140357961A1 (en) * | 2013-06-04 | 2014-12-04 | Purdue Pharma L.P. | System and method for supporting health management services |
US20150007249A1 (en) * | 2013-06-26 | 2015-01-01 | Sap Ag | Method and system for on-the-fly anonymization on in-memory databases |
US20150134346A1 (en) * | 2013-11-14 | 2015-05-14 | Elwha LLC, a limited liability company of the State of Delaware | Devices, systems, and methods for automated medical product or service delivery |
US20150235240A1 (en) * | 2014-02-18 | 2015-08-20 | 24/7 Customer, Inc. | Method and apparatus for improving customer interaction experiences |
US20150244687A1 (en) * | 2014-02-24 | 2015-08-27 | HCA Holdings, Inc. | Providing notifications to authorized users |
US20150269355A1 (en) * | 2014-03-19 | 2015-09-24 | Peach Intellihealth, Inc. | Managing allocation of health-related expertise and resources |
Also Published As
Publication number | Publication date |
---|---|
US10755812B1 (en) | 2020-08-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11798670B2 (en) | Methods and systems for managing patient treatment compliance | |
US20210398626A1 (en) | System and Method for Creation of Persistent Patient Identification | |
Shah et al. | Panacea of challenges in real-world application of big data analytics in healthcare sector | |
US20160140322A1 (en) | System and Method for Conducting Cohort Trials | |
WO2015081086A1 (en) | System and method for medical data analysis and sharing | |
US20090012816A1 (en) | Systems and methods for clinical analysis integration services | |
KR102249739B1 (en) | Handwriting recognition tool | |
Singh et al. | Blockchain with cloud for handling healthcare data: A privacy-friendly platform | |
US20200066412A1 (en) | Validating efficacy of medical advice | |
USRE49853E1 (en) | System and method for timely notification of treatment | |
US10586614B1 (en) | System and method for timely multi-channel notification of treatment | |
Azhagiri et al. | Secured electronic health record management system | |
US20150261916A1 (en) | System Development Dataset Preparation | |
Solomon | Monitoring and evaluation: Key steps for long-term services and supports organizations | |
US20210193325A1 (en) | System and method for providing a drug therapy coordination risk score and improvement model-of-care | |
US20180052960A1 (en) | Computer-implemented methods of promoting patient compliance with one or more recommended treatments or screening regimens | |
Mohamadali et al. | A novel conceptual framework of Health information systems (HIS) sustainability | |
US20160275265A1 (en) | System and Method for Identifyiing Healthcare Professionals | |
US10937531B1 (en) | System and method for timely notification of treatments to healthcare providers and patient | |
Candrilli et al. | The response to and cost of meningococcal disease outbreaks in university campus settings | |
US11830586B2 (en) | Enhancement of patient outcome forecasting | |
McFarlane et al. | Facility registries: Metadata for where care is delivered | |
Nagadeepa et al. | Blockchain-Based Electronic Health Records (EHRs): Enhancing Patient Data Accessibility in Emergency Situations | |
US11188620B1 (en) | System and method to improve dynamic multi-channel information synthesis | |
US11488691B2 (en) | Medical registries |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
AS | Assignment |
Owner name: U.S. BANK TRUST COMPANY, NATIONAL ASSOCIATION, MINNESOTA Free format text: SECURITY INTEREST;ASSIGNORS:IQVIA INC.;IQVIA RDS INC.;IMS SOFTWARE SERVICES LTD.;AND OTHERS;REEL/FRAME:063745/0279 Effective date: 20230523 |
|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT, NORTH CAROLINA Free format text: SECURITY INTEREST;ASSIGNORS:IQVIA INC.;IMS SOFTWARE SERVICES, LTD.;REEL/FRAME:064258/0577 Effective date: 20230711 |
|
AS | Assignment |
Owner name: U.S. BANK TRUST COMPANY, NATIONAL ASSOCIATION, MINNESOTA Free format text: SECURITY INTEREST;ASSIGNOR:IQVIA INC.;REEL/FRAME:065709/0618 Effective date: 20231128 Owner name: U.S. BANK TRUST COMPANY, NATIONAL ASSOCIATION, MINNESOTA Free format text: SECURITY INTEREST;ASSIGNORS:IQVIA INC.;IQVIA RDS INC.;IMS SOFTWARE SERVICES LTD.;AND OTHERS;REEL/FRAME:065710/0253 Effective date: 20231128 |
|
AS | Assignment |
Owner name: U.S. BANK TRUST COMPANY, NATIONAL ASSOCIATION, MINNESOTA Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE CONVEYING PARTIES INADVERTENTLY NOT INCLUDED IN FILING PREVIOUSLY RECORDED AT REEL: 065709 FRAME: 618. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY AGREEMENT;ASSIGNORS:IQVIA INC.;IQVIA RDS INC.;IMS SOFTWARE SERVICES LTD.;AND OTHERS;REEL/FRAME:065790/0781 Effective date: 20231128 |