One medicine, five systems of record

Imagine a single carton of medicine moving from a manufacturer, through a distributor, and eventually into a hospital pharmacy.

Physically, it is one object.

Digitally, it may be five different things.

The commercial system knows what was ordered and sold. The warehouse system knows where inventory is supposed to be. The serialization system knows the identity and event history of the serialized product. A trading partner has its own record of what it shipped, received, or invoiced. Once the medicine enters patient care, the pharmacy or clinical system knows something entirely different again.

All five records can be correct. None of them necessarily tells the whole story.

Start with one medicine

Suppose we want to answer a seemingly simple question:

What happened to this medicine?

The answer depends on what we actually mean.

• Did somebody order it?
• Was the order accepted?
• Was it shipped?
• Which serialized unit was shipped?
• Did it physically arrive?
• Is it still in inventory?
• Was it dispensed?
• Was the expected price invoiced?
• Has it been returned, recalled, credited, or replaced?

These are not different versions of the same question. They are different questions, answered by different systems.

01ERP / commercialOrders, terms, invoices, credits

02Warehouse / inventoryLocation, quantity, status, availability

03Serialization / traceabilityIdentity and serialized event evidence

04Trading partner / distributorIts side of shipments, receipts, and invoices

05Pharmacy / clinicalDispensing, administration, and patient-care context

1. The commercial system

An ERP or purchasing system is often authoritative for the commercial transaction.

It may know:

• which product was ordered;
• which supplier or customer was involved;
• the purchase order;
• agreed quantities;
• commercial terms;
• invoices, payments, or credits.

That is enormously useful. But an ERP record saying that ten units were ordered does not prove that ten physical units arrived. And an invoice saying that ten units were billed does not tell us which ten serialized units moved through the supply chain.

The commercial record describes the transaction. It is not the physical world.

2. The warehouse and inventory system

A warehouse management or inventory system answers another set of questions.

Where is the product? How much is on hand? Is it available, quarantined, allocated, damaged, or already consumed? Which storage location contains it?

This is the operational view of inventory.

But inventory systems usually work at the level required to operate the facility. Depending on the process, that may be product, lot, location, quantity, or individual unit.

They do not automatically contain the complete commercial history, external trading-partner evidence, serialized event history, or patient context associated with that product.

3. The serialization and traceability system

Pharmaceutical serialization adds another identity layer. A product can be identified not only by product and lot, but by an individual serial number.

Standards such as EPCIS are designed to capture and exchange events about products as they move through business processes. Those events can describe what was involved, when something happened, where it occurred, and the business context around the event.

That makes serialization data exceptionally useful for traceability. But it is still evidence about a particular dimension of the process.

A serialization repository may tell us that a serialized unit was commissioned, packed, shipped, received, or otherwise handled. It does not automatically tell us whether the invoice was correct, whether the buyer received its contracted price, whether inventory is currently available for use, or whether a patient eventually received that medicine.

4. The trading partner's system

Now add another organization.

A manufacturer ships to a wholesaler. A wholesaler ships to a hospital. A hospital receives from several suppliers. Each organization maintains its own operational records.

Electronic transactions can connect those records. In a typical commercial flow, one organization might send a purchase order, receive an acknowledgement, receive a shipment notice, and later receive an invoice.

But exchanging information does not magically turn two companies into one database.

The sender can believe a shipment was completed while the receiver is still resolving a receipt. A message can be technically delivered while the business transaction represented by that message remains unresolved.

This is why interoperability is about more than transport.

5. The pharmacy and clinical system

Eventually the medicine crosses another boundary. It becomes part of patient care.

A pharmacy system may record a medication being dispensed. A clinical system may record administration to a patient. These are extraordinarily important facts, but they belong to a different operational context from the original purchase order, warehouse movement, or serialized shipment.

The same physical medicine has now accumulated another digital identity.

The object is the same. The decision context is not.

So which system is the source of truth?

This is where the phrase source of truth can become misleading. There may be no useful universal answer.

Source of truth for what?

The ERP may be authoritative for the purchase order. The warehouse system may be authoritative for current inventory location. The serialization repository may be authoritative for serialized event evidence. The supplier or distributor may be authoritative for its side of a shipment. The pharmacy system may be authoritative for dispensing. The clinical record may be authoritative for administration.

Trying to force every one of these facts into a single giant master database is not necessarily the goal.

The goal is to know which system owns which fact, how the records relate, and how to assemble the evidence needed for a particular decision.

The real difficulty is often in the joins

Several identifiers might help connect the medicine's records:

Product identifier

What product is this?

Lot or batch

Which production group did it come from?

Serial number

Which individual saleable unit is this?

Purchase order

Which commercial request caused the movement?

Shipment

Which delivery contained it?

Location

Which organization or facility handled it?

The problem is that every system does not necessarily carry every identifier. Identifiers may also appear at different levels.

A purchase order might reference product and quantity. A shipment notice might add packaging and shipment structure. An EPCIS event can carry serialized product identities and business context. A warehouse receipt may record what was physically received. A pharmacy system may later associate product use with a patient-facing workflow.

Connecting the story requires matching these records across boundaries. That is one reason apparently simple requests for “visibility” often become difficult integration problems.

The information exists. The work is assembling the evidence.

A recall makes the problem obvious

Imagine a manufacturer discovers a problem affecting a particular lot.

What is our actual exposure?

Traceability data might help establish which serialized units moved through the network. Trading-partner records might help establish what was shipped or accepted. Inventory systems can help determine what remains on hand. Pharmacy or clinical systems may help determine whether affected product has already moved further into patient care.

Commercial systems may be needed for the financial actions that follow: returns, credits, replacements, or reconciliation.

There is no contradiction here. Each system is answering a different part of the recall question. The complete answer emerges only when those pieces are assembled.

From system of record to system of answer

A system of record owns an authoritative piece of operational state.

A system of answer assembles evidence from multiple authoritative systems to answer a question.

That distinction becomes particularly important as AI enters enterprise operations. An AI agent does not need to replace the ERP, warehouse system, serialization repository, distributor platform, or pharmacy system. In many cases, it should not.

Instead, an agent might:

1. Understand the question being asked
2. Identify which systems contain the required evidence
3. Retrieve the appropriate records
4. Resolve identities across those records
5. Identify disagreements or missing evidence
6. Present a supported conclusion
7. Recommend or execute an action within defined permissions

The agent can create a better answer without becoming an accidental sixth source of truth.

Questions to try

• A hospital receives a serialized medicine but inventory does not update. Which systems should I investigate first?
• Which system would I trust to determine whether a specific medicine was dispensed?
• Give me an example where two systems appear to disagree but both records are technically correct.
• Walk a pharmaceutical recall across all five systems.
• What identifiers would I need to connect a purchase order to an individual serialized unit?
• Explain the difference between a system of record and a system of answer.
• Design an AI agent that investigates discrepancies without replacing any authoritative system.

The point is not to memorize five boxes. It is to learn how to reason across system boundaries.

Key takeaways

• One physical medicine can exist as several different digital records.
• Each system is authoritative for a particular operational context, not necessarily the entire process.
• Standards and electronic transactions help systems communicate, but interoperability still requires matching, context, governance, and reconciliation.
• Many visibility problems are really evidence-assembly problems.
• AI becomes especially useful when it can assemble evidence across systems while respecting the authority of the underlying records.