What a hospital will ask before it reconnects your integration

When a health system disconnects from the internet, every vendor that depends on a connection into it goes dark at the same moment, and the vendor does not decide when it comes back. The hospital does.

University Hospitals in Cleveland is the current example. A spokesperson said staff detected "unusual activity" on Thursday, Oct. 22, and that the system activated its response protocols and, out of an abundance of caution, disconnected its systems from the internet. In an updated statement on the evening of Friday, Oct. 23, UH said the action had disrupted certain services, including access to MyChart, and that it had "begun to reconnect to some external partners," while expecting some impact to continue into the following week. UH also said there was no current impact to patient care delivery, though it had begun rescheduling some appointments and elective procedures.

As of that reporting, UH had not publicly detailed the nature of the activity or said whether it involved a cyberattack. I am not going to guess. The cause does not matter for this post. The phrase that matters is "some external partners." Reconnection happens in an order, one partner at a time, and somebody at the hospital is deciding that order right now.

Reconnection is a decision, and you are on the list

If you sell a product that integrates with a health system, picture the inside of that decision. A response team has a list of every external connection: interfaces, APIs, VPN tunnels, file transfers, SaaS tools with service accounts. For each one they have to decide whether it is safe to turn back on, and in what order. The partners that can answer questions quickly and with evidence move up the list. The ones that need a week to find out what their own integration does move down.

That is a readiness question most founders never plan for. Security questionnaires ask whether you have an incident response plan. They rarely ask what you will hand a health system's response team when the problem is on their side and your product is collateral. Being ready for that call is part of being ready to sell into health systems at all.

The questions you should expect

I would expect some version of these, asked by someone who is tired and under pressure.

What exactly connects to us? They want a list, from you, of every connection your product has into their environment: endpoints, IP ranges, ports, protocols, direction of traffic, and which side initiates. If you cannot produce it in an hour, they will assume you do not know.

Which credentials do you hold, and can we rotate them? Service accounts, API keys, certificates, OAuth grants, shared secrets. They may want to rotate all of them before reconnecting. Your product needs to survive that without a code change or an engineer on a plane.

Did anything unusual come from your side? They will ask whether your logs show anything odd in the days before the disconnect. That is a reasonable question even when nobody suspects you. You need logs that cover the integration, kept long enough, and someone who can read them quickly.

What happens to queued data? Messages, orders, results, or files that piled up while the connection was down. Will your system replay them, drop them, or duplicate them? In a clinical setting, a duplicated order or a silently dropped result is a patient safety question.

Can you reconnect with less? Some teams will want to bring partners back with reduced scope first: read-only, fewer endpoints, a narrower allowlist. If your integration is all or nothing, you are harder to reconnect.

Who do we call? A named person, a backup, and a phone number that works on a weekend. A support queue alone will not do.

What to build before you need it

None of this needs to be invented during the outage. Most of it is a one-page document and a few product decisions.

1. An integration sheet per health system: every connection, credential type, data flow, and owner on both sides. Keep it current when the integration changes.
2. Credential rotation you have practiced. Rotate a test tenant's keys on purpose and time it. If it takes days, fix that first.
3. Integration logs you can search and hand over. Know what you log, where, and for how long, and be able to export a time window for one health system.
4. A defined behavior for backlog. Decide in advance how queued data replays, how duplicates are caught, and how the hospital can confirm nothing was lost.
5. A degraded mode. A way to run with reduced permissions or scope while trust is rebuilt.
6. An on-call contact you have put in writing to every health system you serve, with an escalation path.

The leadership view

For a founder or a board, the risk here is revenue and patient-facing service that stop when someone else makes a cautious, correct decision, and stay stopped until you can answer questions you have never rehearsed. A health system that disconnects out of caution is doing its job. Your job is to make it easy to bring you back.

This is also where AI features add a wrinkle. If your product sends data from the health system to a model provider, the response team will want that path on the integration sheet too: which provider, which region, which credentials, and whether anything leaves during reconnection. Treat the AI path as one more external connection, because to them it is.

A test you can run this week

Pick your largest health system integration and ask your team to produce the integration sheet, a credential rotation plan, and a log export for one week, as if that health system had just disconnected. Time how long each takes. Whatever takes longest is what will keep you at the bottom of someone's reconnection list.