Service sharing data processing method and system based on SaaS platform

Abstract

The invention discloses a service sharing data processing method and system based on an SaaS platform, and relates to the field of data processing.The method comprises the steps that a service data set is received, and a corresponding service system is determined; converting each piece of business data into a code item according to a 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 to obtain a unique identification code of each key business entity; encoding the unique identification code to the corresponding code item to obtain an updated code item group; in response to the cross-platform instruction, taking at least one code item in the updated code item group as service shared data, and determining a target business platform; obtaining an interface protocol of the target business platform and a database type of a target database; and converting the service shared data into service data of the target service platform according to the database type and the interface protocol. According to the invention, the cross-system and cross-platform data processing efficiency can be effectively improved.

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 needs. Data in the medical industry is diverse, complex and sensitive, involving patient information, medical records, medical imaging, drug management and other aspects. At the same time, there are often multiple independent information systems within medical institutions, such as electronic medical record systems, medical imaging systems, laboratory information systems, etc. These systems were developed by different suppliers at different times, using different technical architectures and data standards, forming information islands. With the continuous deepening and expansion of medical services, collaboration between medical institutions has become increasingly frequent. For example, the rise of models such as remote consultation and medical consortiums has further increased the demand 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 a direct data exchange interface between every two systems and platforms that need to interact. This method is relatively simple to implement, but with the increase in the number of systems and platforms, the number of interfaces increases exponentially, and the maintenance cost is high due to the inconsistency of data formats and encoding standards adopted by different systems and platforms. 2. Middleware integration method: data exchange between different systems and platforms is achieved by introducing middleware. The middleware is responsible for data conversion and routing, reducing the number of direct interfaces. However, with the increase in the number of systems and platforms, and due to the inconsistency of data formats and encoding standards between different systems and platforms, the middleware needs to handle exponential data exchanges, which seriously affects the performance of the device.

[0004] In summary, the above traditional cross-system and cross-platform data processing methods can still cope with the data interaction between a small number of systems. However, with the expansion of the scale of medical institutions and the increase of business complexity, and due to the inconsistency of data formats and coding standards adopted by different systems and platforms, the workload of data conversion and mapping will be greatly increased, greatly reducing work efficiency. Therefore, a method is urgently needed 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 objectives, the embodiments of the present application adopt the following technical solutions: In a first aspect, a service sharing data processing method based on a SaaS platform is provided, which is applied to the SaaS platform, wherein the SaaS platform integrates multiple business platforms, and the SaaS platform deploys n business code tables, where n is an integer greater than 2, and each business code table corresponds to a business system, and 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.

[0007] In a possible implementation manner of the first aspect, 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 further 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.

[0008] In another possible implementation of the first aspect, the SaaS platform is further deployed with a central policy library, the central policy library stores data access rules, the data access rules include user roles and access control policies, and the code item group after the desensitization processing is filtered according to the user rights to obtain the code item group after the data filtering, 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.

[0009] 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; 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.

[0010] In another possible implementation manner of the first aspect, the central policy library further stores a regular expression library, and the 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 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.

[0011] In another possible implementation manner of the first aspect, 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.

[0012] In another possible implementation manner of the first aspect, converting the service sharing data into 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.

[0013] In another possible implementation manner of the first aspect, after the data conversion logic is used to convert the service shared data into the business data of the target business platform, the method includes: 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.

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

[0015] In a second aspect, the present application provides a service sharing data processing system based on a SaaS platform, comprising: a memory configured to store instructions; and The processor is configured to call the instructions from the memory and implement the above-mentioned service sharing data processing method based on the SaaS platform when executing the instructions.

[0016] 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 realized, effectively overcoming the limitations of traditional point-to-point integration and middleware integration methods. First, the business platform and corresponding business system to which the received business data set belongs are automatically identified, laying the foundation for subsequent data processing and ensuring the accuracy and pertinence of data processing. Secondly, by converting business data into code items, identifying key business entities, encoding them, and obtaining 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 unique coding method effectively reduces the workload of data conversion and mapping and improves work efficiency. Thirdly, in response to cross-platform instructions, the updated code item group can be flexibly transmitted as service shared data to the target database of the target business platform, greatly enhancing the liquidity and sharing capabilities of data, and meeting the increasingly frequent collaboration needs between medical institutions, such as the data exchange needs of 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 sharing data can be converted into the business data of the target business platform, making the data conversion between different systems and platforms more efficient, 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, and significantly reduces 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 the 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. Through unified data standards and data processing mechanisms, information islands are effectively broken, and data interoperability and utilization efficiency are improved. It effectively promotes the development of medical informatization and improves the quality and efficiency of medical services.

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

[0018] Figure 1 A flowchart of a service sharing data processing method based on a SaaS platform provided in an embodiment of the present application; Figure 2 An architectural diagram of a SaaS platform provided in an embodiment of the present application; Figure 3 A schematic diagram of an access control matrix provided in an embodiment of the present application; Figure 4A pseudo-code diagram of a REST API configuration using the HTTPS protocol and accepting data in JSON format provided in an embodiment of the present application; Figure 5 A pseudo code diagram of a database characteristic mapping table provided in an embodiment of the present application; Figure 6 A pseudo code diagram of a mapping rule provided in an embodiment of the present application; Figure 7 A pseudo code diagram of a configuration file structure provided in an embodiment of the present application; Figure 8 A schematic diagram of a mapping pseudo code provided in an embodiment of the present application; Fig. 9 A pseudo code diagram of data processing logic provided in an embodiment of the present application; Fig.10 A pseudo code diagram of a data mapping rule provided in an embodiment of the present application; Fig.11 A pseudo code diagram of a mapping rule object provided in an embodiment of the present application. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the specific implementation methods described herein are only used to illustrate and explain the embodiments of the present application, and are not used to limit the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0020] It should be noted that if the embodiments of the present application involve directional indications (such as up, down, left, right, front, back...), such directional indications are only used to explain the relative position relationship, movement status, etc. between the components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0021] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of the present application, the descriptions of "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or suggesting their relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the ability of ordinary technicians in the field to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0022] Figure 1 The following schematically shows a flow chart of a service sharing data processing method based on a SaaS platform according to an embodiment of the present application. Figure 1 As 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. The SaaS platform deploys n business code tables, 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: S110, in response to receiving a 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; 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; S130, identifying 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; S140, encoding the unique identification code into the corresponding code item to obtain an updated code item group; S150, in response to a cross-platform instruction for at least one code item in the updated code item group, using at least one code item 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; S160, obtaining the interface protocol of the target business platform and the database type of the target database; S170. Convert the service sharing data into 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.

[0023] The business platform in this embodiment can be a platform, a service entity or a system. Figure 2The architecture diagram of a SaaS platform provided in the embodiment of the present application is shown. Figure 2 , multiple business platforms receive data from the SaaS platform. Each business platform includes a target database for storing 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, and the data conversion module is used to process steps S150 to S170.

[0024] In actual implementation, the SaaS platform first receives data sets from various business platforms. Business platforms may include electronic medical record systems, drug management systems, etc., and business data sets may 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 set, the platform can determine the business platform to which it belongs by analyzing the structure, format, or metadata of the business data set. For example, if a business data set contains patient diagnosis information and prescription data, it is identified as coming from an electronic medical record system.

[0025] After determining the business platform, the platform will further analyze the data content and determine the specific business system corresponding to the business data set in combination with pre-defined business rules. The business system includes the outpatient business system, the inpatient business system, the electronic medical record business system, the drug management business system, etc. For example, the business data set belongs to the outpatient business system. In the specific implementation, it can be achieved through keyword recognition. If keywords related to outpatient clinics are identified, the business data set is divided 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 keyword matching.

[0026] After determining the business system, the business code table corresponding to the business system can be obtained, and the business code table can be converted into standardized code items. Specifically, the corresponding business code table can be called according to the business system. Each business code table is pre-defined and contains all possible data items in the business system and their corresponding standard codes. During the conversion process, the platform will process each data item in the business data set one by one. For each data item, the platform will search for matching items in the corresponding business code table and convert it into a standard code item containing 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: code "J00", name "cold", pinyin code "GM", and remarks contain the ICD-10 classification information of the disease. Fuzzy matching algorithms 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 nearest neighbor matching or request manual intervention. Through standardized conversion, data can be converted into a unified code item format, which improves the consistency and comparability of data.

[0027] In the healthcare field, patients, doctors, and drugs are considered core business entities, i.e., key business entities. The identification process first traverses the code item group and determines whether each code item belongs to a key business entity through preset rules or machine learning models. For example, the platform may look at the coding prefix or name features 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 unique identification code can be generated using a combination of UUID (universal unique identifier), a timestamp plus a random number, or a hash value based on entity features. For patients, the unique identification code can be generated in combination with the patient's identity information, date of birth, etc.; for doctors, it can be generated using their employee number or physician practice certificate number; for drugs, it can be generated based on 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, which improves the consistency and traceability of data.

[0028] After obtaining the unique identification code, the unique identification code is encoded into the corresponding code item, so as to add an identifier that can uniquely identify the key business entity across platforms and 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 code items related to each key business entity in the code item group. For each related code item, the platform will add a new field to its structure to store the unique identification code. For example, for patient-related code items (such as basic information of patients, medical records, etc.), the platform will add the patient's unique identification code to these code items. Similarly, for doctor-related code items (such as basic information of doctors, medical records, etc.) and drug-related code items (such as drug information, prescription records, etc.), corresponding unique identification codes will also be added respectively. In this way, each code item not only contains its original code, name, pinyin code and remarks information, but also adds a unique identifier that can be recognized across platforms, greatly improving the relevance and traceability of the data, making it easier to identify and associate different data items of the same entity in subsequent data processing, analysis and sharing, thereby supporting more complex data operations and business processes.

[0029] The platform responds to receiving cross-platform instructions, which come from user operations, preset business rules triggers, or API calls from other platforms. The cross-platform instructions contain the data range that needs to be shared and the information of the target business platform. The platform can select the corresponding code item 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 item is marked as service shared data. At the same time, the platform will parse the target platform information in the cross-platform instruction to determine which database of which business platform the data needs to be transferred to. In the specific implementation, the pre-configured platform mapping table in the platform can be queried to obtain detailed information of the target platform. For example, if the instruction indicates that the examination results of a 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 database information corresponding to the platform.

[0030] 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 library, which stores detailed technical parameters of all known business platforms. For each platform, the information library can contain a detailed description of its API interface, such as the URL of the interface, authentication method (such as OAuth, API Key, etc.), supported data format (such as JSON), and specific request and response structure. At the same time, it will also contain the database type information 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 detection request to the target platform to determine its interface protocol and database type. For the determination of the database type, if it cannot be obtained directly, the platform can infer it based on the received response characteristics. 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 platform's compatibility and scalability, allowing data sharing to transcend the barriers of different technical architectures.

[0031] Finally, the service shared data is converted into a format acceptable to the target business platform and stored. The data can be seamlessly integrated into the target platform based on 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 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.

[0032] This embodiment realizes cross-system and cross-platform data processing and sharing by integrating multiple business platforms and deploying multiple business code tables on the SaaS platform, effectively overcoming the limitations of traditional point-to-point integration and middleware integration methods. First, the business platform and corresponding business system to which the received business data set belongs are automatically identified, laying the foundation for subsequent data processing and ensuring the accuracy and pertinence of data processing. Secondly, by converting business data into code items, identifying key business entities, encoding them, and obtaining unique identification codes, the standardization and uniqueness of data are realized, and the problem of inconsistent coding standards between different systems and platforms is effectively solved. This unique coding method effectively reduces the workload of data conversion and mapping and improves work efficiency. Thirdly, in response to cross-platform instructions, the updated code item group can be flexibly transmitted as service shared data to the target database of the target business platform, greatly enhancing the liquidity and sharing ability of data, and meeting the increasingly frequent collaboration needs between medical institutions, such as data exchange needs of 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 conversion of data between different systems and platforms more efficient, 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 of exponential growth of the number of interfaces as the number of systems and platforms increases, and significantly reduces 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 the middleware to handle exponential data exchange. 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. Through unified data standards and data processing mechanisms, information islands are effectively broken, and data interoperability and utilization efficiency are improved. It effectively promotes the development of medical informatization and improves the quality and efficiency of medical services.

[0033] In one implementation of this embodiment, after 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, the following steps are included: S210, in response to a query instruction of the current user, determining the user authority of the current user; S220, identifying 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; S230, performing desensitization processing on the sensitive information to obtain a desensitized code item group; S240. Filter the desensitized code item group according to user authority to obtain the filtered code item group.

[0034] First, respond to the query instruction of the current user and determine the user's permission level. This can be achieved by checking the user's login credentials (such as username and password), and then querying the user permission database or permission management to obtain the specific permission information of the user. Permissions can include data access levels (such as read-only, read-write), accessible data types (such as patient information, medical records, drug information, etc.), and specific functional permissions (such as data export, modification, etc.). For example, a general doctor only has the permission to view the patient information he is responsible for, while hospital managers have broader data access rights. Permission information can be temporarily stored in the session for use in subsequent steps. This step can effectively ensure data security and privacy protection, prevent unauthorized access, and provide users with different roles with appropriate data access scopes.

[0035] Next, identify sensitive information in the code item group. You can pre-define the categories and characteristics of sensitive information, such as the patient's ID number, name, address and other personal identification information, the doctor's practice license number, contact information and other personal information, as well as the name and dosage of special medicines. You can use regular expressions, keyword matching, etc. to scan each field in the code item group to identify sensitive information that conforms to the predefined pattern. For example, you can identify a string in the format of "XXXXXX YYYYMMDD ZZZZ" as an ID number, or identify certain specific drug names as controlled drugs, so as to accurately locate all sensitive data that require special processing and prepare for subsequent desensitization processing, thereby maximizing the protection of personal privacy and sensitive information during data sharing.

[0036] After sensitive information is identified, it is desensitized. Desensitization is a data processing technology that aims to reduce the risk of sensitive information leakage while retaining data availability. Different desensitization strategies can be used for different types of sensitive information. For ID card numbers, partial hiding can be used, such as retaining the first six digits and the last four digits, and replacing the middle with asterisks (such as "123456********1234"). For names, the first letter can be retained and asterisked (such as "Zhang*"). For address information, it can be retained only to the district or street level. For special drug information, the actual name can be replaced by 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, "Zhang San" can be converted to "Zhang*", etc., so as to greatly reduce the risk of sensitive information leakage while ensuring the value of data analysis and use, and enhance the security of data sharing.

[0037] Finally, according to the determined user permissions, the desensitized code item group is filtered. The user's permission information can be compared with each data item, and only the data that the user has access to is returned. It can involve filtering in multiple dimensions, such as data type, data scope, 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 the data of other departments are hidden. For a pharmacy manager, only information related to drugs can be returned without displaying specific patient information. In actual operation, the WHERE clause of the database query language (such as SQL) can be used to implement data filtering, or the conditional statements of the programming language can be used at the application level to filter data, so as to further refine the data access control and ensure that each user can only see the information within his or her permission range, which not only protects data security, but also facilitates users to obtain the required information efficiently.

[0038] This implementation method maximizes the protection of personal privacy and sensitive information while ensuring data availability through user authority management, sensitive information identification, data desensitization and authority filtering, effectively preventing data leakage and unauthorized access, and supporting the differentiated data needs of users with different roles.

[0039] In one implementation of this embodiment, the SaaS platform is further deployed with a central policy library, which stores data access rules. The data access rules include user roles and access control policies. The desensitized code item group is filtered according to user permissions to obtain the filtered code item group, including the following steps: S310, determining the user role of the current user according to the user authority, and determining the access context information of the user role, where the access context information includes the current time, geographic location, and network environment; S320, determining the access control policy corresponding to the user role in the central policy library by accessing the context information; S330, determining the visible code items of the current user in the code item group through the access control policy; S340: When the user role is a tenant role, determine a shared data field in the visible code item according to a preset cross-tenant access protocol; S350: When the user role is not a tenant role, the visible code item is used as a shared data field; S360: Transfer the shared data field to a preset visible code item group to obtain a code item group after data filtering.

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

[0041] By accessing the context information, the access control policy corresponding to the user role is determined 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 the specific implementation, a rule engine can be used, which can retrieve and evaluate a large number of complex policy rules. When a request containing 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 in a specific location), network environment-based rules (such as prohibiting access to certain data through the public network), 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 weekdays; 2) Allow access to complete patient information only from the hospital network; 3) Hide the patient's personal identification information when accessing from other networks. The rule engine can evaluate these policies and grant full data access rights considering that the user is accessing during working hours and using the hospital network. This step can dynamically determine the applicable access control policy based on the real-time situation, so that data availability can be maximized while ensuring data security. It not only improves the level of data protection, but also meets the flexible access requirements in different scenarios, such as special authorization in emergency situations.

[0042] Through the access control policy, the visible code items of the current user are determined in the code item group, so that the determined access control policy can be applied to the specific data items to achieve access control accurate to 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, and access conditions that users can access. Then, each data item in the code item group is traversed and these rules are applied to each field. For example, suppose the code item group contains the patient's personal information, medical records, and billing information. For an ordinary doctor user, the access control policy can allow him 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, and diagnosis results can be marked as visible, while fields such as bill amount and payment method 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 or recent medical records that he is responsible for, but 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 access to. This fine-grained control not only protects sensitive information, but also provides the most relevant data according to the specific work needs of users, thereby improving work efficiency.

[0043] In the case where the user role is a tenant role, the shared data fields are determined 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, which indicates that the user accesses on behalf of an organization or company. If it is confirmed to be a tenant role, the pre-defined cross-tenant access protocol is called. The cross-tenant access protocol is a series of complex rule sets that define the data types that can be shared between different tenants, the sharing conditions, and the processing of shared data. During the implementation process, the visible code items determined in the previous steps are first traversed, and each data field is matched with the cross-tenant access protocol. The matching process considers multiple factors, including the sensitivity of the data, the purpose of sharing, and legal compliance requirements. 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 diagnosis results and treatment effect data can be allowed to be shared, but the patient's personal identification information will be filtered out. Specifically, if the visible code item contains the patient's name, age, diagnosis results, and treatment plan, the diagnosis 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 and data volume limit of the data will be considered to ensure that sharing complies with the provisions of the agreement. This step can achieve effective data collaboration between different organizations under the premise of protecting data privacy and security. It enables 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 to prevent unauthorized data leakage.

[0044] In the case where the user role is not a tenant role, the visible code item is used as a shared data field to process data access requests from individual users or non-tenant users. When it is determined that the user does not belong to a tenant role, first, check the user's role type to confirm that it is not a tenant user representing an organization or company, and is applicable to individual users, temporary visitors, or administrators of specific functions. In this case, the visible code item can be directly used as the data field 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, suppose a registered user (non-doctor or hospital employee) of a medical consultation platform accesses it. According to the previous permission settings, the user can only see his or her personal information, appointment records, and public health information. In this case, directly marking the visible data item as a shareable data field without considering cross-tenant data sharing rules effectively simplifies the data access process for non-tenant users and improves processing efficiency. At the same time, it effectively ensures that the data access rights 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, making it possible to flexibly respond to various user roles and access scenarios.

[0045] Transfer the shared data fields to the preset visible code item group to obtain the code item group after data filtering, so as to finally organize and encapsulate the shareable data fields and 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 check 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 performed: 1) Data format conversion: Ensure that all data conforms to the predefined format standards for subsequent processing and display. 2) Metadata addition: Add necessary metadata to each data field, such as data source, last updated time, access permission level, etc., which helps to track and manage data. 3) Data consistency check: Ensure that the transferred data is consistent with the original data to avoid data errors or loss during the filtering process. 4) Access log recording: Record the access status of each data field, including access time, access user, access purpose, etc., for subsequent auditing and analysis. For example, suppose the original data contains the patient's name, age, diagnosis and treatment plan. After the previous steps, it is determined that only the diagnosis and treatment plan can be shared. In this step, a new data structure is created, containing only the two fields of diagnosis and treatment plan, and corresponding metadata is added, such as "Data desensitization level: high", "Last updated: 2024-04-15 10:30:00", etc. Finally, a final dataset can be generated that has been strictly filtered, has a unified format, and contains necessary metadata.

[0046] This implementation method first establishes a detailed background for each data access request through user identity authentication and context information collection; then uses the central policy library to dynamically match access control policies to ensure that data access rights are adjusted according to real-time conditions; then accurately screens visible data items in the code item group to achieve field-level access control; for tenant users, the preset cross-tenant access protocol is used to determine the scope of shared data, 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. It not only greatly improves the level of data security and privacy protection, but also achieves high flexibility and traceability of data access. It enables the SaaS platform to maximize the value and availability of data while protecting sensitive information, and supports complex multi-tenant environments and diverse data sharing needs.

[0047] 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; Among them, the protocol framework is used to limit the tenant scenarios of cross-tenant access protocols, the access control matrix is ​​used to define the current user's access rights based on the level of visible code items and tenant roles, the policy engine is used to execute access control policies, and the data sandbox environment is used to provide isolated data processing space.

[0048] In this embodiment, the cross-tenant access protocol also 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; Among them, the data classification system is used to divide visible code items into different levels, the consent mechanism is used to define access rights to visible code, the data tracking system is used to record logs of cross-tenant data access, data usage restrictions are used to define specific usage rules for visible code items, secure transmission protocols are used to ensure the security of data transmission, violation handling mechanisms are used to identify violations, standard APIs and interface specifications are used to define rules for multi-tenant data exchange, identity authentication systems are used to verify tenant identities, and version control systems are used to track updates to data access rules.

[0049] 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 the protocol include a protocol framework, an access control matrix, a policy engine, and a data sandbox environment. The protocol framework defines applicable tenant scenarios, such as data sharing between different medical institutions or cross-departmental information exchange. Figure 3 A schematic diagram of an access control matrix provided by an embodiment of the present application is shown, Figure 3 As shown in Figure 1, the access control matrix is ​​a two-dimensional table, with the horizontal axis representing different tenant roles (such as administrator, ordinary user, guest, etc.) and the vertical axis representing 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 a specific level of data, such as read, modify, or no permission. The policy engine is the executor of the protocol, which determines whether to allow a specific access request based on 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.

[0050] Specifically, Figure 3 The title is Access Control Matrix, with the X-axis representing "low-privilege role" to "high-privilege role", the Y-axis representing "low-sensitivity data" to "high-sensitivity data", and the four quadrants representing 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.

[0051] Figure 3The points in the chart represent the access rights of different roles to data of different sensitivities. The visitor is located at the lower left of the chart, indicating low-privilege access to low-sensitivity data; ordinary user 1 is located at the lower middle, indicating medium-privilege access to low-sensitivity data; ordinary user 2 is located in the middle, indicating medium-privilege access to medium-sensitivity data; administrator 1 is located at the lower right, indicating high-privilege access to low-sensitivity data; administrator 2 is located at the upper right, indicating high-privilege access to higher-sensitivity data; and administrator 3 is located at the upper right, indicating high-privilege access to high-sensitivity data.

[0052] Figure 3 It intuitively shows the access rights of different roles (from guest to administrator) to data of different sensitivities, showing that the rights increase with the promotion of roles and the increase of data sensitivity. Administrators have the highest access rights and can access all levels of data including confidential data, while guests have the lowest access rights and are limited to low-sensitivity public data.

[0053] To further enhance the functionality and security of the protocol, several auxiliary components are also included. The data classification system uses a multi-layer classification approach to classify visible code items into different sensitivity levels, such as public, internal, confidential, and top secret. The consent mechanism requires data owners 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, accessor identity, accessed data items, etc., to facilitate subsequent audits and problem tracing. Data usage restrictions define specific usage rules for visible code items, such as data retention period, 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 alerts or automatic defense measures. Standard APIs and interface specifications ensure interoperability between different tenant systems and define the format, protocol, and process for 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.

[0054] In practical applications, the cross-tenant access protocol can work as follows: Assume that there is a cross-hospital patient data sharing platform. Hospital A (tenant 1) needs to access the medical record data of a patient in hospital B (tenant 2). First, a user of 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 at the internal level) based on the access control matrix. Next, the consent mechanism checks whether the patient has authorized the sharing of his or her data. If all conditions are met, the policy engine allows the access request. The data is transferred from hospital B to a data sandbox environment created for the user of hospital A through a secure transmission protocol. In the sandbox, doctors can view and analyze the data, but cannot take the original data out of the sandbox. All operations are recorded by the data tracking system. If the doctor attempts to access unauthorized data (such as other patients' records), the violation handling mechanism will immediately block and record the behavior.

[0055] This implementation can significantly improve the security and controllability of data sharing and reduce the risk of data leakage and abuse. At the same time, it can promote data collaboration between different organizations. For example, medical research institutions can more easily obtain anonymized clinical data for analysis. Furthermore, the transparency of data use can be improved, and all access behaviors can be traced, 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, flexible access control and version management allow the protocol to be quickly adjusted as needs change, maintaining the long-term applicability of the platform. In summary, the cross-tenant access protocol balances the needs of data sharing and privacy protection, which not only ensures the security and privacy of data, but also promotes the maximization of data value.

[0056] In one implementation of this embodiment, the central policy library also stores a regular expression library, identifies key business entities in the code item group, and encodes each key business entity to obtain a unique identification code for each key business entity, including the following steps: S510, using a regular expression in a regular expression library to identify a shared data field to obtain a key business entity; S520: Encode each key business entity using a preset business code table to obtain a unique identification code for each key business entity.

[0057] First, regular expressions are used to identify key business entities from shared data fields. Regular expressions are an expression language used to describe 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 pattern collection, and each expression is designed for a specific type of business entity.

[0058] When implementing this, we first need to build a comprehensive regular expression library. This library contains patterns for many common business entities, such as ID card numbers, bank card numbers, phone numbers, email addresses, etc. Each business entity has its own specific format and rules, and regular expressions can cover all possible valid formats while excluding invalid formats.

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

[0060] Afterwards, each key business entity is encoded using a preset business code table to obtain a unique identification code for each key business entity.

[0061] The business code table predefines various business entity types and their corresponding encoding rules. In a 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 ID card number can be assigned an "ID" prefix, the bank card number can be assigned a "BC" prefix, the telephone number can be assigned a "TEL" prefix, etc. The encoding rules can include a fixed-length numeric sequence, an alphanumeric combination, or a more complex algorithm-generated string.

[0062] In the specific encoding process, each identified key business entity can be traversed, the corresponding encoding rules can be found according to its type, and then a unique identification code can be 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.

[0063] In order 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 so, it needs to be regenerated.

[0064] This implementation method first uses a regular expression library for accurate entity recognition, ensuring that key business data can be accurately captured without missing important information, effectively improving the efficiency and accuracy of data processing. Secondly, through encoding through a standardized business code table, a unified representation of data is achieved, which not only protects the privacy of the original data, but also retains the business significance of the data, providing convenience for data analysis, data exchange and cross-integration. It effectively improves the efficiency and security of data management.

[0065] 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: S610, traverse the code item group to obtain multiple key business entities; S620: For each key business entity, in the code item corresponding to the key business entity, embed the unique identification code into the remark field of the code item to obtain an updated code item; S630: Take the code item group including all updated code items as the updated code item group.

[0066] First, the code item group is traversed to obtain multiple key business entities, so as to comprehensively scan and analyze the code item group to identify and extract all key business entities contained therein. The code item group is a collection of multiple code items, each of which represents a piece of program code, configuration information or other structured data.

[0067] When implementing it, you first need to determine the traversal strategy. You can use algorithms such as depth-first search (DFS) or breadth-first search (BFS) 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.

[0068] As each code item is parsed, predefined rules or patterns can be applied to identify key business entities. The predefined rules can be keyword matching algorithms. For example, if field names like "customerID", "accountNumber", or "socialSecurityNumber" are found in a code item, they can be marked as potential key business entities.

[0069] Afterwards, for each key business entity, in the code item corresponding to the key business entity, the unique identification code is embedded in the remark field of the code item to obtain an 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 manner that does not affect the original code structure. In this embodiment, the remark field of the code item is used to store the unique identification code, because the remark field usually does not affect the execution of the code, and at the same time can provide enough space to store additional metadata.

[0070] 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 remark is to be inserted.

[0071] When inserting the unique identification code, if the code item already has existing remarks, the new identification information needs to be added in a way that does not damage the existing remarks content. Specific formats or markers can be used to distinguish the newly added identification information, such as using a prefix or encapsulating the information in a specific marker. If the code item has no existing remarks, a new remarks field needs to be created to accommodate the identification information.

[0072] 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 similar to "<!-- ENTITY_ID: [unique identification code] -->" can be used.

[0073] In implementation, special attention needs to be paid to maintaining the readability and original structure of the code. Inserting remarks should not damage the code's indentation, line breaks, or other formatting features.

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

[0075] Finally, the code item group containing all updated code items is used as the updated code item group to integrate all 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 the newly added unique identification code information.

[0076] In 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. Update in place: 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.

[0077] This implementation method first ensures the accurate identification of all key business entities by comprehensively traversing the code item group, laying a foundation for subsequent processing. Secondly, by embedding the unique identification code into the remarks 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 updated code items, a new code item group is formed. This not only improves the traceability and management efficiency of data but also provides a basis for subsequent data analysis.

[0078] In one implementation manner 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: S710, determining the transmission mode and data format of the target service platform according to the interface protocol; S720, determining the data structure, syntax characteristics, and storage structure of the target database according to the database type; S730, obtaining all field information of the service shared data, and determining a mapping rule corresponding to the field information according to the grammatical characteristics, where the field information includes a field name and a data type; S740, creating a configuration file in JSON format according to the mapping rule, data format, data structure and storage structure; S750, using a preset mapping engine to read and parse the configuration file in JSON format to generate data conversion logic; S760. Use data conversion logic to convert the service sharing data into business data of the target business platform.

[0079] 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, and 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 the 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 data in JSON format, the configuration reference Figure 4 The pseudocode shown in the figure describes the basic structure and parameters of an API request. The first line of the pseudocode lists the main features of the API request, which uses the HTTPS protocol, the POST method, and the data format is JSON. The "begin ... end" block defines the HTTP request header: ""Content-Type":"application / json"", which is used to specify that the content type of the request body is JSON. ""Authorization":"Bearer {token}"" is used to specify the use of Bearer tokens for authentication. When facing different target platforms, you only need to adjust the configuration file without modifying the core code logic. This not only simplifies platform maintenance, but also greatly improves the efficiency of adapting to new platforms.

[0080] After that, determine the data structure, syntax characteristics, and storage structure of the target database based on the database type. First, determine the set of data types supported by the database type (such as MySQL, Oracle, PostgreSQL, etc.). For example, MySQL supports types such as INT, VARCHAR, and DATETIME, while Oracle supports types such as NUMBER, VARCHAR2, and DATE. Second, determine the syntax characteristics unique to each database, such as MySQL's AUTO_INCREMENT, Oracle's SEQUENCE, and other auto-increment primary key implementation methods, as well as the syntax differences between different databases in terms of indexes, constraints, and stored procedures.

[0081] In addition, you also need to consider the storage structure of the target database, including table space design, partition strategy, index organization, etc. For example, for large tables, you need to consider partition storage to improve query efficiency; for frequently accessed columns, you need to create indexes.

[0082] When implementing, you can create a database feature mapping table such as Figure 5 As shown in the figure, this pseudocode is the configuration for MySQL database. dataTypes defines the corresponding representation of commonly used data types in MySQL, that is, integer type uses INT, string type uses variable-length string with a maximum length of 255, and date and time type uses DATETIME; syntaxFeatures describes the MySQL-specific syntax features, that is, defining columns for auto-increment, defining the syntax of primary keys, and defining the basic syntax of foreign keys; storageStructure defines storage-related settings, that is, using InnoDB as the default storage engine, using the utf8mb4 character set, supporting the full Unicode range, including emojis, and using utf8mb4_unicode_ci as the sorting rule, which is a case-insensitive Unicode sorting rule.

[0083] By clarifying the characteristics of the target database, we can ensure 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.

[0084] After that, all the field information of the service shared data is obtained, and the mapping rules corresponding to the field information are determined according to the grammatical characteristics. The field information includes the field name and data type. First, it is necessary to traverse all the fields of the service shared data and extract the name and data type of each field. This can be achieved by parsing the data dictionary and metadata table. For each field, its name, original data type and other information need to be recorded. Then, based on the determined grammatical characteristics 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.

[0085] For example, for a source table named "user_info", its mapping rules are as follows Figure 6 As shown, the 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 relationship between each field, including the mapping of three fields. For example, the first field mapping (user_id) maps name to "USER_ID", maps type to "NUMBER", and adds primary key and non-null constraints.

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

[0087] The process of creating a configuration file is as follows: First, define a top-level structure, including target platform information, database information, and field mapping rules. The target platform information section includes the previously determined transmission method and data format. The database information section includes the database type, syntax characteristics, and storage structure. The field mapping rules section lists the source information and target information of each field in detail. A complete configuration file structure is as follows: Figure 7 As shown, in this pseudocode, the targetPlatform part defines the configuration of the target API, the targetDatabase part describes the configuration of the target database, and the dataMapping array defines the data mapping rules, including the mapping of multiple tables.

[0088] Use the preset mapping engine to read and parse the configuration file in JSON format and 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. This can be implemented using standard JSON libraries, such as Java's Jackson, Python's json module, 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 build an internal data structure or object model based on the parsed configuration information. The object model is used for subsequent conversion logic generation. For example, a Table object can be created for each table and a Field object can be created for each field. These objects contain all relevant information about the source data and the target data.

[0089] 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 in-memory data conversion). For SQL generation, the characteristics of the target database can be considered, such as syntax differences, data type mapping, etc. For in-memory data processing, corresponding program code or scripts can be generated.

[0090] For example, for Figure 7 The mapping engine can generate the following configuration files: Figure 8 The Oracle SQL statements shown in the figure are used to create tables, sequences, and insert data. Specifically, the table structure is defined first to create a table for storing user information; the auto-increment primary key uses a sequence to ensure that USER_ID is unique and automatically incremented; the data insertion template provides a reusable insert statement to facilitate batch insertion of data or insertion of a single piece of data through an application; the data type conversion correctly converts the input date string into the Oracle DATE type.

[0091] At the same time, the engine can also generate corresponding data processing logic, such as Fig. 9As shown, the pseudocode is used to convert the source data format into the target data format. Specifically, data mapping is first performed to map the field names of the source system to the field names of the target system; then data conversion is performed; and then data cleaning and standardization are performed to ensure that the data complies with 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 handled, including field renaming, data type conversion, complex data conversion functions, etc. Furthermore, 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.

[0092] Use data conversion logic to convert service shared data into business data of the target business platform. When using the preset mapping engine to read and parse the configuration file in JSON format, the first step is to ensure that the mapping engine has the ability to parse JSON. The engine uses the JSON parsing library to read each element in the configuration file according to its structure. When parsing, first read the top-level structure, which includes overall transmission and formatting information, such as transmission protocol, data format, etc., and then go deep into the database level to obtain information about the database type, syntax characteristics, and storage structure.

[0093] 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 operations and business logic rules. In this way, complex data conversion rules can be implemented through JSON configuration without the need for additional code, achieving flexibility and maintainability.

[0094] The implementation method of using a mapping engine to parse configuration files not only ensures the standardization of data processing logic, but also provides an efficient configuration management mechanism. When business requirements change, only the JSON configuration file needs to be updated, without changing the code, to achieve rapid response. Requirements changes can be completed through simple configuration adjustments, reducing development and testing time and improving business adaptability.

[0095] The logic generated by the mapping engine can be divided into two parts: the first is the logic for interacting with the data source, which is used to extract and preliminarily process the data from the source to ensure that the data is close to the final form when it enters the transformation process. The second is a series of data transformation operations that guide specific field conversions 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.

[0096] In this embodiment, the generation of conversion logic not only includes simple conversion of data types, but also can handle data quality issues. For example, the strategy for handling missing values ​​and abnormal values ​​can be explicitly defined in the generated conversion logic, including setting default values, correcting formats, etc. This not only improves data consistency, but also prevents errors from propagating to the business platform. By means of code generation, the possibility of human error is reduced, and the business logic is decoupled from development details, which improves code reusability and processing efficiency.

[0097] After the data conversion logic is generated, the service shared data can be converted into the business data of the target business platform using the data conversion logic.

[0098] This implementation makes it easier to connect different data sources with the target business platform through standardized JSON configuration files and flexible conversion logic generation mechanisms, greatly reducing the pressure of manually writing data conversion logic. At the same time, it keeps the entire data integration process transparent and traceable, helping to improve business agility and the ability to respond quickly to environmental changes.

[0099] In one implementation of this embodiment, after the service sharing data is converted into the business data of the target business platform by using the data conversion logic, the following steps are included: S810: Transmit the business data to the target business platform using a transmission method, so that the business data is stored in a target database of the target business platform.

[0100] First, select the corresponding network protocol and transmission technology according to the transmission method. The transmission methods can include HTTP / HTTPS, FTP, SFTP, WebSocket or custom TCP / IP protocols. For example, if you need real-time data transmission, you can choose WebSocket; if you need higher security, you can use HTTPS or SFTP.

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

[0102] In addition, in order to ensure the consistency and integrity of data, 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 the failure of some operations.

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

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

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

[0106] JSON (JavaScript Object Notation) is a lightweight data exchange format that is widely used in configuration files and data transmission. The core task of a JSON parser is to convert 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.

[0107] First, in the lexical analysis phase, the JSON parser will break 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 recognize the tokens {, "name", :, "John", ,, "age", :, 30,}.

[0108] Next comes the syntax analysis phase. In this phase, the parser combines these tokens into a meaningful structure according to the syntax rules of JSON. It checks whether the brackets match, whether the key-value pairs are formed correctly, whether the array elements are separated correctly, etc. This can be achieved using the recursive descent parsing method.

[0109] The last phase is the semantic processing phase. In this phase, the parser converts the parsed structure into data types in the programming language. For example, objects in JSON may be converted into hash tables or dictionaries, arrays may be converted into lists or arrays, and strings, numbers, and Boolean values ​​may be converted into corresponding basic data types.

[0110] In a specific implementation, assume that there is a configuration file containing data mapping rules, such as Fig.10 As shown in the figure, this pseudocode defines how to transform the source data field into the target data field, and explains the properties of the field 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", "targetField" and their corresponding values. For nested structures, such as the "transformation" object, the parser will parse recursively.

[0111] 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 such as Fig.11 As shown in the figure, the pseudo code describes a data mapping rule (MappingRule) used to convert the data of the source field and store it in the target field.

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

[0113] This implementation makes the definition and modification of data mapping rules simple and intuitive by implementing a JSON parser in the mapping engine, greatly reducing the complexity of system maintenance and updates. The use of the JSON format not only provides good readability, but also ensures the structuring and standardization of configuration information, which is conducive to cross-platform and cross-system data exchange.

[0114] The embodiment of the present application also provides a service sharing data processing system based on the SaaS platform, including: a memory configured to store instructions; and The processor is configured to call instructions from the memory and implement the above-mentioned service sharing data processing method based on the SaaS platform when executing the instructions.

[0115] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, the present application may 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.) containing computer-usable program codes.

[0116] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram and the combination of the processes 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 a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0117] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0118] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0119] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

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

[0121] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. 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 technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0122] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0123] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should 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 2, 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