Patent Application
20160328537
The present invention relates generally to public health, and more particularly to a system and method for verified reporting of illness states.
Occurrences of illnesses are reported in a variety of ways, and are tracked for by various governmental entities, as well as by private entities. By way of example, illness are reported by individuals when visiting a healthcare provider. Accordingly, illness reports including associated information are reflected in corresponding medical records and/or associated insurance claims records (collectively referred to herein as “healthcare records”). Healthcare provider data from such records is aggregated and reviewed, so that illness can be tracked for various purposes, including for epidemiological purposes. Accordingly, illness data has been associated, for tracking purposes, with geographical areas or regions.
Data feeds reflecting data aggregated from healthcare records are commercially available in the marketplace. For example, IMS Health Incorporated of Danbury, Conn. provides commercially available data feeds reflecting data aggregated from healthcare/electronic medical record and/or insurance claim records. The data in such data feeds reflect the granularity of the underlying structure of the data as it is reported. For example, if the data is gathered from insurance claim records, the data will be matched to a standardized index/code/naming/claim structure used to process such claims. For example, the underlying data may reflect a reported “influenza-like illness (ILI)”, because that there is an associated code/option to the healthcare provider for selecting this reported condition.
Further, the underlying data reflects the granularity resulting from the aggregation process. Accordingly, each reported illness may be reported by an individual having a specific home address, but aggregation of the data may be done on a state, county, zip code, township, or other regional market basis. Accordingly, the data available in the data feed reflects illness data for geographical market regions generally. For example, a commercially-available data feed from IMS Health includes a data record including XML-formatted content identifying a geographical location such as a market region (e.g., Philadelphia metropolitan area), and a reported illness event type (e.g., cold, flu, or allergy). Further, the record may include a severity value, which may reflect a calculated or otherwise-determined reference point on a severity scale representing degrees of severity (e.g., on a scale of 0-12, with 12 indicating a highest severity).
Such data feeds are somewhat limited in nature, as they fail to capture illness states that are not reported to healthcare providers, or for which there is no corresponding healthcare record. Further, they capture illness states for purposes of medical/insurance claims, and not on a per-symptom basis. Accordingly, there is some ambiguity in the data from the perspective of illness states and/or symptoms. For example, it is not clear exactly which symptoms (sore throat and/or fever and/or a cough and/or aches, etc.) were reported for a report of an ILI—the ILI reporting code lacks this granularity.
Other approaches are known for identifying and tracking illness state information. For example, illness information may be discussed in forums other than in the context of a report to a healthcare provider. For example, illnesses and/or symptoms may be discussed by individuals on social media platforms—such as Facebook, Twitter, Google Plus, LinkedIn, etc. Sickweather, LLC of Windsor Mill, Md. provides a commercially available data feed that reflects illness data extracted from social media content. Exemplary technology for extracting illness information from social media content is disclosed in U.S. Published Patent Application No. 2014/0108374, the entire disclosure of which is hereby incorporated herein by reference. Such technology further includes associating extracted illness information with a geographical location (such as a latitude/longitude coordinate), and geographical mapping of such information, as discussed therein. An exemplary data feed includes an illness/symptom identifier, latitude and longitude coordinate information, and a timestamp indicating an associated date/time of the social media posting from which the content was extracted.
The data in such data feeds reflect the fine granularity of user-reported illness/condition/symptom that is essentially unrestricted. In other words, a user may place any words in its social media content—flu, sick, congested, “stuffy,” etc. Further, users are more likely to complain in this context of symptoms, rather than illness diagnoses of the type that would be used by healthcare providers. Accordingly, there may be ambiguity in the social mention data, from an illness perspective. For example, when a user complains in a social media posting of a runny nose, it may be unclear whether the complaint relates to an allergy or common cold illness.
These disparate data sources have different purposes, and both have weaknesses in terms of their usefulness to individual consumers, e.g., purchasing appropriate over-the-counter medications for treating observed illnesses/symptoms. What is needed is a system and method for verified reporting of illness/malady/symptom (collectively, “illness”) states in which illness state data is provided to a consumer in a more reliable fashion that is useful to the consumer in purchasing over-the-counter medications for treating observed illnesses/symptoms.
The present invention provides a system and method for reporting of illness states in a verified manner, using disparate datasets reflecting illness state reporting. According to one aspect, the present invention provides a verified illness state correlation system (VISCS). The VISCS comprises a processor and a memory operatively connected to the processor, the memory storing executable instructions that, when executed by the processor, cause the system to perform a method for correlating disparate datasets to verify illness reports. The method comprises: receiving a first data set comprising records identifying reported illness events, each record of said first data set comprising aggregated illness event data for each of a plurality of geographic regions; receiving a second data set comprising records identifying reported illness events, each record of said second data set identifying a specific reported illness at a specific geographic location; for each record of said second data set: identifying a matching geographic region of the first data set that encompasses the specific geographic location; determining whether the specific reported illness matches any reported illness event for the matching geographic region; determining a severity level for any matching reported illness state for the matching geographic region; storing the specific reported illness in association with the specific geographic location; and if the severity level exceeds a predetermined threshold, storing, in association with the stored specific reported illness and the stored specific geographic location, a verification flag indicating that the specific reported illness of the second data set is verified by data from the first data set.
According to another aspect, the present invention provides a verified illness state reporting system (VISRS). The VISRS comprises a processor; a display device; and a memory operatively connected to the processor, the memory storing executable instructions that, when executed by the processor, cause the system to perform a method for displaying verified illness reports. The method comprises: receiving input identifying a particular geographical region for which illness reporting shall be displayed via the display device; receiving via a communications network, in response to a request therefor, verified illness state data for the particular geographical region, the verified illness state data comprising a plurality of records, each of the plurality of records identifying a specific reported illness and a corresponding specific geographic location, at least one of the records further including a verification flag indicating verification of the specific reported illness; displaying, via the display device, a map of the particular geographical region, the map including a plurality of markers, each marker corresponding to a respective one of the plurality of records, each marker being displayed in a location corresponding to the respective specific geographic location identified in a corresponding record; and displaying, via the display device, a verification indicator in association with each marker for which the corresponding one of the plurality of records includes a respective verification flag.
According to another aspect, the present invention provides a verified illness state tracking system comprising a VISCS and a VISRS.
Also provided is a computer program product for implementing a method for correlating disparate datasets to verify illness reports, the computer program product comprising a non-transitory computer-readable medium storing executable instructions that, when executed by a processor, cause a computerized system to perform a method for correlating disparate datasets to verify illness reports.
Provided also is a computer program product for implementing a method for displaying verified illness reports, the computer program product comprising a non-transitory computer-readable medium storing executable instructions that, when executed by a processor, cause a computerized system to perform a method for displaying verified illness reports.
An understanding of the following description will be facilitated by reference to the attached drawings, in which:
The present invention relates to a system and method for reporting of illness states in a verified manner. Generally, the present invention provides a system and method that receives multiple data feeds, collectively including illness report data from disparate data sources, and correlates disparate data sets from the disparate data sources to provide verified reporting of illness states. In a preferred embodiment, the verified reporting is provided in the form of a geographical mapping of reported illness states displayed via a graphical user interface displayed by a computerized device, such that the mapping includes a visual indication of whether a mapped reporting from one data set is verified by being consistent with data from a disparate data set.
An exemplary embodiment of the present invention is discussed below for illustrative purposes.
The present invention may be understood with reference to the exemplary simplified network environment 10 of
As further illustrated in
As further illustrated in
In this exemplary embodiment, the VISCS 100 is operatively connected to the each VISRS 70a, 70b, and to the Healthcare Provider Data Reporting System 90 and Social Media Content Data Reporting System 80, via a communications network 50, such as the Internet and/or a Virtual Private Network (VPN) connection. Hardware and software for enabling communication of data by such devices via such communications networks are well known in the art and beyond the scope of the present invention, and thus are not discussed in detail herein.
Accordingly, the exemplary VISCS 100 of
The VISCS 100 may communicate with other computers or networks of computers, for example via a communications channel, network card or modem 122. The VISCS 100 may be associated with such other computers in a local area network (LAN) or a wide area network (WAN), and may operate as a server in a client/server arrangement with another computer, etc. Such configurations, as well as the appropriate communications hardware and software, are known in the art.
The VISCS 100 is specially-configured in accordance with the present invention. Accordingly, as shown in
The VISRS may include conventional computing device hardware typical of a mobile computing device 70a or desktop computing device (PC) 70b. Any suitable computing devices may be used for the purposes described herein. By way of example, the mobile computing device may be a smartphone, a tablet computer, or the like. Each VISRS 70a, 70b is specially-configured in accordance with the present invention. Each VISRS includes conventional hardware and software and is able to communicate with the VISCS 100, and further includes software (such as a mobile “app”) for configuring the computing device 70a, 70b to communicate with the VISCS 100 and to provide a graphical user interface for displaying a verified report of illness states to a user, in accordance with the present invention.
Each VISRS 70a, 70b includes components similar to those described above in relation to
The data store 160 further stores Social Media Content Data 166. The Social Media Content Data is made up of data records, each of which includes data indicating a symptom or illness (e.g., “cough” or “runny nose”), a specific location (e.g., street address or latitude/longitude coordinate), and a timestamp (e.g., date/time). This information is, at least in part, extracted form user-generated postings to social media websites/platforms. By way of example, this information may be provided via a commercially-available data feed communicated to the VISCS 100 via the network 50. For example, a commercially-available data feed from Sickweather.com includes a data record indicating a mentioned illness type, and a geographical location, such as latitude and longitude coordinates, indicating a location determined to correspond to the mentioned illness, and a timestamp providing a date/time value. For example, such a record may be provided as XML-formatted content including an illness-identifying code and numerical values indicating latitude and longitude positions within a coordinate system, and a date/time value indicating a time of the mention/social media posting. In certain embodiments, the data records may be provided in response to an API call (e.g., a GET MARKERS call) for recent or geographically-limited records.
The Verification Engine 150 includes a Report Correlation Engine 152 that is responsible for comparing Social Media Content Data 166 with Healthcare Provider Data 162 to determine whether the healthcare provider-derived data corroborates or is otherwise consistent with the social media content-derived data. The Report Correlation Engine 152 may be implemented by suitable software stored in the memory of the VISCS 100. If the provider-reported data corroborates the individual's social mention of an illness/condition/symptom, then in accordance with the present invention the individual's report is considered to be verified, and thus more reliable or persuasive.
The Report Correlation Engine 152 stores the results of its analysis as Verified Illness State Data 168 in the data store 160. The Verified Illness State Data includes data records, each of which includes an illness state identifier, a location (e.g., latitude and longitude coordinates), and an indication of whether the corresponding illness report has been verified by confirming that the reported illness is consistent with a Healthcare Provider Data. In this example, the indication is a verification flag associated with illness report data. This data (or a geographically-relevant portion of this data) is shared with users' VISRS 70 devices (e.g., smartphones running a corresponding app), so that a geographical mapping of the illness state data may be provided, along with a visual indication of whether each report is verified in that data from one data set is consistent with data from the other. The functioning of the Verification Engine (and its component engines) is discussed below with reference to
Referring again to
In a simple example, the Association Engine 154 may match a report of ILI from the Healthcare Provider Data (reflecting terminology consistent with an insurance claims processing taxonomy) with a report of “flu” or “influenza” from the Social Media Content Data (reflecting terminology used by a layperson, and further may match both of these to a tracked “FLU” illness state. In this case, the matching is relatively straightforward, since both datasets specifically reference influenza in one form or another.
In a more complex example, the Association Engine 154 includes more complex logic for resolving ambiguous relationships. For example, the Association Engine 154 may process the data records of the Healthcare Provider Data 162 and determine which individual symptoms (e.g., “cough”, “runny nose” etc.) are associated with the various illnesses (e.g., “influenza-like illness”) identified in the Healthcare Provider Data 162. This may be done according to predetermined logic of the Association Engine. Similarly, the Association Engine may associate a Social Media Content Data report of “runny nose” with “ILI” (in the Healthcare Provider Data) and the “FLU” illness state.
In certain embodiments, the VISCS and/or VISRS system provides a graphical user interface permitting an operator to specify weightings for each illness/condition/symptom (hereinafter “symptom”). In such embodiments, the operator-provider symptom weightings are stored as symptom weighting data 174 in the data store 160, and referenced by the Association Engine 154 and are used to allocate the reports, as will be appreciated from
In this exemplary embodiment, the Verification Engine 150 further includes a Trend Determination Engine 156, which may be implemented by suitable software stored in the memory of the VISCS 100. The Trend Determination Engine 156 is responsible for determining illness trends from the Healthcare Provider Data. More specifically, the Trend Determination Engine 156 processes the data records of the Healthcare Provider Data 162 and determines trends, over time, for each illness identifier, for each region. This may be performed in any suitable fashion. In one embodiment, severity index values (e.g., 0-12), for one or more preceding days, are provided in the Healthcare Provider Data. Further, the daily severity index values may be tracked and stored over time for successive days, and may be stored in a memory of the VISCS 100. In such an embodiment, the Trend Determination Engine 156 compares the severity index values over a plurality of days to determine a trend (e.g., rising, falling, or unchanging) for each illness, for each region. The Trend Determination Engine is configured with logic for determining how much of a change will be taken to be an indication of a change in trend. In one example, the Trend Determination Engine compares a preceding day's index value (e.g., 8), or an average of a predetermined number of days' index values (e.g., 8.3) to a current day's index value (e.g., 10) to determine the trend (e.g., rising). The determined trend information is stored by the Trend Determination Engine 156 as Regional Trend Data 164 in the data store 160, as shown in
Next, the Verification Engine 150 processes the Social Media Content Data. This is performed iteratively, starting with a first Social Media Content Data record, as shown at 308 in
Next, the Verification Engine 150 identifies a market region corresponding to the geographic location of the mentioned illness, as shown at 310. This may be performed by the Report Correlation Engine 152. For example, if the first Social Media Content Data record identifies specific latitude and longitude coordinates, these coordinates may be resolved to a particular town (e.g., Fort Washington, Pa.), and the town may be determined to be within one of a predetermined plurality of predefined market regions (e.g., Philadelphia metropolitan area)—namely, one of the market regions that appear in the healthcare provider data. These steps may be performed by the Report Correlation Engine 152.
Next, it is determined if the mentioned illness (from the Social Media Content Data) corresponds to a provider-reported illness (from the Healthcare Provider Data), as shown at 312. This performed by the Association Engine 154. For example, if a Social Media Content Data record indicates a “Flu” illness for a particular location (or a “fever” symptom that is associated with “Flu” by the Association Engine 154), and Healthcare Provider Data includes reports of “Flu” or “ILP”, then it is determined that the mentioned illness corresponds to a reported illness at 312.
If it is determined at 312 that the mentioned illness (e.g. “tired”, or “aches” or “feeling lousy”) does not match a reported illness, then the mentioned illness and the corresponding geographic location information from the Social Media Content Data are stored in the Verified Illness State Data 168, as shown at 322. Notably, this information is stored without an indication of verification/corroboration by the data in another data set. However, this information is stored so that it may be received and displayed, in unverified fashion, on an illness mapping, as discussed further below.
If, however, it is determined at 312 that the mentioned illness does match a reported illness, then the Verification Engine 150 (e.g., the Report Correlation Engine 152) next identifies a current severity level for the corresponding reported illness in the corresponding market region, as shown at 314. For example, the Healthcare Provider Data may indicate a daily severity index value of 10 for “Flu” in the Philadelphia metropolitan market region.
Next, it is determined whether the relevant severity level (e.g., 8) exceeds a predetermined threshold value, as shown at 316. This is performed by the Report Correlation Engine 152 using a threshold value that may be built into the logic of the Report Correlation Engine 152, or may be a user-configurable setting. The threshold value is selected such that a current index value above the threshold reflects prevailing/current conditions such that it is characteristic of the region, and should result in verification of the social mention of illness. For example, if today's severity value (from Healthcare Provider Data) is 10 for the Philadelphia metropolitan market region, and 10 exceeds a predetermined threshold value of 8, then an individual's social mention of flu at a geographic location within the Philadelphia metropolitan market region will result in the social mention report being considered verified by the Healthcare Provider Data.
If the current severity level does not exceed the predetermined threshold, then the mentioned illness and corresponding location data will be stored in the Verified Illness State Data 168, in unverified fashion, as shown at 322. Accordingly, this information is stored so that it may be received and displayed, in unverified fashion, on an illness mapping, as discussed further below.
If, however, the current severity level does exceed the predetermined threshold, then the mentioned illness, corresponding location data and a verification flag will be stored in the Verified Illness State Data 168, as shown at 318. Accordingly, this information is stored so that it may be received and displayed, in verified fashion, on an illness mapping, as discussed further below.
This is repeated for subsequent reported illnesses. Accordingly, the method next involves determining whether the considered reported illness is the last reported illness for the given geographical region, as shown at 320. If so, then the next reported illness is considered, as shown at 324. If not, then the next market region is considered. Either way, flow then returns to 308, where a next mentioned illness is considered, and the process repeats for all mentioned illnesses from the Social Media Content Data. Notably, the entire process of
In certain embodiments, the Trend Determination Engine 156 determines severity trends as an aggregation of changing severity values in both disparate data sets. By way of example, consider two disparate datasets, namely, a healthcare provider (HCP) data set and a social media content (SMC) data set, each of which reports numerical illness/severity values for each day (or other period) in a particular region. Accordingly, consider that VHCP,i is the reported value for period i, and VHCP,j is the reported value for period j (for the same region). In that case, an average daily trend may be reflected as percentage of change by averaging change vectors for both datasets. By way of example, this may be calculated as follows:
where V is the average percentage change in severity values
HCP is the healthcare provider severity value
SMC is the social media content data severity value
where l, j, k, l and o represent respective time periods (e.g., dates)
where k>l, j>l, and o≠k≠j
In certain other embodiments, the Trend Determination Engine 156 determines trends as a recency-weighted aggregation of severity index values. By way of example, the recency-weighted aggregation may be expressed as percentage of change as weighted by a number of days. The aggregation accounts for disparate trends in disparate data sets, and/or for the asynchronous reporting intervals of the disparate healthcare provider data and social media content data sets. The recency-weighted determination of trends provides greater weight to more recent illness reports, as they are deemed to better reflect current conditions. By way of example, a recency-weighted trend may be calculated as follows:
where V is the percentage change in values of illness values with a recency-weighting providing greater emphasis on recent data/trends
HCP is the healthcare provider severity value
SMC is the social media content data
where l, j, k, l and o represent respective time periods (e.g., dates)
where k>l, j>l, and o≠k≠j
In certain embodiments, the Report Correlation Engine 152 further includes logic for characterizing quantitative index values (stored as Regional Trend Data 164) as qualitative severity measures (e.g., 0-3 is low severity, 3-6 is mild severity, 6-9 is high severity, and 9-12 is extreme severity). These severity characterizations may be stored with the Verified Illness State Data 164 (or elsewhere) for display by the reporting engine 180 as discussed below.
Accordingly, disparate data sets are received by the VISCS 100 and are processed to create the Verified Illness State Data 168 at the VISCS 100. Thus, the illness state correlation application of the VISCS 100 processes disparate data sets to determine correlations between reported illnesses on a location-specific basis to distinguish verified reported illnesses for which there is corroborating information in both data sets, and thus higher relevance, from reported illnesses lacking such corroborating information, and thus having lower relevance.
An individual's VISRS 70 is specially configured with software for displaying at least a relevant portion of the Verified Illness State Data 168. The VISRS 70 includes a Reporting Engine 180 that is responsible for processing received Verified Illness State Data 188 (or at least that portion of it received by the Reporting Engine 180).
The Reporting Engine 180 includes a Graphical User Interface (GUI) Management Engine 182, Dashboard Management Engine 184, Mapping Engine 186 and Personalized Content Engine 192, which may be implemented by suitable software stored in the memory of the VISRS 70 in accordance with the present invention.
The GUI Management Engine 182 interacts with the remaining engines and is responsible for managing a GUI for displaying information to a user via a display device of the VISRS, and for receiving user input via input devices of the VISRS. User input may be stored as user data 190 in a memory of the VISRS 70.
The Mapping Engine 186 determines a current geographical location of the device (e.g., by accessing GPS data available via the device OS), or a selected geographical location (received as user input via the GUI Management Engine 182), and retrieves a relevant portion of Verified Illness State Data 188 corresponding to that location, which is stored in memory of the VISRS 70. For example, if the Mapping Engine determines that the relevant portion includes data for the Philadelphia metropolitan region, the Mapping Engine 186 will retrieve that portion. The Mapping Engine 186 is responsible for creation of an image displaying a mapping 210 of the relevant portion of the Verified Illness State Data 188, as shown in
The Mapping Engine 186 creates a mapping that includes not only markers positioned in a location-appropriate images on a map, but also includes a visual indicator indicating whether the illness report corresponding to an associated marker has been verified, by consistency with a second data set. Accordingly, a user viewing the mapping can tell which illness reports are verified, and which are not, by browsing the map. For example,
Accordingly, the reported illnesses are indicated by markers displayed on the map of the particular geographical region of interest via the display device of the computerized system, and reported illnesses supported by corroborating information in the disparate data sets are indicated by verification indicators displayed on the map in association with such markers. Thus, reported illnesses are processed programmatically by the illness state reporting application and are displayed on a geographically-relevant basis in differentiated fashion to provide a visual indication of verified and unverified reported illnesses via the display device of the computerized system when the illness state reporting application is active on the computerized system.
In certain embodiments, the markers are coded—e.g., by color and/or shape, to convey a severity level associated with the healthcare provider data. For example, data indicating a severity level of 0-3 may be shown with a blue marker, and a severity level of 9-12 may be shown with a red marker.
The Dashboard Management Engine 184 receives user data and communicates with the GUI Management Engine 182 to cause display of customized alerts. The alerts are customized for the relevant geographical region being displayed in the graphical user interface window. If the geographical region being displayed includes more than one market region, severity indices and/or trends may be aggregated (e.g., by averaging values/trends for each market) for the various market regions shown.
The Dashboard Management Engine 184 is further responsible for communicating with the GUI Management Engine 182 to cause display of infographics in a dashboard panel 220. Each exemplary infographic 280 includes a current severity indicator. In the example of
Further, the Dashboard Management Engine 184 is responsible for displaying a trend indicator in the dashboard panel 220. In the example of
The Personalized Content Engine 192 receives user data and communicates with the GUI Management Engine 182 to cause display of relevant information content 260. For example, if the user is concerned about allergies, the user may choose to receive a display of personalized information content including allergy-related information.
It will be noted from
It is noted that the exemplary embodiment(s) discussed above relate to a limited context of Cold, Flu and Allergy illness states. However, it should be appreciated that the present invention may be used for a variety of other states/illness states, and in a variety of other contexts. By way of example, the present invention can be applied in the contexts of sun/skin care, oral care, pediatric care, etc.
Additionally, computer readable media storing computer readable code for carrying out the method steps identified above is provided. The computer readable media stores code for carrying out subprocesses for carrying out the methods described herein.
A computer program product recorded on a computer readable medium for carrying out the method steps identified herein is provided. The computer program product comprises computer readable means for carrying out the methods described above.
While there have been described herein the principles of the invention, it is to be understood by those skilled in the art that this description is made only by way of example and not as a limitation to the scope of the invention. Accordingly, it is intended by the appended claims, to cover all modifications of the invention which fall within the true spirit and scope of the invention.
This application claims the benefit of priority, under 35 U.S.C. §119(e), of U.S. Provisional Patent Application No. 62/158,821, filed May 8, 2015, the entire disclosure of which is hereby incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62158821 | May 2015 | US |
