Software update or service replacement: what to check before a client

The service engineer closes the case. The error message has disappeared. It is tempting to decide that the work is finished.

For the clinic, a short return-to-use check is only beginning.

A software update, replacement handpiece or service intervention can leave the device looking familiar while changing a version, configuration, display, accessory or user check. The first client should not be the test that reveals the difference.

Record what actually changed

“Service complete” is not enough. The record needs to match the exact system: date, device identifier, reported fault, work performed, replaced component or accessory, new version when relevant, checks completed by service and any restriction.

Ask where service confirmation ends. Was only the replaced component checked? Did the full system complete a manufacturer process? Is a further room check required? The answer should be documented, not passed on as the engineer’s confidence.

Evidence differs by system. Use the service report, current instructions and approved local process. Give each open question an owner; if it affects authorised configuration or safe use, the device remains unavailable.

If the change cannot be established, the device stays out of the diary. The team does not fill the gap with “it was probably only software.”

Users check only what belongs to them

The responsible person compares the system with approved documentation and the clinic’s configuration record. They confirm the platform and handpiece, displayed version where applicable, authorised accessories, cooling and the indicators assigned to the user by the instructions.

Do not open the housing, clear the error history or enter a service menu without authorisation. Do not restore saved values from an old screen photograph. An update may retain data, reset them or change how they are shown; the exact system documentation provides the answer.

A short pre-release check asks:

• do the device, handpiece and accessory match the service record;
• is there a new message, alarm or unusual behaviour;
• are the required user checks complete and recorded;
• do protective equipment and room controls match the current configuration;
• did the change affect a step the operator must demonstrate again?

Do not record only “passed”. Name the user check from the current instructions, the authorised configuration and the observed result. A service function must not be improvised with whatever object happens to be available.

If any point is unclear, the check stops and the question returns to service or an authorised person. A client is not a test mode.

The practitioner observes the external state and completes only trained user actions. Service handles internal diagnosis and repair. The release owner joins that evidence with staff readiness. A failed check is recorded, not repeated until it happens to pass.

A change may require competence to be shown again

Not every update requires a full training course. The clinic does need to establish whether it changed something the operator uses or interprets: interface, mode selection, handpiece confirmation, cooling, alarm, record or stop sequence.

When it did, affected staff receive an explanation from an approved source and demonstrate the changed step in a controlled setting before treatment. A signature saying that an email was read does not show that someone can recognise the new screen behaviour.

Keep the demonstration narrow: show the changed step, its stop boundary and the current instruction. Do not involve a client. Record the assessor and date.

The review should match the actual change. That avoids both poor extremes: ignoring a new state and running a large formal retraining exercise unrelated to the service work.

One person makes the release decision

Service confirms its technical work. The operator confirms permitted user checks. The person named in the clinic process decides whether the evidence is sufficient for the diary.

The local process may use three clear states:

• released for use: the exact change is recorded, required checks are complete and affected staff are ready;
• restricted: a written boundary applies, such as one configuration or additional supervision;
• not released: information, a check, competence or a service answer is still missing.

The decision record names the device, service document, confirmed change, completed user checks, any competence demonstration, restrictions, release owner and date. A later review point includes its reason, not only a calendar date.

Device and handpiece matched to the service order. Change recorded. Required user checks completed. Affected operators demonstrated the changed step. No restriction. Designated owner approved return; date and time recorded.

The label on the device, diary status and record must match. A private message to one colleague is not a release.

The most useful question after service is not “Does it work?” It is “What evidence tells us its current state, and who has authorised the next treatment?” When the record answers that question, return to use is complete.