Functional Medicine Patient Portals: A Clinic Checklist for Plans and Follow-Up

A patient portal can make an approved plan easier to find, but the interface alone does not tell a clinic whether the workflow is controlled. A useful evaluation follows the work beyond “the member can log in”: which plan is current, who owns a question, where the response is recorded, what remains unresolved, and—when another person is involved—whose account and authority are being used.

Delegated access is common enough to test explicitly. A July 2025 ASTP/ONC data brief reported that the measured share of individuals who accessed online medical records or a portal for someone they cared for or represented rose from 24% in 2020 to 51% in 2024. The survey wording and comparability notes matter, so that figure should not be read as the adoption rate for any specific clinic or product. It does, however, make delegated access a workflow worth testing rather than a feature to accept on a slide.

The checklist below is for functional-medicine clinic leaders evaluating how a member-facing portal handles a clinician-released plan, a member question, team follow-up and the boundary with the clinic’s source systems. It is a procurement and workflow-observation tool, not legal advice, a clinical protocol, or a statement that HolistiCare—or any other vendor—supports the capabilities described.

Start with the portal boundary, not the feature list

A portal is a delivery and interaction surface. It may show selected information, collect questions or forms, and notify a team. That does not automatically make it the authoritative record for the plan, the final response, access authority or follow-up state. HHS describes a portal as one possible route through which an individual may obtain health information; it does not prescribe one universal portal architecture.

Before a demo, write down the clinic’s intended boundary in plain language:

• Member view: What information should the member see, and what is intentionally absent?
• Authoritative source: Which named system or record determines the current clinician-released plan?
• Interaction record: Where does a question, form, upload or reply first exist?
• Write-back: What moves to another system, by what route, and who reconciles a failure or mismatch?
• Ownership: Which role responds, who can escalate, and what evidence closes the item?
• Access authority: Is the actor the member, a legally authorised personal representative, or another family member or caregiver involved under a different basis?

This boundary also prevents a common buying error: treating “available in the portal” as “complete in the record.” Ask the presenter to name the source for each displayed element and to demonstrate what happens when the portal and that source disagree. For a related view of the upstream transition from clinician review to member delivery, see the post-approval care-plan handoff checklist. It addresses handoff; this article owns the later member-question, team-response and record-reconciliation workflow.

Trace one fictional workflow end to end

Do not use live patient data or ask the vendor to improvise around a customer story. Create one fictional member, one clinician-released plan and one ordinary follow-up question. The objective is to preserve identity, version, ownership and state as the workflow crosses interfaces.

1. Release: A qualified clinician releases fictional plan P-17 v3. The previous v2 should no longer appear current.
2. View: The member signs in and opens the plan. Record the plan ID, version, release date and any current/superseded label visible on screen.
3. Question: The member asks a question from the context of one plan action. Capture whether the question retains the plan reference.
4. Triage: A named team role receives it. Observe assignment, response target, escalation route and what happens if nobody acts.
5. Reply: The team responds. Confirm whether the reply is informational, administrative or clinical, and which role is permitted to send it.
6. Record: Follow the final disposition to the clinic’s named source. If a summary is copied elsewhere, inspect the destination and reconciliation evidence.
7. Close: Confirm what changes the item from open to closed, who can reopen it, and whether the audit evidence identifies the actor and time.

The result should be an evidence trail, not a confident narration. A displayed screen can demonstrate display; it cannot establish an unseen integration, a policy-controlled escalation, or a revocation outcome. Record each substep as Demonstrated, Described or Not verified.

Use one evidence matrix for the whole demo

Use the same fields for the core portal workflow and for any conditional proxy-access module. “Not applicable” and “Not verified” are valid observations; a blank cell is not. The matrix must retain the exact evidence locator so a later reviewer can reproduce the observation.

For every substep, record: scenario/event; member view or action; care-team owner and response; source of truth; write-back destination and reconciliation owner; permission or authority and verifier; state, version, exception, unresolved item or escalation; conditional delegate identity, separate account, scope, dates, revocation, attribution and audit; exact evidence locator; verification status; and the accountable follow-up owner and next check.

Fully filled fictional sample: one procurement scenario with mixed evidence status

Required field	F1a — member views released plan	F1b — member asks about an action	F1c — spouse submits administrative follow-up	F1d — spouse access is revoked
Scenario, substep and fictional member ID	Scenario F1; substep F1a; fictional member M-104 views released plan P-17 v3.	Scenario F1; substep F1b; fictional member M-104 asks about one action in P-17 v3.	Scenario F1; substep F1c; fictional delegate D-22 acts for fictional member M-104.	Scenario F1; substep F1d; fictional member M-104 requests removal of delegate D-22.
Member view or action	View current plan ID, version and release date.	Send a question from the displayed plan.	Submit a fictional, nonclinical administrative form.	Member requests revocation; delegate retries access.
Care-team owner and response	Program coordinator routes questions; clinician owns plan content.	Triage nurse is described as first owner; clinical escalation and closure target are not shown.	Program coordinator reviews; clinical criteria are deliberately outside the fictional case.	Privacy/operations owner; response target is undefined.
Source of truth	Clinic-defined care-plan record; actual system is not supplied.	Portal thread plus a clinic-defined clinical record; authority between them is unresolved.	Portal form response; no authoritative destination is named.	Clinic access register should be named during the demo.
Write-back and reconciliation	No write-back is observed; destination and reconciliation rule are unknown.	Presenter says a summary is copied to another system; route, failure handling and reconciliation are not evidenced.	Write-back destination is not verified.	Revocation should reconcile across portal access and any external identity system; route is unknown.
Permission, authority and verifier	Member’s own account; identity process is described only.	Member’s own account; messaging permission is visible in a menu only.	Fictional invite; spouse relationship is asserted, while authority basis and verifier are not demonstrated.	Member request subject to applicable law and clinic policy; verifier is not identified.
State, version, exception and escalation	Example plan P-17 v3 is labelled current; v2 is expected to be superseded.	Question remains open; escalation rule and closed-state evidence are absent.	Form version F-2 is displayed; access start, end and review date are absent.	Revocation requested; effective time, denial result and exception handling are unverified.
Delegate identity, relationship and separate account	Not applicable; the member uses their own account.	Not applicable; the member uses their own account.	Fictional delegate D-22; spouse relationship asserted but not verified; separate account is described, not demonstrated.	Fictional delegate D-22; spouse relationship remains asserted; separate-account state is not verified during the retry.
Allowed data, allowed actions, access start, end and review	Member may view P-17 v3; delegated data/actions and delegated-access dates are not applicable.	Member may submit a plan-context question; delegated data/actions and delegated-access dates are not applicable.	Plan view and administrative-form submission are described; other data/actions are not verified. Start, end and review dates are not supplied.	Previously claimed plan-view/form-submit scope is not verified. Start, end and review dates are not verified.
Revocation result, actor attribution and audit evidence	Revocation is not applicable. Screen attributes the view to member M-104; audit actor, time, action and outcome are not verified.	Revocation is not applicable. Message attribution to member M-104 is described; audit actor, time, action and outcome are not verified.	Revocation result is not applicable at this substep. Attribution to D-22 and audit actor, time, action and outcome are not verified.	Revocation denial result, attribution of the retry to D-22, and audit actor, time, action, outcome and evidence are all not verified.
Notification recipient	Plan-release notification to member M-104 is not verified.	Triage role is described; exact notification recipient is not verified.	Program coordinator is described as recipient; actual notification recipient is not verified.	Privacy/operations role is described; revocation-confirmation recipient is not verified.
Export and termination behaviour	Plan export content and behaviour at account or contract termination are not verified.	Message export and behaviour at account or contract termination are not verified.	Delegate-attributed form export and delegate-access termination behaviour are not verified.	Post-revocation denial, evidence export and contract-termination behaviour are not verified.
Observation and exact locator	Presenter shows fictional P-17 v3 page; screenshot F1a-demo-01. No source-record comparison.	Verbal explanation F1b-note-01; no completed message or destination screen.	Explanation F1c-note-01; no submitted-response screen.	No revocation screen or denial test; open item F1d-open-01.
Verification status	Demonstrated for displayed page only.	Described	Described	Not verified
Follow-up owner and next check	Operations lead compares displayed ID/state with the named source using synthetic data.	Clinical operations lead runs synthetic triage, escalation, reply and closure.	Privacy/operations lead verifies authority, submits the synthetic form and inspects attribution/audit evidence.	Privacy lead performs revocation, retries access and exports the audit evidence.

This sample is invented. It is not patient data, a customer story, a HolistiCare demonstration or evidence that a product supports any listed capability.

Test the plan, question and follow-up as connected states

Make the current plan unambiguous

A portal should not force the member or team to guess which plan governs today’s action. Ask the presenter to show the clinician-released marker used by the clinic, the plan identifier and version, the release date, and how a replaced plan is labelled. HL7 FHIR R5 CarePlan is useful as a design reference for lifecycle and replacement questions, but it does not define a generic “approved” status. “Clinician-released” in this checklist is therefore a local workflow label, not a universal legal or technical status.

Also test the transition: release v4 using invented data, refresh the member view, and inspect what happens to v3. Can a historic message still point to the version the member actually saw? Does a download carry enough version information to distinguish it later? A feature page about personalised holistic plans can provide product context, but it does not prove the portal states in this checklist; those require direct demonstration.

Keep the question attached to context

Open a question from a specific action, then examine what the receiving team sees. The evidence should answer:

• Does the question retain the member, plan and version context?
• Is the original actor distinguishable from a delegate?
• Is the first owner a named role rather than “the team”?
• What target applies to administrative and clinical responses?
• What visibly changes when the item is escalated, waiting, resolved or reopened?
• Where is the final disposition recorded, and who reconciles a failed write-back?

There is no universal external rule for a clinic’s response target or escalation model. Define these locally and ask the product to demonstrate them. Do not turn a vendor’s notification into proof of clinical review or closure.

Separate action delivery from clinical approval

The member may receive practical tasks after a plan is released, while the clinic retains clinical authority. Keep that division visible in labels, permissions and escalation. The comprehensive action-plans feature page is an internal navigation link, not evidence that proxy, write-back, versioning or audit controls are present in the evaluated workflow.

Add a proxy or caregiver module only when the use case needs it

“Caregiver,” “family member” and “personal representative” are not interchangeable legal categories. HHS explains that a personal representative’s authority is determined under applicable law and may be broad or limited. A signed request to send a copy of information to another person under 45 CFR 164.524 is also not, by itself, proof of an ongoing portal account or standing proxy authority.

When delegated access is relevant, extend the synthetic demo with a separate account and test:

• Purpose and authority: Why is access needed, what is the authority basis, who verifies it and where is that decision recorded?
• Identity: Does the delegate use a separate secure login, or are credentials shared?
• Scope: Which data classes and actions are allowed—view, download, transmit, message, form submission, scheduling or payment?
• Time: What are the start, review and end dates? What happens when authority changes?
• Attribution: Can a reviewer distinguish a member’s message from a delegate’s message or form response?
• Revocation: Does access stop at the expected time across the portal and any linked identity service?
• Evidence: Does an export identify the actor, action, time, outcome and affected item?

ASTP/ONC implementation guidance recommends separate secure logins, configurable access and attribution for caregiver workflows. Treat that as a useful design benchmark, not a universal rule that decides authority. Route minors, limited authority, sensitive information, suspected coercion or endangerment, guardianship questions and jurisdiction-specific exceptions to the clinic’s documented policy and qualified reviewer. Do not improvise a universal answer during a product demo.

Ask for security and source-system proof without turning standards into product claims

For a U.S. HIPAA-regulated deployment, HHS technical-safeguards materials support evaluating unique user identification, authentication, role-appropriate access, integrity controls, session controls and auditable activity. HIPAA is technology-neutral; the checklist should not claim that one named product or implementation is universally required.

Use recognised standards to sharpen questions:

• Authentication: Ask the vendor to map its options to the clinic’s risk assessment. NIST SP 800-63B-4 can provide an authentication benchmark, including phishing-resistant options at applicable assurance levels. Do not state that the 2024 HHS Security Rule proposal is final law or that current HIPAA universally mandates MFA.
• Scope and effective period: HL7 FHIR R5 Consent can inform questions about permit/deny scope, actor, purpose, period, status and verification. It is a Trial Use design reference, not proof of implementation.
• Audit and provenance: FHIR AuditEvent and Provenance can inform evidence fields for actor, action, time, outcome and how a record reached its state. Ask to see the product’s actual implementation.
• Cloud responsibility: Where a cloud service creates, receives, maintains or transmits ePHI on behalf of a covered entity or business associate, verify the applicable business-associate agreement and responsibility split. A BAA alone does not prove security, compliance, availability, recovery or correct configuration.
• Non-HIPAA products: Do not assume a consumer health app has no federal obligations simply because HIPAA does not apply. The FTC’s Health Breach Notification Rule may be relevant to some products and services.

The system-boundary demonstration should show more than a login. Ask for a synthetic export or report covering sign-in, access grant/change/revoke, view/download/transmit, message/form submission and plan-version change. Then compare the actor, item and time with the portal screen and the clinic’s named source. A standards label, certification-style badge or security questionnaire does not replace this observed evidence.

Use buyer questions and red flags to reach a bounded decision

Questions to ask in the workflow demo

1. Which record is authoritative for the clinician-released plan, and which fields are only copied to the portal?
2. How does the member distinguish the current plan from a superseded version?
3. What context follows a member’s question to the receiving role?
4. Who owns first response, escalation and closure for each question type?
5. What is written back, to which system, and how is a failed or duplicate write reconciled?
6. When another person acts, how are identity, authority, scope and attribution preserved?
7. Can the clinic demonstrate review, expiry and revocation with synthetic accounts?
8. What audit evidence can the clinic export, and what does it omit?
9. Which security controls are product capabilities, which require configuration, and which remain the clinic’s responsibility?
10. What happens to data, access and audit evidence at contract termination or migration?

Red flags

• Shared member and caregiver credentials.
• “Current plan” with no stable ID, release state or superseded marker.
• Questions routed to a generic inbox with no accountable owner or unresolved state.
• Integration described without a destination screen, failure case or reconciliation owner.
• Full proxy access as the only option, regardless of purpose or duration.
• Delegate activity displayed as if the member performed it.
• Revocation described but not tested through a subsequent denial.
• Claims of “HIPAA certification,” or a BAA presented as sufficient proof of security.
• A standards reference used as evidence that the product implements the standard.
• A demo that needs real patient data to appear complete.

References

Sources and destination pages were rechecked on 6 October 2026. The HHS individual-access destination returned an automated-retrieval error, while the HHS Personal Representatives page and the other official destinations loaded. The bounded access claim also remains supported by the current eCFR text and related official material. Buyers should confirm the current text before treating any legal or security point as settled.

1. ASTP/ONC, Individuals’ Access and Use of Patient Portals and Smartphone Health Apps, 2024.
2. HHS OCR, Individuals’ Right under HIPAA to Access their Health Information.
3. HHS OCR, Personal Representatives.
4. Electronic Code of Federal Regulations, 45 CFR 164.524.
5. ASTP/ONC, Patient Engagement Playbook, Chapter 5: Allow portal access for caregivers.
6. HHS OCR, Security Standards: Technical Safeguards and The Security Rule.
7. NIST, Special Publication 800-63B-4: Authentication and Authenticator Management.
8. HHS OCR, HIPAA Security Rule Notice of Proposed Rulemaking.
9. HHS OCR, Guidance on HIPAA and Cloud Computing.
10. Federal Trade Commission, Health Breach Notification Rule: The Basics for Business.
11. HL7 FHIR R5, Consent, CarePlan, AuditEvent and Provenance.