Mobile Integrated Health Software: How Do You Prove to the Hospital That Your Program Actually Worked?

Why the software is what gets your program renewed

A community paramedic finishes a home visit with a man who called 911 nine times in the last four months. Today he sorted out a pill box the man could actually open, called the pharmacy about a duplicate prescription, found out the man had missed two cardiology appointments because the bus route changed, and booked transport for the next one. That visit is worth more than most of what the ambulance did on those nine calls. He documents it in the ePCR because that is the tablet he was issued, as a narrative on a form that expects an emergency, with a disposition of no transport.

Nine months later the hospital that funds the program has to decide whether to renew. Somebody in the EMS office spends a fortnight building a slide deck out of ePCR exports, a spreadsheet of enrolled patients and whatever the hospital's analyst is willing to run. The deck shows visit counts. The hospital wanted readmissions on their attributed patients. The two things are not the same and everyone in the room knows it. The program is renewed on goodwill, or it is not renewed at all, and the paramedics who did genuinely good work find out that good work is not the same as evidence.

That is the whole business case for building. Community paramedicine is not funded because it is clinically sensible, it is funded because a hospital, a health plan or a state grant expects a specific number to move. The software's job is to produce that number without a fortnight of someone's life, and to produce it in a form the funder's analyst will accept.

Problem one: an ePCR is the wrong shape for a longitudinal patient

ESO EHR and ImageTrend Elite are competent emergency records and both have added community paramedicine modules, which is a reasonable thing for them to do. The structural mismatch remains. An ePCR is built around an incident: one call, one patient encounter, one disposition, one closed record. A community paramedicine patient is an enrolment that runs for months, with goals, a care plan, a risk score that changes, referrals in flight, and a discharge that means something entirely different from a transport disposition.

Try to express a care plan in an incident record and you get a narrative. Narratives cannot be counted. So the program's actual content, meaning what the paramedic did and whether it worked, becomes unqueryable prose, and the only things you can report are the things the incident form happened to code.

What a custom build does: enrolment is the primary object. A patient has an enrolment with a start, a referral source, a stratification, a set of goals with measurable targets, a schedule of visits, and a defined exit reason. Each visit is a child of the enrolment and captures structured assessment plus what changed against the goals. Julota is genuinely built around this model and is the strongest packaged option in the category, which is why we tell smaller programs to start there. Where it stops is when you have several funders whose definitions of success differ, which brings us to the real problem.

Problem two: every contract counts something different

The hospital counts thirty day readmissions on patients they attribute to you. The health plan counts avoidable emergency department visits on their members, on their attribution logic, in their measurement window. The state grant counts enrolments and visits and wants a demographic breakdown. The fire district wants call volume from your frequent caller list. These are four different numerators over four different denominators, and no packaged product will let you define them because they are written in your contract language and nowhere else.

What a custom build does: make the measure definition a configurable object rather than a hardcoded report. A measure has a population rule, an attribution source, a window, an event definition and an exclusion set. You define the hospital's readmission measure once, exactly as the contract words it, and it recalculates every night. When the plan renegotiates and changes the window from thirty days to forty five, you edit a definition instead of commissioning a report. Every measure carries a drill-down to the patient list behind the number, because the first thing a funder's analyst does is ask which patients, and a number you cannot decompose is a number they will not accept.

Problem three: you cannot measure outcomes without the hospital's data

Here is the uncomfortable truth about outcome reporting. You do not observe the outcome. A readmission happens at the hospital, an emergency department visit happens whether or not your ambulance brought them, and a death happens somewhere you were not. Any program claiming to prove readmission reduction from its own visit records is claiming something it cannot see.

What a custom build does: ingest an admission, discharge and transfer feed. This is the single most valuable integration in the category and it is usually achievable, because your funding hospital already sends ADT notifications to its own care management team and adding a subscriber is a smaller ask than it sounds. With ADT you get near real time notice when an enrolled patient hits the emergency department, which turns your program from retrospective to responsive: a paramedic can be at the house the next day rather than finding out at the next monthly meeting. The same feed produces the outcome measure honestly, because the events are observed rather than inferred. Where a health information exchange is available in your region, subscribing to it covers the hospitals your funder does not own, and that is often where your patients actually go.

Problem four: consent and confidentiality are the part that gets programs shut down

Your program sits across EMS, hospitals, behavioural health, housing and social services. Each of those has a different legal basis for sharing. Substance use treatment records carry stricter federal protection than general health information, and a paramedic who forwards a client's history to a housing caseworker because it seemed helpful can create a real problem for the agency. Consent is not a checkbox at enrolment. It is a scope, a duration, a set of named recipients and a revocation.

What a custom build does: consent is a structured record that gates data flow at the point of sharing, not a scanned PDF in a folder. A referral to a partner organisation carries only the fields that consent covers. Revocation takes effect immediately and is logged. Behavioural health and substance use elements are segmented and released only under a consent that explicitly names them. This is also the design that lets you share with police co-response or a crisis team without merging the records, which is exactly the boundary that gets programs into trouble when it is handled informally.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release covering enrolment, care plans with measurable goals, structured visit capture on a tablet including offline use, consent, and one contract's outcome measure runs $50,000 to $110,000 in 10 to 14 weeks. A full platform adding ADT ingestion, multi-contract measure definitions, partner referral workflow, scheduling and route planning for the visit teams, and a funder-facing reporting portal runs $130,000 to $300,000 across 5 to 10 months.

What drives cost up: the number of external data feeds, since ADT from one hospital is straightforward and a health information exchange connection with identity matching is a project of its own. The number of distinct funders, because each contract's measure logic and reporting format is real work. Deep integration with the ePCR you already run, if you want the same patient visible in both. And identity matching, which is the unglamorous item that decides whether your outcome numbers are believable at all.

What keeps it down: one contract's measures first, ADT from your primary funding hospital only, and referrals to partners by structured email rather than integration until a partner earns the integration.

Build versus buy, and when buying is the right call

Buy if you are in year one with a pilot, a handful of paramedics and one funder. Julota exists for exactly this and it will get you further than a custom build at that size, because what you need in year one is to find out whether the model works, not to encode a model you have not tested. If your ePCR vendor's community paramedicine module covers your single contract's reporting, use it and revisit in eighteen months.

Build when two or more of these are true. You have three or more funding contracts with different outcome definitions. Your program has passed roughly 150 active enrolments and the visit schedule is being managed in a shared calendar. You have secured or can secure an ADT feed, which changes what the software is capable of proving. Your program spans agencies, meaning EMS plus behavioural health plus housing, and consent handling has become a genuine risk. Or your renewal is at stake and the reason is that you cannot produce the number, not that the number is bad.

Our position: the funding for mobile integrated health has been unstable since the federal ET3 model ended, and programs now live or die on their ability to make a local case to a local funder. That case is a data product. Treat it as the deliverable and the visits will take care of themselves.

How to choose a developer for community paramedicine software

Ask them to define one of your contract measures back to you after reading the contract. If they cannot state the population, the attribution, the window and the exclusions without help, they will build you a visit counter and call it outcome reporting.

Ask specifically what they have done with ADT and HL7. This is the integration that determines whether the platform is worth building, and it is not something to learn on your project. A team that has moved real ADT will immediately raise patient identity matching, which is the correct instinct.

Ask how they model consent. The answer should involve scope, named recipients, duration, revocation and segmentation of behavioural health data. If the answer is a signature capture screen, keep looking.

Ask who owns the code and put it in the contract before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit. Grant funded programs in particular should check this, because a contract that ends with a vendor holding your data is a program that cannot be handed to the next operator.