A sample collection mistake-proof delivery system and method for a clinical laboratory

Abstract

The application provides a sample collection mistake-proof delivery system and method for a clinical laboratory, acquires an identity of a patient and an identity of a collector, and constructs an original data packet by using the identity of the patient, a current medical order code, the identity of the collector and a precise time stamp. Then, the original data packet is encrypted according to a pre-shared key of a laboratory receiving end to generate a digital envelope, the hash values of the original data packet and the digital envelope are determined, and then the digital envelope, the original data packet and the hash values of the digital envelope are combined into a source credible identification code of the sample. The digital envelope in the source credible identification code is decrypted based on the pre-shared key to restore the corresponding original data packet, and then the content in the decrypted original data packet is compared with the record in a test information system to determine whether they are consistent. By using the scheme of the application, the sample can be collected and delivered in a high-reliability and tamper-proof manner without subverting the existing blood collection operation habits and mainstream consumable systems.

Description

Technical Field

[0001] This application relates to the field of sample delivery technology, and in particular to a sample collection and delivery system and method for laboratory use to prevent errors in sample delivery. Background Technology

[0002] In the field of clinical medical testing, ensuring the uniqueness of sample identity, the accuracy of information transmission, and the traceability of operation links throughout the entire process from sample collection from the patient to laboratory testing is the cornerstone of ensuring medical quality and patient safety. Traditional laboratory sample delivery processes usually rely on manual operation and paper documents in conjunction with simple information technology, which has many inherent defects and risks.

[0003] The current mainstream process has several significant problems: First, the identity verification and information binding process heavily relies on human diligence and proficiency, making it prone to errors such as mislabeling samples in busy clinical environments—collecting the correct sample but labeling it incorrectly, or wrongly associating the sample with another patient's order. Second, the information flow from collection to receipt is unidirectional and fragile. The process lacks a mandatory, non-repudiable electronic means to verify who, when, where, and what order was executed at the collection end. If the test tube label is damaged, blurred, or if there are deviations in information transmission between HIS / LIS, the laboratory will find it difficult to verify the authenticity of the sample source and will be unable to trace the actual situation at the collection site. Finally, the existing process has weak binding and traceability capabilities for operators, making it difficult to accurately pinpoint responsibility at each stage and failing to fundamentally address the issues of credibility and tamper-proofing in the generation of information at the collection source. Therefore, how to achieve highly reliable and tamper-proof sample collection and delivery without disrupting existing blood collection practices and mainstream consumable systems has become a major challenge for the industry. Summary of the Invention

[0004] Based on this, this application provides a laboratory sample collection and delivery system and method for highly reliable and tamper-proof sample collection and delivery without disrupting existing blood collection practices and mainstream consumable systems.

[0005] Firstly, this application provides a method for preventing incorrect sample collection and submission in a laboratory, comprising the following steps: Obtain the patient's identity identifier and associate it with HIS medical orders. At the same time, obtain the collector's identity identifier to complete system login and identity binding. The patient's identity, current medical order code, collector's identity, and precise timestamp are used to construct the original data packet. The original data packet is then encrypted using the pre-shared key at the laboratory receiving end to generate a digital envelope. The hash value of the original data packet and the hash value of the digital envelope are determined, and then the hash value of the digital envelope, the hash value of the original data packet, and the hash value of the digital envelope are combined to form the source trusted identifier code of the sample; After the sample is transported to the laboratory, the digital envelope in the source trusted identifier is decrypted based on the pre-shared key to restore the corresponding original data packet; The contents of the decrypted original data packet are compared with the records in the verification information system. If they match and the data is complete, the packet is quickly registered for receipt. If they do not match or the decryption verification fails, an abnormal event record is generated.

[0006] In some embodiments, the original data packet, constructed from the patient's identity identifier, current medical order code, collector's identity identifier, and precise timestamp, specifically includes: Extract the patient's identification, current medical order code, and the collector's identification; Obtain accurate timestamps through the data acquisition terminal; The patient's identity, current medical order code, collector's identity, and precise timestamp are serialized according to a predetermined format and assembled into an original data packet.

[0007] In some embodiments, encrypting the original data packet based on a pre-shared key at the laboratory receiver to generate a digital envelope specifically includes: Generate a cryptographically secure random number as the symmetric key used in this encryption. The original data packet is encrypted using the symmetric key and the specified symmetric encryption algorithm to obtain the ciphertext. The pre-shared key of the laboratory receiver is read, and then the public key and the specified asymmetric encryption algorithm are used to perform encryption operations on the symmetric key to obtain the key ciphertext; The encrypted data and the encrypted key are assembled according to a predetermined structure and output as the digital envelope.

[0008] In some embodiments, determining the hash value of the original data packet and the hash value of the digital envelope specifically includes: A preset cryptographic hash algorithm is used to calculate the hash value of the digital envelope, and a fixed-length hash value is output as the hash value of the digital envelope. The original data packet is calculated using the same cryptographic hash algorithm, and a fixed-length hash value is output as the hash value of the original data packet.

[0009] In some embodiments, combining the hash value of the digital envelope, the hash value of the original data packet, and the hash value of the digital envelope into a source trusted identifier for the sample specifically includes: Obtain the pre-defined combination format; The digital envelope, the hash value of the original data packet, and the hash value of the digital envelope are encapsulated according to the combined format to generate the source trusted identifier code of the sample.

[0010] In some embodiments, the method further includes: binding the source trusted identifier code with the unique QR code of the corresponding vacuum blood collection tube.

[0011] In some embodiments, after the sample is transported to the laboratory, the method further includes scanning the QR code on the vacuum blood collection tube to retrieve the source credible identification code of the corresponding sample.

[0012] Secondly, this application provides a sample collection and error-proofing system for laboratory use, the system comprising: The acquisition module is used to acquire the patient's identity identifier and associate it with HIS medical orders. At the same time, it acquires the collector's identity identifier to complete system login and identity binding. The processing module is used to construct a raw data packet using the patient's identity identifier, current medical order code, collector's identity identifier, and precise timestamp, and then encrypt the raw data packet according to the pre-shared key of the laboratory receiver to generate a digital envelope; The processing module is further configured to determine the hash value of the original data packet and the hash value of the digital envelope, and then combine the hash value of the digital envelope, the hash value of the original data packet, and the hash value of the digital envelope into a source trusted identifier code for the sample. The processing module is also used to decrypt the digital envelope in the source trusted identifier code based on the pre-shared key after the sample is transported to the laboratory, and restore the corresponding original data packet; The execution module compares the content of the decrypted original data packet with the record in the verification information system. If they match and the data is complete, the data is quickly registered and received. If they do not match or the decryption verification fails, an exception event record is generated.

[0013] Thirdly, this application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method for preventing errors in sample collection and delivery for laboratory use.

[0014] Fourthly, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described method for preventing errors in sample collection and delivery for laboratory use.

[0015] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects: The laboratory sample collection and delivery system and method provided in this application firstly acquires the patient's identity identifier and associates it with the HIS medical order, and simultaneously acquires the collector's identity identifier to complete system login and identity binding. This step enables electronic, multi-verification, and real-time binding of patient identity, medical order, and collector identity before blood collection, thereby improving the accuracy of source information collection and the traceability of operations, eliminating the risk of misidentification and impersonation from the initial stage. Secondly, the patient's identity identifier, current medical order code, collector's identity identifier, and precise timestamp are used to construct an original data packet, which is then processed according to the pre-shared key at the laboratory receiving end. The process begins with encryption to generate a digital envelope. This step aggregates and encrypts scattered key information into a single, unreadable ciphertext carrier, thereby improving the confidentiality and cohesion of the core sampled data, including who, when, for whom, and what medical orders were executed. This prevents information from being stolen or spied on during subsequent transfers, ensuring privacy and data security. Subsequently, the hash value of the original data packet and the hash value of the digital envelope are determined. These three hash values ​​are then combined to form the source trusted identifier code of the sample. This step protects the integrity of the digital envelope by generating and associating its hash value, creating a tamper-proof "electronic envelope." The "electronic seal" is a source trusted identifier code, which enhances the integrity of sampling event data during transmission and storage. Any data tampering will be easily detected, ensuring the reliability of the information certificate. Then, after the sample is transported to the laboratory, the digital envelope in the source trusted identifier code is decrypted based on the pre-shared key to restore the corresponding original data packet. This step enables the laboratory to authorize decryption and integrity verification of the "electronic seal," thereby improving the automation and objectivity of the sample information verification process and ensuring that the original collected information can only be restored when the data source is legitimate and has not been tampered with. Finally, the content of the decrypted original data packet is compared with the verification... If the records in the information system are consistent and the data is complete, the sample is quickly registered and received. If they are inconsistent or the decryption verification fails, an anomaly record is generated. This step enables fully automatic comparison between the decrypted information and the system records. Based on the strict verification results, i.e., successful decryption, completeness, and information consistency, a differentiated processing procedure is triggered, thereby improving the efficiency and accuracy of the laboratory receiving process, quickly releasing compliant samples, and accurately capturing and recording anomalies to guide efficient traceability and handling, forming a closed-loop management system. In summary, the solution proposed in this application can provide highly reliable and tamper-proof sample collection and testing without disrupting existing blood collection operation habits and mainstream consumable systems. Attached Figure Description

[0016] Figure 1 This is an exemplary flowchart of a laboratory sample collection and error-proofing method according to some embodiments of this application; Figure 2 This is a schematic diagram illustrating an application scenario of a sample collection and error-proofing data processing system according to some embodiments of this application; Figure 3 This is a schematic diagram of the process for generating a digital envelope according to some embodiments of this application; Figure 4 This is a schematic diagram of the structure of a laboratory sample collection and error-proofing delivery system according to some embodiments of this application; Figure 5 This is a schematic diagram of the structure of a computer device for implementing a sample collection and error-proofing method for laboratory testing, according to some embodiments of this application. Detailed Implementation

[0017] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0018] refer to Figure 1 The figure is an exemplary flowchart of a laboratory sample collection and error-proofing method according to some embodiments of this application. The laboratory sample collection and error-proofing method mainly includes the following steps: In step 101, the patient's identity is obtained and associated with the HIS medical order. At the same time, the identity of the data collector is obtained to complete the system login and identity binding.

[0019] It should be noted that the HIS medical order in this application refers to a digital instruction issued by a doctor and stored in the hospital information system to guide the execution of test items for a specific patient. Its function is to uniquely and authoritatively define the content and requirements of a test task and serve as the business basis for connecting patient identity with specific test operations.

[0020] In specific implementation, obtaining the patient's identity identifier and associating it with HIS medical orders, while simultaneously obtaining the collector's identity identifier to complete system login and identity binding, can be achieved in the following way: At the sampling point, the collector operates a dedicated collection terminal, which has barcode scanning, data communication, and processing functions. First, using the barcode scanner integrated into the collection terminal, the collector scans the unique barcode printed on the patient's wristband. This unique barcode encodes the patient's identity identifier in the Hospital Information System (HIS). After successful scanning, the collection terminal, through the hospital's internal network, calls the application programming interface of the Hospital Information System to send the patient's identity identifier to query and obtain the list of currently pending laboratory orders. The list of laboratory orders contains at least one order code and corresponding test item information, thereby completing the association between the patient's identity and the medical orders. Simultaneously, to enhance the evidence at the sampling source, the collection terminal can automatically call its camera to capture a digital image of the scene, including the patient's face and the sampling environment. The digital image serves as supplementary visual evidence for this sampling event. Its filename or hash value calculated using a hash algorithm will be temporarily stored locally on the acquisition terminal, ready to be associated with the subsequently generated acquisition event data. Next, the collector completes identity authentication and login with the acquisition terminal through at least one of the following methods: scanning a personal employee ID barcode, entering an employee number and password, or verifying on the integrated fingerprint recognition module. After successful verification, the acquisition terminal establishes a binding relationship between the current session and the collector's identity identifier, and determines that the collector has the authority to perform subsequent sampling operations. Thus, the patient's identity identifier, the associated current medical order code, the collector's identity identifier, and the subsequently acquired precise timestamp together constitute all the necessary source information elements for constructing the original data packet in subsequent steps. All information is prepared before the physical blood collection operation begins to ensure that information binding precedes the logical order of sample generation. Other methods can also be used in other embodiments, which are not limited here.

[0021] It should be noted that this step enables the electronic, multi-verification, and real-time binding of patient identity, medical orders, and collector identity before blood collection, thereby improving the accuracy of source information collection and the traceability of the operation, and eliminating the risk of misidentification and impersonation from the initial stage.

[0022] In some embodiments, reference Figure 2As shown in the figure, this figure is a schematic diagram of the application scenario of the sample collection error prevention and testing data processing system shown in some embodiments of this application. The figure includes three main components: collection device, server and data storage device. The collection device is responsible for collecting the patient's identity and the collector's identity, and sending the collected patient's identity and the collector's identity to the server through the communication network. The sample collection error prevention and testing data processing system runs on the server. The server stores the processing results in the data storage device and visualizes them.

[0023] In step 102, the patient's identity, current medical order code, collector's identity, and precise timestamp are used to construct an original data packet. The original data packet is then encrypted using the pre-shared key of the laboratory receiver to generate a digital envelope.

[0024] In some embodiments, constructing the original data packet using the patient's identity, current medical order code, collector's identity, and precise timestamp can be achieved through the following steps: Extract the patient's identification, current medical order code, and the collector's identification; Obtain accurate timestamps through the data acquisition terminal; The patient's identity, current medical order code, collector's identity, and precise timestamp are serialized according to a predetermined format and assembled into an original data packet.

[0025] It should be noted that the data acquisition terminal in this application refers to a dedicated computing device deployed at the sample collection point, such as the blood collection room, which has the functions of data acquisition, processing, encryption and communication. Its core role is to serve as the starting point of the error prevention process, perform on-site identity verification, information aggregation, cryptographic operations, and complete the initial binding of electronic information and physical test tubes.

[0026] In specific implementation, the extraction of the acquired patient identity identifier, current medical order code, and collector identity identifier can be achieved in the following way: the collection terminal reads the patient identity identifier, current medical order code, and collector identity identifier that have been associated and temporarily stored in step 101 from its running memory. This extraction process is a memory data access operation and does not involve additional network requests or user interaction. It aims to quickly gather the core identity and medical order information elements required to construct the original data packet. Other methods can also be used in other embodiments, which are not limited here.

[0027] In specific implementation, the acquisition of a precise timestamp through the acquisition terminal can be achieved in the following way: the acquisition terminal calls the application programming interface provided by its operating system to obtain a current time value expressed in Coordinated Universal Time (UTC) accurate to milliseconds, which is used as the precise timestamp; the acquisition of the precise timestamp is preferably based on the terminal system clock synchronized by the network time protocol to ensure the time authority; the acquired precise timestamp provides a unique spatiotemporal identifier for this acquisition event. Other methods can also be used in other embodiments, which are not limited here.

[0028] In specific implementation, serializing the patient's identity, current medical order code, collector's identity, and precise timestamp according to a predetermined format and assembling them into a raw data packet can be achieved in the following way: the collection terminal creates a structured data object according to a predefined key-value pair mapping relationship; this data object contains the following required fields: the key "PatientID" corresponds to the patient's identity value, the key "OrderCode" corresponds to the current medical order code value, the key "CollectorID" corresponds to the collector's identity value, and the key "Timestamp" corresponds to the precise timestamp value; in addition, ... As an optional enhancement field, if a digital image of the scene was acquired in step 101, its hash value is added to the data object with the key "ImageHash". Subsequently, the acquisition terminal uses a standard serialization library (such as a JSON serializer or an XML serializer) to convert the structured data object into a continuous, formatted string or binary data block, which is the original data packet. The format of the original data packet is pre-agreed upon between the acquisition terminal and the laboratory receiving end to ensure that it can be correctly deserialized and parsed after subsequent decryption. Other methods can also be used in other embodiments, which are not limited here.

[0029] In some embodiments, reference Figure 3 As shown in the figure, this is a schematic diagram of the process of generating a digital envelope in some embodiments of this application. In this embodiment, the original data packet is encrypted based on the pre-shared key of the laboratory receiving end. The generation of the digital envelope can be achieved by the following steps: In step 1031, a cryptographically secure random number is generated as the symmetric key used for this encryption. In step 1032, the original data packet is encrypted using the symmetric key and the specified symmetric encryption algorithm to obtain the ciphertext. In step 1033, the pre-shared key of the laboratory receiver is read, and then the public key and the specified asymmetric encryption algorithm are used to perform encryption operation on the symmetric key to obtain the key ciphertext; In step 1034, the data ciphertext and the key ciphertext are assembled according to a predetermined structure and output as the digital envelope.

[0030] It should be noted that the laboratory receiving end in this application refers to a dedicated system or device deployed at the sample receiving point of the laboratory department, which has functions of information reading, decryption verification, data comparison and process control. Its core role is to serve as the endpoint verification and decision-making node of the error prevention process, to automatically verify the identity, information integrity and credibility of the delivered samples, and to perform sample reception or anomaly handling based on the verification results. The pre-shared key is the same key that is pre-distributed and stored in the acquisition terminal and the laboratory receiving end through a secure channel. Its role is to provide a common secret basis for encryption and decryption operations, ensuring that only the legitimate system ends can encrypt and protect sensitive data and authorize decryption. The digital envelope refers to the ciphertext data obtained by encrypting the original data packet containing the sampling source information using the pre-shared key. Its role is to securely encapsulate and protect core sampling facts such as "who, when, for whom, and what medical order is being executed" in an unreadable ciphertext form, preventing the information from being stolen or spied on during transmission and storage.

[0031] In specific implementation, generating a cryptographically secure random number as the symmetric key used for this encryption can be achieved in the following way: the acquisition terminal calls the cryptographically secure random number generator interface provided by its operating system kernel. This interface uses a hardware entropy source or a system-level entropy pool to generate an unpredictable random byte sequence. The acquisition terminal requests the generation of a 32-byte (i.e., 256-bit) binary random number through this interface. After successful generation, the random number is temporarily stored in a protected variable in the memory of the acquisition terminal and marked as the symmetric key dedicated to this sampling event. Other methods can also be used in other embodiments, which are not limited here.

[0032] In specific implementation, the encryption operation of the original data packet using the symmetric key and the specified symmetric encryption algorithm to obtain the ciphertext can be achieved in the following way: the encryption service module of the acquisition terminal reads 32 bytes of the symmetric key from memory and simultaneously obtains the original data packet serialized into a UTF-8 encoded string; subsequently, the encryption service module calls a cryptographic library that supports Advanced Encryption Standard (AES) algorithms and specifies that the operation is performed in Galois / counter mode; before the encryption operation starts, the encryption service module generates a random initialization vector of 12 bytes; then, the symmetric key, the initialization vector, and the byte data of the original data packet are used as input to perform encryption and authentication operations in AES-256 Galois / counter mode; this operation outputs two parts: the first part is an encrypted byte sequence with a length related to the original data packet, and the second part is a 16-byte authentication tag; finally, the initialization vector, the encrypted byte sequence, and the authentication tag are concatenated in sequence into a complete binary data block, which is the ciphertext. Other methods can also be used in other embodiments, which are not limited here.

[0033] In specific implementation, the pre-shared key of the laboratory receiving end is read, and then the public key and the specified asymmetric encryption algorithm are used to perform encryption operations on the symmetric key to obtain the key ciphertext. This can be achieved in the following way: the encryption service module accesses the public key file of the laboratory receiving end, which is stored in the secure storage area of ​​the acquisition terminal. This file is stored in X.509 certificate format. The certificate parsing function is used to extract the RSA public key component from the file. Subsequently, the encryption service module calls the RSA encryption function in the asymmetric encryption algorithm library and specifies the use of the optimal asymmetric encryption padding scheme. When the function is called, the 32-byte symmetric key in memory is used as plaintext input, and the parsed RSA public key is used as the encryption key to perform encryption operations. After the operation is completed, a ciphertext data block with a length of 256 bytes is output. This data block is the key ciphertext obtained by encrypting the symmetric key with the receiving end's public key. Other methods can also be used in other embodiments, which are not limited here.

[0034] In specific implementation, assembling the encrypted data and the encrypted key according to a predetermined structure and outputting the digital envelope can be achieved in the following way: The encryption service module first base64 encodes the binary format encrypted data and the encrypted key into two printable ASCII strings; then, according to the encapsulation structure defined in the system design phase, a new JavaScript object representation object is created; in this object, a member with the key name "data" is added, the value of which is the Base64 string of the encrypted data; another member with the key name "key" is added, the value of which is the Base64 string of the encrypted key; finally, the JavaScript object representation serialization function is used to convert this object into a continuous string, which is the final output digital envelope integrating encrypted data and encryption key. Other methods can also be used in other embodiments, which are not limited here.

[0035] It should be noted that this step can aggregate and encrypt scattered key information into a single, unreadable ciphertext carrier, thereby improving the confidentiality and aggregation of the core sampled data, including who, when, for whom, and what medical orders were executed. This prevents information from being stolen or spied on individually during subsequent circulation, thus ensuring privacy and data security.

[0036] In step 103, the hash value of the original data packet and the hash value of the digital envelope are determined, and then the hash value of the digital envelope, the hash value of the original data packet, and the hash value of the digital envelope are combined into the source trusted identifier code of the sample.

[0037] In some embodiments, determining the hash value of the original data packet and the hash value of the digital envelope can be achieved by the following steps: A preset cryptographic hash algorithm is used to calculate the hash value of the digital envelope, and a fixed-length hash value is output as the hash value of the digital envelope. The original data packet is calculated using the same cryptographic hash algorithm, and a fixed-length hash value is output as the hash value of the original data packet.

[0038] In specific implementation, the encryption service module of the acquisition terminal performs the following operations: First, the encryption service module retrieves the serialized original data packet from memory. This original data packet is a string assembled according to the JavaScript object representation format. Simultaneously, it retrieves the generated digital envelope from memory. This digital envelope is a binary data block composed of key ciphertext encrypted using the laboratory receiver's public key and data ciphertext encrypted using a symmetric key, and has been converted to a Base64 encoded string for processing. Next, the encryption service module calls a cryptographic function library that provides an implementation of an encryption hash algorithm conforming to national commercial cryptography standards. The encryption service module specifies the use of the secure hash algorithm 256 function, first decoding the Base64 encoded digital envelope string into original binary data, and then passing it as input to the secure hash algorithm 256 function. The function performs standard padding, block division, and iterative compression calculations to generate a 256-bit binary digest. This digest is then converted into a 64-character hexadecimal string, which is the hash value of the digital envelope and is immediately stored in a memory variable. Subsequently, the encryption service module calls the same secure hash algorithm 256 function from the same cryptographic function library again, this time using the binary form of the original data packet string as input. It performs the exact same hash calculation process to generate another 256-bit binary digest of the same length, which is then converted into another 64-character hexadecimal string. This string is also the hash value of the original data packet and is stored in a memory variable. At this point, the calculation of both hash values ​​is complete. They are then passed along with the digital envelope to the subsequent combination step to generate the source trusted identifier code of the sample. Other methods can be used in other embodiments, and this is not limited here.

[0039] In some embodiments, combining the hash value of the digital envelope, the hash value of the original data packet, and the hash value of the digital envelope into a source trusted identifier for the sample can be achieved by the following steps: Obtain the pre-defined combination format; The digital envelope, the hash value of the original data packet, and the hash value of the digital envelope are encapsulated according to the combined format to generate the source trusted identifier code of the sample.

[0040] It should be noted that the source trusted identifier code in this application refers to a unique identifier string composed of a digital envelope and its corresponding hash value in a predetermined format. Its function is to serve as an tamper-proof and verifiable "electronic seal" that fully represents the encrypted information and integrity certificate of a sampling event. It is the core carrier for realizing the full trusted traceability and verification of samples from the collection end to the laboratory end.

[0041] In specific implementation, combining the hash value of the digital envelope, the hash value of the original data packet, and the hash value of the digital envelope into the source trusted identifier of the sample can be achieved in the following way: the acquisition terminal obtains the predetermined combination format by reading its internal static configuration file or accessing predefined software constants. This combination format is determined as a structured data encapsulation specification during the system design and development stage. Its specific content is: adopting a JavaScript object representation object structure, and explicitly stipulating that the object must contain three key-value pairs, where the key name "ciphertext" is used to store the digital envelope, the key name "hash_data" is used to store the hash value of the original data packet, and the key name "hash_envelope" is used to store the hash value of the digital envelope; subsequently, the software creates a new, empty JavaScript object in memory. The software generates a JavaScript object representation object and assigns the Base64-encoded digital envelope string, temporarily stored in a memory variable, to the object's "ciphertext" key. Next, it assigns the calculated hash value of the original data packet to the object's "hash_data" key. Then, it assigns the calculated hash value of the digital envelope to the object's "hash_envelope" key. Finally, the software calls a standard JSON serialization library to convert (i.e., serialize) the previously filled JavaScript object representation object into a continuous string conforming to the UTF-8 encoding standard. This string is the final generated source trusted identifier code for the sample, which completely encapsulates all core cryptographic data units used for subsequent verification. Other methods can be used in other embodiments, and are not limited here.

[0042] In some embodiments, the source trusted identifier is also bound to the unique QR code of the corresponding vacuum blood collection tube. Specifically, this can be achieved as follows: the data processing module of the acquisition terminal takes the digital envelope and the hash value in memory as input; according to the predetermined combination format, it performs an encapsulation operation: if the format is JavaScript object representation, a new JavaScript object representation object is created, the digital envelope string is assigned to the `ciphertext` key, the hash value string is assigned to the `hash` key, and then the JavaScript object representation object is serialized into a complete string; if the format is a delimiter concatenation string, the digital envelope string, the delimiter, and the hash value string are directly concatenated into a complete string in sequence; the final generated string is the source trusted identifier of the sample; this source trusted identifier completely contains the decryptable information carrier (digital envelope) and the check value (hash value) used to verify its integrity. Other methods can also be used in other embodiments, which are not limited here.

[0043] It should be noted that this step can protect the integrity of digital envelopes by generating and associating their hash values ​​to form an tamper-proof "electronic seal," namely a source trusted identification code. This improves the integrity of sampled event data during transmission and storage, and any tampering with the data will be easily detected, ensuring the reliability of the information credentials.

[0044] In step 104, after the sample is transported to the laboratory, the digital envelope in the source trusted identifier is decrypted based on the pre-shared key to restore the corresponding original data packet.

[0045] In some embodiments, after the sample is transported to the laboratory, before decrypting the digital envelope in the source trusted identifier code based on the pre-shared key to restore the corresponding original data packet, the method further includes scanning the QR code of the vacuum blood collection tube to retrieve the source trusted identifier code of the corresponding sample. Specifically, this can be achieved using the following steps: After the sample is transported to the laboratory, the QR code on the vacuum blood collection tube is scanned using a barcode scanner to obtain the original data of the QR code; The original data of the QR code is sent to the inspection information system to query the source trusted identification code bound to the QR code; Receive a response from the inspection information system and obtain the source trusted identification code bound to the QR code.

[0046] In some embodiments, decrypting the digital envelope in the source trusted identifier code based on the pre-shared key to restore the corresponding original data packet can be achieved by the following steps: The digital envelope, the original data packet hash value, and the digital envelope hash value are extracted from the source trusted identifier code. The received digital envelope is recalculated using a preset cryptographic hash algorithm, and then compared with the parsed digital envelope hash value to verify the integrity of the digital envelope's transmission. If the hash verification of the digital envelope passes, the pre-shared key at the laboratory receiver is used to decrypt the key ciphertext in the digital envelope to obtain the symmetric key; The symmetric key is used to decrypt the ciphertext in the digital envelope to obtain the original data packet; The original data packet obtained from decryption is recalculated using the same cryptographic hash algorithm, and then compared with the hash value of the parsed original data packet to verify the integrity of the original data before encryption. If the hash verification of the original data passes, the original data packet obtained by decryption is deserialized to restore the structured patient identity identifier, current medical order code, collector identity identifier and precise timestamp.

[0047] In specific implementation, decrypting the digital envelope in the source trusted identifier code based on the pre-shared key to restore the corresponding original data packet can be achieved in the following way: First, the laboratory receiving end calls the JSON parsing function library, takes the scanned source trusted identifier code string as input, parses it according to the predefined key-name mapping relationship, extracts the value corresponding to the key name "ciphertext" from the source trusted identifier code string, which is the Base64 encoded digital envelope string, and simultaneously extracts the string corresponding to the key name "hash_data", which is the hash value of the original data packet. The first hash value is denoted as "ciphertext", and the string corresponding to the key "hash_envelope" is extracted. This string is the hash value of the digital envelope and is denoted as "second hash value". Next, to verify the transmission integrity of the digital envelope, the laboratory receiver calls the SHA-256 hash calculation function in the cryptographic function library. It takes the extracted "ciphertext" value, i.e., the binary form of the original Base64 encoded string of the digital envelope, as input to calculate a new 256-bit hash value. This new hash value is then converted to a 64-bit hexadecimal string. Finally, this calculated string is compared with the hash value obtained from the source trusted identifier. The parsed second hash value string is compared character by character. If they match perfectly, the digital envelope is determined to have not been tampered with during transmission, the integrity verification passes, and the program continues. If they do not match, all subsequent processes are immediately terminated, and an exception event record of type "Digital Envelope Integrity Verification Failure" is created in the verification information system. Next, if the digital envelope hash verification passes, the laboratory receiving end decodes the Base64-encoded digital envelope string into a binary data block and parses the data block according to the encapsulation structure agreed upon with the acquisition terminal, separating the data ciphertext and key ciphertext portions. Subsequently, the laboratory receiving end... The receiving end accesses the laboratory receiver's RSA private key securely stored in the local hardware security module through a secure application programming interface (API), and performs operations on the ciphertext portion of the key using the RSA-OAEP padding and decryption algorithm. After successful decryption, the plaintext symmetric key used for this encryption is obtained. Then, the laboratory receiver uses the symmetric key obtained above and specifies the Advanced Encryption Standard (AES) algorithm in Galois / counter mode to perform decryption and authentication operations on the ciphertext portion of the data. If the authentication tag is successfully verified, the decrypted plaintext data, i.e., the serialized original data packet string, is output. If authentication fails, the process is terminated and a "data ciphertext decryption authentication failed" exception is recorded.Subsequently, to verify the integrity of the original data before encryption, the laboratory receiving end again calls the same SHA-256 hash calculation function, taking the binary form of the plaintext string of the decrypted original data packet as input, calculates a new hash value, and converts it to a hexadecimal string. This string is then compared character by character with the first hash value string parsed earliest from the source trusted identifier code. If they are completely identical, it proves that the original data has not been tampered with from collection and construction to encryption, and the integrity verification passes. If they are inconsistent, the process is immediately terminated and an "original data integrity verification failed" exception is recorded, regardless of whether decryption is successful. Finally, only if all the above verification steps are successfully passed, the laboratory receiving end uses a pre-agreed serialization format (e.g., (JSON format) The decrypted and verified plaintext string of the original data packet is deserialized using the corresponding parsing library to restore it into a structured data object. From this data object, the string value of the patient's identity is obtained by accessing the field with the key name "PatientID", the string value of the current medical order code is obtained by accessing the field with the key name "OrderCode", the string value of the collector's identity is obtained by accessing the field with the key name "CollectorID", and the string value of the precise timestamp is obtained by accessing the field with the key name "Timestamp". Thus, the original information from the collection end is completely and structurally restored. Other methods can also be used in other embodiments, which are not limited here.

[0048] It should be noted that this step enables the laboratory to authorize the decryption and integrity verification of the "electronic seal," thereby improving the automation and objectivity of the sample information verification process and ensuring that the original collected information can only be restored when the data source is legitimate and has not been tampered with.

[0049] In step 105, the contents of the decrypted original data packet are compared with the records in the verification information system. If they match and the data is complete, the reception is quickly registered. If they do not match or the decryption verification fails, an abnormal event record is generated.

[0050] In some embodiments, comparing the content of the decrypted original data packet with the record in the verification information system to see if they match, if they match and the data is complete, then quickly registering receipt; if they do not match or the decryption verification fails, then generating an exception event record can be achieved through the following steps: Extract the patient's identity and current medical order code from the successfully restored original data packet; Using the QR code on the currently scanned vacuum blood collection tube as an index, retrieve the associated expected patient identity and medical order code from the laboratory information system; The extracted information is automatically compared with the queried information. The final decision is made based on the comprehensive decryption success indicator, the original data packet hash value verification result, the digital envelope hash value verification result, and the information comparison result. If all verifications pass, the sample reception registration is quickly completed in the inspection information system. If any verification fails, a structured abnormal event record is generated, and subsequent alarms and manual review processes are triggered.

[0051] In practice, using the QR code on the currently scanned vacuum blood collection tube as an index to query the bound expected patient identity and medical order code from the laboratory information system can be achieved in the following way: The verification software at the laboratory receiving end obtains the raw string data contained in the QR code printed on the vacuum blood collection tube through a connected barcode scanner; subsequently, the verification software initiates a Hypertext Transfer Protocol (HTTP) secure request to the laboratory information system server through the hospital's internal network. The application programming interface (API) address and parameter format of this request follow the query specifications pre-provided by the laboratory information system; in the request body, the verification software encapsulates the scanned QR code string as the query keyword; after receiving the request, the laboratory information system retrieves the sample and medical order binding relationship from its database. In the process, the system uses the QR code string as an index to search for the electronic record that is logically associated with the physical test tube, and extracts the bound patient identification string and medical order code string from the record. Finally, the laboratory information system encapsulates these data into a response message in JavaScript object representation format and returns it to the laboratory receiving verification software via the network. The verification software parses the response, extracts the value of the "patientID" field as the expected patient identification, and extracts the value of the "orderCode" field as the expected medical order code. These two string values ​​are temporarily stored in memory variables for subsequent comparison. Other methods can also be used in other embodiments, which are not limited here.

[0052] In specific implementation, the automated comparison of the extracted information with the queried information can be achieved in the following way: the verification software obtains two information sources from memory: the first information source is the "PatientID" field value and the "OrderCode" field value read from the decrypted and restored structured original data packet object, which serve as the patient identification and medical order code of the collection end to be compared, respectively; the second information source is the "patientID" field value and the "orderCode" field value parsed from the query response of the laboratory information system, which serve as the expected patient identification and expected medical order code of the system to be compared, respectively. The verification software calls a string comparison function. First, it performs a character-by-character precise matching comparison between the patient identification string collected from the acquisition end and the expected patient identification string in the system. Then, it performs a character-by-character precise matching comparison between the medical order code string collected from the acquisition end and the expected medical order code string in the system. The comparison function returns two independent Boolean results: the patient identification comparison result and the medical order code comparison result. The verification software determines that the information comparison result is "consistent" only when both comparison results are "true". If either comparison result is "false", the information comparison result is determined to be "inconsistent". Other methods can be used in other embodiments, which are not limited here.

[0053] In specific implementation, the final decision based on the comprehensive decryption success flag, the original data packet hash value verification result, the digital envelope hash value verification result, and the information comparison result can be achieved in the following way: The verification software maintains a global verification status variable, the initial value of which is "passed"; the software sequentially checks the four key status flags set in the previous steps: First, it checks whether the decryption process has been successfully completed and whether the "decryption success flag" has been set. If the flag is false or the decryption process throws an exception, the verification status variable is set to "failed" and the specific reason is recorded; Second, it checks whether the result of recalculating the original data packet hash value is completely consistent with the first hash value parsed from the source trusted identifier code, that is, whether the "original data packet hash value verification result" is true. If it is false, the verification status variable is set to "failed" and the reason is recorded; Third, it checks... The first step is to check whether the recalculated hash value of the digital envelope is completely consistent with the second hash value parsed from the source trusted identifier, i.e., whether the "digital envelope hash value verification result" is true. If it is false, the verification status variable is set to "failure" and the reason is recorded. The second step is to check whether the information comparison result is "consistent". If it is "inconsistent", the verification status variable is set to "failure" and the reason is recorded. After checking the above four conditions in sequence, the final decision logic is as follows: if the global verification status variable always remains "passed", the final decision "all verifications passed" is generated. If the global verification status variable is set to "failed" after any check step, the final decision "verification failed" is generated, along with a record of all detailed reasons for the failure. Other methods can also be used in other embodiments, which are not limited here.

[0054] In practice, if all verifications pass, the sample reception registration is quickly completed in the inspection information system. If any verification fails, a structured exception event record is generated, triggering subsequent alarms and manual review processes. This can be achieved as follows: For the decision branch of "all verifications passed," the verification software sends a reception confirmation request to the inspection information system by calling the sample status update application interface provided by the system. This request includes the currently scanned QR code identifier and the operation timestamp. After receiving the request, the inspection information system updates the status field of the corresponding sample to "received" in its database and records the reception time and the receiving workstation identifier, completing the rapid registration. For the decision branch of "verification failed," the verification software first creates a new record in the local log and the exception event table of the inspection information system. This record is a structured database entry, and its fields include at least: the QR code identifier of the abnormal sample, the exception trigger timestamp, and the exception type description. The software generates a record containing the following information: (e.g., decryption failure, original data hash mismatch, digital envelope hash mismatch, patient identification mismatch, medical order code mismatch, or a combination thereof); actual information parsed from the original data packet; expected information queried from the testing information system; and collection timestamp. After generating the record, the verification software immediately displays a visual alarm on the user interface of the laboratory receiving end, highlighted in red and displayed in a pop-up window, and locks the subsequent automatic processing flow of the sample. Simultaneously, the software pushes an alarm notification containing key information of the abnormal sample and a QR code to the preset responsible personnel's mobile terminal or workstation in real time through the hospital's internal messaging service. In addition, if the original data packet carries a hash value of a scene image, the software automatically sends a request to the image storage server to retrieve the corresponding scene digital image and displays the image in an independent window on the receiving end interface for the receiving personnel to perform manual visual review and final decision. Other methods can also be used in other embodiments, which are not limited here.

[0055] It should be noted that this step enables fully automated comparison of decrypted information with system records, and triggers differentiated processing procedures based on strict verification results, namely, successful decryption, integrity verification, and information consistency. This improves the efficiency and accuracy of the laboratory receiving process, quickly releases compliant samples, accurately captures and records anomalies, guides efficient traceability and handling, and forms a closed-loop management system.

[0056] In another aspect, in some embodiments, this application provides a sample collection and error-proofing system for laboratory use, as described above. Figure 4 The figure is a schematic diagram of a laboratory sample collection and error-proofing delivery system according to some embodiments of this application. The system includes an acquisition module 401, a processing module 402, and an execution module 403, which are described below: The acquisition module 401 in this application is mainly used to acquire the patient's identity identifier and associate it with HIS medical orders. At the same time, it acquires the identity identifier of the collector to complete system login and identity binding. Processing module 402 in this application is mainly used to construct an original data packet by combining the patient's identity identifier, current medical order code, collector's identity identifier and precise timestamp, and then encrypt the original data packet according to the pre-shared key of the laboratory receiving end to generate a digital envelope; The processing module 402 described in this application is further configured to determine the hash value of the original data packet and the hash value of the digital envelope, and then combine the hash value of the digital envelope, the hash value of the original data packet and the hash value of the digital envelope into a source trusted identifier code of the sample; The processing module 402 described in this application is also used to decrypt the digital envelope in the source trusted identifier code based on the pre-shared key after the sample is transported to the laboratory, and restore the corresponding original data packet; The execution module 403 in this application is mainly used to compare the content of the decrypted original data packet with the record in the verification information system. If they are consistent and the data is complete, the data is quickly registered and received. If they are inconsistent or the decryption verification fails, an abnormal event record is generated.

[0057] The modules in the aforementioned laboratory sample collection and error-proofing delivery system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0058] In another embodiment, this application provides a computer device, which may be a server, and its internal structure diagram may be as follows. Figure 5 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computational and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The database stores error-proofing data for sample collection in the laboratory. The network interface communicates with external terminals via a network. When executed by the processor, the computer program implements an error-proofing method for sample collection in the laboratory.

[0059] Those skilled in the art will understand that Figure 5The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0060] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above embodiment of the sample collection and error prevention method for laboratory use.

[0061] In one 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 embodiment of the sample collection and error-proofing delivery method for laboratory use.

[0062] In one embodiment, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps described in the embodiment of the sample collection and error-proofing delivery method for laboratory use.

[0063] Those skilled in the art will understand that all or part of the processes in the methods of 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, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, 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, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0064] 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.

[0065] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for preventing incorrect sample collection and delivery in a laboratory, characterized in that, Includes the following steps: Obtain the patient's identity identifier and associate it with HIS medical orders. At the same time, obtain the collector's identity identifier to complete system login and identity binding. The patient's identity, current medical order code, collector's identity, and precise timestamp are used to construct the original data packet. The original data packet is then encrypted using the pre-shared key at the laboratory receiving end to generate a digital envelope. The hash value of the original data packet and the hash value of the digital envelope are determined, and then the hash value of the digital envelope, the hash value of the original data packet, and the hash value of the digital envelope are combined to form the source trusted identifier code of the sample; After the sample is transported to the laboratory, the digital envelope in the source trusted identifier is decrypted based on the pre-shared key to restore the corresponding original data packet; The contents of the decrypted original data packet are compared with the records in the verification information system. If they match and the data is complete, the packet is quickly registered for receipt. If they do not match or the decryption verification fails, an abnormal event record is generated.

2. The method as described in claim 1, characterized in that, The original data packet, constructed using the patient's identification, current medical order code, collector's identification, and precise timestamp, specifically includes: Extract the patient's identification, current medical order code, and the collector's identification; Obtain accurate timestamps through the data acquisition terminal; The patient's identity, current medical order code, collector's identity, and precise timestamp are serialized according to a predetermined format and assembled into an original data packet.

3. The method as described in claim 1, characterized in that, Encrypting the original data packet using the pre-shared key at the laboratory receiver to generate a digital envelope specifically includes: Generate a cryptographically secure random number as the symmetric key used in this encryption. The original data packet is encrypted using the symmetric key and the specified symmetric encryption algorithm to obtain the ciphertext. The pre-shared key of the laboratory receiver is read, and then the public key and the specified asymmetric encryption algorithm are used to perform encryption operations on the symmetric key to obtain the key ciphertext; The encrypted data and the encrypted key are assembled according to a predetermined structure and output as the digital envelope.

4. The method as described in claim 1, characterized in that, Determining the hash value of the original data packet and the hash value of the digital envelope specifically includes: A preset cryptographic hash algorithm is used to calculate the hash value of the digital envelope, and a fixed-length hash value is output as the hash value of the digital envelope. The original data packet is calculated using the same cryptographic hash algorithm, and a fixed-length hash value is output as the hash value of the original data packet.

5. The method as described in claim 1, characterized in that, Combining the hash value of the digital envelope, the hash value of the original data packet, and the hash value of the digital envelope into the source trusted identifier of the sample specifically includes: Obtain the pre-defined combination format; The digital envelope, the hash value of the original data packet, and the hash value of the digital envelope are encapsulated according to the combined format to generate the source trusted identifier code of the sample.

6. The method as described in claim 1, characterized in that, Also includes: The source trusted identifier is bound to the unique QR code of the corresponding vacuum blood collection tube.

7. The method as described in claim 1, characterized in that, After the sample is transported to the laboratory, the process also includes scanning the QR code on the vacuum blood collection tube to retrieve the source credible identification code of the corresponding sample.

8. A sample collection and error-proofing system for laboratory use, the system comprising: The acquisition module is used to acquire the patient's identity identifier and associate it with HIS medical orders. At the same time, it acquires the collector's identity identifier to complete system login and identity binding. The processing module is used to construct a raw data packet using the patient's identity identifier, current medical order code, collector's identity identifier, and precise timestamp, and then encrypt the raw data packet according to the pre-shared key of the laboratory receiver to generate a digital envelope; The processing module is further configured to determine the hash value of the original data packet and the hash value of the digital envelope, and then combine the hash value of the digital envelope, the hash value of the original data packet, and the hash value of the digital envelope into a source trusted identifier code for the sample. The processing module is also used to decrypt the digital envelope in the source trusted identifier code based on the pre-shared key after the sample is transported to the laboratory, and restore the corresponding original data packet; The execution module compares the content of the decrypted original data packet with the record in the verification information system. If they match and the data is complete, the data is quickly registered and received. If they do not match or the decryption verification fails, an exception event record is generated.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the sample collection and error prevention method for laboratory use as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the sample collection and error prevention method for laboratory use as described in any one of claims 1 to 7.

Images