Patent Description:
In the medical field, the use of replaceable pharmaceutical product containers with standardized medical devices is generally known. In an example, a replaceable container that accommodates a pharmaceutical product to be administered to a patient may be inserted into an administration device so that the pharmaceutical product may be administered from the container to the body of the patient. The administration device may be an injection device, such as a syringe, for example, and the container may be a replaceable injection cartridge that contains a drug to be injected to the patient. In another example, a corresponding pharmaceutical product container may be used in connection with a reconstitution device for the purpose of preparing a liquid or lyophilized solution specifically adapted to the medication requirements of the patient and, hence, for subsequent administration.

Although pharmaceutical product containers are typically labeled in a clear manner to indicate to the user (e.g., a clinician or the patient) information regarding the pharmaceutical product and its proper use, it may still happen that the user confuses the container and applies it with a wrong medical device or, even worse, to the wrong patient, hence, potentially leading to non-adherence of use instructions given. Thus, in situations in which a pharmaceutical product is specifically prepared for a dedicated patient or, otherwise, in situations in which the pharmaceutical product is to be used in combination with a dedicated medical device, it is generally desired to prevent the user from unintended use of the container.

Patent application <CIT> discloses a medication infusion safety device for assuring an application of a correct medication to a patient which comprises a memory means adapted to be provided at a medication reservoir containing a medication and to store data identifying said medication, a memory reading means adapted to be provided at an infusion pump unit and to read data from said memory means, and control means adapted to control an infusion in accordance with an evaluation of data read by said memory reading means so that only in case the evaluation leads to the result that the medication is correct it causes the infusion from said medication reservoir to be started, wherein said memory reading means is adapted to read data from said memory means through direct wireless connection. Patent application <CIT> relates to management of information relating to medical fluids, containers therefor, and medical fluid administration devices for administering such medical fluids to patients. Data tags (e.g., RFID tags) are associated with the containers and may be electromagnetically read from and/or written to using an electromagnetic device, for example, that may be associated with a medical fluid administration device.

<CIT> concerns a method and apparatus for a connection interface between a reservoir or syringe, infusion set tubing, and an infusion pump. The reservoir, a base and a cap are connected to form an integrated unit that is capable of being inserted and secured in an infusion pump housing. The cap and the infusion pump are each provided with at least one sensor or at least one detectable feature, arranged to interact with at least one corresponding detectable feature or sensor on the other of the cap and infusion pump device, to detect one or more of the presence, position or other characteristic of the cap when the cap is aligned or coupled with the infusion pump housing. The document <CIT> does not disclose: a) the device types of the medical device including a syringe type, an automated injection device type, a patch pump device type, and a reconstitution device type; b) the pairing-specific information comprising an identification of the medical device as well as at least one control parameter, wherein the identification of the medical device and the at least one control parameter are specific to a device type of the medical device; and c) verifying whether the medical device is one of the plurality of medical devices for which pairing-specific information is stored in the memory of the container and whether the container is thus permitted to be used by the medical device.

It is an object of the present disclosure to provide techniques that assist in ensuring that a pharmaceutical product and its container are correctly applied.

Further aspects of the invention are defined by the dependent claims.

According to aspects of the present disclosure, a system for use of a pharmaceutical product, a container accommodating a pharmaceutical product, and a medical device for use of a pharmaceutical product accommodated in a container are provided according to the independent claims. Preferred embodiments are recited in the dependent claims.

According to a first example of the present disclosure, a system for use of a pharmaceutical product is provided. The system comprises a container accommodating a pharmaceutical product. The container comprises a wireless communication unit and a memory which stores pairing-specific information for one or more medical devices. The system further comprises a medical device enabled for wireless communication with the wireless communication unit of the container and configured to read the pairing-specific information from the memory of the container to verify whether the container is permitted to be used by the medical device.

The pairing-specific information is information which enables the medical device to confirm whether the container is allowed to be used in combination with the medical device or, in other words, to confirm whether the container may be paired with the medical device. In this way, it may be checked whether the container is paired with the right medical device before effectively using the pharmaceutical product contained in the container in a medical procedure and, hence, wrong use of the pharmaceutical product may be prevented. Further, since the memory of the container stores pairing-specific information for more than one medical device, the container is prepared to interface with not only one, but with a plurality of medical devices. A system is thus achieved in which a universal container may be used in combination with a suite of dedicated devices. Performing the verification ensures that the medical device is one of the one or more medical devices for which pairing-specific information is stored on the memory of the container.

The medical device may be configured to block use of the pharmaceutical product until the verification is complete. If it is confirmed that the container may be paired with the medical device (hereinafter denoted as a "positive confirmation"), the medical device may release the block so that the medical device may proceed with the intended medical procedure. On the other hand, in case it is determined that the container may not be paired with the medical device (hereinafter denoted as a "negative confirmation"), the medical device may maintain the block and thus prevent use of the pharmaceutical product in the container in a medical procedure with the medical device. In either case, an indication of the result of the verification may be provided by the medical device, e.g., via text form on a display, through an audible output, or through dedicated visual indicators, such as LEDs, provided at the medical device.

The medical device may store pairing-specific information in a memory of the medical device itself in order to be able to perform the verification. Performing the verification may include comparing the pairing-specific information stored in the memory of the container with the pairing-specific information stored by the medical device. The medical device may decide on a positive confirmation if the pairing-specific information stored in the memory of the container and the pairing-specific information stored by the medical device match. It will be understood, however, that other ways of performing the verification, rather than such a simple match, are generally conceivable.

In certain variants, the pairing-specific information stored in the memory of the container may comprise, for each of the one or more medical devices, at least one of an identification of the respective medical device, an identification of a user to which the respective medical device is assigned, and at least one control parameter for controlling a function specific to the respective medical device. It will be understood that these examples are non-limiting and that any other type of information which enables the medical device to perform the verification may be used as the pairing-specific information.

The pairing-specific information stored in the memory of the container comprises an identification of the medical device (e.g., a device ID), therefore the medical device may compare the identification to a corresponding identification (e.g., a device ID) stored on the medical device and decide on a positive confirmation, if both identifications match. In this case, the verification may be used to ensure that the container is used with the right medical device. Similarly, in case the pairing-specific information stored in the memory of the container comprises an identification of a user to which the medical device is assigned (e.g., a patient ID), the medical device may compare the identification to a corresponding identification (e.g., a patient ID) stored on the medical device and decide on a positive confirmation, if both identifications match. In this case, the verification may be used to ensure that the pharmaceutical product is used for the right patient. Further, the pairing-specific information stored in the memory of the container comprises at least one control parameter for controlling a function specific to the medical device. The at least one control parameter may be necessary for the medical device to configure its own operation. If the medical device is an automated injection device, the at least one control parameter may be used by the injection device to configure the injection speed of the pharmaceutical product from the container, for example.

In one variant, which does not fall under the scope of protection by the claims, the identification of the medical device and/or the at least one control parameter may be specific to the medical device, i.e., specific to a particular instance of a medical device type. In this case, the container may be used in combination with a dedicated device only. The medical device types include a syringe, an automated injection device, a patch pump device and a reconstitution device. The identification of the medical device and the at least one control parameter are specific to a device type of the medical device, i.e., specific to all instances of a medical device type. The container may be used in combination with any device of a dedicated medical device type.

The wireless communication unit of the container may be a passive wireless communication unit. In one variant, the wireless communication unit may be a Near Field Communication (NFC) unit and may comprise an RFID tag, for example. If the container comprises a label, the wireless communication unit and/or the memory may be included in the label. The medical device may be an NFC enabled device which is configured to read the pairing-specific information from the memory of the container via NFC. It will be understood that other types of wireless communication technologies are conceivable for the same purpose. It is even conceivable that the wireless communication unit may be an active unit, given that corresponding power supply is provided. It will also be understood that the medical device may not only read from the memory of the container, but may also write to the memory of the container, e.g., to set or update certain information stored in the memory of the container (examples for this will be given further below).

The pairing-specific information stored in the memory of the container may be defined by the manufacturer of the pharmaceutical product and may be written to the memory of the container at an initial stage of the lifecycle of the pharmaceutical product and the container. The pairing-specific information stored in the memory of the container may also be written to the memory of the container at a later stage in the lifecycle of the pharmaceutical product, such as when the container is handed over to a patient in a pharmacy, for example. The same applies to the pairing-specific information stored on the medical device. The pairing-specific information stored on the medical device may be defined by the manufacturer of medical device and may be written to the memory of the medical device at the time of manufacturing. The pairing-specific information stored on the medical device may also be written to the memory of the medical device at a later stage, such as when the medical device is handed over to a patient in a pharmacy, for example. This may particularly be the case, when the medical device is a device for one-time use, such as a one-time use syringe or other injection device which is to be disposed after a single use, for example.

For the purpose of writing into the memory of the medical device, the medical device may comprise a communication unit. The pairing-specific information may in this case be written from an external configuration device to the medical device via the communication unit. The communication unit may be a passive wireless communication unit, e.g., an NFC unit included in the medical device. The external configuration device may be an NFC enabled device which is configured to write the pairing-specific information to the memory of the medical device via NFC. It will be understood that other types of communication technologies (both wired and wireless) are conceivable for the same purpose.

Further than storing pairing-specific information, the memory of the container may also be employed to store additional information which may be relevant to the pharmaceutical product accommodated in the container. In one such variant, the memory of the container may store a usage scheme specifically adapted to the pharmaceutical product accommodated in the container, wherein the usage scheme specifies at least one usage-related parameter to be adhered to in using the pharmaceutical product. The medical device may be configured to read the usage scheme from the memory of the container and to perform a medical procedure in accordance with the usage scheme. The at least one usage-related parameter may be defined by the manufacturer of the pharmaceutical product and may be written to the memory of the container at an initial stage of the lifecycle of the pharmaceutical product and the container. The at least one usage-related parameter may also be written to the memory of the container at a later stage in the lifecycle of the pharmaceutical product, such as when the container is handed over to a patient in a pharmacy, for example.

When the use of the pharmaceutical product corresponds to an administration of the pharmaceutical product to a patient and the medical device is an administration device, the usage-related parameter may be an administration-related parameter. Performing the medical procedure may in this case comprise performing administration of the pharmaceutical product in accordance with the at least one administration-related parameter. The administration-related parameter may relate to a prescription instruction directed to ensure proper administration of the pharmaceutical product to the patient. This may include a general usage instruction for the pharmaceutical product applicable to every patient using the pharmaceutical product or a specific usage instruction prescribed by a physician to a particular patient.

For example, the at least one administration-related parameter may comprise at least one of a prescribed dosage of the pharmaceutical product, a prescribed date and/or time at which the pharmaceutical product is to be administered, a prescribed frequency and/or interval at which the pharmaceutical product is to be administered, a prescribed route of administration according to which the pharmaceutical product is to be administered, and a prescribed location and/or geographical region at which the pharmaceutical product is to be administered.

Among these parameters, the prescribed dosage of the pharmaceutical product may indicate the amount or volume (e.g., in units of ml, mg, etc.) of the pharmaceutical product to be administered, the prescribed frequency and/or interval may indicate the number of doses to be applied as well as a corresponding interval (e.g., hour, day, week, month, etc.) according to which the pharmaceutical product is to be administered, the prescribed route of administration may indicate the way through which the pharmaceutical product is to be administered to the body of the patient (e.g., oral, rectal, intra-arterial, intra-muscular, etc.), and the prescribed location may correspond to a particular treatment center at which the pharmaceutical product is to be administered, for example. The at least one administration-related parameter may be used by the administration device (or a user thereof, e.g., the patient or a clinician) to verify that the pharmaceutical product is administered at the right time, with the right dosage and/or at the right location and, therefore, assist in ensuring that the given prescription instructions are strictly adhered to.

In a variant, the administration device may be an automated administration device, i.e., an administration device which is configured to automatically administer (e.g., upon activation) the pharmaceutical product to the patient when the container is inserted in, or otherwise connected with, the administration device. An automated administration device may verify the at least one administration-related parameter before administering the pharmaceutical product to the patient. If the verification of the at least one administration-related parameter fails (e.g., the right time, the right dosage and/or the right location could not be confirmed), the administration device may refuse to perform the administration and may output a corresponding indication to the user. In one particular example, the administration device may be an (e.g., automated) injection device, wherein performing the administration may comprise injecting the patient with the pharmaceutical product. The container may in this case be an injection cartridge, for example.

Once the pharmaceutical product (or a portion thereof) has been used in a medical procedure (e.g., has been administered to the patient), usage-related information may be stored on the memory of the container in order to keep track of the usage performed. The memory of the container may thus further store usage-related information about the pharmaceutical product accommodated in the container, wherein the usage-related information may include at least one of a date of first use of the pharmaceutical product, a number of uses of the pharmaceutical product, and a remaining amount of the pharmaceutical product in the container. The medical device may for this purpose be configured to write corresponding data to the memory of the container. If the medical device is an administration device, the usage-related information may be written to the memory of the container upon completing an administration operation. For example, if an automated administration device has completed administering a portion of the pharmaceutical product from the container to the patient, the remaining volume of the pharmaceutical product left in the container may be written to the memory of the container so that the container is kept up-to-date regarding its fill volume. When the container is used the next time with the administration device (or another administration device), the respective administration device may verify if sufficient volume is available in the container to meet the prescribed dosage specified by the administration scheme, for example.

The memory of the container may further store non-usage-related information about the pharmaceutical product accommodated in the container. Non-usage-related information about the pharmaceutical product may be information which does not specifically relate to (e.g., prescribed) usage instructions for the pharmaceutical product, but which provides information about the product itself. For example, non-usage-related information about the pharmaceutical product may include at least one of a unique identification of the pharmaceutical product, a certificate of authenticity of the pharmaceutical product, at least one storage condition for the pharmaceutical product, an expiry date of the pharmaceutical product, an identification of a manufacturer of the pharmaceutical product, an identification of a physician who prescribed the pharmaceutical product, an identification of a distributor of the pharmaceutical product, and an identification of a batch in which the pharmaceutical product was produced.

Among this information, the unique identification of the pharmaceutical product may comprise a product name or another identifier uniquely identifying the pharmaceutical product. The certificate of authenticity may be used by the medical device (or a user thereof, e.g., the patient or a clinician) to verify the genuineness of the pharmaceutical product and, as such, contribute to preventing fraud, tampering or counterfeiting with regard to the pharmaceutical product. The at least one storage condition for the pharmaceutical product may comprise indications regarding to the temperature (e.g., minimum/maximum temperature) and/or humidity (e.g., minimum/maximum humidity) at which the pharmaceutical product is to be stored. The manufacturer identification, the physician identification, the distributor (e.g., pharmacy or pharmacist) identification and the batch identification of the pharmaceutical product may be used to track the lifecycle of the container and may be used by the medical device (or a user thereof, e.g., the patient or a clinician) to verify details about the pharmaceutical product accommodated in the container. The medical device may further comprise one or more sensors (or may be configured to communicate with one or more remote sensors) in order to verify that the at least one storage condition is satisfied. To enable traceability of the container, the memory of the container may further store a unique identifier for the container.

The memory of the container may also store at least one file containing additional information about the pharmaceutical product and/or a link to a website providing additional information about the pharmaceutical product. The at least one file may comprise a document (e.g., a PDF document) or a multimedia file (e.g., a movie file), for example. The website may contain information about the pharmaceutical product which is not stored (or cannot be stored due to memory limitations) in the memory of the container itself. For example, the at least one file and/or the website may provide a more detailed product description, e.g., including illustrative images of the product, more detailed usage and prescription instructions (e.g., using illustrative movies), detailed information about the manufacturer, or the like.

In order to provide improved data security, the usage scheme may be stored in the memory of the container in an access protected manner. In one such variant, access to the usage scheme may be password protected. Thus, if a user (e.g., the patient or a clinician) wants to read the usage scheme from the memory of the container, the user may be prompted to enter a password at the medical device. Additionally or alternatively, the usage scheme may be encrypted in the memory of the container and the medical device may have a decryption key for decrypting the usage scheme. In a further variant, only selected portions of the usage scheme may be access protected. Access protection may be defined differently for read and write operations. It will be understood, that equivalent access protection may also be provided for the pairing-specific information, the usage-related information and the non-usage-related information stored in the memory of the container.

In a refinement of the system, the system may further comprise a remote server. The medical device may be configured to communicate with the remote server via wireless communication, preferably WLAN or Bluetooth communication. The remote server may reside in a cloud computing environment, for example, and may be accessible by the medical device through the Internet. Communication between the medical device and the remote server may be secured, e.g., using security protocols such as SSL, TLS, or the like.

The remote server may be used to implement various supplemental services associated with the usage of the pharmaceutical product. In one such variant, the remote server may host supplementary usage-related information accessible by the medical device. For example, the remote server may store additional usage-related parameters which are not stored (or cannot be stored due to memory limitations) in the memory of the container itself. If the medical device is an administration device, the administration device may download one or more additional administration-related parameters from the remote server and apply these parameters when performing administration of the pharmaceutical product accordingly.

Further, the medical device may be configured to exchange at least part of the data stored in the memory of the container with the remote server. In one variant, the medical device may replicate the data stored on the memory of the container (or parts thereof) on the remote server. The exchanged data may be used by the remote server to provide additional services to a user (e.g., the patient or a clinician). For example, the remote server may be configured to notify, based on an analysis of the data stored on the remote server, a user of an upcoming usage (e.g., administration) to be performed according to the usage scheme (e.g., administration scheme). Such notifications may be transmitted in the form of reminders or alarms to a user's end device, such as to the user's pager or smartphone. In another example, the remote server may be configured to report a status relating to the container and/or the medical device upon request by the user. Such report may allow the user to check the status of an ongoing usage (e.g., administration), to check the result of a completed usage (e.g., administration), to track a therapy session, or to track the entire adherence history, for example. The data stored in the remote server may also be aggregated and shared with a caregiver or healthcare provider (HCP). In another example, the data in the remote server may be stored in an electronic patient record. In an electronic patient record, further patient-related information may be stored, such as other drugs prescribed to the patient, for example. Based on the information stored in the electronic patient record, it is generally conceivable to perform an analysis and generate an alert, if one or more drugs prescribed to the patient are incompatible, for example.

In a further variant, the medical device may be instructed by the remote server to write data to the memory of the container, e.g., in order to update at least one usage-related parameter of the usage scheme or to update other data stored in the memory of the container. As an example, if it is encountered that a batch in which the pharmaceutical product was produced has been recalled due to a production fault, the remote server may instruct the medical device to write data into the memory of the container marking the container as unusable so as to prevent further use of the container. The requirement for recalling the container may be identified through the batch identification stored in the memory of the container or the remote server, respectively. If the medical device is an administration device, the administration device may be configured to verify if the container is marked as unusable and block any administration of the pharmaceutical product from the container accordingly.

In another variant, the remote server may be used as the external configuration device described above and may thus be employed to store pairing-specific information, such as a patient ID, on the medical device.

According to a second example of the present disclosure, a container accommodating a pharmaceutical product is provided. The container comprises a wireless communication unit and a memory which stores pairing-specific information for one or more medical devices. The pairing-specific information enables a medical device to verify, via wireless communication with the wireless communication unit of the container, whether the container is permitted to be used by the medical device.

According to a third example of the present disclosure, a medical device for use of a pharmaceutical product accommodated in a container is provided. The container comprises a wireless communication unit and a memory which stores pairing-specific information for one or more medical devices. The medical device is enabled for wireless communication with the wireless communication unit of the container, and the medical device is configured to read the pairing-specific information from the memory of the container to verify whether the container is permitted to be used by the medical device.

Both the container according to the second example and the medical device according to the third example may correspond to the container and the medical device described above in relation to the system according to the first example. All features described above for the container and the medical device may apply to the container according to the second example and the medical device according to the third example as well. Unnecessary repetitions are thus omitted.

In the following, the present disclosure will further be described with reference to exemplary implementations illustrated in the figures, in which:.

It will be apparent to one skilled in the art that the present disclosure may be practiced in other implementations that depart from these specific details.

<FIG> illustrates an exemplary system <NUM> for use of a pharmaceutical product according to the present disclosure. The system <NUM> comprises a container <NUM> which accommodates the pharmaceutical product as well as a medical device <NUM> which, in the illustrated example, is an administration device for administering the pharmaceutical product accommodated in the container <NUM> to a patient. More specifically, the medical device <NUM> is provided as an automated injection device and the container <NUM> is provided as an injection cartridge which accommodates the pharmaceutical product in liquid form and which has a shape-coded cylindrical form so that it may be placed into a slide-in module <NUM> of the medical device <NUM> in a form fitting manner. When the container <NUM> is placed into the slide-in module <NUM> and slid into the medical device <NUM> (as shown in <FIG>), the medical device <NUM> may automatically dispense the pharmaceutical product from the container <NUM> and thereby administer the pharmaceutical product to the patient. The medical device <NUM> may comprise a drive mechanism for this purpose which may be configured to extend an injection needle to the outside of the device (for example at the bottom side of the medical device <NUM>, not shown) through which the pharmaceutical product may be injected into the body of the patient. The drive mechanism may be activated by pressing a button <NUM> of the medical device <NUM> when the bottom side of the medical device <NUM> lies flat against the body of the patient, for example.

The container <NUM> comprises a printed label <NUM> which is affixed around the outer circumference of the container <NUM> and which presents information about the pharmaceutical product accommodated in the container <NUM> (e.g., product name, batch number, expiry date, etc.). <FIG> shows an exemplary label <NUM> for illustrative purposes additionally in an un-affixed and unwound form below the container <NUM>. The label <NUM> comprises a Near Field Communication (NFC) unit <NUM> having an RFID antenna <NUM> which is integrated into the sheet of the label <NUM> so that it is not visible from the outside. For illustrative purposes, the NFC unit <NUM> is shown in <FIG> below the label <NUM> in a detached form. The NFC unit <NUM> comprises a memory <NUM> in which a usage scheme, more specifically an administration scheme, that is specifically adapted to the pharmaceutical product accommodated in the container <NUM> is stored. As described above, the administration scheme may specify at least one administration-related parameter to be adhered to in administering the pharmaceutical product to the patient.

The medical device <NUM> comprises an NFC enabled interface and is enabled for communication with the NFC unit <NUM> using NFC (indicated by reference numeral <NUM>). When the container <NUM> is inserted into the medical device <NUM>, the medical device <NUM> may read the administration scheme from the memory <NUM> via NFC and take into consideration the at least one administration-related parameter specified by the administration scheme for the automated administration of the pharmaceutical product to the patient. For example, when button <NUM> of the medical device <NUM> is pressed, the medical device <NUM> may check the prescribed date/time and/or the prescribed location specified by the administration scheme in order to verify that the pharmaceutical product is administered at the right time and/or at the right location. If the verification is successful, the medical device <NUM> may perform the administration of the pharmaceutical product in accordance with further administration-related parameters specified by the administration scheme, such as the prescribed dosage and/or the injection speed indicated by an administration device specific control parameter. If the verification is not successful, on the other hand, the medical device <NUM> may refuse to perform administration of the pharmaceutical product and output a corresponding indication to the patient.

Once the pharmaceutical product (or a portion thereof) has been administered to the patient, the medical device <NUM> may write usage-related information to the memory <NUM> of the container <NUM> in order to keep track of the administration performed. For example, if the container <NUM> was used for the first time, the medical device <NUM> may set the date of first use in the memory <NUM>. Otherwise, the medical device <NUM> may update the number of uses of the pharmaceutical product in the memory <NUM>. The medical device <NUM> may also update the remaining fill volume of the pharmaceutical product in the container <NUM> so that, when the container <NUM> is used the next time with the medical device <NUM> (or another administration device), the respective device may verify if sufficient fill volume is available in the container <NUM> to meet the prescribed dosage specified by the administration scheme before performing the next administration. Further, the usage-related information may not only be used to keep track of the administration performed but, since this information generally indicates that the container <NUM> has been used, it may also be used to prevent illegal container refilling by checking by the medical device <NUM>, before an administration is performed, whether an (apparently) fully filled container has already been used or not. In a further example, usage-related information may also be stored on a memory of the medical device <NUM> itself in order to support partial dosing using several containers. For example, if a remaining fill volume of the pharmaceutical product in the container <NUM> is not sufficient to meet the prescribed dosage according to the administration scheme, the remaining fill volume may be administered, in a first administration step, from the container <NUM> and a value indicative of the remaining required volume to be administered to meet the prescribed dosage may be stored on the medical device <NUM>. The container <NUM> may then be replaced by a fresh (e.g., fully filled) container from which the remaining required volume may then be administered by the medical device <NUM> in a second administration step.

As described above, in addition to the administration scheme and the usage-related information about the pharmaceutical product, the memory <NUM> of the container <NUM> may further store non-usage-related information about the pharmaceutical product and/or a file or a link to a website providing additional information about the pharmaceutical product.

As may be seen in <FIG>, the system <NUM> also comprises a remote server <NUM> which is exemplarily illustrated by a personal/laptop computer in <FIG>. It will be understood that any other type of computing system may be employed for the remote server <NUM>, such as a physical or virtual server computer which may reside in a cloud computing environment, or even a smartphone, for example. Besides the NFC enabled interface, the medical device <NUM> also comprises a wireless communication interface and is thus enabled to communicate with the remote server <NUM> using wireless communication (indicated by reference numeral <NUM>), preferably WLAN or Bluetooth. The medical device <NUM> may access the remote server <NUM> through the Internet. The communication between the medical device <NUM> and the remote server <NUM> may be secured, e.g., using security protocols such as SSL, TLS, or the like. Also, it will be understood that the medical device <NUM> may communicate with the remote server <NUM> via an intermediate device. For example, the intermediate device may be a personal computer, a laptop computer or a smartphone (e.g., of a clinician or the patient) which may communicate with the medical device <NUM>, on the one hand, and which may communicate with the remote server <NUM> (e.g., a server residing in a cloud computing environment), on the other hand.

The remote server <NUM> may be used to implement various supplemental services associated with the administration of the pharmaceutical product. For example, the remote server may host supplementary administration-related information accessible by the medical device <NUM>, such as additional administration-related parameters which are not stored (or cannot be stored due to memory limitations) in the memory <NUM> of the container <NUM>. The administration device may download the additional administration-related parameters from the remote server <NUM> and apply these parameters when performing administration of the pharmaceutical product accordingly. The medical device <NUM> may also exchange at least part of the data stored in the memory <NUM> with the remote server <NUM>. For example, the medical device <NUM> may replicate the data stored on the memory <NUM> (or parts thereof) on the remote server <NUM>. The exchanged data may be used by the remote server <NUM> to provide additional services to a user (e.g., the patient or a clinician). In an example, the remote server <NUM> may notify, based on an analysis of the exchanged or replicated data, a user of an upcoming administration to be performed according to the administration scheme. Such notifications may be transmitted in the form of reminders or alarms to a user's pager or smartphone, for example. In another example, the remote server <NUM> may report a status relating to the container <NUM> and/or the medical device <NUM> upon request by the user. Such report may allow the user to check the status of an ongoing administration, to check the result of a completed administration, to track a therapy session, or to track the entire adherence history, for example. The data stored in the remote server <NUM> may also be aggregated and shared with a caregiver or HCP. In another example, the data in the remote server <NUM> may be stored in an electronic patient record. In an electronic patient record, further patient-related information may be stored, such as other drugs prescribed to the patient, for example. Based on the information stored in the electronic patient record, it is generally conceivable to perform an analysis and generate an alert, if one or more drugs prescribed to the patient are incompatible, for example.

The remote server <NUM> may further instruct the medical device <NUM> to write data to the memory <NUM>, e.g., in order to update at least one administration-related parameter of the administration scheme or to write other data to the memory <NUM>. As an example, if it is encountered that a batch in which the pharmaceutical product was produced has been recalled due to a production fault, the remote server <NUM> may instruct medical device <NUM> to write data into the memory <NUM> of the container <NUM> marking the container <NUM> as unusable so as to prevent further use of the container <NUM>. The requirement for recalling the container <NUM> may be identified through the batch identification stored in the memory <NUM> or in the remote server <NUM>, respectively. Before performing administration of the pharmaceutical product, the medical device <NUM> may verify if the container <NUM> is marked as unusable and block any administration of the pharmaceutical product from the container <NUM> accordingly.

It will be understood that the above description of the system <NUM> is merely exemplary and that various other implementations in accordance with the present disclosure are conceivable. For example, the pharmaceutical product does not necessarily have to be provided in liquid form and the container does not necessarily have to be a cylindrical injection cartridge. It will be understood that the principles of the present disclosure may be practiced with any other suitable form of pharmaceutical product and corresponding container, such as with tablets provided in another type of suitable packaging, for example. It will also be understood that the NFC unit of the container does not necessarily have to be provided with a label affixed to the container, but may be integrated into the container itself, for example. The skilled person will further appreciate that other types of passive wireless communication technologies (i.e., other than NFC) may be used to realize the communication between the medical device and the container. If corresponding power supply is available, the wireless communication unit of the container may even be provided as an active unit.

Moreover, it will be understood that other types of NFC enabled devices (i.e., other than the automated injection device <NUM>) may be used to read and write data from and to the memory of the container. For example, a smartphone having required functionality (e.g., NFC functionality) to communicate with the wireless communication unit of the container may be used to read and/or write data from and to the memory. The smartphone may have a dedicated application (e.g., provided by the manufacturer of the pharmaceutical product) installed in order to provide the required functionality. For example, the smartphone may be used to read the usage scheme and/or the pairing-specific information from the container for verification by a user (e.g., the patient or a clinician) or to read other data from the memory of the container, such as non-usage-related information like the certificate of authenticity of the pharmaceutical product in order to verify the genuineness of the pharmaceutical product.

In another example, the medical device may be a non-automated administration device, such as a manually operable syringe. Similar to the automated medical device <NUM>, a non-automated administration device may verify that the pharmaceutical product is administered at the right time and/or at the right location, for example. The non-automated administration device may output a corresponding indication for the result of the verification, e.g., via text form on a display, through an audible output, or through visual indicators, such as LEDs provided at the housing of the device.

It will further be understood that, similar to the remote server <NUM>, the medical device <NUM> may be configured to communicate with other end-user devices, such as the above-mentioned external configuration device. These devices may have a dedicated application (e.g., provided by the manufacturer of the medical device) installed enabling the user to configure or view a status of the medical device <NUM> and, in particular, to write pairing-specific information to the medical device <NUM>, such as a patient ID, for example. In one variant, the medical device <NUM> may comprise an NFC unit for this purpose so that the pairing-specific information may be written to the medical device <NUM> from the external configuration device via NFC.

<FIG> is an illustration which shows that the container <NUM> is configured to interface with a plurality of types of medical devices. The container <NUM> is a universal container which may be used in combination with a suite of different dedicated devices. As depicted in the example of <FIG>, the container <NUM> may not only be used in combination with the automated injection device <NUM>, but also in combination with a manually operable (i.e., non-automated) syringe <NUM> as well as an automated patch pump device <NUM>. It will be understood that the medical devices <NUM>, <NUM> and <NUM> are only exemplary and that the container <NUM> may also be used in combination with other types of medical devices, such as with reconstitution devices, which may be used for preparing a liquid or lyophilized solution for subsequent administration. Each of the administration devices <NUM>, <NUM> and <NUM> may have a receiving portion which may receive the container <NUM>. The container <NUM> and the respective receiving portions may be shape-coded so that the container <NUM> may be accommodated in the receiving portions in a form fitting manner.

In order to support pairing with each of the medical devices <NUM>, <NUM> and <NUM>, the memory <NUM> of the container <NUM> may store pairing-specific information for each of these devices and, before effectively using the pharmaceutical product in a medical procedure, each of the medical devices <NUM>, <NUM> and <NUM> may read the pairing-specific information from the memory <NUM> of the container <NUM> to verify whether the container <NUM> is permitted to be used by the respective medical device. More specifically, each of the medical devices <NUM>, <NUM> and <NUM> may be configured to block use of the pharmaceutical product until the verification is complete. If a positive confirmation is determined as a result of the verification, the respective medical device may release the block so that the device may proceed with the intended medical procedure. On the other hand, if a negative confirmation is determined as a result of the verification, the respective medical device may maintain the block and thus prevent use of the pharmaceutical product in a medical procedure. In either case, an indication of the result of the verification may be provided by the respective medical device, e.g., via text form on a display, through an audible output, or through dedicated visual indicators, such as LEDs, provided at the device.

Each of the medical devices <NUM>, <NUM> and <NUM> may store pairing-specific information itself so that the verification may be performed by comparing the pairing-specific information stored in the memory <NUM> of the container <NUM> with the pairing-specific information stored on the respective medical device, wherein a positive confirmation may only be determined in case of a match. The compared pairing-specific information may comprise, for example, a device ID of the respective medical device and/or a patient ID of the patient to which the respective medical device is assigned. In case of a comparison of device IDs, the result of the verification may indicate that the container <NUM> is paired with the right medical device (or the right medical device type) and, in case of a comparison of patient IDs, the result of the verification may indicate that the pharmaceutical product is applied to the right patient. Further, as the pairing-specific information stored in the memory <NUM> of the container <NUM> may also comprise at least one control parameter which may be necessary for the respective medical device to configure its own operation, the verification may also include detecting the presence of the at least one control parameter on the memory <NUM> of the container <NUM>, wherein a positive confirmation may be determined in case the parameter is present and a negative confirmation may be determined in case the parameter is not present. In case of the automated injection device <NUM>, for example, the at least one control parameter may be necessary to configure the device's injection speed of the pharmaceutical product from the container <NUM>. It will be understood that these examples of the pairing-specific information are non-limiting and that any other type of information which enables the medical devices <NUM>, <NUM> and <NUM> to perform the verification may be used as the pairing-specific information.

<FIG> schematically illustrates an exemplary memory structure of the memory <NUM> of the container <NUM>. As shown, the memory <NUM> may comprise five different types of memory areas: a static information area <NUM>, a manufacturer information area <NUM>, variable data areas <NUM>, a prescription and usage area <NUM>, and an initialization vector area <NUM>. Among these types, the static information area <NUM> may be used to store unmodifiable information which may be written during manufacture and which may be write protected thereafter. This information may include the batch identification, the expiry date, the storage conditions (e.g., storage temperature/humidity) of the pharmaceutical product or a device ID of the medical device <NUM>, for example. The manufacturer information area <NUM> may be used to store information which may be readable by off-the-shelf NFC enabled devices, such as NFC enabled smartphones, to allow users to identify information about the manufacturer and the pharmaceutical product without the need to use proprietary reading equipment. Information stored in the manufacturer information area <NUM> may include the manufacturer identification, the unique product identification or the file or link to the website providing additional information about the pharmaceutical product, for example. The information in this area may be stored in ASCII format in order to ensure its readability by off-the-shelf devices. The variable data areas <NUM> may be used to store miscellaneous information that may differ dependent on the pharmaceutical product accommodated in the container <NUM>. The information stored in this area may not have a pre-defined format and a fixed location or length. Information stored in this area may include control parameters for controlling a function specific to the medical device (or the medical device type). The prescription and usage area <NUM> may be used to store information relevant to the prescription and usage of the pharmaceutical product. Such information may include a patient ID, the prescribed dosage, the prescribed date and/or time, the number of uses or the remaining fill volume of the container <NUM>, for example. Finally, the initialization vector area <NUM> may contain information used for encryption and decryption.

Each of the memory areas may be assigned with a dedicated level of read and/or write access to implement desired access protection. For example, the static information area <NUM> and the manufacturer information area <NUM> may be freely readable, but writable by the manufacturer of the pharmaceutical product only. The variable data areas <NUM>, the prescription and usage area <NUM> and the initialization vector area <NUM>, on the other hand, may be writable by a physician or a pharmacy, but their readability may generally be restricted. Read protection may be realized by password protection, for example. Additionally or alternatively, read protection may be realized by encrypting the information stored in the respective memory areas so that only a medical device which holds the required decryption key may read from the respective memory areas.

<FIG> illustrates an exemplary lifecycle of the container <NUM>. In <FIG>, the terms "e-label", "drug" and "cloud" correspond to the terms "label", "pharmaceutical product" and "remote server" described above, respectively. The lifecycle may comprise the stages manufacture, distribution, pharmacy, use and disposal.

In the manufacture stage, initial information about the pharmaceutical product may be written to the memory <NUM> of the label <NUM> by the manufacturer of the pharmaceutical product (e.g., into the static and manufacturer information areas <NUM> and <NUM>, as described above). The label <NUM> may then be affixed to the container <NUM> which may be prefilled with the pharmaceutical product. Tests on the NFC functionality of the label <NUM> may be performed before and after the affixation. Once the label <NUM> is successfully tested, the unique label identifier (e.g., the unique serial number of the NFC unit <NUM>) as well as the information about the pharmaceutical product may be uploaded to the remote server <NUM> to ensure traceability of the container <NUM> and the pharmaceutical product. The container <NUM> may then be assembled together with other containers into a carton for distribution and sealed. In the distribution stage, the carton may be placed into a box and shipped.

In the subsequent stage, a pharmacy (or another distribution center) may receive the container <NUM> and write distributor identification (e.g., a pharmacy ID) to the memory <NUM> of the label <NUM> for further traceability of the container <NUM>. Also, the pharmacy may verify the genuineness of the pharmaceutical product by checking the certificate of authenticity stored in the memory <NUM> of the label <NUM>. If the verification fails, the container <NUM> may be marked as unusable by writing corresponding data into the memory <NUM> of the label <NUM>. Further, the pharmacy may receive a patient specific prescription from a physicist and write the corresponding prescription instructions to the memory <NUM> of the label <NUM> so that the usage scheme stored in the memory <NUM> of the label <NUM> properly reflects the received prescription instructions. Also, the pharmacy may write pairing-specific information, such as a patient ID, to the memory <NUM> of the label <NUM>. The data written to the memory <NUM> may again be uploaded to the remote server <NUM> and the container <NUM> may then be handed over to the patient or a clinician, for example.

The use stage may differ depending on which type of medical device is used for administering the pharmaceutical product from the container <NUM> to the patient. If a manual syringe which is not enabled for wireless communication is used, the label <NUM> of the container <NUM> may be scanned by an NFC enabled device (e.g., by a smartphone having an application provided by the manufacturer) in order to verify that the pharmaceutical product is administered to the right patient, at the right time and/or at the right location, for example. Upon completion of the injection using the syringe, the NFC enabled device may be used to write usage-related information to the memory <NUM> of the label <NUM>. If, on the other hand, an automated injection device (like the automated injection device <NUM>) is used, the container <NUM> may be placed into the device and the device may perform (e.g., upon activation) an automated verification of the pharmaceutical product before administering it to the patient, as described above. If the verification is successful, the device may perform automated administration of the pharmaceutical product and, upon completion, the device write usage-related information to the memory <NUM> of the label <NUM>. The usage-related information may also be uploaded to the remote server <NUM> to keep track of the usage of the container <NUM>. Finally, if the pharmaceutical product has been partly or fully dispensed and the container <NUM> is no longer usable, the container <NUM> may be disposed.

Claim 1:
A system (<NUM>) for use of a pharmaceutical product, comprising:
a container (<NUM>) accommodating a pharmaceutical product, the container (<NUM>) being a universal container configured to interface with a plurality of medical devices (<NUM>; <NUM>; <NUM>) of different types and comprising a wireless communication unit (<NUM>) and a memory (<NUM>) which stores pairing-specific information for each of the plurality of medical devices (<NUM>; <NUM>; <NUM>), wherein the types include a syringe type, an automated injection device type, a patch pump device type, and a reconstitution device type; and
a medical device (<NUM>; <NUM>; <NUM>) enabled for wireless communication with the wireless communication unit (<NUM>) of the container (<NUM>) and configured to read the pairing-specific information from the memory (<NUM>) of the container (<NUM>) to verify whether the medical device (<NUM>; <NUM>; <NUM>) is one of the plurality of medical devices (<NUM>; <NUM>; <NUM>) for which pairing-specific information is stored in the memory (<NUM>) of the container (<NUM>) and whether the container (<NUM>) is thus permitted to be used by the medical device (<NUM>; <NUM>; <NUM>), wherein
the pairing-specific information comprises an identification of the medical device (<NUM>; <NUM>; <NUM>) and at least one control parameter, and wherein the identification of the medical device and the at least one control parameter are specific to a device type of the medical device (<NUM>; <NUM>; <NUM>).