Patient Logistics Infrastructure Should Be Boring

VectorCare ships four products. PACE Logistics. Mass Movement. Air Ambulance Marketplace. vectorcare.dev. Different buyers. Different price points. Different urgency curves.

Same plumbing.

That last sentence is the most important thing I have figured out in six years of building patient logistics software. The applications people see at the surface look nothing alike. The infrastructure they ride on is identical. Once you accept that, the way you build, the way you sell, and the way hospitals buy all change.

This is the case for patient logistics infrastructure as a category, not as a feature of any single app. It is also the most useful frame I have for health systems trying to figure out where to spend the next ten years of IT budget.

The four apps people see

Here is what a normal Tuesday looks like inside our customer base.

A PACE program in Cleveland coordinates 240 participants for transport, dialysis, day-program pickup, and pharmacy delivery. The work happens inside Epic. Each participant is tracked individually. Costs roll up to the program's PMPM.

An ED director in Tampa runs a hurricane drill. Forty-eight beds need to move in twelve hours. Mass Movement gives her a live destination panel, transport availability across ground and air, and a shared incident view that the regional EOC can read without phone calls.

A transfer center in Lubbock dispatches a STEMI to a tertiary cath lab eighty miles away. The Air Ambulance Marketplace shows four carriers, three airframes, current weather, and a quote per leg, all inside Epic.

A vendor in Boston wires a custom asthma-discharge workflow into three hospital instances of Cerner. They built it on vectorcare.dev. Free build tier. Paid implementation. Recurring SaaS once it ships.

Four apps. Four buyers. Four problems. The EHR launch, the dispatch context, the FHIR contract, the audit log, the SMART surface, the directory of providers. All the same.

What infrastructure actually means in this layer

The word gets thrown around in health IT to the point of meaninglessness. Let me be specific.

Patient logistics infrastructure is the set of capabilities every patient-movement application needs to function inside a real hospital. There are five.

A SMART on FHIR launch surface so apps open inside Epic or Oracle Health with the patient context already loaded.

A directory of providers and capabilities. Ambulance services. Air carriers. Home health agencies. DME suppliers. Accepting facilities. With structured availability.

A dispatch primitive that knows how to ask, accept, decline, escalate, and re-route a request without re-implementing the state machine each time.

An audit and billing layer that produces the timestamps, payer codes, and quality metrics regulators and CFOs both ask for.

A common identity and consent layer that respects each hospital's RBAC and HIPAA posture without forcing the app authors to fight it.

If you are building an app that moves a patient, books a vehicle, dispatches a crew, or coordinates a hand-off, you need all five. The mistake the industry made for the last decade was assuming those five had to live inside the application. They do not. They belong one layer down.

Why hospitals end up buying four monoliths instead

Most health systems I talk to have already bought patient logistics software three or four times. A scheduling tool from one vendor in 2017. A discharge platform in 2019. An ambulance dispatch system in 2021. A disaster preparedness package in 2023.

Each one came with its own dispatch logic, its own provider directory, its own EHR integration project, and its own login. Each one was sold as a complete solution. Each one is now its own integration debt.

The reason this keeps happening is not that hospitals are bad at procurement. It is that the vendor incentive runs the other direction. If you sell one app, you can sell the rails underneath it as part of the bundle. The customer pays for those rails four times across four bundles. Nobody calls it that.

The right shape is one rail and many apps. PACE on top. Mass Movement on top. Air Ambulance on top. Whatever the hospital builds itself on vectorcare.dev on top. One audit log. One provider directory. One identity model. One contract for the layer underneath.

What this means for the people writing the checks

For a CIO, the question is not "do we buy the PACE app or the discharge app." It is "which platform are we standing up so that the next eight apps cost a fraction of the first one." The first integration is the expensive one. The eighth should not be.

For a CFO, the case is even simpler. Patient logistics infrastructure is a fixed-cost layer with declining marginal cost per app. Buy the rails. Ride them four times. Compare to the alternative of paying full integration cost per app, every time.

For a CMIO, the win is consistency. A clinician should not have to re-learn the model of "what is happening with this patient in transit" four different times because four apps each invented their own widget. Same launch. Same status. Same audit trail.

For a CNO running a disaster drill, the value is operational. Bed availability, transport availability, evacuation orders, post-event reporting, all in one timeline, all in one set of records, all reportable to Joint Commission without an export.

What we built underneath

The four VectorCare products run on a shared layer we have spent the last five years sharpening. Some of it is obvious. Some of it is not.

A FHIR-native data model. Patients, encounters, transports, providers, accepting facilities. All expressed as FHIR resources. All addressable by the same APIs across all four products.

A SMART on FHIR launcher embedded in the EHR. One install in Epic. One install in Oracle Health. Every product launches inside the chart with the patient context, in under three seconds.

A dispatch state machine that handles request, acknowledge, accept, decline, escalate, divert, and close, without each application reinventing the protocol. PACE uses it for transport. Air Ambulance uses it for flights. Mass Movement uses it for whole-floor movements during evacuations. The state names are the same.

A provider directory with structured capability metadata. PACE programs see ambulettes, dialysis vans, and home health agencies. Mass Movement sees ground transport, helicopter, and fixed-wing. Air Ambulance sees carriers with airframe, crew, and weather minimums. Same directory. Different filters.

A billing and audit layer that produces the right CPT codes, the right HCPCS codes, the right Joint Commission timestamps, and the right CMS reporting fields per product.

vectorcare.dev exposes this entire layer to outside developers. A vendor with a workflow idea can build on the same rails our internal teams use. They get the SMART launch, the FHIR data model, the dispatch primitives, and the audit trail. They do not get a sales motion attached.

The boring part

The reason I keep coming back to the word "boring" is that the moment patient logistics infrastructure stops being interesting, hospital ops start working.

Stripe is the model. The moment payments became a fixed-cost layer that just worked, every internet business stopped writing its own merchant integration and started shipping product. The interesting work moved to the application layer.

That is what I want for hospital operations. Stop debating which dispatch tool to buy. Stop running a six-month integration project for every new patient flow app. Stop re-paying for the same five primitives across four vendors.

If a transfer center director can launch four different apps inside Epic and the launches all feel identical, the rails are working.

If a CIO can stand up a fifth app for a fifth use case in eight weeks instead of two quarters, the rails are working.

If a vendor with a niche idea can build on top in two months instead of two years, the rails are working.

Where this goes next

We are not done. The pieces I described above are the ones we use today across the four products. There are at least two more we have started on and have not finished.

A national capability index any hospital can query in real time to find the right transport, the right facility, or the right accepting service, without dialing.

A reusable consent and identity layer that lets a patient's transport authorization travel with them across hospitals during disaster events, without each receiving facility re-collecting it.

Both will live in the same layer. Both will be available to all four products at the same time. Both will be available on vectorcare.dev for outside developers to build against.

Patient logistics is going to look different in 2030 than it does today. The way it gets there is not by one vendor shipping a bigger app. It is by the infrastructure underneath the apps getting boring enough that the apps stop being the bottleneck.

Patient logistics infrastructure should be boring. We are working on it.