Hierarchical medical electronic business card system and information aggregation method thereof

Abstract

The invention discloses a hierarchical medical electronic business card system and an information aggregation method thereof, the system comprises a front-end layer, a business module layer, an external hospital system layer and a block chain layer, the business module layer comprises a two-dimensional code generation and identification module used for generating an anti-counterfeiting verifiable doctor exclusive two-dimensional code based on multi-dimensional hash and a block chain; the doctor information aggregation display module is used for aggregating the multi-source information and dynamically displaying the multi-source information; and the communication interface access module is used for intelligently scheduling multiple communication channels. According to the method, the unification of digital identities of doctors, credible authentication and efficient aggregation of information are realized, the problems of doctor information dispersion, communication channel splitting and the like in the prior art are solved, and the doctor-patient connection efficiency and the digital management level of doctor services are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of medical information technology, and in particular to a hierarchical medical electronic business card system and its information aggregation method. Background Technology

[0002] Against the backdrop of the ongoing advancement of the hierarchical medical system and the collaborative construction of medical alliances, doctors, as direct providers of medical services, are seeing their ability to digitally present information to patients, communicate online, and coordinate services becoming a crucial aspect of healthcare informatization. However, most medical institutions and platforms still face the following prominent issues in doctor information services: 1. Fragmented digital identities for doctors Doctors have independent access points across multiple service scenarios, including hospital systems, WeChat official accounts, internet platforms, and mini-programs, lacking a unified identity verification and authentication mechanism. Due to inconsistent information standards, patients struggle to accurately assess a doctor's professional qualifications and service capabilities, thus reducing trust and selection efficiency.

[0003] 2. Limited information display methods Current doctor profiles primarily consist of static text and images, lacking multimedia presentation formats such as videos, audio recordings, and flowcharts, thus failing to comprehensively showcase doctors' professional expertise and brand value. This inadequate digital representation of doctors severely restricts the effectiveness of information dissemination and patients' perception of them.

[0004] 3. Fragmented entry points for doctor-patient communication There are issues with fragmented and disjointed doctor-patient communication channels. There is a lack of integration between doctors' official channels and social media tools, requiring patients to switch between multiple platforms or manually add contact information. The absence of a unified, easily accessible channel via QR code results in low communication efficiency and conversion rates.

[0005] 4. Content release lacks a unified platform. Doctors often rely on independent platforms for publishing professional content, such as articles, videos, or lectures, lacking a unified modular organization and centralized management mechanism. They are unable to present multiple types of content holistically on their personal homepages, and lack efficient means to support expansion and dissemination.

[0006] In summary, current digital services for doctors suffer from problems such as information fragmentation, scattered communication entry points, fragmented content distribution, and a lack of aggregated entry points and a unified system. There is an urgent need for a platform system that can unify identity authentication, aggregate entry points, and support modular content display and collaborative communication to improve the efficiency of doctors' external services and the digitalization of doctor-patient relationship management. Summary of the Invention

[0007] Based on this, the purpose of this invention is to address the aforementioned technical problems by providing a system platform for hierarchical medical treatment scenarios that enables trusted authentication of doctors' identities, efficient aggregation and display of information, multi-channel communication and linkage, and unified content publishing and management.

[0008] To achieve the above-mentioned objectives, the first aspect of this application provides a hierarchical medical electronic business card system, comprising: a front-end layer, a business module layer, an external hospital system layer, and a blockchain layer; The front-end layer is used for information display and system operation, including patient terminals for accessing the system by scanning a code or accessing a doctor's QR code page, and doctor terminals for back-end management and content publishing. The business module layer includes: The QR code generation and identification module is used to call the blockchain layer to generate a multidimensional hash value based on the doctor's identity identifier, institution node code, timestamp and random salt, and generate a unique corresponding QR code based on the multidimensional hash value; The doctor information aggregation and display module is used to obtain structured information about doctors from the external hospital system layer and dynamically display it on the front-end layer; The communication interface access module is used to configure multiple doctor-patient communication channels and dynamically schedule the communication path between patients and doctors based on preset priorities and availability detection. The external hospital system layer is used to access, acquire, and provide data information from external hospital systems. The blockchain layer is used to implement blockchain-based evidence storage and the issuance, verification, revocation, and caching of QR code service data.

[0009] Preferably, the blockchain layer includes: The smart contract unit is used to implement the issuance, verification, and revocation of QR codes; Consortium blockchain node units are used to endorse, sort, and record transactions on the blockchain.

[0010] Merkle batch registration unit is used for batch QR code writing in high-concurrency scenarios; Off-chain cache units are used to cache service data; The event listening unit is used to listen for QR code reversal transactions on the blockchain and broadcast a notification when a reversal event is detected. The cancellation of the QR code includes: Receive a QR code cancellation request and record the cancellation transaction on the blockchain by calling the blockchain smart contract; The system monitors blockchain events. When it detects a successful transaction reversal via the QR code, it broadcasts the reversal event through the event monitoring unit, notifying the off-chain caching unit to immediately delete or mark the corresponding service data record cache as invalid and write it to the blacklist.

[0011] Preferably, the system further includes a content extension and publishing module, which is used to receive and store multimedia content submitted by doctors, conduct compliance review of the content by combining artificial intelligence review and manual review mechanism, bind the approved content to a designated column on the doctor's homepage for modular display on the front end, and call the blockchain layer to generate a unique fingerprint for the approved content for on-chain storage.

[0012] Preferably, the doctor information aggregation and display module employs a cache-first loading strategy when acquiring structured doctor information, including: First, check if the doctor's integrated information data exists in the off-chain cache layer; If the cache is hit, the structured display data is returned directly, and the front-end layer performs modular rendering before dynamically displaying it on the front-end. If the cache misses, all external hospital systems in the external hospital system layer are called in parallel to obtain multi-source data; After cleaning, standardizing, and structuring the acquired multi-source data, the results are written to a cache database and returned to the front end for modular rendering.

[0013] Preferably, the communication interface access module includes the following steps when scheduling the communication path: Load the doctor's communication channel configuration. If only a single channel is configured, proceed directly; otherwise, enter the priority scheduling process. According to the preset priority order, the availability of each communication channel is checked in turn. If the communication channel with higher priority is available, it is immediately switched and the switching event is recorded. If it is unavailable, it enters the next communication channel. If all channels are unavailable, a message will be returned to the user.

[0014] Preferably, the system further includes a backend management and data analysis module, used to record and store patients' behavior logs, and quantify the doctor's influence index based on the behavior logs and output it to the frontend layer for display; The specific process of quantifying the physician influence index includes: Extracting multi-dimensional feature metrics from behavior logs; The multi-dimensional feature indicators are normalized or standardized. Configure corresponding weight factors for the processed feature indicators; The doctor's comprehensive influence index is obtained by weighting the weighting factors.

[0015] To achieve the purpose of the invention, a second aspect of this application provides an information aggregation method for a hierarchical medical electronic business card system. The method, which applies the hierarchical medical electronic business card system described above, includes: The QR code generation and identification module and the blockchain layer are invoked to generate a multidimensional hash value based on the doctor's identity identifier, institution node code, timestamp, and random salt, and a unique corresponding QR code is generated based on the hash value; the batch-generated QR code identifiers are written into the blockchain through the Merkle tree batch registration mechanism, and a verifiable credential containing the doctor's professional qualification information is embedded in the QR code; After the patient scans the QR code, the doctor's structured information is obtained from at least one external hospital system through the unified interface of the doctor's electronic business card system. The doctor information aggregation and display module is called, and the doctor's homepage is dynamically generated on the front end by adopting a cache-first loading strategy and a modular rendering mechanism. By calling the communication interface access module, the front-end layer dynamically selects and redirects the patient to the optimal communication channel based on the doctor's configured communication channel list, preset priority, and real-time availability detection results. After receiving the multimedia content submitted by the doctor through the front-end layer, the content extension and publishing module is called to conduct dual review by artificial intelligence and human review. Once approved, the content is bound to the designated column on the doctor's homepage and published on the front-end layer. The system collects and records patient interaction logs on the doctor's homepage through the backend management and data analysis module. Based on the logs, the system calculates the doctor's influence index using weighting factors and outputs it to the frontend layer for display.

[0016] Preferably, when a patient scans the QR code, a QR code verification step is also included: When a patient scans the QR code, the off-chain cache is queried first; If the cache is hit and valid, the verification passes. If the cache misses or expires, query the on-chain status of the QR code; If the QR code has been withdrawn, an invalidation message will be sent to the patient. If the QR code is still valid on the blockchain, the result will be backfilled to the off-chain cache and verified.

[0017] Preferably, the specific process of binding the content to a designated section of the doctor's homepage and publishing it at the front-end layer includes: Store the content submitted by the doctor in an object storage service and generate a content hash value; Use natural language processing models and image recognition APIs to automate pre-screening of content; If the preliminary review fails, a revision suggestion will be returned, requiring the doctor to revise and resubmit. The content that passed the preliminary review will undergo a manual review. If the manual review fails, return the application and record the reason for the failure. If the manual review is successful, the content that has passed the manual review will be bound to a specific module on the doctor's homepage, published through modular rendering, and a unique fingerprint will be generated for the content that has passed the manual review based on its corresponding content hash value and written into the blockchain for storage.

[0018] Preferably, the calculation of the doctor's influence index specifically includes: Batch processing of behavior logs, including data cleaning, deduplication and session concatenation, and extraction of multi-dimensional feature indicators including number of QR code scans, dwell time, click rate and number of communications from the processed behavior logs; The Min-Max method is used to normalize the indicators, and the Z-score method is used to standardize them. Weighting factors are assigned to each processed indicator, and a weighted sum is performed to obtain the doctor's comprehensive influence index.

[0019] Compared with the prior art, the beneficial effects of this invention are: This invention brings significant positive benefits to doctors, hospitals, and patients through the synergistic effect of the front-end layer, business module layer, external hospital system layer, and blockchain layer. By leveraging a QR code generation and identification module to generate unique QR codes based on the blockchain and embed verifiable credentials, combined with a doctor information aggregation and display module that dynamically aggregates structured information from the external hospital system, it achieves a credible presentation of doctors' multi-dimensional digital image, thereby enhancing doctors' personal brand influence. Furthermore, through a communication interface access module, it configures multiple communication channels and, based on priority scheduling and availability detection mechanisms, enables "scanning a code to communicate," significantly improving the efficiency of doctor-patient communication and connection. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the overall structure of a hierarchical medical electronic business card system in one embodiment; Figure 2 This is a schematic diagram illustrating the steps of an information aggregation method for a hierarchical medical electronic business card system in one embodiment. Figure 3 This is a schematic diagram of the QR code generation and redirection process in one embodiment; Figure 4 This is a schematic diagram illustrating the process of QR code cancellation and cache invalidation in one embodiment; Figure 5 This is a schematic diagram of the process of loading and aggregating doctor homepage information in one embodiment; Figure 6 This is a schematic diagram of the communication channel priority redirection logic in one embodiment; Figure 7 This is a flowchart illustrating the content review and module binding process in one embodiment; Figure 8This is a flowchart illustrating the behavior collection and influence scoring process in one embodiment. Detailed Implementation

[0021] 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.

[0022] Example 1 Embodiment 1 of this application provides a hierarchical medical electronic business card system, such as Figure 1 As shown, it includes: Front-end layer, business module layer, external hospital system layer, and blockchain layer; The front-end layer is used for information display and system operation, including patient terminals for accessing the system by scanning a code or accessing a doctor's QR code page, and doctor terminals for back-end management and content publishing. The business module layer includes: The QR code generation and identification module is used to call the blockchain layer to generate a multidimensional hash value based on the doctor's identity identifier, institution node code, timestamp and random salt, and generate a unique corresponding QR code based on the multidimensional hash value. The batch-generated QR codes are written into the blockchain through the Merkle tree batch registration mechanism, and a verifiable credential containing the doctor's professional qualification information is embedded in the QR code. The doctor information aggregation and display module is used to obtain structured information about doctors from the external hospital system layer and dynamically display it on the front-end layer; The communication interface access module is used to configure multiple doctor-patient communication channels and dynamically schedule the communication path between patients and doctors based on preset priorities and availability detection. The content extension and publishing module is used to receive and store multimedia content submitted by doctors. It combines artificial intelligence review and manual review mechanisms to conduct compliance review of the content, binds the approved content to the designated column of the doctor's homepage for modular display on the front end, and calls the blockchain layer to generate a unique fingerprint for the approved content for on-chain storage. The back-end management and data analysis module is used to record and store patients' behavior logs, and to quantitatively output the doctor's influence index based on the behavior logs to the front-end layer for display. The external hospital system layer is used to access, acquire, and provide data information from external hospital systems. The blockchain layer is used to implement blockchain-based evidence storage and the issuance, verification, revocation, and caching of QR code service data.

[0023] The functions and interactions of each layer are as follows: 1) Front-end layer Patient terminal: Patients can access the system by scanning a code or visiting the doctor's QR code page to obtain doctor introductions, scheduling information, communication channels, and extended content.

[0024] Doctor terminal: Used for backend management and content publishing, including information maintenance and uploading health education content.

[0025] 2) Business Module Layer The QR code generation and identification module is responsible for generating and verifying doctors' unique QR codes. It calls the blockchain layer smart contract to implement issuance, anti-counterfeiting, and revocation, and writes the batch-generated QR codes into the blockchain in the form of transactions through the Merkle tree batch registration mechanism. It also embeds verifiable credentials containing doctors' professional qualification information into the QR codes, and is responsible for the generation and verification of QR codes.

[0026] A multi-dimensional hash algorithm based on DoctorID, Organization ID, Timestamp, and Salt is used to generate a unique hash value as the core identifier of the QR code. Using the SHA-256 hash function and a Merkle tree batch registration mechanism, the batch-generated QR code identifiers are written into the blocks of the consortium blockchain (such as Hyperledger Fabric) as transactions, ensuring the immutability of the issued data. The generated QR code embeds the on-chain transaction hash value and a verifiable credential (VC) in W3C Verifiable Credential (VC) format. When a patient scans the code, they can verify it locally or on-chain using the hospital's public key, thus ensuring the authenticity and integrity of the doctor's professional qualifications. The QR code verification result is stored in a Redis cache, reducing on-chain query overhead. When the QR code is revoked, the blockchain event listener (EventHub) triggers cache invalidation, ensuring real-time synchronization of invalidation information.

[0027] Multidimensional hashing algorithm: Input elements: Doctor ID, Institution ID, Timestamp, and Salt.

[0028] Generation rule: Hash = SHA-256(DoctorID || OrgID || Timestamp || Salt). This invention uses multi-dimensional input (including timestamp and random salt), which can increase the difficulty of hash collisions and the ability to resist replay attacks.

[0029] The doctor information aggregation and display module displays basic doctor information, outpatient schedules, and extended content, and supports dynamic adjustment of display order and visibility by the configuration center. This module connects to the Hospital Information System (HIS), Content Management System (CMS), and scheduling system through a unified aggregation interface to obtain structured doctor information.

[0030] A cache-first loading strategy is adopted (first querying the Redis off-chain cache, and if it is not found, then calling the external hospital system for querying), and the data is dynamically displayed on the front end through a modular rendering mechanism to ensure data loading performance and display flexibility.

[0031] Communication interface access module: Connects to various communication channels such as WeChat for Enterprise, hospital IM, and online appointment, and automatically selects and redirects to the optimal channel based on the priority order set in the backend and the channel availability test results.

[0032] Both channel configuration and test results are logged and linked to the doctor's identity issued by the blockchain, ensuring the traceability and compliance of the communication process.

[0033] Content expansion and publishing module: Doctors can publish science popularization content such as text, images, and videos. The content is reviewed by AI (NLP models and image recognition) and manually, ensuring compliance. Once approved, the content is linked to a designated section module and displayed on the front end using a template-based rendering method, achieving compliant multimedia content expansion.

[0034] Backend Management and Data Analysis Module: This module records patient behavior logs, including scanning codes, dwell time, clicks, and communication, and generates statistical reports based on these logs. All behavior logs are timestamped and signed before being written to the log database, ensuring the data reliability for subsequent physician influence index modeling. It is also responsible for data cleaning and behavior analysis, using normalized and standardized log data to obtain multidimensional feature indicators and weighting factors to calculate and generate the physician influence index.

[0035] 3) External hospital system layer Hospital Information System (HIS): Provides basic information and medical records for doctors.

[0036] Scheduling system: Returns doctors' outpatient schedules and clinic hours.

[0037] Content Management System (CMS): Provides content management and popular science article resources.

[0038] 4) Blockchain layer Smart contract (unit): Implements the logic for issuing, verifying, and revoking QR codes, ensuring the immutability of identity and data.

[0039] Consortium blockchain nodes (units): responsible for endorsement, sorting, and on-chain evidence storage.

[0040] Merkle Batch Registration (Unit): Supports batch QR code writing in high-concurrency scenarios, improving on-chain processing efficiency.

[0041] In this embodiment, the blockchain layer further includes: Off-chain cache unit ( Figure 1 (Not shown in the image), used to cache service data; Event Listening Unit ( Figure 1 (Not shown in the image) is used to monitor QR code reversal transactions on the blockchain and broadcast a notification when a reversal event is detected.

[0042] Blockchain registration and verification: Using a consortium blockchain (such as Hyperledger Fabric), endorsement nodes invoke smart contracts to implement QR code issuance, verification, and revocation.

[0043] For high-concurrency scenarios, Merkle trees are used for batch registration, allowing N QR codes to be registered simultaneously in a single transaction, reducing on-chain operation costs.

[0044] Example 2 Embodiment 2 of the present invention, based on Embodiment 1, provides an information aggregation method for a hierarchical medical electronic business card system, such as... Figure 2 As shown, it includes: S1: Call the QR code generation and identification module and the blockchain layer to generate a multidimensional hash value based on the doctor's identity identifier, institution node code, timestamp and random salt, and generate a unique corresponding QR code based on the hash value; write the batch-generated QR code identifiers into the blockchain through the Merkle tree batch registration mechanism, and embed a verifiable credential containing the doctor's professional qualification information in the QR code; S2: After the patient scans the QR code, the doctor's structured information is obtained from at least one external hospital system in the external hospital system layer through the unified interface of the doctor's electronic business card system. The doctor information aggregation and display module is called, and the doctor's homepage is dynamically generated on the front end by adopting a cache priority loading strategy and a modular rendering mechanism. S3: By calling the communication interface access module, the front-end layer dynamically selects and redirects the patient to the optimal communication channel based on the doctor's configured communication channel list, preset priority, and real-time availability detection results; S4: After receiving the multimedia content submitted by the doctor through the front-end layer, the content extension and publishing module is called to conduct dual review by artificial intelligence and human review. After passing the review, the content is bound to the designated column of the doctor's homepage and published in the front-end layer. S5: Collect and record patient interaction logs on the doctor's homepage through the backend management and data analysis module, calculate the doctor's influence index based on the logs using weighting factors, and output it to the frontend layer for display.

[0045] Example 3 This application's Embodiment 3, based on Embodiments 1 and 2, further explains the QR code generation and redirection process, the QR code cancellation and cache invalidation mechanism process, the doctor's homepage information aggregation and loading process, the communication channel priority redirection logic process, the content review and module binding process, and the behavior collection and influence scoring mechanism process, as detailed below: like Figure 3 As shown, the QR code generation and redirection process includes: 1) QR code generation stage The doctor logs into the backend and initiates a QR code generation request; The system generates a unique entry code (containing anti-counterfeiting features) based on the doctor's ID and the institution's ID using a hash algorithm. The system generates a corresponding QR code image and uploads the image to an object storage service (such as OSS). Generate QR code metadata (such as doctor ID, redirect link, validity period, etc.) and write it to the configuration database; Optionally, the information bound to the QR code is written into the blockchain network to achieve tamper-proof traceability verification; Return to the QR code access link and image address for dynamic rendering and display on the front-end page.

[0046] 2) QR code redirection stage Patients access the QR code link by scanning the code; The system front-end receives the request and queries the QR code binding relationship; Verify the validity and expiration of the QR code, and confirm the doctor's identity; If the verification is successful, the system will redirect you to the corresponding doctor's electronic business card homepage; The system dynamically loads basic doctor information, aggregates and displays modules, establishes communication channels, and defines content publishing areas. If the QR code is abnormal (invalid, illegally tampered with, etc.), the default prompt page or error prompt page will be returned.

[0047] like Figure 4 As shown, the QR code cancellation and cache invalidation mechanism process includes: 1) Initiation of withdrawal request Doctors or administrators can initiate a QR code revocation request on the management side (with the parameter txHash), and the QR code service will call the blockchain smart contract to execute the revocation operation.

[0048] 2) On-chain evidence storage and event broadcasting The smart contract records the reversal transaction on the blockchain and generates a transaction hash. After the transaction is successfully confirmed, the blockchain system broadcasts the reversal event through the event listening service (EventHub) to notify the QR code service to update the status.

[0049] 3) Cache invalidation handling Upon receiving a revocation event, the QR code service immediately deletes the corresponding record from the Redis off-chain cache, or marks it as invalid and adds it to the blacklist, ensuring that the revocation result takes effect immediately at the cache level.

[0050] 4) Patient QR code verification When the patient's terminal scans the code again, the verification API first reads the cached result: If the verification is successful: return "Verification passed" directly. If a match is missed or the chain has expired, then further query the on-chain state.

[0051] If the QR code is shown to have been revoked on the chain, an "invalid" flag is written, and the patient is notified that the QR code has expired. If the result is still valid on the chain, the cache is populated back, the TTL is set, and "verification passed" is returned.

[0052] 5) Consistency Guarantee Off-chain cache queries are only used to accelerate verification queries. The final result is based on the on-chain state, thus ensuring the authority of data immutability and revocation while guaranteeing user experience.

[0053] like Figure 5 As shown, the process of aggregating and loading information on a doctor's homepage includes: 1) Homepage access request Patients scan or click on a doctor's QR code in their browser to request the doctor's homepage to be loaded. The request first leads to the doctor's homepage frontend, and then the frontend forwards it to the information aggregation service.

[0054] 2) Cache-first lookup (cache-first loading strategy) The information aggregation service first checks if the integrated doctor information data exists in the Redis cache: Cache hit: The structured display data is returned directly, and the homepage is displayed after front-end rendering; Cache miss: Proceed to the parallel aggregation process.

[0055] 3) Parallel aggregate invocation When a cache miss occurs, the information aggregation service simultaneously sends parallel requests to the hospital's internal HIS system, scheduling system, and CMS system to obtain basic doctor information, outpatient schedules, and public health information. At the same time, the system also queries the display configuration database for module order and visibility configurations.

[0056] 4) Data aggregation and storage The information aggregation service cleans, standardizes, and structures the returned multi-source data to form complete aggregated information for doctor homepages. This result is written to a Redis cache with a TTL set so that subsequent requests can quickly retrieve it, improving performance.

[0057] 5) Result return and page rendering The aggregated structured data is returned to the front end, where it is rendered in modules (basic information, extended content, column display, etc.) and finally displayed as a complete doctor's homepage on the patient's browser.

[0058] like Figure 6 As shown, the communication channel priority redirection logic flow includes: 1) User triggers communication request: Patients click the "Communicate Now" button on the doctor's profile page; The system loads the doctor's communication channel configuration (from the backend configuration table).

[0059] 2) Channel quantity determination and default redirection: If only a single channel is configured, redirect directly; Otherwise, it will enter the priority scheduling process.

[0060] 3) Priority scheduling and availability detection: The system probes each channel in order of priority to determine whether it is reachable (e.g., whether the WeChat Work platform is valid, whether the link is responsive). If available, redirect immediately and record the redirection event; If it is unavailable, proceed to the next channel.

[0061] 4) Fallback strategy when all channels are unavailable: If all channels are unavailable, a friendly message will be displayed (such as "The doctor has not yet enabled communication services, please try again later").

[0062] 5) Behavior log recording: Successful redirects and failed rollbacks will be logged for subsequent behavior analysis and influence scoring.

[0063] like Figure 7 As shown, the content review and module binding process includes: 1) Content Submission and Storage Doctors submit content (including title, summary, body text, and media files) on the front end. The system first stores the content in object storage and generates a content hash value for subsequent uniqueness verification.

[0064] 2) AI pre-screening The system calls the internally integrated (or externally accessible) Natural Language Processing (NLP) model and image recognition API to perform sensitive word detection and compliance identification on the content.

[0065] Approved: Proceed to manual review stage; The review failed: The system returned suggested revisions, requiring the doctor to revise and resubmit.

[0066] 3) Manual review The medical content review panel manually verifies content that has passed AI review. Failed: The system returns and records the reason for the failure to pass the review; Pass: Enter the module binding process.

[0067] 4) Module binding and evidence storage Approved content will be linked to a specific section or module (such as a health column, lectures, videos, etc.). Subsequently, the system will generate a unique fingerprint for the content (SHA-256 hash + timestamp + author ID) and store the fingerprint on the blockchain to form a traceable transaction record.

[0068] 5) Release, launch, and rendering After the evidence is stored, the content is published online using a modular rendering template. The system also performs the following operations: Write back to the cache: Update page fragments, refresh the CDN, and ensure that the content displayed on the front end is the latest version; Behavioral tracking: Tracking and recording user behaviors such as exposure, clicks, dwell time, and sharing, and writing them to a log database (such as ClickHouse / Hive) for subsequent analysis.

[0069] like Figure 8 As shown, the behavior data collection and influence scoring mechanism process includes: 1) Front-end event tracking An SDK is pre-installed in the patient's browser or mini-program to track user behaviors such as scanning, dwelling, clicking, and communication, and generate event data in real time.

[0070] 2) Log reporting and signature storage After behavioral events are uploaded by the log collection service, the system generates a digital signature fingerprint for the log using a timestamp and the SHA-256 algorithm. The logs are stored in object storage for subsequent ETL use, and log summaries can also be uploaded to the blockchain to ensure data tamper-proofing and traceability.

[0071] 3) Log storage and preprocessing The raw logs are stored in object storage and processed in batches by ETL jobs, including data cleaning, deduplication, and session concatenation, to ensure the accuracy of subsequent feature extraction.

[0072] 4) Feature extraction The system extracts multi-dimensional feature metrics from the cleaned logs, such as the number of scans, average dwell time, click-through rate, and number of communications, to measure the depth of interaction between users and doctors' electronic business cards.

[0073] 5) Indicator normalization and standardization The Min-Max method is used to normalize some indicators and map them to a uniform numerical range; The Z-score method was used to standardize some indicators to eliminate differences in different units and distributions; The results of processing the two types of indicators are used as input for modeling.

[0074] 6) Weighting factor configuration and weighted calculation The system includes a pre-configured weighting factor service (e.g., w1, w2, w3, w4), allowing for flexible adjustment of the contribution of each indicator. After weighting by these factors, the doctor's overall score is calculated.

[0075] 7) Results Output and Application The overall score is written into the results table as the doctor's influence index and output to the data dashboard through the interface, realizing the visualization and comparative analysis of the doctor's service communication power and patient interaction influence.

[0076] In summary, this invention brings significant positive benefits to doctors, hospitals, and patients through the synergistic effect of the front-end layer, business module layer, external hospital system layer, and blockchain layer. By leveraging the QR code generation and identification module to generate unique QR codes based on the blockchain and embed verifiable credentials, combined with the doctor information aggregation and display module to dynamically aggregate structured information from the external hospital system, it achieves a credible presentation of doctors' multi-dimensional digital image, thereby enhancing doctors' personal brand influence. Through the communication interface access module, multiple communication channels are configured, and based on priority scheduling and availability detection mechanisms, "scanning a code is all it takes" to achieve "communication," significantly enhancing the efficiency of doctor-patient communication and connection. The doctor information aggregation and display module and the back-end management and data analysis module unify the management of doctor content and interactions, promoting the transformation of hospitals from decentralized services to standardized institutional management and helping hospitals achieve digital doctor management. The content expansion and publishing module supports multimedia content publishing and combines AI review and blockchain notarization to ensure content compliance and credibility, promoting the dissemination of health knowledge and popularization of medical science. Based on the back-end management and data analysis module, behavioral logs are recorded and an influence index model is constructed, combined with credible notarization in the blockchain layer to provide quantitative indicators, supporting the evaluation of doctor service value and the improvement of medical service quality.

Claims

1. A tiered medical electronic business card system, characterized in that, include: Front-end layer, business module layer, external hospital system layer, and blockchain layer; The front-end layer is used for information display and system operation, including patient terminals for accessing the system by scanning a code or accessing a doctor's QR code page, and doctor terminals for back-end management and content publishing. The business module layer includes: The QR code generation and identification module is used to call the blockchain layer to generate a multidimensional hash value based on the doctor's identity identifier, institution node code, timestamp and random salt, and generate a unique corresponding QR code based on the multidimensional hash value; The doctor information aggregation and display module is used to obtain structured information about doctors from the external hospital system layer and dynamically display it on the front-end layer; The communication interface access module is used to configure multiple doctor-patient communication channels and dynamically schedule the communication path between patients and doctors based on preset priorities and availability detection. The external hospital system layer is used to access, acquire, and provide data information from external hospital systems. The blockchain layer is used to implement blockchain-based evidence storage and the issuance, verification, revocation, and caching of QR code service data.

2. The system according to claim 1, characterized in that, The blockchain layer includes: The smart contract unit is used to implement the issuance, verification, and revocation of QR codes; Consortium blockchain node units are used to endorse, sort, and store transactions on the blockchain. Merkle batch registration unit is used for batch QR code writing in high-concurrency scenarios; Off-chain cache units are used to cache service data; The event listening unit is used to listen for QR code reversal transactions on the blockchain and broadcast a notification when a reversal event is detected. The cancellation of the QR code includes: Receive a QR code cancellation request and record the cancellation transaction on the blockchain by calling the blockchain smart contract; The system monitors blockchain events. When it detects a successful reversal of a transaction via the QR code, it broadcasts the reversal event through the event monitoring unit. This notifies the off-chain caching unit to immediately delete or mark the corresponding service data record cache as invalid and add it to the blacklist.

3. The system according to claim 1, characterized in that, The system also includes a content extension and publishing module, which receives and stores multimedia content submitted by doctors, combines artificial intelligence review and manual review mechanisms to conduct compliance review of the content, binds the approved content to a designated column on the doctor's homepage for modular display on the front end, and calls the blockchain layer to generate a unique fingerprint for the approved content for on-chain storage.

4. The system according to claim 1, characterized in that, The doctor information aggregation and display module employs a cache-first loading strategy when acquiring structured doctor information, including: First, check if the doctor's integrated information data exists in the off-chain cache layer; If the cache is hit, the structured display data is returned directly, and the front-end layer performs modular rendering before dynamically displaying it on the front-end. If the cache misses, all external hospital systems in the external hospital system layer are called in parallel to obtain multi-source data; After cleaning, standardizing, and structuring the acquired multi-source data, the results are written to a cache database and returned to the front end for modular rendering.

5. The system according to claim 1, characterized in that, When scheduling communication paths, the communication interface access module includes the following steps: Load the doctor's communication channel configuration. If only a single channel is configured, proceed directly; otherwise, enter the priority scheduling process. According to the preset priority order, the availability of each communication channel is checked in turn. If the communication channel with higher priority is available, it is immediately switched and the switching event is recorded. If it is unavailable, it enters the next communication channel. If all channels are unavailable, a message will be returned to the user.

6. The system according to claim 1, characterized in that, The system also includes a back-end management and data analysis module, which records and stores patients' behavior logs, quantifies the doctor's influence index based on the behavior logs, and outputs it to the front-end layer for display. The specific process of quantifying the physician influence index includes: Extracting multi-dimensional feature metrics from behavior logs; The multi-dimensional feature indicators are normalized or standardized. Configure corresponding weight factors for the processed feature indicators; The doctor's comprehensive influence index is obtained by weighting the weighting factors.

7. An information aggregation method for a tiered medical electronic business card system, applied to the tiered medical electronic business card system described in any one of claims 1-6, characterized in that, The method includes the following steps: The QR code generation and identification module and the blockchain layer are invoked to generate a multidimensional hash value based on the doctor's identity identifier, institution node code, timestamp, and random salt, and a unique corresponding QR code is generated based on the hash value; the batch-generated QR code identifiers are written into the blockchain through the Merkle tree batch registration mechanism, and a verifiable credential containing the doctor's professional qualification information is embedded in the QR code; After the patient scans the QR code, the doctor's structured information is obtained from at least one external hospital system through the unified interface of the doctor's electronic business card system. The doctor information aggregation and display module is called, and the doctor's homepage is dynamically generated on the front end by adopting a cache-first loading strategy and a modular rendering mechanism. By calling the communication interface access module, the front-end layer dynamically selects and redirects the patient to the optimal communication channel based on the doctor's configured communication channel list, preset priority, and real-time availability detection results. After receiving the multimedia content submitted by the doctor through the front-end layer, the content extension and publishing module is called to conduct dual review by artificial intelligence and human review. Once approved, the content is bound to the designated column on the doctor's homepage and published on the front-end layer. The system collects and records patient interaction logs on the doctor's homepage through the backend management and data analysis module. Based on the logs, the system calculates the doctor's influence index using weighting factors and outputs it to the frontend layer for display.

8. The method according to claim 7, characterized in that, The process also includes a QR code verification step when the patient scans the QR code: When a patient scans the QR code, the off-chain cache is queried first; If the cache is hit and valid, the verification passes. If the cache misses or expires, query the on-chain status of the QR code; If the QR code has been withdrawn, an invalidation message will be sent to the patient. If the QR code is still valid on the blockchain, the result will be backfilled to the off-chain cache and verified.

9. The method according to claim 7, characterized in that, The specific process of binding content to a designated section of the doctor's homepage and publishing it on the front end includes: Store the content submitted by the doctor in an object storage service and generate a content hash value; Use natural language processing models and image recognition APIs to automate pre-screening of content; If the preliminary review fails, a revision suggestion will be returned, requiring the doctor to revise and resubmit. The content that passed the preliminary review will undergo a manual review. If the manual review fails, return the application and record the reason for the failure. If the manual review is successful, the content that has passed the manual review will be bound to a specific module on the doctor's homepage, published through modular rendering, and a unique fingerprint will be generated for the content that has passed the manual review based on its corresponding content hash value and written into the blockchain for storage.

10. The method according to claim 7, characterized in that, The calculation of the doctor's influence index specifically includes: Batch processing of behavior logs, including data cleaning, deduplication and session concatenation, and extraction of multi-dimensional feature indicators including number of QR code scans, dwell time, click rate and number of communications from the processed behavior logs; The Min-Max method is used to normalize the indicators, and the Z-score method is used to standardize them. Weighting factors are assigned to each processed indicator, and a weighted sum is performed to obtain the doctor's comprehensive influence index.

Images