US20150120328A1 - Population health condition worklist - Google Patents

Abstract

Methods, systems, computer storage media, and graphical user interfaces for population health management are disclosed. The population health management system may allow for cross-continuum tracking and subsequent interactions with transactional systems, providers, and/or patients. The population health management system may include utilizing clinically relevant algorithms to populate registries to enable healthcare providers to better facilitate care for a population of patients. The population health management system may consolidate and provide comprehensive condition-specific and/or patient situation specific information that is accessible and updatable across venues. The population health management system may create cross venue antibiograms based on medications information and susceptibility results which can be filtered for selected demographics. The population health management system may be utilized to provide multiple medication options including dosing, generic alternatives, cost, availability, and susceptibility information. Inappropriate trends may be flagged and monitored and medication stewards may be alerted or notified to intervene.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This Application is a continuation of U.S. patent application Ser. No. 14/502,336, filed Sep. 30, 2014, which claims priority to U.S. Provisional Application Ser. No. 61/885,359, filed Oct. 1, 2013, and U.S. Provisional Application Ser. No. 61/888,313, filed Oct. 8, 2013, herein incorporated by reference in their entireties, and is related to commonly assigned U.S. Patent Applications entitled “Population-Based Medication Stewardship” (Attorney Docket CRNI.197241), “Comprehensive Medication Advisor” (Attorney Docket CRNI.213287), “Population Health Care Transition” (Attorney Docket CRNI.208054), “Population Health Condition Management” (Attorney Docket CRNI.208055), and “Population Health Situational Awareness” (Attorney Docket CRNI.208056), filed concurrently herewith on the same date.
BRIEF SUMMARY
• This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
• Embodiments of the present invention generally relate to designing and utilizing population health programs to allow for cross-continuum tracking and subsequent interactions with transactional systems, providers, patients, etc. Clinically relevant algorithms may be utilized to populate registries, which can enable healthcare providers to better facilitate care for a population of patients. Comprehensive condition-specific and/or patient situation specific information may be consolidated and provided that is accessible and updatable by multiple providers and venues. Cross venue care related information (e.g., antibiograms based on culture, medications information, and/or susceptibility results) may be created which can be filtered for selected demographics. Multiple medication and/or treatment options including dosing, generic alternatives, cost, availability, and susceptibility information may be provided and inappropriate trends may be flagged and monitored so medication stewards can be alerted or notified to intervene.
• Accordingly, in one aspect, an embodiment of the present invention is directed to one or more computer storage media storing computer-executable instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform a method that facilitates designing and utilizing population health programs. The method includes receiving, at a population health server, healthcare data from disparate sources. The method further includes utilizing the population health server to identify a population of patients based on a set of criteria. The method also includes utilizing the population health server to stratify the population of patients based on one or more algorithms to create one or more groups of patients. At least one group of the one or more groups of patients comprises a plurality of patients having at least one substantially similar attribute. The method further includes utilizing the population health server to create at least one registry, the at least one registry comprising at least a portion of the one or more groups.
• A further embodiment is directed to a system that includes one or more processors; and a non-transitory computer storage medium storing computer-useable instructions that, when used by the one or more processors, cause the one or more processors to: receive healthcare data from disparate sources; identify a population of patients based on a set of criteria; stratify the population of patients based on one or more algorithms; and create a registry for at least a portion of the population of patients, wherein the registry accounts for one or more of: resources available to a patient; lifestyle and prognostic assets that can be used for prediction; and assets necessary for attribution, allocation, or measurement.
• In another embodiment of the invention, an aspect is directed to one or more computer storage media storing computer-executable instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform a method that facilitates designing and utilizing population health programs. The method includes receiving, at a population health server, healthcare data from disparate sources. The healthcare data may comprise one or more of clinical data, healthcare-related financial data, and patient sensor and/or patient device data. The method further includes utilizing the population health server to identify a population of patients based on one or more medical conditions. The method also includes utilizing the population health server to stratify the population of patients into one or more groups based on at least one algorithm. Each group of the one or more groups may comprise one or more patients having a substantially similar medical condition. The method further includes providing an opportunity for a clinician to confirm an output of the at least one algorithm. The method also includes utilizing the population health server to create at least one registry for the population of patients based on at least a portion of the output of the at least one algorithm.
• In another aspect, an embodiment of the present invention is directed to one or more computer storage media storing computer-executable instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform a method for providing a cross venue antibiogram. The method comprises receiving medications information from disparate sources including information from multiple venues, multiple providers, and across multiple conditions. The method further comprises receiving susceptibility results based on testing associated with patient information from the disparate sources. The method also comprises creating a cross venue antibiogram based on the medications information and the susceptibility results. The method further comprises communicating the cross venue antibiogram to a clinician device.
• In another embodiment of the invention, an aspect is directed to a computer-implemented method. The method includes receiving, from a clinician device, a selection of a disease state for a patient. The method further includes receiving patient information, from an Electronic Medical Record (EMR). The patient information includes related conditions, laboratory results, and allergy information for the patient. The method also includes utilizing susceptibility data, based on a cross venue antibiogram, to provide one or more medication options for the disease state. The antibiogram is based on medications information from disparate sources including multiple venues, multiple providers, and across multiple conditions. The method further includes providing the one or more medication options to the clinician device. The one or more medication options includes one or more of dosing, generic alternatives, cost, and availability.
• A further embodiment is directed to a system that includes one or more processors; and a non-transitory computer storage medium storing computer-useable instructions that, when used by the one or more processors, cause the one or more processors to: receive medications information from disparate data sources, the data sources including multiple venues, multiple providers, and across multiple conditions; receive susceptibility results based on testing associated with patient information provided by the disparate sources; create a cross venue antibiogram based on the medications information and the susceptibility results; provide the cross venue antibiogram to a device associated with a clinician; and enable filtering of the cross venue antibiogram based on selected demographics, the selected demographics including an institution, a practice associated with a clinician, a zip code, a county, a city, a state, a region, or a country.
• In another aspect, an embodiment of the present invention is directed to one or more computer storage media storing computer-executable instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform a method for stratifying one or more patients into one or more groups. The method includes receiving, at a population health server, healthcare data, where the healthcare data includes clinical impressions and/or clinical narratives from one or more healthcare providers. The method further includes utilizing the population health server for natural language processing to extract one or more clinical indicators from the healthcare data. In addition, the method includes utilizing the population health server to stratify one or more patients into one or more groups based on at least a portion of the one or more clinical indicators. Furthermore, the method includes utilizing the population health server to create at least one registry including the one or more groups. The at least one registry accounts for one or more of: resources available to a patient; lifestyle and prognostic assets that can be used for prediction; and assets necessary for attribution, allocation, or measurement.
• In another aspect, a further embodiment is directed to a computer system that stratifies one or more patients into one or more groups, the computer system including a processor coupled to a computer storage medium, the computer storage medium having stored thereon a plurality of computer software components executable by the processor. The computer software components include a receiving component that receives healthcare data, where the healthcare data includes clinical impressions and/or clinical narratives from one or more healthcare providers. The computer software components further include a natural language processing component that extracts one or more clinical indicators from the healthcare data, and a stratifying component that utilizes one or more algorithms to stratify one or more patients into one or more groups based on at least a portion of the one or more clinical indicators. In addition, the computer software components include a creating component that creates at least on registry. The at least one registry includes at least a portion of the one or more groups, where the at least one registry accounts for one or more of: resources available to a patient; lifestyle and prognostic assets that can be used for prediction; and assets necessary for attribution, allocation, or measurement.
• In another aspect, an embodiment of the present invention is directed to one or more computer storage media storing computer-executable instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform a method for stratifying one or more patients into one or more groups. The method includes receiving, at a population health server, healthcare data from disparate sources, where the healthcare data includes clinical impressions and/or clinical narratives from one or more healthcare providers. The method further includes utilizing the population health server for natural language processing to extract one or more clinical indicators from the healthcare data, where the one or more clinical indicators are associated with one or more chronic conditions. In addition, the method includes providing a relevance rating to each of the one or more clinical indicators, and utilizing the population health server to stratify one or more patients into one or more groups based on at least a portion of the one or more clinical indicators. Further, the method includes utilizing the population health server to create at least one registry including the one or more groups, where the at least one registry accounts for one or more of: resources available to a patient; lifestyle and prognostic assets that can be used for prediction; and assets necessary for attribution, allocation, or measurement.
• In another aspect, an embodiment of the present invention is directed to one or more computer storage media storing computer-executable instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform a method that facilitates using at least one clinically relevant algorithm in population health programs. The method includes receiving, at a population health server, healthcare data from disparate sources. The method further includes utilizing the population health server to stratify a population of patients based on one or more algorithms to create one or more groups of patients, where at least one group of the one or more groups of patients comprises a plurality of patients having at least one substantially similar attribute. The one or more algorithms include at least one clinically relevant algorithm utilizing clinical data. In addition, the method includes utilizing the population health server to create at least one registry, the at least one registry including at least a portion of the one or more groups.
• In another aspect, a further embodiment is directed to a computer system that facilitates designing and utilizing population health programs, the computer system including a processor coupled to a computer storage medium, the computer storage medium having stored thereon a plurality of computer software components executable by the processor. The computer software components include a receiving component that receives healthcare data from disparate sources, and a stratifying component that stratifies a population of patients based on one or more algorithms. The one or more algorithms comprising at least one clinically relevant algorithm. The computer software components further include a creating component that creates a registry for at least a portion of the population of patients. The registry accounts for one or more of: resources available to a patient; lifestyle and prognostic assets that can be used for prediction; or assets necessary for attribution, allocation, or measurement.
• In another aspect, an embodiment of the present invention is directed to one or more computer storage media storing computer-executable instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform a method that facilitates utilizing clinically relevant algorithms for registry population. The method includes receiving, at a population health server, healthcare data from disparate sources, and utilizing the population health server to identify a population of patients based, at least partly, on one or more medical conditions. The method further includes utilizing the population health server to stratify the population of patients based on at least a clinically relevant algorithm. The clinically relevant algorithm utilizes clinical data, and the clinical data includes one or more of medication information, laboratory values, diagnostics, clinician narratives, and clinician assessments. In addition, the method includes utilizing the population health server to create at least one registry for the population of patients based on at least a portion of an output of the clinically relevant algorithm. The method further includes utilizing the population health server to update the at least one registry when additional clinical data is available for the clinically relevant algorithm to utilize.
BRIEF DESCRIPTION OF THE DRAWINGS
• Embodiments are described in detail below with reference to the attached drawing figures, wherein:
• FIG. 1 is a block diagram of an exemplary computing environment suitable to implement embodiments of the present invention;
• FIG. 2 is a block diagram of an exemplary population health management system to implement embodiments of the present invention;
• FIG. 3 is a flow diagram illustrating exemplary methods of utilizing an identification algorithm for registry population, in accordance with embodiments of the present invention;
• FIG. 4 is a flow diagram illustrating exemplary methods of utilizing a stratification algorithm for stratification one or more patients in a registry, in accordance with embodiments of the present invention;
• FIG. 5 is a flow diagram illustrating exemplary methods for utilizing an algorithm to provide transition management care, in accordance with embodiments of the present invention;
• FIG. 6 is a flow diagram illustrating exemplary methods for utilizing an algorithm to provide transition management care, in accordance with embodiments of the present invention;
• FIG. 7 is a flow diagram illustrating exemplary methods for utilizing an algorithm to provide transition management care, in accordance with embodiments of the present invention;
• FIG. 8 is a flow diagram illustrating exemplary methods for utilizing an algorithm to provide transition management care, in accordance with embodiments of the present invention;
• FIG. 9 is a flow diagram illustrating exemplary methods of utilizing an identification algorithm for registry population, in accordance with embodiments of the present invention;
• FIG. 10 is a flow diagram illustrating exemplary methods of utilizing a stratification algorithm for stratification one or more patients in a registry, in accordance with embodiments of the present invention;
• FIG. 11 is a flow diagram illustrating exemplary methods for utilizing an algorithm to provide transition management care, in accordance with embodiments of the present invention;
• FIG. 12 is a flow diagram illustrating exemplary methods for utilizing an algorithm for assigning a physician to one or more patient in a heart failure registry, in accordance with embodiments of the present invention;
• FIG. 13 is a flow diagram illustrating exemplary methods for utilizing an algorithm to provide transition management care, in accordance with embodiments of the present invention;
• FIGS. 14-27 depict illustrative screen displays, in accordance with exemplary embodiments of the present invention;
• FIG. 28 is a flow diagram illustrating an exemplary method that facilitates designing and utilizing population health programs, in accordance with embodiments of the present invention;
• FIG. 29 is a flow diagram illustrating an exemplary method that facilitates designing and utilizing population health programs, in accordance with embodiments of the present invention;
• FIG. 30 is a flow diagram illustrating an exemplary method for stratifying one or more patients into one or more groups, in accordance with embodiments of the present invention;
• FIG. 31 is a flow diagram illustrating an exemplary method for stratifying one or more patients into one or more groups, in accordance with embodiments of the present invention;
• FIG. 32 is a flow diagram illustrating an exemplary method for facilitating the use of at least one clinically relevant algorithm in population health programs, in accordance with embodiments of the present invention;
• FIG. 33 is a flow diagram illustrating an exemplary method for facilitating the use of clinically relevant algorithms for registry population, in accordance with embodiments of the present invention;
• FIG. 34 is a flow diagram illustrating an exemplary method for providing a cross venue antibiogram, in accordance with embodiments of the present invention; and
• FIG. 35 is a flow diagram illustrating an exemplary method for providing a comprehensive medication advisor, in accordance with embodiments of the present invention;
DETAILED DESCRIPTION
• The subject matter of the present invention is described with specificity herein to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the terms “step” and/or “block” may be used herein to connote different elements of methods employed, the terms should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described.
• Currently there is not a comprehensive and convenient healthcare management system and/or method for a user, e.g., a healthcare provider, to understand populations of patients within their own transactional system, much less across a community or geographic area. Further, current population healthcare management systems are limited in that such systems do not effectively utilize various types of data associated with a population of patients, nor do such systems provide effective consistency across all venues and conditions.
• Accordingly, various aspects of the technology described herein are generally directed to methods, systems, computer storage media, and graphical user interfaces for population health management. Various embodiments of the present invention are directed to facilitating the design and utilization of a population health management system to allow for cross-continuum tracking and subsequent interactions with transactional systems, providers, patients, etc. In embodiments, the population health management system can include utilizing clinically relevant algorithms to populate registries, which can enable healthcare providers to better facilitate care for a population of patients. In certain embodiments, the population health management system can consolidate and provide comprehensive condition-specific and/or patient situation specific information that is accessible and updatable by multiple providers and venues. In embodiments, the population health management system can create cross venue antibiograms based on medications information and susceptibility results which can be filtered for selected demographics. In embodiments, the population health management system can be utilized to provide multiple medication options including dosing, generic alternatives, cost, availability, and susceptibility information. In embodiments, inappropriate trends may be flagged and monitored and medication stewards may be alerted or notified to intervene.
• An exemplary computing environment suitable for use in implementing embodiments of the present invention is described below.FIG. 1 is an exemplary computing environment (e.g., medical-information computing-system environment) with which embodiments of the present invention may be implemented. The computing environment is illustrated and designated generally asreference numeral100. Thecomputing environment100 is merely an example of one suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should thecomputing environment100 be interpreted as having any dependency or requirement relating to any single component or combination of components illustrated therein.
• The present invention might be operational with numerous other purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that might be suitable for use with the present invention include personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above-mentioned systems or devices, and the like.
• The present invention might be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Exemplary program modules comprise routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. The present invention might be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules might be located in association with local and/or remote computer storage media (e.g., memory storage devices).
• With continued reference toFIG. 1, thecomputing environment100 comprises a computing device in the form of acontrol server102. Exemplary components of thecontrol server102 comprise a processing unit, internal system memory, and a suitable system bus for coupling various system components, includingdata store104, with thecontrol server102. The system bus might be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus, using any of a variety of bus architectures. Exemplary architectures comprise Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronic Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus, also known as Mezzanine bus.
• Thecontrol server102 typically includes therein, or has access to, a variety of computer-readable media. Computer-readable media can be any available media that might be accessed bycontrol server102, and includes volatile and nonvolatile media, as well as, removable and nonremovable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed bycontrol server102. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.
• Thecontrol server102 might operate in acomputer network106 using logical connections to one or moreremote computers108.Remote computers108 might be located at a variety of locations in a medical or research environment, including clinical laboratories (e.g., molecular diagnostic laboratories), hospitals and other inpatient settings, veterinary environments, ambulatory settings, medical billing and financial offices, hospital administration settings, home healthcare environments, and clinicians' offices. Clinicians or healthcare providers may comprise a treating physician or physicians; specialists such as surgeons, radiologists, cardiologists, and oncologists; emergency medical technicians; physicians' assistants; nurse practitioners; health coaches; nurses; nurses' aides; pharmacists; dieticians; microbiologists; laboratory experts; laboratory technologists; genetic counselors; researchers; veterinarians; students; and the like. Theremote computers108 might also be physically located in nontraditional medical care environments so that the entire healthcare community might be capable of integration on the network. Theremote computers108 might be personal computers, servers, routers, network PCs, peer devices, other common network nodes, or the like and might comprise some or all of the elements described above in relation to thecontrol server102. The devices can be personal digital assistants or other like devices.
• Computer networks106 comprise local area networks (LANs) and/or wide area networks (WANs). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. When utilized in a WAN networking environment, thecontrol server102 might comprise a modem or other means for establishing communications over the WAN, such as the Internet. In a networking environment, program modules or portions thereof might be stored in association with thecontrol server102, thedata store104, or any of theremote computers108. For example, various application programs may reside on the memory associated with any one or more of theremote computers108. It will be appreciated by those of ordinary skill in the art that the network connections shown are exemplary and other means of establishing a communications link between the computers (e.g.,control server102 and remote computers108) might be utilized.
• In operation, an organization might enter commands and information into thecontrol server102 or convey the commands and information to thecontrol server102 via one or more of theremote computers108 through input devices, such as a keyboard, a pointing device (commonly referred to as a mouse), a trackball, or a touch pad. Other input devices comprise microphones, satellite dishes, scanners, or the like. Commands and information might also be sent directly from a remote healthcare device to thecontrol server102. In addition to a monitor, thecontrol server102 and/orremote computers108 might comprise other peripheral output devices, such as speakers and a printer.
• Although many other internal components of thecontrol server102 and theremote computers108 are not shown, such components and their interconnection are well known. Accordingly, additional details concerning the internal construction of thecontrol server102 and theremote computers108 are not further disclosed herein.
• Turning now toFIG. 2, an exemplary populationhealth management system200 suitable for use in implementing embodiments of the present invention is depicted. The populationhealth management system200 is merely an example of one suitable computing system environment and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the present invention. Neither should the populationhealth management system200 be interpreted as having any dependency or requirement related to any single module/service/component or combination of modules/services/components illustrated therein.
• The populationhealth management system200 may include apopulation health server250, electronic medical records212 (EMRs),activity data214 patient and/or populationdemographic information216,consumer profile information218,provider information220, one or moreoutput registry databases230, and/or one ormore computing devices240, all in communication with each other through wired or wireless connections and/or through thenetwork210. Thenetwork210 may include, without limitation, one or more local area networks (LANs) and/or wide area networks (WANs). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet. Accordingly, the network is not further described herein.
• In embodiments, theEMRs212 may span multiple applications, multiple providers, multiple patients, multiple conditions, multiple venues, multiple facilities, multiple organizations, and/or multiple communities. Embodiments of theEMRs212 may include one or more data stores of healthcare records, which may include one or more computers or servers that facilitate the storing and retrieval of the healthcare records. In some embodiments, one or more EMRs212 may be implemented as a cloud-based platform or may be distributed across multiple physical locations. Example embodiments of theEMRs212 may include hospital, ambulatory, clinic, health exchange, and health plan records systems. TheEMRs212 may further include record systems, which store real-time or near real-time patient (or user) information, such as wearable, bedside, or in-home patient monitors, for example. It is further contemplated that embodiments of theEMRs212 may use distinct clinical ontologies, nomenclatures, vocabularies, or encoding schemes for clinical information, or clinical terms. Further, in some embodiments, theEMRs212 may be affiliated with two or more separate health care entities and/or venues that use two or more distinct nomenclatures.
• In embodiments, theEMRs212 described herein may include healthcare data. As used herein, healthcare data refers to any healthcare or medical care data related or relevant to a patient. Healthcare data may include, but is not limited to, clinical data and healthcare-related financial data. Clinical data, as used herein, refers to any healthcare or medical data particular to a patient. In embodiments, clinical data can be medical care or healthcare data resulting from or associated with a health or medical service performed in association with a clinician in a healthcare environment (e.g., lab test, diagnostic test, clinical encounter, ecare, evisit, etc.). Clinical data may include, but is not limited to, a health history of a patient, a diagnosis, a clinician assessment, clinician narrative, a treatment, a family history (including family health history and/or family genetics), an immunization record, a medication, age, gender, date of birth, laboratory values, diagnostics, a test result, an allergy, a reaction, a procedure performed, a social history, an advanced directive, frequency and/or history of healthcare facility visits, current healthcare providers and/or current healthcare provider location, preferred pharmacy, prescription benefit management data, an alert, claims data, a vital, data traditionally captured at the point of care or during the care process, a combination thereof, and the like. In the same or alternative embodiments, the clinical data may include medical compliance information. In certain embodiments, medical compliance information refers to a level of compliance of a particular patient with one or more prescribed medical treatments, such as medications, diet, physical therapy, follow up healthcare visits, and the like. In one or more embodiments, the clinical data may include data obtained from the natural language processing of one or more clinical assessments and/or clinical narratives.
• In certain embodiments, healthcare-related financial data can refer to any financial information relevant to a patient, such as insurance data, claims data, payer data, etc. Such healthcare data (e.g., clinical data and healthcare-related financial data) may be submitted by a patient, a care provider, a payer, etc. In certain embodiments where the healthcare data is being submitted by anyone other than the patient, the patient may be required to approve of such submission and/or may opt-in to or opt-out of having such healthcare data being submitted.
• In embodiments,activity data214 can refer to health actions or activities performed by a patient outside of, or remote from, a healthcare environment. Embodiments ofactivity data214 may include one or more data stores ofactivity data214, which may include one or more computers or servers that facilitate the storing and retrieval of theactivity data214. In some embodiments, theactivity data214 may be implemented as a cloud-based platform or may be distributed across multiple physical locations. Example embodiments of theactivity data214 may include nutrition information and/or exercise information for a patient. In certain embodiments, at least a portion of theactivity data214 may be recorded utilizing a personal fitness tracker, a smart phone, and/or an application provided by a smart phone. In various embodiments, theactivity data214 may include data obtained from a patient's car. For example, in such embodiments, theactivity data214 may include data on the amount of driving the patient does versus the amount of walking the patient does.
• In one or more embodiments, theactivity data214 may be submitted by a patient, a third party associated with a personal fitness tracker and/or smart phone (such as a software developer or device manufacturer), a care provider, a payer, etc. In certain embodiments where theactivity214 is being submitted by anyone other than the patient, the patient may be required to approve of such submission and/or may opt-in to or opt-out of having such healthcare data being submitted.
• The patient and/or populationdemographic information216 may include age, gender, date of birth, address, phone number, contact preferences, primary spoken language, technology access (e.g., internet, phone, computer, etc.), transportation (e.g., common modes of transportation), education level, motivation level, work status (student, full-time, retired, unemployed, etc.), and/or income. In certain embodiments, the patient and/or populationdemographic information216 may include community resource information, which may include, but is not limited to, fitness facility information, pharmacy information, food bank information, grocery store information, public assistance programs, homeless shelters, etc. In embodiments, the motivation level can include the level of motivation a particular patient has for maintaining their health, which may be derived from other information (e.g., data from personal fitness tracker, indication the patient regularly visits a clinician for check-ups, consumer profile information, etc.). Embodiments of the patient and/or populationdemographic information216 may include one or more data stores ofdemographic information216 which may include one or more computers or servers that facilitate the storing and retrieval of thedemographic information216. In some embodiments, the patient and/or populationdemographic information216 may be implemented as a cloud-based platform or may be distributed across multiple physical locations. In embodiments, the patient and/orpopulation demographics216 may be obtained through any source known to one skilled in the art. For example, in certain embodiments, at least a portion of the patient and/or populationdemographic information216 may be submitted by a third party that relies on census data. In various embodiments, the patient and/or populationdemographic information216 may be obtained from more than one source. In one embodiment, the patient may submit any or all of the patient and/or populationdemographic information216. In certain embodiments, all or a portion of the patient and/or populationdemographic information216 may be anonymized using techniques known to one skilled in the art.
• In one or more embodiments, theconsumer profile information218 may include any or all of the spending habits of one or more patients within a population. For instance, in certain embodiments, theconsumer profile information218 may include information associated with grocery store purchases, athletic or exercise equipment purchases, restaurant purchases, and/or purchases of vitamins and/or supplements. Embodiments of theconsumer profile information218 may include one or more data stores ofconsumer profile information218 which may include one or more computers or servers that facilitate the storing and retrieval of theconsumer profile information218. In some embodiments, theconsumer profile information218 may be implemented as a cloud-based platform or may be distributed across multiple physical locations. In one embodiment, a patient may provide theconsumer profile information218, for example, by linking checking account and/or checking account purchase information to at least a portion of the populationhealth management system200 and/or to a health insurance carrier.
• Thecare provider information220 may include any information relating to a particular care provider or healthcare facility. In one embodiment, thecare provider information220 may include information relating to the number of healthcare providers and their specialties at a particular care provider location. In the same or alternative embodiments, thecare provider information220 may include information relating to non-personnel type resources at a particular care provider location, such as the amount and types of medications and/or the amount and types of surgical or other medical equipment. In one embodiment, thecare provider information220 may include one or more of address and contact information, accepted payer information, status on accepting new patients, transactional systems, primary spoken language, hospital affiliations, and/or care delivery models. In embodiments, thecare provider information220 may include information relating to the availability of any or all resources at a particular healthcare facility including personnel and/or non-personnel resources. Embodiments of thecare provider information220 may include one or more data stores ofcare provider information220 which may include one or more computers or servers that facilitate the storing and retrieval of thecare provider information220. In some embodiments, thecare provider information220 may be implemented as a cloud-based platform or may be distributed across multiple physical locations. In one embodiment, thecare provider information220 can be provided by a healthcare provider, and/or a third party, such as an insurance provider or management entity.
• In one or more embodiments, theoutput registry databases230, which may include the output registries, may be networked storage or distributed storage including storage on servers located in the cloud. Thus, it is contemplated that for some embodiments, the information stored in theoutput registry databases230 is not stored in the same physical location. The information within theoutput registry databases230 may exist in a variety of standardized formats including, for example, narratives and other data. Information in theoutput registry databases230 may be categorized or classified according to, for example, claims, diagnoses, wellness, satisfaction, population directories, and the like.
• In various embodiments, each output registry may be used by, for example, a healthcare organization to manage the health of a population segment. In one or more embodiments, each output registry may be condition specific. By way of example, a healthcare organization or clinician may manage diabetic patients within a proscribed geographic area. The condition in this example is diabetes mellitus and the output registry may help the healthcare organization manage a population segment with this condition. The output registry may, in one aspect, include identified patients within a population segment who have this condition or have risk factors that may lead to the development of diabetes, such as those identified by the identifyingcomponent254 of thepopulation health server250. The output registry may further include stratified patients within an identified segment by degree of severity or risk, such as those stratified by the stratifyingcomponent256 of thepopulation health server250. The stratified patients in an output registry may facilitate the generation of interventions or action workflows designed to reduce disease severity or risk and to improve outcome. Additional uses for the output registries are to measure outcomes related to treatment interventions and also to attribute patients within the identified segment to appropriate healthcare providers (e.g., primary care physicians, care managers health coaches, specialists such as endocrinologists, podiatrists, and the like).
• In embodiments, thedevices240 can include a remote computer, such as theremote computers108 discussed above with reference toFIG. 1. In one or more embodiments, thedevices240 can include any or all of the properties and parameters of theremote computers108 discussed above with reference toFIG. 1. In certain embodiments, any or all portions of output generated by the population health server, e.g., theoutput registries230, theantibiogram database235, etc., may be provided to or accessible via one or more of thedevices240.
• Thepopulation health server250 depicted inFIG. 2 is merely exemplary. While thepopulation health server250 is illustrated as a single unit, it will be appreciated that thepopulation health server250 may include one or more separate components, services, and/or modules. Further in embodiments, thepopulation health server250 may be scalable. For example, thepopulation health server250 may in actuality include a plurality of computing devices in communication with one another. Components of thepopulation health server250 may include a processing unit, internal system memory, and a suitable system bus for coupling various system components, including one or more data stores for storing information (e.g., files and metadata associated therewith). In embodiments, each of these components/services/modules typically includes, or has access to, a variety of computer-readable media.
• In some embodiments, one or more of the illustrated components of thepopulation health server250 may be implemented as one or more stand-alone applications. Further, various components, services, and/or modules may be located on any number of servers. By way of example only, thepopulation health server250 might reside on a server, cluster of servers, a cloud-computing device or distributed computing architecture, or a computing device remote from one or more of the remaining components.
• It should be understood that this and other arrangements described herein are set forth only as examples. Other arrangements and elements (e.g., machines, interfaces, functions, orders, and groupings of functions, etc.) can be used in addition to or instead of those shown, and some elements may be omitted altogether. Further, many of the elements described herein are functional entities that may be implemented as discrete or distributed components or in conjunction with other components and/or modules, and in any suitable combination and location. Various functions described herein as being performed by one or more entities may be carried out by hardware, firmware, and/or software. For instance, various functions described herein with reference to thepopulation health server250 may be carried out by a processor executing instructions stored in memory.
• As discussed above, thepopulation health server250 may comprise one or more components, services, and/or modules. For example, as depicted inFIG. 2, thepopulation health server250 may include areceiving component252, an identifyingcomponent254, astratifying component256, a creatingcomponent258, anoutput component260, aprediction component262, aconsolidation component264, aworklist component266, asituational component268, a naturallanguage processing component270, anantibiogram component272, amedication advisor component274, amedication stewardship component276, amanagement component278, ahealthcare transition component280, acondition component282, a patientportal component284, and abaseline component286. In certain embodiments, one or more of thecomponents252,254,256,258,260,262,264,266,268,270,272,274,276,278,280,282,284, and286 may be configured to provide or convey information that can populate a graphical user interface, which may be viewed on a device, such as one of thedevices240.
• In one or more embodiments, one or more of thecomponents252,254,256,258,260,262,264,266,268,270,272,274,276,278,280,282,284, and286 may be implemented as stand-alone applications. In other embodiments, one or more of thecomponents252,254,256,258,260,262,264,266,268,270,272,274,276,278,280,282,284, and286 may be integrated directly into the operating system of a computing device, such as theremote computer108 ofFIG. 1 and/or the one ormore computing devices240 ofFIG. 2. It will be understood that thecomponents252,254,256,258,260,262,264,266,268,270,272,274,276,278,280,282,284, and286 illustrated inFIG. 2 are exemplary in nature and in number and should not be construed as limiting. Any number of components and/or modules may be employed to achieve the desired functionality within the scope of embodiments hereof.
• In certain embodiments, the receivingcomponent252 can receive healthcare data from disparate sources. In one or more embodiments, the disparate sources may include one or more EMRs, e.g., theEMRs212, each of which may be independent from one another. In certain embodiments, the disparate sources may include a plurality of EMRs, e.g., theEMRs212. In embodiments, the plurality of EMRs may be associated with a plurality of healthcare providers, a plurality of patients, a plurality of medical conditions, a plurality of healthcare venues and/or facilities, a plurality of organizations, and/or a plurality of communities. In certain embodiments, at least a portion of the EMR's received by the receivingcomponent252 may be associated with the same patient.
• In one or more embodiments, in addition to or in place of the healthcare data, the receivingcomponent252 can receive one or more of activity data, e.g., theactivity data214; demographic information, e.g., the patient and/or populationdemographic information216; consumer information, e.g., theconsumer profile information218; and provider information, e.g., thecare provider information220. In such embodiments, the activity data, the demographic information, the consumer information, and/or the provider information may be provided by or obtained from one or more sources, e.g., the sources discussed above with reference to theactivity data214, the patient and/or populationdemographic information216, theconsumer profile information218, and/or thecare provider information220.
• In embodiments, the identifyingcomponent254 can identify a population of patients based on a set of criteria, which may, in one example, be received from aclinician device240. In one or more embodiments, the set of criteria may include one or more medical conditions. In the same or alternative embodiments, the set of criteria may include demographic information of one or more patients, such as age, gender, race, and/or location of residence. In one or more embodiments, the identifyingcomponent254 may utilize any or all of the information and data received by the receivingcomponent252, such as: healthcare data, e.g., the healthcare data present in one or more EMRs212; activity data, e.g., theactivity data214; demographic information, e.g., the patient and/or populationdemographic information216; consumer information, e.g., theconsumer profile information218; and provider information, e.g., thecare provider information220.
• In embodiments, the identifyingcomponent254 can identify a subset of the healthcare data associated with an individual patient related to a particular medical condition of interest. In the same or alternative embodiments, the identifyingcomponent254 can identify one or more patients in a population of patients having a medical condition of interest. In various embodiments, the identifyingcomponent254 can identify healthcare data and/or a patient in a population of patients associated with any medical condition of interest. In various embodiments, data associated with one or more patients identified by the identifyingcomponent254 may be provided to one or more output registries, such as the one or moreoutput registry databases230.
• In certain embodiments, to identify as many people as possible in a population that may have or have a particular medical condition of interest, the identifyingcomponent254 may utilize clinical data, such as lab test results, in combination with other healthcare data. In such embodiments, the particular medical condition can be any condition where specific types of clinical information, e.g., lab test results, may be used to identify one or more patients that have or may have that condition. Exemplary conditions may include, but are not limited to, diabetes and heart disease. For example, in embodiments, the identifyingcomponent254 may utilize diagnostic information, medication information, and/or one or more lab test results to identify a patient as having or potentially having diabetes. In such embodiments, by having the identifyingcomponent254 utilize information from one or more lab test results, the identifyingcomponent254 may identify one or more patients that have diabetes or may have diabetes, even if they have not been formally diagnosed with diabetes or have not been prescribed diabetes medication. In the same or alternative embodiments, the identifyingcomponent254 may utilize lab test results in combination with other healthcare data to identify pre-condition patients, which may allow early intervention to prevent a patient from developing a particular condition.
• In one or more embodiments, the identifyingcomponent254 can identify subsets of a population not based on a medical condition. For instance, in such embodiments, the identifyingcomponent254 can identify subsets of a population based on aspects of one or more patients in a population of patients, e.g., age, gender, primary spoken language, income level, healthcare motivation level, education level, technology access (e.g., phone, computer, etc.), contact preferences, work status (student, full-time, unemployed, retired, etc.), healthcare facility visit history and frequency, advanced directives, and/or consumer profile information. In embodiments, the identifyingcomponent254 can identify specific care provider information, such as address and contact information of a healthcare facility, primary spoken language of the healthcare facility, status on acceptance of new patients, etc. In one or more embodiments, the identifyingcomponent254 can identify population and or community based resources, such as fitness centers, pharmacies, food banks, public assistance, homeless shelters, etc.
• In various embodiments, the identifyingcomponent254 can identify subsets of a population based on non-medical aspects of patients, specific care provider information, and/or population and/or community based resources in order to enable actions and care planning, measure compliance, improve care transitions, optimize utilization of resources, and contain costs. In such embodiments, the identifyingcomponent254 can identify subsets of a population based on non-medical aspects of patients, specific care provider information, and/or population and/or community based resources and populate such subsets into anoutput registry230. Further, in such embodiments, the identified subsets can be utilized by other components of thepopulation health server250, such as thestratifying component256 and/or theprediction component262. Exemplary identification processes that may be performed, at least in part, by the identifyingcomponent254 are further discussed below with reference toFIGS. 3 and 9.
• In embodiments, the stratifyingcomponent256 can stratify a population of patients based on one or more algorithms. In certain embodiments, the population of patients may include at least a portion or all of the population of patients identified by the identifyingcomponent254. In one or more embodiments, the stratifyingcomponent256 may receive data (such as a listing of names or identification information) of at least a portion of the population of patients from the identifyingcomponent254 via thenetwork210. In the same or alternative embodiments, the stratifyingcomponent256 may receive data (such as a listing of names or identification information) of at least a portion of the population of patients from theoutput registry databases230 via thenetwork210.
• In one or more embodiments, the stratifyingcomponent256 can stratify a population of patients based on a clinically relevant algorithm. In such embodiments, the clinically relevant algorithm may utilize clinical data. In one or more embodiments, the clinical data may be provided from one or more EMRs, such as theEMRs212. For example, in embodiments, the clinical data may include one or more of medication information, laboratory values, diagnostics, clinical narratives, and clinician assessments. In the same or alternative embodiments, the clinical data may include data obtained from the natural language processing of one or more clinical assessments and/or clinical narratives. In certain embodiments, the stratifyingcomponent256 can stratify a population of patients based on diagnostic codes, intervention codes, insurance claims, and/or medication information associated with each patient. In one or more embodiments, the output of one or more algorithms associated with thestratifying component256 may be provided to an output registry that may be, for example, stored in one of theoutput registry databases230. In certain embodiments, an output registry can be updated when additional healthcare data, e.g., clinical data, is available for an algorithm, e.g., a clinically relevant algorithm, to utilize. In such embodiments, the stratifyingcomponent256 may re-stratify a population of patients when such additional clinical data is available for the clinically relevant algorithm to utilize.
• In various embodiments, the stratifyingcomponent256 can stratify a population of patients into one or more groups, where the one or more groups can include a plurality of patients having at least one substantially similar attribute. In such embodiments, the substantially similar attributes can include one or more of disease risk levels and/or scores, one or more disease stages, and/or one or more healthcare objectives. For example, in certain embodiments, the stratifyingcomponent256 can stratify a population of patients, such as a population of patients identified as having or potentially having diabetes, into at least two groups corresponding to Type I and Type II diabetes. In certain embodiments, as discussed below with reference to theoutput component260, a clinician may be provided an opportunity to confirm the output of one or more algorithms, such as an algorithm utilized with thestratifying component256.
• In one or more embodiments, the stratifyingcomponent256 may stratify information unrelated to specific medical conditions. For example, in certain embodiments, the stratifyingcomponent256 can stratify a subset of care providers based on venue location, specialty, spoken language, turn-over rate, readmission rate, patient satisfaction, availability, etc. Further, in certain embodiments, the stratifyingcomponent256 can stratify one or more patients based on medical and/or prescription compliance level, socioeconomic status, associated healthcare support system, and/or utilization level of healthcare facilities (including pharmacies).
• In one embodiment, an exemplary stratification process to stratify one or more patients with respect to medication compliance, which may be at least partly performed by thestratification component256, can include stratifying individual patients as having a low, medium, or high medication compliance risk based on information related to the ability to access a pharmacy, the ability to pay for medications, and/or the presence of medication gaps in the healthcare record.
• In certain embodiments, another exemplary stratification process to stratify one or more patients with respect to visit compliance, which may be at least partly performed by thestratification component256, can include stratifying patients as having a high, medium, or low visit compliance level for any or all of the various types of healthcare venues. In such embodiments, individual patients may be stratified based on the number of appointments made, the number of appointments scheduled, the number of appointments attended, the number of missed appointments, the type of appointment, the date and time of the appointment, the visit location, the venue, and whether or not the patient acknowledged the appointment (e.g., was the patient aware of the appointment).
• In one or more embodiments, another exemplary stratification process to stratify one or more patients with respect to their compliance for filling prescriptions, which may be at least partly performed by thestratification component256, can include stratifying patients as having a low, medium, or high level of compliance with filling prescriptions based, at least in part, on the number of prescriptions written, the number of prescriptions filled, and the date and time the prescriptions were filled.
• In another embodiment, an exemplary stratification process to stratify one or more patients as having one or more specific socioeconomic barriers to healthcare, which may be at least partly performed by thestratification component256, can include stratifying one or more patients based on socioeconomic indicators, such as address, employment status, marital status, education level, age, sex, dependents, race, ethnicity, insurance status, and primary spoken language.
• In one embodiment, an exemplary stratification process to stratify one or more patients as having a low, medium, or high level of support outside of a healthcare facility, which may be at least partly performed by thestratification component256, can include stratifying one or more patients based, at least in part, on a patient living situation, marital status, disposition, caregiver status, and/or likelihood of utilization of resources (family, personal, professional, community, etc.).
• In another embodiment, an exemplary stratification process to stratify one or more patients as having a low, medium, or high level of healthcare services utilization, which may be at least partly performed by thestratification component256, can include stratifying one or more patients based, at least in part, on the number of provider visits, claims data, facility visits, and medication usage. Additional exemplary stratification processes, which, in embodiments, may be at least partially performed by thestratification component256, are described below with reference toFIGS. 4 and 10.
• In embodiments, the creatingcomponent258 can create one or more output registries for one or more groups of patients of a population of patients, e.g., one or more groups identified and/or created by the identifyingcomponent254 and/or thestratifying component256. The output registries may account for resources available to a patient, lifestyle and prognostic assets that can be used for prediction, and assets necessary for attribution, allocation, or measurement. The output registries may be stored in one or moreoutput registry databases230 and may be accessible via thenetwork210. In certain embodiments, the output registries may include patient data relevant to a population of patients.
• As discussed above, the stratifyingcomponent256 may re-stratify one or more patients when additional healthcare data is available for a stratification algorithm to utilize. In such embodiments, the creatingcomponent258 may update one or more output registries based on such a re-stratification of one or more patients.
• In certain embodiments, by having particular patients in a particular registry associated with a specific medical condition, e.g., a registry having patients with Type I diabetes, a health system may be able to provide proposed plans specific to at least a portion of the patients in a particular registry. For example, in one embodiment, a Type I diabetes registry may be utilized to provide a proposed plan of care for a Type I diabetic patient, and a Type II diabetes registry may be utilized to provide a proposed plan of care for a Type II diabetic patient. In such embodiments, the proposed plans of care for the Type I and Type II diabetic patients may be different.
• In embodiments, theoutput component260 can provide clinical qualification of algorithm output, such as an algorithm utilized with thestratifying component256. For example, in embodiments, a clinician may be provided an opportunity to see the data utilized by the stratifyingcomponent256 to confirm the output of one or more algorithms. In the same or alternative embodiments, a clinician may be provided an opportunity to change the stratification level assigned to one or more patients. For example, in one embodiment, a clinician may change the heart failure classification of one or more patients after an in-person examination and/or after looking at the healthcare records associated with the one or more patients. In certain embodiments, the clinician may also have the opportunity to comment on the output and/or make additional decisions (e.g., prescriptions, interventions, and the like) based on the output.
• In embodiments, theprediction component262 can provide a prediction of problems or avoidable complications and can trigger events and alerts associated with the patient. In certain embodiments, the healthcare provider may also be provided with a prediction of problems the patient may encounter. In the same or alternative embodiments, the healthcare provider can also trigger events to happen, send alerts to people, and identify the potential of having an avoidable complication within the next twelve months. For example, theprediction component262 may indicate that a patient has a high risk of a heart related issue, and trigger events and/or alerts so that the patient is seen by a cardiologist, is checked more frequently, and is confirmed to be taking the appropriate prophylactic medication. In certain embodiments, theprediction component262 can predict: patient compliance levels for various treatments or medications; the need for transition care; readmission rates, emergency department re-entry rates, future healthcare costs; future patient attrition; comorbidity trending; and/or the amount of care provider resources needed based on patient population information.
• In embodiments, theconsolidation component264 can consolidate the healthcare data for a patient across all venues and healthcare facilities, e.g., for any or all of theEMRs212 associated with a particular patient. In such embodiments, this can allow all clinical support decisions across all venues and programs to be consolidated for the patient. In other words, theconsolidation component264 may consolidate data without regard to a specific condition or venue. In embodiments, theconsolidation component264 can piece together information from all programs that have been alerted or notified or found something out about a patient and consolidate that information for use by a healthcare provider when treating the patient.
• In embodiments, theworklist component266 can provide a filterable worklist for at least a portion of information contained in one or more registries, such as a registry in theoutput registry database230. In such embodiments, a worklist may include a patient's name, risk level, location, clinical issues and alerts, care planning, payer information, demographics, medication information, and/or appointments. In the same or alternative embodiments, the worklist can include a list of patients from a registry, such as a registry in theoutput registry database230, where the patients may be associated with a substantially similar medical condition. Further, the worklist may support, across multiple venues, multiple providers, and/or multiple conditions, providing actionable decision support tools and interventions, linking between applications and enabling documentation for one or more healthcare providers.
• In embodiments, a worklist can link or connect information and workflows from separate venues (and across a community). In such embodiments, the worklist may be a reference point for healthcare providers, including care managers, specialist providers, and primary care providers. In one or more embodiments, the worklist may be parsed by healthcare providers, venue, and/or condition.
• In embodiments, the worklist can provide a manageable list of cross-continuum, cohort specific patients that may be available to a healthcare provider or administrative body. In certain embodiments, the worklist may include criteria specific to the condition of interest, such as demographic factors, type and severity of disease, risk factors, and locality. In such embodiments, the worklist can provide contextuality of the designated cohort to the end-user, e.g., the healthcare provider, and enable efficiencies for population surveillance and resource allocation. In certain embodiments, the worklist may enable cross-continuum monitoring of a variety of activities by providing for the end-user, e.g., the healthcare provider, the ability to monitor events that have occurred or are occurring in near real-time, e.g., within 1 minute, 10 minutes, 30 minutes, 60 minutes, 120 minutes, 240 minutes, or 480 minutes of the event, outside of any one particular transactional system or EMR domain. In embodiments, the worklist may support actionable decision support tools and linking between applications to assist healthcare providers in the care of condition specified populations.
• In one or more embodiments, the worklist may be a near real-time dynamic list of patients from a cohort. As used herein, near real-time dynamic list can mean a dynamic list that contains updated information that is available for viewing within at least about 1 minute, 10 minutes, 30 minutes, 60 minutes, 120 minutes, 240 minutes, or 480 minutes of such information being inputted into an associated population health management system. In certain embodiments, a worklist can enable a healthcare provider to identify patients in a particular program and understand tasks that need to be performed by the healthcare provider or others, as well as identify the status of those tasks. For example, in a hypertension care program setting, a worklist may enable a healthcare provider managing a particular group of patients with hypertension to determine how often their blood pressure should be monitored. In embodiments, if data elements are missing on a particular patient, the healthcare provider may be provided details in a historical and/or longitudinal view. In such embodiments, the details in a historical and/or longitudinal view can enable the healthcare provider to determine: if an appointment was set; if a call to the patient is needed, if help scheduling an appointment is needed; if help getting a prescription filled is needed; if a prescription was not filled; and/or why a patient missed an appointment (e.g., no ride, no money, forgot, in hospital somewhere, etc.). A worklist may also enable one or more healthcare providers to send out group communications or announcements and filter such communications or announcements by venue. Further, in one or more embodiments, a worklist may facilitate interventions. In certain embodiments, a worklist may be dynamic and automatically repopulate as patients enter or are removed from a particular care program.
• In embodiments, the worklist may be a standalone application and/or interface, e.g., the worklist may be available to end-users, e.g., healthcare providers, agnostic of EMRs or a transactional system. In certain embodiments, the worklist may comprise rows of patient names, columns to represent a variety of topics, and/or filtering capability to allow for individual use preferences. In such embodiments, examples of columns (which may be flexible based on the condition of interest) may include risk level, location, clinical issues/alerts, care planning, payer, demographics, medication information, and/or appointments. In addition to filtering, in embodiments, the worklists may facilitate linking, documentation, notes, and the like, all from a single source across venues. Exemplary worklists, which, in embodiments, may be at least partially created by theworklist component266, are depicted inFIGS. 16,17, and18.
• In embodiments, thesituational component268 can provide a patient specific preview that includes consolidated data across multiple providers, venues, and conditions to facilitate care by one or more healthcare providers. Thesituational component268 may connect healthcare providers and/or end-users to a consistent flow of information from the populationhealth management system200, and may provide an efficient view of outputs without interrupting, and may enable cross-venue/cross-role communications. In embodiments, thesituational component268 may be patient-specific, but may consolidate and reconcile information across condition based programs.
• In certain embodiments, thesituational component268 can capture and display time sensitive, patient-specific information within the purview of multiple, cross-continuum healthcare providers and may provide patient-specific information that has been generated from the populationhealth management system200.
• In embodiments, thesituational component268 can provide a patient specific preview within a single view on a portion of a home page or viewing page. In one or more embodiments, the patient specific preview may operate across multiple programs/conditions while remaining patient-specific. In various embodiments, at least a portion of the consolidated information may be provided directly or indirectly from theconsolidation component264. In embodiments, the patient specific preview can provide alerts, notifications, registry identification, program enrollment, model predictions, and time sensitive events of interest for a patient. For example, in such embodiments, the preview may indicate that a patient was recently enrolled in a diabetes registry, provided an alert that the patient was admitted to skilled nursing without an appropriate diet order, that the patient has not received a flu shot, and that the patient has missed the last two appointments with an orthopedic surgeon. In various embodiments, one or more of the alerts, notifications, or other information may expire after a given time period so as to not crowd the situational view with untimely information. For example, in embodiments, a notification that the patient has not taken a flu shot will only be shown shortly before and during a flu season and will not be shown after the flu season. In another embodiment, information may be available for viewing over time and may not be eliminated from view once the first healthcare provider has seen the information.
• In certain embodiments, thesituational component268 may indicate an event or situation has occurred, or may occur, and this information may sequentially reveal the time of events. In the same or alternative embodiments, thesituational component268 may allow for flagging of particular events of interest for communication with additional providers. An exemplary situational view, which, in embodiments, may be at least partially created by thesituational component268, is depicted inFIG.17.
• In embodiments, the naturallanguage processing component270 can extract information, e.g., clinical indicators, from at least a portion of one or more patient's health records, such as the health records associated with one ormore EMRs212. In such embodiments, the naturallanguage processing component270 can extract information from clinical data, which may include clinical impressions and/or clinical narratives from one or more healthcare providers. In embodiments, the clinical impressions and/or clinical narratives may be associated with one or more of: a patient's condition, a course of treatment for a patient, a plan of treatment for a patient, diagnostic tests, specialty studies, pathology reports, and operative reports. The naturallanguage processing component270 can utilize any natural language processing technology known to one skilled in the art, as long as such technology is capable of extracting information from clinical impressions and/or clinical narratives.
• In certain embodiments, the naturallanguage processing component270 may extract, from healthcare data, one or more clinical indicators that may be associated with one or more chronic conditions. In such embodiments, the chronic conditions may include heart failure, acute kidney injury, chronic kidney disease, malnutrition, COPD, asthma, musculoskeletal diseases, cancer, acute infections, HIV, and/or autoimmune diseases. In various embodiments, by having extracted data, e.g., clinical indicators related to one or more chronic conditions, thepopulation health server250, e.g. via thestratifying component256, may be able to stratify one or more patients into one or more clinical stages or classes of a chronic disease.
• In certain embodiments, the naturallanguage processing component270 may qualify clinical assessments. This is because a clinical assessment from one healthcare provider may be more relevant than a clinical assessment from another healthcare provider. For example, a clinical assessment relating to heart failure can be weighted more when coming from a cardiologist compared to a heart failure assessment from an emergency room physician. In this regard, the naturallanguage processing component270 may parse subjective or judgment terms to non-discrete information such as clinical documentation or dictation (e.g., impression, course, plan, etc.) as well as interpretation of test results or diagnostics (e.g., x-ray, echocardiogram, electrocardiogram, pathology reports, stress test, pulmonary functions, operative reports, and the like). Accordingly, in embodiments, the naturallanguage processing component270 may provide a relevance rating to one or more clinical indicators extracted from the healthcare data. In such embodiments, the relevance rating may be based on the expertise of a healthcare provider that is associated with each of the extracted clinical indicators. These relevance ratings may be applied to such extracted information in order to better inform the appropriate healthcare provider when viewing such information. In certain embodiments, a clinical assessment from a physician that does not specialize in that particular field to which the assessment relates may be flagged as needing a second opinion or as needing validation by a particular specialist.
• Generally, theantibiogram component272 provides a flexible report that provides susceptibility rates based on selected populations. The cross venue or population based antibiogram allows providers to view susceptibility trends based on institution, physician practice, zip code, city, state, region, or country. Current antibiograms focus solely on inpatients or outpatients and do not take into account additional factors amongst patients that can impact the effectiveness of the more commonly prescribed antimicrobials. Prescribing an ineffective antimicrobial based on the overall population can lead to significant delays in the patient's recovery. Allowing the provider to see which antimicrobials will be most effective based on the patients circumstances and region allows for better prescribing practices. Currently, antibiograms are only available for a subset of patients and are limited in their ability to display results based on patient populations outside of the hospital.
• The cross venue antibiogram is based on a data set that includes susceptibility results from testing performed on inpatients, outpatients, and results from patients within the community, outside of the hospital setting. This data set contains basic patient demographics, but does not include patient identifiers. Antibiogram reporting is available using this data set allowing the provider to filter the results returned by various demographic parameters. As described herein, these parameters may include, but not be limited to institution, physician practice, zip code, city, state, region, or country. Collectively, the information provided by the cross venue antibiogram allows the prescriber to more accurately prescribe medications, provides a broader view of susceptibility result trends overall, improve infectious disease outcomes, is powerful for use across venues and agencies, and includes public health implications.
• In embodiments,antibiogram component272 receives medications information from disparate data sources. The data sources may include multiple venues, multiple providers, or across multiple conditions. For example, medications information may be received from one or more EMRs212, each of which may be independent from one another. As described herein, theEMRs212 may span multiple applications, multiple providers, multiple patients, multiple conditions, multiple venues, multiple facilities, multiple organizations, and/or multiple communities.
• Susceptibility results may be received based on testing associated with patient information provided by the disparate sources. The susceptibility results may also be received from the one ormore EMRs212. The susceptibility results may indicate, at a population level, culture results for bacteria, fungus, viruses, and the like, that are found in a particular population. In this regard, drug resistance, drug effectiveness, and drug utilization may be received.
• A cross venue antibiogram may be created based on the medications information and the susceptibility results. The cross venue antibiogram enables thepopulation health server250 to create an antibiogram that is not restricted to a single institution or by stale data. Rather the cross venue antibiogram may be created in real-time based on the information received by various components of thepopulation health server250. This allows both a clinician and the population to see how to manage or identify increased resistant patterns, switch pharmacies (i.e., if one particular pharmacy is supplying an ineffective medication that is otherwise not identified in the increased resistant patterns), and the like.
• The antibiogram may account for bacteria, fungus, viruses, and the like that are found in a particular community as well as the medications (e.g., antibiotics, antihypertensives, anticoagulants) that are most effective, those that are not effective, and susceptibility. The antibiogram may be stored in one ormore antibiograms databases235 and may be accessible via thenetwork210. The antibiogram includes antibiogram data relevant to a population of patients. Theantibiogram databases235 may be a networked storage or distributed storage including storage on servers located in the cloud. Thus, it is contemplated that for some embodiments, the information stored in theantibiogram databases235 is not stored in the same physical location. The information within theantibiogram databases235 may exist in a variety of standardized formats including, for example, narratives and other data. Information in theantibiogram databases235 may be categorized or classified according to, for example, claims, diagnoses, wellness, satisfaction, population directories, and the like.
• Each antibiogram may be used by, for example, a healthcare organization to manage or identify resistant patterns for a population segment. Each antibiogram may be condition specific. By way of example, a healthcare organization or clinician may manage diabetic patients within a proscribed geographic area. The condition in this case is diabetes mellitus and theantibiogram databases235 may help the healthcare organization manage a population segment with this condition differently for a particular resistant pattern than another population.
• In embodiments, filtering of the antibiogram enables reporting based on selected demographics. The selected demographics may include an institution, a practice associated with a clinician, a zip code, a county, a city, a state, a region, or a country. The selected demographics may further include a diagnosis, condition, or state associated with the patient. Selections can be made by a clinician, such as from device240 (e.g., a clinician device). Upon making these selections, a filtered antibiogram may be presented on thedevice240 in accordance with the selections. For example, a clinician may be treating a diabetes patient with a particular bacterial infection. The clinician may select demographics associated with the diagnosis, condition, location, and the like to enable the clinician to prescribe the most effective treatment based on the selections.
• Generally, themedication advisor component274 provides a prescriber focused tool that provides dosing, cost, susceptibility, and availability information for the prescriber to consider prior to placing a medication order. The comprehensive medication advisor is a prescriber order entry tool that provides more information face up to the prescriber that is important to evaluate before the medication order is entered. The advisor may be functional in all healthcare settings and may contain dosing recommendations for common disease states including but not limited to infectious diseases, coagulopathy, hypertension, and hyperlipidemia.
• Current prescriber order entry tools are a valuable way to prevent medication errors and influence drug choice. However, the current tools lack the ability to provide a complete picture of additional factors such as cost and availability and, for antimicrobials, susceptibility data. By including cost, availability, and susceptibility data, the comprehensive medication advisor disclosed herein enables clinicians to prescribe the most appropriate medication for their patient.
• The comprehensive medication advisor described herein provides information to clinicians when they are prescribing medication that may expedite the prescribing process and prevent prescribing errors. Providing cost, availability, and susceptibility information during the order entry process may expedite prescriber workflow, improve outcomes, prevent medication errors, and reduce drug expenditures.
• When a prescriber opens the advisor for a specific disease state, the advisor may contain multiple appropriate medication options. The cost, availability, and susceptibility information (when appropriate) may also be available for the prescriber to view prior to prescribing a medication. Cost may be shown in the most appropriate format, including but not limited to relative cost, actual wholesale price, institution cost, or patient cost. Availability may be displayed using numerical amount or relative amount of drug in stock. Susceptibility data may be provided for antimicrobials by incorporating the most appropriate antibiogram data, such as may be provided byantibiogram component272. As such, the susceptibility data may include information relevant to one or more of the individual patient, institution, physician practice, zip code, city, state, region, or country.
• Information provided by the comprehensive medication advisor may expedite prescriber workflow by providing the clinician with the information necessary to accurately prescribe medications, preserve stock when drug shortages occur, reduce drug expenditures, improve infectious disease outcomes, and/or enable evidence based decision support for prescribing providers.
• In embodiments,medication advisor component274 receives a specific disease state for a patient. The specific disease state may be communicated by a clinician via adevice240, such as a clinician device. The specific disease state may be received automatically via anEMR212. The disease state may be utilized to further filter the antibiogram, as described above, to help a clinician identify an antibiogram specific to the disease state associated with a particular patient.
• In embodiments, related conditions, laboratory results, and allergy information for the patient are received, via one or more data sources (e.g., the EMR212), by themedication advisor component274. Each of the related conditions, laboratory results, and allergy information may further influence how the clinician filters the antibiogram to provide a patient-centric antibiogram. In an embodiment, each of the related conditions, laboratory results, and allergy information may be provided to theantibiogram component272 automatically, via one or more data sources (e.g., the EMR212), to create the patient-centric antibiogram that is displayed on the clinician device. Further information may include genomic information and may be similarly provided to theantibiogram component272.
• In embodiments, multiple medication options are provided for the patient. The medication options may include generic alternatives, cost, availability, and susceptibility information. In embodiments, the generic alternatives for a particular medication are provided to the clinician device. In embodiments, the cost for a medication or each of the generic alternatives is provided to theclinician device240. The cost may include relative cost, actual wholesale price, institution cost, patient cost, or cost effectiveness. Cost effectiveness may factor in susceptibility information. In embodiments, availability of a medication is provided to theclinician device240. The availability may include a numerical amount or relative amount of a drug in stock.
• In embodiments, susceptibility information is provided to the clinician device. The susceptibility information is based on the antibiogram and may include information relevant to one or more of the patient, an institution, a practice associated with a clinician, a zip code, a county, a city, a state, a region, or a country. Each of these items of information provided to clinician device allows the clinician to identify, without influence (e.g., drug rep, etc.), the proper formulary of drug included within the ordering framework and provide the patient information that may help the clinician and patient select the most appropriate medication.
• Generally,medication stewardship component276 provides an ability to assess for inappropriate drug utilization as well as trends within a population of people at multiple levels. For example, an assessment can be made within a physician practice, an outpatient facility, a long term care facility, a community, a city, a state, and/or a country. In an embodiment, themedication stewardship component276 is utilized to assess antibiotic use in an inpatient setting. In this regard, direct feedback may be provided to prescribers if a particular use is deemed inappropriate. The assessment may consider, in embodiments, susceptibility information is based on the antibiogram and may include information relevant to one or more of the patient, an institution, a practice associated with a clinician, a zip code, a county, a city, a state, a region, or a country. Additionally or alternatively, the assessment may consider specific clinical data relevant to a particular patient. This feedback may be utilized to reduce medication misuse, errors, and healthcare costs, while improving outcomes.
• For example, in acute care settings, prescribing and patient monitoring oversight is frequently provided by a secondary healthcare provider such as a pharmacist or nurse. Prescribing guidance may also be provided via restricted formularies and prescribing guidelines. However, similar oversight in non-acute care settings is not possible because current healthcare systems are not able to account for patients in non-acute care settings taking multiple medications prescribed by different physicians and/or filled at separate pharmacies.Medication stewardship component276 monitors each of these variables and provides feedback at the individual patient-level, as well as for entire populations of people for evaluation of medication misuse events as well as trends. In this regard,medication stewardship component276 reduces medication misuse, medication errors, and healthcare costs.
• In embodiments, trends of inappropriate medication use may be evaluated or monitored bymedication stewardship component276. Additionally, emerging trends in treatment failure or ineffectiveness (e.g., antimicrobial resistance) may quickly be identified by utilizing information received from other components of the population health server250 (e.g.,antibiogram component272,medication advisor component274, and the like). Patient adherence or lack thereof may also be monitored bymedication stewardship component276. Drug-drug interactions may be detected bymedication stewardship component276 for patients who use multiple pharmacies.Medication stewardship component276 may assess if patients are being properly monitored and educated and may predict patient or clinician non-compliance as well as the need for additional education. Provider prescribing trends and effects of intervention may also be monitored bymedication stewardship component276.
• In embodiments,medication stewardship component276 monitors and flags inappropriate trends and may alert or notify medication stewards to intervene. In embodiments,medication stewardship component276 flags and alerts medication stewards to intervene for development of antimicrobial resistance, unnecessary prescriptions, incorrect or more costly medications, neglecting to order follow up laboratories to monitor for adverse drug reactions, patients not refilling medications as prescribed, and/or drug interactions from patients using multiple pharmacies and/or providers.
• In an embodiment,medication stewardship component276 documents interventions via an automated messaging system. In another embodiment, interventions may be documented manually, such as via adevice240, and stored by themedication stewardship component276. Outcomes of the interventions may be similarly documented or stored bymedication stewardship component276. In this regard, both trending and reporting is enabled bymedication stewardship component276. In addition to antimicrobials,medication stewardship component276 may additionally monitor and improve utilization for antihypertensives, antihyperlipidemics, analgesics, and anticoagulants.
• Themanagement component278 may provide information associated with managing a population of patients for a particular health system. In one or more embodiments, themanagement component278 may utilize data from one or more EMRs212,activity data214,demographics216, and/orcare provider information220 to consolidate, process, and analyze information, and alert a manager or healthcare provider to metrics that are not within a predetermined range. In addition, in such embodiments, themanagement component278 may provide an overview of the health system and the population of patients associated therewith.
• In certain embodiments, themanagement component278 may provide information on the health system and/or on at least a portion of a population of patients within the health system. For example, in such embodiments, this information may include one or more metrics to assess utilization of the facilities and/or services associated with the health system. Further, in embodiments, this information may include any type of financial information associated with the health system. In one or more embodiments, the information may include an overview of various care programs operated by the health system. In certain embodiments, the information may include general population health metrics for the patients associated with the health system, such as the percentage of patients having chronic conditions, rate of readmissions, etc. In one or more embodiments, the information may include alerts to notify a manager or healthcare provider of issues to be addressed, such as low compliance with follow-up appointments, with getting prescriptions filled, etc. The information provided by themanagement component278 may be presented in any fashion. Exemplary health system overviews that may be at least partly provided by themanagement component278 are depicted inFIGS. 14 and 15.
• In certain embodiments, themanagement component278 may provide a proposed plan to help allocate health system and/or healthcare resources available for a population of patients. For example, in such embodiments, themanagement component278 may find care provider resources, e.g., from thecare provider information220, that are available for a population of patients having a particular condition of interest. This may allow a healthcare provider and/or manager to better allocate resources as necessary to accommodate the population of patients of interest. In one embodiment, themanagement component278 may utilize information associated with at least one output registry, such as an output registry stored in theoutput registries database230, to provide a proposed plan to allocate health system and/or healthcare resources available for at least a portion of a population of patients.
• In certain embodiments, thehealthcare transition component280 can facilitate transition care for one or more patients. For example, in one or more embodiments, thehealthcare transition component280 may utilize data from one or more EMRs212,demographics216, and/orcare provider information220 to facilitate the arrangement of transition care. In such embodiments, thehealthcare transition component280 may provide transition care information to a healthcare provider so that the healthcare provider can review the transition care arrangements with the patient during an appointment with the healthcare provider.
• Thehealthcare transition component280 can facilitate any type of transition care required for a patient. For example, in embodiments, thehealthcare transition component280 can schedule an appointment for a patient and/or arrange transportation services for the patient. In one embodiment, thehealthcare transition component280 can arrange for the delivery of prescriptions and/or arrange for prescription assistance. In various other embodiments, thehealthcare transition component280 may arrange follow-up services that may be needed for a patient, such as support groups, dietary requirements, etc., and provide information for a healthcare provider to educate the patient about such services. In certain embodiments, thehealthcare transition component280 may determine and notify a healthcare provider if a referral need exists for a certain patient. Further, in one or more embodiments, thehealthcare transition component280 can facilitate the assignment of a particular healthcare provider to a particular patient. Exemplary transition care processes, which, in embodiments, may be at least partially performed by thehealthcare transition component280, are described below with reference toFIGS. 5-8 and11-13.
• In embodiments, thecondition module282 may be specific to one medical condition and one patient and provide associated information across multiple venues. In such embodiments, thecondition module282 can provide a patient- and condition-specific overview to allow healthcare providers to monitor specific issues and see the story of the patient's condition. In embodiments, the story conveyed by thecondition component282 can include a longitudinal timeline of events related to that condition, such as the time of diagnosis, treatments, labs and diagnostics related to condition, and quality measures. In certain embodiments, thecondition component282 may account for venue and may display time relative information for more acutely collected data (i.e. for the hospitalized patient or acutely monitored patient).
• In one or more embodiments, thecondition component282 may provide visibility to care teams involved, consultations, references, and/or quality measures as they relate to the condition of interest. In certain embodiments, thecondition component282 may provide a healthcare provider access to disparate EMR's for more detailed information associated with the condition of interest while providing access to clinical decision support tools (such as care process maps, treatment nomograms, etc.) for the condition of interest. In embodiments, thecondition component282 can provide similar information across venues and healthcare providers so that all healthcare providers will be accessing similar condition information. In certain embodiments, thecondition component282 may include specialist specific views or information, which can account for more complex care issues. The ability to correlate and connect condition specific information from various systems for cross-continuum display may lessen the burden of potential errors, educate the community of providers responsible for this patient, and improve accuracy and efficiency for population management.
• In certain embodiments, thecondition component282 can include a condition timeline or longitudinal record. In such embodiments, this longitudinal record can provide a timeline of events related to the particular condition of interest. The timeline of events may include laboratory results, medications, diagnostics, and/or interventions derived from the healthcare data from multiple venues, multiple providers, and across multiple conditions. In embodiments, the timeline can enable clinicians to quickly identify additional information about a patient with a particular condition of interest, even while reviewing data originating from multiple data sources, multiple venues, or multiple providers and even from multiple conditions.
• In embodiments, the timeline may provide the clinician a longitudinal story for a patient with a particular diagnosis or condition. For example, a clinician may have a diabetic patient. The timeline of events may provide the clinician events related to diabetes over the last six months that have occurred. The clinician may initially see normal blood sugar and then identify, two weeks later, that the blood sugar was elevated. At this point, the clinician may identify that all other laboratory results were also high or off or find where the patient received an intervention with a specialist. Exemplary condition component information, which, in embodiments, may be at least partially provided by thecondition component282, are described below with reference toFIGS. 18,21, and22.
• In embodiments, thepatient portal component284 can provide healthcare-related information for a particular patient. In certain embodiments, thepatient portal component284 can allow the patient to view their healthcare data and the outputs of any program algorithms, such as an identification algorithm and/or a stratification algorithm. In one or more embodiments, thepatient portal component284 can provide access to educational information and workshops relevant to the patient's health status or conditions. In certain embodiments, thepatient portal component284 can allow the patient to input information into their healthcare record, such as exercise, diet, personal device data, payment information, etc. An exemplary patient portal, which, in embodiments, may be at least partially provided by thepatient portal component284, is described below with reference toFIG. 27.
• In certain embodiments, thebaseline component286 can consolidate basic information about a population, provider, or patient, and direct the identification and stratification of appropriate parameters to facilitate basic care operations. In one or more embodiments, thebaseline component286 can consolidate information associated with identified and/or stratified subsets of a patient population and can provide care planning, improve care transitions, optimize resource utilization; and/or contain costs. For example, in one embodiment, knowing that a patient is likely highly motivated for healthcare purposes and has a high compliance rate, thebaseline component286 can notify a healthcare provider and/or health system that they can rely on the patient to comply with their care and need not spend resources unnecessarily. In certain embodiments, thebaseline component286 can provide a holistic view of a population, provider and/or a patient and can address and/or predict underlying gaps in care, notify appropriate providers, patients, and family, and proactively manage these situations prior to penalties or crises.
• The populationhealth management system200 is an open-loop system meaning that as a healthcare organization utilizes the output of thepopulation health server250, more organizational and patient data is generated which is fed back into thesystem200 and used to update thevarious output registries230,EMRs212, and/orantibiograms235. Further, thesystem200 operates over and is compatible with existing electronic medical record systems associated with healthcare organizations, even if these electronic medical record systems are disparate in nature. Thus, a healthcare organization can utilize the system to manage population health without having to incur significant financial costs to reconfigure its already-existing electronic medical record system.
• Turning now toFIG. 3, anexemplary identification algorithm300 is depicted for identifying patients that have or may have diabetes. It should be understood that the specific steps and the order of the steps depicted in thealgorithm300 are only exemplary and that other steps and different orders of the steps may be user. In addition, it should be understood that other possible variations for thealgorithm300 are within the scope of the present invention.
• In the embodiment depicted inFIG. 3, theidentification algorithm300 may include astart step302, where data associated with one or more patients is received, and then at thestep304 the data is queried to determine if the patient is greater than or equal to 18 years old. If the patient is not greater than or equal to 18 years old, atstep306, the patient is excluded from the being populated in a diabetes registry. After a patient is determined to be greater than 18 years old the patient information is queried to determined, atsteps308 if there is a diabetes code, and atstep310, if there is an insurance claims present in the patient information. Atstep314, if the one out the two criteria insteps308 and310 are present then atstep312, the patient is populated into a diabetes mellitus registry. In none of the two criteria insteps308 and310 are met, atstep316, it is determined if the patient currently has gestational diabetes. If so, then atstep318, that patient is excluded from being populated in the diabetes registry. If the patient does not currently have gestational diabetes, then atstep320, it is determined if the patient is currently on corticosteroids. If so, then, atstep318, the patient is excluded.
• If the patient does not currently on corticosteroids then, atstep322, it is determined if the patient is on diabetic medications. If so, then it is determined, atstep324, if the patient is only on metformin, and if not, then the patient is populated in the diabetes mellitus registry. If the patient is not only on metformin, then atstep326, it is determined if the patient have ever been diagnosed with polycystic ovarian syndrome (PCOS). If so, then atstep328, the patient is excluded from being populated in the diabetes registry.
• For a patient that is not on diabetic medications and has not been ever diagnosed with having PCOS, then, atstep330, it is determined if the patient has any clinical laboratory data to suggest that the patient has diabetes. For instance, atstep332 the patient information is queried to determine if there is laboratory data evidencing a A1C value greater than or equal to 6.5%. Further, atstep334, the patient information is queried to determine if there is laboratory data evidencing if the fasting plasma glucose concentration is greater than or equal to 126 mg/dL (7.0 mmol/L). In addition, atstep336, the patient information is queried to determine if there is laboratory data evidencing a 2-hour plasma glucose concentration of greater than or equal to 200 mg/dL (11.1 mmol/L) during an oral glucose tolerance test (OGTT). Atstep338, it is determined if the patient has an abnormal result for any of the tests queried for insteps332,334, and336. If so, then the patient populates to the diabetes registry atstep312. If not, atstep340, the patient is excluded from population in the diabetes registry.
• FIG. 4 depicts anexemplary stratification algorithm400 is depicted for stratifying one or more patients present in a diabetes registry. It should be understood that the specific steps and the order of the steps depicted in thealgorithm400 are only exemplary and that other steps and different orders of the steps may be user. In addition, it should be understood that there other possible variations for thealgorithm400 within the scope of the present invention.
• Atstep402, patient information associated with patients present in the diabetes registry is received. In certain embodiments, at thestep304, the information related to one or more patients in the diabetes registry is queried to determine if the patient information includes a code related to Type II diabetes within the last five years. If so, then atstep406, the patient is stratified to be associated with Type II diabetes. If the patient information does not include a code related to Type II diabetes within the last five years, atstep408, it is determined if the patient information includes a code related to Type I diabetes within the last five years. If so, then, atstep410, the patient is stratified to be associated with Type I diabetes. If the patient does not include a code related to Type I diabetes within the last five years, atstep412, it is determined if the patient information includes clinical data suggesting the presence of antibodies to islet cells. If so, then, atstep410, the patient is stratified to be associated with Type I diabetes. If the patient information does not include clinical data suggesting the presence of antibodies to islet cells, then atstep414, it is determined if the patient information includes clinical data that suggesting a C-peptide concentration of less than 0.4 ng/mL. If so, then, atstep410, the patient is stratified to be associated with Type I diabetes. If the patient information does not include clinical data that suggesting a C-peptide concentration of less than 0.4 ng/mL, then atstep416, it is determined if the patient has been prescribed diabetic medications other than insulin. If so, then atstep406, the patient is stratified to be associated with Type II diabetes. If the patient has not been prescribed diabetic medications other than insulin, then atstep418, it is determined if the patient has been prescribed insulin and no other diabetic medications. If so, then atstep410, the patient is stratified to be associated with Type I diabetes. If not, then the patient is placed in the “other category” which is does not include patients stratified to be associated with Type I or Type II diabetes.
• As discussed above, in certain embodiments, a population health management system, e.g., the populationhealth management system200 ofFIG. 2, can aid in providing transition healthcare for one or more patients. For example, in certain embodiments, a population health server may provide transition management care associated with transportation of a patient to or from a healthcare venue for an appointment.FIG. 5 depicts one embodiment of analgorithm500 that may be used to determine a need for transportation for an appointment and if, based on the transportation situation of patient if an appointment should be scheduled. It should be understood that the specific steps and the order of the steps depicted in thealgorithm500 are only exemplary and that other steps and different orders of the steps may be user. In addition, it should be understood that there other possible variations for thealgorithm500 within the scope of the present invention.
• Atstep502, a population health management system receives and/or generates a generated provider list that may include one or more patients in need of scheduling an appointment to see a healthcare provider and may or may not have transportation needs. Atstep504, it is determined if the patient has transportation needs, and if not, then atstep506 an appointment is scheduled for the patient. If the patient does transportation needs, then atstep508, it is determined if the patient's insurance will cover transportation services for healthcare provider appointments. If so, then atstep506, an appointment is scheduled. If the patient's insurance will not cover transportation services then, atstep510, it is determined if there are community organizations or free services that can provide transportation. If so, then atstep506, an appointment is scheduled. If there are no community organizations or free services that can provide transportation, then atstep512, it is determined if there are other resources available that have not been identified. If so, then atstep506, an appointment is scheduled. If there are no other resources available, then atstep514 it is determined if there are home health or other service options for this patient. If so, then the home health or other services are arranged atstep518. If there is no home health or other service options available for the patient, then atstep516, the patients an appointment is put on hold until transportation services become available.
• FIG. 6 depicts another embodiment of analgorithm600 that may be utilized to provide transition care by facilitating the provision of medications to a patient. It should be understood that the specific steps and the order of the steps depicted in thealgorithm600 are only exemplary and that other steps and different orders of the steps may be user. In addition, it should be understood that there other possible variations for thealgorithm600 within the scope of the present invention.
• Atstep602, a population health management system, e.g., the populationhealth management system200 ofFIG. 2, can determine that medication follow-up is needed for a patient. Atstep604, it is determined if the patient can access prescriptions, and if so, then atstep606, a prescription is sent to a pharmacy and communication with the patient is initiated in order to arrange the pick-up of the medication. Atstep608, it is determined if the patient can access the pharmacy for medication pick up, and if so, then atstep614, the patient receives the medication. If the patient cannot access the pharmacy, then atstep610, it is determined if the pharmacy can deliver the medication. If so, then atstep614, the patient receives the medication via delivery by the pharmacy. If the pharmacy does not deliver and the patient cannot access the pharmacy, then atstep612 an online pharmacy or a suitable alternative pharmacy is located, where atstep614, the patient will receive the medication.
• If it is determined instep604 that the patient cannot access the prescriptions, then atstep616, it is determined if there is a prescription assistance program (PAP) to help, and if so, atstep618 an application is submitted for the PAP. If a PAP is available to help and an application has been submitted atstep618, and/or if a PAP is not available to help, atstep620 it is determined if there are medication samples available. If there are samples available, then atstep622, samples are provided or arranged to be provided and PAP information is provided or arranged to be provided. If there are no samples to be provided, then atstep624 it is determined if there is a central billing office (CBO) that can provide medication assistance, and if so, atstep626, a referral is sent to the CBO. If there is not a CBO to provide assistance, then atstep628, the care management may absorb the cost of medications in the short term.
• FIG. 7 depicts another embodiment of analgorithm700 that may be utilized to provide transition care by facilitating the provision of additional services for a patient. It should be understood that the specific steps and the order of the steps depicted in thealgorithm700 are only exemplary and that other steps and different orders of the steps may be user. In addition, it should be understood that there other possible variations for thealgorithm700 within the scope of the present invention.
• Atstep702, it is determined that other services, such as follow up support, education, etc., may be necessary for the patient. Atstep704, it is determined if additional referrals are required for the additional services, and if not, atstep706 the process stops. If additional referrals are required, it is determined if support groups, nutritional consultations, physical activity access, and education services are needed at steps,708,710,712, and714, respectively. If any of the services ofsteps708,710,712, and714 are needed, atstep716, it is determined if insurance will cover these services. If not, then atstep718, it is determined if there are free services available. If there are no free services available, then atstep720, as a last resort, the healthcare provider is directed to educate the patient at that time, if possible. If insurance will cover the services or there are free services available, then atstep722, a referral is sent. Atstep724, the healthcare provider is directed to educate the patient regarding the arranged services and verify that the patient has access to and an understanding of the services. Atstep726, a transportation workflow is initiated to facilitate transportation to the services, if necessary, and atstep728 the process ends.
• FIG. 8 depicts another embodiment of analgorithm800 that may be utilized to provide transition management care, if necessary, by determining if a patient requires a referral. It should be understood that the specific steps and the order of the steps depicted in thealgorithm800 are only exemplary and that other steps and different orders of the steps may be user. In addition, it should be understood that there other possible variations for thealgorithm800 within the scope of the present invention.
• Atstep802, a population health management system, e.g., the populationhealth management system200 ofFIG. 2, may generate or provide patients in a diabetes registry, e.g., an output registry in theregistry database230 ofFIG. 2. Atstep804, it is determined if the algorithm was initiated manually. If the algorithm was not initiated manually, then atstep806, it is determined if the patient has a primary care provider (PCP). If the patient has a PCP, then atstep808, it is determined if the patient has Type I diabetes, Latent autoimmune diabetes of adults (LADA), or Maturity onset diabetes of the young (MODY). If not, then atstep810, the patient is stratified as having Type II diabetes. Then atstep812, it is determined if there are factors that necessitate referral to an endocrinologist. Then atstep814, it is determined if there is a patient request for an endocrinologist, if the patient. Atstep816, it is determined if the patient has been hospitalized for hyperglycemia. Atstep818, it is determined if the patient is on two or more diabetic medications and has an elevated HbA1C value greater than 7%. Atstep820, it is determined the patient has had two consecutive HbA1C values greater than 7%. Atstep822, it is determined if one or more of the criteria determined insteps814,816,818, and820 are met, and if not, then atstep824, the process ends and a referral is not provided. If one or more of the criteria determined insteps814,816,818, and820 are met, or if the patient has Type I diabetes, LADA, or MODY, then atstep826 it is determined if the patient has an endocrinologist. If the patient does have an endocrinologist, then atstep828, it is determined if the patient has seen that specialist in the past year, and if so, then atstep824, the process ends and a referral is not provided. If the patient has not seen that specialist in the past year, or if the patient does not have an endocrinologist, then atstep830, it is determined if a referral agent has been run for the combination of the user/healthcare provider and the patient within the last 30 days. If so, then atstep824, the process ends and a referral is not provided. If a referral agent has not been run for the combination of the user/healthcare provider and the patient within the last 30 days, then atstep832 it is determined if the patient in the diabetes registry is an uncontrolled diabetic. If so, then atstep850, it is determined if the patient has an endocrinologist, and if so atstep852, the endocrinologist is placed fixed at the top of the list and is designated as the “current endocrinologist.” Afterstep852, or if it is determined instep850 that the patient does not have an endocrinologist, atstep854, the system is queried for endocrinologist providers. Then atstep856, a primary sort of an endocrinologist provider list by payor compatibility is performed. Then at step858 a secondary sort of the endocrinologist provider list by language compatibility is performed. Then atstep860, a tertiary sort of the endocrinologist provider list by location compatibility is performed. Then atstep862, for the patients with uncontrolled diabetes, a list of endocrinologist providers is generated for the best match.
• In addition, atstep834, for all the patients in the diabetes registry, it is determined if the patient has a PCP and if so, the PCP is placed fixed at the top of the list and designated as the “current PCP.” Regardless of whether the patient has a PCP or not, atstep838, the system is queried for PCP providers. Atstep840, a primary sort of a PCP provider list by payor compatibility is performed. Then at step842 a secondary sort of the PCP provider list by language compatibility is performed. Then atstep846, a tertiary sort of the PCP provider list by location compatibility is performed. Then atstep848, for all the patients in the diabetes registry, a list of PCP providers is generated for the best match.
• Aftersteps848 and862, atstep864, a notification is formatted to the user and includes the top 10 providers. Atstep866, designations for PCPs and endocrinologists are provided. Then at step868, appropriate rationale on a provider basis is provided. Atstep870, an option to view the next ten providers is provider, and atstep872, the process ends.
• FIG. 9 depicts anexemplary identification algorithm900 that may be utilized by a population health management system, e.g. the populationhealth management system200 ofFIG. 2, to identify patients that may have heart failure. It should be understood that the specific steps and the order of the steps depicted in thealgorithm900 are only exemplary and that other steps and different orders of the steps may be user. In addition, it should be understood that there other possible variations for thealgorithm900 within the scope of the present invention.
• Theidentification algorithm900 may include astart step902, where data associated with one or more patients is received, and then at thestep904 the data is queried to determine if the patient is less than 18 years old. If not, then the patient is excluded from being identified with heart failure. If the patient is not less than 18 years old, then atstep908 it is determined if a diagnosis code for heart failure is present in the healthcare data. If so, then atstep912, the patient is included and identified as having or potentially having heart failure. If there is no diagnosis code for heart failure is present in the healthcare data, then atstep910, it is determined if there is claims data present that suggests the patient has or may have heart failure. If so, then atstep912, the patient is included and identified as having or potentially having heart failure. If the is no claims data present that suggests the patient has or may have heart failure, then atstep914, it is determined if there is data that shows that an echocardiogram was performed. If so, then atstep916, it is determined if there is data for an ejection fraction (EF) quantitative results or other codes associated with EF quantitative results. If there is such data or codes present, atstep918, it is determined if the EF is less than 40%. If the EF is less than 40%, then atstep920, the patient is identified as having or potentially having heart failure and is included in the heart failure registry. If the EF is not less than 40%, then atstep922, it is determined if there is data evidencing moderate or severe systolic dysfunction. If so, then atstep920, the patient is identified as having or potentially having heart failure and is included in the heart failure registry.
• If there is no data evidencing moderate or severe systolic dysfunction, or if there is no EF quantitative results or other codes associated with EF quantitative results, or if no echocardiogram was performed, then the patient's data is queried for the presence of several medications. The patient's data is queried for the presence of: ACE inhibitors and angiotensin II receptor blockers atstep926; beta blockers atstep928; nitrates and hydralazine atstep930; calcium channel blockers atstep932; digoxin atstep934; loop diuretics atstep936; aldosterone antagonists atstep938; and anticoagulants atstep940. Then atstep942, it is determined if at least three of the heart failure medications queried insteps926,928,930,932,934,936,938, and940 are present, and if so, then atstep944 the patient is identified as having or potentially having heart failure and is included in the heart failure registry. If less than three of the heart failure medications are present, then atstep946, the patient is not identified as having heart failure and is not included in the registry.
• FIG. 10 depicts anexemplary stratification algorithm1000 is depicted for stratifying one or more patients present in a heart failure registry. It should be understood that the specific steps and the order of the steps depicted in thealgorithm1000 are only exemplary and that other steps and different orders of the steps may be user. In addition, it should be understood that there other possible variations for thealgorithm1000 within the scope of the present invention.
• Atstep1002, data associated with the patients in the heart failure registry are received. Atstep1004, data from the patients in the heart failure registry is filtered only to provide data within the past year, so that forsteps1006 through1026, a New York Heart Association (NYHA) code can be determined or attempted to be determined for the patient. Atstep1006, it is determined if discrete NYHA codes are available in the patient's healthcare data. If so, then instep1008, the NYHA code is assigned to the patient. If not, atstep1010, it is determined if physician notes are available for natural language processing for determining an NYHA code. If so, then atstep1012, it is determined if the patient is symptomatic at rest, and if so, instep1020, the patient is assigned the NYHA IV code. If the patient is not symptomatic at rest, then instep1014, it is determined if the patient is symptomatic with minimal exertion, and if so, instep1022, the patient is assigned the NYHA III code. If the patient is not symptomatic with minimal exertion, then instep1016, it is determined if the patient is symptomatic with moderate exertion, and if so, instep1024, the patient is assigned the NYHA II code. If the patient is not symptomatic with moderate exertion, then instep1018, it is determined if the patient is asymptomatic, and if so, instep1026, the patient is assigned the NYHA I code.
• After assigning the NYHA code to the patient or not being able to assign an NYHA code to the patient, instep1028, it is determined if American Medical Association (AMA) codes are available in the patient's healthcare data. If so, then instep1030, the AMA code is assigned to the patient. If no AMA codes are available in the patient's healthcare data, then atstep1032, it is determined if there are physician notes available for natural language processing for determining an AMA code. If so, then instep1034, it is determined if there is no evidence of structural heart damage. If so, then instep1042, the patient is assigned the AMA code A. If there is not any evidence of structural heart damage, then instep1036, it is determined if the patient's symptoms are minimal or nonexistent. If the symptoms are minimal and nonexistent, then instep1044, the patient is assigned the AMA code B. If the symptoms are not minimal and nonexistent, then instep1038, it is determined if the symptoms are managed with therapy. If the symptoms are managed with therapy, then instep1046, the patient is assigned the AMA code C. If the symptoms are not managed with therapy, then instep1040, it is determined if the patient has symptomatic heart disease that does not respond to therapy, and if so, instep1048, the patient is assigned the AMA code D.
• After assigning the AMA code to the patient or not being able to assign an AMA code to the patient, instep1050, the data from the patients in the heart failure registry is filtered only to provide data within the past year, so that forsteps1052 through1076, Ejection Fraction (EF) classifications can be determined. Instep1052, it is determined if an echocardiogram has been performed. If not, then atstep1054, it is determined if an NV test has been performed. If not, then the process ends and no EF classification is determined. If an NV test or an echocardiogram has been performed, then atstep1058, it is determined if there are EF quantitative results. If so, atstep1062, it is determined if the EF quantitative results reveal an EF greater than 55%. If so, then the patient is classified as having a preserved EF atstep1076. If the EF quantitative results do not reveal an EF greater than 55%, then atstep1066, it is determined if the EF quantitative results reveal an EF greater than 40%. If so, instep1074, the patient is classified as having a moderate EF. If the EF quantitative results do not reveal an EF greater than 40%, then atstep1072, the patient is classified as having a reduced EF.
• If there are no quantitative EF results, atstep1060, it is determined if there are EF qualitative results. If so, instep1064, it is determined if there is no systolic dysfunction. If there is not systolic dysfunction, then instep1076, the patient is classified as having a preserved EF. If it is determined that there is not no systolic dysfunction, then instep1068, it is determined if the patient has mild systolic dysfunction. If so, then the patient is classified as having a moderate EF instep1074. If it is determined that the patient does not have mild systolic dysfunction, then instep1070, it is determined if the patient has moderate or severe systolic dysfunction. If so, the patient is classified as having a reduced EF.
• As discussed above, in certain embodiments, a population health management system, e.g., the populationhealth management system200 ofFIG. 2, can aid in providing transition management care for one or more patients, such as determining if a referral is needed for a patient.FIG. 11 depicts one embodiment of analgorithm1100 that may be used to determine whether a patient needs a referral or not. It should be understood that the specific steps and the order of the steps depicted in thealgorithm1100 are only exemplary and that other steps and different orders of the steps may be user. In addition, it should be understood that there other possible variations for thealgorithm1100 within the scope of the present invention.
• Atstep1102 data from the patients in the heart failure registry and/or the pre-heart failure registry is received. Instep1104, it is determined if the patient has a PCP. If so, then instep1106, it is determined if the patient was stratified as having class BII-BIV, C, or D heart failure. If not, then instep1108, it is determined if the patient was stratified as having class A or BI heart failure. If so, then instep1110, it is determined if the patient had an acute hospital admission during the prior two years for specific diseases or treatments as determined in steps1112-1124. The specific diseases are pulmonary edema, new onset atrial fibrillation, heart failure, coronary artery bypass grafting (CABG), acute myocardial infarction (AMI), valvular disease, cardiomyopathy forsteps1112,1114,1116,1118,1120,1122, and1124, respectively. Atstep1126, it is determined if one or more of the diseases or treatments of determined in1112,1114,1116,1118,1120,1122, and1124 occurred for the patient, If not, then the process ends and no referral is made. If the patient has had one or more of the diseases or treatments of determined in1112,1114,1116,1118,1120,1122, and1124, or if the patient is stratified as having class BII-BIV, C, or D heart failure, instep1132, it is determined if the patient has a cardiologist. If so, instep1130, it is determined if the patient has had a cardiologist outpatient encounter within the last year. If so, instep1128, the process ends and no referral is made. If the patient has not had a cardiologist outpatient encounter within the last year, atstep1134, it is determined if a referral agent was run for the healthcare provider and patient combination in the past 30 days. If so, instep1128, the process ends and no referral is made. If not, then instep1136, a suggestion is provided to the healthcare provider for the referral agent.
• FIG. 12 depicts analgorithm1200 for assigning a physician to one or more patient in a heart failure registry. It should be understood that the specific steps and the order of the steps depicted in thealgorithm1200 are only exemplary and that other steps and different orders of the steps may be user. In addition, it should be understood that there other possible variations for thealgorithm1200 within the scope of the present invention.
• Atstep1202, data from one or more patients in a heart failure registry is received. Atstep1218, for one or more patients classified as having class B, C, D heart failure or reduced EF, it is determined if such a patient has a cardiologist. If so, then atstep1220, the cardiologist is placed fixed at the top of the list and is designated as the “current cardiologist.” Afterstep1220, or if it is determined instep1218 that the patient does not have a cardiologist, atstep1222, the system is queried for cardiologist providers. Then atstep1224, a primary sort of a cardiologist provider list by payor compatibility is performed. Then at step1226 a secondary sort of the cardiologist provider list by language compatibility is performed. Then atstep1228, a tertiary sort of the cardiologist provider list by location compatibility is performed. Then atstep1230, for the patients having class B, C, D heart failure or reduced EF, a list of cardiologist providers is generated for the best match.
• In addition, atstep1204, for all the patients in the heart failure registry, it is determined if the patient has a PCP and if so, the PCP is placed fixed at the top of the list and designated as the “current PCP” instep1206. Regardless of whether the patient has a PCP or not, atstep1208, the system is queried for PCP providers. Atstep1210, a primary sort of a PCP provider list by payor compatibility is performed. Then at step1212 a secondary sort of the PCP provider list by language compatibility is performed. Then atstep1214, a tertiary sort of the PCP provider list by location compatibility is performed. Then atstep1216, for all the patients in the heart failure registry, a list of PCP providers is generated for the best match.
• Aftersteps1216 and1230, atstep1232, a notification is formatted to the user and includes the top 10 providers. Atstep1234, designations for PCPs and cardiologists are provided. Then at step1236, appropriate rationale on a provider basis is provided. Atstep1238, an option to view the next ten providers is provider, and atstep1240, the process ends.
• FIG. 13 depicts analgorithm1300 that may be utilized to provide transition management care by facilitating the provision of additional services for a patient. It should be understood that the specific steps and the order of the steps depicted in thealgorithm1300 are only exemplary and that other steps and different orders of the steps may be user. In addition, it should be understood that there other possible variations for thealgorithm1300 within the scope of the present invention.
• Atstep1302, it is determined that other services, such as follow up support, education, etc., may be necessary for the patient. Atstep1304, it is determined if additional referrals are required for the additional services, and if not, atstep1306 the process stops. If additional referrals are required, it is determined if support groups, nutritional consultations, outpatient cardiac rehabilitation, physical activity access, and education services are needed at steps,1308,1310,1312,1314, and1316, respectively. If any of the services ofsteps1308,1310,1312,1314, and1316 are needed, atstep1318, it is determined if insurance will cover these services. If not, then atstep1322, it is determined if there are free services available. If there are no free services available, then atstep1324, as a last resort, the healthcare provider is directed to educate the patient at that time, if possible. If insurance will cover the services or there are free services available, then atstep1320, a referral is sent. Atstep1326, the healthcare provider is directed to educate the patient regarding the arranged services and verify that the patient has access to and an understanding of the services. Atstep1328, a transportation workflow is initiated to facilitate transportation to the services, if necessary, and atstep1330 the process ends.
• FIGS. 14-27 depict various aspects of a population health management system, e.g., the populationhealth management system200. The aspects of the population health management system depicted inFIGS. 14-27 are merely exemplary and it should be understood that additional aspects or variations on the aspects depicted inFIGS. 14-27 are within the scope of the present invention.
• FIG. 14 depicts anoverview1400 of a health system that can be provided to ahealthcare provider1410. Thehealthcare provider1410 can be any healthcare provider associated with the health system, such as a physician, physician's assistant, nurse, care manager, and/or administrator. Theoverview1400 can be displayed on one or more devices, such as thedevices240 discussed above with reference toFIG. 2. In one or more embodiments, theoverview1400 may be generated, at least in part, by one or more components of a population health server, such as thepopulation health server250 discussed above with reference toFIG. 2.
• In certain embodiments, theoverview1400 can include a keyperformance indicator module1420. In such embodiments, the keyperformance indicator module1420 can include various indicators that represent different features of a health system, such ashealth system utilization1422,financial information1424, healthcare quality of1426,operational indicators1428, healthsystem access indicators1430, and/or appropriateness of thehealthcare1432.
• In one or more embodiments, the overview can includealerts1440 associated with the health system. In certain embodiments, thealerts1440 can include alerts for trends associated with a population of patients cared for by the health system. For example, as depicted inFIG. 14, thealerts1440 can include information related to rate of readmissions, compliance issues, and/or rate or number of prescriptions being filled for a specific group of patients. In the embodiment depicted inFIG. 14, thehealthcare provider1410 has the option of addressing, dismissing, or snoozing one ormore alerts1440 from thisoverview1400.
• In certain embodiments, theoverview1400 can includepatient population information1450. In such embodiments, thepatient population information1450 may include general characterizations of the patient population in the health system. For example, in one embodiment, thepatient population information1450 can include the percentage of the patient population present in various classifications, such as being classified as having chronic conditions.
• In various embodiments, theoverview1400 can include demographic information1460 on the patient population present within the health system. In the same or alternative embodiments, the overview can includesatisfaction metrics1470 associated with the satisfaction of patients and/or employees of the health system.
• In certain embodiments, the information associated with theoverview1400 can include information organized in various tabs, such as thetabs1480. In such embodiments, thehealth care provider1410 can view information associated with the payers or provider groups. In the same or alternative embodiments, thehealth care provider1410 can view information associated with medical conditions or various health system programs.
• In various embodiments, theoverview1400 can also include additional tabbedportions1490 where thehealthcare provider1410 can view information associated with one or more registries, scorecards, medications, or outreach.
• FIG. 15 depicts aprogram view1500 for a specific program associated with a health system. Theprogram view1500 may be displayed on one or more devices, such as thedevices240 discussed above with reference toFIG. 2. In one or more embodiments, theoverview1500 may be generated, at least in part, by one or more components of a population health server, such as thepopulation health server250 discussed above with reference toFIG. 2.
• In certain embodiments, theprogram view1500 may be associated with a particular program offered by the health system. For example, in the embodiment depicted inFIG. 15, theprogram view1500 includes a view of a diabetes program. In certain embodiments, a healthcare provider, e.g., thehealthcare provider1510, can navigate to theprogram view1500 via a health system overview, such as thehealth system overview1400 ofFIG. 14. In such embodiments, a healthcare provider can navigate to theprogram view1500 by clicking on alink1442 to address an alert in theoverview1400 ofFIG. 14.
• Returning now toFIG. 15, in certain embodiments, theprogram view1500 can include all available information related to a population of patients being treated for diabetes within the health system. For example, in such embodiments, theprogram view1500 can include a column listing indicators or measures associated with the population of patients being treated for diabetes, such as one or more of:key performance indicators1520;quality measures1530;prescription information1540; consultations/appointments attendance information1550; and personal patient documentation1560 (such as logging of diet and/or home glucose tests). In one or more embodiments, theprogram view1500 can provide a mainprogram view area1542 of one or more of the indicators ormeasures1520,1530,1540,1550, and1560.
• In the embodiment depicted inFIG. 15, the mainprogram view area1542 provides information associated with the prescriptions filedmeasure1540 from the column listing. In embodiments, themain program view1542 may be formatted differently depending upon which indicators ormeasures1520,1530,1540,1550, and/or1560 thehealthcare provider1510 is highlighting for display. As seen in the embodiment depicted inFIG. 15, a mainprogram view area1542 may display amap1544 highlighting pharmacies and clinics. In such embodiments, the mainprogram view area1542 can illustrate the percentage of prescriptions filled at each of the pharmacies and clinics on themap1544. In one or more embodiments, the mainprogram view area1542 can include alist1580 of various types of entities to display on themap1544.
• FIG. 16 depicts ahealthcare provider overview1600 for a healthcare provider, such as thehealthcare provider1610. In embodiments, thehealthcare provider1610 can be any healthcare provider associated with the health system, such as, a physician, physician's assistant, nurse, care manager, and/or administrator. Thehealthcare provider overview1600 may be displayed on one or more devices, such as thedevices240 discussed above with reference toFIG. 2. In one or more embodiments, thehealthcare provider overview1600 may be generated, at least in part, by one or more components of a population health server, such as thepopulation health server250 discussed above with reference toFIG. 2.
• Thehealthcare provider overview1600 can include any or all information associated with thehealthcare provider1610 for a particular health system. In such embodiments, thehealthcare provider overview1600 can include more than one potential display area. For example, in the embodiment depicted inFIG. 16, thehealthcare provider overview1600 can include thetabs1660 to enable thehealthcare provider1610 to view information associated with various categories, such as worklist, outreach, performance, and connections. In one or more embodiments, thehealthcare provider overview1600 can include ahome view option1662 to view information from several categories at once. For example, in certain embodiments, thehome view option1662 of thehealthcare provider overview1600 can include acommunications area1620, aschedule area1630, aperformance area1640, and/or aworklist area1650. In the embodiment depicted inFIG. 16, thecommunications area1620 can include: aninbox area1622 that can display at least a representation of incoming messages, e.g., emails; anotification area1624 that can display at least a portion of notifications relating to the healthcare provider's duties, and/or anannouncement area1626 to display announcements relating to the healthcare provider or the health system.
• In one or more embodiments, theschedule area1630 can include scheduling information associated with the healthcare provider's duties. For instance, the schedule area can include adaily schedule component1632 of patient appointments for thehealthcare provider1610. In the same or alternative embodiments, theschedule area1630 can include areminders component1634 to display reminders set up by or set up for thehealthcare provider1610.
• In certain embodiments, theperformance area1640 can include information regarding the performance of thehealthcare provider1610 as it relates to various metrics associated with the patients under the care of thehealthcare provider1610. For example, in one or more embodiments, theperformance area1640 can include information related to the high risk population ofpatients1642 seen by thehealthcare provider1610, the top 5chronic conditions1644 of the population of patients seen by thehealthcare provider1610, and/or thetreatment trends1646, e.g., out of network utilization, of the population of patients seen by thehealthcare provider1610.
• In one or more embodiments, theworklist area1650 may include alerts for one or more worklists associated with thehealthcare provider1610. In one embodiment, theworklist area1650 can include any alerts for which a population health management system, such as the populationhealth management system200 ofFIG. 2, has deemed relevant for thehealthcare provider1610 to be aware of. For example, in certain embodiments, theworklist area1650 can include alerts and/or notifications for thehealthcare provider1610 to be aware of new people that have been added to a registry or program, e.g., thealert1652. In the same or alternative embodiments, other alerts can be provided in theworklist area1650, such as alerts relating to the patients seen by thehealthcare provider1610 that detail emergency room visits, hospital discharge, readmission risk, and/or home device alerts.
• In certain embodiments, one or more of theareas1620,1630,1640, and1650 can include items that comprise links that lead to more expanded views or to another view. For example, in one or more embodiments, when thehealthcare provider1610 clicks and/or touches the registry/programs worklist (New Persons Qualify)tile1652 in theworklist area1650, anew view1700 may be opened, which is depicted inFIG. 17.
• In one or more embodiments, theview1700 ofFIG. 17 may be generated, at least in part, by one or more components of a population health server, such as thepopulation health server250 discussed above with reference toFIG. 2. In certain embodiments, a healthcare worker, e.g., thehealthcare worker1710, may choose to highlight information related to one of the patients provided on the worklist new persons list1720, such as thepatient1748. In such embodiments, upon choosing to highlight a specific patient, asituational view1730 may be provided. Thesituational view1730 can include apatient information area1738, a vitals andmeasurements area1732, anappointments list area1734, acare plan area1736, analerts area1740, alongitudinal record area1744, and/or acare team list1746.
• Thepatient information area1738 may include background information on thepatient1748, such as age, contact information, and health insurance information. In certain embodiments, the vitals andmeasurements area1732 can include data including blood pressure readings, height, weight, temperature, and/or heart rate. In the one or more embodiments, theappointments area1734 may include a list of upcoming and/or previous medical appointments for thepatient1748. In one or more embodiments, thecare plan information1736 can include medication information, diet information, exercise information, medical condition education, and/or appointments, recommended by one or more healthcare providers.
• In various embodiments, thealerts area1740 can include alerts related to thepatient1748. In such embodiments, the alerts can include any information that a healthcare provider, e.g., thehealthcare provider1710, may find relevant for providing care to the patient, such as that thepatient1748 that has been newly added to a diabetes registry.
• In certain embodiments, thelongitudinal record area1742 can include a list of any longitudinal records associated with one or more conditions of thepatient1748. In such embodiments, thehealthcare provider1710 can click and/or touch one or more of the listed longitudinal records to display the full longitudinal record. In the same or alternative embodiments, thelongitudinal record area1742 may include a list of medications that thepatient1748 is currently taking or is prescribed to be taking. In one or more embodiments, this list of medications may include medications that the patient is no longer taking. An exemplary longitudinal record is depicted inFIG. 18.
• In one or more embodiments, thecare team list1746 can include a list of all the care team members, such as physicians, specialists, care managers, etc., associated with thepatient1748. In certain embodiments, thecare team list1746 can include links to contacting any or all of the individual care team members.
• In the embodiment depicted inFIG. 18, theview1800 is identical to theview1700 discussed above with reference toFIG. 17 with the exception that theview1800 includes an overlaidlongitudinal record1810. In embodiments, thelongitudinal record1810 may be associated with a patient, e.g., thepatient1748 ofFIG. 17.
• In certain embodiments, thelongitudinal record1810 may be presented in any form known to one skilled in the art. For example, in embodiments, thelongitudinal record1810 may be presented as a pop-up window overlaying another view, such as theview1800. In one or more embodiments, thelongitudinal record1810 may be generated, at least in part, by one or more components of a population health server, such as thepopulation health server250 discussed above with reference toFIG. 2.
• In certain embodiments, thelongitudinal record1810 can include atimeline view area1820, a potentialcomplications viewing area1830, amedication list area1840, and/or aneducation area1850. In embodiments, thetimeline view area1820 can include atimeline view1822 that provides all the medical information associated with a patient, e.g., thepatient1748, regarding at least one medical condition, and may include information across all providers and/or across all venues.
• In one or more embodiments, thehealthcare provider1860 may interact with thetimeline view1822 to reveal all or a portion of the medical information related to a medical condition for a specified time. In one embodiment, thetimeline view1822 can allow a healthcare provider, e.g., thehealthcare provider1860, to view information related to all clinical visits and clinical results associated with a particular condition, e.g., diabetes, since the patient was diagnosed with the condition up until the present moment. For example, as can be seen in the embodiment depicted inFIG. 18,medical information window1824 is displayed, which specifically details a random blood glucose measurement associated with Oct. 10, 2013 at 10:35 AM. In certain embodiments, the scale of thetimeline view1822 may be changed by a healthcare provider, e.g., thehealthcare provider1860, using thetimeline scaling tool1826.
• In one or more embodiments, the potentialcomplications viewing area1830 can include a list of one or more potential complications associated with the medical condition of interest, such as diabetes. For example, the potentialcomplications viewing area1830 displays that there is a 27% chance of congestive heart failure in the next 12 months.
• In certain embodiments, themedication list area1840 can include a list of all medications that a patient, e.g., thepatient1748, is currently taking or is prescribed to take for any medical condition. In various embodiments, themedication list area1840 may include a list of all the medications that a patient is currently taking or is prescribed to take that are related to the medical condition of interest, e.g., diabetes.
• In various embodiments, theeducation area1850 can include a list of education programs recommended by a healthcare provider, e.g., thehealthcare provider1860, for a patient related to the medical condition of interest. In the embodiment depicted inFIG. 18, the education area includes a list of the education programs recommended by a healthcare provider and additionally can include information on whether or not such education programs have been completed by the patient.
• FIG. 19 depicts aschedule view1900 for ahealthcare provider1910 in accordance with one embodiment of the present invention. Theschedule view1900 may include apatient appointment list1920 for a specific day. In the same or alternative embodiments, the schedule view can include acolumn view1930 that may include an abbreviated schedule for thehealthcare provider1910.
• In various embodiments, theschedule view1900 can include information that has been generated, at least in part, by one or more components of a population health server, such as thepopulation health server250 discussed above with reference toFIG. 2.
• In certain embodiments, any or all of the components in theappointment list1920 and/orcolumn view1930 can include links to further information about the appoint or patient associated with the appointment. For example, in one or more embodiments, thehealthcare provider1910 may click on an area associated with a particular patient appointment, such as the appointment for thepatient1922 to reveal relevant information about this patient, such as that depicted in thepatient information view2000 ofFIG. 20.
• Thepatient information view2000 depicted inFIG. 20 can include any or all of the relevant information related to a particular patient, such as thepatient1922 described above with reference toFIG. 19. In various embodiments, thepatient information view2000 can include information that has been generated, at least in part, by one or more components of a population health server, such as thepopulation health server250 discussed above with reference toFIG. 2.
• In certain embodiments, thepatient information view2000 can include a generalpatient information area2020, amain view area2030, and anavigation area2060. Thepatient information area2020 may include general patient information that may be relevant to thehealthcare provider2010 when viewing medical problems associated with the patient, such as age, weight, and/or prescription allergies.
• In certain embodiments, thenavigation area2060 may list various categories of information associated with the patient through which thehealthcare provider2010 may interact to view additional patient information. In certain embodiments, the additional patient information may be populated in themain view area2030 and/or may appear as a pop-up window on top of thepatient information view2000.
• In one or more embodiments, themain view area2030 may include aproblems area2040 and a quality measuresarea2050. In such embodiments, theproblems area2040 may include a list of active2070 and historical2080 problems for the patient, such as theactive diabetes problem2072 for the patient. Further, in such embodiments, thehealthcare provider2010 may click on and/or touch any or all of the active2070 and/or the historical2080 problems listed in theproblems area2040 to view additional information associated with that problem. For example, in one or more embodiments, when thehealthcare provider2010 clicks on and/or touches thediabetes problem2072, a pop-up condition view may appear, such as that depicted inFIG. 21.
• As can be seen in the embodiment depicted inFIG. 21, a pop-upcondition view2110 can display over apatient information view2100. In the embodiment depicted inFIG. 21, thepatient information view2100 ofFIG. 21 is substantially identical to thepatient information view2000 described above with reference toFIG. 20 except for the presence of the pop-upcondition view2110. In certain embodiments, the pop-upcondition view2110 can include alongitudinal record2120 associated with a particular medical condition, e.g., a diabetes condition. In such embodiments, thelongitudinal record2120 may include all the properties and components as thelongitudinal record1810 discussed above with reference toFIG. 18. For example, in such embodiments, thelongitudinal record2120 may include atimeline view area2130, a potentialcomplications viewing area2140, amedication list area2150, and/or aneducation area2160.
• FIG. 22 depicts apatient workflow interface2200 for a healthcare provider, e.g., thehealthcare provider2210. Thepatient workflow interface2200 can include apatient information area2220, amain area2230, and anavigation area2260. Thepatient information area2220 may include pertinent patient information for ahealthcare provider2210 for recommending care to the patient, such as age, weight, and/or prescription allergies.
• In certain embodiments, thenavigation area2260 can include a list of categories of information associated with the patient from which thehealthcare provider2210 may interact with to view additional information or take additional actions.
• In one or more embodiments, themain area2230 can include additional information related to one or more of the categories from thenavigation area2260 chosen by thehealthcare provider2210. In the embodiment depicted inFIG. 22, themain area2230 can include a careplan recommendation interface2240 and apatient education interface2250. In certain embodiments, the careplan recommendation interface2240 can be configured to provide care recommendations for one or more medial conditions. In such embodiments, thehealthcare provider2210 can have the option to add and/or remove care recommendations for the one or more medical conditions. In various embodiments, thepatient education interface2250 can be configured to allow ahealthcare provider2210 to search a patient education database and/or select patient education programs recommended for the patient.
• FIG. 23 depicts apatient management interface2300 for a healthcare provider, e.g., thehealthcare provider2310. In embodiments, thepatient management interface2300 can provide at least a portion of patient information associated with the patients that are under the care of thehealthcare provider2310. In one or more embodiments, thepatient management interface2300 may be generated, at least in part, by one or more components of a population health server, such as thepopulation health server250 discussed above with reference toFIG. 2.
• In certain embodiments, thepatient management interface2300 can be configured to organize at least a portion of the patient information associated with thehealthcare provider2310 into multiple formats. For example, thepatient management interface2300 can includeviewing tab options2320 for thehealthcare provider2310 to choose when viewing the patient information. In the embodiment depicted inFIG. 23, thedashboard viewing option2322 is selected. In the dashboard view, thepatient management interface2300, in certain embodiments, can include apatient population area2330, acommunications area2340, and acategorical snapshot area2360.
• In certain embodiments, thepatient population area2330 can provide one or more metrics associated with the population of patients under the care of thehealthcare provider2310. For example, in the embodiment depicted inFIG. 23, thepatient population area2330 can include information related to the proportion ofpatients2332 that are high risk, which may be presented in a graphical format. In the same or alternative embodiments, thepatient population area2330 can include alist2334 of the top five chronic conditions among the population of patients under the care of thehealthcare provider2310 and/or a list of the persons or patients ofinterest2336.
• In one or more embodiments, thecommunications area2340 can include a list ofannouncements2342 and/ornotifications2344 for thehealthcare provider2310 in relation to the population of patients and/or in relation to the health system associated with thehealthcare provider2310.
• In various embodiments, thecategorical snapshot area2360 may include tiles, e.g., thetiles2362,2364, and2366, which can each provide a brief overview of the patient information organized in the various categories associated with theviewing tab options2320. For example, in embodiments, thetile2366 may include a brief overview of select information relating to medications.
• FIG. 24 depicts apatient management interface2400 for a particular healthcare provider, e.g., thehealthcare provider2410. In embodiments, thepatient management interface2400 can provide at least a portion of patient information associated with the patients that are under the care of thehealthcare provider2410. In one or more embodiments, thepatient management interface2400 may be generated, at least in part, by one or more components of a population health server, such as thepopulation health server250 discussed above with reference toFIG. 2.
• In certain embodiments, thepatient management interface2400 can be configured to organize at least a portion of the patient information associated with thehealthcare provider2410 in multiple formats. For example, thepatient management interface2400 can includeviewing tab options2420 for thehealthcare provider2410 to choose when viewing the patient information. In the embodiment depicted inFIG. 24, theregistries viewing option2422 is selected. In theregistries viewing option2422, thepatient management interface2400, in certain embodiments, can include aregistry information interface2430.
• Theregistry information interface2430 may include a depiction of various metrics for at least a portion of the registries associated with the population patients under the care of thehealthcare provider2410. For example, in the embodiment depicted inFIG. 24, theregistry information interface2430 can include a plurality oftiles2438 which can depict what percentage of patients have received care associated with that registry. For example, as depicted in thetile2439, 21% of the patients have received care related to their presence in the diabetes registry.
• In certain embodiments, theregistry information interface2430 can be configured to provide thehealthcare provider2410 various viewing options for the registries. For instance, in such embodiments, theregistry information interface2430 can include aviewing option2434 for viewing all registries or a specific registry. In the same or alternative embodiments, theregistry information interface2430 can include aviewing option2432 for viewing specific information about the registries that are chosen for viewing, such as a quality score. In one embodiment, a quality score can depict the percentage of patients that have received care or a consultation with respect the condition associated with a particular registry and/or the percentage of patients that have received care or a consultation with respect a particular treatment associated with a particular population of patients in a particular registry.
• In one or more embodiments, thepatient management interface2400 can include near real-time data that is supplied from a population health management system, such as the populationhealth management system200 discussed above with respect toFIG. 2. In such embodiments, thepatient management interface2400 may include anupdate indicator2440 so that thehealthcare provider2410 can be aware how current the information is. As used herein, near real-time data can mean data that is available for viewing or processing by one or more components of a population health management system, such as the populationhealth management system200 discussed above with respect toFIG. 2, within at least about 1 minute, 10 minutes, 30 minutes, 60 minutes, 120 minutes, 240 minutes, or 480 minutes of being input into any component or portion of such a population health management system.
• FIG. 25 depicts apatient management interface2500 for a particular healthcare provider, e.g., thehealthcare provider2510. In embodiments, thepatient management interface2500 can provide at least a portion of patient information associated with the patients that are under the care of thehealthcare provider2510. In one or more embodiments, thepatient management interface2500 may be generated, at least in part, by one or more components of a population health server, such as thepopulation health server250 discussed above with reference toFIG. 2.
• In certain embodiments, thepatient management interface2500 can organize at least a portion of the patient information associated with thehealthcare provider2510 in multiple formats. Further, in such embodiments, thepatient management interface2500 can includeviewing tab options2520 for thehealthcare provider2510 to choose when viewing the patient information. In the embodiment depicted inFIG. 25, theregistries viewing option2522 is selected. In theregistries viewing option2522, thepatient management interface2500, in certain embodiments, can include aregistry information interface2530.
• Like theregistry information interface2430 discussed above with reference toFIG. 24, theregistry information interface2530 can provide thehealthcare provider2510 various viewing options for the registries. For instance, theregistry information interface2530 may include aviewing option2532 for viewing all registries or a specific registry and/or aviewing option2534 for viewing specific information about the registries that are chosen for viewing, such as a quality score. In the embodiment depicted inFIG. 25, the specific registry of diabetes care and the associated quality score were selected.
• Further, like theregistry information interface2430 ofFIG. 24, theregistry information interface2530 may include a depiction of various metrics for at least a portion of the population of patients in the diabetes care registry that are under the care of thehealthcare provider2510. For example, in the embodiment depicted inFIG. 25, theregistry information interface2530 can include a plurality oftiles2536 which can depict what percentage of patients have received care for various treatment aspects associated with diabetes care. For example, as depicted in thetile2538, 12% of these patients have received a foot exam.
• Thepatient management interface2600 depicted inFIG. 26 is similar to thepatient management interface2500 discussed above with respect toFIG. 25, with the exception that the program measuresviewing option2614 was selected along with thediabetes care registry2612 to populate theregistry information interface2610.
• In the embodiment depicted inFIG. 26, the registry information interface can include alist2620 of various program measures and may further include a graphical representation of the compliance level associated with those measures. For instance, as seen in the embodiment depicted inFIG. 26, thelist2620 can include personal patientdocumentation measure indicators2622, healthcare eventcompliance measure indicators2624, and/or diabetes programcompliance measure indicators2626.
• FIG. 27 depicts apatient interface2700 where a patient, e.g., thepatient2710, may view and interact with information associated with any or all care programs associated with the patient's various medical conditions. In certain embodiments, thepatient interface2700 may include alist2720 of associated healthcare providers, anavigation panel2730, amain view area2740, and acommunication interface area2760.
• In certain embodiments, thenavigation panel2730 may include a list of various categories of information of which thepatient2710 may choose to view in themain view area2740 and/or to open new windows for additional information associated with a particular category.
• In the embodiment depicted inFIG. 27, themain view area2740 can include aplan view area2770, which may display various aspects of one or more care plans assigned to thepatient2710, such as medication, diet, and/or appointments. In the same or alternative embodiments, themain view area2740 can include arecent results area2750 that can display one or more results or data from a medical device, such as a weight scale or a blood pressure monitor.
• In one or more embodiments, thecommunication interface area2760 may be configured to allow the patient to contact or engage a number of various groups. For example, in such embodiments, thecommunication interface2760 may include links so that thepatient2710 can contact or message one or more healthcare providers, contact or message a particular community of patients, pay a medical bill, or obtain additional wellness information.
• FIG. 28 depicts an exemplary flow diagram for amethod2800 that facilitates designing and utilizing population health programs. Initially, at step,2810 healthcare data from disparate sources can be received by a population health server. In one embodiments, thestep2810 may be performed at least partly by the receivingcomponent252 discussed above with reference toFIG. 2. In embodiments, the healthcare data may include any or all of the properties of the healthcare data discussed above with reference to theEMRs212 ofFIG. 2. Instep2812, the population health server can be utilized to identify a population of patients based on a set of criteria. In certain embodiments, thestep2812 may be performed at least partly by the identifyingcomponent254 discussed above with reference toFIG. 2. In step2814, the population health server can utilized to stratify the population of patients based on one or more algorithms to create one or more groups of patients. In certain embodiments, the step2814 may be at least partly performed by the stratifyingcomponent256 discussed above with reference toFIG. 2. In step2816, the population health server can be utilized to create at least one registry, the at least one registry comprising at least a portion of the one or more groups. In one embodiment, the step2816 may be performed at least partly by the creatingcomponent258 discussed above with reference toFIG. 2. In one embodiment, the population health server ofsteps2810,2812,2814, and/or2816 can have any or all of the properties of thepopulation health server250 discussed above with reference toFIG. 2.
• FIG. 29 depicts an exemplary flow diagram for amethod2900 that facilitates designing and utilizing population health programs. Instep2910, healthcare data from disparate sources can be received by a population health server. In one embodiments, thestep2910 may be performed at least partly by the receivingcomponent252 discussed above with reference toFIG. 2. In embodiments, the healthcare data may include any or all of the properties of the healthcare data discussed above with reference to theEMRs212 ofFIG. 2. Instep2912, the population health server can be utilized to identify a population of patients based on one or more medical conditions. In certain embodiments, thestep2912 may be performed at least partly by the identifyingcomponent254 discussed above with reference toFIG. 2. In step2914, the population health server can be utilized to stratify the population of patients into one or more groups based on at least one algorithm. In certain embodiments, the step2914 may be at least partly performed by the stratifyingcomponent256 discussed above with reference toFIG. 2. Instep2916, an opportunity for a clinician to confirm an output of the at least one algorithm can be provided. In one embodiment, thestep2916 may be performed at least partly by theoutput component260 discussed above with reference toFIG. 2. Instep2918, the population health server can be utilized to create at least one registry for the population of patients based on at least a portion of the output of the at least one algorithm. In one embodiment, the population health server ofsteps2910,2912,2914, and/or2918 can have any or all of the properties of thepopulation health server250 discussed above with reference toFIG. 2.
• FIG. 30 depicts an exemplary flow diagram for amethod3000 for stratifying one or more patients into one or more groups. Instep3010, healthcare data can be received by a population health server. The healthcare data may include clinical impressions and/or clinical narratives from one or more healthcare providers. In embodiments, the healthcare data may include any or all of the properties of the healthcare data discussed above with reference to theEMRs212 ofFIG. 2. In one embodiment, thestep3010 may be performed at least partly by the receivingcomponent252 discussed above with reference toFIG. 2. Instep3012, the population health server can be utilized for natural language processing to extract one or more clinical indicators from the healthcare data. In certain embodiments, thestep3012 may be at least partly performed by the naturallanguage processing component270 discussed above with reference toFIG. 2. Instep3014, the population health server can be utilized to stratify one or more patients into one or more groups based on at least a portion of the one or more clinical indicators. In one embodiments, thestep3014 may be at least partly performed by the stratifyingcomponent256 discussed above with reference toFIG. 2. Instep3016, the population health server can be utilized to create at least one registry comprising the one or more groups. The at least one registry may account for one or more of: resources available to a patient; lifestyle and prognostic assets that can be used for prediction; and assets necessary for attribution, allocation, or measurement. In certain embodiments, thestep3016 may be at least partly performed by the creatingcomponent258 discussed above with reference toFIG. 2. In one embodiment, the population health server ofsteps3010,3012,3014, and/or3016 can have any or all of the properties of thepopulation health server250 discussed above with reference toFIG. 2.
• FIG. 31 depicts an exemplary flow diagram for amethod3100 for stratifying one or more patients into one or more groups. Instep3110, healthcare data from disparate sources can be received by a population health server. The healthcare data may comprise clinical impressions and/or clinical narratives from one or more healthcare providers. In one embodiment, thestep3110 may be performed at least partly by the receivingcomponent252 discussed above with reference toFIG. 2. In embodiments, the healthcare data may include any or all of the properties of the healthcare data discussed above with reference to theEMRs212 ofFIG. 2. Instep3112, the population health server can be utilized for natural language processing to extract one or more clinical indicators from the healthcare data, where the one or more clinical indicators are associated with one or more chronic conditions. In certain embodiments, thestep3112 may be at least partly performed by the naturallanguage processing component270 discussed above with reference toFIG. 2. Instep3114, a relevance rating can be provided to each of the one or more clinical indicators. In one embodiments, thestep3114 may be at least partly performed by the naturallanguage processing component270 discussed above with reference toFIG. 2. Instep3116, the population health server can be utilized to stratify one or more patients into one or more groups based on at least a portion of the one or more clinical indicators. In one embodiment, thestep3116 may be at least partly performed by the stratifyingcomponent256 discussed above with reference toFIG. 2. Instep3118, the population health server can be utilized to create at least one registry comprising the one or more groups. The at least one registry may account for one or more of: resources available to a patient; lifestyle and prognostic assets that can be used for prediction; and assets necessary for attribution, allocation, or measurement. In certain embodiments, thestep3118 may be at least partly performed by the creatingcomponent258 discussed above with reference toFIG. 2. In one embodiment, the population health server ofsteps3110,3112,3116, and/or3118 can have any or all of the properties of thepopulation health server250 discussed above with reference toFIG. 2.
• FIG. 32 depicts an exemplary flow diagram for amethod3200 that facilitates using at least one clinically relevant algorithm in population health programs. Instep3210, healthcare data from disparate sources can be received by a population health server. In one embodiment, thestep3210 may be performed at least partly by the receivingcomponent252 discussed above with reference toFIG. 2. In embodiments, the healthcare data may include any or all of the properties of the healthcare data discussed above with reference to theEMRs212 ofFIG. 2. Instep3212, the population health server can be utilized to stratify a population of patients based on one or more algorithms to create one or more groups of patients, where the one or more algorithms comprise at least one clinically relevant algorithm utilizing clinical data. In one or more embodiments, the clinical data can have any or all of the properties of the clinical data discussed above with reference to theEMRs212 ofFIG. 2. In certain embodiments, thestep3212 may be performed at least partly by the stratifyingcomponent256 discussed above with reference toFIG. 2. Instep3214, the population health server can be utilized to create at least one registry, the at least one registry comprising at least a portion of the one or more groups. In one embodiment, thestep3214 may be at least partly performed by the creatingcomponent258 discussed above with reference toFIG. 2. In one embodiment, the population health server ofsteps3210,3212, and/or3214 can have any or all of the properties of thepopulation health server250 discussed above with reference toFIG. 2.
• FIG. 33 depicts an exemplary flow diagram for amethod3300 that facilitates utilizing clinically relevant algorithms for registry population. Instep3310, healthcare data from disparate sources can be received by a population health server. In one embodiment, thestep3310 may be performed at least partly by the receivingcomponent252 discussed above with reference toFIG. 2. In embodiments, the healthcare data may include any or all of the properties of the healthcare data discussed above with reference to theEMRs212 ofFIG. 2. Instep3312, the population health server can be utilized to identify a population of patients based, at least partly, on one or more medical conditions. In one embodiment, thestep3312 may be at least partly performed by the identifyingcomponent254 discussed above with reference toFIG. 2. Instep3314, the population health server can be utilized to stratify the population of patients based on at least a clinically relevant algorithm, the clinically relevant algorithm utilizing clinical data. The clinical data including one or more of medication information, laboratory values, diagnostics, clinician narratives, and clinician assessments. In one or more embodiments, the clinical data can have any or all of the properties of the clinical data discussed above with reference to theEMRs212 ofFIG. 2. In certain embodiments, thestep3314 may be performed at least partly by the stratifyingcomponent256 discussed above with reference toFIG. 2. Instep3316, the population health server can be utilized to create at least one registry for the population of patients based on at least a portion of an output of the clinically relevant algorithm. In one embodiment, thestep3316 may be at least partly performed by the creatingcomponent258 discussed above with reference toFIG. 2. Instep3318, the population health server can be utilized to update the at least one registry when additional clinical data is available for the clinically relevant algorithm to utilize. In one embodiment, thestep3318 is at least partly performed by the receivingcomponent252, the stratifyingcomponent256, and/or the creatingcomponent258 discussed above with reference toFIG. 2. In one embodiment, the population health server ofsteps3310,3312,3314,3316, and/or3318 can have any or all of the properties of thepopulation health server250 discussed above with reference toFIG. 2.
• Referring now toFIG. 34, an exemplary flow diagram is depicted of amethod3400 of providing a cross venue antibiogram. Initially, atstep3410, medications information is received from disparate sources. The disparate sources may include multiple venues, multiple providers, and across multiple conditions (e.g., from more than one registry identifying more than one condition). Susceptibility results based on testing associated with patient information are received, atstep3412, from the disparate sources. The susceptibility results may include results from testing being performed on inpatients, outpatients, and patients within the community outside of a hospital setting (e.g., non-acute care settings). The susceptibility results may include patient demographics but does not include patient identifiers.
• A cross venue antibiogram is created, at step3414, based on the medications information and the susceptibility results. Atstep3416, the cross venue antibiogram is communicated to a clinician device. The cross venue antibiogram allows the clinician to more accurately prescribe medications by providing information as to which medications will be most effective based on the patients circumstances and location or setting and provides a broad view of susceptibility result trends. In embodiments, one or more populations can be monitored, based on the cross venue antibiogram, for development of antimicrobial resistance, unnecessary prescriptions, incorrect or more costly medications, neglecting to order follow up labs to monitor for adverse drug reactions, patients not refilling medications as prescribed, drug interactions for patients using multiple pharmacies and/or providers.
• In one embodiment, filtering of the antibiogram is enabled based on selected demographics. In this regard, a clinician can filter the antibiogram based on circumstances relevant to the patient to create a patient-specific antibiogram. The demographics may include an institution, a practice associated with a clinician, a zip code, a county, a city, a state, a region, or a country. A specific disease state may be selected for a patient or received from one or more data sources. Patient information including related conditions, laboratory results, and allergy information for the patient may additionally be received from one or more data sources. Multiple medication options for the patient may be provided based on the received information and the patient-specific antibiogram. The medication options may include dosing, generic alternatives, cost, availability, and susceptibility information, the cost including relative cost, actual wholesale price, institution cost, patient cost, or cost effectiveness, and/or the availability including a numerical amount or relative amount of a drug in stock.
• In embodiments, the cross venue antibiogram can be further utilized to determine a medication for a patient is being prescribed appropriately, as shown atstep3418. For example, information from a data source may indicate the patient was prescribed a medication that is ineffective given the patient's condition or particular location. Similarly, the information may indicate a different medication is more effective. In these examples, it is determined that the medication is not being prescribed appropriately. In a situation where the information indicates the medication is the most effective given the patient's condition or particular location, it is determined that the mediation is being prescribed appropriately. In an embodiment, if it is determined that the medication is not being prescribed appropriately, inappropriate trends (i.e., the medication is not being prescribed appropriately) may be flagged atstep3420. Additionally or alternatively, a medication steward may be alerted to intervene. Inappropriate trends and/or interventions may be documented via an automated messaging system. Similarly, in one embodiment, interventions may be electronically captured for trending and reporting. Provider prescribing trends and effects of intervention may be monitored, atstep3422.
• In embodiments, information from a data source may indicate the patient was prescribed a medication that requires a particular form of monitoring, follow-up, education, additional laboratories, and the like. Based on additional information from a data source that may indicate a requirement has or has not been fulfilled, in one embodiment, it is assessed, atstep3424, if the patient is being properly monitored and educated. In one embodiment, as shown atstep3426, patient or clinician non-compliance and the need for additional education is predicted. In one embodiment, any or all of the steps ofmethod2400 may be at least partly performed by one of various components of thepopulation health server250 discussed above with reference toFIG. 2.
• Turning now toFIG. 35, an exemplary flow diagram is depicted of amethod3500 of providing a comprehensive medication advisor. Initially, atstep3510, a selection of a disease state is received from a clinician device. Patient information including related conditions, laboratory results, allergy information for the patient is received from one or more electronic medical records atstep3512. Utilizing susceptibility data, based on a cross venue antibiogram, one or more medication options are provided for the disease state, atstep3514. The medication options may include dosing, generic alternatives, cost, availability, and susceptibility information. The cost may include relative cost, actual wholesale price, institution cost, patient cost, or cost effectiveness. The availability may include a numerical amount or relative amount of a drug in stock. The susceptibility information may be based on the antibiogram and may include information relevant to one or more of the patient, an institution, a practice associated with a clinician, a zip code, a county, a city, a state, a region, or a country. The one or more medication options are provided to the clinician device, atstep3516. In one embodiment, as shown atstep3518, if a clinician prescribes a medication that is not one of the one or more medication options, a medication steward is alerted to intervene. Alternatively or additionally, prescribing trends and effects of intervention is monitored, in one embodiment, atstep3520. In one embodiment, any or all of the steps ofmethod3500 may be at least partly performed by one of various components of thepopulation health server250 discussed above with reference toFIG. 2.
• The present invention has been described in relation to particular embodiments, which are intended in all respects to be illustrative rather than restrictive. Further, the present invention is not limited to these embodiments, but variations and modifications may be made without departing from the scope of the present invention.

Claims (20)

What is claimed is:

1. One or more computer storage media storing computer-executable instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform a method that facilitates designing and utilizing population health programs

receiving, at a population health server, healthcare data from disparate sources;

receiving a set of criteria from a user to identify a population of patients;

stratifying the population of patients, via the population health server, based on the set of criteria and one or more algorithms to create one or more groups of patients, wherein at least one group of the one or more groups of patients comprises a plurality of patients having at least one substantially similar attribute; and

providing a worklist to a device associated with the user, the worklist comprising a list of one or more patients from the at least a portion of the one or more groups.

2. The media ofclaim 1, wherein the one or more patients are associated with a substantially similar medical condition.

3. The media ofclaim 1, wherein the worklist provides, across multiple venues, multiple providers, and multiple conditions, actionable decision support tools and interventions.

4. The media ofclaim 1, wherein the worklist provides, across multiple venues, multiple providers, and multiple conditions, linking between applications.

5. The media ofclaim 1, wherein the worklist enables, across multiple venues, multiple providers, and multiple conditions, documentation for one or more healthcare providers.

6. The media ofclaim 1, wherein the worklist links information and workflows from separate venues or across a community.

7. The media ofclaim 1, wherein the worklist is configured to be parsed based on healthcare providers, venues, and/or one or more medical conditions.

8. The media ofclaim 1, wherein the worklist includes a patient's name, risk level, location, clinical issues and alerts, care planning, payer information, demographics, medication information, and/or appointments.

9. The media ofclaim 1, wherein the disparate sources include a plurality of EMRs, and wherein at least a portion of the plurality of EMRs is associated with the same patient.

10. The media ofclaim 9, wherein the plurality of EMRs are associated with at least one of: a plurality of healthcare providers, a plurality of patients, a plurality of medical conditions, a plurality of healthcare venues and/or facilities, a plurality of organizations, and a plurality of communities.

11. The media ofclaim 1, wherein the set of criteria comprises one or more medical conditions of interest to the user.

12. The media ofclaim 1, wherein the healthcare data comprises one or more of clinical data, healthcare-related financial data, and patient sensor and/or patient device data.

13. The media ofclaim 1, wherein the at least one substantially similar attribute comprises one or more disease risk levels and/or scores, one or more disease stages, and/or one or more healthcare objective.

14. The media ofclaim 1, wherein the worklist dynamically and automatically repopulates as patients enter or are removed from the worklist.

15. The media ofclaim 1, wherein the worklist provides details in a historical and/or longitudinal view.

16. The media ofclaim 1, wherein the worklist provides a manageable list of cross-continuum, cohort specific patients that may be available to a healthcare provider or administrative body.

17. The media ofclaim 1, wherein the provides contextuality to the user for a designated cohort.

18. The media ofclaim 1, wherein the worklist enables cross-continuum monitoring of a variety of activities by providing the user the ability to monitor events that have occurred or are occurring in near real-time.

19. A computer system that facilitates designing and utilizing population health programs, the computer system comprising a processor coupled to a computer storage medium, the computer storage medium having stored thereon a plurality of computer software components executable by the processor, the computer software components comprising:

a receiving component that receives healthcare data from disparate sources;

an identifying component that identifies a population of patients based on a set of criteria selected by a user;

a stratifying component that stratifies the population of patients based on the set of criteria and one or more algorithms to create one or more groups of patients, wherein at least one group of the one or more groups of patients comprises a plurality of patients having at least one substantially similar attribute; and

a worklist component that provides a worklist that comprises a list of one or more patients from the at least a portion of the one or more groups, the one or more patients associated with a substantially similar medical condition, wherein the worklist supports, across multiple venues, multiple providers, and multiple conditions, providing actionable decision support tools and interventions.

20. A computer-implemented method in a clinical computing environment comprising:

receiving, via a first computing process, healthcare data from disparate sources;

receiving, via a second computing process, a set of criteria from a user to identify a population of patients;

stratifying, via a third computing process, the population of patients based on the set of criteria and one or more algorithms to create one or more groups of patients, wherein at least one group of the one or more groups of patients comprises a plurality of patients having at least one substantially similar attribute; and

providing, via a fourth computing process, a worklist to a device associated with the user, the worklist comprising a list of one or more patients from the at least a portion of the one or more groups;

wherein each of the computing processes is performed by one or more computing devices.

Images