Service Sharing Data Processing Method and System Based on SaaS Platform

Abstract

The present application discloses a service sharing data processing method and system based on a SaaS platform, relating to the field of data processing. The method includes: receiving a business data set and determining the corresponding business system; converting each business data into a code item according to the business code table corresponding to the business system to obtain a code item group; identifying key business entities in the code item group and encoding them to obtain a unique identification code for each key business entity; encoding the unique identification code into the corresponding code item to obtain an updated code item group; in response to a cross-platform instruction, taking at least one code item in the updated code item group as service sharing data and determining the target business platform; obtaining the interface protocol of the target business platform and the database type of the target database; and converting the service sharing data into the business data of the target business platform according to the database type and the interface protocol. The present application can effectively improve the data processing efficiency across systems and platforms.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of data processing, and in particular, to a service sharing data processing method and system based on a SaaS platform. Background Art

[0002] With the rapid development of medical informatization, medical institutions are facing increasingly complex data management and business collaboration requirements. The data in the medical industry is characterized by diversity, complexity, and sensitivity, covering multiple aspects such as patient information, diagnosis and treatment records, medical images, and drug management. At the same time, there are often multiple independent information systems within medical institutions, such as electronic medical record systems, medical imaging systems, and laboratory information systems. These systems were developed by different suppliers at different times, using different technical architectures and data standards, forming information silos. With the continuous deepening and expansion of medical services, the collaboration between medical institutions is becoming increasingly frequent. For example, the rise of models such as remote consultation and medical consortia has further increased the need for cross-system and cross-platform data sharing and business collaboration.

[0003] In the traditional mode, cross-system and cross-platform data processing usually adopts the following two methods: 1. Point-to-point integration method: Establish direct data exchange interfaces between every two systems and platforms that need to interact. This method is relatively simple to implement. However, as the number of systems and platforms increases, the number of interfaces grows exponentially, and due to the inconsistent data formats and coding standards used by different systems and platforms, the maintenance cost is extremely high. 2. Middleware integration method: Implement data exchange between different systems and platforms by introducing middleware. The middleware is responsible for data conversion and routing, reducing the number of direct interfaces. However, as the number of systems and platforms increases, and due to the inconsistent data formats and coding standards between different systems and platforms, the middleware needs to process exponentially increasing data exchanges, seriously affecting the device performance.

[0004] In summary, the above traditional cross-system and cross-platform data processing methods can cope with the data interaction between a small number of systems. However, with the expansion of the scale of medical institutions and the increase in business complexity, and due to the inconsistent data formats and coding standards used by different systems and platforms, the workload of data conversion and mapping will be greatly increased, significantly reducing the work efficiency. Therefore, there is an urgent need for a method to solve the above problems. Summary of the Invention

[0005] The embodiments of the present application provide a service sharing data processing method and system based on a SaaS platform, which are used to effectively improve the data processing efficiency across systems and platforms.

[0006] To achieve the above object, the embodiments of the present application adopt the following technical solutions:

[0007] In a first aspect, a service sharing data processing method based on a SaaS platform is provided, which is applied to a SaaS platform. The SaaS platform integrates multiple business platforms, and n business code tables are deployed on the SaaS platform, where n is an integer greater than 2. Each business code table corresponds to a business system. The method includes:

[0008] In response to receiving a business data set, determine the business platform of the business data set, and based on the business platform, determine the business system corresponding to the business data set;

[0009] According to the business code table corresponding to the business system, convert each business data in the business data set into a code item to obtain a code item group;

[0010] Identify key business entities in the code item group, and encode each key business entity to obtain a unique identification code for each key business entity;

[0011] Encode the unique identification code into the corresponding code item to obtain an updated code item group;

[0012] In response to a cross-platform instruction for at least one code item in the updated code item group, use at least one code item in the updated code item group as service sharing data, and determine a target business platform according to the cross-platform instruction, where the cross-platform instruction is used to indicate that the service sharing data is transmitted to a target database of the target business platform;

[0013] Obtain the interface protocol of the target business platform and the database type of the target database;

[0014] According to the database type and the interface protocol, convert the service sharing data into business data of the target business platform so that the business data of the target business platform is stored in the target database of the target business platform.

[0015] In a possible implementation manner of the first aspect, after converting each business data in the business data set into a code item according to the business code table corresponding to the business system to obtain a code item group, it includes:

[0016] In response to a query instruction of the current user, determine the user permission of the current user;

[0017] Identify sensitive information in the code item group, where the sensitive information includes patient personal identity information, sensitive fields, and doctor personal information;

[0018] Perform desensitization processing on the sensitive information to obtain a desensitized code item group;

[0019] Filter the code item group after desensitization according to the user permissions to obtain a code item group after data filtering, where the code item group includes shared data fields.

[0020] In another possible implementation of the first aspect, the SaaS platform is also deployed with a central policy library that stores data access rules, where the data access rules include user roles and access control policies. Filtering the code item group after desensitization according to the user permissions to obtain a code item group after data filtering includes:

[0021] According to the user permissions, determine the user role of the current user and determine the access context information of the user role;

[0022] Through the access context information, determine the access control policy corresponding to the user role in the central policy library;

[0023] Through the access control policy, determine the visible code items of the current user in the code item group;

[0024] When the user role is a tenant role, determine the shared data fields in the visible code items according to a preset cross-tenant access protocol;

[0025] When the user role is not the tenant role, use the visible code items as the shared data fields;

[0026] Transfer the shared data fields to a preset visible code item group to obtain a code item group after data filtering.

[0027] In another possible implementation of the first aspect, the cross-tenant access protocol includes a protocol framework, an access control matrix, a policy engine, and a data sandbox environment;

[0028] Among them, the protocol framework is used to define the tenant scenarios of the cross-tenant access protocol, the access control matrix is used to define the access permissions of the current user according to the level of the visible code items and the tenant role, the policy engine is used to execute the access control policy, and the data sandbox environment is used to provide an isolated data processing space.

[0029] In another possible implementation of the first aspect, the central policy library also stores a regular expression library. Identifying the key business entities in the code item group and encoding each key business entity to obtain a unique identification code for each key business entity includes:

[0030] Identify the shared data fields using the regular expressions in the regular expression library to obtain key business entities;

[0031] Encode each of the key business entities using a preset business code table to obtain a unique identification code for each of the key business entities.

[0032] In another possible implementation of the first aspect, the encoding the unique identification code into the corresponding code item to obtain an updated code item group includes:

[0033] Traverse the code item group to obtain a plurality of the key business entities;

[0034] For each of the key business entities, embed the unique identification code into the comment field of the code item in the code item corresponding to the key business entity to obtain an updated code item;

[0035] Use the code item group containing all the updated code items as the updated code item group.

[0036] In another possible implementation of the first aspect, the converting the service shared data into the business data of the target business platform according to the database type and the interface protocol includes:

[0037] Determine the transmission method and data format of the target business platform according to the interface protocol;

[0038] Determine the data structure, syntax characteristics, and storage structure of the target database according to the database type;

[0039] Obtain all field information of the service shared data, and determine the mapping rules corresponding to the field information according to the syntax characteristics, where the field information includes field names and data types;

[0040] Create a configuration file in JSON format according to the mapping rules, the data format, the data structure, and the storage structure;

[0041] Use a preset mapping engine to read and parse the JSON format configuration file to generate data conversion logic;

[0042] Use the data conversion logic to convert the service shared data into the business data of the target business platform.

[0043] In another possible implementation of the first aspect, after using the data conversion logic to convert the service shared data into the business data of the target business platform, it includes:

[0044] The service data is transmitted to the target service platform by using the said transmission method, so that the service data is stored in the target database of the target service platform.

[0045] In another possible implementation manner of the first aspect, the mapping engine includes a JSON parser to read and deconstruct the configuration file.

[0046] In a second aspect, the present application provides a service sharing data processing system based on a SaaS platform, including:

[0047] A memory configured to store instructions; and

[0048] A processor configured to call the instructions from the memory and capable of implementing the above-mentioned service sharing data processing method based on the SaaS platform when executing the instructions.

[0049] Through the above technical solution, by integrating multiple business platforms and deploying multiple business code tables on the SaaS platform, cross-system and cross-platform data processing and sharing are achieved, effectively overcoming the limitations of traditional point-to-point integration and middleware integration methods. First, it automatically identifies the business platform and the corresponding business system to which the received business data set belongs, laying a foundation for subsequent data processing and ensuring the accuracy and pertinence of data processing. Second, by converting business data into code items, identifying key business entities, and encoding them to obtain unique identification codes, the standardization and uniqueness of data are achieved, effectively solving the problem of inconsistent coding standards between different systems and platforms. This method of unique coding effectively reduces the workload of data conversion and mapping and improves work efficiency. Third, in response to cross-platform instructions, the updated code item group can be flexibly shared as service data and transmitted to the target database of the target business platform, greatly enhancing the fluidity and sharing ability of data and meeting the increasingly frequent collaboration needs between medical institutions, such as data exchange needs in modes like remote consultation and medical consortium. In addition, it can automatically obtain the interface protocol of the target business platform and the type of the target database, and convert the service shared data into the business data of the target business platform, making the data conversion between different systems and platforms more efficient and greatly reducing the complexity and maintenance cost of system integration. Compared with the traditional point-to-point integration method, this method effectively avoids the problem that the number of interfaces increases exponentially with the increase in the number of systems and platforms, significantly reducing the difficulty and cost of system maintenance. Compared with the middleware integration method, through standardized data processing and data conversion, it effectively avoids the performance bottleneck problem caused by the need for middleware to process exponential data exchanges. In summary, this technical solution can not only meet the data sharing needs between multiple information systems within a single medical institution, but also support data exchange and business collaboration between different medical institutions. By means of unified data standards and data processing mechanisms, it effectively breaks the information silos, improves the interoperability and utilization efficiency of data, effectively promotes the development of medical informatization, and improves the quality and efficiency of medical services.

[0050] Other features and advantages of the embodiments of the present application will be described in detail in the subsequent specific implementation part. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 It is a schematic flowchart of a service sharing data processing method based on a SaaS platform provided by an embodiment of the present application;

[0052] Figure 2 It is an architecture diagram of a SaaS platform provided by an embodiment of the present application;

[0053] Figure 3 It is a schematic diagram of an access control matrix provided by an embodiment of the present application;

[0054] Figure 4 Schematic diagram of pseudo code for a REST API configuration that uses the HTTPS protocol and accepts JSON format data provided by an embodiment of the present application;

[0055] Figure 5 Schematic diagram of pseudo code for a database feature mapping table provided by an embodiment of the present application;

[0056] Figure 6 Schematic diagram of pseudo code for a mapping rule provided by an embodiment of the present application;

[0057] Figure 7 Schematic diagram of pseudo code for a configuration file structure provided by an embodiment of the present application;

[0058] Figure 8 Schematic diagram of pseudo code for a mapping provided by an embodiment of the present application;

[0059] Figure 9 Schematic diagram of pseudo code for a data processing logic provided by an embodiment of the present application;

[0060] Figure 10 Schematic diagram of pseudo code for a data mapping rule provided by an embodiment of the present application;

[0061] Figure 11 Schematic diagram of pseudo code for a mapping rule object provided by an embodiment of the present application. Detailed implementation manners

[0062] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. It should be understood that the specific implementation manners described herein are only for explaining and illustrating the embodiments of the present application, and are not used to limit the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present application without creative efforts shall fall within the scope of protection of the present application.

[0063] It should be noted that if there are directional indications (such as up, down, left, right, front, back...) involved in the embodiments of the present application, the directional indications are only used to explain the relative position relationship and movement conditions between components in a specific posture (as shown in the drawings). If the specific posture changes, the directional indications will also change accordingly.

[0064] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of the present application, such descriptions of "first", "second", etc. are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one such feature. In addition, the technical solutions between various embodiments can be combined with each other, but it must be based on the fact that those of ordinary skill in the art can implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection required by the present application.

[0065] Figure 1 Schematically shows a flowchart of a service sharing data processing method based on a SaaS platform according to an embodiment of the present application. As Figure 1 shown, the embodiment of the present application provides a service sharing data processing method based on a SaaS platform, which is applied to a SaaS platform. The SaaS platform integrates multiple business platforms, and n business code tables are deployed on the SaaS platform, where n is an integer greater than 2, and each business code table corresponds to a business system. The method may include the following steps:

[0066] S110. In response to receiving a business data set, determine the business platform of the business data set, and based on the business platform, determine the business system corresponding to the business data set;

[0067] S120. According to the business code table corresponding to the business system, convert each business data in the business data set into a code item to obtain a code item group;

[0068] S130. Identify the key business entities in the code item group, and encode each key business entity to obtain a unique identification code for each key business entity;

[0069] S140. Encode the unique identification code into the corresponding code item to obtain an updated code item group;

[0070] S150. In response to a cross-platform instruction for at least one code item in the updated code item group, use at least one code item in the updated code item group as service sharing data, and determine the target business platform according to the cross-platform instruction, where the cross-platform instruction is used to indicate that the service sharing data is transmitted to the target database of the target business platform;

[0071] S160. Obtain the interface protocol of the target business platform and the database type of the target database;

[0072] S170. Convert the service - shared data into the business data of the target business platform according to the database type and interface protocol, so that the business data of the target business platform is stored in the target database of the target business platform.

[0073] The business platform in this embodiment can be a platform, a service entity or a system. Figure 2 The architecture diagram of a SaaS platform provided by an embodiment of the present application is shown. Refer to Figure 2 , multiple business platforms receive data from the SaaS platform. Each business platform includes a target database for storing the data transmitted by the business platform. The SaaS platform (hereinafter referred to as the platform) includes a business code table, a data - processing module, a unique - identifier generator, and a data - conversion module. The data - processing module is used to process steps S110, S120, and S140. The unique - identifier generator is used to process step S130. The data - conversion module is used to process steps S150 to S170.

[0074] In actual implementation, the SaaS platform first receives data sets from each business platform. The business platforms can include an electronic medical record system, a drug management system, etc. The business data sets can come from multiple sources such as the hospital's electronic medical record system, drug management system, or other business platforms. After receiving the business data sets, the platform can determine the business platform to which they belong by analyzing the structure, format, or metadata of the business data sets. For example, if the business data set contains patient diagnosis information and prescription data, it is identified as coming from the electronic medical record system.

[0075] After determining the business platform, the platform further analyzes the data content and combines with predefined business rules to determine the specific business system corresponding to the business data set. The business systems include an outpatient business system, an inpatient business system, an electronic medical record business system, a drug management business system, etc. For example, the business data set belongs to the outpatient business system. In specific implementation, it can be achieved through keyword recognition. If keywords related to outpatient are recognized, the business data set is classified into the outpatient business system. Since the keywords of different business systems are quite different, the business system of the business data set can be directly determined by using keyword matching.

[0076] After determining the business system, the corresponding business code table can be obtained and converted into standardized code items. Specifically, according to the business system, the corresponding business code table can be called. Each business code table is predefined and contains all possible data items within the business system and their corresponding standard codes. During the conversion process, the platform will process each data item in the business dataset one by one. For each data item, the platform will search for a matching item in the corresponding business code table and convert it into a standard code item containing the code, name, pinyin code, and remarks. For example, if the original data contains the diagnosis of "cold", the platform will search for the corresponding item in the disease diagnosis code table and convert it into the following format: the code is "J00", the name is "cold", the pinyin code is "GM", and the remarks contain the ICD-10 classification information of the disease. A fuzzy matching algorithm can be used to handle possible synonyms or near-synonyms. For data items that cannot find an exact match in the code table, the platform can use the nearest neighbor matching or request manual intervention. Through the standardized conversion, the data can be converted into a unified code item format, improving the consistency and comparability of the data.

[0077] In the medical field, patients, doctors, and drugs are regarded as core business entities, that is, key business entities. The identification process will first traverse the code item group and determine whether each code item belongs to a key business entity through preset rules or machine learning models. For example, the platform may view the coding prefix or name characteristics of the code item to identify patient information, doctor information, or drug information. If a key business entity is identified, the platform will generate a unique identification code for each entity. The generation of the unique identification code can use UUID (Universally Unique Identifier), a combination of timestamp and random number, or a hash value based on entity characteristics. For patients, the unique identification code can be generated by combining the patient's identity information, date of birth, etc.; for doctors, their employee number or doctor's practice certificate number can be used; for drugs, it can be generated based on the drug code and batch number. The unique identification mechanism ensures that the same entity can be accurately identified and associated even on different platforms or between platforms. Through this step, the platform establishes a unified, cross-platform entity identification system, improving the consistency and traceability of the data.

[0078] After obtaining the unique identification code, the unique identification code is encoded into the corresponding code item to add an identifier that can uniquely identify key business entities across platforms while retaining the original code item information. In specific implementation, the platform traverses the key business entities identified in step S130 and their corresponding unique identification codes, and then finds all the code items related to each key business entity in the code item group. For each related code item, the platform adds a new field to its structure to store the unique identification code. For example, for code items related to patients (such as patient basic information, medical records, etc.), the platform adds the patient's unique identification code to these code items. Similarly, for code items related to doctors (such as doctor basic information, outpatient records, etc.) and code items related to drugs (such as drug information, prescription records, etc.), the corresponding unique identification codes are also added respectively. In this way, each code item not only contains its original encoding, name, pinyin code, and note information, but also adds a unique identifier that can be recognized across platforms, greatly improving the relevance and traceability of data, making it easier to identify and associate different data items of the same entity in subsequent data processing, analysis, and sharing processes, thus supporting more complex data operations and business processes.

[0079] The platform responds to receiving a cross-platform instruction, which comes from a user's operation, a preset business rule trigger, or an API call from another platform, etc. The cross-platform instruction contains the data range to be shared and the information of the target business platform. The platform can select the corresponding code items from the updated code item group according to the range specified in the cross-platform instruction. Data can be filtered according to conditions such as time range, data type, patient ID, etc. The selected code items are marked as service shared data. At the same time, the platform parses the target platform information in the cross-platform instruction to determine which database of which business platform the data needs to be transmitted to. In specific implementation, the platform mapping table pre-configured in the platform can be queried to obtain the detailed information of the target platform. For example, if the instruction indicates that the examination results of a certain patient are to be transmitted to the electronic medical record platform of a cooperative hospital, the platform will determine that the target platform is the electronic medical record platform of the cooperative hospital and obtain the corresponding database information of the platform.

[0080] The platform obtains the interface protocol of the target business platform and the database type of the target database to prepare for subsequent data conversion and transmission, ensuring that the data can be received and processed by the target platform in the correct format and manner. In one embodiment, the platform can first query a pre-configured platform information repository that stores the detailed technical parameters of all known business platforms. For each platform, the information repository may contain a detailed description of its API interface, such as the URL of the interface, the authentication method (e.g., OAuth, API Key, etc.), the supported data format (e.g., JSON), and the specific request and response structures. At the same time, it will also contain information about the database type used by the platform, such as MySQL, Oracle, MongoDB, etc. If the information of the target platform is not in the pre-configured library, the platform can dynamically send a probing request to the target platform to determine its interface protocol and database type. For the determination of the database type, if it cannot be directly obtained, the platform can infer it based on the response characteristics received. For example, a specific error message format may imply the type of the underlying database. Through this step, the platform can obtain all the technical details required for effective communication with the target platform, providing the necessary parameters and guidance for subsequent data conversion and transmission. This ability to dynamically adapt to the characteristics of different platforms greatly improves the compatibility and scalability of the platform, enabling data sharing to cross the barriers of different technical architectures.

[0081] Finally, the service shared data is converted into a format acceptable to the target business platform and stored. It can ensure the seamless integration of the data into the target platform according to the obtained target platform interface protocol and database type. First, the platform can select the corresponding data conversion strategy according to the type of the target database. For example, if the target is a relational database (such as MySQL or Oracle), the platform can organize the code items into a table structure and generate the corresponding SQL insert or update statements. If the target is a document database (such as MongoDB), the data can be converted into JSON format. Next, the platform can construct an API request that meets the requirements according to the interface protocol of the target platform. This includes setting the correct HTTP method (such as POST or PUT), adding authentication information, setting the correct content type header, etc. After the data is transmitted to the target platform, the target platform receives the data and stores it in the corresponding database according to the predefined rules. Through this step, the service shared data is successfully converted, transmitted, and integrated into the target business platform, realizing cross-platform data sharing and business collaboration, greatly enhancing the interoperability between different platforms, and promoting the efficient circulation and utilization of medical information.

[0082] In this embodiment, by integrating multiple business platforms and deploying multiple business code tables on the SaaS platform, cross-system and cross-platform data processing and sharing are achieved, effectively overcoming the limitations of traditional point-to-point integration and middleware integration methods. First, the business platform and the corresponding business system to which the received business data set belongs are automatically identified, laying a foundation for subsequent data processing and ensuring the accuracy and pertinence of data processing. Second, by converting business data into code items, identifying key business entities, and encoding them to obtain unique identification codes, the standardization and uniqueness of data are realized, effectively solving the problem of inconsistent coding standards between different systems and platforms. This method of unique coding effectively reduces the workload of data conversion and mapping and improves work efficiency. Third, in response to cross-platform instructions, the updated code item group can be flexibly shared as service data and transmitted to the target database of the target business platform, greatly enhancing the data mobility and sharing ability and meeting the increasingly frequent collaboration needs between medical institutions, such as data exchange needs in remote consultation and medical consortium models. In addition, the interface protocol of the target business platform and the type of the target database can be automatically obtained, and the service shared data can be converted into the business data of the target business platform, making the data conversion between different systems and platforms more efficient and greatly reducing the complexity and maintenance cost of system integration. Compared with the traditional point-to-point integration method, this method effectively avoids the problem that the number of interfaces increases exponentially with the increase in the number of systems and platforms, significantly reducing the difficulty and cost of system maintenance. Compared with the middleware integration method, through standardized data processing and data conversion, the performance bottleneck problem caused by the need for middleware to process exponential data exchange is effectively avoided. In summary, this technical solution can not only meet the data sharing needs between multiple information systems within a single medical institution but also support data exchange and business collaboration between different medical institutions. By unifying data standards and data processing mechanisms, information silos are effectively broken, improving data interoperability and utilization efficiency. It effectively promotes the development of medical informatization and improves the quality and efficiency of medical services.

[0083] In one implementation manner of this embodiment, after identifying the key business entities in the code item group and encoding each key business entity to obtain the unique identification code of each key business entity, the following steps are included:

[0084] S210. Respond to the query instruction of the current user and determine the user permission of the current user;

[0085] S220. Identify the sensitive information in the code item group, where the sensitive information includes patient personal identity information, sensitive fields, doctor personal information, and special drug information;

[0086] S230. Perform desensitization processing on the sensitive information to obtain the code item group after desensitization processing;

[0087] S240. Filter the code item group after desensitization processing according to the user's permissions to obtain the code item group after data filtering.

[0088] First, in response to the query instruction of the current user, determine the user's permission level. This can be achieved by checking the user's login credentials (such as username and password), and then query the user permission database or permission management to obtain the specific permission information of this user. Permissions can include data access levels (such as read-only, read-write), data types that can be accessed (such as patient information, medical records, drug information, etc.), and specific function permissions (such as data export, modification, etc.). For example, an ordinary doctor only has the permission to view the information of the patients he is responsible for, while hospital administrators have more extensive data access permissions. The permission information can be temporarily stored in the session for subsequent steps. This step can effectively ensure data security and privacy protection, prevent unauthorized access, and at the same time provide appropriate data access ranges for users of different roles.

[0089] Next, identify the sensitive information in the code item group. The categories and characteristics of sensitive information can be predefined, such as personal identity information such as the patient's ID number, name, address, etc., personal information such as the doctor's practicing certificate number, contact information, and information such as the name and dosage of special drugs. Regular expressions, keyword matching, etc. can be used to scan each field in the code item group to identify sensitive information that conforms to the predefined pattern. For example, a string in the format of "XXXXXX YYYYMMDD ZZZZ" can be identified as an ID number, or certain specific drug names can be identified as controlled drugs to accurately locate all sensitive data that requires special processing and prepare for subsequent desensitization processing, so as to maximize the protection of personal privacy and sensitive information during the data sharing process.

[0090] After identifying the sensitive information, desensitize this information. Desensitization is a data processing technology aimed at reducing the risk of sensitive information leakage while retaining the availability of data. Different desensitization strategies can be adopted according to different types of sensitive information. For the ID number, a partial hiding method can be adopted, such as retaining the first six digits and the last four digits, and replacing the middle with asterisks (such as "123456********1234"). For the name, the first letter can be retained plus asterisks (such as "Zhang*"). For the address information, it can only be retained to the district or street level. For special drug information, the actual name can be replaced with a code. In actual operation, each piece of sensitive information identified before can be traversed and converted according to the preset desensitization rules. For example, converting "Zhang San" to "Zhang*", etc., to greatly reduce the risk of sensitive information leakage while ensuring the data analysis and usage value, and enhancing the security of data sharing.

[0091] Finally, according to the determined user permissions, data filtering is performed on the desensitized code item group. The user's permission information can be compared with each data item, and only the data that the user has the right to access is returned. Multiple dimensions of filtering can be involved, such as data type, data ownership range, data sensitivity, etc. For example, for a doctor who is only responsible for a certain department, only the relevant information of the patients in that department can be returned, while hiding the data of other departments. For a pharmacy administrator, only the information related to drugs can be returned, without showing specific patient information. In actual operation, the WHERE clause of a database query language (such as SQL) can be used to implement data filtering, or conditional statements of a programming language can be used at the application level to filter data, further refining data access control to ensure that each user can only see the information within their permission scope, protecting data security while facilitating users to efficiently obtain the required information.

[0092] Through user permission management, sensitive information identification, data desensitization, and permission filtering, this embodiment maximally protects personal privacy and sensitive information while ensuring data availability, effectively preventing data leakage and unauthorized access, and at the same time supporting the differentiated data requirements of users with different roles.

[0093] In one implementation of this embodiment, the SaaS platform is also deployed with a central policy library, which stores data access rules. The data access rules include user roles and access control policies. Data filtering is performed on the desensitized code item group according to user permissions to obtain a data-filtered code item group, including the following steps:

[0094] S310. According to user permissions, determine the user role of the current user, and determine the access context information of the user role. The access context information includes the current time, geographical location, and network environment;

[0095] S320. Through the access context information, determine the access control policy corresponding to the user role in the central policy library;

[0096] S330. Through the access control policy, determine the visible code items of the current user in the code item group;

[0097] S340. When the user role is a tenant role, determine the shared data fields in the visible code items according to the preset cross-tenant access protocol;

[0098] S350. When the user role is not a tenant role, use the visible code items as the shared data fields;

[0099] S360. Transfer the shared data fields to the preset visible code item group to obtain a data-filtered code item group.

[0100] Based on the user's permissions, determine the user role of the current user and determine the access context information of the user role. The access context information includes the current time, geographical location, and network environment. First, when the user logs in to the SaaS platform, the identity can be verified through methods such as username and password, two-factor authentication, or single sign-on. After successful verification, the user database can be queried to obtain the role information of the user, such as administrator, ordinary user, visitor, etc. The user role defines the basic set of permissions of the user in [the system]. At the same time, collect the user's access context information in real time. The current time can be obtained through the server clock, accurate to the second; the geographical location can be obtained through IP address resolution or GPS data (such as for mobile devices); the network environment can be determined by analyzing the user's IP address, VPN usage, network connection type (such as corporate intranet, public Wi-Fi), etc. For example, a doctor can log in using the hospital intranet IP at 9 am on a working day. The following information can be recorded: the user role is "doctor", the current time is "2024-04-15 09:00:23", the geographical location is "hospital building", and the network environment is "hospital intranet".

[0101] Based on the access context information, determine the access control policy corresponding to the user role in the central policy library. Specifically, the central policy library is a complex rule database that stores various fine-grained access control policies. The access control policy is not only based on the user role but also takes into account factors such as time, location, and network environment. In specific implementation, a rule engine can be used, which can retrieve and evaluate a large number of complex policy rules. When a request containing the user role and access context information is received, the rule engine traverses the policy library to find all applicable policies. These policies can include time-based access restrictions (such as only allowing access during working hours), location-based controls (such as only allowing access to sensitive data at specific locations), network environment-based rules (such as prohibiting access to certain data through public networks), etc. For example, for the doctor user mentioned above, the following policies can be matched: 1) Allow access to patient records from 8:00 to 18:00 on working days; 2) Only allow access to complete patient information from the hospital network; 3) When accessing from other networks, hide the patient's personal identification information. The rule engine can evaluate these policies. Considering that the user is accessing during working hours and using the hospital network, full data access permissions will be granted. This step can dynamically determine the applicable access control policy according to real-time situations, enabling maximizing data availability while ensuring data security, not only improving the level of data protection but also meeting flexible access requirements in different scenarios, such as special authorizations in emergency situations.

[0102] Determine the visible code items of the current user in the code item group through the access control policy, so as to apply the determined access control policy to specific data items and achieve access control at the field level. First, the access control policy can be parsed and converted into a series of specific data access rules. These rules define the data types, specific fields that users can access, and access conditions. Then, traverse each data item in the code item group and apply these rules to each field. For example, assume that the code item group contains a patient's personal information, medical records, and billing information. For an ordinary doctor user, the access control policy can allow them to view the patient's basic information and medical records, but restrict access to detailed financial information. In this case, fields such as patient name, age, diagnosis results, etc. can be marked as visible, while fields such as billing amount, payment method, etc. can be marked as invisible. In addition, the timeliness and relevance of the data can also be considered. For example, a doctor can only view the patients they are responsible for or recent medical records, and cannot access the patient information or historical records of other doctors, so as to generate a precisely filtered data view to ensure that users can only see the data items they have the right to access. This fine-grained control not only protects sensitive information, but also provides the most relevant data according to the specific work needs of users, improving work efficiency.

[0103] In the case where the user role is a tenant role, determine the shared data fields in the visible code items according to the preset cross-tenant access protocol to achieve secure and controllable data sharing in a multi-tenant SaaS environment. First, check whether the user's role is a tenant role. A tenant role indicates that the user accesses on behalf of an organization or company. If it is confirmed that the user has a tenant role, then call the predefined cross-tenant access protocol. The cross-tenant access protocol is a series of complex rule sets that define the data types that can be shared between different tenants, sharing conditions, and the processing of shared data. During the implementation process, first traverse the visible code items determined in the previous steps and match each data field with the cross-tenant access protocol. The matching process takes into account multiple factors, including data sensitivity, sharing purpose, legal compliance requirements, etc. For example, in a medical SaaS platform, a hospital (as a tenant) needs to share certain patient data with a research institution for medical research. In this case, according to the preset protocol, anonymized diagnostic results and treatment effect data can be allowed to be shared, but the patient's personally identifiable information will be filtered out. Specifically, if the visible code item contains the patient's name, age, diagnostic results, and treatment plan, the diagnostic results and treatment plan can be marked as shareable fields, while the name and age can be marked as non-shareable. In addition, factors such as the time range of the data and data volume limits will also be considered to ensure that the sharing complies with the protocol regulations. This step enables effective data collaboration between different organizations while protecting data privacy and security. It allows the SaaS platform to support a wider range of data application scenarios, such as cross-institutional research, industry benchmark comparison, etc., while strictly controlling data flow and preventing unauthorized data leakage.

[0104] In the case where the user role is not a tenant role, the visible code items are used as shared data fields to handle data access requests for individual users or users of a non-tenant nature. When it is determined that the user does not belong to the tenant role, first, the role type of the user is checked to confirm that they are not a tenant user representing an organization or company, applicable to individual users, temporary visitors, or administrators for specific functions. In this case, the visible code items can be directly used as the data fields that the user can access and share, without the need for additional cross-tenant data sharing rules. It should be noted that the data access scope of non-tenant users has been fully restricted and defined in the previous permission control and data filtering steps. For example, assume that a registered user (not a doctor or hospital employee) of a medical consultation platform accesses. According to the previous permission settings, the user can only see their own personal information, appointment records, and publicly available health information. In this case, the visible data items are directly marked as shareable data fields without considering cross-tenant data sharing rules, effectively simplifying the data access process for non-tenant users and improving the processing efficiency. At the same time, it effectively ensures that the data access permissions of individual users are strictly controlled and can only view and use data within the preset scope. It not only protects user privacy but also meets the diverse needs of different types of users, enabling flexible response to various user roles and access scenarios.

[0105] Transfer the shared data fields to a preset group of visible code items to obtain a code item group after data filtering, so as to finally organize and encapsulate the sharable data fields to form a strictly filtered data set. First, a new data structure called "visible code item group" can be created to store all data items after permission checking and data filtering. Then, traverse the previously determined shared data fields and transfer each field to this new data structure one by one. During the transfer process, the following steps can be executed: 1) Data format conversion: Ensure that all data conforms to the predefined format standard for subsequent processing and display. 2) Metadata addition: Add necessary metadata to each data field, such as data source, last update time, access permission level, etc., which helps in data tracking and management. 3) Data consistency check: Ensure that the transferred data is consistent with the original data to avoid data errors or losses during the filtering process. 4) Access log recording: Record the access situation of each data field, including access time, access user, access purpose, etc., for subsequent auditing and analysis. For example, assume the original data contains the patient's name, age, diagnosis result, and treatment plan. After the previous steps, it is determined that only the diagnosis result and treatment plan can be shared. In this step, a new data structure will be created that only contains these two fields, and corresponding metadata will be added, such as "Data desensitization level: high", "Last update time: 2024-04-15 10:30:00", etc. Finally, a strictly filtered, uniformly formatted, and metadata-containing final data set can be generated.

[0106] In this embodiment, first, through user authentication and context information collection, a detailed background is established for each data access request; then, a central policy library is used for dynamic access control policy matching to ensure that data access permissions are adjusted according to real-time situations; next, visible data items are accurately screened in the code item group to achieve field-level access control; for tenant users, a preset cross-tenant access protocol is used to determine the shared data scope, while for non-tenant users, visible code items are directly used; finally, the filtered data is transferred to a unified visible code item group, necessary metadata is added, and format standardization is performed. This not only greatly improves the data security and privacy protection level but also achieves a high degree of flexibility and traceability in data access. It enables the SaaS platform to maximize the value and availability of data while protecting sensitive information, supporting complex multi-tenant environments and diverse data sharing requirements.

[0107] In one implementation of this embodiment, the cross-tenant access protocol includes a protocol framework, an access control matrix, a policy engine, and a data sandbox environment;

[0108] Among them, the protocol framework is used to define the tenant scenarios of the cross-tenant access protocol, the access control matrix is used to define the access rights of the current user according to the levels of visible code items and tenant roles, the policy engine is used to execute the access control policy, and the data sandbox environment is used to provide an isolated data processing space.

[0109] In this embodiment, the cross-tenant access protocol further includes a data classification system, a consent mechanism, a data tracking system, data usage restrictions, a secure transmission protocol, a violation handling mechanism, standard APIs and interface specifications, an identity authentication system, and a version control system;

[0110] Among them, the data classification system is used to classify visible code items into different levels, the consent mechanism is used to define the access rights of visible code, the data tracking system is used to record the logs of cross-tenant data access, the data usage restrictions are used to define the specific usage rules of visible code items, the secure transmission protocol is used to ensure the security of data transmission, the violation handling mechanism is used to identify violation behaviors, the standard APIs and interface specifications are used to define the rules for multi-tenant data exchange, the identity authentication system is used to verify tenant identities, and the version control system is used to track the updates of data access rules.

[0111] The cross-tenant access protocol of this embodiment is used to manage and control data access in a multi-tenant environment. The core components of this protocol include a protocol framework, an access control matrix, a policy engine, and a data sandbox environment. The protocol framework defines the applicable tenant scenarios, such as data sharing between different medical institutions or information exchange across departments. Figure 3 The figure shows a schematic diagram of an access control matrix provided by an embodiment of the present application, as Figure 3 shown, the access control matrix is a two-dimensional table, the horizontal axis represents different tenant roles (such as administrator, ordinary user, visitor, etc.), and the vertical axis represents different levels of visible code items (such as public, internal, confidential, etc.). Each cell of the matrix defines the access rights of a specific role to data at a specific level, such as read, modify, or no permission. The policy engine is the executor of the protocol, and it determines whether to allow a specific access request according to the access control matrix and other rules. The data sandbox environment provides an isolated virtual space that allows tenants to process and analyze data without affecting the original data.

[0112] Specifically, Figure 3 the title of is "Access Control Matrix", the X-axis represents from "low-permission role" to "high-permission role", the Y-axis represents from "low-sensitivity data" to "high-sensitivity data", and the four quadrants represent different types of data: the first quadrant represents internal data, the second quadrant represents confidential data, the third quadrant represents public data, and the fourth quadrant represents restricted data.

[0113] Figure 3The dots in it represent the access rights of different roles to data with different sensitivities. Among them, the visitor is located at the lower left of the chart, indicating low - level access to low - sensitivity data; the ordinary user 1 is located at the lower middle, indicating medium - level access to low - sensitivity data; the ordinary user 2 is located in the middle, indicating medium - level access to medium - sensitivity data; the administrator 1 is located at the lower right, indicating high - level access to low - sensitivity data; the administrator 2 is located slightly above the right side, indicating high - level access to relatively high - sensitivity data; the administrator 3 is located at the upper right, indicating high - level access to high - sensitivity data.

[0114] Figure 3 It intuitively shows the access rights of different roles (from visitors to administrators) to data with different sensitivities, indicating that the rights increase with the improvement of the role and the increase of data sensitivity. Administrators have the highest access rights and can access all levels of data including confidential data, while visitors have the lowest access rights, limited to publicly available data with low sensitivity.

[0115] To further enhance the function and security of the protocol, multiple auxiliary components are also included. The data classification system adopts a multi - level classification method to divide visible code items into different sensitivity levels, such as public, internal, confidential, and top - secret. The consent mechanism requires the data owner to explicitly authorize other tenants to access specific data, which can be achieved through electronic forms or smart contracts. The data tracking system records detailed logs of all cross - tenant data accesses, including access time, visitor identity, accessed data items, etc., facilitating subsequent auditing and problem tracing. The data usage restrictions define specific usage rules for visible code items, such as data retention periods, allowed operation types, etc. The secure transmission protocol uses algorithms such as the Advanced Encryption Standard (AES) to ensure the security of data during transmission. The violation handling mechanism identifies potential violations, such as abnormal access patterns or data leakage attempts, through real - time monitoring and intelligent analysis, and triggers corresponding alarms or automatic defense measures. The standard API and interface specifications ensure interoperability between different tenant systems, defining the format, protocol, and process of data exchange. The identity authentication system uses multi - factor authentication, such as passwords, biometrics, and tokens, to verify tenant identities. The version control system tracks and manages all changes to data access rules, supporting rollback and auditing.

[0116] In practical applications, the cross-tenant access protocol can operate as follows: Suppose there is a patient data sharing platform across hospitals. Hospital A (tenant 1) needs to access the medical record data of a certain patient in Hospital B (tenant 2). First, a user in Hospital A (such as the attending physician) logs in to the platform through the identity authentication system. The platform determines that the user has the right to access the medical record data (assuming it is an internal level) according to the access control matrix. Then, the consent mechanism checks whether the patient has authorized the sharing of their data. If all conditions are met, the policy engine will allow the access request. The data will be transmitted from Hospital B to a data sandbox environment created for the users in Hospital A through a secure transmission protocol. In the sandbox, the doctor can view and analyze the data, but cannot take the original data out of the sandbox. All operations will be recorded by the data tracking system. If the doctor attempts to access unauthorized data (such as the records of other patients), the violation handling mechanism will immediately block and record the behavior.

[0117] This embodiment can significantly improve the security and controllability of data sharing, reduce the risks of data leakage and abuse. At the same time, it can promote data collaboration among different organizations. For example, medical research institutions can more easily obtain anonymized clinical data for analysis. Moreover, it can improve the transparency of data usage. All access behaviors are traceable, which helps to comply with data protection regulations. In addition, through standardized APIs and interfaces, the integration between different systems is effectively simplified, and the overall interoperability is improved. Finally, the flexible access control and version management enable the protocol to be quickly adjusted as the requirements change, maintaining the long-term applicability of the platform. Generally speaking, the cross-tenant access protocol balances the needs of data sharing and the requirements of privacy protection, not only ensuring the security and privacy of data, but also promoting the maximization of data value.

[0118] In one implementation of this embodiment, the central policy repository also stores a regular expression library, which identifies the key business entities in the code item group and encodes each key business entity to obtain the unique identification code of each key business entity, including the following steps:

[0119] S510. Use the regular expressions in the regular expression library to identify the shared data fields to obtain the key business entities;

[0120] S520. Use the preset business code table to encode each key business entity to obtain the unique identification code of each key business entity.

[0121] First, use regular expressions to identify key business entities from the shared data fields. Regular expressions are an expression language for describing string patterns. They can flexibly define complex text patterns and quickly find content that matches the pattern in a large amount of text. In this step, the regular expression library acts as a predefined set of patterns, and each expression is designed for a specific type of business entity.

[0122] In specific implementation, it is first necessary to construct a comprehensive regular expression library. This library contains patterns for various common business entities, such as ID numbers, bank card numbers, phone numbers, email addresses, etc. Each business entity has its specific format and rules, and regular expressions can cover all possible valid formats while excluding invalid formats.

[0123] In practical applications, each item in the shared data fields can be traversed, and each expression in the regular expression library is used for matching. When a match is found, the field is marked as the corresponding business entity type. For example, if a field matches the regular expression for an email address, then the field is identified as a key business entity of the "email address" type.

[0124] After that, encode each key business entity using a preset business code table to obtain a unique identification code for each key business entity.

[0125] The business code table predefines various business entity types and their corresponding encoding rules. In specific implementation, the business code table includes all possible key business entity types and assigns a unique prefix or encoding pattern to each type. For example, the prefix "ID" can be assigned to ID numbers, the prefix "BC" to bank card numbers, the prefix "TEL" to phone numbers, etc. The encoding rules can include a fixed-length sequence of numbers, alphanumeric combinations, or strings generated by more complex algorithms.

[0126] In the specific encoding process, each identified key business entity can be traversed, the corresponding encoding rule can be found according to its type, and then a unique identification code is generated. For example, if an entity identified as an ID number is traversed, an identification code in the form of "ID12345678" can be generated, where "ID" represents the ID type and "12345678" is obtained by processing the original ID number through a hash function.

[0127] To ensure the uniqueness of the identification code, it is necessary to maintain a database of used identification codes. Each time a new identification code is generated, it is necessary to check whether it already exists. If it exists, it needs to be regenerated.

[0128] In this embodiment, first, precise entity recognition is performed using a regular expression library, ensuring that key business data can be accurately captured without missing important information, effectively improving the efficiency and accuracy of data processing. Second, encoding is performed through a standardized business code table to achieve unified representation of data, which not only protects the privacy of the original data but also retains the business meaning of the data, facilitating data analysis, data exchange, and cross-integration. It effectively improves the efficiency and security of data management.

[0129] In one implementation of this embodiment, encoding the unique identification code into the corresponding code item to obtain an updated code item group includes the following steps:

[0130] S610. Traverse the code item group to obtain multiple key business entities;

[0131] S620. For each key business entity, in the code item corresponding to the key business entity, embed the unique identification code into the comment field of the code item to obtain an updated code item;

[0132] S630. Use the code item group containing all the updated code items as the updated code item group.

[0133] First, traverse the code item group to obtain multiple key business entities to comprehensively scan and analyze the code item group to identify and extract all the key business entities contained therein. The code item group is a set containing multiple code items, and each code item represents a piece of program code, configuration information, or other structured data.

[0134] In specific implementation, it is first necessary to determine the traversal strategy. Algorithms such as depth-first search (DFS) or breadth-first search (BFS) can be used to ensure that no code item is missed. During the traversal process, each code item is parsed and analyzed. For example, different file formats (such as XML, JSON, or custom formats) can be parsed.

[0135] When parsing each code item, predefined rules or pattern recognition can be applied to identify key business entities. The predefined rules can be keyword matching algorithms. For example, if field names such as "customerID", "accountNumber", or "socialSecurityNumber" are found in a code item, they can be marked as potential key business entities.

[0136] After that, for each key business entity, in the code item corresponding to the key business entity, embed the unique identification code into the comment field of the code item to obtain the updated code item, so as to associate the generated unique identification code with the corresponding key business entity, and embed the unique identification code into the code item in a way that does not affect the original code structure. In this embodiment, the comment field of the code item is used to store the unique identification code because the comment field usually does not affect the execution of the code and can provide enough space to store additional metadata.

[0137] During specific implementation, the specific position of each key business entity in the original code item can be located to accurately find the position where the comment is to be inserted.

[0138] When inserting the unique identification code, if there is an existing comment in the code item, the new identification information needs to be added in a way that does not damage the existing comment content. A specific format or marker can be used to distinguish the newly added identification information, such as using a prefix or encapsulating the information in a specific marker. If there is no existing comment in the code item, a new comment field needs to be created to accommodate the identification information.

[0139] To ensure the consistency and traceability of the insertion process, these embedded identification information can be represented in a standardized format. For example, a format like " <!-- ENTITY_ID: [unique identification code] -->" can be used.

[0140] During implementation, special attention needs to be paid to maintaining the readability and original structure of the code. Inserting comments should not damage the indentation, line breaks or other format features of the code.

[0141] This step not only retains the functions and structures of the original code, but also adds additional metadata, providing convenience for subsequent data tracking, security auditing and compliance management. In this way, a unique and traceable identifier can be established for each key business entity without affecting the code execution.

[0142] Finally, take the code item group containing all the updated code items as the updated code item group to integrate all the processed and updated code items and form a new code item group. The new code item group contains all the original code content and also contains the newly added unique identification code information.

[0143] During specific implementation, the new code item group can be stored in the following ways: 1. Create a new code item group: Generate a completely new code item group structure to completely replace the original code item group. 2. In-place update: Directly update each code item in the original code item group structure. 3. Incremental update: Only store the changed code items and retain references to the original unchanged parts.

[0144] In this embodiment, first, by comprehensively traversing the code item group, all key business entities are accurately identified, laying a foundation for subsequent processing. Second, by embedding the unique identification code into the comment field of the code item, the standardized identification of key business entities is achieved while maintaining the original structure and function of the code. Finally, by integrating all the updated code items, a new code item group is formed, which not only improves the traceability of data and management efficiency but also provides a basis for subsequent data analysis.

[0145] In one implementation of this embodiment, according to the database type and interface protocol, the service shared data is converted into the business data of the target business platform, including the following steps:

[0146] S710. Determine the transmission method and data format of the target business platform according to the interface protocol;

[0147] S720. Determine the data structure, syntax characteristics, and storage structure of the target database according to the database type;

[0148] S730. Obtain all field information of the service shared data, and determine the mapping rules corresponding to the field information according to the syntax characteristics. The field information includes the field name and data type;

[0149] S740. Create a configuration file in JSON format according to the mapping rules, data format, data structure, and storage structure;

[0150] S750. Use a preset mapping engine to read and parse the JSON format configuration file to generate data conversion logic;

[0151] S760. Use the data conversion logic to convert the service shared data into the business data of the target business platform.

[0152] First, according to the interface protocol, determine the transmission method and data format of the target business platform. The supported transmission protocols, such as HTTP, HTTPS, FTP, or proprietary protocols, can be determined through the interface document of the interface protocol. The data format can be determined by the interface protocol. The data format is the data structure accepted by the target platform, including JSON, XML, CSV, etc. The data format used in this embodiment is JSON. In specific implementation, a configuration object or file can be created to store this information. For example, for a REST API that uses the HTTPS protocol and accepts JSON format data, the configuration reference is Figure 4The following pseudocode describes the basic structure and parameters of an API request. In the pseudocode, the first line lists the main features of the API request, namely using the HTTPS protocol, the POST method, and the data format being JSON. The "begin... end" block defines the HTTP request headers: ""Content-Type":"application / json"" to specify that the content type of the request body is JSON. ""Authorization":"Bearer {token}"" is used to specify authentication using a Bearer token. When facing different target platforms, only the configuration file needs to be adjusted without modifying the core code logic. This not only simplifies platform maintenance but also greatly improves the adaptation efficiency for new platforms.

[0153] After that, according to the database type, determine the data structure, syntax features, and storage structure of the target database. First, according to the database type (such as MySQL, Oracle, PostgreSQL, etc.), determine the set of data types it supports. For example, MySQL supports types such as INT, VARCHAR, DATETIME, etc., while Oracle supports types such as NUMBER, VARCHAR2, DATE, etc. Second, determine the syntax features unique to each database, such as the AUTO_INCREMENT in MySQL, the SEQUENCE in Oracle, etc., for implementing self-incrementing primary keys, as well as the syntax differences in aspects such as indexes, constraints, and stored procedures in different databases.

[0154] In addition, the storage structure of the target database needs to be considered, including tablespace design, partitioning strategy, index organization, etc. For example, for large tables, partitioning storage needs to be considered to improve query efficiency; for frequently accessed columns, indexes need to be created.

[0155] During implementation, a database feature mapping table can be created, such as Figure 5As shown, this pseudocode is for the configuration of a MySQL database. dataTypes defines the corresponding representations of common data types in MySQL, that is, the integer type uses INT, the string type uses a variable-length string with a maximum length of 255, and the date and time type uses DATETIME; syntaxFeatures describes the unique syntax features of MySQL, that is, defining columns for auto-increment, the syntax for defining primary keys, and the basic syntax for defining foreign keys; storageStructure defines storage-related settings, that is, using InnoDB as the default storage engine, using the utf8mb4 character set, supporting the full range of Unicode, including emojis, and using utf8mb4_unicode_ci as the collation, which is a case-insensitive Unicode collation.

[0156] By clarifying the characteristics of the target database, it can be ensured that the generated SQL statements and data structures fully meet the requirements of the target database, avoiding errors caused by database differences. At the same time, the structured feature description also provides a basis for automated data migration and cross-database application development, enhancing the portability and scalability of the platform.

[0157] After that, all field information of the service shared data is obtained, and the mapping rules corresponding to the field information are determined according to the syntax features. The field information includes field names and data types. First, it is necessary to traverse all fields of the service shared data, extract the name and data type of each field, which can be achieved by parsing the data dictionary and metadata table. For each field, information such as its name and original data type needs to be recorded. Then, based on the determined syntax features of the target database, corresponding mapping rules are formulated for each source field. This includes the mapping of field names and the conversion of data types.

[0158] For example, for a source table named "user_info", its mapping rules are as Figure 6 shown. This pseudocode defines the correspondence between the source table and the target table, including the mapping of table names and fields. Specifically, the fields array defines the mapping relationships of each field, including the mapping of three fields. For example, for the first field mapping (user_id), map name to "USER_ID", map type to "NUMBER", and add primary key and not-null constraints.

[0159] According to the mapping rules, data format, data structure, and storage structure, a JSON-formatted configuration file is created to integrate into a unified and structured configuration file. Since the JSON format has good readability, is easy to parse, and is widely supported in various programming languages and tools, it is selected as the format of the configuration file.

[0160] The process of creating a configuration file is as follows: First, define a top-level structure that includes target platform information, database information, and field mapping rules. In the target platform information section, it includes the previously determined transmission method and data format. The database information section contains the database type, syntax features, and storage structure. The field mapping rules section details the source information and target information for each field. A complete configuration file structure is as Figure 7 shown. In this pseudocode, the targetPlatform section defines the configuration of the target API, the targetDatabase section describes the configuration of the target database, and the dataMapping array defines the data mapping rules, including the mappings of multiple tables.

[0161] Use a preset mapping engine to read and parse the JSON-formatted configuration file to generate data conversion logic. The mapping engine can interpret the JSON configuration file and generate specific data conversion logic based on it. Specifically, the mapping engine needs to have a JSON parser that can read and deconstruct the configuration file. It can be implemented using standard JSON libraries such as Jackson in Java, the json module in Python, etc. During the parsing process, the mapping engine needs to verify whether the structure of the configuration file is complete and whether it conforms to the predefined schema to ensure that all necessary information has been provided. Secondly, the mapping engine needs to construct an internal data structure or object model based on the parsed configuration information, and the object model is used for subsequent generation of conversion logic. For example, a Table object can be created for each table, and a Field object can be created for each field, and these objects contain all the relevant information of the source data and target data.

[0162] Then, the mapping engine needs to generate specific conversion logic based on these object models. This involves generating SQL statements (for database operations) or data processing code (for data conversion in memory). For SQL generation, the characteristics of the target database can be considered, such as syntax differences, data type mappings, etc. For data processing in memory, corresponding program code or scripts can be generated.

[0163] For example, for the Figure 7 configuration file shown, the mapping engine can generate Oracle SQL statements as shown in Figure 8 . This pseudocode is used to create tables, create sequences, and insert data. Specifically, first define the table structure to create a table for storing user information; an auto-incrementing primary key, use a sequence to ensure that USER_ID is unique and auto-increments; a data insertion template that provides a reusable insertion statement for convenient batch data insertion or single data insertion through an application; data type conversion to correctly convert the input date string to the Oracle DATE type.

[0164] Meanwhile, the engine can also generate corresponding data processing logic, such as Figure 9 As shown, this pseudocode is used to convert the source data format to the target data format. Specifically, first, data mapping is performed to map the field names of the source system to the field names of the target system; then data conversion is carried out; and then data cleaning and standardization are performed to ensure that the data conforms to the naming conventions and format requirements of the target system. This embodiment can achieve the separation of configuration and logic, making the data conversion process more flexible and maintainable. When the conversion rules need to be modified, only the configuration file needs to be updated, without modifying the code. Secondly, complex conversion scenarios can be processed, including field renaming, data type conversion, complex data conversion functions, etc. Moreover, since the conversion logic is dynamically generated, it can easily adapt to different source data structures and target databases, improving the versatility and scalability of the platform.

[0165] The data conversion logic is used to convert the service shared data into the business data of the target business platform. When using the preset mapping engine to read and parse the JSON format configuration file, the first step is to ensure that the mapping engine has the ability to parse JSON. The engine uses a JSON parsing library to read each element in the configuration file according to the structure of the file. During parsing, first, the top-level structure is read, which includes general transmission and format setting information, such as transmission protocols, data formats, etc., and then it delves into the database level to obtain information about the database type, syntax characteristics, and storage structure.

[0166] The engine also needs to parse the field mapping part in the configuration in detail. Each field involves detailed information about the source and target, including data types and conversion rules. After parsing, this information will be stored in an internal data model for subsequent use. For example, the configuration file can contain an item on how to convert from the INT type to the NUMBER type of the target platform, and the parsed mapping rules can be converted into corresponding database operation and business logic rules. In this way, it is ensured that complex data conversion rules can be achieved through JSON configuration without additional code, achieving the purpose of flexibility and maintainability.

[0167] The implementation method of using the mapping engine to parse the configuration file not only ensures the standardization of data processing logic but also provides an efficient configuration management mechanism. When the business requirements change, only the JSON configuration file needs to be updated, without changing the code, achieving a quick response. By simply adjusting the configuration, the requirement changes can be completed, reducing the development and testing time and improving the business adaptability.

[0168] The logic generated by the mapping engine can be divided into two parts: one is the logic for interacting with the data source, which is used to extract and preliminarily process data from the source to ensure that the data is in a near-final form when it enters the transformation process. The other is a series of data transformation operations, which guide specific field transformations according to the rules in the configuration file. For example, converting a date from a string format to the standard date format required by the target platform, or reformatting text data according to the requirements of the target database.

[0169] In this embodiment, the generation of the transformation logic not only includes simple conversions of data types, but also can handle data quality problems. For example, strategies for handling missing values and outliers can be explicitly defined in the generated transformation logic, including setting default values, correcting formats, etc. This not only improves data consistency, but also prevents errors from spreading to the business platform. By means of code generation, the possibility of human errors is reduced, and the business logic is decoupled from the development details, improving code reusability and processing efficiency.

[0170] After generating the data transformation logic, the data transformation logic can be used to transform the service shared data into the business data of the target business platform.

[0171] This embodiment makes the docking between different data sources and the target business platform simpler through a standardized JSON configuration file and a flexible transformation logic generation mechanism, greatly reducing the pressure of manually writing data transformation logic. At the same time, it makes the entire data integration process transparent and traceable, which helps to improve the agility of the business and the ability to quickly respond to environmental changes.

[0172] In one implementation of this embodiment, after using the data transformation logic to transform the service shared data into the business data of the target business platform, the following steps are included:

[0173] S810. Transmit the business data to the target business platform by means of transmission so that the business data is stored in the target database of the target business platform.

[0174] First, according to the transmission method, select the corresponding network protocol and transmission technology. The transmission methods can include HTTP / HTTPS, FTP, SFTP, WebSocket or a custom TCP / IP protocol. For example, if high real-time data transmission is required, WebSocket can be selected; if high security requirements are required, HTTPS or SFTP can be used.

[0175] In the actual transmission process, the size and transmission frequency of the data need to be considered. For scenarios with a large amount of data or frequent transmissions, batch transmission or streaming transmission methods can be used to reduce network load and improve transmission efficiency. For example, a large amount of data can be divided into multiple small pieces, transmitted piece by piece, and recombined at the receiving end.

[0176] In addition, to ensure data consistency and integrity, a transaction management mechanism can be implemented. For example, the entire data transmission and storage process can be wrapped in a transaction, and the transaction is committed only when all operations are successfully completed; otherwise, it is rolled back. This can prevent data inconsistency problems caused by partial operation failures.

[0177] This embodiment establishes a comprehensive and reliable data transmission and storage mechanism, which not only ensures data security and integrity but also improves the efficiency of data transmission and storage.

[0178] In one implementation of this embodiment, the mapping engine includes a JSON parser to read and deconstruct the configuration file.

[0179] The JSON parser in the mapping engine is a key component, whose main function is to read and deconstruct the configuration file, including file I / O operations, string processing, data structure conversion, and error handling, etc.

[0180] JSON (JavaScript Object Notation) is a lightweight data interchange format widely used in configuration files and data transmission. The core task of the JSON parser is to convert the JSON-formatted text into an internal data structure that can be directly used by the program, including three main steps: lexical analysis, syntax analysis, and semantic processing.

[0181] First, in the lexical analysis stage, the JSON parser decomposes the input JSON text into a series of tokens. These tokens may be curly braces, square brackets, colons, commas, or specific data items such as strings, numbers, and boolean values. For example, for the JSON text {"name":"John","age":30}, the parser will identify tokens such as {, "name", :, "John", ,, "age", :, 30,}.

[0182] Next is the syntax analysis stage. In this stage, the parser combines these tokens into meaningful structures according to the JSON syntax rules. It checks whether the parentheses match, whether the key-value pairs are correctly formed, whether the array elements are correctly separated, etc., and the recursive descent parsing method can be used to implement it.

[0183] Finally is the semantic processing stage. In this stage, the parser converts the parsed structure into data types in the programming language. For example, an object in JSON may be converted into a hash table or dictionary, an array will be converted into a list or array, and strings, numbers, and boolean values will be converted into corresponding basic data types.

[0184] In a specific embodiment, assume that there is a configuration file containing data mapping rules, as follows: Figure 10 As shown, this pseudocode defines how to convert source data fields into target data fields, and describes the attributes of the fields and the transformation operations applied. For example, sourceField specifies that the field name in the source data is "customer_name", targetField specifies that the field name in the target data is "name", dataType specifies that the data type of the target field is a string, and sets the maximum length of the target field to 50 characters, etc. The JSON parser will first read this file and then parse it. It will recognize that this is a JSON object containing multiple key-value pairs. The parser will process each key-value pair one by one, extracting the key names such as "sourceField" and "targetField" and their corresponding values. For nested structures, such as the "transformation" object, the parser will recursively parse it.

[0185] After parsing, the above information will be converted into a data structure that can be directly used by the program, such as a mapping rule object as Figure 11 As shown, this pseudocode describes a data mapping rule (MappingRule) for converting and storing the data of the source field into the target field.

[0186] This data structure enables the program to conveniently access and use the configuration information. For example, it can easily obtain information such as the source field name, target field name, and data type, and perform corresponding data conversion operations based on this.

[0187] In this embodiment, by implementing a JSON parser in the mapping engine, the definition and modification of data mapping rules become simple and intuitive, greatly reducing the complexity of system maintenance and update. The use of the JSON format not only provides good readability but also ensures the structuring and standardization of configuration information, which is beneficial for cross-platform and cross-system data exchange.

[0188] The embodiment of this application also provides a service sharing data processing system based on a SaaS platform, including:

[0189] A memory configured to store instructions; and

[0190] A processor configured to call instructions from the memory and be able to implement the above-mentioned service sharing data processing method based on the SaaS platform when executing the instructions.

[0191] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take 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.) that contain computer-usable program code.

[0192] The present application 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 application. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processors of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processors of the computer or other programmable data processing devices generate means for implementing the functions specified in one Figure 1 flow or multiple flows and / or blocks Figure 1 block or multiple blocks.

[0193] 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, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means that implement the functions specified in one Figure 1 flow or multiple flows and / or blocks Figure 1 block or multiple blocks.

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

[0195] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and a memory.

[0196] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). The memory is an example of computer-readable media.

[0197] A computer-readable medium includes permanent and non-permanent, removable and non-removable media that can implement information storage by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer-readable medium does not include transitory computer-readable media, such as modulated data signals and carrier waves.

[0198] It should also be noted that the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article or apparatus comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or apparatus. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising the element.

[0199] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

1. A service sharing data processing method based on a SaaS platform, characterized in that: Applied to a SaaS platform, the SaaS platform integrates multiple business platforms, the SaaS platform deploys n business code tables, n is an integer greater than 2, and each business code table corresponds to a business system, the method includes: In response to receiving the business data set, determining a business platform of the business data set, and based on the business platform, determining a business system corresponding to the business data set; According to the business code table corresponding to the business system, each of the business data in the business data set is converted into a code item to obtain a code item group; Identifying key business entities in the code item group, and encoding each of the key business entities to obtain a unique identification code for each of the key business entities; Encoding the unique identification code into a corresponding code item to obtain an updated code item group; In response to a cross-platform instruction for at least one of the code items in the updated code item group, using at least one of the code items in the updated code item group as service shared data, and determining a target business platform according to the cross-platform instruction, wherein the cross-platform instruction is used to instruct the service shared data to be transmitted to a target database of the target business platform; Acquire the interface protocol of the target service platform and the database type of the target database; The service sharing data is converted into the business data of the target business platform according to the database type and the interface protocol, so that the business data of the target business platform is stored in the target database of the target business platform.

2. The method according to claim 1, characterized in that: After converting each of the business data in the business data set into a code item according to the business code table corresponding to the business system to obtain a code item group, the method includes: In response to a query instruction of a current user, determining user rights of the current user; identifying sensitive information in the code item group, the sensitive information including patient personal identification information, sensitive fields, and physician personal information; Desensitizing the sensitive information to obtain a desensitized code item group; The desensitized code item group is subjected to data filtering according to the user authority to obtain the filtered code item group, wherein the code item group includes a shared data field.

3. The method according to claim 2, characterized in that The SaaS platform is also deployed with a central policy library, which stores data access rules, including user roles and access control policies. The desensitized code item group is filtered according to the user rights to obtain the filtered code item group, including: Determining the user role of the current user according to the user authority, and determining access context information of the user role; Determining, in the central policy repository, an access control policy corresponding to the user role through the access context information; Determining the visible code items of the current user in the code item group by using the access control policy; In the case where the user role is a tenant role, determining a shared data field in the visible code item according to a preset cross-tenant access protocol; In a case where the user role is not the tenant role, using the visible code item as a shared data field; The shared data field is transferred to a preset visible code item group to obtain a code item group after data filtering.

4. The method according to claim 3, characterized in that The cross-tenant access protocol includes a protocol framework, an access control matrix, a policy engine, and a data sandbox environment; Among them, the protocol framework is used to limit the tenant scenarios of the cross-tenant access protocol, the access control matrix is ​​used to define the access rights of the current user according to the level of the visible code item and the tenant role, the policy engine is used to execute the access control policy, and the data sandbox environment is used to provide an isolated data processing space.

5. The method according to claim 3, characterized in that: The central policy library also stores a regular expression library, and the identification of key business entities in the code item group and encoding of each key business entity to obtain a unique identification code for each key business entity includes: Using the regular expression in the regular expression library to identify the shared data field, to obtain a key business entity; Each of the key business entities is encoded using a preset business code table to obtain a unique identification code for each of the key business entities.

6. The method according to claim 1, characterized in that The step of encoding the unique identification code into a corresponding code item to obtain an updated code item group includes: Traversing the code item group to obtain a plurality of key business entities; For each of the key business entities, in a code item corresponding to the key business entity, embedding the unique identification code into a remark field of the code item to obtain an updated code item; A code item group including all the updated code items is taken as an updated code item group.

7. The method according to claim 1, characterized in that The converting the service sharing data into the business data of the target business platform according to the database type and the interface protocol includes: Determine the transmission mode and data format of the target service platform according to the interface protocol; Determining the data structure, grammatical characteristics and storage structure of the target database according to the database type; Acquire all field information of the service shared data, and determine a mapping rule corresponding to the field information according to the grammatical characteristics, wherein the field information includes a field name and a data type; Creating a configuration file in JSON format according to the mapping rule, the data format, the data structure and the storage structure; Using a preset mapping engine to read and parse the configuration file in the JSON format to generate data conversion logic; The data conversion logic is used to convert the service sharing data into the business data of the target business platform.

8. The method according to claim 7, characterized in that After the data conversion logic is used to convert the service sharing data into the business data of the target business platform, the method further comprises: The business data is transmitted to the target business platform using the transmission method, so that the business data is stored in the target database of the target business platform.

9. The method according to claim 7, characterized in that: The mapping engine includes a JSON parser to read and deconstruct the configuration file.

10. A service sharing data processing system based on a SaaS platform, characterized in that: include: a memory configured to store instructions; as well as A processor is configured to call the instructions from the memory and implement the service sharing data processing method based on the SaaS platform according to any one of claims 1 to 9 when executing the instructions.

Images