Healthcare Platform as a Service (PaaS): How It Works and How to Choose One

Key Takeaways

• With a healthcare platform-as-a-service, FHIR storage and patching become the vendor’s job, not items in your sprint backlog.
• The vendor’s BAA covers its slice of the stack, while the HIPAA risk analysis stays with you on every model.
• If the software is your product, PaaS usually beats SaaS because rivals can’t simply buy your app.
• Plan for at least one forced migration, as Azure API for FHIR customers learned in 2026.
• Selling into the NHS swaps the BAA for an Article 28 contract and adds assurance paperwork no vendor can file for you.
• Integration work, not hosting fees, is usually the highest one-time cost. Each EHR link needs custom mapping.

Healthcare platform as a service is one answer to a question every patient app, RPM service, or payer API project hits early. Build on it, or not? The alternatives are an off-the-shelf SaaS product or a custom build on raw compute. Plenty of healthcare organizations run working healthcare IT solutions on each of the three. What separates them is ownership. Pick wrong, and you find out during your first audit or your first hospital procurement review.

This guide answers two questions. What should you build on, and what will you still own? Along the way, we’ll compare PaaS types and map who carries the regulatory load on each side of the contract. Both US (HIPAA) and UK (NHS) rules are covered.

What Is Healthcare Platform as a Service?

Healthcare platform as a service (PaaS) is a cloud environment where the vendor runs servers, runtime, and patching. Your team builds clinical or consumer-facing software on top. The team also gets health-specific pieces like FHIR stores and audit logs, covered by a HIPAA business associate agreement.

Of the three cloud service models, PaaS sits awkwardly in the middle. The vendor owns more of the stack than with IaaS, less than with SaaS. Liability gets fuzzy right there.

Vendors love pitching a “medical-grade cloud” to healthcare providers. There’s no standard behind it, so a buyer can’t test it. What you can test is shorter and duller: four items, checkable in a contract or an admin console.

1. First comes the business associate agreement (BAA). HIPAA calls any vendor that touches protected health information (PHI) for you a business associate — your hosting provider included. Get the BAA template early, ideally before anyone books a demo, because PHI can’t go on the vendor’s servers until it’s signed.
2. Then check which services that BAA actually covers. It’s never the full catalog. AWS keeps a HIPAA Eligible Services Reference, and Google maintains a Covered Products list. Microsoft publishes its own in-scope list. If a new AI service isn’t on the list, it doesn’t touch PHI.
3. Third, health data should arrive in formats the vendor already understands. Think managed FHIR APIs, HL7 v2 ingestion, DICOM. Some vendors take all three in one service, which spares your engineers from writing yet another HL7 parser.
4. Last, the boring controls: encryption at rest and in transit, exportable audit logs, and role-based access wired to your identity provider. On a real one, you configure these. You don’t build them.

And no, there’s no such thing as HIPAA certification. HHS doesn’t issue one, so a “HIPAA-certified” badge says more about a vendor’s marketing team than its controls.

British buyers swap the BAA for a UK GDPR Article 28 data processing agreement. Add London-region hosting and UK Core FHIR R4 to the checklist.

What a healthcare PaaS typically includes

Strip away the branding, and almost every healthcare PaaS ships the same seven building blocks under different product names. The integration layer usually takes the biggest share of EHR/EMR software development effort, so read that row closely.

Healthcare PaaS vs. SaaS vs. IaaS

Forget the textbook diagrams for a moment. For a product team, SaaS, PaaS, and IaaS differ on four questions: who holds PHI, who signs the BAA, who runs FHIR, and who patches. With SaaS, the vendor answers most of them. IaaS hands most of the work back to your team, down to the 2 a.m. OS patch after a new CVE drops. PaaS sits between them.

Who is responsible for what

British teams get the same answer. The DPIA and the yearly assurance toolkit belong to you whatever the hosting model, and so does clinical safety sign-off. A hospital trust usually checks your toolkit status before it asks which vendor hosts you.

So why does anyone still pick SaaS? Speed, mostly. Health plans and plenty of healthcare providers go the SaaS route because the vendor keeps the app running and handles scaling without anyone in-house noticing. The catch sits in the last row of the table. Off-the-shelf software looks identical at every competitor that bought it. Fine for claims processing. Much less fine if the software is the very product your company plans to sell to hospitals. IaaS buys even more freedom, at a price measured in months.

Types of Healthcare PaaS

Ask five vendors what healthcare PaaS means, and you’ll get five answers. Roughly, they fall into these groups.

Hyperscaler health-data services

Each of the big three hyperscalers sells a health layer, for example, AWS HealthLake, Azure Health Data Services, and Google’s equivalent. FHIR and DICOM are table stakes, and Google adds native HL7 v2. Running Microsoft Azure solutions already? Stay there. AWS, Microsoft, and Google all list London among supported regions, and the health service’s hosting guidance expects that choice to be documented.

Compliance-focused application platforms

Say you’re three engineers with a Docker image and a hospital pilot starting in six weeks. None of you wants to own HIPAA hardening. This type of PaaS takes that job: you push the container onto infrastructure that’s already locked down, and the BAA sits in the contract. The price? Less control over settings, and bills that grow quicker than on raw IaaS.

Healthcare integration platforms

Older interface engines and newer API-first platforms solve one problem: getting records out of an EHR in a shape your app can use. The newer ones normalize everything into FHIR or a common model. Lab and payer feeds too. EHR integration is where most project timelines slip, so we’d look at this category before the others.

Industry clouds and low-code health platforms

Not every product in this space is clinical. A care-coordination app mostly tracks people and who’s supposed to call them next. Industry clouds built on a CRM or low-code tool handle that well, since the record model comes prebuilt and you extend it. Push heavy HL7 traffic through one, though, and you’ll notice it was built for sales teams first.

Connected-device and IoMT platforms

Device makers come at this from the other end. Their first worry is getting thousands of sensors online and keeping telemetry flowing into RPM screens. IoMT platforms cover that, and some keep post-market records for regulators. What they can’t cover is the human side of IoT in healthcare: a patient who leaves the sensor in a drawer.

Benefits of Healthcare PaaS

None of the benefits below is free, so each comes with the condition that makes it true.

Faster time to market

Skipping infrastructure setup can pull a first release forward by weeks, sometimes months. The catch is fit. Products that need an unusual database or custom networking for a hospital VPN can burn the saved weeks fighting the vendor’s limits. Check the limits page before the architecture review.

Compliance controls built in — not compliance itself

Audit logging and encryption arrive preconfigured, which removes a big chunk of HIPAA Security Rule groundwork. Compliance still isn’t something you can buy. Auditors usually ask about your risk analysis and workforce training before they get to the hosting vendor’s encryption. Assurance in England works the same way.

Interoperability from day one

With FHIR on launch day, partners can integrate without a bespoke interface. That’s the theory. In practice, FHIR versions and profiles differ, so a US Core app won’t talk to a system built on England’s national profiles without mapping work. Most EHRs also expose only part of their data over FHIR.

Scalability without capacity planning

Nobody has to guess how many servers flu season needs. Managed runtimes are scalable by default, which suits telehealth and consumer apps with spiky traffic. Two limits, though. FHIR stores often come with request-per-second quotas, and a Monday-morning appointment rush can hit them. Autoscaling scales the invoice too.

Lower upfront cost, predictable operations

You don’t buy hardware or hire an ops team before the first user logs in. Monthly costs track usage, which finance teams usually like. Imaging is the exception. Every study copied to a second system triggers egress, on top of DICOM archives that never shrink. Model year three, not month one.

Engineering time spent on clinical logic, not plumbing

Every sprint your engineers don’t spend on key rotation or HL7 parsing goes to features clinicians see. That’s the real argument for PaaS. It only pays off if someone still understands the plumbing. When a FHIR subscription stops firing at 3 a.m., a vendor ticket queue is a poor substitute.

Healthcare PaaS Use Cases

Here’s how the split typically works across seven common products.

Telehealth and virtual care

A video visit needs far more than video. The vendor runs session infrastructure and identity, stores PHI, and scales when evening slots open up. EHR write-back is usually the hardest part of telemedicine app development, and it stays with your team. So does the virtual waiting room.

Remote patient monitoring and connected devices

Without a platform, someone has to write device provisioning and a telemetry pipeline that never drops a blood-pressure reading. IoMT services cover both. Your team defines the alert thresholds and who on the care team gets paged overnight. Those choices are clinical, so no vendor makes them for you.

Patient portals and engagement apps

Identity is the expensive part of a portal, and the vendor takes most of it on. SMART on FHIR handles who can open which record. Consent flags travel with the data. What remains is healthcare web development work, such as accessible pages and lab results written in plain language.

US: Payer interoperability APIs

Impacted payers must run four FHIR APIs by January 1, 2027: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization. That’s the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). Hyperscalers noticed. AWS HealthLake announced native support for them on May 29, 2026, which leaves your team with the claims-to-FHIR mapping.

UK: NHS-integrated apps

Building on NHS login, the Personal Demographics Service, or GP Connect? London-hosted FHIR R4 covers the infrastructure. National onboarding and assurance still decide whether your product goes live, and no vendor can write that evidence for you. UK Core FHIR R4 (DAPB4020) is the official standard, with no conformance date. Plan for it anyway.

Clinical research and real-world data

Names and birth dates must leave every record first. Several platforms ship a managed job for that. From there, bulk FHIR export can fill a healthcare data warehouse without anyone hand-coding the pipeline. Who belongs in a cohort remains an analyst’s call, as does validating any predictive analytics model on top.

Healthtech SaaS products built on PaaS

Selling software to many clinics means multi-tenancy, and multi-tenancy with PHI is unforgiving. A good PaaS lets you keep each tenant’s records in a separate FHIR store, with the same controls in every environment. Your SaaS development effort then goes into onboarding new customers fast.

HIPAA, NHS Requirements, and the Shared Responsibility Model

Regulators on both sides of the Atlantic tell healthcare organizations the same thing: the vendor’s paperwork never replaces yours.

US: HIPAA and the BAA

HHS is blunt about this. A cloud provider that creates, receives, maintains, or transmits ePHI for you is a business associate. Encryption doesn’t change that, and neither does the provider lacking the key. That means the BAA gets signed before a single health record lands on its servers, including test data copied from production.

Signing it covers less than people assume. The BAA applies only to services on the provider’s HIPAA-eligible list, which every major vendor publishes and updates. PHI that drifts into application logs or an unlisted AI service sits outside the agreement. Debug logs are a frequent leak.

Third-party reports help, within limits. A HITRUST certification, a SOC 2 Type II report, or ISO 27001 shows the vendor’s controls were tested. None of them makes your product compliant, and HHS issues no HIPAA certification of its own.

Then there’s your side of the line. It covers the risk analysis, access control, configuration, key management choices, audit log review, and breach response.

One more thing to watch. HHS OCR proposed a major Security Rule update in January 2025, and as of this writing, it still isn’t final. Current reporting doesn’t expect a final rule before mid-2027. We’d build toward it now anyway: MFA everywhere, encryption by default, and a real asset inventory.

UK: UK GDPR, the DSPT and DTAC

Under UK GDPR, a vendor that handles health records on your behalf is a processor, and those records count as special category data. You stay the controller. The Article 28 data processing agreement plays the role a BAA plays under HIPAA.

Processors aren’t off the hook either. In March 2025, the ICO fined Advanced Computer Software Group about £3.07m over a 2022 ransomware attack that disrupted NHS 111. It was the regulator’s first fine against a processor. Attackers got in through a customer account that had no MFA.

NHS guidance does allow health records in the public cloud. They can sit in Britain, the EEA, or a country with a British adequacy decision, provided a documented risk assessment backs the choice. Responsibility stays with the controller. We default to London regions, which tends to shorten procurement talks with trusts.

Any supplier with access to health service records completes the Data Security and Protection Toolkit (DSPT) every year. Version 9, for 2026-27, follows the NCSC Cyber Assessment Framework v4.0, and the deadline is June 30, 2027. Then comes the Digital Technology Assessment Criteria (DTAC). Digital health technologies sold into the NHS get assessed against it, and the refreshed form replaced the old one on April 6, 2026. It has roughly 25% fewer questions. Clinical safety hasn’t moved: DCB0129 still applies to the manufacturer, and DCB0160 to the organization deploying the product.

Two pieces of legislation are moving. The Cyber Security and Resilience Bill pulls medium and large managed service providers and data centers into NIS regulation. It cleared the Lords committee stage in September 2026, and Royal Assent is expected late in the year. UK GDPR is shifting too. The Data (Use and Access) Act 2025 amends it in stages.

US vs UK at a glance

• The provider: physical security, the network, the managed runtime and its patching, uptime of FHIR and imaging services, and the BAA or DPA covering eligible services.
• You: the risk analysis or DPIA, access control and configuration, encryption key choices, audit log review, breach response, toolkit submissions, and technology assessment evidence.

Most of the healthcare cybersecurity challenges that end up in breach reports start on the second list.

Risks and Limitations of Healthcare PaaS

Here’s what tends to go wrong, and what we’d do about it.

Vendor lock-in

Nobody plans lock-in. It arrives one proprietary API call at a time, until two years later the exit estimate covers most of your integration layer.

How to reduce it: Whatever the vendor stores underneath, keep FHIR as the shape of your own data and of every API your app exposes. Plain containers help too. Leaving then means rewriting adapters, not clinical logic.

Service retirements and forced migrations

Managed services get retired, and you migrate on the vendor’s timeline. Microsoft retired Azure API for FHIR on September 30, 2026. New deployments had been blocked since April 1, 2025, and customers were pointed to the FHIR service in Azure Health Data Services.

How to reduce it: Read the deprecation policy before you commit. Assume at least one forced move in the product’s lifetime. A same-vendor move still carries the usual cloud migration risks: FHIR resources that don’t map one-to-one, or a cutover weekend that runs long.

Cost creep at scale

Per-request and per-gigabyte pricing looks cheap at pilot volumes and stops looking cheap around the time a second hospital signs.

How to reduce it: Model the bill at ten times today’s usage before you sign. Then tag resources by product, so the monthly invoice shows which feature is burning money.

Less control over runtime and configuration

You get the runtime versions and tuning knobs the vendor chooses to expose. Need a newer OS image for one library? You wait.

How to reduce it: Before signing, run the ugliest workload you have on a trial account. Usually that’s imaging. Most cloud migration best practices begin with that kind of test. Whatever refuses to fit can run on a plain container service alongside the main stack, which keeps your exit options open.

Data residency and multi-region requirements

Residency rules differ by market, and a vendor’s default region isn’t always the one you need. In the US, no federal rule says where health data must live, so the contract has to. Britain is stricter on paper. Hosting in Britain or the EEA is fine under health service guidance, and so are countries with a British adequacy decision. Anything beyond that needs a written jurisdiction risk decision. So does a provider headquartered outside the EEA, even if its servers sit in London.

How to reduce it: Put the region in writing. For work with English trusts, default to London regions and check that backups and logs stay there too.

What Drives Healthcare PaaS Costs

We won’t quote a price here, because two products on the same stack can land far apart on the invoice. The drivers below explain why.

Cost driver	What affects it
Data volume and FHIR API calls	Imaging archives and long record histories on the storage side. On the API side, apps that poll FHIR endpoints instead of subscribing to changes.
Number of environments	Each environment, from dev to production, carries its own baseline cost. Synthetic test data keeps non-production environments cheaper to secure.
Compliance add-ons	Dedicated tenancy, customer-managed encryption keys, and longer log retention are often priced separately from the base service.
Integration build	Usually the largest one-time cost. Every EHR, lab, or payer connection needs mapping, testing, and sign-off from the partner.
DevOps and monitoring	Pipelines, alerting, and on-call cover still need people, even when the platform patches itself.
Migration effort	Moving data and interfaces off a legacy system, or off a retired service, is billed as engineering time rather than platform fees.

British projects add their own line items. Toolkit and assessment evidence takes real effort to assemble, and many public buyers also expect Cyber Essentials Plus certification. Regional price lists differ too, so price the London region rather than the default one.

Procurement shapes the budget too. Selling to a trust? Chances are the purchase runs through G-Cloud 15, and since August 6, 2026, its Lot 1a has covered IaaS and PaaS. The listing itself is a small project, with its own paperwork.

Actual costs depend on scope, so treat this list as a checklist for estimates, not a price guide. A discovery sprint is where we’d turn it into numbers.

How Intellectsoft Builds on Healthcare PaaS

We start with the platform decision, before anyone writes a line of product code. A senior architect leads that sprint. It maps what the PaaS can carry and what leaving it would take if the vendor changed course.

We treat FHIR as the contract between your services and whatever sits underneath them. If the vendor changes, the contract doesn’t.

Compliance goes into the architecture diagram, not into a remediation backlog six months after launch. PHI boundaries and audit logging get designed alongside the first user story, while changing them is still cheap. Through our DevOps services, those controls end up in the pipeline, so every environment builds the same way, and PHI stays out of test.

If you’re selling to English trusts, we plan toolkit and assessment evidence into the roadmap from day one.

In 18+ years, our list has grown to include 35 Fortune 1000 clients. For a British dental startup, we built a white-label client management platform on AWS in nine months. Role-based admin access and fully automated CI/CD across multiple environments were built in. Ten clinics use it now. Admin time per patient dropped by about 20%, and clinic revenue rose by an average of 8%. XMed went the other way: a consumer iOS app. Its AI advisor asks follow-up questions about symptoms, while users and medical experts weigh in through a built-in social network.

Planning a clinical or consumer-facing product on a healthcare PaaS? Book a consultation, and a senior architect from our healthcare software development services team will review platform fit before anyone talks budget.

FAQ

What is healthcare platform as a service?

Healthcare platform as a service (PaaS) is a managed cloud setup where the vendor runs servers and health APIs while you write the clinical app. A FHIR store, for instance, is ready on day one. The legal piece matters as much as the tech. US vendors sign a BAA, while British deals run on an Article 28 contract.

Is healthcare platform-as-a-service HIPAA compliant?

Not by itself. A healthcare platform-as-a-service vendor can sign a BAA and tell you which of its services are HIPAA-eligible. That’s where its part ends. Whether your product is compliant depends on decisions your team makes, starting with the risk analysis. And ignore anything labeled “HIPAA-certified.” HHS doesn’t hand out that badge.

What does a healthcare PaaS need to meet to sell to the NHS?

The NHS mostly checks you, not the vendor: expect the annual assurance toolkit, a DTAC assessment, and DCB0129 clinical safety files. From the PaaS itself, buyers usually want London hosting and a signed Article 28 contract. Cyber Essentials Plus comes up often. So do England’s national FHIR profiles, once you exchange records with national systems.

What is the difference between healthcare PaaS and SaaS?

A SaaS product is finished software you configure, whereas a healthcare platform-as-a-service hands you components to build your own. Health plans lean toward SaaS when speed matters most. Suppose the software is what you sell, though; buying the same app as your competitors defeats the point. Regulatory ownership barely changes between the two.

What are examples of healthcare PaaS?

For example, AWS HealthLake, Azure Health Data Services, and Google’s FHIR and DICOM stores are the best-known ones. That’s the hyperscaler tier. Smaller vendors cover narrower jobs, such as hosting containers with HIPAA controls preset or onboarding connected medical devices. Names and features change fast, so check current docs before you shortlist.

Does a healthcare PaaS support FHIR and HL7?

FHIR, yes, almost always in R4. HL7 v2 is patchier. Google’s health API stores v2 messages as they arrive, but most other vendors rely on an interface engine to convert them to FHIR first. Building for the NHS? Confirm the vendor can validate against England’s national FHIR profiles.

How much does a healthcare PaaS cost?

No list price exists, since healthcare PaaS costs follow your scope. Storage and API volume drive the monthly bill. Upfront, most of the money goes into integration work, and products for English trusts also carry assurance effort. Add-ons like customer-managed keys sit somewhere in between. We’d scope it in a short discovery phase before quoting anything.