State code-based archive approval information state maintenance method, system, device and medium

Abstract

The application discloses a state code-based archive examination information state maintenance method, system, device and medium, relates to the technical field of information processing, and comprises the following steps: receiving and analyzing a to-be-examined nurse archive request, extracting the field name and field value of the analyzed nurse archive data, and allocating a corresponding unique identifier; querying a corresponding historical nurse archive under a previous examination node event, comparing the historical field name-hash value mapping table of the historical nurse archive with a target field name-hash value mapping table field by field, and assigning a state code representing state change; generating and storing a multi-level visual identifier for information prompting in an examination interface; and in response to an examination node event of an examination process, and based on the unique identifier and the event type of the examination node event, updating and maintaining the state code of the to-be-examined nurse archive and the corresponding multi-level visual identifier. The application can clearly grasp archive changes and avoid redundant operations of expanding and viewing each column without changes.

Description

Technical Field

[0001] This invention relates to the field of information processing technology, and in particular to a method, system, device, and medium for maintaining the status of document approval information based on status codes. Background Technology

[0002] With the deepening development of medical informatization, medical institutions have gradually realized the electronic management of nurses' records, replacing the traditional paper-based record archiving mode and improving the convenience of record storage and retrieval. Current mainstream nurse record management systems typically include basic functions such as record entry, submission, and approval. Their core approval processes are mostly implemented based on workflow engine configurations. After a nurse submits a record, the system automatically forwards it to the head nurse for initial review, and then pushes it to the nursing department for final review, complying with the data flow control and traceability principles proposed in the "Hospital Information System Data Management Operation Specifications".

[0003] The existing technical solution is a general medical record approval system. Taking the record management system used by a university-affiliated hospital as an example, its nurse record approval module allows nurses to fill in their basic personal information, qualification certificates, work experience, etc., and submit them to the head nurse. After the head nurse completes the review, it is transferred to the nursing department for final review. The system only displays the complete record content and the current approval node on the approval page, without optimizing the information status indicators during the approval process. Approver must compare the differences between the record versions word by word to identify the changed content. However, it takes a lot of time to check the differences between the current submission and the previous version, which is prone to omissions or misreadings. It cannot meet the actual needs of efficient processing in medical personnel management, especially during peak nurse recruitment periods, such as when 20 records pile up, causing the approval cycle to be extended to 17-20 working days. For records that have been rejected and resubmitted, it is impossible to quickly locate the core content modified by the nurse, making it difficult to conduct targeted review work, and only a full review can be repeated.

[0004] Therefore, how to improve the efficiency and accuracy of nurse record approval and reduce the risk of invalid operations and errors in the approval process is a technical problem that needs to be solved in the existing technology. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a method, system, device, and medium for maintaining the status of nurse record approval information based on status codes, which can improve the efficiency and accuracy of nurse record approval and reduce invalid operations and error risks during the approval process. The specific solution is as follows: Firstly, this application discloses a method for maintaining the status of document approval information based on status codes, applied to the backend, including: Receive and parse the nurse file request to be approved, extract the field names and field values ​​of the parsed nurse file data, and assign a corresponding unique identifier to each nurse file data; Iterate through each nurse's record data and use a preset hash algorithm to calculate the hash value of each field to generate a target field name-hash value mapping table; Using nurse identifiers, the system queries the database for historical nurse files corresponding to the previous approval node event, and compares the historical field name-hash value mapping table of the historical nurse files with the target field name-hash value mapping table field by field. Based on the comparison results, a status code representing a status change is assigned to each nurse file data. The status code is used to generate and store a multi-level visual identifier for information prompts in the approval interface; wherein, the multi-level visual identifier includes a column-level identifier for prompting the existence of a changed column and an information-level identifier for distinguishing the type of information change, and the changed column is a grouping obtained by dividing the nurse file data according to business semantics; In response to approval node events in the approval process, the status code and corresponding multi-level visual identifier of the nurse's file to be approved are updated and maintained based on the unique identifier and the event type of the approval node event.

[0006] Optionally, the step of receiving and parsing the nurse file request to be approved, extracting the field names and field values ​​of the parsed nurse file data, and assigning a corresponding unique identifier to each nurse file data includes: Receive a request for a nurse's file to be approved and parse the request to obtain a nurse's file to be approved containing various nurse file data; The field names and field values ​​of each nurse record data in the nurse record to be approved are extracted, and a corresponding unique identifier is assigned to each nurse record data.

[0007] Optionally, the step of traversing each nurse's record data and calculating the hash value of each field using a preset hash algorithm to generate a target field name-hash value mapping table includes: The nurse's file data is serialized into a file object in key-value pair format, and the hash value of each field in the file object is calculated to generate a target field name-hash value mapping table; Accordingly, the process of querying historical nurse records corresponding to the previous approval node event from a preset database using nurse identifiers, and comparing the historical field name-hash value mapping table of the historical nurse records with the target field name-hash value mapping table field by field, to assign a status code representing a status change to each nurse record data based on the comparison results, includes: Based on the nurse's unique identifier in the nurse's file pending approval, the system retrieves historical nurse files submitted after the end of the previous approval node event from the preset database. If the historical nurse's file is not found, the first comparison result is generated; If the historical nurse's file is found, a second comparison result is generated; If the comparison result is the first comparison result, then the status code of all fields of the file object is modified to the new status code, and the nurse file to be approved, the target field name-hash value mapping table, the new status code, the file submission time and the operation log corresponding to the approval node event are stored in the preset database. If the comparison result is the second comparison result, the historical nurse file is serialized to obtain a historical file object in key-value pair format, and the hash value of each field in the historical file object is calculated to generate a historical field name-hash value mapping table. Modify the status code of the nurse's file data corresponding to the target field whose hash value is different from that in the target field name-hash value mapping table and the historical field name-hash value mapping table to a modification status code; Modify the status code of the nurse's file data corresponding to the target field with the same hash value as the target field name-hash mapping table and the historical field name-hash value mapping table to the initial status code.

[0008] Optionally, the step of generating and storing a multi-level visual identifier for information prompting in the approval interface based on the status code includes: When a certain column group has a status code that is either the newly added status code or the modified status code, a prompt symbol is rendered near the column name of the corresponding changed column to obtain a column-level identifier. A first background color is rendered for nurse file data with the status code of "new" or "initial"; a second background color is rendered for nurse file data with the status code of "modified"; and a third background color is rendered for nurse file data with the status code of "final approval".

[0009] Optionally, the approval node events include submission events triggered by the nurse's end, rejection events triggered after processing by the head nurse's end, and final review events triggered after processing by the nursing department's end.

[0010] Optionally, the step of responding to approval node events in the approval process and updating and maintaining the status code and corresponding multi-level visual identifier of the nurse's file to be approved based on the unique identifier and the event type of the approval node event includes: If the current approval node event is the submission event, then after the nurse submits the nurse file to be approved on the nurse's end, the status code assignment operation and the multi-level visual identifier generation operation are triggered. If the current approval node event is the rejection event, then when the nurse file to be approved is rejected and resubmitted, the status code of the changed nurse file data in the nurse file to be approved is updated and the corresponding multi-level visualization identifier is refreshed. If the current approval node event is the final review event, then after the final review is completed and passed at the nursing department, the status codes of all nurse file data will be uniformly updated to the final review passed status code, and the multi-level visualization identifier will be cleared.

[0011] Optionally, the status codes include initial status codes, new status codes, modified status codes, and final approval status codes, wherein, The initial status code is a status code indicating that the nurse's file data has not been changed after the first submission; The newly added status code is a status code that indicates nurse file data that exists in the pending nurse file but does not exist in the historical nurse file; The modified status code is a status code that indicates nurse file data that exists in the historical nurse file and whose data has been changed; The final approval status code indicates the status of the nurse's file data after the final review has been approved.

[0012] Secondly, this application discloses a status code-based system for maintaining the status of document approval information, including: The file acquisition module is used to receive and parse the nurse file request to be approved, extract the field names and field values ​​of the parsed nurse file data, and assign a corresponding unique identifier to each nurse file data. The hash calculation module is used to traverse each nurse's record data and use a preset hash algorithm to calculate the hash value of each field in order to generate a target field name-hash value mapping table. The comparison module is used to query the historical nurse files corresponding to the previous approval node event from the preset database using the nurse identifier, and compare the historical field name-hash value mapping table of the historical nurse files with the target field name-hash value mapping table field by field, so as to assign a status code representing the status change to each nurse file data according to the comparison result. The identifier generation module is used to generate and store multi-level visual identifiers for information prompts in the approval interface based on the status code; wherein, the multi-level visual identifiers include a column-level identifier for indicating that there is a changed column and an information-level identifier for distinguishing the information change category, wherein the changed column is a grouping obtained by dividing the nurse file data according to business semantics; The update module is used to respond to the approval node event of the approval process and update and maintain the status code and corresponding multi-level visual identifier of the nurse's file to be approved based on the unique identifier and the event type of the approval node event.

[0013] Thirdly, this application discloses an electronic device, including: Memory, used to store computer programs; A processor is used to execute the computer program to implement the steps of the aforementioned disclosed method for maintaining the status of archive approval information based on status codes.

[0014] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the steps of the aforementioned disclosed method for maintaining the status of document approval information based on status codes.

[0015] As can be seen, this application discloses receiving and parsing requests for nurse files pending approval, extracting field names and field values ​​from the parsed nurse file data, and assigning a corresponding unique identifier to each nurse file data; traversing each nurse file data and calculating the hash value of each field using a preset hash algorithm to generate a target field name-hash value mapping table; using the nurse identifier to query historical nurse files corresponding to the previous approval node event from a preset database, and comparing the historical field name-hash value mapping table of the historical nurse files with the target field name-hash value mapping table field by field, so as to assign a status code representing a status change to each nurse file data according to the comparison result; generating and storing multi-level visual identifiers for information prompts in the approval interface based on the status codes; wherein, the multi-level visual identifiers include a column-level identifier for prompting the existence of a changed column and an information-level identifier for distinguishing the information change category, the changed column being a group obtained by dividing the nurse file data according to business semantics; responding to the approval node event of the approval process, and updating and maintaining the status code and corresponding multi-level visual identifier of the nurse file pending approval based on the unique identifier and the event type of the approval node event. Therefore, by using unique identifiers to locate and compare the differences of the same information item across different versions, the manual, hourly verification process, which previously required several hours, is transformed into automated computation, shortening the approval time. Simultaneously, the comparison results are directly output as status codes, allowing approvers to focus their review on the changed content and avoiding unnecessary, repetitive full-scale audits. Furthermore, the generated category-level identifiers quickly guide approvers to the category groups containing the changed content at the interface level; while information-level identifiers visually differentiate the types of information changes at the micro level. This dual-layer visualization mechanism significantly reduces the visual search time for approvers, enabling them to clearly understand document changes and completely eliminating the redundant operation of manually opening and viewing unchanged categories one by one. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0017] Figure 1 This application discloses a flowchart of a method for maintaining the status of document approval information based on status codes. Figure 2 This is a schematic diagram of a front-end page for document approval information based on status codes, as disclosed in this application. Figure 3 This is a schematic diagram of the structure of a status code-based archive approval information status maintenance system disclosed in this application; Figure 4 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0018] 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 the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0019] With the deepening development of medical informatization, medical institutions have gradually realized the electronic management of nurses' records, replacing the traditional paper-based record archiving mode and improving the convenience of record storage and retrieval. The current mainstream nurse record management system usually includes basic functions such as record entry, submission, and approval. Its core approval process is mostly implemented based on the configuration of a process engine. For example, after a nurse submits a record, the system automatically transfers it to the head nurse for initial review, and then pushes it to the nursing department for final review, which complies with the principles of "data flow control" and "traceability" proposed in the "Hospital Information System Data Management Operation Specification".

[0020] The existing technical solution is a general medical record approval system. The core functions of this type of system include: structured storage of record data, role-based access control, node-based management of the approval process, and log retention of approval records. Taking the record management system used by a university-affiliated hospital as an example, its nurse record approval module allows nurses to fill in their basic personal information, qualification certificates, work experience, etc., and submit them to the head nurse. After the head nurse completes the review, it is transferred to the nursing department for final review. The system only displays the complete record content and the current approval node on the approval page, without optimizing the information status indicators during the approval process. Approver must compare the differences between the record versions word by word to identify the changed content.

[0021] The existing technology has at least the following drawbacks: 1. Low approval efficiency: Approver needs to spend a lot of time checking the differences between the submitted content and the previous versions. According to statistics from the nursing department of a top-tier hospital, nurse files contain 40 categories and more than 500 pieces of information. It takes an average of 6-7 hours for approvers to complete a full version comparison, and each piece of information takes about 0.6-0.9 minutes to check. Moreover, for every 10 such files reviewed, there are 1-2 instances of missed or misreading, with an error rate of 10%-20%. This is far from meeting the actual needs of "efficient processing" in medical personnel management, especially during peak nurse recruitment periods, such as when 20 files are piled up, the approval cycle is extended to 17-20 working days. 2. Insufficient targeted review and high risk of error: For files that have been rejected and resubmitted, approvers cannot quickly locate the core content that the nurse has modified, making it difficult to conduct targeted review. They can only repeat the full review, which not only increases the workload of approval but also increases the risk of error due to fatigue from repeated review. 3. Disconnect between status indicators and approval process: After the final review of the archives, the system cannot automatically clear the temporary status indicators. These redundant indicators become interfering information in the subsequent process of reviewing, retrieving, and managing archives, affecting the accuracy and conciseness of the archive data presentation. 4. Redundant and ineffective operation processes: When archives are managed in groups by column, the existing system cannot mark "contains changed content" at the column level. Approving personnel must review each column individually, even if there are no changes in that column, increasing a large number of ineffective operation processes and reducing overall work efficiency.

[0022] To address this, the present invention provides a status code-based scheme for maintaining the status of nurse record approval information, which can improve the efficiency and accuracy of nurse record approval and reduce invalid operations and error risks during the approval process.

[0023] like Figure 1 As shown, this invention provides a method for maintaining the status of document approval information based on status codes, applied to the backend, including: Step S11: Receive and parse the nurse file request to be approved, extract the field names and field values ​​of the parsed nurse file data, and assign a corresponding unique identifier to each nurse file data.

[0024] In this embodiment, a request for nurse files to be approved is received and parsed to obtain a nurse file to be approved containing various nurse file data. The field names and values ​​of each nurse file data item in the nurse file to be approved are extracted, and a corresponding unique identifier is assigned to each nurse file data item. It is understood that when a nurse completes the file information entry on the front-end interface and clicks the "Submit" button on the front-end page, the front-end module encapsulates the collected form data into a JSON object and sends it to the back-end server via an HTTP request (request for nurse files to be approved). After receiving the request, the back-end server parses the JSON object and identifies the field names and values ​​corresponding to each nurse file data item. For each nurse file data item, the back-end calls a globally unique identifier generator (such as a UUID) to assign it a unique string identifier, such as "N001-01" to "N001-20". Meanwhile, the database records the unique identifier ID, the nurse identifier ID, field name, field type, and creation time for each piece of information in the unique identifier mapping table. This ensures that all subsequent operations (version comparison, status code binding, identifier rendering, log tracing) can accurately locate the information entity. Each nurse file data refers to the smallest independently manageable data unit that constitutes the nurse's personnel file, including but not limited to structured fields such as name, gender, date of birth, education, major, professional certificate number, registration time, start and end dates of work experience, professional title, training records, and assessment results.

[0025] In this way, by assigning a unique identifier to each piece of information, a state tracking foundation at the information level is built, so that subsequent version comparisons no longer depend on field name matching (which is easily affected by naming inconsistencies or translation differences) or on the order of positions (which is easily affected by the addition or deletion of columns), thereby ensuring the stability and reproducibility of status code assignment.

[0026] Step S12: Traverse each nurse's record data and use a preset hash algorithm to calculate the hash value of each field to generate a target field name-hash value mapping table.

[0027] In this embodiment, the nurse's file data is serialized into a key-value pair format file object, and the hash value of each field in the file object is calculated to generate a target field name-hash value mapping table. It can be understood that after receiving the currently submitted file data, the backend first serializes it into a key-value pair format object (e.g., a Map).<String,String> The algorithm iterates through each field, normalizing the field values ​​(removing leading and trailing spaces, standardizing newline characters to LF, standardizing the date format to "yyyy-MM-dd", and ignoring invisible characters). Then, it uses the MD5 algorithm to calculate the hash value of each field value, resulting in a 32-bit hexadecimal string. This generates a target field name-hash value mapping table, for example, {"Name": "a1b2c3d4e5f6...", "Practitioner Certificate Number": "b2c3d4e5f6g7..."}. This mapping table serves as the baseline data structure for subsequent comparisons.

[0028] In this way, by converting field content into hash values ​​and establishing an explicit mapping relationship between field names and hash values, the comparison process is freed from the constraints of the original text format and relies only on the semantic consistency of the content. This avoids misjudgments caused by input method switching, copying and pasting with invisible characters, automatic formatting by the editor, etc., and ensures the semantic accuracy of status code assignment.

[0029] Step S13: Use the nurse identifier to query the historical nurse file corresponding to the previous approval node event from the preset database, and compare the historical field name-hash value mapping table of the historical nurse file with the target field name-hash value mapping table field by field, so as to assign a status code representing the status change to each nurse file data according to the comparison result.

[0030] In this embodiment, based on the nurse's unique identifier in the nurse's file to be approved, the system queries a preset database for historical nurse files submitted after the end of the previous approval node event. If the historical nurse file is not found, a first comparison result is generated. If the historical nurse file is found, a second comparison result is generated. If the comparison result is the first comparison result, the status code of all fields of the file object is modified to a new status code, and the nurse file to be approved, the target field name-hash value mapping table, the new status code, the file submission time, and the operation log corresponding to the approval node event are stored in the preset database. If the comparison result is the second comparison result, the historical nurse records are serialized to obtain a key-value pair format historical record object, and the hash value of each field in the historical record object is calculated to generate a historical field name-hash value mapping table; the status code of the nurse record data corresponding to the target field whose hash value is different from that in the target field name-hash value mapping table and the historical field name-hash value mapping table is modified to a modified status code; the status code of the nurse record data corresponding to the target field whose hash value is the same as that in the target field name-hash value mapping table and the historical field name-hash value mapping table is modified to an initial status code.

[0031] Understandably, an SQL query is constructed using the nurse identifier (such as employee ID or system ID) as an index. This query retrieves the latest record from the `archive_version` table where `submit_status=1` and `nurse_id=?`, sorts it in reverse chronological order by submission time, and takes the first record. In other words, it queries the database for the most recently successfully submitted historical archive version information (i.e., the version with the earliest submission time and whose approval node is not the final review). If a cache exists (such as `latest_ver:{nurse_id}` stored in Redis), the version ID is retrieved from the cache first, and then the complete data is loaded. The query result may be empty (for the first submission) or it may return a record containing the complete fields and values ​​of the historical archive. If the query result is empty, i.e., the first comparison result is generated (for the first submission), the status code of all information submitted by the nurse is uniformly set to the new status code (01), and the original data of the current submission, the target field name-hash mapping table, the status code, the submission time, and the approval node operation log are all stored in the database. Specifically, this is done through a database transaction and written to both the `archive_version` table and the `field_state_log` table. If a historical version is found, i.e., a second comparison result is generated, the historical version is serialized and a historical field name-hash value mapping table is generated. Then, a field-by-field comparison is performed: for fields that exist in the current version but not in the historical version, they are determined to be newly added fields and given a new status code (01); for fields that exist in both versions but have different hash values, they are determined to be modified fields and given a modified status code (10), and the historical field value is recorded; for fields that exist in both versions and have the same hash value, they are determined to be unchanged fields and given an initial status code (00) and recorded as "unchanged" in the field_state_log table. These fields do not need to be reviewed in subsequent approvals. After the comparison is completed, the system binds the unique identifier of each piece of information with the corresponding status code and stores it in the status code record table. It should be noted that the nurse file to be approved refers to the complete set of data uploaded by the nurse who actively triggers the submission operation in this approval process; "the most recently successfully submitted historical file version information refers to the set of historical file data under the same nurse ID that has been successfully submitted and completed at least one approval node (such as the head nurse's initial review) before the current submission time.It is important to note that the nurse identifier is a unique code that identifies a nurse. It can be an employee ID number assigned by the hospital's HR system, a national ID number, or an auto-incrementing primary key ID within the system. This identifier is generated when a nurse first registers or joins the company and remains active throughout the entire lifecycle of their personnel file operations. "The most recently submitted historical file version information" refers to the first valid file record retrieved from the database after sorting by submission time in reverse chronological order using the nurse identifier as the query condition. Its data structure is consistent with the current submission version, containing a complete set of fields and their corresponding values. This query operation is completed by the application service layer calling the Data Access Object (DAO).

[0032] This approach ensures consistency of the comparison subjects by using the nurse's identifier as the unique anchor point to locate historical versions, avoiding mismatches across nurses. Simultaneously, limiting the comparison to "most recent" ensures that status determination is always based on the nearest reference benchmark, aligning with the actual business logic of "current vs. previous" in the approval process. Through inter-version field-level comparison, abstract information change behaviors are transformed into calculable, storable, and traceable status codes. This makes the "whether a change has occurred" business judgment independent of human experience, possessing determinism and verifiability, and providing reliable data input for the generation of visual identifiers.

[0033] Step S14: Generate and store a multi-level visual identifier for information prompting in the approval interface based on the status code; wherein, the multi-level visual identifier includes a column-level identifier for prompting the existence of a changed column and an information-level identifier for distinguishing the information change category, and the changed column is a grouping obtained by dividing the nurse file data according to business semantics.

[0034] In this embodiment, when a certain column group contains a status code that is either the "new" status code or the "modified" status code, a prompt symbol is rendered near the column name of the corresponding changed column to obtain a column-level identifier. A first background color is rendered for nurse file data with the "new" or "initial" status code, a second background color is rendered for nurse file data with the "modified" status code, and a third background color is rendered for nurse file data with the "final approval" status code. It can be understood that when generating the identifier instruction, the status codes of all current nurse information are first obtained from the status code record, and each piece of information is assigned to the corresponding column according to preset column grouping rules (such as field name prefixes or configuration tables). Then, a logical OR operation is performed on each column: such as... Figure 2The image shows one possible display result on the front-end page. If at least one piece of information in this category has a status code of 01 or 10, a red dot instruction is generated for the category. The instruction includes the category name and red dot style parameters. Simultaneously, the system iterates through each piece of information and generates a corresponding background color instruction based on its status code: 01 or 00 corresponds to light blue (#E3F2FD), 10 corresponds to light yellow (#FFF3CD), and 11 corresponds to default white (#FFFFFF). These instructions are encapsulated in JSON format and pushed to the front-end via HTTP response or WebSocket. After receiving the instructions, the front-end parses and dynamically modifies the DOM elements: adding HTML and CSS classes for the red dot element to the category title and adding corresponding background color CSS classes to the information cells. All rendering operations are completed on the front-end and do not affect back-end data storage. Based on the generated status code set, the multi-level visualization identifier module is called to generate front-end rendering instructions. First, each piece of information is traversed according to the preset column grouping rules (such as basic information, education experience, professional qualifications, etc.). It is determined whether there is information with a status code of "new" (01) or "modified" (10) under each column. The status code is represented by a two-bit binary code, where the initial status code is "00", the new status code is "01", the modification status code is "10", and the final approval status code is "11". This encoding method facilitates database field definition, status logic judgment and front-end rendering strategy mapping. If it exists, a column-level identifier instruction is generated, instructing the front-end to render a red dot prompt (diameter 8px, color #FF4757) to the right of the column title. Simultaneously, information-level identification instructions are generated based on the status code of each piece of information: for information with a status code of "new" (01) or "initial" (00), the instruction requires the front end to render the background color of the cell or form item containing the information as light blue (#E3F2FD); for information with a status code of "modified" (10), the instruction requires the background color to be rendered as light yellow (#FFF3CD); for information with a status code of "final approval" (11), the instruction requires the default background color to be restored (white #FFFFFF). These instructions are pushed to the front end via WebSocket or HTTP response. After parsing the instructions, the front end dynamically updates the CSS class of the DOM elements to achieve the real-time presentation of visual identification. Among them, the column-level identification refers to the visual prompt generated after status aggregation judgment by column group in the front-end display interface of nurse files; the information-level identification refers to the differentiated background color rendering applied to each piece of file information with a unique identifier based on its current status code.

[0035] In this way, by presenting both column-level and information-level dual identifiers in a coordinated manner, the need for rapid positioning of the scope of changes at the macro level can be met, while also supporting the goal of accurate identification of the content of changes at the micro level. This significantly shortens the visual search path for approval personnel and improves the efficiency of human-computer interaction.

[0036] Step S15: In response to the approval node event of the approval process, update and maintain the status code and corresponding multi-level visual identifier of the nurse's file to be approved based on the unique identifier and the event type of the approval node event.

[0037] In this embodiment, the approval node events include submission events triggered by the nurse's end, rejection events triggered after processing by the head nurse's end, and final review events triggered after processing by the nursing department's end.

[0038] Furthermore, a submission event refers to a system-level event triggered by a nurse clicking the "Submit" button on the front-end interface after completing or modifying the file information. This event carries the nurse's unique identifier, the current file version number, the submission timestamp, and the client device type information. A rejection event refers to a business event generated by the process engine after the head nurse performs a rejection operation and fills in the rejection comments on the approval interface. This event includes the head nurse's unique identifier, the rejection time, the rejection reason code, and the associated original submission version number. A final review event refers to a process termination event generated after the nursing department reviewer confirms that the file content is correct and clicks "Final Review Passed" during the final review stage. This event is generated after passing the verification by a dual-person review mechanism (optional) or automatic risk control rules. This event includes the nursing department reviewer's unique identifier, the final review time, the approval conclusion code, and a summary of the full approval log. In addition, the nurse's end refers to the front-end interaction module deployed on nurses' personal work terminals (including PC browsers and mobile nursing apps), which has the ability to edit files, cache locally, save offline drafts, and bind submission actions. This end does not directly perform status code calculations or database writes, but is only responsible for collecting user operation intentions, encapsulating raw data, and initiating event notifications. The head nurse's end refers to a dedicated approval front-end configured for department head nurses, integrating initial review opinion input, historical version comparison view, one-click rejection quick operation, and a standardized tag library for rejection reasons. After the user completes the rejection operation and submits, this end will trigger the process engine to call the approval rule service, generate a rejection event with contextual semantics, and ensure that the event content is traceable, auditable, and can be linked to subsequent status updates. The nursing department's end refers to the high-privilege approval terminal used by the nursing management department, which has the functions of parallel review of multiple files, batch final review, mandatory review prompts before final review, and electronic signature embedding. After the reviewer completes the final review operation, this end not only generates a final review event, but also simultaneously pushes a "full status normalization" instruction to the dynamic control module and initiates a final review snapshot archiving request to the data storage module.

[0039] In this way, by clearly defining three types of approval process node events—submission events, rejection events, and final review events—and limiting their triggering entities to the nurse's end, head nurse's end, and nursing department end respectively, a status response mechanism driven by role behavior is constructed. On this basis, each end carries an identity identifier, timestamp, operation context, and structured business parameters when triggering an event, enabling the dynamic identification control module to accurately identify the source of the event, determine the process stage, and match the corresponding control strategy. This ensures that status code updates and visual identification evolution strictly follow the closed loop of approval logic, avoiding misjudgment of status or identification stagnation caused by ambiguous event definitions.

[0040] In this embodiment, if the current approval node event is the submission event, after the nurse submits the nurse's file to be approved on the nurse's end, a status code allocation operation and a multi-level visual identifier generation operation are triggered. It can be understood that the built-in event listening mechanism continuously receives approval process node events pushed by the process engine module. The process engine module is built based on the BPMN 2.0 standard. When the nurse clicks the "Submit" button, the head nurse selects "Reject" and submits, and the nursing department clicks "Final Approval," the process engine generates submission, rejection, and final approval events respectively, and publishes them to the identifier dynamic management module via a message middleware, i.e., a message queue (e.g., RabbitMQ). The identifier dynamic management module, acting as a consumer, subscribes to these events, parses the event type and nurse ID, and triggers corresponding status code updates and identifier refresh operations: if the event is a submission event, the version comparison engine is immediately invoked to perform a comparison step, assigning status codes to all information of the nurse's currently submitted version. After completion, the multi-level visual identifier module is invoked to generate full identifier instructions, which are pushed to the front end via WebSocket or HTTP response. The front end renders red dots and background colors according to the instructions. Meanwhile, the version information, status code records, and operation logs submitted this time will be persisted to the database; by establishing a binding relationship between the submission event and the status code allocation and identifier generation, it is ensured that each valid submission can reflect the information change status in a timely and accurate manner, providing a deterministic and predictable visual basis for subsequent approval processes.

[0041] In this embodiment, if the current approval node event is the rejection event, when the nurse file to be approved is rejected and resubmitted, the status code of the changed nurse file data in the nurse file to be approved is updated and the corresponding multi-level visual identifier is refreshed. It can be understood that if the event is a rejection event, only the rejection mark is recorded and the status code is not updated temporarily. When the nurse resubmits, in the version comparison, only the status code of the changed information is updated to the modified status code (10), and the original status code of other information (such as 01 or 00) is retained. Then, only the information with updated status codes is generated with background color refresh instructions, and the column red dots are recalculated. If there were originally 01 / 10 status codes under a certain column, but all of them become 00 after this update, the column red dots are cleared; otherwise, they are retained. These incremental instructions are pushed to the front end, and the front end only updates the corresponding DOM to avoid the performance overhead and visual flicker caused by a full refresh.

[0042] In this way, by leveraging the "minimum granularity update" mechanism under rejection events, the changes can be precisely focused on while preserving the semantic continuity of historical identifiers, significantly reducing the workload of repetitive review and avoiding identifier jitter and visual interference caused by full refresh.

[0043] In this embodiment, if the current approval node event is the final review event, after the final review is completed and passed at the nursing department end, the status codes of all nurse file data are uniformly updated to the final review passed status code, and the multi-level visualization identifiers are cleared. It can be understood that if the event is a final review event, an atomic transaction is initiated, and the status codes of all current nurse information are uniformly updated to the final review passed status code (11). At the same time, a global clear command is pushed to the front end, and the command content is {"action":"clear_all_identifiers","nurseId":"xxx"}. After receiving the command, the front end traverses all column title elements and removes the red dot DOM; it traverses all information cells, removes all background color-related CSS classes, and restores the default style. After the operation is completed, the final review result and identifier clearing log are written to the database to ensure audit traceability and ensure that the file view is concise and accurate after the final review. It should be noted that all status code updates, identifier command issuance, and operation log recording are executed atomically in the database transaction to ensure data consistency.

[0044] By deeply coupling the lifecycle of status codes and identifiers to approval process node events, a paradigm upgrade from static identifiers to process-aware dynamic identifiers is achieved. This makes visual prompts no longer isolated data byproducts, but an organic component of the approval business flow, truly achieving the goal of human-machine collaboration where what is seen is what is reviewed and what is reviewed is what is needed.

[0045] By acquiring each piece of information and assigning a unique identifier, an information-level tracking anchor is established. Through field-level comparison between the current and historical versions, the ambiguous "whether it has changed" judgment is transformed into a precise status code. By combining column-level red dots with information-level background colors, the semantics of the status code are transformed into a visually perceptible signal for approvers. Furthermore, by responding to three types of process events—submission, rejection, and final review—a closed-loop control system is achieved, from the generation and partial updating of the identifier to its global clearing. The entire technology chain is interconnected, forming a complete closed loop from front-end data collection and mid-platform comparison and calculation to interface presentation and feedback. This effectively solves the problem in existing technologies where approvers cannot intuitively and quickly locate newly added and modified information, avoiding the inefficiency and error risks caused by manually comparing version differences. It provides a feasible, reusable, and scalable technical path for intelligent approval of medical personnel files.

[0046] In this embodiment, the initial status code indicates that the nurse file data has not been changed after the first submission; the new status code indicates that the nurse file data exists in the nurse file pending approval but does not exist in the historical nurse file; the modified status code indicates that the nurse file data exists in the historical nurse file and the nurse file data has been changed; and the final approval status code indicates that the nurse file data has passed the final review. Understandably, this solution also provides status codes including initial status codes, new status codes, modified status codes, and final approval status codes. An initial status code indicates information that has not changed since the first submission; a new status code indicates newly generated information not recorded in previous submissions; a modified status code indicates information that exists in previous submissions but whose content has changed; and a final approval status code indicates information that has passed final approval. Specifically, the initial status code identifies information that exists in both the current and most recent historical submissions and whose field content has not changed; the new status code identifies information that appears for the first time in the current submission but has no corresponding record in the most recent historical submission; the modified status code identifies information that exists in the current submission but has a changed hash value in at least one key field, indicating a substantial change in content; and the final approval status code indicates that the information has completed the nursing department's final review process along with the entire nurse's file, obtained final approval validity, and entered a stable archiving state. Furthermore, the initial status code indicates information that has not been changed since the first submission. "Information that has not been changed since the first submission" means that the information existed when the nurse first submitted the file and that no field content has changed in subsequent submissions, with the field name-hash value mapping table remaining consistent across versions. Information identified by this status code does not require in-depth review during the approval process; only its continued validity needs to be confirmed. By using the simultaneous fulfillment of the conditions of initial submission and no change as prerequisites for assigning the initial status code, information that has been rejected and resubmitted but not modified is avoided from being misjudged as new information, ensuring the semantic rigor and process consistency of the status classification. The new status code indicates newly generated information that is not recorded in previous submission versions. "Newly generated" means that the information is explicitly entered in the current submission version or automatically generated by the system (such as an automatically generated file creation timestamp), and its unique identifier has no historical matching record in the database. "No record in previous submission versions" means that when querying historical version data using the nurse's identifier as an index, no historical entries containing the same unique identifier or the same field combination are retrieved. Information identified by this status code requires in-depth verification of its authenticity and compliance during the approval process.

[0047] In this way, by combining unique identifier matching and field-level existence judgment, misidentification caused by differences in field naming or null value filling is eliminated, ensuring the accuracy of new information determination.

[0048] A modification status code indicates information that exists in historical submissions but has undergone content changes. "Existing in historical submissions" means the unique identifier of the information already exists in a corresponding historical version record in the database. "Content changes" means that the hash value of at least one key field in the current submission is inconsistent with the hash value of the corresponding field in a historical version. Key fields include, but are not limited to, name, ID number, education level, professional certificate number, professional title, and date of employment. The information identified by this status code requires close comparison of the content before and after the change during the approval process to verify the basis for the modification and approval authority. By using field-level hash comparison results to drive the generation of modification status codes, without relying on manual annotation or text similarity calculations, misjudgments caused by format adjustments (such as adding or deleting spaces, or converting capitalization) are avoided, improving the robustness of change recognition.

[0049] The "Final Review Passed" status code indicates that the information has passed the final review. "Final Review Passed" means that the nurse's file to which this information belongs has completed all final review operations and generated a valid approval conclusion by the nursing department, and the workflow engine has pushed the "Final Review Event" to the dynamic management module. This status code has global coverage and is irreversible. Once assigned a value, it terminates all status update behaviors for this information within the current approval cycle and triggers the operation commands to clear the column-level prompt symbol and restore the information-level background color to its default value. Setting the "Final Review Passed" status code as the highest priority status ensures strong coverage in the status code update logic, guaranteeing that the validity of the final review is rigidly reflected at the data level and preventing status residue due to workflow anomalies or concurrent operations.

[0050] By defining four mutually exclusive and complete status code values ​​and their precise semantic boundaries, a classification system covering the entire lifecycle of nurse records' information status is constructed. Initial status codes and newly added status codes jointly support differentiated presentation in the first submission scenario, modified status codes precisely anchor the focus of change, and final approval status codes achieve closed-loop control of approval. The four types of status codes follow a unidirectional evolution logic (00, 01, 10, 11) and do not support reverse degradation, thereby ensuring the determinism of status flow and audit traceability. This status system directly supports the generation of column-level and information-level visual identifiers as described in Example 4 above, as well as the dynamic control mechanism driven by approval node events as described in Example 6 above, enabling approvers to quickly understand the context of information changes based on status semantics, significantly reducing cognitive load and the risk of operational errors.

[0051] As can be seen, this application discloses receiving and parsing requests for nurse files pending approval, extracting field names and field values ​​from the parsed nurse file data, and assigning a corresponding unique identifier to each nurse file data; traversing each nurse file data and calculating the hash value of each field using a preset hash algorithm to generate a target field name-hash value mapping table; using the nurse identifier to query historical nurse files corresponding to the previous approval node event from a preset database, and comparing the historical field name-hash value mapping table of the historical nurse files with the target field name-hash value mapping table field by field, so as to assign a status code representing a status change to each nurse file data according to the comparison result; generating and storing multi-level visual identifiers for information prompts in the approval interface based on the status codes; wherein, the multi-level visual identifiers include a column-level identifier for prompting the existence of a changed column and an information-level identifier for distinguishing the information change category, the changed column being a group obtained by dividing the nurse file data according to business semantics; responding to the approval node event of the approval process, and updating and maintaining the status code and corresponding multi-level visual identifier of the nurse file pending approval based on the unique identifier and the event type of the approval node event. Therefore, by using unique identifiers to locate and compare the differences of the same information item across different versions, the manual, hourly verification process, which previously required several hours, is transformed into automated computation, shortening the approval time. Simultaneously, the comparison results are directly output as status codes, allowing approvers to focus their review on the changed content and avoiding unnecessary, repetitive full-scale audits. Furthermore, the generated category-level identifiers quickly guide approvers to the category groups containing the changed content at the interface level; while information-level identifiers visually differentiate the types of information changes at the micro level. This dual-layer visualization mechanism significantly reduces the visual search time for approvers, enabling them to clearly understand document changes and completely eliminating the redundant operation of manually opening and viewing unchanged categories one by one.

[0052] like Figure 3 As shown, the present invention also discloses a status code-based document approval information status maintenance system, comprising: The file acquisition module 11 is used to receive and parse the nurse file request to be approved, extract the field names and field values ​​of the parsed nurse file data, and assign a corresponding unique identifier to each nurse file data. The hash calculation module 12 is used to traverse each nurse's record data and use a preset hash algorithm to calculate the hash value of each field in order to generate a target field name-hash value mapping table. The comparison module 13 is used to query the historical nurse files corresponding to the previous approval node event from the preset database using the nurse identifier, and compare the historical field name-hash value mapping table of the historical nurse files with the target field name-hash value mapping table field by field, so as to assign a status code representing the status change to each nurse file data according to the comparison result. The identifier generation module 14 is used to generate and store multi-level visual identifiers for information prompts in the approval interface based on the status code; wherein, the multi-level visual identifiers include a column-level identifier for prompting the existence of a changed column and an information-level identifier for distinguishing the information change category, wherein the changed column is a grouping obtained by dividing the nurse file data according to business semantics; The update module 15 is used to respond to the approval node event of the approval process and update and maintain the status code and corresponding multi-level visual identifier of the nurse's file to be approved based on the unique identifier and the event type of the approval node event.

[0053] Therefore, assigning a unique ID and binding a status code to each piece of information ensures that the status is traceable and locatable; transforming abstract status into a red dot and background color that the front end can perceive, achieving dual prompts for the scope and type of change; using approval events as the driving anchor point to achieve a closed-loop response of identifier generation, partial update, and global clearing; ensuring the accuracy and robustness of status determination from the data source through field-level hash comparison; providing standardized and configurable process scheduling capabilities, and sending event signals to the identifier dynamic management module in a low-intrusive manner; and having each module collaborate through clearly defined input / output interfaces, without sharing memory or cross-calling core logic, which not only meets the requirements of medical systems for high stability and strong auditability, but also ensures the portability and deployability of the technical solution across different HIS platforms.

[0054] Furthermore, embodiments of this application also disclose an electronic device, Figure 4 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0055] Figure 4 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the status code-based document approval information status maintenance method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0056] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0057] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0058] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0059] The operating system 221 manages and controls the various hardware devices and computer programs 222 on the electronic device 20 to enable the processor 21 to perform calculations and processing on the massive amounts of data 223 in the memory 22. It can be Windows Server, Netware, Unix, Linux, etc. The computer program 222, in addition to including a computer program capable of performing the status code-based document approval information status maintenance method disclosed in any of the foregoing embodiments, may further include computer programs capable of performing other specific tasks. The data 223 may include data received by the electronic device from external devices, as well as data collected by its own input / output interface 25.

[0060] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned method for maintaining the status of document approval information based on status codes. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0061] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0062] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly in hardware, software modules executed by a processor, or a combination of both. The software module may be located in random access memory (RAM), memory, read-only memory (ROM), electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, removable disks, CD-ROMs (Compact Disc-Read Only Memory), or any other form of storage medium known in the art.

[0063] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0064] The solution provided by the present invention has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for maintaining the status of document approval information based on status codes, characterized in that, Applied to the backend, including: Receive and parse the nurse file request to be approved, extract the field names and field values ​​of the parsed nurse file data, and assign a corresponding unique identifier to each nurse file data; Iterate through each nurse's record data and use a preset hash algorithm to calculate the hash value of each field to generate a target field name-hash value mapping table; Using nurse identifiers, the system queries the database for historical nurse files corresponding to the previous approval node event, and compares the historical field name-hash value mapping table of the historical nurse files with the target field name-hash value mapping table field by field. Based on the comparison results, a status code representing a status change is assigned to each nurse file data. The status code is used to generate and store a multi-level visual identifier for information prompts in the approval interface; wherein, the multi-level visual identifier includes a column-level identifier for prompting the existence of a changed column and an information-level identifier for distinguishing the type of information change, and the changed column is a grouping obtained by dividing the nurse file data according to business semantics; In response to approval node events in the approval process, the status code and corresponding multi-level visual identifier of the nurse's file to be approved are updated and maintained based on the unique identifier and the event type of the approval node event.

2. The method for maintaining the status of document approval information based on status codes according to claim 1, characterized in that, The process of receiving and parsing the nurse file request to be approved, extracting the field names and field values ​​of the parsed nurse file data, and assigning a corresponding unique identifier to each nurse file data includes: Receive a request for a nurse's file to be approved and parse the request to obtain a nurse's file to be approved containing various nurse file data; The field names and field values ​​of each nurse record data in the nurse record to be approved are extracted, and a corresponding unique identifier is assigned to each nurse record data.

3. The method for maintaining the status of document approval information based on status codes according to claim 1, characterized in that, The process of traversing each nurse's record and calculating the hash value of each field using a preset hash algorithm to generate a target field name-hash value mapping table includes: The nurse's file data is serialized into a file object in key-value pair format, and the hash value of each field in the file object is calculated to generate a target field name-hash value mapping table; Accordingly, the process of querying historical nurse records corresponding to the previous approval node event from a preset database using nurse identifiers, and comparing the historical field name-hash value mapping table of the historical nurse records with the target field name-hash value mapping table field by field, to assign a status code representing a status change to each nurse record data based on the comparison results, includes: Based on the nurse's unique identifier in the nurse's file pending approval, the system retrieves historical nurse files submitted after the end of the previous approval node event from the preset database. If the historical nurse's file is not found, the first comparison result is generated; If the historical nurse's file is found, a second comparison result is generated; If the comparison result is the first comparison result, then the status code of all fields of the file object is modified to the new status code, and the nurse file to be approved, the target field name-hash value mapping table, the new status code, the file submission time and the operation log corresponding to the approval node event are stored in the preset database. If the comparison result is the second comparison result, the historical nurse file is serialized to obtain a historical file object in key-value pair format, and the hash value of each field in the historical file object is calculated to generate a historical field name-hash value mapping table. Modify the status code of the nurse's file data corresponding to the target field whose hash value is different from that in the target field name-hash value mapping table and the historical field name-hash value mapping table to a modification status code; Modify the status code of the nurse's file data corresponding to the target field with the same hash value as the target field name-hash mapping table and the historical field name-hash value mapping table to the initial status code.

4. The method for maintaining the status of document approval information based on status codes according to claim 3, characterized in that, The process of generating and storing multi-level visual identifiers for information prompts in the approval interface based on the status code includes: When a certain column group has a status code that is either the newly added status code or the modified status code, a prompt symbol is rendered near the column name of the corresponding changed column to obtain a column-level identifier. A first background color is rendered for nurse file data with the status code of "new" or "initial"; a second background color is rendered for nurse file data with the status code of "modified"; and a third background color is rendered for nurse file data with the status code of "final approval".

5. The method for maintaining the status of document approval information based on status codes according to claim 1, characterized in that, The approval node events include submission events triggered by the nurse's end, rejection events triggered after processing by the head nurse's end, and final review events triggered after processing by the nursing department's end.

6. The method for maintaining the status of document approval information based on status codes according to claim 5, characterized in that, The process of responding to approval node events in the approval process and updating and maintaining the status code and corresponding multi-level visual identifier of the nurse's file to be approved based on the unique identifier and the event type of the approval node event includes: If the current approval node event is the submission event, then after the nurse submits the nurse file to be approved on the nurse's end, the status code assignment operation and the multi-level visual identifier generation operation are triggered. If the current approval node event is the rejection event, then when the nurse file to be approved is rejected and resubmitted, the status code of the changed nurse file data in the nurse file to be approved is updated and the corresponding multi-level visualization identifier is refreshed. If the current approval node event is the final review event, then after the final review is completed and passed at the nursing department, the status codes of all nurse file data will be uniformly updated to the final review passed status code, and the multi-level visualization identifier will be cleared.

7. The method for maintaining the status of document approval information based on status codes according to any one of claims 1 to 6, characterized in that, The status codes include initial status codes, new status codes, modified status codes, and final approval status codes, wherein, The initial status code is a status code indicating that the nurse's file data has not been changed after the first submission; The newly added status code is a status code that indicates nurse file data that exists in the pending nurse file but does not exist in the historical nurse file; The modified status code is a status code that indicates nurse file data that exists in the historical nurse file and whose data has been changed; The final approval status code indicates the status of the nurse's file data after the final review has been approved.

8. A status code-based system for maintaining the status of document approval information, characterized in that, include: The file acquisition module is used to receive and parse the nurse file request to be approved, extract the field names and field values ​​of the parsed nurse file data, and assign a corresponding unique identifier to each nurse file data. The hash calculation module is used to traverse each nurse's record data and use a preset hash algorithm to calculate the hash value of each field in order to generate a target field name-hash value mapping table. The comparison module is used to query the historical nurse files corresponding to the previous approval node event from the preset database using the nurse identifier, and compare the historical field name-hash value mapping table of the historical nurse files with the target field name-hash value mapping table field by field, so as to assign a status code representing the status change to each nurse file data according to the comparison result. The identifier generation module is used to generate and store multi-level visual identifiers for information prompts in the approval interface based on the status code; wherein, the multi-level visual identifiers include a column-level identifier for indicating that there is a changed column and an information-level identifier for distinguishing the information change category, wherein the changed column is a grouping obtained by dividing the nurse file data according to business semantics; The update module is used to respond to the approval node event of the approval process and update and maintain the status code and corresponding multi-level visual identifier of the nurse's file to be approved based on the unique identifier and the event type of the approval node event.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor is configured to execute the computer program to implement the steps of the status code-based document approval information status maintenance method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the steps of the status code-based document approval information status maintenance method as described in any one of claims 1 to 7.

Images