Methods and systems for displaying healthcare metrics associated with patient populations

Abstract

A server-based healthcare system includes an electronic portal configured to accept a heart failure (HF) metric from a user and an HF relationship module, operably coupled to the portal, that includes one or more processors. The HF relationship module determines relationship between the HF metric and hemodynamic data. Memory operably coupled to the one or more processors stores program instructions executable by the one or more processors to receive hemodynamic data from one patient that was acquired by an implantable medical device, store the hemodynamic data in the memory, receive the HF metric via the portal, and retrieve patient data from the memory. The patient data is associated with a sub-set of a patient population including at least two patients, and at least a portion of the patient data comprises hemodynamic data. The system includes a display to display a visualization showing a relationship between the HF metric and the patient data.

Description

METHODS AND SYSTEMS FOR DISPLAYING HEALTHCARE METRICS ASSOCIATED WITH PATIENT POPULATIONSCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to United States ProvisionalApplication No. 63 / 613,145, titled “Methods and Systems for Displaying Healthcare Metrics Associated with Patient Populations”, which was filed on December 21 , 2023, the complete subject matter of which is expressly incorporated herein by reference in its entirety.BACKGROUND

[0002] Embodiments of the present disclosure generally relate to methods and devices for displaying information associated with one or more patients.

[0003] Clinical sites employ clinic-specific, clinician-specific, and guideline directed medical therapy protocols in the care of their patients. For example, a clinical site may serve cardiac patients who have one or more implantable device, such as pulmonary arterial pressure sensors, implantable cardiac monitoring devices, pacemakers, cardioverters, cardiac rhythm management devices, defibrillators, and the like. The same or other clinics may provide patient care for patients with other health concerns, such as diabetes, kidney disease, etc.

[0004] To assess how the clinical decisions impact their patients, such as patients experiencing some level of heart failure, clinicians review data associated with a patient such as pulmonary artery pressure data trends with time-indexed notes, events, and interventions (e.g., medication changes, care instructions, messages). This process is generally regarded as being acceptable on a patient- by-patient basis; however, it is unable to address how care decisions affect multiple patients, patient populations (e.g., patients with heart failure, patients with arrhythmia), or sub-sets of patient populations (e.g., patients with heart failure whoare on a particular medication and / or regimen). The absence of such a feature eliminates a key feedback loop for clinical learning and scaling care.

[0005] Additionally, patient data privacy (PDP) requirements such as the Health Insurance Portability and Accountability Act (HIPAA) in the United States protects sensitive patient health information from being disclosed without the patient’s consent or knowledge. HIPAA thus prevents the access to and the comparison of patient data from patients outside of a particular clinic and / or healthcare network. Therefore, the majority of patient data cannot be accessed directly by clinicians, and thus patient data of particular populations cannot be compared with each other.

[0006] A need remains for a system and method that can provide meaningful feedback to clinicians for accessing care choices and their effects.SUMMARY

[0007] In accordance with embodiments herein, a server-based healthcare system comprises an electronic portal configured to accept a heart failure (HF) metric from a user and an HF relationship module operably coupled to the electronic portal. The HF relationship module comprises one or more processors and is configured to determine relationship between the HF metric and hemodynamic data. The system also includes one or more memory operably coupled to the one or more processors of the HF relationship module, wherein the memory stores program instructions, and wherein the program instructions are executable by the one or more processors to receive hemodynamic data acquired by an implantable medical device implanted in one patient, store the hemodynamic data in the one or more memory, receive the HF metric via the electronic portal, and retrieve patient data from the one or more memory, the patient data associated with a sub-set of a patient population including at least two patients, at least a portion of the patient data comprising hemodynamic data. The system alsoincludes a display configured to display a visualization showing a relationship between the HF metric and the patient data.

[0008] Optionally, the HF relationship module further comprises machine learning, the HF relationship module processing the patient data using the machine learning, the visualization further based on the processed patient data.

[0009] Optionally, the patient population includes i) all patients within a clinic, ii) a sub-set of patients within the clinic, iii) patients outside of the clinic, or iv) a sub-set of patients outside of the clinic, wherein the clinic is associated with the electronic portal.

[0010] Optionally, the HF relationship module further generates a descriptive summary based on the patient data and the HF metric, wherein the display is further configured to display the descriptive summary with the visualization.

[0011] Optionally, the one or more processors further obtains, from the one or more memory, an industry average associated with the HF metric, wherein the display is further configured to display the industry average with the visualization.

[0012] Optionally, the electronic portal is further configured to receive identification of the sub-set of the patient population from the user.

[0013] Optionally, the HF metric comprises a) gender, b) mortality, c) patient age, d) risk profile, e) admission rate, f) readmissions, g) readmissions associated with a particular protocol, h) ethnicity, i) mortality, j) risk profile, k) patient phenotype, I) heart failure patient distribution, m) patients enrolled in a particular protocol, n) patient outcomes, o) adherence trends associated with a particular protocol, or p) adherence to a protocol or regimen.

[0014] Optionally, the electronic portal is further configured to accept a second metric, wherein the visualization is further based on the second metric.

[0015] Optionally, wherein the hemodynamic data includes pulmonary arterial pressure, arterial pressure, systemic blood pressure, heart rate, blood flowmetrics, pressure related to a heart valve, or pressure related to a location in a vein or artery.

[0016] Optionally, the sub-set of the patient population comprises a first sub-set of patients assigned to a first protocol and a second sub-set of patients not assigned to the first protocol, and wherein the one or more processors are further configured to retrieve a national average associated with the HF metric, the visualization further based on the first sub-set of patients, the second sub-set of patients, and the national average.

[0017] Optionally, the HF relationship module further generates i) a monitoring recommendation, ii) a treatment recommendation, or iii) a treatment notification based on the relationship between the HF metric and the patient data, the display further configured to display i) the monitoring recommendation, ii) the treatment recommendation, or iii) the treatment notification.

[0018] Optionally, at least one of the one or more memory is a cloud-based memory.

[0019] In accordance with embodiments herein, a computer implemented method comprises, under control of one or more processors, wherein the one or more processors are configured with specific executable instructions, receiving an HF metric via an electronic portal and receiving identification associated with a patient population via the portal, the patient population comprising at least two patients. The method further comprises retrieving patient data associated with the patient population from one or more memory, the one or memory operably coupled to the one or more processors, at least a portion of the patient data comprising pulmonary arterial pressure (PAP) data acquired by an implantable sensor. The method further comprising determining a relationship between the HF metric and the PAP data, and displaying a visualization on a display, the visualization based on the relationship.

[0020] Optionally, the patient population includes i) all patients within a clinic, ii) a sub-set of patients within the clinic, iii) patients outside of the clinic, oriv) a sub-set of patients outside of the clinic, wherein the clinic is associated with the electronic portal.

[0021] Optionally, the method further comprises obtaining, from the at least one memory, an industry average associated with the HF metric, the visualization further based on the industry average.

[0022] Optionally, the method further comprises processing the patient data using artificial intelligence (Al), the relationship further based on the processed patient data.

[0023] Optionally, the one or memory is further configured to store preferences that define predetermined HF metrics and predetermined patient populations, and, in response to receiving a selection of the preferences via the electronic portal, displaying at least a second visualization on the display, the at least a second visualization based on the predetermined HF metrics and the predetermined patient populations.

[0024] Optionally, the method further comprises receiving a display format via the electronic portal, the visualization being based on the display format, the display format including a bar chart, a graph, a whisker chart, a box chart, a pie chart, or a format over time.

[0025] Optionally, the method further comprises receiving data from a patient application, wherein the visualization is further based on the data from the patient application.

[0026] Optionally, the visualization comprises i) interventions over time within a clinic, ii) interventions over time by a provider, iii) interventions over time by patient, iv) compliance trends over time, v) animated graphs that show changes in data patterns over time, vi) of number of patients, interventions, or billing reports by provider, vii) comparisons of providers within the clinic, or vii) comparisons of providers within the clinic to providers in other clinics.BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1A illustrates a clinician portal that receives input from clinicians to facilitate the visualization of customizable data views, graphics, and insights for assessing patient outcomes in accordance with embodiments herein.

[0028] Figure 1 B illustrates an example of a graphical user interface that displays a plurality of data associated with a clinic’s patients in accordance with embodiments herein.

[0029] Figure 2 illustrates a healthcare system that uses the clinician portal to facilitate the visualization of customizable data views, graphics and insights for assessing patient outcomes in accordance with embodiments herein.

[0030] Figure 3A shows a process flow for defining a visualization of selected and / or predetermined types of data in accordance with embodiments herein.

[0031] Figure 3B shows a process flow for creating a visualization based on predetermined parameters in accordance with embodiments herein.

[0032] Figures 4A-4D illustrate a plurality of visualizations based on metrics and patient population data and / or other data in accordance with embodiments herein.

[0033] Figure 5 illustrates a system that includes an IMD, an implantable sensor, and an external device implemented in accordance with embodiments herein.

[0034] Figure 6 illustrates a block diagram of portions of the system of Figure 5 formed in accordance with embodiments herein, showing components of the implantable sensor.

[0035] Figure 7 illustrates a block diagram of a system for integrating external diagnostics and the ability to determine relationships between HF metrics and data populations with remote monitoring of data, some of which is PAP data, generated by implantable medical devices in accordance with embodiments herein.

[0036] Figure 8 illustrates a healthcare system formed in accordance with embodiments herein.

[0037] Figure 9A illustrates a process flow for a server-based healthcare system configured to determine relationships and display visualizations in accordance with embodiments herein.

[0038] Figure 9B illustrates a process flow for a computer implemented method for displaying a visualization based on a relationship in accordance with embodiments herein.DETAILED DESCRIPTION

[0039] It will be readily understood that the components of the embodiments as generally described and illustrated in the Figures herein, may be arranged and designed in a wide variety of different configurations in addition to the described example embodiments. Thus, the following more detailed description of the example embodiments, as represented in the Figures, is not intended to limit the scope of the embodiments, as claimed, but is merely representative of example embodiments.

[0040] Reference throughout this specification to “one embodiment” or “an embodiment” (or the like) means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” or the like in various places throughout this specification are not necessarily all referring to the same embodiment.

[0041] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments. One skilled in the relevant art will recognize, however, that the various embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In otherinstances, well-known structures, materials, or operations are not shown or described in detail to avoid obfuscation. The following description is intended only by way of example, and simply illustrates certain example embodiments.

[0042] The methods described herein may employ structures or aspects of various embodiments (e.g., systems and / or methods) discussed herein. In various embodiments, certain operations may be omitted or added, certain operations may be combined, certain operations may be performed simultaneously, certain operations may be performed concurrently, certain operations may be split into multiple operations, certain operations may be performed in a different order, or certain operations or series of operations may be re-performed in an iterative fashion. It should be noted that, other methods may be used, in accordance with an embodiment herein. Further, wherein indicated, the methods may be fully or partially implemented by one or more processors of one or more devices or systems. While the operations of some methods may be described as performed by the processor(s) of one device, additionally, some or all of such operations may be performed by the processor(s) of another device described herein.Terms

[0043] The term “aggregate” shall be used to refer to a mathematical combination of two or more data values, signals and the like (e.g., mean, sum, average, median, normalization).

[0044] The term “metric” shall mean a quantifiable measure used to track, monitor, and / or assess a process, procedure, outcome, and / or result.

[0045] The term “insight” shall mean an assessment associated with selected metric(s), patient populations, and / or other data that provides an accurate and / or expanded understanding of the relationship between the metric(s), the patient populations, and the data. An insight provides information for assessing patient outcomes.

[0046] The term “portal” shall mean an electronic access location having the capacity to accept inputs from an external source (e.g., clinician) or softwareprogram. In some embodiments the portal is an interface to, and is operably coupled with, other software, firmware and / or hardware modules. The portal can accept inputs from a keyboard, touchscreen, software application, mouse, microphone, camera, graphical user interface, etc., and may also output data on a display of the portal or associated with the portal. The portal can be implemented as an Application (“App”) on, but not limited to, smart phones, desktop or laptop computers, tablet devices, smart TVs, fixed cameras, smart watch, digital personal assistant (DPA) devices and the like.

[0047] The terms “artificial intelligence”, “machine learning” and “deep learning” are used interchangeably throughout and shall mean an algorithm that learns from various automatic or manual inputs, such as features of interest, pressure signals such as blood pressure signals, prior device classified arrhythmias, observations and / or data. For example, the machine learning algorithm is adjusted, retrained, refined, etc., by supervised learning, unsupervised learning, and / or reinforcement learning. The machine learning algorithm is adjusted over multiple iterations based on the input data. Non-limiting examples of machine learning algorithms are a convolutional neural network (CNN), gradient boosting random forest, decision tree, K-means, deep learning, artificial neural network, and / or the like. The machine learning model may include a CNN architecture. It is recognized that the network architecture may differ and / or other types of machine learning models may be utilized. As non-limiting examples, the architecture may comprise N network layers, each with M sub-layers followed by pooling and normalization. The architecture components may include: 1 - dimensional convolutional layers (“Convl D”), rectified linear unit (“relu”) activation functions, batch normalization (“BN”), etc.

[0048] The term “analysis” shall mean a computer-implemented method that uses one or a combination of different models, techniques, statistical tools, Al algorithms, and / or machine learning. For example, at least one of the following can be used: artificial neural networks, Monte Carlo analysis techniques, aBayesian network, a statistical-based anomaly detection technique, one or more Markov models, knowledge-based techniques, neural networks, clustering and outlier detection, demographic analysis, genetic algorithms, and / or fuzzy logic techniques. In yet another example, an artificial intelligence algorithm is utilized that includes numerous variables and weights that are continuously adjusted to determine the sensor parameter.

[0049] The term “patient data privacy (PDP) requirements” and “PDP” shall mean requirements regarding management and distribution of patient data, where such requirements are defined by a government, state, sovereign entity, agency, administrative body, and the like, The PDP requirements include a plurality of protected healthcare information (PHI) and / or a plurality of personal identification information (PH). The PHI and PH may be different from one region to the next.

[0050] The term “patient data” shall mean PHI, PH, as well as data associated with a patient’s medical device, such as IMD data, PAP data, hemodynamic data, and implantable sensor data, electronic health record data, data tracking biological processes, etc.

[0051] The term “HF” shall mean heart failure.

[0052] The term “health care system” shall mean a system that includes equipment for measuring health parameters, and communication pathways from the equipment to secondary devices. The secondary devices may be at the same location as the equipment, or remote from the equipment at a different location. The communication pathways may be wired, wireless, over the air, cellular, in the cloud, etc. In one example, the healthcare system provided may be one of the systems described in U.S. published application US20210020294A1 entitled METHODS DEVICE AND SYSTEMS FOR HOLISTIC INTEGRATED HEALTHCARE PATIENT MANAGEMENT, filed July 16, 2020, the entire contents of which are incorporated in full herein in its entirety.. Other patents that describe example monitoring systems include U.S. Pat. No. 6,572,557; entitled SYSTEM AND METHOD FOR MONITORING PROGRESSION OF CARDIAC DISEASESTATE USING PHYSIOLOGIC SENSORS, filed Dec. 21 , 2000, to Tchou et al.; U.S. Pat. No. 6,480,733 entitled METHOD FORMONITORING HEART FAILURE filed Dec. 17, 1999, to Turcott; U.S. Pat. No. 7,272,443 entitled SYSTEM AND METHOD FOR PREDICTING A HEART CONDITION BASED ON IMPEDANCE VALUES USING AN IMPLANTABLE MEDICAL DEVICE, filed Dec. 14, 2004, to Min et al; U.S. Pat. No. 7,308,309 entitled DIAGNOSING CARDIAC HEALTH UTILIZING PARAMETER TREND ANALYSIS, filed Jan. 11 , 2005, to Koh; and U.S. Pat. No. 6,645,153 entitled SYSTEM AND METHOD FOR EVALUATING RISK OF MORTALITY DUE TO CONGESTIVE HEART FAILURE USING PHYSIOLOGIC SENSORS, filed Feb. 7, 2002, to Kroll et. al., the entire contents of which are incorporated in full herein in their entireties.

[0053] The term “IMD data” shall refer to any and all types of information and signals conveyed from an implantable medical device to a local or remote external device. Nonlimiting examples of IMD data include cardiac activity signals (e.g., intracardiac electrogram or IEGM signals), impedance signals (e.g., cardiac, pulmonary or transthoracic impedances), accelerometer signatures (e.g., activity signals, posture / orientation signals, heart sounds), pulmonary arterial pressure (PAP) signals, MCS rpm levels, MCS flow rates, device alerts and the like.

[0054] The terms “implantable medical device”, “IMD”, “sensor”, “implantable sensor”, “PAP sensor”, “pressure sensor”, and “Implantable medical sensor” shall mean an implantable medical device configured to be implanted within a patient to collect patient data.

[0055] The terms “clinician” and “user” shall mean medical personnel, nonlimiting examples of which include doctors, nurses, hospital or clinical staff, pharmacist, physical therapist, and any other person trained or licensed to provide medical assistance to a patient.

[0056] The term “PA” shall mean pulmonary artery. The term “PAP” shall mean pulmonary arterial pressure.

[0057] The term “pressure signal” shall refer to measured signals indicative of blood flow pressure within the body. One example is PAP that is measured within the pulmonary artery.

[0058] The term “signal” shall mean pressure signal, pulmonary signal, arterial signal, physiological signal, hemodynamic signal, periodic signal, arterial line signal, capillary blood flow signal, blood flow signal based on a sensed hemodynamic signal, and / or blood flow signal based on a sensed physiological signal.

[0059] The term “hemodynamic” shall mean any features / aspects relating to the flow of blood within the organs and tissues of the body, such as arterial pressure, PAP, systemic blood pressure, heart rate, blood flow metrics, pressures detected / measured / determined related to heart valves and / or locations in veins or arteries, cardiac output, and the like.

[0060] The term “on-demand” shall mean at any time that the system automatically determines that a measurement is warranted and without any need for patient action or intervention. As one example, an implantable sensor will collect pressure measurements “on-demand” automatically and in real-time in response to a data collection instruction from an IMD. As another example, an implantable sensor will collect pressure measurements “on-demand” automatically and in real-time in response to a data collection instruction from an external device such as a bedside monitor, smart phone, physician’s programmer and the like. As another example, an implantable sensor will collect pressure measurements “on- demand” automatically and in real-time in response to a data collection schedule stored at the sensor, IMD or external device.

[0061] The terms “processor,” “a processor”, “one or more processors” and “the processor” shall mean one or more processors. The one or more processors may be implemented by one, or by a combination of more than one implantable medical device, a wearable device, a local device, a remote device, a server computing device, a network of server computing devices and the like. The one ormore processors may be implemented at a common location or at distributed locations. The one or more processors may implement the various operations described herein in a serial or parallel manner, in a shared-resource configuration and the like.

[0062] The term “treatment notification” shall mean a communication and / or device command to be conveyed to one or more individuals and / or one or more other electronic devices, including but not limited to, network servers, workstations, laptop computers, tablet devices, smart phones, IMDs, external diagnostic test (EDT) equipment and the like. When a treatment notification is provided as a communication, the treatment notification may represent in an audio, video, vibratory or other user perceivable medium. The communication may be presented in various formats, such as to display patient information, messages, user directions and the like. The communication is presented on one or more of the various types of electronic devices described herein and may be directed to a patient, a physician, various medical personnel, various patient record management personnel and the like. The communication may represent an identification of a patient diagnosis and various treatment recommendations. The diagnosis and treatment recommendation may be provided directly to the patient. For example, in some circumstances, a diagnosis and treatment recommendation may be to modify a dosage level, in which case, the notification may be provided to the physician or medical practitioner. As another example, the diagnosis and treatment recommendation may be to begin, change or end certain physical activities, in which case, the notification may be provided to the patient, in addition to the physician or medical practitioner. As another example, the treatment notification may present an indication that a patient may or may not be a good candidate suited for implant of a ventricular assist device (e.g., LV assist device), a transplant, a valve repair procedure (e.g., a MitraClip™ valve repair to correct mitral regurgitation), a PAP pressure sensor, and the like. Other nonlimiting examples of a communication type notification include, in part or in whole, arecommendation to schedule an appointment with a physician, schedule an appointment for additional blood work, perform an additional at home point-of-care (POC) blood analysis (e.g., utilizing at home EDT equipment), recommend that the patient collect additional EDT and / or IMD data. When a notification includes an action that may be performed by a patient alone, the notification may be communicated directly to the patient.

[0063] When a treatment notification is provided as a device command, the treatment notification may represent an electronic command directing a computing device (e.g., IMD, EDT equipment, local external device, server) to perform an action. For example, the action may include directing the following:1. IMD or EDT equipment to provide additional IMD data and / or EDT data already available;2. IMD or EDT equipment to collect additional data and / or another type of data;3. IMD to deliver a therapy and / or modify a prior therapy (e.g. , a pacing therapy, neural stimulation therapy, appetite suppression therapy, drug delivery rate);4. Local external device to provide additional information regarding past and present behavior of the patient; and5. Server to analyze further information in the patient medical record and / or from another medical record.

[0064] The term “treatment recommendation” shall mean a recommendation for the patient, medical personnel and / or a device (e.g., an IMD, local external device, remote server, or body generated analyte (BGA) device) to take an action and / or maintain a current course of action. Non-limiting examples of treatment recommendations include dispatching an ambulance to the patient’s location, instructing the patient immediately go to a hospital, instructing the patient schedule an appointment, instructing the patient change a prescription, instructing the patient undergo additional examinations (e.g., diagnostic imagingexaminations, exploratory surgery and the like), instructing the patient undergo a POC test to collect new BGA data, instructing the patient take a nutritional supplement, instructing the patient start, stop or change a physical activity, or instructing the patient make no changes. The treatment recommendation may include an instruction to change, maintain, add or stop a therapy delivered by an active IMD, such as a pacing therapy, and ATP pacing therapy, a neural stimulation therapy, mechanical circulatory support and the like.

[0065] The term “monitoring recommendation” shall mean a recommendation for the patient, medical personnel and / or a device (e.g., an IMD, local external device, remote server, or BGA device) to monitor measurements of a device, a patient parameter, and / or a population parameter. Non-limiting examples of monitoring recommendations include increasing or decreasing monitoring of PAP signals, instructing a patient to provide additional data related to monitoring aspects of their health, decreasing a monitoring level associated with patients who have been stable for a period of time, increasing a monitoring level associated with patients who are not stable or who are no longer stable, and the like.System Overview

[0066] In accordance with new and unique aspects herein, methods and devices are described that facilitate the selection, processing, analysis, and display of data associated with multiple patients in a way that is meaningful to a clinician and / or clinic. A clinician can customize data views, or visualizations, to identify the metrics they are interested in along with identifying one or more patient population. The system retrieves patient data as well as other data, such as government data, electronic health record data, industry data, data collected by patient applications, and the like. The information is correlated, processed, and analyzed, such as by using machine learning, then visually displayed in a default presentation or in the visualization format selected and / or predetermined by theclinician. Therefore, data views are customized in ways that are meaningful to the clinic and / or clinician.

[0067] The embodiments herein graphically show the metrics, patient, and industry information in ways that provide additional insights, information, and / or value to the clinician in their clinical practice. Healthcare choices and their effects can be assessed to empower clinical decision making, simplify the access to meaningful data, and assist with scaling care. For example, clinicians are more able to determine when decision making is affecting a patient population, such as a sub-set of patients with particular attributes (e.g., co-morbidities, ethnicity, race, medications, protocols, implantable medical device).

[0068] According to new and unique aspects of the embodiments herein, patient data can be viewed on more than a patient specific basis. Information can be provided for patient monitoring, treatment notifications, and / or treatment recommendations that are deployed at scale for patients within a clinic or a subset of patients within the clinic. For example, clinics may have different HF subsets, depending on the type of HF. Clinicians can determine, by sub-set of a patient population for example, whether patient care is improving and / or whether other metrics important to the clinic or particular clinician are improving.

[0069] Figure 1A illustrates a clinician portal 100 that receives input from clinicians to facilitate the visualization of customizable data views, graphics, and insights for assessing patient outcomes in accordance with embodiments herein. In some embodiments, the clinician portal 100 can be a stand-alone program or module that is used within a clinical setting to view patient data in relation to selected metrics and / or other patient(s), patient populations, sub-sets of patient populations, etc. In some cases, the patient population includes i) all patients within a clinic, ii) a sub-set of patients within the clinic, iii) patients outside of the clinic, and / or iv) a sub-set of patients outside of the clinic, wherein the clinic is associated with the clinician portal 100. In some embodiments, the clinician portal 100 provides an interface to an HF relationship module as further describedherein. The clinician portal 100 can provide a graphic user interface (GUI) to accept input that is used to identify metrics and data to be aggregated, processed, and / or analyzed and then displayed in a customizable format. Although the metrics and data discussed herein are primarily associated with cardiac patients, such as patients diagnosed with heart failure (HF), it should be understood that the clinician portal 100 can equally be used to provide an interface for aggregating, processing, analyzing, and displaying information associated with patients who have other and / or additional diagnosis, such as diabetes, kidney disease, etc.

[0070] In other embodiments, the clinician portal 100 can be accessed within a larger program or platform. Figure 1 B illustrates an example of a GUI 102 that displays a plurality of data associated with a clinic’s patients in accordance with embodiments herein. The patient information data is exemplary and nonlimiting. The interface provides a plurality of tabs or menu options, such as along a top ribbon 104, although other interface options such as buttons, drop-down menus, etc., can be used. In the non-limiting example shown, a notifications tab 106, an all patients tab 108, a clinic tab 110, an HF module tab 112 (e.g., the clinician portal 100), help tab 114, and sign out tab 116 are shown. If, for example, the all patients tab 108 is selected, the GUI 102 can display a list of patients 118 who are patients of the clinic.

[0071] By way of example, the clinician portal 100 can be included within and / or communicate with a manufacturer’s new or existing platform such as, but not limited to, Merlin.net™ Patient Care Network of Abbott, located at Abbott Park, IL. The clinician portal 100 can also communicate with third party data aggregators and / or utilize third party data aggregator- 1 ike services. The clinician portal 100 can communicate with multiple data storage and data providers to provide and request de-identified patient data from other clinics and / or groups, industry data, etc. In accordance with new and unique aspects, information and data needed to display the customizable data views, graphics and insights for assessing patient outcomeson a patient-by-patient, patient population, and site-basis is accessible via the clinician portal 100.

[0072] The clinician portal 100 and a new or existing platform can be integrated together or separate from each other. Further, the clinician portal 100 and manufacturer’s platform (e.g., servers, monitors, processors, memories), such as a platform accessible via the GUI 102, can be centralized and / or distributed across multiple servers, locations, be cloud-based, etc.

[0073] Returning to Figure 1A, the clinician portal 100 can be an entry point to the information stored on the clinic’s platform and external sources, as well as provide a user interface for accepting and displaying information. The clinician portal 100 is a simple yet comprehensive panel of categories and controls for displaying and tabulating all data available to / accessible by the clinic, such as but not limited to data available in a patient management platform (e.g., Merlin.net) for the clinical site. Providers are given the ability to customize the views and data visualizations, permitting them to review metrics which are most important to them or their clinic. In accordance with new and unique aspects, the clinician portal 100 can provide a plurality of selections to facilitate easy access to customized and / or customizable information. The selections can be accessed using electronic buttons, tabs, a drop-down menu, and the like.

[0074] A clinician can select clinic preferences 120 to define the metrics, patient populations, and / or other information a particular clinic may wish to view on a regular basis, such as weekly, monthly, etc. In response to the clinic preferences 120 being selected, the clinician portal 100 can display a plurality of options from which the clinician can select. For example, the clinic preferences 120 can define what a clinic dashboard 122 is configured to display. The clinician can view the options, change the options, and / or define the options for the clinic dashboard 122.

[0075] When clinic dashboard 122 is selected, the dashboard is displayed, such as on a monitor or other display. Non-limiting examples of visualizations thatcan be included in a clinic dashboard are shown in Figures 4A-4D. Figures 4A- 4D illustrate a plurality of visualizations based on metrics and patient population data (e.g., patient data) and / or other data in accordance with embodiments herein, and will be discussed in further detail below. Although the clinic dashboard illustrates metrics such as gender, mortality, age, risk profile, and hospital admission rate, it should be understood that the clinic may select other metrics, and chose to display the metrics in different graphical manners, according to their needs, concerns, medical diagnosis, etc. Therefore, in accordance with new and unique aspects herein, the clinic dashboard can display a plurality of different data views in different visualizations and include insights for assessing patient outcomes as available.

[0076] Similarly, a clinician can select user preferences 124 to define the metrics, patient populations, etc., for their own user dashboard. When user dashboard 126 is selected, the clinician portal 100 displays the set of metrics that have been defined for display in the user dashboard. In accordance with new and unique aspects, the clinic preferences 120 and user preferences 124 can facilitate quick access to data that is of interest to one or more individuals and / or clinic, customizable based on interest, role in the clinic, patient specifics, etc. It should be understood that there can be multiple user dashboards 126 associated with different users and / or user groups.

[0077] Data view 1 128 and data view 2 130 are defined views that allow a quick selection. Data view 1 128 could be, for example, a comparison of cliniclevel metrics to national / regional data or other publicly-available or privately- available data set. Data view 2 130 could be, for example, a visualization of interventions over time within the clinic. Alternatively or optionally, data views can be defined as a visualization of interventions over time by provider, a visualization of interventions over time by patient, compliance trends over time (e.g., compliance with orders, suggestions, protocol) that can include suggestions to improve compliance, animated graphs that show changes in data patterns overtime, and visualization(s) of number of patients, interventions, billing reports, and the like by provider, wherein further comparisons can be presented across providers within the clinic, or compared to similar / anonymized / average providers in other clinics.

[0078] In some embodiments, the clinic dashboard 122 and one or more data views 128, 130 may be pre-determined in advance of the system installation within the clinic, and in some cases can be subsequently modified by the clinician.

[0079] A clinician can select a data view build module 132 to build a query to display a customizable data view. Different options for data tabulation and visualization are provided. In some embodiments, the options may be based on clinic research, market research, remote care monitoring, and / or heart failure care trends. Graph visualizations are further customizable, permitting clinicians to select which data they want to see and how they want to see it. The tabulations and visualizations can contain time elements to evaluate historical trends.

[0080] The data view build module 132 includes at least three interactive options: select HF metrics 134, select patient population(s) 136, and select display format 138. In some embodiments, selecting one of the options within select HF metrics 134, for example, may limit the number of choices available within select display format 138 and select patient populations 136. Optionally or alternatively, all options may be made available to the clinician.

[0081] Select HF metrics 134 can include many different measurable data, such as a) gender, b) mortality, c) patient age, d) risk profile, e) admission rate, f) readmissions, g) readmissions associated with a particular protocol, h) ethnicity, i) mortality, j) risk profile, k) patient phenotype, I) heart failure patient distribution, m) patients enrolled in a particular protocol, n) patient outcomes, o) adherence trends associated with a particular protocol, or p) adherence to a protocol or regimen, and the like. While the metrics herein are generally referred to as HF metrics, the metrics are not so limited. Further, the clinician can define the timespan, such as in months or years. Optionally or alternatively, the time span may default to one year, 1 .5 years, 2 years, etc.

[0082] Select patient population(s) 136 can include particular patient(s) of the clinic (e.g., one or more the patients of the clinic can be individually selected), all of the patients of the clinic, a sub-set of patients of the clinic (e.g., patients with a particular implantable medical device, patients on or not on a particular protocol, patients enrolled or not enrolled in a study, patients by gender, patients by ethnicity). In addition, patient data from outside the clinic can be accessed, such as patients in other clinic(s) (e.g., may also be selectable based on sub-set), patients in a hospital network, patient data available via government websites such as Medicare and Medicaid, industry data, national / regional data, publicly-available or privately-available datasets, electronic health record data, etc. In some embodiments, the data may be de-identified to remove patient identification specifics.

[0083] Select display format 138 can include bar charts, graphs, whisker charts, box charts, pie charts, a display format over time, number chart, line chart, bar chart, bar graph, maps gauge chart, scatter plot, tables, plots, progress chart, displayed horizontally, displayed vertically, etc. In some embodiments, not all display options may be available depending on the selected metrics.

[0084] The clinician may make multiple selections within the select HF metrics 134 and select patient population(s) 136 to identify and select the desired parameters. The clinician may then select display format 138 to customize how the information is presented to them. As discussed previously, the clinician can save data view preferences.

[0085] Figure 2 illustrates a healthcare system 200 that uses the clinician portal 100 to facilitate the visualization of customizable data views, graphics and insights for assessing patient outcomes in accordance with embodiments herein. In some embodiments the healthcare system 200 can be a server-based healthcare system 200 wherein the electronic clinician portal 100 accepts a HFmetric 134 from a user. The healthcare system 200 includes an HF relationship module 202 having an insight engine 204 (e.g., one or more processor, processing modules and / or models using artificial intelligence (Al), machine learning, and / or deep learning) and at least one memory 206. The HF relationship module 202 is operably coupled to the clinician portal 100 and determines the relationship between the HF metric and pulmonary PAP data and / or hemodynamic data. The HF relationship module 202 can be a stand-alone program or module, and / or can be part of a clinic platform 203, such as the Merlin.net™ Patient Care Network. The HF relationship module 202 can be operable within a smartphone, programmer, desktop computer, laptop, tablet, and the like, and multiple instances of the HF relationship module 202 can exist on multiple devices and / or locations. The memory 206 is operably coupled to the processors of the HF relationship module 202 and can be a data pool, data lake, a database, a hard drive, stored in a single location or distributed, located in a cloud platform, cloud-based, and the like. The memory 206 stores patient data associated with patients of the clinic as well as program instructions. For example, each patient may correspond to a record stored in a database. In addition, the memory 206 can store patient data, industry data, electronic health record data, etc., sent from outside sources, retrieved from outside sources, requested from outside sources, etc. Additionally or alternatively, the patient data from the clinic and the data from outside sources can be stored in one or more memory associated with the clinic platform 203. As discussed previously, at least some of the data can be deidentified.

[0086] The insight engine 204 uses one or more processors configured with specific executable instructions to create the customized visualization defined by the clinician. The insight engine 204 can further utilize Al such as but not limited to machine learning and deep learning to further advance both retrospective and prospective data analysis capabilities. For example, machine learning models can be trained and / or retrained to process HF data to provide retrospective data analysis and / or prospective data analysis. In some cases, the HF relationship module canprocess the patient data using machine learning, and the visualization is further based on the processed patient data. In some embodiments, the insight engine 204 may utilize patient data, and in some cases electronic health record data 208 and / or other data sources outside of the clinic and / or particular patient, to inform monitoring and treatment decisions for one or more patients. In some cases, the monitoring and treatment decisions can be based on the entirety of patient information. Additionally or alternatively, the insight engine 204 can generate treatment notifications and / or treatment recommendations automatically and / or in real-time. In other embodiments, the HF relationship module 202 may push patient information, such as HF information, information associated with HF treatment, and / or the patient’s implantable medical device, out to a patient’s electronic health record 208, patient application (App) 214, etc.

[0087] The HF relationship module 202 further receives local clinic data 210 (e.g., input by clinicians, implantable medical device data transmitted by the implantable medical device to programmers and other external devices) and remote patient data 212 as discussed previously (e.g., remote clinic data, regional data, hospital network data, industry), which are stored in the memory 206. Further, individual patient data can be received from a patient App 214 that collects patient data associated with the patient’s personal health metrics, hemodynamic data detected and / or determined by their implantable medical device(s) (e.g., PAP measurements, other arterial pressure measurements, systemic blood pressure, heart rate, blood flow metrics, pressures detected related to heart valves and / or locations in veins and / or arteries, cardiac output), medication, adherence to protocols, nutrition (e.g., fluid intake, calorie intake, diet), heart rate, systemic blood pressure readings, activity, exercise, symptoms, how the patient feels, etc., which is also stored in memory 206.

[0088] The HF relationship module 202 also receives, requests, and / or retrieves other information such as industry data 216 (e.g., industry averages such as local, regional, and / or national averages, demographic data), government data218 (e g., Medicare, Medicaid, surveys, census), and the like. In a non-limiting example, demographic information can be used to compare, for example, how a particular patient population, such as African American patients, compare to a white patient population in terms of mortality rates or sensitivity to certain medications. In accordance with new and unique aspects, electronic health records 208, industry data 216, government data 218, local clinic data 210, remote patient data 212, and / or patient App data 214 can further inform care decisions.

[0089] In some embodiments, all the data (e.g., local clinic data as well as data from outside sources) will be aggregated in the clinic platform, which may be a cloud platform, to a format that permits a plurality of different tabulations and visualizations. Based on settings and metrics selected by the clinician or preset within the HF relationship module 202, the insight engine 204 will pull the selected data, aggregate the data, analyze the data (e.g., such as with machine learning), and tabulate and visualize it for the clinic. The insight engine 204 can, for example, calculate averages, means, analyze data to provide recommendations and generate a descriptive summary of the data. For example, the HF relationship module 202 can generate a descriptive summary based on the patient data and the HF metric, and a display 220 displays the descriptive summary with the visualization.

[0090] In some embodiments, the insight engine 204 can proactively or automatically, such as in real-time, determine or generate visualizations, such that when the clinician requests data, the associated visualization is displayed in realtime or near real-time. For example, the insight engine 204 can proactively or automatically determine or generate the visualizations associated with the clinic dashboard 122, user dashboard(s) 126, and any predetermined data views 128, 130.

[0091] The HF relationship module 202 can be operably coupled with a display 220, that can be in some cases associated with the clinician portal 100. Additionally or alternatively, the HF relationship module 202 can be operablycoupled with one or more electronic output 222, such as an electronic address such e.g., an email address, texted, faxed, printed, saved to a file, output to a designated smart phone, tablet, etc. The HF relationship module 202 may use a communications circuit 224 to transmit visualization(s) to the display 220 and / or electronic output 222. The display 220 can display the visualization showing a relationship between, for example, the HF metric and the patient data. Non-limiting examples of the communications circuit 224 include capability to transmit over internet, wi-fi, a voice over IP (VoIP) gateway, a local plain old telephone service (POTS) such as a public switched telephone network (PSTN), a cellular phonebased network, satellite-based network, local area network (LAN), a campus area network (CAN), a metropolitan area network (MAN), or a wide area network (WAM).

[0092] Turning to Figure 3A, this figure shows a process flow for defining a visualization of selected and / or predetermined types data in accordance with embodiments herein. The operations of Figure 3A may be implemented by hardware, firmware, circuitry and / or one or more processors housed partially and / or entirely within a local external device, remote server or more generally within a healthcare system. For example, the external devices / systems (e.g., local, remote or anywhere within the health care system) can include memory and one or more processors. The operations of Figure 3A may be implemented by the insight engine 204, including one or more processors and artificial intelligence models. The operations may be performed in an order other than shown in Figure 3A. Figures 1 A, 2 and 3A will be discussed together.

[0093] At 300, one or more processors of the healthcare system 200 receive PAP data from at least one patient. The PAP data (e.g., patient data) can be stored in the local clinic data 210, such as in a patient record in a database. In other embodiments, the PAP data can be stored in the memory 206, retrieved by the HF relationship module 202, transmitted to the HF relationship module 202, etc. Although discussed in terms of PAP data, it should be understood that thehealthcare system 200 can receive hemodynamic data from at least one patient, such as PAP data, arterial pressure data, systemic blood pressure, heart rate, blood flow metrics, pressure data related to heart valve(s) and / or locations in veins or arteries, cardiac output, etc., store, retrieve, transmit, etc., the hemodynamic data. The process of Figure 3A applies equally to the hemodynamic data.

[0094] At 302, one or more processors receive one or more metrics, which can be an HF metric as discussed herein or a metric such as a time span. For example, the clinician portal 100 receives selected metric(s) input and / or selected by the clinician. The clinician can select the metric through any interface, such as keyboard, mouse, voice, gesture, touchscreen, etc. In some embodiments the clinician can input their selections on a clinician app (not shown), such as on a remote interface on a smart phone, tablet, or computer, that electronically interfaces with the clinician portal 100 and / or HF relationship module 202. In other cases, the selected metric can be a selection of the clinic dashboard 122, the user dashboard 126, the data view 1 128 or data view 2 130.

[0095] At 304, one or more processors receive identification associated with at least one patient population, such as of the local clinic data 210 and / or remote patient data 212. In some embodiments the patient population(s) define one or more sub-set of a population. For example, the clinician can select the patient population(s) and / or sub-set of the patient population through any interface, such as via the clinician portal 100. Additionally or alternatively, the insight engine 204 can determine or generate one or more patient population based on predetermined associations that can be stored in memory 206.

[0096] At 306, one or more processors receive display format(s) associated with at least one of the metrics. The clinician can select or otherwise identify the display format through any interface. Additionally or alternatively, the display format can be determined or generated through a predetermined association that can be stored in memory 206. As discussed herein, the visualization is formatted based on the display format.

[0097] By way of example only, in some embodiments, the clinician can select patients who have certain attributes, such as patients of the clinic with a particular type of implantable medical device (e.g., PAP sensor) and who are on a particular protocol. The clinician may wish to see how many hospitalizations the particular patient population has over the course of a year. In this example, the clinician can select hospitalizations as the metric (302), the patient population as the sub-set of the patients who both have the PAP sensor and who are on the particular protocol (304), and may select the display format (306), such as a bar chart.

[0098] In response to receiving or generating the selected parameters, at 308 one or more processors build a query based on the parameters. In some embodiments, the insight engine 204 builds the query based on the parameters.

[0099] At 310, one or more processors retrieve patient data needed to process the query. In some embodiments, the data can be retrieved from the memory 206, where it has been previously stored. In other cases, the data can be requested from outside sources if not available in the memory 206. For example, the insight engine 204 can access the memory 206, retrieve local clinic data 210 (e.g., clinic patient data, other clinic data), request remote patient data 212 (e.g., data sent by or retrieved from remote sources), request electronic health records 208, request industry data 216, request government data 218, access and / or request data uploaded by the patient app 214, etc. In some embodiments, the patient data can be associated with a sub-set of a patient population including at least two patients, and at least a portion of the patient data includes PAP data and / or hemodynamic data. In other embodiments, the one or more processors can obtain, from the one or more memory 206, an industry average associated with the HF metric that will be displayed on the display 220 with the visualization.

[0100] In response to receiving the patient data, at 312, one or more processors process, such as aggregate, tabulate, compile, analyze using Al, machine learning, deep learning, data analytics, etc., the data. In someembodiments, the insight engine 204 can use, additionally or alternatively, one or more Al methods, processes, and / or models to, for example, retrospectively and / or prospectively analyze the data.

[0101] In some embodiments, at 314, one or more processors generate a descriptive summary for the visualization(s). In some embodiments, a descriptive summary may be generated for each visualization and / or for a dashboard. In some cases, the descriptive summary may be based on a fill-in-the blank narrative format provided as a default by the clinician portal 100 or insight engine 204, or may be a customized fill-in-the blank narrative format saved by the clinician.

[0102] In some embodiments, at 316, one or more processors generate monitoring recommendations, treatment notifications, and / or treatment recommendations for one or more patients based on the relationship between the HF metric and the patient data. For example, the insight engine 204 can generate a recommendation for monitoring patients within a particular sub-set, and / or provide or generate treatment recommendations (e.g., adjustment in settings of an IMD, additional or increased monitoring, adjustment to medication and / or change to a different medication). Additionally or alternatively, the HF relationship module 202 can utilize Al, machine learning, and / or deep learning to generate one or more monitoring and / or treatment notification(s) / recommendation(s), such as by using trained models.

[0103] At 318, one or more processors format the processed data to create or generate the visualization(s) requested. The formatting can include integrating data from more than one data source into a single visualization. For example, the visualization can show a relationship between an HF metric and the patient data, and if a second metric is input, such as at 302, the visualization is further based on the second metric.

[0104] At 320, one or more processors output the visualization(s). The visualization(s) can be output to the display 220, that can be in some cases associated with the clinician portal 100. Additionally or alternatively, thevisualization(s) can be electronically output 222. The visualization(s) can include the descriptive summary, monitoring recommendation(s), treatment notifications(s), and / or treatment recommendation(s).

[0105] At 322, one or more processors can optionally save the metric(s), patient population(s), display format(s), and / or visual ization(s) to a user dashboard 126, the clinic dashboard 122, and / or data views 128, 130. The one or more processors further allow the editing of the user dashboard 126, the clinic dashboard 122, and / or data views 128, 130 such that the contents can be modified to meet the needs of clinics and clinicians. In some embodiments, the one or more processors can save data such as the descriptive summary, monitoring recommendations, treatment notifications and / or treatment recommendations in a file / database record associated with individuals of the patient population, and / or within the dashboards 122, 126 and / or data views 128, 130. By way of example, data can be saved for historical purposes or to facilitate comparisons of data over longer periods of time.

[0106] Figure 3B shows a process flow for creating or generating a visualization based on predetermined parameters (e.g., metric(s), patient population(s), display format(s)) such as those stored in the dashboard 122, 126 in accordance with embodiments herein. The operations of Figure 3B may be implemented by hardware, firmware, circuitry and / or one or more processors housed partially and / or entirely within a local external device, remote server or more generally within a healthcare system. For example, the external devices / systems (e.g., local, remote or anywhere within the health care system) can include memory and one or more processors. The operations of Figure 3B may be implemented by the insight engine 204, including one or more processors and artificial intelligence models. The operations may be performed in an order other than shown in Figure 3B.

[0107] In some embodiments, the HF relationship module 202 can be programmed to automatically generate particular visualization(s), such as atcertain times. For example, the clinic dashboard 122 may be generated on a monthly or quarterly basis and provided to various clinicians and / or groups. In other cases, clinicians can set their own data view(s) 128, 130 and or dashboards 126 to be generated at predetermined times and / or time intervals.

[0108] At 352, one or more processors of the healthcare system 200 obtain PAP data from at least one patient. The PAP data can be stored in the local clinic data 210, such as in a patient record in a database. In other embodiments, the PAP data can be stored in the memory 206, retrieved by the HF relationship module 202, transmitted to the HF relationship module 202, etc. As discussed above in 300 of Figure 3A, in some cases the healthcare system 200 can receive hemodynamic data from at least one patient, such as PAP data, arterial pressure data, systemic blood pressure, heart rate, blood flow metrics, pressure data related to heart valve(s) and / or locations in veins or arteries, cardiac output, etc.

[0109] At 354, one or more processors determine the metric(s), which may be HF metrics and / or other metrics. The metric(s) can be stored, for example, in a file associated with the clinic preferences 120, clinic dashboard 122, user preferences 124, user dashboard 126, data view 1 128, and / or data view 2 130.

[0110] At 356, one or more processors determine the patient population(s), such as from within the local clinic data 210 and / or remote patient data 212, and / or sub-set(s) of population(s) to be analyzed, such as based on data stored in the clinic preferences 120, clinic dashboard 122, user preferences 124, user dashboard 126, data view 1 128, and / or data view 2 130.

[0111] At 358, one or more processors determine display format(s) associated with the metric(s) and patient population(s), such as based on data stored in the clinic preferences 120, clinic dashboard 122, user preferences 124, user dashboard 126, data view 1 128, and / or data view 2 130.

[0112] In response to determining the parameters, at 360 one or more processors build or generate a query based on the parameters. In some embodiments, the insight engine 204 builds the query based on the parameters.

[0113] At 362, one or more processors retrieve data needed to process the query. In some embodiments, the data can be retrieved from the memory 206, where it has been previously stored. In other cases, the data can be requested from outside sources if not available in the memory 206. For example, the insight engine 204 can access the memory 206, retrieve local clinic data 210 (e.g., clinic patient data, other clinic data), request remote patient data 212 (e.g., data sent by or retrieved from remote sources), request electronic health records 208, request industry data 216, request government data 218, access and / or request data uploaded by the patient app 214, etc.

[0114] At 364, one or more processors process, such as aggregate, tabulate, compile, analyze using Al, machine learning, deep learning, data analytics, etc., the data. In some embodiments, the insight engine 204 can use, additionally or alternatively, one or more Al methods, processes, and / or models to, for example, retrospectively and / or prospectively analyze the data.

[0115] In some embodiments, at 366, one or more processors generate a descriptive summary for the visualization(s). In some embodiments, a descriptive summary may be generated for each visualization and / or for a dashboard. In some cases, the descriptive summary may be based on a fill-in-the blank narrative format provided as a default by the clinician portal 100 or insight engine 204, or may be a customized fill-in-the blank narrative format saved by the clinician.

[0116] In some embodiments, at 368, one or more processors generate monitoring recommendations, treatment notifications, and / or treatment recommendations for one or more patients. For example, the insight engine 204 can generate a recommendation for monitoring patients within a particular subset, and / or provide treatment recommendations (e.g., adjustment in settings of an IMD, additional or increased monitoring, adjustment to medication and / or change to a different medication). Additionally or alternatively, the HF relationship module 202 can utilize Al, machine learning, and / or deep learning to generate one or moremonitoring and / or treatment notification(s) / recommendation(s), such as by using trained models.

[0117] At 370, one or more processors format the processed data to create or generate the visualization(s) requested. The formatting can include integrating data from more than one data source into a single visualization.

[0118] At 372, one or more processors output the visualization(s). The visualization(s) can be output to the display 220, that can be in some cases associated with the clinician portal 100. Additionally or alternatively, the visualization(s) can be electronically output 222. The visualization(s) can include the descriptive summary, monitoring recommendation(s), treatment notifications(s), and / or treatment recommendation(s).

[0119] At 374, one or more processors can optionally save the visualization(s) to a user dashboard 126, the clinic dashboard 122, and / or data views 128, 130. In some embodiments, the one or more processors can save data such as the descriptive summary, monitoring recommendations, treatment notifications and / or treatment recommendations in a file / database record associated with individuals of the patient population, and / or within the dashboards 122, 126 and / or data views 128, 130. By way of example, data can be saved for historical purposes or to facilitate comparisons of data over longer periods of time.

[0120] Figures 4A-4D illustrate a plurality of different example visualizations in accordance with embodiments herein. The visualizations are nonlimiting, as patient data, industry data, etc., can be analyzed by the HF relationship module 202 to determine relationships between metrics, including HF metrics, and the patient data, including PAP data, to provide many other customized visualizations. In some embodiments, the plurality of visualizations in Figures 4A- 4D can be predetermined and displayed as a clinic dashboard 400 as discussed herein. The clinic dashboard 400 can display a plurality of different visualizations in different graphical manners, and include insights for assessing patient outcomes as available. In some embodiments, the clinic dashboard 400 caninclude one view, two views, or more than two views, and may be scrollable to display multiple pages of views. The clinic dashboard 400 may be configurable as to the order in which the views are displayed, size of the views, etc.

[0121] Turning first to Figure 4A, several visualizations 402a, 402b, 402c, 402d, and 402e are displayed, such as on the display 220 (Figure 2). The number of visualizations 402 displayed can be based on the size of the display screen, magnification, user preference, and the like. The HF relationship module 202 can generate a descriptive summary 404 that uses a narrative format to provide an overall summary of the HF relationships and / or other hemodynamic relationships shown in at least some of the visualizations 402, such as those of visualizations 402a-402e. In some embodiments, a selectable button 406 can provide the clinician with the ability to switch between visualizations and / or select additional visualizations, such as by selecting different metric(s), patient population(s), display format(s), etc.

[0122] The visualizations 402 can optionally include one, both or none of a title 408 and descriptive summary 410. The title 408 can be generated by the HF relationship module 202 and / or input / selected by the clinician, and is generally related to the metric(s). The descriptive summary 410 can be generated by the HF relationship module 202. Additionally, the visualizations can include treatment recommendations, treatment notifications, and / or monitoring recommendations that are generated by the HF relationship module 202.

[0123] Visualization 402a illustrates a bar chart having a title 408a of gender and descriptive summary 410a stating that “61 % of your clinic’s population reported Male, compared to the 60% national average in Heart Failure patients”. By way of example only, the clinician may use the clinician portal 100 to select “compare to national average” and “gender” as the metrics, the patients of the clinic as the patient population, and bar chart as the display format. Therefore, the visualization 402a shows a relationship between the gender of the clinic’s population compared to the national average in HF patients.

[0124] Visualization 402b illustrates a chart having the title 408b of risk profile and descriptive summary 410b of “normal-mean risk profile is very similar to comparison”. For example, the HF relationship module 202 has compared the normal-mean risk of the clinic’s population to the national average of normal-mean risk for HF patients, and indicates that the clinic is very similar to the national average.

[0125] Visualizations 402c, 402d, and 402e illustrate mortality, hospital admission rate, and patient age, respectively, in comparison with national average. Each of the visualizations 402c, 402d, 402e show a corresponding title 408c, 408d, 408e and descriptive summary 410c, 41 Od, 41 Oe. The charts of visualizations 402c and 402d can extend, for example, from zero to 100 percent along the horizontal axis, while the visualization 402e graphs number of patients along the vertical axis and years old along the horizontal axis.

[0126] Turning to Figure 4B, three visualizations 402f, 402g, and 402h are shown. The visualizations 402f-402h can be included in the clinic dashboard 400 and / or user dashboard, and / or are selectable separately, such as assigned to a data view 128, 130. Each of the visualizations 402f, 402g, 402h show a corresponding title 408f, 408g, 408h and descriptive summary 41 Of, 410g, 41 Oh. Each of the visualizations 402f-402h are shown in a different display format.

[0127] Visualization 402f illustrates a bar chart having a title 408f of patient phenotypes. In this example, the clinician can have selected patients having HFrEF (e.g., HF with reduced ejection fraction), patients having HFpEF (e.g., HF with preserved ejection fraction), or other as metrics, and the clinic population as the selected patient population.

[0128] Visualization 402g illustrates a chart showing the distribution of clinic patients and their candidacy for having an implantable medical device (IMD 500 (Figure 5) and / or implantable sensor 502 (Figure 5) such as a PAP sensor), and a particular protocol,.

[0129] Visualization 402h illustrates a line graph showing a relationship between the clinic patients with and without an implantable medical device and a particular protocol. The vertical axis indicates cost of care, while the horizonal axis indicates time in yearly quarters. Line 412 indicates a goal of care cost, which in this example has been set at $12,000 per patient. The graph shows a relationship, determined or generated by the HF relationship module 202, between the cost of care for patients who have the implantable medical device and patients who have both the implantable medical device and are on the protocol, as well as overall cost comparison of patients with the implantable medical device and patients without the implantable medical device.

[0130] With respect to Figures 4C and 4D, four visualizations 402i, 402j, 402k, and 402I are shown. The visualizations 402i— 402I can be included in the clinic dashboard 400 and / or user dashboard, and / or are selectable separately, such as assigned to a data view 128, 130. Each of the visualizations 402i, 402j, 402k, 402I show a corresponding title 408i, 408j, 408k, 408I and descriptive summary 41 Oi, 41 Oj, 410k, 4101. The visualizations 402i— 4021 are shown with a plurality of different display formats that can be predetermined and / or selected by the clinician.

[0131] Visualization 402i illustrates a line graph showing a relationship between sub-sets of a patient population of the clinic, showing the percentage of patients in each sub-set who need direct intervention on the vertical axis and time on the horizontal axis. Sub-sets can be, for example, patients who are in a maintenance phase of the protocol, patients who are in an optimization phase of the protocol, and patients who may or may not be enrolled in the protocol, but who require a higher level of intervention. The visualization 402i can show that as more patients are established in the maintenance phase of the protocol, the number of patients requiring intervention decreases. This provides the advantage of improved patient outcomes, as well as lower costs for the clinic, insurers, etc.

[0132] Visualization 402j illustrates a bar chart comparing sub-sets of patients, such as patients who are on the protocol and patients who are not on the protocol. The HR relationship module 202 has determined the relationship between hospital readmissions for the two sub-sets of patient population in relation to the national average. For example, the clinician can select, via the portal 100, hospitalizations as the metric (302), a first sub-set of the patient population as the patients who both have the PAP sensor and who are on the particular protocol and a second sub-set of the patient population as the patient who have the PAP sensor and who are not on the protocol (304), and may select the display format (306), such as a bar chart. The sub-sets can be selected from a patient population of patients of the clinic, patients at other clinics, patients within a region and / or hospital network, and the like. The HF relationship module 202 can retrieve a national average associated with the HF metric, and the visualization 402j is based on the first sub-set of patients, the second sub-set of patients, and the national average.

[0133] Visualization 402k illustrates a bar chart comparing sub-sets of patient population(s), such as patients who are on the protocol and patients who are not on the protocol. The HF relationship module 202 can determine a relationship between repeat events from one period to the next.

[0134] Visualization 402I illustrates a chart that indicates how many patients, within the last 30 days, were compliant with the protocol. For example, if the protocol pushes requests to the patient to take an action (e.g., take a measurement, adjust a medication), the HF relationship module 202 can determine a relationship between how many of the patients adhered to the protocol. This provides the advantage of helping to determine whether current protocols are working or not working, depending upon whether the patient is compliant with the protocol. Other types of protocols can be monitored.

[0135] Figure 5 illustrates a system 501 that includes an IMD 500, an implantable sensor 502, and an external device (ED) 504 implemented inaccordance with embodiments herein. The IMD 500 and the implantable sensor 502 are implanted within the body of a patient. The ED 504 is outside of the patient body. The ED 504 may be a programmer, an external defibrillator, a workstation, a portable computer (e.g., laptop or tablet computer), a personal digital assistant, a cell phone (e.g., smartphone), a bedside monitor, and the like. The IMD 500 may represent a cardiac monitoring device, a pacemaker, a cardioverter, a cardiac rhythm management device, a defibrillator, a neurostimulator, a leadless monitoring device, a leadless pacemaker, and the like, implemented in accordance with one embodiment of the present invention. The IMD 500 may be a dual-chamber stimulation device capable of treating both fast and slow arrhythmias with stimulation therapy, including cardioversion, defibrillation, antitachycardia pacing and pacing stimulation, as well as capable of detecting heart failure, evaluating its severity, tracking the progression thereof, and controlling the delivery of therapy and warnings in response thereto.

[0136] The IMD 500 includes a housing 506 that is joined to a header assembly 508 that holds receptacle connectors connected to a right ventricular lead 530 and an atrial lead 520, respectively. The atrial lead 520 includes a tip electrode 522 and a ring electrode 523. The right ventricular lead 530 includes an RV tip electrode 532, an RV ring electrode 534, an RV coil electrode 536, and an SVC coil electrode 538. The leads 520 and 530 detect intracardiac electrogram (IEGM) signals that are processed and analyzed as described herein, and also deliver therapies as described herein.

[0137] The IMD 500 may be implemented as a full-function biventricular pacemaker, equipped with both atrial and ventricular sensing and pacing circuitry forfour chamber sensing and stimulation therapy (including both pacing and shock treatment). Optionally, the IMD 500 may further include a coronary sinus lead with left ventricular electrodes. The IMD 500 may provide full-function cardiac resynchronization therapy. Alternatively, the IMD 500 may be implemented with areduced set of functions and components. For instance, the IMD 500 may be implemented without ventricular sensing and pacing.

[0138] The implantable sensor 502 is configured to be implanted at a location remote from the electrodes of the leads 520 and 530. The implantable sensor 502 may be implanted in a blood vessel, such as an artery or vein. In an embodiment, the sensor 502 is implanted within the pulmonary artery (PA). The sensor 502 may be anchored to the vessel wall of a blood vessel using one or more expandable loop wires. The diameter of each loop should be larger than the diameter of target blood vessel in order to provide adequate anchoring force. Optionally, instead of the loop wire, the sensor 502 may be attached to the end of a self-expandable stent and deployed into the blood vessel through a minimally invasive method. This method may be preferable over the loop wire(s) in situations in which strong anchoring is needed.

[0139] Alternatively, the implantable sensor 502 may be secured to tissue outside of blood vessels. The sensor 502 may be secured in place by using a fixation screw (e.g., helix) attached to the housing. The screw may anchor the sensor 502 to patient heart tissue, such as cardiac tissue of the left or right ventricle. The sensor 502 is configured to sense a physiologic parameter of interest (PPOI) and to generate signals indicative of the PPOI. In a non-limiting example, when the sensor 502 is disposed within the PA, the sensor 502 may sense, as the PPOI, blood pressure.

[0140] Figure 6 illustrates a block diagram of portions of the system 501 formed in accordance with embodiments herein, showing components of the implantable sensor 502. The sensor 502 comprises a sensing circuit 552, a controller 554, an optional power source 556, a communications circuit 558 and a memory 560. The controller 554 includes one or more processors 555. The one or more processors 555 are operably coupled to the memory 560. The sensor 502 includes a housing 551 that holds and encapsulates the sensing circuit 552, the controller 554, the power source 556, the communications circuit 558, and thememory 560, to protect these components from the harsh organic environment of the body. The housing 551 may be hermetically sealed.

[0141] The sensing circuit 552 is configured to sense a physiologic parameter of interest (PPOI) and to generate signals indicative of the PPOI. The sensing circuit 552 is configured to sense, as the PPOI, at least one of pressure (e.g., blood pressure), cardiac output, temperature, respiration, or a body generated analyte (BGA) (e.g., blood glucose level). The signals generated by the sensing circuit 552 represent electrical signals. Electrical parameters of the signals, such as voltage, current, capacitance, inductance or resistance, may vary based on a level of the PPOI. The sensing circuit 552 includes one or more sensing elements that sense the PPOI and circuitry that generates the electrical signals indicative of the PPOI.

[0142] The controller 554 may be implemented as a microcontroller unit or another processor configuration. The controller 554 performs at least some of the operations described herein to collect real-time on-demand measurements by generating physiologic data and communicating the physiologic data to at least a second device, without requiring patient interaction or external energy delivery at the time of data generation and communication. The controller 554 represents hardware circuitry that includes and / or is connected with the one or more processors 555 (e.g., one or more microprocessors, integrated circuits, field programmable gate arrays, etc.).

[0143] The controller 554 includes and / or is connected with the memory 560, which is a tangible and non-transitory computer-readable storage medium. The memory 560 stores program instructions (e.g., software) that is executed by the one or more processors 555 to perform the operations of the sensor 502 described herein. The memory 560 additionally may store different information, such as the physiologic data that is generated by the sensing circuit 552. The memory 560 may store the physiologic data until the sensor 502 transmits the physiologic data to the IMD 500 and / or the ED 504.

[0144] In an embodiment, the controller 554 includes and / or is connected with an internal clock 553 or timer. The clock 553 may be used to cycle the sensor 502 between wake and sleep modes to conserve electrical energy. The controller 554 may refer to the clock 553 to determine when to activate the sensing circuit 552 to generate the signals indicative of the PPOI according to a data collection schedule. For example, if the data collection schedule in the memory 560 indicates that new physiologic data should be generated at a specific time (e.g., 6 AM) of the current day, then the controller 554 can utilize the clock 553 to determine when it is the specific time to activate the sensing circuit 552 according to the schedule, such that the physiologic data is generated and collected in real-time at specific prescribed times.

[0145] The communications circuit 558 is operably connected to the controller 554 via conductive elements. The communications circuit 558 communicates with the IMD 500 and / or the ED 504. The communications circuit 558 may be communicatively connected to the IMD 500 via an intra-body bidirectional link, which enables the sensor 502 to transmit information (e.g., data) to the IMD 500 and receive information from the IMD 500. The communications circuit 558 may include an RF module 557 and / or a conductive communication module 559. The RF module 557 includes an antenna for sending and receiving RF signals. The conductive communication module 559 includes at least two spaced-apart electrodes, connected via a conductive wire or cable, that are powered to create a polarized electric field around the sensor 502.

[0146] The optional power source 556 supplies electrical energy to power the operations of the sensor 502. The power source 556 may include one or more secondary (e.g., rechargeable) batteries, one or more primary batteries, one or more capacitors, and / or associated circuitry, such as inductive coils, charging circuits, and the like. In some embodiments the sensor 502 can be powered by an external device. Upon being powered, the sensor 502 detects physiologicalsignals, levels, etc., and transmits the information to the external device and / or another IMD.

[0147] In operation, the controller 554 may directly convert, or manage conversion of, the signals from the sensing circuit 552 to digital physiologic data. The controller 554 may execute the program instructions stored in the memory 560 to activate the sensing circuit to generate the signals indicative of the PPOI. The controller 554 may activate the sensing circuit 552 on-demand in response to receiving a request (e.g., a data collection instruction) from another device or at a prescribed time according to a schedule stored in the memory 560. The controller 554 also executes the program instructions to convert the signals from the sensing circuit 552 to physiologic data indicative of the PPOI. After converting, the controller 554 stores the physiologic data in the memory 560. In an embodiment, the controller 554 (e.g., the one or more processors 555 thereof) are configured to digitize the signals generated by the sensing circuit to form the physiologic data.

[0148] The controller 554 then directs the communications circuit 558 to transmit at least some of the physiologic data stored in the memory 560 to the IMD 500 and / or the ED 504. For example, the memory 560 may store the physiologic data that is recently converted and digitized until the controller 554 directs the communications circuit 558 to transmit the physiologic data. The communications circuit 558 may be directed to transmit the data in real-time in accordance with a predetermined schedule or on-demand in response to a request from at least one of the IMD 500 or the ED 504. For example, the transmission may be triggered by a stimulus, which may be a determination that it is time for a scheduled data transmission, a receipt of an impromptu, on-demand request from the IMD 500 and / or the ED 504, a determination by the controller 554 that the PPOI has crossed a threshold value or has changed more than a threshold rate or extent, or the like. The communications of the physiologic data may be controlled according to a predetermined schedule, a request, and / or a detected exceptional value or trend in the measured PPOI.

[0149] In an embodiment, the IMD 500 is utilized as a bridge component to relay communications between the sensor 502 and the ED 504. For example, the controller 554 may use the communication circuit 558 to transmit a message within the body of the patient to the IMD 500. Upon receipt, the IMD 500 may retransmit the message (or generate a new message that includes the content of the received message) to the ED 504. The IMD 500 may also relay messages received from the ED 504 to the sensor 502. Optionally, the sensor 502 may have sufficient onboard power and / or receive external power to communicate information to the ED 504 and / or receive information from the ED 504 without utilizing the IMD 500 as a relay.

[0150] In an embodiment for pressure sensors, the ED 504 includes an atmospheric pressure gauge that monitors atmospheric pressure either periodically or on-demand. The sensor 502 produces pressure data along with a time stamp, or time synchronized relative to ED 504 or IMD 500. The on-demand or time-stamped atmospheric pressure measurement of ED 504 can be used to convert time-stamped or time synchronized absolute blood pressure measured by the sensor 502 to relative blood pressure, upon time-synchronization between the sensor 502 and the ED 504. For example, to help with time-synchronization, the ED 504 can instruct the sensor 502 or IMD 500 to collect the pressure data when the patient is near-by the ED 504. In another example, the pressure measurement time of sensor 502 and ED 504 can be pre-scheduled relative to the sleep schedule of the patient (e.g., 3 AM), to reduce the variability of blood pressure measurements attributable to changes in patient posture.

[0151] In accordance with embodiments described herein, the intra-body communication between the sensor 502 and the IMD 500 provides various benefits. For example, the PPOI is measured by the sensor 502 and the physiologic data is transferred to the IMD 500. The IMD 500 may provide a treatment for the patient. When the IMD 500 is a CRT / pacemaker, the treatment may be stimulation therapy. When the IMD 500 is an implantable glucosedispenser, the treatment may be a dose of insulin. Communication between the IMD 500 and the sensor 502 enables autonomous and prompt adjustment of treatment parameters based on real-time feedback from the PPOI. For example, in response to a change in the PPOI, the system 501 enables quicker modification of the treatment parameters provided by the IMD 500 than a conventional system that requires the patient to periodically activate the sensor 502 via an external energy source. The earlier adoption of a modified treatment improves patient outcome because the treatment is tailored and timely for the current patient conditions.

[0152] The IMD 500 is able to modify the treatment parameters in real-time or near real-time, relative to the conventional system that requires operator- involved sensor activation to collect a measurement, because the sensor 502 may autonomously collect and communicate updated, real-time physiologic data. The data collection and communication may occur more often and / or with less delay after a change in the PPOI than relying on patient interaction to activate the sensor. For example, the sensor 502 may collect measurements and transmit the physiologic data on a schedule that is more reliable and / or more frequent than schedules that rely on patient involvement. Furthermore, the treatment parameters may be quickly modified because the sensor 502 can autonomously provide on- demand updates to the IMD 500 and / or ED 504. Thus, instead of requiring the ED 504 or another device to prompt the patient or another person to activate the sensor for acquiring an updated measurement, the IMD 500 and / or ED 504 can simply communicate a request or instruction to the sensor 502 whenever the requesting device desires updated physiologic data, and the sensor 502 responds with a real-time update. Optionally, the sensor 502 may also provide unsolicited and unscheduled updates to the IMD 500 and / or ED 504 in certain situations. For example, the sensor 502 may collect and store data measurements at a greater frequency than the data is typically transmitted to the IMD 500 and / or ED 504. Optionally, the controller 554 may monitor the PPOI overtime and determine whena value of the PPOI crosses a designated threshold and / or changes at a rate or extent that is outside of an expected rate or extent of change. In response to making this determination, the sensor 502 may notify the IMD 500 and / or ED 504, even if the notification occurs outside of a scheduled communication session and is not prompted by a received request for updated physiologic data, and provides the IMD 500 and / or the ED 504 early access to information that could require a medical response, thereby improving the patient outcome.

[0153] The intra-body communication also overcomes difficulties with prior implantable sensors, the size of which was limited due to the target implant locations, such as blood vessels. The size constraints limited the size of the batteries and other energy sources onboard the sensor, which also limits the energy storage capability. The limited energy storage in prior sensors limited the operational lifespan of the sensors (at least between charging sessions), and also limited the distance that the sensor could communicate, which created problems for direct communication to the external device such as a bedside monitoring device. In accordance with at least some embodiments herein, these issues can be addressed by energy conservation and the use of the IMD 500 as a bridge or relay communication device between the sensor 502 and the ED 504. For example, the physiologic data from the sensor 502 is sent to the IMD 500, which has an established communication link with the ED 504. The implantable sensor 502 according to embodiments herein is implemented in a small form factor to retain the ability to implant the sensor 502 in narrow locations, such as blood vessels. The sensor 502 can increase reliability and consistency of physiologic data collection by autonomously collecting physiologic data, independent of patient interaction, which promotes a better patient outcome.

[0154] Figure 7 illustrates a block diagram of a system 700 for integrating external diagnostics and the ability to determine relationships between HF metrics and data populations with remote monitoring of data, some of which is PAP data, generated by implantable medical devices in accordance with embodimentsherein. The system 700 may be implemented with various architectures that are collectively referred to as a distributed healthcare system 720. The healthcare system 720 may be implemented with the implantable sensor 502 described according to the embodiments herein. The healthcare system 720 is configured to receive data from a variety of external and implantable sources including, but not limited to, active IMDs 500 capable of delivering therapy to a patient, the implantable sensor 502, BGA test devices 706, wearable sensors 708, and point- of-care (POC) devices 710 (e.g., at home and / or at a medical facility). Optionally, a POC device 710 may represent one type of BGA test device 706.

[0155] The data from one or more of the external and / or implantable sources is collected and transmitted to one or more secure databases within the healthcare system 720. Optionally, the patient and / or other users may utilize a patient data entry (PDE) device, such as a smart phone, tablet device, etc., to enter behavior related medical (BRM) data, such as into the patient App 214. For example, a patient may use a smart phone to provide feedback concerning activities performed by the patient, a patient diet, nutritional supplements and / or medications taken by the patient, how a patient is feeling (e.g., tired, dizzy, weak, good), etc.

[0156] For example, the external BGA test device 706 may collect lab test results for specific tests and then transmit the lab test results to the healthcare system 720. The BGA test device 706 may measure and / or sense one or more body generated analytes (e.g., blood glucose, oxygen). For example, a cartridge based BGA test device may be configured to test patient levels for one or more body generated analytes. The BGA test device 706 may be implemented at a variety of physical locations, such as one or more “core” laboratories, a physician’s office, ER (emergency room), OR (operating room) and / or a medical facility POC (e.g., during hospitalizations or routine healthcare visits). Optionally, the BGA test device 706 may be implemented as a fully implantable “lab on a chip”, such as an implantable biosensor array, that is configured to collect lab test results.

[0157] The at-home POC device 710 may periodically or continuously monitor the BGA (e.g., blood glucose) measured by the BGA test device 706. The at-home POC device 710 may transmit the raw BGA data to the medical network (e.g., a local external device and / or remote server). Additionally or alternatively, the at-home POC device 710 may analyze the BGA data and / or perform a test of the BGA data for a characteristic of interest (COI) such as a malnutrition state COI, an electrolyte COI, a cardiac marker COI, a hematology COI, a blood gas COI, a coagulation COI, an endocrinology COI. The POC device 710 transmits the COI (and optionally the BGA data) to the healthcare system 720 as the tests are performed at home or elsewhere. The POC device 710 may implement periodic or continuous tests for glucose levels, such as through sensors and handheld devices offered under the trademark FREESTYLE LIBRE® by Abbott Laboratories.

[0158] In an embodiment, the components of the system 700 may be independently powered and capable of communicating with each other. For example, the sensor 502 can communicate physiologic data to the IMD 500, the BGA test device 706, the wearable sensor 708, and / or the POC devices 710. Measurements by the sensor 502 may be synchronized with measurements by the IMD 500, the BGA test device 706, and / or the wearable sensor 708. The synchronized measurements may be transmitted to a common device, such as a POC device 710 or a PDE device, to enable real-time, on-demand analysis of multiple different physiologic conditions in combination. For example, up-to-date blood glucose data may be analyzed with up-to-date blood pressure data or PAP data from the sensor 502 to enable more timely treatment modifications based on measured changes in physiologic condition of the patient.

[0159] The patient data collected by any of the various devices discussed herein can be transmitted to the memory 206 of the HF relationship module 202. Optionally or alternatively, the HF relationship module 202 can request the patientdata. The HF relationship module 202 generates a relationship between an HF metric and the patient data that can be displayed on a display.

[0160] Figure 8 illustrates a healthcare system 800 formed in accordance with embodiments herein. The healthcare system 800 includes one or more remote servers 802, each of which is connected to one or more database 804. The servers 802 and databases 804 may be located at a common physical location and / or distributed between multiple remote locations within a city, state, country or worldwide. The servers 802 communicate with at least one network 812. The network 812 may be the internet, a voice over IP (VoIP) gateway, a local plain old telephone service (POTS) such as a public switched telephone network (PSTN), a cellular phone-based network, satellite-based, and the like. Alternatively, the network 812 may be a local area network (LAN), a campus area network (CAN), a metropolitan area network (MAN), or a wide area network (WAM). The network 812 facilitates the transfer / receipt of information and patient data such as IMD data, sensor physiologic data, and BGA data.

[0161] The system 800 also includes one or more IMDs 500, one or more implantable medical sensors 502, one or more local external devices 504, one or more BGA test devices 830, one or more PDE devices 831 , and one or more medical personnel (MP) devices 832, all of which communicate (directly or indirectly) through the network 812 to the servers 802 and / or one another. The servers and devices described herein may wirelessly communicate with one another utilizing various protocols, such as Bluetooth, GSM, infrared wireless LANs, HIPERLAN, 3G, satellite, as well as circuit and packet data protocols, and the like. Alternatively, a hard-wired connection may be used to connect the servers and devices.

[0162] The IMD 500 may be the IMD 500 described in embodiments herein. The sensor 502 may be the sensor 502 described in embodiments herein. The IMD 500 may collect various types of data, such as cardiac electrical and / or mechanical activity data, PAP or other pressure related data, impedance data,flow data, and the like. The sensor 502 may measure a PPOI, such as blood pressure, PAP, temperature, respiration, capacitance, resistance, etc. The BGA test device 830 may analyze various types of body generated analytes to derive the BGA data. The PDE device 831 collects BRM data, such as based on manual inputs from a patient or other user, and / or based on automatic video and / or audio monitoring.

[0163] The local ED 504 may be implemented as a variety of devices including, but not limited to, medical personnel programmer, a local RF transceiver and a user workstation, smart phone, tablet device, laptop computer, desktop computer and the like. The MP devices 832 may also be implemented as a variety of devices including, but not limited to, medical personnel programmer, workstation, smart phone, tablet device, laptop computer, desktop computer and the like. Functionality of the MP devices 832 related to embodiments herein may be implemented through dedicated hardware circuits, firmware, software, and / or application operating on one or more computing devices. The MP devices 832 may include a cell phone 814, a tablet device 815, a laptop 816, and / or the like.

[0164] The server 802 is a computer system that provides services to other computing systems over a computer network. The servers 802 control the communication of information including IMD data, sensor data, patient entered data, medical record information and BGA. The servers 802 interface with the network 812 to transfer information between the servers 802, databases 804, local external devices 504, medical personnel devices 832 for storage, retrieval, data collection, data analysis, diagnosis, treatment recommendations and the like. The databases 804 can store all or various portions of the information described herein, including, but not limited to, PAP data, hemodynamic data, IMD data, sensor physiologic data, BGA data, BRM data, patient data, medical record information, treatment diagnoses and recommendations, clinic dashboard 122, clinic preferences 120, user dashboard 126, user preferences 124, data view 1 128,data view 2 130, other data associated with the HF relationship module 202, and the like.

[0165] The local ED 504 may reside in a patient’s home, a hospital, or a physician’s office. The local ED 504 communicates wired or wirelessly with the IMDs 500, the sensors 502, and / or BGA test devices 830. The local ED 504, when implemented as a programmer, may be configured to acquire cardiac signals from the surface of a person (e.g., ECGs), and / or intra-cardiac electrogram (e.g., IEGM) signals from the IMD 500. The local ED 504 interfaces with the network 812 to upload the data and other information to the server 802.

[0166] Any of the MP devices 832 may interface with the network 812 to download various data, information, diagnoses and treatment recommendations, patient data, government data, electronic health records industry data, from the database 804, as well as receive data from the patient App 214. The HF relationship module 202 can be stored on or accessed from any of the MP devices 832. Further, the clinician portal 100 (Figure 1 ) can operate on any of the MP devices 832, accepting input from a user and displaying visualizations.

[0167] The distributed “digital” healthcare system collects various types of data and enables the data to be analyzed by the HF relationship module 202 operating via various computing devices within the system. The data is deidentified so that it can be processed and viewed while in compliance with HIIPA. The system determines one or more treatment diagnosis and treatment recommendation substantially in real-time with the analysis and / or determining of relationships between the data, such as the HF metric(s) and patient data, such as PAP data and / or hemodynamic data. In this manner, unneeded and undesired hospitalizations may be avoided through preventative detection over a population, reducing costs associated with emergency medical procedures. Additionally, such a system also assists in prolonging a human’s life and improves patient care. Thus, an improved system and methodology are provided.

[0168] In accordance with new and unique aspects herein, methods and systems are described to determine relationships between metrics and patient data associated with populations, providing visual representations as well as descriptive summaries. The embodiments herein are an improvement to the technology of implantable cardiac devices (e.g., IMD 500, sensor 502), and in particular, to implantable cardiac devices in the field of heart failure monitoring. The clinician uses the visualizations, which can provide insights based on the entirety of patient information, to prescribe / change the patients’ therapy (e.g., prescribe new medication, change medication, change diet, recommend physical therapy, recommend to implant IMD, change programmed parameters of IMD already implanted). Further, machine learning models and other Al can be trained and / or utilized to provide both retrospective and prospective data analysis capabilities for populations of patients.

[0169] Figure 9A illustrates a process flow for a server-based healthcare system configured to determine relationships and display visualizations in accordance with embodiments herein. The operations of Figure 9A may be implemented by hardware, firmware, circuitry and / or one or more processors housed partially and / or entirely within a local external device, remote server or more generally within a healthcare system. For example, the external devices / systems (e.g., local, remote or anywhere within the health care system) can include memory and one or more processors. The operations of Figure 9A may be implemented by the insight engine 204, including one or more processors and artificial intelligence models. The operations may be performed in an order other than shown in Figure 9A.

[0170] In some embodiments, an electronic portal is configured to accept a heart failure (HF) metric from a user. An HF relationship module is operably coupled to the electronic portal, the HF relationship module comprising one or more processors, the HF relationship module configured to determine relationship between the HF metric and hemodynamic data. One or more memory is operablycoupled to the one or more processors of the HF relationship module, wherein the memory stores program instructions that are executable by the one or more processors.

[0171] At 902, one or more processors receive hemodynamic data acquired by an implantable medical device implanted in one patient.

[0172] At 904, one or more processors store the hemodynamic data in the one or more memory.

[0173] At 906, one or more processors receive the HF metric via the electronic portal.

[0174] At 908, one or more processors retrieve patient data from the one or more memory, the patient data associated with a sub-set of a patient population including at least two patients, at least a portion of the patient data comprising hemodynamic data.

[0175] At 910, a display displays a visualization showing a relationship between the HF metric and the patient data.

[0176] Figure 9B illustrates a process flow for a computer implemented method for displaying a visualization based on a relationship in accordance with embodiments herein. The operations of Figure 9B may be implemented by hardware, firmware, circuitry and / or one or more processors housed partially and / or entirely within a local external device, remote server or more generally within a healthcare system. For example, the external devices / systems (e.g., local, remote or anywhere within the health care system) can include memory and one or more processors. The operations of Figure 9B may be implemented by the insight engine 204, including one or more processors and artificial intelligence models. The operations may be performed in an order other than shown in Figure 9A.

[0177] At 950, one or more processors receive an HF metric via an electronic portal.

[0178] At 952, one or more processors receive identification associated with a patient population via the portal, the patient population comprising at least two patients.

[0179] At 954, one or more processors retrieving patient data associated with the patient population from one or more memory, the one or memory operably coupled to the one or more processors, at least a portion of the patient data comprising pulmonary arterial pressure (PAP) data acquired by an implantable sensor.

[0180] At 956, one or more processors determine a relationship between the HF metric and the PAP data.

[0181] At 958, one or more processors display a visualization on a display, the visualization based on the relationship.

[0182] Example 1. A server-based healthcare system, comprising an electronic portal configured to accept a heart failure (HF) metric from a user and an HF relationship module operably coupled to the electronic portal, the HF relationship module comprising one or more processors, the HF relationship module configured to determine relationship between the HF metric and hemodynamic data. The system further comprises one or more memory operably coupled to the one or more processors of the HF relationship module, wherein the memory stores program instructions, wherein the program instructions are executable by the one or more processors to: receive hemodynamic data acquired by an implantable medical device implanted in one patient; store the hemodynamic data in the one or more memory; receive the HF metric via the electronic portal; and retrieve patient data from the one or more memory, the patient data associated with a sub-set of a patient population including at least two patients, at least a portion of the patient data comprising hemodynamic data. The system further comprises a display configured to display a visualization showing a relationship between the HF metric and the patient data.

[0183] Example 2. The system of example 1 , the HF relationship module further comprising machine learning, the HF relationship module processing the patient data using the machine learning, the visualization further based on the processed patient data.

[0184] Example 3, The system of examples 1 or 2, wherein the patient population includes i) all patients within a clinic, ii) a sub-set of patients within the clinic, iii) patients outside of the clinic, or iv) a sub-set of patients outside of the clinic, wherein the clinic is associated with the electronic portal.

[0185] Example 4. The system of any one of examples 1 to 3, wherein the HF relationship module further generates a descriptive summary based on the patient data and the HF metric, wherein the display is further configured to display the descriptive summary with the visualization.

[0186] Example 5. The system of any one of examples 1 to 4, wherein the one or more processors further obtains, from the one or more memory, an industry average associated with the HF metric, wherein the display is further configured to display the industry average with the visualization.

[0187] Example 6. The system of any one of examples 1 to 5, wherein the electronic portal is further configured to receive identification of the sub-set of the patient population from the user.

[0188] Example 7. The system of any one of examples 1 to 6, wherein the HF metric comprises a) gender, b) mortality, c) patient age, d) risk profile, e) admission rate, f) readmissions, g) readmissions associated with a particular protocol, h) ethnicity, i) mortality, j) risk profile, k) patient phenotype, I) heart failure patient distribution, m) patients enrolled in a particular protocol, n) patient outcomes, o) adherence trends associated with a particular protocol, or p) adherence to a protocol or regimen.

[0189] Example 8. The system of any one of examples 1 to 7, wherein the electronic portal is further configured to accept a second metric, wherein the visualization is further based on the second metric.

[0190] Example 9. The system of any one of examples 1 to 8, wherein the hemodynamic data includes pulmonary arterial pressure, arterial pressure, systemic blood pressure, heart rate, blood flow metrics, pressure related to a heart valve, or pressure related to a location in a vein or artery.

[0191] Example 10. The system of any one of examples 1 to 9, wherein the sub-set of the patient population comprises a first sub-set of patients assigned to a first protocol and a second sub-set of patients not assigned to the first protocol, wherein the one or more processors are further configured to retrieve a national average associated with the HF metric, the visualization further based on the first sub-set of patients, the second sub-set of patients, and the national average.

[0192] Example 11. The system of any one of examples 1 to 10, wherein the HF relationship module further generates i) a monitoring recommendation, ii) a treatment recommendation, or iii) a treatment notification based on the relationship between the HF metric and the patient data, the display further configured to display i) the monitoring recommendation, ii) the treatment recommendation, or iii) the treatment notification.

[0193] Example 12. The system of any one of examples 1 to 11 , wherein at least one of the one or more memory is a cloud-based memory.

[0194] Example 13. A computer implemented method, comprising, under control of one or more processors, wherein the one or more processors are configured with specific executable instructions, receiving an HF metric via an electronic portal; receiving identification associated with a patient population via the portal, the patient population comprising at least two patients; retrieving patient data associated with the patient population from one or more memory, the one or memory operably coupled to the one or more processors, at least a portion of the patient data comprising pulmonary arterial pressure (PAP) data acquired by an implantable sensor; determining a relationship between the HF metric and the PAP data; and displaying a visualization on a display, the visualization based on the relationship.

[0195] Example 14. The method of example 13, wherein the patient population includes i) all patients within a clinic, ii) a sub-set of patients within the clinic, iii) patients outside of the clinic, or iv) a sub-set of patients outside of the clinic, wherein the clinic is associated with the electronic portal.

[0196] Example 15. The method of examples 13 or 14, further comprising obtaining, from the at least one memory, an industry average associated with the HF metric, the visualization further based on the industry average.

[0197] Example 16. The method of any one of examples 13 to 15, further comprising processing the patient data using artificial intelligence (Al), the relationship further based on the processed patient data.

[0198] Example 17. The method of any one of examples 13 to 16, wherein the one or memory is further configured to store preferences that define predetermined HF metrics and predetermined patient populations, and, in response to receiving a selection of the preferences via the electronic portal, displaying at least a second visualization on the display, the at least a second visualization based on the predetermined HF metrics and the predetermined patient populations.

[0199] Example 18. The method of any one of examples 13 to 17, further comprising receiving a display format via the electronic portal, the visualization being based on the display format, the display format including a bar chart, a graph, a whisker chart, a box chart, a pie chart, or a format over time.

[0200] Example 19. The method of any one of examples 13 to18, further comprising receiving data from a patient application, wherein the visualization is further based on the data from the patient application.

[0201] Example 20. The method of any one of examples 13 to 19, wherein the visualization comprises i) interventions over time within a clinic, ii) interventions over time by a provider, iii) interventions over time by patient, iv) compliance trends over time, v) animated graphs that show changes in data patterns over time, vi) of number of patients, interventions, or billing reports by provider, vii) comparisonsof providers within the clinic, or vii) comparisons of providers within the clinic to providers in other clinics.

[0202] Embodiments may be implemented utilizing all or portions of the methods and systems described in U.S. Patent Application 20220117538, filed June 8, 2021 , entitled “Methods and systems to confirm device classified arrhythmias utilizing machine learning models”, U.S. Patent Application 20220304612, filed December 17, 2023, entitled “Methods and systems for predicting arrhythmia risk utilizing machine learning models”, and U.S. Patent Application serial no. 63 / 515,359, filed July 25, 2023, filed as U.S. Patent Application serial no. 18 / 748,167, filed June 20, 2024, entitled “Convolutional Neural Network for Automatic Discrimination of Pause Episodes Detected by an Implantable Medical Device”, which are hereby incorporated by reference in their entireties.

[0203] The implantable sensor disclosed herein may implement one or more structural and / or functional aspects of the device(s) described in U.S. patent 11 ,033,192, filed November 16, 2018, and entitled “Wireless Sensor for Measuring Pressure”; U.S. patent 10,143,388, filed Jun. 8, 2015, titled "Method of Manufacturing Implantable Wireless Sensor for In Vivo Pressure Measurement”; U.S. patent 9,078,563, filed Nov. 4, 2009, titled "Method of Manufacturing Implantable Wireless Sensor for In Vivo Pressure Measurement"; U.S. patent 7,621 ,036, filed on Aug. 16, 2005, titled "Method of Manufacturing Implantable Wireless Sensor for In Vivo Pressure Measurement"; U.S. published patent application 2006 / 0287602, Ser. No. 11 / 157,375, filed Jun. 21 , 2005, titled "Implantable Wireless Sensor for In Vivo Pressure Measurement," and U.S. patent application Ser. No. 63 / 574,335, filed April 4, 2024, titled “Method and Device for Cardiac Pressure Sensing Using an Active implantable Device and Near Field Communication”, which are expressly incorporated herein by reference in their entireties.

[0204] Embodiments may be implemented in connection with one or more implantable medical devices (IMDs). Non-limiting examples of IMDs include one or more of implantable leadless monitoring and / or therapy devices, and / or alternative implantable medical devices. For example, the IMD may represent a cardiac monitoring device, pacemaker, cardioverter, cardiac rhythm management device, defibrillator, leadless monitoring device, leadless pacemaker and the like. Additionally or alternatively, the IMD may be a leadless implantable medical device (LIMD) that include one or more structural and / or functional aspects of the device(s) described in U.S. Patent 9,216,285 “LEADLESS IMPLANTABLE MEDICAL DEVICE HAVING REMOVABLE AND FIXED COMPONENTS” and U.S. Patent 8,831 ,747 “LEADLESS NEUROSTIMULATION DEVICE AND METHOD INCLUDING THE SAME”, which are hereby incorporated by reference in their entireties. Additionally or alternatively, the IMD may include one or more structural and / or functional aspects of the device(s) described in U.S. Patent 8,391 ,980 “METHOD AND SYSTEM FOR IDENTIFYING A POTENTIAL LEAD FAILURE IN AN IMPLANTABLE MEDICAL DEVICE” and U.S. Patent 9,232,485 “SYSTEM AND METHOD FOR SELECTIVELY COMMUNICATING WITH AN IMPLANTABLE MEDICAL DEVICE”, which are hereby incorporated by reference in their entireties. Additionally or alternatively, the IMD may be a subcutaneous IMD that includes one or more structural and / or functional aspects of the device(s) described in U.S. Application Serial No.: 15 / 973,195, titled “SUBCUTANEOUS IMPLANTATION MEDICAL DEVICE WITH MULTIPLE PARASTERNAL- ANTERIOR ELECTRODES” and filed May 7, 2018; U.S. Application Serial No.: 15 / 973,219, titled “IMPLANTABLE MEDICAL SYSTEMS AND METHODS INCLUDING PULSE GENERATORS AND LEADS” filed May 7, 2018; US Application Serial No.: 15 / 973,249, titled “SINGLE SITE IMPLANTATION METHODS FOR MEDICAL DEVICES HAVING MULTIPLE LEADS”, filed May 7, 2018, which are hereby incorporated by reference in their entireties. Additionally or alternatively, the IMD may be a leadless cardiac monitor (ICM) that includesone or more structural and / or functional aspects of the device(s) described in U.S. Patent 9,949,660, issued April 24, 2018, entitled, “METHOD AND SYSTEM TO DISCRIMINATE RHYTHM PATTERNS IN CARDIAC ACTIVITY,”; U.S. Patent Application 15 / 973,126, titled "METHOD AND SYSTEM FOR SECOND PASS CONFIRMATION OF DETECTED CARDIAC ARRHYTHMIC PATTERNS"; U.S. Patent Application 15 / 973,351 , titled "METHOD AND SYSTEM TO DETECT R- WAVES IN CARDIAC ARRHYTHMIC PATTERNS”; U.S. Patent Application 15 / 973,307, titled "METHOD AND SYSTEM TO DETECT POST VENTRICULAR CONTRACTIONS IN CARDIAC ARRHYTHMIC PATTERNS"; U.S. Patent Application 16 / 399,813, titled "METHOD AND SYSTEM TO DETECT NOISE IN CARDIAC ARRHYTHMIC PATTERNS”; U.S. Patent Application 16 / 930,791 , filed July 16, 2020, titled “METHODS, DEVICES AND SYSTEMS FOR HOLISTIC INTEGRATED HEALTHCARE PATIENT MANAGEMENT”, U.S. Patent 9,333,351 “Neurostimulation Method And System To Treat Apnea”, and U.S. Patent 9,044,610 “System And Methods For Providing A Distributed Virtual Stimulation Cathode For Use With An Implantable Neurostimulation System”, which are hereby incorporated by reference in their entireties. Additionally or alternatively, the IMD may be a subcutaneous IMD that includes one or more structural and / or functional aspects of the device(s) described in U.S. Patent 10,765,860, titled “Subcutaneous Implantation Medical Device With Multiple Parasternal-Anterior Electrodes”; U.S. Patent 10,722,704, titled “Implantable Medical Systems And Methods Including Pulse Generators And Leads”; US Patent 11 ,045,643, titled “Single Site Implantation Methods For Medical Devices Having Multiple Leads”, which are hereby incorporated by reference in their entireties. Further, one or more combinations of IMDs may be utilized from the incorporated patents and applications in accordance with embodiments herein.

[0205] In accordance with embodiments herein, the methods, devices, and systems may be implemented in connection with the communications systems and methods described in U.S. patent application 17 / 820,654, filed on August 18,2022, titled “System and Method for Intra-Body Communication of Sensed Physiologic Data”, which is incorporated herein by reference in its entirety. In accordance with embodiments herein, the methods, devices, and systems may be implemented in connection with those described in US patent 11 ,559,241 , filed on October 01 , 2019, titled “Methods and Systems for Reducing False Declarations of Arrythmias”, which is incorporated herein by reference in its entirety.

[0206] Embodiments may be implemented in connection with one or more PIMDs. Non-limiting examples of PIMDs may include passive wireless sensors used by themselves, or incorporated into or used in conjunction with other implantable medical devices (IMDs) such as cardiac monitoring devices, pacemakers, cardioverters, cardiac rhythm management devices, defibrillators, neurostimulators, leadless monitoring devices, leadless pacemakers, replacement valves, shunts, grafts, drug elution devices, blood glucose monitoring systems, orthopedic implants, and the like. For example, the PIMD may include one or more structural and / or functional aspects of the device(s) described in U.S. Patent No. 9,265,428 entitled “Implantable Wireless Sensor”, U.S. Patent No. 8,278,941 entitled “Strain Monitoring System and Apparatus”, U.S. Patent No. 8,026,729 entitled “System and Apparatus for In-Vivo Assessment of Relative Position of an Implant”, U.S. Patent No. 8,870,787 entitled “Ventricular Shunt System and Method”, and U.S. Patent No. 9,653,926 entitled “Physical Property Sensor with Active Electronic Circuit and Wireless Power and Data Transmission”, which are all hereby incorporated by reference in their respective entireties.

[0207] The physiologic sensor may be implemented as an accelerometer and may be implemented utilizing all or portions of the structural and / or functional aspects of the methods and systems described in US patent 6,937,900, titled “AC / DC Multi-Axis Accelerometer for Determining A Patient Activity and Body Position;” U.S. published application number 2021 / 0345935, filed 3 / 5 / 2021 , titled “SYSTEM FOR VERIFYING A PATHOLOGIC EPISODE USING AN ACCELEROMETER”; U.S. published application number 2021 / 0345891 , filed5 / 8 / 2020, titled “METHOD AND DEVICE FOR DETECTING RESPIRATION ANOMALY FROM LOW FREQUENCY COMPONENT OF ELECTRICAL CARDIAC ACTIVITY SIGNALS;” U.S. published application number 2021 / 0350931 , filed 3 / 8 / 2021 , titled “METHOD AND SYSTEMS FOR HEART CONDITION DETECTION USING AN ACCELEROMETER,” the complete subject matter which is expressly incorporated herein by reference.

[0208] The term “BGA test device” shall mean any and all equipment, devices, disposable products utilized to collect and analyze a BGA. The BGA test device may implement one or more of the methods, devices and systems described in the following publications, all of which are incorporated herein by reference in their entireties: U.S. Patent Number 8,514,086, entitled “DISPLAYS FOR A MEDICAL DEVICE”, issued August 20, 2013; U.S. Patent Publication Number 2011 / 0256024, entitled “MODULAR ANALYTE MONITORING DEVICE”, published October 20, 2011 ; U.S. Patent Publication Number 2010 / 0198142, entitled “MULTIFUNCTION ANALYTE TEST DEVICE AND METHODS THEREFORE”, published August 5, 2010; U.S. Patent Publication Number 2011 / 0160544, entitled “SYSTEM AND METHOD FOR ANALYSIS OF MEDICAL DATA TO ENCOURAGE HEALTHCARE MANAGEMENT”, published June 30, 2011 ; U.S. Patent Number 5,294,404, entitled “REAGENT PACK FOR IMMUNOASSAYS” issued March 15, 1994; U.S. Patent Number 5,063,081 , entitled “METHOD OF MANUFACTURING A PLURALITY OF UNIFORM MICROFABRICATED SENSING DEVICES HAVING AN IMMOBILIZED LIGAND RECEPTOR” issued November 05, 1991 ; U.S. Patent Number 7,419,821 , entitled “APPARATUS AND METHODS FOR ANALYTE MEASUREMENT AND IMMUNOASSAY” issued September 02, 2008; U.S. Patent Publication Number 2004 / 0018577, entitled “MULTIPLE HYBRID IMMUNOASSAYS” published January 29, 2004; U.S. Patent Number 7,682,833, entitled “IMMUNOASSAY DEVICE WITH IMPROVED SAMPLE CLOSURE” issued March 23. 2010; U.S. Patent Number 7,723,099, entitled “IMMUNOASSAY DEVICE WITH IMMUNO-REFERENCE ELECTRODE” issued May 25, 2010; and Baj-Rossi et al. “FABRICATION AND PACKAGING OF A FULLY IMPLANTABLE BIOSENSOR ARRAY”, (2013) IEEE, pages 166-169.

[0209] All references, including publications, patent applications and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.Closing

[0210] It should be clearly understood that the various arrangements and processes broadly described and illustrated with respect to the Figures, and / or one or more individual components or elements of such arrangements and / or one or more process operations associated of such processes, can be employed independently from or together with one or more other components, elements and / or process operations described and illustrated herein. Accordingly, while various arrangements and processes are broadly contemplated, described and illustrated herein, it should be understood that they are provided merely in illustrative and non-restrictive fashion, and furthermore can be regarded as but mere examples of possible working environments in which one or more arrangements or processes may function or operate.

[0211] Some or all of the Figures herein illustrate various methods and processes implemented in accordance with embodiments herein. The operations herein may be implemented by hardware, firmware, circuitry and / or one or more processors housed partially an / or entirely within an IMD, a local external device, remote server or more generally within a healthcare system. Optionally, the operations herein may be partially implemented by an IMD and partially implemented by a local external device, remote server or more generally within a healthcare system. For example, the IMD includes IMD memory and one or more IMD processors, while each of the external devices / systems (ED) (e.g., local,remote or anywhere within the healthcare system) include ED memory and one or more ED processors.

[0212] As will be appreciated by one skilled in the art, various aspects may be embodied as a system, method, or computer (device) program product. Accordingly, aspects may take the form of an entirely hardware embodiment or an embodiment including hardware and software that may all generally be referred to herein as a “circuit,” “module,” or “system.” Furthermore, aspects may take the form of a computer (device) program product embodied in one or more computer (device) readable storage media having computer (device) readable program code embodied thereon.

[0213] Any combination of one or more non-signal computer (device) readable media may be utilized. The non-signal medium may be a storage medium. A storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a storage medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a dynamic random access memory (DRAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD- ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0214] Program code for carrying out operations may be written in any combination of one or more programming languages. The program code may execute entirely on a single device, partly on a single device, as a stand-alone software package, partly on single device and partly on another device, or entirely on the other device. In some cases, the devices may be connected through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made through other devices (for example, through the Internet using an Internet Service Provider) or through a hard wireconnection, such as over a USB connection. For example, a server having a first processor, a network interface, and a storage device for storing code may store the program code for carrying out the operations and provide this code through its network interface via a network to a second device having a second processor for execution of the code on the second device.

[0215] Aspects are described herein with reference to the Figures, which illustrate example methods, devices, and program products according to various example embodiments. These program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing device or information handling device to produce a machine, such that the instructions, which execute via a processor of the device implement the functions / acts specified. The program instructions may also be stored in a device readable medium that can direct a device to function in a particular manner, such that the instructions stored in the device readable medium produce an article of manufacture including instructions which implement the function / act specified. The program instructions may also be loaded onto a device to cause a series of operational steps to be performed on the device to produce a device implemented process such that the instructions which execute on the device provide processes for implementing the functions / acts specified.

[0216] The units / modules / applications herein may include any processorbased or microprocessor-based system including systems using microcontrollers, reduced instruction set computers (RISC), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), logic circuits, and any other circuit or processor capable of executing the functions described herein. Additionally or alternatively, the modules / controllers herein may represent circuit modules that may be implemented as hardware with associated instructions (for example, software stored on a tangible and non-transitory computer readable storage medium, such as a computer hard drive, ROM, RAM, or the like) that perform the operations described herein. The above examples are exemplaryonly, and are thus not intended to limit in any way the definition and / or meaning of the term “controller.” The units / modules / applications herein may execute a set of instructions that are stored in one or more storage elements, in order to process data. The storage elements may also store data or other information as desired or needed. The storage element may be in the form of an information source or a physical memory element within the modules / controllers herein. The set of instructions may include various commands that instruct the modules / applications herein to perform specific operations such as the methods and processes of the various embodiments of the subject matter described herein. The set of instructions may be in the form of a software program. The software may be in various forms such as system software or application software. Further, the software may be in the form of a collection of separate programs or modules, a program module within a larger program or a portion of a program module. The software also may include modular programming in the form of object-oriented programming. The processing of input data by the processing machine may be in response to user commands, or in response to results of previous processing, or in response to a request made by another processing machine.

[0217] It is to be understood that the subject matter described herein is not limited in its application to the details of construction and the arrangement of components set forth in the description herein or illustrated in the drawings hereof. The subject matter described herein is capable of other embodiments and of being practiced or of being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having” and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items.

[0218] It should be recognized that, to the extent embodiments herein are described to apply certain mathematical combinations of select variables, the same variables may be combined in other mathematical combinations that arealso indicative of the same result. For example, when a single data point is utilized for a particular variable, additionally or alternatively, a mean, average, sum, or other mathematical combination of multiple data points may be utilized for the same variable.

[0219] It is to be understood that the above description is intended to be illustrative, and not restrictive. For example, the above-described embodiments (and / or aspects thereof) may be used in combination with each other. In addition, many modifications may be made to adapt a particular situation or material to the teachings herein without departing from its scope. While the dimensions, types of materials and coatings described herein are intended to define various parameters, they are by no means limiting and are illustrative in nature. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the embodiments should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "wherein." Moreover, in the following claims, the terms "first," "second," and "third," etc. are used merely as labels, and are not intended to impose numerical requirements on their objects or order of execution on their acts.

Claims

WHAT IS CLAIMED IS:1 . A server-based healthcare system, comprising: an electronic portal configured to accept a heart failure (HF) metric from a user; an HF relationship module operably coupled to the electronic portal, the HF relationship module comprising one or more processors, the HF relationship module configured to determine relationship between the HF metric and hemodynamic data; one or more memory operably coupled to the one or more processors of the HF relationship module, wherein the memory stores program instructions, wherein the program instructions are executable by the one or more processors to: receive hemodynamic data acquired by an implantable medical device implanted in one patient; store the hemodynamic data in the one or more memory; receive the HF metric via the electronic portal; and retrieve patient data from the one or more memory, the patient data associated with a sub-set of a patient population including at least two patients, at least a portion of the patient data comprising hemodynamic data; and a display configured to display a visualization showing a relationship between the HF metric and the patient data.

2. The system of claim 1 , the HF relationship module further comprising machine learning, the HF relationship module processing the patient data using the machine learning, the visualization further based on the processed patient data.

3. The system of claim 1 , wherein the patient population includes i) all patients within a clinic, ii) a sub-set of patients within the clinic, iii) patients outside of the clinic, or iv) a sub-set of patients outside of the clinic, wherein the clinic is associated with the electronic portal.

4. The system of claim 1 , wherein the HF relationship module further generates a descriptive summary based on the patient data and the HF metric, wherein the display is further configured to display the descriptive summary with the visualization.

5. The system of claim 1 , wherein the one or more processors further obtains, from the one or more memory, an industry average associated with the HF metric, wherein the display is further configured to display the industry average with the visualization.

6. The system of claim 1 , wherein the electronic portal is further configured to receive identification of the sub-set of the patient population from the user.

7. The system of claim 1 , wherein the HF metric comprises a) gender, b) mortality, c) patient age, d) risk profile, e) admission rate, f) readmissions, g) readmissions associated with a particular protocol, h) ethnicity, i) mortality, j) risk profile, k) patient phenotype, I) heart failure patient distribution, m) patients enrolled in a particular protocol, n) patient outcomes, o) adherence trends associated with a particular protocol, or p) adherence to a protocol or regimen.

8. The system of claim 1 , wherein the electronic portal is further configured to accept a second metric, wherein the visualization is further based on the second metric.

9. The system of claim 1 , wherein the hemodynamic data includes pulmonary arterial pressure, arterial pressure, systemic blood pressure, heart rate, blood flowmetrics, pressure related to a heart valve, or pressure related to a location in a vein or artery.

10. The system of claim 1 , wherein the sub-set of the patient population comprises a first sub-set of patients assigned to a first protocol and a second subset of patients not assigned to the first protocol, wherein the one or more processors are further configured to retrieve a national average associated with the HF metric, the visualization further based on the first sub-set of patients, the second sub-set of patients, and the national average.

11. The system of claim 1 , wherein the HF relationship module further generates i) a monitoring recommendation, ii) a treatment recommendation, or iii) a treatment notification based on the relationship between the HF metric and the patient data, the display further configured to display i) the monitoring recommendation, ii) the treatment recommendation, or iii) the treatment notification.

12. The system of claim 1 , wherein at least one of the one or more memory is a cloud-based memory.

13. A computer implemented method, comprising: under control of one or more processors, wherein the one or more processors are configured with specific executable instructions, receiving an HF metric via an electronic portal; receiving identification associated with a patient population via the portal, the patient population comprising at least two patients; retrieving patient data associated with the patient population from one or more memory, the one or memory operably coupled to the one ormore processors, at least a portion of the patient data comprising pulmonary arterial pressure (PAP) data acquired by an implantable sensor; determining a relationship between the HF metric and the PAP data; and displaying a visualization on a display, the visualization based on the relationship.

14. The method of claim 13, wherein the patient population includes i) all patients within a clinic, ii) a sub-set of patients within the clinic, iii) patients outside of the clinic, or iv) a sub-set of patients outside of the clinic, wherein the clinic is associated with the electronic portal.

15. The method of claim 13, further comprising obtaining, from the at least one memory, an industry average associated with the HF metric, the visualization further based on the industry average.

16. The method of claim 13, further comprising processing the patient data using artificial intelligence (Al), the relationship further based on the processed patient data.

17. The method of claim 13, wherein the one or memory is further configured to store preferences that define predetermined HF metrics and predetermined patient populations, and, in response to receiving a selection of the preferences via the electronic portal, displaying at least a second visualization on the display, the at least a second visualization based on the predetermined HF metrics and the predetermined patient populations.

18. The method of claim 13, further comprising receiving a display format via the electronic portal, the visualization being based on the display format, thedisplay format including a bar chart, a graph, a whisker chart, a box chart, a pie chart, or a format over time.

19. The method of claim 13, further comprising receiving data from a patient application, wherein the visualization is further based on the data from the patient application.

20. The method of claim 13, wherein the visualization comprises i) interventions over time within a clinic, ii) interventions over time by a provider, iii) interventions over time by patient, iv) compliance trends over time, v) animated graphs that show changes in data patterns over time, vi) of number of patients, interventions, or billing reports by provider, vii) comparisons of providers within the clinic, or vii) comparisons of providers within the clinic to providers in other clinics.

Images