Predicting billing information for telehealth communications

Abstract

A method is provided that includes receiving a patient message, audit log data, and a provider response message. The secure message and the secure response message are part of a message thread stored in association with the audit log data. The method further includes determining message complexity indicators that characterize a clinical complexity level of the patient message. The method further includes determining provider engagement metrics that quantify engagement of a healthcare provider in responding to the patient message. The method further includes determining a billing eligibility score for the message thread by using a machine learning model to process the message complexity indicators and the provider engagement metrics. The method further includes determining recommended billing information for the message thread based on the billing eligibility score. The method further includes causing the recommended billing information to be made accessible via a provider portal of a healthcare system.

Description

Docket No. UOC-25006WOSYSTEMS AND METHODS FOR PREDICTING BILLING INFORMATION FOR TELEHEALTH COMMUNICATIONSRELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application Serial No. 63 / 695,323 filed September 9, 2025, entitled “Telehealth Secure Messaging Billing Model,” the contents of which is hereby incorporated herein by reference, in its entirety.FIELD OF THE INVENTION

[0002] The present invention relates to systems and methods for predictive billing in telehealth communications, and more particularly, to computer-implemented techniques that analyze message content and provider engagement using machine learning to generate billing eligibility scores and recommended billing information for asynchronous patient-provider message encounters.BACKGROUND

[0003] Secure messaging (SM) telehealth services, also referred to as E-Visit Messages, is a patient portal feature for communicating discreetly, privately, and asynchronously non-urgent medical questions with a patient’ s care team. These services have become a routine feature of patient portals and are increasingly embedded into standard clinical workflows. However, as these services are embedded into routine care, the longstanding expectation of free access is fading, leading to a shift toward a fee-for- service model in response to the increased frequency and expanded use of E-Visit Messages. Within this model, time-based billing is proving to be insufficient and unsustainable, failing to reflect the complexity of the clinical workload required to manage patient-initiated messages.

[0004] The limitations of time-based billing are particularly evident in asynchronous care. Brief messages involving serious conditions may require extensive clinical judgment and review of electronic health record (EHR) data, while lengthy but routine messages may require little cognitive effort. Relying only on elapsed time does not capture these distinctions and leads to mismatched reimbursement. This mismatch contributes to underbilling (e.g., missed opportunities to bill for clinically complex encounters) and overbilling (e.g., inappropriateDocket No. UOC-25006WO charges for routine interactions). Recent studies show that fewer than 5% of eligible e- visits are billed, with underfilling far outpacing ovcrbilling, resulting in substantial lost revenue and operational inefficiency.

[0005] Behavioral and operational factors can accentuate this problem. Clinicians managing high volumes of asynchronous work often face cognitive overload. The bounded attention theory suggests that when a clinician is working on a large volume of smaller tasks, the ability of a medical provider to devote thought to each task diminishes. This can result in tasks such as billing being overlooked. Under these conditions, medical providers tend to focus on delivering clinical responses while omitting administrative steps, even when billing would be appropriate. Conversely, in routine cases, billing errors may arise from habitual or inconsistent application of billing guidelines.

[0006] The challenge is further complicated by the rise of artificial intelligence tools which streamline routine tasks such as drafting responses or triaging inquiries. Although these tools may reduce the time spent per message, they do not diminish the underlying clinical expertise or decision-making required. In fact, oversight of Al-generated content may add to responsibility of medical providers and may increase costs. As such, time-based billing models are becoming increasingly misaligned with the realities of asynchronous digital care.

[0007] Accordingly, there is a need for a system and method that more accurately reflects the complexity of telehealth encounters, such as by analyzing both patient message content and provider engagement with healthcare information systems. The solution should account for cognitive workload and clinical decision-making efforts while also enabling transparent and fair billing determinations.SUMMARY

[0008] In an aspect of the invention, a computer-implemented method for determining billing recommendations for services provided in relation to telehealth communications is provided.The method includes receiving, by a server, a secure message provided by an account of a user through a patient portal of a healthcare records and messaging system. The secure message contains information about a health-related inquiry of the user. The secure message is made accessible to a provider portal of the healthcare records and messaging system. The method further includes receiving, by the server, audit log data including at least one of: system interaction data describing one or more interactions of at least one provider with the healthcareDocket No. UOC-25006WO records and messaging system, and task data describing one or more tasks performed by the at least one healthcare provider in response to the secure message. The method further includes receiving, by the server, a secure response message provided via the provider portal of the healthcare records and messaging system. The secure message and the secure response message are part of a message thread that is stored in association with the audit log data.

[0009] The method further includes determining, by the server, one or more message complexity indicators that characterize a clinical complexity level of the secure message based on a semantic or contextual analysis of content included in the secure message. The method further includes determining, by the server and by processing the audit log data and the secure response message, one or more provider engagement metrics that quantify a level of engagement of the at least one healthcare provider in responding to the secure message. The method further includes determining, by the server, a billing eligibility score for the message thread. The billing eligibility score is determined by using one or more machine learning models to process the one or more message complexity indicators and the one or more provider engagement metrics. The one or more machine learning models are trained on historical data comprising secure messages, corresponding healthcare provider audit log activity, and prior billing determinations. The method further includes determining, by the server, recommended billing information for the message thread based on the billing eligibility score. The method further includes causing, by the server, the recommended billing information to be made accessible via the provider portal of the healthcare records and messaging system.

[0010] In an embodiment of the invention, the method further includes determining an initial billing prediction for the secure electronic message by using a machine learning model, of the one or more machine learning models, to process the one or more message complexity indicators. In this embodiment the method further includes causing the initial billing prediction to be made accessible to the account of the user through a patient portal.

[0011] In another embodiment of the invention, the one or more message complexity indicators include at least one of: a number of total words in the secure message, an average sentence length in the secure message, a semantic complexity of the secure message, an emotional tone, a lexical diversity of the secure message, a number of medical terms or concepts found in the secure message, and a number of clinical categories found in the secure message.Docket No. UOC-25006WO

[0012] In another embodiment of the invention, the one or more provider engagement metrics include at least one of a number of unique sections of the healthcare records and messaging system that are accessed by the at least one provider, a degree to which the at least one provider accessed each respective unique section of the healthcare records and messaging system, a total time that the at least one provider has accessed a medical record of the user, a frequency of distinct review instances of information relating to the secure message or associated medical record, and a number of transitions made by the at least one provider between distinct sections of the healthcare records and messaging system in response to the secure message.

[0013] In another embodiment of the invention, the method further includes determining one or more contextual complexity indicators relating to the message thread. The one or more contextual complexity metrics are derived from metadata of the message thread and include at least one of: a total duration of the message thread, a care setting associated with the message thread, and one or more contextual characteristics of a medical record of the user. In this embodiment, the billing eligibility score is determined for the message thread by using the one or more machine learning models to process the one or more message complexity indicators, the one or more provider engagement metrics, and the one or more contextual complexity indicators.

[0014] In another embodiment of the invention, the historical data used to train the one or more machine learning models includes message threads labeled as underbilled or overbilled based on labeled billing criteria. In this embodiment, the one or more machine learning models include an ensemble of models that are trained using a balanced number of underbilled and overbilled message threads randomly selected from labeled historical data.

[0015] In another embodiment of the invention, causing the recommended billing information to be made accessible via the provider portal includes providing, for display on a user interface of the provider portal, the recommended billing information including an explanation of factors contributing to an overall billing recommendation.

[0016] In another aspect of the invention, a device for determining billing recommendations for services provided in relation to telehealth communications is provided. The device includes a memory storing instructions and a processor communicatively coupled to the memory. The processor is to receive a secure message provided by an account of a user through a patient portal of a healthcare records and messaging system. The secure message contains information about a health-related inquiry of the user. The secure message is made accessible to a provider portal ofDocket No. UOC-25006WO the healthcare records and messaging system. The processor is further to receive system interaction data describing one or more interactions of at least one provider with the healthcare records and messaging system or task data describing one or more tasks performed by the at least one healthcare provider in response to the secure message. The system interaction data or task data is stored as audit log data. The processor is further to receive a secure response message provided via the provider portal of the healthcare records and messaging system. The secure message and the secure response message are part of a message thread that is stored in association with the audit log data.

[0017] The processor is further to determine one or more message complexity indicators that characterize a clinical complexity level of the secure message based on a semantic or contextual analysis of content included in the secure message. The processor is further to determine, by processing the audit log data and the secure response message, one or more provider engagement metrics that quantify a level of engagement of the at least one healthcare provider in responding to the secure message. The processor is further to determine a billing eligibility score for the message thread. The billing eligibility score is determined by using one or more machine learning models to process the one or more message complexity indicators and the one or more provider engagement metrics. The one or more machine learning models are trained on historical data comprising secure messages, corresponding healthcare provider audit log activity, and prior billing determinations. The processor is further to determine recommended billing information for the message thread based on the billing eligibility score. The processor is further to: cause the recommended billing information to be made accessible via the provider portal of the healthcare records and messaging system.

[0018] In an embodiment of the invention, the processor is further to determine an initial billing prediction for the secure electronic message by using a machine learning model, of the one or more machine learning models, to process the one or more message complexity indicators. In this embodiment, the processor is further to cause the initial billing prediction to be made accessible to the account of the user through a patient portal.

[0019] In another embodiment of the invention, the one or more message complexity indicators include at least one of: a number of total words in the secure message, an average sentence length in the secure message, a semantic complexity of the secure message, anDocket No. UOC-25006WO emotional tone, a lexical diversity of the secure message, a number of medical terms or concepts found in the secure message, and a number of clinical categories found in the secure message.

[0020] In another embodiment of the invention, the one or more provider engagement metrics include at least one of a number of unique sections of the healthcare records and messaging system that are accessed by the at least one provider, a degree to which the at least one provider accessed each respective unique section of the healthcare records and messaging system, a total time that the at least one provider has accessed a medical record of the user, a frequency of distinct review instances of information relating to the secure message or associated medical record, and a number of transitions made by the at least one provider between distinct sections of the healthcare records and messaging system in response to the secure message.

[0021] In another embodiment of the invention, the processor is further to determine one or more contextual complexity indicators relating to the message thread. The one or more contextual complexity metrics are derived from metadata of the message thread and include at least one of: a total duration of the message thread, a care setting associated with the message thread, and one or more contextual characteristics of a medical record of the user. In this embodiment, when determining the billing eligibility score, the processor is to determine the billing eligibility score for the message thread by using the one or more machine learning models to process the one or more message complexity indicators, the one or more provider engagement metrics, and the one or more contextual complexity indicators.

[0022] In another embodiment of the invention, the secure message and the secure response message are part of a multi-message thread that includes at one additional secure message and secure response message pair. In this embodiment, the processor determines the one or more message complexity indicators for each respective secure message in the multi-message thread. In this embodiment, the processor determines the one or more provider engagement metrics for each respective secure response message. In this embodiment, when determining the billing eligibility score, the processor is to aggregate the one or more message complexity indicators determined for each respective secure message in the multi-message thread. The processor is further to aggregate the one or more provider engagement metrics determined for each respective secure response message in the multi-message thread. The processor is further to determine the billing eligibility score based on a weighted combination of aggregated values.Docket No. UOC-25006WO

[0023] In another embodiment of the invention, the processor is further to automatically generate a claim submission request that includes the recommended billing information. In this embodiment, the processor is further to provide the claim submission request to a billing system.

[0024] In another aspect of the invention, a non-transitory computer-readable medium storing instructions is provided. The instructions include one or more instructions that, when executed by a processor, cause the processor to receive a secure message provided by an account of a user through a patient portal of a healthcare records and messaging system. The secure message contains information about a health-related inquiry of the user. The secure message is made accessible to a provider portal of the healthcare records and messaging system. The one or more instructions, when executed by the processor, further cause the processor to receive system interaction data describing one or more interactions of at least one provider with the healthcare records and messaging system or task data describing one or more tasks performed by the at least one healthcare provider in response to the secure message. The system interaction data or task data is stored as audit log data. The one or more instructions, when executed by the processor, further cause the processor to receive a secure response message provided via the provider portal of the healthcare records and messaging system. The secure message and the secure response message are part of a message thread that is stored in association with the audit log data. The one or more instructions, when executed by the processor, further cause the processor to determine one or more message complexity indicators that characterize a clinical complexity level of the secure message based on a semantic or contextual analysis of content included in the secure message. The one or more instructions, when executed by the processor, further cause the processor to determine, by processing the audit log data and the secure response message, one or more provider engagement metrics that quantify a level of engagement of the at least one healthcare provider in responding to the secure message. The one or more instructions, when executed by the processor, further cause the processor to determine a billing eligibility score for the message thread. The billing eligibility score is determined by using one or more machine learning models to process the one or more message complexity indicators and the one or more provider engagement metrics. The one or more machine learning models are trained on historical data comprising secure messages, corresponding healthcare provider audit log activity, and prior billing determinations. The one or more instructions, when executed by the processor, further cause the processor to determine recommended billing information for the messageDocket No. UOC-25006WO thread based on the billing eligibility score. The one or more instructions, when executed by the processor, further cause the processor to make the recommended billing classification accessible via the provider portal of the healthcare records and messaging system.

[0025] In an embodiment of the invention, the one or more instructions, when executed by the processor, further cause the processor to determine an initial billing prediction for the secure electronic message by using a machine learning model, of the one or more machine learning models, to process the one or more message complexity indicators. In this embodiment, the one or more instructions, when executed by the processor, further cause the processor to cause the initial billing prediction to be made accessible to the account of the user through a patient portal.

[0026] In another embodiment of the invention, the one or more message complexity indicators include at least one of: a number of total words in the secure message, an average sentence length in the secure message, a semantic complexity of the secure message, an emotional tone, a lexical diversity of the secure message, a number of medical terms or concepts found in the secure message, and a number of clinical categories found in the secure message.

[0027] In another embodiment of the invention, the one or more provider engagement metrics include at least one of a number of unique sections of the healthcare records and messaging system that are accessed by the at least one provider, a degree to which the at least one provider accessed each respective unique section of the healthcare records and messaging system, a total time that the at least one provider has accessed a medical record of the user, a frequency of distinct review instances of information relating to the secure message or associated medical record, and a number of transitions made by the at least one provider between distinct sections of the healthcare records and messaging system in response to the secure message.

[0028] In another embodiment of the invention, the one or more instructions, when executed by the processor, further cause the processor to determine one or more contextual complexity indicators relating to the message thread, the one or more contextual complexity metrics being derived from metadata of the message thread and comprising at least one of: a total duration of the message thread, a care setting associated with the message thread, and one or more contextual characteristics of a medical record of the user. In this embodiment, the one or more instructions, that cause the processor to determine the billing eligibility score, cause the processor to determine the billing eligibility score for the message thread by using the one orDocket No. UOC-25006WO more machine learning models to process the one or more message complexity indicators, the one or more provider engagement metrics, and the one or more contextual complexity indicators.

[0029] In another embodiment of the invention, the one or more instructions, that cause the processor to make the recommended billing information accessible via the provider portal, cause the processor to provide, for display on a user interface of the provider portal, the recommended billing information including an explanation of factors contributing to an overall billing recommendation.BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Fig. 1 is a diagram of an example environment in which systems and / or methods described herein may be implemented.

[0031] Fig. 2 is a diagram of example components of one or more devices of Fig. 1.

[0032] Figs. 3A-3J are diagrams of an example process for using machine learning to generate billing recommendations for services provided in relation to telehealth communications.

[0033] Fig. 4 is a diagram of a flowchart of an example process for training one or more machine learning models to generate billing recommendations according to the principles of the present disclosure.

[0034] Fig. 5 is a diagram of an example set of secure patient messages, provider response messages, and corresponding provider audit log entries, illustrating how message exchanges between a patient and provider are linked with provider engagement captured by the audit log.

[0035] Fig. 6 is a diagram of example statistical coefficients derived from a machine learning model, showing fixed and random effects of provider engagement with different sections of a healthcare records and messaging system.DETAILED DESCRIPTION

[0036] The following detailed description of example embodiments refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.

[0037] Fig. 1 is a diagram of an example environment 10 in which systems and / or methods described herein may be implemented. As shown in Fig. 1, environment 10 may include a patient device 12, a telehealth message management (TMM) platform 14 supported within aDocket No. UOC-25006WO cloud computing environment 16 (and containing one or more computing resources 18), a health records and management (HRM) system 20, a provider device 22, and / or a network 24. Devices of environment 10 may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

[0038] Patient device 12 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with a secure patient message (sometimes referred to herein as a secure message). For example, patient device 12 may include a computing device, such as a tablet computer (e.g., an iPad, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptop computer, a handheld computer, a server computer, a gaming device, a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), or a similar type of device.

[0039] In some embodiments, the patient device 12 may have access to a patient portal which is part of the HRM system 20. The patient portal may permit the patient to communicate with one or more healthcare providers electronically. For example, the patient may have an account with a healthcare application (e.g., a web application, a mobile application, etc.), such as MyChart, that permits the patient to view medical records, view billing information, send and / or receive messages, and / or the like. Communication between the patient device 12, the TMM platform 14, the HRM system 20, and / or the provider device 22 may occur over network 24 and / or may occur over a communication interface, such as an application programming interface (APIO) or another type of interface.

[0040] TMM platform 14 includes one or more devices capable of receiving, storing, processing, and / or providing information associated with a message thread. For example, TMM platform 14 may include a computing device, a server device (e.g., a host server, a web server, an application server, etc.), a data center device, or a similar device. The message thread may include one or more messages provided by the patient and one or more response messages provided by the healthcare provider. In some embodiments, the TMM platform 14 may be configured with, or have access to, one or more machine learning models that have been trained to analyze one or more messages included in the message thread and / or audit log data associated with the message thread. The TMM platform 14 may have access to a database and / or data structure used to sort, organize, and filter one or more types of data described herein.Docket No. UOC-25006WO

[0041] In some embodiments, such as is shown and described in connection with Figs. SA- 31, the TMM platform 14 may communicate with the HRM system 20. In this embodiment, the HRM system 20 supports the patient records, patient-provider messaging functionality, and / or billing information, while the TMM platform 14 is configured with one or more machine learning models to generate billing predictions in a manner described herein. In other embodiments, one or more features described as being performed by the TMM platform 14 may be performed by the HRM system 20. For example, the HRM system 20 may be configured with the one or more machine learning models and may carry out all processing steps described herein as being performed by the TMM platform 14.

[0042] In some embodiments, as shown, the TMM platform 14 may be hosted in the cloud computing environment 16. Notably, while embodiments described herein describe the TMM platform 14 as being hosted in the cloud computing environment 16, in some embodiments, the TMM platform 14 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0043] Cloud computing environment 16 includes an environment that hosts TMM platform 14. Cloud computing environment 16 may provide computation, software, data access, storage, etc. services that do not require end-user knowledge of a physical location and configuration of system(s) and / or device(s) that hosts the TMM platform 14. As shown, the cloud computing environment 16 may include a group of computing resources 18 (referred to collectively as “computing resources 18” and individually as “computing resource 18”).

[0044] Computing resource 18 includes one or more personal computers, workstation computers, server devices, or another type of computation and / or communication device. In some embodiments, the computing resource 18 may host the TMM platform 14. The cloud resources may include compute instances executing in the computing resource 18, storage devices provided in the computing resource 18, data transfer devices provided by the computing resource 18, and / or the like. In some embodiments, the computing resource 18 may communicate with other computing resources 18 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0045] As further shown in Fig. 1, computing resource 18 may include a group of cloud resources, such as one or more applications (“APPs”) 18-1, one or more virtual machinesDocket No. UOC-25006WO(“VMs”) 18-2, virtualized storage (“VSs”) 18-3, one or more hypervisors (“HYPs”) 18-4, and / or the like.

[0046] Application 18-1 may include one or more software applications that may be provided to or accessed by patient device 12, HRM system 20, and / or provider device 22. In some embodiments, application 18-1 may eliminate a need to install and execute the software applications on these devices. In some embodiments, one application 18-1 may send / receive information to / from one or more other applications 18-1, via virtual machine 18-2. In some embodiments, application 18-1 may be a healthcare records and management application. In some embodiments, the healthcare records and management application may include one or more user interfaces that are accessible by users.

[0047] Virtual machine 18-2 may include a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. Virtual machine 18-2 may be either a system virtual machine or a process virtual machine, depending upon use and degree of correspondence to any real machine by virtual machine 18-2. A system virtual machine may provide a complete system platform that supports execution of a complete operating system (“OS”). A process virtual machine may execute a single program and may support a single process. In some embodiments, virtual machine 18-2 may execute on behalf of another device (e.g., patient device 12), and may manage infrastructure of the cloud computing environment 16, such as data management, synchronization, or long-duration data transfers.

[0048] Virtualized storage 18-3 may include one or more storage systems and / or one or more devices that use virtualization techniques within the storage systems or devices of the computing resource 18. In some embodiments, within the context of a storage system, types of virtualizations may include block virtualization and file virtualization. Block virtualization may refer to abstraction (or separation) of logical storage from physical storage so that the storage system may be accessed without regard to physical storage or heterogeneous structure. The separation may permit administrators of the storage system flexibility in how the administrators manage storage for end users. File virtualization may eliminate dependencies between data accessed at a file level and a location where files are physically stored. This may enable optimization of storage use, server consolidation, and / or performance of non-disruptive file migrations.Docket No. UOC-25006WO

[0049] Hypervisor 18-4 may provide hardware virtualization techniques that allow multiple operating systems (c.g., “guest operating systems”) to execute concurrently on a host computer, such as computing resource 18. Hypervisor 18-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems.

[0050] HRM system 20 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with medical records of patient, billing records, and / or message records. For example, the HRM system 20 may include a computing device, a server device (e.g., a host server, a web server, an application server, etc.), a data center device, or a similar device. In some embodiments, the HRM system 20 supports all secure messaging functionality, including generating, transmitting, and receiving secure message threads, as well as capturing and storing audit log data corresponding to provider engagements with patient records and messaging workflows. In some embodiments, the HRM system 20 may support a plurality of sections including a patient chart overview / storyboard section, a problem list section, a medications list section, an allergies section, a lab results section, and imaging and diagnostic reports section, a vital signs / flowsheets section, a clinical notes section, an orders section, a vital diagnoses section, a documents / scanned reports section, an administrative data section, a workflow I task management section, a care team communication section, and / or the like.

[0051] In some embodiments, the HRM system 20 may be deployed as a component within a larger hospital or health system environment, interoperating with other specialized systems. Other specialized systems may include an electronic health records (EHR) system, a clinical decision support system, a care coordination and scheduling system, a financial and billing system, an administrative and operational system, and / or the like. In some embodiments, the HRM system 20 may refer to a combination of one or more of these systems. In this embodiment, the HRM system 20 may be said to include any combination of these healthcare systems. Thus, the HRM system 20 may represent either a single subsystem or an integrated platform spanning multiple domains of hospital operations, with messaging and audit logging as core supported functionalities.

[0052] Provider device 22 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated responding to a secure patient message (sometimes referred to herein as a secure message). For example, the provider deviceDocket No. UOC-25006WG 1 may include a computing device, such as a tablet computer (e.g., an iPad, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptop computer, a handheld computer, a server computer, a gaming device, a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), or a similar type of device. In some embodiments, the provider device 22 may have access to a provider portal that is part of the HRM system 20. The provider portal may permit a healthcare provider to provide a response to the patient message.

[0053] Network 24 includes one or more wired and / or wireless networks. For example, network 24 may include a cellular network (e.g., a fifth generation (5G) network, a fourth generation (4G) network, such as a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, a cloud computing network, or the like, and / or a combination of these or other types of networks.

[0054] The number and arrangement of devices and networks shown in Fig. 1 are provided as an example. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown in Fig. 1. Furthermore, two or more devices shown in Fig. 1 may be implemented within a single device, or a single device shown in Fig. 1 may be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of environment 10 may perform one or more functions described as being performed by another set of devices of environment 10.

[0055] Fig. 2 is a diagram of example components of a device 26. Device 26 may correspond to the patient device 12, the TMM platform 14, the HRM system 20, and / or the provider device 22. In some embodiments, the patient device 12, the TMM platform 14, the HRM system 20, and / or the provider device 22 may include one or more devices 26 and / or one or more components of device 26. As shown in Fig. 2, device 26 may include a bus 28, a processor 30, a memory 32, a storage component 34, an input component 36, an output component 38, and / or a communication interface 40.

[0056] Bus 28 includes a component that permits communication among multiple components of device 26. Processor 30 is implemented in hardware, firmware, and / or aDocket No. UOC-25006WO combination of hardware and software. Processor 30 includes a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and / or another type of processing component. In some embodiments, processor 30 includes one or more processors capable of being programmed to perform a function. Memory 32 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 30.

[0057] Storage component 34 stores information and / or software related to the operation and use of device 26. For example, storage component 34 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0058] Input component 36 includes a component that permits device 26 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone). Additionally, or alternatively, input component 36 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output component 38 includes a component that provides output information from device 26 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0059] Communication interface 40 includes a transceiver-like component (e.g., a transceiver and / or a separate receiver and transmitter) that enables device 26 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 40 may permit device 26 to receive information from another device and / or provide information to another device. For example, communication interface 40 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a WiFi interface, a cellular network interface, an application programming interface (API), and / or the like.Docket No. UOC-25006WO

[0060] Device 26 may perform one or more processes described herein. Device 26 may perform these processes based on processor 30 executing software instructions stored by a non- transitory computer-readable medium, such as memory 32 and / or storage component 34. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.

[0061] Software instructions may be read into memory 32 and / or storage component 34 from another computer-readable medium or from another device via communication interface 40. When executed, software instructions stored in memory 32 and / or storage component 34 may cause processor 30 to perform one or more processes described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, embodiments described herein are not limited to any specific combination of hardware circuitry and software.

[0062] The number and arrangement of components shown in Fig. 2 are provided as an example. In practice, device 26 may include additional components, fewer components, different components, or differently arranged components than those shown in Fig. 2. Additionally, or alternatively, a set of components (e.g., one or more components) of device 26 may perform one or more functions described as being performed by another set of components of device 26.

[0063] Figs. 3A-3I are diagrams of an example process 10 for using machine learning to generate billing recommendations for services provided in relation to telehealth communications. As shown in Fig. 3A, and by reference number 44, a patient may interact with the patient device 12 to input a secure message to a patient portal of the HRM system 20. For example, the patient may have an account with the HRM system 20 and may have access to a patient portal for sending secure messages to a healthcare provider. The patient may then interact with the patient portal to input a secure message to submit a health-related inquiry to the healthcare provider. As used herein, the term “healthcare provider” refers to any medical professional, hospital employee, care team member, and the like, who views, responds, and / or performs a task needed to respond to the secure message provided by the patient.

[0064] In the example shown, the patient inputs the following secure message: “I’ve been having mild but persistent chest tightness for the past 3 days, especially in the mornings. It’s notDocket No. UOC-25006WO severe, but it’s making me anxious because I have a history of high blood pressure. I checked my blood pressure at home, and it’s been around 145 / 90. 1 started a new cholesterol medication last week and wonder if that could be causing side effects. I also had a mild cough recently but no fever. Should I adjust any meds or schedule a follow-up appointment?” It is to be understood that this is provided by way of example. In practice, the secure message may contain any type of information relating to a health-related inquiry of the patient.

[0065] As shown by reference number 46, the patient device 12 may provide the secure message to the TMM platform 14. For example, when the patient submits the secure message, the patient device 12 may transmit the secure message to the TMM platform 14. In some embodiments, the patient device 12 may provide the secure message to the TMM platform 14 directly. In some embodiments, the patient device 12 may provide the secure message to the HRM system 20 and the HRM system 20 may provide the secure message to the TMM platform 14. In some embodiments, the secure message may be provided over network 24 and / or by using an application programming interface (API) or another type of communication interface. In some embodiments, the secure message may include a patient identifier, a message identifier the contents of the message. In some embodiments, the secure message may further include a message type field (e.g., new prescription request, health issue, etc.) to assist with billing predictions.

[0066] As shown in Fig. 3B, and by reference number 48, the TMM platform 14 may perform one or more pre-processing operations on the secure message. Pre-processing is performed to transform raw message text into a structured form suitable for natural language processing and subsequent feature extraction. The one or more pre-processing operations may include tokenizing content of the secure message into words or sub-word units, normalizing terms (e.g., mapping “bp” to “blood pressure”, standardizing verb tense, etc.), removing stop words, and / or the like.

[0067] To provide an example, the TMM platform 14 may perform one or more preprocessing operations on content included in the secure message shown in Fig. 3A. In this example, the TMM platform 14 may, for example, perform pre-processing operations on the sentence “I checked my bp at home, and it’s been around 145 / 90”, such as by tokenizing the words (e.g., splitting the sentence into discrete tokens: [“I,” “checked,” “my,” “bp,” “at,” “home,” “and,” “it’s,” “been,” “around,” “145 / 90”]) by normalizing the abbreviation “bp” intoDocket No. UOC-25006WO“blood pressure.”, and / or by removing the stop words (“I”, “my”, “at”, “and”, “it’s”, “been”, and “around”.

[0068] In some embodiments, the TMM platform 14 may also remove personally identifiable information (PII) from the secure message. This ensures that sensitive information of the patient is protected and not provided as an input to the one or more machine learning models described further herein.

[0069] As shown by reference number 50, the TMM platform 14 may determine one or more message complexity indicators that characterize a clinical complexity level of the secure message. For example, the TMM platform 14 may determine the one or more message complexity indicators by performing a linguistic analysis, a sentiment analysis, a medical terminology identification technique, and / or the like. The one or more message complexity indicators may include: a number of total words in the secure message, an average sentence length, a semantic complexity score derived from syntactic parsing, an emotional tone score derived from sentiment analysis, a lexical diversity score based on unique vocabulary usage, a density of medical terms, a number of distinct clinical concepts, and / or a number of categories of medical terminology (e.g., symptoms, medications, diagnoses), a Flesch-Kincaid readability score, and / or the like.

[0070] The semantic complexity score represents a level of contextual complexity or nuanced meaning within the secure message. For example, assume the secure message contains the following phrase: “since adjusting my insulin, my energy varies drastically, especially after meals”. In this example, the TMM platform 14 may determine that the secure message has high semantic complexity due to the nuanced text provided. The emotional tone score may represent a strength of emotional expression detected in the secure message. To provide an example, assume the secure message contains the following phrase: “I am really worried these symptoms are serious!”. In this example, the TMM platform 14 may determine that the secure message has high emotional tone due to the use of the phrase “really worried” and the use of an exclamation point.

[0071] The lexical diversity score may represent a ratio of unique words to total words in the secure message. To provide an example, assume the secure message contains the following phrase: “I have headaches and dizziness daily.” In this example, the TMM platform 14 may determine that the secure message has a high lexical diversity due to having six total words andDocket No. UOC-25006WO six unique words. The density of medical terms represents a number of unique medical terms or concepts mentioned in the secure message. To provide an example, assume the secure message contains the following phrase: “I have asthma, diabetes, and started metformin.” In this example, the TMM platform 14 may determine that the secure message has 3 unique medical concepts: asthma, diabetes, and metformin.

[0072] The number of distinct categories of medical terminology represents the number of semantic categories referenced in the secure message, such as medication, symptoms, diseases, and the like. To provide an example, assume the secure message contains the following phrase: “I have chest pain (symptom), diagnosed with angina (disease), taking nitroglycerin (medication).” In this example, the TMM platform 14 may determine that the secure message has three concept categories: a symptom, a disease, and a medication. The Flesh-Kincaid Readability score represents a grade-level readability of the secure message where a higher value indicates that the secure message is more difficult to read. To provide an example, assume the secure message contains the following phrase: “I am experiencing persistent gastrointestinal discomfort.” In this example, the TMM platform 14 may determine that the secure message has a higher readability score due to the use of complex medical terminology.

[0073] To provide yet another example, and referring now back to the example secure message shown and described in Fig. 3A, the TMM platform 14 may determine message complexity indicators for the secure message provided by the patient. For example, the secure message contains approximately 78 total words across 6 sentences, resulting in an average sentence length of about 13 words. A lexical diversity score may be computed as 62 unique words out of 78 total words, producing a diversity ratio of 0.79. A semantic complexity score may be elevated because the secure message includes nuanced contextual statements, such as “since starting a new cholesterol medication, I have also noticed a mild cough” that link symptoms, medications, and timing. The emotional tone score may be flagged as moderate, given use of terms such as “anxious” and “worried.” The secure message also includes at least three categories of medical terminology: symptoms (“chest tightness,” “cough”), vital signs (“145 / 90” blood pressure), and medications (“cholesterol medication”), resulting in a category count of three. Finally, the Flesch-Kincaid readability score for the secure message may be computed at approximately grade level 10, reflecting the use of multi-syllable medicalDocket No. UOC-25006WO terminology. These combined indicators collectively quantify the clinical complexity level of the secure message and arc provided as structured inputs for subsequent predictive analysis.

[0074] As shown by reference number 52, the TMM platform 14 may determine an initial billing prediction. For example, the TMM platform 14 may determine an initial billing prediction by using one or more machine learning models to analyze the one or more message complexity indicators. The one or more machine learning models may include a logistic regression classifier, a support vector machine, and / or an ensemble model such as a random forest trained on historical message data with labeled billing outcomes.

[0075] In some embodiments, the TMM platform 14 may apply a balanced random forest classifier trained to account for class imbalance between underbilled and overbilled encounters. In this case, the one or more message complexity indicators may be provided as an input to the classifier. The classifier may then evaluate patterns such as length, clinical detail, emotional tone, and the like, and may output a probability score representing a likelihood that the secure message is billable.

[0076] As shown in Fig. 3C, and by reference number 54, the TMM platform 14 may provide the initial billing prediction to the patient device 12. As shown by reference number 56, the patient device 12 may provide the initial billing prediction for display on a user interface of the patient portal. In the example shown, the initial billing prediction states: “Your message contains multiple clinical issues and may require a detailed review by your care team. Based on our analysis, this message is likely to result in a billable telehealth encounter.”

[0077] In some embodiments, the TMM platform 14 may also generate provider routing recommendations in connection with the initial billing prediction. For example, the TMM platform 14 may determine, based on the message complexity indicators, whether the secure message should be routed to a physician, a nurse practitioner, a medical assistant, or another member of the care team. In this way, the TMM platform 14 not only provides an initial billing prediction but also supports downstream workflow management by mapping the secure message to the most appropriate provider for review and response.

[0078] In this way, the TMM platform 14 provides an initial billing prediction that provides additional transparency to the patient by alerting the patient that the secure message may results in a medical bill. This early notification allows the patient to make an informed decision regarding their communications with the healthcare provider while also helping the healthcareDocket No. UOC-25006WO provider to set proper expectations and reduce the likelihood of patient dissatisfaction regarding receiving an unexpected medical bill.

[0079] As shown in Fig. 3D, and by reference number 58, the TMM platform 14 may provide the secure message to the HRM system 20. In some embodiments, the TMM platform 14 may provide the HRM system 20 with the secure message and a provider routing recommendation that specifies a healthcare provider that should receive the secure message.

[0080] As shown by reference number 60, the HRM system 20 may store the secure message as part of a record of a message thread. The secure message may contain a patient identifier and a message identifier. The HRM system 20 may use the patient identifier to associate the secure message with a medical record of the patient and may use the message identifier to distinguish the secure message from other messages associated with the same patient. In some embodiments, the HRM system 20 may further generate or assign a message thread identifier that links together multiple secure messages and response messages exchanged between the patient and one or more providers.

[0081] As shown by reference number 62, the HRM system 20 may provide the secure message to the provider device 22. For example, the HRM system 20 may provide the secure message to an account of a healthcare provider, where the secure message is accessible via a provider portal of the provider device 22. The provider portal permits a healthcare provider to submit a response message and / or to perform one or more tasks or interactions with the HRM system 20 in connection with responding to the secure message. In some embodiments, the HRM system 20 may provide the secure message to a provider account or provider device 22 associated with a healthcare provider or type of healthcare provider recommended by the TMM platform 14.

[0082] As shown in Fig. 3E, and by reference number 64, a healthcare provider may review the secure message (e.g., via the patient portal) and may interact with the HRM system 20 to perform one or more tasks associated with responding to the secure message. The one or more tasks may include opening a patient chart, reviewing a problem list, reviewing medications, reviewing allergies, reviewing lab results, reviewing vital signs, reviewing recent notes, viewing existing orders, and / or the like. For example, reviewing a problem list may involve examining a structured summary of the patient’s active and historical diagnoses to determine whether the secure message relates to a previously documented condition. Reviewing medications mayDocket No. UOC-25006WO involve checking the patient’s current prescriptions for possible interactions or dosage adjustments. Reviewing allergies may involve verifying known drug or food allergies prior to issuing new orders. Reviewing lab results may include examining recent bloodwork, imaging reports, or diagnostic panels to contextualize the patient’s inquiry. Reviewing vital signs may involve checking recent blood pressure, pulse, or temperature entries recorded in the electronic health record. Reviewing recent notes may involve examining prior clinical documentation by the provider or care team for continuity of care. Viewing existing orders may include verifying open laboratory, diagnostic, or prescription orders to avoid duplicative efforts.

[0083] In some embodiments, multiple healthcare providers may review the secure message and / or may interact with the HRM system 20 to perform tasks associated with responding to the secure message. For example, a nurse practitioner may review medications and vital signs to triage the inquiry, while a physician subsequently reviews lab results and problem lists to finalize the diagnosis and provide a secure response message. Each provider’s interactions are separately logged and associated with the same message thread record.

[0084] As shown by reference number 66, the provider device 22 may provide system interaction data and / or task data to the HRM system 20. For example, as the healthcare provider views the secure message and / or interacts with the HRM system 20, the provider device 22 transmits corresponding interaction data and / or task data (e.g., “Problem List opened,” “Lab Results reviewed,” “Orders viewed”) to the HRM system 20 in real time. Lor example, when a healthcare provider opens the patient’s medication list or navigates to laboratory results, the provider device 22 transmits interaction data and / or task data corresponding to the interactions with the medication list or lab results to the HRM system 20. These digital traces are captured without requiring any additional effort from the provider.

[0085] As shown by reference number 68, the HRM system 20 may store the system interaction data and / or the task data as audit log data. For example, as the HRM system 20 receives the interaction data and / or task data, the HRM system 20 may generate audit log data that includes a structured digital representation of each interaction and / or task. The audit log data may include metadata such as a provider identifier, a message thread identifier, a patient identifier, time data (e.g., a timestamp of a click or interaction or a total time spent viewing a particular type of patient data), a type of record accessed, and / or data describing the interaction and / or task performed. As will be described further herein, the audit log data may subsequentlyDocket No. UOC-25006WO be processed to compute one or more provider engagement metrics that are used in determining a final billing prediction.

[0086] As shown in Fig. 3F, and by reference number 70, the healthcare provider may interact with the provider device 22 to input a response message. For example, the healthcare provider may interact with a user interface of the provider portal to input a response message. In the example shown, the healthcare provider message states: “Thank you for your detailed message. Based on what you’ve described, your blood pressure is slightly elevated, and the chest tightness you’re experiencing is concerning, especially given your history of hypertension. While your cholesterol medication can sometimes cause muscle aches, it’s less likely to cause chest tightness. I’d like you to schedule a virtual or in-office appointment within the next 2-3 days to further evaluate your symptoms and ensure your heart health. In the meantime, please continue taking your current medications, and if your chest pain worsens, becomes severe, or is associated with shortness of breath, dizziness, or sweating, call 911 or go to the nearest emergency room immediately.”

[0087] As shown by reference number 72, the provider device 22 may provide the secure response message to the HRM system 20. As shown by reference number 74, the HRM system 20 may store the secure response message as part of the record of the message thread. For example, the HRM system 20 may associate the secure response message with the patient identifier (e.g., PATID) and the message thread identifier (e.g., ENCID) corresponding to the ongoing secure message exchange. The secure response message may also be assigned a unique message identifier to distinguish it from other messages in the same thread. These identifiers enable the HRM system 20 to maintain a structured record of the conversation, such that all messages (e.g., both patient-initiated and provider responses) are stored in chronological order as part of a unified message thread. In some embodiments, the HRM system 20 may further index the response message by metadata such as a timestamp, provider identifier, and message type, allowing efficient database queries, retrieval for clinical review, and downstream analytics (e.g., feature extraction for billing prediction analysis).

[0088] Fig. 3G is intending to illustrate that patient messages, provider response messages, and provider interactions and / or tasks are asynchronous in nature. The record of the message thread, and associated audit log data, reflects messages and / or data collected over a time period during which the message thread remains active. This asynchronous nature reflects real-worldDocket No. UOC-25006WO clinical workflows where patients and providers may contribute messages or perform tasks at different times, sometimes over the course of several days or weeks. As shown in Fig. 3G, and by reference number 76, the healthcare provider may perform one or more additional interactions with the HRM system 20 and one or more additional tasks associated with responding to the secure message of the patient. As shown by reference number 78, the healthcare provider may route the message thread to a nurse or other staff member, schedule a follow-up visit with the patient, sign and finalize an order, add a note to the message thread, communicate with another member of the care team, close the message thread, and / or the like.

[0089] As shown by reference number 80, as the provider interacts with the HRM system 20, system interaction data and / or task data is provided to the HRM system 20. As shown by reference number 82, the HRM system 20 may store the system interaction data and / or task data as audit log data. In this way, the HRM system 20 creates and maintains a structured record of the message thread that captures all communications, metadata, and associated audit log data within a single record.

[0090] As shown by reference number 84, the HRM system 20 may provide, to the TMM platform 14, the secure message, the secure response message, and all audit log data collected in association with the message thread. In some embodiments, the HRM system 20 may be configured to provide the secure message, the secure response message, and corresponding audit log data to the TMM platform 14 once the message thread has been closed by a healthcare provider. In some embodiments, the secure message, the secure response message, and corresponding audit log data may be provided to the TMM platform 14 based on another trigger, such as an expiration of a timer, completion of a message-response pair, and / or the like.

[0091] As shown in Fig. 3H, and by reference number 86, the TMM platform 14 may perform one or more pre-processing operations on the response message and audit log data. Preprocessing may be performed to transform raw log entries and response message content into structured representations that can be analyzed consistently across message threads. For example, the one or more pre-processing operations may include parsing raw audit log events into structured fields (e.g., event type, timestamp, section of HRM system accessed), normalizing identifiers for consistency (e.g., mapping “ProblemListAccessed” and “OpenProblemList” into a unified “Problem List” category), and removing extraneous or redundant entries, and / or the like. In some embodiments, the one or more pre-processing operations may also include aggregatingDocket No. UOC-25006WO time-based events into continuous interaction intervals (e.g., combining multiple clicks within the same EHR section into a single “review session”) to better capture engagement patterns.

[0092] As shown by reference number 88, the TMM platform 14 may determine one or more provider engagement metrics based on the secure response message and the audit log data. For example, the TMM platform 14 may determine one or more provider engagement metrics that quantify a level of engagement of the healthcare provider in responding to the secure message. In this case, the TMM platform 14 may determine the one or more provider engagement metrics by parsing audit log entries to identify unique sections of the HRM system 20 accessed by the healthcare provider (e.g., medications, labs, problem list, etc.), aggregating timestamps to compute a total time the healthcare provider spent in the patient’ s chart and / or in specific sections of the HRM system, counting discrete events such as the number of transitions between sections in the HRM system 20 or the number of times a provider revisits a section (e.g., reviewing labs multiple times), and / or the like. Additionally, or alternatively, the TMM platform 14 may determine the one or more provider engagement metrics by performing role-based attribution in which log events are associated with specific provider identifiers (e.g., physician vs. nurse practitioner) to quantify the degree of involvement of different providers, by performing a sequence analysis which examines the order and frequency of audit log events to measure workflow patterns (e.g., whether a provider follows a consistent path through patient data), by cross-referencing the secure response message length / content with audit log data activity, such as by determining whether longer or more detailed provider responses correlate with higher numbers of log interactions, and / or the like.

[0093] The one or more provider engagement metrics may include a number of unique sections of the HRM system 20 that are accessed by the healthcare provider, a degree to which the healthcare provider accessed each respective unique section of the HRM system 20, an amount of time that the healthcare provider has spent reviewing data relating to the patient and / or patient message, a frequency of distinct review instances of information relating to the secure message or associated medical record, and / or the like.

[0094] The number of unique sections of the HRM system 20 that are accessed by the healthcare provider may, for example, include accessing sections relating to medications, lab results, clinical notes, and / or the like. In this example, the TMM platform 14 may determine that the number of unique sections accessed is three. The degree to which the healthcare providerDocket No. UOC-25006WO accessed each respective unique section of the HRM system 20 reflects a thoroughness or amount of detail within accessed sections during the healthcare provider’s review. For example, if the provider extensively reviews multiple historical lab results spanning several visits, the TMM platform 14 may quantify the depth of the reviewing by assigning a numeric value indicative of the depth of the review.

[0095] The time that the healthcare provider has spent reviewing data relating to the patient and / or patient message may be represented as data reflecting an amount of time spent reviewing one or more of: administrative data, clinical notes, patient documents, flowchart data (e.g., lab values, vital signs, etc.), medication related data, orders (e.g., labs, imaging, referrals, etc.), clinical information (e.g., medical history), patient profile information (e.g., age, gender, insurance, etc.), a patient problem list, a structured report (e.g., a report from radiology), workflow management tasks (e.g., referrals, scheduling, etc.), and / or the like. To provide examples, the provider engagement metrics may include metrics indicating that the healthcare provider spent two minutes reviewing billing information, four minutes reviewing physician notes from a prior encounter, five minutes reviewing scanned cardiology reports, three minutes reviewing patient vital signs history, two minutes reviewing a patient’s medication list, one minute checking recent lab and imaging orders, three minutes reviewing the patient’s medical history, one minute verifying the patient’s age and insurance, two minutes reviewing the patient’s chronic conditions, four minutes reviewing the radiology and pathology reports, and two minutes scheduling a follow-up appointment.

[0096] The frequency of distinct review instances of information relating to the patient and / or the secure message may include a frequency at which the healthcare provider accessed administrative data, clinical notes, patient documents, flowsheet data, medication-related information, orders (e.g., labs, imaging, etc.), general clinical information (e.g., history, etc.), patient profile information, a patient problem list, a structured report, a workflow task, and / or the like. To provide examples, the provider engagement metrics may include metrics indicating that the provider accessed administrative sections three times during message review, revisited clinical notes four times, accessed scanned documents twice, reviewed patient vitals and lab values three times, checked medications twice, revisited patient lab orders three times, accessed medical history three times, checked patient demographics once, revisited the problem list twice,Docket No. UOC-25006WO accessed radiology reports twice, and returned to workflow-related tasks (e.g., appointments, referrals, etc.) twice.

[0097] In some embodiments, the TMM platform 14 may group provider engagement metrics by role or by interaction type. For example, engagement metrics may be grouped by physician or nurse practitioner, by passing viewing vs active ordering, and / or the like.

[0098] In some embodiments, such as when patient has provided one or more additional secure messages in connection with the same message thread, the TMM platform 14 may determine one or more message complexity indicators for each respective secure patient message. In this case, the TMM platform 14 may aggregate the message complexity indicators determined for each respective secure message in the multi-message thread. The TMM platform 14 may also aggregate the one or more provider engagement metrics determined for each respective secure response message (e.g., in case the healthcare provider has provided multiple responses). These aggregated values may then be used for determining the billing edibility score based on a weighted combination of aggregated values. For example, in some embodiments, more recent messages in the message thread may be assigned a higher weight than earlier messages to emphasize the most current clinical context. In other embodiments, longer or more detailed secure messages may be weighted more heavily than shorter messages, and provider responses that include multiple interactions with the HRM system 20 or longer provider review times may be given higher weights than cursory responses. Additionally, the weights may be learned automatically by a machine learning model during training, such that the model adapts to emphasize features most predictive of billing outcomes. The determination of the billing eligibility score is described in further detail in connection with Fig. 31.

[0099] In some embodiments, in addition to determining message complexity indicators and provider engagement metrics, the TMM platform 14 may determine one or more contextual complexity indicators relating to the message thread. For example, the TMM platform 14 may determine one or more contextual complexity indicators by processing metadata of the message thread. The one or more contextual complexity indicators may include a total duration of the message thread, a care setting associated with the message thread (e.g., primary care, cardiology, urgent care, etc.), one or more contextual characteristics of a medical record of the patient (e.g., presence of a chronic condition, number of prior medical encounters in the past year, etc.), and / or the like. The one or more contextual complexity indicators may be provided as an inputDocket No. UOC-25006WO to the one or more machine learning models (e.g., along with the one or more message complexity indicators and the one or more provider engagement metrics, as is described in Fig. 31 below).

[0100] As shown in Fig. 31, and by reference number 90, the TMM platform 14 may determine a billing eligibility score for the message thread using one more machine learning models. For example, the one or more message complexity indicators, the one or more provider engagement metrics, and / or the one or more contextual complexity indicators may be provided as an input to the one or more machine learning models. The one or more machine learning models may include classifiers such as a balanced random forest, a gradient boosted tree model (e.g., XGBoost), or a logistic regression model trained on historical secure message threads with billing labels. In some embodiments, the balanced random forest may be preferred to address class imbalance (e.g., underbilled cases being more common than overbilled cases) by downsampling the majority class during each bootstrap iteration.

[0101] The machine learning models may be trained using a training dataset of message complexity indicators, provider engagement metrics, and / or contextual complexity indicators, along with corresponding billing labels determined by expert clinical reviewers based on CPT code guidelines. Model training may include splitting the dataset into training and validation subsets, optimizing model hyperparameters, and benchmarking performance using evaluation metrics such as precision, recall, Fl -score, and an area under the receiver operating characteristic (ROC) curve.

[0102] In a preferred embodiment using a balanced random forest model, multiple decision trees may be trained on different random subsets of the training data. Each decision tree evaluates the message complexity indicators, provider engagement metrics, and / or contextual complexity indicators to classify whether the message thread should be billed. The outputs of the individual trees are aggregated (e.g., via majority vote or averaging predicted probabilities) to produce the billing eligibility score for the message thread.

[0103] The billing eligibility score output by the one or more machine learning models may be a continuous value between 0.00 and 1.00 that represents the probability or likelihood that a given message thread qualifies as a billable telehealth encounter. For example, a score closer to 1.00 may indicate a high probability that the encounter is billable while a score closer to 0.00 may indicate a low probability.Docket No. UOC-25006WO

[0104] In some embodiments, the TMM platform 14 may determine recommended billing information based on the billing eligibility score. For example, and as shown by reference number 92, the TMM platform 14 may determine a recommended billing classification based on the billing eligibility score. To provide a specific example, billing eligibility score ranges between 0.00 and 0.39 may be mapped to a classification of “No Charge,” billing eligibility score ranges between 0.40 and 0.59 may be mapped to CPT code 99421 (low complexity telehealth visit), billing eligibility score ranges between 0.60 and 0.79 may be mapped to CPT code 99422 (medium complexity telehealth visit), and billing eligibility score ranges between 0.80 and 1.00 may be mapped to CPT code 99423 (high complexity telehealth visit). It is to be understood that this is provided by way of example. In practice, any number of different billing eligibility score ranges and corresponding CPT codes may be used.

[0105] In some embodiments, the thresholds for mapping billing eligibility scores to CPT codes may be optimized using decision curve analysis. In this embodiment, the thresholds may maximize a net benefit under predefined cost assumptions for false positives and false negatives. In other embodiments, the thresholds may be configured by administrators of a healthcare system or dynamically adjusted based on payer-specific reimbursement guidelines.

[0106] By converting the continuous billing eligibility score into a discrete billing classification, the TMM platform 14 provides an actionable recommendation that can be used by healthcare providers, administrators, or automated billing systems to support accurate and consistent billing practices.

[0107] As shown in Fig. 3J, and by reference number 94, the TMM platform 14 may provide the recommended billing classification to the HRM platform 20. As shown by reference number 96, the HRM platform 20 may provide the recommended billing classification to the provider device 22. As shown by reference number 98, the provider device 22 may provide the recommended billing classification for display on a user interface of the provider portal. In some embodiments, the recommended billing classification may be provided to a billing server or device associated with an accounting department.

[0108] In some embodiments, the recommended billing classification may be presented as a human-readable message (e.g., “Recommended: CPT 99422 - Moderate complexity e- visit”) to assist the provider in making a final decision. In other embodiments, the output may be provided in a structured format (e.g., JSON, HL7 FHIR resource, or another standardized billing codeDocket No. UOC-25006WO format) for automated ingestion by downstream hospital billing systems. In some embodiments, the output may also include a confidence score or explanatory indicators (c.g., “based on message complexity and provider engagement metrics”) to improve transparency and trust in the recommendation. Additionally, the HRM platform 20 may log the recommendation along with provider actions (accept, modify, or reject) to support auditing, quality improvement, and retraining of the one or more machine learning models.

[0109] Through the processes described herein, the TMM platform 14 provides a comprehensive and automated framework for analyzing secure messages, audit log data, and response activity to generate billing recommendations in connection with telehealth communications. By systematically pre-processing patient messages, deriving message complexity indicators, capturing provider engagement metrics, and applying machine learning models, the TMM platform 14 supports accurate and consistent billing determinations. The integration with the HRM system 20 ensures that all secure messages, provider responses, and associated audit log data are captured in a structured record, enabling robust traceability. The output of recommended billing classifications, whether presented directly to providers, routed to billing departments, or integrated into downstream financial systems, reduces the risk of underbilling and overbilling, improves compliance with standardized billing criteria, and enhances overall operational efficiency. In this way, the described embodiments improve the functioning of healthcare information systems by transforming disparate message and log data into actionable billing intelligence that supports both clinical workflows and financial sustainability.

[0110] As indicated above, Figs. 3A-3J are provided merely as an example. Other examples may differ from what is described with regard to Figs. 3A-3J. For example, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown in Figs. 3A-3J. Furthermore, two or more devices shown in Figs. 3A-3J may be implemented within a single device, or a single device shown in Figs. 3A-3J may be implemented as multiple and / or distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of example process 42 may perform one or more functions described as being performed by another set of devices of example process 42.Docket No. UOC-25006WO

[0111] Fig. 4 is a diagram of a flowchart of an example process 100 for training one or more machine learning models to generate billing recommendations according to the principles of the present disclosure. As shown by reference number 102, the process begins with descriptive benchmarking in which provider billing decisions for secure message threads are compared against standardized billing criteria to determine the prevalence of underbilling and overbilling. This stage establishes baseline patterns of billing discrepancies. In this stage, each message thread is assigned a billing label. The billing label may, for example, be determined by expert clinical review applying defined reimbursement guidelines to digital evaluation and management services. Each label is then compared with the provider’s actual billing action for the same message thread. If the provider failed to bill for a message thread that was labeled as billable, the case is counted as underbilling. If the provider billed for a message thread that was labeled as non-billable, the case is counted as overbilling. Cases where provider action matches the label represent appropriate billing. Aggregating the counts across all message threads yields the overall prevalence of underbilling and overbilling, thereby establishing baseline discrepancy patterns.

[0112] As shown by reference number 104, the process continues with feature engineering. In this stage, structured indicators are determined from message content and audit log data, including message complexity indicators, domain engagement metrics, and / or contextual complexity metrics. These features provide quantitative measures of provider workload, message characteristics, and encounter context, and serve as inputs to the subsequent machine learning training process. In some embodiments, the one or more machine learning models may include an ensemble classifier such as a Balanced Random Forest configured to address class imbalance between underbilled and overbilled encounters. Additionally, or alternatively, the one or more machine learning models may include a logistic regression model, a gradient-boosted tree model, or another supervised learning approach trained on historical message threads labeled according to billing criteria.

[0113] As shown by reference number 106, discrepant isolation and validation are performed. Here, cases in which provider billing actions diverge from the labeled criteria (e.g., underbilled or overbilled encounters) are identified from the full training dataset. The identified cases are transformed into structured feature representations, including engineered indicators of message complexity, provider engagement, and contextual complexity. Eabels corresponding toDocket No. UOC-25006WO billing discrepancy type are assigned, and the data is pre-processed to address missing values and to normalize feature scales. The curated dataset is then partitioned into training and validation sets, such that a portion is used to train the machine learning model while a separate portion is withheld to evaluate performance and generalizability of the model.

[0114] As shown by reference number 108, the one or more machine learning models are trained and validated. For example, the one or more machine learning models, such as a balanced random forest classifier, may be trained using the engineered features to distinguish between underbilled and overbilled encounters. In this approach, multiple decision trees are constructed on random subsets of the training data, with class imbalance addressed by downsampling the majority class (e.g., underbilled cases) during each bootstrap iteration so that underbilled and overbilled cases are represented more evenly. Each decision tree learns patterns from the engineered features, such as message length, number of clinical concepts, time spent in patient records, the number of task switches, and the like, to classify whether a given encounter is more likely to be underbilled or overbilled. The outputs of the individual trees are aggregated (e.g., via majority vote or averaged probabilities) to produce a billing prediction. Model performance is validated against a holdout test set, and benchmarked using metrics such as precision (e.g., a number or percentage of correct model predictions), recall (e.g., a proportion of actual underbilled or overbilled encounters that are correctly identified by the model), an area under the receiver operating characteristic (ROC) curve (e.g., plots a tradeoff between positives and false positives across different thresholds), and / or a similar type of metric.

[0115] As shown by reference number 110, decision curve analysis is applied to evaluate the operational utility of the one or more machine learning models. This stage estimates the net benefit of deploying the one or more machine learning models under varying decision thresholds and balancing the trade-off between recovering missed billing opportunities and generating false positive alerts. For example, the probability threshold output by the one or more machine learning models may be varied between low and high values. For each threshold, the relative number of true positives (e.g., correctly identified underbilled encounters) and false positives (e.g., non-billable encounters incorrectly flagged) is measured. The net benefit is then calculated by weighting true positives against false positives according to predefined cost assumptions, such as the administrative cost of reviewing an alert versus the revenue gained from correctly billing an eligible encounter. Plotting these values across thresholds produces a decision curveDocket No. UOC-25006WO which allows stakeholders to select an optimal threshold that maximizes revenue recovery while minimizing unnecessary workload.

[0116] As shown by reference number 112, revenue simulation is performed. Using model performance metrics and standardized reimbursement rates, financial impact is simulated to project potential revenue recovery under different threshold scenarios. For example, at a given decision threshold, the “recall” of the one or more machine learning models may indicate how many underbilled encounters would be correctly identified per 10,000 message threads, while the “precision” indicates how many false positive encounters would also be flagged. These values can be multiplied by reimbursement rates associated with different CPT billing codes (e.g., $15 for low-complexity, $30 for medium-complexity, $47 for high-complexity e-visits, etc.) to estimate expected revenue recovery. By repeating this calculation across multiple thresholds, scenarios can be generated showing the tradeoff between aggressive alerting (greater revenue recovery with more false positives) and conservative alerting (less revenue recovery but fewer false positives). This stage illustrates the potential scale of revenue that may be recovered in practice and provides decision-makers with an evidence-based estimate of the value of implementing the one or more machine learning models in real- world healthcare operations.

[0117] As shown in Fig. 5, and by reference number 114, an example set of secure patient messages, provider response messages, and corresponding provider audit log entries is provided. Fig. 5 illustrates how message exchanges between a patient and provider are linked with provider engagement captured by the audit log. For example, in Fig. 5, message identifiers (MSGIDs) 300 and 370 are unique identifiers for two separate secure message threads between a patient and a provider. MSGID 300 represents a message exchange that occurred on September 1, 2024. This thread contains multiple messages (e.g., MSGID 300, 325, 330, 400, 430) between the same patient and provider (e.g., PADID 1, PROVID 101, ENCID 20). ENCID refers to an encounter ID and may correspond to the message thread identifier described in connection with Fig. 3D. The audit log shows clinical activities performed in response to this message thread (e.g., storyboard view, orders report, problem list review). Essentially, message ID 300 ties together all secure messages in that encounter and all related provider audit log events. Similarly, message ID 370 represents another message thread that occurred on September 3, 2024. This message thread includes multiple messages, such as MSGID 370, 410, and 435. The audit log data shows distinct provider interactions (storyboard view, clinical notes, med list, visitDocket No. UOC-25006WO diagnosis) tied to the message thread. By using the message identifier (MSGID) to link the secure message records to the relevant audit log data, the TMM platform 14 is able to analyze messages and provider engagement per message thread when determining a billing prediction.

[0118] As shown in Fig. 6, and by reference number 116, example graphs are provided illustrating statistical coefficients derived from a machine learning model. In particular, the graphs depict results of a mixed-effects modeling analysis in which provider engagement with different sections of a healthcare records and messaging system is evaluated relative to billing outcomes. The top graph shows fixed effect coefficients while the bottom graph shows random effect coefficients, each corresponding to different knowledge domains or record sections (e.g., Administrative, Demographic, Documents, Flowsheet, Medical History, Medical Problems, Medical Reports, Medications, Orders, Patient Notes, and Workflow).

[0119] Each bar represents the coefficient (0) value associated with a given domain, with longer bars indicating stronger influence on the model’s billing prediction. For example, Medical History shows a relatively large positive coefficient in both the fixed effect and random effect models, suggesting that provider engagement with the patient’s medical history section of the record strongly correlates with higher billing likelihood. Error bars associated with each coefficient indicate the standard errors, providing a measure of statistical confidence.

[0120] The vertical dashed line at zero serves as a reference, allowing visual distinction between positive coefficients (features associated with increased billing likelihood) and negative coefficients (features associated with decreased billing likelihood). The fixed effect model captures average effects across providers, while the random effect model accounts for variability between providers, highlighting domains where individual provider behavior contributes to differences in billing outcomes.

[0121] Overall, Fig. 6 provides a visual representation of how different categories of provider EHR engagement contribute to billing-related predictions. By distinguishing between fixed and random effects, the graphs demonstrate both generalizable patterns across the provider population and provider- specific variations, thereby highlighting the importance of modeling heterogeneity when developing predictive tools for billing support in telehealth messaging contexts.

[0122] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications andDocket No. UOC-25006WO variations may be made in light of the above disclosure or may be acquired from practice of the embodiments.

[0123] Certain user interfaces have been described herein and / or shown in the figures. A user interface may include a graphical user interface, a non-graphical user interface, a text-based user interface, etc. A user interface may provide information for display. In some embodiments, a user may interact with the information, such as by providing input via an input component of a device that provides the user interface for display. In some embodiments, a user interface may be configurable by a device and / or a user (e.g., a user may change the size of the user interface, information provided via the user interface, a position of information provided via the user interface, etc.). Additionally, or alternatively, a user interface may be pre-configured to a standard configuration, a specific configuration based on a type of device on which the user interface is displayed, and / or a set of configurations based on capabilities and / or specifications associated with a device on which the user interface is displayed.

[0124] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, and / or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limiting of the embodiments. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code - it being understood that software and hardware can be used to implement the systems and / or methods based on the description herein.

[0125] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” Furthermore, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, etc.), and may be used interchangeably with “one or more.” Where only one item is intended, the phrase “only one” or similar’ language is used. Also, as used herein, the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.

Claims

Docket No. UOC-25006WOWhat is claimed is:

1. A computer implemented method for determining billing recommendations for services provided in relation to telehealth communications, comprising: receiving, by a server, a secure message provided by an account of a user through a patient portal of a healthcare records and messaging system, wherein the secure message contains information about a health-related inquiry of the user, wherein the secure message is made accessible to a provider portal of the healthcare records and messaging system; receiving, by the server, audit log data including at least one of: system interaction data describing one or more interactions of at least one provider with the healthcare records and messaging system, and task data describing one or more tasks performed by the at least one healthcare provider in response to the secure message; receiving, by the server, a secure response message provided via the provider portal of the healthcare records and messaging system, wherein the secure message and the secure response message are part of a message thread that is stored in association with the audit log data; determining, by the server, one or more message complexity indicators that characterize a clinical complexity level of the secure message based on a semantic or contextual analysis of content included in the secure message; determining, by the server and by processing the audit log data and the secure response message, one or more provider engagement metrics that quantify a level of engagement of the at least one healthcare provider in responding to the secure message; determining, by the server, a billing eligibility score for the message thread, wherein the billing eligibility score is determined by using one or more machine learning models to process the one or more message complexity indicators and the one or more provider engagement metrics, wherein the one or more machine learning models are trained on historical data comprising secure messages, corresponding healthcare provider audit log activity, and prior billing determinations; determining, by the server, recommended billing information for the message thread based on the billing eligibility score; and causing, by the server, the recommended billing information to be made accessible via the provider portal of the healthcare records and messaging system.Docket No. UOC-25006WO2. The method of claim 1, further comprising: determining an initial billing prediction for the secure electronic message by using a machine learning model, of the one or more machine learning models, to process the one or more message complexity indicators; and causing the initial billing prediction to be made accessible to the account of the user through a patient portal.

3. The method of claim 1, wherein the one or more message complexity indicators include at least one of: a number of total words in the secure message, an average sentence length in the secure message, a semantic complexity of the secure message, an emotional tone, a lexical diversity of the secure message, a number of medical terms or concepts found in the secure message, and a number of clinical categories found in the secure message. a linguistic complexity indicator that quantifies a syntactic or lexical complexity of the secure message, an indicator of emotional tone, and an indicator of medical terminology density in the secure message based on a quantity of clinical concepts identified therein.

4. The method of claim 1, wherein the one or more provider engagement metrics include at least one of: a number of unique sections of the healthcare records and messaging system that a e accessed by the at least one provider, a degree to which the at least one provider accessed each respective unique section of the healthcare records and messaging system, a total time that the at least one provider has accessed a medical record of the user,Docket No. UOC-25006WO a frequency of distinct review instances of information relating to the secure message or associated medical record, and a number of transitions made by the at least one provider between distinct sections of the healthcare records and messaging system in response to the secure message.

5. The method of claim 1, further comprising: determining one or more contextual complexity indicators relating to the message thread, the one or more contextual complexity metrics being derived from metadata of the message thread and comprising at least one of: a total duration of the message thread, a care setting associated with the message thread, and one or more contextual characteristics of a medical record of the user; and wherein determining the billing eligibility score comprises: determining the billing eligibility score for the message thread by using the one or more machine learning models to process the one or more message complexity indicators, the one or more provider engagement metrics, and the one or more contextual complexity indicators.

6. The method of claim 1, wherein the historical data used to train the one or more machine learning models comprises message threads labeled as underbilled or overbilled based on labeled billing criteria, and wherein the one or more machine learning models include an ensemble of models that are trained using a balanced number of underbilled and overbilled message threads randomly selected from labeled historical data.

7. The method of claim 1, wherein causing the recommended billing information to be made accessible via the provider portal comprises: providing, for display on a user interface of the provider portal, the recommended billing information including an explanation of factors contributing to an overall billing recommendation.

8. A device for determining billing recommendations for services provided in relation to telehealth communications, comprising: a memory; andDocket No. UOC-25006WO a processor, communicatively coupled to the memory, to: receive a secure message provided by an account of a user through a patient portal of a healthcare records and messaging system, wherein the secure message contains information about a health-related inquiry of the user, wherein the secure message is made accessible to a provider portal of the healthcare records and messaging system; receive system interaction data describing one or more interactions of at least one provider with the healthcare records and messaging system or task data describing one or more tasks performed by the at least one healthcare provider in response to the secure message, wherein the system interaction data or task data is stored as audit log data; receive a secure response message provided via the provider portal of the healthcare records and messaging system, wherein the secure message and the secure response message are part of a message thread that is stored in association with the audit log data; determine one or more message complexity indicators that characterize a clinical complexity level of the secure message based on a semantic or contextual analysis of content included in the secure message; determine, by processing the audit log data and the secure response message, one or more provider engagement metrics that quantify a level of engagement of the at least one healthcare provider in responding to the secure message; determine a billing eligibility score for the message thread, wherein the billing eligibility score is determined by using one or more machine learning models to process the one or more message complexity indicators and the one or more provider engagement metrics, wherein the one or more machine learning models are trained on historical data comprising secure messages, corresponding healthcare provider audit log activity, and prior billing determinations; determine recommended billing information for the message thread based on the billing eligibility score; and cause the recommended billing information to be made accessible via the provider portal of the healthcare records and messaging system.

9. The device of claim 8, wherein the processor is further to:Docket No. UOC-25006WO determine an initial billing prediction for the secure electronic message by using a machine learning model, of the one or more machine learning models, to process the one or more message complexity indicators; and cause the initial billing prediction to be made accessible to the account of the user through a patient portal.

10. The device of claim 8, wherein the one or more message complexity indicators include at least one of: a number of total words in the secure message, an average sentence length in the secure message, a semantic complexity of the secure message, an emotional tone, a lexical diversity of the secure message, a number of medical terms or concepts found in the secure message, and a number of clinical categories found in the secure message.

11. The device of claim 8, wherein the one or more provider engagement metrics include at least one of: a number of unique sections of the healthcare records and messaging system that are accessed by the at least one provider, a degree to which the at least one provider accessed each respective unique section of the healthcare records and messaging system, a total time that the at least one provider has accessed a medical record of the user, a frequency of distinct review instances of information relating to the secure message or associated medical record, and a number of transitions made by the at least one provider between distinct sections of the healthcare records and messaging system in response to the secure message.

12. The device of claim 8, wherein the processor is further to: determine one or more contextual complexity indicators relating to the message thread, the one or more contextual complexity metrics being derived from metadata of the messageDocket No. UOC-25006WO thread and comprising at least one of: a total duration of the message thread, a care setting associated with the message thread, and one or more contextual characteristics of a medical record of the user; and wherein the processor, when determining the billing eligibility score, is to: determine the billing eligibility score for the message thread by using the one or more machine learning models to process the one or more message complexity indicators, the one or more provider engagement metrics, and the one or more contextual complexity indicators.

13. The device of claim 8, wherein the secure message and the secure response message are part of a multi-message thread that includes at one additional secure message and secure response message pair, wherein the processor determines the one or more message complexity indicators for each respective secure message in the multi-message thread, wherein the processor determines the one or more provider engagement metrics for each respective secure response message, and wherein processor, when determining the billing eligibility score, is to: aggregate the one or more message complexity indicators determined for each respective secure message in the multi-message thread, aggregate the one or more provider engagement metrics determined for each respective secure response message in the multi-message thread, and determine the billing eligibility score based on a weighted combination of aggregated values.

14. The device of claim 8, wherein the processor is further to: automatically generate a claim submission request that includes the recommended billing information; and provide the claim submission request to a billing system.

15. A non-transitory computer-readable medium storing instructions, the instructions comprising one or more instructions that, when executed by a processor, cause the processor to:Docket No. UOC-25006WO receive a secure message provided by an account of a user through a patient portal of a healthcare records and messaging system, wherein the secure message contains information about a health-related inquiry of the user, wherein the secure message is made accessible to a provider portal of the healthcare records and messaging system; receive system interaction data describing one or more interactions of at least one provider with the healthcare records and messaging system or task data describing one or more tasks performed by the at least one healthcare provider in response to the secure message, wherein the system interaction data or task data is stored as audit log data; receive a secure response message provided via the provider portal of the healthcare records and messaging system, wherein the secure message and the secure response message are part of a message thread that is stored in association with the audit log data; determine one or more message complexity indicators that characterize a clinical complexity level of the secure message based on a semantic or contextual analysis of content included in the secure message; determine, by processing the audit log data and the secure response message, one or more provider engagement metrics that quantify a level of engagement of the at least one healthcare provider in responding to the secure message; determine a billing eligibility score for the message thread, wherein the billing eligibility score is determined by using one or more machine learning models to process the one or more message complexity indicators and the one or more provider engagement metrics, wherein the one or more machine learning models are trained on historical data comprising secure messages, corresponding healthcare provider audit log activity, and prior billing determinations; determine recommended billing information for the message thread based on the billing eligibility score; and make the recommended billing information accessible via the provider portal of the healthcare records and messaging system.

16. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions, when executed by the processor, further cause the processor to:Docket No. UOC-25006WO determine an initial billing prediction for the secure electronic message by using a machine learning model, of the one or more machine learning models, to process the one or more message complexity indicators; and cause the initial billing prediction to be made accessible to the account of the user through a patient portal.

17. The non-transitory computer-readable medium of claim 15, wherein the one or more message complexity indicators include at least one of: a number of total words in the secure message, an average sentence length in the secure message, a semantic complexity of the secure message, an emotional tone, a lexical diversity of the secure message, a number of medical terms or concepts found in the secure message, and a number of clinical categories found in the secure message.

18. The non-transitory computer-readable medium of claim 15, wherein the one or more provider engagement metrics include at least one of: a number of unique sections of the healthcare records and messaging system that are accessed by the at least one provider, a degree to which the at least one provider accessed each respective unique section of the healthcare records and messaging system, a total time that the at least one provider has accessed a medical record of the user, a frequency of distinct review instances of information relating to the secure message or associated medical record, and a number of transitions made by the at least one provider between distinct sections of the healthcare records and messaging system in response to the secure message.

19. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions, when executed by the processor, further cause the processor to:Docket No. UOC-25006WO determine one or more contextual complexity indicators relating to the message thread, the one or more contextual complexity metrics being derived from metadata of the message thread and comprising at least one of: a total duration of the message thread, a care setting associated with the message thread, and one or more contextual characteristics of a medical record of the user; and wherein the one or more instructions, that cause the processor to determine the billing eligibility score, cause the processor to: determine the billing eligibility score for the message thread by using the one or more machine learning models to process the one or more message complexity indicators, the one or more provider engagement metrics, and the one or more contextual complexity indicators.

20. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions, that cause the processor to make the recommended billing information accessible via the provider portal, cause the processor to: provide, for display on a user interface of the provider portal, the recommended billing information including an explanation of factors contributing to an overall billing recommendation.

Images