Web Development • HIPAA-Aware Healthcare Web • SEO • AI Search Optimization (407) 409-8383   |   [email protected]
Patient Portals & EHR Integration

Patient portals that handle ePHI the way they should.

Custom Laravel portals for the workflows a packaged portal cannot reach: scheduling, records and results access, secure messaging, refill requests, and bill pay, wired to your EHR over FHIR R4 and US Core and the vendor APIs for systems like Epic and Cerner, now Oracle Health. This is the part of healthcare web that genuinely touches patient data, so it carries the full technical layer: mandatory MFA, role-based access, ePHI encrypted in transit and at rest, and tamper-evident audit logging. We build the technical layer; your practice owns the compliance posture.

// no website is HIPAA compliant on its own; compliance is an organizational posture across your whole practice. We build the portal to be HIPAA-aware, and we draw a clean line between what we own and what only your organization, your policies, and your signed agreements can carry.

Start a Project Call (407) 409-8383
FHIR R4 / US CORE MFA + RBAC + AUDIT ePHI ENCRYPTED
The overview

The portal is where the patient data actually lives.

Across a healthcare site, most pages can be kept clean of protected health information. The portal is the deliberate exception. It is the surface where a patient logs in to see results, message a provider, book a visit, request a refill, or pay a bill, which means it genuinely handles ePHI rather than carefully avoiding it. So it does not get a lighter touch. It gets the full technical layer, built in from the first commit rather than retrofitted later under deadline pressure.

We build these portals as custom Laravel applications because the workflows a real practice needs rarely fit a packaged template. Scheduling rules, the way messages route to the right staff, how records and results are surfaced, the refill flow, the billing path: these are where a practice is specific, and a custom build lets us shape them around how you actually work instead of bending your operations to fit a vendor portal. Underneath the surface, the portal speaks to your EHR over standard interfaces so the integration is portable, not welded to one vendor forever.

The framing stays the same as everywhere else on this site. A portal can be built to be HIPAA-aware, with every safeguard the data warrants, but it is still one part of an organizational posture, not the whole of it. We own the code, the integration, the encryption, the access control, and the audit logging. Your practice owns executing the BAAs, running the Security Risk Analysis, training staff, and determining and notifying on breaches. We will not blur that line to make the build sound like more than it is.

What the portal does

A patient portal is a workflow tool first. These are the flows we build into it most often.

  • Scheduling and appointment requests
  • Records and lab or test results access
  • Secure provider and staff messaging
  • Prescription refill requests
  • Bill pay and statement access
  • EHR integration over FHIR R4 and US Core
What is included

The full technical layer, because the data demands it.

Every PHI surface in a portal carries the same non-negotiable baseline. Mandatory MFA on patient and staff logins, role-based access control so a person sees only what their role permits, encryption of ePHI in transit and at rest, and tamper-evident audit logging so activity can be reconstructed. These are not optional add-ons priced separately. They are the floor for any system that touches patient information.

On top of that baseline sits the part that makes the portal yours: the custom workflows and the EHR integration. We build to FHIR R4 and US Core first, so the integration is portable, and reach for vendor APIs from systems like Epic and Cerner, now Oracle Health, where a capability lives outside the standard. The whole thing is documented, and the code and infrastructure live in your accounts so your team can carry it forward.

What is included

  • Custom Laravel portal for scheduling, records, and messaging
  • Refill requests and secure bill pay where you need them
  • EHR integration over FHIR R4 and US Core
  • Vendor API integration for Epic and Cerner / Oracle Health
  • Built with CMS-0057-F and ONC API rules in view
  • Mandatory MFA on every patient and staff login
  • Role-based access control scoped to what each role needs
  • ePHI encrypted in transit and at rest
  • Tamper-evident audit logging from the first commit
  • BAA-eligible hosting and documentation you can keep on file
EHR integration

Standards first, vendor APIs where they are needed.

Connecting a portal to an EHR is its own piece of work, and we scope it as one rather than waving it through. The modern interface is FHIR R4 with the US Core profiles, which most major EHRs now expose, and we build to that so the integration is portable rather than tied to a single vendor for life. Where a system like Epic or Cerner, now Oracle Health, offers its own API surface or app program for a capability the standard does not yet cover, we use it too, behind a clean boundary so the rest of the portal does not care which vendor sits underneath.

The integration is the part that rewards care: the data model, the authorization handshake, the rate limits, and testing against a vendor sandbox before anything touches production. We treat it as engineering, not a configuration toggle, because that is what it is.

Two regulatory notes, stated honestly. CMS-0057-F and the ONC API requirements, with most provisions effective January 1, 2027, shape how portals and payer data are expected to interoperate, so we build with them in view where they apply to your scope. And the MFA, encryption, and audit logging we ship align with the proposed December 2024 Security Rule update, which is prudent to build to now even though it is proposed rather than current law.

How the integration is built

  • FHIR R4 with US Core profiles as the primary interface
  • Vendor APIs for Epic and Cerner / Oracle Health where needed
  • Integration behind a clean, swappable boundary
  • Tested against a vendor sandbox before production
  • Authorization handshake and rate limits handled deliberately
  • Built with CMS-0057-F and ONC API rules in view
  • Aligned to the proposed Security Rule update, framed honestly
  • A candid read on whether a rule applies to your scope
How we work

Map the data, secure the surface, then integrate.

A portal touches ePHI, so we start by being precise about exactly what it handles and who is allowed to see it. The safeguards go in from the first commit. The EHR integration comes next, scoped as its own work, and the whole thing is handed over documented and yours to run.

// the portal carries the weight, so it gets the full layer from day one

  1. Map the data and the rolesWe start by being precise about what ePHI the portal handles, where it enters, where it rests, and who is allowed to see each piece. That map drives the role-based access control and the audit logging, and it keeps the portal scoped to exactly what it should carry rather than more.
  2. Build the safeguards in firstMandatory MFA, role-based access control, encryption of ePHI in transit and at rest, and tamper-evident audit logging go in from the first commit. We lean on Laravel's mature, well-audited auth tooling for the security-critical plumbing rather than inventing our own, because boring and proven beats clever here.
  3. Build the workflowsOn top of the secure baseline we build the flows that make the portal yours: scheduling, records and results, secure messaging, refills, and bill pay, shaped to how your practice actually runs rather than bent around a packaged template.
  4. Integrate with the EHRWe connect to your EHR over FHIR R4 and US Core, reaching for vendor APIs from Epic or Cerner / Oracle Health where the standard does not reach, behind a clean boundary. We test against a sandbox before anything touches production, with CMS-0057-F and the ONC rules in view.
  5. Gate the vendors, document, and hand overPHI only reaches infrastructure a covered vendor will sign a BAA for, so we select BAA-eligible hosting and form processing. We hand the portal over documented: what is encrypted, what is logged, how access is scoped, with the code and infrastructure in your accounts.
Questions, answered honestly

Frequently asked questions

Because the bundled portal is built for the average practice, and your workflows are not average. Packaged portals are fine for the basics, but they tend to fall short the moment you need scheduling logic, intake, messaging, or billing to work the way your practice actually runs, or to pull several systems into one coherent patient experience. A custom Laravel portal lets us shape those workflows around you and integrate with your EHR over standard interfaces rather than bending your operations to fit a vendor template. That said, if the portal you already have genuinely covers what you need, we will tell you so. A custom build earns its cost only when the off-the-shelf option leaves a real gap.

Over standards first, vendor APIs where they are needed. The modern interface is FHIR R4 with the US Core profiles, which most major EHRs now expose, and we build to that so the integration is portable rather than welded to one vendor. Where a system like Epic or Cerner, now Oracle Health, offers its own API surface or app program for capabilities FHIR does not yet cover, we use those too, behind a clean boundary so the rest of the portal does not care which vendor sits underneath. We scope the integration deliberately because connecting to an EHR is its own piece of work: the data model, the authorization handshake, the rate limits, and the testing against a sandbox before anything touches production.

Yes, and the difference is the whole reason we separate them. A marketing site is the public layer (services, conditions, providers, locations, accepted insurance, and FAQs) and we deliberately keep it out of PHI scope so it carries no patient data and stays simple to run safely. A patient portal is the opposite. It handles real ePHI, so it gets the full technical layer: mandatory MFA, role-based access control, encryption in transit and at rest, tamper-evident audit logging, and EHR integration. We keep the two on different footings on purpose, so the large public surface never carries the weight that only the portal should.

They are the baseline, not extras. Every PHI surface in a portal gets mandatory MFA on patient and staff logins, role-based access control so a person sees only what their role permits, encryption of ePHI in transit and at rest, and tamper-evident audit logging so activity can be reconstructed after the fact. We build these in from the first commit rather than retrofitting them under deadline pressure, because security added late is security added badly. We will not ship a portal that touches patient data without them.

No, and we are careful here. The December 2024 update (mandatory MFA, encryption at rest, network segmentation, scan and pen-test cadences, and annual verification) is a proposed rule as of mid-2026, not current law. The MFA, encryption, and audit logging we ship align with where that proposed rule is heading, which is why we consider it prudent to build to now. But building to a proposed standard is good engineering, not a compliance attestation, and HIPAA compliance remains an organizational posture your practice holds, not a checkbox a portal ticks. We build the technical layer to that stricter bar; we do not call it a mandate before it is one.

It is the CMS Interoperability and Prior Authorization rule, and together with the ONC API requirements it shapes how portals and payer data are expected to interoperate, with most provisions effective January 1, 2027. If your portal exchanges data with payers or surfaces information covered by those interoperability requirements, we build with the rule in view so the integration is not at odds with where the standards are going. We will tell you plainly whether it applies to your scope or not, rather than invoking it as a reason to expand the project.

We keep that line clean and visible. We own the technical deliverable: the portal code, the EHR integration, MFA, role-based access, encryption of ePHI in transit and at rest, tamper-evident audit logging, and the documentation of all of it. Your practice owns the posture a vendor cannot carry: signing the Business Associate Agreements with covered vendors, conducting your organization-wide Security Risk Analysis, training your workforce, and making breach determinations and notifications. A portal handles PHI, so a BAA obligation attaches to the pieces that touch it; we select BAA-eligible hosting and make sure patient data never lands in a tool that will not sign one, and you sign the agreements that make those choices hold.
The rest of the codex

Related services

A portal is the heaviest surface of a healthcare site, but it rarely stands alone. These are the neighboring pieces of the HIPAA-aware web hub, and the Insights article that lays out what "HIPAA-compliant" actually means.

THE HUB HIPAA-aware Healthcare Web Overview of HIPAA-aware Healthcare Web services
Healthcare Website Development HIPAA-aware practice and clinic sites, kept out of PHI scope
Secure Forms & Intake Encrypted intake and consent forms routed only to BAA-covered vendors
Accessibility & Section 1557 WCAG audits and remediation for Section 1557 and ADA conformance
Tracking & Analytics Governance Pixel, tag, and analytics audits so patient pages do not leak PHI
Healthcare Security Maintenance Security patching, scans, and monitoring for healthcare sites

Further reading: What "HIPAA-compliant" actually means for a website (and what it does not).

Need a portal that fits your practice and your EHR?

Tell us the workflows the portal has to handle and the EHR it has to talk to. We will give you a straight read on the FHIR and vendor-API integration, the safeguards the data demands, and exactly where the line sits between what we build and what your practice has to own.

Start a Project