System and method for inferring causes of low-score patient experience evaluation responses and providing dynamic follow-up questions

Abstract

The system for inferring the cause of a low-score response in a patient experience evaluation and providing dynamic additional questions according to the present invention comprises: a platform server that receives patient experience evaluation survey responses and Voice of Customer (VoC) data from a patient terminal or a guardian terminal; a database unit that stores the patient experience evaluation survey responses and the VoC data; and an ontology storage unit that stores a patient experience ontology including relationships between patient experience evaluation items, low-score responses, event information, cause candidates, additional questions, and improvement actions. The system includes an AI processing unit that analyzes the VoC data to extract event information, wherein the platform server detects a low-point response among the patient experience evaluation survey responses, maps the low-point response and the event information to the patient experience ontology to generate a plurality of cause candidates, calculates a reliability distribution and uncertainty for the plurality of cause candidates, selects an additional question to reduce the uncertainty and provides it to the patient terminal or the guardian terminal, receives a response to the additional question to update the reliability distribution of the plurality of cause candidates, determines the final cause of the low-point response based on the updated reliability distribution, and generates at least one of guidance information for the patient and an improvement action for the hospital administrator based on the final cause.

Description

Technology Field

[0001] The present invention relates to a system and method for analyzing the results of a patient experience evaluation of hospitalized patients to infer the cause of a low-score response and to improve the patient experience based thereon. More specifically, the present invention relates to a system and method for inferring the cause of a low-score response in a patient experience evaluation and providing dynamic additional questions, which infers candidate causes of a low-score response using patient experience evaluation survey responses and Voice of Customer (VoC) data, generates dynamic additional questions to reduce uncertainty regarding candidate causes, more accurately identifies the cause of the low-score response using responses to the additional questions, and provides guidance for patients and improvement actions for hospital administrators based on the results.

[0002] According to one embodiment, the present invention can be implemented in conjunction with patient experience evaluation, VoC collection, inpatient life guidance, AI inquiry, and hospital operation support functions, and can be applied even to medical institutions that find it difficult to establish their own patient experience management infrastructure.

[0003] In addition, according to one embodiment, the cause inference and dynamic additional question provision technology according to the present invention can be applied not only to VoC data linked to patient experience evaluation survey responses, but also to complaints, suggestions, inquiries, ward inquiries, opinions regarding inpatient life, opinions regarding outpatient use, opinions generated during the examination, treatment, medication, and discharge process, medical institution consultation records, and other medical VoC data generated during the use of medical services by patients or guardians. Background Technology

[0004] Recently, the importance of Patient Experience Evaluation (PAE) in medical institutions has been continuously increasing. This evaluation aims to objectively assess not only patient treatment outcomes but also the quality of medical services actually experienced by patients during hospitalization, and to reflect these findings in the improvement of hospital operations. PEA is utilized as an important means to improve the quality of medical services by evaluating aspects such as explanation, listening, respect, responsiveness, pain management, emotional support, patient safety, the hospital environment, the guarantee of patient rights, and overall satisfaction received from medical staff.

[0005] Patient experience assessment questionnaires generally include domains such as nursing, physicians, medication and treatment processes, emotional support, patient safety and hospital environment, patient rights protection, overall evaluation, and personal characteristics. For example, the nursing domain may include items regarding nurses' respect and courtesy, listening, explanations of hospital life, and efforts to address requests; the physician domain may include items regarding physicians' respect and courtesy, listening, opportunities for consultations, and the provision of information on ward rounds; and the medication and treatment process domain may include items regarding explanations of the reasons for medication, tests, and procedures, explanations of side effects, pain management, precautions after discharge, and communication between hospital departments.

[0006] However, since this patient experience evaluation method quantitatively assesses patient experience using standardized survey questions, it has limitations in that it is difficult to directly identify the causes even if low responses occur on specific items. For instance, even if a low score is assigned to the same item, it may be caused by various factors such as insufficient explanation from medical staff, increased waiting times, poor communication between departments, or a lack of hospital information; therefore, it is difficult to accurately pinpoint the actual causes requiring improvement based solely on survey results. Consequently, relying only on the simple aggregation of survey scores or statistical analysis has limitations in effectively supporting hospital patient experience improvement activities.

[0007] Meanwhile, tertiary or large general hospitals can collect and analyze patient experience data using their own mobile apps, patient experience management personnel, and data analysis infrastructure, and utilize this to improve hospital operations. On the other hand, small and medium-sized hospitals often lack the funds for developing their own apps, patient experience data collection infrastructure, and analysis personnel; consequently, even when they conduct patient experience evaluations, they frequently rely on paper or simple online surveys or remain limited to checking average scores for each item.

[0008] Furthermore, hospitals continuously receive repetitive inquiries regarding meal times, ward rounds, test schedules, parking, discharge procedures, and the issuance of various certificates. These inquiries increase the workload of wards or administrative departments and can cause inconvenience to patients and their guardians. In particular, elderly patients, minor patients, or patients requiring guardian assistance may find it difficult to check information or use services on their own.

[0009] Meanwhile, regarding information processing technology for hospitalized patients, technologies have been proposed in the past to predict specific risk levels using clinical data of hospitalized patients, to extract suspected diseases using patient symptom information, or to provide responses to user inquiries through chatbots or consultation services.

[0010] For example, Korean Patent Publication No. 10-2018-0050812 discloses a "personalized intervention system and method through prediction of fall risk in hospitalized patients." The aforementioned prior art is a technology that predicts the risk of fall occurrence based on clinical data of hospitalized patients and provides customized intervention services accordingly; it differs from a technology that analyzes the causes of low-scoring responses or generates additional questions using patient experience evaluation survey responses.

[0011] In addition, Korean Patent Publication No. 10-2023-0016513 discloses a "method and apparatus for providing a consultation service." The above prior art is a technology for generating a consultation or chatbot response in response to a user's query, but it does not disclose a technology for analyzing low-score responses in a patient experience evaluation or selecting additional questions to identify the cause of the low-score response.

[0012] In addition, Korean Patent Publication No. 10-2010-0083661 discloses a "method and apparatus for providing diagnostic information." The aforementioned prior art is a technology that extracts suspected diseases and supports diagnosis using patient symptom information, and differs from a technology that infers the cause of low patient experience responses using patient experience evaluation survey responses and Voice of Customer (VoC) data entered by a patient or guardian.

[0013] As such, conventional technologies merely present technologies related to clinical risk prediction, provision of counseling responses, or disease diagnosis, respectively, but they fail to present a technology that utilizes low-score responses from patient experience evaluations together with free-form VoC data to infer candidate causes for low-score responses, generates dynamic follow-up questions to reduce uncertainty regarding candidate causes, uses responses to follow-up questions to more accurately identify causes, and links this to guidance for patients and improvement actions for hospital administrators.

[0014] Accordingly, the present invention aims to provide a system and method for inferring the cause of low-score responses in a patient experience evaluation and providing dynamic additional questions, which infers candidate causes of low-score responses using patient experience evaluation survey responses and VoC data, and more accurately identifies the cause of low-score responses by providing dynamic additional questions to reduce the uncertainty of candidate causes, and provides the results as guidance for patients and improvement actions for hospital administrators.

[0015] In addition, according to one embodiment of the present invention, the system can be implemented in conjunction with guardian linkage functions, inpatient life guidance, ward round information, treatment schedule management, application for certificates, insurance-related guidance, and hospital operation support functions, and can be efficiently applied even in medical institutions that find it difficult to establish their own patient experience management infrastructure. The problem to be solved

[0016] The present invention is proposed to solve the problems of the aforementioned prior art, and aims to provide a system and method that can more accurately identify the cause of low-scoring responses in patient experience evaluation surveys and effectively utilize the results to improve patient experience.

[0017] In addition, the present invention aims to provide a system and method capable of efficiently identifying the actual cause of a low-point response with minimal additional questions by using patient experience evaluation survey responses and Voice of Customer (VoC) data together to infer candidate causes related to the low-point response and generating and providing dynamic additional questions to reduce the uncertainty of the candidate causes.

[0018] Furthermore, the present invention aims to provide a system and method that, by reflecting the responses to additional questions, classifies the final cause into surface causes directly experienced by the patient and root causes requiring improvement in hospital operations, and based on this, provides customized guidance to the patient and improvement actions to the hospital administrator.

[0019] In addition, one embodiment of the present invention can be implemented in conjunction with guardian linkage functions, inpatient life guidance, AI inquiry, ward round information, treatment schedule management, application for certificates, insurance-related guidance, and hospital operation support functions, and aims to provide a patient experience management platform that can be efficiently applied even in medical institutions that find it difficult to establish their own patient experience management infrastructure. means of solving the problem

[0020] The system for inferring the cause of low-point responses in patient experience evaluation and providing dynamic additional questions according to the present invention

[0021] A platform server that receives patient experience evaluation survey responses and VoC (Voice of Customer) data from a patient terminal or a guardian terminal;

[0022] A database unit storing the above patient experience evaluation survey responses and the above VoC data;

[0023] An ontology storage unit that stores a patient experience ontology including relationships between evaluation areas, evaluation items, patient journey, events, problem types, surface causes, root causes, working entities, follow-up questions, and improvement actions of a patient experience evaluation; and

[0024] It includes an AI processing unit that analyzes the above VoC data to extract event information regarding at least one of time zone, location, contact point, behavior, problem type, emotion, ward, medical department, and medical service stage, and includes an AI processing unit that analyzes the above VoC data to extract event information regarding at least one of time zone, location, contact point, behavior, problem type, emotion, ward, medical department, and medical service stage.

[0025] The above platform server is,

[0026] Detecting low-scoring responses among the responses to the above patient experience evaluation survey, and

[0027] The above low-point response and the above event information are mapped to nodes regarding evaluation items, events, problem types, surface causes, and root causes of the above patient experience ontology to generate a cause candidate graph in which multiple cause candidates are connected to the above low-point response and probability or confidence values ​​are assigned to each cause candidate, and

[0028] A reliability distribution for each cause candidate is calculated based on the probability or reliability values ​​assigned to the plurality of cause candidates, and uncertainty for the plurality of cause candidates is calculated based on the entropy of the reliability distribution.

[0029] For each of the multiple additional question candidates, the degree of reduction between the entropy before providing the additional question candidate and the expected entropy after reflecting possible responses to the additional question candidate is calculated as the expected information gain, and among the additional question candidates excluding questions that cause a specific medical staff or employee to be directly identified, questions that request sensitive information, and questions that repeat information already included in the VoC data, an additional question is selected based on the expected information gain and provided to the patient terminal or the guardian terminal.

[0030] Receive a response to the above additional question, recalculate the probability or confidence value of the cause candidate related to the received response, and update the confidence distribution for each cause candidate,

[0031] Determine the final cause of the above low point response based on the updated confidence distribution, and

[0032] The method is characterized by classifying the aforementioned final cause into a surface cause, which is an inconvenience or condition directly experienced by the patient, and a root cause, which is a hospital operational cause that caused the said inconvenience or condition; generating guidance information for the patient based on the surface cause and providing it to the patient terminal or the guardian terminal; and generating an improvement action for the hospital administrator based on the root cause and the business entity connected to the root cause, including at least one of a responsible department, a priority of action, and a deadline for action, and providing it to the hospital dashboard terminal.

[0033] In the present invention, the platform server is,

[0034] Among the responses to the above patient experience evaluation survey, at least one of the following is detected as a low score response: a response below the standard score, a response lower than the hospital average, a response lower than the ward average, a response lower than the medical department average, or a response lower than the previous evaluation result.

[0035] Multiple cause candidates may be generated by mapping the low-point response, along with event information extracted from the above VoC data, to the above patient experience ontology.

[0036] In the present invention, the platform server assigns a probability or confidence value to each of a plurality of cause candidates, and when at least one of a low point response, event information extracted from VoC data, pain score, and mood state is input, it recalculates the probability or confidence value of the cause candidate associated with the input information and updates the confidence distribution for each cause candidate.

[0037] Uncertainty may be calculated based on the entropy of the above reliability distribution.

[0038] In the present invention, the platform server, for each of the plurality of additional question candidates,

[0039] The degree of reduction between the entropy of the confidence distribution for each cause candidate before providing the additional question candidate and the expected entropy of the confidence distribution for each cause candidate after reflecting possible responses to the additional question candidate is calculated as the Expected Information Gain (EIG), and

[0040] You may select additional questions based on the expected information gain mentioned above.

[0041] In the present invention, the platform server is,

[0042] Update the confidence distribution of the plurality of cause candidates using the response to the additional question above, and

[0043] Determining the final cause of the low point response based on the updated confidence distribution,

[0044] The aforementioned final cause may be classified into a surface cause, which is an inconvenience or condition directly experienced by the patient, and a root cause, which is a hospital operational cause that generated the said inconvenience or condition; guidance information for the patient based on the surface cause may be provided to the patient or guardian, and improvement actions for the hospital administrator based on the root cause may be provided to the hospital administrator. In this case, the improvement actions for the hospital administrator may include at least one of the business entity, responsible department, priority of action, and deadline for action connected to the root cause.

[0045] In the present invention, the mood state may include at least one emotional state value among anxiety, depression, discomfort, neutrality, or stability, entered by a patient or caregiver through emojis, scales, or selection items, and the emotional information may be extracted through natural language processing or sentiment analysis of free-form or voice VoC data. The platform server may map at least one of the emotional state value and the emotional information to the patient experience ontology together with event information extracted from the VoC data, and correct the reliability distribution by cause candidate by reflecting the mapping result in a cause candidate graph to recalculate the probability or reliability value of the related cause candidate. The emotional state value or the emotional information may not be a value that determines the final cause alone, but may be used as an auxiliary context to correct the reliability distribution by cause candidate related to insufficient explanation, waiting delays, inadequate pain response, lack of emotional support, or issues with response attitude.

[0046] In the present invention, the platform server may update the weights for cause candidates, additional questions, or improvement actions using at least one of patient experience evaluation responses, VoC data, additional question responses, and administrator action results.

[0047] In the present invention, the platform server registers a guardian corresponding to the patient, and

[0048] Depending on the authority of the aforementioned guardian, a response to the aforementioned additional question may be received or patient guidance information may be provided through the aforementioned guardian terminal.

[0049] In the present invention, the patient guidance information is,

[0050] You may include at least one of the following: inpatient life guide, ward round information, treatment schedule, guide on applying for medical certificates, insurance-related information, and AI inquiry responses.

[0051] The method for inferring the cause of a low-point response in a patient experience evaluation and providing dynamic additional questions according to the present invention is,

[0052] A step of receiving patient experience evaluation survey responses and VoC (Voice of Customer) data from a patient terminal or guardian terminal;

[0053] A step of detecting at least one of the following as a low-score response among the responses to the patient experience evaluation survey: a response below a standard score, a response lower than the hospital average, a response lower than the ward average, a response lower than the medical department average, or a response lower than the previous evaluation result;

[0054] A step of extracting event information regarding at least one of time zone, location, contact point, behavior, problem type, emotion, ward, medical department, and medical service stage from the above VoC data;

[0055] A step of mapping the low-point response and the event information to nodes regarding evaluation items, events, problem types, surface causes, and root causes of a patient experience ontology including the relationships between evaluation areas, evaluation items, patient journey, events, problem types, surface causes, root causes, work subjects, follow-up questions, and improvement actions of the patient experience evaluation, thereby generating a cause candidate graph in which a plurality of cause candidates are connected to the low-point response and a probability or confidence value is assigned to each cause candidate;

[0056] A step of calculating a reliability distribution for each cause candidate based on the probability or reliability values ​​assigned to the plurality of cause candidates, and calculating uncertainty for the plurality of cause candidates based on the entropy of the reliability distribution;

[0057] For each of the multiple additional question candidates, the method calculates the expected information gain as the degree of reduction between the entropy before providing the additional question candidate and the expected entropy after reflecting possible responses to the additional question candidate, and selects an additional question based on the expected information gain from among the additional question candidates excluding questions that cause a specific medical staff or employee to be directly identified, questions that request sensitive information, and questions that repeatedly ask for information already included in the VoC data, and provides the additional question to the patient terminal or the guardian terminal;

[0058] A step of receiving a response to the above additional question, recalculating the probability or confidence value of the cause candidate related to the received response, and updating the confidence distribution for each cause candidate;

[0059] A step of determining the final cause of the low point response based on an updated confidence distribution, and classifying the final cause into a surface cause, which is an inconvenience or condition directly experienced by the patient, and a root cause, which is a hospital operational cause that caused the said inconvenience or condition; and

[0060] The method is characterized by including the step of generating guidance information for a patient based on the above surface cause and providing it to the patient terminal or the guardian terminal, and generating an improvement action for a hospital administrator based on the above root cause and the business entity connected to the above root cause, including at least one of a responsible department, an action priority, and an action deadline, and providing it to the hospital dashboard terminal. Effects of the invention

[0061] According to the present invention, instead of merely aggregating low-scoring responses from patient experience evaluation surveys as scores, candidate causes for such low-scoring responses can be structurally inferred by utilizing patient experience evaluation survey responses together with Voice of Customer (VoC) data. Accordingly, hospitals can more accurately identify the actual causes of low-scoring responses and utilize this information to improve patient experience.

[0062] In addition, according to the present invention, dynamic additional questions can be generated and provided to reduce the uncertainty of candidate causes, so the cause of a low-point response can be effectively identified with only a minimum number of additional questions without providing all subsequent questions at once. Accordingly, the accuracy of cause analysis can be improved while reducing the patient's response burden and fatigue.

[0063] Furthermore, according to the present invention, by reflecting the response to additional questions, the final cause of the low-point response can be classified into surface causes directly experienced by the patient and root causes requiring improvement in hospital operations. Accordingly, guidance or emotional support appropriate to the cause can be provided to the patient, and specific improvement actions for improving hospital operations can be provided to the hospital administrator.

[0064] Furthermore, according to the present invention, by continuously accumulating and analyzing patient experience evaluation responses, VoC, and additional question responses, the accuracy of cause inference and additional question selection can be improved, and more sophisticated patient experience analysis and improvement reflecting the characteristics of each medical institution or ward is possible.

[0065] In addition, according to one embodiment of the present invention, the system can be implemented in conjunction with guardian linkage functions, inpatient life guidance, AI inquiry, treatment schedule management, application for certificates and documents, and hospital operation support functions, so that even medical institutions that find it difficult to establish their own patient experience management infrastructure can efficiently provide patient experience management services.

[0066] Therefore, the present invention can improve the usability and reliability of patient experience evaluations by more accurately identifying the causes of low-scoring responses in patient experience evaluations and effectively utilizing the results for patient guidance and hospital operation improvement. Brief explanation of the drawing

[0067] FIG. 1 is an overall service configuration diagram of a system for inferring the cause of a low-point response in a patient experience evaluation and providing dynamic additional questions according to one embodiment of the present invention. Figure 2 is an overall configuration diagram showing the system for inferring the cause of low-point responses in the patient experience evaluation and providing dynamic additional questions of Figure 1 in terms of hardware configuration and function blocks. FIG. 3 is a configuration diagram of information verification, communication, data recording, and guardian linkage services provided in a patient terminal and a guardian terminal according to an embodiment of the present invention. FIG. 4 is a flowchart of an algorithm for LLM natural language processing, speech recognition, sentiment analysis, pain and mood state analysis, VoC event extraction, and low point response cause inference according to an embodiment of the present invention. FIG. 5 is a flowchart of the use of a patient / guardian app-based service, patient experience evaluation response, VoC input, and low point cause analysis according to one embodiment of the present invention. FIG. 6 is a flowchart of the guardian registration, patient consent, authority setting, and authority management procedures according to one embodiment of the present invention. FIG. 7 is a flowchart showing the determination of the final cause, separation of the surface cause and the root cause, and separation of patient, guardian, and administrator actions according to one embodiment of the present invention. FIG. 8 is a flowchart of the construction of data linkage for hospitalization guidance, application for certificates, and documents submitted to insurance companies based on hospital data OCR according to one embodiment of the present invention. Specific details for implementing the invention

[0068] Preferred embodiments of the present invention will be described below with reference to the accompanying drawings. However, the present invention is not limited to the following embodiments and may be modified in various forms within the scope of the technical concept of the present invention.

[0069] In one embodiment of the present invention, the system of the present invention may infer candidate causes using patient experience evaluation survey responses and VoC data to more accurately identify the cause of a low-scoring response in a patient experience evaluation survey, and may generate and provide dynamic additional questions to reduce the uncertainty of the candidate causes. In addition, the system may clearly identify the cause of the low-scoring response using the response to the additional questions and provide the results as guidance for patients and improvement actions for hospital administrators.

[0070] In this specification, "patient experience evaluation" may refer to evaluating, in the form of a survey, the experiences of inpatients regarding nursing, doctors, medication and treatment processes, emotional support, patient safety and hospital environment, guarantee of patient rights, and overall satisfaction during the course of hospital use. The patient experience evaluation may consist of, for example, 23 items, but is not limited thereto, and the number of items and the composition of the items may be changed according to hospital-specific evaluation criteria, patient groups, medical departments, or the purpose of the evaluation.

[0071] "VoC" stands for Voice of Customer and may refer to praise, inconvenience, suggestions, inquiries, requests, or opinions for improvement felt by patients or guardians during the course of using the hospital.

[0072] In the present invention, VoC data may include free-form descriptive VoC freely entered by a patient or guardian, and may further include selective VoC, voice VoC, image VoC, or a combination thereof.

[0073] The above free-form VoC may refer to data entered in the form of natural language sentences by patients or guardians regarding inconveniences, inquiries, requests, emotional expressions, requests for improvement, or praise experienced during the process of using the hospital.

[0074] In one embodiment, the VoC data is not limited to VoC data entered in connection with patient experience evaluation. The VoC data may include complaints, suggestions, inquiries, ward inquiries, opinions regarding inpatient life, opinions regarding outpatient use, opinions arising during examinations, treatments, medication, or discharge processes, medical institution consultation records, and other medical VoC data generated during the use of medical services by patients or guardians.

[0075] In addition, even if the low-point response of the patient experience evaluation is not directly linked to the medical VoC data, at least one of a medical service touchpoint, patient journey stage, event, behavior, situation, problem type, emotion, or requirement can be extracted from the medical VoC data, and multiple cause candidates can be generated based on the extracted information. If the actual cause among the multiple cause candidates is unclear, dynamic follow-up questions can be provided to reduce the uncertainty of the cause candidates, and the reliability or relationship of the cause candidates can be updated based on the response to the follow-up questions.

[0076] "Low score response" may refer to responses below the standard score in the patient experience evaluation survey, responses lower than the hospital average, responses lower than the ward average, responses lower than the medical department average, responses lower than the statistical standards for each attending medical staff, or responses lower than the previous evaluation round.

[0077] "Guardian" may refer to the patient's family, legal representative, parents of a minor patient, children of an elderly patient, or a person authorized by the patient for registration. Within the scope of their established authority, the guardian may access patient information, check ward round schedules, verify dietary information, share treatment calendars, apply for medical certificates on behalf of the patient, verify documents to be submitted to the insurance company, participate in patient experience evaluations on behalf of the patient, and input Voice of Customer (VoC).

[0078] "Treatment calendar" may refer to a function that provides treatment schedules during hospitalization or outpatient visit dates, test dates, medication schedules, rehabilitation schedules, treatment schedules, attending physician consultation schedules, and hospital appointment information in a calendar format.

[0079] "Ontology" can refer to a system of knowledge that structures and expresses concepts included in a specific domain and the relationships between those concepts.

[0080] In the present invention, the patient experience ontology is a knowledge structure that defines semantic relationships between patient experience evaluation items, low-score responses, VoC complaint content, hospital service elements, and improvement actions, and can be used to infer candidate causes of low-score responses from input patient experience evaluation survey responses or VoC data.

[0081] That is, the above patient experience ontology is a knowledge structure that structures candidate causes related to low patient experience evaluation responses and the semantic relationships between them, and can be used to infer candidate causes based on input patient experience evaluation survey responses and VoC data.

[0082] Specifically, the above patient experience ontology may include relationships between evaluation areas, evaluation items, low-point responses, patient journey, events, problem types, pain status, emotional status, VoC complaint content, ward round schedule, dietary information, treatment calendar, certificates, documents submitted to insurance companies, guardian authority, surface causes, root causes, responsible parties, follow-up questions, and improvement actions.

[0083] "Surface causes" may refer to discomfort or conditions directly experienced or expressed by the patient. For example, delayed response to the call bell, failure to provide ward round information, insufficient dietary information, lack of guidance on lifting the fast, inadequate pain management, dissatisfaction with room cleanliness, insufficient explanation, insufficient guidance on paperwork, insufficient guidance on insurance submission documents, or emotional distress may be considered surface causes.

[0084] "Root cause" may refer to operational hospital causes that give rise to surface causes. For example, inadequate ward guidance processes, a lack of a notification system for ward round changes, insufficient integration of dietary information, inadequate pain management procedures, issues with night shift staffing, omissions in handovers, inadequate guidance systems for certification documents, or inadequate administrative and insurance guidance systems may constitute root causes.

[0085] Figure 1 is an overall service configuration diagram of an ontology-based patient experience evaluation low-point response cause inference and guardian-linked patient experience management system according to one embodiment of the present invention.

[0086] Referring to FIG. 1, a system according to one embodiment of the present invention may include a patient terminal (100), a guardian terminal (105), a communication network (200), a fix platform server (300), a database unit (400), an ontology storage unit (500), an AI processing unit (600), a hospital dashboard terminal (700), a hospital system linkage unit (800), a notification linkage unit (900), and an insurance company linkage unit (950).

[0087] The patient terminal (100) can perform check of ward round schedule, check of diet information, view of inpatient life guide, check of treatment calendar, AI inquiry, ward inquiry, appointment of medical staff consultation, application for certificates, input of pain score, input of mood state, response to patient experience evaluation survey, and input of VoC through the patient app or web.

[0088] After registering the guardian and verifying the authority, the guardian terminal (105) can perform tasks such as viewing patient information, checking the ward round schedule, checking the diet information, sharing the treatment calendar, applying for certificates on behalf of the guardian, checking documents required for submission to the insurance company, participating in the patient experience evaluation on behalf of the guardian, and inputting VoC on behalf of the guardian within the set authority range.

[0089] The communication network (200) can provide a data transmission and reception path between a patient terminal (100), a guardian terminal (105), a fix platform server (300), a hospital dashboard terminal (700), a hospital system linkage unit (800), a notification linkage unit (900), and an insurance company linkage unit (950). The communication network (200) may be composed of an internet network, a mobile communication network, a hospital internal network, a wireless LAN, a VPN, or a combination thereof.

[0090] In the present specification, "PIX platform server (300)" may refer to a server that provides patient experience management services by communicating with a patient terminal (100), a guardian terminal (105), a hospital dashboard terminal (700), a hospital system linkage unit (800), a notification linkage unit (900), and an insurance company linkage unit (950).

[0091] The above-mentioned Fix platform server (300) can collect, store, and analyze patient experience evaluation survey responses, VoC data, pain scores, mood status, data on the use of hospitalization guidance, ward round schedules, diet information, treatment calendars, applications for certificates, verification of documents submitted to insurance companies, and guardian linkage data.

[0092] Additionally, the Fix platform server (300) can perform LLM natural language processing, speech recognition, sentiment analysis, VoC event extraction, pain and mood state analysis, OCR document analysis, ontology mapping, low point response cause candidate inference, dynamic additional question selection, guardian authority management, document and insurance linkage processing, statistical analysis, and action guidance generation by linking with the AI ​​processing unit (600) and the ontology storage unit (500).

[0093] Accordingly, if the cause of the low point response is unclear, the fix platform server (300) can provide additional questions based on experience facts to the patient terminal (100) or guardian terminal (105) and determine the final cause based on the response to the additional questions. Additionally, the fix platform server (300) can provide guidance for the patient, information shared with the guardian, and improvement actions for the hospital administrator based on the final cause.

[0094] Here, "Pix" or "PIX" may be used as a name to identify a patient experience management platform, and the technical concept of the present invention is not limited to said name.

[0095] Accordingly, in this specification, the "fix platform server (300)" may be understood as having the same or corresponding configuration as the "platform server (300)" described in the claims. Furthermore, the present invention may be applied to a server, platform, management system, or computing device performing equivalent functions that collect and analyze patient experience data to infer the cause of low-point responses and provide improvement actions.

[0096] The database section (400) is configured to store data necessary for patient experience management and may include a survey DB (410), a VoC DB (420), a guidance content DB (430), a ward rounds / diet / treatment calendar DB (440), a document / insurance linkage DB (450), a pain / mood DB (460), and a guardian authority DB (470).

[0097] The ontology storage unit (500) can store a patient experience ontology including relationships between evaluation areas, evaluation items, patient journey, events, problem types, pain status, emotional status, ward round schedule, diet information, treatment calendar, certificates, documents submitted to insurance companies, guardian authority, surface causes, root causes, responsible parties, additional questions, and improvement actions.

[0098] The AI ​​processing unit (600) can perform LLM natural language processing, speech recognition, sentiment analysis, pain and mood state analysis, VoC event extraction, OCR document analysis, and calculation of expected information gain for dynamic additional question selection.

[0099] Specifically, the AI ​​processing unit (600) can perform LLM-based natural language processing on free-form VoC, AI inquiries, ward inquiries, free survey responses, and inquiries related to certificates and documents input through the patient terminal (100) or guardian terminal (105). The LLM-based natural language processing can be used to extract at least one event information among intention, sentiment, type of problem, time period, place, contact point, action, ward, medical department, and medical service stage from the input sentence.

[0100] Additionally, the AI ​​processing unit (600) can convert voice data into text data through voice recognition when voice VoC or voice inquiry is input, and can extract emotional information by performing natural language processing and sentiment analysis on the converted text data.

[0101] Additionally, the AI ​​processing unit (600) can analyze the pain score and mood state entered through the patient terminal (100) or the guardian terminal (105). The mood state may be at least one emotional state value among anxiety, depression, discomfort, normal, or stable, entered by the patient or guardian through emojis, scales, or selection items. The pain score, emotional state value, or emotional information may be mapped to a patient experience ontology along with low-point responses and event information extracted from VoC data, and used as an auxiliary context to correct the reliability distribution for each related cause candidate.

[0102] Additionally, the AI ​​processing unit (600) can perform OCR document analysis on PDFs, images, brochures, notices, or scanned documents uploaded by the hospital, and classify the extracted text into inpatient life guides, ward round schedules, diet information, treatment calendars, certificate document guides, insurance submission document guides, or FAQ data.

[0103] Additionally, the AI ​​processing unit (600) can calculate a reliability distribution for multiple cause candidates based on low-point responses, VoC events, pain and mood states, and patient experience ontology, and can calculate an expected information gain for each of the multiple additional question candidates. Accordingly, the AI ​​processing unit (600) can be used to select an additional question that can most significantly reduce the uncertainty of the cause candidates.

[0104] The hospital dashboard terminal (700) can display patient experience evaluation statistics, VoC statistics, satisfaction by ward, low score items, candidate causes, final causes, improvement actions, responsible departments, priority of measures, real-time request processing status, and document / insurance linkage processing status.

[0105] Additionally, the hospital dashboard terminal (700) can receive AI inquiries, ward inquiries, requests for certificates, appointments for medical staff consultations, VoCs, and emotional care requests entered from the patient terminal (100) or guardian terminal (105) in real-time or near-real-time, and display the processing status, processing results, and whether follow-up actions have been taken.

[0106] The hospital system linkage unit (800) can be linked with HIS, EMR, OCS, examination and surgery schedule system, diet system, ward round schedule system, and certificate issuance system. Accordingly, the Fix platform server (300) can receive or update ward round schedule, diet information, examination schedule, surgery schedule, treatment schedule, and certificate issuance information through the hospital system linkage unit (800).

[0107] The notification linkage unit (900) can send app push, text, email, or messenger notifications to the patient or guardian. The notifications may include changes to the ward round schedule, dietary information, the time when meals are possible after fasting, treatment calendar schedules, results of processing certificate documents, guidance on documents to be submitted to the insurance company, requests for additional questions, or emotional care messages.

[0108] The insurance company linkage unit (950) can verify documents required for submission to the insurance company, provide guidance on documents related to insurance claims, and perform insurance company API linkage or electronic transmission linkage. Accordingly, the patient or guardian can verify the documents required for submission to the insurance company, apply for necessary certificates at the hospital, and check the processing results through the patient terminal (100) or guardian terminal (105).

[0109] The system of the present invention can be applied to various medical institutions, such as tertiary general hospitals, general hospitals, or small and medium-sized hospitals that find it difficult to adequately establish their own patient experience management infrastructure. Furthermore, the system of the present invention can be implemented as a single platform by integrating functions such as patient experience evaluation, VoC collection, inpatient life guidance, AI inquiries, ward round information, treatment schedule management, application for various certificates, and insurance-related guidance.

[0110] FIG. 2 is an overall hardware block diagram showing the patient experience management system of FIG. 1 in terms of hardware configuration and function blocks. The Fix Platform Server (300) described below is an exemplary name for describing an embodiment of the platform server of the present invention.

[0111] Referring to FIG. 2, the Fix platform server (300) may include a communication interface unit (301), an authentication / authorization management unit (302), an input collection unit (303), an information verification provision unit (304), an AI inquiry processing unit (305), a document / insurance processing unit (306), a guardian management unit (307), a low point detection unit (308), a VoC event extraction unit (309), a pain / mood analysis unit (310), an ontology mapping unit (311), a cause candidate inference unit (312), a dynamic additional question selection unit (313), an action guidance generation unit (314), a statistical analysis unit (315), a treatment calendar management unit (316), an OCR / document conversion unit (317), and a feedback learning unit (318).

[0112] The communication interface unit (301) can transmit and receive data with the patient terminal (100), guardian terminal (105), hospital dashboard terminal (700), hospital system linkage unit (800), notification linkage unit (900), and insurance company linkage unit (950).

[0113] The authentication and authorization management unit (302) can perform authentication of patients, guardians, hospital administrators, and external linked systems, and control access rights for each user.

[0114] The input collection unit (303) can collect patient experience evaluation survey responses, VoC data, AI inquiry data, ward inquiry data, pain score, mood state, ward round schedule inquiry history, diet information inquiry history, treatment calendar usage history, information on application for certificates, history of checking documents submitted to insurance companies, and guardian proxy input information.

[0115] Additionally, the input collection unit (303) may include a survey area classification unit that classifies patient experience evaluation survey responses into multiple evaluation areas and multiple evaluation items, or may perform the function of said survey area classification unit. The said survey area classification unit classifies patient experience evaluation survey responses into at least one evaluation area among a nurse area, a doctor area, a medication and treatment process area, an emotional support area, a patient safety and hospital environment area, a patient rights guarantee area, an overall evaluation area, and a personal characteristics area, and can identify response values ​​for each evaluation item included in each evaluation area.

[0116] The information verification provision unit (304) can provide ward round schedules, meal information, times when meals can be eaten after fasting, hospitalization life guides, ward guides, and treatment calendars to the patient terminal (100) or guardian terminal (105).

[0117] The AI ​​inquiry processing unit (305) can analyze inquiries from patients or guardians and respond to simple and repetitive inquiries related to inpatient life guidance, ward rounds schedule, diet information, test schedule, parking, payment, discharge procedures, and application for certificates. Additionally, if the inquiry content includes emotional anxiety, depression, complaints of pain, or urgent requests, the AI ​​inquiry processing unit (305) can provide an emotional care message or escalate the matter to a ward or the relevant department.

[0118] The document and insurance processing unit (306) can perform requests for certificates, verification of documents required for submission to an insurance company, requests for linkage with an insurance company, requests for electronic transmission, and notification of processing results.

[0119] The guardian management department (307) can perform guardian registration requests, guardian identity verification, patient consent, verification of family or guardian relationship, setting of authority scope, changing guardian authority, and recording audit logs.

[0120] The low point detection unit (308) can detect as low point responses a response below the standard score among the responses to the patient experience evaluation survey, a response lower than the hospital average, a response lower than the ward average, a response lower than the medical department average, a response lower than the statistical standard for each medical staff member, or a response lower than the previous evaluation round.

[0121] The VoC event extraction unit (309) can extract at least one event information among intent, object, emotion, keyword, time zone, place, contact point, action, ward, medical department, and medical service stage from VoC data, AI inquiry data, ward inquiry data, and free-form survey responses.

[0122] The pain and mood analysis unit (310) can analyze the pain score and mood state entered through the patient terminal (100) or the guardian terminal (105). The mood state may be at least one emotional state value among anxiety, depression, discomfort, normal, or stable entered by the patient or guardian through emojis, scales, or selection items. Additionally, the pain and mood analysis unit (310) can extract emotional information through natural language processing or sentiment analysis of free-form or voice VoC data. The pain score, emotional state value, or emotional information is not a value that determines the final cause alone, but can be used as an auxiliary context to correct the reliability distribution for each cause candidate along with low-point responses and event information.

[0123] The ontology mapping unit (311) can map low point responses, VoC events, pain status, emotional status, guardian behavior, ward round schedule, diet information, treatment calendar, information on applications for certificates and information on verification of documents submitted to the insurance company to the patient experience ontology. The patient experience ontology may include relationships between evaluation areas, evaluation items, patient journey, events, problem types, surface causes, root causes, responsible parties, additional questions, and improvement actions.

[0124] The cause candidate inference unit (312) can generate a cause candidate graph in which multiple cause candidates are connected to a low point response based on the ontology mapping result, and can calculate a confidence distribution for each cause candidate by assigning a probability or confidence value to each cause candidate. The dynamic additional question selection unit (313) can recalculate the probability or confidence value of a cause candidate related to the input information based on at least one input information among the low point response, event information extracted from VoC data, pain score, mood state, and patient experience ontology, and update the confidence distribution for each cause candidate.

[0125] The dynamic additional question selection unit (313) can calculate uncertainty based on the entropy of the confidence distribution for each candidate cause and calculate the expected information gain (EIG) for each of the multiple additional question candidates. The expected information gain may be a value representing the degree of reduction between the entropy of the confidence distribution for each candidate cause before providing a specific additional question candidate and the expected entropy of the confidence distribution for each candidate cause after reflecting possible responses to the additional question candidate.

[0126] The dynamic additional question selection unit (313) calculates the entropy of the confidence distribution for each additional question candidate before providing the additional question candidate, calculates the entropy of the confidence distribution for each expected cause candidate after reflecting possible responses to the additional question candidate, and can calculate the value obtained by subtracting the expected entropy of the latter from the entropy of the former as the expected information gain. The dynamic additional question selection unit (313) can select at least one of a plurality of additional question candidates based on the expected information gain.

[0127] In one embodiment, the dynamic additional question selection unit (313) is not limited to simply selecting the additional question candidate with the greatest expected information gain, but can also select an additional question candidate by considering patient fatigue, the possibility of requiring sensitive information, and the degree of overlap with VoC data.

[0128] For example, the dynamic additional question selection unit (313) can calculate the expected information gain (EIG), patient fatigue index (Fatigue), sensitivity information requirement possibility index (Sensitivity), and redundancy index for each of the multiple additional question candidates, and calculate a question selection score for each additional question candidate based on these.

[0129] In one embodiment, the question selection score Score(q) for any additional question candidate q can be calculated by the following formula.

[0130] Score(q) = EIG(q) - α·Fatigue(q) - β·Sensitivity(q) - γ·Redundancy(q)

[0131] Here, EIG(q) may represent the expected information gain that additional question candidate q reduces the uncertainty of the cause candidate, Fatigue(q) may represent an indicator of patient fatigue that may be increased by additional question candidate q, Sensitivity(q) may represent an indicator representing the likelihood that additional question candidate q will request sensitive information, and Redundancy(q) may represent an indicator representing the degree of overlap between additional question candidate q and information already included in the VoC data. Additionally, α, β, and γ may represent weights for patient fatigue, the likelihood of requesting sensitive information, and redundancy, respectively.

[0132] The dynamic additional question selection unit (313) can select the additional question candidate with the highest Score (q) among multiple additional question candidates. Accordingly, even if a question has a high expected information benefit, its selection priority may be lowered if it excessively increases patient fatigue, requires sensitive information, or asks for information already included in the VoC data. Therefore, according to this embodiment, it is possible to provide dynamic additional questions that effectively reduce the uncertainty of the cause candidate while also considering the patient's response burden, protection of personal information, and question duplication.

[0133] Additionally, the dynamic additional question selection unit (313) can exclude questions that directly identify specific medical staff or employees, questions that request sensitive information, questions that repeat information already included in the VoC data, and questions that increase patient fatigue through an allow set filter.

[0134] In this case, the dynamic additional question selection unit (313) may calculate a Score (q) for only the additional question candidates that have passed the allowed set filter, or calculate a Score (q) for multiple additional question candidates and then select an additional question candidate that has passed the allowed set filter among the additional question candidates sorted according to the Score (q).

[0135] The action guidance generation unit (314) separates the final cause into a surface cause and a root cause, and can provide the patient or guardian with immediate guidance based on the surface cause, emotional care messages, ward round schedules, dietary information, treatment schedule sharing, or document / insurance processing results. Additionally, the action guidance generation unit (314) can provide the hospital administrator with improvement actions based on the root cause, the responsible department, action priorities, and action deadlines.

[0136] The statistical analysis unit (315) can generate patient experience evaluation statistics, VoC statistics, pain and mood status statistics, satisfaction by ward, satisfaction by medical department, low score items, candidate causes, final causes, improvement actions, and document and insurance processing status.

[0137] The treatment calendar management unit (316) can organize the treatment schedule during hospitalization, outpatient visitation date after discharge, examination date, medication schedule, rehabilitation schedule, treatment schedule and attending physician consultation schedule in a calendar format and provide it to the patient terminal (100) or guardian terminal (105).

[0138] The OCR / document conversion unit (317) can extract text from PDFs, images, brochures, notices, or scanned documents uploaded by the hospital, and classify the extracted text into items such as inpatient life guide, ward guide, ward round schedule, diet information, treatment calendar, certificate document guide, insurance submission document guide, or FAQ.

[0139] The feedback learning unit (318) can update cause-question-action weights or hospital- and ward-specific prior probabilities based on post-survey, VoC changes, pain and mood changes, patient reactions, guardian usage history and administrator action history.

[0140] Referring to FIG. 2, the database unit (400) is configured to store data necessary for patient experience management in conjunction with the Fix platform server (300), and may include a survey DB (410), a VoC DB (420), a guidance content DB (430), a ward rounds / diet / treatment calendar DB (440), a document / insurance linkage DB (450), a pain / mood DB (460), and a guardian authority DB (470).

[0141] The survey DB (410) can store patient experience evaluation survey templates, evaluation areas, evaluation questions, survey instances, survey responses, score information, and low score response information. The patient experience evaluation survey may consist of, for example, 23 questions, but is not limited thereto, and the number of questions and the composition of the questions may be changed according to hospital-specific evaluation criteria, patient groups, medical departments, or evaluation purposes.

[0142] The VoC DB (420) can store free-form VoC, selection-type VoC, voice VoC, image VoC, VoC categories, VoC keywords, emotion information, and event extraction results entered by a patient or guardian.

[0143] The guidance content DB (430) can store guidance content used for inpatient life guidance, ward guidance, visitation guidance, parking guidance, payment guidance, test guidance, ward rounds guidance, meal guidance, discharge guidance, FAQ and AI inquiry response.

[0144] The ward rounds, diet, and treatment calendar DB (440) can store the attending physician's ward rounds schedule, ward rounds change information, diet information, whether fasting is required, the expected time when eating is possible after fasting, treatment schedule during hospitalization, outpatient visit date after discharge, examination date, medication schedule, rehabilitation schedule, and treatment schedule.

[0145] The document and insurance linkage DB (450) can store the history of applications for certificates, documents subject to issuance, documents required to be submitted to the insurance company, insurance company linkage information, electronic transmission history, and processing result information.

[0146] The pain and mood DB (460) can store pain scores, mood states, input times, change trends, and abnormal state judgment results entered through the patient terminal (100) or guardian terminal (105).

[0147] The guardian authority DB (470) can store guardian registration information, information on the relationship between the patient and the guardian, patient consent information, guardian identity verification information, guardian authority scope, proxy application history, proxy evaluation participation history, proxy VoC input history, treatment calendar sharing history, and audit logs.

[0148] The above survey DB (410), VoC DB (420), pain and mood DB (460), and ontology storage unit (500) can be used for low-point response detection, VoC event extraction, cause candidate graph generation, reliability distribution calculation, and dynamic additional question selection.

[0149] In addition, the guidance content DB (430), ward rounds, diet, and treatment calendar DB (440), and the document and insurance linkage DB (450) can be used to provide inpatient life guidance, ward rounds schedule, diet information, treatment calendar, application for certificates, and verification of documents required for submission to an insurance company to the patient terminal (100) or guardian terminal (105).

[0150] Additionally, the guardian authority DB (470) can be used to determine the authority to view patient information on the guardian terminal (105), check the ward round schedule, check the diet information, share the treatment calendar, apply for certificates on behalf of the guardian, check documents submitted to the insurance company, participate in the patient experience evaluation on behalf of the guardian, and input VoC on behalf of the guardian.

[0151] FIG. 3 is a configuration diagram of information verification, communication, data recording, and guardian linkage services provided in a patient terminal and a guardian terminal according to an embodiment of the present invention.

[0152] Referring to FIG. 3, the services provided through the patient terminal (100) and the guardian terminal (105) can be classified into information verification services, communication services, data recording services, and guardian linkage services.

[0153] The above information verification service may include checking the ward round schedule, checking meal information, checking when meals are possible after fasting, viewing the hospitalization guide, and checking the treatment calendar. Accordingly, the patient or guardian can check the attending physician's ward round time, ward round change information, meal information, test or treatment schedule, and post-discharge treatment schedule through the patient terminal (100) or guardian terminal (105).

[0154] The aforementioned communication services may include AI inquiries, ward inquiries, requests for medical certificates, appointment scheduling with medical staff, and inquiries regarding documents to be submitted to insurance companies. AI inquiries can provide responses to simple and repetitive questions regarding inpatient life guidance, ward rounds schedules, meal information, test schedules, parking, payments, discharge procedures, document requests, and documents to be submitted to insurance companies. Additionally, if an inquiry from a patient or guardian involves emotional distress, complaints of pain, or an urgent request, the system may provide emotional care messages or escalate the matter to the ward or relevant department.

[0155] The above data recording service may include pain score input, mood state input, patient experience evaluation survey responses, and VoC input. In this case, the patient experience evaluation survey may consist of, for example, 23 items, but is not limited thereto; the number of items and the composition of the items may be changed depending on hospital-specific evaluation criteria, patient groups, medical departments, or the purpose of the evaluation. Additionally, VoC input may consist of free-form VoC, multiple-choice VoC, voice VoC, image VoC, or a combination thereof.

[0156] The above guardian linkage service may include guardian registration, guardian identity verification, patient consent, setting of authority scope, viewing of patient information, checking ward round schedules, checking of diet information, sharing of treatment calendars, proxy application for certificates, verification of documents to be submitted to insurance companies, proxy participation in patient experience evaluations, and proxy input of VoC.

[0157] Within the scope of the patient's consent and established authority, guardians may apply for medical certificates, verify documents submitted to insurance companies, participate in patient experience evaluations, input Voice of Customer (VoC), and check post-discharge treatment schedules on behalf of elderly patients, minor patients, elderly parents, grandparents, or patients who have difficulty using the app.

[0158] In addition, pain scores, mood states, patient experience evaluation survey responses, and VoC data entered through the patient terminal (100) or guardian terminal (105) are transmitted to the Fix platform server (300) and can be used for low-point response detection, VoC event extraction, pain and mood state analysis, ontology mapping, cause candidate inference, and dynamic additional question selection.

[0159] FIG. 4 is a flowchart of an algorithm for LLM natural language processing, speech recognition, sentiment analysis, pain and mood state analysis, VoC event extraction, and low point response cause inference according to an embodiment of the present invention.

[0160] Referring to FIG. 4, the AI ​​analysis and low-point response cause inference algorithm of the present invention can be performed in the following steps: an input data collection step, an AI analysis pipeline processing step, a patient experience ontology-based cause inference step, a dynamic additional question selection step, and an analysis result output step.

[0161] First, AI inquiry or conversation data is collected (S400). The AI ​​inquiry or conversation data may include text inquiries, voice inquiries, ward inquiries, inquiries regarding certificates, inquiries regarding documents to be submitted to an insurance company, or inquiries regarding appointment scheduling with medical staff entered by a patient or guardian.

[0162] Next, a pain score is collected (S410). The pain score may represent the degree of pain entered by the patient via a number, scale, slider, or graphic interface.

[0163] Next, a mood state is collected (S420). The mood state may include emotional states such as anxiety, depression, discomfort, neutrality, and stability, which are entered by the patient through emojis, scales, or selection items.

[0164] Next, patient experience evaluation responses and VoC data are collected (S430). The patient experience evaluation responses may include, for example, responses to 23 questions, but are not limited thereto, and the number of questions and the composition of the questions may be changed according to hospital-specific evaluation criteria, patient groups, medical departments, or evaluation purposes. The VoC data may include free-form VoC, multiple-choice VoC, voice VoC, image VoC, or a combination thereof.

[0165] Next, behavior and event logs are collected (S440). The behavior and event logs may include checking the ward round schedule, checking meal information, confirming when a meal is possible after fasting, checking the treatment calendar, applying for certificates, checking documents to be submitted to the insurance company, making inquiries to AI, participating as a guardian, and receiving notifications.

[0166] Next, external data is collected (S450). The external data may include EMR, HIS, OCS, ward round schedule, diet information, examination schedule, surgery schedule, treatment schedule, information on documents required for submission to the insurance company, and information on the processing of certificate issuance, which are received through the hospital system linkage unit (800) or the insurance company linkage unit (950).

[0167] The collected data is transferred to an AI analysis pipeline, and data preprocessing is performed (S460). The data preprocessing may include data normalization, anonymization, pseudonymization, handling of missing values, removal of duplicates, format conversion, and quality checks.

[0168] If voice data is included, voice recognition is performed (S470). The voice recognition may be a process of converting a voice inquiry or voice VoC from a patient or guardian into text data.

[0169] Subsequently, LLM-based natural language processing is performed (S480). The LLM-based natural language processing may be a process of extracting at least one event information among intent, object, sentiment, keyword, time zone, place, contact point, action, ward, medical department, and medical service stage from AI inquiries, ward inquiries, VoC, and free-form survey responses.

[0170] Next, patient experience ontology mapping is performed (S490). At this stage, the Fix platform server (300) can connect evaluation items, low-point responses, VoC events, pain status, mood status, ward round schedule, diet information, treatment calendar usage history, history of requesting certificates and documents submitted to insurance companies, and history of verifying documents submitted to insurance companies with the evaluation area, event, problem type, surface cause, root cause, responsible party, additional question, and improvement action nodes of the patient experience ontology.

[0171] Next, a cause candidate graph is generated, and a reliability distribution for each cause candidate is calculated (S500). The cause candidate graph may be a graph connecting possible cause candidates from low-point items and VoC events, and a probability or reliability value may be assigned to each cause candidate.

[0172] Next, the reliability distribution for each cause candidate reflecting the input information is updated (S510). At this stage, the Fix Platform Server (300) can update the reliability distribution for each cause candidate by recalculating the probability or reliability value of the cause candidate associated with the input information based on at least one of the input information among low point responses, VoC events, pain scores, mood states, hospitalization context, behavior and event logs, external data, and patient experience ontology. For example, if the VoC includes the expression 'waited a long time at night,' the reliability of the cause candidate associated with the night call bell response delay or the lack of response from the night ward may increase.

[0173] Next, uncertainty is calculated (S520). The uncertainty may refer to the degree to which it is unclear which of the multiple cause candidates is the actual cause. The Fix Platform Server (300) may calculate the entropy of the reliability distribution for each cause candidate as the uncertainty, and, depending on the embodiment, may additionally use the reliability difference, variance, or a combination thereof among the top cause candidates.

[0174] Next, additional question candidates are searched (S530). The additional question candidates may consist of questions to verify facts experienced by the patient or guardian, and may be questions that increase the possibility of distinguishing between candidate causes.

[0175] Next, an allow set filter is applied (S540). The allow set filter can exclude from additional question candidates questions that require the direct identification of specific medical staff or employees, questions that request sensitive information, questions that repeat information already included in the VoC data, and questions that increase patient fatigue indicators.

[0176] Next, the expected information gain is calculated and an additional question is selected (S550). For each additional question candidate, the Fix Platform Server (300) can calculate the expected information gain as the degree of reduction between the entropy of the confidence distribution for each cause candidate before providing the additional question candidate and the entropy of the confidence distribution for each cause candidate expected after reflecting possible responses to the additional question candidate. The dynamic additional question selection unit (313) can select an additional question based on the expected information gain among the additional question candidates that have passed through the allow set filter.

[0177] Next, a termination condition is determined (S560). The termination condition may be determined based on at least one of whether the reliability of the first-ranked cause candidate is greater than or equal to a reference value, whether the entropy of the reliability distribution is less than or equal to a reference value, whether the number of additional questions has reached a reference number, or whether the patient fatigue index is greater than or equal to a reference value. If the termination condition is not satisfied, the Fix Platform Server (300) may return to the additional question candidate search step (S530).

[0178] When the termination condition is satisfied, the Fix Platform Server (300) determines the final cause candidate and separates the final cause into a surface cause and a root cause (S570). The surface cause may refer to an inconvenience or condition directly experienced by the patient, and the root cause may refer to a cause related to hospital operations that caused the inconvenience.

[0179] Next, a personalized response is generated (S580). The personalized response may include an AI inquiry response provided to the patient or guardian, immediate guidance, emotional care messages, guidance on ward rounds schedules, guidance on diet information, guidance on the treatment calendar, guidance on the results of processing certificates, or guidance on documents to be submitted to the insurance company.

[0180] Next, an administrator dashboard is created (S590). The administrator dashboard may include patient experience evaluation statistics, VoC statistics, pain and mood status statistics, satisfaction by ward, satisfaction by medical department, low score items, candidate causes, final causes, and improvement actions.

[0181] Next, an improvement action is proposed (S600). The improvement action may be generated based on the root cause and may include a responsible department, priority, deadline for action, and follow-up verification items.

[0182] Next, a notification or escalation is performed (S610). The notification or escalation may be transmitted to the patient, guardian, ward manager, administrative department, facility management department, insurance representative, or hospital manager.

[0183] Finally, feedback learning is performed (S620). The feedback learning unit (318) can update cause-question-action weights or hospital-specific / ward-specific prior probabilities based on post-survey, VoC changes, pain / mood changes, patient reactions, guardian usage history, treatment calendar usage history, certificate application history, insurance company submission document verification history, and administrator action history.

[0184] In FIG. 4, the survey DB (410), VoC DB (420), pain and mood DB (460), and ontology storage unit (500) may be represented as data storage units directly used for AI analysis and low-point response cause inference algorithms. The survey DB (410) provides low-point response and evaluation question information, the VoC DB (420) provides free-form VoC and event extraction results, the pain and mood DB (460) provides pain score and mood state information, and the ontology storage unit (500) may provide knowledge relationships necessary for generating cause candidate graphs and selecting additional questions.

[0185] Meanwhile, the AI ​​analysis and low-point response cause inference algorithm of Fig. 4 can be performed in a way that narrows down the causes of low-point responses by using low-point responses and free-form VoC together, rather than simply aggregating patient experience evaluation scores as in the conventional method.

[0186] Specifically, the Fix Platform Server (300) can map low-score response and evaluation item information stored in the survey DB (410) and free-form VoC and event extraction results stored in the VoC DB (420) to the patient experience ontology stored in the ontology storage unit (500). Accordingly, the Fix Platform Server (300) can calculate the reliability or probability for each possible cause candidate.

[0187] In this case, the patient experience ontology may correspond to a cause map representing the relationship between low-point responses and possible cause candidates. For example, if a low-point response occurs in the question regarding the provision of ward round time information in the doctor's domain and the VoC includes the expression "I didn't know the ward round time had changed," the Fix Platform Server (300) may generate the following as cause candidates: failure to provide ward round information, omission of notification of ward round change, or lack of opportunity for consultation.

[0188] Additionally, the Fix Platform Server (300) can select an additional question that can most significantly reduce the uncertainty of the cause candidate when the actual cause among multiple cause candidates is unclear. At this time, the dynamic additional question selection unit (313) calculates the expected information gain for each of the multiple additional question candidates, and after excluding questions that cause a specific medical staff or employee to be directly identified, questions that require sensitive information, questions that repeat information already included in the VoC data, and questions that increase patient fatigue through an allow set filter, the additional question with the greatest expected information gain can be selected.

[0189] Accordingly, only one or a few additional questions that are absolutely necessary may be provided to the patient or guardian. For example, if the VoC includes the expression “waited a long time at night,” the Fix platform server (300) may provide experience-based questions that can effectively distinguish the cause candidates, such as “Was the situation where you needed help closer to pain, assistance with mobility, or guidance on daily life?”

[0190] The Fix Platform Server (300) updates the reliability distribution for each cause candidate by reflecting the response to the additional question, and can terminate the additional question process when the reliability of the first-ranked cause candidate becomes greater than or equal to the reference value, the entropy of the reliability distribution becomes less than or equal to the reference value, or the number of additional questions or the patient fatigue index reaches the reference condition.

[0191] Subsequently, the Fix Platform Server (300) can separate the final cause into a surface cause and a root cause. The surface cause refers to the discomfort or condition directly experienced by the patient, and the root cause refers to the cause of the hospital's operation that caused the discomfort.

[0192] The Fix Platform Server (300) can provide immediate guidance messages, emotional care messages, ward round schedules, diet information, treatment calendars, document and insurance processing results, or guardian-shared information to the patient terminal (100) or guardian terminal (105) based on the surface cause. Additionally, the Fix Platform Server (300) can provide the responsible department, priority, action deadline, and improvement action to the hospital dashboard terminal (700) based on the root cause.

[0193] Additionally, the Fix platform server (300) can accumulate patient experience evaluation responses, VoC, pain scores, mood status, guardian usage history, treatment calendar usage history, certificate application history, insurance company submission document verification history, and administrator action history in the database section (400). And the feedback learning section (318) can reflect post-survey results, VoC changes, pain and mood changes, and action results in cause-question-action weights or prior probabilities by hospital and ward.

[0194] Accordingly, the present invention enables small and medium-sized hospitals to digitally perform and analyze patient experience evaluations, identify the causes of low scores with minimal additional questions, improve patient experience through immediate guidance and emotional care during hospitalization, and contribute to improving subsequent patient experience evaluation scores through root cause-based improvement actions.

[0195] FIG. 5 is a flowchart of the use of a patient / guardian app-based service, patient experience evaluation response, VoC input, and low point cause analysis according to one embodiment of the present invention.

[0196] Referring to FIG. 5, first, the patient or guardian accesses the patient app or guardian app (S100). The Fix platform server (300) performs user authentication and, if access is through a guardian terminal (105), checks whether the guardian is registered and the scope of authority (S110).

[0197] Subsequently, an entry purpose is selected by the user (S120). The entry purpose may include at least one of information verification, communication, data recording, or guardian functions.

[0198] When the information verification function is selected, the fix platform server (300) can provide the patient terminal (100) or guardian terminal (105) with a ward round schedule, diet information, time when meals can be eaten after fasting, hospital life guide, and treatment calendar (S130).

[0199] When the communication function is selected, the Fix Platform Server (300) can process AI inquiries, ward inquiries, medical staff consultation reservations, inquiries regarding applications for certificates, or inquiries regarding documents to be submitted to an insurance company (S140). In this case, if the inquiry from the patient or guardian includes emotional anxiety, depression, complaints of pain, or urgent requests, the Fix Platform Server (300) can provide an emotional care message or escalate the matter to the ward or the relevant department.

[0200] When the data recording function is selected, the Fix platform server (300) can collect pain scores, mood states, responses to patient experience evaluation surveys, and VoC inputs (S150). At this time, the patient experience evaluation survey may consist of, for example, 23 questions, but is not limited thereto, and the number of questions and the composition of the questions may be changed according to the evaluation criteria, patient group, medical department, or purpose of evaluation.

[0201] When the guardian function is selected, the guardian terminal (105) can perform patient information viewing, ward round schedule checking, diet information checking, treatment calendar sharing, proxy application for certificates, checking documents submitted to the insurance company, proxy participation in patient experience evaluation and proxy input of VoC within the set authority range (S160).

[0202] The Fix platform server (300) integrates data collected from each of the above functions (S170). The integrated data may include patient experience evaluation survey responses, VoC data, AI inquiry data, ward inquiry data, pain scores, mood status, ward round schedule inquiry history, diet information inquiry history, treatment calendar usage history, certificate application history, insurance company submission document verification history, and guardian proxy input information.

[0203] Subsequently, the Fix platform server (300) detects a low-point response or an abnormal state based on integrated data (S180). Here, the abnormal state may include a high pain score, a negative mood state, repeated inquiries, expressions of emotional anxiety, repeated VoCs from the same ward or medical department, repeated inquiries regarding documents or insurance, or repeated inquiries regarding ward rounds, diet, or treatment schedules.

[0204] Next, the fix platform server (300) determines whether there is a low-point response or an abnormal state (S190). If there is no low-point response or an abnormal state, the fix platform server (300) can provide a survey termination and thank message (S200) and can store general usage data in the database unit (400) (S210).

[0205] On the other hand, if a low score response or an abnormal state exists, the Fix Platform Server (300) may recommend a free-form VoC input or call previously collected VoC data (S220). For example, if a patient gave a low score to a specific item but did not enter the reason, the Fix Platform Server (300) may request a free-form input such as, "Please briefly describe the situation that was uncomfortable."

[0206] Subsequently, the fix platform server (300) extracts VoC events and emotions (S230). The VoC events may include at least one of a time zone, place, contact point, behavior, problem type, emotion, ward, medical department, and medical service stage.

[0207] Next, the Fix platform server (300) performs ontology mapping (S240). At this stage, the Fix platform server (300) can map low point responses, VoC events, pain status, mood status, ward round schedule, diet information, treatment calendar usage history, history of applying for certificates, history of checking documents submitted to the insurance company, and guardian behavior to the patient experience ontology.

[0208] Next, the Fix Platform Server (300) generates a graph of candidate causes and calculates a confidence distribution for each candidate cause (S250). The candidate causes may include, for example, a delay in the call bell response, failure to provide ward round information, omission of notification regarding changes to ward rounds, insufficient explanation before the examination, insufficient pain management, insufficient dietary information, insufficient guidance on lifting fasting, a gap in emotional care, insufficient guidance on certificates or documents to be submitted to the insurance company.

[0209] Next, the Fix platform server (300) applies an allow set filter and selects the minimum additional question with the greatest expected information gain (S260). At this stage, questions that require the direct identification of specific medical staff or employees, questions that request sensitive information, questions that repeat information already included in the VoC data, or questions that increase patient fatigue indicators may be excluded from the additional question candidates.

[0210] The patient or guardian responds to selected additional questions (S270). The additional questions may consist of experience-based questions that can effectively distinguish candidate causes. For example, if the VoC includes the expression "waited a long time at night," a question such as "Was the situation requiring help closer to pain, assistance with mobility, or guidance on daily life?" may be provided.

[0211] The fix platform server (300) updates the reliability distribution for each cause candidate by reflecting the additional question response (S280). Subsequently, the fix platform server (300) determines whether the termination condition is satisfied (S290). The termination condition may be determined based on at least one of whether the reliability of the first-ranked cause candidate is greater than or equal to a reference value, whether the entropy of the reliability distribution is less than or equal to a reference value, whether the number of additional questions has reached a reference number, or whether the patient fatigue index is greater than or equal to a reference value. If the termination condition is not satisfied, the fix platform server (300) may return to the additional question selection step (S260).

[0212] When the termination condition is satisfied, the Fix Platform Server (300) determines the final cause and separates the final cause into a surface cause and a root cause (S300). The surface cause may refer to an inconvenience or condition directly experienced by the patient, and the root cause may refer to a cause related to hospital operations that caused the inconvenience.

[0213] Afterwards, the Fix platform server (300) can immediately provide guidance, emotional care messages, ward round schedules, diet information, treatment calendars, information shared with guardians, or document / insurance processing results to the patient terminal (100) or guardian terminal (105) (S310).

[0214] Additionally, the fix platform server (300) can provide improvement actions for administrators to the hospital dashboard terminal (700) (S320). The improvement actions for administrators can be generated based on the root cause and may include a responsible department, priority, action deadline, and follow-up verification items.

[0215] Finally, the Fix platform server (300) can perform feedback learning based on post-survey, VoC changes, pain and mood changes, patient reactions, guardian usage history, treatment calendar usage history, certificate application history, insurance company submission verification history, and administrator action history (S330). Accordingly, cause-question-action weights or prior probabilities by hospital and ward can be updated.

[0216] FIG. 6 is a flowchart of the guardian registration, patient consent, authority setting, and authority management procedures according to one embodiment of the present invention.

[0217] Referring to FIG. 6, first, the patient can request guardian registration through the patient terminal (100) (S600). At this time, the patient can enter the guardian's name, contact information, relationship information, or invitation information in the guardian addition menu.

[0218] Next, the patient may perform identity verification and consent to guardian registration (S610). The identity verification may be performed by mobile phone authentication, simple authentication, joint certificate authentication, in-person verification procedure within the hospital, or a combination thereof.

[0219] Next, the patient can set the scope of authority to be granted to the guardian (S620). The scope of authority may include at least one of the following: basic viewing of patient information, checking ward round schedule, checking diet information, viewing or sharing of treatment calendar, AI inquiry or ward inquiry, proxy application for certificates, checking documents submitted to the insurance company, proxy participation in patient experience evaluation, proxy input of VoC, and setting of notification reception.

[0220] When the guardian registration request is completed, the Fix platform server (300) can send a notification of the completion of the registration request to the patient terminal (100) or the guardian terminal (105) (S630).

[0221] Subsequently, the guardian terminal (105) may receive an invitation link, a registration code, or a notification message (S640). The guardian may perform identity verification through the guardian terminal (105) (S650). The guardian identity verification may include mobile phone authentication, simple authentication, joint certificate authentication, or a verification procedure within the hospital.

[0222] Once the guardian's identity is verified, the guardian can accept the invitation (S660). Afterwards, the guardian can use the guardian service within the scope of authority verified by the Fix Platform Server (300) (S670).

[0223] The Fix platform server (300) can verify the registration information of the patient and the guardian (S680). At this time, the Fix platform server (300) can verify at least one of the patient information, guardian information, guardian contact information, invitation code, registration code, authentication information, and registration validity period.

[0224] Additionally, the Fix platform server (300) can verify family relationships, guardian relationships, or patient consent (S690). The verification can be performed based on relationship information entered by the patient, hospital registration information, guardian submission information, patient consent information, or hospital administrator verification information.

[0225] Once verification is complete, the Fix platform server (300) can apply a guardian authority policy (S700). Accordingly, the guardian terminal (105) can perform actions such as viewing patient information, checking ward round schedules, checking diet information, sharing treatment calendars, applying for certificates on behalf of others, checking documents submitted to insurance companies on behalf of others, participating in patient experience evaluations on behalf of others, inputting VoC on behalf of others, and receiving notifications only within the set authority range.

[0226] Afterwards, the Fix platform server (300) can record the guardian's access, inquiry, application, proxy response, VoC proxy input, treatment calendar sharing, notification reception, and permission change history as an audit log (S710).

[0227] The history of guardian registration and authority management can be stored in the database section (400). Specifically, the guardian authority DB (470) can store guardian registration information, information on the relationship between the patient and the guardian, patient consent information, guardian identity verification information, guardian authority scope, proxy application history, proxy evaluation participation history, proxy VoC input history, treatment calendar sharing history, notification reception settings, and audit logs.

[0228] In FIG. 6, the guardian authority DB (470) may be represented as a data storage unit directly related to guardian registration and authority management. The guardian authority DB (470) may be used to determine the authority to view patient information on the guardian terminal (105), check ward round schedules, check diet information, share treatment calendars, apply for certificates on behalf of others, check documents submitted to insurance companies, participate in patient experience evaluations on behalf of others, input VoC on behalf of others, and receive notifications.

[0229] FIG. 7 is a flowchart showing the determination of the final cause, separation of the surface cause and the root cause, and separation of patient, guardian, and administrator actions according to one embodiment of the present invention.

[0230] Referring to FIG. 7, the fix platform server (300) can determine the final cause candidate based on a cause candidate graph, a reliability distribution for each cause candidate, and additional question responses (S700). The final cause candidate may be determined based on at least one of the reliability of the first-ranked cause candidate, the reliability difference between cause candidates, entropy, or whether the termination condition is satisfied.

[0231] Next, the Fix Platform Server (300) can separate the final cause into a surface cause and a root cause (S710). The surface cause may refer to an inconvenience or condition directly experienced or expressed by the patient, and the root cause may refer to a hospital operational cause that caused the surface cause.

[0232] For example, if the superficial cause is the inconvenience of not knowing the ward round time, the underlying cause may be an inadequate notification system for changes to ward rounds or insufficient coordination with the ward round schedule. Furthermore, if the superficial cause is a delay in pain management, the underlying cause may be an inadequate response system for nighttime call bells, insufficient pain management procedures, or a failure in the handover process.

[0233] Next, the Fix platform server (300) can determine whether patient discomfort or emotional care is needed (S720). The need for emotional care can be determined based on at least one of the following: mood state, VoC emotion analysis results, whether there are repeated inquiries, pain score, low response in patient experience evaluation, AI inquiry content, or ward inquiry content.

[0234] If patient discomfort or the need for emotional care is recognized, the Fix platform server (300) may generate an immediate guidance message for the patient (S730). The immediate guidance message may include at least one of the following: current status, results of verification regarding the discomfort, next action, details scheduled for verification by the hospital, ward round schedule, diet information, treatment calendar, document processing status, or guidance on insurance submission documents.

[0235] Next, the Fix platform server (300) can perform guardian notifications and share treatment schedules (S740). If a guardian is registered and relevant permissions are set, the Fix platform server (300) can send ward rounds schedules, diet information, treatment calendars, post-discharge treatment schedules, results of processing certificates, guidance on documents to be submitted to the insurance company, or notifications related to emotional care to the guardian terminal (105).

[0236] Next, the fix platform server (300) can generate improvement actions for administrators (S750). The improvement actions for administrators can be generated based on the root cause and may include the responsible department, action priority, action deadline, follow-up verification items, whether it occurs repeatedly, and information on the relevant ward or medical department.

[0237] For example, if the root cause is an inadequate notification system for ward round changes, improvement actions for administrators may include measures to automatically send notifications to patient terminals (100) and guardian terminals (105) when ward rounds are changed. Additionally, if the root cause is an inadequate response system for night call bells, improvement actions for administrators may include strengthening night rounds, monitoring call bell response times, or checking ward staff handover procedures.

[0238] The hospital dashboard terminal (700) displays the improvement action for the administrator and, if necessary, can send a notification to the ward, administrative department, facility management department, insurance manager, or hospital administrator (S760). At this time, the hospital dashboard terminal (700) can display the processing status of the improvement action, the responsible department, the action deadline, the processing result, and whether follow-up action has been taken.

[0239] Afterwards, the Fix Platform Server (300) can store the history of providing guidance for patients, the history of notifications to guardians, the history of providing improvement actions for administrators, the history of processing by the responsible department, and the results of actions in the database section (400) (S770).

[0240] Additionally, the feedback learning unit (318) can update cause-question-action weights or prior probabilities by hospital and ward by reflecting user feedback, post-surveys, changes in VoC, changes in pain and mood, guardian usage history, and administrator action results. Accordingly, the Fix platform server (300) can perform more sophisticated cause inference and improvement action recommendations when similar low-point responses or VoCs occur thereafter.

[0241] FIG. 8 is a flowchart of the construction of data linkage for hospitalization guidance, application for certificates, and documents submitted to insurance companies based on hospital data OCR according to one embodiment of the present invention.

[0242] Referring to FIG. 8, first, a hospital administrator can upload hospital data (S800). The hospital data may include PDFs, images, brochures, notices, scanned documents, ward round schedules, meal plans, inpatient life guides, ward guides, test guides, discharge guides, certificate document guides, insurance company submission document guides, or FAQ documents.

[0243] Next, the OCR / document conversion unit (317) can extract text from the uploaded hospital data (S810). At this time, the OCR / document conversion unit (317) can recognize document titles, tables, characters within images, keywords, paragraph structures, item names, and formatting information.

[0244] Next, the Fix platform server (300) can classify the extracted text by document type (S820). The document types may include inpatient life guide, ward guide, ward round schedule, diet information, fasting guide, treatment calendar, certificate document guide, insurance company submission document guide, and FAQ.

[0245] Next, the classified data can be stored in the database section (400) (S830). Specifically, inpatient life guide, ward guide, test guide, discharge guide, and FAQ data can be stored in the guide content DB (430). Rounds schedule, rounds change information, diet information, fasting status, expected time when eating is possible after fasting, and treatment schedule can be stored in the rounds, diet, and treatment calendar DB (440). Guide to certificate documents, documents required for submission to the insurance company, insurance company linkage information, and electronic transmission-related information can be stored in the document and insurance linkage DB (450).

[0246] Subsequently, the patient or guardian can view stored information or make an application through the patient terminal (100) or guardian terminal (105) (S840). For example, the patient or guardian can view information regarding hospitalization guidelines, ward rounds schedules, meal information, treatment calendars, guidelines for certificates, or guidelines for documents to be submitted to the insurance company. Additionally, if the guardian is granted proxy application authority, the guardian can make an application for certificates on behalf of the patient.

[0247] Next, the AI ​​inquiry processing unit (305) can perform an AI inquiry response or document application guidance based on the stored document data (S850). For example, if a patient or guardian inquires "what documents are required for an insurance claim after discharge," the AI ​​inquiry processing unit (305) can generate a response based on the information on documents required for submission to an insurance company stored in the document-insurance linkage DB (450).

[0248] Next, the document and insurance processing unit (306) can verify the documents required by the insurance company (S860). The documents required by the insurance company can be verified based on the insurance company linkage unit (950), information on documents submitted by the insurance company, internal hospital document standards, or user-entered insurance company information.

[0249] Next, the Fix platform server (300) can be linked with a hospital system or an insurance company (S870). At this time, the hospital system linkage unit (800) can transmit a request for the issuance of certificate documents to the hospital system, and the insurance company linkage unit (950) can verify the documents required for submission to the insurance company, link with the insurance company API, or link with electronic transmission.

[0250] Next, the processing results and notifications may be provided to the patient terminal (100) or the guardian terminal (105) (S880). The processing results and notifications may include whether the application for certificate documents has been received, whether issuance is possible, whether issuance has been completed, a list of documents required for submission to the insurance company, whether electronic transmission is possible, or the results of electronic transmission processing.

[0251] Finally, the Fix platform server (300) can store processing history, inquiry history, application history, issuance history, insurance company linkage history, electronic transmission history, and user feedback in the database section (400) (S890). The stored history and feedback can be reflected in updating hospital data, improving AI inquiry responses, improving guidance on certificate documents, and improving guidance on documents to be submitted to the insurance company.

[0252] In FIG. 8, the guidance content DB (430), the ward rounds, diet, and treatment calendar DB (440), and the document and insurance linkage DB (450) can be represented as data storage units directly related to the construction of guidance, document, and insurance linkage data based on hospital data OCR. The guidance content DB (430) can store inpatient life guidance, ward guidance, test guidance, discharge guidance, FAQ, and AI inquiry response data.

[0253] The ward rounds, meal plan, and treatment calendar DB (440) can store ward round schedules, ward round change information, meal plans, fasting status, expected time when eating is possible after fasting, treatment schedules during hospitalization, and treatment schedules after discharge. The document and insurance linkage DB (450) can store information on certificate documents, documents required for submission to the insurance company, application history, issuance history, electronic transmission history, and insurance company linkage history.

[0254] Example 1: Guardian Registration and Proxy Participation in Patient Experience Evaluation

[0255] This embodiment relates to registering a guardian for elderly patients, minor patients, patients who have difficulty using the app, or patients who require assistance from a guardian, and to cases where the registered guardian participates in the patient experience evaluation on behalf of the patient or inputs Voice of Customer (VoC) within the scope of set permissions.

[0256] For example, if a child of an elderly patient is registered as a guardian, the patient can perform a guardian registration request through the patient terminal (100). Alternatively, if it is difficult for the patient to operate the app directly, a guardian registration request can be performed auxiliaryly through the hospital administrator terminal or the hospital dashboard terminal (700).

[0257] At this time, the patient or hospital administrator may enter the guardian's name, contact information, relationship information with the patient, or invitation information. The Fix platform server (300) may send an invitation link, registration code, or notification message to the guardian terminal (105) based on the entered guardian information.

[0258] The guardian can verify the invitation link or registration code through the guardian terminal (105) and perform identity verification through mobile phone authentication, simple authentication, joint certificate authentication, or an in-hospital verification procedure. The Fix platform server (300) can determine whether to register the guardian after verifying patient consent information, guardian identity verification information, and relationship information between the patient and the guardian.

[0259] Once guardian registration is complete, the patient or hospital administrator may set the scope of permissions to be granted to the guardian. The said scope of permissions may include at least one of the following: viewing patient information, checking ward rounds schedule, checking dietary information, sharing treatment calendars, applying for certificates on behalf of the patient, checking documents to be submitted to the insurance company, participating in patient experience evaluations on behalf of the patient, inputting VoC on behalf of the patient, and setting up notification reception.

[0260] Afterward, the guardian can participate in the patient experience evaluation survey on behalf of the patient or input VoC regarding the patient's inconveniences within the scope of the set authority. For example, if an elderly patient is unaware of the change in ward round time or has difficulty using the app directly, the guardian can input VoC such as "The guardian did not know the ward round time had changed and contacted the hospital several times" through the guardian terminal (105).

[0261] At this time, the guardian's patient experience evaluation response or VoC input can be stored as a guardian proxy response to distinguish it from the patient's own response. Specifically, the database unit (400) can store the respondent, input terminal, input time, guardian authority scope, whether patient consent was given, and whether the input was made by proxy as metadata.

[0262] The Fix Platform Server (300) can separately identify the guardian's proxy response so as not to confuse it with the patient's own response, while also using it as auxiliary data for inferring the cause of the low-score response. For example, if a low-score response occurs in the patient experience evaluation regarding the question on providing ward round time information, and the guardian's VoC includes content regarding insufficient notification of ward round changes, the Fix Platform Server (300) can generate the non-provision of ward round information, omission of notification of ward round changes, or insufficient sharing with guardians as potential causes.

[0263] Additionally, the Fix platform server (300) maps the guardian input content to the patient experience ontology, and can reflect guardian actions, guardian inquiries, whether the treatment calendar is shared, whether the ward round schedule is checked, and whether notifications are received in the cause candidate inference. Accordingly, the guardian linkage data can be used to complementarily analyze the causes of low patient experience in elderly patients or patients who have difficulty using the app.

[0264] The history of guardian access, viewing, proxy application, proxy evaluation participation, proxy VoC input, and treatment calendar sharing can be stored in the guardian authority DB (470). Additionally, the Fix platform server (300) can record the above history as an audit log to manage the situation so that access or proxy input outside the scope of guardian authority does not occur.

[0265] Accordingly, according to the present embodiment, elderly patients, minor patients, or patients who have difficulty using the app can participate in patient experience evaluation and VoC input through a guardian, and the guardian input data is stored separately from the patient's own response and can be used as an auxiliary tool for inferring the cause of low-point responses.

[0266] Example 2: Provision of ward round schedule and improvement of physician consultation

[0267] This embodiment relates to a case where a patient assigns a low score to a patient experience evaluation item in the physician domain and inputs a VoC related to the ward round schedule or the opportunity to consult with a doctor.

[0268] For example, a patient can provide a low score on questions in the doctor domain regarding whether they had an opportunity to meet and speak with the doctor or whether they were provided with information regarding ward rounds, and input content into the Voice of Customer (VoC) such as, "It was difficult to meet the attending physician because I did not know when the ward rounds were," or "The guardian contacted the hospital multiple times because they were unaware that the ward rounds had changed."

[0269] In this case, the Fix platform server (300) can map low-point responses, VoC data, ward round schedule lookup history, ward round change information, and guardian inquiry history to the patient experience ontology. Accordingly, the Fix platform server (300) can identify failure to provide a ward round schedule, omission of ward round change notifications, insufficient guidance on available consultation times, insufficient sharing with guardians, or delay in responding to ward inquiries as potential causes.

[0270] If the actual cause among multiple candidate causes is unclear, the Fix Platform Server (300) may provide additional questions based on experience to the patient or guardian. For example, additional questions such as, "Was it difficult to check the ward round time because the ward round time was not displayed, because the ward round time was changed, or because it was difficult to know how to request an interview?" may be provided.

[0271] The Fix platform server (300) can update the confidence distribution for each candidate cause by reflecting the additional question response and separate the final cause into a surface cause and a root cause. For example, the surface cause may be "difficulty meeting the attending physician because the ward round time is unknown," and the root cause may be "inadequate notification system for ward round changes," "inadequate integration with the ward round schedule system," or "missing guardian notification settings."

[0272] Once the final cause is determined, the Fix Platform Server (300) can provide the attending physician's ward round schedule, ward round change notifications, available consultation times, or medical staff consultation appointment guidance to the patient terminal (100) or guardian terminal (105). If a guardian is registered and relevant permissions are set, the ward round schedule or available consultation times can also be shared with the guardian terminal (105).

[0273] Additionally, the hospital dashboard terminal (700) may display improvement actions for administrators, such as improving the ward round change notification procedure, setting automatic notifications for the ward round schedule, enabling the guardian sharing function, improving the ward inquiry response procedure, or improving the medical staff consultation appointment procedure.

[0274] Accordingly, according to the present embodiment, low-score responses in the physician domain are not merely aggregated as low scores but can be structured into specific causes such as insufficient provision of ward round schedules or insufficient guidance on consultations, and immediately verifiable ward round and consultation information can be provided to patients and guardians, and specific actions for improving the ward round notification system can be provided to hospital administrators.

[0275] Example 3: Provision of dietary information and timing for eating after fasting

[0276] This embodiment relates to cases where a patient or guardian inputs an inquiry or VoC regarding dietary information, whether fasting is required, or when a meal can be eaten after fasting.

[0277] For example, a patient can input an AI inquiry or VoC through the patient terminal (100) such as “I was anxious because I didn’t know when I could eat,” “I was not informed whether I could eat after the examination,” or “I didn’t know when the fasting would end.”

[0278] In this case, the Fix Platform Server (300) can extract event information related to inquiries about when meals are possible, lack of guidance on lifting fasting, lack of diet information, lack of guidance after the test, or anxiety emotions from the input sentence through LLM natural language processing and sentiment analysis of the AI ​​processing unit (600).

[0279] The Fix platform server (300) maps the extracted event information to the patient experience ontology and can identify the lack of dietary information, lack of guidance on lifting fasting, lack of guidance on when a meal is possible after the examination, or lack of ward guidance process as candidate causes.

[0280] Afterwards, the Fix platform server (300) can check the patient's dietary status, whether they are fasting, examination schedule, surgery schedule, the scheduled time for lifting the fast, and the scheduled time for eating through the ward rounds, diet, and treatment calendar DB (440) or the hospital system linkage unit (800).

[0281] Based on the results of the verification, the Fix platform server (300) can provide guidance to the patient terminal (100) or guardian terminal (105) regarding the current dietary status, information on the meal plan to be provided, whether fasting is being maintained, the scheduled time for eating after fasting, or whether ward verification is required. For example, guidance such as "You are currently fasting after the examination, and the scheduled time for eating will be provided after verification by the department in charge" or "The scheduled time to end fasting is 3:00 PM, after which porridge will be provided" may be provided.

[0282] If a guardian is registered and relevant permissions are set, the above diet information, fasting status, and expected time for eating may also be shared with the guardian terminal (105). Accordingly, the guardian can check the patient's eating status and guidance status after the examination.

[0283] Additionally, the Fix platform server (300) can determine whether inquiries or VoCs related to diet information or guidance on lifting fasting occur repeatedly in the same ward, the same type of examination, or the same medical department.

[0284] If repeated occurrences are confirmed, the hospital dashboard terminal (700) may display improvement actions for administrators, such as strengthening meal guidance, setting automatic notifications for when meals are available after examination, supplementing ward notices, checking meal system integration, or improving nursing staff guidance procedures.

[0285] Accordingly, according to the present embodiment, patient anxiety regarding dietary information or the timing of when meals can be eaten after fasting is not merely treated as a simple inquiry, but can be structured as a candidate cause for low scores in patient experience evaluations. Additionally, patients and guardians are provided with immediately verifiable dietary and fasting guidance, and hospital administrators are provided with actions to improve the dietary guidance process to reduce repetitive inquiries.

[0286] Example 4: Sharing Treatment Calendar and Post-Discharge Treatment Schedule

[0287] This embodiment relates to a case where a treatment schedule during hospitalization or a treatment schedule after discharge is provided to a patient terminal (100) and a guardian terminal (105).

[0288] In the case of a patient scheduled for discharge, the Fix platform server (300) can receive outpatient treatment dates, examination dates, medication schedules, rehabilitation schedules, treatment schedules, attending physician consultation schedules, and hospital appointment information through the hospital system linkage unit (800).

[0289] The Fix Platform Server (300) can organize the received schedule information into a calendar form through the treatment calendar management unit (316) and store the generated treatment calendar in the ward rounds, diet, and treatment calendar DB (440).

[0290] The patient can check the treatment schedule during hospitalization, outpatient visit dates after discharge, examination dates, medication schedule, rehabilitation schedule, and appointment information through the patient terminal (100). Additionally, if a guardian is registered and relevant permissions are set, the Fix platform server (300) can share the treatment calendar with the guardian terminal (105).

[0291] At this time, the Fix platform server (300) can provide notifications regarding changes to the treatment schedule, the arrival of an outpatient appointment date, scheduled examination date, medication schedule, rehabilitation schedule, or attending physician consultation schedule to the patient terminal (100) or guardian terminal (105).

[0292] For example, if a child of an elderly patient is registered as a guardian, the guardian can check the outpatient appointment date, examination date, medication schedule, and rehabilitation schedule of the elderly parent after discharge through the guardian terminal (105). In addition, the parents of a minor patient can check the treatment appointment schedule and hospital visit schedule through the guardian terminal (105).

[0293] The Fix platform server (300) can store treatment calendar viewing history, notification reception history, and schedule change history in the database unit (400). The history can be used to determine whether the patient or guardian has been sufficiently informed about the treatment schedule.

[0294] In addition, if a patient or guardian inputs a VoC such as “I didn’t know when to come back to the hospital after discharge,” “It was difficult to check the date of the test appointment,” or “The guardian was not shared with the treatment schedule,” the Fix platform server (300) can identify the failure to provide a treatment calendar, lack of guidance on the treatment schedule after discharge, omission of notification of schedule changes, or lack of sharing with the guardian as potential causes.

[0295] Once the final cause is determined, the Fix Platform Server (300) can provide the patient or guardian with guidance on the treatment schedule, guidance on notification settings, or guidance on guardian sharing settings. Additionally, the hospital dashboard terminal (700) may display improvement actions for administrators, such as improving the post-discharge treatment schedule guidance procedure, automating schedule change notifications, improving the guardian sharing procedure, or checking the treatment calendar linkage.

[0296] Accordingly, according to the present embodiment, patients and guardians can easily check treatment schedules during hospitalization and after discharge, and in particular, the management of treatment and appointment schedules becomes easier for elderly parents, grandparents, minor patients, or patients who have difficulty using apps. Furthermore, it is possible to structurally analyze the causes of poor patient experience due to insufficient treatment schedule guidance and link this to actions for improving hospital operations.

[0297] Example 5: Application for Certificates and Linkage with Insurance Companies

[0298] This embodiment relates to a case where a patient or guardian requests certificates for insurance claims, submission to a company or school, or personal safekeeping, and verifies the documents required for submission to an insurance company.

[0299] For example, a patient or guardian may select a menu for applying for certificates for the purpose of claiming insurance benefits through a patient terminal (100) or a guardian terminal (105). In this case, if the guardian is registered and the relevant authority is set, the guardian may perform the application for certificates on behalf of the patient.

[0300] The Fix Platform Server (300) can check the purpose of application, insurance company information, type of treatment, whether hospitalization is required, whether examination or surgery is required, billing items, and user input information through the document / insurance processing unit (306). Additionally, the Fix Platform Server (300) can check the list of documents required for submission to the insurance company through the document / insurance linkage DB (450), the hospital's internal document standards, or the insurance company linkage unit (950).

[0301] For example, if a medical certificate, admission / discharge confirmation, medical expense receipt, medical expense detailed statement, prescription, test results, or surgery confirmation is required for an insurance claim, the Fix platform server (300) can display the list of required documents on the patient terminal (100) or guardian terminal (105).

[0302] After checking the indicated list of required documents, the patient or guardian can select the documents to be issued, the purpose of submission, the method of receipt, or whether to electronically transmit them. Once the application is completed, the Fix platform server (300) can transmit the request for issuance of certificate documents to the hospital system through the hospital system integration unit (800).

[0303] The hospital system linkage unit (800) can check the issuance availability, processing status, issuance completion status, or requirements for supplementation by linking with the HIS, EMR, OCS, or certificate issuance system. Additionally, the insurance company linkage unit (950) can check the documents required for submission to the insurance company, check the possibility of electronic transmission, or perform electronic transmission processing through insurance company API linkage or electronic transmission linkage.

[0304] The processing result may be provided to the patient terminal (100) or guardian terminal (105) through the notification linkage unit (900). The processing result may include whether the application has been received, whether issuance is possible, whether issuance has been completed, notification of receipt, electronic transmission processing result, whether supplementary documents or submission to the insurance company has been completed.

[0305] Additionally, the Fix platform server (300) can store the history of applications for certificates, the history of verification of documents submitted to insurance companies, the history of issuance processing, the history of electronic transmission, the history of applications by guardians, and the history of user inquiries in the document-insurance linkage DB (450).

[0306] When a patient or guardian inputs a VoC stating, "I did not know what documents were needed for the insurance claim," "I re-applied for documents several times," or "The information received at the administrative counter was different from the information provided in the app," the Fix Platform Server (300) can identify the following as potential causes: insufficient guidance on certificate documents, insufficient guidance on documents to be submitted to the insurance company, inadequate administrative guidance system, or unclear document application process.

[0307] Once the final cause is determined, the Fix Platform Server (300) can provide the patient or guardian with a list of necessary documents, application methods, processing status, or instructions for submission to the insurance company. Additionally, the hospital dashboard terminal (700) may display improvement actions for administrators, such as supplementing the instructions for certificate documents, organizing the standards for documents to be submitted by each insurance company, improving the guidance procedures at the administrative counter, checking electronic transmission linkages, or supplementing FAQs to reduce repetitive inquiries.

[0308] Therefore, according to this embodiment, patients or guardians can easily verify and accurately apply for the certificates required for submission to insurance companies, and hospitals can reduce the burden of inquiries at administrative counters and the need to re-apply for documents. Furthermore, inconveniences related to documents and insurance can be structured as causes of poor patient experience, leading to actions to improve hospital operations.

[0309] Example 6: Analysis of Low Point Causes Based on Pain Score and Mood State

[0310] This embodiment relates to a case in which the cause of a low score response is analyzed by combining the pain score and mood state entered through the patient terminal (100) or guardian terminal (105) with the patient experience evaluation response and VoC data.

[0311] For example, if a patient gives a low score to the patient experience evaluation item in the medication and treatment process area and simultaneously inputs a high pain score, the Fix platform server (300) can analyze the low score response and the pain score together.

[0312] In this case, the Fix platform server (300) can map pain scores, low-score responses related to medication, examination, and treatment, VoC data, AI inquiry data, and ward inquiry data to the patient experience ontology. Accordingly, the Fix platform server (300) can identify poor pain management, delay in taking action after complaining of pain, insufficient explanation of medication, insufficient guidance on pain after examination or treatment, delay in responding to the night call bell, or omission of ward handover as candidate causes.

[0313] In addition, if the patient inputs the mood state as anxiety, depression, or discomfort and gives a low score to the patient experience evaluation item in the emotional support area, the Fix platform server (300) can analyze the mood state, the low score response in the emotional support area, the free-form VoC, and the AI ​​inquiry content together.

[0314] In this case, the Fix platform server (300) can identify a gap in emotional care, failure to confirm the state of anxiety, lack of guidance on hospital life, lack of explanation before examination or treatment, lack of sharing with guardians, or a delay in connecting to ward counseling as potential causes.

[0315] If the actual cause is unclear among multiple candidate causes, the Fix Platform Server (300) may provide additional questions based on experience facts to the patient or guardian. For example, in the case of a low point response related to pain, a question such as "Which was the most uncomfortable aspect after feeling pain: a delay in pain treatment, a lack of explanation, or a delay in the call bell response?" may be provided. In the case of a low point response related to emotional anxiety, a question such as "Which was the main reason you felt anxious: a lack of explanation of treatment, a lack of information sharing with the guardian, or a lack of connection to ward counseling?" may be provided.

[0316] The Fix platform server (300) can update the reliability distribution for each candidate cause by reflecting the additional question response and separate the final cause into a surface cause and a root cause. For example, the surface cause may be "feeling that the action was delayed despite the pain persisting" or "feeling anxious due to a lack of explanation regarding the treatment process," and the root cause may be "inadequate pain management procedures," "inadequate night call bell response system," "lack of explanation process before examination," or "inadequate emotional care connection procedures."

[0317] Once the final cause is determined, the Fix platform server (300) can provide pain management guidance, guidance on scheduled confirmation by the responsible department, emotional care messages, guidance on hospitalization life, information shared with the guardian, or guidance on connecting to ward counseling to the patient terminal (100) or guardian terminal (105).

[0318] Additionally, the hospital dashboard terminal (700) may display improvement actions for administrators, such as improving pain management procedures, checking the night call bell response system, strengthening pain guidance after examination and treatment, improving emotional care procedures, setting ward escalation standards, or improving guardian sharing procedures.

[0319] The Fix platform server (300) can store changes in pain scores, changes in mood state, patient experience evaluation responses, changes in VoC, and administrator action history in the database unit (400). The feedback learning unit (318) can use the above data to update the weights between pain / mood state and low point cause candidates or the prior probabilities by ward.

[0320] Accordingly, according to the present embodiment, pain scores and mood states are not merely used as simple record information, but can also be utilized as analytical data to more accurately infer the causes of low responses in the patient experience evaluation. As a result, immediate guidance or emotional care can be provided to the patient, and specific actions to improve pain management and emotional care procedures can be provided to hospital administrators.

[0321] Example 7: Providing dynamic follow-up questions and actions for low-point responses

[0322] This embodiment relates to a case where a low score response occurs in a patient experience evaluation, and the cause of the low score response is not clear from free-form VoC alone, and the Fix Platform Server (300) provides dynamic additional questions to clarify the cause of the low score response, and separately provides measures for the patient and improvement actions for the administrator based on the result.

[0323] For example, a patient might give low scores to items in the nurse, medication and treatment process, or overall evaluation areas of the patient experience survey and input into the Voice of Customer (VoC) comments such as "I waited a long time at night" or "I asked for help at night but they were late."

[0324] In this case, the Fix Platform Server (300) can extract event information related to nighttime hours, call bells or requests for help, response delays, feelings of discomfort, ward contacts, and medical service stages from the VoC through LLM natural language processing and sentiment analysis of the AI ​​processing unit (600).

[0325] The Fix platform server (300) can map extracted event information, low point response, pain score, mood state, AI inquiry data, and ward inquiry data to the patient experience ontology. Accordingly, the cause candidate inference unit (312) can generate cause candidates such as a delay in night call bell response, missing request, night staff shortage, delay in action after complaining of pain, lack of assistance with movement, or lack of guidance on daily life.

[0326] In cases where the actual cause among multiple cause candidates is unclear, the dynamic additional question selection unit (313) can calculate the expected information gain for each of the multiple additional question candidates. The expected information gain may be a value indicating how much the uncertainty of the reliability distribution for each cause candidate is reduced when a specific question is provided.

[0327] At this time, the dynamic additional question selection unit (313) can exclude from additional question candidates questions that require direct identification of specific medical staff or employees, questions that request sensitive information, questions that repeat information already included in the VoC data, and questions that increase patient fatigue by applying an allow set filter.

[0328] Afterward, the dynamic additional question selection unit (313) can select the question with the greatest expected information gain among the additional question candidates that have passed through the allow set filter. For example, experience-based questions such as "Which situation was closest to pain, mobility assistance, or daily life guidance?" or "Which was closest to the most inconvenient aspect after requesting help, such as delayed response, lack of explanation, or not knowing how to make additional requests?" can be provided to the patient terminal (100) or guardian terminal (105).

[0329] When a patient or guardian responds to an additional question, the Fix platform server (300) can update the reliability distribution for each candidate cause by reflecting the response. For example, if the patient selects "pain," the reliability of delay in action after complaining of pain or delay in response to the night call bell may increase, and if the patient selects "assistance with movement," the reliability of lack of night movement support or ward staffing issues may increase.

[0330] The Fix Platform Server (300) can terminate the additional questioning process and determine the final cause when the reliability of the first priority cause candidate becomes greater than or equal to the reference value, the entropy of the reliability distribution becomes less than or equal to the reference value, or the number of additional questions or the patient fatigue index reaches the reference condition.

[0331] Once the final cause is determined, the Fix Platform Server (300) can separate the final cause into a surface cause and a root cause. For example, the surface cause may be "feeling that one has waited a long time after requesting help at night," and the root cause may be "inadequate night call bell response system," "problems with night ward staffing," "inadequate procedures after complaining of pain," or "lack of night rounding procedures."

[0332] Subsequently, the Fix platform server (300) can provide immediate guidance messages, emotional care messages, guidance on scheduled ward checks, pain management guidance, or guardian sharing information to the patient terminal (100) or guardian terminal (105). For example, a guidance such as, "The ward will be checking on the situation where you are experiencing discomfort, and if the pain persists, please notify us immediately via the call bell or AI inquiry," may be provided to the patient.

[0333] Additionally, improvement actions for administrators may be displayed on the hospital dashboard terminal (700). The improvement actions for administrators may include checking the night call bell response system, strengthening night rounds, monitoring call bell response times, improving pain management procedures, checking night handover procedures, or reviewing ward staffing.

[0334] The Fix Platform Server (300) can store additional question responses, final causes, patient guidance provision history, guardian sharing history, and improvement actions and action results for administrators in the database unit (400). The feedback learning unit (318) can use the above data to update the reliability of each cause candidate, additional question priority, and improvement action recommendation weight when similar VoC related to night standby or call bell occurs.

[0335] Accordingly, according to the present embodiment, even when somewhat ambiguous VoC such as "waited at night" is entered, the Fix Platform Server (300) can specify the actual cause of discomfort, such as pain, assistance with movement, guidance on daily life, delay in call bell response, or lack of response in the night ward, through additional questions. Accordingly, immediate guidance and emotional care can be provided to the patient or guardian, and specific actions to improve the night response system can be provided to the hospital administrator.

[0336] Example 8: Inference of Cause Candidates and Provision of Dynamic Follow-up Questions Based on Medical VoC Data

[0337] This embodiment relates to a case in which a cause candidate is inferred based on medical VoC data that is not directly linked to a low-point response in a patient experience evaluation, and a dynamic additional question is provided when the actual cause among multiple cause candidates is unclear.

[0338] For example, a patient or guardian can input details such as "I kept waiting because no one explained anything after the test" through ward inquiries, medical institution consultations, or free-form VoC.

[0339] The Fix platform server (300) can analyze the medical VoC data to extract event information related to the medical service stage after the examination, non-provision of explanation, waiting, medical staff contact, and discomfort.

[0340] Additionally, the Fix platform server (300) can map the extracted event information to a patient experience ontology to generate multiple cause candidates, such as delay in test result delivery, omission of test result explanation, omission of ward handover, or lack of contact with the medical staff in charge.

[0341] If the actual cause among multiple cause candidates is unclear, the fix platform server (300) can generate or search for additional question candidates that can distinguish each cause candidate, and select an additional question that reduces uncertainty of the cause candidate and provide it to the patient terminal (100) or guardian terminal (105).

[0342] For example, additional questions may be provided, such as "Did you not receive an explanation even after being notified that the test results were in?" or "Did you inquire about the test results with the attending medical staff after moving to the ward following the test?"

[0343] The Fix Platform Server (300) can update the reliability distribution for each cause candidate by reflecting the response to the additional question, and finally determine the surface cause directly experienced by the patient and the root cause related to hospital operations.

[0344] For example, the superficial cause may be determined as "failure to provide an explanation of test results," and the root cause as "inadequate procedures for delivering test results and ward handover." Accordingly, the patient may be provided with information regarding the procedure for explaining test results or verifying the responsible department, while hospital administrators may be provided with improvement actions related to reviewing test result delivery procedures and the handover process.

[0345] Accordingly, according to the present embodiment, the cause inference and dynamic additional question provision technology of the present invention can be applied not only when a low-score response occurs in a patient experience evaluation, but also when the medical VoC data generated during the process of using medical services contains problems or inconveniences with unclear causes.

[0346] It should be understood that the description of the invention provided above is merely illustrative for the purpose of understanding the invention and is not intended to define the scope of protection of the invention. The scope of protection of the invention is defined by the appended claims, and within this scope, simple variations or modifications of the invention shall be interpreted as falling within the scope of rights of the invention. Explanation of the symbols

[0347] 100: Patient terminal 105: Guardian terminal 200: Network 300: Fix Platform Server 301: Communication Interface Unit 302: Authentication and Authorization Management Unit 303: Input Collection Unit 304: Information Verification Provision Unit 305: AI Inquiry Processing Department 306: Document & Insurance Processing Department 307: Guardian Management Unit 308: Low Point Detection Unit 309: VoC Event Extraction Unit 310: Pain and Mood Analysis Unit 311: Ontology Mapping Unit 312: Cause Candidate Inference Unit 313: Dynamic follow-up question selection section 314: Action guide generation section 315: Statistical Analysis Department 316: Treatment Calendar Management Department 317: OCR / Document Conversion Unit 318: Feedback Learning Unit 400: Database Department 410: Survey DB 420: VoC DB 430: Guide Content DB 440: Rounds, Diet, and Treatment Calendar DB 450: Document and Insurance Linkage DB 460: Pain / Mood DB 470: Guardian Authority DB 500: Ontology Storage Unit 600: AI Processing Unit 700: Hospital Dashboard Terminal 800: Hospital System Integration Unit 900: Notification Integration Unit 950: Insurance Company Integration Unit

Claims

Claim 1 A platform server that receives patient experience evaluation survey responses and Voice of Customer (VoC) data from a patient terminal or a guardian terminal; a database unit that stores the patient experience evaluation survey responses and the VoC data; and an ontology storage unit that stores a patient experience ontology including relationships between evaluation areas, evaluation items, patient journey, events, problem types, surface causes, root causes, working entities, follow-up questions, and improvement actions of the patient experience evaluation. The system includes an AI processing unit that analyzes the above VoC data to extract event information regarding at least one of time zone, location, contact point, behavior, problem type, emotion, ward, medical department, and medical service stage. The platform server detects at least one of the following as a low-point response among the patient experience evaluation survey responses: a response below a threshold score, a response lower than the hospital average, a response lower than the ward average, a response lower than the medical department average, or a response lower than the previous evaluation result. The system maps the low-point response and the event information to nodes regarding evaluation items, events, problem types, surface causes, and root causes of the patient experience ontology to generate a cause candidate graph in which a plurality of cause candidates are connected to the low-point response and a probability or confidence value is assigned to each cause candidate. The system calculates a confidence distribution for each cause candidate based on the probability or confidence value assigned to the plurality of cause candidates, calculates the entropy of the confidence distribution as the uncertainty for the plurality of cause candidates, and for each of the plurality of additional question candidates, calculates the expected entropy before providing the corresponding additional question candidate and the possible response to the corresponding additional question candidate. Calculate the degree of reduction between entropies as the expected information gain, and select additional questions based on the expected information gain from among additional question candidates excluding questions that directly identify specific medical staff or employees, questions that request sensitive information, and questions that repeat information already included in the said VoC data, and provide them to the said patient terminal or the said guardian terminal.A system for inferring the cause of a low-point response in a patient experience evaluation and providing dynamic additional questions, characterized by receiving a response to the additional question above, recalculating the probability or confidence value of the cause candidate related to the received response to update the confidence distribution for each cause candidate, determining the final cause of the low-point response based on the updated confidence distribution, classifying the final cause into a surface cause, which is an inconvenience or condition directly experienced by the patient, and a root cause, which is a hospital operational cause that caused the said inconvenience or condition, generating guidance information for the patient based on the surface cause and providing it to the patient terminal or the guardian terminal, and generating an improvement action for the hospital administrator, including at least one of a responsible department, action priority, and action deadline, based on the root cause and the business entity connected to the root cause, and providing it to the hospital dashboard terminal. Claim 2 delete Claim 3 delete Claim 4 A system for inferring the cause of a low response in a patient experience evaluation and providing dynamic additional questions, wherein, in claim 1, the platform server calculates an expected information gain EIG(q), a patient fatigue index Fatigue(q), a sensitivity information request possibility index Sensitivity(q), and a redundancy index with the VoC data Redundancy(q) for each of the plurality of additional question candidates, and calculates a question selection score Score(q) for any additional question candidate q according to the following formula: Score(q) = EIG(q) - α·Fatigue(q) - β·Sensitivity(q) - γ·Redundancy(q), where α, β, and γ are weights for patient fatigue, sensitivity information request possibility, and redundancy, respectively, and selects the additional question candidate with the highest question selection score Score(q) among additional question candidates excluding questions that require direct designation of specific medical staff or employees, questions that request sensitive information, and questions that repeat information already included in the VoC data. Claim 5 A system for inferring causes of low-score responses in a patient experience evaluation and providing dynamic additional questions, characterized in that, in claim 1, the platform server calculates a patient fatigue index during the additional questioning process, and terminates the additional questioning process and determines the final cause when the reliability of the first-ranked cause candidate becomes greater than or equal to a reference value, the entropy of the reliability distribution for each cause candidate becomes less than or equal to a reference value, the number of additional questions reaches a reference number, or the patient fatigue index becomes greater than or equal to a reference value. Claim 6 A system for inferring causes of low-score responses in a patient experience evaluation and providing dynamic additional questions, wherein, in claim 1, the platform server receives at least one emotional state value among anxiety, depression, discomfort, normal, or stable input through emojis, scales, or selection items from the patient terminal or the guardian terminal, or extracts emotional information through natural language processing or sentiment analysis of free-form or voice VoC data, maps at least one of the emotional state value and the emotional information together with the event information to the patient experience ontology, and corrects the reliability distribution for each cause candidate by recalculating the probability or reliability value of the cause candidate related to the emotional state value or the emotional information by reflecting the mapping result in the cause candidate graph, wherein the emotional state value or the emotional information is not a value that determines the final cause alone, but is used as an auxiliary context for correcting the reliability distribution for each cause candidate related to insufficient explanation, waiting delay, inadequate pain response, lack of emotional support, or response attitude issues. Claim 7 A system for inferring causes of low patient experience evaluation responses and providing dynamic additional questions, wherein, in claim 1, the platform server updates weights for cause candidates, additional questions, or improvement actions using at least one of patient experience evaluation responses, VoC data, additional question responses, and administrator action results. Claim 8 A system for inferring the cause of a low score response in a patient experience evaluation and providing dynamic additional questions, characterized in that, in claim 1, the platform server registers a guardian corresponding to the patient and receives a response to the additional question or provides guidance information for the patient through the guardian terminal according to the authority of the guardian. Claim 9 A system for inferring the cause of a low patient experience evaluation response and providing dynamic additional questions, characterized in that, in claim 1, the patient guidance information includes at least one of hospitalization life guidance, ward round information, treatment schedule, guidance on applying for certificates, insurance-related guidance, and AI inquiry response. Claim 10 A method for inferring the cause of a low-scoring response in a patient experience evaluation and providing dynamic follow-up questions, comprising: receiving patient experience evaluation survey responses and Voice of Customer (VoC) data from a patient terminal or a guardian terminal; detecting at least one of the following as a low-scoring response among the patient experience evaluation survey responses: a response below a reference score, a response lower than the hospital average, a response lower than the ward average, a response lower than the medical department average, or a response lower than the previous evaluation result; extracting event information regarding at least one of time zone, place, touchpoint, behavior, problem type, emotion, ward, medical department, and medical service stage from the VoC data; mapping the low-scoring response and the event information to nodes regarding evaluation items, events, problem types, surface causes, and root causes of a patient experience ontology including the relationship between the evaluation area, evaluation items, patient journey, events, problem types, surface causes, root causes, working entities, follow-up questions, and improvement actions of the patient experience evaluation, thereby generating a cause candidate graph in which a plurality of cause candidates are connected to the low-scoring response and a probability or confidence value is assigned to each cause candidate; and the probability assigned to the plurality of cause candidates Alternatively, a step of calculating a reliability distribution for each cause candidate based on a reliability value, and calculating the entropy of the reliability distribution as the uncertainty for the plurality of cause candidates; for each of the plurality of additional question candidates, a step of calculating the expected information gain as the degree of reduction between the entropy before providing the additional question candidate and the expected entropy after reflecting possible responses to the additional question candidate, and a step of selecting an additional question based on the expected information gain from among the additional question candidates excluding questions that cause a specific medical staff or employee to be directly identified, questions that request sensitive information, and questions that repeatedly ask for information already included in the VoC data, and providing the additional question to the patient terminal or the guardian terminal;A method for inferring the cause of a low-point response in a patient experience evaluation and providing dynamic additional questions, characterized by comprising: a step of receiving a response to the additional question above and recalculating the probability or reliability value of the cause candidate related to the received response to update the reliability distribution for each cause candidate; a step of determining the final cause of the low-point response based on the updated reliability distribution and classifying the final cause into a surface cause, which is an inconvenience or condition directly experienced by the patient, and a root cause, which is a hospital operational cause that caused the said inconvenience or condition; and a step of generating guidance information for the patient based on the surface cause and providing it to the patient terminal or the guardian terminal, and generating an improvement action for the hospital administrator based on the root cause and the business entity connected to the root cause, including at least one of a responsible department, an action priority, and an action deadline, and providing it to the hospital dashboard terminal.

Images