Deploying Software Inside Hospital Networks: What to Expect

There is a category of software vendor that has never had to think about where their application runs. They provision in a cloud region, point a DNS record at it, and the deployment conversation is over.

Hospital software is not in that category. For a meaningful set of clinical and operational systems, the answer to "where does it run" is: inside our network, on infrastructure we control, integrated with our identity provider — or we are not buying it.

This changes the engineering, not just the sales conversation.

Why hospitals insist

It is easy to read this as institutional caution. Mostly it is not.

Hospitals operate under regulatory obligations with real consequences, and they hold data whose exposure harms people who did not choose to take the risk. A hospital security team that declines to send inventory and procurement data to a third-party cloud is making a defensible call about a system they will be accountable for long after the vendor relationship ends.

There is also a continuity argument that gets less attention and is arguably stronger. A hospital cannot pause because a vendor is having an incident. Software that runs inside the network keeps running when the internet link does not.

What changes when you cannot assume your own infrastructure

You do not control the environment. Different sites run different OS versions, different database versions, different network topologies. Anything your application quietly depended on — a managed service, a specific cloud primitive, outbound internet access — is now a deployment requirement someone has to satisfy.

You cannot deploy on Tuesday because you feel like it. Updates go through change control. There is a window, an approval, and a rollback plan. Continuous deployment is not available; versioned, tested releases with documented upgrade paths are what you ship instead.

Debugging is different. No production access. No live logs streaming to your dashboard. When something breaks, you work from what the customer can export. Applications built for on-premise need to be far more forthcoming in their own logs, because those logs may be your only view.

Authentication is theirs, not yours. You will integrate with their identity provider. Building your own user store is generally a non-starter, and rightly so — nobody wants another set of credentials to manage and offboard.

Backups and disaster recovery are theirs too. Your job is to fit their process: documented data layout, a supported backup mechanism, and a restore path someone can verify without you on the call.

Security review is a project

Expect a security questionnaire, and expect it to be long. Data flows, encryption at rest and in transit, dependency inventories, vulnerability handling, incident response commitments, access controls, audit logging.

The useful reframing is that this is not a hurdle placed in front of the work. It is a specification of the work. A team that treats it as a form to complete at the end will be rewriting things. A team that treats it as requirements will find most answers already true.

Two things pay for themselves repeatedly:

• A real dependency inventory, maintained rather than generated in a panic. You will be asked what you ship and how you handle a CVE in it.
• Meaningful audit logging. Who did what, when. Clinical environments need this for reasons that have nothing to do with your application, and retrofitting it is much harder than designing it in.

What we learned building MediVentory

MediVentory runs inside hospital networks, tracking medical inventory, procurement, and consumption. A few things shaped it more than anything else:

Design the install before the feature set. If deployment is an afterthought, every feature accumulates an assumption that has to be unwound. We containerised early and treated the installation as a deliverable in its own right.

Assume no outbound internet. Not every hospital network segment has it. Anything that phoned home for licensing, telemetry, or updates would have been a blocker.

Make configuration explicit and few. Every configurable option is something a customer's IT team has to understand and get right. Sensible defaults with a small, documented set of overrides beats flexibility nobody asked for.

Write documentation someone else can execute. You will not be in the room. The install guide is not marketing collateral — it is the product, as far as the person doing the installation is concerned.

Is it worth it

For most consumer software, no. The overhead is substantial and it constrains how fast you can move.

For software that needs to live in regulated environments, it is often the only way in — and that difficulty is precisely why the field is less crowded. Vendors who can clear procurement and security review are competing in a much smaller set than vendors who cannot.

---

eRP Systems builds and operates MediVentory, a medical inventory and procurement platform deployed inside hospital networks. Get in touch if you need software that has to run inside your own environment.