Building a Patient-Portal SaaS: Access, Privacy by Design, QA

Build a patient-portal SaaS so that access control, audit logging and data minimisation are in the first feature, not retrofitted later. Access is by relationship, not only role: a clinician reaches their own patients, a patient only their own record. Log every access, collect the least data you need, and test all of it. Whether it meets HIPAA, GDPR or another regime is a legal question for your adviser.

This is general engineering information, not compliance or legal advice; confirm your obligations with your compliance adviser, and pair any build with a compliance partner. If you would rather have it built and tested for you, see how RAITHub would build this below.

What should go into the first release?

The parts that are slow and risky to retrofit once real patient data has arrived: the access model, the audit log and consent. Features can wait; foundations cannot. This is the same reasoning behind a well-built multi-tenant SaaS, where isolation and roles ship first, as set out in multi-tenant SaaS development.

Foundation	Why it goes first	How you prove it
Relationship-based access	Retrofitting it means re-checking every endpoint later	A role-and-relationship matrix, tested at the API
Append-only audit log	You cannot reconstruct who saw what after the fact	A write and a change produce entries that cannot be edited
Consent model	Uses of data depend on it from the first feature	Covered use allowed, uncovered use refused, withdrawal effective
Data minimisation	Every extra field is extra risk and extra deletion work	The schema holds only what a feature needs
Transport and secrets	Fixing leaks after launch means rotating live secrets	TLS everywhere, no sensitive data in logs, secrets out of the repo

What does access by relationship mean?

In most SaaS, access is a role: an admin can do admin things. In a patient portal, a clinician's role is not enough; the system must also know the clinician is treating that patient. Model the relationship explicitly, and scope every query by it. Broken access control is A01, the top risk, in the OWASP Top 10:2025, and relationship bugs are the version health apps ship most.

• Store the care relationship as data (assignment, care team, episode), not as an implicit "any clinician can read".
• Scope every read and write to the acting user's relationships, enforced in the database or the API, never only the screen.
• Default to deny: a new endpoint returns nothing until a relationship permits it.
• Give break-glass access, if you need it, its own path that is heavily logged and alerts.

How do you design the audit log?

A patient portal needs a trustworthy record of who accessed what. Make it append-only so it cannot be quietly rewritten, and record the actor, the record, the action and the time. A hash-chained design, where each entry includes a hash of the previous one, makes tampering detectable; the pattern is in designing an audit log customers trust. Log failed access attempts as well as successful ones, and keep the log free of data it does not need, such as full record bodies where an identifier would do.

What should you build, and what should you rent?

Build the parts that are specific to your product and its access rules; rent the commodities. This keeps scope down and reduces the surface you have to secure yourself.

Capability	Buy / rent	Build
Authentication and sessions	A managed auth provider for login, reset and sessions	Your relationship-based authorisation on top
Payments	A payment provider's hosted checkout or hosted fields	Your booking and billing logic, tested
Clinical data exchange	An EHR or FHIR partner's API where interoperability is required	The integration and its contract tests
Access model and audit	—	Both, because they encode your product's rules
Consent and data rights	—	The logic; your adviser sets the requirements

On interoperability, RAITHub has built and contract-tested REST APIs, which is adjacent experience; FHIR work on your project would be new, scoped against your EHR partner's version and profiles. The intake side (digital forms, consent capture, e-signature) is covered in patient intake software, and a wider build guide is telemedicine platform development. This post is about the portal's access and privacy foundations and proving them.

How do you test a patient portal before launch?

Prove the foundations, not just the features. Test the access matrix with two accounts per role and per relationship, through the API; OWASP calls the cross-record case broken object level authorization (OWASP API1:2023).

• A patient reads only their own record; a clinician reads their own patients and is refused another clinician's.
• No user can escalate their own role or attach themselves to a care relationship.
• Audit entries are written for reads and changes and cannot be edited through the API.
• Consent governs data use, and withdrawal takes effect on the next request.
• Export returns only the right patient's data; deletion leaves nothing behind where policy requires.

The full access test plan is in testing login, roles and data access, and the HealthTech-specific QA plan is in testing a HealthTech app before launch.

Buy, build or hire this?

Option	Choose this when	Trade-off
A certified patient-portal or EHR product	You need a vendor that already carries certifications and attestations	Fast to adopt; you fit their model and licensing, and customise little
No-code or a template	You are validating demand with non-sensitive data only	Not suitable once real patient data is involved; access control is too limited
Build in-house	You have engineers who know access control and a compliance partner	Full control; slower, and the access model is easy to get wrong
A custom build with a studio, plus a compliance partner	You need a product-specific portal built with privacy by design and tested	An outside dependency; the studio builds the engineering, not the compliance attestation

A focused first release, built to production standard, typically takes 4 to 6 weeks at a fixed scope; a data model and integration-heavy backend sits nearer 6 to 12 weeks. Building the access model yourself is realistic only with engineers who have done relationship-based access before.

Why RAITHub for this

• Access control and audit are everyday work. Sundor Skin runs 146 PostgreSQL tables under row-level security with a hash-chained audit log and 530+ tests; PropDesk has 4 roles and 1,024 tests. RAITHub has built a healthcare scheduling app for a client.
• Privacy by design, then proven, with access tested at the database, the API and the screen, gated in CI.
• Honest limits. This is engineering, not compliance. RAITHub has not shipped a regulated health product, is not SOC 2 or ISO 27001 certified, does not decide whether a BAA is needed, and has not integrated FHIR; that would be new work. Confirm obligations with your compliance adviser.

When you don't need us

• You are buying a certified product and only need it configured.
• You have engineers experienced in relationship-based access and a compliance partner.
• You need a certified assessment or a BAA, which require a certified vendor and your adviser.

How RAITHub would build this

• Scope: the access model, the audit log, consent and the first workflow, agreed in a signed architecture spec after a free 15-minute call.
• Build: relationship-based access enforced in the database and the API, an append-only audit log, data minimisation, and the first patient-facing workflow, with weekly demos.
• Test: the access matrix and audit behaviour gated in CI, plus the pre-launch QA plan above.
• Timeline: typically 4 to 6 weeks for a focused first release at a fixed scope; integration-heavy work 6 to 12 weeks.
• What you receive: the product on accounts you own, tests and CI, handover runbooks, and full IP; an NDA is standard. Compliance is handled with your partner, not claimed by RAITHub.

The next step is a free 15-minute audit, then a written fixed quote. See SaaS development, QA as a Service, and the HealthTech industry page. To start, book the audit.

General information only; confirm compliance obligations with your adviser. Documentation checked on 10 October 2026.

Frequently asked questions

What does privacy by design mean for a patient portal?

Building access control, audit logging, consent and data minimisation into the first feature rather than adding them later. In practice it means access is scoped by the clinician-patient relationship, every access is logged, and the schema holds only the data a feature needs.

Why is role-based access not enough for a health app?

Because a clinician's role does not say which patients they treat. The system must model the care relationship and scope every query by it, so a clinician reaches their own patients and is refused others. Test the refuse cases explicitly.

What should you build versus rent in a patient portal?

Rent commodities such as authentication, payments and, where needed, EHR or FHIR exchange. Build the parts that encode your product's rules: the access model, the audit log and the consent logic. That keeps scope and the security surface smaller.

Can a patient portal be HIPAA compliant out of the box?

No. Compliance is an obligation on your organisation, decided with a compliance professional, not a property of the software. Good engineering supports a programme; it does not replace an adviser or a certified assessment. Confirm your obligations with your adviser.

How long does it take to build a patient-portal SaaS?

A focused first release built to production standard typically takes 4 to 6 weeks at a fixed scope; an integration-heavy backend sits nearer 6 to 12 weeks. The access model and audit log should be in that first release, not a later sprint.

Has RAITHub shipped a regulated health product?

No. RAITHub has built a healthcare scheduling app for a client and has not shipped a regulated health product, nor integrated FHIR. For a regulated build, pair RAITHub's engineering with a compliance partner and a certified assessor.