Medical syringes and systems and methods for injection management platforms

Abstract

The systems, methods, and articles provide an injection management platform that allows for the verification and management of injection event transactions involving syringes equipped with NFC or RFID chips, utilizing distributed security technologies such as blockchain. An injection event transaction ledger allows for the secure verification and updating of digital receipts for injection event transactions. According to some embodiments, the syringe may include a blow-fill-seal (BFS) syringe pre-filled with a single dose of a fluid medication comprising a vaccine or drug, thereby allowing the tracking of individual doses of the fluid medication via the injection event transaction ledger.

Description

[0001] Priority requirements

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 019,192, filed May 1, 2020, in the name of Jay S. Walker, entitled "NFC-ENABLEDDRUG CONTAINING SYSTEM AND ASSOCIATED INFORMATION LAYER". The entire contents of that provisional application are incorporated herein by reference for all purposes.

[0003] Copyright Notice

[0004] This patent document discloses a portion of copyrighted material. The copyright holder does not object to any reproduction of the patent document or patent disclosure appearing in the patent documents or records of the Patent and Trademark Office, but retains all copyrights.

[0005] background

[0006] Every year, a staggering number of people contract and die from a variety of diseases, some of which can be prevented (or have their severity reduced) by injectable medication (i.e., medication delivered via syringe or other needle-based medical delivery devices). While injectable medication has led to a dramatic decrease in the number of cases (or the severity of symptoms or deaths) of several infectious diseases, some remain quite common, and new diseases are emerging. In many cases, large parts of the world’s population suffer from the spread of preventable diseases due to ineffective injectable medication / vaccine delivery programs, either due to poor implementation, lack of available medication / vaccines, insufficient skilled personnel to administer injections, inadequate tracking and management of sites where injections have been given and where injections are still needed, or a combination of these factors.

[0007] Recent global events have further highlighted the inadequacies of existing vaccine and other injectable medication administration programs. This pandemic is an example in which the public would benefit from (i) the ability to verifiable and effective track who has been vaccinated (and potentially where, when, and with which specific vaccine); (ii) allowing people to effectively provide evidence of vaccination (and, in some embodiments, situations where current vaccination status, such as vaccine effectiveness requiring booster or additional injections); (iii) identifying population areas with ongoing vaccination needs; and / or (iv) broadening the reach of vaccination efforts by providing means of administering vaccines to less experienced individuals. Existing systems and infrastructure have proven insufficient to meet these needs. Attached Figure Description

[0008] When considered in conjunction with the accompanying drawings, the embodiments described herein and their many accompanying advantages can be readily understood by referring to the following detailed description, wherein:

[0009] Figure 1 These are example block diagrams of systems consistent with at least some of the embodiments described herein;

[0010] Figure 2 This is an example block diagram of a server device consistent with at least some of the embodiments described herein;

[0011] Figures 3A to 3L These are example graphical user interfaces of mobile device applications (Apps) that can be output to users according to some embodiments described herein;

[0012] Figure 4 This is an example process flowchart that is consistent with at least some of the embodiments described herein. Detailed Implementation

[0013] The embodiments described herein relate to a syringe for administering a single-dose fluid medication, the syringe being equipped with a data storage mechanism that allows for electronic identification, tracking, and / or authorization of single-dose administration to a patient. In some embodiments, an electronic platform is operable to facilitate (i) the transmission of data from the syringe to the injection provider's device, and then to the platform's electronic processing system, to facilitate the authorization and tracking of the administration of a dose of fluid medication from the syringe to the patient; and / or (ii) the exchange of data with the patient's device, allowing the patient to receive and store a digital receipt indicating that a single dose of fluid medication has been administered from the syringe. The electronic platform also allows healthcare systems and authorities to generate and utilize an information layer associated with the syringe equipped with the data storage mechanism.

[0014] As used herein, the term "syringe" refers to a device filled with a single-dose fluid medication, such as a vaccine or drug (in some embodiments, it may include lyophilized components that can be recombined into a fluid prior to injection). Syringes may be made of plastic, glass, or other materials, and the embodiments described herein do not depend on syringes made of any particular material. Syringes may include, for example, auto-injectors equipped with a spring or having another mechanism for assisting in the injection of the fluid medication, or manual syringes that rely on user operation of the injection mechanism. Examples of manual syringes include plunger syringes or plastic vial syringes (e.g., blow-fill-seal ("BFS") syringes), which require pressure or squeezing action from the injection provider (e.g., a nurse or patient, in the case of self-injection) to expel the fluid medication from the vial or other components of the syringe for containing the fluid medication. Examples of syringe devices that may be used in the embodiments described herein can be found in PCT application No. PCT / US21 / 25683, filed April 3, 2021, by Koska et al., entitled “SYSTEMS AND METHODS FOR PRE-FILLED MEDICAL DELIVERY DEVICES”, and PCT application No. PCT / US18 / 61696, filed November 16, 2018, by Koska et al., each of which is incorporated herein by reference.

[0015] It should be noted that syringes pre-filled with a single-dose fluid agent can be pre-filled during the manufacturing process (pre-filling), such as the BFS syringe described in the previously cited PCT application by Koska et al., or filled by the injection provider, for example, by drawing a single dose from a multi-dose container (on-site filling). On-site filled or on-site fillable syringes are those in which, prior to injection, the injection provider draws a single dose of liquid agent from another container (e.g., a multi-dose vial) into the syringe. In on-site filled syringes, the dose of liquid agent administered via the syringe is not unique to the syringe, so the injection provider may need to provide two pieces of data to identify the syringe and the identifier of the multi-dose vial from which the dose was drawn. In pre-filled syringes, the unique identifier of the syringe inherently identifies both the syringe itself and the dose of the fluid agent contained therein. For example, in embodiments where information such as batch number, fluid agent type, manufacturer, and dose manufacturing date is of interest, it may be necessary to identify the dose of the fluid agent. The embodiments described herein focus primarily on pre-filled syringes.

[0016] According to the embodiments described herein, the syringe is equipped with a data storage mechanism that uniquely identifies each syringe, for example by storing a unique identifier for each syringe, which is generated during syringe manufacturing (and, in the case of pre-filled syringes, when the syringe is pre-filled with a dose of fluid medication). Such a data storage mechanism may include, for example, a near-field communication (NFC) chip, a radio frequency identification (RFID) chip, a two-dimensional (QR) code, a barcode, or any other machine-readable means that allows the unique identifier of the syringe to be stored in association with the syringe (e.g., attached to or embedded in the syringe or a portion thereof, such as above or below a label on the label portion of the syringe).

[0017] It should be noted that in some embodiments, unique identifiers and / or other data stored on the NFC chip or other data storage mechanism may be stored in encrypted form. It should also be noted that in some embodiments, communication with the NFC chip (or other data storage mechanism) and / or the injection management application may be accomplished in encrypted form (e.g., using a public-private key protocol) or by utilizing other security measures (e.g., two-factor authentication or blockchain technology).

[0018] According to some embodiments, the injection management system may include an injection management application to facilitate the verification / authorization of injections via syringes equipped with a data storage facility as described herein. Individuals may utilize the injection management application to communicate with centralized or decentralized (e.g., blockchain-based) systems to create and utilize information layers or electronic record storage based on syringe usage. According to some embodiments, the injection management application may include an injection provider portal or platform through which an injection provider, or other individuals (“injection providers”) using syringes to administer fluid medications as described herein, can log into the system and gain access to the functionality of such an injection provider. For example, an injection provider may use the injection management application to verify that a specific dose in a pre-filled syringe is valid and authorized for use (e.g., not counterfeit, not expired, and not subject to recall), then administer it to a patient, and use the injection management system to record each injection event, including instances where the injection provider has provided a specific patient with a dose of fluid medication packaged in a uniquely identified syringe. Similarly, injection management applications may include a patient portal or platform through which an individual receiving an injection (“patient”) can log in to the system to access functions (e.g., obtain a digital receipt to be stored on the patient’s mobile device, which may be shared with a third party in some form to provide verification that a specific vaccine has been administered or a specific dose of fluid medication has been received).

[0019] In some embodiments and situations, a given individual may act as both an injection provider and a patient. In some embodiments, for a given injection event, a given individual may act as both an injection provider and a patient (e.g., the individual may administer the injection themselves).

[0020] The applicant notes that utilizing uniquely identifiable pre-filled syringes and providing an injection management application operable to identify injection events using that syringe offers one or more advantages over existing healthcare systems. For example, many implementations of immunization programs typically involve administering vaccines via typical reusable syringes. However, in many cases, vaccine administration occurs outside of hospitals and may be provided by untrained individuals, resulting in injections to patients without careful control over syringe use. The use of reusable syringes in these situations increases the risk of infection and transmission of bloodborne diseases, especially when previously used and no longer sterile syringes are used for subsequent injections. For example, the World Health Organization (WHO) estimates that bloodborne diseases such as hepatitis and human immunodeficiency virus (HIV) are spreading due to the reuse of such syringes, causing more than one million deaths annually. Utilizing pre-filled syringes equipped with unique identifiers, and particularly providing easy-to-use injection management applications that track when a particular syringe is used and, according to some embodiments, output warnings or, more than once, refuse authorization to administer a dose of fluid medication from a particular syringe, would help mitigate these drawbacks of existing systems.

[0021] The embodiments presented herein describe systems, apparatuses, interfaces, methods, and articles of manufacture for managing, tracking, authorizing, and verifying injection events in which a patient receives an injection of a dose of fluid medication from a syringe equipped with a unique identifier. For example, in some embodiments, an injection management system (which, in some embodiments, may incorporate a blockchain distributed network system for security purposes) facilitates a method that provides (i) identifying a first injection event transaction, wherein the identification is based on receiving an instruction to administer a dose of fluid medication to a patient via an injection provider platform stored via an injection management application corresponding to a first user, the instruction including first data including a unique identifier of the syringe containing the dose, wherein the first user previously logged into the injection provider platform via the first mobile device by providing first user credentials, the first user credentials allowing the electronic processing device to uniquely identify the first user and recognize the first user as a registered injection provider; (ii) authorizing the dose of fluid medication based on the unique identifier of the syringe; (iii) generating an electronic record unique to the first injection event transaction, thereby generating a first injection event record; (iv) receiving an instruction from the first user and via the injection management application that the dose has been administered to the patient; and (v) generating a first injection event record in response to the receipt. (vi) A verification code, the first verification code corresponding to an expiration time of the first verification code, and stored in association with the first injection event record; (vii) Outputting the first verification code to a first user via an injection management application; (vii) Receiving the first verification code from a second user before the expiration time, wherein the second user has previously logged into the patient platform of the injection management application via a second mobile device by providing a second user credential, the second user credential allowing an electronic processing device to uniquely identify the second user and recognize the second user as a registered patient; (viii) Based on receiving the first verification code from the second user, inferring that the second user is a patient to whom the first user has administered a dose of fluid medication from a syringe as part of the first injection event transaction; (ix) Updating the first injection event record to indicate that the dose of fluid medication has been administered to the second user; and (x) Transmitting a verifiable confirmation that the dose of fluid medication has been administered to the second user's second mobile device via the patient portal of the injection management application, thereby transmitting a digital receipt of the first injection event to the second mobile device for storage in the patient portal of the second user's injection management application.

[0022] The applicant hereby describes various improvements that can be made to syringes such as BFS tubes or conventional glass vials by including or attaching a unique identifier within the syringe. The unique identifier can be in the form of a physical component, such as an NFC or RFID chip, or a QR code. Regardless of the form in which the unique identifier is embodied, the presence of a unique identifier associated with each syringe allows for the creation of an information layer around or associated with the syringe (or the dose contained within the syringe, particularly in the case of pre-filled syringes) and / or the patient receiving the dose of fluid medication packaged within the syringe. While the various embodiments described herein are applicable to syringes including BFS tube syringes, it should be understood that at least some of these embodiments are also applicable to glass or other vial or syringe systems that can benefit from the data generation and new functionalities described herein. Therefore, it should be understood that when referring to BFS tubes or other specific types of syringes, this reference is not intended to be limiting, and in various embodiments, the same or similar functionality can be provided for other types of syringes used as containers for fluid medications. Similarly, while this document references NFC chip-driven syringes in some embodiments, this reference is intended to refer to any type of syringe (whether BFS tube mechanism, conventional glass bottle, or others) associated with a unique identifier that can be read by the software application described herein (e.g., having an NFC or RFID chip embedded therein or attached in some way, or a QR code attached thereto, which allows the unique identifier of the NFC chip to uniquely identify the corresponding syringe and a specific dose of the fluid medicine contained therein). A syringe with such a corresponding unique identifier is also referred to herein as a unique ID syringe. It should be noted that the use of the term "syringe" instead of "unique ID syringe" should not be construed as implying that the unique identifier is not associated with the syringe in the context described, as the term "syringe" is used as an abbreviation for "unique ID syringe" in some paragraphs. Furthermore, it should be noted that in some embodiments, a unique identifier or data storage device that includes a unique identifier attached to, embedded in, printed or embossed on or otherwise associated with the syringe may include a unique identifier, or a data storage device that stores a unique identifier together with the syringe may mean that the unique identifier or data storage device is attached to or otherwise associated with a particular component (e.g., a BFS tube or a label portion of a BFS tube) or the packaging of the syringe (e.g., an NFC chip may be attached to the foil packaging of the syringe).

[0023] The applicant has recognized that including a data storage mechanism such as an NFC chip in each syringe (e.g., having a data storage mechanism in, or connecting to, or otherwise corresponding to, the syringe or its components) will allow for certain new and useful benefits, such as: (i) allowing the syringe to connect to the Internet of Things (IoT) and / or communicate with remote servers and / or other devices connected to the IoT; (ii) enabling adherence tracking / reward mechanisms (e.g., for self-injection, multiple-injection therapy, or other situations); and (iii) allowing users of the uniquely ID syringe (whether the user is the injection provider, the patient receiving the injection, or a parent, guardian, or other person associated with the patient receiving the injection) to use a specially coded syringe on mobile devices or other devices. The software application for the process (which has been previously downloaded to the device), referred to herein as the injection management application, inputs data or information into the application and / or allows the application to read information from a data storage mechanism (and, in some embodiments, writes data to the data storage mechanism, such as if the data storage mechanism includes an NFC or RFID chip); (iv) allows verification, authorization, tracking, confirmation, and reward of the administration of fluid medication from the syringe to the patient; and (v) allows subsequent communication (e.g., text messages or messages output by the injection management application) to the patient who has received an injection from such syringe, such as reminding the patient to self-administer an additional dose or return to the clinic for an additional dose, inquiring about possible adverse reactions, receiving confirmation that an additional verified or authorized dose has been administered to the patient as advised, and so on.

[0024] It should be noted that when injecting a fluid medication from an NFC-driven syringe, at least three different types of users may be involved: (i) the injection provider, such as a healthcare worker; (ii) the patient receiving the fluid medication; and (iii) the patient's guardian (e.g., parent), friend, or family member (in some cases, a person in a village sharing a mobile device with the patient; collectively referred to herein as a patient liaison). Not all of these types of users may be involved in a given injection. According to some embodiments, one or more of these users may access different platforms, portals, or versions of the injection management application (or different aspects, features, or pages of such an application) on their mobile devices to facilitate one or more embodiments described herein. For example, the injection provider may access and utilize a first version or aspect of the injection management application (referred to as the provider platform of the injection management application), while the patient or patient liaison may access or utilize a second version or aspect of the injection management application (referred to as the patient platform of the injection management application). In some embodiments, the patient platform may facilitate tracking of vaccines or other fluid medications administered to a particular patient and provide online or electronic records of the vaccines or other fluid medications administered to the patient (e.g., digital receipts or electronic vaccine vouchers for injection events). In some cases, a family can share a mobile device on which an app can track the injections of multiple family members.

[0025] According to some embodiments, injection management applications (whether provider platforms or patient platforms) may allow data transfer to / from a remote server (referred to herein as an injection management service) of a service that provides or manages the injection management application and the injection data collected therefrom. In some embodiments, according to at least some embodiments described herein, the injection management service may be involved in (e.g., controlling or having a business relationship with an entity that so controls) the manufacture and / or distribution of the unique ID syringes described herein, and store records of unique ID syringes manufactured according to the embodiments described herein and tracked from the point of manufacture to the point of injection. In some embodiments, when a device on which the application is downloaded cannot communicate with the injection management service (e.g., when the device is not connected to Wi-Fi or has insufficient cellular service connectivity), data collected via the injection management application may be cached and stored in local memory, and then transferred to the injection management service once sufficient communication connections are established. According to some embodiments, the injection management service may open a record in a database for each unique ID syringe manufactured according to the embodiments described herein. In some embodiments, the injection management service may store in the record a unique identifier of an NFC or RFID chip embedded or attached to the vial, along with other information corresponding to the dosage of the fluid medication (e.g., manufacturing time and place; batch, lot number, and / or test strip number; type of fluid medium; dosage of the fluid; expiration date of the fluid medication; etc.). Subsequently, when a user (e.g., injection provider, patient, or patient contact person) taps the unique ID of the syringe onto their mobile device, the injection management application may read the unique identifier (e.g., NFC chip identifier) ​​stored in the data storage of the syringe and communicate with the injection management service to retrieve information associated with the vial / chip in order to (i) verify or authorize the injection (e.g., check that the fluid medication is not expired or recalled); (ii) open or create a new record (or update information in an existing data record) to indicate that the dosage of the fluid medication corresponding to that identifier is being injected. This may also include storing various new information obtained from the user or based on tapping the vial onto the phone. The information includes indications such as the time / location of the injection; an identifier of the injection provider, if any; a patient identifier and / or an identifier of the patient's associated mobile device (e.g., a phone number), also referred to herein as an injection event record. In some embodiments, the injection management service operates an injection management system including one or more servers operable to communicate with a user's mobile device, on which the injection management application is installed and which is a registered device and / or user of the system. In some embodiments, the injection management system utilizes a distributed server network of a blockchain type to store injection event records (e.g., for security purposes).

[0026] In some embodiments, in addition to contacting the injection management service to verify or authorize the injection, or instead of contacting the injection management service, once the user taps the vial onto their mobile device to open the injection management application, the injection management application can read information from a data storage facility other than the chip identifier (e.g., an NFC or RFID chip may store information such as expiration date, dosage, and type of fluid medication contained in the vial), and use that information to authorize the injection and output to the user that he / she can continue with the injection.

[0027] According to some embodiments, the unique ID syringe includes a BFS tube mechanism. The applicant envisions that, during the BFS manufacturing process described herein, a pre-filled BFS tube filled with a fluid agent can be embedded within its plastic, or otherwise attached to or included therein or on its surface or portion, with an NFC chip (the term "embedded" will be used for brevity but is intended to encompass all forms of attachment, impregnation, embedding, or addition to or on the tube, whether the tube is a BFS tube, another type of plastic bottle, or a glass bottle). In other embodiments, during manufacturing, a data storage device (whether an NFC chip, an RFID chip, or other form) can be bonded to or otherwise attached to the syringe (e.g., it can be bonded to or otherwise attached to a label on the label portion of the BFS bottle).

[0028] Turn now Figure 1 A block diagram of a system 100 according to some embodiments is shown. In some embodiments, system 100 may include a plurality of node devices 102a-n, a network 104, a management device 106, and / or a server device 110. According to some embodiments, any or all of devices 102a-n, 106, and 110 may include data storage and / or storage devices 140-1a-n, 140-2, and / or communicate with them. Each node device 102a-n may include a local storage device 140-1a-n, for example, and / or server device 110 may include a network storage device 140-2. Figure 1As shown, any one or all (or any combination thereof) of devices 102a-n, 106, 110, 140-1a-n, and 140-2 can communicate via network 104. In some embodiments, communication between and / or within devices 102a-n, 106, 110, 140-1a-n, and 140-2 of system 100 can be used to provide and manage a distributed injection event transaction ledger. For example, server device 110 can interface with one or more node devices 102a-n and / or management device 106 to execute multiple instances of specially programmed chaincode (not shown) stored in storage devices 140-1a-n and 140-2, and / or provide a specially constructed interface through which users participating in injection event transactions can obtain, verify, and / or modify status information regarding injection event transactions.

[0029] System 100 may include fewer or more components 102a-n, 104, 106, 110, 140-1a-n, 140-2 and / or various configurations of the depicted components 102a-n, 104, 106, 110, 140-1a-n, 140-2 without departing from the scope of the embodiments described herein. In some embodiments, components 102a-n, 104, 106, 110, 140-1a-n, 140-2 may be similar in configuration and / or function to similarly named and / or numbered components described herein. In some embodiments, system 100 (and / or portions thereof) may include a distributed injection event management program, system and / or platform programmed and / or otherwise configured to perform, implement and / or facilitate the methods described herein, including method 400 and / or portions thereof.

[0030] In some embodiments, node devices 102a-n may include any type or configuration of computing, mobile electronics, networking, user, and / or communication devices that are known or feasible. Node devices 102a-n may, for example, include one or more electronic devices, such as mobile devices including cellular and / or wireless phones, such as the iPhone® (also manufactured by Apple®) or the LG Optimus™ Zone™ 3 smartphone manufactured by LG® Electronics, Inc. of San Diego, CA, and running Android from Google®, Inc. of Mountain View, CA. ®Operating system. In some embodiments, node devices 102a-n may include devices owned and / or operated by one or more users, such as patients, injection providers, or third parties seeking confirmation of information about a specific injection event. According to some embodiments, node devices 102a-n may communicate with server device 110 via network 104 to perform injection verification queries and / or processes and / or record, store, confirm, or update information about injection events (e.g., the fact that a particular patient received a specific dose of a specific fluid medication on a specific date, time, and / or location, and / or the patient's current vaccination status (e.g., as a result of participation in a vaccination event)). According to some embodiments, node devices 102a-n may each store an instance of an injection management application as described herein, through which users of node devices 102a-n may communicate with an injection management system that may own, control, or operate (or operate on behalf of) server device 110.

[0031] In some embodiments, for example, node devices 102a-n may interface with server device 110 and / or management device 106 to enable (direct or indirect) communication with one or more other node devices 102a-n operated by other users (such communication is not in...). Figure 1 (as explicitly shown in the document). In some embodiments, node devices 102a-n may interface with server device 110 to enable (direct or indirect) communication with management device 106 (such communication is not explicitly shown in the document). Figure 1 (As explicitly shown herein). In some embodiments, node devices 102a-n and / or server device 110 may execute separate instances of a chaincode algorithm that enables the injection event transaction ledger to be distributed in a cryptographic and verifiable manner. As described herein, for example, node devices 102a-n and / or server device 110 may communicate with management device 106 to perform cryptographic services for securely propagating injection event chaincode blocks or payloads to multiple node devices 102a-n.

[0032] According to some embodiments, network 104 may include a local area network (LAN; wireless and / or wired), cellular phone, Bluetooth®, near field communication (NFC), and / or radio frequency (RF) network, having communication links between server devices 110, node devices 102a-n, management devices 106, and / or storage devices 140-1a-n, 140-2. In some embodiments, network 104 may include direct communication links between any or all of the components 102a-n, 106, 110, 140-1a-n, 140-2 of system 100. Node devices 102a-n may, for example, directly interface with or connect to one or more server devices 110 and / or management devices 106 via one or more wires, cables, wireless links, and / or other network components (such network components, such as communication links, include portions of network 104). In some embodiments, network 104 may include one or more different from Figure 1 Other link or network components are shown. Node devices 102a-n can be connected to server device 110 and / or management device 106, for example, via various cell towers, routers, repeaters, ports, switches and / or other network components, including the Internet and / or cellular telephone (and / or Public Switched Telephone Network (PSTN)) networks, and include portions of network 104.

[0033] Although network 104 is Figure 1 While described as a single object, network 104 can include any number, type, and / or configuration of networks that are or become known or implementable. According to some embodiments, network 104 can include an aggregation of different subnets and / or network components directly or indirectly interconnected by components 102a-n, 106, 110, 140-1a-n, 140-2 of system 100. Network 104 can include, for example, one or more cellular telephone networks having communication links between node devices 102a-n and server device 110, and / or can include, for example, the Internet having communication links between server device 110 and management device 106 and / or one or more storage devices 140-1a-n, 140-2.

[0034] In some embodiments, management device 106 may include any type or configuration of computerized processing equipment, such as a PC, laptop computer, computer server, database system, and / or other electronic devices, apparatus, or any combination thereof. In some embodiments, management device 106 may be owned and / or operated by a third party (i.e., an entity different from any entity that owns and / or operates node devices 102a-n or server device 110; for example, a credential, authentication, and / or encryption service provider). Management device 106 may, for example, perform one or more web services that provide centralized blockchain encryption capabilities, such as the Hyperledger™ Fabric™ blockchain framework available from The Linux Foundation® of San Francisco, CA. In some embodiments, management device 106 may receive blockchain data from one or more node devices 102a-n and / or server device 110, apply a hash algorithm to the received data, and transmit encrypted data to each of node devices 102a-n and server device 110 (e.g., for storage in a local copy of the blockchain ledger). According to some embodiments, management device 106 may include multiple devices and / or may be associated with multiple third-party entities.

[0035] In some embodiments, server device 110 may include electronic and / or computerized controller devices, such as computer servers communicatively linked to interface (directly and / or indirectly) with node devices 102a-n and / or management device 106. For example, server device 110 may include one or more PowerEdge™ R830 rack servers manufactured by Dell®, Inc. of Round Rock, TX, which may include one or more twelve-core Intel® Xeon® E5-4640 v4 electronic processing units. In some embodiments, server device 110 may include multiple processing units specifically programmed to perform and / or implement processes that would be impossible without the assistance of server device 110. For example, server device 110 may execute one or more coded rules to manage a blockchain ledger of multiple injection event transactions, allowing for real-time updates and adjustments to the injection event status that would not be possible without the benefit of a specially programmed server device 110. According to some embodiments, the server device may include an injection management system as described herein, operable to communicate with the patient and injection provider via their respective mobile devices (e.g., node devices 102a-n) to obtain, update, and transmit verification of data stored in injection event records contained in an injection event transaction ledger, an injection event database, or other electronic record repository indicating injection events tracked and managed by the injection management system.

[0036] According to some embodiments, server device 110 may be located remotely from one or more node devices 102a-n and / or management device 106. Server device 110 may also or optionally include multiple electronic processing devices located at one or more different locations and / or positions.

[0037] According to some embodiments, server device 110 may store and / or execute specially programmed instructions to operate according to the embodiments described herein. Server device 110 may, for example, execute one or more programs, modules, and / or routines that facilitate the management, tracking, authorization, verification, and / or updating of injection events, for example, in an online environment via an injection management application as described herein. According to some embodiments, server device 110 may include computerized processing devices, such as computer servers and / or other electronic devices, to manage and / or facilitate transactions and / or communications concerning node devices 102a-n. Private companies, government health agencies, healthcare companies, syringe manufacturers, and / or other users may utilize server device 110, for example, to (i) receive or identify injection events associated with a syringe with a unique ID; (ii) authorize injections from such syringes; (iii) receive confirmation from the injection provider that a specific dose of a fluid agent has been administered to a specific patient (e.g., on a specific date / time / or location); (iv) as a result of any of the foregoing, store the vaccination status of a specific patient for a specific vaccine; and / or (iii) provide an interface through which third parties can confirm a patient's vaccination status and / or provide real-time updates, as described herein.

[0038] In some embodiments, node devices 102a-n, management device 106, and / or server device 110 may communicate with memory devices 140-1a-n, 140-2. Memory devices 140-1a-n, 140-2 may include, for example, various databases and / or data storage media that may store, for example, syringe data, fluid drug data, registered patient data, registered injection provider data, injection event data and / or injection or vaccination status data obtained from node devices 102a-n, digital receipt data defined by server device 110 (including the privacy level associated with the digital receipt, in embodiments employing such a level), injection authorization processing rules, chaincode instructions, blockchain data, keys and / or data, login and / or identity credentials of registered users, and / or instructions to operate various devices (e.g., server device 110, management device 106, and / or node devices 102a-n) according to the embodiments described herein.

[0039] Storage devices 140-1a-n and 140-2 may store, for example, blockchain data defining a distributed ledger for injection event transactions, which stores records of injection event transactions (e.g., data defining injection events where an injection has been authorized and / or administered to a specific patient, and the injection provider has provided data indicating that a specific fluid medication has been administered to a specific patient, including accompanying details such as the time / date, location, fluid medication, and / or injection provider corresponding to the injection), chaincode instructions, and data causing communication with management device 106 (e.g., to an API and / or API tunnel to a web service providing blockchain authentication, proof, and / or cryptographic hashes). In some embodiments, storage devices 140-1a-n and 140-2 may include any type, configuration, and / or number of data storage devices that are or become known or feasible. Storage devices 140-1a-n, 140-2 may include, for example, optical and / or solid-state hard disk drive arrays configured to store injection event transaction ledger data, syringe and / or injection event analysis data (e.g., analysis formulas and / or mathematical models), and / or various operational instructions, drives, etc., provided (and / or requested) by node devices 102a-n. While storage devices 140-1a-n, 140-2 are described as separate components of the various node devices 102a-n and server 110, storage devices 140-1a-n, 140-2 may include multiple components. In some embodiments, multi-component storage devices 140-1a-n, 140-2 may be distributed across various devices and / or may include remotely distributed components. For example, any or all of node devices 102a-n, management device 106, and / or server device 110 may include storage devices 140-1a-n, 140-2, or a portion thereof.

[0040] Now go to Figure 2 The diagram illustrates a block diagram of an injection management system 200, which may be a component of the injection management service described herein. In one embodiment, the injection management system 200 may include a server device 110. Figure 1 Examples of injection management systems 200 include, for example, a processor 201, a memory 203, a database 202, and multiple software modules 222-226.

[0041] According to some embodiments, any or all components of the injection management system 200 may include one or more hardware components, such as a microprocessor, microcontroller, or digital sequential logic, such as processor 201. Processor 201 may include one or more processors that operate sequentially or in parallel, such as one or more Intel™ processors. Processor 201 communicates with or is operatively connected to memory 203. Memory 203 may include a suitable combination of magnetic, optical, and / or semiconductor memories, and may include, for example, random access memory (RAM), read-only memory (ROM), optical disk, and / or hard disk. Processor 201 and memory 203 may, for example, be located entirely within a single computer or other device; or (ii) interconnected via a remote communication medium such as a serial port cable, telephone line, or radio frequency transceiver. In one embodiment, system 200 may include one or more devices connected to a remote server computer for maintaining a database or injection event transaction record (e.g., Figure 1 (Management equipment 106).

[0042] System 200 may also include database 202, which in some embodiments may store data for implementing one or more embodiments described herein. Non-limiting examples of database 202 include (i) data associated with one or more users (e.g., patients receiving injections and / or injection providers), (ii) data associated with one or more pharmaceutical companies whose drugs are packaged in syringes, (iii) data associated with syringes that include a data storage mechanism for storing unique identifiers, (iv) data associated with one or more injection events or injection event transactions, and (v) data associated with one or more rewards that patients receive (or are receiving) in an injection compliance program, as described herein.

[0043] According to some embodiments, database 202 includes data, associated data structures, and database management software. Database 202 can be implemented, for example, using any well-known database management system, including Microsoft SQL, Oracle, IBM DB2, etc. It should be noted that in some embodiments, database 202 (or at least some of the data described as being stored therein) can be stored in memory 203 and / or another storage device accessible to memory 203 and / or processor 201. For example, in one embodiment, database 202 (or at least some of the data described as being stored therein) can be stored in the memory of a third-party server, such as a server for a cloud-based computing service, with which the injection management service may contract for data storage.

[0044] In some embodiments, data described herein as stored in database 202 may be stored across more than one database; for simplicity only, example data useful in at least some embodiments is described herein as being stored in a single database 202. According to some embodiments, one or more types of data 204-212 may be stored in separate databases.

[0045] An example of one type of data that can be stored in database 202 includes syringe data 204, which defines a uniquely identifiable syringe (and, in the case of a pre-filled syringe, the dosage of the fluid agent packaged therein) that is identified by the system (e.g., a syringe registered in the system for the purpose of being tracked, managed and / or authorized). Such syringe data may include at least one of the following: (i) a unique serial number of the syringe (in some embodiments, this may include a unique serial number of an NFC or other chip attached to or otherwise associated with the syringe); (ii) the batch number of the fluid agent contained in the syringe; (iii) a batch identifier of the manufacturer of the fluid agent; (iv) the manufacturing time and / or location of the fluid agent and / or syringe; (v) the type, variety, and / or name of the fluid agent packaged within the syringe; (vi) the expiration date of the fluid agent, if any; (vii) a strip ID number (e.g., if the syringe is manufactured and sold as a strip of multiple syringes); (viii) the dosage or strength of the fluid agent; (ix) the intended destination or recipient (e.g., children versus adults); (x) one or more characteristics of the syringe (e.g., it is a 1.5 ml BFS vial); and / or (xi) other information required to identify or track the unique ID syringe and / or the fluid agent contained therein (e.g., recall alerts). In some embodiments, the unique serial number may be a unique identifier pointing to other data (e.g., at least some of the information indicated in items (ii)-(x) of the foregoing list). In some embodiments, syringe data 204 may be used as part of the injection authorization process (e.g., to confirm that the syringe is not counterfeit, that the dose contained therein has not been recalled, etc.).

[0046] According to at least some of the embodiments described herein, another example of a type of data that can be stored in database 202 includes patient data 206, which defines individuals who have registered with the injection management system 200 (e.g., individuals who have downloaded the injection management application to track their injection events (e.g., tracking the vaccines they have received and their vaccination status for various infectious diseases)). In each corresponding patient record of patient data 206, such patient data 206 may include at least one of the following: (i) name; (ii) contact data; (iii) a unique identifier (e.g., assigned by the injection management system or a third-party organization cooperating with the injection management system to help manage the injection event information of individuals within that organization); (iv) login credentials (e.g., a username and password by which the patient can log in to the patient portal of the injection management application); (v) health history; and (vi) injection event status or vaccination status for various infectious diseases that the patient has received (or has not received).

[0047] In some embodiments, the injection management system may allow different levels of privacy to be associated with a given digital receipt for an injection event transaction or vaccination. For example, a first version or level of such a digital receipt may allow the patient to remain anonymous while sharing that version of the digital receipt with a third party to confirm his / her vaccination status for a specific infectious disease. This version or privacy level of the digital receipt may indicate, for example, the patient's vaccination status and some information about the vaccination (e.g., the time / date and / or location of the vaccination) without providing the patient's personally identifiable information (PII). A second version or level of the digital receipt may include the patient's PII. In such embodiments, different permission requirements may correspond to different privacy levels of the digital receipt (e.g., the patient / user may need to provide an additional password or participate in two-factor authentication to confirm that the second level of the digital receipt (including the PII) will be shared with a third party). In such embodiments, the different levels of the digital receipt (and, for example, the different information to be shared with a third party at each level) and the corresponding permission requirements for each level may also be stored for the patient in the patient record of patient data 206.

[0048] In some embodiments, data defining the digital receipt for the injection event may be stored in patient data 206, while in other embodiments, the identifier of the digital receipt may be stored in patient data 206, pointing to another location where the digital receipt is stored (e.g., in injection event data 210 or in another database or ledger where the digital receipt is stored separately from patient data 206 and injection event data 210).

[0049] Another example of data types that can be stored in database 202 includes injection provider data 208, which defines an individual registered as an injection provider in injection management system 200. For each patient provider record, this injection provider data may include at least one of the following: (i) name; (ii) contact data; (iii) a unique identifier (e.g., assigned by the injection management system or a third party working with the injection management system to assist in administering injections to patients via syringes registered in the injection management system); and (iv) login credentials (e.g., a username and password by which the patient can log in to the injection provider portal of the injection management application). In some cases, a given individual can register as both a patient and an injection provider in the injection management system, in which case the individual needs to log in to the appropriate portal or platform (patient or injection provider) depending on the reason for login.

[0050] Another example of data that can be stored in database 202 is injection event data 210, which defines a list of injection events or injection event transactions that have been identified and recorded by the injection management system 200. In some embodiments, the injection event database may include, as referred to Figure 1 The embodiment of the injection event transaction ledger may refer to some or all of the same data as the data stored in the ledger. According to some embodiments, each record of the injection event data 210 may store information defining the specific injection event that is identified and recorded (e.g., based on, for example, information about...). Figure 4 The method described in method 400). Examples of data that can be recorded in injection event data 210 include: (i) the date / time of the injection (it should be noted that the terms “date,” “time,” and “date / time” are used interchangeably herein to refer to the date and / or time of the event); (ii) the location where the injection was performed (e.g., based on information provided by the injection provider and / or patient, whether affirmatively or passively based on GPS or geolocation information obtained from a mobile device, or both); (iii) the instruction or identifier of the injection provider who performed the injection; (iv) the identifier of the patient who received the injection; (v) the instruction for the injection (e.g., the instruction for the dose and / or fluid medication administered, the name of the medication, batch or lot number, etc.); (vi) the expiration date of the injection (if any); (vii) the unique identifier of the syringe used in the injection event; (viii) the unique identifier of the transaction (if different from the syringe identifier), which may be generated by the injection management system 200 when a new record of injection event data 210 is opened; (ix) once the administration of the injection has been confirmed (e.g., according to...). Figure 4(x) the generated verification code (which may expire); (x) the expiration time of the verification code and / or an indication that the verification code was received from the patient before the expiration time; (xi) the injection status corresponding to the injection event (e.g., if the injection is for a vaccine that is effective within a predetermined time period, statistics may indicate whether the injection is currently considered valid / active versus expired); and (x) the digital receipt or digital receipt identifier corresponding to the injection event. In some embodiments, data defining the digital receipt for the injection event may be stored in the injection event data, while in other embodiments, the identifier of the digital receipt may be stored in the injection event data 210, pointing to another location where the digital receipt is stored (e.g., in patient data 206 or in another database or ledger where the digital receipts are stored separately from patient data 206 and injection event data 210).

[0051] Another example of data that can be stored in database 202 is fluid medication data 212. Fluid medication data 212 may include data about various fluid medications packaged in syringes managed by injection management system 200. In some embodiments, when administering a fluid medication to a patient, the injection provider is able to look up information about a specific fluid medication in fluid medication data 212. In other embodiments, fluid medication data 212 may be used as part of the injection authorization process. Examples of information about fluid medications that may be stored in fluid medication data 212 include, but are not limited to: (i) the disease or condition or the name of the fluid medication for treatment / prevention; (ii) the manufacturer of the fluid medication; (iii) the ingredients contained in the fluid medication (e.g., for allergy or compatibility purposes); (iv) the distributor or contract manufacturer that produces the fluid medication; and (v) contact information for a pharmaceutical company or other representative who can provide additional information about the fluid medication or for submitting concerns, complaints, questions, or issues related to the fluid medication.

[0052] It should be noted that the examples provided in this article regarding which types of information can be included in which types of sample data should not be considered restrictive. Modifications can be made regarding which types of information are stored with which types of data, different types of data can be combined, some information can be stored with more than one type of data, and so on.

[0053] The injection management system 200 may also include one or more software modules or engines for directing the processor 201 to perform certain functions. According to some embodiments, software components, applications, routines or subroutines, or instruction sets used to cause one or more processors to perform certain functions may be referred to herein as “modules” or “engines.” It should be noted that such modules, engines, or any other software or computer programs mentioned herein (including injection management applications that can be downloaded to a user’s mobile device for communication with the injection management service, such as via the injection management server 200) can be written in any computer language and may be part of a monolithic codebase or developed as more discrete code segments, such as typical object-oriented computer languages. Furthermore, in some embodiments, the modules, engines, or any software or computer programs mentioned herein may be distributed across multiple computer platforms, servers, terminals, etc. For example, a given module may be implemented such that the described functions are executed by a separate processor and / or computing hardware platform.

[0054] refer to Figure 2 It should be understood that any software module or computer program shown herein may be part of a single program or integrated into various programs for controlling processor 201. Furthermore, any software module or computer program shown herein may be stored in a compressed, uncompiled, and / or encrypted format and includes instructions that, when executed by processor 201, cause processor 201 to operate according to at least some of the methods described herein. Of course, additional and / or different software modules or computer programs may be included, and it should be understood that regarding… Figure 2 The example software modules shown and described are not required in any embodiment. The use of the terms "module" or "engine" does not imply that the functionality described with reference to them is embodied as a standalone or independently operating program or application. While in some embodiments the functionality described with reference to a particular module may operate independently, in other embodiments, such functionality is described with reference to a particular module merely for ease of description or convenience, and such functionality may actually be integrated into another module, program, application, or part of the instruction set of a processor used to direct a computing device.

[0055] According to one embodiment, reference Figure 2Any or all of the instructions of the described software module, engine, or program may be read into main memory from another computer-readable medium, such as from ROM to RAM. Execution of the sequence of instructions in the software module, engine, or program causes processor 201 to perform at least some of the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions to implement the processes of the embodiments described herein. Therefore, the embodiments described herein are not limited to any particular combination of hardware and software. Some non-limiting examples of software modules that may be used in system 200 include: (i) injection management engine 220; (ii) authorization module 222; (iii) injection event transaction log module 224; and (iv) injection status module 226.

[0056] exist Figure 2 In the example embodiment shown, the injection management engine is shown to communicate with (i) the authorization module 222; (ii) the injection event transaction log module 224; (iii) the injection status module 226; and (iv) the database 202. Therefore, the injection management engine can operatively access data in the database 202 and perform some of the functions and embodiments described herein, either by itself or by providing such data to one or more modules 222-226. This arrangement is shown as an example of how data in the database 202 can be accessed, modified, and utilized.

[0057] Generally, injection management engines 220 and modules 222-226 should be understood as accessible to processor 201, regardless of their specific arrangement within system 200, to implement one or more embodiments described herein. As described above, one or more of engines 220 and modules 222-226 can be used to utilize at least some data stored in database 202. Furthermore, according to some embodiments, one or more of engines 220 and modules 222-226 can be used to retrieve, manipulate, select, update, modify, and / or determine data transferred to and stored in database 202.

[0058] According to some embodiments, the injection management engine 220 may be operable to manipulate data from the database 202 to perform or facilitate one of the following example functions: (i) authorizing injections from a uniquely identifiable syringe (e.g., based on a mobile device via the injection provider (e.g., Figure 1 (ii) receiving information from the injection provider through the injection provider portal of the injection management application on the node device 102a-n); (iii) storing records of each injection or dose of fluid medication administered by the injection provider using the injection management system 200; and (iv) generating digital receipts or other indications that an injection has been given to a specific patient, to be transmitted via the patient's mobile device (e.g., Figure 1(iv) The node device 102a-n) outputs to the patient; and allows patients who have received an injection or dose of a fluid agent managed by the injection management system 200 to provide verification of the injection or dose received in an effective, electronic, safe and verifiable manner.

[0059] According to one embodiment, the injection management engine 220 or another component of the system 200 is operable to output information to a user, such as a patient or injection provider registered with the system 200, via one or more graphical user interfaces (GUIs) of an injection management application as described herein (and receive input or data from such users, such as syringe identifiers, information confirming that an injection has been successfully administered, or verification codes confirming that an injection has been successfully administered). This document references... Figure 3A-3L An example of this GUI is described. This article references... Figure 4 Examples of processes are described, through which information can be received from or output to users such as injection providers and patients.

[0060] The interface of an injection administration application can, for example, take the form of a web server that uses well-known transport protocols, such as HTTP and TCP / IP, to transmit data in HTML, XML, or other well-known formats. Proprietary protocols and data formats can also be used. Figure 3A-3L Non-limiting examples are shown of the types of information that an injection management application, which is operable to interface with the injection management system 200, can output to the user and the mechanisms by which it can collect information from the user.

[0061] Now go to Figure 3A-3L and Figure 4 , Figure 4 Example process 400 is shown, which provides one embodiment of some of the functionalities of the injection management system described herein, referenced in [reference]. Figure 3A-3L For example, a GUI can be used in this process. Process 400 can be, for example, controlled by an injection management system 200 ( Figure 2 ) to be executed. In some embodiments, process 400 may be executed by one or more dedicated and / or specially programmed computers (e.g., Figure 2 The processor 201 is used to execute and / or implement, and / or otherwise associate with one or more dedicated and / or specially programmed computers. It should be noted that, with respect to process 400 and all other processes described herein, not all steps described with respect to that process are necessary in all embodiments, these steps may be performed in a different order in some embodiments, and additional or alternative steps may be utilized in some embodiments.

[0062] For reference here Figure 3A-3LThe description process 400 shows several example GUIs (in no limited way) that can be presented to the user (in some cases the injection provider, in some cases the patient, as described herein) during the progress of an injection event transaction. Figure 3A-3L Each displays a corresponding GUI that can be output on the corresponding user's mobile device (which may include...) Figure 1 Examples of node devices 102a-102n). Figure 3A-3L A graphical user interface (GUI) can include an application (a software application operable to run on a mobile device) or a specific version thereof, several tabs, screens, or pages of a portal or platform (e.g., some screens are output from the injection provider portal when a user logs in as an injection provider, while other screens are output from the patient portal when a user logs in as a patient). It should be noted that many variations of this graphical user interface can be implemented (e.g., menus and layouts of elements can be modified, and additional graphics and functionality can be added). Figure 3A-3L The graphical user interface is presented in a simplified form to focus on the specific embodiments and features described.

[0063] Now go to Figure 3A The diagram illustrates a GUI 300A, which can be output via a mobile device to a user who has an injection management application installed on their mobile device. This could be a login screen presented to the user each time the injection management application is launched or opened. According to one embodiment, the application may include different portals / platforms for different types of users (e.g., patients and injection providers). In such an embodiment, the user may first be prompted to choose whether he / she is logged in as an injection provider (in which case the user will select the option depicted by area 302a of GUI 300A) or as a patient (in which case the user will select the option depicted by area 302b of GUI 300A). In other embodiments, different applications can be available for different users, such that a given user can only launch the application corresponding to his / her role (e.g., an injection provider can access the first application, while a patient can access the second application, eliminating the need to select the user type on the launch screen). For the purposes of description... Figure 3A-3L The purpose of the described embodiments is to assume that the user as the injection provider and the user as the patient have previously registered with the injection management system 200 and are therefore identified by the injection management system (e.g., in...). Figure 2 The example system 200 stores data corresponding to the patient data 206 and / or injection provider data 208, and has login credentials recognized by the system 200 (those skilled in the art will understand that such users can register with the system through a registration process, which will not be described here for the sake of brevity).

[0064] Now go to Figure 3B The document illustrates an example GUI300B that can be presented to a user acting as an injection provider (as shown in area 304a of GUI300B). To continue using the injection management application and access the functionality of the injection management service as described herein, the user provides his / her username and password, or other credentials required by the injection management service. In some embodiments, the username may be a unique identifier assigned to the user (e.g., by the injection management service or a third-party organization that works with the injection management service to help its members or participants manage their injection events). In some embodiments, additional security measures may be incorporated to verify the identity of the user logged into the injection management application (e.g., two-factor authentication).

[0065] Now go to Figure 3C The example GUI 300C is shown, which can be output to an injection provider to indicate the progress of an injection event transaction (and the current state of the process). An injection event can be considered an event in which a patient receives an injection (a dose of fluid medication) (e.g., an event in which a patient receives a dose of a specific vaccine). An injection event transaction is an activity involving the patient receiving the injection and the injection management service (or the injection provider, acting as a representative of the injection management service), in which the patient receives the injection and their digital receipt, in exchange for information provided that allows the injection management service to track and store records of patients who have received injections (e.g., a unique identifier that allows system 200 to identify the patient and a verification code that allows the system to confirm that the patient has been administered a specific dose of fluid medication to him / her via a unique ID syringe, as described herein). According to the embodiments described herein, the record transaction allows the patient and the injection management system to subsequently access and verify the occurrence of the injection event in an efficient and secure manner.

[0066] like Figure 3C As shown, according to some embodiments, the process of an injection event transaction may include (i) the injection of a registered dose of fluid agent (referred to as "registration inoculation") and step 1 in region 306a, assuming Figure 3A-3L (i) the example of a fluid medication being a vaccine; (ii) receiving confirmation from the patient that the fluid medication has been administered to the patient (referred to as “Patient Confirmation” and step 2 in Area 306a); and (iii) storing a verifiable record of the injection event (referred to as “Record Verification” and step 3 in Area 306a). Reference Figure 4 The description of process 400 here provides some example ways to implement each step of this process.

[0067] According to some embodiments, as each step of the exemplary process is completed, the injection provider's application will display an indication that the step has been successfully completed (e.g., via a check mark or other visual aid). Although a specific example screen of the GUI 300C shows a check mark next to each step, it can be assumed that a step will be indicated as incomplete until it is confirmed (e.g., without a check mark, by being displayed in gray, or by some other visual aid).

[0068] Now go to Figure 4 When the system (e.g., injection management system 200) recognizes the start of injection event processing, process 400 begins at box 402, which includes receiving a syringe identifier. In some embodiments, a patient identifier or other patient registration process may precede box 402 (e.g., the injection provider or its collaborators may first process the patient via a standard appointment registration process before the injection event actually begins).

[0069] The initiation of an injection event transaction can be identified, for example, based on a unique syringe identifier received from the injection provider via an injection management application. Figure 3D The GUI300D illustrates an example of a GUI or interface through which the injection provider can transmit or provide a unique syringe identifier. As described herein, each syringe managed by the injection management service may be equipped with or correspond to a data storage mechanism, such as an NFC chip, RFID chip, QR code, barcode, or other mechanism, through which sensors of the mobile device for the injection management application are installed, and this data storage mechanism can store a unique identifier that uniquely identifies the syringe. Figure 3D In the illustrated embodiment, the data storage device is an NFC chip, thus prompting the injection provider to enter a unique identifier for the syringe to be used, either by bringing the syringe close to the provider's mobile device or by tapping the syringe (or a specific part of the syringe, such as the tag area where the NFC chip is located) onto the mobile device to administer an injection. In embodiments where the data storage device includes something other than an NFC chip, the user may be prompted to enter the unique syringe identifier in different ways. For example, the user may be prompted to scan a QR code or barcode on the syringe, or to hold the syringe, which includes an RFID chip, near an RFID antenna operable to read information from the RFID chip (which in turn can communicate with the provider's mobile device and / or the injection management system to transmit the syringe's unique identifier and allow injection event transactions to proceed).

[0070] Once the injection event processing is initiated and a unique syringe identifier is received in box 404, the syringe identifier is verified (e.g., as genuine) and the corresponding syringe is authorized for use. For example, information associated with the syringe identifier can be retrieved, and an authorization process can be performed (e.g., confirming that the syringe is not expired, has not been used, has not been recalled, and / or is not authorized for use). According to some embodiments, the functionality described for box 404 can be at least partially handled by the authorization module 222 ( Figure 2 ) to execute.

[0071] In one embodiment, once the syringe identifier is received in box 404, it is used to access data associated with the syringe (as referenced). Figure 2 (As described). For example, the injection management system 200 can access records of syringe data 204, and a program or module (e.g., authorization module 222) can check one or more fields to confirm that there is no existing condition that would prevent the syringe from being authorized for use by the injection provider (e.g., the syringe has not been recalled; the syringe is trustworthy, and if the syringe identifier is found in the syringe data, it can be assumed to be trustworthy). In some embodiments, as part of the syringe authorization process, the injection management system can output information about the syringe and / or the fluid medication packaged in the syringe to the injection provider via a GUI (not shown). For example, the injection provider may be prompted to confirm that certain information printed or imprinted on the syringe or its label matches information stored in a database associated with the syringe identifier provided by the injection provider.

[0072] According to some embodiments, additional information or considerations may be involved in verifying the syringe identifier and whether the syringe should be authorized for use (i.e., block 404 may include additional steps and / or authorization module 222 may perform additional verification). For example, in some embodiments, BFS vials or other types of syringes may include a vaccine vial monitor (VVM) that may include an environmental monitoring device (e.g., a strip attached to the syringe). According to some embodiments, the VVM includes a thermochromic label placed on the vial containing the vaccine or other fluid agent, which provides a visual indication of whether the vaccine or other fluid agent has been maintained within the temperature range that maintains its efficacy. The label is designed to address the problem of shipping vaccines to countries where environmental characteristics (e.g., vaccine storage temperatures) are difficult to maintain and track, and where previous vaccines have degenerated due to exposure to inappropriate temperatures (e.g., temperatures too cold for the vaccine), becoming inactive and ineffective for administration. In some embodiments, the VVM may include a measurement of the cumulative amount of heat or cold that the vial to which it is attached has been exposed to since leaving the manufacturing plant. If a vial is exposed to an unacceptable temperature for an unacceptable period of time, the label will turn black. A black label indicates that the vaccine or other fluid medication inside the vial is no longer effective and should not be administered. In other embodiments, a more expensive digital VVM can be used to track similar ambient temperature information.

[0073] Depending on some embodiments where the syringe may include a VVM, the syringe's NFC chip or other components may include an optical chip monitor that allows reading the VVM's output (e.g., whether the VVM tag turns black). For example, a user could open an appropriate injection management app on their mobile device and tap the vial, which includes the NFC chip and / or optical chip monitor, against their mobile device (keeping their mobile device (or its camera) on the VVM), allowing the app to read an indication based on the VVM output whether the vaccine is good and usable. In another example, a user could open an appropriate injection management app on their mobile device, take a picture of the VVM output, and program the app (or a server including a processor operable to implement appropriate procedures, with which the app communicates) to determine whether the fluid medication in the vial is usable based on the VVM output. In either example, if the injection management app determines the fluid medication is usable based on the VVM output, it can output an indication to the user that the user is authorized to administer the fluid medication (e.g., a green button, light, or other indicator may appear on the injection management app's screen), as described above regarding the authorization of syringe use and providing such authorization to the injection provider. In one example, the applicant envisions a simple optical monitor included within a vial and operable to communicate with or monitor the VVM's status, such that if the VVM tag (or an indicator of the digital VVM) turns black (or otherwise indicates that the fluid medication has been exposed to unacceptable temperatures), a signal is generated or it is determined that the fluid medication is no longer feasible or authorized for use. The optical monitor is then operable to transmit this indication to an NFC chip and / or an injection management application, enabling the NFC chip and / or the injection management application to determine that the fluid medication in the vial should not be authorized for injection into a patient.

[0074] Once the syringe has been verified by the injection management system to confirm that the syringe identifier is authentic and that no other known information would lead to the syringe being used without authorization, the syringe can be considered registered or verified. This may include, for example, generating records of injection event transactions (e.g., in the database of the injection management system 200, e.g., in...) Figure 2 (In the injection event data 210) open a new record for the current injection event transaction, and / or generate a unique transaction identifier for the injection event transaction. Furthermore, once the syringe is certified and authorized for use, Figure 3CStep 1 of the process shown can be considered complete, and a visual indication of this can be output to the injection provider via GUI 300C (e.g., a checkmark can be output next to step 1, or step 2 can be highlighted or activated). In some embodiments, additional visual, auditory, and / or tactile indications can be output to the injection provider to indicate that the syringe has been authorized for use and that the injection provider should continue administering the injection to the patient (e.g., symbols or other visual indications (e.g., checkmarks, green lights, or thumbs-up or full circles), sounds, or vibrations can be output via the GUI of the injection management application).

[0075] If the syringe identifier is not successfully verified or the injection management system 200 determines that the injection is not authorized, an error, warning, or other message indicating that the authorization injection failed can be output to the injection provider via the GUI of the injection management application. For example, the injection provider may receive an indication that a syringe has been recalled (in which case the injection provider may try to verify a different syringe and discard the rejected syringe) or an indication that the syringe identifier was not read (in which case the injection provider may try tapping the syringe on the mobile device again, scanning the QR or other code again, or otherwise try to enter the syringe identifier again, such as manually typing the human-readable code of the syringe).

[0076] Assuming the injection identifier is successfully verified in box 404 and the injection of the encapsulated fluid medication therein is authorized, the system waits for the injection provider to provide an indication that the dose of the fluid medication corresponding to the syringe identified in box 402 has been administered to the patient. It should be noted that in some embodiments, at this point in the process, the system may not yet have identified the patient to whom the injection is to be administered, while in other embodiments, a patient identifier may have already been provided for the injection event transaction record (e.g., provided by the injection provider or by the patient). Once the system has received confirmation (e.g., from the injection provider) that the injection has been successfully administered to the patient (box 406), a unique verification code is generated and output to the injection provider via the GUI of the injection management application (box 408). An example of such a verification code output to the injection provider is shown in the example of GUI 300E. Figure 3E Although area 310a of the GUI300E displays a six-digit CAPTCHA, any length or type of CAPTCHA can be used.

[0077] A verification code generated by the system (either locally generated by a module of the injection management application or remotely generated by a server device such as server device 110, with the user's mobile device communicating with the server device 110 via the injection management application) is transmitted to the patient who has received the injection. This allows the patient to use the verification code to verify their presence in the injection event and further provides the data to the injection management system as part of the injection event transaction. In some embodiments, the injection provider may show or read the verification code aloud to the patient as output on the injection provider's mobile device. In some embodiments, the verification code may be output in the form of a QR code or other mechanism directly readable by the patient's mobile device.

[0078] In some embodiments, the verification code may correspond to an expiration time, making it valid only before that time. In some embodiments, if the patient needs more time to receive and use the verification code, a new verification code may be generated based on a request from the injection provider. In some embodiments, the generated verification code is stored in association with the injection event transaction (e.g., in injection event data 210 and / or the injection event transaction ledger, if different). In some embodiments, the generated verification code may be sent to a device other than the injection provider's mobile device. For example, in some embodiments, the verification code may be sent directly to the patient (e.g., via SMS) based on previously stored contact information associated with a patient identifier provided earlier in the process of the injection event. In another example, the verification code may be sent to another server device (e.g., Figure 1 (Management equipment 106).

[0079] Once the verification code is generated in box 408, Figure 3C Step 2 of the process shown can be considered complete, and visual or other indications of completion can be output to the injection provider via the injection provider portal of the injection management application (e.g., the GUI300E can be updated to indicate the completion of step 2). Once the verification code is output, the system waits for the patient to enter the verification code.

[0080] According to some embodiments, upon arrival at an appointment for an injection event, the patient can log in to the patient portal of the injection management application (e.g., by selecting the "Patient" option in area 302b of GUI 300A and then entering the appropriate login credentials in area 304b of GUI 300B). Upon logging into the injection management application (and, in some embodiments, after selecting the appropriate "Injection Confirmation" option of the application), the patient may be prompted to enter a verification code provided by the injection provider after the injection is administered. Example GUI 300F ( Figure 3FThe diagram illustrates an example interface through which a patient is prompted to enter a verification code. The patient can confirm receipt of the injection by providing the verification code in area 312a of the GUI 300F. In some embodiments, the patient may also be prompted to provide additional information related to the injection event (e.g., confirmation time / date, injection location, and / or the fluid medication administered to the patient). Once the verification code (and any other confirmation information or input) is received from the patient (box 410), the system can record a successful injection event as completed (box 412).

[0081] In some embodiments, additional steps or input may be required from the injection provider for the system to recognize the injection event as verified and to determine that the injection event transaction has been successfully verified and / or completed. For example, in some embodiments, after receiving a verification code from the patient's device, the injection provider (via the injection provider app on the injection provider's mobile device) may be prompted to re-enter his / her password to confirm his / her identity and "sign" when the injection has been successfully completed. Figure 3H An example GUI 300H is shown, in which the injection provider is prompted to enter a password or other credentials via area 316a to verify the injection. According to some embodiments, the password or other credentials entered by the injection provider can serve as a digital "signature" of the injection event record by the injection provider. Other methods for allowing the injection provider to "sign" the injection event record may include having the injection provider enter a code via a token or NFC chip on an item provided to the injection provider for this purpose (e.g., an NFC chip or other entity of such an item can operatively transmit a unique identifier to the injection management application to confirm the injection provider's presence and identity). In some embodiments, such a token or other item can also be used by the injection provider to log in to the injection provider portal of the injection management application.

[0082] After receiving the verification code from the patient, receiving successful confirmation or verification of the injection record from the injection provider can be used to satisfy step 3 of the injection management application process, as shown in example GUI 300C. In some embodiments, the injection provider may be further prompted to confirm the successful completion of the injection event by selecting a "save" or similar option via the injection management application, such as... Figure 3I As shown in area 318a of the example GUI 300I. The injection provider is allowed to definitively “save” the injection event and indicate it as complete. Furthermore, the injection provider can check and confirm additional information about the injection event that the system has already collected, for use in the injection event transaction record, by outputting other information about the injection event that the system has already collected to the injection event provider (e.g., also as shown in the example GUI 300I).

[0083] In some embodiments, the system may also confirm the verification code entered by the patient into the patient portal of the injection management application by determining (i) that the verification code received from the patient in box 410 matches the verification code output to the injection provider in box 412; and (i) that the verification code was received before its expiration time. While the system is verifying the verification code entered by the patient (and in some embodiments, awaiting input from the injection provider as a “signature” for the injection event record), the patient’s injection management application may output an indication of a pending verification status (e.g., as shown in the image). Figure 3G (As shown in area 314b of the example GUI300G). Once the verification process has been completed (e.g., based on data provided by the injection provider to sign the injection event (e.g., providing a password or other code or input to confirm the identity of the injection provider), and in some embodiments, additionally indicating that the injection event is complete), the patient's injection management application can output an updated status of the injection event or injection (e.g., a "vaccinated" status if the injection is a vaccine, and the name of the vaccine and / or the infectious disease for which the patient has been vaccinated). Figure 3J The example GUI300J shows one way to output this updated status to the patient.

[0084] It should be noted that some or all of the functions described in boxes 402-412 herein can be provided by the authorization module 222 ( Figure 2 ) and / or inject event transaction log module 224 ( Figure 2 For example, the injection event transaction log module 224 can be used to update or send updates about injection event transactions to another device (e.g., node devices 102a-n and / or management device 106) so that the device can update its injection event transaction records, while the authorization module 222 can be used to perform functions that allow confirmation or verification of such updates / data.

[0085] In some embodiments, receiving a verification code from the patient in box 412 can also be used to identify and / or confirm the identity of the patient participating in the injection event transaction. For example, in some embodiments, the verification code received from the patient via the patient portal of the injection management application can be received in a data packet that also includes an indication of the patient's unique identifier (e.g., received as a result of the patient logging into the patient portal of the injection management application to enter a verification code, which can then be provided to the system via the application, and as shown in area 314a of GUI 300G). The system can identify the patient and add the indication of the patient's identifier to the injection event transaction record of the transaction by matching the verification code received from the patient with the verification code generated and output to the injection provider as part of the open injection event transaction. In some embodiments, updating the injection event transaction record with the patient's identifier can be done as part of the process in box 412.

[0086] In some embodiments, once an injection event is completed and the transaction is considered successfully recorded (box 412) in one or more records, additional data in the form of a digital receipt for the injection event can be generated and transmitted to the patient's mobile device (step 414). In some embodiments, it is this transmission of data / digital receipt that allows the patient portal of the injection management application to display a "vaccinated" or similar status to indicate that the patient has received an injection of the corresponding fluid medication. In some embodiments, the digital receipt may include data such as the effective date or expiry date of the injection. For example, in some cases, an injection is considered valid until a certain period of time after the patient receives the injection (e.g., two (2) weeks). In another example, an injection may only be valid for a period of time (e.g., one (1) year). In this case, the digital receipt can be automated for this data because the status of the injection or the patient regarding the injection (e.g., the patient's vaccination status for a specific vaccine) can be automatically updated in the injection management application based on a comparison of the current time with the effective time and / or expiry time of the injection. For example, if the injection is only valid for one (1) year after the patient receives the injection, the status of the injection may show as "expired" or similar when the patient logs into the patient portal of the injection management application after the effective time. Figure 3L The GUI300L shows an example of this state and how to display a specific vaccine.

[0087] As described herein, in some embodiments, the injection management system may allow different levels of privacy to be associated with a given digital receipt for an injection event transaction or vaccination. For example, a first version or level of such a digital receipt may allow the patient to remain anonymous while sharing that version of the digital receipt with a third party to confirm his / her vaccination status for a specific infectious disease. This version or privacy level of the digital receipt may indicate, for example, the patient's vaccination status and some information about the vaccination (e.g., the time / date and / or location of the vaccination) without providing the patient's personally identifiable information (PII). A second version or level of the digital receipt may include the patient's PII. In such embodiments, different permission requirements may correspond to different privacy levels of the digital receipt (e.g., the patient / user may need to provide an additional password or participate in two-factor authentication to confirm that the second level of the digital receipt (including the PII) will be shared with a third party). In such embodiments, the different levels of the digital receipt (and, for example, the different information to be shared with a third party at each level) and the corresponding permission requirements for each level may also be stored for the patient in the patient record of patient data 206. In some embodiments, public-private key encryption may be employed to allow the patient to control the release of certain private information associated with the digital receipt for the injection.

[0088] In some embodiments, the injection management system may output codes (e.g., QR codes) or other means through which patients can share or "flip" verification that they have currently received a vaccine against a specific infectious disease or a specific fluid medication. Injection Status Module 226 ( Figure 2 It can be used to (i) track and update a patient’s status regarding a specific fluid medication injection; and (ii) generate a code or license by which a patient can share his / her injection status with a third party (e.g., accept a permission request from the patient or decrypt a password and publish a digital receipt or certain levels or data of a digital receipt to an authorized third party).

[0089] In some embodiments, the injection management system 200 may request additional information or data from the injection provider during the injection event before considering the completion and verification of the injection event transaction. In one exemplary embodiment, the system may prompt the injection provider to take a photo or video of the patient receiving the injection and upload it as part of the injection event confirmation process (e.g., in box 406) or before considering the successfully recorded injection event transaction (e.g., in box 412). The example in Figure 300K illustrates one implementation of this embodiment. In this example, the GUI 300K-1 of the injection provider portal prompts the injection provider to upload visual confirmation of the patient's presence and image via area 320a, and GUI 300K-2 shows the visual confirmation that has been uploaded as part of the patient confirmation process in area 322a.

[0090] In some embodiments, in addition to the injection provider, a regulator or other second person may be required to confirm the injection event before it is completed. Figure 3K The example embodiments shown also illustrate how such embodiments can be implemented by providing an input mechanism for supervisor approval (as part of step 3 in area 322b of GUI300K-1 and GUI300K-2).

[0091] In some embodiments, the NFC or RFID chip may be a read-only chip, while in other embodiments it may be a writable chip to which information can be added. In some embodiments, the NFC or RFID chip may be a passive chip, such that it does not have its own power supply and can be powered by a reader device (e.g., a user's mobile phone) or other mechanisms external to the NFC chip.

[0092] In embodiments where the NFC or RFID chip is a writable chip (and perhaps others), a power supply or power source for the chip may be required. In one embodiment, the power supply or power source may be included in a syringe. In one embodiment, the power source may be embedded in a BFS tube (e.g., a capacitor may be embedded in the BFS tube as part of the extrusion process). Other examples of power sources or power supplies that can be used to power NFC or RFID chips include, but are not limited to: (i) energy generated by a user squeezing or pressing the BFS vial to inject a fluid medication within the vial; (ii) energy generated by a user shaking the BFS tube; (iii) power from a light source or solar energy on / within the BFS vial; (iv) power utilizing piezoelectric effects and / or materials; and (v) power from external light, either natural sunlight or by keeping the device under a bright light source (e.g., in a plastic tube embodiment, the plastic of the tube may embed solar conversion chemicals or materials, where placing the tube in light provides a very low microvolt trickle charge for the associated battery or capacitor). It should be understood that in many embodiments, the amount of power required by many of the embodiments described herein (if the NFC or RFID chip requires power) may be very small (e.g., one or two microvolts or even a fraction of a microvolt).

[0093] According to some embodiments, an NFC or RFID chip may become faulty, out of power, damaged, or at least partially inoperable, preventing information on it from being rewritten or additional information from being written to or stored therein. In some embodiments, the NFC or RFID chip may have limited capabilities (e.g., it can only be written to or rewritten a maximum number of times or within a maximum time period). Therefore, in some embodiments, it is desirable for the NFC or RFID chip to have the ability to confirm that information that a user attempted to write or rewrite has been successfully written to or processed. In at least some embodiments, any and all information transmitted to or from the NFC or RFID chip may be encrypted or protected, or include secure elements to protect it from unauthorized access.

[0094] According to some embodiments, the NFC or RFID chip may include or provide GPS or location tracking capabilities. For example, the NFC or RFID chip may output or transmit the GPS coordinates of its location (e.g., periodically, non-periodically, in response to being queried by a sensor, or in response to meeting another condition). In some embodiments, the GPS or location tracking functionality may provide the NFC or RFID chip with information to determine and / or store (or provide information to allow another device, such as a user's mobile device using a corresponding software application, to determine and / or store) information, such as the current or past location of a vial corresponding to the NFC or RFID chip (e.g., where it was and how long it has been there, and where it is currently).

[0095] According to some embodiments, after each NFC or RFID chip is embedded into the BFS tube, the functionality of each NFC or RFID chip can be tested during the manufacturing process, and any tube determined to contain a malfunctioning NFC chip or one within desired parameters can be discarded or sent to a specialized processing procedure. Thus, in one embodiment, the manufacturing process may provide (i) adding the NFC or RFID chip to the tube (e.g., embedding the NFC or RFID chip into the plastic during plastic extrusion manufacturing, or attaching the NFC or RFID chip under the cap of a glass bottle or to another part of the glass bottle); (ii) filling the tube with a fluid reagent and sealing it; (iii) testing the NFC or RFID chip to determine if it functions within acceptable parameters (e.g., testing whether the unique identifier stored thereon can be successfully read); and (iv) performing one of the following: (a) if the NFC or RFID chip test is successful, allowing the bottle to proceed to a first manufacturing path (e.g., packaging and selling as a unique ID syringe), or (b) if the NFC chip test is unsuccessful, sending the bottle to a second manufacturing path (e.g., discarding or selling as a non-NFC chip bottle). According to some embodiments, inkjet printers or other printers may also print indications of NFC or RFID chip identifiers embedded in or attached to the vial or vial components. These indications may be in human-readable form (e.g., alphanumeric codes) or machine-readable form (e.g., barcodes or QR codes). The indications may be printed directly on the vial or vial components (e.g., on the cap in the case of glass bottles) or on a label subsequently affixed to the vial. Therefore, in such embodiments, the manufacturing process described above may further provide (v) reading the NFC or RFID identifier of the NFC or RFID chip embedded in the vial; and (vi) having a printing mechanism print the NFC or RFID identifier and place it on the vial (directly or as a label on the vial).

[0096] According to some embodiments, users, in conjunction with an injection management application, use a uniquely ID syringe to reward qualified use (once the application authorizes and the user self-injects the vaccine / medication in the syringe within an appropriate time window). In one embodiment, the end user (the user who will self-inject the vaccine / medication in the syringe) downloads the injection management application to their smartphone as a prerequisite for allowing the user to earn rewards based on qualified use of the vial (e.g., extra minutes of phone use, extra data from a data plan, monetary payments, etc.). (In other embodiments, the user does not need to download the application, and offline methods for verifying use can be implemented.) For example, a user can earn extra phone minutes by tapping the syringe on their smartphone during a qualified time window (e.g., the period during which the user should self-inject the vaccine / medication in the syringe based on a treatment plan stored in the application) (after opening the application). If the user taps the syringe during the qualified window, the user wins extra phone minutes or another reward (in some embodiments, the injection may also require additional application authorization based on verified information such as the dose in the syringe not being expired or the VVM status of the syringe being acceptable, as described herein).

[0097] In some embodiments of prescribing multiple injection regimens for users, the reward value can be based on the degree to which the user adheres to the multiple injection regimen. For example, for certain diseases or conditions, a user may need to self-administer multiple doses at specific time intervals. In this case, the user can be rewarded based on "completing the game": the user will be given a relatively large reward for complying with all required injections, but a smaller reward if he / she only complies with some rather than all of the injections.

[0098] Therefore, according to some embodiments, during the manufacture / filling of syringes, injection management services can effectively assign unique identifiers to specific doses of fluid medications (e.g., specific doses of vaccines) in a way that makes it difficult to modify the relationship between the dose and the unique identifier of the NFC or RFID chip embedded in or attached to the syringe storing the dose. This brings many benefits, including tracking when / where a specific dose of fluid medication is injected into a patient and allowing injection providers to easily verify that the dose to be injected into the syringe is indeed the dose they claim (e.g., by using an injection management app to read the unique identifier of the syringe's NFC or RFID chip before injection and enabling the app to verify / authorize the use of the dose).

[0099] In some embodiments, the NFC or RFID chip can be used to provide a periodic, non-periodic (e.g., triggered by certain events or randomly) or continuous GPS tracking history of the chip / syringe location (e.g., stored on the chip (e.g., in the cloud, on a server, where the NFC or RFID chip and / or a mobile device with an injection management application downloaded thereon can communicate with it)). Furthermore, the chip can communicate with the VVM, store photos or indications of the VVM's state, or be operable to determine the VVM's state. This VVM state data can be stored locally on the chip and / or at another location (e.g., in the cloud and / or on a server, where the NFC or RFID chip and / or a mobile device with an injection management application downloaded thereon can operable to communicate with it). Therefore, according to some embodiments, regarding the dosage of the syringe and the fluid agent it contains, the NFC or RFID chip can know one or more of the following: (i) where it is now, (ii) where it was previously; (iii) what temperature it was exposed to during its long journey; and (iv) how much time has passed since the day it was made and how much time has passed since then.

[0100] According to some embodiments, the injection management application (via an NFC chip) and / or the NFC or RFID chip itself is operable to identify, store, and / or forward various data that can be provided by a user, who may be an injection provider, patient, or other user. For example, as described herein, a user injecting a fluid medication from an NFC or RFID chip-enabled syringe into a patient, or a user injecting a fluid medication themselves, may tap the vial onto their mobile device before performing the injection, allowing the application to read and process the data from the NFC or RFID chip. For example, the application may verify (based on information known to the application about the patient) that (i) the syringe contains the appropriate fluid medication; (ii) the medication was taken at the appropriate time; and (iii) the fluid medication is still suitable for injection (e.g., the VVM does not indicate that it has been exposed to inappropriate temperatures, the expiry date associated with the syringe does not indicate that the fluid medication has expired, there is no recall associated with the vial, the vial is not a stolen vial, etc.). In some embodiments, the user may be required to take a photograph of the vial and / or injection site at the time of injection (in some embodiments, the user may be rewarded for providing this information). In some embodiments, users may be asked to provide indications of side effects or reactions to the fluid medication using the application (e.g., by answering one or more questions and / or uploading pictures of the injection site or related side effects) (and in some embodiments, users may be rewarded for providing such information).

[0101] According to some embodiments, users may be rewarded with phone minutes or mobile payments for providing specific information to the app or for complying with specific injection requirements that the app is tracking (e.g., by following an injection protocol, such as undergoing prescribed diabetes or tuberculosis treatment). Examples of such rewards include, but are not limited to, phone call minutes and mobile payments (e.g., micropayments). Such rewards may be offered to individual users (e.g., patients) or groups of users (e.g., to a family account associated with a mobile device storing the app).

[0102] According to some embodiments, injection management applications can be used to communicate with or follow up with users (e.g., patients receiving injections, or their guardians or family members). For example, a text message or application reminder can be sent to the user's mobile device to remind them to administer another self-injection of the fluid medication as part of the treatment course. In another example, the text message or application reminder can prompt the user to provide instructions regarding any reactions or side effects to the injection.

[0103] It should be noted that in some cases, users may be unwilling to receive text messages or alerts that clearly indicate that the message or alert is for an injection or specifies the type of injectable / fluid medication the user needs to receive. For example, users may feel embarrassed if others see these types of messages or alerts (which can be particularly problematic for users receiving alerts or messages on shared home mobile devices). Therefore, in some embodiments, messages or alerts may be hidden or encoded so that they do not explicitly state that they are about an injection or what kind of injection they refer to.

[0104] According to some embodiments, particularly in cases where self-injection is performed by a user who is not the injection provider, it may be desirable to know how much fluid medication in the syringe is actually injected into the patient. Therefore, for example, an injection management application can be used to perform and report a comparison of refractive indices before and after injection. In another example, the flow meter at the valve level (of the check valve in the delivery mechanism) can be compared before and after injection to determine the amount of fluid medication delivered.

[0105] According to some embodiments, it may be desirable to verify that the injection of a fluid agent from a uniquely identified syringe is indeed injected into a human or at least an animal (e.g., and not merely expelled into the air to obtain a reward associated with the injection). Therefore, for example, back pressure at the time of injection may be measured, and / or it may be necessary to input photographs of the injection site taken at or before and after the injection into the application.

[0106] According to some embodiments, the functionality or operability of a one-way valve in the delivery mechanism of a syringe, including one attached to an NFC or RFID chip-enabled syringe, can be controlled or influenced by the NFC or RFID chip. For example, according to some embodiments (e.g., as a measure to prevent injection of fluid medication contained in a stolen NFC or RFID chip-enabled syringe), if the unique ID syringe is first tapped onto a mobile device with an injection management application open thereon, and the application verifies that the syringe is authorized and not stolen or otherwise unsuitable for use, the one-way valve can only be opened, and the fluid medication is thus allowed to flow out. Only when the application verifies the authorized use of the syringe will it send communication to the NFC or RFID chip or another component of the syringe (e.g., a door or barrier associated with the valve), thereby allowing the valve to open.

[0107] According to some embodiments (e.g., embodiments where the syringe's NFC or RFID chip or other component allows for bidirectional communication), the syringe can be operated to broadcast its location (e.g., periodically or non-periodically), such as its current GPS coordinates. In some embodiments, if the syringe's NFC or RFID chip or other component determines that it is in an unauthorized or accidental location, that component can be operated to make a phone call or send a text message, or simply convey its location. In yet another embodiment, when its location needs to be determined, the NFC or RFID chip or other component can be remotely queried. All of the above contributes to preventing or tracking stolen syringes.

[0108] It should be noted that although it has been described herein that compliant or authorized injections from a uniquely ID syringe can be tracked via an application on a user's mobile device, the mobile device is not required for any of the embodiments described herein. Alternative devices can be used to assist in tracking user injections (e.g., a SIM card or other electronic card may be provided to the user that is operable to directly store the user's injection instructions or to store an identifier pointing to a cloud-based database that stores the user's injection instructions).

[0109] Interpretation rules

[0110] Numerous embodiments have been described, and these embodiments are for illustrative purposes only. The described embodiments are not limiting in any sense. The invention can be widely applied to many embodiments, as will be apparent from the disclosure herein. These embodiments have been described in sufficient detail to enable those skilled in the art to practice the invention, and it should be understood that other embodiments can be utilized, and structural, logical, software, electrical, and other changes can be made without departing from the scope of the invention. Therefore, those skilled in the art will recognize that the invention can be practiced with various modifications and variations. While specific features of the invention may be described with reference to one or more specific embodiments or drawings that form a part of this disclosure, and wherein specific embodiments of the invention are illustrated by way of illustration, it should be understood that these features are not limited to their use in the one or more specific embodiments or drawings to which they are described. Therefore, this disclosure is neither a verbal description of all embodiments of the invention, nor a list of features of the invention that must be present in all embodiments.

[0111] The terms “an embodiment,” “embodiment,” “embodiments,” “the embodiment,” “the embodiments,” “an embodiment,” “some embodiments,” “example embodiments,” “at least one embodiment,” “one or more embodiments,” and “an embodiment” refer to “one or more (but not necessarily all) embodiments of the present invention,” unless otherwise expressly stated.

[0112] The terms “including,” “comprise,” and their variations mean “including, but not limited to,” unless otherwise expressly stated.

[0113] Unless otherwise expressly stated, the term "consisting of" and its variations mean "including and limited to".

[0114] The list of listed items does not imply that any or all items are mutually exclusive. The list of listed items does not imply that any or all items are exhaustive, unless otherwise explicitly stated. The list of listed items does not imply that these items are ordered in any way according to the order in which they are listed.

[0115] The term "including at least one" followed by a series of items does not mean that every item in the list is required to be a component or subcomponent. Rather, it means that one or more of the listed items may include the specified item. For example, if it says "where A includes at least one of a, b, and c", it means that (i) A may include a, (ii) A may include b, (iii) A may include c, (iv) A may include both a and b, (v) A may include both a and c, (vi) A may include both b and c, or (vii) A may include a, b, and c.

[0116] Unless otherwise expressly stated, the terms “a”, “an” and “the” mean “one or more”.

[0117] Unless otherwise expressly stated, the term "based on" means "at least based on".

[0118] The methods described herein (whether referred to as methods, procedures, algorithms, computations, etc.) inherently include one or more steps. Therefore, all references to one or more "steps" of this method have a premise basis when merely stating the term "method" or similar terms. Consequently, any reference to one or more "steps" of the method in the claims is considered to have a sufficient premise basis.

[0119] The chapter titles and headings provided in this document are for convenience only and should not be construed as limiting this disclosure in any way.

[0120] Unless otherwise explicitly stated, devices communicating with each other do not need to communicate continuously. Furthermore, devices communicating with each other may communicate directly or indirectly through one or more intermediaries.

[0121] The description of an embodiment having several components that communicate with each other does not imply that all such components are required, or that each disclosed component must communicate with every other component. Rather, various optional components are described to illustrate various possible embodiments of the invention.

[0122] Furthermore, although process steps, method steps, algorithms, etc., may be described sequentially, these processes, methods, and algorithms may be configured to operate in an alternating order. In other words, any order or sequence of steps that may be described in this document does not itself imply that these steps must be performed in that order. The steps of the process described herein may be performed in any actual order. Moreover, some steps may be performed simultaneously, although they are described or implied to not occur at the same time (e.g., because one step is described after another). Furthermore, the fact that a process is illustrated by description in the accompanying drawings does not imply that the illustrated process does not include other variations and modifications thereof, nor does it imply that the illustrated process or any step thereof is necessary for the invention, nor does it imply that the illustrated process is preferred.

[0123] It is evident that the various methods and algorithms described herein can be implemented, for example, by a properly programmed general-purpose computer and computing device. Typically, a processor (e.g., a microprocessor or controller device) receives instructions from memory or a similar storage device and executes those instructions, thereby performing the process defined by those instructions. Furthermore, programs implementing such methods and algorithms can be stored and transmitted using a variety of known media.

[0124] When describing a single device or item, it is obvious that more than one device / item (whether they cooperate or not) can be used in place of a single device / item. Similarly, when describing more than one device or item (whether they cooperate or not), it is obvious that a single device / item can be used in place of more than one device or item.

[0125] The functionality and / or features of the device may be embodied by one or more other devices that are not explicitly described as having such functionality / features. Therefore, other embodiments of the invention do not necessarily need to include the device itself.

[0126] As used herein, the term "computer-readable medium" refers to any medium that participates in providing data (e.g., instructions) that can be read by a computer, processor, or similar device. Such media can take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical discs or magnetic disks, and other permanent storage devices. Volatile media can include dynamic random access memory (DRAM), which typically constitutes main memory. Transmission media can include coaxial cables, copper wires, and optical fibers, including conductors or other paths that include a system bus connected to a processor. Transmission media can include or transmit sound waves, light waves, and electromagnetic radiation, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tape, any other magnetic media, CD-ROMs, DVDs, any other optical media, punched cards, paper tape, any other physical media with a perforated pattern, RAM, PROMs, EPROMs, FLASH-EEPROMs, any other memory chips or cartridges, the carrier waves described below, or any other computer-readable media.

[0127] Various forms of computer-readable media can be used to transmit instruction sequences to a processor. For example, instruction sequences (i) can be transmitted from RAM to the processor, (ii) can be transmitted via wireless transmission media, and / or (iii) can be formatted according to various formats, standards, or protocols, such as Transmission Control Protocol, Internet Protocol (TCP / IP), Wi-Fi, Bluetooth, TDMA, CDMA, and 3G.

[0128] Where databases are described, those skilled in the art will understand that (i) alternative database structures can be readily employed, and (ii) other storage structures besides databases can be readily employed. Any illustrative diagrams and accompanying descriptions of any sample databases given herein are illustrative arrangements of the storage representation of information. Any number of other arrangements may be employed in addition to those suggested in the tables shown. Similarly, any illustrative entries for a database represent exemplary information only; those skilled in the art will understand that the number and content of entries may differ from those shown herein. Furthermore, although databases are described as tables, other formats, including relational databases, object-based models, and / or distributed databases, can be used to store and manipulate the data types described herein.

[0129] Similarly, database object methods or behaviors can be used to implement the process of this invention. Furthermore, the database can be stored locally or remotely from the device accessing the data in such a database, in a known manner.

[0130] For example, as an alternative to a database structure for storing information, a hierarchical electronic folder structure can be used. A program can then access the appropriate information in the appropriate folder within the hierarchical structure based on the file paths named within the program.

[0131] It should also be understood that any term referenced in the claims is used in this document in a manner consistent with the single meaning, merely for clarity and not to imply that any such term is so limited to that single meaning by implication or otherwise.

[0132] In the claims, the limitation of a claim that includes the phrase "apparatus" or the phrase "step" means that 35 U.S.SC §112, paragraph 6 applies to that limitation.

[0133] In claims, the absence of the phrase "apparatus" or "step" implies that paragraph 6 of 35 USC § 112 does not apply to that limitation, regardless of whether the limitation describes a function without describing a structure, material, or action for performing that function. For example, in a claim, the mere use of the phrase "step" or "step" when referring to one or more steps of that claim or another claim does not imply that paragraph 6 of 35 USC § 112 applies to that step.

[0134] Regarding the methods or procedures for performing a particular function according to paragraph 6 of 35 USC §112, the corresponding structures, materials, or behaviors and their equivalents described in the specification may perform additional and specific functions.

[0135] Computers, processors, computing devices, and similar products are structures capable of performing multiple functions. Such products can perform specific functions by executing one or more programs, such as programs stored in or accessed by the product's storage devices. Unless explicitly stated otherwise, such programs do not need to be based on any specific algorithm, such as any specific algorithm that may be disclosed in this application. It will be well known to those skilled in the art that specific functions can be implemented using different algorithms, and any of the various different algorithms is merely a design choice for implementing a particular function.

[0136] Therefore, regarding the means or steps for performing a particular function under 35 USC §112, paragraph 6, the structure corresponding to the particular function includes any product programmed to perform the particular function. Such a structure includes a programmed product that performs the function, whether or not such product is programmed with (i) a publicly available algorithm for performing the function, (ii) an algorithm similar to the publicly available algorithm, or (iii) a different algorithm for performing the function.

[0137] While various embodiments have been described herein, it should be understood that the scope of the invention is not limited to the specific embodiments explicitly described. Many other variations and embodiments will be understood by those skilled in the art upon reading this specification.

Claims

1. A method comprising: The first injection event is identified through the electronic processing equipment of the injection management system. The identification is based on receiving an indication of the dosage of a fluid medication to be administered to a patient via an injection provider platform stored on an injection management application corresponding to a first user. This indication includes first data, which includes a unique identifier for the syringe containing the dosage. The first user previously logged into the injection provider platform via the first mobile device by providing a first user credential, which allows the electronic processing device to uniquely identify the first user and recognize the first user as a registered injection provider; Authorize the dosage of fluid medication based on the syringe's unique identifier; Generate a unique electronic record for the first injection event transaction, thereby generating the first injection event record; Receive an indication from the first user and via the injection management application that the dose has been administered to the patient; In response to the receipt, a first verification code is generated, the first verification code corresponding to the expiration time of the first verification code, and is stored in association with the first injection event record; The first verification code is output to the first user via the injection management application; Before the expiration time, the first verification code is received from the second user. The second user has previously logged into the patient platform of the injection management application via a second mobile device by providing a second user credential, which allows the electronic processing device to uniquely identify the second user and recognize the second user as a registered patient; Based on receiving the first verification code from the second user, it is inferred that the second user is a patient who has been given a dose of fluid medication by the first user from a syringe as part of the first injection event transaction; Update the first injection event record to indicate that the dose of fluid medication has been administered to the second user; and A verifiable confirmation that the dose of fluid medication has been administered to the second user is transmitted to the second user's second mobile device via the patient portal of the injection management application, thereby transmitting a digital receipt of the first injection event to the second mobile device for storage in the patient portal of the second user's injection management application.

2. The method of claim 1, wherein the digital receipt includes a unique digital receipt identifier corresponding to the first injection event record, the unique digital receipt identifier being used to enable the second user to communicate with the injection management system via a patient portal of the injection management application and to verify the second user's vaccination status based on data stored in the first injection event record.

3. The method according to claim 1, further comprising: Before receiving the injection, the first user is given an instruction that the injection has been authorized via the injection management application.

4. The method according to claim 1, wherein the first injection event record is stored as a blockchain record in the distributed network of the injection management system.

5. The method of claim 1, wherein the digital receipt comprises at least one of: (i) an indication of a fluid medication; (ii) an identifier of a syringe; (iii) the time of administration of the dose; (iv) the location of administration of the dose; (v) an identifier of a second user; and (vi) an indication of an first user administering the dose.

6. The method of claim 5, wherein the digital receipt includes a code that can be displayed on a second user's mobile device via a GUI of a patient platform of an injection management application upon request by the second user, the code being readable by an external electronic device to confirm that the dose of fluid medication has been administered to the second user.

7. The method according to claim 5, wherein, The digital receipt includes multiple privacy levels of information that can be shared with third parties. Each privacy level of information corresponds to a specific permission requirement of a second user, such that in order to share a given privacy level of information of the digital receipt with a third party, the second user must first provide the corresponding permission requirement.

8. The method according to claim 7, wherein, The first level of information among the multiple privacy levels corresponds to anonymous information about the dose administered to the second user without identifying the second user, and the second level of information among the multiple privacy levels corresponds to information that identifies the second user and information about the dose administered to the second user.

9. The method according to claim 1: The fluid medication includes a vaccine against a specific transmissible disease, which is effective for a predetermined period of time from the time of administration, such that the second user believes they have been vaccinated against the specific transmissible disease during the predetermined period of time. Furthermore, the digital receipt also includes a cutoff date for the dose based on the predetermined time period, the cutoff date being used by the patient portal of the injection management application, only up to the cutoff date, to output confirmation via the GUI of the injection management application that the second user is considered to have been vaccinated against the specific transmissible disease.

10. The method of claim 1, wherein receiving an indication that the dose has been administered to the patient comprises receiving a photograph of the second user taken during the first injection event, and wherein updating the electronic record comprises sending a copy of the photograph to the second user's mobile device for storage in association with the digital receipt.

11. The method according to claim 1, wherein, A copy of the photograph is stored in association with the record of the first injection event.

12. The method of claim 1, further comprising: Information describing the fluid agent and dosage is retrieved from a database accessible by the electronic processing device, based on the syringe's unique identifier.

13. The method of claim 12, wherein the authorization includes: Based on the information provided, it was confirmed that the dosage was effective and approved for administration.

Images