The service protocol became a living record.
Update #1 was about AI, update #2 about the knowledge the AI works from. This one is about the least glamorous and most regulated part of a medtech distributor's life: service. On 9 September the Imedex service lead handed us two short lists — one about the installed technology, one about the periodic safety inspection. Eight days later, 22 of the 26 items were live in the production system, checked one by one in the running instance and in the generated PDFs. Nothing left on the list is waiting for engineering; what remains is two decisions.
The problem, in one document
Every medical device installed in a hospital must pass a periodic safety inspection — in the Czech Republic every 12 months, by law — and the hospital keeps the signed protocol. One visit, several devices, one protocol per device. That protocol is the whole point of the visit, and until this round the two dates that matter most on it — when the inspection was performed and when the next one is due — were not real data anywhere. The system held a planned period; the performed date was whatever someone typed; the next date was arithmetic nobody could correct. Location, warranty status, the customer's order number and the technician's name were re-typed on every protocol. The printout also carried internal numbers that mean nothing to a hospital.
What changed
The dates are first-class. Performed date and next-due date now live on every service activity — editable, pre-filled by the client's own rule (twelve months on, rounded to month end), shown in the header and printed. Warranty is derived, never stored, from the device's warranty dates — so it cannot drift from the truth. Location comes from the installed base, not from the technician's memory. The customer's order number has a home: entered once on the visit, printed on every protocol from that visit, and searchable — "find the job for this purchase order" is now a filter, not a phone call. The technician is a role you pick, not a name you type. And the protocol dropped the three internal fields the service lead crossed out on a printed copy.
The installed base itself now speaks the client's language: Installed items instead of generic labels, device state and install date instead of quantities, three fields nobody at Imedex uses hidden (not deleted — the values are still there), and location set at the moment a device is created. Devices on loan to a hospital and devices on rental are now two different states, because they are two different realities.
Why this is bigger than one client
Nothing in the code knows the word "BTK". The dates, the order number, the loan state and the location became platform capabilities, switched on by the configuration of an activity type. A dental or laboratory service company with a different inspection cycle and a different legislation starts from the same place — and one of them already inherited the clearer wording without filing a request of its own.
What's next
Imedex runs two legal entities — a Czech one in CZK and a Slovak one in EUR — on one instance with one shared product catalogue. The next wave promotes this service configuration to the Slovak entity and adds product texts in three languages, so the same catalogue prints correctly in Prague and Bratislava. The two open decisions on the list are ours to make with the service lead, not features to build. Why a device should be able to cross a border inside its own group without a second system — and what the EU makes of that — is in "Devices without borders".
Talk to us about your service protocol →
Owner: Jan Safka · Healtek field notes, September 2026. Counts (26 requirements, 22 live) are from the verification walk on the client's production instance, 17 September 2026 — not from a test system.