Internet-based hospital inquiry system and interaction method

Abstract

The invention discloses a hospital inquiry system based on the Internet. The hospital inquiry system comprises a business platform layer, a multi-terminal application layer, a composite interaction layer and a verification layer, the service platform layer is constructed by adopting a Java Springboot and SpringCloud micro service architecture, and a plurality of core functions can be packaged into an independent service process; the multi-end application layer can select an optimal technology stack to form a multi-end application based on operation habits and performance requirements of different terminal users, and each end performs front-end and back-end separated interaction with the service middle station through an API gateway; and the composite interaction layer is used for establishing a communication link between a doctor and a patient so as to carry out a full-service process of online inquiry, prescription making and medicine distribution. According to the system, a one-stop business process of online inquiry, prescription extraction, medicine purchasing and distribution is realized, meanwhile, doctors are supported to receive diagnosis through a mobile terminal or a computer anytime and anywhere, and the problem that the licensing behaviors of the doctors are bound to fixed places and time of physical hospitals is solved.

Description

Technical Field

[0001] This invention relates to the field of internet healthcare technology, specifically to an internet-based hospital consultation system and interaction method. Background Technology

[0002] With the continuous advancement of the "Internet Plus Healthcare" policy, more and more medical institutions are beginning to value and invest in the construction of online consultation systems, making this convenient medical service model gradually popularized in society. Patients can use mobile phones, computers, and other devices to conduct online consultations, make appointments, and view reports anytime, anywhere, greatly saving time and energy. At the same time, doctors can also manage patient information more efficiently through online platforms, provide personalized treatment suggestions, and further improve the quality and efficiency of medical services.

[0003] For example, Chinese patent publication number CN 113707346 B discloses a novel online consultation system and method based on an internet hospital, which uses IM communication to achieve real-time transmission of consultation information and improve consultation efficiency.

[0004] However, while most hospital consultation systems can improve consultation efficiency, their interaction modes are limited. Patients need to go through multiple, fragmented processes to complete a full consultation (including consultation, follow-up visit, prescription, medication pickup, and report acquisition), resulting in high time and economic costs and a poor medical experience. Furthermore, doctors' practice is constrained by the fixed location and time of physical hospitals, lacking efficient online patient management tools and platforms to showcase their personal influence. Their knowledge value and services are difficult to translate beyond geographical limitations, leading to insufficient utilization of high-quality medical resources. Summary of the Invention

[0005] Therefore, the present invention provides an Internet-based hospital consultation system and interaction method to solve the problems in the prior art.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] The first aspect is an internet-based hospital consultation system and interaction method, including a business middle platform layer, a multi-terminal application layer, a composite interaction layer, and a verification layer;

[0008] The business middle platform layer is built using a Java Springboot plus SpringCloud microservice architecture, which can encapsulate multiple core functions into independent service processes;

[0009] The multi-terminal application layer can select the optimal technology stack to form multi-terminal applications based on the operating habits and performance requirements of different terminal users. Each terminal interacts with the business platform through the API gateway to achieve front-end and back-end separation, enabling real-time data acquisition and submission.

[0010] The composite interaction layer is used to establish a communication link between doctors and patients to carry out the entire business process of online consultation, prescription issuance, and drug delivery, and integrates multiple interaction modes such as text, voice, video and asynchronous messaging;

[0011] The verification layer is used to enforce verification of follow-up visit eligibility, double review of prescriptions, and data encryption and anonymization when performing medical services.

[0012] Furthermore, the core functions include users, permissions, payments, orders, prescriptions, and message information.

[0013] Furthermore, the business middleware layer also includes a persistence submodule, which coordinates, accesses, and manages the system's structured data, cache, messages, unstructured data, and files by uniformly scheduling multiple types of storage components.

[0014] Furthermore, the composite interaction layer includes an instant messaging submodule, a video consultation submodule, an asynchronous consultation submodule, and a prescription stream module;

[0015] The instant messaging submodule can use the WebSocket protocol to build a full-duplex communication channel to realize full-duplex text and voice message interaction between doctors and patients;

[0016] The video consultation submodule is built on WebRTC technology and is used to establish an end-to-end media streaming channel, through which audio and video data streams can be transmitted directly between the two ends.

[0017] The asynchronous consultation submodule implements the process of patient messages and doctor non-real-time replies based on message queues, and notifies doctors to handle the messages through push services;

[0018] The prescription transfer module can receive approved prescriptions and, based on the patient's chosen method of medication collection, simultaneously or according to rules, push the electronic prescription to the hospital pharmacy system and one or more third-party partner pharmacy systems, and automatically generate logistics delivery orders or in-store medication collection vouchers.

[0019] Furthermore, the instant messaging submodule also supports message roaming and integrates a commonly used dialogue script library unit and a diagnostic template library unit, both of which are set on the side of the doctor's chat interface and displayed as an expandable structured template menu for doctors to quickly access.

[0020] Message roaming ensures that all messages are synchronously persisted to the database and search engine as they are relayed through the message service.

[0021] Furthermore, the video consultation submodule also has a legal evidence storage unit. Before the video consultation begins, the legal evidence storage unit clearly prompts and obtains the user's authorization. After authorization is obtained, recording starts immediately, including server-side recording and front-end recording.

[0022] Furthermore, the startup state of the prescription flow rotor module is triggered by changes in the prescription status, and reads the order information associated with the prescription and the medication collection method selected by the patient.

[0023] Furthermore, the specific content of the verification layer is as follows:

[0024] 1) Verification of eligibility for follow-up visits

[0025] Secure communication with the hospital's internal information system is achieved through a set of predefined, standardized RESTful API interfaces. The output carries the patient's unique identifier and the target department's information, triggering a verification request.

[0026] 2) Double review of prescriptions

[0027] The system enforces dual auditing through a pre-set auditing state machine, utilizes message queues to achieve asynchronous task distribution and collaborative work, and employs digital signatures to ensure a closed-loop process.

[0028] 3) Data encryption and desensitization

[0029] Configure and maintain valid digital certificates on the API gateway and each microservice instance, and use transport layer security protocols to ensure that the client and server generate identical symmetric session keys.

[0030] Secondly, an interactive method for an internet-based hospital consultation system includes the following steps:

[0031] S1: The patient initiates a consultation request through the multi-terminal application layer, and the verification layer verifies the patient's identity and eligibility for follow-up consultation;

[0032] S2: After successful verification, the composite interaction module establishes a corresponding communication link based on the patient's selected consultation type;

[0033] S3: During the consultation process, the doctor issues a prescription using an embedded preset template. After the prescription is submitted, it undergoes a double review process through the prescription flow module.

[0034] S4: After approval, the prescription transfer module will distribute the prescription information to the designated pharmacy and complete the subsequent drug delivery or pickup arrangements.

[0035] This invention has the following advantages: It provides patients with a convenient, installation-free entry point through a multi-terminal application layer, enables real-time audio and video communication with doctors through the instant messaging and video consultation sub-modules of the composite interaction layer, and integrates prescription issuance, drug delivery, and report query functions through the microservice architecture of the business middle platform layer; the verification layer ensures service compliance through follow-up visit qualification verification, while the prescription flow module intelligently matches pharmacies and generates logistics orders based on the patient's selection, truly realizing a one-stop business process of "online consultation-prescription-drug purchase-delivery", reducing patients' travel and waiting time.

[0036] Meanwhile, by supporting doctors to conduct consultations anytime, anywhere via mobile devices or computers, and with the embedded script and diagnostic template libraries in the composite interaction layer improving the efficiency of consultation and medical record writing, the system also provides doctors with reliable practice tools and compliance guarantees through a dual review mechanism of microservice architecture and verification layer. This allows doctors to flexibly arrange their work and solves the problem of doctors' practice being restricted to the fixed location and time of physical hospitals.

[0037] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. Attached Figure Description

[0038] To more intuitively illustrate the prior art and this application, exemplary drawings are provided below. It should be understood that the specific shapes and structures shown in the drawings should not generally be regarded as limiting conditions for implementing this application; for example, based on the technical concept disclosed in this application and the exemplary drawings, those skilled in the art are able to easily make conventional adjustments or further optimizations to the addition / reduction / classification, specific shapes, positional relationships, connection methods, size ratios, etc. of certain units (components).

[0039] Figure 1 This is a module architecture diagram of an Internet-based hospital consultation system according to the present invention.

[0040] Figure 2 This is a flowchart illustrating an interactive method for an internet-based hospital consultation system according to the present invention.

[0041] Figure 3 This is a schematic diagram of the expert consultation process, which is an application example of the interactive method of an Internet-based hospital consultation system according to the present invention. Detailed Implementation

[0042] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these embodiments are merely for further explanation of the present invention and should not be construed as limiting the scope of protection of the present invention. Technical engineers in the field can make some non-essential improvements and adjustments to the present invention based on the above-described content. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0043] Please see Figure 1 A hospital consultation system based on the Internet includes: a business middle platform layer, a multi-terminal application layer, and a composite interaction layer.

[0044] The business middle platform is built using a Java Spring Boot and Spring Cloud microservice architecture. It can encapsulate multiple core functions such as users, permissions, payments, orders, prescriptions, and messages into independent service processes. Combined with technologies such as Nacos configuration center, Ribbon microservice load balancing, Sentinel traffic control, Seata distributed transactions, OpenFeign scheduling, and Gateway, it ensures high performance, high availability, and scalability of the system, effectively handling high-concurrency access and complex business scenarios.

[0045] Nacos serves as both the service registry and configuration center, ensuring centralized management and dynamic updates of system configurations. Ribbon microservice load balancers are used to achieve load balancing of requests in a microservice architecture, optimize resource utilization, and improve system concurrency capabilities.

[0046] Sentinel traffic control enables traffic control and circuit breaking / degradation for microservices; ensures system stability under high load; and uses the Seata framework to handle distributed transactions across microservices, ensuring data consistency and integrity.

[0047] OpenFeign is used to implement declarative calls between services, simplifying inter-service communication and improving development efficiency; Spring Cloud Gateway, as a unified API gateway, is responsible for routing, authentication and rate limiting, enhancing system security and performance.

[0048] The business middle platform layer also includes a persistence sub-module, which coordinates and efficiently accesses and manages the system's structured data, cache, messages, unstructured data, and files by uniformly scheduling multiple storage components such as MySQL, Redis, RocketMQ, Elasticsearch, MongoDB, and OSS.

[0049] The persistence submodule utilizes the Mybatis framework and integrates MySQL as a relational database. The combination of Mybatis and MySQL provides efficient relational database operations, supporting complex queries and transaction management. Redis serves as a caching database, providing high-speed caching, reducing database access pressure, and improving system response speed. RocketMQ acts as a message queue, handling asynchronous tasks and decoupling the system, enhancing scalability and reliability. Elasticsearch serves as a search engine, supporting fast full-text search, suitable for log analysis and big data search scenarios. MongoDB is used for unstructured data storage, flexibly addressing diverse data format requirements. Additionally, object storage services such as OSS / MinIO are used for file storage, providing a highly available and scalable file storage solution.

[0050] The multi-terminal application layer can select the optimal technology stack to form multi-terminal applications based on the operating habits and performance requirements of different terminal users. Each terminal interacts with the business platform through an API gateway in a front-end and back-end separation manner. Specifically, for the doctor and pharmacist apps that require high-frequency operation, strong interactivity, and high performance, both mobile apps (Objective-C for iOS, Kotlin for Android) and PC versions are supported. This ensures that the applications can directly access mobile hardware resources (such as camera, microphone, and push notifications), providing a smooth and stable tool experience in core business scenarios such as consultation, prescription issuance, and review. For the patient end, a native mini-program framework is used, enabling users to use the app immediately without downloading or installing, perfectly adapting to lightweight but high-concurrency businesses such as online consultation, report retrieval, and medication purchase.

[0051] The PC-based doctor workstation, pharmacy platform, and operations management platform adopt a component-based development model based on Vue and Element-UI. Through rich UI components and data binding mechanisms, it achieves front-end and back-end separation interaction, while realizing efficient data processing and business management.

[0052] The front-end applications all follow the "front-end and back-end separation" architecture, which prevents them from being directly coupled with the back-end database or business logic. Instead, they communicate with the back-end microservice business platform through a unified API gateway (Spring Cloud Gateway).

[0053] The workflow is as follows: The front-end application (such as a mini-program or app) initiates a UI interaction request (e.g., clicking "Start Consultation"). This request first passes through a load balancer and is then routed to the API gateway. As the system's sole entry point, the gateway handles all external non-business functions, including: user authentication and authorization, request routing and forwarding, traffic control and circuit breaking (relying on Sentinel), and logging. Only after passing gateway verification is the request distributed to the corresponding specific business microservice (such as consultation service or prescription service). This model decouples the front-end and back-end, allowing the front-end team to focus on user experience and the back-end team to focus on service stability and business logic. Simultaneously, the gateway layer unifies security policies, ensuring the security and efficiency of the system entry point.

[0054] The multi-terminal application layer can also interact with the business middle platform layer through the API gateway, and realize real-time data acquisition and submission by calling the standardized RESTful API interface of the business middle platform.

[0055] For example, in a consultation scenario, text and image messages sent by patients on the mini-program are pushed to the doctor's app in real time via a WebSocket long connection through a gateway. When a doctor issues a prescription on the app, the front-end interface calls the "Medical Basic Library Service" via API to load the drug catalog and verifies the doctor's prescription authorization by calling the "Permission Service." After the prescription is submitted, the data is sent to the "Prescription Service" through the gateway, triggering subsequent review processes. Upon receiving back-end data, all front-end applications render the data according to predetermined business rules, such as anonymizing sensitive patient information (e.g., displaying the name as "Zhang*") and dynamically displaying different function buttons based on the user's role (e.g., the "Prescribe" button is only visible to the doctor). This collaborative working principle ensures data consistency, security, and real-time performance across multiple platforms.

[0056] The composite interaction layer is used to establish a communication link between doctors and patients to carry out the entire business process of online consultation, prescription issuance, and drug delivery, and integrates multiple interaction modes such as text, voice, video and asynchronous messaging.

[0057] The composite interaction layer includes an instant messaging submodule, a video consultation submodule, an asynchronous consultation submodule, and a prescription stream module. The instant messaging submodule can use the WebSocket protocol to build a full-duplex communication pipeline to realize full-duplex text and voice message interaction between doctors and patients, support message roaming, and embed a library of commonly used dialogue scripts and diagnostic templates for doctors to quickly access.

[0058] Once the doctor and patient enter a consultation session, their front-end application (mini-program / app) establishes a persistent WebSocket connection with a dedicated back-end messaging service microservice. This connection avoids the frequent request-response overhead of the HTTP protocol, allowing messages (including text, images, and voice clips) to be pushed to the other party in real time with low latency after one party sends them. At the start of the session, the system creates a unique session ID for that consultation. All messages in the same session are bound to this ID, ensuring that messages are correctly routed between the doctor and patient, and enabling parallel management and data isolation of multiple consultation sessions.

[0059] The instant messaging submodule also integrates a common dialogue script library and a diagnostic template library. Both are located on the side of the doctor's chat interface, displayed as an expandable structured template menu. When a doctor selects a preset dialogue script (such as "Please describe your current symptoms") or a diagnostic template (such as a JSON template containing fields like "Preliminary Diagnosis" and "Treatment Suggestions"), the frontend doesn't simply send text; instead, it generates a structured message with a specific type identifier (such as `msgType: template`). This message is sent and stored via WebSocket. During rendering, the receiving (patient) frontend recognizes this type and displays it in a clear, concise style, thus partially transforming unstructured, free-flowing communication into structured data entry, laying the foundation for subsequent medical record generation and data analysis.

[0060] The foundation for message roaming functionality lies in the fact that all messages, while being relayed through the message service, are synchronously persisted to a database (such as MySQL for storing metadata, or MongoDB or OSS for storing large files like images and voice messages) and a search engine (Elasticsearch). When a user (whether a doctor or a patient) logs in or re-enters a session on a different device, the frontend sends an HTTP API request to the message service to retrieve historical message records under that session ID, based on a time range. This mechanism ensures that chat logs are not lost due to device changes or connection interruptions, providing a continuous communication experience. Furthermore, all interactions are traceable, meeting the medical compliance requirements for a complete record of the consultation process.

[0061] The video consultation submodule is built on WebRTC technology to establish an end-to-end (P2P) low-latency media streaming channel. The doctor and patient's front-ends exchange network information needed to establish a connection via a signaling service: first, they exchange SDP (Session Description Protocol), including their respective media capabilities (such as supported codecs); then, they exchange ICE (Interactive Connection Establishment) candidates, i.e., all possible network addresses for both parties (internal IP, public IP, etc.). After this information is relayed through the signaling server, the WebRTC engine attempts to find the optimal direct communication path between the two parties. Once a connection is successfully established, audio and video data streams can be transmitted directly between the two ends, bypassing the central server's forwarding, thus achieving millisecond-level low latency.

[0062] The video consultation submodule also includes a legal evidence storage unit. Before the video consultation begins, the legal evidence storage unit explicitly prompts and obtains the user's authorization. Once authorization is obtained, recording immediately begins. This includes the following two types of recording:

[0063] 1) Server-side recording: Recording the video stream on a media server;

[0064] 2) Front-end recording: On the doctor's or patient's end, the local media stream is recorded using the browser's MediaRecorder API. The recorded video file is immediately encrypted using an encryption algorithm (such as AES), and then stably uploaded to the cloud's object storage service using a segmented, breakpoint-resumption upload method, ensuring file integrity and no loss.

[0065] After the video file is uploaded to object storage, the system generates a unique file identifier (such as a URL). Subsequently, the legal evidence preservation unit calls the API of a third-party electronic evidence preservation service or blockchain evidence preservation service to package the video file's hash value, recording time, associated consultation order ID, and other information to generate a legally valid electronic evidence certificate. This certificate will be closely linked to the electronic medical record, prescription, and other data from this consultation in the business database. In the event of a future medical dispute, this certificate can serve as independent, tamper-proof third-party evidence, completely reconstructing the consultation scene.

[0066] The asynchronous consultation submodule implements the process of patient messages and doctor non-real-time replies based on message queues, and notifies doctors to handle the requests through push services.

[0067] For example, when a patient submits an asynchronous consultation request (i.e., a message), the front-end calls the API gateway to send the core information of the consultation request (such as patient ID, problem description, and order number) as a message body to a message queue topic. This sets the initial status of the consultation form to "Pending Consultation." The doctor enters the app, sees the task in "My To-Do List," and begins replying, changing the status to "Replying." After the doctor completes and submits the reply, the status updates to "Replied." At this point, the system again notifies the patient via push service that "Doctor has replied." After viewing the reply, the patient can choose to end the consultation or continue asking follow-up questions (the status returns to "Pending Consultation"), forming a closed loop. This immediately releases the request thread, allowing the system to quickly respond to the patient with "Submission Successful," achieving asynchronous requests, avoiding request blocking due to the doctor's offline status, and improving system throughput and responsiveness.

[0068] The prescription transfer module can receive approved prescriptions and, based on the patient's chosen method of medication collection, simultaneously or according to rules, push the electronic prescription to the hospital pharmacy system and one or more third-party partner pharmacy systems, and automatically generate logistics delivery orders or in-store medication collection vouchers.

[0069] The prescription circulation module's startup is triggered by changes in prescription status. When an electronic prescription successfully passes the dual review of the "platform pharmacist" and the "third-party pharmacist," and its status is marked as "approved" in the database, an event is triggered. This event is captured by the "prescription circulation service," thus initiating the circulation process. This service first reads the order information associated with the prescription, especially the patient's chosen medication pickup method ("home delivery" or "in-store pickup"). Then, the service's internal rules engine intelligently matches and outputs the optimal pharmacy list based on multiple dimensions, including the medication pickup method, the patient's delivery address or geographical location, and the drug inventory status of each partner pharmacy.

[0070] Once the target pharmacy is identified, the transfer service uses standardized interfaces to push structured prescription data (including drug information, usage and dosage, patient information, etc.) to one or more pharmacy systems in parallel or according to priority.

[0071] For in-hospital pharmacies, their HIS system is accessed directly via the internal network interface; for third-party partner pharmacies, their pharmacy management system is connected via a public network API. To ensure data security and consistency, all external distribution requests must be authenticated (e.g., using an API Key and Secret), and prescriptions are marked as "distributed" after being sent to prevent duplicate distributions. The system supports sending the same prescription to multiple pharmacies simultaneously, allowing patients to ultimately decide where to purchase it.

[0072] The verification layer is used to enforce follow-up visit eligibility verification, double-check prescriptions, and data encryption and anonymization during the execution of medical services, ensuring that the system complies with the "Administrative Measures for Internet-based Medical Services" and the Level 3 requirements of network security protection. Specific details are as follows:

[0073] 1) Verification of eligibility for follow-up visits

[0074] Secure communication with the hospital's internal information systems is achieved through a set of predefined, standardized RESTful API interfaces. When a patient attempts to initiate a "follow-up visit and prescription" request on the front end, the "consultation service" in the business middle platform does not immediately create an order. Instead, it synchronously calls the API, outputting the patient's unique identifier (such as ID card number or medical insurance card number) and the target department information, thereby triggering a verification request.

[0075] The rule engine embedded in the verification layer executes strict verification logic based on the requirements of the "Administrative Measures for Internet-based Medical Services." Through the standardized interface mentioned above, it queries the hospital's system to determine if the patient has a valid, completed initial consultation record in the target department within a specific timeframe (e.g., the past three months). The engine then matches the query results against preset rules.

[0076] For example, whether the diagnosed disease is a chronic disease (such as hypertension or diabetes) listed in the Internet medical service catalog, and whether the patient's condition is stable.

[0077] 2) Double review of prescriptions

[0078] The system enforces dual auditing through a pre-defined audit state machine, utilizes message queues for asynchronous task distribution and collaborative work, and employs digital signatures to ensure a closed-loop process.

[0079] After a doctor submits an electronic prescription, it must be reviewed sequentially by the platform's own pharmacists and third-party partner pharmacists. Pharmacists can view the complete prescription information in their respective review interfaces and use the system's rational drug use knowledge base for further assessment. Review comments and modification records are fully recorded. Only after all stages are approved will an electronic signature be added and the prescription processed downstream. If any stage rejects the prescription, the system will automatically notify the prescribing doctor to make modifications. This measure effectively prevents prescriptions from exceeding dosage or scope, ensuring patient medication safety.

[0080] 3) Data encryption and desensitization

[0081] Configure and maintain valid digital certificates on the API gateway and each microservice instance. When a client (such as a mini-program) establishes a connection with the server, the Transport Layer Security (TLS) protocol is initiated, enabling the client and server to generate identical symmetric session keys. These symmetric keys will be used throughout the entire session, thus ensuring both the confidentiality and integrity of communication while maintaining encryption and decryption performance, effectively preventing man-in-the-middle eavesdropping and data tampering.

[0082] For sensitive data requiring persistent storage, this unit employs the national standard SM4 algorithm for field-level encryption. Before business services write data to the database, a unified encryption service is invoked to encrypt specified fields (such as ID card number, mobile phone number, and detailed address), and the encrypted data is stored in the database. Only authorized services can decrypt the data during its use.

[0083] The system also integrates the following capabilities:

[0084] I. Supports data integration with provincial-level internet healthcare service regulatory platforms, enabling real-time uploading of diagnosis and treatment process data; establishes a real-time data channel with provincial-level internet healthcare service regulatory platforms through pre-built standardized API interfaces that comply with the "Internet Healthcare Service Regulatory Platform Data Interface Specification"; driven by a compliance control engine, the system automatically triggers data uploads at key business nodes (such as the start of a consultation, prescription issuance, and completion of review), synchronizing anonymized core diagnosis and treatment data (including patient and doctor identities, diagnostic conclusions, prescription content, and operation timestamps) to the regulatory platform in real time, ensuring that all online diagnosis and treatment activities are conducted under national regulatory oversight and meeting the requirements of in-process supervision and post-event auditing.

[0085] 2. Integrate facial recognition services for real-person verification of doctors' and pharmacists' identities; before doctors / pharmacists register or perform critical operations, the client (APP or PC) calls the camera to collect the user's facial biometric image, and transmits the media stream along with the user's submitted ID information in encrypted form to the facial recognition server; the server verifies that the person is "real" and "the person" through liveness detection, image quality judgment, and a 1:1 comparison with the ID photo, and returns the verification result (success / failure) to the business system. Only after successful verification can the account be activated or subsequent sensitive operations be performed, thereby ensuring the authenticity and uniqueness of the practitioner's identity.

[0086] Third, it has an independent prescription review platform that supports the review of the rationality and compliance of prescriptions. When a doctor submits an electronic prescription, the prescription data is asynchronously pushed to the prescription review platform through a message queue and enters the waiting queue for review. The platform has a built-in rational drug use rule engine (including drug incompatibilities, dosage ranges, indications, etc.) to assist platform pharmacists and third-party pharmacists in conducting dual reviews in turn. The review interface centrally displays the patient's medical history, diagnosis, and prescription details. Pharmacists can provide review opinions (approval, modification, or rejection) based on rules and clinical experience. All prescription review behaviors and results are recorded and traced, forming a closed-loop prescription quality control process.

[0087] Fourth, support read / write separation for business databases to improve system performance and data processing capabilities; deploy a master database instance to handle write operations (such as insert, update, and delete), and configure one or more slave database instances to synchronize master database data in real time and handle complex query operations (such as report queries and statistical reports); the business code layer integrates data source middleware (such as ShardingSphere) or configures multiple data sources to achieve automatic routing, sending write requests to the master database and distributing read requests to slave databases, thereby effectively distributing the database load and improving the overall data processing capabilities and response speed of the system.

[0088] V. Achieving traffic distribution, failover, and high service availability through load balancers and Nginx clusters. The load balancer is located at the front end, providing services to the outside world through virtual IPs and distributing massive user requests to multiple backend Nginx servers. The Nginx cluster further performs reverse proxying, static / dynamic content separation (directing static resource requests to object storage and forwarding dynamic API requests to the gateway cluster), and load balancing. This architecture also has a health check mechanism that can automatically monitor the status of backend service nodes. When a failure is detected in an Nginx or business service node, it is immediately removed from the service pool, and traffic is seamlessly switched to healthy nodes, ensuring high availability and continuity of the system under high concurrency.

[0089] Please see Figure 2 An interactive method for an internet-based hospital consultation system includes the following steps:

[0090] S1: Patients initiate consultation requests through the multi-terminal application layer, and the verification layer verifies the patient's identity and eligibility for follow-up visits. After the patient submits a consultation request through the front-end application, the system immediately verifies the patient's offline first consultation record and disease compliance through a standardized interface. Only after the verification is passed can the patient enter the doctor-patient matching process.

[0091] Patients access the internet hospital platform through a mini-program or app. After logging in and authenticating, they select the online consultation function, fill in a basic description of their condition, choose the target department and doctor, and finally click submit to generate a consultation order. Simultaneously, the system verifies the patient's eligibility for a follow-up visit. A standardized RESTful API is used to call the hospital system, using the patient's ID number and department information to check if they have a valid offline initial consultation record within the past three months. The verification engine also checks whether the diagnosed disease falls under the chronic disease follow-up consultation catalog stipulated in the "Internet Medical Services Management Measures." If verification fails, the system immediately blocks the process and returns a "Does not meet the follow-up consultation conditions" message to the patient. If verification succeeds, the consultation order status is updated to "Pending Consultation," triggering subsequent doctor-patient matching logic.

[0092] S2: After successful verification, the composite interaction module establishes the corresponding communication link based on the consultation type selected by the patient; video consultation establishes a WebRTC point-to-point channel through signaling exchange, while asynchronous consultation transfers the request to a message queue for the doctor to process.

[0093] For real-time consultations: The instant messaging submodule immediately creates a unique session ID for the consultation session. The patient and doctor establish a persistent connection with the message service microservice via the WebSocket protocol, enabling full-duplex real-time transmission of text, images, and voice messages. Simultaneously, the system loads the doctor's frequently used scripts and diagnostic templates into the chat interface sidebar for quick access.

[0094] For video consultations: The video consultation submodule exchanges SDPoffer / answer and ICE candidate information between the doctor and patient via a signaling service (based on Socket.io), negotiates media capabilities, and establishes an end-to-end WebRTC connection. After obtaining explicit authorization from both parties, the legal evidence storage unit starts front-end recording, encrypts the video stream using the AES algorithm, uploads it in segments to object storage, and simultaneously generates a blockchain evidence hash.

[0095] For asynchronous consultations: The asynchronous consultation submodule encapsulates the consultation request into a message body and pushes it to the "Pending Consultation" topic of RocketMQ. The task scheduling service listens to this topic and assigns the task to the to-do list of the corresponding department doctor. At the same time, it sends a notification to the doctor's APP through the vendor's push channel.

[0096] S3: During the consultation process, the doctor issues a prescription using an embedded preset template. After the prescription is submitted, it undergoes a double review process through the prescription flow module.

[0097] In the consultation interface, doctors can select a structured template (containing fields such as diagnosis, medication list, and dosage) from the diagnostic template library in the sidebar that matches their condition. The system automatically fills the template into the prescription form. After the doctor confirms and submits, the prescription status changes to "review status".

[0098] At this point, the prescription data is asynchronously pushed to the independent prescription review platform via RocketMQ. The platform's pharmacists first conduct an initial review based on the rational drug use rule engine (which includes built-in rules on drug incompatibilities, dosage thresholds, etc.). Once approved, the status changes to "awaiting third-party pharmacist review." The third-party collaborating pharmacist receives the prescription data through a standardized interface for a second review; both levels of review require digital signature confirmation. If any step rejects the prescription, the system automatically notifies the prescribing physician to make modifications; once all steps are approved, the prescription status is updated to "approved," and a double electronic signature is attached.

[0099] S4: After approval, the prescription transfer module distributes the prescription information to the designated pharmacy and completes the subsequent drug delivery or pickup arrangements, thus completing the drug supply loop.

[0100] The prescription transfer module can monitor prescription status changes. When a prescription is approved, the distribution process is immediately initiated: First, the system parses the patient's chosen pickup method (home delivery / in-store pickup) and intelligently matches the optimal pharmacy list based on the patient's preset delivery address, drug inventory, delivery radius, and other dimensions. Then, encrypted prescription data is pushed in parallel to the target pharmacy system via HTTPS. If home delivery is selected, the system automatically calls the logistics service interface to generate an electronic waybill; if in-store pickup is selected, a pickup voucher with an encrypted QR code is generated. After the pharmacy confirms receipt of the prescription, the order status is synchronously updated to the patient's end, forming a complete service loop. All transfer records are uploaded to the provincial regulatory platform in real time, meeting compliance audit requirements.

[0101] In the aforementioned internet-based hospital consultation system and interaction method, a multi-terminal application layer provides patients with a convenient, installation-free entry point. The composite interaction layer utilizes instant messaging and video consultation sub-modules to enable real-time audio and video communication with doctors. Furthermore, the microservice architecture of the business middle platform layer integrates prescription issuance, drug delivery, and report query functions. The verification layer verifies follow-up visit eligibility to ensure service compliance, while the prescription flow module intelligently matches pharmacies based on patient selection and generates logistics orders. This truly realizes a one-stop service of "online consultation - prescription - drug purchase - delivery," greatly reducing patients' travel and waiting time.

[0102] Meanwhile, by supporting doctors to conduct consultations anytime and anywhere via mobile devices or computers, the embedded script library and diagnostic template library in the composite interaction layer greatly improve the efficiency of consultation and medical record writing. At the same time, the dual prescription review mechanism of the microservice architecture and verification layer provides doctors with reliable practice tools and compliance guarantees, enabling them to flexibly arrange their work and solving the problem that doctors' practice is restricted to the fixed location and time of physical hospitals.

[0103] The system is based on a highly available and scalable microservice architecture in the business middleware layer, which can easily cope with high concurrency of online business and effectively expand the hospital's service radius and time. Through standardized interfaces and connection with the provincial regulatory platform, as well as mandatory follow-up verification and prescription review, it realizes compliant and efficient management of online business and a closed loop of online and offline services.

[0104] Here is a specific application example: taking expert consultation as an example:

[0105] (1) Patient appointment and submission

[0106] Patients can access the platform from its homepage, select a specific department and their preferred specialist doctor, and submit a description of their condition and relevant information (such as medical history and examination reports).

[0107] The system guides patients to select or create an electronic health record, followed by payment of the consultation fee. After successful payment, the order status changes to "pending consultation".

[0108] (2) Doctor-patient interaction and diagnosis

[0109] Once the doctor receives a consultation order and begins the consultation, both doctor and patient communicate about the patient's condition through the built-in instant messaging or video consultation module. The doctor will review the information submitted by the patient and may request the patient to provide supplementary information if necessary. After the consultation, the doctor will provide a professional diagnosis or treatment suggestion.

[0110] (3) Order termination and closed loop

[0111] Once the consultation service is completed, the system will update the order status to "Completed," signifying the successful end of the service. If the patient cancels the order before the doctor sees the patient, or if payment fails, the system will automatically close the order or issue a refund. If the doctor refuses to see the patient, the system will also trigger order closure and automatically refund the patient.

[0112] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An internet-based hospital consultation system, characterized by, The business middle station layer, the multi-terminal application layer, the composite interaction layer and the verification layer are included. The business middle station layer is built by Java Springboot and SpringCloud micro service architecture, and can encapsulate multiple core functions as independent service processes. The multi-terminal application layer can select the optimal technology stack to form a multi-terminal application based on the operation habits and performance requirements of different terminal users, and each terminal interacts with the business middle station through an API gateway to realize real-time data acquisition and submission. The composite interaction layer is used to establish a communication link between doctors and patients to perform the whole business process of online consultation, prescription issuance and drug distribution, and integrates multiple interaction modes such as text, voice, video and asynchronous message. The verification layer is used to perform mandatory re-examination qualification verification, prescription double-check and data encryption and desensitization when performing diagnosis and treatment services.

2. The internet-based hospital consultation system according to claim 1, wherein, The core functions include user, permission, payment, order, prescription and message information. 3.The Internet-based hospital consultation system according to claim 1, characterized in that, The business middle station layer further includes a persistence submodule, which cooperates, accesses and manages structured data, cache, message, unstructured data and file of the system by uniformly scheduling multiple types of storage components.

4. The Internet-based hospital consultation system according to claim 1, wherein, The composite interaction layer includes an instant messaging submodule, a video consultation submodule, an asynchronous consultation submodule and a prescription flow submodule. The instant messaging submodule can build a duplex communication pipeline using the WebSocket protocol to realize full-duplex text and voice message interaction between doctors and patients. The video consultation submodule is built based on WebRTC technology and is used to establish an end-to-end media stream channel, through which audio and video data streams can be directly transmitted between two ends. The asynchronous consultation submodule realizes the process of patient message and doctor non-real-time reply based on a message queue, and notifies the doctor of processing through a push service. The prescription flow submodule can receive the checked prescription, push the electronic prescription to the hospital pharmacy system and one or more third-party cooperative pharmacy system according to the patient's selected drug pickup method, and automatically associate to generate a logistics distribution order or a store pickup voucher.

5. The internet-based hospital consultation system according to claim 4, wherein, The instant messaging submodule also supports message roaming and integrates a common speech library unit and a diagnosis template library unit, which are set on the side of the doctor's chat interface and displayed as an expandable structured template menu for doctors to quickly call. Message roaming is used to synchronize all messages to the database and search engine when they are transferred through the message service.

6. The internet-based hospital consultation system according to claim 4, wherein, The video consultation submodule also has a legal evidence unit, which prompts and obtains the user's authorization before the video consultation starts, and starts recording after obtaining the authorization, including server recording and front-end recording. 7.The Internet-based hospital consultation system according to claim 1, wherein, The start state of the prescription flow submodule is triggered by the change of the prescription state, and the order information associated with the prescription and the patient's selected drug pickup method are read. 8.The Internet-based hospital consultation system according to claim 1, wherein, The specific content of the verification layer is as follows: 1) Re-examination qualification verification Through a set of pre-defined, standardized RESTful API interfaces, the system securely communicates with the hospital's internal information systems, outputting information carrying the patient's unique identifier and the target department, triggering the verification request; 2) Double-checking of prescriptions The pre-set audit state machine enforces double-checking, message queues are used for asynchronous task distribution and collaborative work, and digital signatures are used to ensure process closure; 3) Data encryption and desensitization Valid digital certificates are configured and maintained on the API gateway and each microservice instance, and the client and server generate the same symmetric session key through the Transport Layer Security protocol.

9. An interaction method of an Internet-based hospital consultation system, characterized by, The method comprises the following steps: S1: The patient initiates a consultation request through a multi-terminal application layer, and the verification layer verifies the patient's identity and re-consultation qualification; S2: After verification, the corresponding communication link is established by the composite interaction module according to the patient's selected consultation type; S3: During the consultation interaction, the doctor issues a prescription through the embedded pre-set template, and the prescription is submitted to the prescription flow sub-module for a double-checking process; S4: After the audit is passed, the prescription flow sub-module distributes the prescription information to the designated pharmacy and completes the subsequent medicine distribution or medicine collection arrangement.

Images