Patient Visit Advocate compliance-gap-review
internal prototype · canonical JSON + Dreamborn Forge HTML
internal generated
compliance-gap-review · supabase_json

Patient Visit Advocate compliance-gap-review

Existing Patient Visit Advocate artifacts already establish broad no-diagnosis and no-treatment boundaries, but the client-provided Pocket Advocate documents add launch-blocking Q&A-specific requirements that must be promoted into M-00, policy, data model, UX, and implementation plan before public content work.

Planning Surface

Use this to decide what happens next.

Status

approved

Agent Handoff
Start Here

Existing Patient Visit Advocate artifacts already establish broad no-diagnosis and no-treatment boundaries, but the client-provided Pocket Advocate documents add launch-blocking Q&A-specific requirements that must be promoted into M-00, policy, data model, UX, and implementation plan before public content work.

Completion Evidence

No explicit evidence field yet. Require tests, screenshots, linked PRs, or reviewed outputs before marking complete.

Artifact Shape
  • product: Pocket Advocate / Patient Visit Advocate
  • summary: Existing Patient Visit Advocate artifacts already establish broad no-diagnosis and no-treatment boundaries, but the client-provided Pocket Advocate documents add launch-blocking Q&A-specific requirements that must be promoted into M-00, policy, data model, UX, and implementation plan before public content work.
  • created at: 2026-05-07T13:22:15.478Z
  • project id: 31d7f681-bed2-44e9-9a55-b9fadcbba0da
  • review type: client-compliance-gap-review
  • schema version: 1.0
  • source artifact: client-source-reference
  • verification risks: 3 items
  • recommended next action: Update M-00, policy, architecture, feature UX spec, and plan to reference client-source-reference before approving any implementation or worker dispatch.
  • required artifact updates: 5 items
  • aligned existing boundaries: 5 items
  • implementation acceptance criteria: 7 items
Structured Payload

Machine-readable source fields

product

Pocket Advocate / Patient Visit Advocate

summary

Existing Patient Visit Advocate artifacts already establish broad no-diagnosis and no-treatment boundaries, but the client-provided Pocket Advocate documents add launch-blocking Q&A-specific requirements that must be promoted into M-00, policy, data model, UX, and implementation plan before public content work.

created at

2026-05-07T13:22:15.478Z

project id

31d7f681-bed2-44e9-9a55-b9fadcbba0da

review type

client-compliance-gap-review

schema version

1.0

source artifact

client-source-reference

verification risks
idrisknext step
VR-001Workbook summary says 1,000+ Q&As, but direct extraction observed 253 nonempty master rows.Verify whether rows are hidden, generated, omitted, or represented across sheets differently before sizing ingestion work.
VR-002Existing artifacts describe AI-first visit prep, while the new XLSX is a static Q&A knowledge base.Decide whether Q&A library is a separate content surface, a support layer for dynamic question generation, or the MVP itself.
VR-003Client guide says attorney review will provide definitive guidance; current document is internal pre-review guidance.Treat these as current build boundaries but keep legal-final signoff as a release gate.
recommended next action

Update M-00, policy, architecture, feature UX spec, and plan to reference client-source-reference before approving any implementation or worker dispatch.

required artifact updates
targetupdateseverity
policyAdd explicit rules for no universal clinical thresholds, no directive clinical verbs, no drug names as answer-text recommendations, no emergency thresholds/time windows, and no unqualified comparative effectiveness claims.blocking_before_public_qna_launch
module-spec/M-00 Safety and Product BoundaryPromote the client developer reference into official project source material and make the four structural changes mandatory acceptance criteria.blocking_before_build_approval
feature-ux-specAdd Q&A card persistent non-dismissible disclaimer footer using exact client text; add first-launch onboarding disclaimer with acknowledgement; add Settings > Legal access.blocking_before_qna_card_ui
architectureAdd content schema support for Questions to Ask Your Provider, coverage cluster tagging, per-card disclaimer rendering, onboarding acknowledgement timestamp, and source-file audit metadata.blocking_before_knowledge_base_ingestion
planAdd tasks for source-file verification, Q&A import/normalization, compliance linting, disclaimer UI, onboarding legal screen, and coverage recency caveat banner.blocking_before_dispatch
aligned existing boundaries
  • No diagnosis or treatment recommendations.
  • Questions should be framed for clinician discussion.
  • Serious disclosures should trigger conservative escalation language without precise triage.
  • Structured user-corrected memory should be preferred over raw chat logs.
  • Legal/medical review is required before provider-facing or clinical efficacy claims.
implementation acceptance criteria
  • All Q&A records use the provider-question section heading, not What to do or ask.
  • Every expanded Q&A card renders the exact persistent disclaimer and it cannot be dismissed or collapsed.
  • First launch requires acknowledgement of the exact onboarding disclaimer before accessing content.
  • Coverage clusters render the exact recency caveat banner.
  • A content lint/check script flags directive clinical language, universal thresholds, drug recommendations in answer text, emergency triage thresholds, diagnosis implications, and unqualified comparative effectiveness claims.
  • Knowledge-base import records source filename, sheet name, row ID, wave, cluster, category, revised flag, and import timestamp.
  • The workbook row-count discrepancy is resolved before treating the file as a complete 1,000+ Q&A source.