William Chien,1 Josenor de Jesus,1 Ben Taylor2; Victor Dods,2 Leo Alekseyev,2 Diane Shoda,2 Perry B. Shieh1
Affiliations: 1UCLA Health, Los Angeles, California, USA; 2LedgerDomain, Las Vegas, Nevada, USA
Corresponding Author: Ben Taylor, CEO of LedgerDomain, 3722 Las Vegas Blvd., South Unit 2111E, Las Vegas, NV 89158-4323, USA. Email: ben.taylor@ledgerdomain.com
Section: Research Article: Use Cases/Pilots/Methodologies
Purpose: As part of the FDA’s DSCSA Pilot Project Program, UCLA and its solution partner, LedgerDomain (collectively referred to as the team hereafter), focused on building a complete, working blockchain-based system, BRUINchain, which would meet all the key objectives of the Drug Supply Chain Security Act (DSCSA) for a dispenser operating solely on commercial off-the-shelf (COTS) technology.
Methods: The BRUINchain system requirements include scanning the drug package for a correctly formatted 2D barcode, flagging expired products, verifying the product with the manufacturer, and quarantining suspect and illegitimate products at the last mile: pharmacist to patient, the most complex area of the drug supply chain.
The authors demonstrate a successful implementation where product-tracing notifications are sent automatically to key stakeholders, resulting in enhanced timeliness and reduction in paperwork burden. At the core of this effort was a blockchain-based solution to track and trace changes in custody of drug. As an immutable, time-stamped, near-real-time (50-millisecond latency), auditable record of transactions, BRUINchain makes it possible for supply chain communities to arrive at a single version of the truth. BRUINchain was tested using real data on real caregivers administering life-saving medications to real patients at one of the busiest pharmacies in the United States.
Results: In addition to communicating with the manufacturer directly for verification, BRUINchain also initiated suspect product notifications. During the study, a 100% success rate was observed for scanning, expiration detection, and counterfeit detection; and paperwork reduction from approximately 1 hour to less than a minute.
Conclusions: By automatically interrogating the manufacturer’s relational database with our blockchain-based system, our results indicate a projected DSCSA compliance cost of 17 cents per unit, and potentially much more depending on regulatory interpretation and speed of verification. We project that this cost could be reduced with manufacturers’ adoption of a highly performant, fully automated end-to-end system based on digital ledger technology (DLT). During an examination of the interoperability of such a system, we elaborate on its capacity to enable verification in real time without keeping humans in the loop, the key feature driving lower compliance cost. With 4.2 billion prescriptions being dispensed each year in the United States, DLT would not only reduce the projected per-unit cost to 13 cents per unit (saving $183 million in annual labor costs), but also serve as a major bulwark against bad or fraudulent transactions, reduce the need for safety stock, and enhance the detection and removal of potentially dangerous drugs from the drug supply chain to protect US consumers.
Keywords: Blockchain, DSCSA, FDA, Healthcare Information Technology, Hyperledger Fabric, Patient Care, Pharmaceutical Supply Chain
Enacted in 2013, the Drug Supply Chain Security Act (DSCSA) outlines steps to build an electronic, interoperable system to help identify and trace certain prescription drugs as they are distributed in the United States by 2023.1 The DSCSA intends to enhance the U.S Food & Drug Administration (FDA)’s ability to help protect consumers from exposure to drugs that may be counterfeit, stolen, contaminated, or otherwise harmful. This law sets forth requirements for multiple stakeholders along the pharmaceutical supply chain, from manufacturers, repackagers, and wholesale distributors to dispensers.i
By allowing for more rapid tracing and potentially even allowing for real-time tracking, the system will also improve detection and removal measures: “The ability to track and trace finished prescription drugs plays a significant role in providing transparency and accountability in the drug supply chain.”2 To facilitate the development of the system by 2023, the FDA established the DSCSA Pilot Project Program, which prompted the study outlined in this paper.3 (It must be noted that selection into this program should not be interpreted as FDA’s position on an entity’s compliance with regulatory requirements or an endorsement of a particular technology, system, or other approach.)
UCLA Health consists of five distinct facilities and over 200 clinics, with roughly 20,000 employees serving nearly 600,000 unique patients per year comprising over 2.5 million patient visits. The UCLA Health Pharmacy supports all these facilities with three hospital pharmacies—an infusion pharmacy, two research pharmacies, and five retail/specialty pharmacies staffed by over 300 employees.4 As one of the nation’s leading dispensers and a blockchain solutions provider with extensive healthcare experience, the team decided to take on the challenge of applying DSCSA requirements to the last mile—a pharmacy in a large hospital setting—a highly complex area of the drug supply chain.
Both UCLA and LedgerDomain are members of the Linux Foundation and the Hyperledger Project, and are active in advancing the use of blockchain to drive pharmaceutical supply assurance directly to patients. UCLA and LedgerDomain are also both charter members of the Clinical Supply Blockchain Working Group, an initiative formed along with Pfizer, Biogen, GSK, Merck, UPS, IQVIA, and other healthcare leaders. In 2019, the group published results from Project KitChain, a collaborative model for immutable digital recordation and inventory and event tracking in the pharmaceutical clinical supply chain.5
The objective of the study was to focus on the enhanced requirements for package-level tracing and notification that would go into effect in 2023 to comply with the DSCSA. In particular, the team focused on the verification system requirements under section 582 of the FD&C Act6 and the existing protocols around Form FDA 3911, which is used by manufacturers, repackagers, wholesale distributors, and dispensers to notify FDA and all appropriate immediate trading partners within 24 hours after determining that a product is illegitimate or has a high risk of illegitimacy.7
As part of this endeavor, the team also aimed to learn about the challenges of implementing an interoperable system on a larger scale, identify projected costs, and articulate potential soft costs and benefits encountered that might be worthy of further study. The logical components of such a system are depicted in Figure 1.
Figure 1—The logical components of an interoperable supply chain system.
In supply chain systems, transactions are captured as events in the “transaction plane.” These events are aggregated into trends in the “control plane.” Exceptions and problems are then surfaced to the “risk management plane.” In the legacy relational database world, the transaction plane was often termed the online transaction processing (OLTP) database,8 while the control plane was termed the online analytical processing (OLAP) database, or data warehouse.9 With an integrated system, not only can a single expired unit simply be blocked at the transaction plane level, but multiple blocked transactions of this expired drug can rise to the level of a risk-management issue.
There are security tradeoffs made with relational database implementations of such multiplanar supply chain systems. In these implementations, it is typical for each transacting party to manage its own database systems: there is no shared global system of record representing the single source of truth describing the flow of items through the supply chain. Maintaining a private database allows each party to minimize the security threat to which they are exposed while maximizing internal data consistency, as a global relational database would require each party to trust all other parties in the supply chain with the integrity and security of their data.
However, a system in which each supply chain participant maintains its own system of record comes at the expense of the supply chain’s resilience to common attack vectors such as man-in-the-middle or spoofing,10 as each participant must be trusted to securely manage user privileges, authentication, and auditing. Perhaps more importantly, each participant must be trusted to not carry out malicious edits of data in their system of record to their own benefit. This makes it difficult for any single source of truth to be synthesized.
Without global and persistent visibility regarding the true state of the supply chain, duplicate “spoofed” counterfeit drugs cannot be identified; counterfeit or defective lots cannot be tracked, traced, and recovered; and malicious “men in the middle” cannot be identified by the signature transaction patterns they leave across multiple points in the supply chain. Distributed ledger technologies such as blockchain represent a potential system of record that would lessen the need to trade data integrity and privacy for global visibility and interpretability,11 contributing to the inspiration for the BRUINchain study.
In a highly regulated community, regulations need to drive the data standards, which drive the implementation. With that in mind, much of this study also focuses on establishing the “ground truths” of regulatory requirements and data standards, as they are ultimately critical to the implementation as well as the financial analysis.
The questions this pilot aims to answer are:
The last mile in the pharmaceutical supply chain is a complex environment, as drugs are moved from shipping containers and pallets to individual packages and amber bottles with several degrees of separation from their point of origin (see Figure 2). The first mile might be compared to counting Humpty Dumpty; the last mile is where we track and trace the pieces.
Figure 2—A simplified model of the pharmaceutical supply chain, with the last mile at UCLA outlined. Note that this study encompasses the administration of drugs to patients.
The keystone of this project is BRUINchain, a blockchain-based mobile solution and notification system designed to track and trace changes in custody of drug within a “dispenser” organization using FDA-stipulated barcodes.12 Changes in custody were translated into the application with real-time reporting of inventory counts and locations within the UCLA Pharmacy system. The following checkpoints were built into this system to prevent distribution of suspect product to patients: (1) verify that the information on the scanned barcode matches the human readable label; (2) verify that the product is fit for distribution, that is, not past its expiration date; (3) obtain verification from the manufacturer; and (4) visual inspection of the product. This flow is outlined in more detail in the “Process flow” section.
Based on earlier learnings from a pilot application designed for the clinical supply chain,5 system requirements included notifications; that is, (1) automated product tracing notifications to key stakeholders and (2) notifications for suspect product with key information that mapped to the existing Form FDA 3911. For this pilot project, the team assessed BRUINchain system requirements for a successful implementation on a larger scale, including identifying, flagging, and preventing the distribution of suspect and illegitimate products, and evaluating the enhanced timeliness and reduction in paperwork that might be achieved.
To fully test the system’s track-and-trace capability, the team decided to select one study drug and have BRUINchain track its journey from the point UCLA received the drug in its receiving dock to being dispensed to the clinic/patient. While to some observers this may encompass greater scope than that warranted by the DSCSA, a closer examination of UCLA’s workflow revealed that different UCLA colleagues were performing different DSCSA-mandated checks.
SPINRAZA®ii (referred to as study drug hereafter), a Biogen product, is used for treatment of children and adults with spinal muscular atrophy (SMA). Infantile-onset SMA (Type 1) results in early mortality.13 This was chosen as the study drug for its ideal tracking characteristics. It is packaged as single-dose medicine with a GS1 DataMatrix barcode on the outer packaging (see image).14 In this particular situation, a single MD administers all of the study drug in the UCLA system. Because the MD, not the pharmacy, opens the carton, the team decided to track the drug all the way to the prescriber/clinic in order to incorporate visual inspection of the vial as part of the BRUINchain process.
Most importantly, however, the study drug has a complex workflow at UCLA Health. After UCLA Receiving takes custody of the drug, the study drug may be forwarded to a variety of pharmacy locations, including the Intravenous Additive Service Pharmacy (IVAS), the Operating Room Pharmacy (OR), the Bowyer Infusion Pharmacy (Bowyer), and outside the pharmacy, the MD’s clinic; all depending upon a variety of important variables. This complex real-world setting, depicted in Figure 3, was an ideal use case for the BRUINchain application.
Figure 3—The typical “happy path” (blue arrows) of the study drug as it is distributed through the UCLA Health pharmacy, from Receiving to the Clinic. At any point the drug may be quarantined (yellow zones) if it is suspected of being illegitimate. If found to be illegitimate, it is removed from distribution (red zone). Once a drug is administered in the clinic, it has fulfilled its journey in the supply chain (green zone).
As part of exploring DSCSA requirements for verification of the drug as a legitimate product, the team coordinated with the study drug’s manufacturer on a potential solution. This culminated in the development of an automated verification system (supported by the Oraculous notification service, detailed in the “BRUINchain implementation, soft start” section), involving queries of serial and lot numbers between the UCLA Pharmacy and the manufacturer’s serialization team.
It is important to note that the implementation of the BRUINchain pilot study (see the “BRUINchain pilot study” section) was conducted as a system parallel to existing systems of record in an active pharmacy at UCLA Health. In this way, the team met its goal of getting real data in a real-world setting.
A pharmacy purchasing manager at UCLA Health Pharmacy (hereafter the Manager) was the system owner and manager, providing LedgerDomain with workflow requirements to design the system. The manager also recruited and managed technicians and pharmacists to test the solution and provide feedback.
UCLA Health also acted as the prescriber. The MD personally retrieved the medicine at the relevant UCLA pharmacy or received into his clinic directly from a specialty distributor via pre-dispensed distribution (also known as “white bagging”) and administered to the patient. The manager, prescriber, and other roles are outlined in the “Technology” section.
LedgerDomain designed, coded, and tested the BRUINchain iPhone application, and supplied the DocuSeal framework, the Oraculous notification service, and Selvedge blockchain application server, as well as hosted the Hyperledger Fabric backend.
Blockchain enables a tamper-proof, time-stamped, near-real-time, auditable record of transactions, thereby making it possible to enhance privacy and security across a range of collaborative applications.15 Unlike a centralized relational database, no single user or organization can access the full record of transactions within a blockchain (provided a sufficient number of nodes within a diversified trading community). Unlike in a relational data model, blockchain communities converge on a single version of the truth through the application of validated transactions. Once transaction finality is achieved, that single best version is committed to the blockchain.
This consensus is particularly important in the drug supply chain, as this single version of the truth cancels out double counting and reveals possible instances of counterfeiting, diversion, spoofing, or man-in-the-middle attacks. In implementations such as BRUINchain, each event within the blockchain occurs when relevant parties agree to cryptographically sign a transaction. This agreement, in turn, adheres to an associated “smart contract.” Once this transaction has met those conditions and is committed to the blockchain, it is both binding and irrevocable.
After a transaction is struck between two parties, each will have keyed access for later decryption and analysis, as might a regulator or auditor. Thus, the team saw blockchain as a potential “honest broker” that would allow hundreds of competing pharmaceutical and biotech enterprises and their vendors to work collaboratively and communicate with hundreds of wholesalers and tens of thousands of dispensers.
BRUINchain was designed and scoped to be a shared-permission blockchain-based system; that is, a system where membership and participation in the network is controlled rather than open to the public.iii Linux Foundation Hyperledger Fabric components were chosen as a scaffolding for the pilot, as well as a Fabric-based framework that allowed for off-chain private storage combined with blockchain-based authentication.16
The goal of the DSCSA is interoperability among thousands of companies that make up the pharmaceutical supply chain shown in Figure 2, including manufacturers, repackagers, wholesale distributors, and dispensers. Even within these four categories, one can identify numerous organizational and individual roles; between the distributor and the practitioner at UCLA there are shippers, technicians in the pharmacy receiving department, and stations/carts within the pharmacy itself. A key goal of BRUINchain was to provide a real-time system that allows all its internal stakeholders to interact in a manner appropriate to their privileges.
Under DSCSA, dispensers are required to be able to trace and verify drugs. The drug barcode may be used to pull the relevant data fields, but the question in the pre-2023 environment is from which external party might BRUINchain electronically poll to trace. This presented an additional challenge: how BRUINchain might communicate without compromising its security envelope. To address this challenge, LedgerDomain designed a novel approach that leverages the blockchain concept of an oracle,iv detailed in the “BRUINchain implementation, soft start” section.
A key goal of the BRUINchain application and process is to detect and report problems. In the pilot, the team defined the ideal supply chain workflow as the “happy path,” and possible failure states as “sad paths.” A package that (1) has a valid barcode with a GS1 Global Trade Item Number (GTIN) that matches the expected value, (2) is unexpired, (3) is verified by the manufacturer, and (4) passes visual inspection has fulfilled the happy path (shown in Figure 4).
Figure 4—An overview of the happy and sad paths.
At the last stage of the drug’s route through the pharmacy, the MD scanned the package using his iPhone (see Figure 8) to take custody on behalf of the clinic prior to administration (of the drug) and retirement (of the unique Asset ID within the blockchain system). However, if it fails any of these tests at any of the pharmacy locations (detailed in the “Pilot scope” section), the package has taken one of the sad paths. Again, in UCLA’s current workflow, the study drug is delivered to the prescriber as a sealed package, and the prescriber performs the unsealing and inspection, thereby fulfilling the final requirement.
Of the four types of problems that are identified by a dispenser locally, each requires a slightly different approach. If a medicine is expired, the transaction is flagged: there may be no external reporting necessary.
In the case of the barcode failing to match the medication, or a visual inspection failure, the dispenser is required to escalate the situation and stand ready to file Form FDA 3911. The BRUINchain application automatically generates the XML-formatted dataset for the filing of a 3911 and asks users to take a photo supporting their issue (see Figure 5). Both documents are encrypted, timestamped, and stored in a secure archive, mediated by DocuSeal. At UCLA, the policy is for the user to report these issues to the manager. The manager then confirms the issue and submits the email if necessary, in addition to any steps stipulated by UCLA Health.
Figure 5—An XML message (left) generated by a simulated issue report, in this case an empty box (right).
Finally, if there is a problem in verification, the BRUINchain system will have already provided the manufacturer with all of the fields necessary for the manufacturer to file a Form FDA 3911. Figure 5 shows a sealed document from the blockchain of a simulated issue, including a photograph that supports the issue and is sealed to the blockchain as well. (Note that for security purposes, all study drug serial numbers have been obfuscated except for the last four digits; barcodes and contact information have also been obfuscated.)
It should be noted that quarantine is an intermediate step within the BRUINchain system; human review is required to determine whether the drug is illegitimate, or whether it has been quarantined due to user error or other factors. In the event of a quarantined drug, a sticker or tape (as shown in Figure 6, alongside the quarantine bin) is to be affixed to the package until resolution of its status. If a quarantined medication is deemed illegitimate, it is flagged as “bad” within the BRUINchain workflow, potentially resulting in a report to FDA via Form FDA 3911.
Figure 6—A quarantine bin (left) and quarantine sticker (right).
Under the FD&C Act, manufacturers are required to “affix or imprint a product identifier to each package and homogenous case of a product intended to be introduced in a transaction into commerce.”18 This must take the form of a two-dimensional data matrix barcode for packages,19 with data containing the product’s National Drug Code (NDC), unique alphanumeric serial number, lot number, and expiration date. The barcode must be “on a data carrier that conforms to the standards developed by a widely recognized international standards development organization.”20
For the BRUINchain pilot, it was determined that this barcode would set the stage for intake into Receiving for further evaluation as to expiry, storage condition, tampering, and barcode verification. The barcode on the study drug is based on the GS1 standard. GS1, which develops and maintains global standards for efficient business communication, has published a material identification standard for both commercial and clinical pharmaceutical supplies.21 (In GS1-compliant barcodes, the NDC is concatenated within the GTIN.)
The data standards used in the BRUINchain pilot further include: a concept of network time and time-stamping; FDA Form 3911 specified problem-handling fields; user ID, email, and location; quarantine and retired statuses; and verification statuses.
The BRUINchain system has five major components:
These components are shown in Figures 9 and 10. The first thing presented to the member is a modal login screen (member email and password). Once logged in, the full application user interface (UI) is presented (Figure 7).
Figure 7—The BRUINchain home screen.
Figure 8—Scanning a barcode (left), awaiting verification (middle), and error message on rescan (right).
Figure 9—A general overview of the BRUINchain application infrastructure. Smart contracts are run within a Hyperledger Fabric infrastructure, denoted in orange.
Figure 10—An overview of LedgerDomain’s standard system architecture. This diagram includes multiple organizations and multiple frontend clients; as a single-organization pilot with a mobile application, the BRUINchain implementation test was purposely simplified.
Figure 11—An overview of the blockchain pilot development process.
Account actions. All members can change their first name, last name, and avatar; change location; or logout. Admins additionally have the ability to invite a new member (sending an email that grants the recipient access to the application) and purge the blockchain of data to reset for testing.
Distinct roles. There are four roles:
Scan. The logical custody is keyed off the scan, which is checked for expiration date and validly formatted drug barcode. In addition, the barcode is checked against the register of verified (but not retired) barcodes: if the barcode is not already verified, the verification procedure is automatically initiated by the Oraculous notification service. Once scanned, the application displays the elements of the barcode (GTIN, serial number, expiration date, and lot number) in a human-readable format. Users can then compare the information on the screen against the human-readable information on the package (see Figure 8).
Confirming modals. Users have the ability to flag units that do not pass visual inspection and start an exception report. If the application detects a duplicate scan, the users are asked to confirm whether or not they believe they scanned the same box twice (“rescan”). Any of these routes can turn from the “happy path” to the “sad path,” which eventually leads to quarantine and potentially to “bad status” and Form FDA 3911 for resolution.
While not exhaustive, the following captures the core components of the BRUINchain system on final test:
For this pilot, the BRUINchain application was restrictedly used amongst a few participants at UCLA Health and handled no patient data. It should be noted that no scanned packages had any personally identifiable information or protected health information (PII/PHI), except for the white-bagged units in the “Live parallel user-site testing with UCLA” section, which were handled exclusively by UCLA personnel.
The team performed multiple cycles of by-invitation only testing. At the end of each cycle, personal and personally identifiable information such as names, email addresses, and IP addresses were discarded.22 In addition, the application was distributed via the Apple TestFlight sandbox and was thus not exposed to the general public in the App Store.
This phase of the pilot project comprised (1) gathering of requirements and confirming target drugs and partners; (2) specifying and building the blockchain application; and (3) testing in controlled environments, referred to as User Site and Developer Site.
During this phase, existing workflows were mapped, and possible paths to DSCSA compliance were workshopped. These were then built as process flows within the system’s roles, privileges, and smart contracts. This culminated in the happy and sad paths workflow (shown in the “Process flow” section). The team’s methodology in testing the counterfeit sad path was to flag everything that was not the study drug and generate a modal warning.
Training was self-guided with LedgerDomain personnel as coach. Trainees from the UCLA pharmacy staff typically spent 15–20 minutes getting familiar with the BRUINchain application, roles, and locations. Eighteen minutes was the training time mean.
For this phase, a “board game” simulation mat of the UCLA pharmacy workflows was used. Training and testing were conducted with naive LedgerDomain colleagues playing different roles (receiving tech, pharmacist, and prescriber).
| Test Round | Objective | Units Scanned | Outcomes |
|---|---|---|---|
| Round 1, User 1 | Gain insight into barcode reading error rates | Two (2) non-study drug packages and two (2) study drug packages | All barcodes were successfully read and packages were correctly identified as non-study drug vs. study drug |
| Round 1, User 2 | Ten (10) study drug packages and randomly selected non-study drugs | ||
| Round 2 | Quantify the amount of time to scan barcodes | Four rolling carts (25–50 scannable units per cart) were randomly selected and their contents were scanned and timed | Four time-measured flights involved 197 units scanned in 27:50 minutes (11.8 seconds per package); zero failures were encountered during scanning |
User site testing and training objectives and results.
| Objective | Units Scanned | Outcomes |
|---|---|---|
| Test inventory counts and location of drug | Seven (7) discarded study drug packages traveling from Receiving to Clinic | Scanning was 100% successful, and inventory tracking was 100% accurate |
Developer site board game testing objective and results.
Training and testing were conducted with a group of UCLA pharmacy staff, first in a conference room setting, and later onsite at the pharmacy (see Figure 12). This session was used to test inventory count, location of drug, and “sad path” of expired drug.
Figure 12—Round 1 user-site test with the simulation mat.
Training was self-guided with LedgerDomain personnel as coach. Trainees typically spent 20 minutes getting up to speed. Once trainees pronounced themselves comfortable, the trainees worked together to push the packages through the board game supply chain (see Figure 13).
Figure 13—Scanning packages of study drug.
Training took 18 minutes in total, while provisioning the application on the iPhone took an additional 10 minutes and scanning 33 packages across a variety of bins took 4:58 minutes or 9.0 seconds/package.
As an initial test, the team successfully verified 11 out of 11 study drug barcodes with the manufacturer’s serialization team through a manual process (i.e. emailing parsed barcodes for review).
The goal of the soft start was to confirm UCLA’s forecasted activity for the week of December 16–20 (“Live Test”) and to verify all on-hand study drugs 3 days prior through the BRUINchain system. This enabled the team to pre-verify the study drug and avoid quarantine scenarios, while also gathering further feedback from the manufacturer. The manager scanned all five units on hand.
The BRUINchain system automatically generated a notification to the manufacturer’s serialization team through the LedgerDomain Oraculous Notification Service. The process was fully automated in-bound and out-bound for UCLA users on BRUINchain. The Oraculous service allowed for manual verification on the manufacturer side, as shown in Figure 14.
Figure 14—The notification and associated verification flow.
The first five notifications were successfully verified by the manufacturer. The “not verified” functionality was also tested, although it should be clear that this was strictly a test of the software, not a real event.
| Test Round | Objective | Units Scanned | Outcomes |
|---|---|---|---|
| Round 1: UCLA pharmacy staff | Test inventory count, location of drug, and “sad path” of expired drug | Seven (7) discarded study drug packages | The total time was 45 minutes to individually train and to work together as a team. BRUINchain successfully flagged expired drug barcodes and generated modal warning screens to indicate expiry |
| Round 2: Prescriber | Receive, transfer, and simulate administration | Seven (7) discarded study drug packages | Ambient lighting was poor and scanning was slow, but accurate |
| Round 3: UCLA pharmacy staff | Training and testing in the infusion pharmacyv | Ten (10) discarded study drug packages (two expired) | User was readily able to receive and transfer the drug on the BRUINchain application |
User-site board game testing objectives and results.
The following day, UCLA scanned a second batch of three additional incoming study drug units; again, all three generated automatic notifications and were subsequently verified as good serial numbers. As such, the live test began with six uncommitted study drug units in aggregate across the pharmacies and two study drug units committed with PHI in the clinic. These two had come in directly from a specialty distributor, pre-dispensed (“white bagged”). All units were scanned for expiration date as well as verified by the manufacturer.
With only eight units, it is unsurprising that no duplicates were found; nonetheless, the BRUINchain system does check for this, blocking retired units and requesting user feedback for units that are duplicates within the system. Duplicate scans are normative, as units are tracked with BRUINchain through their retirement or quarantine, but users are always asked to confirm the unit is indeed an existing unit, as shown in the “Technology” section.
During this phase, the Oraculous service was updated to provide the manufacturer with more information to aid in verification and improve record auditability. UCLA colleagues commenced the live parallel user-site testing by updating the locations of each of the drug doses. UCLA typically uses a weekly paper forecast of study drug doses as a fail-safe to ensure an adequate supply: eight doses were confirmed as being on hand and seven patients were scheduled.
Following a day of testing, the Oraculous service was further updated to tune the notifications to the manufacturer. The manufacturer now received a follow-on email confirming “Verified” in addition to those confirming “Not Verified” (shown in Figure 15). As such, the manufacturer would receive a record of data sufficient to initiate a Form FDA 3911 on both suspect and non-suspect units.
Figure 15—Verification email sent by the Oraculous service (left) and notification of verification within the BRUINchain app (right).
The client application continued to perform as expected, as all inventories continued to match up with user commands (see Figure 16). Following the live test with the manufacturer verifying inventories (see “BRUINchain implementation, soft start” section) and through the live parallel user-site testing, the team gathered the metrics outlined below. It is important to note that no suspect or illegitimate drug was identified during the pilot, and any error reports or exclusions were performed as part of testing.
Figure 16—The final scan of the BRUINchain pilot.
In summary, during the busy pre-holiday week, UCLA started with six doses of the study drug in the pharmacy and two additional white-bagged doses in the clinic; by the week’s end, UCLA had three in pharmacy. The system tracked pharmacy doses to user input accurately throughout the week, checking each package for expiry and soliciting verification from the manufacturer.
User feedback suggested that some barcodes are faster to scan than others, with the testers favoring larger barcodes with simpler (black ink on white card stock) color contrast. With practice, 3.16–3.59 seconds were seen per scan for the larger barcodes, which includes: (1) pushing the scanning button, (2) aligning the package in the application reticle, (3) scanning, and (4) accepting by pushing the modal screen. Time trials of bigger versus smaller barcodes were performed to determine the importance of this factor.vi
| Asset Serial Number | First Event | Last Event | Touches |
|---|---|---|---|
| XXXXXXXX9621 | Fri Dec 13 16:14:16 2019 | Mon Dec 16 18:21:35 2019 | 57 |
| XXXXXXXX7449 | Wed Dec 11 18:30:38 2019 | Fri Dec 20 19:58:16 2019 | 143 |
| XXXXXXXX9154 | Wed Dec 18 21:46:48 2019 | Thu Dec 19 17:15:13 2019 | 64 |
| XXXXXXXX4202 | Wed Dec 11 18:30:19 2019 | Mon Dec 16 18:36:27 2019 | 57 |
| XXXXXXXX2024 | Fri Dec 13 16:14:00 2019 | Sat Dec 21 00:00:32 2019 | 99 |
| XXXXXXXX6442 | Wed Dec 11 18:41:20 2019 | Thu Dec 12 10:21:32 2019 | 46 |
| XXXXXXXX6075 | Thu Dec 19 23:07:35 2019 | Sat Dec 21 01:28:17 2019 | 65 |
| XXXXXXXX5195 | Fri Dec 13 16:13:46 2019 | Sat Dec 21 00:01:49 2019 | 99 |
| XXXXXXXX2141 | Wed Dec 11 18:41:08 2019 | Tue Dec 17 23:20:37 2019 | 59 |
| XXXXXXXX0150 | Wed Dec 11 18:30:03 2019 | Mon Dec 16 18:36:10 2019 | 59 |
A breakdown of API touches by asset. (Note that all times are in UTC. Touches refers to API calls related to the specific asset. For logging and analysis we used Splunk, software designed to search, monitor, and analyze machine-generated big data.)
By running a live study at one of the nation’s busiest pharmacies with real medications being delivered to real patients, the team gained important insights into what a larger implementation of a DSCSA verification system would look like. While not every dispenser will share that exact experience, extrapolating this performance and cost of the electronic, interoperable system mandated by the DSCSA to the dispenser community may provide some insights for stakeholders.
A scanning success rate of 100% was observed, but initially scanning was difficult and slow. Reprogramming the cameras and re-framing the reticle improved performance. Subsequent developer-site practice dropped scanning to as fast as 3.16 seconds per scan. This further validates the use of COTS phones as scanning and application endpoints.23,24 It should be noted that one of the motivating factors in selecting COTS technology was the need to manage equipment costs at an industry-wide level.
Moreover, the study supports recent findings by AmerisourceBergen, McKesson, and GS1 that there has been significant and growing adoption of the GS1 DSCSA-compliant standard. For instance, at AmerisourceBergen, 71.9% of all packages in 2019 had a readable 2D GS1 DataMatrix barcode with all four DSCSA-required data elements, compared to 20.4% in 2018 and 7.2% in 2017. In 2019, they reported improved legibility of barcodes as well, as previously they often “could not scan certain barcodes since they were applied on shiny surfaces or were printed in inappropriate colors.”23,24
Throughout the course of the study, the BRUINchain application was capable of identifying expired and duplicate products. Expired products, duplicates, and failed verifications all resulted in the relevant stakeholders being alerted in real time with modal screens, mobile push notifications, and/or emails. An automated verification system was developed (the Oraculous Notification Service) to serve the role of “blockchain oracle,” allowing manufacturer study participants to verify products without requiring provisioning their membership on the BRUINchain blockchain.
Study participants were surveyed following test rounds, with six responses.
| Metric | Rating (%) |
|---|---|
| Login success | 100 |
| Application look and feel | 93 |
| Notification success | 100 |
| Barcode scanning reliability | 97 |
| Notification format and appearance | 97 |
| Ease of location change | 92 |
| Overall impression | 90 |
Respondents reported two usability issues: slow scanning times and occasional modal screen freezes after sending notifications.
The team experienced a 100% success rate across scanning, expiration detection, and counterfeit detection. (As mentioned in the “Development and testing” section, the study methodology for counterfeits was to flag everything that was not the study drug and generate a modal warning.) Further on-site study with a significantly higher number of users and drugs is recommended to explore potential new edge cases.
According to FDA, “the burden time for [Form FDA 3911] is estimated to average 1 hour per response, including the time to review instructions, search existing data sources, gather and maintain the data needed and complete and review the collection of information.”25 By automatically sourcing all of the fields required for a Form FDA 3911, the solution explored in this study reduces reporting times to the push of a button.
For the current study drug workflow at UCLA, a minimum of three scans were found to be required: (1) the first scan in Receiving checks that the barcode is indeed a valid barcode, that the unit is not yet expired, and initiates the barcode verification process with the manufacturer; (2) after the notification is received from the manufacturer, a second scan is required to pull that unit out of quarantine, placing it into inventory and if desired, to notify the clinic; and (3) the prescriber, who is delivered a sealed box of the drug, re-scans it and after inspecting the vial for visual issues (such as cracks or discoloration) accepts the unit.
One could postulate over time that the number of scans required under an industry-standard interpretation of DSCSA might be lowered. For typical products that are visually inspected by the dispenser, only two scans are required, assuming the manufacturer verification is delayed more than a few seconds (i.e. not in real time).
According to Statista, there are 4.2 billion prescriptions dispensed each year in the United States.26 With a barcode scan time of 3.16 seconds, this implies 1,139 scans per hour. Based on two scans per package—one to send the barcode to the manufacturer or repackager in order to trigger the verification request, and one to check the package again after verification has been received—one might anticipate 7.4 million hours of scanning nationwide each year.
According to the US Bureau of Labor Statistics, the mean average salary for the 309,550 pharmacists in the United States is $123,670 per year, or $59.45 per hour,27 while the mean average salary for the 417,860 pharmacy technicians in the United States is $34,020 per year, or $16.35 per hour.28 At UCLA, the first scan was performed by a pharmacy technician and the second scan was performed by a pharmacist. Thus, assuming a roughly equal distribution of engagement with the scanning system, one can assume the value of pharmacy time as $37.90 per hour.
This drives a best single-point estimate of the cost for barcode scanning at the dispenser level of $280 million in labor costs. With a 30% benefit component added,29 the fully loaded labor-related cost would be approximately $365 million. On top of this, one can also project additional requirements at the individual employee. Based on these figures, a full breakdown is shown below:
| Expenditure | Unit Cost | Per | Annual Cost |
|---|---|---|---|
| Scan labor (two scans per barcode) | $0.087 | Two scans | $365MM |
| Client hardware and training (biennial) | $1,000 | Employee | $364MM |
Thus one may project that the cost of scanning, hardware, and training will amount to $729 million, or approximately 17 cents per prescription.
Critically, the above analysis presumes that two scans would be required. In a future state with a real-time blockchain-based connection, a workflow involving a single scan for the happy path would potentially be achievable. The dispenser would need to have a fast internet connection and the persistent digital ledger technology (DLT) would need to reply within “internet time” (~120 milliseconds) for the entire process to be completed in a single scan. If the system performance were seconds or minutes, the receivers would have to momentarily set the box aside, and then rescan later to match the unit to its “verified” notification and move it from the quarantine bin into the regular inventory.
This represents a “two-tier warehouse” model at the receiving site, consisting of a “quarantine” tier into which drugs are scanned, and a “verified” tier that drugs are moved to upon receipt of verification. The verification tier can consist of several “sub-warehouses” representing separate stocks for programs such as 340B.vii
Any single-scan solution would clearly demand a highly performant, fully automated end-to-end system involving real-time access to a persistent DLT with up-to-date statuses. (It should be noted that BRUINchain is already driven remotely by hosting it on the cloud and not locally at UCLA Health; the only change would be that the BRUINchain app would interact with a consolidated DLT rather than BRUINchain.) If it could be achieved within the required response time window, it would represent a $183 million annual savings to dispensers in the United States, as well as a major bulwark against bad or fraudulent transactions.
Further benefits are recognized through the minimization of safety stock needed in the case of a potential quarantine event. At any given time, the dispenser’s safety stock must accommodate the overall latency of the system to serve as a buffer. The DSCSA gives each trading partner 24 hours to respond to a verification request, and the dispenser has no way of knowing how many trading partners who handled the drug prior to receipt at the dispenser. Given that tracing is performed by chaining together 24-hour-latency messages, and that the number of trading partners is commonly thought to be up to 10, the dispenser must hold safety stock roughly proportional to the requirements of 10 days.
Even if the message chain can be collapsed to 24 hours, the dispenser must still hold safety stock in case of potential non-verification events. However, if the verification is performed on real-time DLT, no additional safety stock is required. With the top three wholesalers approaching $500 billion in annual sales within the United States,30 one may estimate based on a 5-day week that an extra 10 days of safety stock would equate to $20 billion in inventory. The carrying cost of this safety stock at 7% cost of capital is $1.4 billion.viii
The cost and scale of the projected DSCSA deployment suggests a need to investigate other solutions that reduce total system cost. Stricter guidelines for barcode sizes, color, and placement represent such a potential solution, as even a 5% reduction in average scan time would save U.S. dispensers nearly $20 million annually.23
A “bottle bill” model is worthy of consideration to drive compliance and trading partner equity. Even if a highly performant system were to reduce the cost of compliance to 10 cents per unit, this still indicates 10 cents taken away from patient care. Focus on tracing places the burden squarely on last-mile participants, both in terms of responsibility and cost. A blockchain system could levy 10-cent unit-level charges on those adding assets to the system and remit 10 cents per unit to those retiring barcodes. This cost-shifting31 might be seen as a source not only of trading partner equity and an assignment to the least cost avoider,32 but perhaps more importantly might enhance compliance and notify those adding assets with definitive assurance that their asset had been immutably retired.
Furthermore, the future adoption of radio-frequency identification (RFID) tags and readers (either standalone or in combination33 with DSCSA-mandated DataMatrix barcodes) could allow for more rapid and less expensive scanning, as pharmacists would not need to align the barcode with an optical scanner and could scan an entire “tote” with a wave of their arm.
Other high-level topics worthy of further study include the application of federated models, potential risk mitigation strategies, and governance models.
The deeper question is whether policymakers and stakeholders rally around a DLT solution which includes manufacturers and wholesalers and federates their data into a single actual or virtual persistent data store. A persistent DLT with blockchain security protocols which covers all units traversing the United States could perhaps allow for dispensers to fulfill their obligations under DSCSA with a single scan, without trading off the security or integrity of trading partner data.
This also has major implications for the broader security of the supply chain. In the absence of a single persistent data store, dispensers and other stakeholders are left vulnerable to spoofing or man-in-the-middle attacks. Moreover, the interception of counterfeits becomes an ongoing challenge that must be identified and resolved repeatedly; whereas known counterfeits can be immediately flagged by a persistent blockchain system.
In our implementation, transaction timestamps are centralized, but the supporting documentation is stored in a decentralized private store. Pharmacies under common control, manufacturers, and other trading partners could have their own user access administration and each act as an organization on the persistent DLT to better manage privileges and desired segregation.
In conclusion, this study has introduced BRUINchain, a successful blockchain-based implementation of a system capable of meeting DSCSA standards for a dispenser operating solely on COTS technology. BRUINchain is capable of real-time performance, multiple roles with differing permissions, in-app member provisioning, inventory tracking at the stockroom level, accurate barcode scanning and parsing, and verification from the manufacturer. Through a series of tests performed onsite at the UCLA pharmacy, the study has shown users’ ability to use BRUINchain to efficiently scan, track, and verify drugs with minimal training.
The study has also discussed the nature of BRUINchain’s persistent blockchain database, and contrasted DLTs with comparable relational databases to highlight BRUINchain’s improved security and potential to drive cost savings. Finally, the study discussed the relevant policy considerations that must be weighed to ensure American patients receive the full suite of benefits a globally accessible, DSCSA-compliant supply chain could afford them.
The authors thank UCLA Health under the leadership of CEO Johnese Spisso. No outside money was accepted. The authors also personally thank Marlon Barrios, Veronica Burwick (PharmD), Cheng Cai (PharmD), and Jacquilin Parker, all of UCLA Health; and Ben Nichols of LedgerDomain. They are particularly grateful for the support of Biogen (manufacturer of SPINRAZA®), especially from Imran Shakur, and direct and invaluable assistance from their serialization program with Lead Bjoern Rosner (PhD) and the Operations Team, specifically Steve Van Nuffel, Derry Manley, Lindy Blom, and Donncha Phelan. In addition, thanks to Leigh Verbois (PhD), Connie Jung (PhD) and Daniel Bellingham, all of FDA; Bob Celeste; Jennifer Colon (PharmD); and Desmond Hunt (PhD) each of whom provided valuable insights.
Funding statement: The study was a joint collaboration of LedgerDomain and UCLA Health, and received no external funding.
Conflicts of interest: The authors declare no competing interests exist with respect to research, authorship, and/or publication of this article.
Contributors: William Chien was the principal author and conducted research at UCLA. Perry B. Shieh played an advisory role as a key participant in the BRUINchain workflow. Josenor de Jesus played an advisory role with regard to UCLA workflows and requirements. Ben Taylor conducted research. Victor Dods and Leo Alekseyev conducted research and development on the software framework. Diane Shoda played an advisory role.
| 1. | U.S. Department of Health and Human Services Food and Drug Administration, Drug Supply Chain Security Act (DSCSA). [Internet]. U.S. Department of Health and Human Services Food and Drug Administration [updated 2019 May 22; cited 2020 Jan 13]. Available from: https://www.fda.gov/drugs/drug-supply-chain-integrity/drug-supply-chain-security-act-dscsa |
| 2. | Standards for the Interoperable Exchange of Information for Tracing of Human, Finished, Prescription Drugs, in Paper or Electronic Format; Establishment of a Public Docket. Fed Regist. Document no. 2014-03592. [Internet]. 2014 February 20 [cited 2020 Jan 13];79(34):9745–7. Available from: https://www.federalregister.gov/documents/2014/02/20/2014-03592/standards-for-the-interoperable-exchange-of-information-for-tracing-of-human-finished-prescription |
| 3. | U.S. Department of Health and Human Services Food and Drug Administration. DSCSA Pilot Project Program. [Internet]. U.S. Department of Health and Human Services Food and Drug Administration [updated 22 May 2019; cited 2020 Jan 13]. Available from: https://www.fda.gov/drugs/drug-supply-chain-security-act-dscsa/dscsa-pilot-project-program |
| 4. | UCLA Health. About us: Best healthcare, latest medical technology [Internet]. [cited 2020 Jan 13]. Los Angeles, CA: UCLA Health. Available from: https://www.uclahealth.org/about-us |
| 5. | Sklodosky C, Shakur I, Plante G, Taylor B. Transforming pharmaceutical clinical supply messaging with blockchain. Version 1.8 [Internet]. Clinical Supply Blockchain Working Group; 2019 [cited 2020 Jan 13]. Available from: http://kitchain.org/transforming-clinical-supply-whitepaper |
| 6. | Federal Food, Drug, and Cosmetic Act, 21 U.S.C; 1938 [cited 2020 Jan 13]. Available from: https://www.fda.gov/regulatory-information/laws-enforced-fda/federal-food-drug-and-cosmetic-act-fdc-act |
| 7. | U.S. Department of Health and Human Services Food and Drug Administration. Drug Supply Chain Security Act implementation: Identification of suspect product and notification guidance for industry. Docket no. FDA-2013-S-0610. [Internet]. Silver Spring, MD: U.S. Department of Health and Human Services Food and Drug Administration; 2016 [cited 2020 Jan 13]. Available from: https://www.fda.gov/media/88790/download |
| 8. | Microsoft Azure. Online transaction processing (OLTP) [Internet]. Microsoft Azure; 2019 July 26 [cited 2020 Jan 13]. Available from: https://docs.microsoft.com/en-us/azure/architecture/data-guide/relational-data/online-transaction-processing |
| 9. | Microsoft Azure. Online analytical processing (OLAP) [Internet]. Microsoft Azure; 2018 February 11 [cited 2020 Jan 13]. Available from: https://docs.microsoft.com/en-us/azure/architecture/data-guide/relational-data/online-analytical-processing |
| 10. | Chowdhury M, Colman A, Kabir A, Han J, Sarda P. Blockchain versus database: A critical analysis. 2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/12th IEEE International Conference On Big Data Science And Engineering. DOI: 10.1109/TrustCom/BigDataSE.2018.00186. [cited 2020 Jan 13]. Available from: https://www.researchgate.net/publication/327483781_Blockchain_Versus_Database_A_Critical_Analysis |
| 11. | Archa, Alangot B, Achuthan K. Trace and track: Enhanced pharma supply chain infrastructure to prevent fraud. Ubiquitous Communications and Network Computing [cited 2020 January 13];189–95. DOI:10.1007/978-3-319-73423-1_17. Available from: https://link.springer.com/chapter/10.1007%2F978-3-319-73423-1_17 |
| 12. | GS1 Healthcare US. Update: Barcode readability for DSCSA 2023 interoperability. [Internet]. Ewing, NJ: GS1 US; 2019 [cited 2020 Jan 13]. Available from: https://www.gs1us.org/documents?Command=Core_Download&EntryId=1933 |
| 13. | Finkel RS, McDermott MP, Kaufmann P, et al. Observational study of spinal muscular atrophy type I and implications for clinical trials. Neurology [Internet]. 2014 July 30 [cited 2020 Jan 13];83(9):810–7. Available from: https://n.neurology.org/content/83/9/810. DOI:10.1212/WNL.0000000000000741 |
| 14. | SPINRAZA (nusinersen) injection, for intrathecal use [package insert on the Internet]. Cambridge, MA: Biogen; 2016 [cited 2020 Jan 13]. Available from: https://www.accessdata.fda.gov/drugsatfda_docs/label/2016/209531lbl.pdf |
| 15. | NITAAC Solutions. NITAAC Solutions Showcase blog [Internet]. Blockchain: Innovations in health data sharing with FDA and Booz Allen. 2019 February 1 [cited 2020 Jan 13]. Available from: http://nitaac-nih.hs-sites.com/showcase/blockchain-innovations-in-health-data-sharing-with-fda-and-booz-allen |
| 16. | Androulaki E, Barger A, Bortnikov V, et al. Hyperledger fabric: A distributed operating system for permissioned blockchains. Proceedings of EuroSys 2018 conference [Internet]. 2018 [cited 2020 Jan 16]. Available from https://arxiv.org/abs/1801.10228. DOI: 10.1145/3190508.3190538. |
| 17. | Voshmgir S. Token economy: How blockchains and smart contracts revolutionize the economy. Berlin: Shermin Voshmgir; 2009. |
| 18. | Federal Food, Drug, and Cosmetic Act, 21 U.S.C § 582(b)(2)(A). 1938 [updated 2014 Dec 16, cited 2020 Jan 13]. Available from: https://www.fda.gov/drugs/drug-supply-chain-security-act-dscsa/title-ii-drug-quality-and-security-act |
| 19. | Federal Food, Drug, and Cosmetic Act, 21 U.S.C § 582(a)(9). 1938 [updated 2014 Dec 16, cited 2020 Jan 13]. Available from: https://www.fda.gov/drugs/drug-supply-chain-security-act-dscsa/title-ii-drug-quality-and-security-act |
| 20. | U.S. Department of Health and Human Services Food and Drug Administration. Product identifiers under the Drug Supply Chain Security Act questions and answers guidance for industry. Silver Spring, MD: U.S. Department of Health and Human Services Food and Drug Administration; September 2018 [cited 2020 Jan 13]. Available from: https://www.fda.gov/media/116304/download |
| 21. | GS1 Healthcare US. Identification of investigational products in clinical trials application standard. Release no. 1.0.1. [Internet]. GS1 US; March 2019 [cited 2020 Jan 13]. Available from: https://www.gs1.org/docs/barcodes/GS1_ClinicalTrial_Application_Standard.pdf |
| 22. | LedgerDomain [Internet]. Las Vegas, NV: LedgerDomain; c2019. BRUINchain Privacy Policy; c2019 [cited 2020 Jan 13]. Available from: https://www.ledgerdomain.com/privacy-policy-bruinchain |
| 23. | GS1 Healthcare US. 2019 Update: Barcode readability for DSCSA 2023 interoperability [Internet]. Ewing, NJ: GS1 US; 2019 [cited 2020 Jan 29]. Available from: https://www.gs1us.org/DesktopModules/Bring2mind/DMX/Download.aspx?Command=Core_Download&EntryId=1933&language=en-US&PortalId=0&TabId=134 |
| 24. | GS1 Healthcare US. Assessing current implementation of DSCSA serialization requirements [Internet]. Ewing, NJ: GS1 US; 2018 [cited 2020 Jan 29]. Available from: https://www.gs1us.org/DesktopModules/Bring2mind/DMX/Download.aspx?Command=Core_Download&EntryId=1210&language=en-US&PortalId=0&TabId=134 |
| 25. | FDA Form 3911, Drug notification to FDA 2019 (US) [cited 2020 Jan 13]. Available from: https://www.fda.gov/media/99185/download |
| 26. | Mikulic M. Total number of medical prescriptions dispensed in the U.S. from 2009 to 2018 (in millions). Statista; May 2019 [cited 2020 Jan 13]. Available from: https://www.statista.com/statistics/238702/us-total-medical-prescriptions-issued/ |
| 27. | U.S. Bureau of Labor Statistics. Pharmacy technicians [Internet]. Washington, DC: United States Department of Labor. [updated 2019 Mar 29; cited 2020 Jan 13]. Available from: https://www.bls.gov/oes/current/oes292052.htm |
| 28. | U.S. Bureau of Labor Statistics [Internet]. Pharmacists. Washington, DC: United States Department of Labor. [updated 2019 Mar 29; cited 2020 Jan 13]. Available from: https://www.bls.gov/oes/current/oes291051.htm |
| 29. | U.S. Bureau of Labor Statistics. Employer costs for employee compensation—September 2019 [Internet]. USDL-19-2195. Washington, DC: United States Department of Labor 2019 December 18 [cited 2020 Jan 13]. Available from: https://www.bls.gov/news.release/pdf/ecec.pdf |
| 30. | Fein AJ. 2018 MDM market leaders: Top pharmaceutical distributors [Internet]. MDM Analytics; 2019 [cited 2020 Jan 29]. Available from: https://www.mdm.com/2018-top-pharmaceuticals-distributors |
| 31. | Coase R. The problem of social cost. Journal of Law and Economics. The University of Chicago Press, Vol. 3 [Oct. 1960]:1–44. DOI:10.1086/466560. |
| 32. | Calabresi G, Melamed AD. Property rules, liability rules and inalienability: One view of the cathedral. Harvard Law Review. 1972;85:1089–128. |
| 33. | Barcodes, Inc. [Internet]. Not barcodes or RFID, but both. c2012 [cited 2020 Jan 13]. Available from: https://www.barcodesinc.com/news/not-barcodes-or-rfid-but-both/ |
Copyright Ownership: This is an open access article distributed in accordance with the Creative Commons Attribution Non Commercial (CC BY-NC 4.0) license, which permits others to distribute, adapt, enhance this work non-commercially, and license their derivative works on different terms, provided the original work is properly cited and the use is non-commercial. See: http://creativecommons.org/licenses/by-nc/4.0.
iUnder DSCSA, the term “dispenser” “(A) means a retail pharmacy, hospital pharmacy, a group of chain pharmacies under common ownership and control that do not act as a wholesale distributor, or any other person authorized by law to dispense or administer prescription drugs, and the affiliated warehouses or distribution centers of such entities under common ownership and control that do not act as a wholesale distributor; and (B) does not include a person who dispenses only products to be used in animals in accordance with section 512(a)(5).” See Reference 1.
iiAll product names, trademarks ,and registered trademarks are the property of their respective owners. All company, product, and service names used in this paper are for identification purposes only. Use of these names, trademarks, and brands does not imply endorsement. SPINRAZA is a registered trademark of Biogen Inc. Pyxis is a trademark of Becton, Dickinson and Company. UCLA, UCLA Bruins, University of California Los Angeles and all related trademarks are the property of the Regents of the University of California. Hyperledger and Hyperledger Fabric are trademarks of the Linux Foundation. The DocuSeal, Selvedge, and Oraculous software programs and the accompanying procedures, functions, and documentation described herein are sold under license agreement(s) by LedgerDomain Inc. Their use, duplication, and disclosure are subject to the restrictions stated in the license agreement(s). The QuaRxantine image is property of LedgerDomain Inc.
iiiThe benefits of permissioned versus non-permissioned blockchain systems are a well-established and hotly discussed question within the blockchain community, and outside the scope of this paper.
ivOracles are “services that send and verify real world occurrences and submit this information to smart contracts, triggering state changes on the blockchain.” See reference 17.
vTraining and testing in the infusion pharmacy, in which the workflow includes affixing patient names and subsequently dispensing either directly to nurses or through a Pyxis™ interface.
viThe smaller study drug barcodes were approximately 7.5 mm2, while the larger were approximately 10.5 mm2. In study trials, the larger barcodes scanned slightly faster. The smaller barcode times were more variable, but the fastest set required 15% more time to perform the scan compared to the larger barcodes.
viiA US federal government program that requires drug manufacturers to provide certain drugs to healthcare organizations and covered entities at significantly reduced prices.
viiiThe specific calculations regarding the exact amount of safety stock to hold are complex and depend on a variety of factors, including expected utilization of a drug, daily variance in utilization, relative stock of sub-warehouses in the verified tier, and desired safety margins.