Definition
In the "Medical Device UDI and Network Registration" scenario, sensors and business terminals often connect through a cellular IoT platform; coverage quality, latency, security, and the full lifecycle of SIM management need to be considered simultaneously.
Technical Features
It is recommended to differentiate telemetry, alarms, configuration, and OTA traffic; configure caching and retransmission in weak network environments; include TLS, certificates, and keys in the change and rollback strategy.
Use Cases
Applicable to distributed sites and remote operations. SimtoLink can provide combined capabilities like connection management, data pool, and directed/private networks, supporting large-scale replication.
Key points for cooperation with IoT SIM cards
- Ledger: ICCID / IMEI bound to device number, installation location, and person in charge.
- Network: APN, whitelist, SIM-device binding, and regional/roaming policies.
- Operations & Maintenance: online rate, abnormal traffic, silent SIMs, and alert closure in ITSM.
- Compliance: log desensitization, retention period, and cross-border/subcontracting agreements.
Replacing the SIM Does Not Change the Product Identifier
What the unique identifier and the SIM ledger mean
A unique device identifier meets an IoT SIM because a connected device has a product identifier and a production identifier, and also a SIM that will be replaced. The product identifier points at the registered model. The production identifier points at a specific serial or batch. The SIM number points at the current communication relationship. Together they are a ledger in which each can find the others: from a SIM number, find the device; from a device serial, find the SIM in use now. Identifier rules sit next to drug traceability. See drug and device traceability code. A device serial must not be replaced by a SIM number. Replacing a SIM is communication maintenance. It is not the manufacture of a new device.
If a connected-device filing requires the communication method to be reported, the report should be "which already identified device this SIM number corresponds to now," not a new device with no history every time the SIM changes. Adverse events and recalls trace by product identifier and production identifier. A broken SIM only means the device cannot be reached for the moment. It does not mean the device's identity changed.
Conditions for going live under a network filing
At shipment or at goods-in, the identifier is already written into the device and the ledger. Activating the SIM only binds it. It does not start a new number that cannot be parsed. Remote upgrade, location, or run state may come back over the SIM, but the message has to carry the production identifier. When the module or the SIM is replaced, unbind the old SIM, bind the new one, and keep history on the original serial. If the device is sold into different regions, roaming and suspension policy may change. The identifier's coding rule must not be rewritten by region.
A SIM that has not finished binding should not be reported as a filed device. When repair replaces the main unit, distinguish "the communication board was replaced" from "the whole device was replaced." The first keeps the production identifier. Only the second uses a new one. Keep patient information out of the SIM-management platform's logs.
An identifier bound to the wrong physical serial
A common failure shifts rows during a bulk import, so device A's serial is written onto device B's SIM. A recall notice goes to the wrong device that is online, and the one that actually needs to be reached shows as silent. Another reuses a SIM on the next refurbished unit, and run data from the old serial keeps writing into the new machine. If the platform uses the SIM number as the primary key, history breaks after a SIM swap, and the device looks as if it was scrapped and then put on the market again.
An identifier stuck only on the package, and not carried in the connected message, cannot be checked once the package is opened on site. Acceptance should swap one SIM: the serial number does not change, both the old and the new SIM number can find the same device, and a bad import row is rejected rather than covering the original binding.
The identifier carrier and the communication module are often not on the same board. The barcode is on the shell. The SIM is in a replaceable communication module. Repair swaps only the module, and the serial on the shell remains. If the binding is written in the module's factory file rather than in the whole-device record, swapping the module equals swapping the device. The record's primary key should be the whole device's production identifier. The module and the SIM are replaceable parts, and the replacement is recorded under that key. When software version, registration version, and SIM number all change at once, the message should give them separately. Do not pack them into one free-text field and let the platform split it. A bad split records the registration version as a SIM number. A retired old SIM should be marked unbound, not deleted as a row, or an audit cannot find which SIM was carrying traffic in that period. Traffic bound to no production identifier should not enter the device run record. It may stay on the SIM side as unclaimed, so an unnamed record does not pollute the recall list.
The same model sharing a product identifier, with different production identifiers, is normal. If the platform merges run data by product identifier, alarms from dozens of devices stack into one. Count online devices by production identifier. A SIM data pool may be summarized by organization, but a traffic total must not stand in for a device count. Do not mix pilot devices and marketed devices on the same reporting address. Once a pilot SIM's data is written into the marketed record, the recall scope is widened. Separate the address and the identifier rule at activation. That is more reliable than cleaning up afterwards.