Patent ID: 12198820

DETAILED DESCRIPTION

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.

Aspects, features and advantages of exemplary embodiments of the present invention will become better understood with regard to the following description in connection with the accompanying drawing(s). It should be apparent to those skilled in the art that the described embodiments of the present invention provided herein are illustrative only and not limiting, having been presented by way of example only. All features disclosed in this description may be replaced by alternative features serving the same or similar purpose, unless expressly stated otherwise. Therefore, numerous other embodiments of the modifications thereof are contemplated as falling within the scope of the present invention as defined herein and equivalents thereto. Hence, use of absolute and/or sequential terms, such as, for example, “always,” “only,” “will,” “will not,” “shall,” “shall not,” “must,” “must not,” “first,” “initially,” “next,” “subsequently,” “before,” “after,” “lastly,” and “finally,” are not meant to limit the scope of the present invention as the embodiments disclosed herein are merely exemplary.

I. System Architecture

Referring now toFIG.1, medical system100is shown, in accordance with some embodiments. The system100is shown to include medical source114, a medical information navigation engine (MINE)112, and medical information consumers (also referred to herein as “output” or “medical output”)117. The medical source114are shown to include one or more electronic health records (EHR)118and120, health information exchange (HIE)122, and a picture archiving and communication system (PACS)124. The MINE112is shown to include interface113, a back-end medical processor116, and a front-end medical processor115.

“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, referral information, and billing information.

The source114generally provides various medical information to the MINE112. For example, the EHRs118and120each may provide information such as medical records and billing, the HIE122may provide information such as medical records, and the PACS124may provide information such as diagnostic imaging and reports.

The medical information consumers117, 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 processor115of MINE112and 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 processor115to a number of users within the medical information consumers117. In this case, the processor115generates 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.

The processor116, in some embodiments, indexes identifies, maps, and consolidates medical information, received from the interface113, 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.

The information in the MINE112is encrypted and secure to ensure privacy of sensitive medical information.

It is understood that the sources114ofFIG.1includes merely some examples of the sources that communicate with the MINE112and that other sources, known to those in the field, are contemplated. Similarly, the output117may be used by those or entities not discussed herein but that are contemplated and within the scope and spirit of the invention.

The interface113serves 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 interface113then provides to the processors115and116information, as needed.

The processor116receives some of the medical information that the interface113processes 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.

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 processor116recognizes 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 system100may also manually perform reconciliation. The processor116advantageously determines whether or not reconciliation is performed.

The processor116outputs the indexed, tagged and reconciled information to the processor115. The foregoing tasks are a generalization and further details of each are provided below.

The processor115performs certain tasks on the information provided by the interface113and the processor116, which include query, search, presentation, and quality checking. The output of the processor115is the output of the MINE112, or output117.

The MINE112, through the processor115, in some embodiments and methods, invites members of a medical care team to join it thereby allowing distributed user-organized care teams.

Querying, as performed by the processor115, 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.

Search, as performed by the processor115, 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 processor115, 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 output117and security privileges are either determined by the MINE112or by the patient or both. The information that is uploaded to the MINE112by users, such as in output117(in some embodiments) is searched by the processor115. 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 output117, as needed.

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 MINE112(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. Smith's 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.

Presentation, as performed by the processor115, 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.

Quality checking, as performed by the processor115, is checking of the quality of medical information provided by various sources, i.e. source114, 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 processor115, are further described in detail below. Additionally, the users or patients may make comments regarding medical information, in a Wiki-like manner.

In summary, the MINE112transacts medical information including the interface113receiving medical information from a number of medical sources (such as within the source114) for processing, identifying, mapping, and consolidating by the medical processor116, 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 processor115, and generating user-customized processed medical information to a number of users, such as within the output117, 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.

FIG.2shows further details of some embodiments of the system100, particularly the MINE112thereof. That is, the processor116is shown to include an indexing and metal tagging module234, which includes an indexing module and a meta tagging module (both of which are not shown inFIG.2in the interest of clarity), which may be a module, as shown inFIG.2or two physically separate modules. The processor116is further shown to include a reconciliation and de-duplication module236, which also can be broken out into two modules, a reconciliation module and a de-duplication module, and a code and semantic mapping module238, which also may be a single module or multiple modules. The modules234,236, and238communicate with one another.

The processor115, in some embodiments, includes display and visualization340executing on one or more servers238, which may be any suitable computing engine, similar to the servers232, including but not limited to PCs or servers. The display340is used to construct presentation and display information to users, such as the patient's records, billing information, and other types of medical information. The display340, in some embodiments, also performs processing of some of the functions of the processor115.

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

FIG.3shows an exemplary embodiment implementing the system100using various devices. That is, the medical system330is analogous to the system100and is shown to include the sources114coupled to communicate, securely, through the secure communication link342, to the interface113. The link342may be any suitable communication channel allowing information, of various formats and types, to be transferred to the interface113in a secure and encrypted fashion. Exemplary communication channels of which the link342is made include the Internet, VPN connections over the Internet, private dedicated digital lines such as T1, T3, E1, E3, SONET, and other fiber optic formats.

The interface113, in some embodiments, is a software program that executes on one or more servers232, which can be a server of any kind of suitable computing engine, such as personal computer (PC). The servers232receive secure information through the link342from the sources114. The processor116, in some embodiments, includes the module236and one or more servers234, which may be any suitable computing engine, similar to the servers232, including but not limited to PCs or servers.

The module236and servers234perform the tasks discussed above relative to the processor116and the display340and servers238perform the tasks discussed above relative to the processor115though 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.

The processor115, in some embodiments, includes display and visualization340executing on one or more servers238, which may be any suitable computing engine, similar to the servers232, including but not limited to PCs or servers. The display340is used to construct presentation and display information to users, such as the patient's records, billing information, and other types of medical information. The display340, in some embodiments, also performs processing of some of the functions of the processor115.

As shown inFIG.3, the servers232are coupled to the module236and the servers234, and to the display340and the servers238and the module236and servers234are coupled to the display340and the servers238.

In some embodiments, the interface113, servers232, module236, servers234, display340, and servers238are remotely located relative to the sources114and 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 inFIG.3or other figures herein and/or not discussed are contemplated.

FIG.4shows further details of the module236ofFIG.2, in accordance with an embodiment of the invention. The module236is shown to include a reconciliation engine (also referred to hereinafter as the “mapper”)502responsive to data506, which is, at least in part, within the source114, and is shown to provide reconciled information that is provided to the intent-based presentation block504.

The engine502advantageously learns, through history, ontology, user-input, the type of user, and a host of other factors, similarities between various information from the data506, defines characteristics thereof, models this information conceptually, pre-selects and sorts information before providing it the block504for 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.

Presentation by the block504is intent-based, that is, the user of the module236along with history, and other factors are used to determine the information to be presented. With time, as the engine502'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 by504becomes increasingly intent-based.

The engine502is shown to include a conceptual model block508, which conceptually models the data506, such as to determine similarities, an example of which is provided and discussed in subsequent figures.

FIG.5shows further details of the engine502and the block504ofFIG.4. The engine502is shown to include a reconciler block510that receives data506and a similarity mapper512, which generally performs the tasks of the block508inFIG.1. The block504is shown to include a presentation cluster block514, which is shown to receive information from the mapper512, and a data cluster516.

A set of similarity rules526, which identify similarities of various types of information, and define characteristics thereof, is shown being utilized by the reconciler510. The rules526are applied to the data506to 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 users518, this becomes a learned process with improved and more sophisticated conceptual similarity detection. The similarity mapper512maps the reconciled information, generated by the reconciler510.

Another set of rules, namely, a set of clustering rules528, is provided to the presentation cluster block514for determining which information, if any, to cluster or group. The block514also receives as input, user intent query540, from a user, and applies the rules528to the latter. The rules528are used by the block514to group information received from the mapper512, based on the user intent query540, and in the process additional apply a set of dynamics (time) rules530thereto. The rules530serve to identify what is to be looked at to find what information has been changed over time. In this respect, feedback from the user, through542, is utilized. Similarly, the rules528utilize feedback from the user. Additionally, feedback from the user is utilized, at534, to accumulate concept-based information and definitions in a Wiki-style fashion.

The presentation cluster block514generates output data clusters516. The cluster516information 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.

The rules526,528, and530are 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 data506, 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 ofFIG.5, breakdown categories, such as similarity, display, and history, allows configuration of various aspects thereof.

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 ofFIG.5allows for progressive learning of various attributes of the device by, for example, using the above exemplary rules as the rules526but based on the rules530and528, 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.

Use of various rules, such as rules526,528, and530, 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.

II. Medical Information Management

For a better understanding of the flexibility the rules ofFIGS.5-7offer, an example is now presented. Suppose the data506carries medical information for which a particular condition, e.g. diabetes, is to be detected. Rule526allows for a similarity between lab results and “diabetes” to be identified but that is nearly where the application of rule526ends until further information is known and extracted later in the processing of the data506. Namely, when rule528is applied to the outcome identified by Rule526, 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 A1c (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 rule530is applied to the outcome of the application of rule528where 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 rule526or even rule528, a large patient base could not have been correlated.

The user input at540and the user feedback at518all help in the clustering of data. At the application of rule526, 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 block514, in real-time.

During the application of rule526, the system is informed of key parameters but not how to put the data together. Then, during the application of the rule528, the system is informed of how to put the data together (cluster) by aligning the data in a particular manner. Application of rule530determines how things change over time, or not, but not what the correlation or similarity actually is, which is generally done through the rule528. Part of the reason for splitting the rules is to delay decision-making as long as possible in an effort to cleverly use more information, such as that provided by the user, for an increasingly accurate finding.

The outcome of the data cluster516can be transmitted to another processor, system, user, or any other entity.

Another example of the manner rules are employed, outside of the medical community, is for example, in determining parameters of hair where rule526is used to look for length of hair and rule528uses the outcome of the length of hair to further determine alopecia as compared with normal hair growth. Rule530may 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 toFIGS.6-11.

As with the blocks of the MINE112ofFIG.1, it is understood that the blocks shown inFIG.5, such as block510and514, and516may 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.

FIGS.6and7each show examples of applying the rules526, and528and530, to the data506to yield certain beneficial results. InFIG.6, rule526is applied to the data506to 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.

Using the same example, rules528and530may be applied to the outcome of the rule526to the data506to 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 rule528, after applying rule526such that the outcome of rule526detects Ibuprofen types of medications and rule528narrows the detection to those with a threshold dosage.

FIG.7shows an application of the rules528and530where a set of associated terms, m1(c), has been identified and another set of associated items, m2(c), has been identified. For example m1(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, rule526, is the time base characteristics. Rules for clustering, rules528, 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.

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 m1(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 rules526,528, and530, there can be different ways of displaying information, from the data clusters516, about a concept under different intents.

By way of further explanation, the rules528are used to determine what is considered inside the cluster and the rules530is 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 rules528are 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 ofFIG.5advantageously learns whether they “belong” or not. Through the rule530, the Ibuprofen cluster might emphasize recent events (past week) in the ranking. Other clusters may interact differently with time.

FIG.11shows a flow chart of the steps performed by the block514ofFIG.5in applying the rules therein, in accordance with an exemplary method of applying intent-based clustering and display to the data506ofFIG.5.

InFIG.11, at step1151, an automatic or manual, or a combination, of attribute selection is performed by applying rules526and528, 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 block514, in an exemplary embodiment of the invention.

Next, at step1153, 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 data506can 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.

Next, at1155, the distance between the data506'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 step1159, otherwise, step1157, such data is rejected (not included) in the cluster.

III. Patient Retention in Network

Now that the mechanisms of the MINE112have been described in detail, attention should be turned toFIGS.8A-8C, which discloses means for patient retention through referral analytics and management. The MINE112provides the ability to track patient referrals in a manner which may guide practitioners to refer patients in network, and can provide tools for targeting physician education and training on referral practices.

Medical foundations refer substantial patient care outside the Medical Network where equal or superior care is available within the network. These referrals are often uncoordinated and not uniformly reported using existing stacking systems. For most medical providers, it is not clear where these patients are referred or for what reason(s) and the related costs. To ensure affordable, quality care and positive patient experience better referral analytics are desired.

FIG.8Aillustrates that the optimization of patient retention in network relies upon three core areas: 1) patient retention enhancement, 2) patient retention management, and 3) enablers of patient retention. The first category of retention optimization relies upon medical network procedures and education in order to increase patient retention. This is well known, but in order to effectively implement these actions, retention analytics, including referral analytics, are desirable. For example, a procedure for placing quality standards for referrals outside of network may not be effective if the practice area rarely engages in referral practices. In a similar manner, patient retention enablers, such as marketing, central logic systems, and set payment rates enable the retention of patients through affordability and quality of care.

As previously noted, in order to drive enablers to enhance patient retention, patient retention management systems are employed. These systems collect data, generate referral analytics, and otherwise compile and analyze relevant data. The MINE112is a particularly powerful tool capable of performing many of these activities.

Moving toFIG.8B, a physician referral network is illustrated, for context. The goal of any patient referral optimization is to ensure the best patient experience, outcomes and cost. This illustration provides a representative example of what a typical physician referral network may look like, and relative costs associated with the various providers.

FIG.8Cprovides an example diagram for a complete referral lifecycle. In this example, a patient has an initial encounter which yields a visit note, a referral and a claim. The referral may be for a specialist or an internal referred encounter. A procedure note or consult note are generated from this interaction. A return encounter is then made, with the generation of another visit note. These records of the encounter may be utilized by the MINE112to determine referral activity in ways currently not possible without manual review of each note.

The MINE112is able to analyze all referral data to establish an analytical dashboard that provides benchmarking, outcome measures, and enables knowledge driven care. Existing referral workflow systems (i.e. Epic, etc.) only have the ability to report, track and manage referrals if entered. Currently, most referral data is undefined, untrackable and unmanageable, thus making referral workflow systems inefficient. The MINE112is capable of picking out the referral data in a manageable form for consumption by the referral workflow systems. With more robust referral data, these referral workflow systems will be able to assist in the development of strategies that optimize access, continuity of care, resource management, affordability, quality, and patient/physician satisfaction.

The disclosed system may then utilize the referral data to generate one or more metrics of compliance by physicians to preferred referral reporting. An example of such a metric is defined by Formula A:

Formula⁢A=Number⁢of⁢in⁢network⁢referrals⁢reportedin⁢the⁢workflow⁢systemTotal⁢Number⁢of⁢in⁢network⁢referrals

Further, a second metric can be computed which reveals opportunities for improvement of out of network reporting. An example of such a metric is defined by Formula B:

Formula⁢B=Number⁢of⁢out⁢network⁢referrals⁢reportedin⁢the⁢workflow⁢systemTotal⁢Number⁢of⁢out⁢network⁢referrals

The denominator values for these metrics necessitate the usage of the MINE112to scour patient records in order to capture all incidences where a referral is given. In order to ensure complete capture of referrals, the MINE112data was compared to auditing data. The results of these comparisons are provided in Table 1.

TABLE 1Analytics of referral versus internal AuditReferral entriesInferred referralsin workflownot alreadyFormula BMethodsystemcapturedTotalresultsMINE25617342960%AnalysisInternal21813134962%Audit

As can be seen, given similar samples, the results of the automated MINE112modeling of referrals is statistically similar to the results of a costly and time consuming audit. Also striking, is that the referral reporting practices differ significantly when it is an in network, HMO style, practice, as compared to an out of network, PPO style arrangement. Table 2 provides the referral reporting rates for these two scenarios:

TABLE 2Analytics of referral reporting for in network versus out of networkReferral entriesInferred referralsin workflownot alreadyMethodsystemcapturedTotalResultsIn network29,4569,54238,99876%(Formula A)Out of network13,3659,47922,84459%(Formula B)

The MINE112is also able to utilize its analytical capabilities to pinpoint the distribution of referral services.FIG.9Aprovides breakdowns of referral types. Interestingly, the referral distributions have significant differences between in network and out of network referrals. For example, radiology and surgery are referred more frequently when out of network, and hospital and physical therapy is more often referred in network.

FIG.9Bprovides a graph illustrating where referrals were located when not in the referral workflow system. The overwhelming majority of these referrals were sent out of network, which on a whole is more costly, and does not deliver a higher level of care. For this very reason, the capture of un-reported referral data is critical to the control over health care costs, and the optimization of patient retention through better outcomes at lower costs.

Lastly, while the architecture of the MINE112, and the analytics performed to capture referral data that is otherwise not reported has been disclosed in considerable detail, specific examples of referral modeling are helpful for further clarification.FIGS.10A-10Eprovide such examples.

For instance, inFIGS.10A and10B, physician notes can be analyzed for a specific procedure referral, even when the referral has not been reported into a referral workflow system. In contrast,FIGS.10C and10Dprovide an instance where referral activity is being reported in the workflow system (MRI referral) but the physician's notes provide a more complete story (referral is also for occupational therapy).

FIG.10Eprovides an example of which data is deemed relevant for some embodiment of the MINE112as part of the analysis. This includes cost data, quality data, and patient experience data.

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.