System and method for updating electronic health records or health database based on patient information searches

Abstract

Systems and methods are provided for capturing and storing user health and wellness related search and search results activity in a database such as an electronic health record (EHR). A component captures search queries on a website or search engine, retrieves corresponding results, and stores them into one or more EHR. Users can share queries and results with others as needed, for health and wellness management.

Description

SYSTEM AND METHOD FOR UPDATING ELECTRONIC HEALTH RECORDS OR HEALTH DATABASE BASED ON PATIENT INFORMATION SEARCHES CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of priority of U.S. Application No. 63 / 647,812, filed May 15, 2024, which is incorporated herein by reference for all purposes.BACKGROUND

[0002] Today, individuals frequently turn to online resources such as websites and search engines to investigate health or wellness concerns before consulting a medical professional. Users may search for information on symptoms, general health guidance, or over-the-counter remedies because they perceive their conditions as minor or not urgent. This growing reliance on web-based medical information can lead to missed diagnoses or delayed professional intervention if the symptoms warrant more attention.

[0003] Furthermore, while many healthcare providers encourage patients to share selfreported symptoms, few patients share their medical or wellness issues. Consequently, healthcare professionals may miss the early warning signs of potentially serious or escalating medical issues.

[0004] A user might repeatedly look up advice on managing headaches, dismissing them as tension headaches when, in fact, they could be an indicator of a more serious condition. A family member could use the system to search on behalf of a relative, early insight into possible emerging concerns. The invention helps reduce the risk of critical conditions going unnoticed until they become acute.SUMMARY OF THE INVENTION

[0005] The present invention addresses the challenges associated with users’ reliance on online searches for medical or wellness information and the corresponding risk of overlooking significant or emergent health conditions. The invention seeks to provide a systematic and proactive approach to monitoring, identifying, and communicating potentially serious or escalating health concerns gleaned from user search behaviors or related self-reported data.

[0006] In one embodiment, the invention provides a method for analyzing user interactions with online resources such as websites, search engines, or symptom-checker tools to detect patterns indicative of potential health risks. These patterns can include repeated searches for the same or related symptoms, prolonged engagement with medical content, or inquiries that suggest progressive or worsening conditions. Through data analysis, the system may correlatethe frequency, duration, and content of these user inquiries with known risk factors for various diseases, syndromes, or chronic conditions.

[0007] In another embodiment, the invention provides a system architecture designed to safeguard patient confidentiality while capturing critical health-related insights. The system employs secure data collection mechanisms that can operate anonymously or via user opt-in. If certain predefined thresholds or rules are met, e.g., the user searches repeatedly for severe headache symptoms over a period of weeks the system generates a context-sensitive notification. This notification may be conveyed directly to the user, strongly encouraging them to seek professional medical advice, or may be sent (with appropriate consent) to a designated healthcare provider or caregiver.

[0008] In another embodiment, the system focuses on improving clinical decision-making by supplying healthcare professionals with a comprehensive snapshot of a patient’s or family member’s self-reported concerns and online research behaviors. The invention can integrate with electronic health record (EHR) systems to supplement official medical histories with realtime intelligence on patients’ evolving concerns. Such intelligence may highlight the early onset of conditions that might otherwise go undiagnosed or untreated, leading to more informed consultations and proactive interventions.

[0009] In certain embodiments, the invention utilizes machine learning or artificial intelligence algorithms to refine detection patterns and personalize alerts. By analyzing aggregated data across multiple users, the system may dynamically adjust risk thresholds or prediction models, thereby increasing accuracy in flagging potentially urgent conditions. This adaptive framework can learn from individual users’ health profiles, analyzing factors such as age, gender, existing medical diagnoses, and genetic predispositions, ensuring highly tailored insights and recommendations.

[0010] In further embodiments, the invention includes a user-facing dashboard or mobile application that visualizes trends and highlights potential concerns. This interactive interface may present simple yet informative indicators (e.g., color-coded risk levels, trend lines for recurring searches) to encourage timely action. Additionally, the dashboard can offer educational resources such as health articles, symptom checklists, or appointment scheduling tools, enabling users to promptly transition from online research to professional medical consultation.

[0011] By proactively capturing repeated searches or patterns related to possible health conditions, the invention significantly reduces the likelihood that warning signs are ignored untilthey become acute. It also empowers family members or caregivers who conduct research on behalf of others to intervene earlier and with greater confidence. The system’s capacity for data- driven insights, customizable alerts, and seamless integration with healthcare workflows leads to improved patient outcomes, more efficient clinical practices, and a broad reduction in the delay of critical diagnoses.

[0012] Embodiments of the present disclosure may include claims for a System and Method for Updating Electronic Health Records (EHR) or Health Database based on Information Searches done by the patient or an agent on behalf of the patient, or an intermediary.

[0013] In some embodiments, the patient is not currently under medical supervision. The term user and patient are interchangeable.

[0014] In some embodiments, the user may be an artificial intelligence agent / worker, person or an automated or semi- automated process.

[0015] In some embodiments, the user may be conducting a search on behalf of someone else.

[0016] In some embodiments, the Al agent is a collection of one or more computer programs. In some embodiments, the Al agent is a collection of one or more self-learning programs.

[0017] Embodiments of the present disclosure may also include a method for updating electronic health records (EHR) including receiving a search query terms and results directly or indirectly from a user related to health, wellness or medical information such as symptoms, topics. Embodiments may also include identifying the user’s associated EHRs. Embodiments may also include updating the EHRs with information related to the search query.

[0018] In some embodiments, the health records could belong to someone other than the user.

[0019] In some embodiments, the search query may be input through a search engine, medical website (such as WebMD), or a specialized health, wellness platform such as Rekha's List. In some embodiments, the method may include notifying one or more healthcare providers associated with the user's EHR about the update. In some embodiments, the search query may be related to the user signing up for or inquiring about clinical trials.

[0020] In some embodiments, the healthcare provider may be a traditional healthcare provider, an Al agent, a family member or friend.

[0021] In some embodiments, the method may include using artificial intelligence to analyze the search query and predict potential health issues or needs. In some embodiments, the EHRupdate includes information about potential drug interactions based on the user’s current medication and search query. In some embodiments, the user has multiple EHRs, and the method includes updating one or more of these EHRs through a connecting intermediary such as Google, Amazon or Rekha's List, or an EHR solution provider or EHR data broker / aggregator.

[0022] In some embodiments, the method may include consolidating updates across multiple EHRs for comprehensive healthcare provider notification. Embodiments may also include a computer-readable medium including instructions which, when executed by a processor, perform the method. In some embodiments, the method may include allowing the user to specify whether the search may be for themselves, a family member, a friend, or for general research.

[0023] In some embodiments, an agent is aware of patient information and proactively conducts searches on behalf of a user.

[0024] In some embodiments, the method may include integrating the system with a healthcare-related website, such as Rekha’s List, for additional healthcare resource connectivity. In some embodiments, the EHR updater may be configured to trigger automatic alerts or interventions by healthcare providers or Al systems based on search and or EHR content. In some embodiments, the EHR update includes a timestamp and a source of the search query for historical tracking. Embodiments may also include user can store medication list.

[0025] Embodiments of the present disclosure may also include a system for updating electronic health records (EHR), including a search query receiver. Embodiments may also include an EHR identifier. Embodiments may also include an EHR updater configured to update the EHR based on the search query content. In some embodiments, the search query receiver may be configured to accept inputs in forms including, but not limited to, text, images, and audio.

[0026] In some embodiments, the system may include an artificial intelligence module configured to analyze patterns in the search queries for early detection or analysis of health issues. In some embodiments, the EHR updater may be further configured to compare medications of the user with the search query to identify potential drug interactions and inform user and the user's providers.

[0027] In some embodiments, the EHR updates can be done by a process or service in front of an EHR to identify the need to update zero or more EHR records.

[0028] In some embodiments, the system, further incorporating a user interface enabling the user to specify the context of their search. Embodiments may also include an internet or network connectivity module to facilitate the reception of search queries from various online platforms.In some embodiments, the system may include a database for storing historical search queries and associated EHR updates for longitudinal health tracking and analysis.

[0029] In some embodiments, an application may be monitoring user’s audio, video, or both and sending updates of events such as coughing, sneezing, slow speech pattern, lack of movement of body parts, tone and content of one or more voices.

[0030] In some embodiments, an application, or agent may be monitoring verbal, audio or gestural interaction via digital assistants. Analyzing audio content for tone and content, for example, curse words, and threats; video content for weapons such as knives or guns; or gestural interactions / inputs could indicate the user or someone in the user’s environment may be a victim of domestic violence or other harmful actions and notifications to emergency services, friends or family may need to be triggered.

[0031] Embodiments of the present disclosure may also include a method of granting permission (implicitly or explicitly) to send search terms and, or results to another entity such as a provider, or artificial intelligence agent.BRIEF DESCRIPTION OF THE FIGURES

[0032] FIG. 1 provides a high-level schematic view of a system in one embodiment of the invention.

[0033] FIG. 2 is a flowchart further illustrating the method for updating electronic health records from FIG. 1 , according to some embodiments of the present disclosure.

[0034] FIG. 3 is a block diagram illustrating a user from FIG. 1 , according to some embodiments of the present disclosure.

[0035] FIG. 4 is a block diagram illustrating a transaction system 120 from FIG. 1, according to some embodiments of the present disclosure.

[0036] FIG. 5 is a block diagram further illustrating an Al agent 140 from FIG. 1, according to some embodiments of the present disclosure.

[0037] FIG. 6 is a block diagram further illustrating agents 150 from FIG. 1 , according to some embodiments of the present disclosure.

[0038] FIG. 7 is a block diagram further illustrating notifications 170 from FIG. 1, according to some embodiments of the present disclosure.

[0039] FIG. 8 is a block diagram further illustrating network 160 from FIG. 1 , according to some embodiments of the present disclosure.

[0040] FIG. 9 is a schematic view further illustrating EHR system 130 from FIG. 1, according to some embodiments of the present disclosure.

[0041] FIG. 10 illustrates an exemplary representation of a row in a database table from a database from FIG. 9, according to some embodiments of the present disclosure.

[0042] FIG. 11 is a block diagram further illustrating health devices and environment monitoring devices from FIG. 1 , according to some embodiments of the present disclosure.

[0043] FIG. 12 is a block diagram illustrating an example computing system architecture suitable for implementing functionalities described herein, including receiving a user search query, analyzing search results, and updating an electronic health record (EHR) based on contextual information, wherein the system includes a processor, memory, user interface device, display device, storage device, removable storage, and a communications interface.DETAILED DESCRIPTION

[0044] In some embodiments, claims for a System and Method for Updating Electronic Health Records (EHR) or Health Database Based on Patient Information Searches.

[0045] FIG. 1 is a flowchart that describes a method for updating electronic health records, according to some embodiments of the present disclosure. In some embodiments, at 110, the method may include receiving a search query terms and results directly or indirectly from a user related to health or medical information such as symptoms, topics. At 120, the method may include identifying the user’s associated EHRs. At 130, the method may include updating the EHRs with information related to the search query. In some embodiments, the search query may be input through, but not limited to a search engine, medical website (such as WebMD), a health device, an application, or a wellness platform such as Rekha's List.

[0046] In some embodiments, the method may include notifying one or more healthcare providers associated with the user’s EHR about the update. In some embodiments, the search query and results may be related to the user signing up for or inquiring about clinical trials.

[0047] In some embodiments, the method may include using artificial intelligence to analyze the search query and predict potential health issues or needs.

[0048] In some embodiments, the EHR update may include information about potential drug interactions based on the user’ s current medication and search query. The update is generated by a process independently of the user such as an Al agent.

[0049] In some embodiments, a computer-readable medium. Instructions which, when executed by a processor, perform the method. In some embodiments, the method may include allowing the user to specify whether the search may be for themselves, a family member, a friend, or for general research. In some embodiments, the method may include integrating the system with a healthcare-related website, such as Rekha’s List, for additional healthcareresource connectivity. In some embodiments, the EHR updater may be configured to trigger automatic alerts or interventions by healthcare providers or Al systems based on search and or EHR content. In some embodiments, the EHR update may include a timestamp and a source of the search query for historical tracking. In some embodiments, users can store medication lists. In some embodiments, the EHR updater may have access to user’s medication list. In some embodiments, the EHR updater may access one or more EHRs related to user’s family or friends to formulate update(s). In some embodiments, access to the EHR may include one or more permissions and may further include the ability to update one or more records associated with the user.

[0050] FIG. 2 is a flowchart that further describes the method for updating electronic health records from FIG. 1 , according to some embodiments of the present disclosure. In some embodiments, at 210 the user is connected to one or more EHRs through an intermediary. In some embodiments at 210, the intermediary may also be the EHR. In some embodiments, at 220, the method may include consolidating updates across multiple EHRs for comprehensive healthcare provider notification. The process of locating and updating the EHR will be referred to as “EHR updater” or “EHR update”. This process can be anywhere in the system.

[0051] By way of example, a user 210 feels numbness in their left arm and wonders what the cause is. Was it caused by sleeping on his left side or was it from throwing a baseball for long periods of time from the day before? His iWatch 330 recorded abnormal readings during that time period. Later in the day, he feels numbness or weakness on the left side of his face. He decides to look up the causes of the symptoms by using the browser 220 application on his mobile device 320 using a search engine 410 to query what could cause numbness of his face. To the casual observer, it is possible these two events are unrelated. But to providers 180 of medical services or an Al agent 140, these search queries are datapoints that would cause them to believe the user 210 has symptoms of a stroke or other serious condition and immediate medical attention is necessary. The user’s EHR 130 has been located by the search engine 410 and updates from the iWatch 330 and search query and results of the search have been entered. Additional data can be reviewed by providers 180, Al agent 140, and transaction system 120 from devices 190 to narrow down possibilities. The user’s provider 650, family 620, and friends 610 would be notified 170. An Al agent 140 or provider 180 can contact user 110 to ensure proper care such as referring to emergency room, scheduling an appointment, or conduct field tests using health devices 330 and 190.

[0052] FIG. 3 illustrates an example user interaction subsystem 300, which represents a user and the various modalities by which the user may interact with the overall system, or on behalf of the user. The subsystem 300 includes but is not limited to: a personal computer (PC) 310, a mobile device 320, and a health device 330. These components may operate independently or in coordination, and any one or more of them may serve as an entry point for user generated data, device generated data, user queries, or device queries, or sensor-based input into the electronic health record (EHR) infrastructures.

[0053] A component may be also be referred to as a computing device.

[0054] In some embodiments, the query can be a search request against a search engine or website.

[0055] In some embodiments, the query can be a search against EHRs.

[0056] The terms query, search query and lookup can be used interchangeably.

[0057] In some embodiments, further incorporating, the system 300 may include a storage or database for storing queries and query results and associated EHR updates for tracking and analysis. The storage, database may be local or remote such as in the cloud, or both.

[0058] The PC 310 may be used by a user to initiate search queries via a web browser or other application. These queries may be captured by the system and analyzed for relevance to health conditions, symptoms, or lifestyle factors. In some embodiments, search activity on the PC 310 may be monitored passively or in response to explicit consent by the user and may be transmitted for further processing by the system’s Al agent or search analysis modules.

[0059] The mobile device 320 may include a smartphone or tablet and may serve multiple roles, including functioning as a portable search interface, a biometric monitoring gateway, or an environmental data collection platform. The mobile device 320 may include applications or operating system services that record user interactions, voice queries, passive or active audio capture, GPS data, or background sensor data, and may transmit such data to other parts of the system for health context analysis. In some embodiments, the mobile device may interface with wearable or external sensors to relay physiological or environmental information (e.g., heart rate, activity levels, ambient air quality) back to the user’s EHR. In some embodiments, the device itself can be all or part of the system FIG. 1.

[0060] The health device 330 may include any dedicated medical or wellness device configured to monitor one or more physiological parameters of the user. This may include, without limitation, pulse oximeters, glucose monitors, smartwatches, ECG devices, blood pressure monitors, or implantable devices. The health device 330 may transmit data eitherdirectly to the system or indirectly via an intermediary device such as mobile device 320. In some embodiments, the data from health device 330 may be used in real time or near-real time to update the user’s EHR or to support analysis by forecasting or anomaly detection modules.

[0061] It should be understood that system 300 is not limited to these three components. Additional user-facing interfaces or devices, such as smart speakers, home health hubs, or voice assistants, may also be incorporated into the system in other embodiments. Further, each of the components in system 300 may participate in both passive and active data flows, and may initiate or receive communications from other modules within the overall architecture depending on system configuration and user permissions.

[0062] It should also be understood that a combination of data from one or more of the components can be considered as multifaceted data.

[0063] FIG. 4 is a block diagram 400 that depicts an expanded view of Transaction System 120 from FIG. 1. In some embodiments, at 400 entities are connected via the network 160. At 430 various means of connectivity can be used. In some embodiments, the connectivity is wireless. In some embodiments, the connectivity is wired, or a wide area network (WAN).

[0064] In some embodiments, the one or more of the entities at 400 may be an intermediary. An intermediary will enable a connection or passing of data to and from another intermediary to enable the completion of a task such as sending a query, receiving results from a query, or sending data for updates or acknowledgments of data transfers.

[0065] In one embodiment, the Transaction System 400 may include elements such as a Search Engine 410, Rekha’s Fist 420, WebMD 430, and EPIC EHR 440. These components enable users 110 to initiate actions or queries that trigger responses throughout the overall system, including updates to EHR 130, interactions with the Al 140 and Agents 150, and data inputs from Health Devices 190. In addition to these components, the Transaction System 400 may also include one or more of the following modules:

[0066] Payment Gateway 450 can facilitate financial transactions related to healthcare services or product purchases. For instance, a user who locates a recommended service or product via Search Engine 410 or Rekha’s List 420 can check out securely via the Payment Gateway 450. This gateway may interface with external financial institutions, insurance systems, or user’s bank accounts to handle co-pays, subscriptions, medical supply orders, or other fees. Transaction details can be logged in the EHR 130 or an associated billing system to maintain records for analysis and processing.

[0067] Scheduler 460 allows users to book, modify, or cancel appointments with medical professionals. The module can interface with Provider 180 calendars, the EPIC EHR 440, and external scheduling platforms. Once an appointment is confirmed, the Appointment Scheduler 460 can trigger updates to the user’s EHR 130, create reminders via Agents 150, and even interact with Al 140 to recommend ideal times or follow-up procedures based on the user’s historical data.

[0068] Telehealth (or Telemedicine) Portal 470 enables virtual consultations between patients and providers. Users can initiate video calls, chat sessions, or remote diagnostic procedures directly through the Transaction System 120. After a telemedicine session concludes, the Portal 470 can forward consult notes or new prescriptions to the EPIC EHR 440 and can also utilize Al 140 or Agents 150 for automated follow-up recommendations, such as scheduling lab tests or adjusting medication dosages.

[0069] Pharmacy 480 integrates with local or online pharmacies. Users can search for medication details via WebMD 430, compare prices or coverage, and refill prescriptions all within the Transaction System 400. Once a prescription is selected or refilled, the Pharmacy Interface 480 may pass information to the Payment Gateway 450 for any necessary co-payments or direct billing, and it can log the transaction in the user’ s EHR 130 to maintain a current medication list.

[0070] An Insurance or Coverage Manager 490 module can handle insurance claims, preauthorizations, or coverage inquiries. When a user searches for a particular procedure through Search Engine 410, this module may check policy details to confirm whether the service is covered, partially covered, or requires prior approval. Based on the results, Al 140 or an Agent 150 might update the user’s record or send notifications prompting next steps. The Insurance Manager 490 can also interact with Payment Gateway 450 to reconcile any out-of-pocket expenses.

[0071] A Health Community or Forum 495 provides an online space where users 110 can discuss health-related topics, share experiences, or access expert Q&A. Connections to Al 140 may enhance this forum by recommending relevant discussion threads or resources based on user interests. Forum interactions could further link to the user’s EHR 130 if, for instance, they discover relevant self-care measures or provider recommendations they wish to save or discuss with a professional.

[0072] An Educational or Coaching Platform 497 delivers personalized lessons, tutorials, or health coaching programs. Users may pick programs (e.g., fitness routines, nutritional guides)recommended by Al 140 or discovered via the Search Engine 410. Progress tracking data from Health Devices 190 can feed into the user’s EHR 130, while the Coaching Platform 499 adjusts future lessons or advice accordingly. Agents 150 may provide reminders or encouragement via push notifications or text messages, helping users stay engaged.

[0073] FIG. 5 is a block diagram that further describes an Al sub-system 500 configured to perform various automated tasks and provide intelligent outputs or guidance. The Al module described herein may include a plurality of functional sub-systems or components, such as forecasting, anomaly detection, natural language processing, environmental signal interpretation, user profiling, and personalized recommendation engines. It should be understood that one or more of these sub-systems may be implemented individually or in combination, subdivided, or supplemented with additional features and services depending on the desired implementation. In certain implementations, specific sub-systems may be enabled, disabled, or selectively activated based on use case requirements, patient consent parameters, device capabilities, or system configurations. This modular architecture allows the Al module to be tailored for various healthcare environments, privacy needs, or levels of automation while still supporting the broader objectives of personalized health monitoring and electronic health record (EHR) enhancement. As shown in FIG. 5, the Al sub-system 500 may include one or more modules, such as Searching 510, Alerting 520, and Recommending 530.

[0074] In one embodiment, Searching module 510 is configured to query one or more data sources (e.g., a local database, a cloud-based repository, or a distributed ledger). The Searching module 510 can employ keyword matching, natural language processing, or vector-based search algorithms to retrieve relevant information. In one embodiment, Searching 510 might locate all patient records containing certain medication names or lab test results. In another embodiment, Searching 510 might index transaction data to find high-risk patterns or user- specific details. The Searching functionality can be extended to support semantic or context-aware queries, thereby allowing sophisticated retrieval of information beyond simple keyword matching.

[0075] Alerting module 520 is designed to monitor incoming and outgoing data to detect events or conditions that warrant notification. Such notifications can include system messages, user alerts, or third-party signals. In one embodiment, the Alerting module 520 correlates realtime data streams against predefined thresholds or Al-driven anomaly detection models. In one embodiment, when certain criteria are met, a high-risk transaction is detected, a critical lab result is recorded, or a sensor reading indicates a possible malfunction — the module automatically generates alerts that may be delivered via email, text message, mobile app push notification, orany other suitable channel. The Alerting module 520 can also prioritize or categorize alerts based on severity, urgency, or relevance, thus preventing unnecessary noise and ensuring critical events are appropriately escalated.

[0076] Recommending module 530 leverages machine learning algorithms, rules-based logic, or a combination thereof, to generate suggestions or recommendations. These recommendations can range from product suggestions (in an e-commerce scenario) to treatment plans (in a clinical setting) or next-step actions (in a workflow management application). In some embodiments, 530 adapts recommendations based on user preferences, learned patterns, or contextual data such as location, time of day, or user behavior history. The module can interface with user interfaces, chatbots, or external applications to deliver recommendations in a contextually relevant manner (e.g., prompting a user to reorder supplies when stock runs low, or suggesting an upcoming appointment time slot when a calendar gap is detected).

[0077] In one embodiment, the Al agent monitors data sources such as internet-based sources comprising of peer reviewed journals, clinical trial repositories, government databases and medical news feeds.

[0078] In other embodiments, the Al sub-system 500 may include or interface with additional modules or processes, such as:

[0079] Summarizing 540: In one embodiment, the Summarizing module may employ natural language processing and machine learning to generate concise textual or verbal summaries of lengthy or complex data. In one embodiment, the system may produce a brief synopsis of patient history or financial reports.

[0080] Classifying 550: In one embodiment, the Classification module may categorize documents, images, or structured data into predefined classes or topics. In one embodiment, the system may automatically classify support tickets, emails, medical images, or financial transactions by type, enabling faster and more organized workflows.

[0081] Forecasting 560: In one embodiment, the Forecasting module is configured to predict future health-related events, trends, or risk factors based on historical, biometric, environmental, behavioral, and contextual data. For example, the module may forecast the likelihood of disease onset, exacerbation of chronic conditions, medication adherence issues, or lifestyle-triggered health events such as sleep disruption, cardiovascular stress, or respiratory complications. The forecasting capabilities may also extend to anticipating patient care needs, such as the timing of follow-up visits, likelihood of emergency interventions, or care coordination requirements.These predictions may be incorporated into the patient's EHR, presented to authorized healthcare professionals, or used to trigger preemptive alerts and recommendations through the system.

[0082] In certain embodiments, the Forecasting module 560 may further support proactive patient engagement and clinical decision-making by generating reminders and alerts based on analyzed data. These may include preventive care reminders, such as notifications for recommended screenings, vaccinations, or wellness activities tailored to the patient’s age, medical history, or risk profile. The system may also issue reminders for upcoming appointments or follow-up visits, improving care plan adherence. Additionally, the module may trigger anomaly flags when monitored data — such as biometric signals, environmental exposure levels, or behavioral patterns — deviate from established baselines or clinical thresholds, indicating a potential health issue that warrants attention. Such flags may be displayed to the user, caregiver, or healthcare provider via a secure interface and may be recorded in the EHR along with system-generated contextual explanations.

[0083] Pattern Recognition 570: In one embodiment, the Pattern Recognition algorithms can identify repeated behaviors, anomaly signals, or correlations in large datasets. For example, if a user’s account exhibits an uncharacteristic spending pattern, the system may flag it for review.

[0084] Automated Decision-Making 580: In one embodiment, the Al sub-system 500 may be authorized to take autonomous actions based on its analysis. In one embodiment, the system may auto-approve low-risk transactions or automatically schedule routine maintenance when sensor data indicates an impending need.

[0085] Explanation Generation 590: In one embodiment, to support transparency or regulatory compliance, or to enhance communication of information, an Explanation module may provide human-readable justifications for system driven events. In one embodiment this could be language / dialect translation. In one embodiment, 590 could be located in various parts of the system.

[0086] The Al sub-system 500 may reside on-premises, in a cloud environment, or in a hybrid architecture. It can interface with one or more networks 160 to communicate with Agents 150 or other subsystems within the overall system. Notably, the Al functionalities need not be limited to generating or managing agents 150. Instead, Al capabilities can be invoked at virtually any point in the data flow, such as when collecting data, archiving it, analyzing it in real time, or generating dashboards and analytics for system operators.

[0087] For instance, an enterprise software platform may deploy Searching 510 in a centralized data lake environment, Alerting 520 in an incident response service, andRecommending 530 in a user-facing portal. Other functionalities like Summarizing 540 or Classifying 550 could be modular add-ons, invoked only if authorized or required by certain user roles or system processes. Thus, the invention contemplates a versatile and extensible Al sub-system 500 that can be integrated into virtually any portion of a larger technical architecture to enhance data-driven decision-making, automation, and user experience.

[0088] In some embodiments, the data used by the Al agents may be curated, customized or filtered for that specific Al agent.

[0089] In some embodiments, one or more Al agents may collaborate to work as a unified Al agent.

[0090] FIG. 6 is a system block 600 that expands on the Agents block 150 described previously. In certain embodiments, Agents may be human participants, software processes, or hardware devices that interact with various other components of the overall system, for example, the electronic health record (EHR 130), Providers 180, Health Devices 190, or the Transaction System 120. As shown in FIG. 6, the Agents system 600 may include, among others, Friend 610, Family 620, Autonomous Process 630, Semi-autonomous Process 640, Provider 650, and Durable Medical Equipment 660. It will be understood that these are illustrative categories; the invention contemplates Agents in other forms as well, depending on context and implementation.

[0091] In some embodiments, a user 1 10 interacting with the Transaction System 120 may designate one or more human Agents as Friend 610 or Family 620. These individuals could receive partial or full access privileges to the user’ s data, enabling them to view or update the user’s information stored in the EHR 130. In one embodiment, a Friend might schedule an appointment on behalf of the user, or a family member could receive notifications of important healthcare updates. The system may implement permission settings, authentication protocols, and role-based access controls to ensure that each Agent can only access or modify data to the extent authorized.

[0092] An Autonomous Process 630 represents a component configured to operate without direct human intervention. In one embodiment, this component is a software program. In one embodiment, this Agent can be deployed anywhere in the network 160 to automatically carry out tasks such as monitoring, scheduling, ordering supplies, or performing analytics. In one embodiment, an Autonomous Process might scan the EHR 130 for missing data, check Health Devices 190 for abnormal readings, or interface with the Transaction System 120 to triggerpurchases of consumable medical supplies. The process’s autonomy allows it to respond in real time to system events or data changes, improving efficiency and reducing human error.

[0093] A Semi-autonomous Process 640 has similar capabilities to the Autonomous Process 630 but requires some level of human confirmation or oversight. For example, the system might flag a potential prescription renewal automatically but prompt a human user 110 or Provider 650 to confirm before finalizing the transaction in the EHR 130. This hybrid approach leverages automated logic to expedite routine tasks, while still allowing for manual review or additional input where necessary to ensure accuracy or meet regulatory requirements.

[0094] Provider 650 refers to healthcare professionals, clinicians, or any authorized personnel who interface with the system to access, review, or modify patient information. While Providers 650 may also appear as a separate entity in the overall system 180, within the Agents block 600 they function specifically as an Agent with distinct permissions and responsibilities.A Provider might, for instance, update patient treatment plans in the EHR 130, order tests via the Transaction System 120, or receive device readings from Health Devices 190. Providers can likewise delegate tasks to other Agents — such as instructing an Autonomous Process 630 to schedule follow-up appointments or alerting a Family Agent 620 about critical care instructions.

[0095] Durable Medical Equipment 660 can also serve as an Agent within the system. Examples include patient monitoring devices, infusion pumps, or other equipment that can communicate directly with the EHR 130 and / or Health Devices 190. By embedding communication modules and Al-based controls, such equipment may track usage, report selfdiagnostic information, and even reorder necessary supplies via the Transaction System 120. Furthermore, Durable Medical Equipment 660 may generate autonomous alerts (e.g., low battery warnings, calibration needs) or transmit updated readings to the EHR without requiring manual data entry, thereby improving the accuracy and timeliness of health records.

[0096] FIG. 6 depicts Agents 600 as discrete blocks, Friend 610, Family 620, Autonomous Process 630, Semi-autonomous Process 640, Provider 650, and Durable Medical Equipment 660, etc. it should be noted that these entities can be located or deployed in various parts of the overall network 160. In one embodiment, a user’s friend 610 might be geographically remote, accessing the system through a secure web portal; a semi-autonomous process 640 might run in a cloud environment dedicated to handling scheduling requests; and a piece of durable medical equipment 660 might be stationed at the patient’s residence or in a clinical setting.

[0097] The invention contemplates that Agents communicate with each other and with other system blocks (e.g., EHR 130, Providers 180, Health Devices 190, Transaction System 120) in aflexible manner. In some embodiments, the Al sub-system (FIG. 5) may attach to one or more Agents to provide intelligent features (such as recommending, searching, or alerting). In other embodiments, Agents may operate independently of Al to fulfill their intended functions. This architecture thereby allows for a customizable, scalable solution, enabling the addition, removal, or modification of Agent types and functionalities to accommodate evolving requirements, user preferences, and technological advancements.

[0098] A Caregiver 670 could be a professional home health aide, personal care assistant, or any non-physician healthcare worker who interacts directly with the patient. Like Friend 610 and Family 620, a Caregiver might have partial or full permissions to access patient data within the EHR 130, update daily observations (e.g., vitals, mood, dietary intake), and even carry out tasks prescribed by a Provider 650. In some scenarios, Caregivers could leverage Semi- Autonomous Processes 640 to remind them when medication administration or device checks are due, ensuring more accurate, timely care.

[0099] A Pharmacy 680 Agent can represent a pharmacy system (either brick-and-mortar or online) authorized to receive and process prescription orders from Providers 650. The Pharmacy Agent may also interface with the Transaction System 120 to manage payment and billing details. By being part of the Agents block 600, the Pharmacy 680 can automatically receive prescription requests, check for drug availability or potential interactions, and update the EHR 130 once a medication has been dispensed, all under secure, role-based access controls.

[0100] An Insurance or Payer 690 Agent can handle insurance claims, coverage approvals, or payment processing. For example, after a Provider 650 issues a new treatment plan, the Payer 690 Agent could automatically review coverage details and update the user’ s financial or claims status in the Transaction System 120. In some embodiments, advanced logic (e.g., Al-driven policy matching) could be employed by the Payer Agent to expedite pre- authorization for procedures or medications, and to notify the user 110 or Caregiver 670 of any cost-sharing obligations.

[0101] A Billing Entity 695 Agent might specifically manage invoicing and payment reconciliation for any services rendered in the system. Although closely related to Insurance / Payer 690, the Billing Entity 695 may be more general, handling direct user payments (e.g., out-of-pocket costs), subscription fees, or co-pays. This Agent can interface both with the Transaction System 120 for real-time payment processing and with the EHR 130 to ensure all charges align with documented care events or device usage logs.

[0102] A Chatbot or Virtual Assistant 697 could serve as a communication layer for user 110 interactions, answering questions about upcoming appointments, medication schedules, or general system navigation. If Al sub-system (FIG. 5) is integrated, the chatbot can leverage Searching 510 to retrieve relevant data from the EHR 130, Alerting 520 to push important notifications, and Recommending 530 to suggest personalized health tips or next steps.

[0103] In one embodiment, a Third-Party Integrator 699 might facilitate data exchange with external platforms such as labs, imaging centers, specialty clinics, or even social support services. In some embodiments, the Integrator handles format conversion, authentication, and secure communication protocols to ensure that data flows seamlessly between the user’s EHR 130 and these external systems. By categorizing such an integrator as an Agent, you can clearly define its responsibilities and data access privileges in the patent.

[0104] FIG. 7 is a block diagram that further describes the notification system 170 from FIG. 1, which may be integrated into any parts of the other system in different embodiments. In one embodiment, subsystem 700 is configured to send out a variety of notifications through multiple channels, including but not limited to Email 710, an EHR Portal 720, SMS / MMS 730, Phone 740 calls, and Mail 750.

[0105] Email 710: In one embodiment, this component enables sending and receiving email notifications to one or more recipients. By way of non-limiting example, the subsystem 700 may integrate with third-party email providers or SMTP servers to handle message delivery, tracking, and bounce management.

[0106] EHR Portal 720: In one embodiment, this portal may be accessible via a web-based or mobile application interface. This portal 720 can display alerts, documents, or other information to users. Notifications within this channel can include messages about account status, available downloads, or time-sensitive prompts.

[0107] SMS / MMS 730: The subsystem 700 may communicate via text messages (SMS) and multimedia messages (MMS). In some implementations, third-party messaging services are leveraged to handle message routing, delivery confirmations, and retries. This feature 730 can be used for transactional alerts, marketing messages, or urgent system updates.

[0108] Phone 740: This element covers automated or semi-automated phone calls, which can provide voice-based notifications. In various embodiments, the phone component 740 could use prerecorded messages, text-to-speech conversion, or interactive voice response (IVR) to guide recipients through instructions or gather responses.

[0109] Mail 750: The subsystem 700 may also generate and coordinate physical mailings. This can include printing, stuffing, and sending letters or other printed materials. This channel 750 is particularly useful for notices, documents, or scenarios in which email and digital channels are insufficient or unavailable.

[0110] The arrangement shown in FIG. 7 is merely illustrative. In various embodiments, additional or fewer channels may be present, and the implementation details for each channel can vary. For instance, subsystem 700 may employ local hardware, cloud-based services, third- party APIs, or any combination thereof. Furthermore, while the blocks 710, 720, 730, 740, and 750 are shown within a single subsystem 700, they may be distributed across multiple servers or applications. The particular arrangement, naming conventions, and integration points can be adapted or altered without departing from the scope of the invention.

[0111] FIG. 8 is a block diagram that further describes the network system 160 from FIG. 1.

[0112] The term “network” as used herein refers broadly to any infrastructure or configuration that facilitates communication and / or data exchange between devices, systems, users, or services. The network may include, but is not limited to, the Internet, intranets, extranets, local area networks (LAN), wide area networks (WAN), wireless networks (Wi-Fi, cellular), and any combination thereof. The network may employ any suitable communication protocols, such as TCP / IP, HTTP, HTTPS, FTP, and others, and may utilize wired, wireless, or hybrid communication paths.

[0113] In various embodiments, the network functions as a communication medium through which client devices, servers, data repositories, or other components interact. The network enables the exchange of messages, data packets, control signals, and service requests across different hardware platforms, operating systems, and physical locations. The specific architecture of the network is not limited and may dynamically change to accommodate device mobility, bandwidth variation, or fault tolerance mechanisms. The network may also support peer-to-peer communication, cloud-based services, or hybrid models.

[0114] The network described herein is intended to be scalable, supporting connections among a few devices or extending to millions of users and endpoints across global regions. It is also interoperable, capable of connecting heterogeneous systems regardless of underlying software, hardware, or network topology. For example, a smartphone on a 5G mobile network, a desktop computer on a fiber-optic broadband connection, and a web server hosted on a cloud platform can all communicate via the same network framework described.

[0115] In the context of the claimed invention, the network provides the essential infrastructure for enabling distributed operations, remote access, and data synchronization between participating components. The network serves as the underlying layer for service delivery, whether that involves transmitting user inputs to a remote server, retrieving content from cloud storage, or broadcasting messages between interconnected devices. The invention does not rely on a specific type of network or configuration; rather, it is adaptable to any suitable communication infrastructure that fulfills the described functional requirements.

[0116] FIG. 9 is an illustrative block diagram depicting a healthcare platform or system for managing, updating, and coordinating patient medical records across multiple healthcare providers. The system includes a provider 910, which may be a hospital system or other healthcare institution that originates or maintains patient records. The provider 910 is communicatively coupled to an electronic health record (“EHR”) provider 920, which may be a commercial EHR solution (e.g., Epic), or another platform responsible for storing and managing health-related data. By interfacing with the provider 910, the EHR provider 920 facilitates the creation, retrieval, and modification of patient records, ensuring consistency of patient data across various healthcare entities.

[0117] In some embodiments, the system at 900 may be implemented as, or may otherwise be comprised of an electronic healthcare system, an electronic healthcare database, or any combination thereof.

[0118] The EHR provider 920 is connected to a record lookup module 930. The record lookup module 930 is configured to identify or verify patient identities, for instance, by referencing unique patient identifiers. In one embodiment, the record lookup module 930 may receive a request containing patient demographic data (e.g., name, date of birth, address, and other relevant information) and then conduct a search to match or retrieve the appropriate patient identifier from a database 940. In alternative implementations, the record lookup module 930 may also generate new identifiers for patients without existing records, thereby integrating seamlessly into healthcare environments that lack standardized patient identification protocols.

[0119] The record lookup module 930 is operatively coupled to a database 940, which is configured to store a variety of patient-related information, including demographic data, historical diagnoses, lab results, and other healthcare data. In some embodiments, the database 940 may also store provider or facility information, allowing the record lookup module 930 to retrieve records corresponding to multiple providers 910. As a result, when the EHR provider 920 initiates an update request for a patient’s records at one or more providers 910, the recordlookup module 930 references the database 940 to confirm the correct patient identifier(s) and relevant record(s).

[0120] In further embodiments, the database 940 may be distributed or replicated across multiple geographic regions or cloud infrastructures to promote data redundancy and facilitate quick access. The record lookup module 930 may employ communication protocols to synchronize patient IDs and medical data between the database 940 and various EHR systems, ensuring that a given patient’s data is consistent across different providers 910. Additionally, the provider 910, EHR provider 920, record lookup module 930, and database 940 may collectively implement security measures — such as encryption, role-based access controls, and auditing functionalities — to comply with healthcare privacy regulations and to safeguard sensitive patient information.

[0121] FIG. 9 depicts a single provider 910, it is understood that multiple providers can be connected to the EHR provider 920, with each provider maintaining its own data sets. The record lookup module 930 may handle aggregation, reconciliation, and synchronization of records across these multiple providers. In certain implementations, a patient or authorized user may also have the capability to review and approve changes before the EHR provider 920 finalizes updates in the database 940. Such flexibility ensures the system can accommodate different governance or compliance requirements as they pertain to healthcare data management.

[0122] It will be appreciated that FIG. 9 is an exemplary illustration. In other variations, the record lookup module 930 and database 940 may be integrated into a single unit within the EHR provider’s 920 infrastructure or distributed across different physical or virtual environments. Likewise, the functionalities described for the EHR provider 920 and the record lookup module 930 may be divided among additional subsystems or combined into fewer integrated modules without departing from the scope of the present disclosure.

[0123] FIG. 10 is a schematic illustration of one embodiment showing a meta database table configured to facilitate the identification of patient records across multiple providers and electronic health record (“EHR”) systems. The meta database table captures various identifiers that collectively form a mapping to link a patient’s health records, regardless of the differing identification conventions used among providers. In one embodiment, the meta database table may reside within a transaction system 120 or another platform capable of serving as a unified repository for patient identity information.

[0124] In the illustrative embodiment of FIG. 10, the meta database table includes a User ID 1010, which may correspond to an email address or other unique username for a patient (e.g.,“mike_jones@example.com”). The User ID 1010 allows the patient to be uniquely recognized by the transaction system 120 or other entities interfacing with the meta database table. An EHR System field 1020 indicates the specific EHR platform associated with the patient’s records, such as Epic or another health information software solution.

[0125] Provider field 1030 (e.g., “Stanford Hospital”) further refines the identification process by specifying the healthcare organization or institution where the records are held. Because individual providers may maintain their own local patient identifiers, an EHR ID 1040 column is included to store the unique identifier assigned by that provider’ s EHR system. EHR ID 1040 enables accurate retrieval of the patient’s clinical data from a particular healthcare facility.

[0126] SSN field 1050 captures the patient’s Social Security Number or another form of government-issued identifier, when legally permissible, for additional verification or disambiguation. It will be appreciated that while the use of SSNs is common in certain regions, this field may be replaced by other national identifiers or personal identification data, depending on regulatory requirements and privacy constraints.

[0127] Master ID 1060 field is provided for unifying the patient’s identity across diverse EHR systems and healthcare providers. In some implementations, the Master ID 1060 may be a globally unique identifier that allows an authorized entity (e.g., transaction system 120) with access to the meta database table to locate the patient’s medical records in any associated EHR system or provider. In one embodiment, when a lookup is performed using any one of the identifiers contained in the table, such as the User ID 1010, SSN 1050, or a specific EHR ID 1040, the meta database table returns the corresponding Master ID 1060 to pinpoint the correct medical record location.

[0128] In one embodiment, the metadata approach delivers a robust, scalable solution for data interoperability. In exemplary use cases, the transaction system 120 can leverage the meta database table not only for resolving a patient’s identity across multiple care settings, but also for routing or updating patient-related transactions (e.g., prescription refills, billing, insurance claims) without manual reconciliation of mismatched identifiers. FIG. 10 depicts an illustrative set of data columns, additional fields may be included (e.g., contact information, date of birth, insurance policy ID) to further enrich the record linking process.

[0129] FIG. 11, a schematic diagram, illustrates various health and environment monitoring devices (generally referred to as devices 190 in preceding figures) capable of capturing, transmitting, and potentially retrieving health or wellness data for a patient. These devices mayinclude sensors configured to detect environmental factors that may influence health, such as air quality, temperature, humidity, geolocation, noise levels, language content, tone of voice, and other context-sensitive or affective environmental conditions. The captured data may be physiological, behavioral, or environmental in nature, and may be used to provide continuous or periodic updates to the patient’s electronic health record (EHR) system. Such updates enable authorized users and receivers of data, including healthcare providers, caretakers, and emergency services, to access the patient’s most recent biometric, diagnostic, and environmental exposure data. In certain embodiments, the devices 190 or the networks that interconnect them are equipped with robust privacy and permissions mechanisms to ensure that data transmissions and lookups remain compliant with applicable regulations (e.g., HIPAA) and patient consent protocols.

[0130] In the illustrated embodiment, a Cell Phone 1110 may have one or more installed health applications, devices, components that measure user activity, heart rate, and other vitals. These applications employ secure channels, such as encrypted connections or token-based authentication, to update or query a patient’s EHR. User permission is typically required for sharing personal health data, ensuring that the patient’s privacy preferences and consent requirements are respected. A Pulse Oximeter 1120 (“Pulse Ox Monitor”) similarly records and relays oxygen saturation (SpO2) values and heart rate data to the patient’s EHR, with built-in privacy and role-based access controls. In this manner, only credentialed healthcare professionals or authorized family members are able to review or retrieve the transmitted measurements.

[0131] In some embodiments, the application, device or component may be passive. For example, continuous streaming of audio, continuous streaming of video or a combination of both.

[0132] In some embodiments, haptic technology may be used.

[0133] An iWatch 1130 (or a similar wearable device) illustrates how devices may incorporate EHR lookup capabilities. For instance, the iWatch 1130 can receive commands from a healthcare provider’s application programming interface (API) to display summarized portions of the patient’s health record or relevant medication reminders. Before performing any data retrieval, however, the iWatch 1130 confirms the user’s identity via biometrics (e.g., face identification, fingerprint, or passcode) and ensures that authorization tokens are valid, thereby preventing unauthorized access. In alternate implementations, the network infrastructure mayhandle EHR lookup requests, verifying the identity of the requesting device and patient, and then returning the relevant data subsets.

[0134] A Pacemaker 1140, which may store critical device performance data (e.g., battery status, pacing frequency), as well as a Defibrillator 1150, which may maintain logs of defibrillation events and self-diagnostics. Both the Pacemaker 1140 and the Defibrillator 1150 can securely transmit these data sets into a patient’s health record via either direct communication with the EHR system or an intermediary monitoring server. Likewise, these devices can retrieve limited patient data through authorized lookups for example, to confirm medication dosages or other relevant clinical instructions subject to patient consent and proper authentication protocols.

[0135] FIG. 11 shows specific devices (Cell Phone 1110, Pulse Ox Monitor 1120, iWatch 1130, Pacemaker 1140, and Defibrillator 1150), the disclosed arrangement extends to additional consumer electronics, wearable sensors, or implantable devices that collect health metrics. Each device’s connectivity framework may be configured to ensure compliance with privacy regulations and user permissions. For instance, encryption may be used for all data in transit, while secure key management ensures only certified applications can read or write to the EHR. Furthermore, each transaction or lookup may be logged by an auditing service to provide an immutable record of accesses and updates, thus assisting in maintaining accountability and detecting any potential breaches.

[0136] The system’s ability to seamlessly integrate these various devices with an EHR platform along with robust privacy controls and permissions handling enables a comprehensive view of a patient’s wellness profile. In certain embodiments, real-time analytics can be applied to the data streams, generating automated alerts for both the patient and healthcare providers when readings fall outside predefined thresholds. Likewise, a healthcare provider may send targeted information, such as medication adjustments or exercise recommendations, back to these devices for immediate patient guidance. The overall architecture thus supports a bidirectional flow of secure, patient-centric health information, offering improved care coordination, early detection of adverse events, and enhanced patient engagement.

[0137] FIG 12 is one embodiment of a computing system 1200 for use in implementing aspects of the invention, including processing search-based inputs and updating electronic health records (EHRs) based on analysis of internet search results. The computing system 1200 may be configured to execute instructions for receiving, analyzing, and generating recommendations forEHR updates using one or more agents, including artificial intelligence (Al) modules or human operators.

[0138] The computing system 1200 includes one or more processors 1202 for executing software instructions and performing processing tasks related to search analysis, contextual relevance evaluation, and EHR recommendation generation. Coupled to the processor(s) 1202 is memory 1204, which may include volatile or non-volatile memory (e.g., RAM, ROM, cache) and stores executable instructions and temporary data structures.

[0139] A display device 1206 is configured to present visual data, including search results, update recommendations, confidence scores, and EHR interface views. A user interface device 1208, such as a keyboard, touchscreen, mouse, microphone, or voice recognition system, allows users to input search queries, respond to update prompts, or appro ve / reject update recommendations .

[0140] The system also comprises a storage device 1212, which may include a hard disk, solid-state drive, or similar permanent storage, and is configured to store electronic health records, patient history, update logs, and machine learning models. In some embodiments, a removable storage device 1214, such as a USB drive or external memory card, may be used to import / export EHR data, software updates, or audit logs.

[0141] It would readily be apparent to a person of ordinary skill in the art of Al and ML that the models must be trained. Training can be done using one or more datasets as determined by the person.

[0142] A communications interface 1216 enables the computing system 1200 to access remote content via a network (e.g., the Internet), allowing it to retrieve search results in real time and, optionally, transmit or receive EHR data from a central healthcare server or cloud-based system. The interface 1216 may support wired and / or wireless protocols, including Ethernet, Wi-Fi, Bluetooth, or 5G.

[0143] In operation, the computing system 1200 may execute software stored in memory 1204 to perform the processes described in the system, method, and computer-readable medium claims, including receiving user-generated search input, analyzing search content using local and / or remote tools, and determining whether EHR updates are warranted based on clinical relevance.

[0144] Furthermore, method embodiments may execute solely upon the processors or may execute over a network such as the Internet in conjunction with remote processors that share a portion of the processing.

[0145] The term “non-transient computer readable medium” is used generally to refer to media such as main memory, secondary memory, removable storage, and storage devices, such as hard disks, flash memory, disk drive memory, CD-ROM, and other forms of persistent memory and shall not be construed to cover transitory subject matter, such as carrier waves or signals. Examples of computer code include machine code, such as produced by a compiler, and files containing higher level code that are executed by a computer using an interpreter. Computer readable media may also be computer code transmitted by a computer data signal embodied in a carrier wave and representing a sequence of instructions that are executable by a processor.

[0146] While FIG. 12 depicts an example configuration, other implementations may include additional components or combine certain components. The system may be embodied in a standalone device, a server, a distributed system, or as part of a networked EHR platform.

[0147] Unless context states otherwise, the term “processing module” refers to any hardware, software, firmware, or combination thereof that executes computational logic to analyze, transform, or derive information from input data. A processing module may include one or more processors (e.g., CPUs, GPUs, ASICs), memory devices, and executable instructions configured to perform tasks such as data cleansing, feature extraction, statistical inference, machine-learning model training or inference, rules-based decision making, or any other data-processing operation. The processing module may be implemented as a standalone component, as part of a distributed computing cluster, or co-located with other modules within the same physical housing.

[0148] Unless the context states otherwise, the term “integration module” refers to any hardware, software, firmware, or combination thereof that facilitates communication, data exchange, or functional coordination between two or more distinct systems, services, or components. An integration module may perform operations such as protocol translation, API orchestration, message queuing, data normalization, schema mapping, or authentication / authorization brokering. The integration module may be implemented as middleware, a service bus, an adapter layer, a microservice, or any other architectural construct that enables interoperability among heterogeneous systems.

[0149] Embodiments of the present disclosure may include claims for a System and Method for Updating Electronic Health Records (EHR) or Health Database Based on Patient’s or Agent’s Information Searches.

Claims

CLAIMS1. A method for updating at least one electronic health record, the method comprising: a) receiving, by a computing device, a search query from a user; b) identifying, by the computing device, at least one electronic health record associated with the user; and c) updating the at least one electronic health record with information regarding the search query.

2. The method of claim 1 , wherein at least one electronic health record may be associated with a family member or a friend of the user.

3. The method of claim 1 , further comprising providing notification based on the updated electronic health record.

4. The method of claim 1 , wherein updating at least one electronic health record is performed through an intermediary system.

5. The method of claim 1 , wherein the search query is a search query over the Internet regarding symptoms of an illness.

6. The method of claim 1 , wherein the search query is a search query over the Internet regarding a treatment for an illness.

7. The method of claim 1, wherein the search query is received from an artificial intelligence service regarding symptoms of an illness.

8. An electronic healthcare system, comprising:(a) an electronic healthcare database comprising a plurality of electronic health records for a plurality of users; and(b) a controller in communication with the electronic healthcare database, the controller configured to:(i) receive at least one search query from a user;(ii) identify at least one electronic health record associated with the user; and(iii) update the identified electronic health record with information regarding the search query.

9. The electronic healthcare system of claim 8, further comprising a module configured to allow one or more user’ s electronic health records to connect and share information including genetic predispositions, test results, or evaluation results.

10. A system for integrating diverse data types into electronic health records (EHRs), the system comprising:(a) a data collection module configured to capture:(i) web browsing data initiated by a user;(ii) verbal interactions via digital assistants;(iii) passive data inputs from background applications on user devices;(iv) environmental data from sensors; and(v) health data from monitoring devices;(vi) non-verbal interactions;(vii) physical interactions;(b) an integration module configured to:(i) aggregate the captured data;(ii) enhance the data with historical medical records of the user;(iii) optionally incorporate data pertaining to family members of the user; and(iv) transmit the aggregated data to one or more EHR systems;(c) a processing module configured to:(i) use artificial intelligence (Al) to analyze the aggregated data for health-related insights using the user’s comprehensive health profile and optionally health profiles of friends or family members; and(ii) operate autonomously or semi-autonomously on behalf of the user to identify health issues or potential future issues; and(d) a notification module configured to issue alerts based on the Al analysis to at least one of the users, a healthcare provider, emergency services or a combination thereof.

11. The system of claim 10, wherein the environmental data includes at least one of: air quality, temperature, humidity, noise levels, user language content, or other health- affecting environmental conditions.

12. The system of claim 10, wherein the health data from monitoring devices includes at least one of: heart rate, blood pressure, glucose level, oxygen saturation, or body temperature.

13. The system of claim 10, wherein the integration module further comprises mechanisms for correlating and synchronizing real-time and historical health data from multiple sources to maintain an accurate and up-to-date electronic health record.

14. The system of claim 10, wherein the processing module utilizes machine learning-based predictive modeling to assess health risks and trends from comprehensive data inputs and is configured for continuous execution to facilitate patient compliance, scheduling of appointments, and delivery of reminders.

15. A method for integrating multifaceted data into electronic health records (EHRs), the method comprising:(a) collecting data from at least one of:(i) web browsing activity;(ii) verbal interactions;(iii) passive device monitoring, video, audio and motion / gesture;(iv) active device monitoring, video, audio and motion / gesture;(v) environmental sensing;(vi) health device monitoring; or(vii) artificial intelligence agent activity performed on behalf of a user;(b) enhancing the collected data with historical medical data of the user;(c) transmitting the enhanced data to one or more EHR systems;(d) utilizing an Al-based processing module to analyze the enhanced data for holistic health insights;(e) issuing health-related alerts to at least one of a user, a healthcare provider, an emergency responder or combination thereof based on the analyzed data; and(f) monitoring, by an agent, internet-based sources for articles, research, or other information related to the user’s EHR.

16. The method of claim 15, further comprising of real-time integration of data from health or environmental monitoring devices into at least one electronic health record for continuous health and environmental condition monitoring.

17. The method of claim 15, wherein the Al-based processing module comprises a machine learning model trained on at least one of: historical medical records, anonymized patient datasets, or population-level health trends.

18. The method of claim 15, wherein the alerts issued include at least one of: preventive care recommendations, reminders for follow-up appointments, or anomaly flags indicating potential health deterioration.

19. The method of claim 15, wherein the data collection includes contextual metadata such as timestamps, geolocation, device ID, and user activity level.

20. The method of claim 15, wherein the Al agent monitors internet-based sources comprising at least one of: peer-reviewed medical journals, clinical trial repositories, government health databases, and curated medical news feeds.

21. The method of claim 15, further comprising prioritizing alerts based on a user-specific risk score derived from the enhanced data and historical medical conditions.

22. The method of claim 15, wherein the collected data is securely transmitted to the EHR system via a HIPAA-compliant communication protocol.

23. The method of claim 15, wherein the agent activity includes contextual tracking of emerging disease outbreaks, drug recalls, or clinical research related to the user’s diagnosed conditions.

24. The method of claim 15, wherein the alerts are presented to the user through a user interface comprising at least one of: a mobile application, a web-based dashboard, or a wearable device.

25. A method for updating an electronic health record (EHR), the method comprising:(a) receiving a user-initiated search query via a user interface device;(b) retrieving, via a communications interface, internet search results related to the search query;(c) identifying one or more clinical concepts in the search results by matching the search query and search content to a medical knowledge base;(d) determining, using one or more processors, whether the identified clinical concepts are relevant to a patient's EHR;(e) generating a recommendation for updating the EHR based on the determination; and(f) transmitting the recommendation to an agent comprising at least one of an artificial intelligence engine or a human reviewer, wherein the agent selectively approves or rejects the EHR update.

26. The method of claim 17, further comprising generating an alert to notify a clinician of the recommended update.

27. The method of claim 17, wherein identifying clinical concepts comprises parsing the search results using natural language processing (NLP).

28. The method of claim 1, where in the contextual information comprises page titles, snippets, timestamps, and metadata from search queries and search results.

29. The system of claim 10, wherein the agent includes a machine learning model trained on prior EHR updates and clinician-approved decisions.

30. A system comprising:(a) a first database storing electronic health records (EHRs) for a plurality of patients;(b) a second database storing data generated by a user's search; and(c) a computer system comprising one or more processors and memory storing instructions that, when executed by the one or more processors, cause the one or more processors to:(i) receive, from a user interface device, a search query initiated by a user;(ii) match the search query to one or more topics associated with clinical concepts or symptoms by analyzing internet search results obtained via a communications interface;(iii) determine, based on the matched topics and contextual information from the internet search results, whether to update one or more portions of an EHR associated with the user; and(iv) output a recommendation for updating the EHR to an agent, wherein the agent comprises at least one of an artificial intelligence module or a human operator, and wherein the update is selectively incorporated into the EHR by the agent. a) An apparatus comprising:(a) a processor subsystem configured to execute stored program instructions;(b) a memory subsystem configured to store:(i) electronic health records for a plurality of patients, and(ii) executable instructions;(c) a display device configured to present information to a user;(d) a user interface device configured to receive user input;(e) a storage device configured to store historical updates and audit logs;(f) a removable storage device configured to receive program updates or external data; and(g) a communications interface configured to retrieve internet search results in response to a user-initiated query; wherein the processor subsystem is further configured to:(i) process the user query;(ii) analyze retrieved internet data for clinical relevance;(iii) determine whether to propose updates to the EHR; and(iv) transmit the proposed update to an agent, wherein the agent may approve or deny the recommendation.