---
name: no-connectivity-no-purchase
description: 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. It classifies the device with the Device Classification Worksheet, sets the class minimum on the Connectivity Maturity Model before reading any vendor answer, scores the vendor's written answers to the No Connectivity, No Purchase Checklist, runs the relevant 25 Questions Before Buying an Institutional Medical Device, checks data rights, cloud exit, lifecycle support, and AI readiness where they apply, and concludes buy, buy with a dated roadmap commitment and remedy, buy under a signed exception, or don't buy, with the reasoning. Every vendor claim stays unverified until evidence is supplied. Triggers on requests like "should we buy this pump," "score this vendor's RFP answers," "run No Connectivity, No Purchase," "is this device connected enough," "what class minimum should we set," "check this contract for data rights and cloud exit," "the vendor says it's AI-ready," "do we need an exception record," or "none of the bidders meet our requirements."
---

# No Connectivity, No Purchase
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:

| Level | Name | What the institution can do with the evidence |
| --- | --- | --- |
| 0 | Silent | Nothing machine-readable |
| 1 | Exportable | Retrieve complete machine-readable records after the fact, by a person |
| 2 | Network Observable | See status and records over the network as they happen |
| 3 | Workflow Integrated | Move events and state into the workflows that use them, with context |
| 4 | Fleet Managed | Inventory, configure, update, monitor, and retire every unit as a fleet |
| 5 | AI-Ready and Evidence-Producing | Rely on the twelve AI-ready capabilities and Evidence by Operation, with provenance |

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.