System and methods for estimating level of services

Abstract

Systems and methods are provided for estimating a level of service for a medical service. An example method entails (a) retrieving a medical record of a patient seeking emergency medical service; (b) analyzing the medical record, preferably using a machine learning model, to identify problems, data and risk useful to support estimation of a level of service (LoS); (c) displaying, on a user interface, (i) the identified problems, data and risk, (ii) forms for a user to input additional information on the problems, data or risk or edit the identified problems, data or risk, and (iii) an estimated LoS based on the problems, data and risk; and (d) generating an output summarizing the problems, data and risk and the estimated LoS.

Description

SYSTEM AND METHODS FOR ESTIMATING LEVEL OF SERVICESCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit under 35 U.S.C. § 119(e) of United States Provisional Application Serial Number 63 / 552,565, filed February 12, 2024, the contents of which is incorporated by reference in its entirety into the present disclosure.BACKGROUND

[0002] Professional billing in the US for emergency doctors is based on rules created by the Centers for Medicare & Medicaid Services (CMS) and followed by nearly all payers. Emergency doctors and their employers have learned approaches to maximize what they can bill for - essentially, remembering to not leave any potential charges “on the table,” typically by making sure work that was done was properly documented.

[0003] CMS changed these billing rules in January 2023, for the first time in decades, for emergency doctors and for a few other specialties. Practices have variably adjusted to the new rules, with many using partially effective strategies that sometimes also lead to physician frustration.

[0004] Physicians bill an overall “Evaluation and Management” (E / M) billing code for each patient seen, in addition to procedures. In emergency medicine, these E / M codes represent 85- 90% of the revenue, so the focus is mostly on increasing these. Each chart was marked as one of 5 levels: E / M Level 1-5, or “Critical Care” (essentially a 6th level with a different set of rules for the ~5% of “critically sick” patients that require immediate attention).

[0005] The billing rules are challenging to follow, however. Three main factors are considered for the determination of the E / M level, including Data, Problems and Risk, each having their own logic. Notably, many of these inputs are not well described by CMS and other resources, perhaps on purpose to allow the physicians to express their own views, such as what they see as severe vs non-severe.

[0006] In some institutions a professional medical coder is designated to review the physicians’ documentation - perhaps a few days after the chart is written - to convert their notes into a code.Some institutions / practices create feedback loops from coders to physicians to provide feedback generally, or feedback directly for a chart “did you mean to say .. The direct feedback per chart is an expensive step which can be much larger than professional fees.

[0007] There is a need to improve the efficiency of and reduce the time spent on the professional billing process for emergency service providers or other healthcare service providers. Also, it is important to ensure that correct billings are created to avoid loss of reasonable revenue.SUMMARY

[0008] Systems and methods are provided for estimating a level of service for a medical service. An example method entails (a) retrieving a medical record of a patient seeking medical service (e.g., emergency service); (b) analyzing the medical record to identify problems, data and risk useful to support estimation of a level of service (LoS); (c) displaying, on a user interface, (i) the identified problems, data and risk, (ii) forms for a user to input additional information on the problems, data or risk or edit the identified problems, data or risk, and (iii) an estimated LoS based on the problems, data and risk; and (d) generating an output summarizing the problems, data and risk and the estimated LoS. In some embodiments, the medical record is analyzed using a machine learning model.

[0009] In some embodiments, the machine learning model is trained with training data with historic patient data and determined LoS. In some embodiments, the machine learning model is a neuro network model, a large language model or a generative artificial intelligence model.

[0010] In some embodiments, the method further comprises identifying potential problems, data or risk and displaying the potential problems, data or risk on the user interface but does not apply the potential problems, data or risk in the estimation of the LoS, until confirmed by the user.

[0011] In some embodiments, the potential problems, data or risk has lowered confidence, as determined by the machine learning model, as compared to the identified problems, data or risk.

[0012] In some embodiments, the machine learning model is configured to monitor one or more of (1) editing, by users, the identified problems, data or risk, (2) whether the users confirm the potential problems, data or risk, or (3) edits to the output made by the users.

[0013] In some embodiments, the method further comprises displaying the output or saving the output in a non-transitory medium.

[0014] In some embodiments, the method further comprises displaying a questionnaire taking input from a user that comprises considerations concerning potential medical treatments and / or hospitalizations.

[0015] Various embodiments of the present disclosure provide a device, one or more processors, and / or non-transitory storage medium to implement the method as described above. For example, the device may include system having one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the system to perform the method as described above.

[0016] These and other features of the devices, methods, and non-transitory computer readable media disclosed herein, as well as the methods of operation and functions of the related elements of structure and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for purposes of illustration and description only and arc not intended as a definition of the limits of the invention.BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Certain features of various embodiments of the present technology are set forth with particularity in the appended claims. A better understanding of the features and advantages of the technology will be obtained by reference to the following detailed description that sets forth illustrative embodiments, in which the principles of the invention are utilized, and the accompanying drawings of which;

[0018] FIG. 1 illustrates an example user interface used in one embodiment of the present disclosure.

[0019] FIG. 2 is a flowchart of an example process 200 of the present disclosure.DETAILED DESCRIPTION

[0020] Embodiments described in this application provide a method, implemented by a system having one or more computer processors, that estimates the level of service based on patient records and / or doctor notes.

[0021] The CMS has established an updated 2023 evaluation and management (E / M) coding guidelines to determine the level of service (LoS) provided during a patient encounter. Documentation of various elements in the patient’s chart determines the LoS, which is in turn categorized into five levels. Level 1 of LoS corresponds to the lowest reimbursement, and Level 5 charts correspond to the highest reimbursement. There are also some nonnumerical levels used in conjunction with these standardized LoS. For instance, “Critical Care” is used for “critically sick” patients that require immediate attention. The determination of LoS is primarily based on the complexity of medical decision-making, making its documentation critically important for appropriate reimbursement.

[0022] Briefly, the 2023 E / M guidelines are based on three categorical elements: problems, data, and risk (Table 1).Table 1. Elements in E / M Coding Guidelines

[0023] The problems element is an assessment of the number, severity, and complexity of patient problems addressed during the patient encounter.

[0024] The data element includes medical records, tests, and / or other information that must be obtained, ordered, reviewed, and analyzed for the encounter. This includes information obtained from multiple sources or interprofessional communications that are not reported separately and interpretation of tests that are not reported separately. Ordering a test is included in the category of test result(s) and the review of the test result is part of the encounter and not a subsequent encounter. Ordering a test may include those considered but not selected after shared decisionmaking. For example, a patient may request diagnostic imaging that is not necessary for their condition and discussion of the lack of benefit may be required. Alternatively, a test may normally be performed, but due to the risk for a specific patient it is not ordered. These considerations must be documented. Data are divided into three categories:- Tests, documents, orders, or independent historian(s). (Each unique test, order, or document is counted to meet a threshold number.)- Independent interpretation of tests (not separately reported).- Discussion of management or test interpretation with external physician or other qualified health care professional or appropriate source (not separately reported).

[0025] The risks element includes decisions made at the encounter associated with diagnostic procedure(s) and treatment(s). This includes the possible management options selected and those considered but not selected after shared decision making with the patient and / or family. For example, a decision about hospitalization includes consideration of alternative levels of care. Examples may include a psychiatric patient with a sufficient degree of support in the outpatient setting or the decision to not hospitalize a patient with advanced dementia with an acute condition that would generally warrant inpatient care, but for whom the goal is palliative treatment.

[0026] The actual compliance of the 2023 E / M guidelines, however, can be time consuming and cumbersome. In many cases, unless paying particular attention, the doctors may overlook items leading to incorrectly lower LoS, hence lower reimbursement. For instance, for the Data section, it’s fairly easy to narrow in on the key typical aspects that a coder may not be able to pull from a note, but that a physician may have done. First, it’s easy to see most of the inputs to the Data section, such as: how many labs, X-ray’s, and other tests were performed? However, the data section includes a few inputs that aren’t always captured: did the doctor get history from someone besides the patient? Did they independently review an X-ray or EKG, and what did they see?

[0027] The Problems and Risk sections have similar patterns, where some items are easy to see from the chart, such as if a parenteral controlled substance was used (e.g., easy to see the doctor ordered IV morphine) or that a “Hospitalization was considered” if the patient was actuallyadmitted to the hospital. But other items may be less easy to see: when a patient was sent home, the doctor may or may not have first considered admission; when a CT scan is ordered of the abdomen in a patient with flank pain, the doctor may have been evaluating for a kidney stone (“moderate” problem) or an abdominal aortic aneurysm (a “high” problem).

[0028] It’s not difficult to create a list of questions that, if the doctor consistently answers thoughtfully, less will be left on the table for reimbursement. Along this line, some hospitals have generated a listing of 8-12 questions that a doctor is required to ask on each chart. Example questions include, “did you independently interpret an EKG?” “did you speak with anyone besides the patient for the history?” and “were you considering admission?”

[0029] There are a few problems with such an approach. First, the physician is typically writing their note afterwards; sometimes they’re just signing a resident or physician assistant (PA) note and being asked these questions - which are hard to remember. Second, these 8-12 questions are typically quite broad or even vague. Third, the physician knows that these questions may only help increase the chart level in 2-3 patients out of 10, and even for those few patients, there may have been one specific question that improved the chart. So the doctor is asked 8-12 questions x 10 patients, which amount to about 100 questions - when only 2-4 questions actually helped. This contrast disincentivizes engagement. The more time the doctors spend with this system, the more frustrated they are. As a result, doctors are not typically compliant with the system (at one practice, % docs surveyed indicated that they just choose “N / A” on most questions a few months after this started).

[0030] Currently, there are no reliable solutions for these problems. Indeed, according to reports, emergency departments have seen an overall decrease of about 10% in revenue due to incorrect downshift of reported LoS.ML-Based Medical Decision-Making (MDM) Engine

[0031] The instant inventor has developed a machine learning (ML)-based solution for these problems. In some embodiments, an ML-based medical decision-making (MDM) engine is created that can take input from an electronic health record (EHR) and output data back to the EHR. Further, the ML-based MDM engine is integrated into the EHR, to improve information collection.

[0032] In some embodiment, when a doctor prepares a patient note in the EHR, the MDM engine is triggered to present a user interface which is presented like a calculator that includes questions that need to be completed by the doctor before the doctor can proceed. An example MDM engine-powered calculator is illustrated in FIG. 1.

[0033] As illustrated in FIG. 1, the calculator 100 is pre-filled with information that can be pulled from the patient chart, in a similar way that the coder would pull information from the patient chart. For instance, the Data section may be filled out with info that’s clear in the chart: number of labs and tests ordered (see, e.g., “3+” in 101). Likewise, “Hospitalization considered” will be automatically selected if the patient was indeed hospitalized. Based on such automatic inputs, the estimated coding level is shown (110), and down below a set of sentences automatically created are shown (120) to the doctor for review.

[0034] The calculator also allows edits and inputs directly from the doctor. For instance, the input box 102 prompts the doctor to describe “independent interpretation of tests.” Also, the number of tests ordered (101) can be adjusted by the doctor. In some embodiments, the system highlights tests that can potentially be edited by the doctor (e.g., those that commonly require independent interpretation) to facilitate review and editing. When each input / edit is made, the coding level (110) and descriptions are automatically updated.ML-Based Recommendations

[0035] As described above, the MDM engine is capable of automatically populating the calculator with information extracted from the patient chart, and calculating the initial LoS based on such information. While the auto-populated information can be edited by the doctor, this portion of automatic action is typically done with information retrieval of high confidence. That is, the system only extracts information that is considered to be highly reliable.

[0036] In certain embodiments, the MDM engine is configured to analyze patient chart and patient data, through machine learning, to make recommendations to the doctor. An objective of this approach is to not ask too many questions (e.g., 8-12 questions as some hospitals currently mandate). In some embodiments, unless answered or confirmed by the doctor, the MDM engine does not automatically update the calculator, to avoid mistakes, given that such recommendations generally have lower confidence than the auto-populated data.

[0037] In one example, a patient arrived with “asthma exacerbation,” was given treatment for asthma, and was then sent home. The patient had first arrived with a low oxygen level and high respiratory rate, signs suggesting that they may have been quite sick. Upon retrieving such information, the MDM engine does both of the following: (A) automatically choosing the “moderate” level of risk for “exacerbation of a chronic condition,” and (b) suggesting a “high” level of risk for “severe exacerbation of a chronic condition,” reminding the doctor that the patient arrived with the low oxygen level and high resp rate. (A) is auto-population with high confidence, while (B) is a recommendation that requires confirmation from the doctor. For (B), the doctor would have to actively choose it by clicking on the suggest button.

[0038] In some embodiments, when making recommendations, the MDM engine can highlight those which, if confirmed by the doctor, will elevate the LoS level. For example, there are situations where the above “exacerbation” -> “severe exacerbation” edit to the Problem section would NOT result in a high chart level (either because the patient is already a Level 5, OR because the Data and Risk sections would not support it). While the suggestion will still be there in the form of a clickable button, it won’t be highlighted. However, if such a change would result in a change of Level from 4 to 5, then the system will highlight the recommendation to the doctor. The highlighting, on the computer interface, can be done with methods known in the art, such as using color, shading, flashing, and annotation, without limitation.

[0039] The recommendation and highlighting can be of great assistance to the doctor. In particular, in the event where an additional piece of documentation may matter, the doctor can immediately see where and what may matter. For example, a section on “‘discussion with an external provider” is highlighted, and the doctor can type in a sentence or two on what other doctors they discussed the care, what they discussed, and why, all within about 10-15 seconds. By doing so, the LoS can be elevated appropriately.

[0040] Once the doctor has confirmed the recommendations and has also otherwise completed the inputs of the calculator, the MDM engine then generates an output in text format which the doctor can copy and paste into a report, which can optionally be transmitted to a coder for finalization and submission. The calculated LoS, in some embodiments, is included or shown in the output. In a preferred embodiment, however, the output does not include a formallycalculated LoS. Rather, it only includes an “estimated” LoS. In other words, the MDM engine serves as an estimation tool, rather than a coding tool. In yet another embodiment, no LoS is included at all, and the output serves as information collection / identification to support the coder’s coding work. An example of such an output is shown below:2023 Emergency Medicine Coding GuideAll calculations should be rechecked by clinician prior to use * *RESULT SUMMARY :4 Estimated Level of ServiceProblems : Moderate ( 4 )Risk : Moderate ( 4 ) Data : Extensive ( 5 )NARRATIVE MDM :This patient ' s problem complexity is Moderate as patient : with chronic illness ( es ) with exacerbat on / progression / side effects of treatment .This patient ' s risk is Moderate due to : overall presentation requiring evaluation for a potentially Moderate-risk process .This patient ' s data complexity is Extensive due to :-multiple tests ordered / reviewed-external notes reviewed-_ndependenL in terpre tation of imaging or EKG-discussion of management / testing with external professionalINPUTS :Number and Complexity — > 3 = 4 : chronic illness with exacerbation ( c )Rask level — > 3 = ModerateTest s ordered — > 2 = 2Tests results reviewed ( excluding labs ) — > 2 = 2Prior external notes reviewed — > 2 = 2Assessment requiring and independent historian — > 0 = No Independent interpretation of tests — > 1 = YesDiscussed management / test interpretation w / external professional — > 1 = Yes

[0041] Such a system, it can be readily appreciated, can save a lot of time for doctors and their organizations, while providing the opportunity to not lose revenue due to incorrect billing. With the MDM engine, it is estimated that a doctor only needs to spend about 10 seconds on average for each patient chart as the doctor only has to answer 2-4 most relevant questions.

[0042] The ML-based recommendation system can be trained with various methods. One example is the large language model (LLM), which is a specialized neural network-basedsystem, employing a modified Generative Pre-trained Transformer (GPT) architecture. The model can be trained on a diverse dataset of hcalthcarc-rclatcd language patterns and structures. It can incorporate domain-specific knowledge to ensure accurate interpretation of medical information.

[0043] The model can undergo rigorous pre-training on a vast dataset comprising electronic health records, medical literature, and healthcare terminology. This training process optimizes the model’s parameters, enabling it to recognize and understand complex medical concepts.

[0044] When used, the LLM is presented with a patient chart or an electronic health record, the model utilizes advanced tokenization techniques specifically tailored for medical language. It breaks down the record into clinically relevant units, facilitating efficient processing while maintaining the medical context. Through such advanced capabilities, the model extracts key information from electronic health records, including diagnosis details, treatment plans, medication history, and relevant patient parameters. This extracted information serves as a foundation for medical decision-making.

[0045] Another model is the generative artificial intelligence (Al). Generative Al can process and understand unstructured patient data from EHRs and clinical notes. It can extract key information, summarize medical histories, and present relevant details in a concise manner. The model can analyze doctor’s notes, patient symptoms, laboratory results, imaging reports, and other diagnostic data to extract elements useful to populate in any of the problems / data / risks.

[0046] In addition, the model can be improved with feedbacks from doctors while using the instant system. In one example, the system makes an estimation of the level, while the doctor or coder eventually decides on one which may be the same or different from the estimated one. The system compares them, and takes the comparison results as input to update the model.

[0047] In a second example, the system monitors on how often doctors click on suggestions, or unclick high confidence auto-fills, and what of them specifically. Such monitoring can provide insight on how each suggestion is considered by the doctors, and the model can then use that information to reevaluate the suggestion mechanism.

[0048] In a third example, the system monitors how often doctors type into free text boxes, and what they type. The typed information can be compared to what is in the patient record and to help understand whether similar’ information can be extracted in the future.

[0049] In a fourth example, the system monitors how often doctors edit the output text. If certain corrections are made, the system can use that to improve future output text generation.

[0050] In some embodiments, the system is specifically modeled for the “Critical Care” level, which has some unique rules. In some embodiments, the estimation can be simplified. For instance, if there’s clear evidence and documentation that the patient was “sick enough” for critical care, the doctor only needs to document that they spent 30+ minutes doing “critical care.” So long as the system retrieves such notes from the patient chart, the system will directly recommend a Critical Care level, without the need to fill out information for all three sections, which can be grayed out on the user interface.Model-Driven Improvement of Care

[0051] The ML-based tools of the instant disclosure can have uses in addition to estimating LoS. In certain situations, multiple options may be available for a patient, each of which is acceptable. For example, about 70% of patients with head trauma can be prescribed for a CT scan of the head which, however, may not be necessary if they satisfy, e.g., the Canadian Head CT Rule. If the doctor is unsure whether ordering a CT test can only add to the cost, which may not increase reimbursement, then the doctor may be reluctant to order the test. By the same token, if the doctor is concerned that not ordering the CT test would result in not generating more revenue, the doctor may order the CT regardless.

[0052] With the instantly described technology, the doctor can try different inputs in the system, and may realize that not ordering the CT test would not reduce the LoS . With such knowledge, therefore, the doctor can opt to apply the rule for credit, without ordering a CT test. Such would amount to significant saving of costs and patient time, patient exposure to radiation, and align incentives with the clinician to use evidence-based tools to reduce the need for tests. Application of the rule, for instance, can be done and evidenced with a module in the instant system that evaluates the situation with respect to the rule e.g., the Canadian Head CT Rule).

[0053] Similar modules can be added in the system to evidence other medical considerations. For instance, the module can help determine how sick a patient is, and whether the patient can be safely sent home. The module can measure various factors for the determination. Examples include Chest Pain (Heart Score and others), Pneumonia (CURB-65 and PSI), COPD Exacerbation (BAP-65), and Syncope (Canadian Syncope Rule). By using these modules, the doctors can satisfy / support the “Hospitalization considered” level, even if the patient was ultimately sent home.

[0054] More generally, the instant technology provides additional / altemative care options to the doctors, optionally along with their associated LoS, to give the doctors information on how to provide the best care and minimize intervention or patient discomfort / inconvenience, and yet not lose reasonable revenue. At the same time, when necessary, the use of the technology provides a written record of what medical interventions have been considered by the doctor, to support calculation of LoS.

[0055] In some embodiments, the technology is used at multiple phases during the medical service and reporting. Such integration brings about additional benefits. For instance, during the medical service stage, the doctor uses the module to determine a suitable treatment based on a symptom (e.g., head trauma) which suggests to not do a CT scan. At this stage, the input is anonymized (no patient-identifying information). While the doctor is preparing for a report with the module at a later stage, the system will retrieve the patient’s record, indicating that the patient had head trauma. Even though the earlier record is anonymized, by virtue of their time closeness and common symptom, the system can suggest (cannot directly enter since the system cannot confirm) to the doctor that a CT scan was considered but was not ordered. The doctor can confirm the information and allow the system to enter the information, supporting an appropriate LoS calculation.

[0056] FIG. 2 is a flowchart of an example process 200. In some implementations, one or more process blocks of FIG. 2 may be performed by a computer device.

[0057] As shown in FIG. 2, process 200 may include (a) retrieving a medical record of a patient seeking emergency medical service (block 210). For example, the device may (a) retrieve a medical record of a patient seeking medical service, as described above. As also shown in FIG.2, process 200 may include (b) analyzing the medical record, using a machine learning model, to identify problems, data and risk useful to support estimation of a level of service (LoS) (block 220). For example, the device may (b) analyze the medical record, using a machine learning model, to identify problems, data and risk useful to support estimation of a level of service (LoS), as described above.

[0058] As further shown in FIG. 2, process 200 may include (c) displaying, on a user interface, (i) the identified problems, data and risk, (ii) forms for a user to input additional information on the problems, data or risk or edit the identified problems, data or risk, and (iii) an estimated LoS based on the problems, data and risk (block 230). For example, the device may (c) display, on a user interface, (i) the identified problems, data and risk, (ii) forms for a user to input additional information on the problems, data or risk or edit the identified problems, data or risk, and (iii) an estimated LoS based on the problems, data and risk, as described above. As also shown in FIG. 2, process 200 may include (d) generating an output summarizing the problems, data and risk and the estimated LoS (block 240). For example, the device may (d) generate an output summarizing the problems, data and risk and the estimated LoS, as described above.

[0059] In some embodiments, the machine learning model is trained with training data with historic patient data and determined LoS. In some embodiments, the machine learning model is a neuro network model, a large language model or a generative artificial intelligence model.

[0060] Optionally, in some embodiments, the method further entails identifying potential problems, data or risk and displaying the potential problems, data or risk on the user interface but does not apply the potential problems, data or risk in the estimation of the LoS, until confirmed by the user (block 250). In some embodiments, the potential problems, data or risk has lowered confidence, as determined by the machine learning model, as compared to the identified problems, data or risk.

[0061] In some embodiments, the machine learning model is configured to monitor one or more of (1) editing, by users, the identified problems, data or risk, (2) whether the users confirm the potential problems, data or risk, or (3) edits to the output made by the users.

[0062] Optionally, in some embodiments, the method further entails displaying the output or saving the output in a non-transitory medium (block 260).

[0063] Optionally, in some embodiments, the method further entails displaying a questionnaire taking input from a user that comprises considerations concerning potential medical treatments and / or hospitalizations.

[0064] Process 200 may include additional implementations, such as any single implementation or any combination of implementations described below and / or in connection with one or more other processes described elsewhere herein. A first implementation, process 200 may include, identifying potential problems, data or risk and displaying the potential problems, data or risk on the user interface but does not apply the potential problems, data or risk in the estimation of the LoS, until confirmed by the user.

[0065] A second implementation, alone or in combination with the first implementation, process 200 may include displaying the output or saving the output in a non-transitory medium.

[0066] A third implementation, alone or in combination with the first and second implementation, process 200 may include displaying a questionnaire taking input from an user that may include considerations concerning potential medical treatments and / or hospitalizations.

[0067] Although FIG. 2 shows example blocks of process 200, in some implementations, process 200 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in FIG. 2. Additionally, or alternatively, two or more of the blocks of process 200 may be performed in parallel.Hardware Configuration and System Implementation

[0068] The techniques described herein, for example of the one or more processors, are implemented by one or more special-purpose computing devices. The special-purpose computing devices may be hard-wired to perform the techniques, or may include circuitry or digital electronic devices such as one or more application- specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are persistently programmed to perform the techniques,or may include one or more hardware processors programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination.

[0069] The computer system is one example of many possible computer systems that have different architectures. For example, personal computers based on an Intel microprocessor often have multiple buses, one of which can be an TO bus for the peripherals and one that directly connects the processor and the memory (often referred to as a memory bus). The buses are connected together through bridge components that perform any necessary translation due to differing bus protocols.

[0070] Network computers are another type of computer system that can be used in conjunction with the teachings provided herein. Network computers do not usually include a hard disk or other mass storage, and the executable programs are loaded from a network connection into the memory for execution by the processor. A Web TV system, which is known in the art, is also considered to be a computer system, but it may lack some of the features, such as certain input or output devices. A typical computer system will usually include at least a processor, memory, and a bus coupling the memory to the processor.

[0071] In general, a computer system will include a processor, memory, non-volatile storage, and an interface. A typical computer system will usually include at least a processor, memory, and a device (c.g., a bus) coupling the memory to the processor. The processor can be, for example, a general-purpose central processing unit (CPU), such as a microprocessor, or a special-purpose processor, such as a microcontroller.

[0072] The memory can include, by way of example but not limitation, random access memory (RAM), such as dynamic RAM (DRAM) and static RAM (SRAM). The memory can be local, remote, or distributed. As used in this paper, the term “computer-readable storage medium” is intended to include only physical media, such as memory. As used in this paper, a computer- readable medium is intended to include all mediums that are statutory, and to specifically exclude all mediums that are non-statutory in nature to the extent that the exclusion is necessary for a claim that includes the computer-readable medium to be valid. Known statutory computer- readable mediums include hardware (e.g., registers, random access memory (RAM), non-volatile (NV) storage, to name a few), but may or may not be limited to hardware.

[0073] The bus can also couple the processor to the non-volatile storage. The non-volatile storage is often a magnetic floppy or hard disk, a magnetic-optical disk, an optical disk, a readonly memory (ROM), such as a CD-ROM, EPROM, or EEPROM, a magnetic or optical card, or another form of storage for large amounts of data. Some of this data is often written, by a direct memory access process, into memory during execution of software on the computer system. The non-volatile storage can be local, remote, or distributed. The non-volatile storage is optional because systems can be created with all applicable data available in memory.

[0074] Software is typically stored in the non-volatile storage. Indeed, for large programs, it may not even be possible to store the entire program in the memory. Nevertheless, it should be understood that for software to run, if necessary, it is moved to a computer-readable location appropriate for processing, and for illustrative purposes, that location is referred to as the memory in this paper. Even when software is moved to the memory for execution, the processor will typically make use of hardware registers to store values associated with the software, and local cache that, ideally, serves to speed up execution. As used in this paper, a software program is assumed to be stored at an applicable known or convenient location (from non-volatile storage to hardware registers) when the software program is referred to as “implemented in a computer- readable storage medium.” A processor is considered to be “configured to execute a program” when at least one value associated with the program is stored in a register readable by the processor. Thus, the processor may include software, hardware, and firmware.

[0075] In one example of operation, a computer system can be controlled by operating system software, which is a software program that includes a file management system, such as a disk operating system. One example of operating system software with associated file management system software is the family of operating systems known as Windows® from Microsoft Corporation of Redmond, Washington, and their associated file management systems. Another example of operating system software with its associated file management system software is the Linux operating system and its associated file management system. The fde management system is typically stored in the non-volatile storage and causes the processor to execute the various acts required by the operating system to input and output data and to store data in the memory, including storing files on the non-volatile storage.

[0076] The bus can also couple the processor to the interface. The interface can include one or more input and / or output (I / O) devices. The I / O devices can include, by way of example but not limitation, a keyboard, a mouse or other pointing device, disk drives, printers, a scanner, and other I / O devices, including a display device. The display device can include, by way of example but not limitation, a cathode ray tube (CRT), liquid crystal display (LCD), or some other applicable known or convenient display device. The interface can include one or more of a modem or network interface. It will be appreciated that a modem or network interface can be considered to be part of the computer system. The interface can include an analog modem, Integrated Services Digital Network (ISDN) modem, cable modem, token ring interface, satellite transmission interface (e.g. “direct PC”), or other interfaces for coupling a computer system to other computer systems. Interfaces enable computer systems and other devices to be coupled together in a network.

[0077] Several components described in this paper, including clients, servers, and engines, can be compatible with or implemented using a cloud-based computing system. As used in this paper, a cloud-based computing system is a system that provides computing resources, software, and / or information to client devices by maintaining centralized services and resources that the client devices can access over a communication interface, such as a network. The cloud-based computing system can involve a subscription for services or use a utility pricing model. Users can access the protocols of the cloud-based computing system through a web browser or other container application located on their client device.

[0078] This paper describes techniques that those of skill in the art can implement in numerous ways. For instance, those of skill in the art can implement the techniques described in this paper using a process, an apparatus, a system, a composition of matter, a computer program product embodied on a computer-readable storage medium, and / or a processor, such as a processor configured to execute instructions stored on and / or provided by a memory coupled to the processor. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used in this paper, the term ‘processor’ refers to one or more devices,circuits, and / or processing cores configured to process data, such as computer program instructions.

[0079] A detailed description of one or more implementations of the invention is provided in this paper along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such implementations, but the invention is not limited to any implementation. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

[0080] Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0081] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system'sregisters and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[0082] Techniques described in this paper relate to apparatus for performing the operations. The apparatus can be specially constructed for the required purposes, or it can comprise a general- purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as, but is not limited to, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.

[0083] Unless the context requires otherwise, throughout the present specification and claims, the word “comprise” and variations thereof, such as, “comprises” and “comprising” are to be construed in an open, inclusive sense, that is as “including, but not limited to.” Recitation of numeric ranges of values throughout the specification is intended to serve as a shorthand notation of referring individually to each separate value falling within the range inclusive of the values defining the range, and each separate value is incorporated in the specification as it were individually recited herein. Additionally, the singular forms “a,” “an” and “the” include plural referents unless the context clearly dictates otherwise. The phrases “at least one of,” “at least one selected from the group of,” or “at least one selected from the group consisting of,” and the like are to be interpreted in the disjunctive (e.g., not to be interpreted as at least one of A and at least one of B).

[0084] Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment, but may be in some instances. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0085] A component being implemented as another component may be construed as the component being operated in a same or similar manner as the other component, and / or comprising same or similar features, characteristics, and parameters as the other component.

Claims

CLAIMS1. A computer-implemented method for estimating a level of service, comprising:(a) retrieving a medical record of a patient seeking medical service;(b) analyzing the medical record to identify problems, data and risk useful to support estimation of a level of service (LoS);(c) displaying, on a user interface, (i) the identified problems, data and risk, (ii) forms for a user to input additional information on the problems, data or risk or edit the identified problems, data or risk, and (iii) an estimated LoS based on the problems, data and risk; and(d) generating an output summarizing the problems, data and risk and the estimated LoS.

2. The method of claim 1, wherein the medical record is analyzed using a machine learning model, which is preferably trained with training data with historic patient data and determined LoS.

3. The method of claim 2, wherein the machine learning model is a neuro network model, a large language model or a generative artificial intelligence model.

4. The method of claim 2, further comprising, identifying potential problems, data or risk and displaying the potential problems, data or risk on the user interface but does not apply the potential problems, data or risk in the estimation of the LoS, until confirmed by the user.

5. The method of claim 4, wherein the potential problems, data or risk has lowered confidence, as determined by the machine learning model, as compared to the identified problems, data or risk.

6. The method of claim 5, wherein the machine learning model is configured to monitoring one or more of (1) editing, by users, the identified problems, data or risk, (2) whether the users confirm the potential problems, data or risk, or (3) edits to the output made by the users.

7. The method of claim 5, further comprising displaying the output or saving the output in a non-transitory medium.

8. The method of claim 5, further comprising displaying a questionnaire taking input from a user that comprises considerations concerning potential medical treatments and / or hospitalizations.

9. A device for estimating a level of service comprising: one or more processors configured to:(a) retrieve a medical record of a patient seeking medical service;(b) analyze the medical record, using a machine learning model, to identify problems, data and risk useful to support estimation of a level of service (LoS);(c) display, on a user interface, (i) the identified problems, data and risk, (ii) forms for a user to input additional information on the problems, data or risk or edit the identified problems, data or risk, and (iii) an estimated LoS based on the problems, data and risk; and(d) generate an output summarizing the problems, data and risk and the estimated LoS.

Images