Medical syringe, and system and method for an injection management platform

Abstract

The disclosed systems, methods, and products provide an injection management platform that utilizes decentralized, secure technologies, such as blockchain, to enable the verification and management of injection event transactions involving syringes equipped with NFC or RFID chips. The injection event transaction ledger allows for secure verification and updating of digital receipts of injection event transactions. In some embodiments, the syringes include blow-fill-seal (BFS) syringes pre-filled with a single dose of a fluid medication, such as a vaccine or medication, and each administration of the fluid medication can be tracked via the injection event transaction ledger.

Description

Technical Field

[0001] (Claims of Priority) This application claims priority based on U.S. Provisional Patent Application No. 63 / 019,192, titled "NFC-ENABLED DRUG CONTAINING SYSTEM AND ASSOCIATED INFORMATION LAYER", filed on May 1, 2020. The entire disclosure of the above application is incorporated herein by reference.

[0002] (Copyright Notice) Part of the disclosure of this patent document contains materials subject to copyright protection. The copyright owner does not object to the reproduction by others of this patent document or patent disclosure as it appears in the patent file or records of the U.S. Patent and Trademark Office, but reserves all copyrights in other respects.

Background Art

[0003] Every year, a surprising number of people are infected with various diseases and die. Among these diseases, there are some that can be prevented (or the severity of the disease can be reduced) by injectable drugs (i.e., drugs administered using a syringe or other needle-type delivery device). Thanks to injectable drugs, the number of cases of some infectious diseases (or the severity of the symptoms or the number of deaths caused by these infectious diseases) has decreased dramatically. However, among these infectious diseases, some are still common, and new infectious diseases are also emerging. In many cases, people around the world, especially in developing and economically disadvantaged countries, are suffering from the spread of preventable diseases due to ineffective injectable drug / vaccination programs. The reasons include insufficient implementation of injections, shortages of available drugs / vaccines, shortages of skilled personnel sufficient to administer injections, insufficient tracking and management of the locations where injections have been administered and the locations where injections are still needed, and any combination of these.

Summary of the Invention

Problems to be Solved by the Invention

[0004] Due to recent global events such as the COVID-19 pandemic, the inadequacies of existing injection drug / vaccination programs have become even more apparent. This pandemic is an example of a situation where a population can benefit from the following (i) to (iv). (i) Vaccinated individuals can be verifiably and efficiently tracked (it is also possible to track the location and date of vaccination, as well as the type of vaccine administered). (ii) Proof of vaccination (and in some embodiments, proof of the current vaccination status in cases where the effectiveness of the vaccine requires a booster shot or additional injection) can be efficiently provided. (iii) Areas that require continuous vaccination can be identified. (iv) By providing means for less skilled individuals to administer vaccinations, a wider range of vaccination activities can be enabled. Existing systems and infrastructure have been found to be inadequate to meet the above needs.

Brief Description of the Drawings

[0005] Many of the embodiments described herein and the attendant advantages thereof will be readily understood by reference to the following detailed description when taken in conjunction with the accompanying drawings.

[0006]

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 3C

Figure 3D

Figure 3E

Figure 3F

Figure 3G

Figure 3H

Figure 3I

Figure 3J

Figure 3K

Figure 3L

Figure 4

Best Mode for Carrying Out the Invention

[0007] The embodiments described herein relate to a syringe for single administration of a fluid medicament, the syringe comprising a data storage mechanism that enables electronic recognition, tracking, and / or approval of a single administration of a fluid medicament to a patient. In some embodiments, the electronic platform of the present invention facilitates (i) transmitting data from the syringe to the injector's device and then to the electronic processing system of the electronic platform to facilitate approval and tracking of the administration of the fluid medicament from the syringe to the patient, and / or (ii) enabling data exchange with the patient's device and enabling the patient to receive and store a digital receipt indicating that a single administration of the fluid medicament has been made from the syringe. The electronic platform of the present invention further enables a healthcare system and healthcare authorities to generate and utilize an information layer associated with a syringe equipped with a data storage mechanism.

[0008] As used herein, the term syringe refers to a device filled with a single dose of a fluid medicament such as a vaccine or a drug (in some embodiments, including a lyophilized component that can be reconstituted into a liquid prior to injection). The syringe can be made of plastic, glass, or other materials, and the embodiments described herein do not depend on syringes made of a particular material. Syringes include, for example, auto-injectors with a spring mechanism or other mechanism to assist in the injection of the fluid medicament, or manual syringes where the operation of the injection mechanism depends on the user. Examples of manual syringes include plunger syringes and plastic vial syringes (e.g., blow-fill-seal (BFS) syringes), which require the injector (e.g., a nurse, or in the case of self-injection, the patient) to apply pressure to push the fluid medicament out of the vial or other component that makes up the syringe filled with the fluid medicament. Examples of syringe devices that can be utilized in the embodiments described herein include those described in Patent Document 1 (PCT / US21 / 25683, filed Apr. 3, 2021, by Koska et al., entitled "SYSTEMS AND METHODS FOR PRE-FILLED MEDICAL DELIVERY DEVICES") and Patent Document 2 (PCT / US18 / 61696, filed Nov. 16, 2018, by Koska et al., entitled "SYSTEMS AND METHODS FOR FLUID DELIVERY MANIFOLDS") (the entire disclosures of the above patent documents are incorporated herein by reference).

[0009] Syringes pre-filled with a single dose of a fluid agent may be pre-filled during the manufacturing process like the BFS syringes described in Patent Document 1 and Patent Document 2 above (pre-filled type), or there may also be cases where the injector extracts and fills a single dose from a multi-dose container (on-site filling type). It should be noted that in the on-site filling type syringe, before injection, the injector extracts a single dose of the fluid agent from another container (e.g., a glass multi-dose vial) and fills the syringe. In the on-site filling type syringe, since the fluid agent administered through the syringe is not unique to that syringe, the injector needs to provide two pieces of data to identify both the identifier of the syringe and the identifier of the multi-dose vial from which a single dose of the fluid agent is extracted. In the pre-filled type syringe, the unique identifier of the syringe essentially identifies both the syringe itself and the fluid agent filled in that syringe. Identifying the fluid agent is desirable in one embodiment where there is interest in information such as, for example, the batch number, type of fluid agent, manufacturer, and manufacturing date of the fluid agent. The embodiments described in this specification mainly focus on pre-filled type syringes with unique identifiers.

[0010] In the embodiments described in this specification, each syringe has a data storage mechanism that uniquely identifies the syringe, such as by storing the unique identifier of each syringe generated at the time of manufacturing the syringe (in the case of a pre-filled type syringe, at the time when the syringe is pre-filled with the fluid agent). Examples of such a data storage mechanism include, for example, a near field communication (NFC) chip, a radio frequency identification (RFID) chip, a QR code (registered trademark), a barcode, or other machine-readable mechanisms capable of storing the unique identifier of the syringe in relation to the syringe (e.g., attached to or embedded in the syringe or a part thereof (such as above or below the label part of the syringe)).

[0011] Note that in some embodiments, the unique identifier of the syringe and / or other data stored in the NFC chip or other data storage mechanism may be stored in an encrypted form. Further, note that in some embodiments, communication with the NFC chip (or other data storage mechanism) and / or the injection management application may be performed in an encrypted form (e.g., using a public key / private key protocol, etc.) or using other security measures (such as two-factor authentication or blockchain technology).

[0012] In some embodiments, the injection management system of the present invention includes providing an injection management application for facilitating authentication / approval of an injection via a syringe having a data storage mechanism as described herein. The injection management application of the present invention can be used by an individual to communicate with a centralized or distributed (e.g., blockchain-based) system for facilitating the creation and utilization of an information layer based on the use of the syringe or the retention of electronic records. In some embodiments, the injection management application of the present invention includes a portal or platform for injection implementers through which an injection implementer (or other individual, collectively referred to as the "injection implementer") who performs an injection of a fluid drug using a syringe as described herein can sign in to the injection management system and access functions for injection implementers. For example, before injecting a fluid drug into a patient, the injection implementer can use the injection management application to confirm that the fluid drug filled in the pre-filled syringe is valid and its use is approved (e.g., not a counterfeit, not expired, not subject to recall), and record each injection event in the injection management system, including an instance of the injection implementer who administered the fluid drug filled in the uniquely identified syringe to a specific patient. Similarly, the injection management application includes a portal or platform for patients through which an individual receiving an injection (the "patient") can sign in to the injection management system and access functions for patients (e.g., obtain a digital receipt and store it on the patient's mobile device, and provide proof of having received a specific vaccine or other administration of a specific fluid drug by sharing the digital receipt with a third party in some way).

[0013] In some embodiments and situations, an individual may play both the role of an injection implementer and a patient. In some embodiments, an individual may play both the role of an injection implementer and a patient in a particular injection event (e.g., an event in which the individual can self-administer an injection).

[0014] By providing an injection management app that can recognize injection events in which a uniquely identifiable pre-filled syringe is used, one or more advantages can be provided that are superior to the existing functions of the medical system. For example, many vaccination programs involve administering vaccines using common reusable syringes. However, in many cases, especially in developing countries, vaccine administration may be carried out by non-experts outside the hospital, and injections may be given to patients without careful management of access to syringes. Using reusable syringes in such situations increases the risk of spreading infectious diseases and blood-borne diseases, especially when subsequent injections are given using used and unsterilized syringes. For example, the World Health Organization (WHO) estimates that blood-borne infections such as hepatitis and human immunodeficiency virus (HIV) are transmitted due to the reuse of reusable syringes, resulting in more than one million deaths each year. Utilizing pre-filled syringes with unique identifiers, and in particular, being able to track when a specific syringe was used, and in some embodiments, providing an easy-to-use injection management app that can output warnings or hold approval for multiple administrations of a fluid drug from a specific syringe, will help mitigate the above problems with existing systems.

[0015] The embodiments presented in this specification describe a system, apparatus, interface, method, and article of manufacture for managing, tracking, approving, and certifying injection events in which a patient receives an injection of a specific fluid drug from a syringe equipped with a unique identifier. For example, in some embodiments, an injection management system (which may incorporate a blockchain distributed network system for security purposes in some embodiments) may perform the following steps: (i) recognizing a first injection event transaction by an electronic processing device of the injection management system, where the recognition of the first injection event transaction is based on receiving information regarding the administration of a fluid drug to a patient via an injector platform of an injection management app stored on a first mobile device corresponding to a first user, the information including first data including the unique identifier of the syringe filled with the fluid drug, and the first user has pre-signed in to the injector platform via the first mobile device by providing first user authentication information that enables the electronic processing device to uniquely identify the first user and recognize the first user as a registered injector, the step of (ii) approving the administration of the fluid drug based on the unique identifier of the syringe; (iii) generating a first injection event record by generating an electronic record unique to the first injection event transaction; (iv) receiving, from the first user via the injection management app, information indicating that the administration of the fluid drug to the patient has been performed; (v) generating a first passcode having an expiration date in response to receiving the information indicating that the administration of the fluid drug to the patient has been performed, and storing the first passcode in association with the first injection event record; (vi) outputting the first passcode to the first user via the injection management app. (vii) Before the expiration of the first passcode, receiving the first passcode from a second user, wherein the second user provides second user authentication information that enables the electronic processing device to uniquely identify the second user and recognize the second user as a registered patient, and thereby signs in advance to the patient platform of the injection management app stored in the second mobile device via the second mobile device corresponding to the second user; (vii) Based on receiving the first passcode from the second user, determining that the second user is the patient who received the administration of the fluid drug from the first user as part of the first injection event transaction; (ix) Updating the first injection event record to indicate that the second user received the administration of the fluid drug; (x) Sending, via the patient platform of the injection management app of the second user, a confirmation to the second mobile device of the second user that proves that the second user received the administration of the fluid drug, thereby sending a digital receipt of the first injection event record that will be stored in the patient platform of the injection management app of the second user to the second mobile device; facilitating the implementation of the method.

[0016] This specification describes various improvements that can be made to syringes, such as BFS vials and conventional glass vials, by including or attaching a unique identifier to the syringe. The unique identifier can be in the form of a physical component such as an NFC chip or an RFID chip, or in the form of a QR code (registered trademark). Regardless of the form in which the unique identifier is embodied, by associating the unique identifier with each syringe, an information layer can be created that relates to the syringe (or, particularly in the case of a pre-filled syringe, the fluid drug filled in the syringe) and / or the patient receiving the administration of the fluid drug filled in the syringe. In this specification, various embodiments are described as being applicable to syringes including BFS vial syringes, but it should be understood that at least some of these embodiments are also applicable to vial or syringe systems made of glass or other materials that can benefit from the data generation and new functions described herein. Therefore, when referring to a BFS vial or other specific type of syringe, that reference is not intended to be limiting, and it should be understood that in various embodiments, the same or similar functions can be provided for other types of syringes that function as containers for fluid drugs. Similarly, in this specification, some embodiments refer to NFC chip-enabled syringes, but that reference is also intended to refer to any type of syringe (regardless of whether it is a BFS vial mechanism, a conventional glass vial, or another type) associated with a unique identifier that can be read via a software application as described herein (e.g., an NFC chip or an RFID chip is embedded or attached in some way, or a QR code (registered trademark) is attached such that the unique identifier of the NFC chip can uniquely identify the corresponding syringe and the specific fluid drug filled in that syringe). A syringe having such a unique identifier is also referred to herein as a unique ID syringe.It should be noted that when the term "syringe" is used other than as a "unique ID syringe", it may be used in this specification as a shortened form of the "unique ID syringe", and in the context of the description, it should not be construed to mean that an identifier is not associated with the syringe. Further, a unique identifier or data storage mechanism that includes a unique identifier attached to, embedded in, printed on, embossed on, or otherwise associated with the syringe includes the unique identifier or the data storage mechanism that stores the unique identifier in the syringe, and in some embodiments, it should be noted that it means being attached to or otherwise associated with a specific component of the syringe (e.g., a BFS vial or the label portion of a BFS vial) or a package (e.g., an NFC chip may be attached to the foil packaging of the syringe).

[0017] By providing each syringe with a data storage mechanism such as an NFC chip (e.g., by attaching a data storage mechanism to the syringe or its components or otherwise making it compatible), new and useful advantages including the following (i) to (v) can be realized. (i) Enable the syringe to be connected to the Internet of Things (IoT) or to communicate with an IoT-connected remote server and / or other devices. (ii) Enable a compliance tracking / reward mechanism (e.g., for self-injection situations, multiple injection regimens, or other situations). (iii) The user of the proprietary ID syringe (regardless of whether the user is the person administering the injection, the patient receiving the injection, or a parent, guardian, or other relevant person of the patient receiving the injection) uses a specially programmed software application on a mobile device or other device (assuming the application has been pre-downloaded to the device) to input data or information into the application and / or enable the application to read information from a data storage mechanism (and in some embodiments, for example, when the data storage mechanism includes an NFC chip or an RFID chip, it is possible to write data to the data storage mechanism). (iv) Enable proof, approval, tracking, confirmation, and remuneration for the administration of the fluid drug from the syringe to the patient. (v) Enable follow-up communication (e.g., text messages, messages via an injection management application) to remind the patient who has received an injection from the syringe to self-administer additional injections or receive additional injections at a clinic, ask questions about possible side effects, or receive confirmation that the additional authenticated or approved fluid drug has been injected into the patient as recommended.

[0018] It should be noted that for the injection of a fluid drug from an NFC chip-compatible syringe, at least three types of users including the following (i) to (iii) may be involved. (i) An injector such as a medical staff member. (ii) A patient who receives the injection of the fluid drug. (iii) A protector (e.g., a parent), friend, or family member of the patient who receives the injection of the fluid drug (in some cases, the patient may be a person in a village who shares a mobile device. Such a person who may be related to the patient is collectively referred to as a patient contact in this specification). It is not always the case that all three types of these users are involved in a certain injection. In some embodiments, one or more of these users can access various platforms, portals, or versions of an injection management app (or various aspects, functions, or pages of such an app) on the user's mobile device to facilitate one or more of the embodiments described herein. For example, the injector can access and use a first version or aspect of the injection management app (referred to as the injector platform of the injection management app), and the patient or patient contact can access and use a second version or aspect of the injection management app (referred to as the patient platform of the injection management app). In some embodiments, the patient platform can facilitate the tracking of vaccines or other fluid drugs administered to a specific patient and provide an online or electronic record (e.g., a digital receipt of an injection event or a vaccine electronic certificate) of the vaccines or other fluid drugs administered to the patient. In some situations, a family may share one mobile device, and the app on that mobile device may enable the tracking of the injections of multiple members of that family.

[0019] In some embodiments, the injection management application (regardless of whether it is for the injector platform or the patient platform) enables communication of data between the injection management application and a remote server of a service that provides or manages the injection management application and the injection data collected thereby (hereinafter, such a service is referred to as an injection management service). In some embodiments, the injection management service is involved in the manufacture and / or distribution of the unique ID syringes described herein (e.g., manages the organization that manages it or has a transactional relationship), stores records of unique ID syringes to be tracked from the time of manufacture to the time of injection according to the embodiments described herein, and can be manufactured according to the embodiments described herein. In some embodiments, when the device on which the application is downloaded cannot communicate with the injection management service (e.g., the device is not connected to Wi-Fi® or is not sufficiently connected to the cellular phone service), the data collected via the injection management application is cached and stored in the local memory, and then, when a sufficient communication connection is established, the data stored in the local memory is transferred to the injection management service. In some embodiments, the injection management service can open records in a database of each unique ID syringe manufactured according to the embodiments described herein. In some embodiments, the injection management service stores, in its storage mechanism, the unique identifier of an NFC chip or an RFID chip embedded in or attached to a vial, in association with other information corresponding to the liquid medicine (e.g., manufacturing time and location; batch, lot, and / or strip number; type of liquid medicine; dosage of the liquid medicine; expiration date of the liquid medicine; etc.).After that, when the user (e.g., the injector, the patient, or the patient liaison) taps the unique ID syringe on the mobile device, the injection management app reads the unique identifier (e.g., the identifier of the NFC chip) stored in the syringe's data storage mechanism and communicates with the injection management service to (i) obtain information related to the vial / chip to authenticate or approve the injection (e.g., check whether the expiration date of the fluid drug has passed or whether it is subject to recall), or (ii) open or create a new record (or update the information in an existing data record) to record that the fluid drug corresponding to the identifier has been injected. This also includes storing various new information obtained from the user or obtained by tapping the vial on the mobile device (e.g., the date / time / location of the injection; the identifier of the injector (if available); the identifier of the patient and / or the identifier of the mobile device associated with the patient (e.g., phone number)), which is also referred to herein as an injection event record. In some embodiments, the injection management service operates an injection management system comprising one or more servers communicable with the user's mobile device on which the injection management app is installed. The user's mobile device is a device registered with the injection management system and is a user of the injection management system. In some embodiments, the injection management system utilizes a blockchain-type distributed server network (e.g., for security purposes) to store injection event records.

[0020] In some embodiments, after the user taps the vial on the mobile device on which the injection management app is open, in addition to or instead of contacting the injection management service to authenticate or approve the injection, the injection management app reads information from the data storage mechanism in addition to the chip identifier (e.g., NFC chips and RFID chips can store readable data such as the expiration date, dosage, type, etc. of the fluid drug filled in the vial), uses the read information to approve the injection, and can output to the user that the injection can be performed.

[0021] In some embodiments where the native ID syringe includes a BFS vial mechanism, it is assumed that a pre-filled BFS vial, into which the fluid medicament is filled during the BFS manufacturing process described herein, comprises an NFC chip embedded within the plastic thereof, or attached to the interior or surface thereof (the term "embedded" is used for brevity, but is intended to encompass any form of attachment or embedding to the vial, whether it be a BFS vial or another type of plastic or glass vial). In another embodiment, the data storage device (regardless of whether it is an NFC chip, RFID chip, or other form) can be adhered or otherwise attached to the syringe during the manufacturing process (for example, it can be adhered or otherwise attached above or below the label portion of the BFS vial).

[0022] Referring now to FIG. 1, a block diagram of an injection management system 100 according to some embodiments is shown. In some embodiments, the injection management system 100 includes a plurality of node devices 102a-n, a network 104, a management device 106, and a server device 110. In some embodiments, any or all of the node devices 102a-n, the management device 106, and the server device 110 include or are configured to communicate with data storage and / or memory devices 140-1a-n, 140-2. For example, each node device 102a-n is configured to include a local memory device 140-1a-n, and the server device 110 is configured to include a network memory device 140-2. As shown in FIG. 1, any or all (or any combination thereof) of the node devices 102a-n, the management device 106, the server device 110, the local memory devices 140-1a-n, and the network memory device 140-2 can communicate via the network 104. In some embodiments, communication between and / or within each of the node devices 102a-n, the management device 106, the server device 110, the local memory devices 140-1a-n, and the network memory device 140-2 of the injection management system 100 is utilized to provide and manage a distributed injection event transaction ledger. The server device 110 can, for example, interface with one or more of the node devices 102a-n and / or the management device 106 to execute multiple instances of a specially programmed chain code (not shown) stored in any or all of the memory devices 140-1a-n, 140-2, or provide a specially structured interface through which a user participating in an injection event transaction can obtain, verify, and / or change status information regarding the injection event transaction.

[0023] A lesser or greater number of components 102a-n, 104, 106, 110, 140-1a-n, 140-2, and / or various configurations of components 102a-n, 104, 106, 110, 140-1a-n, 140-2 may be included in the injection management system 100 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 have the same configuration and / or function as components of the same name and / or reference numeral described herein. In some embodiments, the injection management system 100 (and / or a portion thereof) may include a distributed injection event management program, system, and / or platform that is programmed or otherwise configured to execute, implement, and / or facilitate the methods described herein, including the injection management method 400 and / or a portion thereof.

[0024] In some embodiments, the node devices 102a-n can include any type or configuration of known or implementable computer device, mobile electronic device, network device, user device, and / or communication device. The node devices 102a-n include one or more electronic devices such as mobile devices including smartphones, cellular phones, and / or wireless phones, such as, for example, the iPhone (registered trademark) manufactured by Apple, Inc., and the LG Optimus Zone 3 manufactured by LG Electronics, Inc. of San Diego, California, USA, which runs the Android (registered trademark) operating system of Google, Inc. of Mountain View, California, USA. In some embodiments, the node devices 102a-n can include devices owned and / or operated by one or more users, such as patients, injection administrators, or third parties for the purpose of verifying information regarding a particular injection event transaction. In some embodiments, the node devices 102a-n communicate with the server device 110 via the network 104 and perform injection authentication inquiries and / or processes, or record, store, verify, or update information regarding injection events (e.g., the fact that a particular patient received an administration of a particular fluid drug at a particular date and time and / or location, and / or the patient's current vaccination status (e.g., as a result of participating in a vaccination event)) according to the distributed blockchain code execution process described herein. In some embodiments, each of the node devices 102a-n can store an instance of an injection management application as described herein, through which the users of the node devices 102a-n can communicate with an injection management system that owns, controls, or operates (or operates instead of) the server device 110.

[0025] In some embodiments, the node devices 102a-n can interface with the server device 110 and / or the management device 106 to effect (direct or indirect) communication with one or more other node devices 102a-n, for example, operated by other users (such communication is not explicitly shown in FIG. 1). In some embodiments, the node devices 102a-n can interface with the server device 110 to effect (direct or indirect) communication with the management device 106 (such communication is also not explicitly shown in FIG. 1). In some embodiments, the node devices 102a-n and / or the server device 110 can execute a separate instance of a chain code algorithm that distributes the transaction ledger of injection events in an encrypted and authenticated manner. As described herein, for example, the node devices 102a-n and / or the server device 110 can communicate with the management device 106 to execute cryptographic services utilized to securely distribute injection event chain code blocks or payloads to a plurality of node devices 102a-n.

[0026] In some embodiments, network 104 may include a local area network (LAN; wireless and / or wired), a cellular phone, Bluetooth®, near field communication (NFC), and / or a radio frequency (RF) network having communication links with server device 110, node devices 102a-n, management device 106, and / or memory devices 140-1a-n, 140-2. In some embodiments, network 104 may include direct communication links with any or all of the components 102a-n, 106, 110, 140-1a-n, 140-2 of injection management system 100. Node devices 102a-n can interface or connect directly with one or more server devices 110 and / or management device 106 via one or more wires, cables, wireless links, and / or other network components, such as network components (e.g., communication links) that make up a part of network 104. In some embodiments, network 104 may include one or more other links or network components other than those shown in FIG. 1. Node devices 102a-n can be connected to server device 110 and / or management device 106 via various cell towers, routers, repeaters, ports, switches, and / or other network components that make up a part of network 104, such as the Internet and / or cellular phone (and / or public switched telephone network (PSTN)) networks, for example.

[0027] Although network 104 is shown as a single object in FIG. 1, network 104 can include any number, type, and / or configuration of networks that have been identified or made available. In some embodiments, network 104 can include various sub-networks and / or collections of network components that are directly or indirectly interconnected by components 102a-n, 106, 110, 140-1a-n, 140-2 of injection management system 100. Network 104 can be, for example, one or more cellular phone networks with communication links between node devices 102a-n and server device 110, or alternatively, for example, the Internet with communication links between server device 110 and one or more of management device 106 and / or memory devices 140-1a-n, 140-2.

[0028] In some embodiments, the management device 106 includes a computer processing device of any type or configuration, such as a PC (personal computer), laptop computer, computer server, database system, other electronic device, other device, or any combination thereof. In some embodiments, the management device 106 can be owned and / or operated by a third party (i.e., an entity different from any entity that owns and / or operates either the node devices 102a-n or the server device 110; for example, a provider of certificate, authentication, and / or encryption services). The management device 106 can execute one or more web services that provide a centralized blockchain encryption function, such as the Hyperledger(TM) Fabric(TM) blockchain framework available from The Linux(registered trademark) Foundation in San Francisco, California, USA. In some embodiments, the management device 106 can receive blockchain data from one or more node devices 102a-n and / or server devices 110, apply a hash algorithm to the received data, and send the encrypted data to each of the node devices 102a-n and server devices 110 (e.g., for storage in a local copy of the blockchain ledger). In some embodiments, the management device 106 may include a plurality of devices or may be associated with a plurality of third-party entities.

[0029] In some embodiments, the server device 110 may include an electronic and / or computerized control device, such as a computer server, communicatively connected to interface (directly and / or indirectly) with the node devices 102a-n and / or the management device 106. The server device 110 may include, for example, one or more PowerEdge(TM) R830 rack servers manufactured by Dell, Inc. of Round Rock, Texas, USA, which may include one or more Twelve-Core Intel(R) Xeon(R) E5-4640v4 electronic processing devices. In some embodiments, the server device 110 may include a plurality of processing devices specially programmed to execute and / or perform processes that cannot be executed without the assistance of the server device 110. The server device 110 can manage, for example, a blockchain ledger of multiple injection event transactions by executing one or more coded rules, such management enabling real-time updates and changes to injection event status that cannot be performed without the benefit of the specially programmed server device 110. In some embodiments, the server device may include an injection management system as described herein that can communicate with patients and injection administrators via respective mobile devices (e.g., node devices 102a-n) to obtain, update, and transmit authentication of data stored in an injection event record embodied in an injection event transaction ledger, an injection event database, or other repository of electronic records representing injection events tracked and managed by the injection management system.

[0030] In some embodiments, the server device 110 may be located at a remote location from one or more of the node devices 102a-n and / or the management device 106. Also, the server device 110 may include a plurality of electronic processing devices disposed at one or more various sites and / or locations.

[0031] In some embodiments, the server device 110 can store and / or execute instructions specially programmed to operate in accordance with the embodiments described herein. The server device 110 can execute, for example, one or more programs, modules, and / or routines in an online environment that facilitate the management, tracking, approval, authentication, and / or updating of injection events via an injection management app as described herein. In some embodiments, the server device 110 can include a computerized processing device, such as a computer server and / or other electronic device, for managing and / or facilitating transactions and / or communications related to the node devices 102a-n. Private companies, government health agencies, healthcare companies, syringe manufacturers, and / or other users can, for example, use the server device 110 to implement the following (i) to (v). (i) Receive or recognize injection events related to unique ID syringes. (ii) Approve an injection from the syringe. (iii) Receive from the injector confirmation that a specific fluid drug has been administered to a specific patient (e.g., at a specific date and time and / or location). (iv) As a result of any of the above, store the vaccination status (vaccination situation) of a specific patient for a specific vaccine. (v) Provide an interface for a third party to check the vaccination status of a patient and / or provide up-to-date information in real time as described herein.

[0032] In some embodiments, the node devices 102a-n, the management device 106, and / or the server device 110 can communicate with the memory devices 140-1a-n, 140-2. The memory devices 140-1a-n, 140-2 can include various databases and / or data storage media capable of storing various data and instructions. Such various data and instructions include, for example, syringe data, fluid drug data, registered patient data, registered injector data, injection event data, and / or injection or vaccination status data obtained from the node devices 102a-n, digital receipt data defined by the server device 110 (including the privacy level related to the digital receipt in embodiments adopting such a level), injection approval processing rules, chain code instructions, blockchain data, encryption keys and / or data, login and / or ID authentication information of registered users, and / or instructions for operating various devices (e.g., the server device 110, the management device 106, and / or the node devices 102a-n) according to the embodiments described herein.

[0033] Memory devices 140-1a-n, 140-2 can store, for example, blockchain data defining a distributed injection event transaction ledger (e.g., data defining injection events provided by an injection implementer indicating that an injection event for a specific patient has been approved and / or administered and / or that a specific fluid drug has been administered to a specific patient, which data includes accompanying detailed information such as the date and time, location, fluid drug, and / or injection implementer corresponding to the injection), chain code instructions, and data for communicating with the management device 106 (e.g., APIs and / or API tunnels for web services providing blockchain authentication, certificates, and / or cryptographic hashes). In some embodiments, memory devices 140-1a-n, 140-2 can include any type, configuration, and / or quantity of data storage devices that have been identified or made available. Memory devices 140-1a-n, 140-2 can include, for example, an array of optical hard drives and / or solid state hard drives configured to store injection event transaction ledger data provided by (and / or requested from) node devices 102a-n, analysis data of syringes and / or injection events (e.g., analytical formulas and mathematical models), and / or various operation instructions and drivers, etc. Memory devices 140-1a-n, 140-2 are shown as stand-alone components of various node devices 102a-n and server 110, but memory devices 140-1a-n, 140-2 may include multiple components. In some embodiments, memory devices 140-1a-n, 140-2 including multiple components may be distributed among various devices and / or distributed remotely. Any or all of node devices 102a-n, management device 106, and / or server device 110 may include, for example, memory devices 140-1a-n, 140-2 or a portion thereof.

[0034] Next, referring to FIG. 2, a block diagram of an injection management system 200, which is a component of the injection management service described herein, is shown. In one embodiment, the injection management system 200 may include an example of the server device 110 (FIG. 1). The injection management system 200 includes, for example, a processor 201, a memory 203, a database 202, and a plurality of software modules 222-226.

[0035] In some embodiments, any or all of the components of the injection management system 200 include one or more hardware components, such as a microprocessor, a microcontroller, or digital sequential logic, such as the processor 201. The processor 201 includes one or more processors, such as one or more INTEL(TM) processors, operating sequentially or in parallel. The processor 201 communicates with the memory 203 or is operably connected to the memory 230. The memory 203 can include a suitable combination of magnetic memory, optical memory, and / or semiconductor memory, and can include, for example, random access memory (RAM), read-only memory (ROM), compact disk, and / or hard disk. The processor 201 and the memory 203 can each be, for example, (i) disposed entirely within a single computer or other device, or (ii) interconnected with each other by a remote communication medium, such as a serial port cable, a telephone line, or a radio frequency transceiver. In one embodiment, the injection management system 200 can include one or more devices (e.g., the management device 106 of FIG. 1) connected to a remote server computer to maintain a database or injection event transaction records.

[0036] The injection management system 200 further includes a database 202. In some embodiments, the database 202 can store data useful for implementing one or more of the embodiments described herein. Non-limiting examples of such data include the following (i)-(v). (i) Data related to one or more users (e.g., a patient receiving an injection and / or an injector). (ii) Data related to a pharmaceutical company that manufactured the drug filled in the syringe. (iii) Data related to a syringe equipped with a data storage mechanism for storing a unique identifier. (iv) Data related to one or more injection events or injection event transactions. (v) Data related to one or more rewards that a patient has obtained (or is scheduled to obtain) through an injection compliance program as described herein.

[0037] In some embodiments, database 202 includes data, related data structures, and database management software. For example, database 202 can be implemented using well-known database management systems including, for example, Microsoft SQL, Oracle, IBM DB2, etc. Note that in some embodiments, database 202 (or at least a portion of the data stored therein) can be stored in memory 203 and / or another memory device accessible to memory 203 and processor 201. For example, in one embodiment, database 202 (or at least a portion of the data stored therein) can be stored in the memory of a third-party server, such as a server of a cloud-based computing service that the injection management service has contracted with for the purpose of storing data.

[0038] In some embodiments, the data stored in database 202 may be stored across multiple databases. The sample data described herein as being useful in at least some embodiments is described as being stored in a single database 202 for simplicity purposes only. In some embodiments, one or more of data 204 - 212 may be stored as separate databases.

[0039] Examples of the types of data that can be stored in the database 202 include syringe data 204 that defines a syringe uniquely identifiable by the injection management system 200 (e.g., a syringe registered in the injection management system 200 for purposes of tracking, managing, and / or approving), and in the case of a pre-filled syringe, the fluid drug filled in the syringe. Examples of such syringe data include the following (i) to (xi). (i) The unique serial number of the syringe (in some embodiments, including the unique serial number of an NFC chip or other chip attached to or otherwise associated with the syringe). (ii) The batch number of the fluid drug filled in the syringe. (iii) The lot identification number of the manufacturer of the fluid drug. (iv) The time and / or place of manufacture of the fluid drug and the syringe. (v) The type, category, and name of the fluid drug filled in the syringe. (vi) The expiration date of the fluid drug (if there is an expiration date). (vii) The strip ID number (e.g., if the syringe is manufactured and distributed as a strip of multiple syringes). (viii) The dosage or strength of the fluid drug. (ix) Information regarding the patient receiving the injection (e.g., whether the patient is a child or an adult). (x) One or more characteristics of the syringe (e.g., the information that the syringe is a 1.5 ml BFS vial). (xi) Other information desirable for identifying or tracking the unique ID syringe and / or the fluid drug filled therein (e.g., recall alerts). In some embodiments, the unique serial number may be a unique identifier that indicates other data (e.g., at least a part of the information described in (ii) to (x) above). In some embodiments, the syringe data 204 can be used as part of the injection approval process (e.g., to confirm that the syringe is not a counterfeit and that the fluid drug filled in the syringe is not subject to recall).

[0040] As another example of the types of data that can be stored in the database 202, in at least some embodiments described herein, patient data 206 that defines a patient registered in the injection management system 200 (for example, a person who has downloaded an injection management application to grasp the vaccines inoculated and the vaccine inoculation status for various infectious diseases) may be mentioned. Such patient data 206 can include at least one of the following (i) to (vi) in each patient record of the patient data 206. (i) Name. (ii) Contact information. (iii) Unique identifier (for example, one assigned by the injection management system or a third-party organization partnered with the injection management system to assist in managing injection event information regarding the patient). (iv) Login authentication information (for example, a username and password used when the patient logs in to the patient portal of the injection management application). (v) Medical history. (vi) Injection event status or vaccine inoculation status for various infectious diseases for which the patient has received (or not received) vaccinations.

[0041] In some embodiments, the injection management system 200 can enable various privacy levels associated with injection event transactions or a given digital receipt for vaccination. For example, in a first version or level of such a digital receipt, a patient can share a version of the digital receipt anonymously with a third party to check the vaccination status against a particular infectious disease. Such a version or privacy level of the digital receipt can show the patient's vaccination status and some information regarding vaccination (e.g., the date and location of vaccination) without providing personal identifying information (PII) about the patient. A second version or level of the digital receipt can include the patient's PII. In such embodiments, different permission requirements can be associated with 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 including the patient's PII in the digital receipt is shared with a third party). In such embodiments, different levels of the digital receipt (and, for example, different information shared with a third party under each), as well as the permission requirements corresponding to each level, can also be stored for each patient in the patient record of the patient data 206.

[0042] In some embodiments, the data defining the digital receipt of the injection event may be stored in the patient data 206. In another embodiment, an identifier of the digital receipt indicating another location where the digital receipt is stored may be stored in the patient data 206 (e.g., the injection event data 210, or a database or ledger of other digital receipt data stored separately from both the patient data 206 and the injection event data 210).

[0043] Another example of a different type of data that can be stored in the database 202 is the injector data 208 that defines the individuals registered as injectors in the injection management system 200. Such injector data can include, for at least one of the following (i) to (iv) for each record of the injector. (i) Name. (ii) Contact information. (ii) Unique identifier (e.g., assigned by the injection management system or a third party partnered with the injection management system to assist in injecting a patient using a syringe registered in the injection management system). (iv) Login authentication information (e.g., username and password used when a patient logs in to the injector portal of the injection management app). In some situations, a particular individual may be registered in the injection management system as both a patient and an injector, and in such cases, that individual needs to log in to the appropriate portal or platform (for patients or injectors) depending on the reason for logging in.

[0044] Yet another example of data that can be stored in the database 202 is the injection event data 210 that defines a list of injection events or injection event transactions recognized and recorded by the injection management system 200. In some embodiments, the injection event database includes an embodiment of the injection event transaction ledger, as described with respect to FIG. 1, or represents some or all of the same data stored in the injection event transaction ledger. In some embodiments, each record of the injection event data 210 can store information that defines a particular injection event that has been recognized and recorded (e.g., according to a method such as the injection management method 400 described with reference to FIG. 4). Examples of data recorded in the injection event data 210 include the following (i) to (xii). (i) Date and time of injection (note that in this specification, the terms "date", "time", and "date / time" are used interchangeably to refer to the date and time of the injection event). (ii) The location where the injection was administered (e.g., based on information provided by the injector and / or the patient. It may be information selected from a list of options, or information based on location information obtained from either or both of a GPS or a mobile device). (iii) Information or an identifier regarding the injector who administered the injection. (iv) An identifier of the patient who received the injection. (v) Information regarding the injection (e.g., the name, batch, lot number, etc. of the fluid drug administered). (vi) The expiration date of the injection (if there is an expiration date). (vii) The unique identifier of the syringe used in the injection event. (viii) A unique identifier of the transaction generated by the injection management system 200 when a new record of the injection event data 210 is opened (if different from the syringe identifier). (ix) A passcode (with an expiration period) generated after the administration of the injection has been confirmed (e.g., in accordance with the injection management method 400 of FIG. 4). (x) Information regarding the expiration date of the passcode, or whether the patient received the passcode before its expiration date. (xi) The injection status corresponding to the injection event (e.g., in the case of an injection of a vaccine valid for a predetermined period, the injection status can indicate whether the injection is currently considered valid / effective or expired). (xii) A digital receipt or a digital receipt identifier corresponding to the injection event. In some embodiments, the data defining the digital receipt of the injection event may be stored in the injection event data. In another embodiment, an identifier of the digital receipt indicating another location where the digital receipt is stored may be stored in the injection event data 210 (e.g., in the patient data 206, or in another database or ledger of digital receipts stored separately from both the patient data 206 and the injection event data 210).

[0045] Yet another example of data that can be stored in the database 202 is fluid drug data 212. The fluid drug data 212 can include data regarding a fluid drug filled in a syringe managed by the injection management system 200. In some embodiments, when administering a fluid drug to a patient, the injector can search and examine information regarding a specific fluid drug from the fluid drug data 212. In another embodiment, the fluid drug data 212 can be used as part of an injection approval process. Examples of information regarding the fluid drug that can be stored in the fluid drug data 212 include, but are not limited to, the following (i) to (v). (i) The disease treated / prevented by the fluid drug, or the name of the fluid drug. (ii) The manufacturer of the fluid drug. (iii) The components contained in the liquid preparation (e.g., for allergy and compatibility purposes). (iv) The distributor or contract manufacturer that produced the fluid drug. (v) The contact information of the pharmaceutical company or other representative who can provide additional information regarding the fluid drug, or the contact information for submitting concerns, complaints, questions, or problems corresponding to the fluid drug.

[0046] Note that the examples in this specification showing what types of information are included in what types of data are not intended to be limiting. Various changes are possible, such as what types of information to store in what types of data, combining different types of data, and storing some information in multiple types of data.

[0047] The injection management system 200 can further include one or more software modules or engines for causing the processor 201 to execute specific functions. In some embodiments, software components, applications, routines or subroutines, or instruction sets for causing one or more processors to execute specific functions are referred to herein as "modules" or "engines". It should be noted that such modules, engines, or other software or computer programs referred to herein (including an injection management application downloaded to the user's mobile device to facilitate communication with an injection management service via the injection management system 200, etc.) can be described in any computer language, and can be part of a monolithic codebase, or, as is common in object-oriented computer languages, can also be developed with more discrete code portions. Additionally, the modules, engines, or any software or computer programs referred to herein can, in some embodiments, be distributed across multiple computer platforms, servers, terminals, etc. For example, a certain module may be implemented such that the functions described herein are executed by separate processors and / or computing hardware platforms.

[0048] Any of the software modules or computer programs shown in FIG. 2 may be part of a single program or may be integrated into various programs for controlling the processor 201. It should be understood that, further, any of the software modules or computer programs shown in FIG. 2 may be stored in a compressed, uncompiled, and / or encrypted form and may include instructions that cause the processor 201 to operate in accordance with at least some of the methods described herein when executed by the processor 201. Of course, additional and / or different software modules or computer programs may be included, and it should be understood that the examples of software modules illustrated and described with respect to FIG. 2 are not essential in any embodiment. The use of the terms “module” or “engine” does not mean that the functions described in connection therewith are embodied as a stand-alone or independently functioning program or application. In some embodiments, the functions described with respect to a particular module may be able to function independently, but in other embodiments, such functions are described with respect to a particular module for ease of explanation or convenience only, and such functions may actually be part of another module, program, application, or set of instructions integrated for instructing a processor of a computing device.

[0049] In one embodiment, any or all of the instructions of the software modules, engines, or programs described with respect to FIG. 2 can be read from another computer-readable medium into main memory, for example, from ROM to RAM. By executing the instruction sequences within the software modules, engines, or programs, the processor 201 executes at least some of the method steps described herein. In another embodiment, instead of or in combination with the software instructions for implementing the method steps of the embodiments described herein, hardwired circuitry may be used. Accordingly, the embodiments described herein are not limited to a particular combination of hardware and software. Non-limiting examples of software modules that can be utilized in the injection management system 200 include (i) an injection management engine 220, (ii) an approval module 222, (iii) an injection event transaction log module 224, and (iv) an injection status module 226.

[0050] In the exemplary embodiment shown in FIG. 2, the injection management engine 220 is illustrated as communicating with (i) an approval module 222, (ii) an injection event transaction log module 224, (iii) an injection status module 226, and (iv) a database 202. Accordingly, the injection management engine 220 can access the data within the database 202 and perform some of the functions and embodiments described herein by itself or by providing such data to one or more of the modules 222-226. Such a configuration is shown as an example of how to access, modify, and utilize the data in the database 202.

[0051] Generally, injection management engine 220 and modules 222 - 226 are to be understood as being accessible to processor 201 in order to implement one or more of the embodiments described herein, regardless of how they are specifically arranged within injection management system 200. As described above, one or more of engine 220 and modules 222 - 226 can utilize at least some of the data stored in database 202. Further, in some embodiments, one or more of engine 220 and modules 222 - 226 can be transmitted to database 202 to search, manipulate, select, update, modify, and / or determine data stored in database 202.

[0052] In some embodiments, injection management engine 220 can manipulate the data in database 202 to execute or facilitate one of the following function examples (i) - (iv). (i) Approving an injection from a uniquely identifiable syringe (e.g., approving based on information received from an injector via the injector portal of the injection management application on the injector's mobile device (e.g., node devices 102a - n of FIG. 1)). (ii) Storing a record of a fluid agent injected or administered by an injection administrator using the injection management system 200. (iii) Generating a digital receipt or other information indicating that a patient has received an injection and outputting it to that patient via the patient's mobile device (e.g., node devices 102a - n of FIG. 1). (iv) Providing proof that a patient has received an injection or administration of a fluid agent managed by the injection management system 200 in an efficient, electronic, secure, and verifiable manner.

[0053] In one embodiment, the injection management engine 220, or another component of the injection management system 200, can output information to a user such as a patient or an injection performer registered in the injection management system 200 via one or more graphical user interfaces (GUIs) of the injection management application as described herein (and can also receive input or data such as an identifier of a syringe, information verifying that an injection has been successfully performed, or a passcode for confirming that an injection has been successfully performed from such a user). Examples of such GUIs will be described with reference to FIGS. 3A to 3L. Also, an example of a process of receiving information from a user such as an injection performer or a patient and outputting information to the user will be described with reference to FIG. 4.

[0054] The interface of the injection management application may take the form of a web server that transmits data in HTML, XML, or other well-known formats using well-known transmission protocols such as HTTP or TCP / IP. Also, an exclusive protocol or data format may be used. FIGS. 3A to 3L show the types of information that can be output to or collected from a user via an injection management application capable of interfacing with the injection management system 200, and non-limiting examples of such output and collection processes.

[0055] Referring to FIGS. 3A-3L and FIG. 4, FIG. 4 shows an exemplary injection management method 400 that provides one embodiment of some of the functions of the injection management system described herein, and FIGS. 3A-3L show examples of GUIs that can be utilized in such an injection management method 400. The injection management method 400 can be implemented, for example, by an injection management system 200 (FIG. 2). In some embodiments, the injection management method 400 may be implemented and / or carried out by one or more special computers and / or specially programmed computers (e.g., the processor 201 of FIG. 2), or may be otherwise associated. With respect to the injection management method 400 and all other methods described herein, not all of the steps described with respect to the method are essential in all embodiments, and in some embodiments those steps may be carried out in a different order, and in some embodiments additional or alternative steps may be used.

[0056] Here, the injection management method 400 will be described with reference to FIGS. 3A-3L, which show examples of a plurality of GUIs that can be presented to a user (who can be an injector or a patient as described herein) during the progress of an injection event transaction. FIGS. 3A-3L show examples of GUIs that can be output to a user's mobile device (e.g., the node devices 102a-102n of FIG. 1). The GUIs of FIGS. 3A-3L include an app (a software application that operates on a mobile device) or a tab, screen, or page of a particular version, portal, or platform thereof (e.g., one screen is a screen of an injector portal that is output when the user signs in as an injector, and another screen is a screen of a patient portal that is output when the user signs in as a patient). Note that many variations of such graphical user interfaces can be implemented (e.g., the arrangement of menus and elements is changed, graphics and functions are added). The graphical user interfaces of FIGS. 3A-3L are shown in a simplified form to focus on the particular embodiments and functions described herein.

[0057] First, referring to FIG. 3A, FIG. 3A shows a GUI 300A that can be output via a mobile device of a user in which an injection management application is installed. This GUI 300A can be a sign-in screen that is displayed to the user each time the injection management application is launched or opened. In one embodiment, the application may include different portals / platforms for different types of users such as patients and injection administrators. In such an embodiment, the user is first required to select whether to sign in as an injection administrator (in which case the user selects the option shown in region 302a of GUI 302A) or to sign in as a patient (in which case the user selects the option shown in region 302b of GUI 302A). In another embodiment, different users may be made to use different applications, in which case the user only launches the application corresponding to their role (for example, the injection administrator accesses the first application and the patient accesses the second application. In this case, there is no need to select the type of user on the launch screen). For the purpose of explaining the embodiments shown in FIGS. 3A - 3L, the user who is an injection administrator and the user who is a patient are pre-registered in the injection management system 200, and thus the injection management system 200 can recognize the user (for example, data corresponding to the user is stored in the patient data 206 and / or injection administrator data 208 of the injection management system 200 in FIG. 2), and it is assumed that the user has sign-in authentication information recognized by the injection management system 200 (the process of registering the user in the injection management system is understood by those skilled in the art and will not be described in detail herein for the sake of brevity).

[0058] Next, referring to FIG. 3B, FIG. 3B shows an example of the GUI 300B presented to a user who is an injection performer (it is shown in the area 304a of the GUI 300B that the user is an injection performer). To access the functions of the injection management service as described herein using the injection management application, the user inputs a username and password, or other authentication information required by the injection management service. In some embodiments, the username may be a unique identifier assigned to the user (for example, assigned to the user by the injection management service or a third-party organization partnered with the injection management service to assist members or participants of the injection management service or the third-party organization in managing injection events). In some embodiments, additional security measures (such as two-factor authentication) may be incorporated to verify the identity of the user signing into the injection management application.

[0059] Next, referring to FIG. 3C, FIG. 3C shows an example of the GUI 300C output to the injection performer to show the process of the injection event transaction (and the current status (situation) in that process). An injection event is an event of performing an injection (administering a fluid drug) to a patient (for example, an event where a patient receives an inoculation of a specific vaccine). An injection event transaction is an activity in which a patient receiving an injection and the injection management service (or an injection performer acting on behalf of the injection management service) participate, and the patient receives the injection and a digital receipt thereof. The digital receipt provides information that the injection management service can track and store records of the patient who received the injection (for example, the digital receipt includes a unique identifier that enables the injection management system 200 to identify the patient as described herein, and a passcode that enables the injection management system 200 to confirm that the patient was administered a specific fluid drug via a unique ID syringe). By recording the transaction according to the embodiments described herein, both the patient and the injection management system can access and confirm that the injection event was performed in an efficient and secure manner after the injection event is performed.

[0060] As shown in FIG. 3C, in some embodiments, the process of an injection event transaction includes the following (i) to (iii). (i) Registering to perform an injection (administration of a fluid agent) (assuming that the fluid agent in the examples of FIGS. 3A - 3L is a vaccine, it is shown as "Registration of vaccination" and step 1 in region 306a). (ii) Receiving confirmation from the patient that the fluid agent has been administered (shown as "Patient confirmation" and step 2 in region 306a). (iii) Storing a provable record of the injection event (shown as "Record vaccination" and step 3 in region 306a). The description of the injection management method 400 with reference to FIG. 4 provides some exemplary manners of implementing each step of such a process of an injection event transaction.

[0061] In some embodiments, when each step of this exemplary process is completed, the injection implementer's application displays information indicating that the step has been completed successfully (e.g., displayed using a check mark or other visual aids). In the screen of GUI300C, a check mark is illustrated next to each step, but until the completion of that step is confirmed, it is displayed that the step is incomplete (e.g., by not having a check mark, being grayed out, or using other visual aids).

[0062] Next, with reference to FIG. 4, the injection management method 400 starts at step 402 when the start of an injection event transaction including the reception of a syringe identifier is recognized by an injection management system (e.g., injection management system 200). In some embodiments, the reception of a patient identifier or other patient check - in process may be performed before step 402 (e.g., an injection implementer or a related person may perform a standard reservation check - in process before the injection event substantially starts).

[0063] The start of an injection event transaction can be recognized, for example, based on a unique syringe identifier received from an injector via an injection management application. An example of a GUI or interface for the injector to send or provide a unique syringe identifier is shown as GUI300D in FIG. 3D. As described herein, each syringe managed by an injection management service is provided with or associated with a data storage mechanism such as an NFC chip, an RFID chip, a QR code (registered trademark), a barcode, etc., which can be read by sensors of a mobile device on which an injection management application is installed. Such a data storage mechanism stores a unique identifier that uniquely identifies the syringe. In the embodiment shown in FIG. 3D, the data storage mechanism is an NFC chip, and the injector is required to input the unique identifier of the syringe used by the injector to perform an injection on a patient by holding the syringe near the injector's mobile device or tapping (contacting) the syringe (or a specific part of the syringe such as a label area where the NFC chip is disposed) on the mobile device. In embodiments where the data storage mechanism is other than an NFC chip, the user may be required to input the unique syringe identifier in different ways as needed. For example, the user may be required to scan a QR code (registered trademark) or a barcode on the syringe, or the user may be required to hold a syringe equipped with an RFID chip in proximity to an RFID antenna capable of reading information from the RFID chip (in this case, the RFID antenna reads the unique syringe identifier from the RFID chip and transmits it to the injector's mobile device and / or an injection management system to proceed with the injection event transaction).

[0064] When an injection event transaction is initiated and a unique syringe identifier is received, at step 404, the unique identifier is authenticated (e.g., authenticated as genuine), and the use of the syringe corresponding to the unique identifier is approved (permitted). For example, information associated with the syringe identifier is obtained and an approval process is carried out (e.g., to confirm that the syringe is not expired, has not been used previously, is not subject to recall, and / or is not otherwise prohibited from use in other respects). In some embodiments, the functionality described with respect to step 404 can be at least partially implemented by the approval module 222 (FIG. 2).

[0065] In one embodiment, at step 404, when a syringe identifier is received, the syringe identifier is used to access data related to the syringe (as described with respect to FIG. 2). For example, a record of syringe data 204 is accessed by the injection management system 200, one or more fields are reviewed by a program or module (e.g., the approval module 222), and it is confirmed that there are no conditions that would cause the syringe to be prohibited from use by the injection practitioner (e.g., it is confirmed that the syringe is not subject to recall. Also, if the syringe data has the syringe identifier, it can be presumed that the syringe is legitimate). In some embodiments, the injection management system may output information regarding the syringe and / or the fluid drug filled in the syringe to the injection practitioner via a GUI (not shown) as part of the syringe approval process. For example, the injection practitioner may be required to confirm that specific information printed or embossed on the syringe or its label matches the information stored in the database associated with the syringe identifier provided by the injection practitioner.

[0066] In some embodiments, authentication of the syringe identifier and approval of syringe use may include additional information or considerations (i.e., step 404 can include additional steps, and / or the approval module 222 can perform additional authentication). For example, in some embodiments, a BFS vial or other type of syringe includes a vaccine vial monitor (VVM) such as an environmental monitoring mechanism (e.g., a strip attached to the syringe). In some embodiments, the VVM includes a thermochromic label affixed to a vial containing a vaccine or other fluid agent. The thermochromic label visually indicates whether the vaccine or other fluid agent has been kept within the temperature range in which it maintains its potency. This thermochromic label is designed to address the problem that when delivering vaccines to developing countries where it is difficult to maintain and track environmental characteristics (e.g., heat and cold during vaccine storage), the vaccine may be inactivated due to being exposed to an inappropriate temperature (e.g., a temperature that is too cold for the vaccine) and thus the effect of vaccination cannot be obtained. In some embodiments, the VVM includes a measure of the cumulative amount of heat or cold to which the vial to which it is attached has been exposed after leaving the manufacturing facility. If the vial is exposed to an unacceptable temperature for an unacceptable period of time, the label turns black. The black label indicates that the vaccine or other fluid agent in the vial is no longer good and should not be injected. In another embodiment, a more expensive digital VVM can be utilized to track similar ambient temperature information.

[0067] In some embodiments where the syringe comprises a VVM, the NFC chip or other components of the syringe can include an optical chip monitor capable of reading the output of the VVM (e.g., whether the VVM label has changed color to black). For example, the user opens an appropriate injection management app on the mobile device, taps the vial equipped with the NFC chip and / or the optical chip monitor on the mobile device (or holds the mobile device (or the camera of the mobile device) over the VVM), and the app reads an indicator as to whether the vaccine is good or whether the vaccine can be used based on the output of the VVM. In another example, the user opens an appropriate injection management app on the mobile device, takes a photo of the output of the VVM, and the app may be programmed (or a server communicable with the app may include a processor capable of executing an appropriate program) to determine whether the fluid medicament in the vial is suitable for use based on the output of the VVM. In any example, when it is determined based on the output of the VVM that the use of the fluid medicament is appropriate, as described above with respect to providing the injector with information indicating approval (permission) to use the syringe or the right to inject the fluid medicament, the injection management app outputs to the user information or a display approving the use of the syringe (e.g., displays an indicator such as a green button or light on the screen of the injection management app). As an example, the applicant contemplates that the vial is provided with a simple optical monitor capable of communicating with the VVM or monitoring the state of the VVM such that when the VVM label (or indicator of the digital VVM) changes color to black (or indicates that the fluid medicament has been exposed to an unacceptable temperature), a signal or information indicating that the fluid medicament is no longer usable or that use is not permitted is generated. In this case, the optical monitor transmits the above signal or information to the NFC chip and / or the injection management app, causing the NFC chip and / or the injection management app to determine that the fluid medicament in the vial should not be permitted for injection into the patient.

[0068] When the injection management system confirms that the syringe identifier is genuine and determines that there is no other information that would cause the use of the syringe to be unauthorized, the syringe is considered registered or authenticated if it is so certified. This includes, for example, creating a record of the injection event transaction (e.g., opening a new record of the current injection event transaction in the database of the injection management system 200 (e.g., the injection event data 210 of FIG. 2) and / or generating a unique transaction identifier for the injection event transaction). Further, when the syringe is authenticated and its use is approved, it is considered that step 1 of the process shown in FIG. 3C is completed, and visual information indicating this is output to the injection operator via the GUI300C (e.g., a checkmark is output next to step 1, or step 2 is highlighted or activated). In some embodiments, additional visual, audible, and / or tactile information is output to the injection operator to indicate that the use of the syringe has been approved and that the injection operator should proceed with the injection into the patient (e.g., symbols or other visual information (e.g., checkmarks, green lights, thumbs up or completed circles), sounds, or vibrations are output via the GUI of the injection management application).

[0069] If the authentication of the syringe identifier fails or if the injection management system 200 determines not to approve the injection, a message indicating the failure of injection approval, such as an error or warning, is output to the injection operator via the GUI of the injection management application. For example, the injection operator may receive information indicating that a recall has been issued for the syringe (in which case, the injection operator discards the recalled syringe and attempts to authenticate another syringe). Also, the injection operator may receive a notification indicating that the reading of the syringe identifier is invalid (in which case, the injection operator attempts to re-enter the syringe identifier by tapping the syringe on the mobile device again, scanning the QR code (registered trademark) or other code again, or manually entering the syringe code).

[0070] In step 404, assuming that the injection identifier is successfully authenticated and the use of the fluid drug filled in the syringe is approved, the injection management system 200 waits for the injection implementer to provide information indicating that the fluid drug filled in the syringe identified in step 402 has been administered to the patient. In some embodiments, at this point in the injection management method 400, the injection management system 200 may not identify the patient receiving the injection, while in other embodiments, it should be noted that a patient identifier may be provided to the injection event transaction record (e.g., by the injection implementer or the patient). When the injection management system 200 receives confirmation (e.g., from the injection implementer) that the injection to the patient has been successfully performed (step 406), a unique passcode is generated and output to the injection implementer via the GUI of the injection management application (step 408). An example of outputting such a passcode to the injection implementer is shown in the example of GUI300E (Figure 3E). Although a 6-digit numerical passcode is illustrated in region 310a of GUI300E, passcodes of any length or type can be utilized.

[0071] For the purpose of transmitting to the patient who received the injection, by generating a passcode, the injection management system 200 enables the patient to prove that they received the injection event using the passcode and further provide data to the injection management system as part of the injection event transaction (the generation of the passcode may be performed locally by a module of the injection management application or remotely by a server device such as server device 110 with which the user's mobile device communicates via the injection management application). In some embodiments, the injection implementer may show or read aloud the passcode output to the injection implementer's mobile device to the patient. In some embodiments, the passcode may be output in the form of a QR code (registered trademark) or other form directly readable by the patient's mobile device.

[0072] In some embodiments, an expiration date may be set for the passcode such that the passcode is only valid until the expiration date. In some embodiments, if it takes the patient more time to receive and use the passcode, a new passcode may be generated based on a request from the injector. In some embodiments, the generated passcode is stored in association with the injection event transaction (e.g., in the injection event data 210 and / or in a different injection event transaction ledger). In some embodiments, the generated passcode may be sent to a device other than the injector's mobile device. For example, in some embodiments, the passcode may be sent directly (e.g., via text) to the patient based on the contact information pre-stored in association with the patient identifier provided prior to the performance of the process related to the injection event. In another example, the passcode may be sent to another server device (e.g., the management device 106 of FIG. 1).

[0073] When the passcode is generated in step 408, it is considered that step 2 of the process illustrated in FIG. 3C is completed, and visual or other information indicating this completion is output to the injector via the injector portal of the injection management app (e.g., the GUI 300E is updated to indicate the completion of step 2). When the passcode is output, the injection management system 200 waits for the passcode input from the patient.

[0074] In some embodiments, when scheduling an injection event, the patient logs into the patient portal of the injection management app (e.g., by selecting the "Patient" option in region 302b of GUI300A and then entering appropriate sign-in authentication information in region 304b of GUI304B). After logging into the injection management app (and in some embodiments, after selecting the appropriate "Injection Confirmation" option of the app), the patient is prompted to enter a passcode provided by the injector after the injection is administered. An example of GUI300F (FIG. 3F) shows an example of an interface that prompts the patient to enter a passcode. The patient can proceed to confirm having received the injection by entering the passcode in region 312a of GUI300F. In some embodiments, the patient may be prompted to provide other information related to the transaction of the injection event (e.g., to confirm the date and time when the patient received the injection and / or the fluid medication administered to the patient). When the injection management system 200 receives the passcode (and other confirmation information or inputs) from the patient (step 410), the injection management system 200 records that the injection event has been successfully completed (step 412).

[0075] In some embodiments, the injection management system 200 requires additional steps or the injection provider to perform an input in order to consider the injection event as authenticated and determine that the injection event transaction has been successfully authenticated and / or completed. For example, in some embodiments, after the injection management system receives a passcode from the patient's mobile device, the injection provider is required to re-enter their password (via the injection provider app on the injection provider's mobile device) in order to confirm their identity and "sign off" on the successful completion of the injection. FIG. 3H shows an example of a GUI that requests the injection provider to enter a password or other authentication information via area 316a to confirm the injection. In some embodiments, the injection provider's input of such a password or other authentication information serves as a digital "signature" on the injection event record by the injection provider. Other ways to enable the injection provider to "sign" the injection event record include the injection provider entering a code via a token or NFC chip for this purpose provided to the injection provider (e.g., the injection management app may communicate a unique identifier for the purpose of confirming the presence and identity of the injection provider via the NFC chip or other mechanism). In some embodiments, such a token or other item can similarly be used for the injection provider to log in to the injection provider portal of the injection management app.

[0076] After receiving the passcode from the patient, receiving confirmation or authentication of the success of the injection record from the injector serves to fulfill step 3 of the process of the injection management application, as shown in the exemplary GUI300C. Further, in some embodiments, the injector is required to actively confirm the successful completion of the injection event by selecting "store" or a similar option via the injection management application, as illustrated in the exemplary region 318a of the GUI318I of FIG. 3I. By enabling the injector to actively "store" and indicate completion of the injection event, the injection management system 200 can cause the injector to review and confirm other information collected by the injection management system 200 about the injection event of the injection event transaction record by outputting it to the injection event provider (as illustrated, for example, in the example of the GUI300I).

[0077] Also, in some embodiments, the injection management system 200 can verify the passcode entered by the patient into the patient portal of the injection management application by (i) verifying that the passcode received from the patient in step 410 matches the passcode output to the injection administrator in step 412, and (ii) verifying that the passcode was received before its expiration date. While the injection management system 200 is authenticating the passcode entered by the patient (and, in some embodiments, while the injection management system 200 is waiting for the injection administrator's input, which serves as the "signature" of the injection event record), the patient's injection management application outputs information indicating a waiting authentication state (e.g., as shown in region 314b of the exemplary GUI 314G of FIG. 3G). When the authentication process is complete (e.g., based on the injection administrator providing a password or other code or input to verify the injection administrator's identity and providing data to sign in to the injection event, and, in some embodiments, adding information indicating that the injection event is complete), the patient's injection management application outputs an updated state regarding the injection event or injection (e.g., if the injection is a vaccine, outputs a "vaccinated" state, the vaccine name, and / or the name of the infectious disease for which the vaccine was received). The example of the GUI 300J of FIG. 3J shows one manner of outputting such an updated state to the patient.

[0078] Note that some or all of the functions described herein with respect to steps 402-412 can be performed by the approval module 222 (FIG. 2) and / or the injection event transaction log module 224 (FIG. 2). For example, the injection event transaction log module 224 serves to update an update regarding an injection event transaction or transmit the updated data to another device (e.g., node devices 102a-n and / or the management device 106) so that the other device can update the record of the injection event transaction. On the other hand, the approval module 222 serves to verify or authenticate such an update / data.

[0079] In some embodiments, receiving a passcode from the patient at step 412 also serves to identify and / or authenticate the patient participating in the injection event transaction. For example, in some embodiments, the passcode received from the patient via the patient portal of the injection management app may be received as a data packet containing information about the patient's unique identifier (e.g., the patient signs in to the patient portal of the injection management app, enters the passcode, and provides it to the injection management system 200 via the app and displays it in area 314a of the GUI 300G). The injection management system 200 may identify the patient based on comparing the passcode received from the patient with the passcode generated as part of an open injection event transaction and output to the injection implementer, and add the patient identifier to the injection event transaction record of the transaction. In some embodiments, as part of the process of step 412, the injection event transaction record may be updated with the patient identifier.

[0080] In some embodiments, when an injection event is completed and the transaction is considered to be successfully recorded in one or more records (step 412), additional data is generated in the form of a digital receipt of the injection event and sent to the patient's mobile device (step 414). In some embodiments, such transmission of data / digital receipt enables the patient portal of the injection management app to display a "vaccinated" or similar status indicating that the patient has received an injection of the corresponding liquid medicine. In some embodiments, the digital receipt includes data such as the date of administration of the injection and the expiration date. For example, in some situations, the injection may not be considered valid until a certain period (e.g., two weeks) has elapsed since the patient received the injection. In another example, the injection may only be valid for a certain period (e.g., one year). In such cases, the digital receipt may be configured to automatically update the patient's status regarding the injection (e.g., the patient's vaccination status for a particular vaccine) in the injection management app based on a comparison between the current time and the effective time and / or expiration date of the injection. For example, if the injection is only valid for one year after it is administered to the patient, when the patient logs in to the patient portal of the injection management app after the expiration date, the status of the injection may be displayed as "expired". An example of such a status and how it is displayed for a particular vaccine is shown in the GUI 300L of FIG. 3L.

[0081] As described herein, in some embodiments, the injection management system enables various privacy levels associated with injection event transactions or a given digital receipt for vaccination. For example, in a first version or level of such a digital receipt, a patient can share that version of the digital receipt with a third party anonymously to check the vaccination status for a particular infectious disease. Such a version or privacy level of the digital receipt can indicate the patient's vaccination status and some information regarding vaccination (e.g., the date and location of vaccination) without providing personal identifying information (PII) about the patient. A second version or level of the digital receipt can include the patient's PII. In such embodiments, different permission requirements can be associated with 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 including the PII of the digital receipt is shared with a third party). In such embodiments, the different levels of the digital receipt (and, e.g., the different information shared with a third party under each) and the permission requirements corresponding to each level are also stored for each patient in the patient record of the patient data 206. In some embodiments, public-key encryption may be employed to enable the patient to control the disclosure of specific secret information related to the digital receipt for an injection.

[0082] In some embodiments, the injection management system of the present invention can output a code (e.g., a QR code (registered trademark)) or other means that can share or "flip" proof that a patient is currently vaccinated against a specific infectious disease or is receiving the administration of a specific fluid drug in another way. The injection status module 226 (FIG. 2) can (i) track and update the status (situation) of a patient regarding the injection of a specific fluid drug, and (ii) generate a code or permission for the patient to share the injection status with a third party (e.g., receive a permission requirement or decryption password from the patient and disclose a digital receipt or a specific level or data of the digital receipt to an approved third party).

[0083] In some embodiments, the injection management system 200 requires the injector to provide additional information or data during an injection event before considering the injection event transaction to be completed and authenticated. In an exemplary embodiment, the injection management system 200 may request the injector 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., at step 406) or before considering the injection event transaction to be successfully recorded (e.g., at step 412). FIG. 3K shows an example of such an embodiment. In this example, the GUI 300K-1 of the injector portal requests the injector to upload a visual confirmation of the patient's presence and image via area 320a, and the GUI 300K-2 displays the uploaded visual confirmation as part of the patient confirmation process in area 322a.

[0084] In some embodiments, before completing an injection event, in addition to the injector, a supervisor or other third party may be required to confirm. The exemplary embodiment shown in FIG. 3K shows how such an embodiment is implemented by providing an input mechanism for the supervisor's sign-off (approval) (as part of step 3 of GUI 300K-1 and in area 322b of GUI 300K-2).

[0085] In some embodiments, the NFC chip or RFID chip can be a read-only chip. In another embodiment, the NFC chip or RFID chip can be a writable chip that can add information in addition to reading. In some embodiments, the NFC chip or RFID chip can be a passive chip that does not include its own power source and is powered by a reader device (e.g., the user's mobile phone) or other mechanism that exists outside the NFC chip.

[0086] In an embodiment (or another embodiment) where the NFC chip or RFID chip is a writable chip, power for the chip may be required. In one embodiment, the power source is provided in the syringe. In one embodiment, the power source is embedded in the BFS vial (e.g., as part of an extrusion process, a capacitor is embedded in the BFS vial). Other examples of power sources that can be used to power the NFC chip or RFID chip include, but are not limited to, the following (i) to (v). (i) Power generated by the user squeezing or pressing the BFS vial to inject the fluid drug into the vial. (ii) Power generated by the user shaking the BFS vial. (iii) Power from a light source or solar cell included in the BFS vial. (iv) Power generated by the use of the piezoelectric effect and / or materials. (v) Electric power from external light obtained by holding the device under a natural light source such as sunlight or a lighting light source (for example, in an embodiment of a plastic vial, a sunlight conversion chemical substance or material is embedded in the plastic of the vial, and by shining light on the vial, a very low microvolt trickle charge can be provided to the associated battery or capacitor). It should be understood that in many embodiments, the amount of electric power required in many of the embodiments described herein may be very small (for example, it may be 1 or 2 microvolts, or a fraction of a microvolt).

[0087] In some embodiments, an NFC chip or an RFID chip may malfunction, run out of battery, be damaged, or at least partially become inoperable, making it impossible to rewrite the information stored in the chip or write or store additional information in the chip. In some embodiments, the capabilities of the NFC chip or RFID chip are limited (for example, the maximum number of times or the maximum period during which information can be written or rewritten to the chip is limited). Therefore, in some embodiments, it is desirable for the NFC chip or RFID chip to have a function of confirming that the information the user attempts to write or rewrite to the chip has been successfully written or rewritten. All information communicated with the NFC chip or RFID chip should be encrypted or protected, or include a security element, so as to be protected from unauthorized access in at least some embodiments.

[0088] In some embodiments, the NFC chip or RFID chip may be equipped with a GPS or location tracking function. For example, the NFC chip or RFID chip may output or transmit the GPS coordinates of its location (e.g., output the GPS coordinates periodically, aperiodically, in response to an inquiry from a sensor, or in response to another condition being met). In some embodiments, the GPS or location tracking function provided for the NFC chip or RFID chip detects and / or stores information such as the current or past location of the vial corresponding to the NFC chip or RFID chip (e.g., where it was, for how long, and where it is currently) (or provides the information to another device so that the other device (such as the user's mobile device) can detect and / or store it using a corresponding software application).

[0089] In some embodiments, the functionality of the NFC chip or RFID chip is tested during the manufacturing process after the NFC chip or RFID chip is embedded in the BFS vial, and if it is determined that it does not function properly or the function parameters are outside the desired range, the vial is discarded or sent to a dedicated processing process. Thus, in one embodiment, the manufacturing process may include the following (i) to (vi). (i) Adding an NFC chip or RFID chip to the vial (e.g., embedding the NFC chip or RFID chip in plastic in a plastic extrusion manufacturing process, or attaching the NFC chip or RFID chip under the cap of a glass vial or to another part of the glass vial). (ii) Filling and sealing the vial with a fluid drug. (iii) Testing to confirm whether the NFC chip or RFID chip is functioning within acceptable parameters (e.g., testing whether the unique identifier stored in the chip can be read properly). (vi) (a) If the test of the NFC chip or RFID chip is successful, the vial is advanced to the first manufacturing route (e.g., packaged and sold as a unique ID syringe), or (b) if the test of the NFC chip is not successful, the vial is advanced to the second manufacturing route (e.g., discarded or sold as a non-NFC chip vial).

[0090] In some embodiments, an inkjet or other printer may print information of the NFC identifier or RFID identifier of the NFC chip or RFID chip embedded in or attached to the vial or a component of the vial. The information of the NFC identifier or RFID identifier may be in a human-readable format (e.g., alphanumeric code), or may be in a machine-readable format (e.g., barcode or QR code (registered trademark)). The information of the NFC identifier or RFID identifier may be printed directly on the vial or a component of the vial (e.g., the cap in the case of a glass vial), or may be printed on a label and pasted on the vial or a component of the vial. Thus, in such embodiments, the above manufacturing process further includes (v) reading the NFC identifier or RFID identifier of the NFC chip or RFID chip embedded in the vial, and (vi) printing the NFC identifier or RFID identifier on the vial by a printing device (either directly printing or printing on a label and pasting on the vial).

[0091] In some embodiments, a user (e.g., a patient receiving an injection of a fluid medicament in a vial) can obtain a reward for a qualified use (self-injecting the vaccine / drug in the vial within an appropriate time window after being approved by the app) by using a unique ID syringe in combination with an injection management app. In one embodiment, an end user (the user self-injecting the vaccine / drug with the syringe) downloads an injection management app to their smartphone so that the user can obtain a reward (e.g., additional time for phone use, additional data for a data plan, payment of money, etc.) based on a qualified use of the vial. (In another embodiment, the user may not need to download the app, and an offline method for authenticating use may be implemented on the smartphone.) For example, the user can obtain additional call time by tapping the vial on the smartphone within a qualified time window (e.g., within the time window in which the user is supposed to self-inject the vaccine / drug filled in the syringe based on the treatment regimen stored in the app). When the user taps the syringe within the qualified time window, additional call time or another reward can be obtained. (In some embodiments, as described herein, the injection may need to be further approved by the app based on information such as whether the fluid medicament filled in the syringe has expired or whether the VVM status of the syringe is acceptable.)

[0092] In some embodiments where the user is prescribed a multiple-injection regimen, the reward value may be based on how well the user adheres to the multiple-injection regimen. For example, in certain diseases or conditions, multiple self-injections may need to be performed at a given interval. In such a situation, the user can obtain a reward based on "completion of the game". The user can obtain a relatively large reward if they adhere to all of the required injections, but only a small reward if they adhere to only some, but not all, of the injections.

[0093] Thus, in some embodiments, the injection management service can effectively assign an identifier to a particular fluid medicament (e.g., a particular vaccine) in a way that cannot easily change the relationship between the particular fluid medicament and the unique identifier of an NFC chip or RFID chip embedded in or attached to the syringe in which the fluid medicament is filled, at the time the syringe is manufactured or when the syringe is filled with the fluid medicament. This provides many advantages, such as tracking the time / location at which a particular fluid medicament is injected into a patient and allowing the injector to easily confirm that the fluid medicament filled in the syringe is the intended one (e.g., by using an injection management app to read the unique identifier of the NFC chip or RFID chip of the syringe before the injection is administered and having the app authenticate / approve the fluid medicament).

[0094] In some embodiments, the NFC chip or RFID chip is operable to provide a periodic, aperiodic (e.g., triggered by a specific event or randomly), or continuous GPS tracking history of the chip / syringe location (the GPS tracking history may be stored in the NFC chip or RFID chip, or may be stored in a cloud and / or server communicable with the NFC chip or RFID chip and / or the mobile device that has downloaded the injection management app). Additionally, the NFC chip or RFID chip can communicate with the VVM, store photos or information indicating the state of the VVM, or store information used to determine the state of the VVM. This VVM status data may be stored locally in the NFC chip or RFID chip, or may be stored elsewhere (e.g., in a cloud and / or server communicable with the NFC chip or RFID chip and / or the mobile device that has downloaded the injection management app). Thus, in some embodiments, the NFC chip or RFID chip can know one or more of the following (i)-(iv) regarding the syringe and the fluid drug filled therein. (i) Where it is currently. (ii) Where it has been in the past. (iii) What temperatures it has been exposed to during a long journey. (iv) The elapsed time since the manufacturing date.

[0095] In some embodiments, the injection management app (via the NFC chip) and / or the NFC chip or RFID chip itself can recognize various data provided by the user, regardless of whether the user is the injector, patient, or other user, and store and / or transfer the data to a server or other device. For example, as described in this specification, a user who injects a fluid drug into a patient from a syringe compatible with an NFC chip or an RFID chip, or a user who self-injects a fluid drug, taps the vial on a mobile device before performing the injection so that the data stored in the NFC chip or the RFID chip can be read and processed by an app. For example, the app can authenticate the following (i) to (iii) (based on information about the patient known to the app). (i) The syringe is filled with the appropriate fluid drug. (ii) The timing of the injection is appropriate. (iii) The fluid drug is still suitable for injection (e.g., the VVM does not indicate exposure to an inappropriate temperature, the expiration date associated with the syringe does not exceed the expiration date of the fluid drug, there is no recall associated with the vial, the vial has not been stolen, etc.). In some embodiments, the user may be required to take a photo of the vial and / or the injection site during the injection (in some embodiments, the user can receive a reward for providing this information). In some embodiments, the user may be required to use the app to provide information about side effects or reactions to the fluid drug (e.g., answer one or more questions, upload a photo of the injection site or related side effects) (also, in some embodiments, the user can receive a reward for providing such information).

[0096] In some embodiments, the user is provided with call time or mobile payment for providing specific information to the app or following specific injection requirements (e.g., following an injection regimen for the treatment of diabetes or tuberculosis) tracked by the app. Examples of such rewards include, but are not limited to, call time and mobile payment (e.g., micropayment). Such rewards can be provided to individual users (e.g., patients) or groups of users (e.g., to a family account of a family associated with the mobile device storing the app).

[0097] In some embodiments, an injection management application can be used to communicate with and follow up on a user (e.g., a patient who has received an injection, or a caregiver or family member of that patient). For example, text messages or app reminders can be sent to the user's mobile device to notify the user to perform self-injection of a fluid drug again according to a regimen. In another example, the user may be asked via text messages or app reminders to send information about the reaction or side effects to the injection.

[0098] Note that in some situations, users may dislike receiving text messages or reminders that clearly indicate that the message or reminder is for an injection or specify the type of injectable / fluid drug that the user needs to inject. For example, a user may feel embarrassed if such types of messages or reminders are seen by other users (this can be particularly problematic if the user is receiving reminders or messages on a family-shared mobile device). Thus, in some embodiments, the messages or reminders may be concealed or coded so that they do not explicitly indicate that they are related to an injection or the injection they are referring to.

[0099] In some embodiments, particularly in the case of self-injection by a user who is not the injector, it may be desirable to know how much of the fluid drug filled in the syringe has actually been injected into the patient. Thus, for example, a comparison of the refractive index before and after the injection may be obtained and reported using the injection management application. In another example, a flow meter of the valve level (of a one-way valve of the delivery mechanism) may be compared before and after the injection to measure the amount of fluid drug delivered.

[0100] In some embodiments, it may be desirable to confirm that the injection of the fluid drug from the unique ID syringe has actually been administered to a human or at least an animal (e.g., to confirm that it has not been expelled into the air in order to obtain a reward associated with the injection). Therefore, for example, it may be required to measure the backpressure during injection or to input into the app a photo of the injection site taken during or before and after the injection.

[0101] In some embodiments, the function or operation of the one-way valve that constitutes the delivery mechanism attached to the NFC chip or RFID chip-enabled syringe may be controlled by the NFC chip or RFID chip. For example, in some embodiments (e.g., as a means of preventing the injection of the fluid drug filled in a stolen NFC chip or RFID chip-enabled syringe), the unique ID syringe is first tapped on a mobile device that has the injection management app open, and the app opens the one-way valve and permits the outflow of the fluid drug only when it has authenticated the syringe and confirmed that it has not been stolen or is suitable for use. The app transmits a communication to the NFC chip or RFID chip, or another component of the syringe (e.g., a gate or obstacle related to the valve) and permits the opening of the valve only when it has confirmed the permission to use the syringe.

[0102] In some embodiments (e.g., in embodiments where the NFC chip or RFID chip, or another component of the syringe communicates bidirectionally), the syringe may be configured to broadcast location information such as the current GPS coordinates (e.g., periodically or aperiodically). In some embodiments, the NFC chip or RFID chip, or another component of the syringe, may be configured to place a call or send a text if it is determined that it is in an unapproved or unexpected location, or simply to communicate its location information. In yet another embodiment, the NFC chip or RFID chip, or another component of the syringe, may be queried remotely if it is necessary to determine its location. All of the above are useful for preventing the theft of the syringe and for tracking the syringe.

[0103] This specification describes that eligible or approved injections from a proprietary ID syringe can be tracked via an app on the user's mobile device, but it should be noted that the mobile device is not essential for any of the embodiments described herein. Another device may be used to track the user's injections (for example, a SIM card or other electronic card that can directly store information about the user's injections or store an identifier that refers to a cloud-based database storing information about the user's injections may be provided to the user).

[0104] Interpretation Rules

[0105] Although various embodiments are described, these are presented for illustrative purposes only. The described embodiments are not intended to be limiting in any sense. The present invention is widely applicable to various embodiments, as will be readily apparent from the disclosure herein. These embodiments are described in sufficient detail so that those skilled in the art can practice the invention. It should also be understood that other embodiments may be utilized and structural, logical, software, electrical, or other changes may be made without departing from the scope of the invention. Thus, those skilled in the art will recognize that the invention can be practiced with various modifications and changes. Certain features of the invention are described with reference to one or more specific embodiments or drawings that form a part of this disclosure, and specific embodiments of the invention are shown by way of example, but it should be understood that such features are not limited to their use in the one or more specific embodiments or drawings in which they are described. Accordingly, this disclosure is not an exact description of all embodiments of the invention nor a list of features that must exist in all embodiments of the invention.

[0106] The terms "embodiment", "some embodiments", "exemplary embodiments", "at least one embodiment", "one or more embodiments", and "an embodiment" mean, unless otherwise explicitly stated, "one or more embodiments of the present invention (not all of which are essential)".

[0107] The term "including" (comprising) and its variations mean, unless otherwise explicitly stated, "including but not limited to".

[0108] The term "consisting of" and its variations mean, unless otherwise explicitly stated, "including but not limited to".

[0109] The listed items do not mean that any or all of them are mutually exclusive. The listed items do not mean, unless otherwise explicitly stated, that any or all of them collectively cover something. The listed items do not mean that they can be ordered in any way according to the listed order.

[0110] When a list of items follows the term "comprising at least one of", it does not mean that the components or sub-components of each listed item are essential. Rather, it means that one or more of the listed items may constitute the specified item. For example, the statement "A comprises at least one of a, b, and c" means that (i) A can include a, (ii) A can include b, (iii) A can include c, (iv) A can include a and b, (v) A can include a and c, (vi) A can include b and c, (vii) A can include a, b, and c.

[0111] The terms "a", "an", and "the" mean "one or more" unless otherwise explicitly stated.

[0112] The term "based on" means "at least based on" unless otherwise specified.

[0113] The methods described herein (regardless of whether they are referred to as methods, processes, algorithms, calculations, etc.) essentially include one or more steps. Accordingly, all references to "steps" of such methods have the prior description in the mere description of the term "method" or similar terms. Accordingly, references to "steps" of a method in a claim are considered to have sufficient prior description.

[0114] The headings and titles of the sections described herein are for convenience only and do not limit the present disclosure in any way.

[0115] Devices that communicate with each other do not necessarily need to communicate with each other continuously unless otherwise specified. Additionally, devices that communicate with each other may communicate directly or indirectly via one or more intermediary mechanisms.

[0116] The description of embodiments in which a plurality of components communicate with each other does not mean that all such components are required, or that each disclosed component needs to communicate with all other components. On the contrary, various optional components are described to illustrate various possible embodiments of the present invention.

[0117] Also, even when process steps, method steps, algorithms, etc. are described sequentially, such processes, methods, algorithms may be configured to be performed in a different order. In other words, the order of the steps described in this specification does not indicate a requirement that the steps be executed in that order. The steps of the methods described in this specification may be executed in a practical order. Further, even though some steps are described or implied not to be executed simultaneously (for example, because one step is described after another step), they may be executed simultaneously. Furthermore, the description of the processes shown in the drawings does not mean that the described processes exclude other variations and modifications thereof, that any of the described processes or steps thereof is essential to the present invention, or that the described processes are preferred.

[0118] It will be readily understood that the various methods and algorithms described in this specification can be implemented, for example, by a suitably programmed general-purpose computer or computer device. Generally, a processor (e.g., a microprocessor or a controller device) receives instructions from a memory or a storage device and executes those instructions to perform the processes defined by those instructions. Further, programs implementing such methods and algorithms can be stored and transmitted using various known media.

[0119] It will be readily understood that when a single device or article is described in this specification, a plurality of devices or articles (regardless of whether they cooperate) may be used instead of the single device or article. Similarly, it will be readily understood that when a plurality of devices or articles are described in this specification (regardless of whether they cooperate), a single device or article may be used instead of the plurality of devices or articles.

[0120] The functions and / or features of the device may alternatively be embodied by one or more other devices that do not explicitly describe having such functions / features. Accordingly, another embodiment of the present invention need not include the device itself.

[0121] As used herein, the term "computer-readable medium" refers to any medium involved in providing data (e.g., instructions) that can be read by a computer, a processor, or a similar device. Such media include, but are not limited to, various forms such as non-volatile media, volatile media, and transmission media. Examples of non-volatile media include, for example, optical disks, magnetic disks, and other permanent memories. Examples of volatile media generally include dynamic random access memory (DRAM) that constitutes main memory. Examples of transmission media include coaxial cables, copper wires, and optical fibers, including wires or other paths that make up the system bus connected to the processor. The transmission media can include or transmit sound waves, light waves, and electromagnetic radiation generated during data communication at high frequency (RF) or infrared (IR). General forms of computer-readable media include, for example, floppy disk (registered trademark), flexible disk, hard disk, magnetic tape, other magnetic media, CD-ROM, DVD, other optical media, punch card, paper tape, other physical media having hole patterns, RAM, PROM, EPROM, FLASH (registered trademark)-EEPROM, other memory chips or cartridges, carrier waves described later, or other media that can be read by a computer.

[0122] Various forms of computer-readable media can be involved in transmitting a sequence of instructions to a processor. For example, the sequence of instructions can be (i) distributed from RAM to the processor, (ii) transmitted via a wireless transmission medium, or (iii) formatted according to various forms, standards, or protocols such as Transmission Control Protocol, Internet Protocol (TCP / IP), Wi-Fi (registered trademark), Bluetooth (registered trademark), TDMA, CDMA, and 3G.

[0123] When a database is described, those skilled in the art will understand that (i) it is possible to easily adopt a database structure that replaces what is described, and (ii) it is possible to easily adopt other memory structures other than the database. The schematic diagram and description of the sample database presented in this specification are exemplary configurations for a configuration for storing information. Various other configurations can be adopted in addition to those shown. Similarly, the exemplified entries in the database represent only exemplary information. Those skilled in the art will understand that the number and content of the entries may be different from those shown in this specification. Furthermore, although the database is described as a table, other forms (including relational databases, object-based models, and / or distributed databases) may be used to store and manipulate the data types described in this specification.

[0124] Similarly, the process of the present invention can be implemented using the object method or operation of the database. In addition, the database may be stored locally or remotely from a device that accesses the data in such a database in a known manner.

[0125] For example, as an alternative to the database structure for storing information, a hierarchical electronic file folder structure can be used. In this case, a program can be used to access the appropriate information in the appropriate file folder within the hierarchy based on the file path specified by the program.

[0126] Also, as long as the terms described in the claims are referred to in a manner that is consistent with a single meaning elsewhere in this specification, it should be understood that this is done merely for clarification and is not intended to limit such terms implicitly or in any other way to that single meaning.

[0127] In a claim, a limitation of a claim that includes the phrase "means for" or "step of" means that 35 U.S.C. § 112(f) applies to that limitation.

[0128] In a claim, a limitation of a claim that does not include the phrase "means for" or "step of" means that 35 U.S.C. § 112(f) does not apply to that limitation, regardless of whether the limitation recites a structure, material, or act for performing that function. For example, simply using the phrase "step of" in a claim when referring to one or more steps of that claim or other claims does not mean that 35 U.S.C. § 112(f) applies to that step.

[0129] With respect to a means or step for performing a particular function in accordance with 35 U.S.C. § 112(f), the corresponding structures, materials, or acts described herein, and their equivalents, can perform not only the particular function but also additional functions.

[0130] Products such as computers, processors, and computing devices are structures that can perform various functions. Such products can perform a particular function by executing one or more programs, such as a program stored in a memory device of the product or a program stored in a memory device accessible by the product. Unless otherwise specified, such programs need not be based on a particular algorithm, such as a particular algorithm disclosed in the present application. A particular function can also be implemented using different algorithms, and it is well known to those skilled in the art that any of the various algorithms is merely a design choice for performing a particular function.

[0131] Accordingly, with respect to means or steps for performing a particular function in accordance with 35 U.S.C. § 112(f), the structure corresponding to the particular function includes a product programmed to perform the particular function. Such structure includes a programmed product that performs the function regardless of whether such product is programmed by (i) the disclosed algorithm for performing the function, (ii) an algorithm similar to the disclosed algorithm, or (iii) a different algorithm for performing the function.

[0132] Although 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 apparent to those skilled in the art upon reading this specification.

Claims

1. The step in which an electronic processing device of an injection management system recognizes a first injection event transaction, where the recognition of the first injection event transaction is performed based on the electronic processing device receiving information regarding the administration of a fluid drug to a patient via an injector implementation platform of an injection management application stored in a first mobile device of a first user, the information including first data including a unique identifier of a syringe filled with the fluid drug, the first user has pre-signed in to the injector implementation platform of the injection management application stored in the first mobile device by providing first user authentication information that enables the electronic processing device to uniquely identify the first user and recognize the first user as a registered injector, this step, the step in which the electronic processing device approves the administration of the fluid drug based on the unique identifier of the syringe, the step in which the electronic processing device generates a first injection event record by generating an electronic record unique to the first injection event transaction, the step in which the electronic processing device receives, from the first mobile device of the first user via the injection management application, information indicating that the administration of the fluid drug to the patient has been performed, the step in which the electronic processing device generates a first passcode having an expiration date in response to receiving the information indicating that the administration of the fluid drug to the patient has been performed, and stores the first passcode in association with the first injection event record, the step in which the electronic processing device displays the first passcode on the first mobile device of the first user via the injection management application, the step in which the electronic processing device receives the first passcode from a second mobile device of a second user before the expiration date of the first passcode has passed, The second user provides second user authentication information that enables the electronic processing device to uniquely identify the second user and recognize the second user as a registered patient, and thereby signs in advance to the patient platform of the injection management application stored in the second mobile device via the second mobile device corresponding to the second user. The first passcode is input from the second user via the patient platform of the injection management application. This step, Based on the electronic processing device receiving the first passcode from the second mobile device of the second user, the step of determining that the second user is a patient who received administration of the fluid drug from the syringe by the first user as part of the first injection event transaction. The step of the electronic processing device updating the first injection event record to indicate that the second user received administration of the fluid drug. The step of the electronic processing device transmitting a digital receipt of the first injection event record, which is to be stored in the patient platform of the injection management application of the second mobile device of the second user, to the second mobile device of the second user as confirmation that the second user received administration of the fluid drug. A method comprising.

2. The method according to claim 1, wherein the digital receipt includes a unique digital receipt identifier corresponding to the first injection event record, and the unique digital receipt identifier is for enabling the second user to communicate with the injection management system via the patient platform of the injection management application and check the vaccination status of the second user based on the data stored in the first injection event record. A method.

3. The method according to claim 1, The method further includes the step of the electronic processing device displaying, via the injection management application, a message indicating that the injection has been approved on the first mobile device of the first user before receiving the information regarding the administration of the fluid drug to the patient.

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

5. The method according to claim 1, wherein the digital receipt includes at least one of (i) information about the fluid drug, (ii) an identifier of the syringe, (iii) the date and time when the fluid drug was administered, (iv) the location where the fluid drug was administered, (v) an identifier of the second user, and (vi) an identifier of the first user who administered the fluid drug.

6. The method according to claim 5, wherein the digital receipt includes code that can be displayed on the second mobile device of the second user via the graphical user interface of the patient platform of the injection management application in response to a request from the second user, the code indicating to the second user that the fluid drug has been administered and being readable by an external electronic device outside the injection management system.

7. The method according to claim 5, wherein the digital receipt includes information at a plurality of privacy levels that can be shared with a third party, each of the privacy level information corresponding to the respective permission requirements of the second user, and in order to share information at a certain privacy level of the digital receipt with a third party, the second user needs to provide the permission requirements corresponding to the information at that privacy level.

8. The method according to claim 7, wherein the information at the first level in the plurality of privacy level information is information regarding that the fluid drug has been administered to the second user, corresponding to anonymous information that does not identify the second user who received the fluid drug, and the information at the second level in the plurality of privacy level information is information regarding that the fluid drug has been administered to the second user, corresponding to information that identifies the second user who received the fluid drug.

9. The method according to claim 1, The fluid agent includes a vaccine against a specific infectious disease that is effective for a predetermined period from the date and time of administration, and the second user is considered to have received vaccination against the specific infectious disease for the predetermined period. The digital receipt further includes an expiration date of the fluid agent based on the predetermined period, and the electronic processing device indicates, via the patient platform of the injection management application, that the second user has received vaccination against the specific infectious disease until the expiration date of the fluid agent. A method of displaying a confirmation to the second mobile device via a graphical user interface of the patient platform.

10. The method according to claim 1, The step of receiving the information indicating that the administration of the fluid agent to the patient has been performed includes receiving a photo of the second user taken during the first injection event transaction. The step of transmitting the digital receipt to the second mobile device of the second user includes transmitting a copy of the photo of the second user to the second mobile device of the second user and storing it in association with the digital receipt. Method.

11. The method according to claim 10, A method, wherein a copy of the photo of the second user is stored in association with the first injection event record.

12. The method according to claim 1, The method further includes a step in which the electronic processing device obtains information on the fluid agent and the administration of the fluid agent from a database accessible to the electronic processing device based on the unique identifier of the syringe.

13. The method according to claim 12, The step of approving the administration of the fluid agent based on the unique identifier of the syringe includes confirming that the administration of the fluid agent is valid and the administration of the fluid agent has been approved based on the information on the fluid agent and the administration of the fluid agent. Method.

Images