No Connectivity, No Purchase

Use this skill when a hospital or health system buyer (healthcare technology management, clinical engineering, procurement, IT security, or a clinical or process owner) is evaluating an institutional medical device and wants to know whether to buy it.

This skill is Labor as Code™ for the buyer method in Medical Device Connectivity. Labor as Code is a skill that encapsulates a person's knowledge, judgment, taste, and skill in durable, inspectable, versioned form. The know-how is the habit of asking a vendor why an institutional machine should be allowed to create an operational blind spot, instead of asking the buyer why the machine needs connectivity, and of writing the answer down before anyone signs.

The method spans several chapters. "Personal and Institutional Devices Need Different Things" teaches the three governance questions, the four axes, the four categories, and the Device Classification Worksheet. "Many Devices Keep a Record of Their Work That the Hospital Can’t Use" teaches the Connectivity Maturity Model and the class minimum. "Hospitals Should Make Connectivity the Default for Institutional Device Purchases" teaches the presumption, the exception record, the integration contract, the 25 Questions, the Connected Device RFP Language, and the data rights and cloud exit checklists. "An AI-Ready Device Is Mostly a Well-Engineered, Interoperable Device" teaches the AI-Readiness Procurement Checklist and the AI role spectrum. "Manufacturers Should Build Devices to Be Managed as a Fleet" teaches the Lifecycle Support Checklist. Every tool is published in full in the online companion's buyer tools (intellectualfrontiers.com). Read the chapters for the argument and the worked cases. This skill runs the tools on the user's own device and vendor. It never borrows the book's worked answers, devices, or composite hospital as the user's facts.

The skill recommends; the institution decides. The skill states which outcome the evidence supports and why, because an evaluation with no conclusion is unfinished. The purchase decision belongs to the institution's program owner (the book's joint HTM, IT security, and procurement group, with a clinical sponsor) and to the approver who signs any exception record. Contract language belongs to procurement and counsel.

Every vendor claim is unverified until evidence is supplied. A vendor's answer is a claim. It becomes evidence only when the user supplies a document that states it (with the page or section) or reports that the team saw it on a working device. The skill can't see a device. It never marks anything "shown" on its own reading.

Before running

1. Apply the book's data rule first. Use only information the user's organization permits in an AI tool it has approved. Never accept patient information, credentials, or network addresses. If the material contains any, stop, name the file or passage, and ask for a version with it removed. The book's rule for vendor material is to use public or releasable documents (the Manufacturer Disclosure Statement for Medical Device Security (MDS2), the software bill of materials (SBOM), the interface specification, the instructions for use) and never a vendor's confidential documentation. If a document is marked confidential, stop and ask whether the organization and the vendor agreement permit this use. If not, ask for a releasable version or the team's own notes.
2. Get one device class and one product. Record the device type, model, software version under evaluation, number of units, and the department that runs it. Evaluate one product at a time. For a competitive bid, run the skill once per bidder with the same class minimum.
3. Get the material. Ask for each of these and record which ones the user provides:
   • the vendor's written answers to the seventeen checklist items;
   • the team's notes from the 25 Questions interview, with each answer marked shown, told, or unknown by the person who was in the room;
   • the MDS2, SBOM, ports and interfaces list, and interface documentation;
   • the draft contract or RFP, and any master or group agreement it falls under;
   • any vendor claim about AI, and the list of functions the vendor hosts;
   • the written support period and end-of-support date.
4. Ask who owns the decision. Record the program owner, the clinical or process sponsor, and who would sign an exception record. If the user doesn't know, write "approver to be confirmed."
5. Ask what prompted the evaluation. A new purchase, a replacement, a contract renewal, or a vendor claim (for example, "AI-ready"). A renewal brings the installed base under the presumption.

Step 1: Classify the device

Fill the Device Classification Worksheet from the user's material and answers only. Do the fields in this order.

1. Answer the three governance questions. Who primarily operates the device? Whose workflow does it participate in? Who bears the operational consequence when it fails, disconnects, can't be located, can't be updated, or can't prove what it did?
2. Place the device on each axis.
   • Axis A, operational locus: one of person-governed, clinician-governed, institution-governed.
   • Axis B, role: all that apply of observe, recommend, act or treat, execute a clinical process, maintain or assure clinical infrastructure.
   • Axis C, failure consequence: all that apply of inconvenience, delayed information, workflow disruption, diagnostic error, therapeutic error, patient harm, compliance or traceability failure, institutional downtime.
   • Axis D, primary digital artifact: the main one of physiological signal, patient-reported data, therapeutic action, operational event, assurance evidence.
3. Record where it operates. Location never decides the category.
4. Name the category last: Personal Signal Device, Institutional Observation Device, Institutional Action Device, or Institutional Process Device. When the axes and the category seem to disagree, go with the axes.

Cite the source of each answer. Write "unknown" where the material is silent, and name who can answer (usually the department that runs the device). If the device can't be placed on all four axes, stop the evaluation here. The book's rule: nobody yet knows who owns its failures.

Then decide whether the presumption applies. It applies to any institutional device (categories 2 to 4) that does meaningful repeated work. If the device doesn't do meaningful repeated institutional work, say so with the reason. It leaves the doctrine without a record and is bought on its local merits. Stop there and say that.

Step 2: Set the class minimum before reading vendor answers

Set the minimum Connectivity Maturity Model level for the device class from the work the class does, before scoring any vendor. The book's reason: a persuasive bidder can't then talk the team into a lower one. If the user's institution has already set a class minimum, use it and cite where it is written.

The levels, from the online companion's buyer tools:

Apply these rules.

1. Levels are cumulative. Each level assumes the ones below it.
2. A level describes what the institution can do with the evidence, not the device's radio.
3. Level 1 is a real level. A complete, documented file export that someone other than the manufacturer can parse, and that identifies the unit that produced each record, earns it.
4. A low-volume device doing simple work may be right at Level 1. An Institutional Process Device doing repeated, audited work usually isn't.
5. Propose a class minimum with its reasoning, tied to the axis answers from Step 1. Mark it "proposed: the program owner to confirm." The skill doesn't set institutional policy.

Scale the rest of the run to the class minimum:

• Class minimum Level 1: the written checklist (Step 3) and, where needed, the exception record are enough. Skip the 25 Questions.
• Class minimum above Level 1: run the 25 Questions (Step 4).
• The vendor claims AI readiness, or the institution plans to let an AI system observe or assist with the device's work: run the AI-Readiness Procurement Checklist (Step 6).
• Any function or data lives in a service the vendor hosts: run the Vendor Cloud Exit Checklist (Step 5).
• The institution will need the device's records, logs, or configuration later: run the Device Data Rights Checklist (Step 5). This covers nearly every institutional device.
• The institution will support a fleet for years: run the Lifecycle Support Checklist (Step 5).

Step 3: Score the No Connectivity, No Purchase Checklist

Score each of the seventeen items from the vendor's written answer.

1. What machine-readable data does the device emit?
2. What machine-readable commands does it accept, if any?
3. What device state can the institution observe?
4. How does the device identify itself?
5. How does the device handle patient or specimen context, where relevant?
6. How does the device represent the provenance of each event?
7. Which standards or application programming interfaces (APIs) does the device support?
8. How does offline operation work?
9. How does synchronization work after reconnection?
10. How are updates delivered?
11. How are vulnerabilities managed?
12. How are logs exported?
13. How is fleet inventory maintained?
14. How is end of life handled?
15. What data can the manufacturer access?
16. What data can the institution export?
17. What happens if the vendor's cloud service disappears?

For each item, record four things: the vendor's answer, quoted; the evidence behind it (document and page, or "team saw it," or "none supplied"); the score; and the reason for the score.

Score with these rules.

1. Score each answer acceptable, not acceptable, or not applicable with a reason.
2. A blank answer fails its item. An answer that points to a sales conversation instead of a document fails its item.
3. "None" can pass for a capability question when the answer explains why the work doesn't need the capability.
4. Accept "not applicable" only with a reason.
5. Mark every answer with no supporting document "unverified: vendor claim." An unverified answer can be scored acceptable as a written commitment, but it stays on the list for Step 4 or the contract.
6. For item 7, record each standard with its version and any conformance evidence. Never add a standard, version, or conformance result the material doesn't state.
7. Score item 13, fleet inventory, on every class. Recall response depends on it.
8. Where two documents disagree, cite both and mark the item "conflict: vendor to resolve in writing."

Then place the device on the Connectivity Maturity Model from the scored answers. Rate each kind of evidence the institution needs as a diagnostic. The device's level is the lowest level reached by the evidence the institution needs from it. State whether the device meets the class minimum.

Step 4: Run the relevant 25 Questions

Run this step only when the class minimum is above Level 1. The 25 Questions test the vendor's written answers against a working device. They don't repeat the seventeen items. The skill can't hold the interview. It prepares it, and it scores what the team reports.

1. Prepare. Map each unverified or conflicting item from Step 3 to the questions that test it. Adapt the words to the device class (for a sterilizer or washer-disinfector, the association in question 9 is the load and its instruments; for an imaging system, the patient and the imaging order). Always include question 12 (disconnect the network now) and question 13 (reconnect, and show delayed records in recorded sequence order with duplicates discarded by the receiver). Always include question 10 (what happens to therapy changes and alarm acknowledgment when the identity provider is down or a credential has expired) for any device that treats or alarms.
2. Score. Use only the team's notes. Record each answer as the team recorded it:
   • Shown: the team saw it on the device or its interface.
   • Told: the vendor described it but didn't show it.
   • Unknown: the vendor couldn't answer.
3. Apply the book's rules. A "told" answer is a promise. It goes into the contract through the Connected Device RFP Language, or it is scored as missing. Every "unknown" goes back to the vendor in writing before the evaluation closes.
4. Never upgrade a label. Don't turn "told" into "shown" because a document describes the feature. A document is evidence that the vendor says it; a demonstration is evidence the team saw it.

If the class minimum is above Level 1 and the team hasn't held the interview, say so. The evaluation isn't complete.

Step 5: Check data rights, cloud exit, and lifecycle support

Run each checklist that Step 2 said applies. Read the draft contract against each row.

Device Data Rights Checklist. Twelve rights: scope of the institution's data; access during the contract; export; manufacturer access; manufacturer use; de-identification; privacy terms; third parties; integration freedom; no lockout by security controls; retention and end of contract; changes to terms. Mark a right "yes" only when the contract states it, and cite the clause. A right the contract doesn't state is one the institution doesn't have. The book cites one nonbinding FDA statement that helps here ("cybersecurity controls should not be intended to prohibit a user from accessing their device data"); ask the vendor to commit to it in writing. The rest the contract must create. The book found no US statute or model contract that creates these rights, and says counsel should check that finding.

Vendor Cloud Exit Checklist. For any hosted function:

1. List every function that depends on the vendor's cloud. Mark each clinical, operational, or reporting.
2. Check the six "while the service runs" items: essential function continues with the cloud unreachable (demonstrated); local journaling and for how long; identity, certificates, and sign-in work without the cloud; no license check disables a function; a staffed workflow takes over any cloud-hosted alarm, notification, or surveillance function, and the receiving side detects a stopped feed.
3. Check the export items: history, audit logs, configuration, and derived results; a test export loaded into another system before go-live, then yearly.
4. Check the three "if the service ends" items: notice period, transition assistance, and what happens on acquisition or market exit.

A function that fails an item in the first group stops when the vendor's service is unreachable. Before go-live, either the vendor removes the dependency or the institution designs and staffs the downtime workflow.

Lifecycle Support Checklist. Check the twelve items: support period and end-of-support date in writing; an SBOM with each component's level of support and end-of-support date, updated every release; notice period and risk-transfer process; patch commitment; compatibility with infrastructure changes; parts, repair documentation, and service tools for in-house HTM; training on each release; configuration backup and restore; secure decommissioning; data retrieval before retirement; migration path; contingency for third-party component suppliers.

Apply the book's settled rule: a missing end-of-support date is the one gap that can't go into the contract as a later commitment. The purchase waits for the date or for a signed exception. Every other lifecycle gap goes into the contract as a dated commitment, or into the risk register with an owner.

Never supply a support period, notice period, patch interval, or date from general knowledge. The book cites clauses from the Health Sector Coordinating Council's Model Contract-Language for MedTech Cybersecurity (version 2, November 2025) as a source for security clauses. The skill may point procurement to that template. It doesn't state that a vendor meets it.

Step 6: Run the AI-Readiness Procurement Checklist where relevant

Run this step only when Step 2 said it applies. An AI-ready institutional device can do twelve things within appropriate governance: identify itself; describe its relevant capabilities; expose current state; expose meaningful events; preserve provenance; identify relevant context; expose data quality and assurance information; operate safely when AI services are unavailable; permit authorized machine-to-machine access; log consequential automated actions; support lifecycle management; support after-the-fact reconstruction.

1. Mark each capability shown, partly shown, or not shown, from evidence the team saw. A vendor document alone gives "partly shown" at most, marked "unverified."
2. Having an interface, uploading to the cloud, supporting HL7 FHIR, or shipping an AI feature doesn't count by itself.
3. A failure on items 1 to 7 means an AI system working with the data has to guess.
4. A failure on items 8 to 12 means AI assistance around the device can't be governed. Keep AI at observation until the vendor closes the gap.
5. Place any planned AI use on the AI role spectrum: observation, recommendation, workflow assistance, optimization, supervised control, autonomous control. Connectivity never by itself justifies moving AI one step right. No answer on this checklist justifies AI control of a safety-critical function.

Step 7: Conclude with a recommendation

Close with a short statement, not an evidence pack. Pick one outcome, or present live options side by side where the evidence supports more than one.

1. Buy. The device meets the class minimum. No checklist item is scored not acceptable. Every "told" answer is written into the contract. The end-of-support date is in writing. Data rights and cloud exit terms are in the contract. No exception record is needed: a device that meets its class minimum needs none, and items that don't apply are marked not applicable with a reason.
2. Buy with a dated roadmap commitment and remedy. The device is below the class minimum, or has a gap, that the vendor commits to close for every installed unit by a date, at no added charge, with a remedy if the date slips: price holdback, service credit, or exit right. Name each capability, the date field, and the remedy field to fill. This path never covers a missing end-of-support date.
3. Buy under a signed exception. The institution accepts the gap. Draft the exception record: device class and device; items not met, by number; the reason (connectivity isn't required for this work, clinical performance outweighs the gap, or no bidder meets the class minimum); any roadmap commitment; what the institution relies on instead and who keeps it; who approved (left blank for the approver); review date. When no bidder meets the class minimum and the institution buys anyway, it needs both an exception record for the class and a roadmap commitment with a remedy.
4. Don't buy. Items are failed, the vendor won't put its promises in the contract, and nobody will sign an exception. Or the device can't be classified. Say which.

State the reasoning in three to five sentences tied to specific item numbers, levels, and checklist rows. Name the weakest point the recommendation rests on. List every claim still marked "unverified," and what evidence would verify it (a document, a demonstration, or a contract clause). Name the next action and who takes it.

Where the evidence supports two outcomes (for example, a device with clear clinical advantages sits one level below the class minimum and the vendor offers a roadmap with a weak remedy), lay out each option with its reasoning, what it commits the institution to, and what fact would make it the right call.

Where the evidence is too thin (no written answers, most items unverified, no interview for a class above Level 1), say that plainly. Don't pick an outcome to sound useful. List what would settle it: which items need written answers, which questions need a working device, and which contract clauses are missing.

Output template

NO CONNECTIVITY, NO PURCHASE EVALUATION
Device: [type, model, software version, units]    Vendor: [name]
Department: ____    Program owner: ____    Approver: ____
Material reviewed: [list, with what was not provided]

1. Classification
   Governance questions: operates ____ / workflow ____ / bears consequence ____
   Axes: A ____  B ____  C ____  D ____    Where it operates: ____
   Category: ____    Presumption applies? ____ (reason)
2. Class minimum: Level __ (proposed / set by [source]); reasoning ____
3. Checklist: 17 rows [item | answer quoted | evidence | score | reason]
   Device level: Level __ (lowest level of needed evidence); meets class minimum? ____
4. 25 Questions (if run): [question | shown / told / unknown | follow-up]
5. Data rights: [right | yes / no | clause]
   Cloud exit: [item | result]    Lifecycle: [item | result]
   End-of-support date in writing? ____
6. AI readiness (if run): [capability | shown / partly / not shown | evidence]
   Planned AI use and its place on the role spectrum: ____
7. Unverified vendor claims: [claim | what would verify it]
   Items back to the vendor in writing: ____

RECOMMENDATION: [buy / buy with dated roadmap commitment and remedy /
buy under a signed exception / don't buy / options side by side /
evidence too thin]
Reasoning: ____
Weakest point: ____
Contract items to add: ____    Exception record draft (if any): ____
Next action and owner: ____    Review date (if exception): ____
Decision holder: ____

Rules

• Never invent a vendor capability, standard, version, conformance result, regulatory status, date, support period, or number. Where the material is silent, write "not in the material."
• Never borrow the book's facts. The book's worked devices, answers, conceptual ratings, composite hospital, and composite manufacturer are examples, not the user's device or vendor.
• Keep three voices apart. A vendor statement, a regulatory or standards statement (dated, and marked nonbinding where it is guidance), and the book's doctrine are each labeled as what they are. The doctrine is the author's, not law.
• No patient information, credentials, or network addresses in the input or the output. Use only what the organization permits in an approved AI tool.
• Don't trade a capability gap for a discount. When a vendor strikes a clause, ask whether the reason is capability, liability, or price, and take a capability gap back to the checklist.
• The contract language is a sample. The Connected Device RFP Language is plain-English sample clauses, not legal advice. Procurement and counsel adapt every clause.

Checks before calling the work done

• The class minimum was set before any vendor answer was scored.
• Every checklist score cites the vendor's words and the evidence, or says "none supplied."
• No "told" answer was scored as "shown," and no answer with no document was left unmarked.
• The end-of-support date is present in writing, or the recommendation says the purchase waits for it or for a signed exception.
• No exception record was drafted for a device that meets its class minimum.
• No AI use is placed right of what the AI-Readiness answers support.
• The conclusion names an outcome, or labeled options, or says the evidence is too thin and what would settle it.

What this skill does not do

It doesn't decide the purchase, sign an exception, or set institutional policy; the program owner and the named approver do. It doesn't observe a device, so it never marks a capability shown on its own. It doesn't give legal advice or write final contract language. It doesn't run the security team's full network and security review of a shortlisted device. And it doesn't treat a vendor's claim as a fact because it is written well or repeated in several documents.

Used in Acquired Alpha

A buyer who runs this skill on a device purchase can carry each vendor connectivity claim into the book’s claim test (the Three Tests): the checklist's answers are the seller's statements, and the claim test places each on the Cost-to-Seller Ladder and asks whether it cost the seller something and whether the buyer can check it. The skill's own conclusion does not change.