Treatment planning, treatment evaluation, and treatment instruction creation support system using search expansion and generation

Abstract

We provide a treatment planning, treatment evaluation, and treatment instruction creation support system that uses search expansion generation in a large-scale language model. [Solution] The system comprises a case data recording means for recording case data of patients for whom treatment has been completed, a feature vector recording means (RAG database) for recording feature vectors obtained by calculation from case feature data, a target patient feature vector calculation means for determining a target patient feature vector obtained by calculation from the case feature data of a target patient for whom treatment will be initiated, a similar case search means for searching the feature vector recording means for case groups having feature vectors similar to the target patient feature vector, and a similar case data group extraction means for extracting case data groups of similar cases having the searched similar feature vectors from the case data recording means.

Description

[Technical Field]

[0001] The present invention relates to a treatment planning, treatment evaluation, and treatment instruction creation support system using search expansion and generation in a large-scale language model. [Background technology]

[0002] In the medical field, the fundamental issues of how to plan blood tests, radiological tests, etc. based on the symptoms reported by the patient and the physical findings (symptoms and findings) obtained by the doctor during the examination, or how to arrive at an accurate diagnosis of the disease by supplementing missing symptoms and physical findings, and how to prescribe highly effective treatment after a diagnosis has been confirmed, are fundamental problems of medical care. Various methods have been tried in the past.

[0003] The first method is to use multivariate analysis. Since the postwar period, attempts have been made to perform discriminant analysis of liver disease using blood test data (Takahashi, Akimasa, 1969, Quantitative Diagnostics, University of Tokyo Press). In those days, when only hand-cranked gear calculators were available, it took several months to calculate the correlation coefficients and eigenvalues ​​between several test data items.

[0004] Advances in computers have made it easy to perform multivariate analysis, but clinical data obtained from medical records consists of at least several thousand symptoms, findings, disease names, and treatments. As a result, the number of items actually entered into medical records is actually quite small. The correlations between elements form a huge matrix of tens of thousands of elements, but most of the elements are sparse matrices with zeros. Such huge sparse matrices suffer from severe rank deficiency, making it difficult to calculate correlation coefficient matrices, let alone eigenvalues. To solve this problem, the frequency (co-frequency) of items where both elements are present is calculated, and this is used to extract items that are highly associated with the disease name. Items with large frequency differences depending on the disease name are considered to be effective items for differentiation, and an index such as Bayesian probability is used to gradually approach a correct diagnosis (Patent Document 1). However, this method using co-frequency requires cumbersome procedures by the user.

[0005] Machine learning has made remarkable progress in recent years, with large-scale language models (LLMs) becoming increasingly widespread. Neural network parameters, numbering in the tens of billions to trillions, are trained on massive amounts of data, amounting to terabytes, to handle tasks such as translation, speech and image recognition, and text summarization. Generative AI, which generates images, music, and documents based on queries, questions, or prompts, is also being put to practical use. It has become known that performance improves by scaling models (scaling laws), and the scale of models is rapidly increasing. By additionally training large amounts of clinical data into large-scale language models and quantifying the relationships between items using attention mechanisms, it is now possible to make diagnoses based on actual clinical symptoms, findings, and test data (Patent Document 2).

[0006] As the range of applications of large-scale language models expands, knowledge data from various fields is required. Furthermore, with social conditions and technological advances in each field, there is a need to constantly incorporate the latest knowledge data. However, training large amounts of data requires large-scale computational resources, enormous amounts of electricity, and costs. For this reason, large-scale language models cannot be reconstructed frequently. When large-scale language models are queried, they can generate answers that are not based on facts, even if they do not have the necessary knowledge stored internally. This phenomenon, known as hallucination, has limited their widespread use in fields such as medicine, where errors can lead to serious accidents.

[0007] In order to utilize large-scale language models based on the latest information in the field, it is necessary to obtain additional up-to-date information, and two approaches are currently being used. The first is called additional training (fine tuning) or transfer learning, in which additional information is used to train part of the output layer of an existing large-scale language model (fine tuning) or only the final layer (transfer learning) to create a specialized large-scale language model. This is highly useful as it results in a domain-specific large-scale language model. However, while it is not as costly as training a large-scale language model from scratch, it does require a certain amount of cost and technical skill for training.

[0008] Another approach is the RAG Retrieval-Augmented Generation approach used in this invention. The large-scale language model itself is not modified. Additional information is stored in a separate database (RAG database), and the information necessary to solve a question is searched for in the RAG database. The obtained information is added to the question, and an answer is obtained from the large-scale language model. Although there is a large amount of potentially additional data, the additional information necessary to answer a given question is limited. Therefore, only this limited additional information is searched for in the RAG database, and the extracted additional information (context) is added to the question in the question input box of the large-scale language model. This approach does not involve any learning changes to the large-scale language model itself; it simply adds context information to the question input box, thereby reducing costs and technical hurdles. Furthermore, it offers excellent responsiveness, such as the ability to immediately reflect urgent information, such as information on emergency drug side effects (Non-Patent Document 1, Non-Patent Document 2).

[0009] The RAG database is a database created by cutting document information to be added into small fragments (chunks) as needed, and then converting each chunk into a feature vector (chunk vector). When asking a question, the question itself is also vectorized, and chunk vectors with a high similarity to the vector of the question are searched for in the RAG database, and the contents of the obtained chunk group are added to the question. This makes it possible to respond to specific fields and the latest information without the need for expensive additional training of large-scale language models, and by limiting the basis for responses to questions to the RAG database, hallucinations can be prevented (Patent Document 3). Prior art documents relevant to this application include the following: [Prior art documents] [Patent documents]

[0010] [Patent Document 1] Patent No. 6792750 "Diagnosis Support System" [Patent Document 2] Patent No. 7592232 "Diagnosis and prescription support system using large-scale language models" [Patent Document 3] Patent application no. 2024-226197 "Large-scale language model using search expansion generation" [Patent Document 4] Patent No. 7441391 "Electronic medical record system using large-scale language models" [Patent Document 5] Patent No. 6902693 "Document Creation System"

[0011] [Non-Patent Document 1] https: / / ja.wikipedia.org / wiki / %E5%A4%A7%E8%A6%8F%E6%A8%A1%E8%A8%80%E8%AA%9E%E3%83%A2%E3%83%87%E3%83%AB [Non-patent document 2] https: / / www.idnet.co.jp / column / page_308.html Summary of the Invention [Problem to be solved by the invention]

[0012] In clinical settings, not only are patients' records and test orders required, but a large amount of documentation is also required, including treatment plans for doctors, nurses, rehabilitation specialists, and registered dietitians, as well as recording and evaluating the results of implementing those plans. The time and effort required to create documentation related to plans, evaluations, and treatment instructions accounts for at least 30% of staff time, causing increased fatigue. AI technology utilizing RAG is expected to reduce this workload. However, when attempting to build and search a RAG database using the feature vectors of all the clinical data actually obtained from patients, and recording the symptoms, findings, test results, treatment plans, evaluations, and treatment instructions of patients who have already been diagnosed and treated, the data becomes too large for each record, causing the focus of the feature vector to become blurred, making it difficult to match the feature vectors of the case data for which treatment and evaluation plans are to be created. Planning and evaluation patterns differ for each medical staff member, including doctors, and uniform planning and evaluation does not easily reflect the planning and evaluation patterns of each staff member, so in the field, it is time-consuming to customize plans and evaluations individually.

[0013] The present invention aims to solve these problems and provides a case data database that records all cases of patients who have completed treatment, and a separate RAG database that extracts and stores feature vectors of patient attributes, symptoms, physical findings, and test data (case characteristic data) that characterize the case data. The RAG database is then searched using the feature vectors of patient attributes, symptoms, physical findings, and test data already obtained for patients (target patients) who require the development of treatment plans, evaluations, and treatment instructions, to obtain a group of patients with high similarity. The treatment plans, evaluations, and treatment instructions (treatment content data) for this group of patients are extracted from the case data database and analyzed to provide useful information for creating appropriate treatment plans, evaluations, and treatment instructions. Furthermore, the present invention selectively extracts and utilizes treatment plan, evaluation, and treatment instruction content patterns based on diagnosis, treatment results, and attending physician. Furthermore, the selected treatment plans, evaluations, and treatment instructions are input into a large-scale language model, enabling stress-free and smooth development of treatment plans, evaluations, and treatment instructions. [Means for solving the problem]

[0014] As a means for achieving the above object, the treatment planning, treatment evaluation, and treatment instruction creation support system according to claim 1 includes: (1) a case data recording means for recording case data of patients whose treatment has been completed; (2) the case data characterizing the cases; Case characteristics data including patient demographics, symptoms, physical findings, and test data and treatment content data including at least one of a treatment plan created by the therapist's judgment, an evaluation, treatment instructions, a diagnosis, treatment results, and a doctor in charge, (3) A feature vector recording means (RAG database) for recording feature vectors calculated from the case feature data, (4) A target patient feature vector calculation means for determining a target patient feature vector calculated from the case feature data of a target patient for whom treatment is to be initiated, (5) A similar case search means for searching the feature vector recording means for case groups having feature vectors similar to the target patient feature vector, and (6) A similar case data group extraction means for extracting case data groups of similar cases having the searched similar feature vectors from the case data recording means.

[0015] The treatment plan, treatment evaluation, and treatment instruction creation support system described in claim 2 is characterized in that, in the treatment plan, treatment evaluation, and treatment instruction creation support system described in claim 1, it is equipped with a case data extraction means for extracting some or all of the case data from the electronic medical record.

[0016] The treatment plan, treatment evaluation, and treatment instruction creation support system described in claim 3 is characterized in that, in the treatment plan, treatment evaluation, and treatment instruction creation support system described in claim 1 or 2, it is provided with a similar case data filter means for selecting relevant similar case data from the extracted similar case data group using at least one of the diagnosis name, treatment result, and attending physician.

[0017] The treatment plan, treatment evaluation, and treatment instruction creation support system described in claim 4 is characterized in that the treatment plan, treatment evaluation, and treatment instruction creation support system described in claim 3 is further provided with a treatment plan, treatment evaluation, and treatment instruction proposal means that inputs the case data group obtained by the similar case data filter means into a large-scale language model and creates proposals for the treatment plan, treatment evaluation, and treatment instruction content.

[0018] The treatment plan, treatment evaluation, and treatment instruction creation support system described in claim 5 is characterized in that, in the treatment plan, treatment evaluation, and treatment instruction creation support system described in claim 4, it is provided with an electronic medical record input means for converting the proposed treatment plan, treatment evaluation, and treatment instruction content into an electronic medical record format and inputting it. [Effects of the Invention]

[0019] The treatment plan, treatment evaluation and treatment instruction creation support system according to claim 1 includes a case data recording means, which records case data of patients whose treatment has been completed. Case data characterizes cases Case characteristics data including patient demographics, symptoms, physical findings, and test data and treatment content data including at least one of a treatment plan created at the discretion of the therapist, evaluation, treatment instruction content, diagnosis name, treatment result, and attending physician. The feature vector recording means is provided, and records the feature vector calculated from the case feature data. The system is provided with a target patient characteristic vector calculation means, which determines a target patient characteristic vector that can be calculated from the case characteristic data of the target patient for whom treatment is to be started. The similar case search means is provided, and a group of cases having feature vectors similar to the target patient feature vector is searched from the feature vector recording means. The similar case data group extraction means extracts case data groups of similar cases having similar feature vectors from the case data recording means.

[0020] The treatment plan, treatment evaluation and treatment instruction creation support system according to claim 2 is provided with a case data extraction means, which extracts part or all of the case data from the electronic medical record.

[0021] The treatment plan, treatment evaluation, and treatment instruction creation support system described in claim 3 is equipped with a similar case data filter means, which selects relevant similar case data from the extracted similar case data group using at least one of the diagnosis, treatment result, and attending physician.

[0022] The treatment plan, treatment evaluation, and treatment instruction creation support system described in claim 4 is equipped with a treatment plan, treatment evaluation, and treatment instruction content proposing means, which inputs a group of case data obtained by the similar case data filtering means into a large-scale language model to create a proposal for a treatment plan, treatment evaluation, and treatment instruction content.

[0023] The treatment plan, treatment evaluation and treatment instruction creation support system according to claim 5 includes an electronic medical record input means, so that the proposed treatment plan, treatment evaluation and treatment instruction contents are converted into the format of the electronic medical record and input. [Brief explanation of the drawings]

[0024] [Figure 1] 1 illustrates an embodiment of a network configuration according to the present invention. [Figure 2] This is an example of a user interface for a large-scale language model (LLM). [Figure 3] We show the general relationship between large-scale language models and RAG databases. [Figure 4] The structure of case data is shown below. [Figure 5] This is an example of an inpatient treatment plan. [Figure 6] This is an example of a nursing plan. [Figure 7] This is an example of a risk assessment document. [Figure 8] This indicates the portion of the case data that will be registered in the RAG database and searched. [Figure 9] This shows the process of searching for similar cases from the RAG database using the case attributes, symptoms, physical findings, and feature vectors of test results of the target cases for which a plan / evaluation document needs to be created, extracting the treatment plans, evaluation documents, treatment results, and attending physicians for the similar cases, and creating appropriate treatment plans, evaluation documents, and treatment instruction documents. DETAILED DESCRIPTION OF THE INVENTION

[0025] FIG. 1 shows a typical system configuration of the present invention. Large-scale language models consist of huge amounts of data, numerous CPUs (Central Processing Units), GPUs (Graphics Processing Units), and high-speed networks connecting them, so they are built on huge servers such as cloud data centers and provided via the web. In hospitals and other facilities, many PC terminals are connected via a LAN (Local Area Network) connected to the web. There are also servers within the hospital that operate electronic medical records. In recent years, there has been an increasing number of cases where people use mobile devices such as smartphones and tablets to access cloud services such as large-scale language models and electronic medical records while moving around the hospital or from outside the hospital.

[0026] Servers, terminals, and mobile devices all consist of memory for recording programs and data, recording media such as hard disks that permanently record said programs and data as needed, a CPU that reads and processes said programs and data, a GPU that performs high-speed parallel processing as needed, and a communication module. As cloud services become more stable and cheaper, there are increasing cases of people migrating some or all of their electronic medical records to the cloud. Conversely, there is also a movement underway to move some or all of the large-scale language models to servers or terminals installed within hospitals with increased processing capabilities and storage capacity (edge ​​computing). Furthermore, the development of small-scale language models, which limit the number of parameters in the language model, is also progressing. Note that, although they are small-scale, they are still sufficiently large compared to the time before the advent of large-scale language models, and any embodiment, including this form, is included in the present invention.

[0027] Figure 2 shows an example of a user interface for a large-scale language model (LLM). LLMs are currently being rapidly developed, and many models have been developed, including ChatG PT (a registered trademark of OpenAI), Bard, LaMDA (a registered trademark of Google), and LLaMA (a registered trademark of Meta). Any LLM is included in the scope of this invention. Naturally, the user interface will differ, but typically, as shown in Figure 2, it consists of a box (prompt input box) for inputting prompts to instruct and inquire of the LLM, a box (answer display box) for displaying the answers to those prompts, and a box (usage history box) for displaying the history of prompts and answers as a usage log.

[0028] Recently, in addition to using LLMs alone as described above, there has been an increase in cases where LLMs themselves have APIs (Application Programming Interfaces) and LLM functions are used from external software. In this case, prompts, answers, and history are input and output to and from external software via API, so the display format is not limited to that shown in Figure 2 and is controlled by the external software.

[0029] In large-scale language models, to represent a certain vocabulary, a one-hot vector is used, which is a long vector consisting of zeros with the same number of dimensions as the number of types of vocabulary used, with a single 1 placed in the position corresponding to the vocabulary in question. All the vocabulary in a large amount of literature is replaced with vectors of this format, and deep learning is used to determine the associations (attention) between each vocabulary vector.In response to a query (prompt), vocabulary that is likely to appear next to the query and the answer sentences that have already been generated is generated and added one by one to create an answer sentence. If the information from which answers are generated is contained in the large amount of literature, it is expected that correct sentences that are rational and highly useful will be generated. However, if the information on which the answer is generated is not contained in the large amount of literature, the answer generation process will proceed by mechanically adopting vocabulary with a high probability, which is known to generate false answers that are not based on any evidence (hallucination). If this hallucination occurs in medical settings or other settings, it could pose a risk to the patient's life, which is one of the reasons why the application of large-scale language models to core business processes has not progressed.

[0030] Training large-scale language models requires large-scale servers equipped with a large number of parallel computing units (GPUs), as well as a large amount of electricity and money, in order to read a large amount of documents and use deep learning to find relationships between vocabulary words. New documents are generated every day, and it is not realistic to reflect all of them in a large-scale language model without any time delay. Furthermore, the large amount of documents that are scanned are mainly public documents that are available on the web, etc., but they do not include sensitive information such as internal company documents or hospital electronic medical records, so it is said that the documents that can be collected are only a small portion of the total documents that exist on Earth.

[0031] In order to utilize large-scale language models based on the latest information in the field, it is necessary to obtain additional up-to-date information, and two approaches are currently being taken. One is called additional learning (fine tuning) or transfer learning, which uses additional information to train part of the output layer of an existing large-scale language model (fine tuning) or only the final layer (transfer learning), resulting in a specialized large-scale language model. It is a domain-specific large-scale language model and is therefore highly useful, but it does require a certain amount of cost and technical skill for learning, although not as much as training a large-scale language model from scratch. Furthermore, because the additional information contains sensitive information such as personal information and descriptions of medical conditions, there is a risk that it may be accessed outside the organization. To prevent this, it is necessary to build and operate a large-scale, additionally trained language model exclusively within your own company or hospital.

[0032] Another approach is the Search Extension Generation (RAG) approach used in the present invention (Figure 3). The large-scale language model itself is not changed. The text of the additional information is cut into small fragments (chunks) as needed, and feature vectors are calculated for each chunk and stored in a separate database (RAG database). The system calculates the feature vector of the question, searches for the information needed to solve the question based on the similarity between the feature vector of the question and the feature vector of the chunks recorded in the RAG database, adds the text information of the chunks found to be highly similar to the question, and searches for an answer in a large-scale language model (Figure 3).

[0033] The degree of similarity between feature vectors is often expressed by the magnitude of the inner product between the vectors (cosine similarity), but the Manhattan distance, which is the sum of the absolute values ​​of the differences between the elements of both vectors, may also be used. The threshold value of the degree of similarity that serves as the extraction standard is variable depending on the situation. If the extracted list is too large, you can narrow it down by raising the criteria, or if the list is too small, you can lower the criteria to make the list larger. In some cases, you can set the top 10 items, etc., and automatically adjust the criteria so that the number of items extracted matches the set value.

[0034] Even if there is a large amount of data in a related field, the additional information required to answer a certain question is limited. Therefore, only this limited additional information is searched for in the RAG database, and the additional information contained in the extracted chunks is added to the question (context) in the question input box of the large-scale language model. This approach does not involve any changes to the large-scale language model itself through learning, but simply adds contextual information to the question input box, which keeps costs and technical hurdles low. Furthermore, it is highly responsive, being able to immediately reflect information of high urgency, such as information on emergency side effects of drugs.

[0035] FIG. 4 shows an example of the configuration of case data recorded in the case database. Case data includes case attributes, symptoms, physical findings, test results, the diagnosis obtained from the above, the treatment plan that was planned and used, the contents of evaluation documents, treatment procedures such as medication, surgical treatment, and rehabilitation, the final treatment results, and the name of the treating physician. "Case attributes" are used to identify cases at the medical institution, such as patient ID, age, and gender. Depending on the disease, age and gender may be important. "Symptoms" is a list of the patient's subjective complaints. "Physical findings" are objective physical findings noticed by doctors and medical staff, such as body temperature and swelling of joints, tenderness, etc. This information is mainly obtained by doctors and nurses in the examination room.

[0036] "Test Results" shows the results of tests performed using testing machines, such as blood test results such as elevated CRP or positive rheumatoid reactions such as RAHA, X-rays such as bone erosion, etc. For images such as X-rays, MRIs, and ultrasounds, enter a description of the image. "Diagnosis" is the confirmed disease name, such as rheumatoid arthritis. "Plans and evaluation documents" are the group of contents written in medical treatment plans prepared by doctors, nursing care plans prepared by nurses, rehabilitation plans prepared by rehabilitation staff, and evaluation documents that record the results of treatment. "Treatment" refers to treatments given for the disease, such as administered medication, surgery, rehabilitation, etc. "Treatment outcome" refers to the extent to which the patient's condition improved as a result of the treatment. The "physician in charge" is the so-called attending physician, who is responsible for the treatment of the patient.

[0037] Figure 5 is an example of an inpatient treatment plan. Figure 6 is an example of a nursing care plan. Figure 7 is an example of a risk assessment document. There are hundreds of different types of plans, evaluation documents, and treatment instruction documents created in medical care. Various surcharges are set out in medical fees, and as a requirement for calculating these surcharges, it is essential to create documents that prove that the relevant action was performed. This results in a huge amount of document creation work.

[0038] In principle, case data should be based on actual cases, but in the case of rare diseases with low incidence, it is useful to deliberately record typical data from fictitious cases of the rare disease, as this can suggest the possibility of the rare disease during the diagnostic process. The notation format can be plain text, but JSON, XML, or Markdown formats that clearly show the logical structure are preferable.

[0039] FIG. 8 is an explanatory diagram illustrating how a group of items constituting case feature data to be searched for similar cases is extracted from case data, converted into feature vectors, and recorded in the RAG database. For the target case (target case) for which a treatment plan, evaluation document, and treatment instructions are to be prepared, item group data (case characteristic data) are registered in the RAG database to perform searches that will serve as clues for extracting similar case data from past case data groups. The case feature data of the target case is converted into a feature vector, and the feature vectors are compared with those of past cases registered in the RAG database to extract a group of past cases with high similarity.For the extracted group of past cases with high similarity, the case ID# is used to reference item data (treatment content data) such as the diagnosis name, treatment plan, evaluation document, treatment content, treatment results, and attending physician of the case data.

[0040] Although it is possible to convert the entire case data into a feature vector, the data becomes too large, and since the diagnosis, treatment plan, evaluation document, treatment content, treatment results, and attending physician are all parts that can be manipulated by the therapist, the focus of the case feature vector becomes blurred, and this is not necessarily useful.In terms of multiple regression analysis, the case feature data corresponds to the explanatory variable, and the treatment content data corresponds to the objective variable. By constructing a feature vector using only the case attributes, symptoms, physical findings, and test results that indicate the characteristics of the case, it becomes possible to search for similar case data in a more focused manner. Normally, data is cut into chunks and converted into RAG, but in this invention, the data is not cut into chunks, and a feature vector is defined for the entire case feature data. The items that make up the case characteristic data can be any combination of items that represent the characteristics of the case. For example, depending on the medical institution, it may be more reasonable to include items such as the surgical method performed in the case characteristic data when extracting cases. That is, the items included in the RAG are not limited to those shown in Fig. 8 and may be changed depending on the situation. In addition, in order to use different features, multiple patterns of case feature data may be prepared and each RAG database may be constructed. The case ID# is simply a reference number to the case recorded in the case database, and is not necessarily required if the sequences of the cases in the case database and the RAG database are identical.

[0041] Figure 9 shows the process of searching for similar cases in the RAG database using the case attributes, symptoms, physical findings, and feature vectors of test results for a target case for which a plan document, evaluation document, and treatment instruction document need to be created, and then creating an appropriate treatment plan, evaluation document, and treatment instruction document for the target case using the treatment plan, evaluation document, treatment instruction document, treatment results, and attending physician of the similar case group found. First, case data such as that shown in Figure 8 is extracted from the medical records (electronic or paper) of cases for which treatment has been completed. In this case, although it is possible to manually input each item of data, it is more preferable to extract it from the electronic medical record using a technique such as that shown in Patent Document 5. The case data of the extracted treatment-completed cases is recorded in a case database (case data recording means). The case characteristic data of each case is converted into a characteristic vector and recorded in a characteristic vector recording means (RAG database).

[0042] The case feature data is extracted from the target case for which a treatment plan, evaluation document, and treatment instruction document are to be created, and converted into a feature vector.The feature vector of the target case is used to search the RAG database for similar case(s) with similar feature vectors. The treatment content data, such as treatment plans, evaluation documents, and treatment instruction documents, for case data with highly similar feature vectors are listed. At this point, useful suggestions for creating treatment plans, evaluation documents, and treatment instruction documents can already be obtained. Furthermore, by using this system as a means of filtering similar case data and excluding data on cases with "poor" treatment outcomes or cases with different diagnoses, it is possible to improve the accuracy of creating treatment plans, evaluation documents, and treatment instruction documents that are expected to produce even better treatment outcomes. In addition, by narrowing down the cases by the attending physician, it is possible to understand the trends in the creation of treatment plans, evaluation documents, and treatment instruction documents for each attending physician. By inputting the "reference case data" that has passed through such filters into a large-scale language model and creating treatment plans, evaluation documents, and draft treatment instruction documents, it is expected that the efficiency of document creation will be significantly improved. Here, various types of treatment plans, evaluation documents, and treatment instruction documents can be proposed all at once, or proposals can be received for each individual document (treatment plan, treatment evaluation, and treatment instruction proposal means).Furthermore, if the document text of the proposed treatment plan, evaluation document, and treatment instruction document is converted into the format of each document in the electronic medical record, and document creation or treatment prescription orders can be issued in the electronic medical record all at once, the usefulness will be further increased.

[0043] Furthermore, since there is a risk of information leakage if the content entered into the prompt is used to train a large-scale language model, it is useful to explicitly declare in the prompt that learning is prohibited, or to use a paid version of a large-scale language model that is guaranteed not to be used for learning, or even to use a large-scale language model that has been independently constructed within the medical institution.

[0044] Although the embodiments have been described above, the specific configuration of the present invention is not limited to the above-described embodiments, and the present invention also includes design changes and the like that do not deviate from the gist of the invention.

Claims

1. (1) a case data recording means for recording case data of patients whose treatment has been completed; (2) The case data includes case characteristic data including patient attributes, symptoms, physical findings, and test data that characterize the case, and treatment content data including at least one of a treatment plan created by the therapist's judgment, evaluation, treatment instructions, diagnosis, treatment results, and attending physician; (3) A feature vector recording means (RAG database) for recording a feature vector calculated from the case feature data, (4) A target patient characteristic vector calculation means is provided for calculating a target patient characteristic vector obtained by calculation from case characteristic data of a target patient for whom treatment is to be initiated; (5) A similar case search means for searching the feature vector recording means for a group of cases having a feature vector similar to the target patient feature vector, (6) A treatment planning, treatment evaluation, and treatment instruction creation support system characterized by comprising a similar case data group extraction means for extracting case data groups of similar cases having the searched similar feature vectors from the case data recording means.

2. 2. The treatment planning, treatment evaluation and treatment instruction creation support system according to claim 1, further comprising a case data extraction means for extracting a part or all of the case data from the electronic medical record.

3. 3. The treatment plan, treatment evaluation, and treatment instruction creation support system according to claim 1, further comprising a similar case data filter means for selecting corresponding similar case data from the extracted similar case data group using at least one of diagnosis, treatment result, and attending physician.

4. 4. The treatment plan, treatment evaluation, and treatment instruction creation support system according to claim 3, further comprising a treatment plan, treatment evaluation, and treatment instruction proposal means for inputting the case data group obtained by the similar case data filter means into a large-scale language model and creating a proposal for the treatment plan, treatment evaluation, and treatment instruction contents.

5. 5. A treatment plan, treatment evaluation and treatment instruction creation support system according to claim 4, further comprising an electronic medical record input means for converting the proposed treatment plan, treatment evaluation and treatment instruction contents into an electronic medical record format and inputting the converted contents.

Images