What does it take to build a referring-physician portal in-house?

More than a login screen over your data. You'd own automated identity verification of outside practices (NPI, exclusion lists, sanctions checks), row-level role-scoped access so each physician sees only their own patients, comprehensive PHI audit logging, break-the-glass governance, interoperability with your EMR (HL7/FHIR), onboarding workflows for HIM, and ongoing security and support. Each of those is a project in itself.

Why is the audit and access-control part so hard?

Because it's PHI going to people outside your organization. Every access has to be scoped to the right patients and logged at the row level, identities have to be verified and re-verified, and emergency access has to be governed and separately audited. Getting this slightly wrong is a compliance incident, not a bug — which is why it tends to consume far more effort than the visible UI.

When does building make sense?

Rarely, for this specific capability. Building can make sense when a need is core to your differentiation and nothing fit-for-purpose exists. A referring-physician portal is neither — it's a well-defined, compliance-heavy capability that several proven systems already provide, so building usually means re-creating solved problems at your own risk and cost.

What's the hidden cost of buying?

Mostly integration and governance fit: making sure the portal works with your EMR, runs under your controls, and matches your HIM workflows. A portal that's standards-based and runs in your environment minimizes that — you're adding a governed access layer, not exporting your data to someone else's cloud.

Referrals & physician engagement

Build vs buy a referring-physician portal

Updated June 2026 · Reviewed by David Higginson, CHIME Innovator of the Year

A referring-physician portal looks simple from the outside — a login over your records. The hard part is everything that makes giving outside clinicians access to PHI safe, and that's where build-vs-buy is really decided.

The build-vs-buy decision weighs developing a referring-physician portal in-house against adopting an existing one. Building means owning identity verification, row-level role-scoped access, full PHI audit logging, interoperability and ongoing support; buying shifts that engineering and compliance burden to a proven system. Because this capability is compliance-heavy and well-defined, buying is usually the lower-risk path.

What "build" actually includes

The visible portal is a fraction of the work. To build it responsibly you'd own:

Identity verification of outside practices — NPI Registry, OIG-LEIE exclusion checks, SAM.gov, and re-verification over time.
Row-level access control so each physician sees only their own patients — not your whole population.
Comprehensive PHI audit logging — who saw which patient, when, from where.
Break-the-glass governance for emergencies, governed and audited separately.
Interoperability with your EMR via HL7 v2 and FHIR.
HIM onboarding workflows — review queues, approvals, user lifecycle.
Security, monitoring and support, indefinitely.

The risk asymmetry

This isn't ordinary feature work — it's PHI flowing to people outside your organization. A mistake in access scoping or audit isn't a bug, it's a reportable incident. Building means carrying that risk yourself and re-solving problems that proven portals have already solved and hardened. The engineering cost is real, but the compliance cost is the one that bites.

When buying is the clear call

Build when a capability is core to your differentiation and nothing fit-for-purpose exists. A referring-physician portal is neither: it's a standard, compliance-heavy capability with proven options. The thing to evaluate when buying isn't features so much as fit — does it run under your controls, work with your EMR, and match your HIM workflows? See standalone vs EHR-native referrals and the vendor questions in what a community physician portal is.

Where this fits at Bluefish

HealthPoint is the bought option done the low-risk way: identity verification, row-level audit, break-the-glass governance and HIM onboarding are built in, it's standards-based (HL7 v2 / FHIR), and it runs in your environment rather than exporting your data.

Frequently asked questions

What does it take to build a referring-physician portal in-house?: More than a login screen over your data. You'd own automated identity verification of outside practices (NPI, exclusion lists, sanctions checks), row-level role-scoped access so each physician sees only their own patients, comprehensive PHI audit logging, break-the-glass governance, interoperability with your EMR (HL7/FHIR), onboarding workflows for HIM, and ongoing security and support. Each of those is a project in itself.
Why is the audit and access-control part so hard?: Because it's PHI going to people outside your organization. Every access has to be scoped to the right patients and logged at the row level, identities have to be verified and re-verified, and emergency access has to be governed and separately audited. Getting this slightly wrong is a compliance incident, not a bug — which is why it tends to consume far more effort than the visible UI.
When does building make sense?: Rarely, for this specific capability. Building can make sense when a need is core to your differentiation and nothing fit-for-purpose exists. A referring-physician portal is neither — it's a well-defined, compliance-heavy capability that several proven systems already provide, so building usually means re-creating solved problems at your own risk and cost.
What's the hidden cost of buying?: Mostly integration and governance fit: making sure the portal works with your EMR, runs under your controls, and matches your HIM workflows. A portal that's standards-based and runs in your environment minimizes that — you're adding a governed access layer, not exporting your data to someone else's cloud.