System and method for managing a cardiac monitoring device equipped with a monitoring interval tracker

Abstract

The system and method include a monitoring interval tracker for managing transmitted data originating from a cardiac monitoring device. [Solution] The monitoring interval tracker generates monitoring intervals corresponding to multiple different patient care modes (e.g., in-hospital care mode, remote monitoring care mode, and / or heart failure care mode). Upon receiving transmitted data, a medical record report corresponding to the transmitted data, and / or approval of the medical record report, the monitoring interval tracker determines whether to extend the monitoring interval, generate a date for the operation, and / or create a new monitoring interval. Multiple monitoring intervals may be enabled simultaneously to track transmitted data, medical record reports, and approval timestamps for multiple different patient care modes. The results of the monitoring interval tracker may be output as an interactive monitoring interval visualizer and / or transmission dashboard to prevent failures in patient tracking management and improve patient care by improving the accuracy and efficiency of billing.

Description

Technical Field

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

Background Art

[0002] Implanted medical devices are regularly used for the treatment and / or monitoring of various physical disorders. For example, cardiac monitoring devices such as cardiac implantable electronic devices (CIEDs). CIEDs include a pacemaker (PM) that uses low - energy electrical pulses to prevent a decrease in heart rate, an implantable cardioverter - defibrillator (ICD) that detects abnormal cardiac arrhythmias and delivers a life - saving shock to prevent sudden cardiac arrest, an implantable loop recorder (ILR) and an implantable cardiac monitor (ICM) that continuously monitor cardiac data and transmit the data to a clinic according to a clinician's prescription and the patient's discretion, among others, but are not limited to those listed here. Such CIEDs may store and periodically transmit information regarding the operation of an external device 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 various types of devices and different types of patient care. Different devices may transmit cardiac monitoring information to the clinic at different frequencies. Some devices may transmit cardiac monitoring information more consistently than others. Furthermore, each type of patient care may have unique requirements for patient monitoring. For example, some types of patient care (e.g., remote monitoring) may require quarterly transmissions from cardiac monitoring devices, while others (e.g., in-hospital monitoring) may require annual visits. In addition, every transmission may require a corresponding medical record report and approval of the medical record report before scheduling an action date for the transmission. The complexity of managing cardiac monitoring transmissions becomes even more complex when a single cardiac monitoring device is used for multiple types of patient care (e.g., remote monitoring and heart failure monitoring). Therefore, tracking every transmission from every cardiac monitoring device, creating medical record reports for each transmission, approving the medical record reports, and scheduling actions for transmissions in a timely manner without compromising patient care is a significant burden for clinics providing such services.

[0004] In particular, with these observations in mind, we have devised and developed various embodiments of this disclosure. [Overview of the Initiative]

[0005] The aforementioned problems are addressed by providing a system and method for managing patient devices in the implementation described and claimed herein.

[0006] Typically, professional cardiac monitoring is performed throughout the patient's life. Such monitoring is covered by reimbursement and care guidelines. Cardiac care can vary depending on the 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"). US health insurance generally adheres to such guidelines. However, while health insurance reimburses are provided, in many cases the labor costs associated with acquiring, reviewing, and documenting device transmissions are not covered. Due to the rapid introduction of new ILRs and ICMs and the increasing volume of data, the estimated transmission load under such guidelines could exceed 800 million cardiac monitoring transmissions over the next five years. Adhering to such guidelines improves patient outcomes, reduces healthcare system costs, nearly doubles the mortality rate for patients with PMs, and reduces hospitalizations for patients with ICDs by more than 65%. However, due to the burden associated with such guidelines, it is estimated that less than 30% of patients are monitored in accordance with them.

[0007] In one implementation example, a medical device management platform for managing cardiac monitoring devices may include a monitoring interval tracker that tracks transmitted data from cardiac monitoring devices by associating the transmitted data with another monitoring interval. One or more monitoring intervals may correspond to one or more patient care modes, such as heart failure patient care, out-of-hospital patient care, and / or in-hospital patient care. The monitoring interval tracker calculates monitoring interval extensions as needed and categorizes transmitted data, medical record reports for transmitted data, and approvals of medical record reports according to the patient care mode and monitoring interval extension, thereby minimizing situations where proper tracking management attention to transmissions cannot be drawn while improving the accuracy of date-in-time calculations for operations.

[0008] Other implementation examples are described and referenced herein. Furthermore, while several implementation examples are disclosed, other implementation examples of the disclosed technology will become apparent to those skilled in the art from the following detailed description, which illustrates exemplary implementations of the disclosed technology. As can be seen from the following description, the disclosed technology can be modified in various ways without departing from the spirit and scope of the disclosed technology. Therefore, the drawings and detailed description should be considered illustrative and not limiting. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 shows an example block diagram of a network environment that includes a medical device manager running on a network-connected server or other computing device to manage one or more implantable cardiac electronic devices.

[0010] [Figure 2] Figure 2 shows a block diagram of a medical device data communication system, including an exemplary medical device data platform.

[0011] [Figure 3] Figure 3 shows a block diagram of an exemplary medical device data platform.

[0012] [Figure 4] Figure 4 shows a block diagram of an exemplary monitoring interval tracker interacting with one or more databases and healthcare provider portals.

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

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

[0015] [Figure 7] Figure 7 shows a timeline diagram of an exemplary operation performed by a monitoring interval tracker to manage a patient's medical device.

[0016] [Figure 8] Figure 8 shows a timeline diagram of an exemplary operation performed by a monitoring interval tracker to manage a patient's medical device.

[0017] [Figure 9] Figure 9 shows a timeline diagram of an exemplary operation performed by a monitoring interval tracker to manage a patient's medical device.

[0018] [Figure 10] Figure 10 shows a timeline diagram of an exemplary operation performed by a monitoring interval tracker to manage a patient's medical device.

[0019] [Figure 11] Figure 11 shows a timeline diagram of an exemplary operation performed by a monitoring interval tracker to manage a patient's medical device.

[0020] [Figure 12] Figure 12 shows a flowchart of an exemplary operation performed by a monitoring interval tracker to manage a patient's medical device.

[0021] [Figure 13] Figure 13 shows an exemplary monitoring tracker visualization device user interface for managing a patient's medical device.

[0022] [Figure 14] Figure 14 shows an exemplary monitoring tracker visualization device user interface for managing a patient's medical device.

[0023] [Figure 15]Figure 15 shows an exemplary monitoring tracker visualization device user interface for managing a patient's medical devices.

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

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

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

[0027] [Figure 19] Figure 19 shows an exemplary billing report dashboard user interface for managing patient medical devices.

[0028] [Figure 20] Figure 20 shows an exemplary computing system that can implement the various systems and methods discussed herein. [Modes for carrying out the invention]

[0029] Aspects of this disclosure include systems, methods, computer program products, etc., for a medical device management platform for managing one or more implantable or wearable electronic devices. Electronic devices may include medical devices such as one or more cardiac monitoring devices (e.g., cardiac implantable electronic devices (CIEDs)). A 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, and manages the care of such patients, and may include 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 transmitted data in the monitoring interval tracker via 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 transmitted data, the monitoring interval tracker can associate the transmitted data with the corresponding monitoring interval to ensure timely reception of medical record reports, medical record report approvals, and DOSs.

[0030] For example, a monitoring interval tracker may generate a monitoring interval associated with a cardiac monitoring device before receiving transmitted data as part of a registration procedure, or in response to the receipt of transmitted data. The monitoring interval may correspond to a specific type of patient care (e.g., remote monitoring care, in-hospital care, and / or heart failure care) and have a length of time based on patient care style rules accessed from a rules database. The transmitted data may be time-stamped indicating the date and / or time (i.e., “reception date”) that the clinic received the transmitted data. The monitoring interval tracker may determine if the reception date is within the monitoring interval by calculating whether the reception date is before or after the end date of the monitoring interval. If the reception date is after the end date, the monitoring interval tracker may access interval extension rules from a rules database that indicate how to adjust the monitoring interval to take in subsequently received transmitted data. For example, if the end date has occurred but no transmitted data has 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 a day, and may create an extended end date for the monitoring interval each day until transmitted data is received. If transmitted data is received during an extended monitoring interval, the extended monitoring interval may end, and in some cases, the date of operation (DOS) for the extended monitoring interval may be generated on the reception date (which may be the extended end date). In addition to or separately from this, the monitoring interval tracker may, upon reaching the end date, access a second interval extension rule from the rules database indicating that the monitoring interval (e.g., the first monitoring interval) is scheduled to end without receiving transmitted data before the end date, and a second monitoring interval (having the same length of time as the first monitoring interval, as indicated by the patient care style rules) may be generated on a new second end date.

[0031] In some cases, a monitoring interval tracker may determine whether the DOS criteria are met in order to generate a DOS. For example, the DOS criteria may include: the date of receipt of transmitted data being before the end date (or extended end date) of the monitoring interval; generating a medical record report for the transmitted data before the end date (or extended end date); and receiving an approval timestamp for the medical record report indicating an approval date that is 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 style rules and / or interval extension rules for generating and extending monitoring intervals depending on the type of patient care, to ensure that the DOS criteria are met. For example, a monitoring interval tracker may receive transmitted data before the end date and generate a medical record report before the end date, but may not yet have received an approval timestamp indicating the approval date of the medical record report when the end date occurs. Therefore, the monitoring interval tracker may access a third interval extension rule from the rules database indicating that the monitoring interval is extended daily until an approval timestamp is received and the DOS criteria for the monitoring interval are met, creating an extended end date each day.

[0032] In some cases, a monitoring interval tracker may generate multiple simultaneously active monitoring intervals for a cardiac monitoring device, each corresponding to a different patient care pattern rule and therefore having different durations and end dates. The monitoring interval tracker may also receive and generate multiple medical record reports for transmitted data, such as medical record reports 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 among multiple medical record reports before, on, or after the end date, while still lacking a second approval timestamp for a second medical record report among multiple medical record reports. For example, a first medical record report for a first monitoring interval concerning 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 concerning remote patient care may remain unapproved. The monitoring interval tracker may generate a DOS for transmitted data of an approved medical record report even if the second medical record report remains unapproved. Furthermore, the monitoring interval tracker may receive a second approval timestamp for a second medical record report during a third monitoring interval (for example, generated after a first monitoring interval). Additionally, the monitoring interval tracker may recognize that the second approval timestamp corresponds to transmitted data for which a DOS has already been received (based on the first approval timestamp of the first medical record report), and may omit the step of generating a second DOS based on the second approval timestamp.

[0033] In some examples, a medical device management platform may include interface tools, such as a monitoring interval visualizer, for presenting information generated by a monitoring interval tracker on a display in a clinic providing patient care, via a graphical user interface (GUI). For example, the monitoring interval visualizer may present monitoring intervals as interactive interval shapes (e.g., bars, blocks, lines, etc.) on one or more timelines. The interactive interval shapes may include metrics or icons corresponding to the reception date, medical record report status, medical record report date, and / or approval date. Upon receiving user input, the interactive interval shapes and / or metrics may present various transmission-related data to the authorized user, such as the transmission data reception date, medical record report date, approval date, and one or more action request metrics corresponding to the medical record report and / or monitoring interval (including the names of the healthcare professionals who created and / or approved the medical record report). In some examples, the interface tool may include a transmission dashboard for aggregating transmission-related data for a specific clinic from a transmission database, generating one or more transmission metrics for a specific clinic, and presenting the transmission metrics on a display in that clinic. In addition, the received transmissions and the resulting statistics on care protocols, as well as other measured values, may be provided through interface tools to improve the operation and efficiency of the clinic, improve patient care, or share data with other organizations that have access to the interface. In this way, the management of device transmissions is simplified and improved for users of the device management platform interface.

[0034] Refer to Figure 1, which shows an exemplary network environment 100, including a medical device manager 102 running on a server 112 or other computing device connected to a network 106, for managing one or more cardiac implantable electronic devices 104. In one implementation example, users, such as members of a medical team and / or third parties to whom access has been delegated to manage or complete administrative tasks, use 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, or multimedia console. 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 example, the network environment 100 includes at least one server 112 that hosts a website or application that a user can access to access the medical device manager 102, and / or other network components, including a device programming machine located in a physician's office and used in the presence of a patient. Server 112 may be a single server, multiple servers where each such server is a physical server or a virtual machine, or a collection of both physical and virtual servers. In another implementation example, a cloud hosts one or more components of the network environment 100. Information sources, including user devices 108 and server 112 connected to network 106, may access one or more other servers to access one or more websites, applications, web service interfaces, storage devices, computing devices, etc., used for integrated healthcare delivery. 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 educational data. In one implementation example, the medical device manager 102 provides access to data and / or other information of one or more medical devices 104, such as cardiac monitoring devices.

[0036] The medical device 104 may communicate with the network 106 to provide operational data to the medical device manager 102. For example, as described above, implantable cardiac electronic devices (CIEDs), such as implantable cardioverter-defibrillators (ICDs), often transmit information related to the operation of the external device for analysis, programming, etc. In some cases, the clinic may retrieve data for the medical device 104 from the device manufacturer's secure website and / or from a device programming machine physically located in the healthcare provider's office. The data generated by the medical device 104 is typically reviewed by the healthcare provider, who then generates a medical record report. Typically, the healthcare provider implants and monitors transmissions from any manufacturer, device model, and type. Healthcare providers rarely embed and monitor a single device type. Each manufacturer uses its own proprietary data formats, displays, access protocols, reporting, and programming machines for data transmission and the review of that data. Because healthcare providers receive data in this wide range of proprietary and heterogeneous formats, it is difficult for them to efficiently manage patient care. The burden of data access and management is a major obstacle to improving patient care. Clumsy workflows result in excessive costs, hindering the adoption of telecare, a superior care model, leading to missed reimbursement opportunities. Some clinics abandon telecare altogether, instead pushing patients into even less in-hospital care, further degrading care due to lower patient compliance and increased burden on the healthcare system associated with increased hospitalizations. Therefore, as will be further detailed below, the medical device manager 102 enables 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 traceability failures.

[0037] Referring to Figure 2, the medical device manager 102 may include a medical device data communication system 200. In one implementation example, the medical device data communication system 200 includes a medical device platform 204 that communicates with multiple implantable medical device manufacturer systems 206 and multiple clinic systems 202. The medical device platform 204 may be communicably coupled to the manufacturer systems 206 and clinic systems 202 via a wide area network (WAN), such as the Internet. In some implementation examples, each of the manufacturer systems 206 may be associated with a specific implantable medical device manufacturer. In other examples, each of the manufacturer systems 206 may be associated with a specific combination of an implantable medical device manufacturer and a particular clinic or medical office. In the example of system 200 in Figure 2, the manufacturer system 206 may include a manufacturer platform 212, such as a web server, that reads previously uploaded diagnostic data and related data from multiple implantable medical devices from the device database 214. Such data may be pre-read from various implantable medical devices via clinics or medical offices, or via remote monitoring, as described above.

[0038] As shown in Figure 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 the manufacturer platform 206 with a Clinical Information System (CIS) identifier associated with a specific clinic to retrieve the diagnostic and related information. Such information may be in the form of Implantable Device Cardiac Observation (IDCO) messages. In some implementation examples, messages between the integration manager 210 and the manufacturer platform 212 may be in the form of alternative data messages, enhanced data messages, or extended data messages. For example, IDCO messages often contain 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 numerical data and / or graphical electrophysical record (EGM) data regarding arrhythmias or other heart attacks detected by the implantable device in integer, floating-point, or other data formats. Such information may facilitate easier and / or more detailed processing of device data within the medical device platform 204.

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

[0040] As shown in Figure 2, a user (e.g., one or more doctors, nurses, technicians, analysts, etc.) may use the clinic system 202 to retrieve processed device information, including advanced information such as monitoring interval tracking and analysis results for one or more implanted medical devices. In some examples, the clinic system 202 may also include a clinic access system 218 (e.g., a desktop computer, laptop computer, tablet computer, 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 Figure 2, the clinic system 202 may also include one or more of the following: an electronic medical record manager system 216 configured to store and make easily accessible the medical records of the clinic's patients; and a health information exchange (HIE) system 220 configured to exchange health information for the clinic's patients using other computing systems outside the clinic system 202. In one implementation example, the time a user would normally need to access each of these systems individually may be reduced by having the user 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.

[0041] In some cases, the integration manager 210 may read device information, including device diagnostic data, via transmitted data received through a communication connection with one or more implantable medical devices, which may reduce the need for one or more manufacturer systems 206 in some cases. In such and other cases, the integration manager 210 and / or the cloud computing system 208 may transfer, or "push," raw and / or processed device information, as well as advanced information, including analysis results, to one or more 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., transmitted data and transmitted-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 transmitted data according to the cardiac monitoring device from which the transmitted data originated, a type of patient care associated with the transmitted data (e.g., a "patient care pattern") (based on its association with the cardiac monitoring device or the 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 extend monitoring intervals and generate DOS for monitoring intervals. In some cases, the monitoring interval tracker 222 may perform analysis of the transmitted data and transmitted-related data and output the results to the healthcare provider portal. The monitoring interval tracker 222 may receive indications (for example, during the registration process) that a patient is associated with a particular patient care pattern, and / or store the association between the patient and the patient care pattern in one or more databases 110. The monitoring interval tracker 222 may also determine and store the 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 will be discussed in more detail below.

[0043] Figure 3 is a block diagram of an example of the medical device platform 204 shown in Figure 2. As shown in Figure 3, the medical device platform 204 may include one or more of the following: a transmit 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. In addition, other examples may include other software components, data structures, applications, or modules not specifically described herein in the medical device platform 204. Furthermore, each of these software components may be incorporated into a monitoring interval tracker 222, an integration manager 210, and / or a cloud computing system 208, as shown in Figure 2.

[0044] In some examples, the transmit analyzer 300 may be configured to analyze information and data received from one or more cardiac monitoring devices and to provide an automated snapshot of trends in the analyzed information. In some embodiments, such information may be analyzed for a specific clinic or for a group of 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 implanted device. This information is transmitted to or downloaded to the medical device platform 204 and analyzed by the transmit analyzer 300. The analysis of the information may provide a specific snapshot of the analyzed and / or aggregated information through a portal (further details are described below). For example, the transmit analyzer 300 may provide information based on the type of device associated with the information or data, the manufacturer of the device, or a specific device model. Similarly, a tracker 302 may be included in the medical device platform 204 to track trends in received data over time. The combination of the Transmit Analyzer 300, the Tracker 302, and other software components may provide snapshots of device information, such as trends in medical record reports regarding the receipt or absence of approval, extended DOS monitoring intervals, overall transmission of received data, and specific monitoring intervals. The analysis results and information regarding data received from one or more medical devices and analyzed by the Transmit Analyzer 300 will be discussed in further detail below.

[0045] In some examples, the aggregator 304 may also be included in the medical device platform 204. Generally, the aggregator 304 may be configured to read device-related data, including diagnostic data, from each manufacturer system 206 discussed above, and / or to read information from cardiac monitoring devices. In one example, the aggregator 304 may use a manufacturer-specific courier engine to read data using specific security measures, communication protocols, data formats, and other characteristics of the specific manufacturer system 206 required to read 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 within a clinic, particularly for devices from multiple manufacturers, each employing its own data formats, communication protocols, etc., to read diagnostic data and other information from implantable medical devices.

[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 healthcare provider-oriented device data information corresponding to the clinic's patients. The healthcare provider portal 306 may use clinic staff and patient logons, respectively, to grant access to healthcare provider-oriented or patient-oriented information as needed. In some examples, as described above, logging on to the healthcare provider portal 306 may facilitate access by clinic staff to other systems located outside or inside the clinic system 202 (e.g., the medical record manager 216 and / or HIE system 220 in Figure 2) via single sign-on (SSO) functionality. Furthermore, the healthcare provider portal 306 may provide an application programming interface (API) that facilitates patient or healthcare provider access to the patient's electronic health record (EHR), which may include access points to device-related information, such as embedded web links. The healthcare provider portal 306 may present one or more visualizations of the monitoring interval tracker 222, such as timelines representing monitoring intervals, medical record reports, approval dates and DOS, interval shapes, indicators, blocks and / or icons, as will be discussed in more detail below.

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

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

[0049] The medical record generator 310 may be configured to create one or more medical records (e.g., “medical record reports”) relating to a patient or a set of received data. Generally, a medical record report is a type of report that summarizes, or otherwise provides, an interpretation and record of the received patient CIED transmission. The medical record report may include, in whole or in part, information received during transmission, and the medical record report may be provided in whole or in part 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 plans, device tracking records, patient information, and a summary of data analysis. Any information relating to patient information, or information received from multiple medical devices, may be included in the medical record through the medical record generator 310. In some cases, the monitoring interval tracker 222 may generate an indicator that requires a medical record report in response to the receipt of transmitted data. This indicator, 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 monitors information related to cardiac monitoring devices for one or more patients, including information on periodic device checks and resulting diagnostic data, and based on this information, it recommends changes to the clinic's workflow, such as changes to the device check schedule, changes to specific types of information read from the implanted medical device, and changes to how the read information is processed, thereby potentially making the clinic's operations more efficient.

[0051] The billing engine 314 may be configured to present (for example, via a web portal for healthcare providers) an interface in which clinical staff can input instructions for one or more clinical actions performed on a patient's implantable medical device, such as a cardiac monitor, and to generate a currently appropriate billing code representing that action. 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 the patient, health insurance company, etc. In some examples, the billing engine 314 may receive or read information regarding changes to billing codes from Centers for Medicare and Medicaid Services (CMS) that are available under a fixed-price reimbursement scheme (PPS), and may use such changes to update the billing codes corresponding to clinical actions related to the implantable medical device.

[0052] The recording integrator 316 may be configured to update the patient's EHR, for example, by embedding a web link in the patient's EHR that facilitates access to processed device-related data, or to input information related to the implanted medical device, including processed diagnostic data, into the EHR. Such data may include, for example, the date of the diagnosis performed with respect to the implanted medical device, numerical data and / or graphs of the diagnostic results, recommended and / or performed actions based on the diagnostic results, and the patient's health status or biological response to the operation of the device based on data detected by the device.

[0053] Figure 4 is a block diagram of an example of the monitoring interval tracker 222 of Figure 2. The monitoring interval tracker 222 may include many of the software components discussed above with respect to Figure 3 to analyze the received transmitted data and identify the cardiac monitoring device from which the transmitted data originated, classify the transmitted data according to one or more patient care modes provided to the cardiac monitoring device, generate one or more medical records for the transmitted data, extend one or more monitoring intervals of the cardiac monitoring device, and / or generate a DOS for the transmitted 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 mode rules 402 and / or one or more interval extension rules 404. The patient care mode rule 402 may include a first patient care mode rule for heart failure patient care, indicating that the monitoring interval has a duration of 31 days when the monitoring interval is associated with heart failure patient care. Patient care format rule 402 may include a second patient care format rule for remotely monitored patient care, indicating that the monitoring interval has a duration of 91 days when the monitoring interval is associated with remotely monitored patient care. Patient care format rule 402 may include a third patient care format rule for in-hospital patient care, indicating that the duration of the monitoring interval is 91 days when the monitoring interval is associated with in-hospital patient care. Patient care format rule 402 may include additional patient care format rules for other types of patient care, indicating that the monitoring interval has a different duration. According to the patient care format rule, 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 rule to generate an extended end date for the monitoring interval.

[0054] In some examples, interval extension rule 404 may indicate how the monitoring interval is extended, not extended, or closed based on the transmitted data and transmitted-related data. For example, interval extension rule 404 may include a first interval extension rule (e.g., a "daily transmit roll" rule) that indicates the DOS is either the end date of the monitoring period or the date the transmitted data is received (whichever is later). According to the daily transmit roll rule, if the end date of the monitoring interval has arrived and the transmitted 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 transmitted data is received. When the transmitted data is received, the monitoring interval ends, a DOS is generated for the monitoring interval as the date the transmission was received (which is also the final extended end date of the monitoring interval), and a second monitoring interval is generated to become effective after the monitoring interval has ended or been closed. According to the daily transmission role rules, while transmitted data may require a medical record report and subsequent approval of that report for billing purposes, the second monitoring interval will begin on a date after the date of receipt of the transmission, so as not to depend on a physician or healthcare professional creating and approving a medical record report of the transmitted data in a timely manner.

[0055] In some examples, interval extension rule 404 may include a second interval extension rule (e.g., a “per-interval roll” rule) indicating that the DOS is the end date of the monitoring period, regardless of whether transmitted data was received during the monitoring period. According to the per-interval roll rule, if the end date of the monitoring period occurs and transmitted data has not yet been received, the monitoring interval will end without extension and may be classified as a “missing” monitoring interval for patient follow-up and billing procedures. A second monitoring interval will be generated to run after the terminated or closed monitoring interval. The second monitoring interval may have the same duration as the closed monitoring period. No medical record reports or approval requirements will be generated during the closed monitoring period.

[0056] In some examples, interval extension rule 404 may include a third interval extension rule (e.g., a “daily approval role” rule) indicating that the DOS is the later of either the end date of the monitoring period or the approval date (e.g., indicated by the approval timestamp) of the medical record report corresponding to the transmitted data. According to the daily approval role rule, if 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. When the approval timestamp is received, the monitoring interval ends, a DOS is 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 is generated to become effective after the end or closed monitoring interval. In some cases, the medical device platform 204 may generate multiple medical record reports during a 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 cases, the patient care style rule 402 and / or interval extension rule 404 may be based on one or more healthcare policies stored, for example, in the healthcare policy database 406. The healthcare 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, the CMS care guidelines may include one or more professional codes (PCs).For example, PC93294 is described as "Single-lead, dual-lead, or multi-lead pacemaker systems with remote evaluation of the medical interview device, up to 90 days, with interim analysis, review, and reporting by a physician or other qualified medical professional (please do not report 93294 together with 93288 and 93293) (please report 93294 only once every 90 days)," and PC93295 is described as "Single-lead, dual-lead, or multi-lead implantable cardioverter-defibrillator systems with remote evaluation of the medical interview device, up to 90 days, with interim analysis, review, and reporting by a physician or other qualified medical professional (please use 93297 for remote monitoring of physiological cardiovascular data elements obtained from the ICD) (please do not report 93295 together with 93289) (please report 93295 only once every 90 days)," and PC93297 is described as, The instructions state, "An implantable cardiovascular monitoring system including remote evaluation of the medical 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 reporting by a physician or other qualified medical professional (for heart rhythm-derived data elements, please use 93295) (please do not report 93297 together with 93290 and 93298) (please report 93297 only once every 30 days)," and / or PC93298 states, "An implantable loop recorder system including remote evaluation of the medical interview device, analysis of recorded heart rhythm data for up to 30 days, analysis, review and reporting by a physician or other qualified medical professional (please do not report 93298 together with 33282, 93291 and 93297) (please report 93298 only once every 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 style rules and / or interval extension rules to correspond to the PC codes (e.g., via manual input and / or automated text and content recognition using machine learning techniques).The healthcare policy database may be updated at regular intervals (e.g., weekly, monthly, yearly, etc.) to reflect changes in HRS or CMS policies, so that the patient care style rules and / or interval extension rules 404 are kept continuously up-to-date and to provide accurate monitoring interval tracking that corresponds to highly efficient billing methods.

[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, transmission-related data associated with a transmission may include a reception date timestamp indicating the date the transmission data was received, a cardiac monitor identifier corresponding to the cardiac monitor from which the transmission data originated, a patient identifier, a clinic identifier, a timestamp indicating the date the medical record report was created, an approval timestamp, a display of the DOS standard status, and / or any data generated or received by other components of the medical device platform 204 related to the transmission data (e.g., integration manager 210, cloud computing system 208, transmission analyzer 300, tracker 302, aggregator 304, etc.).

[0059] In some examples, the monitoring interval tracker 222 may generate a monitoring interval visualizer 410 to display the monitoring interval and the end date, extended end date, medical record creation date, approval date, and / or DOS indication. The monitoring interval visualizer 410 may display an “Action Required” indication to alert healthcare providers that a particular monitoring interval requires transmission, medical record reporting, or approval of medical record reporting. The indication may be presented via the healthcare provider portal as a selectable shape and / or interactive graphical user interface (GUI) indicator to provide additional information when user input is received. 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 transmission data and / or transmission-related data from the transmission database 408, aggregate the transmission data and / or transmission-related data, perform analysis on the aggregated transmission data and / or transmission-related data, and present the results of the analysis on the transmission dashboard 412. In some examples, the transmission data and / or transmission-related data may be aggregated according to a specific clinic identifier such that the results become transmission metrics for a specific clinic corresponding to a specific clinic identifier. The transmission dashboard 412 may be presented via the healthcare provider portal 306. The transmission dashboard 412 will be discussed in more detail below.

[0061] Figure 5 shows several exemplary timeline diagrams of the actions performed by the monitoring interval tracker 222 using the daily send role rule to generate one or more DOSs. Figure 6 shows several exemplary timeline diagrams of the actions performed by the monitoring interval tracker 222 using the interval send role rule to generate one or more DOSs. Figures 7 to 11 show several exemplary timeline diagrams of the actions performed by the monitoring interval tracker 222 using the daily approval role rule to generate one or more DOSs.

[0062] Referring to Figure 5, two exemplary timeline diagrams are shown illustrating the actions performed by the monitoring interval tracker 222 using the daily transmit roll rule to generate one or more DOSs, generate a new monitoring interval, and / or generate an extension of a monitoring interval. For example, in the first exemplary scenario 500, a first monitoring interval 502 may be generated. A trigger may occur when transmit data 504 is generated. This is defined as a “success” when the transmit 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 becomes effective following the first monitoring interval. The second monitoring interval 508 has a second end date 510 that specifies the same duration as the first monitoring interval 502 (this may be based on the patient care style rule 404). A second exemplary scenario 512 is illustrated, in which the transmitted data 504 has not been received during the first monitoring interval 502 (i.e., before the end date 506). This is defined as a “failure” according to the daily transmitted roll rule. For this reason, the monitoring interval tracker 222 may generate an interval extension 514, extending the interval by one day, for example, until the transmitted data 504 is received on the extended end date 516. If, during the interval extension 514, the monitoring interval tracker receives the transmitted data 504 on the extended end date 516, it generates a DOS (e.g., a confirmed DOS as opposed to an initial predicted DOS before the interval extension is generated) on the date the transmitted data 504 was received (i.e., the extended end date 516), and generates a new monitoring interval 508 or a second monitoring interval 508 that becomes effective following the first monitoring interval 502. The second monitoring interval 508 has a second end date 510 that specifies the same duration as the first monitoring interval 502 before the interval extension 514 was added.

[0063] Figure 6 shows an exemplary timeline diagram illustrating the actions performed by the monitoring interval tracker 222 using the per-interval send roll rule to generate one or more DOSs and generate a new monitoring interval. In exemplary scenario 600, the send data 504 is not received during the first monitoring interval 502 (i.e., before the end date 506). The per-interval send roll rule defines this as a “failure”. In response to the failure, the monitoring interval tracker 222 closes the first monitoring interval 502, resulting in a closed or missing monitoring interval 602, and the monitoring interval generates a new monitoring interval 508 or a second monitoring interval 508 that becomes effective following the missing monitoring interval 602. The monitoring interval tracker 222 does not generate a DOS during the missing monitoring interval. The second monitoring interval 508 has a second end date 510 that specifies the same duration as the missing monitoring interval 602.

[0064] Figure 7 shows two exemplary timeline diagrams illustrating the actions performed by the monitoring interval tracker 222 using the daily approval role rule to generate one or more DOSs, interval extensions, and / or new monitoring intervals. For example, in the first exemplary scenario 700, the monitoring interval tracker 222 may generate a first monitoring interval 502. A “success” is defined when the medical record report 702 and the 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 with an end date of 506 and generates a second monitoring interval 508. However, if the approval date has not occurred 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 approval date 704 (i.e., extended end date 516), and generates a second monitoring interval 508 that becomes effective following the first monitoring interval 502. The second monitoring interval 508 has a second end date 510 that specifies the same duration as the first monitoring interval 502 before the interval extension 514 was added. In the second exemplary scenario 706, the first monitoring interval 502 is defined as “successful” by the daily approval role 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 criterion for the first monitoring interval 502 is met, the first DOS is generated as end date 506, and the second monitoring interval 508 is generated. The second transmission data 712 is received during the second monitoring interval 508 (i.e., before the second end date 510), and the second medical record report 714 is generated for the second transmission data 712 during the second monitoring interval 508 (i.e., before the second end date 510). However, since the approval 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 approval date 716 that satisfies the DOS criteria occurs during the second monitoring interval 508.Therefore, 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 which may have the same duration as the second monitoring interval 508 prior to the interval extension 514.

[0065] Figure 8 shows two exemplary timeline diagrams illustrating the actions performed by the monitoring interval tracker 222 using the daily approval role rule to generate one or more DOSs, interval extensions, and / or new monitoring intervals. For example, in the first exemplary scenario 800, the monitoring interval tracker 222 may generate the first monitoring interval 502. A "success" occurs because the first transmission data 504, the first medical record report 708 for the first transmission, and the first approval date 710 for 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). In addition, the second transmission data 712, the third transmission data 802, and the second medical record report 714 (for example, 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 approval date 716 within the first monitoring interval (i.e., before the end date 506). However, since the DOS criteria are met at least with respect to the first transmitted data 504, the DOS is generated for the end date 506 with no interval extension relative to the first monitoring interval 502, regardless of whether the second approval date 716 occurs within the first monitoring interval 502. The second approval date 716 may occur within the second monitoring interval 508, but since the second approval date 716 is relative to the second medical record report 714 in the previous first monitoring interval 502, the second approval date 716 will not trigger a DOS for the second monitoring interval 508 (the second approval date 716 alone does not meet the DOS criteria for the second monitoring interval 508 without the corresponding transmitted data or medical record report for the second monitoring interval 508). In the second exemplary 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. The first medical record report 708 may be generated for the first transmission data 504, and the second medical record report 714 may be generated for the third transmission data 802.When end date 506 occurs, since approval for the first medical record report 708 and the second medical record report 714 has not yet been received, the monitoring interval tracker 222 generates interval extensions 514 daily until the first approval date 710 is received, and the DOS is generated as the first approval date 710 (i.e., the extended end date 506). The second approval date 716 may also be received as the extended end date 516, but since the first approval date 710 already satisfies the DOS criteria for the first monitoring interval 504, the second approval date 716 does not affect the DOS calculation for the first monitoring interval 504.

[0066] Figure 9 shows two exemplary timeline diagrams illustrating the actions performed by the monitoring interval tracker 222 using the daily approval role rules to generate one or more DOSs, interval extensions, and / or new monitoring intervals. For example, in the first exemplary scenario 900, 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 502. The monitoring interval tracker 222 may generate an interval extension 514 based on the absence of the first approval date 710 prior to the first end date 506. The second transmission data 712 and the third transmission data 802 may be received during the interval extension 514 of the first monitoring interval 502. The second medical record report 714 may be generated for the second transmission data 712, and during the interval extension 514, the third medical record report 902 may be generated for the third transmission data 802. The interval extension 514 may extend the first monitoring interval by days until the first approval date 710 is received and the 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. Furthermore, the fourth transmission data 906 and the fourth medical record report 908 may occur during the second monitoring interval 508. However, the DOS criterion for the second monitoring interval 508 is 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 they do 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 extension of the first monitoring interval 514). According to the daily approval role rule, the approval date and / or transmission date of the medical record occurring in a previous monitoring interval does not meet the DOS criterion for the current monitoring interval. In the 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 approval date 710 prior to the first end date 506. The second transmission data 712 may occur during the interval extension 514. The first approval date 710 may occur on the extended end date 516, which can 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 the second monitoring interval 508. The second transmission data 712 may not have received a reported medical record or approval, but it will not affect the DOS for the first monitoring interval because the DOS criteria have already been satisfied by the first transmission data 504, the first medical record report 708 and the first approval 704. The third transmission data 802 may be received during the second monitoring interval 508, and the second medical record report 714 may be generated during the second monitoring interval 508, and may correspond to the third transmission data 802 of the second monitoring interval 508, as well as the second transmission data 712 of the first monitoring interval (for which the medical record report was not received during the first monitoring interval 502). The second approval date 716 of the second medical record report 714 may occur during the second monitoring interval 508, which satisfies the DOS criteria for the second monitoring interval and generates a DOS with an end date 510.

[0067] Figure 10 shows two exemplary timeline diagrams illustrating the actions performed by the monitoring interval tracker 222 using the daily approval role rules to generate one or more DOSs, interval extensions, and / or new monitoring intervals. For example, in the first exemplary scenario 1000, the first transmission data 504, the first medical record report 708 for the first transmission data 504, and the first approval date 710 may be received during the first monitoring interval 502. The second transmission data 712 and the second medical record report 714 may also be received during the first monitoring interval 502, but the 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. The second approval 716 for the second medical record report 714 may be received during the second monitoring interval 508. Furthermore, 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, when the second end date 510 occurs, the monitoring interval tracker 222 will generate an interval extension 514 of the second monitoring interval 508 daily until the approval date is received, because the second approval date 716 (which occurred during the second monitoring interval 508) does not correspond to any 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 during the second monitoring interval 508. Rather, the second approval 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 the second exemplary scenario 1002, the first transmission data 504 and the first medical record report 708 relating 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 with a first end date 506, and generates a second monitoring interval 508 that becomes effective after the first monitoring interval 502. The second monitoring interval 508 has a second end date 510 that specifies the same duration as the first monitoring interval 502. The second transmission data 712, the third transmission data 802, and the fourth transmission data 906 are received during the second monitoring interval 508. The second medical record report 714 for the second transmission data 712 and the second approval date 716 for the second medical record report 714 are also received during the second monitoring interval 508, and the DOS criteria for the second monitoring interval 508 are met. The 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. Nevertheless, the monitoring interval tracker 222 may 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. The third approval date 904 may be received during the third monitoring interval 718, but since the third approval date 904 corresponds to a medical record report from a previous monitoring interval (e.g., the third medical record report 902), it would not be considered a DOS criterion for the third monitoring interval 718. Nevertheless, the fifth transmission data 1002, the fourth medical record report 1004 relating to the fifth transmission data 1002, and the fourth approval date 1006 relating to the fourth medical record report 1004 may still be generated during the third monitoring interval 718, and as a result the DOS criteria are met in the third monitoring interval 718, no extension of the interval is necessary, and the DOS for the third monitoring interval 718 is generated as the third end date 1008 of the third monitoring interval. After generating the DOS for the third monitoring interval 718, the monitoring interval tracker 222 may also generate the fourth monitoring interval 1010. In the fourth monitoring interval, the sixth transmission data 1012 and the fifth medical record report 1014 relating to the sixth transmission data 1012 may be received.Since the fourth end date of the fourth monitoring interval 1010 may occur without receiving the approval date corresponding to the fifth medical record report 1014, the monitoring interval tracker 222 may generate daily interval extensions 514 for the fourth monitoring interval 1010 in accordance with the daily approval role rules until the approval date of the fifth medical record report 1014 is received and the DOS criteria are met for the fourth monitoring interval 1010.

[0068] Figure 11 shows an exemplary timeline diagram illustrating the actions performed by the monitoring interval tracker 222 using the daily approval role rule to generate one or more DOSs, interval extensions, and / or new monitoring intervals. For example, in exemplary scenario 1100, the first transmission data 504 and the first medical record report 708 relating to the first transmission data 504 are received during the first monitoring interval. However, since the DOS criterion is not met when the first end date 506 occurs, the monitoring interval tracker 222 generates an interval extension 514 to the first monitoring interval 502 until the first approval date 710 is received. The DOS is generated as the first approval date (i.e., the extended end date 516) for the first monitoring interval 502, and 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 relating 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 approval 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, extending the second monitoring interval day by day until the second approval date 716 is received. Upon receiving the second approval date 716, the monitoring interval tracker determines that the DOS criteria for the second monitoring interval are met and generates a DOS for the second approval date 716. The 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 are already met by the second approval date 716, the second medical record report 714, and the second transmitted data 712. In response to the generation of the DOS of the second monitoring interval 508, the monitoring interval tracker 22 generates a third monitoring interval 718 having a time length determined by the patient care style rules.

[0069] In some examples, any of the exemplary scenarios shown in Figures 5 to 11 may be implemented concurrently with other exemplary scenarios to simultaneously represent different monitoring intervals for different patient care modes. For example, the first exemplary scenario 700 may represent a heart failure care mode, while the second exemplary scenario 706 may represent a remote monitoring care mode. Therefore, the monitoring interval for the first exemplary scenario 700 may have a duration of 31 days, while the monitoring interval for the second exemplary scenario 706 may have a duration of 91 days. A single transmission data (e.g., the first transmission data 504) may be included in multiple concurrently implemented monitoring intervals, such as each monitoring interval for each type of patient care mode. When the first transmission data 504 is received, separate medical record creation reports and approval dates may be required for different patient care modes, and as a result, even though both concurrently implemented monitoring intervals track the same transmission data, the DOS criteria for one patient care mode (e.g., heart failure care mode) may be met, while the DOS criteria for another patient care mode (e.g., remote monitoring care mode) may not be met. The ability to independently track different patient care patterns with varying time durations significantly improves the efficiency of patient care tracking, patient tracking management, and reducing missing monitoring intervals and tracking management failures for a single data transmission from a single cardiac monitoring device. This improvement is particularly significant when the system scales to manage hundreds or thousands of different patients with hundreds or thousands of different cardiac monitoring devices, each having its own transmission speed and different combinations of patient care patterns.

[0070] Figure 12 shows an exemplary flowchart of operations performed by the monitoring interval tracker 222 to manage the cardiac monitoring device, for example, 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 the cardiac monitoring device. The monitoring interval tracker 222 may receive or generate a reception date timestamp indicating the date the transmission data 1202 was received. The monitoring interval tracker 222 may classify the transmission data 1202 into one or more patient care style rules, e.g., in-hospital care style 1204, remote monitoring care style 1206 and / or heart failure care style 1208 (for example, by comparing the patient identifier, cardiac device identifier or other information from the incoming transmission data with information stored in one or more databases). If the incoming transmission data 1202 corresponds to remote monitoring care mode 1206 and / or heart failure care mode 1208, the monitoring interval tracker 222 may calculate whether the reception date is later than 10 or 30 days after the embedding date associated with the cardiac monitoring device (e.g., an association stored in one or more databases 110). If the answer is "no", the monitoring interval tracker 222 may decide to do nothing (i.e., omit generating a response to the transmission data), but if the incoming transmission data 1202 further corresponds to remote monitoring care mode 1206 and "interval-based" extension rules (e.g., interval-based transmission role rules), the monitoring interval tracker 222 may decide to generate a new monitoring interval with a new end date (e.g., predicted DOS). If the monitoring interval tracker calculates that the reception date is later than 10 or 30 days after the embedding date, the monitoring interval tracker 222 may begin calculating whether "today" (i.e., the reception date) is later than the end date (e.g., predicted DOS for the monitoring interval). Similarly, if the transmitted data 1202 is classified under the in-hospital care format 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 date of the monitoring interval).If the answer is "no," the monitoring interval tracker 222 may decide to do nothing (i.e., omit generating a response to the transmitted data), but if the incoming transmitted data 1202 further corresponds to the remote monitoring care format 1206 and the "interval-by-interval" extension rules (e.g., interval-by-interval transmission roll rules), the monitoring interval tracker 222 may decide to generate a new monitoring interval with a new end date (e.g., predicted DOS). If the answer is "yes," i.e., if the monitoring interval tracker 222 calculates that "today" (i.e., the reception date) is actually later than the end date (e.g., predicted DOS for the monitoring interval), the monitoring interval tracker may, accordingly, access and / or use the interval extension rules 404 for the monitoring interval. If the monitoring interval tracker 222 accesses and / or uses a “daily” extension rule (e.g., a daily send role rule or a daily approve role rule), the monitoring interval tracker 222 may proceed to determine whether the DOS criterion for the current monitoring interval is met. If “yes,” it generates a new monitoring interval with a new end date (e.g., predicted DOS) which is the previous DOS for the current monitoring interval plus a time length based on the patient care style rule (e.g., one year for in-hospital care style 1204, 91 days for remote monitoring care style 1206, and / or 31 days for heart failure care style 1208). If “no,” i.e., if the monitoring interval tracker 222 determines that the DOS criterion is not met while using the “daily” rule, the monitoring interval tracker 222 may continue to extend the current monitoring interval daily until the DOS criterion is met. If the monitoring interval tracker 222 accesses and uses the “interval” rule, the monitoring interval may generate a new monitoring interval by calculating a new end date (e.g., predicted DOS) for the new monitoring interval by adding a time length based on the patient care style rule (e.g., 1 year for in-hospital care style 1204, 91 days for remote monitoring care style 1206, and / or 31 days for heart failure care style 1208) to “today” (i.e., the day of reception). If the monitoring interval tracker 222 determines that the DOS criterion is met, the monitoring interval tracker 222 may further generate a DOS for the current monitoring, which is “today” (i.e., the day of reception).In some cases, once the first medical record is approved for a monitoring interval, a DoS may be generated for all medical records within that 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 those states with the monitoring interval (for reporting and / or visualization via the monitoring interval visualizer 410 and / or transmission dashboard 412, for example, as will be discussed in more detail below). For example, a monitoring interval in remote monitoring care form 1206 may be associated with one or more states, including a state requiring transmission (if no transmission data is received during the monitoring interval), a state requiring a medical record report (if no medical record report is generated during the monitoring interval), a state requiring approval (if no approval is given for a medical record report received during the monitoring interval), or a state being met (if the DOS criteria are met). The monitoring interval in Heart Failure Care Form 1208 may be associated with one or more conditions, including: a condition requiring transmission (if no transmission data is received during the monitoring interval), a condition requiring feedback (if no feedback is received for the transmission data), a condition requiring a medical record report (if no medical record report is generated during the monitoring interval), a condition requiring approval (if no approval is given for the medical record report received during the monitoring interval), or a condition being met (if the DOS criteria are met). The monitoring interval in In-Hospital Care Form 1204 may be associated with one or more conditions, including: a condition requiring outpatient visit (if no transmission data is received from an outpatient visit during the monitoring interval), a condition requiring a medical record report (if no medical record report is generated during the monitoring interval), a condition requiring approval (if no approval is given for the medical record report received during the monitoring interval), or a condition being met (if the DOS criteria are met).

[0072] Referring here to Figures 13 to 19, various examples of portals or user interfaces are provided for accessing, analyzing, observing, or otherwise managing information and data received from cardiac monitoring devices at the medical device platform 204 and / or generated by monitoring interval trackers 222. The user interfaces may be displayed on a user device 108, such as the device described above in relation to Figure 1. Various user interfaces displayed on the user device 108 may be accessed by the user device via the network 106 and run by one or more servers 112 in the network environment 100. Furthermore, 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 and store it in the database 110. For example, using the Health Level 7 (HL7) protocol, the medical device manager 102 may receive communications from remote transmissions of device manufacturers, including device and / or patient-specific data and device fields of device type and model. Next, as discussed above, this information may be processed in various ways by the monitoring interval tracker 222 and presented or managed by the user via a user interface. This allows the user (such as a nurse or doctor in a clinic) to receive, access, analyze, and / or manage data from one or more medical devices 104 on a patient-by-patient or patient-by-patient basis in ways that were previously unavailable.

[0073] As described herein, the medical device manager 102 manages the transmission and interviews of CIED devices, including both in-hospital and remote interviews. In one implementation example, in-hospital interviews utilize an in-hospital upload interface generated by the medical device manager 102, which the user may use to drop or select one or more files for import. Files may be accessed over a network or via memory (e.g., a flash drive). Once files are selected, the interface may generate a visualization of the upload progress status as the medical device manager 102 processes the interview data. In one implementation example, an internal interface may be generated and used to verify, add to, or edit contact information corresponding to data extraction, including but not limited to the contact date, patient name, patient's date of birth, clinic name, device manufacturer, device type, and device serial number. If data is missing, the user can enter the data via the internal interface. The medical device manager 102 may determine whether the patient is a new or existing patient and proceed with processing accordingly. Multiple visualizations are provided via the interface, including the progress of processing the medical history data, options for procedures, editing, or canceling, and the progress of uploading the data to the medical device manager 102. The user may also be given further options, including uploading a related PDF from the medical history. During processing and uploading, the data file is parsed, and individual data is imported from the parsed data file. During import, the user can add, edit, and review the imported data via the user interface. If a PDF is imported, the PDF may be presented with the imported data or accessible via the interface. The imported data may be saved automatically or manually. If the submission is associated with an existing patient, a set of key identifiers is matched. The patient record indicates that the in-hospital submission (if any) is added to the in-hospital medical history stack.If only a remote transmission stack exists, or if the current in-hospital interview stack does not exist, the medical device manager 102 generates a new medical record instance. Therefore, the medical device manager 102 may generate and track a workflow for in-hospital interviews separate from remote interviews. Thus, the medical device manager 102 may generate in-hospital and remote medical records, with the in-hospital records containing 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-hospital interview, as well as the traces of technician observations and healthcare provider approval. This report is generated by the medical device manager 102 for in-hospital or remote interviews by combining patient information, unique medical history presentations, and submitted PDF files if attached by reviewers. The report may be generated and stored in the cloud by the medical device manager 102, 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 described herein. Furthermore, the monitoring interval tracker 222 may generate a monitoring interval visualizer 410 and / or a transmission dashboard 412 based on the output of its operation, as will be discussed in more detail below.

[0074] Figure 13 shows an exemplary monitoring interval visualizer 410. Generally, the monitoring interval visualizer 410 provides data and data management options as a graphical display of multiple monitoring intervals, which can serve as a user-specific portal to the user's role (such as a nurse or physician in a clinic, or a patient analyzing their own device data). Therefore, the data management options displayed in the monitoring interval visualizer may be different or modified 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 when accessing the system. Other interfaces, which will be 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 specific example shown in Figure 13, the monitoring interval visualizer 410 may include a first section 1302 for presenting multiple timelines. For example, the first timeline may correspond to in-hospital care format 1204, the second timeline to remote monitoring care format 1206, and / or the third timeline to heart failure care format 1208. Furthermore, a fourth timeline representing the reception dates of one or more transmitted data may be presented in the first section 1302. The monitoring interval may be presented as one or more shapes, such as blocks, on the multiple timelines. Multiple interactive indicators and / or selectable indicators, such as graphic elements or icons, may be presented on the multiple timelines to represent the reception dates of transmitted data and other transmitted-related data. For example, a rectangle on the timeline may represent a medical record report (e.g., the date the medical record report was created), and a checkmark 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 section 1302 may present one or more behavioral requirement indicators 1304 alongside multiple timelines. Since the behavioral requirement indicators may correspond to patient care modes, they may reside on the same line as the timelines corresponding to the same patient care mode. The monitoring interval tracker 222 may determine the status of the current monitoring interval for each timeline, such as whether the 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 the behavioral requirement indicator corresponding to the particular DOS criterion that is not met. For example, the first behavioral requirement indicator may indicate that a medical record report is required for a particular patient care mode (e.g., heart failure care mode). In addition to or separately from this, the behavioral requirement indicator 1304 may indicate that data transmission is required for the current monitoring interval, that approval of a medical record report is required for the current monitoring interval, and / or that the DOS criteria are met for the current monitoring interval.

[0076] In some examples, the interactive and / or selectable indicators of the first section 1302 may provide additional transmission-related information in response to user input or selection, such as clicking the interactive and / or selectable indicator or hovering the cursor over it. For example, a second section 1306 (e.g., positioned below the first section 1302 on the display of the user device 108) may present transmission-related information corresponding to user input in the first section 1302. The second section 1306 may include, in response to the selection of a particular monitoring interval, a display 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 section 1306 may include a transmission sidebar 1308 that presents selectable transmission indicators representing the transmissions and / or transmission dates for the selected monitoring interval. Upon receiving user input on a selectable transmission indicator, the second section 1306 may present additional information corresponding to the particular transmission represented by the selectable transmission indicator, such as past remarks regarding the medical record report and transmission, patient records, and cardiac monitor details. The second part 1306 may include one or more display windows 1310 for displaying transmission-related information corresponding to user input in the first part 1302 and / or the transmission sidebar 1308. In some cases, the second part 1306 may present a completed medical record report for monitoring intervals in which the DOS criteria have been met. In some examples, upon receiving a selection of monitoring intervals in which the DOS criteria have not yet been met, the second part 1306 may present an interval report summarizing the transmissions, observations, plans and physician records included within the monitoring interval. Interval reports may be automatically generated for each type of patient care mode, i.e., without requiring approval. The interval report may indicate diagnostic information (e.g., showing a “stable” or “improving” status with respect to a heart failure diagnosis) and / or which information is awaiting approval (e.g., has a “pending” status) or has received approval from the physician (e.g., has an “approved” status). In some cases, the monitoring interval visualizer 410 may not display the monitoring interval's DOS (e.g., predictive DOS) until the medical records within that monitoring interval are approved.In other cases, a predictive DOS may be displayed. In some cases, the monitoring interval may not be displayed until the first medical record for that monitoring interval is approved.

[0077] Figure 14 shows an exemplary monitoring interval visualizer 410 having a medical record stacking window 1400 in a second section 1306. For example, upon receiving a selection of a first section of specific transmitted data, the second section 1306 of the monitoring interval visualizer may present multiple medical record reports in the medical record stacking window 1400 corresponding to the selected transmitted data. For example, the medical record stacking window may present a first medical record corresponding to an in-hospital care form 1204, a second medical record report corresponding to a remote monitoring care form 1206, and / or a third medical record report corresponding to a heart failure care form 1208. The multiple medical record reports may be presented aligned with the selectable transmission indicators of the transmission sidebar 1308 so that the multiple medical record reports appear to overlap. Upon receiving a selection of a specific medical record report from the medical record stacking window 1400 and / or the transmission sidebar 1308, the monitoring interval visualizer may present an unobstructed or complete version of the selected medical record report.

[0078] Figure 15 shows an exemplary monitoring interval visualizer 410, including a transmission detail graph 1500 that may be presented in a first section 1302. For example, selectable graphic indicators may, upon receiving user input, present a list of selectable graphing options. The graphing options may include any specific values ​​or metrics contained in or related to the transmission data (e.g., detected values, impedance, pulse amplitude, pulse width, atrial fibrillation (AT) load, atrial pacing, left ventricular pacing, etc.). Upon receiving a selection of one or more graphing options, the monitoring interval visualizer 410 may place a graph (e.g., a line graph, a bar graph, etc.) on the first section 1302 (e.g., instead of a timeline) with the data points defined by each transmission. The monitoring interval tracker 222 may generate the transmission detail graph 1500 by accessing data stored in the transmission database (e.g., based on a timestamp and / or identifier associated with each transmission).

[0079] Figure 16 shows an exemplary monitoring interval setting interface 1600 for generating parameters for a 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 indicating which of the patient care style rules 402 and / or interval extension rules 404 to use for a particular transmission data. The parameters generated by the monitoring interval setting interface 1600 may, in some cases, be associated with a specific patient name or identifier or a specific cardiac monitoring device identifier and stored in the transmission database 408. When the transmission data is received, the patient name or identifier or cardiac monitoring device identifier contained in the transmission data can be matched with those stored in the transmission database 408, and the relevant parameters may be read and applied to the transmission data. In some examples, the monitoring interval setting interface 1600 may receive information related to remote monitoring care mode 1206 in a first section 1602, such as whether to opt in or opt out of this type of patient care mode, interval length (e.g., 91 days or another interval length), initial predicted DOS of the initial monitoring interval (e.g., end date), and / or whether the interval extension rule 404 is an interval-based rule or a daily rule. In a second section 1604, the monitoring interval setting interface 1600 may receive information related to heart failure monitoring care mode 1208, such as whether to opt in or opt out of this type of patient care mode, interval length (e.g., 31 days or another interval length), initial predicted DOS of the initial monitoring interval (e.g., end date), whether the interval extension rule 404 is an interval-based rule or a daily rule, and / or an 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 mode 1204, such as opt-in or opt-out for this type of patient care mode, interval length (e.g., 365 days or another interval length), and the end date of the initial monitoring interval, in the third section 1606.In some examples, the monitoring interval setting interface 1600 may include an interactive component for generating a new configurable patient care pattern having an arbitrary interval length, initial interval monitoring period, initial DOS, future DOS, interval extension rules, and / or ICD-10 code, and for adding the configurable patient care pattern to the patient-associated transmission database 408. The monitoring interval setting interface 1600 may include an option for selecting a patient group and / or device type class, and for 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 an option for modifying the patient's patient care pattern rules 402 and / or interval extension rules 404 in response to the patient changing clinics (e.g., moving from clinic 1 to clinic 2).

[0080] Figure 17 shows an exemplary transmission dashboard 412 for aggregating transmission-related data for a specific clinic from a transmission database 408, generating one or more transmission metrics for a specific clinic, and presenting the transmission metrics on a user device 108 for a specific clinic. For example, the transmission dashboard 412 may receive input in one or more interactive graphic elements that indicate which clinical settings the transmission metrics will be related to and which patient care modes the transmission metrics will be related to. The transmission metrics may be presented in the first section 1700 and may include a display of the number of currently active monitoring intervals that require transmissions for a selected patient care mode, the number of transmissions that require medical record reports for a selected patient care mode, the number of medical record reports that require approval for a selected patient care mode, the number of currently active monitoring intervals that meet all DOS criteria for a selected patient care mode, the number of patients who have opted in to a selected patient care mode, the number of patients who have opted out of a selected patient care mode, and the number of DOS required for a selected patient care mode. In some examples, the transmission metrics may include interactive graph indicators such that, upon receiving a selection or user input in the transmission metrics, additional details related to the selected transmission metrics, such as a list of patients corresponding to the selected transmission metrics (e.g., patients requiring transmission, patients requiring medical record reports, etc.) and / or additional information related to the list of patients, are presented in a second section 1702 under 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 currently valid monitoring interval billing requirements (e.g., DOS criteria) and a second color indicating patients who meet the currently valid monitoring interval billing requirements (e.g., listed in the second section 1702).

[0081] Figure 18 shows an exemplary transmission dashboard 412 for aggregating transmission-related data for a specific clinic from a transmission database 408, generating one or more transmission metrics for that clinic, and presenting the transmission metrics on the user device 108 for that clinic. The transmission dashboard 412 may also help a clinic to see and understand the steps required to meet the DOS criteria for currently valid monitoring intervals, how a particular clinic tracks monitoring compliance overall, and which patients have met the billing criteria. Transmission metrics may be sorted by type of patient care (e.g., based on a common clinic identifier associated with multiple transmissions), by clinic, by site (e.g., via user input in one or more interactive graphic elements such as drop-down menus, text fields, selectable icons, or sliders), by device type, and by service date. The transmission metrics may include one or more of the following displays: the number of DOSs that have elapsed or been extended, the number of patients without a DOS (including patients who have not opted in to any patient care style tracking), the number of actions required within 10 days, the number of actions required after 11 days, and / or the number of monitoring intervals in which the DOS criteria are met and waiting for a DOS to occur. Furthermore, the transmission dashboard may provide patient filtering to generate lists of patients categorized by days to 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 transmission, and / or DOS elapsed or extended), and / or by patient name input.

[0082] Figure 19 shows 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 requiring approval, and / or the number of monitoring intervals that are billable because the DOS criteria are 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 style, start date, and / or end date) that forms 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), which, 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 metric, a second section may present a list of monitoring intervals containing additional information related to the monitoring interval, such as clinic name, patient name, DOS, patient care style, status, matching date, and / or first approval date. Upon receiving input, the billing report dashboard may present one or more interactive elements to convert the submitted metrics into one or more billing reports (e.g., downloadable, sendable, and / or printable) to indicate whether the patient's monitoring interval is currently billable and what actions are needed to meet the DOS criteria to make the patient's monitoring interval billable. Billing reports may be generated weekly or based on user input selecting how often billable reports are generated. The billing report data (e.g., submitted metrics) may be generated as a downloadable spreadsheet.The billing report may be a downloadable report containing the patient's name, date of birth, medical record number (MRN), device type, device model, device implantation date, start and end dates of the monitoring interval, opt-in to the type of patient care form (e.g., in-hospital care form 1204, remote monitoring care form 1206, and / or heart failure care form 1208), healthcare provider approval, approval date, professional 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 verify that the DOS criteria are met for the patient name to appear in the billing report. This generates only one billing report per patient monitoring interval, reducing the time the practice spends tracking such relevant data. In some examples, recognizing the first approval date of a monitoring interval (rather than subsequent approval dates) as meeting the DOS criteria provides additional assurance of compliance to know that the billing requirements for that monitoring interval are met. The billing report dashboard 1900 may output one or more reports, such as billing reports and / or patient care reports, that show practices and / or retrospective actions that a clinic can take to ensure compliance (for example, that the DOS criteria for monitoring intervals are met), including, for example, reports showing transmitted metrics.

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

[0084] Various non-limiting and exemplary embodiments of the monitoring interval tracker 222, monitoring interval visualizer 410, 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 the steps of: determining a monitoring interval associated with the cardiac monitoring device; displaying blocks on a display representing monitoring intervals on one or more timelines corresponding to one or more patient care modes; accessing transmitted data originating from the cardiac monitoring device; displaying one or more icons on one or more timelines, including a transmitted icon representing the date the transmitted data was received and a medical record icon corresponding to the transmitted data; receiving one or more inputs indicating at least the approval date of a medical record report associated with the medical record icon; and determining the date of operation (DOS) for the transmitted data based at least in part on the date of receipt, one or more patient care modes, and the approval date.

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

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

[0088] Furthermore, the step of receiving one or more inputs may include the step of receiving a first input providing comments on the medical record report and the step of receiving a second input providing approval for the medical record report, and one or more icons may include a first display for comments and a second display for approval.

[0089] Furthermore, the method may further comprise the step of presenting on a display one or more input elements for registering a patient associated with a 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 among one or more patient care modes, a second selectable icon for indicating an interval extension rule, a first input field for indicating the length of the monitoring interval, and a second input field for indicating the date of the service.

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

[0091] Furthermore, the method may further include a step of determining, at least in part, based on one or more patient care modes, that the interval extension rule extends the monitoring interval by days until approval is received.

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

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

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

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

[0096] Furthermore, the method may further include the steps of receiving a selection of a block representing one of several monitoring intervals, and presenting an interval report in at least a partial response to the block selection. The monitoring interval report may be an interval report showing completed monitoring intervals and historical information associated with completed monitoring intervals, or an interval report showing active monitoring intervals and pending required approvals.

[0097] Furthermore, the method may further include a step of presenting one or more input elements on a display for generating a transmission report to the clinic, where one or more input elements correspond to the care mode, the clinical setting, or the number of days until DOS.

[0098] Furthermore, the method may further include the steps of receiving input through one or more input elements, and presenting, on a display, one or more transmission-related metrics representing aggregated transmission data to the clinic, in at least a partial response to the input.

[0099] Furthermore, one or more transmission-related metrics may further include one or more of the following: the number of monitoring intervals awaiting receipt of transmissions, the number of transmissions awaiting receipt of medical record reports, the number of medical record reports awaiting approval, the number of completed monitoring intervals, the number of patients who have opted in to patient care mode, the number of patients who have opted out of patient care mode, and the number of monitoring intervals requiring a DOS.

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

[0101] Furthermore, the method may further include the steps of: presenting a DOS analysis dashboard on a display that includes one or more filter input elements corresponding to a clinic, clinical setting, care mode, type of cardiac monitoring device, date of work, days to DOS, monitoring interval status, or patient name; receiving input at one or more filter input elements; and presenting one or more DOS-related metrics on a display that represent aggregated DOS data, at least in part based on the reception of input at one or more filter input elements.

[0102] Furthermore, DOS-related metrics may include one or more of the following: the number of monitoring intervals that passed DOS or did not pass DOS, the number of monitoring intervals requiring action within 10 days, the number of monitoring intervals requiring action after 11 days, and the number of monitoring intervals that met the DOS criteria.

[0103] Furthermore, the method may further include the steps of displaying a billing report dashboard for completed monitoring intervals, which includes one or more filter input elements corresponding to a clinic, clinical setting, type of cardiac monitoring device, care mode, date range, DOS, or patient name; receiving input in one or more filter input elements; and, at least in part, displaying on the screen one or more of the following: the number of monitoring intervals requiring a medical record report, the number of medical record reports requiring approval, or the number of monitoring intervals ready for billing.

[0104] In some cases, a method for managing a cardiac monitoring device includes the steps of: determining a first monitoring interval associated with the cardiac monitoring device, having a first length corresponding to a first patient care mode; determining a second monitoring interval associated with the patient, having a second length corresponding to a second patient care mode; displaying the first monitoring interval on a display 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 transmitted data from the cardiac monitoring device. The steps may further include: presenting one or more transmission icons representing one or more reception dates for the transmitted data on a third timeline corresponding to the transmission; presenting a first medical record icon corresponding to the transmitted data on a first timeline; presenting a second medical record icon corresponding to the transmitted data on a second timeline; receiving one or more inputs indicating at least the approval date of a medical record report associated with the first or second medical record icon; and determining the date of operation (DOS) of the transmitted data based at least in part on one or more reception and approval dates.

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

[0106] The computer system 2000 may be a computing system capable of executing computer processes by executing computer program products. Data files and program files may be input to the computer system 2000. The computer system 2000 reads the files and executes the programs contained therein. Some elements of the computer system 2000 are shown in Figure 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. Furthermore, the computing system 2000 may include other elements that will be recognized by those skilled in the art, but are not explicitly shown in Figure 20 or discussed further herein. Various elements of the computer system 2000 may communicate with one or more communication buses, point-to-point communication paths or other means of communication not explicitly shown in Figure 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 a plurality of processing units that can execute instructions and operate in parallel with one another, commonly referred to as a parallel processing environment.

[0108] 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 through a cloud computing architecture. The technology described herein may be optionally implemented in software stored in data storage device 2004, stored in memory device 2006, and / or communicated through one or more of ports 2008-2010, thereby transforming computer system 2000 in Figure 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, and set-top boxes.

[0109] One or more data storage devices 2004 may include any non-volatile data storage device capable of storing data generated or adopted within the computing system 2000, such as computer executable instructions for carrying out computer processes. The non-volatile data storage device may contain instructions for both application programs and operating systems (OS) that manage various components of the computing system 2000. The data storage device 2004 includes, but is not limited to, magnetic disk drives, optical disk drives, solid-state drives (SSDs), and flash drives. The data storage device 2004 may also 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 disk read-only memory (CD-ROM), digital versatile disk read-only memory (DVD-ROM), magneto-optical disks, and flash drives. Examples of non-removable data storage media include internal magnetic hard disks and SSDs. 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] Computer program products, including mechanisms for implementing systems and methods using the technologies described herein, may reside in a data storage device 2004 and / or memory device 2006 called a machine-readable medium. It will be understood that the machine-readable medium may include any tangible, non-temporary medium that can store or encode instructions for performing one or more of the operations of the present disclosure performed by a machine, or that can encode data structures and / or modules used by such instructions or associated with such instructions. The machine-readable medium may include a single medium or multiple mediums (e.g., a centralized or distributed database and / or associated caches and servers) for storing one or more executable instructions or data structures.

[0111] In some implementations, the computer system 2000 includes one or more ports, such as input / output (I / O) ports 2008 and communication ports 2010, for communicating with other computing devices, network devices, or vehicle devices. Ports 2008-2010 may be coupled or separated, and the computer system 2000 may contain more or fewer ports.

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

[0113] In one implementation example, the input device converts human-generated signals, such as human voice, physical movement, physical contact, or pressure, into electrical signals as input data to the computing system 2000 via I / O port 2008. Similarly, the output device may convert electrical signals received from the computing system 2000 via I / O port 2008 into signals that can be perceived as human output, such as sound, light, and / or touch. The input device may also be an alphanumeric input device, including keys such as alphanumeric keys for transmitting information and / or command selections to the processor 2002 via I / O port 2008. The input device may also be another type of user input device, including, but not limited to, direction and selection control devices such as a mouse, trackball, cursor keys, joystick, and / or wheel, one or more sensors such as a camera, microphone, position sensor, compass sensor, gravity sensor, inertial sensor, and / or accelerometer, and / or a touch-sensitive display screen ("touchscreen"). The output device may include, but is not limited to, a display, touchscreen, speaker, haptic and / or force feedback output device, etc. In some implementations, for example, with a touchscreen, 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 I / O port 2008. For example, it may convert an electrical signal generated within the computing system 2000 into another type of signal, and / or vice versa. In one implementation example, the environmental transducer device senses characteristics or aspects of the environment near or away from the computing system 2000, such as light, sound, temperature, pressure, magnetic field, electric field, chemical properties, physical motion, direction, acceleration, and gravity. Furthermore, the environmental transducer device may generate signals that have some effect on the environment near or away from the exemplary computing system 2000, such as the physical motion of an object (e.g., a mechanical actuator), heating or cooling of a substance, or the addition of a chemical substance.

[0115] In one implementation example, the communication port 2010 is connected to a network, and the computer system 2000 may, via the network, perform the methods and systems described herein and receive network data useful for 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), and Long-Term Evolution (LTE). One or more such communication interface devices may be used via the communication port 2010 to communicate directly with one or more other machines 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 network (e.g., third-generation (3G) or fourth-generation (4G)), or via another means of communication. Furthermore, the communication port 2010 may communicate with an antenna or other link for transmitting and / or receiving electromagnetic signals.

[0116] The system shown in Figure 20 is merely one possible example of a computer system that may be employed or configured in accordance with the embodiments of this disclosure. It will be understood that other non-temporary, tangible, computer-readable storage media may be used to store computer executable instructions for implementing the technologies disclosed herein on a computing system.

[0117] In this disclosure, the disclosed method may be implemented as a set of instructions or software readable by an apparatus. Furthermore, it is understood that the particular order or hierarchy of steps in the disclosed method is an example of an exemplary technique. It is understood that, based on design preferences, the particular order or hierarchy of steps in the method can be rearranged while remaining within the scope of the disclosed subject matter. The claims of the appended method present elements of various steps in a sample order and are not necessarily limited to the particular order or hierarchy presented.

[0118] The disclosures described herein may be provided as computer program products or software that may include a non-temporary machine-readable medium on which instructions can be stored that may be used to program a computer system (or other electronic device) to perform the processes described herein. The machine-readable medium includes any mechanism for storing information in a format (e.g., software, processing applications) that is readable by a machine (e.g., a computer). The machine-readable medium includes, but is 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] While this disclosure has been described with reference to various implementation examples, it should be understood that these examples are illustrative and the scope of this disclosure is not limited to these examples. Many variations, modifications, additions, and improvements are possible. Furthermore, generally speaking, the implementation examples provided in this disclosure have been described in relation to specific implementation examples. Functionality may be separated in different ways, combined into blocks, or described using different terminology in the various implementation examples of this disclosure. Such variations, modifications, additions, and improvements, among others, may fall within the scope of this disclosure as defined in the claims. The inventions disclosed herein include the following: [Aspect 1] A method for managing a cardiac monitoring device, wherein the method is Steps to access patient care style rules from the rules database, A step of generating a monitoring interval related to the cardiac monitoring device, wherein the monitoring interval has at least a partially defined end date based on the patient care style rules, The steps include: having a reception date and accessing the transmitted data sent from the cardiac monitoring device; A step of calculating whether the aforementioned reception date is after the aforementioned end date, The steps include generating a medical record report of the transmitted data, The steps include receiving an approval timestamp corresponding to the aforementioned medical record report, A step of calculating whether the approval timestamp indicates an approval date later than the end date, Steps to access interval extension rules from the rule database, A step of generating a monitoring interval extension having an extended end date that is extended at least partially based on the receiving date being later than the end date, or the approval date being later than the end date, in accordance with the interval extension rules, A method comprising the step of generating a Date of Service (DOS) for the transmitted data, wherein the DOS is the extended end date of the monitoring interval extension. [Aspect 2] The step of calculating whether the reception date is after the end date includes the step of determining that the transmitted data has not yet been received at the time the end date occurs. The method according to embodiment 1, wherein the step of generating the monitoring interval extension includes the step of generating a daily extension to the monitoring interval until the transmitted data is received on the extended end date. [Aspect 3] The method according to embodiment 2, wherein the end date is the initial DOS prediction for the monitoring interval, and the extended end date is the final DOS for the monitoring interval. [Aspect 4] The step of calculating whether the approval date is later than the end date includes the step of determining that the approval timestamp has not yet been received when the end date occurs, The method according to embodiment 1, wherein the step of generating the monitoring interval extension includes the step of generating a daily extension to the monitoring interval until the approval timestamp occurs on the extended end date. [Aspect 5] The method according to embodiment 4, wherein the monitoring interval includes a first monitoring interval, the end date includes a first end date, and the method further includes the step of generating a second monitoring interval having a second end date at least partially based on the patient care style rules in response to the approval timestamp occurring on the extended end date. [Aspect 6] The method according to embodiment 5, wherein the medical record report is a first medical record report, the patient care style rules are a first patient care style rules, 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 style rules, the method is The steps include accessing a second patient care style rule from the aforementioned rule database, A step of generating a second medical record report of the transmitted data, wherein the second medical record report is associated with a second patient care style rule, The steps include receiving a second approval timestamp indicating an approval date that is after the extended end date and before the second end date, A step of determining that the second approval timestamp corresponds to the second medical record report, A method comprising the step of determining, at least in part, based on the second approval timestamp corresponding to the second medical record report, that a second DOS should not be generated. [Aspect 7] The aforementioned monitoring interval is the first monitoring interval, The first patient care style rule corresponds to the heart failure care style and indicates that the first monitoring interval is 31 days long. The second patient care style rule corresponds to the remote monitoring care style and indicates that the second monitoring interval is 91 days long. The method according to embodiment 6, wherein the second monitoring interval is effective simultaneously with the first monitoring interval. [Aspect 8] A method for managing a cardiac monitoring device, wherein the method is Steps to access multiple patient care style rules from a rules database, A step of generating a first monitoring interval associated with the cardiac monitoring device, wherein the first monitoring interval has a first end date that is at least partially based on a first patient care style rule among the plurality of patient care style rules; A step of generating a second monitoring interval associated with the cardiac monitoring device, wherein the second monitoring interval has a second end date that is at least partially based on a second patient care style rule among the plurality of patient care style rules, and the second end date is different from the first end date. The steps include: having a reception date and accessing the transmitted data sent from the cardiac monitoring device; The steps include generating a first medical record report associated with the first patient care style rule for the transmitted data, The steps include generating a second medical record report associated with the second patient care style rule for the transmitted data, A step in which an approval timestamp is received after the aforementioned reception date, and the approval date is indicated for only one of the first medical record report or the second medical record report, A step of calculating whether the aforementioned approval date is later than the aforementioned first end date, The steps include: accessing interval extension rules from the aforementioned rule database, A step of determining whether to generate a monitoring interval extension having an extended end date, at least partially based on whether the approval date is later than the first end date, in accordance with the interval extension rules, A method comprising the step of generating a Date of Service (DOS) for the transmitted data, wherein the DOS is the approval date. [Aspect 9] The step of calculating whether the approval date is later than the first end date includes the step of determining that the approval timestamp has not yet been received when the first end date occurs. The method according to embodiment 8, wherein the step of generating the monitoring interval extension includes the step of generating a daily extension for the first monitoring interval until the approval timestamp occurs on the extended end date. [Aspect 10] The method according to embodiment 9, further comprising the step of generating a third monitoring interval that becomes effective following the first monitoring interval and has a third end date based at least in part on the first patient care style rules, in response to the approval timestamp occurring on the extended end date. [Aspect 11] The first patient care style rule described above corresponds to the heart failure care style, The first monitoring interval has a length of 31 days before generating the monitoring interval extension. The method according to embodiment 10, wherein the third monitoring interval has a length of 31 days. [Aspect 12] The method according to embodiment 11, wherein the second patient care style rule corresponds to a remote monitoring care style and the second monitoring interval has a length of 91 days. [Aspect 13] The method according to embodiment 11, wherein the second patient care style rule corresponds to an in-hospital care style and 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 is The steps include receiving a second approval timestamp indicating a second approval date before the third end date of the third monitoring interval, A step of determining that the second approval date corresponds to the second medical record report, The method according to embodiment 10, further comprising the step of omitting the step of generating a second DOS for the second approval timestamp based at least in part on the fact that the second approval date corresponds to the second medical record report and the second medical record report is prior to the extended end date. [Aspect 15] A method for managing a cardiac monitoring device, wherein the method is Steps to access multiple patient care style rules from a rules database, A step of generating a plurality of monitoring intervals that are simultaneously effective and associated with the cardiac monitoring device, based at least in part on the plurality of patient care style rules, wherein a first monitoring interval among the plurality of monitoring intervals has a first end date, and a second monitoring interval among the plurality of monitoring intervals has a second end date different from the first end date, The steps include: accessing transmitted data originating from the cardiac monitoring device, having a reception date prior to the first termination date; The steps include generating a medical record report associated with the first monitoring interval or the second monitoring interval for the transmitted data, The steps include: receiving an approval date that is later than the aforementioned receipt date and receiving an approval timestamp corresponding to the aforementioned medical record report; A step of calculating whether the aforementioned approval date is later than the aforementioned first termination date, The steps include: accessing interval extension rules from the aforementioned rule database, A step of generating a monitoring interval extension having an extended end date, based at least in part on the fact that the approval date is later than the reception date and later than the first end date, in accordance with the interval extension rules, A method comprising the step of generating a Date of Service (DOS) for the transmitted data, wherein the DOS is the approval date. [Aspect 16] The step of calculating whether the approval date is later than the first end date includes the step of determining that the approval timestamp has not yet been received when the first end date occurs. The method according to embodiment 15, wherein the step of generating the monitoring interval extension includes the step of generating a daily extension for the first monitoring interval until the approval timestamp occurs on the extended end date. [Aspect 17] The method according to embodiment 16, further comprising the step of generating a third monitoring interval having a third end date that is at least partially based on a specific 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] The DOS criteria for the first monitoring interval described above are met. The reception date of the transmitted data is earlier than the first end date, The aforementioned medical record report is generated for the transmitted data before the first end date, The step of determining whether the approval timestamp indicates that the approval date is later than the receipt date and corresponds to the medical record report, at least in part, The method according to embodiment 15, further comprising the step of generating the DOS, wherein the step of generating the DOS is based in part on the fulfillment of the DOS criteria. [Aspect 19] A step of accessing transmission-related data from a transmission database, which represents multiple transmissions originating from multiple cardiac monitoring devices, wherein the transmission-related data is associated with a common clinic identifier. A step of generating one or more transmission metrics corresponding to a clinic associated with the common clinic identifier, based at least in part on the transmission-related data and the common clinic identifier, wherein the one or more transmission metrics are: The first number of monitoring intervals for waiting for transmission reception, The second number of monitoring intervals that satisfy the DOS criteria, The third number of monitoring intervals that require DOS, The fourth number of monitoring intervals requiring action within 10 days, The fifth number of monitoring intervals requiring action from the 11th onward, The number of transmissions awaiting receipt of medical record reports, The number of medical record reports awaiting approval, The first number of patients who opted in to a specific patient care style, A second number of patients who have opted out of a specific patient care pattern, and a step including one or more of the following: The method according to embodiment 15, further comprising the step of causing one or more of the aforementioned transmission metrics to be displayed on a display associated with the clinic. [Aspect 20] A step of generating a graphic representation of the multiple monitoring intervals as interactive blocks on multiple timelines presented simultaneously, wherein the multiple timelines presented simultaneously are: Corresponding to the heart failure care style, a first timeline including the first monitoring interval of 31 days, In accordance with the remote monitoring care format, a second timeline including the aforementioned second monitoring interval of 91 days in length, The method according to embodiment 15, further comprising steps including a third timeline that includes a third monitoring interval of one year in length, corresponding to an in-hospital care style.

Claims

1. A method for managing a cardiac monitoring device, wherein the method is The computer accesses patient care style rules from a rules database, The computer generates a monitoring interval associated with the cardiac monitoring device, wherein the monitoring interval has at least a partial end date based on the patient care style rules; The computer accesses the data transmitted by the cardiac monitoring device, The computer accesses the interval extension rules from the rule database, The computer generates an extended monitoring interval having an extended end date, based at least in part on the patient care style rules. A method comprising the step of the computer generating a date of service (DOS) for the transmitted data, wherein the DOS is the extended end date of the monitoring interval extension.

2. The transmitted data has a reception date, and the method is The method according to claim 1, further comprising the step of the computer calculating whether the reception date is later than the end date.

3. The aforementioned method, The computer generates a medical record report of the transmitted data, The computer receives an approval timestamp corresponding to the medical record report, The method according to claim 2, comprising the step of the computer calculating whether the approval timestamp indicates an approval date later than the end date.

4. The method according to claim 1, wherein the patient care style rules correspond to a specific type of patient care.

5. The method according to claim 4, wherein the specific type of patient care is one of remote monitoring care, in-hospital care, or heart failure care.

6. The aforementioned method, The method according to claim 1, comprising the step of the computer generating an extended monitoring interval by acquiring data from a medical device platform, wherein the data corresponds to at least one procedure code.

7. The method according to claim 6, wherein the at least one procedure code is updated periodically.

8. A method for managing a cardiac monitoring device, wherein the method is The computer accesses multiple patient care style rules from a rules database, The steps include: the computer generating a first monitoring interval related to the cardiac monitoring device, wherein the first monitoring interval has a first end date based at least in part on a first patient care style rule among the plurality of patient care style rules; The steps include: the computer generating a second monitoring interval associated with the cardiac monitoring device, wherein the second monitoring interval has a second end date that is at least partially based on a second patient care style rule among the plurality of patient care style rules, and the second end date is different from the first end date; The computer accesses the data transmitted by the cardiac monitoring device, The computer accesses the interval extension rules from the rule database, The steps include determining whether the computer generates an extended monitoring interval having an extended end date, based at least in part on the first patient care style rule or the second patient care style rule, in accordance with the interval extension rule, A method comprising the step of the computer generating a date of operation (DOS) for the transmitted data, wherein the DOS is the extended end date of the monitoring interval extension.

9. The transmitted data has a reception date, and the method is The method according to claim 8, comprising the step of the computer calculating whether the reception date is later than the first end date or the second end date.

10. The aforementioned method, The computer generates a first medical record report associated with the first patient care style rule for the transmitted data, The computer generates a second medical record report associated with the second patient care style rule for the transmitted data, The computer receives an approval timestamp after the reception date and indicates an approval date corresponding to only one of the first medical record report or the second medical record report, The method according to claim 9, comprising the step of the computer calculating whether the approval date is later than the first end date.

11. The method according to claim 8, wherein the plurality of patient care style rules correspond to a specific type of patient care.

12. The method according to claim 11, wherein the specific type of patient care is one of remote monitoring care, in-hospital care, or heart failure care.

13. The aforementioned method, The method according to claim 11, comprising the step of the computer generating an extended monitoring interval by acquiring data from a medical device platform, wherein the data corresponds to at least one procedure code.

14. The method according to claim 13, wherein the at least one procedure code is updated periodically.

15. A method for managing a cardiac monitoring device, wherein the method is The computer accesses multiple patient care style rules from a rules database, The steps include: the computer generating a plurality of monitoring intervals that are simultaneously active and associated with the cardiac monitoring device, at least in part based on the plurality of patient care style rules, wherein a first monitoring interval among the plurality of monitoring intervals has a first end date, and a second monitoring interval among the plurality of monitoring intervals has a second end date different from the first end date; The computer accesses the data transmitted from the cardiac monitoring device, The computer accesses the interval extension rules from the rule database, The computer generates an extended monitoring interval having an extended end date, based at least partially on the patient care style rules, according to the interval extension rules. A method comprising the step of the computer generating a date of service (DOS) for the transmitted data, wherein the DOS is the extended end date of the monitoring interval extension.

16. The transmitted data has a reception date, and the method is The method according to claim 15, comprising the step of the computer calculating that the reception date is later than the first end date or the second end date.

17. The aforementioned method, The computer generates a medical record report associated with the first monitoring interval or the second monitoring interval for the transmitted data, The computer receives an approval timestamp indicating an approval date later than the reception date and corresponding to the medical record report, The method according to claim 16, comprising the step of the computer calculating that the approval date is later than the first end date.

18. The method according to claim 15, wherein the patient care style rules correspond to a specific type of patient care.

19. The method according to claim 18, wherein the specific type of patient care is one of remote monitoring care, in-hospital care, or heart failure care.

20. The aforementioned method, The method according to claim 15, comprising the step of generating an extended monitoring interval by acquiring data from a medical device platform, wherein the data corresponds to at least one procedure code, and the at least one procedure code is updated periodically.

Images