Treatment planning support system

Abstract

To provide a treatment plan creation support system that enables a diagnosis, additional tests, and suggestions for treatment to be obtained through simple operations in the clinical setting, and also enables an efficient medical plan to be created without oversight depending on the situation. [Solution] The treatment plan creation support means includes at least one of a similar disease definition record document display means for displaying a list of similar disease definition record documents, a similar case data extraction means for extracting and displaying a list of case data of highly similar patients, and an additional examination and treatment method list display means for outputting a list of corresponding additional examinations, treatment plans, evaluation documents, treatment instruction contents, diagnosis names, and treatment results based on prompt input of symptoms, physical findings, and test findings of a new patient.

Description

[Technical Field]

[0001] The present invention relates to a treatment planning support system using search expansion 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 (RAG) approach. The large-scale language model itself is not modified. Additional information is stored in a separate database (the RAG database). The information necessary to solve a question is searched for in the RAG database, and the obtained information is added to the question to obtain an answer from the large-scale language model. While there is a large amount of potentially additional data, the additional information required 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, resulting in low costs and technical hurdles. Furthermore, it offers excellent responsiveness, allowing for the immediate reflection of 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] When a new patient with an unknown diagnosis visits the hospital, the doctor first asks about the patient's age, gender, etc. (case attributes), and listens to their complaints (symptoms). Next, the doctor looks at the patient's facial expressions and movements, touches them to check for pain or lumps (physical examination), and performs general tests such as blood pressure, blood tests, chest X-rays, and electrocardiograms. Based on the test results, a possible diagnosis is predicted, and additional symptoms and physical findings necessary to confirm the diagnosis are obtained, while additional tests are performed to confirm or rule out the diagnosis (differential diagnosis). By repeating these steps, the doctor narrows down the diagnosis to one with the highest probability. There are tens of thousands of possible diagnoses, and the above-mentioned narrowing down process requires a great deal of experience to be carried out efficiently, and the correct diagnosis cannot always be reached. Young doctors lack clinical experience, making it difficult to narrow down possible diagnoses, and they often prescribe numerous unnecessary tests. This increases the cost of the tests and places a physical burden on the patient. On the other hand, experienced doctors run the risk of overlooking relatively rare diseases and conditions by relying on disease patterns they have seen in the past. 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 has been made to solve these conventional problems, and its objectives are to (i) prevent the possibility of relatively rare diseases from being overlooked by searching disease definition documents contained in a large amount of medical literature, (ii) facilitate the search for a diagnosis that matches the characteristics of a medical institution by searching for similar cases from actual past cases, and (iii) provide a large-scale language model that has undergone additional training to estimate a diagnosis, additional tests, and treatment methods from symptoms, physical findings, and general test findings, thereby enabling suggestions for a diagnosis, additional tests, and treatment methods to be obtained with simple operations in the clinical setting, and further provide a medical plan creation support system that, by appropriately combining the above means (i) to (iii), enables the creation of an efficient medical plan that does not overlook anything depending on the situation.

[0014] In addition, a case data database is provided that records the entire cases of patients whose treatment has been completed, and multiple RAG databases (arbitrary portion case data feature vector recording means) are provided that are separate from the case data database and contain optional parts of the case attributes, symptoms, physical findings, and test findings (case feature data) that characterize the case data, which are then extracted and converted into feature vectors and recorded.The RAG database is searched using the feature vectors of patient attributes, symptoms, physical findings, and test data already obtained for patients (target patients) who require the creation of treatment plans, evaluation documents, and treatment instructions, to obtain a group of patients with high similarity.The treatment plans, evaluation documents, and treatment instructions (treatment content data) for this patient group can then be extracted from the case database and analyzed, allowing for the selection, extraction, and utilization of patterns of diagnosis names, treatment plans, evaluation documents, and treatment instructions appropriate for the new patient, based on the attending physician.Furthermore, supervised additional learning is performed on a large-scale language model using pairs of case feature data and treatment methods for the case, making it possible to easily obtain treatment suggestions from the input of the case feature data of a new case. In addition, by converting the additional tests and treatments selected for the patient into an electronic medical record format, it will be possible to smoothly and stress-freely create treatment plans, evaluations, and treatment instructions. [Means for solving the problem]

[0015] As means for achieving the above object, the treatment planning support means of claim 1 comprises the following treatment planning support means in creating a treatment plan. (1) Definition documents for each disease category were recorded. Disease definition document record database Each disease definition record document includes a disease name, case attributes, symptoms, physical findings, test findings, and treatment methods, and any part of the case attributes, symptoms, physical findings, and test findings in the disease definition record document is converted into a feature vector and recorded. Disease definition record document arbitrary part feature vector record database a feature vector corresponding to the case attributes, symptoms, physical findings, and test findings of the arbitrary part of a new patient whose disease classification is unknown (a new patient symptom and finding arbitrary part feature vector creation means); Disease definition record document arbitrary part feature vector record database and a disease definition record document display means for displaying a list of extracted similar disease definition record documents. In the treatment planning support means according to claim 2, The treatment planning support system according to claim 1. In The following treatment plan creation support tools are provided for creating treatment plans: (2) A treatment plan creation support means comprising: a case data recording means for recording case data of patients whose diagnoses have been confirmed and whose treatment has been completed, said case data comprising case characteristic data including at least one of case attributes, symptoms, physical findings, and test data that characterize the case; and treatment content data including at least one of a treatment plan, evaluation document, treatment instructions, diagnosis, treatment results, and attending physician created at the discretion of the therapist; an arbitrary part case data feature vector recording means for converting any part of the case attributes, symptoms, physical findings, and test findings of said case data into feature vectors and recording them; and a similar case data extraction means for searching the arbitrary part case data feature vector recording means using the feature vectors of any part of the case attributes, symptoms, physical findings, and test findings of a new patient, and extracting and displaying a list of case data of patients with high similarities. In the treatment planning support means according to claim 3, The treatment planning support system according to claim 2. In The following treatment plan creation support tools are provided for creating treatment plans: (3) A treatment plan creation support means for supporting the creation of medical plans by performing supervised additional learning on the LLM using pairs of (i) case attributes, symptoms, physical findings, and test findings of patients who have completed treatment and (ii) additional tests, treatment plans created at the discretion of the therapist, evaluation documents, treatment instructions, diagnosis, and treatment results (symptom findings / treatment method additional learning means), and outputting a list of corresponding additional tests, treatment plans, evaluation documents, treatment instructions, diagnosis, and treatment results from the additionally trained LLM in response to prompt input of symptoms, physical findings, and test findings of a new patient.

[0016] Claim 4 In the treatment planning support tool, Claim 1 or 2 The treatment plan creation support system is characterized by comprising a case data extraction means for extracting case attributes, physical findings, and test findings of new patients with unknown diagnoses from electronic medical records.

[0017] Claim 5 stated In the treatment planning support tool, Claim 1 or 2 In the treatment planning support system, for each of the displayed list of similar disease definition records, the list of similar case data, and the list of additional examination and treatment methods, A means for the system operator to select similar disease definition records, similar case data, and additional testing and treatment options appropriate for new cases The present invention is characterized by the following.

[0018] Claim 6 stated In the treatment planning support tool, Claim 5 stated In the treatment planning support system, Similar disease definition records, similar case data, additional testing and treatment methods The present invention is characterized by including an electronic medical record input means for converting the data into an electronic medical record format and inputting the data. [Effects of the Invention]

[0019] Claims 1 to 3This treatment planning support tool (i) searches disease definition documents found in a large amount of medical literature to ensure that relatively rare diseases are not overlooked, (ii) searches for similar cases from past actual cases to facilitate the search for a diagnosis that matches the characteristics of a medical institution, and (iii) prepares a large-scale language model that has undergone additional training to estimate a diagnosis, additional tests, and treatment options from symptoms, physical findings, and general test results, enabling suggestions for a diagnosis, additional tests, and treatment options to be obtained with simple operations in the clinical setting. Furthermore, by appropriately combining the above means (i) to (iii), it is possible to create an efficient medical plan that does not overlook anything depending on the situation.

[0020] Claim 4 The treatment plan creation support means is provided with a case data extraction means, which extracts case attributes, physical findings, and test findings of new patients with unknown diagnoses from electronic medical records.

[0021] Claim 5 stated In the treatment planning support tool, The system operator has a means for selecting similar disease definition records, similar case data, and additional testing and treatment methods suitable for new cases, For each of the displayed list of similar disease definition records, list of similar case data, and list of additional testing and treatment options, The system operator selects similar disease definition records, similar case data, and additional testing and treatment methods appropriate for the new case.

[0022] Claim 6 stated The treatment plan creation support means is provided with an electronic medical record input means, so the selected Similar disease definition records, similar case data, additional testing and treatment methods Convert the data into electronic medical record format and enter it. [Brief explanation of the drawings]

[0023] [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] This shows the typical structure of medical literature for each disease. [Figure 5]This is an explanatory diagram of creating multiple RAGs from a medical literature database to search for similar disease records based on the symptoms, physical findings, and test results of new patients. [Figure 6] 2 shows an example of the structure of case data recorded in a case database (case data recording means). [Figure 7] FIG. 1 is an explanatory diagram illustrating how a group of items (partial case data) constituting case feature data that are the subject of a search for similar cases is extracted from case data, converted into a feature vector, and recorded in an RAG database (RAG database for partial case data). [Figure 8] This 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 need to be created, and then using the treatment plans, evaluation documents, treatment instruction documents, treatment results, and attending physicians of the similar case group found to create an appropriate treatment plan, evaluation document, and treatment instruction document for the target case. [Figure 9] FIG. 10 is an explanatory diagram illustrating additional learning of a large-scale language model by the third treatment planning support means. [Figure 10] FIG. 10 is an explanatory diagram for inputting case characteristic data of a new case and creating proposed treatment content data such as a treatment plan, evaluation document, and proposed treatment instruction document. DETAILED DESCRIPTION OF THE INVENTION

[0024] 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.

[0025] 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.

[0026] 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.

[0027] Recently, in addition to using LLM alone as described above, there has been an increase in cases where LLM itself has an API (Application Programming Interface) 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.

[0028] 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 result in the generation of 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.

[0029] 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. 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.

[0030] 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.

[0031] Another approach is the search expansion generation (RAG) approach (Figure 3). The large-scale language model itself is not changed. The text of additional information sources is cut into small fragments (chunks) as needed, feature vectors are calculated for each chunk, and a separate database is created (RAG database). The size of the chunks is often mechanically cut to a fixed number of characters, but sometimes a unit of meaning is divided into multiple chunks, so the size is changed depending on the case. In the present invention, since parts such as symptoms, physical findings, and test findings have meaning collectively, each part is grouped together to form a chunk. 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).

[0032] 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 increase the size of the list. In some cases, the criteria may be automatically adjusted so that the number of extracted items is equal to the set value, such as the top 10 items.

[0033] 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.

[0034] Figure 4 shows the typical organization of medical literature by disease. The information includes the name of the disease, case attributes such as the age at which it occurs most frequently, gender, region, and race, symptoms reported by patients such as pain, nausea, and fatigue, body temperature, heart rate, blood pressure, weight, and physical findings such as swelling, redness, and tenderness, blood and X-ray findings from general examinations, additional blood tests to confirm the diagnosis, and additional test results such as CT, MRI, and ultrasound, as well as medications and treatments such as surgery for the disease. Medical textbooks are typical, but there are multiple sources of information, such as medical journals dealing with the disease, online information, etc. It is acceptable for each disease to have multiple descriptions from different sources. When searching medical literature for diseases that are likely to be relevant using patient attributes, symptoms, physical findings, and test results obtained from medical records, if the entire literature is converted into a feature vector, it will include information that is not directly related to a search aimed at finding a diagnosis, such as "treatment methods," which can blur the focus and make the search more susceptible to malfunctions such as missing search results or finding literature that is only slightly relevant. This is known as the "Lost in the Middle" problem.

[0035] To avoid this problem, the present invention extracts a group of items that indicate the characteristics of the patient, such as symptoms, physical findings, and test findings, from medical literature, and records each feature vector in the RAG database, as shown in Figure 5. Needless to say, a reference link to the original medical literature is provided for each feature vector. Once the symptoms, physical findings, and general test findings of a new patient with an unknown disease are obtained, each is converted into a feature vector and searched against the corresponding symptom RAG, physical finding RAG, and test finding RAG databases. The intersection of the lists of disease names obtained by each method will be the target list of similar disease definition records. If the list of disease names is too small, a union may be used as appropriate. By using this first treatment planning support means, it is possible to avoid overlooking rare diseases that are difficult to find using other treatment planning support means. Based on the details of the similar disease definition record document that matches the selected new patient, additional symptoms, physical findings, and test results are obtained to confirm the diagnosis, and treatment options such as medication, surgery, and rehabilitation are determined, and an order document is created in the electronic medical record.

[0036] FIG. 6 shows an example of the configuration of case data recorded in the case database (case data recording means) used in the second treatment planning support means. 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.

[0037] "Test results" show the results of tests performed using testing equipment, such as blood test results such as elevated CRP or positive rheumatoid reactions such as RAHA, and X-ray tests such as bone erosion. For images such as X-rays, MRIs, and ultrasounds, medical evaluation of the images themselves is still in the development stage, so instead of the images themselves, you should enter a description of the images. "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. The notation format can be plain text, but JSON, XML, or Markdown formats that clearly show the logical structure are preferable.

[0038] Figure 7 is an explanatory diagram showing how a group of items (partial case data) constituting case characteristic data that are the subject of a search for similar cases is extracted from case data, converted into a feature vector, and recorded in an RAG database (RAG database for partial case data). 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 case data with high similarity.For the extracted group of past case data 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. Here, any part of the case data (partial case data) is converted into a feature vector, but as in the first treatment plan creation support means, feature vectors may be converted for each group of items such as symptoms, physical findings, and test findings, and the intersection set of the list of searched case data may be obtained.

[0039] Although it is possible to convert the entire case data into a feature vector, the data becomes too large, and because 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, making effective searches difficult. This is known as the "lost in the middle" problem.

[0040] By constructing a feature vector using only 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, the data is cut into chunks and converted into RAG, but in the present invention, the data is not cut into chunks, and a feature vector is defined for the entire case feature data. The items constituting the case characteristic data may 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. 7, 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 RAG databases may be constructed for each. 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 8 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 for a target case for which a plan document, evaluation document, and treatment instruction document need to be created, and then using the treatment plan, evaluation document, treatment instruction document, treatment results, and attending physician of the searched similar case group to create an appropriate treatment plan, evaluation document, and treatment instruction document for the target case. First, case data such as that shown in Figure 7 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 (case data extraction means). 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. Using the feature vector of the target case, the RAG database is searched for similar case data (groups) having similar feature vectors. 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. Based on similar case data that matches the selected new patient, additional symptoms, physical findings, and test results are obtained to confirm the diagnosis, and then treatment methods such as medication, surgery, and rehabilitation are decided based on treatment content data such as treatment plans, evaluation documents, and treatment instruction documents, and an order document is created in the electronic medical record (electronic medical record input means).

[0043] The third treatment planning support means is shown in FIG. Case data is extracted from the electronic medical record server, and questions are asked about case attributes, symptoms, physical findings, test findings, etc. that characterize the case. Supervised additional learning is performed on a large-scale language model using the case's disease classification and prescriptions for medication, surgery, rehabilitation, etc. as answers (a symptom and findings / treatment additional learning method). For this additionally trained large-scale language model, as shown in Figure 10, there is provided an additional examination and treatment method list display means that outputs a list of corresponding disease classifications, additional examinations, and treatment methods based on prompt input of symptoms, physical findings, and test findings, which are case characteristic data of new cases. In this way, by creating treatment content data drafts such as treatment plans, evaluation documents, and treatment instruction document drafts, a significant improvement in the efficiency of document creation can be expected. Here, various types of treatment plans, evaluation documents, and treatment instruction documents may be proposed all at once, or proposals may be received for each individual document (treatment plan, treatment evaluation, and treatment instruction proposing means). Furthermore, the system's usefulness will be further enhanced 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 are issued in the electronic medical record all at once.

[0044] The three treatment planning support tools mentioned above are not separate. The first treatment planning support tool utilizes medical literature, and can utilize literature data on all disease classifications, including rare diseases. This is particularly useful for small and medium-sized medical institutions with little experience or a short history. However, because common and rare diseases are treated uniformly, it can be cumbersome for daily medical care. It is also difficult to accommodate individualized care by medical institutions and doctors.

[0045] The second treatment planning support method utilizes case data accumulated within a medical institution or group of medical institutions. It has the advantage of being able to easily respond to the characteristics of each medical institution and the tendencies of each doctor in charge. In addition, the system also supports the creation of treatment plans and evaluation documents required at the clinical site, resulting in significant labor savings. By narrowing down the disease classification to some extent using the first treatment planning support means and then using the second and third treatment planning support means, it becomes possible to support the creation of an efficient treatment plan without overlooking anything.

[0046] The third treatment planning support tool is the easiest to use, but since it requires the accumulation of a certain amount of case data for additional learning, it would be more realistic to first use the first and second treatment planning support tools, and then wait until sufficient case data has been accumulated before moving on to the third treatment planning support tool using additional learning. Note that, due to the nature of large-scale language models, variations in proposals are unavoidable, but conversely, this may lead to suggestions for new treatments. In this way, the first to third treatment planning support methods are complementary, and when used together, they become even more useful.

[0047] 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.

[0048] 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. A treatment planning support system comprising the following treatment planning support means for creating a treatment plan: (1) A treatment plan creation support means comprising: a disease definition document record database in which disease definition documents are recorded for each disease classification, each disease definition record document comprising, in addition to the disease name, case attributes, symptoms, physical findings, test findings, and treatment methods; a disease definition record document arbitrary portion feature vector record database in which any portion of the case attributes, symptoms, physical findings, and test findings of the disease definition record document is converted into a feature vector and recorded; a disease definition record document arbitrary portion feature vector search means for creating a feature vector corresponding to the case attributes, symptoms, physical findings, and test findings of any portion of a new patient with an unknown disease classification (new patient symptom and finding arbitrary portion feature vector creation means); a disease definition record document arbitrary portion feature vector search means for searching the disease definition record document arbitrary portion feature vector record database to search for similar disease definition record documents having similar feature vectors; and a similar disease definition record document display means for displaying a list of the extracted similar disease definition record documents.

2. A treatment plan creation support system as described in claim 1, characterized in that it is equipped with the following treatment plan creation support means in creating a treatment plan. (2) A treatment plan creation support means comprising: a case data recording means for recording case data of patients whose diagnoses have been confirmed and whose treatment has been completed, the case data comprising case characteristic data including at least one of case attributes, symptoms, physical findings, and test data that characterize the case, and treatment content data including at least one of a treatment plan created at the discretion of a therapist, an evaluation document, treatment instructions, a diagnosis, treatment results, and an attending physician; an arbitrary part case data feature vector recording means for converting any part of the case attributes, symptoms, physical findings, and test findings of the case data into feature vectors and recording them; and a similar case data extraction means for searching the arbitrary part case data feature vector recording means using the feature vectors of any part of the case attributes, symptoms, physical findings, and test findings of a new patient, and extracting and displaying a list of case data of patients with high similarities.

3. A treatment plan creation support system as described in claim 2, characterized in that it is equipped with the following treatment plan creation support means in creating a treatment plan. (3) A treatment plan creation support means for supporting the creation of medical plans by providing an additional test and treatment method list display means for performing supervised additional learning on the LLM using pairs of (i) case attributes, symptoms, physical findings, and test findings of patients who have completed treatment and (ii) additional tests, treatment plans created at the discretion of the therapist, evaluation documents, treatment instructions, diagnosis, and treatment results (symptom findings / treatment method additional learning means), and outputting a list of corresponding additional tests, treatment plans, evaluation documents, treatment instructions, diagnosis, and treatment results from the additionally trained LLM in response to prompt input of symptoms, physical findings, and test findings of new patients.

4. 3. The treatment planning support system according to claim 1, further comprising a case data extraction means for extracting case attributes, physical findings, and test findings of new patients with unknown diagnoses from electronic medical records.

5. The treatment planning support system according to claim 1 or 2, characterized in that the system operator is provided with a means for selecting a similar disease definition record, a similar case data, and an additional examination and treatment method suitable for a new case for each of the displayed lists of similar disease definition record documents, similar case data, and additional examination and treatment methods.

6. 6. The treatment plan creation support system according to claim 5, further comprising an electronic medical record input means for converting the selected similar disease definition records, similar case data, and additional examination and treatment methods into an electronic medical record format and inputting them.

Images