Immutable Ledger-Based Workflow Management for Patient Samples

Abstract

Blockchain-based workflow management for patient samples. In one embodiment, for each of a plurality of first devices, a request for a unique sample identifier is received from the first device, and in response to the request, a unique sample identifier is generated and sent to the first device. Then, for each of a plurality of second devices and for each of a plurality of interactions, interaction information is received from the second device, a transaction is generated based on the interaction information, and the transaction is recorded in an immutable ledger. The interaction information can include a unique sample identifier, a user identifier, a location, an event type, and a timestamp.

Description

Technical Field

[0001] The embodiments described herein generally relate to workflow management, and more particularly to immutable ledger-based workflow management for samples such as tissue specimens from patients. Background Art

[0002] In the context of asset management, an immutable ledger is a promising tool. Specifically, the use of an anti-modification ledger (i.e., implemented as a blockchain or a directed acyclic graph (DAG)) effectively ensures accurate and immutable tracking of assets. Such tracking is particularly useful in tracking samples from collection to archival, such as those collected on microscope slides for digital pathology and other medical uses.

[0003] However, the medical context poses unique privacy issues for specimen tracking. Specifically, personally identifiable health information is regulated by, for example, the Health Insurance Portability and Accountability Act (HIPAA). For this reason, a public ledger of health information related to a patient's specimen should not be provided. Summary of the Invention

[0004] Accordingly, systems, methods, and non-transitory computer-readable media for immutable ledger-based workflow management of patient samples (e.g., tissue specimens) are disclosed.

[0005] In one embodiment, a method is disclosed that includes using at least one hardware processor of a user device to: for each of a plurality of first devices, receive, via at least one network, a request for a unique sample identifier from the first device, and in response to the request, generate a unique sample identifier and send the generated unique sample identifier to the first device via at least one network; and, for each of a plurality of second devices, for each of a plurality of interactions, receive, via at least one network, interaction information for the interaction from the second device, where the interaction information includes a unique sample identifier, a user identifier, a location, an event type, and a timestamp; generate a transaction from the interaction information and record the transaction in an immutable ledger. The immutable ledger can be a blockchain or a directed acyclic graph.

[0006] In one embodiment, the method further includes: using at least one hardware processor to analyze the transactions in the immutable ledger to calculate one or more metrics for the interactions represented by the transactions. The one or more metrics can include throughput rates for one or more of a specific user identifier, location, or event type.

[0007] In one embodiment, the method further includes: using at least one hardware processor to retrieve a history that includes all transactions in the immutable ledger associated with a specific unique sample identifier. The method may also include: using at least one hardware processor to display, in a graphical user interface, a representation of the history and a digital image of the sample identified by the specific unique sample identifier.

[0008] In one embodiment, the method further includes: using at least one hardware processor of a server system to: receive, via at least one network, a request from a user to access the immutable ledger; and in response to the request, provide the user with read-only access to only a subset of the transactions in the immutable ledger while preventing the user from accessing any other transactions in the immutable ledger.

[0009] These methods may be embodied in executable software modules of a processor-based system (such as a server), and / or in executable instructions stored in a non-transitory computer-readable medium. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Details of the structure and operation of the present invention can be gathered in part by studying the accompanying drawings, in which like reference numerals refer to like parts, and in which:

[0011] Figure 1A and Figure 1B is a block diagram illustrating an example infrastructure according to an embodiment, in which one or more of the processes described herein may be implemented;

[0012] Figure 2 is a block diagram illustrating an example processing system according to an embodiment, through which one or more of the processes described herein may be executed;

[0013] Figure 3 is a flowchart illustrating a process for workflow management based on an immutable ledger according to an embodiment; and DETAILED DESCRIPTION

[0014] In one embodiment, a system, method, and non-transitory computer-readable medium for immutable ledger-based workflow management for patient samples (e.g., tissue specimens) are disclosed. As used herein, the term "immutable ledger" refers to a virtual ledger in which past transactions (i.e., transactions that have been added to the ledger) cannot be modified due to practical limitations on computing resources. Thus, the term "immutable ledger" may refer to a virtual ledger in which past transactions are theoretically modifiable, provided that such modification is practically impossible.

[0015] After reading this specification, it will be apparent to those skilled in the art how to implement the present invention in various alternative embodiments and alternative applications. However, although various embodiments of the present invention will be described herein, it should be understood that these embodiments are presented by way of example and illustration only and not by way of limitation. Thus, the detailed description of the various embodiments should not be construed as limiting the scope or breadth of the present invention as set forth in the appended claims.

[0016] I. System Overview

[0017] 1.1. Infrastructure

[0018] Figure 1A An example system for blockchain-based workflow management for patient samples (e.g., tissue specimens) according to an embodiment is illustrated. The backbone of the workflow management is the blockchain network 100. The blockchain network 100 may include a plurality of systems 110 connected as nodes in a peer-to-peer network. The systems 110 may be connected via any one or more wired or wireless, public or private networks including the Internet, and may communicate via any standard or proprietary communication protocol. The systems 110 may include one or more entities involved in collecting and processing samples, one or more entities manufacturing devices for collecting and processing samples, and / or networked computers of third parties (e.g., personal computers, servers, etc.). In one embodiment, the blockchain network 100 may be implemented using open source technologies such as IBM's Hyperledger Fabric.

[0019] Each node (i.e., system 110) within the blockchain network 100 includes a complete copy of the blockchain 120. The blockchain 120 represents a ledger of all transactions for those samples whose workflow involving the samples is managed by the blockchain network 100. As is well known in the prior art, the blockchain 120 is an open distributed ledger resistant to modification. Specifically, the blockchain 120 includes a plurality of blocks arranged in chronological order, which are linked together using cryptography. As transactions are created, batches of valid transactions are packed together with the cryptographic hash added to the latest block of the blockchain 120 into a new block. Then the cryptographic hash of the new block is generated and the new block with its cryptographic hash is added to the blockchain 120. In theory, the blockchain 120 can be changed. However, since these blocks are linked together via their cryptographic hashes, in order to change the blockchain 120, the entire blockchain 120 would need to be recalculated, making such a task computationally impractical.

[0020] In blockchain network 100, each node (i.e., system 110) is capable of verifying transactions, generating new blocks, and broadcasting the generated blocks to other nodes. Since multiple nodes can generate and broadcast new blocks, a consensus method is used to select the next block to be added to blockchain 120. For example, in a blockchain using the proof-of-work method, temporary forks may result in different nodes having different versions of blockchain 120, but ultimately the chain with the most cumulative proof-of-work will win. In one embodiment, blockchain network 100 utilizes the proof-of-stake method, in which nodes are selected to produce the next valid block in blockchain 120 based on their stake in blockchain 120 (e.g., wealth and / or age). The proof-of-stake method prevents malicious actors by ensuring that malicious actors have a stake in the integrity of blockchain 120.

[0021] In one embodiment, the physical computing resources required for blockchain 120 are provided as a standard client service (e.g., executed on each of multiple user devices 130), and this standard client service operates as part of blockchain network 100. In this case, access to blockchain network 100 may depend on the user continuing to provide mining capabilities (e.g., on their user device 130).

[0022] Generally speaking, blockchain 120 is open and can be viewed by anyone who can access a system 110 storing a copy of blockchain 120. However, the parties to each transaction can be anonymous. In one embodiment, software (e.g., in client application 132) can be provided that allows a particular user to view, search, and otherwise organize or manage all transactions related to that user on blockchain 120 (e.g., all transactions involving the user's electronic address or other identifier or within the user's responsibilities or permissions).

[0023] In one embodiment, blockchain 120 utilizes a cryptocurrency similar to Bitcoin, which can be transferred between the e-wallets of parties. The cryptocurrency can be used for value transactions associated with test samples. For example, as part of a transaction (e.g., outsourcing testing), one laboratory can use the cryptocurrency to pay another laboratory, an insurance company may use the cryptocurrency to pay hospital bills, and a social healthcare system (e.g., Medicare / Medicaid) can use the cryptocurrency to reimburse a patient's medical bills. Additionally, an insurance company can review each transaction suite recorded in the ledger of blockchain 120 (e.g., including transactions for surgeries, primary laboratory tests, outsourced laboratory tests, and / or other paid services within the chain of events leading to a diagnosis), and use the cryptocurrency to pay for each transaction suite. In one embodiment, the cryptocurrency can also be mined to provide an incentive for parties to lend their computing resources to blockchain network 100.

[0024] In an alternative embodiment, another implementation or type of immutable ledger can be used to record each of the described transactions. Figure 1B An example system for immutable ledger-based workflow management for patient samples (e.g., tissue specimens) according to one embodiment is illustrated, which utilizes a directed acyclic graph (DAG). For example, instead of blockchain 120, an alternative embodiment can use a DAG, such as Tangle TM . A DAG is a hierarchical structure of nodes without any cycles. A DAG can be beneficial if a large number of users is expected. In contrast to a blockchain, a DAG becomes faster as the number of users increases and does not require miners. However, a DAG is more vulnerable to attacks than a blockchain when the network size is small. In a DAG, in order for a user to add a transaction, the user must approve two randomly selected unconfirmed transactions (e.g., using the Markov chain Monte Carlo (MCMC) algorithm, which ensures that the user does not pick the user's own transaction). Like a blockchain, a DAG can utilize a cryptocurrency (e.g., IOTA in TangleTM).

[0025] Regardless of the specific immutable ledger used, transactions in the immutable ledger can include the collection of samples (e.g., via surgery), the processing of samples (e.g., preparing and mounting specimens on slides), the archiving of samples (e.g., in physical or digital storage), etc. Each transaction can identify the sample(s) involved in the transaction, the party or parties involved in the transaction, the location (e.g., the location of scanning, data entry, or other events that generate the transaction), the transaction or event type (e.g., the type of interaction involved in the transaction), and the time (e.g., a timestamp representing the date and time of scanning, data entry, or other events that generate the transaction). Each transaction can also include any additional information related to the transaction, such as the identifier of the operator who performed the interaction represented by the transaction, the current temperature during the interaction represented by the transaction, the lot number of the reagents or other consumables used during the interaction represented by the transaction, etc.

[0026] (Multiple) user devices 130 communicate with the distributed network 100 via one or more wired or wireless, public or private networks including the Internet. (Multiple) user devices 130 can include any one or more types of computing devices capable of wired and / or wireless communication, including but not limited to desktop computers, laptop computers, tablet computers, smart phones or other mobile phones, servers, game consoles, televisions, set-top boxes, kiosks, point-of-sale terminals, etc. However, in a preferred embodiment, (multiple) user devices 130 include wireless devices (such as smart phones or tablet computers) that communicate via a wireless network (e.g., cellular and / or Wi-Fi TM network) and include a camera or other device (e.g., a laser scanner, such as one mounted in a wand) capable of reading machine-readable markings (e.g., barcodes, quick response (QR) codes, radio frequency identification (RFID) tags, etc.). Each user device 130 can store and execute a client application 132 that implements one or more of the functions described herein.

[0027] (Multiple) instruments 140 process the samples described herein. For example, (multiple) instruments 140 can include those from Leica Biosystems TM)The provided tissue processing system and / or staining system. As an example, instrument 140 can include the BOND-III fully automated IHC and ISH stainer from Leica Biosystems, Aperio GT450, and so on. For privacy or other reasons, some instruments such as instrument 140A may be offline, so they cannot communicate with the distributed network 100. Other instruments such as instruments 140B and 140D may be online, so they can communicate with the distributed network 100 via one or more wired or wireless, public or private networks including the Internet. In either case, each instrument 140 can store and execute software 142 that implements one or more of the functions described herein, including separate processes depending on whether the instrument 140 is online or offline.

[0028] 1.2. Example processing devices

[0029] Figure 2 is a block diagram illustrating an example wired or wireless system 200 that can be used in conjunction with various embodiments described herein. For example, system 200 can be used as or in conjunction with one or more of the functions, processes, or methods described herein (e.g., storing and / or executing client application 132 and / or software 142, or one or more modules of client application 132 and / or software 142), and can represent components of the distributed network 100, system(s) 110, user device(s) 130, instrument(s) 140, and / or other processing devices described herein. System 200 can be a server or any conventional personal computer, or any other processor-enabled device capable of wired or wireless data communication. Other computer systems and / or architectures can also be used, which will be clear to those skilled in the art.

[0030] System 200 preferably includes one or more processors, such as processor 210. Additional processors can be provided, such as an auxiliary processor for managing input / output, an auxiliary processor for performing floating-point mathematical operations, a dedicated microprocessor with an architecture suitable for rapidly executing signal processing algorithms (e.g., a digital signal processor), a subordinate processor subordinate to the main processing system (e.g., a backend processor), an additional microprocessor or controller for a dual or multiprocessor system, and / or a coprocessor. Such auxiliary processors can be discrete processors or can be integrated with processor 210. Examples of processors that can be used with system 200 include, but are not limited to processors, Core processors and processors, all of which are available from Intel Corporation in Santa Clara, California.

[0031] The processor 210 is preferably connected to the communication bus 205. The communication bus 205 may include data channels for facilitating the transfer of information between the storage and other peripheral components of the system 200. In addition, the communication bus 205 may provide a set of signals for communicating with the processor 210, including a data bus, an address bus, and / or a control bus (not shown). The communication bus 205 may include any standard or non-standard bus architecture, such as, for example, a bus architecture compliant with: Industry Standard Architecture (ISA), Extended Industry Standard Architecture (EISA), Micro Channel Architecture (MCA), Peripheral Component Interconnect (PCI) local bus, standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE), including IEEE 488 General-Purpose Interface Bus (GPIB), IEEE 696 / S-100, etc.

[0032] The system 200 preferably includes a main memory 215 and may also include an auxiliary memory 220. The main memory 215 provides storage for instructions and data for programs executed on the processor 210, such as one or more of the functions and / or modules discussed herein. It should be understood that the programs stored in the memory and executed by the processor 210 may be written and / or compiled in any suitable language, including but not limited to C / C++, Java, JavaScript, Perl, Visual Basic,.NET, etc. The main memory 215 is typically a semiconductor-based memory, such as dynamic random access memory (DRAM) and / or static random access memory (SRAM). Other semiconductor-based memory types include, for example, synchronous dynamic random access memory (SDRAM), Rambus dynamic random access memory (RDRAM), ferroelectric random access memory (FRAM), etc., including read-only memory (ROM).

[0033] The auxiliary memory 220 may optionally include an internal medium 225 and / or a removable medium 230. The removable medium 230 is read from and / or written to in any well-known manner. The removable storage medium 230 may be, for example, a tape drive, a compact disc (CD) drive, a digital versatile disc (DVD) drive, other optical drives, a flash drive, etc.

[0034] The auxiliary memory 220 is a non-transitory computer-readable medium having computer-executable code (e.g., the disclosed software modules) and / or other data stored thereon. The computer software or data stored on the auxiliary memory 220 is read into the main memory 215 for execution by the processor 210.

[0035] In an alternative embodiment, the secondary storage 220 may include other similar components for allowing a computer program or other data or instructions to be loaded into the system 200. Such components may include, for example, a communication interface 240 that allows software and data to be transferred from an external storage medium 245 to the system 200. Examples of the external storage medium 245 may include an external hard disk drive, an external optical drive, an external magneto-optical drive, and the like. Other examples of the secondary storage 220 may include semiconductor-based memories such as programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), and flash memory (a block-oriented memory similar to EEPROM).

[0036] As mentioned above, the system 200 may include a communication interface 240. The communication interface 240 allows software and data to be transferred between the system 200 and external devices (such as a printer), a network, or other information sources. For example, computer software or executable code may be transferred from a network server (such as the platform 110) to the system 200 via the communication interface 240. Examples of the communication interface 240 include a built-in network adapter, a network interface card (NIC), a Personal Computer Memory Card International Association (PCMCIA) network card, a CardBus network adapter, a wireless network adapter, a Universal Serial Bus (USB) network adapter, a modem, a wireless data card, a communication port, an infrared interface, an IEEE 1394 FireWire, and any other device capable of interfacing the system 200 with a network (such as the network 120) or other computing devices. The communication interface 240 preferably implements industrially promulgated protocol standards such as the Ethernet IEEE 802 standards, Fibre Channel, Digital Subscriber Line (DSL), Asymmetric Digital Subscriber Line (ADSL), Frame Relay, Asynchronous Transfer Mode (ATM), Integrated Digital Services Network (ISDN), Personal Communication Services (PCS), Transmission Control Protocol / Internet Protocol (TCP / IP), Serial Line Internet Protocol / Point-to-Point Protocol (SLIP / PPP), etc., but may also implement custom or non-standard interface protocols.

[0037] The software and data transferred via the communication interface 240 are typically in the form of electrical communication signals 255. These signals 255 may be provided to the communication interface 240 via a communication channel 250. In one embodiment, the communication channel 250 may be a wired or wireless network (such as the (multiple) networks 120) or any other type of communication link. The communication channel 250 carries the signals 255 and may be implemented using various wired or wireless communication means, including, by way of example only, wires or cables, optical fibers, conventional telephone lines, cellular telephone links, wireless data communication links, radio frequency (“RF”) links, or infrared links.

[0038] Computer-executable code (e.g., a computer program or software module such as the disclosed application) is stored in the main memory 215 and / or the secondary memory 220. A computer program may also be received via the communication interface 240 and stored in the main memory 215 and / or the secondary memory 220. Such a computer program, when executed, causes the system 200 to perform the various functions of the disclosed embodiments described elsewhere herein.

[0039] In this specification, the term "computer-readable medium" is used to refer to any non-transitory computer-readable storage medium for providing computer-executable code and / or other data to or within the system 200. Examples of such media include the main memory 215, the secondary memory 220 (including the internal memory 225, the removable media 230, and the external storage media 245), and any peripheral device (including a network information server or other network device) communicatively coupled to the communication interface 240. These non-transitory computer-readable media are components for providing executable code, programming instructions, software, and / or other data to the system 200.

[0040] In embodiments implemented using software, the software may be stored on a computer-readable medium and loaded into the system 200 via the removable media 230, the I / O interface 235, or the communication interface 240. In such embodiments, the software is loaded into the system 200 in the form of an electrical communication signal 255. When executed by the processor 210, the software preferably causes the processor 210 to perform one or more of the processes and functions described elsewhere herein.

[0041] In one embodiment, the I / O interface 235 provides an interface between one or more components of the system 200 and one or more input and / or output devices. Example input devices include, but are not limited to, sensors, keyboards, touchscreens or other touch-sensitive devices, biometric sensing devices, computer mice, trackballs, pen-based pointing devices, etc. Examples of output devices include, but are not limited to, other processing devices, cathode ray tubes (CRTs), plasma displays, light-emitting diode (LED) displays, liquid crystal displays (LCDs), printers, vacuum fluorescent displays (VFDs), surface conduction electron emitter displays (SEDs), field emission displays (FEDs), etc. In some cases, such as in the case of a touch panel display (e.g., in a smart phone, a tablet computer, or other mobile device), the input and output devices may be combined.

[0042] System 200 may also include an optional wireless communication component that facilitates wireless communication over a voice network and / or a data network (e.g., in the case of user system 130). The wireless communication component includes an antenna system 270, a radio system 265, and a baseband system 260. In system 200, radio frequency (RF) signals are transmitted and received in the air by antenna system 270 under the management of radio system 265.

[0043] In one embodiment, antenna system 270 may include one or more antennas and one or more multiplexers (not shown) that perform a switching function to provide transmit and receive signal paths to antenna system 270. In the receive path, the received RF signal may be coupled from the multiplexer to a low noise amplifier (not shown) that amplifies the received RF signal and sends the amplified signal to radio system 265.

[0044] In an alternative embodiment, radio system 265 may include one or more radios configured to communicate over various frequencies. In one embodiment, radio system 265 may combine a demodulator (not shown) and a modulator (not shown) in one integrated circuit (IC). The demodulator and modulator may also be separate components. In the incoming path, the demodulator strips the RF carrier signal, leaving a baseband received audio signal that is sent from radio system 265 to baseband system 260.

[0045] If the received signal contains audio information, then baseband system 260 decodes the signal and converts it to an analog signal. The signal is then amplified and sent to a speaker. Baseband system 260 also receives analog audio signals from a microphone. These analog audio signals are converted to digital signals and encoded by baseband system 260. Baseband system 260 also encodes the digital signals for transmission and generates a baseband transmitted audio signal that is routed to the modulator section of radio system 265. The modulator mixes the baseband transmitted audio signal with the RF carrier signal to generate an RF transmitted signal that is routed to antenna system 270 and may be passed through a power amplifier (not shown). The power amplifier amplifies the RF transmitted signal and routes it to antenna system 270, where the signal is switched to an antenna port for transmission.

[0046] The baseband system 260 is also communicatively coupled to a processor 210, which can be a central processing unit (CPU). The processor 210 can access data storage areas 215 and 220. The processor 210 is preferably configured to execute instructions (i.e., computer programs or software modules such as the disclosed applications) that can be stored in the main memory 215 or the secondary memory 220. The computer programs can also be received from the baseband processor 260 and stored in the main memory 210 or the secondary memory 220, or executed after being received. When such computer programs are executed, the system 200 is enabled to perform the various functions of the disclosed embodiments.

[0047] 2.. Process Overview

[0048] Embodiments of a process for immutable ledger-based workflow management for a patient sample (e.g., a tissue specimen) will now be described in detail. It should be understood that the described process can be embodied in one or more software modules executed by one or more hardware processors (e.g., processor 210), such as software applications (e.g., client application 132 and / or software 142) discussed herein. The described process can be implemented as instructions represented in source code, object code, and / or machine code. These instructions can be executed directly by the (one or more) hardware processors, or alternatively, can be executed by a virtual machine operating between the object code and the hardware processor. Additionally, the disclosed applications can be built on top of or interact with one or more existing systems.

[0049] Alternatively, the described process can be implemented as hardware components (e.g., general-purpose processors, integrated circuits (ICs), application-specific integrated circuits (ASICs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic, etc.), combinations of hardware components, or combinations of hardware and software components. To clearly illustrate the interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps are generally described herein in terms of their functionality. Whether this functionality is implemented as hardware or software depends on the particular application and the design constraints imposed on the overall system. A person skilled in the art can implement the described functionality in different ways for each particular application, but such implementation decisions should not be construed as causing a departure from the scope of the present invention. Additionally, the functional grouping within a component, block, module, circuit, or step is for ease of description. A particular function or step can be moved from one component, block, module, circuit, or step to another without departing from the present invention.

[0050] In addition, although the processes described herein are illustrated with a particular arrangement and order of steps, each process may be implemented with fewer, more, or different steps and with different arrangements and / or orders of steps. Further, it should be understood that any step that does not depend on the completion of another step may be performed before, after, or in parallel with that other independent step, even if the steps are described or illustrated in a particular order.

[0051] 2.1. Workflow Tracking

[0052] Figure 3 FIG. 300 is a flowchart of a process for workflow tracking based on an immutable ledger according to an embodiment. In one embodiment, the immutable ledger represents all "touchpoints" for each sample from collection through analysis to archival. Each touchpoint may be represented as a transaction in the immutable ledger, where the transaction includes a timestamp indicating the time of occurrence of the touchpoint, an identifier of the party handling the sample at the touchpoint (e.g., surgeon, technician, archivist, etc.), an identifier of the sample being processed at the touchpoint, the location of the touchpoint, the temperature of the sample at the touchpoint, and so on. Each transaction may also include additional information, such as the results from one or more tests (e.g., readings from an analyzer performed on the sample, including manually dictated or recorded reports, documents, or official reports from a pathologist or other medical professional). A set of touchpoints (e.g., from collection to archival) for a given sample may be referred to as a "transaction suite". Tracking the touchpoints allows for tracking metrics for each sample, such as the time between extraction of the sample and placement of the sample in formalin (e.g., by calculating the difference between the timestamp of the transaction recording the extraction of a particular sample and the timestamp of the transaction recording the placement of that particular sample in formalin).

[0053] In one embodiment, the workflow tracked for each sample may include collection of the sample, preparation of the sample, mounting of the sample (e.g., on a slide), imaging of the sample (e.g., via an automated slide scanning system), testing of the sample, archival of the sample, etc. The archival process may include physical archival of the sample (e.g., within a facility) and / or archival of the digital images of the sample.

[0054] In step 310, a sample is associated with an identifier that uniquely identifies the sample from all other samples. The sample identifier can also encode relationships between samples (e.g., by including the same segment within a prefix or suffix as one or more other sample identifiers), such as split samples that together constitute a case, where the split samples are too large to process the entire or multiple samples from an individual patient. Each sample identifier can be encoded into a machine-readable marker, such as a barcode or QR code, which can be applied to the sample holder. For example, the machine-readable marker can be printed on a label that is applied to a glass microscope slide holding the sample. Thus, the machine-readable marker can be read via a reading device, which in the context of a barcode or QR code can include a barcode reader or a camera. Alternatively, the machine-readable marker can be a radio-frequency identification (RFID) tag or other wireless transmitter that transmits a signal encoding the unique identifier, which can be wirelessly read by an antenna-based reading device (e.g., an RFID interrogator).

[0055] A unique identifier for a given sample can be obtained at the same time as the sample is acquired. For example, before, during, or after collecting the sample, a user (e.g., a surgeon, nurse, or other individual collecting the sample) can interact with the user device 130, which communicates with the distributed network 100, to obtain a new unique identifier. The issuance of the new unique identifier can be automatically recorded as a transaction in an immutable ledger at the time of issuance. Once obtained, the user device 130 can provide the unique identifier to the user (e.g., via the graphical user interface of the client application 132) and / or encode the unique identifier into a machine-readable marker to be applied to the sample (e.g., by initiating the printing of a label with the machine-readable marker). Additionally, when laboratory work is standardized, a human-readable version of the unique identifier can be combined with the machine-readable marker and applied to the sample together with the machine-readable marker to form a machine-readable and human-readable marker. The user can then apply the marker to the sample holder (e.g., by adhering the printed label with the marker to the label portion of the slide holding the sample).

[0056] In step 320, process 300 waits to read a unique sample identifier at the point of contact. The point of contact can include any interaction with the sample, including, for example, collection of the sample, any processing of the sample (e.g., digital imaging, laboratory testing, etc.), archiving of the sample, and so on. Reading can include manual scanning (e.g., using a camera of user device 130, a laser scanning wand, etc.), manual input (e.g., using an input device of user device 130), and / or automatic scanning of machine-readable markings encoding the unique sample identifier (e.g., by online instrument 140). For an online instrument (e.g., instruments 140B and 140D in FIG. 1), the instrument 140 can scan the machine-readable markings. This scanning can be performed manually using a wand or other scanning device attached to or integrated into the instrument 140, or automatically by the instrument 140 after the sample has been loaded into the instrument 140. If a unique sample identifier is read at the point of contact (i.e., "yes" in step 320), then process 300 proceeds to step 330. Otherwise (i.e., "no" in step 320), process 300 continues to wait to read a unique sample identifier at the point of contact.

[0057] In step 330, each read is transmitted as a transaction to distributed network 100 (e.g., incorporated into a new block on blockchain 120 or a new node in a DAG). This communication can occur in real time or near real time relative to the time the read occurs. Specifically, the unique sample identifier of the sample can be packaged with additional information into a message that is transmitted to distributed network 100 (e.g., transmitted to system 110), which packages the information from the message into a transaction that is incorporated into an immutable ledger. In one embodiment, this additional information includes a user identifier (e.g., identifying the user or user device 130 associated with the point of contact), a location (e.g., identifying the location of the point of contact, such as using a facility and / or terminal identifier), an event type (e.g., indicating the type of interaction with the sample at the point of contact), and a timestamp (e.g., indicating the time of interaction with the sample at the point of contact). Alternatively or additionally, the additional information can include other information (e.g., details of the interaction with the sample, such as the test or other processing being performed, temperature or other environmental metrics at the point of contact, etc.).

[0058] Additional information can be obtained automatically and / or manually. At least some of the information can be manually input by the user via the graphical user interface of the client application 132 on the user device 130, while other information can be automatically obtained or inferred. Alternatively, all of the information can be automatically obtained, or all of the information can be manually obtained. As an example, the user identifier can be automatically determined based on the user currently logged into the user system 130 or instrument 140 that performs the reading in step 320 (e.g., according to the user account or profile). Similarly, the location can be automatically determined based on the location of the user system 130 or instrument 140 that performs the reading in step 320 (e.g., the location set in the memory of the user system 130 or instrument 140, the location obtained from the global positioning system (GPS) within the user system 130 or instrument 140, etc.), and a timestamp can be automatically generated by the user system 130 or instrument 140 that performs the reading in step 320 (e.g., as the current time). The event type can be automatically determined based on the following information: the user currently logged into the user system 130 or instrument 140 that performs the reading in step 320 (e.g., based on the role in the user account or profile), the type of the instrument 140 used to perform the reading, the location of the user system 130 or instrument 140 that performs the reading in step 320, the manual input or selection input of the user, the user or system settings, and so on.

[0059] In one embodiment, to ensure that only real transactions are added to the immutable ledger, only authenticated users or devices can generate transactions. Specifically, before creating a transaction, it may be necessary for the user or device (e.g., the user system 130 or instrument 140) to authenticate to the distributed network 100 using any well-known authentication mechanism (e.g., digital keys, usernames and passwords, etc.). The distributed network 100 can ignore or discard any messages from unauthenticated users or devices.

[0060] In one embodiment, before a transaction involving a sample identifier is added to the immutable ledger, the distributed network 100 may first confirm that the sample identifier and / or the transaction is valid. For example, an invalid sample identifier may be one for which there is no published transaction representing the sample identifier in the immutable ledger. An invalid transaction may include any inappropriate or unanticipated transaction. As an example, a transaction with a non-collection event type that occurs when there is no previous collection transaction in the immutable ledger may be considered invalid (e.g., because it is assumed that a sample cannot be processed or archived until it is collected). When performing the verification, nodes in the distributed network 100 (i.e., the system 110) may refer to a copy of the immutable ledger (e.g., a copy of its blockchain 120) to ensure that the sample identifier has been published and that the transaction to be recorded is appropriate given any previous transactions in the immutable ledger involving the same sample identifier.

[0061] Generally speaking, patient information should not be included in any machine-readable markings described herein. More generally, patient information should never be sent to the distributed network 100 or recorded in the immutable ledger. This maintains patient privacy and ensures that the disclosed embodiments do not pose a threat to the security of patient information.

[0062] It should be understood that process 300 may be applied to multiple different samples in parallel and / or serially. For example, steps 320 and 330 may be performed in parallel and in real time for multiple reads of different sample identifiers. Additionally, the read in step 320 may include a batch read of multiple sample identifiers at once (e.g., a storage or transport device holding multiple samples). Thus, multiple samples (e.g., hundreds, thousands, millions, billions of samples) may be tracked through many iterations of process 300 to produce a ledger in the distributed network 100 that includes multiple transactions for each of the multiple samples. The ledger provides an immutable record of every touchpoint on each tracked sample.

[0063] 2.2. Access Restriction

[0064] In one embodiment, access to the immutable ledger may be restricted based on user role and / or permissions. Specifically, a regular user may only have access to a subset of the transactions in the immutable ledger (e.g., transactions only for a particular sample(s), user(s), device(s), and / or location(s)). For example, a surgeon may only be able to access the transactions created by that surgeon and / or the surgeon's department (e.g., collection transactions). As another example, a user who needs to verify a particular sample may have the right to access all transactions involving that particular sample (e.g., to verify that all appropriate tests were performed), but not to access transactions for other samples. However, it should be understood that there may be users (e.g., administrative users) who have access to the entire ledger (i.e., every transaction). Advantageously, each user can access the information relevant to them while fully ensuring data integrity.

[0065] 2.3. Encryption of Identifiers

[0066] In one embodiment, to increase security and privacy, one or more identifiers included in a transaction in the immutable ledger may be encrypted (e.g., using a hash function) before being added to the transaction. This encryption will make it more difficult for external parties to link the identifiers to a specific user (e.g., facility, institution, device, individual, etc.).

[0067] 3. Example Applications and Advantages

[0068] By design, the immutable ledger (e.g., blockchain 120 or DAG) provides a very high level of security, traceability, and anti-fraud protection. For example, since the immutable ledger cannot be changed, there is no database of records that can be compromised, tampered with, or otherwise altered. All transactions will be recorded indelibly in the immutable ledger indefinitely, providing rich data for analysis, data mining, and so on.

[0069] In addition, instead of multiple information technology (IT) standards that healthcare providers must navigate in traditional systems, interacting with the distributed network 100 only requires a single set of IT standards. This overcomes the connectivity complexity and the need for middleware that traditional systems (e.g., CerebroTM and laboratory information systems (LIS)) exhibit, thus simplifying system management. The use of the distributed network 100 allows a common system to be used for the entire workflow.

[0070] 3.4. Financial Payment

[0071] In one embodiment, an immutable ledger can be used to determine, audit, or reconcile financial payments. For example, the ledger provides immutable evidence of interactions that have occurred, such as evidence of an ordered test that has been performed. This can be used as proof of healthcare for reimbursement by an insurance company or a government agency.

[0072] 3.5. Performance Monitoring

[0073] In one embodiment, an immutable ledger can be used to measure the performance of one or more health networks. For example, transactions in the immutable ledger can be analyzed to calculate metrics such as the number of interactions (e.g., collections, tests, etc.) performed per unit time by each user or device (e.g., user system 130 or instrument 140) (e.g., using the user identifier and timestamp of the transaction), the number of interactions per unit time at each location (e.g., using the location and timestamp of the transaction), the average time between interactions for each user, device, or location (e.g., using the sample identifier, user identifier, or location, event type, and timestamp of the transaction), and so on. Such metrics allow an operator to evaluate the performance of their health network, optimize workflows (e.g., increase throughput of sample processing, handling, storage, etc.), troubleshoot (e.g., identify bottlenecks, underutilized resources, overutilized resources, etc.), and so on.

[0074] 3.6. Tracking Healthcare-Related Events

[0075] In one embodiment, an immutable ledger can be used to track healthcare-related events associated with a sample, including adverse events. For example, transactions in the immutable ledger for a specific sample can be analyzed to identify all adverse events associated with that sample or the overall adverse event rate for a particular facility for benchmarking or determining penalties.

[0076] 3.7. Audit

[0077] In one embodiment, an immutable ledger can be used for auditing. For example, a user who needs to verify a specific sample can access the immutable ledger to verify all interactions associated with that specific sample. The user can view the complete history of the sample without having to contact any external parties or access any other systems. Additionally, at least some users may have read-only access to a data repository of digital images of the samples. Such users can be able to view the digital image of a specific sample (e.g., extracted from transactions in the immutable ledger), as well as the entire interaction history for that sample.

[0078] 3.8. Sample-Specific Information

[0079] In one embodiment, additional information can be associated with a sample identifier over time. Naturally, machine-readable markings applied to a sample cannot incorporate new information without being reprinted and reapplied to the sample. However, the additional information can be associated with the sample identifier encoded in the machine-readable marking, such that the additional information can be retrieved based on the machine-readable marking. In this way, the information associated with the machine-readable marking applied to a sample can be extended or otherwise changed over time without having to change the machine-readable marking and reapply it to the sample.

[0080] 3.9. Instrument History

[0081] In one embodiment, since all sample processing performed by a particular tool 140 can be recorded in an immutable ledger, the immutable ledger can also be used to track the tool 140. For example, the usage history of each tool 140 can be inferred from usage transactions associated with that tool 140 (e.g., transactions that include the identifier of the tool 140). This usage history can be used to generate maintenance and / or repair information (e.g., schedule maintenance or repairs). For example, assume that the manufacturer recommends that the instrument 140 be serviced (e.g., routine inspection, replacement of specific parts, etc.) every thousand uses. Software services of the manufacturer and / or the customer can continuously check the immutable ledger and calculate the usage volume for each tool 140 in the transactions recorded in the immutable ledger. When the usage volume for a particular tool 140 reaches one thousand, the software service can notify the customer and / or the user of the manufacturer, automatically schedule the servicing of the instrument 140, prevent the instrument 140 from being used before it is serviced, and so on.

[0082] The foregoing description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles described herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, it should be understood that the description and drawings presented herein represent the current preferred embodiments of the invention and thus represent the broad subject matter contemplated by the invention. It should also be understood that the scope of the invention fully encompasses other embodiments that may become obvious to those skilled in the art, and thus the scope of the invention is not limited.

[0083] Combinations described herein, such as "at least one of A, B, or C", "one or more of A, B, or C", "at least one of A, B, and C", "one or more of A, B, and C", and "A, B, C, or any combination thereof" include any combination of A, B, and / or C and may include multiple A's, multiple B's, or multiple C's. Specifically, combinations such as "at least one of A, B, or C", "one or more of A, B, or C", "at least one of A, B, and C", "one or more of A, B, and C", and "A, B, C, or any combination thereof" can be A only, B only, C only, A and B, A and C, B and C, or A and B and C, and any such combination can include one or more members of its components A, B, and / or C. For example, the combination of A and B can include one A and multiple B's, multiple A's and one B, or multiple A's and multiple B's.

Claims

1. A system, comprising: At least one hardware processor, the at least one hardware processor being configured to: Receive, via at least one network, a request for a unique sample identifier for a first sample from a first device, the first sample being associated with patient information, In response to the request, generate the unique sample identifier and send the generated unique sample identifier to the first device via the at least one network; And For each of a plurality of interactions associated with the first sample, Receive, via the at least one network, interaction information for the interaction from one of a plurality of second devices, wherein one of the plurality of second devices includes an instrument configured to process the first sample, and wherein the interaction information includes the unique sample identifier, a user identifier of the instrument, a location, an event type, and a timestamp, Generate a transaction from the interaction information, and Record the transaction in an immutable ledger, wherein the unique sample identifier and all transactions regarding the immutable ledger do not contain patient information; wherein the at least one hardware processor is further configured to retrieve a history that includes all transactions in the immutable ledger associated with a specific unique sample identifier; wherein the at least one hardware processor is further configured to display, within a graphical user interface, a representation of the history and a digital image of the sample identified by the specific unique sample identifier; and wherein the at least one hardware processor is further configured to infer a usage history of a specific instrument.

2. The system according to claim 1, wherein the immutable ledger is a blockchain.

3. The system according to claim 1, wherein the immutable ledger is a directed acyclic graph.

4. The system according to any one of claims 1-3, wherein the at least one hardware processor is further configured to analyze transactions in the immutable ledger to compute one or more metrics for an interaction represented by the transaction.

5. The system according to claim 4, wherein the one or more metrics include a throughput rate for one or more of a specific user identifier, location, or event type.

6. The system according to any one of claims 1-3, wherein the at least one hardware processor is further configured to: Receive, via the at least one network, a request from a user to access the immutable ledger; and In response to the request, provide the user with read-only access to only a subset of the transactions in the immutable ledger while preventing access by the user to any other transactions in the immutable ledger.

7. A method, comprising using at least one hardware processor of a server system to: Receive, via at least one network, a request for a unique sample identifier for a first sample from a first device, the first sample being associated with patient information, In response to the request, generate the unique sample identifier and send the generated unique sample identifier to the first device via the at least one network, and For each of a plurality of interactions associated with the first sample, Receive interaction information for the interaction from one of the plurality of second devices via the at least one network, wherein one of the plurality of second devices includes an instrument configured to process the first sample, and wherein the interaction information includes the unique sample identifier, the user identifier of the instrument, location, event type, and timestamp. Generate a transaction from the interaction information and record the transaction in an immutable ledger. Use the at least one hardware processor to retrieve a history that includes all transactions in the immutable ledger associated with a particular unique sample identifier. Use the at least one hardware processor to display a representation of the history and a digital image of the sample identified by the particular unique sample identifier within a graphical user interface. Use the at least one hardware processor to infer the usage history of a particular instrument. Wherein the unique sample identifier and all transactions regarding the immutable ledger do not contain patient information.

8. The method according to claim 7, wherein the immutable ledger is a blockchain.

9. The method according to claim 7, wherein the immutable ledger is a directed acyclic graph.

10. The method according to any one of claims 7-9 further comprises: Use the at least one hardware processor to analyze the transactions in the immutable ledger to calculate one or more metrics for the interactions represented by the transactions.

11. The method according to claim 10, wherein the one or more metrics include throughput rates for one or more of a particular user identifier, location, or event type.

12. The method according to any one of claims 7-9 further comprises: Use the at least one hardware processor of the server system to: Receive a request from a user to access the immutable ledger via the at least one network. And In response to the request, provide the user with read-only access to only a subset of the transactions in the immutable ledger while preventing the user from accessing any other transactions in the immutable ledger.

13. A non-transitory computer-readable medium having instructions stored therein, wherein when the instructions are executed by a processor, cause the processor to perform the method according to any one of claims 7 to 12.

Images