Chapter 3 — Working with clinical device vendors
Lesson map
Lesson 03 published. Map, example, EX011.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Certified configurations"]
N2["3.2 Costs and timing"]
N3["3.3 Written commitments"]
N4["3.4 Shared responsibility"]
N5["When the vendor cannot help yet"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX011"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Certified configurations"]
N2["3.2 Costs and timing"]
N3["3.3 Written commitments"]
N4["3.4 Shared responsibility"]
N5["When the vendor cannot help yet"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX011"]
[Learning outcomes]
|
v
[3.1 Certified configurations]
|
v
[3.2 Costs and timing]
|
v
[3.3 Written commitments]
|
v
[3.4 Shared responsibility]
|
v
[When the vendor cannot help yet]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX011]
Learning outcomes
You will (1) find a vendor's certified configurations; (2) plan upgrades jointly; (3) record vendor commitments.
3.1 Certified configurations
Imaging software is certified on specific operating system versions. Running it on an uncertified version may void support. Priya asks the vendor for its current compatibility list and finds that a supported version is certified for newer software releases, but the clinic's licence covers only the old release. The licence gap turns a technical question into a commercial one. Priya records the certified versions, the licensed release and the upgrade path for each imaging model, with the date of the vendor's list, so that later decisions can be traced to that evidence.
3.2 Costs and timing
Upgrading means a software licence upgrade, possibly new hardware for capture cards, and a visit by the vendor's engineer. Priya builds a simple cost and schedule table per machine, which shows that most can move within the year if work is batched by clinic. Batching by clinic means one engineer visit can cover several machines and one disruption window for each site. The table lists each machine's licence, hardware and labour needs with a target month, and Kestrel's finance lead reviews it before the budget is set. Priya marks costs as estimates until the vendor's quote arrives, so the table does not promise more than the evidence supports.
3.3 Written commitments
Promises made on the phone are easily forgotten. Priya asks the vendor to confirm in writing the target versions, prerequisites and engineer availability. These letters become evidence for the exception register and for auditors. Written confirmation also protects Kestrel if staff change at the vendor. For Harbour's machines, the letter states the target version, the capture card replacement and the planned month. Priya files each letter with the inventory row it supports, so anyone reviewing an exception can see what the vendor promised and when it was due.
3.4 Shared responsibility
NIST SP 800-53 Rev. 5 control SA-22 addresses unsupported system components, expecting replacement or documented justification. Kestrel cannot shift this duty to the vendor, but it can make the vendor's role explicit in the contract renewal, including notice periods before support ends. Priya drafts contract language for the operations manager: the vendor should give notice before support for a certified version ends, publish its compatibility list, and state how long each release will be supported. The supplier's role is also written down, since it operates the machines but does not own the risk. The proposal goes to Kestrel's next contract review, and Priya records it as a recommendation rather than an agreed term.
When the vendor cannot help yet
For two cephalometric machines the vendor has no certified newer release. Upgrading anyway would leave the clinic with unsupported clinical software, which is a different risk rather than a fix. Priya records the vendor's expected release quarter in writing, asks to be notified when it ships and moves both machines into the exception process described in chapter 4. The record states what is waiting on whom, and until when. This matters for governance: an unsupported machine that is known, isolated and scheduled is a managed risk, whereas one that is simply forgotten is an unmanaged one, even though the machine itself is identical in both cases.
Worked example
For Harbour's four machines, the table shows one licence upgrade, two capture card replacements and one engineer day, with a target month agreed in writing.
Synthetic case. The vendor, versions and costs are fictional.
Errors and limits
Upgrading the operating system without the vendor's confirmation can break imaging; the plan always waits for written compatibility.
Exercises
- EX011 — Certification risk. What risk arises from upgrading an imaging PC's OS without vendor certification? Rubric: 3 = loss of support and possible clinical disruption;; 2 = one of those;; 1 = vague;; 0 = none.
- EX012 — Batching. Why batch upgrades by clinic? Rubric: 3 = reduces engineer visits and disruption;; 2 = reduces cost;; 1 = vague;; 0 = none.
- EX013 — Evidence. Why ask for written vendor commitments? Rubric: 3 = audit evidence and reliability;; 2 = one;; 1 = vague;; 0 = none.
- EX014 — Contract terms. Suggest one clause for contract renewal. Rubric: 3 = specific notice period before end of support;; 2 = general clause;; 1 = vague;; 0 = none.
- EX015 — Control reference. Which SP 800-53 control addresses unsupported components? Rubric: 3 = SA-22 with its expectation;; 2 = SA-22 only;; 1 = wrong control;; 0 = none.
Synthesis
Vendor engagement turns an impossible-looking upgrade into a costed, scheduled plan.
Continue studying — chapter 03 of 12
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →