Patent Application
20220310268
Embodiments described herein are generally related to the use of data analytics in medical applications, and to systems and methods for patient monitoring, including use of pattern detection in assessing self-reported participant symptom data indicative of possible illnesses.
Today's medical health systems maintain databases of symptom data which can be useful in determining trends within the data. However, in situations where patient participation or symptom reporting may be voluntary and/or intermittent, the recorded symptom data may be sparse, and gaps in the data can impact its use in various investigations.
For example, when participation is voluntary, there may be no requirement that a person exhibiting symptoms, or who has been tested for the presence of a particular medical condition, will actually return to report any change in their symptoms, which information might be useful in treatment of their condition, or tracing within the wider community. Voluntary and/or intermittent reporting may also impact the ability to accurately assess a particular patient's progress over a period of time.
In accordance with an embodiment, described herein are systems and methods for use of data analytics in medical applications, including the use of pattern detection in assessing self-reported participant symptom data indicative of possible illness. A patient monitoring system or service can be provided, for example at an analytics cloud environment. The system is adapted to capture self-reported participant symptom data from individual participants, and track changes in their reported symptoms over time. The system performs data queries against the received participant symptom data, to identify patterns in the data indicative of participant clusters and episodes indicative of possible illness, which information can then be provided, for example, to a medical organization system and used to respond to investigative queries. The approach can accommodate voluntary and/or intermittent reporting, including sparsity or gaps in the input stream of symptom data received from the participants.
As described above, today's medical health systems maintain databases of symptom data which can be useful in determining trends within the data. However, in situations where patient participation or symptom reporting may be voluntary and/or intermittent, the recorded symptom data may be sparse, and gaps in the data can impact its use in various investigations.
In accordance with an embodiment, described herein are systems and methods for use of data analytics in medical applications, including the use of pattern detection in assessing self-reported participant symptom data indicative of possible illness.
In accordance with an embodiment, a patient monitoring system or service can be provided, for example at an analytics cloud environment. The system is adapted to capture self-reported participant symptom data from individual participants, and track changes in their reported symptoms over time. The system performs data queries against the received participant symptom data, to identify patterns in the data indicative of participant clusters and episodes indicative of possible illness, which information can then be provided, for example, to a medical organization system and used to respond to investigative queries.
In accordance with an embodiment, the approach can accommodate voluntary and/or intermittent reporting, including sparsity or gaps in the input stream of symptom data received from the participants.
For example, in accordance with an embodiment, the systems and methods described herein can be used to capture self-reported participant symptom data provided by individual participants who are either suspected to have contracted, or may have been potentially exposed to, severe acute respiratory syndrome coronavirus disease (e.g., Coronavirus Disease 2019, COVID-19, COVID), and track changes in their reported symptoms over time. Such information can then be used to identify patterns in the participant symptom data indicative of participant clusters, and episodes indicative of possible coronavirus-related illnesses.
In accordance with an embodiment, the determination of participant clusters can be used, for example, to identify continuous sets of symptom reports; or segment a population into irregular reporters versus regular reporters, and correlate their reports to actual symptoms. An identification of such participant clusters is useful in aggregating participant behavioral information at a cluster level, and correlating the information provided with actual symptoms and symptom density.
In accordance with an embodiment, the determination of episodes can be used, for example, to identify actual bouts of illness/sickness reflected in the fine-grain participant symptom data stream, and aggregate and report various parameters regarding those bouts of illness/sickness, for further classification. An identification of such episodes is useful in summarizing disease characteristics at a higher level which can be used, for example, to analyze the emergence of possible COVID infections or trends within the community.
In accordance with an embodiment, a patient monitoring system or service can be provided at an analytics cloud environment, for example as described below, for use of data analytics in medical applications, including the use of pattern detection in assessing self-reported participant symptom data indicative of possible illness.
In accordance with an embodiment, the example analytics cloud environment illustrated in
As illustrated in
In accordance with an embodiment, the components and processes illustrated in
In accordance with an embodiment, the control plane enables access by a client computer device 10 having a device hardware 12, administrative application 14, and user interface 16, under control of a user (tenant) 20 and/or a cloud environment having a provisioning component.
In accordance with an embodiment, the data plane can include a data pipeline or process layer and a data transformation layer that together process operational or transactional data from an organization's enterprise software application or data environment. In accordance with an embodiment, the data transformation layer can include a data model, such as, for example, a knowledge model (KM), or other type of data model, that the system uses to transform the transactional data, into a model format understood by the analytics cloud environment. The model format can be provided in any data format suited for storage in a data warehouse.
In accordance with an embodiment, a data pipeline or process can be scheduled to execute at intervals (e.g., hourly/daily/weekly) to extract transactional data from a software application or database environment.
In accordance with an embodiment, an extract process can extract the transactional data, whereupon extraction the data pipeline or process can insert extracted data into a data staging area, which can act as a temporary staging area for the extracted data. The data quality component and data protection component can be used to ensure the integrity of the extracted data. For example, the data quality component can perform validations on the extracted data while the data is temporarily held in the data staging area. In accordance with an embodiment, when the extract process has completed its extraction, the data transformation layer can be used to begin the transform process, to transform and load the extracted data into the data warehouse.
As illustrated in
In accordance with an embodiment, the presentation layer enables access to a data warehouse instance, database, or data content using, for example, a software analytic application, dashboard, views 242, or other type of report or interface as may be provided by products such as, for example, Oracle Analytics Cloud, Oracle Analytics for Applications, or Oracle Fusion analytics.
As further illustrated in
In accordance with an embodiment, the participant interface enables communication with mobile devices or other devices that include a participant reporting application and that are adapted receive from participants a symptom data, for example via an email or text survey communicated by the patient monitoring system or service to the participant's device for completion by the participant.
In accordance with an embodiment, the provider interface enables communication with medical organization systems or other devices that enable display of a dashboard of information that allows the organization or user to perform interactive reporting or visualizations associated with the participant symptom data.
In accordance with an embodiment, the disease-specific data views, enable data queries to be performed on the data and used to create visualizations. The result of such data queries can be provided directly to a medical organization system via the provider interface, or can be provided via and/or combined with information provided by the presentation layer.
As further illustrated in
For example, in accordance with an embodiment, the information saved in the database can be stored in a data warehouse instance which is populated using any of the above means.
In accordance with an embodiment, the system is adapted to capture self-reported participant symptom data from individual participants, and track changes in their reported symptoms over time. The system performs data queries 312 against the received participant symptom data, to identify patterns 314 in the data indicative of participant clusters and episodes indicative of possible illness, which information can then be provided, for example, to a medical organization system and used to respond to investigative queries.
In accordance with an embodiment, the patient monitoring system or service as described herein can use pattern-matching capabilities supported by a database that stores the participant symptom data, such as for example the use of a MATCH_RECOGNIZE data query, to identify and abstract the above participant and episode concepts from fine-grained participant symptom data. Such pattern-matching data queries can be used to identify a particular shape in a stream of data, and to sift through the fine-grained records and identify participant clusters and episodes.
For example, in accordance with an embodiment, the patient monitoring system or service can provide a disease-specific data view into the reported participant symptom data, which utilizes a MATCH_RECOGNIZE data query to assess, within a 3-day rolling window, various, e.g., COVID-related symptoms associated with one or more patient participants; including filtering or grouping symptom reports and tracking them over time.
As illustrated in
In accordance with an embodiment, the participant device can communicate 332 with the participant interface of the system, via for example the Internet or other communication means to provide self-reported participant symptom data.
As further illustrated in
In accordance with an embodiment, the medical organization system can communicate 352 with the provider interface of the system, via for example the Internet or other communication means of receiving or accessing the self-reported participant symptom data.
As illustrated in
In accordance with an embodiment, the patient monitoring system or service as described herein can use pattern-matching capabilities such as for example the use of a MATCH_RECOGNIZE data query, to identify and abstract the above participant and episode concepts from fine-grained participant symptom data. For example, MATCH_RECOGNIZE enables the system to perform data queries to accomplish tasks such as, for example:
Logically partition and order the data that is used in the MATCH_RECOGNIZE clause with PARTITION BY and ORDER BY clauses.
Define patterns of rows to seek using a PATTERN clause. These patterns can use a regular expression syntax applied to the pattern variables.
Specify the logical conditions required to map a row to a row pattern variable in a DEFINE clause. DEFINE indicates the conditions that must be met for a row to map to a row pattern variables STRT, DOWN, and UP. Because there is no condition for STRT, any row can be mapped to STRT.
Define measures, which are expressions usable in other parts of the SQL query, in a MEASURES clause.
An indication of ONE ROW PER MATCH means that for every pattern-match found, there will be one row of output.
An indication of AFTER MATCH SKIP TO LAST UP means that whenever a match is found, the search will be restarted at the row that is the last row of the UP pattern variable.
An indication of PATTERN (STRT DOWN+ UP+) indicates that the pattern being searched has three pattern variables: STRT, DOWN, and UP. The plus sign (+) after DOWN and UP means that at least one row must be mapped to each of them.
For example, when applied to a set of data, the MATCH_RECOGNIZE clause performs these steps:
The row pattern input table is partitioned according to the PARTITION BY clause. Each partition consists of the set of rows of the input table that have the same value on the partitioning columns.
Each row pattern partition is ordered according to the ORDER BY clause.
Each ordered row pattern partition is searched for matches to the PATTERN.
Pattern-matching operates by seeking the match at the earliest row, considering the rows in a row pattern partition in the order specified by the ORDER BY clause.
Pattern-matching in a sequence of rows is an incremental process, with one row after another examined to see if it fits the pattern. If no match is found at the earliest row, the search moves to the next row in the partition, checking if a match can be found starting with that row. After a match is found, row pattern-matching calculates the row pattern measure columns, which are expressions defined by the MEASURES clause.
Using ONE ROW PER MATCH, pattern-matching generates one row for each match that is found. If ALL ROWS PER MATCH is used, every row that is matched is included in the pattern-match output.
The AFTER MATCH SKIP clause determines where row pattern-matching resumes within a row pattern partition after a non-empty match is found.
The above is provided by way of example, to illustrate the manner by which a MATCH_RECOGNIZE data query or clauses can be used to access a data warehouse or database that stores self-reported participant symptom data and provide resultant information to the presentation layer and/or to the health system provider interface. In accordance with other embodiments, other types of data queries or clauses can be used to perform pattern recognition.
In accordance with an embodiment, the system is adapted to capture self-reported symptom data from individual participants, and track changes in their reported symptoms over time.
As illustrated in
As illustrated in
As illustrated in
As illustrated in
As illustrated in
In accordance with an embodiment, the system performs data queries against the received participant symptom data, to identify patterns in the data indicative of participant clusters and episodes indicative of possible illness, which information can then be provided, for example, to a medical organization system and used to respond to investigative queries.
For example, in accordance with an embodiment, the U.S. Centers for Disease Control and Prevention (CDC) may provide a “COVID-like illness” symptom definition as including “Fever”=Yes AND (“Cough”=Yes OR “Shortness of Breath”=Yes OR “Gasping for Air”=Yes OR “Difficult Breathing”=Yes); for 3 consecutive days OR at least 2 out of 3 days with the middle day missing. In accordance with this definition, if data for the middle day is present, but does not have that combination of symptoms, then the present day should not be marked as COVID-like illness.
In accordance with an embodiment, the patient monitoring system or service can provide a disease-specific data view into the reported participant symptom data, which utilizes a MATCH_RECOGNIZE data query to assess, within a 3-day rolling window, various, e.g., COVID-related symptoms associated with one or more patient participants; including filtering or grouping symptom reports and tracking them over time.
Such tracking can be discontinued once there is, e.g., a 5-day gap in reported symptoms, again as determined by a MATCH_RECOGNIZE data query. Provided information can be used to assess, for example, whether particular participants may be stopping and/or restarting their reporting of symptoms, or to distinguish situations wherein reported symptoms indicate the presence of perhaps seasonal allergies or influenza versus, e.g., a COVID-like illness.
As illustrated in
For example, in accordance with an embodiment, the system can perform data queries against the received participant symptom data, as defined by a cluster pattern 382, to determine participant clusters 383, which information can then be provided, for example, to a medical organization system and used to respond to investigative queries.
For example, as illustrated in
In accordance with an embodiment, the example symptoms and cluster pattern definition illustrated in
In accordance with an embodiment, the patient monitoring system or service is adapted to perform SQL data queries that correspond to the defined pattern, including for example one or more pattern-matching SQL data queries that incorporate a MATCH_RECOGNIZE clause, for example as illustrated in example (MATCH_RECOGNIZE) query 1 below, to access the data warehouse or database that stores self-report participant symptom data and provide resultant information to the presentation layer and/or to the health system provider interface.
In accordance with an embodiment, the determination of participant clusters can be used, for example, to identify continuous sets of symptom reports; or segment a population into irregular reporters versus regular reporters, and correlate their reports to actual symptoms. An identification of such participant clusters is useful in aggregating participant behavioral information at a cluster level, and correlating the information provided with actual symptoms and symptom density.
Determination of Episodes Indicative of Possible Illness
For example, as illustrated in
For example, as illustrated in
In accordance with an embodiment, the example episode pattern illustrated in
In accordance with an embodiment, the system can be used to determine further investigations, for example: What is the exact logic for triggering an episode (or terminating an episode (how long, which symptoms)? What do we need summarized at episode/cluster level? Can one combine multiple event data (tests and status updates), for example:
Symptom X−Symptom Y−Test A−Symptom Z−Test B
As described above, in accordance with an embodiment, the patient monitoring system or service is adapted to perform SQL data queries that correspond to the defined pattern, including for example one or more pattern-matching SQL data queries that incorporate a MATCH_RECOGNIZE clause, for example as illustrated in example (MATCH_RECOGNIZE) query 2 below, to access the data warehouse or database that stores self-report participant symptom data and provide resultant information to the presentation layer and/or to the health system provider interface.
In accordance with an embodiment, the determination of episodes can be used, for example, to identify actual bouts of illness/sickness reflected in the fine-grain participant symptom data stream, and aggregate and report various parameters regarding those bouts of illness/sickness, for further classification. An identification of such episodes is useful in summarizing disease characteristics at a higher level which can be used, for example, to analyze the emergence of possible COVID infections or trends within the community.
As illustrated in
Example Organization Dashboards
In accordance with an embodiment, the provider interface enables communication with medical organization systems or other devices that enable display of a dashboard of information that allows the organization or user to perform interactive reporting or visualizations associated with the participant symptom data.
As illustrated in
As illustrated in
For example, an identification of such participant clusters is useful in aggregating participant behavioral information at a cluster level, and correlating the information provided with actual symptoms and symptom density.
As illustrated in
For example, an identification of such episodes is useful in summarizing disease characteristics at a higher level which can be used, for example, to analyze the emergence of possible COVID infections or trends within the community.
As illustrated in
At step 392, a patient monitoring system (service), including a participant interface that provide access by participant devices is provided, wherein the system (service) is adapted to capture self-reported (e.g., COVID) symptom data from individual participants, and track changes in their symptoms over time.
At step 394, by applying MATCH_RECOGNIZE data queries to the self-reported participant symptom data, patterns of symptoms associates with participants can be determined.
At step 396, the system determines participant clusters, and episodes indicative of possible illness, for use in generating dashboards or responding to investigative queries.
Example Participant Surveys
In accordance with an embodiment, the systems and methods described above can be used to provide a patient monitoring system, for example at an analytics cloud environment, which can also be shared by various organizations, such as for example hospital systems, insurance providers, universities, senior living facilities, pharmacies, and workplaces, for purposes of monitoring public health during, e.g., a COVID pandemic.
For example, in accordance with an embodiment, the patient monitoring system allows organizations to track population trends for symptoms, exposure, and preventative actions related to COVID, by inviting the public to report daily activities. Organizations can access de- identified participant data, and use the information to prepare data visualizations and reports that are useful in addressing the pandemic.
In accordance with an embodiment, the participant interface enables communication with mobile devices or other devices that include a participant reporting application and that are adapted receive from participants a symptom data, for example via a survey.
For example, in accordance with an embodiment, an organization can invite individuals to report their daily symptoms, behaviors, treatments, contacts, use of personal protective equipment, or other factors. Participants receive a request to share their information via a daily update, for example by responding to an email or text survey. An organization can create one or more additional or custom surveys, such as, for example:
Standard daily: A standard daily survey.
Custom daily: A custom daily survey that allows the organization customize the questions in the daily update.
Supplemental: A supplemental survey that contains questions that participants complete in addition to the standard or custom daily survey; for example, to capture information about whether participants participated in non-household gatherings, or exercised safeguards during a holiday weekend.
In-office: An in-office survey that a healthcare practitioner completes for a participant, usually as part of an in-office or telehealth visit, and is suitable for information that is best collected from a practitioner in an office situation, or that might require medical interpretation.
On-demand: An on-demand survey that a practitioner completes for a participant after an event has occurred, and is suitable for information that is best collected from a practitioner in an office situation, or that might require medical interpretation.
In accordance with an embodiment, an organization can also create surveys at various levels, such as, for example: Organization: for all participants in the organization; or Entity: for all participants in one entity. An organization can also determine the frequency of custom surveys, for example, to send the custom daily survey every other day rather than every day, or to start on a particular date.
The above feature are provided by way of example, to illustrated a particular embodiment or example of the types of features and surveys that can be supported by a patient monitoring system. In accordance with other embodiments, other types of features and surveys that can be supported by the patient monitoring system.
In accordance with various embodiments, the teachings herein may be conveniently implemented using one or more conventional general purpose or specialized computer, computing device, machine, or microprocessor, including one or more processors, memory and/or computer readable storage media programmed according to the teachings of the present disclosure. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art.
In some embodiments, the teachings herein can include a computer program product which is a non-transitory computer readable storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the present teachings. Examples of such storage mediums can include, but are not limited to, hard disk drives, hard disks, hard drives, fixed disks, or other electromechanical data storage devices, floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems, or other types of storage media or devices suitable for non-transitory storage of instructions and/or data.
The foregoing description has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the scope of protection to the precise forms disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art.
The embodiments were chosen and described in order to best explain the principles of the present teachings and their practical application, thereby enabling others skilled in the art to understand the various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope be defined by the following claims and their equivalents.
