Cloud computing and medicament dispenser

Abstract

A method is described for programming a medicament dispenser. The method comprises connecting a first component of the medicament dispenser to a computing device in such a manner that allows the computing device to load data onto the first component. The method further comprises sending a data request from the computing device to a data service of a cloud-based network. The method further comprises generating, in the cloud-based network, a data package for sending to the computing device as a result of the data service receiving the data request from the computing device, wherein the data is collected from a data store within the cloud-based network, and the generating is done completely within the cloud-based network. The method further comprises sending the data package from the cloud-based network to the computing device. The method further comprises transferring, by the computing device, data from the data package to the first component of the medicament dispenser.

Description

[0001] CLOUD COMPUTING AND MEDICAMENT DISPENSER

[0002] TECHNICAL FIELD

[0003] This invention relates to methods of manufacturing, filling, and controlling medical devices with medicament, in particular oral dosage forms, and utilising cloud computing and similar techniques.

[0004] BACKGROUD

[0005] In recent years, cloud computing has become widespread in fields of software and Information Technology (IT). Cloud computing is a term now generally understood to refer to the on-demand availability of computer system resources, without direct active management by a user.

[0006] An example of cloud computing is cloud storage, wherein a user is able to upload data to a cloud via the internet. The cloud is managed by a third party or service provider, and the user can access their data in any location and at any time via the internet. The user is not required to maintain the services or infrastructure related to the cloud storage, which in this example illustrates how cloud computing can provide a more flexible, scalable, and cost effective solution to providing data storage compared to the user having to devise their own internet based data storage and retrieval system.

[0007] There are, however, technical challenges when implementing cloud computing in new technical fields, for example, in the field of medical devices, and in particular, in the field of medicament dispensing devices, in particular those that dispense oral dosage forms.

[0008] A medicament dispensing device may be configured to dispense medicament (or drugs) by weight or volume. This has recently seen more interest due to the dispensing of medicament in smaller units, such as pellets or minitablets. This advantageously allows for a dose to be varied using the same dispensing device, as distinct from, for example, blister-pack type devices, wherein individual tablets can be retained within pockets and retained therein by the use of foil, or dispensing bottles.

[0009] A medicament dispensing device, for example that disclosed in European Patent No. 3873398 (which is incorporated by reference herein in its entirety), may include a cartridge to store medicament in pellet form, and a control unit to operate the device. The cartridge must be filled with the correct dosage of the correct medicament. The dosage requirements and user data must be secure, but also readily accessible both during filling of the cartridge and during operation of the device, for example, if needed by a doctor or the user. The medicament dispensing device may be used, for example in case of paediatric medicine; antibiotics for easier swallowing, in case of geriatric medicine; chronic medication for easier swallowing, in the case of certain controlled substances such as stimulants for ADHD or pain medications such as opioids; for improved control over the dispensed dose or limit the risk for overdosing, or for medications that require titration at initiation or flexible adjustments as a result of disease variability or as a result of achieved outcomes, for example in case of immunosuppression after organ transplant, for psychiatric disorders such as depression or for neurological disorders such as epilepsy.

[0010] It is desired to improve the methods by which medicament dispensing devices are manufactured, filled, and controlled during operation.

[0011] SUMMARY

[0012] According to an aspect of the disclosure, there is provided a method for programming a medicament dispenser, the method comprising:

[0013] (i) connecting a first component of the medicament dispenser to a computing device in such a manner that allows the computing device to load data onto the first component;

[0014] (ii) sending a data request from the computing device to a data service of a cloud-based network;

[0015] (iii) generating, in the cloud-based network, a data package for sending to the computing device as a result of the data service receiving the data request from the computing device, wherein the data is collected from a data store within the cloud-based network, and the generating is done completely within the cloud-based network;

[0016] (iv) sending the data package from the cloud-based network to the computing device; and

[0017] (v) transferring, by the computing device, data from the data package to the first component of the medicament dispenser.

[0018] The medicament dispenser may include a controller (or control unit), which includes a processor or circuitry configured to control the dispensing of medicament. This may be using an actuator located within the controller. The first component may be a cartridge containing a medicament, which may be provided as an oral dosage form (pellets, tablets, minitablets, and the like). The cartridge may be a replaceable medicament cartridge connectable to the controller. The controller may be configured to cause the actuator to move and dispense the medication within the cartridge to a user. The dispenser may be a mobile (e.g. handheld) device that can be held, operated and transported using one hand. Such a controller / control unit and cartridge may be as disclosed in International (PCT) Patent Application No. PCT / EP2019 / 079999 (published as W02020 / 089469), which is incorporated by reference herein in its entirety. The data package may include information relating to the type of medicament within the cartridge (e.g., the type of drug, amount, volume, batch no., and the like) and / or one or more security / authentication credentials (e.g., an encryption key, security token, password, etc.).

[0019] The first component may (instead of a cartridge) be a (or the) controller of the medicament dispenser, and the data package includes information relating to the firmware of the controller and / or one or more security / authentication credentials.

[0020] The method may be for programming a plurality of medicament dispensers (as described above and in W02020 / 089469). The method may comprise connecting a plurality of cartridges, each corresponding to a different medicament dispenser, to the computing device, the computing device configured to transfer data onto each of the plurality of cartridges in a sequential manner.

[0021] The step of sending a data request may include requesting data for all of the plurality of cartridges in a single request, and the data package generated in the generating step may include data for all of the plurality of cartridges. The step of sending the data package may include downloading the entire data package from the cloud-based network and storing it locally, so that the computing device can access the data relating to each separate cartridge and transfer this to each cartridge sequentially as aforesaid. This enables the computing device to subsequently program the cartridges with data 'offline', without any need for a constant connection to the cloud-based network.

[0022] The method may further comprise connecting a (or the) controller of the medicament dispenser to a second computing device in such a manner that allows the second computing device to load data onto the controller, wherein the method optionally further comprises the steps of: sending a second data request from the second computing device to a second data service of the cloud-based network; generating, in the cloud-based network, a second data package for sending to the second computing device as a result of the second data service receiving the second data request from the second computing device, wherein the data is collected from a second data store within the cloud-based network, and the generating is done completely within the cloud-based network; sending the second data package from the cloud-based server to the second computing device; and transferring, by the second computing device, data from the second data package to the controller of the medicament dispenser.

[0023] The second data package may include information relating to the firmware of the controller (e.g., the type of controller, dispensing information, actuation information, dosing information, and the like) and / or one or more security / authentication credentials (e.g., an encryption key, security token, password, etc.).

[0024] The data package for the cartridge may include a first encryption key, and the second data package may include a second encryption key, wherein the first and second encryption keys form an asymmetric pair enabling authentication of the cartridge using asymmetric encryption.

[0025] The method may further comprise assembling the medicament dispenser with the controller and the first component to complete assembly of the medicament dispenser ready for use.

[0026] The method may further comprise providing a mobile telecommunications device that is configured to run a software application configured to communicate data between the medicament dispenser and the cloud-based network, wherein the software application is configured to pass data from the medicament dispenser to the cloud-based network without substantially any manipulation of the data.

[0027] Once the application on the mobile telecommunications device is being utilised, a secure (optionally encrypted) communication channel can be set up between the cloud-based network and the medicament dispenser, via the mobile telecommunications device. The application thereby acts as a "soft gateway" as defined herein. This means, for example, that the medicament dispenser can send data securely to the cloud-based network as described above, for example usage, battery or dosing data, which data can then be stored on the cloud-based network and optionally associated with a unique ID as described elsewhere herein.

[0028] According to an aspect of the disclosure there is provided a system for programming a medicament dispenser, the system comprising: a cloud-based network comprising a plurality of data services, each data service comprising a set of routines stored on the cloud-based network, as well as one or more data stores within the cloud-based network; a first computing device configured to request a first data package from a first of the data services of the cloud-based network, wherein, upon receiving a request for a data package from the first computing device, the first data service is configured to process the request and return a first data package to the first computing device, the first data package comprising data collected from the one or more data stores of the first data service, wherein the first computing device is configured to transfer data within the received first data package to a component of the medicament dispenser.

[0029] The component of the medicament dispenser may be a cartridge for containing medicament, as described above. The system may further comprise a second computing device configured to request a second data package from the data services of the cloud-based network. Upon receiving the request for a second data package from the second computing device, the second data service may be configured to process the request and return a second data package to the second computing device, the second data package comprising data collected from the one or more data stores of the second data service. The second computing device may be configured to transfer data within the received data package to a controller of the medicament dispenser.

[0030] According to an aspect of the disclosure there is provided a method of establishing secure communication between a medicament dispenser and a cloud-based server, the method comprising:

[0031] (i) establishing a first communication channel between the medicament dispenser and a mobile telecommunications device;

[0032] (ii) establishing a second communication channel between the mobile telecommunications device and a cloud server;

[0033] (iii) transferring device identification data from the medicament dispenser to the mobile telecommunications device via the first communication channel;

[0034] (iv) sending the device identification data to the cloud server via the second communication channel, and storing the device identification data on the cloud server;

[0035] (v) generating, within the cloud server, an authentication data file configured to be processed by the medicament dispenser for authenticating the cloud server and / or the medicament dispenser;

[0036] (vi) sending the authentication data file to the medicament dispenser via the mobile telecommunications device;

[0037] (vii) processing, by a processor of the medicament dispenser, the authentication data file and generating a response based on the processing that authenticates the cloud server and / or the medicament dispenser; and

[0038] (viii) sending the response to the cloud server via the mobile telecommunications device.

[0039] The mobile telecommunications device may be a mobile telephone. The medicament dispenser may include a controller (or control unit), which includes a processor or circuitry configured to control the dispensing of medicament. This may be using an actuator located within the controller. The medicament dispenser may include a cartridge containing a medicament, which may be provided as an oral dosage form (pellets, tablets, minitablets, and the like). The cartridge may be a replaceable medicament cartridge connectable to the controller. The controller may be configured to cause the actuator to move and dispense the medication within the cartridge to a user. The dispenser may be a mobile (e.g. handheld) device that can be held, operated and transported using one hand. Such a controller / control unit and cartridge may be as disclosed in International (PCT) Patent Application No. PCT / EP2019 / 079999 (published as W02020 / 089469), which is incorporated by reference herein in its entirety.

[0040] The method may further comprise providing a software application on the mobile telecommunications device configured to transfer data between the mobile telecommunications device and the cloud server and / or the medicament dispenser.

[0041] The mobile telecommunications device may be configured to run an application that is able to communicate data between the medical device and the cloud server, and the application may be configured to act as a “soft gateway” as defined herein.

[0042] That is, the application may be configured to pass data from the medical device to the cloud server without any, or without substantially any manipulation of the data and / or without storing any of the data other than to pass the data from the medical device to the cloud server as aforesaid. The mobile telecommunications device may thereby be, or may act merely as a “pass-thru” device.

[0043] Once the application on the mobile telecommunications device is being utilised, a secure (optionally encrypted) communication channel can be set up between the cloud server and the medical device, via the mobile telecommunications device including the application acting as a "soft gateway". This means, for example, that the medical device can send data securely to the cloud server as described above, for example usage, battery or dosing data, which data can then be stored on the cloud server and optionally associated with a unique ID as described elsewhere herein

[0044] The authentication data file may use asymmetric encryption, for example using a first encryption key associated with the cloud server, and a second encryption key associated with the controller.

[0045] The method may further comprise receiving the response at the cloud server and verifying, by a software program within the cloud server, the response as authentic, and then, only if the response is verified as authentic, setting up a secure communications channel between the cloud server and the medicament dispenser via the mobile telecommunications device.

[0046] The method may further comprise sending usage data from the medical device to the cloud server via the secure communications channel.

[0047] According to an aspect of the disclosure there is provided a system for establishing secure communication between a medical device and a cloud-based server, the system comprising: a medical device; a mobile telecommunications device; and a cloud server. The mobile telecommunications device is configured to transfer data between the medical device and the cloud server.

[0048] The mobile telecommunications device may be configured to run an application that is able to communicate data between the medical device and the cloud server, and the application may be configured to act as a “soft gateway” as defined herein. That is, the application may be configured to pass data from the medical device to the cloud server without any, or without substantially any manipulation of the data and / or without storing any of the data other than to pass the data from the medical device to the cloud server as aforesaid. The mobile telecommunications device may thereby be, or may act merely as a “pass-thru” device.

[0049] Once the application on the mobile telecommunications device is being utilised, a secure (optionally encrypted) communication channel can be set up between the cloud server and the medical device, via the mobile telecommunications device including the application acting as a "soft gateway". This means, for example, that the medical device can send data securely to the cloud server as described above, for example usage, battery or dosing data, which data can then be stored on the cloud server and optionally associated with a unique ID as described elsewhere herein.

[0050] The above features may be applied to any of the aspects and embodiments described herein including a mobile telecommunications device, medical device and cloud server, in order to set up a secure communications channel.

[0051] The cloud server may be configured to generate, within the cloud server, an authentication data file configured to be processed by the medicament dispenser for authenticating the cloud server and / or the medicament dispenser, and then to send the authentication data file to the medicament dispenser via the mobile telecommunications device.

[0052] The medicament dispenser may be configured, by a processor thereof, to receive and process the authentication data file and generate a response based on the processing that authenticates the cloud server and / or the medicament dispenser, and then to send the response to the cloud server via the mobile telecommunications device.

[0053] According to an aspect of the disclosure there is provided a system for transferring data between different cloud-based networks and a plurality of user devices, the system comprising: a first cloud-based network in data communication with a plurality of user devices, the user devices configured to collect first data, wherein the first cloudbased network is configured to receive, process, store and transmit the first data; a second cloud-based network configured to receive the first data, and process, store and transmit second data, wherein at least some of the second data is associated with the first data, wherein the system is configured such that the second data is not, and cannot be sent from the second cloud-based network to the first cloud-based network.

[0054] The user devices may be medicament dispensers. The medicament dispensers may each include a controller (or control unit), which includes a processor or circuitry configured to control the dispensing of medicament. This may be using an actuator located within the controller. The medicament dispenser may include a cartridge containing a medicament, which may be provided as an oral dosage form (pellets, tablets, minitablets, and the like). The cartridge may be a replaceable medicament cartridge connectable to the controller. The controller may be configured to cause the actuator to move and dispense the medication within the cartridge to a user. The dispensers may themselves be mobile (e.g. handheld) devices that can be held, operated and transported using one hand. Such a control ler / control unit and cartridge may be as disclosed in International (PCT) Patent Application No. PCT / EP2019 / 079999 (published as W02020 / 089469), which is incorporated by reference herein in its entirety.

[0055] The first data may include usage information of the medicament dispensers, such as how many doses have been dispensed, frequency of dosing, amount of medicament dispensed, and the like. The first data may be non-personalised.

[0056] In contrast, the second data may include personal information of the users of the medicament dispensers. The second data could also, or alternatively include medical information of the users of the medicament dispensers. This keeps private information separated from the first cloud-based network. By "associated with", it is meant that the second data has some link to the users of the user devices and can be matched up with the same user data held in the first data. The second data could, for example, include the personal information of the (non-personalised) first data, such as the name of the person that is using each medicament dispenser (and / or the name of a patient receiving the medicament).

[0057] The system may further comprise a third cloud-based network configured to receive the second data, and process, store and transmit third data, wherein at least some of the third data is associated with the second data. Similar to the first and second data, by "associated with" it is meant that the third data has some link to the users of the user devices and can be matched up with the same user data held in the first and / or the second data. The third data could, for example, constitute an analysis of the second data (or first data), which analysis constitutes some medical assessment of a user based on that user's data held within the first and / or second data. The system may be configured such that the third data is not, and cannot be sent from the third cloud-based network to the second or first cloud-based networks.

[0058] The system may further comprise a plurality of mobile telecommunications devices, each configured to provide the aforesaid communication between the first cloudbased network and the user devices, such that each user device is configured to send respective first data to the first cloud-based network via a respective mobile telecommunications device.

[0059] Definitions:

[0060] Cartridge - a user replaceable assembly used to store and dispense medicament such as an oral dosage form

[0061] Medicament - (also called medicine, pharmaceutical drug, medicinal drug or simply drug) is a drug used to diagnose, cure, treat, or prevent disease, for example a dosage form such as an oral dosage form

[0062] Oral dosage form - a unit, such as a granule, pellet, tablet or minitablet containing one or more drugs

[0063] User - typically the end user to which the medicament is dispensed, such as a patient, but could include someone that uses the dispenser but does not ingest the medicament (such as a caregiver)

[0064] Cloud-based network - a type of infrastructure in which some or all of an organisation’s network capabilities and resources are hosted in a public or private cloud platform (e.g., cloud server).

[0065] Cloud server - a virtual server running in a cloud computing environment delivered over a network (e.g. the internet) that can be accessed on demand by users. A cloud server may be created using virtualisation software to divide physical servers into multiple virtual servers, which abstracts the server's processing power and / or memory / storage, pooling them together to create a virtual, cloud server.

[0066] Data service - a set of routines / programs, in this case stored on a cloud-based network, as well as one or more data stores within the cloud-based network, which respond to requests by executing the routines / programs to provide a response, the form of which depends on the type of service required.

[0067] Computing device - one or more hardware components that comprise processors or circuitry (e.g., one or more CPUs) configured to execute instructions of a computer program, such as arithmetic, logic, controlling, and input / output (I / O) operations. Program - a sequence or set of instructions in a programming language for a computer to execute.

[0068] Routine - a component (e.g., portion of code) of a software application or program that performs a specific task.

[0069] Module - similar to a data service, but in this case implemented on a single computing device, or multiple computing devices connected by a local area network, in the form of a set of routines / programs that respond to inputs by executing the routines / programs to provide an output as described.

[0070] Soft gateway - a software program stored and executable on a device (e.g. a mobile telecommunications device) that is configured to communicate data (e.g. from one interface connected to the device to another) in such a manner that at least some or all of the data being communicated is not manipulated, and is not stored on the device other than to be communicated through it as aforesaid.

[0071] BRIEF DESCRIPTION OF THE DRAWINGS

[0072] Various examples will now be described with reference to the accompanying drawings, in which:

[0073] Figure 1 shows a high level overview of a system to transfer data between a plurality of cloud-based services and one or more different entities, including a device, control unit, manufacturing controller, medicament controller and medicament cartridge;

[0074] Figure 2 shows data flow between a cloud-based service for loading data onto a drug cartridge and one or more different entities, including controllers, programmers and the drug cartridge;

[0075] Figure 3 shows data flow between a cloud-based service for loading data onto a control unit and one or more different entities, including controllers, programmers and the control unit;

[0076] Figure 4 shows a method of secure communication between a medicament dispenser and a cloud-based service, via a mobile telecommunications device; and

[0077] Figure 5 includes the system of Figure 1 in terms of data management (e.g., storage), and illustrates the transfer of data between the one or more cloud-based networks and the various entities, including the medicament dispenser, mobile telecommunications device, etc. DETAILED DESCRIPTION

[0078] With reference to Figure 1, a system 100 includes a cloud server 110, a drug filler plant 120, a cartridge 125 for containing a drug or medicament, a manufacturing plant 130, a user device 140 and a control unit 150.

[0079] The terms "drug filler plant" and "manufacturing plant" are to be read generically, and are not necessarily separate physical locations, or even separate pieces of equipment. They could, for example, be different programs on the same computing device. The term "manufacturing" is also to be read generically, and encompasses assembly and is not, for example, limited to the physical build-up of components from raw materials.

[0080] The cartridge 125 is filled with medicament at the drug filler plant 120, and may then be incorporated into the control unit 150. The intention is that the control unit 150 controls access to and dispensing of the drug(s) in the cartridge 125 to a user. The control unit 150 is an example of a medicament dispensing device, and is discussed further below.

[0081] The system 100 is a flexible, adaptable, multi-purpose system. As will be disclosed herein, the system 100 is usable in one or more of the manufacture of a medical device, the filling of a cartridge, and for providing services for the use of the medical device by a user. These and other features of the system 100 will become apparent throughout the following description.

[0082] The cloud server 110 is understood by the skilled person to be a virtual environment including a number of cloud-based services. Cloud-based services are application and infrastructure resources that exist in the cloud server 110.

[0083] The cloud server 110 comprises a cartridge data service 111 , a drug filler service 112, a provisioning service 114, a manufacturing service 113, a control unit data service 117 and a user service 118. Each of the services are configured for an intended purpose, and will be discussed further below.

[0084] The cloud services included in the cloud server 110 are accessible through various Application Programming Interfaces (APIs). The APIs enable communication or access from an external application, program or hardware to the cloud service in the cloud server 110, in order for the external application, program or hardware to use the application and infrastructure resources that exist in the cloud service. An external application, program or hardware is something which is not a part of the cloud server 110. These may, or may not be comprised in the system 100.

[0085] The APIs may allow communication between different services performed by the cloud server 110. In this way, the APIs may allow for internal communication between services included in the cloud server 110. Although the examples disclosed herein include APIs for communication to the services in the cloud server 110, the APIs may be replaced by any other format or method of communication, for example suitable for transferring data between a cloud-based service and an external or internal application, program or hardware.

[0086] The drug filler service 112 is accessible via a drug filler plant API 122. The drug filler plant 120 is configured to communicate with the drug filler service 112 via the drug filler plant API 122.

[0087] The manufacturing service 113 is accessible via a manufacturing API 132. The manufacturing plant 130 is configured to communicate with the manufacturing service 113 via the manufacturing API 132.

[0088] The provisioning service 114 is accessible via a provisioning service API 142. The user device 140 is configured to communicate with the provisioning service 114 via the provisioning service API 142.

[0089] A further API 146 may allow communication between the provisioning service 114 and the manufacturing service 113.

[0090] The user service 118 is accessible via a user services API 144. The user device 140 is configured to communicate with the user service 118 via the user services API 144.

[0091] An event bus may be provided to enable communication between some of the services, for example the control unit data service 117 or the cartridge data service 111 , and their targets. The use of an event bus is well-known in the art, and an example location is shown in Figure 1.

[0092] Programming the medicament cartridge

[0093] The drug filler plant 120, the cartridge 125, the drug filler service 112, and the cartridge data service 111 are configured to collectively work together to program the cartridge 125, for example with data enabling identification of the cartridge and / or the medicament to be loaded into the cartridge.

[0094] Generally, the cartridge 125 is programmed with data and then filled with a medicament at the drug filler plant 120. The cartridge 125 is then, in a later step, assembled with (e.g. inserted into) a control unit 150. Later, during operation, the control unit 150 operates the cartridge 125 to dispense the medicine contained within the cartridge 125 as desired or prescribed for a user. The data programmed into the cartridge 125 contains identification information, as well as any other relevant information, for example the type of medicament that is to be filled into the drug cartridge.

[0095] This data may take the form of a data table and may include any type of data that may be useful, for example drug type, identifiers (e.g., unique ID), production date / time, expiry date and so forth. The data table may contain an identifier for the cartridge 125, so that the respective drug cartridge 125 can be identified consistently during drug filling, assembly, and operation.

[0096] The data may be configured to allow the drug filler plant 120 to fill the correct medicine into the cartridge 125, and the control unit 150 to dispense the correct dose during operation.

[0097] It is important that the generation and programming of the data is secure and reliable. If the security or reliability of the data is compromised, then the type of medicament filled into the cartridge 125, or the dose dispensed by the control unit 150, may be incorrect, which could be harmful to the user.

[0098] In this context, the security of the data is a reference to the likelihood of the data being changed, perhaps in a malicious manner. Thus, secure data is generated and programmed in a manner which would not be vulnerable to, for example, a hacker attack, tampering or changing of the data in a malicious manner.

[0099] In this context, the reliability of the data is a reference to the likelihood of the data being generated or changed in an unintentional manner by the manufacturer during a manufacture related process. Reliable data is generated and programmed in a manner which would not, for example, unintentionally be a duplicate of other data, or for example be generated from out-dated software which may result in a bug or deficiency in code associated with the data.

[0100] Accordingly, in a manufacturing environment there arises problems of providing a secure and reliable method to program and / or fill the cartridge 125. In various aspects the present disclosure provides solutions to these problems.

[0101] With reference to Figure 2, the drug filler plant 120 comprises a production station 210 and a programmer 220. The drug filler plant 120 is configured to communicate with the drug filler service 112 via the drug filler plant API 122 and an intermediate module 212. The intermediate module 212 communicates with the production station 210 as well as the drug filler service 112. The drug filler service 112 comprises various features, including the cartridge data service 111 , as discussed below.

[0102] The production station 210 and programmer 220 may form part of a manufacturing / assembly line or process for the cartridge 125. The production station 210 is configured to communicate with (i.e. send data to and receive data from) the drug filler service 112 via the intermediate module 212 and drug filler plant API 122, in order to construct the data (e.g. a data table) in a secure and reliable manner. The production station 210 communicates with the programmer 220. The programmer 220 programs (i.e. sends data to) the drug cartridge 125 with the data table, and is also able to read data from (i.e. receive data from) the drug cartridge 125.

[0103] The inventive method of generating and programming the cartridge with the data is as follows.

[0104] In a first step, a request is sent from the production station 210 to the cartridge data service 111 , via the intermediate module 212 and the drug filler plant API 122, for a certain number of data tables. Each data table may be for a different cartridge 125, such that a plurality of data tables may be requested to enable the programming and filling of multiple cartridges. Once the data tables are received at the drug filler plant 120 the programming and filling of the cartridges can be done 'offline' (that is, without the need to communicate further with the cloud server 110.

[0105] The request may be based on or include a number of parameters, such as production time, expiry time, batch information, etc.

[0106] It will be appreciated that the functionality of the intermediate module 212 (and other features of the drug filler plant 120) could be provided by (or seen as) a common "module", for example with the production station 210. They could all be part of the same computer, for example, or provided on separate computing devices. In other words, what is important is not the names given to the various modules, but the functionality they provide, which functionality could be provided by several modules or a single module, and / or within the same hardware / software or different hardware / software as required.

[0107] In a second optional step, the intermediate module 212 receives the request from the production station and forwards this to the drug filler service 112.

[0108] In a third step, the drug filler service 112 receives this request, optionally at a cartridge filler module 111a, and passes this through to the cartridge data service 111.

[0109] In a fourth step, the cartridge data service 111 retrieves a single data table and then a program is run in a fifth step, optionally at the cartridge filler module 111a, to generate by iteration a data package comprising a plurality of data tables according to the number requested by the drug filler plant 120, starting with the single data table retrieved from the cartridge data service 111. Each data table will be specific to one cartridge, and will include one or more encryption keys that enable the cartridge to be identified. For example, the cartridge may be tied to a control unit using the encryption keys as discussed further below. The type of encryption used may be public-key or asymmetric cryptography, whereby a public key can be matched with a corresponding private key, for example to enable authentication.

[0110] In a sixth step, a data package including the data tables is sent, optionally from the cartridge filler module 111 a to a cloud storage 111b.

[0111] In a seventh step, the drug filler service 112, optionally using the cartridge filler module 111a, sends the location of the data package in the cloud storage to the intermediate module 212 of the drug filler plant 120.

[0112] In an eighth step, the intermediate module 212 accesses and downloads the data package from the cloud storage 111b and stores the data package locally (e.g., within the module or other storage in the drug filler plant 120).

[0113] In an optional ninth step, the intermediate module 212 sends the file path of the data package to the production station 210, which is then able to retrieve the data. In this manner, the production station 210 is not required to maintain any software libraries (or at least, would need only minimal software libraries).

[0114] A large number of production stations 210 can be used in conjunction with the same drug filler service 112 and cartridge data service 111 , without compromising the reliability or security of the generated data, due to the generation of the data tables (including their encryption keys) being centralised.

[0115] Accordingly, by using cloud computing in this manner, the reliability and security of programming the drug cartridge 125 is improved.

[0116] In a tenth step, the production station 210 sends a request to the programmer 220 configured to program the plurality of cartridges 125, and in an eleventh step the programmer 220 programs each cartridge with a data table.

[0117] The programmer 220 may also be configured to read the data on a particular cartridge, and / or the production station 210 may be configured to produce a report based on the retrieved data. This report could be sent and used, for example, by the cartridge data service 111 (or other part of the cloud network) to verify the integrity of the data programmed onto the cartridge 125. For example, the report could be compared with the data generated in the fifth step.

[0118] Each data table may include a unique serial number and one or more encryption keys. The serial number and / or encryption key(s) of the last data table generated in the fifth step may be saved (e.g. in the cartridge data service) to avoid overlapping or duplicate serial numbers / encryption keys in subsequent requests.

[0119] As discussed above, the encryption key may be part of an asymmetrical pair and used to authenticate or tie the cartridge to a control unit, as discussed further below.

[0120] In summary, the inventive method allows for the programming of a cartridge 125 without requiring management of complex software libraries locally with each production unit 210. Also it is not required to store encryption keys locally within the production unit 210 or at the drug filler plant 120 (or send them outside of the central database). Furthermore, unique serial numbers and encryption keys for a plurality of cartridges 125, without compromising the reliability of the encryption keys and without resulting in duplicate keys. Because the generation and storage of the data and encryption keys is managed centrally in the cartridge data service 111, it is relatively easy to change the data format or add new data, without having to update a plurality of drug filler plants 120 or production units 210.

[0121] As noted above, the names given to the various parts of the drug filler service 112 or drug filler plant 120 are not particularly important. Instead, it is the functionality they provide, which could be provided by several modules or a single module, and / or within the same hardware / software or different hardware / software within the cloud server 110 or drug filler plant 120 as required.

[0122] Assembly and programming of control units

[0123] As discussed above, and referring back to Figure 1 , the manufacturing plant 130 collectively works with various parts of the system 100 to manufacture / assemble a control unit 150. This has similar reliability and security requirements as identified above in respect of the cartridge 125. This is because each control unit 150, for operational purposes, requires a device identification (ID), up-to-date firmware and security credentials.

[0124] The generation and programming of the data onto each control unit 150 must be reliable and secure, and is similar to the generation and programming of data onto the drug cartridge 125 described above.

[0125] Referring now to Figure 3, the manufacturing plant 130 comprises a production station 310 and a programmer 320. The manufacturing plant 130 is configured to communicate with the manufacturing service 113 via a manufacturing plant API 132 and an intermediate module 312. The manufacturing service 113 comprises various features, including the control unit data service 117 and cloud storage 113b (which may be the same as, or different to the cloud storage 111b discussed above in respect of the cartridge data service 111). The production station 310 and programmer 320 may form part of a manufacturing / assembly line or process for the control unit 150. The production station 310 is configured to communicate with (i.e. send data to and receive data from) the manufacturing service 113 via the intermediate module 312 and manufacturing plant API 132. The production station 310 communicates with the programmer 320. The programmer 320 programs (i.e. sends data to) the control unit 150, and is also able to read data from (i.e. receive data from) the control unit 150.

[0126] It will be appreciated that the functionality of the intermediate module 312 (and other features of the manufacturing plant 130) could be provided by (or seen as) a common "module", for example with the production station 310. What is important is not the names given to the various modules, but the functionality they provide, which could be provided by several modules or a single module, and / or within the same hardware / software or different hardware / software within the cloud server 110 or manufacturing plant 130 as required

[0127] The inventive method of generating and programming the control unit with data is as follows. The data may include firmware updates, as well as security credentials (e.g., encryption keys). The following method could be carried out multiple times to get different types of data. For example, the method could be carried out to obtain firmware data, and separately the method could be carried out to obtain security credentials.

[0128] In a first step, the production station 310 of the manufacturing plant 130 sends a data request to the manufacturing service 113, optionally via the intermediate module 312 in a second step, and using the manufacturing API 132. The data request may include firmware data for the control unit 150, or security credentials, etc.

[0129] In a third step, the request is passed to the control unit data service 117, which then, in a fourth step, retrieves the required data (whatever was requested) and then a program is run in a fifth step by the manufacturing service 113 to generate by iteration a data package comprising the required data according to the number of control units to be programmed at the manufacturing plant 130.

[0130] In a sixth step, this data is sent to the cloud storage 113b.

[0131] In a seventh step, the manufacturing service 113 then sends the location or path of the data package within the cloud storage 113b to the intermediate module 312, which then, in an eighth step, accesses and downloads the data package from the cloud storage 113b and stores the data package locally (e.g., within the module or other storage in the manufacturing plant 130). As noted above, the data package may include identification and / or security credentials. These may include encryption keys, counterpart to those discussed above in respect of the cartridge. As discussed above, the encryption key may be part of an asymmetrical pair and used to authenticate or tie the control unit to a particular cartridge, as discussed further below.

[0132] In an optional ninth step, the intermediate module 312 sends the file path of the data package to the production station 310, which is then able to retrieve the data. In this manner, the production station 310 is not required to maintain any software libraries (or at least, would need only minimal software libraries).

[0133] A large number of production stations 310 can be used in conjunction with the same manufacturing service 113 and control unit data service 117, without compromising the reliability or security of the generated data similar to the above method relating to the drug filler plant 120.

[0134] Accordingly, by using cloud computing in this manner, the reliability and security of programming the control unit 150 is improved.

[0135] In a tenth step, the production station 310 sends a request to the programmer 320 configured to program the plurality of control units 150, and in an eleventh step the programmer 320 programs each control unit 150 with the data.

[0136] Because the manufacturing plant 130 is able to receive the most up-to-date firmware every time a control unit 150 is to be programmed, the manufacturing plant 130 is not required to maintain any software libraries (or at least, minimal software libraries) in order to continuously provide the most up-to-date firmware. This reduces the probability or likeliness of a control unit 150 being programmed with out-of-date firmware, which further improves the reliability and security of the method.

[0137] Additionally, a large number of manufacturing plants 130 can be used in conjunction with the same manufacturing service 113, without compromising the reliability or security of the generated provisioning data. This is because the generation of the data is centralised, whereas the programming may be carried out by a plurality of manufacturing plants 130 in different locations.

[0138] Furthermore, because the manufacturing plant 130 is not required to store the data locally, the security of manufacturing the control unit 150 is improved, as there are fewer points of vulnerability in the process.

[0139] By using cloud computing in this manner, therefore, the reliability and security of manufacturing / assembling a control unit 150 is improved. Optionally, the manufacturing plant 130 may be able to read (i.e. receive data from) the control unit 150. In response to receiving the data, the manufacturing plant 130 may send this data to the manufacturing service 113, which may be indicative of the data programmed onto the control unit. The manufacturing service 113 could then receive the data and, if desired, verify the integrity of it.

[0140] Because verification of the integrity of the data programmed onto the control unit 150 can be done within the same service that generated the data, if an error has occurred in any stage of the programming, the error will be identified and can be resolved. As such, the reliability of the data is further improved.

[0141] Furthermore, if in verifying the integrity of the data, the manufacturing service 113 could identify a change or an unexpected report, which can be an indicator that the data or a part of the programming process is unreliable. If such an identification is made, appropriate security actions could be taken to rectify the problem. Thus, the security of the manufacturing process further improved.

[0142] Securely connecting the medicament dispenser with the cloud

[0143] Referring back to Figure 1 , after the programming of a cartridge 125 and control unit 150, these may then be combined to form a medicament dispenser. In doing so the encryption keys could be used to confirm that the cartridge 125 and control unit 150 are authentic, for example to prevent an unauthorised cartridge being used.

[0144] It is further desired that the assembled medicament dispenser is securely and safely connected to the cloud server 110, to enable the dispenser to communicate with the cloud network 110. This secure connection to the cloud may be used to transfer data that enables monitoring of the dispenser by the cloud, such as battery levels, dosing information, etc.

[0145] The method of securely connecting the medicament dispenser to the cloud server 110 is referred to herein as "provisioning". This method enables, for example, the control unit 150 to validate the cloud server 110, and vice versa, to ensure that the cloud and control unit are authentic so that a secure communication channel can be set up.

[0146] Generally, therefore, there is a desire for safe and secure communications between the control unit 150 and the cloud-based network. This is advantageously provided by a secure communication channel between the control unit 150 and the cloud server 110, as enabled by the following inventive system and method.

[0147] Reference is made to Figure 1 , and as discussed above, the user device 140 and provisioning service 114 collectively work together to provide a means to communicate with the control unit 150. The user device 140 is for example a mobile telecommunications device (e.g., a mobile telephone) that is configured to run what is termed a "soft gateway". This is an application that is able to communicate data between the control unit 150 and cloud server 110. The application is able to do this (and may be configured to do this) such that there is no manipulation of the data. In other words the device 140 is able to act merely as a pass-thru' device.

[0148] The provisioning of the control unit 150 enables it to be authenticated with the cloud server 110, and ultimately, if desired, tied to a specific user. After provisioning, the control unit 150 and the cloud server 110 are set up with a secure communication channel. When that is all in place, communications between the control unit 150 and the cloud server 110 are end-to-end encrypted. The communications will pass through the user device 140, which is acting at this point as the aforementioned "soft gateway".

[0149] The method comprises pairing or bonding the mobile device 140 with the control unit 150. This can use a typical BLE pairing with PIN code, or any suitable wireless pairing method. A unique device ID for the control unit 150 (which may be stored thereon, following the method discussed above) may be sent to the user device 140.

[0150] The user device 140 then communicates with the provisioning service 114 via the provisioning API 142, sending the device ID for the control unit 150 to allow the user device 140 to claim the control unit 150, using this unique ID. Upon receiving the request to claim the control unit 150, the provisioning service 114 obtains a certificate and creates a suitable challenge that is sent to the control unit 150.

[0151] The control unit 150 is configured to decrypt this challenge and reply back to the provisioning service 114. In doing so, the provisioning service 114 can then set up the desired end-to-end secure communications channel, and (if desired) tie the medicament dispenser to a specific user.

[0152] Accordingly, following the above method, the control unit 150 and the cloud server 110 can set up a secure communication channel via the user device 140 acting as a "soft gateway" as aforesaid.

[0153] This secure communications channel can be used to implement various features, such as those mentioned above. For example, the control unit 150 can send usage and dosage data to the cloud server 110. In some embodiments, a medical practitioner could load, change or update the control unit 150 remotely, or access and review the dosage history.

[0154] Figure 4 shows an example of an inventive method for establishing a secure communication channel between the control unit 150 and a the cloud server 110. An optional first step includes downloading an application to the user device 140, for example from an application store. Alternatively the user device 140 may have the appropriate application already stored thereon.

[0155] A communications channel is then established between the control unit 150 and the user device 140, for example "pairing or bonding" as described above. Similarly, a communications channel is established between the user device 140 and the cloud server 110, which is likely to be via the internet.

[0156] The method is aimed at authenticating both the control unit 150 and the cloud network 110 with each other. This may include sending a unique device ID to the application on the user device 140, which is then forwarded on to the cloud server 110. The cloud server 110 can then identify the control unit 150 and associate, or pair this with the user device 140.

[0157] In order to authenticate both the control unit 150 and the cloud network 110, a certificate (or other security method) may be generated by the provisioning service as described above. This enables a challenge to be sent by the cloud server 110 to the user device 140, via the provisioning service 114.

[0158] The control unit 150 can then generate a response based on the certificate, which is then transferred from the control unit 150, via the "soft gateway", to the cloud server 110. The cloud server 110 then uses the response data to verify the control unit 150.

[0159] In the case of asymmetric keys, the cloud server 110 could encrypt a message in the form of a challenge using a public encryption key. The control unit 150 may hold the counterpart private encryption key, which enables the control unit 150 (and only the control unit 150) to decrypt the message and respond accordingly.

[0160] The response data may be stored in the cloud-based server 110 (e.g., cloud storage 110a) for use in communication between the cloud-based server 110 and the control unit 150.

[0161] Once the authentication is complete a secure (encrypted) communication channel is set up between the cloud server 110 and the control unit 150, via the user device 140 application acting as a "soft gateway". This means, for example, that the control unit 150 can send data securely to the cloud server 110 as described above, for example usage, battery or dosing data, which data can then be stored on the cloud server 110 and associated with the unique ID.

[0162] T ransfer of data

[0163] Figure 5 shows the cloud server 110 of Figure 1, as well as other cloud-based platforms, and is provided to illustrate further aspects of the present disclosure, as well as how the systems and methods disclosed herein can lead to improved experiences for both healthcare professionals and patients.

[0164] The system includes the cloud server 110, which may be a first cloud-based platform configured to receive, process, store and transmit first data. The first data may be the data packets identified above, including, for example the firmware for a control unit 150, the data tables for the cartridge 125, etc.

[0165] The system may further include a second cloud-based platform 410 configured to receive, process and store the first data, as well as receive, process, store and transmit second data. The second data may include personal information, such as medical records, etc.

[0166] At least some of the second data may be associated with the first data. For example, some of the second data may be the result of processing the first data, or the second data could be information relating to the first data. The relationship may be that the second data is personal information for the first data. Other relationships are possible.

[0167] It may be that the first data is anonymised. For example, a control unit 150 could be paired up with a cartridge 125 and / or user device 140 as discussed above, but using a unique ID code instead of personal information (e.g., a name). Then, the second data could be associated with that unique ID so that in the second cloudbased platform 410, and anything connected to it, personal information could be provided with the data from the first cloud-based platform. In this scenario, the control unit 150, cartridge 125 and the first cloud-based platform 110 may never store personalised data.

[0168] The user device may comprise a first application 412, which may be the "soft gateway" discussed above, which is able to communicate data (e.g., the anonymous first data) between the control unit 150 and first cloud-based platform 110. The first application 412 is configured such that there is no substantial (or any) manipulation of the data being passed through to the control unit 150.

[0169] The user device 140 may comprise a second application 414 that provides a user interface, for example for a healthcare professional or user.

[0170] Each of the first and second applications 412, 414 are configured to be operable on the user device 140 to receive, process, store and transmit data.

[0171] The system may permit data communication between the first application 412 and the first cloud-based platform 110, in particular of the first data. This may be via any suitable communication channel. The first data may be transferred to the second cloud-based platform 410 (from the first cloud-based platform 110) and processed therein. The second data may be transferred between second application 414 and the second cloud-based platform. In order to avoid any risk of personal data being sent to or stored in the first cloud-based platform 110, the system is configured such that the second data is not (or cannot be) sent to the first cloud-based platform 110 or to the first application 412.

[0172] The system may comprise a third cloud-based platform 420, and the user device 140 may comprise a third application 416. The third application 416 could be similar to the second application 414 (e.g., a user interface).

[0173] It is not essential that the first, second and third application are located on the same device, and these could be located on different user devices. For example, the second and / or third applications could be located on a different device to that of the first application, and may be operable to receive, process, store and transmit data on that different device in the same manner.

[0174] The third cloud-based platform 420 and third application 416 may provide additional functionality, for example for a healthcare professional or user. For example, the third cloud-based platform 420 could be to store or process higher-level data (e.g., third data) in order to process this data to provide medical advice.

[0175] The use of second and third data could relate to different regulations and requirements on different types of data. For example, for personalised data, data protection regulations (e.g., "GDPR") may be applicable. Similar restrictions may apply for medical data (e.g., "HIIPAA" or "MDR"). It may therefore be advantageous to separate services in the system to handle different types of data in this manner.

[0176] The second data could be transferred between the second application 414 and the second cloud-based platform 420, and then to the third cloud-based platform 420 for storage and / or processing in the third cloud-based platform 420, for example to produce the third data.

[0177] The third data could then be sent to the third application 416 via the third cloudbased platform 420.

[0178] Similar to the second data, the third data cannot be transferred to the second application 414, second cloud-based platform 410, first application 412 or the first cloud-based platform 110.

[0179] For completeness, we note that the restriction of data transfer may not mean that data is prevented from being transmitted from the higher-level platforms downwards (although that is encompassed within this disclosure). It could be that the system does not mix the types of data. For example, if there is "second data" in the second cloud-based platform 410 and it is desired to transfer this to the first cloud-based platform 110, the data may be modified so that it no longer meets the requirements of the "second data" (e.g., personal information is removed).

[0180] The first application 412 could be replaced by direct communication between medical device and first cloud-based platform. For example, the soft gateway 412 may be required where direct communication between the control unit 150 and the first cloud-based platform 110 is not possible. In case such communication is possible, however, the first cloud-based platform 110 may communicate with the control unit 150 directly.

[0181] The first cloud-based platform 110, the second cloud-based platform 410 and the third cloud-based platform 420 may be configured to transfer and ingest data to and from external systems (e.g., EHR and EMR systems and third party software providers).

[0182] The system may allow healthcare providers and other third parties to provide analytical and monitoring tools, enabling more informed decisions on treatment and therapy processes. The third application 416 may be configured remotely by the third cloud-based platform 420.

[0183] The system may incorporate the use of third party data, particularly the use of third party biometric collection devices 510 and / or third party cloud-based platforms 512.

[0184] For example, some of the first data could be added to the first cloud-based platform 110 directly from a third-party biometric collection device 510, or indirectly via a third-party cloud-based platform 512. This enables more data ingestion points, and allows collaboration with other manufacturers who do not have access to cloudbased platforms.

[0185] Any of the first, second and third data could be exported to external data storage 610, for example for further processing 612, such as Al and / or analytics.

[0186] The methods, method steps, or functional features disclosed herein, for example in connection with the medical device, medicament dispenser, computer or computing device, cloud server or cloud-based network, platforms, etc. described above, may be implemented at least partially using software, e.g., computer programs. These may be located on a data processor on the control assembly itself. It will thus be seen that when viewed from further aspects the present invention provides computer software specifically adapted to carry out the methods, method steps, or functional features herein described when installed on data processing means, a computer program element comprising computer software code portions for performing the methods, method steps, or functional features herein described when the program element is run on data processing means, and a computer program comprising code means adapted to perform all the steps of a methods, method steps, or functional features herein described when the program is run on a data processing system. The data processor may be a microprocessor system, a programmable FPGA (field programmable gate array), etc. Where applicable, the methods, method steps, or functional features disclosed herein may be implemented on a virtual server or “cloud”, such as a cloud server or cloud-based network.

[0187] Although the present invention has been described with reference to various embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the scope of the invention as set forth in the accompanying claims.

Claims

Claims1. A method for programming a medicament dispenser, the method comprising: connecting a first component of the medicament dispenser to a computing device in such a manner that allows the computing device to load data onto the first component; sending a data request from the computing device to a data service of a cloud-based network; generating, in the cloud-based network, a data package for sending to the computing device as a result of the data service receiving the data request from the computing device, wherein the data is collected from a data store within the cloudbased network, and the generating is done completely within the cloud-based network; sending the data package from the cloud-based network to the computing device; and transferring, by the computing device, data from the data package to the first component of the medicament dispenser.

2. The method of claim 1 , wherein the first component is a cartridge for containing medicament.

3. The method of claim 2, wherein the data package includes information relating to the type of medicament within the cartridge and / or one or more security / authentication credentials.

4. The method of claim 2 or 3, wherein the method is for programming a plurality of medicament dispensers, and comprises connecting a plurality of cartridges, each corresponding to a different medicament dispenser, to the computing device, the computing device configured to transfer data onto each of the plurality of cartridges in a sequential manner.

5. The method of claim 4, wherein the step of sending a data request includes requesting data for all of the plurality of cartridges in a single request, and the data package generated in the generating step includes data for all of the plurality of cartridges.

6. The method of claim 5, wherein the step of sending the data package includes downloading the entire data package from the cloud-based network and storing it locally, so that the computing device can access the data relating to each separate cartridge and transfer this to each cartridge sequentially as aforesaid.

7. The method of any preceding claim, further comprising connecting a controller of the medicament dispenser to a second computing device in such amanner that allows the second computing device to load data onto the controller, wherein the method further comprises: sending a second data request from the second computing device to the data service of the cloud-based network; generating, in the cloud-based network, a second data package for sending to the second computing device as a result of the data service receiving the second data request from the second computing device, wherein the data is collected from a second data store within the cloud-based network, and the generating is done completely within the cloud-based network; sending the second data package from the cloud-based server to the second computing device; and transferring, by the second computing device, data from the second data package to the controller of the medicament dispenser.

8. The method of claim 7, wherein the second data package includes information relating to the firmware of the controller and / or one or more security / authentication credentials.

9. The method of claim 7 or 8, wherein the data package for the cartridge may include a first encryption key, and the second data package may include a second encryption key, wherein the first and second encryption keys form an asymmetric pair enabling authentication of the cartridge using asymmetric encryption.

10. The method of claim 7, 8 or 9, further comprising assembling the medicament dispenser with the controller and the first component to complete assembly of the medicament dispenser ready for use.11 . The method of claim 1 , wherein the first component is a controller of the medicament dispenser, and the data package includes information relating to the firmware of the controller and / or one or more security / authentication credentials.

12. The method of any preceding claim, further comprising providing a mobile telecommunications device that is configured to run a software application configured to communicate data between the medicament dispenser and the cloudbased network, wherein the software application is configured to pass data from the medicament dispenser to the cloud-based network without substantially any manipulation of the data.

13. A system for programming a medicament dispenser, the system comprising: a cloud-based network comprising a plurality of data services, each data service comprising a set of routines stored on the cloud-based network, as well as one or more data stores within the cloud-based network; a first computing device configured to request a first data package from a first of the data services of the cloud-based network,wherein, upon receiving a request for a data package from the first computing device, the first data service is configured to process the request and return a first data package to the first computing device, the first data package comprising data collected from the one or more data stores of the first data service, wherein the first computing device is configured to transfer data within the received first data package to a component of the medicament dispenser.

14. The system of claim 13, wherein the component of the medicament dispenser is a cartridge for containing medicament, and the system further comprises a second computing device configured to request a second data package from a second of the data services of the cloud-based network, wherein, upon receiving the request for a second data package from the second computing device, the second data service is configured to process the request and return a second data package to the second computing device, the second data package comprising data collected from the one or more data stores of the second data service, wherein the second computing device is configured to transfer data within the received data package to a controller of the medicament dispenser.

15. A method of establishing secure communication between a medicament dispenser and a cloud-based server, the method comprising: establishing a first communication channel between the medicament dispenser and a mobile telecommunications device; establishing a second communication channel between the mobile telecommunications device and a cloud server; transferring device identification data from the medicament dispenser to the mobile telecommunications device via the first communication channel; sending the device identification data to the cloud server via the second communication channel, and storing the device identification data on the cloud server; generating, within the cloud server, an authentication data file configured to be processed by the medicament dispenser for authenticating the cloud server and / or the medicament dispenser; sending the authentication data file to the medicament dispenser via the mobile telecommunications device; processing, by a processor of the medicament dispenser, the authentication data file and generating a response based on the processing that authenticates the cloud server and / or the medicament dispenser; and sending the response to the cloud server via the mobile telecommunications device.

16. The method of claim 15, further comprising providing a software application on the mobile telecommunications device configured to transfer data between the mobile telecommunications device and the cloud server and / or the medicament dispenser.

17. The method of claim 15 or 16, wherein the authentication data file uses asymmetric encryption.

18. The method of claim 15, 16 or 17, further comprising receiving the response at the cloud server and verifying, by a software program within the cloud server, the response as authentic, and then, only if the response is verified as authentic, setting up a secure communications channel between the cloud server and the medicament dispenser via the mobile telecommunications device.

19. The method of any of claim 18, further comprising sending usage data from the medical device to the cloud server via the secure communications channel.

20. A system for establishing secure communication between a medical device and a cloud-based server, the system comprising: a medical device; a mobile telecommunications device; and a cloud server, wherein the mobile telecommunications device is configured to transfer data between the medical device and the cloud server, wherein the cloud server is configured to generate, within the cloud server, an authentication data file configured to be processed by the medicament dispenser for authenticating the cloud server and / or the medicament dispenser, and then to send the authentication data file to the medicament dispenser via the mobile telecommunications device, wherein the medicament dispenser is configured, by a processor thereof, to receive and process the authentication data file and generate a response based on the processing that authenticates the cloud server and / or the medicament dispenser, and then to send the response to the cloud server via the mobile telecommunications device.

21. The method or system of any of claims 15-20, wherein the mobile telecommunications device is configured to run an application that is able to communicate data between the medical device and the cloud server, and the application is configured to pass data from the medical device to the cloud server without substantially any manipulation of the data.

22. A system for transferring data between different cloud-based networks and a plurality of user devices, the system comprising: a first cloud-based network in data communication with a plurality of user devices, the user devices configured to collect first data, wherein the first cloudbased network is configured to receive, process, store and transmit the first data; a second cloud-based network configured to receive the first data, and process, store and transmit second data, wherein at least some of the second data is associated with the first data,wherein the system is configured such that the second data is not, and cannot be sent from the second cloud-based network to the first cloud-based network.

23. A system as claimed in claim 22, wherein the user devices are medicament dispensers and the first data includes usage information of the medicament dispensers.

24. A system as claimed in claim 23, wherein the first data is non-personalised, and the second data includes personal information of the users of the medicament dispensers.

25. A system as claimed in claim 23 or 24, wherein the second data includes medical information of the users of the medicament dispensers.

26. A system as claimed in any of claims 23-25, further comprising a third cloudbased network configured to receive the second data, and process, store and transmit third data, wherein at least some of the third data is associated with the second data, wherein the system is configured such that the third data is not, and cannot be sent from the third cloud-based network to the second or first cloud-based networks.

27. A system as claimed in any of claims 23-26, further comprising a plurality of mobile telecommunications devices, each configured to provide the aforesaid communication between the first cloud-based network and the user devices, such that each user device is configured to send respective first data to the first cloudbased network via a respective mobile telecommunications device.

Images