BACKGROUND

[0001] The present invention relates generally to medical information engine, and particularly to management and consolidation of medical information.

[0002] Despite rapid growth of innovation in other fields in recent decades, the world of medical information, including patient medical records, billing, and a host of other information, has enjoyed little to no useful consolidation, reliability, or ease-of- access, leaving medical professionals, hospitals, clinics, and even insurance companies with many issues, such as unreliability of medical information, uncertainty of diagnosis, lack of standard, and a slew of other related problems.

[0003] One of the challenges facing those in the medical or related areas is the number of sources of information, the great amount of information from each source, and consolidation of such information in a manner that renders it meaningful and useful to those in the field in addition to patients. Obviously, this has contributed to increased medical costs and is perhaps largely attributed to the field suffering from an organized solution to better aid the medical professionals, to better aid those requiring more reliable patient history and those requiring more control and access over such information.

[0004] Currently, when a patient sees various medical professionals over the years, there is no method for universally tracking recommendations, thoughts, prescriptions, diagnosis. This hinders the job of insurance companies in making certain requisite determinations, physicians making decisions that directly impact the health of the patient, and hospitals and other medical institutions that similarly rely but do not have the benefit of the requisite information, not to mention the patient.

[0005] Further, there are problems in the current medical system that are associated with patient identity in that due to the exposure of a patient to various medical associations/professionals over the years and the possibility of various ways of identifying the same patient, patients' records and identity are oftentimes

compromised, creating a slew of problems both for the patient as well as those treating the patient. [0006] Further, privacy of a patient's health records is not currently reliably maintained, as there are too many cases of health record compromises. Additionally, patient control of access to medical information is nearly nonexistent. Additionally, secure and remote access of medical information is currently lacking.

[0007] It is therefore apparent that an urgent need exists for a medical information navigation engine ("MINE") capable of managing medical information in a manner that is beneficial, reliable, portable, flexible, and efficiently usable to those in the medical field, including patients. Such a MINE should also be capable of reconciling and intent-based clustering of patient data by applying at least one clustering rule to the reconciled medication information, and presenting the clustered reconciled medical information to a user.

SUMMARY

[0008] To achieve the foregoing and in accordance with the present invention, systems and methods for managing medical information are provided. In particular, systems and methods for intent-based clustering of medical information.

[0009] In one embodiment, a medical information navigation engine ("MINE") includes a medical information interface, a reconciliation engine and an intent-based presentation engine. The medical information interface is configured to receive medical information from a plurality of medical sources, which is subsequently reconciled by the reconciliation engine. The intent-based presentation engine is configured to cluster the reconciled medical information by applying at least one clustering rule to the reconciled medication information. The presentation engine can be further configured to present the clustered reconciled medical information to a user.

[0010] In some embodiments, the MINE also applies at least one dynamic rule to the reconciled medical information, and the reconciliation may include applying one or more similarity rules to the medical information. The similarity rules may include comparing patient data attributes. The intent-based presentation engine can be configured to compute a distance between the patient data attributes and clustered reconciled medical information. If the computed distance is less than a threshold, then the clustered reconciled medical information is included in a presentation cluster prepared for the user. Conversely, if the distance is greater than a threshold, then the clustered reconciled medical information is excluded from a presentation cluster prepared for the user. The similarity rules may include identifying associated terms

[0011 ] Note that the various features of the present invention described above may be practiced alone or in combination. These and other features of the present invention will be described in more detail below in the detailed description of the invention and in conjunction with the following figures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order that the present invention may be more clearly ascertained, some embodiments will now be described, by way of example, with reference to the accompanying drawings, in which:

[0013] Fig. 1 shows a medical system 100, in accordance with an embodiment of the invention;

[0014] Fig. 2 shows further details of the MINE 1 12 of Fig. 1, in accordance with an embodiment of the invention;

[0015] Fig. 3 shows an exemplary embodiment implementing the system 100 using various devices;

[0016] Fig. 4 shows further details of the system 100, in accordance with an embodiment of the invention;

[0017] Fig. 5 shows further details of the engine 502 and the block 504 of Fig. 4;

[0018] Figs. 6 and 7 each show examples of applying the rules 526, and 528 and 530, to the data 506 to yield certain beneficial results;

[0019] Figs. 8-10 show screen shots of an exemplary application of the rules of Fig. 5 in the context of medical application; and

[0020] Fig. 1 1 shows a flow chart of the steps performed by the block 504 of Fig. 5 in applying the rules therein, in accordance with an exemplary method of applying intent-based clustering and display to the data 506 of Fig. 5. DETAILED DESCRIPTION

[0021] The present invention will now be described in detail with reference to several embodiments thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present invention. It will be apparent, however, to one skilled in the art, that embodiments may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures have not been described in detail in order to not unnecessarily obscure the present invention. The features and advantages of embodiments may be better understood with reference to the drawings and discussions that follow.

[0022] Referring now to Fig. 1, medical system 100, in accordance with an embodiment of the invention. The system 100 is shown to include medical source 1 14, a medical information navigation engine (MINE) 1 12, and medical information consumers (also referred to herein as "output" or "medical output") 1 17. The medical source 1 14 are shown to include an electronic health record (EHR) 118, EHR 120, health information exchange (HIE) 122, and a picture archiving and communication system (PACS) 124. The MINE 112 is shown to include interface 1 13, a back-end medical processor 1 16, and a front-end medical processor 1 15.

[0023] "Medical information", as used herein, refers to any health-related information, including but not limited to patient medical records, patient entered information, care team entered information, healthcare device generated information, and billing information.

[0024] The source 114 generally provides various medical information to the MINE 1 12. For example, the EHRs 118 and 120 each may provide information such as medical records and billing, the HIE 122 may provide information such as medical records, and the PACS 124 may provide information such as diagnostic imaging and reports.

[0025] The medical information consumers 117, which may be made of a host of entities or individuals, such as patients, clinics, medical institutions, health organization, and any other medical-related party, use information that is provided by the processor 115 of MINE 112 and that can, by way of example, consist of patients, medical systems, medical organization administrators, medical researchers, and/or EHR users. For example, user-customized processed medical information is provided by the processor 1 15 to a number of users within the medical information consumers 1 17. In this case, the processor 115 generates user-customized processed medical information to a plurality of users, with at least a portion of the user-customize processed medical information being provided to each of the users based on the relevancy of the portion being provided of each user's specific function or role and each user's associated security privileges.

[0026] The processor 116, in some embodiments, indexes identifies, maps, and consolidates medical information, received from the interface 1 13, and tags this information, and determines to reconcile the tagged information. In some methods and embodiments, information that is extracted from images is tagged to enhance recall of search queries. Indexing, at least in part, processes document and converts them into formats that allows for quick searching across a large collection of documents.

[0027] The information in the MINE 112 is encrypted and secure to ensure privacy of sensitive medical information.

[0028] It is understood that the sources 114 of Fig. 1 includes merely some examples of the sources that communicate with the MINE 112 and that other sources, known to those in the field, are contemplated. Similarly, the output 117 may be used by those or entities not discussed herein but that are contemplated and within the scope and spirit of the invention.

[0029] The interface 113 serves to receive information that is in various forms, such as but not limited to text, html, CCD, CCR, HL7 and any other type or formatted information. The interface 1 13 then provides to the processors 1 15 and 1 16 information, as needed.

[0030] The processor 116 receives some of the medical information that the interface 1 13 processes and performs certain tasks to process it, such as indexing, semantic meta-tagging, and reconciliation. Indexing takes processed documents and converts them into formats that make it easy to quickly search across a large collection of documents. Semantic meta-tagging embeds information into the medical information that is relevant thereto and that can be later used to search for certain information for the purpose of reconciliation and search, among many others.

[0031] One aspect of consolidation, reconciliation and de-duplication, generally refers to removing of redundant patient medical records, such as, multiple records for the same individual appearing as though the records are for different individuals or multiple data elements that are recorded similarly but slightly differently in the different sources. In this case, the processor 1 16 recognizes that the records belong to a single individual or are the same data and just recorded differently and

automatically consolidates them. The patient or a user of the system 100 may also manually perform reconciliation. The processor 116 advantageously determines whether or not reconciliation is performed.

[0032] The processor 116 outputs the indexed, tagged and reconciled information to the processor 115. The foregoing tasks are a generalization and further details of each are provided below.

[0033] The processor 115 performs certain tasks on the information provided by the interface 113 and the processor 1 16, which include query, search, presentation, and quality checking. The output of the processor 1 15 is the output of the MINE 1 12, or output 117.

[0034] The MINE 1 12, through the processor 1 15, in some embodiments and methods, invites members of a medical care team to join it thereby allowing distributed user-organized care teams.

[0035] Querying, as performed by the processor 115, is the ability to receive, as input, a free text query, from a user, (i.e., a query without any restrictions on the structure) - and converting the free text query into commands to a medical search engine, such as Medical Lexical Search Engine and the MATRIX (Medical

Application Terminology Relationship IndeX) Concept Search Engine, using a sophisticated query processing engine optimized to work with medical queries. The results of the search engine are sent to the presentation display planner - which decides the most relevant presentation given the user's organization and role (e.g. the provider, search query program, a healthcare administrator, a study administrator, and the patient). The presentation discussed below, receives such information. In some embodiments and methods, the medical information or user information is processed to suggest relevant queries.

[0036] Search, as performed by the processor 1 15, is built around the concept of Zero-Click Relevance - or the ability to get to all the relevant information an actor in the healthcare system requires by typing in just a single query. The search engine, within the processor 1 15, performing the search comprises an indexing and searching, as will become apparent shortly. Optionally, search results may be securely embedded into third party programs. In some embodiments, searching involves determining presenting (also referred to herein as "providing") access to specific relevant data based on a search query, the patient, and the user's specific function and/or role and security privileges. A user may be within the output 117 and security privileges are either determined by the MINE 112 or by the patient or both. The information that is uploaded to the MINE 1 12 by users, such as in output 1 14 (in some embodiments) is searched by the processor 1 15. The uploaded information may include information such as but not limited to status posts, records, and images. Such user-uploaded information is routed automatically to the output 1 17, as needed.

[0037] Some aspects of the search are now discussed relevant to an example.

Assuming, by way of example, that Dr. Smith, an internal medicine physician, sees a new patient, Joan Sample, who presents with a complaint of chest pain. Joan has brought several continuity-of-care documents (CCDs) and a 600-page pdf file representing of her medical chart. She has seen a cardiologist who uses NextGen's electronic medical record (EMR) and a gastroenterologist who uses eMD's EMR and she has recently visited a local emergency room. Dr. Smith uses the search of the various methods and embodiments of the invention to efficiently assemble the relevant information he needs. Dr. Smith selects Joan Sample as the patient and enters the clinical context "chest pain" in the search bar of a screen presented by the MINE 112 (examples of such screens are shown in subsequent figures herein). He is presented with relevant lab results, such as CKMB, troponin, and amylase; relevant diagnostic results, such as prior electrocardiograms (EKGs) and the most recent chest computed tomography (CT) scan; and all progress notes and consult reports in which concepts relevant to chest pain, like "GERD" and "cardiac stress test", are mentioned. Two distinct types of searches are combined, in accordance with a method and embodiment of the invention, to retrieve information medically relevant to Joan's complaint: 1) Lexical search, where text in the patient record is searched for occurrences of the search term, its variants and synonyms; and 2) Medical concept search, where data that is medically related to the search term is retrieved. Medical concept search finds relevant structured data with standardized codes, such as lab results, and text results, such as progress notes, which include terms medically related to the search term. In Joan's case, a search for "chest pain" returns a CKMB lab result and a reference to the most recent chest CT scan. Accordingly and

advantageously, the Lexical and Medical concept search solves Dr. Smiths' information overload problem by returning information in the chart most relevant to determining the etiology of Joan's chest pain complaint. Further, in some embodiments, the presentation, discussed shortly, presents a united view of Joan's history by reconciling and de-duplicating data from multiple sources that may be coded and described differently. Redundant data is automatically reconciled even if it is described differently by differently sources.

[0038] Presentation, as performed by the processor 115, is displaying health information to the requesting user in a way that reduces the number of clicks and maximizes the amount of meaningful information delivered based on the interpreting the intent of the user query.

[0039] Quality checking, as performed by the processor 1 15, is checking of the quality of medical information provided by various sources, i.e. source 1 14, by the patients, structured data, and unstructured data, in a Wiki-like mannered setting whereby the users can help maintain and improve the quality of information displayed. The foregoing tasks, performed by the processor 1 15, are further described in detail below. Additionally, the users or patients may make comments regarding medical information, in a Wiki-like manner.

[0040] In summary, the MINE 1 12 transacts medical information including the interface 113 receiving medical information from a number of medical sources (such as within the source 114) for processing, identifying, mapping, and consolidating by the medical processor 116, providing access to specific relevant data, based on a user's security privileges, within the identified, mapped, and consolidated medical information, based on user-specific functions or roles, performed by the processor 1 15, and generating user-customized processed medical information to a number of users, such as within the output 117, with at least a portion of the user-customized processed medical information being provided to each of the users based on its relevancy to each user's specific function or role and each user's associated security privileges.

[0041] Fig. 2 shows further details of the system 100, particularly the MINE 1 12 thereof. That is, the processor 116 is shown to include an indexing and metal tagging module 234, which includes an indexing module and a meta tagging module (both of which are not shown in Fig. 2 in the interest of clarity), which may be a module, as shown in Fig. 2 or two physically separate modules. The processor 116 is further shown to include a reconciliation and de-duplication module 236, which also can be broken out into two modules, a reconciliation module and a de-duplication module, and a code and semantic mapping module 238, which also may be a single module or multiple modules. The modules 234, 236, and 238 communicate with one another.

[0042] The processor 115, in some embodiments, includes display and visualization 340 executing on one or more servers 238, which may be any suitable computing engine, similar to the servers 232, including but not limited to PCs or servers. The display 340 is used to construct presentation and display information to users, such as the patient's records, billing information, and other types of medical information. The display 340, in some embodiments, also performs processing of some of the functions of the processor 1 15.

[0043] The foregoing modules may be software programs, executed by a computer or computing engine of suitable sorts, or may be implemented in hardware.

[0044] Fig. 3 shows an exemplary embodiment implementing the system 100 using various devices. That is, the medical system 330 is analogous to the system 100 and is shown to include the sources 114 coupled to communicate, securely, through the secure communication link 342, to the interface 1 13. The link 342 may be any suitable communication channel allowing information, of various formats and types, to be transferred to the interface 113 in a secure and encrypted fashion. Exemplary communication channels of which the link 342 is made include the Internet, VPN connections over the Internet, private dedicated digital lines such as Tl, T3, El, E3, SONET, and other fiber optic formats.

[0045] The interface 113, in some embodiments, is a software program that executes on one or more servers 232, which can be a server of any kind of suitable computing engine, such as personal computer (PC). The servers 232 receive secure information through the link 342 from the sources 114. The processor 116, in some embodiments, includes the module 236 and one or more servers 234, which may be any suitable computing engine, similar to the servers 232, including but not limited to PCs or servers.

[0046] The module 236 and servers 234 perform the tasks discussed above relative to the processor 116 and the display 340 and servers 238 perform the tasks discussed above relative to the processor 115 though these processors may and often perform additional tasks related to medical information, some examples of which are presented and discussed below and the rest of which are contemplated and achieve the various advantages, results and functions presented herein.

[0047] The processor 115, in some embodiments, includes display and visualization 340 executing on one or more servers 238, which may be any suitable computing engine, similar to the servers 232, including but not limited to PCs or servers. The display 340 is used to construct presentation and display information to users, such as the patient's records, billing information, and other types of medical information. The display 340, in some embodiments, also performs processing of some of the functions of the processor 1 15.

[0048] As shown in Fig. 3, the servers 232 are coupled to the module 236 and the servers 234, and to the display 340 and the servers 238 and the module 236 and servers 234 are coupled to the display 340 and the servers 238.

[0049] In some embodiments, the interface 113, servers 232, module 236, servers 234, display 340, and servers 238 are remotely located relative to the sources 114 and in some embodiments, remotely located relative to one another. Further, they are considered a part of the Internet cloud where, performing their tasks in a manner known as "cloud-computing". However, other manner of achieving the functions and advantages of the invention, including various other of implementation, not shown in Fig. 3 or other figures herein and/or not discussed are contemplated.

[0050] Fig. 4 shows further details of the module 236 of Fig. 2, in accordance with an embodiment of the invention. The module 236 is shown to include a reconciliation engine (also referred to hereinafter as the "mapper") 502 responsive to data 506, which is, at least in part, within the source 114, and is shown to provide reconciled information that is provided to the intent-based presentation block 504.

[0051] The engine 502 advantageously learns, through history, ontology, user- input, the type of user, and a host of other factors, similarities between various information from the data 506, defines characteristics thereof, models this information

conceptually, pre-selects and sorts information before providing it the block 504 for presentation in the form of a display, or other known types of presentations. Such processing entails the use of various sets of rules, at various stages, as will be evident shortly relative to subsequent figures and discussions.

[0052] Presentation by the block 504 is intent-based, that is, the user of the module 236 along with history, and other factors are used to determine the information to be presented. With time, as the engine 502 's knowledge of medical information, such as drugs, type of users, diagnosis, the relationship between various diagnosis/diseases relative to each other and relative to various medications, and other information, increases, the information presented by 504 becomes increasingly intent-based.

[0053] The engine 502 is shown to include a conceptual model block 508, which conceptually models the data 506, such as to determine similarities, an example of which is provided and discussed in subsequent figures.

[0054] Fig. 5 shows further details of the engine 502 and the block 504 of Fig. 4. The engine 502 is shown to include a reconciler block 510 that receives data 506 and a similarity mapper 512, which generally performs the tasks of the block 508 in Fig. 1. The block 504 is shown to include a presentation cluster block 514, which is shown to receive information from the mapper 512, and a data cluster 520.

[0055] A set of similarity rules 526, which identify similarities of various types of information, and define characteristics thereof, is shown being utilized by the reconciler 510. The rules 526 are applied to the data 506 to identify similar concepts, which unlike prior art techniques, is not to look for matches and rather to correlate information based on concepts. Through feedback from users 536, this becomes a learned process with improved and more sophisticated conceptual similarity detection. The similarity mapper 512 maps the reconciled information, generated by the reconciler 510. [0056] Another set of rules, namely, a set of clustering rules 528, is provided to the presentation cluster block 514 for determining which information, if any, to cluster or group. The block 514 also receives as input, user intent query 540, from a user, and applies the rules 528 to the latter. The rules 528 are used by the block 514 to group information received from the mapper 512, based on the user intent query 540, and in the process additional apply a set of dynamics (time) rules 530 thereto. The rules 530 serve to identify what is to be looked at to find what has information has been changed over time. In this respect, feedback from the user, through 542, is utilized. Similarly, the rules 528 utilize feedback from the user. Additionally, feedback from the user is utilized, at 534, to accumulate concept-based information and definitions in a Wiki-style fashion.

[0057] The presentation cluster block 514 generates output data clusters 520. The cluster 520 information may be displayed and/or presented in other manners, such as with an Application Programming Interface (API), and it further may receive user feedback and use the same to further refine rules for clustering and similarity mappings.

[0058] The rules 526, 528, and 530 are independent of one another in some embodiments of the invention. In other embodiments, information flows there between. Advantageously, these rules, partly because they are applied at different stages in the processing of the data 506, allow for a learned and conceptualized process as opposed to a hard decision. For example, in current techniques, where only one set of rules are utilized early on in the processing of the data, a hard decision is made with no flexibility to alter this decision thereby increasing the risk of mis- categorization and/or identification of relevant information. In contrast, thereto, the different sets of rules of the embodiment of Fig. 5, breakdown categories, such as similarity, display, and history, allows configuration of various aspects thereof.

[0059] By way of example, in prior art techniques, where the data is regarding electronic devices and a cell phone is to be identified, where the single set of rules, made early on in the process, is based on the lack of a keyboard, and a central processing unit, the device may be erroneously identified as an electronic tablet, with no recourse. Whereas, the embodiment of Fig. 5 allows for progressive learning of various attributes of the device by, for example, using the above exemplary rules as the rules 526 but based on the rules 530 and 528, introducing attributes, such as size of the device, that allow for a more accurate identification of the device. And further, due to the user- feedback and query, allow for dynamically altering the rules.

[0060] Use of various rules, such as rules 526, 528, and 530, at various stages of processing, allows flexibility in applying the rules to achieve greater accuracy of clustering. In medical applications in particular, information is oftentimes duplicated for various reasons, such as lack of standardization of names of medications, shorthand identification of information, and a slew of other reasons. In this regard, flexibility of applying rules is vital. While three sets of rules are shown in the figures and discussed herein relative to various embodiments, it is understand that a different number of rules may be employed.

[0061] For a better understanding of the flexibility the rules of Figs. 5-7 offer, an example is now presented. Suppose the data 506 carries medical information for which a particular condition, e.g. diabetes, is to be detected. Rule 526 allows for a similarity between lab results and "diabetes" to be identified but that is nearly where the application of rule 526 ends until further information is known and extracted later in the processing of the data 506. Namely, when rule 528 is applied to the outcome identified by Rule 526, the lab results are crawled or inspected for "diabetes" or another identifier for "diabetes". Additionally, the presence of various relevant labs is detected and the association between the presence of the labs and the problem of diabetes and perhaps, hemoglobin Ale (a measure of average blood glucose concentration over the past 30 to 120 days, used in the diagnosis and treatment of diabetes) is made. Next, the rule 530 is applied to the outcome of the application of rule 528 where patient data is used or a correlation between a problem and a treatment for a large percent of the patient population is made. Specifically, the percentage of patients with diabetes is detected. The parameter of time allows for the latter detection, otherwise, for example, at the application of rule 526 or even rule 528, a large patient base could not have been correlated.

[0062] The user input at 540 and the user feedback at 518 all help in the clustering of data. At the application of rule 526, a determination is made as to how things are similar until a user asks about the similarity after which a more educated application of rules is performed. Thus, no decision is made until the end or at the output of the block 514, in real-time. [0063] During the application of rule 526, the system is informed of key parameters but not how to put the data together. Then, during the application of the rule 528, the system is informed of how to put the data together (cluster) by aligning the data in a particular manner. Application of rule 530 determines how things change over time, or not, but not what the correlation or similarity actually is, which is generally done through the rule 528. Part of the reason for splitting the rules is to delay decisionmaking as long as possible in an effort to cleverly use more information, such as that provided by the user, for an increasingly accurate finding.

[0064] The outcome of the data cluster 520 can be transmitted to another processor, system, user, or any other entity.

[0065] Another example of the manner rules are employed, outside of the medical community, is for example, in determining parameters of hair where rule 526 is used to look for length of hair and rule 528 uses the outcome of the length of hair to further determine alopecia as compared with normal hair growth. Rule 530 may then be used to determine a percentage of a demographic that has experienced baldness. Further examples of the application of these rules is shown and discussed relative to Figs. 6- 1 1.

[0066] As with the blocks of the MINE 112 of Fig. 1, it is understood that the blocks shown in Fig. 5, such as block 510 and 514, and 516 may be independently a machine and/or processor or a part of a machine and/or processor. They may alternatively, be carried out in software programs.

[0067] Figs. 6 and 7 each show examples of applying the rules 526, and 528 and 530, to the data 506 to yield certain beneficial results. In Fig. 6, rule 526 is applied to the data 506 to identify the medication named "Advil" as an "Ibuprofen". Similarly, "Motrin" is identified as Ibuprofen, therefore, allowing more flexibility to a patient and a medical professional in deciding to use these drugs. Rules for similarity specific what characteristics need to be looked at to determine similarity of an object to another object.

[0068] Using the same example, rules 528 and 530 may be applied to the outcome of the rule 526 to the data 506 to determine other information based on the intent of the user. For example, the dosage of Ibuprofen, from all sources, even those with other ingredients, may be determined by applying rule 528, after applying rule 526 such that the outcome of rule 526 detects Ibuprofen types of medications and rule 528 narrows the detection to those with a threshold dosage.

[0069] Fig. 7 shows an application of the rules 528 and 530 where a set of associated terms, ml(c), has been identified and another set of associated items, m2(c), has been identified. For example ml(c) is one medication, m2(c) is another medication and "c" are particular characteristics of each medication such as, but not limited to, brand name, generic name, dosage, prescription instructions (sig), prescription date, and start date. Rules for dynamics, rule 526, is the time base characteristics. Rules for clustering, rules 528, would be probability of matches of other characteristics. For example, for a given medication such as oral contraceptive pills (OCPs), the rules of dosage might be ignored such that different prescriptions with different doses would be considered the same for clustering purposes. In this example, the use of oral contraceptive medications at all dosages is contraindicated for women with a genetic predisposition or other risk factors associated with thrombotic events (e.g., venous thromboembolism). Another medication where dosage might be very important to outcomes would not be clustered together if the dosage were different. For example, Warfarin, a medication commonly used to prevent blood clotting, has a very narrow therapeutic window and its metabolism widely varies among individuals. The dosage of Warfarin is highly correlated to outcomes of interest. Physicians routinely prescribe different dosages of Warfarin to treat or prevent thrombotic events or predisposing conditions such as pulmonary embolism or atrial fibrillation.

[0070] For further clarification, in the example of Advil and Ibuprofen, if the intent is to investigate whether the current dosage of Ibuprofen is too high, all sources of ibuprofen (even those with other ingredients) are better to be identified, in which case the set ml(c) may represent all sources. The date may also be an indicator, such as the last day or week this medication was prescribed or consumed and may accordingly be a part of the set, m2(c). In contrast, if contributors to (or indicators of) of a chronic condition is the intent, a longer history (months, years) and the chronic condition itself would be "related" despite low "similarity". Thus, through the flexibility of the application of various rules, such as rules 526, 528, and 530, there can be different ways of displaying information, from the data clusters 516, about a concept under different intents. [0071] By way of further explanation, the rules 528 are used to determine what is considered inside the cluster and the rules 530 is how things in the cluster change over time. Though, in other embodiments, other types of rules are anticipated and other numbers of rules are anticipated. Using the Advil/Ibuprofen example above, the rules 528 are used to determine whether other medicines belong in the display cluster, for instance if they contain Ibuprofen but they also contain other things (such as sleep aid, Comtrex) that may or may not "belong" in the display cluster. The embodiment of Fig. 5 advantageously learns whether they "belong" or not. Through the rule 530, the Ibuprofen cluster might emphasize recent events (past week) in the ranking. Other clusters may interact differently with time.

[0072] Figs. 8-10 show screen shots of an exemplary application of the rules of Fig. 5 in the context of medical application. Fig. 8 shows a screen shot of lab results of a patient throughout time. As shown the lab result for "ALT" is shown twice, once on May 18, 2010 and another on May 7, 2010. With the application of rule 526, in this case, identifying similar or same lab results, these two indications of ALT are consolidated. Further, with the application of rule 528, in Fig. 9, a screen shot is shown of the medication, Diltiazem ER, having been consolidated. This is better appreciated in Fig. 10 with an expanded screen shot of Diltiazem ER including its various iterations. That is any use or indication of Diltiazem ER, abbreviated or otherwise, is consolidated at 900 with a pull-down menu option for a user to view all occurrences.

[0073] Fig. 1 1 shows a flow chart of the steps performed by the block 504 of Fig. 5 in applying the rules therein, in accordance with an exemplary method of applying intent-based clustering and display to the data 506 of Fig. 5.

[0074] In Fig. 1 1, at step 1151, an automatic or manual, or a combination, of attribute selection is performed by applying rules 526 and 528, in accordance with a method and embodiment of the invention. Accordingly, attributes to be included in clustering are selected. For example, for a presentation of medications, several attributes might be included. To present results to a user, another machine, processor or the like, for a medication history intent, medication brand name, generic name, coding system, drug code, and ingredient might be selected. This may be done by a user, manually, or automatically by the block 514, in an exemplary embodiment of the invention. [0075] Next, at step 1 153, the criteria for clustering relevant combinations is defined, manually, automatically or using a combination thereof. The matching criteria for each of these attributes are defined as a maximum distance along with an appropriate definition of distance. Examples of "maximum match distance" are "exact match", "close match", "loose match" or distance < x where x is an appropriate maximum distance. Examples of distance measures are numerical difference, any edit distance, semantic distance, abstract distance along an ontology or graph, etc. Rules for relevant combinations of the selected attributes are also defined during this step. In some methods and embodiments, attributes can be combined to create a composite threshold that the data 506 can be measured against. With reference to the medication history intent presented hereinabove, all medications in the patient history that are close matches on brand name or generic name might be included, along with exact semantic matches on a particular drug ingredient or exact numerical matches on a group of related drug codes.

[0076] Next, at 1 155, the distance between the data 506's attributes and cluster is computed. For example, it is determined whether all distances are less than the maximum distance threshold and if so, the cluster is updated to include such data in the presentation, at step 1 159, otherwise, step 1 157, such data is rejected (not included) in the cluster.

[0077] While this invention has been described in terms of several embodiments, there are alterations, modifications, permutations, and substitute equivalents, which fall within the scope of this invention. Hence, it should also be noted that there are many alternative ways of implementing the methods and apparatuses of the present invention. It is therefore intended that the following appended claims be interpreted as including all such alterations, modifications, permutations, and substitute equivalents as fall within the true spirit and scope of the present invention.