Systems and methods for managing cardiac monitoring device with monitoring interval tracker

Abstract

To provide systems and methods that include a monitoring interval tracker for managing transmission data originating from a cardiac monitoring device.SOLUTION: A monitoring interval tracker generates monitoring intervals corresponding to multiple, different patient care modalities (for example, an in-office care modality, a remote monitoring care modality, and / or a heart failure care modality). Upon receiving transmission data, a docket report corresponding to the transmission data, and / or an approval of the docket report, the monitoring interval tracker determines whether to extend the monitoring interval, generate a date of service, and / or create a new monitoring interval. Multiple monitoring intervals may run concurrently to track transmission data, docket reports, and approval time-stamps for the multiple, different patient care modalities. Results of the monitoring interval tracker may be outputted as an interactive monitoring interval visualizer and / or a transmission dashboard to improve patient care by preventing failures to follow up with patients and by improving billing accuracy and efficiency.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority under 35 USC §119(e) to and claims the benefit of U.S. Provisional Patent Application No. 63 / 215,647, filed June 28, 2021, entitled "Systems and Methods for Managing a Cardiac Monitoring Device with a Monitoring Interval Tracker," which is hereby incorporated by reference in its entirety. Aspects of the present disclosure relate to the management of patient care devices for one or more patients, and more particularly, to systems and methods for managing cardiac monitoring devices. [Background technology]

[0002] Implantable medical devices are used regularly to treat and / or monitor a variety of physical ailments, for example cardiac monitoring devices such as cardiac implantable electronic devices (CIEDs). CIEDs include, but are not limited to, pacemakers (PMs), which use low-energy electrical pulses to prevent a slowing of the heart rate, implantable cardioverter-defibrillators (ICDs), which are used to detect abnormal cardiac arrhythmias and deliver a life-saving shock to prevent sudden cardiac arrest, and implantable loop recorders (ILRs) and implantable cardiac monitors (ICMs), which continuously monitor cardiac data and transmit the data to a clinic as prescribed by a clinician and at the patient's discretion. Such CIEDs may store and periodically transmit information about the operation of the device outside the body for analysis, programming, etc. More specifically, CIEDs store and transmit information for in-hospital or remote monitoring by a healthcare provider.

[0003] However, healthcare providers are often responsible for managing a large number of patients requiring different types of devices and different types of patient care. Various devices may have different transmission frequencies for reporting cardiac monitoring information to the clinic. Some devices may transmit cardiac monitoring information more consistently than others. Additionally, each type of patient care may have unique requirements for monitoring the patient. For example, some types of patient care (e.g., remote monitoring) may require quarterly transmissions from the cardiac monitoring device, while other types of patient care (e.g., in-office monitoring) may require an annual visit. Additionally, every transmission may require a corresponding medical record report and approval of the medical record report before a transaction date can be set for the transmission. When a single cardiac monitoring device is used for multiple types of patient care (e.g., remote monitoring and heart failure monitoring), the complexity of managing cardiac monitoring device transmissions becomes even more complex. Thus, tracking every transmission from every cardiac monitoring device, generating medical record reports for the transmissions, approving the medical record reports, and setting transaction dates for the transmissions in a timely manner without compromising patient care is a significant burden for clinics providing such services.

[0004] It is with inter alia these observations in mind that the various aspects of the present disclosure have been conceived and developed. Summary of the Invention

[0005] The implementations described and claimed herein address the aforementioned problems by providing systems and methods for management of patient devices.

[0006] Typically, specialist cardiac monitoring is performed throughout a patient's lifetime. Such monitoring is subject to reimbursement and care guidelines. Cardiac care may vary by type of patient care. For example, cardiac care may include four remote data checks per year for patients with pacemakers (PMs) or implantable cardioverter defibrillators (ICDs) ("remote monitoring patient care"), at least one in-hospital check per year for patients with PMs or ICDs ("in-hospital patient care"), and eleven remote data checks per year for patients with implantable cardiac monitors (ICMs) or implantable loop recorders (ILRs) ("heart failure patient care"). Health insurance in the United States generally adheres to such guidelines. However, while health insurance reimbursements are available, they often do not cover the labor costs of obtaining, reviewing, and documenting device transmissions. With the rapid adoption of new ILRs and ICMs and the growing volume of data, the estimated transmission load of such guidelines could exceed 800 million cardiac monitoring transmissions over the next five years. Adherence to such guidelines improves patient outcomes and reduces costs to the healthcare system, reducing mortality rates by nearly 2.5-fold in patients with PMs and reducing hospitalizations by over 65% in patients with ICDs. However, due to the burden associated with such guidelines, it is estimated that less than 30% of patients are monitored according to these guidelines.

[0007] In one implementation, a medical device management platform for managing cardiac monitoring devices may include a monitoring interval tracker that tracks transmitted data from the cardiac monitoring devices by associating the transmitted data with another monitoring interval. The one or more monitoring intervals may correspond to one or more patient care modalities, such as heart failure patient care, out-of-hospital patient care, and / or in-hospital patient care. The monitoring interval tracker calculates an extension of the monitoring interval as necessary and classifies the transmitted data, medical record reports for the transmitted data, and medical record report acknowledgements according to the patient care modality and the monitoring interval extension to improve accuracy of date of business DOS calculations while minimizing failure to attract proper follow-up management attention for the transmission.

[0008] Other implementations are described and referenced herein. Moreover, while multiple implementations are disclosed, still other implementations of the presently disclosed technology will become apparent to those skilled in the art from the following detailed description, which shows and describes exemplary implementations of the presently disclosed technology. As will be seen from the following description, the presently disclosed technology can be modified in various aspects without departing from the spirit and scope of the presently disclosed technology. Thus, the drawings and detailed description are to be regarded as illustrative in nature, and not restrictive. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 illustrates an example block diagram of a network environment including a medical device manager operating on a server or other computing device coupled to a network for managing one or more cardiac implantable electronic devices.

[0010] [Diagram 2] FIG. 2 illustrates a block diagram of a medical device data communication system including an exemplary medical device data platform.

[0011] [Diagram 3] FIG. 3 illustrates a block diagram of an exemplary medical device data platform.

[0012] [Figure 4] FIG. 4 illustrates a block diagram of an example monitoring interval tracker interacting with one or more databases and a healthcare provider portal.

[0013] [Diagram 5] FIG. 5 illustrates a timeline diagram of exemplary operations performed by a monitoring interval tracker to manage a patient-worn medical device.

[0014] [Figure 6] FIG. 6 illustrates a timeline diagram of exemplary operations performed by a monitoring interval tracker to manage a patient's medical devices.

[0015] [Figure 7] FIG. 7 illustrates a timeline diagram of exemplary operations performed by a monitoring interval tracker to manage a patient's medical devices.

[0016] [Figure 8] FIG. 8 illustrates a timeline diagram of exemplary operations performed by a monitoring interval tracker to manage a patient's medical devices.

[0017] [Figure 9] FIG. 9 illustrates a timeline diagram of exemplary operations performed by a monitoring interval tracker to manage a patient's medical devices.

[0018] [Figure 10] FIG. 10 illustrates a timeline diagram of exemplary operations performed by a monitoring interval tracker to manage a patient's medical devices.

[0019] [Figure 11] FIG. 11 illustrates a timeline diagram of exemplary operations performed by a monitoring interval tracker to manage a patient's medical devices.

[0020] [Figure 12] FIG. 12 illustrates a flow chart of exemplary operations performed by a monitoring interval tracker to manage a patient's medical devices.

[0021] [Figure 13] FIG. 13 illustrates an exemplary surveillance tracker visualizer user interface for managing a patient's medical devices.

[0022] [Figure 14] FIG. 14 illustrates an exemplary surveillance tracker visualizer user interface for managing a patient's medical devices.

[0023] [Figure 15]FIG. 15 illustrates an exemplary surveillance tracker visualizer user interface for managing a patient's medical devices.

[0024] [Figure 16] FIG. 16 illustrates an exemplary monitoring interval setting user interface for managing a patient's medical devices.

[0025] [Figure 17] FIG. 17 illustrates an exemplary transmission dashboard user interface for managing a patient's medical devices.

[0026] [Figure 18] FIG. 18 illustrates an exemplary transmission dashboard user interface for managing a patient's medical devices.

[0027] [Figure 19] FIG. 19 illustrates an example billing report dashboard user interface for managing a patient's medical devices.

[0028] [Figure 20] FIG. 20 illustrates an example computing system in which various systems and methods discussed herein may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0029] Aspects of the present disclosure include systems, methods, computer program products, etc. for a medical device management platform for managing one or more implantable or wearable electronic devices. The electronic devices may include medical devices such as one or more cardiac monitoring devices (e.g., cardiac implantable electronic devices (CIEDs)). The medical device management platform may generally include a monitoring interval tracker that receives operational transmissions from one or more patient medical devices, such as CIEDs, to manage the care of such patients, including receiving data, reports, and information from such devices so that healthcare providers can evaluate, document, report, and generate patient care strategies. Such operational transmissions may be received as transmission data at the monitoring interval tracker through a number of sources, including reports from the corresponding device, device programming machine, patient or manufacturer, or third party organizations that receive transmissions from the device. Upon receiving the transmission data, the monitoring interval tracker may associate the transmission data with the corresponding monitoring interval to ensure timely medical record reports, medical record report acknowledgments, and DOS are received.

[0030] For example, the monitoring interval tracker may generate a monitoring interval associated with the cardiac monitoring device prior to receiving transmission data as part of a registration procedure or in response to receiving transmission data. The monitoring interval may correspond to a particular type of patient care (e.g., remote monitoring care, in-hospital care, and / or heart failure care) and may have a length of time based on patient care modality rules accessed from a rules database. The transmission data may be time-stamped to indicate the date and / or time the clinic received the transmission data (i.e., the "received date"). The monitoring interval tracker may determine whether the received date is within the monitoring interval by calculating whether the received date is before or after the end date of the monitoring interval. If the received date is after the end date, the monitoring interval tracker may access an interval extension rule from the rules database that indicates how to adjust the monitoring interval to incorporate the later received transmission data. For example, if the end date occurs but transmission data has not yet been received for the monitoring interval, the monitoring interval tracker may access a first interval extension rule indicating that the monitoring interval is extended by day and may create an extended end date for the monitoring interval for each day until transmission data is received. If transmission data is received during the extended monitoring interval, the extended monitoring interval may end, and in some cases may generate a date of operation (DOS) for the extended monitoring interval on the date of receipt (which may be the extended end date). Additionally or alternatively, the monitoring interval tracker may access a second interval extension rule from the rules database that indicates that upon reaching the end date, a monitoring interval (e.g., a first monitoring interval) is scheduled to end without receiving transmission data prior to the end date, and a second monitoring interval (e.g., having the same length of time as the first monitoring interval as dictated by a patient care modality rule) may be generated with a new second end date.

[0031] In some examples, the monitoring interval tracker may determine whether the DOS criteria are met to generate a DOS. For example, the DOS criteria may include a receipt date of the transmission data before the end date (or extended end date) of the monitoring interval, generating a medical record report for the transmission data before the end date (or extended end date), and receiving an approval timestamp for the medical record report indicating an approval date after the receipt date and after the date of the medical record report but before the end date (or extended end date). The monitoring interval tracker may access multiple rules from a rules database, such as one or more patient care modality rules and / or interval extension rules for generating and extending the monitoring interval according to the type of patient care, to ensure that the DOS criteria are met. For example, the monitoring interval tracker may receive the transmission data before the end date and generate the medical record report before the end date, but may not yet receive an approval timestamp indicating an approval date for the medical record report when the end date occurs. To this end, the monitoring interval tracker may access a third interval extension rule from the rules database that indicates that the monitoring interval is to be extended on a day by day basis, creating an extended end date for each day, until an acknowledgement timestamp is received and the DOS criteria for the monitoring interval is met.

[0032] In some examples, the monitoring interval tracker may generate multiple simultaneously active monitoring intervals for a cardiac monitoring device, each simultaneously active monitoring interval corresponding to a different patient care modality rule and therefore having a different time length and a different end date. Multiple medical record reports may be received or generated for the transmitted data, such as a medical record report for each simultaneously active monitoring interval. In some cases, the monitoring interval tracker may receive a first approval timestamp for a first medical record report of the multiple medical record reports before the end date, on the end date, or on an extended end date, while still missing a second approval timestamp for a second medical record report of the multiple medical record reports. For example, a first medical record report for a first monitoring interval relating to the care of a heart failure patient may be approved within the first monitoring interval, but a second medical record report for a second monitoring interval relating to the care of a patient via remote monitoring remains unapproved. The monitoring interval tracker may generate a DOS for the transmitted data of the approved medical record report even if the second medical record report remains unapproved. Additionally, the monitoring interval tracker may receive a second acknowledgment timestamp for the second medical record report during a third monitoring interval (e.g., generated after the first monitoring interval). Additionally, the monitoring interval tracker may recognize that the second acknowledgment timestamp corresponds to transmitted data for which it has already received a DOS (based on the first acknowledgment timestamp of the first medical record report) and may omit generating a second DOS based on the second acknowledgment timestamp.

[0033] In some examples, the medical device management platform may include an interface tool, such as a monitoring interval visualizer, for presenting information generated by the monitoring interval tracker via a graphical user interface (GUI) on a display of a clinic providing patient care. For example, the monitoring interval visualizer may present the monitoring interval as an interactive interval shape (e.g., a bar, block, line, etc.) on one or more timelines. The interactive interval shape may include indicators or icons corresponding to the receipt date, the medical record report status, the date of the medical record report, and / or the approval date. Upon receiving user input, the interactive interval shape and / or indicator may present to the authorized user various transmission-related data, such as the receipt date of the transmission data, the date of the medical record report, the approval date, one or more action request indicators corresponding to the medical record report (including the name of the medical professional who created the medical record report and / or the medical professional who approved the medical record report) and / or the monitoring interval. In some examples, the interface tool may include a transmission dashboard for aggregating transmission-related data for a particular clinic from a transmission database, generating one or more transmission metrics for the particular clinic, and presenting the transmission metrics on a display of the particular clinic. Additionally, statistics and other metrics of received transmissions and resulting care protocols may be provided through the interface tools to improve clinic operations and efficiency, improve patient care, or share data with other organizations that have access to the interface, thus simplifying and improving management of device transmissions for users of the device management platform interface.

[0034] Reference is now made to Figure 1. Figure 1 illustrates an exemplary network environment 100 including a medical device manager 102 running on a server 112 or other computing device coupled to a network 106 to manage one or more cardiac implantable electronic devices 104. In one implementation, a user, such as a member of a medical team and / or a third party who has been delegated access to manage or complete administrative tasks, uses a user device 108 to access and interact with a portal for the medical device manager 102 to access or manage one or more medical devices via the network 106 (e.g., the Internet). The user device 108 is generally any form of computing device capable of interacting with the network 106, such as a personal computer, terminal, workstation, portable computer, mobile device, smartphone, tablet, multimedia console, etc. The network 106 is used by one or more computing devices or data storage devices (e.g., one or more databases 110 or other computing units described herein) to implement services, data structures, applications, or modules, including the medical device manager 102, within the network environment 100.

[0035] In one implementation, the network environment 100 includes at least one server 112 that hosts a website or application that a user may access to access the medical device manager 102 and / or other network components, including a device programming machine that resides in a physician's office and is utilized in the presence of a patient. The server 112 may be a single server, multiple servers, each such server being a physical server or a virtual machine, or a collection of both physical servers and virtual machines. In another implementation, a cloud hosts one or more components of the network environment 100. User devices 108, servers 112, and other information sources connected to the network 106 may access one or more other servers to access one or more websites, applications, web service interfaces, storage devices, computing devices, and the like, used for integrated healthcare delivery. The server 112 may also host a search engine that the medical device manager 102 uses to access, search, and modify data, including patient data, team member data, and education data. In one implementation, the medical device manager 102 provides access to data and / or other information for one or more medical devices 104, such as cardiac monitoring devices.

[0036] The medical devices 104 may communicate with the network 106 to provide operational data to the medical device manager 102. For example, as described above, cardiac implantable electronic devices (CIEDs), such as implantable cardioverter defibrillators (ICDs), often transmit information related to the operation of the device outside the body for analysis, programming, etc. In some cases, a clinic retrieves data for the medical devices 104 from a secure website of the device manufacturer and / or from a device programming machine physically located in the healthcare provider's office. Data generated by the medical devices 104 is typically reviewed by the healthcare provider, who then generates a medical record report. Typically, the healthcare provider implants and monitors transmissions from all manufacturers, models and types of devices. Healthcare providers rarely embed and monitor a single device type. Each manufacturer uses unique and proprietary data formats, displays, access protocols, reports, and programming machines for data transmission and review modalities. This wide range of unique and disparate formats of data received by healthcare providers makes it difficult for healthcare providers to effectively manage patient care. The burden of accessing and managing data is a major impediment to improved patient care. Cumbersome workflows incur excessive costs, hinder the adoption of telecare, a preferred care modality, lead to missed reimbursement opportunities, and cause some clinics to abandon telecare and instead push patients to even less in-office care, further reducing care through lower patient compliance and increased strain on the healthcare system with increased hospitalizations. Thus, as described in more detail below, the medical device manager 102 allows users to manage, analyze, and / or store data from one or more medical devices 104 across various device types and different manufacturers while improving DOS calculations and reducing tracking failures.

[0037] With reference to FIG. 2, the medical device manager 102 may include a medical device data communication system 200. In one implementation, the medical device data communication system 200 includes a medical device platform 204 that communicates with a number of implantable medical device manufacturer systems 206 and a number of clinic systems 202. The medical device platform 204 may be communicatively coupled to the manufacturer systems 206 and the clinic systems 202 via a wide area network (WAN), such as the Internet, for example. In some implementations, each of the manufacturer systems 206 may be associated with a unique implantable medical device manufacturer. In other examples, each of the manufacturer systems 206 may be associated with a unique combination of an implantable medical device manufacturer and a particular clinic or office. In the example system 200 of FIG. 2, the manufacturer system 206 may include a manufacturer platform 212, such as a web server, that retrieves previously uploaded diagnostic and related data from a number of implantable medical devices from a device database 214. Such data may have been previously retrieved from the various implantable medical devices via the clinic or office or via remote monitoring, as described above.

[0038] As shown in FIG. 2, the medical device platform 204 may include an integration manager 210 that accesses diagnostic and related data for implantable medical devices from each manufacturer system 206. In one example, the integration manager 210 may provide a Clinical Information System (CIS) identifier associated with a particular clinic to the manufacturer platform 206 to retrieve the diagnostic and related information. Such information may be in the form of an Implantable Device Cardiac Observation (IDCO) message. In some implementations, messages between the integration manager 210 and the manufacturer platform 212 may be in the form of alternative, enhanced, or extended data messages. For example, IDCO messages often include information formatted as a summary report in Portable Document Format (PDF). In other examples, IDCO-like messages may provide more detailed or "raw" data, such as numeric data and / or graphic electrogram (EGM) data regarding arrhythmias or other heart events detected by the implantable device in integer, floating point, or another data format. Such information may facilitate easier and / or more detailed processing of the device data within the medical device platform 204.

[0039] The integration manager 210 may then process the retrieved information to generate patient-oriented information and / or healthcare provider-oriented information. In some examples, the retrieved information from the various implantable medical devices may be processed into a format that is uniform or generalized across all manufacturers and / or a particular type of device. The integration manager 210 may then forward the processed information to a cloud computing system 208, which may provide one or more web portals to the clinic system 202. In other examples, the integration manager 210 may forward the retrieved device data to the cloud computing system 208, which may then act as an information processor to process the data. The cloud computing system 208 may also generate and provide advanced information, including analytical results, based on the processed information via the web portal. Examples of web portals and generating and providing analytics of information are described in more detail below. In some examples, the cloud computing system 208 may include multiple computing devices or systems configured to perform various operations attributed to the cloud computing system 208 herein.

[0040] As shown in FIG. 2, a user (e.g., one or more doctors, nurses, technicians, analysts, etc.) may employ the clinic system 202 to retrieve processed device information, possibly including advanced information such as monitoring interval tracking, analysis results, and other information for one or more implantable medical devices. In some examples, the clinic system 202 may include a clinic access system 218 (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.). From the clinic access system 218, a user may access a web portal provided by the cloud computing system 208 to retrieve information for healthcare providers such as the medical device manager 102. As shown in FIG. 2, the clinic system 202 may also include one or more of an electronic medical record manager system 216 configured to store and facilitate access to medical records of the clinic's patients, and a health information exchange (HIE) system 220 configured to exchange health care information for the clinic's patients with other computing systems external to the clinic system 202. In one implementation, a user may sign on or log on to the cloud computing system 208, the medical record manager 216, and / or the HIE system 220 using a single sign-on (SSO) procedure, thereby reducing the time a user would normally require to access each such system individually.

[0041] In some examples, integration manager 210 may retrieve device information, including device diagnostic data, via transmission data received over a communications connection with one or more of the implantable medical devices, potentially reducing the need for one or more of manufacturer systems 206. In these and other examples, integration manager 210 and / or cloud computing system 208 may forward or "push" raw and / or processed device information, as well as advanced information, including analysis results, to one or more of manufacturer systems 206 used by the corresponding manufacturers of the devices.

[0042] In some examples, the medical device platform 204 may include a monitoring interval tracker 222. The monitoring interval tracker may receive data (e.g., transmission data and transmission-related data) from other components of the medical device manager 102, such as the integration manager 210. The monitoring interval tracker 222 may receive data from the clinic system 202, such as the access system 218. In some cases, the monitoring interval tracker 222 may classify the transmission data according to the cardiac monitoring device from which the transmission data originated, the type of patient care (e.g., “patient care modality”) associated with the transmission data (e.g., based on an association with the cardiac monitoring device or a patient being monitored by the cardiac monitoring device), and / or one or more monitoring intervals for the cardiac monitoring device. The monitoring interval tracker may access one or more rules from the database 110 and perform calculations to generate extensions of the monitoring intervals and DOS for the monitoring intervals. In some cases, the monitoring interval tracker 222 may perform an analysis of the transmission data and transmission-related data and output the results to a healthcare provider portal. The monitoring interval tracker 222 may receive an indication (e.g., during a registration process) that a patient is associated with a particular patient care modality and / or store the association of the patient with the patient care modality in one or more databases 110. The monitoring interval tracker 222 may determine and store an association between one or more interval extension rules and a particular patient and / or a particular clinic in one or more databases 110. The operation of the monitoring interval tracker 222 is discussed in further detail below.

[0043] Figure 3 is a block diagram of an example of the medical device platform 204 of Figure 2. As shown in Figure 3, the medical device platform 204 may include one or more of a transmission analyzer 300, a tracker 302, an aggregator 304, a healthcare provider portal 306, a scheduler 308, a medical record generator 310, a workflow engine 312, a billing engine 314, and / or a record integrator 316. Additionally, in other examples, other software components, data structures, applications, or modules not specifically described herein may be included in the medical device platform 204. Furthermore, each of such software components may be incorporated within the monitoring interval tracker 222, the integration manager 210, and / or the cloud computing system 208 as shown in Figure 2.

[0044] In some examples, the transmission analyzer 300 may be configured to analyze information and data received from one or more cardiac monitoring devices and provide an automated snapshot of trends in the analyzed information. In some embodiments, such information may be analyzed for a particular clinic or multiple clinics. As described above, one or more cardiac monitoring devices may transmit stored or acquired information or data regarding the performance or operation of the implantable device. This information is transmitted or downloaded to the medical device platform 204 and analyzed by the transmission analyzer 300. Analysis of the information may provide a particular snapshot of the analyzed and / or aggregated information through a portal (discussed in further detail below). For example, the transmission analyzer 300 may provide information based on the type of device, device manufacturer, or specific device model associated with the information or data. In a similar manner, a tracker 302 may be included in the medical device platform 204 to track trends in the received data over time. Through a combination of the transmission analyzer 300, tracker 302, and other software components, a snapshot of device information may be provided, such as trends in medical record reports regarding received acknowledgments or lack of acknowledgments, monitoring intervals with extended DOS, overall transmission of data received and specific monitoring intervals, etc. Further analysis and information regarding data received from one or more medical devices and analyzed by the transmission analyzer 300 is discussed in more detail below.

[0045] In some examples, the aggregator 304 may also be included in the medical device platform 204. In general, the aggregator 304 may be configured to retrieve diagnostic and other device-related data from each of the manufacturer systems 206 discussed above and / or retrieve information from the cardiac monitoring devices. In one example, the aggregator 304 may utilize a manufacturer-specific courier engine to retrieve data using the specific security measures, communication protocols, data formats, and other characteristics of the particular manufacturer system 206 required to retrieve the data from the courier engine. In at least some examples, the use of the aggregator 304 may reduce the need for information technology (IT) professionals in the clinic to retrieve diagnostic and other information from the implantable medical devices, especially devices from multiple manufacturers that may each employ proprietary data formats, communication protocols, etc.

[0046] In some examples, the healthcare provider portal 306 may be configured to present a web interface to the clinic system 202 that facilitates clinic staff access to provider-directed device data information corresponding to the clinic's patients. The healthcare provider portal 306 may utilize clinic staff and patient logons, respectively, to allow access to provider-directed or patient-directed information as appropriate. In some examples, as described above, logging on to the healthcare provider portal 306 may facilitate clinic staff access to other systems (e.g., medical records manager 216 and / or HIE system 220 of FIG. 2) located outside or within the clinic system 202 via single sign-on (SSO) functionality. Additionally, the healthcare provider portal 306 may provide application programming interfaces (APIs) that facilitate patient or provider access to the patient's electronic health record (EHR), which may include access points to device-related information, such as, for example, embedded web links. The healthcare provider portal 306 may present one or more visualizations of the monitoring interval tracker 222, such as timelines, interval shapes, indicators, blocks and / or icons representing the monitoring intervals, medical record reports, approval dates and DOS, as discussed in further detail below.

[0047] In some examples, the medical device platform 204 may provide or include other information portals other than the healthcare provider portal 306, such as portals for administrative personnel associated with a clinic or insurance company, executives associated with a clinic or insurance company, employees of one or more cardiac device manufacturers, etc. In such examples, each particular class or group of potential users of the medical device platform 204 may be associated with a particular range or set of access rights, set of security requirements (e.g., requirements for usernames, passwords, computer systems, etc.). As a result, each group of users may employ a corresponding user portal that is substantially similar to the healthcare provider portal 306. Each particular portal may be accessible via a different Uniform Resource Locator (URL), and the same may be distinguished in one or more other ways.

[0048] In some examples, the scheduler 308 may be configured to present a web interface (e.g., the web portal described above or another web portal) accessible to patients and / or clinic staff to schedule appointments, such as in-office or home device checks or programming of clinic patient visits. In some examples, the scheduling web portal may be customized for a particular clinic and may provide additional information regarding the services offered by the clinic, descriptions of clinic staff members, etc. For example, the monitoring interval tracker 222 may generate an action call indicator corresponding to a cardiac monitoring device having in-office care. Upon receiving user input in the action call indicator, the scheduler 308 may initiate a scheduling procedure for a particular patient being monitored by a cardiac monitoring device.

[0049] The medical record generator 310 may be configured to generate one or more medical records (e.g., "medical record reports") associated with the patient or the set of received data. In general, a medical record report is some type of report that summarizes or otherwise provides an interpretation and record of the received patient CIED transmission. All or a portion of the medical record report may be populated with information received during transmission, and all or a portion of the medical record report may be provided to clinic staff for analysis and approval. The medical record report may include information such as device manufacturer information, clinic staff approval, clinical data, care plan, device tracking, patient information, data analysis summary, etc. Any information related to the patient information, or information received from multiple medical devices, may be included in the medical record via the medical record generator 310. In some cases, the monitoring interval tracker 222 may generate an indication that a medical record report is required in response to receiving the transmitted data. This indication, upon receiving user input, causes the medical record generator 310 to initiate the medical record creation process for the received transmission.

[0050] The workflow engine 312 may be configured to monitor information related to one or more patient's cardiac monitoring devices, including information regarding periodic device checks and resulting diagnostic data, and based on that information, recommend changes to the clinic's workflow, such as changes to device check schedules, changes to particular types of information retrieved from implantable medical devices, or changes to how the retrieved information is processed, thereby, in some cases, making the clinic's operations more efficient.

[0051] The billing engine 314 may be configured to present (e.g., via a web portal for healthcare providers) an interface through which clinical staff may input an indication of one or more clinical procedures to be performed on a patient's implantable medical device, such as a cardiac monitoring device, and generate currently appropriate billing codes representing the procedures. Furthermore, the resulting billing codes for one or more such actions may be further inserted into a billing code summary sheet or other format for presentation to patients, health insurance companies, etc. In some examples, the billing engine 314 may receive or retrieve information regarding changes to billing codes from the Centers for Medicare and Medicaid Services (CMS) that may be employed in a Pro for Sale Payment System (PPS), and may use such changes to update billing codes corresponding to clinical procedures associated with the implantable medical device.

[0052] The record integrator 316 may be configured to update the EHR or populate the EHR with information related to the implantable medical device, including processed diagnostic data, for example, by embedding web links in the patient's EHR that facilitate access to processed device-related data. Such data may include, for example, dates of diagnostics performed on the implantable medical device, numerical data and / or graphs of diagnostic results, actions recommended and / or taken based on diagnostic results, the patient's health status or biological response to operation of the device based on data detected by the device, etc.

[0053] 4 is a block diagram of an example of the monitoring interval tracker 222 of FIG. 2. The monitoring interval tracker 222 may include many of the software components discussed above with respect to FIG. 3 to analyze received transmission data to identify the cardiac monitoring device from which the transmission data originated, classify the transmission data according to one or more patient care modalities provided to the cardiac monitoring device, generate one or more medical records for the transmission data, extend one or more monitoring intervals of the cardiac monitoring device, and / or generate a DOS for the transmission data. The monitoring interval tracker 222 may access information stored in the database 110. For example, the database 110 may include a rules database 400 for storing one or more patient care modality rules 402 and / or one or more interval extension rules 404. The patient care modality rules 402 may include a first patient care modality rule for heart failure patient care indicating that the monitoring interval has a time length of 31 days if the monitoring interval is associated with heart failure patient care. The patient care modality rules 402 may include a second patient care modality rule for remotely monitored patient care indicating that the monitoring interval has a length of 91 days if the monitoring interval is associated with remotely monitored patient care. The patient care modality rules 402 may include a third patient care modality rule for in-hospital patient care indicating that the monitoring interval is 91 days if the monitoring interval is associated with in-hospital patient care. The patient care modality rules 402 may include additional patient care modality rules for other types of patient care indicating that the monitoring interval is of other lengths of time. According to the patient care modality rules, if all DOS criteria are met during the monitoring interval, the end date of the monitoring interval may be the predicted DOS of the transmitted data received during the monitoring interval (i.e., before the end date). However, in some cases, the DOS criteria may not be met by the end date, in which case the monitoring interval tracker 222 may access the interval extension rules to generate an extended end date for the monitoring interval.

[0054] In some examples, the interval extension rules 404 may indicate how a monitoring interval is extended, not extended, or closed based on the transmission data and the transmission-related data. For example, the interval extension rules 404 may include a first interval extension rule (e.g., a "day transmission roll" rule) that indicates that the DOS is the end date of the monitoring period or the date of receipt of the transmission data (whichever is later). According to the day transmission roll rule, if the end date of the monitoring interval occurs and the transmission data has not yet been received, the monitoring interval tracker 222 will generate an extended end date by adding one day to the monitoring interval each day until the transmission data is received. At that point, the monitoring interval will end and a DOS will be generated for the monitoring interval as the date of receipt of the transmission (which is also the final extended end date of the monitoring interval), and a second monitoring interval will be generated to be effective after the ended or closed monitoring interval. According to the daily transmission role rules, the transmitted data may still require a medical record report and approval of that medical record report for billing purposes, but the second monitoring interval would still begin on a date after the receipt date of the transmission so as not to be dependent on a physician or medical professional creating and approving a medical record report for the transmitted data in a timely manner.

[0055] In some examples, the interval extension rule 404 may include a second interval extension rule (e.g., a "roll by interval" rule) that indicates that the DOS is the end date of the monitoring period regardless of whether transmission data was received during the monitoring period. According to the roll by interval rule, if the end date of the monitoring period occurs and transmission data has not yet been received, the monitoring interval will end without being extended and may be classified as a "missed" monitoring interval for patient follow-up and billing procedures. A second monitoring interval will be generated to be performed after the ended or closed monitoring interval. The second monitoring interval may have a time length equal to the time length of the closed monitoring period. No medical record reports or approval requirements will be generated during the closed monitoring period.

[0056] In some examples, the interval extension rule 404 may include a third interval extension rule (e.g., a "daily approval roll" rule) that indicates that the DOS is the later of the end date of the monitoring period or the approval date (e.g., as indicated by an approval timestamp) of the medical record report corresponding to the transmitted data. According to the daily approval roll rule, when the end date of the monitoring interval occurs and the approval timestamp of the medical record report has not yet been received, the monitoring interval tracker 222 will generate an extended end date by adding one day to the monitoring interval each day until the approval timestamp is received. Once the approval timestamp is received, the monitoring interval will end and a DOS will be generated for the monitoring interval as the approval date of the medical record report (which is also the final extended end date of the monitoring interval), and a second monitoring interval will be generated to take effect after the ended or closed monitoring interval. In some cases, the medical device platform 204 may generate multiple medical record reports during the monitoring interval, in which case the earliest approval timestamp corresponding to one of the multiple medical record reports will be determined to be the DOS date of the monitoring interval.

[0057] In some examples, the patient care modality rules 402 and / or the interval extension rules 404 may be based on one or more medical policies stored, for example, in a medical policy database 406. The medical policy database 406 may store one or more Heart Rhythm Society (HRS) care guidelines and / or Center for Medicare and Medicaid Services (CMS) care guidelines. For example, a CMS care guideline may include one or more professional codes (PCs).For example, PC93294 states, "Interview device evaluation (remote), single-lead, dual-lead or multi-lead pacemaker systems with interim analysis, review and report by a physician or other qualified health professional for up to 90 days (please do not report 93294 with 93288, 93293) (please report 93294 only once per 90 days)"; PC93295 states, "Interview device evaluation (remote), single-lead, dual-lead or multi-lead implantable cardioverter defibrillator systems with interim analysis, review and report by a physician or other qualified health professional for up to 90 days (for remote monitoring of physiological cardiovascular data elements derived from an ICD, please use 93297) (please do not report 93295 with 93289) (please report 93295 only once per 90 days)"; PC93297 states, PC93298 states: “Implantable Cardiovascular Monitoring Systems, including evaluation (remote) of the interview device, analysis of one or more physiological cardiovascular data elements recorded from any internal and external sensors for up to 30 days, analysis, review and report by a physician or other qualified health professional (for cardiac rhythm derived data elements, please use 93295) (please do not report 93297 in conjunction with 93290, 93298) (please only report 93297 once per 30 days)” and / or PC93298 states: “Implantable Loop Recorder Systems, including evaluation (remote) of the interview device, analysis of recorded cardiac rhythm data for up to 30 days, analysis, review and report by a physician or other qualified health professional (please do not report 93298 in conjunction with 33282, 93291, 93297) (please only report 93298 once per 30 days).” The monitoring interval tracker 222 (and / or other components of the medical device platform 204) may access medical policies, such as PC codes, and generate patient care modality rules and / or interval extension rules to correspond to the PC codes (e.g., via manual entry and / or automatic text and content recognition using machine learning techniques).The medical policy database may be updated at regular intervals (e.g., weekly, monthly, annually, etc.) to reflect changes in HRS or CMS policies so that patient care modality rules and / or interval extension rules 404 are continually kept current to provide accurate monitoring interval tracking that corresponds to highly efficient billing practices.

[0058] In some examples, database 110 may include a transmission database for storing transmission data and transmission-related data associated with the transmission data. For example, the transmission-related data associated with a transmission may include a receipt date timestamp indicating a date the transmission data was received, a cardiac monitoring device identifier corresponding to a cardiac monitoring device from which the transmission data was received, a patient identifier, a clinic identifier, a medical record report creation date timestamp, an approval timestamp, an indication of DOS criteria status, and / or any data generated or received by other components of medical device platform 204 (e.g., integration manager 210, cloud computing system 208, transmission analyzer 300, tracker 302, aggregator 304, etc.) related to the transmission data.

[0059] In some examples, the monitoring interval tracker 222 may generate a monitoring interval visualizer 410 to present an indication of the monitoring interval and the end date, extended end date, medical record creation date, approval date, and / or DOS. The monitoring interval visualizer 410 may present an indication of "action required" to alert a medical professional that a particular monitoring interval requires submission, medical record report, or medical record report approval. The indication may be presented as a selectable shape and / or interactive graphical user interface (GUI) indicator via a medical provider portal to provide additional information upon receipt of user input. The monitoring interval visualizer 410 is discussed in more detail below.

[0060] In some examples, the monitoring interval tracker 222 may generate a transmission dashboard 412. For example, the monitoring interval tracker 222 may access the transmission data and / or transmission-related data from the transmission database 408, aggregate the transmission data and / or transmission-related data, perform analytics on the aggregated transmission data and / or transmission-related data, and present the results of the analytics in the transmission dashboard 412. In some examples, the transmission data and / or transmission-related data may be aggregated according to a particular clinic identifier such that the result is transmission metrics for a particular clinic corresponding to the particular clinic identifier. The transmission dashboard 412 may be presented via the healthcare provider portal 306. The transmission dashboard 412 is discussed in more detail below.

[0061] Figure 5 shows several example timeline diagrams of operations performed by the monitoring interval tracker 222 using a daily transmit roll rule to generate one or more DOS. Figure 6 shows several example timeline diagrams of operations performed by the monitoring interval tracker 222 using a daily transmit roll rule to generate one or more DOS. Figure 7-11 show several example timeline diagrams of operations performed by the monitoring interval tracker 222 using a daily acknowledge roll rule to generate one or more DOS.

[0062] 5, two exemplary timeline diagrams are shown illustrating operations performed by the monitoring interval tracker 222 using the daily transmission roll rule to generate one or more DOS, generate a new monitoring interval, and / or generate an extension of a monitoring interval. For example, in a first exemplary scenario 500, a first monitoring interval 502 may be generated. A trigger may occur when transmission data 504 occurs. This is defined as a "success" when transmission data 504 is received during the first monitoring interval 502 (i.e., before the end date 506 of the first monitoring interval 502). In response to the "success", the monitoring interval tracker generates a DOS as the end date 506 of the first monitoring interval 502 and generates a new monitoring interval 508 or a second monitoring interval 508 that is effective following the first monitoring interval. The second monitoring interval 508 has a second end date 510 that specifies the same length of time as the first monitoring interval 502 (which may be based on the patient care modality rules 404). A second example scenario 512 is illustrated, in which the transmission data 504 is not received during the first monitoring interval 502 (i.e., before the end date 506). This is defined as a "failure" according to the daily transmission roll rules. Thus, the monitoring interval tracker 222 may generate an interval extension 514, for example, to extend the interval by one day until the transmission data 504 is received on the extended end date 516. Upon receiving transmission data 504 at the extended end date 516 during the interval extension 514, the monitor interval tracker generates a DOS (e.g., a determined DOS as opposed to an initial predicted DOS prior to generating the interval extension) as being the date of receipt of the transmission data 504 (i.e., the extended end date 516) and generates a new or second monitor interval 508 that is effective subsequent to the first monitor interval 502. The second monitor interval 508 has a second end date 510 that defines the same length of time as the length of time of the first monitor interval 502 prior to adding the interval extension 514.

[0063] FIG. 6 illustrates an exemplary timeline diagram showing operations performed by the monitoring interval tracker 222 using the transmit-per-interval roll rule to generate one or more DOS and generate a new monitoring interval. In an exemplary scenario 600, transmission data 504 is not received during the first monitoring interval 502 (i.e., before the end date 506), which the transmit-per-interval roll rule defines as a "failure." In response to the failure, the monitoring interval tracker 222 closes the first monitoring interval 502, resulting in a closed or missed monitoring interval 602, and generates a new or second monitoring interval 508 that is valid following the missed monitoring interval 602. The monitoring interval tracker 222 does not generate a DOS during the missed monitoring interval. The second monitoring interval 508 has a second end date 510 that defines a time length equal to the time length of the missed monitoring interval 602.

[0064] FIG. 7 illustrates two exemplary timeline diagrams illustrating operations performed by the monitoring interval tracker 222 using the daily approval role rules to generate one or more DOS, interval extensions, and / or new monitoring intervals. For example, in a first exemplary scenario 700, the monitoring interval tracker 222 may generate a first monitoring interval 502. A "success" is defined when a medical record report 702 and an approval date 704 of the medical record report 702 are generated during the first monitoring interval 502 (i.e., before the end date 506 of the first monitoring interval 502). In response to the success, the monitoring interval tracker 222 generates a DOS as the end date 506 and generates a second monitoring interval 508. However, if the approval date does not occur before date 506 (as shown in the first exemplary scenario 700), a "failure" occurs and the monitoring interval tracker 222 generates an interval extension 514 to extend the first monitoring interval 502 by one day until the approval date 704 occurs. The monitoring interval tracker 222 generates a DOS for the first monitoring interval as the approval date 704 (i.e., the extended end date 516) and generates a second monitoring interval 508 that is effective subsequent to the first monitoring interval 502. The second monitoring interval 508 has a second end date 510 that defines a length of time equal to the length of time of the first monitoring interval 502 before the interval extension 514 is added. In a second exemplary scenario 706, the first monitoring interval 502 is defined as "successful" by the daily approval roll rule because the first medical record report 708 is created before the end date 506 and the first approval date 710 of the first medical record report occurs before the end date 506. Therefore, the DOS criteria for the first monitoring interval 502 is met, a first DOS is generated as the end date 506, and the second monitoring interval 508 is generated. A second transmission 712 is received during the second monitoring interval 508 (i.e., before the second end date 510) and a second medical record report 714 is generated during the second monitoring interval 508 (i.e., before the second end date 510) for the second transmission 712. However, because an acknowledgement date for the second monitoring interval 508 is not received before the second end date 510, the monitoring interval tracker 222 generates an interval extension 514 for the second monitoring interval 508 until a second acknowledgement date 716 occurs during the second monitoring interval 508 that meets the DOS criteria.Thus, the monitoring interval tracker 222 generates a second DOS as the second approval date 716 (i.e., the extended end date 516) of the second monitoring interval 508 and generates a third monitoring interval 718 that may have a length of time the same as the second monitoring interval 508 before the interval extension 514.

[0065] 8 illustrates two exemplary timeline diagrams illustrating operations performed by the monitoring interval tracker 222 using the daily approval role rules to generate one or more DOS, interval extensions, and / or new monitoring intervals. For example, in a first exemplary scenario 800, the monitoring interval tracker 222 may generate a first monitoring interval 502. A "success" occurs because the first transmission data 504, the first medical record report 708 of the first transmission, and the first approval date 710 of the first medical record report 708 are generated during the first monitoring interval 502 (i.e., before the end date 506 of the first monitoring interval 502). Additionally, the second transmission data 712, the third transmission data 802, and the second medical record report 714 (e.g., for the second transmission data 712 or the third transmission data 802) may occur during the first monitoring interval 502 before the end date 506. The second medical record report 714 may lack a second acknowledgement date 716 within the first monitoring interval (i.e., prior to the end date 506). However, because the DOS criteria are met for at least the first transmitted data 504, a DOS is generated for the first monitoring interval 502 at the end date 506 without interval extension, regardless of the second acknowledgement date 716 not occurring within the first monitoring interval 502. Although the second acknowledgement date 716 may occur within the second monitoring interval 508, because the second acknowledgement date 716 is for the second medical record report 714 at the prior first monitoring interval 502, the second acknowledgement date 716 will not trigger a DOS for the second monitoring interval 508 (the second acknowledgement date 716 alone does not meet the DOS criteria for the second monitoring interval 508 without the corresponding transmitted data or medical record report at the second monitoring interval 508). In a second example scenario 804, the first transmission data 504, the second transmission data 712, and the third transmission data 802 may be received during the first monitoring interval 502. A first medical record report 708 may be generated for the first transmission data 504, and a second medical record report 714 may be generated for the third transmission data 802.Once the end date 506 occurs, because acknowledgments for the first medical record report 708 and the second medical record report 714 have not yet been received, the monitoring interval tracker 222 generates an interval extension 514 for each day until the first acknowledgment date 710 is received, and a DOS is generated for the first acknowledgment date 710 (i.e., extended end date 506). A second acknowledgment date 716 may also be received for the extended end date 516 as well, but since the first acknowledgment date 710 already met the DOS criteria for the first monitoring interval 504, the second acknowledgment date 716 does not affect the DOS calculation for the first monitoring interval 504.

[0066] 9 illustrates two exemplary timeline diagrams illustrating operations performed by the monitoring interval tracker 222 using the daily approval role rules to generate one or more DOS, interval extensions, and / or new monitoring intervals. For example, in a first exemplary scenario 900, a first transmission data 504 and a first medical record report 708 for the first transmission data 504 may be received during the first monitoring interval 502. The monitoring interval tracker 222 may generate an interval extension 514 based on the absence of a first approval date 710 prior to the first end date 506. A second transmission data 712 and a third transmission data 802 may be received during the interval extension 514 of the first monitoring interval 502. A second medical record report 714 may be generated for the second transmission data 712, and a third medical record report 902 may be generated for the third transmission data 802 during the interval extension 514. The interval extension 514 may extend the first monitoring interval by days until the first approval date 710 is received and a DOS is generated as the first approval date 710 (i.e., the extended end date 506). The second approval date 716 of the second medical record report 714 and the third approval date 904 of the third medical record report 902 may occur during the second monitoring interval 508. Additionally, the fourth transmission data 906 and the fourth medical record report 908 may occur during the second monitoring interval 508. However, the DOS criteria for the second monitoring interval 508 are not yet met because the second approval date 716 and the third approval date 904 do not correspond to the fourth transmission data 906 or the fourth medical record report 908 (which occurred during the second monitoring interval 508), but correspond to the second medical record report 714 and the third medical record report 902 (which occurred during the first monitoring interval 502 and / or during the interval extension 514 of the first monitoring interval). According to the daily approval roll rule, the approval date and / or transmission date of the medical record occurring in the previous monitoring interval do not meet the DOS criteria for the current monitoring interval. In a second exemplary scenario 910, the first transmission data 504 and the first medical record report 708 for the first transmission data 504 may be received during the first monitoring interval 504.The monitoring interval tracker 222 may generate an interval extension 514 based on the absence of a first acknowledgement date 710 prior to the first end date 506. A second transmission 712 may occur during the interval extension 514. The first acknowledgement date 710 may occur on the extended end date 516 that may satisfy the DOS criteria for the first monitoring interval 502, causing the monitoring interval tracker to generate a DOS for the first monitoring interval 502 and generate a second monitoring interval 508. Although the second transmission 712 may not have received a reported medical record or acknowledgement, it will not affect the DOS for the first monitoring interval because the DOS criteria have already been met by the first transmission 504, the first medical record report 708, and the first acknowledgement 704. A third transmission data 802 may be received during the second monitoring interval 508, and a second medical record report 714 may be generated during the second monitoring interval 508 and may correspond to the third transmission data 802 for the second monitoring interval 508 as well as the second transmission data 712 for the first monitoring interval (for which no medical record report was received during the first monitoring interval 502). A second approval date 716 of the second medical record report 714 may occur during the second monitoring interval 508 that meets the DOS criteria for the second monitoring interval and causes a DOS to be generated as the end date 510.

[0067] 10 illustrates two exemplary timeline diagrams illustrating operations performed by the monitoring interval tracker 222 using the daily approval roll rules to generate one or more DOS, interval extensions, and / or new monitoring intervals. For example, in a first exemplary scenario 1000, a first transmission data 504, a first medical record report 708 for the first transmission data 504, and a first approval date 710 may be received during the first monitoring interval 502. A second transmission data 712 and a second medical record report 714 may also be received during the first monitoring interval 502, but a second approval date 716 may not be received within the first monitoring interval. However, because the first transmission data 504, the first medical record report 708, and the first approval date 710 meet the DOS criteria, the first monitoring interval 502 is not extended and a DOS is generated as the first end date 506. The second transmission data 712 and the second medical record report 714 do not affect the first monitoring interval. A second acknowledgment 716 for the second medical record report 714 may be received during the second monitoring interval 508. Additionally, the third transmission data 802, the fourth transmission data 906, and the third medical record report 902 for the third transmission data 802 and / or the fourth transmission data 906 may be received during the second monitoring interval 508. However, once the second end date 510 occurs, the monitoring interval tracker 222 will generate interval extensions 514 for the second monitoring interval 508 for each day until an acknowledgment date is received, since the second acknowledgment date 716 (which occurred during the second monitoring interval 508) does not correspond to a transmission data or medical record report (e.g., the third transmission data 802, the fourth transmission data 906, or the third medical record report 902) that also occurred in the second monitoring interval 508. Rather, the second acknowledgement date 716 corresponds to the second medical record report 714 from the previous first monitoring interval 502. The DOS criteria are not met in the second monitoring interval 508. In a second example scenario 1002, the first transmission data 504 and the first medical record report 708 related to the first transmission data 504 may be received during the first monitoring interval 502.The DOS criteria are met and the monitoring interval tracker 222 generates a DOS as being the first end date 506 and generates a second monitoring interval 508 that is effective after the first monitoring interval 502. The second monitoring interval 508 has a second end date 510 that defines a length of time the same as the length of time of the first monitoring interval 502. A second transmission 712, a third transmission 802, and a fourth transmission 906 are received during the second monitoring interval 508. A second medical record report 714 for the second transmission 712 and a second approval date 716 for the second medical record report 714 are also received during the second monitoring interval 508, meeting the DOS criteria for the second monitoring interval 508. A third medical record report 902 may be received for the third transmission data 802 or the fourth transmission data 906, but the third approval date 904 of the third medical record may not be received before the second end date 510 of the second monitoring interval 508. The monitoring interval tracker 222 may nevertheless generate a DOS as the second end date 510 based on the DOS criteria previously met by the second approval date 716, the second medical record report 714, and the second transmission data 712. Although the third approval date 904 may be received during the third monitoring interval 718, the third approval date 904 will not be considered for the DOS criteria of the third monitoring interval 718 because it corresponds to a medical record report from a previous monitoring interval (e.g., the third medical record report 902). Nevertheless, the fifth transmission data 1002, the fourth medical record report 1004 for the fifth transmission data 1002, and the fourth approval date 1006 for the fourth medical record report 1004 may still be generated during the third monitoring interval 718, such that the DOS criteria are met for the third monitoring interval 718, no interval extension is required, and the DOS for the third monitoring interval 718 is generated as the third end date 1008 for the third monitoring interval. Upon generating the DOS for the third monitoring interval 718, the monitoring interval tracker 222 may also generate a fourth monitoring interval 1010. In the fourth monitoring interval, the sixth transmission data 1012 and the fifth medical record report 1014 for the sixth transmission data 1012 may be received.Because the fourth end date of the fourth monitoring interval 1010 may occur without receiving an approval date corresponding to the fifth medical record report 1014, the monitoring interval tracker 222 may generate a day-by-day interval extension 514 for the fourth monitoring interval 1010 in accordance with the day-by-day approval roll rules until an approval date for the fifth medical record report 1014 is received and the DOS criteria are met for the fourth monitoring interval 1010.

[0068] 11 illustrates an exemplary timeline diagram illustrating operations performed by the monitoring interval tracker 222 using the daily approval roll rules to generate one or more DOS, interval extensions, and / or new monitoring intervals. For example, in an exemplary scenario 1100, a first transmission data 504 and a first medical record report 708 related to the first transmission data 504 are received during a first monitoring interval. However, because the DOS criteria are not met upon occurrence of a first end date 506, the monitoring interval tracker 222 generates an interval extension 514 to the first monitoring interval 502 until a first approval date 710 is received. A DOS may be generated for the first monitoring interval 502 as a first approval date (i.e., an extended end date 516), a second monitoring interval 508 is generated, and the first approval date 710 may be received during the first monitoring interval 502. During the second monitoring interval 508, the monitoring interval tracker 222 may receive the second transmission data 712, the third transmission data 802, and the third medical record report 902 related to the second transmission data 712 and / or the third transmission data 802. When the second end date 510 of the second monitoring interval 508 occurs, the acknowledgement dates for the second medical record report 714 and the third medical record report 902 have not yet been received, so the monitoring interval tracker generates a second interval extension 1102 for the second monitoring interval 508 and extends the second monitoring interval by days until the second acknowledgement date 716 is received. Upon receiving the second acknowledgement date 716, the monitoring interval tracker determines that the DOS criteria for the second monitoring interval have been met and generates a DOS as the second acknowledgement date 716. A third approval date 904 of the third medical record report 902 may also be received on the second approval date 716, but the third approval date and the third medical record report do not affect the DOS of the second monitoring interval 508 because the DOS criteria for the second monitoring interval 508 have already been met by the second approval date 716, the second medical record report 714, and the second transmitted data 712. In response to generating the DOS for the second monitoring interval 508, the monitoring interval tracker 22 generates a third monitoring interval 718 having a length of time determined by the patient care modality rules.

[0069] In some examples, any of the exemplary scenarios shown in FIGS. 5-11 may be implemented simultaneously with other exemplary scenarios to simultaneously represent different monitoring intervals of different patient care modalities. For example, the first exemplary scenario 700 may represent a heart failure care modality, while the second exemplary scenario 706 may represent a remote monitoring therapy modality. Thus, the monitoring intervals of the first exemplary scenario 700 may have a time length of 31 days, while the monitoring intervals of the second exemplary scenario 706 may have a time length of 91 days. A single transmission data (e.g., the first transmission data 504) may be included in multiple simultaneously implemented monitoring intervals, such as each monitoring interval of each type of patient care modality. Separate charting reports and approval dates may be required for the different patient care modalities when the first transmission data 504 is received, such that DOS criteria for one patient care modality (e.g., heart failure care modality) may be met but DOS criteria for another patient care modality (e.g., remote monitoring care modality) may not be met even though both simultaneously implemented monitoring intervals are tracking the same transmission data. The ability to track different patient care modalities having different lengths of time independently of one another for a single transmission of data from a single cardiac monitoring device greatly improves the efficiency of patient care tracking, patient tracking management, and reduction of missed monitoring intervals and tracking failures, especially when the system is expanded to manage hundreds or thousands of different patients with hundreds or thousands of different cardiac monitoring devices, each with their own transmission rates and different patient care modality combinations.

[0070] 12 illustrates an example flowchart of operations performed by the monitoring interval tracker 222 to manage a cardiac monitoring device, e.g., to generate one or more DOS, interval extensions, and / or new monitoring intervals, as discussed above. The monitoring interval tracker 222 may receive incoming transmission data 1202 representing a transmission from a cardiac monitoring device. The monitoring interval tracker 222 may receive or generate a receipt date timestamp indicating a receipt date of the transmission data 1202. The monitoring interval tracker 222 may classify the transmission data 1202 into one or more patient care modality rules, e.g., an in-hospital care modality 1204, a remote monitoring care modality 1206, and / or a heart failure care modality 1208 (e.g., by comparing a patient identifier, a cardiac device identifier, or other information from the incoming transmission data to information stored in one or more databases). If the incoming outgoing data 1202 corresponds to a remote monitoring care modality 1206 and / or a heart failure care modality 1208, the monitoring interval tracker 222 may calculate whether the receipt date is more than 10 or 30 days after the embedding date associated with the cardiac monitoring device (e.g., the association stored in one or more databases 110). If no, the monitoring interval tracker 222 may determine to do nothing (i.e., omit generating a response to the outgoing data), but if the incoming outgoing data 1202 further corresponds to a remote monitoring care modality 1206 and a "per interval" extension rule (e.g., per interval roll transmit rule), the monitoring interval tracker 222 may determine to generate a new monitoring interval with a new end date (e.g., predicted DOS). If the monitoring interval tracker calculates that the receipt date is more than 10 or 30 days after the embedding date, the monitoring interval tracker 222 may begin calculating whether "today" (i.e., the receipt date) is more than the end date (e.g., the predicted DOS of the monitoring interval). Similarly, if the transmitted data 1202 is classified under an in-hospital care style 1204, the monitoring interval tracker 222 may proceed directly to calculating whether "today" (i.e., the date of receipt) is later than the end date (e.g., the predicted DOS of the monitoring interval).If "no", the monitoring interval tracker 222 may determine to do nothing (i.e., omit generating a response to the outgoing data), but if the incoming outgoing data 1202 further corresponds to a remote monitoring care modality 1206 and an "interval by interval" extension rule (e.g., an interval by interval roll transmission rule), the monitoring interval tracker 222 may determine to generate a new monitoring interval with a new end date (e.g., predicted DOS). If "yes", i.e., if the monitoring interval tracker 222 calculates that "today" (i.e., the date of receipt) is actually later than the end date (e.g., the predicted DOS of the monitoring interval), the monitoring interval tracker may access and / or use the interval extension rules 404 for the monitoring interval accordingly. If the monitoring interval tracker 222 accesses and / or uses a "day by day" extension rule (e.g., a daily send roll rule or a daily acknowledge roll rule), the monitoring interval tracker 222 may proceed to determine if the DOS criteria for the current monitoring interval have been met, and if "yes," generate a new monitoring interval with a new end date (e.g., a predicted DOS) that is the previous DOS of the current monitoring interval plus a length of time based on the patient care modality rule (e.g., 1 year for in-hospital care modality 1204, 91 days for remote monitoring care modality 1206, and / or 31 days for heart failure care modality 1208). If "no," i.e., if the monitoring interval tracker 222 determines that the DOS criteria have not been met while using the "day by day" rule, the monitoring interval tracker 222 may continue to extend the current monitoring interval by days until the DOS criteria are met. If the monitoring interval tracker 222 has access to and uses the "per interval" rules, the monitoring interval may generate a new monitoring interval by calculating a new end date (e.g., predicted DOS) for the new monitoring interval that is "today" (i.e., date received) plus a length of time based on the patient care modality rules (e.g., 1 year for in-hospital care modality 1204, 91 days for remote monitoring care modality 1206 and / or 31 days for heart failure care modality 1208). If the monitoring interval tracker 222 determines that the DOS criteria are met, the monitoring interval tracker 222 may further generate a DOS for the current monitoring interval that is "today" (i.e., date received).In some examples, when the first medical record is approved for a monitoring interval, a DOS may be generated for all medical records within the monitoring interval, including any subsequent medical records within the same monitoring interval.

[0071] In some cases, calculations performed by the monitoring interval tracker 222 may determine one or more states of a monitoring interval and / or associate a state with the monitoring interval (e.g., for reporting and / or visualization via the monitoring interval visualizer 410 and / or transmission dashboard 412, as discussed in further detail below). For example, a monitoring interval of a remote monitoring care modality 1206 may be associated with one or more states including a transmission required state (when no transmission data is received during the monitoring interval), a medical record report required state (when no medical record report is generated during the monitoring interval), an approval required state (when there is no approval for a medical record report received during the monitoring interval), or a met state (when DOS criteria are met). A monitoring interval of the heart failure care form 1208 may be associated with one or more states including a transmission required state (if no transmission data is received during the monitoring interval), an opinion required state (if no opinion on the transmission data is received), a medical record report required state (if no medical record report is generated during the monitoring interval), an approval required state (if there is no approval on the medical record report received during the monitoring interval), or a met state (if the DOS criteria are met). A monitoring interval of the in-hospital care form 1204 may be associated with one or more states including a hospital visit required state (if no transmission data is received from a hospital visit during the monitoring interval), a medical record report required state (if no medical record report is generated during the monitoring interval), an approval required state (if there is no approval on the medical record report received during the monitoring interval), or a met state (if the DOS criteria are met).

[0072] 13-19, various examples of portals or user interfaces are provided for accessing, analyzing, viewing, or otherwise managing information and data received at the medical device platform 204 from cardiac monitoring devices and / or generated by the monitoring interval tracker 222. The user interfaces may be displayed on a user device 108, such as the devices described above in connection with FIG. 1. The various user interfaces displayed on the user device 108 may be accessed by the user device over the network 106 and executed by one or more servers 112 of the network environment 100. Additionally, one or more medical devices 104, such as one or more cardiac monitoring devices and / or implantable medical devices from one or more patients, may provide information or other operational data to the medical device manager 102 for storage in the database 110. For example, utilizing the Health Level 7 (HL7) protocol, the medical device manager 102 may receive communications from a device manufacturer remote transmission including device field of equipment and / or patient specific data and device type and model. This information may then be processed in a variety of ways by the monitoring interval tracker 222, as discussed above, and presented and managed by a user via a user interface, thus enabling a user (such as a nurse or doctor at a clinic) to receive, access, analyze, and / or manage data from one or more medical devices 104 on a patient-by-patient or across multiple patients in ways not previously available.

[0073] As described herein, the medical device manager 102 manages CIED device transmission and interviews, including both in-house and remote interviews. In one implementation, the in-house interview utilizes an in-house upload interface generated by the medical device manager 102, using which a user may drop or select one or more files for import. The files may be accessed over a network, via memory (e.g., flash drive), etc. Once a file is selected, the interface may generate a visualization of the upload progress as the medical device manager 102 processes the interview data. In one implementation, an in-house interface may be generated and used to verify, add, or edit contact information, including but not limited to contact date, patient name, patient date of birth, clinic name, device manufacturer, device type, device serial number, corresponding to the data extraction. If data is missing, the user may enter the data through the in-house interface. The medical device manager 102 may determine if the patient is a new or existing patient and proceed accordingly. Multiple visualizations are provided through the interface, including the progress of the processing of the interview data, options to proceed, edit or cancel, and the progress of uploading the data to the medical device manager 102. The user may be further provided with an option to upload an associated PDF from the interview. During processing and uploading, the data file is parsed and individual data is imported from the parsed data file. Upon import, the user may add, edit and review the imported data through the user interface. If a PDF is imported, the PDF may be presented with the imported data or accessible through the interface. The imported data may be automatically or manually saved. If the submission is associated with an existing patient, a set of key identifiers are matched. The patient record indicates that the in-hospital submission (if any) is added to the stack of in-hospital interviews.If only a remote transmission stack exists or if there is no current in-house interview stack, the medical device manager 102 creates a new medical record instance. Thus, the medical device manager 102 may create and track a workflow for an in-house interview separate from a remote interview. Thus, the medical device manager 102 may create an in-house medical record and a remote medical record, with the in-house medical record including unique CPT and ICD-10 codes. In some examples, the medical device manager 102 generates a report (e.g., a medical record) documenting the review of the patient's in-house interview and the technician's impressions and the provider's approval. This report is generated by the medical device manager 102 for an in-house or remote interview by combining the patient information, the unique medical history presentation, the submitted PDF file if attached by the reviewer, etc. The report is generated in the cloud by the medical device manager 102 and may be stored, packaged, or made available as a PDF download. Any of this information may be sent to the monitoring interval tracker 222 to perform the operations herein. Additionally, based on the output of the operations, the monitoring interval tracker 222 may generate a monitoring interval visualizer 410 and / or a transmission dashboard 412, as discussed in more detail below.

[0074] 13 illustrates an exemplary monitoring interval visualizer 410. In general, the monitoring interval visualizer 410 provides a graphical representation of multiple monitoring intervals with data and data management options that may be a user-specific portal to a user role (such as a nurse or doctor in a clinic, or a patient analyzing their own device data). Thus, the data management options displayed in the monitoring interval visualizer may change or be different depending on the role of the user accessing the user interface. The medical device manager 102 may determine the style and / or content of the monitoring interval visualizer 410 based on login information provided to the system by the user upon accessing the system. Other interfaces, discussed in more detail below, may or may not be available to a particular user based on substantially the same identification information.

[0075] In the particular example shown in FIG. 13 , the monitoring interval visualizer 410 may include a first portion 1302 for presenting multiple timelines. For example, a first timeline may correspond to an in-hospital care modality 1204, a second timeline may correspond to a remote monitoring care modality 1206, and / or a third timeline may correspond to a heart failure care modality 1208. Additionally, a fourth timeline representing one or more receipt dates of transmission data may be presented in the first portion 1302. The monitoring intervals may be presented as one or more shapes, such as blocks, on the multiple timelines. Multiple interactive and / or selectable indicators, such as graphic elements or icons, may be presented on the multiple timelines to represent receipt dates of transmission-related data, including transmission data. For example, a rectangle on the timeline may represent a medical record report (e.g., a creation date of the medical record report), and a check mark within the rectangle may indicate that the medical record report has been approved (e.g., associated with an approval timestamp). The blocks may be color coded such that a first color indicates that the DOS criterion is met and / or a second color indicates that the DOS criterion is not met. In some examples, the first portion 1302 may present one or more action call indicators 1304 alongside the multiple timelines. The action call indicators may correspond to a patient care modality and therefore may be in the same row as timelines that correspond to the same patient care modality. The monitoring interval tracker 222 may determine a status of the current monitoring interval for each timeline, such as whether a DOS criterion is met, and if the monitoring interval tracker 222 determines that a particular DOS criterion is not met, it may indicate the status of the monitoring interval and present an action call indicator that corresponds to the particular DOS criterion that is not met. For example, a first action call indicator may indicate that a medical record report is required for a particular patient care modality (e.g., a heart failure care modality). Additionally or alternatively, the action required indicator 1304 may indicate that transmission data is required for the current monitoring interval, that medical record report approval is required for the current monitoring interval, and / or that DOS criteria have been met for the current monitoring interval.

[0076] In some examples, the interactive indicators and / or selectable indicators of the first portion 1302 may provide additional transmission-related information in response to a user input or selection, such as clicking on or hovering a cursor over the interactive indicators and / or selectable indicators. For example, a second portion 1306 (e.g., positioned below the first portion 1302 on the display of the user device 108) may present transmission-related information corresponding to a user input in the first portion 1302. In response to a selection of a particular monitoring interval, the second portion 1306 may include an indication of the patient's name associated with the selected monitoring interval, the patient's age, the patient's date of birth, the name of the attending physician, and / or the number of transmissions that occurred during the selected monitoring interval. The second portion 1306 may include a transmission sidebar 1308 presenting selectable transmission indicators representing transmissions and / or transmission dates for the selected monitoring interval. Upon receiving user input at the selectable transmission indicators, the second portion 1306 may present additional information corresponding to the particular transmission represented by the selectable transmission indicator, such as medical record reports and past impressions regarding the transmissions, the patient's records, cardiac monitoring device details, etc. The second portion 1306 may include one or more display windows 1310 for displaying transmission-related information corresponding to user input in the first portion 1302 and / or the transmission sidebar 1308. In some cases, the second portion 1306 may present a completed medical record report for a monitoring interval for which DOS criteria have been met. In some examples, upon receiving a selection of a monitoring interval for which DOS criteria have not yet been met, the second portion 1306 may present an interval report summarizing the transmissions, impressions, plans, and physician notes contained within the monitoring interval. Interval reports may be automatically generated for each type of patient care modality, i.e., without the need for approval. The interval report may indicate diagnosis information (e.g., indicating a "stable" or "improving" status for a heart failure diagnosis) and / or which information is awaiting approval (e.g., has a "pending" status) or has received approval from a physician (e.g., has an "approved" status). In some cases, the monitoring interval visualizer 410 may not display the DOS (eg, predicted DOS) for a monitoring interval until a medical record within the monitoring interval is acknowledged.In other examples, a predicted DOS may be displayed. In some examples, a monitoring interval may not be displayed until the first medical record of the monitoring interval is acknowledged.

[0077] 14 illustrates an exemplary monitoring interval visualizer 410 having a medical record stack window 1400 in the second portion 1306. For example, upon receiving a selection of a first portion of a particular transmission data, the second portion 1306 of the monitoring interval visualizer may present multiple medical record reports in the medical record stack window 1400 corresponding to the selected transmission data. For example, the medical record stack window may present a first medical record corresponding to the in-hospital care modality 1204, a second medical record report corresponding to the remote monitoring care modality 1206, and / or a third medical record report corresponding to the heart failure care modality 1208. The multiple medical record reports may be presented aligned with the selectable transmission indicator in the send sidebar 1308 such that the multiple medical record reports appear overlapping. Upon receiving a selection of a particular medical record report from the medical record stack window 1400 and / or the send sidebar 1308, the monitoring interval visualizer may present an unobstructed or complete version of the selected medical record report.

[0078] FIG. 15 illustrates an example monitoring interval visualizer 410 including a transmission details graph 1500 that may be presented in the first portion 1302. For example, a selectable graphic indicator may cause a list of selectable graphing options to be presented upon receiving a user input. The graphing options may include any particular value or metric included in or related to the transmission data (e.g., sensed value, impedance, pulse amplitude, pulse width, atrial fibrillation (AT) load, atrial pacing, left ventricular pacing, etc.). Upon receiving a selection of one or more of the graphing options, the monitoring interval visualizer 410 may cause a graph (e.g., a line graph, a bar graph, etc.) to be placed on the first portion 1302 (e.g., instead of a timeline) with data points defined by each transmission. The monitoring interval tracker 222 may access data stored in a transmission database (e.g., based on a timestamp and / or identifier associated with each transmission) to generate the transmission details graph 1500.

[0079] 16 illustrates an example monitoring interval setting interface 1600 for generating parameters for the monitoring interval tracker 222. The monitoring interval setting interface 1600 may present one or more input fields or selectable icons for generating parameters and / or for indicating which of the patient care modality rules 402 and / or interval extension rules 404 to use for a particular transmission. The parameters generated by the monitoring interval setting interface 1600 may be associated with a particular patient name or identifier or a particular cardiac monitoring device identifier, as the case may be, and stored in the transmission database 408. When the transmission data is received, the patient name or identifier or cardiac monitoring device identifier included in the transmission data may be matched with those stored in the transmission database 408, and the associated parameters may be retrieved and applied to the transmission data. In some examples, the monitoring interval setting interface 1600 may receive information related to the remote monitoring care modality 1206 in a first section 1602, such as opting in or out of this type of patient care modality, the interval length (e.g., 91 days or another interval length), the initial predicted DOS of the initial monitoring interval (e.g., end date), and / or whether the interval extension rules 404 are interval-by-interval or daily rules. The monitoring interval setting interface 1600 may receive information related to the heart failure monitoring care modality 1208 in a second section 1604, such as opting in or out of this type of patient care modality, the interval length (e.g., 31 days or another interval length), the initial predicted DOS of the initial monitoring interval (e.g., end date), whether the interval extension rules 404 are interval-by-interval or daily rules, and / or the International Classification of Diseases (ICD)-10 code related to the patient care. The monitoring interval setting interface 1600 may receive information related to the in-hospital care modality 1204 in a third section 1606, such as opting in or out of such patient care modality, the interval length (e.g., 365 days or another interval length), and the end date of the initial monitoring interval.In some examples, the monitoring interval setting interface 1600 may include an interactive component for creating a new configurable patient care modality with any interval length, initial interval monitoring period, initial DOS, future DOS, interval extension rules, and / or ICD-10 code, and adding the configurable patient care modality to the transmission database 408 associated with the patient. The monitoring interval setting interface 1600 may include options for selecting a patient group and / or device type class and applying specific rules, settings, and parameters to the selected patient group and / or device type class. In some examples, the monitoring interval setting interface 1600 may present options for changing a patient's patient care modality rules 402 and / or interval extension rules 404 in response to the patient changing clinics (e.g., moving from a first clinic to a second clinic).

[0080] 17 illustrates an exemplary transmission dashboard 412 for aggregating transmission-related data for a particular clinic from the transmission database 408, generating one or more transmission metrics for the particular clinic, and presenting the transmission metrics on the user device 108 for the particular clinic. For example, the transmission dashboard 412 may receive input in one or more interactive graphic elements indicating which clinical site the transmission metrics will be associated with and which patient care modality the transmission metrics will be associated with. The transmission metrics may be presented in a first section 1700 and may include an indication of the number of currently active monitoring intervals requiring transmission for the selected patient care modality, the number of transmissions requiring medical record reports for the selected patient care modality, the number of medical record reports requiring approval for the selected patient care modality, the number of currently active monitoring intervals that have met all DOS criteria for the selected patient care modality, the number of patients who have opted in to the selected patient care modality, the number of patients who have opted out of the selected patient care modality, and the number of DOS required for the selected patient care modality. In some examples, the transmission metrics may include interactive graph indicators such that upon receiving a selection or user input on the transmission metrics, additional details related to the selected transmission metrics, such as a list of patients (e.g., patients needing transmission, patients needing medical record reports, etc.) corresponding to the selected transmission metric and / or additional information related to the list of patients, are presented in a second section 1702 below the first section 1700 of the transmission dashboard. In some cases, the transmission metrics may be color coded with a first color indicating the transmission metrics required to meet the billing requirements (e.g., DOS criteria) for the currently active monitoring interval and a second color indicating the patients (e.g., listed in the second section 1702) that have met the billing requirements for the currently active monitoring interval.

[0081] 18 illustrates an exemplary transmission dashboard 412 for aggregating transmission-related data for a particular clinic from the transmission database 408, generating one or more transmission metrics for the particular clinic, and presenting the transmission metrics on the user device 108 for the particular clinic. The transmission dashboard 412 may help the clinic see and understand the steps required to meet DOS criteria for the currently active monitoring interval and how the particular clinic is tracking overall regarding monitoring compliance and patients who have met billing criteria. The transmission metrics may be sorted by type of patient care modality (e.g., based on a common clinic identifier associated with multiple transmissions), as well as by clinic, by site (e.g., via user input in one or more interactive graphical elements such as drop-down menus, text fields, selectable icons, slide bars, etc.), by equipment type, and by date of service. The submission metrics may include one or more of the following: number of DOS passed or extended, number of patients without DOS (including patients who have not opted in to any patient care modality tracking), number of actions required within 10 days, number of actions required after 11 days, and / or an indication of the number of monitoring intervals in which DOS criteria have been met and are waiting for DOS to occur. Additionally, the submission dashboard may provide patient filtering to generate a list of patients categorized by number of days until predicted DOS (e.g., end date), by status (e.g., DOS criteria met, medical record report approval required, no medical record report, no DOS, no submission, and / or DOS passed or extended), and / or by entry of patient name.

[0082] 19 illustrates a billing report dashboard 1900 that may be generated by the monitoring interval tracker 222. The billing report dashboard may present one or more transmission metrics related to the DOS criteria, such as the number of monitoring intervals without medical record reports, the number of monitoring intervals with medical record reports that require approval, and / or the number of monitoring intervals that are billable because the DOS criteria have been met. The billing report dashboard 1900 may include a first section 1902 that presents one or more interactive filters for receiving user input (e.g., clinic, site, device type, patient care modality, start date, and / or end date) that are the basis for the transmission metrics related to the DOS criteria. The first section 1902 may present the transmission metrics related to the DOS criteria as interactive indicators (e.g., selectable blocks) that, when selected, present additional information related to the transmission metrics in a second section 1904 below the first section. For example, upon receiving user input on a billable monitoring interval indicator, the second section may present a list of monitoring intervals including additional information related to the monitoring intervals, such as clinic name, patient name, DOS, patient care modality, status, matching dates, and / or first approval date. Upon receiving the input, the billing report dashboard may present one or more interactive elements to convert the transmission metrics into one or more billing reports (e.g., downloadable, transmittable, and / or printable) to indicate whether the patient's monitoring interval is currently billable and what actions are required to meet the DOS criteria to make the patient's monitoring interval billable. The billing reports may be generated weekly or based on user input selecting the frequency at which to generate the billable reports. The data for the billing reports (e.g., transmission metrics) may be generated as a downloadable spreadsheet.The billing report may be a downloadable report that includes the patient's name, date of birth, medical record number (MRN), device type, device model, device implant date, monitoring interval start and end dates, opt-in to type of patient care modality (e.g., in-hospital care modality 1204, remote monitoring care modality 1206, and / or heart failure care modality 1208), provider authorization, authorization date, specialty and technical CPT codes and / or ICD-10 codes. In some cases, the billing report generator may take into account many of the variables discussed herein and may verify that DOS criteria have been met in order for the patient's name to appear on the billing report. This results in only one billing report being generated per monitoring interval per patient, reducing the time a clinic spends tracking such related data. In some instances, recognizing the first authorization date of a monitoring interval (rather than subsequent authorization dates) as meeting the DOS criteria provides an additional assurance of compliance in knowing that the billing requirements for that monitoring interval have been met. The billing report dashboard 1900 may output one or more reports (e.g., showing transmission metrics), such as billing reports and / or patient care reports indicating practical and / or retroactive actions the clinic can take to ensure compliance (e.g., that DOS criteria for the monitoring interval have been met).

[0083] In some examples, the actions performed by the monitoring interval tracker 222 to generate the monitoring interval visualizer 410, transmission dashboard 412, and / or billing report dashboard may result in visualization of data trends, levels of completed and pending care, and workflow actions in a graphical interface that can simplify complex data and parameters into potentially millions of unique combinations. Additionally, generating the visualization may provide a "compliance to-do list" that describes what actions need to be performed for each type of patient care modality to meet DOS criteria for the currently active monitoring interval.

[0084] Various non-limiting, exemplary embodiments of the monitoring interval tracker 222, the monitoring interval visualizer 410, the transmission dashboard 412, and / or other components of the medical device platform 204 are discussed below.

[0085] In some cases, a method for managing a cardiac monitoring device may include determining a monitoring interval associated with the cardiac monitoring device, presenting on a display blocks representing the monitoring intervals on one or more timelines corresponding to one or more patient care modes, accessing transmitted data originating from the cardiac monitoring device, presenting on the one or more timelines one or more icons including a transmission icon representing a receipt date of the transmitted data and a medical record icon corresponding to the transmitted data, receiving one or more inputs indicating at least an approval date of a medical record report associated with the medical record icon, and determining a date of operation (DOS) for the transmitted data based at least in part on the receipt date, the one or more patient care modes, and the approval date.

[0086] Additionally, the one or more timelines may include multiple timelines presented simultaneously on the display and extending horizontally, the multiple timelines including a first timeline corresponding to an in-hospital care mode of the one or more patient care modes, a second timeline corresponding to a heart failure care mode of the one or more patient care modes, a third timeline corresponding to a remote monitoring care mode of the one or more patient care modes, and a fourth timeline corresponding to transmissions from a cardiac monitoring device.

[0087] Further, a first timeline may represent the monitoring interval as one or more one-year blocks, a second timeline may represent the monitoring interval as one or more 31-day blocks, and a third timeline may represent the monitoring interval as 91-day blocks.

[0088] Further, receiving the one or more inputs may include receiving a first input providing an opinion of the medical record report and receiving a second input providing an approval of the medical record report, and the one or more icons may include a first indication of the opinion and a second indication of the approval.

[0089] Additionally, the method may further comprise presenting on the display one or more input elements for registering a patient associated with the cardiac monitoring device, the one or more input elements including one or more of: a first selectable icon for indicating a particular patient care mode of the one or more patient care modes, a second selectable icon for indicating an interval extension rule, a first input field for indicating a length of the monitoring interval, and a second input field for indicating a date of operation.

[0090] Additionally, the receipt date may occur after expiration of the monitoring interval, and the method may further include generating an extension of the monitoring interval based at least in part on the receipt date that occurred after expiration of the monitoring interval and based at least in part on the interval extension rule.

[0091] Additionally, the method may further include determining, based at least in part on one or more patient care modes, that the interval extension rules extend the monitoring interval on a daily basis until approval is received.

[0092] Additionally, the blocks may include a first block, and the method may further include determining, based at least in part on the one or more patient care modes, that the interval extension rule adds an extended monitoring interval represented by a second block having the same length as the first block representing the monitoring interval when the receipt date is outside the monitoring interval.

[0093] Additionally, the monitoring interval may include a first monitoring interval and the transmitted data may include the first transmitted data. The method may further include presenting one or more action request icons next to the one or more timelines indicating at least one of: a second monitoring interval requiring second transmitted data, a third transmitted data corresponding to a heart failure care mode requiring an opinion, a patient associated with an in-hospital care mode requiring a hospital visit, or a fourth transmitted data corresponding to a heart failure care mode, an in-hospital care mode, or a remote monitoring care mode requiring a medical record report.

[0094] Additionally, the method may further include receiving a selection of the medical record icon and, in response at least in part to the selection of the medical record icon, presenting one or more medical record reports associated with the transmitted data on the display beneath one or more timelines.

[0095] In some cases, a method for managing a cardiac monitoring device may include determining a number of monitoring intervals associated with the cardiac monitoring device; presenting on a display a series of blocks representing the number of monitoring intervals on a timeline, where one block of the series of blocks has a length based on a patient care mode corresponding to the timeline; accessing transmitted data originating from the cardiac monitoring device; presenting on the timeline one or more icons including a transmit icon representing a receipt date of the transmitted data and a medical record icon corresponding to the transmitted data; and determining a date of business (DOS) for the transmitted data based at least in part on the receipt date, the patient care mode, and the approval date.

[0096] Additionally, the method may further include receiving a selection of a block representing a monitoring interval of the plurality of monitoring intervals, and presenting an interval report, at least in part in response to the selection of the block, where the monitoring interval is an interval report indicating completed monitoring intervals and historical information related to the completed monitoring intervals, or an interval report indicating valid monitoring intervals and any required approvals that are pending.

[0097] Additionally, the method may further comprise presenting on the display one or more input elements for generating a transmission report to the clinic, the one or more input elements corresponding to a mode of care, a point of care, or days until DOS.

[0098] Additionally, the method may further include receiving input at one or more input elements and presenting at the display, at least in part in response to the input, one or more transmission-related metrics representative of aggregated transmission data for the clinic.

[0099] Additionally, the one or more transmission related metrics may further include one or more of the number of monitoring intervals waiting to receive a transmission, the number of transmissions waiting to receive a medical record report, the number of medical record reports waiting for approval, the number of monitoring intervals completed, the number of patients who have opted in to the patient care mode, the number of patients who have opted out of the patient care mode, and the number of monitoring intervals requiring DOS.

[0100] Additionally, the method may further include receiving a selection of a monitoring report icon presented in a sidebar on the display, and the step of presenting one or more input elements for generating the transmission report is at least partially in response to the selection of the monitoring report icon.

[0101] Additionally, the method may further include presenting on the display a DOS analysis dashboard including one or more filter input elements corresponding to a clinic, a site of care, a mode of care, a type of cardiac monitoring device, a date of operation, days to DOS, a monitoring interval status, or a patient name; receiving input at the one or more filter input elements; and presenting on the display one or more DOS-related metrics representative of the aggregated DOS data based at least in part on the receiving of the input at the one or more filter input elements.

[0102] Additionally, the DOS related metrics may include one or more of the number of monitoring intervals that passed DOS or were missing DOS, the number of monitoring intervals that required action within 10 days, the number of monitoring intervals that required action after 11 days, and the number of monitoring intervals that met the DOS criteria.

[0103] Additionally, the method may further include presenting on the display a billing report dashboard for completed monitoring intervals including one or more filter input elements corresponding to a clinic, a clinical site, a cardiac monitoring device type, a mode of care, a date range, a DOS, or a patient name; receiving input at the one or more filter input elements; and presenting on the display one or more of an indication of a number of monitoring intervals requiring medical record reports, a number of medical record reports requiring approval, or a number of monitoring intervals ready for billing based at least in part on receiving input at the one or more filter input elements.

[0104] In some cases, a method of managing a cardiac monitoring device includes determining a first monitoring interval associated with the cardiac monitoring device, the first monitoring interval having a first length corresponding to a first patient care mode, determining a second monitoring interval associated with the patient, the second monitoring interval having a second length corresponding to a second patient care mode, displaying on a display the first monitoring interval as a first block on a first timeline corresponding to the first patient care mode and simultaneously displaying the second monitoring interval as a second block on a second timeline corresponding to the second patient care mode, and accessing transmission data originating from the cardiac monitoring device. presenting one or more transmission icons representing one or more receipt dates of the transmitted data on a third timeline corresponding to the transmission; presenting a first medical record icon corresponding to the transmitted data on the first timeline; presenting a second medical record icon corresponding to the transmitted data on the second timeline; receiving one or more inputs indicating at least an approval date of a medical record report associated with the first medical record icon or the second medical record icon; and determining a date of business (DOS) of the transmitted data based at least in part on the one or more receipt dates and approval dates.

[0105] 20, a detailed description of an exemplary computing system 2000 having one or more computing units that may implement the various systems and methods discussed herein is provided. The computing system 2000 may be applicable to computing or network devices, including the medical device manager 102 and / or the user computing devices 108. It will be appreciated that specific implementations of such devices may be in different possible specific computing architectures, not all of which are specifically discussed herein, but which will be understood by those skilled in the art.

[0106] Computer system 2000 may be a computing system capable of executing computer program products to perform computer processes. Data files and program files may be input to computer system 2000. Computer system 2000 reads the files and executes the programs therein. Some of the elements of computer system 2000 are shown in FIG. 20, including one or more hardware processors 2002, one or more data storage devices 2004, one or more memory devices 2006, and / or one or more ports 2008-2010. Additionally, other elements may be included in computing system 2000 that will be recognized by those of ordinary skill in the art, but are not explicitly shown in FIG. 20 or further discussed herein. Various elements of computer system 2000 may communicate with each other via one or more communication buses, point-to-point communication paths, or other communication means not explicitly shown in FIG. 20.

[0107] The processor 2002 may include, for example, a central processing unit (CPU), a microprocessor, a microcontroller, a digital signal processor (DSP), and / or one or more internal level caches. There may be one or more processors 2002 such that the processor 2002 comprises a single central processing unit, or multiple processing units capable of executing instructions and performing operations in parallel with one another, commonly referred to as a parallel processing environment.

[0108] The computer system 2000 may be any other type of computer, such as a conventional computer, a distributed computer, or one or more external computers made available via a cloud computing architecture. The techniques described herein are optionally implemented in software stored in data storage device 2004, stored in memory device 2006, and / or communicated via one or more of ports 2008-2010, thereby transforming the computer system 2000 of FIG. 20 into a dedicated machine for performing the operations described herein. Examples of computer system 2000 include personal computers, terminals, workstations, mobile phones, tablets, laptops, personal computers, multimedia consoles, game consoles, set-top boxes, etc.

[0109] The one or more data storage devices 2004 may include any non-volatile data storage device capable of storing data generated or employed within the computing system 2000, such as computer executable instructions for implementing computer processes. The non-volatile data storage devices may include both application program and operating system (OS) instructions that manage the various components of the computing system 2000. The data storage devices 2004 may include, but are not limited to, magnetic disk drives, optical disk drives, solid state drives (SSDs), flash drives, and the like. The data storage devices 2004 may include removable data storage media, non-removable data storage media, and / or external storage devices made available via a wired or wireless network architecture with such computer program products, including one or more database management products, web server products, application server products, and / or other additional software components. Examples of removable data storage media include compact disc read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM), magneto-optical disks, flash drives, and the like. Examples of non-removable data storage media include internal magnetic hard disks, SSDs, and the like. The one or more memory devices 2006 may include volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM), etc.) and / or non-volatile memory (e.g., read only memory (ROM), flash memory, etc.).

[0110] A computer program product including mechanisms for implementing the systems and methods according to the techniques described herein may reside in data storage device 2004 and / or memory device 2006, referred to as a machine-readable medium. It will be appreciated that a machine-readable medium may include any tangible, non-transitory medium capable of storing or encoding instructions for performing one or more of the operations of the present disclosure that are executed by a machine, or encoding data structures and / or modules utilized by such instructions or associated with such instructions. A machine-readable medium may include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) that store one or more executable instructions or data structures.

[0111] In some implementations, computer system 2000 includes one or more ports, such as an input / output (I / O) port 2008 and a communication port 2010, for communicating with other computing devices, network devices, or vehicle devices. It will be appreciated that ports 2008-2010 may be combined or separated, and computer system 2000 may include more or fewer ports.

[0112] I / O port 2008 may be connected to I / O devices or other devices through which information is input to or output from computing system 2000. Such I / O devices may include, but are not limited to, one or more input devices, output devices, and / or environmental transducer devices.

[0113] In one implementation, an input device converts human-generated signals, such as human voice, physical movement, physical touch, or pressure, into electrical signals as input data to the computing system 2000 via the I / O port 2008. Similarly, an output device may convert electrical signals received from the computing system 2000 via the I / O port 2008 into signals that can be sensed as human output, such as sound, light, and / or touch. An input device may be an alphanumeric input device, including keys, including alphanumeric keys, for communicating information and / or command selections to the processor 2002 via the I / O port 2008. An input device may be another type of user input device, including, but not limited to, a mouse, a trackball, cursor direction keys, a joystick, and / or a wheel, direction and selection controls, one or more sensors, such as a camera, a microphone, a position sensor, an orientation sensor, a gravity sensor, an inertial sensor, and / or an accelerometer, and / or a touch-sensitive display screen ("touch screen"). The output devices may include, but are not limited to, a display, a touch screen, a speaker, a haptic and / or force sense output device, etc. In some implementations, for example in the case of a touch screen, the input device and the output device may be the same device.

[0114] The environmental transducer device converts one form of energy or signal into another form for input and output to the computing system 2000 via the I / O port 2008. For example, electrical signals generated within the computing system 2000 may be converted into other types of signals and / or vice versa. In one implementation, the environmental transducer device senses features or aspects of the environment near or remote from the computing device 2000, such as light, sound, temperature, pressure, magnetic field, electric field, chemical properties, physical movement, direction, acceleration, gravity, etc. Additionally, the environmental transducer device may generate signals that have some effect on the environment near or remote from the exemplary computing device 2000, such as the physical movement of some object (e.g., a mechanical actuator), the heating or cooling of a substance, the addition of a chemical substance, etc.

[0115] In one implementation, the communication port 2010 is connected to a network through which the computer system 2000 may receive network data useful for performing the methods and systems described herein as well as transmitting information and network configuration changes determined thereby. In other words, the communication port 2010 connects the computer system 2000 to one or more communication interface devices configured to transmit and / or receive information between the computer system 2000 and other devices via one or more wired or wireless communication networks or connections. Examples of such networks or connections include, but are not limited to, Universal Serial Bus (USB), Ethernet, Wi-Fi, Bluetooth, Near Field Communication (NFC), Long Term Evolution (LTE), etc. One or more such communication interface devices may be utilized via communication port 2010 to communicate with one or more other machines directly via a point-to-point communication path, via a wide area network (WAN) (e.g., the Internet), via a local area network (LAN), via a cellular (e.g., third generation (3G) or fourth generation (4G)) network, or via another communication means. Additionally, communication port 2010 may be in communication with an antenna or other link for transmission and / or reception of electromagnetic signals.

[0116] The system illustrated in Figure 20 is only one possible example of a computer system that may be employed or configured in accordance with aspects of the present disclosure. It will be understood that other non-transitory, tangible, computer-readable storage media that store computer-executable instructions for implementing the techniques disclosed herein on a computing system may be utilized.

[0117] In this disclosure, the disclosed methods may be implemented as a set of device readable instructions or software. Further, it is understood that the specific order or hierarchy of steps in the disclosed methods is an example of a sample approach. Based on design preferences, it is understood that the specific order or hierarchy of steps in the method can be rearranged while remaining within the scope of the disclosed subject matter. The accompanying method claims present elements of the various steps in a sample order, and are not necessarily meant to be limited to the specific order or hierarchy presented.

[0118] The described disclosure may be provided as a computer program product or software, which may include a non-transitory machine-readable medium having instructions stored thereon that may be used to program a computer system (or other electronic device) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form (e.g., software, processing application) readable by a machine (e.g., a computer). Machine-readable media include, but are not limited to, magnetic storage media, optical storage media, magneto-optical storage media, read-only memory (ROM), random access memory (RAM), erasable programmable memory (e.g., EPROM and EEPROM), flash memory, or other types of media suitable for storing electronic instructions.

[0119] Although the present disclosure has been described with reference to various implementations, it will be understood that such implementations are exemplary and that the scope of the present disclosure is not limited to the implementations. Many variations, modifications, additions, and improvements are possible. More generally, implementations according to the present disclosure have been described with reference to specific implementations. Functions may be separated differently, combined into blocks, or described with different terms in various implementations of the present disclosure. Such variations, modifications, additions, and improvements, as well as other variations, modifications, additions, and improvements, may be included within the scope of the present disclosure, as defined by the claims. The inventions disclosed herein include the following: [Aspect 1] 1. A method for managing a cardiac monitoring device, the method comprising: accessing patient care modality rules from a rules database; generating a monitoring interval associated with the cardiac monitoring device, the monitoring interval having an end date based at least in part on the patient care modality rules; accessing transmission data originating from said cardiac monitoring device, said transmission data having a date of receipt; calculating whether the received date is after the end date; generating a medical record report of the transmitted data; receiving an approval timestamp corresponding to the medical record report; calculating whether the approval timestamp indicates an approval date that is later than the end date; accessing an interval extension rule from a rules database; generating a monitoring interval extension having an extended end date based at least in part on whether the received date is after the end date or the acknowledged date is after the end date in accordance with the interval extension rule; generating a date of operation (DOS) for the transmitted data, the DOS being the extended end date of the monitoring interval extension. [Aspect 2] calculating whether the received date is later than the end date includes determining that the transmitted data has not yet been received at the occurrence of the end date; 2. The method of aspect 1, wherein generating the monitoring interval extension comprises generating a daily extension for the monitoring interval until the transmission data is received on the extended end date. [Aspect 3] 3. The method of claim 2, wherein the end date is an initial DOS prediction for the monitoring interval and the extended end date is a final DOS for the monitoring interval. [Aspect 4] calculating whether the acknowledgement date is later than the end date includes determining that the acknowledgement timestamp has not yet been received at the occurrence of the end date; 2. The method of aspect 1, wherein generating the monitoring interval extension comprises generating a daily extension for the monitoring interval until the acknowledgement timestamp occurs on the extended end date. [Aspect 5] The method of claim 4, wherein the monitoring interval comprises a first monitoring interval and the end date comprises a first end date, the method further comprising generating a second monitoring interval having a second end date based at least in part on the patient care style rule in response to the approval timestamp occurring on the extended end date. [Aspect 6] 6. The method of claim 5, wherein the medical record report is a first medical record report, the patient care modality rule is a first patient care modality rule, the approval timestamp is a first approval timestamp, the DOS is a first DOS, and the first medical record report is associated with the first patient care modality rule, the method comprising: accessing second patient care modality rules from the rules database; generating a second medical record report of the transmitted data, the second medical record report being associated with a second patient care modality rule; receiving a second approval timestamp indicating an approval date that is after the extended end date and before the second end date; determining that the second acknowledgement timestamp corresponds to the second medical record report; determining not to generate a second DOS based at least in part on the second approval timestamp corresponding to the second medical record report. [Aspect 7] the monitoring interval is a first monitoring interval, the first patient care modality rule corresponds to a heart failure care modality and indicates that the first monitoring interval is 31 days long; the second patient care modality rule corresponds to a remote monitoring care modality and indicates that a second monitoring interval is 91 days long; 7. The method of claim 6, wherein the second monitoring interval is in effect simultaneously with the first monitoring interval. [Aspect 8] 1. A method for managing a cardiac monitoring device, the method comprising: accessing a plurality of patient care modality rules from a rules database; generating a first monitoring interval associated with the cardiac monitoring device, the first monitoring interval having a first end date based at least in part on a first patient care modality rule of the plurality of patient care modality rules; generating a second monitoring interval associated with the cardiac monitoring device, the second monitoring interval having a second end date based at least in part on a second patient care modality rule of the plurality of patient care modality rules, the second end date being different from the first end date; accessing transmission data originating from said cardiac monitoring device, said transmission data having a date of receipt; generating a first medical record report for the transmitted data, the first medical record report being associated with the first patient care modality rule; generating a second medical record report for the transmitted data, the second medical record report being associated with the second patient care modality rule; receiving an approval timestamp after the receipt date indicating an approval date corresponding to only one of the first medical record report or the second medical record report; calculating whether the approval date is after the first end date; accessing an interval extension rule from the rules database; determining whether to generate a monitoring interval extension having an extended end date based at least in part on whether the approval date is later than the first end date according to the interval extension rules; generating a date of action (DOS) for the transmission data, the DOS being the approval date. [Aspect 9] calculating whether the acknowledgement date is later than the first end date includes determining that the acknowledgement timestamp has not yet been received at the occurrence of the first end date; 9. The method of aspect 8, wherein generating the monitoring interval extension comprises generating a daily extension for the first monitoring interval until the acknowledgement timestamp occurs on the extended end date. [Aspect 10] 10. The method of claim 9, further comprising: generating a third monitoring interval in response to the approval timestamp occurring on the extended end date, the third monitoring interval being effective subsequent to the first monitoring interval and having a third end date based at least in part on the first patient care modality rule. [Aspect 11] the first patient care modality rule corresponds to a heart failure care modality; the first monitoring interval having a length of 31 days before generating the monitoring interval extension; 11. The method of embodiment 10, indicating that the third monitoring interval has a length of 31 days. [Aspect 12] 12. The method of embodiment 11, wherein the second patient care modality rule corresponds to a remote monitoring care modality and indicates that the second monitoring interval has a length of 91 days. [Aspect 13] 12. The method of embodiment 11, wherein the second patient care modality rule corresponds to an in-hospital care modality and indicates that the second monitoring interval has a length of one year. [Aspect 14] the approval timestamp is a first approval timestamp, the approval date is a first approval date corresponding to the first medical record report, the DOS is a first DOS, and the method further comprises: receiving a second acknowledgment timestamp indicating a second acknowledgment date prior to the third end date of the third monitoring interval; determining that the second approval date corresponds to the second medical record report; The method of aspect 10, further comprising: omitting the step of generating a second DOS for the second approval timestamp based at least in part on the second approval date corresponding to the second medical record report and the second medical record report being prior to the extended end date. [Aspect 15] 1. A method for managing a cardiac monitoring device, the method comprising: accessing a plurality of patient care modality rules from a rules database; generating a plurality of concurrently active monitoring intervals associated with the cardiac monitoring device based at least in part on the plurality of patient-care modality rules, a first monitoring interval of the plurality of monitoring intervals having a first end date and a second monitoring interval of the plurality of monitoring intervals having a second end date that is different from the first end date; accessing transmission data originating from the cardiac monitoring device having a reception date prior to the first end date; generating a medical record report associated with the first monitoring interval or the second monitoring interval for the transmitted data; receiving an approval timestamp corresponding to the medical record report, the timestamp indicating an approval date that is later than the receipt date; calculating that the approval date is after the first end date; accessing an interval extension rule from the rules database; generating a monitoring interval extension having an extended end date based at least in part on the acknowledgement date being later than the receipt date and later than the first end date in accordance with the interval extension rule; generating a date of action (DOS) for the transmission data, the DOS being an approval date. [Aspect 16] calculating that the acknowledgement date is later than the first end date includes determining that the acknowledgement timestamp has not yet been received at the occurrence of the first end date; 16. The method of aspect 15, wherein generating the monitoring interval extension comprises generating a daily extension for the first monitoring interval until the acknowledgement timestamp occurs on the extended end date. [Aspect 17] 17. The method of claim 16, further comprising generating a third monitoring interval having a third end date based at least in part on a particular patient care style rule among the plurality of patient care style rules in response to the approval timestamp occurring on the extended end date. [Aspect 18] confirming that the DOS criterion for the first monitoring interval is met; The reception date of the transmission data is before the first end date; and the medical record report is generated for the transmitted data prior to the first end date; determining, based at least in part on, that the approval timestamp indicates that the approval date is later than the receipt date and corresponds to the medical record report; 16. The method of embodiment 15, further comprising: generating the DOS based in part on the DOS criteria being satisfied. [Aspect 19] accessing transmission-related data from a transmission database representing a plurality of transmissions originating from a plurality of cardiac monitoring devices, the transmission-related data being associated with a common clinic identifier; generating one or more transmission metrics corresponding to clinics associated with the common clinic identifier based at least in part on the transmission-related data and the common clinic identifier, the one or more transmission metrics comprising: a first number of monitor intervals to wait to receive a transmission; and a second number of monitoring intervals during which the DOS criterion is met; and a third number of monitoring intervals requiring DOS; and A fourth number of monitoring intervals for which action is required within 10 days; and The fifth number of monitoring intervals for which action is required after the 11th day; How many submissions are waiting to receive medical record reports? The number of medical record reports waiting to receive approval; a first number of patients who have opted in to a particular patient care modality; a second number of patients who opted out of the particular patient care modality; and 16. The method of aspect 15, further comprising: causing the one or more transmission metrics to be presented on a display associated with the clinic. [Aspect 20] generating a graphical representation of the plurality of monitoring intervals as interactive blocks on a plurality of simultaneously presented timelines, the plurality of simultaneously presented timelines comprising: a first timeline corresponding to a heart failure care modality and including the first monitoring interval having a length of 31 days; a second timeline corresponding to the remote monitoring care modality and including said second monitoring interval having a length of 91 days; and a third timeline corresponding to an in-hospital care modality and including a third monitoring interval having a length of one year.

Claims

1. 1. A method for managing a cardiac monitoring device, the method comprising: a computer accessing patient care mode rules from a rules database; generating a monitoring interval associated with the cardiac monitoring device, the monitoring interval having an end date based at least in part on the patient care modality rules; accessing transmission data having a date of receipt and originating from the cardiac monitoring device by the computer; the computer calculating whether the receipt date is later than the end date; generating a medical record report of the transmitted data; receiving an approval timestamp corresponding to the medical record report; the computer calculating whether the approval timestamp indicates an approval date that is later than the end date; said computer accessing an interval extension rule from a rules database; generating a monitoring interval extension having an extended end date based at least in part on whether the received date is later than the end date or based at least in part on whether the acknowledged date is later than the end date according to the interval extension rules; the computer generating a date of operation (DOS) for the transmission data, the DOS being the extended end date of the monitoring interval extension.

2. the step of the computer calculating whether the receipt date is after the end date includes the step of the computer determining that the transmission data has not yet been received at the occurrence of the end date; 2. The method of claim 1, wherein the computer generating the monitoring interval extension comprises the computer generating a daily extension for the monitoring interval until the transmission data is received on the extended end date.

3. 3. The method of claim 2, wherein the end date is an initial DOS prediction for the monitoring interval and the extended end date is a final DOS for the monitoring interval.

4. the step of the computer calculating whether the approval date is later than the end date includes the step of the computer determining that the approval timestamp has not yet been received at the occurrence of the end date; 2. The method of claim 1, wherein the computer generating the monitoring interval extension comprises the computer generating a daily extension for the monitoring interval until the acknowledgement timestamp occurs on the extended end date.

5. 5. The method of claim 4, wherein the monitoring interval comprises a first monitoring interval and the end date comprises a first end date, the method further comprising the step of the computer generating, in response to the approval timestamp occurring on the extended end date, a second monitoring interval having a second end date based at least in part on the patient care modality rules.

6. 6. The method of claim 5, wherein the medical record report is a first medical record report, the patient care modality rule is a first patient care modality rule, the approval timestamp is a first approval timestamp, the DOS is a first DOS, and the first medical record report is associated with a first patient care modality rule, the method comprising: accessing second patient care modality rules from the rules database by the computer; generating a second medical record report of the transmitted data, the second medical record report being associated with a second patient care modality rule; receiving, by the computer, a second approval timestamp indicating an approval date that is after the extended end date and before the second end date; determining, by the computer, that the second approval timestamp corresponds to the second medical record report; and determining, by the computer, not to generate a second DOS based at least in part on the second approval timestamp corresponding to the second medical record report.

7. the monitoring interval is a first monitoring interval, the first patient care modality rule corresponds to a heart failure care modality and indicates that the first monitoring interval is 31 days long; the second patient care modality rule corresponds to a remote monitoring care modality and indicates that a second monitoring interval is 91 days long; The method of claim 6 , wherein the second monitoring interval is in effect simultaneously with the first monitoring interval.

8. 1. A method for managing a cardiac monitoring device, the method comprising: accessing by the computer a plurality of patient-care modality rules from a rules database; generating, by the computer, a first monitoring interval associated with the cardiac monitoring device, the first monitoring interval having a first end date based at least in part on a first patient care modality rule of the plurality of patient care modality rules; generating, by the computer, a second monitoring interval associated with the cardiac monitoring device, the second monitoring interval having a second end date based at least in part on a second patient care style rule of the plurality of patient care style rules, the second end date being different from the first end date; accessing transmission data having a date of receipt and originating from the cardiac monitoring device by the computer; generating, by the computer, a first medical record report for the transmitted data, the first medical record report being associated with the first patient care modality rule; generating, by the computer, a second medical record report for the transmitted data, the second medical record report being associated with the second patient care modality rule; receiving an approval timestamp after the receipt date, the computer indicating an approval date corresponding to only one of the first medical record report or the second medical record report; the computer calculating whether the approval date is after the first end date; said computer accessing an interval extension rule from said rules database; determining whether the computer generates a monitoring interval extension according to the interval extension rules, the monitoring interval extension having an extended end date based at least in part on whether the approval date is later than the first end date; the computer generating a date of operation (DOS) for the transmission data, the DOS being the approval date.

9. the step of the computer calculating whether the acknowledgement date is later than the first end date includes the step of the computer determining that the acknowledgement timestamp has not yet been received at the occurrence of the first end date; 9. The method of claim 8, wherein the computer generating the monitoring interval extension comprises the computer generating a daily extension for the first monitoring interval until the acknowledgement timestamp occurs on the extended end date.

10. 10. The method of claim 9, further comprising the step of: generating, in response to the approval timestamp occurring on the extended end date, a third monitoring interval that is effective subsequent to the first monitoring interval and has a third end date that is based at least in part on the first patient care modality rule.

11. the first patient care modality rule corresponds to a heart failure care modality; the first monitoring interval having a length of 31 days before generating the monitoring interval extension; 11. The method of claim 10, further indicating that the third monitoring interval has a length of 31 days.

12. 12. The method of claim 11, wherein the second patient care modality rule corresponds to a remote monitoring care modality and indicates that the second monitoring interval has a length of 91 days.

13. 12. The method of claim 11, wherein the second patient care modality rule corresponds to an in-hospital care modality and indicates that the second monitoring interval has a length of one year.

14. the approval timestamp is a first approval timestamp, the approval date is a first approval date corresponding to the first medical record report, the DOS is a first DOS, and the method further comprises: receiving, by the computer, a second acknowledgment timestamp indicating a second acknowledgment date prior to the third end date of the third monitoring interval; the computer determining that the second approval date corresponds to the second medical record report; 11. The method of claim 10, further comprising the step of: the computer omitting the step of generating a second DOS for the second approval timestamp based at least in part on the second approval date corresponding to the second medical record report and the second medical record report being prior to the extended end date.

15. 1. A method for managing a cardiac monitoring device, the method comprising: accessing by the computer a plurality of patient-care modality rules from a rules database; generating, based at least in part on the plurality of patient-care modality rules, a plurality of monitoring intervals that are simultaneously valid and associated with the cardiac monitoring device, wherein a first monitoring interval of the plurality of monitoring intervals has a first end date and a second monitoring interval of the plurality of monitoring intervals has a second end date that is different from the first end date; accessing, by the computer, transmission data originating from the cardiac monitoring device having a reception date prior to the first end date; generating, by the computer, a medical record report for the transmitted data, the medical record report associated with the first monitoring interval or the second monitoring interval; receiving, by the computer, an approval timestamp indicating an approval date that is later than the receipt date and corresponding to the medical record report; the computer calculating that the approval date is after the first end date; said computer accessing an interval extension rule from said rules database; generating a monitoring interval extension having an extended end date based at least in part on the acknowledgement date being later than the receipt date and later than the first end date in accordance with the interval extension rules; the computer generating a date of operation (DOS) for the transmission data, the DOS being an approval date.

16. the step of the computer calculating that the acknowledgement date is after the first end date includes the step of the computer determining that the acknowledgement timestamp has not yet been received at the occurrence of the first end date; 16. The method of claim 15, wherein the computer generating the monitoring interval extension comprises the computer generating a daily extension for the first monitoring interval until the acknowledgement timestamp occurs on the extended end date.

17. 17. The method of claim 16, further comprising the computer generating a third monitoring interval having a third end date based at least in part on a particular patient care style rule of the plurality of patient care style rules in response to the approval timestamp occurring on the extended end date.

18. The computer, that the DOS criterion for the first monitoring interval is satisfied; The reception date of the transmission data is before the first end date; and the medical record report is generated for the transmitted data prior to the first end date; determining, based at least in part on: the approval timestamp indicates that the approval date is later than the receipt date and corresponds to the medical record report; 16. The method of claim 15, wherein the computer generating the DOS is based in part on the DOS criteria being met.

19. accessing, by the computer, transmission-related data from a transmission database representing a plurality of transmissions originating from a plurality of cardiac monitoring devices, the transmission-related data being associated with a common clinic identifier; generating, based at least in part on the transmission-related data and the common clinic identifier, one or more transmission metrics corresponding to the clinic associated with the common clinic identifier, the one or more transmission metrics comprising: a first number of monitor intervals to wait to receive a transmission; and a second number of monitoring intervals during which the DOS criterion is met; and a third number of monitoring intervals requiring DOS; and a fourth number of monitoring intervals for which action is required within 10 days; and A fifth number of monitoring intervals for which action is required after the 11th day; How many submissions are waiting to receive medical record reports? The number of medical record reports waiting to receive approval; a first number of patients who have opted in to a particular patient care modality; a second number of patients who opted out of the particular patient care modality; and 16. The method of claim 15, further comprising: causing the computer to present the one or more transmission metrics on a display associated with the clinic.

20. generating a graphical representation of the plurality of monitoring intervals as interactive blocks on a plurality of simultaneously presented timelines, the plurality of simultaneously presented timelines comprising: a first timeline corresponding to a heart failure care modality and including the first monitoring interval having a length of 31 days; a second timeline corresponding to a remote monitoring care modality and including the second monitoring interval having a length of 91 days; a third timeline corresponding to an in-hospital care modality and including a third monitoring interval having a length of one year.

Images