Updated October 2026 · Written and maintained by the Progression Agency strategy team
Patient portal software development is the design and engineering of the secure web and mobile front door patients use to message their care team, book visits, complete forms, see results and pay bills, connected to the record system behind it. We build custom patient portals for practices, clinics, hospitals, health plans and digital-health companies whose needs have outgrown the portal their EHR vendor supplies. Progression Agency is based in New York City and works with clients across the United States and worldwide.
On this page · 16 sections
- What is patient portal software development?
- Should you build a custom patient portal or use the one in your EHR?
- What does a patient portal provide? Patient portal features in detail
- What is patient portal integration, and which systems does it connect?
- Building a HIPAA compliant patient portal
- Patient portal security: are patient portals secure?
- Patient portal federal regulations beyond HIPAA
- Patient portal app development: is a patient portal an app?
- How do patient portals improve patient engagement?
- Designing for adoption, accessibility and plain language
- How much does patient portal development cost?
- How do you build a patient portal, and how long does it take?
- How AI assistants answer questions about patient portal developers
- How to choose a patient portal development company
- Patient portals for hospitals, clinics and small practices
- Related services for healthcare organizations
The short answerChoose a custom build when one sign-in must span several EHRs, when specialty intake or program flows do not fit the vendor portal, or when the portal is the product you sell. The work covers identity and sign-in, messaging, scheduling, forms, results, billing and proxy access, connected through HL7 FHIR and the EHR vendor’s APIs, with the HIPAA Security Rule’s technical safeguards designed in and hosting covered by business associate agreements. Success is measured by active patient accounts, messages answered on time, forms completed before arrival and calls the front desk no longer takes. Published US price bands for a focused portal run from $50,000 to $150,000 over three to five months; every build is quoted after a written scope. These are published US price bands (market figures, not a Progression rate card).
Rules were read in October 2026 in the eCFR text of 45 CFR Parts 164, 170 and 171, CMS’s Promoting Interoperability page, HHS’s tracking technologies bulletin, the SMART App Launch guide and W3C’s WCAG overview; nothing here is legal advice. Price bands are published US market figures, not a Progression rate card, and every build is quoted after a written scope.
What is patient portal software development?
It is building, integrating and running the patient-facing application that sits on top of a practice’s clinical and billing systems. The portal holds little data of its own; its value comes from showing the right part of the chart to the right person, safely, and taking work off the phones.
Patient portal development services we provide
Patient portal development services run from a first discovery sprint to years of releases after launch. Most engagements combine several of the lines below; a few organizations need only one, such as a new intake flow added to the portal they already run.
| Service | What it covers | When organizations usually ask for it |
|---|---|---|
| Discovery and data map | Workflows, data classes, systems, risks and a written scope | Before any budget is committed |
| New custom patient portal | Web app and optional mobile apps with sign-in, messaging, scheduling, forms, results and billing | The vendor portal cannot do what patients or staff need |
| Portal extension | One new module added beside an existing portal, such as intake or payments | The portal works but one flow still runs on paper or phone |
| EHR and system integration | FHIR, HL7 v2 and vendor APIs, practice management, payments, identity | Data is rekeyed between the portal and the chart |
| Portal rebuild or migration | Accounts, proxies, messages and documents moved to a new platform | The old portal is slow, unsupported or hard to use |
| Security testing and hardening | Code review, dependency scanning, penetration testing, logging review | Before launch, after major changes, or ahead of a customer review |
| Support and releases | Monitoring, security updates, interface changes, monthly releases | After launch, for the life of the product |
Custom patient portal or patient portal software off the shelf
Off-the-shelf patient portal software is sold by EHR vendors and specialist patient portal software companies, and for many single-site practices it is the right answer. A custom patient portal earns its cost when the organization needs something those products do not do, which the next section sets out.
Should you build a custom patient portal or use the one in your EHR?
Use the EHR’s portal when it already covers your patients’ main tasks and you run one EHR. Build when you need one experience across several systems, flows the vendor will not add, or a portal that is itself your product. Many organizations do both: the vendor portal stays, and a custom layer handles what it cannot.
| Situation | Usual route | Why |
|---|---|---|
| Single practice on one EHR, patients mostly message and view results | Use the EHR’s portal | Lowest cost and effort, maintained by the vendor |
| Several practices acquired onto different EHRs | Custom portal over all of them | Patients get one sign-in instead of three |
| Specialty intake, consent or program enrollment the vendor portal lacks | Extend with a custom module | Keeps the vendor portal and fixes the gap |
| Digital-health company whose service runs through a patient login | Custom build | The portal is the product and must carry your brand and logic |
| Health plan joining claims, benefits and care data | Custom build | Data comes from several sources, not one chart |
| Unsure which applies | A paid discovery sprint | Settles the question before a build budget is spent |
When is the vendor portal the better answer?
If your EHR’s portal already lets patients message, book, see results and pay, and your complaint is adoption rather than features, a rebuild rarely fixes it. Better onboarding at the front desk, clearer invitations and a cleaner sign-in usually do more, and we say so in the first call.
When a custom layer pays back
A custom layer pays back where staff time is being lost: intake still done on clipboards, refill and referral requests arriving by phone, payment plans set up by hand, or patients of two acquired practices calling to ask which portal to use. Those costs are measurable before the build starts, which makes the case easy to test.
What does a patient portal provide? Patient portal features in detail
A modern portal handles identity, communication, scheduling, forms, records, payments and shared access. Each feature looks simple on screen and carries real work behind it, usually an integration and a rule the practice must decide.
| Feature | What the patient sees | What it needs behind the screen |
|---|---|---|
| Registration and identity proofing | Sign-up with an invitation code or identity check | Matching to the right chart, rules for duplicate records |
| Multi-factor sign-in | A code or app prompt at sign-in, biometric on the phone | An identity provider, recovery flow and session rules |
| Secure messaging | Threads with the care team, attachments | Routing to the right inbox, response-time targets, copies to the chart |
| Scheduling and check-in | Open slots, booking, reminders, online check-in | Practice management availability, visit types, cancellation rules |
| Intake and consent forms | Forms completed at home before the visit | Form logic, e-signature, answers filed to the chart |
| Results and records | Lab results, visit summaries, medications, allergies | FHIR reads, release rules, plain-language context |
| Bills and payments | Statements, balance, payment plans | Billing system data and a payment processor that keeps card data off your servers |
| Proxy and shared access | An adult manages a parent’s or partner’s account | Consent records, role permissions, a way to revoke access |
| Notifications | Email, text or push alerts that something is waiting | Content that never includes health details in the alert itself |
Registration, identity proofing and sign-in
Most portal problems start at sign-up. We match each new account to the right chart, block duplicate accounts, offer a second factor and biometric sign-in on the phone, and design account recovery that a patient can finish without calling the front desk.
HIPAA compliant patient messaging
Messages are where patients judge the portal. Each thread is routed to the right care team inbox, stored inside the portal rather than in email, and filed to the chart where the practice wants it. Alerts tell the patient a message is waiting without repeating what it says.
HIPAA compliant patient forms and intake
HIPAA compliant patient forms replace the clipboard: history, medications, insurance, consents and screening questionnaires completed before arrival, with answers written back to the record. Online check-in builds on the same forms so the visit starts on time.
Results, records and plain-language context
Results appear on the schedule the practice sets, with a short explanation of what the test measures and who to contact. Visit summaries, medication lists and immunizations come from the record through FHIR, so the portal never holds a second copy that can drift.
Proxy access for caregivers
An adult caring for a parent or partner needs their own sign-in with the patient’s consent on file, limited to what the patient allows, and easy to revoke. We build proxy access for adult account holders, with the consent rules your compliance lead sets.
What is patient portal integration, and which systems does it connect?
Patient portal integration is the connection between the portal and every system that holds what patients want to see or do. It decides most of the cost and the risk of a build, so we map it before design starts.
| System | What flows through it | Typical method |
|---|---|---|
| EHR | Demographics, results, medications, allergies, visit summaries, documents | HL7 FHIR R4 APIs, SMART on FHIR app launch, vendor APIs |
| Practice management | Appointment types, availability, bookings, cancellations | Vendor scheduling API or HL7 v2 scheduling messages |
| Billing | Statements, balances, payment postings | Billing system API or a clearinghouse feed |
| Payment processor | Card and bank payments, saved methods, plans | Hosted payment fields so card data never touches the portal |
| Identity provider | Accounts, second factor, single sign-on | OAuth 2.0 and OpenID Connect |
| Labs and imaging | Results and reports not yet in the EHR | HL7 v2 results feeds or partner APIs |
| Messaging services | Email, text and push notifications | Vendors that sign a BAA, with no health details in the alert |
HL7 FHIR and SMART on FHIR
FHIR is the modern API standard most certified EHRs expose, and the SMART App Launch implementation guide defines how an app is launched and authorized to read FHIR data using OAuth 2.0. A portal built this way asks for a scoped token for one patient and reads only what that token allows.
Patient portal EHR integration with Epic, Oracle Health or athenahealth
We connect through each vendor’s FHIR endpoints and published APIs, subject to the vendor’s access programs, and fall back to HL7 v2 feeds or an integration engine where an API does not cover a need. Our EHR and EMR development page covers that integration work in depth.
Patient portal API design for your own product
Digital-health companies often need their own patient portal API so the web app, the mobile apps and partner systems share one set of rules. We design it with versioning, rate limits, scoped tokens and audit logging from the first release. Our API development team builds the same way for other industries.
Outgrowing the portal that came with your EHR?Tell us which EHR you run, what patients complain about and what your front desk still does by phone. A free proposal follows with a build-or-extend recommendation, the integration route and a written scope.
Building a HIPAA compliant patient portal
A HIPAA compliant patient portal is one built, hosted, contracted and operated so that it meets the Security Rule and handles protected health information only as the Privacy Rule allows. There is no official HIPAA certification for software; what a buyer can check is the evidence behind those safeguards.
The technical safeguards a portal must answer sit in 45 CFR 164.312. Some implementation specifications are required and others are addressable, which means the organization assesses whether each is reasonable and appropriate and documents its decision. For a patient portal the practical answer to most addressable items is to implement them.
| Standard in 164.312 | Implementation specification | Required or addressable | How the portal meets it |
|---|---|---|---|
| Access control | Unique user identification | Required | One account per person, never shared sign-ins for staff or patients |
| Access control | Emergency access procedure | Required | A documented, logged way for authorized staff to reach data in an outage |
| Access control | Automatic logoff | Addressable | Sessions end after a set idle period on web and mobile |
| Access control | Encryption and decryption | Addressable | Encryption of databases, files and backups |
| Audit controls | Record and examine activity | Standard | An audit log of every view, change and export of patient data |
| Integrity | Mechanism to authenticate ePHI | Addressable | Checks that records and documents have not been altered |
| Person or entity authentication | Verify identity before access | Standard | Multi-factor sign-in and identity proofing at registration |
| Transmission security | Integrity controls and encryption | Addressable | TLS on every connection between app, API and EHR |
Business associate agreements and HIPAA-eligible hosting
Every vendor that touches patient data on your behalf signs a BAA: the hosting provider, the messaging and email services, any support tool that can see records. We host on HIPAA-eligible services from AWS, Microsoft Azure or Google Cloud under the cloud provider’s BAA, in an account your organization owns, and sign a BAA ourselves when our work involves PHI.
A HIPAA compliant client portal for patients and their representatives
Patients are not the only users. A HIPAA compliant client portal for patients and their representatives has to handle proxies, personal representatives and staff, each with roles that show only what they need. Our guide to building HIPAA software covers the risk analysis, administrative safeguards and breach rules that sit around these technical controls.
Patient portal HIPAA compliance after launch
Compliance is a property of how the portal runs, not a badge it receives at go-live. Access reviews, log monitoring, security updates, a refreshed risk analysis when the portal changes and incident drills keep it true. Our support plans include those tasks on a calendar.
Patient portal security: are patient portals secure?
They can be, when security is designed in rather than added at the end. Patient portal security covers sign-in, sessions, data handling, third-party code and testing, and the weakest of those decides how secure the portal really is.
Tracking pixels and analytics on portal pages
HHS’s Office for Civil Rights says in its bulletin on online tracking technologies that tracking code on user-authenticated pages such as a patient portal generally has access to PHI, and that a tracking vendor receiving PHI needs a BAA. A June 20, 2024 court order vacated part of that guidance, and the part it vacated concerns unauthenticated public pages, not logged-in portal pages. We keep advertising pixels out of the portal and use analytics that stay inside your BAA.
Sessions, devices and shared computers
Patients sign in from family tablets and library computers. Short idle timeouts, a clear sign-out, no health details in browser titles or notifications, and remembered devices that patients can review and remove all reduce what a shared screen can leak.
Security testing before every major release
Before launch we run code review, dependency and container scanning and a penetration test, then fix and retest. Major releases get the same treatment. Results are written up in a form your security reviewers and your customers’ reviewers can read. Our website security services cover the marketing site that links to the portal.
Patient portal federal regulations beyond HIPAA
Three federal rule sets shape portals besides the Security Rule: the patient right of access, the 21st Century Cures Act information blocking rules, and ONC’s certification criteria for EHR APIs. We build inside these rules and leave legal interpretation to your counsel.
| Rule | What the text says | What it means for a portal |
|---|---|---|
| Right of access, 45 CFR 164.524 | A covered entity must act on an access request within 30 days, with one extension of up to 30 more; electronic copies in the form requested if readily producible | Downloadable records and documents in usable electronic formats reduce manual requests |
| Information blocking, 45 CFR 171.103 | A practice likely to interfere with access, exchange or use of electronic health information, unless required by law or covered by an exception | Release delays, blocked downloads and refusals to connect patient-chosen apps need a documented exception |
| Standardized API, 45 CFR 170.315(g)(10) | Certified health IT must offer an API for single and multiple patients, app registration and secure, authorized connections | Your certified EHR exposes FHIR endpoints a custom portal can use |
| Promoting Interoperability (CMS) | Programs that measure meaningful use of certified EHR technology by eligible hospitals and clinicians | Patient electronic access still matters to hospitals and clinicians reporting to CMS |
Patient portal 21st Century Cures Act and information blocking
Under 45 CFR 171.103, health IT developers of certified health IT and health information networks are held to a knows or should know standard, while health care providers are covered when they know a practice is unreasonable and likely to interfere. For a portal that means release rules, download options and app connections are written down and defensible.
The certified API your EHR already exposes
The ONC criterion in 45 CFR 170.315(g)(10) requires certified health IT to let apps register, connect securely and read single-patient and multi-patient data, with public API documentation and revocation of an app’s access within one hour of a patient’s request. That is why a custom portal can usually read from a certified EHR without bespoke interfaces.
Patient portal meaningful use, now Promoting Interoperability
Older portal requirements came from the Medicare and Medicaid EHR Incentive Programs. CMS’s Promoting Interoperability Programs succeeded them and still measure meaningful use of certified EHR technology. Hospitals and clinicians reporting to CMS should map any custom portal to the measures they report.
Right of access timing and the portal
Under 45 CFR 164.524, a covered entity has 30 days to act on a patient’s request for access, with one 30-day extension, and must provide an electronic copy in the form requested when it is readily producible. A portal that offers downloads of records and documents answers many of those requests in minutes.
Patient portal app development: is a patient portal an app?
It can be a web app, a mobile app or both, for iOS, Android and the web. Most organizations launch a responsive web portal first and add patient portal app development for iOS and Android once adoption shows patients want it.
| Option | Strengths | Trade-offs |
|---|---|---|
| Responsive web portal | No download, works on any device, one codebase | No biometric sign-in or push alerts on most browsers |
| Cross-platform mobile apps | One codebase for iOS and Android, biometrics, push | App store review, two release channels to manage |
| Native mobile apps | Best performance and access to device features | Two codebases, higher build and upkeep cost |
| Web portal plus mobile apps | Patients choose; shared API and design system | Largest scope; needs a clear release cadence |
Patient portal applications in the app stores
Patient portal applications in the Apple App Store and Google Play need privacy disclosures, review-ready test accounts and a plan for app updates when the EHR changes its API. Our cross-platform app team and iOS developers handle store submission and updates.
Patient portal mobile app features worth the extra cost
Biometric sign-in, push alerts that something is waiting, camera capture of insurance cards and photos for the care team, and calendar integration for appointments are the features patients use most on the phone. Each one is weighed against the build and upkeep it adds.
How do patient portals improve patient engagement?
Portals improve engagement when they remove a step the patient would otherwise take by phone: booking, refills, forms, questions, payments. Patient engagement software development extends that with reminders, education and program check-ins that run through the same sign-in.
- Reminders for appointments, screenings and refills sent as alerts that link back into the portal
- Pre-visit and post-visit questionnaires that reach the care team before the next visit
- Education matched to the visit type, written at a plain reading level
- Program enrollment and check-ins for chronic care or behavioral health programs
- Satisfaction surveys that route negative answers to a person, not a spreadsheet
- Referral and second-opinion requests with document upload
Patient engagement software inside or beside the portal
Specialist patient engagement software is a large vendor category of its own. We build engagement features into the portal when they depend on its data and sign-in, and connect to an existing tool when it already does the job well.
Patient portal benefits for providers
For the practice, the benefits are fewer inbound calls, forms complete before arrival, faster payments, fewer no-shows and a written record of every message. We set those measures at the start so the portal is judged on them, not on downloads.
Launching a digital-health product that needs a patient login?Share the care model, the data you will hold and the systems you must connect to. We reply with a free proposal covering architecture, HIPAA safeguards, hosting under a BAA and a phased release plan.
Designing for adoption, accessibility and plain language
A portal patients cannot use has no value, however secure it is. Patients include older adults, people with disabilities and people reading in a second language, so the design starts with them.
- Design to WCAG 2.2 level AA, with screen-reader testing and support for larger text sizes
- Plain-language labels: ‘Message your care team’ rather than system terms
- Sign-up that works on a phone in under a few minutes, with help text at every step
- Translated content planned with your language access lead and reviewed by qualified translators
- Error messages that say what to do next, never a code
- Usability sessions with real patients before the build is finished
Patient portal design that staff can support
Front-desk staff explain the portal more than anyone. We give them an invitation script, a printable guide and an admin view that shows a patient’s account status, so a support call takes one minute instead of ten. Our UI and UX designers run the patient and staff sessions.
How much does patient portal development cost?
Patient portal development cost depends on integrations, features, platforms and compliance scope. Published US price bands run from $50,000 to $150,000 for a focused portal and $150,000 to $300,000 for a portal with deeper EHR integration; these are market figures, not a Progression rate card, and every build is quoted after a written scope.
| Scope | Published US price band | Typical duration |
|---|---|---|
| EHR integration only, through FHIR or HL7 v2 | $40,000 to $120,000 | 2 to 4 months |
| Focused patient portal | $50,000 to $150,000 | 3 to 5 months |
| Scheduling or intake app | $60,000 to $150,000 | 3 to 6 months |
| Patient or provider portal with EHR integration | $150,000 to $300,000 | 5 to 8 months |
| Telehealth added to an existing portal or app | $50,000 to $120,000 | 2 to 4 months |
What moves the price up or down
The biggest levers are the number of systems the portal reads from and writes to, whether mobile apps launch with the web portal, how many roles and proxies the permission model handles, migration of accounts and history from an old portal, and the depth of security testing your reviewers require.
Costs that continue after launch
Budget for HIPAA-eligible hosting, monitoring, security updates, EHR interface changes, app store updates and a release cadence. Our guide to app build and running costs explains how those lines usually compare with the build.
How do you build a patient portal, and how long does it take?
We run patient portal software development in phases with a working release at the end of each: discovery, design, build sprints, security testing and a staged launch. A focused portal tied to one EHR commonly takes three to five months; deeper integration takes longer.
- Discovery: workflows, data classes, systems, risks and the written scope, with BAAs signed before any PHI is shared
- Risk analysis: threats and safeguards documented against the Security Rule before design is final
- Design: patient and staff journeys, a clickable prototype and usability sessions with patients
- Integration access: sandbox credentials and app registration with the EHR vendor, started early because it takes time
- Build: two-week sprints demonstrated on a staging environment with test data only
- Testing: security testing, accessibility audit, integration tests with the EHR sandbox and a pilot clinic
- Launch and support: staged rollout by site, staff training, monitoring and monthly releases
| Milestone | When | What to measure |
|---|---|---|
| Pilot clinic live | End of the build | Sign-up completion rate, support calls per new account |
| All sites live | One to three months after the pilot | Share of active patients with an account |
| First full quarter | Three months after launch | Messages answered within target, forms completed before arrival |
| Steady state | Six months and after | Calls avoided, online payments, no-show rate, patient satisfaction |
Patient portal requirements to settle in discovery
Who can sign up and how identity is checked, which results release automatically and when, who answers messages and how fast, what proxies may see, which systems are sources of truth, and how a patient closes an account. Writing these down first prevents most rework later.
How AI assistants answer questions about patient portal developers
Buyers researching patient portal software development increasingly ask ChatGPT, Claude, Perplexity, Gemini, Microsoft Copilot and Google AI Overviews who can build a custom patient portal that connects to a named EHR, what one costs and whether it can be HIPAA compliant. The answers draw on pages that state those facts plainly.
- Questions buyers type: ‘who builds custom patient portals that integrate with our EHR’, ‘cost of a HIPAA compliant patient portal’, ‘custom portal or the EHR’s portal’
- Pages assistants tend to cite: service pages with clear definitions, feature tables, published price bands and FAQ answers
- Primary sources they lean on: eCFR and HHS pages for HIPAA, ONC pages for information blocking and certified APIs, HL7 for FHIR
- Signals that help a vendor get named: a precise scope of work, integration methods stated plainly, security practices described without vague badges
- What healthcare organizations should publish themselves: a clear portal help page, sign-up steps and an accessibility statement patients and assistants can quote
For the marketing side of being found by patients, our AI visibility work for healthcare and healthcare SEO pages explain how practices earn citations in those assistants.
How to choose a patient portal development company
Choose the team that can show integration experience with your EHR, explain its security practices in plain terms, sign a BAA and hand you the code and accounts. Compare written scopes, not hourly rates.
| Requirement | How to check it |
|---|---|
| Integration experience with your EHR’s APIs | Ask how they would read results and write intake answers back, and what the vendor’s access program requires |
| A clear account of HIPAA safeguards | Ask them to walk through 45 CFR 164.312 for your portal, item by item |
| Willingness to sign a BAA | Request their BAA template before the scope is final |
| Security testing before launch | Ask for a sample test report with findings and fixes |
| Accessibility practice | Ask which WCAG level they design to and how they test with assistive technology |
| Code and account ownership | Confirm the repository, cloud account and app store accounts are yours |
| Honest scope advice | Ask when they would recommend the EHR’s own portal instead |
| Support after launch | Ask how EHR interface changes and security updates are handled and priced |
Questions that separate strong patient portal developers
Ask how they handle duplicate patient records at sign-up, what goes in a notification, how proxy consent is revoked, how they keep tracking code out of logged-in pages and how they would migrate message history from your current portal. Precise answers show experience.
Patient portal software development company or in-house team
An in-house team suits organizations with steady portal work and engineers who already know their EHR. A patient portal software development company suits a first build, a rebuild or a product launch, and many organizations use both, with our team handing over to theirs. Our page on outsourcing development covers how that handover works.
Patient portals for hospitals, clinics and small practices
The same building blocks serve very different organizations; what changes is scale, the number of systems and who answers patients.
Patient portal for hospitals and health systems
Hospitals need one front door across inpatient and outpatient care, several EHR instances after acquisitions, and messaging routed to many departments. Single sign-on and a shared design system matter more here than any single feature.
Patient portal for clinics and specialty practices
Clinics usually need specialty intake, consent and education flows the vendor portal lacks. A custom module beside the existing portal is often the fastest route, with the patient signing in once.
Patient portal for small practice owners
A small practice rarely needs a full custom build. The right move is usually to make the EHR’s portal work harder, add one custom flow where staff time is lost, and connect the practice website cleanly. Our healthcare website design team handles that connection.
Medical patient portal software for digital-health companies
For a digital-health company, medical patient portal software is the product itself. We build it as a SaaS platform with tenants, roles, audit logging and an API from day one. Our SaaS development page covers the platform side.
Related services for healthcare organizations
Patient portal software development sits beside other healthcare software and marketing work. These pages cover the neighboring services in depth.
- EHR and EMR development, including custom modules and integrations
- Custom software for healthcare organizations, from workflow tools to platforms
- Building HIPAA software: risk analysis, hosting, BAAs and breach rules
- Mobile health apps for patients and clinicians
- Telehealth and video visit apps that can join the portal
- Customer, partner and employee portals for other industries
- Websites for practices and health systems that link to the portal
- Web application development for complex browser-based products
- Custom software development across industries
- API design and development for partner and product integrations
- AI integration for organizations adding assistants to existing systems
- React Native apps for iOS and Android from one codebase
- Android app development for patient-facing apps
- Medical marketing that brings patients to the practice
- Analytics setups that measure without leaking patient data
Talk to a patient portal development team
Send your EHR, the patient tasks that still run by phone and any portal you use today. We reply with a free proposal: build, extend or keep, the integration route, the safeguards and a written scope.
Getting found in search
AI, AEO and what is changing
Paid media and lead generation
Websites and design
Choosing and working with an agency
Software and app development
Website design by industry and type
Web development, platforms and hosting
Social, content and brand
By industry and by situation
Frequently asked questions
What does patient portal software development include from start to finish?
How much does it cost to create a patient portal?
How do you build a patient portal that patients actually use?
What is the purpose of a patient portal?
Why are patient portals important for a practice?
How does a patient portal work behind the screen?
Are patient portals required by law?
What does HIPAA have to say about patient portals?
Is there a HIPAA certification for a patient portal?
Can a custom patient portal connect to our EHR through FHIR?
What is patient portal integration in practical terms?
Who creates patient portals?
Is a patient portal an app or a website?
What is the realistic timeline to launch a custom patient portal?
Should we build a custom patient portal or use the one in our EHR?
Can tracking pixels or analytics run inside a patient portal?
How do family members or caregivers get access to a patient’s account?
What does a patient portal provide for patients who need records quickly?
How do you keep a patient portal accessible?
Can you migrate patients from our current portal without forcing them to re-register?
Do you only build patient portals for New York organizations?
Does our organization keep the repository, cloud account and patient data at the end?
Outgrowing the portal that came with your EHR?Tell us which EHR you run, what patients complain about and what your front desk still does by phone. A free proposal follows with a build-or-extend recommendation, the integration route and a written scope.
Get a free marketing proposal
Tell us what you are trying to grow and we will come back with a plan, not a pitch deck. Same-day reply on weekdays.