Diagnosis and prescription assistance system

Abstract

[Problem] To search a corresponding RAG database by using a feature vector of available clinical data of a patient with an unknown diagnosis name, and to obtain a list of patients with known diagnosis names and high similarities, when proceeding with the diagnosis and prescription stages for the patient with an unknown diagnosis name. The present invention provides appropriate information corresponding to each stage of the diagnosis and prescription by extracting clinical data of a patient group from a database of clinical data and performing an analysis. [Solution] This system is provided with: a case data recording means for recording case data of a patient with a known diagnosis name; and a feature vector recording means for each arbitrary portion, provided with a feature vector recording means for recording a feature vector derived from extracting an arbitrary portion of case data, at each of the arbitrary portions. This system is further provided with a case data extracting means which extracts the arbitrary portion from the case data of a patient with an unknown diagnosis name and vectorizes the arbitrary portion into a feature vector, extracts a case group with a similar feature vector from the feature vector recording means for each arbitrary portion, and extracts the case data of the extracted case group from the case data recording means.

Description

Diagnosis and Prescription Support System

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

[0002] In the medical field, how to formulate an examination plan such as a blood test or a radiation test from the symptoms described by the patient and the physical findings (symptom findings) obtained by the doctor's examination, or how to reach an accurate diagnosis of the disease name by supplementing the insufficient symptoms and physical findings, and furthermore, 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 Akira, 1969, Metrological Diagnosis, University of Tokyo Press). In an era when there were only hand-cranked gear computers, it took several months to calculate the correlation coefficients and eigenvalues between several items of examination 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 record are rather few. The correlation between elements becomes an extremely large matrix of tens of thousands by tens of thousands, but most of the items become a sparse matrix with 0s. Such an extremely large sparse matrix has a severe rank degradation, 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 with two aligned elements, and the items highly related to the disease name are extracted using this. Items with a large frequency difference depending on the disease name are regarded 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 cumbersome procedures 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, which generates images, music, and documents based on inquiries, questions, or prompts, is also becoming increasingly practical. It has become known that scaling up models improves performance (scaling laws), leading to a rapid increase in model size. By adding large amounts of clinical data to large-scale language models for further training, 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 on large amounts of data requires massive computing resources, enormous electricity, and expense. For this reason, large-scale language models cannot be rebuilt frequently. A phenomenon called hallucination is known to occur when a large-scale language model is questioned and generates a response that is not based on facts, even if the knowledge necessary to answer the question is not stored internally. This is one of the reasons why the widespread use of large-scale language 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.

[0008] Another approach is the 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 necessary 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 creating a database of each chunk by vectorizing its features (chunk vectors). 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.

[0010] Japanese Patent Publication No. 6792750 "Diagnostic Support System", Japanese Patent Publication No. 7592232 "Diagnosis and Prescription Support System Using a Large-Scale Language Model", Japanese Patent Application No. 2024-226197 "Large-Scale Language Model Using Search Extension Generation", Japanese Patent Publication No. 7441391 "Electronic Medical Record System Using a Large-Scale Language Model"

[0011] 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%ABhttps: / / www.idnet.co.jp / column / page_308.html

[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 the symptoms and findings, tests necessary to differentiate these provisional diagnoses are obtained, and additional symptoms and findings that should be acquired are obtained, and after the diagnosis is confirmed, a 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 conventional approach, 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 uses the obtained feature vectors of the clinical data of the patient with an unknown diagnosis to search the corresponding RAG database and 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, the present invention provides appropriate information according to each stage of diagnosis and prescription. 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.

[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 recording feature vectors obtained by extracting arbitrary parts of the case data, each of which is provided as an arbitrary part feature vector recording means; 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; extracting case data of similar cases using acquired case attributes, symptoms, and physical findings of patients with unknown diagnoses as the arbitrary parts; and a 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.

[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, it extracts case data of similar cases using the case attributes, symptoms, physical findings, and test results obtained as a result of the means for suggesting the tests, additional symptoms, and additional physical findings, and provides means for suggesting additional tests, additional symptoms, and additional physical findings that are useful for determining a provisional diagnosis and confirming the diagnosis, and means for suggesting additional tests, additional symptoms, and additional physical findings that are useful to obtain, and provides means for determining a diagnosis that repeats the means for suggesting additional tests, additional symptoms, and additional physical findings until the diagnosis is determined.

[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 2, it includes a treatment suggestion means that extracts 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 suggests a treatment method with good results using the obtained treatment method and treatment results.

[0017] The diagnostic and prescription support system according to claim 4 is characterized in that, in the diagnostic and prescription support system according to claim 2, the means for suggesting tests, additional symptoms, and additional physical findings, and the means for suggesting additional tests, additional symptoms, and additional physical findings, are provided with at least a means for issuing test orders to the electronic medical record.

[0018] The diagnostic and prescription support system according to claim 5 is characterized in that, in the diagnostic and prescription support system according to claim 3, the treatment method suggestion means is provided with a treatment prescription order issuing means for issuing a treatment prescription order to the electronic medical record.

[0019] The diagnostic and prescription support system according to claim 1 includes a case data recording means for recording case data of patients with known diagnoses. It also includes a feature vector recording means for each arbitrary portion, which records feature vectors obtained by extracting arbitrary portions of case data. It includes a case data extraction means, which extracts arbitrary portions from case data of patients with unknown diagnoses, converts them into feature vectors, extracts groups of cases with similar feature vectors from the feature vector recording means for each arbitrary portion, and extracts case data of the extracted groups of cases from the case data recording means. It also includes a means for suggesting tests, additional symptoms, and additional physical findings, which extracts case data of similar cases using acquired case attributes, symptoms, and physical findings of patients with unknown diagnoses as arbitrary portions, and suggests provisional diagnoses, tests useful for confirming diagnoses, and additional symptoms and physical findings that are useful to acquire.

[0020] The diagnostic and prescription support system according to claim 2 includes means for suggesting additional tests, additional symptoms, and additional physical findings. Using the case attributes, symptoms, physical findings, and test results obtained as a result of the means for suggesting tests, additional symptoms, and additional physical findings, case data of similar cases is extracted, and a provisional diagnosis, additional tests useful for confirming the diagnosis, and additional symptoms and physical findings useful for obtaining are suggested. The system also includes means for confirming the diagnosis, and the means for suggesting additional tests, additional symptoms, and additional physical findings are repeated until the diagnosis is confirmed.

[0021] The diagnostic and prescription support system described in claim 3 includes means for suggesting treatment methods. It extracts case data of similar cases using the diagnostic name obtained as a result of the diagnostic name determination means, the obtained case attributes, symptoms, physical findings, and test results, and suggests treatment methods with good results using the obtained treatment methods and treatment outcomes.

[0022] The diagnostic and prescription support system according to claim 4 includes means for issuing test orders, and at least the means for suggesting tests, additional symptoms, and additional physical findings, and the means for suggesting additional tests, additional symptoms, and additional physical findings, issue test orders to the electronic medical record.

[0023] The diagnostic and prescription support system described in claim 5 includes means for issuing treatment prescription orders, and the means for suggesting treatment methods issues treatment prescription orders to the electronic medical record.

[0024] This is an embodiment of the network configuration of the present invention. This is an example of a user interface in a Large-Scale Language Model (LLM). This shows the general relationship between the Large-Scale Language Model and the RAG database. This shows the relationship between multiple RAG databases and case databases of the present invention. This shows the structure of case data. This shows the structure of a RAG database for partial case data in which arbitrary parts (partial case data) are extracted from the case data as needed, feature vectorized, and recorded in the feature vector database. This shows a procedure that suggests the next tests to be performed for provisional diagnosis and differential diagnosis, as well as additional symptoms and physical findings that may be useful, based on the obtained case attributes, symptoms, and physical findings. This shows a procedure that leads to a definitive diagnosis by repeatedly using the additionally obtained symptoms, physical findings, and test results. This shows a procedure for searching for treatment prescriptions after the diagnosis has been confirmed.

[0025] The diagnostic and prescription support system according to the present invention comprises a server device, a database, and a terminal. The server device is a known computer device and comprises an arithmetic unit, main memory, auxiliary storage device, input device, output device, and communication device. The arithmetic unit, main memory, auxiliary storage device, input device, output device, and communication device are connected to each other via a bus interface. The arithmetic unit comprises a known processor capable of executing an instruction set. The main memory comprises volatile memory such as RAM capable of temporarily storing the instruction set. The auxiliary storage device comprises non-volatile data storage capable of recording the OS and programs. The data storage may be an HDD or an SSD, for example. The input device may be a keyboard or mouse, for example. The output device may be a display such as an LCD, for example. The communication device comprises a network interface capable of connecting to a network. The server device includes means such as case data recording means, feature vector recording means, feature vector recording means for arbitrary parts, case data extraction means, means for suggesting tests, additional symptoms, additional physical findings, additional tests, additional symptoms, additional physical findings, means for confirming a diagnosis, means for suggesting a treatment method, means for issuing a test order, and means for issuing a treatment prescription order. The processor of the server device exerts the effects of these means. The database according to the present invention may be configured in the auxiliary storage device of the server device, or it may be configured in a separate auxiliary storage device independent of the server device. The database stores information handled by the diagnosis and prescription support system. The terminal according to the present invention has the same known computer hardware configuration as the server device. The server device, database, and terminal according to the present invention are communicable via a network.

[0026] 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. In hospitals, numerous PC terminals are connected via a LAN (Local Area Network) connected to the Web. Hospitals also have servers operating electronic medical records. In recent years, there has been an increase in cases where mobile devices such as smartphones and tablets are used 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.

[0027] Servers, terminals, and mobile terminals all consist of memory for recording 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 cheaper, there is an increasing trend to migrate some or all of electronic medical records to the cloud. Conversely, there is also a movement to move some or all of large-scale language models to servers and terminals installed within hospitals with increased processing power and memory capacity (edge ​​computing). Furthermore, the development of small-scale language models with a reduced number of parameters is also progressing. It should be noted that even small-scale models are still sufficiently large compared to those before the emergence of large-scale language models, and all embodiments, including this form, are included in the present invention.

[0028] Figure 2 shows an example of a user interface for a Large-Scale Language Model (LLM). LLMs are currently under rapid development, with numerous models being developed, 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 interfaces naturally differ, the standard configuration, as shown in Figure 2, consists of a prompt input field for entering instructions and inquiries to the LLM, a response display field for displaying the answer to that prompt, and a usage history field for displaying the history of prompts and answers as a usage log.

[0029] Recently, in addition to using LLM as a standalone application as described above, there has been an increase in cases where LLM itself is equipped with an API (Application Programming Interface), allowing external software to utilize LLM's functions. In this case, prompts, responses, and history are input and output between the external software and the LLM via the API, so the display format is controlled by the external software and is not limited to Figure 2.

[0030] 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 amount of literature is replaced with vectors of this type, and the relationships (Attention) between each vocabulary vector are determined using deep learning. For a query (prompt), the model generates and adds vocabulary words one by one that are highly likely to follow the query and the already generated partial answer sentence to create the answer sentence. If the information used to generate the answer is contained in the large amount of literature, it is expected that a rational, useful, and correct sentence will be generated. However, if the information used to generate the answer sentence is not contained in the large amount of literature, the model mechanically selects the vocabulary words with high probability and proceeds with generating the answer sentence, which is known to generate false answers that are not based on evidence (hallucination). If this hallucination occurs in a medical setting, it can endanger the patient's life, and this is one of the reasons why the application of large-scale language models to core business operations has not progressed.

[0031] 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 vast amounts of documents and use deep learning to determine relationships between vocabulary words. While new documents are created daily, it is not realistic to reflect all of them in large-scale language models without any delay. Furthermore, the vast amount of documents processed mainly consists of publicly available documents on the web, but 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 that exist on Earth.

[0032] To effectively utilize large-scale language models based on the latest information in the field, additional up-to-date information is required, and currently two approaches are being taken. One is called additional learning (fine-tuning) or transfer learning, where additional information is used to train only a part 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. While this results in a domain-specific large-scale language model with high utility, it still requires considerable expense and technical skills, even if not as extensive as training a large-scale language model from scratch. Furthermore, sensitive information such as personal information and descriptions of medical conditions included in the additional information is used for training, posing a risk of it being accessed outside the organization. To prevent this, it is necessary to exclusively build and operate the additionally trained large-scale language model within the company or hospital.

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

[0034] The degree of similarity 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 both vectors, can also be used. The magnitude of the similarity threshold used as the basis for extraction is variable depending on the situation. If the extracted list is too large, the threshold can be raised to narrow it down, and if the list is too small, the threshold can be lowered to increase the size of the list. In some cases, the threshold can be set to the top 10, for example, and the system can automatically adjust the threshold so that the number of extracted items matches the set value.

[0035] Even if there is a large amount of potentially additional data, the additional information required to answer a given question is limited. Therefore, this approach searches the RAG database for only that limited additional information and adds the extracted chunks of additional information to the question text (context) in the question input field of the large-scale language model. This approach does not involve any changes to the large-scale language model itself through training, and only adds contextual information to the question input field, thus keeping costs and technical hurdles low. Furthermore, it offers excellent responsiveness, such as immediately reflecting highly urgent information like urgent drug side effect information.

[0036] 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 purpose is to convert case data obtained at a certain point in time into feature vectors for patients for whom a diagnosis has been confirmed and treatment prescriptions are to be made, and then to search for case data of diagnosed patients that have feature vectors similar to those feature vectors. Here, the case data of diagnosed patients is enormous, as shown in Figure 5. If this large amount of case data is converted into feature vectors all at once, too much information will be packed in, including information unrelated to the purpose of the search, and the accuracy of the search will decrease. For this reason, the standard RAG system shown in Figure 3 has limitations.

[0037] To resolve this issue, 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 (partial case data-specific RA databases, (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 included within the chunks, and the content of chunks with similar feature vectors was used for subsequent processing. In the present invention, the RAG (partial case data-specific RA database) is solely for searching, and when a group of cases with similar feature vectors is found, the case data for those cases is accessed through the case database.

[0038] Figure 5 shows an example of the structure of case data. Case # is the reference address for the case in the case database. "Case Attributes" are used to identify the case, such as the patient ID, age, and gender at the medical institution. Depending on the disease, age and gender may be of significant importance. There may be differences in the types of tests and prescriptions given by the attending physician. "Symptoms" is a list of the patient's subjective complaints. "Physical Findings" are objective physical findings noticed by the doctor or medical staff, such as body temperature, joint swelling, and tenderness. "Tests" show the results of tests using medical equipment, such as blood test results like elevated CRP and positive rheumatoid arthritis reactions like RAHA, and X-rays showing bone erosion, etc. For images such as X-rays, MRIs, and ultrasounds, a description of the image should be entered to facilitate future searches. "Diagnosis" is the confirmed disease name, such as rheumatoid arthritis. "Treatment" shows the treatment performed for the disease, such as administered medications, surgery, and rehabilitation. "Treatment Outcome" shows how much the patient's condition improved as a result of the treatment. Case data should, in principle, consist of real cases. However, in the case of rare diseases with low incidence, it is useful to record typical data for a fictional case of that rare disease, as this can suggest the possibility of the disease during the diagnostic process. While plain text is acceptable, JSON, XML, or Markdown formats, which clearly indicate the logical structure, are preferable. A mix of these formats may be used as appropriate.

[0039] Figure 6 shows the structure of a RAG database based on partial case data, in which arbitrary parts (partial case data) are extracted from case data as needed, converted into feature vectors, and recorded in the RAG database. This allows for focused and highly accurate searches when calculating feature vectors for data obtained from cases with unknown diagnoses to search for similar cases. The method of acquiring partial case data is not limited to the example shown in Figure 6 and can be arbitrarily set according to the situation.

[0040] Figure 7 shows the procedure for suggesting the next tests to be performed, and additional symptoms and physical findings that may be useful for provisional diagnosis and differential diagnosis, based on the obtained case attributes, symptoms, and physical findings. In cases with an unknown diagnosis, once the case attributes, symptoms, and physical findings are obtained, the broker program in Figure 4 performs a case search using the RAG database shown in Figure 6(A), sets multiple provisional diagnoses from the known diagnostic groups in the obtained case data, and suggests tests, additional symptoms, and physical findings that may be useful for confirming the provisional diagnosis (differential diagnosis). Here, tests, additional symptoms, and physical findings that may be useful for confirming the provisional diagnosis are those for which there is a large difference in the frequency of positive or negative findings among the provisional diagnoses. By checking the positive / negative values ​​of tests, symptoms, and physical findings with large frequency differences, the provisional diagnoses are narrowed down, and the likelihood of reaching a definitive diagnosis increases. In addition, if the attending physician has a history of testing, symptoms, or physical findings, those tests, symptoms, and physical findings 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.

[0041] In Figure 8, the Broker Program in Figure 4 features the test findings, original symptoms, and additional symptoms and physical findings obtained in Figure 7 as feature vectors, searches the RAG database (B) in Figure 6, and searches for similar cases. The case attributes, symptoms, physical findings, test results, and diagnosis names of the retrieved case group are checked, and if a definitive diagnosis has not yet been reached, test findings, symptoms, and physical examinations are added, and the cycle in Figure 8 is repeated. Here again, if the attending physician has a history of testing, symptoms, or physical findings, those tests, symptoms, and physical findings are given priority consideration. Here as well, a definitive diagnosis may be made by visually reviewing the obtained case attributes, symptoms, and physical findings directly, or it may be made after organizing them with the Broker Program, or after summarizing them with a large-scale language model. Diagnosis is a matter of the physician's sole responsibility, and the system of the present invention provides the physician with the material to make a judgment. The diagnosis is confirmed when the physician becomes confident. If a definitive diagnosis is obtained with sufficient accuracy, proceed to the procedure in Figure 9. Here, by providing the means for suggesting the aforementioned tests, additional symptoms, and additional physical findings, or the means for suggesting the aforementioned additional tests, additional symptoms, and additional physical findings, with a means for issuing test orders to the electronic medical record, an efficient diagnostic procedure becomes possible.

[0042] Figure 9 shows the procedure for suggesting treatment prescriptions after a diagnosis has been confirmed. The broker program in Figure 4 features vectorized the confirmed diagnosis, case attributes, symptoms, physical findings, and test results obtained for cases that previously had an unknown diagnosis, searches the RAG database (C) in Figure 6, and obtains treatment prescriptions and treatment outcomes for similar case groups. It suggests treatment prescriptions with good treatment outcomes, and the physician issues a treatment prescription to the electronic medical record, etc. While it is also possible to search for treatment prescriptions and treatment outcomes using only the confirmed diagnosis, the above search is preferable because the optimal treatment method is influenced and fluctuates depending on the symptoms, physical findings, and test results of the case. If the attending physician has a pattern in past treatment prescriptions, those prescriptions should be given priority consideration. The obtained treatment prescriptions can be visually reviewed and suggested as is, or they can be organized by the broker program, or summarized using a large-scale language model before being suggested. Here, if the treatment order issuance means for issuing treatment prescription orders to the electronic medical record is used in the treatment suggestion means, a significant reduction in labor can be achieved.

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

[0044] 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 diagnostic and prescription support system characterized by comprising: a case data recording means for recording case data of patients with known diagnoses; a feature vector recording means for recording feature vectors obtained by extracting arbitrary parts of the case data, each of which is provided as an arbitrary part; a case data extraction means for extracting arbitrary parts from case data of patients with unknown diagnoses, converting them into feature vectors, and 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; and extracting case data of similar cases using acquired case attributes, symptoms, and physical findings of patients with unknown diagnoses as the arbitrary parts, and providing 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.

2. The diagnostic and prescription support system according to claim 1, 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 means for suggesting the above-mentioned tests, additional symptoms, and additional physical findings, and means for suggesting additional tests, additional symptoms, and additional physical findings that are useful for determining a provisional diagnosis and determining a diagnosis, and means for repeating the means for suggesting the above-mentioned additional tests, additional symptoms, and additional physical findings until a diagnosis is determined.

3. The diagnostic and prescription support system according to claim 2, 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 for suggesting treatment methods with good results using the obtained treatment methods and treatment outcomes.

4. The diagnostic and prescription support system according to claim 2, 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.

5. The diagnostic and prescription support system according to claim 3, characterized in that the treatment suggestion means is equipped with a treatment prescription order issuing means for issuing a treatment prescription order to an electronic medical record.

Images