Building a consumer platform without losing the hospital
The pitch for the consumer platform arrives with a screenshot. One app. The patient logs in once and sees every appointment, every report, every prescription, every bill, across every hospital, clinic, lab and pharmacy in the group. A single relationship. Loyalty. Lifetime value. The deck usually has a slide with the word ecosystem on it and another with a valuation multiple borrowed from a consumer healthtech company that has since run out of money.
I have built the case for this platform, run parts of it, and defended it in budget reviews. The promise is real and the difficulty is nowhere near where the deck thinks it is. It is not the app. Any competent team can build the app. The difficulty is that a hospital group is not one company. It is a holding structure over several entities — hospitals, a diagnostics arm, a pharmacy company, a joint venture or two, sometimes a separate digital subsidiary created precisely to house this platform — and the patient whose relationship you want to unify is, legally and operationally, a different patient in each of them.
Get that wrong and you build a startup the hospital does not need, sitting on top of data it is not sure it may use, charging a commercial model the units resent, and measured on downloads. This is about how to avoid that.
What the platform is actually promising
Strip out the ecosystem language and the platform promises three things. That a patient can transact with any part of the group — book, pay, receive a report, order a refill — without re-entering their identity. That the group can see the patient across those transactions and act on what it sees: a follow-up due, an abnormal result, a chronic condition unmanaged. And that the relationship, over time, keeps the patient in the group rather than losing them to an aggregator or a nearer competitor.
Each of those depends on a single patient identity across entities, a consented right to combine the data, and a commercial arrangement in which the units benefit from the platform’s success rather than being taxed by it. None of those is a technology problem. All of them are governance problems, and the executive committee will need to resolve them before a line of code is worth writing.
Step 1: Whose patient is it
In a multi-entity group the patient who had surgery at the flagship, a scan at the diagnostics company and a prescription filled by the pharmacy subsidiary has three records, three consents and three data controllers. Each entity collected the data for its own purpose. The platform proposes to combine them for a purpose none of the entities stated at the time.
Under the data-protection regime now in force, that is not a detail. Consent has to be specific and purpose-bound, the data fiduciary has to be identifiable, and sharing across group companies is a transfer between separate legal persons, not an internal matter. The national health-data framework layers its own requirements on top for clinical records. A platform that quietly aggregates across entities on the theory that it is all the group anyway is carrying a liability it has not priced.
The workable structures are few. One entity — often the digital subsidiary — becomes the platform operator and obtains a fresh, explicit consent from the patient to combine records across named group entities for named purposes. Or each entity retains its data and the platform holds only an identity map and a consented index, pulling records on demand with the patient’s authorisation. The first is simpler for the product and harder for legal. The second is the reverse. Decide with counsel, before the architecture is drawn, and be prepared for the answer to constrain the product.
Step 2: Data rights across group companies
Once the consent structure is settled, the harder question is who may do what with the combined view. The pharmacy company would like to know which patients are on long-term medication. The diagnostics arm would like to know who is due for a repeat test. Marketing would like all of it. The clinician who ordered the test believes the result is a clinical record and not a marketing signal, and is right.
Write the data-use rules before the platform has any data. Clinical data is used for care and for care reminders that the patient has agreed to. Transactional data can inform service but not cross-sell without separate consent. No entity gets bulk access to another entity’s records; it gets what the patient has authorised for a specific interaction. These rules are unpopular with every entity head who was promised growth from the platform. They are also the only thing that lets the medical directors support it, and without the medical directors it does not work.
Step 3: What the platform owns
The platform should own the patient identity, the consent registry, the digital front door — booking, payments, reports, reminders — and the consumer relationship layer: the app, the portal, the messaging, the contact centre integration. It should own the data model for the unified view and the rules for who may use it. It should own the engagement metrics and the retention numbers.
It should not own the clinical record — that stays with the entity that created it. It should not own pricing, which belongs to the units and the tariff committee. It should not own the doctor. The relationship between a consultant and their patient is the hospital’s, and a platform that tries to insert itself between them by, for instance, routing a patient’s follow-up to whichever consultant has capacity will lose the clinicians in a month.
The test I use is this: if the platform were switched off tomorrow, what would stop working? The answer should be the patient’s ability to transact with the group as a whole — and nothing clinical. If the answer includes anything a doctor depends on to treat a patient, the platform has taken on something it should have left in the HIS.
Step 4: What the units keep
The units keep the clinical record, the clinical workflow, the consultant relationship, their own front desk and their own tariff. They keep the right to say no to a campaign that targets their patients. They keep their direct channels — a unit’s own phone line, its walk-in, its referral coordinators — because a platform that tries to force every interaction through itself will be routed around by the people on the ground who need to get a patient a bed today.
The friction point is the unit’s own digital front door. Every unit has an appointment page, some have an app, several have a messaging number that the marketing manager runs from a personal handset. The platform proposes to replace all of them. It should — but by being better, and by handing the unit’s leads back to the unit with full attribution, not by decree from the centre. I have watched a platform mandated from head office get quietly bypassed by three units within a quarter. The mandate was not the problem. The attribution was: the units could not see their own patients in the numbers, so they stopped believing the numbers.
Step 5: The commercial model between platform and hospital
This is where most platforms are quietly killed. If the platform is a cost centre funded by the group, the units treat it as free and value it accordingly. If it charges a per-transaction fee to the units, the units see a tax on patients they believe were theirs anyway and start to route around it. If it takes a share of revenue on patients it brought, the argument about who brought whom consumes every quarterly review.
The model I would defend is a funded platform with a cost allocation to entities based on usage, transparent enough that a unit head can see what they are paying and what they are getting — appointments booked, reports delivered, no-shows reduced, follow-ups retained. Add a modest incentive on measurable retention: patients who transacted with two or more entities in a year, follow-ups that would otherwise have lapsed. Do not try to charge a platform take-rate inside your own group. You are not a marketplace and the units are not sellers.
If there is a separate digital subsidiary with its own investors or an intended exit, the commercial model becomes an arm’s-length contract, and the whole thing gets harder. Which brings me to the trap.
Step 6: The startup the hospital does not need
At some point someone will suggest that the platform should be a company. It will have its own brand, its own valuation, its own product roadmap and, eventually, its own customers outside the group. The hospitals become anchor clients. The pitch is that this unlocks value and attracts talent the group cannot otherwise hire. The reality, in most of the cases I have seen, is a business that is neither a good platform for the group nor a viable startup for anyone else.
The reasons are structural. A platform built to serve the group has integration into the group’s HIS, contact centre and CRM as its core asset, and none of that transfers to another customer. A platform built to be sold to other hospitals needs to be generic, and a generic platform serves the group worse than the specific one it replaced. The team, meanwhile, is measured on downloads, monthly active users and a consumer roadmap, while the units need reports delivered and appointments kept. The two sets of incentives pull apart within a year, and the group ends up funding a product team that is building for a customer it does not have.
If the group wants a healthtech venture, build one deliberately, capitalise it as such and give it the P&L conversation any new vertical deserves. Do not let the patient platform become one by drift. The platform’s job is to make the group’s own patient relationship work. That is a large enough job.
What tells you it is working
- Share of the group’s active patients with a single verified identity across entities, and with a valid combined-data consent.
- Share of appointments, payments and report deliveries transacted through the platform rather than the unit front desk, by unit.
- Follow-up adherence and no-show rates for platform patients against the rest.
- Patients transacting with two or more group entities in a year, and the change in that number.
- Unit-head satisfaction — measured bluntly, in the quarterly review, by asking whether they would fund it from their own budget.
Downloads are not on the list. Monthly active users are not on the list. A patient who opens the app twice a year to collect a report and book a follow-up is a success. A patient who opens it daily is usually unwell.
If you’re starting this next quarter
- Map the entities, the data each holds, and the consent each collected. Take it to counsel and get a written view on the combining structure before any product work.
- Agree the data-use rules with the medical directors and entity heads, and get them signed, not nodded at.
- Define what the platform owns and what the units keep in a one-page charter approved by the executive committee.
- Settle the cost-allocation model with the CFO and show it to the unit heads before launch.
- Build identity and consent first, then booking and reports. Engagement features come last, if at all.
- Kill the startup conversation early, or have it properly as a vertical case. Do not let it happen by drift.
The hospital does not need a startup. It needs its own patients to be able to find it twice.
Questions people ask
Strip out the ecosystem language and it promises three things. A patient can transact with any part of the group — book, pay, receive a report, order a refill — without re-entering their identity. The group can see the patient across those transactions and act on a follow-up due or an abnormal result. And the relationship keeps the patient in the group rather than losing them to an aggregator. Each depends on a single identity, a consented right to combine data, and units that benefit rather than being taxed.
Because a hospital group is not one company. It is a holding structure over several legal entities — hospitals, a diagnostics arm, a pharmacy company, joint ventures, sometimes a digital subsidiary — and the patient you want to unify is legally a different patient in each. Three records, three consents, three data controllers, each collected for its own purpose. Any competent team can build the app. The difficulty is governance the executive committee must resolve before a line of code is worth writing.
Consent has to be specific and purpose-bound, the data fiduciary identifiable, and sharing across group companies is a transfer between separate legal persons, not an internal matter. The national health-data framework adds requirements for clinical records. A platform that quietly aggregates on the theory that it is all the group anyway carries an unpriced liability. The workable structures: one entity becomes platform operator with fresh explicit consent to combine records across named entities for named purposes, or each entity keeps its data and the platform holds only an identity map and consented index.
The platform owns patient identity, the consent registry, the digital front door — booking, payments, reports, reminders — the app and messaging, the unified data model and the rules for using it, and the engagement and retention numbers. The units keep the clinical record, clinical workflow, consultant relationships, front desk, tariff and direct channels, plus the right to refuse a campaign aimed at their patients. My test: if the platform switched off tomorrow, only transacting with the group as a whole should stop. Nothing clinical.
Clinical data is used for care and for care reminders the patient agreed to. Transactional data can inform service but not cross-sell without separate consent. No entity gets bulk access to another entity’s records; it gets what the patient authorised for a specific interaction. These rules are unpopular with every entity head who was promised growth from the platform. They are also the only thing that lets medical directors support it, and without the medical directors the platform does not work. Get them signed, not nodded at.
A funded platform with cost allocation to entities based on usage, transparent enough that a unit head can see what they pay and what they get — appointments booked, reports delivered, no-shows reduced, follow-ups retained — plus a modest incentive on measurable retention. Do not charge a take-rate inside your own group; you are not a marketplace and the units are not sellers. If it is a free cost centre the units value it accordingly. If it charges per transaction they route around it. If it takes revenue share, every quarterly review becomes an argument about who brought whom.
Attribution, usually. I watched a platform mandated from the centre get quietly bypassed by three units within a quarter. The mandate was not the problem. The units could not see their own patients in the platform’s numbers, so they stopped believing the numbers and went back to their own appointment page and the marketing manager’s messaging number. The platform should replace unit front doors by being better and by handing each unit’s leads back with full attribution, not by decree.
Almost always no, and never by drift. A platform built to serve the group has integration with the group’s HIS, contact centre and CRM as its core asset, and none of that transfers to another customer. A platform built to sell to other hospitals must be generic, and a generic platform serves the group worse. Meanwhile the team is measured on downloads and monthly active users while units need reports delivered. If the group wants a healthtech venture, build one deliberately with its own P&L case.
Share of active patients with a single verified identity and valid combined-data consent. Share of appointments, payments and report deliveries transacted through the platform rather than the unit desk, by unit. Follow-up adherence and no-show rates for platform patients versus the rest. Patients transacting with two or more group entities in a year. And unit-head satisfaction, measured bluntly by asking whether they would fund it from their own budget. Downloads and monthly active users are not on the list. A patient who opens the app daily is usually unwell.
Identity and consent first, then booking and reports. Engagement features last, if at all. Before any of that: map the entities, the data each holds and the consent each collected, and get a written view from counsel on the combining structure. Agree data-use rules with medical directors and entity heads. Define what the platform owns and what units keep in a one-page charter approved by the executive committee. Settle cost allocation with the CFO and show it to unit heads before launch.
Who the data fiduciary is and whether counsel has signed off on the combining structure, because an unpriced liability is a cost. How costs will be allocated to entities and whether unit heads have seen it. What the platform will be measured on — and if the answer is downloads, send it back. Whether anyone is quietly planning to make it a company with its own valuation, because that changes the capital conversation entirely. And what stops working if it is switched off, which reveals whether it has taken on things the HIS should hold.
A single hospital with one legal entity has none of the consent-combining problem, so the platform is mostly a good digital front door: booking, payments, reports, reminders, one identity. That is worth building and far cheaper. The governance work in this article — data-use rules across companies, cost allocation between entities, the startup trap — arrives when a hospital adds a diagnostics arm, a pharmacy company or a second entity. Build the identity and consent layer properly the first time so it survives that day.
Two things, and they are right on both. First, that a test result is a clinical record and not a marketing signal, so the pharmacy or diagnostics arm should not mine it for cross-sell without separate consent. Second, that a platform routing a patient’s follow-up to whichever consultant has capacity inserts itself between doctor and patient; do that and you lose the clinicians in a month. The platform should not own the doctor, the clinical record or pricing.
