Method and system for constructing multi-layer data semantic architecture based on ontology and cross-concept set

Abstract

This application discloses a method and system for constructing a multi-layered data semantic architecture based on Ontology and cross-cutting concept sets. The method consists of two phases: construction and execution. In the construction phase, object types and underlying physical data source mapping rules are registered, a cross-layer shared set of cross-cutting concepts is defined, derived attribute formulas, dependencies, and materialization strategies are configured, an analysis queue (Cohort) is defined, and metrics are declaratively configured, forming an Ontology semantic architecture comprising an object layer, a Cohort layer, and a metric layer. In the execution phase, object access requests are received, multi-source identity alignment is completed through entity parsing, a unified object view is assembled, and derived attributes are calculated. Object subsets are filtered according to Cohort conditions, metric aggregation is performed, data quality is verified, and results are returned or preset business actions are triggered. This method can solve problems such as semantic inconsistency in multi-source heterogeneous data integration, improving the flexibility, maintainability, and analytical accuracy of the data architecture.

Description

Technical Field

[0001] This invention relates to the field of multi-source data governance and semantic modeling technology, and in particular to a method and system for constructing a multi-layer data semantic architecture based on Ontology and cross-cutting concept sets. Background Technology

[0002] Currently, with the continuous advancement of industry informatization, multi-source heterogeneous data is accumulating in fields such as healthcare, finance, and government. Taking the healthcare field as a typical scenario, multiple business systems coexist, including Hospital Information System (HIS), Laboratory Information System (LIS), Picture Archiving and Communication System (PACS), Electronic Medical Record System (EMR), and Medical Insurance Settlement System. The data covers various modalities such as structured business records, semi-structured text, and medical images. Each system has significant differences in identification systems, coding standards, table structure design, and field naming rules, which pose challenges to data governance and large-scale analysis and utilization.

[0003] However, the current data semantic architecture construction scheme has the following prominent problems, which seriously restrict the reusability and analysis efficiency of data assets: (1) The modeling unit is not aligned with the business semantics. The existing data warehouse and data platform solutions use physical tables as the basic modeling unit, which is misaligned with the object, relationship and action semantics that naturally exist in the business domain. Each new type of analysis requirement requires the construction of a specialized wide table. As the requirements accumulate, hundreds to thousands of data tables with overlapping semantics and different definitions are formed, which eventually leads to the problem of data set decay. No one dares to delete or maintain the data, and the complexity of the architecture continues to increase. (2) The definition of business concepts lacks unified governance. The same business concept is repeatedly defined inline in places such as attribute derivation logic, analysis queue screening conditions, and indicator calculation rules. When industry standards are iterated (such as ICD coding upgrade), it is necessary to modify them one by one in all reference positions, which is very easy to cause omissions and cause definition drift, and it is impossible to achieve full-link traceability of concept references. (3) The analysis unit is implicitly fixed as a single entity type. The existing solution defaults to using core entities such as patients and customers as the entry point for all analyses, and does not support event-level objects such as consultation, treatment, and examination as independent analysis units. When the correct denominator of the indicator calculation is the event granularity, the system cannot distinguish the analysis unit, resulting in distorted indicator calculation results. (4) Strong coupling between object instances and physical storage. Traditional object modeling solutions either require data to be physically centralized in independent object storage, resulting in irreversible data copies, T+1 real-time delays and high schema evolution costs, or are strongly bound to the underlying physical table structure. When data sources are added or table structures are changed, large-scale table structure migrations are required, resulting in high implementation costs and difficulty in compatibility with the enterprise's existing lake warehouse and data warehouse ecosystem. (5) Irreversible master data merging mechanism. Traditional master data management merges multi-source records into a single golden record through deterministic rules. The differences between the original records are eliminated, and the cost of correcting errors when matching is incorrect is extremely high. Moreover, it cannot meet the data traceability and auditing requirements in compliance-sensitive scenarios such as medical care and finance. Summary of the Invention

[0004] The purpose of this application is to provide a method and system for constructing a multi-layer data semantic architecture based on Ontology and cross-cutting concept sets, which effectively solves problems such as semantic inconsistency, scattered business concept definitions, and limited analysis units in the integration of multi-source heterogeneous data, and improves the flexibility, maintainability and accuracy of the data architecture and analysis results.

[0005] Firstly, this application proposes a method for constructing a multi-layered data semantic architecture based on Ontology and cross-cutting concept sets, including: The construction phase steps are as follows: Register object types and mapping rules from object types to the underlying physical data source; define a cross-cutting concept set, which serves as a semantic resource shared across layers; configure derived attribute formulas and dependencies between derived attributes; configure materialization strategies for derived attributes based on query frequency, data scale, and change frequency; define an analysis queue (Cohort) based on any object type; and declaratively configure indicator definitions to form an Ontology semantic architecture that includes an object layer, a Cohort layer, and an indicator layer. Operational steps: Receive object access requests addressed by object ID; call the entity resolution service to perform multi-source identity alignment and determine the underlying physical record range corresponding to the object instance; assemble the underlying query results into a unified object view as needed according to the mapping rules; calculate the derived attribute values ​​based on the derived attribute formula; filter the qualified object subsets according to the Cohort's filtering conditions; perform index aggregation calculations based on the object subsets and verify the calculation results according to the data quality threshold; return the results that pass the verification, or execute preset business actions when the trigger conditions are met.

[0006] Optionally, the step of registering object types and mapping rules from object types to the underlying physical data source in the construction phase includes: The object type registration module maintains object type metadata, which includes object type identifier, primary key, list of ordinary attributes, list of derived attribute references, relationship link declaration, and executable action declaration. The cross-cutting concept set includes a globally unique name, description, source standard, value range type, member list, responsible entity, maintenance cycle, and version history; the cross-cutting concept set is jointly referenced by the derived attribute judgment of the object layer, the filtering conditions of the Cohort layer, and the calculation logic of the indicator layer; before the version change, all reference points are automatically scanned and the affected downstream objects are marked; All configurations during the build phase are stored in a declarative manner, supporting version control and change auditing.

[0007] Optionally, the step of invoking the entity resolution service to perform multi-source identity alignment includes: Calculate the matching probability for two candidate records from different source systems: ; in To match the set of field indexes, For fields The matching confidence weight satisfies and For fields Value similarity, For record In the field The value on, This is a field value similarity function. For exact matching fields, it uses 0 / 1 to determine the similarity, and for fuzzy matching fields, it uses edit distance or pronunciation similarity to calculate the similarity. When the matching probability is greater than or equal to the preset matching threshold, a bidirectional reversible clustered mapping label is added to the two records without modifying the original record content; when a matching error occurs, the mapping label splitting and tracing are supported.

[0008] Optionally, the step of assembling the underlying query results into a unified object view on demand according to the mapping rules includes: The object service layer does not store object instances independently; upon receiving an access request, it converts the object access request into a query statement that can be executed by the underlying data source according to the mapping rules in the object type registration module. Maintain the hot data caching layer and the cold data federated query path, pull the corresponding physical records from the data lake, data warehouse or source system, assemble them into a unified object view in real time and return them.

[0009] Optionally, the step of calculating the derived attribute value based on the derived attribute formula includes: The derived attributes are abstracted and configured based on multiple upper-level references, domain terminology meanings, or judgment rules that need to trigger business actions; Maintain the dependency graph between derived attributes; automatically select a materialization strategy based on query frequency, computational complexity, and data change frequency. The materialization strategy includes full materialization, incremental materialization, real-time virtual view calculation, and on-demand calculation. During the calculation of derived attributes, the attribute value attribution is determined by referencing the cross-cutting concept set, and the derived attribute value is output.

[0010] Optionally, the step of defining the analysis queue Cohort based on any object type includes: Each Cohort contains a base object type declaration, a set of filtering conditions, optional parameterized variables, and metadata, including name, version, responsible person, and approval status. The base object type can be configured as any registered object type, including patient, visit, treatment, examination, and medical order types. The set of filtering conditions refers to the common attributes, derived attributes, and cross-cutting concept set of the object layer to construct the filtering logic, providing the filtering range of the numerator and denominator for index calculation.

[0011] Optionally, the step of performing index aggregation calculation based on a subset of objects and verifying the calculation results according to a data quality threshold includes: Each indicator definition includes numerator conditions, denominator conditions, output data format, and data quality threshold; based on the filtering range provided by Cohort, it performs aggregation calculations by referencing object attributes and outputs scalar indicator values; When the denominator sample size is insufficient or the data integrity does not meet the data quality threshold, the output of the indicator is automatically suppressed; the output data format includes percentage format, count format and mean format.

[0012] Secondly, this application also proposes a multi-layered data semantic architecture construction system based on Ontology and cross-cutting concept sets, including: The object type registration module is used to register object types and mapping rules from object types to the underlying physical data source, and to maintain object type metadata. The concept set cross-cutting module is used to define cross-cutting concept sets, provide cross-layer shared semantic resources, and perform version management and reference impact analysis; The derived attribute engine is used to configure derived attribute formulas and dependencies, automatically select materialization strategies, and calculate derived attribute values. The object service layer is used to receive object access requests and assemble a unified object view as needed according to mapping rules. The Cohort definition management module is used to define analysis queues based on any object type and maintain the Cohort's filtering logic and metadata. The metrics calculation engine is used to declaratively configure metric definitions, perform metric aggregation calculations, and verify data quality. The entity resolution service performs multi-source identity alignment by adding reversible co-cluster mapping tags to object instances.

[0013] Thirdly, this application also proposes a multi-layer data semantic architecture construction device based on Ontology and cross-cutting concept set, including: a memory, a processor, and a multi-layer data semantic architecture construction program based on Ontology and cross-cutting concept set stored on the memory and executable on the processor. When the multi-layer data semantic architecture construction program based on Ontology and cross-cutting concept set is executed by the processor, it implements the above-mentioned multi-layer data semantic architecture construction method based on Ontology and cross-cutting concept set.

[0014] Fourthly, this application also proposes a computer program product, which includes a multi-layer data semantic architecture construction program based on Ontology and cross-cutting concept set, wherein the multi-layer data semantic architecture construction program based on Ontology and cross-cutting concept set implements the above-mentioned multi-layer data semantic architecture construction method based on Ontology and cross-cutting concept set when executed by a processor.

[0015] Compared with the prior art, this application has the following advantages: This application provides a method and system for constructing a multi-layer data semantic architecture based on Ontology and cross-cutting concept sets. By constructing an Ontology semantic architecture including an object layer, a cohort layer, and an indicator layer, and defining cross-cutting concept sets to achieve cross-layer semantic sharing, combined with a reversible multi-source identity alignment mechanism and a unified object view assembled on demand, business semantics and physical storage are effectively decoupled. It supports any object type as an analysis unit, avoids data duplication and caliber drift, and effectively solves problems such as semantic inconsistency, scattered business concept calibers, and limited analysis units in the integration of multi-source heterogeneous data, thereby improving the flexibility, maintainability, and accuracy of the data architecture and analysis results. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a method for constructing a multi-layer data semantic architecture based on Ontology and cross-cutting concept sets, as provided in an embodiment of this application.

[0017] Figure 2 This is a schematic diagram of a multi-layer data semantic architecture construction system based on Ontology and cross-cutting concept set, provided as an embodiment of this application. Detailed Implementation

[0018] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0019] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0020] Firstly, such as Figure 1 As shown, this application provides a method for constructing a multi-layered data semantic architecture based on Ontology and cross-cutting concept sets, including: Build phase steps; Register object types and mapping rules from object types to the underlying physical data source; Object types can be manually entered into the system and assigned a unique identifier. Then, through the configuration interface, the various attributes of this object type can be associated with the underlying physical data source (such as table fields in a relational database, file paths in a data lake, etc.) in a one-to-one or many-to-one manner. For example, the primary key of the "Patient" object type can be manually specified to correspond to the "patient_id" field in database A, and its "name" attribute can correspond to the "name" field in database B.

[0021] Define a cross-cutting concept set, which serves as a semantic resource shared across layers; Cross-cutting concepts can be created manually and assigned a globally unique name and description. For example, a cross-cutting concept named "Disease Classification" can be defined, and its member list can include coding systems such as "ICD-9" or "ICD-10". This set of concepts is stored in a separate configuration file for reference by other modules later.

[0022] Configure derived attribute formulas and dependencies between derived attributes; Formulas for derived attributes can be entered manually; for example, the formula for the derived attribute "Patient Age" can be defined as "Current Date - Date of Birth". Dependencies between derived attributes can be manually drawn through a graphical interface; for example, the calculation of derived attribute A depends on derived attributes B and C. These formulas and dependencies are stored in a configuration library.

[0023] Configure the materialization strategy of derived attributes based on query frequency, data size, and change frequency; Materialization strategies can be manually selected. For example, for derived attributes with high query frequency, small data size, and low change frequency, the "full materialization" strategy can be manually selected; for derived attributes with low query frequency, large data size, and high change frequency, the "virtual view real-time calculation" strategy can be manually selected.

[0024] Define an analysis queue, Cohort, based on any object type; A Cohort can be created manually, specifying its base object type, such as "patient". Its set of filters can be manually entered, for example, filtering for "patients older than 60 years". These definitions are stored in the Cohort management module.

[0025] Declarative configuration of metrics defines an Ontology semantic architecture that includes an object layer, a cohort layer, and a metric layer. Indicator definitions can be manually entered. For example, an indicator named "proportion of hypertension patients" can be defined, with the numerator condition being "patients with hypertension" and the denominator condition being "all patients". These indicator definitions, together with the definitions of the object layer and the cohort layer, constitute a complete view of the Ontology semantic architecture.

[0026] Operational phase steps; Receive object access requests addressed by object ID; The system received a query request to retrieve detailed information about the patient with ID "P001".

[0027] Call the entity resolution service to perform multi-source identity alignment and determine the range of underlying physical records corresponding to the object instance; The entity resolution service can be configured to identify the same entity from different data sources by matching simple rules (e.g., names and dates of birth must match exactly). When a matching record is identified, the IDs of these records are associated to form a logical cluster.

[0028] Based on the mapping rules, the underlying query results are assembled into a unified object view as needed; The object service layer merges and transforms physical records from different underlying data sources at the field level according to pre-registered mapping rules, forming a unified, business-oriented object view. For example, the "patient_name" field in database A and the "full_name" field in database B are both mapped to the "name" attribute of the object view.

[0029] Calculate the derived attribute value based on the derived attribute formula; The system calculates the values ​​of the derived attributes based on the configured derived attribute formulas for the basic attributes in the unified object view. For example, it calculates the "age" based on the "date of birth".

[0030] Filter the subset of objects that meet the Cohort's filtering criteria; The system matches all object instances in the unified object view against the filtering conditions defined in Cohort, selecting the set of objects that meet the conditions. For example, it filters out all patients "aged over 60 years".

[0031] The calculation of aggregated metrics is performed based on a subset of objects, and the calculation results are verified according to the data quality threshold. The system performs predefined aggregation operations, such as counting, summing, and averaging, on the selected subset of objects to obtain the raw calculation results of the indicators. Then, the results are compared with preset data quality thresholds; for example, if the denominator sample size is below a certain threshold, the calculation results are considered unreliable.

[0032] Return the result of successful verification, or execute a preset business action when the trigger condition is met; If the metric calculation result passes the data quality verification, it is returned to the requester. If the verification fails, or other preset trigger conditions are met (e.g., an abnormal metric value), the system can execute preset business actions, such as sending an alarm notification or initiating a data governance process.

[0033] In some possible embodiments, the step of registering object types and mapping rules from object types to the underlying physical data source in the build phase includes: The object type registration module maintains object type metadata, which includes object type identifier, primary key, list of ordinary attributes, list of derived attribute references, relationship link declaration, and executable action declaration. The cross-cutting concept set includes a globally unique name, description, source standard, value range type, member list, responsible entity, maintenance cycle, and version history; the cross-cutting concept set is jointly referenced by the derived attribute judgment of the object layer, the filtering conditions of the Cohort layer, and the calculation logic of the indicator layer; before the version change, all reference points are automatically scanned and the affected downstream objects are marked; All configurations during the build phase are stored in a declarative manner, supporting version control and change auditing.

[0034] Specifically, object type metadata is a collection that provides a structured description and management of all object types in the system. It provides a comprehensive definition for each object type, ensuring the uniqueness, integrity, and operability of objects within the overall data semantic architecture. By maintaining this metadata, the system can clearly understand the composition of each object type and its behavior at the data layer. Object type metadata specifically includes: an object type identifier, used to uniquely identify an object type, such as "patient" or "visit"; a primary key, defining a unique identification attribute for an object instance, serving as the basis for data association and querying; a list of common attributes, describing attributes inherent to the object type and directly mapped from the underlying data source, such as a patient's name, gender, and date of birth; a list of derived attribute references, listing derived attributes that the object type may possess, derived through calculation or logical inference, such as a patient's age and length of hospital stay; relationship link declarations, defining the relationships between this object type and other object types, such as a one-to-many relationship between "patient" and "visit"; and action declarations, describing business operations or services related to this object type that can be triggered under specific conditions, such as "generate patient report" or "update visit status". This metadata is typically stored in the metadata repository of the object type registration module, which can be a relational database, a NoSQL database, or a dedicated metadata management system. During system runtime, the object service layer queries this metadata to understand and process object access requests.

[0035] Meanwhile, the cross-cutting concept set is a group of business concepts with unified semantics shared across different business domains and data layers. It aims to eliminate differences in understanding the same concept across different systems or departments, providing a standardized semantic foundation to promote semantic consistency across layers and domains. The cross-cutting concept set includes: a globally unique name to ensure the uniqueness of each cross-cutting concept within the entire architecture; a description that details the concept's meaning, scope of application, and business context; a source standard that indicates the concept's source, such as industry standards, national standards, or internal company specifications; a value range type that defines the type and range of possible values ​​the concept can take, such as enumerated values ​​or numerical ranges; a member list that, for enumerated concepts, lists all possible member values; a responsible entity that clarifies the concept's definer and maintainer, ensuring the concept's authority and accuracy; a maintenance cycle that specifies the frequency of review and updates; and a version history that records all changes to the concept, including the content, time, and person making the changes. The cross-cutting concept set is referenced by derived attribute judgments at the object layer, filtering conditions at the Cohort layer, and computational logic at the indicator layer, meaning these concepts play a core and fundamental role in the entire semantic architecture. To ensure the correctness of references, the system automatically scans all reference points before any cross-cutting concept set version change, including derived attribute formulas, cohort filtering conditions, and metric calculation logic, and identifies affected downstream objects. This helps assess the impact of changes and avoids potential semantic breaks or calculation errors. Cross-cutting concept sets can be stored in a dedicated concept management service and made available to all layers via an API. Version management can be implemented through database transactions, content version control systems, or dedicated metadata version management tools.

[0036] Furthermore, all configurations during the build phase, including object type definitions, mapping rules, cross-cutting concepts, derived attribute formulas, cohort definitions, and indicator definitions, are stored declaratively. This means that configuration content describes "what should be" in a structured data format, rather than "how to do it." This storage method improves the readability and maintainability of the configuration. Version control of these declarative configurations means that each configuration modification is recorded as a new version, allowing for easy reverting to historical versions. This is crucial for managing complex semantic architectures, as it allows for team collaboration, parallel development, and rapid recovery in case of problems. A change auditing mechanism records detailed information on all configuration changes, including who modified what and when. This provides a complete operational log, helping to trace the root cause of problems, meet compliance requirements, and enhance system transparency and security. Declarative configurations can be stored in a file system, configuration management database, or version control system. Version control can be implemented by integrating version control tools or utilizing the database's built-in version management functionality. Change auditing is typically achieved by recording configuration change logs, operator identities, and timestamps.

[0037] In some possible embodiments, the step of invoking the entity resolution service to perform multi-source identity alignment includes: Calculate the matching probability for two candidate records from different source systems. By indexing the matching fields Each field in Match it with confidence weights With fields Value similarity The product is obtained by multiplying and then summing. ; in To match the set of field indexes, For fields The matching confidence weight satisfies and For fields Value similarity, For record In the field The value on, This is a field value similarity function. For exact matching fields, it uses 0 / 1 to determine the similarity, and for fuzzy matching fields, it uses edit distance or pronunciation similarity to calculate the similarity. When the matching probability is greater than or equal to the preset matching threshold, a bidirectional reversible clustered mapping label is added to the two records without modifying the original record content; when a matching error occurs, the mapping label splitting and tracing are supported.

[0038] For fields requiring precise matching, such as ID numbers and unique codes, a 0 / 1 distinction is used: 1 for a perfect match and 0 otherwise. For fuzzy matching fields like names and addresses, which may contain spelling errors or different expressions, edit distance (e.g., Levenshtein distance) or pronunciation similarity (e.g., the Soundex algorithm) is used to improve matching robustness. When the calculated matching probability Pmatchra,rb is greater than or equal to a preset matching threshold, the system adds a bidirectional reversible clustered mapping label to the two records. The advantage of this labeling mechanism is that it only establishes a logical association between records without modifying the original record content, thus ensuring the originality and integrity of the underlying data source. Furthermore, the mapping label is "bidirectionally reversible," meaning that once a matching error is detected, the mapping label can be easily split and traced, effectively correcting the error and analyzing its cause, greatly improving the flexibility and accuracy of data governance and maintenance.

[0039] In some possible embodiments, the step of assembling the underlying query results into a unified object view on demand according to mapping rules includes: The object service layer does not store object instances independently; upon receiving an access request, it converts the object access request into a query statement that can be executed by the underlying data source according to the mapping rules in the object type registration module. Maintain the hot data caching layer and the cold data federated query path, pull the corresponding physical records from the data lake, data warehouse or source system, assemble them into a unified object view in real time and return them.

[0040] Specifically, the object service layer does not independently store object instances. This means that this layer primarily serves as an abstraction and coordination layer for data access, rather than an actual data storage layer. Its core function is to provide a unified view of objects without internally copying or persisting object instances from the underlying data source. This design avoids data redundancy, reduces storage costs, and ensures data consistency because all data always originates directly from its original physical storage location. When an object instance needs to be accessed, the object service layer dynamically retrieves the latest data from the underlying data source.

[0041] Upon receiving an access request, the object service layer converts the high-level object access request (e.g., querying all attributes of a specific object) into a query statement that the underlying data source can understand and execute, based on the predefined mapping rules in the object type registration module. For example, a request for a "patient" object might be converted into an SQL query statement targeting multiple tables in a relational database (such as a patient basic information table, a medical record table, and an examination result table), or a query instruction targeting a specific file path in a data lake. This conversion process is dynamic and real-time, ensuring that the request can accurately locate and retrieve the required data.

[0042] To optimize data access performance, this embodiment maintains a hot data caching layer and a cold data federated query path. The hot data caching layer stores frequently accessed or recently updated data to significantly improve the response speed of this data and reduce the pressure of direct access to the underlying data source. For example, it can be implemented using an in-memory database or a distributed caching system. The cold data federated query path, on the other hand, is used to handle historical or archived data that is not frequently accessed but still needs to be queried. It can use federated query technology to uniformly query and integrate scattered data from data lakes, data warehouses, or various source systems without storing all cold data in one place.

[0043] Subsequently, the system retrieves the corresponding physical records from the data lake, data warehouse, or source system based on the transformed query. Data lakes typically store raw, diverse data, data warehouses store cleaned, integrated, and structured data, while source systems are the origin of the raw data for business operations. By interacting with these different types of data sources, the system can obtain all the underlying physical data needed to build a unified object view.

[0044] Finally, the system assembles the retrieved physical records into a unified object view in real time and returns it. This means that the data assembly process is triggered on demand, rather than being pre-calculated and stored. The object service layer integrates, transforms, and structures the scattered physical records retrieved from different sources according to object type definitions and mapping rules, forming a complete and semantic object view that meets the expectations of upper-layer applications. This real-time assembly ensures the timeliness and accuracy of the returned data.

[0045] In some possible embodiments, the step of calculating the derived attribute value based on the derived attribute formula includes: Derived attributes are abstracted and configured based on multiple upper-level references, domain terminology meanings, or judgment rules that need to trigger business actions; Maintain the dependency graph between derived attributes; automatically select materialization strategies based on query frequency, computational complexity, and data change frequency. Materialization strategies include full materialization, incremental materialization, real-time virtual view calculation, and on-demand calculation. During the calculation of derived attributes, the attribute value attribution is determined by referencing the cross-cutting concept set, and the derived attribute value is output.

[0046] Specifically, the abstract configuration of derived attributes aims to encapsulate complex business logic and data transformation rules at a high level. For example, a derived attribute may be referenced by multiple analysis queues (Cohort) or metric definitions, and its calculation result may represent specific domain terms (such as "hypertensive patients" or "hospital stay"), or its value may trigger a preset business action (such as "sending an early warning notification") when it reaches a specific threshold. Through abstract configuration, the system can clearly define the semantics and behaviors of these derived attributes, ensuring consistency in their use across different contexts and providing a foundation for subsequent automated processing.

[0047] To effectively manage the computation order and dependencies between derived attributes, this embodiment maintains a dependency graph of derived attributes. This graph is typically represented as a directed acyclic graph (DAG), where each node represents a derived attribute and edges represent computational dependencies between attributes. When the value of a derived attribute changes, the system can identify all affected downstream attributes based on the dependency graph and recalculate only these affected attributes, thereby avoiding unnecessary full computation and improving computational efficiency.

[0048] To further optimize the computational performance and resource utilization of derived attributes, this embodiment automatically selects an appropriate materialization strategy based on the query frequency, computational complexity, and underlying data change frequency of the derived attributes. For example, for derived attributes with high query frequency, low computational complexity, and infrequent data changes, the system can choose a full materialization strategy, that is, pre-calculate and store all derived attribute values ​​to achieve fast query response. For derived attributes with frequent data changes but limited impact of each change, an incremental materialization strategy can be adopted, recalculating and updating only the changed data. When the query frequency of derived attributes is low, but real-time requirements are high, or the computational complexity is moderate, a virtual view real-time calculation strategy can be adopted, that is, dynamically calculating derived attribute values ​​during queries without pre-storage. For derived attributes with extremely low query frequency, high computational complexity, and uncertain data changes, an on-demand calculation strategy can be adopted, triggering calculation only when needed. This dynamic materialization strategy selection mechanism ensures that the system can flexibly balance computational resource consumption and data query efficiency according to actual operating conditions.

[0049] In the actual calculation of derived attributes, this embodiment uses a cross-cutting concept set to perform attribute value attribution judgment. As a cross-layer shared semantic resource, the cross-cutting concept set provides standardized concept definitions and value ranges. For example, when calculating a derived attribute representing "patient age group," the system can reference the precise ranges of age groups such as "child," "adolescent," "adult," and "elderly" defined in the cross-cutting concept set, ensuring that the judgment logic of derived attribute values ​​remains consistent with globally unified standards, thereby outputting accurate and semantically consistent derived attribute values.

[0050] In some possible embodiments, the step of defining an analysis queue Cohort based on arbitrary object types includes: Each Cohort contains a base object type declaration, a set of filter conditions, optional parameterized variables, and metadata. The metadata includes name, version, responsible person, and approval status. The base object type can be configured as any registered object type, including patient, visit, treatment, examination, and medical order types. The set of filtering conditions references the common attributes, derived attributes, and cross-cutting concept sets of the object layer to construct the filtering logic, providing the filtering range for the numerator and denominator in the indicator calculation.

[0051] Specifically, each analysis cohort is designed as a structured definition, the core of which is to explicitly specify the scope and conditions of the data being analyzed. The base object type declaration clarifies the core entity type that the cohort targets. For example, in the healthcare domain, the base object type could be a registered "patient" object type, or other registered object types such as "visit," "treatment," "examination," or "medical order." This declaration ensures that the context of the cohort analysis is clear, avoids ambiguity, and allows the system to be extended based on existing object models.

[0052] A set of filtering conditions consists of logical rules used to select specific subsets of data from a base object type. These conditions can be constructed with great flexibility. For example, they can reference common attributes at the object level (such as patient age, gender, and diagnosis results), derived attributes (such as calculated length of hospital stay, disease severity score, and readmission risk index), or cross-cutting concept sets (such as standard disease codes, drug classifications, and treatment types) to build complex filtering logic. For instance, a Cohort can be defined to filter patients who are "over 60 years old, have a specific chronic disease, and have received a specific treatment in the past year." These filtering logics are typically composed of logical operators (such as AND, OR, and NOT) and comparison operators (such as greater than, less than, and equal to) to achieve highly refined and semantic filtering of data.

[0053] To enhance the flexibility and reusability of Cohorts, optional parameterized variables can be introduced. These variables allow dynamic parameters to be set in the Cohort definition, such as date ranges (e.g., "patients admitted between [start date] and [end date]"), numerical thresholds (e.g., "patients with oxygen saturation below [threshold]"). By providing different parameter values ​​at runtime, the same Cohort definition can be reused in different scenarios without having to be recreated each time, significantly improving analysis efficiency and definition maintainability.

[0054] In addition, each Cohort contains metadata for managing and governing its definition. Metadata includes: a name, providing an easily understandable identifier; a version, recording the Cohort definition's change history, supporting the retrospective and comparison of analysis results from different versions, ensuring the traceability of the analysis; a responsible party, clearly identifying the creator or maintainer of the Cohort definition for ease of communication and management; and an approval status, reflecting the Cohort definition's lifecycle stage (e.g., draft, pending approval, approved, obsolete), ensuring that only validated and approved Cohorts can be used for formal analysis, thereby guaranteeing data quality and compliance.

[0055] In some possible embodiments, the steps of performing metric aggregation calculations based on a subset of objects and validating the calculation results according to a data quality threshold include: Each indicator definition includes numerator conditions, denominator conditions, output data format, and data quality threshold; based on the filtering range provided by Cohort, it performs aggregation calculations by referencing object attributes and outputs scalar indicator values; When the denominator sample size is insufficient or the data integrity does not meet the data quality threshold, the output of the indicator is automatically suppressed; the output data formats include percentage format, count format and mean format.

[0056] In the indicator definition stage, each indicator has its numerator and denominator conditions explicitly defined. This is particularly crucial for constructing ratio-based indicators, ensuring the clarity and accuracy of the calculation logic. For example, in medical data analysis, the numerator condition for an indicator like "patient cure rate" might be defined as "patients diagnosed with a specific disease and recovered after treatment," while the denominator condition would be "patients diagnosed with a specific disease and receiving treatment." These conditions are typically constructed precisely by referencing object attributes, derived attributes, or cross-cutting sets of concepts. Simultaneously, the indicator definition also includes the output data format to standardize the presentation of the indicator calculation results. For example, percentage formats are suitable for ratio indicators, count formats for statistical quantity indicators, and mean formats for indicators calculating averages. This helps users intuitively understand the meaning of the indicators. More importantly, each indicator definition introduces a data quality threshold, which is a series of preset rules or thresholds used to assess the completeness, accuracy, and consistency of the raw data used in the calculation. For example, an upper limit for the missing rate of key attributes or a minimum value for the denominator sample size can be set to ensure the reliability of the indicator.

[0057] When performing aggregated index calculations, the system first uses the filtering range provided by Cohort to determine the subset of objects to be included in the calculation. Cohort, through its predefined set of filtering conditions, can precisely identify a group of object instances with common characteristics, such as "male patients aged 30-40". Subsequently, the index calculation engine references specific object attributes from these subsets, such as patient age, diagnosis results, and treatment duration, to perform the aggregation operation. Aggregation calculations can encompass various statistical methods, including summation, counting, averaging, maximum, and minimum values, ultimately generating a single, numerical scalar index value.

[0058] To ensure the reliability of the output indicators, this embodiment introduces a mechanism for automatically suppressing indicator output. When the denominator sample size is found to be too small during indicator calculation—for example, when calculating the cure rate, the total number of treated patients is too small, leading to unrepresentative statistical results—or when the data involved in the calculation fails to meet a preset data quality threshold—for example, too many key data fields are missing or there are a large number of outliers—the system will automatically suppress the output of that indicator. This means the system will not directly present the calculation result of the indicator, but may provide a prompt indicating that the indicator is unusable or unreliable due to data quality issues or insufficient sample size, thereby avoiding misleading analysis and decisions caused by incomplete or unreliable data. The output data format settings, including percentage format, count format, and mean format, can flexibly meet the display needs of different types of indicators. For example, the percentage format is suitable for indicators representing proportions or ratios, the count format is suitable for indicators representing quantity or frequency, and the mean format is suitable for indicators representing average levels, further improving the readability and usability of the indicators.

[0059] It should be noted that the above description describes some embodiments of the present invention. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than that shown in the above embodiments and still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0060] Secondly, based on the same inventive concept, corresponding to any of the above-described embodiments, such as... Figure 2 As shown in the embodiments of this application, a multi-layer data semantic architecture construction system based on Ontology and cross-cutting concept sets is also provided, including: The object type registration module 100 is used to register object types and mapping rules from object types to underlying physical data sources, and to maintain object type metadata. Concept set cross-cutting module 200 is used to define cross-cutting concept sets, provide cross-layer shared semantic resources, and perform version management and reference impact analysis; Derived Attribute Engine 300 is used to configure derived attribute formulas and dependencies, automatically select materialization strategies, and calculate derived attribute values. The object service layer 400 is used to receive object access requests and assemble a unified object view as needed according to mapping rules. Cohort defines the management module 500, which is used to define analysis queues based on arbitrary object types and maintain Cohort's filtering logic and metadata; The Metrics Calculation Engine 600 is used for declarative configuration of metric definitions, execution of metric aggregation calculations, and data quality verification. Entity resolution service 700 is used to perform multi-source identity alignment and add reversible co-cluster mapping tags to object instances.

[0061] The system described above is used to implement the corresponding methods in the foregoing embodiments and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0062] Thirdly, based on the same inventive concept, embodiments of this application also provide a multi-layer data semantic architecture construction device based on Ontology and cross-cutting concept set, including: a memory, a processor, and a multi-layer data semantic architecture construction program based on Ontology and cross-cutting concept set stored on the memory and executable on the processor. When the multi-layer data semantic architecture construction program based on Ontology and cross-cutting concept set is executed by the processor, it implements the above-mentioned multi-layer data semantic architecture construction method based on Ontology and cross-cutting concept set.

[0063] Fourthly, based on the same inventive concept, embodiments of this application also provide a computer program product, which includes a multi-layer data semantic architecture construction program based on Ontology and cross-cutting concept set. When the multi-layer data semantic architecture construction program based on Ontology and cross-cutting concept set is executed by a processor, it implements the above-mentioned multi-layer data semantic architecture construction method based on Ontology and cross-cutting concept set.

[0064] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for constructing a multi-layered data semantic architecture based on Ontology and cross-cutting concept sets, characterized in that, include: The construction phase steps are as follows: Register object types and mapping rules from object types to the underlying physical data source; define a cross-cutting concept set, which serves as a semantic resource shared across layers; configure derived attribute formulas and dependencies between derived attributes; configure materialization strategies for derived attributes based on query frequency, data scale, and change frequency; define an analysis queue (Cohort) based on any object type; and declaratively configure indicator definitions to form an Ontology semantic architecture that includes an object layer, a Cohort layer, and an indicator layer. Operational steps: Receive object access requests addressed by object ID; Invoke the entity resolution service to perform multi-source identity alignment and determine the range of underlying physical records corresponding to the object instance; Based on the mapping rules, the underlying query results are assembled into a unified object view as needed; Calculate the derived attribute value based on the derived attribute formula; The system filters out a subset of objects that meet the criteria based on the Cohort's filtering conditions; it then performs aggregated calculations of metrics based on the subset of objects and verifies the calculation results according to the data quality threshold. Returns the result of successful verification, or executes a preset business action when the trigger condition is met.

2. The method for constructing a multi-layer data semantic architecture based on Ontology and cross-cutting concept sets as described in claim 1, characterized in that, The steps in the construction phase, including registering object types and mapping rules from object types to the underlying physical data source, include: The object type registration module maintains object type metadata, which includes object type identifier, primary key, list of ordinary attributes, list of derived attribute references, relationship link declaration, and executable action declaration. The cross-cutting concept set includes a globally unique name, description, source standard, value range type, member list, responsible entity, maintenance cycle, and version history; the cross-cutting concept set is jointly referenced by the derived attribute judgment of the object layer, the filtering conditions of the Cohort layer, and the calculation logic of the indicator layer; before the version change, all reference points are automatically scanned and the affected downstream objects are marked; All configurations during the build phase are stored in a declarative manner, supporting version control and change auditing.

3. The method for constructing a multi-layered data semantic architecture based on Ontology and cross-cutting concept sets as described in claim 1, characterized in that, The step of invoking the entity resolution service to perform multi-source identity alignment includes: Calculate the matching probability for two candidate records from different source systems: ； in To match the set of field indexes, For fields The matching confidence weight satisfies and For fields The similarity of values, For record In the field The value on, This is a field value similarity function. For exact matching fields, it uses 0 / 1 to determine the similarity, and for fuzzy matching fields, it uses edit distance or pronunciation similarity to calculate the similarity. When the matching probability is greater than or equal to the preset matching threshold, a bidirectional reversible clustered mapping label is added to the two records without modifying the original record content; when a matching error occurs, the mapping label splitting and tracing are supported.

4. The method for constructing a multi-layered data semantic architecture based on Ontology and cross-cutting concept sets as described in claim 1, characterized in that, The step of assembling the underlying query results into a unified object view as needed according to the mapping rules includes: The object service layer does not store object instances independently; upon receiving an access request, it converts the object access request into a query statement that can be executed by the underlying data source according to the mapping rules in the object type registration module. Maintain the hot data caching layer and the cold data federated query path, pull the corresponding physical records from the data lake, data warehouse or source system, assemble them into a unified object view in real time and return them.

5. The method for constructing a multi-layered data semantic architecture based on Ontology and cross-cutting concept sets as described in claim 1, characterized in that, The step of calculating the derived attribute value based on the derived attribute formula includes: The derived attributes are abstracted and configured based on multiple upper-level references, domain terminology meanings, or judgment rules that need to trigger business actions; Maintain the dependency graph between derived attributes; automatically select a materialization strategy based on query frequency, computational complexity, and data change frequency. The materialization strategy includes full materialization, incremental materialization, real-time virtual view calculation, and on-demand calculation. During the calculation of derived attributes, the attribute value attribution is determined by referencing the cross-cutting concept set, and the derived attribute value is output.

6. The method for constructing a multi-layered data semantic architecture based on Ontology and cross-cutting concept sets as described in claim 1, characterized in that, The steps for defining the analysis queue Cohort based on any object type include: Each Cohort contains a base object type declaration, a set of filtering conditions, optional parameterized variables, and metadata, including name, version, responsible person, and approval status. The base object type can be configured as any registered object type, including patient, visit, treatment, examination, and medical order types. The set of filtering conditions refers to the common attributes, derived attributes, and cross-cutting concept set of the object layer to construct the filtering logic, providing the filtering range of the numerator and denominator for index calculation.

7. The method for constructing a multi-layered data semantic architecture based on Ontology and cross-cutting concept sets as described in claim 1, characterized in that, The steps of performing aggregated calculations of metrics based on object subsets and verifying the calculation results according to data quality thresholds include: Each indicator definition includes numerator conditions, denominator conditions, output data format, and data quality threshold; based on the filtering range provided by Cohort, it performs aggregation calculations by referencing object attributes and outputs scalar indicator values; When the denominator sample size is insufficient or the data integrity does not meet the data quality threshold, the output of the indicator is automatically suppressed; the output data format includes percentage format, count format and mean format.

8. A multi-layer data semantic architecture construction system based on Ontology and cross-cutting concept sets, applied to the multi-layer data semantic architecture construction method based on Ontology and cross-cutting concept sets as described in any one of claims 1 to 7, characterized in that, include: The object type registration module is used to register object types and mapping rules from object types to the underlying physical data source, and to maintain object type metadata. The concept set cross-cutting module is used to define cross-cutting concept sets, provide cross-layer shared semantic resources, and perform version management and reference impact analysis; The derived attribute engine is used to configure derived attribute formulas and dependencies, automatically select materialization strategies, and calculate derived attribute values. The object service layer is used to receive object access requests and assemble a unified object view as needed according to mapping rules. The Cohort definition management module is used to define analysis queues based on any object type and maintain the Cohort's filtering logic and metadata. The metrics calculation engine is used to declaratively configure metric definitions, perform metric aggregation calculations, and verify data quality. The entity resolution service performs multi-source identity alignment by adding reversible co-cluster mapping tags to object instances.

9. A device for constructing a multi-layered data semantic architecture based on Ontology and cross-cutting concept sets, characterized in that, The device for constructing a multi-layer data semantic architecture based on Ontology and cross-cutting concept sets includes: a memory, a processor, and a multi-layer data semantic architecture construction program based on Ontology and cross-cutting concept sets stored in the memory and executable on the processor. When the multi-layer data semantic architecture construction program based on Ontology and cross-cutting concept sets is executed by the processor, it implements the method for constructing a multi-layer data semantic architecture based on Ontology and cross-cutting concept sets as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a multi-layer data semantic architecture construction program based on Ontology and cross-cutting concept set. When the multi-layer data semantic architecture construction program based on Ontology and cross-cutting concept set is executed by a processor, it implements the multi-layer data semantic architecture construction method based on Ontology and cross-cutting concept set as described in any one of claims 1 to 7.

Images