A.net-based intelligent medical self-service query terminal device, implementation method, medium and product

Abstract

The application provides a.NET-based intelligent medical self-service query terminal device, an implementation method, a medium and a product, and relates to the technical field of intelligent medical treatment. When a front-end self-service terminal is started, interface configuration data is requested and loaded from a back-end management platform, and a user operation interface is constructed according to the data, so that the front-end interface display and the back-end business logic are decoupled. This decoupling makes it no longer necessary to modify and redeploy the front-end application program when adjusting interface elements such as function entries and theme colors, but only needs to make simple modifications to the back-end configuration file. Secondly, on this basis, by integrating various hardware driver interfaces, identity input information from different sources is uniformly processed into a patient identity session throughout the business cycle, and the session becomes the core credential that links all business instructions. It has flexibility and maintainability, and can provide complete and unified cross-business (outpatient and inpatient) process services.

Description

Technical Field

[0001] This application relates to the field of smart healthcare technology, and in particular to a smart healthcare self-service query terminal device, implementation method, medium, and product based on .NET. Background Technology

[0002] With the rapid development of information technology and the popularization of the concept of "smart healthcare," major hospitals have introduced self-service terminals to alleviate the pressure on manual service windows and optimize patient flow. These self-service devices aim to provide patients with one-stop services such as registration, payment, and report printing, reducing waiting time and improving overall medical service efficiency and patient satisfaction. The widespread application of self-service terminals has become an indispensable part of modern hospital construction, and their completeness of function and ease of operation directly affect the hospital's operational efficiency and brand image.

[0003] To implement the aforementioned self-service functions, existing self-service terminal software systems typically employ a client-server (C / S) architecture. In this architecture, a pre-installed client application with fixed functionality is pre-installed on the front-end self-service terminal. The application's interface layout, button arrangement, and overall visual style are all hard-coded directly into the source code during the software development phase. When a hospital needs to launch new business functions or adjust the entry points of existing functions to accommodate seasonal peak visitation times, the software developer needs to modify the client's source code, recompile and repackage it, and then maintenance personnel must uninstall the program and reinstall the new version on each of the hospital's self-service terminals.

[0004] The aforementioned method of updating the interface by modifying the source code and redeploying demonstrates significant lag in daily hospital operations. Furthermore, because different hospitals have different brand images (VI) and specialized departments, software vendors cannot provide customized interfaces for each hospital, resulting in a uniformity of self-service machine interfaces on the market. This fails to reflect the individual characteristics of each hospital and reduces brand recognition. In addition, each update requires large-scale on-site deployment by maintenance personnel, incurring high costs in terms of manpower and time. Summary of the Invention

[0005] This application provides a .NET-based smart healthcare self-service query terminal device, implementation method, medium, and product to enhance the hospital's "hot update" capability.

[0006] Firstly, this application provides a method for implementing a smart healthcare self-service query terminal device based on .NET, comprising: when the front-end self-service terminal starts up, it requests and loads interface configuration data from the back-end management platform, and constructs a user interface based on the interface configuration data; the interface configuration data is obtained by the back-end management platform parsing the configuration file; the interface configuration data includes a structured instruction set of front-end function entry, interface theme color code, and layout coordinate parameters; the front-end self-service terminal detects the identity input information through different hardware driver interfaces to obtain the patient identity session within the current business cycle, the patient identity session including an encrypted patient identifier and a valid session timestamp; the identity input information includes one or more of the following: magnetic stripe card, ID card, medical insurance electronic voucher QR code, and heterogeneous face format; after verifying the validity of the patient identity session, the front-end self-service terminal receives business instructions; the front-end self-service terminal encapsulates the business instructions together with the associated session information into business data to be processed, the business instructions including one or more of the following: registration, payment, admission registration, or hospitalization renewal.

[0007] By adopting the above technical solution, the system requests and loads interface configuration data from the backend management platform upon startup of the front-end self-service terminal, and constructs the user interface based on this data, thus decoupling the front-end interface display from the backend business logic. This decoupling means that adjustments to interface elements such as function entry points and theme colors no longer require modification and redeployment of the front-end application, but are transformed into simple modifications to the backend configuration files. Furthermore, by integrating multiple hardware driver interfaces, identity input information from different sources is uniformly processed into a single patient identity session that spans the entire business cycle. This session becomes the core credential connecting all business instructions. This achieves a system that is both flexible and maintainable, while providing complete and unified cross-business (outpatient and inpatient) process services.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, after the front-end self-service terminal detects the identity input information through different hardware driver interfaces to obtain the patient's identity session within the current business cycle, the method further includes: the front-end self-service terminal using the identity input information to obtain local medical data and external medical data; the front-end self-service terminal caching and binding the local medical data and external medical data with the patient's identity session; after receiving the business instruction: extracting the current context vector from the business instruction; calculating the matching degree between the current context vector and the vectors of data in the local medical data and external medical data; and determining whether the matching degree calculation result of the current context vector and the vector of any data is higher than a preset matching degree threshold; if it is higher than the preset matching degree threshold, it is determined to be a continuous operation, and the front-end self-service terminal encapsulates the business instruction along with the associated session information into business data to be processed; if it is not higher than the preset matching degree threshold, it is determined to be a non-continuous operation, the current interface and data are saved, and the user operation interface is refreshed.

[0009] By adopting the above technical solution, after creating a patient identity session, the system further utilizes this session to acquire and cache medical data related to the patient's identity. Based on this, when a new business instruction is received, it is no longer executed unconditionally. Instead, the system first extracts its current context vector and calculates its matching degree with the previously cached medical data. This calculation process is essentially an implicit verification of the logical consistency between the current operation and the patient's historical behavior. It no longer relies on the user's active operation or additional verification steps, but identifies anomalies by analyzing the rationality of the business behavior itself. Ultimately, this achieves the identification and interception of high-risk scenarios such as "session misuse by others" without sacrificing a smooth user experience, thus improving account security and data privacy protection in public self-service device environments.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, if the matching degree is not higher than a preset threshold, the operation is determined to be discontinuous, the current interface and data are saved, and the user interface is refreshed. Specifically, this includes: the front-end self-service terminal acquiring local behavior data within the current business cycle; the front-end self-service terminal using the local behavior data to retrieve potential instruction intent sets according to preset medical business logic rules; determining whether the business instruction matches any instruction intent in the instruction intent set; if not, the operation is determined to be discontinuous, the current interface and data are saved, and the user interface is refreshed; if it matches, the operation is determined to be continuous, and the front-end self-service terminal encapsulates the business instruction along with associated session information into business data to be processed.

[0011] By adopting the above technical solution, after determining that an operation is "discontinuous," the system further utilizes existing local behavioral data to search the medical business logic rule base to generate a set of potential instruction intents predicting the user's most likely next action. It avoids directly classifying user hesitation or erroneous operations as malicious behavior. Based on this, when the user issues a business instruction again after a preset time, it is compared with this set of potential instruction intents. This provides a secondary screening capability when facing abnormal operations. It effectively intercepts genuine abnormal operations while avoiding "false positives" caused by user unfamiliarity with the operation or network latency, improving usability and user-friendliness while ensuring security.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, after the front-end self-service terminal obtains local medical data and external medical data using identity input information; the front-end self-service terminal obtains the patient identity session and associated matters from the local medical data in the previous business cycle; the front-end self-service terminal determines whether there are any unfinished pending matters among the associated matters; if there are any unfinished pending matters, the pending matters are associated with the patient identity session in the current business cycle.

[0013] By adopting the above technical solution, when a long interval (e.g., spanning multiple days) is identified between the current business cycle and the previous business cycle, a cross-cycle context inheritance step is triggered to proactively obtain the historical business context of the previous business cycle (especially unfinished tasks). These inherited tasks are then further associated with the patient's identity session within the current business cycle. This combines multiple previously fragmented and isolated medical cycles into a coherent and complete medical journey at the data and logical levels. This facilitates long-cycle medical procedures such as "retrieving reports the next day" and "follow-up visits every other week."

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, after the step of associating the to-do item with the patient identity session in the current business cycle, the method further includes: retrieving a supplementary instruction intent set by using the historical behavior data corresponding to the to-do item in preset medical business logic rules; and adding the supplementary instruction intent set to the instruction intent set.

[0015] By adopting the above technical solution, after associating to-do items with the current patient's session, the inherited to-do items and their corresponding historical behavior data are further utilized to retrieve data from medical business logic rules, generating a supplementary instruction intent set. This supplementary instruction intent set is then merged with the instruction intent set generated in the current cycle. This ensures that when making subsequent intent judgments, the "view" is no longer limited to the behavior of the current cycle, but extends to a global view including historical key tasks. This avoids the rigidity of the process that may result from simple inheritance.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, after the front-end self-service terminal verifies the validity of the patient's identity session and receives the business instruction, the method further includes: when the business instruction is to apply for hospital admission, the front-end self-service terminal uses the patient's identity session to retrieve the admission information and guides the user to pay the hospital deposit; the back-end management platform generates an electronic hospital admission certificate corresponding to the patient's identity session; the electronic hospital admission certificate serves as an index to query and display the patient's hospital expense list on the front-end self-service terminal, and connects to the front-end self-service terminal to perform self-service renewal and top-up of the hospital account.

[0017] By adopting the above technical solution, when the business instruction is to be admitted to the hospital, after completing the admission registration and deposit payment, the backend server generates an electronic hospitalization certificate corresponding to the patient's identity session. This becomes a unique digital identity index throughout the entire hospitalization period. Based on this, all subsequent operations during hospitalization, such as fee inquiries and renewals, use this electronic hospitalization certificate as an index. This collaborative mechanism anchors multiple hospitalization business processes that were originally scattered at different times and required repeated identity verification onto a single digital certificate.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after the front-end self-service terminal encapsulates the business instruction along with the associated session information into business data to be processed, the method further includes: performing access control verification based on a preset role on the operation request of the back-end administrator through the back-end management platform; after the verification is successful, the back-end management platform sends a remote control instruction to the designated front-end self-service terminal; causing the front-end self-service terminal to call its internally pre-installed hardware vendor SDK to perform a health status self-check on the hardware components, and constructing a device status diagnostic data set from the self-check results; and sending it back to the back-end management platform.

[0019] By adopting the above technical solution, during the execution of backend maintenance tasks, the backend management platform performs role-based access control verification on administrator operation requests. This ensures the legality and traceability of operations. Based on this, only after successful verification is a remote control command sent to the designated front-end self-service terminal, triggering it to call the hardware vendor's SDK to perform a health status self-check and return device status diagnostic data. This achieves a dual improvement in operational efficiency and security level.

[0020] Secondly, this application provides a .NET-based smart healthcare self-service query terminal device, which includes: one or more processors and a memory; the memory is coupled to one or more processors, and the memory is used to store computer program code, which includes computer instructions, and the one or more processors call the computer instructions to cause the .NET-based smart healthcare self-service query terminal device to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, this application provides a computer program product containing instructions that, when run on a .NET-based smart healthcare self-service query terminal device, cause the .NET-based smart healthcare self-service query terminal device to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, this application provides a computer-readable storage medium including instructions that, when executed on a .NET-based smart healthcare self-service query terminal device, cause the .NET-based smart healthcare self-service query terminal device to perform the method described in the first aspect and any possible implementation thereof.

[0023] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. By requesting and loading interface configuration data from the backend management platform upon startup of the front-end self-service terminal, and constructing the user interface based on this data, the decoupling of the front-end interface display and backend business logic is achieved. This decoupling means that adjustments to interface elements such as function entry points and theme colors no longer require modification and redeployment of the front-end application, but are transformed into simple modifications to the backend configuration files. Secondly, based on this, by integrating multiple hardware driver interfaces, identity input information from different sources is uniformly processed into a single patient identity session that spans the entire business cycle. This session becomes the core credential connecting all business instructions. This achieves a system that is both flexible and maintainable, while providing complete and unified cross-business (outpatient and inpatient) process services.

[0024] 2. After creating a patient identity session, the system further utilizes this session to acquire and cache medical data related to the patient's identity. Based on this, when a new business instruction is received, it is no longer executed unconditionally. Instead, the system first extracts the current context vector and calculates its matching degree with the previously cached medical data. This calculation process is essentially an implicit verification of the logical consistency between the current operation and the patient's historical behavior. It no longer relies on the user's active actions or additional verification steps, but identifies anomalies by analyzing the rationality of the business behavior itself. Ultimately, this achieves the identification and interception of high-risk scenarios such as "session misuse by others" without sacrificing a smooth user experience, thus improving account security and data privacy protection in public self-service device environments.

[0025] 3. After determining an operation to be "discontinuous," the system further utilizes saved local behavioral data to search the medical business logic rule base to generate a set of potential instruction intents predicting the user's most likely next action. It does not directly classify user hesitation or erroneous operations as malicious behavior. Based on this, when the user issues a business instruction again after a preset time, it is compared with this set of potential instruction intents. This provides a secondary screening capability when facing abnormal operations. It effectively intercepts genuine abnormal operations while avoiding "false positives" caused by user unfamiliarity with the operation or network latency, improving usability and user-friendliness while ensuring security. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating the implementation method of a smart healthcare self-service query terminal device based on .NET in this application embodiment; Figure 2 This is another flowchart illustrating the implementation method of the .NET-based smart healthcare self-service query terminal device in this application embodiment; Figure 3 This is another flowchart illustrating the implementation method of the .NET-based smart healthcare self-service query terminal device in this application embodiment; Figure 4 This is an exemplary hardware structure diagram of a .NET-based smart healthcare self-service query terminal device in the embodiments of this application. Detailed Implementation

[0027] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0028] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0029] Please see Figure 1 , Figure 1 This is a flowchart illustrating the implementation method of a smart healthcare self-service query terminal device based on .NET in this application embodiment; S101. When the front-end self-service terminal starts up, it requests and loads the interface configuration data from the back-end management platform, and builds the user operation interface based on the interface configuration data. The interface configuration data is obtained by the back-end management platform from parsing the configuration file. The interface configuration data includes a structured instruction set of front-end function entry, interface theme color code and layout coordinate parameters.

[0030] Among them, the front-end self-service terminal refers to the physical hardware equipment deployed in public areas such as the hospital lobby for patients or their families to operate independently; the back-end management platform refers to the software deployed on the server side used by the hospital's information department administrator for centralized management and configuration of all front-end devices; interface configuration data is a data packet organized in a specific format (such as XML or JSON) to describe the appearance and structure of the front-end interface; configuration files refer to one or more text files stored on the back-end server, which administrators modify to define the content of the interface configuration data; front-end function entry points are used to represent clickable buttons on the interface, such as "registration" and "payment"; interface theme color codes are used to represent the color values ​​of various elements on the interface, such as the main color and background color; layout coordinate parameters are used to represent the precise position and size of each function entry point on the screen; and structured instruction sets refer to the fact that the interface configuration data is organized according to a predefined format with hierarchical and key-value pair relationships, rather than unordered text.

[0031] Specifically, when the application of each front-end self-service terminal starts or is activated, it proactively sends a data request to the designated back-end management platform via the network. Upon receiving the request, the back-end management platform reads its locally stored XML or JSON configuration file, which can be modified by the administrator at any time. It parses this configuration file in real time, extracting parameters such as the list of function buttons, the main color scheme of the interface, and the x / y coordinates and dimensions of each button on the screen. These parameters are then combined into standardized, structured interface configuration data, which is finally returned to the front-end self-service terminal as a response.

[0032] In some embodiments, the backend administrator modifies a UILayout.xml file stored in the server's web directory using a text editor or a dedicated graphical interface tool, and uses the following in the file: <button>、 <color>The `` tag defines each UI element. Next, when the front-end self-service terminal starts, it uses the .NET HttpClient class to send an HTTP GET request to the URL of the XML file. Finally, after obtaining the XML text, the front-end uses the .NET System.Xml.Linq library (such as XDocument.Parse) to parse the XML text into an object model, and iterates through the nodes and properties in the model to call the APIs of the UI framework (such as WPF or AvaloniaUI) to dynamically generate buttons, set colors, and layouts; specific limitations are not specified here.

[0033] In other embodiments, the backend provides a graphical management interface where administrators design the UI through drag-and-drop and property settings. All configuration information is stored in real-time in multiple related tables in the database. Secondly, the backend provides a RESTful API interface (e.g., / api / ui / config / {terminalId}) using the .NET ASP.NET Core framework. Finally, when the front-end self-service terminal starts, it calls this API interface. The backend then queries the database for the latest UI configuration matching the terminal ID, serializes it into a JSON string, and returns it. Upon receiving the JSON, the frontend uses the System.Text.Json or Newtonsoft.Json library to deserialize it into a dynamic or strongly typed object and constructs the interface accordingly. It is understood that other methods can also be used to generate and load interface configuration data, such as efficient binary data transmission via gRPC, which is not limited here.

[0034] In some preferred embodiments, after each successful loading of interface configuration data from the backend, the front-end self-service terminal encrypts and stores a copy of this data, along with a version number or timestamp, in local persistent storage (such as an SQLite database or an encrypted file). When the terminal restarts, it first attempts to connect to the backend platform. If the connection is successful, it loads the latest configuration data and updates the local cache. If the connection fails, it does not report an error but automatically reads the last successfully loaded interface configuration data from the local cache to build the interface. Simultaneously, a subtle message "Currently in offline mode; some functions may be limited" is displayed on the screen. In this way, even in the event of a complete network outage, the terminal can still provide basic, non-real-time dependent services (such as information queries), ensuring the basic availability of the device in harsh network environments.

[0035] S102. The front-end self-service terminal detects the identity input information through different hardware driver interfaces to obtain the patient identity session within the current business cycle. The patient identity session includes an encrypted patient identifier and a valid session timestamp. The identity input information includes one or more of the following: magnetic stripe card, ID card, medical insurance electronic voucher QR code, and heterogeneous face format.

[0036] Among them, the hardware driver interface refers to the software interface used to communicate with various physical card readers, scanners and other hardware devices built into the self-service machine, which is usually provided by the hardware manufacturer in the form of SDK or API; identity input information refers to the original physical or digital credentials provided by the user to prove their identity; the current business cycle refers to the entire time period from when the user starts to authenticate on the self-service machine to when they complete all operations and exit or the session times out; the patient identity session is a temporary digital credential object created in memory that represents the currently logged-in user; the encrypted patient identifier is a string of encrypted data that uniquely points to the patient's file in the hospital (such as an encrypted patient ID or national ID number) to prevent it from being directly read in network transmission or memory; the session validity timestamp records the creation time and preset expiration time of the session, which is used to implement the automatic exit function upon timeout; heterogeneous format refers to the fact that different identity credentials have different data structures, encoding methods and verification logic.

[0037] Specifically, when the front-end interface guides the user through identity verification, the front-end application listens to all integrated hardware driver interfaces in parallel. Whether the user swipes their medical insurance card, places their ID card in the reading area, or scans the QR code of their electronic medical insurance voucher on their phone, the corresponding hardware driver captures the raw data (such as card magnetic stripe information, ID card chip data, QR code string, etc.). The application then calls the appropriate parsing and verification logic based on the data source. For example, it might send the ID card data to the Ministry of Public Security interface for verification, or interact with the medical insurance voucher data with the medical insurance platform for verification. Once identity verification is successful, the application extracts the patient's unique ID in the hospital from the verification result, encrypts it to generate an encrypted patient identifier, and combines this with the current system time and a preset session duration (e.g., 300 seconds) to generate a valid session timestamp. Finally, it encapsulates these two core pieces of information into a standard "patient identity session" object, stores it in memory, and uses it as the unique identity credential for all subsequent user operations.

[0038] In some embodiments, each hardware driver is encapsulated as an independent background service. These services continuously monitor the hardware status, and once data is read, they encapsulate the raw data along with the device type into an "identification event" and publish it to an internal message bus (such as using .NET's MassTransit or Azure ServiceBus). Secondly, a dedicated "identity authentication service" subscribes to all these events. Finally, when the "identity authentication service" receives any event, it dispatches it to the corresponding processing logic for verification based on the device type in the event. Upon successful verification, a patient identity session is generated, and the UI main thread is notified via another "session created" event; this is not limited to specific events.

[0039] S103. After verifying the validity of the patient's identity session, the front-end self-service terminal receives the business instruction.

[0040] Receiving business instructions refers to responding to a user's click behavior on the user interface (such as clicking the "register" button) and preparing to start executing the corresponding business process.

[0041] Specifically, after a patient identity session is successfully created in S102, the user enters a logged-in state and can see all the operable function entries on the interface. When the user clicks any button (such as "Outpatient Payment"), the front-end application does not immediately redirect to the payment page. Instead, it first performs a pre-verification operation. This operation checks whether a valid patient identity session object exists in memory. If it does not exist (for example, the session failed to be created in a previous step), or if it exists but the session has expired by comparing its "session validity timestamp" with the current system time, the subsequent process is immediately interrupted, and the user is forcibly redirected to the initial identity authentication interface, requiring the user to log in again. Only after confirming the existence of a valid, unexpired patient identity session will the current user be deemed legitimate and authorized, and the business instruction represented by the user's click behavior will be formally "received," thus initiating the invocation of the business processing module related to that instruction.

[0042] S104. The front-end self-service terminal encapsulates the business instructions along with the associated session information into business data to be processed. The business instructions include one or more of the following: registration, payment, admission registration, or hospitalization renewal.

[0043] Encapsulation refers to the process of combining and packaging multiple data of different types and sources according to a predefined, unified structure; the business data to be processed is a standardized data packet (DataTransferObject, DTO), which serves as a "task order" and contains all the information required to execute a complete backend business; the content of the business instruction clarifies the specific task type of this "task order".

[0044] Specifically, this step is the "packaging" stage before the front-end and back-end exchange data. After S103 confirms the user's identity and receives their business instructions (for example, the user clicked "Appointment Registration" and selected a specific doctor and time), the front-end application does not directly send fragmented data such as department IDs and doctor IDs to the back-end. Instead, it initiates a packaging process. This process creates a new pending business data object. It fills the data payload of this object with the specific content of the business instructions (such as the business type code "Register," and parameters such as the department ID and doctor's scheduling ID required for registration). Secondly, and most importantly, it retrieves a valid patient identity session object from the current memory and fills the authentication part of this object with the encrypted patient identifier and other session information. Finally, a unified and complete data packet is formed.

[0045] As can be seen, by requesting and loading interface configuration data from the backend management platform when the front-end self-service terminal starts up, and then constructing the user interface based on this data, the decoupling of the front-end interface display and the backend business logic is achieved. This decoupling means that adjustments to interface elements such as function entry points and theme colors no longer require modification and redeployment of the front-end application, but are transformed into simple modifications to the backend configuration files. Secondly, based on this, by integrating multiple hardware driver interfaces, identity input information from different sources is uniformly processed into a patient identity session that spans the entire business cycle. This session becomes the core credential connecting all business instructions. This approach offers both flexibility and maintainability, while providing complete and unified cross-business (outpatient and inpatient) process services.

[0046] In practical use, while dynamically constructing the front-end UI by loading interface configuration data improves the deployment flexibility of a single terminal, the lack of standardized constraints on the interface layout and interaction logic of different terminals in the special scenario of hospitals leads to session security risks caused by differences in user operating habits. For example, when a patient becomes accustomed to the UI of Hospital A and then switches to a terminal of Hospital B with a different interface layout, they are easily misled by their existing experience and leave the device without explicitly logging out, resulting in a still valid patient session being unintentionally retained. Subsequent users can then directly operate on this residual session without triggering the authentication process, leading to the execution of incorrect business instructions in the name of the previous user. This implicit session misuse caused by inconsistent interfaces not only poses a risk of patient privacy leakage and medical data corruption but also triggers subsequent transaction disputes and trust crises.

[0047] Therefore, in some embodiments, after step S102, the method further includes: Please see Figure 2 , Figure 2 This is another flowchart illustrating the implementation method of the .NET-based smart healthcare self-service query terminal device in this application embodiment; S201. The front-end self-service terminal uses identity input information to obtain local medical data and external medical data.

[0048] Local medical data refers to historical medical information related to the current patient's identity that is stored in the local persistent storage medium of the front-end self-service terminal, such as past medical records or report summaries cached to improve performance; external medical data refers to the latest medical information that needs to be retrieved from external systems via the network.

[0049] Specifically, the front-end self-service terminal uses the encrypted patient identifier from the patient's session to concurrently initiate two data acquisition processes: First, it queries the local built-in database or file cache to find "local medical data" left by the same patient during previous logins that has not yet expired, in order to quickly load some frequently used information; second, and more importantly, it initiates a series of API requests to the backend server via the network. The backend server then queries multiple "external medical data" sources such as HIS and LIS based on these requests, pulling all the latest and most comprehensive medical data for the patient, such as pending bills, newly generated examination reports, and available appointment slots. Ultimately, the data from these two sources is aggregated, preparing the data for building a complete user business context.

[0050] S202. The front-end self-service terminal caches and binds local medical data and external medical data with the patient's identity session.

[0051] Cache binding refers to establishing a strong, one-to-one correspondence between the medical data set obtained in the previous step and the currently active patient identity session object in the memory of the front-end self-service terminal. This binding ensures that throughout the entire lifecycle of the current session, all access to the patient's medical data can be quickly and accurately located through this session credential, without the need for repeated queries.

[0052] S203. Extract the current context vector from the business instruction; S204. Calculate the matching degree between the current context vector and the vectors of local medical data and external medical data; and determine whether the matching degree calculation result between the current context vector and the vector of any data is higher than the preset matching degree threshold. S205. If the matching degree is higher than the preset threshold, it is determined to be a continuous operation, and S104 is executed. S206. If the matching degree is not higher than the preset threshold, it is determined to be a non-continuous operation. The current interface and data are saved, and the user operation interface is refreshed.

[0053] Here, the current context vector refers to the structured and vectorized representation of the target and content of the user's current business instruction (S103), representing what the user "wants to do now"; the "vector of data in local medical data and external medical data" refers to the business context vector bound to the patient's identity session in S202, representing what to-do items the patient "has in the past and present"; the matching degree calculation is an algorithm used to quantify the logical correlation between the aforementioned two vectors; the matching degree threshold is a preset value used as a dividing line to judge whether the correlation degree is high enough; continuous operation indicates that the current operation is considered to be a normal operation that conforms to the user's historical behavior logic; discontinuous operation indicates that the current operation is considered abnormal, disconnected from the user's historical behavior logic, and may be an operation misused by others.

[0054] Specifically, after a user issues a business instruction, it is not executed immediately. First (S203), the instruction (e.g., "book an orthopedic appointment") is converted into a standardized "current context vector". Then (S204), the "business context vector" representing all to-do items and history of the patient, bound in S202, is retrieved from the current session, and these two vectors are input into a matching degree calculation model. This model calculates a similarity score based on preset medical business rules (e.g., after seeing a doctor in department A, the next step is to pay for medication in department A, resulting in a high matching degree; after seeing a doctor in department A, suddenly booking an appointment in an unrelated department B results in a low matching degree). Finally (S205 / S206), this score is compared with a preset "matching degree threshold". If the score is high enough, it indicates that the current operation is "reasonable", is judged as a "continuous operation", and is allowed to continue the normal business encapsulation process of S104. Conversely, if the score is very low, it is assumed that this is likely not the user's operation, and it is judged as "discontinuous operation". Safety measures are then implemented - the current work status is saved immediately, and the interface is forcibly refreshed to interrupt the abnormal process.

[0055] In some embodiments, both the "business context vector" and the "current context vector" are represented as multi-dimensional vectors composed of medical keywords (such as department names, drug names, and examination item names), with the value in each dimension being the TF-IDF weight or business importance weight of that keyword. Next, in S204, a cosine similarity algorithm is used to calculate the cosine value of the angle between the two vectors; this value is the matching score (ranging from 0 to 1). Finally, in S205 / S206, the calculated cosine value is compared with a preset threshold (such as 0.6); a value greater than this threshold indicates continuity, while a value less than this threshold indicates discontinuity; no specific limitation is imposed here.

[0056] In other embodiments, all of the patient's medical actions are constructed in the background into a time-based knowledge graph, where each medical event (such as registration, prescription, and payment) is a node. Secondly, in S204, the "business context vector" represents the most recent nodes in the graph, and the "current context vector" represents a new node the user wants to create. The matching degree calculation is then transformed into a graph path analysis problem: calculating the "logical distance" or "transition probability" from a historical node to this new node. For example, the probability of moving from the "cardiology consultation" node to the "pay cardiology medication" node is high, while the probability of moving to the "orthopedics appointment" node is low. Finally, this probability value is the matching degree score, which is used to make decisions in S205 / S206, without limitation here.

[0057] As can be seen, after creating a patient identity session, the system further utilizes this session to acquire and cache medical data related to the patient's identity. Based on this, when a new business instruction is received, it is no longer executed unconditionally. Instead, the system first extracts the current context vector and calculates its matching degree with the previously cached medical data. This calculation process is essentially an implicit verification of the logical consistency between the current operation and the patient's historical behavior. It no longer relies on the user's active actions or additional verification steps, but identifies anomalies by analyzing the rationality of the business behavior itself. Ultimately, this achieves the identification and interception of high-risk scenarios such as "session misuse by others" without sacrificing a smooth user experience, thus improving account security and data privacy protection in public self-service device environments.

[0058] In some preferred embodiments, another implementation of step S206 is as follows: Please see Figure 3 , Figure 3 This is another flowchart illustrating the implementation method of the .NET-based smart healthcare self-service query terminal device in this application embodiment; S301. The front-end self-service terminal obtains local behavior data within the current business cycle; S302. The front-end self-service terminal uses local behavioral data to retrieve potential instruction intent sets according to preset medical business logic rules; S303. Determine whether the business instruction conforms to any instruction intent in the potential instruction intent set; S304. If it does not meet the requirements, it is determined to be a non-continuous operation. The current interface and data are saved, and the user interface is refreshed. S305. If the condition is met, it is determined to be a continuous operation, and S104 is executed.

[0059] Local behavioral data refers to the collection of all successful or interrupted operations recorded by the user within the lifecycle of the current patient session. It is a dynamically generated log that records "what just happened". Medical business logic rules are a series of predefined rules that simulate the sequence and relationships of medical processes in the real world (e.g., "Rule 1: Payment or examination order is usually generated after a consultation"). Potential instruction intent set is a list derived from the aforementioned rules that predicts the user's most likely next action.

[0060] Specifically, this set of steps describes how, when an operation is initially determined to be "discontinuous" in S206, the process is not immediately terminated abruptly, but rather a more refined "fault-tolerant recovery" mechanism is initiated. First (S301), all user behavior records during the current session are retrieved. Then (S302), these behavior records are used as input to match the "medical business logic rules" library. For example, if the behavior records show that the user has just viewed the introduction of a "cardiologist," the rule library will infer that their next step is likely to be "booking an appointment with this doctor," thus generating a "potential instruction intent set" containing "booking an appointment with this doctor." Next (S303), the business instruction currently issued by the user and determined to be "discontinuous" is compared with this newly generated intent set. If (S305) finds that the instruction happens to be within this intent set (for example, the user did indeed click to book an appointment with the doctor), it considers the previous "discontinuous" judgment to be a misjudgment, possibly due to user hesitation or network fluctuations. Therefore, it "forgives" this operation, restores it to a "continuous operation," and continues to execute S104. Conversely (S304), if the instruction is completely inconsistent with the intent set, it finally confirms that this is a genuine abnormal operation and maintains the "discontinuous" judgment.

[0061] In some embodiments, the patient's medical process is abstracted as a Functional Management System (FSM), where each state represents a business node (e.g., "Logged in," "Selected Department," "Pending Payment"), and each state transition represents a valid operation. Secondly, in S302, the "potential instruction intent set" is the set of operations corresponding to all possible outgoing state transitions in the current state. For example, if the current state is "Selected Department," then valid transition operations are "Select Doctor" or "Return to Previous Step." Finally, in S303, it is determined whether the user's business instruction corresponds to a valid state transition. If valid, the state transition is executed, and the operation is considered continuous; if invalid, it is considered discontinuous.

[0062] In other embodiments, a Markov chain model is constructed by analyzing massive amounts of historical user behavior data. This model calculates the transition probability of the next specific medical action following any given medical action. Secondly, in S302, when an operation is interrupted, the previous action is used as the current state. The Markov model is then searched for all subsequent actions with a transition probability greater than a certain threshold (e.g., 0.1). These actions constitute a "potential instruction intent set." Finally, in S303, it is determined whether the user's business instruction is within this set, and based on this, a decision is made whether to resume it as a continuous operation; this is not limited here.

[0063] As can be seen, after determining an operation to be "discontinuous," the system further utilizes existing local behavioral data to search the medical business logic rule base to generate a set of potential instruction intents predicting the user's most likely next action. It does not directly classify user hesitation or erroneous operations as malicious behavior. Based on this, when the user issues a business instruction again after a preset time, it is compared with this set of potential instruction intents. This provides a secondary screening capability when facing abnormal operations. It effectively intercepts genuine abnormal operations while avoiding "false positives" caused by user unfamiliarity with the operation or network latency, improving usability and user-friendliness while ensuring security.

[0064] Understandably, in step S102, the patient identity session is limited to the "current business cycle," which is sufficient for handling tasks that are completed immediately. However, in the medical context, there are many inherently discontinuous long-cycle medical tasks that require multiple calendar days to complete, such as "retrieving reports for a follow-up visit the next day" or "paying for phased treatment." Strictly adhering to the "current business cycle" limitation would prevent patients from accessing to-do items generated in the previous cycle that are closely related to the current task when creating a new session on a subsequent visit day, thus causing a disruption in the business process.

[0065] In some embodiments, after step S201, the method further includes... S401. The front-end self-service terminal obtains the patient's identity session and related matters from the local medical data in the previous business cycle. S402. The front-end self-service terminal determines whether there are any unfinished pending items among the associated items; S403. If there are unfinished to-do items, associate the to-do items with the patient identity session in the current business cycle.

[0066] The previous business cycle refers to a complete or interrupted medical process that occurred in the past (usually the next day or earlier) with the same identity subject as the current patient's identity session; related matters refer to all medical records generated by the patient in the previous business cycle, such as registration records, prescriptions, examination orders, etc.; unfinished pending matters refer to those matters that have been generated but have not yet completed the subsequent key steps, such as examination orders that have been issued but not yet paid for, or appointment numbers that have been booked but have not yet been picked up.

[0067] Specifically, in the data acquisition phase (S201), after identifying a new business cycle (e.g., by comparing the login time with the last login time), a special process is triggered. First (S401), it retrieves the user's previous or most recent medical records (i.e., "related items" from the "previous business cycle") from the local or backend data source based on the current user's identity information. Then (S402), it performs status analysis on these retrieved historical items, determining whether they are in an "incomplete" state. For example, it checks whether the payment status field of a prescription is "pending payment," or whether the appointment date of an appointment record is "today." Finally (S403), if any "incomplete pending items" are found, it doesn't simply display them; instead, it performs a crucial "association" operation: injecting these pending items from the past into the context of the newly created patient identity session in the data structure, making them part of the current session that can be legally accessed and manipulated.

[0068] In some embodiments, at the end of each business cycle, the frontend encrypts and stores all unfinished tasks from that cycle, along with their status, in the browser's or application's local database, indexed by the patient ID. Next, when S401 is triggered, the frontend first queries the local database using the current patient ID to quickly load historical to-do items. Then, to ensure the data is up-to-date, it asynchronously sends a "to-do item synchronization" request to the backend to obtain the status of tasks that may have changed during offline periods. Finally, the frontend performs the association operation in S403 on the final to-do item list after local loading and network synchronization; this is not limited to specific steps.

[0069] As can be seen, when a significant gap (e.g., spanning multiple days) is identified between the current and previous business cycles, a cross-cycle context inheritance step is triggered, proactively retrieving the historical business context of the previous cycle (especially any unfinished tasks). These inherited tasks are then further associated with the patient's session within the current business cycle. This combines multiple previously fragmented and isolated medical cycles into a coherent and complete medical journey at the data and logical levels. This facilitates long-cycle medical procedures such as "reports picked up the next day" and "follow-up visits every other week."

[0070] It should be noted that, in actual use, the context inheritance scheme for ensuring the continuity of long-cycle services as defined in steps S401-S403, and the intent recovery scheme for handling short-term operation interruptions as defined in steps S301-S305, have potential logical conflicts when applied to cross-cycle scenarios. The "cross-cycle context inheritance" mechanism (S401-S403) aims to handle the continuity of long-cycle services measured in "days," for example, ensuring that patients can see the "CT report to be printed" to-do item when logging in the next day. The "non-continuous operation fault tolerance recovery" mechanism (S301-S305), on the other hand, is intended to handle short-cycle operation hesitation measured in "seconds" or "minutes." It "forgives" users who continue to perform related operations after a brief period of thought by generating a "potential instruction intent set."

[0071] Problems arise when these two mechanisms operate in the same scenario. When a patient logs in the next day, the system loads yesterday's "CT report to be printed" context through an "inheritance" mechanism and generates a "potential instruction intent set" based on this, predicting that the user will "print the report." However, if the patient's primary goal today is to handle a completely new, higher-priority task unrelated to yesterday (e.g., registering for an emergency appointment), then this "register for an emergency appointment" instruction will inevitably mismatch with the "instruction intent set" based on yesterday's history.

[0072] At this point, the short-cycle "fault tolerance and recovery" mechanism might mistakenly overstep its authority, classifying this perfectly reasonable long-cycle new business as a "discontinuous operation" and executing interruption processes such as refreshing the interface. As a result, a "inheritance" mechanism intended to provide convenience and a "recovery" mechanism designed to improve fault tolerance, when combined, unexpectedly create a situation where "users must process old tasks first," thus depriving them of the right to freely prioritize their business on the new appointment day.

[0073] Therefore, in some embodiments, the method further includes the following step before step S403: S501. The supplementary instruction intent set will be obtained by retrieving the historical behavior data corresponding to the to-do items in the preset medical business logic rules. S502. Add the supplementary instruction intent set to the instruction intent set.

[0074] Among them, the historical behavior data corresponding to the to-do items refers to the behavior records that have occurred in the previous business cycle and are directly related to the "unfinished to-do items" inherited from S403 (for example, in order to issue this "CT scan bill to be paid", the patient must have had the two historical behaviors of "visiting a doctor" and "the doctor issuing a bill"); the supplementary instruction intent set is a predictive operation list derived from these historical behaviors and the to-do items themselves, specifically for how to handle these "old tasks".

[0075] Specifically, this set of steps describes how, after successfully inheriting historical to-do items, this historical information is used to enhance its "intelligence" to better guide users in completing these cross-cycle tasks. First (S501), the "to-do items" associated with the current session in S403 are retrieved. For each to-do item, it not only sees the item itself but also traces back the related "historical behavior data." Then, it combines this information and inputs it into the "medical business logic rules" library for inference. For example, if the to-do item is "CT report to be printed," and its historical behavior is "CT examination completed," then the rule library will infer that the user's most likely next action is "to print this CT report," thus generating a "supplementary instruction intent set" containing "print CT report." Finally (S502), this "supplementary instruction intent set" inferred from history is merged with the "potential instruction intent set" that may have already been generated in S302 based on the current cycle behavior.

[0076] In some embodiments, an intent generation rule template is predefined for each type of "to-do item". For example, the template defined for "prescriptions pending payment" is: "If the prescription is not paid, generate an intent to 'pay'; if the prescription has been paid but the medication has not been picked up, generate an intent to 'pick up'". Next, in S501, all inherited to-do items are iterated over, and based on their type and current state, the corresponding rule template is matched, and the template is executed to generate the corresponding instruction intent, forming a "supplementary instruction intent set". Finally, in S502, this newly generated intent set is combined with the original intent set using a simple union operation to remove duplicates; this is not limited here.

[0077] As can be seen, after associating to-do items with the current patient's session, the inherited to-do items and their corresponding historical behavior data are further utilized to retrieve data from the medical business logic rules, generating a supplementary instruction intent set. This supplementary instruction intent set is then merged with the instruction intent set generated in the current cycle. This ensures that when making subsequent intent judgments, the "view" is no longer limited to the behavior of the current cycle, but extends to a global view including historical key tasks. This avoids the rigidity of the process that may result from simple inheritance.

[0078] In some embodiments, after step S103, the method further includes: S601. When the business instruction is to process hospital admission, the front-end self-service terminal uses the patient's identity session to retrieve the admission information and guides the user to pay the hospital deposit. S602. The backend management platform generates an electronic hospitalization certificate corresponding to the patient's identity session. The electronic hospitalization certificate serves as an index to query and display the patient's hospitalization expense list on the front-end self-service terminal, and connects to the front-end self-service terminal for self-service renewal and top-up of the hospitalization account.

[0079] Here, "pending admission information" refers to an electronic admission notice or hospitalization certificate issued by a doctor, containing the patient's basic information, the proposed department, and diagnosis results; "hospitalization deposit" is a prepayment by the patient to cover potential expenses during hospitalization; "electronic hospitalization certificate" is a globally unique digital identifier (such as a UUID containing the hospitalization number) generated by the backend for the patient's current hospitalization, replacing the traditional physical wristband or paper hospitalization form at the data level, becoming a "digital key" linking all hospitalization activities; "index" refers to using the electronic hospitalization certificate to quickly locate and retrieve all records related to the current hospitalization during database queries; "connectivity" here indicates a collaborative process, where the backend provides the data interface, and the frontend is responsible for the interface display and user interaction, working together to complete a function.

[0080] Specifically, when a user selects the "Admission" command on the self-service machine, the front-end application uses the currently valid patient identity session to request the patient's admission information from the back-end. This information is clearly displayed on the interface for the user to verify. After confirmation, the user is guided to pay a specified hospitalization deposit via scanning a QR code. Upon successful payment (S602), a crucial step in the process is triggered: the back-end management platform creates a record for this admission event in the database and generates a unique electronic hospitalization certificate, binding this certificate to the current patient identity session. From this moment on, this electronic hospitalization certificate becomes the "master switch" for the patient's hospitalization. During the subsequent hospitalization period, whether checking daily expenses, printing bills, or renewing the hospitalization account, the front-end will use this electronic hospitalization certificate as the core index to request data and initiate operations from the back-end, thereby achieving closed-loop management of all hospitalization-related services on a single self-service machine.

[0081] As can be seen, when the business instruction is to admit a patient, after completing the admission registration and deposit payment, the backend server generates an electronic hospitalization certificate corresponding to the patient's identity session. This becomes a unique digital identity index throughout the entire hospitalization period. Based on this, all subsequent operations during hospitalization, such as fee inquiries and renewals, use this electronic hospitalization certificate as an index. This collaborative mechanism anchors multiple hospitalization business processes that were originally scattered at different times and required repeated identity verification onto a single digital certificate.

[0082] In some embodiments, after step S104, the method further includes: S701. Perform access control verification based on preset roles on the operation requests of the backend administrator through the backend management platform; S702. After successful verification, the backend management platform sends a remote control command to the designated frontend self-service terminal. S703 enables the front-end self-service terminal to call its internal pre-installed hardware manufacturer SDK to perform a health status self-check on the hardware components and construct a device status diagnostic data from the self-check results. S704, sent back to the backend management platform.

[0083] Here, "backend administrator" refers to the IT operations and maintenance personnel responsible for information maintenance and management in the hospital; "operation request" refers to various maintenance commands initiated by the administrator through the backend management interface, such as "restart device" and "test printer"; "Role-Based Access Control (RBAC)" is a security model that assigns permissions to "roles" (such as "administrator" and "regular operations and maintenance personnel"), and then assigns roles to users, thereby achieving refined and centralized management of permissions; "remote control command" is a data packet sent from the backend to the frontend, containing the target device ID and the code for the specific task to be executed; "hardware vendor SDK" is a software development kit provided by hardware manufacturers to facilitate interaction between developers and their devices, encapsulating the underlying hardware communication protocols; "hardware accessories" refers to the physical components inside the self-service machine, such as printers, card readers, and cameras; "device status diagnostic data" is a structured report that includes information such as the hardware's health status code (such as "normal", "out of paper", "paper jam"), device serial number, and testing time.

[0084] Specifically, when a backend administrator attempts to perform any remote maintenance operation, the permission management module of the backend management platform intercepts the request. It checks the currently logged-in administrator's role and checks whether that role has been granted permission to perform the operation. For example, a "regular maintenance worker" might only have permission to "query status," while an "administrator" has permission to "remotely restart." Only after permission verification is successful can the process continue. Then (S702), after obtaining authorization, the remote maintenance management module generates an encrypted remote control command based on the administrator's instructions and pushes it precisely to the target front-end self-service terminal via the network (such as using real-time communication technologies like SignalR). Next (S703), after receiving the command, the front-end application parses the task to be executed (such as "detect printer") and calls the pre-built functions in the hardware vendor SDK provided by the corresponding printer manufacturer. The SDK communicates directly with the hardware, queries its internal status register, and obtains underlying information such as "paper sensor status" and "ink cartridge level." The front-end then organizes and encapsulates this raw information into standardized device status diagnostic data. Finally (S704), the front end sends this diagnostic data packet back to the back end management platform. After receiving it, the platform displays it on the operation and maintenance monitoring screen in a graphical way (such as green light indicating normal and red light indicating fault), so that the administrator can have a clear understanding of the real-time health status of all devices.

[0085] As can be seen, when performing backend maintenance tasks, the backend management platform performs role-based access control verification on administrator operation requests, ensuring the legitimacy and traceability of operations. Based on this, only after successful verification is a remote control command sent to the designated front-end self-service terminal, triggering it to call the hardware vendor's SDK to perform a health status self-check and return device status diagnostic data. This achieves a dual improvement in operational efficiency and security level.

[0086] The following describes an exemplary .NET-based smart healthcare self-service query terminal device 400 provided in an embodiment of this application. Figure 4 This is an exemplary hardware structure diagram of the .NET-based smart healthcare self-service query terminal device 400 provided in this application embodiment.

[0087] In some embodiments, the .NET-based smart healthcare self-service query terminal device 400 is a computer device or includes a computer device. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores data. The network interface of the computer device is used to communicate with other external terminals or servers via a network connection. In some embodiments, the network interface can be a wired network interface; in some embodiments, the network interface can also be a wireless network interface. When the computer program is executed by the processor, it implements the methods in the embodiments of this application.

[0088] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0089] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0090] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if..." or "after..." or "in response to determining..." or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining..." or "in response to determining..." or "when (the stated condition or event) is detected" or "in response to detecting (the stated condition or event)".

[0091] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0092] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.< / color> < / button>

Claims

1. A method for implementing a smart medical self-service query terminal device based on .NET, characterized in that, include: When the front-end self-service terminal starts up, it requests and loads interface configuration data from the back-end management platform, and constructs the user interface based on the interface configuration data. The interface configuration data is obtained by the back-end management platform by parsing the configuration file. The interface configuration data includes a structured instruction set of front-end function entry points, interface theme color codes, and layout coordinate parameters. The front-end self-service terminal detects the identity input information through different hardware driver interfaces to obtain the patient identity session within the current business cycle. The patient identity session includes an encrypted patient identifier and a valid session timestamp. The identity input information includes one or more of the following: magnetic stripe card, ID card, medical insurance electronic voucher QR code, and heterogeneous face format. After verifying the validity of the patient's identity session, the front-end self-service terminal receives the business instruction; The front-end self-service terminal encapsulates the business instructions along with associated session information into business data to be processed. The business instructions include one or more of the following: registration, payment, hospital admission registration, or hospitalization renewal.

2. The method according to claim 1, characterized in that, After the front-end self-service terminal detects the identity input information through different hardware driver interfaces to obtain the patient's identity session within the current business cycle, the method further includes: The front-end self-service terminal uses the identity input information to obtain local medical data and external medical data; The front-end self-service terminal caches and binds the local medical data and the external medical data with the patient's identity session; After the step of receiving the service instruction: Extract the current context vector from the business instruction; The matching degree of the current context vector with the vectors of the local medical data and the external medical data is calculated; and it is determined whether the matching degree calculation result of the current context vector with the vector of any data is higher than the preset matching degree threshold. If the value exceeds the preset matching threshold, it is determined to be a continuous operation, and the front-end self-service terminal will encapsulate the business instruction along with the associated session information into business data to be processed. If the matching degree is not higher than the preset threshold, it is determined to be a non-continuous operation, the current interface and data are saved, and the user operation interface is refreshed.

3. The method according to claim 2, characterized in that, The steps of determining that if the matching degree is not higher than a preset threshold, it is a discontinuous operation, saving the current interface and data, and refreshing the user interface specifically include: The front-end self-service terminal acquires local behavior data within the current business cycle; The front-end self-service terminal uses the local behavioral data to retrieve a set of potential instruction intents based on preset medical business logic rules; Determine whether the business instruction conforms to any instruction intent in the instruction intent set; If it does not meet the requirements, it is determined to be a non-continuous operation, the current interface and data are saved, and the user operation interface is refreshed; If the conditions are met, it is determined to be a continuous operation, and the step of encapsulating the business instruction along with the associated session information into business data to be processed by the front-end self-service terminal is executed.

4. The method according to claim 3, characterized in that, After the step of the front-end self-service terminal using the identity input information to obtain local medical data and external medical data; The front-end self-service terminal obtains the patient's identity sessions and associated matters from the local medical data within the previous business cycle; The front-end self-service terminal determines whether there are any unfinished pending items among the associated items; If there are unfinished tasks, then those tasks are associated with the patient identity session within the current business cycle.

5. The method according to claim 4, characterized in that, Following the step of associating the to-do items with patient identity sessions within the current business cycle, the method further includes: The supplementary instruction intent set will be obtained by retrieving historical behavior data corresponding to the pending items in the preset medical business logic rules; Add the supplementary instruction intent set to the instruction intent set.

6. The method according to claim 1, characterized in that, After the front-end self-service terminal verifies the validity of the patient's identity session and receives the business instruction, the following steps are also included: When the business instruction is to apply for hospital admission, the front-end self-service terminal uses the patient's identity session to retrieve the admission information and guides the user to pay the hospital deposit. The backend management platform generates an electronic hospitalization certificate corresponding to the patient's identity session; the electronic hospitalization certificate serves as an index to query and display the patient's hospitalization expense list on the front-end self-service terminal, and connects to the front-end self-service terminal for self-service renewal and top-up of the hospitalization account.

7. The method according to claim 1, characterized in that, After the step of the front-end self-service terminal encapsulating the business instruction along with the associated session information into business data to be processed, the method further includes: The backend management platform performs access control verification based on preset roles for the operation requests of the backend administrator; After successful verification, the backend management platform sends a remote control command to the designated frontend self-service terminal; the frontend self-service terminal calls its internal pre-installed hardware manufacturer SDK to perform a health status self-check on the hardware components, and constructs a device status diagnostic data set from the self-check results; and sends it back to the backend management platform.

8. A smart medical self-service query terminal device based on .NET, characterized in that, The .NET-based smart healthcare self-service query terminal device includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the .NET-based smart healthcare self-service query terminal device to perform the method as described in any one of claims 1-7.

9. A computer program product containing instructions, characterized in that, When the computer program product is run on a .NET-based smart healthcare self-service query terminal device, the .NET-based smart healthcare self-service query terminal device performs the method as described in any one of claims 1-7.

10. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is run on a .NET-based smart healthcare self-service query terminal device, the .NET-based smart healthcare self-service query terminal device performs the method as described in any one of claims 1-7.

Images