Patent Application
20180330808
The present invention generally relates to Machine Learning (ML) for healthcare, and more particularly, is directed to a method and system of performing medication recommendation via a relation-constrained subset selection model.
Prescribing medications is a complicated process, where several aspects need to be taken into consideration. First and foremost, what medications can be used for treatment of one or more diagnosed diseases? For a single disease, there can be hundreds of medications for treatment. Typically, a patient has multiple conditions/diseases simultaneously, which further increases the number of candidate medications that can be prescribed to the patient. Second, some medications have adverse interactions and are discouraged to be used together. Physicians need to keep these antagonistic medications in mind and avoid prescribing them simultaneously. The number of medication pairs that have antagonistic interactions is very large, which makes it highly challenging to remember all of them precisely. Third, in clinical practice, rich knowledge has been accumulated so as to identify that, when used together, some medications can generate a synergy benefit and treat a disease more effectively. Such knowledge should be leveraged to improve the treatment recommendation. The number of synergy relations is large as well, making it difficult to remember and use. It is highly challenging for physicians to clearly remember the vast amount of knowledge mentioned-above (e.g., what drugs can be utilized to treat a certain disease; which drugs have adverse interactions or synergy relations). Because a patient can be diagnosed with several diseases, how to select from a large number of drugs that can be potentially applied to treat these diseases a small subset that possess the best treatment effect while avoiding adverse interaction and promoting synergy benefit becomes even more difficult.
Artificial Intelligence (AI) systems have become increasingly popular in clouds and data centers, especially in an enterprise environment. These systems are designed to resolve complicated issues involving large amount of data through, for example, self-learning. A need for an Operating System (OS) software in the enterprise AI data centers that can manage all the assets mentioned above with regard to providing medication for a particular medical condition is desired.
The presently disclosed embodiments are directed to solving issues relating to one or more of the problems presented in the prior art, as well as providing additional features that will become readily apparent by reference to the following detailed description when taken in conjunction with the accompanying drawings.
One embodiment is directed to a medication-recommending system. The medication-recommending system includes: a medication-medication correlation (MMC) sub-module configure to generate a correlation score of a first candidate medication and a second candidate medication; a medication-EHR dependency (MED) sub-modules configure to generate a dependency score between each of the first and second medications and an electronic health record (EHR); a relation-constraint (RC) sub-module configured to generate a relationship constraint indicating the interaction relation between the first and second medications; and a medication selection (MS) sub-module configure to select one or more recommended medications from at least the first and second medications based on the correlation score, dependency scores, and relational constraint.
Another embodiment is directed to a method of recommending medications. The method includes: receiving an electronic health record (EHR) including a plurality of modalities; encoding each of the modalities into a vector representation; combining the vector representations into a single vector; receiving profile articles of a plurality of candidate medications; encoding the profile articles into article vectors; computing a dependency score between the EHR and each candidate medication based on the single vector and the article vectors; computing a correlation score between a pair of medications of the plurality of candidate medications based on the article vectors; combining the dependency score and the correlation score into a kernel matrix generating at least one binary constraint based on medication interactions among the plurality of candidate medications; and selecting a subset of the plurality of the candidate medications based on the kernel matrix and the at least one binary constraint.
Further features and advantages of the present disclosure, as well as the structure and operation of various embodiments of the present disclosure, are described in detail below with reference to the accompanying drawings.
The present disclosure, in accordance with one or more various embodiments, is described in detail with reference to the following figures. The drawings are provided for purposes of illustration only and merely depict exemplary embodiments of the disclosure. These drawings are provided to facilitate the reader's understanding of the disclosure and should not be considered limiting of the breadth, scope, or applicability of the disclosure. It should be noted that for clarity and ease of illustration these drawings are not necessarily made to scale.
The following description is presented to enable a person of ordinary skill in the art to make and use the invention. Descriptions of specific devices, techniques, and applications are provided only as examples. Various modifications to the examples described herein will be readily apparent to those of ordinary skill in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the invention. Thus, embodiments of the present invention are not intended to be limited to the examples described herein and shown, but is to be accorded the scope consistent with the claims.
The word “exemplary” is used herein to mean “serving as an example or illustration.” Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs.
Reference will now be made in detail to aspects of the subject technology, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to like elements throughout.
It should be understood that the specific order or hierarchy of steps in the processes disclosed herein is an example of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
Embodiments disclosed herein are directed to a Medication Recommendation (MR) system designed for recommending medication based on one or more sets of data including, but not limited to the patient's health records, profiles of medications, correlations between medications and patients' symptoms and/or diagnosis, and known interactions between the different medications.
In one embodiment, such an MR system is configured to perform medication recommendation tasks by receiving inputs of an electronic health records (EHRs) (e.g., the clinical notes, lab test values, physical exams, medical images, etc.), profile articles of medications (e.g., in Drugs.com which is an encyclopedia of medications, each medication has an article describing what this medication is, what diseases/conditions it can treat, how it should be taken, its side effect, etc.) and interaction relations (e.g., diflucan and dolasetron have an antagonistic interaction; but aspirin and clopidogre have a synergistic interaction) between medications and generating an output of a subset of medications that can best treat this patient. The MR system utilizes deep neural networks to learn representations for patients' EHRs and medications, and compute the correlation among medications and the dependency between EHRs and medications. It uses a structural probabilistic model to perform medication-subset selection and is able to capture medication-correlation of any order. The MR system can flexibly incorporate the interaction relations among medications for better recommendation.
The ME Sub-module 102 can take the information on the medications as input and produce a vector representation of this medication. In one example, specifically, the ME sub-module 104 can be a convolutional neural network which takes the word sequence of a medication's profile article (e.g., a Drugs.com article) as input, performs convolution, pooling, and generates a vector representing this article. The vector can be the bag-of-words feature vector of the medications' profile articles.
In this embodiment, the EHR encoding (EE) sub-module 106 of the MR system 100 is configured to receive and learn feature representations of electronic health records (EHR), which can include multiple modalities of clinical information, including clinical notes, lab tests, vital signs, demographics, etc. The EE Sub-module 106 is discussed in detail below with reference to
As illustrated in
Referring back to
The MEC sub-module 108 can measure the dependency between a medication and an EHR. As illustrated in
The RC sub-module can use the interaction relations between medications to control the selection of medications. The relations can have two types. If the interaction is antagonistic, the two medications are prohibited to be co-selected to treat a disease. If the interaction is synergic, the two medications are encouraged to be co-selected. These antagonism and synergy relations can be obtained from one or more existing external medical knowledge bases. In one embodiment, the interaction can be represented as a binary constraint. The term RC Sub-module and the term Medication Interaction Procession (MIP) Sub-module are used interchangeably in this application.
The SS sub-module 110 (or Medication Selection (MS) sub-module) can select a subset of medications from the candidate medications, as the prescription to patients. In one example, the SS sub-module 110 can take the following information as inputs: (1) correlation scores between the medications that are produced by the MMC sub-module 104; (2) dependency scores between the medications and the input EHR that are produced by the MEC sub-module 108; (3) relational constraints regarding medication co-selection that are produced by the RC sub-module 110. Also, the SS sub0module 110 can produce a subset of medications that maximize the correlations scores and dependency scores but do not violate the constraints. At the core of this sub-module 110 is a probabilistic model. In one embodiment, the probabilistic model can be referred to as Determinantal Point Process (DPP) that is able to capture the medication-medication correlation of any order. In one embodiment, DPP can be a stochastic process defined on subsets. Given a set of medications {ai}i=1K, each represented by a vector ai, DPP computes a K-by-K kernel matrix L, where Lij=k(ai, aj) and k(.,.) is a kernel function. Then the probability over a subset of medications S⊆{1, . . . , K} can be defined as:
where LS is the submatrix of L indexed by element in S, I is an identity matrix and det(⋅) denotes the determinant of a matrix.
The MR System 100 of
While various embodiments of the invention have been described above, it should be understood that they have been presented by way of example only, and not by way of limitation. Likewise, the various diagrams may depict an example architectural or other configuration for the disclosure, which is done to aid in understanding the features and functionality that can be included in the disclosure. The disclosure is not restricted to the illustrated example architectures or configurations, but can be implemented using a variety of alternative architectures and configurations. Additionally, although the disclosure is described above in terms of various exemplary embodiments and implementations, it should be understood that the various features and functionality described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described. They instead can be applied alone or in some combination, to one or more of the other embodiments of the disclosure, whether or not such embodiments are described, and whether or not such features are presented as being a part of a described embodiment. Thus the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments.
In this document, the term “module” as used herein, refers to software, firmware, hardware, and any combination of these elements for performing the associated functions described herein. Additionally, for purpose of discussion, the various modules are described as discrete modules; however, as would be apparent to one of ordinary skill in the art, two or more modules may be combined to form a single module that performs the associated functions according embodiments of the invention.
In this document, the terms “computer program product”, “computer-readable medium”, and the like, may be used generally to refer to media such as, memory storage devices, or storage unit. These, and other forms of computer-readable media, may be involved in storing one or more instructions for use by processor to cause the processor to perform specified operations. Such instructions, generally referred to as “computer program code” (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system.
It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing: the term “including” should be read as meaning “including, without limitation” or the like; the term “example” is used to provide exemplary instances of the item in discussion, not an exhaustive or limiting list thereof; and adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known”, and terms of similar meaning, should not be construed as limiting the item described to a given time period, or to an item available as of a given time. But instead these terms should be read to encompass conventional, traditional, normal, or standard technologies that may be available, known now, or at any time in the future. Likewise, a group of items linked with the conjunction “and” should not be read as requiring that each and every one of those items be present in the grouping, but rather should be read as “and/or” unless expressly stated otherwise. Similarly, a group of items linked with the conjunction “or” should not be read as requiring mutual exclusivity among that group, but rather should also be read as “and/or” unless expressly stated otherwise. Furthermore, although items, elements or components of the disclosure may be described or claimed in the singular, the plural is contemplated to be within the scope thereof unless limitation to the singular is explicitly stated. The presence of broadening words and phrases such as “one or more,” “at least,” “but not limited to”, or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent.
Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the invention. It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processing logic elements or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processing logic elements or controllers may be performed by the same processing logic element or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processing logic element. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined. The inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather the feature may be equally applicable to other claim categories, as appropriate.
| Number | Date | Country | |
|---|---|---|---|
| 62504474 | May 2017 | US |
