Invented by Kevin McRAITH, Hari KESANI, Anand Iyer, Gabriel SUSAI, Mansur SHOMALI, Prasad Matti RAO, WellDoc Inc
Analyzing blood samples is a crucial aspect of diagnosing and monitoring various medical conditions. It provides valuable insights into a patient’s overall health, including information about organ function, nutrient levels, and the presence of diseases or infections. However, managing and interpreting the vast amount of data generated from blood analysis can be challenging without proper tools and systems in place.
Database management systems specifically designed for blood analysis play a vital role in organizing and storing patient data. These systems allow healthcare professionals to efficiently manage and access patient records, test results, and other relevant information. By centralizing data in a secure and easily accessible manner, these databases enable healthcare providers to make informed decisions and provide personalized care to patients.
Furthermore, graphical user interfaces (GUIs) have revolutionized the way healthcare professionals interact with and interpret blood analysis data. GUIs provide a visual representation of complex data sets, making it easier for medical practitioners to understand and analyze the information. These interfaces often include customizable dashboards, interactive charts, and real-time updates, allowing for quick and accurate decision-making.
The market for database management and GUIs for blood analysis has seen significant growth due to several factors. Firstly, the increasing prevalence of chronic diseases such as diabetes, cardiovascular diseases, and cancer has led to a higher demand for blood analysis and data management tools. As the number of patients requiring regular blood tests continues to rise, healthcare providers are seeking efficient solutions to handle the influx of data.
Secondly, technological advancements have played a crucial role in driving the market growth. The development of advanced laboratory equipment and automated blood analysis systems has increased the speed and accuracy of data collection. Consequently, there is a need for robust database management systems and GUIs to handle the large volume of data generated by these advanced technologies.
Moreover, the growing emphasis on personalized medicine has further fueled the demand for efficient data management tools. With the increasing availability of genetic and molecular testing, healthcare professionals require sophisticated systems to integrate and analyze diverse data sets. Database management systems and GUIs provide the necessary infrastructure to store, analyze, and visualize this complex information, enabling personalized treatment plans and improved patient outcomes.
In conclusion, the market for database management and GUIs for measurements collected by analyzing blood is experiencing significant growth. The increasing prevalence of chronic diseases, technological advancements, and the emphasis on personalized medicine are driving the demand for these tools in the healthcare industry. As the importance of accurate and efficient data management continues to grow, the market for these solutions is expected to expand further in the coming years.
The WellDoc Inc invention works as follows
The devices and methods include database management, graphical user interfaces, and measurements taken by analysing blood.
Background for Database Management and Graphical User Interfaces for Measurements Collected by Analyzing Blood
This disclosure is directed at a computer-implemented treatment method for managing blood sugar levels of a patient. The method includes electronically receiving initial data by one or multiple processors before generating the treatment plans, determining the goal that the patient should achieve during the treatment period using the initial data and generating the treatment for the patient to achieve the target based upon the time the patient has been diagnosed. Presenting the treatment to the client via an electronic device, electronically receiving data related to the treatment for a subset of that treatment period and
The initial data includes the types and dosages consumed by the patient and the historical A1C value of the patient. The goal is to reduce the A1C of the patient at the end of treatment compared with the A1C of the patient at the beginning. The treatment plan contains instructions on tasks that the user must perform during the first part of the treatment period. These tasks include measuring blood glucose before and after meals according to prescribed guidelines, taking prescribed medication at prescribed times and dosages, eating prescribed carbohydrates and performing prescribed exercises. The revised treatment includes one or several tasks that the user is to perform during the next subset of treatment. These tasks include changes to the prescribed blood glucose measurements pairs, the prescribed timing and dosages of medication, the prescribed amount of carbohydrate for the patient to consume and the prescribed exercise. The data related to the treatment plan include types, timing and dosages, carbohydrates consumed, sleep, exercise, and blood sugar levels. This also involves receiving GPS data via the electronic devices of the users, based upon a time proximity of one or more meals scheduled in the treatment plan that the user will consume, using the GPS to identify nearby restaurants which are cataloged and include meals and carbohydrate contents, presenting the list of restaurants to the users via the electronic devices, displaying recommended meal options based upon the carbohydrate contents of meals at the identified restaurant, and receiving a choice of a cataloged restaurant from a user. The method also includes receiving an indication that the patient would like to exercise. After receiving the indication, the GPS data is retrieved from the electronic device and the route generated corresponds to the exercise prescribed in the treatment plan. The method also includes administering a questionnaire via a software program downloaded onto the electronic device of a user. One or more processors electronically receive the answers of the users to the questionnaire. Based on these answers, the method determines if the user is likely to adhere to a prescribed medication regiment, diet regiment, and exercise regiment. Based on the identified patterns the method also includes identifying a trigger event which occurs before an adverse impact on blood glucose levels. The method also includes sending an electronic notification to the user upon detection of a subsequent instance. The notification includes a description of the trigger to the user, as well as a description of any adverse effects on blood sugar that occur after the trigger. The trigger is the day of week. A user exceeding a certain threshold of exercise is another trigger event. Hyperglycemia is one of the adverse effects on blood glucose levels.
The disclosure can also be directed at a system that manages blood glucose levels for a user. The system includes a memory that stores processor-readable instruction, and a computer configured to access and execute those instructions. When executed, these instructions configure the processor to perform the method. Initial data includes the types and dosages consumed by the users and their historical A1C levels. The goal is to reduce the A1C values of users at the end of treatment periods compared with the A1C values of users at the beginning of treatment periods.
The The
Now, we will refer in detail to the examples of disclosure that are shown in the accompanying drawing.” The same reference numbers are used to refer to similar or identical parts wherever possible.
Health Care and Computing Environment
FIG. According to an example in the present disclosure, FIG. 1 shows a block diagram for a health-management system 100. Users (e.g. patients, consumers, etc.) 8 with electronic devices 19, such as mobile devices, computers, medical devices, or other electronic gadgets configured to connect to an electronic network 32 (such as the Internet) may communicate or access a mobile (mHealth) app 1. In some cases, network 32 can include wireless or wired connections, such as mobile phone networks, Wi-Fi or LANs or WANs. Bluetooth, NFC, or other forms of network communication may also be included. Multi-device electronic networks 32 can be configured. Users 8 can access the mHealth app 1 using a single account that is linked to multiple devices 19, such as a mobile device, tablet or laptop computer. The electronic device 19 may also include, but not be limited to mobile health devices (such as a tablet, smartphone, PDA, cellular phone), desktop computers or workstations, laptop computers, media players, navigation devices, game consoles, set-top boxes, biometric sensing devices with communication capabilities, smart TVs, and any combination thereof. Electronic device 19 can include any combination or type of input/output device such as a display screen, keyboard, touchpad (or touchscreen), accelerometer, microphone, gyroscope and mouse, touchscreen camera, projector, touch panel, button, switch, motion sensor, audio sensor, pressure sensor, thermal sensor and/or mic. Electronic devices 19 may also communicate with one another by wired or wireless methods (e.g. via Wi-Fi (radio frequency), infrared, Bluetooth, Near Field Communication or any other suitable method) to send or receive information.
mHealth application” 1 can be in communication with another entity or network to send and receive data. In some cases, mHealth applications 1 can communicate with other applications that are associated with user 8, such as exercise tracking applications (e.g. step tracking) and/or health-related apps. The mHealth app 1 can import data to analyze, and then use to generate treatment plans for user 8. mHealth app 1 can import data such as activity tracking data and analyze it to determine patterns in the user’s blood glucose levels. mHealth app 1 can export data to any other mobile application, such as other mobile health apps with social or interactive functions. A physician or other healthcare provider 7 may prescribe the application. It is possible that mHealth app 1 does not require a prescribed, e.g. it could be a consumer-friendly application that can be accessed without a prescription through a digital distribution platform of computer software. mHealth application 1, which is tailored to a particular user 8, can be activated by the user in person at a pharmacy 9, or by another authorized entity. The pharmacy may provide an access code to the user 8. This will allow the user to access the mHealth app 1. A mHealth support system 25, and/or an application trainer 24, may train the user 8 on how to use mHealth app 1. mHealth app 1 may also include machine learning programming algorithms 26, for example. The treatment plan for the user may include a prescription, e.g. for a device, therapy, or drug. This can be filled by the pharmacy. After receiving authorization, the pharmacy 9 can allow the user to refill the prescribed product/therapy if he/she is following his/her healthcare plan. The pharmacy 9 may receive the authorization via a communication sent by the application 1 over, for example, the network 32 or various servers 29. The manufacturer 37 may also be notified of the use of the drug, or any other medical product/therapy by the user 8 via the network 32. The manufacturer 37 can use this information to assess demand and plan supply of the product or therapy. Healthcare provider 7 may also receive a report on the basis of the information provided by the application 1 and update the treatment plan for the user based on that information. The electronic medical record 14 of the user may also be automatically updated by the network 32, based on user information. This may include user feedback 8 that is electronically transmitted, and received by the mHealth app 1. The healthcare provider 7 can be any appropriate healthcare provider, such as a doctor or specialist, nurse, educator social worker, MA, PA or the like.
FIG. The schematic diagram 2 shows additional aspects of the system 100. The system 100, for example, may access decision model databases 270 through network 32. The retrieved models can be displayed and/or processed by electronic devices 19, including a mobile device 215, tablet device 220 or computer (e.g. laptop or desktop), kiosk 230 or any other device connected to the network 32.
In the example shown in FIG. “In the example shown in FIG.
Each electronic device 19, such as mobile device 215, tablets 220, computers 225 and/or kiosks 230, can be configured to send or receive data (e.g. clinical information) from and to a system 29 of servers over the network 32. Servers 29 can send information to each device 19, such as clinical data, via network 32. Servers 29 can include algorithm servers 245, UI servers 250 and/or clinical data servers. The electronic device 19 could include a user-interface that communicates data with UI server via network 32. To retrieve decision models, each server can access the database of decision models 270. Each server can include memory, processors, and/or databases. The clinical data server 240, for example, may be equipped with a processor that can retrieve clinical data either from a database of a provider or a patient’s electronic health record. The algorithm server 245 can have a database with various algorithms and a processor that is configured to process clinical data. The UI Server 250 can be configured to accept and process input from the user 8, such as preferences for clinical decisions. Satellite 255 can be configured to transmit and receive data between devices 19 and servers 29.
The clinical data server 240 can receive data from the electronic device 19, such as user data, via the network 32. It may also be able to do so indirectly through the UI server. The clinical data servers 240 can save the information to memory. For example, a computer-readable memory.
The clinical data server 240 may also be in contact with other servers such as the algorithm servers 245 or external servers. Server 29 could contain data on provider preferences and/or health history of user 8. The clinical data server 240 can also include data from users. The algorithm server 245, for example, may use machine learning and/or other algorithms. The algorithm server 245, which may also be in contact with external servers, may also be updated to suit your needs. The algorithm server 245, for example, may be updated to include new algorithms, powerful programming and/or additional data. The algorithm server 245 and/or clinical data server may transmit the data to the database 270. In one example algorithm server(s), 245 may obtain pattern definitions in a simple form, predict future time steps by using models (e.g. Markov, Gaussian or Bayesian models, classification models like linear discriminant functions and nonlinear discriminant function, random forest algorithms, etc. ), optimize results on the basis of its predictions, detect the transition between patterns, extract abstract data to infer higher knowledge levels, obtain information and extract data to infer higher knowledge levels, combine higher and low levels of data to infer
Each server of the system of servers 29 including algorithm server 245, clinical data server 250 and UI servers 250 may represent one of many types of servers, including but not limited, to a web or application server, proxy server, network server or server farm. The system of servers 29 can be implemented by any general-purpose computing device capable of providing data to other devices, including but not limited devices 19, or other computing devices (not shown), via network 32. A general-purpose device can be a server with a processor, memory, and storage for instructions. Memory can be any type of random-access memory (RAM) and read-only memory(ROM) embedded in a physical medium such as magnetic storage, including floppy disc, hard disk or magnetic tape, semiconductor storage, such as Solid-State Disk (SSD) (or flash memory), optical disc storage, or magneto-optical disk storage. Software can include one or several applications, as well as an operating system. Hardware includes, but isn’t limited to, a CPU, memory and graphical UI. Each server may also have multiple processors, multiple memory components, either shared or separate, that are configured for a server farm or clustered computing environment.
FIG. This is a third representation of the system 100, showing more details about electronic device 19 as well as a server 29, in FIG. Each electronic device 19 and server 29, such as processors 301-2 and 304-1, may contain up to two processors. The processors 301-1 or 304-1 may each be a central processor unit, microprocessors, general-purpose processors, application specific processors, or any other device that executes instruction. The electronic device 19 and the server 29 may also include one or multiple memories that store software modules, such as memory 301-2 and 304-2. Memory 301-2 and memory 304-2 can be implemented with any computer-readable medium, including hard drives, CDs or DVDs, flash memories, RAM, ROM etc. Memory 301-2 can store a module 301-3 that is executed by processor 301-2. Memory 304-2 can also store a module 301-3, which is executable by processor 304-1.
Electronic devices 19 may also comprise one or multiple UIs. The UI can allow for one or more interfaces that present information to a users 8, such as a program or intervention. The UI can be web-based, like a web site, or a standalone application. The UI can also be configured to accept data inputs from a user 8 and feedback. The information can be manually entered by the user 8, or automatically. For example, the user 8, or the caretaker of the user, may enter information about when the medication was taken and what the user 8 ate. The electronic device 19 may also include testing equipment, not shown, or an interface to receive information from the testing equipment. Testing equipment can include, for instance, a glucose meter or heart rate monitor. It could also be a weight scale, cuff of blood pressure, etc. The electronic device 19 may also include one or several sensors (not shown), including a microphone, camera, or accelerometer for collecting feedback from an 8 user. The device could include, for example, a glucose meter that automatically reports the blood glucose level of the user.
Electronic Device 19 may also include a Presentation Layer. The presentation layer can be a web-browser, an application, or a messaging interface (e.g. email, instant messages, SMS). ), etc. Presentation layer allows the electronic device to present notifications, alerts and reading materials as well as guides, reminders or suggestions. The presentation layer can present, for example, articles that have been determined to be relevant for the user 8, reminders about purchasing medications, tutorials (e.g. a tutorial on carbohydrate), testimonials of others who share similar symptoms and/or goals (e.g. a carbohydrate count goal). The presentation layer may also present information, such as a guide (e.g. a video or user guide) and/or facilitate communications between the healthcare provider and the patient, i.e. the user 8. Communications between the healthcare provider and the patient 8 may take place via voice or video, electronic messaging (e.g. SMS or e-mail), or even real-time video. As described below, one or more of these items can be displayed based on the treatment plan or updated treatment plan. This layer can also be used to get feedback from the user.
The system 100 may also include one or multiple databases, such a database 302. Database 302 can be implemented by any database technology that is known to a person of ordinary skill, including relational database technologies or object-oriented databases. Database 302 may store data 302-1. Data 302-1 can include knowledge bases for inferences, statistical modeling, and/or information about the user. Data 302-1 or portions of it may be stored on server 29 or electronic device 19.
The system 100 is capable of a variety of uses, such as monitoring and tracking nutrition, sleep, and other aspects related to a person’s health. In some implementations, system 100 may store data in encrypted form in databases to ensure data security against unauthorized access, as well as comply with HIPAA privacy and/or other legal regulations.
Any server or system 29 shown in system 100 may include one or multiple databases.” Databases can be used as any type or medium of storing data. Database 302 can store, for example, data that is received or processed by the server 29, including information about a user?s treatment plan. This includes timings and doses of each prescribed medication. Database 302 may also store information about the user 8, including their literacy levels related to a number of prescribed medications.
Click here to view the patent on Google Patents.
Leave a Reply