A blockchain-based family doctor subscription data security interaction method and system
By using blockchain-based classified and hierarchical storage, smart contract dynamic authorization, and full-process traceability auditing, the security and trustworthiness issues of family doctor contract data across multiple institutions have been resolved, achieving trusted data storage, trusted interaction, and trusted auditing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 北京啄木鸟云健康科技有限公司
- Filing Date
- 2026-04-10
- Publication Date
- 2026-07-10
AI Technical Summary
Existing technologies suffer from insufficient security, reliability, dynamic control capabilities, and end-to-end traceability in the storage, authorization, sharing, and auditing processes of family doctor contract data.
Using a blockchain-based approach, sensitive data is encrypted and stored in an off-chain database through classified and hierarchical management, while key summary information is stored on the blockchain. Smart contracts are used for dynamic access control, a unified data interaction interface is used for legality verification, and access logs are collected for full traceability and auditing.
It achieves improved data storage credibility and integrity while ensuring data privacy, enhanced the credibility and automation of the authorization process, improved the security and authenticity of cross-organizational data interaction, and realized trusted traceability and auditing throughout the entire lifecycle.
Smart Images
Figure CN122369760A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of medical and health data security management and data interaction technology, and in particular to a blockchain-based method and system for secure data interaction in family doctor contracting. Background Technology
[0002] Family doctor contract services play a vital role in the primary healthcare system, generating a large amount of resident contract information, doctor service records, follow-up data, and health management data during the related processes. This data is characterized by its multi-source nature, continuity, and sensitivity, and is typically collected, stored, and used separately by different healthcare institutions. In practice, family doctor contract data not only needs to be used within community health service institutions but also requires access, sharing, and verification among higher-level hospitals, medical insurance platforms, and regulatory departments. Therefore, this places high demands on secure data storage, trusted authorization, cross-institutional interaction, and end-to-end auditing.
[0003] In existing technologies, family doctor contract data is typically managed using centralized databases, and data sharing between different institutions often relies on interface connections, manual approval, or static authorization based on account permissions. This approach has the following shortcomings: First, centralized storage of sensitive data easily creates single points of risk, making it difficult to detect unauthorized access, tampering, or leakage in a timely manner. Second, data access control between different institutions lacks a unified and reliable authorization mechanism, with unclear authorization boundaries and insufficient dynamic revocation and fine-grained control capabilities. Third, during cross-institutional data interaction, the authenticity of data sources, the integrity of transmission, and the traceability of access behavior are weak, making it difficult to achieve reliable auditing of the entire data lifecycle. Fourth, existing log records are usually stored in each institution's local system, lacking tamper-proof capabilities, which is detrimental to subsequent regulatory verification and accountability.
[0004] Therefore, there is an urgent need for a family doctor contract data security interaction technology solution that can take into account data security storage, dynamic authorization control, cross-institutional trusted interaction, and full-process traceability and auditing, in order to solve the above-mentioned problems existing in the current technology. Summary of the Invention
[0005] The main objective of this invention is to provide a secure interaction method and system for family doctor contract data based on blockchain, in order to solve the problems of insufficient security, insufficient trust, insufficient dynamic control capabilities, and insufficient full-process traceability capabilities in the storage, authorization, sharing, and auditing processes of family doctor contract data in the prior art.
[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A blockchain-based method for secure data exchange in family doctor contract signing includes the following steps: Acquire family doctor contract data, classify and manage the family doctor contract data according to level, encrypt sensitive data and store it in an off-chain database, and store the key summary information of the family doctor contract data on the blockchain; Based on smart contracts, the access permissions of different roles are dynamically controlled, operations on the family doctor contract data are automatically verified and executed, and authorization certificates are generated and stored on the blockchain. The system receives data access requests through a unified data interaction interface, verifies the legality of the data access requests based on the authorization credentials, and performs cross-organizational data interaction after the verification is successful. Access logs are collected during the operation and transfer of family doctor contract data. These access logs are stored on the blockchain, and the family doctor contract data is traced and audited throughout the entire process using on-chain hash verification and timestamp mechanisms.
[0007] Preferably, the family doctor contract data includes resident contract information, doctor service records, follow-up data, and health management data; The data stored on the blockchain includes key summary information, access logs, and authorization credentials. The generation of the key summary information includes: Perform a hash operation on the sensitive data to obtain a feature hash value; The feature hash value is associated with a timestamp to generate the key summary information; The key summary information, access logs, and authorization credentials are uploaded to the blockchain node for storage.
[0008] Preferably, the dynamic control of access permissions for different roles based on smart contracts includes: Identify the identities of different roles involved in data interaction, including at least residents, family doctors, community organizations, higher-level hospitals, and regulatory authorities; Based on residents' authorization instructions, smart contracts are used to automatically verify and execute operations such as signing, accessing, updating, sharing, and revoking authorization.
[0009] Preferably, the step of receiving data access requests through a unified data interaction interface, verifying the legitimacy of the data access requests based on the authorization credentials, and performing cross-organizational data interaction includes: The data caller initiates a call request through the unified data interaction interface; The smart contract verifies the authorization credentials of the data caller. After successful verification, it controls the off-chain database to return the corresponding encrypted sensitive data to the data caller. The data caller decrypts the encrypted sensitive data locally, calculates the hash value of the decrypted data, and compares the calculated hash value with the key digest information stored on the blockchain.
[0010] Preferably, the step of collecting access logs during the operation and transfer of family doctor contract data, storing the access logs on the blockchain, and combining on-chain hash verification and timestamp mechanisms to conduct full-process traceability auditing of the family doctor contract data includes: The access logs include data access records during the contract signing and record keeping, health follow-up, two-way referral, performance evaluation, and regulatory audit processes; The data call records are collected and an access log is generated; The access logs are uploaded to the blockchain node for storage.
[0011] A blockchain-based secure data exchange system for family doctor contracts, used to execute the above-described method, includes: The classification and grading and collaborative evidence storage module is used to acquire family doctor contract data, classify and manage the family doctor contract data, encrypt sensitive data and store it in an off-chain database, and store the key summary information of the family doctor contract data on the blockchain. The smart contract dynamic authorization module is used to dynamically control the access permissions of different roles based on smart contracts, automatically verify and execute operations on the family doctor contract data, and generate authorization certificates and store them on the blockchain. The unified interface data interaction module is used to receive data access requests through the unified data interaction interface, verify the legality of the data access requests based on the authorization credentials, and perform cross-organizational data interaction after the verification is successful. The full-process traceability and audit module is used to collect access logs of family doctor contract data during operation and transfer, store the access logs on the blockchain, and combine the on-chain hash verification and timestamp mechanism to perform full-process traceability and audit of the family doctor contract data.
[0012] Preferably, the unified interface data interaction module connects to at least community health service centers, hospitals, and medical insurance platforms; The unified interface data interaction module is used to unify data standards between different institutions and, in conjunction with the authorization credentials generated by the smart contract dynamic authorization module, to perform cross-institutional data interaction.
[0013] Preferably, the full-process traceability and auditing module works in conjunction with the classification, grading and collaborative evidence storage module, using on-chain evidence storage and off-chain exchange to collaboratively process the evidence storage and exchange of family doctor contract data.
[0014] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention classifies and grades family doctor contract data, encrypts and stores sensitive data in an off-chain database, and stores key summary information on the blockchain, thereby ensuring data privacy while achieving trusted evidence storage and integrity verification of off-chain data.
[0015] 2. This invention uses smart contracts to dynamically control the access permissions of different roles, and solidifies the rules such as authorization conditions, permission boundaries and validity periods on the blockchain, realizing automatic verification and execution of operations such as signing, accessing, updating, sharing and revoking authorization, thereby improving the credibility and automation of the authorization process.
[0016] 3. This invention achieves standardized reception and processing of cross-organizational data access requests through a unified data interaction interface, and improves the security, authenticity and integrity of cross-organizational data interaction by combining authorization credential verification, encrypted return and digest consistency comparison mechanisms.
[0017] 4. This invention collects logs of the operation and transfer process of family doctor contract data and stores the access logs on the blockchain. By utilizing the immutability, hash verification mechanism and timestamp mechanism of blockchain, it realizes the trusted traceability and auditing of the entire life cycle of family doctor contract data, which is conducive to regulatory verification and responsibility definition. Attached Figure Description
[0018] Figure 1 This is an exemplary flowchart illustrating a blockchain-based family doctor contract data security interaction method according to some embodiments of the present invention. Detailed Implementation
[0019] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the linguistic context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.
[0020] It should be understood that the terms "system," "device," "unit," and / or "module" as used in this specification are a method of distinguishing different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.
[0021] As indicated in this specification and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not specifically singular and may include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.
[0022] Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.
[0023] The following describes in detail, with reference to the accompanying drawings, the blockchain-based family doctor contract data security interaction method and system provided in the embodiments of this specification.
[0024] like Figure 1 As shown, this invention provides a blockchain-based method and system for secure data interaction in family doctor contract signing, applicable to secure data storage, authorized access, trusted interaction, and full-process traceability and auditing among multiple institutions in family doctor contract signing service scenarios. The system is preferably built on a blockchain network, an off-chain database, a smart contract execution environment, and a unified data interaction interface, and steps S1 to S4 are implemented collaboratively by modules M1 to M4.
[0025] In this invention, the blockchain network preferably adopts a consortium blockchain structure, jointly maintained by multiple institutional nodes. These institutional nodes can be deployed in the information systems of community health service centers, hospitals, medical insurance platforms, and regulatory departments, and are used to jointly store on-chain data such as key summary information, authorization credentials, and access logs. An off-chain database is used to store the original business data from family doctor contract data, especially sensitive data. This off-chain database can employ a relational database, a distributed database, or other data storage structures suitable for healthcare data management.
[0026] The family doctor contract data includes resident contract information, doctor service records, follow-up data, and health management data. Resident contract information may include resident identification, contracted institution information, contracted doctor information, and contract status information; doctor service records may include performance records, service time information, and related processing records; follow-up data may include follow-up time, follow-up content, health indicator records, and feedback information; health management data may include health assessment data, intervention records, chronic disease management data, and health record update data.
[0027] Step S1: Classification, Grading, and Collaborative Evidence Storage Step S1 is executed by module M1, which is used to obtain family doctor contract data, classify and manage the family doctor contract data, encrypt sensitive data and store it in an off-chain database, and store the key summary information of the family doctor contract data on the blockchain.
[0028] Specifically, module M1 first acquires family doctor contract data. This family doctor contract data can originate from business processes such as contract registration, service delivery, health follow-up, two-way referral, performance evaluation, and regulatory verification. Acquisition methods can include writing to the business system, terminal collection and uploading, or transfer via a unified data interaction interface.
[0029] After acquiring the data, module M1 classifies and manages the family doctor contract data according to its type and level. This classification and level management can be based on data content attributes, sensitivity, sharing necessity, and scope of use. Data involving resident identification information, health status information, medical treatment information, or other highly private information is treated as sensitive data; data used for business collaboration, such as institution identification, business type, process status, and service time, can be treated as general business data. Furthermore, the data can be divided into different levels based on its importance and security requirements to match corresponding storage and access control strategies.
[0030] For sensitive data, module M1 performs encryption processing and then stores it in an off-chain database. The encryption processing can be implemented using symmetric encryption algorithms, asymmetric encryption algorithms, or a hybrid encryption mechanism. This invention does not limit the specific type of encryption algorithm, as long as it can protect the sensitive data. By adopting an off-chain encrypted storage method, sensitive raw data can be avoided from being directly exposed to the blockchain network.
[0031] While storing sensitive data off-chain, module M1 generates key summary information for the family doctor contract data and stores it on-chain. The generation of the key summary information includes: normalizing the target data; performing a hash operation on the normalized data to obtain a feature hash value; associating the feature hash value with a timestamp to generate key summary information; and uploading the key summary information to a blockchain node for storage. If necessary, the key summary information may also include data identifiers, data categories, source organization identifiers, and status identifiers.
[0032] In this invention, the data stored on the blockchain includes at least key summary information, access logs, and authorization credentials. By adopting a collaborative approach of on-chain evidence storage and off-chain storage, module M1 can reduce the pressure on on-chain storage while providing a reliable basis for verifying the integrity of off-chain data.
[0033] Step S2: Dynamic Authorization of Smart Contracts Step S2 is executed by module M2, which is used to dynamically control the access permissions of different roles based on smart contracts, automatically verify and execute operations on the family doctor contract data, and generate authorization certificates and store them on the blockchain.
[0034] Specifically, module M2 first identifies the identities of different roles involved in data interaction. These roles include at least residents, family doctors, community organizations, higher-level hospitals, and regulatory authorities. Different roles correspond to different data access permissions, operational scopes, and business boundaries. Residents can act as authorized entities to manage the scope of data authorization related to themselves; family doctors can perform signing, access, and update operations within their authorized scope; community organizations and higher-level hospitals can conduct cross-institutional access and sharing within their authorized scope; and regulatory authorities can conduct audits and regulatory verifications, provided they comply with laws and regulations.
[0035] Module M2 receives authorization instructions from residents and automatically verifies and executes signing, accessing, updating, sharing, and revoking authorization operations based on smart contracts. The resident authorization instructions may include the authorized object, the scope of authorized data, the permitted operation types, and the authorization validity period. The smart contract automatically verifies the relevant conditions, including at least whether the authorizing entity's identity is legitimate, whether the authorized entity's identity is legitimate, whether the authorized data category is clear, whether the requested operation falls within the permitted scope, and whether the authorization period is valid.
[0036] After successful verification, module M2 generates an authorization credential and uploads it to the blockchain node for storage. This authorization credential serves as the basis for subsequent verification of data access legitimacy. The authorization credential includes at least the authorizing entity identifier, the authorized entity identifier, the target data category, the permitted operation type, the authorization effective time, the authorization expiration time, and the credential status information. If necessary, it may also include additional information such as the credential number, credential digest value, associated business identifier, or revocation status identifier.
[0037] When a resident initiates an authorization revocation operation, module M2 verifies the revocation conditions through a smart contract and updates the status of the corresponding authorization credential if the conditions are met, rendering it invalid or changing it to an unusable state, thereby achieving dynamic adjustment of access permissions. Through this method, module M2 can achieve refined and dynamic authorization control for different roles.
[0038] Step S3: Unified Interface Data Interaction Step S3 is executed by module M3, which receives data access requests through a unified data interaction interface, verifies the legality of the data access requests based on the authorization credentials, and performs cross-organizational data interaction after the verification is successful.
[0039] Specifically, module M3 receives data access requests initiated by data callers through a unified data interaction interface. The data access request includes at least the caller's identity identifier, target data identifier, target data category, requested operation type, authorization credential identifier, and request time. If necessary, it may also include a digital signature, organization identifier, or session verification information.
[0040] In this invention, the multiple institutions connected by module M3 include at least community health service centers, hospitals, and medical insurance platforms. Since the data structures, field definitions, and communication formats of the business systems of different institutions may differ, module M3 is also used to unify data standards between different institutions, performing format conversion, field mapping, or standardization processing on call requests and return results to improve the consistency and compatibility of cross-institutional data interaction.
[0041] Upon receiving the data access request, module M3 verifies the legality of the data access request based on the authorization credential. Preferably, the authorization credential of the data caller is verified by a smart contract, and the verification includes at least: whether the authorization credential exists, whether the authorization credential is valid, whether the requesting entity is consistent with the authorized entity, whether the target data category is within the authorized scope, whether the requested operation type is within the allowed scope, and whether the request time is within the authorization validity period.
[0042] Once verification is successful, module M3 controls the off-chain database to return the corresponding encrypted sensitive data to the data caller. "Control" here includes, but is not limited to, initiating a data retrieval command to the off-chain database, triggering the off-chain database's authorized read process, or calling a preset data access service interface. The data returned by the off-chain database is preferably encrypted sensitive data to further enhance data security during the interaction process.
[0043] After receiving the encrypted sensitive data, the data caller decrypts the encrypted sensitive data locally, calculates the hash value of the decrypted data, and then compares the calculated hash value with the key digest information stored on the blockchain. If they match, it indicates that the obtained data is consistent with the on-chain evidence data, and the data has not been tampered with during storage and transmission. If they do not match, it indicates that the data has an abnormal risk, and subsequent processing can be suspended and an anomaly record can be generated for subsequent auditing.
[0044] Through the above methods, module M3 can achieve unified processing of data access request reception, authorization credential verification, off-chain data retrieval, and on-chain digest consistency verification, thereby ensuring the security and trustworthiness of cross-institutional data interaction.
[0045] Step S4: Full-process traceability and auditing Step S4 is executed by module M4, which is used to collect access logs of family doctor contract data during operation and transfer, store the access logs on the blockchain, and combine the on-chain hash verification and timestamp mechanism to perform full traceability audit of the family doctor contract data.
[0046] Specifically, module M4 collects data access records generated during the operation and transfer of family doctor contract data and generates access logs. These access logs include data access records during contract registration, health follow-ups, two-way referrals, performance evaluation, and regulatory audits. Furthermore, the access logs may include at least the following: access subject identifier, access object identifier, access institution identifier, access time, operation type, data category, associated authorization credential identifier, access result status, and log summary value. If necessary, they may also include anomaly information, source node identifier, or call chain identifier.
[0047] After generating the access log, module M4 uploads the access log to the blockchain node storage. Preferably, the original access log can be stored in off-chain storage, while the corresponding summary information, timestamp, and index information of the access log are written to the blockchain, so as to reduce the on-chain storage pressure while ensuring the immutability and verifiability of the log.
[0048] During the audit process, module M4 combines on-chain hash verification and timestamp mechanisms to conduct full-process traceability audits of family doctor contract data. Specifically, it can perform correlation queries on key summary information, access logs, and authorization credentials on the blockchain based on target data identifiers, authorization credential identifiers, access subject identifiers, or time ranges. By verifying the consistency between access logs and off-chain original logs, the consistency between key summary information and target data, and the correspondence between authorization credential status and access behavior, the authenticity, integrity, and compliance of family doctor contract data in the storage, authorization, access, and sharing processes are confirmed.
[0049] Through the above methods, module M4 can achieve reliable recording, transfer tracking, and accountability of family doctor contract data throughout its entire lifecycle, thereby meeting the audit and supervision needs in multi-institutional collaborative scenarios.
[0050] Module correspondence and system collaboration In this invention, modules M1, M2, M3 and M4 work together and correspond to steps S1, S2, S3 and S4 respectively.
[0051] Module M1 is responsible for data classification and grading, off-chain encrypted storage of sensitive data, and on-chain notarization of key summary information, providing a data foundation for subsequent authorization control and integrity verification; Module M2 is responsible for dynamic authorization control and authorization credential generation for different roles, providing a reliable authorization basis for verifying the legality of data access; Module M3 is responsible for unified interface access, unified data standards, authorization verification, off-chain data retrieval and integrity comparison, providing a processing channel for cross-organizational data interaction; Module M4 is responsible for access log collection, log uploading to the blockchain, and traceability auditing, providing a record-keeping basis for full-process security supervision.
[0052] Module M4 works in collaboration with Module M1, employing on-chain notarization and off-chain exchange to collaboratively process the notarization and exchange of family doctor contract data; Module M3, in conjunction with the authorization credentials generated by Module M2, performs cross-institutional data interaction; Modules M1, M2, and M4 together form a technical closed loop covering the entire process of data storage, authorization, access, and auditing.
[0053] It should be noted that, without departing from the core concept of this invention, the deployment method of blockchain nodes, the type of off-chain database, the data encryption method, the hash algorithm, the timestamp acquisition method, the composition of the authorization credential field, the composition of the access log field, and the implementation method of the unified data interaction interface can all be adjusted or replaced by those skilled in the art according to the actual application scenario, and all such adjustments or replacements should fall within the protection scope of this invention.
[0054] The present invention will be described below with reference to a set of specific example data. It should be noted that the following data is only used to illustrate the technical solution of the present invention and does not constitute a limitation on the scope of protection of the present invention.
[0055] In this embodiment, a resident completes a family doctor contract at a community health service center. The system classifies and grades the contract data, controls authorization, allows cross-institutional access, and performs full-process auditing. The system includes a classification and grading and collaborative evidence storage module M1, a smart contract dynamic authorization module M2, a unified interface data interaction module M3, and a full-process traceability and auditing module M4, which correspond to steps S1 to S4 respectively.
[0056] In step S1, module M1 acquires family doctor contract data. Example data is as follows: resident identifier is RID001, contracting institution identifier is ORG-C001, family doctor identifier is DOC-F001, contract date is T1, and contract status is "signed"; follow-up record identifier is FUP001, follow-up date is T2, and follow-up conclusion is "blood pressure control is fair"; health management record identifier is HMG001, management type is "hypertension management," and the most recent systolic blood pressure is 148 mmHg, and diastolic blood pressure is 96 mmHg. Among these, the resident's name, ID number, contact number, address, blood pressure indicators, and health assessment conclusion are treated as sensitive data, encrypted to generate ciphertext data ENC-DATA-0001, and stored in an off-chain database. Simultaneously, module M1 performs a hash operation on the data used for evidence storage, obtaining the feature hash value HASH-A1B2C3D4, and combines it with the timestamp TS1 to generate key summary information DG001, which is then uploaded to the blockchain node for storage. The key summary information may include: summary identifier DG001, data object identifier DATA-0001, feature hash value HASH-A1B2C3D4, timestamp TS1, and source organization identifier ORG-C001.
[0057] In step S2, module M2 dynamically controls access permissions for different roles based on smart contracts. In this embodiment, the resident, as the authorizing entity, grants access to follow-up data and health management data from the higher-level hospital. An example authorization instruction is: authorizing entity identifier RID001, authorized entity identifier ORG-H001, authorized data scope "follow-up data, health management data", allowed operation type "access", authorization effective time T3, and authorization expiration time T4. The smart contract verifies the identity of the authorizing entity, the identity of the authorized entity, the scope of authorization, and the authorization period. Upon successful verification, an authorization credential AT001 is generated and stored on the blockchain. The authorization credential may include: credential identifier AT001, authorizing entity identifier RID001, authorized entity identifier ORG-H001, data category "follow-up data, health management data", allowed operation type "access", effective time T3, expiration time T4, and credential status "valid".
[0058] In step S3, module M3 receives a data access request through a unified data interaction interface. An example request initiated by the superior hospital is as follows: request identifier REQ001, calling institution identifier ORG-H001, calling user identifier USR-H001, target resident identifier RID001, target data category "follow-up data, health management data", request operation type "access", authorization credential identifier AT001, and request time T5. Module M3 calls a smart contract to verify the legality of the authorization credential. After successful verification, the control off-chain database returns the corresponding encrypted sensitive data ENC-DATA-0001-P2. The data caller decrypts the data locally to obtain the corresponding plaintext data, recalculates the hash value HASH-A1B2C3D4, and then performs a consistency comparison with the characteristic hash value in the key digest information DG001 stored on the blockchain. If the comparison result matches, it confirms that the returned data has not been tampered with and allows subsequent business use.
[0059] In step S4, module M4 collects access behavior during the aforementioned data processing and flow process and generates access logs. An example access log is as follows: Log ID LOG001, Access Subject ID ORG-H001, Access Object ID RID001, Access Time T5, Operation Type "Retrieval", Data Category "Follow-up Data, Health Management Data", Associated Authorization Certificate ID AT001, Access Result Status "Success", Log Summary Value LOGHASH-Z9Y8X7. Module M4 uploads the access logs to the blockchain node for storage and, combined with the on-chain timestamps and summary information, performs traceability auditing of the entire process of the resident's contracted data from filing, authorization, retrieval to verification.
[0060] As can be seen from the above example data, the present invention adopts the processing methods of off-chain encrypted storage, on-chain digest notarization, smart contract dynamic authorization, unified interface verification and call, and on-chain auditing of access logs, which can realize secure interaction and reliable traceability of family doctor contract data in multi-institutional collaborative scenarios.
[0061] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.
[0062] Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments described herein. Other variations may also fall within the scope of this specification. Therefore, alternative configurations of the embodiments described herein are intended to be illustrative rather than limiting, and should be considered consistent with the teachings of this specification. Accordingly, the embodiments described herein are not limited to those explicitly introduced and described herein.
Claims
1. A secure data interaction method for family doctor contract signing based on blockchain, characterized in that, Includes the following steps: Acquire family doctor contract data, classify and manage the family doctor contract data, encrypt sensitive data and store it in an off-chain database, and store the key summary information of the family doctor contract data on the blockchain; Based on smart contracts, the access permissions of different roles are dynamically controlled, operations on the family doctor contract data are automatically verified and executed, and authorization certificates are generated and stored on the blockchain. The system receives data access requests through a unified data interaction interface, verifies the legality of the data access requests based on the authorization credentials, and performs cross-organizational data interaction after the verification is successful. Access logs are collected during the operation and transfer of family doctor contract data. These access logs are stored on the blockchain, and the family doctor contract data is traced and audited throughout the entire process using on-chain hash verification and timestamp mechanisms.
2. The method for secure data interaction in family doctor contracting based on blockchain according to claim 1, characterized in that, The family doctor contract data includes resident contract information, doctor service records, follow-up data, and health management data; The data stored on the blockchain includes key summary information, access logs, and authorization credentials. The generation of the key summary information includes: Perform a hash operation on the sensitive data to obtain a feature hash value; The feature hash value is associated with a timestamp to generate the key summary information; The key summary information, access logs, and authorization credentials are uploaded to the blockchain node for storage.
3. The blockchain-based family doctor contract data secure interaction method according to claim 1, characterized in that, The dynamic control of access permissions for different roles based on smart contracts includes: Identify the identities of different roles involved in data interaction, including at least residents, family doctors, community organizations, higher-level hospitals, and regulatory authorities; Based on residents' authorization instructions, smart contracts are used to automatically verify and execute operations such as signing, accessing, updating, sharing, and revoking authorization.
4. The method for secure data interaction in family doctor contracting based on blockchain according to claim 1, characterized in that, The step of receiving data access requests through a unified data interaction interface, verifying the legitimacy of the data access requests based on the authorization credentials, and performing cross-organizational data interaction includes: The data caller initiates a call request through the unified data interaction interface; The smart contract verifies the authorization credentials of the data caller. After successful verification, it controls the off-chain database to return the corresponding encrypted sensitive data to the data caller. The data caller decrypts the encrypted sensitive data locally, calculates the hash value of the decrypted data, and compares the calculated hash value with the key digest information stored on the blockchain.
5. The blockchain-based family doctor contract data secure interaction method according to claim 1, characterized in that, The process of collecting access logs during the operation and transfer of family doctor contract data, storing these access logs on the blockchain, and conducting full-process traceability auditing of the family doctor contract data using on-chain hash verification and timestamp mechanisms includes: The access logs include data access records during the contract signing and record keeping, health follow-up, two-way referral, performance evaluation, and regulatory audit processes; The data call records are collected and an access log is generated; The access logs are uploaded to the blockchain node for storage.
6. A blockchain-based secure data interaction system for family doctor contract signing, used to execute the method described in any one of claims 1-5, characterized in that, include: The classification and grading and collaborative evidence storage module is used to acquire family doctor contract data, classify and manage the family doctor contract data, encrypt sensitive data and store it in an off-chain database, and store the key summary information of the family doctor contract data on the blockchain. The smart contract dynamic authorization module is used to dynamically control the access permissions of different roles based on smart contracts, automatically verify and execute operations on the family doctor contract data, and generate authorization certificates and store them on the blockchain. The unified interface data interaction module is used to receive data access requests through the unified data interaction interface, verify the legality of the data access requests based on the authorization credentials, and perform cross-organizational data interaction after the verification is successful. The full-process traceability and audit module is used to collect access logs of family doctor contract data during operation and transfer, store the access logs on the blockchain, and combine the on-chain hash verification and timestamp mechanism to perform full-process traceability and audit of the family doctor contract data.
7. The blockchain-based family doctor contract data security interaction system according to claim 6, characterized in that: The unified interface data interaction module connects to at least the community health service centers, hospitals, and medical insurance platforms. The unified interface data interaction module is used to unify data standards between different institutions and, in conjunction with the authorization credentials generated by the smart contract dynamic authorization module, to perform cross-institutional data interaction.
8. The blockchain-based family doctor contract data security interaction system according to claim 6, characterized in that: The full-process traceability and audit module works in conjunction with the classification, grading and collaborative evidence storage module, using on-chain evidence storage and off-chain exchange to collaboratively process the evidence storage and exchange of family doctor contract data.