Fhir data dynamic desensitization distribution method and system, electronic device and storage medium

Abstract

The FHIR data dynamic desensitization distribution method, system, electronic equipment and storage medium belong to the technical field of medical informatization and data security, and the method comprises the following steps: analyzing a subscription request to extract identity information, binding with a privacy view configuration, and generating an extended subscription contract; a resource change event is listened to, when the event is captured, a target FHIR resource associated with the event is extracted, and it is judged whether the subscription condition is hit; if the subscription condition is hit, a privacy calculation interceptor is activated, the privacy level and the desensitization strategy of the subscriber are obtained according to the subscription contract, and it is judged whether desensitization is needed; if not, the resource copy is directly loaded; if needed, the target FHIR resource payload is reconstructed in real time according to the desensitization strategy, and the desensitized resource copy meeting the privacy level of the subscriber is generated; thereby, the subscriber identity is intelligently perceived under the premise of compatibility FHIR standard subscription mechanism, and the data is dynamically and differentially desensitized in real time.

Description

Technical Field

[0001] This application belongs to the field of medical informatics and data security technology, and relates to a dynamic desensitization and distribution technology for clinical data based on the FHIR standard protocol for subscribers with different permissions during medical data interoperability. Specifically, it relates to a method, system, electronic device and storage medium for dynamic desensitization and distribution of FHIR data based on subscriber identity awareness. Background Technology

[0002] With the deepening development of medical informatization, the interconnection and interoperability of medical data has become an industry consensus. As a new generation of international medical data exchange standard, HL7 FHIR (Fast Healthcare Interoperability Resources) is gradually replacing the traditional HL7 v2 / v3 standard due to its RESTful architecture, easy scalability, and support for mobile internet. It is widely used in hospital integration platforms, regional health information platforms, and internet-based medical applications.

[0003] In the FHIR standard framework, Subscription resources provide an event-driven data interaction mechanism. Its working principle is typically as follows: a client (subscriber) registers a subscription request with the server (including triggering conditions, such as "all newly created hypertension diagnoses"); when the server generates data that meets the conditions, it automatically pushes the data to the subscriber. This mechanism greatly improves the timeliness of data transmission and reduces the system overhead of polling.

[0004] However, in actual medical practice, the existing standard FHIR Subscription mechanism has revealed significant technical flaws and application pain points:

[0005] 1. The "one-size-fits-all" forwarding mechanism leads to the risk of privacy leaks:

[0006] Existing mainstream FHIR servers (such as HAPI FHIR and Firely) typically follow a "forward as is" logic when processing subscription requests. That is, once data meets the trigger conditions, the server directly pushes the complete FHIR resource (including sensitive information such as patient name, ID number, and detailed address) to the subscriber. This is acceptable for trusted systems within hospitals (such as doctor workstations), but for third-party applications (such as research data collection, chronic disease management apps, and insurance claims systems), directly pushing full plaintext data poses a serious risk of patient privacy breaches and violates the principle of minimum availability.

[0007] 2. Lack of fine-grained dynamic access control:

[0008] While the current FHIR standard supports OAuth2-based authentication, it lacks dynamic access control at the data content level during the subscription and distribution phase. The system cannot distinguish the access permissions of "Doctor A" and "Pharmaceutical Company B" for the same data. For example, Doctor A has the right to see the patient's "name" and "full set of test results," while Pharmaceutical Company B only has the right to see the "anonymized age group" and "specific indicator trends." Existing solutions typically require developing different interfaces for different recipients or deploying multiple sets of data copies, resulting in complex system architecture and high maintenance costs.

[0009] 3. Static anonymization cannot meet the needs of real-time interaction:

[0010] Traditional medical data anonymization solutions are typically static, meaning that data is cleaned and anonymized before being stored in a data warehouse (DW), generating a fixed anonymized dataset for subsequent queries. This approach cannot adapt to the real-time streaming interaction represented by FHIR Subscriptions. In scenarios such as clinical emergency care, real-time referrals, or instant messaging alerts, data must be distributed within milliseconds of its generation. If data is first stored, then anonymized, and then pushed, unacceptable latency will occur, and the system cannot flexibly handle the diverse changes in subscriber identities.

[0011] 4. Existing modification plans are highly intrusive to standard protocols:

[0012] To address these issues, some vendors have attempted to hard-code the data masking logic into the business code. This approach compromises the versatility of the FHIR server, leading to incompatibility with standard protocol stacks and difficulty passing regional interoperability tests. Furthermore, any changes to fields (such as adding privacy fields) require a complete system recompilation and redeployment, resulting in extremely poor scalability.

[0013] 5. Although existing technologies (such as some API gateway-based desensitization mechanisms) mention dynamic desensitization based on user roles and support processing of FHIR format data, in the specific FHIR Subscription asynchronous event-driven technology environment, existing technologies rely on synchronous access initiated by the client to obtain the request context. This cannot solve the memory data pollution and cache conflict problems caused when a single event source pushes to multiple subscribers with different permissions concurrently in the server-initiated push scenario. Summary of the Invention

[0014] To address the shortcomings of the aforementioned existing technologies, this application provides a method, system, electronic device, and storage medium for dynamic de-identification and distribution of FHIR data based on subscriber identity awareness. This method can intelligently detect subscriber identities in the data distribution pipeline while maintaining compatibility with the FHIR standard subscription mechanism, and perform real-time and dynamic differentiated de-identification of the data accordingly.

[0015] To achieve the above objectives, the present invention employs the following techniques:

[0016] A subscriber-aware FHIR data dynamic de-identification and distribution method includes:

[0017] Receive FHIR subscription requests from subscribers, which include subscription conditions;

[0018] Parse the identity credential information in the subscription request to extract the subscriber's identity information, associate and bind the identity information with the preset privacy vision configuration, and generate an extended subscription contract;

[0019] The system monitors data center resource change events in real time via the internal event bus of the FHIR server or persistent layer database logs. When an event is captured, the target FHIR resource associated with the event is extracted, and a pre-built matching engine is used to determine whether it matches the subscription conditions. If it matches, a distribution task is generated and the distribution task and the corresponding extended subscription contract are pushed into the asynchronous distribution task queue.

[0020] When retrieving tasks from the asynchronous distribution task queue in the outbound pipeline, before pushing the target FHIR resource to the subscriber, a privacy computing interceptor is activated. Based on the subscription contract, the subscriber's privacy level and desensitization strategy are obtained, and it is determined whether the current distribution task needs to start the desensitization process: if not, the payload of the target FHIR resource is directly loaded as a resource copy; if so, based on the desensitization strategy, a pre-set algorithm model is used to perform real-time reconstruction of the payload of the target FHIR resource at the object level or serialized text stream, generating a desensitized resource copy that conforms to the subscriber's privacy level.

[0021] The directly loaded resource copy or the de-identified resource copy is encapsulated in the standard FHIR format and pushed to subscribers through a specified channel.

[0022] Furthermore, the Privacy Vision configuration includes multi-level privacy permission definitions, which include: privacy level that is fully visible, privacy level that is partially de-identified, and privacy level that is completely hidden. The privacy level corresponding to subscribers of different types of roles is predefined in an identity-permission mapping table.

[0023] The extension is a structured extension based on the standard FHIR resources subscribed to, adding an extension element to the resource definition to store the reference ID of the privacy vision configuration;

[0024] When determining whether the current distribution task needs to initiate the de-identification process, if the privacy level of the obtained subscribers is a fully visible privacy level, it is determined that it is not required; if the privacy level of the obtained subscribers is a partially de-identified privacy level or a completely hidden privacy level, it is determined that it is required.

[0025] Furthermore, if a broken window token is found to be carried by the subscriber when parsing the subscription request, the broken window token will also be generated into the subscription contract.

[0026] When the activated privacy computing interceptor detects a broken window token based on the subscription contract, it performs the following verifications in sequence: verifying whether the digital signature of the broken window token is authorized and issued by the authorization center; verifying whether the timestamp embedded in the broken window token is within the allowed emergency time window; extracting the task ID from the broken window token and querying whether the task ID is associated with the patient ID of the current FHIR resource.

[0027] If all the above verifications pass, the privacy level of the current subscriber will be temporarily switched to the preset highest privilege level, bypassing the step of determining whether the current distribution task needs to start the de-identification process, and directly loading the payload of the target FHIR resource as a resource copy;

[0028] If no broken window token is detected or all of the above verifications fail, the subscriber's privacy level and de-identification strategy are obtained to determine whether the current distribution task needs to initiate the de-identification process.

[0029] Furthermore, when all the above verifications pass and the payload of the target FHIR resource is directly loaded as a resource copy, a structured audit log containing the token fingerprint, access time, and target FHIR resource hash value is generated and written to the tamper-proof storage area; wherein, the token fingerprint is the unique identifier of the broken window token.

[0030] Furthermore, when the extracted target FHIR resource simultaneously matches multiple subscription conditions from different subscribers, multiple distribution tasks corresponding to each subscription condition are generated, and subsequent processes are triggered in parallel using a multi-threaded approach; finally, a resource copy conforming to their respective privacy level and encapsulated in standard FHIR format is pushed to each subscriber.

[0031] Furthermore, real-time reconstruction includes field-level erasure, masking, generalization, and resource stripping;

[0032] Field-level erasure includes setting the field value of a sensitive field to null or deleting the sensitive field.

[0033] Masking involves partially replacing identifier fields with specific characters, such as retaining the first 6 and last 4 digits of an ID card while replacing the middle 8 digits with the specific character "*".

[0034] Generalization processing includes converting exact values ​​to range values ​​for numeric and date fields;

[0035] Resource stripping involves recursively checking and removing sub-resources that the current subscriber does not have permission to view based on the de-identification strategy when the target FHIR resource contains nested sub-resources.

[0036] A subscriber-aware FHIR data dynamic de-identification and distribution system includes:

[0037] The subscription registration module is used to receive FHIR subscription requests sent by subscribers, which contain subscription conditions; and to parse the identity credential information in the subscription request to extract the subscriber's identity information, associate and bind the identity information with the preset privacy vision configuration, and generate an extended subscription contract.

[0038] The event capture module is used to monitor resource change events in the data center in real time through the internal event bus of the FHIR server or the persistent layer database logs. When an event is captured, the target FHIR resource associated with the event is extracted, and a pre-built matching engine is used to determine whether it hits the subscription conditions. If it does, a distribution task is generated and the distribution task and the corresponding extended subscription contract are pushed into the asynchronous distribution task queue.

[0039] The dynamic interception module is used to extract tasks from the asynchronous distribution task queue in the outbound pipeline. Before pushing the target FHIR resource to the subscriber, it activates the privacy computing interceptor, obtains the subscriber's privacy level and de-identification strategy according to the subscription contract, and determines whether the current distribution task needs to start the de-identification process.

[0040] The loading and reconstruction module is used to directly load the payload of the target FHIR resource as a resource copy when the dynamic interception module determines that the desensitization process does not need to be started; when the dynamic interception module determines that the desensitization process needs to be started, it performs real-time reconstruction of the payload of the target FHIR resource at the object level or serialized text stream according to the desensitization strategy and uses a pre-set algorithm model to generate a desensitized resource copy that meets the subscriber's privacy level.

[0041] The secure distribution module is used to encapsulate directly loaded resource copies or de-identified resource copies into the standard FHIR format and push them to subscribers through a specified channel.

[0042] An electronic device includes at least one processor and a memory; wherein the memory stores computer-executable instructions; the at least one processor executes the computer-executable instructions stored in the memory, causing the at least one processor to execute the FHIR data dynamic desensitization and distribution method.

[0043] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, controls the device where the storage medium is located to perform the FHIR data dynamic desensitization and distribution method.

[0044] The beneficial effects of this invention are as follows:

[0045] 1. This invention achieves intelligent sensing of subscriber identity in the data distribution pipeline while maintaining compatibility with the FHIR standard subscription mechanism, and performs real-time, dynamic, and differentiated de-identification distribution of data accordingly;

[0046] 2. The interception and real-time reconstruction method of the present invention does not require modification of the business code of the source system such as HIS and EMR, nor does it require modification of the standard FHIR server kernel. It is plug-and-play and has extremely low implementation cost.

[0047] 3. This invention breaks through the limitations of traditional role-based access control at the data content level, realizing real-time privacy computation at the field level; and supports one data source and multiple delivery states, which not only meets the real-time needs of medical business, but also strictly complies with the requirements of data security regulations.

[0048] 4. This invention has a token mechanism that can provide a channel for designated subscribers to quickly obtain all resources in emergency situations, and can prevent access by illegal tokens, non-subscribers, and expired tokens; it can also further configure anti-tampering logs for this operation.

[0049] 5. This invention addresses the problem that traditional API gateways or query-based static permission masking solutions cannot adapt to high-concurrency event streams. By pre-binding the privacy horizon as an extended contract during the subscription registration phase, this invention avoids time-consuming dynamic permission calculations in the distribution pipeline. Combined with memory-level reconstruction in the asynchronous outbound pipeline, it achieves millisecond-level secure push.

[0050] 6. This invention addresses the technical shortcomings of traditional text regular expression masking or gateway string truncation, which easily compromise the interoperability of FHIR resources in the medical field. Specifically, in the medical interoperability technical environment of this invention, existing technologies cannot accurately remove sensitive nodes from deeply nested FHIR composite resources while ensuring that the masked payload strictly conforms to the official HL7 FHIR schema structure definition. This invention uses FHIR Path expressions for precise positioning and maintains the structural constraints of resources through validation after masking, thus preventing downstream medical system parsing crashes.

[0051] 7. This invention solves the technical challenge that existing role-based static desensitization strategies cannot adapt to complex clinical emergency scenarios. Existing technologies cannot handle the complex requirement of instantly reversing permissions for the same user under different business states in emergency rescue and other emergency scenarios. The invention's unique broken window token mechanism, through the interceptor's built-in security context state machine to perform timeliness and atomic binding verification of the token, achieves dynamic bypassing of the desensitization algorithm engine, filling the technical gap of traditional desensitization gateways. Attached Figure Description

[0052] Figure 1 This is a flowchart of a method embodiment of this application.

[0053] Figure 2 This is an example of direct loading or desensitization processing based on the privacy level in this application.

[0054] Figure 3 This is a system structure block diagram of an embodiment of this application. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the implementation methods of the present invention will be described in detail below with reference to the accompanying drawings. However, the embodiments described in this invention are only some embodiments of the present invention, and not all embodiments.

[0056] One aspect of this application provides a method for dynamic de-identification and distribution of FHIR data based on subscriber identity awareness, such as... Figure 1 As shown, it includes the following steps:

[0057] (1) Receive FHIR subscription requests sent by subscribers, which contain subscription conditions.

[0058] (2) Parse the identity credential information in the subscription request to extract the subscriber's identity information, associate and bind the identity information with the preset privacy vision configuration, and generate an extended subscription contract; wherein, the identity credential information includes the access token, digital certificate or request header signature transmitted by the API gateway, etc.; the privacy vision configuration includes multi-level privacy permission definitions, which include: privacy level that is fully visible, privacy level that is partially desensitized and privacy level that is completely hidden. The privacy level corresponding to different types of subscribers (such as clinicians, researchers, and third-party manufacturers) is predefined in an identity-permission mapping table; the extension is a structured extension based on the standard FHIR resource of the subscription, and an extension element is added to the resource definition to store the reference ID of the privacy vision configuration.

[0059] (3) Monitor resource change events in the data center in real time through the internal event bus of the FHIR server or the persistent layer database log. Here, change events include resource creation, update or deletion operations, etc. When an event is captured, extract the target FHIR resource associated with the event and use the preset matching engine to determine whether it hits the subscription conditions. If it hits, generate a distribution task and push the distribution task and the corresponding extended subscription contract into the asynchronous distribution task queue. If it does not hit, end the process.

[0060] (4) When retrieving tasks from the asynchronous distribution task queue in the outbound pipeline, activate the privacy computation interceptor before pushing the target FHIR resource to the subscriber. The privacy computation interceptor operates in the outbound pipeline of the FHIR server. When the distribution engine generates a list of messages to be sent, it intervenes in the execution through a preset interception mechanism or a hook function. Based on the subscription contract, obtain the subscriber's privacy level and desensitization strategy, and determine whether the current distribution task needs to start the desensitization process:

[0061] If the privacy level of the subscriber obtained is the privacy level that is visible to all, it is determined that it is not needed, and the payload of the target FHIR resource is directly loaded as a resource copy.

[0062] If the privacy level of the obtained subscriber is partially anonymized or completely hidden, it is determined that it is necessary to perform real-time reconstruction of the payload of the target FHIR resource at the object-level or serialized stream using a pre-set algorithm model according to the anonymization strategy, and generate an anonymized resource copy that conforms to the subscriber's privacy level.

[0063] like Figure 2 In the example shown, for the target FHIR resource "Name: Zhang San, Phone: 13800000000": when it is determined that no desensitization is required, it is directly loaded / allowed, and "Name: Zhang San, Phone: 13800000000" is used as a resource copy; when it is determined that desensitization is required, based on its privacy level of "partial desensitization", it is reconstructed in real time to form a desensitized resource copy "Name: Zhang*, Phone: 138****0000".

[0064] In this example, during real-time reconstruction, specific nodes in the JSON or XML tree are precisely located and modified based on predefined FHIR Path expressions. After modification, a validation engine ensures that the generated anonymized resource copy still conforms to the structured constraints of standard FHIR resources, maintaining medical data interoperability. As an optional example, a visual interface can be used to allow administrators to predefine rules using FHIR Path syntax, such as administrator inputting rules:

[0065] Path: Patient.address.line;

[0066] The action `ReplaceWith("******")` will automatically compile the rule into the interceptor's execution logic. When processing resources containing address information, regardless of the nesting level of the address in the JSON structure, as long as it conforms to the FHIR Path, it will be accurately de-identified.

[0067] Real-time refactoring includes field-level erasure, masking, generalization, and resource stripping. Field-level erasure involves setting or deleting sensitive fields (such as Patient.telecom, phone number); masking involves partially replacing identifier fields with specific characters (e.g., Patient.name, retaining the last name and replacing the first name with "*"; Patient.identifier, retaining the first 6 and last 4 digits of the ID number and replacing the middle digit with "*"); generalization involves converting numeric and date fields (e.g., Patient.birthDate, Observation.value, detection result) from precise values ​​to range values ​​(e.g., converting "1980-05-12" to "1980" or "40-50 years old"); and resource stripping involves recursively checking and removing sub-resources that the current subscriber's privacy level does not have permission to view when the target FHIR resource contains nested sub-resources, based on the de-identification strategy. When a target FHIR resource contains nested "child resources" (such as components, nested objects, or array elements), checking only the top-level node might miss sensitive information. Recursive checks ensure coverage of all levels; rules are passed down the tree structure, performing the same desensitization, validation, or transformation operations on elements at each level. For example, a Patient resource might contain multiple contacts, and each contact might contain telephones. If a rule requires desensitizing telephones, the recursive check will traverse the telephones within each contact, ensuring they are all processed, rather than just stopping at the outer contact level.

[0068] (5) Encapsulate the directly loaded resource copy or the de-identified resource copy into the standard FHIR format and push it to the subscriber through the specified channel.

[0069] To prevent data confusion caused by network middleware or client-side general caching mechanisms, when directly loading resource copies or de-identified resource copies are encapsulated in the standard FHIR format for HTTP push, the distribution adapter will force the injection of no-caching directives (such as adding Cache-Control: no-store, no-cache or Vary:Authorization) into the HTTP response header to ensure that the generated differentiated copies have an independent temporary lifespan and are only valid in the current push session.

[0070] The following example illustrates the specific steps of this case: Suppose a third-party chronic disease management app (subscriber, hereinafter referred to as the chronic disease app) wants to subscribe to the hospital's "hypertension patient data".

[0071] The subscriber sends an HTTP POST subscription request to the platform to create an FHIR subscription resource.

[0072] The system gateway parses the access token in the subscription request, Authorization: Bearer <token>, it is recognized that this Token belongs to the "external vendor" role; according to the preset privacy horizon configuration, the default privacy level corresponding to "external vendor" is partial desensitization. The system binds the ID of the subscribed resource with the privacy level of partial desensitization and stores it in the "extended subscription contract table" in memory.

[0073] Listening for data change events: The hospital HIS system enters a new patient "Name: Zhang San; ID card: 510100123412341234; Phone: 13800000000" and is diagnosed with hypertension. HIS writes the data to the FHIR server. The event listening engine captures the creation events of Encounter (visit) and Patient (patient) resources. The engine matches according to the subscription condition (Criteria: "Condition?code=I10") and finds that it hits the subscription of the above chronic disease App.

[0074] Dynamic interception and policy loading: Prepare to push the data to the callback address of the chronic disease App. Before the data leaves the server network card, activate the privacy computing interceptor to intercept the message object.

[0075] Policy acquisition: The interceptor finds the corresponding privacy level of partial desensitization from the memory table according to the subscription contract. The policy set corresponding to this level is:

[0076] Patient.name (Name) -> Perform masking processing (retain the surname);

[0077] Patient.identifier (ID card) -> Perform masking processing (retain the first 6 digits and the last 4 digits);

[0078] Patient.telecom (Phone) -> Perform field-level erasure.

[0079] Perform dynamic desensitization: The interceptor deeply traverses and reconstructs the JSON format FHIR Payload in volatile memory. According to the FHIR Path path Patient.name.text, it locates the value "Zhang San", calls the masking function Mask(Value,Start=1, End=0, Char="*"), and modifies "Zhang San" to "Zhang*"; locates the value "510100123412341234" of the Patient.identifier node, and through masking processing, modifies it to "510100********1234"; locates the Patient.telecom node and directly removes the Key-Value pair from the JSON object. The above operations are performed on the deep copy (Deep Copy) copy of the original data and will not affect the original data in the database.

[0080] Encapsulating and pushing messages: The distribution adapter encapsulates the modified, anonymized copy into a standard FHIR format and sends it to the chronic disease app via HTTP POST. At this point, the data received by the chronic disease app shows the patient's name as "Zhang*", their ID number as "510100********1234", and their phone number is not visible, thus achieving privacy protection.

[0081] This example method supports a "one-source, multi-morphic" distribution mode. When the extracted target FHIR resource simultaneously matches the subscription conditions of multiple subscribers with different identities, multiple distribution tasks corresponding to each subscription condition are generated, and subsequent processes are triggered in parallel using multi-threading. Multiple anonymized copies with different content but the same structure ID (Resource.id) are generated in parallel using multi-threading. Finally, a resource copy conforming to its respective privacy level and encapsulated in a standard FHIR format is pushed to each subscriber. This ensures that the data format seen by different subscribers matches their permissions, does not interfere with each other, and that the generated copies have independent temporary lifecycles and are not persisted by general caching mechanisms.

[0082] Suppose that "Attending Physician A" (privacy level: fully visible) and "Research System B" (privacy level: completely anonymous) both subscribed to the aforementioned hypertension event.

[0083] When an event is triggered, two parallel processing threads, Thread-A and Thread-B, are started.

[0084] Thread-A: The interceptor detects that the privacy level of attending physician A is fully visible, determines that no desensitization is required, allows the process directly, and loads and copies the target FHIR resources.

[0085] Thread-B: The interceptor detects that the privacy level of research system B is completely anonymous and executes a strict "de-identification" algorithm, such as replacing patient names with hash values ​​and generalizing birth dates to "1980".

[0086] Result: A notification with complete information popped up on the workstation of attending physician A, while the database of research system B only contained the anonymized statistical data. The two distribution paths did not block or interfere with each other.

[0087] Preferably, when parsing a subscription request, if a broken-glass token is found to be carried by the subscriber, the broken-glass token is also generated into the subscription contract. When the activated privacy computing interceptor detects the broken-glass token according to the subscription contract, it performs the following verifications in sequence: verifying whether the digital signature of the broken-glass token is authorized and issued by the authorization center; verifying whether the timestamp embedded in the broken-glass token is within the allowed emergency time window; extracting the task ID from the broken-glass token and querying whether the task ID is associated with the encounter ID or patient ID of the target FHIR resource; if all the above verifications pass, the privacy level of the current subscriber is temporarily switched to the preset highest privilege level, bypassing the step of determining whether the current distribution task needs to start the de-identification process, and directly loading the payload of the target FHIR resource as a resource copy; if no broken-glass token is detected or the above verifications do not all pass, then "obtain the subscriber's privacy level and de-identification strategy, and determine whether the current distribution task needs to start the de-identification process" is executed.

[0088] When all the above verifications pass and the payload of the target FHIR resource is directly loaded as a resource copy, a structured audit log containing the token fingerprint, access time, and target FHIR resource hash value is generated and written to a tamper-proof storage area, such as WORM storage or a blockchain node; wherein, the token fingerprint is the unique identifier of the broken window token.

[0089] This preferred method introduces a token mechanism, which allows for bypassing the "determination of whether the current distribution task needs to start the desensitization process" when a token is held, and directly obtaining resource copies. This provides an optional handling method for subscription distribution in case of emergencies in practical applications.

[0090] Example: When the emergency system (subscriber) initiates an emergency procedure, it requests a short-lived broken glass token (JWT format) from the authorization center. This token contains: { "sub": "DoctorA", "task_id": "EMG-2023001", "exp": 1698765432,"scope": "break-glass"}, and is digitally signed using a private key. The emergency system places this token in the X-Break-Glass-Token field of the HTTP request header. When the activated privacy computation interceptor detects the broken glass token based on the subscription contract, it performs the following verifications in sequence:

[0091] Signature verification: After the privacy interceptor intercepts the request, it first uses a pre-set public key to verify the legality of the token signature and whether it was issued by the authorization center, ensuring that the token has not been tampered with;

[0092] Timeliness check: Verify whether the timestamp embedded in the broken window token is within the allowed emergency time window; expired tokens will be rejected immediately, and the system will revert to the default desensitization policy;

[0093] Contextual verification: The interceptor extracts the Task ID from the token and compares it with the Encounter ID or Patient ID in the target FHIR resource that triggered the distribution. Privilege escalation is only allowed if the task object specified by the token matches the current target data resource object. This technically prevents token-holding doctors from arbitrarily accessing data of non-emergency patients.

[0094] After successful verification, the interceptor's memory state machine transitions from State_Normal to State_Privileged. At this point, the distribution engine skips the step of determining whether the current distribution task needs to initiate the de-identification process and directly references the original data object through a memory pointer to load the payload of the target FHIR resource as a resource copy.

[0095] Simultaneously, the metadata of this operation (including token fingerprint, access time, target resource ID, etc.) is captured, the target FHIR resource hash value (hash message authentication code) is calculated, and it is synchronously written to a separate security audit log file. This log file is configured in "append-only" mode to prevent it from being maliciously erased later.

[0096] This example successfully achieved the effect of "one data source, multiple delivery states" by embedding an intelligent interception layer into the FHIR standard distribution pipeline, which not only meets the real-time requirements of medical business, but also strictly complies with the requirements of data security regulations.

[0097] Another aspect of this application provides a subscriber-aware FHIR data dynamic de-identification and distribution system, such as... Figure 3 As shown, it includes a subscription registration module, an event capture module, a dynamic interception module, a loading and refactoring module, and a secure distribution module.

[0098] The subscription registration module is used to receive FHIR subscription requests sent by subscribers, which contain subscription conditions; and to parse the identity credential information in the subscription request to extract the subscriber's identity information, associate and bind the identity information with the preset privacy vision configuration, and generate an extended subscription contract.

[0099] The event capture module is used to monitor resource change events in the data center in real time through the internal event bus of the FHIR server or the persistent layer database logs. When an event is captured, the target FHIR resource associated with the event is extracted, and a pre-built matching engine is used to determine whether it matches the subscription conditions. If it matches, a distribution task is generated and the distribution task and the corresponding extended subscription contract are pushed into the asynchronous distribution task queue, and the dynamic interception module is triggered.

[0100] The dynamic interception module, when in a triggered state and retrieving tasks from the asynchronous distribution task queue in the outbound pipeline, activates a privacy computation interceptor before pushing the target FHIR resource to subscribers. Based on the subscription contract, it obtains the subscriber's privacy level and desensitization strategy, determining whether the current distribution task requires initiating a desensitization process. The loading and reconstruction module, when the dynamic interception module determines that a desensitization process is not required, directly loads the payload of the target FHIR resource as a resource copy. When the dynamic interception module determines that a desensitization process is required, it performs real-time object-level or serialized text stream reconstruction of the target FHIR resource payload using a pre-set algorithm model, based on the desensitization strategy, to generate a desensitized resource copy that conforms to the subscriber's privacy level.

[0101] The secure distribution module is used to encapsulate directly loaded resource copies or de-identified resource copies into the standard FHIR format and push them to subscribers through a specified channel.

[0102] In another aspect of this application, an electronic device is provided, including at least one processor and a memory; wherein the memory stores computer execution instructions; the at least one processor executes the computer execution instructions stored in the memory, causing the at least one processor to perform the FHIR data dynamic desensitization and distribution method as described in the preceding embodiments.

[0103] In another aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, controls the device where the storage medium is located to perform the FHIR data dynamic desensitization and distribution method as described in the preceding embodiments.

[0104] The above description is only a preferred embodiment of this application and is not intended to limit this application. Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application.< / token>

Claims

1. A method for dynamic desensitization and distribution of FHIR data, characterized in that, include: Receive FHIR subscription requests from subscribers, which include subscription conditions; The identity credential information in the subscription request is parsed to extract the subscriber's identity information. This identity information is then associated and bound with a preset privacy horizon configuration to generate an extended subscription contract. The privacy horizon configuration includes multi-level privacy permission definitions, such as: fully visible privacy level, partially anonymized privacy level, and completely hidden privacy level. The privacy levels corresponding to different types of subscribers are predefined in an identity-permission mapping table. The extension is a structured extension based on the target FHIR resource of the subscription, adding an extension element to the resource definition to store the reference ID of the privacy horizon configuration. The system monitors data center resource change events in real time via the internal event bus of the FHIR server or persistent layer database logs. When an event is captured, the target FHIR resource associated with the event is extracted, and a pre-built matching engine is used to determine whether it matches the subscription conditions. If it matches, a distribution task is generated and the distribution task and the corresponding extended subscription contract are pushed into the asynchronous distribution task queue. When retrieving tasks from the asynchronous distribution task queue in the outbound pipeline, before pushing the target FHIR resource to the subscriber, a privacy computing interceptor is activated. Based on the subscription contract, the privacy level and desensitization strategy of the subscriber are obtained, and it is determined whether the current distribution task needs to start the desensitization process: if the obtained privacy level of the subscriber is a fully visible privacy level, it is determined that it is not needed, and the payload of the target FHIR resource is directly loaded as a resource copy; if the obtained privacy level of the subscriber is a partially desensitized privacy level or a completely hidden privacy level, it is determined that it is needed, and according to the desensitization strategy, a preset algorithm model is used to perform real-time reconstruction of the payload of the target FHIR resource at the object level or serialized text stream to generate a desensitized resource copy that conforms to the privacy level of the subscriber; The directly loaded resource copy or the de-identified resource copy is encapsulated in the standard FHIR format and pushed to subscribers through a specified channel.

2. The FHIR data dynamic desensitization and distribution method according to claim 1, characterized in that, If a broken window token is found to be carried by the subscriber when parsing the subscription request, the broken window token will also be generated into the subscription contract. When the activated privacy computing interceptor detects a broken window token based on the subscription contract, it performs the following verifications in sequence: verifying whether the digital signature of the broken window token is authorized and issued by the authorization center; verifying whether the timestamp embedded in the broken window token is within the allowed emergency time window; extracting the task ID from the broken window token and querying whether the task ID is associated with the patient ID of the current FHIR resource. If all the above verifications pass, the privacy level of the current subscriber will be temporarily switched to the preset highest privilege level, bypassing the step of determining whether the current distribution task needs to start the de-identification process, and directly loading the payload of the target FHIR resource as a resource copy; If no broken window token is detected or all of the above verifications fail, the subscriber's privacy level and de-identification strategy are obtained to determine whether the current distribution task needs to initiate the de-identification process.

3. The FHIR data dynamic desensitization and distribution method according to claim 2, characterized in that, When all the above verifications pass and the payload of the target FHIR resource is directly loaded as a resource copy, a structured audit log containing the token fingerprint, access time, and target FHIR resource hash value is generated and written to the tamper-proof storage area; wherein, the token fingerprint is the unique identifier of the broken window token.

4. The FHIR data dynamic desensitization and distribution method according to claim 1, characterized in that, When the extracted target FHIR resource simultaneously matches multiple subscription conditions from different subscribers, multiple distribution tasks corresponding to each subscription condition are generated, and subsequent processes are triggered in parallel using a multi-threaded approach; finally, a resource copy conforming to their respective privacy level and encapsulated in standard FHIR format is pushed to each subscriber.

5. The FHIR data dynamic desensitization and distribution method according to claim 1, characterized in that, Real-time refactoring includes field-level erasure, masking, generalization, and resource stripping; Field-level erasure includes setting the field value of a sensitive field to null or deleting the sensitive field. Masking involves replacing certain bits of identifier fields with specific characters; Generalization processing includes converting exact values ​​to range values ​​for numeric and date fields; Resource stripping involves recursively checking and removing sub-resources that the current subscriber does not have permission to view based on the de-identification strategy when the target FHIR resource contains nested sub-resources.

6. The FHIR data dynamic desensitization and distribution method according to claim 1, characterized in that, During real-time reconstruction, the system precisely locates and modifies specific nodes in the JSON or XML tree based on predefined FHIR Path expressions. After modification, the verification engine ensures that the generated de-identified resource copy still conforms to the structured constraints of standard FHIR resources, thereby maintaining the medical interoperability of the data.

7. An FHIR data dynamic desensitization and distribution system, characterized in that, include: The subscription registration module receives FHIR subscription requests from subscribers, which include subscription conditions. It parses the identity credentials in the subscription request to extract the subscriber's identity information, and associates this identity information with a preset privacy horizon configuration to generate an extended subscription contract. The privacy horizon configuration includes multi-level privacy permission definitions, including: fully visible privacy level, partially anonymized privacy level, and completely hidden privacy level. The privacy levels corresponding to different types of subscribers are predefined in an identity-permission mapping table. The extension is a structured extension based on the target FHIR resource being subscribed to, adding an extension element to the resource definition to store the reference ID of the privacy horizon configuration. The event capture module is used to monitor resource change events in the data center in real time through the internal event bus of the FHIR server or the persistent layer database logs. When an event is captured, the target FHIR resource associated with the event is extracted, and a pre-built matching engine is used to determine whether it hits the subscription conditions. If it does, a distribution task is generated and the distribution task and the corresponding extended subscription contract are pushed into the asynchronous distribution task queue. The dynamic interception module is used to extract tasks from the asynchronous distribution task queue in the outbound pipeline. Before pushing the target FHIR resource to the subscriber, it activates the privacy computing interceptor, obtains the subscriber's privacy level and desensitization strategy according to the subscription contract, and determines whether the current distribution task needs to start the desensitization process: if the obtained privacy level of the subscriber is a fully visible privacy level, it is determined that it is not needed; if the obtained privacy level of the subscriber is a partially desensitized privacy level or a completely hidden privacy level, it is determined that it is needed. The loading and reconstruction module is used to directly load the payload of the target FHIR resource as a resource copy when the dynamic interception module determines that the desensitization process does not need to be started; when the dynamic interception module determines that the desensitization process needs to be started, it performs real-time reconstruction of the payload of the target FHIR resource at the object level or serialized text stream according to the desensitization strategy and uses a pre-set algorithm model to generate a desensitized resource copy that meets the subscriber's privacy level. The secure distribution module is used to encapsulate directly loaded resource copies or de-identified resource copies into the standard FHIR format and push them to subscribers through a specified channel.

8. An electronic device comprising at least one processor and a memory; wherein, The memory stores computer execution instructions; characterized in that, when the at least one processor executes the computer execution instructions stored in the memory, the at least one processor performs the FHIR data dynamic desensitization and distribution method as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is run by the processor, it controls the device containing the storage medium to perform the FHIR data dynamic desensitization and distribution method as described in any one of claims 1-6.

Images