One-code multi-service method and system in medical scene

Abstract

The invention relates to a one-code multi-service method and system in a medical scene, and the method comprises the steps: dynamic code generation: generating a visual dynamic code after security processing based on a user identity, a current medical scene code, a service intention, a timestamp and a random number; the dynamic codes are analyzed and verified, format verification, timeliness verification, anti-replay verification and digital signature verification are executed on the obtained dynamic codes, the dynamic codes are analyzed, and an analysis result is obtained; and performing service routing decision and execution, querying a predefined scene-service-authority rule according to the scene and user information in the dynamic coding analysis result, determining a target service of a user, calling a corresponding back-end medical service system interface to receive and perform service response, and finally returning a service result to the user terminal. According to the invention, the convenience, the integration level, the safety and the user experience of medical services can be improved, the operation and maintenance efficiency of the medical services is improved, and the collaborative cost of multiple medical systems is reduced.

Description

Technical Field

[0001] This application relates to the field of medical information technology, and in particular to a method and system for providing multiple services with a single code in a medical setting. Background Technology

[0002] In current medical services, patients generally face the following situations when verifying their identity and accessing services at different service nodes (such as registration, payment, diagnosis and treatment, medication dispensing, report inquiry, and inpatient management): Physical / electronic card credentials based on fixed codes: This is the most common model. Patients typically hold physical medical cards (magnetic stripe cards or IC cards), social security cards, medical insurance cards, or static QR codes on some early-promoted electronic health cards / medical insurance electronic vouchers. The encoded content of these credentials (such as card number, ID card number, and associated ID) is usually fixed and is mainly used by the backend system to query basic patient information or associate a single account through the ID. For example, QR codes are widely used in the healthcare industry for electronic medical record management and quick access to patient information, but in most application scenarios, QR codes are static or semi-static, linking to fixed information query pages or simple application entry points.

[0003] Parallel operation of multiple applications / entry points: To access different types of medical services, patients often need to install and register multiple applications on their mobile phones, such as official apps of various hospitals, unified medical insurance service apps, and third-party health management platform apps. Each app may generate its own temporary business credential code when providing specific services, or require users to log in and verify their identity independently. In this model, the authentication and authorization mechanisms between the various systems are usually independent.

[0004] Limited attempts at unified code access or integration: Some regions or large medical institutions have begun to try integrating multiple services into a single electronic voucher. However, in practical applications, the service coverage, scenario adaptability, and dynamism of these unified code access solutions are often limited. In most cases, even with a unified entry code, the service it points to may still rely on complex backend logic, manual intervention, or secondary selection by the user on the front end, making it difficult to achieve truly dynamic service adaptation and seamless switching based on real-time scenarios.

[0005] The technological foundation of these existing solutions mainly relies on backend database queries for fixed IDs, pre-defined static link information, and separate authentication and authorization mechanisms for various business systems. Although artificial intelligence technologies, such as AI applications in the healthcare field, including the use of large models for disease prediction, have begun to penetrate the medical field, there is still considerable room for improvement in the dynamic and intelligent aspects of patient identity authentication and service access credentials.

[0006] Existing technologies have significant limitations in improving the convenience, integration, and security of healthcare services: Insufficient convenience: Throughout the entire medical process, patients still experience many delays, repeated verifications, and manual operations due to issues with credentials, resulting in an overall inadequate medical experience.

[0007] Poor integration: There is a lack of an efficient, unified, and secure identity authentication and data exchange language and channel between different medical service systems (HIS, LIS, PACS, EMR, medical insurance system, etc.).

[0008] There are shortcomings in security considerations: Whether it is the easily copied static code or the multi-application system with numerous account passwords, both bring about information security risks at different levels, such as identity theft and data leakage.

[0009] Limited operational efficiency of medical institutions: Hospitals need to invest resources in maintaining multiple credential management systems and user authentication channels, and the complexity and cost of information system management and upgrades are relatively high.

[0010] These issues are among the main obstacles to achieving deep integration of smart healthcare and Internet+ healthcare, and are also the fundamental driving force for promoting a unified national medical security information service code and breaking through the difficulties of multiple cards coexisting and information barriers in medical services. Therefore, there is an urgent need for a method and system for one code to provide multiple services in medical scenarios. Summary of the Invention

[0011] Based on this, the purpose of this invention is to address the above-mentioned technical problems by providing a method and system for one code to provide multiple services in a medical scenario. This system enables users to be intelligently identified and automatically connected to the corresponding backend medical services by simply scanning or displaying a code in different medical service stages, thereby improving the convenience, integration, and security of medical services.

[0012] To achieve the aforementioned objectives, the first aspect of this application provides a method for providing multiple services with a single code in a medical setting, comprising: Based on the encoding generation request, a predefined encoding generation strategy is obtained to generate a visually dynamic encoding that has been securely processed. The parameters of the encoding generation request include user identity, current medical scenario information, service intent, timestamp, and random number Nonce value. The service intent is a user input parameter. If it is empty, it will be determined based on the current medical scenario information. Perform format verification, timeliness verification, anti-replay verification, and digital signature verification on the acquired dynamic encoding, and then parse it to obtain the parsing results; The system makes service routing decisions and executes the process. Based on the scenario and user information in the dynamic encoding parsing results, it determines the user's target service and calls the corresponding backend medical service system interface to receive the service response. It queries the predefined user-scenario-service-permission rules and determines the service result based on the service response, returning the service result to the user terminal.

[0013] Preferably, the generation of the visual dynamic code specifically includes the following steps: Receive encoding generation requests and parameters and perform legality verification. The encoding generation requests are initiated by the user, pre-generated by the process context-driven system, or triggered by the operation of medical staff. Obtain the encoding generation strategy corresponding to the current medical scenario. The strategy content information includes the encoding version number, validity period, list of allowed embedded data fields, encryption algorithm and its key identifier and validity count, digital signature algorithm and its key identifier and validity count. The core data payload, including user identity, scene code, and service intent, is encrypted and digitally signed according to the encoding generation strategy. The core data after signing, the encoding version number, the issuing organization identifier, and some public scenario prompts are assembled into an encoded string according to a predetermined format and then converted into a visual dynamic encoded image.

[0014] Preferably, the encryption uses the Chinese national cryptographic SM series algorithm or an international standard encryption algorithm, and the digital signature algorithm uses an asymmetric signature algorithm.

[0015] Preferably, the service routing decision and execution step further includes: If the service intent is not explicitly specified in the dynamic encoding parsing result, the target service is inferred based on at least one of the following: scanning device type, default service of the scenario, user session, or user history behavior. If there are multiple target services, then the multiple associated target services are combined, orchestrated, and invoked in sequence.

[0016] Preferably, after the dynamic encoding passes all verifications, the encrypted core data payload is decrypted, and key business information is parsed and extracted according to a predefined structure, including user identity identifier, scene code, timestamp, random number and target service intent information.

[0017] To achieve the purpose of this invention, a second aspect of this application provides a one-code-for-multiple-services system for medical scenarios, used to implement the one-code-for-multiple-services method for medical scenarios described in the above technical solution, the system comprising: The dynamic encoding generation service module is used to obtain a predefined encoding generation strategy based on the encoding generation request and generate a visual dynamic encoding that has been securely processed. The parameters of the encoding generation request include user identity, current medical scenario information, service intent, timestamp, and random number Nonce value. The service intent is a user input parameter. If it is empty, it will be determined later based on the current medical scenario information. The encoding parsing and verification module is used to perform format verification, timeliness verification, anti-replay verification, and digital signature verification on the acquired dynamic encoding and then parse it to obtain the parsing results. The unified service gateway and scheduling module is used to determine the user's target service based on the scenario and user information in the dynamic encoding parsing results, call the corresponding backend medical service system interface to receive the service response, query the predefined user-scenario-service-permission rules, determine the service result based on the service response, and return the service result to the user terminal. The scenario and permission management module is used to store and manage medical scenario information, predefined encoding generation strategies, and predefined scenario-service-permission rules generated during the service process, and provides an interface for other modules to query.

[0018] Preferably, the dynamic encoding generation service module is further configured to: Receive encoding generation requests from user terminals, medical workstations, or self-service devices; It integrates an encoding strategy engine, a cryptographic signature component, and an encoding formatter to generate dynamic encodings that meet the requirements of the encoding generation strategy.

[0019] Preferably, the unified service gateway and scheduling module is further configured to: Provides standard interface adaptation with at least one of the following: Hospital Information System (HIS), Laboratory Information System (LIS), Image Archiving and Communication System (PACS), Electronic Medical Record System (EMR), and Medical Insurance Payment System; It supports service call orchestration, parameter transformation, response aggregation, and unified return.

[0020] Preferably, the scene and permission management module further stores: Medical scenario metadata, including scenario code, applicable device types, and geofencing information; Encoding strategy content information for different scenarios, including validity period, number of uses, encryption algorithm, signature algorithm and embedded fields; Scenario-service mapping rules and user-service-operation permission relationship table.

[0021] Preferably, the system further includes a security and auditing module, used for: Manage encryption keys and signing certificates; Record audit logs for dynamic code generation, usage, and service calls; Provides support for preventing replay attacks and for responding to security incidents.

[0022] Compared with the prior art, the beneficial effects of this invention are: This invention effectively safeguards the security of medical data and service access through dynamic encoding generation and multi-dimensional security verification mechanisms, preventing information leakage and unauthorized access. Context-aware dynamic service routing decisions enable a single, universally applicable code, significantly simplifying patient procedures in different medical scenarios and improving the convenience, real-time performance, integration, security, and user experience of medical services. Simultaneously, the system improves the efficiency of medical service operation and maintenance and reduces the cost of multi-system collaboration through a unified service center and flexible, configurable rule management, providing reliable support for the digital service upgrades of medical institutions. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the steps of a one-code-for-multiple-services method in a medical scenario, as shown in one embodiment. Figure 2 This is a flowchart illustrating a dynamic encoding generation method in one embodiment; Figure 3 This is a schematic diagram of the dynamic encoding parsing and verification process in one embodiment. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of the invention. The following embodiments are used to illustrate the invention but are not intended to limit its scope.

[0025] Example 1 Embodiment 1 of this application provides a method for one code serving multiple services in a medical scenario, such as... Figure 1 As shown, it includes the following steps: S1: Based on the encoding generation request, obtain the predefined encoding generation strategy and generate a visual dynamic encoding that has been securely processed. The parameters of the encoding generation request include user identity, current medical scenario information, service intent, timestamp, and random number Nonce value. The service intent is a user input parameter. If it is empty, it will be determined based on the current medical scenario information. S2: Based on the encoding generation request, generate a securely processed visual dynamic encoding. The parameters of the encoding generation request include user identity, current medical scenario information, service intent, timestamp, and random number Nonce value. The service intent is a user input parameter. If it is empty, it will be determined based on the current medical scenario information. S3: Performs service routing decisions and execution. Based on the scenario and user information in the dynamic encoding parsing results, it determines the user's target service and calls the corresponding backend medical service system interface to receive the service response. It queries the predefined user-scenario-service-permission rules and determines the service result based on the service response, returning the service result to the user terminal.

[0026] Furthermore, the generation of the visual dynamic code specifically includes the following steps: Receive encoding generation requests and parameters and perform legality verification. The encoding generation requests are initiated by the user, pre-generated by the process context-driven system, or triggered by the operation of medical staff. Obtain the encoding generation strategy corresponding to the current medical scenario. The strategy content information includes the encoding version number, validity period, list of allowed embedded data fields, encryption algorithm and its key identifier and validity count, digital signature algorithm and its key identifier and validity count. The core data payload, including user identity, scene code, and service intent, is encrypted and digitally signed according to the encoding generation strategy. The core data after signing, the encoding version number, the issuing organization identifier, and some public scenario prompts are assembled into an encoded string according to a predetermined format and then converted into a visual dynamic encoded image.

[0027] Furthermore, the encryption adopts the Chinese national cryptographic SM series algorithm or the international standard encryption algorithm, and the digital signature algorithm adopts an asymmetric signature algorithm.

[0028] Furthermore, the service routing decision and execution steps also include: If the service intent is not explicitly specified in the dynamic encoding parsing result, the target service is inferred based on at least one of the following: scanning device type, default service of the scenario, user session, or user history behavior. If there are multiple target services, then the multiple associated target services are combined, orchestrated, and invoked in sequence.

[0029] Furthermore, after the dynamic encoding passes all verifications, the encrypted core data payload is decrypted, and key business information is parsed and extracted according to a predefined structure, including user identity identifiers, scenario codes, timestamps, random numbers, and target service intent information.

[0030] Dynamic encoding generation technology: Dynamic encoding generation is one of the core features of this invention, aiming to generate a short-term valid, content- and scene-related, and secure visual credential.

[0031] Dynamic encoding generation trigger mechanism: User-initiated request: When a patient explicitly selects a service on the user terminal (APP or self-service machine), such as clicking the "Register Now", "View My Report", or "Self-service Payment" button, code generation is triggered.

[0032] Service process information drives system pre-generation: After a specific service process node is completed, the system predicts the next step based on the context information of the service process and automatically generates a pending code for the user. For example, after a patient completes online payment, the app automatically displays a dynamic code for pharmacy medication pickup or examination registration.

[0033] Triggered by medical staff operation: After a doctor issues an electronic prescription or examination request at the workstation, he can generate a corresponding medication voucher code or examination registration code for the patient with one click. The patient can check the code on his / her APP or the doctor can print it directly from the workstation.

[0034] Encode the required input information (parameters): User ID: A unique identity ID of the patient that has been authenticated by the system, such as the main index number of the electronic health card, the encrypted ID card number, or the unified user identifier assigned internally by the platform.

[0035] Current medical scenario information (contextual information, such as geographic location, device ID, service type) (SceneContext): Current Medical Scenario Code (SC): A predefined and unique code managed by SPMS that identifies the specific scenario generated by the code, such as MZDT_ZZJ_GH (Outpatient Hall_Self-service Machine Registration) and NKSZS_YSGZT_ZD (Internal Medicine Clinic_Doctor Workstation_Diagnosis).

[0036] Device Identifier / Type (DeviceID / DeviceType): The unique ID (such as self-service machine number, doctor workstation IP / MAC) or type (such as "MobileAPP", "SelfServiceKiosk") of the device that initiated the encoding generation request or will display / read the encoding.

[0037] Location information: The approximate location of the device obtained through GPS, Wi-Fi, or Bluetooth beacons, which can be used to assist in scene judgment or security risk control.

[0038] Service Intent: This refers to the service type. If the user has explicitly requested a specific service, it includes the target service code (TS). If not explicitly requested, it can be empty or a broad service category. The specific service will be inferred by the USGS based on other information in the current medical scenario.

[0039] Timestamp (TM): The current precise time generated by DCGS, used to calculate the validity period of the code and as an important parameter to prevent replay attacks.

[0040] Nonce: A random string or number generated by DCGS to increase the uniqueness of each encoded instance, and effectively prevents replay attacks when combined with timestamps.

[0041] Security parameters (SecurityParams): may include specific session key information used for this encoding and signing, and dynamic key factors bound to the user identity or device (used to enhance the security of the encryption / signing process).

[0042] Example 2 This application's embodiment 2, based on embodiment 1, provides a one-code-for-multiple-services system for medical scenarios, used to implement the one-code-for-multiple-services method for medical scenarios described in embodiment 1. The system includes: The dynamic encoding generation service module is used to obtain a predefined encoding generation strategy based on the encoding generation request and generate a visual dynamic encoding that has been securely processed. The parameters of the encoding generation request include user identity, current medical scenario information, service intent, timestamp, and random number Nonce value. The service intent is a user input parameter. If it is empty, it will be determined later based on the current medical scenario information. The encoding parsing and verification module is used to perform format verification, timeliness verification, anti-replay verification, and digital signature verification on the acquired dynamic encoding and then parse it to obtain the parsing results. The unified service gateway and scheduling module is used to determine the user's target service based on the scenario and user information in the dynamic encoding parsing results, call the corresponding backend medical service system interface to receive the service response, query the predefined user-scenario-service-permission rules, determine the service result based on the service response, and return the service result to the user terminal. The scenario and permission management module is used to store and manage medical scenario information, predefined encoding generation strategies, and predefined scenario-service-permission rules generated during the service process, and provides an interface for other modules to query.

[0043] The dynamic encoding generation service module is further configured to: Receive encoding generation requests from user terminals, medical workstations, or self-service devices; It integrates an encoding strategy engine, a cryptographic signature component, and an encoding formatter to generate dynamic encodings that meet the requirements of the encoding generation strategy.

[0044] The unified service gateway and scheduling module are also configured to: Provides standard interface adaptation with at least one of the following: Hospital Information System (HIS), Laboratory Information System (LIS), Image Archiving and Communication System (PACS), Electronic Medical Record System (EMR), and Medical Insurance Payment System; It supports service call orchestration, parameter transformation, response aggregation, and unified return.

[0045] The scenario and permission management module also stores: Metadata for medical scenarios includes scenario codes, applicable device types, and geofencing information; Information on encoding strategies in different scenarios, including the validity period of the encoding, the number of times it is used, the encryption algorithm used, the signature algorithm, and the embedded fields of the encoding; Scenario-service mapping rules and user-scenario-service-permission rules.

[0046] In addition, the system includes a security and auditing module for managing encryption keys and signing certificates; recording audit logs of dynamic code generation, usage, and service calls; and providing support for replay attack prevention and security incident risk control response. Integrating these security mechanisms ensures end-to-end security and reliability, and supports integration with existing user identity management systems in medical institutions.

[0047] Core module composition: Dynamic Code Generation Service (DCGS) module: It is responsible for dynamically generating codes based on requests (from user terminals or authorization systems). Input parameters include user identification, current medical scenario information (such as department, device ID, service type), target service intent, timestamp, and nonce value. DCGS internally integrates an encoding policy engine (obtaining policies from SPMS), encryption / signature components, and an encoding formatter. The output is an encoded string containing specific information, which is then converted into a visual form (such as a QR code).

[0048] CPVS (Code Parsing and Validation Service) module: Receives encoded information strings submitted from various scanning devices or user terminals. It is responsible for performing format verification, timeliness verification (to prevent the use of expired codes), replay attack prevention verification (based on nonce and timestamp), digital signature verification (to ensure the code has not been tampered with and its source is trustworthy), and data decryption when necessary. After successful parsing, it extracts the payload information carried in the code (such as user ID, scene identifier, service intent indication, etc.).

[0049] Unified Service Gateway / Scheduler (USGS): As the core hub and intelligent brain of the system, it receives information parsed from CPVS and queries the pre-set rule base in the Scenario and Permission Management Module (SPMS) based on this information (especially scenario identifiers and user identities). According to the scenario-service-permission mapping relationship defined in the rule base, USGS dynamically decides which specific interface(s) of the backend healthcare service system(s) the user's code generation request should be routed to. It is responsible for parameter conversion, service call orchestration, and response aggregation and return. This draws on the concept of achieving a unified code across the national medical insurance system using the medical insurance information business coding standard, but is more dynamic and scenario-based in service scheduling.

[0050] Scene and Permission Management Service (SPMS): This is the key configuration center for enabling one code for multiple services and scenario awareness. SPMS is used to store, define, and manage: Metadata of various medical scenario information during the service process (such as scenario code, scenario name, applicable equipment type, geofence, etc.).

[0051] Encoding generation strategies for different scenarios (such as encoding version, encryption level, signature algorithm, validity period, allowed embedded information fields, whether it is valid only once, etc.).

[0052] Scenario-Service Mapping Rules: Defines a list of services that can be activated by scanning a QR code in a specific scenario.

[0053] User-Scenario-Service-Permission Access Control Strategy: Fine-grained management of the operation permissions (such as query, submit, modify, etc.) of different users (or user roles) on specific services in specific scenarios.

[0054] SPMS provides interfaces for DCGS, CPVS, and USGS to query and call.

[0055] In this embodiment 2, as Figure 2 As shown, the dynamic encoding generation process is as follows: S101: Receive request parameters and perform preliminary verification: DCGS receives an encoding generation request from a user terminal or authorized system, containing the aforementioned UserID, SC, DeviceID, TS(), and other parameters. It verifies the validity of the request (e.g., source authentication, parameter integrity).

[0056] S102: Query SPMS to obtain the encoding strategy: Based on the input SC (Scene Code) and possible UserID (User Type), DCGS queries SPMS for the detailed encoding strategy applicable to the current scenario. The strategy includes: encoding version number, validity period (e.g., 60 seconds, 5 minutes, or until the next stage), list of allowed embedded data fields, data encryption algorithm and key identifier (if encryption is required), digital signature algorithm and key identifier, and whether it is valid only once.

[0057] S103: Payload Construction: According to the queried encoding strategy, organize key information such as UserID, SC, TS (or its placeholders / inference factors), TM (generated timestamp), Nonce, and other necessary dynamic information allowed by the strategy (such as part of DeviceID, simplified to-do list prompts) into a structured (such as JSON format or a more compact custom binary format) core data body.

[0058] S104: Data Encryption Processing: If the SPMS policy requires encryption of all or part of the sensitive fields of the core data payload, DCGS will obtain the corresponding encryption key from SAMS (such as a session-based symmetric key or a user / device-related key) and encrypt the specified data using a specified encryption algorithm (such as AES-GCM, SM4-CBC). Encryption aims to protect the privacy of data during encoded transmission.

[0059] S105: Data Signature Processing: To ensure the integrity and immutability of the encoded data, DCGS must digitally sign the core data payload (if it is plaintext, sign it directly; if it is ciphertext, sign it in ciphertext, or use an integrated signature / ciphertext scheme) or its digest (calculated using algorithms such as SM3 or SHA-256). The private key used for signing is securely managed by DCGS (possibly stored in the hardware security module HSM or with signature services provided by SAMS). The signature algorithm is typically an asymmetric algorithm (such as RSA-PSS, ECDSA, or SM2 signature algorithm).

[0060] S106: Assemble the complete encoded string: Encapsulate the signed data (including the original payload or its ciphertext, and the signature value itself), encoding version number, issuing organization identifier, and some public scenario prompts (such as short plaintext identifiers for payment codes and medication pickup codes, excluding sensitive information) into the final encoded string according to a predefined encoding format. This string is the direct content for subsequent conversion into visual encoding.

[0061] S107: Convert to visual encoding: Convert the assembled encoding string into a visual encoding image (such as QR code image data) that can be displayed by the user terminal and read by the scanning device through a standard encoding algorithm (such as QR code generation algorithm, or PDF417 barcode algorithm for large information scenarios).

[0062] Finally, the dynamic encoding is returned: DCGS returns the generated visual encoded image data (or its URL / Base64 representation) and related validity time information to the requester (user terminal or application).

[0063] Coding characteristic analysis: Dynamic nature: A completely new encoding instance is generated with each request (or after a specific time window), or the encoding has a strict and short validity period (such as the dynamic QR code of the medical insurance electronic voucher, which is displayed as a dynamic QR code to ensure security).

[0064] Contextual relevance / self-explanatory nature: The encoded content (or its encrypted / signed portion) directly or indirectly carries the context information (SC) and possible initial service intent (TS) at the time of encoding, enabling the parser to make preliminary context judgments and intelligent routing based on this information.

[0065] Security: Anti-counterfeiting and anti-tampering: The digital signature mechanism ensures that the encoded content is not illegally modified during transmission and display; if core sensitive information is encrypted, it further increases the difficulty of maliciously constructing valid codes.

[0066] Anti-replay attack: The timestamp (TM) and nonce value contained in the encoding, together with the strict timeliness verification and nonce usage status check during parsing by the backend CPVS (usually supported by SAMS), can effectively prevent the same encoding from being intercepted and reused.

[0067] Prevention of misuse after theft: The short validity period of the code and its one-time or limited-use characteristics (configured according to the SPMS policy) greatly limit the misuse value of the code after it is stolen.

[0068] Uniqueness: During its validity period, each generated encoding instance is guaranteed to be unique through timestamps, nonces, and possible serial number mechanisms, which facilitates auditing and tracking.

[0069] Configurability: Through SPMS policy configuration, the validity period of the encoding, the information fields contained, the encryption strength, the signature algorithm, the number of times it can be used and other attributes can be flexibly adjusted in different scenarios to adapt to diverse business needs and security levels.

[0070] Encoding parsing and service routing technologies: Once a user presents a dynamic code and it is read by a scanning device, the system needs to quickly and accurately parse the code content, verify its validity, and intelligently redirect the user's request to the correct backend service based on the parsing results.

[0071] Scanning and Data Collection: Users use the scanning function at various interaction points provided by medical institutions (such as self-service machine scanning ports, external scanners for doctors' workstations, nurse PDAs, and patient mobile apps accessing cameras) to scan dynamic visual codes (such as QR codes) displayed on their personal devices or other equipment. The decoding library built into the scanning device or app is responsible for converting the image information into the original encoded string.

[0072] The encoding parsing and verification process (executed by CPVS), such as... Figure 3 As shown, it includes the following steps: S201: Receive raw encoded string: CPVS receives raw encoded string data from the user terminal or barcode scanning device through a secure interface (such as HTTPS).

[0073] S202: Preliminary Format Verification: CPVS first checks whether the overall format of the encoded string conforms to predefined specifications. For example, it checks whether the version number is supported and whether the issuing organization code belongs to the trusted list. If the format is incorrect, it is rejected directly.

[0074] S203: Timeliness Verification: Extract the encoding generation timestamp TM from the encoded string. CPVS queries SPMS to obtain the current encoding's scenario (SC) or encoding type configuration validity rules (e.g., valid for 60 seconds, valid for the current day, etc.). Combined with the current server time, determine if the encoding has expired. Expired encodings will be rejected, and the user will be prompted to obtain a new one.

[0075] S204: Anti-replay check: Extract the Nonce value from the encoding and / or the unique hash value of the encoding itself. CPVS queries the SAMS (Security and Auditing Module) Nonce / encoding usage record library (usually a time-limited cache or database) to check if the Nonce or encoding hash has been successfully used recently (within a very short time window, e.g., twice the validity period). If the record exists (and the policy is configured for one-time validity or limited use), it is considered a replay attack and the attempt is rejected. Successfully used Nonce / encoding hashes should be recorded.

[0076] S205: Digital Signature Verification: Separate the original data payload and the digital signature value from the encoded string. CPVS obtains the signature verification public key corresponding to the encoding version and issuing authority from SAMS or the local security configuration (this public key is paired with the private key used by DCGS when generating the signature). Using this public key and an agreed-upon signature algorithm (such as RSA-PSS, ECDSA, SM2), the original data payload (or its digest) is verified. If verification fails, it indicates that the encoded content may have been tampered with or that the encoding was not issued by a legitimate DCGS, and CPVS will reject the encoding.

[0077] S206: Data Decryption Processing: If the encoding policy indicates that all or part of the core data payload has been encrypted, CPVS, after successful signature verification, will obtain the corresponding decryption key from SAMS (which may be a symmetric key, or a session key encrypted by the client's public key using the server's private key), and use the specified decryption algorithm (such as AES-GCM, SM4-CBC) to decrypt the ciphertext data, restoring the plaintext core data payload. The process will abort if decryption fails.

[0078] S207: Core Information Extraction and Structured Parsing: After passing all security checks, CPVS parses and extracts key business information from the (potentially decrypted) core data payload according to a predefined structure (such as JSON, binary protocol). This information mainly includes: UserID (user identity identifier), SC (scenario code generated during encoding), TM (original generation timestamp), Nonce value, TS (service intent information), and DeviceID, etc.

[0079] Service routing decision and execution (performed by USGS): S208: Receive parsing results and make service routing decisions: USGS obtains verified and parsed structured core information (UserID, SC, TS, etc.) from CPVS.

[0080] Querying Services and Permission Policies: Based on the parsed SC (the actual scenario the user scanned, which may be the same as or different from the SC generated during encoding, depending on the business design) and UserID, USGS initiates a user-scenario-service-permission rule query request to SPMS. SPMS returns a list of services associated with the current SC, default services, and the specific operation permissions of the UserID for these services under the current SC (such as whether registration, report retrieval, and payment are allowed).

[0081] Target service identified: If the parsed code contains an explicit TS (Target Service Code), and the user has permissions to the TS under the current SC, then USGS will prioritize using the TS as the target service.

[0082] If TS is empty, or if TS is a broad service category (such as query services or processing services), USGS will combine the default service configured in SPMS for the current SC, or other contextual information (such as the scanning device type, for example, scanning on a self-service machine is more likely to be a self-service), and the user's historical behavior in this scenario to infer the most appropriate target service. For example, in the scenario of a self-service machine in the outpatient hall (SC_LobbyKiosk), if the code does not specify TS, it may default to the self-service registration or self-service payment selection interface.

[0083] If the SPMS policy allows, multiple related services can be triggered by a single scan in a given scenario (such as automatically accessing the latest test results after checking in at the clinic), and USGS will orchestrate the services accordingly.

[0084] S209: Parameter Preparation and Backend Service Interface Invocation: Once the target service (or service list) is determined, the USGS is responsible for assembling all the parameters required to invoke the corresponding backend healthcare service system interface. These parameters may come from: Obtain it directly from the parsed encoding (such as UserID).

[0085] Retrieve from the user's session (if the user is logged into the app).

[0086] Fixed parameters or transformation rules configured by SPMS for specific scenarios / services.

[0087] USGS dynamically generates parameters based on current time, system status, and other factors.

[0088] USGS then uses its adaptation layer (part of the API Gateway) to call the corresponding backend service systems (such as the HIS registration interface, LIS report query interface, EMR medical record summary interface, and payment gateway order creation interface) using standard interface protocols (such as RESTfulAPI, gRPC, SOAP, HL7 FHIR, etc.). Detailed logs of the call process should be recorded to SAMS.

[0089] S210: Receive and process service responses: USGS receives response data from the backend service system. As needed, it may perform format conversions (e.g., converting backend XML to frontend JSON), content aggregation (e.g., merging results after calling multiple services), or error handling (e.g., backend service timeouts or returns error codes).

[0090] Finally, the service results are returned to the user's terminal / application: USGS returns the processed service results (success information and data, or error messages) to the user's terminal or application that initiated the scan through a secure channel for display. For example, after successful registration, the appointment number and consultation location are returned; after successful report retrieval, the report content is returned.

[0091] One code for multiple services implementation mechanism The core of this invention for achieving multiple services with a single code lies in the dynamic generation of the code and the embedding of contextual information, as well as unified backend parsing and policy-based intelligent service routing. This ensures that for the same user, at different times, locations, on different devices, or at different business process nodes, the generated (or system-recognized) "codes," while similar in form (all being a QR code), have dynamically changing content and activated services that are highly relevant to the current context.

[0092] Core principle: The encoding is dynamic and context-dependent: Unlike static code, the encoding generated by this invention is dynamic. Its content (or at least the encrypted / signed core payload) is injected with crucial contextual information at the time of generation, including the precise generation time (TM), current scenario code (SC), user identity (UserID), and possible initial service intent (TS). This means that each encoding instance is tailored to a specific moment, place, event, and person.

[0093] The core of the central parsing, verification, and intelligent scheduling system consists of a unified encoding parsing and verification module (CPVS) and a unified service gateway / scheduling module (USGS). Any dynamic encoding submitted by a user or device will first undergo rigorous verification by CPVS (timeliness, signature, anti-replay, decryption, etc.). After verification, USGS does not simply perform a fixed redirect based on the encoded content (such as opening a URL), but extracts the structured information carried in the encoding (such as UserID, SC, TS). Then, and this is crucial, it queries the predefined rule base in the Scenario and Permission Management module (SPMS).

[0094] Policy-driven Scenario and Permission Management Module (SPMS): SPMS is the brain behind dynamic service adaptation. It stores detailed configuration rules and defines: In healthcare scenario X (SC=X), a user of type Y (UserID belongs to type Y) uses a device of type Z. (DeviceType=Z) After scanning the code, the system should activate which backend services by default, or the user can choose which services to activate.

[0095] For each activatable service, does the user have execute permissions?

[0096] If the code carries a specific service intent (TS), that intent will be matched first, but the scenario and permissions still need to be verified.

[0097] USGS dynamically decides to route service requests to specific backend service interfaces based on rules such as "IF SC is X AND User is Y AND Device is ZTHEN accessible services are {S1, S2, ... default=S1} WITH permissions {P1, P2, ...}".

[0098] Example 3 This embodiment 3, based on embodiments 1 and 2, further illustrates the methods or systems of embodiments 1 and 2 using an example of an outpatient self-service medical process.

[0099] Suppose patient Zhang San (UserID: ZhangSan001) uses the hospital's official app, Smart Healthcare, for outpatient treatment: Step 1: Self-service appointment registration via APP Scenario (SC): APP_SelfService_Register (Mobile APP - Self-service - Appointment Registration).

[0100] The patient selected Gastroenterology - Dr. Li - Tomorrow morning on the APP and confirmed.

[0101] The app requests a code from DCGS to generate for this appointment. DCGS generates a dynamic QR code (Code_RegPay), whose core payload may include {UserID: ZhangSan001, SC: APP_SelfService Register, ...} The data entry is: TS: CreateAppointment_Pay, DoctorID: Li001, Dept: Digest, TimeSlot: YYYYMMDDHHMM, TM: current_time, Nonce: xyz123}, and is signed. The validity period may be set to 10 minutes (for payment). The app displays Code_RegPay and prompts the user to pay the registration fee.

[0102] Step 2: Scan the QR code to pay the registration fee Patients can use the payment function embedded in the app (or return after being redirected to a third-party payment app) to scan or directly use the context of Code_RegPay to make payments.

[0103] The app submits the Code_RegPay (or its associated payment request) to CPVS / USGS.

[0104] CPVS verifies Code_RegPay (validity period, signature, etc.).

[0105] After USGS analysis, it was identified that SC is APP_SelfService_Register and TS is CreateAppointment_Pay. According to SPMS rules, in this scenario, it is permissible to call the HIS's create appointment and lock number source interface and the payment gateway's initiate payment interface.

[0106] USGS first calls the HIS interface to attempt to reserve a number. If successful, it calls the payment gateway to complete the payment. After successful payment, it calls the HIS interface again to confirm the reservation.

[0107] The app receives a success notification and displays the appointment confirmation information. At this point, the SPMS strategy may instruct DCGS to pre-generate a new dynamic code (Code_CheckIn) for the patient's next step (such as check-in at the clinic).

[0108] Step 3: Check in at the self-service check-in machine in the clinic area on the day of your visit. Scenario (SC): CliniArea Kiosk _CheckIn (Clinic Area A - Self-service Check-in Machine).

[0109] Patient Zhang San arrives at the gastroenterology clinic and finds the self-service check-in machine. He opens the Smart Healthcare App, selects 7 "My Appointments," and the app displays the previously generated or newly acquired check-in code, Code_CheckIn. Its core payload may contain {UserID: ZhangSan001, SC: ClinicArea_Kiosk_CheckIn (updated by the app based on current status or beacon), AppointmentID: ApptXYZ789, TM: current_time, Nonce: abc789}.

[0110] The patient aligns the Code_CheckIn on their mobile phone with the scanning port of the self-service check-in machine.

[0111] The self-service check-in machine will submit the scanned Code CheckIn to CPVS / USGS.

[0112] CPVS verification. USGS parsing identifies SC as ClinicArea_Kiosk_CheckIn, UserID as ZhangSan001, and the associated appointment ID.

[0113] According to SPMS rules, the permitted service in this scenario is patient check-in and joining the waiting queue. USGS calls the corresponding HIS interface.

[0114] The self-service machine displays a message indicating successful check-in, and informs you of the estimated waiting time and your appointment number.

[0115] Step 4: Doctor's Clinic, Identity Verification and Medical Record Review Scene (SC): DoctorOffice_Workstation_Consult (Clinic Room 101 - Doctor Workstation - Treatment).

[0116] When it was Zhang San's turn to see Dr. Li, he entered Dr. Li's office. Dr. Li was at his workstation preparing to see him.

[0117] Method 1 (Patient displays code): Zhang San displays the dynamic code (Code_Consult_PatientView) representing the current consultation status on the APP, and Dr. Li scans it with a handheld scanner.

[0118] Method 2 (Doctor scans patient's wristband / card as a backup plan, or system automatically associates): If available.

[0119] Method 3 (Doctor's workstation displays code, patient scans and confirms via APP): Used for two-way confirmation.

[0120] Assuming method one is used, after the doctor scans the code, Code_Consult PatientView is submitted. CPVS verification is performed. USGS parsing identifies SC as DoctorOffice_Workstation_Consult and UserID as ZhangSan001.

[0121] According to SPMS rules, in this scenario, doctors have the authority to access patients' electronic medical records, order examinations / tests, and issue prescriptions. Based on the doctor's actions on the workstation (such as clicking the "view medical records" button), USGS will route the request to the EMR system to access Zhang San's medical records. If the doctor issues a prescription, USGS will send the prescription information to the pharmacy system and the HIS billing system.

[0122] Next steps: Laboratory / Radiology Department Registration: Patients scan the registration code (Code LabScan / CodePacsScan) from the app at the corresponding department to register. Self-service machine / Payment window payment (medication / examination fees): Use a dynamic code (Code_Payment) containing payment information to complete the payment.

[0123] Picking up medication at the pharmacy window: Show your medication pickup code (Code_PharmacyPickup) and scan it. The pharmacy system will verify the prescription, confirm payment, and dispense the medication.

[0124] Self-service report printer: Scan the report query / print code (Code_ReportPrint) to obtain and print the issued inspection and testing report.

[0125] Throughout the entire process described above, patients interact with the system by scanning or displaying a code. However, the backend achieves seamless integration and automatic adaptation to different services by dynamically generating and intelligently parsing codes of the same format. Each generated code may carry different core information due to differences in scenario (SC), intent (TS), and time (TM), and security is ensured through signatures.

[0126] In summary, this invention provides a method and system for providing multiple services with a single code in a medical setting, which has the following advantages and features: User experience consistency: Patients only need to master one interaction method—scanning / showing the code—to go through the entire medical process without having to remember or switch between multiple cards, codes, or APP function access points.

[0127] Centralization and intelligentization of backend service logic: Complex decision-making logic regarding which service to provide in which scenario has been moved up and centralized to USGS and SPMS from various scattered business systems or user terminals. This allows service process adjustments, additions, and optimizations to be primarily configured on the central platform, reducing the burden of modifying individual business systems and terminals.

[0128] High flexibility and scalability: When hospitals need to introduce new medical services (such as remote consultation and chronic disease management modules) or adjust existing medical processes, the main workload lies in adding scenario definitions, service rules, and permission configurations in SPMS, as well as adapting possible service interfaces in USGS. The core encoding generation (DCGS) and parsing (CPVS) mechanisms do not require major changes, and upgrades to user terminals are also likely to be minor (mainly updates to the UI and service lists).

[0129] Excellent compatibility with heterogeneous systems: USGS uses standardized API interfaces to loosely connect with numerous backend medical business systems (which may come from different vendors and use different technologies), which helps protect the hospital's existing IT investment and gradually achieve information integration.

[0130] This invention can improve the convenience, integration, security, and user experience of medical services, while also improving the operational efficiency of medical services, reducing the cost of collaboration among multiple medical systems, and providing reliable support for the digital service upgrade of medical institutions.

Claims

1. A one code multiple service method in a medical scenario, characterized in that, The system comprises: Based on the code generation request, obtain the pre-defined code generation strategy, generate the security-processed visual dynamic code, the parameters of the code generation request include user identity, current medical scene information, service intention, timestamp and random number Nonce value, the service intention is user input parameter, if it is empty, it is determined according to the current medical scene information subsequently; Format verification, timeliness verification, anti-replay verification and digital signature verification are performed on the obtained dynamic code, and the analysis result is obtained; Service routing decision and execution are carried out, the target service of the user is determined according to the scene and user information in the dynamic code analysis result, and the corresponding backend medical service system interface is called to receive the service response, the pre-defined user-scene-service-permission rule is queried, and the service result is determined according to the service response, and the service result is returned to the user terminal.

2. The method of claim 1, wherein, The generation of the visual dynamic code specifically includes the following steps: Receive the code generation request and parameters and perform legality verification, the code generation request is generated by user initiative, pre-generated by service process information driving system or triggered by medical staff operation; Obtain the code generation strategy corresponding to the current medical scene, and the strategy content information includes the version number of the code, the validity period, the list of allowed embedded data fields, the encryption algorithm and the key identification and effective number of the encryption algorithm, the digital signature algorithm and the key identification and effective number of the signature algorithm; According to the code generation strategy, the core data load including user identity, scene code and service intention is encrypted and digitally signed; The signed core data, code version number, code issuing agency identification and part of the public scene prompt information are assembled into a code string according to the predetermined format, and converted into a visual dynamic code image.

3. The method of claim 2, wherein, The encryption adopts the national standard SM series algorithm or international standard encryption algorithm, and the digital signature algorithm adopts the asymmetric signature algorithm.

4. The method of claim 1, wherein, The service routing decision and execution step further comprises: If the service intention is not specified in the dynamic code analysis result, at least one of the following is inferred: the type of the code scanning device, the default service of the scene, the user session or the user historical behavior; If there are multiple target services, the multiple associated target services are combined and arranged in sequence and called.

5. The method of claim 1, wherein, After the dynamic code passes all the verifications, the encrypted core data load is decrypted, the key business information including user identity, scene code, timestamp, random number and target service intention information is parsed and extracted according to the pre-defined structure, and if the decryption fails, the process is aborted.

6. A one code multiple service system in a medical scenario, for implementing the one code multiple service method in a medical scenario of any one of claims 1-5, characterized in that, The system comprises: A dynamic code generation service module is configured to obtain a pre-defined code generation strategy based on a code generation request, and generate a security-processed visual dynamic code, wherein the parameters of the code generation request include user identity, current medical scene information, service intention, timestamp and random number Nonce value, the service intention is a user input parameter, and if it is empty, it is determined according to the current medical scene information subsequently; The coding analysis and verification module is configured to perform format checking, timeliness verification, anti-replay checking and digital signature verification on the acquired dynamic code, and to analyze the dynamic code to obtain an analysis result; The unified service gateway and scheduling module is configured to determine a target service of a user according to scene and user information in the dynamic code analysis result, to call a corresponding backend medical service system interface to receive a service response, to query predefined user-scene-service-permission rules, and to determine a service result according to the service response, and to return the service result to the user terminal; The scene and permission management module is configured to store and manage medical scene information generated in a service process, predefined coding generation strategies and predefined scene-service-permission rules, and to provide an interface for other modules to query.

7. The system of claim 6, wherein, The dynamic code generation service module is further configured to: receive a code generation request from a user terminal, a medical workstation or a self-service device; integrate a coding strategy engine, an encryption signature component and a coding formatter to generate a dynamic code that meets the requirements of the coding generation strategy.

8. The system of claim 6, wherein, The unified service gateway and scheduling module is further configured to: provide a standard interface adaptation with at least one of a hospital information system (HIS), a laboratory information system (LIS), a picture archiving and communication system (PACS), an electronic medical record system (EMR) and a medical insurance payment system; support service call arrangement, parameter conversion, response aggregation and unified return.

9. The system of claim 6, wherein, The scene and permission management module further stores: medical scene information metadata, including scene codes, applicable device types and geographic fence information; coding strategy content information in different scenes, including the validity period, the number of uses, the encryption algorithm, the signature algorithm and the embedded fields of the code of the coding; scene-service mapping rules and user-scene-service-permission rules.

10. The system of claim 6, wherein, The system further includes a security and audit module configured to: manage encryption keys and signature certificates; record audit logs of dynamic code generation, use and service call; provide anti-replay attack support and security event risk control response.

Images