Patient360 — Vision map

01

What's actually built right now

Over the past several weeks I've put together a complete design package for Patient360 — a healthcare analytics platform — and published it at patientpulse360.com. This is not a pitch deck or a mockup. It's a working specification with enough technical depth that an engineer could start building from it tomorrow.

In plain terms, here's what exists:

• A market gap analysis Eight specific opportunities in healthcare analytics, each rated, each with a named buyer, a competitor table, and a tech stack. Three rated "highest priority": the mid-market hospital cliff, real-time operational analytics, and workforce/staffing analytics.
• A working architecture Epic Clarity/Cadence, ERP, HR, and payer 835 data flowing through a defined pipeline (MWAA, Kinesis, S3, RDS, Snowflake, dbt) into role-specific dashboards. This is specified to the column level — I know which Epic table feeds which chart.
• Five sample dashboards Built with realistic data, showing what a customer would actually see: revenue cycle, supply chain, physician performance, patient access, AI-generated executive narratives.
• A commercial model PMPM subscription pricing, tiered packaging, a land-and-expand GTM motion, and unit economics stress-tested against how Health Catalyst, Arcadia, and Epic Cogito are priced today.
• A security and compliance posture HIPAA BAA requirements, Snowflake Business Critical tier, the specific AWS controls a hospital security team will ask about.

02

What's real vs. what's assumed

Before we take this anywhere, I want to be precise about which parts of this are grounded in something verifiable, and which parts are well-reasoned assumptions that still need to be tested against an actual hospital.

This isn't a flaw in the work — every startup starts here. But it changes what we can honestly say to each other versus what we can say to an investor. I can defend the architecture with confidence. I cannot yet defend "hospitals will pay $14 PMPM for this" with anything more than logic.

03

The case for moving forward

Here's why I think this is worth your time and a real conversation, stated as plainly as I can:

• The gap is real even if the numbers need validation. Health Catalyst and Arcadia genuinely don't serve the 3–20 hospital regional system well — their pricing and implementation timelines exclude that segment. That's a structural market fact, not a guess.
• We have a real unfair advantage. Our backgrounds in healthcare data give us 12–18 months of head start that an outside founding team would have to spend learning Epic's data model, HL7 quirks, and hospital procurement culture.
• The work compounds. Every hour spent on the architecture, the dbt models, and the competitive analysis is reusable regardless of which opportunity we pick first. This isn't sunk cost into one narrow bet.
• The technology choice is de-risked. AWS + Snowflake + dbt is a proven, fundable stack. No investor will push back on the technical architecture — that part of the diligence is already done.

04

Who else is already in this market

Worth a clear-eyed look before we go further, because the honest answer shapes which opportunity we pick and how we'd have to position against it. The first version of this section only looked at the general healthcare-analytics players. That undersold how crowded parts of this market already are — there are at least four distinct competitive categories, and they map closely to the eight opportunities the site already lists. Each has a different "big vs. small" split.

05

Beyond Epic — the EHR landscape we should also consider

Everything built on the site so far — the data model, the architecture, the dashboards — is written specifically against Epic Clarity. That was a reasonable starting point given our background, but it understates both the size of the addressable market and a real concentration risk if Epic is the only platform we can integrate with.

The current US acute-care EHR market, by hospital share (KLAS Research, 2026):

In plain terms: Epic covers under half of US acute-care hospitals by count (though more by bed count, since it skews toward larger systems). Building only against Epic means we're deliberately ignoring the majority of hospitals by number — including most of the smaller, mid-market systems this memo's core thesis says are underserved in the first place.

07

A separate consideration — India as a market

Everything above is written with the US as the implicit market, because that's where the site content and the competitive analysis currently live. Worth flagging as its own, contained item: we are both from India, and that gives us an option most teams building this kind of platform don't have. This is noted here as a single open consideration — not folded into the core plan above, and not yet a recommendation either way.

08

How we'd actually sell this — open question, not a decision yet

The site's commercial pages describe a PMPM subscription model. That's one reasonable answer, but it was written as a default based on how Health Catalyst and Arcadia price themselves — not because we tested it against a buyer or weighed it against the alternatives deliberately. Worth treating as a genuinely open decision, because it changes almost everything downstream: who we hire, how we price the first deal, and how fast we can get to a "yes."

At the core, there are three different businesses hiding inside "Patient360," and they are not the same business:

Layered on top of that choice, four monetization models — these aren't mutually exclusive with the above, but each implies a different sales motion and a different first conversation:

What I'd suggest we explicitly ask during the validation conversations in Section 13: not "would you pay $X PMPM," but "how does your hospital typically budget for something like this — is it a capital project, an operating expense, a vendor contract renewal?" That answer alone will tell us more about which of the four models above fits than any amount of internal debate.

09

Open questions

These aren't rhetorical. I genuinely want pushback on these before we go further.

• Which sales model do we even test first? Section 8 lays out product vs. services vs. hybrid, and four ways to monetize whichever we choose — we haven't picked, and probably shouldn't until we've had a real budget conversation with a buyer.
• Which of the 8 opportunities do we actually start with? The site rates real-time operational analytics highest (9.5/10) and workforce analytics close behind (9.3/10) — but "highest opportunity score" isn't the same as "the one we have the warmest relationships to sell."
• Are we building a platform or selling one thing well? The site presents eight modules. Have we actually picked the one thing to start with, or are we still hedging across all eight?
• What's our actual unfair distribution advantage? Technical credibility is necessary but not sufficient — hospitals buy on trust and relationships. Whose network are we actually using for the first conversation?
• How much of this do we build before talking to a hospital, vs. how much do we validate first? There's a real risk in spending another two months perfecting dashboards before a single buyer conversation confirms anyone wants this at any price.
• Do we want outside capital at all right now, or should the first move be unpaid design partners? The honest path for a pre-revenue healthcare startup is often a design partner relationship before any pitch — raising money before that proof exists is harder and dilutes more.

10

Risks to discover (possible)

Framed deliberately as possible risks — things to actively go test, not settled conclusions.

• Sales cycle risk. Even "fast" hospital sales cycles run 4–8 months. We should plan runway assuming the first dollar of revenue is 6+ months after the first real conversation, not 6 weeks.
• Pricing-model risk. We've defaulted to a PMPM subscription model on the site without testing it against a real budget conversation. If hospitals actually buy this the way they buy a services engagement — not a SaaS subscription — our entire commercial page may need rework before it's customer-facing (see Section 8).
• The HR-to-Epic bridge problem. The workforce analytics opportunity depends on a field (epic_user_id) that is frequently missing or stale in real hospital HR systems. If we lead with that opportunity, our first implementation could stall on a data quality issue outside our control.
• We are pre-relationship with any actual buyer. Everything on the site is built from market logic and documentation, not from a conversation with someone who currently has this problem and a budget to solve it. That's the single biggest risk to everything else in this memo.
• Regulatory and security overhead is real, not theoretical. Snowflake Business Critical, signed BAAs, and SOC 2 readiness all cost real money and time before a contract can be signed — this isn't a "we'll figure it out later" line item.
• Founder bandwidth. Worth saying directly: do we both have the time this actually requires over the next several months, alongside whatever else is on our plates?

11

Options under consideration

I see three honest options. I have a preference, but I want your view before I say which.

My honest lean: Option A first, Option B second, Option C only after Option A gives us something concrete to say. But I want to hear if you see it differently.

12

What I'm asking from you today

Not a yes or no on the whole company. Eight specific things:

13

Path forward

Stated as a sequence of steps with clear exit criteria for each — not a calendar, since the right pace depends on what we both decide above and how quickly real conversations actually materialize.

13

If we move forward — what actually building this looks like

Everything before this section has been about whether and what to validate. This one is different in kind: it sketches what the build-out actually looks like after Section 12 gives us a real signal — registering the company, putting a team in place, locking the first product scope, and getting to a showable MVP. Treat the durations below as planning placeholders, not commitments — they compress significantly if Option A surfaces a design partner early, and stretch if it doesn't.

Who we'd need on the team to get through Stage 6, roughly in hiring order:

14

Revenue projection — illustrative, not a forecast

Stated as plainly as everything else in this memo: the numbers below are a planning scenario built from the pricing logic on the site's commercial pages, not a forecast we'd stand behind in front of an investor. They exist to stress-test whether the unit economics from Section 7 hold together across a few years, and to give us a shared mental model before we start putting real numbers in a spreadsheet together.

16

Proprietary notice & disclaimer