Information display system

Abstract

This system provides information presentation capabilities that significantly improve physicians' decision-making accuracy and treatment speed, enabling highly reach-based advertising delivery without interrupting the medical flow. [Solution] In the information presentation system, the server's processing means 294 converts speech into text using the speech recognition processing unit 294A, unifies multiple languages ​​using the translation processing unit 294B, and converts visual data into text using the image / video analysis processing unit 294C. Then, the natural language processing / similarity evaluation unit 294D / 294E calculates the cosine similarity of the embedded vectors (threshold of 0.8 or higher are candidates, and ties are ranked using the company priority table), the reverse auction processing unit 294G selects the optimal candidate, and the notification control unit 294F provides real-time notification within 5 seconds via side panel banner, email, SMS, etc.

Description

Technical Field

[0001] The present invention relates to information processing technology (information presentation system, method, program) for a medical support platform that combines a real-time decision-making support function in a clinical setting with a reverse auction method for selecting optimal medical information from multiple information sources, and particularly features real-time identification and presentation of pharmaceutical promotion information (hereinafter, "promotion information") based on acquired clinical data.

Background Art

[0002] With the spread of Electronic Medical Records (EMR) and various medical information systems, diverse data such as voice, text, images, and videos are being generated and utilized daily both inside and outside the examination room. Technologies that utilize such big data to support physicians' diagnosis and treatment decisions have attracted attention.

[0003] For example, Patent Document 1 discloses a technology that performs real-time speech recognition on conversations during medical treatment, collates them with a medical concept dictionary, and displays relevant EMR information in a pop-up manner. However, the input is limited to voice conversations, and the notification method is also limited to pop-ups. Patent Document 2 vectorizes structured patient data into multi-dimensional vectors, weights and synthesizes them using multiple similarity functions, and extracts similar cases, but does not assume the integrated processing of unstructured data such as free conversations, images, and videos that occur during medical treatment. There is also no description regarding the matching with medical information provided by pharmaceutical companies.

[0004] Furthermore, Patent Document 3, which is patented overseas, only detects EMR structured fields (diagnosis codes, prescription drugs, test orders, etc.) as triggers and inserts brand messages into the banner area within the same screen when applicable. The input information is limited to pre-registered fields, and there is no disclosure regarding unstructured voice text derived from physician-patient conversations, dynamic switching of presentation channels, or even a notification function to pharmaceutical companies or their contractors.

[0005] Thus, although attempts have been made to integrate advertising and promotional information into clinical support systems, practical implementation has been extremely limited due to challenges such as (1) concerns about disrupting physicians' workflows, (2) the burden of complying with regulations such as the Pharmaceuticals and Medical Devices Act and OPDP guidelines, and (3) the lack of real-time utilization of unstructured data. Furthermore, because there is a risk of undue influence on clinical judgment if healthcare professionals cannot verify the basis for the information presented, it has been common practice in practice to intentionally exclude advertising functions.

[0006] Therefore, it can be said that there was no incentive for those skilled in the art to simply combine existing voice recognition automated medical record creation technology (Patent Document 2) and banner advertising technology (Patent Document 3), and furthermore, there were so-called inhibiting factors. In other words, simply combining existing voice recognition automated medical record creation technology and banner advertising technology would present several obstacles to actual operation. First, the data format and timing output by the voice medical record system and the interface specifications required by the advertising platform are incompatible, and information cannot be transmitted correctly even if they are linked as is. Also, because medical information is subject to strict regulations such as privacy protection and the Pharmaceuticals and Medical Devices Act, combining it with an advertising distribution system would drastically increase operational costs and the burden of legal compliance. Furthermore, while real-time processing within a few seconds is required in clinical settings, advertising distribution infrastructure is not necessarily designed with low latency in mind, and the incompatibility of these quality requirements is a major inhibiting factor. In addition, for medical institutions and pharmaceutical companies to invest in this type of integrated solution expecting a number of ad clicks, the cost-effectiveness is not commensurate, and there is little business incentive. Furthermore, system integration requires enormous development effort and maintenance costs, leading many in the industry to hesitate in implementing such systems, as they believe simple combinations are not cost-effective. In this specification, "reverse auction method," "reverse auction," and "auction mechanism" are synonymous. Also, "generative AI" and "LLM" are general terms for generative artificial intelligence models. Furthermore, it is explicitly stated that the reverse auction method defined in claim 13 corresponds to Figure 6 of Embodiment B, and the priority assignment coefficient in claim 16 is embodied in the company priority table in step S603A of the same figure. This clarifies the cross-reference between the claims and embodiments.

[0007] The present invention 1. By acquiring multimodal unstructured data such as audio, text, images, and video in real time, we can accurately grasp the clinical context. 2. Ensure transparency by presenting metadata such as the identifier that serves as the basis for the identification, the application and contraindication information that serves as the basis, and the score. 3. Using a reverse auction method, medical information provided by multiple pharmaceutical companies is automatically selected by optimizing it in terms of both "clinical relevance," "appropriateness," and "bid value." It is characterized by the following: In this specification, "(identifying a drug)" refers to a series of actions that take clinical text or its vector representation (hereinafter referred to as "clinical text, etc.") as input, compare it with drug metadata stored in a drug information database, extract clinically relevant drugs uniquely or collectively, and process them to a state where they can be presented to healthcare professionals. Therefore, "identification" includes, but is not limited to, the following aspects. [Process 1: Candidate extraction] A process that lists one or more drugs whose relevance exceeds a predetermined threshold, using algorithms such as similarity calculation, keyword / phrase matching, pattern matching, rule engines, AI inference, graph inference, and others. [Process 2: Prioritization and Scoring] This process assigns a numerical value or ranking to each of the extracted candidate drugs, taking into account the clinical context (patient attributes, medical history, urgency, etc.), economic indicators (bid price, cost-effectiveness, etc.), and normative parameters (contraindication suitability, compliance with advertising regulations, etc.). [Process 3: Filtering / Refining] This process reduces the burden on healthcare professionals by abbreviating the candidate set based on reasons such as contraindication information, incompatibility scores, notification limits, and duplicate candidates. [Process 4: Final Selection (Automatic Confirmation)] A process that determines a predetermined number of candidates (e.g., top 1, top k) from the candidate set based on the above score or rules, using algorithmic or generative AI-based re-ranking. [Process 5: User-Selected Decision] A process that presents a set of candidates on a user interface and allows healthcare professionals to ultimately select one or more candidates through actions such as clicking, tapping, or using voice commands. [Process 6: Hybrid Type] This system involves healthcare professionals approving, rejecting, or changing the ranking of candidates that have been automatically extracted and scored. In the claims, embodiments, drawings, etc. of this invention, when the terms "specified drug," "drug identification means," etc. are used, it means that the drug has been included in the candidate set and made available for display or notification after undergoing at least one of the processes described in 1 to 6 above. The specified drugs may be singular or plural, and are included in this definition regardless of whether they are manually or automatically determined, the processing order, the type of computing resource (edge / cloud), or the type of matching algorithm.

[0008] While reverse auctions are widely used in e-commerce and general procurement, there are no examples of them being combined with real-time decision support in the medical field, particularly in clinical settings where regulatory and ethical requirements are stringent. This invention overcomes the aforementioned obstacles, • Presenting pinpoint information backed by suitability. • Reduce the number of ad impressions, • Designing learning incentives for doctors, It achieves practical effects such as those mentioned above and possesses innovative features that would not be easily conceivable by those skilled in the art.

[0009] The present invention aims to solve the following problems simultaneously. A. The significant burden on Medical Representatives (MRs) to acquire sufficient specialized knowledge. B. The difficulty for medical representatives (MRs) to attend consultations due to personal information protection measures. C. The burden on doctors of manually entering and transcribing information. D. The difficulty in setting and optimizing conditions for providing appropriate medical information to physicians. Furthermore, given the increasing specialization among physicians, physicians often do not accurately grasp the information they need, resulting in unmet information needs. In other words, this invention acquires and analyzes diverse input data—voice, text, images, and video—in real time at medical settings, thereby accurately grasping the individual context of patients, which was difficult with conventional CDS (Clinical Data Systems). Based on this, it automatically identifies and notifies optimal drug information and related promotional information. (presentation) It is characterized by the following point.

[0010] Specifically, conversational audio, OCR text, chat logs, image and video data acquired via mobile devices, fixed / wearable microphones, and electronic medical record screen captures are first embedded and vectorized by a generative AI model. These vectors are then compared with each drug's metadata in the drug information database using cosine similarity. A composite score is calculated by multiplying the resulting similarity score by clinical weights and economic parameters, and candidates exceeding a threshold are extracted. If multiple candidates exceed the threshold and clear the contraindication check, the final winning drug is determined through a reverse auction based on a company priority table and EvidenceGrade / CostIndex. The results are then immediately sent to the physician via a flexible combination of multiple channels, including electronic medical record side panel banners, push notifications, email, and SMS. This enables integrated utilization of multimodal unstructured data, high-dimensional vector similarity evaluation, multi-faceted evaluation and selection through reverse auctions, guardrail checks to prevent redundant notifications, privacy protection through edge computing, and secure terminal operation under MDM management—all in a seamless manner, allowing physicians to receive optimal medical information without interrupting their clinical flow.

[0011] According to the present invention, 1. Extraction of clinical context using multimodal unstructured data. 2. Ensuring transparency and regulatory compliance through metadata attachment, 3. Information optimization selection using a reverse auction method. This integrated system can support physicians' decision-making while eliminating excessive or inappropriate advertising. In particular, by designing the system so that doctors receive higher points for information with higher bids, it becomes possible to provide doctors with an incentive to learn information that has a significant impact on clinical judgment.

[0012] Ideally, pharmaceutical sales representatives (MRs) in clinical settings would have a thorough understanding of medical knowledge, attend patient consultations with physicians, and provide appropriate medical information about their company's products to the patients. This invention involves performing voice recognition on physicians and patients in a medical setting, and using AI to judge the appropriateness of the voice recognition results based on clearly defined presentation conditions, and then presenting content that would be beneficial for the physician to learn. Furthermore, by using a reverse auction system for these presentation conditions, only the information with the highest clinical relevance, appropriateness, and bidding value from among the information presented by multiple pharmaceutical companies can be fairly and automatically selected, eliminating redundant advertising. In addition, by implementing a system that awards more points to physicians for information with higher bids in the reverse auction, it becomes possible to design an incentive for physicians themselves to learn appropriate information related to decisions with a wide-ranging impact.

[0013] As prior art examples, there are those that SOAPify medical conversations to automatically generate prescriptions, those that link emergency voices to EMR searches, those that post academic materials through MR dialogue analysis, and promotion target extraction technologies and anonymization platforms based on prescription estimation. However, none of these have a five-stage integrated pipeline that collates the "patient profile template" registered for each provider with real-time SOAP-structured text vectorized into high-dimensional vectors by a generative AI, normalizes and synthesizes the clinical fitness score and economic bid value on the same number line, determines the winning bid through a reverse auction after threshold judgment, and presents it to the doctor's terminal in a multi-channel manner within 5 seconds. Specifically, there is no example of constructing a real-time next-generation CDS that JSONifies the drug metadata (indications, recommended by treatment line, combination contraindications, etc.) transmitted from each provider, gives a prompt to the generative AI to "select the top 2 considering clinical validity and BID and list the reasons within 50 characters", and further switches banners / emails / SMS as notification channels according to the urgency. Additional effects and application possibilities

[0014] By adopting the reverse auction method, it is possible to promote fair competition among information providers while providing the doctor with the clinically optimal information in real time. As a result, an improvement in medical treatment quality, optimization of drug selection, and efficiency of medical economy are expected. All of the prior technologies lack a framework that mutually interprets the application conditions arbitrarily set by the provider and the patient situation data extracted in real time during the medical treatment process at a high semantic level, and instantaneously integrates and evaluates the fitness index and economic index. In other words, the three elements of a general-purpose model that can project various context information into the same semantic space, a scoring mechanism that synthesizes the fitness and bid value on the same scale, and an execution platform that can output the judgment result in sub-second order are not cross-linked. As a result, it is technically difficult to simultaneously satisfy the conflicting requirements of both the information accuracy (reach accuracy) and the processing delay (workflow immediacy).

Prior art documents

Patent documents

[0015]

Patent Document 1

Patent Document 2

Patent Document 3

[0016]

Non-Patent Document 1

Summary of the Invention

[0017] The present invention solves the above problems and provides a medical support platform that integrates both information provision and decision-making support in the clinical field in a high-dimensional manner. Although there are already many precedent examples of the reverse auction method in the fields of e-commerce and procurement, there are no application examples in medical information selection and clinical support, and there is a lack of an optimal information selection means by automatic competition.

[0018] The present invention solves the above problems and provides a medical support platform that integrates both information provision and decision-making support in the clinical field in a high-dimensional manner.

[0019] Although there are already many precedent examples of the reverse auction method in the fields of e-commerce and procurement, there are no application examples in medical information selection and clinical support, and there is a lack of an optimal information selection means by automatic competition.

[0020] The effects of each claim are described below. Each claim integrates multifaceted technological elements, starting with the acquisition of multimodal clinical data, and including enrichment of drug metadata, visualization of evaluation indicators, multi-layered notification channels, automatic linking of patient identification, OCR integration, guardrail checks, protection of personal information, edge computing, MDM management, vector similarity search, reverse auction selection, utilization of generative AI, and use of patient self-reported information. This comprehensively solves and mitigates the problems of conventional technologies, such as "difficulty in accessing necessary information," "insufficient utilization of unstructured data," "search load," "lack of transparency in information presentation," "mismatches and missed notifications," "risk of patient misidentification," "risk of regulatory violations," "risk of personal information leakage," "low accuracy of keyword searches," and "excessive advertising noise," thereby realizing highly accurate and secure real-time clinical decision support without disrupting the physician's clinical flow.

[0021] [Table 1] [Problems that the invention aims to solve]

[0022] However, conventional clinical decision support systems had the following problems: • Limitations on input modalities: It only supports voice conversations or structured data such as electronic medical records, and does not allow for the full utilization of unstructured data (chat, images, videos, etc.) in diverse clinical settings. • Rigidity of the evaluation logic: It relies on keyword matching and fixed rules, making it difficult to dynamically and accurately match information that reflects the individual context and urgency of each patient. • Limitations of notification channels: They are primarily single-channel, such as pop-ups and emails, making it difficult to flexibly select the most suitable information delivery method based on urgency and the user's environment.

[0023] Furthermore, none of the aforementioned prior art technologies have a means of semantically matching patient profile templates defined by pharmaceutical companies with SOAP-structured text generated during medical consultations using a generating AI, and then combining the degree of relevance with bid values ​​to determine the target audience for real-time ad delivery. Therefore, it is difficult to simultaneously satisfy both ad reach accuracy and the immediacy of the medical workflow.

[0024] Furthermore, the aforementioned prior art is inefficient due to four challenges: A) the difficulty of MRs acquiring medical knowledge, B) the inability to attend medical facilities due to personal information restrictions, C) the effort required for doctors to transcribe information, and D) the difficulty of optimizing the conditions for providing doctors with appropriate medical information. In addition, with the increasing specialization of doctors, many doctors themselves do not understand what kind of medical information they need, and there is an unmet need for information matching.

[0025] Furthermore, conventional technology lacks a real-time ad delivery method that integrates patient profile templates × SOAP matching and bid evaluation, making it impossible to simultaneously satisfy reach accuracy and immediacy.

[0026] On the other hand, while reverse auctions are widely used in e-commerce and procurement, there have been no examples of their application to the selection of medical information or clinical support. As a result, there has been a lack of an automated competitive method for optimal information selection that comprehensively considers evidence levels and cost efficiency.

[0027] The present invention solves the above problems, • Advanced real-time CDS capabilities based on embedded vector similarity evaluation and contextual weighting, • A means to improve the efficiency of reaching applicable cases through a reverse auction function across multiple information sources, The aim is to integrate these elements to simultaneously improve the accuracy of physicians' judgments and streamline information provision within limited consultation time. In other words, the present invention aims to overcome the limitations of conventional technologies and enable practical real-time support in clinical settings by enabling integrated handling of multimodal inputs such as voice, text, images, videos, translated text, and sentiment analysis; improving context-dependent accuracy in vector similarity evaluation by dynamically changing thresholds and weights according to patient attributes and circumstances; and achieving immediacy and re-notification control by switching between multiple channels such as banners, emails, and SMS according to urgency, delivering information within seconds after the end of a consultation. In particular, it is characterized by (a) calculating the probability of matching a patient profile template with SOAP text (Prob) using a generative AI model, (b) generating a bid value (Bid) sent by pharmaceutical companies and a composite score (Score = Prob + Bid), and (c) immediately determining the target of ad delivery through a reverse auction based on the score. [Means for solving the problem]

[0028] This invention is an information processing program that acquires and stringifies various modal inputs, such as audio data including speech from patients or healthcare professionals, text data, and image / video data, and stores the generated conversational text linked to a user identifier. It generates an embedding vector from the acquired text, matches it with a pre-associated set of conditional description data using cosine similarity, selects candidates above a threshold, and in case of a tie, performs ranking using a company priority table or reverse auction selection based on EvidenceGrade / CostIndex. Finally, it transmits the relevant information linked to the selected conditional description data in real time via multiple channels such as fixed banners in electronic medical records, email, and SMS, simultaneously improving the accuracy of clinical judgment and the efficiency of information provision. Furthermore, the system's processor is functionally divided into a "determination unit" and a "notification unit." The determination unit compares metadata (a) to (g) with speech recognition data, etc., to determine whether notification is necessary, and the notification unit outputs promotional information using at least one of the methods (i) to (vii). The system includes a processor and memory, and holds a "promotional database (PD)" in the memory. The PD stores at least two items of metadata for at least two drugs: (a) product name, (b) active ingredient name, (c) efficacy / effects, (d) dosage / administration, (e) contraindications / side effects, (f) pharmaceutical company information, and (g) optional information provided by the company. The processor is functionally divided into a "determination unit" and a "notification unit." The determination unit compares speech recognition data, OCR text, etc., with the PD's metadata to determine whether notification is necessary, and the notification unit outputs promotional information using at least one of the methods (i) to (vii). When calculating evaluation data, the generated AI Score = Prob (Probability of matching patient profile) + Bid (Bid price) The system calculates the score and determines the final winning bidder through a reverse auction based on the highest score. This reduces the process from two stages (contextual matching → ad selection) to one step, shortening the average latency by approximately 50%.

[0029] In the evaluation data calculation process, a synthetic score (Score) is generated by a generation AI model (GPT-based or LlaMA-based) using the following formula. Score = Prob (Probability of matching patient profile) + Bid (Bid price) This allows contextual relevance and economic indicators to be treated on the same scale, and the final ranking can be determined in a single step. As a result, the analysis + bidding calculation process, which was previously two stages, can be reduced to one stage, resulting in an average processing delay reduction of more than 50%. In this specification, "probabilization" means that the similarity cosθ of the embedding vectors is expressed using the sigmoid function σ(x) = 1 / (1+e -x This includes a step of normalizing the result to a probability value between 0 and 1 using statistical methods such as log(p / (1-p)) or logit transformation. The specific form of the function can be replaced with Softmax or Temperature Scaling, etc., depending on the implementation requirements.

[0030] (1) The information processing program described in claim 1 provides a means to simultaneously solve the problems of input modality limitations, fixed matching logic, and single-channel notification in the prior art by having the following configuration requirements. (Input data acquisition process): Acquires audio data including speech from patients or healthcare professionals, text data, images, or video data. If audio is included, it is converted into text to generate conversational text. This comprehensively captures unstructured data generated in various clinical settings and integrates conversations, chats, videos, and images on a single platform, making previously unsupported information sources available in real time. (Text saving process): Generated conversation text or text in input data is saved, linked to a user identifier. This ensures a history of who spoke and when, allowing for immediate reference to past contexts. This enables contextual weighting for each patient, suppression of re-notifications, and audit logs for legal compliance, all within the same framework. The present invention also includes configurations that use streaming storage to a log management server or persistence means through integration with an external audit system as an alternative to this file system storage. Furthermore, control of multiple layers, such as history tracking, audit logs, and re-notification suppression, can be completed within the same memory space without the need for additional plugins. (Evaluation Data Calculation Process): At least one conversation text or text derived therefrom is compared with multiple conditional description data linked to related information, and at least one evaluation data, such as a similarity score, ranking information, or selection label, is calculated for each. This allows for the highly accurate extraction of context-dependent information that is difficult to capture with keyword matching by applying flexible matching logic using embedding vectors and multi-element synthesis. Specifically, first, the acquired conversation text or derived text generated therefrom is compared with an embedding vector prepared in advance for each conditional description data, and a "similarity score" is calculated, which quantifies the degree of match. Next, the similarity scores of all conditional description data are compared and sorted in descending order, and recorded as "ranking information". At this time, if multiple candidates with the same score occur, the ranking is determined according to tie-breaking rules such as a company priority table. Furthermore, based on pre-set thresholds and operational policies such as the top number of items, "selection labels" such as "candidate," "non-candidate," and "requires consideration" may be assigned to each data point. By passing at least one of these evaluation data to subsequent selection processing, flexible automatic filtering based on scores, priority selection based on rankings, and binary / multi-class determination based on labels are performed, achieving optimal narrowing of conditional description data while balancing context dependency and operational requirements. Note that this invention also includes configurations that use evaluation logic employing Euclidean distance, Jaccard coefficients, or even machine learning models in addition to cosine similarity. This makes it possible to separate gray areas that are difficult to capture with single-keyword judgments or single-value scores. (Selection Process): Based on the calculated evaluation data, one or more conditional description data are automatically selected. By combining this with threshold judgment and tie resolution (e.g., reflecting priority tables), the most relevant information is narrowed down while preventing an excessive number of candidates. Note that this invention also includes configurations that use selection judgment by a trained classifier or rule engine instead of threshold judgment or priority table judgment. (Notification Processing): The system notifies the user or data creator of relevant information associated with the selected condition description data. This enables the delivery of information to doctors at the appropriate time according to the urgency and usage environment through output control that supports multiple channels such as side panel banners, email, and SMS. In addition to these, the present invention also includes configurations that alternatively use push notifications, voice announcements, AR overlays, etc. The notification channel is selectively executed from (i) in-device display, (ii) push notification, (iii) email, (iv) SMS / MMS, (v) in-app message, (vi) web dashboard update, and (vii) HTTPS API integration.

[0031] By linking these requirements as a series of pipelines, a seamless clinical support workflow is realized: multimodal input → context-dependent evaluation → automatic selection → flexible notification. This provides a CDS platform that simultaneously satisfies real-time performance, accuracy, and operability, which could not be achieved with conventional technologies that fragmented processing using individual modules and fixed rules.

[0032] Furthermore, the system normalizes diverse input modalities into a single format to prevent data loss, then stores it inseparably with user identifiers to establish traceability, subsequently evaluates conditional description data with high accuracy using a quantified contextual relevance score, automatically determines candidates based on that evaluation value to ensure reproducibility, and finally notifies users through the most appropriate channel according to urgency, maximizing information transmission efficiency without disrupting the workflow.

[0033] (2) In claim 2, the input data acquisition process acquires multiple modalities individually or in combination. By providing integrated support for these, a multimodal input environment is realized that goes beyond the conventional "voice only" or "structured data only," enabling the acquisition and storage of information without omissions in any medical scenario and facilitating high-precision CDS processing. Furthermore, the present invention also includes configurations that similarly acquire other human and equipment logs as alternatives, such as vital sensor data, wireless tag location information, and direct reading of PDF / electronic documents. (Voice memos by healthcare professionals alone): By treating audio recordings made by doctors and nurses without a conversation partner as input data, it becomes possible to analyze observation notes and practical reports made when patients are not present using the same workflow. (IoT Fixed Microphone / Wearable Microphone Continuous Audio Recording): By acquiring continuous audio streams from ceiling microphones, pen-type microphones, smart glasses-mounted microphones, etc., within the examination room, and processing not only dialogue but also ambient sounds, coughing sounds, breathing sounds, etc., in a unified manner, it supports real-time anomaly detection and automatic updating of medical records. (Online conversation audio for telemedicine / second opinion); By capturing audio from telemedicine sessions conducted via web conferencing or video call systems and feeding it into the same analysis routine as for in-person consultations, the same CDS functionality is provided for patient care in remote locations. (Text Chat / Message Logs): By acquiring medical information chats and business communications exchanged on messaging platforms such as Teams, LINEWorks, and Slack via API and using them for matching in the same way as conversation texts, it is possible to cover a wide range of communication methods in the medical field. (Free-form text notes entered via keyboard): Text notes entered in the free field of electronic medical records or on tablet devices are included in the analysis, allowing for the capture and utilization of detailed notes and supplementary information that are difficult to express orally. (Automatically translated text of multilingual speech): This system translates speech exchanged in multiple languages ​​such as Japanese, English, and Chinese in real time, and compares the translated results with the text to be analyzed, enabling support for global expansion and operation in multinational teams. (Images / Videos): By acquiring endoscopic images, ultrasound videos, and operating room camera footage and sending them to the image analysis department, condition matching based on visual findings, as well as text information, can be achieved on the same system.

[0034] (3) The user terminal is equipped with a camera capable of capturing barcodes / QR codes, and the judgment unit extracts patient identification information from the code and associates it with voice recognition data. (4) The patient identification information or judgment result can be output in QR code or barcode format and can be linked with electronic medical records and in-hospital logistics systems via machine reading. (5) The user terminal is equipped with a camera unit that captures images of the electronic medical record screen and an OCR engine, and the OCR extracted text is used in conjunction with speech recognition data to make a judgment. (6) The judgment unit cross-references the medical terms contained in the speech recognition data and the OCR extracted text. If they match, the medical record notation is given priority. If they do not match, an uncertain flag is added and the item is excluded from the promotion judgment. In the overall processing flow shown in Figure 5, a sigmoid normalization process S505A is added after metadata matching. In S505A, the similarity expressed as cosθ is normalized to a probability value Prob between 0 and 1 using the sigmoid function σ(x) = 1 / (1 + e^-x), and then used for the subsequent judgment S506. The normalization coefficient can be replaced with Softmax or Temperature Scaling, etc., depending on the actual operation. Furthermore, in the overall processing flow shown in Figure 5, the sigmoid normalization process S505A is executed immediately after metadata matching S505. In S505A, the similarity value cosθ is normalized to a probability value Prob between 0 and 1 using the sigmoid function σ(x) = 1 / (1 + e^-x), and then submitted to the judgment process S506. This allows scores obtained on different scales to be converted into a unified index, improving the reproducibility of threshold comparisons.

[0035] By adding various limited functions to the basic CDS pipeline of Claim 1, the operational, accuracy, and notification requirements are further enhanced. While each of these limited functions individually offers benefits tailored to specific operational needs, combining them allows for the construction of an advanced and practical clinical support platform that satisfies multiple requirements such as "high-precision candidate extraction," "clear tie-breaking," "multi-layered and reliable notification," "specialization in specific fields," "real-time capabilities," and "compatibility with existing EHR environments."

[0036] The natural language processing unit calculates the cosine similarity between the generated embedding vectors and automatically extracts conditional description data with a score of 0.8 or higher as "candidates." This ensures that only data showing high contextual relevance above a threshold is kept for the next stage, reliably eliminating low-relevance noise. • When multiple candidates show the same similarity score, the ranking is determined by referring to a pre-managed company priority table. This allows for a unique selection even in tie situations, ensuring a fair and clear tie-breaking process in accordance with operational policies. • The notification mechanism will be controlled from multiple angles. Specifically, selected relevant information will be displayed as a fixed banner on the side panel of the electronic medical record, allowing physicians to immediately check the content directly from their operating screen. In addition, by combining email sending and read flag monitoring, unnecessary duplicate communications will be suppressed by automatically stopping the next notification if the message is not marked as read. Furthermore, to enhance robustness, if email or banner sending fails three times in a row, an SMS will be sent to the medical information representative's terminal as a backup, ensuring that important information is reliably delivered through multiple notification channels. • By limiting the content of the condition description data to efficacy and usage information extracted from pharmaceutical company package inserts (PDFs), and especially to package inserts for anticancer drugs, only highly reliable information specific to specialized fields such as oncology is handled. • We explicitly state the real-time requirement to complete notifications within a short timeframe of 5 seconds after the end of a consultation, guaranteeing an instant notification function that can provide information immediately without disrupting the physician's consultation flow. By deliberately limiting input data to only electronic medical record data and laboratory system data, and by allowing the option of a configuration that does not perform conversational analysis, we provide flexibility that makes the system applicable to medical institutions that want to implement the system using only their existing EHR integration environment. Furthermore, examples of embodiments employing Faiss, Elasticsearch's knn_vector function, or ScaNN as an approximate nearest neighbor search engine for high-speed searching of a conditional description database are provided. This allows for the extraction of the top k records within 50ms, even with a database of 100 million records. Furthermore, the reverse auction processing flow in Figure 6 includes a step S603A for referencing the tie clustering priority table. In S603A, candidate sets exceeding the similarity threshold are clustered, and a primary tie-break is performed using the provider priority table to resolve duplicate competition. Subsequently, the normalization score calculation S604 multiplies the BID coefficients α and β, and the process moves to the reverse auction S605.

[0037] This system utilizes microservices for each function, including speech recognition processing, generative AI models, and reverse auction calculations, enabling horizontal scaling on a container-based infrastructure. This allows individual services to be expanded independently even during periods of increased load, ensuring high availability. Furthermore, the system implements speech recognition, LLM inference, and reverse auction calculations as microservices on Kubernetes, and the HorizontalPodAutoscaler automatically increments the number of containers when it detects CPU usage exceeding 70%. This maintains a service level of notification within 5 seconds, even with 1000 simultaneous sessions.

[0038] All stored data is encrypted, and rigorous auditing features, including access control logs, are implemented, fully meeting the requirements of healthcare information protection regulations such as HIPAA and GDPR. User identifiers and conversation texts are handled under multi-factor authentication, and internal controls are strengthened by combining multi-step access control with multi-factor authentication.

[0039] For natural language processing models, version control and drift detection functions are included as standard, enabling phased deployment through A / B testing and canary releases. This prevents performance degradation during model updates while maintaining optimal accuracy by running new and old models in parallel.

[0040] The dashboard for system administrators provides real-time visualization of notification transmission status, reverse auction bid results, and system operational status, enabling early detection and response to anomalies and bottlenecks. This significantly improves operational maintainability.

[0041] Furthermore, it can seamlessly integrate with biosensors, nurse call systems, drug inventory management systems, and other systems to optimize the overall workflow of the hospital information system. This configuration makes it possible to dramatically improve the quality and efficiency of information provision in clinical settings. [Effects of the Invention]

[0042] According to the present invention, diverse input data such as voice, text, images, and videos are processed integrally, and based on a highly accurate matching logic that combines embedded vector similarity and contextual weighting, optimal medical information can be extracted and presented in real time from physicians' consultation conversations and draft medical records. This enables highly context-dependent decision support that could not be obtained with conventional keyword matching or fixed rule-based methods, and has the effect of significantly improving the accuracy of physicians' judgments and the speed of treatment. Furthermore, by achieving immediate determination with a single score of Score=Prob+Bid, a 50% reduction in processing delay and a 1.4 times improvement in click-through rate compared to conventional methods are achieved, enabling highly reach-accurate ad delivery without interrupting the consultation flow.

[0043] Furthermore, by using the reverse auction mechanism in this invention, conditional description data provided by multiple companies, academic societies, and equipment manufacturers can be used as competing bidding information based on evidence ratings and cost indicators, automatically selecting the information with the highest value. This allows for efficient access to optimal information from diverse sources without requiring physician intervention, even within limited consultation time, dramatically improving the reach efficiency of medical information provision.

[0044] Furthermore, this invention combines notification control across multiple channels (side panel banners, email, SMS, etc.) according to urgency, and a company priority table for resolving tie-breaking candidates, thereby achieving both "immediacy" and "reliability," which were difficult to achieve with a single channel and single evaluation alone. As a result, physicians can receive information at the necessary and appropriate time without interrupting their clinical flow, and receive clinical support that is both safe and efficient.

[0045] As described above, by introducing the information processing program and system of the present invention, a next-generation clinical decision support service that combines advanced selection logic and flexible notification control while comprehensively utilizing diverse data sources in clinical settings can be easily integrated into the existing medical IT environment, offering a significant industrial advantage. [Brief explanation of the drawing]

[0046] [Figure 1] A diagram showing the network configuration of an information presentation system according to an embodiment of the present invention. [Figure 2] This diagram shows the system configuration and hardware layout of this system. [Figure 3] A block diagram showing an example of the functional configuration of a processing device. [Figure 4] A block diagram showing an example of the functional configuration of Server 20. [Figure 5] (Embodiment A) A flowchart showing the entire process including the sigmoid normalization step S505A. Corresponding to claims 1-3 and 12. [Figure 6] (Embodiment B) A flowchart showing the reverse auction process including the tie clustering priority table step S603A. Corresponding to claims 6 and 13. [Figure 7] A schematic diagram showing the hierarchical structure of detailed condition data. [Figure 8] This diagram illustrates an example of how this system displays a medical summary and related promotional cards in card format on the same screen of a physician's terminal. [Figure 9] This diagram shows an example screen where key messages extracted by the AI ​​generator and corresponding promotional banners are placed side-by-side at the bottom of the medical summary. [Figure 10] This diagram shows an example screen displaying a QR code that encodes the SOAP summary and other information generated during a medical session. [Figure 11] A flowchart showing, in order: (A) a camera startup screen with three modes: barcode / screen / video, (B) a scene of reading a QR code containing a patient ID, and (C) a scene of performing OCR analysis after capturing an electronic medical record screen. Claims 5 and 7. [Best Mode for Carrying Out the Invention]

[0047] Figure 1 shows the network configuration of the information presentation system of the present invention. The user terminal 1, the information presentation system 2, and the medical system 3 are interconnected via network 4, and each component operates cooperatively via network 4 to provide real-time clinical decision support and automatic selection functions using a reverse auction method. Network 4 can be a virtualized network configuration including VPN or dedicated lines, and can be extended not only to the hospital LAN but also to remote presentations via the cloud and collaboration with other facilities.

[0048] User terminal 1 is a client device for doctors and medical professionals to operate conversations and chat inputs during medical consultations, and is equipped with an interface for checking condition matching results and related information, and inputting operation instructions. User terminal 1 can also support conversation input via message logs and chat APIs such as Teams and LINEWorks, and can handle various communication methods on the same platform. Information presentation system 2 consists of a group of core servers that perform conversation data transcription, natural language processing, similarity evaluation using embedded vectors, reverse auction selection, and transmission control to various notification channels, and includes functions to realize steps (1) to (5) described in the claims. Medical system 3 includes an electronic health record (EHR) and a laboratory system, and has a group of databases that hold structured data such as basic patient information, medical history, and various test results. Medical system 3 can also include an attachment document DB that stores efficacy and usage data extracted from PDF attachments, and can also support automatic analysis of regulatory documents. Information presentation system 2 links data with medical system 3 and obtains information necessary for extracting condition description data to be matched and contextual weighting based on medical history.

[0049] Within the hospital, user terminals 1 used by doctors and nurses, input devices including fixed and wearable microphones for recording audio during treatment, and image / video acquisition devices such as endoscopes and ultrasound machines are installed. These are connected to the information presentation system 2 via a local area network (LAN). The information presentation system 2 consists of a group of high-performance servers and software modules. It performs preprocessing such as transcription, translation, and image analysis of unstructured data acquired during medical treatment to convert it into text and extract features, and then performs similarity evaluation with medical information stored in a conditional description database and selection processing using a reverse auction method. This group of servers also works in conjunction with the medical system 3 (electronic medical record and laboratory department system), acquiring structured data such as the patient's medical history and test results and using it for contextual weighting. In this embodiment, output channels such as notifications to user terminals 1 and email / SMS transmission are also centrally managed from server 2, and a system is realized that provides optimized medical information in real time while ensuring security through encrypted communication compliant with TLS1.3 / FIPS140-3.

[0050] Figure 2 shows an example of the hardware arrangement of each device constituting the information presentation system of the present invention. This system is applicable not only to on-premise environments but also to cloud-native configurations using containers / Kubernetes, and can be horizontally scaled as needed. User terminal 1, operated by doctors and medical professionals, is equipped with a display device and input device for inputting conversations during medical treatment and confirming results. Server 20 has a processor 29 that is responsible for calculation processing, memory 25 that temporarily holds data and programs being processed, and storage 26 that permanently stores condition description data and history information. Server 20 is further equipped with a communication interface 22 that sends and receives data to and from user terminal 1 and medical system 3 via the network, and an input / output interface 23 that connects to a voice recording device, chat device, and notification destination device, and through these, real-time CDS processing and optimal information selection based on a reverse auction method are safely and efficiently executed.

[0051] More specifically, the processor 29 is a computing unit that performs calculations for each step shown in Figures 5 and 6 at high speed, including transcription, natural language processing, embedding vector similarity calculation, reverse auction selection, and notification channel control. The memory 25, which temporarily stores intermediate results of these processes and the program itself, functions as a volatile memory device that reads and writes complex machine learning models and translation data at high speed, reducing processing delays. The storage 26, which the system references, stores large amounts of persistent data such as a condition description database, meta-attribute tables, and user history logs, and is used when retrieving past treatment records and guideline documents. Communication with external systems is performed via the communication interface 22, and communication with the medical system 3's electronic medical record and laboratory systems, as well as the email / SMS sending gateway, is securely processed using TLS1.3 / FIPS140-3 compliant encrypted communication. The input / output interface 23 not only connects voice input devices, chat terminals, and image / video acquisition devices to the voice recognition and image analysis units within the server, but also plays a role in comprehensively managing a wide range of input / output devices, such as fixing banners on the side panel and sending emails / SMS messages to external mobile terminals based on instructions from the notification control processing unit. These elements work together to efficiently and securely realize the real-time CDS and reverse auction mechanism of the present invention. Furthermore, the communication interface 22 has a redundant configuration of encryption modules compliant with TLS 1.3 / FIPS 140-3, enabling duplication and load balancing.

[0052] Figure 3 is a block diagram showing the functional configuration of the "processing means 294" which is responsible for the core processing of the present invention. The processing means 294 includes a speech recognition processing unit 294A, a translation processing unit 294B, an image / video analysis processing unit 294C, a natural language processing unit 294D, an evaluation unit 294E, a notification control processing unit 294F, a reverse auction processing unit 294G, a determination unit 294H, a notification unit 294I, and an OCR processing unit 294J. Each processing unit (294A to 294G) is microservice-based and can be deployed independently on a container basis, making it easy to update functions and perform A / B testing.

[0053] First, audio data is converted into a string by the speech recognition processing unit 294A, and if necessary, the multilingual data is converted to a unified language via the translation processing unit 294B. In parallel, image and video data undergoes feature extraction by the image and video analysis processing unit 294C, and the output, which is either converted into text or feature vectors, is sent to the natural language processing unit 294D. The natural language processing unit 294D converts the input text into embedding vectors using generative AI models such as BERT and CLIP, and the evaluation unit 294E calculates a similarity score with each record in the condition description database. Candidates whose scores are above a threshold are sent to the reverse auction processing unit 294G, where, after bidding calculations based on EvidenceGrade and CostIndex, the top-ranking information is finally selected. The selected information is processed by the intelligent control processing unit (94F) and output in the most optimal way from multiple channels such as side panel banners, email, and SMS, depending on the UrgencyLevel and user environment.

[0054] The generative AI model is positioned as the core algorithm for realizing the functions of the translation processing unit 294B and the natural language processing unit 294D. Specifically, the translation processing unit calls the generative AI model when automatically converting multilingual conversations or texts into a unified language to produce highly accurate translation results. The natural language processing unit also utilizes the same model when converting input text into embedding vectors and generating derived texts such as summaries and sentiment labels, enabling advanced language understanding and expression generation. As a result, consistently high-quality analysis results can be obtained from input data preprocessing to subsequent similarity evaluation, contributing to improved accuracy of the real-time CDS and reverse auction mechanism of the present invention. Furthermore, in this embodiment, the user terminal is equipped with a camera unit → performs a procedure to read a patient identification barcode or QR code at the start of medical treatment → the same camera unit captures an image of the electronic medical record screen → and the built-in OCR engine converts the prescription field and test result field into text. The acquired patient identification information and OCR-extracted text are associated with a common session identifier with the speech recognition result and used as input for the aforementioned identification means.

[0055] The natural language processing unit 294D can also generate derived text such as sentiment analysis and keyword summaries, which can be used in conjunction with similarity calculations. The reverse auction processing unit 294G can also be configured to work in conjunction with external auction engines and machine learning models.

[0056] The judgment unit 294H functions as the logic hub within the processing unit 294, responsible for score threshold determination and final bid determination. It combines the Prob (probability of matching patient profile) received from the speech recognition processing unit 294A, the OCR processing unit 294J, and the natural language processing unit 294D and evaluation unit 294E with the Bid (bid value) calculated by the reverse auction processing unit 294G to calculate Score = Prob + Bid in real time. Only if the Score exceeds the notification threshold set in advance by the administrator is it flagged as "notification possible," and if there are multiple ties, it narrows them down to one record by referring to the company priority table and EvidenceGrade. In addition, it also evaluates the number of notifications per day, which is limited by the medical institution, and the read status recorded in the user history DB, and incorporates a governance layer to deter spamming. The notification unit 294I is an endpoint aggregation module that receives records deemed "notification possible" by the determination unit 294H and executes the actual transmission according to the channel priority rules (in-terminal banner / push notification / email / SMS / in-app message / web dashboard / HTTPS API) held by the notification control processing unit 294F. While delegating channel-specific payload formatting, template application, rich card creation, and attachment encryption to channel-specific microservices, it logs the response code, read / unread status, and delivery confirmation in a unified format after transmission and streams them to the user history DB. This results in loose coupling between the transmission permission determination logic and the delivery infrastructure layer, allowing for hot-swapping of channel additions and UI modifications without system downtime. The OCR processing unit 294J implements a pipeline for image preprocessing (trapezoidal correction and noise reduction) → layout analysis → character recognition → medical dictionary-based postprocessing for electronic medical record screens and paper report images captured from the camera mounted on the information terminal. The extraction results are sent to the natural language processing unit 294D as "medical record display text" and integrated with the speech recognition data. The judgment unit 294H compares the two, and if the terms match, the notation on the medical record side is adopted as the preferred notation; if they do not match, the relevant word is kept with an uncertain flag and excluded from the promotion judgment. This automatically corrects oral errors and fluctuations in speech recognition, ensuring a high level of reliability in the consistency between medical record information and promotion conditions.

[0057] Figure 4 is a block diagram showing the internal functional configuration of server 20. Each subunit of the control means 290 is configured for redundancy across multiple servers and regions, enabling failover and load balancing.

[0058] The communication means 220 uses encrypted communication for data transmission and reception with the user terminal 1, the medical system 3, and the external mail / SMS gateway, ensuring the security of the entire system. The storage means 280 stores temporary data and intermediate results during execution as a work area 281, and the screen definition storage area 284 holds layout information for side panel displays and notification templates. The application program 282 includes control code that realizes the series of processing flows shown in Figures 5 and 6, and the control means 290 is the central unit that manages its execution. The operation management dashboard is equipped with a slider-type GUI that allows immediate adjustment of α (semantic fit weight), β (bid value weight), and γ (physician preference weight) within the range of 0.0 to 2.0, and the set values ​​are immediately reflected in the auction parameter area 283C via WebSocket.

[0059] The control unit 290 comprises multiple subunits. The input acquisition unit 290A2 acquires data from input devices 230 (keyboard 231, mouse 232, etc.) and voice recording devices, and relays it to the processing unit 294. The physician terminal UI unit 290A1 is responsible for displaying screens and receiving operations on the user terminal. The evaluation / selection control unit 290A3 identifies the optimal candidate by referring to the condition description DB 283A and user history DB 283B based on scores from the natural language processing unit and similarity evaluation unit. The bid management unit 290A5, which is responsible for the auction mechanism, reads the coefficient settings in the auction parameter area 283C and works in cooperation with the reverse auction processing unit 294G (see Figure 3) to determine the highest bid candidate. The notification hub processing unit 290A4 manages the notification device 250 (speaker 251, email transmission, etc.) and banner output to the user terminal, realizing the function of delivering identified information to physicians through appropriate channels.

[0060] The input acquisition unit 290A2 can also acquire biometric information and data from wearable sensors via an IoT device integration plugin API. The storage means 280 can employ a hybrid storage configuration including a GPU cache and NVMe storage, and supports high-speed inference of large-scale models.

[0061] The area of ​​the condition description database 283A stores a set of records of "condition description data." Each record has a unique condition ID (CondID) as the key and possesses attributes that the matching algorithm directly references, such as an embedding vector, trigger phrases, keywords, logical operators (LogicalOp), and revision history (VersionID, RevDate). Furthermore, reference links to related information (display text, media URI, evidence rating, etc.) are also linked here, allowing the evaluation unit 294E to immediately retrieve detailed information after calculating the similarity score. The condition description database 283A stores diverse information without limiting the provider to companies, academic societies, equipment manufacturers, etc., and filtering by source type is also possible.

[0062] The user history database 283B stores user operation history and notification history acquired for each individual physician terminal 1 and session in chronological order. Specifically, it records the timestamp and user ID of text input saved in step S504), the ID and channel type of the condition description data notified in step S509, the read / unread flag, and the status of the re-notification flag. This information is used for context weighting in subsequent matching and for logic to suppress consecutive excessive notifications to the same user. Furthermore, the user history DB 283B stores free-form history including chat logs, metadata, and sentiment analysis results, which can be widely used for context weighting and excessive notification suppression logic. Furthermore, in the reverse auction processing flow shown in Figure 6, the tie clustering priority reference process S603A is executed after the bid information generation S603. In S603A, the set of candidates that exceed the threshold is clustered according to their score equals, and a primary tie-break is performed by referring to the provider priority table set in advance by the administrator. This makes it possible to uniquely rank multiple candidates with different providers even if they are tied, and reduces the processing load of the subsequent normalization score calculation S604 and reverse auction S605.

[0063] The auction parameter area 283C stores parameters (α, β) used by the reverse auction processing unit 294G for calculating bid scores, the number of top successful bids (TopX), a tie-break algorithm selection flag, and the last update date. These can be updated from the management screen or the automatic tuning module, and by reflecting them in the bid calculation (S603) and successful bid conditions (S605) of Embodiment B, flexible auction operation can be achieved according to the operational policies and cost efficiency requirements of each medical institution. Furthermore, the auction parameter area 283C can dynamically update the α / β coefficients and TopX value from the GUI or the automatic tuning module, and also supports multi-tenant operation.

[0064] The promotion database 283D stores the following information in a hierarchical structure for each pharmaceutical company and drug. At the top level is the "product meta record" with DrugID as the key, which holds seven series of attributes in JSON format: (a) product name, (b) active ingredient name, (c) approved efficacy and effects, (d) dosage and administration, (e) contraindications / precautions and side effects, (f) company identification information, and (g) arbitrary tags assigned by the company (e.g., academic society recommendation level, market launch phase). In the middle layer, 1 to n "patient profile templates" are associated with each drug, and each template stores EmbedVector_P (patient profile embedding vector) and threshold recommendation value Thr_P. Further down the layer, there is "promotion assets," which contains media-specific URIs such as HTML banners, PDF materials, webinar URLs, and contact information for the assigned MR, as well as the UI template IDs used to display them. Each asset is assigned a Bid (bid price), budget balance, listing period, and valid / invalid flag, which are referenced in real time by the reverse auction processing unit 294G. With this three-tiered structure, the determination unit 294H is First, the EmbedVector_P from the patient profile template and the EmbedVector_S obtained from the clinical session are compared to calculate Prb. Next, from the asset group associated with the same drug, those that are within their validity period and have a remaining budget are extracted as candidates, and the Bid is read. The asset URI of the record with the highest combined Prob+Bid score is passed to the notification unit 294I and distributed via the specified channel. This is how the database functions. The coefficient learning module for optimizing α and β employs Q-Learning, autonomously updating the coefficients in a nightly batch using the bid results and physician click-through rates as rewards, and reflecting the changes on the next business day. Furthermore, the BID obtained in the normalized score calculation S604 is dynamically updated by the Q-Learning coefficient optimization module, which is executed in the nightly batch, and reflected in S604 on the next business day. This system asynchronously sends guardrail detection results to a log server in encrypted hashed JSON format as evidence of regulatory compliance, and retains them for two years. The log items consist of a CondID regulation flag detection time hash value, and a Blockchain linked hash method is used to prevent tampering.

[0065] Figure 7 is a schematic diagram showing the hierarchical structure in which condition description data is managed and used for evaluation and notification processing. The top-level "condition description record" uses a unique condition ID as a key and holds trigger vectors, logical operators, and key keywords used for matching. The middle-level "meta-attribute" layer links dynamic weighting information such as patient context, urgency, and cost efficiency, and is referenced as threshold adjustments during real-time CDS processing and as bid coefficients in reverse auctions. The lowest-level "related information" layer stores text excerpts, links to images / videos, and evidence ratings that are actually presented to physicians, and is used as content sent from the notification control unit to the output channel according to the combination of selected condition description records and meta-attributes. This three-tiered structure efficiently and hierarchically distributes the processing from condition matching to notification, achieving both flexible scalability and high operability. Furthermore, this hierarchical structure employs a general-purpose schema that can be newly extended to image finding matching and 3D model linkage functions.

[0066] In other words, in this invention, "condition description data" refers to a knowledge artifact that determines whether a condition is met by comparing it with conversational text during medical treatment or derived text generated therefrom, and notifies relevant information when it is met. The condition description data is broadly composed of three elements: "condition body," "related information," and "meta-attributes." The condition body includes diverse content such as drug contraindications, academic society guidelines, and medical device manuals. The related information holds specific display text, reference URIs, and evidence ratings, while the meta-attributes have attributes used for dynamic evaluation, such as contextual weights, urgency levels, and cost indicators. This structure allows medical information from these different formats and sources to be handled as a single format via a unified API, consistently achieving advanced similarity matching and notification control. Embodiment A

[0067] The overall control flow shown in Figure 5, as an explanation for Embodiment A of this system, realizes highly accurate and efficient clinical support processing through the coordinated execution of the processing means 294 and the control means 290 / storage means 283. Embodiment A enhances access control in compliance with the Medical Information Protection Act by inserting an authentication and authorization module in the preceding stage.

[0068] The input acquisition unit 290A2 acquires input data (step S501). Data is acquired from the user terminal 1, the voice recording device, and the image / video acquisition device. The inputs handled here are multimodal, including voice, chat, free text, images, and videos. In input acquisition (S501), the acquisition of continuous data from the message log API and wearable sensors can also be processed using the same framework. Next, the speech recognition processing unit 294A performs speech recognition on the acquired voice data, converts it to text (STT), and outputs string data (step S502). The speech recognition processing unit 294A can further improve the accuracy of recognizing medical-specific terminology by combining a medical engine and a specialized dictionary. This system is implemented on the Kubernetes container management platform. The speech recognition microservice, generative AI microservice, and reverse auction microservice are each deployed as independent Pods, and the HPA (Hyperscaled Platform) horizontal scaling mechanism increases or decreases the number of replicas based on a threshold of 70% CPU usage. MetricsServer is used for metric collection, and external access is routed to the cluster via an API gateway.

[0069] Next, the control means 290A2 assigns a user identifier (user ID) (patient ID / doctor ID) to the text obtained in S502 and links it to subsequent processing (step S503). The input acquisition unit 290A2 and the data storage area 283B (user history DB) of the storage means 280 are used to save the text with the user ID (step S504). Two-factor authentication, such as facial recognition or linkage with an RFID card reader, can be incorporated in the user ID assignment (S503). All text saving (S504) is performed in encrypted format, and audit logs compliant with the laws, regulations and privacy requirements of each country are output.

[0070] Next, in metadata matching (similarity calculation) (step S505), the following two-stage process is performed. (1) The natural language processing unit 294D tokenizes the conversation text / OCR text obtained in S502 and S503 and generates embedding vectors. At the same time, it concatenates and normalizes at least two items from the metadata (a) product name to (g) pharmaceutical company information stored in the promotion database 283D and generates embedding vectors for each record. (2) The evaluation unit 294E calculates the cosine similarity between the embedding vector and all metadata in parallel and quantifies it as Score = cosθ. At this time, a weight (e.g., contraindications = 1.5, usage = 1.2, etc.) is multiplied for each metadata type to calculate a composite score, which allows for the priority evaluation of clinically important items. The similarity score is passed directly to the subsequent threshold determination (S506), and the top k metadata IDs and weighted scores are temporarily stored in the work memory and used as input for resolving tie candidates and reverse auction processing. In this way, S505 performs high-dimensional semantic matching of "input text ⇔ product metadata" in a single operation, quantitatively evaluating contextual relationships that cannot be detected by simple keyword matching. The Kubernetes HPA configuration is set with a CPU usage threshold of 70%, a minimum of 2 Pods, and a maximum of 16 Pods, guaranteeing an average response time of less than 5 seconds even during sudden load spikes. Metrics are collected using PrometheusExporter, and automatic scaling out is triggered when the alert threshold of 90% is reached.

[0071] Next, the score obtained in step S505 is subjected to similarity determination (Score ≥ 0.8?) (step S506), and the evaluation / selection control unit 290A3 compares it with a threshold of 0.8. If it is less than 0.8, the process returns to S502 and waits for the next input data. On the other hand, if it is greater than or equal to 0.8, the process proceeds to the next step (step S506). In addition, specialized models such as BioBERT and ClinicalBERT can be used for embedding generation, and the number of vector dimensions and model update frequency can be flexibly changed. The similarity threshold can be dynamically calculated from a trained model, and adaptive threshold control can be performed according to the patient's condition and urgency.

[0072] If there are multiple candidates that exceed the threshold in step S506, a tie determination is performed, and the evaluation / selection control unit 290A3 works in cooperation with the evaluation unit 294E to rank the candidates with the same score by referring to the company priority table (storage area 283C) (step S507). Alternatively, in the tie determination / auction (step S507), for the candidate set C= that exceeded the threshold in the preceding step S506, the following multi-stage processing (1) to (4) is executed in one step. (1) Tie clustering The evaluation and selection control unit 290A3 automatically clusters records in the candidate set that have the same similarity score (or within a predetermined difference) and generates tie-score clusters G1, G2, ... (2) Primary tiebreaking using a priority table For each cluster, the enterprise priority table (storage area 283C) is referenced and sorted in ascending order using the provider rank as the key. Records whose rank is uniquely determined at this stage remain, and only records with duplicate ranks in the priority table are sent to the next stage. (3) Reverse auction bidding For the remaining records, the reverse auction processing unit 294G is activated, and a normalized score Bid* is calculated from parameters such as EvidenceGrade, CostIndex, and Bid value. The record with the highest Bid is considered the winning bidder, and the TieWinner flag is assigned to it. (4) Result packing The final ranking, TieWinner flag, Bid*, and priority rank are attached as metadata, and the top X (default 2) are stored in memory as a notification candidate list R. This allows the decision-making process, which was previously done in two stages (tips resolving → bidding), to be completed in a single step, reducing average latency by approximately 40% while simultaneously selecting the optimal record that satisfies fairness (rank), clinical validity (Score), and economic efficiency (Bid) in real time. Furthermore, the company priority table can be updated instantly from the administrator portal, and score adjustments can be made using the pre-configured OverrideWeight. If notification transmission fails three times in a row, the backup channel will automatically switch, and attempts will be made to resend the notification in the following order: first priority: in-device banner; second priority: email; third priority: SMS. If all channels fail, a push notification will be sent to the assigned MR terminal, and a FailSafe flag will be recorded in the user history database. Manual approval will be required for resending.

[0073] Here, the company priority table defines which provider's information should be prioritized for presentation to physicians when multiple conditional description data with the same similarity score are candidates. By pre-setting rankings for each information source, such as companies, academic societies, and equipment manufacturers, the system uniquely narrows down the notification target according to these rankings in the event of a tie. Even if the contract status or usage policy of a medical institution changes, the operational policy can be flexibly switched simply by updating this table, allowing for priority management without system modifications. The company priority table consists of an ID that uniquely identifies the provider, a type such as "company," "academic society," or "equipment manufacturer," and a numerical priority. It also stores the update timing and start / end dates indicating the validity period, and by multiplying by an OverrideWeight (correction coefficient) as needed, finer control than simple ranking can be achieved. Processing using this table begins with the natural language processing unit calculating the similarity score, and then the evaluation / selection control unit detects candidates with the same score. At that point, the company priority table is referenced for multiple records with the same score, and the priority of each provider is read. The control unit automatically identifies the highest-ranked record (lower numbers indicate higher priority) according to these priorities, and re-evaluates it by applying OverrideWeight to the score as needed, ensuring flexibility beyond simple ranking. Only the selected conditional description data is delivered to the doctor's terminal via the notification control unit, so even if the contract or operational policy changes, the priority of the presented information can be easily switched with a single table update.

[0074] Next, the notification control processing unit 294F and the notification hub processing unit 290A4 select the optimal notification channel, such as a side panel banner, email, or SMS, considering the UrgencyLevel and user environment corresponding to the candidate information (step S508). In notification channel selection (S508), new channels such as IoT device voice notifications and AR overlays are also included. The notification hub processing unit 290A4 transmits the information to the user terminal 1 within 5 seconds via the selected channel, presents the results to the doctor as a real-time CDS (step S509), and then terminates this subroutine. Embodiment B

[0075] The reverse auction selection process shown in Figure 6 is executed in cooperation with the processing means 294 and the control means 290 to implement a reverse auction mechanism in which multiple condition description data providers compete in bidding, enabling the automatic selection and presentation of optimal medical information. The vector similarity search process is performed in the following six stages. 1. Convert the input text into a numerical vector using the embedding model. 2. Load the pre-processed embedded index into memory as the search target. 3. Extract a candidate set using the approximate nearest neighbor search algorithm FAAIST or HNSW. IV. Select the top K items based on distance values. 5. Eliminate low-scoring candidates using threshold testing. 6. Output the IDs of the remaining candidates as the identification result. Furthermore, the index generation is updated continuously in a separate thread.

[0076] First, the evaluation / selection control unit 290A3 retrieves condition description data and obtains all target condition description records from the condition description database 283A (step S601). The condition description data retrieval (S601) can also be implemented using NoSQL or graph databases, enabling low-latency retrieval of large amounts of data.

[0077] Next, the evaluation / selection control unit 290A3 retrieves a list of providers from the auction parameter area 283C (step S602). It reads a list of identifiers and a priority table (priority, correction coefficients α, β, etc.) for each provider (company, academic society, equipment manufacturer) making a bid. In retrieving the list of providers (S602), it is also conceivable that the list may be dynamically retrieved from LDAP, internal directory integration, or SaaS-type management services.

[0078] Next, the reverse auction processing unit 294G references the EvidenceGrade and CostIndex of the corresponding provider for each condition description record, assembles bid-based initial information, and generates bid information (step S603). In S603, sentiment analysis results and real-time workload indicators can be added as sub-parameters to extend the multivariate evaluation of bids.

[0079] Next, the reverse auction processing unit 294G quantifies the bid information from step S603 using an expression with coefficients α and β held in the parameter area 283C, and calculates a normalized score for all candidate records (step S604). The normalized score calculation (S604) can be replaced with a multi-objective optimization algorithm or a machine learning-based scoring method. Bid=α×EvidenceGrade-β×CostIndex

[0080] Next, the reverse auction processing unit 294G compares the Bid values ​​calculated in step S604 and marks the condition description data with the highest Bid as a candidate for "winning bid," thus performing a reverse auction (winning bid determination) (step S605). The reverse auction (winning bid determination) (S605) can also include a multi-round auction and a test bid function for simulation. The dashboard for system administrators includes a settings screen where the clinical fit weighting coefficient α, economic value weighting coefficient β, and priority correction coefficient γ can be adjusted using sliders. By adjusting the slider and selecting update, the internal parameters of the evaluation unit are immediately reflected via real-time web sockets, enabling a balance between notification accuracy and bidding efficiency. The line chart streams the number of notifications, average delay, and bid success rate trends, allowing administrators to immediately see the effects of coefficient adjustments.

[0081] Next, the reverse auction processing unit 294G (or the bidding management unit 290A5) extracts only a predetermined number (TopX) from the group of potential successful bidders and identifies the top X bids to be notified (step S606). The criteria for selecting the top X bids (S606) can be dynamically changed according to the real-time workload and budget allocation. Subsequently, the notification control processing unit 294F and the notification hub processing unit 290A4 distribute the relevant information for the identified top X bids to the physician terminal 1 via appropriate channels such as side panel banners, email, and SMS, depending on the UrgencyLevel and the status of the user terminal, maximizing the efficiency of information reach within the limited consultation time (step S607), and then terminate this subroutine. Embodiment C

[0082] The integration of the real-time clinical decision support function (Embodiment A) and the reverse auction-based information selection mechanism (Embodiment B) described above first executes real-time CDS processing according to Embodiment A, performing input data acquisition, text conversion, score calculation using embedded vectors, threshold determination, tie resolution, notification channel selection, and notification to the physician terminal within 5 seconds. At this time, for candidate groups that the evaluation / selection control unit 290A3 determines to have a tie score, the process is not terminated there, but control can be transferred to the reverse auction mechanism of Embodiment B (Figure 6). That is, when a tie candidate is detected, the control means passes the condition description data and the list of providers 283C to the reverse auction processing unit 294G, and the optimal information is selected in the flow of Bid calculation → winning bid determination → selection of the top X items. After the reverse auction processing, the notification control processing unit 294F and the notification hub processing unit 290A4 receive the selection results again and make a final notification to the physician terminal 1 via the optimal channel such as banner, email, or SMS according to the UrgencyLevel and operational policy. In this way, the system seamlessly transitions from the real-time CDS function of Embodiment A to the reverse auction method of Embodiment B, achieving a configuration that balances both "immediacy" and "reach efficiency." Furthermore, Embodiment C allows for the construction of a more advanced analysis flow by linking with an external AI platform or DICOM image analysis API and applying a custom model. [Example 1]

[0083] [A reverse auction-type recommendation mechanism specializing in the oncology field] This embodiment describes a tumor-specific reverse auction type recommendation mechanism that targets only conditional description data based on package inserts for anticancer drugs. The aim is to improve the efficiency of matching medical practice with pharmaceutical companies by utilizing a generation AI model as a control unit and displaying advertising banners on physician terminals.

[0084] First, pharmaceutical companies A, B, and C extract information such as "indications," "recommendations by treatment line," and "contraindications for concomitant use" from the package inserts (PDFs) of the anticancer drugs they sell, and store it in a predetermined JSON template. Furthermore, they set a bid value (BID) indicating the priority of their recommendations (e.g., Company A = 120 points, Company B = 90 points, Company C = 75 points) and send it to the platform. In response, the hospital server extracts patient ID, tumor type, stage, past treatment, and administration history from electronic medical records and claims data from the past three years, and builds a prescription history table for each patient.

[0085] During each consultation, the doctor-patient conversation recorded by a ceiling-mounted microphone is transcribed into text by a speech recognition engine, and a draft medical record in SOAP format is automatically generated. Based on the key keys extracted from this draft (tumor type, treatment line, PerformanceStatus, etc.), a query is issued to Elasticsearch to retrieve the top 20 similar medical records. Each similar medical record is assigned the anticancer drug code actually used and a treatment outcome label (effective / ineffective).

[0086] Next, using the drug codes extracted in the previous step as keys, the corresponding package insert JSON is retrieved to create a set of candidate drugs suitable for treatment. The BID values ​​from each company received in the previous step are also merged into this set to form a list for the reverse auction.

[0087] The generating AI model is given prompts containing patient information such as SOAP JSON, a list of candidate drugs, excerpts from package inserts, and treatment results of similar past cases, and is instructed to "select the top two drugs considering clinical validity and BID, and list the reasons in 50 characters or less." The model responds with "Drug A, Drug B," and provides a concise explanation as the reason, such as "Matches indication XX + PS◎ / high response rate."

[0088] This system treats the results returned by the AI-generated data as a list of successful bidders. For pharmaceutical companies with top-ranking drugs, it displays a pop-up on the physician's terminal containing an advertising banner, a webinar URL, and a direct dial number for the assigned medical representative (MR). Simultaneously, the successful bidder information is posted to each company's dashboard, and companies that did not win the bid execute a loop process that automatically adjusts the BID value in preparation for the next consultation.

[0089] Ultimately, the actual prescribed anticancer drug codes and patient outcomes are returned to the platform, and the prompt responses and BID values ​​of the generated AI model are used for weekly retraining. This completes a feedback loop that maximizes the advertising ROI (return on investment) of pharmaceutical companies while ensuring clinical validity. [Example 2]

[0090] Figure 8 shows a use case in which this system displays a summary of the speech recognition results and corresponding promotional information on a single screen in card format via an information terminal. The upper section displays the "Today's AI Speech Recognition" text acquired during the consultation, while the lower section displays key messages (summary of chief complaint, findings highlights, etc.) extracted by the generating AI.

[0091] Figure 9 shows that the upper section displays the "Today's AI Speech Recognition" text acquired during consultations, while the lower section displays key messages extracted by the generating AI, along with related advertising banners such as "Click here for the lecture on diarrhea treatment drug A" and "Article on how to diagnose laxative use." Only the top two promotional cards identified by the reverse auction processing unit are displayed, and tapping them provides a deep link to the pharmaceutical company's dashboard or the conference abstract page. This allows doctors to view consultation notes and the latest promotional information in one place, enabling them to make decisions without needing to switch screens.

[0092] Figure 10 shows an example screen displaying a QR code encoded with a clinical summary. The QR code functions as a portable token that combines the SOAP summary generated during the clinical session, associated promotion IDs, and hashed patient identifiers into a single payload. In the examination room, the medical record input tablet displays this code simultaneously with the summary confirmation, allowing doctors and nurses to launch the mobile CDS app simply by scanning it with their smartphones, enabling them to review and add information to the summary without waiting for a cloud query. If a doctor presents the code during a conference or interview, the MR terminal can retrieve the information and securely transfer it to the pharmaceutical company's CRM, allowing for immediate receipt of promotional materials and conference abstracts. Even in environments with unstable networks, such as hospital wards and local clinics, the system caches the summary in a local web view and transmits it in the background after reconnection, maintaining convenience regardless of communication status. The code payload is encrypted with AES-GCM and has a sufficiently short expiration period imposed by a timestamp, and the patient ID is hashed with HMAC-SHA-256, so clinical information will not be leaked even if scanned by an unauthorized terminal. For external organizations that publish FHIR endpoints, the system is designed to automatically send summaries in / Bundle format after scanning, and can also be used for RWE collection for research purposes. In this way, QR codes are used as a hub to securely and instantly transfer only the minimum necessary metadata without leaving detailed clinical information outside the medical record.

[0093] Figure 11 shows (A) When the doctor taps the camera icon displayed on the examination tablet, a camera preview appears on the same screen, and three modes—"barcode / QR code reading," "EMR screen capture," and "video recording"—are presented as an overlay. After tapping to select a mode, the device enters a shutter waiting state, and the input stream flows in real time from the terminal's streaming API into the analysis pipeline. (B) This shows the state when the "Barcode / QR Reading" mode is being executed, with the QR code centered in the viewfinder and being photographed. The terminal library completes the decoding, and the extracted patient ID, hospitalization number, and initial name are generated as JSON fields and attached as unique keys to all records in subsequent processing. This integrates the speech recognition text, image analysis results, and OCR extracted text within the same patient session. (C) The next example shows the selected "EMR screen capture" mode, where a doctor is taking a single shot with the prescription tab of the electronic medical record open. Immediately after the capture, the terminal's OCR engine starts up, and the coordinates of fields such as drug name, dosage, and test value are visualized in a heatmap while text is extracted. The extracted text is immediately passed to the SOAP generation pipeline, where it is integrated with the clinical findings obtained from the audio to form the input vector for metadata matching (similarity calculation). The seamless flow from A to B to C creates a highly reliable dataset where patient identification information and medical treatment text are bundled with the same timestamp, enabling subsequent generation AI matching and reverse auction decisions to proceed without delay. [Example 3]

[0094] The present invention is not limited to the above embodiments. The components may be combined, omitted, or substituted as appropriate.

[0095] (1. Information processing system (Claim 1)) As one form of implementation, the "information processing system" described in claim 1 may be an in-hospital installation type, a mobile terminal processing type, an external cloud-linked type, etc. One form of implementation of an information processing system: • On-site installation: Rack-mount computing server, shared file device, 10 Gigabit compatible switch • Mobile device-side processing type: Smartphone controlled by management software, processor with AI calculation circuitry, built-in storage • External cloud integration type: Gateway for medical data conversion, encrypted Web API, virtual private network • Combined type: Inference is performed within the device, and only the summary data is sent externally. • Redundant configuration: Load balancing equipment with automatic switching function • Compliant with guidelines: In accordance with the Medical Information Security Management Guidelines, the Clinical Research Act, and the Personal Information Protection Act.

[0096] (2. Obtain medical textbooks) Processing ) One form of implementation is "obtaining medical textbooks." Processing This includes the following: speech recognition, character recognition, sensor data acquisition, etc. Text data based on That's fine. Medical text Obtain One form of implementation; • Audio: The conversation between the patient and the doctor is transcribed in real time using a general speech recognition engine. • Character Recognition: The electronic medical record screen is captured with a high-resolution camera and analyzed by a character recognition engine. • Handwriting recognition: The handwriting recognition engine reads the paper questionnaire. • Wearable devices: Obtaining data from devices that measure things like fingertip oxygen saturation as standardized observation data. • Patient input: Receive patient report information via the chat function of the Personal Health Record (PHR) app.

[0097] (3. Drug information (Claim 1-4)) As one form of implementation, the "drug information" described in claims 1-4 may include not only the pharmaceuticals listed below, but also medical devices, regenerative medicine products, and the like. One form of providing drug information: • Pharmaceuticals: efficacy, contraindications, price, product code • Medical devices: Device identification number, sterilization method, insurance classification • Software medical devices: Version history, user manual • Regenerative medicine products: Manufacturing lot, storage temperature information • Digital therapeutic apps: Patient usage indicators, trial numbers

[0098] (4. Promotion (Claim 1, 3, 4, 8)) As one form of implementation, the "promotion" described in claim 1, etc., may be the following information presentation form: • Summary of conference presentation materials and QR code for reservations • Case report webinar participation guide • Application form for trial use of remote monitoring equipment • Banners advertising recruitment for clinical trial participants (displayed separately for each region)

[0099] (5. Specification means (Claim 3-12-14)) As one form of implementation, the "specific means" described in claim 3, etc., may be the search method or inference method shown below. One form of implementation of specific measures: • Combined search: Combining keyword search and similarity search. • AI inference: Decision-making using large-scale language models • Knowledge-based reasoning: Matching using a medical terminology dictionary • Decision tree: Classification based on severity and drug price as branching conditions. • Integrated evaluation: Final decision made by combining the results of multiple models. • Rule-based: Contraindications / recommendations are determined by predefined IF-THEN rules. • Word extraction: Symptom names and drug names are extracted using morphological analysis and then compared with a dictionary. • Phrase extraction: Extract clinical phrases using n-gram / chunk analysis and match them with templates. • Dependency structure analysis: Use dependency parsing to understand and score the "symptom → disease → treatment" relationships. • Vector Similarity Search: Embed medical text and package inserts and extract nearby drugs using cosine similarity. • Graph Inference: Evaluate path length and centrality on a symptom-disease-drug knowledge graph to extract relevant drugs. • Time series analysis: Analyze past medical records using LSTM or similar methods to detect changes in treatment phases. • Reinforcement learning: Reward physician feedback for updating specific policies online.

[0100] (6. Regulation (Claim 8)) As one form of implementation, the “regulations” described in claim 8 may refer to the following domestic and international laws and guidelines. One form of regulatory implementation: • Domestic: Advertising regulations based on the Pharmaceuticals and Medical Devices Act, medical advertising guidelines, and the Personal Information Protection Act. • Overseas: US FDA advertising guidelines, EU medical advertising guidelines, GDPR for personal data protection, etc. • Checking method: Legality is confirmed in two stages: standard rules + AI judgment.

[0101] (7.Notification (Claims 4, 6, and 7)) As one form of implementation, the "notification" described in claim 4, etc., may be a display using the terminals or services shown below. One form of notification: • Pop-up window for electronic medical records • Vibration and short message display on smartwatch devices • On-screen overlay for augmented reality glasses • Event notification based on the Standard Medical Data Exchange Specification • Interactive email notification with approval button

[0102] (Contents of each claim and a detailed embodiment) (Claim 2. Metadata assignment) As one embodiment of the implementation, the "metadata" described in claim 2 may be as follows: One form of metadata implementation: • Drug identifier: Product code, approval number, etc. • Specific parameters: disease code, renal function values, search score • Audit trail: Name of algorithm used, execution date and time, hash value for verifying the result. • Restriction tags: Flags indicating compliance with domestic and international advertising regulations. • Terms of use: Information expiration date, whether redistribution is permitted, point redemption rate

[0103] (Claim 3. Evaluation index display means) As one embodiment of the implementation, the "evaluation index display means" described in claim 3 may be as follows: One form of implementation of an evaluation index display means; • Screen badge: Displays compatibility in 5 different colors. • Bar graph: Visualizes the impact of each element. • Warning tooltip: Contraindications and other information are displayed in red. • History graph: Displays past score trends as a simple line graph. • Printed report: Evaluation results are automatically attached in tabular format.

[0104] (Claim 4. Metadata matching + multi-channel notification) As one embodiment of the implementation, the metadata matching conditions and notification method described in claim 4 may be as follows: One form of metadata matching: • Matching criteria: [Both efficacy and contraindications match] / [Similar active ingredients and price range], etc. One form of notification method; (i) Display within electronic medical records (ii) Official SNS accounts (iii) Team chatbot (iv) HTML email (v) SMS (vi) Real-time web notifications (vii) Standard medical data notifications

[0105] (Claim 5. Patient barcode linking) The "acquisition of patient identification information" described in claim 5 can take several routes depending on the operating environment inside and outside the hospital. Firstly, it is a machine-readable medium type, where a camera reads a two-dimensional code / barcode printed on a wristband or medical card, or a near-field wireless tag (NFC / RFID) is held over a reader. This has the advantage that linking can be completed simply by tapping at the bedside, and if the tag is lost, it can fall back to the barcode. Secondly, there is an electronic medical record (EMR) integration type where the system is launched via a URL launcher while the target patient is being displayed in the EMR, and the patient ID (and facility ID, if necessary) is added as a query parameter to the URL to initiate the transition. Methods that receive the ID by directly reading the display context, calling a dedicated API, or receiving an event notification are also included in this type, and since the voice recognition screen is launched with a single click, barcode operation is eliminated. In a multi-facility environment, facility IDs can be sent concurrently to prevent ID collisions. Thirdly, there is an external application integration type in which the patient ID is embedded in an electronic token (OAuth2 / JWT, etc.) issued by the patient's PHR app or telemedicine app, and this system receives it via the network. This allows for linking home and online consultations using the same workflow as in the hospital. Fourthly, there is a reservation information matching type that connects to the medical appointment system and automatically retrieves the patient ID from the corresponding reservation record by matching it with the reception time and examination room number. In this method, the linking from reception to the examination room is completed automatically without ever reading a code. As a final backup, having a manual input system where healthcare professionals manually enter patient IDs and confirm them via a double-confirmation dialog ensures that operations can continue even in the event of missing tags or communication failures. Patient identification information obtained through any route is retained as contextual information at the start of the session and is added to the medical text data or derived data before output. Furthermore, the time of receipt of the identifier, the acquisition route, and source metadata (e.g., source URL, device ID) are encrypted and stored in the audit log to ensure traceability that can be verified at a later date.

[0106] (Claim 6. QR / barcode output) The "data output format" described in claim 6 may include, in addition to standard static QR / barcodes, concatenated QR codes that sequentially encode multiple data, hospital-specific encrypted QR codes that store the same information in different encrypted blocks by switching encryption keys for each medical institution, and animated concatenated QR codes that present large amounts of data by sequentially rendering several frames. The embedded information may include medical information or information processed therefrom, or the contents of a specified drug ID, patient ID (or its hash). The generated codes can be attached within the hospital using a label printer or attached to paper medical records by outputting them as PDFs. In addition, these QR codes can be read by reading a QR reader with a keyboard emulation function, allowing for secure data exchange without a network connection. In particular, hospital-specific encrypted QR codes can only be deciphered using a QR reader specific to that hospital, thus minimizing the risk of patient information leaks during BYOD (Bring Your Own Device) operations.

[0107] (Claim 7. Electronic medical record OCR integration) One embodiment of the "OCR engine" described in claim 7 may be a character recognition model that has been pre-trained on medical terminology. Alternatively, pre-processing combining contrast correction, tilt correction, and noise reduction may be applied, and accuracy may be improved by using one or more post-processing rules such as normalization of disease name codes or standardization of dosage units. If the recognition confidence level falls below a predetermined threshold, the system prompts the user for confirmation, and if the patient ID obtained from the medical record screen does not match the barcode reading result, an immediate warning is issued. Furthermore, by using the terminal's front camera image and window capture to determine the currently focused EHR sub-window in real time and applying OCR only to the target area, the processing load is reduced, information unrelated to the patient and input fields are identified, and high-speed character recognition is achieved without disrupting the medical flow.

[0108] (Claim 8. Guardrail standard check) As one form of implementation, the "norm checking means" described in claim 8 may be as follows: One form of implementing normative checks: • Standard rules: Automatic detection using a dictionary of prohibited terms • AI Judgment: Approval or non-approval is determined using a pre-trained model that complies with advertising regulations. • Risk assessment: Assigns a score based on the degree of the violation. • Blocking criteria: Notifications are stopped if the score falls below a certain value. • Audit log: The judgment results are encrypted and stored for a certain period of time.

[0109] (Claim 9. Automatic deletion of personal information) As one form of implementation, the “deletion means” described in claim 9 may be as follows: One form of implementation of the deletion method; • Deletion timing: Automatically deleted within 5 minutes after processing is complete. • Key management: Temporary encryption keys are stored in a secure device. • Record: Saves the deletion date and time and the user who performed the operation, with an electronic signature. • Troubleshooting: If deletion fails, lock the device and notify the administrator. • Inquiry API: Allows obtaining deletion trails in standard format.

[0110] (Claim 10. Edge Computing) As one form of implementation, the "local processing" described in claim 10 may be as follows: One form of edge processing: • Device-side AI: Executes a lightweight speech recognition model within the device. • Communication protection: Connecting terminals and servers using the latest encryption protocols. • Content to send: Send only the minimum necessary summary data. • Offline countermeasures: When out of range, save temporarily and send after reconnecting. • Status monitoring: Device operation is confirmed using periodic heart rate signals.

[0111] (Claim 11. MDM-managed smartphone) As one form of implementation, the "MDM function" described in claim 11 may be as follows: One form of MDM management: • Allowed apps: Only pre-registered business apps can be launched. • Forced VPN: Enforce encrypted communication for each app. • Remote erasure: Instantly erases data on the device in case of loss. • Detection of unauthorized modifications: If modification of the device is detected, the service will be suspended. • Audit integration: Send operation logs to a centralized management system.

[0112] (Claim 12. Vector Similarity Search) As one embodiment of the implementation, the "vector similarity search means" described in claim 12 may be as follows: One form of vector search implementation: • Converting text to numbers: Converting medical documents into multidimensional vectors • Index structure: Utilizes a near-nearest neighbor data structure for high-speed searching. Similarity determination: Uses cosine similarity to extract data above a certain value. Exclusion criteria: Drugs that fall under the contraindications are excluded from selection. • Re-evaluation: The top results are re-ranked using a different model.

[0113] (Claim 13. Reverse auction selection) As one form of implementation, the "reverse auction method" described in claim 13 may be as follows: One form of reverse auction implementation: • Bidding method: Advertisers submit bid prices via secure communication. • Evaluation metrics: Both price and clinical suitability are scored. • Selection method: The information with the highest score is automatically selected. • Tie-breaking: In case of a tie, a random number will be used to determine the winner and ensure fairness. • Evidence preservation: Record results in a tamper-proof mechanism.

[0114] (Claim 14. Utilization of generation AI) As one embodiment of the implementation, the "generative AI model" described in claim 14 may be as follows: One form of implementation utilizing generative AI: (i) Context generation: Automatically generate summary text from medical records. (ii) Drug selection: AI selects appropriate drug candidates. (iii) Regulatory check: Automatic determination of whether the generated text complies with the law. • Safety measures: Input validation to remove inappropriate words • Output verification: Automatic check to ensure it conforms to the specified format.

[0115] (Claim 15. Utilization of patient self-reported information) As one form of implementation, the "patient-reported information" described in claim 15 may be as follows: One form of implementation utilizing patient self-reporting: • Input method: Patients answer via a questionnaire on a smartphone app. • Example items: Health indicators, severity of symptoms, diet, sleep duration • Data integration: Batch processing combined with medical texts. • Explanation and return: Clearly display the specific reason on the patient's screen. • Privacy protection: Apply statistical processing that does not identify individuals.

[0116] (Other embodiments [non-medical fields]) This invention is also applicable to the non-medical fields mentioned above. In that case, the concept is extended as follows. 1: Information Processing System 2: How to obtain medical texts → Conversations between customers and their customers 3: Drug information → Products that customers use to decide whether to use them for their customers. 4: Promotion → Product advertising 5: Specifying means 6. Regulations → Regulations on product advertising, regulations on the management of information terminals 7. Notifications → Notification content, notification method, and target audience. Non-medical sectors include retail, financial services, travel, real estate, energy supply, and subscription-based digital services.

[0117] (1. Information processing system (Claim 1)) As one form of implementation, the "information processing system" described in claim 1 may be a self-hosted server type, a store terminal type, a cloud-linked type, etc., as shown below. One form of implementation of an information processing system: • On-site server setup: Rack-mount servers, shared storage, 10 GbE switches • Store terminal type: A sales floor terminal incorporating a small computer and camera. • Cloud-integrated type: External cloud services using Web APIs and encrypted communication • Combined type: Quickly calculates on the device and sends only the aggregated results to the cloud. • Redundancy configuration: Prevent service interruptions with a load balancer with failover functionality.

[0118] (2. Means for obtaining customer conversations (Claim 1)) As one form of implementation, the "means for obtaining customer conversations" described in claim 1 may be voice recording, chat acquisition, sensor utilization, etc., as shown below. One form of implementing a method for obtaining customer conversations; • Audio: Call center conversations are transcribed using a speech recognition engine. • Chat: Integrates web chat and social media interactions. • Image: Store cameras capture the gaze and movements of customers. • Sensor: Detects product removal based on changes in shelf weight. • Reviews: Retrieve the full customer reviews from the e-commerce site.

[0119] (3. Product information (claims 1 and 4)) As one form of implementation, the "product information" described in claims 1-4 may include the following diverse product attributes. One form of product information implementation: • Cosmetics: Product name, ingredients, precautions for skin problems, barcode • Financial products: interest rates, risk indicators, fees, international product codes • Travel products: departure city, required documents, seat availability, CO2 emissions • Real estate property: Location, year built, expected yield, 360-degree virtual tour video • Electricity plans: Price per kWh, percentage of renewable energy

[0120] (4. Promotion (Claim 1, 3, 4)) As one form of implementation, the "promotion" described in claim 1, etc., may take the following forms. One form of promotion: • Limited-time coupon: Discount voucher with QR code • AR Try-on: A feature that allows you to try on colors and sizes on your smartphone screen. • Short video ads: A one-tap purchase button is displayed after viewing. • Point accrual: Notification of point multiplier based on purchase amount. • Same-day delivery information: Displays the same-day delivery option when the item is in stock.

[0121] (5. Specifying means (Claim 3-12)) As one form of implementation, the "specific means" described in claim 3, etc., may be in the following manner. One form of implementation of specific measures: • Purchase probability prediction: Calculates purchase likelihood using a machine learning model. • Inventory turnover rate evaluation: Weighting that takes into account inventory margin for each product. • Similar customer reviews search: Products are recommended based on similar reviews. • Rule filter: Exclude products on the prohibited sales list. • AI dialogue evaluation: Generating AI makes recommendations in response to customer questions.

[0122] (6. Regulation (Claim 8)) As one form of implementation, the "regulations" described in claim 8 may refer to the following domestic and international laws and guidelines. One form of regulatory implementation: • Premiums and Representations Act: Checks for excessive discounts and unsubstantiated claims of superiority. • Financial Instruments and Exchange Act: Block advertisements with insufficient risk explanations. • GDPR: Compliant with the right to delete and disclose personal data. • Chinese Advertising Law: Prohibits the unauthorized use of the national flag and the names of national institutions. • COPPA: Automatically excludes ads targeting children under 13.

[0123] (7.Notification (Claims 4 and 6)) As one form of implementation, the "notification" described in claim 4, etc., may be by the following method. One form of notification: • Web push notifications: Messages using the browser's notification function. • RCS: A high-performance messaging service offered by mobile carriers. • Internal chat notifications: Automatic posting to business chat. • Metaverse: Avatars distribute coupons within virtual stores • Audio watermark: Discount information is embedded in in-store background music and detected by smartphones.

[0124] As described above, each configuration explained in the medical field can be substituted and applied to non-medical businesses. The target domain, notification methods, and analytical methods may be modified as appropriate according to industry trends and operational policies.

[0125] (Example 1: A specific example using AI inference) Patient X (a man in his 60s) with advanced lung cancer visited the outpatient clinic for a second opinion. An edge device (equivalent to a smartphone) installed in the examination room showed that • Audio streaming: Doctor-patient conversations are transcribed in real time using ASR. • Screen capture: The doctor takes a picture of the medical history and test results being viewed using a mobile camera and processes them using OCR. • Metadata integration: The obtained text is stored in a buffer as "medical text" with medical context tags (speaker, time, material type, etc.). The following Japanese prompt is entered into the terminal's LLM (8B quantization model), causing AI inference to generate S (subjective information) in SOAP format (draft version). The LLM output is returned in JSO format, and a UI is provided that allows only the S portion to be converted into a QR code and transferred to the electronic medical record with a single tap. Simultaneously, the A (evaluation) / P (planning) sections output by LLM are parsed, and a rule-based determination is made as to whether they contain the words "Drug A (approved PD-L1 antibody)" or "Drug B (next-generation antibody of the same class)." • If a hit occurs, the determination method is established as "AI inference + rule-based integrated evaluation". Add parameters such as "Specific Drug = Drug B" and "Specific Score = 0.82" to the metadata for the slot. • Physician's terminal: A promotional PDF for drug B (including examples of expanded indications and a quick reference chart for dosage) is displayed as a pop-up. • Pharmaceutical company terminal: Drug B: Sends an MQTT payload containing only the word sequence "Specific Notification". However, before notification, the system automatically performs a vector search on the package insert for drug B (latest publicly available PDF), The section on efficacy and effects lists "advanced lung cancer" = Applicability confirmed. The contraindications section lists "interstitial pneumonia" → patient CT scan shows no fibrotic shadows ⇒ not contraindicated (contraindications not confirmed → false). We verify the above in the background and only send out promotions / notifications after the "no issues" flag is raised. As a result, doctors can paste S from QR codes at their desks and reconsider treatment plans based on A / P, and pharmaceutical companies can immediately identify facilities and cases where sales opportunities have arisen. Furthermore, if the name of competitor drug C appears in A / P, it is flagged as "potential competitor drug → true," and a filter is used to suppress notifications directed to the company.

[0126] [Table 2]

[0127] The above embodiment uses AI inference (generative LLM) + rule-based judgment + metadata assignment for identification, and ensures compliance with the Pharmaceuticals and Medical Devices Act and medical advertising guidelines while also ensuring responsiveness by including an automated application check before promotional notifications.

[0128] [Table 3]

[0129] [Table 4]

[0130] [Table 5]

[0131] This ensures that both doctors and pharmaceutical companies receive the same identification results in real time, and that pre-promotion checks for indications and contraindications are automatically guaranteed.

[0132] (Example Case 2: A specific example using a webinar video by a renowned physician (Claim 1, 3, 4, 6, 13)) Patient Y (45-year-old male) with moderate to severe psoriasis vulgaris and resistance to oral medications visited a dermatology specialist outpatient clinic. An edge device (5G tablet) in the examination room detected... • Audio streaming: Doctor-patient conversations are transcribed in real time using ASR. • Screen capture: Take a picture of the treatment history tab in the electronic medical record and use OCR. • Metadata integration: Acquired text is tagged with medical context tags (speaker, time, image type) and stored in a buffer as "medical text". The following prompt is sent to the LLM (7B quantization model) on the terminal to generate S (subjective information) for the SOAP draft. The S field of the output JSON is converted into a QR code and a UI is provided that allows it to be pasted into the electronic medical record with a single tap. At the same time, the A / P section output by the LLM is parsed and rule-based determination is made to determine whether it contains the words "Drug X (IL-17A inhibitor secukinumab)" or "Drug Y (next-generation antibody ixekizumab of the same class)".

[0133] • Upon hit → "AI inference + rule-based integrated evaluation" adds specific drug = drug X and specific score = 0.88 as metadata. • Doctor's terminal: A promotional card for drug X (★Content = "30-minute webinar video on the latest evidence of IL-17A by Professor Sato of XX University") is displayed as a fixed banner on the side panel. • Pharmaceutical company terminal: Immediately sends an MQTT payload with DrugID=X, PatientHash=···Score=0.88 to notify_to =crm: / / corpC / derma. The pharmaceutical CRM compiles a list by facility that same evening and reflects it in the weekly email or MR visit plan. Before notification, the system automatically performs a vector search on the PDF package insert for drug X. • Under the "Indications and Effects" section, "Moderate to Severe Psoriasis Vulgaris" → Applicability confirmed. • In the "Contraindications" section, there is "Active Tuberculosis" → No abnormalities found on the patient's chest X-ray → No contraindications apply. The system verifies the information behind the scenes, and only sends out promotional cards / notifications after a "no issues" flag is raised. As a result, doctors can transcribe the S from the QR code and consider introducing biologics based on the A / P, and pharmaceutical companies can immediately grasp sales opportunities, compile appropriate seminar video information, and follow up via email or MR visits.

[0134] [Table 6]

[0135] [Table 7]

[0136] [Table 8] [Example 4]

[0137] Case Study 3: Specific Implementation Examples Using Search Engine Matching + Company-Provided Case Templates (Claims 1, 4, 7, 8, 12, 13) Patient Z (32-year-old female) presented to the emergency room with a fever of 38 degrees Celsius and bilateral abdominal pain. An edge device (12-inch tablet) in the examination room showed that • Audio streaming: Doctor-patient conversations are transcribed in real time using ASR. • Screen capture: Take a picture of the specimen testing system and perform OCR (extract WBC 15000, CRP 12 mg / dL). • Metadata integration: Time, speaker, and terminal ID are added to the acquired text, and it is stored in a temporary buffer as "medical text". In this example, no generation AI is used; instead, the search is performed using the hospital's Elasticsearch 7.9 (index of 3 years, 4.6 million records). The search target is a collection of "case templates + drug metadata" provided by five pharmaceutical companies (satisfying claims 4(a) to (g)).

[0138] (1) Query generation The regular expression [ICD-10=N10.*,「pyelonephritis」,「fever」,「lower back pain」] is extracted from the medical text, and the search query is formatted using Boolean and wildcards. (2) Search for similar cases The top 20 results were retrieved from the template index. 14 results with a search score >18.0 matched the template "Acute Pyelonephritis + Cefmetazon" provided by Company C. (3) Guardrail (suitability / contraindications) determination Using metadata embedded in each template record, • Applicable section: "Acute uncomplicated pyelonephritis in adults" → Applicable section confirmed = true • Contraindication clause: "History of severe hypersensitivity to penicillin-based drugs" → Patient allergy history OCR = - → No contraindications found Twelve cases that meet both conditions are considered to have passed the guardrail, and the rest are automatically excluded (Claim 8). (4) Drug scoring The drug database is referenced using the DrugAdminID of the candidate as the key. • Cefmetazone: 12 cases, 0 treatment failures → 100% effectiveness rate • No other medications apply. (5) Judgment / Notification The judgment module confirmed that the selected drug is cefmetazone. • Physician's terminal: cefmetazon administration protocol PDF + dosage quick reference chart based on renal function are displayed as a pop-up (Claim 6). • Patient barcode: When printing the IV label, [PatientID, DrugID, Dose] is converted into a QR code and the wristband is re-verified (Claim 7). • Pharmaceutical company terminal: DrugID=CFMZ20, PatientHash=···, Score=12 is immediately sent via MQTT to company C CRM (notify_to=crm: / / corpC / id). Company C compiles cases weekly, the email distribution team automatically generates e-DM for physicians, and the MR management system automatically generates visit plans (Claim 13).

[0139] This system is entirely search engine-based, eliminating the need for model drift monitoring. Since all templates and metadata are provided by pharmaceutical companies via regular XML feeds, hospitals only need to update the index dictionary for maintenance. Physicians can obtain reliable historical case statistics and dosage guidelines with a single click, minimizing delays to treatment initiation, while automatic checks of indications and contraindications ensure compliance with the Pharmaceuticals and Medical Devices Act and medical advertising guidelines.

[0140] Case 4: Specific Examples of Integrated Search Using Generating AI Agents (Claim 1, 2, 3, 4, 9, 12, 14, 16) Patient W (71-year-old male) suspected of having bacterial cholangitis complicated with diabetic nephropathy was admitted to the Department of Gastroenterology of a general hospital. In this case, the generative AI operates as a "multi-agent" and autonomously cross-searches multiple sources such as the electronic medical record DWH, the attached documents provided by pharmaceutical companies, the dosage guidelines by renal function, and the past notes of doctors to make a decision.

[0141]

Table 9

[0142] (1) Data collection phase The agent executes four subtasks in parallel and aggregates the obtained results in a temporary workspace.

[0143] (2) Inference phase (generative AI main body) Embed the aggregated four streams into the prompt and instruct Chain of Thought Reasoning. · The CoT output is left in chronological order in YAML and encrypted and saved for auditing. · When the thinking completion signal FINISH is output in Step 7, transition to downstream. (3) Guardrail & scoring For the candidate drugs presented by the generative AI (e.g., ceftazidime / piperacillin-tazobactam), · Eligibility check: attached document efficacy = "cholangitis" → true · Contraindication check: no history of severe β-lactam allergy → true · Renal dosage check: eGFR38 → automatically corrected to ceftazidime 1 g q24h · Comprehensive score: calculate α semantic compliance + β doctor preference coefficient + γ cost (Claim 16) [[ID=· 39]]Identify ceftazidime with a score of 0.91 as the specific drug and exclude other candidates. (4) Medical record draft generation & notification The generative AI returns a SOAP draft (S → symptoms, O → findings, A → cholangitis + CKD St3, P → ceftazidime 1 g q24h) in JSON.

[0144] [Table 10]

[0145] • Doctor's terminal: Present a QR code that allows for one-tap copying of the above P. • Pharmaceutical company terminal: Send DrugID=CAZ10, PatientHash=···, Score=0.91 via MQTT to company D's CRM (notify_to setting). • Attached promotion: The "CAZ administration manual PDF by renal function" and the "15-minute video link to a webinar by a prominent infectious disease specialist" registered by Company D are displayed as cards on the side panel (linked to claims 3, 6, and 13). (5) Personal Information Governance The Chain-of-Thought log generated by the AI ​​is automatically deleted 5 minutes after SOAP is generated (Claim 9). The deletion hash is written to the audit database to ensure tamper prevention.

[0146] result Physicians received individualized renal dose-adjusted drafts instantly without having to perform CPU-intensive search operations, reducing the average delay to treatment initiation by 45%. Pharmaceutical companies were able to identify truly relevant cases in real time, taking into account clinical context and physician preferences, and provide webinar invitations and dosage manuals at the appropriate time.

[0147] (Case 5: Specific implementation of rule-based judgment + generation AI rule extraction) (Claim 1, 2, 4, 8, 12, 14) A 7-year-old male with a history of stroke was diagnosed with non-valvular atrial fibrillation (NVAF) during a routine outpatient visit. The attending physician is considering initiating anticoagulation therapy. In this case, the generative AI is used to convert natural language text into machine-readable rules; the identification itself is performed entirely by the rule engine.

[0148] (1) Attached document → Rule conversion phase (offline) Pharmaceutical company E provides the latest PDF package insert for its DOAC (drug Q: Idalvion). • A LangChain-based LLM tool automatically extracts the "Indications / Contraindications / Dose Adjustment / Interactions" section and maps it to the following SON schema.

[0149] [Table 11]

[0150] (2) Acquisition of patient data • Medical text: The doctor entered the medical record using voice input. "History of cerebral infarction," "CHADS2=3," and "Renal function CrCl 42 mL / min" were extracted using division. • HER-OCR: Ultrasound findings confirmed "no history of bioprosthetic valve replacement." • The data is integrated as medical data (Claim 1, 2) (3) Rule engine evaluation • The five rules with drugid=DOAC-Q registered in the rule store will be evaluated sequentially. NVAF==true→true mechanical_valve == true→false CrCl < 15 → false CrCl >= 15 && CrCl < 50 → true → Recommended capacity=30 mg OD Since all exclude conditions are false and include is true, the application check is OK. • Record that the guardrail (claim 8) has passed. (4) Creating a draft of the medical record No generation AI is used; the template engine automatically generates SOAP-P. • Start taking Idalvion 30mg once a day after dinner. • Enter Hb and Cr values ​​before starting treatment. Re-evaluate the dosage after a blood test two weeks later. (5) Notifications and Promotions • Doctor's terminal: Present the above P as a Q code (one-tap transcription). • Side banner: Displays a card for the "20-minute webinar explaining the latest evidence on DOACs" (presented by a renowned cardiologist) provided by Company E (Claim 3, 6). · Pharmaceutical company notification: Transmit DrugID=DOAC-Q, PatientHash=···, RuleMatch=true to the corporate ECRM (notify_to: crm: / / corpE / cardio) via MQTT. The pharmaceutical side aggregates cases monthly, and the MR determines whether a visit is necessary. (6) Personal information protection · The intermediate evaluation logs (true / false values of each rule) returned by the rule engine are automatically deleted after 10 minutes (Claim 9). Write the deletion hash to the audit database to ensure anti-tampering. · The strength of the generation AI + rule-based check is that words are registered first, and it is guaranteed that only the registered words will be notified to the pharmaceutical company. By combining this function with restricting the notification frequency to about once a day, it is blurred to the extent of the patients the doctor saw on a certain day, protecting personal information. (7) Effects · Since the role of the generation AI is limited to the conversion of "natural text → formal rules", there is no ambiguity in interpretation during inference and the liability for explanation is guaranteed. · Rule updates only require the enterprise to re-run the LLM every time the attached document is revised, minimizing the in-hospital maintenance load. · Doctors can directly adopt the automatically generated P, reducing the risk of incorrect dosing of DOAC in renal patients.

[0151] Although not explicitly stated in the current claims, in an advanced version of this system, it can be equipped with a function to statistically analyze the difference (gap) between the doctor's prescription result and the AI prescription simulation for the same medical input data. Specifically, 1. AI prescription simulation: Use the medical text as input to execute a specific means (vector similarity search or generation AI) and output candidate drugs and recommended dosages. 2. Gap calculation: Compare the AI-proposed drugs with the set of actual doctor prescriptions, and calculate the "number of missed prescriptions" and "non-adoption rate of recommendations" for each drug efficacy classification and enterprise. 3. Estimation of sales potential: Multiply the gap difference by the drug price and treatment period to predict the theoretically additional sales. 4. Physician Sensitivity Coefficient Correction: The expected sales revenue is obtained by multiplying the information sensitivity coefficient calculated from the click-through rate and viewing completion rate for past notifications by the actual information sensitivity coefficient, adjusting for feasibility. 5. Sales Prioritization: Sorting expected sales in descending order, the system automatically allocates sales resources such as MR visit schedules, email distribution priority, and seminar invitation slots. It should be noted that this series of processing flows, as well as the mechanism for generating sales priority tables based on expected sales, represent novel inventive elements that may be described as independent or dependent claims in future patent applications. [Industrial applicability]

[0152] The information processing program and system according to the present invention can be integrated and operated within electronic medical record systems and clinical information platforms in medical institutions, and can be applied to real-time clinical decision support (CDS) in clinical settings such as hospitals and clinics. Furthermore, the function of automatically selecting information by having conditional description data provided by pharmaceutical companies, academic societies, medical device manufacturers, etc., compete using a reverse auction method can also be applied to cloud-based subscription services by medical information service providers and to integration into hospital software products. Furthermore, it is expected to have practical applications in a wide range of medical-related industries, including deployment to telemedicine platforms and mobile applications, support for clinical data analysis at academic research institutions, and use in medical education simulations.

[0153] [Note D] Computer-readable recording media This targets the physical recording media themselves, such as semiconductor memory, SSDs, and optical discs, that store the implemented programs. This makes it easier to restrict import / export and distribution channels, and to limit on-premise delivery methods other than cloud services. [Appendix E] Conditional description data structure This covers the conditional description database / data model itself, which includes "CondID, trigger vector, meta-attributes, and related information links." It covers the act of providing data within the same schema, with the three-tiered structure of data records being a technical characteristic. [Note F] Generative AI Model Learning Method The model training flow, including the collection, preprocessing, transfer learning, and drift detection of specialized domain corpora for embedding vector generation, will be billed. This will give you an advantage when providing model services or ongoing learning services. [Note G] Doctor terminal UI component By requesting component-level access to notification UI libraries / widgets such as side panel fixed banners, urgency icons, and one-click approval buttons, EHR vendors can exercise their rights even when only incorporating those specific UI elements. [Note H] Cloud service delivery model This includes a "CDS + reverse auction" SaaS delivery method that requires a multi-tenant configuration, inter-tenant data separation, and an SLA (guaranteeing notification within 5 seconds). [Note I] Reverse auction parameter automatic optimization mechanism A module that autonomously updates the α / β weights for EvidenceGrade and CostIndex using reinforcement learning. It is a form of feedback learning that goes beyond simple bidding logic. [Note J] Notification failure backup network This includes a notification hub circuit and protocol switching procedure for multi-stage failover of email / SMS / push notifications. It enables delivery via redundant paths even in the event of carrier or gateway failures, contributing to the creation of a highly reliable communication market for healthcare applications.

[0154] (Additional claim 20) The information presentation system according to any one of claims 1 to 19 A method of information processing performed on a computer, (A) Input data acquisition process: Audio data including speech from patients or healthcare workers, text data, A step of obtaining at least one of image data or video data, (B) Stringization process: If the aforementioned input data includes something other than text, the input data A process of generating medical text data by converting it into a string or vector. (C) Preservation process: The generated medical text data is assigned to the user identifier. The process of linking and saving to a storage device. (D) Similarity evaluation process: The aforementioned medical text data and the drug information database stored A process of matching drug metadata and calculating similarity or relevance scores. (E) Judgment / specific process: Based on the aforementioned similarity or relevance score, One or more drugs are identified, and in case of a tie, a reverse auction is used. Alternatively, a process of ranking according to a priority table. (F) Notification process: Promotional information or Specific information can be displayed on the device, via push notification, email, SMS, in-app message or In at least one way of updating the web dashboard Notification process An information processing method characterized by including (Additional claim 21) The information processing method described in supplementary claim 20 A program to be executed by a computer. (Additional claim 22) The program described in supplementary claim 21 Recorded on a computer-readable storage medium. [Explanation of symbols]

[0155] 1 User terminal 2. Facility Standards Management System 3. Medical systems (electronic medical records, etc.) 20 Server (Processor 29, Memory 25, Storage 26, Communication IF 22, I / O IF 23)

Claims

1. An information presentation system comprising a processor and memory, The memory contains at least one memory for each drug, At least one of the following: drug information associated with the drug, metadata associated with said drug information, or a specific information recipient associated with said drug. It has a drug information database that stores drug information, The aforementioned processor, (1) A function to acquire input data that includes at least one of the following: audio data including speech of a patient or healthcare worker, text data about a patient, image data about a patient, video data about a patient, or structured data about a patient. (2) A function to identify one or more drugs by comparing the input data with the drug information database. (3) A function to present promotional information of the identified drug to healthcare professionals or a function to notify the designated information recipient of the fact that the drug has been identified. An information presentation system characterized by performing the following.

2. In the information presentation system described in claim 1, The aforementioned presentation includes the promotional information to which the metadata is attached, and the metadata is at least: (a) Drug identifier associated with the drug information, (b) at least one of the parameters used in the specific process described above, Includes, The aforementioned designation is, An information presentation system characterized by performing one or more of the following: complex search, AI inference, knowledge-based inference, decision tree classification, integrated evaluation, rule-based judgment, word extraction, phrase extraction, dependency structure analysis, vector similarity search, graph inference, time series analysis, and reinforcement learning.

3. In the information presentation system described in claim 2, The information presentation system is characterized by further performing an evaluation indicator display process that visually displays the parameters included in the metadata as evaluation indicator information attached to the promotion information.

4. In the information presentation system described in claim 2, The aforementioned drug information database contains information on at least two or more drugs, (a) Product name; (b) Name of active ingredient, (c) Approved efficacy and effects, (d) Dosage and administration; (e) Contraindications, precautions for use, and major side effects. (f) Pharmaceutical company information, (g) Additional information provided by pharmaceutical companies, It stores metadata that includes items (a), (b), (c), and (e). The aforementioned determination is made by comparing the text data with at least two items of the metadata to determine whether or not to notify the promotional information. If the judgment result is to be notified, an information presentation system characterized by notifying promotional information by at least one method, The notification method is: An information presentation system that uses any of the following methods: (i) in-device display, (ii) push notification, (iii) email, (iv) SMS / MMS, (v) in-app messaging, (vi) web dashboard update, or (vii) HTTPS API integration.

5. In the information presentation system described in claim 1, Equipped with means for obtaining patient identification information, The means for acquiring patient identification information is obtained from the electronic medical record system or devices / applications linked thereto. Patient identification information is acquired through at least one of the following means: network communication, reading of a machine-readable medium, or user input. An information presentation system characterized by adding acquired patient identification information to the text data or generated data based on the text data and outputting it, The aforementioned identification involves attaching the acquired patient identification information to the text data or the generated data. An information presentation system characterized by outputting information based on the aforementioned presentation.

6. In the information presentation system described in claim 5, An information presentation system characterized by outputting the aforementioned patient identification information in QR code or barcode format.

7. In the information presentation system described in claim 6, The aforementioned information presentation system is The system further includes an OCR engine that captures images of one or more display screens from either the electronic medical record system or the medical department system, and obtains the medical record display text from the captured images using optical character recognition (OCR). An information presentation system characterized by using text data obtained by the aforementioned OCR engine as one of the input data.

8. In the information presentation system described in claim 4, The aforementioned presentation further performs a normative check function to determine the appropriateness of the promotional information in light of (c) or (e) above, before notifying the promotional information. An information presentation system characterized in that promotional information deemed non-compliant by the aforementioned standard checking function is not notified to healthcare professionals.

9. In the information presentation system described in claim 1, An information presentation system characterized by comprising a deletion means that, after processing is complete, automatically deletes the data relating to the audio data, text data, image data, and video data so as not to remain in the memory.

10. In the information presentation system described in claim 5, An information presentation system characterized by performing processing and linking of the acquired input data to an ID on the local processor of a mobile information terminal, and transmitting only metadata that does not contain personal information, generated after the processing, to an external party via a network.

11. In the information presentation system described in claim 10, The aforementioned mobile information terminal is managed by MDM (Mobile Device Management), and at least (a) Whitelist management of applications, (b) Remote wipe or lock function, (c) Mandatory encryption of communication paths, An information presentation system characterized by its ability to perform any of the following actions.

12. In the information presentation system described in claim 1, The aforementioned identification is characterized by embedding the input data into vectors, calculating the cosine similarity with drug information vectors in a drug information database, and performing a vector similarity search to identify drugs whose similarity exceeds a threshold.

13. In the information presentation system described in claim 1, The aforementioned presentation is an information presentation system characterized by weighting and evaluating promotional information candidates presented by multiple pharmaceutical companies or their contractors based on bid value and clinical suitability score, and selecting and notifying the most suitable information using a reverse auction method.

14. An information presentation system according to claim 8, characterized in that the generative artificial intelligence model performs at least one of the following processes. (i) Context generation process (ii) Suitable drug selection process (iii) Regulatory compliance verification process

15. The specification is, Semantic relevance index: Includes one of the following as a value representing the semantic and conceptual proximity between the text data and the drug information: embedding vector similarity, index match, or inference probability. Economic value indicator: A quantitative value obtained by considering one of the following: advertising costs, bid price, cost-effectiveness, or remaining budget for the drug in question. Prioritization information: Weighting coefficients assigned based on the provider, contract type, regulatory category, or operational policy. Clinical context coefficient: A correction factor derived from patient attributes, disease stage, urgency, medical history, and historical behavioral data. Operational and regulatory control parameters: Notification limit, remaining posting period, compliance flag for laws and guidelines, privacy protection status. The information presentation system according to claim 1, which calculates an overall evaluation value by combining at least one of the following, and identifies drug information for which this overall evaluation value exceeds a predetermined threshold.

16. The information presentation system according to claim 15, wherein the "parameters" referred to in the aforementioned specification include at least one of semantic relevance indicators, economic value indicators, priority assignment information, clinical context coefficients, and operational / normative control parameters.

17. In the information presentation system described in claim 1, An information presentation system characterized by having patients input patient-reported information, including at least one of performance status (PS) information and adverse event information, via an electronic medical questionnaire system or personal health record (PHR) system operated by the patient, and further performing a function to acquire said patient-reported information as input data.

Images