CN119380908A - Medical fluid delivery system including a mobile platform for patient engagement and treatment compliance - Google Patents
Medical fluid delivery system including a mobile platform for patient engagement and treatment compliance Download PDFInfo
- Publication number
- CN119380908A CN119380908A CN202411390832.9A CN202411390832A CN119380908A CN 119380908 A CN119380908 A CN 119380908A CN 202411390832 A CN202411390832 A CN 202411390832A CN 119380908 A CN119380908 A CN 119380908A
- Authority
- CN
- China
- Prior art keywords
- patient
- treatment
- data
- medical
- mobile communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000011282 treatment Methods 0.000 title claims abstract description 455
- 239000012530 fluid Substances 0.000 title claims abstract description 183
- 238000012384 transportation and delivery Methods 0.000 title abstract description 69
- 238000002560 therapeutic procedure Methods 0.000 claims abstract description 103
- 238000010295 mobile communication Methods 0.000 claims description 360
- 238000000034 method Methods 0.000 claims description 125
- 230000036772 blood pressure Effects 0.000 claims description 70
- 208000001647 Renal Insufficiency Diseases 0.000 claims description 65
- 201000006370 kidney failure Diseases 0.000 claims description 65
- 230000005540 biological transmission Effects 0.000 claims description 47
- 230000001413 cellular effect Effects 0.000 claims description 26
- WQZGKKKJIJFFOK-GASJEMHNSA-N Glucose Natural products OC[C@H]1OC(O)[C@H](O)[C@@H](O)[C@@H]1O WQZGKKKJIJFFOK-GASJEMHNSA-N 0.000 claims description 18
- 238000009530 blood pressure measurement Methods 0.000 claims description 18
- 230000035488 systolic blood pressure Effects 0.000 claims description 16
- 239000008103 glucose Substances 0.000 claims description 14
- 230000015654 memory Effects 0.000 claims description 12
- 238000000108 ultra-filtration Methods 0.000 claims description 12
- 238000012790 confirmation Methods 0.000 claims description 6
- 238000003860 storage Methods 0.000 claims description 6
- 238000009825 accumulation Methods 0.000 claims description 5
- 230000000694 effects Effects 0.000 claims description 5
- 230000036541 health Effects 0.000 claims description 5
- 238000001802 infusion Methods 0.000 claims description 5
- 230000002411 adverse Effects 0.000 claims description 4
- 230000004913 activation Effects 0.000 claims description 3
- 230000035487 diastolic blood pressure Effects 0.000 claims description 2
- 238000001454 recorded image Methods 0.000 abstract description 26
- 239000000284 extract Substances 0.000 abstract description 7
- 210000004369 blood Anatomy 0.000 description 64
- 239000008280 blood Substances 0.000 description 64
- 230000006854 communication Effects 0.000 description 64
- 238000004891 communication Methods 0.000 description 63
- 230000008569 process Effects 0.000 description 54
- 238000004659 sterilization and disinfection Methods 0.000 description 41
- 230000001225 therapeutic effect Effects 0.000 description 41
- 238000000502 dialysis Methods 0.000 description 34
- 238000010586 diagram Methods 0.000 description 33
- 238000012360 testing method Methods 0.000 description 33
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 31
- 230000001954 sterilising effect Effects 0.000 description 29
- 230000009471 action Effects 0.000 description 27
- 230000008859 change Effects 0.000 description 27
- 230000004044 response Effects 0.000 description 27
- 239000003795 chemical substances by application Substances 0.000 description 25
- 238000011049 filling Methods 0.000 description 25
- 238000012546 transfer Methods 0.000 description 24
- 239000000463 material Substances 0.000 description 21
- 238000001631 haemodialysis Methods 0.000 description 19
- 230000000322 hemodialysis Effects 0.000 description 19
- 230000008901 benefit Effects 0.000 description 14
- 206010042602 Supraventricular extrasystoles Diseases 0.000 description 13
- 239000008186 active pharmaceutical agent Substances 0.000 description 13
- 230000006870 function Effects 0.000 description 13
- 238000007726 management method Methods 0.000 description 13
- 238000012545 processing Methods 0.000 description 13
- 239000002699 waste material Substances 0.000 description 10
- 239000012528 membrane Substances 0.000 description 9
- 230000002093 peripheral effect Effects 0.000 description 9
- 210000003200 peritoneal cavity Anatomy 0.000 description 9
- 238000002360 preparation method Methods 0.000 description 9
- 239000003053 toxin Substances 0.000 description 9
- 231100000765 toxin Toxicity 0.000 description 9
- 108700012359 toxins Proteins 0.000 description 9
- 238000013461 design Methods 0.000 description 8
- 239000003814 drug Substances 0.000 description 8
- 210000004379 membrane Anatomy 0.000 description 8
- 230000002829 reductive effect Effects 0.000 description 8
- HTTJABKRGRZYRN-UHFFFAOYSA-N Heparin Chemical compound OC1C(NC(=O)C)C(O)OC(COS(O)(=O)=O)C1OC1C(OS(O)(=O)=O)C(O)C(OC2C(C(OS(O)(=O)=O)C(OC3C(C(O)C(O)C(O3)C(O)=O)OS(O)(=O)=O)C(CO)O2)NS(O)(=O)=O)C(C(O)=O)O1 HTTJABKRGRZYRN-UHFFFAOYSA-N 0.000 description 7
- 229940079593 drug Drugs 0.000 description 7
- 229960002897 heparin Drugs 0.000 description 7
- 229920000669 heparin Polymers 0.000 description 7
- 238000001990 intravenous administration Methods 0.000 description 7
- 238000012015 optical character recognition Methods 0.000 description 7
- 238000013439 planning Methods 0.000 description 7
- 239000000243 solution Substances 0.000 description 7
- 238000012377 drug delivery Methods 0.000 description 6
- 230000001976 improved effect Effects 0.000 description 6
- 238000002156 mixing Methods 0.000 description 6
- 238000000746 purification Methods 0.000 description 6
- BVKZGUZCCUSVTD-UHFFFAOYSA-M Bicarbonate Chemical compound OC([O-])=O BVKZGUZCCUSVTD-UHFFFAOYSA-M 0.000 description 5
- 239000002253 acid Substances 0.000 description 5
- 239000000385 dialysis solution Substances 0.000 description 5
- 238000009792 diffusion process Methods 0.000 description 5
- 230000000977 initiatory effect Effects 0.000 description 5
- 235000015097 nutrients Nutrition 0.000 description 5
- 230000002572 peristaltic effect Effects 0.000 description 5
- 238000002203 pretreatment Methods 0.000 description 5
- QGZKDVFQNNGYKY-UHFFFAOYSA-N Ammonia Chemical compound N QGZKDVFQNNGYKY-UHFFFAOYSA-N 0.000 description 4
- 238000012356 Product development Methods 0.000 description 4
- 239000012141 concentrate Substances 0.000 description 4
- 238000013479 data entry Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 238000010191 image analysis Methods 0.000 description 4
- 238000003384 imaging method Methods 0.000 description 4
- 239000008213 purified water Substances 0.000 description 4
- 230000000007 visual effect Effects 0.000 description 4
- XSQUKJJJFZCRTK-UHFFFAOYSA-N Urea Chemical compound NC(N)=O XSQUKJJJFZCRTK-UHFFFAOYSA-N 0.000 description 3
- 239000003463 adsorbent Substances 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 3
- 238000002615 hemofiltration Methods 0.000 description 3
- 239000000203 mixture Substances 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 235000016709 nutrition Nutrition 0.000 description 3
- 230000037452 priming Effects 0.000 description 3
- 238000005086 pumping Methods 0.000 description 3
- 238000012959 renal replacement therapy Methods 0.000 description 3
- 239000000126 substance Substances 0.000 description 3
- IRLPACMLTUPBCL-KQYNXXCUSA-N 5'-adenylyl sulfate Chemical compound C1=NC=2C(N)=NC=NC=2N1[C@@H]1O[C@H](COP(O)(=O)OS(O)(=O)=O)[C@@H](O)[C@H]1O IRLPACMLTUPBCL-KQYNXXCUSA-N 0.000 description 2
- IJGRMHOSHXDMSA-UHFFFAOYSA-N Atomic nitrogen Chemical compound N#N IJGRMHOSHXDMSA-UHFFFAOYSA-N 0.000 description 2
- 229920002177 Icodextrin Polymers 0.000 description 2
- 229910021529 ammonia Inorganic materials 0.000 description 2
- 239000003146 anticoagulant agent Substances 0.000 description 2
- 229940127219 anticoagulant drug Drugs 0.000 description 2
- QVGXLLKOCUKJST-UHFFFAOYSA-N atomic oxygen Chemical compound [O] QVGXLLKOCUKJST-UHFFFAOYSA-N 0.000 description 2
- 210000001124 body fluid Anatomy 0.000 description 2
- 239000010839 body fluid Substances 0.000 description 2
- 230000037396 body weight Effects 0.000 description 2
- 239000004202 carbamide Substances 0.000 description 2
- DDRJAANPRJIHGJ-UHFFFAOYSA-N creatinine Chemical compound CN1CC(=O)NC1=N DDRJAANPRJIHGJ-UHFFFAOYSA-N 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 230000003205 diastolic effect Effects 0.000 description 2
- 238000000605 extraction Methods 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 150000002500 ions Chemical class 0.000 description 2
- 230000003907 kidney function Effects 0.000 description 2
- 230000005291 magnetic effect Effects 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000003204 osmotic effect Effects 0.000 description 2
- 239000001301 oxygen Substances 0.000 description 2
- 229910052760 oxygen Inorganic materials 0.000 description 2
- 210000004303 peritoneum Anatomy 0.000 description 2
- 230000000241 respiratory effect Effects 0.000 description 2
- 239000002594 sorbent Substances 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 238000010998 test method Methods 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- ZAMOUSCENKQFHK-UHFFFAOYSA-N Chlorine atom Chemical compound [Cl] ZAMOUSCENKQFHK-UHFFFAOYSA-N 0.000 description 1
- 206010053567 Coagulopathies Diseases 0.000 description 1
- 206010020772 Hypertension Diseases 0.000 description 1
- 241000735480 Istiophorus Species 0.000 description 1
- LEHOTFFKMJEONL-UHFFFAOYSA-N Uric Acid Chemical compound N1C(=O)NC(=O)C2=C1NC(=O)N2 LEHOTFFKMJEONL-UHFFFAOYSA-N 0.000 description 1
- TVWHNULVHGKJHS-UHFFFAOYSA-N Uric acid Natural products N1C(=O)NC(=O)C2NC(=O)NC21 TVWHNULVHGKJHS-UHFFFAOYSA-N 0.000 description 1
- 210000001015 abdomen Anatomy 0.000 description 1
- 230000005856 abnormality Effects 0.000 description 1
- 230000035508 accumulation Effects 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000009118 appropriate response Effects 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000017531 blood circulation Effects 0.000 description 1
- 230000036760 body temperature Effects 0.000 description 1
- 239000002775 capsule Substances 0.000 description 1
- JYYOBHFYCIDXHH-UHFFFAOYSA-N carbonic acid;hydrate Chemical compound O.OC(O)=O JYYOBHFYCIDXHH-UHFFFAOYSA-N 0.000 description 1
- 239000007795 chemical reaction product Substances 0.000 description 1
- 239000000460 chlorine Substances 0.000 description 1
- 229910052801 chlorine Inorganic materials 0.000 description 1
- 230000002060 circadian Effects 0.000 description 1
- 230000004087 circulation Effects 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 230000035602 clotting Effects 0.000 description 1
- 230000001332 colony forming effect Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 239000000356 contaminant Substances 0.000 description 1
- 229940109239 creatinine Drugs 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000013502 data validation Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 239000008121 dextrose Substances 0.000 description 1
- 230000003467 diminishing effect Effects 0.000 description 1
- 239000008151 electrolyte solution Substances 0.000 description 1
- 239000002158 endotoxin Substances 0.000 description 1
- 229940049774 extraneal Drugs 0.000 description 1
- 239000002880 extraneal Substances 0.000 description 1
- 206010016256 fatigue Diseases 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- LLWFBEQLNVSCKV-DKWTVANSSA-N hydrogen carbonate;hydron;(2s)-2-hydroxypropanoate Chemical compound [H+].[H+].OC([O-])=O.C[C@H](O)C([O-])=O LLWFBEQLNVSCKV-DKWTVANSSA-N 0.000 description 1
- 230000007062 hydrolysis Effects 0.000 description 1
- 238000006460 hydrolysis reaction Methods 0.000 description 1
- 229940016836 icodextrin Drugs 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 229910052500 inorganic mineral Inorganic materials 0.000 description 1
- 210000003734 kidney Anatomy 0.000 description 1
- 230000002045 lasting effect Effects 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 229920002521 macromolecule Polymers 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000002503 metabolic effect Effects 0.000 description 1
- 230000004060 metabolic process Effects 0.000 description 1
- 239000011707 mineral Substances 0.000 description 1
- 230000036651 mood Effects 0.000 description 1
- 239000010813 municipal solid waste Substances 0.000 description 1
- 229910052757 nitrogen Inorganic materials 0.000 description 1
- 239000003678 nutrineal Substances 0.000 description 1
- 230000035764 nutrition Effects 0.000 description 1
- 239000002357 osmotic agent Substances 0.000 description 1
- 244000052769 pathogen Species 0.000 description 1
- 230000010412 perfusion Effects 0.000 description 1
- 230000004962 physiological condition Effects 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 238000003825 pressing Methods 0.000 description 1
- 239000000047 product Substances 0.000 description 1
- 238000010926 purge Methods 0.000 description 1
- 230000002040 relaxant effect Effects 0.000 description 1
- 210000005227 renal system Anatomy 0.000 description 1
- 238000012827 research and development Methods 0.000 description 1
- 230000000284 resting effect Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000011012 sanitization Methods 0.000 description 1
- 230000035807 sensation Effects 0.000 description 1
- 230000007958 sleep Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000012414 sterilization procedure Methods 0.000 description 1
- 230000004936 stimulating effect Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 230000008093 supporting effect Effects 0.000 description 1
- 230000002459 sustained effect Effects 0.000 description 1
- 239000008399 tap water Substances 0.000 description 1
- 235000020679 tap water Nutrition 0.000 description 1
- 229940124597 therapeutic agent Drugs 0.000 description 1
- 230000003867 tiredness Effects 0.000 description 1
- 208000016255 tiredness Diseases 0.000 description 1
- 210000001519 tissue Anatomy 0.000 description 1
- 231100000331 toxic Toxicity 0.000 description 1
- 230000002588 toxic effect Effects 0.000 description 1
- 238000012549 training Methods 0.000 description 1
- 238000013518 transcription Methods 0.000 description 1
- 230000035897 transcription Effects 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
- 229940045136 urea Drugs 0.000 description 1
- 239000002441 uremic toxin Substances 0.000 description 1
- 229940116269 uric acid Drugs 0.000 description 1
- 238000013022 venting Methods 0.000 description 1
- 230000003442 weekly effect Effects 0.000 description 1
- 238000005303 weighing Methods 0.000 description 1
- 230000004584 weight gain Effects 0.000 description 1
- 235000019786 weight gain Nutrition 0.000 description 1
- 230000036642 wellbeing Effects 0.000 description 1
- 229910000166 zirconium phosphate Inorganic materials 0.000 description 1
- LEHFSLREWWMLPU-UHFFFAOYSA-B zirconium(4+);tetraphosphate Chemical compound [Zr+4].[Zr+4].[Zr+4].[O-]P([O-])([O-])=O.[O-]P([O-])([O-])=O.[O-]P([O-])([O-])=O.[O-]P([O-])([O-])=O LEHFSLREWWMLPU-UHFFFAOYSA-B 0.000 description 1
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
- G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
- G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
- G16H20/17—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients delivered via infusion or injection
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H30/00—ICT specially adapted for the handling or processing of medical images
- G16H30/20—ICT specially adapted for the handling or processing of medical images for handling medical images, e.g. DICOM, HL7 or PACS
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H30/00—ICT specially adapted for the handling or processing of medical images
- G16H30/40—ICT specially adapted for the handling or processing of medical images for processing medical images, e.g. editing
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
- G16H40/63—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
- G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
- G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
- G16H50/30—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for calculating health indices; for individual health risk assessment
Landscapes
- Health & Medical Sciences (AREA)
- Engineering & Computer Science (AREA)
- Medical Informatics (AREA)
- Public Health (AREA)
- Epidemiology (AREA)
- General Health & Medical Sciences (AREA)
- Primary Health Care (AREA)
- Biomedical Technology (AREA)
- Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
- Radiology & Medical Imaging (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Chemical & Material Sciences (AREA)
- Bioinformatics & Cheminformatics (AREA)
- Medicinal Chemistry (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Pathology (AREA)
- External Artificial Organs (AREA)
- Medical Treatment And Welfare Office Work (AREA)
Abstract
The present invention relates to a medical fluid delivery system comprising a mobile platform for patient participation and treatment compliance. A patient platform for patient participation and treatment compliance is disclosed. In an example, the processor is configured to obtain medical information from a patient for participation and therapy compliance tracking. To obtain the medical information, the processor causes the user interface to display fields in which the medical information is to be filled. After receiving the selection of the data field, the processor provides an option to input medical information from the image. If the option is selected, the processor receives a recorded image of the medical device or a screen of the medical device, extracts text from the image, enables selection of at least a portion of text from the image, and writes the selected text from the image in a data field of the user interface as medical information. The processor communicates the medical information to a patient medical record stored in a clinician database.
Description
The present application is a divisional application, which is directed to the original application of the application having the application number 201980057821.X, which is filed as "bucktet international corporation" and "bucktet healthcare co-available corporation", 9/5/2019/date, and the application's name "medical fluid delivery system including a mobile platform for patient participation and treatment compliance".
Technical Field
The present invention relates to a medical fluid delivery system comprising a mobile platform for patient participation and treatment compliance.
Background
At present, contact with the patient for a long time outside the medical environment is a nearly impossible task. Similar to starting to become a gym member or purchasing a treadmill, many patients are often initially more robust. For example, initially, patients may readily receive medical treatment (e.g., medical fluid delivery treatment) that is performed by themselves in the patient's home. For treatment, the patient must connect himself to the medical fluid conveyor (or container containing the renal failure treatment fluid) to clear the blood of the toxin build-up. A portion of the treatment may include tasks that the patient must perform, such as weighing himself, measuring his blood pressure, and/or recording information related to his treatment. Patient recorded information is typically reviewed by a clinician to ensure prescribed treatment. The clinician will also review the recorded data to determine if adjustments to the treatment are needed.
Over time, many patients become less enthusiastic for treatment due to loss of freshness, just becoming another obligation. It is envisioned that patients would prefer to perform more exciting, relaxing or stimulating activities than self-administered medical treatments. As patients continue treatment, they sometimes begin to omit performing other tasks related to the treatment. Omitting other tasks and reducing enthusiasm for treatment may create gaps in clinical supervision of ongoing treatments. As patients get further out of treatment they may begin to skip treatment or drop treatment altogether, posing a health risk in the process.
Disclosure of Invention
Technical problem
Disclosed herein are medical fluid data transmission systems including mobile platforms. The medical fluid data transmission system is configured to improve participation and/or therapy compliance with a patient through interactions provided by the patient's portable device (e.g., cellular phone, smartphone, tablet, etc.). In particular, the medical fluid data transmission system provides enhanced feedback and control to the patient (without being overwhelmed), which makes the patient feel as if he is controlling his own therapy, rather than following the instructions of the clinician. For example, a personal mobile communication device of a medical fluid data transmission system may display treatment information and/or vital sign data of a patient. The personal mobile communication device may also enable the patient to switch between different prescribed treatments or procedures without having to directly program the medical fluid delivery machine. Patients who feel mastered are more likely to continue to receive treatment.
The example medical fluid data transmission system also reduces the data collection burden on the patient by automating the process. For example, personal mobile communication devices enable patients to capture therapy data or vital sign data for automatic transmission to a centralized clinician database. The patient may input the data directly into the personal mobile communication device, electronically receive the data from the connected machine, or record the data using a camera. The data is transferred within the medical fluid data transfer system to a database that stores the data in a patient medical record.
Additionally, the example medical fluid data transmission system provides a gateway to a clinician to enable the patient to communicate with the clinician in real-time with respect to any concerns or problems associated with medical fluid delivery therapy. In some embodiments, the medical fluid data transmission system also provides the patient with access to educational or training materials. As such, the example medical fluid data transmission system is configured to connect a patient to assistance that is needed or requested to maintain participation in and/or compliance with a therapy.
The medical fluid data transfer systems and methodologies of the present disclosure may be applied to fluid delivery such as plasma removal, hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF") and continuous renal replacement therapy ("CRRT") therapy. The medical fluid data transfer systems described herein are also suitable for peritoneal dialysis ("PD"), intravenous drug delivery, and nutrient fluid delivery. These modalities may be referred to herein collectively or generally individually as medical fluid delivery or treatment.
The above-described manner may be provided by a medical fluid conveyor that houses components required to convey medical fluids, such as one or more pumps, valves, heaters (if desired), on-line medical fluid generating devices (if desired), sensors (such as one or more or all of pressure sensors, conductivity sensors, temperature sensors, air detectors, blood leak detectors, etc.), user interfaces, and control units that may employ one or more processors and memories to control the above-described devices. The medical fluid conveyor may also include one or more filters, such as dialyzers or hemofilters for cleaning blood and/or ultrafilters for purifying water, dialysate or other fluids.
The medical fluid conveyor and medical fluid data transmission systems and methods described herein may be used with home-based machines. For example, these systems may be used with home HD, HF or HDF machines that are operated at the patient's convenience. One such home system is described in U.S. patent No. 8,029,454 ("454 patent") filed on 11/4/2004, published 4/10/2011 and assigned to the assignee of the present application. Other such household systems are described in U.S. patent No. 8,393,690 ("690 patent") filed on 8.27 of 2008 and published on 12 of 3.2013 under the name "Enclosure for a Portable Hemodialysis System". The entire contents of each of the above references are incorporated herein by reference.
As described in detail below, the medical fluid data transmission systems and methods of the present disclosure may operate within an inclusive platform system that includes a plurality of machines, including many different types of devices, patients, clinicians, doctors, service personnel, electronic medical record ("EMR") databases, websites, resource planning systems that process data generated via patient and clinician communications, and business intelligence. The medical fluid data transmission system and method of the present disclosure operates seamlessly throughout the system and does not violate its rules and protocols.
Technical proposal
In view of the disclosure herein and without limiting the disclosure in any way, in a first aspect of the disclosure, it may be combined with any other aspect listed herein unless otherwise specified, a machine accessible device having instructions stored thereon that are configured to, when executed, cause a machine to fill out a patient medical record of a clinical system by operating a camera to record an image, operating a display interface, operating a connection interface configured to connect to a clinician database configured to store the patient medical record, and operating a processor to obtain medical information. The processor is operated to obtain medical information by displaying, via the display interface, a user interface having fields to be filled in with medical information, and upon selection of a data field of the user interface, graphically providing, via the display interface, a first option to enter medical information from an image and a second option to enter medical information via text entry. If the first option is selected, the processor receives a recorded image from the camera, the recorded image comprising a medical device or a screen of a medical device, extracts text from the image, enables selection of at least a portion of text from the image via the display interface, and writes the text selected from the image as the medical information in a data field of the user interface. If the second option is selected, the processor enables text entry of the data field as medical information via the display interface. The processor is also operative to obtain medical information by transferring the medical information written to the data fields to a patient history stored in the clinician database after receiving a send instruction.
According to a second aspect of the disclosure, which may be used in combination with any other aspect set forth herein unless otherwise specified, the machine accessible device further comprises instructions stored on the device that are configured, when executed, to cause the machine to operate the processor to determine a data template for extracted text on the image, process the extracted text using the data template to group the extracted text into fields, and enable selection of at least one of the fields to write text selected from the image to the data field of the user interface.
According to a third aspect of the present disclosure, which may be used in combination with any other aspect listed herein, unless otherwise specified, the data template is configured to specify a context for the extracted text in relation to a text position within the image.
According to a fourth aspect of the disclosure, which may be used in combination with any other aspect set forth herein unless otherwise specified, the machine accessible device further comprises instructions stored on the device that are configured, when executed, to cause the machine to operate the processor to determine the data template based on at least one of (i) a medical device type selected via the user interface, (ii) information scanned from an identifier located on the medical device, and (iii) a tag within the extracted text, or (iv) a relative layout of the extracted text.
According to a fifth aspect of the present disclosure, which may be used in combination with any other aspect set forth herein unless otherwise specified, the identifier located on the medical device includes at least one of a quick response ("QR") code, a bar code, a serial number, or a hardware number located on a housing of the medical device or on a screen of the medical device.
According to a sixth aspect of the present disclosure, which may be used in combination with any other aspect set forth herein unless otherwise indicated, the medical device includes at least a renal failure therapy machine, an infusion pump, an oxygen sensor, a respiratory monitor, a blood glucose meter, a blood pressure monitor, an ECG monitor, a weight scale, and a heart rate monitor.
According to a seventh aspect of the present disclosure, which may be used in combination with any other aspect listed herein unless otherwise indicated, the data field of the user interface is configured to receive at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual exchange data, subjective data, or consumable related consumption data.
According to an eighth aspect of the present disclosure, which may be used in combination with any other aspect set forth herein unless otherwise indicated, the consumable includes at least one of a filter, a blood line set, a dialysate concentrate container, a blood anticoagulant container, a drug container, a disposable cartridge, a sorbent cartridge, and a clean water container.
According to a ninth aspect of the present disclosure, unless otherwise indicated, it may be used in combination with any other aspect set forth herein, the machine being a personal mobile communications device.
According to a tenth aspect of the present disclosure, which may be used in combination with any other aspect set forth herein unless otherwise specified, a method for filling out a patient medical record of a clinical database using recorded images includes transmitting a first message to a personal device prompting a patient to record a first image of a medical device using a camera of the personal device, and receiving the first image from the personal device. The method includes determining, via a processor, first medical information indicating a type or model of the medical device from the first image, determining, via the processor, a data template and a second message associated with the type or model determined by the medical device, and transmitting, via the processor, the second message to the personal device prompting the patient to record a second image of a screen of the medical device using the camera. The method further includes receiving, via the processor, the second image from the personal device, extracting, via the processor, text from the second image, and processing, via the processor, the extracted text using the data template to group the extracted text into fields. The method further includes writing, via the processor, at least some text in at least one field to the patient medical record.
According to an eleventh aspect of the present disclosure, which may be used in combination with any other aspect set forth herein unless otherwise indicated, the method further comprises determining, via the processor, a correspondence between one of the fields and a record field in the patient medical record, and writing, via the processor, at least some text from the field to the record field in the patient medical record.
According to a twelfth aspect of the present disclosure, which may be used in combination with any of the other aspects set forth herein unless otherwise indicated, the method further includes determining, via the processor, a treatment time from the patient medical record, and transmitting, via the processor, the first message prior to the treatment time.
According to a thirteenth aspect of the present disclosure, which may be used in combination with any other aspect set forth herein unless otherwise indicated, the method further comprises receiving, in the processor, a treatment message from the personal device indicating that the patient is to begin treatment, and transmitting the first message via the processor prior to beginning treatment.
According to a fourteenth aspect of the present disclosure, which may be used in combination with any other aspect set forth herein, unless otherwise specified, the first image is received in the processor via a first text message or a first short message service ("SMS") message, and the second image is received in the processor via a second text message or a second SMS message.
According to a fifteenth aspect of the present disclosure, which may be used in combination with any other aspect listed herein unless otherwise indicated, the method further comprises converting, via the processor, at least some text from at least one field to a Health-Level-7 ("HL 7") format prior to writing the patient medical record.
According to a sixteenth aspect of the present disclosure, which may be used in combination with any other aspect set forth herein unless otherwise indicated, the method further comprises comparing, via the processor, at least some text from at least one field to a predetermined range, and writing, via the processor, at least some text from at least one field if the at least some text from the at least one field is within the predetermined range.
According to a seventeenth aspect of the present disclosure, which may be used in combination with any of the other aspects set forth herein unless otherwise specified, a system for communicating information to a patient includes a home therapeutic apparatus of a patient configured to communicate therapeutic information, and a clinician database configured to store medical records and registration files identifying the home therapeutic apparatus and a personal device of the patient as registered devices, and identifying whether the personal device has installed an application for viewing the therapeutic information and the medical information. The system also includes a clinician server communicatively coupled to the clinician database, the home treatment instrument, and the personal device. The clinician server is configured to store the therapy information and the medical information into the medical record, receive an indication that at least some of the therapy information and the medical information are to be displayed on the personal device, and determine from the registration file whether the application is installed on the personal device. If the application is installed, the clinician server is configured to convert at least some of the therapy information and the medical information into an application format for display within the application, and to send the converted at least some of the therapy information and medical information to the personal device. If the application is not installed, the clinician server is configured to convert at least some of the therapy information and the medical information to a text message or short message service ("SMS") format and to send the converted at least some of the therapy information and medical information to the personal device via one or more text messages or SMS messages.
According to an eighteenth aspect of the present disclosure, unless otherwise indicated, it may be used in combination with any of the other aspects set forth herein, the application format including at least one of an extensible markup language ("XML") format or a hypertext markup language ("HTML") format.
According to a nineteenth aspect of the present disclosure, which may be used in combination with any other aspect listed herein unless otherwise indicated, the indication that at least some of the treatment information and the medical information are to be displayed on the personal device includes at least one of a message from the application or a text/SMS message from the personal device.
According to a twentieth aspect of the present disclosure, the registration file is included within the medical record, unless otherwise indicated, as may be used in combination with any of the other aspects listed herein.
According to a twenty-first aspect of the present disclosure, which may be used in combination with any other aspect set forth herein unless otherwise specified, the home therapeutic apparatus is configured to store a recipe having two programs, each program providing parameters for operating the home therapeutic apparatus to perform a treatment, and the clinician server is configured to receive a program message from the personal device indicating a change from a first program to a second program, and to send program instructions to the home therapeutic apparatus to change from the first program to the second program.
In a twenty-second aspect of the present disclosure, any of the structures and functions disclosed in connection with fig. 1-33 may be combined with any of the other structures and functions disclosed in connection with fig. 1-33.
Advantageous effects
In view of the present disclosure and the above, it is therefore an advantage of the present disclosure to provide an improved medical fluid delivery system.
Another advantage of the present disclosure is to provide improved patient lifestyle.
Another advantage of the present disclosure is to provide improved clinician or caregiver efficiency.
Another advantage of the present disclosure is to provide improved machine efficiency.
Yet another advantage of the present disclosure is to provide improved patient compliance.
Another advantage of the present disclosure is to provide a medical fluid data transmission system and method that may be applied to different types of medical fluid conveyors.
It is yet another advantage of the present disclosure to provide a medical fluid data transmission system and method that enables communication between a medical fluid conveyor and multiple persons, such as a patient and clinician or a patient and primary care provider.
Further, an advantage of the present disclosure is to reduce waste of disposable kits and other auxiliary soft goods due to discarding that typically occurs upon expiration of a machine timer.
Advantages discussed herein may be found in one or some, perhaps not all, of the embodiments disclosed herein. Additional features and advantages are described herein, and will be apparent from, the following detailed description and the accompanying drawings.
Drawings
Fig. 1 is a schematic diagram illustrating one embodiment for a medical fluid data transmission system incorporating a medical fluid conveyor of the present disclosure such that data may be transmitted between the machines, according to an embodiment of the present disclosure.
Fig. 2 is a schematic view of one embodiment of a medical fluid conveyor of the present disclosure.
Fig. 3 is a perspective view illustrating a blood set for use with one embodiment of the medical fluid conveyor of fig. 2, according to an embodiment of the present disclosure.
Fig. 4 is a schematic diagram of one embodiment of a medical fluid conveyor and data transmission system and method of the present disclosure.
Fig. 5 is a schematic diagram of a second embodiment of the medical fluid conveyor and data transmission system and method of the present disclosure.
Fig. 6 is a schematic diagram of a third embodiment of a medical fluid conveyor and data transmission system and method of the present disclosure.
Fig. 7 is a schematic diagram of one embodiment of a hospital or clinical version of the medical fluid delivery device and data transmission system and method of the present invention with a mobile communication device application in a first state.
Fig. 8 is a schematic diagram of one embodiment of a hospital or clinical version of the medical fluid delivery device and data transmission system and method of the present invention with a mobile communication device application in a second state.
Fig. 9 is a schematic diagram of one embodiment of a hospital or clinical version of the medical fluid delivery device of the present disclosure and data transmission systems and methods with a mobile communication device application in a third state.
Fig. 10 shows a second embodiment of a medical fluid data transmission system.
Fig. 11 shows a diagram illustrating an operational module of an application at a clinician server of the medical fluid data transmission system of fig. 10, in accordance with an embodiment of the present disclosure.
Fig. 12 shows a diagram illustrating communications between the home treatment apparatus, the personal mobile communication device, and the clinician server of fig. 10 and 11, according to an example embodiment of the present disclosure.
Fig. 13 illustrates an example patient data structure stored on a clinician database of the medical fluid data transmission system of fig. 10, according to an example embodiment of the present disclosure.
Fig. 14 and 15 show diagrams illustrating a user interface of the application of fig. 11, according to an example embodiment of the present disclosure.
Fig. 16 is a schematic diagram of the personal mobile communication device of fig. 10 and 11 in accordance with an example embodiment of the present disclosure.
Fig. 17 shows a schematic diagram of a data template according to an example embodiment of the present disclosure.
Fig. 18 shows a diagram illustrating writing of data fields of the user interface of fig. 14, according to an example embodiment of the present disclosure.
Fig. 19 is a flowchart of an example process for inputting medical information from an image using an application of the personal mobile communication device of fig. 10 and 11, according to an example embodiment of the present disclosure.
Fig. 20 illustrates an example of a user interface that may be displayed by an application on the personal mobile communication device of fig. 10 and 11 to enable a patient to provide recorded images, according to an example embodiment of the present disclosure.
Fig. 21 shows a schematic diagram of a patient medical template used by the clinician server of fig. 10 and 11 to populate data fields of a patient's medical record, according to an example embodiment of the present disclosure.
Fig. 22 is a schematic diagram of a data acquisition module of the clinician server of fig. 11, according to an example embodiment of the present disclosure.
Fig. 23 and 24 are flowcharts of example processes for filling out the medical device template of fig. 21 using images recorded by the personal mobile communication devices of fig. 10 and 11 (and/or text messages received from the personal mobile communication devices of fig. 10 and 11) in accordance with example embodiments of the present disclosure.
Fig. 25 shows a diagram of a clinician server hosting a website or file transfer site to receive medical information via images from the personal mobile communication device of fig. 10 and 11, according to an example embodiment of the present disclosure.
Fig. 26-29 illustrate diagrams of personal mobile communication devices displaying medical information provided by the clinician server of fig. 10 and 11, according to example embodiments of the present disclosure.
Fig. 30 illustrates a diagram of the personal mobile communication device of fig. 10 and 11 prompting a patient to enter medical information, according to an example embodiment of the present disclosure.
Fig. 31 shows a diagram of the personal mobile communication device of fig. 10 and 11 providing a patient with a procedure selected for medical treatment, according to an example embodiment of the present disclosure.
Fig. 32 illustrates a diagram of the personal mobile communication device of fig. 10 and 11 providing educational content to a patient, in accordance with an example embodiment of the present disclosure.
Fig. 33 illustrates a diagram of the personal mobile communication device of fig. 10 and 11 providing a video chat session between a patient and a clinician, in accordance with an example embodiment of the present disclosure.
Detailed Description
Medical fluid delivery systems are disclosed herein. An example medical fluid delivery system is configured to improve patient participation in medical treatment, such as medical fluid delivery therapy. The medical fluid delivery system is configured to provide patients with more transparency regarding their treatment and at least some control to guide their treatment while providing resources to educate or otherwise assist the patient throughout the treatment. An example medical fluid delivery system is configured to provide patient participation regardless of the type or set of functional components of a medical device associated with a patient's treatment or personal mobile communication device. Such a configuration makes the disclosed medical fluid delivery system compatible with virtually any patient situation.
In some embodiments, a medical fluid delivery system includes a personal mobile communication device, a medical fluid delivery machine, and a clinician server/database. The example personal mobile communication device and medical fluid delivery machine are located in a patient's home and/or in a self-service medical facility. The clinician server is communicatively coupled to the personal mobile communication device and/or the medical fluid delivery machine via a wide area network (i.e., the internet). The clinician server is configured as a hub that enables the personal mobile communication device to provide functionality designed for patient participation in medical fluid delivery therapy.
As disclosed herein, the example clinician server receives medical fluid delivery data (e.g., therapy information) from a medical fluid delivery machine, which is stored in one or more patient records in a clinician database. The clinician server provides access to the medical fluid delivery data for the personal mobile communication device to enable the patient to track the progress of the treatment. In addition, the patient may use the personal mobile communication device to change the treatment program (or request a change in the treatment program). The request is sent through a clinician server to verify that the change is appropriate before being transmitted to the medical fluid delivery machine.
The example clinician server operates in conjunction with a personal mobile communication device to enable a patient to easily provide medical information, such as vital sign data, medical device data, and the like. The personal mobile communication device is configured to enable the patient to manually input data, record pictures including data, and/or wirelessly receive data from a connected medical device (such as a weight scale, blood pressure monitor, thermometer, blood glucose meter, etc.). The collected data is stored in a medical record of the patient. In some embodiments, the clinician server and/or personal mobile communication device can use templates to determine how to automatically fill in the received data into the patient's medical record.
As disclosed herein, a personal mobile communication device may include a rich-function smart device, such as a smart phone or tablet. The smart device may operate a dedicated application (e.g., an "app") defined by instructions stored in memory. Execution of the stored instructions may cause the smart device to run a process of the application configured to increase patient engagement with the medical treatment. In some cases, the personal mobile communication device may include a reduced functionality traditional cellular telephone that includes significantly less processing power and functionality than the smart device. The cellular device may operate using text messages and/or a dedicated application (e.g., app) defined by instructions stored in memory. Applications for reduced functionality devices may have fewer functions than applications for smart devices.
The following disclosure is divided into two parts. The first section discloses embodiments of a medical fluid delivery system. The second section discloses features that enable the medical fluid delivery system to increase patient engagement and/or compliance with the medical treatment.
I. medical fluid delivery system embodiments
An example medical fluid delivery system includes one or more medical fluid conveyors. An example of a medical fluid conveyor is a renal failure therapy device. With respect to renal failure therapies, the patient's renal system may fail for a variety of reasons. Renal failure can cause several physiological abnormalities. It is no longer possible to balance water and minerals or to excrete daily metabolic loads. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, etc.) accumulate in blood and tissues.
Renal failure and reduced renal function are treated by dialysis. Dialysis can remove waste, toxins and excess water from the body that would otherwise be removed by a properly functioning kidney. Dialysis therapy to replace kidney function is critical to many people because such therapy can save lives.
One type of renal failure treatment is hemodialysis ("HD"), which typically uses diffusion to remove waste products from the patient's blood. A diffusion gradient occurs across the semipermeable dialyzer between the blood and the electrolyte solution, called dialysate, causing diffusion.
Hemofiltration ("HF") is an alternative renal replacement therapy that relies on convective transport of toxins in the patient's blood. HF is achieved by adding a replacement fluid or replacement fluid (typically 10 to 90 liters of such fluid) to the extracorporeal circuit during treatment. During HF treatment, ultrafiltration is performed on the substitution fluid and the fluid that the patient has accumulated in the middle of the treatment, providing a convective transport mechanism that is particularly advantageous for removing medium and macromolecules (in hemodialysis, small amounts of waste are removed and the fluid is obtained between dialysis processes, but the solute resistance to removing the ultrafiltrate is insufficient to provide convective clearance).
Hemodiafiltration ("HDF") is a treatment that combines convective and diffusive clearance. HDF uses dialysate (similar to standard hemodialysis) flowing through a dialyzer to provide diffusion clearance. Additionally, the substitution solution is provided directly to the extracorporeal circuit, providing convective clearance.
Most HD (HF, HDF) treatments occur centrally. Today, there is a trend for home hemodialysis ("HHD"), in part because HHD can be performed daily, which has therapeutic advantages over central hemodialysis treatments, which are typically performed once every two or three weeks. Studies have shown that frequent treatment can clear more toxins and waste than patients receiving less frequent but possibly longer treatments. Patients receiving treatment more frequently do not experience as many cycles of decline than patients receiving treatment at the center, who had accumulated toxins for two to three days prior to treatment. In some areas, the nearest dialysis center may be several miles away from the patient's home, resulting in a gate-on treatment time consuming a significant portion of the day. HHD may occur during the daytime when the patient is resting, working or otherwise engaged in production.
Another treatment for renal failure is peritoneal dialysis, which infuses a dialysis solution (also called dialysate) into the peritoneal cavity of a patient via a catheter. The dialysate contacts the peritoneum of the peritoneal cavity. Due to diffusion and osmosis, waste, toxins and excess water flow from the patient's blood through the peritoneum and into the dialysate, i.e., an osmotic gradient occurs across the membrane. The osmotic agent in dialysis provides an osmotic gradient. The spent or spent dialysate is drained from the patient and waste, toxins and excess water are removed from the patient. For example, repeating the cycle a plurality of times.
There are various types of peritoneal dialysis treatments, including continuous ambulatory peritoneal dialysis ("CAPD"), automated peritoneal dialysis ("APD"), tidal flow dialysis, and continuous flow peritoneal dialysis ("CFPD"). CAPD is a manual dialysis treatment. Here, the patient manually connects the implanted catheter to the drain tube to allow the used or spent dialysate to drain from the peritoneal cavity. The patient then connects the catheter to a fresh bag of dialysate to infuse the fresh dialysate into the patient through the catheter. The patient disconnects the catheter from the fresh dialysate bag and the dialysate is retained in the peritoneal cavity where the transfer of waste, toxins and excess water takes place. After a period of stay, the patient repeats the manual dialysis procedure, for example four times a day, each treatment lasting about one hour. Manual peritoneal dialysis requires a great deal of time and effort from the patient, and there is room for improvement.
Automated peritoneal dialysis ("APD") is similar to CAPD in that dialysis treatment includes drainage, fill and dwell cycles. APD machines typically perform cycles automatically when the patient falls asleep. APD machines eliminate the need for the patient to manually perform a treatment cycle, nor to transport supplies during the day. The APD machine is fluidly connected to an implanted catheter, a source or bag of fresh dialysate, and a drain. The APD machine pumps fresh dialysate from a dialysate source through a catheter to the patient's peritoneal cavity. APD machines also allow dialysate to reside within the chamber and transfer waste, toxins, and excess water. The source may include a plurality of sterile dialysate bags.
APD machines pump spent or spent dialysate from the peritoneal cavity through a catheter to a drain tube. As with the manual process, several drain, fill and dwell cycles occur during dialysis. The "last fill" occurs at the end of the APD and remains in the patient's peritoneal cavity until the next treatment is performed.
Any of the above-described manners performed by the machine may be scheduled to operate and may require a start-up procedure. For example, dialysis patients are typically treated on a schedule, such as every other day, daily, etc. Blood treatment apparatus typically require some time to set up, such as running a sterilization process, before treatment. Patients receiving the above-described regimen may go through a busy life, and an item to be performed or a task scheduled to be completed on the day of treatment.
Most of the attractiveness of home treatment to a patient is around the flexibility of lifestyle afforded by allowing the patient to perform treatment in his or her home largely on his own schedule. However, the home medical fluid delivery machine may include a software timer that indicates and constrains the user or patient. Home hemodialysis systems may, for example, require that the patient be in close proximity to the home hemodialysis machine to initiate a pre-treatment, during-treatment, and post-treatment sequence.
In one particular example, a home treatment instrument may reuse certain components by sterilizing them between treatments. The machine may employ one or more sterilization timers that require the patient or caregiver to begin treatment using the machine before the sterilization timer expires. Otherwise, the patient will have to wait until another sterilization procedure is completed before starting the treatment. In an embodiment, the home treatment instrument communicates a treatment start time period via a graphical user interface of the machine, which requires the patient to access the machine to access the start time period and respond accordingly.
It should be understood that the present disclosure is applicable to any type of sterilization, such as hot water sterilization and chemical sterilization. In this regard, the present disclosure is not limited to home treatment devices, e.g., machines in the center are typically chemically sterilized and a treatment initiation time period may be set after such sterilization. Furthermore, the present disclosure is not limited to a start time period based on disinfection, but may also be applied to other start time periods, such as a start time period based on completion of perfusion. Still further, the present disclosure is not limited to an initial start time period. For example, most machines will allow the patient to temporarily stop the treatment and disconnect from the machine to perform some type of necessary action away from the machine. For blood treatment, the machine will typically flush blood back to the patient and may or may not circulate dialysate over a period of time. In either case, the time that the patient can temporarily disconnect from the machine is not infinite, and it is contemplated that the present disclosure is also applicable to return time limits.
In one embodiment, the system of the present disclosure provides a software application ("app") installed on a personal mobile communication device (e.g., a smart phone) of a patient and/or caregiver. In one embodiment, the app is provided via a middleware software application, examples of which are discussed in detail below. In an alternative embodiment, the software is configured to communicate with a personal mobile communication device (e.g., a smart phone) of the patient and/or caregiver directly using text messaging functionality through a middleware software application. In either case, in one embodiment, the app or text message is structured to alert the patient to any upcoming deadlines and allow the patient and/or caregiver to track when treatment needs to begin without tying the patient to the machine.
It is contemplated that communication software may alternatively or additionally be structured to automatically program reminders on a user's mobile communication device, for example, on a device's native task tracking function (such as a calendar application). Most smartphones are equipped with a calendar that divides each day into a plurality of time periods, such as hours. The software of the disclosed systems and methods may be programmed to access the smartphone calendar of the authorized patient and/or caregiver and fill in the appropriate time period of the appropriate day with the appropriate information, e.g., during which the machine should begin or complete sterilization.
In one embodiment, communications from the software systems and methods of the present disclosure are unidirectional. For example, the communication may be a mobile communication device from a medical fluid conveyor (possibly a home machine) to a patient or caregiver. In alternative embodiments, the software systems and methods of the present disclosure enable two-way communication between a medical fluid conveyor and a mobile communication device of a patient or caregiver. In one example, two-way communication may allow a patient or caregiver to remotely initiate certain machine routines using their mobile communication device. One example routine is an automated self-checking routine that can be performed without any user interaction with the system other than initializing or starting up the sequence. The remote start sequence may benefit the patient or caregiver, for example, by providing additional time for the patient or caregiver to perform other tasks remote from the machine. When the machine initiates a communication by indicating that the machine is ready to perform a self-test routine, the communication becomes bi-directional. The patient or caregiver responds to the machine at the desired time via the software system and method of the present disclosure to initialize the sequence.
For the software of the disclosed systems and methods, it is contemplated that communication between the patient and/or caregiver and the machine is inhibited as long as the machine is in a "patient connected" software state. For example, if a clinician attempts to send a command to a machine that is currently treating a patient, the command may be intercepted by the middleware software application so that the command is not transmitted to the machine. The middleware software application may then return a clinician that the machine is busy and not accepting communications.
The examples described herein are applicable to any medical fluid delivery system that delivers medical fluids such as blood, dialysate, replacement fluid, or/and intravenous ("IV") drugs. These examples are particularly suitable for renal failure treatment, such as all forms of hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF"), continuous renal replacement therapy ("CRRT"), and peritoneal dialysis ("PD"), collectively or generally referred to herein above as renal failure treatment. The medical fluid conveyor may alternatively be a drug delivery or nutritional fluid delivery device, such as a peristaltic pump or syringe pump of the high volume type. The machine described herein may be used in a home setting. For example, a machine operating with the data transmission scheme of the present disclosure may be used with a home HD machine that may be operated, for example, at night when the patient sleeps. The medical fluid data transmission systems and methods of the present disclosure may alternatively be used to assist a clinician or nurse in a hospital and/or clinic.
Referring now to the drawings, and in particular to FIG. 1, a medical fluid data transmission system 10 is shown operating within a medical fluid conveyor 90. The system 10 includes a number of medical fluid conveyors 90 (one of which will be discussed in detail below). The machines 90 of the data transmission system 10 may be of the same type (e.g., all HD machines) or of different types (e.g., HD, PD, CRRT and a mix of medical or nutritional fluid delivery).
Although a single medical fluid delivery device 90 is shown in communication with the connection server 118, the system 10 oversees the operation of multiple medical fluid delivery systems and machines of the same type or different types listed above. For example, there may be M hemodialysis machines 90, N hemofilters 90, O CRRT machines 90, P peritoneal dialysis machines 90, Q home drug delivery machines 90, R nutrition or drug delivery machines 90 connected to the server 118 and operating with the system 10. The numbers M to R may be the same or different numbers, and may be 0,1 or greater than 1. In fig. 1, the medical fluid delivery machine 90 is shown as a home treatment device 90 (home indicated by dashed lines).
The home treatment apparatus 90 may receive purified water from the water treatment device 60 as described above at its front end. In one embodiment, the water treatment apparatus 60 is connected to the home treatment device 90 via an ethernet cable. The home treatment apparatus 90 in the illustrated embodiment operates with other devices in addition to the water treatment apparatus 60, such as a blood pressure monitor 104, a weight scale (e.g., wireless weight scale 106), and a user interface, such as a wireless tablet user interface 122. In one embodiment, home treatment device 90 is wirelessly connected to server 118 via modem 102. Each of these components may (but need not) be located in the patient's home, as shown by the dashed lines in fig. 1. Any one or more or all of the components 60, 104, 106, and 122 may be in wired or wireless communication with the home treatment device 90. The wireless communication may be via BluetoothTM, wiFiTM, zigbee, Z-Wave, wireless universal serial bus ("USB"), infrared, or any other suitable wireless communication technology. Alternatively, any one or more or all of components 60, 104, 106, and 122 may communicate with home treatment device 90 via wired communications.
The connection server 118 communicates with the medical fluid delivery machine 90 via the medical device system hub 120. The system hub 120 enables data and information about each home treatment device 90 and its peripherals to travel back and forth between the machine 90 and other clients connected to the server 118 via the connection server 118. In the illustrated embodiment, the system hub 120 is connected to a service portal 130, an enterprise resource planning system 140, a Web portal 150, a business intelligence portal 160, a HIPAA compliant database 124, a product development team 128, and an electronic medical record database maintained, for example, at clinics or hospitals 126 a-126 n.
An electronic medical record ("EMR") database at the clinics or hospitals 126 a-126 n stores electronic information about patients. The system hub 120 can send data collected from the log files of the machine 90 to the hospital or clinic databases 126 a-126 n to consolidate or supplement the patient's medical records. The databases of clinics or hospitals 126 a-126 n may contain patient-specific treatment and prescription data, and thus access to such databases may be severely restricted. Enterprise resource planning system 140 obtains and compiles data generated via patient and clinician web site access, such as complaints, billing information, and lifecycle management information. The Web portal 150 enables patient and patient-treated clinics 152 a-152 h to access Web sites that are publicly available to users of the medical fluid delivery machine 90. The business intelligence portal 160 gathers data from the system hub 120 and provides the data to marketing 162, research and development 164, and quality/medication alert 166.
It will be appreciated that the systems, methods, and processes described herein may be implemented using one or more computer programs or components. The program of components may be provided as a series of computer instructions on any conventional computer readable medium, including random access memory ("RAM"), read only memory ("ROM"), flash memory, magnetic or optical disk, optical storage or other storage medium, the instructions being configured to be executed by a processor that, when executed, performs or facilitates execution of all or part of the disclosed methods and processes.
In one embodiment, home therapeutic apparatus 90 performs home treatment, such as home hemodialysis of a patient at the patient's home, and then reports the results of the treatment to the clinician, doctor, and nurse responsible for managing the patient's health and well-being.
In one embodiment, home treatment device 90 uses, for example, a Linux TM operating system to write the log file. The log file records data, including peripheral data, for the associated home treatment device 90. The log files may include any one or more of extensible markup language ("XML"), comma separated value ("CSV"), or text files. The log file is placed in a file server box of the software of the home treatment device 90. It is also contemplated that data not sent to the machine 90 may be stored at a peripheral device (e.g., the water treatment device 60). Such data may be obtained in other ways via wired or wireless connections to the peripheral device, or may be downloaded via other data connections or storage media. For example, the attendant may access the additional data via a laptop computer connected to the water treatment apparatus 60 or the wireless weight scale 106, for example via an ethernet connection. Or additional data may be retrieved remotely from the peripheral device using the home treatment device 90 as a data transfer contact between the peripheral device and an authorized client of the medical fluid data transfer system.
In one embodiment, home treatment device 90 uses a connectivity service to transfer data between modem 102 and system hub 120, for example, via the internet. Here, a dedicated line may be provided at each patient's home for connecting the home therapeutic apparatus 90 to the connection server 118 via the modem 102. In one embodiment, home treatment device 90 uses a separate, e.g., 3G, 4G, or 5G modem 102 to access the internet. Modem 102 may use an internet service provider ("ISP") such as Vodafone TM. In one embodiment, a connection agent 114 developed by a connection service provider (e.g., the provider of connection server 118) is installed onto home treatment device 90 and runs on the ACPU 50 of the machine. A suitable connection service is provided by AxedaTM that provides a secure management connection 116 between the medical device and the connection server 118.
The connection agent 114 allows the home treatment device 90 to connect to the connection server 118 and to communicate data to and from the connection server 118. The connection service, which operates via agent 114 and server 118, ensures that the connection with machine 90 is secure, that the data properly passes through the firewall of machine 90, that it checks if there is data or a system crash, and that connection server 118 is communicating with the proper home therapeutic apparatus 90.
In one embodiment, the home treatment device 90 may connect to the connection server 118 only when the connection agent 114 is turned on or activated. During treatment and post-treatment sterilization, while machine 90 and its peripherals are functioning properly, in one embodiment, connection agent 114 is closed, preventing home treatment device 90 from communicating with any entity and preventing data from being sent or received during treatment and sterilization or while machine 90 is running or running. In one embodiment, ACPU 50 opens connection agent 114 when home therapeutic apparatus 90 is idle, e.g., after treatment and disinfection is completed. In an embodiment, the connection broker 114 is shut down during treatment and possibly during pre-treatment. After treatment, the connection agent 114 retrieves the log file from the home treatment device 90 and transmits the data to the connection server 118 using the connection service. In one embodiment, the connection service routes the data packets to their appropriate destination, but does not modify, access, or encrypt the data.
In the medical fluid data transmission system 10 system of fig. 1, a connection service via the connection server 118 may transfer data to various places via a system hub 120 such as a service portal 130, clinics or hospitals 126 a-126 n, and a Web portal 150. Connection server 118 allows service personnel 132a through 132h and/or clinicians to track and retrieve various assets, such as the appropriate home therapeutic device 90 and 3G, 4G or 5G modems 102, and their associated information, including machine or modem serial numbers, through the network. Connection server 118 may also be used to receive firmware upgrades approved by a supervisor of service personnel 134 and obtained remotely via service portal 130 and provide them to authorized home treatment devices 90 and related peripheral devices, such as water treatment device 60.
A. Example medical fluid conveyor
Referring now to fig. 2, an example of an HD flow schematic for a medical fluid conveyor 90 is shown. Because the HD system of fig. 2 is relatively complex, fig. 2 and its discussion also provide support for any of the renal failure therapy regimens discussed above, as well as IV, drug delivery, or nutrient fluid delivery. Generally, the illustrated medical fluid delivery machine 90 has a simplified form of dialysate or process fluid delivery circuit. The blood circuit is also simplified, but not to the extent that the dialysate circuit is simplified. It should be appreciated that the loops have been simplified to facilitate the description of the present disclosure, and if the system is implemented, will have additional structure and functionality such as found in the publications incorporated by reference above.
The medical fluid delivery machine 90 of fig. 2 includes a blood circuit 20. The blood circuit 20 draws blood from the patient 12 and returns the blood to the patient 12. Blood is drawn from the patient 12 via arterial line 14 and returned to the patient via venous line 16. Arterial line 14 includes arterial line connector 14a connected to arterial needle 14b, which arterial needle 14b is connected to the patient 12 for blood collection. The intravenous line 16 includes an intravenous line connector 16a connected to an intravenous needle 16b, the intravenous needle 16b being in return communication with the patient's blood. The arterial and venous lines 14 and 16 also include line clamps 18a and 18v, which may be spring loaded fail safe mechanical compression clamps. In one embodiment, the line clamps 18a and 18v are automatically closed in the event of an emergency.
The arterial and venous lines 14 and 16 also include air or bubble detectors 22a and 22v, respectively, which may be ultrasonic air detectors. Air or bubble detectors 22a and 22v look for air in arterial and venous lines 14 and 16, respectively. If one of the air detectors 22a and 22v detects air, the system 10 closes the line clamps 18a and 18v, pauses the blood pump and the dialysate pump, and provides instructions to the patient to purge the air in order to resume treatment.
In the illustrated embodiment, a blood pump 30 is located in the arterial line 14. In the illustrated embodiment, the blood pump 30 includes a first blood pump compartment 30a and a second blood pump compartment 30b. The blood pump compartment 30a operates with an inlet valve 32i and an outlet valve 32 o. The blood pump compartment 30b operates with an inlet valve 34i and an outlet valve 34 o. In one embodiment, blood pump chambers 30a and 30b are each blood receptacles that include a rigid housing, such as a sphere, with a flexible diaphragm within the housing, thereby forming a diaphragm pump. One side of each membrane receives blood, while the other side of each membrane is operated by negative and positive air pressure. The blood pump 30 may alternatively be a peristaltic pump operating with the arterial line 14 or a plurality of peristaltic pumps operating with the arterial line 14 and the venous line 16.
In the illustrated embodiment, heparin vial 24 and heparin pump 26 are located between blood pump 30 and blood filter 40 (e.g., dialyzer). Heparin pump 26 may be a pneumatic pump or a syringe pump (e.g., a stepper motor driven syringe pump). Providing heparin upstream of the blood filter 40 helps prevent clotting of the filter membrane.
A master control processor ("ACPU") or control unit 50 includes one or more processors and memory. The control unit 50 receives air detection signals from the air detectors 22a and 22v (and other sensors of the system 10 such as temperature sensors, blood leak detectors, conductivity sensors, pressure sensors, and on-off transducers 86, 88) and controls components such as the line clamps 18a and 18v, the blood pump 30, the heparin pump 26, the dialysate pumps 64 and 96, and the valves 32i, 32o, 34i, 34o, 68i, 68o, 98i, and 98 o. Blood exiting the blood filter 40 via the venous line 16 flows through the air trap 28. The air trap 28 removes air from the blood before the dialyzed blood is returned to the patient 12 via the venous line 16.
For the hemodialysis version of the medical fluid delivery machine 90 of fig. 2, dialysate is pumped along the exterior of the membrane of the hemofilter 40, while blood is pumped through the interior of the hemofilter membrane. The dialysate is first prepared by purifying water via the water purification unit 60. One suitable water purification unit is set forth in U.S. patent publication No.2011/0197971 entitled "water purification System and method" filed on month 4 and 25 of 2011, the entire contents of which are incorporated herein by reference. In one example, the water purification unit includes filters and other structures to purify tap water (e.g., remove pathogens and ions, such as chlorine) such that in one embodiment, the water has endotoxin units below 0.03 milliliters ("EU/ml") and colony forming units below 0.1 ml ("CFU/ml"). The water purification unit 60 may be provided in a housing separate from the housing or chassis of the hemodialysis machine 90, which includes the blood circuit 20 and the dialysate circuit 70.
The dialysate circuit 70 is again highly simplified in fig. 2 to simplify the illustration. In fact, the dialysate circuit 70 can include all of the relevant structures and functions set forth in the publications incorporated by reference above. Certain features of the dialysate circuit 70 are shown in fig. 2. In the illustrated embodiment, the dialysate circuit 70 includes a hemofilter dialysate pump 64. In one embodiment, pump 64 is configured the same as blood pump 30. Like pump 30, pump 64 includes a pair of pump chambers 66, each having an inlet valve 68i and an outlet valve 68o, which may also be spherical. Like the blood pump 30, the two pump compartments are alternately operated such that one pump compartment is filled with HD dialysate and the other pump compartment is drained of HD dialysate.
The pump 64 is a hemofilter dialysate pump. There is another double-chambered pump chamber 96 that operates with valves 98i and 98o located in the drain line 82 to push the spent dialysate out. A third compartment pump (not shown) is present for pumping pump purified water through bicarbonate box 72. A fourth cabin pump (not shown) is present for pumping acid from the acid container 74 into the mixing line 62. The third and fourth pumps, i.e. the concentrate pumps, may be single compartment pumps, since in one embodiment, continuous pumping in the mixing line 62 is not important, as there is a buffer dialysis fluid tank (not shown) between the mixing line 62 and the hemofilter dialysis fluid pump 64.
When HD therapy is provided, a fifth capsule pump (not shown) disposed in the exhaust line 82 is used to remove a known amount of ultrafiltration ("UF"). The system 10 tracks the UF pump to control and know how much ultrafiltrate has been removed from the patient. The system 10 ensures that the necessary amount of ultrafiltrate is removed from the patient at the end of the treatment.
Each of the above pumps may alternatively be peristaltic pumps working with pump tubes. If so, the system valve may still be pneumatically actuated according to features of the present disclosure.
In one embodiment, purified water from the water purification unit 60 is pumped along the mixing line 62 through the bicarbonate box 72. Acid from the container 74 is pumped along the mixing line 62 into the bicarbonate water exiting the bicarbonate cartridge 72 to form an electrolytic and physiologically compatible dialysate solution. Pumps and temperature compensated conductivity sensors for properly mixing purified water with bicarbonate and acid are not shown, but are disclosed in detail in the publications incorporated herein by reference above.
Fig. 2 also shows that the dialysate is pumped along the fresh dialysate line 76 by the heater 78 and ultrafilter 80 before reaching the hemofilter 40, after which the spent dialysate is pumped out via the drain line 82. The heater 78 heats the dialysate to body temperature or about 37 ℃. The ultrafilter 80 further purifies and purifies the dialysate, filtering foreign substances and/or contaminants introduced from the dialysate, for example, via the bicarbonate box 72 or the acid container 74, before reaching the hemofilter 40.
In the illustrated embodiment, the dialysate circuit 70 also includes a sample port 84. The dialysate circuit 70 will further include a blood leak detector (not shown, but for detecting if the fibers of the blood filter 40 are torn) and other components not shown, such as a balancing chamber, a plurality of dialysate valves, and a dialysate holding tank, all of which are described in detail and in the publications incorporated herein by reference.
In the illustrated embodiment, the medical fluid delivery machine 90 is an in-line, in-line system that pumps dialysate through the hemofilter at a time and then pumps spent dialysate for draining. After each treatment, both the blood circuit 20 and the dialysate circuit 70 can be sterilized by hot water so that the blood circuit 20 and the dialysate circuit 70 can be reused. In one embodiment, the blood circuit 20 including the hemofilter 40 is sterilized with hot water and reused for about one month each day, while the dialysate circuit 70 is sterilized with hot water and reused for about six months.
In an alternative embodiment, for example for CRRT, multiple bags of sterile dialysate or infusate are combined together and used one after the other. In this case, the emptied replenishment bag may be used as a drainage bag or a waste bag.
The medical fluid delivery machine 90 includes a housing as shown in phantom in fig. 2. The housing of the machine 90 varies depending on the type of treatment, whether the treatment is in-center or in-home, and whether the dialysate/infusate supply is intermittent (e.g., in bags) or on-line.
Fig. 3 shows that the machine 90 of fig. 2 may operate with a blood set 100. The blood set 100 includes an arterial line 14, a venous line 16, a heparin vial 24, a heparin pump 26/blood pump 30, and a blood filter 40 (e.g., a dialyzer). An air trap 28 may be located in the intravenous line 16 to remove air from the blood prior to returning the blood to the patient 12. Air detectors 22a and 22v contact arterial and venous lines 14 and 16, respectively, for operation.
In fig. 2 and 3, any one of pumps 26, 30 (30 a and 30 b), 64, 96 (and other pumps not shown) and any one of valves (such as valves 32i, 32o, 34i, 34o, 68i, 68o, 98i, and 98 o) may be pneumatically actuated. In an embodiment, each pump and valve has a fluid side and an air side separated by a flexible membrane. A negative air pressure may be applied to the air side of the membrane to draw fluid into the pump chamber or open the valve (or the pump or valve may be opened by venting the positive closing air pressure to atmosphere and allowing the fluid pressure to open). Positive air pressure is applied to the air side of the membrane to expel fluid from the pump chamber or to close the valve.
B. example connectivity embodiments of medical fluid delivery systems
Referring now to fig. 4, a system 110a of the present disclosure is shown. System 110a in the illustrated embodiment operates in conjunction with system 10 described above, including connection server 118, system hub 120, service portal 130, enterprise resource planning system 140, web portal 150, and business intelligence portal 160, which are shown in FIG. 4 as part of a cloud environment. Connection server 118, system hub 120, service portal 130, enterprise resource planning system 140, web portal 150, and business intelligence portal 160 may each be part of a cloud environment or located on one or more dedicated servers.
Other components of system 10 not shown in fig. 4 may also be part of system 110 a. For example, the medical fluid conveyors 90a and 90b may be located separately at the home (shown off-home) of the patients 12a and 12 b. Alternatively, the medical fluid conveyors 90a and 90b may be located in the same clinic 126 a-126 n or in different clinics 126 a-126 n. Clinicians 112a and 112b may be resident within the clinic or outside the clinic.
As described above, the medical fluid conveyors 90a and 90b are connected to the connection server 118 via the secure management connection 116. To this end, machines 90a and 90b are connected to Internet 52, for example, via modem 102 as described above. In one embodiment, the system hub 120 stores middleware software that is accessible by mobile communication devices 200a and 200b (collectively referred to herein as device 200 or generally referred to as device 200 alone). The mobile communication devices 200a and 200b may be smart phones running on AndroidTM、iOSTM、Windows PhoneTM、BlackBerryTM、Sailfish OSTM、TizenTM or Ubuntu Touch TM operating systems, for example. Mobile communication devices 200a and 200b may belong to patients 12a and 12b, respectively, and/or to clinicians 112a and 112b, respectively. The mobile communication devices 200a and 200b as shown in fig. 4 are also connected to the internet 52.
In one embodiment, the mobile communication devices 200a and 200b download application software ("app") from middleware software stored on the system hub 120 via their connection to the internet 52. The app is updated whenever the state of the corresponding machine 90a or 90b changes. For example, the medical fluid conveyor 90a may have just completed its auto-self-test routine and is now ready to run a sterilization process. Machine 90a may generate and send code identifying the state to middleware software stored on system hub 120. The middleware software then converts the code into a message, e.g., "self-test complete, ready for sterilization," using, for example, a look-up table, and causes the application downloaded to the patient 12a or the mobile communication device 200a of the clinician 112a to display the message. The application may be programmed to provide a visual identifier with the message, such as an icon associated with a particular state in which machine 90a is located. The application may also provide any one or more of an audio alert (such as a "stings" sound) and/or a tactile alert (such as a vibration) that prompts the patient 12a or clinician 112a to view the application and learn about the change in state of the machine 90.
In another example, the medical fluid delivery machine 90b may have been preprogrammed to begin treatment at 3:00 pm. The medical fluid conveyor 90b may take three hours to self-test and sterilize. Thus, patient l2a or clinician 112a needs to be at machine 90b before noon to begin the pretreatment. In one embodiment, patient l2a or clinician 112a makes a setting on machine 90b about how long before the three hour preparation time (e.g., 2 hours) patient 12a or clinician 112a should be notified or alerted. Thus, in this example, machine 90b may generate a code at 10:00 a.m. and send the code to middleware software stored on system hub 120. The middleware software then converts the code into a message, such as "treatment preparation needs to be started within two hours", for example, using a look-up table, and causes the application downloaded to the patient l2b or the mobile communication device 200b of the clinician 112b to display the message. The application may again be programmed to provide a visual identifier with the message, such as a countdown timer that counts down from one hundred twenty minutes to zero timeout. The application may also provide any one or more of an audio alert (such as a "stings" sound) and/or a tactile alert (such as a vibration) prompting the patient l2b or clinician 112b to view the application and learn about the treatment preparation notification. The application may also be programmed to repeat the "stings" sound and/or tactile feedback process at preprogrammed intervals (e.g., at one hour and thirty minutes) during the countdown.
In addition to or instead of providing an application on the user's communication device 200b, it is also contemplated that middleware software at the system hub 120 converts the code from the machine 90b into messages that are deposited on the device's 200 native task tracking function, such as its calendar application. For example, most smart phone devices 200 are provided with a calendar that will divide each day into time periods, such as hours. Here, the message converted by the middleware software of the system hub 120 may be programmed to access the calendar of the authorized communication device 200b and fill in the appropriate time period of the appropriate date with the appropriate information. In the example above, for the appropriate date, the native calendar software application will fill in a message in the 10:00:00 am time slot, such as "treatment preparation needs to be started in two hours". An audio and/or tactile feedback signal may be provided to inform the patient 12 or clinician 112 of the calendar entry.
It should be appreciated that the machines 90a and 90b, middleware software at the central server 120, and the communication devices 200a and 200b may be programmed and operated as described above to provide any desired messages to the patients 12a, 12b and/or the clinicians 112a, 112b, and are not limited to the messages described herein. For example, the patient 12a, 12b and/or clinician 112a, 112b may also be informed at the end of sterilization by an accompanying countdown timer that treatment needs to begin within the countdown time to avoid having to re-sterilize the machine 90a, 90 b.
Referring now to fig. 5, a system 110b of the present disclosure is shown. System 110b in the illustrated embodiment operates with system 10 described above, including connection server 118, system hub 120, service portal 130, enterprise resource planning system 140, web portal 150, and business intelligence portal 160, which are shown in FIG. 5 as part of a cloud environment, but may alternatively be located on one or more dedicated servers. Other components of system 10 not shown in fig. 5 may also be part of system 110 a. For ease of description, a single medical fluid conveyor 90 is shown, however, a plurality of medical fluid conveyors 90 may be similarly connected to the system 110b. The medical fluid delivery machine 90 may be located in a home (shown as not being at home) of the patient 12 or in a clinic 126 a-126 n of the clinician 112. In the illustrated embodiment, the medical fluid delivery machine 90 is again connected to the connection server 118 via the secure management connection 116 and the internet 52 connection using, for example, the modem 102.
In one embodiment, the system hub 120 stores middleware software accessible by the mobile communication device 200 (shown as a single device for convenience, but multiple devices 200 may be similarly connected to the system 110 b). The mobile communication device 200 in fig. 5 includes all of the structures, functions and alternatives disclosed for the devices 200a and 200b shown in fig. 4, including connection to the internet 52. In fig. 5, the mobile communication device 200 may, but need not, download a software application ("app") from middleware software stored on the system hub 120 via their connection to the internet 52. The application may operate as described immediately above in connection with fig. 4, including middleware software that converts the encoded message from machine 90 into a format that can be presented on the application. Alternatively or additionally, middleware software stored on the system hub 120 can convert code from the machine 90 into messages that are deposited on the mobile communication device 200's native task tracking function (such as its calendar application) in any of the ways described in fig. 4.
Further alternatively or additionally, the system 110b includes a cellular network 210, the cellular network 210 being connected between middleware software stored, for example, at the system hub 120 and the mobile communication device 200. Cellular network 210 may include a network of cell phone towers operating using radio waves and/or employ satellites. The communication protocols suitable for use with the cellular network 210 of the system 110b may be remote protocols such as (i) the worldwide interoperability for microwave access ("WiMAX") protocol, and (ii) the global system for mobile communications "(GSM) protocol, which is a widely used remote wireless protocol supporting data communication with many cellular telephones in the world. Network 210 may alternatively or additionally employ a medium range protocol, such as a wireless local area network ("WLAN"), which may be part of an institute of electrical and electronics engineers ("IEEE") 802.11 standard, such as (i) IEEE 802.11a, (ii) IEEE 802.11b, (iii) WEE 802.11g, or (iv) 802.11n. Other suitable cellular technologies may include CDMA, AMPS (analog), general packet radio service ("GPRS"), cdmaOne, CDMA2000, evolution data optimized ("EV-DO"), enhanced data rates for GSM evolution ("EDGE"), universal mobile telecommunications system ("UMTS"), digital enhanced cordless communications ("DECT"), digital AMPS ("IS-136/TDMA"), and integrated digital enhanced networks ("iDEN").
The mobile communication device 200 communicates with the cellular network 210 via any means known to those skilled in the art, for example, via a short message service ("SMS") or multimedia message service ("MMS") protocol. Middleware software at the system hub 120 may communicate with the cellular network 210 in a variety of ways. In one example, the telephone number and operator of the user 12, 112 (any or all of the patient 12, the patient at home care partner, the patient's clinician 112) is associated with a particular machine 90, for example, via a lookup table at middleware software. When a message/code is received by the middleware from a particular machine 90, the middleware software can be programmed to send an email to the [ user phone number ] @ [ carrier ]. Net. For example, if the phone number of patient 001 is (555) 555-5555 and the operator of patient 001 is AT & T TM, when the machine 90 of patient 001 sends a message to the middleware of the system hub 120, upon receipt of the message, the middleware software 120 is programmed to relay the email to 5555555555@att.net, which is received as a text message by the mobile communication device 200 of patient 001. Those skilled in the art will appreciate that there are a number of websites dedicated to informing how to send text messages via email, summarizing the details required by different operators.
The middleware software stores each of the phone numbers of each mobile communication device 200 and matches each phone number with the machine 90. As described above, when an event code is sent from machine 90 to the middleware software, the middleware software locates the telephone number of the mobile communication device 200 associated with the machine, converts the code into an appropriate message, for example using a look-up table as described above, and sends the converted message to the called telephone number. It is contemplated that multiple communication devices 200 may be associated with the same medical fluid conveyor 90. For example, in any of clinics 126 a-126 n, multiple doctor, nurse, and/or clinician telephone numbers may be associated with the same machine 90. In a home environment, the telephone numbers of the patient 12 and its clinician and/or caregiver assistant may be associated with the same machine 90.
Likewise, a telephone number for the mobile communication device 200 may be associated with a plurality of medical fluid conveyors 90. For example, in any of clinics 126 a-126 n, a single nurse may monitor multiple machines 90. If an event occurs at any of these machines during the nurse shift, the nurse may be notified via a cellular message sent to the nurse's mobile communication device 200. This scenario is described in detail below in connection with fig. 7-9.
The cellular message may convey information regarding any of the same events used to fill in the software app and calendar update modes of the mobile communication device 200 with information as described above. For example, the medical fluid delivery machine 90 may have just completed its automatic self-test procedure and is ready to run a sterilization process. Machine 90a may generate and send code identifying the state to middleware software stored on system hub 120. The middleware software then converts the code into a message, e.g., using a look-up table, such as "self-test complete, ready for sterilization," and causes a cellular output routine such as described above to send a text message to the mobile communication device 200 of the patient 12 or clinician 112 to display the message. In an alternative embodiment, no code is required and the machine 90 instead sends the actual text string, which the middleware software forwards as a text message to the mobile communication device 200 via, for example, the cellular output routine discussed above. As is well known, receiving a text message on the communication device 200 may be accompanied by audio, e.g., a "stings" sound and/or a tactile alert, such as a vibration, that prompts the patient 12 or clinician 112 to view the message.
In another example, the medical fluid delivery machine 90 may have been preprogrammed to begin treatment at 3:00 pm. The medical fluid conveyor 90 may again take three hours to self-test and sterilize. Thus, the patient 12 or clinician 112 needs to be located at the machine 90 before noon to begin the pretreatment. In an embodiment, the patient 12 or clinician 112 makes settings on the machine 90 about how long (e.g., 2 hours) before the three hour preparation time should the patient 12 or clinician 112 be notified or alerted. Here, the machine 90 generates a code at 10:00 AM and sends the code to middleware software stored on the system hub 120. The middleware software then converts the code into a message, such as "treatment preparation needs to be started within two hours", for example, using a look-up table, and causes, for example, the cellular output routine described above to send a text message to the mobile communication device 20 of the patient l2 or clinician 112 to display the message, for example, along with an audio alert (such as a "stings" sound) and/or a tactile alert (such as a vibration), prompting the patient l2 or clinician 112 to view the notification.
It should be appreciated that the machine 90, middleware software at the central server 120, and the communication device 200 may be programmed and operated as described above to provide any desired messages to the patient 12 and/or clinician 112 using the cellular network 210 instead or in addition. For example, at the end of sterilization, patient 12 and/or clinician 112 may likewise be notified that treatment needs to begin within a countdown time to avoid having to re-sterilize machine 90. It should also be appreciated that updating of the local task tracking feature of a calendar application, such as communication device 200, may be accomplished through an internet connection or via cellular network 210 as shown in fig. 5.
Referring now to fig. 6, a system 110c of the present disclosure is shown. System 110c in the illustrated embodiment operates with system 10 described above, including connection server 118, system hub 120, service portal 130, enterprise resource planning system 140, web portal 150, and business intelligence portal 160 shown in FIG. 6 as part of a cloud environment, but may alternatively be located on one or more dedicated servers. Other components of system 10 not shown in fig. 6 may also be part of system 110 a. For ease of description, a single medical fluid conveyor 90 is shown, however, multiple medical fluid conveyors 90 may be similarly connected to the system 110b. The medical fluid delivery machine 90 may be located in a home (shown as not being at home) of the patient 12 or in a clinic 126 a-126 n of the clinician 112. In the illustrated embodiment, the medical fluid delivery machine 90 is again connected to the connection server 118 using, for example, the modem 102, via a secure management connection 116 and an internet 52 connection. In fig. 6, a connection server 118 and a security management connection 116 are used for bi-directional communication.
In one embodiment, the system hub 120 stores middleware software accessible by the mobile communication device 200 (shown as a single device for convenience, but multiple devices 200 may be similarly connected to the system 110 b). The mobile communication device 200 in fig. 6 includes all of the structures, functions and alternatives disclosed for the devices 200a and 200b shown in fig. 4, including connection to the internet 52. In fig. 6, the mobile communication device 200 may, but need not, download a software application ("app") from middleware software stored on the system hub 120 via their connection to the internet 52. The application may operate as described immediately above in connection with fig. 4, including middleware software converting the encoded message from machine 90 into a format that can be rendered on the application. Alternatively or additionally, middleware software stored on the system hub 120 may be capable of transcoding from the machine 90 into messages that are deposited on the local task tracking feature of the mobile communication device 200 (such as its calendar application) in any of the manners described in fig. 4. The calendar application may alternatively be updated via the cellular network 210 discussed above in connection with fig. 5 (shown as an alternative via the dashed line leads in fig. 6).
Fig. 6 illustrates that communication between the medical fluid delivery device 90 and the mobile communication device 210 may be bi-directional. Communication between the mobile communication device 210 and the middleware software at the server computer 120 may occur via the internet 52 and/or the cellular network 210. As described in detail above, communication between middleware software at the server computer 120 may occur via the secure management connection 116 via the connection server 118.
As described above, home treatment device 90 is connected to connection server 118 via its on-board connection agent 114, and in one embodiment, on-board connection agent 114 is turned off during treatment, for example, while machine 90 and its peripheral devices are running (on-board connection agent 114 may or may not be turned off during post-treatment sterilization). This prevents the home treatment device 90 from communicating with any entity and sending or receiving data during treatment and sterilization or when the machine 90 is in an active or operational state. It is contemplated that communications via systems 110a through 110c may be secured in the same manner. For example, assume that a particular machine 90 is set up via middleware software to communicate with both the patient 12 and the clinician 112. Here, if the patient is being treated by machine 90, it is contemplated that connection agent 114 be disconnected so that clinician 112 is not able to receive notifications from machine 90 or send commands to machine 90 at this time. In alternative embodiments, clinician 112 may be able to receive notifications from machine 90 during treatment.
Determining when to disconnect agent 114 (no communication) may depend on what machine claim systems 110 a-110 c desire to communicate with mobile communication device 200, or how many machine claim systems 110 a-110 c desire to communicate with mobile communication device 200. For example, assume that it is only desirable to notify the patient 12 or clinician 112 two hours prior to treatment preparation that the patient 12 or clinician 112 needs to return to the machine 90 to begin treatment preparation. Here, once the patient 12 or clinician 112 begins a first treatment preparation step, such as running a self-test routine, the connection agent 114 may be closed.
In another example, it may be desirable for machine 90 to automatically run a self-test routine at some preset time before starting treatment. The machine 90 notifies the patient 12 or clinician 112 at the beginning of sterilization. Here, once the patient 12 or clinician 112 begins machine sterilization, the connection agent 114 may be disconnected. In another example, it may be desirable for machine 90 to notify patient 12 when sterilization is complete, so that the patient begins treatment within a certain time from the end of sterilization, thus eliminating the need for repeated sterilization. Here, once the patient 12 or clinician 112 begins treatment, the connection agent 114 may be disconnected, for example, while the initial patient still needs to be connected to a treatment line (e.g., arterial line 14 or venous line 16).
The system 110c allows the patient 12 or clinician 112 to remotely initiate any of the above-described actions (as well as other actions not explicitly described herein). The patient 12 or clinician 112, for example, may select an icon of an application displayed on the mobile communication device 200 to begin, for example, a self-test routine or disinfection process. The selection of the icon is communicated to the middleware software via the internet 52. The middleware software may then translate the icon selections into action codes, e.g., via a lookup table, that are sent to the machine 90 with the connection agent 114 in an open state via the connection server 118 and the security management connection 116, allowing the action codes for the selected actions to be sent to the ACPU 50 of the machine, the ACPU 50 beginning to perform the selected actions.
In alternative embodiments, the patient 12 or clinician 112 may enter a known code, for example, in a text message, to select a particular action to be performed at the machine 90, such as a self-test routine or a disinfection process. The code may be a prompt code such as "self-test" or "disinfection". The text message is sent to middleware software at the system hub 120 via the cellular network 210. The middleware software converts the text code into action code for the selected action, for example, via a lookup table. Or the code entered by the patient 12 or clinician 112 may be an action code so that no conversion is required. In either case, the action code is sent to the machine 90 with the connection agent 114 in an open state via the connection server 118 and the secure management connection 116, allowing the action code for the selected action to be sent to the ACPU 50 of the machine, thereby beginning to perform the selected action.
Fig. 6 shows the following example seven step sequence. In step 1, the medical fluid delivery machine 90 sends a message to the middleware software application of the system hub 120 indicating that the machine is ready for the patient 12 to initiate a start-up of the machine 90, e.g., a two hour automated self-test routine. In step 2, the middleware software application at the system hub 120 sends a corresponding message (e.g., a converted message) to the patient's mobile communication device 200 indicating that the machine 90 is ready for the patient 12 to initiate the initiation of the automated self-test routine.
In step 3, the custom application downloaded to the patient's mobile communication device 200 will alert the patient 12 via audio, visual and/or tactile alerts and related messages that the patient is ready for the patient's 12 machine 90 to initiate, for example, two hours of initiation of an automated self-test procedure. In step 4, the patient 12 uses the custom application on the mobile communication device 200 to confirm that the machine 90 should initiate its automated self-test routine.
In step 5, the patient's mobile communication device 200 sends a message to the middleware software application at the system hub 120 to confirm that the patient's machine 90 is expected to begin its auto-self-test routine. In step 6, the middleware software application at the system hub 120 sends (e.g., converts and sends) a message to the machine 90 indicating that the patient 12 has confirmed that the machine 90 will initiate its auto-self-test routine. In step 7, machine 90 begins and executes its auto-self-test routine.
Once the self-test is performed, it is contemplated that the system 110c performs the same steps 1 through 7 described above, except that the action is now a disinfection program rather than an automatic self-test routine. Here, the custom application downloaded to the patient's mobile communication device 200 may display a countdown timer to the patient 12, reminding the patient how long it must return to the machine 90 to initiate treatment. It should be appreciated that different types of medical fluid delivery machines may have different one, two, three, or more actions that the patient 12 or clinician 112 may perform before treatment begins.
Regarding the systems 110a to 110c, it is contemplated that an application on the mobile communication device 200 is programmed to be configurable by a user to select what notification the user wishes to receive on his device 200, e.g., via the application itself, via a text message, and/or via a calendar notification. In one embodiment, the system hub 120 may send all notification types wherein the mobile communication device 200 ignores the communication types that the user has disabled. In another embodiment, the system hub 120 stores the user's preferences and sends the information only in the selected notification type.
C. clinician device/server embodiment
Referring now to fig. 7-9, one embodiment of a system 110d having a clinician-based downloadable software application ("app") 230 for a mobile communication device or server 200 for a doctor, clinician, or nurse is shown on screens 232-236. As described above, the mobile communication device 200 may be a mobile communication device of the patient 12 or a mobile communication device of the doctor/nurse/clinician 112. The screens 232-236 of fig. 7-9 illustrate that the application 230 may be used in a clinic or hospital 126 a-126 n, where a nurse is responsible for multiple machines 90 a-90 n, for example. The machines 90a to 90n may again be hemodialysis machines, peritoneal dialysis machines, CRRT machines, drug and/or nutrient solution delivery machines, and combinations thereof.
Screen 232 shows that application 230 may monitor and control (if desired) multiple machines 90. In the illustrated embodiment, machines 90a through 90n are represented by dedicated icons 190a through 190n, respectively, displayed on a screen 232 of application 230. In the illustrated embodiment, the order of icons 190a through 190n on screens 232 through 236 is the same as the order of machines 90a through 90n in clinics 126a through 126c to help orient doctor/nurse/clinician 112.
It is contemplated that the application 230 operates with the system hub 120 as already discussed herein, wherein the system hub 120 is remote from the clinic or hospital 126 a-126 n and maintained, for example, by a manufacturer of one or more of the machines 90 a-90 n. For example, the application 230 may be initially developed at the product development 128 shown in FIG. 1. The application 230 may then be sent from the product development 128 to the system hub 120 via the service portal 130, as shown in fig. 1 and 7. Any nurse, clinician or doctor 112 authorized to download the application 230 may download from the system hub 120. Thereafter, the system hub 120 maintains middleware software to operate with the applications 230 in the systems 110 a-110 c in the manner described above.
In alternative embodiments, the clinics 126 a-126 n may maintain their own local area networks, each operating with the local system hub 220. The application 230 may again be developed by the product development 128 (FIG. 1) and transmitted via the service portal 130 to the local system hubs 220 of the clinics 126 a-126 n operating with the overall system 10. Each nurse, clinician or doctor 112 authorized to download the application 230 downloads from the local system hub 220. Thereafter, the local system hub 220 maintains middleware software to operate with the applications 230 in the manner described above for the system hubs 120 in the systems 110 a-110 c. In another alternative embodiment, the application 230 may be developed by the clinics 126 a-126 n and stored on its local system hub 220.
The middleware software of the system hub 120 or the local system hub 220 updates the state of each machine 90a through 90n. The nurse, clinician or doctor 112 may select the icons 190a through 190n at any time to view the current status of each machine 90a through 90n, such as "rest", "self-test", "sanitize" or "treat patient", as shown in screen 234 of fig. 8. Other status flags are contemplated and may be different for different types of machines. The nurse, clinician or doctor 112 may then select any of "rest", "self-test", "sanitize" or "treat patient" to return to home icons 190a through 190n as shown in fig. 9.
As described above, it is contemplated that the connection agent 114 of each machine 90 is shut down while the machine is running, particularly when the patient 12 is connected to the machine. However, it is also contemplated to allow the connection agent 114 of each machine 90 a-90 n of the clinics 126 a-126 n to remain on until sterilization is complete, so that the middleware software at the system hub 120 or local system hub 220 may receive a status change from each machine 90 a-90 n of the "treatment patient". In addition, because each machine 90 a-90 n knows its planned treatment duration, the machine may also send the planned duration to middleware software, which then sends the duration in the form of a countdown timer along with a status change for "treating the patient". Then, here, when the nurse, clinician or doctor 112 selects "treat patient" in fig. 8, they can see a countdown timer indicating the remaining treatment time, as shown in fig. 9.
It is contemplated that for a countdown timer, connection agent 114 allows machines 90a through 90n to send time remaining data to system hub 120 so that application 230 may display the actual time remaining for each machine 90 undergoing the timing process. Application 230 accounts for alarms or other delays that machine 90 may experience. During an alarm condition, the respective icons 190a through 190f may display a message such as "alarm" or "safe mode". The nurse, clinician or doctor 112 may then select the countdown time in fig. 9 to return to home icons 190c, 190d and 190h shown in fig. 7.
The nurse, clinician or doctor 112 may also toggle the alarm on/off icon 238 to allow or disallow the change of state of the machines 90 a-90 n to be alerted visually, audibly and/or tactilely. If the alert on/off icon 238 is switched "on," the application 230 of the mobile communication device 200 provides a visual, audible, and/or tactile alert each time the machine state changes, such as (i) start self-test, (ii) self-test complete, (iii) start disinfection, (iv) disinfection complete, (v) treatment start, (vi) treatment complete. In an embodiment, the code of (i) through (v) is sent via machines 90a through 90n, through secure management connection 116, connection server 118, and system hub 120 or local system hub 220 to be converted by middleware software and forwarded to application 230, application 230 updating the appropriate icon 190. In various embodiments, "(vi) treatment complete" may be inferred (a) with the connection agent 114 activated, sent via the machines 90 a-90 n, or (b) when the countdown timer for the appropriate icons 190 a-190 n expires and with the connection agent 114 still closed.
If the alarm on/off icon 238 is turned off, for example, if the nurse, clinician or doctor 112 does not wish to be disturbed at a given moment, the icons 190a through 190n are still updated as described above, but no audible and/or tactile alarm is provided. However, nurse, clinician or doctor 112 may still actively view the status of each machine 90 a-90 n by selecting the associated icon 190 a-190 n.
Screens 232 through 236 show action buttons 240a and 240b (collectively referred to herein as action buttons 240, or generally referred to as action buttons 240 individually). Any number of action buttons 240 may be provided for any type of priming action required for any form (e.g., hemodialysis, peritoneal dialysis, CRRT, drug and/or nutrient delivery). In the illustrated embodiment, action button 240a is used to initiate a self-test of machine 90, while action button 240b is used to initiate a sterilization sequence of machine 90.
In one embodiment, when self-test button 240a is selected, any machine 90a through 90n that is capable of performing self-tests at this time highlights its corresponding icon 190a through 190 n. A nurse, clinician or doctor 112 selects any of the icons 190 of the machines 90 for which the nurse, clinician or doctor 112 wishes to perform a self-test. The selected icon 190 may then become a "confirm" button that the nurse, clinician or doctor 112 must press again to cause the selected machine 90 to perform its self-test. The application 230 of the mobile communication device 200 then sends the corresponding self-test code to the middleware software at the system hub 120 or the local system hub 220, which converts the self-test code into a self-test initialization command, if necessary, and sends the command via the connection server 118 to the connection agent 114 of the selected machine 90 over the secure management connection 116, which transmits the command to the ACPU 50 of the machine, which in turn initializes the self-test.
In the illustrated embodiment, when the sanitize button 240b is selected, any machine 90 a-90 n that is capable of performing sanitization at this time highlights its corresponding icon 190 a-190 n. The nurse, clinician or doctor 112 selects any of the icons 190 that the nurse, clinician or doctor 112 wishes to perform sterilization. The selected icon 190 may again become a "confirm" button that the nurse, clinician or doctor 112 must again press to cause the selected machine 90 to perform its sterilization. The application 230 of the mobile communication device 200 then sends the corresponding disinfection code to middleware software at the system hub 120 or the local system hub 220, which converts the disinfection code into a disinfection initialization command, if necessary, which is sent via the connection server 118 over the secure management connection 116 to the connection agent 114 of the selected machine 90, which transmits the command to the ACPU 50 of the machine, which in turn initializes the disinfection.
The process just described for action button 240 may also be implemented in system 110c and may be implemented for other machine commands, which may vary depending on the type of machine 90. It is also contemplated that the clinic 126a may determine that it is sufficiently safe to keep the connection agent 114 in an open state during a treatment or portion of a treatment in the presence of one or more nurses, clinicians or doctors 112 at the clinic. In this case, a nurse, clinician or doctor 112 may control the in-treatment activities of machine 90. For example, a nurse, clinician or doctor 112 may receive and respond to alarms/alerts, start and stop pumps, and other therapeutic aspects, start and stop disinfection, start and stop priming, etc., via the application 230 at the mobile connection device 200.
Each of the systems 110a to 110d operates by some form of addressing. As described above, a connection server 118 is provided in one embodiment to ensure that data is transferred to the appropriate machine 90 in its appropriate form and that data from the machine 90 is transferred to the appropriate destination in its appropriate form. In one embodiment, when a machine 90 sends data to the system hub 120 or the local system hub 220 for transmission to the mobile communication device 200, the data is provided with a machine identifier that identifies the machine 90 from which the data was sent. The connection server 118 knows each mobile communication device 200 to which the data for a particular machine belongs and tells the system hub 120 or the local system hub 220 which communication devices 200 will receive the data. The system hub 120 or the local system hub 220 may then convert the data as discussed herein. When sending, for example, converted data, the system hub 120 or the local system hub 220 may strip the machine identifier from the data because it is no longer needed. However, in the system 110d, the machine identifier may be transmitted with, for example, the converted data so that the application 230 knows which icon 190 a-190 n to write the new data to. Here, once the machine identifier is no longer needed, the application 230 may strip the machine identifier.
In one embodiment, when the mobile communication device 200 sends data to the system hub 120 or the local system hub 220 for transfer to the machine 90, the data is provided with an identifier of the mobile communication device 200 that identifies the mobile communication device 200 from which the data was sent. As described above, the system hub 120 or the local system hub 220 may or may not convert data from the mobile communication device 200, but in either case maintains a mobile communication device 200 identifier for the connection server 118. The connection server 118 knows which machine 90 will receive the converted data, e.g., for each mobile communication device 200, and sends the converted data, e.g., to each associated communication device 200. Once transmitted to machine 90, connection server 118 may strip the identifier of mobile communication device 200 from the data because it is no longer needed.
The application 230 as described above allows a nurse, clinician or doctor 112 to set up, monitor and possibly control treatment at the medical fluid delivery machine 90. It is contemplated that similar functionality is provided to the patient 12 or a caregiver of the patient 12 in the patient's home (dashed box in fig. 1) via the application. The connectivity may be the same as shown in fig. 7 to 9. However, the setup is not a clinic 126a to 126n, but a home or other non-clinical location, such as a business or vacation location. In addition, there is typically only a single machine 90, rather than a plurality of machines 90a through 90n. However, a single patient 12 may be treated via multiple machines 90, which multiple machines 90 may each be supported by an application as described herein. If the patient 12 is at home but away from the machine 90, the application may provide valuable information, such as the amount of time left to initiate or complete a startup procedure task, disinfection procedure, or self-test routine. When the machine 90 is treating a patient, he/she may see information on his/her user interface 122, which may itself be a tablet as shown in fig. 1. But may also be a caregiver, such as a spouse, friend, or family nurse, who helps the patient 12 at home. The caregiver benefits from the home application by receiving status updates, remaining start-up procedure time, remaining sterilization time, remaining priming time, remaining treatment time, information regarding whether the patient 12 has been connected to the machine 90, reminders, alarms, etc. In one embodiment, the application requires entry of a login name and password associated with the patient before it can be downloaded to the caregiver's mobile communication device 200 so that only authorized personnel can view the patient treatment data or information.
Patient participation example
The example medical fluid data transmission system 10 disclosed above in connection with fig. 1-9 is configured to improve patient participation in medical fluid delivery therapies such as dialysis therapies, renal failure therapies, and/or peritoneal therapies. Fig. 10 illustrates an example medical fluid data transmission system 1000, which is similar to the medical fluid data transmission system 10 discussed in connection with fig. 1-9, according to an example embodiment of the present disclosure. The example medical fluid data transmission system 1000 (e.g., mobile platform) is configured to improve patient participation and/or compliance with therapy by increasing therapy transparency, providing patient features to control and report information related to the therapy, and/or providing access to educational materials and/or real-time assistance from a clinician.
The example medical fluid data transmission system 1000 includes a personal mobile communication device 200a operated by a patient, for example. The medical fluid data transfer system 1000 also includes a blood pressure monitor 104, a weight scale 106, and a home therapy device 90, which are similar to the various devices discussed above in connection with fig. 1-9. The personal mobile communication device 200a, home therapeutic apparatus 90, blood pressure monitor 104, and weight scale 106 may be located, for example, in a patient's home, self-service clinic, and/or a medical care clinic.
The home treatment device 90 may include any type of hemodialysis machine, peritoneal dialysis machine, CRRT machine, drug and/or nutrient solution delivery machine, and combinations thereof. The home treatment apparatus 90 may provide, for example, continuous circulation peritoneal dialysis ("CCPD"), tidal flow automated peritoneal dialysis ("APD"), and continuous flow peritoneal dialysis ("CFPD"). The home treatment device 90 may typically automatically perform the drain, fill, and dwell periods while the patient is sleeping.
The peritoneal dialysis solution can include a solution or mixture comprising 0.5% to 10% glucose (or more generally glucose), preferably 1.5% to 4.25%. The peritoneal dialysis solution can include, for example, dianeal, physioneal, nutrineal, and Extraneal volumes of dialysate sold by the assignee of the present disclosure. The dialysate may additionally or alternatively include a percentage of icodextrin.
In both hemodialysis and peritoneal dialysis, the "adsorbent" technique can be used to remove uremic toxins from spent dialysate, re-infuse the treated fluid with a therapeutic agent (e.g., ions and/or glucose), and then resume patient dialysis using the fluid. One commonly used adsorbent is made of zirconium phosphate for removal of ammonia produced by urea hydrolysis. Typically, a large amount of adsorbent is required to remove ammonia generated during dialysis treatment.
The example weight scale 106 includes any device configured to measure the mass of a patient or a treatment assembly. For example, the weight scale 106 may measure patient weight before, during, and/or after renal failure treatment. Additionally or alternatively, the weight scale 106 may measure replenishment or drainage bags for tracking renal failure therapy. Specifically, the weight scale 106 may be used to measure the amount of UF removed or the amount of fluid provided to the patient. The weight scale 106 may display a digital value indicative of body weight. Alternatively, the weight scale 106 may display a physical scale or dial aligned with the indicia to indicate the measured weight. In some embodiments, the weight scale 106 may store weight values before, during, and/or after treatment in separate windows, such that patient input is required to view all values when recording medical information.
The example blood pressure monitor 104 includes any device configured to measure the blood pressure and/or pulse of a patient. For example, the blood pressure monitor 104 may measure the patient's blood pressure before, during, and/or after renal failure treatment. The blood pressure monitor 104 may display a digital value indicative of the patient's blood pressure. Alternatively, the blood pressure monitor 104 may display a physical scale with a dial aligned with the numerical value to indicate the measured blood pressure. In some embodiments, the blood pressure monitor 104 may store the blood pressure values before, during, and/or after the treatment in a separate window such that patient input is required to view all values when recording medical information. The blood pressure monitor 104 may be integrated with the home treatment device 90. In another embodiment, the blood pressure monitor 104 may include a wearable sensor, such as a smart watch or fitness tracking device.
In addition to obtaining medical information (e.g., medical device data) from the medical devices 90, 104, and 106, the example personal mobile communication device 200a may also obtain medical information from the patient and/or the treatment consumable 1006. Fig. 10 illustrates an example of a consumable 1006 that includes, for example, a renal failure therapy medical device filter, a disposable cartridge, a blood line set, a drug delivery line set, and a container (e.g., a dialysate concentrate container, a blood anticoagulant container, a drug container, and/or a clean water container). Consumable 1006 may also include a sorbent cartridge or any other disposable or material supply for medical use. The consumable may include an identifier 1008 configured to provide the medical information in the form of consumption information or consumption data. For example, the identifier 1008 may include information identifying the type of consumable, a serial number, and/or an attribute of the consumable. In some cases, consumable 1006 may also include a tag that contains medical information (such as chemical composition properties). The patient or clinician uses the personal mobile communication device 200a to record an image of the identifier 1008, an image of a tag on the consumable 1006, and/or an image of the consumable 1006 itself to record the material used during treatment.
The personal mobile communication device 200a may be communicatively coupled to the home therapeutic apparatus 90, the blood pressure monitor 104, and/or the weight scale 106 via a wired connection (e.g., a USB connection) or a wireless connection (e.g., bluetoothTM, wiFiTM, zigbee, Z-Wave, wireless USB, or wireless local area network ("WLAN")). In other examples, personal mobile communication device 200a is not communicatively coupled to any of home therapy device 90, blood pressure monitor 104, and/or weight scale 106. In these other examples, the patient may manually input data displayed by the home therapy device 90, the blood pressure monitor 104, and/or the weight scale 106 into the personal mobile communication device 200 a. Additionally or alternatively, in these other examples, the patient may record one or more images of the data (or identifiers placed thereon) displayed by the home therapy device 90, the blood pressure monitor 104, and/or the weight scale 106 using the camera 1004 of the personal mobile communication device 200 a.
The blood pressure monitor 104 and the weight scale 106 are collectively referred to as medical devices. It should be appreciated that the medical fluid data transmission system 1000 may include additional medical devices such as infusion pumps (e.g., syringe pumps, linear peristaltic pumps, large volume pumps ("LVP"), dynamic pumps, multi-channel pumps), oxygen sensors, respiratory monitors, blood glucose meters, blood pressure monitors, electrocardiogram ("ECG") monitors, weight scales, and/or heart rate monitors. In other examples, the medical fluid data transmission system 1000 may include fewer medical devices and/or medical devices integrated together (e.g., the blood pressure monitor 104 integrated with the home therapy device 90).
In some embodiments, the personal mobile communication device 200a is configured to record, display, and/or fill in patient medical records with medical information or data. As disclosed herein, medical information or data includes medical device data and patient data, which may refer to data or information created, generated, or otherwise related to medical devices, patients, and/or consumables used by medical devices. For example, the medical information includes prescription or programming information used by the medical device to manage the treatment. The medical information also includes sensed data such as fluid pressure, flow rate, conductivity, concentration, temperature, and patient data. As provided herein, patient data (e.g., vital sign data) includes sensed patient physiological information, such as patient blood pressure, weight, heart rate, and the like. The medical information may also include subjective information such as information about the patient's sensation (e.g., tiredness, fatigue, happiness, excitement, etc.). The medical information may be displayed on a screen of the medical device, provided by a physical dial or display of the medical device, or printed on an attached label or medical device. Thus, the medical device data or medical information includes medical device settings, medical device readings, and/or patient readings.
Medical information also refers to information contained on an identifier on a patient or treatment consumable. In particular, the medical information may include information conveyed by an identifier provided on the patient wristband for identifying the patient of the patient. The medical information also includes information about the consumable that can identify the type of consumable, the model of the consumable, and/or the nature of the consumable, such as the glucose level in the replenishment bag of the renal failure treatment solution.
Treatment data or treatment information refers to data generated and/or transmitted by the home treatment device 90 of fig. 1-10. The treatment information may include the amount of fluid injected, the amount of ultrafiltration UF removed from the patient, and/or the treatment time. The treatment information may also include alarm, reminder, and/or diagnostic information generated by the home treatment device 90. Typically, treatment information is transmitted from the home treatment device 90 to the clinician server 200b. In some embodiments, the treatment information may be recorded in the personal mobile communication device 200 a. In these embodiments, the treatment information may be referred to and/or included/processed as medical information.
As shown in fig. 10, some of all of the medical devices 90, 104, and 106 may include an identifier 1012 configured to store a unique identification number. The identifier 1012 may encode, for example, a designated device number, serial number, hardware number, model number, and/or device type of the respective medical devices 90, 104, and 106. For example, the identifier 1012b of the home treatment instrument 90 may store a designated device number. Personal mobile communication device 200a reads identifier 1012b to determine, for example, the medical device type for subsequent analysis and identification of medical information in images recorded from the screen of machine 90. In some embodiments, the identifier 1012 may more generally indicate the model or type of medical device. For example, the identifier 1012c may indicate that the device 106 is a weight scale and/or indicate a model of a weight scale.
The identifier 1012 may include a machine-readable indicia, such as a bar code or a quick response ("QR") code. The identifier 1012 may also include human readable text such as a serial number, asset number, or hardware number. In some embodiments, the identifier 1012 may be printed onto an item physically attached to the housing of the respective medical device 90, 104, and 106, such as the identifier 1012b shown for the home treatment instrument 90. Additionally or alternatively, the identifier 1012 may be displayed on a screen of some of all of the medical devices 90, 104, and 106. For example, the clinician may select a control interface to cause home treatment device 90 to display a window with identifier 1012b on a screen. In other embodiments, the identifier 1012 may be included within a radio frequency ("RF") microchip, such as an RFID chip or NFC chip.
The example medical devices 90, 104, and 106 may also include one or more control interfaces for providing control instructions. For example, home treatment device 90 includes a control interface 1014. The control interface may include buttons, a control panel, or a touch screen. The control interface may be configured to enable a user to navigate to a window or user interface on the screen of the respective medical device 90, 104, 106. The control interface may also provide instructions for operating or controlling the respective medical devices 90, 104, and 106.
As shown in fig. 10, the example fluid data transfer system 1000 includes a Web portal 150, a system hub 120, and a clinician server 200b (similar to the various devices discussed in connection with fig. 1-9) to communicate with a personal mobile communication device 200a. The Web portal 150, the system hub 120, and/or the clinician server 200b communicate medical information (stored in the clinician database 1010) from the patient's medical record to the personal mobile communication device 200a. In addition, the Web portal 150, the system hub 120, and/or the clinician server 200b may provide the personal mobile communication device 200a with access to educational materials or a real-time help session with a clinician. The example Web portal 150, the system hub 120, and/or the clinician server 200b are further configured to enable the personal mobile communication device 200a to provide medical information for filling in patient medical records.
The example fluid data transmission system 1000 of fig. 10 also includes a connection server 118, the connection server 118 being communicatively coupled to the home treatment device 90. As discussed above in connection with fig. 1-9, the connection server 118 provides two-way communication between the home therapeutic apparatus 90 and the clinician server 200b and/or clinician database 1010. The home treatment device 90 may be connected to the connection server 118 via the internet.
In the example shown in fig. 10, the example personal mobile communication device 200a includes a processor 1016 in communication with a memory 1018 storing instructions. At least some of the instructions define or specify an application 1002 that, when executed by the processor 1016, causes the processor 1016 to provide features that improve patient engagement and/or compliance with the therapy. Processor 1016 may include digital and analog circuitry configured as a microprocessor, application specific integrated circuit ("ASIC"), controller, or the like. Memory 1018 includes volatile or nonvolatile storage media. Further, memory 1018 may include any solid state or magnetic disk storage medium.
Features of the application 1002, as discussed in more detail below, include displaying treatment progress information, controlling which treatment programs the home treatment instrument 90 runs, recording medical information, displaying instructional materials, and/or initiating a help session with a clinician. The application 1002 may be function rich or function reduced. The smart phone is configured with a rich-functioning application that utilizes the native graphics, touch screen and processing capabilities of the personal mobile communication device 200 a. The reduced functionality application is configured to run on a cellular telephone having relatively less complex graphics and reduced processing power. The cellular telephone may also not include a touch screen or have a touch screen with limited functionality.
In some embodiments, personal mobile communication device 200a may not include application 1002. Instead, the personal mobile communication device 200a may use a native or other installed application to communicate with the clinician server 200 b. For example, the personal mobile communication device 200a may use text, SMS, or email programs to communicate with the clinician server 1020.
The example clinician server 200b includes an application 1020, such as the application 230 described in connection with fig. 1-9. The application 1020 is configured to communicate with the personal mobile communication device 200a to provide improved patient participation and/or compliance. In some embodiments, the example application 1020 is configured to facilitate storing medical information (recorded by the personal mobile communication device 200 a) to one or more medical records in the database 1010. The application 1020 may also include one or more interfaces or application programming interfaces ("APIs") to provide treatment progress data and/or medical information to the application 1002 for display on a display interface 1022 (e.g., a touch screen) of the personal mobile communication device 200 a. The application 1020 on the clinician server 200b may also provide educational material upon receiving a request from the application 1002 and/or facilitate a communication session between the personal mobile communication device 200a and the clinician device 152.
In some cases, the application 1002 on the personal mobile communication device 200a and/or the application 1020 on the clinician server 200b is configured to convert or otherwise provide medical information to a clinician database 1010 of other devices in the medical fluid data transfer system 1000 that are compliant with the health level 7 ("HL 7") standard (e.g., medical standard). This conversion enables medical information to be stored in HL7 format, regardless of the format at the time of input on the personal mobile communication device 200a. When gaps exist in the network or device connection, the application 1002 and/or the application 1020 can act as a network conduit to seamlessly propagate relevant medical information from the medical device to the patient medical record.
Fig. 11 shows a diagram of operational modules of application 1020 at clinician server 200b of fig. 10, according to an embodiment of the present disclosure. The application 1020 may include a registration module 1102, the registration module 1102 being configured to register patient medical records stored in the patient-specific and/or clinician database 1010 with the home treatment apparatus 90 and/or the personal mobile communication device 200 a. As described in more detail in connection with fig. 12, registration may include determining a type of personal mobile communication device 200a formatted for subsequent communication.
The application 1020 may also include a data acquisition module 1104 configured to receive treatment and/or medical information from the registered home treatment instrument 90 and/or personal mobile communication device 200 a. In addition, the application 1020 can include a data access module 1106 to send or otherwise provide access to medical information stored in one or more medical records associated with a patient. The application 1020 may also include an educational module 1108, the educational module 1108 configured to provide the patient with access to educational material or help documents regarding the patient's treatment and/or the operation of the home treatment device 90. Further, the application 1020 may include a therapy control module 1110 that enables a patient (or clinician) to change (or modify) a therapy program performed by the home therapy device 90. The application 1020 may additionally include an assistance module 1112, the assistance module 1112 creating a real-time communication session between the personal mobile communication device 200a and the clinician device 152.
Each of the example modules 1102-1112 is configured to improve patient participation in medical fluid delivery therapy, thereby increasing patient compliance with prescribed therapy. It should be appreciated that while modules 1102-1112 are shown, example application 1020 may include fewer or additional modules. For example, in some embodiments, the educational module 1108 and the auxiliary module 1112 may be omitted. The following sections provide further description regarding each of the modules 1102-1112.
As described below, each of the modules 1102-1112 is configured to communicate with the personal mobile communication device 200a and/or the clinician device 152. In some embodiments, communications from personal mobile communication device 200a may be addressed to clinician server 200b, web portal 150, connection server 118, and/or system hub 120. Messages may be routed internally to the different modules 1102-1112 based on content and/or identifiers. For example, application 1002 may provide an identifier in the header to specify which of modules 1102-1112 received the message. For text-based messages, the router at clinician server 200b may determine the destination modules 1102-1112 based on the message content or previous messages. For example, the router may determine that the received message corresponds to a message previously sent by the data acquisition module 1104. Based on the correspondence, the router sends the received message for processing via the data acquisition module 1104.
A. registration module embodiment
The example registration module 1102 is configured to register the personal mobile communication device 200a and/or the home treatment device 90 with medical records of the patient stored in the clinician server 200b and/or the database 1010. The example registration module 1102 is configured to provide different types of registrations that are used by the data access module 1106 to determine how to display information to a patient based on what type of device is registered. In addition, the data acquisition module 1104 determines how to acquire treatment and/or medical information based on the registration information.
Registration module 1102 is configured to store registration information to registration files stored in clinician database 1010. The registration file may specify, for each patient or patient activation code ("PAC"), information indicating registered personal mobile communication device 200a, information indicating registered home therapy device 90, and/or an indication as to whether application 1002 is installed on personal mobile communication device 200 a. In some embodiments, the registration file (or information from the registration file) can be included in a patient's medical record.
In some embodiments, there are different registration scenarios. For example, the patient may register the personal mobile communication device 200a by downloading the application 1002 while also registering the home treatment device 90. In this case, the registration module 1102 records that the patient has installed the application 1002 on the personal mobile communication device 200a and registered the home therapeutic apparatus 90 (alone or through the application 1002). Based on the registration, the data acquisition module 1104 determines that the application 1002 installed on the registered personal mobile communication device 200a will instruct or otherwise prompt the patient to acquire medical information. In addition, the data acquisition module 1104 determines that treatment information is to be received from the home treatment instrument 90 rather than via the personal mobile communication device 200 a. Thus, the data acquisition module 1104 may send a message to the application 1002 to disable the user interface for acquiring treatment information from the home treatment instrument 90 (but still enable the user interface for manual exchange if so prescribed for the patient). If the home therapeutic apparatus 90 is not registered, the data acquisition module 1104 causes the application 1002 to display a user interface to acquire therapeutic information from the home therapeutic apparatus 90 in the application 1002. Through registration, the data access module 1106 determines that information is to be displayed by the application 1002 and accordingly reads components compatible with or configured for the application 1002 using APIs and/or other data.
If the patient registers without downloading and/or installing the application 1002, the data acquisition module 1104 determines that data acquisition is to be prompted or directed. For example, the data acquisition module 1104 may send a text message and/or email to the registered personal mobile communication device 200a prompting the patient for certain medical and/or therapeutic information (if the home therapeutic apparatus 90 has not been registered). The information in the message specifies which data from the patient is needed. Although the remote directions may be used with reduced functionality personal mobile communication device 200a, they may also be used with smartphones where the patient does not wish to download or install applications 1002 on a rich device.
The data access module 1106 can also be configured to display information from patient medical records differently if the application 1002 is not installed. For example, in addition to sending data that inserts a well-defined, rich-function user interface, the data access module 1106 can render the data in a picture that is transmitted via text to the personal mobile communication device 200a for viewing. Additionally or alternatively, the data access module 1106 can communicate the stored medical record information as text to the personal mobile communication device 200a. Thus, even if the application 1002 is not installed, the application 1020 on the clinician server 200b is configured to provide the patient with access to the data using the native application on the personal mobile communication device 200a.
Fig. 12 shows a diagram illustrating communications between the home treatment apparatus 90, the personal mobile communication device 200a, and the clinician server 200b of fig. 10 and 11, according to an example embodiment of the present disclosure. First, the home therapeutic apparatus 90 is registered with the clinician server 200b via the registration module 1102 of fig. 11. Otherwise, the clinician server 200b will not have information about which medical record data from the home therapeutic device 90 to store. In some embodiments, the home treatment device 90 is preprogrammed with destination address information for the connection server 118, the system hub 120, and/or the clinician server 200 b. The destination address may include an internet protocol ("IP") address and/or a hypertext transfer (or transport) protocol ("HTTP") address.
During setup, the patient (or clinician) enters a patient activation code ("PAC") into home therapeutic apparatus 90.PAC is initially generated and stored at clinician server 200b and provided to the patient when the patient receives home therapeutic apparatus 90. The PAC may include a patient identifier or other code unique to the patient. Registration module 1102 at clinician server 200b stores the generated PAC to one or more medical records and/or registration files associated with the patient. After inputting the PAC, the home treatment apparatus 90 generates and transmits a message 1202 including the PAC. The message may also include a hardware identifier of the home treatment device 90 and/or an IP address assigned to the home treatment device 90. The home treatment device 90 sends a message 1202 to the preprogrammed address, in this case the connection server 118. The example connection server 118 relays the message 1202 to the system hub 120, which system hub 120 routes to the clinician server 200b. A registration module 1102 at the clinician server 200b registers the home therapeutic apparatus 90 with the patient using PAC. Registration includes, for example, associating an identifier of the home treatment device 90 with a patient medical record of the patient. Registration may also include clinician server 200b storing the IP address of home therapy device 90 to enable messages to be transmitted to home therapy device 90. After registration, the data acquisition module 1104 of the clinician server 200b stores the treatment information received from the home treatment device 90 to one or more medical records associated with the patient.
The example personal mobile communication device 200a is also configured to register with a clinician server 200b via a registration module 1102. For registration, the personal mobile communication device 200a can download or otherwise receive the application 1002 from the clinician server 200b (or third party application store) via one or more messages 1204. In an embodiment, during registration of the home treatment device 90, the patient (or clinician) may provide the phone number of the personal mobile communication device 200 a. Registration module 1102 uses the telephone number to communicate message 1204 as a text message. The message may include a hyperlink to a location (e.g., database 1010 or a third party website) that provides the application 1002 for downloading to the personal mobile communication device 200 a. In other cases, the message 1204 may include an accessory that, when executed, installs the application 1002 on the personal mobile communication device 200 a. In addition to providing a telephone number, the patient may provide an email address during registration of the home treatment device 90. Accordingly, the message 1204 includes an email message with a file or hyperlink for installing the application 1002 on the personal mobile communication device 200 a.
In another embodiment, the message 1204 may enable the patient to register in two different ways depending on the capabilities and/or personal preferences of the personal mobile communication device 200a. The message 1204 includes text prompting the patient to respond to the text if they wish to register their personal mobile communication device 200a as a reduced function device. A reply to message 1204 is provided via text message 1206, which is routed to registration module 1102. Further, the registration module 1102 registers the personal mobile communication device 200a with an indication that the application 1002 is not installed. In some cases, the message 1204 may also include text or hyperlinks to prompt the patient to select a hyperlink or to otherwise obtain an application if desired. The message 1204 may also provide a prompt or option to select a device type, such as an Apple device or an Android device. During registration, registration module 1102 registers personal mobile communication device 200a based on information provided by the patient and/or information read from personal mobile communication device 200a.
After installing the application 1002, the patient may register the personal mobile communication device 200a. In an embodiment, to register, the patient completes a registry or field provided by application 1002. The table or field is configured to accept the PAC of the patient. The form or field may also include a prompt for a patient name, email address, home address, telephone number, etc. Information from the form or field is sent in one or more messages 1206 to the Web portal 150, and the Web portal 150 communicates the message 1206 to the system hub 120 for routing to the clinician server 200b. Message 1206 may also include device type information for personal mobile communication device 200a (as determined by application 1002).
In some cases, the application 1002 may be configured with a destination address of the Web portal 150, which is used to transmit the message. In other examples, message 1206 may be provided to an API at Web portal 150 for registering application 1002 at clinician server 200 b. In other cases, the application 1002 sends the message 1206 to the Web portal 150 as one or more text messages or email messages (where the Web portal 150 is assigned a telephone number, IP address, email address, or other address). The example registration module 1102 uses the PAC within the message 1206 to register the personal mobile communication device 200a with medical records and/or registration files stored in the database 1010. At this time, both the home therapeutic apparatus 90 and the personal mobile communication device 200a are registered to the same patient at the clinician server 200 b.
As described above, in some embodiments, the personal mobile communication device 200a may not include an application. In these embodiments, the personal mobile communication device 200a may communicate with the clinician server 200b via text messages or through a Web browser. Accordingly, the registration module 1102 of the clinician server 200b may send a text message to the personal mobile communication device 200a with a hyperlink to a database or web page to complete registration. Alternatively, the text message may include a prompt to the patient to respond with his PAC. Providing PACs via any of these registration processes enables registration module 1102 to associate personal mobile communication device 200a (e.g., a phone number, hardware address, or IP address) with the appropriate patient medical record and/or registration file.
B. Data acquisition Module embodiment
Fig. 12 also shows data communication between the home treatment apparatus 90, the personal mobile communication device 200a and the clinician server 200 b. During operation, the home treatment instrument 90 generates treatment information and status information (e.g., medical information). As discussed above in connection with fig. 1-9, the treatment information includes the amount of fluid injected, the amount of ultrafiltration ("UF") removed from the patient, and/or the treatment time. The status information includes alarm, alert or diagnostic information. Before and after treatment, the home treatment device 90 generates one or more messages 1208 with medical information that are transmitted to the connection server 118. The connection server 118 then routes the message 1208 to the system hub 120, and the system hub 120 routes the message 1208 to the data acquisition module 1104 of the clinician server 200 b. Upon receipt, the data acquisition module 1104 stores the medical information to a designated portion of a patient medical record (e.g., the patient medical record 1302 of FIG. 13). The message 1208 can include an identifier or address of the home treatment device 90 that is used by the data acquisition module 1104 to locate the appropriate medical record in the database 1010.
The example home treatment instrument 90 may be configured to encode, tag, or otherwise identify medical information being transmitted using metadata or other data identification techniques. The encoding or marking enables the data acquisition module 1104 (or the interface at the server 200 b) to determine the context of the medical information to write the medical information into the appropriate fields of the medical record. Additionally or alternatively, the code or mark may also be stored in a record that is subsequently used to search for and display medical information.
Fig. 12 also shows that the personal mobile communication device 200a transmits medical information or transmits medical information to the clinician server 200b. As described in more detail below, personal mobile communication device 200a is configured to obtain medical information from devices including devices 90, 104, and 106. Acquiring medical information may include receiving information manually entered by a patient via a wired or wireless connection and/or processing images recorded by the camera 1004 of the personal mobile communication device 200 a. The acquired medical information is packaged into one or more messages 1210 and transmitted by the personal mobile communication device 200a to the Web portal 150. Message 1210 may be a text message, an email message, or a Web-based message (e.g., an HTTP message, an extensible markup language ("XML") message, a JavaScript object notation ("JSON") payload, etc.). In some embodiments, the personal mobile communication device 200a may format the acquired medical information into one or more data fields prior to transmission. Generally, the structure of medical information acquired in the personal mobile communication device 200a is less than the structure of medical information generated by the home therapeutic apparatus 90. Accordingly, the data acquisition module of the personal mobile communication device 200a and/or clinician server 200b performs at least some processing of the medical information to provide an appropriate context or structure for inclusion within the patient medical record. Hereinafter, examples of the performed processing are described in further detail.
Fig. 13 illustrates an example patient data structure 1300 stored on the clinician database 1010 of fig. 10, according to an example embodiment of the disclosure. The patient data structure 1300 includes individual medical records for different patients. In the illustrated example, the data structure 1300 includes a patient medical record 1302 of a patient associated with an identifier "DCM31913" and a patient medical record 1304 of a patient associated with an identifier "GAM 41215". The data structure 1300 can include additional patient medical records.
As shown in fig. 13, each medical record 1302 and 1304 includes data fields that identify the patient, the personal mobile communication device 200a, and the home treatment device 90. For example, medical records 1302 and 1304 include data fields for a patient identifier, a personal mobile communication device 200a type, a home treatment device 90 type, and a home treatment device identifier (received via registration). The patient identifier may correspond to a PAC assigned to the patient. The medical records 1302 and 1304 can include additional fields for patient name, address, gender, date of birth, etc. The medical records 1302 and 1304 can further include fields for network addresses of the personal mobile communication device 200a and/or the home treatment device 90. In some embodiments, the data access module 1106 of the application 1020 uses the information in the device type field to determine how to present and/or send the therapy information and the medical information to the personal mobile communication device 200a.
As also shown in FIG. 13, medical records 1302 and 1304 include fields for treatment and medical information. The data acquisition module 1104 stores therapy information to medical records 1302 and 1304 received from the respective home therapeutic devices 90. In addition, the data acquisition module 1104 stores medical information to medical records 1302 and 1304 received from the respective personal mobile communication devices 200 a. In some embodiments, the data field is further divided into separate fields for the data type. For example, medical records 1302 and 1304 can include treatment information fields for an amount of fluid injected, an amount of ultrafiltration ("UF") removed from a patient, and/or a treatment time. The medical records 1302 and 1304 can also include data fields for reminders or alerts generated during treatment and/or data fields for alerts or reminders determined at the clinician server 200b based on treatment information and/or medical information. The medical records 1302 and 1304 can further include medical information of the patient's weight and/or blood pressure recorded before, during, and/or after treatment.
The treatment and/or medical device may be organized by treatment, date/time of creation, and/or date/time of receipt. In some embodiments, medical records 1302 and 1304 can store communications from a patient. The communication may include pictures or videos recorded by the personal mobile communication device 200a relating to the treatment or a problem with the treatment. The communication may also include text messages, emails, etc. sent from the personal mobile communication device 200a regarding treatment assistance. In addition, the communication may include information related to a request from the personal mobile communication device 200a and/or the clinician device 152 to change or modify the therapy. In general, medical records 1302 and 1304 are configured to store information that improves patient participation in therapy in addition to archiving therapy results and information related to patient participation in therapy via clinician server 200 b.
The data received by the example data acquisition module 1104 varies based on the source. For example, treatment information received from the home treatment device 90 is generally structured. In other words, the home treatment instrument 90 is configured to transmit treatment information formatted for direct entry into one or more fields of a patient medical record. In some embodiments, the home treatment instrument 90 formats the message for transmission (or access to one or more APIs) through the APIs of the data acquisition module 1104 to fill in the treatment information into the appropriate data fields. In contrast, medical information recorded by the patient's personal mobile communication device 200a may not initially be structured for inclusion in the patient's medical record. The application 1002 of the personal mobile communication device 200a and/or the data acquisition module 1104 of the clinician server 200b can use different techniques to process and/or format medical information to fill it into medical records, as described in more detail below.
1. Manually inputting medical information into application embodiments
To receive structured information, in some embodiments, the example application 1002 of the personal mobile communication device 200a is configured to display a prompt indicating which medical information is needed to be filled into a patient medical record by a patient. The example application 1002 may include a routine or algorithm that specifies which fields to display to prompt medical information from a patient. In some embodiments, the fields or screens displaying the fields are arranged and/or ordered in relation to the medical fluid delivery treatment. The display of fields informs the patient about which medical information is needed for the medical record.
Fig. 14 and 15 show diagrams illustrating a user interface of an application 1002 that enables a patient to enter medical information for transfer to a data acquisition module 1104. Specifically, the user interface 1400 of fig. 14 prompts the patient for blood pressure information, while the user interface 1500 of fig. 15 prompts the patient for medical fluid delivery information (e.g., treatment information). It should be appreciated that the application 1002 of the personal mobile communication device 200a may display other user interface screens that enable the patient to manually enter medical information. For example, the application 1002 may display a user interface screen for blood glucose level, patient temperature, patient weight, etc.
In some embodiments, the patient may manually enter some medical information in the user interface 1400 or 1500 while other medical information is acquired wirelessly or some medical information is recorded via an image. In these configurations, the application 1002 may be configured to enable a patient to select an information input source. The patient may manually enter medical information after selecting a manual source from a menu of available data entry methods or by default.
Upon receiving medical information manually entered by a patient, the example application 1002 transmits the medical information to the data acquisition module 1104 to fill it into a patient's medical record. The application 1002 and user interfaces 1400 and 1500 are configured to align data fields for receiving medical information with data fields in one or more medical records. In some examples, the data fields can correspond to one or more APIs at the data acquisition module 1104 for writing medical information directly into design data fields of a patient medical record. Accordingly, the user interfaces 1400 and 1500 of the applications prompt the patient for the medical information in a structured manner, thereby eliminating the need or need to identify or format the medical information.
In some embodiments, the application 1002 may be configured to display the user interfaces 1400 and 1500 at design time. For example, the application 1002 may include a calendar that includes a time/date at which the treatment was scheduled. At a design time prior to treatment (e.g., 5 minutes, 15 minutes, 30 minutes, etc.), the example application 1002 is configured to cause the personal mobile communication device 200a to display a user interface 1400 prompting the patient for blood pressure medical information. The prompt informs the patient that a blood pressure measurement is required before treatment begins. Accordingly, the patient uses the blood pressure monitor 104 to make blood pressure measurements. The patient then enters the measurements into the user interface 1400 before the treatment begins.
In the illustrated embodiment, the user interface 1400 includes a systolic data field 1402, a diastolic data field 1404, and a pulse data field 1406. The patient may select the corresponding data field 1402, 1404, or 1406 to cause the application 1002 to display a text entry function to enter a value. The user interface 1400 also includes a field 1408, which field 1408 enables the patient to specify whether to stand or sit for blood pressure measurements. Further, the user interface 1400 includes a data field 1410 that enables a user to specify the date/time that the blood pressure measurement was performed.
In some examples, the patient may select any one of fields 1402-1410 to receive more information about performing the corresponding measurement. For example, the patient may select systolic blood pressure data field 1402, which causes application 1002 to display a tutorial that instructs the patient how to perform the blood pressure measurement and identify the systolic blood pressure measurement. The course may include text, text/pictures, recordings, animations and/or video. The tutorials may be stored locally as part of the application 1002 or may be stored on the clinician server 200b for remote access or streaming.
The user interface 1500 of fig. 15 is configured to be displayed by the application 1002 when the patient is scheduled to perform a manual exchange treatment and/or if the home treatment device 90 is not registered with the clinician server 200 b. Manual renal failure exchange therapy requires that the patient connect the dialysate container to their peritoneal cavity for a sustained period of time before allowing the spent dialysate to drain, all without the aid of a machine. For manual treatment, the patient needs to enter his or her manual exchange of medical information so that his or her medical history can reflect accurate treatment information.
The example application 1002 may also be configured to display the user interface 1500 when the patient is not registered with the home treatment device 90. During registration, registration module 1102 may send a message to application 1002 indicating whether home therapeutic apparatus 90 has been registered. If the home therapeutic apparatus has not been registered, the application 1002 may be configured to display the user interface 1500 and/or other user interfaces to obtain therapeutic information that may generally be transmitted by the home therapeutic apparatus 90.
In the illustrated example, the user interface 1500 includes progress of the treatment, including a solution phase, a drain phase, a fill phase, a UF or dwell phase, and a summary phase. The application 1002 may display a separate user interface for each stage prompting the patient to enter the corresponding or requested treatment information. The example user interface 1500 corresponds to the UF phase, as indicated by the highlighting box 1502. User interface 1500 includes drainage volume field 1504, UF field 1506, and fill volume field 1508. In the example shown, user interface 1500 prompts the patient to enter an amount of drainage into data field 1504 during the drainage phase and prompts the patient to enter an amount of filling into data field 1508 during the filling phase. User interface 1500 may calculate a UF value for UF data field 1506 or prompt the patient for the value.
In addition to displaying the user interfaces 1400 and 1500 at the designed time, the application 1002 may cause an alert to be displayed on the personal mobile communication device 200 a. The alert may identify which medical information is needed or include a link to either of the user interfaces 1400 or 1500. The alert may include a pop-up window displayed by the personal mobile communication device 200 a. The alert may also include an icon displayed adjacent to the icon of the application 1002 on the home screen of the personal mobile communication device 200 a. In other embodiments, the application 1002 may not inform the patient which medical information is needed. Rather, the application 1002 may enable the patient to navigate to a desired user interface to enter medical device data and/or treatment information.
In some embodiments, the application 1002 may identify at least some data fields of one or more user interfaces as requiring input, while other data fields are optional. The application 1002 may outline or otherwise graphically indicate which data fields are needed (e.g., a red frame is displayed around the systolic data field 1402). If the required data fields are not complete or are not complete within a certain time, the application 1002 may cause the personal mobile communication device 200a to display a reminder message. In some embodiments, the application 1002 may prevent the patient from navigating to another user interface until all necessary fields have been filled in for the currently viewed user interface.
After the patient inputs medical information into one or more of interfaces 1400 and 1500, application 1002 communicates the medical information to data acquisition module 1104 of clinician server 200b for entry into the patient's medical record. The application 1002 is configured to transmit medical information after the patient completes a data field in the user interface or otherwise presses a send button on the interface. In other cases, the application 1002 may transmit medical information at predetermined times, such as before and after treatment.
2. Medical information is wirelessly input to application embodiments
In some embodiments, the patient may choose to enter medical information wirelessly in their personal mobile communication device 200a. The medical information may be received in the personal mobile communication device 200a via, for example, a Bluetooth connection, a Zigbee connection, a Z-Wave connection, a wireless USB connection, a wireless RF connection, an NFC connection, an infrared connection, or any other suitable wireless communication technology. In some cases, the patient may have to wirelessly pair the personal mobile communication device 200a with a medical device (such as the blood pressure monitor 104 and/or the weight scale 106). In other embodiments, the patient activates a connection application (e.g., NFC application) that reads medical information wirelessly from the medical device.
In an example, the patient may pair their personal mobile communication device 200a with the blood pressure monitor 104. To enter blood pressure medical information into the user interface 1400 of fig. 14, the user selects, for example, systolic blood pressure data field 1402. Selection of field 1402 causes application 1002 to display a prompt requesting the patient to select a data entry method (e.g., manual, wireless, photo, etc.). After selecting the wireless option, the application 1002 displays a menu of available wireless connection options and/or a list of paired Bluetooth devices. The patient selects the blood pressure monitor 104 from the list, which causes a menu of available medical information to be displayed. The patient selects the systolic pressure, which causes the systolic pressure value to be filled in to the systolic pressure data field 1402. In some embodiments, the application 1002 is configured to read medical information from the blood pressure monitor 104 after the patient selects the device. The application 1002 may use the data tag or metadata to determine which of the fields 1402-1410 to fill in medical information from the blood pressure monitor 104.
In some embodiments, the application 1002 is configured to enable a patient to establish a permanent or semi-permanent connection with a medical device. During a setup operation, the application 1002 prompts the patient to select a data field from the user interface 1400. After selection, the application 1002 prompts the patient to select a paired wireless medical device (and/or select a data type from a menu associated with the medical device). Patient selection configures the application 1002 to automatically read medical information from the blood pressure monitor 104, for example, when new medical information is available. In other words, the application 1002 is configured to automatically wirelessly access a telemedicine device to read certain medical information to populate one or more data fields. For example, after a patient takes a blood pressure measurement using the blood pressure monitor 104, the monitor 104 sends a ping or status message to the application 1002 indicating that new data is available. Alternatively, the application 1002 may poll or otherwise ping the blood pressure monitor 104 to determine if new data is available. The application 1002 then reads the new data into one or more of the data fields 1402-1410 to automatically fill in the user interface 1400. The application 1002 then sends the medical information to the data acquisition module 1104 of the clinician server 200b to automatically update the patient's medical record.
3. Recording medical information images to application embodiments
The example application 1002 on the personal mobile communication device 200a is configured to enable a patient to enter medical information and/or therapy information by recording an image of the medical device or a screen of the medical device. The personal mobile communication device 200a uses the camera 1004 to record one or more images. Application 1002 extracts text from the recorded images using optical character recognition ("OCR"). The extracted text is filled in one or more data fields of the user interface of the application 1002. Using the images may reduce data entry errors from the patient or clinician.
In some embodiments, the application 1002 uses rules or data templates to identify which text from the image may be selected as relevant medical information for the data field. Otherwise, simply using OCR functionality allows all displayed text to be selected. Thus, the patient still has to copy and paste the text from the image into the data field. In contrast, rules or data templates may group or identify text in an image as fields, which allows a patient to easily select or automatically select to fill in data fields of a user interface.
The data templates or rules of the application 1002 are configured to organize or otherwise decode text extracted from the image. The application 1002 determines or otherwise selects one or more data templates for establishing a context of the medical information based on, for example, the location of the medical information within the image and/or the tags/keywords included within the medical information. To determine the data template, the example application 1002 may prompt the patient to specify the type of medical device from which the image was recorded. Additionally or alternatively, the application 1002 enables the patient to select a medical device template. In other embodiments, the patient may first record an image of the identifier 1012 (e.g., an identifier image) that the application 1002 uses to determine the type, model, etc. of the corresponding medical device. The application 1002 then selects a data template or rule corresponding to the type, model, screen, etc. of the medical device.
The data templates define or specify data fields of certain medical information contained in the image. Typically, the image includes extracted text composed of medical information. In some cases, not all of the extracted medical information is necessary or necessary. Instead, only certain medical information in the recorded images need be entered into the user interface or data fields of the patient medical record. The relevant medical information or relevant medical information refers to medical device data or medical information identified or selected for filling into data fields of a user interface of the application 1002, or more generally, for filling into a medical record of a patient.
Fig. 16 shows a schematic diagram of a personal mobile communication device 200a for recording and processing images for medical information extraction according to an example embodiment of the present disclosure. The illustration of the personal mobile communication device 200a is exemplary and some of the blocks may be combined, further divided, or removed. Additionally, in some embodiments, the personal mobile communication device 200a may include additional blocks of memory 1018, such as storing instructions that, when executed by the data processor 1602 (or more generally, the processor 1016), cause the application 1002 to process the image to extract medical information.
The example data processor 1602 may be configured to manage the acquisition of medical information from one or more images. Such management includes displaying one or more camera messages via screen 1002 that provide information prompting a clinician or patient (e.g., operator) to record certain images. Alternatively, the data processor 1602 may initialize the image processing mode after the patient has selected to enter medical information into one or more data fields of the application 1002 using the image entry method. Upon selection of the image entry method, the data processor 1602 is configured to acquire one or more images.
In some embodiments, the data processor 1602 causes the personal mobile communication device 200a to open a camera application to enable the patient to record one or more images. The patient may choose which recorded image will be further processed or discarded. The selected image is analyzed to identify text (as medical information) for data fields that may be filled in to one or more user interfaces of the application 1002.
In other embodiments, the data processor 1602 may instruct the patient through one or more steps for acquiring images. The data processor 1602 may execute a workflow or routine based on which data fields the patient selected. For example, the data processor 1602 performs a blood pressure workflow for obtaining images from a blood pressure monitor based on patient selection of the systolic pressure data field 1402.
In an example, the data processor 1602 of fig. 16 is configured to display a camera message identifying a medical device, a user interface window of the medical device, and/or an identifier on the medical device to be recorded. The data processor 1602 may also display a navigation message specifying a user interface window for the medical device being imaged. Further, the data processor 1602 may display a reminder message if no image is recorded for a predetermined period of time (e.g., five minutes). The message may include text that provides instructions and/or identifies the intended target for imaging. The message may also include instructions on how to navigate to a certain user interface window of the medical device using the control interface of the medical device. The message may further include graphical elements such as an exemplary illustration of the medical device, a consumable, an identifier 1012, and/or a user interface window to record an image thereof.
It should be appreciated that in some embodiments, the data processor 1602 does not display a message. Instead, the data processor 1602 reacts to the images recorded by the patient to determine relevant medical information. For example, upon receiving an indication to record an image, the data processor 1602 operates a workflow in which the application 1002 prompts the clinician to identify the medical device from which the image has been recorded. The prompt may include a drop down menu of available or common medical devices. In other examples, the data processor 1602 automatically identifies medical information using one or more data templates or data tags to determine which extracted medical information is to be filled in or written to data fields of a user interface or medical record.
To record an image, the example data processor 1602 and the image processor 1604 (more generally, the processor 1016) provide for operation of the application 1002 in conjunction with the camera 1004. The patient provides an indication via a camera user interface 1606 (e.g., a touch screen or buttons on the personal mobile communication device 200 a) to record the image. For example, when the camera is focused on the medical device user interface window or identifier 1012, the patient activates the camera user interface 1606. The data processor 1602 receives the indication and instructs the camera 1004 to record an image. The recorded images are transferred from the camera 1004 to the image processor 1604. In addition, a copy of the image is displayed by the data processor 1602 on the display interface 1022 of the personal mobile communication device 200 a.
In some embodiments, the data processor 1602 may cause a ghost to appear on the display interface 1022 that illustrates an image to be recorded. In preview mode, ghosts are provided on top of the image stream provided by camera 1004. The purpose of the ghost is to provide assistance to the clinician or patient to confirm that the image to be recorded contains the required medical information and is recorded at the appropriate distance. For example, data processor 1602 may display a ghost of a given identifier on a given medical device. The patient is aligned with the personal mobile communication device 200a such that the image stream of the identifier 1012a is positionally aligned with the ghost image. The patient may then record an image of the identifier 1012 a. In some cases, the data processor 1602 uses image analysis to determine the delta between the ghost and the image stream. The data processor 1602 may cause display of instructions that prompt the patient to move the personal mobile communication device 200a in a direction to decrease the determined increment. The data processor 1602 may determine when the increment is below a threshold to indicate that the images are aligned. Once the images are substantially aligned, the data processor 1602 may provide a graphical indication on the display interface 1022 that indicates images that may be recorded or automatically cause the images to be recorded without input from the patient.
The data processor 1602 may provide a prompt requesting the patient to accept the image. After receiving the acceptance indication via the camera user interface 1606, the image processor 1604 may analyze the image to identify or otherwise extract text. In some cases, the data processor 1602 may not prompt the clinician to accept the image. Instead, the patient may provide an indication via the camera user interface 1606 to delete the image. Before deleting an image, the image processor 1604 performs analysis to identify text.
To recognize text, the image processor 1604 uses, for example, OCR. In addition, the image processor 1604 may determine the location or position of the text relative to the center or origin of the image. In some cases, the image processor 1604 may assign two-dimensional coordinates to each character or group of characters. The location text information may be stored as metadata in an image file of the image. The image processor 1604 may also use the clock of the personal mobile communication device 200a to append a date/time (corresponding to the time when the image was recorded) to metadata associated with the image.
In addition to performing OCR to identify text, the image processor 1604 may be configured to use image analysis to identify patients, medical devices, and/or consumables. For example, the image processor 1604 may access a medical device image library to identify medical devices within the image. In this example, the image processor 104 may use an image matching routine to determine a match. Such a comparison may be made in place of the medical device having the identifier 1012. The image processor 1604 may use similar routines and/or algorithms to identify the consumable 1006.
The example data processor 1602 is configured to decode the identifier 1012 to determine the type of medical device of the consumable. Decoding may include associating the location and thickness of the lines and/or rectangles with relevant medical information. The code lines and rectangles may correspond to sequences of letters and/or numbers. For example, the data processor 1602 may use the line or rectangle of the identifier 1012 to determine a device model, medical device type, asset code, etc. The decoded identifier 1012 may provide relevant medical information for filling in one or more data fields of the user interface of the application 1002. Additionally or alternatively, the decoded identifier may be used by the data processor 1602 to select a workflow for acquiring images from a medical device or consumable and/or determining a data template.
The example image processor 1604 of fig. 16 communicates the image with the extracted or otherwise identified text and/or medical information to the data processor 1602. The example data processor 1602 uses one or more data templates, e.g., from the data template database 1608, to identify relevant medical information from the extracted text. In some examples, the data processor 1602 receives the data templates from the clinician server 200b, which may then be stored in the database 1608. In other examples, the data processor 1602 maintains a database 1608 with data templates.
Fig. 17 shows a schematic diagram of a data template 1700 according to an example embodiment of the disclosure. The image processor 1604 (e.g., application 1002) uses the example data template 1700 to identify the extracted text as relevant medical information. Typically, a screen of the medical device displays medical information. Some of the information is related to the data field content of the user interface of the application 1002. Other data may be less relevant or irrelevant. Furthermore, medical information may be located in different locations or have different labels depending on the model of the medical device. The data template 1700 is configured to specify the location and name of relevant medical information for a particular home treatment device 90.
The data template 1700 is stored in the database 1608 along with a plurality of other data templates for different types and/or models of medical devices and/or consumables. Upon receiving the identifier 1012 of the medical device (or a specification or data field of the patient's medical device), the image processor 1604 selects the corresponding data template 1700. Additionally or alternatively, the image processor 1604 may use image processing to select a data template that best matches the recorded image using, for example, information tags or text locations.
The example data template 1700 of FIG. 17 includes device data (or text) fields 1702, 1704, 1706, and 1708 that specify that certain medical information is located on a particular user interface window of a medical device. In some examples, data template 1700 is graphical such that image analysis is performed to align fields 1702 through 1708 with text extracted in an image. In other examples, the data template 1700 includes a file (or other data structure) having coordinates or locations of each of the device data fields 1702-1708 relative to an origin. The image processor 1604 uses the extracted text to identify an origin in the image and to identify text for each of the data fields 1702-1708 based on a substantial match to a location in the data template 1700. In some examples, image processor 1604 may scale the image to match the size or coordinate space of data template 1700.
In addition to coordinates and/or location, some of the illustrated data fields 1702-1708 may also include tag text. For example, device data field 1702 includes the tag text "UF Window" and device data field 1704a includes the tag text "UF Vol". The image processor 1604 matches the tag text with similar text extracted from the image. In some cases, the matches between tag text are used only to identify device data fields, rather than using location or image analysis.
A match between the tag text, including the tag text for the non-relevant device data fields, may be used to confirm that the image is from the correct window or screen of the medical device. For example, the image processor 1604 may match the tag text "ultrafiltration window" with corresponding extracted text in the relative same location of the recorded image. The match confirmation image is recorded from the ultrafiltration window of the renal failure therapy medical device. But the extracted text is not relevant medical information for the patient's medical record. If the tag text does not match the extracted text, the image processor 1604 may display a message prompting the patient to record an image of the ultrafiltration window of the renal failure therapy medical device.
The tag text associated with the device data fields 1706 and 1708 may be used to confirm that the recorded image is current or recorded for a determined period of time. For example, some windows of the medical device display the current date and time. This information may be extracted by the image processor 1604 and identified using the device data fields 1706 and 1708. The image processor 1604 compares the extracted date/time with the date/time rules or restrictions associated with the device data fields 1706-1708 to determine if the recorded image is current. For example, if the dates do not match or the time is not within a predetermined threshold (e.g., 5 minutes, 15 minutes, 60 minutes, 3 hours, etc.) of the current time on the personal mobile communication device 200a, the image processor 1604 may determine that another image needs to be recorded.
The application 1002 uses the example device data fields 1704a and 1704b of FIG. 17 to identify relevant medical information. In some cases, the application 1002 may display a flag or metadata indicating that the device data fields l704a and l704b are related to selected data fields of a user interface (e.g., user interface 1400 or 1500). By comparison, the device data fields 1702, 1706 and 1708 may include flags or metadata that indicate that the respective extracted data is not relevant. In the example shown in fig. 17, the image processor 1604 uses the tag text of the data field 1704a to locate the corresponding extracted text in the image. The image processor 1604 then uses the positional relationship between the device data fields l704a and l704b or text value markers to identify the extracted medical information corresponding to the numerical value of the ultrafiltration volume from the image. The image processor 1604 copies the extracted medical information related to the field 1704b from the image to fill out, for example, the systolic blood pressure data field 1402 of fig. 14.
As discussed above in connection with fig. 17, the data processor 1602 of fig. 16 may use the known positional relationship and text labels of the text in the image to determine which of the extracted text corresponds to the relevant medical information. In some embodiments, the data processor 1602 selects the data templates based on an indication of the model or type of medical device and/or consumable. The indication may be determined by a previous image of the identifier 1012 received from the patient via the camera user interface 1606 and/or specified by selecting a data field of the user interface for the application 1002 that will fill in medical information. In other examples, the data processor 1602 compares the data templates in the database 1608 with the image with the extracted text to find a match. In these other examples, the data processor 1602 uses the text labels and text locations between the image and the data templates to determine matches.
The example data processor 1602 is configured to, after identifying the relevant medical information, write or otherwise populate one or more data fields of a user interface of the application 1002. In some embodiments, the data processor 1602 is configured to automatically populate data fields of a user interface of the application 1002 using the data templates. To automatically populate medical information, the data processor 1602 compares text, tags, and/or metadata associated with fields of the data template with text, tags, metadata, and/or other data field information of one or more user interfaces of the application 1002. If at least some of the text, tags, and/or metadata match, the data processor 1602 identifies certain text (e.g., numerical values) corresponding to matching fields of the data template. The identified text is written to a corresponding matching data field of the user interface of the application 1002.
In other embodiments, the data processor 1602 is configured to prompt the patient to select one or more fields of the data template to fill in one or more data fields of the user interface of the application 1002. Fig. 18 shows a diagram illustrating a patient filling out data fields 1402 through 1406 of user interface 1400, according to an example embodiment of the present disclosure. In the illustrated example, the user interface 1400 is opened on the personal mobile communication device 200 a. To enter medical information into data fields 1402 through 1406, the patient selects each data field sequentially or together. For each selection, the application 1002 displays a prompt asking the patient how to enter data. After the patient selects the photo entry method, the application 1002 opens the camera application to enable the patient to record an image 1800 of the screen of the blood pressure monitor 104 using the personal mobile communication device 200 a. In some embodiments, as described above, the application 1002 may display text or graphics to assist the patient in acquiring images.
After recording the image 1800, the application 1002 performs an OCR operation to extract text. The application 1002 then determines a data template 1801 corresponding to the extracted text. In some embodiments, the application 1002 matches the location of text and/or tags within the image with the text and/or tag locations in the data template to find a matching data template. In other examples, the patient may specify an indication of the blood pressure monitor 104, which allows the application 1002 to locate the corresponding data template 1801. In other examples, the application 1002 may first prompt the patient to record an image of the identifier 1012a of the blood pressure monitor 104. The data from the identifier is used by the application 1002 to select a data template. Regardless of how the data template 1801 is identified, the application 1002 applies the data template 1801 to the extracted text in the image 1800. The process includes the application 1002 identifying groups or fields of similar text. In some cases, the application 1002 may identify groups or fields of similar text based on the spacing between letters and/or words.
In the illustrated example of fig. 18, the application 1002 provides fields 1802, 1804a, 1804b, 1806, 1808, and 1810 for different text sets. The patient selects the fields whose data is to be filled in to the selected data fields of the user interface 1400. For example, to fill out systolic blood pressure data field 1402, patient select field 1804a. Patient selection causes application 1002 to copy at least some of the data from field 1804a to data field 1402. Data field 1402 may include rules specifying that only integer values may be accepted. Application 1002 reads text from selected field 1804a to obtain an integer value (i.e., "145"). The application 1002 then populates the systolic data field 1402 with the identified integer values. The patient may continue with the other fields 1404-1410 of the user interface 1400 using the image 1800. In each case, the patient may choose between entering data manually, wirelessly, or via an image. If a second image is desired (e.g., prompted by the application 1002 or determined by the patient), the application 1002 enables the patient to record and view multiple images. The application 1002 applies the appropriate data templates to each recorded image. Accordingly, the application 1002 enables the patient to input information into the user interface 1400 using one or more recorded images as if the patient were manually inputting values.
In some embodiments, the application 1002, and more particularly the data processor 1602, performs a check on the extracted data selected by the user to ensure that the values are within a predetermined range and/or of a specified type. The application 1002 may perform similar checks on data entered manually by the patient or received wirelessly from the medical device. Each data template and/or data field of the user interface may include metadata or rules for certain fields that provide an acceptable range of thresholds or values. For example, metadata or rules for the weight data field may specify a predetermined acceptable range of values between 20kg and 200 kg. For values outside of the predetermined range, the application 1002 may display an error on the display interface 1022 or prompt the patient to record another image or modify the value.
Fig. 19 shows a flowchart of an example process 1900 for inputting medical information from an image using an application 1002 of a personal mobile communication device 200a, according to an example embodiment of the disclosure. Although process 1900 is described with reference to the flowchart shown in fig. 19, it should be appreciated that many other methods of performing the steps associated with process 1900 may be used. For example, the order of many of the blocks may be changed, some blocks may be combined with other blocks, and many of the blocks described may be optional. Additionally, the example process 1900 may include an optional box for prompting the patient to record an image of the screen and/or the identifier 1012 of the medical device.
In one embodiment, the example process 1900 begins when an application 1002 is launched on the personal mobile communication device 200a and operates with the processor 1016 to establish a wired and/or wireless connection with the clinician server 200b (block 1902). Establishing a connection may include, for example, transmitting and/or receiving one or more messages 1903, the messages 1903 providing device addresses, patient identifiers, device identifiers, network addresses, and/or protocol information for accessing and/or writing patient medical records. After opening the application 1002, the patient navigates or otherwise accesses a user interface (e.g., user interface 1400 or 1500 of fig. 14 and 15) for entering medical information (block 1904).
Prior to block 1906, the patient uses the application 1002 to select data fields and to select that medical information is to be provided via photograph entry. At block 1906, the personal mobile communication device 200a records an image 1907 of the medical device, consumable, patient, etc. The image may include an identifier of the medical device and/or a screen. The personal mobile communication device 200a then determines or identifies text within the recorded image (block 1908). For example, the personal mobile communication device 200a may perform an OCR routine on the image. In the case where the image includes a bar code and/or QR code, the personal mobile communication device 200a decodes the bar code and/or QR code. The imaged or encoded data is converted to texture or american standard code for information interchange ("ASCII") characters. In some embodiments, the personal mobile communication device 200a may also determine a data field for the identified text (block 1910). The data fields may be determined using, for example, a data template. As described above in connection with fig. 17 and 18, the data template may specify the location of certain text and/or a label specifying certain text that is used to operatively place the data field over the identified text within the recorded image. In some cases, the data fields and/or data templates may be selected by the patient and/or determined by the identifier 1012 of the medical device. Alternatively, in addition to using templates, process 1900 may provide an indication that the most recently recorded image has relevant medical information for extraction, selection, and/or transmission.
In one embodiment, the example process 1900 continues by determining whether there are other images to record (decision block 1912). In an example, process 1900 can access a list of images that need to be recorded for a particular therapy or treatment. The process 1900, via the personal mobile communication device 200a, can be performed by sequentially directing the patient to obtain all of the desired images, or providing prompts to obtain images containing medical information determined to be desired or lost. In other cases, the patient may determine which images are needed. If additional images are to be recorded, process 1900 returns to block 1906.
If no additional images are needed, as determined at decision block 1912, the patient begins the process of filling relevant medical information into the data fields of the user interface. The process in the illustrated embodiment includes enabling the patient to select an image from which to transmit relevant medical information. The selection of the image causes the personal mobile communication device 200a to display the image on the display interface 1022 (block 1914). It will be appreciated that the selected image includes the identified text and optionally the data fields. The patient may also specify the data fields (or locations in the data fields) of the user interface to which the data is to be filled.
The personal mobile communication device 200a receives a selection of relevant medical information and/or data fields having relevant medical information for filling it into the design data fields of the user interface of the application 1002. The selection may be performed by the patient pressing an area of the touch screen 1002 of the personal mobile communication device 200a corresponding to the medical information to be filled out. In an embodiment, selection of the relevant medical information and/or fields causes the personal mobile communication device 200a to automatically fill in at least a portion of the selected text (block 1916).
After the selected text has been filled in, the personal mobile communication device 200a determines whether additional related medical information is to be filled in based on the selection of the additional data fields of the user interface (decision block 1918). In some examples, the personal mobile communication device 200a operates a sequence or routine that provides prompts to the patient to select appropriate text and/or images for filling in the data fields. If additional relevant medical information is present, as determined by decision block 1918, process 1900 returns to blocks 1914 and 1916 where the patient fills out the specified image and/or relevant medical information for the image field. If, as determined by decision block 1918, no other relevant medical information exists for filling out, the example process 1900 ends.
4. Image/text attachment application embodiments
In some embodiments, the example application 1002 and clinician server 200b are configured to enable a patient to provide images or text as an attachment or appendix to his medical record. In the section above, the application 1002 provides the data fields of the user interface as a hint for the desired information. In some cases, however, the patient or clinician may wish to provide additional information. Additionally or alternatively, one or more user interfaces of the application 1002 may include data fields for free text input, prompts for patient input text (e.g., "how you feel today"), or features that enable photos or images to be incorporated into a portion of a record. For example, the user interface 1400 may include a photo icon adjacent to a prompt for an image to be fluidly connected to the patient's abdomen, which when selected, will open a camera application to enable the patient to attach an image for transmission with medical information. The images can be stored to design fields in the appropriate patient medical record.
The example application 1002 on the personal mobile communication device 200a is configured to accept images and/or text provided by a patient. In an embodiment, the application 1002 is configured to enable a patient to select between text or photo entry. If the patient selects text entry, application 1002 displays a text box. The patient enters information into the text box, which is stored by the application 1002. The application 1002 may then transmit the information in one or more messages to the clinician server 200b. The application 1020 on the clinician server 200b determines the appropriate patient medical record in the database 1010 and locates the "notes" or free text fields. The application 1020 stores the text provided by the patient in this field. In some cases, the application 1020 may also include a time/date stamp with the entered text. This information provides additional information to the clinician from the patient, including feedback regarding the treatment.
Fig. 20 illustrates an example of a user interface 2000 that may be displayed by an application 1002 on a personal mobile communication device 200a, the user interface 2000 enabling a patient to provide recorded images, according to example embodiments of the present disclosure. The example user interface 2000 includes an image title field 2002 that may be edited by the patient. The user interface 2000 also includes one or more recorded images 2004, or previews of recorded images. The application 1002 is configured to enable a patient to browse through gallery folders of recorded images to select which images to transmit. The date field 2006 and time field 2008 provide information in the user interface 2000 indicating the date/time of recording the displayed image. The patient may select the "trash" button to discard the image 2004, or may select the "upload" button to transfer the image 2004 from the application 1002 to the clinician server 200b. The example photo capture feature of application 1002 enables a patient to archive a physiological condition that is connected to a fluid line of home therapeutic device 90 or that is relevant to treatment. The application 1020 at the clinician server 200b is configured to attach or otherwise link the received image 2004 to a medical record of the patient.
5. Medical information embodiment via text manual/wireless/image entry
In some embodiments, the personal mobile communication device 200a of fig. 10-12 may not be able to install or operate the application 1002, or the patient may decide not to install the application 1002. However, the clinician server 200b is still registering the personal mobile communication device 200a during the registration process. In addition to receiving medical information via the application 1002, the data acquisition module 1104 of the clinician server 200b determines to execute a routine or algorithm to prompt or otherwise obtain medical information from the patient via the personal mobile communication device 200a. The example data acquisition module 1104 can read the patient's registration file and/or medical record to determine that the personal mobile communication device 200a is registered but the application 1002 is not installed.
In some embodiments, the data acquisition module 1104 is configured to obtain medical information from the patient via one or more text messages. For example, at a design time corresponding to a time of prescribed treatment, the data acquisition module 1104 may transmit one or more text messages prompting the patient to respond with medical information using the registered personal mobile communication device 200 a. In other cases, the data acquisition module 1104 is configured to begin a sequence or routine for acquiring medical information in response to text from a patient. In other cases, the patient may send a text message with medical information and/or images to the data acquisition module without a reminder message.
The example data acquisition module 1104 of fig. 11 is configured to format or otherwise construct the received information for filling in one or more data fields of a patient medical record. Typically, the medical information received from the text message is unstructured. In other words, the text message does not provide a clear association or reference to the design fields of the patient medical record. Rather, the data acquisition module 1104 is configured to determine the appropriate fields of the medical information received in the text message.
In some embodiments, the data acquisition module 1104 uses the context of the text message received from the personal mobile communication device 200a to determine the data field. For example, the patient may send a message including the text "systolic blood pressure 145". The data acquisition module 1104 compares at least some text (e.g., one or more words in a string) to field data tags, keywords, and/or metadata. If at least some of the words match, the data acquisition module 1104 is configured to identify a value in the content of the text message and write the identified value in a data field of the patient medical record corresponding to the matching text. In some embodiments, the data acquisition module 1104 may compare the value to an acceptable range of values prior to writing the value. If the value is outside of an acceptable range, the data acquisition module 1104 may send a message to the personal mobile communication device 200a indicating an error or a message prompting the patient to reenter the value.
In these embodiments, the data acquisition module 1104 may be configured to send subsequent text to the patient if text from the received text message cannot be properly placed into the data field. For example, the data acquisition module 1104 may receive a message with text including "blood pressure 145". The data acquisition module 1104 determines that the message may correspond to a "systolic" or "diastolic" blood pressure data field based on the matching text. Thus, the data acquisition module 1104 sends a message to the personal mobile communication device 200a with text asking the patient whether the value is "systolic pressure" or "diastolic pressure".
In other embodiments, the data acquisition module 1104 prompts the patient to provide certain medical information via a series of messages (which may be defined by routines or algorithms). The order of the sequence is known or defined and corresponds to the data fields in the medical record. In this way, the data acquisition module 1104 automatically determines that the response to a prompt corresponds to a data field of a medical record associated with the prompt. For example, the data acquisition module 1104 sends a text message prompting the patient to make a "systolic blood pressure measurement". The data acquisition module 1104 determines that the response to the text contains a value for "systolic blood pressure measurement". The data acquisition module 1104 may analyze the received message to identify values in other text and/or compare the values to acceptable ranges. After confirming that the patient provided an acceptable response with medical information, the data acquisition module 1104 determines a subsequent message to send to the personal mobile communication device 200a based on the message sequence.
In addition to receiving messages with text, the data acquisition module 1104 may also receive messages with photo attachments. Similar to the process described above in connection with fig. 16-19, the data acquisition module 1104 is configured to process the images to extract text and identify relevant medical device data for one or more data fields of the medical record. Furthermore, while the above disclosure describes the use of text messages, the data acquisition module 1104 may additionally or alternatively receive medical information and/or photos via other communication media such as email, instant messaging, or Web-based messages, social media posts, and the like.
Fig. 21 shows a schematic diagram of a patient medical template 2100 that can be used by the data acquisition module 1104 of the clinician server 200b to populate data fields of a patient medical record, according to an example embodiment of the disclosure. The fields of the template 2100 can correspond to or otherwise be linked or referenced to data fields of a patient medical record. In other embodiments, a copy of the completion template 2100 can be stored to the medical record or as the medical record itself. In some embodiments, the patient medical template 2100 can be part of or otherwise integrated with a patient medical record.
The example template 2100 includes predefined fields 2102, 2104, 2106, 2108, 2110, 2112, 2114, 2116, 2118, and 2120, which correspond to renal failure therapy ("RFT"). The example data acquisition processor 1104 may select the template 2100 based on a therapy prescribed for the patient. Although an RFT template 2100 is shown, the example data acquisition module 1104 may select other templates specifically configured for pre-treatment data acquisition, post-treatment data acquisition, and the like. For example, the pre-treatment acquisition template may include data fields for blood pressure, pulse, and weight.
It should be appreciated that in other embodiments, the patient medical template 2100 may include more or fewer fields. For example, the template 2100 may additionally include data fields for pre-and post-treatment patient weight, patient glucose level, and/or patient date of birth. In another example, the template 2100 may include fields for fill rate, dwell time, drain or fluid removal rate, blood flow rate, outflow dose, ultrafiltration removal rate, dialysate removal rate, total dialysate infused, dialysate flow, pre-exchange flow, post-exchange flow, patient weight balance, return pressure, excess patient body fluid, filtration fraction, time remaining, dialysate concentration, dialysate name, patient identifier, room identifier, care area identifier, time stamp indicating when data was generated, alarm condition, alert condition, and/or event.
In some embodiments, the data acquisition module 1104 is configured to select the template 2100 based on prompts from the patient. For example, the patient may send a message to the data acquisition module 1104 that includes "manually exchanged" text. In response, the data acquisition module 1104 identifies and selects the template 2100 for manual exchange. In another example, the patient may send a message to the data acquisition module 1104 via the personal mobile communication device 200a that includes text of "pre-treatment" or "start treatment. In response, the data acquisition module 1104 identifies and selects templates for acquiring medical information required prior to the initiation of treatment.
In the example shown in fig. 21, example data fields include a field 2102 for a patient name, a field 2104 for a patient identifier, a field 2106 for a patient weight, a field 2108 for a patient blood pressure, a field 2110 for a treatment date, a field 2112 for removing UF amounts, a field 2114 for a total fluid amount provided to the patient, a field 2116 for a glucose level, a field 2118 for a treatment prescription identifier, and a field 2120 for a disposable cassette identifier. In the event that renal therapy device 90 is registered with clinician server 200b, data acquisition module 1104 may remove at least fields 2112 through 2120 (or alternatively omit a separate template having fields 2112 through 2120) because such information is already provided by machine 90. But if the patient is reporting a manual change, fields 2112 through 2120 may be used in the template. In addition, the template 2100 may omit fields 2102 and 2104 based on at least some patient information already registered.
The example data fields of the patient medical template 2100 may be filled in from one or more different sources of medical information, including device information, patient information, and/or consumable information. For example, the patient name field 2102 and the patient identifier field 2104 may be filled in from images recorded by the personal mobile communication device 200a of the patient's identifier 1012 (or the patient's worn identifier 1012). The blood pressure field 2108 may be filled in from an image recorded by the personal mobile communication device 200a of the screen of the blood pressure monitor 104, while the body weight field 2106 may be filled in from an image recorded by the personal mobile communication device 200a of the screen of the scale 106. Date field 2110, remove UF field 2112 and fluid fill-out field 2114 may be filled out from images recorded by personal mobile communication device 200a of the screen (showing a treatment status window) of home treatment instrument 90. Similarly, the dextrose level field 2116 may be filled from an image recorded by the personal mobile communication device 200a of the screen (setting window shown) of the home treatment instrument 90, while the prescription identifier field 2118 may be filled from an image recorded by the personal mobile communication device 200a of the screen (setting window shown) of the home treatment instrument 90. Finally, the cartridge identifier field 2120 may be filled out from an image recorded by the personal mobile communication device 200a of the identifier 1008 of the disposable cartridge consumable 1006. As described above, the data acquisition module 1104 may receive one or more messages having text for the fields 2102 to 2120, in addition to receiving images containing medical information.
The patient medical template 2100 shown in fig. 21 is configured to be stored on the clinician database 1010 and accessed by the clinician server 200b shown in fig. 10 and 11. Upon receiving a request to fill out a template for a patient, the clinician server 200b is configured to make a copy of the template 2100 or create an instance of the template 2100. Medical information received from the personal mobile communication device 200a is entered by the data acquisition module 1104 into the appropriate data fields 2102 to 2120 of the copy or instance of the template 2100. Once completed, the copies or instances are stored as medical records of the patient in the clinician database 1010 repository.
In some embodiments, the data acquisition module 1104 operates the routine 2150 in conjunction with or in lieu of the example patient medical template 2100. In some embodiments, the routine 2150 may be programmed as metadata or computer executable code for the various data fields 2102 through 2120. In other examples, routine 2150 may be stored in clinician database 1010 in association with patient medical template 2100. Further, in these other examples, selecting template 2100 causes routine 2150 to be performed. Example routine 2150 includes routine modules 2152 through 2164 that provide associations between data fields 2102 through 2120 and corresponding medical devices, identifiers 1012, and/or consumables 1006.
At least some of the routine modules 2152 to 2164 may be associated with or otherwise related to a data template (e.g., the data template 1700 of fig. 17). The data acquisition module 1104 is configured to access the data templates for the respective routine modules 2152 to 2164 when the patient provides images and/or text in the message. For example, while executing the routine module 2156 for blood pressure, the data acquisition module 1104 sends a message prompting the personal mobile communication device 200a to make a "systolic blood pressure measurement". The patient responds with a text message containing an image of the screen or dial of the sphygmomanometer 104. The data acquisition module 1104 is configured to access a data template corresponding to or referencing the routine module 1156 for blood pressure measurement. The data acquisition module 1104 then applies the data template to extract text from the image using the process described above in connection with fig. 16-19 to identify relevant systolic blood pressure medical information for filling in the blood pressure data field 2108 of the template 2100.
The example routine 2150 may be configured to begin upon a request from the patient based on one or more messages received by the data acquisition module 1104. For example, the data acquisition module 1104 may receive a message with text that includes "start", and/or "pre-processing". Receipt of this message causes the data acquisition module 1104 to determine and initiate the routine 2150 to fill in the data fields 2102 through 2120 of the template 2100. In other examples, the data acquisition module 1104 sends the first message specified by the routine 2150 to the patient at a predetermined time related to the treatment. After receiving a response message with the appropriate medical information from the personal mobile communication device 200a, the data acquisition module 1104 sequentially transmits the message specified by the routine 2150. In this way, the data acquisition module 1104 controls the acquisition of medical information from the patient according to a predetermined sequence. Until an appropriate response message is received from the personal mobile communication device 200a (and medical information is filled into the specified data fields 2102 to 2120 of the template 2100), the data acquisition module 1104 does not send the next message in the order defined by the routine 2150.
In the example shown, the patient ring module 2152 may include metadata or a pre-formatted message that instructs the patient to record an image of the patient's wristband. The patient ring module 2152 may also include a character validation check to ensure that the received medical information meets the textual requirements of the patient name and/or patient identifier. For example, the patient ring module 2152 may reject or discard medical information including the digital patient name.
The weight scale module 2154 may include metadata or a pre-formatted message indicating an image of the patient record identifier 1012c and the screen of the weight scale 106 of fig. 10. The weight scale module 2154 may also include a character validation check to ensure that the received medical information is within an acceptable range of values and/or the correct unit type. In some cases, the weight scale module 2154 may use the medical information from the identifier 1012c to confirm that the medical information from the screen of the weight scale 106 is patient weight medical information. In other cases, the medical information from the identifier 1012c is used to select a data template based on, for example, the model or type of the weight scale 106. The data acquisition module 1104 uses the data templates to identify relevant weight scale medical information extracted from images of the screen of the weight scale 106.
The blood pressure module 2156 is similar to the weight scale module 2154 with respect to the blood pressure monitor 104. Renal failure therapy ("RFT") modules 2158 to 2162 are also similar to weight scale module 2154. However, for each different window from which medical information is needed, multiple modules 2158 to 2162 are used for home treatment appliance 90 (or manually exchanged). For example, module 2158 provides a message for acquiring an image of identifier 1012 of home treatment instrument 90 and a first window showing a treatment status window, while module 2160 provides one or more messages for acquiring an image of a setup window of home treatment instrument 90, and module 2162 provides one or more messages for acquiring an image of a prescription window of home treatment instrument 90.
The cartridge module 2164 may include metadata or preformatted messages indicating images of the clinician or patient record identifier 1008, the disposable cartridge consumable 1006, and/or labels on the package or cartridge consumable itself. It should be appreciated that routine 2150 may include additional modules if patient medical template 2100 includes additional data fields, or routine 2150 may include fewer modules if template 2100 includes fewer fields.
Once the medical information is received using routine 2150, data acquisition module 1104 of application 1020 uses a data validation check to ensure that the data is within acceptable limits, properly formatted, and/or in the proper units. In some cases, the modules of the routine 2150 may include conversion or formatting instructions that are used by the data acquisition module 1104 to prepare medical information to be included in the template 2100 and/or corresponding fields of the patient's medical record. Once the data is in the proper format and unit, the data acquisition module 1104 writes the medical information to the template 2100 and/or corresponding fields of the patient's medical record.
In alternative embodiments, the patient medical template 2100 may not have an associated routine. In contrast, the data acquisition module 1104 of fig. 11 is configured to read the data fields 2102-2120 of the patient medical template 2100 to determine incomplete data fields, for example. In these alternative embodiments, the data acquisition module 1104 identifies the lost data and transmits one or more messages to the personal mobile communication device 200a prompting the patient for the lost data.
To fill out the data fields, in some embodiments, the data acquisition module 1104 may read the names of the data fields 2102 to 2120 (and any corresponding metadata) to create and send a message to the patient prompting to record certain images. In an example, the weight data field 2106 includes metadata identifying the weight scale as a related medical device. The data acquisition module 1104 determines that the data field 2106 is not filled in, reads the corresponding metadata, and constructs a message indicating that the patient of the personal mobile communication device 200a records an image of the screen of the weight scale. In the illustrated embodiment, the data acquisition module 1104 can, in turn, search for unfilled data fields in the template 2100 (or patient's medical record) and request medical information from the patient via a message displayed by the personal mobile communication device 200a accordingly. Alternatively, the data acquisition module 1104 may pass through the template 2100 according to a predetermined order or sequence. For example, the data acquisition module 1104 may first search for data fields associated with a patient wristband and then search for data fields for a weight scale medical device, a blood pressure medical device, and a renal failure therapy medical device.
Fig. 22 is a schematic diagram of a data acquisition module 1104 of the clinician server 200b of fig. 11 according to example embodiments of the disclosure. It should be appreciated that the illustration of the data acquisition module 1104 is exemplary and that some blocks may be combined, further divided, or removed. Additionally, in some embodiments, the data acquisition module 1104 may include additional boxes, such as boxes for user interfaces.
The example data acquisition module 1104 (and more generally, the clinician server 200 b) includes an interface 2202 that provides connectivity to the personal mobile communication device 200a. Interface 2202 may include, for example, an internet port or connection. In one embodiment, interface 2202 is configured to receive messages from personal mobile communication device 200a and convert them to a format compatible with internal processing. For example, interface 2202 may convert an SMS or text message to HL7 or ASCII format. The example interface 2202 is also configured to format or convert messages for transmission to the personal mobile communication device 200a. In some cases, interface 2202 may encrypt messages for transmission and/or decrypt received messages.
The example data acquisition module 1104 includes a template processor 2204, the template processor 2204 being configured to manage writing or filling of medical information from the personal mobile communication device 200a to the patient medical template 2100 or medical records. For example, upon request from a patient or clinician, or automatically, the template processor 2204 selects a template from the patient medical template database 2206. The template processor 2204 uses the selected template (e.g., template 2100 of fig. 21) to operate a routine (e.g., routine 2150), if available or configured, to obtain medical information from the personal mobile communication device 200 a.
The example template processor 2204 is configured to identify messages from modules of a routine (e.g., routine 2150) for transmission to the personal mobile communication device 200a. In some cases, the messages may be transmitted in a predetermined order to guide or guide the clinician or patient through the process of filling out the patient medical template. For example, the template processor 2204 may read the module 2156 of the routine 2150 of fig. 21 and determine a message to transmit prompting the patient to record an image of the identifier 1012c of the scale 106. The template processor 2204 may be configured to wait until medical information (for filling in the data field 2106 of fig. 21) relating to the identifier 1012c is received before identifying a message from the routine module 2156 to be transmitted. In other cases, the template processor 2204 selects a message to send based on the message received from the personal mobile communication device 200a. For example, the processor 2204 may receive medical information associated with an identifier 1012c of the weight scale 106. In response to the received medical information, the template processor 2204 may determine that the module 2154 corresponds to the received data and, thus, select a message prompting the patient to record an image of the screen of the weight scale 104. As shown in fig. 22, the personal mobile communication device 200a displays a text message from the template processor 2204 instructing the patient to record an image of the screen 2220 of the weight scale 106.
In addition to sending messages, the template processor 2204 may be configured to select a data template. In the illustrated embodiment, the data templates are stored in a data template database 2208. The template processor 2204 selects a data template based on the type or model of medical device indicated in the medical information corresponding to the identifier 1012. In some cases, the patient may specify the model and/or type of medical device type to the template processor 2204 via a message. Further, as described above, the template processor 2204 may receive images from the personal mobile communication device 200a, extract text from the images, and select an appropriate data template from the database 2208 to identify relevant medical information from the image(s) as described above.
In some embodiments, the template processor 2204 can receive a message stream from the personal mobile communication device 200a containing substantially all of the medical information for the patient medical template 2100 or patient medical record. In these embodiments, the template processor 2204 reads tag, metadata, and/or device data field information provided with the data to determine the data fields of the template 2100 to which the data is to be filled or written. For example, the template processor 2204 matches the metadata or information of the module (or the data fields 2102 to 2120 themselves) with tags, metadata, and/or device data field information provided by medical information to determine the appropriate data fields of the template 2100.
After filling in or otherwise completing the patient medical template, the template processor 2204 of fig. 22 is configured to store the completed template to the clinician database 1010. This can include filling in the patient's medical record using the template 2100, wherein fields in the template correspond to, are linked to, or reference fields in the patient's medical record. In other examples, writing the medical record can include storing the filled-in template into the patient's medical record or storing the template 2100 as the medical record itself.
Fig. 23 and 24 are flowcharts of example processes 2300 and 2350 of filling out the medical device template 2100 of fig. 21 using images recorded by (and/or text messages received from) the personal mobile communication device 200a of fig. 10-12 and 22, according to example embodiments of the present disclosure. Although processes 2300 and 2350 are described with reference to the flowcharts shown in fig. 23 and 24, it should be appreciated that many other methods of performing the steps associated with processes 2300 and 2350 may be used. For example, the order of many of the blocks may be changed, some blocks may be combined with other blocks, and many of the blocks described may be optional. In an embodiment, the order of the blocks may be modified if there is no permanent connection between the clinician server 200b and the personal mobile communication device 200 a. Instead, in an embodiment, the personal mobile communication device 200a may first acquire and queue substantially all relevant medical information for the patient medical template until a connection is available (or by design) with the clinician server 200 b. The actions described in processes 2300 and 2350 may be performed between a plurality of devices including, for example, personal mobile communication device 200a and clinician server 200 b.
The example process 2300 begins in fig. 23 (block 2302) when the clinician server 200b of fig. 10-12 and 22 receives the message 2301 from the personal mobile communication device 200 a. Message 2301 indicates a treatment to be performed on the patient or a request to begin sending medical information. The clinician server 200b then determines a patient medical template (e.g., the patient medical template 2100 of fig. 21) based on the type of treatment specified in message 2301 or the prescribed treatment specified in the patient medical record (block 2304). In the event that clinician server 200b only provides a template that completes one type (e.g., a template for renal failure therapy), message 2301 may indicate a request to begin filling in a blank template. In response to message 2301, clinician server 200b creates a copy of the patient medical template for filling out.
After providing the patient medical template for filling out, the clinician server 200b determines at least one medical device from which medical information is needed (using a routine associated with the template or reading the template itself), and transmits a first camera message 2305 to the personal mobile communication device 200a accordingly (block 2306). The first camera message 2305 includes instructions indicating that an image, such as an identifier 1012 of a medical device, is to be recorded. After a period of time, clinician server 200b receives message 2307, message 2307 including medical information indicating a type of medical device (e.g., medical information from identifier 1012 a) (block 2308). The clinician server 200b then determines a device data template (e.g., device data template 1700 of fig. 17) based on information included in the message 2307 or specified in the patient's medical record (block 2310). For example, after the determination message 2307 identifies the blood pressure monitor 104 (type and/or model), the clinician server 200b determines or locates a device data template for the blood pressure monitor. The clinician server 200b loads a device data template for identifying relevant medical device data from the images received from the screen of the blood pressure monitor 104 (block 2312).
The example process 2300 continues in fig. 24, wherein the clinician server 200b transmits a second camera message 2313 to the personal mobile communication device 200a (block 2314). The second camera message 2313 may be determined based on the type of medical device specified by the message 2307. In addition, the second camera message 2313 may include information for displaying a certain window (or related medical information) on the medical device for recording an image. After a period of time, the clinician server 200b receives a message 2315, the message 2315 including text or images from a window of the medical device (block 2316). The example clinician server 200b extracts relevant medical information from the image using the identified data templates and determines or otherwise identifies data fields of the patient medical template corresponding to the relevant medical information (block 2318). If the message 2315 includes text, the clinician server 200b determines or otherwise identifies data fields in the patient medical template corresponding to the relevant medical information. Next, the clinician server 200b populates the data fields of the determined and/or identified templates with the received relevant medical information (block 2320).
After filling in the relevant data fields, the example clinician server 200b determines whether additional relevant medical information is required from the medical device associated with the received relevant medical information (decision block 2322). For example, the clinician server 200b may determine that the current medical device may include additional windows or operating displays from which relevant medical information still needs to be obtained. If additional medical information is needed, the example clinician server 200b returns to block 2314 and transmits a camera message 2313 for another window for which relevant medical information is needed. However, if additional medical information for the current medical device is not needed, clinician server 200b determines if medical information from other medical devices (or consumables 1006) is needed (decision block 2324). If additional medical information is needed, the clinician server 200b returns to block 2306 and transmits a camera message 2305, the camera message 2305 identifying another medical device for imaging or receiving relevant medical information therefrom. If additional medical information is not needed to complete the patient medical template 2100, the example clinician server 200b stores the completed patient medical template 2100 to the clinician database 1010 as a medical record for the patient and the process 2300 ends.
An example process 2350 begins in fig. 23 by the personal mobile communication device 200a transmitting a message 2301 indicating a request to perform a treatment on a patient or to begin inputting medical information (2352). Next, the personal mobile communication device 200a receives the camera message 2305 from the clinician server 200 b. The personal mobile communication device 200a uses the information from the message 2305 to display a reminder to the patient (block 2354). The prompt may specify, for example, an identifier 1012 of the medical device to be imaged. The personal mobile communication device 200a then records an image of the identifier 1012 of the medical device based on the input from the patient (block 2356). In some embodiments, if the identifier is not available or the patient does not want (or cannot) to record an image, the patient may enter text specifying the type/model of medical device or select from a drop down menu.
After recording the image of the identifier 1012, the personal mobile communication device 200a extracts or otherwise determines the medical information encoded in the identifier (block 2358). The personal mobile communication device 200a transmits the medical information extracted in message 2307 to the clinician server 200b. In some embodiments, personal mobile communication device 200a sends the recorded image within message 2307.
Thereafter, the personal mobile communication device 200a receives a camera message 2313 from the server 200b, the camera message 2313 having information for displaying a prompt to the patient for recording an image of a screen (or other designated area) of the medical device (block 2360). The personal mobile communication device 200a accordingly displays a prompt to the patient with the information needed for imaging the medical device. In response to the prompt, the patient uses the personal mobile communication device 200a to record an image of the screen (or other designated area) of the medical device (block 2362).
In fig. 24, the example process 2350 continues with the creation of a text message by the personal mobile communication device 200a with recorded images or text entered by the patient (block 2364). In some examples, the patient may modify or specify the medical information. The personal mobile communication device 200a then transmits a message 2315 including the medical information or an image thereof (block 2366).
Next, the example personal mobile communication device 200a determines whether additional related medical information is required from the medical device associated with the extracted related medical information (decision block 2368). The determination may include, for example, checking to see if additional camera messages related to the current medical device are received from the clinician server (block 2360). If additional medical information is needed, the example personal mobile communication device 200a returns to block 2360 and processes a camera message 2313 for another window (or portion of medical device/consumable) for which relevant medical information is needed. However, if additional medical information is not needed for the current medical device, the personal mobile communication device 200a determines if medical information from other medical devices (or consumables 1006) is needed (decision block 2370). If additional medical information is needed, the personal mobile communication device 200a returns to block 2354 and processes the camera message 2305 identifying another medical device for imaging. If additional medical information is not needed for completing the patient medical template, the example personal mobile communication device 200a ends the session, ending the process 2350.
6. Manual/wireless/image medical information entry via Web browser or file transfer
In some embodiments, the data acquisition module 1104 of fig. 11 is configured to enable patients to input medical information or provide images via a Web browser or file transfer program using their personal mobile communication devices 200 a. The Web browser or file transfer program enables the personal mobile communication device 200a to provide medical information and/or images without using the application 1002. In this embodiment, the clinician server 200b hosts a website, API, and/or file transfer site assigned an address or uniform resource locator ("URL"). The Web browser or file transfer program on the personal mobile communication device 200a is configured to access a hosted website, API, and/or file transfer site to transfer medical information.
In some embodiments, the data acquisition module 1104 is configured to prompt the patient to enter a user name and password to access a website or file transfer site. In other embodiments, the data acquisition module 1104 determines the personal mobile communication device 200a that has been previously registered and provides access. In other embodiments, the data acquisition module 1104 provides a mailbox or other interface (e.g., an API) to receive medical information or images without providing the personal mobile communication device 200a with access to a more secure location.
Once the patient has gained access via the personal mobile communication device 200a, in some embodiments, the data acquisition module 1104 provides a graphical user interface that prompts the patient for medical information and/or images. The user interface may be similar to user interfaces 1400 and 1500 described in connection with fig. 14 and 15. Similar to the personal mobile communication device 200a containing the application 1002, the clinician server 200b provides a user interface and data fields for receiving medical information. The data acquisition module 1104 may also enable the patient to select a data entry method, such as text or images.
In some embodiments, the clinician server 200b may provide a menu to enable the patient to select an appropriate user interface. In other embodiments, clinician server 200b may select a user interface requiring medical information based on prescribed therapy or therapy information provided by the patient. In other embodiments, the application 1020 of the clinician server 200b may operate a routine 2150, the routine 2150 providing graphical prompts for medical information.
Fig. 25 shows a diagram of a clinician server 200b hosting a website or file transfer site to receive medical information via images from a personal mobile communication device 200a, according to an example embodiment of the present disclosure. In the example shown, personal mobile communication device 200a is operating a Web browser application 2500 directed to a Web site 2502 hosted by clinician server 200 b. Website 2502 includes a graphical user interface for inputting medical information. In this example, the personal mobile communication device 200a records an image 1800 of the screen of the blood pressure monitor 104 of fig. 10. Clinician server 200b applies data template 1801 to the image to extract a text set, as shown in fields 1802, 804, 1806, 1808, and 1810. The patient selects fields 1802, 804, 1806, 1808, and 1810 of one or more selected data fields to be filled with text to website 2502. In this way, the clinician server 200b enables the patient to provide medical information via a website, file transfer program, or API(s).
C. data access module embodiment
Returning to fig. 11, the example data access module 1106 is configured to provide patients and clinicians with access to medical information stored in medical records of the clinician database 1010. As described above in connection with the data acquisition module 1104, there are different possible configurations of the personal mobile communication device 200a in which the application 1002 may or may not be installed. The data access module 1106 is configured to provide access to or otherwise display data based on the configuration. To determine which configuration a particular patient is using, the example data access module 1106 is configured to access a registry or patient's medical records to identify registered personal mobile communication devices 200a and/or whether the application 1002 is installed.
In some embodiments, the data access module 1106 is configured to provide medical information differently based on the operating system of the personal mobile communication device 200a and/or the capabilities of the personal mobile communication device 200 a. For example, a first subset of medical information may be designated for a rich personal mobile communication device 200a, while a second subset of medical information may be provided for a reduced-function personal mobile communication device 200 a. Based on the registration information, the data access module 1104 determines whether the application 1002 is running on a rich or reduced-function device and selects a first or second subset of the corresponding medical information.
The example data access module 1106 can also determine whether to convert medical and/or therapeutic information in a patient medical record to a different format prior to transmission. For example, medical information and/or treatment information can be stored in a medical record in HL7 format. But such formats are disadvantageous for text messages and/or applications. The example data access module 1106 determines the capabilities of the personal mobile communication device 200a to which the data is to be transferred. The data access module 1106 determines capabilities based on registration information indicating whether the application 1002 is installed and/or whether the personal mobile communication device 200a is a rich-function device. To view medical information on application 1002, data access module 1106 converts the medical information and/or therapy information from HL7 format to, for example, hypertext markup language ("H TM L") format, javaScript object notation ("JSON") format, or XML format (e.g., application format) using one or more APIs. If the data access module 1106 determines that the application 1002 is not installed, the data access module 1106 converts the information from the HL7 format to a text message or SMS message format via, for example, one or more APIs. Thus, the example data access module 1106 enables a patient to view patient medical record information regardless of the capabilities of their personal mobile communication device 200 a.
1. Information display embodiment via application
In some embodiments, the data access module 1106 is configured to display medical and/or therapeutic information via the application 1002 installed on the personal mobile communication device 200 a. In these examples, the data access module 1106 provides medical information from one or more medical records for display in particular fields, graphics, etc. of one or more user interfaces provided by the application 1002. In some cases, fields from medical records are referenced to fields of a user interface of the application 1002.
Fig. 26-29 illustrate diagrams of an application 1002 on a personal mobile communication device 200a displaying medical information provided by an access module 1006, according to an example embodiment of the present disclosure. The application 1002 may be configured to display different user interfaces 2600, 2700, 2800, and 2900 upon selection by the patient. In some cases, the application 1002 provides a menu or other selectable graphical feature listing the different user interfaces available. The application 1002 can be configured to receive medical information via one or more APIs linked to data fields of patient medical records. In other words, medical information from medical records is inserted into blank templates that define a graphical user interface for displaying the medical information.
User interface 2600 of fig. 26 provides a first graph 2602 and a second graph 2604, the first graph 2602 showing total UF removed daily, and the second graph 2604 showing average UF removed per individual circadian exchange. It should be appreciated that the medical information displayed within charts 2602 and 2604 may originate from home therapeutic device 90 and/or one or more medical devices. Once the information has been stored in the patient's medical record, the data access module 1106 of the clinician server 200b provides access to medical information from different sources, thereby providing transparency of the information to the patient.
User interface 2600 is configured to enable the patient to select data points on charts 2602 and 2604 to provide additional treatment information. User interface 2600 also enables the patient to select a time range for charts 2602 and 2604. After receiving the selection, the application 1002 transmits a message indicating the selection to the data access module 1106. In turn, the data access module 1106 provides the requested medical information.
The example user interface 2700 of fig. 27 shows the average drain time for each UF exchange. The drain time is provided in graph 2702. Between user interfaces 2600 and 2700, the patient can evaluate the progress of the treatment over time. Any deviation in treatment should be apparent and help persuade the patient to adhere to the prescribed treatment.
The example user interface 2800 includes a calendar indicating the number of days a patient adheres to a treatment or therapy as compared to the number of days the patient does not adhere to a treatment. The patient may select one of the days to view additional medical information. For example, user interface 2900 displays treatment or medical information for day 4 and 26. This information includes the total amount of UF removed during the day in addition to the UF details removed during the manual exchange as compared to UF removed via home therapeutic apparatus 90. In the illustrated embodiment, the machine treatment information includes the program name, prescribed treatment time, actual treatment time, and the amount of UF removed. The data access module 1106 may determine whether to adhere to the therapy based on the actual therapy time being within a threshold of the prescribed therapy time. In some embodiments, the data access module 1106 and/or the data acquisition module 1104 can determine a adherence upon receiving medical or treatment information and set a corresponding flag or other indication in the patient's medical record to reflect the adherence or lack thereof.
In some examples, the patient enters therapy information for manual exchange via application 1002 on personal mobile communication device 200a while receiving machine therapy information alone from home therapy instrument 90. In other examples, user interface 2900 may display treatments occurring in the patient's home as well as treatments occurring in the clinic. The information may be organized based on the machine receiving the information, the program name, the type of treatment, the prescription, etc. The user interface 2900 in the illustrated example accordingly provides a single display of UF removed for different exchanges, providing the patient with information regarding the effectiveness of the manual exchange as compared to the exchange of machine operations. The example system 100 of fig. 10 enables information from both exchanges to be stored together (based on treatment day) for subsequent display and/or analysis.
2. Information display embodiment via Web browser
In some embodiments, the personal mobile communication device 200a may not install the application 1002. Instead, the patient may use a Web browsing application to access a website or interface hosted by clinician server 200 b. In these embodiments, the data access module 1006 is configured to display medical information and/or treatment information in one or more web pages, similar to the user interfaces 2600-2900 of fig. 26-29. In this embodiment, the personal mobile communication device 200a accesses the data access module 1106 via a website. The user interface or feature selected via the personal mobile communication device 200a causes the data access module 1106 to display medical information within the web page. The data access module 1106 may be configured to format or render medical information and/or therapy information based on the Web browser type and/or operating system of the personal mobile communication device 200 a. In some cases, the data access module 1106 may request a user name and password from the patient before providing access to the website.
3. Information display embodiment via text
In some embodiments, the data access module 1106 is configured to provide medical information and/or therapy information to the personal mobile communication device 200a via a text message. In these examples, the data access module 1106 may provide information in response to text received from the personal mobile communication device 200 a. In other examples, the data access module 1106 may periodically (e.g., daily, weekly, etc.) transmit medical and/or therapeutic information to the patient's personal mobile communication device 200 a.
In an example, the data access module 1106 may receive a text message including text of "send 7 days UF data". In response, the data access module 1106 identifies a medical record corresponding to the phone number of the personal mobile communication device 200a from which the text message was received. The data access module 1106 can then use a lookup table or keyword search to identify fields in the patient's medical record that include matching characters or text sets related to the UF data (e.g., "7 day UF"). The data access module 1106 copies the matched text and creates a reply message with UF values for the first 7 days, which is transmitted to the personal mobile communication device 200a. Additionally or alternatively, the data access module 1106 creates and renders a seven day graph, similar to the graph 2602 in fig. 26. The data access module 1106 creates an image of the chart that is sent to the personal mobile communication device 200a as an image in a text message. The image may be stored as a file of jpeg, gif, png, etc. The patient of the personal mobile communication device 200a can view the chart via a text message. In this manner, the example data access module 1106 is configured to provide the patient with access to medical and treatment information regardless of the capabilities and/or operating system of their personal mobile communication device 200a. In addition, the data access module 1106 determines how to transfer the data based on registration information provided by the patient and/or an indication of whether the application 1002 is installed on the patient's personal mobile communication device 200a.
4. Alert/reminder embodiments
In addition to providing for display of medical and/or treatment information, the example data access module 1106 of fig. 11 is also configured to determine and/or generate alerts and/or reminders for patients and/or clinicians. The data access module 1106 can send an alarm and/or reminder to the patient's personal mobile communication device 200a or clinician device 152. In some embodiments, the data access module 1106 may include a rules table that specifies to which devices certain alerts/reminders are to be sent. The clinician may subscribe to certain alarms/reminders and/or patients using the clinician device 152.
The data access module 1106 is configured to provide alerts/reminders based on how the personal mobile communication device 200a is configured to display medical and/or treatment information. For example, if the application 1002 is installed, the data access module 1106 provides alerts/reminders through an appropriate user interface of the application 1002. In some cases, the application 1002 is configured to display a notification indicating an alert/reminder. If the application 1002 is not installed, the data access module 1106 determines that an alert and/or reminder is to be transmitted to the personal mobile communication device 200a via an SMS or other text message.
In some embodiments, the data access module 1106 includes or has access to a data structure or list specifying certain conditions under which an alert or reminder is to be generated. In an example, the condition may compare a single data value or trend (e.g., 30-day moving average) to a range of acceptable values and/or thresholds (which may include hard limits and/or soft limits). In other examples, an alert or reminder may be generated based on a plurality of conditions based on comparing different types of information to respective limits. In some cases, the data access module 1106 determines derived information calculated from the treatment and/or medical information and then compares it to an acceptable range. Examples of alerts/reminders that may be transmitted via text messaging and/or displayed within application 1002 by data access module 1106 are provided below.
In an example, if it is detected that the patient begins to deviate from prescribed therapy, the data access module 1106 may generate an alarm or reminder. For example, after detecting that two days have elapsed since the treatment information was received, the data access module 1106 (operating according to the alert rules) transmits an alert message to the personal mobile communication device 200a. For example, the reminder message specifies that the patient should perform the treatment. The reminder message may also include information (or information links) describing why the treatment is important, or to the patient what happens to his body if the treatment is not being performed in time. If the data access module 1106 detects that no treatment information has been received for, for example, four days, the data access module 1106 raises the reminder to an alarm (operating according to alarm rules). The data access module 1106 communicates an alert to the personal mobile communication device 200a and/or the clinician device 152 to provide an indication of the severity of the non-adherence to the therapy. As described above, alerts and/or reminders are transmitted by the data access module 1106 based on whether the application 1002 is installed. Even if the application 1002 is installed, the data access module 1106 is configured to transmit a text message to the personal mobile communication device 200a to mark the patient's attention.
In some examples, the patient is prescribed a manual exchange. Thus, the patient must provide treatment information indicating manual exchanges. The data acquisition module 1106 is configured to send an alarm or reminder if no manual exchange information is received within a predetermined period of time (e.g., within 2 days after a predetermined treatment). Further, if the manual exchange is not completed properly (e.g., a short fill out or dwell time), the data access module 1106 sends a reminder and/or alarm regarding the lack of exchange. To determine an insufficient exchange, the data access module 1106 may compare fill, dwell, and/or drain times to pre-established acceptable ranges and/or thresholds. In some cases, the data access module 1106 may request that the patient perform a complete exchange.
In an example, an alarm and/or reminder may be generated to indicate that the patient should select a different treatment program from a plurality of prescribed treatment programs or adjust the treatment program. In this example, the alert or reminder rules may specify that the data access module 1106 compare the patient's blood pressure or weight to a corresponding change threshold while calculating and comparing the accumulated fluid value to the threshold. The cumulative fluid value can be determined from the individual fluid fill and drain volumes, which are indicative of the fluid remaining in the patient's peritoneal cavity. If the blood pressure or weight and the accumulated fluid value (or trend) are outside of acceptable ranges, the data access module 1106 generates an alert. The alarm may indicate that the patient has accumulated fluid and that a longer duration (or shorter fill duration) treatment program should be selected (or that the treatment program should be adjusted to provide a longer duration or shorter fill duration) of fluid discharge. The data access module 1106 sends an alert for display on the personal mobile communication device 200 a. The patient may respond via application 1002 or a text message to cause clinician server 200b to make appropriate changes to the patient's prescription or treatment program.
In some embodiments, the alarm and/or reminder may specify a condition under which the patient is to be prompted to enter additional information. In these embodiments, the data access module 1106 uses the therapy information from the home therapy device 90 as a basis for determining whether the patient is to provide medical information via the personal mobile communication device 200a. In an example, the data acquisition module 1106 can access alarm and/or alert rules specifying conditions under which prompts or text messages are sent to the patient's personal mobile communication device 200a to prompt additional weight or blood pressure measurements. For example, if the blood pressure value (or trend) exceeds a predetermined threshold, an alarm or reminder may specify that a prompt for a new blood pressure measurement is required. In other examples, if the accumulated fluid value or UF removal value (or trend) is outside of an acceptable range, an alarm or reminder may specify that a prompt for a new blood pressure measurement is required. In response, the data access module 1106 sends a text message or notification via the application 1002 to cause the patient to perform and record blood pressure measurements. In some cases, the application 1002 may open a user interface (e.g., user interface 3000 of fig. 30) prompting the patient to enter blood pressure information. If the additional data received from the personal mobile communication device 200a is not within an acceptable range, the data access module 1106 can raise the alert to an alert that is transmitted to the clinician device 152 and/or the personal mobile communication device 200a. Thus, the data access module 1106 is configured to operate rules that determine critical patient conditions that seek additional information from the patient before determining whether further attention or action is required by the clinician or patient.
In further embodiments, the rules of the data access module 1106 may instruct the patient to examine and/or make changes to the home treatment device 90. In an example, the rules may specify that if no treatment information is received from the home treatment device 90 within a defined period of time (e.g., two days), the data access module 1106 will send a reminder to the patient. In this case, the patient may have provided medical information indicating that treatment occurred, which is used by the data access module 1106 to determine that a reminder of treatment compliance is not required. Instead, the data access module 1106 determines that a reminder to check the network connection of the home treatment device 90 is to be sent to the patient so that treatment information stored on the machine 90 can be retrieved. The patient may respond to the reminder using the personal mobile communication device 200a to indicate that the connection has been checked. After receiving the response from the patient, the data acquisition module 1104 may send a ping message to the home treatment instrument 90 to acquire the lost treatment information. If a connection is still not established, the data access module 1106 may send a reminder to the patient, clinician, and/or network administrator with more specific instructions for activating the home treatment device 90 and/or overcoming the network connectivity issue.
In another example, the data access module 1106 can include one or more rules specifying generating alerts in response to treatment information being out of range. For example, a large difference between the fluid fill and drain may indicate a leak in the dialysis tubing or connection to the patient. In response, the data access module 1106 sends a reminder to the patient prompting the patient to verify the fluid connection. The patient may provide a response indicating whether a leak is detected. In response, the data access module 1106 determines whether the leak has been corrected in a subsequent processing cycle (or base order) or whether the pipe should be replaced. The data access module 1106 may determine cartridge, and similar consumable problems based on the treatment and/or medical information. For example, the removed small amount of UF may prompt the data access module 1106 to send a reminder to the patient to verify the concentration of the dialysate and/or concentrate being connected to the home treatment device 90.
D. treatment control module embodiments
The example treatment control module 1110 of fig. 11 is configured to enable a patient and/or clinician to change prescriptions and/or procedures on the home treatment device 90. To operate, the home treatment device 90 is assigned one or more prescriptions for the patient. The recipe may specify the type of treatment (e.g., automated peritoneal dialysis treatment, manual exchange treatment, hemodialysis treatment, etc.), the period of time the patient will receive the treatment, the glucose level or other concentration level of the treatment fluid, the amount of UF removed per day, and/or the number of times per day or duration range for each treatment. Each recipe may include one or more programs. The program may specify the duration of the treatment, the total amount of fluid to be provided to the patient, the fill to be repeated, the dwell, the number of drain cycles, and/or an indication of whether the treatment includes tidal therapy. Program variations in the prescription allow the patient or clinician to alter certain treatment parameters based on the patient's condition or activity.
The prescription and associated programs are stored in an electronic prescription in clinician database 1010. In some embodiments, the prescription can be stored into a patient's medical record. The home treatment device 90 is programmed with one or more prescriptions. The programming may be performed locally via the clinician or patient, or may be performed remotely from the clinician server 200 b. For example, the clinician server 200b (e.g., treatment control module 1110) may send a copy of the prescription from the clinician database 1010 to the home treatment device 90 after registration.
In some embodiments, the example treatment control module 1110 is configured to operate in conjunction with the application 1002 on the personal mobile communication device 200a and/or the application on the clinician device 152 to enable a patient and/or clinician to select different prescription programs and/or prescriptions. Fig. 31 shows a diagram of a user interface 3100 of an application 1002 that enables a patient to select between three different programs, short, long, and weekend. The patient may select a procedure based on their activity and/or condition. In some embodiments, the application 1002 may display a reminder from the data access module 1106 to provide a suggestion to change the procedure based on detected body fluid accumulation, weight gain, or blood pressure elevation.
After the patient selects a different procedure via user interface 3100, application 1002 sends a message to therapy control module 1110 indicating the selection. In response, the therapy control module 1110 updates the patient's medical record to reflect the changed procedure, including the time/date of the change. In addition, the treatment control module 1110 communicates a message to the home treatment device 90 that provides instructions to change to the selected procedure. In some cases, the message may include treatment parameters for the newly selected procedure. The home treatment device 90 thus performs the next treatment based on the newly selected program. In some cases, home treatment device 90 may display a prompt to the patient to confirm the new procedure before operating according to the procedure.
In some embodiments, the therapy control module 1110 may perform a check to verify that the patient is authorized to make changes to the procedure and/or whether the changes are allowed. For example, the therapy control module 1110 receives an indication that the patient desires to change from a short procedure to a long procedure. The therapy control module 1110 compares the patient's medical information to one or more thresholds to ensure that the change does not adversely affect the patient. For example, if the patient has accumulated a relatively large amount of fluid, the therapy control module 1110 may not approve the change from a short procedure to a long procedure. If no changes can be made, the therapy control module 1110 sends a message to the personal mobile communication device 200a indicating why the changes cannot be made.
In an embodiment, the therapy control module 1110 may send a notification to the clinician device 152 indicating that the patient desires to change procedures. The treatment control module 1110 may not communicate the change to the home treatment instrument 90 until confirmation is received from the clinician device 152. In some embodiments, the clinician may use their clinician device 152 to change the procedure and/or prescription via the therapy control module 1110. In these embodiments, the therapy control module 1110 may send a message indicating a change in the procedure and/or indicating that the clinician made the change for display in the application 1002 of the personal mobile communication device 200 a.
In the case where the personal mobile communication device 200a does not include the application 1002, the therapy control module 1110 is configured to allow the prescription to be changed. For example, the therapy control module 1110 can host a website that is accessible by a Web browser on the personal mobile communication device 200 a. The website may include features similar to user interface 3100 of fig. 31 to enable a patient to remotely select different programs and/or prescriptions.
Additionally or alternatively, the therapy control module 1110 is configured to enable therapy changes via text messages. In an example, the patient may send a message from the personal mobile communication device 200a that includes text of "change treatment. In response, the therapy control module 1110 is configured to send a reply message with different therapy program options and corresponding codes or indicators after each option. The patient may enter a flag or code in the response message to select the desired procedure. In another example, the patient may send a message with text consisting of, for example, "long program" to cause the therapy control module 1110 to change the program to a long program.
E. Education module embodiment
The example educational module 1108 of fig. 11 is configured to provide educational material and/or encouragement to a patient via the personal mobile communication device 200 a. Similar to the other modules 1102-1106 and 1110 of fig. 11, the educational module 1108 is configured to provide content/information based on the configuration of the personal mobile communication device 200 a. For example, if the application 1002 is installed, the educational module 1108 is configured to select and provide educational material through the application 1002. If the application is not installed, the educational module 1108 is configured to provide educational material via a website and/or text message. In the example of a text message, the educational module 1108 may be configured to construct educational material appropriate for the text message, or to provide a link to the educational material at the clinician database 1010 or hosted by a third party server.
As described herein, educational materials may include text-based articles, audio, video, multimedia presentations, and the like. The educational material may provide general information about the patient's condition, information about the application 1002, and/or information about the home treatment device 90. The teaching material can also be targeted based on detected patient conditions (as determined by their medical history) and/or feedback regarding the patient's use of the application 1002 and/or the home treatment device 90.
Further, as described herein, encouragement includes text, audio, video, or multimedia presentations intended to improve a patient's mood or help the patient adhere to the program. The encouragement measures may also include rewards or badges. In some embodiments, the educational module 1108 may be configured to provide encouragement based on detected conditions. In some cases, encouragement may be provided in connection with an alert generated by the data access module 1106. In an encouraging example, the patient may be provided with different status levels based on adherence rates (e.g., "dialysis giant" for near perfect adherence).
Educational materials and/or encouragement may be stored in clinician database 1010. In addition, the educational module 1108 may access third party materials, such as materials from the national institutes of health or CLEVELAND CLINIC. The educational module 1108 may include a rules data structure that specifies conditions under which certain educational materials and/or encouragement will be provided to the personal mobile communication device 200a.
In an example, the data access module 1106 determines that the patient does not adhere to the treatment. In addition to the data access module 1106 sending a reminder, the educational module 1108 may also suggest or provide a video link regarding the importance of the adherence. Fig. 32 illustrates an example user interface 3200 of an application 1002 that displays educational videos related to adherence provided by the educational module 1108. The example user interface 3200 also provides a list of recommended educational materials based on the detected patient condition. For example, upon detecting that a patient has hypertension from a medical record or receiving it as medical information, the educational module 1108 is configured to recommend educational content regarding lowering blood pressure. Further, upon detecting that the patient has not yet had a prescription program that has changed, the educational module 1108 determines that educational content that interprets the program options should be recommended.
The example educational module 1108 may also detect how a patient interacts with the application 1002 and recommend educational content. For example, the educational module 1108 receives feedback from the application 1002 indicating that the patient has made multiple attempts to fill in the data fields of the user interface (e.g., the user interface 14 of fig. 14) using the recorded images. In response, the educational module 1108 may provide a notification via the application 1002 that recommends the patient to view a course of information entry regarding use of the recorded images.
The example education module 1108 can store any educational content or instructions for encouragement displayed by the personal mobile communication device 200a to the patient's medical record. Such information may be useful for a clinician to determine how to encourage the patient to receive treatment. The stored information may also provide an indication of the patient's awareness of the treatment.
F. Auxiliary module embodiment
The example assistance module 1112 of fig. 12 is configured to create a communication session between the patient and the clinician. In particular, the assistance module 1112 is configured to create a communication session between the clinician device 152 and the personal mobile communication device 200 a. The assistance module 1112 can use the capabilities of the personal mobile communication device 200a to determine an appropriate communication session.
The communication session may include a video session, an audio call, a conference call, an SMS session, or a Web message session. If the application 1002 is installed, the assistance module 1112 can access an option for selecting a video session, a conference session, or a Web message session, which is used to connect the patient to the clinician through the application 1002. If the application 1002 is not installed, the auxiliary module 1112 may be limited to options related to the native communication capabilities of the personal mobile communication device 200a, such as text messaging and audio calls.
In some embodiments, the patient may initiate a session. The application 1002 is configured to enable a patient to request contact with a clinician, including specifying a preferred communication method. Using the text feature of the application 1002, the patient may send a text message including "help" text to the auxiliary module 1112 to begin the session. After the patient requests to begin a session, the assistance module 1112 is configured to identify available clinicians. In some embodiments, the assistance module 1112 can locate a record of a clinician associated with the patient and send a ping/request message to their device. The response received from one of the devices 152 provides an indication that the clinician is available and willing to communicate with the patient. In some cases, the response may indicate the manner in which the clinician communicates. In response to the received message, the assistance module 1112 begins a communication session. This may include establishing a Web call, messaging session, or audio call between the personal mobile communication device 200a and the clinician device 152. In some embodiments, in addition to broadcasting the ping message to a group of clinicians, the assistance module 1112 may sequentially send ping/request messages to the clinicians according to a predetermined order (e.g., first the clinician, second the on-duty clinician of the same office, third the on-duty clinician of other offices, etc.). Fig. 33 illustrates a diagram of a user interface 3300 of an application 1002 that provides a video session within a clinician. Video sessions enable patients to address their concerns about treatment. The video session also enables the clinician to view real-time settings of the therapy or assist the patient in setting the therapy.
In some embodiments, the assistance module 1112 may determine to open the communication session or recommend opening the communication session. The auxiliary module 1112 may provide recommendations in conjunction with the data access module 1106 generating alerts and/or reminders. The assistance module 1112 can identify the clinician devices 152 available to engage in the session after detecting the alert and/or alarm condition and then initiate a call to the personal mobile communication device 200a to address the alert and/or alarm. In an example, the assistance module 1112 may attempt to create a communication session after detecting that the patient's blood pressure, weight, accumulated fluid, etc. is above a predetermined threshold or has changed significantly within a predetermined period of time.
The example assistance module 1112 may determine the type of assistance being sought to identify the correct individual to connect. In addition to clinicians, the auxiliary module 1112 may also be connected to information technology specialists and home therapists. Before starting the session, the application 1002 may prompt the patient to identify the type of assistance (e.g., application assistance, machine assistance, clinical assistance, etc.). In other cases, the assistance module 1112 may determine the assistance type based on the context in which the session request was received. For example, after reviewing the educational training program for the home treatment device 90, the assist module 1112 determines that the subsequent assist request is related to operating the home treatment device 90. In another example, when application 1002 is displaying a user interface regarding UF trends, assistance module 1112 determines that the subsequent assistance request is regarding a clinical issue.
The example assist module 1112 can be configured to log the communication session into a medical record of the patient. The auxiliary module 1112 may record the date/time of the communication session and an indication of how to initiate the session. The record may also include participants of the communication session and the communication record. For text messages, this may include a copy of the message. For audio or video, this may include a recording of the call or transcription of the call.
Conclusion (III)
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 subject matter and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.
Claims (43)
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201862727305P | 2018-09-05 | 2018-09-05 | |
| US62/727,305 | 2018-09-05 | ||
| PCT/US2019/049737 WO2020051325A1 (en) | 2018-09-05 | 2019-09-05 | Medical fluid delivery system including a mobile platform for patient engagement and treatment compliance |
| CN201980057821.XA CN112655046B (en) | 2018-09-05 | 2019-09-05 | Medical fluid delivery system including a mobile platform for patient engagement and treatment compliance |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201980057821.XA Division CN112655046B (en) | 2018-09-05 | 2019-09-05 | Medical fluid delivery system including a mobile platform for patient engagement and treatment compliance |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN119380908A true CN119380908A (en) | 2025-01-28 |
Family
ID=67998733
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201980057821.XA Active CN112655046B (en) | 2018-09-05 | 2019-09-05 | Medical fluid delivery system including a mobile platform for patient engagement and treatment compliance |
| CN202411390832.9A Pending CN119380908A (en) | 2018-09-05 | 2019-09-05 | Medical fluid delivery system including a mobile platform for patient engagement and treatment compliance |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201980057821.XA Active CN112655046B (en) | 2018-09-05 | 2019-09-05 | Medical fluid delivery system including a mobile platform for patient engagement and treatment compliance |
Country Status (9)
| Country | Link |
|---|---|
| EP (1) | EP3847656A1 (en) |
| JP (2) | JP7431808B2 (en) |
| KR (2) | KR102748214B1 (en) |
| CN (2) | CN112655046B (en) |
| AU (1) | AU2019335308A1 (en) |
| BR (1) | BR112021002555A2 (en) |
| CA (1) | CA3110999A1 (en) |
| MX (1) | MX2021002594A (en) |
| WO (1) | WO2020051325A1 (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20230105767A1 (en) * | 2020-03-26 | 2023-04-06 | Janssen Biotech, Inc. | Annotating and managing of therapeutic or biological digital data |
| CN112364857B (en) * | 2020-10-23 | 2024-04-26 | 中国平安人寿保险股份有限公司 | Image recognition method, device and storage medium based on numerical extraction |
| CN112381193A (en) * | 2020-11-10 | 2021-02-19 | 联赢医疗科技有限公司 | Data transmission device and data transmission method for clinical data acquisition |
| KR20230050595A (en) * | 2021-10-08 | 2023-04-17 | 가톨릭대학교 산학협력단 | Server for integrated management of personal health records into global big data, method, and recording media thereof |
| KR20230105904A (en) * | 2022-01-05 | 2023-07-12 | 동은정보기술주식회사 | Service provision system through automatic extraction and classification of medical data |
| CN118155818B (en) * | 2024-05-09 | 2024-08-02 | 山东众仁志合信息科技有限公司 | Integrated message management platform |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001034627A (en) | 1999-07-19 | 2001-02-09 | Hitachi Ltd | Receipt inspection method and system, and storage medium storing receipt inspection program |
| US8029454B2 (en) | 2003-11-05 | 2011-10-04 | Baxter International Inc. | High convection home hemodialysis/hemofiltration and sorbent system |
| FR2896792B1 (en) | 2006-01-27 | 2008-07-18 | Millipore Corp | SYSTEM AND METHOD FOR PURIFYING WATER |
| US8393690B2 (en) | 2007-02-27 | 2013-03-12 | Deka Products Limited Partnership | Enclosure for a portable hemodialysis system |
| US20090192813A1 (en) * | 2008-01-29 | 2009-07-30 | Roche Diagnostics Operations, Inc. | Information transfer through optical character recognition |
| US10089443B2 (en) * | 2012-05-15 | 2018-10-02 | Baxter International Inc. | Home medical device systems and methods for therapy prescription and tracking, servicing and inventory |
| US11462321B2 (en) * | 2010-08-12 | 2022-10-04 | Fenwal, Inc. | Mobile applications for blood centers |
| CN102542158A (en) * | 2011-12-07 | 2012-07-04 | 南京毗邻医疗科技有限公司 | Intelligent medical service system based on composite diagnosis and treatment template and composite illness condition template |
| KR20140013124A (en) * | 2012-07-03 | 2014-02-05 | 삼성전자주식회사 | Method, apparatus and system for transmitting measurement results of measurement device to information system |
| JP2014026411A (en) | 2012-07-26 | 2014-02-06 | Nippon Telegraph & Telephone West Corp | Health care system and server therefor |
| JP6196024B2 (en) | 2012-09-05 | 2017-09-13 | 京セラ株式会社 | Information providing system, electronic device, control method, and control program |
| US9351641B2 (en) | 2012-10-04 | 2016-05-31 | Cerner Innovation, Inc. | Mobile processing device system for patient monitoring data acquisition |
| EP3005282A4 (en) | 2013-06-06 | 2017-03-01 | Janssen Pharmaceutica N.V. | Electronic medication adherence, identification, and dispensation |
| US20150134361A1 (en) * | 2013-11-08 | 2015-05-14 | The Cleveland Clinic Foundation | Graphical generation and retrieval of medical records |
| US10028658B2 (en) * | 2013-12-30 | 2018-07-24 | Welch Allyn, Inc. | Imager for medical device |
| EP4365911A3 (en) * | 2017-02-24 | 2024-05-29 | Masimo Corporation | Medical device cable and method of sharing data between connected medical devices |
| CN109784235A (en) * | 2018-12-29 | 2019-05-21 | 广东益萃网络科技有限公司 | Method for automatically inputting, device, computer equipment and the storage medium of paper form |
-
2019
- 2019-09-05 CN CN201980057821.XA patent/CN112655046B/en active Active
- 2019-09-05 BR BR112021002555-3A patent/BR112021002555A2/en unknown
- 2019-09-05 CA CA3110999A patent/CA3110999A1/en active Pending
- 2019-09-05 JP JP2021512439A patent/JP7431808B2/en active Active
- 2019-09-05 AU AU2019335308A patent/AU2019335308A1/en active Pending
- 2019-09-05 WO PCT/US2019/049737 patent/WO2020051325A1/en active Application Filing
- 2019-09-05 KR KR1020217009514A patent/KR102748214B1/en active Active
- 2019-09-05 KR KR1020247042820A patent/KR20250007051A/en active Pending
- 2019-09-05 CN CN202411390832.9A patent/CN119380908A/en active Pending
- 2019-09-05 MX MX2021002594A patent/MX2021002594A/en unknown
- 2019-09-05 EP EP19772923.9A patent/EP3847656A1/en active Pending
-
2023
- 2023-12-01 JP JP2023203666A patent/JP2024009361A/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| JP2024009361A (en) | 2024-01-19 |
| JP2021536632A (en) | 2021-12-27 |
| KR20210056366A (en) | 2021-05-18 |
| BR112021002555A2 (en) | 2021-05-04 |
| CN112655046A (en) | 2021-04-13 |
| JP7431808B2 (en) | 2024-02-15 |
| CN112655046B (en) | 2024-10-25 |
| MX2021002594A (en) | 2021-05-12 |
| WO2020051325A1 (en) | 2020-03-12 |
| AU2019335308A1 (en) | 2021-04-15 |
| KR20250007051A (en) | 2025-01-13 |
| EP3847656A1 (en) | 2021-07-14 |
| KR102748214B1 (en) | 2024-12-31 |
| CA3110999A1 (en) | 2020-03-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US12020788B2 (en) | Medical fluid delivery system including a mobile platform for patient engagement and treatment compliance | |
| US11823779B2 (en) | Medical device data back-association, system, apparatuses, and methods | |
| CN112655046B (en) | Medical fluid delivery system including a mobile platform for patient engagement and treatment compliance | |
| JP7506727B2 (en) | Medical fluid delivery system including remote machine update and control | |
| JP2023500448A (en) | Medical fluid delivery systems including analytics to manage patient engagement and treatment compliance |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |