1. Field
This field is generally related to data analysis systems, and more particularly to systems for managing and analyzing massive quantities of population health data.
2. Background
Medical records related to a patient's health information are essential to the practice of medical care. Traditionally, medical records were paper-based documents. The emergence of electronic health record (EHR) systems offers medical professionals and patients with new functionalities that paper-based medical records cannot provide. An EHR, sometimes known as electronic medical record (EMR), is a collection of electronically stored information about an individual patient's lifetime health status and health care. EHRs may include a broad range of data, including demographics, medical history, medication and allergies, immunization status, laboratory test results, radiology images, vital signs, personal statistics like age and weight, and billing information. Many commercial EHR systems combine data from a number of health care services and providers, such as clinical care facilities, laboratories, radiology providers, and pharmacies.
EHRs are a drastic improvement over paper-based medical records. Paper-based medical records require a large amount of storage space. Paper records are often stored in different locations, and different medical professionals may each have different and incomplete records about the same patient. Obtaining paper records from multiple locations for review by a health care provider can be time consuming and complicated. In contrast, EHR data is stored in digital format, and thus can be accessed from anywhere. EHR systems significantly simplify the reviewing process for health care providers. Because data in EHRs can be linked together, EHRs vastly improve the accessibility of health records and the coordination of medical care.
EHRs also decrease the risk of misreading errors by health care professionals. Poor legibility is often associated with handwritten, paper medical records, which can lead to medical errors. EHRs, on the other hand, are inherently legible given that they are typically stored in typeface. In addition, electronic medical records enhance the standardization of forms, terminology and abbreviations, and data input, which help ensure reliability of medical records. Further, EHRs can be transferred electronically, thus reducing delays and errors in recording prescriptions or communicating laboratory test results.
The benefits of digitizing health records are substantial. Health care providers with EHR systems have reported better outcomes, fewer complications, lower costs, and fewer malpractice claim payments. But despite EHRs' potential in drastically improving the quality of medical care, only a low percentage of health care providers use EHR systems. While the advantages of EHRs are significant, they also carry concerns, including security and privacy risks, high costs, lost productivity during EHR implementation or computer downtime, and lack of EHR usability.
The Health Insurance Portability and Accountability Act (HIPAA), enacted in the U.S. in 1996, establishes rules for access, authentication, storage, auditing, and transmittal of medical records. HIPPA sets a limit as to what health information can be disclosed to third parties, and who can view a patient's medical records. HIPPA protects information in electronic medical records, such as information doctors and nurses input, recorded conversations between a doctor and a patient, and billing information. The HIPAA Security Rule, effective on Apr. 20, 2005 for most covered entities, adds additional constraints to electronic data security and the storage and transmission of private health information (PHI). Despite the regulatory restrictions, privacy and security threats are still a major risk of the current EHR systems. The convenient and fast access to patients' health records through an EHR system introduces a host of security concerns. Medical information in digital format is vulnerable to various privacy exploitations associated with hacking, computer theft, malicious attack, or accidental disclosure. According to some estimates, between 250,000 and 500,000 patients experience medical identity theft every year.
Additionally, the high cost of EHRs also significantly hinders EHR adoption. A large number of physicians without EHRs have referred to initial capital costs as a barrier to adopting EHR systems. Cost concerns are even more severe in smaller health care settings, because current EHR systems are more likely to provide cost savings for large integrated institutions than for small physician offices. During EHR technology's implementation, productivity loss can further offset efficiency gains. The need to increase the size of information technology staff to maintain the system adds even more costs to EHR usages.
Usability is another major factor that holds back adoption of EHRs. It is particularly challenging to develop user-friendly EHR systems. There is a wide range of data that needs to be integrated and connected. Complex information and analysis needs vary from setting to setting, among health care provider groups, and from function to function within a health care provider group. To some providers, using electronic medical records can be tedious and time consuming, and the complexity of some EHR systems renders the EHR usage less helpful. Some doctors and nurses also complain about the difficulty and the length of time to enter patients' health information into the system.
Under-utilization of EHR systems, despite incentives and mandates from the government and the tremendous potential of EHRs in revolutionizing the health care system, calls for better EHR systems that are secure, cost-effective, efficient, and user-friendly.
Comprehensive EHR systems can provide capabilities far beyond simply storing patients' medical records. Because EHR systems offer health care providers and their workforce members the ability to securely store and utilize structured health information, EHR systems can have a profound impact on the quality of the health care system. In Framework for Strategic Action on Health Information Technology, published on Jul. 21, 2004, the Department of Health & Human Services (HHS) outlined many purposes for EHR services. The outlined purposes include, among other things, improving health care outcomes and reducing costs, reducing recordkeeping and duplication burdens, improving resource utilization, care coordination, active quality and health status monitoring, reducing treatment variability, and promoting patients' engagement in and ownership over their own health care.
Recent legislation has set goals and committed significant resources for health information technology (IT). One of the many initiatives of the American Recovery and Reinvestment Act of 2009 (ARRA) was “to increase economic efficiency by spurring technological advances in science and health.” The Health Information Technology for Economic and Clinical Health (HITECH) Act, passed as a part of ARRA, allocated billions of dollars to adopt meaningful use of EHRs in the health care system. HITECH also mandates the Office of the National Coordinator for Health Information Technology (ONC) to define certification criteria for “Certified EHR Technology.”
EHR systems satisfying “Certified EHR Technology” criteria are capable of performing a wide range of functions, including: entry and storage, transmission and receipt of care summaries, clinical decision support, patient lists and education resources, generation of public health submission data, and patient engagement tools. Entry and storage is related to the ability to enter, access and modify patient demographic information, vital signs, smoking status, medications, clinical and radiology laboratory orders and results. Transmission and receipt of care summaries involve the ability to receive, incorporate, display and transmit transition of care/referral summaries. Clinical decision support features configurable clinical decision support tools, including evidence-based support interventions, linked referential clinical decision support, and drug-drug and drug-allergy interaction checks. Patient lists and education resources include the ability to create patient lists based on problems, medications, medication allergies, demographics and laboratory test result values, and the ability to identify patient-specific education resources based on such data elements. Generating public health submission data allows users to create electronic immunization and syndromic surveillance data files that can be submitted to public health agencies. Patient engagement tools allow medical professionals to grant patients with an online means to view, download and transmit their health information to a third party, provide patients with clinical summaries after office visits, and facilitate secure-doctor patient messaging.
Population health may describe the health outcomes of a group of individuals. Medical care is one factor that affects those outcomes. Other factors include public health interventions, aspects of the social environment (income, education, employment, social support, and culture) and of the physical environment (urban design, clean air, and water), genetics, and individual behavior.
Managing a population's health may involve the organization and management of the healthcare delivery system in a manner that makes it safer, more clinically effective, and more cost effective.
Data processing may assist in population health management. However, significant technical problems exist that limit the ability to manage and analysis large amounts of diverse data to produce effective health management indicia and notifications. Specifically, as the number of patients in the population, the criteria for assessing health outcomes, and the data involved in assessing health outcomes all grow, computing resources, such as processing power and memory, may get bogged down, hindering performance. Furthermore, existing system architectures are inadequate to support the diverse sources of data and large amounts of data needed to be processed in near real time. Improved systems and methods for managing and analyzing population health data are needed.
In an embodiment, a system provides population health management. The system includes a computing device, and, implemented on the computing device, a clinical guideline database, a patient health data interface, a population health management engine, and a practitioner communications module. The clinical guideline database includes clinical guidelines related to one or more medical conditions. The patient health data interface receives patient health data entries. The population health management engine generates outputs based at least upon patient health data entries and clinical guidelines. Finally, the practitioner communications module presents data the population health management engine generates, and enables a practitioner to interact with the system.
Method and computer program product embodiments are also disclosed.
Further embodiments, features, and advantages of the invention, as well as the structure and operation of the various embodiments, are described in detail below with reference to accompanying drawings.
The accompanying drawings, which are incorporated herein and form part of the specification, illustrate the present disclosure and, together with the description, further serve to explain the principles of the disclosure and to enable a person skilled in the relevant art to make and use the disclosure.
The drawing in which an element first appears is typically indicated by the leftmost digit or digits in the corresponding reference number. In the drawings, like reference numbers may indicate identical or functionally similar elements.
Embodiments relate to population health management. To assess the health of individual patients, data about the patients may be compared against various criteria. When the criteria are met, the patient or her health practitioner may be notified of potential issues. Population health management may look beyond the health of an individual patient to other individuals in a common group. For example, a physician may be interested in the aggregate health of all patients in her practice. Similarly, other healthcare organizations—such as insurance providers or government organizations—may be interested in aggregate population data. The aggregated population health data may, for example, provide useful information about how successful different physicians are in treating their patients.
Embodiments relate to processing this population health data. In particular, some embodiments relate to dividing processing of the population health data into two different software modules. The first module processes incoming health data in real time to determine whether a criteria is met. For example, when the patient's blood pressure is measured, the blood pressure may be assessed against a criteria defining a threshold blood pressure level, above which corrective measures, such as diet or medication, should be taken. If the module determines that the criteria is met, the module may send a notification to the patient or position regarding the measurement and recommending corrective action. In this way, by assessing patient health data in real time, embodiments provide actionable data for individual patients in a timely manner.
In addition to the real time module, embodiments also include a second module that does not operate on the data in real time. Instead, this module may operate periodically and may assess the criteria against an entire population of patients. This module would then determine aggregate statistics for the population. For example, this module may determine what percentage of a particular physician's patients have high blood pressure. In this way, by determining aggregate statistics on a periodic, non-real time basis, embodiments may more efficiently process data needed to conduct population health management.
The following detailed description is divided into four sections. First, a population health management system according to embodiments is described with respect to
As explained in detail below, population health management system 100 dynamically applies clinical guidelines and predictive models across patient populations to identify care gaps and stratify risks. Additionally, system 100 accesses health information from many patients being served by many practitioners. With access to large volumes of patient health data for patients served by many practitioners, system 100 provides aggregated analytics related to patient medical conditions, outcomes, and treatments that can be compared across practitioners or against benchmarks.
Population health management system 100 includes four modules: population patient health data interface 120, notification module 150, reporting module 140 and population health management engine 110. Population health management engine 110 includes two submodules: real time processing engine 112 and non-real time processing engine 114. System 100 also includes three databases: patient health database 132, clinical guideline database 134, and population measurement database 136.
In general, patient health management system 100 operates as follows. Patient health data interface 120 receives patient health data, formats it uniformly, and stores it in patient health database 132. Patient health data interface 120 also transmits the patient health data to population health management engine 110. Population health management engine 110's real time processing engine 112 evaluates the data against criteria stored in clinical guideline database 134. If the data matches the criteria, notification module 150 sends a notification to the patient or to the patient's physician or other healthcare provider.
Separately from real time processing engine 112's assessment, non-real time processing engine 114 evaluates the patient health data stored in patient health database 132 to determine whether it meets criteria in clinical guideline database 134. As a result of this evaluation, non-real time processing engine 114 may determine ratios of patients within populations that meet the criteria in clinical guideline database 134. Then, non-real time processing engine 114 may store the determined ratios in population measurement database 136. The ratios are available to patients and their healthcare providers through reporting module 140. In addition, healthcare providers may receive the ratios as notifications via notification module 150. Each of these modules and its operation are discussed in detail below.
Patient health data interface 120 receives patient health data entries that are provided to population health management engine 110 for evaluation and processing. Patient health data interface 120 may, for example, receive data from an electronic health record system. Patient health data interface 120 accesses patient health data and structures the health data into a common data language. The common data language may include entries encoded using the Quality Data Model (QDM). In an embodiment, patient health data interface 120 may receive event changes and store the formatted information in patient health database 132 in a patient-specific log, as described below with respect to
Event receipt module 152 receives that notifications when patient health information is generated, altered, or deleted. The events may occur, for example, when there are changes to a patient's diagnosis, medication, vaccination, labs, allergies, family history, risk factors (e.g., tobacco use), demographics, encounters, vitals, procedures, screening/assessment/interventions, referrals, and patient conditions. The events may be transmitted by different health databases whenever a patient's health data changes. They may be formatted, for example, as API requests. When a new event is received, events receipt module 152 receives data describing the change in stores the data on service bus 154.
Service bus 154 queues the incoming events. For example, service bus 154 may operate in a first-in-first-out manner to store incoming events and provide them to event listener 156.
Event listener 156 may be one or more threads of execution that watch for data on service bus 154. When data is available on service bus 154, event listener 156 takes the data off service bus 154 and uses it to alter a patient-specific file that describes the patient's health in a common format, such as the Quality Data Model, stored in patient health database 132.
Depending on the event data, event listener 156 may delete QDM entries for the patient. It may add new QDM entries for the patient. Or it may alter QDM existing entries for the patient. For example, if an API request is received by event receipt module 152 and queued on service bus 154 that indicates that a patient is no longer taking a particular medication, then event listener 156 would remove the QDM entry representing the medication from the patient-specific file. This may involve, for example, looking up the QDM code for that medication and deleting the QDM entry corresponding to that medication code and the patient's corresponding patient ID. In other examples, a single event may alter delete or remove multiple QDM entries.
In this way, by receiving events and queuing them on the service bus, embodiments obviate the need to individually query large number of databases. In particular, the relevant data is pushed to the first service bus and then to a patient specific table or data file, assembling all the data needed for clinical decision support in a single location. By having the data together in a single location, embodiments may enable clinical decision support over a large number of patients or within a greater amount of data than would be otherwise possible.
The QDM describes clinical concepts in a standardized format so individuals (e.g., providers, researchers, measure developers) monitoring clinical performance and outcomes can clearly and concisely communicate necessary information. The QDM may be specified by the Centers for Medicare and Medicaid Services.
Each QDM entry may represent a wide range of things, including diagnoses, medications, vitals, lab tests, encounters, procedures, allergies, referrals, family histories, patient and provider characteristics, and EHR-specific events. To represent these different things, an entry may include a variety of data points, including:
The combination of the category, state, and negation data points may define a class of the corresponding entry. This class may indicate that other optional data points may be present. The optional data points may include:
In this way, patient health data interface 120 structures incoming health information. After formatting the health information, patient health data interface 120 stores the information in patient health database 132 and sends it to population health management engine 110 for processing.
Returning to
As mentioned above, clinical guideline database 134 stores clinical guidelines related to one or more medical conditions. The clinical guidelines stored within database 134 are provided to the population health management engine 110 and applied against patient health data entries in patient health database 132 for population health management engine 110 to generate various outputs.
The clinical guidelines may be stored in a scripting language that is set-based. A set-based scripting language may consume and create collections of things by examining the attributes of each thing, and the relationship between things. The things in question can take a variety of forms, and may together create a tuple, such as a relational algebra tuple. The language may support many relational operations like projection, selection, union, intersection, difference, semijoin, antijoin, count, sum, first, and last.
The clinical guidelines may stratify patients into patient groups. The stratification may be based on levels of risk to a medical condition. For example, for patients with a healthy weight, the clinical guidelines may trigger an action when engine 112 receives a blood pressure measurement above 140 mm Hg. But for obese patients, the threshold may lower. For obese patients, clinical guidelines may trigger an action when engine 112 receives a blood pressure measurement above only 130 mm Hg.
The clinical guidelines may be standard or may include rules specific to a particular practitioner. For example, a practitioner may specify rules that request notification whenever one of her patients' cholesterol is measured to be above a threshold, such as 200 mg/dL. Also, the practitioner may specify rules that trigger a notification when one of her patients meets a particular guideline. For example, a practitioner trying to help control a patient's blood pressure may request a notification when that patient's blood pressure drops below threshold, such as 180 mg/dL.
When engine 112 determines that the formatted clinical data received from patient health data interface 120 meets criteria stored in clinical guideline database 134, engine 112 signals notification module 150 to send a notification.
Notification module 150 sends a clinical notification that indicates the medical characteristics of the patient that violates or achieves a clinical guideline. The clinical notification may be sent to the patient or the patient's health practitioner. The notification may involve sending a text message or email indicating that a new notification is available. On receipt of the text message or email, the patient or health practitioner may log into a secure portal to review the notification. An example notification is illustrated in
The notification may ask that the patient schedule an appointment with a practitioner. Notification module 150 may record whether the patient actually schedules an appointment in response to the notification to track response rates. Notification module 150 may use the patient's past response rate to determine whether to send future notifications to the patient. In this way, notification module 150 may throttle back on notifications likely to be ignored.
In addition to processing new data for individual patients as it comes in, population health management engine 110 also processes data across a population, such as a practitioner's patient roster, to determine a portion of the population that complies with the clinical guidelines in clinical guideline database 134. To generate this population data, population health management engine 110 uses non-real time processing engine 114. Non-real time processing engine 114 may execute periodically, such as nightly. On execution, engine 114 may, for each population, determine the ratio of patients in patient health database that comply with various guidelines in clinical guideline database 134 and store the ratios in population measurement database 136.
Engine 114 may operate by translating the scripted guidelines in clinical guideline database 134 into stored procedures, such as SQL stored procedures. A stored procedure may be a subroutine implemented on the database management system and may be available to applications that access a relational database system. For example, stored procedures can consolidate and centralize logic that was originally implemented in applications. Stored procedures may consolidate processing that would otherwise require engine 114 to execute of several SQL statements on database 132, into a single call to database 132's database management system. In that example operation, during periodic executions, engine 114 would operate by calling the stored procedures to return the population data.
When its periodic processing is complete, engine 114 stores the resulting population data to population measurement database 150. The population data may include several lists of patients, or possibly specific occurrences for a patient (when counting events as opposed to people). These several lists constitute the base population (Denominator), patients meeting a specific guidelines (Numerator), and patients with special circumstances (Exception and Exclusion). To attribute responsibility for the care of a patient to one or more providers, an attribution population may also be included. The attribution population is a set of provider-patient (or provider-occurrence) pairs. Finally, to assist in providing clinical decision support, an alert population may be used. The alert population may specify patients for which a clinical action is recommended. The types of populations that may be determined by engine 114 and stored in population measurement database 150 are below:
Once the population data is stored in population measurement database 136, reporting module 140 uses to the population data to generate reports. In an embodiment, these reports are provided through a practitioner dashboard. Example embodiments of a practitioner dashboard are illustrated in
In one embodiment, reporting module 140 may personalize a dashboard to a practitioner. In another embodiment, the practitioner dashboard may display a meta-dashboard with a summary panel for each available population management dashboard, and each population management dashboard may provide population management outputs related to a particular medical condition. In yet another embodiment, the population management dashboard may display outputs for patients of a particular practitioner compared to patients serviced by a set of other practitioners.
When a practitioner selects a portion of a dashboard, the dashboard may display more detailed information. For example, a dashboard may be configured to receive requests from a practitioner for more detailed information about one or more of the practitioner's patients. In response to the request, the dashboard may display health management information for the requested one or more of the practitioner's patients.
Measurements on the dashboard may each have a narrow clinical focus. Often, the measurements may be the ratio of the population of patients for which some condition is met over the population for which the condition should be met. The gap between the eligible population and those who are meeting the goal can be used as a trigger for notifications.
As described above, real time processing engine 112 conducts processing in real time to provide timely results for individual patients. But providing real time processing of population data may be costly on computing resources. At the same time, querying the raw data at the time a practitioner navigates to the dashboard may also slow response time. For at least that reason, non-real time processing engine 114 pre join and filters data between the patient health database 132 and clinical guideline database 134 and stores the resulting population data in population management database 136. By pre joining and filtering population before reporting them to the dashboard, embodiments avoid having to include this logic in the dashboard functions themselves and reduce the count and size of the records sent.
At step 204, the health data is encoded using the quality data model (QDM). The encoded data is compared against clinical decision support (CDS) trigger criteria at step 206. As described above, these triggers may accord with clinical guidelines for that patient. When the criteria is met at decision block 208, one or more triggers are generated at step 210. The triggers may be sent to a notification to the patient or the patient's health practitioner, indicating that particular action should be taken, such as setting up an appointment with a health practitioner.
In an embodiment, method 200 is executed whenever new health data becomes available. In that way, by executing method 200 in real time, embodiments are able provide timely actionable advice, thereby improving healthcare.
In addition to the numerator, a denominator is also determined at steps 356 and 358. The denominator is the total number of data points, such as the total number patients, providers, or occurrences, for which the measurement is relevant. At step 356, the health data is evaluated to determine whether it meets certain exclusionary criteria. For example, some patients may have conditions where some data, such as their cholesterol, may not be relevant. Those patients should be removed from the data set at decision block 356. The remaining patients are summed at step 358 to create the denominator.
With the numerator and denominator determined, a ratio, or proportional measurement, is generated at step 360. This proportional measurement indicates provides a metric indicative of the population's health. At step 362, the proportional measurement is stored and made available for reporting on health practitioner's dashboard.
In this way, by periodically conducting the necessary processing to determine population data, computing performance is improved.
In addition to the physician dashboard, the patient may also have a dashboard. The patient's dashboard may only include data specific to that patient.
Each of the engines, interfaces and modules in
An example computing device is illustrated in
In an embodiment, computing device 1000 contains a combination of hardware, software, and firmware constituent parts that allow it to run an applications layer 1030. Computing device 1000, in embodiments, may be organized around a system bus 1008, but any type of infrastructure that allows the hardware infrastructure elements of computing device 1000 to communicate with and interact with each other may also be used.
Processing tasks in the embodiment of
To manipulate data in accordance with embodiments describe herein, processors 1002 access a memory 1004 via system bus 1008. Memory 1004 is nontransitory memory, such as random access memory (RAM). Memory 1004 may include one or more levels of cache. Memory 1004 has stored therein control logic (i.e., computer software) and/or data. For data that needs to be stored more permanently, processors 1002 access persistent storage 1006 via system bus 1008. Persistent storage 1006 may include, for example, a hard disk drive and/or a removable storage device or drive. A removable storage drive may be an optical storage device, a compact disc drive, flash memory, a floppy disk drive, a magnetic tape drive, tape backup device, and/or any other storage device/drive.
Processors 1002, memory 1004, and persistent storage 1006 cooperate with operating system 1020 to provide basic functionality for computing device 1000. Operating system 1020 provides support functionality for applications layer 1030.
Network connection 1010 enables computer device 1000 to communicate and interact with any combination of remote devices, remote networks, remote entities, etc. For example, network connection 1010 may allow computer device 1000 to communicate with remote devices over network 102, which may be a wired and/or wireless network, and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer device 1000 via network connection 1010.
Applications layer 1030 may house various modules and components. For example, the applications and modules in
It should be noted that computer-readable medium embodiments may include any physical medium which is capable of encoding instructions that may subsequently be used by a processor to implement methods described herein. Example physical media may include floppy discs, optical discs (e.g. CDs, mini-CDs, DVDs, HD-DVD, Blu-ray), hard drives, punch cards, tape drives, flash memory, or memory chips. However, any other type of tangible, persistent storage that can serve in the role of providing instructions to a processor may be used to store the instructions in these embodiments.
Identifiers, such as “(a),” “(b),” “(i),” “(ii),” etc., are sometimes used for different elements or steps. These identifiers are used for clarity and do not necessarily designate an order for the elements or steps.
In this detailed description, references to “one embodiment”, “an embodiment”, “an example embodiment”, etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
The present invention has been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.
The foregoing description of the specific embodiments will so fully reveal the general nature of the invention that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.
The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.