A compliance certification management system for cross-border medical device trade
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- XIAMEN UNIV TAN KAH KEE COLLEGE
- Filing Date
- 2025-11-04
- Publication Date
- 2026-06-19
Smart Images
Figure CN121094846B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of compliance certification management technology, specifically a compliance certification management system for cross-border medical device trade. Background Technology
[0002] The medical device industry is a highly regulated sector, and cross-border trade of its products requires manufacturers to comply with the complex regulatory systems of different countries or regions and submit extensive compliance certification documents to gain market access.
[0003] In current practice, these compliance certification materials typically exist in static, unstructured document formats, such as PDF technical reports, Word design specifications, or image files. Internal management of these documents often relies on file server-based directory structures and manually named version control. When providing materials to external entities, such as regulatory agencies or customs, this is usually done via email attachments or uploading to a designated portal.
[0004] This document-centric management and interaction model has inherent technical flaws. Because compliance information is enclosed in separate, unstructured documents, key data such as specific performance parameters and material specifications are difficult for the system to automatically retrieve, aggregate, or reuse. This results in a large amount of repetitive manual screening and editing work being required when preparing registration dossiers for different markets.
[0005] Meanwhile, when compliance documents are revised, tracking the impact of those revisions on all registered products becomes extremely difficult. Manually maintained version records are prone to errors or omissions, compromising the integrity and traceability of compliance data. Furthermore, the process of questioning and responding to regulatory agencies is often detached from the core document repository and conducted through fragmented channels such as email. This makes it difficult to effectively link the interaction history to specific compliance data points, leading to breaks in the audit evidence chain.
[0006] More importantly, sending complete documents containing a large amount of sensitive information directly to external entities means that the data owner loses control over the content of the document once it is sent. They cannot restrict the recipient to only access necessary information, nor can they revoke access rights afterward. This poses significant risks to data security and the leakage of trade secrets. Therefore, existing technologies cannot provide a systematic solution that ensures data integrity, controllable interaction, and efficient processes. Summary of the Invention
[0007] This invention provides a compliance certification management system for cross-border medical device trade, aiming to solve technical problems in existing compliance processes such as unstructured data, difficulty in traceability, low efficiency of multi-party collaboration, and poor security and controllability of data sharing.
[0008] To achieve the above objectives, the present invention provides a compliance certification management system for cross-border medical device trade. The system is deployed on a server and includes: a unified compliance data management module, a regulatory knowledge graph module, a dynamic registration dossier generation module, and an interaction and presentation module.
[0009] The unified compliance data management module is used to store, manage, and maintain multiple standardized compliance data units in a structured form.
[0010] The standardized compliance data unit is a basic data entity formed by atomically deconstructing information in traditional compliance documents. Each standardized compliance data unit includes: a globally unique identifier to uniquely identify the data unit within the system, a version number to identify its different revisions, and a lifecycle state to characterize its stage in the business process. Based on predefined business actions, such as submitting for review, approval, rejection, or receiving an inquiry, this module calls a state transition function to update the lifecycle state of the standardized compliance data unit.
[0011] Specifically, when a revision request is received for a standardized compliance data unit that is in an approved state, the unified compliance data management module performs version control: first, it creates a new version data unit that inherits the globally unique identifier and sets its lifecycle state to the initial draft state, while updating the lifecycle state of the original data unit to be replaced, thereby ensuring that the historical record of compliance data is complete and tamper-proof.
[0012] The regulatory knowledge graph module is used to store the regulations, technical standards, and relationships between medical devices to form a graph database, providing structured rule query support for subsequent data aggregation and strategy recommendation.
[0013] The dynamic registration dossier generation module is used to respond to dossier generation requests initiated by the manufacturer's terminal. Based on parameters such as the target market included in the request, this module queries and parses the corresponding regulatory requirements from the regulatory knowledge graph module, and then queries and aggregates all standardized compliance data units related to the target product that are in an approved state and are the latest version from the unified compliance data management module, ultimately forming a dossier data set for use by subsequent modules.
[0014] The interaction and presentation module generates a dynamic authorization access credential based on the dossier data set generated in the preceding steps. This dynamic authorization access credential includes an encrypted access token for authentication and integrity verification, a permission scope for precisely defining the range of accessed data, and a view template identifier for specifying the presentation interface. When an external terminal initiates an access request using this dynamic authorization access credential, the interaction and presentation module first performs a security verification on the encrypted access token; after successful verification, it retrieves the corresponding data from the unified compliance data management module according to the permission scope defined in the credential, loads the interface layout according to the view template identifier, and finally dynamically renders a visual interface that contains only authorized data and is adapted to the business scenario of the external terminal.
[0015] In one embodiment, the system further includes an interactive inquiry response processing module. This module is used to capture structured inquiry information initiated by an external terminal (e.g., a regulatory terminal) through the visualization interface, associate the inquiry information with one or more standardized compliance data units being questioned, and call a state transition function to update the lifecycle state of the associated standardized compliance data unit to be questioned. Furthermore, this module is also used to associate response data units created internally by the enterprise in response to the inquiry information, which also exist in the form of standardized compliance data units, with the original inquiry information at the data level. Thus, when the external terminal accesses the system again through the original dynamic authorization access credentials, the interaction and presentation module can present the original questioned data, the inquiry information, and the subsequent response data units in the same visualization interface, thereby forming a traceable interactive closed loop.
[0016] In another embodiment, the system also includes a compliance strategy recommendation module based on state analysis. This module continuously monitors lifecycle state change events of standardized compliance data units triggered by multi-terminal interaction behavior within the system. A state change event is defined as a structured data object containing the identifier of the target standardized compliance data unit, its lifecycle state before and after migration, and the source terminal type and specific business action type that triggered the state migration. Upon receiving such an event, the module initiates a deep association query to the regulatory knowledge graph module, starting with the event content, to obtain relevant entities and relationships. Subsequently, the query results are matched against a preset inference rule base containing multiple IF-THEN rules. Once a match is successful, a structured recommendation object containing recommendation type, description, and suggested action is generated and pushed to the manufacturer terminal, realizing a forward-looking compliance strategy recommendation driven by data state.
[0017] This invention provides a compliance certification management system for cross-border medical device trade. It has the following beneficial effects:
[0018] 1. This invention significantly improves the integrity and traceability of compliance data by designing standardized compliance data units and combining them with lifecycle status and version control mechanisms. The system deconstructs unstructured compliance information into atomic data units, which are managed by a unified compliance data management module. Any revision to approved data is achieved by creating a new version and setting the old version to be superseded, ensuring that every change is clearly recorded and historical versions are retained, providing a solid and reliable data foundation for regulatory audits and quality management.
[0019] 2. This invention achieves precise control and high security for compliant data sharing in cross-border trade by designing dynamic authorization access credentials and corresponding parsing and presentation mechanisms. The interaction and presentation module can generate access credentials containing specific permission ranges, view templates, and encrypted access tokens for different external entities, ensuring that external entities can only view their authorized data content and present it in an interface adapted to their business scenario. This effectively avoids the security risks of excessive data exposure and loss of control in traditional file exchange models.
[0020] 3. This invention improves multi-party collaboration efficiency and transforms compliance management from passive response to proactive planning by constructing an interactive inquiry response processing module and a compliance strategy recommendation module based on state analysis. The system directly links external inquiries and internal responses to specific data units, forming a closed loop and improving communication efficiency. Simultaneously, by continuously monitoring data state change events and combining them with regulatory knowledge graphs for reasoning, it can automatically identify opportunities for evidence reuse or warn of potential risks, providing forward-looking decision support for managers. Attached Figure Description
[0021] Figure 1 This is a functional module architecture diagram of a cross-border medical device trade compliance certification management system according to an embodiment of the present invention;
[0022] Figure 2 This is a sequence diagram illustrating the workflow of a cross-border medical device trade compliance certification management method according to an embodiment of the present invention.
[0023] The modules include: 10. Unified Compliance Data Management Module; 20. Regulatory Knowledge Graph Module; 30. Dynamic Registration Dossier Generation Module; 40. Interactive Inquiry Response Processing Module; 50. Compliance Strategy Recommendation Module Based on Status Analysis; and 60. Interaction and Presentation Module. Detailed Implementation
[0024] To make the objectives, technical solutions, and advantages of the present invention clearer, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. These descriptions are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.
[0025] See attached document Figure 1 , Figure 1 This is a functional module architecture diagram of a cross-border medical device trade compliance certification management system according to an embodiment of the present invention. The present invention provides a cross-border medical device trade compliance certification management system, which is deployed on a server. The system includes: a unified compliance data management module 10, a regulatory knowledge graph module 20, a dynamic registration dossier generation module 30, an interactive inquiry response processing module 40, a compliance strategy recommendation module based on state analysis 50, and an interaction and presentation module 60.
[0026] The Unified Compliance Data Management Module 10 is used to store, manage, and maintain all Standardized Compliance Data Units (SCDUs) in a structured format. This module performs version control and lifecycle status management on SCDUs, providing an accurate, consistent, and traceable compliance data source for requests from different business terminals.
[0027] The regulatory knowledge graph module 20 is a graph database that stores medical device regulations, technical standards, and their interrelationships. This module provides structured rule query and correlation analysis support for the dynamic registration dossier generation module 30 and the state-based compliance strategy recommendation module 50.
[0028] The dynamic registration dossier generation module 30 is used to perform data aggregation functions. Based on the regulatory requirements of a specific target market, this module queries and aggregates relevant SCDUs from the unified compliance data management module 10 to form a virtual dossier for authorized access generated by the supply interaction and presentation module 60.
[0029] The interactive challenge response processing module 40 is used to process feedback initiated by external entities such as regulatory terminals. This module captures structured challenge information, associates it with a specific SCDU, updates the lifecycle status of the SCDU, and manages the internal response process to ensure traceability between challenges and responses.
[0030] The compliance strategy recommendation module 50, based on state analysis, is used to analyze the state of compliance data. This module monitors SCDU state change events triggered by interactions between different terminals (such as approval at a regulatory terminal or clearance at a customs terminal), and uses the regulatory knowledge graph module 20 to infer and generate strategy recommendations for other compliance tasks.
[0031] The interaction and presentation module 60 is the interactive interface of this system for various types of terminals (including internal manufacturer terminals, external regulatory terminals, customs terminals, etc.). It is used to generate dynamic authorized access credentials (DAAC) containing specific permissions and access tokens, and to verify credentials and dynamically render a visual interface adapted to the business scenario based on the DAAC request of different terminals. For example, it provides a deep review view for regulatory terminals or a fast release verification view for customs terminals.
[0032] See attached document Figure 2 , Figure 2 This is a sequence diagram illustrating the workflow of a cross-border medical device trade compliance certification management method according to an embodiment of the present invention. The present invention provides a cross-border medical device trade compliance certification management method, comprising the following steps:
[0033] S10: Internal users of the enterprise enter the original compliance information through the manufacturer's terminal. After receiving the information, the system generates the corresponding standardized compliance data unit (SCDU) in the unified compliance data management module 10, and sets its lifecycle status to approved after the internal review process.
[0034] S20, in response to the need to submit a registration application to a regulatory agency in a specific country, the dynamic registration dossier generation module 30 aggregates relevant approved SCDUs according to the rules parsed by the regulatory knowledge graph module 20, and the interaction and presentation module 60 generates a first dynamic authorized access credential (DAAC) for the regulatory terminal. This first DAAC has the scope of authority for in-depth technical review.
[0035] S30, the supervisory terminal accesses the system through the first DAAC, and the interaction and presentation module 60 verifies the credentials and presents an online dossier view for review. If the supervisory terminal initiates an inquiry during the review process, the interactive inquiry response processing module 40 captures the inquiry, associates it with the SCDU being inquired about, and updates its status.
[0036] S40: After receiving the challenge notification, the manufacturer terminal submits response materials through the system. The response is associated with the original challenge via the interactive challenge response processing module 40 and updates the access content of the first DAAC, so that the supervisory terminal can view the response.
[0037] S50: After a product receives market approval, the interaction and presentation module 60 generates a second dynamic authorized access credential (DAAC) for the customs terminal to meet the needs of export customs clearance. The scope of authority of this second DAAC is strictly limited, including only data items required for customs clearance such as product approval status, validity period, manufacturer and importer information.
[0038] S60: The customs terminal initiates a rapid verification request to the interaction and presentation module 60 by scanning the second DAAC attached to the goods or shipping documents. After verifying the document, the interaction and presentation module 60 immediately returns a simplified verification interface containing only the release information to the customs terminal.
[0039] S70, the compliance strategy recommendation module 50 based on status analysis continuously monitors the status changes of SCDU. For example, based on the approval status update generated by the interaction with the regulatory terminal in S30, or the batch release data generated by the interaction with the customs terminal in S60, it performs inference analysis and pushes compliance strategy recommendations for registration in other countries' markets or optimization of existing processes to the manufacturer's terminal.
[0040] The core of the unified compliance data management module 10 is the management of standardized compliance data units (SCDUs). SCDUs are the basic information entities processed, stored, and interacted with in the method of this invention. Their purpose is to deconstruct unstructured or semi-structured information in traditional compliance documents into discrete, machine-readable atomic data units.
[0041] In this invention, the Standardized Compliance Data Unit (SCDU) is formally defined in the system as a tuple. :
[0042] ;
[0043] The definitions and specific implementation methods of each component are as follows:
[0044] This is a globally unique identifier of string data type. This identifier is used to uniquely identify an SCDU throughout the entire system and even in a distributed environment, regardless of its version. In one specific implementation, this identifier can be generated by calling a generic unique identifier (UUID) generation algorithm (e.g., UUIDv4) to ensure its global uniqueness.
[0045] This is a version number, and its data type is an integer. This version number is used to identify the same... The SCDU has different revisions, with an initial value of 1. Each valid revision of the content will cause the version number to increment.
[0046] This is a timestamp that records the creation or last revision time of the current version of the SCDU. This timestamp can be stored in the ISO 8601 format published by the International Organization for Standardization (ISO) to ensure the clarity and universality of the time information.
[0047] This is a user identifier of string type. This identifier records the identity of the internal user or system process that created or revised the current version of the SCDU.
[0048] It is a data type whose value is a collection of predefined enumerations. The value selected from the data. This type of field is a fundamental classification of the business attributes of the content carried by the SCDU, and is the basis for subsequent retrieval, aggregation, and access control. Collection This includes, but is not limited to, the following enumerated values: performance parameters, material specifications, biocompatibility test results, sterilization process parameters, design inputs, risk control measures, label content, and instruction snippets. The system architecture of this invention supports this enumerated set. It will be expanded to accommodate future new compliance data requirements.
[0049] This is structured data content. The field is stored in a machine-readable data format, such as JavaScript Object Notation (JSON). Its internal data structure strictly depends on... The values of the fields, i.e., different data types correspond to different content structures. For example:
[0050] when When it is a performance parameter, The structure can be defined as {"parameter_name":"...","test_method":"...","value":...,"unit":"..."}.
[0051] when When it is a material specification, The structure can be defined as {"material_name":"...","supplier":"...","grade":"...","batch_number":"..."}.
[0052] In this way, the inherent structural consistency and predictability of data of the same type are ensured.
[0053] This is a pointer to the source file, with a string data type and a Uniform Resource Identifier (URI) content. This pointer points to the original, unanalyzed evidence file associated with the current SCDU, such as a complete PDF test report or a CAD drawing. The URI can point to a specific file location within an enterprise's document management system or a secure cloud object storage service. The purpose of this field is to provide atomic data while preserving a traceability path to complete contextual evidence.
[0054] This refers to the lifecycle state. The value of this field is a set of predefined states. The selected values represent the stage of the SCDU within the business process. (Set) This includes, but is not limited to: draft, pending review, approved, superseded, and subject to inquiry. The transitions between these states are controlled by subsequent business processes.
[0055] In one specific embodiment, the process of creating an SCDU may include the following steps:
[0056] S210, the system receives the raw data input by the user from the manufacturer's terminal, the data type to which the data belongs, and the associated raw evidence file.
[0057] S211, System calls UUID algorithm to generate Record the user currently performing the operation. and timestamp and initialize the version number. The value is 1.
[0058] S212, the system determines the type of data received. It calls the corresponding content structure template, fills in the user-inputted raw data, and forms structured data content. The generation of JSON can be implemented by those skilled in the art using various existing programming language libraries, and is well-known in the field, so it will not be elaborated here.
[0059] S213, the system uploads the received original evidence file to the pre-configured storage server, obtains its access URI, and assigns it to the source file pointer. .
[0060] S214, The system uses all the fields generated in the above steps to instantiate a new SCDU object and initialize its lifecycle state. Set as a draft, and then store the SCDU object in the database of the unified compliance data management module 10.
[0061] To ensure that the use of Standardized Compliance Data Units (SCDUs) is controlled and traceable throughout the business process, the Unified Compliance Data Management Module 10 integrates a lifecycle and version control mechanism. This mechanism ensures that every SCDU's state change is traceable, and that any revision generates a new version, preserving a complete historical record.
[0062] SCDU lifecycle management is achieved through a state transition function. This is implemented by defining the SCDU from a lifecycle state. The rules for transitioning to another state can be formally expressed as follows:
[0063] ;
[0064] in, This represents the new lifecycle state of the SCDU after migration; This represents the current lifecycle status of the SCDU; This represents an external or internal business action that triggers a state transition, and its value is a set of predefined actions. The values selected from the set. This includes, but is not limited to: submitting for review, approving, rejecting, initiating revisions, and receiving inquiries.
[0065] A typical lifecycle state transition process may include the following steps:
[0066] S220: When an SCDU is in draft state, the user who created it can edit its content freely. This action occurs when the user submits the SCDU for review on the manufacturer's terminal. It was captured by the system.
[0067] S221, System call state transition function The function takes the current draft status and the action submission for review as input, and returns a new status pending review.
[0068] S222, the system updates this SCDU instance. The field value is "Pending Review". In this state, the content of the SCDU is locked and cannot be edited by ordinary users; it can only be viewed by users with review privileges. When a user with the appropriate privileges performs an approval or rejection action, it will trigger a further status transition to "Approved" or "Return to Draft".
[0069] S223, specifically, when the interactive challenge response processing module 40 captures a challenge from an external terminal, and the challenge points to an SCDU in an approved state, the system will act as if it has received the challenge. Call the state transition function and change the state of the SCDU. The data unit is updated to be questioned, which serves as a marker that the data unit is under external review.
[0070] The version control mechanism and lifecycle management mechanism of this invention are integrated to handle revision requests for approved SCDUs. This mechanism ensures that any modification to official data does not overwrite historical records, but is achieved by creating a new version. A specific version creation and control process is as follows:
[0071] S230, when an SCDU (denoted as...) When a content is in the approved state, it means that its content has been reviewed and confirmed and can be used to generate a formal registration dossier. If revisions are needed at this point, the user must modify the content on the manufacturer's terminal. Initiate the revision action.
[0072] S231, after receiving this action, the system does not directly modify it. The system performs a new version creation operation, which first generates a new SCDU instance in the database, denoted as... .
[0073] S232, New Instance Most fields are inherited from Including the same globally unique identifier But its version number Set as Meanwhile, new instances Lifecycle status Reset to the initial draft state, its timestamp and user identifier Updated to the time and user of the current operation.
[0074] S233, At the same time, the system will use the old version of the SCDU instance. Lifecycle status Updated to "Overridden". This status indicates that the data in this version has been replaced by a newer version. It should no longer be selected by default in the generation of new dossiers, but it is permanently retained as historical data for auditing and traceability.
[0075] S234, and subsequent new versions It will be treated as an independent SCDU, following the lifecycle process from S220 to S222, until it obtains its own approved status before it can be used for subsequent business.
[0076] All state updates and version creation operations within this lifecycle and version control mechanism are executed at the database level through atomic transactions to ensure operational integrity and data consistency. For the implementation of database transactions, those skilled in the art can utilize the standard functions provided by existing mature relational or NoSQL databases, which are well-known technologies in the field and will not be elaborated upon here. Through this mechanism, this invention ensures that every compliant data point possesses an immutable historical record, providing a data foundation for compliance requirements and regulatory audits.
[0077] The dynamic registration dossier generation module 30 automatically aggregates distributed Standardized Compliance Data Units (SCDUs) into a structured collection of registration dossier data awaiting authorized access, according to specific regulatory requirements. This method replaces the traditional process of manually searching, filtering, and compiling documents. Its core lies in utilizing the structured knowledge provided by the regulatory knowledge graph module 20 to guide the retrieval and aggregation of compliance data.
[0078] The dynamic dossier aggregation method is executed by the dynamic registration dossier generation module 30, and may include the following steps:
[0079] S310, the system receives a dossier generation request from the manufacturer's terminal. This request contains at least three key parameters: the target product identifier from which the dossier needs to be generated. Target market or regulatory agencies and specific submission types (For example, initial registration or change application).
[0080] S311, the dynamic registration dossier generation module 30 initiates a structured knowledge query to the regulatory knowledge graph module 20 based on the received request parameters. This query is executed within the regulatory knowledge graph, and its query logic is as follows:
[0081] First, identify the target market that is associated with the category to which the target product belongs. and submission type The legal entity node;
[0082] Then, starting from the legal entity node, traverse all edges representing "requirement" relationships, and finally summarize all data type nodes pointed to by these edges.
[0083] The result of this query is a set of SCDU data types necessary to complete this submission. For the implementation of the graph query language, those skilled in the art can use existing graph database systems, which are well-known technologies in the field and will not be elaborated upon here.
[0084] S312, after obtaining the required set of data types, the dynamic registration dossier generation module 30 executes a data aggregation query on the database of the unified compliance data management module 10. This aggregation query aims to filter out all SCDU instances that meet all of the following conditions to form the data set constituting the virtual dossier:
[0085] First, the SCDU instance and the target product identifier Related. In one specific implementation, this relationship can be determined by checking whether the metadata fields of the SCDU instance (such as product_link) contain... This relationship can be determined by the user in the metadata when the SCDU is created, or maintained through other data tables.
[0086] Second, the data type of this SCDU instance belongs to the data type set obtained in the previous step S311.
[0087] Third, the lifecycle status of this SCDU instance is approved.
[0088] Fourth, the SCDU instance must be the latest version under its globally unique identifier. In a specific implementation, this can be determined by querying the database for all SCDUs with the same globally unique identifier as the instance and comparing their version numbers. This condition is satisfied if and only if there is no version with a higher version number than the instance.
[0089] S313, the execution result of this data aggregation query operation is a structured data set. It should be noted that this data set is a list of references or a collection of objects containing all SCDU instances that meet the conditions. This set is then passed to the interaction and presentation module 60 as the data basis for generating Dynamic Authorization Access Credentials (DAAC). In this way, the present invention completes the automated process from parsing regulatory requirements to the precise aggregation of compliant data, and prepares the necessary data carrier for the subsequent dynamic authorization access stage.
[0090] After receiving the SCDU data set aggregated by the dynamic registration dossier generation module 30, the interaction and presentation module 60 executes the dynamic authorization access credential (DAAC) generation and security parsing mechanism. This mechanism aims to create a controllable, secure, and timely data access channel for external terminals other than the manufacturer (such as regulatory agencies, customs, and business partners) to review and verify compliance data.
[0091] A DAAC is formally defined in the system as a tuple. :
[0092] ;
[0093] The definitions and specific implementation methods of each component are as follows:
[0094] This is a unique identifier for this DAAC, and its data type is string.
[0095] The identifier of the target entity that the DAAC authorizes to access, such as the ID of a registered project, which is associated with one or more SCDU collections.
[0096] The DAAC pre-defines the recipient's identity profile, with data formatted as JSON. This profile describes the recipient's type and identity, such as {"type":"regulator","agency":"FDA"} or {"type":"customs","port":"Shanghai"}.
[0097] This is the expiration timestamp for the DAAC. Once the current time exceeds this timestamp, the DAAC will be automatically invalidated.
[0098] It is an encrypted access token used for authentication and integrity verification of access requests.
[0099] The scope of permissions defines a subset of the data types of SCDUs that can be accessed through this DAAC, which is a subset of the complete set of SCDU types. A subset of.
[0100] This is an identifier for a view template, used to specify the interface layout and style used when presenting data.
[0101] The DAAC generation process is executed by the interaction and presentation module 60 and may include the following steps:
[0102] S320, the system receives a request to generate a DAAC from the manufacturer's terminal, the request containing the target entity identifier associated with the aforementioned aggregated SCDU set. and the identity profile of the recipient specified by the user. Scope of permissions View Templates And the validity period.
[0103] S321, the interaction and presentation module 60 generates an access token based on the received parameters. In one specific implementation, the access token can be a JSON Web Token (JWT) conforming to the RFC 7519 standard. The payload portion of the JWT must contain at least... , , , , and expiration timestamp The system then signs the JWT using the asymmetric encryption private key stored on the server, generating the final access token. The generation and signing of JWTs can be implemented using existing open-source libraries, which are well-known technologies in the field and will not be elaborated upon here.
[0104] S322, the interaction and presentation module 60 will generate the access token. Embedded within a Uniform Resource Locator (URL), a final, shareable DAAC is formed. For example, the format of this DAAC could be https: / / [system domain name] / access?token=[T_{a}]. This URL can be provided to the intended recipient via email, instant messaging, or printed as a QR code.
[0105] When an external end-user uses DAAC to access the system, the system's security resolution and dynamic rendering mechanism is triggered, which may include the following steps:
[0106] S330, the external end-user's device (such as a computer or mobile scanning device) initiates an HTTPS request to the interaction and presentation module 60 via the DAAC URL. This request contains the access token. .
[0107] S331, After receiving the request, the interaction and presentation module 60 first checks the access token. Perform security verification. This verification process includes at least the following: First, verify the token's signature using the public key paired with the private key used to generate the signature, ensuring the token has not been tampered with; second, parse the expiration timestamp in the token payload. The system compares the token with the current server time to ensure it hasn't expired. If any verification fails, the system will reject the access request.
[0108] S332, after the access token passes security verification, the interaction and presentation module 60 parses the permission scope from the token's payload. and view template identifier .
[0109] S333, the interaction and presentation module 60, based on the parsed permission scope... The system requests relevant SCDU data from the Unified Compliance Data Management Module 10. This module will only return data whose data type falls within its authorized scope. Subset of data. Subsequently, the interaction and presentation module 60 loads the view template identifier. The corresponding interface template is generated, and the acquired SCDU data is injected into the template to ultimately produce an HTML page response. This response is sent back to the external end user's device for rendering, allowing the user to see a dynamic view containing only the data they are authorized to access, with an interface adapted to their business scenario.
[0110] The interactive challenge response processing module 40 handles challenges initiated by external terminals using Dynamic Authorization Access Credentials (DAAC) and links this interaction with the lifecycle status of Standardized Compliance Data Units (SCDUs). This mechanism transforms traditional, unstructured email or telephone communication into a traceable, integrated, closed-loop processing flow.
[0111] When an external user (e.g., a regulatory auditor) accesses and views a dynamically generated dossier view via DAAC, the challenge capture and status linkage mechanism of this invention may include the following steps:
[0112] In the dynamic view generated by the interaction and presentation module 60 (S410), each presented SCDU data item is associated with a user interface element, such as a button or link labeled "Initiate a Question". This interface element is embedded with a globally unique identifier for its corresponding SCDU during generation. .
[0113] S411, when an external user has a question about a specific SCDU data item and clicks on the interactive interface element, the system presents a structured query input form. The user enters their query in the form and submits it. This submission sends a query request to the interactive query response processing module 40. This request must contain at least the globally unique identifier of the SCDU being queried. The challenge text entered by the user, and the access token originating from the current DAAC used to verify the user's identity. .
[0114] S412, after receiving the challenge request, the interactive challenge response processing module 40 first checks the access token. A security check is performed to verify the identity and permissions of the challenger. Once the check passes, the module instantiates a structured challenge object. A challenge object is formally defined in the system as a tuple. :
[0115] ;
[0116] in, This is a unique identifier for this query; The globally unique identifier of the SCDU being challenged, whose value is derived from the request. ; To create an identity profile for the inquirer, its value is derived from the access token. The load was analyzed and obtained; The timestamp of when the query was received; This is structured challenge content, the value of which comes from the challenge text entered by the user.
[0117] The query object is stored in the system's database for persistent recording and tracing.
[0118] S413, after the challenge object is successfully created, the interactive challenge response processing module 40 executes the SCDU status linkage operation. This module uses the data from the challenge object... The SCDU instance being questioned was located in the database of the unified compliance data management module 10.
[0119] S414, this module calls the lifecycle state transition function of SCDU. The current status of the SCDU (usually approved) is used as input. And take a predefined challenge-receiving action as input. After the function executes, it returns a new lifecycle state that is challenged. The system then updates the SCDU instance's... The field value is "Under Question". This status change serves as a system flag indicating that the data point is currently under external review and awaiting a response.
[0120] S415, after completing the storage of the challenge object and updating the SCDU status, the system pushes a notification to the manufacturer's terminal or generates a to-do item in its task management interface. This notification or to-do item includes a summary of the challenge content and a link to the challenge object, prompting relevant internal personnel to process and respond to the challenge. Through these steps, the present invention ensures that every external challenge is captured and structured, and automatically reflected in the status management of core compliance data.
[0121] After the interactive challenge response processing module 40 captures and processes the external challenge, the present invention provides a method for creating and presenting the internal response with traceable associations to complete the closed loop of challenge processing and ensure that the entire interactive process has a complete chain of evidence.
[0122] The internal response creation and presentation method of the present invention may include the following steps:
[0123] S420: After the system pushes a challenge notification to the manufacturer's terminal, an internal user with the appropriate permissions accesses the challenge object. To view the specific content of the inquiry.
[0124] S421, the user prepares response materials based on the query content. In embodiments of the present invention, the response materials do not exist in the form of unstructured text or independent files, but are created as one or more new Standardized Compliance Data Units (SCDUs). These SCDUs used for responses (hereinafter referred to as "response SCDUs") also follow the structured definition and lifecycle management mechanism of SCDUs, such as their data types. It can be set as a response description or supplementary evidence. After its creation, the response SCDU undergoes an internal drafting and review process until its lifecycle status. Approval has been reached.
[0125] S422, after the SCDU response is approved, the interactive challenge response processing module 40 performs a correlation operation to establish a traceable link between the original challenge and the response. This module instantiates a structured response object. A response object is formally defined in the system as a tuple. :
[0126] ;
[0127] in, This is a unique identifier for this response; A unique identifier for the responding query object, whose value is derived from the query object to be processed. ; A globally unique identifier for an approved response SCDU that contains specific response content; For the timestamp used to create this response; The identifier of the internal user who created the response.
[0128] The response object The data is stored in the system's database, thus solidifying the correspondence between the challenge and the response at the data level.
[0129] S423, after the response object is created, the interactive challenge response processing module 40 processes the original challenged SCDU (i.e., The SCDU (pointed to) executes the state linkage operation again. This module calls the state transition function. The current state of the SCDU is queried as input. and takes a predefined completion response action as input. After the function executes, it can return a new status, such as "responded". The system then updates the SCDU instance. Field value.
[0130] S424, the external challenger does not need to obtain a new link; it can view the response content by accessing the original Dynamic Authorization Access Token (DAAC). When the external terminal initiates an access request again through the same DAAC, the interaction and presentation module 60 performs an extended data query after completing token verification.
[0131] S425, when preparing data for an external terminal, the interaction and presentation module 60 checks each SCDU contained in the view. If it finds that a certain SCDU (e.g., the original challenged SCDU) has an associated challenge object... and response object This module will not only obtain the data of the SCDU itself, but also, based on the response object... In It also retrieves the data content of the associated response SCDU.
[0132] S426, Interaction and Presentation Module 60 loads a preset view template. The acquired data is then injected into the template. This template contains conditional rendering logic; when a data item is detected to have both challenge and response data, it displays the original data, challenge content, and response content on the interface, forming a logically coherent view unit. Through this method, the present invention dynamically adds subsequent interaction content to the original view without compromising the validity of the original authorization certificate, presenting a complete interaction history to external users.
[0133] The compliance strategy recommendation module 50 based on state analysis relies on the effective capture of business-significant events occurring within the system. To this end, this invention provides a state data acquisition model for multi-terminal interaction events. This model aims to transform heterogeneous interaction actions originating from different business terminals into unified, structured state change event data that can be used for analysis.
[0134] This invention defines a state change event as a data object within the system. The core of this acquisition model lies in identifying business interaction actions that can trigger state changes in the SCDU lifecycle, and collecting and solidifying the context information of these interactions into a state change event object. This object is formally defined within the system as a tuple. :
[0135] ;
[0136] The definitions and specific implementation methods of each component are as follows:
[0137] This is a unique identifier for this state change event.
[0138] The globally unique identifier of the target SCDU affected by this event.
[0139] This represents the lifecycle state of the SCDU before the event occurred.
[0140] This represents the lifecycle state to which the SCDU migrates after the event occurs.
[0141] The source terminal type for this terminal interaction action is a value selected from a predefined set of terminal types, including but not limited to: manufacturer terminals, regulatory terminals, and customs terminals.
[0142] The specific business action that triggers this event, such as approving a listing, releasing goods, or completing an internal audit.
[0143] This field contains additional data associated with the event, formatted as JSON. It stores non-stateful contextual information related to the event; for example, if the event is market approval, the additional data might include the approval number and approval date.
[0144] The specific implementation process of this state data acquisition model may include the following steps:
[0145] S510, when processing interaction requests from different terminals, the various modules in the system (such as the interaction and presentation module 60 and the interactive query response processing module 40) monitor business actions that are predefined as triggering state changes. For example, approval operations performed by the regulatory terminal through the DAAC view, or clearance operations performed by the customs terminal.
[0146] S511, when such a business action is triggered, the module handling the action will determine the corresponding SCDU state transition logic based on a preset "terminal action-state transition" mapping rule. This mapping rule defines which terminal and which action will cause the target SCDU to transition from which old state to which new state. For example, a rule can be defined as: (Terminal type: regulatory terminal, Action type: approved for market launch) => (SCDU old state: responded, SCDU new state: approved - specific market).
[0147] S512, after determining the state transition logic, the system executes the actual SCDU state update operation, updating its lifecycle state. Update from the old state to the new state.
[0148] S513, after the SCDU state update is successful, the system instantiates a state change event object as defined above. The system generates a unique identifier for the event. It also extracts information from the context of the interaction to populate the various fields of the event object, including the identifier of the target SCDU. State before and after migration and The type of terminal from which the interaction occurs Specific types of business actions and additional data parsed from the interaction request. .
[0149] S514, the system will generate state change event objects The event object is stored in a dedicated event log database for auditing, tracing, and long-term business analysis. Simultaneously, this event object, as a data signal, is pushed to the message queue or input terminal of the state-based compliance policy recommendation module 50, serving as direct input for subsequent reasoning and analysis. Through this model, the present invention transforms multi-source, real-time business interactions into a standardized data stream suitable for machine analysis.
[0150] The compliance strategy recommendation module 50, based on state analysis, executes a reasoning recommendation method based on the state change event captured by the state data acquisition model of multi-terminal interaction events after receiving the event. This method aims to transform isolated data state changes into compliance strategy suggestions that can guide business decisions.
[0151] The reasoning recommendation method of the present invention is executed by the compliance policy recommendation module 50 based on state analysis, and may include the following steps:
[0152] S520, the input of the compliance strategy recommendation module 50 based on state analysis receives one or more state change event objects. This event object serves as a trigger signal for the reasoning process.
[0153] S521, this module uses event objects The target SCDU identifier included Business Action Types and additional data Starting from this point, a deep correlation query is initiated into the regulatory knowledge graph module 20. The purpose of this query is not simply data retrieval, but rather to traverse the graph through entities and their relationships related to the event, in order to uncover potential equivalence, relevance, or influence. For example, if an event indicates that a certain test result (SCDU) has been approved in the US market, the query will search the knowledge graph for "equivalent to" relationships to locate regulations in other countries that recognize that test result.
[0154] S522, the module internally contains an inference rule base, which stores a series of inference rules in the form of "IF-THEN". This module matches the related entities and relationships retrieved in step S521 against the rules in the inference rule base. In a specific implementation, this rule base may contain the following types of rules:
[0155] Evidence reuse rule: IF the status of an SCDU changes to approved - specific market M1, AND the knowledge graph shows that the requirements of market M1 for this SCDU type are equivalent to the requirements of market M2, THEN trigger an evidence reuse recommendation.
[0156] Change Impact Analysis Rule: IF if the status of an SCDU that is a base material changes to being replaced, AND the knowledge graph shows that products P1, P2 and P3 all use the base material, THEN trigger a registration change risk warning for products P1, P2 and P3.
[0157] The construction and matching execution of this inference rule base can be achieved by those skilled in the art using existing rule engine technology, which is a well-known technology in the field and will not be elaborated here.
[0158] S523, when one or more inference rules are successfully matched and triggered, the system generates a structured recommendation object. A recommendation object is formally defined in the system as a tuple. :
[0159] ;
[0160] in, This is a unique identifier for this recommendation; For recommendation types, the value is a value selected from a predefined enumeration set, such as new market opportunities, compliance risk warnings, and process optimization suggestions; A detailed textual description of the recommendation, used to explain the reasons and background for the recommendation to users; This recommendation is linked to a contextual trace, which contains the identifier of the original state change event that triggered the recommendation. and related SCDU identifiers; A suggested action can contain a deep link to an internal system function. When a user clicks on it, they can be directly redirected to the interface that performs the suggested action, such as the interface for "Starting a new EU MDR registration project".
[0161] S524, Finally, the system will generate recommended objects. The recommendations are pushed to the manufacturer's terminal. In one implementation, the recommended item can be presented as a card on the main dashboard after the user logs into the system, or a notification can be sent to the relevant project personnel or product managers through the system's internal message center. Through this method, the present invention transforms the business interaction results of different terminals into intelligent suggestions that can proactively guide the enterprise's compliance strategy through knowledge reasoning, thereby improving the efficiency and foresight of compliance management.
[0162] To more comprehensively illustrate how the various technical components of this invention work together, the following will be explained through a specific and comprehensive application scenario.
[0163] This example sets the scenario as follows: A medical device manufacturer has developed a smart blood glucose meter (hereinafter referred to as "the product"). The company plans to first apply for a certain type of registration in the US market, and simultaneously prepare compliance materials for the EU market.
[0164] S601: After completing performance testing of the product, the company's R&D engineers need to enter the critical "measurement accuracy" data into the system. Users log into the manufacturer's terminal, select "Create SCDU," and choose the data type. Select "Performance Parameter". The user inputs the test results (e.g., compliance with an internationally accepted standard) and uploads a PDF test report containing raw data and charts as the source file. The system then generates a new SCDU based on this, assigning it a globally unique identifier. Version number Set it to 1, and set its lifecycle state. Initialize as a draft.
[0165] S602: After the engineer completes data entry, they submit the data for review within the system. The Unified Compliance Data Management Module 10 captures this action, calls the state transition function, and changes the lifecycle state of the SCDU. The draft has been updated to pending review.
[0166] In S603, the company's quality assurance manager receives an audit notification and reviews the contents of the SCDU and its associated original report in the system. After confirming that everything is correct, the manager approves it. The system then calls the state transition function again to update the SCDU's status to approved. At this point, the SCDU concerning measurement accuracy has become a compliant data point that can be formally cited.
[0167] S604, the company's regulatory affairs manager is preparing to initiate the target market submission process. She initiates a dynamic dossier generation request in the manufacturer terminal, specifies the target product as this product, and sets the target market and submission type.
[0168] In step S605, after receiving the request, the dynamic registration dossier generation module 30 queries the regulatory knowledge graph module 20 for the set of data types required by the target market and submission type. Subsequently, based on this set of data types, the module performs a data aggregation query on the database of the unified compliance data management module 10, filtering out all SCDUs related to the product that are approved and are the latest version, including the measurement accuracy SCDUs approved in step S603.
[0169] S606, the Interaction and Presentation Module 60, based on the aggregated SCDU dataset and according to the permission scope specified by the regulatory manager (e.g., viewing only, downloading the original report not allowed), generates a DAAC containing an encrypted access token. This DAAC is ultimately represented as a secure URL, which the enterprise submits to the designated regulatory auditor through official channels.
[0170] S607, the regulatory auditor accesses the system by clicking this URL. After verifying the token's validity, the interaction and presentation module 60 dynamically renders a webpage view containing only the authorized SCDU data. While reviewing the measurement accuracy data, the auditor raises questions about the statistical analysis methods used in the report. He clicks the "Initiate Question" button next to the data item and enters the question in the pop-up form: "Please provide the statistical basis for the sample size selection."
[0171] S608, the interactive challenge response processing module 40 captures the challenge and creates a structured challenge object. This includes the content of the inquiry and an identity profile from the auditor's DAAC. Simultaneously, this module will display the inquiry target... Associate the SCDU with the queried measurement accuracy and call the state transition function to change the SCDU's lifecycle state. The system was updated to be subject to a challenge. The system then sent a challenge notification to the relevant engineers within the company.
[0172] S609, upon receiving the notification, the engineer prepared a detailed statistical methodology specification and created it as a new data type. This is the SCDU (Signature Query Unit) for the response description. After the SCDU has undergone internal review and obtained an approved status, the engineer designates it as the formal response to the auditor's query in the query processing interface. The system then creates a response object accordingly. At the data level, a system was established for questioning. Link to the response SCDU and update the status of the queried SCDU to "responded".
[0173] S610, when convenient, the auditor revisits the same DAAC link received previously. At this point, the interaction and presentation module 60 not only displays the original measurement accuracy data, but also dynamically loads and displays the auditor's own questions below it, along with the statistical methodology explanation (SCDU) provided by the company in response. The entire "data-question-response" interaction history is clearly presented in the same view.
[0174] S611, the auditor is satisfied with the response and performs an "Accept" or "Close Challenge" interaction in the view. This action is captured by the system and recorded as a state change event by the multi-terminal interaction event state data acquisition model. The source terminal type of this event object. For regulatory terminals, business action types For approval - technical review.
[0175] S612, this state change event It was pushed to the compliance strategy recommendation module 50 based on state analysis.
[0176] S613, this module uses this event as a trigger point to perform a correlation query with the regulatory knowledge graph module 20. The query reveals that there is an equivalence relationship between the testing standard on which the approved measurement accuracy SCDU is based and the standard that the product is required to comply with under the regulations of another market.
[0177] S614, the system matched an "evidence reuse rule". Based on this rule, the system generated a recommendation object Rec and displayed a strategy suggestion on the system homepage of the enterprise's regulatory affairs manager: "Measurement accuracy data that has passed technical review in one market has testing standards that are equivalent to the requirements of another market. It is recommended to directly reuse it in the registration project of this product in another market."
[0178] The suggestion is accompanied by a link that, when clicked, allows the SCDU to be added directly to the data list of another market project, thus completing an intelligent compliance strategy recommendation.
[0179] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.
Claims
1. A compliance certification management system for cross-border medical device trade, characterized in that, include: The unified compliance data management module is used to store, manage, and maintain multiple standardized compliance data units in a structured format. The standardized compliance data unit is a data unit formed by atomically deconstructing compliance information; The regulatory knowledge graph module is used to store regulations, technical standards, and their interrelationships for medical devices, forming a graph database. The dynamic registration dossier generation module is used to respond to dossier generation requests. Based on the target market regulatory requirements parsed by the regulatory knowledge graph module, it queries and aggregates relevant standardized compliance data units from the unified compliance data management module to form a dossier data set. The interaction and presentation module is used to generate a dynamic authorization access credential containing preset permissions based on the case file data set, and to respond to access requests initiated by external terminals through the dynamic authorization access credential, so as to verify the credential and dynamically render a visual interface adapted to the business scenario of the external terminal. The standardized compliance data unit includes: A globally unique identifier used to uniquely identify the data unit, a version number used to identify its different revisions, and a lifecycle state used to characterize its stage in the business process. The unified compliance data management module is also used for: Based on predefined business actions, a state transition function is invoked to update the lifecycle state of the standardized compliance data unit; the business actions include submitting for review, approval, rejection, or receiving inquiries. When a revision request is received for a standardized compliance data unit that is already in an approved state, the unified compliance data management module performs version control in the following manner: Create a new version of the data unit that inherits from the globally unique identifier and set its lifecycle state to draft, while updating the lifecycle state of the original data unit to be replaced. The dynamic authorization access credentials include: an encrypted access token for authentication and integrity verification, a permission scope for defining the scope of accessible data, and a view template identifier for specifying the presentation interface. When responding to the access request, the interaction and presentation module retrieves data from the unified compliance data management module according to the permission scope, and loads the interface layout according to the view template identifier.
2. The compliance certification management system for cross-border medical device trade according to claim 1, characterized in that, The system also includes: The interactive challenge response processing module is used to capture structured challenge information initiated by external terminals through the visual interface, associate the challenge information with one or more specific standardized compliance data units, and update the lifecycle status of the associated standardized compliance data units to be challenged.
3. The compliance certification management system for cross-border medical device trade according to claim 2, characterized in that, The interactive challenge response processing module is also used to: associate the response data unit created in response to the challenge information with the original challenge information; when the external terminal accesses again through the dynamic authorization access credential, the interaction and presentation module presents the original challenge information, the challenged standardized compliance data unit, and the response data unit together in the visualization interface.
4. The compliance certification management system for cross-border medical device trade according to claim 1, characterized in that, The system also includes: The compliance strategy recommendation module based on state analysis is used to monitor lifecycle state change events of standardized compliance data units and, in conjunction with the regulatory knowledge graph module, to perform reasoning to generate compliance strategy suggestions and push them to the manufacturer's terminal.
5. The compliance certification management system for cross-border medical device trade according to claim 4, characterized in that, The compliance strategy recommendation module based on state analysis monitors the system by capturing structured state change events, which include: the identifier of the target standardized compliance data unit, the lifecycle state before and after migration, and the source terminal type and business action type that trigger the state migration.
6. The compliance certification management system for cross-border medical device trade according to claim 5, characterized in that, The compliance strategy recommendation module based on state analysis generates the compliance strategy suggestions in the following manner: Based on the state change event, an association query is initiated to the regulatory knowledge graph module to obtain associated entities and relationships; The retrieved related entities and relationships are then matched with a pre-defined inference rule base to generate structured recommendation objects.