JNXRFID · Know-how Series · Healthcare Identification KH‑007
The Data Is Already on the Label
A nurse is still typing the drug, the concentration and the rate into the pump, even though all three are printed on the bag. The re-typing is not a keyboard problem. It is what happens when the label carries an identifier instead of the values.
14 min read · Applies to HF/NFC labelling at 13.56 MHz · Infusion, blood and pharmacy labelling · First edition, October 2026
Every infusion bag already carries the drug name, the concentration, the infusion duration and the flow rate. The nurse still types them into the pump. Why is the same information on the bag being entered a second time, and what would have to be true for the bag to configure the pump itself?
Because a barcode and an NFC tag carry different things. A barcode carries an identifier, and an identifier is not a set of instructions: the device has to look the values up somewhere else, and a human has to confirm them before they reach the pump. An NFC tag can carry the parameters themselves, so the device receives the values that were written when the bag was prepared. That removes a re-typing step. It does not remove the need to verify what was written, and it does not by itself decide whether the tag will be readable next to a bag full of liquid and a hand around it.
Where the second entry comes from
Start with the workflow rather than with the technology. A dose reaches a patient through a chain of handovers, and at every handover the data is represented by something a person reads. The bag carries a printed label. The label carries a machine-readable code. The code carries an identifier. The identifier points at a record elsewhere, and the parameters are copied from that record into a device by hand.
Each arrow in that chain is a place where the value can change, and the arrows are not equally dangerous. A printed character can be misread by a person. An identifier does not carry that risk: either it resolves or it does not. The dangerous arrow is the one that converts a resolved value back into typed characters, because a typed value has no checksum, no source reference and no record of who entered it.
An identifier and a parameter set travel different routes
This is the distinction that decides the design, and it is worth stating precisely because the two are often treated as the same thing at different stages of a project.
| Step | Barcode identifier | NFC parameter set |
|---|---|---|
| What is on the label | A code that resolves to a record | The values themselves |
| What the device needs | A network or database lookup | Nothing beyond the read |
| Where a person is involved | Confirming what the lookup returned | Confirming what was read |
| What a wrong value looks like | A transcription or a decimal error | A wrong value written at the bench |
| Where the error is caught | At the point of entry, if it is | At the write, if it is |
The last row is the important one. Moving the parameters from a lookup to a write moves the opportunity for error from the ward to the preparation bench, and the preparation bench is a controlled place with a record in front of the operator. That is the whole argument for encoding rather than scanning. It is not that an NFC read cannot fail: it can, and a tag that was written with the wrong value will be read correctly every time.
The bag and the hand decide the band
RFID is usually presented as a choice between frequencies, and in a healthcare context it is easy to assume that the higher-frequency, longer-range option is automatically the better one. For a tag on an infusion bag it is not, because the bag is full of liquid and the tag is read while someone is holding it.
Liquid and living tissue absorb radio energy, and they absorb more of it at higher frequencies. The same property that gives a UHF system its range takes that range away when liquid or a body sits between the reader and the tag. UHF sits in the 860-960 MHz band, and at that frequency a bag of fluid and a hand are a serious obstacle to the signal. At 13.56 MHz the field is deliberately short: it is a controlled, close-range interaction, and the field does not have to cross a bag of fluid or a hand to reach the label.
Two standards cover what a healthcare label needs, and they are worth keeping distinct because they answer different questions. ISO/IEC 14443 Type A is the standard behind NFC Forum Type 2 tags and is what a phone or a watch reads when a user taps it, which makes it the right choice when the reader is a device the clinician already carries. That said, this is a question about the operating system as much as the hardware: a watch may carry the NFC controller and the antenna and still not expose a general tag-reading session to an app, so the reader has to be confirmed against the specific device rather than assumed from the fact that it is wearable. ISO/IEC 15693 is the standard behind NFC Forum Type 5 tags and is read by dedicated readers at a somewhat greater distance, which suits a fixed workstation positioned beside the bag.
The practical consequence is that the tag family is chosen by who does the reading, not by the bag. A label read by a phone or a watch is a Type 2 application. A label read by a fixed encoder and a dedicated reader is a Type 5 application, and a printer that writes both is the more useful starting point. The HF/NFC encoder range is where that choice is made, and the two families of question it has to answer are whether the label is written on a bench or on a line, and whether it has to be readable by a device the user is already wearing or holding.
Write it once, where the facts are still together
Every value that belongs on an infusion label exists in one place at one moment: the preparation record. The drug, the concentration, the rate, the duration, the batch and the expiry are together when the bag is prepared, and they come apart from that point on. That is why the write belongs there.
The alternative is to encode tags in advance and print them later. It looks like it saves a step at the bench, and it does, but it separates the value from the person who owns it. Once encoding and printing are different operations performed at different times, a label can carry a value that does not belong to the bag it is on, and nothing in the workflow is comparing the two.
Writing and printing in the same operation also makes the write verifiable. A tag can be read back and compared against the preparation record before it is used, and then locked so that it stops accepting new content. Locking is not reversible, so the verification step is not a formality: it is the only moment at which a wrong value can still be corrected.
What to measure before you buy an encoder
The measurement that settles this is not a read range quoted in a datasheet. It is the number of tags that read first time on a real bag, held by a real hand, at the speed the line actually runs. Four numbers separate the causes, and each one points at a different decision.
| Measure | How | What it separates |
|---|---|---|
| First-read rate on a filled bag | Read the tag on a prepared bag in the position it will be applied, with the bag full and the label at its final position. | Whether the tag and the placement work at all. |
| First-read rate on an empty bag | Repeat with the same tag and label on the same bag type, unfilled. | Liquid from placement and construction. |
| Read time to a successful read | Time the read from approach to result, with a hand in position. | Whether the process can absorb the read time. |
| Write-to-read verification rate | Read every tag back after writing, before locking, and count the mismatches. | Encoding quality from encoding process. |
Run the first two together. If the empty-bag rate is good and the filled-bag rate is poor, the cause is the liquid and the position, and the answer is a different label construction or a different position on the bag. If both rates are poor, the cause is the tag and the antenna, and no amount of repositioning will fix it. If both rates are good but the verification rate is not, the problem is upstream of the reader entirely: it is in the data being written, and a better reader will not help.
What to specify when you procure
When the encoder is genuinely the answer, the specification has to describe the label and the workflow, not just the protocol. Five fields decide it.
| Field | State it as | Why |
|---|---|---|
| Protocols to support | The ISO/IEC 15693 and ISO/IEC 14443A tags the workflow actually uses, and whether the same label may be read by a phone or a watch. | It decides whether one printer covers both a fixed workstation and a handheld read. |
| Label construction | The tag, the adhesive, the laminate and the media thickness, as they will be on the bag. | The reader sees the finished label, not the bare tag. |
| Data format | ASCII, hexadecimal or NDEF, and whether the payload is a fixed record or a variable one. | It decides whether the write is a keystroke or a data feed. |
| Write control | Whether the tag can be locked after write, and whether the write can be verified before it is locked. | It is the only point at which a wrong value can still be caught. |
| Throughput | Bags per hour on the line, and the resolution the printed data has to be read at. | It separates a desktop station from a production unit. |
Ask for the encoder to be quoted against a filled bag and a hand, not against a bench. A supplier who quotes a read range alone is telling you about an empty room. A supplier who quotes a first-read rate on a prepared bag is telling you about your line.
Questions integrators ask most
The questions below are the ones integrators and end users ask most often about this topic. They are answered from published device specifications and field practice, not from marketing copy.
We already print a barcode on every infusion bag. Why is it not enough?
A barcode carries an identifier, not a dose. The device still has to resolve that identifier into a record somewhere else and a person still has to confirm the values before they reach the pump. An NFC tag can carry the parameter set itself, which removes the lookup and the re-typing. It does not remove the confirmation, and it does not remove the need to verify what was written.
Which standard should the label use, ISO/IEC 14443A or ISO/IEC 15693?
It depends on who reads the tag. ISO/IEC 14443 Type A is what a phone or a watch reads when a user taps it, so it suits a label that may be checked with a device the clinician already carries. Whether a specific watch can do that read is a separate question from whether it has NFC hardware: some watches carry the controller and the antenna without exposing a general tag-reading session to apps, so confirm the device rather than the platform. ISO/IEC 15693 is read by dedicated readers at a somewhat greater distance, so it suits a fixed workstation beside the bag. If the same label may be read both ways, an encoder that writes both is the useful starting point.
Why is HF/NFC the right band for a bag of fluid when UHF is used for warehouse inventory?
Because the two applications have different geometry. A warehouse read needs range across a wide zone, and liquid in the zone is not the deciding factor. A read at the bedside needs a short, deliberate interaction with one bag while a hand is on it, and liquid and tissue absorb more energy at higher frequencies. A short field is also what keeps a neighbouring bag from answering.
Can we encode tags in advance and just print the variable data later?
You can, and it is the usual source of a mismatch. Separating the two operations means the encoded value and the printed value can disagree, and nothing in the workflow compares them. Writing and printing in the same operation, at the moment of preparation, also allows the write to be read back and verified before the tag is locked.
Is a lock on the tag necessary?
It is the point at which the value becomes permanent, and it is not reversible. Locking after a read-back comparison against the preparation record means the value stops changing between the bench and the ward. Locking without that comparison simply makes a wrong value permanent.
Our existing reader works on the same labels. Do we need a new one?
If the labels carry a barcode today, the reader at the point of care is already resolving identifiers, and the encoder is where the change is made, not at the reader. If the existing reader is a fixed workstation, an encoder that writes both ISO/IEC 15693 and ISO/IEC 14443A covers a handheld read and a workstation read from the same label. If a read is failing on a filled bag, measure the first-read rate before and after adding fill level, because a failing read is a construction problem more often than a reader problem.
From the measurement to the specification
Send us the first-read rate on a filled bag
The measurement that settles this is the proportion of tags that read first time on a prepared bag, filled, held, at the speed your line runs. Send us that number and the label construction, and the encoder comes back as a specification rather than a shortlist.
- Tell us the first-read rate on a filled bag, and the same rate on an empty bag.
- Send us the label construction and the tag you use, and how the label is positioned on the bag.
- Tell us bags per hour, and we will size the encoder against that number rather than a peak figure.