NexLotus Request a briefing

Asset Tracking

Feature-complete, pre-pilot

A record of where the equipment has been. Not a claim about where it is.

For Ontario hospitals, long-term care homes, municipalities, school boards and universities. Every asset carries a printed label with a QR and six characters. Anyone may scan it, signed-in staff move it, staff file fault reports against it, a technician records the inspections and service it owes, and nothing that reaches the event log can ever be edited afterwards.

Event log

Append-only. No update and no delete at any layer, including for an administrator.

Roles

3 signed-in roles, plus the nightly job and anonymous scanning.

Status

Built and audited, never deployed. See where it actually stands.

This page changed again in October 2026.

The module is built: the corridor console, the administrator surface on the host machine, three signed-in roles, sealed service notes, a recall workbench fed by Health Canada's daily feed, a printable device history, and twenty-one screens that cleared WCAG 2.0 and 2.1 Level A and AA with zero violations in September. On 25 October the equipment room chat was deleted and replaced with fault reports filed about one machine; that section is rewritten below, and the new screens have not yet been through the accessibility run. The schedules were always generic, so the same record serves a fire extinguisher or a boiler as well as an infusion pump. The last section says what the module still has not had.

No sign-in wall between a person and the thing in front of them.

Equipment gets a label carrying a QR and a six-character public code, random and fixed for the life of that machine. Anyone who scans it, a porter, a nurse, a visitor, a contractor, sees what the thing is and whether it is in service. No account, no sign-in wall.

They do not see where it is or who has it. That rule decides which columns are encrypted, and it is one sentence long: what this system prints on a sticker stuck to the outside of a machine, in a public corridor, is not a secret. The name, the hospital tag and the home location stay readable. The serial number, make, model, firmware version, service vendor, contract reference, description and photograph do not.

The hospital's own existing asset number stays on the record and is never replaced. A system that renumbers a hospital's equipment estate to suit itself has made the hospital's problem worse in exchange for its own convenience.

A sealed column that has to be searchable carries a blind index. The serial number is stored as an HMAC of its normalised value under a key derived from the primary key, which makes serial search exact rather than partial. The interface says so on the search field, because a search box that silently will not do prefix matching is a search box people stop trusting.

An equipment label A printed label carrying a QR code, a six-character public code, the equipment name, and the hospital's own existing asset tag. Public code 7F3K9M Infusion pump Volumetric Hospital tag BME-0148829 Scan · no account needed See what it is and whether it is in service. Nothing else.
Illustrative. The code shape is real; this is not data from any deployment.

Three custody states, and a fourth that was deleted.

An earlier version of this module had five, including one called unconfirmed and one called lost. Both went, because both were the system dressing up an absence of information as a finding. What remains is the smallest set that can be true.

AVAILABLE

Nobody is holding it. The only state it can move to is checked out.

CHECKED_OUT

One named person took it and named a place. Somebody else may take it from them, which is written as a check-in and a check-out inside one transaction, so both halves land or neither does. You cannot, however, take it from yourself: that was a real defect, and the fix is a test.

OVERDUE

Held past the hour limit its category carries, and nothing more than that. It is not lost, not missing, and not overdue in the maintenance sense. It still names a holder and it still says how long it has been.

UNCONFIRMED

Deleted. A state that exists because time passed is a state the system invented, and it made an administrator's screen look like an investigation had happened when nothing had happened at all.

LOST

Deleted with it. Whether a machine is gone is a conclusion somebody reaches by walking a floor, and this product does not have a floor.

What it prints instead. Last left at Tower 4, Clean Utility, three days ago. It never prints currently in Tower 4. The system did not watch the machine after somebody put it down, and saying otherwise is the lie every tracking system tells first. The phrases real-time, live location and current location are refused by a test that runs on every commit.


Nearest first, from where you are standing.

Where is the closest free infusion pump to the cath lab is the question a nurse asks at three in the morning, and answering it by reading the whole fleet list by eye is how somebody ends up at an empty hook two floors away. It is a checkbox on the list already in hand rather than a second screen with its own picker, because it is the same search with one more constraint on it.

The order comes from the wayfinding graph. One pass out from where the person is standing gives the walking distance to every node in the building, so ranking the whole fleet costs one traversal rather than one per machine. Same graph, same closures, same physical scale as the map a visitor is reading downstairs, which is the reason these are two pillars of one product rather than two products. A corridor an operational notice has taken out of routing is taken out of this answer too.

It ranks where a machine was last left

Not where it is. Every row carries the date of the scan it is standing on, and the answer is only ever as good as the last person who named a place. The minutes it prints are the modelled walk, at the same deliberately slow pace the reader's map quotes.

A short list is not a small fleet

Machines with no place recorded are counted separately rather than dropped, and so are the ones the router could not walk to. Four more and nobody knows where is information; leaving them out silently would make the fleet look smaller than it is.

The map is an enhancement, never a dependency

A hospital that wants the equipment record and no map still gets the whole list. The distances are simply absent, one line on the screen says so, and the ordinary order stands.

The technician's half

01 / What is due

Counts, never a percentage.

Six need service. Two have never been serviced. A percentage is a grade, and a grade points every incentive in the building at moving the number rather than servicing the machine. A count has no denominator anybody can argue about, and the word compliant never appears, because this system records evidence and does not adjudicate.

Due · Overdue · Never serviced. Schedule intervals are in weeks, always, and there is no second unit anywhere in the module

02 / Record it

One named schedule, completed by one named person.

Servicing is the only event that advances a schedule, and it carries which task it was. A porter tapping something is not evidence of maintenance, which is why clinical staff cannot write this and a technician can. Equipment may carry several schedules, and each is its own obligation with its own clock.

SERVICE_DONE, carrying the task kind · written by TECH only · advances exactly one schedule

03 / Say what you found

A null answer is a real answer, and it is not "fine".

A condition note is the technician's own words and it is required. A replacement grade is one of three, with a reason, and it is also required. No grade at all means nobody has looked, which is a different fact from somebody having looked and said it is fine. A report that cannot tell those apart tells an administrator an unexamined fleet is healthy.

MONITOR · PLAN · REPLACE_NOW. A null grade is not MONITOR

04 / Fix a mistake

Strike it out. Never delete, never edit, never undo.

A wrong entry is voided by a correction naming the row it supersedes, and the correct fact is recorded fresh. The struck row stays visible forever with a rule through it and the reason underneath, because the pair is the correction. An administrator cannot edit this log either. Nobody can.

CORRECTION · a void carrying a reason and no payload · custody is replayed in commit order so the log and the record agree

One label. Two answers. Two routes with two guards.

A nurse who scans six characters and a technician who scans the same six characters need almost nothing in common. Rather than one handler branching on a flag, there are two routes behind two guards, because an authorisation mistake should be a refusal rather than a rendering bug.

The nurse gets a door

What the thing is, whether it is in service, and one button sized like a door: Take it. Nothing blocks her. Equipment somebody else is holding can be taken, and equipment a technician has taken out of service can be taken too, with the reason shown loudly first. A block is a block somebody works around by not using the app, and then nothing is recorded at all.

The technician gets the record

What the machine owes, what the floor has said about it, whether opening the case ends its warranty, the firmware version a recall is written against, and the service notes. Custody is demoted to a plain button underneath all of it, because taking a pump is not what a technician came to this screen to do.

The equipment console signed in as clinical staff. A large scan-a-label target fills most of the screen, with smaller options to type a code or find equipment.
The floor's console. One decision per screen. The scan target is the screen, because a nurse holding a pump in one hand has one thumb.

The floor can say something, and only a technician can decide what it means. A nurse who finds a broken pump files a fault report in a few taps, with her name on it. It changes nothing about the machine: taking equipment out of service is a technician's judgement, and a report is not a verdict. The card warns while a report is unanswered and never blocks, because a nurse at three in the morning with one pump in the building makes her own decision with the facts in front of her.

Fault reports

The group chat is gone. A fault report is filed about one machine, in about ten seconds.

Until 25 October 2026 this module had a hospital-wide equipment room with side rooms. Free text in a shared room is where a patient's name or health card number eventually gets typed, so the chat was deleted outright and replaced with notes: one machine, a few taps, and words only if the writer wants them. In the interface they are called notes. On this site we call them fault reports, because that is what they are for.

Filing one. Scan the label or search for the machine. Say where it is by picking a place on the map; the place it was last left is offered first, and never pre-selected. Say what is wrong with one tap: not working, showing an error, unusual sound, damaged or missing part, won't power on or charge, or other. Say how soon it is needed: needed now with no working spare here, needed today, or can wait. An error code and a short description are optional.

Answering one. Anyone with an equipment role can reply with one tap (I'm working on it, seen it, taken to biomed or facilities, working again, same problem here), with words, or both. A technician, an administrator or the person who filed it can mark it resolved.

What it is not. Nobody is assigned a report and it has no due date. "I'm working on it" is a reply, not a state. A report never changes whether the machine is in service: that is a technician's judgement, on its own sheet. This is not a work order system, and the module is deliberately built so that it cannot quietly become one.

Fault report, open Infusion pump 7F3K9M

Clinical staff, 03:14

Showing an error. Needed today. Last seen at 4B clean utility. Error code E-21.

Technician, 08:40

I'm working on it

Technician, 09:02

Working again

Resolved by the technician's reply

Illustrative, not data from any deployment.

The machine's own record gains one line: a report was made, by whom and when. No copy of any words is written to the permanent record.

Words are screened before they are stored, and refused text is never kept.

Every description and written reply is checked, in the browser and again on the server, for the shape of patient details: Ontario health card numbers, the site's own record-number formats, dates that look like birth dates, phone numbers, and phrases like "patient" or a room and bed together. A match is refused with a plain explanation. The refused text does not reach the log, the audit trail or any metric. The machine's own serial and tag numbers are exempt, so the screen does not trip over them.

Names cannot be caught reliably, and we do not claim otherwise.

The screen is a safety net. A warning sits above every text box asking for the equipment only. Free text can be switched off for a whole site, and the pick lists still work without it.

Text can be removed, and the record that it existed stays.

An administrator can remove the words of any report or reply, with a reason from a short list; an author can withdraw their own. The words are deleted and a signed audit entry records the removal, with no text in it. A fingerprint of the original stays, and it cannot be tested against guessed names once the words are gone.

Twelve months, then the words go and the reports stay.

A nightly sweep removes text older than the site's text-keeping period, 365 days by default, by the same mechanism. Setting it to zero keeps text indefinitely. This is the one place the module deletes rather than strikes through, and only for these words.

Staff only, never the public door.

Reports are served on the staff door and the host console. The public reader app has no route to them, and a test proves that it answers 404. Report text is never sent to translation, AI or analytics.

Health Canada publishes a recall every day. Somebody has to ask whether it is one of yours.

A daily sweep reads the public recall feed and matches it against the equipment register on make, model and firmware version, which is precisely what the profile fields were collected for. What it produces is a list of candidates and a decision to make about each one. It is not an alert, and it does not change the state of any machine.

It says "may be affected", and a test says so too

The screen never says a unit is recalled, or unsafe, or out of service. It says the model matched and names the class Health Canada assigned. The words the screen must not print are asserted absent by a test, in the same way the rest of this product's vocabulary is held.

Three answers, and one of them is "not us"

We hold this unit, Not us with a reason, or print the equipment record to take into the conversation. A dismissal is recorded with its reason rather than vanishing, because "we checked and it was a different production run" is a fact somebody will need again next year.

The plate says what it cannot show

Affected units are marked on a schematic floor plate, and it is schematic on purpose: a diagram that looks surveyed invites somebody to navigate by it. Units with no mapped home are listed beside the plates under a heading saying they are not on the map, with whatever free-text home they do have. Nine of twelve units drawn with no note is a worse answer than drawing nothing, because it looks complete.

The marker is not red

It uses the colour this product gives to "due", not to "out of service". Nothing here is an emergency; every unit on the plate is a candidate awaiting a human decision, and colouring it like a hazard would be the map telling a lie the text is careful not to.

One recall candidate in the equipment console. An infusion pump is listed with its code, hospital tag and model, a line reading that the model matched every unit of this model with Health Canada class Type II, a link to read the recall on Health Canada, and three buttons: we hold this unit, not us, and print the equipment record.
One candidate, and what is known about it. What matched, the class Health Canada gave it, a link out to the notice itself, and a decision waiting on a person. Development build, seeded data.

The sweep fetches from an allowlist, and that was a fix. The first version followed whatever URL the feed handed it, including across a redirect, which makes a public feed into a way to point this system at any address on the network it sits in. A redirect leaves the allowlist by definition, so it is refused rather than followed.

A surveyor points at a pump and asks where it came from.

Today that answer gets assembled from a spreadsheet and somebody's memory while the surveyor waits. Scanning the sticker produces the same answer as a PDF: where the machine came from, everyone who has held it, every service recorded against it, every correction, and the provenance of every line on the page.

Counts, and the reason printed beside them

The fleet section reads "14 overdue, 6 never serviced, 212 in schedule" and no ratio appears anywhere, because the shape of the data has no field to put one in. The pack says why on its own face: the first question a reader asks of five numbers is "so what is the compliance rate", and a single percentage flattens "never serviced once" into the same bucket as "two days late".

Corrections are in it

A device history that hid its corrections would be the opposite of a device history. Struck entries appear alongside services and custody, the people are resolved to names rather than printing an identifier at somebody holding a clipboard, and a history long enough to be cut says it was cut instead of implying it is complete.

Service notes are not in it, and it says so

The pack prints a line stating that service notes exist for this machine and are not included, rather than omitting them silently. A surveyor who is not told will assume the history in front of them is complete, and a silent omission in a document produced for an auditor is the worst kind there is.

Producing one is a disclosure

The pack carries custody history, which names staff, and it leaves the building on paper or as a file. So generating one is audited like any other disclosure. The record of who produced it is the thing that makes it defensible afterwards.

Every page says what it is

Facility, equipment code, timestamp, who generated it and the build version are stamped on each page, so a sheet separated from its pack still identifies itself. Paper gets separated. That is what paper does.

A draft is still a 404

Equipment whose label was never printed answers exactly as the anonymous scan card does: nothing. Holding a technician role is not a reason to confirm that a record exists behind a code that was never printed on anything.

Three roles, one nightly job, and a fourth role that was removed.

This page used to describe an independent auditor with an audit period, a sign-off and findings. All of it was built, shipped, and then deleted, because in a department with four technicians the auditor was one of the four, and a role that only ever exists on paper puts a signature line under a document nobody independently checked.

Roles in the Asset Tracking module
Role Who they are What they may write Where they work
ADMIN Department or biomedical manager. Adds equipment, prints labels, sets schedules and equipment access. Answers fault reports as the equipment office, and can remove the words of any report. Reads every service note and still cannot save one. Host console only
TECH Technician. One word, not three. Records that a named schedule was completed, writes the condition note and the replacement grade, takes equipment out of service, and replies to fault reports or resolves them. The corridor
STAFF Nurse, doctor, porter, environmental services. Takes equipment and puts it back, naming a place each time. Files fault reports, replies to them, and resolves the ones they filed. Nothing that constitutes evidence of maintenance. The corridor
system The nightly job. Never a staff account. Ages custody past its hold window, and nothing else. Writes as a literal actor with no relation behind it. No screen
anonymous Anyone with a phone and line of sight to a label. Nothing. Reads what the machine is and whether it is in service. The scan card

Why a technician role exists at all

The two-role design a hospital usually asks for, an administrator and everybody else, has nobody whose signature on a maintenance record means anything. That record is the spine of the module. If clinical staff can write it, the resulting count is decoration.

Why the administrator moved off the network

Adding equipment, printing labels, the equipment board, the fleet report and equipment access all live on the host console, which is bound to loopback. They are unreachable through the tunnel by design, not by configuration. The corridor keeps four verbs and nothing else.

This page used to claim end-to-end encryption here. It never worked once.

Until 7 September 2026 each machine's service notes were encrypted in the technician's browser under a facility passphrase the server never received, and this section described that scheme at length, limits and all. The panel that set the passphrase was gated on an equipment authority that first-run setup never granted to anybody. Every attempt answered 403 and showed "Did not save. Try again." Zero keys and zero notes were ever written, on any installation, for the entire life of the feature.

The honest thing to say about a security property that was never exercised is not that it was strong. It is that nobody would have found out. The ceremony was removed rather than repaired, and what replaced it is written below along with what that trade actually cost.

What it is now.

One document per machine, AES-256-GCM under the same application keyring that seals every other note in the product, with the machine's own identifier bound into the tag. A copy of the database yields ciphertext and nothing else, and the key is held in the environment rather than beside the data.

What was given up, and it is real.

The server can now decrypt what it stores. Under the old design it could not. That is a genuine property to lose, and it is listed first rather than last because a reviewer will find it either way.

Why losing it was worth it.

It protected notes about machines, on a branch that holds no patient data at all. It was bought with a shared secret every technician had to be told, which is a secret that ends up written on the wall beside the thing it unlocks, with no way to revoke one person without rotating for everybody. And a facility that forgot the string lost every note in the building, permanently, with no escrow and no recovery.

What was kept unchanged.

Notes cannot be moved between records: pasting one machine's document onto another produces a decryption failure rather than a plausible wrong answer. Technicians write, every floor role reads, and an administrator who may read every note may save none. A save carries the revision it read, so two technicians cannot silently overwrite each other. The audit line still records that a note was written and still carries none of its words.

Feature-complete, and it has never run anywhere.

Both halves of that sentence are load-bearing. The first is a genuine change from what this page said in August. The second has not changed at all, and no amount of building is going to change it.

What is built

  • The four verbs, and the corridor console rebuilt around one decision per screen.
  • The administrator surface, on the host machine, unreachable from the network.
  • Three signed-in roles, the nightly job, and anonymous scanning.
  • The append-only event log, with corrections that strike out rather than delete.
  • Encrypted profile fields, a blind index on the serial, and sealed service notes.
  • Twenty-one screens across all four apps at zero WCAG 2.0 and 2.1 A and AA violations.
  • An ASVS Level 2 self-assessment, and the two findings writing it exposed.
  • Fault reports filed about one machine, with text screened for patient details before it is stored.
  • Nearest first, ranked on the same graph and the same closures the visitor's map uses.
  • A daily sweep of Health Canada's recall feed, matched against the register, with a workbench for the decisions.
  • A printable device history, produced from a scan and audited as the disclosure it is.

What it has not had

  • A corridor. Nothing here has met a real floor, a real trolley or a real night shift.
  • A printer. Labels have never been produced by hospital hardware and stuck to a real machine.
  • A technician who did not help design it, using the due list on their own shift.
  • A year. Schedules have never survived twelve months of real drift, staff turnover and a recall.
  • A budget meeting. Nobody has yet read the fleet report while deciding what to buy.
  • An independent audit. The accessibility and security results above are the project's own.
  • A site outside healthcare. The schedules are generic, but no municipality, school board or university has used them.
  • An accessibility run over the fault report screens added on 25 October.

Three things this page used to say that were wrong. It described an independent auditor role, which was built and then deleted for the reason given above. It said an unauthenticated sighting could raise an item in a queue for confirmation, which should not have survived the rebuild: anonymous scanning writes nothing at all. And it described the service notes as end-to-end encrypted, which was true of a design that never once ran. All three are corrected in place rather than quietly removed, on the same principle the event log runs on.

The next thing this module needs is a corridor.

A pilot in one department, with real machines, real labels and a technician who will tell us which screen is wrong. A briefing walks through the data model, the roles, the encryption boundary and this whole list of what it has not had.