Patent Description:
Many medical devices, such as some implanted heart pumps, should be monitored by medical personnel to ensure efficacy and patient safety. Some such medical devices have associated controllers that collect and display operational data about the medical devices, such as heart signal level, battery temperature and plumbing integrity. Some of these controllers raise alarms when operational data values fall beyond predetermined values or ranges, for example if a leak or loss of suction is detected. Many of these controllers include video display screens as human interfaces, on which the operational data and/or alarms are displayed.

In many cases, these medical devices are monitored remotely, especially in cases of ambulatory patients. In these cases, the controllers may be coupled via computer networks, often including wireless segments, to central servers, which may be accessed by monitoring stations. The monitoring stations may display real-time operational data and/or alarms on display screens for viewing by medical personnel. Typically, the servers also record the operational data, so operational data from earlier times can be "played back" upon request by the medical personnel.

However, computer network connections between the medical device controllers and the servers are often intermittent, i.e., subject to occasional gaps in computer network connectivity between the medical device controllers and the servers, particularly when the computer networks include wireless segments. The medical device controllers typically lack sufficient memory to store operational data during these gaps, or the device controllers lack an ability to detect these gaps. Thus, the medical device controllers cannot compensate for these gaps by transmitting operational data from earlier times, once a network connection is restored. Instead, the medical device controllers simply transmit their current operational data whenever computer network connections to the servers exist. Therefore, the operation data recorded by the servers often include gaps, corresponding to the gaps in computer network connectivity.

The servers record the operational data, as and when the operational data is received from the medical device controllers. However, during gaps in computer network connectivity, the servers pause recording, because the servers have nothing to record. Consequently, although recorded operational data is stored in contiguous data files, the stored data does not represent continuous time, which has made it impossible to index into a data file to a time of interest. Instead, in the prior art, medical personnel are limited to playing back the recorded operational data from the beginning of a data file, or guessing how far to index into the data file to find operational data that corresponds to the time of interest.

<NPL>, discloses monitors to be placed at different parts of a mobile health monitoring system for detecting failures of wireless connections between components of the system.

<CIT> discloses portable patient communicators (PPCs) comprising a first radio configured to communicate wirelessly with a patient implantable medical device (PIMD) associated with the PPC and a second radio configured to communicate wirelessly with a network. A memory is configured to store at least first information about wireless connectivity between the PPC and its associated PIMD. A processor is coupled to the memory and the first and second radios. A power source is configured to supply power to components of the PPC. The processor is configured to coordinate discontinuous communication between the PPC and its associated PIMD via the first radio and coordinate discontinuous communication between the PPC and the network via the second radio. The processor is configured to coordinate wireless transmission of the first information to a remote server via the network, and the remote server receives second information about wireless connectivity between each of the PPCs and the network.

<NPL>, discloses that a file's block can be stored contiguously or scattered about a storage device.

<NPL>, discloses that all blocks of a filed can be stored contiguously on a disk. Other types of block allocation are also mentioned, for example Scattered (random), Extent-based, Cylinder-based, Log-structured, Zoned and Constrained.

The scope of the invention is defined by the appended claims <NUM>-<NUM>. The examples, aspects and embodiments, if any, disclosed in the following description that do not fall within the scope of the claims are for reference only and are to be interpreted as examples useful for understanding various embodiments of the invention.

An embodiment of the present invention provides a data storage and retrieval system for non-contiguous medical device data. The system includes a medical device. The medical device is connectable to a computer network. The medical device is subject to occasional gaps in connectivity to the computer network. The medical device is configured to automatically repeatedly capture status information about the medical device and send messages containing the status information via the computer network.

The system also includes a network connectivity log. The network connectivity log is configured to automatically record times at which the medical device connects to the computer network. The network connectivity log is also configured to automatically record times at which the medical device disconnects from the computer network.

The system also includes a data store. The data store is configured to automatically store digital media data in a media file. The data store is also configured to automatically provide a requested portion, less than all, of the stored media file in response to a provision request. The provision request includes an index, relative to an end of the media file, that corresponds to the requested portion.

The system also includes a media server. The media server is connectable to the computer network. The media server is configured to automatically receive the messages via the computer network. The media server is also configured to automatically store status information from received messages into the data store. Status information from consecutive received messages is stored contiguously in the data store, notwithstanding the occasional gaps in connectivity between the medical device and the computer network.

The media server is also configured to automatically receive a status request that includes a time at which requested status information was captured. The media server is also configured to automatically access the network connectivity log and calculate an index, relative to an end of the media file, where the requested status information is stored. In performing this calculation, the media server is configured to take into account the occasional gaps in connectivity between the medical device and the computer network as represented in the network connectivity log.

The media server is also configured to automatically request a portion of the stored media file beginning at the calculated index. The media server is further configured to automatically provide the portion of the stored media file beginning at the calculated index.

In any embodiment, the data store may be further configured to store digital media data in at least one archive file. When the media file stores a predetermined amount of digital media data, the digital media data stored in the media file may be copied to the at least one archive file. In any embodiment, the data store may be configured to provide a requested portion, less than all, of the stored archive file in response to a provision request. The provision request may include an index, relative to an end of the archive file, that corresponds to the requested portion.

In any embodiment, the network connectivity log may be further configured to automatically record, for each period of connectivity to the computer network, information identifying one of the media file and the archive file where the digital media data is stored.

In any embodiment, the media server may be further configured to access the network connectivity log and calculate an index, relative to an end of the archive file, where the requested status information is stored. The calculation may take into account the occasional gaps in connectivity between the medical device and the computer network as represented in the network connectivity log.

In any embodiment, the media server may be further configured to request a portion of the stored archive file beginning at the calculated index. In any embodiment, the media server may be further configured to provide the portion of the stored archive file beginning at the calculated index.

In any embodiment, the media server may be further configured to automatically cause display of a pop-up message when a message indicates the medical device requires attention.

In any embodiment, the pop-up message may include a URL of a web page that contains additional information about the status of the medical device.

Any embodiment may also include an outgoing e-mail server configured to send an e-mail message when a message from the medical device indicates the medical device requires attention.

In any embodiment, the e-mail message may include a URL of a web page that contains additional information about the status of the medical device.

Another embodiment of the present invention provides a method for storing and retrieving non-contiguous medical device data. The method includes connecting a medical device to a computer network, subject to occasional gaps in connectivity to the computer network. The method further includes automatically repeatedly capturing, by the medical device, status information about the medical device and sending, by the medical device, messages containing the status information via the computer network. The method further includes automatically recording in a network connectivity log (a) times at which the medical device connects to the computer network and (b) times at which the medical device disconnects from the computer network.

The method further includes storing, in a data store, digital media data in a media file. The method further includes providing, by the data store, a requested portion, less than all, of the stored media file in response to a provision request. The provision request includes an index, relative to an end of the media file, that corresponds to the requested portion.

The method further includes receiving, by a media server, the messages via the computer network. The method further includes storing, by the media server, status information from received messages into the data store. Status information from consecutive received messages is stored contiguously in the data store, notwithstanding the occasional gaps in connectivity between the medical device and the computer network.

The method further includes receiving, by the media server, a status request that includes a time at which requested status information was captured. The method further includes accessing, by the media server, the network connectivity log and calculating an index, relative to an end of the media file. The requested status information is stored, taking into account the occasional gaps in connectivity between the medical device and the computer network as represented in the network connectivity log. The method further includes requesting, by the media server, a portion of the stored media file beginning at the calculated index. The method further includes providing, by the media server, the portion of the stored media file beginning at the calculated index.

In any embodiment, the method may further include storing digital media data in at least one archive file and, when the media file stores a predetermined amount of digital media data, copying the digital media data stored in the media file to the at least one archive file. A requested portion, less than all, of the stored archive file may be provided in response to a provision request. The provision request may include an index, relative to an end of the archive file, that corresponds to the requested portion. For each period of connectivity to the computer network, information identifying one of the media file and the archive file where the digital media data is stored may be automatically recorded in the network connectivity log.

In any embodiment, the network connectivity log may be accessed by the media server and an index may be calculated, relative to an end of the archive file, where the requested status information is stored, taking into account the occasional gaps in connectivity between the medical device and the computer network as represented in the network connectivity log.

In any embodiment, a portion of the stored archive file beginning at the calculated index may be requested by the media server. The portion of the stored archive file beginning at the calculated index may be provided by the media server.

In any embodiment, the method may further include automatically causing, by the media server, display of a pop-up message when a message indicates the medical device requires attention.

In any embodiment, the method may further include automatically sending, by an outgoing e-mail server, an e-mail message when a message from the medical device indicates the medical device requires attention.

Yet another embodiment of the present invention includes a non-transitory computer-readable medium encoded with instructions. When executed by a processor, the instructions establish processes for performing a computer-implemented method for storing and retrieving non-contiguous medical device data. The processes include a process configured to connect a medical device to a computer network, subject to occasional gaps in connectivity to the computer network. A process is configured to automatically repeatedly capture, by the medical device, status information about the medical device and send, by the medical device, messages containing the status information via the computer network. A process is configured to automatically record in a network connectivity log (a) times at which the medical device connects to the computer network and (b) times at which the medical device disconnects from the computer network.

A process is configured to store, in a data store, digital media data in a media file. A process is configured to provide, by the data store, a requested portion, less than all, of the stored media file in response to a provision request, wherein the provision request includes an index, relative to an end of the media file, that corresponds to the requested portion.

A process is configured to receive, by a media server, the messages via the computer network. A process is configured to store, by the media server, status information from received messages into the data store, wherein status information from consecutive received messages is stored contiguously in the data store, notwithstanding the occasional gaps in connectivity between the medical device and the computer network. A process is configured to receive, by the media server, a status request that includes a time at which requested status information was captured.

A process is configured to access, by the media server, the network connectivity log and calculate an index, relative to an end of the media file, where the requested status information is stored, taking into account the occasional gaps in connectivity between the medical device and the computer network as represented in the network connectivity log. A process is configured to request, by the media server, a portion of the stored media file beginning at the calculated index. A process is configured to provide, by the media server, the portion of the stored media file beginning at the calculated index.

The invention will be more fully understood by referring to the following Detailed Description of Specific Embodiments in conjunction with the Drawings, of which:.

Embodiments of the present invention provide data storage and retrieval systems and methods for non-contiguous medical device operational data. A web-based interface enables medical personnel to remotely monitor medical devices, such as implanted heart pumps. A monitoring system records operational data, such as battery temperature and alarms from the medical devices, in a file. However, since network connections between the medical devices and the monitoring system are intermittent, the file does not contain a contiguous stream of data for each medical device. Instead, the file simply records data when data is available. The file pauses recording during gaps in the data, i.e., during gaps in network connectivity. The file may be in the form of a video file, such as an MP4 file, although other suitable file formats may be used.

The system displays current, or most recently available, data, as well as a list of alarms. If medical personnel wish to view more detail about an earlier time or one of the alarms, the system calculates where in the file the medical device data was recorded. This calculation is novel and not obvious, due to the discontiguous nature of the data. For each medical device, the system records times the medical device connects via the network ("network connect events") and times the medical device network connection breaks ("network disconnect events"). The system uses these times to calculate an index into the file that corresponds to the time of the user-selected alarm.

Optionally, the system notifies users of alarms by sending e-mail messages and/or text messages and/or by displaying pop-up windows in browsers. The messages or pop-up windows may include links, such as URLs, to web pages that display information about the alarms. Users may click on the URL to open the web pages.

Unless otherwise indicated, the following terms, as used herein, shall have the following meanings.

Contiguous - sharing a common border, touching. Data, such as records, blocks, video frames, etc., that are stored contiguously are stored without space between consecutive elements.

Discontiguous - not contiguous; not sharing a common border; not touching. Data, such as records, blocks, video frames, messages, etc., that are stored discontiguously have space between consecutive elements. Data, such as records, blocks, video frames, messages, etc., that are received discontiguously have missing elements between consecutive received elements.

Continuous - forming an unbroken whole, without interruption.

Connect to a computer network - establish or reestablish a connection to the computer network, without necessarily establishing a new network session.

Disconnect from a computer network - lose, including temporarily, a connection to the computer network. For example, in a wireless computer network link, electrical noise, a strong signal from another station, a change in propagation characteristics, such as due to movement or change in orientation of an antenna, or interposition, between a transmitting antenna and a receiving antenna, of a material that attenuates or reflects electromagnetic waves, may temporarily cause loss of connectivity.

Digital media data - digital data that represent imagery, video and/or sound.

Consecutive - one element after another like element, without a third element between. For example, with two consecutive messages, one message follows the other, without a third message in between, although there may be a gap in time between the two messages.

Time - a time may include a date and a time within the date, for example <NUM>-<NUM>-<NUM><NUM>:<NUM>.

<FIG> is a schematic block diagram of major components of a data storage and retrieval system <NUM> for collecting, storing and retrieving operational data from and about medical devices, represented by exemplary medical devices <NUM>, <NUM> and <NUM>. Although three medical devices <NUM>-<NUM> are shown, other numbers of medical devices may be used. Each medical device <NUM>-<NUM> is connectable to a computer network <NUM>. Each medical device <NUM>-<NUM> is configured to automatically repeatedly capture status information about the medical device <NUM>-<NUM> and send messages containing the status information via the computer network <NUM>. In some embodiments, the status information is sent in the messages encoded as a video frame or a sequence of video frames. The video frame(s) may, for example, contain copies of images displayed on display screens of the medical devices <NUM>-<NUM>.

The computer network <NUM> may include wired and/or wireless segments. Each medical device <NUM>-<NUM> is, therefore, subject to occasional gaps in connectivity to or through the computer network <NUM>.

A data store <NUM> includes a media file <NUM>, such as an MP4 video or other suitable type of media file. As described in more detail below, the data store <NUM> records the status information about the medical devices <NUM>-<NUM>. The data store <NUM> is configured to automatically store digital media data, such as frames of video, in the media file <NUM>.

The data store <NUM> is also configured to provide a requested portion, less than all, of the stored media file <NUM> in response to a provision request. The data store <NUM> thereby supports playback of the medical device status information, as described in more detail below. For example, the data store <NUM> may provide one or more frames of video stored in the media file <NUM>, for display to a user.

Such a provision request includes an index, relative to the beginning or the end of the media file <NUM>. The index corresponds to the beginning of the requested portion, i.e., how far into the media file <NUM> the data store <NUM> must seek to reach the beginning of the requested portion. For example, the index may indicate an amount of time, or a number of video frames, from the beginning or the end of the media file <NUM> to where the requested portion begins. For example, a provision request may request a video frame that begins <NUM> minutes and <NUM> seconds (<NUM>:<NUM>) from the beginning of the media file <NUM>. In another example, a provision request may request a sequence of video frames that begins <NUM>,<NUM> frames from the end of the media file <NUM>.

Optionally, the data store <NUM> is configured to create and maintain one or more archive files, represented by archive file <NUM>. Although three archive files <NUM> are shown, any number of archive files <NUM> may be used. In some embodiments that are configured to maintain the archive files <NUM>, when the media file <NUM> reaches a predetermined size, such as about five hours' worth of status information, the data store <NUM> makes an archive copy <NUM> of the media file <NUM> and begins recording from the beginning of the media file <NUM>, thereby overwriting previously stored status information in the media file <NUM>. In some embodiments, after the media file <NUM> reaches the predetermined size, the data store <NUM> closes the media file <NUM>, renames the media file <NUM> to the next available archive file <NUM> name and creates a new media file <NUM>. Copying the contents of the media file <NUM> into the archive file <NUM> and closing and renaming the media file <NUM> to the next available archive file <NUM> are collectively herein referred to as copying the digital media data stored in the media file to the at least one archive file.

A media server <NUM> is connectable to the computer network <NUM> and is configured to automatically receive, via the computer network <NUM>, the messages containing the status information from the medical devices <NUM>-<NUM>. The media server <NUM> may parse the messages to extract the status information from the messages. For example, in some embodiments, the media server <NUM> includes an optical character recognizer (OCR) to recognize text in video frames sent by the medical devices <NUM>-<NUM>. In some embodiments, the media server <NUM> is communicably coupled to a separate OCR (not shown).

The media server <NUM> may then use the recognized text to automatically ascertain serial numbers or other identifiers of the medical devices <NUM>-<NUM>, operating parameters of the medical device <NUM>-<NUM>, whether an alarm has been raised by one of the medical devices <NUM>-<NUM>, etc. The media server <NUM> is further configured to store the status information from received messages into the data store <NUM>, typically in the form of video frames. In addition, as described below, the media server <NUM> facilitates playing back (displaying to a user) requested portions of the recorded medical device status information.

The media server <NUM> stores received status information into the data store <NUM> as the media server <NUM> receives the status information. However, the media server <NUM> does not receive messages from a given medical device <NUM>-<NUM> during the occasional gaps in connectivity to the computer network <NUM> experienced by the medical device <NUM>-<NUM>. The media server <NUM> pauses storing status information about the given medical device <NUM>-<NUM> into the data store <NUM> during each gap in network connectivity. Thus, status information from consecutive received messages may be stored contiguously in the data store, even if there is a time gap, represented by a network connectivity gap, between the consecutive received messages. Consequently, contiguous data in the media file <NUM> does not necessarily represent continuous time, i.e., status information continuously collected by a medical device <NUM>-<NUM>.

The status information from consecutive received messages is stored contiguously in the data store, notwithstanding the occasional gaps in connectivity between the medical device <NUM>-<NUM> and the computer network <NUM>. Additional components, which are described below, solve the problem of correctly indexing into the media file <NUM> to retrieve status information associated with a requested time, i.e., accounting for the non-contiguous nature of the status information conveyed by the received messages.

A network connectivity log <NUM> is configured to automatically record: (a) times at which each medical device <NUM>-<NUM> connects to the computer network <NUM> and (b) times at which each medical device <NUM>-<NUM> disconnects from the computer network <NUM>. A time at which a first message is received by the media server <NUM> from a given medical device <NUM>-<NUM> may be taken as the time the medical device <NUM>-<NUM> connects to the computer network <NUM>. If no message has been received by the media server <NUM> from a given medical device <NUM>-<NUM> for a predetermined timeout period, the medical device <NUM>-<NUM> may be assumed to have lost network connectivity, and the time at which the timeout is detected, minus the timeout period, may be taken as the time the medical device <NUM>-<NUM> disconnected from the computer network <NUM>.

After such a disconnect event, if a message is received by the media server <NUM> from the medical device <NUM>-<NUM>, the medical device <NUM>-<NUM> may be assumed to have again connected to the computer network <NUM>, and a time at which the message is received by the media server <NUM> from the given medical device <NUM>-<NUM> may be taken as the time the medical device <NUM>-<NUM> reconnects to the computer network <NUM>.

In some embodiments, the medical devices <NUM>-<NUM> periodically transmit or broadcast messages, without necessarily including any device status information. These messages are sent to indicate the respective medical devices <NUM>-<NUM> are operational. Receipt of these messages indicates the respective sending medical device <NUM>-<NUM> is connected, via the computer network <NUM>, to the recipient. Therefore, a cessation of receipt of these messages may be used as an indication the respective medical device <NUM>-<NUM> has lost computer network connectivity, i.e., the beginning of a gap in computer network connectivity. A time of this loss may be stored in the network connectivity log <NUM>.

If one of these messages is subsequently received, the respective medical device <NUM>-<NUM> may be assumed to again be connected to the computer network <NUM>, and a time of this reconnection may be stored in the network connectivity log <NUM>. More detailed descriptions of several embodiments of the network connectivity log <NUM> are provided herein.

All the messages from a given medical device <NUM>-<NUM> to the media server <NUM> may be carried over a single network session, despite gaps in the network connectivity. Alternatively, each or some of the gaps may cause termination of a network session, and resumption of network connectivity may cause creation of a new network session.

<FIG> is an isometric view of an exemplary medical device <NUM>. The exemplary medical device <NUM> is an intravascular blood pump. However, many other kinds of suitable medical devices may be used as each of the medical devices <NUM>-<NUM> in <FIG>. The pump <NUM> includes a pump handle <NUM>, a pump head <NUM>, a catheter <NUM> connecting the pump handle <NUM> to the pump head <NUM>, and a connecting hub <NUM>. The catheter <NUM> is tubular and has a substantially uniform outer diameter <NUM>. The catheter <NUM> enables the pump head <NUM> to be in electro-mechanical communication with the pump handle <NUM>.

The pump handle <NUM> is in communication with control circuitry (described below), which allows control of the pump head <NUM>. The pump head <NUM> contains electro-mechanical components that enable the device to perform various tasks within the body of a human patient, such as pump blood from a location within the body. The pump head <NUM> has a diameter <NUM> that is larger than the diameter <NUM> of the catheter <NUM>. An example of such a percutaneous pump <NUM> is the Impella <NUM>® blood pump system available from Abiomed, Inc. , Danvers, Massachusetts. This blood pump system includes the pump <NUM> and an Automatic Impella Controller (AIC) controller for the pump <NUM>.

<FIG> is a front view of an exemplary medical device controller <NUM>, such as the above-mentioned Automatic Impella Controller (AIC) controller, that may be coupled to the medical device <NUM> of <FIG> and included in embodiments of the present invention. The medical device controller <NUM> provides a human interface for monitoring and controlling functions of the pump <NUM>. The medical device controller <NUM> may include a display screen <NUM> that displays images of a video stream, in which the images illustrate data associated with the medical device <NUM> over time. In some implementations, the display screen <NUM> displays real-time operating and/or medical data associated with the pump <NUM>.

<FIG> is an exemplary hypothetical image (frame) <NUM> displayed on the display screen <NUM> of the medical device controller <NUM> of <FIG>. The image <NUM> may include waveforms <NUM> illustrating medical and/or operational data corresponding to operation of the corresponding pump <NUM>. Examples of medical data illustrated by the waveforms <NUM> include placement signal and motor current. The waveforms <NUM>, such as the motor current waveform, may provide a history, representation and/or illustration of motor current over a period time, for example <NUM> seconds. In this way, the image <NUM> includes motor current data, and possibly other data (collectively status information about the medical device <NUM>-<NUM>), associated with the pump <NUM> over a period of time, such as <NUM> seconds.

As shown schematically in <FIG>, a medical device <NUM> may be communicably coupled to an associated medical device controller <NUM>, as discussed above. In some embodiments, the medical device controller <NUM> is directly communicably coupled to the computer network <NUM> and sends a stream of video frames, representing real time (current) contents of the display screen <NUM> (<FIG>), via the computer network <NUM>. Alternatively, the medical device controller <NUM> may periodically, such as every <NUM> seconds, or occasionally, capture a frame of the video representing the current contents of the display screen <NUM> and send that video frame.

However, some medical device controllers <NUM> are incapable of sending video frames via the computer network <NUM>. In such cases, a remote link module <NUM> may be communicably coupled to the medical device controller <NUM>, such as via a cable <NUM> connected to a video output port <NUM> of the medical device controller <NUM>. The remote link module <NUM> may thereby receive a video signal representative of the contents of the display screen <NUM> (<FIG>). The remote link module <NUM> may also be communicably coupled to the computer network <NUM>.

The remote link module <NUM> may send a stream of video frames, representing real time (current) contents of the display screen <NUM> (<FIG>), via the computer network <NUM>. Alternatively, the remote link module <NUM> may periodically, such as every <NUM> seconds, or occasionally, capture a frame of the video representing the current contents of the display screen <NUM> and send that video frame. Additional information about the remote link module <NUM> is available in <CIT>, assigned to the assignee of the present invention and titled "Systems and Methods for Capturing Data from a Medical Device.

For simplicity of explanation, the medical device <NUM> (<FIG>) or <NUM> (<FIG>), its associated medical device controller <NUM> (<FIG>) or <NUM> (<FIG>) and, if used, its associated remote link module <NUM> (<FIG>) are referred to herein collectively as one of the medical devices <NUM>-<NUM>. As discussed with respect to <FIG>, each medical device <NUM>-<NUM> is connectable to the computer network <NUM>.

As noted, the media server <NUM> (<FIG>) may include or use an optical character recognizer (OCR) that parses predefined regions of the video frames received from the medical devices <NUM>-<NUM>, for example to convert text displayed in the video frames to computer character data, such as ASCII or UNICODE. For example, region <NUM> (<FIG>) may be parsed by the OCR to extract the medical device serial number (S/N) and any error indicators, ex. "Impella Stopped," "Air In Purge System" and "Impella Stopped. Retrograde Flow. assigned to the assignee of the present application and titled "Systems and Methods for Time-Based One-Time Password Management for a Medical Device," describes such an OCR mechanism.

<FIG> is a schematic block diagram of the media server <NUM>, including an automatic optical character recognizer <NUM>. However, as noted, the OCR may be a separate component. As noted, the media server <NUM> (<FIG>) may recognize text in video frames sent by the medical devices <NUM>-<NUM> to automatically ascertain serial numbers or other identifiers of the medical devices <NUM>-<NUM>, operating parameters of the medical device <NUM>-<NUM>, whether an alarm has been raised by one of the medical devices <NUM>-<NUM>, etc. In other embodiments, the medical device serial numbers or other identifiers, operating parameters, alarms, etc. may be encoded as metadata that accompany the video frame(s), and the media server <NUM> may access this metadata instead of, or in addition to, recognizing text in the video frame(s).

A web server <NUM> (<FIG>), such as an HTTP server, serves web pages to clients, represented by monitoring stations (clients) <NUM> and <NUM>. The monitoring stations <NUM> and <NUM> may be computers executing conventional web browsers. Although two monitoring stations <NUM>-<NUM> are shown, any number of monitoring stations may be included. The web server <NUM> communicates with the media server <NUM>, such as to obtain a list of medical devices <NUM>-<NUM>, for which status information is available live or for playback from the data store <NUM>.

The web pages enable users of the monitoring stations <NUM>-<NUM> to select and then monitor individual medical devices <NUM>-<NUM>. For example, a web page, exemplified by a web page <NUM> shown in <FIG>, may display a list of available medical device <NUM>-<NUM> serial numbers or other identifiers, and the web page <NUM> may solicit a user to select one of the medical devices <NUM>-<NUM> to monitor, such as by clicking on one of the displayed medical device identifiers.

<FIG> illustrates an exemplary hypothetical web page <NUM> generated by the web server <NUM>. The web page <NUM> displays "live" status information about one of the medical devices <NUM>-<NUM>. A portion <NUM> of the web page <NUM> reproduces part or all of the imagery displayed on the corresponding medical device's controller screen <NUM> (<FIG>). The web server <NUM> (<FIG>) obtains video frames from the media server <NUM> to generate and update the web page <NUM>, including the portion <NUM>. In some embodiments, the web server <NUM> streams the video frames from the media server <NUM> to the monitoring station <NUM> or <NUM> for display in the portion <NUM>.

As noted, the media server <NUM> may automatically ascertain whether an alarm has been raised by one of the medical devices <NUM>-<NUM>. In addition, the media server <NUM> may analyze portions of the imagery from the medical devices <NUM>-<NUM> to automatically detect anomalies or other conditions that warrant attention, and/or the media server <NUM> may automatically detect undesirable conditions, such as sub-par computer network connectivity. Sub-par computer network connectivity may, for example, be declared if computer network connectivity, as measured by a percentage of "up" time, drops below a predetermined value, an excessive number gaps in computer network connectivity is detected, or an excessive total gap time over a predetermined period of time for a given medical device <NUM>-<NUM> is detected.

A portion <NUM> ("Alert Summary") of the web page <NUM> (<FIG>) contains a list of alarms, warnings, anomalies, conditions that warrant attention, etc. Each such alert may be color coded according to urgency or significance. Each alert displays a time, at which the alert was generated or detected. Some alerts also display additional information. The alerts are listed in chronological order, with the most recent alert at the top of the list. If the portion <NUM> is insufficiently large to list all the alerts, older alerts may be hidden and made accessible via scroll elements (not shown) on the web page <NUM>. A user clicking on one of the displayed alerts causes the web server <NUM> to replace the live portion <NUM> of the web page <NUM> with a reproduction of part or all of the imagery displayed on the corresponding medical device's controller screen <NUM> (<FIG>) at the time of the alert, as described in more detail below.

A third portion <NUM> of the web page <NUM> (<FIG>) includes buttons <NUM>, <NUM> and <NUM> that enable a user to select among "Live" <NUM> view (described above), a previous time period, such as "Previous <NUM> Hours" <NUM>, or an "Archive" <NUM> of recorded medical device status information. In some embodiments, the data store <NUM> (<FIG>) records status information about each medical device <NUM>-<NUM> in the media file <NUM> for up to a fixed amount of time, such as about five hours, and thereafter makes an archive copy <NUM> of the media file <NUM> and begins recording in a new media file <NUM>. Alternatively, the data store <NUM> renames the media file <NUM> as the next available archive file <NUM> and creates a new media file <NUM>. In yet another embodiment, after the media file <NUM> is filled with the fixed amount of status information, such as about five hours' worth of data, as additional status information is received and recorded into the media file <NUM>, a corresponding amount of the oldest data in the media file <NUM> is moved to an archive file <NUM>. In this way, the media file <NUM> contains the most recent (in this example five hours) status information.

Clicking on the "Previous <NUM> Hours" button <NUM> causes the web server <NUM> to replace the live portion <NUM> of the web page <NUM> with a reproduction of part or all of the imagery displayed on the corresponding medical device's controller screen <NUM> (<FIG>) earlier, up to five hours earlier, in time than the present time. <FIG> is an exemplary hypothetical web page <NUM> generated by the web server <NUM> to display previously recorded status information about one of the medical devices <NUM>-<NUM>. As in the live display, a portion <NUM> of the web page <NUM> reproduces part or all of the imagery displayed on the corresponding medical device's controller screen <NUM> (<FIG>), except from an earlier time.

Another portion <NUM> of the web page <NUM> includes user interface controls that enable a user to play/stop <NUM> the status information in the portion <NUM>, view the time <NUM> at which the currently displayed <NUM> status information was received, back up (rewind) <NUM> seconds <NUM> from the currently displayed status information, back up (rewind) <NUM> seconds <NUM> from the currently displayed status information, skip forward (fast forward) <NUM> seconds <NUM> beyond the currently displayed status information and skip forward (fast forward) <NUM> seconds <NUM> beyond the currently displayed status information. In some embodiments, the time <NUM> may be entered by a user to specify a specific time at which playback is to begin.

A third region <NUM> of the web page <NUM> contains an Alert Summary and operates in a manner similar to the Alert Summary <NUM> described with respect to <FIG>.

As noted, in some embodiments, the media file <NUM> (<FIG>) contains only up to a predetermined amount of status information, such as about five hours' worth of status information, and older status information is stored in one of possibly many archive files <NUM>. The "Archive" button <NUM> (<FIG> and <FIG>) enables a user to command playback of medical device status information from an archive file <NUM>.

Although one media file <NUM> is shown in <FIG>, for live monitoring the media file <NUM> may comprise several files, as indicated at <NUM>. Multiple media files <NUM> may be used, particularly if simultaneous read and write access to a single media file <NUM> is not supported by an operating system or data storage facility. In this case, each file of the multiple media files <NUM> stores a relatively short time period's status information, such as about five minutes' worth of status information. Consequently, one file of the multiple media files <NUM> may be written to, as messages are received from the medical devices <NUM>-<NUM>, and the remaining files of the multiple media files <NUM> may be read to support playback of the status information to the monitoring stations <NUM>-<NUM>.

The media file <NUM> may be implemented using network digital video recorder (nDVR) technology, such as the Wowza nDVR technology and the Wowza Streaming Engine, both available from Wowza Media Systems, LLC, <NUM> Park Point Drive, Suite <NUM>, Golden, CO <NUM>.

As noted, each medical device <NUM>-<NUM> (<FIG>) sends a stream of status information messages via the computer network <NUM>. Each message may be carried by an individual network packet, or a message may require several network packets to transport the message. The messages and/or the packets may include sequence numbers to facilitate detecting gaps in the message stream. Optionally or alternatively, non-receipt of any message or packet from a given medical device <NUM>-<NUM> for a predetermined period of time may be used to indicate a gap in computer network connectivity.

The media server <NUM> (<FIG>) stores received status information into the data store <NUM> as the media server <NUM> receives the status information from the medical devices <NUM>-<NUM>. The media server <NUM> pauses storing status information about a given medical device <NUM>-<NUM> into the data store <NUM> during each gap in network connectivity with the medical device <NUM>-<NUM>, as schematically illustrated in <FIG>. Hypothetical exemplary times during which status information is received from a given medical device <NUM>-<NUM> are indicated by respective periods of computer network connectivity (data blocks) <NUM>, <NUM>, <NUM>, <NUM> and <NUM>. Gaps in computer network connectivity, such as gaps <NUM> and <NUM>, occur between respective consecutive pairs of the data blocks, such as between data block pair <NUM>-<NUM> and between data block pair <NUM>-<NUM>, from individual ones of the medical devices <NUM>-<NUM>.

Although the network packets of a given message from a given medical device <NUM>-<NUM>, or the network packets of a sequence of messages from the given medical device <NUM>-<NUM>, may arrive spaced apart in time, the time between packets is not considered a gap in network connectivity. Instead, as used herein, a gap in network connectivity prevents receipt of at least one message from a medical device <NUM>-<NUM> and is detectable by the media server <NUM>.

Times at which computer network connectivity begins (connect events) and ends (disconnect events) are indicated at <NUM>. Collectively, the data blocks <NUM>-<NUM> are referred to as network traffic <NUM> from the medical device <NUM>-<NUM>. The network traffic <NUM> is discontiguous, in that the data blocks <NUM>-<NUM> do not share any common boundaries. Gaps <NUM>-<NUM> occur between adjacent data messages <NUM>-<NUM>.

Each message <NUM>-<NUM> may include one or more video frames, as indicated at <NUM>. The media server <NUM> stores the status information in the media file <NUM> (<NUM>). Thus, status information from consecutive received data blocks, for example data blocks <NUM> and <NUM>, may be stored contiguously, as indicated at <NUM>, in the data store <NUM>, even if there is a time gap <NUM> between the consecutive received data blocks <NUM> and <NUM>. Consequently, the entire media file <NUM> stores data contiguously.

The media file <NUM> (<NUM>) may be accessed using an index, for example a time index or a frame index, represented by exemplary index <NUM>. The index <NUM> indicates how far from the beginning of the media file <NUM> (<NUM>) data of interest begins, i.e., the index <NUM> is a pointer, relative to the beginning of the media file <NUM> (<NUM>). Similarly, any of the archive files <NUM> (<FIG>) may be accessed using an index <NUM>. However, in some cases, the index <NUM> may indicate how far from the end of the media file <NUM> data of interest begins.

As noted, the network connectivity log <NUM> (<FIG>) is configured to automatically record: (a) times at which each medical device <NUM>-<NUM> connects to the computer network <NUM> and (b) times at which each medical device <NUM>-<NUM> disconnects from the computer network <NUM>. <FIG> is a schematic diagram illustrating data fields <NUM>, and hypothetical exemplary contents, of the network connectivity log <NUM>, according to an embodiment of the present invention. The network connectivity log <NUM> includes one record for each computer network connect event and one record for each computer network disconnect event.

Each record includes: a field <NUM> that identifies a medical device, such as by a medical device serial number; a time field <NUM> that identifies a time at which the medical device identified in field <NUM> experiences an event; an event type field <NUM> that indicates whether the corresponding event is a connect event or a disconnect event; and a field <NUM> that indicates in which file (media file <NUM> or one of the archive files <NUM>) status information, for example video frames, from the event is stored.

For simplicity, the hypothetical exemplary contents of the data fields <NUM> include information about only one medical device (IC2958). However, information about other medical devices may be interspersed in the network connectivity log <NUM>. That is, records for a variety of medical devices <NUM>-<NUM> may be stored in a single network connectivity log <NUM>.

When a user commands playback of non-live, i.e., recorded, medical device status information, the media server <NUM> (<FIG>) automatically ascertains which file, i.e., the media file <NUM> or one of the archive files <NUM>, contains the desired medical device status information, and the media server <NUM> calculates the index <NUM> or <NUM> (<FIG>), relative to the beginning or end of the appropriate file <NUM>, where the requested status information is stored. The user may command playback of non-live medical device status information through the web pages <NUM> and <NUM> (<FIG> and <FIG>). For example, the user may click on an alert <NUM> (<FIG>) or <NUM> (<FIG>), select "Previous <NUM> Hours" <NUM> or "Archive" <NUM> (<FIG>), back up <NUM> or <NUM> (<FIG>) or skip forward <NUM> or <NUM> in time, or enter a specific time <NUM> at which playback is to begin. In response, the media server <NUM> uses the network connectivity log <NUM> fields <NUM> (<FIG>) to automatically ascertain which file, i.e., the media file <NUM> or one of the archive files <NUM>, contains the desired medical device status information. In addition, the media server <NUM> calculates the index <NUM> or <NUM> (<FIG>), relative to the beginning or end of the appropriate file <NUM>, where the requested status information is stored.

When the user commands playback of non-live medical device status information, the user implicitly or explicitly specifies a time at which the status information of interest was received by the media server <NUM>. For example, each alert in the Alert Summary <NUM> (<FIG>) or <NUM> (<FIG>) has an associated time. Clicking on an alert causes the web server <NUM> to use the time of the selected alert. Invoking the "back up <NUM> seconds" button <NUM> causes the web server <NUM> to calculate a time <NUM> seconds earlier than the time of the currently displayed status information. Similarly, invoking the "skip forward <NUM> seconds" button <NUM> causes the web server <NUM> to calculate a time <NUM> seconds later than the time of the currently displayed status information. Optionally, the user may enter a specific time <NUM>.

The media server <NUM> searches the network connectivity log <NUM> fields <NUM> (<FIG>) for a connect-disconnect event pair (for the specified medical device ID, field <NUM>) that spans the implicitly or explicitly specified time. If such a connect-disconnect event pair is found, the field <NUM> identifies in which file the status information is stored. If no such connect-disconnect event pair is found, no status information for the specified time is available, and an error message may be displayed to the user.

<FIG> contains a flowchart schematically illustrating a process <NUM> for calculating the index <NUM> (<FIG>). The process <NUM> accepts two input parameters: a time of interest (Time) and a medical device identifier (Device ID), i.e., an identifier of one of the medical devices <NUM>-<NUM>. The time of interest (Time) may be a time implicitly or explicitly specified by the user, such as by selecting a particular alert in an Alert Summary <NUM> or <NUM> (<FIG> or <FIG>), or by clicking the "back up <NUM> seconds" button <NUM>.

At <NUM>, an internal variable (Offset within Media File) is initialized to zero, and the process <NUM> enters a loop. At the beginning of the loop, at <NUM>, the first network connect event entry for the specified medical device (Device ID) is fetched from the network connectivity log <NUM>, and the time of the connect event is stored in a temporary variable (Segment Connect Time). At <NUM>, the first network disconnect event entry for the specified medical device (Device ID) is fetched from the network connectivity log <NUM>, and the time of the disconnect event is stored in a second temporary variable (Segment Disconnect Time). The term "segment" here refers to a period of continuous network connectivity for the specified medical device <NUM>-<NUM>.

A duration of the computer network connection (the segment) is calculated by subtracting the Segment Connect Time from the Segment Disconnect Time, and the result of the calculation is stored in a third temporary variable (Segment Duration).

At <NUM>, the time of interest (Time) is compared to the Segment Connect Time and to the Segment Disconnect Time to ascertain whether the time of interest (Time) is between the Segment Connect Time and the Segment Disconnect Time, i.e., whether the time of interest (Time) occurs during the current segment (period of network connectivity). At <NUM>, if the time of interest (Time) is between the Segment Connect Time and the Segment Disconnect Time, control passes to <NUM>. At <NUM>, another temporary variable (Offset within Segment) is calculated by subtracting Segment Connect Time from the time of interest (Time). The Offset within Segment indicates how far into the current segment (period of network connectivity) the time of interest occurs. A graphic example of a hypothetical Offset within Segment value is shown at <NUM> (<FIG>).

At <NUM>, a return value (Index) is calculated by adding the Offset within Segment to the Offset within Media File. This return value (Index) corresponds to the index <NUM> exemplified in <FIG>. Control returns to the caller of the procedure <NUM>.

If, however, at <NUM>, the time of interest (Time) is not between the Segment Connect Time and the Segment Disconnect Time, control passes to <NUM>. The time of interest (Time) does not occur during the current segment (period of network connectivity). At <NUM>, the time of interest (Time) is compared to the Segment Connect Time. If the time of interest (Time) is before, i.e., less than, the Segment Connect Time, the time of interest (Time) occurred before the next segment of network connectivity, i.e., during a gap in network connectivity. Consequently, the media or archive file <NUM> or <NUM> does not contain status information for the time of interest (Time). Control passes to <NUM>, where an error (Time not in Medial Archive File) is returned, and control returns to the caller of the procedure <NUM>.

On the other hand, at <NUM>, if the time of interest (Time) is not less than, i.e., not before, the Segment Connect Time, control passes to <NUM>. A subsequent segment may include the time of interest (Time). The Offset within Media File is increased by the Segment Duration, shifting the Offset within Media File to the beginning of the next segment in the media or archive file. Control returns to the beginning of the loop, i.e., to <NUM>, where the next network connect event entry is fetched from the network connectivity log <NUM>.

If a monitoring station <NUM>-<NUM> is displaying recent information, such as the "previous <NUM> hours" web page <NUM> (<FIG>), it may be more convenient to use an index <NUM> (<FIG>) relative to the end of a media file <NUM>, rather than the index <NUM> from the beginning of the media file <NUM>. As new messages arrive from the corresponding medical device <NUM>-<NUM>, new status information is added to the end of the media file <NUM>. Thus, the end of the media file <NUM> contains the most recent status information. Typically, a user is interested in the most recent status information, and the user interface controls <NUM>-<NUM> enable the user to back up or skip forward, relative to the displayed information. Thus, calculating the index relative to the end of the media file <NUM>, rather than relative to the beginning of the media file <NUM>, may be advantageous, at least in certain circumstances.

The process <NUM> may be easily modified to calculate the index relative to the end of the media file <NUM>. According to this modification, in operation <NUM>, the Offset within Segment is calculated by subtracting the time of interest (Time) from the Segment Disconnect Time. In operation <NUM>, the time of interest (Time) is compared to the Segment Disconnect Time. If the time of interest (Time) is greater than, i.e., later than, the Segment Disconnect Time, control passes to <NUM>, otherwise control passes to <NUM>.

As used in the claims, "an end of the media file" refers to either the beginning of the media file or the end opposite the beginning of the media file. In other words, an end of the media file refers to either end of the media file.

As noted, when a user commands playback of non-live, i.e., recorded, medical device status information, the web server <NUM> sends a status request, including a time of interest, to the media server <NUM> (<FIG>). In response, the media server <NUM> automatically ascertains which file, i.e., the media file <NUM> or one of the archive files <NUM>, contains the desired medical device status information, and the media server <NUM> calculates the index <NUM> or <NUM> (<FIG>), relative to the beginning or end of the appropriate file <NUM>, where the requested status information is stored. The media server <NUM> uses the process <NUM> of <FIG> to calculate the index <NUM> or <NUM>. The media server <NUM> then fetches stored status information stored in the media file <NUM> or archive file <NUM>, as the case may be, that begins at the calculated index. The media server <NUM> provides the fetched status information to the web server <NUM>, and the web server <NUM> provides the status information to the appropriate client <NUM> or <NUM>.

Thus, the media server <NUM> is configured to receive a status request that includes a time at which requested status information was captured. The media server <NUM> is also configured to access the network connectivity log <NUM> and calculate the index <NUM> (<FIG>), relative to the beginning or end of the media or archive file <NUM>, where the requested status information is stored, taking into account the occasional gaps <NUM>, <NUM>, etc., in computer network connectivity between the medical device <NUM>-<NUM> and the computer network <NUM>, as represented in the network connectivity log <NUM>. The media server <NUM> is also configured to request a portion of the stored media file <NUM> or archive file <NUM> beginning at the calculated index <NUM>. The media server <NUM> is further configured to provide the portion of the stored media file <NUM> or archive file <NUM> beginning at the calculated index <NUM>.

Optionally, the web server <NUM> displays pop-up message, exemplified by a hypothetical pop-up message <NUM> in <FIG>, on one or more of the monitoring stations <NUM>-<NUM> when a new alert is raised. A web application executed in conjunction with the media server <NUM> and/or the web server <NUM> may create the pop-up message. The pop-up message may include a clickable link that includes a URL which, if invoked, transfers to a web page similar to the web page of <FIG>, as though the user clicked on the corresponding alert in region <NUM> or <NUM> (<FIG>).

Optionally, an outgoing e-mail server (SMTP server) <NUM> (<FIG>) sends an e-mail message to one or more predefined e-mail addresses whenever an alert is raised. <FIG> illustrates an exemplary hypothetical e-mail message <NUM>. The e-mail message <NUM> may include information about the alert, as well as a link <NUM> that includes a URL which, if invoked, opens a web page similar to the web page of <FIG>, as though the user clicked on the corresponding alert in region <NUM> or <NUM> (<FIG>).

The media server <NUM>, web server <NUM> and data store <NUM> may be implemented by a processor executing instructions stored in a memory. The instructions may include instructions for implementing the process <NUM> described with reference to <FIG>, as well as processes described with reference to <FIG>, <FIG>, <FIG> and <FIG>.

The network connectivity log <NUM> may be implemented with a relational database and may include a front end (load balancer) that distributes access requests across multiple copies of the database to support a high volume of requests. Similarly, the data store <NUM> may include a front end (load balancer) that distributes load across multiple copies of the media file <NUM> and/or the archive files <NUM>. The web server <NUM> and/or the media server <NUM> may include respective front ends (load balancers) that distribute load across multiple copies of the web server <NUM> and/or the media server <NUM>.

In some embodiments, one media file <NUM> stores status information from only one of the medical devices <NUM>-<NUM>, i.e., each medical device has an associated media file <NUM>. However, in other embodiments, one media file <NUM> stores status information from multiple medical devices <NUM>-<NUM>. Similarly, one archive file <NUM><NUM> may service one or multiple medical devices <NUM>-<NUM>.

While the invention is described through the above-described exemplary embodiments, modifications to, and variations of, the illustrated embodiments may be made without departing from the inventive concepts disclosed herein. For example, although specific parameter values, such as timeouts and recording times, may be recited in relation to disclosed embodiments, within the scope of the invention, the values of all parameters may vary over wide ranges to suit different applications. Unless otherwise indicated in context, or would be understood by one of ordinary skill in the art, terms such as "about" mean within ±<NUM>%.

As used herein, including in the claims, the term "and/or," used in connection with a list of items, means one or more of the items in the list, i.e., at least one of the items in the list, but not necessarily all the items in the list. As used herein, including in the claims, the term "or," used in connection with a list of items, means one or more of the items in the list, i.e., at least one of the items in the list, but not necessarily all the items in the list. "Or" does not mean "exclusive or.

Although aspects of embodiments may be described with reference to flowcharts and/or block diagrams, functions, operations, decisions, etc. of all or a portion of each block, or a combination of blocks, may be combined, separated into separate operations or performed in other orders. All or a portion of each block, module or combination thereof may be implemented as computer program instructions (such as software), hardware (such as combinatorial logic, Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), processor or other hardware), firmware or combinations thereof.

The media server <NUM>, data store <NUM>, web server <NUM> and/or network connectivity log <NUM>, or portions thereof, may be implemented by one or more processors executing, or controlled by, instructions stored in a memory. Each processor may be a general purpose processor, such as a central processing unit (CPU), a graphic processing unit (GPU), digital signal processor (DSP), a special purpose processor, etc., as appropriate, or combination thereof.

The memory may be random access memory (RAM), read-only memory (ROM), flash memory or any other memory, or combination thereof, suitable for storing control software or other instructions and data. Instructions defining the functions of the present invention may be delivered to a processor in many forms, including, but not limited to, information permanently stored on tangible non-transitory non-writable storage media (e.g., read-only memory devices within a computer, such as ROM, or devices readable by a computer I/O attachment, such as CD-ROM or DVD disks), information alterably stored on tangible non-transitory writable storage media (e.g., floppy disks, removable flash memory and hard drives) or information conveyed to a computer through a communication medium, including wired or wireless computer networks. Moreover, while embodiments may be described in connection with various illustrative data structures, systems may be embodied using a variety of data structures.

Disclosed aspects, or portions thereof, may be combined in ways not listed above and/or not explicitly claimed. In addition, embodiments disclosed herein may be suitably practiced, absent any element that is not specifically disclosed herein. Accordingly, the invention should not be viewed as being limited to the disclosed embodiments.

Claim 1:
A data storage and retrieval system (<NUM>) for non-contiguous medical device data, the system comprising:
a medical device (<NUM>; <NUM>; <NUM>), connectable to a computer network (<NUM>), subject to occasional gaps in connectivity to the computer network, and configured to automatically repeatedly capture status information about the medical device (<NUM>; <NUM>; <NUM>) and send messages containing the status information via the computer network (<NUM>);
a network connectivity log (<NUM>) configured to automatically record: (a) times at which the medical device (<NUM>; <NUM>; <NUM>) connects to the computer network (<NUM>) and (b) times at which the medical device (<NUM>; <NUM>; <NUM>) disconnects from the computer network (<NUM>);
a data store (<NUM>) configured to automatically:
store digital media data in a media file (<NUM>); and
provide a requested portion, less than all, of the stored media file (<NUM>) in response to a provision request, wherein the provision request includes an index, relative to an end of the media file (<NUM>), that corresponds to the requested portion;
a media server (<NUM>), connectable to the computer network (<NUM>) and configured to automatically:
receive the messages via the computer network (<NUM>);
store status information from received messages into the data store (<NUM>), wherein status information from consecutive received messages is stored contiguously in the data store (<NUM>), notwithstanding the occasional gaps in connectivity between the medical device (<NUM>; <NUM>; <NUM>) and the computer network (<NUM>);
receive a status request that includes a time at which requested status information was captured;
access the network connectivity log (<NUM>) and calculate an index, relative to an end of the media file (<NUM>), where the requested status information is stored, taking into account the occasional gaps in connectivity between the medical device (<NUM>; <NUM>; <NUM>) and the computer network (<NUM>) as represented in the network connectivity log (<NUM>);
request a portion of the stored media file (<NUM>) beginning at the calculated index; and
provide the portion of the stored media file (<NUM>) beginning at the calculated index;
wherein the end of the media file is either the beginning of the media file or the end opposite the beginning of the media file, such that the end of the media file refers to either end of the media file.