Contents |
UNICEF. Contact person: Dmitri Davydov, tel. +45 3064900
Current system of UNICEF vaccine temperature monitoring does not allow for an automatic collection and transmission of data on the state of vaccine shipments during international distribution.
UNICEF uses stand-alone single-use electronic temperature loggers. The system is open to data loss (accidental or deliberate), it is passive during transport (vaccine cannot be saved if in danger), it has negative environmental implications (devices require specialised recycling in countries where it is not easily available), it requires manual start & stop of loggers, and it makes the reporting of the state of vaccine upon arrival incomplete, subjective & costly (it relies on the vaccine recipient to complete & return to UNICEF a paper form – Vaccine Arrival Report - which then needs to be manually entered into an Excel database).
'UNICEF is the World’s largest public buyer of vaccines, using over 200,000 shipping containers annually to distribute vaccines from 16 strategic suppliers to over 80 of the poorest nations. UNICEF is developing a product-service system capable of providing real-time temperature and positioning data on each vaccine shipping container to stakeholders (incl. vaccine suppliers, consignees, freight forwarders and UNICEF).
UNICEF and its partners require information on the contents (vaccine quantities, type, production batch numbers, etc), temperature conditions during transportation, location status and the proof/condition of delivery to consignee, for each vaccine shipment. The information is required to ensure vaccine safety as well as for insurance and quality assurance purposes. Currently, the gathering of this information requires manual verification and entry, incl. filling in of the Vaccine Arrival Report paper form (often in hand writing), printing, signing and faxing / emailing of this form to UNICEF where it requires interpretation and manual data entry into an Excel database.
UNICEF considers equipping each shipping box with a device that would store and stream real-time information on the current temperature and geographical position of the box to a website (or similar) accessible by relevant stakeholders (incl. vaccine suppliers, consignees, freight forwarders and UNICEF). Upon delivery to the destination, the consignee would return the device to enable its re-use.
Vaccine suppliers would ‘pre-load’ the device with the data on the contents of the box (vaccine type, quantity, expiration date, UNICEF order number, production batch number, etc), as well as with the alarm settings applicable to the specific vaccine type. Upon receipt of the shipment, the consignee would need to be able to report back to the system any discrepancies in the state of the vaccine that could not be automatically collected by the device (e.g., box was mechanically damaged, some vaccine vials were broken or missing, the contents of the box does not correspond to the supplier’s declaration, etc).
The proposal should elaborate on the process and method(s) of data transmission (GPS, GSM, etc), IT infrastructure, hardware & software, user interfaces, security of data access, data storage & retrieval, indication of the total cost of the system and the level of effort & expertise required to develop and implement the system. There must not be any transmission of live data while devices are on aircraft (devices would continue to record data for transmission after the plane has landed). Money is an issue so the solution must be practical; e.g., it should not rely exclusively on the introduction of additional specialty auxiliary devices such as RFID scanners, iPhones, etc., because these devices cannot be assumed to be available to end users.
The proposed concept and technical specifications should not pose a barrier to delivery by service providers from countries with emerging economies / economies in transition.
The proposed solution will represent a crucial contribution to the ongoing UNICEF project to develop and implement an economically and technically viable product-service system serving to enhance vaccine safety during international distribution. The project is led by DTU with the support from other academic institutions, international public organisations and private sector experts who contribute their technical expertise pro bono. UNICEF does not intend to enter into system development alliances with entities whose intention is to subsequently become commercial providers of this service to UNICEF. As UNICEF is committed to facilitating the transfer of innovative technologies to the developing economies, it envisions engaging potential providers of the service from a broader geographical and economic spectrum.
In order to have a better understanding of the proposed problem we would like to invite you to have an introductive reading on the topic: Guidelines on the international packaging and shipping of vaccines
As it is possible to see from the requirements and the use cases, the problem is quite complicated and require advanced and professional knowledge in very different fields. Analyzing it, it seemed natural for us to divide the problem in three different sub-problems, in order to separately find solutions and combine them afterwards. These are the followings:
Referring to the devices that are currently in use ($NAME_DEVICE), we worked on the concept for a single new device which would have the following new features:
The first is due to the new need expressed from our stakeholder, namely the transmission of data from the devices to a central service which will collect, analyze and publish them. It has been chosen the GSM network since with high probability our devices will travel in development countries, in which no other wireless connection is actually available. Moreover, this is a technology that is cheaper in terms of both battery consumption and technology used for the physical implementation.
Analyzing what these devices were required to do, we defined 5 different steps in the life cycle of a device, namely:
One of the main challenger in this project has been to understand the requirements for the system. Use Case 1 says that the device should stream real time data from the package to the server. When the device is in an airplane it is must not transmit any data. To transmit the data it has been chosen the GSM network since with high probability our devices will travel in development countries, in which no other wireless connection is actually available. Moreover, this is a technology that is cheaper in terms of both battery consumption and technology used for the physical implementation. GPS was suggested for location retrieval. The coverage of GPS is very limited indoor, and we also question the coverage when the the device is packed inside a truck. Because of these liabilities in the GPS protocol, we do not see this as a potential solution. During our analysis we realized that the precision we would get by using the GSM cells would be good enough for the requirements.
Another challenge in the project has been to make the device able to detect when it is in an airplane, and when it is not. We are not allowed (or even able to) transmit any data while in the plane. The crucial moments is during take-of and landing. To solve this issue, we decided to put in an accelerometer in the device, and only transmit data when the device is standing still, ie. when it is in the warehouse. We still want the device to transmit data when it is located on a truck, at the moment we do not have a solution how to distinguish between these two contexts. One way to do it would to build in a altimeter to measure the altitude.
Following what said in the above section, we will describe the main ideas behind each step of the life cycle of a device.
The vaccines will, depending on the its type, need to be kept at a specific temperature. For the device to know the temperature, it needs some kind of configuration. For the configuration of the device we had several ideas. The most interesting are two:
The system will be required to know what device is monitoring what package. At some time in the packaging we need to make a parring between the device and the package. For the package pairing we were imagining a system based on the scan of bar codes; the devices has some bar code and the box of vaccines has also its own bar code. Once these two bar code are scanned, the central server register the box with the relative control device. Of course, depending on which kind of configuration method has been chosen, here it is possibly needed execute some more operations.
One possible solution is to combine the parring and the configuration. When the two pieces are scanned, the system will transmit the configuration to the device. Depending on the communication protocol used, it could be SMS (Text Message) or through GPRS.
The main problem of the transportation has been understand how the devices could understand whether they are on a plane or not. This problem has been addressed by the use of an accelerometer. This device can perceive whether the object on which is placed is actually having an acceleration (put it simply if it is actually moving). So when the boxes are in movement the devices have not the permission of using the GSM network. This can be done just when the boxes have been still for a period x. When this happens, the devices communicate to the central server the information that have been periodically logged. This could seem not respecting the requirements, specifically about tracking; instead since the devices are supposed to log also information about the position, together with timestamps and temperature, the central server will be able to process this data once this will be sent. Moreover, constantly updating our Unicef contacts about how we were proceeding, in order to have feedbacks, we understood that actually the main problems they had with the vaccine transportation have been related with the boxes abandoned somewhere (airports, warehouse, etc.). Thus actually this solution ended up to be the best trade-off between performance constraints, logistic constraints and requirements.
Interviewing our stakeholders we discovered that one of the main issue of the existent system is retrieving some information from the target location on the state in which the vaccines have been received. This could means if something went wrong with the temperature control, or if something inside the boxes brake. The problem is related to the fact that this information should be inserted onto a paper form, so filled "analogically". This end up most of the time in unreadable documents that give no information at all about the state of the goods received. In order to solve this problem we were thinking to expand a bit the interface of the device, permitting the reporting of broken or unusable vaccines, just specifying for each box the number of items damaged. In this way we will not need anymore paper documents, and the information required could be on the server potentially in real time.
Since the device it is actually tracking it-self, if something goes wrong, i.e. the device is stolen, turned off, broken, etc., will be extremely simple and very accurate to determine who had the responsibility of the vaccines in the period of time in which the device stopped to send messages. This will reduce to a near-zero factor the percentage of loss of the devices. Moreover another idea we had in order to make it simpler the recollecting of the device, is that we could insert inside the vaccines box, in which the device is placed, another box in which the device can be inserted and which is already be prepared to be sent back to the Unicef Headquarter, or wherever we want to recollect those devices.
The data logging can be made in two different ways:
Another problem with which we faced with has been the data transmission; namely, when a device is actually going to send messages to the central server. We had different ideas in order to address this issue, the most important are the following:
About the communication we have been concerned about trying to define a protocol that could work using both TCP connections over the GSM network and SMS text messages. We have tried to do this since it is very possible that in the countries in which our devices are going to trying to contact the central server, the internet connection over the GSM network it is not supported. If this is the case, it would be possible to switch to an SMS-based communication protocol. During our simulations we have been creating and transmitting messages using a protocol that could fit in less than 100 characters all the information needed (temperature, timestamp and information about position). This means that actually both the implementation can be supported from a real device.
The central server is the machine that has to collect, store and analyze the data sent from the devices that are controlling the vaccines. Based on the previous discussion made on the device, the server could also execute extra work in order to produce alerts if it detects anomalous behavior based on the temperature and/or location information. Moreover, as required, it has to produce human readable information and statistics about whatever can be interesting to know from the stakeholders point of view.
A part the research that has been conducted in order to find the best solutions at this problem between all the possible ones, we have dedicated also a bit of the time we had in order to implement a proof of concept (PoC) to see and demonstrate if actually what we are planning to do it is actually implementable in a real world environment. In order to do it we implemented a program that is simulating the workload produced by 50 GSM devices. Moreover, a server that is collecting the data and exposing these information has been implemented in order to monitor the mocked devices. Furthermore, we had the possibility to insert in our PoC a real Accelerometer, in this way we could also simulate still packages and packages in movement. In order to show our experiment we are going to upload as soon as possible a video showing our simulation.
We are making a simulation of the life cycle of the vaccine shipments.
The central element in the concept is the device deployed in the package. We believe one of the most important next steps would be to make simple prototypes to test the coverage of GSM network when the device is located inside a truck, inside a warehouse etc.
The initial prototype could be deployed as a simple Android app. This would give a great insight to the issues regarding the prototype. It will be a simple test to see if the design ideas we have proposed would be possible in real life.
Many cellphones will have the required hardware (GSM and accelerometer) and will be a cheap way to test new ideas. The temperature measurement will be easy to add afterwards. Prototypes we envision:
For the future iterations of the project, a GUI needs to be created. Its purpose shall be to use the data received by the device to create statistical data exposing weaknesses in UNICEF’s logistical network. The GUI is planned to work through Google Maps or a similar service. The things of interest for UNICEF is to be able to track when a shipment is stuck, or overheats, for whatever reason, and to use the statistical data to search for patterns in these failures. A use scenario could look as below:
Initially, the user chooses to either watch all shipments currently out there on Google Maps, or to watch a database list view of all shipments in progress. The user is then to be able to, on either interface, mouse over or click on an individual shipment to see vital data about the shipment. Such as whether the shipment is too hot, it's 'heat history' - heat fluctuations over time in a graph - and similar stuff. Under the details of the shipment the user is then able to view at what point in time the temperature went wrong, if it has gone wrong, and where in the world the shipment where at the given time. For example if the shipment was 'in transit', or if it was stuck at an airport. The icons for the airport and in-flight is then portrayed under the time-line. These are also clickable so the user can see the statistics for the different airports and flight-routes which has been used. Also on the interface, in both map and database view, are the receivers of the shipments. The UNICEF staffs are then supposed to be able to input new data about various transport hubs and destinations, besides the data gathered by the statistical system. "There are often problems with this airports shipments to Ghana" or "this end receiver has usually problems with picking up packages during month X due to the monsoon" or whatever. In that way, UNICEFs experiences with different logistical partners and end receivers can be combined with the statistical data auto-generated by the system, allowing UNICEF to gain an overview about where the systemic problems and bottlenecks are in their overall logistical system. This will allow UNICEF to make a focused effort in terms of resolving their issues and run an efficient operation.
Below are some of the features suggested in the above text presented in a more code-like manner.
google maps: static image, url like [1] [2]
features:
Tracking of individual boxes overview of all shipments track & trace
onmouseover (shipment): show data of shipment plot temperature over time
onclick (shipment): see more details [was at these airports [...] for durations [...];
src airport = ... dst airport = ...]
onclick (airport): show [shipments whose edges have me as node]
stats of package standstill delay [per airport] airport pair: [shipments between, delivery success]
Making notes on {routes, airports, recipient warehouses (managers)}
In case of disputes: often involved airports probably suck, seldomly involved airports probably don't. Use/chart this.
Following shipments as they split and/or merge.
[correlate with external data; weather, political events(?)]
Further, an auto generation program needs to be generated for the Recipient Confirmation papers. UNICEF has problems with these papers not being filled properly, thus slowing their work process. In an attempt to prevent this, a script must be generated which auto-fills as much data as possible regarding the shipment in the papers. This will raise the likelihood that the parts of the paper UNICEF actually needs the end recipient to fill is actually filled, as he or she will no longer need to waste time filling in the redundant information already available to the system.
Below is first a link to the PDF document in question, as well as an overview in code format as to what data needs to be auto generated how and from what sources.
Link: UNICEF End Recipient papers
report no: recipient
date of report: when paper written
inspection timespace != date of report (often)
cold store == warehouse
[date of cold store <= date of inspect <= date of report]
PART 1 - ADVANCE NOTICE
"Did we get information in advance?"
clear customs ahead of time [so vaccine isn't stuck]
"[X] No" means problem
"Shipping notification": from airline, "your stuff is here[landed]"
[list other documents: registration at ??]
PART II -- []
AWB -- copied from form
airport of dest. -- known in system [?]
freighter -- packages documents, sends to recipient
Consignee reenters ETA/notif and TA/actual [datetime]
["on behalf of": {unicef country office, $NATION health ministry}] [name of clearing agent: "who cares?"]
PART III manufacturer(=supplier) knows everything, will fill in [have filled in]
purchase order number [8 digit 'ish] consignee = recipient
[sometimes, hypothetically manufacturers packs the wrong vaccine]
Vaccine // Diluent/droppers [DILUENT DONT NEED TEMP CONTROL :) packed seperately, normal boxes (no cool)]
supplier: knows vacc/dilute table data; consignee must confirm lot number: ["serial" number, which batch of live stuff made this shpmnt] prefill lot numbers, nothing else
[form-fillers: ministry employees] [qty recv per ship notif: ...]
PART IV --- docs with shipmnt
OFF-TOPIC: [[[implementation timeframe: mid 2011 -- whole system mapped [full & complete architecture // design spec] plan for business model for delivery of this system.]]]
[[[refurbish phones vs. mfgmt of own devices???]]]
PART IV --- docs with shipmnt
in "Box Number One" -- papers similar to advance notif. [were docs there?] [$this is vacc arr rpt]
tot. number of boxes: $$\sum_{each lot} nboxes(that lot)$$ (they should enter this manually, is easy and fairly certain)
[no coolant: shouldn't happen;; might be "dry ice evaporated"]
temp mon presnt: cold chain card: litmus-ish paper [only with dry ice] [current gadget incompatible with dry ice] vvm (vaccine vial monitor): dot on vial (on 98% of all vax),
long term temperature sensor, circle with square, square is lighter: good; square is as dark as or darker than circle: bad
[provide below details [only when bad]] gadget knows box number and lot number; should auto-fill these should auto-fill "Alarm in device" [alarm: no --> N/A] datetime -- pre-fill [EPI expanded program of immunization]