Software Development
Security Services
Cloud Services
AI Services
Other Services
TechMagic Academy
Building a Patient Portal With Medplum TypeScript SDK: Ship the Product, Not the Backend
Last updated:10 August 2026
Worldwide digital health revenue is projected to reach $181.25 billion in 2026, a 15.9% rise on the year before, according to Statista. Much of that goes into patient-facing software, and a lot of it into infrastructure patients never see.
In fact, that infrastructure work no longer needs building from scratch. Medplum is an open-source, FHIR-native developer platform for healthcare products. When you build a patient portal with Medplum TypeScript SDK foundations, the hard parts are already done: secure login, the patient record, file storage, and the rules about who sees what.
Many teams rebuild those pieces anyway. The reasoning is sound, since engineers want a clean model of their own... but it costs two to three months of engineering time and a later launch, for work no patient or buyer will ever notice.
This guide covers what the Medplum TypeScript SDK gives you, how long building a portal really takes, and an honest view of where it fits best.
Two of our engineers weigh in throughout. Thiago Roberto, Full-Stack Software Engineer at TechMagic, works across our Medplum builds. Roman Danylov, Senior Full-Stack Developer in our Center of Excellence, leads a telehealth platform running on Medplum in production.
Key Takeaways
- Medplum gives you a compliant, HIPAA-ready backend. Login, the patient record, storage and access rules ship with the platform, so rebuilding them spends runway on work no patient or buyer ever sees.
- With Medplum, you hire differently, not just fewer people. Two strong full-stack TypeScript engineers and a designer cover what would otherwise take an infrastructure engineer, two backend engineers and a frontend engineer, saving one to two engineer-quarters.
- The costliest mistake is copying the clinical record into your own model. Keeping your own database for your own business data is correct and expected.
- With Medplum, expect a pilot-ready portal in about one quarter, for a defined scope.
- Medplum fits products where workflow and experience are the differentiator. It is not the best core for claims and revenue cycle work, or when the product itself is two-way integration with legacy systems.
What Is the Medplum TypeScript SDK, in Plain Terms?
The Medplum TypeScript SDK is the toolkit that hands your team a ready-made, compliant healthcare backend: secure login, the patient data foundation, storage, and access rules. Your engineers build the portal itself instead of that plumbing.
Medplum is an open-source FHIR native developer platform. FHIR (Fast Healthcare Interoperability Resources) is the modern standard healthcare systems use to exchange patient data, so other systems can connect to you later without a custom project each time.
Our introduction to Medplum covers the platform in more detail.
What your engineers inherit with Medplum
A few technical details on what Medplum provides out of the box. If that is not your area, skip ahead to the business value below.
- Data. FHIR R4 resources with search, history and versioning on every resource type, behind a REST API and GraphQL APIs. Search criteria come predefined, the layer supports typed nested queries, pulling a patient plus other resources in one call, with FHIRPath style array filtering and reverse reference traversal.
- Access. FHIR authentication on OAuth 2.0, SMART on FHIR, external identity providers and MFA. Declarative access policies scope permissions per resource type and field, and every SDK method goes through the same authorization.
- Logic and events. TypeScript based serverless bots, which Medplum calls AWS Lambda style, run from HTTP triggers, a scheduled cron job or resource changes, and these TypeScript serverless functions share a language with your frontend. FHIR subscriptions dispatch real time notifications when matching resources change, over rest hooks between servers and over WebSockets into a browser the patient already has open, and those events are logged.
- UI and tooling. A React component library ships with the SDK. Its React components cover standard screens, so a records page, an intake form or a clinical documentation view starts from working UI components in the browser. A developer console handles data fixes, and a separate provider portal application covers daily clinical work.
Find out more in Medplum's API reference and our FHIR app development with Medplum piece.
What Does Building a Patient Portal on Medplum Actually Give You?
You get a faster path to a launchable, HIPAA-ready portal, with your team on the product instead of the infrastructure. Login, the patient data foundation and storage arrive with the platform, so they are not yours to design, harden or defend in a security review.
That matters because patients now expect a portal. ASTP/ONC reports that 77% of individuals were offered access to an online medical record or patient portal in 2024, and 65% used one. What separates products now is the experience, which is exactly the part a platform cannot build for you.
So, here are the key benefits.
You launch sooner
With Medplum, you can show something real in month one: a working portal with real patient data in it, not a prototype. That changes the conversation with a design partner, a clinic running a pilot, or an investor, because you demonstrate behaviour rather than describe it.
"Medplum removes a whole slab of work from the front of the project: the data model, a versioned clinical API, identity and login, patient-scoped authorization, audit trails, file storage, and an admin console your clinical and ops staff can use on day one," Thiago says. "That's months of building for a small team, and it's work no patient will ever see. What's left is the product itself: screens, workflow, and the integrations specific to the business."
You keep the team on the product, not the plumbing
With Medplum, your engineers start on the product itself. The data layer, login and storage are already built, so their weeks go into the screens and workflows patients actually judge. The invisible work is no longer yours to do.
You get a HIPAA-ready foundation from day one
HIPAA (Health Insurance Portability and Accountability Act) work is where healthcare builds lose their first month. On Medplum's paid hosted plans you inherit that posture instead of assembling it. You get a Business Associate Agreement, the contract that lets a vendor handle patient data for you, and the safeguards underneath already run: encryption, access rules per patient, and audit logging as a first-class part of the data.
Medplum has also achieved SOC 2 Type II and is ONC certified, covering version 5 as of 31 December 2025. Check which plan carries what, since ONC certification starts on the Premium tier.
One caution, because buyers ask. There is no official HIPAA certificate: HHS does not recognise private HIPAA certifications, and compliance is a legal obligation covering your whole organization, from policies and training to contracts and safeguards. A vendor's certifications cover the vendor's part. They shorten the path, they do not end it.
You reduce the risk of an expensive rebuild later
Standards keep your options open. Because patient data sits in a common format, you can switch vendors, bring the work in-house or hand the system to another team later, while a custom backend gets more expensive to move away from every quarter you add to it.
The same holds in a sales cycle. When an enterprise buyer's procurement team asks how you store and share patient data, you can point to a recognised standard instead of explaining a design only your own engineers understand.
What You Don't Have to Build, and What That Saves You
The most expensive parts of a healthcare backend are already handled, so the savings show up as time and as reduced risk. Most Medplum TypeScript SDK and patient portal guides list capabilities. This table translates them into what you stop paying for.
The validation row is the one buyers never scope. Medical profiles vary across the US, and in Roman's experience from clinic to clinic. Every variation is a rule somebody writes, tests and keeps current. On our own build that alone removed a workstream nobody had budgeted for.
Where Should Your Team's Time Actually Go?
It should go into the part patients and buyers judge you on: the experience, the workflow, and whether people come back. That work is still yours, and bigger than it looks.
It covers the clinical workflow, which is the whole product. Your business rules: eligibility, pricing, care plans, coaching. The logic inside each partner integration. Consent flows and the wording around them. Notifications, testing and monitoring. Even the revisit consent button before a follow-up booking is your decision, not a platform setting.
In Deloitte's 2026 Global health care outlook, 49% of 180 health system executives expect benefits from tech-enabled patient engagement and remote monitoring. Nobody in that group is paying for your data layer.
Thiago is blunt about it:
"You can write your own FHIR server, or you can find out whether patients use your product. In the first six months, you don't get to do both."
The most expensive detour Thiago sees is a second copy of the patient record behind a team's own internal API. In practice every new field then changes in four places, and the platform's search, history and permissions stop applying to the copy. Thiago puts that at six to ten weeks of delay. Two other rebuilds appear almost as often: login and permissions, and an admin panel Medplum already ships.
Keeping your own database for your own business data is correct. Copying the clinical record into it is not.
How Fast Can You Get a Patient Portal Live?
Weeks of product work, against the two extra quarters a from-scratch backend puts in front of you. We will be specific, because the numbers circulating online are loose. What repeats for us is about one quarter to a pilot-ready portal, for a defined scope and team.
The scope is patient onboarding, questionnaire-based intake, a records view, secure messaging with a care team, a staff-facing view, and one or two external integrations. The team is two or three engineers using AI tooling, plus a product owner who decides inside the week.
Five things break that number, each its own timeline: two-way integration with a legacy on-premise EHR (electronic health record), anything touching claims or eligibility, provider scheduling with licensing rules, a native mobile app, and a certification path.
So the honest version is "a pilot-ready patient portal in about one quarter, for this scope, with this team." Treat any flat "12 weeks" claim, including one about us, as a scope question you have not asked yet.
Pilot-ready is also not production-ready. Pilot-ready is what you show a design partner or an investor. Production-ready means real patients, real clinicians and someone on call. On our own build the first took a few months, the second about a year.
It changes who you hire, too
Using Medplum TypeScript SDK for patient portal builds changes who you hire. Instead of one infrastructure engineer, two backend engineers and a frontend engineer, you staff two strong full-stack TypeScript engineers and a product designer, plus part-time clinical and compliance input. Thiago's estimate: one to two engineer-quarters saved early on.
The bigger win is subtler. You delete the hire that is hardest to make: someone who has done healthcare data modelling and HIPAA-grade infrastructure before, and who is expensive, slow to find and often unavailable to a pre-seed team.
Two caveats, or the claim does not hold up. Someone still has to learn how clinical data is modelled in FHIR: a real learning cost, just not a headcount cost. If you run self hosted, add back roughly half a DevOps person on an ongoing basis.
Is Medplum the Right Foundation for Your Portal?
Good fit if you want to launch fast, stay standards-based, and keep your options open later. Reconsider if your portal needs something a platform genuinely cannot support. Our guide to Medplum for founders makes the full build-versus-buy case, including what it costs.
"Right fit is a patient or clinician-facing product where the differentiator is workflow and experience, with a TypeScript team, and clinical data you'll need to query and share over years," Thiago says. "That's most of virtual care, remote monitoring and care navigation. Not a right fit: if the product is really about claims, revenue cycle or payer billing, FHIR isn't where the value sits. And if the product is two-way integration with legacy on-premise systems, an integration-first platform is a better core."
How Does Working With a Team That Has Shipped Portals on Medplum Benefits You?
It removes the biggest risk on the project: learning the platform on your budget. Few outsourced teams have taken a Medplum portal to production, and those that have know where the platform stops being the answer. That is the real benefit you buy.
Our own example is a telehealth platform in one clinical specialty, now expanding into others. It started small, with a content management system for the patient-facing site while the rest ran on Medplum. Months in, the client asked for a full portal.
"Medplum significantly reduced the time required for integrating with a national clinical data network, where I had to store massive bundles of FHIR resources, ranging from several thousand to sometimes even tens of thousands of resources," Roman says. "Looking back, I think the biggest time savings come from developing the FHIR API server itself, especially when you know you'll have integrations and imports and exports. FHIR is basically the common protocol that's a must-have for modern EMRs."
Because both sides spoke the same standard, the team could sync a patient's medical history across all states. With custom backends it would have been a mapping project. We cover that pattern in detail in using Medplum as an integration layer.
Medplum got the client to an investable MVP in a few months, and the team has since reached SOC 2 on its own infrastructure. Physicians have asked to switch for the workflow features, including a read-only AI assistant. Roman is equally clear it cannot yet replace a whole clinic's systems.
Then the honest part, and the reason to hire people who have done it before:
"Medplum started out as a full-fledged framework, meaning it covered 90% of our needs, but ended up covering only about 30% in the end."
Read that as specialisation, not decline. Medplum's job there today is integration and treatment management, keeping the resources the team creates ready to share under HL7 standards, and it still saves them writing validation code. The 90% is why you start here. The 30% is what you design for.
See one of our case studies for the delivery detail on another Medplum build.
Summary
Building a patient portal on Medplum is the faster, lower-risk path. The compliant foundation is already there, so your team spends its time on the product instead.
For a CTO, that changes where the hard work sits. The data layer is settled, so design starts at the patient record. What takes real effort is the integration backbone: making sure the same event arriving twice, from two partners or from local clinical systems, still ends up correct. Companies shipping clinical software should expect Medplum to settle into exactly that role as the product grows.
For a founder, it means a working product to show in month one and a realistic date for production, rather than a prototype and a guess.
talk to us to get straight answers to all questions
FAQ
A patient-facing app built on Medplum, an open-source healthcare developer platform supplying the clinical data layer, login, storage and access rules. That foundation is already compliant and standards-based, so engineering time goes to the patient experience.
About one quarter to pilot-ready, for a defined scope: onboarding, questionnaire intake, a records view, secure messaging, a staff view, and one or two integrations. That assumes two or three engineers and a decision-maker available inside the week. Production-ready took about a year on one TechMagic build.
Medplum handles the patient data model and API, login and permissions, audit logging, document storage, server-side logic and an admin console. You build the patient experience, the clinical workflow, your business rules and the logic inside partner integrations. Your own database for your own data is fine; copying the clinical record is not.
It starts from a HIPAA-ready foundation. Medplum has SOC 2 Type II, offers a Business Associate Agreement on its paid plans, and is ONC certified from the Premium tier upward. There is no official HIPAA certificate, and compliance is a legal obligation covering your whole organization, so a vendor's certifications shorten the path without ending it.
Start with Medplum Cloud unless you have a concrete reason not to. The hosted service gives you a Business Associate Agreement and an inherited compliance posture with no infrastructure headcount. Self hosted is supported, since most of the platform is open source and ships as one self hostable monorepo. It suits data residency, VPC isolation or unit economics at scale, though you then operate that cluster yourself.
Ask which parts of the patient record they modelled, which outside system they had to integrate, and where the platform stopped being enough. Teams that have only prototyped cannot answer the third. TechMagic has taken a Medplum portal to production on a telehealth platform, syncing patient history across all states.
