Method and device for generating data verification rule of shared document, equipment and medium

Abstract

The invention provides a method and a device for generating a data verification rule of a shared document, equipment and a medium. The method comprises the following steps: S1, receiving related configuration of each data node based on an industry specification through a configuration interface; s2, obtaining related configuration of the shared document according to the type of the selected shared document of which the verification rule is to be generated; s3, sorting the node set, arranging non-necessary nodes in the front, and arranging short nodes xpath in the front; s4, creating a related set; and S5, traversing the node set, generating a verification rule of each node, and further generating a data verification rule of the shared document. After configuration based on industry shared document specification requirements, the data verification rules of all the shared documents are automatically generated by analyzing the configuration, and the technical blank of automatically generating the data verification rules of the shared documents is filled.

Description

Technical Field

[0001] The invention relates to a method, device and medium for generating data verification rules for a shared document. Background Art

[0002] The core of deepening the reform of the medical industry lies in building a practical and shared medical and health information system. This system aims to integrate existing resources, strengthen information standardization, and build a public service information platform to gradually achieve the goal of unification, efficiency, and interconnection.

[0003] By implementing the "Electronic Medical Record Sharing Document Specification", the construction of the hospital information platform can meet the standardization and unification needs of hospitals at all levels and types in terms of information transmission and exchange. This not only promotes the exchange and sharing of hospital information between different institutions and regions, but also effectively promotes the sharing of population health information and business collaboration. Under such regulatory requirements, hospitals must strictly manage data to ensure that the generated electronic medical record sharing documents meet the standards of interconnection and interoperability.

[0004] Other fields similar to the medical industry, such as finance, law, or education, also have strict industry standards and requirements. In these industries, the generation of data verification rules for shared documents also faces the same technical challenges as the medical industry. In order to meet these challenges, relevant technical teams need to develop and implement efficient data verification mechanisms that not only comply with industry standards, but also adapt to the ever-changing technical environment and business needs. In this way, it can ensure that shared documents can be safely and accurately transmitted and used in various industries, thereby improving the operational efficiency and data management level of the entire industry.

[0005] However, to date, we have not seen any technical solutions that can automatically generate data verification rules for shared documents. Despite significant progress in the field of data processing and automation, the technical implementation in this particular field is still blank. Researchers and developers have not yet found an effective way to automatically generate and verify data in shared documents, which is undoubtedly a technical problem that needs to be solved urgently. Summary of the invention

[0006] The technical problem to be solved by the present invention is to provide a method, device, equipment and medium for generating data verification rules for a shared document, thus filling the gap in the current technical field.

[0007] In a first aspect, the present invention provides a method for generating data verification rules for a shared document, comprising:

[0008] S1. Receive the relevant configurations of each data node based on industry specifications through the configuration interface, including node dependencies, data sources, SQLs used to obtain node data, parameter expressions, bound fields or dependent node attributes, mapping to standard data, standard dictionary IDs, and data elements;

[0009] S2. According to the type of shared document for which verification rules are to be generated, obtain the relevant configurations of the shared document, including data configurations of each node, structural information of each node, and data sets bound to each node, and assemble the necessary information for each node;

[0010] S3. Sort the node set, with non-required nodes in the front and nodes with shorter XPath in the front;

[0011] S4. Create relevant sets, including a MAP set nullCheckSqlMap for non-empty verification SQLs, a MAP set optionalSqlMap for non-required condition SQLs, and a MAP set baseMap for basic SQLs:

[0012] S5. Traverse the node set to generate verification rules for each node, and then generate data verification rules for the shared document, including:

[0013] S51. Generate the basic SQL for the node according to the mapping configuration and store it in baseMap; generate non-empty verification SQLs and put them into nullCheckSqlMap; generate non-required verification partial SQLs and put them into optionalSqlMap;

[0014] S52. Determine whether the node is bound to a mapping. If so, generate mapping verification constraint SQLs and then proceed to the next step; if not, directly proceed to the next step;

[0015] S53. Determine whether the node is bound to a dictionary. If so, generate dictionary constraint SQLs and then proceed to the next step; if not, directly proceed to the next step;

[0016] S54. Determine whether the node is configured with data elements. If so, generate data element verification constraint SQLs and then proceed to the next step; if not, directly proceed to the next step;

[0017] S55. Use non-empty constraints;

[0018] S56. Parse the basic SQL and replace the table names in the constraint SQLs;

[0019] S57. After replacing the table names, splice the basic SQL and the constraint SQLs to obtain the final verification SQL;

[0020] S6. Wrap the final verification SQL into an object according to the system requirements, persist it in the database, and generate the data verification rules for the shared document.

[0021] In a second aspect, the present invention provides an apparatus for generating data verification rules for a shared document, which implements the method described in the first aspect when executing the program.

[0022] In a third aspect, the present invention provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, it implements the method described in the first aspect.

[0023] In a fourth aspect, the present invention provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, it implements the method described in the first aspect.

[0024] The technical solution provided by the present invention has at least the following technical effects or advantages: After configuration based on the requirements of the industry shared document specification, all data verification rules for the shared document are automatically generated by parsing the configuration. By automatically executing the data verification rules, data maintenance personnel can immediately discover and process data that does not meet the specification, further improving the data quality and ensuring that the generated shared document can meet the requirements of the interconnection standard, realizing high-quality data exchange between institutions. It lays a solid foundation for cross-institutional and cross-regional industry data exchange and mutual recognition, and is particularly suitable for data sharing in the medical industry.

[0025] The above description is only an overview of the technical solution of the present invention. In order to be able to understand the technical means of the present invention more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features and advantages of the present invention more obvious and understandable, the following specifically describes the embodiments of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The present invention will be further described below with reference to the accompanying drawings in conjunction with embodiments.

[0027] Figure 1 It is a flowchart of the method in Embodiment 1 of the present invention;

[0028] Figure 2 and Figure 3 It is an example diagram of the configuration status of the data node receiving the industry specification of the electronic medical record shared document in the configuration interface of the embodiment of the present invention;

[0029] Figure 4 It is a schematic diagram of the parameter configuration interface when there is a parameter in the parameter list that depends on the data of the upper-level node in the embodiment of the present invention;

[0030] Figure 5Schematic diagram of parameter configuration interface during binding mapping in an embodiment of the present invention;

[0031] Figure 6 Schematic diagram of parameter configuration interface during binding dictionary in an embodiment of the present invention;

[0032] Figure 7 Example diagram of data element directory in an embodiment of the present invention;

[0033] Figure 8 Schematic diagram of the structure of the device in the second embodiment of the present invention;

[0034] Figure 9 Schematic diagram of the structure of the electronic device in the third embodiment of the present invention;

[0035] Figure 10 Schematic diagram of the structure of the medium in the fourth embodiment of the present invention. Detailed implementation manners

[0036] By providing a method, device, equipment and medium for generating data verification rules of shared documents in the embodiments of the present application, the blank in this technical field is filled.

[0037] The technical solution in the embodiments of the present application has the following general idea: receiving relevant configurations of each data node based on industry specifications through a configuration interface, generating the basic sql of the node, mapping verification constraint sql, dictionary constraint sql, and data element verification constraint sql according to the relevant configurations; using non-null constraints; parsing the basic sql and replacing the table names in the constraint SQL; concatenating the basic sql and the constraint SQL to obtain the final verification sql; then packaging it into an object and persisting it to the database to generate the data verification rules of the shared document. Thus, after configuring according to the requirements of the industry shared document specification, all data verification rules of the shared document can be automatically generated by parsing the configuration. By automatically executing the data verification rules, data maintenance personnel can immediately discover the data that does not meet the specifications for processing, further improving the data quality and ensuring that the generated shared document can meet the requirements of the interconnection standard, realizing high-quality data exchange between institutions. It lays a solid foundation for cross-institutional and cross-regional industry data exchange and mutual recognition, and is particularly suitable for data sharing in the medical industry.

[0038] Embodiment 1

[0039] As Figure 1 shown, this embodiment provides a method for generating data verification rules of shared documents, including:

[0040] S1. Receive the relevant configurations of each data node based on industry specifications through the configuration interface, including node dependencies, data sources, SQL statements used to obtain node data, parameter expressions, bound fields or dependent node attributes, mapping to standard data, standard dictionary IDs, and data elements.

[0041] Such as Figure 2 and Figure 3 As shown, taking the configuration of electronic medical record sharing documents as an example, in the "Specification for Electronic Medical Record Sharing Documents", the template structures of 53 types of documents, as well as the connotations and cardinalities of each node, are clearly defined. Therefore, it is necessary to provide an "electronic medical record sharing document" configuration system, in which we configure each data node and specify the data source. The configuration items are as follows:

[0042] (1) Dependency: Identify whether this node has a specific SQL statement. If "yes" is selected, the dependent node can be selected, and the data of this node is obtained from the dependent node.

[0043] (2) Data source: The database where the data is located.

[0044] (3) SQL: The SQL statement used to obtain the data of this node.

[0045] (4) Parameter expression: Configure the parameters in the SQL statement (SQL parameters such as visit number and patient master index number used to locate health events).

[0046] (5) Bound field / dependent node attribute: Which field is used as the data to fill in the shared document node after obtaining the result set through SQL or the dependent node.

[0047] (6) Mapping to standard data: If the data standard dictionary of the business system is inconsistent with that used in the "Specification for the Generation of Electronic Medical Record Sharing Documents", it can be mapped and converted into the standard dictionary data of the "Specification for the Generation of Electronic Medical Record Sharing Documents".

[0048] (7) Standard dictionary ID: Convert codes and names to each other through the dictionary. For example, convert the gender code "1" obtained from the sex field to the gender name "male".

[0049] (8) Data element: Select the relevant data set of the "Specification for the Generation of Electronic Medical Record Sharing Documents", and the system will bring out the data element, table name, and field. Selecting the data element has nothing to do with generating the shared document itself, but will be used when generating the shared document verification rules later, and is used to identify the data set constraints that the node data needs to meet.

[0050] S2. According to the type of shared document for which verification rules are to be generated, obtain the relevant configurations of the shared document, including:

[0051] Data configuration of each node (source SQL, dependent nodes, etc.);

[0052] Structural information of each node (node cardinality, whether it is required, etc.);

[0053] Datasets bound to each node;

[0054] Assemble the necessary information for each node.

[0055] S3. Sort the node set, and the sorting rules are as follows:

[0056] Non-required nodes are ranked first, and nodes with shorter XPath are placed in the front;

[0057] S4. Create relevant sets, including:

[0058] nullCheckSqlMap: MAP set of non-null check SQL;

[0059] optionalSqlMap: MAP set of non-required condition SQL;

[0060] baseMap: MAP set of basic SQL. After each node generates the basic SQL, it is stored in this set:

[0061] S5. Traverse the node set, generate the verification rules for each node, and then generate the data verification rules for the shared document, including:

[0062] S51. Generate the basic SQL of the node according to the mapping configuration and store it in baseMap; generate the non-null check SQL and put it into nullCheckSqlMap; generate the non-required check part SQL and put it into optionalSqlMap;

[0063] The above S51 further includes:

[0064] 1) First, determine whether the node depends on a certain upper-level node?

[0065] 1.1 If so, find the upper-level node according to DEPEND_XPATH and obtain the dependent upper-level SQL;

[0066] Since the nodes with shorter XPath are placed in the front when sorting the node set, it is very likely that the dependent upper-level has already executed the step of generating the verification SQL at this time, and only the SQL needs to be directly obtained from the "baseMap"; if the current node is a non-required node and the dependent upper-level node is a required node, and the dependent upper-level node has not generated the verification SQL at this time, then replace the object for generating the basic SQL with the upper-level node, and then go back to 1) to get the basic SQL of a parent node (this is a recursion here).

[0067] 1.2 Secondly, determine whether there are non-required nodes in the parent node. If so, generate the non-required condition SQL and store it in the optionalSqlMap. The steps for generating the non-required condition SQL are as follows:

[0068] Obtain the non-null check SQL for this non-required node. First, try to directly obtain it from the "nullCheckSqlMap". If not, similarly change the object for generating the basic SQL to this upper-level non-required node, and then jump to step1 to obtain the non-null check SQL for this upper-level non-required node;

[0069] Use the JSqlParse Java SQL parsing tool (subsequent SQL parsing also uses this tool, so it will not be repeated) to parse the non-null check SQL of the upper-level non-required node. Use the tool to capture the where condition in the SQL and take the negation with not. Name the SQL at this time as "optionalNodeNotSql";

[0070] Use the tool to parse "optionalNodeNotSql" to obtain the main table name "mainTableName"; obtain the unique visit number field name visit_no of the main table of this type of shared document, and change the select part of "optionalNodeNotSql" to mainTableName.visit_no;

[0071] Finally, concatenate it into the following SQL:

[0072] A.visit_no IN(SELECT mainTableName.visit_no from the remaining part of optionalNodeNotSql);

[0073] Store the non-required condition SQL of this node in the "optionalSqlMap".

[0074] 1.3 Then, generate the non-null check SQL; specifically:

[0075] Determine whether this node is a non-required node. If so, its non-null check is meaningless and can be skipped, or you can just give an SQL and set the where condition to 1 = 2, indicating no verification meaning; if not, the conditional SQL for the non-null check part is the dependent attribute of this node plus "IS NULL", so as to generate the non-null check SQL and put it into the nullCheckSqlMap;

[0076] For example, if it depends on the "name" attribute, the non-null condition is "name is null". Similarly, first obtain the non-null check SQL for the dependent parent node from "nullCheckSqlMap". Which judgment of the dependent parent node does this node depend on? If the non-null check SQL of the dependent parent node does not have a where condition, then connect the non-null condition with where; if it does, then connect with and. Put the SQL for generating the non-null check part into "nullCheckSqlMap".

[0077] End S51 and enter S52.

[0078] 2) Determine whether the node is the head node. If it is, obtain the part before "where" and give the table an alias, for example, the alias is A, and enter S52;

[0079] 3) Obtain the parameter list of the node and whether it contains parameters that depend on the superior node;

[0080] 4) Obtain the main table SQL:

[0081] 4.1 If there are parameters in the parameter list that are data dependent on the superior node, obtain the basic SQL of the dependent superior node as the main table SQL and replace the select part of the SQL configured for the current node; if there are no parameters in the parameter list that are data dependent on the superior node, use the basic SQL of the head node as the main table SQL;

[0082] As Figure 4 shown, for example, the superior node "Surgical item" is a multi-element node. The SQL of the "Anesthesia method code" node here needs to use a surgical record ID parameter to associate with the "Surgical item" node to ensure that the data under the same entry comes from the same surgical record.

[0083] 4.1.1 At this time, obtain the basic SQL of the dependent superior node as the main table SQL.

[0084] 4.1.2 Replace the select part of the SQL configured for the current node.

[0085] Since there may be table association operations in the SQL configured for the node, resulting in duplicate field names in the result set queried by the SQL. So first obtain the result set structure of the SQL, remove the duplicate field names and use them as the select part of the SQL. Intercept the part before the where condition of the SQL at this time and name it selectSql.

[0086] 4.2 If there are no parameters in the parameter list that are data dependent on the superior node, use the basic SQL of the head node as the main table SQL.

[0087] 5) Generate the basic sql of the node: specifically:

[0088] 5.1 Extract the part before where in the node sql; if sql is not an associated query, replace the "select query field list" with "select*".

[0089] 5.2 Parse the where part in the node sql and generate the on condition "onSql" and the where condition "whereSql";

[0090] For ease of understanding, Figure 4 The sql is an example, the sample sql is as follows:

[0091] SELECT

[0092] ANESTHESIA_DOCTOR,ANESTHESIA_DOCTOR_ID

[0093] FROM

[0094] CDR_MEDICAL_OPERATION

[0095] WHERE

[0096] OPERATION_ID=:KEY

[0097] AND DATA_PROVIDE_ORG_CODE=:orgCode

[0098] AND ANESTHESIA_DOCTOR IS NOT NULL AND ANESTHESIA_DOCTOR! ="ANDANESTHESIA_DOCTOR!='-'

[0099] AND ANESTHESIA_DOCTOR_ID IS NOT NULL AND ANESTHESIA_DOCTOR_ID! ="ANDANESTHESIA_DOCTOR_ID!='-'

[0100] 5.2.1 Define a string collection SubtableJoinFields to store associated fields.

[0101] 5.2.2 Use "and" and "or" to match the SQL in the where part and split it to obtain different SQL fragments. Then traverse these fragments and execute steps 5.2.3 to 5.2.5.

[0102] 5.2.3 Record whether there are unpaired left parentheses or unpaired right parentheses in the SQL fragment.

[0103] 5.2.4 Match the parameters in the string to obtain the corresponding parameter information. The parameters in this article are marked with colons, so use (:\w+) to match. If the currently traversed SQL fragment successfully matches a parameter, perform the following steps to generate the association condition.

[0104] 5.2.4.1 Obtain the information of this parameter in the parameter list.

[0105] 5.2.4.2 The first non-comparison symbol (such as greater than sign, less than sign, equal sign, etc.) before the matched parameter is the association field "joinWord". If there is an association in the SQL, a field like "A.field" may be obtained. Therefore, "joinWord" should be split according to "." and take the last fragment. Put the obtained association field into SubtableJoinFields.

[0106] 5.2.4.3 Generate the association condition according to the parameter information

[0107] (1) Determine whether the parameter is some context parameters predefined by the system.

[0108] If it is some context parameters predefined by the system, such as visit number, institution, etc. The main table fields corresponding to these parameters are fixed, and the association condition is A.main table field = B.association field. Taking "DATA_PROVIDE_ORG_CODE = :orgCode" in the example as an example, when the association field is recognized as "DATA_PROVIDE_ORG_CODE" and the main table field corresponding to the institution parameter is "ORG_CODE", the obtained association condition is "A.ORG_CODE = B.DATA_PROVIDE_ORG_CODE".

[0109] If it is not some context parameters predefined by the system, obtain the attribute of the upper-level node bound by the parameter. The association condition is A.attribute of the upper-level node bound = B.association field. Taking OPERATION_ID = :KEY in the example as an example, the attribute of the upper-level node bound by the parameter is OPERATION_ID, and the obtained association condition is

[0110] "A.OPERATION_ID = B.OPERATION_ID".

[0111] (2) The generated associated conditions are spliced into "onSql". When splicing, it is spliced according to the "AND" and "OR" in front of the current sql fragment. At the same time, it should also be noted that if there are unmatched parentheses (step 5.2.3), they need to be supplemented correspondingly during splicing.

[0112] 5.2.5 If the current traversed sql fragment does not match the parameter, splice the sql fragment into "whereSql", and also pay attention to parentheses and connection strings (AND or OR).

[0113] 5.3 Generate the basic sql of this node.

[0114] 6) Generate non-null verification sql: Generate non-null conditions according to the associated field set SubtableJoinFields, and add them to the where condition outside the basic sql to generate the non-null sql of the node;

[0115] The non-null verification sql of the example sql is

[0116] SELECT * FROM (" + main table sql + ") A LEFT JOIN (" + selectSql + whereSql + ") B ON " + onSql;

[0117] The basic sql of the example sql is

[0118]

[0119] 7) Generate the sql for non-required verification part;

[0120] In the above (1) and (7), the specific method of generating the sql for non-required verification part is:

[0121] Obtain the non-null verification sql of this non-required node. First, try to directly obtain it from the nullCheckSqlMap. If not, replace the object for generating the basic sql with this upper-level non-required node, and then jump to step 1 to obtain the non-null verification sql of this upper-level non-required node;

[0122] Use the JSqlParse parsing tool to parse the non-null verification sql of the upper-level non-required node, use the JSqlParse parsing tool to capture the where condition in the sql and take the inverse with not, and name the sql at this time as "optionalNodeNotSql";

[0123] Use a tool to parse "optionalNodeNotSql" to obtain the main table name "mainTableName"; obtain the unique field name visit_no of the main table of such shared documents, change the select part of "optionalNodeNotSql" to mainTableName.visit_no, splice to obtain the non-mandatory condition sql of the node, and save it to "optionalSqlMap".

[0124] S52. Determine whether the node is bound to a mapping. If so, generate a mapping verification constraint sql, and then proceed to the next step; if not, directly proceed to the next step;

[0125] In the above S52, generating the mapping verification constraint sql specifically includes:

[0126] S521. According to the different meanings of the data source, the mapping verification sql is divided into the following two:

[0127] The "codeVerifySql" for verifying code:

[0128] select LOCAL_VALUE_CODE value from mdm_dict_map_item where MAP_ID=”

[0129] union all

[0130] selectVALUE_CODE value frommdm_dict_map_itemwhere MAP_ID=”;

[0131] The "nameVerifySql" for verifying name:

[0132] select LOCAL_VALUE_NAME value from mdm_dict_map_item where MAP_ID=”

[0133] union all

[0134] selectVALUE_NAME value frommdm_dict_map_itemwhere MAP_ID=”;

[0135] S522. According to the following method, determine whether the meaning of the source data used when generating the shared document for this node is code or name:

[0136] A) Determine whether the node name contains "@code". If it does, initially determine that the meaning of the node is code. At this time, check whether the node has a bound dictionary. If there is a bound dictionary, it means the source data is name, and use nameVerifySql. If there is no bound dictionary, it means the source data is code, and use codeVerifySql;

[0137] B) Determine whether the node name contains "@displayName". If it does, initially determine that the meaning of the node is name. At this time, also determine whether to take the inverse according to whether there is still a bound dictionary;

[0138] C) If the node name does not contain "@code" nor "@displayName", then connect codeVerifySql and nameVerifySql through "UNION ALL". As long as one of them is met, it is considered that the source data meets the verification;

[0139] As Figure 5 shown, if the node name contains "@code" and there is no bound dictionary, the meaning of the source data is code, and use codeVerifySql.

[0140] As Figure 6 shown, if the node name contains "@displayName" but there is a bound dictionary indicating the mutual conversion between code and name, then the meaning of the source data is code, and use codeVerifySql.

[0141] S523. Determine whether the node is a non-required node. If not, the verification sql is: not(bound field is not null and (bound field in (mapping verification sql))); if so, the verification sql is: not(bound field is not null and (bound field in (mapping verification sql))) and bound field is not null.

[0142] S53. Determine whether the node is bound to a dictionary. If so, generate a dictionary constraint sql, and then proceed to the next step; if not, directly proceed to the next step;

[0143] In the above S53, generating the dictionary verification sql specifically includes:

[0144] S531. Generate codeVerifySql and nameVerifySql according to the configured dictionary,

[0145] Verify the "codeVerifySql" of code:

[0146] select VALUE_CODE value from mdm_dict_view where class_id = “

[0147] Verify the “nameVerifySql” for name:

[0148] select VALUE_NAME value from mdm_dict_view where class_id = “

[0149] S532. Determine whether the meaning of the source data used when this node generates a shared document is code or name according to the following method:

[0150] A) Determine whether the node name contains “@code”. If it does, initially determine that the meaning of this node is code; at this time, determine whether the node has a bound dictionary. If there is a bound dictionary, it means the source data is name, and use nameVerifySql; if there is no bound dictionary, it means the source data is code, and use codeVerifySql;

[0151] B) Determine whether the node name contains “@displayName”. If it does, initially determine that the meaning of this node is name. At this time, also determine whether to take the inverse according to whether there is still a bound dictionary;

[0152] C) If the node name does not contain “@code” nor “@displayName”, then connect codeVerifySql and nameVerifySql through “UNION ALL”. As long as one of them is met, it is considered that the source data meets the verification;

[0153] S533. Determine whether this node is a non - required node. If not, the verification sql is: not (bound field is not null and (bound field in (mapped verification sql))); if yes, the verification sql is: not (bound field is not null and (bound field in (mapped verification sql))) and bound field is not null.

[0154] S54. Determine whether the node is configured with a data element. If so, generate a data element verification constraint sql, and then proceed to the next step; if not, directly proceed to the next step; generating the element verification constraint sql specifically includes:

[0155] S541. Find the data element information according to the data element identifier of the node, and determine whether this data element has a related dictionary code: if so, find the dictionary according to the dictionary code, and generate a dictionary verification sql after finding the dictionary; if not, proceed to the next step;

[0156] S542. For data elements of non-date and time types, corresponding constraint conditions are generated according to the data type description rules of the data element values. For data elements of non-date and time types, they are not considered.

[0157] As Figure 7 shown, taking health information as an example, its data elements include attributes such as data type, data length, and relevant field codes. That is, the data element information can be found according to the data element identifier of the node, and it can be judged whether the data element has relevant dictionary codes. If there is no dictionary code: corresponding constraints are generated according to the data element.

[0158] The data type description rules of data element values are shown in Table 1, and the representation formats are shown in Tables 2 and 3. The character type (S) is divided into three forms:

[0159] S1 represents non-enumerable and in the form of character description;

[0160] S2 represents an enumerated type, and the number of enumerated values does not exceed 3;

[0161] S3 represents the form of a code table.

[0162] Table 1 Data type description rules of data element values

[0163]

[0164]

[0165] Table 2 Description rules of character meanings in the representation format of data element values

[0166]

[0167] Table 3 Description rules of character lengths in the representation format of data element values

[0168]

[0169] Application example:

[0170] Example 1: S character type

[0171] AN10 is a character fixed with a length of 10 characters (equivalent to 5 Chinese characters).

[0172] AN..10 is a character with variable length and a maximum length of 10 characters.

[0173] AN4..10 is a character with variable length, a minimum of 4 and a maximum of 10 characters.

[0174] AN..20X3 is a character with variable length, at most 3 lines, and a maximum length of 20 characters per line.

[0175] As shown in the aforementioned Tables 1 to 3, the health information data element WS363 defines the data type of the data element. Among them, for the date types D, DT, and T, as long as the corresponding time field is designed as a time type in the data center table model design, then at the data quality level, only whether it is null needs to be concerned about and there is no need to worry about the value not meeting the standard. Therefore, the data elements of the date and time type are not considered here. The binary BY will not be used and is skipped. For other data types, just generate the corresponding constraint conditions according to the descriptions and examples in the figure above. For example, for the data element of age, its data format is N1..3, which means the minimum length is 1 digit and the maximum length is 3 digits. The corresponding constraint sql is:

[0176] not(

[0177] AGE_YEAR is notnull

[0178] and REGEXP_LIKE(to_char(AGE_YEAR),'^\d*(\.\d+)?$')

[0179] and(1<=length(TO_CHAR(AGE_YEAR,'FM990'))

[0180] and length(TO_CHAR(AGE_YEAR,'FM990'))<=3)

[0181] )。

[0182] S55. Use the not-null constraint; specifically:

[0183] Since the not-null constraint and the not-required sql for this node have been generated when generating the basic sql in S51, and they exist in nullCheckSqlMap and optionalSqlMap.

[0184] If there is a not-required node in the upper-level node of the node, obtain the not-null verification sql from nullCheckSqlMap and modify the not-null verification sql;

[0185] Wrap the original where condition with parentheses and add the not-required condition sql, and connect them with "AND".

[0186] S56. Parse the basic sql and replace the table name in the constraint SQL; in S56, replacing the table name in the constraint SQL means replacing the table name.field name in the constraint SQL with the alias.field name.

[0187] For example: When generating the basic SQL, alias the main table part as A and the slave table part as B. When connecting the basic SQL and the constraint SQL, it is necessary to replace the table name.field name in the constraint SQL with the alias.field name. That is, replace table.xx>1 and table.xx<2 in the constraint SQL with A.xx>1 and B.xx<2.

[0188] S57. After replacing the table names, splice the basic SQL and the constraint SQL to obtain the final verification SQL;

[0189] S6. Package the final verification SQL into an object according to the system requirements, persist it to the database, and generate the data verification rules for the shared document.

[0190] Embodiment 2

[0191] Based on the same inventive concept, the present application also provides a device corresponding to the method in Embodiment 1, as detailed in Embodiment 2.

[0192] As Figure 8 shown, in this embodiment, a device is provided for the method of Embodiment 1, specifically including:

[0193] A configuration interface for accepting the relevant configurations of each data node based on industry specifications, including node dependency situations, data sources, SQL used to obtain node data, parameter expressions, bound fields or dependent node attributes, mapping to standard data, standard dictionary IDs, and data elements;

[0194] An acquisition configuration module for acquiring the relevant configurations of the shared document according to the selected type of the shared document for which verification rules are to be generated, including the data configurations of each node, the structural information of each node, and the data sets bound to each node, and assembling the necessary information for each node;

[0195] A sorting module for sorting the node set, with non-required nodes placed in the front and nodes with shorter node xpaths placed in the front;

[0196] A set creation module for creating relevant sets, including a MAP set nullCheckSqlMap of non-empty verification SQL, a MAP set optionalSqlMap of non-required condition SQL, and a MAP set baseMap of basic SQL:

[0197] A verification rule generation module for traversing the node set and generating the verification rules for each node, including:

[0198] S51. Generate the basic SQL of the node according to the mapping configuration and store it in baseMap; non-empty verification SQL, and non-required verification partial SQL;

[0199] S52. Determine whether the node is bound to a mapping. If so, generate a mapping verification constraint SQL; if not, proceed to the next step.

[0200] S53. Determine whether the node is bound to a dictionary. If so, generate a dictionary constraint SQL; if not, proceed to the next step.

[0201] S54. Determine whether the node is configured with data elements. If so, generate a data element verification constraint SQL; if not, proceed to the next step.

[0202] S55. Use a non - null constraint.

[0203] S56. Parse the basic SQL and replace the table name in the constraint SQL.

[0204] S57. After replacing the table name, concatenate the basic SQL and the constraint SQL to obtain the final verification SQL.

[0205] S6. Package the final verification SQL into an object according to the system requirements, persist it to the database, and generate the data verification rules for the shared document.

[0206] Since the device introduced in the second embodiment of the present invention is the device used to implement the method of the first embodiment of the present invention, based on the method introduced in the first embodiment of the present invention, those skilled in the art can understand the specific structure and variations of the device, so it will not be elaborated here. Any device used to implement the method of the first embodiment of the present invention belongs to the scope of protection of the present invention.

[0207] Embodiment Three

[0208] Based on the same inventive concept, this application provides an electronic device embodiment corresponding to Embodiment One, as detailed in Embodiment Three. This embodiment provides an electronic device, as Figure 9 shown, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, any implementation manner in Embodiment One can be realized.

[0209] Since the electronic device introduced in this embodiment is the device used to implement the method in Embodiment One of this application, based on the method introduced in Embodiment One of this application, those skilled in the art can understand the specific implementation manner of the electronic device in this embodiment and its various forms of change. Therefore, how this electronic device implements the method in Embodiment One of this application will not be described in detail here. Any device used by those skilled in the art to implement the method in Embodiment One of this application belongs to the scope of protection of this application.

[0210] Embodiment Four

[0211] Based on the same inventive concept, this application provides a storage medium corresponding to Embodiment 1. For details, see Embodiment 4. This embodiment provides a computer-readable storage medium. As Figure 10 shown, a computer program is stored thereon. When the computer program is executed by a processor, any implementation manner in Embodiment 1 can be realized.

[0212] The technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0213] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0214] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram can be realized by computer program instructions, and the combination of processes and / or blocks in the flowchart and / or block diagram can also be realized by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for realizing the functions specified in one Figure 1 process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0215] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device, and the instruction device realizes the functions specified in one Figure 1 process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0216] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process. Therefore, the instructions executed on the computer or other programmable device provide steps for realizing the functions specified in one Figure 1 process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0217] Although the specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments we described are illustrative rather than used to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should all be covered by the scope protected by the claims of the present invention.

Claims

1. A method for generating data verification rules for a shared document, characterized in that: include: S1. Receive the relevant configuration of each data node based on industry specifications through the configuration interface, including node dependency, data source, SQL used to obtain node data, parameter expression, binding field or dependent node attribute, mapping to standard data, standard dictionary ID and data element; S2. According to the type of the selected shared document for which verification rules are to be generated, obtain the relevant configuration of the shared document and assemble the necessary information of each node; the relevant configuration includes the data configuration of each node, the structural information of each node and the data set bound to each node; S3, sort the node set, put non-mandatory nodes in front, and put nodes with short xpath in front; S4. Create related collections, including the MAP collection nullCheckSqlMap of non-null check SQL, the MAP collection optionalSqlMap of non-mandatory condition SQL, and the MAP collection baseMap of basic SQL: S5. Traverse the node set, generate verification rules for each node, and then generate data verification rules for the shared document, including: S51, generate the basic sql of the node according to the mapping configuration and store it in baseMap; Generate non-empty check SQL and put it into nullCheckSqlMap; generate non-mandatory check part SQL and put it into optionalSqlMap; S52, determine whether the node is bound to a mapping, if so, generate a mapping verification constraint SQL, and then proceed to the next step; if not, directly proceed to the next step; S53, determine whether the node is bound to a dictionary, if so, generate a dictionary constraint SQL, and then proceed to the next step; if not, directly proceed to the next step; S54, determine whether the node is configured with data elements, if so, generate data element verification constraint SQL, and then proceed to the next step; if not, directly proceed to the next step; S55. Use non-null constraints; S56, parse the basic SQL and replace the table name in the constraint SQL; S57, after replacing the table name, concatenate the basic SQL and the constraint SQL to obtain the final verification SQL; S6. Package the final verification SQL into an object according to system requirements, persist it to the database, and generate data verification rules for shared documents.

2. The method for generating data verification rules for a shared document according to claim 1, characterized in that: The S51 further comprises: 1) Determine whether the node depends on a certain upper node. If so, find the upper node according to DEPEND_XPATH and obtain the upper SQL that it depends on; Determine whether there is a non-mandatory node in the parent node. If so, generate non-mandatory conditional SQL and store it in optionalSqlMap; Determine whether the node is a non-required node. If so, skip it. If not, add "IS NULL" to the node's dependency property to generate a non-empty check SQL and put it into nullCheckSqlMap. 2) Determine whether the node is a head node. If so, obtain the part before "where" and give the table an alias, and enter S52; 3) Get the parameter list of the node and whether it contains parameters that depend on the parent node; 4) Get the main table SQL: If there are parameters in the parameter list that are dependent on the data of the upper node, get the basic SQL of the upper node as the main table SQL and replace the select part of the SQL configured for the current node; if there are no parameters in the parameter list that are dependent on the data of the upper node, use the basic SQL of the head node as the main table SQL; 5) Generate the basic SQL of the node: intercept the part before where in the node SQL; parse the where part in the node SQL, generate the on condition "onSql" and the where condition "whereSql"; generate the basic SQL of the node; 6) Generate non-empty check SQL: Generate non-empty conditions based on the associated field set SubtableJoinFields, and add them to the where condition of the outer layer of the basic SQL to generate the non-empty SQL of the node; 7) Generate non-mandatory verification part sql; In 1) and 7), the non-mandatory verification part sql is generated as follows: Get the non-empty check sql of this non-mandatory node. First try to get it directly from nullCheckSqlMap. If it does not work, replace the object that generates the basic sql with this parent non-mandatory node, and then jump to step 1 to get the non-empty check sql of this parent non-mandatory node. Use JSqlParse to parse the non-empty check SQL of the upper non-mandatory node, use JSqlParse to capture the where condition in the SQL and set the not negation, and name the SQL at this time "optionalNodeNotSql"; Use tools to parse "optionalNodeNotSql" to obtain the main table name "mainTableName"; obtain the unique field name visit_no of the main table of this type of shared document, change the select part of "optionalNodeNotSql" to mainTableName.visit_no, concatenate the non-mandatory conditional sql of the node, and save it in "optionalSqlMap".

3. The method for generating data verification rules for a shared document according to claim 1, characterized in that: In S52, generating the mapping verification constraint SQL specifically includes: S521. According to the different meanings of data sources, the mapping verification sql is divided into the following two types: "codeVerifySql" to verify the code: select LOCAL_VALUE_CODE value from mdm_dict_map_item where MAP_ID=" union all selectVALUE_CODE value frommdm_dict_map_itemwhere MAP_ID="; Verify name "nameVerifySql": select LOCAL_VALUE_NAME value from mdm_dict_map_item where MAP_ID=" union all selectVALUE_NAME value frommdm_dict_map_itemwhere MAP_ID="; S522. Determine whether the source data used by the node to generate a shared document means code or name according to the following method: A) Determine whether the node name contains "@code". If so, it is preliminarily determined that the meaning of the node is code. At this time, determine whether the node has a binding dictionary. If there is a binding dictionary, it means that the source data is name, and use nameVerifySql. If there is no binding dictionary, it means that the source data is code, and use codeVerifySql. B) Determine whether the node name contains "@displayName". If so, it is preliminarily determined that the meaning of the node is name. At this time, it is also determined whether to negate it based on whether there is a bound dictionary; C) If the node name does not contain "@code" or "@displayName", codeVerifySql and nameVerifySql are connected through "UNION ALL". As long as one of them is met, the source data is considered to meet the verification requirements; S523. Determine whether the node is a non-mandatory node. If not, the verification SQL is: not(bound field is notnull and(bound field in(mapped verification SQL))); if so, the verification SQL is: not(bound field is not nulland(bound field in(mapped verification SQL)))and bound field is notnull.

4. The method for generating data verification rules for a shared document according to claim 1, characterized in that: In S53, generating the dictionary check SQL specifically includes: S531, codeVerifySql and nameVerifySql generated according to the configured dictionary, "codeVerifySql" to verify the code: selectVALUE_CODE value frommdm_dict_viewwhere class_id=" Verify name "nameVerifySql": selectVALUE_NAME value frommdm_dict_viewwhere class_id=" S532: Determine whether the source data used by the node to generate a shared document means code or name according to the following method: A) Determine whether the node name contains "@code". If so, it is preliminarily determined that the meaning of the node is code. At this time, determine whether the node has a binding dictionary. If there is a binding dictionary, it means that the source data is name, and use nameVerifySql. If there is no binding dictionary, it means that the source data is code, and use codeVerifySql. B) Determine whether the node name contains "@displayName". If so, it is preliminarily determined that the meaning of the node is name. At this time, it is also determined whether to negate it based on whether there is a bound dictionary; C) If the node name does not contain "@code" or "@displayName", codeVerifySql and nameVerifySql are connected through "UNION ALL". As long as one of them is met, the source data is considered to meet the verification requirements; S533. Determine whether the node is a non-mandatory node. If not, the verification SQL is: not(bound field is notnull and(bound field in(mapped verification SQL))); if yes, the verification SQL is: not(bound field is not nulland(bound field in(mapped verification SQL)))and bound field is notnull.

5. The method for generating data verification rules for a shared document according to claim 1, characterized in that: In S54, generating the dictionary check SQL specifically includes: S541, find the data element information according to the data element identifier of the node, and determine whether the data element has a related dictionary code: if so, find the dictionary according to the dictionary code, and generate a dictionary check SQL after finding the dictionary; if not, proceed to the next step; S542. For data elements of non-date and time types, corresponding constraint conditions are generated according to the data type description rule of the data element value. Data elements of non-date and time types are not considered.

6. The method for generating data verification rules for a shared document according to claim 1, characterized in that: The S55 is specifically: if there is a non-mandatory node in the parent node of the node, obtain the non-empty check sql from nullCheckSqlMap, modify the non-empty check sql to wrap the original where condition with brackets, add the non-mandatory condition sql, and connect them with "AND".

7. The method for generating data verification rules for a shared document according to claim 1, characterized in that: In S56, replacing the table name in the constraint SQL means replacing the table name.field name in the constraint SQL with alias.field name.

8. A device for generating data verification rules for a shared document, characterized in that: When the program is executed, the method according to any one of claims 1 to 7 is implemented.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When executed, the processor implements the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images