Medical clinical data management system based on sdtm standard

Abstract

The application provides a medical clinical data management system based on the SDTM standard, and relates to the technical field of medical clinical data management.The system comprises a client module located at a presentation layer, a standard engine module located at a business logic layer, and a database located at a data layer.The client module serves as an operation interface for a user and is used to receive a management operation of the user.The standard engine module responds to the management operation and performs a management operation on medical clinical data according to a standard data model.The standard data model is constructed based on the SDTM standard and comprises an organization work area, a project data set, a business table, a data row, and a table header field.The database comprises a system table and a project data set composed of one or more business tables.The system table is used to store metadata and global configuration information, and the business table is used to store medical clinical data under a corresponding project.

Description

Technical Field

[0001] This application relates to the field of medical clinical data management technology, and in particular to a medical clinical data management system based on the SDTM standard. Background Technology

[0002] Standardization of medical clinical data is a core foundation for ensuring the quality of clinical trial data and the efficiency of global collaboration. As the Study Data Tabulation Model (SDTM) standard developed by the Medical Clinical Data Exchange Standards Association has become the data submission standard for drug regulatory agencies in various countries.

[0003] Due to the lack of uniformity in data formats and standards within hospitals and research institutions, the existing conversion process from medical clinical data to SDTM standard datasets is cumbersome, has high manual processing costs, and is prone to errors, making it difficult to manage medical clinical data efficiently. Summary of the Invention

[0004] In view of the above problems, this application provides a medical clinical data management system based on the SDTM standard to overcome or at least partially solve the above problems.

[0005] This application discloses a medical clinical data management system based on the SDTM standard. The system includes a client module in the presentation layer, a standard engine module in the business logic layer, and a database in the data layer. Each database represents a storage unit for an organization, wherein:

[0006] The client module serves as the user's interface, used to receive user management operations, including data import, data export, and data editing.

[0007] The standard engine module responds to the management operation and performs management operations on medical clinical data according to the standard data model. The standard data model is built based on the Research Data Table Model (SDTM) standard and includes organizational workspaces, project datasets, business tables, data rows, and table header fields.

[0008] The database includes system tables and project datasets consisting of one or more business tables. The system tables are used to store metadata and global configuration information, and the business tables are used to store medical clinical data under the corresponding projects.

[0009] Optionally, the system table includes project-related tables and SDTM standard tables;

[0010] The project-related tables include a project table, a relationship table, and a list; wherein, the project table is used to record the attribute information of the organization's work area, project dataset, and business table; the relationship table is used to record the mapping relationship between the business table and the domain of the SDTM standard, as well as the relationship between the business table and the project; and the list is used to store the attribute information and derivation rules of each table header field.

[0011] The SDTM standard table includes a domain table, a variable table, a controlled terminology table, and a version table. The domain table stores the attribute information and derivation rules of each header field. The variable table records the variable information of the SDTM standard. The controlled terminology table records the controlled terms that conform to the standard. The version table records the supported SDTM standard versions and controlled terminology versions.

[0012] Optionally, if the management operation is a data import operation, the standard engine module performs the following steps:

[0013] The standard engine module detects whether the database has created the target project dataset based on the data import operation.

[0014] In the absence of a target project dataset, the standard engine module creates a target project dataset through an organizational workspace;

[0015] When a target project dataset is created, the standard engine module parses each table of the imported medical clinical dataset, determines the corresponding SDTM standard domains and header fields of the table, and inserts the data of each table of the medical clinical dataset into the business table of the target project dataset according to the SDTM standard domains and header fields.

[0016] Optionally, the standard engine module creates a target project dataset through an organizational workspace, including:

[0017] The standard engine module detects whether a target organization workspace has been created based on the data import operation.

[0018] Without creating a target organization workspace, the standard engine module creates a target organization workspace and a system table, and records the metadata of the target organization workspace in the system table;

[0019] When a target organization workspace is available, the standard engine module creates the target project dataset through the target organization workspace.

[0020] Optionally, the standard engine module creates a target project dataset through the target organization's workspace, including:

[0021] The standard engine module queries the domains of the SDTM standard based on the domain table, generates a business table for each domain, queries the required fields of the domain based on the variable table, and initializes the business table.

[0022] The standard engine module records the relationship between the business table and the target project dataset in the relationship table, records the header fields of the business table in the list, and records the metadata of the business table and the metadata of the target project dataset in the project table.

[0023] Optionally, if the management operation is a data export operation, the standard engine module performs the following steps:

[0024] The standard engine module queries the relation table based on the data export operation to determine the names of all non-empty business tables in the current project dataset, and constructs business tables by combining the metadata of the business tables in the project table.

[0025] The standard engine module queries the data rows in the business table and writes them in batches to a target format file for export.

[0026] Optionally, if the management operation is a data editing operation, the standard engine module performs the following steps:

[0027] The standard engine module determines the target business table based on the data editing operation;

[0028] The standard engine module performs data editing operations based on the target business table. The data editing operations include data row operations and header field operations. The data row operations include data row creation, data row addition, data row deletion, data row update, and data row query. The header field operations include header field creation, header field row addition, header field deletion, header field update, and header field query.

[0029] Optionally, the business logic layer further includes an intelligent question-answering module, and the client module includes an intelligent question-answering area;

[0030] The client module receives user field mapping query operations or user data query operations through the intelligent question and answer area;

[0031] In response to the field mapping query operation, the intelligent question-answering module generates a field mapping relationship between non-standard medical clinical data fields and SDTM standard fields, and feeds back the field mapping relationship to the intelligent question-answering area for display, so that users can perform data import operations based on the client module; or, in response to the data query operation, the intelligent question-answering module generates the data query result and feeds back the data query result to the intelligent question-answering area for display.

[0032] Optionally, the client module includes a navigation window and a data display area;

[0033] The navigation window includes a three-level data table node consisting of an organizational workspace, a project dataset, and a business table.

[0034] The client module responds to the user's click operation on the third-level data table node by displaying the corresponding table data in the data display area.

[0035] Optionally, the client module records the current data editing operation;

[0036] Upon a user's request to resume the data editing operation, the business table is restored according to the current data editing operation.

[0037] The embodiments of this application have the following advantages:

[0038] The SDTM-based medical clinical data management system in this embodiment adopts a multi-layered architecture, providing complete system functionality through the collaborative work of multiple layers. The system includes a client module in the presentation layer, a standard engine module in the business logic layer, and a database in the data layer. The client module serves as the user interface, receiving user management operations, including data import, data export, and data editing. The standard engine module responds to these management operations and executes management operations on the medical clinical data according to a standard data model. The database includes system tables and project datasets composed of one or more business tables. The system tables store metadata and global configuration information, while the business tables store the medical clinical data for the corresponding project.

[0039] Thus, following the hierarchical logic of the SDTM standard, this system achieves end-to-end control of medical clinical data from organizational management to subject data through core objects such as organizational workspaces, project datasets, business tables, data rows, and table header fields. Furthermore, the standard data model is built upon the SDTM standard, ensuring that data formats and field definitions conform to SDTM specifications, resolving data format inconsistencies between medical institutions, and thereby improving the compatibility and exchange efficiency of multi-center research data. In addition, each database in the data layer corresponds to a storage unit for an organization. This organizationally isolated database design satisfies data ownership management requirements while ensuring data consistency through unified metadata management via system tables. Therefore, this system enables efficient medical clinical data management, supporting the collection, standardization, storage, and analysis of medical clinical data. It also facilitates seamless data standard integration and efficient collaboration between pharmaceutical companies, hospitals, and drug review agencies, thereby improving the scientific rigor and data utilization efficiency of the entire clinical research process. Attached Figure Description

[0040] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 This is a schematic diagram of a medical clinical data management system based on the SDTM standard provided in an embodiment of this application;

[0042] Figure 2 This is a database architecture diagram provided in an embodiment of this application;

[0043] Figure 3 This is a flowchart illustrating a data import operation provided in an embodiment of this application;

[0044] Figure 4 This is a schematic diagram illustrating the creation process of an organizational workspace provided in an embodiment of this application;

[0045] Figure 5 This is a schematic diagram illustrating the creation process of a project dataset provided in an embodiment of this application;

[0046] Figure 6 This is a schematic diagram of a data export process provided in an embodiment of this application;

[0047] Figure 7 This is a schematic diagram of the functional modules of a medical clinical data management system based on the SDTM standard provided in an embodiment of this application. Detailed Implementation

[0048] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0049] To better understand the technical solution of this application, the technical concepts involved in this application will be explained.

[0050] The Study Data Table Model (SDTM) standard aims to address issues such as inconsistent formats across different data sources, confusing variable naming, and unclear data interpretation, providing a unified structured framework for the submission and review of medical clinical data. Its core design is a "tall, thin" data architecture, where each observation unit (such as a participant's visit record) is stored in an independent row, with logical connections achieved through domain classification. This design overcomes the limitations of traditional horizontal table structures, enabling the standardized expression of complex event sequences such as tumor measurements (TR domain) and efficacy assessments (RS domain), and ensuring data interpretability, traceability, and reusability through strict data governance rules. The core elements of SDTM can be summarized in the following three aspects:

[0051] 1) Domains and Observation Classes: SDTM divides medical clinical data into multiple logical units (domains) based on themes. Each domain corresponds to a data table containing multiple variables. For example, demographic data is stored in the DM (Demographics) domain, recording information such as the subject's ID, age, gender, and ethnicity; adverse event data is stored in the AE (Adverse Events) domain, recording information such as the description of adverse reactions, onset time, severity, and whether they are life-threatening. The domain design is based on the concept of observation classes, mainly including three general observation classes: event-based, intervention-based, and discovery-based, as well as special purpose-based and trial design-based observations.

[0052] 2) Variable Roles and Data Governance Rules: SDTM assigns clear role attributes to each variable in the domain table to standardize its purpose and logical relationships. These include: identifier variables, used to uniquely identify studies, subjects, or observation records; subject variables, used to describe the core attributes of the observation content, such as the event name in the AE domain; time variables, used to record the time point of event occurrence or evaluation; rule variables, defining the data derivation logic, such as the generation rule for the BMI (Body Mass Index) field being weight (kg) divided by the square of height (m); and modifier variables, used to refine, supplement, or restrict the meaning of other variables.

[0053] SDTM ensures data quality through data governance rules. For example, missing data must be clearly marked as "null" or "not applicable" to avoid ambiguity caused by default values; time variables must conform to the ISO 8601 format (ISO 8601 refers to the representation of dates and times for data storage and exchange forms), and logical consistency must be verified through cross-validation (e.g., the subject's date of birth must not be later than the trial enrollment date).

[0054] 3) Version compatibility and extension mechanism: The SDTM standard continuously optimizes the data structure of the SDTM standard dataset through version iterations (such as 1.0, 2.0, 2.1). Taking SDTM 2.1 as an example, it added a "Medical Device Domain" to support clinical trials of medical devices, while deprecating the "Comment Domain" in earlier versions. To address the personalized needs of research, SDTM allows users to add custom variables through "Supplementary Domains," but strict naming conventions must be followed and metadata descriptions must be provided upon submission.

[0055] The SDTM standard, as a clinical data standard, is widely used in the data processing, submission, and analysis processes of pharmaceutical companies, hospitals, and regulatory agencies. However, due to the lack of uniformity in data formats and standards within hospitals and research institutions, data mapping and transformation processes are complex, manual processing is costly, and prone to errors. Therefore, there is an urgent need for a medical clinical data management system to effectively reduce the difficulty of data standardization, improve data consistency, and help clinical researchers efficiently manage SDTM datasets.

[0056] This application provides a medical clinical data management system based on the SDTM standard, which can be used for collaborative scenarios involving pharmaceutical companies, hospitals, and drug review agencies, covering the entire lifecycle management from clinical data collection to standardized dataset submission.

[0057] Reference Figure 1 As shown, Figure 1 This is a schematic diagram of a medical clinical data management system based on the SDTM standard provided in an embodiment of this application. Figure 1As shown, the system includes a client module in the presentation layer, a standard engine module in the business logic layer, and a database in the data layer. Each database represents a storage unit for an organization, wherein:

[0058] The client module serves as the user's interface, used to receive user management operations, including data import, data export, and data editing.

[0059] The standard engine module responds to the management operation and performs management operations on medical clinical data according to the standard data model, which is built based on the SDTM standard and includes organizational workspaces, project datasets, business tables, data rows, and table header fields.

[0060] The database includes system tables and project datasets consisting of one or more business tables. The system tables are used to store metadata and global configuration information, and the business tables are used to store medical clinical data under the corresponding projects.

[0061] In this embodiment, the system is divided into three layers, from top to bottom: the presentation layer, the business logic layer, and the data layer. The presentation layer serves as the medium for interaction with the system, displaying data to users, performing management operations, and providing visual management capabilities. Users can include groups such as hospital users, pharmaceutical company users, and drug review users. Specifically, the client module in the presentation layer provides interfaces for data import, data export, and data editing operations to receive user management operations. For example, when a user needs to export data (i.e., perform a data import operation), the entered medical clinical data is first transmitted through the client module of the presentation layer to the standard engine module of the business logic layer for logical processing. The processed data is then transmitted to the data bureau of the storage layer for persistent storage.

[0062] The business logic layer encapsulates core business logic through a standard engine module, shielding users from the details of SDTM standard processing. It abstracts five core objects: workspace, project dataset, business table, data row, and table header field, providing basic operations on these five core objects and interacting with the database layer to complete the management of medical clinical data.

[0063] The basic operations include workspace management (creating, querying, modifying metadata, and importing datasets), project dataset management (creating, querying, deleting, modifying metadata, importing, and exporting datasets), business table management (creating, querying, modifying metadata, and deleting business tables), data row management (creating, adding, querying, modifying, and deleting data rows), and header field management (adding, deleting, querying, and modifying header fields). This allows for the creation of independent databases (organizational workspaces) for different organizations (e.g., hospitals), the creation of new project datasets within the current database, the initialization of business tables, and the addition of fields and insertion of rows within existing business tables. Based on these basic operations, complex management operations can be implemented; for example, data import operations can be completed by creating workspaces, creating project datasets, adding fields, and inserting row records within an organization.

[0064] The data layer is primarily responsible for storing all medical clinical data (subject data). In this embodiment, to meet the core needs of multi-organizational collaboration and data standardization, the data layer adopts a database sharding strategy, achieving physical isolation and logically unified management of data through a hierarchical database architecture. For example, such as... Figure 2 As shown, Figure 2 This is a database architecture diagram provided in an embodiment of this application. Each organization has an independent organizational workspace, corresponding to an independent database, avoiding data mixing across organizations. Each database is internally divided into system tables and one or more project datasets. Each project dataset includes one or more business tables. In other words, different projects within the same organization share the same database.

[0065] The database is built according to the SDTM standard. Medical clinical data is stored in the business tables of the corresponding project datasets according to the SDTM standard specifications. The database records metadata (e.g., project dataset metadata) and global configuration information (e.g., the project dataset to which the business table belongs) through system tables.

[0066] Understandably, both the client module and the standard engine module are built on a standard data model, and the client module's functionality is deeply coupled with that of the standard engine module, enabling full lifecycle management of medical clinical data. For example, when an organizational workspace needs to be created, the client module calls the standard engine module's "Create Organizational Workspace" interface, passing in the database connection information and the organizational workspace name filled in by the user; when the user creates project data in the current organizational workspace, the client module calls the standard engine module's "Create Project Dataset" interface to perform the project dataset creation operation.

[0067] The technical solution adopted in this application provides complete system functionality through multi-layered collaborative work. This system follows the layered logic of the SDTM standard, achieving end-to-end control of medical clinical data from organizational management to subjects through core objects such as organizational workspaces, project datasets, business tables, data rows, and table header fields. Furthermore, the standard data model is built based on the SDTM standard, ensuring that data formats and field definitions conform to SDTM specifications, resolving the issue of inconsistent data formats among medical institutions, and thus improving the compatibility and exchange efficiency of multi-center research data. In addition, each database in the data layer corresponds to a storage unit of an organization. This database design, isolated by organization, not only meets the needs of data ownership management but also ensures data consistency through unified management of metadata via system tables. Therefore, this system achieves efficient medical clinical data management to support the collection, standardization, storage, and analysis of medical clinical data. Furthermore, this system enables seamless connection and efficient collaboration of data standards among pharmaceutical companies, hospitals, and drug review agencies, thereby improving the scientific rigor and data utilization efficiency of the entire clinical research process.

[0068] In one optional embodiment, the system table includes a project-related table and an SDTM standard table;

[0069] The project-related tables include a project table, a relationship table, and a list; wherein, the project table is used to record the attribute information of the organization's work area, project dataset, and business table; the relationship table is used to record the mapping relationship between the business table and the domain of the SDTM standard, as well as the relationship between the business table and the project; and the list is used to store the attribute information and derivation rules of each table header field.

[0070] The SDTM standard table includes a domain table, a variable table, a controlled terminology table, and a version table. The domain table stores the attribute information and derivation rules of each header field. The variable table records the variable information of the SDTM standard. The controlled terminology table records the controlled terms that conform to the standard. The version table records the supported SDTM standard versions and controlled terminology versions.

[0071] In this embodiment, the system table can be understood as the cornerstone of data operations implemented by the standard engine module. The system table design balances metadata integrity and scalability. The project table, as a global metadata registry, uniformly manages the attribute information of three types of objects: organizational workspaces, project datasets, and business tables, thereby simplifying cross-table query logic. Specifically, the core fields of the project table are shown in Table 1, where JSON refers to a lightweight data exchange format, varchar refers to a variable-length string data type, and int refers to an integer type.

[0072] Table 1. Schematic diagram of the project table structure

[0073]

[0074] The relational table supports the integrity verification of exported medical clinical data by recording the mapping relationship between business tables and domains in the SDTM standard, as well as the relationship between business tables and projects. Specifically, the core fields of the relational table are shown in Table 2. Taking the AE domain table of a certain project as an example, its records contain dataset=research1, table_type=AE, and is_empty=0, indicating that the table is non-empty and must be included in the exported SDTM dataset. Through dynamic updates of the is_empty field, such as marking it as 1 after all data in the table is deleted, the system can automatically filter empty tables and reduce invalid data redundancy.

[0075] Table 2. Relationship Table Structure Diagram

[0076]

[0077] The list serves as the core of the field-level metadata storage, storing attribute information and derivation rules for each table header field. As shown in Table 3, the list fields include full names in Chinese and English, controlled term codes, variable descriptions, and derivation rules. When a user extends a custom field, the system inserts a new record into this table and checks for field name conflicts; the "text" field indicates the text type.

[0078] Table 3. List Structure Diagram

[0079]

[0080] The domain table is used to store the attribute information and derivation rules of each header field, including domain abbreviation, full name in Chinese and English, key variables of the domain, etc., as shown in Table 4. When a Dataset is created, the system queries this table to obtain all SDTM domains and creates a database table for each standard domain and its supplementary domain to store the subject data.

[0081] Table 4. Schematic diagram of the domain table structure

[0082]

[0083] The variable table records variable information for the SDTM standard, including the domain to which the variable belongs, its core level, controlled terms, and its full Chinese and English names, as shown in Table 5. When the system creates a database table (business table) for each domain, it queries the table based on the domain field and core level field to obtain the list of required fields for the domain, thereby initializing the database table.

[0084] Table 5. Schematic diagram of the variable table structure

[0085]

[0086] The controlled terminology list records controlled terms that conform to standards, specifically information on all controlled terms that comply with CDISC (Clinical Data Interchange Standards Consortium) standards. Fields in the controlled terminology list include term code, term group code, Chinese and English submission values, and Chinese and English synonyms, as shown in Table 6. The term group name field is associated with the controlled term group name in the variable table, representing the controlled term group used by the variable, thus constraining the variable's value. NCI refers to the National Cancer Institute.

[0087] Table 6. Schematic diagram of the controlled terminology list

[0088]

[0089] The version table records the supported SDTM standard versions and controlled terminology versions, as shown in Table 7. For example, if the system supports SDTM 2.1 and SDTM 2.0, the version will contain two records: type=SDTM, version=2.1 and type=SDTM, version=2.0, thus achieving multi-version standard compatibility of the system.

[0090] Table 7. Version Table Structure Diagram

[0091]

[0092] In this embodiment, database data consistency is achieved through system-related tables (i.e., project tables, relationship tables, and lists). The dataset field of the relationship table is linked to the project name of the project table via a foreign key, ensuring that each business table belongs to a valid project dataset. The table name field of the list is further linked to the relationship table, forming a hierarchical dependency of "project dataset → business table → table header field". Furthermore, the system-related tables prevent the existence of isolated tables or fields, ensuring the integrity of the data structure. During data import operations, the standard engine module guarantees the atomicity of the operation through system-related tables. For example, when inserting 1000 data rows into the DM table, if an exception occurs midway, the system automatically rolls back to the data before the import, avoiding partial write errors.

[0093] Multi-version standard compatibility is achieved through SDTM standard tables (i.e., domain tables, variable tables, controlled terminology tables, and version tables). The version tables store the SDTM and controlled terminology versions supported by the system. For multiple versions of SDTM and controlled terminology standards supported by the system, there are multiple versions of the domain tables, variable tables, and controlled terminology tables; for example, domain table_2.1 and domain table_2.0. When a user creates an organizational workspace, the system creates and initializes tables from the corresponding domain tables and variable tables based on the selected version.

[0094] In one alternative embodiment, such as Figure 3 As shown, Figure 3 This is a flowchart illustrating a data import operation provided in an embodiment of this application. When the management operation is a data import operation, the standard engine module executes the following steps S1 to S3:

[0095] Step S1: The standard engine module detects whether the database has created the target project dataset based on the data import operation.

[0096] Step S2: In the absence of a target project dataset, the standard engine module creates a target project dataset through the organization workspace.

[0097] Step S3: If a target project dataset has been created, the standard engine module parses each table of the imported medical clinical dataset, determines the corresponding SDTM standard domains and header fields of the table, and inserts the data of each table of the medical clinical dataset into the business table of the target project dataset according to the SDTM standard domains and header fields.

[0098] In this embodiment, different organizational structures correspond to different organizational workspaces (i.e., databases), and medical clinical datasets for different projects are stored in the corresponding project datasets under the organizational workspace. When the standard engine module performs the data import operation, it first executes step S1 to check whether the target project dataset has been created in the database. If no target project dataset has been created, it executes step S2; if a target project dataset has been created, it directly executes step S3.

[0099] Specifically, in step S1, the database can be checked to see if a target project dataset has been created by querying the attribute information of the project dataset recorded in the project table. In step S2, to ensure system security, the target project dataset can only be created by the upper-level target organization's workspace. The detailed creation process will be explained in detail below and will not be repeated here.

[0100] In step S3, the medical clinical dataset imported by the user includes data recorded in one or more tables. Each table is parsed to determine the corresponding SDTM standard fields and header fields. Specifically, based on the SDTM standard fields and header fields, the data from each table of the medical clinical dataset is inserted into the business table of the target project dataset. This includes adding non-required fields using the "Add Header Field" operation in the business table, thus establishing the correspondence between the business table structure and the table structure of the medical clinical dataset (i.e., the mapping relationship between medical clinical data fields and SDTM standard fields). Finally, based on this correspondence, the data from the tables is imported into the medical clinical dataset using the batch insert row operation in the business table, storing the medical clinical dataset in the corresponding project dataset's business table according to the SDTM standard specifications.

[0101] Furthermore, step S2 may specifically include steps S21 to S23:

[0102] Step S21: The standard engine module detects whether a target organization workspace has been created based on the data import operation.

[0103] Step S22: If no target organization workspace is created, the standard engine module creates the target organization workspace and system table, and records the metadata of the target organization workspace in the system table.

[0104] Step S23: If a target organization workspace has been created, the standard engine module creates a project dataset through the target organization workspace.

[0105] In this embodiment of the application, in order to ensure the security of the system, the target project dataset can only be created by the upper-level target organization workspace. When it is necessary to create a target database, step S21 is executed first to check whether a target organization workspace has been created. If no target organization workspace has been created, step S22 is executed first to create the corresponding target organization workspace, and then step S23 is executed. If it is detected that a target organization workspace has been created, step S23 can be executed to create the project dataset through the target organization workspace.

[0106] Specifically, such as Figure 4 As shown, Figure 4 This is a schematic diagram of the creation process of an organization workspace provided in an embodiment of this application. In step S21, database connection information can be added, that is, the attribute information of the organization workspace recorded in the project table can be queried to detect whether a target organization workspace has been created (i.e., the initialization work of the target organization workspace).

[0107] In step S22, the initialization work required for creating workspaces for different target organizations may vary. For example, considering the different SQL (Structured Query Language) scripts used to create tables, a factory pattern can be used to uniformly create workspaces for various organizations. Simultaneously, the interface design for each organization's workspace needs to consider the necessary basic functionalities, such as creating project datasets, deleting project datasets by name, retrieving a list of project datasets, and obtaining metadata information for the organization's workspace, to support the creation of workspaces for organizations with multiple database types.

[0108] In step S23, as Figure 5 As shown ( Figure 5 This is a schematic diagram of a project dataset creation process provided in an embodiment of this application. The standard engine module creates the project dataset through the target organization's workspace, including: the standard engine module queries the domains of the SDTM standard based on the domain table and generates a business table for each domain; and queries the required fields of the domains based on the variable table and initializes the business tables; the standard engine module records the relationship between the business tables and the target project dataset in the relationship table, records the header fields of the business tables in the list, and records the metadata of the business tables and the metadata of the target project dataset in the project table.

[0109] In this way, a project dataset is created through the target organization's workspace, and the attribute information of the target project dataset (e.g., header fields, metadata, etc.) is recorded in a system table. This ensures system security and enables unified management of the project dataset based on the system table in the organization's workspace.

[0110] In one alternative embodiment, such as Figure 6 As shown, Figure 6 This is a schematic diagram of a data export process provided in an embodiment of this application. When the management operation is a data export operation, the standard engine module performs the following steps A1 to A2:

[0111] Step A1: The standard engine module queries the relation table based on the data export operation to determine the names of all non-empty business tables in the current project dataset, and constructs business tables by combining the metadata of the business tables in the project table.

[0112] Step A2: The standard engine module queries the data rows in the business table and writes them in batches to the target format file for export.

[0113] In this embodiment of the application, the relation table records the attribute information of each project dataset and the attribute information of each business table in the project dataset (e.g., the name of the business table). Therefore, when performing data export operations, the name of the corresponding non-empty business table (i.e., the business table that records medical clinical data) can be queried based on the relation table, and the metadata of the business table is recorded in the project table. Then, based on the non-empty business table and the metadata of the business table, the corresponding business table can be determined.

[0114] The standard engine module queries data rows in the business table, which can be understood as writing the corresponding query data to a target format file through paginated row queries in the business table. The target format file can be an Excel file (a spreadsheet software) or an XML (Extensible Markup Language) file.

[0115] In this way, the standard engine module responds to data export operations and implements data export functionality based on basic operations such as data business table query, data row query, and data writing.

[0116] In an optional embodiment, when the management operation is a data editing operation, the standard engine module performs the following steps D1 to D2:

[0117] Step D1: The standard engine module determines the target business table based on the data editing operation.

[0118] Step D2: The standard engine module performs data editing operations based on the target business table. The data editing operations include data row operations and header field operations. The data row operations include data row creation, data row addition, data row deletion, data row update, and data row query. The header field operations include header field creation, header field row addition, header field deletion, header field update, and header field query.

[0119] In this embodiment, to ensure system security, the business table can only be created from the upper-level project dataset, and the data rows and header fields can only be created from the upper-level business table object. The business table is mainly responsible for the full lifecycle management of the data rows and header fields, including object creation, addition, deletion, update, and query operations. When performing data editing operations, the corresponding target business table is first determined, and then the target business table performs data editing operations on the data rows and / or header fields.

[0120] Specifically, when adding header field rows (i.e., adding derived variables), a query list is used to check for naming conflicts between header field names and existing fields. Simultaneously, derivation rules are configured for the derived variables to obtain their expressions and values. Syntax error detection is then performed based on the expressions and values. If syntax errors are found, the derivation rules are reconfigured; otherwise, the value of the derived variable is calculated using the expression engine. When adding data rows, the expression engine generates values ​​for all derived variables before inserting them into the business table. When deleting data rows, it is necessary to check whether the corresponding field is a required field in the SDTM standard.

[0121] In this way, by performing data row operations and header field operations on the target business table, the data editing operation can be achieved.

[0122] In one optional embodiment, the client module includes a navigation window and a data display area; wherein, the navigation window includes a three-level data table node consisting of an organizational workspace, a project dataset, and a business table; the client module responds to the user's click operation on the three-level data table node by displaying the corresponding table data in the data display area.

[0123] In this embodiment, after creating the organizational workspace, project dataset, and business tables, a three-level navigation window consisting of the organizational workspace, project dataset, and business tables can be formed, allowing users to clearly view the current project structure. When a user clicks on a data table node, the corresponding table data is displayed in the data display area of ​​the client module.

[0124] In one optional embodiment, the client module records the current data editing operation; upon a user's request to restore the data editing operation, the business table is restored according to the current data editing operation.

[0125] In this embodiment of the application, in order to reduce database pressure and system design difficulty, the data editing operations of users in the client module will not directly affect the data in the database. The client module will record the current data editing operations (e.g., changing data rows). When the user needs to restore (or undo) the data editing operations, the business table can be restored according to the current data editing operations, thereby maintaining the correctness of the business table.

[0126] In one optional embodiment, the business logic layer further includes an intelligent question-answering module, and the client module includes an intelligent question-answering area;

[0127] The client module receives user field mapping query operations or user data query operations through the intelligent question and answer area;

[0128] In response to the field mapping query operation, the intelligent question-answering module generates a field mapping relationship between non-standard medical clinical data fields and SDTM standard fields, and feeds back the field mapping relationship to the intelligent question-answering area for display, so that users can perform data import operations based on the client module; or, in response to the data query operation, the intelligent question-answering module generates the data query result and feeds back the data query result to the intelligent question-answering area for display.

[0129] In this embodiment, the client module includes an intelligent question-and-answer area, enabling the intelligent question-and-answer module's functionality to be used by the user. Within the intelligent question-and-answer area, user questions and AI (Artificial Intelligence) answers from the intelligent question-and-answer module are differentiated; for example, user questions are aligned to the right of the intelligent question-and-answer area, while AI answers are aligned to the left.

[0130] The intelligent question-answering module leverages the learning and reasoning capabilities of large-scale models to provide functions such as field mapping and data search, and displays the answers to users through the client module. Specifically, the field mapping capability of the intelligent question-answering module can map non-standard collected fields to SDTM standard fields during data import operations, thereby reducing the complexity of data entry. The data search function allows users to search for relevant database data using natural language, bringing convenience to users in querying data.

[0131] like Figure 7 As shown, Figure 7 This diagram illustrates the functional modules of a medical clinical data management system based on the SDTM standard, as provided in this application embodiment. The system includes three functional modules: a client module, a standard engine module, and an intelligent question-and-answer module. The standard engine module supports organizational workspace management, project dataset management, business table management, data row management, and header field management. The client module supports data import, data export, and data editing functions. The intelligent question-and-answer module supports field mapping and data query functions.

[0132] Through the above implementation process, a complete system function is provided through multi-level collaborative work. The system follows the hierarchical logic of the SDTM standard, and through core objects such as organizational workspaces, project datasets, business tables, data rows, and table header fields, it achieves end-to-end control of medical clinical data from organizational management to subjects. Furthermore, the medical clinical data in the database is stored in the business tables of the corresponding project datasets according to the SDTM standard specifications, achieving standardized data management. In addition, through the large model and the SDTM standard domain knowledge base, non-standard fields can be mapped to SDTM standard fields, thereby reducing the complexity of data entry.

[0133] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0134] This application describes embodiments of methods, apparatus, and systems according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0135] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0136] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0137] The above provides a detailed description of a medical clinical data management system based on the SDTM standard provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A medical clinical data management system based on the SDTM standard, characterized in that, This includes a client module located in the presentation layer, a standard engine module located in the business logic layer, and a database located in the data layer. Each database represents a storage unit for an organization, wherein: The client module serves as the user's interface, used to receive user management operations, including data import, data export, and data editing operations. The standard engine module responds to the management operation and performs management operations on medical clinical data according to the standard data model, which is built based on the Research Data Table Model (SDTM) standard and includes organizational workspaces, project datasets, business tables, data rows, and table header fields. The database includes system tables and project datasets consisting of one or more business tables. The system tables are used to store metadata and global configuration information, and the business tables are used to store medical clinical data under the corresponding projects. The system tables include project-related tables and SDTM standard tables; The project-related tables include a project table, a relationship table, and a list; wherein, the project table is used to record the attribute information of the organization's work area, project dataset, and business table; the relationship table is used to record the mapping relationship between the business table and the domain of the SDTM standard, as well as the relationship between the business table and the project; and the list is used to store the attribute information and derivation rules of each table header field. The SDTM standard table includes a domain table, a variable table, a controlled terminology table, and a version table. The domain table stores the attribute information and derivation rules of each header field. The variable table records the variable information of the SDTM standard. The controlled terminology table records the controlled terms that conform to the standard. The version table records the supported SDTM standard versions and controlled terminology versions.

2. The medical clinical data management system based on the SDTM standard according to claim 1, characterized in that, When the management operation is a data import operation, the standard engine module performs the following steps: The standard engine module detects whether the database has created the target project dataset based on the data import operation. In the absence of a target project dataset, the standard engine module creates a target project dataset through an organizational workspace; When a target project dataset is created, the standard engine module parses each table of the imported medical clinical dataset, determines the corresponding SDTM standard domains and header fields of the table, and inserts the data of each table of the medical clinical dataset into the business table of the target project dataset according to the SDTM standard domains and header fields.

3. The medical clinical data management system based on the SDTM standard according to claim 2, characterized in that, The standard engine module creates the target project dataset through the organization's workspace, including: The standard engine module detects whether a target organization workspace has been created based on the data import operation. Without creating a target organization workspace, the standard engine module creates a target organization workspace and a system table, and records the metadata of the target organization workspace in the system table; When a target organization workspace is available, the standard engine module creates the target project dataset through the target organization workspace.

4. The medical clinical data management system based on the SDTM standard according to claim 3, characterized in that, The standard engine module creates a target project dataset through the target organization's workspace, including: The standard engine module queries the domains of the SDTM standard based on the domain table, generates a business table for each domain, queries the required fields of the domain based on the variable table, and initializes the business table. The standard engine module records the relationship between the business table and the target project dataset in the relationship table, records the header fields of the business table in the list, and records the metadata of the business table and the metadata of the target project dataset in the project table.

5. The medical clinical data management system based on the SDTM standard according to claim 1, characterized in that, When the management operation is a data export operation, the standard engine module performs the following steps: The standard engine module queries the relation table based on the data export operation to determine the names of all non-empty business tables in the current project dataset, and constructs business tables by combining the metadata of the business tables in the project table. The standard engine module queries the data rows in the business table and writes them in batches to a target format file for export.

6. The medical clinical data management system based on the SDTM standard according to claim 1, characterized in that, When the management operation is a data editing operation, the standard engine module performs the following steps: The standard engine module determines the target business table based on the data editing operation; The standard engine module performs data editing operations based on the target business table. The data editing operations include data row operations and header field operations. The data row operations include data row creation, data row addition, data row deletion, data row update, and data row query. The header field operations include header field creation, header field row addition, header field deletion, header field update, and header field query.

7. The medical clinical data management system based on the SDTM standard according to claim 1, characterized in that, The business logic layer also includes an intelligent question-and-answer module, and the client module includes an intelligent question-and-answer area; The client module receives user field mapping query operations or user data query operations through the intelligent question and answer area; In response to the field mapping query operation, the intelligent question-answering module generates a field mapping relationship between non-standard medical clinical data fields and SDTM standard fields, and feeds back the field mapping relationship to the intelligent question-answering area for display, so that users can perform data import operations based on the client module; or, in response to the data query operation, the intelligent question-answering module generates data query results and feeds back the data query results to the intelligent question-answering area for display.

8. The medical clinical data management system based on the SDTM standard according to any one of claims 1-7, characterized in that, The client module includes a navigation window and a data display area; The navigation window includes a three-level data table node consisting of an organizational workspace, a project dataset, and a business table. The client module responds to the user's click operation on the third-level data table node by displaying the corresponding table data in the data display area.

9. The medical clinical data management system based on the SDTM standard according to any one of claims 1-7, characterized in that, The client module records the current data editing operations; Upon a user's request to resume the data editing operation, the business table is restored according to the current data editing operation.

Images