Custom Patient Portal Development

What patients actually open a portal to do

Most portal sessions start with a notification: a new lab result, a reply from a nurse, a form to finish before next Tuesday’s visit. Patients rarely browse. They arrive for one task, and if it takes more than a minute or two they call the front desk instead, which is exactly the call the portal was meant to prevent. Tepia designs portals around those single task visits, starting at the notification and ending at the answer.

For a specialty group or a digital health startup, the top tasks tend to be the same five: read results with context, message the care team, complete intake and consent forms, request a refill or referral, and view or pay a statement. Behind each one sits a rule your EHR already holds, such as which message pool a question routes to, which results release automatically, and which consent forms expire after a year. The portal has to honor those rules rather than invent its own.

What drives patients away is just as predictable: a second password they forget, a result with no explanation, and a message that sits unanswered for days. Tepia treats login friction, visible reply times and results context as product requirements rather than polish, because they decide whether portal adoption grows or stalls.

Portal modules and the rules behind each

Every module in a patient portal looks simple on screen and carries a clinical or regulatory rule underneath. Tepia scopes them one at a time in Discovery so nothing surprises your compliance lead after launch.

A startup with its own clinical model may hold more of this data directly, which simplifies some rows and adds obligations to others, since you then run a full HIPAA program around your own records. Our page on HIPAA compliant software development explains how Tepia structures that.

Identity, proxy access and results release

The hardest portal problems are about who sees what, and when. Tepia works through three of them early in every engagement.

• Identity proofing at signup. An activation code printed on a visit summary is easy to issue and easy to leak. A third party identity verification step, or a match on several demographic fields against the EHR, is safer. Tepia pairs either one with multifactor login and passkeys so returning patients are not locked out every month.
• Proxy accounts. A parent of a toddler needs full access, while in many states a parent of a 15 year old should not see reproductive or behavioral health visits. An adult daughter managing her father’s care needs a signed authorization on file. Tepia models each proxy relationship as its own record with scopes and an expiration date.
• Results release. Since the 21st Century Cures Act information blocking provisions took effect, many organizations release results to the portal as soon as they are final, sometimes before the clinician has reviewed them. Tepia builds the patient side to soften that moment with plain language reference ranges, a note that the care team will follow up, and a direct path to send a question.

These decisions come out of interviews with your compliance, nursing and front desk staff, and Tepia documents each one so a later audit can trace why the portal behaves the way it does.

How Tepia approaches patient portal development

Tepia uses the same six phases on every build and fits each one to the portal’s clinical and data realities. A US based project manager leads the engagement, with engineering overseen by Brianna Martison, Director of Engineering.

1. Discovery: a review of your EHR’s API access and sandbox, interviews with patients, nurses and billing staff, and a map of every rule above. Deliverables are an Investigation Summary, an Interview Summary and User Stories such as a mother switching between two children’s records.
2. Design: a design questionnaire, moodboards and a style guide, then detailed wireframes for results, messaging and proxy switching, checked against WCAG 2.1 AA so screen reader users and older patients can finish every task.
3. Development and Testing: an Alpha with staff accounts on synthetic data and a Beta with a small patient cohort, plus test plans for access control, audit logging and load on heavy result release mornings.
4. Training: sessions for front desk and nursing teams on account activation, proxy setup and message pools.
5. Launch: account migration from the old portal, a patient communication plan, and support reps on hand during rollout.
6. Support: bug tracking, quick response on access issues, and feature requests such as adding a new consent form.

Discovery typically runs 1 to 3 months, development and QA 2 to 6 months, and launch about one month. The full method is on our process page.

Tethered EHR portal, custom portal, or both

Most EHRs ship a tethered portal, and for many practices it is enough. If you are a single specialty clinic on one EHR, your patients already use the vendor’s app, and your goals are basic results and messaging, Tepia will usually advise you to configure what you have.

A custom portal makes sense when the experience is part of what you offer, or when one vendor portal cannot cover your situation:

• You are a healthcare startup whose care model, such as a virtual specialty clinic or a membership practice, is the product, and a vendor portal would bury your brand.
• You operate across several EHRs after acquisitions and want one login for every patient.
• You need program content next to the chart, such as condition education, care plans or device readings from a remote patient monitoring app.
• You want intake, scheduling and payments in a single flow instead of three separate links.

The common middle path keeps the EHR as the source of truth and places a branded web and mobile portal on top of it through FHIR, often paired with a patient intake platform. As the Newport Medical Solutions CIO said of working with Tepia, “We were impressed with Tepia’s genuine passion for their craft.” To see whether your EHR’s APIs support the portal you have in mind, talk to Tepia.

Frequently asked questions