Medical device system and method having a distributed database

Information

  • Patent Grant
  • 11495334
  • Patent Number
    11,495,334
  • Date Filed
    Wednesday, June 22, 2016
    8 years ago
  • Date Issued
    Tuesday, November 8, 2022
    a year ago
Abstract
A medical device system (10) including a distributed database (10a to 10f); a plurality of medical devices (12) operating with the distributed database (10a to 10f); and a logic implementer (20) associated with each medical device (12), wherein each logic implementer (20) is programmed to access the distributed database (10a to 10f), so that each medical device (12) of system (10) periodically (i) delivers at least one of prescription input parameters or treatment output data to and (ii) retrieves at least one of prescription input parameters or treatment output data from each of the other medical devices (12).
Description
PRIORITY CLAIM

The present application is a National Phase of International Application No. PCT/EP2016/064392, filed on Jun. 22, 2016, which claims priority to Swedish Patent Application No. 1550885-6, filed on Jun. 25, 2015, the entire contents of each of which are being incorporated herein by reference.


BACKGROUND

The present disclosure relates generally to computer networks. More specifically, the present disclosure relates to computer networks for medical devices that pump fluids.


Hemodialysis (“HD”) in general uses diffusion to remove waste products from a patient's blood. A diffusive gradient that occurs across the semi-permeable dialyzer between the blood and an electrolyte solution called dialysate causes diffusion. Hemofiltration (“HF”) is an alternative renal replacement therapy that relies on a convective transport of toxins from the patient's blood. This therapy is accomplished by adding substitution or replacement fluid to the extracorporeal circuit during treatment (typically ten to ninety liters of such fluid). The substitution fluid and the fluid accumulated by the patient in between treatments is ultrafiltered over the course of the HF treatment, providing a convective transport mechanism, which is particularly beneficial in removing middle and large molecules (in hemodialysis there is a small amount of waste removed along with the fluid gained between dialysis sessions, however, the solute drag from the removal of that ultrafiltrate is typically not enough to provide convective clearance).


Hemodiafiltration (“HDF”) is a treatment modality that combines convective and diffusive clearances. HDF flows dialysate through a dialyzer, similar to standard hemodialysis, providing diffusive clearance. In addition, substitution solution is provided directly to the extracorporeal circuit, providing convective clearance.


The above modalities are provided by a dialysis machine. The machines can be provided in a center or in a patient's home. Dialysis machines provided in a center are used multiple times a day for multiple patients. Prescription input data is inputted into the dialysis machines before treatment, while treatment output data is collected from the dialysis machines during and after treatment. The data is useful to the clinic to track how the patient's treatment is proceeding over time, so that the treatment can be modified if needed. The data is also useful to see how a particular machine is performing. For example, if the data indicates that a particular machine is alarming for the same reason over multiple treatments with different patients, the clinic may determine that the problem is with the machine, not the patients. The data is also useful as a basis for billing and reimbursement purposes. The data can track how many different drugs or solutions (e.g., heparin or saline) and disposables are consumed over a treatment, so that the clinic can then bill and be reimbursed for the proper amount for the materials consumed.


It is known to install centralized servers that collect treatment data from multiple dialysis machines over multiple treatments. The drawbacks that the central servers present are many. First, the central servers result in significant hardware and installation costs. Second, the central servers require a good deal of computer experience to install and maintain. Many clinics simply do not have the information technology (“IT”) support for the centralized data systems. These drawbacks in many cases result in the clinics not using automated data collection systems and instead collecting the data manually, which is time consuming and error prone. For example, many backend software systems handle dialysis related information, disconnected from the dialysis machines, manually and far from the point of care in both space and time, which is time consuming and prone to failure. It would be advantageous if this and other types of data collection could be performed closer to the machine and the treatment.


A need accordingly exists for an improved data network system for medical devices.


SUMMARY

The present disclosure provides a distributed database system and method for medical devices, such as a renal failure therapy system and method that performs hemodialysis (“HD”), hemofiltration (“HF”), hemodiafiltration (“HDF”), peritoneal dialysis (“PD”), isolated UF (“UF”) and continuous renal replacement therapy (“CRRT”), slow continuous ultrafiltration (“SCUF”), continuous veno-venous hemodialysis (“CVVHD”), continuous veno-venous hemofiltration (“CVVH”), and continuous veno-venous hemodiafiltration (“CVVHDF”). Accordingly, “renal failure therapy” as used herein is meant to include any one, or more, or all of HD, HF, HDF, PD, UF, and CRRT (including SCUF, CVVHD, CVVH, and CVVHDF versions of CRRT). The present disclosure focuses primarily on renal failure therapy systems but is not limited to them. The network system and method described herein applies to other medical devices, such as, drug delivery pumps (including intravenous (“IV”) pumps, syringe pumps, large volume pumps (“LVP's”), shuttle pumps, peristaltic IV pumps, and any combination thereof, for example), and apheresis machines.


In one primary embodiment, the distributed database system of the present disclosure includes a local area network (“LAN”) formed between multiple renal failure therapy machines located in a clinic or other group setting or cluster, wherein the distributed database system does not need to interface with a centralized server, database, backbone network, or wide area network (“WAN”) of the clinic. Indeed, the network of the distributed database system can be the backbone network of the clinic. The distributed database system is stand-alone and all of the functionality to host the system can be provided within each dialysis machine. Each renal failure therapy machine has a control processor that operates with a memory device, which in turn communicates with the distributed database system via cable or wirelessly.


It should be appreciated that while one primary embodiment of the distributed database system uses a LAN having a network router, it is not necessary for the LAN to use such a router. Instead, the LAN could alternatively be a different type of network, such as an ad-hoc network or a power line network. As used herein, LAN includes network router types, Ethernet types, wireless types, ad-hoc types, power line types, others known to those of skill, others developed in the future, and combinations thereof.


The machines of the distributed database system can each access the same medically related data in one embodiment, where medically related data includes but is not limited to (i) prescription input parameters or data (e.g., machine operating parameters), (ii) treatment output data (e.g., UF removed, total blood volume moved, total dialysis fluid volume consumed, heparin volume consumed, alarms, and treatment effectiveness measurements Kt/V, etc.), (iii) technical input data (e.g., calibrations, alarm limits, etc.), (iv) technical output data (e.g., actual component usage, sensor measurements, etc.), and (v) administrative data (e.g., inventory data and staffing data). In general, data (i) and (ii) are helpful to evaluate a patient's treatment over time, while data (iii) and (iv) are helpful to evaluate how a particular machine is performing. Data (v) helps the clinic to run smoothly and efficiently.


Prescription input parameters can also include any and all fluid flowrate, pressure alarm limits, volume, temperature, conductivity, dose, treatment time, etc., settings used during the one or more treatments performed on any machine of the distributed database system. Prescription input parameters can further include any drugs that the patient is supposed to take and any supplies that the patient is supposed to use in connection with treatment, e.g., any medical delivery drug, anticoagulant such as heparin, saline, Erythropoietin stimulating agent (“ESA”) such as Epogen™, iron supplements, potassium supplements, bicarbonate used, acid concentrate used, dialyzer used, etc.


Treatment output data can also be any and all sensed or recorded data, e.g., actual fluid flowrate, pressure, treatment fluid volume, temperature conductivity, dialysis or drug delivery dose, treatment time, UF volume, etc., actually achieved during a treatment performed on a machine of the distributed database system. Treatment output data can further include any alarms or alerts generated during the treatment. Still further, treatment output data can include any physiological data, such as blood pressure, patient temperature, patient weight, patient glucose level, as well as subjective feelings such as nauseousness, light-headedness, sleepiness, etc., recorded during the treatment (including any physiological data sensed by the machine (e.g., a dialysis or drug delivery machine) or at one or more remote sensing equipment).


Each machine can broadcast medically related data to the other machines on the distributed database system. And as discussed below, an operator can use any machine of the distributed database system to obtain information regarding any patient of the clinic and the status of any other machine. It should be appreciated however that each machine of distributed database system does not have to have access to all the data of the system, or to the same data as each other machine, allowing for the machines or groups of the machines to instead have access to less than all the medically related data of the system.


The the distributed database system uses the fact that even very large amounts of memory storage are relatively inexpensive. The the distributed database system accordingly copies at least part of data of the machines on some periodic basis, or in real time, such that each machine has the same, or virtually the same, data stored in its memory device. If in real time, the distributed database system may be limited to distributing only certain types of data so that ongoing treatments are not interrupted. For example, the machines may be limited to only distributing alarm information so that a nurse attending to a patient at a first machine can see at the first machine that an alarm is occurring at a second machine. In the example, the machines can later, after the treatments are completed, exchange their bulk treatment output data.


Real time data sharing is alternatively more extensive, such that a nurse or clinician at a first machine can obtain treatment data concerning other machines of the distributed database system. For example, it is contemplated to provide a clinician's summary screen that allows a clinician to quickly view the status of all ongoing treatments. For example, a main treatment screen of the medical device can provide a “clinic summary” button that when pressed takes the clinician to the clinician's summary screen. Once at that screen, the clinician can quickly see real time or the current day's information about each other machine of the distributed database system, such as, current state of the machine (e.g., running, paused, under alarm condition, or not in use), elapsed treatment time, time of treatment remaining, amount of UF collected, and alarm history, and the like.


The system can provide multiple summary screens. For example, a main treatment screen of the medical device can provide a “summary” button, which when pressed leads the user to a screen having multiple summary buttons, such as the “clinic summary” button, a “patient summary” button, a “stock keeping summary” button, a “staffing summary” button, for example. The “patient summary” button when pressed could lead to a list of patients (for all of the clinic or only those currently undergoing treatment), wherein pressing any patient name on the list leads to a screen dedicated to that patient. Thus the nurse or clinician can reach a dedicated patient screen from any machine in the distributed database system. The “stock keeping summary” button when pressed could lead to a stock summary screen listing supply names, how many of each is supply in stock and how many of each supply is on back order. The “staffing summary” button when pressed could lead to a “staffing summary” screen listing all clinicians, nurses and doctors associated with the clinic, and which ones are currently at the clinic, their shift times, their technical specialties, and the like.


The “stock summary” and “staffing summary” screens are good examples of how different machines or other equipment connected to the distributed database system do not all have to share the same data. Here, one or more backend computer may be used to update the stock summary and/or the staffing summary information, e.g., at the end of each day. The one or more backend computer can share its updated stock summary and/or staffing summary information with each machine of the distributed database system, however, the one or more backend computer does not need to have access to the other types of medically related data listed above, which is provided to and received from the machines.


The summary information may or may not be real time information. For example, the clinician summary screen may involve real time data transfer, e.g., of treatment output data for different patients being treated on the machines employing the distributed database system. Stock summary information on the other hand can be current but not necessarily up to the minute information. For example, the information is in one embodiment not updated immediately as a dialyzer is pulled from inventory, but updated instead at the end of the day, where the total number of dialyzers used during that day are subtracted from inventory.


In one embodiment, a user such as a nurse or clinician must enter identification to be authenticated and receive authorization to review any information of the distributed databases of the present disclosure, including the summary information just described. For example, the summary screens discussed above when selected first present user identification and password entry boxes. Only after entry of an authorized username and password can the requesting nurse or clinician see patient identifiable data.


In one embodiment, the renal failure therapy machines are of a plug-and-play type, so that the machines can connect to the distributed database system automatically and share data on the system without any (or very little) user setup or configuration. Besides sharing treatment data, the distributed database system of the present disclosure also shares or makes sure that each machine has and operates with the latest software. If a software update is provided on one of the machines, the machine if allowed by the clinic will be able to propagate the software update to all machines of the distributed database system. In an embodiment, software updates are performed at the end of the day while the machines are not performing treatment. In many cases, the machines at the end of the day go into a dormant, sleep, hibernation or offline mode or state (“hibernation state”). The machine with the software update will awaken any machines in the hibernation state, so that all machines of the distributed database system or cluster can receive the software updates.


In certain instances, a renal failure therapy machine of the distributed database system may be disconnected from the system, e.g., for mechanical service or updating, cleaning, etc. In such a case, when the disconnected machine is placed back online with the distributed database system, the machine is updated to store any missing operating software and treatment data, so that the machine is fully up to date with the other machines of the distributed database system or cluster.


The distributed database system may include machines of only a single type or manufacturer. Alternatively, the distributed database system or cluster can include medical devices of different types and/or manufacturers. For example, the distributed database system or cluster can include renal failure therapy machines provided by manufacturer X, Y, and Z. It is contemplated that adapters, intermediate computers or interfaces be provided so that machines provided by manufacturers Y and Z can (i) communicate with each other, and (ii) communicate with the machine of manufacturer X. The adapters, intermediate computers or interfaces also ensure that the machines of each of manufacturers X, Y, and Z have adequate processing and memory to receive the data updating discussed herein.


There are various fundamental modes contemplated for the machines of the distributed database system to share data. In a first fundamental mode, the machines “push” their newly acquired data out to the other machines. Here, the machines can take turns sending their data to the other machines of the distributed database system. In particular, the machines in one “push” embodiment take turns sending their patient or treatment data at the end of a designated time period, such as at the end of every second, minute, hour, shift or treatment day. For example, each machine of the distributed database system may be given a queue number, e.g., 1/10, 2/10, 3/10 . . . 10/10, assuming that there are ten machines in the distributed database system. When it comes time for the machines to share data, machine 1/10 sends its data to machines 2/10 to 10/10. When machine 1/10 is complete, machine 2/10 sends its data to machines 1/10, and 3/10 to 10/10, and so on until machine 10/10 sends its data to machines 1/10 to 9/10. In the end, all ten machines have the data from every other machine of the cluster.


In another “push” embodiment, one of the machines acts as a hub machine, while other machines of the distributed database system act as spokes. Here, one or more machine of the cluster, e.g., machine 1/10 receives the data from all other machines 2/10 to 10/10. Machines 2/10 to 10/10 can each send their respective data according to a sequence requested by hub machine 1/10. Hub machine 1/10 will then store the data from machines 2/10 to 10/10 in the order in which the data is sent to hub machine 1/10. Once hub machine 1/10 is fully updated with the data from all the other machines of the distributed database system or cluster, machine 1/10 sends out the totalled data, including machine 1/10's data to all other machines 2/10 to 10/10 in the distributed database system or cluster, which can again be according to a sequence requested by hub machine 1/10. Again, in the end, all ten machines should have the data from every other machine of the distributed database system.


Another fundamental mode in which the machines of the distributed database system share data is for each machine to “pull” any new data from all other machines of the system. Here, as opposed to pushing data, each machine of the distributed database system asks each other machine of the system whether it has any new data to deliver. To do so, the requesting machine can keep a record of which data each other machine has sent. The requesting machine tells the delivering machine which of the delivering machine's data has already been delivered. The delivering machine then looks to see if there is any additional data, and if so, the delivering machine delivers the new data to the requesting machine. Each machine of the distributed database system takes turns being the requesting machine, so that at the end of an exchange session, each machine is fully updated.


In a further fundamental mode, the machines can perform a “push-pull” routine to ensure that they share the same data. For example, a “push” routine can be performed to push new data out from each of the machines to each of the other machines of the distributed database system. The push can be performed for example when the new data is created or at a designated interval, e.g., once a day or shift. A “pull” routine can be used to compare the stored data of any two machines to make sure that they match. For example, when a machine comes back online to the distributed database system, it can perform a “pull” routine to capture any new data generated while offline by the other machines of the systems. “Pull” routines can also be performed periodically, e.g., daily or per shift. In a “pull” routine, two machines compare and pull data from each other and select the most recent data to make sure that the two machines in the end have the same most recent data. This “pull” routine takes place on some periodic basis between all pairs of the machines of the distributed database system. The premise here is that if all pairs of machines of a distributed database have the same data, then all machines of distributed database have the same data.


The “push” and the “push-pull” routines can be implemented in many different ways. For example, the “push” can be an accumulated push. Say, for example, that the distributed database system includes twelve machines, 1/12 to 12/12. If each machine does its own individual new data push, then there will be 11 pushes per machine multiplied by 12 machines, totalling 132 pushes. In another embodiment, each machine has a partner, say machines 1/12+2/12, 3/12+4/12, 5/12+6/12, 7/12+8/12, 9/12+10/12, and 11/12+12/12, creating six machine couples. Each couple requires twelve new data pushes, two individual pushes to each other, plus 10 more collective data pushes to each of the other machines outside the couple. Here, twelve data pushes per couple multiplied by six couples equals only 72 total data pushes. In a further embodiment, each machine works in a trio, say machines 1/12+2/12+3/12, 4/12+512+6/12, 7/12+8/12+9/12, and 10/12+11/12+12/12, creating four total trios. Each trio requires fifteen new data pushes, six individual pushes to each other, plus 9 more collective data pushes to each machine outside the trio. Here, fifteen data pushes per trio multiplied by four trios equals only 60 total data pushes. In this same manner, grouping the same twelve machines into three quartets again yields 60 total new data pushes (twenty new data pushes per quartet multiplied by three quartets). Interestingly, grouping the same twelve machines into two halves results in 72 total new data pushes (36 new data pushes per half multiplied by two halves). Thus, there may be an optimum one or more grouping (in terms of lesser data pushes being better) for any total number of machines in the distributed database.


To keep track of which data has been delivered, it is contemplated to assign the data, or a packet of data, with tag data or metadata. In an embodiment, the tag data or metadata includes a unique identifier (“id”), a hash sum, and a time stamp. The unique id identifies the particular machine and the sequence in the machine that a particular piece of new data (usually an array of data) is generated. The hash sum identifies or represents the actual content of the new data (e.g., array). The time stamp marks the time at which the new data was generated. When two machines are synchronized, the machines first look to see if they have each of each other's unique id's. If a unique identifier of machine X is missing in machine Y, the corresponding new data and all metadata are copied to machine Y, and vice versa. If any two unique id's match but the corresponding hash sums are different, then the hash sum with the most recent time stamp is selected for storage in each machine X and Y. In this manner if machine Y is taken offline or has been permanently hibernating for a number of days, machine Y upon returning can go through a synchronization procedure with each other machine of the distributed database system to retrieve any missing new data generated during the time that machine Y has been offline.


Discussed herein are methods for the machines of the distributed database system to periodically check the integrity of their shared data and to correct the data if it becomes corrupted. Similarly, methods are discussed herein for checking whether data has been transferred correctly from one machine to another. In both cases, the checking can be done via the comparison of hash sums calculated for one or more pieces of data.


In any of the embodiments discussed herein, the renal therapy machines or other types of medical machines of the distributed database system can send data and status information within or outside of the LAN for storage at a remote computer or network of the clinic, machine manufacturer or other desired entity. For example, the data can be remotely stored for the purposes of backup in case the LAN or other portion of the distributed database is damaged. The data can be archived remotely for analysis, e.g., for averaging, trending, supply chain analysis, or supply ordering analysis. The data can also be archived remotely to lessen or alleviate the data storage burden to the distributed database system. That is, it is contemplated for data that is over a certain age to be incorporated into ongoing trends kept for each patient on the distributed database system, archived remotely on a computer or network within or outside the LAN, and purged eventually from the machines of the distributed database system to free storage space for new patient data.


The distributed database system also supports connectivity to sensing equipment, such as sensors, monitors, analysers, other medical instruments, and lab equipment. For example, a weight scale provided in the clinic can be used to weigh each patient prior to and after treatment. Patient weight can be sent to each machine of the distributed database system, e.g., wired or wirelessly, because each machine keeps a record of the patient being weighed. Alternatively, patient weight can be sent, e.g., wirelessly, to the machine on which the patient is being treated that day, and then sent later after treatment from the specific machine to each machine of the distributed database system. Or, the patient weight can be stored on a data storage device, e.g., a flash drive, taken to the machine on which the patient is being treated that day, and then sent later after treatment from the specific machine to each machine of the distributed database system. Data from other sensors, such as, blood pressure measurement devices and glucose sensors can be recorded and distributed in the same way.


The distributed database system can also monitor the performance of the sensors, monitors, analysers, other medical instruments, and lab equipment and report if it appears that any of these appear to be giving false readings. For example, the system can have a backend computer that runs an algorithm analysing the data from each sensor, monitor, analyser, or other medical instrument. The algorithm can look for trends in the readings from the sensor, monitor, etc., for example, to look for sensing equipment that is tending to read patients higher or lower than normal. If such a piece of sensing equipment is identified, the backend computer sends a flag to each machine of the distributed database system, notifying the machines to either not accept readings from such sensing equipment and/or to flag a clinician to have the equipment recalibrated or replaced. It should therefore be appreciated that if a particular clinic uses two or more scales (or other sensors), the data sent from each scale or sensor can have an identifier identifying that piece of sensing equipment. Moreover, it is contemplated that if the system finds an improperly working piece of sensing equipment, e.g., weight scale or blood pressure module, the system can be programmed to look back to see if there has been similar corrupt data in the past from the particular piece of equipment. In any case, it is contemplated to connect any sensing equipment to the distributed database system of the present disclosure, so as to share data along with the medical fluid pumping deliveries.


A backend computer has been mentioned multiple times thus far. It is contemplated in an alternative embodiment for any one or more backend computer to be eliminated and its function to be performed instead in one or more of the medical machines of the distributed database system. For example, the functionality performed by the one or more backend computer used to update the stock summary and/or the staffing summary information discussed above, or the backend computer for the sensing equipment, may be provided instead by the processing and memory of one or more (or all) medical machines of the distributed database system. In this way, clinics with limited or no backend computing can enjoy the benefits described in connection with these backend computers. But, clinics that do have such backend computing can leverage such computing into the distributed database of the present disclosure. It is contemplated that the distributed database system of the present disclosure can operate (i) without any backend computing capability, (ii) with and compliment existing backend computing capability, or (iii) independently from existing backend computing capability.


The distributed database system also supports data transmission from its renal failure therapy or other medical machines to a mobile device or personal computer of a clinician, doctor, nurse or other authorized person. In an embodiment, a record of any transmission to an external mobile device or personal computer is maintained. In one embodiment, data stored in the distributed database system can be accessed (read) on a mobile device or remote personal computer, but not stored on the mobile device or remote personal computer, or transferred from those devices.


In light of the technical features set forth herein, and without limitation, in a first aspect, a medical device system includes: a distributed database; a plurality of medical devices operating with the distributed database; and a logic implementer associated with each medical device, wherein each logic implementer is programmed to access the distributed database, so that each medical device of system periodically (i) delivers at least one of prescription input parameters or treatment output data to and (ii) retrieves at least one of prescription input parameters or treatment output data from each of the other medical devices.


In a second aspect, which may be used with any other aspect described herein unless specified otherwise, the medical devices are in data communication with each other via a local area network (“LAN”) used in connection with the distributed database.


In a third aspect, which may be used with any other aspect described herein unless specified otherwise, each of the medical devices is updated to store the same at least one of the prescription input parameters or treatment output data for each of a plurality of patients.


In a fourth aspect, which may be used with any other aspect described herein unless specified otherwise, the medical devices and the distributed database do not interact with a centralized server.


In a fifth aspect, which may be used with any other aspect described herein unless specified otherwise, the medical devices are provided by first and second manufacturers, and which includes an interface enabling the medical devices of the first and second manufacturers to communicate with one another.


In a sixth aspect, which may be used with any other aspect described herein unless specified otherwise, at least one of the (i) prescription input parameters or (ii) treatment output data is shared via the distributed database along with at least one other of (iii) technical input data, (iv) technical output data, or (v) administrative data.


In a seventh aspect, which may be used with any other aspect described herein unless specified otherwise, the distributed database also shares information from at least one medical equipment selected from the group consisting of: a weight scale, a blood pressure measurement device, a glucose sensor, a physiological sensor, an electrocardiogram device, water treatment equipment, a bed scale, an access disconnection device, a bioimpedance measurement device, a pH sensor, lab testing equipment, a blood sample analyzer, or an access flow measurement device.


In an eighth aspect, which may be used with any other aspect described herein unless specified otherwise, the distributed database is a first distributed database, and which includes a second distributed database that shares information from at least one medical equipment selected from the group consisting of: a weight scale, a blood pressure cuff, a glucose sensor, a physiological sensor, an electrocardiogram device, water treatment equipment, a bed scale, an access disconnection device, a bioimpedance measurement device, a pH sensor, lab testing equipment, a blood sample analyzer, or an access flow measurement device.


In a ninth aspect, which may be used with any other aspect described herein unless specified otherwise, periodically delivering and retrieving prescription input parameters or treatment output data includes doing so in at least one of: real time, a matter of seconds, a matter of minutes, hourly, daily, weekly, monthly, at an end of a treatment, at an end of a treatment day, or at an end of a treatment shift.


In a tenth aspect, which may be used with any other aspect described herein unless specified otherwise, at least one of the logic implementers is configured to periodically push at least one of the prescription input parameters or the treatment output data to each of the other medical devices of system.


In an eleventh aspect, which may be used with any other aspect described herein unless specified otherwise, at least one of the logic implementers is configured to periodically pull at least one of the prescription input parameters or the treatment output data from each of the other medical devices of system.


In a twelfth aspect, which may be used with any other aspect described herein unless specified otherwise, the system is further configured to share operating software between the medical devices via the distributed database.


In a thirteenth aspect, which may be used with any other aspect described herein unless specified otherwise, the distributed database is a first distributed database, and which includes a second distributed database, wherein at the logic implementer of at least one of the plurality of machines is programmed to access the second distributed database.


In a fourteenth aspect, which may be used with the thirteenth aspect in combination with any other aspect described herein unless specified otherwise, wherein one of the distributed databases is a real time data database.


In a fifteenth aspect, which may be used with the thirteenth aspect in combination with any other aspect described herein unless specified otherwise, one of the distributed databases is an administrative data database.


In a sixteenth aspect, which may be used with any other aspect described herein unless specified otherwise, each medical device of system is programmed to periodically verify its at least one prescription input parameters or treatment output data.


In a seventeenth aspect, which may be used with the sixteenth aspect in combination with any other aspect described herein unless specified otherwise, wherein verification is performed via a comparison of hash sums.


In an eighteenth aspect, which may be used with any other aspect described herein unless specified otherwise, the plurality of medical devices of system are programmed to periodically synchronize their at least one prescription input parameters or treatment output data.


In a nineteenth aspect, which may be used with the eighteenth aspect in combination with any other aspect described herein unless specified otherwise, synchronization is performed via a comparison of at least one of record identifications, hash sums, or time stamps.


In a twentieth aspect, which may be used with any other aspect described herein unless specified otherwise, at least one of the medical devices of system is programmed to display at least one summary screen showing at least one of the prescription input parameters or treatment output data for different medical devices of system.


In a twenty-first aspect, which may be used with any other aspect described herein unless specified otherwise, a medical device system includes: a plurality of medical devices; a first distributed database sharing first data generated or used by the plurality of medical devices amongst the plurality of medical devices; and a second distributed database sharing second data generated or used by the plurality of medical devices amongst the plurality of medical devices, (ii) second data generated or used by a second plurality of medical devices amongst the second plurality of medical devices, or (iii) second data generated or used by medical equipment.


In a twenty-second aspect, which may be used with the twenty-first aspect in combination with any other aspect described herein unless specified otherwise, one of the first medical devices and one of the second medical devices are configured to provide treatment to a same patient.


In a twenty-third aspect, which may be used with the twenty-first aspect in combination with any other aspect described herein unless specified otherwise, one of the first medical devices and one of the medical equipment are configured to provide treatment to a same patient.


In a twenty-fourth aspect, which may be used with the twenty-first aspect in combination with any other aspect described herein unless specified otherwise, the first medical devices are for providing treatment to a first group of patients and the second medical devices are for providing treatment to a second group of patients.


In a twenty-fifth aspect, which may be used with any other aspect described herein unless specified otherwise, a medical device includes: at least one medical fluid pump; and a logic implementer operating the at least one medical fluid pump so as to accept a pump input parameter and generate pump output data, the logic implementer programmed to (i) periodically share at least one of the pump input parameter or the pump output data with a plurality of other medical devices via a distributed database, and (ii) periodically receive at least one of a pump input parameter or pump output data from the plurality of other medical devices via the distributed database.


In a twenty-sixth aspect, which may be used with the twenty-fifth aspect in combination with any other aspect described herein unless specified otherwise, the logic implementer is programmed to synchronize at least one of the pump input parameter or the pump output data with the other medical devices via the distributed database.


In a twenty-seventh aspect, which may be used with the twenty-sixth aspect in combination with any other aspect described herein unless specified otherwise, the logic implementer is programmed to compare its own hash sum with a corresponding hash sum of one of the other medical devices to synchronize at least one of the pump input parameter or the pump output data with that other medical device.


In a twenty-eighth aspect, which may be used with the twenty-fifth aspect in combination with any other aspect described herein unless specified otherwise, the logic implementer is programmed to send a hash sum for at least one of the pump input parameter or the pump output data to one of the other medical devices for comparison at the other medical device with a corresponding hash sum of the other medical device.


In a twenty-ninth aspect, which may be used with the twenty-fifth aspect in combination with any other aspect described herein unless specified otherwise, the logic implementer is programmed to verify at least one of its pump input parameter or pump output data.


In a thirtieth aspect, which may be used with the twenty-ninth aspect in combination with any other aspect described herein unless specified otherwise, verification includes comparing a newly calculated hash sum with a previously established hash sum for at least one of the pump input parameter or the pump output data.


In a thirty-first aspect, which may be used with the second aspect in combination with any other aspect described herein unless specified otherwise, the LAN includes a network router.


In a thirty-second aspect, which may be used with the second aspect in combination with any other aspect described herein unless specified otherwise, the LAN is wired or wireless.


In a thirty-third aspect, which may be used with any other aspect described herein unless specified otherwise, the system of device is configured to create at least one treatment record trend from the medically related data.


In a thirty-fourth aspect, which may be used with any other aspect described herein unless specified otherwise, the system or device is configured to remove data at or after a certain age or for a regulatory reason.


In a thirty-fifth aspect, which may be used with any other aspect described herein unless specified otherwise, the system or device is which is configured to deliver the medically related data after each of the medical devices has completed treatment.


In a thirty-sixth aspect, which may be used with any other aspect described herein unless specified otherwise, the system or device is configured to deliver medically related data during treatment.


In a thirty-seventh aspect, which may be used with any other aspect described herein unless specified otherwise, the system or device is configured to awaken at least one of the medical devices from a hibernation mode for medically related data delivery.


In a thirty-eighth aspect, which may be used with any other aspect described herein unless specified otherwise, the system or device is configured to deliver multiple days of medically related data to one of the medical devices upon its returning to data communication with the other medical devices.


In a thirty-ninth aspect, which may be used with any other aspect described herein unless specified otherwise, the system or device is configured to update each medical device automatically with new software.


In a fortieth aspect, which may be used with any other aspect described herein unless specified otherwise, the system a medical device system includes: a plurality of medical devices in data communication with each other; and a logic implementer associated with each medical device, wherein each logic implementer is programmed to periodically store medically related data for each of a plurality of patients treated via the plurality of medical devices.


In a forty-first aspect, which may be used with any other aspect described herein unless specified otherwise, a medical device distributed database system includes: a local area network (“LAN”); and a plurality of medical devices in data communication with the LAN, wherein each of the plurality of medical devices periodically takes turns transferring medically related data via the LAN to each of the other medical devices.


In a forty-second aspect, which may be used with the forty-first aspect in combination with any other aspect described herein, each of the plurality of medical devices includes a place in a queue dictating an order in which the plurality of medical devices takes turns transferring medically related data.


In a forty-third aspect, which may be used with the forty-second aspect in combination with any other aspect described herein, the first medical device in the queue initiates the periodic transferring of data.


In a forty-fourth aspect, which may be used with the forty-first aspect in combination with any other aspect described herein, the transferring of data occurs after each day of treatment with the medical devices.


In a forty-fifth aspect, which may be used with the forty-first aspect in combination with any other aspect described herein, the transferring of data occurs during treatment with the medical devices.


In a forty-sixth aspect, which may be used with any other aspect described herein unless specified otherwise, a medical device distributed database system includes: a local area network (“LAN”); and a plurality of medical devices in data communication with the LAN, wherein a first one of the plurality of medical devices is programmed to periodically receive medically related data via the LAN from each of the other of the medical devices, and send the collective medically related data via the LAN to each of the other medical devices.


In a forty-seventh aspect, which may be used with the forty-sixth aspect in combination with any other aspect described herein, each of the other medical devices sends its data upon receiving a notice from the first medical device.


In a forty-eighth aspect, which may be used with the twenty-fifth aspect in combination with any other aspect described herein unless specified otherwise, the logic implementer is further programmed to share at least one of the pump input parameter or the pump output data with at least one of a personal communication device (“POD”, 175), a personal computer (170), a server computer (180), or medical equipment (185) via the distributed database (10a to 10f).


In a forty-ninth aspect, which may be used with the twenty-fifth aspect in combination with any other aspect described herein unless specified otherwise, the logic implementer is further programmed to receive data from at least one of a personal communication device (“PCD”, 175), a personal computer (170), a server computer (180), or medical equipment (185) via the distributed database (10a to 10f).


In a fiftieth aspect, any of the features, functionality and alternatives described in connection with any one or more of FIGS. 1A to 11 may be combined with any of the features, functionality and alternatives described in connection with any of the other one or more of FIGS. 1A to 11.


It is therefore an advantage of the present disclosure to provide a distributed database system and method for medical devices, which does not require a centralized server.


It is another advantage of the present disclosure to provide a distributed database system and method for medical devices, which enables any patient to use any machine of the system, wherein each machine will have a record of the patient.


It is a further advantage of the present disclosure to provide a distributed database system and method for medical devices, in which a clinician may approach any machine and obtain data about any patient within the distributed database system.


Moreover, it is an advantage of the present disclosure to provide a distributed database system and method for medical devices, which can handle different types and manufacturers of medical devices.


Additional features and advantages of the present invention are described in, and will be apparent from, the following Detailed Description of the Invention and the figures.





BRIEF DESCRIPTION OF THE FIGURES


FIG. 1A is a schematic view of one embodiment of a distributed database system and method of the present disclosure.



FIGS. 1B to 1D illustrate different example types of local area networks suitable for use with the distributed database systems and methods of the present disclosure.



FIG. 2 is a schematic view of another embodiment of a distributed database system and method of the present disclosure.



FIG. 3 is a schematic view of a further embodiment of a distributed database system and method of the present disclosure.



FIG. 4A is a logic flow diagram illustrating one embodiment of a subroutine for generating metadata for data transferred via the distributed database system and method of the present disclosure.



FIG. 4B is a logic flow diagram illustrating one embodiment of a subroutine for sending data to other machines or sensing equipment of the distributed database system of the present disclosure.



FIG. 5A is a logic flow diagram illustrating one embodiment of a subroutine for synchronizing different machines using the distributed database system and method of the present disclosure.



FIG. 5B is a logic flow diagram illustrating one embodiment of a subroutine for comparing data between two machines, the subroutine used with the logic flow diagram of FIG. 5A.



FIG. 5C is a logic flow diagram illustrating one embodiment for a machine or sensing equipment of the distributed database system of the present disclosure to verify its data.



FIG. 6A is a logic flow diagram illustrating one embodiment of a “push-pull” method employing the subroutines of FIGS. 4A, 4B and 5A (including FIG. 5B) to enable each machine of a distributed database system and method of the present disclosure to share data.



FIG. 6B is a logic flow diagram illustrating one embodiment of a “pull” method employing the subroutines of FIGS. 4A and 5A (including FIG. 5B) to enable each machine of a distributed database system and method of the present disclosure to share data.



FIG. 7A is a logic flow diagram illustrating one embodiment of a “push” mode for updating operating software on different machines of a distributed database system and method of the present disclosure.



FIG. 7B is a logic flow diagram illustrating one embodiment of a subroutine for a user to confirm installation of a new software update, the subroutine used with the logic flow diagram of FIG. 7A.



FIG. 7C is a logic flow diagram illustrating another embodiment of a “pull” mode for updating operating software on different machines of a distributed database system and method of the present disclosure.



FIG. 8A is a screenshot from a machine of a distributed database system of the present disclosure, illustrating one embodiment of a “clinic summary” button that when pressed takes the user to a clinic summary screen.



FIG. 8B is a screenshot from a machine of a distributed database system of the present disclosure, illustrating one embodiment of a clinic summary screen.



FIG. 9 is a schematic representation of one embodiment for a life cycle for data stored on the distributed database system of the present disclosure.



FIG. 10 is a flow schematic of one embodiment of a dialysate circuit of a renal failure therapy machine operable with the distributed database system and method of the present disclosure.



FIG. 11 is a flow schematic of one embodiment of a blood circuit of a renal failure therapy machine operable with the distributed database system and method of the present disclosure.





DETAILED DESCRIPTION

Referring now to the drawings and in particular to FIG. 1, an embodiment of a distributed database system 10 is illustrated. Distributed database system 10 includes plural medical devices 12a to 12j (referred to herein collectively as medical devices 12 or generally individually as medical device 12). Medical devices 12 can be any type of medical devices that can be grouped into a cluster, e.g., at a clinic, hospital, or other medical device setting. Medical devices 12 can for example be drug delivery or infusion pumps. Suitable infusion pumps for distributed database system 10 are described for example in copending U.S. Patent Publications 2013/0336814 (large volume peristaltic pump) and 2013/0281965 (syringe pump). In another embodiment, medical devices 12 are any type of renal failure therapy machine, such as a hemodialysis (“HD”), hemofiltration (“HF”), hemodiafiltration (“HDF”), continuous renal replacement therapy (“CRRT”), slow continuous ultrafiltration (“SCUF”), continuous veno-venous hemodialysis (“CVVHD”), continuous veno-venous hemofiltration (“CVVH”), continuous veno-venous hemodiafiltration (“CVVHDF”) machine, and/or peritoneal dialysis (“PD”). FIGS. 10 and 11 below provide some context for how a renal failure therapy machine works, and in particular what type of data is needed to program the machine (machine prescription parameters), and what type of data the machine generates (treatment output data).


While distributed database system 10 is shown in FIG. 1 with medical devices 12a to 12j, it should be appreciated that any one or more of machines 12a to 12j or positions 12a to 12j can instead be a personal computer (such as computer 170 illustrated below), a server computer (such as server computer 180 illustrated below), or any type of sensing or other medical equipment (such as sensing equipment 185 illustrated below). Thus while medical fluid machines 12 are the predominant type of device sharing data on distributed database system 10, wherever medical fluid machines 12a to 12j or simply medical fluid machines 12 are referenced herein, those references are also meant to apply to personal computers 170, server computers 180 and sensing or other medical equipment 185.


Distributed database system 10 in one embodiment operates using a local area network (“LAN”) 150. LAN 150 of system 10 ties together the cluster of machines 12a to 12j. Distributed database system 10 can include more or less than the illustrated ten machines. Distributed database system 10 does not require a server computer, an outside network, an intranet or an internet. Distributed database system 10 can be completely self-standing and located in areas with little or no internet capability and in facilities with little or no computer infrastructure. LAN 150 of distributed database system 10 connects to machines in a wired or wireless manner. FIG. 1 illustrates both scenarios. In a wired scenario, LAN 150 connects to machines 12a to 12j via a wired connection 152 at each machine. The wired connection can be of a Universal Serial Bus (“USB”) variety or of another type, such as that of an Ethernet network, e.g., a standard IEEE 802.3 network.


In an alternative embodiment, LAN 150 is wireless. Here, each machine 12a to 12j is provided with a wireless transceiver 154, which (i) broadcasts information wirelessly to other machines of distributed database system 10 along LAN 150 and (ii) receives information wirelessly from other machines of the distributed database system 10 along LAN 150. The wireless network can be implemented as a Wi-Fi network, e.g., as set forth in standard IEEE 802.11. Any one of a variety of different Wi-Fi protocols can be used, e.g., type “a”, “b”, “g”, “n”, “ac” and other coming protocols, such as “af”. Alternatively, protocols different from Wi-Fi may be used, such as Bluetooth or ZigBee.


In the example of FIG. 1, machines 12a to 12d and 12f to 12j of distributed database system 10 are all of the same type and manufacturer or are otherwise able to communicate directly with one another. Machines 12a to 12d and 12f to 12j are accordingly illustrated as communicating wired or wirelessly directly with one another. Machine 12e of distributed database system 10 on the other hand is not of the same manufacturer, the same model, or for whatever reason is not able to communicate directly with machines 12a to 12d and 12f to 12j. For example, different dialysis machine manufacturers, while generally requiring the same data input to run a treatment and generally generating the same treatment output data, will likely vary in terms of how the data is specifically inputted and generated. For example, while each dialysis machine will need to know treatment time, ultrafiltration (“UF”) volume to be removed or UF goal, and UF flowrate, the three parameters are related and only two of the three need to be specified. One manufacturer may decide to input treatment time and UF goal and calculate UF flowrate, while another manufacturer may set UF goal and UF flowrate and calculate treatment time. In other examples, different manufacturers may input parameters and generate treatment data in different units, e.g., English standard versus metric units. Still further, different manufacturers may take into account different or additional parameters, e.g., fluid and food intake and volume of infused fluids during treatment for UF.


Different machine 12e illustrates one solution to the above-described manufacturer or machine type mismatch. An adapter, intermediate computer, or interface 160 is provided with different machine 12e. Here, LAN 150 is connected to intermediate interface 160 via wired connection 152 or wireless transceiver 154. A separate data line 156 and wired connection 158 can be made between intermediate interface 160 and machine 12e. Or, a separate wireless connection between transceivers 154 of machine 12e and intermediate interface 160 can be made to enable machine 12e to be in data communication with the other machines via LAN 150 indirectly.


Intermediate interface 160 may be provided with its own video screen 162, e.g., touch screen or onscreen touch keypad, and/or have its own electromechanical keyboard (not illustrated). Alternatively, intermediate interface 160 may simply be a data converter, wherein the user interacts with intermediate interface 160 via the user controls and video screen of different machine 12e (e.g., different manufacturer. While intermediate interface 160 is illustrated as a separate unit located in conjunction with the machine for which it operates, intermediate interface 160 is alternatively (i) one or more printed circuit board located within different machine 12e, (ii) one or more printed circuit board located within any of machines 12a to 12d, or 12f to 12j, or (iii) software loaded on a separate server 180 or computer 170 illustrated below in connection with FIG. 2.


In any of the configurations for intermediate interface 160, it is contemplated that the interface have its own data storage capabilities, so that the interface can store some or all of the information distributed amongst the machines of distributed database system 10. In an embodiment, a backend computer 170 (FIG. 2) hosting backend software can operate as intermediate interface 160. Computer 170/interface 160 can scrub data coming from different machine 12e and act as a link to the other machines 12 of distributed database system 10. Computer 170/interface 160 can in addition scrub other data, such as sensor outputs and lab results or other third party medical information, for each of machines 12, including different machine 12e.


Intermediate interface 160 enables different machine 12e to operate normally but in the eyes of system 10 as it were of the same type (e.g., same manufacturer or same model) as machines 12a to 12d and 12f to 12j. Intermediate interface 160 enables the data sent from distributed database system 10 for different machine 12e to be the same as the data sent from system 10 to machines 12a to 12d and 12f to 12j, and the data sent from different machine 12e to be provided in the same format within LAN 150 as the data sent from machines 12a to 12d and 12f to 12j.


As discussed above, LAN 150 of system 10 ties together the cluster of machines 12a to 12j. FIGS. 1B to 1D illustrate different example types for LAN 150. LAN 150 (including LAN's 150a to 150d discussed below) of FIGS. 1A, 2 and 3 can be of any type illustrated in FIGS. 1B to 1D and of any other type known to those of skill in the art today or developed in the future.



FIG. 1B illustrates that LAN 150 may be provided in the form a type using a network manager router 140 and/or a wireless access point 142 operating with a dynamic host configuration protocol (“DHCP”) server (not illustrated). LAN 150 of FIG. 1B can be configured alternatively to use fixed addressing in addition to dynamic addressing. The DHCP functionality can be provided by router 140. FIG. 1B illustrates that LAN 150 may be wired (machines 12a and 12b), wireless (machines 12c to 12e) or wired and wireless (network manager router 140 connected to wireless access point 142 via a data communication link 144). This mode of network operation for LAN 150 of FIG. 1B can be called an “infrastructure mode”.



FIG. 1C illustrates an alternative ad-hoc network LAN 150. Ad-hoc LAN 150 is a decentralized network that does not rely on network infrastructure, such as network manager router 140 or wireless access point 142 discussed above with FIG. 1B. Each machine 12a to 12e of ad-hoc LAN 150 sends and receives information to and from each other machine 12a to 12e directly, without a middleman or central hub. As illustrated in FIG. 1C, machines 12a to 12e of ad-hoc LAN 150 are typically (but do not have to be) connected wirelessly.



FIG. 1D illustrates an alternative power line LAN 150. Power line network uses the AC power line 146 bringing power to machines 12a to 12d to additionally carry network traffic (dotted line) to the machines. Due to the branched relationship of machines 12a to 12d to power line 146, power line LAN 150 normally (but does not have to) employs a network manager 148 to direct network traffic (dotted line) in and out of machines 12a to 12d.


Referring now to FIG. 2, another embodiment of distributed database system 10 includes multiple distributed databases 10a, 10b, 10c . . . 10n located in multiple clinics or dialysis centers 130a, 130b, 130c . . . 130n, respectively (the large circles in general represent the physical structure of the clinic or dialysis center). Clinics 130a to 130c (referred to collectively as clinics 130 or generally individually as clinic 130) can be part of a common medical group or network, or can be separate and individual. Machines 12 (referring to machines 12a to 12j . . . 12n above) can be different for different clinics or dialysis centers.


For example, machines 12 for clinic 130a can be infusion pumps. Machines 12 for clinic 130b can be hemodialysis machines that communicate via LAN 150a and peritoneal dialysis machines that communicate via LAN 150b. Machines 12 for clinic 130c can be hemodialysis machines. Three clinics 130a to 130c are merely an example; there can be more or less than three clinics operating with distributed database system 10.


Clinic 130a is outfitted with a distributed database 10a operating with a single LAN 150 to coordinate multiple machines 12 in a manner and including any of the alternatives discussed herein. LAN 150 of distributed database 10a is also connected to multiple personal computers 170 located within the LAN. Personal computers 170 enable doctors, clinicians, nurses, service people, etc., to (i) view information on distributed database 10a, (ii) input, and/or (iii) store information to the database, before, during and after treatment.


LAN 150 of distributed database 10a of clinic 130a is also connected to one or more server computer 180. Server computer 180 in an embodiment serves as a backup to the information stored on machines 12. As discussed in more detail below, machines 12 of distributed database 10a are periodically updated so that they have one mind, or the same mind, meaning each machine 12 is updated so that all machines 12 store the same data. Thus, each machine 12a to 12j serves as a backup to each of the other machines 12. Nevertheless, server 180 can be provided as additional protection in case each machine 12a to 12j of distributed database 10a is somehow damaged. Server 180 can also store older data that may be removed from machines 12 communicating via LAN 150 of distributed database 10a. For instance, distributed database 10a may be programmed such that each machine 12a to 12j stores six months or one year's worth of data for the patients associated with clinic 130a. Data older than the time limit are purged from the memories of machines 12a to 12j. Server 180 however can retain the older data in case it is needed for some reason. Server 180 of system 10 can alternatively or additionally manage information that is not part of the data shared between machines 12a to 12j. Server 180 can also be responsible for interfaces external to clinic 130c.


As discussed below in connection with FIG. 9, it is contemplated to add data to ongoing or moving trends. Each machine 12a to 12j stores each of the ongoing or moving trends. Thus even though the actual values of the older data may be removed from machines 12, the removed data can still maintained within the machines as part of the trends.

    • Server 180 can be connected to a wide area network (“WAN”) or an internet via a wired connection 182, e.g., Ethernet connection or via a wireless connection 182, e.g., a mobile internet connection, such as UTMS, CDMA, HSPA or LTE. In either case, data stored at server 180 can be shared with (i) servers 180 of other dialysis centers 130b, 130c, e.g., dialysis centers of a same network or group, (ii) outside personal computers 170, e.g., computers 170a to 170e, (iii) personal communication devices (“PCD's”) 175, such as smartphones, tablet computers, pagers and the like, and (iv) a central hub 190, e.g., a central control center for a group or network of dialysis centers 130a to 130c. Each of outside servers 180, personal computers 170a to 170e, PCD's 175, and central hub 190 of system 10 connects to the WAN or internet via a wireless or wired internet connection 182 in the illustrated embodiment. It is also contemplated to bypass or not provide server 180, and allow machines 12 of system 10 to communicate directly with personal communication devices (“PCD's”) 175, such as smartphones and tablets, as well as other data sharing equipment, such as personal computers, pagers, printers, facsimile machines, scanners, combinations thereof, and the like.
    • Personal computers 170 inside clinics 130a to 130c are limited to accessing information specific to their respective clinic in one embodiment. Outside computers 170a to 170e may be able to access data from multiple clinics 130a to 130c, or may be dedicated to a single clinic or group of clinics. Outside computers 170a to 170e may be read only and not be able to store and/or modify data associated with clinics 130a to 130c.


Central hub 190 can communicate wired or wirelessly with any one or more server computer 180 (180a, 180b) within a clinic, as illustrated in each of clinics 130a to 130c. Alternatively or additionally, central hub 190 can communicate wired or wirelessly directly with any one or more LAN 150 within a clinic, as illustrated in clinic 130a. Central hub 190 in the illustrated embodiment has its own server computer 180, which connects to the WAN or internet via a wireless or wired internet connection 182. Central hub 190 can be an additional data backup to the servers 180 of dialysis centers 130a to 130c. Central hub 190 can alternatively or additionally track data trends and averages across multiple dialysis centers or medical clinics 130a to 130c. Central hub 190 can also perform other duties, such as inventory tracking and fulfillment. It is accordingly contemplated that central hub 190 can be part of or work in cooperation with a factory associated with the manufacturer of machines 12 and its related supplies. It is further contemplated to bypass server 180 and allow machines 12 of system 10 to communicate directly with hub 190 for stock balance information (e.g., dialyzers, ultrafilters, concentrates, disinfection fluids, blood sets, etc.), billing or economic transaction information, and/or lab data regarding different patients (e.g., bicarbonate, potassium levels, etc.).


Clinic or dialysis center 130b is outfitted with two or more distributed databases 10b and 10c that operate respectively with two or more LANs 150a and 150b, located within the same clinic or dialysis center. In the example given above, machines 12 located within clinic 130b can be hemodialysis machines communicating via LAN 150a of distributed database 10b and peritoneal dialysis machines communicating via LAN 150b of distributed database 10c. In another example, machines 12 located within clinic 130b can be hemodialysis machines of a first manufacturer communicating via LAN 150a of distributed database 10b and hemodialysis machines of a second manufacturer communicating via LAN 150b of distributed database 10c. In a further example, machines 12 located within clinic 130b can be first medical delivery pumps communicating via LAN 150a of distributed database 10b and second medical delivery pumps communicating via LAN 150b of distributed database 10c. The separate LAN's 150a and 150b of distributed databases 10b and 10c, in general, group machines having common input parameters and output data. LAN's 150a and 150b of distributed databases 10b and 10c may also be separated based upon geographical location, for example, LAN's 150a and 150b may each operate with the same types of machines 12 but be separated because they are located at different rooms or areas of clinic 130b.


PCD's 175 communicate with servers 180 (180a, 180b), central hub 190, personal computers 170, other PCD's, and possibly directly with machines 12 over the WAN or internet using mobile internet connections (such as UTMS, CDMA, HSPA or LTE) or satellite protocols as is known to those of skill in the art. PCD's 175 can be carried by doctors, clinicians, nurses (e.g., for inside or outside of clinics or dialysis centers 130a to 130c. Patients may also use PCD's 175, e.g., during treatment to (i) provide feedback concerning their current treatment or history, (ii) self-assessment, and/or (iii) ask a question to the nurse or clinician to answer either during a current treatment or for a subsequent treatment.


Access to data stored at machines 12 of distributed databases 10b and 10c via PCD's 175 and personal computers 170 can be password protected. It is also contemplated to separate data stored at machines 12 of distributed databases 10b and 10c into patient-identified data and patent de-identified data and to restrict access to any patient-identified data. For example, patient-identified data may be restricted to doctors, nurses or clinicians located within a clinic 130a to 130c and who are associated with a particular LAN 150 of a distributed database 10a to 10d. De-identified data on the other hand may be available to people located outside of clinics 130a to 130c, e.g., marketing people associated with the clinics or with the manufacturing of machines 12 and their supplies, staff responsible for technical services, and manufacturers of machines 12 for monitoring how the machines are performing and/or implementing preventive updates. The above-mentioned staff and employees associated with the manufacturer may be located at central hub 190 for example.


Even amongst the categories of patient-identified data and patient de-identified data, it is contemplated for distributed database system 10 to restrict data access levels within the categories. For example, under the category of patient-identified data, there may be high, medium and low access levels, where a doctor has high access, clinicians and nurses have medium access, while patient's have low access (e.g., limited to their own data). An administrator can be assigned to maintain and modify the access levels as needed. The access levels are tied to the doctor's, clinician's, nurse's and patient's passwords in one embodiment, so that the appropriate access level is established automatically upon login. The access levels can also be applied to machines 12, such that a doctor, clinician, nurse and/or patient can log into any of the machines and be restricted to the appropriate level of access.


Each LAN 150a and 150b of distributed database 10b and 10c of clinic or dialysis center 130b in the illustrated embodiment connects to its own server computer 180 (180a, 180b) having a WAN or internet connection 182. Each LAN 150a and 150b of distributed database 10b and 10c also enables communication with personal computers 170. At least one personal computer 170 illustrated for clinic 130b can communicate with distributed databases 10b and 10c via both LAN's 150a and 150b. Clinic or dialysis center 130b also includes a server computer 180a that communicates only with distributed database 10b and a second server computer 180b that communicates with both distributed databases 10b and 10c via both LAN's 150a and 150b. Server computers 180a and 180b may or may not have a WAN or internet connection 182.


Clinic or dialysis center 130b also illustrates that one or more machine, such as machine 12k, can operate with multiple distributed databases 10b and 10c. The data synchronized in different distributed databases 10b and 10c can be different, and it may also be data of a different type. For example, distributed database 10b can be used for sharing medical treatment information, while distributed database 10c is used to share backend information, such as machine setting information, e.g., language of the machine, or user interface appearance of the machine. As discussed in detail with FIG. 3, each machine of a primary treatment information distributed database (such as database 10b) can also be a member of another distributed database (such as database 10c).


Clinic or dialysis center 130c is outfitted with a distributed database 10d having single LAN 150 supporting multiple medical machines 12. Personal computers 170 located within clinic 130c are placed in data communication with each other via LAN 150. Server computers 180a and 180b having any of the functionality described above are likewise placed in data communication with distributed database 10d via LAN 150. Thus, any distributed database or LAN discussed herein can be connected to two or more server computers 180.


Clinic 130c also illustrates that a sensing device or other medical equipment 185 may also communicate with distributed database 10d via LAN 150 via wired or wireless connection 182, such as an Ethernet, Wi-Fi or Bluetooth connection. Sensing device or medical equipment 185 can for example be a weight scale used by patients of machines 12 of LAN 150 of clinic 130c. Each patient weighs himself or herself before and/or after treatment. Those weights are then transmitted wired or wirelessly via LAN 150 to the machine 12 that the patient uses that day for treatment, for example, to the machine 12 that the patient decides or requests to use that day for treatment. The patient can, for example, scan his or her identification card or enter an ID number at both the weight scale and machine 12 so that the weight measurement taken and the particular machine 12 can be matched. Alternatively, the sensor reading is stored at the sensing equipment 185 (e.g., scale or blood pressure measurement device), after which the machine 12 that the patient uses that day asks for the reading from the one or more sensor.


Further alternatively, sensing equipment 185 sends the reading to all machines 12 of distributed database 10d. Here, a weight value, for example, is stored in the machines in a record or file for the particular patient in one embodiment.


Any of the above-described methodologies can be used to match a reading from a blood pressure measurement device 185 to the particular machine 12. Any of the above-described methodologies can also be used to match a glucose measurement from a glucose monitor to a particular machine 12. Any of clinics 130a to 130c can use or employ such equipment 185. Equipment 185 can also include any physiological sensing equipment associated with an emergency room or dialysis center, for example, electrocardiogram (“ECG”), water treatment equipment, bed scales, access disconnection devices, bioimpedance measurement devices, pH sensors, lab testing equipment, blood sample analyzers, and/or a psychological status application stored on a PCD 175.


It should be appreciated that sensing equipment 185 does not have to be undedicated sensing equipment, but can instead be one or more pieces of sensing equipment dedicated to a machine 12, e.g., via a USB connection, electrical connection, pneumatic connection (e.g., pneumatic pressure measurement device), cable or wirelessly (e.g., using Bluetooth, Wi-Fi or ZigBee). Sensing equipment data 185 here is associated with the patient being treated on the machine 12 and is made accessible to other machines via distributed database system 10 as described herein.


While distributed database system 10 of FIG. 2 illustrates multiple server computers 180, personal computers 170, PCD's 175, and central hub 190, it should be appreciated that none of those devices is needed to maintain system 10. Each of machines 12 of distributed databases 10a to 10d of distributed database system 10 is updated periodically to store the same data as each of the other machines 12 of the LAN. Server computers 180, personal computers 170, PCD's 175 and central hub 190 are not required to perform the updating. Instead, for example, personal computers and PCD's 175 can be used to view the data stored on machines 12 distributed database system 10, while personal computers 170, server computers 180 and central hub 190 can be used for data backup, trending and/or analysis.


Clinic 130c also illustrates a machine 12l, which is not present along LAN 150 and thus is not part of distributed database 10d. Machine 12l is still part of the overall distributed database system 10 of the present disclosure, however, because machine 12l may at anytime become part of distributed database 10d, at which time the collective data of all machines 12 of distributed database 10d is updated. In the meantime, treatment is performed at disconnected machine 12l using locally stored prescription parameters, etc., and operating software that may not be current. System 10 can make the user of machine 12l aware of its status.


Referring now to FIG. 3, distribute database system 10 is further illustrated. As discussed above in connection with machine 12k of clinic 130b in FIG. 2, each machine 12 can be part of multiple distributed databases. In FIG. 3, machines 12a and 12b belong to distributed databases 10a and 10b operating with LAN's 150a and 150b, respectively. Machines 12c and 12d belong to distributed databases 10a and 10c operating with LAN's 150a and 150c, respectively. Machine 12e belongs to distributed databases 10b and 10d operating with LAN's 150b and 150d, respectively. Machine 12f belongs to distributed databases 10c and 10d operating with LAN's 150c and 150d, respectively. In alternative embodiments, any one or more of machines 12 may belong to three or more distributed databases.


Distributed databases 10a to 10d can be grouped by machine or device type as well. For example, machines 12a to 12d may be drug delivery pumps or IV pumps, while machines 12e and 12f are other types of devices, such as, oxygenators or sensing equipment, such as, glucose monitoring. Distributed database 10b can be dedicated to a first patient connected to two IV pumps 12a and 12b and an oxygenator 12e. Distributed database 10c can be dedicated to a second patient connected to two IV pumps 12c and 12d and a glucose monitor 12f. Patient databases 10b and 10c can each have a common prescription, e.g., for operating pumps 12a, 12b and for incorporating oxygenator 12e for the first patient, and for operating pumps 12c, 12d and for incorporating glucose monitor 12f for the second patient. Distributed database 10a shares IV pump data across multiple patients, while distributed database 10d shares oxygenator 12e and glucose monitor 12f data across multiple patients. Distributed databases, such as databases 10a and 10d may therefore be dedicated to a patient, a group of like machines, or a group of like functionality, e.g., physiological sensing.


Machines 12 belonging to multiple distributed databases 10a to 10d allow overall system 10 to, for example, share medically related data, e.g. software updates and software configurations, in one distributed database 10a to 10d, while sharing medical data, e.g. prescription input data and treatment output data in another distributed database 10a to 10d. Doing so allows different distributed databases to be managed differently, for example, one distributed database may be a real time database, while another distributed database may be updated at set intervals, e.g., at the end of a shift or workday.


The different distributed databases 10a to 10d can perform different tasks, resulting in a very flexible overall system 10. In FIG. 3, assume for example that machines 12a to 12d are performing hemodialfiltration (“HDF”), while machines 12e and 12f are performing hemodialysis (“HD”). Distributed database 10a accordingly provides prescription parameters and collects treatment output data for HDF, while distributed database 10d does the same for HD. Distributed databases 10b and 10c are then used to share data based on some commonality between machine group 12a, 12b, 12e and group 12c, 12d, 12f, respectively. For example, machine group 12a, 12b, 12e could have a different language or user interface appearance than machine group 12c, 12d, 12f. Distributed databases 10b and 10c provide and track such different languages or user interface appearances.


Or, machine group 12a, 12b, 12e and group 12c, 12d, 12f may require different real time data to be monitored. For example, machine group 12a, 12b, 12e can be dedicated to a certain category of patient, e.g., infants, where operating pressure limits must be monitored very closely.


System 10 of FIG. 3 allows databases 10b and 10c to be real time alarm distributed databases that are separate from and thus incapable of interrupting, main treatment distributed databases 10a and 10d. Distributed database 10b is also able to separate, e.g., infant, machine group 12a, 12b, 12e for specialized shared real time alarm purposes from the shared real time alarms of distributed database 10c for machine group 12c, 12d, 12f (e.g., a normal adult machine group).


Real time alarm data (which is not limited to multiple distributed database scenarios and is described elsewhere in this application) allows nurses and clinicians to see an alarm occurring in a different room, on the other side of a wall, or at the other end of a clinic. The indication of an alarm could be as simple as a small pulsating icon in a corner of the user interface 14 (see FIGS. 8A, 8B, 10) with an indication of which machine 12 is alarming. The nurse or clinician can press the icon to learn more information about which type of alarm is occurring. The icon can be of two or more types (i) for more demanding alarms versus (ii) for more attention alerting alarms. Alternatively, a plurality of icons are provided, for example, with a number, to indicate the type of alarm, e.g., icon with number 1=blood leak alarm, icon with number 2=UF rate alarm, icon with number 3=venous pressure alarm, etc.


Each of the circles illustrated inside machines 12a to 12f of FIG. 3 may represent a different memory 18 (see FIG. 10) within the machines or separate areas of the same memory 18 within the machines. Distributed databases 10a and 10d may be updated and synchronized according to any of the same or different methods discussed below in connection with FIGS. 4A to 7C, at the same or different times. Real time data can also be shared according to the methods discussed below in connection with FIGS. 4A to 6B, with a primary difference being that instead of running only a single time through the flow diagrams from “start” to “end”, which is performed for normal treatment (e.g., at the end of the day), a loop for real time data is cycled from “end” to “start” in at least one of the methods of FIGS. 4A to 6B at a desired frequency to look for new pertinent real time, e.g., alarm, data.


While it is contemplated for system 10 to allow real time data sharing, it is also contemplated for the system to implement safeguards regarding such sharing. For example, in an embodiment, certain functions, such as downloading new software and servicing machines 12 can only take place after treatment when machines 12 are not performing treatment, e.g., are in a service mode, are in a hibernation mode or are otherwise disabled. It may be possible to transfer certain additional data during a disinfection mode when the machine is running but a patient is not connected. When a patient is connected, however, system 10 can be operated so as to take care not to transfer any data that may interrupt treatment or bother the patient.


In an embodiment, real time treatment data is not permanently stored in any machine 12. For example, real time data can be stored for as long as the treatment is ongoing, so that it can be viewed in a summary screen as described in detail herein, or for longer periods, such as a week, multiple weeks, or months. When treatment of any machine 12a to 12j is completed, or the real time data storage period expires, its real time data can be purged. Storing all real time treatment data permanently may fill memory too quickly. Generally, the values that will be stored permanently will be total values, average values, mean values, or other combined or statistically relevant values.


The different distributed databases 10a to 10d can have different updating speeds based, for example, upon which type of medically related data they convey and allow for access. Real time databases 10 may have high frequency update speed (e.g., microseconds, seconds, minutes), while administrative type of databases such as inventory and/or staffing databases 10 can be updated at a slower speed, such as once every hour, day or shift.


Referring now to FIG. 4A, method 200 illustrates one embodiment for assigning tag data or metadata to new data shared by the distributed database system 10 of the present disclosure. Method 200 can be used as a subroutine and at oval 202, method 200 begins. At block 204, a new piece of data or data record is generated. The new data can be any of (i) prescription input parameters or data (e.g., machine operating parameters), (ii) treatment output data (e.g., UF removed, total blood volume moved, total dialysis fluid volume consumed, heparin volume consumed, alarms, and treatment effectiveness measurements Kt/V, etc.), (iii) technical input data (e.g., calibrations, alarm limits, etc.), (iv) technical output data (e.g., actual component usage, sensor measurements, etc.), and (v) administrative data (e.g., inventory data and staffing data) generated by or inputted into any machine 12 of distributed database 10. The new data can be an array of data, for example, a snapshot of treatment output data generated at a particular time, e.g., pressure readings from all pressure sensors of a machine 12 operating at a given time. In this manner, the tag data or metadata can represent a larger collection of data, so that there does not have to be tag data or metadata for each new individual piece of data. New data therefor represents either a single piece of new data or an array of new data.


At block 206, the machine 12 at which the new data (e.g., array of data) is generated generates (i) a unique record identification (“id”), (ii) a time stamp, and (iii) a hash sum or checksum for the new data. The unique record id identifies both the machine 12 and the sequence number for that machine, which created the new data. So in FIG. 1A, if machine 12c at sequence number 0000000444 creates new data, the unique id could be 12c: 0000000444. In essence, the unique id gives the new data a home (the particular machine or computer sharing distributed database system 10) and a location within the home, that is, the sequence number.


The hash sum identifies the actual content of the new data (e.g., array of data). For example, suppose a new array of data includes six pressure readings [a, b, c, x, y, z]. A hash sum, hs002500 could be generated for those readings, so that hs002500=[a, b, c, x, y, z]. hs002500 now represents the six pressure readings. The machines 12 of system 10 therefore do not have to look for the specific pressure readings; rather, the machines look to see if hs002500 exists. As explained in more detail below, the hash sum can be recalculated by a transferee machine of the distributed database after transfer from a transferor machine. The transferee machine can then compare the transferred and calculated hash sums to confirm that data has not been corrupted during transfer or to raise a system error if data corruption is detected. The transferee machine can ask the transferor machine to retransmit the data a predefined number of times, check for data corruption after each transfer, and raise a system error only after the data is found to be corrupted after each of the predefined number of data transfers.


The time stamp identifies the time at which the new data (e.g., array of data) is generated. The time stamp could, for example, be 30 May 2015/8:15 a for data created at 8:15 am on May 30, 2015. The time stamp serves to determine which data to move forward with when two hash sums for the same unique id do not match. In an embodiment, the hash sum corresponding to the later time stamp is chosen, as illustrated below in connection with FIG. 5B. A complete record set of tag data or metadata for data array [a, b, c, x, y, z] could therefor be (i) unique id 12c: 0000000444, (ii) time stamp 30 May 2015/8:15 a, and (iii) hash sum hs002500, or 12c: 0000000444; 30 May 2015/8:15 a; hs002500.


Blocks 208, 210 and 212 of method 200 each involve calculating and updating hash sums for multiple, increasing time periods. In the illustrated embodiment, the time periods include day, month, and multi-month. Alternatively, the time periods could be shift, day, week, and month. There can be as many different time periods as desired, e.g., three to six time periods. The time periods can be any desired duration, e.g., minutes, hours, shifts, days, weeks, months, years, etc. For ease of description, the remainder of the example of FIG. 4A uses day, month, and multi-month time periods.


At block 208, the machine 12 at which the new data (e.g., array of data) is generated calculates or updates a “day hash” for all has sums generated at that machine over the same day or twenty-four hour period during the same month. “day hash 30 May 2015” for example could equal or include hs002500 through hs010000 for a particular machine 12. The “day hash” calculation could be performed at the end of each day for example.


At block 210, the machine 12 at which the new data (e.g., array of data) is generated calculates or updates a “month hash” for all hash sums generated at that machine over the current month. “month hash may” for example could equal or include day hash 1 May 2015 to day hash 31 May 2015. The “month hash” calculation could also be performed at the end of each day, or set of days such as a week, for example.


At block 212, the machine 12 at which the new data (e.g., array of data) is generated calculates or updates a “total hash” for all hash sums generated at that machine over the current year, for example, “total hash 2015” for example could equal or include “month hash january” to “month hash may”. The “total hash” calculation could be performed at machine 12 at the end of each week or month, for example.


At oval 214, method 200 ends.


Referring now to FIG. 4B, method 220 illustrates one embodiment for sending data from one machine 12 to all other machines 12 of distributed database system 10. Method 220 can be used as a subroutine, and at oval 222, method 220 begins. As discussed above, either a single machine 12 or an aggregate of machines 12 can send to all other machines 12b to 12j of system 10. For example, in FIG. 1, a single machine 12a can send its new data to all other (online) machines 12b to 12j of system 10. Or, aggregated new data from machines 12a, 12b and 12c can be sent to all other (online) machines 12d to 12j of system 10. Aggregating the data can optimize (minimize) the number of new data pushes and thereby reduce the potential for error. It should be appreciated therefore that method 220 can be viewed from the standpoint of a single machine 12 sending its new data or as an aggregate of machines (e.g., 12a, 12b, 12c) sending their collective new data.


At block 224, the machine 12 (or aggregate of machines 12) picks a new machine 12 (outside aggregate if aggregate used) of system 10, which is currently online. At block 226, new data along with data tagging or metadata described in FIG. 4A are sent to the recently selected machine. At block 228, the receiving machine 12 calculates its own hash sum for the received new data entry. At diamond 230, the receiving machine 12 determines whether the received hash sum is different than the recently calculated hash sum. If at diamond 230, the received hash sum is different than the recently calculated hash sum, then the newly selected machine 12 notifies the sending machine 12 (single machine 12 or representative machine 12 of an aggregate that sent the new data to the selected machine 12) of the hash sum mismatch. Upon receiving the hash sum mismatch, the sending machine 12 repeats the sending step of block 226, and the loop between block 226 and diamond 228 is repeated until at diamond 230, the received hash sum is the same as the recently calculated hash sum, which ensures eventually that data transfer between the sending and receiving machines 12 is not corrupted.


When it is determined at diamond 230 that the received hash sum is the same as the recently calculated hash sum, the sending machine 12 (single machine 12 or representative machine 12 of an aggregate) determines whether there is another machine 12 (outside aggregate if aggregate used) to which to send the new data. If so, method 220 steps 224 to 232 are repeated until there are no new machines, as determined at diamond 232, at which time method 220 ends, as illustrated at oval 234.


Referring now to FIGS. 5A and 5B, method 300 illustrates one example of how two machines 12 of distributed database system 10, e.g., any two of machines 12a to 12j of FIG. 1A, can synchronize with one another, that is, check to see if they share the same data, and if they do not share the same data, then to update one another as needed so that the two machines do share the same data. At oval 302, method 300 begins. As will be seen from below, method 300 incorporates the data tagging or metadata illustrated in connection with FIG. 4A.


At diamond 304, method 300 determines whether the total hash calculation performed in connection with FIG. 4A for a first machine 12 of the distributed database system 10, e.g., machine 12a, is not equal to the total hash calculation performed in connection with FIG. 4A for a second machine 12 of the distributed database system 10, e.g., machine 12b. Comparing total hash for machine 12a (total hash A) to that of machine 12b (total hash B) is performed at one of the machines in one embodiment. A protocol can be set so that the machine with the lower or earlier identification number performs the comparison, e.g., machine 12a performs the comparison when compared to remaining machines 12b to 12j. Machine 12b performs the comparison when compared to remaining machines 12c to 12j, and so on. In an alternative protocol, both machines perform the comparison to create a check on the result. Here, the machine with the lower or earlier number can be set to perform the comparison first. If the result is not the same for machine 12a performing the total hash comparison versus machine 12b performing the total hash comparison, then method 300 ends in a system error, causing system 10 to prompt an administrator for assistance. The above two protocols, and/or alternatives thereof, can be used for each of the queries performed at diamonds 304, 308, 312, 318 and 320 of FIG. 5A.


If the answer to the query at diamond 304 answer is no, meaning total hash for machine 12a does equal total hash for machine 12b, then the two machines 12a and 12b are synchronized completely. Method 300 proceeds to the end at oval 322.


If the answer to the query at diamond 304 is yes, meaning total hash for machine 12a does not equal total hash for machine 12b, then method 300 looks to drill down into the hash sums to see where the problem lies. At block 306, the comparing machine 12a or 12b (or if both machines compare then the machine performing the comparison first) selects a next month. In an embodiment, the first month selected is the current month because the preceding months may have already been synchronized, leading to the likelihood that the mismatch probably resides in the current month.


At diamond 308, the comparing machine 12a or 12b (or alternatively both machines 12a or 12b as discussed above) determines for the month selected at block 306 whether the month hash for machine A (month hash A) does not equal the month hash for machine B (month hash B). If the answer to the query of diamond 306 is no, meaning that month hash A does equal month hash B, then method 300 proceeds to diamond 320, which queries whether there is another month to analyze. If the answer to the query 320 is no, and there is no other month to analyze, method 300 ends, as illustrated at oval 322. If the answer to the query 320 is yes, and there is another month to analyze, then method 300 returns to select another month at block 306 (e.g., the first preceding month, followed by the second preceding month, and so on), after which the loop just described between block 306, diamond 308 and diamond 320 is repeated until a month hash A mismatch with month hash B occurs at diamond 308, or no more months remain, as determined at diamond 320.


If the total hash query at diamond 304 concludes that a mismatch does exist, but the monthly loop between block 306, diamond 308 and diamond 320 shows no mismatch, then method 300 ends in a system error, causing system 10 to prompt an administrator for assistance.


When method 300 finds a month in which a mismatch has occurred at diamond 308, method 300 next looks for the one or more day of the month in which the mismatch occurred. At block 310, the comparing machine 12a or 12b (or if both machines compare then the machine performing the comparison first) selects a next day. In an embodiment, the first day selected is the current day because the preceding days may have already been synchronized, leading to the likelihood that the mismatch probably resides with the current day.


At diamond 312, comparing machine 12a or 12b (or alternatively both machines 12a or 12b as discussed above) determines for the day selected at block 310 whether the day hash for machine A (day hash A) does not equal the day hash for machine B (day hash B). If the answer to the query of block 306 is no, meaning that day hash A does equal day hash B, then method 300 proceeds to diamond 318, which queries whether there is another day to analyze. If the answer to the query 318 is no, and there is no other day of the current month to analyze, method 300 inquires whether there is another month (e.g., another preceding month) to analyze as discussed above in connection with the loop including diamond 320.


If the answer to query 318 is yes, and there is another day to analyze, then method 300 returns to select another day at block 310 (e.g., the first preceding day, followed by the second preceding day, and so on), after which the loop just described between block 310, diamond 312 and diamond 318 is repeated until a day hash A mismatch with day hash B occurs at diamond 308, or no more days remain, as determined at diamond 318.


If the monthly query at diamond 308 concludes that a mismatch within a month does exist, but the loop between block 310, diamond 312 and diamond 318 shows no day hash mismatch for the month, then method 300 ends in a system error, causing system 10 to prompt an administrator for assistance.


When method 300 finds a day in which a mismatch has occurred at diamond 308, method 300 proceeds to the hash A and hash B synchronization steps illustrated at blocks 314 and 316. At block 314, day hash A is synchronized to machine 12b for the data mismatch date. At block 316, day hash B is synchronized to machine 12a for the data mismatch date. A subroutine for blocks 314 and 316 is discussed next in connection with FIG. 5B. It should be appreciated first, however, that once total hash A is determined to be different than total hash B at diamond 304, there may be multiple days and multiple months within the hash totals that are mismatched. Thus even after performing the synchronizing at blocks 314 and 316 for a given day within a month, there may be one or more other day within the same month needing the synchronization of blocks 314 and 316. Likewise, even after synchronizing one or more days of a first month via the synchronization of blocks 314 and 316, there may be one or more days of one or more additional month of total hash A and total hash B, as determined within the loop defined by block 306 to diamond 320, needing the synchronization of blocks 314 and 316.


Once no more months for machines 12a and 12b need synchronization, as determined by the loop defined by block 306 to diamond 320, method 300 ends, as illustrated at oval 322.


Referring now to FIG. 5B, method 350 illustrates one embodiment for a subroutine used at both blocks 314 and 316 of method 300 of FIG. 5A. In FIG. 5B, X is the initiating or “from” machine in blocks 314 and 316. Thus X is machine 12a in block 314 and machine 12b in block 316. Likewise, Y is machine 12b in block 314 and machine 12a in block 316. At oval 352, method 350 begins.


At block 354, machine X selects a newly created piece or array of data to be analyzed. In one embodiment, machine X knows the last unique id to be analyzed and selects the next unique id in the sequence to be analyzed at block 354.


At diamond 356, method 350 queries whether the Y machine currently stores the corresponding unique id. If the answer is no, and machine Y does not already contain the unique id record being analyzed, then machine X copies and replaces the unique id record (along with its time stamp, hash sum, and corresponding actual data) to machine Y.


If the answer at diamond 356 is yes, and machine Y does already contain the unique id record being analyzed, then method 350 determines whether the current record hash for machine X does not equal the current record hash for machine Y, as determined at diamond 358. If the answer is no, and record hash X does equal record hash Y, then no further action is needed for this unique id, and method 350 proceeds to diamond 366 to look to see if a next unique id exists.


If the answer at diamond 358 is yes, and record hash X does not equal record hash Y, then method 350 at diamond 360 determines which machine's time stamp is later. If the time stamp for machine X is later than the time stamp for machine Y, then machine X at block 362 copies and replaces the unique id record (along with its time stamp, hash sum, and corresponding actual data) to machine Y. Next, at diamond 363, machine Y checks to see whether the unique id record (along with its time stamp, hash sum, and corresponding actual data) transferred correctly to machine Y. In one embodiment, machine Y calculates its own hash sum and compares it to the hash sum received from machine X (as discussed in connection with method 220 of FIG. 4B) to determine if the record transferred correctly. If not, e.g., the calculated hash sum does not equal the received hash sum, machine Y sends a corresponding message to machine X, and machine X repeats the step at block 362. The loop at block 362 and diamond 363 is repeated until the record is transferred correctly, e.g., the calculated hash sum does equal the received hash sum.


If instead the time stamp for machine Y is later than the time stamp for machine X, machine Y at block 364 copies and replaces the unique id record (along with its time stamp, hash sum, and corresponding actual data) to machine X. Next, at diamond 365, machine X checks to see whether the record (along with its time stamp, hash sum, and corresponding actual data) transferred correctly to machine X. In one embodiment, machine X calculates its own hash sum and compares it to the hash sum received from machine Y (as discussed in connection with method 220 of FIG. 4B) to determine if the record transferred correctly. If not, e.g., the calculated hash sum does not equal the received hash sum, machine X sends a corresponding message to machine Y, and machine Y repeats the step at block 364. The loop at block 364 and diamond 365 is repeated until the record is transferred correctly, e.g., the calculated hash sum does equal the received hash sum.


After the verifying step at diamonds 363 or 365, method 350 causes machine X at diamond 366 to look for the next unique id in the sequence. If a next unique id in the sequence exists, method 350 repeats the sequence from block 354 to diamond 366. Eventually, machine X runs out of new data to check for synchronization with machine Y as indicated by negative response to diamond 366, at which time method 350 ends at oval 368. Again, in FIG. 5A, any two machines 12a and 12b for example both get the opportunity to the be the X machine and the Y machine of FIG. 5B.


Referring now to FIG. 5C, method 370 illustrates one embodiment for verifying that data stored in any of machines 12 is correct and not corrupt. In an embodiment, each machine 12 of distributed database system 10 is programmed to perform method 370 routinely on some periodic basis, e.g., upon each power up, upon being awakened from a sleep mode, hourly, daily, at the beginning or end of each shift, at the beginning or end of each treatment, weekly, monthly, or at some other desired period.


At oval 372, method 370 begins. At block 374, the particular machine 12a to 12j selects a next month's worth of data to verify. At block 376, the particular machine 12a to 12j selects a next day's worth of data within the selected month to verify. At block 378, the particular machine 12a to 12j selects the next data (or array of data) to verify for the selected day of the selected month. At block 380, the particular machine 12a to 12j calculates a new hash sum for the selected data (or array of data). At diamond 382, the particular machine 12a to 12j compares the current (previously calculated) hash sum for the data (or array of data) with the newly calculated hash sum for the data (or array of data).


If the answer to diamond 382 is yes, and the current (previously calculated) hash sum for the data (or array of data) does not equal the newly calculated hash sum for the data (or array of data), then the particular machine 12a to 12j takes corrective action, as indicated at block 384, in response to determining that the particular data (or array of data) has become corrupted. In an embodiment, corrective action at block 384 includes deleting the corrupted data (or data array) associated with the current (previously calculated) hash sum. The deleted data will be replaced automatically via the synchronization procedures discussed next in connection with FIGS. 6A and 6B (which use the subroutines of FIGS. 4A, 5A and 5B). In an alternative embodiment, corrective action at block 384 includes automatically invoking a synchronization procedure discussed next in connection with FIGS. 6A and 6B upon learning of corrupt data at diamond 386. The machine 12 can for example be programmed to synchronize with the next downstream machine 12 of the distributed database system 10, e.g., machine 12a having corrupted data synchronizes with machine 12b, machine 12b with machine 12c, machine 12j with machine 12a, and so on.


After corrective action block 384, or if the answer to diamond 382 is no, and the current (previously calculated) hash sum for the data (or array of data) does equal the newly calculated hash sum for the data (or array of data), then the particular machine 12a to 12j at diamond 386 queries whether there is another data record for the particular day to verify. If so, the loop between block 378 and diamond 386 is repeated until there is no new data record for the particular day to verify, upon which the particular machine 12a to 12j at block 388 calculates a new hash sum for the selected day (which corresponds to block 208 of FIG. 4A).


After block 388, the particular machine 12a to 12j at diamond 390 queries whether there is another day in the selected month having data to verify. If so, the loop between block 376 and diamond 390 is repeated until there is no new day within the selected month having a data record to verify, at which time the particular machine 12a to 12j at block 392 calculates a new month hash sum for the selected month (which corresponds to block 210 of FIG. 4A).


After block 392, the particular machine 12a to 12j at diamond 394 queries whether there is another month in the total hash having data to verify. If so, the loop between block 374 and diamond 394 is repeated until there is no new month within the total hash sum calculation having a data record to verify, at which time the particular machine 12a to 12j at block 396 calculates a new total hash sum (which corresponds to block 212 of FIG. 4A).


After block 396, method 370 ends as at oval 398. Method 370 of FIG. 5C as illustrated verifies data, on a machine by machine basis, for all months, days and records of the total hash sum for that machine. Not only is all data for the machine 12 verified, new total hash sums, e.g., total day hash sum, total month hash sum, and total hash sum are also verified. In this manner, if the corrupted data has been sent to any other machine 12 of distributed database system 10, it will be corrected in the other machine 12 of system 10 via the synchronization procedures discussed next.


The methods of FIGS. 4A, 5A and 5B are building blocks used for the “push-pull” method 400 of FIG. 6A and the “pull” method of FIG. 6B. Referring now to FIG. 6A, method 400 illustrates one methodology that can be implemented on distributed database system 10 for updating machines 12, so that each machine 12 includes all data for each patient within a clinic 130 receiving a particular type of treatment. Method 400 is an example of a data synchronization mode in which machines 12 “push” new data to other machines 12 of distributed database system 10 between diamond 404 and block 408, and “pull” data from each other between block 410 and diamond 414. Method 400 can allow each machine 12 to take turns pushing data to the other machines 12 of system 10 or to an aggregate of machines 12. Method 400 is for one machine of distributed database system 10. Method 400 would therefore be repeated for each machine 12, or aggregate of machines 12, of system 10.


At oval 402, method 400 begins. It is possible to begin data updating at a time when machines 12 have finished delivering treatments. For instance, if clinic or dialysis center 130 provides treatment between 8:00 AM and 7:00 PM, method 400 can begin automatically later in the evening, e.g., 11:00 PM during or after machines 12 have all been cleaned and prepared for the next treatment shift or next day. Machines 12 of distributed database system 10 may all be hibernating or in a sleep mode at 11:00 PM. If needed, method 400 wakes each machine 12 of distributed database system 10 from a sleep mode to perform method 400.


Diamond 404 and blocks 406 and 408 for a given machine 12 (or aggregate of machines 12) generate and send any new data for that machine to all other machines of distributed database system 10. At diamond 404, machine 12 determines whether it has any new data to send. If the answer is yes, there is new data to send, machine 12 at block 406 performs the tag data or metadata of method 200 of FIG. 4A. Machine 12 at block 408 then pushes the tagged new data (including unique id record, time stamp, hash sum, and corresponding actual data) to each other machine 12 of distributed database system 10 that is currently online and capable of receiving the tagged new data according to method 220 of FIG. 4B in one embodiment.


It should be appreciated that steps 404 to 408 can be performed (i) so as to push to the other machines each tagged new data individually as it is created, or alternatively (ii) to collect all new data for that day or time period and send the collected data as one packet to all other online machines 12 of distributed database system 10. When there is no other new data for machine 12, as determined at diamond 404, method 400 moves to a synchronization (“pull”) portion to synchronize with any other machine 12 that may have been offline.


The synchronization portion of method 400 is performed at blocks 410, 412 and diamond 414. The same machine 12 (or aggregate of machines 12) at steps 404 to 408 now at block 410 picks another machine 12 of distributed database system 10 to see if any data needs to be synchronized. In an embodiment, machine 12 picks the next addressed machine, and then the following machine and so on. For example, machine 12a first picks machine 12b, then machine 12c, and so on. The last addressed machine picks the first addressed machine, and then proceeds in order, e.g., machine 12j picks machine 12a, then machine 12b, and so on.


At block 412, the given machine 12 and its chosen machine 12 perform the synchronization sequence illustrated in FIGS. 5A and 5B. The synchronization sequence supplies any missing data between the given machine 12 and its chosen machine 12 due, for example, to one or both of the machines having been offline from system 10 at a time in which the other machine generated new data. At diamond 414, the chosen machine 12 checks to see if there is another machine 12 of distributed database system 10 with which to synchronize. If so, steps 410 to 414 are performed again, and so on until chosen machine 12 has synchronized with each other online machine of distributed database system 10, after which method 400 ends as illustrated at oval 416.


Method 400 is then performed for each machine 12 (or aggregate of machines 12) of distributed database system 10. In this manner, each machine 12 (i) sends its new data to each of the other machines 12 of system 10 and (ii) is synched with each other machine of system 10. Thus when a patient arrives at clinic or dialysis center 130, e.g., the next day, the patient can be brought to any machine 12a to 12j of distributed database system 10. That machine will have that patient's full treatment history. The machine will also have the patient's preferred treatment settings, or perhaps multiple sets or ranges of preferred settings for the patient, streamlining treatment setup for the nurse or clinician, and optimizing treatment results for the patient.


An alternative “push” embodiment (not illustrated) is a hub and spoke type of push. One of the machines acts as a hub machine, while other machines of distributed database system 10 act as spokes. Here, one or more machine of the cluster, e.g., machine 12a receives the data from all other machines 12b to 12j. Machines 12b to 12j can each send their respective data according to a sequence requested by hub machine 12a. Hub machine 12a will then store the data from machines 12b to 12j in the order in which the data is sent to hub machine 12a. Once hub machine 12a is fully updated with data from all the other machines of distributed database system 10, hub machine 12a sends out the totalled data, including machine 12a's data, to all other machines 12b to 12j in the distributed database system 10, which can again be according to a sequence requested by hub machine 12a. Again, in the end, each of the, e.g., ten machines, should have the same data from every other machine of the distributed database system.


Referring now to FIG. 6B, method 430 illustrates another methodology that can be implemented on distributed database system 10 for updating machines 12, so that each machine 12 includes all data for each patient within a clinic 130, or for each patient receiving a particular type of treatment within clinic 130. Method 430 is an example of a data synchronization mode in which machines 12 “pull” new data from other machines 12 of distributed database system 10 or an aggregate of machines as has been described herein. Method 430 is for one machine of distributed database system 10 or an aggregate of machines 12 as has been described herein. Method 400 would therefore be repeated for each machine 12, or aggregate of machines 12, of the system.


At oval 432, method 430 begins. Steps 434 and 436 are very similar to steps 404 and steps 406 of method 400 of FIG. 6A. Step 436 is performed in accordance with method 200 of FIG. 4A. Here, however, machine 12 data tags all of its new data at steps 434 and 436 at once but does not send it to the other machines 12 of distributed database system 10. Step 408 of method 400 is missing in method 430. The new data is instead pulled from machine 12 via the synchronization process of steps 438 to 442, which are performed the same as steps 410 to 414 described above for method 400 of FIG. 6A.


The same machine 12 or aggregate of machines 12 at steps 434 and 436 now at block 438 picks another machine 12 of distributed database system 10 to see if any data needs to be synchronized. In an embodiment, machine 12 picks the next addressed machine, and then the following machine and so on, as described above. At block 440, the given machine 12 and its chosen machine 12 perform the synchronization sequence illustrated in FIGS. 5A and 5B. The synchronization sequence supplies any missing data between the given machine 12 and its chosen machine 12 due, for example, to one or both of the machines having been offline from system 10 at a time in which the other machine generated new data. At diamond 442, the given machine 12 checks to see if there is another machine 12 of distributed database system 10 with which to synchronize. If so, steps 438 to 442 are performed again, and so on until the given machine 12 has synchronized with each other online machine of distributed database system 10, after which method 430 ends as illustrated at oval 444.


Method 430 is then performed for each machine 12, or aggregate of machines 12, of distributed database system 10. Thus each machine 12 (i) pulls data from and (ii) is synchronized with each other machine 12 of distributed database system 10. Afterwards, when a patient arrives at clinic or dialysis center 130, e.g., the next day, the patient can be brought to any machine 12a to 12j of distributed database system 10. That machine will have that patient's full treatment history and preferred settings.


Referring now to FIG. 7A, method 500 illustrates one embodiment for providing software updates to the machines of distributed database system 10. Software updates in an embodiment are operating software updates, which can be main control software, user interface software, safety software, software for peripheral items (such as a water system or remote sensors), software configurations (user/clinic preferences for how machines 12 should work in their particular settings), and any combination thereof. At oval 502, method 500 begins. At block 504, new software is downloaded to one of machines 12 of distributed database system 10. The software can be downloaded via a USB drive at the machine or over LAN 150 via any of the LAN embodiments described above. The software can be provided from server computer 180 in one embodiment.


In an embodiment, new software is downloaded automatically to the lowest numbered or earliest lettered addressed machine 12 of distributed database system 10 that is online. For example, server computer 180 via LAN 150 would download the software to machine 12a if it is online, or to machine 12b if it is online and machine 12a is offline. Alternatively, an installer can bring a USB drive manually to any machine 12a to 12j of distributed database system 10 for initial installation. That machine would then select the next addressed online machine, e.g., if the installer brings the USB drive to machine 12g, machine 12g would thereafter deliver the new software to machine 12h, and so on.


At diamond 506, the user (nurse or clinician) at the initial machine 12 decides whether or not to confirm the installation of the new operating software. The user does not have to accept the new software for whatever reason, for example, the user likes the current software. If the user decides not to accept the new software at block 508, the new software is not installed at the initial machine 12. The new software nevertheless resides in the memory of the initial machine 12, with a flag that it has been rejected and the date rejected. A system administrator can be notified that the initial machine 12 rejected the software. The rejected software can be accepted at a later date, and may be configured to periodically prompt the user to see if they are ready for the software update.


If the user decides to accept the new software at diamond 506, the new software or configuration of software at block 510 is installed at the initial machine 12. In either case, after block 508 (download but no install) or block 510 (download and install), the initial machine picks a new machine 12 of distributed database system 10 and asks the new machine using LAN 150 whether the new machine needs the new software, as indicated at diamond 514. Again, the new machine can be the next addressed machine, e.g., machine 12a selects machine 12b, which selects machine 12c, and so on. Machine 12j (of FIG. 1A) would select first machine 12a.


If the answer is to the question of diamond 514 is no, e.g., the new machine 12 already has the new operating software, then initial machine 12 at diamond 518 looks to see if another machine of distributed database system 10. If the answer to the question of diamond 514 is yes, e.g., the new machine 12 needs the new operating software, then the installation subroutine at block 516 is performed. The installation subroutine is discussed in detail below in connection with FIG. 7B.


When the installation subroutine at block 516 is completed, or if the new machine does not need the new operating software as determined at diamond 514, method 500 at diamond 518 determines whether there is another machine of distributed database system 10 to query. If so, then the loop created between block 512 to diamond 518 is repeated until there is no other machine of distributed database system 10 to query. Method 500 then ends at oval 520.


Referring now to FIG. 7B, method 530 illustrates one embodiment for the installation subroutine 516 of method 500 of FIG. 7A. At oval 532, method 530 begins by downloading the new operating software to the new machine (e.g., from the initial machine to the first new machine, from the first new machine to the second new machine, from the second new machine to the third new machine, and so on). At diamond 534, the user (nurse or clinician) at the new machine 12 decides whether or not to confirm the installation of the new operating software. The user again does not have to accept the new software for whatever reason, for example, the user likes the current software. If the user decides not to accept the new software at block 536, the new software is not installed at the new machine 12. The new software nevertheless resides in the memory of new machine 12, with a flag that it has been rejected and the date rejected. A system administrator can be notified that the new machine 12 has rejected the new operating software. The rejected software can be accepted at the new machine at a later date, and may be configured to periodically prompt the user to see if they are ready for the software update.


If the user at the new machine decides to accept the new software at diamond 534, the new software or configuration of software at block 538 is installed at the new machine 12. In either case, after block 536 (download but no install) or block 538 (download and install), the initialization subroutine of method 530 ends, as indicated at oval 540. Upon returning to the loop created between block 512 and diamond 518, the new machine becomes the first new machine, which at block 512 picks a second new machine. If the second new machine needs the new operating software, as determined at diamond 514, then in subroutine 516, the first new machine downloads the new software to the second new machine. If the second new machine does not need the new operating software, as determined at diamond 514, then a third new machine can be picked at block 512. If the third new machine needs the new operating software, as determined at diamond 514, then in one embodiment of subroutine 516, the first new machine downloads the new software to the third new machine. In an alternative embodiment, because the second new machine already had the new operating software, as determined at diamond 514, the second new machine can download the new software to the third new machine.



FIGS. 7A and 7B illustrate an example of where new operating software is pushed out to each online machine 12 of distributed database system 10 sequentially, machine to machine. In an alternative embodiment, system 10 instead pushes the new operating software out to each online machine 12 at once, in parallel. A user (nurse or clinician) at each machine then proceeds through steps 506 and 508 or 510 (or steps 534 and 536 or 538) in the manner described above.


Method 550 of FIG. 7C, on the other hand, is performed in one embodiment when a machine 12 that has been offline comes back online. Here, the newly online machine 12 looks to the other machines 12 of distributed database system 10 to see if there is any new operating software to “pull”. If so, the newly online machine is given the option of choosing to install such software. Method 550 begins at oval 552. At block 554, the newly online machine 12 picks a machine of distributed database system 10 to query. As before, machine 12 can pick the next addressed machine, e.g., machine 12d first picks machine 12e, then machine 12f, then machine 12g, and so on.


At diamond 556, the newly online machine 12 compares its operating software version(s) with that of the selected machine to see if the selected machine has a higher version(s). If no, the newly online machine 12 checks if there is another machine to query at diamond 560. If yes, the newly online machine 12 retrieves (but does not install) the newer software from the selected machine, as indicated at block 558. After block 558, or if the answer to diamond 556 is no, the newly online machine checks to see if there is another machine to query at diamond 560. If there is another machine 12 to query, newly online machine 12 at diamond 556 compares its latest software version (its original software version or a newer version retrieved at block 558) to that of the second selected machine to see if the second selected machine 12 has an even later version. If so, the newly online machine retrieves the even later version and purges the earlier version. The loop at block 554 to diamond 560 is repeated until the newly online machine 12 queries all other online machines 12 of distributed database system 10, as determined at diamond 560.


At diamond 562, if the newly online machine 12 has retrieved no new software, then method 550 ends at oval 570. At diamond 562, if the newly online machine 12 has retrieved new software, then the user (e.g., nurse of clinician) at diamond 564 is prompted to either confirm or deny the installation of the newly retrieved software. The user again does not have to accept the new software for whatever reason, for example, the user likes the current software. If the user decides not to accept the new software at block 566, the new software is not installed at the new machine 12. The new software nevertheless resides in the memory of new machine 12, with a flag that it has been rejected and the date rejected. A system administrator can be notified that the new machine 12 has rejected the software. The rejected software can be accepted at the newly online machine 12 at a later date, and may be configured to periodically prompt the user if they are ready for the software update.


If the user at the newly online machine decides to accept the new software at diamond 564, the new software or configuration of software at block 568 is installed at new machine 12. Method 550 then ends at oval 570. It should be appreciated that the software receiving machine 12 of method 550 does not have to be a newly online machine and can instead be each machine 12 of distributed database system 10, which prompts itself periodically to see if there is any newer operating software to download for approval. Also, in any software update scenario discussed herein, while it may be advantageous or needed under a regulatory control to require user acceptance or confirmation, e.g., at diamond 564 above, such acceptance or confirmation in an alternative embodiment is not required.


Referring now to FIGS. 8A and 8B, real time data is not limited to alarms and can include other information pertinent to a nurse or clinician. FIG. 8A illustrates an example home screen 242 of user interface 14 (see additionally FIG. 10), which can be displayed on user interface 14 (see FIG. 10 below) of machine 12. In the illustrated embodiment, home screen 242 is for a hemodialysis (“HD”) machine or hemodiafiltration (“HDF”) machine and displays prescription parameters and treatment output data pertinent to HD or HDF. Home screen 242 also displays a “clinic summary” button 244 that when pressed takes the nurse or clinician to a clinic summary screen 246 of user interface 14 illustrated in FIG. 8B. Clinic summary screen 246 includes a “home” button 248, which when pressed takes the nurse or clinician back to home screen 242. The nurse or clinician can therefore very quickly via two presses of a button, from any machine 12 of a distributed database system 10, see a summary of real time progress of all machines 12 of the distributed database, and then return to the user interface display of the machine 12 at which the nurse or clinician is attending.


Clinician's summary screen 246 of FIG. 8B can display any desired information. In the illustrated embodiment, clinician's summary screen 246 displays for each machine 12a to 12j information regarding current state of the machine (e.g., running, paused, under alarm condition, or not in use), elapsed treatment time, time of treatment remaining, amount of UF collected, patient blood pressure, and alarm history. Other treatment output data could also be displayed. Moreover, one or more of the displayed data can also be a button that the nurse or clinician can press to gather more information regarding the selected data.


As discussed above with FIG. 3, it is contemplated that the real time data of clinician's summary screen 246 be shared on a different distributed database than the prescription parameters and treatment output data shared for normal treatment. To do so, timer and sensor outputs can be sent to different memories 18 (see FIG. 10 below) or areas of the same memory 18. For example, the patient's blood pressure reading could be sent to a first memory 18 or area of memory 18 for normal treatment sharing on a first distributed database, and to a second memory 18 or area of memory 18 for real time streaming on a second distributed database. In this way, a malfunction or corruption of data of the second, real time streaming distributed database does not affect normal operation of machines 12 or the sharing of normal prescription parameters or treatment output data.


Besides the clinician's summary screen, it is contemplated to provide one or more additional summary screens, such as a treatment summary screen, patient summary screen, planning summary screen, inventory or stock keeping summary screen, and staffing summary screen. Each of the screens can be called up via a home screen button as illustrated above in FIG. 8A. Where multiple summary screens are contemplated, home screen 242 can provide a “summary” button, which when pressed calls up a series of summary buttons, one each for “clinic summary”, “treatment summary”, “patient summary”, “planning summary”, “stock keeping summary” and “staffing summary”. Pressing any of the summary buttons takes the user to the appropriate screen, which is outfitted with a return “home” button 248.


In general, a “treatment summary” button when pressed leads to a screen providing information for a single patient and a single treatment. The “patient summary” button when pressed leads to a screen providing information for a single patient over multiple treatments. The “planning summary” button when pressed leads to a screen that can be a daily, weekly, and/or monthly calendar showing planned dates for one or more patient's treatments. The “stock keeping summary” button when pressed can lead to a stock summary screen listing supply names, how many of each supply is in stock and how many of each supply is on back order. The “staffing summary” button when pressed can lead to a “staffing summary” screen listing all clinicians, nurses and doctors associated with the clinic, and which ones are currently at the clinic, their shift times, their technical specialties, and the like. Thus a nurse or clinician at any machine 12 of distributed database 10 can reach any of the above summaries of information, quickly and easily.


In one embodiment, a user such as a nurse or clinician must enter identification and receive authorization to review any information of the distributed databases of the present disclosure, including the summary information just described. For example, machine 12 between home screen 242 and clinician summary screen 246 can present an authentication screen (not illustrated), which requests the user's user identification and password. Machine 12 is programmed such that only after entry of an authorized username and password can the requesting nurse or clinician see clinician summary screen. It is likewise contemplated for the retrieval of any and all distributed database data, e.g., any medically related data as described above, to be username and password protected. Remote computers 170 and PCD's 175 may be subject to even more stringent authentication, such as being required to manually enter a Completely Automated Public Turing test to tell Computers and Humans Apart (“CAPTCHA”) code generated at the remote computers 170 and PCD's 175. Strong authentication can also be required at machine 12 and/or at the remote computers 170 and PCD's 175, e.g., in the form of an authentication (e.g., login) based on something the requesting person knows (e.g., a password) and something the requesting person possesses (e.g., an authorization card). Moreover, it is contemplated that system 10 keep track, e.g., at one or more of machine 12, server 180, and/or personal computer 170, of a log of which people, e.g., of a clinic 130a to 130c, have accessed which data on distributed database system 10. In this manner, a listing of which individuals have accessed any particular data of system 10 can be generated.


Referring now to FIG. 9, method 250 illustrates one possible life cycle for machine prescription parameter or treatment output data (“data”) acquired by distributed database system 10 via one of the methods discussed above in connection with FIGS. 4A to 6B. At oval 252, method 250 begins. At block 254, new data is acquired at one of machines 12a to 12j of distributed database system 10. At block 256, the newly acquired data is inputted into a moving average trend. For example, the data could be an amount of ultrafiltration (“UF”) removed from the patient, which is entered as the latest or most recent UF entry in an ongoing or moving UF trend. The trend can include multiple trends, such as an actual data trend, a three-day moving average trend, a seven-day moving average trend, etc. System 10 of the present disclosure takes advantage of the compiling of data for multiple patients and multiple treatments, where trending and the calculation of averages are two examples.


At block 258, the new data and the updated trend are synchronized to the other machines 12 of distributed database system 10. The synchronization can be performed according to any of the methods discussed above in connection with the methods of FIGS. 4A to 6B. The nurse or clinician can then see the data in tabulated and trended form at each of machines 12a to 12j of distributed database system 10.


An optional step is provided at block 260 (shown in phantom line). The data here is backed up to one or more server computer 180 or personal computer 170. As discussed herein, distributed database system 10 can operate without any server computers. For example the backup at block 260 could instead be to an external memory storage device, e.g., a USB or flash drive. However, if the clinic 130 wants to connect a server computer 180 or personal computers 170 to LAN 150, distributed database system 10 provides the opportunity to do so, e.g., for use as backup memory devices.


At block 262, the data is purged from distributed database system 10 after a time period, e.g., six months or one year, as desired, and as dictated by the memory capacity of machines 12a to 12j of distributed database system 10. In this manner, the memory capacity of machines 12a to 12j does not have to be unduly large. However, even though the individual data points are purged, the data can still be maintained on machines 12 of LAN 150 as part of one or more trend. Also, the data can be backed-up and retrieved from memory storage at a later time if needed.


It should be noted that the memory or hard disk needed for most machines 12 will at the time of filing this application have a typical capacity from about thirty-two to sixty-four gigabytes. In many cases, the size of memory for machines 12 is selected based upon cost, where a larger memory can actually be less expensive than a smaller memory because the larger memory is in greater supply and/or is more readily available. If a typical treatment requires about two to four kilobytes of data, machines 12 can store on the order of million treatments. Assuming that a given machine 12 performs 5,000 treatments during its lifetime of, for example, ten years, that machine 12 can store treatment data for 200 machines. Nevertheless, data may need to be purged from system 10 reasons other than storage capacity. For example, medical regulations of certain jurisdictions can require that information about a patient be removed when the patient no longer has a relationship with a clinic. Thus at block 262, the designated time period may be due to a regulatory requirement rather than a memory storage issue.


To delete or remove data, system 10 in one embodiment deletes the data but leaves metadata attached to the data. System 10 uses the left-behind metadata to make sure the deleted data is not restored when a machine 12 that has been disconnected from the distributed database at the time of deletion is later reconnected. System 10 provides a hand shaking process to ensure that all deleted data is deleted from all machines 12 in the distributed database. Here, deleted data is given a new header or identifier and a trail for how and when the data has been deleted. The header and trail are propagated out to the other machines 12 according to any of methods discussed in connection with FIGS. 4A to 6B, so that the other machines can see that there is new “deleted” data and update their data in the same position with deleted data. It is further contemplated to provide an array in the header to track whether all machines 12 have deleted the data or not. Additional headers can be built to ensure that after all machines 12 have received the deleted data message, the data is actually deleted, freeing the cells in memory 18 (FIG. 10) to be used for new data.


At oval 264, method 250 ends.



FIGS. 10 and 11 provide detail on hemodialysis, hemodiafiltration and hemofiltration versions of machine 12. Much of the structure of renal failure therapy machines 12, e.g., user interface, processing, memory, pumps, is likewise provided on other types of machines. It is contemplated, however, that any of the input parameters and treatment output data associated with the renal failure therapy machines 12 discussed next be included in the updates data just described.



FIG. 10 illustrates that renal failure therapy machine 12 incudes a user interface 14, which allows a nurse or other operator to interact with renal failure therapy machine 12. User interface 14 can have a monitor screen operable with a touch screen overlay, electromechanical buttons, e.g., membrane switches, or a combination of both. User interface 14 is in electrical communication with at least one processor 16 and at least one memory 18. As discussed above, at least one memory 18 can have a capacity of thirty-two to sixty-four gigabytes. At least one processor 16 can have a standard processing speed known to those at the time of filing, e.g., two gigahertz. Processor 16 and memory 18 also electronically interact with, and where appropriate, control the pumps, valves and sensors described herein, e.g., those of dialysate circuit 30. At least one processor 16 and at least one memory 18 are referred to collectively herein as a logic implementer 20.


Dialysate circuit 30 includes a purified water inlet line 32, an acid (“A”) concentrate line 34 and a bicarbonate (“B”) concentrate line 36. Purified water inlet line 32 receives purified water from a purified water device or source 22. The water may be purified using any one or more process, such as, reverse osmosis, carbon filtering, ultraviolet radiation, electrodeionization (“EDI”), and/or ultrafiltering.


An A concentrate pump 38, such as a peristaltic or piston pump, pumps A concentrate from an A concentrate source 24 into purified water inlet line 32 via A concentrate line 34. Conductivity cell 40 measures the conductive effect of the A concentrate on the purified water, sends a signal to logic implementer 20, which uses the signal to properly proportion the A concentrate by controlling A concentrate pump 38. The A conductivity signal is temperature compensated via a reading from temperature sensor 42.


A B concentrate pump 44, such as a peristaltic or piston pump, pumps B concentrate from a B concentrate source 26 into purified water inlet line 32 via B concentrate line 36. Conductivity cell 46 measures the conductive effect of the B concentrate on the purified water/A concentrate mixture, sends a signal to logic implementer 20, which uses the signal to properly proportion the B concentrate by controlling B concentrate pump 44. The B conductivity signal is also temperature compensated via a reading from temperature sensor 48.


A heating tank 50 operates with a heater 52 controlled by logic implementer 20 to heat purified water for treatment to body temperature, e.g., 37° C. Heating the water in tank 50 will also degas the water. For ease of illustration, a separate degassing chamber and pump are not illustrated but may be provided to aid expansion tank 50 in removing air from the purified water. The fluid exiting conductivity cell 46 is therefore freshly prepared dialysate, properly degassed and heated, and suitable for sending to dialyzer 102 for treatment. A fresh dialysate pump 54, such as a gear pump, delivers the fresh dialysate to dialyzer 102. Logic implementer 20 controls fresh dialysate pump 54 to deliver fresh dialysate to dialyzer 102 at a specified flowrate as described in more detail below.


A drain line 56 via a used dialysate pump 58 returns used dialysate from the dialyzer to a drain 60. Logic implementer 20 controls used dialysate pump 58 to pull used dialysate from dialyzer 102 at a specified flowrate. An air separator 62 separates air from the used dialysate in drain line 56. A pressure sensor 64 senses the pressure of used dialysis fluid within drain line 56 and sends a corresponding pressure signal to logic implementer 20.


Conductivity cell 66 measures the conductivity of used fluid flowing through drain line 56 and sends a signal to logic implementer 20. The conductivity signal of cell 66 is also temperature compensated via a reading from temperature sensor 68. A blood leak detector 70, such as an optical detector, looks for the presence of blood in drain line, e.g., to detect if a dialyzer membrane has a tear or leak. A heat exchanger 72 recoups heat from the used dialysate exiting dialysate circuit 30 to drain 60, preheating the purified water traveling towards heater 52 to conserve energy.


A fluid bypass line 74 allows fresh dialysate to flow from fresh dialysate line 76 to drain line 56 without contacting dialyzer 102. A fresh dialysate tube 78 extends from renal failure therapy machine 12 and carries fresh dialysate from fresh dialysate line 76 to dialyzer 102. A used dialysate tube 80 also extends from renal failure therapy machine 12 and carries used dialysate from dialyzer 102 to drain line 56.


Fresh dialysate line also includes a conductivity sensor or cell 82 that senses the conductivity of fresh dialysate leaving a UF system control unit 90 and sends a corresponding signal to logic implementer 20. The conductivity signal of cell 82 is likewise temperature compensated via a reading from temperature sensor 84.


An ultrafilter 86 further purifies the fresh dialysate before being delivered via dialysate line 76 and fresh dialysate tube 78 to dialyzer 102. As discussed in more detail below, one or more ultrafilter 88 can be used to purify the fresh dialysate to the point where it can be used as substitution fluid to perform pre- or post-dilution hemofiltration or hemodiafiltration.


UF system 90 monitors the flowrate of fresh dialysate flowing to dialyzer 102 (and/or as substitution fluid flowing directly to the blood set (FIG. 11)) and used fluid flowing from the dialyzer. UF system 90 includes fresh and used flow sensors Q1c and Q2c, respectively, which send signals to logic implementer 20 indicative of the fresh and used dialysate flowrate, respectively. Logic implementer 20 uses the signals to set used dialysate pump 58 to pump faster than fresh dialysate pump 54 by a predetermined amount to remove a prescribed amount of ultrafiltration (“UF”) from the patient over the course of treatment. Fresh and used flow sensors Q1p and Q2p are redundant sensors that ensure UF system 90 is functioning properly.


Renal failure therapy machine 12 uses plural valves 92 (collectively referring to valves 92a to 92l) under the control of logic implementer 20 to selectively control a prescribed treatment. In particular, valve 92a selectively opens and closes bypass line 68, e.g., to allow disinfection fluid to flow from fresh dialysate line 76 to drain line 56. Valve 92b selectively opens and closes fresh dialysate line 76. Valve 92c selectively opens and closes used dialysate or drain line 56. Valve 92d selectively opens and closes drain line 56 to drain 60. Valve 92e selectively opens and closes purified water line 32 to purified water source 22. Valves 92f and 92g control A and B concentrate flow, respectively. Valves 92h to 92k operate with UF system 90.



FIG. 10 further illustrates a substitution line 96 (located inside the housing of machine) extending off of fresh dialysate line 76. Substitution line 96 is fluidly coupled to a substitution tube 98 of a blood set 100 discussed below. A valve 92l under control of logic implementer 20 selectively opens and closes substitution line 96. A substitution pump 94 under control of logic implementer 20 selectively pumps fresh dialysate from ultrafilter 86 through a second ultrafilter 88 to produce replacement or substitution fluid, which is delivered via substitution line 96 (within machine housing) and a substitution tube 98 (external to machine housing) to arterial blood line 106 and/or venous blood line 108 instead of fresh dialysate via line 76 (hemofiltration (“HF”)) or in addition to fresh dialysate via line 76 (for hemodiafiltration (“HDF”)).



FIG. 11 illustrates one embodiment of a blood set 100 that can be used with renal failure therapy machine 12. Blood circuit or set 100 includes a dialyzer 102 having many hollow fiber semi-permeable membranes 104, which separate dialyzer 102 into a blood compartment and a dialysate compartment. The dialysate compartment during treatment is placed in fluid communication with a distal end of fresh dialysate tube 78 and a distal end of used dialysate tube 80. For HF and HDF, a separate substitution tube, in addition to fresh dialysate tube 78, is placed during treatment in fluid communication with one or both of arterial line 106 and venous line 108. In HDF, dialysate also flows through dialysate tube 78 to dialyzer 102, while for HF, dialysate flow through tube 78 is blocked.


Arterial line 106 includes a pressure pod 110, while venous line 108 includes a pressure pod 112. Pressure pods 110 and 112 operate with blood pressure sensors (not illustrated) mounted on the machine housing, which send arterial and venous pressure signals, respectively, to logic implementer 20 (FIG. 10). Venous line 108 includes an air separation chamber or venous drip chamber 114, which removes air from the patient's blood before the blood is returned to patient 116.


Arterial line 106 of blood circuit or set 100 is operated on by blood pump 120, which is under the control of logic implementer 20 to pump blood at a desired flowrate. Renal failure therapy machine 12 also provides multiple blood side electronic devices that send signals to and/or receive commands from logic implementer 20. For example, logic implementer 20 commands pinch clamps 122a and 122b to selectively open or close arterial line 106 and venous line 108, respectively. A blood volume sensor 124 monitors how the patient's hematocrit changes over the course of treatment. Blood volume sensor 124 is in one embodiment placed in arterial line 106 upstream of the blood pump. Air detector 126 looks for air in the venous blood line. Substitution tube 98 as illustrated can be coupled to arterial line 106 for pre-dilution HF or HDF and/or venous line 108 for post-dilution HF or HDF.


It should be understood that various changes and modifications to the presently preferred embodiments described herein will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the present invention and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.

Claims
  • 1. A medical device system comprising: a plurality of medical devices each including a memory, the plurality of medical devices communicatively coupled such that the memories collectively form a distributed database;anda logic implementer associated with each medical device, wherein each logic implementer is programmed to automatically access the distributed database, so that each medical device of the system periodically (i) delivers at least one selected from the group consisting of prescription input parameters and treatment output data to at least one of the other medical devices and (ii) retrieves at least one selected from the group consisting of prescription input parameters and treatment output data from at least one of the other medical devices,wherein the medical devices are configured to communicate directly with at least one of the other medical devices via the distributed database,wherein at least one of the logic implementers is configured to periodically push at least one of the prescription input parameters or the treatment output data to at least one of the other medical devices without instruction from a centralized server,wherein at least one of the logic implementers is configured to periodically pull at least one of the prescription input parameters or the treatment output data from at least one of the other medical devices without instruction from a centralized server by after receiving a request to perform a renal failure treatment for a patient in a logic implementer of a selected one of the medical devices, compare, via the logic implementer a most recent time stamp of prescription input parameters related to the patient at the selected medical device to time stamps of prescription input parameters related to the same patient at the other medical devices,determine a most recent time stamp in one of the other medical devices,select the prescription input parameters corresponding to the most recent time stamp from the other medical device, andlocally store in the selected medical device the prescription input parameters corresponding to the most recent time stamp to perform the renal failure treatment for the patient, andwherein the medical devices are renal failure therapy machines.
  • 2. The medical device system of claim 1, wherein the medical devices are in data communication with each other via a local area network used in connection with the distributed database.
  • 3. The medical device system according to claim 1, wherein each of the medical devices is updated to store the same at least one of the prescription input parameters or the treatment output data for each of a plurality of patients.
  • 4. The medical device system according to claim 1, wherein the medical devices and the distributed database do not interact with a centralized server.
  • 5. The medical device system according to claim 1, wherein the medical devices are provided by first and second manufacturers, and which includes an interface enabling the medical devices of the first and second manufacturers to communicate with one another.
  • 6. The medical device system according to claim 1, wherein at least one selected from the group consisting of the (i) prescription input parameters and (ii) treatment output data is shared via the distributed database along with at least one other selected from the group consisting of (iii) technical input data, (iv) technical output data, and (v) administrative data.
  • 7. The medical device system according to claim 1, wherein the distributed database also shares information from at least one medical equipment selected from the group consisting of: a weight scale, a blood pressure measurement device, a glucose sensor, a physiological sensor, an electrocardiogram device, water treatment equipment, a bed scale, an access disconnection device, a bioimpedance measurement device, a pH sensor, lab testing equipment, a blood sample analyzer, and an access flow measurement device.
  • 8. The medical device system according to claim 1, wherein the distributed database is a first distributed database, and which includes a second distributed database that shares information from at least one medical equipment selected from the group consisting of: a weight scale, a blood pressure measurement device, a glucose sensor, a physiological sensor, an electrocardiogram device, water treatment equipment, a bed scale, an access disconnection device, a bioimpedance measurement device, a pH sensor, lab testing equipment, a blood sample analyzer, and an access flow measurement device.
  • 9. The medical device system according to claim 1, wherein periodically delivering and retrieving prescription input parameters or treatment output data includes doing so in at least one selected from the group consisting of: real time, a matter of seconds, a matter of minutes, hourly, daily, weekly, monthly, at an end of a treatment, at an end of a treatment day, and at an end of a treatment shift.
  • 10. The medical device system according to claim 1, which is configured to share operating software between the medical devices via the distributed database.
  • 11. The medical device system according to claim 1, wherein the distributed database is a first distributed database, and which includes a second distributed database, wherein the logic implementer of at least one of the plurality of the medical devices is programmed to access the second distributed database.
  • 12. The medical device system according to claim 11, wherein one of the distributed databases is a real time data database.
  • 13. The medical device system according to claim 11, wherein one of the distributed databases is an administrative data database.
  • 14. The medical device system according to claim 1, wherein each medical device is programmed to periodically verify the at least one of the prescription input parameters or the treatment output data.
  • 15. The medical device system according to claim 14, wherein verification is performed via a comparison of hash sums.
  • 16. The medical device system according to claim 1, wherein the plurality of medical devices are programmed to periodically synchronize the at least one of the prescription input parameters or the treatment output data.
  • 17. The medical device system according to claim 16, wherein synchronization is performed via a comparison of at least one selected from the group consisting of record identifications, hash sums, and time stamps.
  • 18. The medical device system according to claim 1, wherein at least one of the medical devices is programmed to display at least one summary screen showing at least one of the prescription input parameters and treatment output data for different medical devices of the system.
  • 19. A medical device distributed database system comprising: a plurality of medical devices each including a memory, the medical devices including renal failure therapy machines for preforming renal failure treatments;a first distributed database automatically sharing first data generated or used by a plurality of first medical devices amongst the plurality of medical devices, the memories of the plurality of first medical devices collectively forming the first distributed database; anda second distributed database automatically sharing (i) second data generated or used by the plurality of first medical devices amongst the plurality of medical devices, (ii) second data generated or used by a plurality of second medical devices amongst the plurality of medical devices, or (iii) second data generated or used by medical equipment, at least one of (a) the memories of the plurality of first medical devices or (b) the memories of the plurality of second medical devices collectively forming the second distributed database,wherein at least one medical device of the plurality of first medical devices is configured to periodically push the first data including at least one of prescription input parameters or treatment output data to at least one of the other medical devices of the plurality of first medical devices without instruction from a centralized server, andwherein at least one medical device of the plurality of first medical devices is configured to periodically pull the first data including at least one of the prescription input parameters or the treatment output data from at least one of the other medical devices of the plurality of first medical devices without instruction from a centralized server by after receiving a request to perform a renal failure treatment for a patient in the at least one medical device, compare a most recent time stamp of prescription input parameters related to the patient at the at least one medical device to time stamps of prescription input parameters related to the same patient at the plurality of first medical devices,determine a most recent time stamp in one of the plurality of first medical devices,select the prescription input parameters corresponding to the most recent time stamp from the determined first medical device, andlocally store in the at least one medical device the prescription input parameters corresponding to the most recent time stamp to perform the renal failure treatment for the patient.
  • 20. The medical device distributed database system according to claim 19, wherein one of the plurality of first medical devices and one of the second medical devices are configured to provide treatment to a same patient.
  • 21. The medical device distributed database system according to claim 19, wherein one of the first medical devices and one of the medical equipment are configured to provide treatment to a same patient.
  • 22. The medical device distributed database system according to claim 19, wherein the first medical devices are for providing treatment to a first group of patients and the second medical devices are for providing treatment to a second group of patients.
  • 23. A medical device comprising: at least one medical fluid pump;a plurality of other medical devices including respective memories that form a distributed database, the plurality of other medical devices each including a renal failure therapy machine; anda logic implementer including a memory and operating the at least one medical fluid pump so as to accept a pump input parameter and generate pump output data, the logic implementer programmed to (i) automatically share at least one selected from the group consisting of the pump input parameter and the pump output data with the plurality of other medical devices via the distributed database, and (ii) automatically receive at least one selected from the group consisting of a pump input parameter and pump output data from the plurality of other medical devices via the distributed database,wherein the memory of the logic implementer is configured to be communicatively coupled with the memories of the other medical devices to form the distributed database, such that the logic implementer is able to communicate directly with at least one of the other medical devices via the distributed database,wherein the logic implementer is configured to periodically push at least one of the pump input parameter or the pump output data to at least one of the other medical devices without instruction from a centralized server, andwherein the logic implementer is configured to periodically pull at least one of the prescription input parameters or the treatment output data from at least one of the other medical devices without instruction from a centralized server by after receiving a request to perform a renal failure treatment for a patient in the logic implementer of the at least one medical fluid pump, compare, via the logic implementer a most recent time stamp of pump input parameters related to the patient at the at least one medical fluid pump to time stamps of pump input parameters related to the same patient at the plurality of other medical devices,determine a most recent time stamp in one of the other medical devices,select the pump input parameters corresponding to the most recent time stamp from the other medical device, andlocally store, in the at least one medical fluid pump, the pump input parameters corresponding to the most recent time stamp to perform the renal failure treatment for the patient.
  • 24. The medical device of claim 23, wherein the logic implementer is programmed to synchronize at least one of the pump input parameter or the pump output data with the other medical devices via the distributed database.
  • 25. The medical device of claim 24, wherein the logic implementer is programmed to compare a first corresponding hash sum thereof with a second corresponding hash sum of one of the other medical devices to synchronize at least one of the pump input parameter or the pump output data with that other medical device.
  • 26. The medical device according to claim 23, wherein the logic implementer is programmed to send a hash sum for at least one of the pump input parameter or the pump output data to one of the other medical devices for comparison at the other medical device with a corresponding hash sum of the other medical device.
  • 27. The medical device according to claim 23, wherein the logic implementer is programmed to verify at least one of the pump input parameter or the pump output data.
  • 28. The medical device according to claim 27, wherein the verification includes comparing a newly calculated hash sum with a previously established hash sum for at least one of the pump input parameter or the pump output data.
  • 29. The medical device according to claim 23, wherein the logic implementer is programmed to share at least one of the pump input parameter or the pump output data with at least one selected from the group consisting of a personal communication device, a personal computer, a server computer, and medical equipment via the distributed database.
  • 30. The medical device according to claim 23, wherein the logic implementer is programmed to receive data from at least one selected from the group consisting of a personal communication device, a personal computer, a server computer, and medical equipment via the distributed database.
  • 31. The medical device system according to claim 1, wherein each of the medical devices is configured to: store a first hash sum based on at least one of previous prescription input parameters or previous treatment output data;calculate a second hash sum based on at least one of the prescription input parameters or the treatment output data;generate an error indicative of corrupted data when the first hash sum is different from the second hash sum; andperform a synchronization procedure with at least one other medical device of the distributed database to replace the at least one of the prescription input parameters or the treatment output data with at least one of second prescription input parameters or second treatment output data.
  • 32. The medical device system according to claim 1, further comprising a weight scale configured to weigh each patient prior to and after treatment by one of the plurality of medical devices, wherein the distributed database is configured to support connectivity to the weight scale, andwherein the distributed database is configured for: sending a patient weight to each renal failure therapy machine of the system when each renal failure therapy machine is configured to maintain a record of patient weight; orsending the patient weight to the renal failure therapy machine on which a patient is being treated that day and then sending the patient weight later, after treatment from the renal failure therapy machine, to each renal failure therapy machine of the system; orstoring the patient weight on a data storage device that is taken to the renal failure therapy machine on which a patient is being treated that day and then sending the patient weight later, after treatment from the renal failure therapy machine, to each renal failure therapy machine of the system.
Priority Claims (1)
Number Date Country Kind
1550885-6 Jun 2015 SE national
PCT Information
Filing Document Filing Date Country Kind
PCT/EP2016/064392 6/22/2016 WO
Publishing Document Publishing Date Country Kind
WO2016/207206 12/29/2016 WO A
US Referenced Citations (1753)
Number Name Date Kind
250868 Abbott Dec 1881 A
927476 Barker Jul 1909 A
1505050 Lauritsen Aug 1924 A
2292007 Morgan Aug 1942 A
2529028 Landon Jul 1947 A
2122509 Beliaeff Jul 1948 A
2736332 Simmons Feb 1956 A
3044236 Bearden et al. Jul 1962 A
3074645 Main Jan 1963 A
3095062 Neely Jun 1963 A
3229445 Kraft Jan 1966 A
3287031 Simmons et al. Nov 1966 A
3287885 Sommer Nov 1966 A
3295297 Collins Jan 1967 A
3332737 Krause Jul 1967 A
3342019 Smythe Sep 1967 A
3388803 Scott Jun 1968 A
3412760 Franck Nov 1968 A
3426150 Tygart Feb 1969 A
3463728 Kolobow et al. Aug 1969 A
3485245 Lahr et al. Dec 1969 A
3490479 Mott et al. Jan 1970 A
3527572 Urkiewicz Sep 1970 A
3528550 Cappelen, Jr. Sep 1970 A
3540477 Hogel Nov 1970 A
3545438 De Vries Dec 1970 A
3563381 Edelson et al. Feb 1971 A
3581464 Bhuta et al. Jun 1971 A
3598727 Wilock Aug 1971 A
3608729 Haselden Sep 1971 A
3617545 Dabois et al. Nov 1971 A
3619423 Galletti et al. Nov 1971 A
3667612 Leonard Jun 1972 A
3669878 Marantz et al. Jun 1972 A
3669880 Marantz et al. Jun 1972 A
3677710 Hirsch Jul 1972 A
3682817 Marx Aug 1972 A
3685680 Tenckhoff et al. Aug 1972 A
3697418 Johnson Oct 1972 A
3703959 Raymond Nov 1972 A
3707967 Kitrilakis et al. Jan 1973 A
3727612 Sayers et al. Apr 1973 A
3730183 Goldsmith et al. May 1973 A
3739943 Williamsen et al. Jun 1973 A
3742938 Stern Jul 1973 A
3744492 Leibinsohn Jul 1973 A
3744636 Commarmot Jul 1973 A
3756234 Kopp Sep 1973 A
3756752 Stenner Sep 1973 A
3769207 Baer Oct 1973 A
3771288 Wisman et al. Nov 1973 A
3774762 Lichtenstein Nov 1973 A
3786190 Pori Jan 1974 A
3795088 Esmond Mar 1974 A
3799873 Brown Mar 1974 A
3809241 Alvine May 1974 A
3809871 Howard et al. May 1974 A
3810102 Parks, III et al. May 1974 A
3814249 Eaton Jun 1974 A
3825493 Brown et al. Jul 1974 A
3827561 Serfass et al. Aug 1974 A
3827975 Bizot et al. Aug 1974 A
3830234 Kopp Aug 1974 A
3834386 Sisley Sep 1974 A
3848112 Weichselbaum et al. Nov 1974 A
3849071 Kayser Nov 1974 A
3850835 Marantz et al. Nov 1974 A
3858574 Page Jan 1975 A
3878095 Frasier et al. Apr 1975 A
3878564 Yao et al. Apr 1975 A
3884808 Scott May 1975 A
3908653 Kettering Sep 1975 A
3910257 Fletcher et al. Oct 1975 A
3910260 Sarnoff et al. Oct 1975 A
3911915 Seifter et al. Oct 1975 A
3915802 Kominek Oct 1975 A
3921196 Patterson Nov 1975 A
3926797 Gigou et al. Dec 1975 A
3939069 Granger et al. Feb 1976 A
3946731 Lichtenstein Mar 1976 A
3964479 Boag et al. Jun 1976 A
3971000 Cromwell Jul 1976 A
3976311 Spendlove Aug 1976 A
3979284 Granger et al. Sep 1976 A
3985134 Lissot et al. Oct 1976 A
3989622 Marantz et al. Nov 1976 A
3996027 Schnell et al. Dec 1976 A
3998103 Bjorklund et al. Dec 1976 A
4000072 Sato et al. Dec 1976 A
4031010 Nose Jun 1977 A
4031891 Jess Jun 1977 A
4032908 Rice et al. Jun 1977 A
4036747 Hori et al. Jul 1977 A
4038190 Baudet et al. Jul 1977 A
4047563 Kurata Sep 1977 A
4048995 Mittleman Sep 1977 A
4054522 Pinkerton Oct 1977 A
4060485 Eaton Nov 1977 A
4061031 Grimsrud Dec 1977 A
4067803 Quentin Jan 1978 A
4078562 Friedman Mar 1978 A
4081372 Atkin et al. Mar 1978 A
4102655 Jeffery et al. Jul 1978 A
4115259 Bigi Sep 1978 A
4118314 Yoshida Oct 1978 A
4137160 Ebling et al. Jan 1979 A
4144496 Cunningham et al. Mar 1979 A
4149860 Kulik Apr 1979 A
4151088 Wolf, Jr. et al. Apr 1979 A
4151407 McBride et al. Apr 1979 A
4156867 Bench et al. May 1979 A
4164320 Irazoqui et al. Aug 1979 A
4173537 Newhart et al. Nov 1979 A
4173971 Karz Nov 1979 A
4180460 Calari Dec 1979 A
4181245 Garrett et al. Jan 1980 A
4190047 Jacobsen et al. Feb 1980 A
4191182 Popovich et al. Mar 1980 A
4191646 Larsson et al. Mar 1980 A
4192748 Hyden Mar 1980 A
4194536 Stine et al. Mar 1980 A
4199307 Jassawalla Apr 1980 A
4200095 Reti Apr 1980 A
4209402 Gentles Jun 1980 A
4212738 Henne Jul 1980 A
4213859 Smakman et al. Jul 1980 A
4229299 Savitz et al. Oct 1980 A
4240408 Schael Dec 1980 A
4244816 Vogler et al. Jan 1981 A
4247393 Wallace Jan 1981 A
4256718 McArthur et al. Mar 1981 A
4263647 Merrell et al. Apr 1981 A
4267040 Schal May 1981 A
4267047 Henne et al. May 1981 A
4269708 Bounomini et al. May 1981 A
4270532 Franetzki et al. Jun 1981 A
4273121 Jassawalla Jun 1981 A
4276175 Bower Jun 1981 A
4282872 Franetzki et al. Aug 1981 A
4293413 Schnell Oct 1981 A
4293762 Ogawa Oct 1981 A
4303376 Siekmann Dec 1981 A
4303521 Lehmann Dec 1981 A
4304670 Watanabe et al. Dec 1981 A
4308866 Jelliffe et al. Jan 1982 A
4311137 Gerard Jan 1982 A
4313831 Lehmann et al. Feb 1982 A
4319338 Grudowski et al. Mar 1982 A
4320757 Whitney et al. Mar 1982 A
4325715 Bowman et al. Apr 1982 A
4332264 Gortz et al. Jun 1982 A
4338190 Kraus et al. Jul 1982 A
4344777 Siposs Aug 1982 A
4345919 Wilkinson et al. Aug 1982 A
4345999 Sigdell et al. Aug 1982 A
4348280 George et al. Sep 1982 A
4353368 Slovak et al. Oct 1982 A
4354252 Lamb et al. Oct 1982 A
4360323 Anderson Nov 1982 A
4360507 McArthur et al. Nov 1982 A
4363641 Finn, III Dec 1982 A
4364747 Blackshear et al. Dec 1982 A
4368118 Siposs Jan 1983 A
4369780 Sakai Jan 1983 A
4370983 Lichtenstein Feb 1983 A
4373527 Fischell Feb 1983 A
4381003 Buoncristiani Apr 1983 A
4381776 Latham, Jr. May 1983 A
4385630 Gilcher et al. May 1983 A
4386634 Stasz et al. Jun 1983 A
4398289 Schoute Aug 1983 A
4398908 Siposs Aug 1983 A
4416654 Schoendorfer et al. Nov 1983 A
4425114 Schoendorfer et al. Jan 1984 A
4427009 Wells et al. Jan 1984 A
4428381 Hepp Jan 1984 A
4433971 Lindsay et al. Feb 1984 A
4443216 Chappell Apr 1984 A
4445174 Fletcher Apr 1984 A
4447224 DeCant, Jr. et al. May 1984 A
4449538 Corbitt et al. May 1984 A
4451255 Bujan et al. May 1984 A
4457750 Hill Jul 1984 A
4458693 Badzinski et al. Jul 1984 A
4460358 Somerville et al. Jul 1984 A
4460555 Thompson Jul 1984 A
4464172 Lichtenstein Aug 1984 A
4464563 Jewett Aug 1984 A
4469481 Kobayashi Sep 1984 A
4473449 Michaels et al. Sep 1984 A
4475901 Kraegen et al. Oct 1984 A
4476381 Rubin Oct 1984 A
4477342 Allan et al. Oct 1984 A
4480751 Lueptow Nov 1984 A
4481670 Freeburg Nov 1984 A
4487604 Iwatschenko et al. Dec 1984 A
4490798 Franks et al. Dec 1984 A
4493705 Gordon et al. Jan 1985 A
4496351 Hillel et al. Jan 1985 A
4498900 Buoncristiani Feb 1985 A
4511352 Theeuwes et al. Apr 1985 A
4512163 Wells et al. Apr 1985 A
4525861 Freeburg Jun 1985 A
4529401 Leslie et al. Jul 1985 A
4531527 Reinhold, Jr. et al. Jul 1985 A
4531937 Yates Jul 1985 A
4532414 Shah et al. Jul 1985 A
4538138 Harvey et al. Aug 1985 A
4542015 Smakman et al. Sep 1985 A
4545071 Freeburg Oct 1985 A
4551133 Zegers de Beyl et al. Nov 1985 A
4559038 Berg et al. Dec 1985 A
4560472 Granzow et al. Dec 1985 A
4560979 Rosskopf Dec 1985 A
4561443 Hogrefe et al. Dec 1985 A
4562751 Nason Jan 1986 A
4568333 Sawyer et al. Feb 1986 A
4574283 Arakawa et al. Mar 1986 A
4581141 Ash Apr 1986 A
4583981 Urquhart et al. Apr 1986 A
4586920 Peabody May 1986 A
4586925 Carlsson et al. May 1986 A
4590473 Burke et al. May 1986 A
4602249 Abbott Jul 1986 A
4618343 Polaschegg Oct 1986 A
4619653 Fischell Oct 1986 A
4622032 Katsura et al. Nov 1986 A
4622979 Katchis et al. Nov 1986 A
4624661 Arimond Nov 1986 A
RE32303 Lasker et al. Dec 1986 E
4636950 Caswell et al. Jan 1987 A
4637817 Archibald et al. Jan 1987 A
4643713 Viitala Feb 1987 A
4643715 Isono et al. Feb 1987 A
4650458 Dahlberg et al. Mar 1987 A
4650464 Ruiz et al. Mar 1987 A
4650469 Berg et al. Mar 1987 A
4650857 May Mar 1987 A
4652262 Veracchi Mar 1987 A
4655941 Suzuki Apr 1987 A
4657490 Abbott Apr 1987 A
4661246 Ash Apr 1987 A
4664891 Cosentino et al. May 1987 A
4666598 Heath et al. May 1987 A
4670007 Wheeldon et al. Jun 1987 A
4676776 Howson Jun 1987 A
4678460 Rosner Jul 1987 A
4680445 Ogawa Jul 1987 A
4681563 Deckert et al. Jul 1987 A
4681606 Swan, Jr. et al. Jul 1987 A
4684460 Issautier Aug 1987 A
4688167 Agarwal Aug 1987 A
4691580 Fosslien Sep 1987 A
4695944 Zandveld et al. Sep 1987 A
4695954 Rose et al. Sep 1987 A
4696671 Epstein et al. Sep 1987 A
4697928 Csongor Oct 1987 A
4702595 Mutschler et al. Oct 1987 A
4702829 Polaschegg et al. Oct 1987 A
4703913 Hunkapiller Nov 1987 A
4705506 Archibald Nov 1987 A
4707778 Yamada et al. Nov 1987 A
4708802 Rath et al. Nov 1987 A
4714462 DiComenico Dec 1987 A
4717042 McLaughlin Jan 1988 A
4718576 Tamura et al. Jan 1988 A
4718890 Peabody Jan 1988 A
4722224 Scheller et al. Feb 1988 A
4722349 Baumberg Feb 1988 A
4722725 Sawyer et al. Feb 1988 A
4722731 Vailancourt Feb 1988 A
4722734 Kolln Feb 1988 A
4725694 Auer et al. Feb 1988 A
4730849 Siegel Mar 1988 A
4731058 Doan Mar 1988 A
4731731 Cochran Mar 1988 A
4732411 Siegel Mar 1988 A
4734198 Harm et al. Mar 1988 A
4734269 Clarke et al. Mar 1988 A
4735609 Comeau et al. Apr 1988 A
4741732 Crankshaw et al. May 1988 A
4741736 Brown May 1988 A
4747822 Peabody May 1988 A
4756706 Kerns et al. Jul 1988 A
4759756 Forman et al. Jul 1988 A
4765907 Scott Aug 1988 A
4767399 Bollish Aug 1988 A
4769151 Shouldice Sep 1988 A
4778449 Weber et al. Oct 1988 A
4778451 Kamen Oct 1988 A
4779626 Peel et al. Oct 1988 A
4784645 Fischell Nov 1988 A
4785799 Schoon et al. Nov 1988 A
4785969 McLaughlin Nov 1988 A
4796634 Huntsman et al. Jan 1989 A
4796644 Polaschegg Jan 1989 A
4797840 Fraden Jan 1989 A
4803625 Fu et al. Feb 1989 A
4804474 Blum Feb 1989 A
4806135 Siposs Feb 1989 A
4810090 Boucher Mar 1989 A
4810243 Howson Mar 1989 A
4811844 Moulding, Jr. et al. Mar 1989 A
4816208 Woods et al. Mar 1989 A
4817044 Ogren Mar 1989 A
4823256 Bishop et al. Apr 1989 A
4828543 Weiss et al. May 1989 A
4828545 Epstein et al. May 1989 A
4830018 Treach May 1989 A
4831562 McIntosh et al. May 1989 A
4832033 Maher et al. May 1989 A
4835372 Beard et al. May 1989 A
4835521 Andrejasich et al. May 1989 A
4838275 Lee Jun 1989 A
4838865 Flank et al. Jun 1989 A
4839806 Goldfischer et al. Jun 1989 A
4844074 Kurucz Jul 1989 A
4845644 Anthias et al. Jul 1989 A
4847470 Bakke Jul 1989 A
4847764 Halvorson Jul 1989 A
4850009 Zook et al. Jul 1989 A
4850972 Schulman et al. Jul 1989 A
4853521 Claeys et al. Aug 1989 A
4854324 Hirschman et al. Aug 1989 A
4857713 Brown Aug 1989 A
4857716 Gombrich et al. Aug 1989 A
4865584 Epstein et al. Sep 1989 A
4871351 Feingold Oct 1989 A
4878175 Norden-Paul et al. Oct 1989 A
4889132 Hutcheson et al. Dec 1989 A
4889134 Greenwold et al. Dec 1989 A
4893270 Beck et al. Jan 1990 A
4897777 Janke et al. Jan 1990 A
4897784 Nay Jan 1990 A
4898576 Philip Feb 1990 A
4898578 Rubalcaba, Jr. Feb 1990 A
4901728 Hutchison Feb 1990 A
4906816 van Leerdam Mar 1990 A
4908017 Howson et al. Mar 1990 A
4912623 Rantala et al. Mar 1990 A
4916441 Gombrich et al. Apr 1990 A
4922922 Pollock et al. May 1990 A
4923612 Trivett et al. May 1990 A
4925444 Orkin et al. May 1990 A
4932987 Molina Jun 1990 A
4933843 Scheller et al. Jun 1990 A
4937777 Flood et al. Jun 1990 A
4941808 Qureshi et al. Jul 1990 A
4941875 Brennan Jul 1990 A
4943279 Samiotes et al. Jul 1990 A
4946439 Eggers Aug 1990 A
4949274 Hollander et al. Aug 1990 A
4950259 Geary et al. Aug 1990 A
4952928 Carroll et al. Aug 1990 A
4953074 Kametani et al. Aug 1990 A
4955508 Capanna et al. Sep 1990 A
D311061 Vrana et al. Oct 1990 S
4960230 Marelli Oct 1990 A
4966579 Polaschegg Oct 1990 A
4967928 Carter Nov 1990 A
4968295 Neumann Nov 1990 A
4976683 Gauthier et al. Dec 1990 A
4976685 Block, Jr. Dec 1990 A
4977590 Milovancevic Dec 1990 A
4978335 Arthur Dec 1990 A
4990258 Bjare et al. Feb 1991 A
4991091 Allen Feb 1991 A
4992926 Janke et al. Feb 1991 A
4993068 Piosenka et al. Feb 1991 A
4997464 Kopf Mar 1991 A
4998249 Bennett et al. Mar 1991 A
5002055 Merki et al. Mar 1991 A
5002471 Perlov Mar 1991 A
5003296 Lee Mar 1991 A
5004459 Peabody et al. Apr 1991 A
5006699 Felkner et al. Apr 1991 A
5007429 Treatch et al. Apr 1991 A
5011607 Shinzato Apr 1991 A
5012402 Akiyama Apr 1991 A
5012411 Policastro et al. Apr 1991 A
5014875 McLaughlin et al. May 1991 A
5016172 Dessertine May 1991 A
5023770 Siverling Jun 1991 A
5025374 Roizen et al. Jun 1991 A
5032265 Jha et al. Jul 1991 A
5036852 Leishman Aug 1991 A
5038800 Oba Aug 1991 A
5041086 Koenig et al. Aug 1991 A
5045048 Kaleskas et al. Sep 1991 A
5047147 Chevallet et al. Sep 1991 A
5047959 Phillips et al. Sep 1991 A
5049492 Sauer et al. Sep 1991 A
5053031 Borsanyi Oct 1991 A
5053684 Nooyan Oct 1991 A
5053990 Kreifels et al. Oct 1991 A
5055001 Natwick et al. Oct 1991 A
5057076 Polaschegg Oct 1991 A
5059173 Sacco Oct 1991 A
5061236 Sutherland et al. Oct 1991 A
5061243 Winchell et al. Oct 1991 A
5061365 Utterberg Oct 1991 A
5062774 Kramer et al. Nov 1991 A
5072356 Watt et al. Dec 1991 A
5072383 Brimm et al. Dec 1991 A
5072412 Henderson, Jr. et al. Dec 1991 A
5073167 Carr et al. Dec 1991 A
5078683 Sancoff et al. Jan 1992 A
5084828 Kaufman et al. Jan 1992 A
5087245 Doan Feb 1992 A
5088515 Kamen Feb 1992 A
5088904 Okada Feb 1992 A
5088981 Howson et al. Feb 1992 A
5088990 Hivale et al. Feb 1992 A
5091094 Veech Feb 1992 A
5096385 Georgi et al. Mar 1992 A
5098377 Borsanyi et al. Mar 1992 A
5100380 Adaniya et al. Mar 1992 A
5104374 Bishko et al. Apr 1992 A
5108363 Tuttle et al. Apr 1992 A
5108367 Epstein et al. Apr 1992 A
5108372 Swenson Apr 1992 A
5109487 Ohgomori et al. Apr 1992 A
5109849 Goodman et al. May 1992 A
5112319 Lai May 1992 A
5112480 Hukasawa May 1992 A
5114580 Ahmad et al. May 1992 A
5116203 Natwick et al. May 1992 A
5116312 Blankenship et al. May 1992 A
5120303 Hombrouckx Jun 1992 A
5122516 Watanabe et al. Jun 1992 A
5125069 O'Boyle Jun 1992 A
5131092 Sackmann et al. Jul 1992 A
5134574 Beaverstock et al. Jul 1992 A
5135500 Zdeb Aug 1992 A
5137023 Mendelson et al. Aug 1992 A
5141492 Dadson et al. Aug 1992 A
5141493 Jacobsen et al. Aug 1992 A
5151978 Bronikowski et al. Sep 1992 A
5152296 Simons Oct 1992 A
5153416 Neeley Oct 1992 A
5153827 Coutre et al. Oct 1992 A
5155693 Altmayer et al. Oct 1992 A
5157595 Lovrenich Oct 1992 A
5158091 Butterfield et al. Oct 1992 A
5159673 Sackmann et al. Oct 1992 A
5160320 Yum et al. Nov 1992 A
5161211 Taguchi et al. Nov 1992 A
5167235 Seacord et al. Dec 1992 A
5167921 Gordon Dec 1992 A
5172698 Stanko Dec 1992 A
5173125 Felding Dec 1992 A
5176004 Gaudet Jan 1993 A
5178763 Delaunay Jan 1993 A
5179569 Sawyer Jan 1993 A
5179700 Aihara et al. Jan 1993 A
5180896 Gibby et al. Jan 1993 A
5181910 Scanlon Jan 1993 A
5186609 Inoue et al. Feb 1993 A
5190185 Blechl Mar 1993 A
5190522 Wojcicki et al. Mar 1993 A
5191891 Righter Mar 1993 A
5204000 Steadman et al. Apr 1993 A
5208907 Shelton et al. May 1993 A
5211849 Kitaevich et al. May 1993 A
5213099 Tripp, Jr. May 1993 A
5213232 Kraft et al. May 1993 A
5213568 Lattin et al. May 1993 A
5219330 Bollish et al. Jun 1993 A
5219331 Vanderveen Jun 1993 A
5221267 Folden Jun 1993 A
5225974 Mathews et al. Jul 1993 A
5226425 Righter Jul 1993 A
5228450 Sellers Jul 1993 A
5228889 Cortial et al. Jul 1993 A
5231990 Gauglitz Aug 1993 A
5234404 Tuttle et al. Aug 1993 A
5235510 Yamada et al. Aug 1993 A
5236416 McDaniel et al. Aug 1993 A
5236476 Klick Aug 1993 A
5238001 Gallant et al. Aug 1993 A
5240007 Pytel et al. Aug 1993 A
5244463 Cordner, Jr. et al. Sep 1993 A
5245693 Ford et al. Sep 1993 A
5245704 Weber et al. Sep 1993 A
5246560 Nekoksa et al. Sep 1993 A
5254096 Rondelet et al. Oct 1993 A
5256156 Kern et al. Oct 1993 A
5256157 Samiotes et al. Oct 1993 A
5256371 Pippert Oct 1993 A
5259954 Taylor Nov 1993 A
5259961 Eigendorf Nov 1993 A
5265010 Evans-Paganelli et al. Nov 1993 A
5265431 Gaudet et al. Nov 1993 A
5267174 Kaufman et al. Nov 1993 A
5268077 Bubik et al. Dec 1993 A
5271405 Boyer et al. Dec 1993 A
5272318 Gorman Dec 1993 A
5272321 Otsuka et al. Dec 1993 A
5273517 Barone et al. Dec 1993 A
5274434 Morioka et al. Dec 1993 A
5276611 Ghiraldi Jan 1994 A
5277188 Selker Jan 1994 A
5277820 Ash Jan 1994 A
5283861 Dangler et al. Feb 1994 A
5284150 Butterfield et al. Feb 1994 A
5284470 Beltz Feb 1994 A
5286252 Tuttle et al. Feb 1994 A
5292029 Pearson Mar 1994 A
5295505 Polaschegg et al. Mar 1994 A
5297257 Struger et al. Mar 1994 A
5298021 Sherer Mar 1994 A
5304126 Epstein et al. Apr 1994 A
5307263 Brown Apr 1994 A
5307372 Sawyer et al. Apr 1994 A
5307463 Hyatt et al. Apr 1994 A
5311908 Barone et al. May 1994 A
5314243 McDonald et al. May 1994 A
5315505 Pratt et al. May 1994 A
5317506 Coutre et al. May 1994 A
5318750 Lascombes Jun 1994 A
5319363 Welch et al. Jun 1994 A
5319543 Wilhelm Jun 1994 A
5321618 Gessman Jun 1994 A
5321829 Zifferer Jun 1994 A
5325478 Shelton et al. Jun 1994 A
5326473 Lascombes et al. Jul 1994 A
5326476 Grogan et al. Jul 1994 A
5327341 Whalen et al. Jul 1994 A
5330420 Lee Jul 1994 A
5331549 Crawford, Jr. Jul 1994 A
5336165 Twardowski Aug 1994 A
5336173 Folden Aug 1994 A
5336245 Adams et al. Aug 1994 A
5337230 Baumgartner et al. Aug 1994 A
5338157 Blomquist Aug 1994 A
5338293 Jeppsson et al. Aug 1994 A
5339821 Fujimoto Aug 1994 A
5341291 Roizen et al. Aug 1994 A
5341412 Ramot et al. Aug 1994 A
D350822 Lanigan Sep 1994 S
D350823 Lanigan Sep 1994 S
5348008 Bornn et al. Sep 1994 A
5348539 Herskowitz Sep 1994 A
5349675 Fitzgerald et al. Sep 1994 A
5350357 Kamen et al. Sep 1994 A
5356376 Milijasevic et al. Oct 1994 A
5356378 Doan Oct 1994 A
5358481 Todd et al. Oct 1994 A
5361202 Doue Nov 1994 A
5361758 Hall et al. Nov 1994 A
5366630 Chevallet Nov 1994 A
5366896 Margrey et al. Nov 1994 A
5366904 Qureshi et al. Nov 1994 A
5367555 Isoyama Nov 1994 A
5368555 Sussman et al. Nov 1994 A
5368562 Blomquist et al. Nov 1994 A
5370612 Maeda et al. Dec 1994 A
5370674 Farrell Dec 1994 A
5371687 Holmes, II et al. Dec 1994 A
5374251 Smith Dec 1994 A
5374813 Shipp Dec 1994 A
5374965 Kanno Dec 1994 A
5375604 Kelly et al. Dec 1994 A
5376070 Colman et al. Dec 1994 A
5376263 Fischel Dec 1994 A
5377864 Blechl et al. Jan 1995 A
5378231 Johnson et al. Jan 1995 A
5379214 Arbuckle et al. Jan 1995 A
5381510 Ford et al. Jan 1995 A
5385564 Slater et al. Jan 1995 A
5389078 Zalesky et al. Feb 1995 A
5390238 Kirk et al. Feb 1995 A
5392951 Gardner et al. Feb 1995 A
5394732 Johnson et al. Mar 1995 A
5395320 Padda et al. Mar 1995 A
5395321 Kawahara et al. Mar 1995 A
5398336 Tantry et al. Mar 1995 A
5401059 Ferrario Mar 1995 A
5401342 Vincent et al. Mar 1995 A
D357312 Riquier et al. Apr 1995 S
5404292 Hendrickson Apr 1995 A
5404384 Colburn et al. Apr 1995 A
5406473 Yoshikura et al. Apr 1995 A
5408576 Bishop Apr 1995 A
5411472 Steg, Jr. et al. May 1995 A
5411705 Thor et al. May 1995 A
5412715 Volpe May 1995 A
5415167 Wilk May 1995 A
5416695 Miller et al. May 1995 A
5417222 Dempsey et al. May 1995 A
5420962 Bakke May 1995 A
5420977 Sztipanovits et al. May 1995 A
5421343 Feng Jun 1995 A
5421815 Noguchi et al. Jun 1995 A
5423746 Burkett et al. Jun 1995 A
5429595 Wright, Jr. et al. Jul 1995 A
5429602 Hauser Jul 1995 A
5431299 Brewer et al. Jul 1995 A
5431627 Pastrone et al. Jul 1995 A
5433736 Nilsson Jul 1995 A
5438510 Bryant et al. Aug 1995 A
5438607 Przygoda, Jr. et al. Aug 1995 A
5440699 Farrand et al. Aug 1995 A
5441047 David et al. Aug 1995 A
5441636 Chevallet et al. Aug 1995 A
5445294 Gardner et al. Aug 1995 A
5445610 Evert Aug 1995 A
5445621 Poli et al. Aug 1995 A
5446868 Gardea, II et al. Aug 1995 A
5453098 Botts et al. Sep 1995 A
5455851 Chaco et al. Oct 1995 A
5458123 Unger Oct 1995 A
5460294 Williams Oct 1995 A
5460605 Tuttle et al. Oct 1995 A
5461665 Shur et al. Oct 1995 A
5462051 Oka et al. Oct 1995 A
5464392 Epstein et al. Nov 1995 A
5465286 Clare et al. Nov 1995 A
5467773 Bergelson et al. Nov 1995 A
5468110 McDonald et al. Nov 1995 A
5468388 Goddard et al. Nov 1995 A
5469855 Pompei et al. Nov 1995 A
5470483 Bene et al. Nov 1995 A
5471382 Tallman et al. Nov 1995 A
5472614 Rossi Dec 1995 A
5474552 Palti Dec 1995 A
5474683 Bryant et al. Dec 1995 A
5482043 Zulauf Jan 1996 A
5482446 Williamson et al. Jan 1996 A
5484397 Twardowski Jan 1996 A
5485408 Blomquist Jan 1996 A
5487827 Peterson et al. Jan 1996 A
5489385 Raabe et al. Feb 1996 A
5490610 Pearson Feb 1996 A
5490925 Eigendorf Feb 1996 A
5494592 Latham, Jr. et al. Feb 1996 A
5496265 Langley et al. Mar 1996 A
5496273 Pastrone et al. Mar 1996 A
5498338 Kruger et al. Mar 1996 A
5502944 Kraft et al. Apr 1996 A
5503801 Brugger Apr 1996 A
5507412 Ebert et al. Apr 1996 A
5508912 Schneiderman Apr 1996 A
5509422 Fukami Apr 1996 A
5509895 Noguchi et al. Apr 1996 A
5513957 O'Leary May 1996 A
5514088 Zakko May 1996 A
5514095 Brightbill et al. May 1996 A
5515426 Yacenda et al. May 1996 A
5520450 Colson, Jr. et al. May 1996 A
5520637 Pager et al. May 1996 A
5520640 Utterberg May 1996 A
5522396 Langer et al. Jun 1996 A
5522798 Johnson et al. Jun 1996 A
5522998 Polaschegg Jun 1996 A
5526428 Arnold Jun 1996 A
5528503 Moore et al. Jun 1996 A
5529063 Hill Jun 1996 A
5531680 Dumas et al. Jul 1996 A
5531697 Olsen et al. Jul 1996 A
5531698 Olsen Jul 1996 A
5533079 Colburn et al. Jul 1996 A
5533981 Mandro et al. Jul 1996 A
5534691 Holdaway et al. Jul 1996 A
5536084 Curtis et al. Jul 1996 A
5537313 Pirelli Jul 1996 A
5537853 Finburgh et al. Jul 1996 A
5540808 Vincent et al. Jul 1996 A
5540842 Aoyama et al. Jul 1996 A
5542420 Goldman et al. Aug 1996 A
5542919 Simon et al. Aug 1996 A
5544649 David et al. Aug 1996 A
5544651 Wilk Aug 1996 A
5544661 Davis et al. Aug 1996 A
5545131 Davankov Aug 1996 A
5545140 Conero et al. Aug 1996 A
5546580 Seliger et al. Aug 1996 A
5547470 Johnson et al. Aug 1996 A
5549117 Tacklind et al. Aug 1996 A
5549460 O'Leary Aug 1996 A
5553609 Chen et al. Sep 1996 A
5558638 Evers et al. Sep 1996 A
5558640 Pfeiler et al. Sep 1996 A
5560352 Heim et al. Oct 1996 A
5562232 Pearson Oct 1996 A
5562621 Claude et al. Oct 1996 A
5563347 Martin et al. Oct 1996 A
5564803 McDonald et al. Oct 1996 A
5568912 Minami et al. Oct 1996 A
5569186 Lord et al. Oct 1996 A
5569187 Kaiser Oct 1996 A
5570026 Buffaloe, IV et al. Oct 1996 A
5571258 Pearson Nov 1996 A
5573502 LeCocq et al. Nov 1996 A
5573506 Vasko Nov 1996 A
5575632 Morris et al. Nov 1996 A
5576952 Stutman et al. Nov 1996 A
5578070 Utterberg Nov 1996 A
5579001 Dempsey et al. Nov 1996 A
5579378 Arlinghaus, Jr. Nov 1996 A
5581369 Righter et al. Dec 1996 A
5581687 Lyle et al. Dec 1996 A
5582593 Hultman Dec 1996 A
5583758 McIlroy et al. Dec 1996 A
5588815 Zaleski, II Dec 1996 A
5588816 Abbott et al. Dec 1996 A
5589932 Garcia-Rubio et al. Dec 1996 A
5590648 Mitchell et al. Jan 1997 A
5591251 Brugger Jan 1997 A
5591344 Kenley et al. Jan 1997 A
5593267 McDonald et al. Jan 1997 A
5594637 Eisenberg et al. Jan 1997 A
5594786 Chaco et al. Jan 1997 A
5597995 Williams et al. Jan 1997 A
5598536 Slaughter, III et al. Jan 1997 A
5601445 Schipper et al. Feb 1997 A
5605540 Utterberg Feb 1997 A
5609572 Lang Mar 1997 A
5609575 Larson et al. Mar 1997 A
5609576 Voss et al. Mar 1997 A
5609770 Zimmerman et al. Mar 1997 A
5613115 Gihl et al. Mar 1997 A
5614677 Wamsiedler et al. Mar 1997 A
5616248 Schal Apr 1997 A
5618441 Rosa et al. Apr 1997 A
5619428 Lee et al. Apr 1997 A
5619991 Sloane Apr 1997 A
5620608 Rosa et al. Apr 1997 A
5623652 Vora et al. Apr 1997 A
5623925 Swenson et al. Apr 1997 A
5626144 Tacklind et al. May 1997 A
5628619 Wilson May 1997 A
5628908 Kamen May 1997 A
5629871 Love et al. May 1997 A
5630710 Tune et al. May 1997 A
5631844 Margrey et al. May 1997 A
5633910 Cohen May 1997 A
D380260 Hyman Jun 1997 S
5634893 Rishton Jun 1997 A
5637081 Noguchi et al. Jun 1997 A
5637082 Pages et al. Jun 1997 A
5637093 Hyman et al. Jun 1997 A
5640301 Roecher et al. Jun 1997 A
5640953 Bishop et al. Jun 1997 A
5640995 Packard et al. Jun 1997 A
5641405 Keshaviah et al. Jun 1997 A
5641628 Bianchi Jun 1997 A
5643193 Papillon et al. Jul 1997 A
5643201 Peabody et al. Jul 1997 A
5643212 Coutre et al. Jul 1997 A
5643250 Utterberg Jul 1997 A
5645734 Kenley et al. Jul 1997 A
5647853 Feldmann et al. Jul 1997 A
5647854 Olsen et al. Jul 1997 A
5650071 Brugger et al. Jul 1997 A
5651775 Walker et al. Jul 1997 A
5652566 Lambert Jul 1997 A
5658240 Urdahl et al. Aug 1997 A
5658250 Blomquist et al. Aug 1997 A
5658456 Kenley et al. Aug 1997 A
5661978 Holmes et al. Sep 1997 A
5664270 Bell et al. Sep 1997 A
5666404 Ciccotelli et al. Sep 1997 A
5674199 Brugger Oct 1997 A
5678562 Sellers Oct 1997 A
5678568 Uchikubo et al. Oct 1997 A
5681285 Ford et al. Oct 1997 A
5681294 Osborne et al. Oct 1997 A
5682526 Smokoff et al. Oct 1997 A
5683355 Fini et al. Nov 1997 A
5683367 Jordan et al. Nov 1997 A
5683381 Carr et al. Nov 1997 A
5685844 Marttila Nov 1997 A
5685988 Malchesky Nov 1997 A
5685989 Krivitski et al. Nov 1997 A
5687717 Halpern Nov 1997 A
5687734 Dempsey et al. Nov 1997 A
5690614 Carr et al. Nov 1997 A
5690831 Kenley et al. Nov 1997 A
5695473 Olsen Dec 1997 A
5697951 Harpstead Dec 1997 A
5700998 Palti Dec 1997 A
5701894 Cherry et al. Dec 1997 A
5702597 Chevallet et al. Dec 1997 A
5702606 Peter, Jr. et al. Dec 1997 A
5704351 Mortara et al. Jan 1998 A
5704364 Saltzstein et al. Jan 1998 A
5704366 Tacklind et al. Jan 1998 A
5712798 Langley et al. Jan 1998 A
5712912 Tomko et al. Jan 1998 A
5713485 Liff et al. Feb 1998 A
5713856 Eggers et al. Feb 1998 A
5715823 Wood et al. Feb 1998 A
5716114 Holmes et al. Feb 1998 A
5716194 Butterfield et al. Feb 1998 A
5718562 Lawless et al. Feb 1998 A
5719761 Gatti et al. Feb 1998 A
RE35743 Pearson Mar 1998 E
5722947 Jeppsson et al. Mar 1998 A
5724025 Tavori Mar 1998 A
5724478 Thweatt Mar 1998 A
5724580 Levin et al. Mar 1998 A
5725511 Urrutia Mar 1998 A
5725776 Kenley et al. Mar 1998 A
5729653 Magliochetti et al. Mar 1998 A
5730712 Falkvall et al. Mar 1998 A
5730730 Darling, Jr. Mar 1998 A
5732709 Tacklind et al. Mar 1998 A
5733259 Valcke et al. Mar 1998 A
5735887 Barreras, Sr. et al. Apr 1998 A
5737539 Edelson et al. Apr 1998 A
5740185 Bosse Apr 1998 A
5740800 Hendrickson et al. Apr 1998 A
5744042 Stange et al. Apr 1998 A
5745366 Higham et al. Apr 1998 A
5745378 Barker et al. Apr 1998 A
5752917 Fuchs May 1998 A
5752976 Duffin et al. May 1998 A
5755563 Clegg et al. May 1998 A
5759044 Redmond Jun 1998 A
5762782 Kenley et al. Jun 1998 A
5763266 Palsson et al. Jun 1998 A
5764923 Tallman et al. Jun 1998 A
5766155 Hyman et al. Jun 1998 A
5769811 Stacey et al. Jun 1998 A
5771657 Lasher et al. Jun 1998 A
5772585 Lavin et al. Jun 1998 A
5772586 Heinonen et al. Jun 1998 A
5772635 Dastur et al. Jun 1998 A
5772637 Heinzmann et al. Jun 1998 A
5776057 Swenson et al. Jul 1998 A
5776091 Brugger et al. Jul 1998 A
5776345 Truitt et al. Jul 1998 A
5778345 McCartney Jul 1998 A
5778882 Raymond et al. Jul 1998 A
5781442 Chamberlain et al. Jul 1998 A
5782575 Vincent et al. Jul 1998 A
5782805 Meinzer et al. Jul 1998 A
5782878 Morgan et al. Jul 1998 A
5784547 Dittmar et al. Jul 1998 A
5785650 Akasaka et al. Jul 1998 A
5788669 Peterson Aug 1998 A
5788851 Kenley et al. Aug 1998 A
5790409 Fedor et al. Aug 1998 A
5790752 Anglin et al. Aug 1998 A
5791342 Woodard Aug 1998 A
5791880 Wilson Aug 1998 A
5793861 Haigh Aug 1998 A
5793969 Kamentsky et al. Aug 1998 A
5795317 Brierton et al. Aug 1998 A
5795327 Wilson et al. Aug 1998 A
5797515 Liff et al. Aug 1998 A
5800387 Duffy et al. Sep 1998 A
5803906 Pratt et al. Sep 1998 A
5805442 Crater et al. Sep 1998 A
5805456 Higham et al. Sep 1998 A
5805505 Zheng et al. Sep 1998 A
5807321 Stoker et al. Sep 1998 A
5807322 Lindsey et al. Sep 1998 A
5807336 Chen et al. Sep 1998 A
5810747 Brudny et al. Sep 1998 A
5814015 Cowen et al. Sep 1998 A
5815566 Ramot et al. Sep 1998 A
5816779 Lawless et al. Oct 1998 A
5822418 Yacenda et al. Oct 1998 A
5822544 Chaco et al. Oct 1998 A
5823949 Goltra Oct 1998 A
5826237 Macrae et al. Oct 1998 A
5829438 Gibbs et al. Nov 1998 A
5830185 Block, Jr. Nov 1998 A
5832448 Brown Nov 1998 A
5832450 Myers et al. Nov 1998 A
5833599 Schrier et al. Nov 1998 A
5836908 Beden et al. Nov 1998 A
5841975 Layne et al. Nov 1998 A
5842841 Danby et al. Dec 1998 A
5842976 Williamson Dec 1998 A
5845253 Rensimer et al. Dec 1998 A
5846419 Nederlof Dec 1998 A
5848593 McGrady et al. Dec 1998 A
5849065 Wojke Dec 1998 A
5851186 Wood et al. Dec 1998 A
5851202 Carlsson Dec 1998 A
5852590 De La Huerga Dec 1998 A
5853387 Clegg et al. Dec 1998 A
5855550 Buyan et al. Jan 1999 A
5857967 Frid et al. Jan 1999 A
5858238 McRea et al. Jan 1999 A
5858239 Kenley et al. Jan 1999 A
5859972 Subramaniam et al. Jan 1999 A
5863421 Peter, Jr. et al. Jan 1999 A
5865745 Schmitt et al. Feb 1999 A
5865786 Sibalis et al. Feb 1999 A
5866880 Seitz et al. Feb 1999 A
5867821 Ballantyne et al. Feb 1999 A
5871465 Vasko Feb 1999 A
5871694 Beden et al. Feb 1999 A
5873853 Keilman et al. Feb 1999 A
5875282 Jordan et al. Feb 1999 A
5876611 Shettigar Mar 1999 A
5876926 Beecham Mar 1999 A
5880443 McDonald et al. Mar 1999 A
5882338 Gray Mar 1999 A
5883370 Walker et al. Mar 1999 A
5883576 De La Huerga Mar 1999 A
5885245 Lynch et al. Mar 1999 A
5891035 Wood et al. Apr 1999 A
5891734 Gill et al. Apr 1999 A
5893697 Zimi et al. Apr 1999 A
5894273 Meador et al. Apr 1999 A
5895368 Utterberg Apr 1999 A
5895371 Jordan et al. Apr 1999 A
5895578 Simard et al. Apr 1999 A
5897493 Brown Apr 1999 A
5897530 Jackson Apr 1999 A
5897989 Beecham Apr 1999 A
5899665 Makino et al. May 1999 A
5899855 Brown May 1999 A
5899998 McGauley et al. May 1999 A
5901150 Dupouy et al. May 1999 A
5902336 Mishkin May 1999 A
5902476 Twardowski May 1999 A
5904668 Hyman et al. May 1999 A
5905653 Higham et al. May 1999 A
5907291 Chen et al. May 1999 A
5908027 Butterfield et al. Jun 1999 A
5910107 Iliff Jun 1999 A
5910252 Truitt et al. Jun 1999 A
5911132 Sloane Jun 1999 A
5911687 Sano et al. Jun 1999 A
5912818 McGrady et al. Jun 1999 A
5913197 Kameda Jun 1999 A
5913310 Brown Jun 1999 A
5915240 Karpf Jun 1999 A
5919154 Toavs et al. Jul 1999 A
5919369 Ash Jul 1999 A
5921938 Aoyama et al. Jul 1999 A
5921951 Morris Jul 1999 A
5923018 Kameda et al. Jul 1999 A
5924074 Evans Jul 1999 A
5924103 Ahmed et al. Jul 1999 A
5925011 Faict et al. Jul 1999 A
5927540 Godlewski Jul 1999 A
5928744 Heilmann et al. Jul 1999 A
5928889 Bakich et al. Jul 1999 A
5931791 Saltzstein et al. Aug 1999 A
5931990 Andrews Aug 1999 A
5932103 Kenley et al. Aug 1999 A
5932110 Shah Aug 1999 A
5935060 Iliff Aug 1999 A
5935099 Peterson et al. Aug 1999 A
5935106 Olsen Aug 1999 A
5938413 Makino et al. Aug 1999 A
5938634 Packard Aug 1999 A
5939326 Chupp et al. Aug 1999 A
5939699 Perttunen et al. Aug 1999 A
5940306 Gardner et al. Aug 1999 A
5940802 Hildebrand et al. Aug 1999 A
5941829 Saltzstein et al. Aug 1999 A
5942986 Shabot et al. Aug 1999 A
5943423 Muftic Aug 1999 A
5943633 Wilson et al. Aug 1999 A
5944659 Flach et al. Aug 1999 A
5944684 Roberts et al. Aug 1999 A
5945651 Chorosinski et al. Aug 1999 A
5946083 Melendez et al. Aug 1999 A
5946659 Lancelot et al. Aug 1999 A
5947937 Urrutia et al. Sep 1999 A
5948251 Brugger Sep 1999 A
5950006 Crater et al. Sep 1999 A
5951300 Brown Sep 1999 A
5951510 Barak Sep 1999 A
5951870 Utterberg Sep 1999 A
5954640 Szabo Sep 1999 A
5954885 Bollish et al. Sep 1999 A
5954958 Folden Sep 1999 A
5954971 Pages et al. Sep 1999 A
5956023 Lyle et al. Sep 1999 A
5957153 Frey et al. Sep 1999 A
5957885 Bollish et al. Sep 1999 A
5959529 Kail, IV Sep 1999 A
5960085 De La Huerga Sep 1999 A
5960160 Clark et al. Sep 1999 A
5960403 Brown Sep 1999 A
5960991 Ophardt Oct 1999 A
5961446 Beller et al. Oct 1999 A
5961448 Swenson et al. Oct 1999 A
5961487 Davis Oct 1999 A
5964700 Tallman et al. Oct 1999 A
5966304 Cook et al. Oct 1999 A
5967975 Ridgeway Oct 1999 A
5970423 Langley et al. Oct 1999 A
5971593 McGrady Oct 1999 A
5971921 Timbel Oct 1999 A
5971948 Pages et al. Oct 1999 A
5974124 Schlueter, Jr. et al. Oct 1999 A
5975737 Crater et al. Nov 1999 A
5980481 Gorsuch Nov 1999 A
5980490 Tsoukalis Nov 1999 A
5980741 Schnell et al. Nov 1999 A
5983193 Heinonen et al. Nov 1999 A
5983947 Utterberg Nov 1999 A
5984891 Keilman et al. Nov 1999 A
5987519 Peifer et al. Nov 1999 A
5989238 Ginsburg Nov 1999 A
5989318 Schroll Nov 1999 A
5989423 Kamen et al. Nov 1999 A
5991731 Colon et al. Nov 1999 A
5993046 McGrady et al. Nov 1999 A
5993420 Hyman et al. Nov 1999 A
5995077 Wilcox et al. Nov 1999 A
5995965 Experton Nov 1999 A
5997167 Crater et al. Dec 1999 A
5997476 Brown Dec 1999 A
6001201 Vincent et al. Dec 1999 A
6003006 Colella et al. Dec 1999 A
6004020 Bartur Dec 1999 A
6004276 Wright et al. Dec 1999 A
6004311 Heilmann et al. Dec 1999 A
6006191 DiRienzo Dec 1999 A
6009333 Chaco Dec 1999 A
6010454 Arieff et al. Jan 2000 A
6010623 Schnell et al. Jan 2000 A
6011858 Stock et al. Jan 2000 A
6011999 Holmes Jan 2000 A
6012034 Hamparian et al. Jan 2000 A
6013057 Danby et al. Jan 2000 A
6014631 Teagarden et al. Jan 2000 A
6016444 John Jan 2000 A
6017318 Gauthier et al. Jan 2000 A
6018713 Coli et al. Jan 2000 A
6019745 Gray Feb 2000 A
6019824 Schnell Feb 2000 A
6021392 Lester et al. Feb 2000 A
6022315 Iliff Feb 2000 A
6023522 Draganoff et al. Feb 2000 A
6024539 Blomquist Feb 2000 A
6024699 Allen et al. Feb 2000 A
6024720 Chandler et al. Feb 2000 A
6027217 McClure et al. Feb 2000 A
6029138 Khorasani et al. Feb 2000 A
6032119 Brown et al. Feb 2000 A
6032155 de la Huerga Feb 2000 A
6033076 Braeuning et al. Mar 2000 A
6039251 Crone et al. Mar 2000 A
6039467 Holmes Mar 2000 A
6042784 Wamsiedler et al. Mar 2000 A
6046806 Thompson Apr 2000 A
6047259 Campbell et al. Apr 2000 A
6050940 Braun et al. Apr 2000 A
6051134 Schnell et al. Apr 2000 A
6052752 Kwon Apr 2000 A
6053967 Heilmann et al. Apr 2000 A
6055487 Margery et al. Apr 2000 A
6057758 Dempsey et al. May 2000 A
6059736 Tapper May 2000 A
6061603 Papadopoulos et al. May 2000 A
6065819 Holmes et al. May 2000 A
6066111 Brockhoff May 2000 A
6068153 Young et al. May 2000 A
6069343 Kolowich May 2000 A
6071269 Schnell et al. Jun 2000 A
6073046 Patel et al. Jun 2000 A
6074345 van Oostrom et al. Jun 2000 A
6074359 Keshaviah et al. Jun 2000 A
6079621 Vardanyan et al. Jun 2000 A
6080106 Lloyd et al. Jun 2000 A
6081048 Bergmann et al. Jun 2000 A
6082776 Feinberg Jul 2000 A
6083206 Molko Jul 2000 A
6093146 Filangeri Jul 2000 A
6095985 Raymond et al. Aug 2000 A
6101407 Groezinger Aug 2000 A
6101478 Brown Aug 2000 A
6102856 Groff et al. Aug 2000 A
6108399 Hernandez-Guerra et al. Aug 2000 A
6108588 McGrady Aug 2000 A
6109774 Holmes et al. Aug 2000 A
6112224 Peifer et al. Aug 2000 A
RE36871 Epstein et al. Sep 2000 E
6113554 Gilcher et al. Sep 2000 A
6116461 Broadfield et al. Sep 2000 A
6117342 Schnell et al. Sep 2000 A
6117940 Bond et al. Sep 2000 A
6123524 Danby et al. Sep 2000 A
6125350 Dirbas Sep 2000 A
6129517 Danby et al. Oct 2000 A
6129699 Haight et al. Oct 2000 A
6132371 Dempsey et al. Oct 2000 A
6132616 Twardowski et al. Oct 2000 A
6134504 Douglas et al. Oct 2000 A
6135949 Russo et al. Oct 2000 A
6137776 Bauerschmidt et al. Oct 2000 A
6139495 De La Huerga Oct 2000 A
6139528 Kistner et al. Oct 2000 A
6139748 Ericson et al. Oct 2000 A
6139754 Hartranft Oct 2000 A
6139757 Ohmura Oct 2000 A
6142974 Kistner et al. Nov 2000 A
6142975 Kistner et al. Nov 2000 A
6144922 Douglas et al. Nov 2000 A
6145695 Garrigues Nov 2000 A
6146359 Carr et al. Nov 2000 A
6146523 Kenley et al. Nov 2000 A
6146536 Twardowski Nov 2000 A
6148297 Swor et al. Nov 2000 A
6149063 Reynolds et al. Nov 2000 A
6151298 Bernhardsson et al. Nov 2000 A
6151536 Arnold et al. Nov 2000 A
6152364 Schoonen et al. Nov 2000 A
6154668 Pedersen et al. Nov 2000 A
6154726 Rensimer et al. Nov 2000 A
6157914 Seto et al. Dec 2000 A
6158965 Butterfield et al. Dec 2000 A
6160478 Jacobsen et al. Dec 2000 A
6161095 Brown Dec 2000 A
6163737 Fedor et al. Dec 2000 A
6165154 Gray et al. Dec 2000 A
6168563 Brown Jan 2001 B1
6168578 Diamond Jan 2001 B1
6170007 Venkatraman et al. Jan 2001 B1
6170746 Brook et al. Jan 2001 B1
6171112 Clark et al. Jan 2001 B1
6171237 Boaz et al. Jan 2001 B1
6171264 Bader Jan 2001 B1
6171484 Schnell et al. Jan 2001 B1
6173198 Schulze et al. Jan 2001 B1
6175688 Cassidy et al. Jan 2001 B1
6175779 Barrett Jan 2001 B1
6175977 Schumacher et al. Jan 2001 B1
6176903 Wamsiedler Jan 2001 B1
6182047 Dirbas Jan 2001 B1
6183417 Geheb et al. Feb 2001 B1
6186145 Brown Feb 2001 B1
6187198 Utterberg Feb 2001 B1
6188988 Barry et al. Feb 2001 B1
6192320 Margrey et al. Feb 2001 B1
6193480 Butterfield Feb 2001 B1
6193684 Burbank et al. Feb 2001 B1
6195887 Danby et al. Mar 2001 B1
6196992 Keilman et al. Mar 2001 B1
6198394 Jacobsen et al. Mar 2001 B1
6200264 Satherley et al. Mar 2001 B1
6200289 Hochman et al. Mar 2001 B1
6203495 Bardy Mar 2001 B1
6203528 Deckert et al. Mar 2001 B1
6206238 Ophardt Mar 2001 B1
6206829 Iliff Mar 2001 B1
6206954 Schnell et al. Mar 2001 B1
6210361 Kamen et al. Apr 2001 B1
6213391 Lewis Apr 2001 B1
6213738 Danby et al. Apr 2001 B1
6219439 Burger Apr 2001 B1
6219587 Ahlin et al. Apr 2001 B1
6220299 Arvidsson et al. Apr 2001 B1
6221011 Bardy Apr 2001 B1
6221012 Maschke et al. Apr 2001 B1
6222619 Herron et al. Apr 2001 B1
6224549 Van Drongelen May 2001 B1
6225901 Kail, IV May 2001 B1
6226564 Stuart May 2001 B1
6228047 Dadson May 2001 B1
6229957 Baker May 2001 B1
6230927 Schoonen et al. May 2001 B1
6234991 Gorsuch May 2001 B1
6234992 Haight et al. May 2001 B1
6234997 Kamen et al. May 2001 B1
6236809 Cassidy et al. May 2001 B1
6245013 Minoz et al. Jun 2001 B1
6245039 Brugger et al. Jun 2001 B1
6246473 Smith, Jr. et al. Jun 2001 B1
6248063 Barnhill et al. Jun 2001 B1
6248065 Brown Jun 2001 B1
6251167 Berson Jun 2001 B1
6251279 Peterson et al. Jun 2001 B1
6254567 Treu et al. Jul 2001 B1
6255951 De La Huerga Jul 2001 B1
6256643 Cork et al. Jul 2001 B1
6256967 Hebron et al. Jul 2001 B1
6259355 Chaco et al. Jul 2001 B1
6259654 De La Huerga Jul 2001 B1
6260715 Simard et al. Jul 2001 B1
6261261 Gordon Jul 2001 B1
6261809 Bertling et al. Jul 2001 B1
6266645 Simpson Jul 2001 B1
6269340 Ford et al. Jul 2001 B1
D446854 Cheney, II et al. Aug 2001 S
6270455 Brown Aug 2001 B1
6270457 Bardy Aug 2001 B1
6272394 Lipps Aug 2001 B1
6272505 De La Huerga Aug 2001 B1
6274034 Nikaido et al. Aug 2001 B1
6274103 Taylor Aug 2001 B1
6277072 Bardy Aug 2001 B1
6280632 Polaschegg Aug 2001 B1
6280634 Shah et al. Aug 2001 B1
6283322 Liff et al. Sep 2001 B1
6283944 McMullen et al. Sep 2001 B1
6287516 Matson et al. Sep 2001 B1
6290646 Cosentino Sep 2001 B1
6290650 Butterfield et al. Sep 2001 B1
6290669 Zicherman Sep 2001 B1
6293921 Shinmoto et al. Sep 2001 B1
6294999 Yarin et al. Sep 2001 B1
6295506 Heinonen Sep 2001 B1
6302653 Bryant et al. Oct 2001 B1
6304788 Eady et al. Oct 2001 B1
6306088 Krausman et al. Oct 2001 B1
6307956 Black Oct 2001 B1
6308171 De La Huerga Oct 2001 B1
6309673 Duponchelle Oct 2001 B1
6311163 Sheehan et al. Oct 2001 B1
6312227 Davis Nov 2001 B1
6312378 Bardy Nov 2001 B1
6312414 Brockhoff et al. Nov 2001 B1
6314384 Goetz Nov 2001 B1
6315895 Summerton et al. Nov 2001 B1
6317719 Schrier et al. Nov 2001 B1
6319200 Lai Nov 2001 B1
6319221 Savage et al. Nov 2001 B1
6321203 Kameda Nov 2001 B1
6322504 Kirshner Nov 2001 B1
6322515 Goor et al. Nov 2001 B1
6322551 Brugger Nov 2001 B1
6331252 El Sayyid et al. Dec 2001 B1
RE37531 Chaco et al. Jan 2002 E
6337631 Pai Jan 2002 B1
6338007 Broadfield et al. Jan 2002 B1
6339732 Phoon et al. Jan 2002 B1
6344139 Utterberg Feb 2002 B1
6345260 Cummings, Jr. et al. Feb 2002 B1
6346886 De La Huerga Feb 2002 B1
6348162 Ash Feb 2002 B1
6352200 Schoonen et al. Mar 2002 B1
6353817 Jacobs et al. Mar 2002 B1
6357600 Scagliarini Mar 2002 B1
6358225 Butterfield Mar 2002 B1
6358237 Paukovits Mar 2002 B1
6361201 Russell et al. Mar 2002 B1
6361263 Dewey et al. Mar 2002 B1
6362591 Moberg Mar 2002 B1
6363282 Nichols et al. Mar 2002 B1
6363290 Lyle et al. Mar 2002 B1
6364143 Knierbein Apr 2002 B1
6364834 Reuss et al. Apr 2002 B1
6364857 Gray et al. Apr 2002 B1
6366282 Nichols et al. Apr 2002 B1
6368273 Brown Apr 2002 B1
6370841 Chudy et al. Apr 2002 B1
6381577 Brown Apr 2002 B1
6382923 Gray May 2002 B1
6385505 Lipps May 2002 B1
6391541 Petersen et al. May 2002 B1
6391638 Shaaltiel May 2002 B1
6393369 Carr May 2002 B1
6397190 Goetz May 2002 B1
6402702 Gilcher et al. Jun 2002 B1
6406426 Reuss et al. Jun 2002 B1
6406631 Collins et al. Jun 2002 B1
6407335 Franklin-Lees et al. Jun 2002 B1
6408330 De La Huerga Jun 2002 B1
6416293 Bouchard et al. Jul 2002 B1
6416471 Kumar et al. Jul 2002 B1
6421650 Goetz et al. Jul 2002 B1
6426056 Taylor Jul 2002 B2
6427088 Bowman, IV et al. Jul 2002 B1
6434531 Lancelot et al. Aug 2002 B1
6434569 Tomlinson et al. Aug 2002 B1
6449927 Hebron et al. Sep 2002 B2
6450956 Rappaport et al. Sep 2002 B1
6458102 Mann et al. Oct 2002 B1
6464977 Kai et al. Oct 2002 B2
6468242 Wilson et al. Oct 2002 B1
6470234 McGrady Oct 2002 B1
6471089 Liff et al. Oct 2002 B2
6471645 Warkentin et al. Oct 2002 B1
6475146 Frelburger et al. Nov 2002 B1
6475148 Jackson et al. Nov 2002 B1
6475180 Peterson et al. Nov 2002 B2
6478737 Bardy Nov 2002 B2
6485465 Moberg et al. Nov 2002 B2
6489301 Kobira et al. Dec 2002 B1
6511138 Gardner et al. Jan 2003 B1
6519569 White et al. Feb 2003 B1
6537244 Paukovits et al. Mar 2003 B2
6542902 Dulong et al. Apr 2003 B2
6542910 Cork et al. Apr 2003 B2
6544174 West et al. Apr 2003 B2
6544228 Heitmeier Apr 2003 B1
6551243 Bocionek et al. Apr 2003 B2
6551276 Mann et al. Apr 2003 B1
6554791 Cartledge et al. Apr 2003 B1
6554798 Mann et al. Apr 2003 B1
6555986 Moberg Apr 2003 B2
6558321 Burd et al. May 2003 B1
6561975 Pool et al. May 2003 B1
6562001 Lebel et al. May 2003 B2
6564104 Nelson et al. May 2003 B2
6564105 Starkweather et al. May 2003 B2
6571128 Lebel et al. May 2003 B2
6575900 Zweig et al. Jun 2003 B1
6577899 Lebel et al. Jun 2003 B2
6579232 Sakamaki et al. Jun 2003 B2
6579253 Burbank et al. Jun 2003 B1
6581069 Robinson et al. Jun 2003 B1
6582385 Burbank et al. Jun 2003 B2
6584336 Ali et al. Jun 2003 B1
6585157 Brandt et al. Jul 2003 B2
6585644 Lebel et al. Jul 2003 B2
6585675 O'Mahony et al. Jul 2003 B1
6592551 Cobb Jul 2003 B1
6593528 Franklin-Lees et al. Jul 2003 B2
6595944 Balschat et al. Jul 2003 B2
6595948 Suzuki et al. Jul 2003 B2
6602502 Strahilevitz Aug 2003 B1
6607485 Bardy Aug 2003 B2
6613009 Bainbridge et al. Sep 2003 B1
6623709 Taylor Sep 2003 B2
6635014 Starkweather et al. Oct 2003 B2
6648821 Lebel et al. Nov 2003 B2
6656355 Sano Dec 2003 B2
6659948 Lebel et al. Dec 2003 B2
6664893 Eveland et al. Dec 2003 B1
6668196 Villegas et al. Dec 2003 B1
6673314 Burbank et al. Jan 2004 B1
6673376 Knerr et al. Jan 2004 B1
6676621 Menninger Jan 2004 B1
6685831 Donig et al. Feb 2004 B2
6687546 Lebel et al. Feb 2004 B2
6689091 Bui et al. Feb 2004 B2
6694191 Starkweather et al. Feb 2004 B2
6694334 DuLong et al. Feb 2004 B2
6733446 Lebel et al. May 2004 B2
6733447 Lai et al. May 2004 B2
6740075 Lebel et al. May 2004 B2
6745903 Grandics Jun 2004 B2
6746398 Hervy et al. Jun 2004 B2
6746607 Vijayalakshmi et al. Jun 2004 B1
6749818 Sano et al. Jun 2004 B2
6752928 Pfeil et al. Jun 2004 B2
6758810 Lebel et al. Jul 2004 B2
6758975 Peabody et al. Jul 2004 B2
6768425 Flaherty et al. Jul 2004 B2
6787032 Kurome et al. Sep 2004 B2
6790198 White et al. Sep 2004 B1
6804656 Rosenfeld et al. Oct 2004 B1
6810290 Lebel et al. Oct 2004 B2
6811533 Lebel et al. Nov 2004 B2
6811534 Bowman, IV et al. Nov 2004 B2
6811707 Rovatti et al. Nov 2004 B2
6813519 Lebel et al. Nov 2004 B2
6820093 De La Huerga Nov 2004 B2
6854088 Massengale et al. Feb 2005 B2
6861033 Mullins et al. Mar 2005 B2
6868309 Begelman Mar 2005 B1
6871211 Labounty et al. Mar 2005 B2
6873268 Lebel et al. Mar 2005 B2
6880034 Manke et al. Apr 2005 B2
6885288 Pincus Apr 2005 B2
6902670 Ho Jun 2005 B2
6908546 Smith Jun 2005 B2
6912549 Rotter et al. Jun 2005 B2
6913590 Sorenson et al. Jul 2005 B2
6923987 Kai et al. Aug 2005 B2
6928452 De La Huerga Aug 2005 B2
6950708 Bowman, IV et al. Sep 2005 B2
6958705 Lebel et al. Oct 2005 B2
6960179 Gura Nov 2005 B2
6974437 Lebel et al. Dec 2005 B2
6976628 Krupa Dec 2005 B2
6979306 Moll Dec 2005 B2
6980958 Surwit et al. Dec 2005 B1
6986872 Taylor Jan 2006 B2
7024245 Lebel et al. Apr 2006 B2
7039878 Auer et al. May 2006 B2
7044927 Mueller et al. May 2006 B2
7045061 Nishimura et al. May 2006 B2
7051002 Keresman, III et al. May 2006 B2
7061831 De La Huerga Jun 2006 B2
7072769 Fletcher-Haynes et al. Jul 2006 B2
7076520 Nelson et al. Jul 2006 B2
7077956 Rovatti Jul 2006 B2
7089780 Sunshine et al. Aug 2006 B2
7092796 Vanderveen Aug 2006 B2
7096072 Engleson et al. Aug 2006 B2
7108790 Collins et al. Sep 2006 B2
7117239 Hansen Oct 2006 B1
7122210 Paola Oct 2006 B2
7152469 Milleker et al. Dec 2006 B2
7156808 Quy Jan 2007 B2
7161484 Tsoukalis Jan 2007 B2
7165221 Monteleone et al. Jan 2007 B2
7171274 Starkweather et al. Jan 2007 B2
7188151 Kumar et al. Mar 2007 B2
7194336 DiGianfilippo et al. Mar 2007 B2
7208092 Micheli Apr 2007 B2
7216802 De La Huerga May 2007 B1
7231263 Choi Jun 2007 B2
7238156 Adamczyk Jul 2007 B1
7241272 Karoor et al. Jul 2007 B2
7250619 Taylor et al. Jul 2007 B2
7251610 Alban et al. Jul 2007 B2
7264148 Tachibana Sep 2007 B2
7274799 Cohen et al. Sep 2007 B2
7275220 Brummel et al. Sep 2007 B2
7290680 Henry et al. Nov 2007 B2
7292141 Staats et al. Nov 2007 B2
7300418 Zaleski Nov 2007 B2
7304582 Robert et al. Dec 2007 B2
7306736 Collins et al. Dec 2007 B2
7308894 Hickle Dec 2007 B2
7309323 Gura et al. Dec 2007 B2
7315825 Rosenfeld et al. Jan 2008 B2
7316648 Kelly et al. Jan 2008 B2
7316662 Delnevo et al. Jan 2008 B2
7317967 DiGianfilippo et al. Jan 2008 B2
7319386 Collins, Jr. et al. Jan 2008 B2
7321862 Rosenfeld et al. Jan 2008 B2
7343224 DiGianfilippo et al. Mar 2008 B2
7347819 Lebel et al. Mar 2008 B2
7356382 Vanderveen Apr 2008 B2
7369913 Heminway et al. May 2008 B2
7383196 Tang et al. Jun 2008 B1
7384410 Eggers et al. Jun 2008 B2
7419587 Valbjoern et al. Sep 2008 B2
7419597 Brugger et al. Sep 2008 B2
7544300 Brugger et al. Jun 2009 B2
7749393 Brugger et al. Jul 2010 B2
7805407 Verbeke Sep 2010 B1
7892423 Rohde et al. Feb 2011 B2
7942851 Fairies et al. May 2011 B2
7976711 Brugger et al. Jul 2011 B2
8071055 Newcombe Dec 2011 B2
8177977 Gaignet May 2012 B2
8192387 Brugger et al. Jun 2012 B2
8216452 Rohde et al. Jul 2012 B2
8226595 Childers et al. Jul 2012 B2
8354029 Hank Jan 2013 B2
8425767 Fava et al. Apr 2013 B2
9053033 Derbeko Jun 2015 B1
9180238 Bedingfield et al. Nov 2015 B2
9860302 Wittner et al. Jan 2018 B2
9934540 Schneider et al. Apr 2018 B2
20010001237 Stroda et al. May 2001 A1
20010003177 Schena et al. Jun 2001 A1
20010007053 Bardy Jul 2001 A1
20010007932 Kamen et al. Jul 2001 A1
20010011153 Bardy Aug 2001 A1
20010016699 Burbank et al. Aug 2001 A1
20010017817 De La Huerga Aug 2001 A1
20010021801 Bardy Sep 2001 A1
20010021817 Brugger et al. Sep 2001 A1
20010025138 Bardy Sep 2001 A1
20010025156 Bui et al. Sep 2001 A1
20010027289 Treu et al. Oct 2001 A1
20010027634 Hebron et al. Oct 2001 A1
20010028308 De La Huerga Oct 2001 A1
20010030234 Wiklof Oct 2001 A1
20010031944 Peterson et al. Oct 2001 A1
20010032101 Statius Muller Oct 2001 A1
20010034502 Moberg et al. Oct 2001 A1
20010034616 Giannini Oct 2001 A1
20010037057 Bardy Nov 2001 A1
20010037079 Burbank et al. Nov 2001 A1
20010037083 Hartlaub et al. Nov 2001 A1
20010037217 Abensour et al. Nov 2001 A1
20010037220 Merry et al. Nov 2001 A1
20010041892 Burbank et al. Nov 2001 A1
20010041920 Starkweather et al. Nov 2001 A1
20010042441 Purdom et al. Nov 2001 A1
20010044588 Mault Nov 2001 A1
20010044731 Coffman et al. Nov 2001 A1
20010051764 Bardy Dec 2001 A1
20010053885 Gielen et al. Dec 2001 A1
20020002326 Causey, III et al. Jan 2002 A1
20020002473 Schrier et al. Jan 2002 A1
20020004645 Carlisle et al. Jan 2002 A1
20020010568 Rubbert et al. Jan 2002 A1
20020013612 Whitehurst Jan 2002 A1
20020016567 Hochman et al. Feb 2002 A1
20020016568 Lebel et al. Feb 2002 A1
20020016719 Nemeth et al. Feb 2002 A1
20020016722 Kameda Feb 2002 A1
20020019606 Lebel et al. Feb 2002 A1
20020019748 Brown Feb 2002 A1
20020022776 Bardy Feb 2002 A1
20020025796 Taylor et al. Feb 2002 A1
20020026104 Bardy Feb 2002 A1
20020029157 Marchosky Mar 2002 A1
20020029776 Blomquist Mar 2002 A1
20020032602 Lanzillo, Jr. et al. Mar 2002 A1
20020038392 De La Huerga Mar 2002 A1
20020040208 Flaherty et al. Apr 2002 A1
20020044043 Chaco et al. Apr 2002 A1
20020046062 Kameda Apr 2002 A1
20020046185 Villart et al. Apr 2002 A1
20020046346 Evans Apr 2002 A1
20020052539 Haller et al. May 2002 A1
20020052542 Bardy May 2002 A1
20020052574 Hochman et al. May 2002 A1
20020065540 Lebel et al. May 2002 A1
20020067273 Jaques et al. Jun 2002 A1
20020068015 Polaschegg et al. Jun 2002 A1
20020072718 Brugger et al. Jun 2002 A1
20020072733 Flaherty Jun 2002 A1
20020077852 Ford et al. Jun 2002 A1
20020077865 Sullivan Jun 2002 A1
20020082480 Riff et al. Jun 2002 A1
20020082865 Bianco et al. Jun 2002 A1
20020082868 Pories et al. Jun 2002 A1
20020084904 De La Huerga Jul 2002 A1
20020087120 Rogers et al. Jul 2002 A1
20020099283 Christ et al. Jul 2002 A1
20020099301 Bardy Jul 2002 A1
20020100762 Liff et al. Aug 2002 A1
20020107476 Mann et al. Aug 2002 A1
20020107707 Naparstek et al. Aug 2002 A1
20020116509 De La Huerga Aug 2002 A1
20020128606 Cowan et al. Sep 2002 A1
20020128871 Adamson et al. Sep 2002 A1
20020128880 Kunikiyo Sep 2002 A1
20020131332 Kaelin Sep 2002 A1
20020133377 Brown Sep 2002 A1
20020140675 Ali et al. Oct 2002 A1
20020143254 Maruyama Oct 2002 A1
20020156462 Stultz Oct 2002 A1
20020158128 Ashiura Oct 2002 A1
20020162778 Peabody et al. Nov 2002 A1
20020165491 Reilly Nov 2002 A1
20020169636 Eggers et al. Nov 2002 A1
20020187940 Masuda et al. Dec 2002 A1
20020198513 Lebel et al. Dec 2002 A1
20030000876 Kawaguchi Jan 2003 A1
20030023177 Bardy Jan 2003 A1
20030036783 Bauhahn et al. Feb 2003 A1
20030050621 Lebel et al. Mar 2003 A1
20030052787 Zerhusen et al. Mar 2003 A1
20030060753 Starkweather et al. Mar 2003 A1
20030060754 Reilly Mar 2003 A1
20030060765 Campbell et al. Mar 2003 A1
20030060768 Kiyatake Mar 2003 A1
20030065287 Spohn et al. Apr 2003 A1
20030078534 Hochman et al. Apr 2003 A1
20030083901 Bosch et al. May 2003 A1
20030088238 Poulsen et al. May 2003 A1
20030097092 Flaherty May 2003 A1
20030105424 Karoor et al. Jun 2003 A1
20030114836 Estes et al. Jun 2003 A1
20030125611 Bardy Jul 2003 A1
20030135250 Lauman et al. Jul 2003 A1
20030139701 White et al. Jul 2003 A1
20030140929 Wilkes et al. Jul 2003 A1
20030141368 Pascual et al. Jul 2003 A1
20030144878 Wilkes et al. Jul 2003 A1
20030144880 Talachian et al. Jul 2003 A1
20030144881 Talachian et al. Jul 2003 A1
20030144882 Talachian et al. Jul 2003 A1
20030154108 Fletcher-Haynes et al. Aug 2003 A1
20030160683 Blomquist Aug 2003 A1
20030163088 Blomquist Aug 2003 A1
20030163223 Blomquist Aug 2003 A1
20030163789 Blomquist Aug 2003 A1
20030167035 Flaherty et al. Sep 2003 A1
20030176933 Lebel et al. Sep 2003 A1
20030181851 Mann et al. Sep 2003 A1
20030182164 Shabot et al. Sep 2003 A1
20030195397 Bardy Oct 2003 A1
20030201697 Richardson Oct 2003 A1
20030204414 Wilkes et al. Oct 2003 A1
20030204416 Radpay et al. Oct 2003 A1
20030204419 Wilkes et al. Oct 2003 A1
20030204420 Wilkes et al. Oct 2003 A1
20030212379 Bylund et al. Nov 2003 A1
20030220605 Bowman et al. Nov 2003 A1
20030220609 Childers et al. Nov 2003 A1
20030225596 Richardson et al. Dec 2003 A1
20030225728 Moura Dec 2003 A1
20040010425 Wilkes et al. Jan 2004 A1
20040039260 Bardy Feb 2004 A1
20040039264 Bardy Feb 2004 A1
20040039456 Davlin et al. Feb 2004 A1
20040051368 Caputo et al. Mar 2004 A1
20040088374 Webb et al. May 2004 A1
20040111293 Firanek et al. Jun 2004 A1
20040116862 Ray Jun 2004 A1
20040117215 Marchosky Jun 2004 A1
20040121767 Simpson et al. Jun 2004 A1
20040167465 Mihai et al. Aug 2004 A1
20040172283 Vanderveen et al. Sep 2004 A1
20040172300 Mihai et al. Sep 2004 A1
20040172301 Mihai et al. Sep 2004 A1
20040172302 Martucci et al. Sep 2004 A1
20040176667 Mihai et al. Sep 2004 A1
20040193328 Zaitsu et al. Sep 2004 A1
20040204673 Flaherty Oct 2004 A1
20040215490 Duchon et al. Oct 2004 A1
20040220829 Baharav et al. Nov 2004 A1
20040235446 Flaherty et al. Nov 2004 A1
20040260233 Garibotto et al. Dec 2004 A1
20050038680 McMahon Feb 2005 A1
20050054923 Pan Mar 2005 A1
20050065817 Mihai et al. Mar 2005 A1
20050070767 Maschke Mar 2005 A1
20050071194 Bormann et al. Mar 2005 A1
20050080651 Morrison et al. Apr 2005 A1
20050101901 Gura May 2005 A1
20050102028 Arnin et al. May 2005 A1
20050102167 Kapoor May 2005 A1
20050131340 Sorenson et al. Jun 2005 A1
20050131741 Tang et al. Jun 2005 A1
20050133449 Sternby Jun 2005 A1
20050135306 McAllen et al. Jun 2005 A1
20050137573 McLaughlin Jun 2005 A1
20050139651 Lim et al. Jun 2005 A1
20050143671 Hastings et al. Jun 2005 A1
20050148890 Hastings Jul 2005 A1
20050171815 Vanderveen Aug 2005 A1
20050177096 Bollish et al. Aug 2005 A1
20050177395 Blomquist Aug 2005 A1
20050201345 Williamson Sep 2005 A1
20050228693 Webb et al. Oct 2005 A1
20050231374 Diem et al. Oct 2005 A1
20050234381 Niemetz et al. Oct 2005 A1
20050246416 Blomquist Nov 2005 A1
20050267780 Ray et al. Dec 2005 A1
20050278194 Holland et al. Dec 2005 A1
20050283385 Hunkeler et al. Dec 2005 A1
20060015015 Kawamoto et al. Jan 2006 A1
20060167722 Struys et al. Jan 2006 A1
20060064020 Burnes et al. Mar 2006 A1
20060064053 Bollish et al. Mar 2006 A1
20060065713 Kingery Mar 2006 A1
20060089539 Miodownik et al. Apr 2006 A1
20060089854 Holland et al. Apr 2006 A1
20060089855 Holland et al. Apr 2006 A1
20060100907 Holland et al. May 2006 A1
20060106647 Brummel et al. May 2006 A1
20060106649 Eggers et al. May 2006 A1
20060116639 Russell Jun 2006 A1
20060129435 Smitherman et al. Jun 2006 A1
20060143051 Eggers et al. Jun 2006 A1
20060149591 Hanf et al. Jul 2006 A1
20060173713 Petro et al. Aug 2006 A1
20060190302 Eggers et al. Aug 2006 A1
20060200369 Batch et al. Sep 2006 A1
20060206356 Vanderveen Sep 2006 A1
20060211994 Roman et al. Sep 2006 A1
20060229551 Martinez et al. Oct 2006 A1
20060247606 Batch Nov 2006 A1
20060253301 Simms et al. Nov 2006 A1
20060258985 Russell Nov 2006 A1
20060259327 Hoag Nov 2006 A1
20060277070 Hungerford et al. Dec 2006 A1
20070033073 Tajaliawal et al. Feb 2007 A1
20070073266 Chmiel et al. Mar 2007 A1
20070073787 Tysowski et al. Mar 2007 A1
20070083386 Chuang et al. Apr 2007 A1
20070083390 Gorup et al. Apr 2007 A1
20070088578 Hoffman et al. Apr 2007 A1
20070112297 Plahey et al. May 2007 A1
20070124002 Estes et al. May 2007 A1
20070129983 Scherpbier et al. Jun 2007 A1
20070135866 Baker et al. Jun 2007 A1
20070156452 Batch Jul 2007 A1
20070158268 DeComo Jul 2007 A1
20070163965 Wolfe Jul 2007 A1
20070179807 Nessinger et al. Aug 2007 A1
20070185738 Anuszewski et al. Aug 2007 A1
20070197878 Shklarski Aug 2007 A1
20070198293 Ash et al. Aug 2007 A1
20070203753 Hasan et al. Aug 2007 A1
20070214003 Holland et al. Sep 2007 A1
20070233035 Wehba et al. Oct 2007 A1
20070233049 Wehba et al. Oct 2007 A1
20070233050 Wehba et al. Oct 2007 A1
20070233281 Wehba et al. Oct 2007 A1
20070233520 Wehba et al. Oct 2007 A1
20070233521 Wehba et al. Oct 2007 A1
20070255126 Moberg et al. Nov 2007 A1
20070265879 Charlson et al. Nov 2007 A1
20070276328 Childers et al. Nov 2007 A1
20070276869 Charlson et al. Nov 2007 A1
20070278155 Lo et al. Dec 2007 A1
20070293817 Feng et al. Dec 2007 A1
20080015493 Childers et al. Jan 2008 A1
20080015895 Charlson et al. Jan 2008 A1
20080021741 Holla et al. Jan 2008 A1
20080033360 Evans et al. Feb 2008 A1
20080033749 Blomquist Feb 2008 A1
20080034323 Blomquist Feb 2008 A1
20080045877 Levin et al. Feb 2008 A1
20080045932 Beau et al. Feb 2008 A1
20080052317 Francis et al. Feb 2008 A1
20080059239 Gerst et al. Mar 2008 A1
20080076969 Kraft et al. Mar 2008 A1
20080077436 Muradia Mar 2008 A1
20080091466 Butler et al. Apr 2008 A1
20080097912 Dicks et al. Apr 2008 A1
20080097913 Dicks et al. Apr 2008 A1
20080097914 Dicks et al. Apr 2008 A1
20080103554 Dicks et al. May 2008 A1
20080114292 Rasch-Menges et al. May 2008 A1
20080126969 Blomquist May 2008 A1
20080133265 Silkaitis et al. Jun 2008 A1
20080143515 Wood et al. Jun 2008 A1
20080161754 Marano-Ford Jul 2008 A1
20080177222 Roger Jul 2008 A1
20080203023 Burbank et al. Aug 2008 A1
20080208111 Kamen et al. Aug 2008 A1
20080210606 Burbank Sep 2008 A1
20080230450 Burbank et al. Sep 2008 A1
20080233925 Sun Sep 2008 A1
20080287919 Kimball Nov 2008 A1
20080318678 Stivoric Dec 2008 A1
20090008318 Anes et al. Jan 2009 A1
20090008331 Wilt et al. Jan 2009 A1
20090012655 Kienman et al. Jan 2009 A1
20090045121 Kabayama et al. Feb 2009 A1
20090099552 Levy et al. Apr 2009 A1
20090218285 Hank Sep 2009 A1
20100010427 Yu Jan 2010 A1
20100018923 Rohde et al. Jan 2010 A1
20100051546 Vuong et al. Mar 2010 A1
20100078092 Weilhoefer et al. Apr 2010 A1
20100137693 Porras et al. Jun 2010 A1
20100326916 Wrazel et al. Dec 2010 A1
20100332149 Scholpp Dec 2010 A1
20110072422 Brauer Mar 2011 A1
20110100913 Minami et al. May 2011 A1
20110163034 Castellarnau Jul 2011 A1
20110180480 Kloeffel et al. Jul 2011 A1
20110186521 Burbank et al. Aug 2011 A1
20110192796 Smejtek et al. Aug 2011 A1
20110208160 Wu et al. Aug 2011 A1
20110315611 Fulkerson et al. Dec 2011 A1
20130006666 Schneider Jan 2013 A1
20130008854 Wallace et al. Jan 2013 A1
20130053651 Tarn Feb 2013 A1
20130062265 Balschat et al. Mar 2013 A1
20130066661 Biebesheimer et al. Mar 2013 A1
20130197929 Vanderveen et al. Aug 2013 A1
20130245611 Bonnet et al. Sep 2013 A1
20130281965 Kamen et al. Oct 2013 A1
20130317753 Kamen Nov 2013 A1
20130336814 Kamen et al. Dec 2013 A1
20140047263 Coatney et al. Feb 2014 A1
20140195257 Perkins Jul 2014 A1
20140238912 Vincent Aug 2014 A1
20140324464 Carlsgaard Oct 2014 A1
20150041531 Vavala Feb 2015 A1
20150067021 Protas et al. Mar 2015 A1
20150127733 Ding May 2015 A1
20170203022 Burbank et al. Jul 2017 A1
Foreign Referenced Citations (158)
Number Date Country
296007 Jan 1954 CH
1806654 May 1970 DE
20 02 033 Aug 1970 DE
29 01 628 Jul 1980 DE
31 22 756 Jun 1982 DE
33 07 830 Jun 1984 DE
34 42 744 Jun 1986 DE
40 03 452 Aug 1991 DE
42 08 054 Oct 1992 DE
41 22 754 Jan 1993 DE
198 14 695 Oct 1999 DE
19828923 Jan 2000 DE
19849787 Feb 2000 DE
198 54 338 Jun 2000 DE
19814695 Sep 2001 DE
0 058 325 Aug 1982 EP
0 064 393 Oct 1982 EP
64393 Nov 1982 EP
0 106 026 Apr 1984 EP
0 143 340 Jun 1985 EP
0 143 341 Jun 1985 EP
152717 Aug 1985 EP
0 171 550 Feb 1986 EP
0 233 848 Aug 1987 EP
0306211 Mar 1989 EP
0 318 993 Jun 1989 EP
0 350 675 Jan 1990 EP
0 373 455 Jun 1990 EP
0 222 709 May 1991 EP
0428505 May 1991 EP
0432138 Jun 1991 EP
0243547 Jul 1991 EP
0 490 212 Jun 1992 EP
0491183 Jun 1992 EP
0 501 144 Sep 1992 EP
0 560 368 Sep 1993 EP
0402505 Dec 1993 EP
0 587 251 Mar 1994 EP
0611228 Aug 1994 EP
0 720 856 Jul 1996 EP
0 722 744 Jul 1996 EP
0498382 Nov 1996 EP
0778033 Nov 1996 EP
0 749 328 Dec 1996 EP
0 776 222 Jun 1997 EP
0 826 3 84 Mar 1998 EP
0 826 383 Mar 1998 EP
0575512 May 1998 EP
0928615 Jul 1999 EP
0956876 Nov 1999 EP
980685 Feb 2000 EP
0659092 Oct 2000 EP
0 659 091 Dec 2000 EP
1 097 724 May 2001 EP
0847769 Aug 2001 EP
1 277 485 Jan 2003 EP
1614437 Jan 2006 EP
1894586 Mar 2008 EP
2180908 May 2010 EP
2 397 197 Feb 1979 FR
2 585 251 Jan 1987 FR
1 408 319 Oct 1975 GB
2 014 060 Aug 1979 GB
1 554 810 Oct 1979 GB
2 061 755 May 1981 GB
2122509 Jan 1984 GB
2124511 Feb 1984 GB
2 212 739 Aug 1989 GB
2282244 Mar 1995 GB
3 026 703 Jul 1998 GR
55-32384 Mar 1980 JP
55-45437 Mar 1980 JP
55-122559 Sep 1980 JP
57161511 Oct 1982 JP
61-25564 Feb 1986 JP
6-143074 Jun 1986 JP
S61143074 Jun 1986 JP
4-2060 Jan 1992 JP
92002060 Jan 1992 JP
4348757 Mar 1992 JP
4-384757 Dec 1992 JP
59-029264 Feb 1994 JP
7-299455 Nov 1995 JP
07-299455 Nov 1995 JP
8-29224 Feb 1996 JP
8029224 Feb 1996 JP
96029224 Feb 1996 JP
9-327511 Dec 1997 JP
9327511 Dec 1997 JP
10085324 Apr 1998 JP
H1085324 Apr 1998 JP
11-137672 May 1999 JP
11137672 May 1999 JP
2000-217908 Aug 2000 JP
2000-296318 Oct 2000 JP
200120483 Dec 2000 JP
2001-270856 Oct 2001 JP
2003047657 Feb 2003 JP
2003-513714 Apr 2003 JP
2008181358 Aug 2008 JP
2009510566 Mar 2009 JP
2011-172961 Aug 2011 JP
2012519547 Aug 2012 JP
2014520593 Aug 2014 JP
1012918 Mar 1981 SE
1344362 Jun 1984 SE
1001945 Mar 1983 SU
9014850 Dec 1990 WO
1992 018048 Oct 1992 WO
9415099 Jul 1994 WO
9420158 Sep 1994 WO
9502559 Jan 1995 WO
9517597 Jun 1995 WO
9535124 Dec 1995 WO
9625214 Aug 1996 WO
9640318 Dec 1996 WO
9709074 Mar 1997 WO
9747337 Jun 1997 WO
9817333 Apr 1998 WO
9822165 May 1998 WO
9823353 Jun 1998 WO
9832477 Jul 1998 WO
9903519 Jan 1999 WO
9906082 Feb 1999 WO
9942150 Aug 1999 WO
9964103 Dec 1999 WO
9966407 Dec 1999 WO
0009182 Feb 2000 WO
0020050 Apr 2000 WO
0020052 Apr 2000 WO
0031967 Jun 2000 WO
0050143 Aug 2000 WO
0055762 Sep 2000 WO
0057925 Oct 2000 WO
0057926 Oct 2000 WO
0057927 Oct 2000 WO
0057928 Oct 2000 WO
0064510 Nov 2000 WO
0137786 May 2001 WO
0137894 May 2001 WO
0137895 May 2001 WO
0137900 May 2001 WO
0141831 Jun 2001 WO
0141832 Jun 2001 WO
0141833 Jun 2001 WO
0142758 Jun 2001 WO
0145769 Jun 2001 WO
0147576 Jul 2001 WO
0243859 Jun 2002 WO
2004070562 Aug 2004 WO
2007118235 Oct 2007 WO
2008138311 Nov 2008 WO
2011069110 Jun 2011 WO
2012120078 Sep 2012 WO
2012129501 Sep 2012 WO
2012170961 Dec 2012 WO
2013068393 May 2013 WO
2014203023 Dec 2014 WO
Non-Patent Literature Citations (27)
Entry
Notice of Reasons for Rejection dated Dec. 5, 2017 in corresponding JP Application No. 2013-257132.
European Search Report—EP Application No. 16176496 dated Mar. 21, 2017—13 pages.
European Communication—EP Application No. 09710209.9 dated Mar. 20, 2015—6 pages.
Search and Examination Report dated Jul. 29, 2014 for related GB Appl. No. 1322331.8.
Office Action for Mexican Patent Application No. MX/a/2010/008961.
International Search Report for PCT/US2017/031405 dated Sep. 26, 2017—7 pages.
Written Opinion of the International Searching Authority for PCT/US2017/031405 dated Sep. 26, 2017—13 pages.
International Search Report for PCT/US2017/031400 dated Sep. 26, 2017—7 pages.
Written Opinion of the International Search Authority for PCT/US2017/031400 dated Sep. 26, 2017—14 pages.
International Search Report for PCT/US2017/031396 dated Jul. 27, 2017—6 pages.
Written Opinion of the International Search Authority for PCT/US2017/031396 dated Jul. 27, 2017—7 pages.
U.S. Appl. No. 15/195,801, filed Jun. 28, 2016.
International Search Report and Written Opinion for International Application No. PCT/US2009/046997 dated Feb. 16, 2010.
International Search Report for corresponding International Application PCT/US2009/031809 dated Oct. 19, 2009.
Written Opinion for corresponding International Application PCT/US2009/031809 dated Oct. 19, 2009.
Japanese Office Action dated Dec. 14, 2012 for related Application No. 2011-100145—corresponding communication indicates no references cited in JP Office Action (1 page).
Fresenius 90/2 Peritoneal Therapy Cycler, Articile, written by Fresenius SA, dated Jul. 1993—6 pages.
Japanese Office Action for Japanese Application No. 2011-100145.
Japanese Office Action dated Feb. 18, 2014 for related Japanese Appln. No. 2013-051434.
International Preliminary Report on Patentability for PCT/EP2016/064392 dated Dec. 26, 2017—1 page.
International-Type Search Report for ITS/SE15/00154 dated Jan. 5, 2016—5 pages.
International Search Report issued in International Patent Application No. PCT/EP2016/064392 dated Sep. 14, 2016.
Written Opinion issued in International Patent Application No. PCT/EP2016/064392 dated Sep. 14, 2016.
Martins et al., “Survey of data replication in P2P systems,” Institut National de Recherche en Informatique et en Automatique INRIA, N 6083 Dec. 2006—version 2, Feb. 7, 2007—45 pages—XP002501325.
Chinese Office Action Appl. No. 2016800373131 dated Jun. 23, 2021.
Chinese Search Report Appl. No. 2016800373131 dated Jun. 23, 2021.
Japanese Office Action Application No. 2021-015123 dated May 6, 2022—8 pages.
Related Publications (1)
Number Date Country
20180144817 A1 May 2018 US