rfid simulation of the us pharmaceutical supply chain
DESCRIPTION
Modeling Registry Network Traffic in the Pharmaceutical Supply Chain joint project - MIT Auto-ID Labs and SAPTRANSCRIPT
© Auto-ID Labs 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 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 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, RFID\EPC 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 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 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 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 7
Safe & Secure Supply Chain
Authentication
Product Identity
Physical Features
Pedigree
Track
Trace
Is the Product Genuine?
Is the Chain of Custody Intact?
Is the EPC associated with the item valid?
Does the item have expected covert or overt features?
Where is the product and where is it headed?
Where was the product? (Locations 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 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 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
3.1
The sys
facility
“Ports”.
“endpoi
Service
Figure 2
The ph
Wholes
-ID Labs
Softwa
tem is desig
is totally in
. Facilities a
ints” that ca
endpoints o
2 Simulator
hysical supp
aler, Tier 2
are Arch
gned to run
ndependent o
are known b
an be either
on a differen
r Layers wit
ply chain i
2 Wholesale
hitectur
on a single
of all other
by their “Fa
references
nt machine.
th Scheduler
is organize
er, and so o
re
machine in
facilities an
acilityID” an
to facility o
.
r and Regis
d into Tier
on with the
n a massivel
nd interacts
nd the Sche
objects on th
stry Services
rs, such as
Retailer Ti
ly threaded
by receivin
eduler maint
he same ma
s
s Manufact
er being th
environmen
ng messages
tains a regis
chine or We
turing Tier,
e final Tier
10
nt. Each
s on
stry of
eb
, Tier 1
r (Figure
© Auto
2). The
orders a
Figure 3
There a
the Sou
goods b
purchas
Request
Both the
example
Request
day the
elapsed
million
manufac
warehou
-ID Labs
e physical g
are propagat
3. The Supp
re two spec
urce and Sin
because the
ser of good
ts into the s
e source an
e, the flow
ts to the Re
en once the
to reach st
items per
cture goods
uses is finit
goods flow
ted upstream
ply Chain O
cial Facilitie
nk. These a
Source act
ds and also
ystem.
nd the sink c
of goods t
etail Tier. F
e purchase
teady state
r day. This
s and there
e.
w downstrea
m until a fac
Organized in
es in our mo
are named
ts as the un
o simulates
can be used
through the
For example
orders hav
the average
s can be
e is no los
am from th
cility is able
nto Tiers and
odel that are
from the p
niversal prod
s purchaser
to control t
e system ca
e, if the Sin
ve reached
e flow of p
easily seen
s of goods
he manufact
e to satisfy t
d Facilities
e not in the
perspective
ducer of go
rs’ demand
the flow of
an be contr
nk issues re
the manufa
physical goo
n since on
in the sys
turer to the
them.
physical su
of the prod
oods. The S
ds by issuin
goods throu
rolled by th
equests for
acturers and
ods through
nly the uni
stem, and t
e retailer. P
upply chain,
duction of
ink is the u
ng Purchas
ugh the syst
he Sink issu
1 million it
d enough t
h any tier w
iversal Sou
the capacity
11
Purchase
, namely
physical
universal
se Order
tem. For
uing PO
tems per
time has
will be 1
urce can
y of the
© Auto-ID Labs 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 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
day and
warehou
Figure 7
4
The Sch
that dete
rate at w
also pro
shipped
-ID Labs
d only subm
uses fulfill i
7.4 The Fac
.2 The S
heduler keep
ermine the r
which purch
ovides “Tim
d downstream
mit them ups
incoming pu
cility State M
Schedu
ps track of
rate at whic
hase orders
mers” that s
m and when
stream ever
urchase ord
Machine Sh
uler
all the facil
ch manufact
are injecte
send trigger
n POs are se
ry 24 hours
ders.
howing Inco
lities. It also
tured goods
d by the ret
r events to t
ent upstream
. Similarly
oming and O
o provides a
s are injecte
tailers in re
the facilitie
m.
we can var
Outgoing Ev
a number of
d into the su
esponse to g
es that contr
ry the way i
vents
f control par
upply chain
goods being
rol when go
14
in which
rameters
n and the
g sold. It
oods are
© Auto-ID Labs 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
fun
exa
Figure 5
A port
laptop it
Since th
to pass
message
goods to
The CC
POF m
indepen
4.
The sim
third pa
-ID Labs
nction(s). T
ample, we c
5 The Port
with no me
t is possible
hese “intern
on its mes
es to the R
o or from a
CR arranges
messages ar
ndently (as a
.2.2 The
mulator is ca
arty registry
The way in
can wait unt
Abstraction
essages in i
e to create a
nal ports” co
ssages to a
Registry we
Facility to
s for every
e injected
autonomous
Registry
apable of sim
. There are
n which me
til N messag
n Showing t
its buffer co
around 7 mi
orrespond c
an external
can easily
a Registry W
Port to run
into the s
s state mach
mulating the
two kinds o
essages are
ges have arr
the Buffer a
onsumes ar
llion ports.
closely to so
Web Servi
push mess
Web Servic
n in its own
simulator th
hines).
e message t
of message t
e buffered c
rived before
and the Dele
round 175 b
ockets it is q
ice for proc
sages repres
e on a remo
n thread of e
he facilities
traffic both b
traffic to th
can be con
e passing th
egate Functi
bytes of me
quite easy t
cessing. Th
senting ship
ote machine
execution. T
s respond
between fac
e registry, n
ntrolled so
hem to the fu
ion
emory, so t
to arrange fo
hus, to simu
pment or re
e.
Thus, once
to these m
cilities and
namely “I’v
16
that for
function.
hat on a
for a port
ulate the
eceipt of
POR or
messages
also to a
ve
© Auto-ID Labs 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 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 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 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</bizTransaction>
<bizTransaction type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.A</bizTransaction>
</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</bizTransaction>
© Auto-ID Labs 21
<bizTransaction type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.B</bizTransaction>
</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</bizTransaction>
<bizTransaction type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.C</bizTransaction>
</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 22
<bizTransaction type="urn:epcglobal:fmcg:btt:po">urn:epcglobal:fmcg:bti:po:0614141073468.4</bizTransaction>
<bizTransaction type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.D</bizTransaction>
</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</bizTransaction>
<bizTransaction type="urn:epcglobal:fmcg:btt:bol">urn:epcglobal:fmcg:bti:bol:0614141073468.E</bizTransaction>
</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 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