How Do Data Standards Support Secure RFID Medical Device Traceability?

Medical device traceability becomes much easier to understand when we separate three different questions:

1. What medical device is this?
2. How does the RFID tag communicate with the reader?
3. Who is allowed to see the information associated with that device?

Those three questions are handled by different parts of the system.

UDI and identification standards help answer the first question.

RFID standards such as ISO/IEC 18000-63 — formerly ISO/IEC 18000-6 Type C and commonly called ISO 18000-6C — help answer the second.

Authentication, network security, access control, audit logs, and healthcare privacy controls answer the third.

That is the key point: standards make medical-device data interoperable, but standards alone do not make the complete RFID system secure.

A secure traceability architecture has to protect the complete journey from the physical device to the authorized backend record.

Start With One Medical Device

Consider a hospital infusion pump.

The hospital wants to identify it automatically and maintain a reliable traceability record.

A simplified RFID workflow might look like this:

Infusion Pump
     ↓
RFID Tag
     ↓
RFID Reader
     ↓
Hospital Network
     ↓
Asset / Traceability Software
     ↓
Authorized Backend Records

Each layer answers a different question.

The RFID tag may carry a device or asset identifier.

The reader captures that identifier.

The network transports the event.

The application determines what the identifier means.

The backend may associate the device with information such as:

• product model
• serial number
• maintenance status
• department
• cleaning status
• current operational state

If the hospital later associates that device with a patient or clinical procedure, the sensitive relationship usually exists in the protected information system rather than needing to be written onto the RFID tag.

This simple example explains why:

RFID security is an end-to-end architecture problem, not just a tag-encryption problem.

What Does UDI Actually Do?

UDI means Unique Device Identification.

Its purpose is to give regulated medical devices a standardized identity.

Under the U.S. FDA UDI system, an applicable device generally has a UDI containing a Device Identifier (DI) and, where applicable, Production Identifier (PI) information such as lot number, serial number, expiration date, or manufacturing date.

The FDA explains the UDI framework in its official UDI Basics.

But UDI is not an RFID protocol.

And UDI does not mean:

every medical device must contain an RFID tag.

The FDA requires applicable UDI information in human-readable form and in an Automatic Identification and Data Capture, or AIDC, form.

That AIDC carrier can be implemented using different technologies.

RFID is one possible technology.

Barcodes and two-dimensional symbols are also widely used.

So the first distinction is:

UDI tells us what identity must be represented. RFID is one possible way to capture that identity automatically.

Is GS1 the Same Thing as UDI?

No.

GS1 provides one widely used standards system for creating and representing identifiers used in healthcare.

For example, GS1 identifiers and Application Identifiers can be used in a UDI implementation.

But:

UDI is the regulatory concept. GS1 is one standards framework that can be used to implement it.

This matters because medical-device traceability projects should not start by assuming:

UDI = GS1 = RFID.

Instead, ask the questions in order:

What regulatory identification requirement applies?

Then:

Which issuing and identification system is being used?

Then:

Which data carrier should the application use?

Only after that should the project decide whether RFID is part of the architecture.

Where Does ISO 18000-6C Fit In?

This is where the naming becomes confusing.

Many RFID engineers, manufacturers, and buyers still use the term:

ISO 18000-6C

That terminology is still widely recognized.

The current standard name is:

ISO/IEC 18000-63

GS1 describes ISO/IEC 18000-63 as the new name of the former ISO/IEC 18000-6 Type C.

So for practical purposes:

ISO/IEC 18000-6C → ISO/IEC 18000-63

is an evolution in naming, not a completely different RFID technology.

ISO/IEC 18000-63 defines the air interface for compatible RFID systems operating in the 860–960 MHz UHF range.

In simple terms, it defines how the reader and tag communicate.

It covers things such as:

• reader-to-tag signalling
• tag responses
• commands
• multiple-tag inventory
• collision arbitration
• optional security commands

It does not define:

• a patient record
• a hospital database
• the complete UDI regulation
• who may access clinical information

That is why it is useful to think of ISO/IEC 18000-63 as:

the language spoken over the radio link.

For the underlying reader-tag process, see how RFID tags work.

So What Do the Main Standards Actually Do?

The easiest way to understand the architecture is to give every standard one job.

The important lesson is:

No single one of these standards solves the entire problem.

They form different layers of the system.

What Should Actually Be Stored on the RFID Tag?

A common mistake is to treat the RFID tag as a miniature medical database.

Usually, that is unnecessary.

For many traceability applications, the tag mainly needs a reliable identifier.

For example:

RFID Tag
EPC / Device Reference
        ↓
Hospital Backend
        ↓
Infusion Pump #175
Model: XXXXX
Serial: XXXXX
Maintenance status: Available
Department: ICU

The sensitive and changeable information stays in the backend.

This architecture has several advantages.

The tag does not need to be rewritten every time the device changes department.

The tag does not need to contain the complete maintenance history.

And if the RFID identifier is read outside the intended workflow, it exposes less information directly.

The FDA's GUDID architecture illustrates the distinction between device identity and personal identity: its device database contains device-identification information and does not contain information about who is using the device.

This leads to a useful security principle:

Store only the information on the RFID tag that the RFID workflow actually needs.

More tag memory does not mean more patient information should be placed there.

When Does an RFID Identifier Become Sensitive?

Consider two cases.

Case 1: The RFID Identifier Only Identifies the Device

An unauthorized reader sees:

EPC: 3034XXXXXXXX

By itself, that may reveal very little.

Case 2: A Backend System Resolves the Identifier

The authorized system may know:

EPC: 3034XXXXXXXX
        ↓
Infusion Pump #175
        ↓
Assigned to Room 306
        ↓
Associated with a patient workflow

The sensitive information is now created through the association between the RFID identifier and protected backend records.

This is why privacy analysis should ask:

What can someone read directly from the tag?

and also:

What could that identifier reveal if it were correlated with another system?

The second question is often more important.

Does Every UHF RFID Tag Use AES-128 Encryption?

No.

This is another area where RFID security is often oversimplified.

A conventional passive RFID tag may primarily provide identification and basic memory-access controls.

Some more security-focused RFID ICs support cryptographic authentication.

ISO/IEC 29167-10:2026 defines an AES-128 crypto suite for RFID air-interface communication.

It includes security services for compatible RFID systems such as tag and interrogator authentication.

But that does not mean:

every ISO 18000-6C / ISO 18000-63 tag contains AES-128.

ISO/IEC 18000-63 itself includes optional security commands that can work with ISO/IEC 29167 crypto suites.

The important word is:

optional

So before specifying a secure medical RFID system, check the actual IC and reader.

Ask:

• Does the tag IC support cryptographic authentication?
• Does the reader support the required commands?
• How are keys provisioned?
• Where are keys stored?
• Who is allowed to manage them?
• What happens if a key must be replaced or revoked?

A standard name alone cannot answer those questions.

When Is Tag Authentication Useful?

Not every hospital asset needs a cryptographically authenticated RFID tag.

The requirement should come from the threat model.

For example, stronger tag authentication may be useful when the system needs to verify that:

• a high-value tagged device is genuine
• a tagged item has not simply been cloned
• protected memory should only be accessed by authorized readers
• unauthorized modification of selected tag data must be prevented

For a basic internal inventory workflow, that level of tag security may not always be necessary.

That is why security should follow:

risk → requirement → hardware capability

rather than:

healthcare → therefore use the most expensive secure chip.

Where Does Patient Privacy Actually Need Protection?

Now return to the infusion-pump example.

The complete path may be:

RFID Tag
   ↓
Reader
   ↓
Hospital Network
   ↓
Middleware / Application
   ↓
Asset Database
   ↓
Clinical System

If the RFID tag contains only an equipment identifier, the patient information may not exist until much later in this chain.

That means patient privacy cannot be protected only at the tag.

The hospital also has to protect:

• reader credentials
• network traffic
• APIs
• middleware
• application accounts
• databases
• user permissions
• audit records

A secure design therefore uses defense in depth.

What Security Control Belongs at Each Layer?

NIST's Guidelines for Securing RFID Systems, SP 800-98 takes this broader approach.

It does not treat RFID security as only:

encrypt the tag.

It also discusses reader, network, middleware, policy, password, and cryptographic-system security.

How Does HIPAA Fit Into This?

HIPAA is not an RFID communication standard.

In the United States, HIPAA becomes relevant when a regulated entity's system creates, receives, maintains, or transmits electronic protected health information.

The HIPAA Security Rule addresses areas such as:

• access control
• audit controls
• integrity
• person or entity authentication
• transmission security

That means a hospital cannot say:

Our RFID tags use AES, therefore our patient information is HIPAA-secure.

Tag authentication addresses only part of the architecture.

HIPAA-related safeguards apply to the information system handling the protected data.

Under the currently effective Security Rule, encryption is an addressable implementation specification rather than a rule requiring one specific RFID encryption algorithm.

The organization has to evaluate risk and determine reasonable and appropriate safeguards.

So:

HIPAA does not require every medical RFID tag to use AES-128.

Do Patient Names Need to Be Stored on the RFID Tag?

Usually, no operational benefit justifies doing that when a non-sensitive identifier can perform the same function.

A better architecture is generally:

Tag:
Device / Asset Identifier

          ↓

Authorized Backend:
Identifier → Device Record → Authorized Clinical Association

This reduces the amount of sensitive information exposed at the edge of the system.

However, the reason is not:

RFID tags are legally forbidden from ever containing a name.

The stronger engineering principle is:

Do not expose sensitive information when the workflow does not require it.

Use the minimum data necessary at the RFID layer, then protect sensitive associations in the authorized backend.

What Does EPCIS Do?

Suppose the medical device moves through several stages:

Manufacturer
    ↓
Distributor
    ↓
Hospital Receiving
    ↓
Central Store
    ↓
Clinical Department
    ↓
Cleaning / Maintenance

The RFID tag does not need to store this entire history.

Instead, systems can record events in databases.

GS1 EPCIS provides a standardized framework for sharing visibility event information.

At a high level, an EPCIS event can help systems describe:

• What object was involved?
• When did the event happen?
• Where did it happen?
• Why or in what business context did it occur?

So you can think of the layers this way:

EPC identifies the object.

EPCIS records what happened to the object.

Again, this history normally lives in information systems rather than being written repeatedly into the RFID tag itself.

Are Interoperability and Security in Conflict?

No.

This is an important correction to the original article.

Open standards do not mean:

anyone may access everything.

And proprietary technology does not automatically mean:

secure.

Interoperability means two compatible systems can communicate or interpret the same standardized data.

Security determines whether that communication is:

• authenticated
• authorized
• protected
• auditable

The two can exist together.

For example:

ISO/IEC 18000-63 provides a standardized UHF RFID communication framework.

At the same time:

ISO/IEC 29167 can provide standardized cryptographic mechanisms for compatible systems.

So the goal is not:

interoperability or security.

The goal is:

interoperability where systems need to work together, and security wherever access must be controlled.

Does Security Make RFID Too Slow?

Security adds processing steps, but there is no universal rule that a secure RFID system becomes too slow for healthcare.

Actual performance depends on:

• tag IC
• reader
• authentication method
• number of tags
• RF conditions
• network latency
• application logic
• backend response time

The right question is not:

Does encryption slow RFID down?

It is:

Can the required security level and the required workflow throughput both be achieved in the real deployment?

That should be measured during testing.

A Better Way to Design the System

Instead of starting with standards, start with the workflow.

For an RFID medical-device traceability project, define:

Step 1: What Are We Identifying?

For example:

• infusion pump
• surgical instrument tray
• reusable medical device
• diagnostic equipment
• mobile clinical asset

Step 2: What Identifier Is Required?

Determine:

• regulatory UDI requirements
• internal asset identifier
• serial identifier
• GS1 or other identification framework

Step 3: What Should Be on the Tag?

Usually:

only the identifier and other data that genuinely need to be available at the RFID layer.

Step 4: How Will It Be Read?

Define:

• HF, NFC, UHF, or another technology
• fixed or handheld reader
• read distance
• read zone
• metal or liquid environment
• regional frequency requirements

If the project uses passive UHF RAIN RFID, this is where ISO/IEC 18000-63, formerly 18000-6C, becomes relevant.

Step 5: Does the Tag Require Authentication?

Ask whether the threat model requires:

• ordinary identification
• password protection
• protected memory
• cryptographic authentication
• anti-cloning capability

Step 6: Where Does Sensitive Data Live?

Define where the identifier becomes associated with:

• maintenance data
• hospital department
• procedure
• patient
• treatment record

Sensitive associations should be protected at the appropriate backend layer.

Step 7: How Does the Data Reach the Backend?

Review:

• reader credentials
• API authentication
• TLS or equivalent protected transport
• network segmentation
• middleware permissions

Step 8: Who May See the Final Record?

Define:

• user roles
• access control
• authentication
• logging
• audit
• retention

Now the security architecture becomes much easier to understand.

A Practical Medical RFID Security Checklist

Before approving an RFID traceability system, the project team should be able to answer these questions:

Where Does the RFID Hardware Manufacturer Fit In?

The RFID manufacturer is responsible for only part of this architecture.

A hardware supplier can help confirm:

• tag technology
• IC capability
• tag memory
• authentication support
• reader compatibility
• reader interfaces
• regional UHF support
• antenna and read-zone design
• physical durability
• cleaning or sterilization requirements

But a tag or reader manufacturer cannot make the entire hospital information environment secure by itself.

The hospital, software provider, system integrator, and IT/security team also have responsibilities.

This is why a good medical-device RFID specification should connect:

physical tag → RF performance → protocol → integration → security architecture

instead of evaluating the RFID product in isolation.

For broader tag qualification, see how to choose the right RFID tag.

For reader interfaces and hardware architecture, see the RFID reader buying guide.

For a wider healthcare application overview, see RFID in healthcare: medical asset tracking and patient safety.

If the system uses UHF readers in multiple countries, also check RFID frequency regulations by country.

FAQ

Q:​ Is ISO/IEC 18000-63 different from ISO 18000-6C?

A:​ They refer to the same UHF RFID Type C technology lineage. ISO/IEC 18000-63 is the current name of the former ISO/IEC 18000-6 Type C, commonly called ISO 18000-6C. The standard defines compatible reader-tag communication in the 860–960 MHz UHF range.

Q:​ Does UDI mean a medical device must use RFID?

A:​ No. UDI defines how applicable medical devices are uniquely identified. RFID is one possible AIDC technology that can carry or reference that identity. Other carriers such as barcodes and two-dimensional symbols are also widely used.

Q:​ What is the difference between UDI, GS1, and ISO 18000-63?

A:​ UDI is a regulatory device-identification framework. GS1 provides one widely used standards system for identifiers and data structures. ISO/IEC 18000-63, formerly ISO 18000-6C, defines how compatible passive UHF RFID tags and readers communicate over the radio interface.

Q:​ Does every ISO 18000-6C RFID tag use AES-128 encryption?

A:​ No. ISO/IEC 18000-63 supports optional security commands, but cryptographic capability depends on the actual tag IC and reader. ISO/IEC 29167-10 defines an AES-128 crypto suite for compatible RFID systems; it is not a default feature of every UHF tag.

Q:​ Should patient names be stored directly on medical RFID tags?

A:​ Usually, sensitive patient-identifying information can remain in an authorized backend while the tag carries only the identifier required for the physical workflow. This reduces unnecessary exposure if the tag is read outside the intended system.

Q:​ Does AES encryption make a hospital RFID system secure?

A:​ No. AES-based RFID authentication can protect part of the tag-reader interaction, but the reader, network, middleware, APIs, databases, accounts, access controls, audit logs, and key-management processes must also be secured.

Q:​ What does EPCIS do in a medical traceability system?

A:​ EPCIS provides a standardized way to represent and exchange traceability events about an identified object. Instead of storing the complete history on the RFID tag, backend systems can record what object was observed, when, where, and in what business context.

Q:​ Are open RFID standards less secure than proprietary systems?

A:​ Not inherently. Interoperability and security are different design requirements. A standards-based RFID system can still use authentication, encryption, access control, protected networks, and audit mechanisms.

Q:​ Does HIPAA require medical RFID tags to use AES-128?

A:​ No. HIPAA does not prescribe a specific RFID tag IC or air-interface encryption algorithm. Where ePHI is handled, regulated organizations must apply appropriate administrative, physical, and technical safeguards to the complete information system.

Conclusion

Medical RFID traceability becomes much easier to understand when every layer has one clear responsibility.

UDI answers: What device is this?

GS1 can answer: How is that identity represented in a standardized way?

ISO/IEC 18000-63, formerly ISO 18000-6C, answers: How does a passive UHF reader communicate with the tag?

EPCIS answers: What happened to the identified object, when, and where?

ISO/IEC 29167 can answer: How can compatible RFID systems add cryptographic authentication at the air interface?

And the hospital security architecture answers the most sensitive question:

Who is authorized to connect that device identity to protected operational or patient information?

That is the central security principle.

Do not expect one RFID standard to secure the entire medical traceability system. Standardize the identity and communication, minimize sensitive data on the tag, and protect the full path from the RFID reader to the authorized backend.

For the wider healthcare use case, continue with RFID in healthcare: medical asset tracking and patient safety.

For the RFID communication basics, see how RFID tags work.

For reader architecture and integration planning, see the RFID reader buying guide.

For help evaluating tags, readers, authentication requirements, encoding, or integration architecture for a medical-device traceability project, Contact Fongwah.