Patient Portal Software Development Services
Patient portal software development services cover the design, build, EHR integration, and compliance architecture behind a secure portal where your patients view records, book visits, message clinicians, and pay bills. Arkenea is a patient portal software development company working with hospitals, medical groups, and health tech firms, and we have built healthcare software and nothing else since 2011.
Book a discovery callWhy Healthcare Organizations Choose Arkenea as Their Patient Portal Software Development Company
Portals fail for reasons that have very little to do with code quality. They fail because the release logic for lab results does not match how your clinicians actually want results released, because proxy access was treated as a permissions checkbox instead of a legal question, or because the integration was scoped before anyone looked at what your EHR vendor will let you read and write. Arkenea works on healthcare software exclusively, so those are the questions we open with.
We already know the workflows a portal touches
A patient portal is not a standalone product. It sits on top of scheduling rules, result release policy, refill protocols, billing statements, and clinical inboxes. We have built inside every one of those workflows across 15 years, so we spend discovery pressure testing your policy decisions rather than asking you to explain what a chart note is.
Compliance is an architecture decision, not a checklist
Audit logging, encryption key handling, session behavior, minimum necessary access, and break glass procedures all get decided when the data model is drawn, not during a pre launch review. We design portals so the HIPAA Security Rule safeguards are structural. Retrofitting them costs several times more than building them in.
Discovery comes before a fixed price
We will not quote a portal build from a feature list. Discovery produces a functional specification, an integration plan validated against your actual EHR interfaces, a compliance model, and a wireframe set. The fixed price comes after that document exists, which is why our portal projects tend to land close to their original estimate.
What Does Patient Portal Software Development Actually Involve?
Patient portal software development is the process of building a secure, authenticated application that gives patients access to their own health information and a set of self service actions against their care. The core deliverable is usually four things: an identity and access layer that proves the person logging in is who they claim to be, a data layer that pulls clinical and financial records out of your source systems, a task layer that lets patients do something with what they see, and an administrative layer that lets your staff manage all of it. Everything else is a module bolted onto that spine.
The work splits roughly into three streams that run in parallel. Integration engineering connects the portal to your EHR, practice management system, lab interfaces, clearinghouse, and payment processor, typically through HL7 v2 messages, FHIR R4 APIs, or a vendor specific API depending on what your systems expose. Product and UX work decides what patients see, in what order, and under what conditions, which for a portal is mostly a set of policy decisions rendered as an interface. Compliance and security engineering covers authentication strength, audit trails, encryption at rest and in transit, role definitions, and the documentation you will need when someone asks how patient data is protected.
A patient portal development company earns its fee in the integration and policy streams, not the interface. The screens are the visible part and the least difficult part. The difficulty sits in questions like how quickly an abnormal pathology result should appear to a patient, what happens to a teenager's account on their 18th birthday under your state's consent law, and whether your EHR's API will actually let you write an appointment back or only read one. Those answers change the architecture, and they need to be settled before development starts rather than discovered in week nine.
Patient Portal Development Services: What We Build, Module by Module
Most portal projects start with four or five of the modules below and add the rest over the following year. We build them as separate services against a shared identity and data layer, so the second phase does not require rebuilding the first. Here is what each module involves in practice.
Health records and results release
Problem lists, medications, allergies, immunizations, visit summaries, imaging reports, and lab results, mapped to USCDI v3 data classes. The engineering question is release timing: which result types publish immediately, which hold for clinician review, and how your policy reconciles with information blocking rules.
Scheduling, intake, and reminders
Self service booking against real provider availability, rescheduling and cancellation, waitlist logic, digital intake forms that write structured data back rather than producing a PDF, and reminder sequences over SMS, email, and push notification with confirmation handling.
Secure messaging and clinical inbox
Threaded patient to clinician messaging with attachments, routing rules by message type, pooled inboxes for care teams, response time tracking, and automatic escalation. Message volume is the single most common source of clinician complaint after a portal launch, so routing design matters more than the chat interface.
Billing, estimates, and online payment
Statement display in plain language, itemized charge detail with CPT and revenue codes where your system supplies them, card and ACH payment through a payment processor inside a compliant boundary, payment plans, and good faith estimate delivery for self pay patients.
Prescriptions and refill requests
Current medication list, refill request routing to the prescribing clinician, pharmacy selection, and status visibility. Where electronic prescribing is in scope we work through NCPDP SCRIPT and your existing prescribing network rather than building a parallel path.
Proxy access, caregivers, and dependents
Parent and guardian access to a child's record, adult caregiver access with patient granted scope, revocation, and automatic scope changes at the age of majority under your state's minor consent law. Federal survey data shows caregiver portal use doubled between 2020 and 2024, and portals built without a proper relationship model cannot support it safely.
Telehealth and video visits
Video consultation launched from within the portal session, virtual waiting room, device and connection checks before the call, consent capture, and post visit summary delivery. We build this as a module inside the portal rather than a separate telemedicine application when the patient should experience one product.
Patient generated data and device sync
Blood pressure, glucose, weight, symptom logs, and questionnaire responses flowing from consumer devices and wearables into the record, with the review workflow and alert thresholds that make the data usable by clinical staff instead of just stored.
Patient Portal Web Development Services or Patient Portal Mobile App Development Services: Which Do You Need?
Start with a responsive web portal, then add a native mobile app once you know which actions patients repeat. That order holds for most organizations, and the reason is that the federal usage data shows both channels now matter but they carry different traffic. In 2024, 57% of people who used their online medical record reached it through an app, while the share using web only access fell to 42%. Neither number is small enough to skip.
Patient portal web development services produce the system of record for the portal experience. Everything lives there: full record access, long documents, billing detail, intake forms, and the administrative console your staff uses. Web is where a patient goes when they need to read something carefully or complete something long. It is also faster and cheaper to change, since a fix ships without an app store review, and it works on a borrowed laptop in a waiting room.
Patient portal mobile app development services earn their cost on the repeat actions. Biometric login instead of a password, push notifications for results and appointment reminders, camera access for insurance card and document capture, health kit and device data sync, and location aware check in. A native healthcare mobile app also lifts engagement measurably on messaging and reminders, because a push notification reaches a patient who never opens portal email. If your portal's value depends on chronic condition monitoring, medication adherence, or high message volume, the app is not optional and should be planned in phase one rather than deferred.
The build decision that saves money later is architectural. Both channels should consume the same API layer, the same authentication service, and the same permissions model. When the web portal and the mobile app are built as two products with two backends, every future feature costs twice and the two eventually disagree about what a patient is allowed to see. We build one healthcare web application backend and treat web and mobile as two clients against it.
Where AI Earns Its Place in a Patient Portal
AI belongs in a patient portal where it removes measurable staff minutes or measurable patient confusion, and nowhere else. The five uses below are the ones we see produce a defensible return in portal projects. Each one runs inside the compliance boundary with a business associate agreement in place and a human review step where the output touches clinical meaning. Our AI development team builds these as scoped features rather than a general assistant bolted onto the interface.
- Message triage and drafting. Incoming patient messages get classified by type and urgency, routed to the right pool, and returned with a draft reply the clinician edits and sends. The saving is in routing and first draft time, and clinics that measure it typically report cutting inbox handling time by a third or more.
- Plain language result explanation. A lab or imaging result is paired with a reading level appropriate explanation of what the value means and what it does not mean, with an explicit prompt to contact the practice rather than an interpretation of the patient's specific condition. This reduces the call volume that follows every batch of released results.
- Intake and history summarization. Free text a patient enters at intake gets structured into problem, medication, and allergy candidates that the clinician confirms rather than retypes, which shortens the first few minutes of a visit.
- Scheduling assistance. A conversational booking path that reads real availability, applies visit type rules and provider constraints, and offers slots, with fallback to a human when the request does not match a defined visit type.
- Coverage and estimate questions. Retrieval over your own benefits, pricing, and policy documents so the portal answers billing questions from your source material with a citation, instead of a general model guessing at your fee schedule.
Integrations and Interoperability
A patient portal is only as useful as the systems it reads from and writes to. Integration scope is the largest single variable in a portal budget, so we validate what each interface actually permits during discovery rather than assuming a published API does what its documentation implies.
Systems we integrate with
- EHR and EMR platforms including Epic, Oracle Health, athenahealth, eClinicalWorks, NextGen, MEDITECH, Greenway, AdvancedMD, and DrChrono, plus custom and legacy systems through our EHR development practice
- Practice management and scheduling systems, for provider availability, visit types, and appointment write back
- Laboratory and diagnostic interfaces, including Quest and Labcorp result feeds and hospital laboratory information systems
- Revenue cycle and clearinghouse connections for eligibility, claim status, and statement data
- Payment processing through PCI DSS compliant processors, kept outside your own cardholder data scope
- Pharmacy and prescribing networks for refill routing and medication history
- Identity providers, single sign on, and multi factor authentication services
- Communication infrastructure for SMS, email, push notification, and secure document delivery
Standards we work in
- HL7 FHIR R4, using US Core profiles, and SMART on FHIR for app authorization against certified EHR APIs
- HL7 v2 messaging for ADT, ORU results, ORM orders, SIU scheduling, and DFT charge feeds
- USCDI v3 as the data class baseline for what a portal must be able to surface
- C-CDA documents for continuity of care summaries and record import from other organizations
- X12 transactions including 270 and 271 eligibility, 837 claims, and 835 remittance
- NCPDP SCRIPT for prescription and refill transactions
- Terminology systems: LOINC for observations, RxNorm for medications, SNOMED CT for clinical findings, ICD-10-CM for diagnoses, and CPT for procedures
- OAuth 2.0 and OpenID Connect for authorization, with identity assurance aligned to NIST SP 800-63 IAL2 where remote proofing is required
What HIPAA Compliance Requires in Patient Portal Architecture
The HIPAA Security Rule does not hand you a technical specification, and that is exactly why portals get it wrong. It sets required and addressable safeguards and expects you to justify how your implementation meets them, which means the compliance posture of a portal is a set of architectural decisions you have to be able to defend. In practice that means encryption in transit and at rest with documented key management, unique user identification with no shared accounts, an audit trail that records every access to protected health information including reads rather than only writes, automatic session termination, role based access enforced at the API layer rather than only in the interface, a defined emergency access procedure, and integrity controls that show a record was not altered in transit. Business associate agreements need to be in place with every vendor that touches the data, including your cloud provider, your messaging provider, and any AI service in the path. Full guidance on the safeguards is published by the HHS Office for Civil Rights.
Above HIPAA sits a second regulatory layer specific to patient facing systems, and it pushes in the opposite direction. The 21st Century Cures Act information blocking rules require that you not unreasonably delay a patient's access to their own electronic health information, which constrains how long you can hold results for clinician review before release. Certified EHR technology has to expose standards based FHIR APIs that let a patient use a third party app of their choice, which means your portal is no longer the only door to the data and your architecture should assume it. Layered on top of that are 42 CFR Part 2 protections for substance use disorder records, state minor consent laws that vary considerably in what a parent may see once a child reaches adolescence, and state privacy statutes with their own breach notification timelines. A portal designed only against HIPAA will satisfy the security requirements and still be out of step with the access requirements. Both layers need to be in the specification before development begins, which is part of what our discovery and roadmapping engagement produces.
Should You Build a Custom Patient Portal or Use the One Bundled With Your EHR?
Use the portal bundled with your EHR if your requirements sit inside what it already does and your patient population tolerates it. Build custom when the portal is part of how you differentiate, when you serve a population the generic experience fails, or when you need to combine data from systems your EHR vendor has no interest in connecting. The table below sets out where each choice holds.
| A platform or EHR bundled portal makes sense when | Custom patient portal development makes sense when |
|---|---|
| You run a single EHR and your patients interact with one organization, so a single vendor portal covers the whole relationship. | Your patients touch several systems, or you have grown through acquisition and people hold accounts on three different portals that do not talk to each other. |
| Your needs are the standard set: results, scheduling, messaging, bill pay, and refills, configured rather than built. | Your care model has requirements no vendor ships, such as program specific care plans, condition tracking, group or family structures, or a service line with its own workflow. |
| You want a predictable subscription line item and no engineering headcount or vendor management overhead. | Per user or per provider subscription pricing scales badly against your patient volume, and a build plus maintenance model costs less across a five year horizon. |
| Your brand experience is not a competitive factor, and a vendor branded interface with limited theming is acceptable. | The portal is your product, or a major part of how patients experience your organization, and the interface has to be yours from the login screen forward. |
| Your compliance team prefers the vendor to carry the certification and attestation burden. | You are commercializing the portal to other organizations, which puts you in the position of the vendor and makes multi tenancy, configurability, and your own SOC 2 Type II posture part of the requirement. |
There is a middle path, and for a lot of organizations it is the right one. You keep the EHR portal as the record of truth for results and clinical documents, then build custom medical software modules around it that consume the same data through FHIR APIs and single sign on. Patients get one entry point and one login, your differentiated workflows live in software you control, and you avoid rebuilding the parts your EHR already handles adequately. Federal data from 2024 shows 70% of non federal acute care hospitals now expose FHIR based app access, which makes this approach viable in more environments than it was three years ago. It is also the fastest path to something in production, since the first release can be narrow.
Patient Portal Projects We Have Delivered
The three below are the closest matches in our portfolio to a patient portal build. Each one solved a different part of the problem: the full patient facing plus staff facing portal pairing, secure patient communication at scale, and patient generated data flowing back to a clinician. More of our work is on the case studies page.
Cumberland Health: patient app paired with admin, provider, and front desk portals
The problem was fragmentation. Patient onboarding, provider scheduling, and front desk operations ran on disconnected tools, so onboarding went uncompleted, providers had no view of live appointment assignment, and front desk staff could not track payment collection.
We built a patient facing mobile application alongside a web portal serving three staff roles. Patients complete guided onboarding with mandatory HIPAA consent, sign in through one time passcode or Google and Apple single sign on, manage dependent profiles, and move from secure chat into a live video consultation. Staff portals carry provider availability windows that control assignment visibility, full appointment lifecycle tracking, automatic closure of appointments left unattended past a defined service level window, integrated payment collection inside the appointment record, and a central analytics dashboard. Access is governed by role with account lockout and automatic logout across every role.
Careusel: HIPAA compliant messaging and content delivery to patients at scale
Professionals were running client communication across several disconnected tools with no automation, which meant manual outreach, delayed responses, and clients who struggled to reach anyone or find the resources they had been sent.
We built a web application and a cross platform mobile application that automate communication journeys, carry HIPAA compliant one to one and group chat, support broadcast messaging to an entire population at once, and hold a central content library so materials are shared from one source rather than reattached each time. Connections are added by scanning a QR code, which removed the manual account linking step. The messaging and content architecture here maps directly onto the secure messaging and patient education modules of a portal.
MiPHR: patient generated health data flowing back to the clinician
Patients managing diabetes risk had no single place to track health data and no straightforward way to get what they tracked in front of their provider, so useful information stayed on the patient's phone.
We built a mobile health record application with calorie tracking against the USDA food database with QR code scanning, connectivity to leading consumer health devices for automatic data sync, an interactive dashboard with trend graphs, and face and fingerprint authentication protecting the record. Monthly detailed and summary reports are generated and transmitted to the treating provider automatically. This is the patient generated data module of a portal built as a standalone product, and it is the same problem: getting patient reported data into a form a clinician will actually act on.
How the Patient Portal Development Process Works
Six phases, with a fixed price set at the end of the first one rather than the beginning. The sequence below is what a portal build looks like from first conversation to a supported production system.
Discovery and functional specification
Two to four weeks. We map the workflows the portal will touch, settle the policy questions that drive architecture, audit what your EHR and ancillary systems actually expose, and produce a functional specification with an integration plan, a compliance model, wireframes, and a fixed price. You own the document whether or not you build with us.
Workflow and experience design
Interface design for both patient and staff sides, tested against the populations that struggle most: older patients, patients with low digital confidence, caregivers acting for someone else, and patients using assistive technology. We design to WCAG 2.1 AA, which is a practical requirement for a portal serving a general patient population.
Architecture and compliance design
Data model, API contracts, tenancy model, authentication and identity proofing strength, role and permission definitions, audit logging scope, encryption and key management, retention rules, and the hosting configuration. This phase produces the security documentation you will be asked for later, written while the decisions are being made rather than reconstructed afterward.
Development and integration
Two week sprints with a working build you can use at the end of each one. Integration work starts in the first sprint rather than being saved for the end, because interface surprises are the most common cause of a portal project slipping, and they are cheapest to find early.
Testing against clinical scenarios
Functional, integration, performance, and accessibility testing, plus security testing that includes authorization boundary checks against the specific ways portal data leaks: proxy relationships, adolescent record transitions, merged duplicate patient records, and result release timing. We test with clinical scenarios drawn from your own workflows, not generic test data.
Launch, adoption, and support
Phased rollout starting with a defined patient cohort, staff training, enrollment built into your existing patient touchpoints, monitoring and alerting, and an ongoing support agreement. Adoption work belongs in the launch plan, since federal data shows patients encouraged by their provider to use the portal access it at far higher rates than those who are not.
What Does Patient Portal Software Development Cost?
Custom patient portal development runs from roughly $60,000 to $300,000 in the United States, and the number is driven far more by integration count and compliance scope than by how many screens the portal has. A portal with four modules and one clean FHIR integration costs a fraction of the same portal integrating three legacy systems through HL7 v2 interfaces that need custom mapping. Here is how the range breaks down by project tier.
- Focused portal or first release: $60,000 to $110,000, typically 12 to 16 weeks. Records access, scheduling, secure messaging, and one EHR integration through a supported API. This is the right starting scope for a practice or a health tech firm validating demand.
- Full portal with multiple integrations: $110,000 to $180,000, typically 16 to 24 weeks. Adds billing and payment, refill requests, proxy and dependent access, patient generated data, and integrations across your practice management system, laboratory feeds, and clearinghouse.
- Enterprise or commercial portal: $180,000 to $300,000 and above, typically 24 to 40 weeks. Multi site or multi tenant architecture, several EHRs, a native mobile application alongside the web portal, advanced identity proofing, AI modules, and the audit and certification posture required when you are selling the portal as a SaaS product to other organizations.
- Ongoing maintenance and support: 15% to 20% of the build cost per year. This covers hosting and infrastructure, security patching, dependency updates, interface changes when your EHR vendor releases a new version, compliance monitoring, and support response. Budget for it from the start, since a portal that is not maintained becomes a security liability rather than an asset.
We do not quote from a feature list. Discovery produces a functional specification and a validated integration plan, and the fixed price follows from that document. It is a paid engagement, it takes two to four weeks, and the specification is yours to take to any patient portal development agency you like. Most clients find it is the cheapest part of the project and the part that most reliably prevents the expensive surprises.
What the Federal Data Says About Patient Portal Adoption
Portal use is no longer a question of whether patients will log in. The national survey data collected by the Office of the Assistant Secretary for Technology Policy shows the behavior has already shifted, and it points at where the build effort should go.
65%
of individuals nationwide were offered and accessed their online medical record or patient portal in 2024, up from 25% in 2014.
57%
of portal users reached their records through an app in 2024, up from 38% in 2020, while web only access fell from 60% to 42%.
70%
of non federal acute care hospitals enabled patient access through apps built to HL7 FHIR specifications in 2024, though only 56% let patients import records from another organization.
Patient Portal Software Development FAQs
How long does patient portal development take?
A focused first release takes 12 to 16 weeks from the end of discovery. A full portal with billing, refills, proxy access, and several integrations takes 16 to 24 weeks. Enterprise and commercial portals with multiple EHRs and a native mobile application run 24 to 40 weeks. Discovery adds two to four weeks ahead of any of those. The variable that moves the timeline most is integration: waiting on EHR vendor API access, sandbox credentials, and interface engineering time on your side routinely adds more calendar time than the development work itself, so we start that request on day one.
Can you integrate a patient portal with Epic, Oracle Health, or athenahealth?
Yes. We integrate with Epic, Oracle Health, athenahealth, eClinicalWorks, NextGen, MEDITECH, Greenway, AdvancedMD, DrChrono, and custom or legacy systems. The method depends on what the system exposes. Certified EHRs publish FHIR R4 APIs with US Core profiles and support SMART on FHIR app authorization, which is the cleanest path. Where an interface is limited we work through HL7 v2 messaging for ADT, results, orders, and scheduling, or a vendor specific API. During discovery we test the actual interfaces against your requirements rather than relying on the documentation, because what an API permits in practice and what its documentation describes are frequently different.
Do we own the code and the patient data?
Yes to both. You own the source code, the repositories, the infrastructure accounts, and the data outright. The code is delivered into your version control from the first sprint, not handed over at the end, and the hosting sits in your cloud account. Nothing is licensed back to you and there is no dependency on Arkenea for you to continue operating or extending the portal. We think this matters most on portals specifically, because a portal holds a patient relationship you cannot afford to have hostage to a vendor agreement.
What does it cost to maintain a patient portal each year?
Budget 15% to 20% of the original build cost annually. That covers hosting and infrastructure, security patching and dependency updates, changes needed when your EHR vendor updates its interfaces, compliance monitoring and audit log review, monitoring and incident response, and support. Portals carry a higher maintenance ratio than internal software because they face the public internet, hold protected health information, and depend on third party interfaces that change without asking you first. A portal left unmaintained for two years is a security exposure rather than an asset.
Should the portal be a web application, a mobile app, or both?
Start with a responsive web portal and add a native mobile app once you know which actions your patients repeat. Web carries the full record, long documents, billing detail, and intake forms, and it ships changes without an app store review. Mobile earns its cost on repeat actions: biometric login, push notifications for results and reminders, camera capture for insurance cards, and device data sync. If your portal depends on chronic condition monitoring, medication adherence, or high message volume, plan the app into phase one. Whatever the sequence, both should run against one shared API layer and one permissions model so future features do not have to be built twice.
How do you handle identity proofing and proxy access?
Identity proofing gets designed around the enrollment path. In person enrollment can rely on staff verification at the point of care. Remote self enrollment needs something stronger, typically knowledge based verification, document verification, or an identity service, with assurance aligned to NIST SP 800-63 IAL2 where the risk warrants it. Proxy access is modeled as a relationship with its own scope, start date, end date, and revocation, never as a shared login. Parent access to a child's record, adult caregiver access granted by the patient, and legal guardian access are separate relationship types with different permissions, and adolescent records need automatic scope changes at the ages your state's minor consent law specifies. Caregiver portal use doubled nationally between 2020 and 2024, so this is no longer an edge case.
Is a custom portal harder to keep HIPAA compliant than a vendor portal?
No, but the responsibility sits with you rather than with a vendor. A vendor portal comes with the vendor's attestations and their security team. A custom portal means the safeguards, the documentation, the audit logging, and the business associate agreements are yours to maintain. That is manageable and it is what we build for, with encryption and key management, unique user identification, comprehensive access logging, role based authorization enforced at the API layer, session controls, and the security documentation produced during the architecture phase rather than reconstructed later. The upside is control: you decide the release timing, the access rules, and the retention policy instead of accepting a vendor's defaults.
Can you take over a patient portal another team built?
Yes, and it is a common engagement. We start with a technical and security audit covering code quality, dependency currency and known vulnerabilities, the integration layer, audit logging completeness, authorization boundaries, and infrastructure configuration. That audit produces an honest recommendation on whether the codebase should be maintained and extended or replaced, along with the cost of each path. We have taken over portals that were sound and needed a year of catch up work, and we have seen portals where the authorization model was broken deeply enough that rebuilding was cheaper than repairing.
How do you get patients to actually use the portal after launch?
The strongest lever is your own staff. Federal survey data from 2024 shows 87% of patients whose provider encouraged them to use the portal accessed it at least once that year, against 57% of those who were not encouraged. That gap is larger than anything an interface change produces. So enrollment belongs in your existing touchpoints, at registration, at discharge, and in the appointment reminder, with staff who have been trained on how to ask. Beyond that: make the first login trivially easy, put something worth returning for behind it such as results and bill pay, use push notification rather than email alone, and measure enrollment and repeat use as separate metrics because they fail for different reasons.
What if we cannot replace the patient portal bundled with our EHR?
Then keep it and build around it. Your EHR portal stays the record of truth for clinical documents and results, and custom modules sit alongside it consuming the same data through FHIR APIs with single sign on, so patients experience one login and one entry point. This is often the better answer even when replacement is possible, because it puts the differentiated workflows in software you control while leaving the commodity functions where they already work. With 70% of hospitals now exposing FHIR based app access, this approach is viable in far more environments than it was three years ago, and the first release can be narrow enough to reach production quickly.
Talk to a Team That Builds Patient Portals and Nothing Outside Healthcare
Bring us the workflow problem, not a feature list. Discovery gives you a functional specification, a validated integration plan, a compliance model, and a fixed price, and the document is yours whether you build it with us or not.