Diagnostic and prescription support system using search and extended generation

JP2026125439AActive Publication Date: 2026-08-03INST OF MEDICAL INFORMATION TECH CO LTD
View PDF 4 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
INST OF MEDICAL INFORMATION TECH CO LTD
Filing Date
2025-01-22
Publication Date
2026-08-03

AI Technical Summary

Benefits of technology

【0020】 請求項1記載の診断、処方支援システムでは、症例データ記録手段を備えるので、診断名既知患者の症例データを記録する。 任意部分ごと特徴ベクトル記録手段を備えるので、症例データの任意部分を抽出して得られる特徴ベクトルを記録する特徴ベクトル記録手段を任意部分ごとに備える。 症例データ抽出手段を備えるので、診断名未知患者の症例データから任意部分を抽出して特徴ベクトル化し任意部分ごと特徴ベクトル記録手段から特徴ベクトルの類似した症例群を抽出し、抽出された症例群の症例データを症例データ記録手段から抽出する。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026125439000001_ABST
    Figure 2026125439000001_ABST
Patent Text Reader

Abstract

This system provides a diagnostic and prescription support system that extracts and analyzes clinical data from patient groups from a clinical data database, thereby providing appropriate information at each stage of diagnosis and prescription. [Solution] The diagnostic and prescription support system includes a case data recording means for recording case data of patients with known diagnoses, a feature vector recording means for each arbitrary part for recording feature vectors obtained by extracting arbitrary parts of the case data, and a case data extraction means for extracting arbitrary parts from case data of patients with unknown diagnoses, converting them into feature vectors, extracting case groups with similar feature vectors from the feature vector recording means for each arbitrary part, and extracting case data of the extracted case groups from the case data recording means.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to a diagnosis and prescription support system using retrieval augmented generation in a large language model.

Background Art

[0002] In the medical field, based on the symptoms described by patients and the physical findings (symptom findings) obtained by doctors through examinations, how to formulate an examination plan such as blood tests and radiation tests, or how to supplement the insufficient symptoms and physical findings to reach an accurate diagnosis of the disease name, and further how to prescribe highly effective treatment after the diagnosis is confirmed are fundamental issues in medicine. Various methods have been tried conventionally.

[0003] The first is a method using multivariate analysis. Since the post-war period, discriminant analysis of liver diseases has been attempted using blood test data (Takahashi Kosei, 1969, Metrological Diagnosis, University of Tokyo Press). In an era when there were only manual gear-type computers, it took several months to calculate the correlation coefficients and eigenvalues between several items of test data.

[0004] With the progress of electronic computers, multivariate analysis itself has become easy to perform. However, clinical data obtained from medical records consists of at least thousands of symptoms, findings, disease names, and treatment actions. Therefore, the items actually entered in the medical records are rather few. The correlation between elements becomes an extremely large matrix of tens of thousands by tens of thousands, but it becomes a sparse matrix with most items being 0. Such an extremely large sparse matrix has a severe rank reduction of the matrix, and it is difficult to calculate the correlation coefficient matrix, let alone the eigenvalues. To solve this problem, the frequency (co-frequency) is obtained for those in which two elements are aligned, and this is used to extract items highly related to the disease name. Items with a large frequency difference depending on the disease name are used as discriminatively effective items, and gradually indicators such as Bayesian probability are used to approach an accurate diagnosis (Patent Document 1). However, the method using this co-frequency required a cumbersome procedure by the user.

[0005] In recent years, machine learning has advanced remarkably, with the widespread adoption of large-scale language models (LLMs) in particular. These models, with tens of billions to trillions of neural network parameters trained on terabytes of data, are now capable of handling tasks such as translation, speech and image recognition, and text summarization. Furthermore, generative AI that generates images, music, and documents based on inquiries, questions, or prompts is also becoming increasingly practical. It has become known that scaling models improves performance (scaling laws), leading to a rapid increase in model size. By further training large-scale language models with the aforementioned massive amounts of clinical data, and quantifying the relationships between items using attention mechanisms, it is becoming possible to diagnose actual symptoms, findings, and test data obtained in clinical settings (Patent Document 2).

[0006] As the applications of large-scale language models expand, knowledge data from various fields becomes necessary, and the incorporation of the latest knowledge data is required at all times, in line with social conditions and technological advancements in each field. However, training with large amounts of data requires massive computing resources, enormous electricity, and significant costs. For this reason, the reconstruction of large-scale language models cannot be done frequently. A phenomenon known as hallucination is known to occur when large-scale language models are questioned, resulting in the generation of fact-inaccurate responses even if the necessary knowledge to answer the question is not stored internally. This is one reason why the widespread use of such models is limited in fields such as medicine, where errors can directly lead to accidents.

[0007] To effectively utilize large-scale language models based on the latest information in real-world applications, additional up-to-date information is necessary, and currently, two approaches are being taken. One is called additional learning (fine-tuning) or transfer learning, where additional information is used to train a portion of the output layer (fine-tuning) or only the final layer (transfer learning) of an existing large-scale language model, creating a specialized large-scale language model. As it becomes a domain-specific large-scale language model, its usefulness is high. However, even if it is not as complex as training a large-scale language model from scratch, it still requires considerable expense and technical skills for training.

[0008] Another approach is the RAG Retrieval-Augmented Generation (RAG) approach used in this invention. The model of 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 the question is retrieved from the RAG database. The obtained information is added to the question, and the large-scale language model is asked to produce an answer. Even if there is a large amount of data that could potentially be added, the additional information required to answer a given question is limited. Therefore, only that limited additional information is retrieved from the RAG database, and the extracted additional information (context) is added to the question in the question input field of the large-scale language model. In this approach, no changes are made to the model of the large-scale language model itself through learning; only contextual information is added to the question input field, resulting in lower costs and technical hurdles. Furthermore, it offers excellent responsiveness, such as being able to immediately reflect highly urgent information, such as urgent drug side effect information (Non-Patent Literature 1), (Non-Patent Literature 2).

[0009] Here, the RAG database is created by breaking down the additional document information into small fragments (chunks), and then vectorizing each chunk into feature vectors (chunk vectors) and creating a database. When a question is asked, the question itself is also vectorized, and chunk vectors with a high similarity to the vector of the question are searched from the RAG database. The contents of the obtained chunk group are then added to the question. This makes it possible to handle specific fields and the latest information without requiring additional training of a costly large-scale language model, and by limiting the basis for the answer to the question to the RAG database, it is possible to prevent hallucinations (Patent Document 3). The following are prior art documents related to this application. [Prior art documents] [Patent Documents]

[0010] [Patent Document 1] Japanese Patent Publication No. 6792750, "Diagnostic Support System" [Patent Document 2] Japanese Patent Publication No. 7592232, "Diagnosis and Prescription Support System Using a Large-Scale Language Model" [Patent Document 3] Japanese Patent Application No. 2024-226197, "Large-scale language model using search extension generation" [Patent Document 4] Japanese Patent Publication No. 7441391, "Electronic Medical Record System Using a Large-Scale Language Model"

[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 [Overview of the project] [Problems that the invention aims to solve]

[0012] When attempting to construct and search a RAG database using the feature vectors of the entire clinical data of patients actually obtained, (1) the data for each patient, such as symptoms, findings, test results, and treatment methods, becomes too large. As a result, the focus of the feature vector becomes blurred, and matching with the feature vectors of case data for cases with unknown diagnoses is not successful. (2) Multiple provisional diagnoses are inferred from symptom findings, tests necessary to differentiate these provisional diagnoses are obtained, and additional symptom findings that should be acquired are obtained, and after the diagnosis is confirmed, the treatment method appropriate for that diagnosis is determined. In this way, diagnosis and treatment prescription are carried out in stages. However, it is difficult to handle the staged diagnosis and prescription decision-making process described above using the feature vectors of the entire clinical data of patients. (3) There are still many unresolved problems with current large-scale language models, such as insufficient image recognition and retrieval. (4) Because it is difficult to reflect the diagnosis and prescription patterns of each medical staff member, including doctors, it becomes necessary to individually customize the orders for tests and prescriptions at the site.

[0013] The present invention was made to solve the aforementioned problems of the past, and its objective is to provide a clinical data database that records the entire clinical data of a patient, and separately, multiple RAG databases for each arbitrary portion of the patient's clinical data, which are extracted, converted into feature vectors, and recorded. When proceeding with the diagnosis and prescription stages for patients with an unknown diagnosis, the present invention searches the corresponding RAG database using the obtained feature vectors of the clinical data of the patient with an unknown diagnosis to obtain a set of patients with known diagnoses that have a high degree of similarity. By extracting the clinical data of this patient group from the clinical data database and performing analysis, appropriate information according to each stage of diagnosis and prescription is provided. Furthermore, by inputting information such as images of patients with an unknown diagnosis as text from the clinical data database, it becomes possible to search for information that is currently insufficiently addressed. In addition, by extracting and utilizing order patterns for diagnosis and prescription for each staff member, such as a physician, it becomes possible to enable stress-free and smooth order entry. [Means for solving the problem]

[0014] As a means to achieve the above objective, the diagnostic and prescription support system according to claim 1 is characterized by comprising: a case data recording means for recording case data of patients with known diagnoses; a feature vector recording means for each arbitrary part for recording feature vectors obtained by extracting arbitrary parts of the case data; a case data extraction means for extracting arbitrary parts from case data of patients with unknown diagnoses, converting them into feature vectors, extracting case groups with similar feature vectors from the feature vector recording means for each arbitrary part; and extracting case data of the extracted case groups from the case data recording means.

[0015] The diagnostic and prescription support system according to claim 2 is characterized in that, in the diagnostic and prescription support system according to claim 1, the system extracts case data of similar cases using acquired case attributes, symptoms, and physical findings of patients with an unknown diagnosis as an optional part, and includes means for suggesting a provisional diagnosis, tests useful for confirming the diagnosis, tests that suggest additional symptoms and physical findings that are useful to acquire, additional symptoms, and additional physical findings.

[0016] The diagnostic and prescription support system according to claim 3 is characterized in that, in the diagnostic and prescription support system according to claim 1 or 2, it extracts case data of similar cases using case attributes, symptoms, physical findings, and test results obtained as a result of the means for suggesting tests, additional symptoms, and additional physical findings, and provides means for suggesting a provisional diagnosis, additional tests useful for confirming a diagnosis, additional tests useful for confirming additional symptoms, and additional physical findings useful for additional acquisition, and provides means for confirming a diagnosis, which repeats the means for suggesting additional tests, additional symptoms, and additional physical findings until a diagnosis is confirmed.

[0017] In the diagnosis and prescription support system according to claim 4, in the diagnosis and prescription support system according to claim 3, case data of similar cases is extracted using the diagnosis name obtained as a result of the diagnosis name determination means, the obtained case attributes, symptoms, physical findings, and examination results, and a treatment method suggestion means for suggesting a treatment method with good results using the obtained treatment method and treatment results is provided.

[0018] In the diagnosis and prescription support system according to claim 5, in the diagnosis and prescription support system according to claim 2 or 3, in the examination, additional symptom, and additional physical finding suggestion means, and the additional examination, additional symptom, and additional physical finding suggestion means, at least an examination order issuing means for issuing an examination order to an electronic medical record is provided.

[0019] In the diagnosis and prescription support system according to claim 6, in the diagnosis and prescription support system according to claim 4, the treatment method suggestion means is provided with a treatment prescription order issuing means for issuing a treatment prescription order to an electronic medical record.

Advantages of the Invention

[0020] In the diagnosis and prescription support system according to claim 1, since a case data recording means is provided, case data of patients with known diagnosis names is recorded. Since a feature vector recording means for each arbitrary part is provided, a feature vector recording means for each arbitrary part for recording a feature vector obtained by extracting an arbitrary part of case data is provided. Since a case data extraction means is provided, an arbitrary part is extracted from the case data of a patient with an unknown diagnosis name, vectorized into a feature vector, a group of cases with similar feature vectors is extracted from the feature vector recording means for each arbitrary part, and the case data of the extracted case group is extracted from the case data recording means.

[0021] In the diagnosis and prescription support system according to claim 2, since an examination, additional symptom, and additional physical finding suggestion means is provided, case data of similar cases is extracted using the obtained case attributes, symptoms, and physical findings of a patient with an unknown diagnosis name as an arbitrary part, and an examination useful for determining a provisional diagnosis name and a diagnosis name, additional symptoms and physical findings useful for obtaining are suggested.

[0022] In the diagnostic and prescription support system according to claim 3, since it is provided with means for suggesting additional examinations, additional symptoms, and additional physical findings, case data of similar cases are extracted using the case attributes, symptoms, physical findings, and examination results obtained from the results of the examinations, additional symptoms, and means for suggesting additional physical findings, and additional examinations and additional acquisitions of symptoms and physical findings useful for determining the preliminary diagnosis name and diagnosis name are suggested. Since it is provided with a diagnosis name determination means, the above-mentioned additional examinations, additional symptoms, and means for suggesting additional physical findings are repeated until the diagnosis name is determined.

[0023] In the diagnostic and prescription support system according to claim 4, since it is provided with treatment method suggestion means, case data of similar cases are extracted using the diagnosis name obtained from the results of the diagnosis name determination means, the obtained case attributes, symptoms, physical findings, and examination results, and a treatment method with good results is suggested using the obtained treatment method and treatment results.

[0024] In the diagnostic and prescription support system according to claim 5, since it is provided with examination order issuance means, at least an examination order is issued to the electronic medical record in the examinations, additional symptoms, means for suggesting additional physical findings, and the above-mentioned additional examinations, additional symptoms, and means for suggesting additional physical findings.

[0025] In the diagnostic and prescription support system according to claim 6, since it is provided with treatment prescription order issuance means, a treatment prescription order is issued to the electronic medical record in the treatment method suggestion means.

Brief Description of the Drawings

[0026] [Figure 1] This is an example of the network configuration of the present invention. [Figure 2] This is an example of a user interface in a large language model (LLM). <( [Figure 3] This shows a general relationship between a large language model and a RAG database. [Figure 4] This shows the relationship between multiple RAG databases and a case database of the present invention. [Figure 5] This shows the configuration of case data. [Figure 6] This document describes the structure of a RAG database for partial case data, in which arbitrary parts (partial case data) are extracted from case data as needed, converted into feature vectors, and recorded in a feature vector database. [Figure 7] Based on the obtained case attributes, symptoms, and physical findings, this document outlines the next tests to be performed for provisional diagnosis and differential diagnosis, as well as the steps to suggest additional symptoms and physical findings that may be useful. [Figure 8] This document outlines the procedure for reaching a definitive diagnosis by repeatedly using additional symptoms, physical findings, and test results. [Figure 9] This is the procedure for searching for treatment prescriptions after a diagnosis has been confirmed. [Modes for carrying out the invention]

[0027] Figure 1 shows a typical system configuration of the present invention. Since large-scale language models consist of massive amounts of data, numerous CPUs (Central Processing Units), GPUs (Graphics Processing Units), and a high-speed network connecting them, they are built within large servers such as cloud data centers and provided via the Web. Hospitals and similar institutions have numerous PC terminals connected via a Local Area Network (LAN) that is connected to the web. Hospitals also have servers that operate electronic medical records. In recent years, there has been an increasing trend of using mobile devices such as smartphones and tablets to access cloud services such as large-scale language models and electronic medical records while moving around within the hospital or from outside the hospital.

[0028] Servers, terminals, and mobile terminals all consist of memory for storing programs and data, recording media such as hard disks for persistently storing the programs and data as needed, a CPU for reading and processing the programs and data, a GPU for high-speed parallel processing as appropriate, and communication modules. As cloud services become more stable and affordable, there is a growing trend of migrating some or all of electronic medical records to the cloud. Conversely, there is also a growing movement to move some or all of large-scale language models to servers and terminals installed within hospitals that have increased processing power and memory capacity (edge ​​computing). Furthermore, the development of small-scale language models with a limited number of parameters is also progressing. It should be noted that even these small-scale models are still quite large compared to those developed before the emergence of large-scale language models, and all embodiments, including this form, are included in the present invention.

[0029] Figure 2 shows an example of a user interface in a Large-Scale Language Model (LLM). LLM is currently under rapid development, with numerous models being created, including ChatG PT (a registered trademark of OpenAI), Bard, LaMDA (a registered trademark of Google), and LLaMA (a registered trademark of Meta). While the user interface will naturally differ, the standard configuration, as shown in Figure 2, consists of a prompt input field for entering instructions and inquiries to the L LM, a field for displaying the response to that prompt, and a field for displaying the history of prompts and responses as a usage log.

[0030] Recently, in addition to using LLM as a standalone tool as described above, there has been an increasing trend for LLM itself to have an API (Application Programming Interface), allowing its functions to be used by external software. In this case, prompts, responses, and history are input and output to and from external software via an API, so the display format is controlled by the external software and is not limited to Figure 2.

[0031] In large-scale language models, a one-hot vector is used to represent a vocabulary word. This vector consists of zeros with the same number of dimensions as the number of vocabulary words used, and a single 1 is placed at the position corresponding to that vocabulary word. The vocabulary of a large volume of literature is replaced entirely with vectors of this format, and the relationships (Attention) between each vocabulary vector are determined using deep learning. Then, for each query (prompt), the vocabulary that is most likely to follow the query and the already generated partial response is generated and added one word at a time to create the response. If the information used to generate the response is contained in the aforementioned large volume of literature, it is expected that a rational, useful, and correct sentence will be generated. However, if the information used to generate the response is not included in the aforementioned large volume of literature, the system will mechanically select vocabulary with a high probability of success, resulting in the generation of false responses that are not based on evidence (hallucination). When these hallucinations occur in medical settings, they can endanger patients' lives, which is one of the reasons why the application of large-scale language models to core business operations has not progressed.

[0032] Training large-scale language models requires massive servers, including a large number of parallel processing units (GPUs), as well as significant electricity resources and costs, to process large amounts of documents and use deep learning to determine relationships between vocabulary words. New documents are created every day, but it's not realistic to reflect all of them in a large-scale language model without any time lag. Furthermore, while the vast amount of documents scanned are primarily publicly available documents published on the web and other platforms, they do not include sensitive information such as internal company documents or electronic medical records from hospitals. Therefore, it is said that the documents that can be collected represent only a small fraction of all documents existing on Earth.

[0033] To effectively utilize large-scale language models based on the latest information in real-world applications, additional up-to-date information is required, and currently, two approaches are being taken. One approach is called additional learning (fine-tuning) or transfer learning, which involves using additional information to train a portion of the output layer (fine-tuning) or only the final layer (transfer learning) of an existing large-scale language model, thereby creating a specialized large-scale language model. While these domain-specific, large-scale language models are highly useful, they still require a considerable amount of investment and technical skill, even if it's not as complex as training a large-scale language model from scratch. Furthermore, because sensitive information such as personal details and descriptions of medical conditions included in the additional information is used for training, 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 language model with additional training exclusively within the company or hospital.

[0034] Another approach is the Search-Augmented Generator (RAG) approach used in this invention (Figure 3). The model of the large-scale language model itself is not changed. The text of the additional information is cut into small fragments (chunks), a feature vector is calculated for each chunk, and a separate database is created (RAG database). The feature vector of the question is calculated, and the information necessary to solve the question is searched based on the similarity between the feature vector of the question and the feature vectors of the chunks recorded in the RAG database. The text information of the chunks obtained with high similarity is added to the question, and the large-scale language model is asked to produce an answer.

[0035] The degree of approximation between feature vectors is often expressed by the magnitude of the dot product between the vectors (cosine similarity), but the Manhattan distance, which is the sum of the absolute differences of each element of the two vectors, can also be used. The size of the approximation threshold used as the basis for extraction is variable depending on the situation. If the extracted list is too large, you can raise the criteria to narrow it down; if the list is too small, you can lower the criteria to increase the list size. In some cases, you can set the criteria to the top 10, for example, and automatically adjust the criteria so that the number of extracted items matches the set value.

[0036] Even if there is a large amount of potentially additional data, the additional information required to answer a given question is limited. Therefore, only that limited additional information is searched from the RAG database, and the additional information contained in the extracted chunks is appended to the question text (context) in the question input field of the large-scale language model. This approach involves no changes to the large-scale language model itself through training; it simply adds contextual information to the question input field, resulting in lower costs and technical hurdles. Furthermore, it excels in responsiveness, being able to immediately reflect highly urgent information such as emergency drug side effect information.

[0037] Figure 4 shows the relationship between the multiple RAG databases (RA databases separated by partial case data) and the case database of the present invention. The objective is to create feature vectors from case data obtained at a certain point in time for patients for whom a diagnosis has been confirmed and treatment prescriptions are to be issued, and then to search for case data of diagnosed patients that have feature vectors similar to those obtained. As shown in Figure 5, the case data for diagnosed patients is enormous. If this entire large amount of case data is converted into feature vectors all at once, too much information will be crammed in, including information irrelevant to the search objective, thus reducing the accuracy of the search. Therefore, the standard RAG system shown in Figure 3 has limitations.

[0038] To resolve this situation, the present invention extracts any part (chunk) useful for searching case data, obtains its feature vector, and constructs multiple RAG databases corresponding to each of the aforementioned arbitrary parts (RA databases for each part of case data, (A), (B), (C)… in Figure 4). A separate case database containing a large amount of data for each case is constructed, and the RAG database assigns a reference address to the case database for each individual feature vector. Using this reference address (reference # in Figure 5), all data for the case corresponding to the extracted chunk can be obtained from the case database. In the conventional RAG shown in Figure 3, article content was stored within chunks, and the content of chunks with similar feature vectors was used for subsequent processing. In the present invention, the RAG (RA database by partial case data) is solely for searching, and when a group of cases with similar feature vectors is found, the case data for those cases is referenced in the case database.

[0039] Figure 5 shows an example of the structure of case data. The case number is the reference address for the case in the case database. "Case attributes" are used to identify cases, including patient ID, age, and gender at the medical institution in question. For some diseases, age and gender can be important factors. Doctors may have their own preferences regarding tests and prescriptions. "Symptoms" are a list of the patient's subjective complaints. "Physical findings" refer to objective physical findings such as body temperature and joint swelling and tenderness noticed by doctors and medical staff. "Tests" refers to the results of tests performed using medical equipment, such as blood test results (e.g., elevated CRP, positive rheumatoid arthritis reactions like RAHA) and X-rays (e.g., bone erosion). For images such as X-rays, MRIs, and ultrasounds, enter a descriptive text about the image to facilitate future searches. The "diagnosis" is the name of a confirmed disease, such as rheumatoid arthritis. "Treatment" refers to any treatment given for the disease in question, such as administered medication, surgery, or rehabilitation. "Treatment outcome" indicates how much the patient's condition improved as a result of the aforementioned treatment. While case data should ideally consist of real cases, in the case of rare diseases with low incidence, recording typical data for a fictional case of that rare disease can be useful as it can suggest the possibility of the disease during the diagnostic process. While plain text is acceptable, JSON, XML, and Markdown formats, which clearly indicate the logical structure, are preferable. A mix of formats is permitted as appropriate.

[0040] Figure 6 shows the structure of the RAG database for individual case data, where arbitrary parts (partial case data) are extracted from case data as needed, converted into feature vectors, and recorded in the RAG database. By doing this, when calculating feature vectors from data obtained for cases with unknown diagnoses, it becomes possible to perform focused and highly accurate searches for similar cases. The method for collecting partial case data is not limited to the example shown in Figure 6, and can be arbitrarily set according to the situation.

[0041] Figure 7 shows the steps to take to perform subsequent tests, additional symptoms, and physical findings that may be useful for provisional or differential diagnosis, based on the obtained case attributes, symptoms, and physical findings. For cases with an unknown diagnosis, once the case attributes, symptoms, and physical findings are obtained, the broker program (Figure 4) performs a case search using the RAG database shown in Figure 6(A). It then sets multiple provisional diagnoses from the known diagnostic names in the obtained case data set and suggests tests, additional symptoms, and physical findings that are useful for confirming the provisional diagnosis (differential diagnosis). Here, the tests, additional symptoms, and physical findings that are useful for confirming a provisional diagnosis are those tests, symptoms, and physical findings that show a large difference in the frequency of positive or negative findings among provisional diagnoses. Positive / negative results for tests, symptoms, and physical findings with significant frequency differences can narrow down the provisional diagnosis and increase the likelihood of reaching a definitive diagnosis. Furthermore, if the attending physician has a history of specific tests, symptoms, or physical findings, these should be given priority consideration. The additional symptoms, physical findings, and suggested test results obtained are added to the original case attributes, symptoms, and physical findings and provided to the procedure in Figure 8. Here, the obtained case attributes, symptoms, and physical findings may be provided to Figure 8 as is and unprocessed, or they may be organized using a broker program or summarized using a large-scale language model before being provided to Figure 8.

[0042] In Figure 8, the Figure 4 broker program features vectors of the examination findings, original symptoms, additional symptoms, and physical findings obtained in Figure 7, searches the RAG database (B) in Figure 6, and searches for similar cases. Review the case attributes, symptoms, physical findings, test results, and diagnosis of the searched group of cases. If a definitive diagnosis has not yet been reached, add test findings, symptoms, and physical examinations and repeat the cycle shown in Figure 8. Here again, if the attending physician has a history of specific tests, symptoms, or physical examinations, prioritize considering those tests, symptoms, and physical examinations. Here too, the obtained case attributes, symptoms, and physical findings can be used to make a definitive diagnosis based on visual inspection alone, or they can be processed using a broker program or summarized using a large-scale language model before a definitive diagnosis is made. Diagnosis is a matter of the physician's sole responsibility, and the system of this invention provides physicians with the information they need to make that judgment. The diagnosis is confirmed when the physician becomes confident in its accuracy. If a definitive diagnosis is obtained with sufficient accuracy, proceed to the procedure shown in Figure 9. Here, by providing a means for issuing test orders to the electronic medical record in the aforementioned tests, additional symptoms, and additional physical findings suggestions, or the aforementioned means for issuing additional tests, additional symptoms, and additional physical findings suggestions, an efficient diagnostic procedure becomes possible.

[0043] Figure 9 shows a procedure that suggests treatment prescriptions after a diagnosis has been confirmed. Figure 4 shows that the broker program features vectorized the confirmed diagnosis, case attributes, symptoms, physical findings, and test results of cases that were previously undiagnosed. It then searches the RAG database (C) in Figure 6 to obtain treatment prescriptions and treatment outcomes for similar cases. The system suggests treatment prescriptions with favorable outcomes, and the physician issues a treatment prescription in the electronic medical record system. While it is acceptable to search for treatment prescriptions and outcomes using only the confirmed diagnosis, the optimal treatment method is influenced and varies depending on the patient's symptoms, physical findings, and test results. Therefore, the aforementioned search method is preferable. If the attending physician has a pattern of past treatment prescriptions, those prescriptions should be given priority consideration. The obtained treatment prescriptions can be used directly for treatment prescription suggestions, or they can be organized using a broker program, or summarized using a large-scale language model before being used for treatment prescription suggestions. Here, if the aforementioned treatment suggestion means uses a treatment order issuing means to issue treatment prescription orders to the electronic medical record, and the treatment prescription orders are automatically issued to the electronic medical record, a significant reduction in labor can be achieved.

[0044] As shown in Figures 7 to 9, if the RAG database is used to search for similar cases and the case data of those cases is simply listed and organized, then the objective may be achieved without using a large-scale language model, in which case the diagnostic name, additional symptoms to be addressed, physical findings, and tests can be suggested. This case is also included in the present invention. Furthermore, since there is a risk of information leakage if the content entered in the prompt is used to train a large-scale language model, it is useful to explicitly declare in the prompt that training is prohibited, or to use a paid version of a large-scale language model that guarantees that the content will not be used for training.

[0045] Although embodiments have been described above, the specific configuration of the present invention is not limited to the embodiments described above, and design changes and the like that do not depart from the spirit of the invention are also included in the present invention.

Claims

1. A case data recording means for recording case data of patients with known diagnoses. The system includes a feature vector recording means for each arbitrary portion, which is provided for recording a feature vector obtained by extracting an arbitrary portion of the case data. From the case data of patients with an unknown diagnosis, an arbitrary portion is extracted and converted into a feature vector, and for each arbitrary portion, a group of cases with similar feature vectors is extracted from the feature vector recording means. A diagnostic and prescription support system characterized by comprising a case data extraction means for extracting case data of the extracted case group from the case data recording means.

2. The diagnostic and prescription support system according to claim 1, characterized in that, as the aforementioned optional part, it extracts case data of similar cases using acquired case attributes, symptoms, and physical findings of patients with an unknown diagnosis, and includes means for suggesting a provisional diagnosis, tests useful for confirming the diagnosis, tests that suggest additional symptoms and physical findings that are useful to acquire, additional symptoms, and additional physical findings.

3. The diagnostic and prescription support system according to claim 1 or 2, characterized in that it includes means for extracting case data of similar cases using case attributes, symptoms, physical findings, and test results obtained as a result of the aforementioned tests, additional symptoms, and additional physical findings suggestion means, which includes means for suggesting a provisional diagnosis, additional tests useful for confirming a diagnosis, additional tests useful for obtaining additional symptoms and physical findings, and means for confirming a diagnosis, which repeats the means for suggesting additional tests, additional symptoms, and additional physical findings until a diagnosis is confirmed.

4. The diagnostic and prescription support system according to claim 3, characterized in that it includes a means for extracting case data of similar cases using the diagnostic name obtained as a result of the diagnostic name determination means, obtained case attributes, symptoms, physical findings, and test results, and a means for suggesting treatment methods with good results using the obtained treatment methods and treatment outcomes.

5. The diagnostic and prescription support system according to claim 2 or 3, characterized in that the means for suggesting the tests, additional symptoms, and additional physical findings, and the means for suggesting the additional tests, additional symptoms, and additional physical findings, are further provided with at least a means for issuing a test order to an electronic medical record.

6. The diagnostic and prescription support system according to claim 4, characterized in that the treatment suggestion means includes a treatment prescription order issuing means for issuing a treatment prescription order to an electronic medical record.