An ophthalmic outpatient intelligent guide and appointment system based on a blockchain

Abstract

This invention discloses a blockchain-based intelligent triage and appointment system for ophthalmology clinics, relating to the field of outpatient triage technology. The system generates target event data based on patient complaint data, risk inquiry data, and consultation context data, forming triage voucher data. This data is then used to jointly arrange examination appointment data and patient reception appointment data, achieving closed-loop appointment scheduling between pre-examination nodes and patient reception nodes in ophthalmology clinics. By writing triage voucher data, appointment scheduling data, and node execution data into the blockchain, path release control and full-process traceability can be achieved. When node result data is abnormal, path change data can be automatically generated and subsequent appointments rearranged, thereby reducing misbooking, missed examinations, duplicate queuing, and invalid registration, and improving the accuracy and resource utilization efficiency of ophthalmology clinic triage.

Description

Technical Field

[0001] This invention relates to the field of outpatient triage technology, and in particular to a blockchain-based intelligent triage and appointment system for ophthalmology outpatient clinics. Background Technology

[0002] With the continuous increase in the number of patients visiting ophthalmology clinics in large general hospitals and specialized hospitals, there is often a significant discrepancy between patients' understanding of their eye symptoms before seeking medical attention and the actual treatment pathways in hospitals. This is especially true in scenarios such as glaucoma screening, fundus acute change screening, pediatric refractive assessment, and postoperative follow-up. Patients typically make appointments based solely on subjective feelings such as blurred vision, eye pain, floaters, flashes of light, photophobia, and tearing. However, the actual treatment process for different complaints is often not a single clinic allocation relationship, but rather a continuous treatment chain including pre-examination nodes, reception nodes, nodes that cannot be skipped, and time window constraints. Most existing ophthalmology clinic systems still primarily rely on departmental triage, general registration, or single-node examination appointments. The typical approach is to first generate an appointment record based on the patient's selection, and then manually determine in subsequent stages whether additional examinations are needed, whether to change to a specialized clinic, or whether to reschedule. This approach is ill-suited to the specific operational characteristics of ophthalmology clinics, where examinations and receptions are closely coupled, abnormal results trigger frequent path switching, and examinations such as mydriasis and imaging have effective time constraints.

[0003] In existing technologies, the triage process typically only provides suggestive triage results, lacking a unified constraint carrier that can run through the entire process of examination appointment, outpatient reception, and abnormal rerouting. This leads to situations where patients, even after completing triage, may still experience repeated queuing, repeated rebooking, and resource conflicts due to missing pre-examination nodes, mismatched appointment time windows, or abnormal results. Especially during peak outpatient hours, if the ordinary registration system only allocates appointments based on availability without verifying whether patients have met the pre-examination constraints for the corresponding path, it is easy for patients to occupy reception resources but be unable to enter the effective reception process, thereby further reducing the available resource slots for other patients. At the same time, although existing medical information systems can record some examination results and appointment results, these records are mostly static archived information, lacking a data organization method for path-oriented release control, making it difficult to support dynamic control requirements such as allowing entry to the next node only after pre-examination is completed, and automatically releasing invalid appointments and reordering subsequent paths after abnormal node results.

[0004] Furthermore, some key scenarios in ophthalmology clinics are highly specialized. For example, suspected glaucoma patients need to proceed to the appropriate consultation node after intraocular pressure testing and slit-lamp examination; suspected acute fundus problems require prompt access to image interpretation or specialized consultation nodes after cycloplegic refraction and fundus imaging; and pediatric refractive assessment patients need to complete initial visual function screening before being scheduled for refraction and corresponding consultation nodes. Current technologies generally lack a solution that can convert patient complaint data, risk inquiry data, and consultation context data into target event data, generate referral voucher data based on this target event data, and then use this referral voucher data to constrain the joint arrangement of examination resource status data and outpatient consultation status data. Therefore, it is difficult to achieve intelligent referral and appointment control for the actual treatment process in ophthalmology clinics at the system level. Summary of the Invention

[0005] The technical problem solved by this invention is that existing technologies are unable to form executable triage voucher data based on patient complaint data, risk inquiry data, and medical context data, and thereby realize closed-loop appointment of pre-examination nodes and reception nodes, on-chain state constraint release, and path rearrangement control triggered by abnormal results.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: A blockchain-based intelligent triage and appointment system for ophthalmology clinics includes a chief complaint event construction module, a path credential generation module, a resource closed-loop orchestration module, an on-chain state writing module, and an abnormal rerouting control module. The chief complaint event construction module is used to collect patient chief complaint data, risk inquiry data, and medical context data to generate target event data. The path voucher generation module is used to call preset path template data based on target event data to generate path constraint data and triage voucher data. The resource closed-loop orchestration module is used to collect examination resource status data and outpatient reception status data, and to jointly match the examination resource status data and outpatient reception status data according to path constraint data to generate appointment orchestration data. The on-chain state writing module is used to write the triage voucher data and appointment scheduling data into the blockchain to generate on-chain state data. The abnormal rerouting control module is used to collect node result data, compare the node result data with the on-chain status data, generate path change data, and release, rearrange or append the reservation scheduling data according to the path change data, and output reservation control result data.

[0007] Preferably, the chief complaint event construction module includes a chief complaint data acquisition unit, an inquiry data acquisition unit, and an event data generation unit; The chief complaint data acquisition unit is used to collect patient chief complaint data, which includes blurred vision description data, eye pain description data, floaters and flashes of light description data, photophobia and tearing description data, and follow-up visit explanation data. The inquiry data collection unit is used to collect risk inquiry data and medical treatment context data. The risk inquiry data includes emergency situation marking data, trauma situation marking data, diabetes history marking data, corneal contact lens wearing marking data, and pupil dilation marking data. The medical treatment context data includes arrival time data, number of people waiting for treatment data, and patient identity type data. The event data generation unit is used to perform rule mapping processing on patient complaint data, risk inquiry data, and medical context data to output target event data.

[0008] Preferably, the logic of the event data generation unit is as follows: extract event features from each chief complaint field in the patient's chief complaint data to obtain chief complaint feature data; Assign risk level values ​​to each query field in the risk query data to obtain query feature data; Input the chief complaint feature data, inquiry feature data, and medical visit context data into the event determination model, and output the target event data; The target event data includes glaucoma screening event data, fundus acute change screening event data, pediatric refractive assessment event data, general eye disease visit event data, and postoperative follow-up event data.

[0009] Preferably, the path voucher generation module includes a path template calling unit and a triage voucher generation unit; The path template calling unit is used to call preset path template data according to target event data. The preset path template data includes pre-examination node data, reception node data, prohibited skipping node data, and time window constraint data, and outputs path constraint data. The patient guidance certificate generation unit is used to combine and encapsulate target event data and path constraint data to generate patient guidance certificate data. The patient guidance certificate data includes event type identification data, pre-examination constraint data, patient reception order constraint data, and time window constraint data.

[0010] Preferably, the logic of the triage certificate generation unit is as follows: if the target event data is glaucoma screening event data, then the preset path template data containing intraocular pressure examination node data and slit lamp examination node data is called to generate glaucoma path constraint data; If the target event data is fundus acute change screening event data, then the preset path template data containing mydriatic examination node data and fundus imaging node data is called to generate fundus path constraint data; If the target event data is children's refractive assessment event data, then the preset path template data containing visual function screening node data and refraction examination node data is called to generate refractive path constraint data; Combine glaucoma path constraint data, fundus path constraint data, or refractive path constraint data with target event data to output triage voucher data.

[0011] Preferably, the resource closed-loop orchestration module includes a resource status acquisition unit and a joint orchestration unit; The resource status acquisition unit is used to collect examination resource status data and outpatient reception status data. The examination resource status data includes examination equipment identification data, examination start time data, examination end time data, and number of available examination slots. The outpatient reception status data includes outpatient identification data, reception start time data, reception end time data, and number of available reception slots. The joint orchestration unit is used to perform sequential matching and time window matching on the examination resource status data and outpatient reception status data according to the path constraint data, and output appointment orchestration data, which includes examination appointment data, reception appointment data and path closed loop marking data.

[0012] Preferably, the logic of the joint orchestration unit is as follows: first, based on the preceding inspection node data in the path constraint data, the inspection appointment data that meets the requirements of inspection start time data and inspection end time data is filtered from the inspection resource status data; Then, based on the patient reception node data in the path constraint data, filter the patient reception appointment data corresponding to the examination appointment data from the outpatient reception status data; If the time interval between the inspection appointment data and the patient reception appointment data is within the time window constraint data, then path closed loop marker data is generated; If the time interval between the inspection appointment data and the outpatient appointment data exceeds the time window constraint data, the inspection resource status data and outpatient appointment status data will be called again for rearrangement processing until the output appointment orchestration data containing path closure mark data is output.

[0013] Preferably, the on-chain state writing module includes a credential on-chain unit and a node state appending unit; The certificate on-chain unit is used to write the triage certificate data and appointment scheduling data into the blockchain to generate initial on-chain state data. The node state appending unit is used to collect node execution data generated during the execution of each node, and append the node execution data to the initial on-chain state data to generate on-chain state data. The node execution data includes check-in data, check-complete data, patient check-in data, patient completion data, and path release data.

[0014] Preferably, the logic of the node status appending unit is as follows: when the check-in data is consistent with the pre-check constraint data in the triage voucher data, the check-in data is written. When the completed inspection data meets the pre-inspection constraints, write the path release data. When the patient check-in data matches the patient appointment data in the appointment scheduling data, write the patient check-in data. If the preceding path data corresponding to the patient check-in data has not been written, then path blocking data will be generated and appended to the on-chain state data; The check-in data, check-completion data, path release data, patient check-in data, and path blocking data are all used as on-chain state data.

[0015] Preferably, the abnormal rerouting control module includes a node result acquisition unit and a path change control unit; The node result acquisition unit is used to acquire node result data, which includes intraocular pressure abnormality marker data, fundus abnormality marker data, visual function abnormality marker data, and mydriasis completion marker data. The path change control unit is used to compare the node result data with the chain status data. If the node result data meets the preset rerouting conditions, path change data is generated, and the failed inspection appointment data or failed patient appointment data in the original appointment scheduling data is released according to the path change data. At the same time, new inspection appointment data or new patient appointment data is added, and appointment control result data is output. If the node result data does not meet the preset rerouting conditions, the original reservation arrangement data will remain unchanged, and the reservation control result data will be output.

[0016] The beneficial effects of this invention are as follows: This invention generates target event data based on patient complaint data, risk inquiry data, and medical context data, and forms triage voucher data. This data is then used to jointly arrange examination appointment data and patient reception appointment data, realizing a closed-loop appointment system between pre-examination nodes and patient reception nodes in ophthalmology clinics. By writing triage voucher data, appointment arrangement data, and node execution data into the blockchain, path release control and full-process traceability can be achieved. When node result data is abnormal, path change data can be automatically generated and subsequent appointments can be rearranged, thereby reducing misbooking, missed examinations, duplicate queuing, and invalid registration, and improving the accuracy of triage and resource utilization efficiency in ophthalmology clinics. Attached Figure Description

[0017] Figure 1 This is a system composition diagram of a blockchain-based intelligent triage and appointment system for ophthalmology clinics, provided as an embodiment of the present invention. Detailed Implementation

[0018] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0019] Example, refer to Figure 1 This paper presents a blockchain-based intelligent triage and appointment system for ophthalmology clinics, including a chief complaint event construction module, a path credential generation module, a resource closed-loop orchestration module, an on-chain state writing module, and an abnormal rerouting control module. The chief complaint event construction module is used to collect patient chief complaint data, risk inquiry data, and medical context data to generate target event data.

[0020] The route voucher generation module is used to call preset route template data based on target event data to generate route constraint data and triage voucher data.

[0021] The resource closed-loop orchestration module is used to collect examination resource status data and outpatient reception status data, and to perform joint matching of examination resource status data and outpatient reception status data based on path constraint data to generate appointment orchestration data.

[0022] The on-chain state writing module is used to write triage voucher data and appointment scheduling data into the blockchain to generate on-chain state data.

[0023] The abnormal rerouting control module is used to collect node result data, compare the node result data with the on-chain status data, generate path change data, and release, rearrange or append the reservation orchestration data according to the path change data, and output reservation control result data.

[0024] This embodiment is deployed between the hospital's ophthalmology outpatient triage terminal, nurse pre-screening terminal, examination equipment access terminal, doctor reception terminal, and blockchain node server. After a patient arrives at the hospital, it generates target event data based on the patient's chief complaint data, risk inquiry data, and treatment context data. Then, it generates triage voucher data based on the target event data. Based on the triage voucher data, it performs closed-loop orchestration of examination resource status data and outpatient reception status data to form appointment orchestration data. Subsequently, the triage voucher data, appointment orchestration data, and node execution data generated during the treatment process are continuously written to the blockchain to form on-chain state data. When the node result data returned by the examination node meets the preset rerouting conditions, the system generates path change data based on the on-chain state data, releases, rearranges, or appends the appointment orchestration data, and finally outputs appointment control result data.

[0025] The chief complaint event construction module includes a chief complaint data collection unit, an inquiry data collection unit, and an event data generation unit.

[0026] The chief complaint data collection unit is used to collect patient chief complaint data, which includes descriptions of blurred vision, eye pain, floaters and flashes of light, photophobia and tearing, and follow-up visit information.

[0027] After entering the ophthalmology clinic, patients first have their chief complaint data entered through a triage terminal. This data includes descriptions of blurred vision, eye pain, floaters / flashes, photophobia / tearing, and follow-up visit instructions. This patient complaint data is not simply saved as natural language text; instead, the data collection unit breaks it down and standardizes it according to a pre-defined field structure. For example, the blurred vision description data further records whether it occurs in one or both eyes, its duration, and whether it is sudden; the eye pain description data further records stinging, throbbing, persistent, or intermittent pain; the floaters / flashes description data further records whether it is accompanied by visual field obstruction; the photophobia / tearing description data further records whether it is accompanied by increased discharge; and the follow-up visit instructions further records the department visited and the previous examination results. After this breakdown, structured patient complaint data is obtained, allowing subsequent event determination to no longer rely on doctors manually reading the entire description, but instead to directly process the standardized fields.

[0028] The inquiry data collection unit is used to collect risk inquiry data and medical visit context data. Risk inquiry data includes data marking sudden situations, trauma, diabetes history, contact lens wearing, and dilated pupils. Medical visit context data includes arrival time, number of people waiting, and patient identity type.

[0029] While collecting patient complaint data, the inquiry data collection unit also collects risk inquiry data and visit context data. Risk inquiry data includes data marking sudden events, injuries, diabetes history, contact lens wear, and dilated pupils. Visit context data includes arrival time, number of people waiting, and patient identity type. In this embodiment, risk inquiry data is not used to generate a separate risk score, but rather participates in the generation of target event data along with patient complaint data; visit context data is not merely used for statistics, but directly participates in subsequent resource closed-loop orchestration.

[0030] The event data generation unit is used to perform rule mapping processing on patient complaint data, risk inquiry data, and medical context data to output target event data.

[0031] The logic of the event data generation unit is as follows: extract event features from each chief complaint field in the patient's chief complaint data to obtain chief complaint feature data.

[0032] Assign risk level values ​​to each query field in the risk query data to obtain query feature data.

[0033] Input the chief complaint feature data, inquiry feature data, and medical visit context data into the event determination model, and output the target event data.

[0034] The target event data includes glaucoma screening event data, fundus acute change screening event data, pediatric refractive assessment event data, general eye disease visit event data, and postoperative follow-up event data.

[0035] After receiving patient complaint data, risk inquiry data, and consultation context data, the event data generation unit performs rule mapping processing to generate target event data. Specifically, the system pre-establishes an ophthalmology outpatient event mapping table. This event mapping table is not categorized by department, but by treatment pathway. In other words, the system does not first determine which outpatient department the patient belongs to and then decide whether an examination is needed. Instead, it first determines which type of ophthalmology consultation event the patient is most likely to be involved in, and then retrieves the corresponding pre-examination node data and reception node data based on that ophthalmology consultation event. This ophthalmology consultation event includes at least glaucoma screening event data, fundus acute change screening event data, pediatric refractive assessment event data, general eye disease consultation event data, and postoperative follow-up event data. If the patient's complaint data includes descriptions of significant eye pain and sudden onset, along with fields such as nausea and blurred vision, the system categorizes the patient into glaucoma screening event data. If the patient's complaint data includes descriptions of floaters and flashes of light, visual field obstruction, and the risk inquiry data indicates a history of diabetes, the system categorizes the patient into fundus acute exacerbation screening event data. If the patient's complaint data includes descriptions of squinting, blurred distance vision, or learning fatigue, and the patient's identity type is child, the system categorizes the patient into pediatric refractive assessment event data. If the system cannot clearly categorize the patient's complaint data and risk inquiry data into any of the above high-priority paths, it categorizes them into general eye disease visit event data. The event data generation unit then outputs the target event data.

[0036] The path voucher generation module includes a path template calling unit and a triage voucher generation unit.

[0037] The path template calling unit is used to call preset path template data based on target event data. The preset path template data includes pre-check node data, reception node data, prohibited skip node data, and time window constraint data, and outputs path constraint data.

[0038] The path template calling unit pre-establishes preset path template data in the system. This preset path template data is not a regular triage rule table, but a set of path templates linked to ophthalmology clinic resources. Each set of preset path template data includes at least the following: pre-examination node data, patient reception node data, prohibited skipping node data, and time window constraint data.

[0039] Taking the aforementioned glaucoma screening event data as an example, the corresponding preset path template data includes pre-examination node data such as intraocular pressure examination node data and slit lamp examination node data, and the reception node data is the glaucoma clinic reception node data. The prohibition to skip node data means that patients cannot directly enter the glaucoma clinic reception node data without completing the intraocular pressure examination node data. The time window constraint data indicates the allowable time range between the completion of the slit lamp examination and the start of the reception.

[0040] For fundus acute refractive error screening event data, the corresponding preset path template data includes pre-examination node data (mydriatic examination and fundus imaging) and consultation node data (fundus disease outpatient consultation). The "no skipping" node data indicates that patients cannot directly access the fundus disease outpatient consultation node data without completing the mydriatic examination and fundus imaging node data. For pediatric refractive assessment event data, the corresponding preset path template data includes pre-examination node data (initial visual function screening and refraction examination) and consultation node data (refraction clinic consultation). The "no skipping" node data indicates that patients cannot directly access the refraction examination or refraction clinic consultation node data without completing the initial visual function screening node data.

[0041] The patient guidance certificate generation unit is used to combine and encapsulate target event data and path constraint data to generate patient guidance certificate data. The patient guidance certificate data includes event type identification data, pre-examination constraint data, patient reception order constraint data, and time window constraint data.

[0042] The logic of the triage voucher generation unit is as follows: if the target event data is glaucoma screening event data, then the preset path template data containing intraocular pressure examination node data and slit lamp examination node data is called to generate glaucoma path constraint data.

[0043] If the target event data is fundus acute change screening event data, then the preset path template data containing cycloplegic examination node data and fundus imaging node data is called to generate fundus path constraint data.

[0044] If the target event data is children's refractive assessment event data, then the preset path template data containing visual function screening node data and refraction examination node data is called to generate refractive path constraint data.

[0045] Combine glaucoma path constraint data, fundus path constraint data, or refractive path constraint data with target event data to output triage voucher data.

[0046] The path template invocation unit invokes the corresponding preset path template data based on the target event data and outputs path constraint data. Subsequently, the triage voucher generation unit encapsulates the target event data and path constraint data into triage voucher data. The triage voucher data includes at least event type identifier data, pre-examination constraint data, reception order constraint data, and time window constraint data. Further, in this embodiment, the triage voucher data also includes patient identification data and triage voucher generation time data. Once generated, the triage voucher data is not only used for display on the triage interface, but also serves as the unified basis for subsequent appointment scheduling, on-chain writing, and path release control.

[0047] The resource closed-loop orchestration module includes a resource status acquisition unit and a joint orchestration unit; The resource status acquisition unit is used to collect examination resource status data and outpatient reception status data. The examination resource status data includes examination equipment identification data, examination start time data, examination end time data, and number of available examination slots. The outpatient reception status data includes outpatient identification data, reception start time data, reception end time data, and number of available reception slots.

[0048] The resource status acquisition unit collects examination resource status data and outpatient reception status data respectively. Examination resource status data includes examination equipment identification data, examination start time data, examination end time data, and the number of available examination slots. Outpatient reception status data includes outpatient identification data, reception start time data, reception end time data, and the number of available outpatient slots. Unlike existing registration systems, this embodiment does not first search for available appointment slots among all outpatient appointment resources, nor does it first search for vacancies among all examination equipment. Instead, the joint scheduling unit integrates the examination resource status data and outpatient reception status data according to the preceding examination node data and reception node data in the path constraint data, following the treatment sequence.

[0049] The joint orchestration unit is used to perform sequential matching and time window matching on examination resource status data and outpatient reception status data based on path constraint data, and output appointment orchestration data, which includes examination appointment data, reception appointment data and path closed loop marking data.

[0050] The logic of the joint orchestration unit is as follows: First, based on the preceding inspection node data in the path constraint data, the inspection appointment data that meets the requirements of inspection start time data and inspection end time data is filtered from the inspection resource status data.

[0051] Then, based on the patient reception node data in the path constraint data, filter the patient reception appointment data corresponding to the examination appointment data from the outpatient reception status data.

[0052] If the time interval between the check appointment data and the patient reception appointment data is within the time window constraint data, then path closure mark data is generated.

[0053] If the time interval between the inspection appointment data and the outpatient appointment data exceeds the time window constraint data, the inspection resource status data and outpatient appointment status data will be called again for rearrangement processing until the output appointment orchestration data containing path closure mark data is output.

[0054] The joint orchestration unit first searches for examination appointment data that meets the sequence requirements from the examination resource status data based on the preceding examination node data. If a target event corresponds to two preceding examination node data, the system needs to consider both the order between the two examination nodes and their connection with subsequent reception nodes, rather than providing two separate appointments.

[0055] Subsequently, the joint orchestration unit searches for appointment data from the outpatient appointment status data that can effectively connect with the aforementioned examination appointment data, based on the appointment node data. During this process, the system focuses on verifying time window constraint data. Time window constraint data indicates the time frame within which a patient should enter the appointment node after the preliminary examination is completed. Examples include the effective appointment window after cycloplegic refraction, the effective image interpretation window after fundus imaging, and the initial glaucoma diagnosis connection window after intraocular pressure testing.

[0056] If the time interval between candidate examination appointment data and candidate patient appointment data falls within the time window constraint data, the joint scheduling unit will confirm the group of examination appointment data and patient appointment data as appointment scheduling data and generate path closed-loop marker data.

[0057] If the time interval exceeds the time window constraint data, it is considered that the group of examination appointment data and outpatient appointment data cannot form an effective closed loop. The system will continue to rearrange and search in the examination resource status data and outpatient appointment status data until appointment scheduling data that meets the path closed loop marking data is generated.

[0058] Therefore, the appointment scheduling data output in this embodiment is not a single registration result, but a combination of examination appointment data, patient reception appointment data, and path closed-loop marking data. The on-chain state writing module includes a credential uploading unit and a node state appending unit; The on-chain voucher unit is used to write triage voucher data and appointment scheduling data into the blockchain to generate initial on-chain state data.

[0059] The credential on-chain unit first writes the triage credential data and appointment scheduling data into the blockchain, generating initial on-chain state data. In this embodiment, the blockchain node server can adopt an internal hospital consortium blockchain structure, with nodes deployed at the triage terminal, examination equipment access terminal, outpatient reception terminal, and hospital information center, to ensure that the triage credential data and appointment scheduling data are consistent and verifiable across multiple business terminals. After the triage credential data and appointment scheduling data are written into the blockchain, all subsequent node execution data must be appended based on the triage credential data, and cannot form a state fragment independently of the triage credential data.

[0060] The node state appending unit is used to collect the node execution data generated during the execution of each node, and append the node execution data to the initial on-chain state data to generate on-chain state data. The node execution data includes check-in data, check-complete data, patient check-in data, patient completion data, and path release data.

[0061] The logic of the node status appending unit is as follows: when the check-in data is consistent with the pre-check constraint data in the triage voucher data, the check-in data is written.

[0062] Once the completed inspection data meets the pre-inspection constraints, write the path release data.

[0063] When the patient check-in data matches the patient appointment data in the appointment scheduling data, the patient check-in data is written.

[0064] If the preceding path data corresponding to the patient check-in data has not been written, path blocking data will be generated and appended to the on-chain state data.

[0065] The check-in data, check-completion data, path release data, patient check-in data, and path blocking data are all used as on-chain state data.

[0066] The node status appending unit continuously collects node execution data as patients complete processes such as examination check-in, examination completion, patient check-in, and patient completion. Node execution data includes examination check-in data, examination completion data, patient check-in data, patient completion data, and pathway release data. The node status appending unit first determines whether the examination check-in data is consistent with the pre-examination constraint data in the patient guidance voucher data.

[0067] If they match, the check-in data can be written; if they don't match, the system records the abnormal node access and refuses to allow subsequent paths. Subsequently, the node status appending unit continues to determine whether the check completion data has covered all the preceding check constraint data in the triage voucher data.

[0068] If the data has already been covered, path release data is generated and appended to the on-chain state data. The purpose of path release data is to indicate that the patient has met the data prerequisites for the next reception node. Subsequent reception terminals are only allowed to write reception check-in data after reading the path release data.

[0069] If the patient reception terminal finds that although the patient check-in data matches the appointment data in the appointment scheduling data, but the corresponding path release data does not yet exist in the on-chain status data, the node status appending unit will generate path blocking data and write it into the on-chain status data. This prevents patients from directly occupying outpatient reception resources without completing the pre-examination nodes. In this way, the on-chain status data not only serves as evidence but also controls path release.

[0070] The abnormal rerouting control module includes a node result acquisition unit and a path change control unit.

[0071] The node result acquisition unit is used to acquire node result data, which includes intraocular pressure abnormality marker data, fundus abnormality marker data, visual function abnormality marker data, and mydriasis completion marker data.

[0072] The path change control unit is used to compare the node result data with the chain status data. If the node result data meets the preset rerouting conditions, path change data is generated, and the failed inspection appointment data or failed patient appointment data in the original appointment scheduling data is released according to the path change data. At the same time, new inspection appointment data or new patient appointment data is added, and appointment control result data is output.

[0073] If the node result data does not meet the preset rerouting conditions, the original reservation arrangement data will remain unchanged, and the reservation control result data will be output.

[0074] The node result acquisition unit collects node result data after the node inspection is completed. The node result data includes intraocular pressure abnormality marker data, fundus abnormality marker data, visual function abnormality marker data, and mydriasis completion marker data. In this embodiment, the intraocular pressure abnormality marker data is generated by the intraocular pressure examination node, the fundus abnormality marker data is generated by the fundus imaging node or the doctor's image review node, the visual function abnormality marker data is generated by the visual function preliminary screening node, and the mydriasis completion marker data is generated by the mydriasis examination node.

[0075] After reading the node result data, the path change control unit does not directly modify the original appointment scheduling data. Instead, it first compares the node result data with the on-chain status data to confirm the current path stage of the patient, the completed pre-examination node data, and the unexecuted reception node data. If the node result data meets the preset rerouting conditions, the system generates path change data. These preset rerouting conditions are not simply referrals due to abnormalities, but rather path change rules set for different target event data. For example, when the patient's original target event data is a general eye disease visit, but the intraocular pressure abnormality marker data in the node result data meets the preset conditions, the path change control unit generates new path change data, changing the original reception node data from a general eye disease clinic reception node data to a glaucoma clinic reception node data. When the patient's original target event data is a fundus acute exacerbation screening event, and the fundus abnormality marker data in the node result data meets the preset conditions, the path change control unit retains the completion status of the fundus imaging node in the original path, while changing the subsequent reception node data from a general fundus review node to a fundus-specific disease reception node. If the node result data does not meet the preset rerouting conditions, the system will keep the original scheduled data unchanged.

[0076] Once the route change data is generated, the system releases invalid examination or outpatient appointment data from the original appointment scheduling data based on the route change data. Simultaneously, it re-invokes the examination resource status data and outpatient appointment status data based on the updated preceding examination node data, outpatient node data, and time window constraint data to generate new examination or outpatient appointment data, and outputs the appointment control result data. Therefore, the rerouting in this embodiment is not a manual cancellation and re-registration, but a route rescheduling process based on on-chain status data. Because the system can identify completed examination node data, it does not repeatedly assign completed examination nodes to patients during rerouting, nor does it simply clear all appointments; instead, it only releases invalid resource slots that no longer match the current route change data.

[0077] The key to this embodiment lies in establishing a data processing chain specifically for ophthalmology outpatient clinics. This chain first maps patient complaint data, risk inquiry data, and consultation context data into target event data. Then, it calls preset path template data based on the target event data and generates triage voucher data. Subsequently, it performs closed-loop orchestration of examination resource status data and outpatient reception status data based on the triage voucher data. Next, it uses on-chain status data to implement path release control between preceding examination nodes and reception nodes. Finally, when node result data triggers a rerouting condition, it performs partial release and partial rearrangement of appointment scheduling data based on on-chain status data and path change data. Thus, the system does not solve the problem of whether there are available appointment slots in a typical appointment system, but rather addresses more specific technical issues in ophthalmology outpatient clinics, such as what examinations should be performed first, when to enter which outpatient department, which nodes cannot be skipped, and how to reroute without repeatedly occupying resources after an anomaly.

[0078] This invention provides a blockchain-based intelligent triage and appointment system for ophthalmology outpatient clinics. Taking patient complaint data, risk inquiry data, and consultation context data as input, the system generates target event data through a complaint event construction module. Then, a path credential generation module calls preset path template data based on the target event data to form triage credential data and path constraint data. This allows the system to identify the corresponding ophthalmology consultation event at the initial stage of a patient's entry into the outpatient clinic and pre-determine pre-examination nodes, reception nodes, no-skip nodes, and time window constraints. Compared to existing methods that allocate services solely based on department tags or available appointment slots, this invention elevates triage results from ordinary prompts to a unified control basis for subsequent appointments and releases, thereby enabling triage behavior to directly participate in outpatient process scheduling.

[0079] This invention utilizes a resource closed-loop orchestration module to jointly process examination resource status data and outpatient reception status data. Instead of treating examination appointments and outpatient appointments as two separate processes, it orchestrates examination appointment data, reception appointment data, and path closed-loop marker data into a continuous appointment orchestration dataset based on path constraint data. This ensures that after preliminary examinations such as intraocular pressure testing, mydriatic testing, fundus imaging, and initial visual function screening are completed, patients can enter the corresponding reception node within the effective time window. This reduces duplicate queuing, invalid results, manual insertion, and secondary rescheduling caused by a disconnect between examination completion time and reception start time. It is particularly suitable for scenarios with complex examination chains, such as glaucoma screening, fundus acute recurrence screening, and pediatric refractive assessment.

[0080] This invention continuously writes triage voucher data, appointment scheduling data, and node execution data to the blockchain through an on-chain state writing module, forming on-chain state data. This establishes a consistent and traceable data link between triage, examination, patient reception, and pathway release. Since patient reception and check-in must be based on the premise that the preceding pathway release data has been written to the on-chain state data, the system effectively prevents patients from directly occupying reception resources without completing the preceding examination nodes, thus improving the authenticity and effectiveness of outpatient resource utilization. Simultaneously, the introduction of blockchain ensures consistency in the reading of the same patient's pathway status across different terminals, reducing process conflicts caused by manual verbal confirmation and data asynchrony between different terminals.

[0081] This invention compares node result data with on-chain status data through an abnormal rerouting control module. When preset rerouting conditions are met, path change data is generated. Based on the path change data, invalid examination appointment data or invalid patient appointment data in the original appointment scheduling data are released. Then, new examination appointment data or new patient appointment data are generated based on the updated path constraint data. This allows for timely switching of patients from the original path to a more suitable patient path after node results such as abnormal intraocular pressure, fundus abnormalities, or visual function abnormalities occur. Only invalid resources are reordered, avoiding duplicate allocation of completed examination nodes, thereby reducing manual rerouting costs, minimizing duplicate examinations and invalid resource occupation, and improving overall outpatient workflow efficiency.

[0082] The system architecture and data flow method of this invention enable hospitals to build a more refined outpatient management mechanism based on target event data, appointment scheduling data, on-chain status data, and path change data. By continuously recording the execution status of paths corresponding to different target events, it is possible to further analyze which examination nodes are most prone to congestion, which time window constraints most affect closed-loop efficiency, and which abnormal detour scenarios are most likely to cause resource conflicts, thereby providing a basis for subsequent optimization of path template data. Therefore, this invention can not only improve the patient's triage experience and consultation efficiency, but also enhance the hospital's examination resource allocation capabilities, patient reception resource utilization capabilities, and process management level.

[0083] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0084] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the protection scope of the present invention.

Claims

1. A blockchain-based intelligent guidance and appointment system for ophthalmic outpatient clinics, characterized in that, It includes a main complaint event construction module, a path credential generation module, a resource closed-loop orchestration module, an on-chain state writing module, and an exception rerouting control module; The chief complaint event construction module is used to collect patient chief complaint data, risk inquiry data, and medical context data to generate target event data. The path voucher generation module is used to call preset path template data based on target event data to generate path constraint data and triage voucher data. The resource closed-loop orchestration module is used to collect examination resource status data and outpatient reception status data, and to jointly match the examination resource status data and outpatient reception status data according to path constraint data to generate appointment orchestration data. The on-chain state writing module is used to write the triage voucher data and appointment scheduling data into the blockchain to generate on-chain state data. The abnormal rerouting control module is used to collect node result data, compare the node result data with the on-chain status data, generate path change data, and release, rearrange or append the reservation scheduling data according to the path change data, and output reservation control result data.

2. The blockchain-based intelligent guidance and appointment system for ophthalmic outpatient service according to claim 1, wherein, The chief complaint event construction module includes a chief complaint data collection unit, an inquiry data collection unit, and an event data generation unit; The chief complaint data acquisition unit is used to collect patient chief complaint data, which includes blurred vision description data, eye pain description data, floaters and flashes of light description data, photophobia and tearing description data, and follow-up visit explanation data. The inquiry data collection unit is used to collect risk inquiry data and medical treatment context data. The risk inquiry data includes emergency situation marking data, trauma situation marking data, diabetes history marking data, corneal contact lens wearing marking data, and pupil dilation marking data. The medical treatment context data includes arrival time data, number of people waiting for treatment data, and patient identity type data. The event data generation unit is used to perform rule mapping processing on patient complaint data, risk inquiry data, and medical context data to output target event data.

3. The blockchain-based intelligent guiding and appointment system for ophthalmic outpatient service according to claim 2, wherein, The logic of the event data generation unit is as follows: extract event features from each chief complaint field in the patient's chief complaint data to obtain chief complaint feature data; Assign risk level values ​​to each query field in the risk query data to obtain query feature data; Input the chief complaint feature data, inquiry feature data, and medical visit context data into the event determination model, and output the target event data; The target event data includes glaucoma screening event data, fundus acute change screening event data, pediatric refractive assessment event data, general eye disease visit event data, and postoperative follow-up event data.

4. The intelligent triage and appointment system for ophthalmology clinics based on blockchain as described in claim 3, characterized in that, The path voucher generation module includes a path template calling unit and a triage voucher generation unit; The path template calling unit is used to call preset path template data according to target event data. The preset path template data includes pre-examination node data, reception node data, prohibited skipping node data, and time window constraint data, and outputs path constraint data. The patient guidance certificate generation unit is used to combine and encapsulate target event data and path constraint data to generate patient guidance certificate data. The patient guidance certificate data includes event type identification data, pre-examination constraint data, patient reception order constraint data, and time window constraint data.

5. The intelligent triage and appointment system for ophthalmology clinics based on blockchain as described in claim 4, characterized in that, The logic of the triage certificate generation unit is as follows: if the target event data is glaucoma screening event data, then the preset path template data containing intraocular pressure examination node data and slit lamp examination node data is called to generate glaucoma path constraint data. If the target event data is fundus acute change screening event data, then the preset path template data containing mydriatic examination node data and fundus imaging node data is called to generate fundus path constraint data; If the target event data is children's refractive assessment event data, then the preset path template data containing visual function screening node data and refraction examination node data is called to generate refractive path constraint data; Combine glaucoma path constraint data, fundus path constraint data, or refractive path constraint data with target event data to output triage voucher data.

6. The intelligent triage and appointment system for ophthalmology clinics based on blockchain as described in claim 5, characterized in that, The resource closed-loop orchestration module includes a resource status acquisition unit and a joint orchestration unit; The resource status acquisition unit is used to collect examination resource status data and outpatient reception status data. The examination resource status data includes examination equipment identification data, examination start time data, examination end time data, and number of available examination slots. The outpatient reception status data includes outpatient identification data, reception start time data, reception end time data, and number of available reception slots. The joint orchestration unit is used to perform sequential matching and time window matching on the examination resource status data and outpatient reception status data according to the path constraint data, and output appointment orchestration data, which includes examination appointment data, reception appointment data and path closed loop marking data.

7. The intelligent triage and appointment system for ophthalmology clinics based on blockchain as described in claim 6, characterized in that, The logic of the joint orchestration unit is as follows: First, based on the preceding inspection node data in the path constraint data, the inspection appointment data that meets the requirements of inspection start time data and inspection end time data is filtered from the inspection resource status data; Then, based on the patient reception node data in the path constraint data, filter the patient reception appointment data corresponding to the examination appointment data from the outpatient reception status data; If the time interval between the inspection appointment data and the patient reception appointment data is within the time window constraint data, then path closed loop marker data is generated; If the time interval between the inspection appointment data and the outpatient appointment data exceeds the time window constraint data, the inspection resource status data and outpatient appointment status data will be called again for rearrangement processing until the output appointment orchestration data containing path closure mark data is output.

8. The intelligent triage and appointment system for ophthalmology clinics based on blockchain as described in claim 7, characterized in that, The on-chain state writing module includes a credential on-chain unit and a node state appending unit; The certificate on-chain unit is used to write the triage certificate data and appointment scheduling data into the blockchain to generate initial on-chain state data. The node state appending unit is used to collect node execution data generated during the execution of each node, and append the node execution data to the initial on-chain state data to generate on-chain state data. The node execution data includes check-in data, check-complete data, patient check-in data, patient completion data, and path release data.

9. The intelligent triage and appointment system for ophthalmology clinics based on blockchain as described in claim 8, characterized in that, The logic of the node status appending unit is as follows: when the check-in data is consistent with the pre-check constraint data in the triage voucher data, the check-in data is written. When the completed inspection data meets the pre-inspection constraints, write the path release data. When the patient check-in data matches the patient appointment data in the appointment scheduling data, write the patient check-in data. If the preceding path data corresponding to the patient check-in data has not been written, then path blocking data will be generated and appended to the on-chain state data; The check-in data, check-completion data, path release data, patient check-in data, and path blocking data are all used as on-chain state data.

10. The intelligent triage and appointment system for ophthalmology clinics based on blockchain as described in claim 9, characterized in that, The abnormal rerouting control module includes a node result acquisition unit and a path change control unit; The node result acquisition unit is used to acquire node result data, which includes intraocular pressure abnormality marker data, fundus abnormality marker data, visual function abnormality marker data, and mydriasis completion marker data. The path change control unit is used to compare the node result data with the chain status data. If the node result data meets the preset rerouting conditions, path change data is generated, and the failed inspection appointment data or failed patient appointment data in the original appointment scheduling data is released according to the path change data. At the same time, new inspection appointment data or new patient appointment data is added, and appointment control result data is output. If the node result data does not meet the preset rerouting conditions, the original reservation arrangement data will remain unchanged, and the reservation control result data will be output.

Images