A test item multi-level management system, method, device and medium based on process approval driving

Abstract

The application discloses a test item change multi-level management system and method based on process approval driving, equipment and medium, relates to the field of medical information and business process management, and comprises the following steps: a form driving layer is used for generating and rendering an application form of a test item change process; the form driving layer comprises an item change component and an item verification component, and each field in the item change component is configured with an independent state controller; a process approval engine layer is used for dynamically selecting a corresponding multi-level approval flow branch by evaluating a preset condition expression during process instance running; and when the process flows to each approval node, a node permission instruction is generated according to a three-level mapping relationship and is delivered to the item change component; and an integrated interface layer is used for realizing data communication between the form driving layer, the process approval engine layer and a test system. The application can realize full-process traceability, fine permission control and intelligent condition branch flow transfer of test items.

Description

Technical Field

[0001] This application relates to the field of medical information and business process management, and in particular to a multi-level management system, method, equipment and media for variable test items based on process approval. Background Technology

[0002] In hospital laboratory information systems, modifications to laboratory test items are typically made by directly manipulating the database or through the back-end management interface. When the laboratory needs to add a new test item (such as adding "novel coronavirus antibody test") or modify existing item information (such as adjusting reference ranges, pricing standards, or testing methods), it is usually done directly in the back-end management module of the laboratory system by operators with system administration privileges, and the changes take effect immediately.

[0003] The existing management methods for inspection items have the following technical problems: (1) Lack of approval and control mechanism. As the core basic data of medical testing, the accuracy of test items directly affects the clinical diagnosis results. In the existing scheme, any person with management authority can directly modify the project information, lacking multi-level approval and verification links, which poses a data security risk of misoperation and unauthorized modification.

[0004] (2) The modification process is not traceable. Under the direct modification mode, the data comparison relationship before and after modification is unclear, and it is impossible to fully record information such as the applicant, modification content, approval opinions, and final execution results of each change, which is not conducive to medical quality control and compliance audit.

[0005] (3) Lack of fine-grained field-level permission control. Existing inspection systems typically manage permissions at the "role-functional module" level, which cannot achieve precise control over specific fields of a single inspection item (such as allowing only modification of the item name and reference range, and prohibiting modification of the fee standard).

[0006] (4) Lack of flexible conditional branching and workflow capabilities. The levels and workflow paths required for change approval should differ for different categories and levels of importance of inspection items. The existing inspection system's back-end management function cannot dynamically adjust the approval path based on project attributes and modified content. Summary of the Invention

[0007] The purpose of this application is to provide a multi-level management system, method, equipment and media for variable inspection items based on process approval, which can realize full-process traceability of inspection items, refined access control and intelligent conditional branching.

[0008] To achieve the above objectives, this application provides the following solution: Firstly, this application provides a multi-level management system for variable inspection items based on process approval, including: The form-driven layer is used to generate and render application forms for the inspection project change process. The form-driven layer includes a project change component, which is used to bind to a preset inspection project category and obtain and display the current information data of the specified inspection project through the integration interface layer. Each field inside the project change component is configured with an independent state controller. The form-driven layer also includes a project verification component, which is used to automatically generate simulated data for verification based on the attributes of the project applying for change in the current process before the change is submitted, and to verify historical project data. The workflow approval engine layer, connected to the form-driven layer, is used to extract the application form submission data and the attribute information of the associated inspection items when the workflow instance is running. It dynamically selects the corresponding multi-level approval flow branch by evaluating the preset conditional expression. When the workflow flows to each approval node, it generates node permission instructions and issues them to the project change component based on the three-level mapping relationship of "workflow node - form - field". An integrated interface layer is connected to both the form-driven layer and the process approval engine layer to enable data communication between the form-driven layer, the process approval engine layer, and the inspection system.

[0009] Secondly, this application provides a multi-level management method for inspection item changes based on process approval, applied to the aforementioned system, the method comprising: Based on the applicant's selection of the project process template, a corresponding process instance is generated, and a change application form is dynamically rendered according to the type of the project process template; wherein, the project process template includes a new inspection project process template and a modified inspection project process template; Obtain the node permission instructions of the node where the process instance is located, and dynamically set the corresponding fields in the application form to editable, read-only, or hidden states according to the node permission instructions, and receive the change data entered by the applicant within the editable state field range; before the change is submitted, the project verification component automatically generates simulated data for verification based on the project attributes of the application for change in the current process, and verifies the historical project data; after the verification is passed, the process is allowed to be submitted; Based on the changed data, the attribute information of the application form submission data and associated inspection items is extracted, and the corresponding multi-level approval flow branch is dynamically selected by evaluating the preset conditional expression to determine the target approval path; The process instance is sequentially transferred to each approval node along the target approval path. When the process is transferred to each approval node, a node permission instruction is generated and issued to the project change component based on the three-level mapping relationship of "process node - form - field". When the process instance reaches the termination node, the changed data and the complete approval trajectory of the process instance are assembled into a change event message, and the change event message is pushed to the inspection information system, triggering the inspection information system to perform the addition or update operation of the project master data according to the changed data.

[0010] Thirdly, this application provides a computer device, including: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described process approval-driven multi-level management method for variable inspection items.

[0011] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described multi-level management method for variable inspection items based on process approval.

[0012] According to the specific embodiments provided in this application, this application has the following technical effects: (1) The process approval engine layer is used to extract the application form submission data and related test item attribute information when the process instance is running. It dynamically selects the corresponding multi-level approval flow branch by evaluating the preset condition expression, transforming the original "direct database operation" in the backend of the test system into a standardized process instance that must go through "form initiation → engine routing → multi-level flow". All change requests are forcibly included in the control domain of the process engine, eliminating the possibility of personnel with management authority bypassing approval to directly modify core medical data, and establishing a mandatory control mechanism of "approval first, execution later". (2) Based on the three-level mapping relationship of “process node - form - field”, the process approval engine layer generates node permission instructions and issues them to the project change component. It can independently perform editable / read-only / hidden state switching for a single field, rather than uniformly controlling the entire page or module. It realizes that the same application form presents differentiated field operation permissions at different approval nodes, which meets the business needs of multi-role collaboration and responsibility isolation in project management. (3) The process approval engine layer extracts the application form submission data and the attribute information of the associated inspection items, and dynamically selects the corresponding multi-level approval flow branches by evaluating the preset conditional expressions. This makes the process routing no longer dependent on the preset fixed path, but calculates and decides in real time based on the actual content of the current change and the inherent attributes of the project. The same set of process templates can be automatically differentiated into approval links of different lengths and levels; so that low-risk and routine changes can go through short processes to improve efficiency, while high-risk and critical changes can go through long processes to ensure safety, maximizing the efficiency of business flow while ensuring compliance. (4) By using an independent integration interface layer as the only data interaction channel, the process management platform and the inspection system are decoupled. On the one hand, this ensures that the process management platform and the inspection system evolve independently and do not intrude on each other, reducing the system integration and maintenance costs. On the other hand, based on the full life cycle record of the process instance, it provides an immutable audit traceability basis for each change. Attached Figure Description

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

[0014] Figure 1 A schematic diagram of the functional modules of a multi-level management system for variable inspection items driven by process approval, provided in Embodiment 1 of this application; Figure 2 A flowchart illustrating a process approval-driven, multi-level management method for variable inspection items, provided for the purposes of this application. Detailed Implementation

[0015] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0017] Example 1: like Figure 1 As shown, a multi-level management system for variable laboratory test items based on process approval is provided. This system includes: a form-driven layer 1, a process approval engine layer 2, and an integration interface layer 3. This system communicates loosely with the hospital's existing laboratory system 4, namely the Laboratory Information System (LIS), through the integration interface layer 3. Each part is described in detail below.

[0018] (1) Form-driven layer 1.

[0019] Form-driven layer 1 is used to generate and render the application form for the inspection item change process; the form-driven layer 1 includes an item change component 11, which is used to bind a preset inspection item category and obtain and display the current information data of the specified inspection item through the integration interface layer 3. Each field inside the item change component 11 is configured with an independent status controller.

[0020] Specifically, the form-driven layer 1 is deployed on a front-end client (such as a web browser or desktop application) and is responsible for generating and rendering the application form for verifying the project change process. The form-driven layer 1 includes a project change component 11, which is a front-end UI component that encapsulates data loading, field rendering, and state control functions.

[0021] The project change component 11 is bound to a preset test item category (such as "biochemical test", "immunological test", "microbiological test", "molecular diagnostics" etc.). Through the integrated interface layer 3, it calls the project information query interface 31 in real time to obtain and display the current information data of the specified test item, including but not limited to: project name, project code, test method, sample type, reference range, reporting unit, fee standard, medical insurance code, clinical significance and other fields.

[0022] Each field within the project change component 11 is configured with an independent status controller. The status controller is used to dynamically switch the field to editable, read-only, or hidden status according to the node permission instructions issued by the process approval engine layer 2.

[0023] Specifically, the state controller is implemented using the observer pattern, continuously listening for node permission commands issued by the workflow approval engine layer 2. Internally, the state controller maintains a state mapping table, where the key is the field identifier and the value is the current permission status (editable / read-only / hidden). When a new node permission command is received, the state controller iterates through the permission configurations in the node permission command, updates the state mapping table, and triggers a responsive re-render of the form view, thereby achieving dynamic switching of field states.

[0024] The form-driven layer 1 also includes a project validation component 12. The project validation component 12 is used to automatically generate simulated data for validation based on the project attributes for which changes are requested in the current process before the change is submitted, and to verify historical project data.

[0025] Project verification component 12 is used to automatically verify the changes before the applicant submits a change request. This component automatically generates relevant project simulation data for verification based on the project attributes for which changes are being requested in the current process. Specifically, the generation of simulation data is based on two dimensions: limiting conditions and judgment range. Limiting conditions include two scenarios: "satisfied" and "not satisfied"; judgment range includes three scenarios: "within the range," "outside the range," and "at the critical value." The component uses a Cartesian product algorithm to combine each scenario of the limiting conditions with each scenario of the judgment range in a one-to-one correspondence, generating simulation data that covers all combinations. This ensures that the generated simulation data can exhaustively cover various boundary scenarios and abnormal scenarios, thereby improving the coverage and accuracy of project change verification.

[0026] Furthermore, the project verification component 12 can also simultaneously perform random filtering and verification of historical project data: based on pre-set limiting conditions and associated project attributes, it queries historical data that meets the limiting conditions from the historical project data, and the query results cover various situations such as being within the range and being outside the range. For each situation in the limiting conditions, it also corresponds one-to-one with all situations within and outside the range in the judgment range to ensure that each situation is included in the verification range and to avoid verification omissions.

[0027] The results of the simulation data verification and historical data verification need to be manually confirmed a second time: if the verification fails, the submission of the corresponding application will be restricted; if the verification is successful, the process can be submitted and enter the review stage.

[0028] (2) Process approval engine layer 2.

[0029] The process approval engine layer 2, connected to the form driver layer 1, is used to extract the application form submission data and the attribute information of the associated inspection items when the process instance is running, dynamically select the corresponding multi-level approval flow branch by evaluating the preset condition expression; and when the process flows to each approval node, it generates node permission instructions and issues them to the project change component 11 of the form driver layer 1 according to the three-level mapping relationship of "process node - form - field".

[0030] Specifically, the process approval engine layer 2 is built based on the BPMN 2.0 protocol and implemented using the Activiti or Flowable open-source process engine framework. It is used to define, parse, and execute multi-level approval processes for verifying project changes. The process approval engine layer 2 includes a process template management unit 21, a conditional branch decision unit 22, and a permission mapping unit 23.

[0031] 1) Process Template Management Unit 21.

[0032] The process template management unit 21 is used for visual configuration of new inspection project process templates and modification of inspection project process templates, and independently configures the node responsible person, approval method and form permission mapping relationship for each process node.

[0033] The process template management unit 21 provides a visual process designer interface, allowing system administrators to visually configure at least two sets of process templates: a new inspection project process template and a modified inspection project process template. Each process node can be independently configured with the node responsible person (a specific user, job role, or department can be specified), approval method (such as countersigning, independent signature, sequential approval, etc.), and form permission mapping relationship.

[0034] 2) Conditional branch decision unit 22.

[0035] The conditional branch decision unit 22 is used to extract the application form submission data and related inspection item attribute information during process instance execution, and dynamically select the corresponding multi-level approval flow branch by evaluating the preset conditional expression.

[0036] The conditional branch decision unit 22 adopts a two-stage mode of "design-time rule template definition + runtime data evaluation".

[0037] During the design phase, when drawing flowcharts, process designers configure conditional expression templates on the outbound connections of branch gateways (such as exclusive gateways, i.e., XOR gateways). Conditional expressions can reference form field values ​​and item attributes as evaluation variables.

[0038] Project attribute variables: prefixed with project., including but not limited to project.category (checking project category), project.isHighRisk (whether it is a high-risk project), project.department (the department to which it belongs), etc.

[0039] Form change variables: prefixed with "form.", each form field corresponds to a change detection variable, formatted as "form.{field Id}Changed", a boolean value indicating whether the field has changed in this application, such as "form.reference Range Changed", "form.price Changed", and "form.test Method Changed".

[0040] Example: Configure a conditional expression on branch A: {project.category}="Biochemistry Test" or `{form.reference Range Changed}=true` indicates that when the project category is biochemical testing and the fee standard field changes, the process will follow branch A.

[0041] In this embodiment, the expression syntax follows the BPMN 2.0 conditional expression specification.

[0042] During runtime, when a process instance flows to a branch gateway node, the process engine extracts the actual submitted form data and associated validation item attribute information from the current process instance context, populates the variable placeholders in the conditional expressions, and evaluates them. If the condition of a connection evaluates to true, that connection is selected as the flow branch. If multiple connections are both true, the first matching connection is selected according to the connection configuration priority (or connection order); if all connections are not true, the process engine throws an exception and rolls back to the state before the gateway.

[0043] Through the above mechanism, the same process template can automatically adapt to different approval paths based on the classification of different test items and the severity of the modifications. For example, minor adjustments to the reference range of routine biochemical test items (modifying only the reference range) follow a two-level process: "approval by the head of the professional group → execution"; the creation of new high-risk immunoassay test items involving the setting of fee standards follows a four-level process: "approval by the head of the professional group → approval by the deputy director → approval by the director → execution".

[0044] 3) Permission mapping unit 23.

[0045] The permission mapping unit 23 is used to establish and store a three-level mapping relationship of "process node - form - field". When the process flows to each approval node, the three-level mapping relationship is executed to generate permission configuration information for each field and form a node permission instruction, which is then sent to the project change component 11 of the form driver layer 1.

[0046] The three-level mapping relationship of "process node - form - field" is stored in a relational database table. The table structure includes at least: mapping ID (primary key), node ID (associated process node), form ID (associated form template), field ID (specific field in the associated form), and permission type (editable / read-only / hidden). When the process flows to the target approval node, the permission mapping unit 23 queries all field permission configurations corresponding to that node, encapsulates them into node permission instructions, and sends them to the project change component 11 of the form driver layer 1.

[0047] (3) Integration interface layer 3.

[0048] The integration interface layer 3 connects to both the form-driven layer 1 and the process approval engine layer 2, enabling data communication between the form-driven layer 1, the process approval engine layer 2, and the inspection system 4. The integration interface layer 3 is implemented using a RESTful API architecture, with all interfaces adhering to the HTTP / HTTPS protocol and JSON (JavaScript Object Notation) as the data exchange format. The integration interface layer 3 includes at least an inspection item information query interface 31 and an approval result feedback interface 32.

[0049] 1) Inspection item information query interface 31.

[0050] The inspection item information query interface 31 is used by the project change component 11 to obtain the project master data in the inspection system 2.

[0051] 2) Approval result feedback interface 32.

[0052] The approval result feedback interface 32 is used by the process approval engine layer 2 to call at the end of the process instance to push the approved change dataset to the inspection system 4.

[0053] Furthermore, the system also includes a change execution and confirmation module 41 on the inspection system 4 side. This module is a service component deployed inside the inspection system 4, used to receive the approval results pushed by the integration interface layer 3 through the approval result feedback interface 32, and accordingly execute the creation or modification operation of the project in the database of the inspection system 4.

[0054] The change execution and confirmation module 41 is also used to send a change notification to the downstream business system 5 (such as the Hospital Information System (HIS), Electronic Medical Record (EMR), quality control system, etc.) after the change is completed. The notification method can be message queue or HTTP callback. The change notification shall include at least the unique identifier of the changed item, the effective time of the change, and a summary of the changed content.

[0055] Upon receiving the change notification, each downstream business system 5 performs a synchronization update operation and returns a confirmation receipt to the verification system 4. The receipt includes at least the identifier of the downstream business system, the reception status (success / failure), and application status feedback. The verification system 4 receives and records the confirmation receipts from each downstream system, and stores them in the audit log of the process instance, forming a complete closed loop of "application—approval—execution—confirmation".

[0056] Through the above system architecture and the collaborative work of its components, this application achieves full-process approval-driven management of inspection project changes.

[0057] Example 2: This embodiment provides a complete description of the specific implementation method for a multi-level management approach to inspection item changes based on process approval. For example... Figure 2 As shown, a multi-level management method for inspection item changes based on process approval is provided, including the following steps: S1: Based on the applicant's selection of the project process template, generate a corresponding process instance, and dynamically render the change application form according to the type of the project process template; wherein, the project process template includes a new inspection project process template and a modified inspection project process template.

[0058] The applicant (i.e., the laboratory staff) logs into the system through a client (such as a PC web application or a mobile H5 application), selects the "Create a new test item" or "Modify a test item" process template on the process initiation interface, fills in the item code (in the modification scenario) or related basic information, and clicks the initiate button. The system responds to this selection operation by calling the process engine's API to generate the corresponding process instance.

[0059] After the process instance is generated, the process template management unit 21 dynamically renders the change request form based on the type of the project process template (new / modified). Specifically: If the process template is modified, the project change component 11 reads and loads the current full field data of the target inspection item into the application form in real time from the inspection system 4 through the inspection item information query interface 31 of the integration interface layer 3, and displays it to the applicant as the baseline data before modification. If it is a newly created process template, a blank application form will be initialized, and some fields will be pre-filled according to the default value rules of the template (such as automatically generating project code prefixes, setting default report units, etc.).

[0060] S2: Obtain the node permission instruction of the node where the process instance is located, and dynamically set the corresponding fields in the application form to editable, read-only, or hidden status according to the node permission instruction, and receive the change data entered by the applicant in the editable field range; before the change is submitted, the project verification component automatically generates simulated data for verification based on the project attributes of the application for change in the current process, and verifies the historical project data; after the verification is passed, the process is allowed to be submitted.

[0061] After a process instance is started, the node identifier of the node where the process instance is located (i.e., the "initiating node") is obtained. The permission mapping unit 23 uses the node identifier as an index to retrieve the three-level mapping relationship of "process node—form—field" in the database, obtaining the permission configuration information for all fields under that node. The permission mapping unit 23 converts the permission configuration information into node permission instructions. Node permission instructions are instantiated projections of the permission configuration information at runtime—they are not original records stored in the database, but rather dynamic, instantaneous control signals assembled by the permission mapping unit 23 after retrieving permission configuration information from the database based on the current node identifier.

[0062] The project change component 11 receives the node permission instruction. The status controller parses the permission values ​​of each field in the instruction and dynamically sets the corresponding fields in the application form to editable, read-only, or hidden states. For example, in the initiation node, its permission configuration information stipulates that business fields such as project name, reference scope, and charging standard are editable, making it easy for the applicant to fill in the change content; system audit fields such as "creation time" and "creator" are read-only, automatically filled by the system and cannot be modified; status fields such as "approval status" and "effective time" are hidden and not visible to the applicant during the initiation stage.

[0063] After the applicant completes or modifies the information within the editable fields, the changes are temporarily saved and have not yet been formally submitted.

[0064] Project verification component 12 automatically generates relevant project simulation data for verification based on the project attributes for which changes are requested in the current process. The verification results undergo a second manual confirmation: if verification fails, the submission of the corresponding application is restricted; if verification succeeds, the process is allowed to be submitted and enters the review stage.

[0065] Clicking the submit button submits a change request, passing the form data as a process variable to the process engine. Upon receiving the submitted data, the process engine automatically records the applicant's user ID, submission time, and a comparison of field values ​​before and after the change, serving as the basis for the audit log.

[0066] S3: Based on the changed data, extract the application form submission data and the attribute information of the associated inspection items, and dynamically select the corresponding multi-level approval flow branch by evaluating the preset conditional expression to determine the target approval path.

[0067] After receiving the submitted change data, the workflow approval engine layer 2 transfers the workflow instance to the branch gateway node. The conditional branch decision unit 22 executes conditional routing, as follows: (1) Variable extraction.

[0068] Conditional branch decision unit 22 extracts two types of data as evaluation variables from the context of the process instance: 1) Form submission data: This refers to the changed values ​​of each field submitted by the applicant in step S2, stored as process variables. For example, if the applicant changes the reference range from "negative" to "negative (can be positive after vaccination)," the process variable contains the current value of form.referenceRange.

[0069] 2) Attribute information of associated inspection items: These are the project master data attributes loaded by the project change component 11 from the inspection system 4 in step S1, including but not limited to project.category (project category), project.isHighRisk (whether it is a high-risk project), project.department (the department to which it belongs), etc. These attribute data are passed into the process engine as process initiation variables.

[0070] (2) Evaluation of conditional expressions.

[0071] The conditional branch decision unit 22 substitutes the extracted variable values ​​into the preset conditional expressions for evaluation. The conditional expressions are configured by the system administrator through a visual process designer on each outgoing connection of the branch gateway during the design phase, and their syntax follows the BPMN 2.0 specification (using the JUEL Unified Expression Language).

[0072] The variables used in conditional expressions fall into two main categories: Form field identifiers: prefixed with "form.", each form field corresponds to a change detection variable, formatted as "form.{field Id}Changed", which is a boolean value indicating whether the field has changed in this application.

[0073] Project attribute identifiers: prefixed with project., including but not limited to project.category (project category), project.isHighRisk (whether it is a high-risk project), project.department (the department to which it belongs), etc.

[0074] The conditional branch decision unit 22 substitutes these variable values ​​into a preset conditional expression for evaluation, and selects the target approval path from multiple candidate approval paths based on the evaluation result (Boolean value). For example, for a new application for an immunological testing project, if the conditional expression project.category = "immunological testing" evaluates to true, then the fourth-level approval path is selected; if it is an application to modify the reference range for a biochemical testing project, if the conditional expression project.category = "biochemical testing" && form.reference Range Changed = true && form.price Changed = false evaluates to true, then the two-level approval path is selected.

[0075] S4: The process instance is sequentially transferred to each approval node along the target approval path. When the process is transferred to each approval node, a node permission instruction is generated and issued to the project change component based on the three-level mapping relationship of "process node - form - field".

[0076] The workflow engine sequentially transfers the workflow instance to each approval node based on the selected target approval path. At each approval node, the permission mapping unit 23 performs a mapping query again, using the node ID of the current approval node as an index to retrieve all field-level permission records corresponding to that node from the database. The query results are then dynamically assembled into node permission instructions and sent to the project change component 11 of the form-driven layer 1. The status controller parses the instructions and switches each field in the form to its corresponding access status (editable / read-only / hidden) to limit the current approver's access permissions to each field in the form. For example, in the "Chief Approval" node, all fields are set to read-only, and the approver can only view the changes and fill in the approval comments, but cannot modify the project data; in the "Execution Confirmation" node, all fields are set to read-only, and only the final approved complete data can be viewed.

[0077] S5: When the process instance reaches the termination node, the changed data and the complete approval trajectory of the process instance are assembled into a change event message, and the change event message is pushed to the inspection information system, triggering the inspection information system to perform the addition or update operation of the project master data according to the changed data.

[0078] When a process instance reaches the termination node (i.e., the "end event"), the process engine triggers the end event listener. This listener calls the approval result feedback interface 32 of the integration interface layer 3, pushing the complete change data and multi-level approval records to the inspection system 4.

[0079] The pushed change data should at least include a comparison of the field values ​​before and after the change (encapsulated in a JSON structure), and the multi-level approval record summary should at least include the approver, approval comments, and approval time for each approval node. After receiving the callback request, the change execution and confirmation module 41 of the inspection system 4 uses the change dataset in the callback data as a basis to perform the actual project creation or modification operation in the database of the inspection system 4. Preferably, the inspection system 4 performs incremental updates based on the differences between the field values ​​before and after the change, that is, only the fields that have changed are modified, while the unchanged parts remain unchanged.

[0080] Furthermore, it also includes: after the change is executed, the inspection system sends a change notification to the downstream business system and receives a processing confirmation receipt, thus completing the multi-level management closed loop of inspection item changes driven by process approval.

[0081] After the change is executed, the change execution and confirmation module 41 listens for and obtains the execution status code returned by the database operation of the verification system 4. If the status code is "200 OK" or "SUCCESS", it indicates that the database operation was successful, and a change effective notification is generated.

[0082] The change notification is broadcast to all downstream business systems that depend on this verification project via message queues (such as RabbitMQ or Apache Kafka) or HTTP callbacks. The change notification must include at least the unique identifier of the changed project, the effective date of the change, and a summary of the changes.

[0083] Upon receiving a change notification, each downstream business system 5 executes corresponding synchronization update operations based on its own business logic (such as updating the billing item catalog, laboratory prescription dictionary, quality control rules, etc.), and returns a confirmation receipt to the testing system 4 after processing. The confirmation receipt includes at least the identifier of the downstream business system, the reception status (success / failure), and application status feedback. The testing system 4 receives and records the confirmation receipts from each downstream system, and stores them in the audit log of the process instance, completing the multi-level management closed loop of process approval-driven laboratory item changes.

[0084] Through the above steps, this application realizes a complete management process from change application initiation, restricted filling, conditional branch routing, multi-level approval, data write-back execution to downstream system closed-loop confirmation, ensuring that the entire process of inspection project changes is traceable, controllable, and auditable, effectively solving technical problems in the existing technology such as lack of approval control, untraceable changes, coarse-grained access control, fixed and rigid approval paths, and inconsistent data between systems.

[0085] In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments. The computer device can be a server or a terminal. The computer device includes a processor, a memory, an input / output interface (I / O), and a communication interface. The processor, memory, and I / O interface are connected via a system bus, and the communication interface is connected to the system bus via the I / O interface. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device stores data to be processed. The I / O interface of the computer device is used for exchanging information between the processor and external devices. The communication interface of the computer device is used for communicating with an external terminal via a network connection. When the computer program is executed by the processor, it implements the steps in the above-described method embodiments.

[0086] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0087] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0088] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0089] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0090] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0091] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A multi-level management system for variable inspection items based on process approval, characterized in that, include: The form-driven layer is used to generate and render application forms for the inspection project change process; The form-driven layer includes a project change component, which is used to bind to a preset inspection project category and obtain and display the current information data of the specified inspection project through the integration interface layer. Each field inside the project change component is configured with an independent state controller. The form-driven layer also includes a project verification component, which is used to automatically generate simulated data for verification based on the attributes of the project applying for change in the current process before the change is submitted, and to verify historical project data. The process approval engine layer, connected to the form-driven layer, is used to extract the application form submission data and the attribute information of the associated inspection items when the process instance is running, and dynamically select the corresponding multi-level approval flow branch by evaluating the preset conditional expression. And when the process flows to each approval node, based on the three-level mapping relationship of "process node - form - field", node permission instructions are generated and issued to the project change component; An integrated interface layer is connected to both the form-driven layer and the process approval engine layer to enable data communication between the form-driven layer, the process approval engine layer, and the inspection system.

2. The multi-level management system for variable inspection items based on process approval as described in claim 1, characterized in that, The state controller is used to dynamically switch fields to editable, read-only, or hidden states according to the node permission instructions issued by the process approval engine layer.

3. The multi-level management system for variable inspection items based on process approval as described in claim 1, characterized in that, The process approval engine layer is built on the BPMN 2.0 protocol.

4. The multi-level management system for variable inspection items based on process approval as described in claim 1, characterized in that, The process approval engine layer includes: The process template management unit is used to visually configure and modify process templates for creating and modifying inspection projects, and to independently configure the responsible person, approval method, and form permission mapping relationship for each process node. The conditional branch decision unit is used to extract the application form submission data and related inspection item attribute information during process instance execution, and dynamically select the corresponding multi-level approval flow branch by evaluating the preset conditional expression; The permission mapping unit is used to establish and store a three-level mapping relationship of "process node - form - field". When the process flows to each approval node, the three-level mapping relationship is executed to generate permission configuration information for each field and form a node permission instruction, which is then sent to the project change component.

5. The multi-level management system for variable inspection items based on process approval as described in claim 1, characterized in that, The integrated interface layer includes: The inspection project information query interface is used by the project change component to obtain the project master data in the inspection system. The approval result feedback interface is used by the process approval engine layer to call at the end of the process instance to push the approved change dataset to the inspection system.

6. The multi-level management system for variable inspection items based on process approval as described in claim 5, characterized in that, Also includes: The module for executing and confirming changes on the inspection system side; The change execution and confirmation module is used to receive the approval result pushed by the integration interface layer through the approval result feedback interface, and to perform the creation or modification operation of the project in the inspection system according to the approval result; The change execution and confirmation module is also used to send change notifications to downstream business systems and collect change confirmation receipts after the change is completed.

7. A multi-level management method for variable inspection items based on process approval, applied to the system described in any one of claims 1-6, characterized in that, The method includes: Based on the applicant's selection of the project process template, a corresponding process instance is generated, and a change application form is dynamically rendered according to the type of the project process template; wherein, the project process template includes a new inspection project process template and a modified inspection project process template; Obtain the node permission instructions of the node where the process instance is located, dynamically set the corresponding fields in the application form to editable, read-only, or hidden states according to the node permission instructions, and receive the change data entered by the applicant within the editable state field range; Before submitting a change request, the project verification component automatically generates simulated data for verification based on the attributes of the project requesting changes in the current process, and verifies historical project data; once the verification is successful, the process can be submitted. Based on the changed data, the attribute information of the application form submission data and associated inspection items is extracted, and the corresponding multi-level approval flow branch is dynamically selected by evaluating the preset conditional expression to determine the target approval path; The process instance is sequentially transferred to each approval node along the target approval path. When the process is transferred to each approval node, a node permission instruction is generated and issued to the project change component based on the three-level mapping relationship of "process node - form - field". When the process instance reaches the termination node, the changed data and the complete approval trajectory of the process instance are assembled into a change event message, and the change event message is pushed to the inspection information system, triggering the inspection information system to perform the addition or update operation of the project master data according to the changed data.

8. The method for multi-level management of inspection item changes based on process approval as described in claim 7, characterized in that, Also includes: After the change is implemented, the inspection system sends a change notification to the downstream business system and receives a processing confirmation receipt, thus completing the multi-level management closed loop of inspection item changes driven by process approval.

9. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the process approval-driven, variable multi-level management method for inspection items according to any one of claims 7-8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the multi-level management method for variable inspection items based on process approval driven as described in any one of claims 7-8.

Images