Creation and update of dynamic health profiles through natural language processing

Abstract

Disclosed herein are apparatuses (including systems) and methods to generate and update a dynamic health profile that describes the mental and / or physical state of a patient. In some examples, a system can access one or more dynamic health profiles, access a treatment protocol for a patient for treating a medical condition, generate one or more questions based on the treatment protocol, receive responses to the one or more questions, and create an updated dynamic health profile base on the received responses.

Description

CREATION AND UPDATE OF DYNAMIC HEALTH PROFILES THROUGHNATURAL LANGUAGE PROCESSINGCLAIM OF PRIORITY

[0001] This application claims priority to U.S. provisional patent application no. 63 / 674,783, titled “CREATION AND UPDATE OF DYNAMIC HEALTH PROFILES THROUGH NATURAL LANGUAGE PROCESSING,” and filed on July 23, 2024, herein incorporated by reference in its entirety.INCORPORATION BY REFERENCE

[0002] All publications and patent applications mentioned in this specification are herein incorporated by reference in their entirety to the same extent as if each individual publication or patent application was specifically and individually indicated to be incorporated by reference.FIELD

[0003] The present disclosure relates generally to dynamic heath profiles and more specifically to creating and updating dynamic health profiles through natural language processing.BACKGROUND

[0004] Traditional ways of modelling the state of a patient rely on the use of discrete items of information such as clinical biomarkers, notes about mental state, mobility, etc. When managing a patient in a typical healthcare setting, various entities are involved in updating the state of the patient. For instance, the provider could have ordered an MRI study which would be fulfilled by a radiology lab and the results would be transmitted to a radiologist for analysis or directly to the provider. Each new item of health information exists mostly in isolation. Typically the healthcare provider or a qualified member in the care team assimilates all of these disparate data points and contextualizes the results to put together an overall view of the state of the patient that can be used to influence care decisions

[0005] When a patient is in a chronic or a long term care situation, updating the state of the patient may be difficult to accomplish in an efficient manner. For instance, the patient might not be scheduled for a visit and the changes in state of the health of the patient, while marked, might not be acute enough to trigger intervention. This results in a needless deterioration of the health of the patient.

[0006] Some medical systems rely on rule-based monitoring in order to watch for changes in the state of the patient. These rules are often complex, rely on highly structured inputs, and are difficult to maintain by lay people, with the result that the providers rely on the clinical staff to manually monitor the patients in non-acute care situations.SUMMARY OF THE DISCLOSURE

[0007] Described herein are apparatuses (e.g., systems) and methods to update a dynamic health profile. A dynamic health profile (DHP) describes the mental and / or physical state of a patient with respect to a particular date and time. In general, a DHP can include objective and subjective data. Objective data can include the patient’s name, weight and other health metrics, date and time, and the like. Subjective data can include patient pain levels, perceived quality of sleep, patient comments, and the like. In this manner a DHP can provide a compact synopsis of the state of a patient.

[0008] The DHP is generated and updated through interactions with the patient and the patient’s care team using natural language processing implemented with a large language model (LLM) trained in a medical specialty. Through guided conversations, the patient is asked questions regarding his or her health. The answers to those questions are processed and used to populate the DHP. The DHP is updated over time. Analysis of multiple DHPs can show the care team patient trends.

[0009] Although the use of large language models (LLMs) show great promise in healthcare, their use presents significant challenges and risks, and it has not been straightforward to address these risks. Specifically, the use of LLMs in treating patients may have accuracy and reliability issues, such as hallucinations and misinformation. LLMs can generate plausible but factually incorrect or unsupported information, potentially leading to inaccurate diagnoses or inappropriate treatment recommendations. LLMS may also suffer from “data poisoning.” LLMs are vulnerable to bias and other problems due to “bad” data, in which misinformation or misallocated information in training data may lead to the generation of harmful content. Further, LLMs may result in inconsistent outputs, as small variations in prompts can lead to significantly different outputs, and model updates can cause further inconsistencies over time, making it difficult to rely on the results. These problems are particularly troublesome in the context of medical care.

[0010] The methods and apparatuses described herein may address these problem, and in particular, the problem hallucination and inconsistencies mentioned above. Specifically these methods and apparatuses divide each patient’s dynamic health profiles (which describe a physical and / or mental state of a patient) into separate subjective and objective sections, andfurther divide the subjective and objective sections into a hierarchy of nested subsections in each of the subjective and objective sections, thereby having a hierarchical structure. In operation the LLM is used with this nested hierarchy by dynamically updating the health profile by updating higher levels of the hierarchical structure following prescribed changes in the lower sections using a sequence of invocations to the LLM, e.g., in the context of relevant protocols. Thus, the method or system may operate under the narrowly focused objective to update individual sections (lower level section) with appropriate contexts and protocols, to allow higher level sections to be updated.

[0011] The technique described herein may therefore solve specific problems associated with the use of LLMs in patient care to dynamically update or maintain a patient’s DHP while avoiding or minimizing the effects of hallucinations and inconsistencies. The techniques described herein may be applied as part of a system for creating and maintaining dynamic health profiles. Further, by transforming the collection of patent data in the DHP into separate “hard” and “soft” (objective / subjective) sections arranged in a hierarchy having higher and lower levels, and targeting the LLM to lower levels of the resulting hierarchical structures for each, the operation of the system, including the LLM may be significantly improved. These techniques solve the prior difficulties with LLM hallucinations and inconsistent replies.

[0012] These techniques may be specific to the operation of the medical (e.g., patient treatment) DHP context, where the patient data is amenable to dividing into separate hierarchies of objection (hard) and subjective (soft) information.

[0013] In general, the methods and apparatuses described herein may be configured to transform patient information for the DHP into the separate subjective and objective hierarchies using any of the techniques described herein.

[0014] The conversations are conducted through any feasible user interface, such as but not limited to a WEB interface. The patient can access the user interface at home and in some cases through a mobile device such as a smart phone. The state of the patient can easily and frequently be updated and not limited to trips to a clinic or a doctor’s appointment.

[0015] For example, described herein are methods and apparatuses (e.g., systems) for maintaining a patient’s dynamic health profiles. For example, a system may include: one or more processors; a memory coupled to the one or more processors, the memory storing computer-program instructions, that when executed by the one or more processors, perform a computer-implemented method comprising: accessing one or more dynamic health profiles for a patient, wherein the dynamic health profiles describe a physical and / or mental state of a patient and include a subjective section and an objective section, wherein the dynamic healthprofile has one or more nested subsections in each of the subjective and objective sections, thereby having a hierarchical structure; accessing a treatment protocol for the patient, wherein the treatment protocol includes guidelines for treating a medical condition of the patient; generating one or more questions based on the treatment protocol and the one or more dynamic health profiles; displaying, on a user interface, the one or more questions; receiving responses to the one or more questions; and creating an updated dynamic health profile based on the received responses, wherein creating the update to the dynamic health profile comprises updating the hierarchical structure by updating higher levels of the hierarchical structure by changes in the lower sections using a sequence of invocations to a large language model in the context of relevant protocols; and displaying the one or more questions and the responses as a conversation on the user interface.

[0016] Any of the methods and apparatuses (e.g., systems) described herein can maintain a patient’s dynamic health profiles. Any of the systems may include also includes one or more processors; a memory coupled to the one or more processors, the memory storing computer-program instructions, that when executed by the one or more processors, perform a computer-implemented method comprising accessing one or more dynamic health profiles for a patient, where the dynamic health profiles describe a physical and / or mental state of a patient; accessing a treatment protocol for the patient, where the treatment protocol includes guidelines for treating a medical condition of the patient; generating one or more questions based on the treatment protocol and the one or more dynamic health profiles; displaying, on a user interface, the one or more questions; receiving responses to the one or more questions; and creating an updated dynamic health profile based on the received responses.

[0017] In any of the methods and apparatuses described herein, the one or more dynamic health profiles can include a subjective section and an objective section. In any of the systems described herein the one or more dynamic health profiles can include an initial dynamic health profile comprising default values.

[0018] In some examples, generating the one or more questions can include processing, with a large language model, the one or more dynamic health profiles and the treatment protocol, where the large language model is trained with respect to a medical specialty.

[0019] In general, the updated dynamic health profile is based at least in part on natural language processing of the responses to the one or more questions.

[0020] In any of the systems described herein, the one or more questions are generated by an interaction pipeline configured to perform natural language processing on at least some of the dynamic health profiles.

[0021] In some examples, the one or more questions and the responses are displayed as a conversation on the user interface.

[0022] In any of the methods and apparatuses described herein may include generating, by an analysis pipeline, a patient summary based at least in part on the dynamic health profiles of the patient. Furthermore, each of the dynamic health profiles may be associated with a particular date and time. In some examples, the systems can determine health trends based the dynamic health profiles according to particular dates and times.

[0023] Also described herein are methods for maintaining a patient’s dynamic health profiles, the method comprising: accessing one or more dynamic health profiles for a patient, wherein the dynamic health profiles describe a physical and / or mental state of a patient and include a subjective section and an objective section, wherein the dynamic health profile has one or more nested subsections in each of the subjective and objective sections, thereby having a hierarchical structure; accessing a treatment protocol for the patient, wherein the treatment protocol includes guidelines for treating a medical condition of the patient; generating one or more questions based on the treatment protocol and the one or more dynamic health profiles; displaying, on a user interface, the one or more questions; receiving responses to the one or more questions; and creating an updated dynamic health profile based on the received responses, wherein creating the update to the dynamic health profile comprises updating the hierarchical structure by updating higher levels of the hierarchical structure by changes in the lower sections using a sequence of invocations to a large language model in the context of relevant protocols; and displaying the one or more questions and the responses as a conversation on the user interface.

[0024] All of the methods and apparatuses described herein, in any combination, are herein contemplated and can be used to achieve the benefits as described herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0025] A better understanding of the features and advantages of the methods and apparatuses described herein will be obtained by reference to the following detailed description that sets forth illustrative embodiments, and the accompanying drawings of which:

[0026] FIG. l is a block diagram of a system for creating and maintaining dynamic health profiles.

[0027] FIG. 2 is a block diagram of an example dynamic health profile.

[0028] FIG. 3 is a block diagram of another example system for creating and maintaining dynamic health profiles.

[0029] FIGS. 4A-4C show examples of a user interface implementing operations for the system of FIG. 3.

[0030] FIG. 5 is a flowchart showing an example method for creating and updating patient dynamic health profiles.

[0031] FIG. 6 shows a block diagram of a device that may be one example of a device configured to implement the system of FIG. 1 and / or the system of FIG. 3.DETAILED DESCRIPTION

[0032] Described herein are systems and methods for creating and updating a dynamic health profile of a patient. A dynamic health profile (DHP) is a patient health profile that includes data reflecting the current physical and / or mental state of a patient. The DHP is dynamically updated to incorporate and / or include new and current physical and mental data as they become available from tests, examinations, as well as information provided by the patient or any other clinician. In this manner the DHP can reflect the current physical and / or mental state of the patient. As a DHP is updated, a copy of the previous DHP can be stored in a memory, including a data base, data structure, or any other feasible data storage mechanism or unit. In some examples, health or mental trends can be automatically determined through an examination of previous DHPs.

[0033] In some examples, a system for creating and maintaining DHPs can include an analysis pipeline and an interaction pipeline. The analysis pipeline can review current and previous DHPs to note physical and / or mental health trends. The interaction pipeline can drive interaction with the patient to collect patient health information.

[0034] In some examples, a DHP can be maintained with a natural language interface using a large language model (LLM) specifically trained for use with medical terminology and within a health care setting. In some examples, the analysis and / or interaction pipelines can use a natural language interface. Thus, DHPs can be easily updated and be kept current enhancing the care of the patient.

[0035] FIG. 1 is a block diagram of a system 100 for creating and maintaining DHPs. The system 100 can include a DHP processor 110, a doctor interface 130, a patient interface 140, a patient protocol module 150, and clinical data module 160. The system 100 can create, update, and / or maintain patient DHPs 120. As shown, the DHPs 120 may be separate from the system 100. In some other examples, the DHPs 120 may be included within the system 100.

[0036] The DHP processor 110 can create and maintain the DHPs 120. In general, the DHPs can include current patient data. The patient data can include objective patient datasuch as data from the patient’s Electronic Health Records (EHR), standard health metrics, and the like. The patient data can also include subjective patient data such as pain levels, and the like. In some examples, the DHPs 120 may be implemented with data structures that include a “hard” section (also referred to as an objective section) for the objective data and a “soft” section (also referred to a subjective section) for the subjective data. The structure and contents of the DHPs 120 is described in more detail below in conjunction with FIG. 2. The data included in the DHPs 120 can describe a physical and / or mental state of the patient.

[0037] The doctor interface 130 can include one or more modules that can interact with a doctor or other clinical staff to enter or collect patient information to be included in the DHPs 120. The patient interface 140 includes one or more modules that can interact with the patient to collect patient information including objective and subjective patient information.

[0038] In some examples, the patient interface 140 initiates conversations with a patient based on the triggers generated by updates to a DHP 120 and / or interaction with the care team through the doctor interface 130. The interactions can have multiple objectives, viz., obtaining direct statements from the patient, indirectly observing the patient’s movement patterns, tone of voice, etc.

[0039] The DHP processor 110 may include an LLM that implements a natural language interface. In some examples, the doctor interface 130 can use the LLM to interact with doctors and other members of the care team to collect inputs or direction.. In a similar manner, the patient interface 140 can use the LLM to interact with one or more patients to collect patient data.

[0040] The patient protocol module 150 includes treatment protocols for the treatment of any feasible patient, particularly patients represented by the DHPs 120. For example, if a patient has high blood pressure, then the patient protocols may include one or more methods to treat high blood pressure.

[0041] The clinical data module 160 can include clinical and / or test data associated with a patient. The clinical and / or test data can include vital sign data as well as test data from MRIs, X-rays, lab results, or the like.

[0042] The DHP processor 110 can create, populate, and update the DHPs 120 through the doctor interface 130, the patient interface 140, using information from the patient protocol module 150 and clinical data module 160.

[0043] FIG. 2 is a block diagram of an example DHP 200. In some examples, the DHP 200 can be implemented as a JavaScript Object Notation (JSON) file, although other files and formats are contemplated. Entries into the DHP 200 can be structured as “key / value” pairs. The “key” can be a label that is used to describe a data element (e.g., the “value”). The DHP200 can include a hard section 210 and a soft section 220. The hard section 210 can include objective patient data such as patient’s name, time and date of last surgery, current time (a particular time and date that the DHP 200 was created), and the like. In some examples, the hard section 210 can include standard health metrics or test data contained within patient medical records, or the like. The soft section 220 can include subjective patient information such as pain level, sleep quality, overall comments and the like. The soft section 220 can include a list of data elements which require some form of subjective analysis and interpretation.

[0044] Generally, DHP information may be determined from conversation histories, DHP-relevant documents, software layer information and previous DHPs related to a patient. Conversation histories may be related to conversations or “chats” between the DHP processor 110 and a patient through the patient interface 140 as shown in FIG. 1. Data from earlier DHPs 230 can be used to determine trends. In some cases, earlier DHPs 230 may be identified through date and time information included within the respective DHPs. For example, trends in patient pain, sleep, vital signs, and the like can be determined with an examination of one or more earlier DHPs 230. The hard section 210 of the dynamic health profile may be updated through an interface with an electronic health record system (EHR). The interface can be configured to receive pertinent updates from the EHR or be configured to poll the EHR and fetch updates to the patient’s health record.

[0045] When a DHP is created, some values may be unknown and set to a default value. In some examples, the default values in the hard section 210 may be set to “null.” The initial values corresponding to the keys in the soft section 220 are not required to be null but could be reasonable default values based on a preference / expectation of the care team. In some examples, the soft section 220 is recursive in nature with the lower-level elements contributing to the state of the elements above it. For instance, a lower level element representing the ‘range of movement progress’ updates the higher level node ‘physical therapy progress’, which in turn updates a higher level node, ‘patient status.’

[0046] An example DHP in an initial state is shown below:“State”: { "hard": { "Patient Name" : null, "Surgery Area": null, "Patient's most recent message to you": null,Time of most recent conversation" : null,"Surgery Time": null},"soft": “"Pain Level:ModerateSleep Quality:ModerateTrending: StableOverall Comments:- Patient is recovering from surgery- Experiencing sleep disturbances- Experiencing painRecent Comments:- The patient reported having a lot of trouble sleeping, which is causing a dull pain.- The patient asked how to use the sling"DHP (0)

[0047] As mentioned, the methods and apparatuses described herein may be configured to transform patient information for the DHP into the separate subjective and objective hierarchies using any of the techniques described herein. FIG. 2, discussed above may indicate one example of a technique for transforming this patient information into separate hard and soft hierarchies, which may then be acted upon and modified by these techniques, e.g., judiciously using one or more LLMs in a manner that may avoid problems that may otherwise impair existing LLM-based technologies.

[0048] FIG. 3 is a block diagram of another example system 300 for creating and maintaining DHPs. The system 300 can include a DHP processor 310, electronic health records (EHRs) 350 and an interaction log 360. The system 300 can interact with a patient380 and one or more members of a care team 390.

[0049] The DHP processor 310 can include an analysis pipeline 320, an interaction pipeline 330, one or more DHPs 340, and treatment protocols 370. The DHP processor 310 can create and maintain the one or more DHPs 340. The analysis pipeline 320 can traverse the DHPs 340 and analyze data and trends contained within the DHPs 340. The analysis pipeline 320 can include or access an LLM that uses natural language to analyze the interactions log 360, data from the patient’s EHRs 350 and treatment protocols 370 to update the DHPs 340. In some other examples, members of the care team 390 can direct the analysis pipeline 320 to summarize and / or extract data from the DHPs 340 using natural language. The system stores the literal transcript of the interaction in a database along with the associated timestamps.

[0050] The interaction pipeline 330 can be used to interact with a patient 380, collect patient data and responses, and update the DHPs 340. The interaction pipeline 330 can include or access an LLM that uses natural language to interact with the patient 380 to collect patient data. In some examples, the interaction pipeline 330 can include a chatbot configured to interact with the patient 380 and guide the patient 380 to answer particular questions as well as gather information regarding the patient’s current state (sleep patterns, pain levels, and the like). Thus, the interaction pipeline 330 can receive patient responses to questions or prompts.

[0051] Furthermore, the system instructs an LLM to summarize the interaction from the transcript and the information in the dynamic health profile. The system invokes the LLM multiple times, supplies the transcript and individual sections of the subjective part of the dynamic health profile, and instructs the LLM to generate updates to individual response

[0052] The interactions with the patient 380 can be given context by the DHP processor 310 based on an analysis performed by the analysis pipeline 320. For example, the analysis might indicate that the patient’s overall progress is of concern to the care team 390 and the interaction pipeline 330 establishes user-facing prompts, questions, and greetings, to reflect the concern. The treatment protocols 370 may include directives and / or instructions for treating a patient’s medical condition. The treatment protocols 370 defined by the care team 390 are used to drive messages presented to the patient. For instance, the treatment protocols 370 specified by the care team 390 might stipulate that worsening pain a week after a surgery would be cause for direct intervention from the care team 390. The interaction pipeline 330 communicates with the patient based on a synthesis of the treatment protocols 370 and the patient’s status.

[0053] In some examples, current and previous versions of a patient’s DHP may be processed by an ancillary LLM to determine changes between different DHPs. In someexamples, the ancillary LLM can be instructed to generate follow-up questions based on perceived changes in the DHP and also based on the treatment protocols 370.

[0054] When a user interacts with the system 300 for the first time as a part of a given episode of care, the system 300 uses a predetermined set of greetings based on the patient’s indications as described in the EHRs 350 to generate an initial DHP. Once the system 300 has determined the patient’s initial DHP, the system 300 maintains a continuity of interactions by generating subsequent greetings and prompts based on an existing DHP. The treatment protocols 370 defined by the care team 390 are also used to start the conversations with the patient 380. For instance, the treatment protocols 370 could indicate that the DHP Processor 310 should watch for changes in sleep patterns. The prompts generated by the LLM can be influenced by these configurations. The care team 390 can also send direct messages to the interaction pipeline 330 in response to any changes in the DHP 340. The system 300 can update the planned greeting messages to prioritize the messages from the care team 390.

[0055] In some cases, the analysis pipeline 320 and the interactive pipeline 330 can work cooperatively to update the DHP 340. For example, analysis from the analysis pipeline 320 might indicate that the patient’s overall progress is of concern to the care team 390 and the interaction pipeline 330 can establish user-facing (patient-facing) prompts, questions, and greetings, to reflect the concern. The treatment protocols 370 defined by the care team 390 can be used to drive these messages. For instance, the treatment protocols 370 specified by the care team might stipulate that worsening pain a week after a surgery would be cause for direct intervention from the care team 390. The interaction pipeline 330 can communicate with the patient 380 based on a synthesis of the treatment protocols 370 and the patient’s status.

[0056] In general terms, the soft section of the DHP 340 is a consolidated view of a patient’s clinical and non-clinical health data. The system 300 can use an LLM, suitably trained in a particular medical specialty, to create a summary of the patient clinical and / or non-clinical health data for the care team 390.

[0057] The system 300 can use a structured form of prompting to force an LLM to respond with an appropriate level of completeness. Since the DHP processor 310 is expected to handle patients under a wide variety of circumstances, and since the patients’ clinical histories might be significantly different, the patients’ internal state might need to surface specific aspects unique to their situation. Consequently, generating a summary to update the soft section of the DHP 340 cannot be accomplished by an arbitrary set of prompts.

[0058] In order to handle this variability the LLM is invoked multiple times with narrowly focused objective to update individual sections with appropriate contexts andprotocols. The prompt generator can use a template provided by the care team 390 to help structure the response of the LLM. In some cases, the response might have to include an image or a video clip or might trigger a call to the EHR. The system uses a special purpose ancillary LLMs to decide the appropriate modality of the response. The response of the prompt generator, i.e., the specialized prompt is supplied to the primary LLM along with clinical and non-clinical observations recorded by the associated health database, such as an electronic medical record system. The state, i.e., the DHP from the previous session DHPn-1 is also supplied to the primary LLM. The primary LLM is also instructed of its role, akin to a medical assistant summarizing the findings for a provider, and is further instructed to use the history of the conversation with the patient. This forces the primary LLM’s response to maintain continuity from one interaction to another and permit trends to emerge.

[0059] Instructions, prompts, to the primary LLM are divided into sections, reflecting the keys in the internal state of the DHP. Each section has instructions on how the state corresponding to the key is to be updated.

[0060] FIGS. 4A-4C show examples of a user interface implementing operations for the system 300 of FIG. 3. The operations performed with the user interface of FIGS. 4A-4C can update the DHP (0) shown above in conjunction with FIG. 2. In some examples, the hard section of DHP (0) is updated with the patient’s name and surgery area. The system 300 can use the analysis pipeline 320 and / or the interaction pipeline 330 to interact with the patient using a natural language user interface as shown in FIG. 4 A. The system 300 may use an LLM to provide prompting texts to a user and process responses to update a DHP. In the example of FIG. 4A, prompting texts are shown on the left side of the user interface and user responses are shown on the right side. Thus, FIG. 4A shows a “conversation” between the patient and the system 300. The prompting texts may be determined from inputs from the analysis pipeline 320, the interaction pipeline 330, the interaction log 360 and the treatment protocols 370. Based on the interactions shown on the user interface 4A, the DHP (0) can be updated to a patient’s current state as shown in DHP (1) below:“State”: {"hard": {"Patient Name" : "Jane Doe","Surgery Area": "Left Shoulder","Patient's most recent message to you": "The pain is not bad apart from a few days when I sleep in a weird position. I will take your advice and am going to sleep soon.", "Time of most recent conversation": "2024-06-27 14:50: 15.869781","Surgery Time": "2023-10-05 10:47:00"},"soft":"Pain Level:GoodSleep Quality:ModerateTrending:ImprovingOverall Comments:- Patient is recovering from surgery- Experiencing sleep disturbances- Experiencing painRecent Comments:- The patient mentioned that the pain is not bad except when sleeping in an uncomfortable position.- The patient was advised on how to sleep properly to avoid pain, such as not sleeping on the operated shoulder and using pillows for support."}DHP (1)

[0061] In some examples, the system 300 can provide a patient progress summary based on DHP (1). For example, a doctor facing interface (such as the doctor interface 130 of FIG.1) can analyze patient DHPs with the analysis pipeline 320 and provide a summary of patient care. An example summary of patient care for one or more members of the care team based on patient DHPs up to and including DHP (1) is shown below:Surgery:Performed on October 5th, 2023.- Left shoulder Subacromial Space Release (SSR), labral debridement, and biceps tenodesis.Functional Recovery:- As of the last PT note on February 9th, 2024, the patient's shoulder strength has improved, with no noticeable strength deficits in daily activities. The patient still has some difficulty reaching behind the back but has shown improvement.Patient Compliance:- The patient has been compliant with the prescribed weight-bearing status and use of the sling as per the clinic visit note on November 14th, 2023. Medication adherence is confirmed as taking as directed, and the patient has been attending physical therapy sessions regularly.KalCompanion Progress:- The patient reports good pain quality, moderate sleep quality, and was inquiring about how to sleep comfortably.Previous 'Next Steps':- Continue prescribed physical therapy.- Follow-up with the surgeon for ongoing assessment and to address any concerns or questions regarding recovery.- Gradual return to activities as strength and range of motion improve, with specific attention to any limitations or precautions advised by the physical therapist or surgeon.

[0062] FIG. 4B shows an example follow-up conversation between the patient and the system 300. Based on the conversation of FIG. 4B, DHP (1) can be updated to DHP (2), as shown below.“State”: {"hard": {"Patient Name" : "Jane Doe","Surgery Area": "Left Shoulder","Patient's most recent message to you": "My sleep has been a lot better. But today my pain is a lot worse. My prescribed pain medicine does not seem to be working. What are my medication guidelines?","Time of most recent conversation": "2024-06-28 14:50: 15.869781","Surgery Time": "2023-10-05 10:47:00"},"soft":"Pain Level:BadSleep Quality:GoodTrending:Worsening (in terms of pain)Overall Comments:- Patient is recovering from surgery- Experiencing sleep disturbances- Experiencing painRecent Comments:- The patient reported that their sleep quality has improved.- Today, the patient is experiencing worse pain, and their prescribed pain medication does not seem to be effective.- The patient was reminded of their medication guidelines and advised to consult with their surgeon if pain persists or worsens."}

[0063] FIG. 4C shows another follow-up conversation between the patient and the system 300. As indicated, the system initiates the context based on the previous states of the DHP. The patient’s response is used to update all pertinent sections. In some cases, changes in states of updates to trends will be communicated with the care team. The system 300 can provide a patient progress summary based on DHP (2). For example the doctor facing interface can analyze patient DHPs with the analysis pipeline 320 and provide a summary ofpatient care. An example summary of patient progress for one or more members of the care team based on patient DHPs up to and including DHP (2) is shown below:Surgery:Performed on October 5th, 2023.- Left shoulder Subacromial Space Release (SSR), labral debridement, and biceps tenodesis.Functional Recovery:- As of the last PT note on February 9th, 2024, the patient's shoulder strength has improved, with no noticeable strength deficits in daily activities. The patient still has some difficulty reaching behind the back but has shown improvement.Patient Compliance:- The patient has been compliant with the prescribed weight-bearing status and use of the sling as per the clinic visit note on November 14th, 2023. Medication adherence is confirmed as taking as directed, and the patient has been attending physical therapy sessions regularly.KalCompanion Progress:- The patient reports bad pain quality, good sleep quality.- Pain medicine reported to be ineffective, but compliance to medication instructions not reportedPrevious 'Next Steps':- Continue prescribed physical therapy.- Follow-up with the surgeon for ongoing assessment and to address any concerns or questions regarding recovery.- Gradual return to activities as strength and range of motion improve, with specific attention to any limitations or precautions advised by the physical therapist or surgeon

[0064] FIG. 5 is a flowchart showing an example method 500 for creating and updating patient DHPs. Some examples may perform the operations described herein with additional operations, fewer operations, operations in a different order, operations in parallel, and someoperations differently. The method 500 is described below with respect to the system 300 of FIG. 3, however, the method 500 may be performed by any other suitable system or device.

[0065] The method 500 begins in block 502 as the system 300 accesses EHRs 350. For example, the system 300 can access one or more electronic health records for one or more patients. The electronic heath records may include patient information including patient name, dates of any surgical procedure, type of surgery, area of surgery and the like.

[0066] Next, in block 504 the system 300 generates an initial DHP. For example, the system 300 may use information from a patient’s electronic health records to populate key and value fields of a patient’s dynamic health profile. In some examples, the initial DHP may include key and values as described above with respect to FIG. 2

[0067] Next, in block 506, the system accesses all available DHPs for a patient. In cases where only an initial DHP exists, the system 300 accesses the initial DHP. On the other hand, in cases where several DHPs exist for a patient (for example, a patient’s previous DHPs are available), then the system 300 accesses all the DHPs for a patient.

[0068] Next, in block 508 the system 300 accesses treatment protocols for the patient. For example, one or more clinicians in the care team 390 may have provided the system 300 treatment protocols 370 for procedures that the patient 380 may have undergone. Thus, the system 300 can access these treatment protocols 370.

[0069] Next, in block 510 the system 300 updates the patient’s DHP using the interaction pipeline 330. For example, the system 300 can communicate with the patient using an LLM and a natural language user interface. In some examples, the system 300 can interact with the patient as shown in FIGS. 4A-4C above. The interaction pipeline 330 can interact with the patient based on the patient’s DHPs 340, treatment protocols 370, and information in the interaction log 360. After interacting with the patient, the system 300 updates the patient’s DHP, and the method 500 returns to block 506.

[0070] Returning to block 506, the method 500 can proceed to block 512 (instead of to block 510) where the system 300 analyzes the patient’s DHPs using the analysis pipeline 320. For example, the analysis pipeline 320 can review patient DHPs 340, treatment protocols 370, and interaction log 360 and generate a patient summary. The method 500 returns to block 506.

[0071] FIG. 6 shows a block diagram of a device 600 that may be one example of a device configured to implement the system 100 of FIG. 1 and / or the system 300 of FIG. 3. The device 600 may include a communication interface 620, a processor 630, and a memory 640.

[0072] The communication interface 620, which may be coupled to a network (such as network 610) and to the processor 630, may transmit signals to and receive signals from other wired or wireless devices, including remote (e.g., cloud-based) storage devices, cameras, processors, compute nodes, processing nodes, computers, mobile devices (e.g., cellular phones, tablet computers and the like) and / or displays. For example, the communication interface 620 may include wired (e.g., serial, ethernet, or the like) and / or wireless (Bluetooth, Wi-Fi, cellular, or the like) transceivers that may communicate with any other feasible device through any feasible network. In some examples, the communication interface 620 may receive previous patient information, patient test results (lab results, CAT scan information, MRI information, and the like), health treatment protocols, etc.

[0073] The processor 630, which is coupled to the communication interface 620, and the memory 640, may be any one or more suitable processors capable of executing scripts or instructions of one or more software programs stored in the device 600 (such as within memory 640).

[0074] The memory 640 may include a DHP database 642 that may be used to locally store DHPs for one or more patients. In some examples, the DHP database 642 may include health profiles in a JSON format that includes subjective and objective patient data. In some examples, the patient data may be represented as key / value pairs.

[0075] The system uses a special purpose ancillary LLM to format the output in the form of a JSON object which is stored

[0076] The memory 640 may include treatment protocols 643. The treatment protocols 643 may include health care instructions and directives directed to the care of a particular patient. In some examples, the treatment protocols 643 may be provided by qualified members on the care team 390.

[0077] The memory 640 may also include a non-transitory computer-readable storage medium (e.g., one or more nonvolatile memory elements, such as EPROM, EEPROM, Flash memory, a hard drive, etc.) that may store the following software modules:• an LLM 644 to process DHP data and treatment protocol data with a learning model trained to perform natural language processing;• an interaction pipeline module 646 configured to interact with a user through a user interface 615;an analysis pipeline module 647 configured to analyze DHPs stored in the DHP database 642; a DHP update module 648 configured to generate an updated DHP; and• a communication module 649 to communicate via the communication interface 620.Each software module includes program instructions that, when executed by the processor 630, may cause the device 600 to perform the corresponding function(s). Thus, the non- transitory computer-readable storage medium of memory 640 may include instructions for performing all or a portion of the operations described herein.

[0078] The processor 630 may execute the LLM 644 to process data and provide a user interface using natural language processing. For example, execution of the LLM 644 can process patient data within one or more DHPs and treatment protocols to determine questions for the patient. Execution of the LLM 644 can process data entered by the patient in the user interface 615 and determine elements for an updated DHP.

[0079] The processor 630 may execute the interaction pipeline module 646 to interact with the patient and / or medical staff through the user interface 615. For example, execution of the interaction pipeline module 646 may cause the processor 630 to analyze the DHP database 642 and / or the treatment protocols 643 and determine questions and / or prompts to ask the patient through the user interface 615. In some cases, execution of the interaction pipeline module 646 can execute the LLM 644 to generate the questions and prompts and also analyze any responses from the patient.

[0080] The processor 630 may execute the analysis pipeline module 647 to analyze DHPs stored in the DHP database 642. In some cases, execution of the analysis pipeline module 647 can execute the large language model 644 to assist in the analysis of the DHPs. Execution of the analysis pipeline module 647 can generate a patient summary report as described herein.

[0081] The processor 630 may execute the DHP update module 648 to update or generate a DHP based on patient input through the user interface 615. In some cases, execution of the DHP update module 648 may cause the execution of the large language model 644 to assist in the processing of data through the user interface 615.

[0082] The processor 630 may execute the communication SW module 649 to communicate with any other feasible devices. For example, execution of the communication SW module 649 may enable the device 600 to communicate via cellular networksconforming to any of the LTE standards promulgated by the 3rdGeneration Partnership Project (3GPP) working group, Wi-Fi networks conforming to any of the IEEE 802.11 standards, Bluetooth protocols put forth by the Bluetooth Special Interest Group (SIG), Ethernet protocols, or the like. In some embodiments, execution of the communication SW module 649 may enable the device 600 to communicate with the user interface 615 and / or other systems (not shown). In some other embodiments, execution of the communication SW module 649 may implement encryption and / or decryption procedures.

[0083] In some examples, the procedures and systems described herein can be extended beyond simply generating and updating DHPs. For example, instead of monitoring the state of a patient, the state or status of any feasible entity can be monitored. That is, two LLM- based pipelines (one to interact with a user directly and one to analyze logs or other data sources) may be used to monitor the entity and also provide a summary of the state of the entity. The apparatuses described herein provide a framework for the manner in which a DxP, a generalized implementation of a DHP, can be configured and updated. Unlike traditional rule-based systems, the linguistic basis for controlling the behavior of a DxP processor provides greater flexibility and ease of use. Examples of DxP in other domains include a learning management system.

[0084] It should be appreciated that all combinations of the foregoing concepts and additional concepts discussed in greater detail below (provided such concepts are not mutually inconsistent) are contemplated as being part of the inventive subject matter disclosed herein and may be used to achieve the benefits described herein.

[0085] The process parameters and sequence of steps described and / or illustrated herein are given by way of example only and can be varied as desired. For example, while the steps illustrated and / or described herein may be shown or discussed in a particular order, these steps do not necessarily need to be performed in the order illustrated or discussed. The various example methods described and / or illustrated herein may also omit one or more of the steps described or illustrated herein or include additional steps in addition to those disclosed.

[0086] Any of the methods (including user interfaces) described herein may be implemented as software, hardware or firmware, and may be described as a non-transitory computer-readable storage medium storing a set of instructions capable of being executed by a processor (e.g., computer, tablet, smartphone, etc.), that when executed by the processor causes the processor to control perform any of the steps, including but not limited to: displaying, communicating with the user, analyzing, modifying parameters (including timing, frequency, intensity, etc.), determining, alerting, or the like. For example, any of the methodsdescribed herein may be performed, at least in part, by an apparatus including one or more processors having a memory storing a non-transitory computer-readable storage medium storing a set of instructions for the processes(s) of the method.

[0087] While various embodiments have been described and / or illustrated herein in the context of fully functional computing systems, one or more of these example embodiments may be distributed as a program product in a variety of forms, regardless of the particular type of computer-readable media used to actually carry out the distribution. The embodiments disclosed herein may also be implemented using software modules that perform certain tasks. These software modules may include script, batch, or other executable files that may be stored on a computer-readable storage medium or in a computing system. In some embodiments, these software modules may configure a computing system to perform one or more of the example embodiments disclosed herein.

[0088] As described herein, the computing devices and systems described and / or illustrated herein broadly represent any type or form of computing device or system capable of executing computer-readable instructions, such as those contained within the modules described herein. In their most basic configuration, these computing device(s) may each comprise at least one memory device and at least one physical processor.

[0089] The term “memory” or “memory device,” as used herein, generally represents any type or form of volatile or non-volatile storage device or medium capable of storing data and / or computer-readable instructions. In one example, a memory device may store, load, and / or maintain one or more of the modules described herein. Examples of memory devices comprise, without limitation, Random Access Memory (RAM), Read Only Memory (ROM), flash memory, Hard Disk Drives (HDDs), Solid-State Drives (SSDs), optical disk drives, caches, variations or combinations of one or more of the same, or any other suitable storage memory.

[0090] In addition, the term “processor” or “physical processor,” as used herein, generally refers to any type or form of hardware-implemented processing unit capable of interpreting and / or executing computer-readable instructions. In one example, a physical processor may access and / or modify one or more modules stored in the above-described memory device. Examples of physical processors comprise, without limitation, microprocessors, microcontrollers, Central Processing Units (CPUs), Field-Programmable Gate Arrays (FPGAs) that implement softcore processors, Application-Specific Integrated Circuits (ASICs), portions of one or more of the same, variations or combinations of one or more of the same, or any other suitable physical processor.

[0091] Although illustrated as separate elements, the method steps described and / or illustrated herein may represent portions of a single application. In addition, in some embodiments one or more of these steps may represent or correspond to one or more software applications or programs that, when executed by a computing device, may cause the computing device to perform one or more tasks, such as the method step.

[0092] In addition, one or more of the devices described herein may transform data, physical devices, and / or representations of physical devices from one form to another. Additionally or alternatively, one or more of the modules recited herein may transform a processor, volatile memory, non-volatile memory, and / or any other portion of a physical computing device from one form of computing device to another form of computing device by executing on the computing device, storing data on the computing device, and / or otherwise interacting with the computing device.

[0093] The term “computer-readable medium,” as used herein, generally refers to any form of device, carrier, or medium capable of storing or carrying computer-readable instructions. Examples of computer-readable media comprise, without limitation, transmission-type media, such as carrier waves, and non-transitory-type media, such as magnetic-storage media (e.g., hard disk drives, tape drives, and floppy disks), optical-storage media (e.g., Compact Disks (CDs), Digital Video Disks (DVDs), and BLU-RAY disks), electronic-storage media (e.g., solid-state drives and flash media), and other distribution systems.

[0094] A person of ordinary skill in the art will recognize that any process or method disclosed herein can be modified in many ways. The process parameters and sequence of the steps described and / or illustrated herein are given by way of example only and can be varied as desired. For example, while the steps illustrated and / or described herein may be shown or discussed in a particular order, these steps do not necessarily need to be performed in the order illustrated or discussed.

[0095] The various exemplary methods described and / or illustrated herein may also omit one or more of the steps described or illustrated herein or comprise additional steps in addition to those disclosed. Further, a step of any method as disclosed herein can be combined with any one or more steps of any other method as disclosed herein.

[0096] The processor as described herein can be configured to perform one or more steps of any method disclosed herein. Alternatively or in combination, the processor can be configured to combine one or more steps of one or more methods as disclosed herein.

[0097] Terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. For example, as used herein, thesingular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items and may be abbreviated as " / ".

[0098] Although the terms “first” and “second” may be used herein to describe various features / elements (including steps), these features / elements should not be limited by these terms, unless the context indicates otherwise. These terms may be used to distinguish one feature / element from another feature / element. Thus, a first feature / element discussed below could be termed a second feature / element, and similarly, a second feature / element discussed below could be termed a first feature / element without departing from the teachings of the present invention.

[0099] Throughout this specification and the claims which follow, unless the context requires otherwise, the word “comprise”, and variations such as “comprises” and “comprising” means various components can be co-jointly employed in the methods and articles (e.g., compositions and apparatuses including device and methods). For example, the term “comprising” will be understood to imply the inclusion of any stated elements or steps but not the exclusion of any other elements or steps.

[0100] In general, any of the apparatuses and methods described herein should be understood to be inclusive, but all or a sub-set of the components and / or steps may alternatively be exclusive, and may be expressed as “consisting of’ or alternatively “consisting essentially of’ the various components, steps, sub-components or sub-steps.

[0101] Although various illustrative embodiments are described above, any of a number of changes may be made to various embodiments without departing from the scope of the invention as described by the claims. For example, the order in which various described method steps are performed may often be changed in alternative embodiments, and in other alternative embodiments one or more method steps may be skipped altogether. Optional features of various device and system embodiments may be included in some embodiments and not in others. Therefore, the foregoing description is provided primarily for exemplary purposes and should not be interpreted to limit the scope of the invention as it is set forth in the claims.

[0102] The examples and illustrations included herein show, by way of illustration and not of limitation, specific embodiments in which the subject matter may be practiced. Asmentioned, other embodiments may be utilized and derived there from, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. Such embodiments of the inventive subject matter may be referred to herein individually or collectively by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept, if more than one is, in fact, disclosed. Thus, although specific embodiments have been illustrated and described herein, any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

Claims

CLAIMSWhat is claimed is:

1. A system for maintaining a patient’s dynamic health profiles, the system comprising: one or more processors; a memory coupled to the one or more processors, the memory storing computerprogram instructions, that when executed by the one or more processors, perform a computer-implemented method comprising: accessing one or more dynamic health profiles for a patient, wherein the dynamic health profiles describe a physical and / or mental state of a patient and include a subjective section and an objective section, wherein the dynamic health profile has one or more nested subsections in each of the subjective and objective sections, thereby having a hierarchical structure; accessing a treatment protocol for the patient, wherein the treatment protocol includes guidelines for treating a medical condition of the patient; generating one or more questions based on the treatment protocol and the one or more dynamic health profiles; displaying, on a user interface, the one or more questions; receiving responses to the one or more questions; and creating an updated dynamic health profile based on the received responses, wherein creating the update to the dynamic health profile comprises updating the hierarchical structure by updating higher levels of the hierarchical structure by changes in the lower sections using a sequence of invocations to a large language model in the context of relevant protocols; and displaying the one or more questions and the responses as a conversation on the user interface.

2. The system of claim 1, wherein a first set of invocations summarize the objective findings using the supplied protocol, a second set of invocations create a higher-level summary in a context of historical value of this subjective finding and / or objective / subjective information from other sections in the hierarchy.

3. The system of claim 1, wherein the one or more dynamic health profiles include an initial dynamic health profile comprising default values.

4. The system of claim 1, wherein generating the one or more questions comprises: processing, with the large language model (LLM), the one or more dynamic health profiles and the treatment protocol, wherein the large language model is trained with respect to a medical specialty.

5. The system of claim 4, wherein the LLM is instructed to generate a question given a section of the dynamic health profile and one or more of the protocols.

6. The system of claim 5, wherein the LLM is further instructed to assume the persona of a healthcare provider in generating the question.

7. The system of claim 5, wherein the LLM is provided with a history of interaction summaries and is asked to generate the question, thereby ensuring that the questions have connections to prior conversations and pursue unresolved issues.

8. The system of claim 1, wherein the updated dynamic health profile is based at least in part on natural language processing of the responses to the one or more questions.

9. The system of claim 4, wherein the LLM is instructed to provide a summary of interactions with the patient.

10. The system of claim 4, wherein the LLM is instructed to generate summaries for specific topics, represented in the subjective section of the dynamic health profile.

11. The system of claim 1, wherein the system initiates a hierarchical update of the dynamic health profile at the end of each interaction.

12. The system of claim 1, wherein the one or more questions are generated by an interaction pipeline configured to perform natural language processing on at least some of the dynamic health profiles.

13. The system of claim 1, further comprising: generating, by an analysis pipeline, a patient summary based at least in part on the dynamic health profiles of the patient.

14. The system of claim 1, wherein each of the dynamic health profiles is associated with a particular date and time.

15. The system of claim 14, further comprising determining health trends based the dynamic health profiles according to particular dates and times.

16. The system of claim 4, wherein the LLM is provided with dynamic health profile history and the protocols and is instructed to generate trends.

17. A method for maintaining a patient’s dynamic health profiles, the method comprising: accessing one or more dynamic health profiles for a patient, wherein the dynamic health profiles describe a physical and / or mental state of a patient and include a subjective section and an objective section, wherein the dynamic health profile has one or more nested subsections in each of the subjective and objective sections, thereby having a hierarchical structure; accessing a treatment protocol for the patient, wherein the treatment protocol includes guidelines for treating a medical condition of the patient; generating one or more questions based on the treatment protocol and the one or more dynamic health profiles; displaying, on a user interface, the one or more questions; receiving responses to the one or more questions; and creating an updated dynamic health profile based on the received responses, wherein creating the update to the dynamic health profile comprises updating the hierarchical structure by updating higher levels of the hierarchical structure by changes in the lower sections using a sequence of invocations to a large language model in the context of relevant protocols; and displaying the one or more questions and the responses as a conversation on the user interface.

Images