A family end drug monitoring system and method based on a national medical insurance drug traceability system

Abstract

The application discloses a kind of based on national medical insurance medicine traceability system's family end medicine monitoring system and method, comprising the following steps: (1) acquisition step: through intelligent terminal acquisition medicine traceability code on the minimum sales unit of medicine;(2) pre-verification step;(3) verification step: call national medical insurance medicine traceability query interface, obtain the full life cycle flow record of pre-verification successful medicine traceability code;(4) logic determination step: based on the full life cycle flow record of this medicine traceability code executes multidimensional joint determination, generates comprehensive risk score and implements graded early warning;(5) synchronization step: establish medicine traceability code, commodity bar code and national medical insurance medicine code " three codes in one " mapping relationship;(6) expiration monitoring step.The application integrates " no code not pay " policy traceability interface, " three codes in one " mapping database and backflow medicine dynamic identification algorithm organically, and closed-loop management is realized in family end.

Description

Technical Field

[0001] This invention relates to the field of medical informatization and digital governance of medical insurance, and in particular to a home-based drug monitoring system and method based on the national medical insurance drug traceability system. Background Technology

[0002] With the continuous increase in the number of home-preserved medicines, the resulting drug safety issues are becoming increasingly prominent. Existing technologies have the following three core defects: 1. "Recycled drugs" pose serious harm and are difficult to identify. "Recycled drugs" refer to illegal drugs that patients purchase using medical insurance reimbursement, then sell unused surplus drugs at low prices to unregulated recyclers, which then refurbish them, assign false codes, and re-enter the market. 1. The storage conditions for such drugs are difficult to guarantee, and their drug traceability codes may be reused, posing a significant threat to patients' health and lives. Existing home-based drug management tools that simply scan and record drug codes lack the ability to query drug traceability codes and cannot identify the risk of "returned drugs." 2. The "three codes" are fragmented, resulting in severe information silos. The drug traceability code (20 digits), the commodity barcode (EAN-13), and the national medical insurance drug code (15 digits) have long coexisted, creating data silos. Home users cannot obtain comprehensive information such as the generic name, dosage form, specifications, and authorized expiration date of drugs through a single entry point, leading to incomplete and inaccurate home drug management information. 3. The expiration date reminder function lacks authoritative data support. Some existing drug management apps provide expiration date reminders by requiring users to manually enter the expiration date, which has a high error rate. The existing solutions suffer from several problems, including high latency and low data reliability. They also lack integration with medical appointment systems, resulting in fragmented functions. Furthermore, none of the existing solutions consider intelligent estimation of remaining medication or early warning of medication shortages. 4. Medication management in home settings faces difficulties in multi-user collaboration. The elderly often experience cognitive decline and rely on their children for remote medication management. Existing technologies lack unified multi-member management, cross-terminal collaboration, and proxy operation mechanisms, leading to low efficiency in home medication management. 5. Existing solutions have insufficient data security capabilities. Home medication management involves sensitive data such as users' medical insurance accounts, identity information, prescription information, and medication records. However, existing medication management applications generally lack systematic cryptographic security solutions, mostly using plaintext storage or simple encryption, which does not meet the national commercial cryptography application security assessment (cryptographic evaluation) requirements and poses a risk of data leakage. Summary of the Invention

[0003] To address the aforementioned issues, the present invention aims to provide a home-based drug monitoring system and method based on the national medical insurance drug traceability system. This system organically integrates the "no payment without code" policy traceability interface, the "three-code integration" mapping database, and the dynamic identification algorithm for returned drugs, and achieves closed-loop management at the home level.

[0004] To achieve the above objectives, the present invention adopts the following technical solution:

[0005] A method for home-based drug monitoring based on the national medical insurance drug traceability system includes the following steps:

[0006] (1) Collection steps: Collect the 20-digit drug traceability code on the smallest sales unit of the drug through the smart terminal, and determine whether it is a general drug or a special drug based on the prefix flag of the drug traceability code;

[0007] (2) Pre-verification step: Perform local integrity pre-verification on the last 4 digits of the drug traceability code. If it fails, it is judged as a "forged code" and the online verification is rejected; if the pre-verification is successful, proceed to step (3) verification step.

[0008] (3) Verification steps: After the pre-verified drug traceability code is encrypted with the national cryptographic SM4, it is uploaded to the cloud server, and the national medical insurance drug traceability query interface is called to obtain the full life cycle circulation record of the drug traceability code;

[0009] (4) Logical judgment steps: Based on the full life cycle circulation record of the drug traceability code, perform multi-dimensional joint judgment, generate a comprehensive risk score and implement graded early warning;

[0010] (5) Synchronization steps: Establish a “three-code integration” mapping relationship between drug traceability code, commodity barcode and national medical insurance drug code, and synchronize drug structured data to the local encrypted storage of smart terminal;

[0011] (6) Expiry date monitoring steps: The local expiry date management engine of the smart terminal parses the drug expiry date field, calculates the remaining expiry date and triggers reminder instructions in different levels.

[0012] Preferably, in step (4), the multi-dimensional joint determination includes:

[0013] (1) First-level judgment, settlement frequency analysis: Count the number of sales settlements N of the drug traceability code. If N≥2, the first-level score is the preset full score of 100, and enter the second-level judgment; if N=1, the first-level score is zero, and enter the second-level judgment; if N=0, the first-level score is zero, and enter the third-level judgment.

[0014] (2) Secondary determination, combined analysis of geofencing and time series:

[0015] (I) Geofencing analysis: Compare the administrative division of the sales agency with the user's medical insurance location. If the drug is purchased across provinces and there is no record of medical treatment in another place, the geofencing score is assigned the preset full score of 50; otherwise, the geofencing score is assigned zero.

[0016] (II) Time series analysis: When N≥2, the time interval Δt1 between two adjacent sales settlement requests for the same drug traceability code is analyzed. If Δt1 is less than the shortest logistics time Tmin calculated based on distance dynamics, the time series score is assigned the preset full score of 50; otherwise, the time series score is assigned zero. When N=1, the time of the only sales settlement request is compared with the current user's scanning time. If the time difference Δt2 is greater than the set percentage M1 of the drug's expiration date, the time series score is assigned the set percentage M2 of the preset full score of 50.

[0017] Secondary rating = geofencing rating + time-series rating;

[0018] (3) Level 3 judgment and batch association analysis: Call and count the percentage M3 of abnormal drug traceability codes under the same production batch number. If the percentage M3 of abnormal drug traceability codes exceeds the preset threshold G, the verification level of all drug traceability codes under this batch is increased, and a level 3 score is assigned as the batch association risk score. The batch association risk score = preset full score 100 * percentage M3 of abnormal drug traceability codes * preset multiplier P. The maximum batch association risk score shall not exceed the preset full score 100. If the percentage of abnormal drug traceability codes is less than the preset threshold G, a level 3 score of zero is assigned. Among them, the percentage M3 of abnormal drug traceability codes = the total number of traceability codes with a level 1 or level 2 score that is not zero under the same production batch number / the total number of all traceability codes under the same production batch number.

[0019] The comprehensive risk score S = w1 * Level 1 score + w2 * Level 2 score + w3 * Level 3 score, where w1, w2, and w3 are weighted weights, and w1 + w2 + w3 = 100%. The weights are determined by an objective weighting method based on information entropy, and the weights are recalculated periodically with new data.

[0020] (4) Grading of comprehensive risk score S: The high-risk threshold T_high and the medium-risk threshold T_mid are determined by the receiver operating characteristic curve analysis method and used for grading of comprehensive risk score; when S < T_mid, it is judged as low risk, compliant and normal storage management; when T_mid ≤ S < T_high, it is judged as medium risk, the channel is abnormal, and it is recommended to verify the source; when T_high ≤ S, it is judged as high risk, suspected of being a reflux drug, and it is recommended to stop use and report it.

[0021] Preferably, for special drug types with a prefix marker of "89", the multi-dimensional joint judgment also includes a special drug special verification score: verifying whether there is a valid special drug qualification record under the special drug prescription and the user's medical insurance account. If the special drug qualification verification passes, the special drug special score is assigned a score of zero. If the special drug qualification verification fails, the special drug special score is assigned a preset special drug qualification abnormality additional score, which is 10-20 points. The comprehensive risk score S = w1 * Level 1 score + w2 * Level 2 score + w3 * Level 3 score + Special drug qualification abnormality additional score. Furthermore, in the time series analysis of the Level 2 judgment, the shortest logistics time Tmin and the set percentage M1 of the drug's expiration date are tightened to 50% of that of ordinary drugs.

[0022] Preferably, in step (2), the verification algorithm includes at least one of the Luhn algorithm and the verification rules stipulated by the National Medical Products Administration; for drug traceability codes that fail pre-verification, the system generates a local abnormal log and records the failure reason code.

[0023] Preferably, in step (5), the "three-code integration" mapping database uses the national medical insurance drug code as the primary key, associates the drug traceability code with the commodity barcode, and achieves daily incremental synchronization through the official interface of the National Medical Products Administration; the database adopts a distributed deployment architecture and supports multi-regional copy synchronization.

[0024] As a preferred option, step (6) also includes a medical treatment triggering sub-step: the system calculates the cumulative amount of medication and the remaining amount of medication based on the user's historical medication purchase records and prescription information. When the remaining amount of medication is lower than the preset dosage threshold, the system automatically triggers the medical treatment appointment interface of the smart terminal and sends a follow-up visit application instruction to the contracted doctor. The instruction includes the patient's desensitized medical insurance account, a list of medication types, an estimated time of medication interruption, and a summary of recent test results.

[0025] A monitoring system employing the aforementioned home-based drug monitoring method based on the national medical insurance drug traceability system, the system comprising:

[0026] The barcode scanning and data collection module, installed on a smart terminal, supports high-speed parsing and prefix analysis of drug traceability codes;

[0027] The local verification unit is used to perform integrity verification of the last 4 check bits of the drug traceability code and completes pre-verification before networking.

[0028] Encrypted communication module: used to encrypt the drug traceability code and related query parameters using the national cryptographic standard SM4, and then upload them to the cloud via an HTTPS secure channel;

[0029] Cloud-based traceability query service: used to connect to the national medical insurance drug traceability query interface and return the entire lifecycle transfer record;

[0030] Backflow drug dynamic identification engine: used to execute multi-dimensional joint judgment algorithm and output comprehensive risk score;

[0031] The three-code mapping database is used to store the association mapping between drug traceability codes, product codes, and medical insurance codes, as well as extended drug information.

[0032] Local expiration management engine: Used to periodically calculate remaining expiration and trigger tiered reminders;

[0033] The medical care linkage module is used to connect with the Internet hospital appointment registration interface or the family doctor contract platform. It calculates the remaining amount of medicine based on the user's historical medication purchase records and average daily usage parameters, and automatically initiates a follow-up visit application when the remaining amount of medicine is lower than a preset threshold.

[0034] Secure storage module: Used in conjunction with SM4 encryption technology and a TEE trusted execution environment to encrypt and control access to local drug data and medication records.

[0035] Preferably, the secure storage module also implements the following data security mechanisms:

[0036] 1) Transmission security: The cloud and terminal use the national cryptographic TLS 1.3 protocol, based on the SM2 / SM3 / SM4 algorithm suite;

[0037] 2) Identity desensitization: User identity identifiers are desensitized using SM3 hashing, and the original ID card number or medical insurance account number is not transmitted in plaintext;

[0038] 3) Audit Log: All verification requests retain auditable logs stored using SM3 hash chain technology to prevent subsequent tampering.

[0039] As an option, an offline caching module is also included: when the smart terminal is in a network-free or weak network environment, the system automatically switches to offline mode, performs only local pre-verification and queries cached records that have been verified within the last 30 days; the query results are marked "Offline query - results for reference only", and cloud-based supplementary verification is automatically initiated after the network is restored; offline cached data is stored using SM4 encryption.

[0040] As a preferred embodiment, it also includes at least one of the following: a regulatory data reporting module, an intelligent reminder push module, a family medicine ledger management unit, a multi-terminal data synchronization module, and a standardized open interface, wherein:

[0041] Regulatory data reporting module: After verifying the records of "suspected returned drugs" and "abnormal channels", the module automatically reports them to the medical insurance supervision platform after being digitally signed with the national cryptographic SM2. It also supports regulatory authorities to query abnormal records in batches through authorized interfaces.

[0042] Smart reminder push module: Supports push notifications from multiple channels such as in-site messages, SMS and mini-program notifications, and allows users to customize push time windows and configure recipients separately for family members;

[0043] Family Medicine Ledger Management Unit: Supports multi-member medicine list management, multi-dimensional sorting and filtering, and visualization of expiration date distribution;

[0044] Multi-terminal data synchronization module: It adopts an end-to-end encryption protocol and a last-write priority strategy to realize the synchronization of ledgers on multiple terminals within the family;

[0045] Standardized open interface: Following the RESTful API and OAuth2.0 protocol, it supports data exchange with third-party systems and provides functions such as drug traceability verification query, expiration date warning subscription and read-only access to medication ledger.

[0046] The present invention, by adopting the above technical solution, has the following beneficial effects:

[0047] 1. This invention is the first to achieve dynamic identification of "returned medicines" at the home end, relying on the traceability interface of the "no code, no payment" policy. Through a "three-level joint judgment" algorithm, it comprehensively considers four dimensions: settlement frequency, geofencing, time series and batch risk, and is combined with an interpretable scoring mechanism. The identification accuracy is significantly better than the existing single settlement frequency judgment method, and can effectively detect returned medicines disguised as normal transactions.

[0048] 2. This invention utilizes a "three-in-one" database, allowing users to obtain authoritative and complete drug data simply by scanning a code, without having to manually enter any drug information, thus reducing the data entry error rate to near zero.

[0049] 3. This invention creatively combines expiration date warning with remaining drug quantity estimation, realizing automated management of the entire process from drug expiration date monitoring to medical follow-up visits, reducing health risks caused by drug shortages or drug expiration. The three-stage graded warning design (90 / 30 / 7 days) takes into account the user experience, and is combined with intelligent push strategies such as time window control, frequency limit, aggregated push, and member-based push to avoid "warning fatigue". At the same time, the 7-day emergency warning is combined with the recommendation of the nearest recycling point, providing a complete closed-loop solution for the disposal of expired drugs.

[0050] 4. This invention adopts the national cryptographic algorithm system (SM2 / SM3 / SM4) throughout the process, combined with hardware-level key protection of the TEE trusted execution environment, which meets the requirements of the national commercial cryptography application security assessment (cryptographic evaluation) and has a high level of data security protection.

[0051] 5. The offline degradation mode of this invention ensures that the system still has basic availability in the absence of network environment, and the mechanism of automatic re-verification after network recovery ensures the eventual consistency of data.

[0052] 6. The system of the present invention features multi-family member collaborative management, multi-terminal synchronization, and a standardized open interface design, which gives the present invention good scalability and interoperability and can be seamlessly integrated into the existing medical and health information ecosystem. Attached Figure Description

[0053] Figure 1 This is a schematic diagram of the overall business process of the present invention;

[0054] Figure 2 A schematic diagram of the entity relationship model for mapping the "three codes into one" database;

[0055] Figure 3 This is a flowchart of the three-level judgment logic of the dynamic identification algorithm for refluxed drugs in this invention. Detailed Implementation

[0056] The embodiments of this application are described in detail below. The described embodiments are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0057] like Figure 1 As shown, this invention discloses a home-based drug monitoring method based on the national medical insurance drug traceability system, comprising the following steps:

[0058] (1) Data collection steps: The 20-digit drug traceability code on the smallest sales unit of the drug is collected by scanning the code with the built-in camera of a smart terminal such as a smartphone or tablet. The prefix analysis unit extracts the first and second prefix flag bits of the traceability code and determines the drug type through the locally maintained prefix rule table: the prefix "81 / 83 / 85 / 86 / 87 / 88" is determined to be a general drug, the prefix "89" is determined to be a special drug, and the prefix is ​​not in the rule table, so it is directly rejected and an anomaly log is recorded. This prefix pre-screening step is completed locally without network requests and can quickly filter obvious abnormal codes.

[0059] (2) Pre-verification step: Perform local integrity pre-verification on the last 4 digits of the drug traceability code. If it fails, it is judged as a "forged code" and the online verification is rejected. If the pre-verification is successful, proceed to step (3) verification step. The verification algorithm includes at least one of the Luhn algorithm and specific polynomial verification rules. Specifically, the verification algorithm includes two modes: Luhn algorithm and specific polynomial verification rules. The algorithm version control unit maintained locally automatically selects the corresponding verification algorithm according to the traceability code prefix. For drug traceability codes that fail the pre-verification, the system generates a local abnormal log and records the failure reason code.

[0060] (3) Verification Steps: The pre-verified drug traceability code is processed by the encrypted communication module. The encrypted communication module first uses SM4 (128-bit block cipher) to symmetrically encrypt the traceability code and its associated parameters, such as the administrative division code of the user's medical insurance location, the query timestamp, and the fingerprint hash value of the terminal device. The session key is generated through negotiation using the SM2 (asymmetric cryptography) key exchange protocol, and the key exchange process uses the SM3 hash algorithm for message authentication. The encrypted data is then uploaded to the cloud traceability query service node via the national cryptographic TLS1.3 channel (based on the SM2 / SM3 / SM4 suite) using HTTPS POST.

[0061] The cloud-based traceability query service maintains a long-lived connection pool for the national medical insurance drug traceability query interface. After calling the interface, it obtains a JSON data packet containing the entire lifecycle of the traceability code. This data packet is then structured and parsed by the cloud service to extract core fields. These core fields include at least the drug traceability code (20 digits), generic name, trade name, manufacturer name, manufacturer's unified social credit code approval number, specifications, dosage form, minimum packaging specification, production batch number, production date, expiration date, settlement serial number, settlement institution name, settlement institution code, including latitude and longitude and administrative division code, settlement time, insurance type, settlement amount, and quantity of drugs purchased.

[0062] (4) Logical Judgment Steps: Based on the full lifecycle circulation record of the drug traceability code, perform multi-dimensional joint judgment, generate a comprehensive risk score, and implement graded early warning. The multi-dimensional joint judgment specifically includes:

[0063] 1) Level 1 Judgment, Settlement Count Analysis: Count the number of sales settlements N for the drug traceability code. If N≥2, the Level 1 score is the preset full score of 100 points, and proceeds to Level 2 Judgment; if N=1, the Level 1 score is 0 points, and proceeds to Level 2 Judgment; if N=0, the Level 1 score is 0 points, marked as "self-paid drug purchase", but the system prompts on the interface "No medical insurance settlement record found, settlement dimension verification cannot be performed", and proceeds to Level 3 Judgment.

[0064] 2) Secondary determination: Geofencing and time-series joint analysis:

[0065] (I) Geofencing analysis: Extract the geographical location code of the last sales institution (the first two digits of the administrative division code, representing the provincial division), and compare it with the province to which the user's medical insurance account belongs. If the drug is purchased in a different province and there is no record of medical treatment in another place, the geofencing score is given as the preset full score of 50 points; otherwise, the geofencing score is given as 0 points.

[0066] (II) Time Series Analysis: When N≥2, the time interval Δt1 between two adjacent sales settlement requests for the same drug traceability code is analyzed. At the same time, the shortest possible logistics time T is calculated based on the spherical distance D between the two sales agencies (calculated using the Haversine formula). min =D / V_max (V_max is taken as the maximum speed of trunk logistics vehicles, 1,000 km / day), if Δt1 is less than T min If the time difference Δt2 is greater than the preset maximum score of 50, then the time-series score is assigned to the time-series score; otherwise, the time-series score is assigned to the time-series score of 0. When N=1, the time difference is compared with the time of the unique sales settlement request and the current user's scanning time. If the time difference Δt2 is greater than the set percentage M1 of the drug's expiration date, then the time-series score is assigned to the set percentage M2 of the preset maximum score of 50. The set percentage M1 of the drug's expiration date meets the following criteria: 50%≤M1≤80%. M1 can be set according to the actual situation. For example, initially, M1=70%. For a drug with an expiration date of 24 months, if the time difference Δt2 exceeds 16.8 months, it is marked as "abnormal circulation time". 40%≤M2≤60%. M2 can be set according to the actual situation. Initially, M2=50%.

[0067] Secondary rating = geofencing rating + time-series rating;

[0068] 3) Three-level judgment and batch association analysis: The system retrieves all traceability code flow data under the same production batch number and calculates the percentage (M3) of abnormal drug traceability codes under the same production batch number. If the percentage (M3) of abnormal drug traceability codes exceeds a preset threshold (G), the verification level of all drug traceability codes under that batch is increased, and a third-level score is assigned as the batch association risk score. The batch association risk score = preset full score 100 * percentage of abnormal drug traceability codes (M3) * preset multiplier (P). The maximum batch association risk score cannot exceed the preset full score of 100. If the percentage (M3) of abnormal drug traceability codes is less than the preset threshold (G), a third-level score of zero is assigned. The percentage (M3) of abnormal drug traceability codes = total number of traceability codes with non-zero first-level or second-level scores under the same production batch number / total number of all traceability codes under the same production batch number. The preset threshold (G) can be adjusted according to actual conditions; initially, the preset threshold (G) is 5%. The preset multiplier (P) can also be adjusted according to actual conditions; initially, the preset multiplier (P) is 10.

[0069] The comprehensive risk score S = w1 * Level 1 score + w2 * Level 2 score + w3 * Level 3 score, where w1, w2, and w3 are weighted weights, and w1 + w2 + w3 = 100%. The weights are determined by an objective weighting method based on information entropy, and the weights are recalculated periodically with new data.

[0070] For special drug types with a prefix marker of "89", the multi-dimensional joint judgment also includes a special drug-specific verification score: verifying whether there is a valid special drug qualification record under the special drug prescription and the user's medical insurance account. If the special drug qualification verification passes, the special drug-specific score is assigned zero points; if the special drug qualification verification fails, the special drug-specific score is assigned a preset special drug qualification anomaly additional score, which is 10-20 points. The comprehensive risk score S = w1 * Level 1 score + w2 * Level 2 score + w3 * Level 3 score + Special drug qualification anomaly additional score. Furthermore, in the time-series analysis of the Level 2 judgment, the shortest logistics time Tmin and the percentage M1 of the drug's expiration date are tightened to 50% of that of ordinary drugs, thus doubling the sensitivity of time-series anomaly detection for special drugs. Regardless of compliance, the special drug verification results are simultaneously reported to the National Healthcare Security Administration's special drug regulatory database through the regulatory data reporting module.

[0071] The specific steps of the objective weighting method based on information entropy are as follows:

[0072] (a) Constructing a calibration dataset: Using no less than 10,000 historical verification records that have been subsequently confirmed and annotated by the National Healthcare Security Administration as samples, each record contains the original score of the traceability code in three judgment dimensions and the final confirmed risk category (returned drugs / channel abnormality / compliance).

[0073] (b) Data normalization: The original score matrix X of each dimension is normalized by range standardization, x'_ij = (x_ij - min(x_j)) / (max(x_j) - min(x_j)), to eliminate the difference in dimensions;

[0074] (c) Calculate information entropy: For the normalized j-th dimension, calculate the score proportion of each sample p_ij = x'_ij / Σx'_ij, and the information entropy H_j = -k × Σ(p_ij × ln(p_ij)), where k = 1 / ln(n), and n is the total number of samples, such that 0≤H_j≤1. The smaller the information entropy H_j, the higher the discrimination and the greater the information content of this dimension among samples;

[0075] (d) Calculate the weights: the weights for each dimension are wj = (1 - H_j) / Σ(1 - H_j).

[0076] The technical principle of this method is that information entropy measures the uncertainty of data distribution. The more dispersed the scores of a certain dimension are on different samples, that is, the greater its contribution to distinguishing between returned drugs and compliant drugs, the lower its information entropy. The relative importance of each dimension can be objectively quantified by the redundancy of information entropy.

[0077] Initially, the weights for each dimension were w1=0.40, w2=0.40, and w3=0.20.

[0078] 1) Classification of the comprehensive risk score S: Using the receiver operating characteristic (ROC) curve analysis method, the high-risk threshold T_high and the medium-risk threshold T_mid are determined for the classification of the comprehensive risk score. When S < T_mid, it is judged as low risk, compliant and approved, and normally entered into the warehouse for management. When T_mid ≤ S < T_high, it is judged as medium risk, the channel is abnormal, and it is recommended to verify the source. When T_high ≤ S, it is judged as high risk, suspected of being a refluxed drug, and it is recommended to discontinue use and report it.

[0079] The high-risk threshold T_high and the medium-risk threshold T_mid used for classification were determined using receiver operating characteristic (ROC) curve analysis. The specific steps are as follows:

[0080] (a) Calibration of the high-risk threshold T_high: The confirmed "return drug" samples in the calibration dataset are taken as the positive class and the remaining samples are taken as the negative class. The ROC curve is plotted with the comprehensive score S as the discriminant variable. All candidate threshold points are traversed, and the sensitivity Se (true positive rate) and specificity Sp (true negative rate) at each threshold are calculated. The score value corresponding to maximizing the Youden index J = Se + Sp - 1 is taken as T_high.

[0081] (b) Calibration of the risk threshold T_mid: The confirmed "returned drugs" and "channel abnormalities" samples in the calibration dataset are merged into the positive class, and the "compliance passed" samples are the negative class. Similarly, ROC curves are plotted and the score value corresponding to the maximum Youden index is taken as T_mid.

[0082] (c) Threshold validation: Calculate the AUC values ​​corresponding to T_high and T_mid on the independent validation set. Only AUC ≥ 0.90 is acceptable. Otherwise, the above process is repeated after expanding the calibration dataset.

[0083] Initially, the high-risk threshold T_high=75 and the medium-risk threshold T_mid=40.

[0084] Dynamic adaptive calibration mechanism: The system sets up periodic model calibration tasks, which can be adjusted monthly, quarterly, semi-annually, or annually according to actual conditions. The system uses the cumulatively added labeled data as the incremental training set to recalculate information entropy weights and calibrate ROC thresholds. The switching between old and new models employs an A / B comparison validation mechanism: Precision, recall, and harmonic mean F1 score on the independent validation set are used as performance metrics. The new model must achieve an F1 score on the validation set no lower than the old model to be replaced and deployed; otherwise, the old model continues to run, and calibration failure logs are recorded. This dynamic adaptive calibration mechanism ensures that the scoring system automatically adjusts as the illegal drug reflux behavior patterns change, continuously maintaining optimal detection performance.

[0085] Preferably, when the calibration dataset reaches 50,000 or more entries, the system can switch to a logistic regression model for weight learning. Cases of returned drugs confirmed by regulatory authorities are used as positive samples, and compliant drugs are used as negative samples. The weights of each dimension are solved through maximum likelihood estimation. L2 regularization is used during training to prevent overfitting, and the training and validation sets are divided in an 8:2 ratio. The weight coefficients of the logistic regression model can be directly mapped to the scoring contribution of each dimension, consistent with the interpretable scoring mechanism of this invention.

[0086] (5) Synchronization steps: such as Figure 2 As shown, a unified mapping relationship is established between drug traceability codes, product barcodes, and national medical insurance drug codes, and structured drug data is synchronized to the local encrypted storage of smart terminals. The unified mapping database uses the national medical insurance drug code as the primary key, linking drug traceability codes and product barcodes. Daily incremental synchronization and weekly full-scale comparison and verification are achieved through the official interface of the National Medical Products Administration. Incremental synchronization employs a change detection mechanism based on data version numbers, synchronizing only records with updated version numbers to reduce data transmission volume. The database adopts a distributed deployment architecture, supporting synchronization of multiple regional copies.

[0087] When a mapping record for a certain traceability code does not exist in the mapping database, the system initiates an alternative query process: using the enterprise identifier segment (digits 3-7) and product identifier segment (digits 8-12) in the traceability code, it calls the drug basic information query interface published by the National Medical Products Administration to perform fuzzy matching, returns the query result to the terminal in a "pending confirmation" state for user verification, and writes it to the local mapping cache and reports it to the cloud mapping database for completion.

[0088] (6) Expiry date monitoring steps: The local expiry date management engine of the smart terminal parses the drug expiry date field, calculates the remaining expiry date, and triggers reminder instructions in different levels. The remaining days d = the last day of expiry date - the current date. When d ≤ 90 and d > 30, a mild reminder is given, suggesting a follow-up visit, and the drug entry displays a yellow warning icon, thus triggering an L1 expiry date warning; when d ≤ 30 and d > 7, an urgent reminder is given, and a counter icon is displayed, the drug entry displays an orange near-expiry icon, and the main interface counts, thus triggering an L2 near-expiry warning; when d ≤ 7, an emergency notification is given, recommending the nearest recycling point, the drug entry displays a red flashing icon, and the recycling point is navigated to, thus triggering an L3 emergency response.

[0089] When an L3 level warning is triggered, the system calls a commercial map app and recommends the three nearest drug recycling points based on the user's current GPS location, displaying the recycling station's name, address, business hours, and navigation route.

[0090] The push module supports multiple push mechanisms: in-app message push, SMS push, and notifications from health-related mini-program services. The push strategy includes the following intelligent control logic:

[0091] (a) Time window control: Users can customize the push time window. The system will not push non-emergency notifications outside the window, but L3 emergency response notifications are not subject to time window restrictions.

[0092] (b) Frequency control: The same level of reminder for the same drug shall not be pushed repeatedly within 24 hours; Level L1 shall be pushed no more than once a week, and Level L2 shall be pushed no more than once a day;

[0093] (c) Member-specific push notifications: When family members share the same family medication ledger, it supports configuring separate push notification recipients for each member. For example, the grandfather's medication expiration reminder can be configured to be pushed to both the grandfather and his children's mobile devices simultaneously;

[0094] (d) Aggregated push notifications: When multiple medications trigger the same level of alerts within the same time period, the system will aggregate the multiple alerts into a single summary push notification to avoid push notification bombardment.

[0095] Step (6) also includes a medical appointment triggering sub-step: the system calculates the cumulative medication and remaining medication based on the user's historical medication purchase records and prescription information. When the remaining medication is lower than the preset dosage threshold, the system automatically triggers the medical appointment interface of the smart terminal and sends a follow-up visit application instruction to the contracted doctor. The instruction includes the patient's desensitized medical insurance account, a list of medications, an estimated time of medication interruption, and a summary of recent test results. After receiving the application, the doctor's workstation can confirm the appointment with one click, and the confirmation result is pushed to the patient's terminal in real time via push notification.

[0096] Specifically, the system obtains the medical insurance payment record corresponding to the current drug through the "three-code integration" database (including the purchase quantity of each settlement, purchase_qty), and combines it with the user-defined daily average usage parameter (tablets / capsules / ml / day) to estimate the current remaining drug quantity using a formula:

[0097] Remaining medication quantity = Σ(quantity of each purchase) - Σ(average daily usage × number of days used since purchase date);

[0098] When the remaining medication dosage is less than or equal to the threshold Q, the medical follow-up appointment application process is triggered. Threshold Q = average daily dosage * n days, where n is 1-7 days.

[0099] This invention also discloses a monitoring system employing the home-based drug monitoring method based on the national medical insurance drug traceability system as described above, the system comprising:

[0100] The barcode scanning and data collection module, installed on a smart terminal, supports high-speed parsing and prefix analysis of drug traceability codes;

[0101] The local verification unit is used to perform integrity verification of the last 4 check bits of the drug traceability code and completes pre-verification before networking.

[0102] Encrypted communication module: used to encrypt the drug traceability code and related query parameters using the national cryptographic standard SM4, and then upload them to the cloud via an HTTPS secure channel;

[0103] Cloud-based traceability query service: used to connect to the national medical insurance drug traceability query interface and return the entire lifecycle transfer record;

[0104] Backflow drug dynamic identification engine: used to execute multi-dimensional joint judgment algorithm and output comprehensive risk score;

[0105] The three-code mapping database is used to store the association mapping between drug traceability codes, product codes, and medical insurance codes, as well as extended drug information.

[0106] Local expiration management engine: Used to periodically calculate remaining expiration and trigger tiered reminders;

[0107] The medical care linkage module is used to connect with the Internet hospital appointment registration interface or the family doctor contract platform. It calculates the remaining amount of medicine based on the user's historical medication purchase records and average daily usage parameters, and automatically initiates a follow-up visit application when the remaining amount of medicine is lower than a preset threshold.

[0108] Secure storage module: Used in conjunction with SM4 encryption technology and a TEE trusted execution environment to encrypt and control access to local drug data and medication records.

[0109] Preferably, the secure storage module also implements the following data security mechanisms:

[0110] 1) Transmission security: The cloud and terminal use the national cryptographic TLS 1.3 protocol, based on SM2 key exchange, SM3 message authentication, and SM4 data encryption suite; all communication from the smart terminal to the cloud server is completed within this encrypted channel.

[0111] 2) Storage security: Local drug data and medication records are stored using SM4 symmetric encryption.

[0112] 2) Identity Anonymization: User identity identifiers are anonymized using SM3 hashing before uploading, ensuring that the original ID card number or medical insurance account number is not transmitted in plaintext; this ensures that third-party interfaces do not access the original identity information. The anonymized hash value serves as the user's unique anonymous identifier in the system.

[0113] 3) Audit Logs: All traceability code verification operation logs are stored in the form of a hash chain. The log sequence forms a unidirectional chain structure, and all verification requests retain auditable logs stored using SM3 hash chain technology to prevent subsequent tampering.

[0114] The trusted execution environment in the secure storage module meets the following technical requirements:

[0115] (a) The TEE conforms to the GlobalPlatform TEE specification (version ≥ 1.2) or the ARM TrustZone standard, providing an independent secure memory region (Secure World) at the processor level, which is hardware-level isolated from the normal memory region (Normal World / Rich OS) run by a normal operating system;

[0116] (b) The key materials stored in the TEE (including the SM4 symmetric key, SM2 private key and PBKDF2 salt value) cannot be directly read by Rich OS and any ordinary application running on it through system calls, memory mapping or debugging interfaces; key usage operations (encryption, decryption, signing) can only be completed through secure API calls provided by the TEE, and the key materials do not leave the boundaries of the TEE.

[0117] (c) The TEE performs a Secure Boot Chain verification each time the device starts up, calculates the SM3 integrity check value for the stored key materials and compares it with the pre-stored benchmark value; if any inconsistency is detected (indicating possible tampering or root attack), the TEE immediately performs a Secure Erase operation, clears all key materials in the TEE, and sends a "security environment abnormal" warning notification to the user through the application layer, guiding the user to re-register biometric information to rebuild the key system;

[0118] (d) The TEE also performs the digital signature function for traceability code verification requests: each verification request uploaded to the cloud is signed by the SM2 private key within the TEE, and the cloud server uses the corresponding SM2 public key to verify the signature, ensuring that the request source is trustworthy and has not been tampered with. This mechanism can effectively defend against man-in-the-middle attacks and request forgery attacks.

[0119] The monitoring system in this invention also includes an offline caching module: when the smart terminal is in a network-free or weak network environment, the system automatically switches to offline mode.

[0120] Verification process in offline mode:

[0121] (a) Local pre-checking is performed as usual: the prefix check and the last 4 check bits of the traceability code are both completed locally and are not affected by the network status;

[0122] (b) Local Cache Query: The system maintains an encrypted cache database locally—the offline cache module—which stores traceability codes verified through the cloud within the past 30 days and their associated complete drug information. In offline mode, the system uses the currently scanned traceability code as the search key to find matching records in the local cache;

[0123] (c) Cache hit handling: If a matching record is found in the cache, the system displays the drug information and the last verification result of the record, but marks it in a striking blue on the interface as "Offline query - the result is based on cached data of [last verification date] and is for reference only";

[0124] (d) Cache miss handling: If there is no matching record in the cache, the system will only display the local pre-verification result (valid / forged code) and prompt "Currently offline, unable to complete cloud verification, please rescan after connecting to the network", and add the traceability code to the "verification queue";

[0125] (e) Cache Expiration Management: Cache records are set to have a 30-day expiration period. Expired cache records are automatically marked "Cache expired - requires re-internet verification" when queried, prompting users not to rely on the result. Expired cache records are not automatically deleted, but are displayed in a gray semi-transparent style on the interface to clearly distinguish them from valid cache records;

[0126] (f) Automatic Supplementary Verification Upon Network Recovery: When the system detects network recovery, it automatically initiates supplementary verification requests to the cloud according to the priority of traceability codes in the "Verification Queue," for example, special drugs take precedence over general drugs, and recent scans take precedence over earlier scans. After the supplementary verification is completed, the local cache status is updated. If the supplementary verification result is inconsistent with the offline display result, the system proactively pushes a correction notification to the user.

[0127] (g) Offline cached data security: Offline cached data is also stored using SM4 encryption, and the key is the same as the local storage key in online mode, both of which are hosted in TEE.

[0128] It also includes at least one of the following: a regulatory data reporting module, an intelligent reminder push module, a family medicine ledger management unit, a multi-terminal data synchronization module, and a standardized open interface, wherein:

[0129] Regulatory data reporting module: After verifying the records of "suspected returned drugs" and "abnormal channels", the module automatically reports them to the medical insurance supervision platform after being digitally signed with the national cryptographic SM2. It also supports regulatory authorities to query abnormal records in batches through authorized interfaces.

[0130] Smart reminder push module: Supports push notifications from multiple channels such as in-site messages, SMS and mini-program notifications, and allows users to customize push time windows and configure recipients separately for family members.

[0131] The family medicine ledger management unit supports multi-member medicine list management, multi-dimensional sorting and filtering, and visualization of expiration date distribution. A specific example is provided below:

[0132] (a) Multi-member management: Supports the creation of multiple sub-accounts for medication users under the same family medication ledger. Each sub-account is associated with its own medical insurance account and an independent medication list. The system sets up a master administrator account with the following permissions: view the medication list of all family members, receive summary information on expiration dates for all members, and perform barcode scanning and medical appointment operations on behalf of the user.

[0133] (b) Multi-dimensional sorting and filtering: Supports sorting and filtering of the drug list by the following dimensions: by member, by drug type, by expiration date and urgency, and by medical insurance category;

[0134] (c) Visualization: Two types of visualization charts are provided: ① Bar chart - showing the distribution of the number of medicines and their expiration status for each member; ② Calendar heat map - showing the number of medicines expiring on each date within the next 90 days in the form of a monthly calendar. The shade of color indicates the number of medicines expiring, making it easy for the family manager to grasp the expiration status of the family's medicines at a glance.

[0135] (d) Customizable daily dosage parameters: Each drug supports setting its own daily dosage parameters. The system optimizes the accuracy of remaining drug dosage estimation based on these parameters and displays the expected expiration date on the drug details page.

[0136] Multi-terminal data synchronization module: Employs an end-to-end encryption protocol and a last-write-first-preference strategy to achieve multi-terminal ledger synchronization within a household.

[0137] (a) Multi-terminal access: The same family's medicine ledger can be accessed and logged in on multiple smart terminals. Each terminal establishes a connection with the cloud synchronization service through the unique identifier of the family ledger;

[0138] (b) End-to-End Encrypted Synchronization: Data synchronization between multiple terminals adopts an end-to-end encrypted (E2EE) protocol. Specifically, when a family ledger is created, an SM2 asymmetric key pair is generated, and the private key is stored only in the TEE of the main administrator device; other family terminals obtain the derived key by scanning the QR code for authorization on the main administrator device. Synchronization data is encrypted using an SM4 symmetric key at the sending end and then uploaded to the cloud relay server. The cloud server only stores the encrypted ciphertext, does not hold the decryption key, and cannot access the plaintext data; the receiving end downloads the ciphertext from the cloud and decrypts it locally.

[0139] (c) Conflict Resolution Strategy: When multiple terminals edit the same drug ledger record within a short period of time, the system adopts a last-write-first-return strategy to resolve conflicts, with the last write operation reaching the cloud taking precedence. Simultaneously, the system maintains operation logs locally on each terminal, recording the timestamp, operation content, and terminal identifier for each edit operation. This allows the main administrator to review the conflict resolution history on the "Synchronization Log" page and, if necessary, manually roll back to any historical version.

[0140] Standardized open interface: Following the RESTful API and OAuth2.0 protocol, it supports data exchange with third-party systems and provides functions such as drug traceability verification query, expiration date warning subscription and read-only access to medication ledger.

[0141] The following are some specific examples:

[0142] Example 1: Single-item drug verification and information synchronization (typical scenario)

[0143] After purchasing a brand of antihypertensive drug (traceability code prefix "85", belonging to the general drug category) from a designated pharmacy, the user can open the smart terminal application of this invention to scan the 20-digit traceability code on the drug packaging.

[0144] The local verification unit then performs Luhn algorithm verification on the last 4 check bits. The encrypted communication module negotiates the session key (SM4, 128 bits) through SM2 key exchange, and uploads the traceability code and the user's medical insurance location (provincial administrative division code, desensitized by SHA-256) to the cloud traceability query service through the national cryptographic TLS1.3 channel after SM4 encryption.

[0145] The cloud-based traceability query service calls the National Medical Insurance Drug Traceability Query Interface and returns the circulation record: the drug was sold and settled once in the current month at a designated pharmacy in this city, the sales agency code matches the drug purchase invoice provided by the user, and the geographical location (provincial administrative division code) is consistent. The return drug dynamic identification engine performs a three-level judgment: Level 1 score = 0 (settlement count = 1); Level 2 score = 0 (same province, no cross-provincial anomalies; no multiple settlement records with comparable time series); Level 3 score = 0 (batch anomaly rate < 5%). The comprehensive score S = 0, and it is judged as "low risk, compliant and passed".

[0146] The system then calls the "three-code integration" mapping database to automatically extract the drug's generic name (amlodipine tablets), specifications (5mg×28 tablets), production batch number (batch number: 202501ZB), and expiration date (expiration date: 2026-12). This information is then encrypted using SM4 and written to the drug ledger maintained by the local expiration date management engine. The smart terminal interface displays the verification results and drug details to the user. Simultaneously, the expiration date management engine records approximately 300 days remaining until the expiration date, and no alert is triggered at this time.

[0147] Example 2: Backflow drug identification triggers alarm (high-risk scenario)

[0148] A user purchased a targeted anticancer drug (prefix "89", classified as a special drug) through unofficial channels. After scanning the code, the cloud-based traceability service returned a transaction record showing that the traceability code had been used for medical insurance settlement once three months ago at a designated hospital (institution code prefix: 6XX) in a western province (settlement amount: 21,600 yuan), and a second settlement record was recorded in the same month at a private clinic in the same city (institution code prefix: 1XX). The two settlement locations are approximately 2,100 kilometers apart and the time interval is only 72 hours.

[0149] The reflux drug dynamic identification engine performs a three-level joint judgment: Level 1 score = 100 points (number of settlements = 2); Level 2 score calculation: geofencing score = 50 points (cross-province and no out-of-town medical treatment record), time series score: Δt1 = 72 hours = 3 days, D = 2,100 kilometers, T min =2,100 / 1,000 = 2.1 days, Δt > T min The time-series score is 0. The third-level score, based on the batch correlation analysis, shows that out of 4,000 traceability codes for this batch (batch number: 202410TC), 68 abnormal codes were found. The percentage of abnormal drug traceability codes, M3, is 1.7% < 5%, resulting in a third-level score of 0. In this assessment, the weighted averages w1=0.40, w2=0.40, w3=0.20, and the overall risk score S=0.4*100+0.4*50+0.2*0=60.

[0150] Because the drug is a special drug type (prefix "89"), the system automatically triggers a special drug verification: verifying the prescription holder corresponding to the traceability code, it finds that the prescription holder's medical insurance account hash is inconsistent with the current user's medical insurance account hash, and determines it as "abnormal special drug qualification", adding a preset special drug qualification abnormality bonus of 15 points. The final comprehensive score S=60+15=75 points, reaching the high-risk threshold (≥75 points), and is determined as "high-risk suspected return drug".

[0151] Example 3: Expiration date warning and automatic linkage with medical treatment (chronic disease continuous medication scenario)

[0152] The user log records an oral medication for treating type 2 diabetes (2 tablets daily, average daily dosage: 2 tablets / day), valid until February of the following year, with an expiration date of 2026-02-28.

[0153] The current date is November 30, 2025, with 92 days left until expiration. No warning will be triggered at this time. On December 2, 2025, d=90, an L1 "Expiration Warning" push notification will be triggered, with the following content: "Your glimepiride tablets (specification: 2mg×60 tablets) will expire on February 28, 2026, with only 90 days left. Please arrange a follow-up visit in time."

[0154] On January 29, 2026, with 30 days remaining until expiration, the expiration management engine triggered an L2 "Near-Expiration Reminder" push notification. Simultaneously, the drug ledger entry on the application's main interface displayed an orange near-expiration badge. The notification added an urgency reminder: "Glimepiride tablets have only 30 days until expiration; please use them first."

[0155] Meanwhile, the remaining medication quantity estimation sub-model continues to operate: the user's historical medical insurance settlement record shows that the most recent purchase was 60 tablets on January 20, 2026. As of January 29, 2026, 9 days × 2 tablets / day = 18 tablets had been used, leaving 60 - 18 = 42 tablets remaining. When the remaining medication quantity = 42 tablets > 6 tablets (the 3-day supply threshold), no medical treatment application is triggered.

[0156] As of February 18, 2026, the remaining medication dosage was calculated to be 4 tablets, which is below the 3-day dosage threshold of 6 tablets. The medical service linkage module automatically sent a follow-up visit request to the contracted community doctor. The request included: the patient's desensitization label, glimepiride medication usage information, and a summary of the fasting blood glucose test results for the past 30 days (from the user's authorized shared personal health record). The community doctor confirmed the appointment with one click, and the patient received a push notification: "Your follow-up visit appointment has been confirmed. Appointment time: 9:00 AM, February 20, 2026. Appointment location: XX Community Health Service Center."

[0157] Example 4: Unified Management of Medicines in Multi-Member Families

[0158] A family of three: The grandfather (75 years old) takes one type of antihypertensive drug (amlodipine tablets) and one type of hypoglycemic drug (glimepiride tablets); the grandmother (70 years old) takes one type of osteoporosis drug (alendronate sodium); and the child (45 years old) takes one type of loratadine tablets due to seasonal allergies.

[0159] The children, acting as the primary administrators, create a family ledger within the application, establishing three sub-accounts for each medication user, corresponding to the medication lists of the three individuals. Each account is linked to their respective medical insurance account (with anonymized data). The ledger management unit maintains the expiration date and average daily usage parameters for each medication separately, calculating the remaining shelf life and remaining dosage.

[0160] Children through calendar heat Figure 1 This overview shows the distribution of all family medication expiration dates: The current month's highlighted section indicates "Grandma's Alendronate Sodium - Near Expiration - 14 Days Left," allowing children to easily request a follow-up appointment for Grandma; the next month's section indicates "Grandpa's Amlodipine Tablets - Warning - 45 Days Left." The bar chart provides a clear picture of Grandpa's two medications, Grandma's one, and their own, along with the distribution of each medication's expiration date.

[0161] Regarding push notification settings, the children configured all expiration date reminders for their grandparents' medications to be sent simultaneously to both their own and their children's phones, ensuring that the children are aware of the situation even if the elderly person misses the reminder. The children's own loratadine tablet reminders are only sent to their own phones.

[0162] Through unified management from a family perspective, children can efficiently arrange medical treatment and medication purchase plans for the whole family, significantly reducing the cognitive burden of elderly people managing multiple medications independently and improving the safety of family medication use.

[0163] Example 5: Drug Inquiry in Offline Scenarios

[0164] While visiting his parents in his rural hometown, the user encountered a weak mobile network signal, only a 2G signal, and frequent disconnections. The user used his mobile device to scan the traceability code of a type of blood sugar-lowering medication his father was taking.

[0165] The system sends a heartbeat packet to the cloud server. If there is no response after three consecutive timeouts, it automatically switches to offline downgrade mode, and a blue "Offline Mode" indicator bar is displayed at the top of the interface.

[0166] Local pre-verification proceeds as normal: prefix verification passed (prefix "83", general medicine), and check bit verification passed.

[0167] The system retrieved the traceability code from its local cache and found that the drug had been scanned and verified via cloud verification 15 days prior when the user connected to the city's online system. The verification result was "Low Risk, Compliant Passed," and the cached record was still within its 30-day validity period. The system displayed the cached drug information (generic name: metformin extended-release tablets, specification: 500mg × 30 tablets, expiration date: 2026-06), and marked it in blue: "Offline query—results based on cached data from 2026-02-10, for reference only."

[0168] The user then scanned another blood pressure medication for their father. This medication had not been scanned before, and there was no matching record in the local cache. The system only displayed the local pre-verification result: "The traceability code format is valid (prefix: 85, common drug), but it is currently offline and cannot complete cloud verification. Please rescan after connecting to the internet." At the same time, the traceability code was automatically added to the "pending verification queue."

[0169] The following day, the user returned to their city residence and connected their phone to Wi-Fi. The system detected network recovery, automatically retrieved the antihypertensive medication traceability code from the "Verification Queue," and initiated supplementary cloud verification. Upon successful verification, the local cache was updated with complete medication information, and the system sent a notification to the user: "The medication you scanned in offline mode has completed cloud verification—Amlodipine Tablets (5mg x 28 tablets). Verification result: Low risk, compliant."

[0170] Example 6: Multi-terminal collaborative management

[0171] Continuing from the scenario of a family of three in Example 4, after the children create a family ledger on their own mobile phones, they need to be able to access the same ledger on their grandfather's tablet and their grandmother's mobile phones.

[0172] The children access the "Device Management" page on their mobile phones, click "Add Family Device," and the system generates a QR code containing encrypted authorization information. The grandfather scans this QR code with his tablet, and the system securely transfers the derived key between the two devices via the SM2 key exchange protocol, completing the device authorization and binding. The same process is used to bind the grandmother's phone.

[0173] Afterward, all three devices can access the same family medication ledger. When the children scan a code on their phones to add a medication (lipid-lowering drug) for their grandfather, the new record is encrypted with SM4 and uploaded to the cloud relay server. The grandfather's tablet and grandmother's phone download the encrypted data from the cloud and decrypt it locally during the next synchronization cycle (automatic synchronization every 15 minutes by default, or manual instant synchronization can be triggered). The ledger data on the three devices remains consistent.

[0174] One day, the children changed their grandfather's daily dosage of blood pressure medication from one tablet to two tablets on their phones. Almost simultaneously, the grandfather accidentally deleted the medication on his tablet. The children's changes reached the cloud first, followed by the grandfather's deletion. Following the LWW (Large-Time Flow) policy, the system prioritized the grandfather's deletion. After syncing their phones, the children found the medication missing. They opened the "Sync Log" page and saw the change record. After confirming it was a mistake by their grandfather, the children clicked "Rollback to this version" in the Sync Log, restoring the medication record and retaining the modified daily dosage.

[0175] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, alterations, deletions of some features, additions of features, or recombinations of features to the above embodiments within the scope of the present invention without departing from the principles and spirit of the present invention. Any simple modifications, equivalent changes, and alterations made to the above embodiments based on the innovative principles of the present invention shall still fall within the scope of the technical solutions of the present invention.

Claims

1. A method for home-based drug monitoring based on the national medical insurance drug traceability system, characterized in that, Includes the following steps: (1) Collection steps: Collect the 20-digit drug traceability code on the smallest sales unit of the drug through the smart terminal, and determine whether it is a general drug or a special drug based on the prefix flag of the drug traceability code; (2) Pre-verification step: Perform local integrity pre-verification on the last 4 digits of the drug traceability code. If it fails, it is judged as a "forged code" and the online verification is rejected; if the pre-verification is successful, proceed to step (3) verification step. (3) Verification steps: After the pre-verified drug traceability code is encrypted with the national cryptographic SM4, it is uploaded to the cloud server, and the national medical insurance drug traceability query interface is called to obtain the full life cycle circulation record of the drug traceability code; (4) Logical judgment steps: Based on the full life cycle circulation record of the drug traceability code, perform multi-dimensional joint judgment, generate a comprehensive risk score and implement graded early warning; (5) Synchronization steps: Establish a "three-code integration" mapping relationship between drug traceability code, commodity barcode and national medical insurance drug code, and synchronize drug structured data to the local encrypted storage of smart terminal; (6) Expiry date monitoring steps: The local expiry date management engine of the smart terminal parses the drug expiry date field, calculates the remaining expiry date and triggers reminder instructions in different levels.

2. The method for home-based drug monitoring based on the national medical insurance drug traceability system according to claim 1, characterized in that, In step (4), the multi-dimensional joint determination includes: (1) First-level judgment, settlement frequency analysis: Count the number of sales settlements N of the drug traceability code. If N≥2, the first-level score is the preset full score of 100, and proceed to the second-level judgment; if N=1, the first-level score is zero, and proceed to the second-level judgment; if N=0, the first-level score is zero, and proceed to the third-level judgment; (2) Second-level judgment, geofencing and time series joint analysis: (I) Geofencing analysis: Compare the administrative division of the sales agency with the user's medical insurance location. If the drug is purchased across provinces and there is no record of medical treatment in another place, the geofencing score is assigned the preset full score of 50; otherwise, the geofencing score is assigned zero. (II) Time Series Analysis: When N≥2, analyze the time interval Δt1 between two adjacent sales settlement requests for the same drug traceability code. If Δt1 is less than the shortest logistics time T calculated based on distance dynamics... min If the time difference is greater than the set percentage M1 of the drug's expiration date, then the time-series score is assigned to the preset full score of 50; otherwise, the time-series score is assigned to zero. When N=1, the time of the only sales settlement request and the current user's scanning time are compared. If the time difference Δt2 is greater than the set percentage M1 of the drug's expiration date, then the time-series score is assigned to the set percentage M2 of the preset full score of 50. Secondary rating = geofencing rating + time-series rating; (3) Level 3 judgment and batch association analysis: Call and count the percentage M3 of abnormal drug traceability codes under the same production batch number. If the percentage M3 of abnormal drug traceability codes exceeds the preset threshold G, the verification level of all drug traceability codes under this batch is increased, and a level 3 score is assigned as the batch association risk score. The batch association risk score = preset full score 100 * percentage M3 of abnormal drug traceability codes * preset multiplier P. The maximum batch association risk score shall not exceed the preset full score 100. If the percentage of abnormal drug traceability codes is less than the preset threshold G, a level 3 score of zero is assigned. Among them, the percentage M3 of abnormal drug traceability codes = the total number of traceability codes with a level 1 or level 2 score that is not zero under the same production batch number / the total number of all traceability codes under the same production batch number.

3. The comprehensive risk score S = w1 * Level 1 score + w2 * Level 2 score + w3 * Level 3 score, where w1, w2, and w3 are weighted weights, and w1 + w2 + w3 = 100%. The weights are determined by an objective weighting method based on information entropy, and the weights are recalculated periodically with new data. (4) Grading of comprehensive risk score S: The high-risk threshold T_high and the medium-risk threshold T_mid are determined by the receiver operating characteristic curve analysis method and used for grading of comprehensive risk score; when S < T_mid, it is judged as low risk, compliant and normal storage management; when T_mid ≤ S < T_high, it is judged as medium risk, the channel is abnormal, and it is recommended to verify the source; when T_high ≤ S, it is judged as high risk, suspected of being a reflux drug, and it is recommended to stop use and report it.

4. A method for home-based drug monitoring based on the national medical insurance drug traceability system according to claim 1, characterized in that, For special drug types with a prefix flag of "89", the multi-dimensional joint judgment also includes a special drug-specific verification score: verifying whether there is a valid special drug qualification record under the special drug prescription and the user's medical insurance account. If the special drug qualification verification passes, the special drug-specific score is assigned zero points; if the special drug qualification verification fails, the special drug-specific score is assigned a preset special drug qualification abnormality additional score, which is 10-20 points. The comprehensive risk score S = w1 * Level 1 score + w2 * Level 2 score + w3 * Level 3 score + Special drug qualification abnormality additional score. Furthermore, in the time-series analysis of the secondary judgment, the shortest logistics time T min And the percentage of the drug's shelf life set by M1 is tightened to 50% of that of general drugs.

5. A method for home-based drug monitoring based on the national medical insurance drug traceability system according to claim 1, characterized in that, In step (2), the verification algorithm includes at least one of the Luhn algorithm and the verification rules stipulated by the National Medical Products Administration; for drug traceability codes that fail pre-verification, the system generates a local abnormal log and records the failure reason code.

6. A method for home-based drug monitoring based on the national medical insurance drug traceability system according to claim 1, characterized in that, In step (5), the "three-code integration" mapping database uses the national medical insurance drug code as the primary key, associates the drug traceability code with the commodity barcode, and achieves daily incremental synchronization through the official interface of the National Medical Products Administration; the database adopts a distributed deployment architecture and supports multi-regional copy synchronization.

7. A method for home-based drug monitoring based on the national medical insurance drug traceability system according to claim 1, characterized in that, Step (6) also includes a medical treatment triggering sub-step: the system calculates the cumulative amount of medication and the remaining amount of medication based on the user's historical medication purchase records and prescription information. When the remaining amount of medication is lower than the preset dosage threshold, the system automatically triggers the medical treatment appointment interface of the smart terminal and sends a follow-up visit application instruction to the contracted doctor. The instruction includes the patient's desensitized medical insurance account, a list of medication types, an estimated time of medication interruption, and a summary of recent test results.

8. A monitoring system employing the home-based drug monitoring method based on the national medical insurance drug traceability system as described in any one of claims 1-6, characterized in that, The system includes: The barcode scanning and data collection module, installed on a smart terminal, supports high-speed parsing and prefix analysis of drug traceability codes; The local verification unit is used to perform integrity verification of the last 4 check bits of the drug traceability code and completes pre-verification before networking. Encrypted communication module: used to encrypt the drug traceability code and related query parameters using the national cryptographic standard SM4, and then upload them to the cloud via an HTTPS secure channel; Cloud-based traceability query service: used to connect to the national medical insurance drug traceability query interface and return the entire lifecycle transfer record; Backflow drug dynamic identification engine: used to execute multi-dimensional joint judgment algorithm and output comprehensive risk score; The three-code mapping database is used to store the association mapping between drug traceability codes, product codes, and medical insurance codes, as well as extended drug information. Local expiration management engine: Used to periodically calculate remaining expiration and trigger tiered reminders; Medical Treatment Linkage Module: Used to connect with the Internet hospital appointment registration interface or family doctor contract platform, calculate the remaining medication quantity based on the user's historical medication purchase records and average daily usage parameters, and automatically initiate a follow-up visit request when the remaining medication quantity is lower than a preset threshold; Secure Storage Module: Used to encrypt and store local drug data and medication records and control access by using SM4 encryption technology combined with a TEE trusted execution environment.

9. A home-based drug monitoring system based on the national medical insurance drug traceability system according to claim 7, characterized in that, The secure storage module also implements the following data security mechanisms: 1) Transmission security: The cloud and terminal use the national cryptographic TLS 1.3 protocol, based on the SM2 / SM3 / SM4 algorithm suite; 2) Identity desensitization: User identity identifiers are desensitized using SM3 hashing, and the original ID card number or medical insurance account number is not transmitted in plaintext; 3) Audit Log: All verification requests retain auditable logs stored using SM3 hash chain technology to prevent subsequent tampering.

10. A home-based drug monitoring system based on the national medical insurance drug traceability system according to claim 7, characterized in that, It also includes an offline caching module: when the smart terminal is in a network-free or weak network environment, the system automatically switches to offline mode, performs only local pre-verification and queries cached records that have been verified within the last 30 days; the query results are marked "Offline query - results for reference only", and cloud-based supplementary verification is automatically initiated after the network is restored; offline cached data is stored using SM4 encryption.

11. A home-based drug monitoring system based on the national medical insurance drug traceability system according to claim 7, characterized in that, It also includes at least one of the following modules: a regulatory data reporting module, an intelligent reminder push module, a family medicine ledger management unit, a multi-terminal data synchronization module, and a standardized open interface. Specifically: The regulatory data reporting module automatically reports verification records of "suspected returned drugs" and "channel anomalies" to the medical insurance regulatory platform after being digitally signed using the national cryptographic SM2 standard, and supports regulatory departments in batch querying of abnormal records through authorized interfaces; The intelligent reminder push module supports push notifications through multiple channels such as in-site messages, SMS, and mini-program notifications, and allows users to customize push time windows and configure recipients separately for family members. Family Medicine Ledger Management Unit: Supports multi-member medicine list management, multi-dimensional sorting and filtering, and visualization of expiration date distribution; Multi-terminal data synchronization module: It adopts an end-to-end encryption protocol and a last-write priority strategy to realize the synchronization of ledgers on multiple terminals within the family; Standardized open interface: Following the RESTful API and OAuth2.0 protocol, it supports data exchange with third-party systems and provides functions such as drug traceability verification query, expiration date warning subscription and read-only access to medication ledger.

Images