Patent Application
20220020498
Electronic healthcare records (EHR) are generated and stored according to various company-specific, product-specific, or standardized data models, such as HL7 and FHIR. But healthcare software applications may use variants of standard data models or customized data models that are not openly available. Moreover, EHR health data is often fragmented, but still growing more so by the day. Consequently, stakeholders (e.g., patients, insurers, care providers, employers) do not have access to comprehensive datasets that needed to control health outcomes, and consumers historically have not had any access to their own health data. Additionally, as user devices and products moving into a digital age where consumers can access fitness, nutrition, diagnosis and have medical encounters all online through a growing number of platforms and providers, there is a growing need for data to be aggregated and standardized across disparate data sources.
The usage of this aggregated and standardized health care data is in its infancy as well. Determining useful information and actionable recommendations for a user related to their health care can be incredibly difficult, given the increasing amount of data from disparate data sources about individuals and their healthcare data.
The following detailed description references the drawings, wherein:
The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar parts. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only. While several examples are described in this document, modifications, adaptations, and other implementations are possible. Accordingly, the following detailed description does not limit the disclosed examples. Instead, the proper scope of the disclosed examples may be defined by the appended claims.
Electronic healthcare records (EHR) are generated and stored according to various company-specific, product-specific, or standardized data models, such as HL7 and FHIR. But healthcare software applications may use variants of standard data models or customized data models that are not openly available. Moreover, EHR health data is often fragmented, but still growing more so by the day. Consequently, stakeholders (e.g., patients, insurers, care providers, employers) do not have access to comprehensive datasets that needed to control health outcomes, and consumers historically have not had any access to their own health data. Additionally, as user devices and products moving into a digital age where consumers can access fitness, nutrition, diagnosis and have medical encounters all online through a growing number of platforms and providers, there is a growing need for data to be aggregated and standardized across disparate data sources.
The usage of this aggregated and standardized health care data is in its infancy as well. Determining useful information and actionable recommendations for a user related to their health care can be incredibly difficult, given the increasing amount of data from disparate data sources about individuals and their healthcare data.
Examples disclosed herein provide technical solutions to these technical challenges by dynamically evaluating health care risk in an automated way that enables health care action recommendations for a user based on their healthcare profile and healthcare decision tree, and based on the profiles and healthcare decision trees of other users similar to that user. By determining cohorts of users that have a similar healthcare decision tree to the user, a health care risk evaluation system may determine health care actions that may be better suited for the user based on the effects of those health care actions on the cohorts of similar users and the trajectories of their healthcare decision trees after performing those health care actions. As such, these technical solutions correlate healthcare decision trees between users to understand historical success related to similar people and applies that historical success to the health care action recommendations. The solutions described herein enable an improved and effective analysis and recommendation of health care actions from complicated, large data sets related to users, health care, pharmacy, insurance, providers, and other medical data related to managing user health care. Further, the technical solutions disclosed herein also enable optimization of the health care recommendations for a user in a myriad of ways.
Some examples disclosed herein to dynamically evaluate health care risk include creating, for a set of users, a corresponding set of digital healthcare profiles, where each digital healthcare profile includes a healthcare decision tree for the corresponding user; determining, for a first user of the set of users, a first subset of the set of users with a first set of similar digital healthcare profiles based on the corresponding set of healthcare decision trees; determining, based on correlation between a first healthcare decision tree of the first user with the first set of healthcare decision trees of the first subset of users, a first recommended action for the first user; providing, to the first user, information related to the first recommended action; updating, for a second user in the first subset of users, a second digital healthcare profile and second healthcare decision tree of the second user; determining, based on the updated second healthcare decision tree of the second user, that the updated second healthcare decision tree deviates from the first set of healthcare decision trees; removing, based on the determined deviation, the second user from the first subset of users; determining, based on the updated first set of digital healthcare profiles, a second recommended action to the first user; and providing, to the first user, information related to the second recommended action.
Some of the examples disclosed herein to dynamically evaluate health care risk include a system comprising a physical processor implementing machine readable instructions that cause the system to: create, for a set of users, a corresponding set of digital healthcare profiles, where each digital healthcare profile includes a healthcare decision tree for the corresponding user; determine, for a first user of the set of users, a first subset of the set of users with a first set of similar digital healthcare profiles based on the corresponding set of healthcare decision trees; determine, based on correlation between a first healthcare decision tree of the first user with the first set of healthcare decision trees of the first subset of users, a first recommended action for the first user; provide, to the first user, information related to the first recommended action; update, for a second user in the first subset of users, a second digital healthcare profile and second healthcare decision tree of the second user; determine, based on the updated second healthcare decision tree of the second user, that the updated second healthcare decision tree deviates from the first set of healthcare decision trees; remove, based on the determined deviation, the second user from the first subset of users; determine, based on the updated first set of digital healthcare profiles, a second recommended action to the first user; and provide, to the first user, information related to the second recommended action.
Some examples disclosed herein to dynamically evaluate health care risk include a non-transitory machine-readable storage medium comprising instructions executable by a physical processor of a computing device for dynamically evaluating health care risk, the machine-readable storage medium comprising: instructions to create, for a set of users, a corresponding set of digital healthcare profiles, where each digital healthcare profile includes a healthcare decision tree for the corresponding user; instructions to determine, for a first user of the set of users, a first subset of the set of users with a first set of similar digital healthcare profiles based on the corresponding set of healthcare decision trees; instructions to determine, based on correlation between a first healthcare decision tree of the first user with the first set of healthcare decision trees of the first subset of users, a first recommended action for the first user; provide, to the first user, information related to the first recommended action; instructions to update, for a second user in the first subset of users, a second digital healthcare profile and second healthcare decision tree of the second user; instructions to determine, based on the updated second healthcare decision tree of the second user, that the updated second healthcare decision tree deviates from the first set of healthcare decision trees; instructions to remove, based on the determined deviation, the second user from the first subset of users; instructions to determine, based on the updated first set of digital healthcare profiles, a second recommended action to the first user; and instructions to provide, to the first user, information related to the second recommended action.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term “plurality,” as used herein, is defined as two or more than two. The term “another,” as used herein, is defined as at least a second or more. The term “coupled,” as used herein, is defined as connected, whether directly without any intervening elements or indirectly with at least one intervening elements, unless otherwise indicated. Two elements can be coupled mechanically, electrically, or communicatively linked through a communication channel, pathway, network, or system. The term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will also be understood that, although the terms first, second, third, etc. may be used herein to describe various elements, these elements should not be limited by these terms, as these terms are only used to distinguish one element from another unless stated otherwise or the context indicates otherwise. As used herein, the term “includes” means includes but not limited to, the term “including” means including but not limited to. The term “based on” means based at least in part on.
The various components (e.g., components 129, 130, and/or 140) depicted in
According to various implementations, health risk evaluation system 110 and the various components described herein may be implemented in hardware and/or a combination of hardware and programming that configures hardware. Furthermore, in
Health risk evaluation system 110 may comprise a digital healthcare profile engine 121, a similarity engine 122, a recommendation engine 123, and/or other engines. In some examples, health risk evaluation system 110 may also comprise a vendor management engine 124, and/or other engines. The term “engine”, as used herein, refers to a combination of hardware and programming that performs a designated function. As is illustrated respect to
Digital healthcare profile engine 121 may manage medical data related to a set of users. The medical data may comprise patient data, provider data, insurer data, lab data, wearable device data, pharmacy data, and/or other data related to health of a user. The medical data may be obtained from numerous sources, with similar or different formats of data. The digital healthcare profile engine 121 may standardize and create a healthcare digital profile (e.g., a digital health record) for each user of the health risk evaluation system 110, as described in U.S. patent application Ser. No. 15/800,772. For example, the digital healthcare profile engine 121 may anonymize and aggregate the digital health care records of each user to create the healthcare digital profile. In some of these examples, personally identifiable information may be kept separate from the healthcare digital profile. Given that, the data in the healthcare digital profile is anonymized, and any calculations, aggregations, statistics, and/or other analysis may be performed on the anonymized healthcare digital profile.
The digital healthcare profile engine 121 may generate and manage a healthcare decision tree for each user as well, where a healthcare decision tree may be part of the healthcare digital profile for each user. The healthcare decision tree for a user may comprise information about a set of actions. An action may comprise, for example, a recommendation, a doctor's visit, prescription, refill, exercise, weight change, activity, and/or other act. The information about an action may comprise, for example, a date of the action, time of the action, title for the action, description of the action, indicator of whether the action was performed or not, provider(s) associated with the action, insurer(s) associated with the action, lab result(s) associated with the action, prescription(s) associated with the action, other user(s) associated with the action, and/or other data related to the action. The healthcare decision tree for a user may represent a chronological order of actions based on a date/time of each action.
In some examples, information about an action may also comprise a score associated with the action. The score may indicate: a state of health associated with the action, a health care cost associated with the action, a state of health associated with the health care decision tree up until that action, a health care cost associated with the health care decision tree up until that action, a priority related to the performance of the action, likelihood of engagement in the action, motivation to perform the action, health history associated with the action, treatment risk associated with the action, mortality rate associated with performing the action, mortality rate associated with not performing the action, life expectancy associated with performing the action, life expectancy associated with not performing the action, patient satisfaction associated with performing the action, patient satisfaction associated with not performing the action, total cost associated with performing the action, total cost associated with not performing the action, user preference associated with performing the action, health care provider preference associated with performing the action, and/or other factors related to the action. In some examples, a score associated with an action may be determined based on calculating and/or aggregating multiple level of scores. In these examples, the factors related to mortality rate, life expectancy, total cost, and/or other factors may be treated as a set of sub-scores that can be aggregated or otherwise used to determine an overall score for the health care cost associated with the action.
In some examples, a score or sub-score may be determined based on machine learning by the system, user interaction with actions along the user's healthcare decision tree, user preferences, user demographics, average scores of actions or healthcare decision trees users with similar healthcare decision trees, hashing, statistical measures, regressions, classifiers, clusterings, Bayesian methods, a user's engagement with gamification provided by the system 110, any combination thereof, and/or other mathematical calculations. In some examples, the score for an action, and/or each sub-score associated with the action, may be weighted based on machine learning by the system, user interaction with actions along the user's healthcare decision tree, user preferences, user demographics, average scores of actions or healthcare decision trees users with similar healthcare decision trees, hashing, statistical measures, regressions, classifiers, clusterings, Bayesian methods, a user's engagement with gamification provided by the system 110, any combination thereof, and/or other mathematical calculations. Scores and/or weights may be updated responsive to changes in a healthcare decision tree of the user or other user in the system, other change in data in the system, and/or other factor.
In some examples, the healthcare decision tree may also comprise relationships between actions. For example, a relationship between a set of actions may comprise actions linked to each other based on one action resulting in another action. In one example, a set of linked actions may include a doctor visit, a prescription, a test, lab result(s) from the test, and/or other actions linked to the doctor visit. In another example, a set of linked actions may comprise actions associated with a condition that the user has, including recommended exercise actions as part of a treatment for the condition, a set of weight recordings obtained at specific time intervals, a set of symptom data related to the condition that are obtained at specific time intervals, and/or other data related to the condition and recommended treatment. In some examples, the actions between the doctor visit and the condition may be linked as well. The links may comprise different types of links that indicate a type of relationship of the link, such as symptoms, treatments, time-based, activity-based, recommendation-based, and/or other type of relationship. In some examples, there may be multiple types of links between actions.
As such, the healthcare decision tree may include information about the healthcare journey of the user, with actions and dates/times of the actions, related to the health of the user and related to other users based on different types of links. In some examples, the relationships between actions may also be scored, with sets of scores/sub-scores, in a manner the same as or similar to scoring an individual action described above. In some examples, the healthcare decision tree may be scored as well, with sets of scores/sub-scores, in a manner the same as or similar to scoring an individual action or relationships between actions described above.
The digital healthcare profile engine 121 may update the healthcare decision tree of a user based on received data about a doctor's visit, prescription filling, exercise undertaken, weight change, activity level, performance of a recommended action, and/or other change or addition of an action by the user. The digital healthcare profile engine 121 may update the healthcare decision tree for a user continuously, as actions are recommended, performed, removed, and/or otherwise changed for the user. In some examples, the digital healthcare profile engine 121 may update the healthcare decision tree of a user based on receipt of data from one or multiple numerous sources of data from which medical data is obtained by the digital healthcare profile engine 121.
The similarity engine 122 may determine, for a first user of the set of users, a first subset of users with a first set of similar digital healthcare profiles. The similarity engine 122 may determine the first subset of users (among the set of users) based on a similarity of the healthcare decision trees of the first subset of users with the first user. In some examples, the similarity engine 122 may normalize each of the healthcare decision trees of the users of the health risk evaluation system 110, and may determine a similarity of the healthcare decision trees with the first user based on one or multiple metrics related to the normalized healthcare decision trees.
In some examples, the similarity engine 122 may determine similarity of a healthcare decision tree by hashing, statistical measures, regressions, classifiers, clusterings, Bayesian methods, any combination thereof, and/or other mathematical calculations. In some examples, the similarity engine 122 may use data science, machine learning, artificial intelligence, and/or other mathematical calculations to determine a similarity of the healthcare decision trees. For example, the similarity engine 122 may consider actions of the healthcare decision tree, attributes of the digital healthcare profile, metadata related to the decision tree, metadata related to the profile, and/or other data in the system 110 to determine a similarity of the healthcare decision trees.
In some of these examples, the similarity engine 122 may determine how many actions are similar between the healthcare decision trees, and may determine how many differ. The differing actions may be considered inflection points, and the similarity engine 122 may determine whether the one or multiple inflection points between two healthcare decision trees are different enough that they would not be considered similar. In some of these examples, the similarity engine 122 may determine similarity based on statistically significant closeness of the healthcare decision trees. In some of these examples, the similarity engine 122 may determine similarity based on a subset of healthcare decision trees within a standard deviation, a predetermined statistically significant amount, and/or other similarity metric. The similarity engine 122 may use a predetermined threshold for each of the one or multiple metrics used to determine whether a healthcare decision tree is similar to the first healthcare decision tree of the first user.
In some examples, the similarity engine 122 may determine multiple sets of similar healthcare decision trees to the first healthcare decision tree of the first user. The similarity engine 122 may determine each set of similar healthcare decision trees based on one or multiple actions in the user's healthcare decision tree, one or multiple sets of linked actions, and/or based on other factors. For example, as shown in
Returning to
In some examples, upon a healthcare decision tree being updated (e.g., with a new healthcare action, with updated data related to an existing healthcare action, etc.), the similarity engine 122 may determine that the updated healthcare decision tree that had been considered similar has deviated from the set of similar healthcare decision trees based on the one or multiple metrics applied to an updated metric. For example, the similarity engine 122 may determine that the updated healthcare decision tree is statistically significantly different from the set of healthcare decision trees similar to the first healthcare decision tree, may determine that the updated healthcare decision tree is statistically closer to a different set of healthcare decision trees, and/or may otherwise determine that the updated healthcare decision tree deviates from the set of healthcare decision trees similar to the first healthcare decision tree.
Recommendation engine 123 may determine, based on the correlation between the first healthcare decision tree and the set of similar healthcare decision trees, a first recommended action for the first user. In some examples, recommendation engine 123 may determine the first recommended action for the first user from a set of recommended actions determined by the engine 123. In some examples, a recommended action may include one or more of: providing recommended healthcare information, providing information about healthcare providers, providing a healthcare challenge, providing a survey, optimizing the order of the set of recommendations, ranking the set of recommendations for the first user, and/or otherwise interacting with the first user via the system 110 to enable better healthcare. The recommended actions are not limited to the examples provided herein.
First, the recommendation engine 123 may determine a set of existing actions in the first user's healthcare decision tree from which to provide recommendations. For example, the recommendation engine 123 may select one or multiple actions to provide recommendations about, based on an action or set of related actions being stored or updated within a predetermined time period, an action or set of related actions having a score or sub-score related to a metric above a predetermined threshold, a user- or provider-initiated request for recommended actions, an action or set of related actions triggering an determination that a recommendation is required to be provided, a treatment plan related to the action or set of related actions, a system-generated determination that a recommendation should be provided for an action or set of related actions, and/or based on other factors.
The recommendation engine 123 may provide one or multiple actions in response to each action in the set of selected actions. The recommendation engine 123 may determine the one or multiple actions based on stored treatment plans, actions recommended or undertaken by users with similar healthcare decision trees, scores or other metrics related to the actions, and/or based on other factors. In addition to or in lieu of this, the recommendation engine 123 may use machine learning, decision trees, data science, statistical regressions, clustering, any of the above, and/or other mathematical or statistical models to determine the one or multiple actions in response. In addition to or in lieu of this, the recommendation engine 123 may determine the one or multiple actions based on a determined cost of a predicted health care decision tree after performing the recommended action.
In some examples, responsive to determining the one or multiple actions, the recommendation engine 123 may determine which action to provide to the user based on prioritizing the determined one or multiple actions. The recommendation engine 123 may prioritize the one or multiple actions based on a score associated with the action, a score associated with the related actions to that action, a cost associated with each of the one or multiple actions, user preferences related to the actions, any combination thereof, and/or other factors related to the one or multiple actions. In some examples, the recommendation engine 123 may determine priorities related to the one or multiple actions based on each user, such that the same action may have a different priority for a first user than a second user.
In some examples, the recommendation engine 123 may provide multiple actions to the user. In some examples, the recommendation engine 123 may provide the first n recommendations based on priority, a subset of recommendations where the associated score of each recommendation is greater than a predetermined number, a first subset of recommendations ordered by priority where the total score of all of the recommendations in the subset is equal to or less than a predetermined number, and/or other configurations of a subset of the recommendations. In these examples, the number of actions recommended to a user may vary based on the criteria used to determine which multiple actions to recommend.
The recommendation engine 123 may provide information related to the action from the one or multiple actions with a highest priority based on the determined priorities associated with each of the one or multiple actions. The information related to the action may comprise, for example, a title related to the action, a description related to the action, a status of the action, a set of providers with performing the action, a set of treatments with performing the action, a set of users associate with performing the action, a date range within which the action is to be performed, information to be input to the system related to performing the action, and/or other information related to the action.
In some examples, the health risk evaluation system 110 may include a vendor management 124 engine. In response to the recommendation engine 123 determining an action or set of actions to provide to the user, the vendor management engine 124 may determine, for each action to be provided, a third party vendor (e.g., a doctor, health care provider, insurer, pharmacy, fitness provider, dietician, and/or other entity associated with the health of a user) is associated with the action. In some examples, the vendor management engine 124 may determine no vendor is needed in association with performing the action. In other examples, the vendor management engine 124 may identify a single vendor associated with performing the action, or multiple sub-actions of the action that could each involve a third party vendor. For each identified vendor, the vendor management engine 124 may identify a vendor type (e.g., medical professional, insurer, pharmacy, fitness provider, and/or other entity type associated with health of a user).
Responsive to determining each vendor and vendor type associated with the action, the vendor recommendation engine 124 may provide a vendor recommendation associated for each vendor and vendor type. In some examples, data store 129 stores information related to each third party vendor associated with the health risk evaluation system 110, including, for example, vendor name, vendor id, vendor type, vendor address, vendor description, vendor capabilities, actions associated with the vendor, schedule of the vendor, ratings provided by users of the system for the vendor, feedback provided by users of the system for the vendor, pricing of the vendor, user(s) that have engaged with the vendor, third party(ies) associated with the vendor, insurance information related to the vendor, and/or other information related to the vendor. The vendor recommendation engine 124 may determine based on the action or sub-action involving a vendor, the vendor information stored by the system 110, and/or other considerations, a set of vendors to recommend to the user.
In some examples, the vendor management engine 124 may determine a recommended vendor of the determined set of vendors for each of the action/sub-actions that involve third party vendors. For example, the vendor management engine 124 may determine the recommended vendor based on a set of metrics associated with each of the set of vendors. The vendor management engine 124 may generate the set of metrics based on the results of one or multiple tests applied to each vendor. The vendor management engine 124 may determine the one or multiple tests to apply to a vendor based on the vendor type associated with the vendor.
In some examples, the vendor management engine 124 may run the one or multiple tests after providing a recommendation of the vendor to a user for the involved action/sub-action, may determine the results and store the results as metrics related to the vendor. In some examples, the vendor management engine 124 actively solicit feedback from users that have engaged with the vendor. In some of these examples, the vendor management engine 124 may determine baseline parameters and thresholds for the metrics stored, and compare the results of the vendor to the baseline parameters and thresholds. In some examples, the vendor management engine 124 may determine the baseline parameters and thresholds based on hashing, statistical measures, regressions, classifiers, clustering, Bayesian methods, machine learning, any combination thereof, and/or other mathematical calculations.
In
Returning to
Data storage 129 may include a database to organize and store data. The database may reside in a single or multiple physical device(s) and in a single or multiple physical location(s). The database may store a plurality of types of data and/or files and associated data or file description, administrative information, or any other data.
In the foregoing discussion, engines 121-124 were described as combinations of hardware and programming. Engines 121-124 may be implemented in a number of fashions. Referring to
In
Machine-readable storage medium 410 may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. In some implementations, machine-readable storage medium 410 may be a non-transitory storage medium, where the term “non-transitory” does not encompass transitory propagating signals. Machine-readable storage medium 410 may be implemented in a single device or distributed across devices. Likewise, processor 411 may represent any number of processors capable of executing instructions stored by machine-readable storage medium 410. Processor 411 may be integrated in a single device or distributed across devices. Further, machine-readable storage medium 410 may be fully or partially integrated in the same device as processor 411, or it may be separate but accessible to that device and processor 411.
In one example, the program instructions may be part of an installation package that when installed can be executed by processor 411 to implement health risk evaluation system 110. In this case, machine-readable storage medium 410 may be a portable medium such as a floppy disk, CD, DVD, or flash drive or a memory maintained by a server from which the installation package can be downloaded and installed. In another example, the program instructions may be part of an application or applications already installed. Here, machine-readable storage medium 410 may include a hard disk, optical disk, tapes, solid state drives, RAM, ROM, EEPROM, or the like.
Processor 411 may be at least one central processing unit (CPU), microprocessor, and/or other hardware device suitable for retrieval and execution of instructions stored in machine-readable storage medium 410. Processor 411 may fetch, decode, and execute program instructions 421-424, and/or other instructions. As an alternative or in addition to retrieving and executing instructions, processor 411 may include at least one electronic circuit comprising a number of electronic components for performing the functionality of at least one of instructions 421-424, and/or other instructions.
In block 521, method 500 may include managing, for a set of users, a corresponding set of digital healthcare profiles, where each digital healthcare profile includes a healthcare decision tree for the corresponding user. Referring to
In block 522, method 500 may include determining, for a first user of the set of users, a first subset of the set of users with a first set of similar digital healthcare profiles based on the corresponding set of healthcare decision trees. Referring to
In block 523, method 500 may include determining, based on correlation between a first healthcare decision tree of the first user with the first set of healthcare decision trees of the first subset of users, a first recommended action for the first user. Referring to
In block 524, method 500 may include providing, to the first user, information related to the first recommended action. Referring to
In block 525, method 500 may updating, for a second user in the first subset of users, a second digital healthcare profile and second healthcare decision tree of the second user. Referring to
In block 526, method 500 may include determining, based on the updated second healthcare decision tree of the second user, that the updated second healthcare decision tree deviates from the first set of healthcare decision trees. Referring to
In block 527, method 500 may include removing, based on the determined deviation, the second user from the first subset of users. Referring to
In block 528, method 500 may include determining, based on the updated second healthcare decision tree of the second user, that the updated second healthcare decision tree deviates from the first set of healthcare decision trees. Referring to
In block 529, method 500 may include providing, to the first user, information related to the second recommended action. Referring to
The foregoing disclosure describes a number of example implementations for dynamically evaluating health risk. The disclosed examples may include systems, devices, computer-readable storage media, and methods for dynamically evaluating health risk. For purposes of explanation, certain examples are described with reference to the components illustrated in
Further, all or part of the functionality of illustrated elements may co-exist or be distributed among several geographically dispersed locations. Moreover, the disclosed examples may be implemented in various environments and are not limited to the illustrated examples. Further, the sequence of operations described in connection with
This application is a continuation-in-part of U.S. patent application Ser. No. 15/800,772, which has been incorporated by reference herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62416106 | Nov 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15800772 | Nov 2017 | US |
| Child | 17351075 | US |
