Running HCBS Software Air-Gapped: What It Actually Means for Your IT

Short answer: An air-gapped deployment means the system that holds your client records has no network path to the internet at all — not a firewall rule, no path. For HCBS software that is achievable, but it is not free. EVV submissions, claims and remittances still have to leave and enter the building, so they become deliberate, logged file transfers instead of background network calls. Caregivers in the field are outside your network by definition. And everything a vendor normally does for you — patching, monitoring, backups, support — becomes a process your IT team runs. Choose it when policy requires no path at all; otherwise a restricted on-premise deployment usually gives you most of the protection for a fraction of the work.

"On-premise" and "air-gapped" get used as if they were the same thing. They are not, and the difference is exactly where most of the operational cost sits.

Three deployments that get called "on-premise"

Most of the benefit people want from "air-gapped" — the data stays in the building, and the vendor cannot reach it — is delivered by the middle column. The right-hand column adds one more guarantee: nothing can reach the data over a network, including a misconfigured rule or a compromised dependency. That guarantee is real. So is the work.

What still has to cross the gap

HCBS is not a closed system. Even a fully isolated deployment has to exchange data with the outside world on a schedule:

• EVV. In Colorado, a Provider Choice system transmits completed visits to the Sandata aggregator. Air-gapped, that transmission becomes an export file that someone moves out through your transfer process. Confirm with HCPF and the aggregator which submission methods your alternate EVV enrollment supports before you commit to a schedule.
• Claims. 837 claim files go to your clearinghouse or the state, and 835 remittances come back. Each direction is a transfer.
• Eligibility and authorizations. Anything you currently check live — member eligibility, updated authorizations — becomes a periodic import.
• Payroll and accounting. Approved hours and billing data go out to systems that almost certainly are not air-gapped.

None of this is a reason not to do it. It is a reason to design the transfer step before go-live rather than after the first delayed claim run: who moves files, how often, through what scanned and logged path, and what happens when that person is on vacation.

Our API and integrations page describes how these exchanges run as controlled file transfer when outbound connections are not allowed.

The field problem: your caregivers are not on your network

An air-gapped server sits inside your building. The people delivering services do not.

A caregiver clocking in at a member's home cannot reach an isolated system in real time. The workable pattern is offline capture: the caregiver app records the visit on the device with its original timestamps and location, and syncs when the device next joins your internal network — usually at the office.

Two consequences to plan for:

EVV timing. Visits arrive in the system when devices come back, not when the visit ends, and then leave for the aggregator on your export schedule. Check that lag against your own submission and billing timelines.

Telephony fallback. Phone-based visit verification needs a phone line into the system. That is a network path. Decide with your security team whether it is in scope for the isolated environment, or whether members without a usable device are handled another way.

What your IT team takes on

This is the part vendor brochures skip. In an air-gapped deployment, your team owns:

• Updates and security patches. Delivered as signed packages that your staff verify and install. Agree a cadence in writing — an isolated system that is never patched is not more secure, it is just harder to reach.
• Backups and restores. Off-site copies have to leave the building physically or through the same controlled path. Test a restore; a backup you have never restored is a hope.
• Time. EVV records the time of service. A network with no internet has no internet time source, so it needs its own — a local time server with a reliable reference. Drifting clocks are a quiet way to generate EVV exceptions.
• Identity and access. Single sign-on, password resets and account removal happen against your own directory, inside the network.
• Monitoring and logs. Audit logs are only useful if someone reviews them and they are retained for as long as your records policy requires.
• Support. A vendor engineer cannot connect in. Agree how diagnostics leave the building, and how quickly, before you need them.
• Hardware lifecycle. Capacity, disk replacement, and a recovery plan for the day the server itself fails.

If that list reads as a job description, that is accurate. Budget for it as one.

When air-gapped is the right call

It is the right answer when a policy — county IT, a Community Centered Board's board, a tribal or government host network — says protected health information may not sit on any system with a network path outside the building. It is also defensible when your risk assessment concludes that the remaining network risk is unacceptable for your population.

It is usually not the right answer because HIPAA "requires" it. It does not. The HIPAA Security Rule is risk-based and does not mandate a particular architecture; encryption, access control, audit logging and a documented risk analysis satisfy it in the cloud too.

And it is not the right answer if nobody on staff will own the list above. An unowned air-gapped server tends to become an unpatched one.

Questions to ask any vendor who says "air-gapped"

Ask all of these, of everyone, including us.

• Which features, if any, are unavailable or delayed in an air-gapped deployment? Get the list in writing.
• Show me an EVV submission leaving an isolated deployment, end to end.
• How are updates delivered, how are they signed, and how do we verify them?
• What does the caregiver app do when it cannot reach the server for a full day?
• How do your support engineers help us without remote access?
• Where do AI or analytics features run, and does any data leave for them?
• What time source does the system trust for visit timestamps?
• Can we move between cloud, on-premise and air-gapped later without re-implementing?
• What can we export, in what format, if we leave?

A vendor who has actually run isolated deployments will answer the first question quickly and specifically. One who has only put the word on a pricing page will tell you nothing changes.

Where OutcomeGrid fits

OutcomeGrid runs in our managed private cloud, on your own server, or fully air-gapped. In isolated deployments, integrations — including EVV transmission and claim files — run through controlled file exchange rather than live outbound calls, updates arrive as signed packages, and AI features run inside your deployment so client data does not leave your network for analysis. The caregiver app captures visits offline and syncs when devices return to your network.

Most agencies are best served by the managed cloud or a restricted on-premise install, and we will say so when that is true for you. For the agencies whose boards or host networks require no path at all, the Colorado overview and our security page cover how the deployment options compare.

If your board is asking the question, bring us the policy wording. We will walk through what an isolated deployment would look like against it, including the parts your IT team would own.