Más contenido relacionado
Similar a RFID Simulation of the US Pharmaceutical Supply Chain (20)
RFID Simulation of the US Pharmaceutical Supply Chain
- 1. Modeling Registry Network
Traffic in the Pharmaceutical
Supply Chain
A State Machine Approach to Supply Chain Simulation
John R. Williams, Abel Sanchez1, Paul Hofmann, Tao Lin,
Ph.D., Michael Lipton, Krish Mantripragada2
1
MIT Auto-ID Laboratory
2
SAP Research Labs, Palo Alto
© Auto-ID Labs 1
- 2. Summary
In the future, when the Internet of Things becomes reality, serialized data (typically RFID
and/or barcode, based on EPCglobal, DOD/UID and other standards) can potentially be stored
in millions of data repositories world wide. In fact, large data volumes of serialized
information may be coming soon, as the global healthcare industry moves towards deploying
anti-counterfeiting standards as soon as 2009. Those data will be sent to enterprise
applications through the EPC Network Infrastructure. The data volume, message volume,
communication and applications with EPC Network Infrastructure will raise challenges to the
scalability, security, extensibility and communication of current IT Infrastructure. Several
architectures for EPC Network Infrastructure have been proposed. So far, most pilots have
focused on the physical aspects of tag readings within a small network of companies. The lack
of data quantifying the expected behavior of network message traffic within the future EPC
Network Infrastructure is one of the obstacles inhibiting industry moving to the next level.
This paper presents a simulator aimed at quantifying the message flows within various EPC
Network architectures in order to provide guidance for architecting a scalable and secure
network.
© Auto-ID Labs 2
- 3. 1. Introduction and Motivation
RFID/EPC technology enables the tracking of physical objects through their lifecycle without
direct human involvement. Through the wide range of initiatives, such as the one with retail
giants (Wal-Mart and Target), with Food and Drug Administration (FDA), numerous state
Boards of Pharmacy, aerospace (Airbus and Boeing), and Department of Defense (DoD) [1],
RFID/EPC/UID has demonstrated its great value for business operation automation. Taking
an airplane part as an example, it has the potential to be in any place of the world. Therefore,
the data for tracking this part can be recorded from any location. Considering the diversity of
organizations potentially dealing with this part: manufacturer, airline, maintenance and repair,
there could be thousands of data repositories that might record the information related to this
part.
The data stored in the data repositories and also on RFID tags with the new IT infrastructure
together form the EPC Network Infrastructure for the Internet of Things. Considering data
operations with an airplane part, the number of data repositories, the data volume, the number
of messages through the network, the business operations and business applications involved
are potentially far beyond the capacity of today’s IT infrastructure.
With the joint effort by academia and industry, RFIDEPC technology has made great
progress in the past few years. Up to now, most pilots have focused on the physical aspects of
© Auto-ID Labs 3
- 4. tag readings within a small network of companies. No quantified data has been collected for
the potential EPC Network Infrastructure. Several architectures for the EPC Network
Infrastructure have been proposed. However, due to the lack of the mechanism for evaluating
these architectures with quantified data, no common criteria can be researched.
This paper presents a supply chain simulator in order to obtain the quantified data of the
message flow in the future EPC Network Infrastructure. The design and development of such
a simulator is a complicated task as a number of dimensions needs to be considered, such as
scalability, extensibility, security, privacy, communication frequency, and in-time response.
The rest of this paper is organized as follows. Section 2 analyzes the requirements of the
simulator through a Pharmaceutical use case. Section 3 presents the software architecture for
this simulator environment. Section 4 discusses a few implementation issues and gives some
initial results. Section 5 concludes this paper.
2. Requirements
2.1 The Pharmaceutical Supply Chain
Counterfeit and compromised drugs are increasingly making their way into the public
healthcare system and are considered a threat to the public health by the Food and Drug
Administration (FDA) [2]. Counterfeit pharmaceuticals are a $32 billion dollar industry
representing 10 percent of the global market, according to the FDA. The recent increase in
© Auto-ID Labs 4
- 5. patients in the U.S. receiving fake or diluted drugs is focusing more attention on the need for
drug authenticity. In 2003, 18 million tablets of the cholesterol-lowering drug Lipitor, the
world’s best-selling prescription drug in 2004, were recalled by Pfizer in the United States
after fake pills were found in pharmacies [3]. In 2004, the FDA reported 58 counterfeit drug
cases, a 10-fold increase since 2000 [4].
Supply chains consist of several kinds of enterprises, such as manufacturers, transportation
companies, wholesalers, and retailers. The pharmaceutical supply chain is one of the most
complex supply chains and can have as many as a dozen or more enterprises between the
manufacturer and the customer. Recently, the growth of counterfeiting has led to a number of
states in the United States of America considering laws that require the pedigree of every
saleable unit of drugs be tracked. To date, over 30 states have proposed or passed pedigree
legislation. In the case of California a digital document tracking each saleable unit with a
unique identifier must be initiated by the manufacturer, transmitted downstream step by step
to the dispensing pharmacy, and appended to by each enterprise along the way, with digitally
signed details of every shipping and receiving event. There are several proposals being
considered for how this digital document should be produced. The FDA Counterfeit Drug
Task Force has recommended “a combination of rapidly improving ‘track and trace’
technologies and product authentication technologies” to protect the pharmaceutical drug
supply (Combating Counterfeit Drugs, Feb 18, 2004).
Four feature characteristics are paramount to widespread adoption and impact:
• Automated – the high volume and high variance of pharmaceutical packages makes it
impractical for supply chain participants to economically authenticate packaging manually.
Therefore, there is a need for authentication that is automated – needing little to no human
© Auto-ID Labs 5
- 6. involvement or interpretation to authenticate the packaging. Automated Strong Authentication
requires electronic acquisition of information from product packages in mass and without
special handling.
• Secure – In order to have high confidence that the product is authentic, the expected features of
the package, either physical, electronic or the combination of both, must be difficult or
economically impractical to duplicate and simulate.
• Private - Concerns for consumer privacy must be respected.
Response in-time – As companies cannot ship or use product until pedigrees are received
and authenticated, timely response for all pedigree-related transactions is required
2.2 Options for e-Pedigree
In varying degrees, all of the state and federal legislative initiatives require a document to be
passed along the supply chain along with the physical product. Many of these states, such as
California, require an electronic document tied to unique serial numbers. The e-Pedigree
standard recently ratified by EPCGlobal Inc. provides a ratified XML schema for such a
document (see Figure 7.1).
© Auto-ID Labs 6
- 7. Safe & Secure
Supply Chain
Is the Is the Chain
Product Authentication Pedigree of Custody
Genuine? Intact?
Is the EPC
associated with the Product Where is the
item valid? Track product and where
Identity is it headed?
Does the item have Where was the
Physical
expected covert or Trace product? (Locations
overt features? Features and Custodians)
Figure 1 Base Reference Model for Secure Supply Chain (EPCGlobal Inc. E-Pedigree)
Thus, when the manufacturer makes a shipment of say N items a pedigree document will
accompany the shipment listing the manufacturer, the date of shipment, the type of product,
and the EPC codes of all the items. A hash of this document is then computed and signed with
the manufacturer’s private key (using the public key infrastructure). Upon, receiving the
goods the wholesaler will add to the e-Pedigree details of the receipt and will again hash and
sign the document. The wholesaler will then add further to the document upon shipment.
This, process is repeated at every receipt and shipment event until the goods reach the
dispensing pharmacy. At each level, the signed inbound e_Pedigree documents must be
embedded into the outbound document, creating a complex nested document.
One disadvantage of this system is that downstream customers may gain knowledge of
upstream enterprises business practices. For example, if the manufacturer produces only one
© Auto-ID Labs 7
- 8. e-Pedigree document for say 500 items then everyone downstream can see that the
manufacturer shipped this quantity of goods. To obviate this issue, manufacturers may choose
to produce a separate e-Pedigree document for every item (or case) shipped.
There is concern in the industry that the size and number of e-Pedigree documents will be
large resulting in a problem as the system scales.
2.1.1. The Registry concept
Several alternatives to the document passing scheme have been proposed. One alternative is
that e-Pedigree “fragments” remain with the “owner” and that the “fragments” be assembled
“on the fly” only if required by some authority. Thus, instead of passing on the actual e-
Pedigree document, a link to this “fragment” would be either passed along the supply chain or
possibly passed to some third party registry. Within this concept there are numerous
variations, with more or less information stored in the registry, implying more or less effort
to assemble the pedigree when required.
© Auto-ID Labs 8
- 9. 3. Supply Chain Network Simulator
In order to explore the implications of various approaches to granularity, security, and
alternative pedigree models, a simulator is being developed. The simulator is composed of
N supply chain tiers, such as Manufacturer, Wholesaler or Retailer, where each tier may have
an arbitrary number of facilities. Each facility is modeled as a state machine running in its
own thread of execution.
Just like the links in a metal chain the members of a supply chain may only have business
relationships with their immediate neighbors. They may or may not know about more distant
members of the chain and even if they are aware of their existence they may not have a
business relationship with them.
The supply chain functions by executing business events between trading partners. One party
initiates an event by sending a message to the other party, such as a Purchase Order (P.O.
message).
The state of a facility is determined by the number of Purchase Orders it has pending and how
much stock it has accumulated in its Warehouse. The simulation is driven by Purchase Orders
that are submitted “upstream” by the retail tier. Goods are manufactured in response to
purchase orders and are shipped “downstream”. Initial results show the simulator is capable of
modeling 100,000 facilities and 100 million items of product being injected into the system
per day. The load on the registry can vary by a factor of over 1000 in peak to average load
with around 200 messages per second being the peak load for a 1 million per day flow.
© Auto-ID Labs 9
- 10. 3.1 Softwa Arch
are hitectur
re
The system is desig
gned to run on a single machine in a massivel threaded environmen Each
n ly nt.
ndependent o all other facilities an interacts by receivin messages on
facility is totally in of nd ng s
“Ports”. Facilities a known b their “Fa
. are by acilityID” an the Sche
nd eduler maint
tains a regis of
stry
“endpoi
ints” that ca be either references to facility objects on th same machine or We
an o he eb
Service endpoints o a differen machine.
on nt .
Figure 2 Simulator Layers wit Scheduler and Regis Services
r th r stry s
The ph
hysical supp chain i organized into Tier such as Manufact
ply is rs, s turing Tier, Tier 1
,
Wholesaler, Tier 2 Wholesale and so o with the Retailer Tier being the final Tier (Figure
er, on r
© Auto-ID Labs 10
- 11. 2). The physical g
e goods flow downstrea from th manufact
w am he turer to the retailer. Purchase
e P
orders a propagat upstream until a fac
are ted m cility is able to satisfy t
e them.
Figure 3 The Supp Chain O
3. ply Organized in Tiers and Facilities
nto d
There are two spec Facilitie in our mo that are not in the physical su
cial es odel e upply chain, namely
,
the Sou
urce and Sin These a named from the perspective of the prod
nk. are p duction of physical
goods b
because the Source act as the un
ts niversal prod
ducer of go
oods. The Sink is the universal
u
purchas of good and also simulates purchaser demand by issuin Purchas Order
ser ds o s rs’ ds ng se
Request into the system.
ts
Both the source an the sink c be used to control the flow of goods throu the syst
e nd can t ugh tem. For
example the flow of goods t
e, through the system ca be contr
e an rolled by th Sink issu
he uing PO
Request to the Re
ts etail Tier. F example if the Sin issues re
For e, nk equests for 1 million it
tems per
day the once the purchase orders hav reached the manufa
en e ve acturers and enough time has
d t
elapsed to reach st
teady state the average flow of physical goo through any tier will be 1
e p ods h w
million items per day. This can be easily seen since on the uni
r s n nly iversal Sou
urce can
manufac
cture goods and there is no loss of goods in the sys
s e stem, and t capacity of the
the y
warehou is finite.
uses
© Auto-ID Labs 11
- 12. 3.2 Purchase Order Request
When a purchase order request message is posted to a facility the facility checks its
warehouse for the items required. If the warehouse can fulfill the order then the items are sent
to “shipping” were they are stored until shipped. If the warehouse cannot fulfill the order then
the order is sent to the PO Consolidation Store and a copy is sent to the PO Pending
Fulfillment Store. The items sent to the PO Consolidation Store are aggregated by SKU ID
and held there until a trigger from the Scheduler initiates sending the new consolidated POs
upstream. The facility therefore generates new PORs and these may be issued in “bursts” at
various times of the day. These bursts do not generate event traffic to the Registry but to add
variability to the supply chain.
The facility is able to aggregate purchase orders and hold them for some period of time. In a
real supply chain a distributer may apply various strategies to manage their inventory,
including pre-ordering items based on past history. The simulator is able to accommodate
such strategies.
3.3 Purchase Order Fulfilment
When physical goods representing a filled inbound purchase order arrive at a facility they are
immediately moved to the Warehouse. When new stock arrives in the warehouse the store of
outbound POs Pending Fulfillment are scanned to see if any can now be filled. If an outbound
PO Request can now be filled the items are removed from the warehouse and sent to Shipping
where they await a shipping event trigger from the Scheduler.
© Auto-ID Labs 12
- 13. 4. Implementation
4.1 Modelling Facilities as State Machines
Each facility is represented as a state machine running in its own thread of execution. The
state of the facility is modified by two kinds of events, namely Purchase Order Request
Messages (POR) that represent purchase orders and Purchase Order Filled Messages (POF)
that accompany goods being received. These messages are received on two external message
ports, one for each kind of message. The state of the facility is represented by the following:
1. The number and type of goods stored in the Warehouse as a result of goods received,
2. The Unfulfilled POR Store that keeps track of purchase order requests that have been
sent upstream but have not yet been filled. ie goods are not yet available in the
Warehouse to fill these orders.
There are also two temporary stores, namely the Shipping Store, where goods are
accumulated before being shipped downstream and the Consolidated PO Store where
incoming POs that cannot be filled locally by the Warehouse are aggregated and then sent
upstream as new POR messages. These temporary stores are “emptied” and the messages
fired upon receipt of trigger messages from the global “Scheduler”. The Scheduler allows us
to inject delays into the facility that represent the time taken by the facility to say ship goods
from the Warehouse.
These two stores, one for digital documents (POs) and the other for physical goods
(Warehouse) allow us to add rules and strategies into how purchase orders are aggregated and
the timing of their submittal. For example, we might consolidate all purchase orders for one
© Auto-ID Labs 13
- 14. day and only subm them ups
d mit stream ever 24 hours. Similarly we can var the way in which
ry ry i
warehou fulfill i
uses incoming pu
urchase ord
ders.
Figure 7 The Fac
7.4 cility State M
Machine Sh
howing Inco
oming and O
Outgoing Ev
vents
4.2 The S
Schedu
uler
The Sch
heduler keep track of all the facil
ps lities. It also provides a number of control par
o f rameters
that dete
ermine the r at whic manufact
rate ch tured goods are injected into the su
s upply chain and the
n
rate at w
which purch
hase orders are injected by the ret
tailers in re
esponse to g
goods being sold. It
g
also pro
ovides “Tim
mers” that s
send trigger events to the facilitie that contr when go
r t es rol oods are
shipped downstream and when POs are se upstream
d m n ent m.
© Auto-ID Labs 14
- 15. The messages for POR and POF are inherited from the base POMessage class shown below.
Each message contains a PO and the address of the sender of the message. The Scheduler is
responsible for translating FacilityIDs to actual endpoints to which the message is delivered.
These endpoints are called “Ports” and are the building blocks of our simulator.
public class PO
{
public FacilityID nextDestination;
public int skuID;
public int numItems;
}
public class POMessage
{
public PO body;
public FacilityID senderFacilityID;
}
4.2.1 The Port Abstraction
One novel aspect of the simulator is that it is built upon the Microsoft Coordination and
Concurrency Runtime [4]. The runtime provides support for multi-threaded
programming. It provides an abstraction called a Port that deals with messages of a
single type. A port allows messages to be “Posted” to it and there is a buffer that stores
the messages. A multi-cast delegate can be attached to the Port and when messages
arrive on the Port they are passed to the delegate for processing. There is the concept of
“Activating” a port which triggers the passing of the messages to the delegate
© Auto-ID Labs 15
- 16. fun
nction(s). T way in which me
The n essages are buffered c be con
e can ntrolled so that for
exa
ample, we c wait unt N messag have arr
can til ges rived before passing th to the function.
e hem fu
Figure 5 The Port Abstraction Showing t Buffer and the Dele
n the a egate Functi
ion
A port with no me
essages in i buffer co
its onsumes ar
round 175 b
bytes of me
emory, so that on a
laptop it is possible to create a
t e around 7 million ports.
Since th
hese “intern ports” co
nal orrespond c
closely to so
ockets it is q
quite easy t arrange for a port
to fo
to pass on its mes
ssages to a external Web Servi for proc
an ice cessing. Th
hus, to simu
ulate the
message to the R
es Registry we can easily push mess
sages repres
senting ship
pment or re
eceipt of
goods to or from a Facility to a Registry W Service on a remo machine
o Web ote e.
The CC arranges for every Port to run in its own thread of e
CR s n n Thus, once POR or
execution. T
POF m
messages are injected into the s
simulator th facilities respond to these messages
he s m
indepen
ndently (as a
autonomous state mach
s hines).
4.
.2.2 The Registry
The sim
mulator is ca
apable of sim
mulating the message traffic both b
e t between fac
cilities and also to a
third pa registry. There are two kinds o message traffic to the registry, n
arty of t namely “I’v
ve
© Auto-ID Labs 16
- 17. touched EPC X” messages, and query messages of the kind “Who has seen EPC X?” The
first kind of message traffic results from shipments received (incoming POFs) and from
shipments shipped (outgoing POFs). This traffic places into the registry notification events for
each EPC code involved. A typical message might contain the following: EventType, EPC,
Shipper, DateTime, Receiver, PedigreeHash, PedigreeURI
According to the EPCIS 1.0 specification this traffic is likely to aggregate together all EPCs
read at one time (we note that there is as yet no specification for these messages). It is likely
that these messages will conform either to the EPCIS 1.0 specification or something quite
similar. (Appendix I shows an EPCIS 1.0 conformant Ship Order Event)
The Registry will probably respond to such messages with a simple acknowledgement, and
therefore the incoming messages can be buffered by the Registry to smooth any peaks in the
message traffic.
The second kind of message traffic results from queries, such as Pedigree queries, which
require a more elaborate response and which are likely to be time sensitive. Thus, these
queries should be answered in a “timely” manner by the Registry. The query response time
will depend on the volume of data to be searched (EPC data must be stored for several years)
and therefore partitioning of the Registry data may be critical. MIT and SAP are presently
working on strategies for partitioning in-memory databases spread over many machines
(based on the Google model).
4.2.3 Security and Authorization
© Auto-ID Labs 17
- 18. One element affecting the latency of the Registry responses is how authentication and
authorization will be achieved. If there is a single Registry and all supply chain participants
have security credentials pre-established then there are a number of standard methods for
dealing with both authentication and authorization. Authentication (who is making the query)
can be established by using X.509 certificates and the PKI [999] infrastructure. Authorization
requires the Registry to answer the question, “Does this person have permission to retrieve
data related to this EPC?” This is a more complex question because to answer it the Registry
must have knowledge of the kind of item to which the EPC is attached. For example, the EPC
might be attached to a packet of cornflakes or to a cruise missile. In the latter case, even
details about what companies are involved in the supply chain might be secret, let alone
details about the present location of the missile. Thus, the Registry must have “business rules”
that depend on the type of item (its SKU) and on the roles associated with that item.
If there are multiple Registries with multiple security boundaries (i.e. Registries operated by
different enterprises) then the problem becomes more complex, since standards for
communicating queries between Registries need to be established. This problem is presently
being researched by EPCGlobal Inc and the Architectural Review Committee and by the
Auto-ID Laboratories.
5 Simulator Performance
MIT and SAP are currently working on applying the simulator to analyze potential network
traffic of the pharmaceutical supply chain. Inputs for this model consist of item throughput
© Auto-ID Labs 18
- 19. statistics and queries to the Registry. Based on this model we expect to be able to develop
envelopes for the capabilities necessary for the various kinds of registry.
The present simulator, running on a Dell Latitude 620, is able to represent around one million
facilities, which consume around 1 GByte of memory. The CCR is very efficient in that only
those facilities that are “actively” processing messages consume resources. The performance
of the simulator is ultimately limited by the message traffic. Initial runs have simulated a
volume of 1million items per day with the simulator running in real time.
© Auto-ID Labs 19
- 20. APPENDIX I
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<epcis:EPCISDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:epcis="urn:epcglobal:epcis:xsd:1" xmlns:epcglobal="urn:epcglobal:xsd:1"
xsi:schemaLocation="urn:epcglobal:epcis:xsd:1 EPCglobal-epcis-1_0.xsd"
xmlns:hls="http://schema.hls.com/extension" creationDate="2006-06-25T07:15:00Z"
schemaVersion="1.0">
<EPCISBody>
<EventList>
<TransactionEvent>
<eventTime>2006-06-25T07:16:00Z</eventTime>
<bizTransactionList>
<bizTransaction
type="urn:epcglobal:fmcg:btt:po">urn:epcglobal:fmcg:bti:po:0614141073468.1</bizTransa
ction>
<bizTransaction
type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.A</bizTran
saction>
</bizTransactionList>
<epcList>
<epc>urn:epc:id:sgtin:0614141.107340.1</epc>
<epc>urn:epc:id:sgtin:0614141.107340.2</epc>
</epcList>
<action>ADD</action>
<bizStep>urn:epcglobal:fmcg:bizstep:shipping</bizStep>
<disposition>urn:epcglobal:fmcg:disp:sellable_available</disposition>
<readPoint>
<id>urn:epcglobal:fmcg:loc:0614141073468.RP-3</id>
</readPoint>
<bizLocation>
<id>urn:epcglobal:fmcg:loc:0614141073468.3</id>
</bizLocation>
</TransactionEvent>
<TransactionEvent>
<eventTime>2006-06-25T07:17:00Z</eventTime>
<bizTransactionList>
<bizTransaction
type="urn:epcglobal:fmcg:btt:po">urn:epcglobal:fmcg:bti:po:0614141073468.2</bizTransa
ction>
© Auto-ID Labs 20
- 21. <bizTransaction
type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.B</bizTran
saction>
</bizTransactionList>
<epcList>
<epc>urn:epc:id:sgtin:0614141.107342.1</epc>
<epc>urn:epc:id:sgtin:0614141.107342.2</epc>
</epcList>
<action>ADD</action>
<bizStep>urn:epcglobal:fmcg:bizstep:shipping</bizStep>
<disposition>urn:epcglobal:fmcg:disp:sellable_available</disposition>
<readPoint>
<id>urn:epcglobal:fmcg:loc:0614141073468.RP-3</id>
</readPoint>
<bizLocation>
<id>urn:epcglobal:fmcg:loc:0614141073468.3</id>
</bizLocation>
</TransactionEvent>
<TransactionEvent>
<eventTime>2006-06-25T07:18:00Z</eventTime>
<bizTransactionList>
<bizTransaction
type="urn:epcglobal:fmcg:btt:po">urn:epcglobal:fmcg:bti:po:0614141073468.3</bizTransa
ction>
<bizTransaction
type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.C</bizTran
saction>
</bizTransactionList>
<epcList>
<epc>urn:epc:id:sgtin:0614141.107344.1</epc>
<epc>urn:epc:id:sgtin:0614141.107344.2</epc>
</epcList>
<action>ADD</action>
<bizStep>urn:epcglobal:fmcg:bizstep:shipping</bizStep>
<disposition>urn:epcglobal:fmcg:disp:sellable_available</disposition>
<readPoint>
<id>urn:epcglobal:fmcg:loc:0614141073468.RP-3</id>
</readPoint>
<bizLocation>
<id>urn:epcglobal:fmcg:loc:0614141073468.3</id>
</bizLocation>
</TransactionEvent>
<TransactionEvent>
<eventTime>2006-06-25T07:19:00Z</eventTime>
<bizTransactionList>
© Auto-ID Labs 21
- 22. <bizTransaction
type="urn:epcglobal:fmcg:btt:po">urn:epcglobal:fmcg:bti:po:0614141073468.4</bizTransa
ction>
<bizTransaction
type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.D</bizTran
saction>
</bizTransactionList>
<epcList>
<epc>urn:epc:id:sgtin:0614142.107346.1</epc>
<epc>urn:epc:id:sgtin:0614142.107346.2</epc>
</epcList>
<action>ADD</action>
<bizStep>urn:epcglobal:fmcg:bizstep:shipping</bizStep>
<disposition>urn:epcglobal:fmcg:disp:sellable_available</disposition>
<readPoint>
<id>urn:epcglobal:fmcg:loc:0614141073468.RP-3</id>
</readPoint>
<bizLocation>
<id>urn:epcglobal:fmcg:loc:0614141073468.3</id>
</bizLocation>
</TransactionEvent>
<TransactionEvent>
<eventTime>2006-06-25T07:20:00Z</eventTime>
<bizTransactionList>
<bizTransaction
type="urn:epcglobal:fmcg:btt:po">urn:epcglobal:fmcg:bti:po:0614141073468.5</bizTransa
ction>
<bizTransaction
type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.E</bizTran
saction>
</bizTransactionList>
<epcList>
<epc>urn:epc:id:sgtin:0614142.107348.1</epc>
<epc>urn:epc:id:sgtin:0614142.107348.2</epc>
</epcList>
<action>ADD</action>
<bizStep>urn:epcglobal:fmcg:bizstep:shipping</bizStep>
<disposition>urn:epcglobal:fmcg:disp:sellable_available</disposition>
<readPoint>
<id>urn:epcglobal:fmcg:loc:0614141073468.RP-3</id>
</readPoint>
<bizLocation>
<id>urn:epcglobal:fmcg:loc:0614141073468.3</id>
</bizLocation>
</TransactionEvent>
© Auto-ID Labs 22
- 24. REFERENCES
[1] Available at http://www.acq.osd.mil/dpap/UID/
[2] Combating Counterfeit Drugs: A Report of the Food and Drug Administration Annual
Update, May 18, 2005, page 1. Available at
http://www.fda.gov/bbs/topics/NEWS/2005/NEW01179.html
[3] Cracks in the Pharmaceutical Supply Chain, January 15, 2006, page 1. Available at
http://www.cio.com/article/16565/Cracks_in_the_Pharmaceutical_Supply_Chain/1
[4] Ibid [2], page 2
[5] Giorgio Chrysanthakopoulos and Satnam Sing, “An Asynchronous Messaging Library for
C#” Microsoft Research Paper, http://research.microsoft.com/~tharris/scool/papers/sing.pdf
© Auto-ID Labs 24