Glossary & Open Questions
Glossary & Open Questions
Section titled “Glossary & Open Questions”Who this is for: anyone reading this wiki who runs into an internal term, plus engineers/agents translating between the two.
Glossary (code shorthand → plain-language meaning)
Section titled “Glossary (code shorthand → plain-language meaning)”| Shorthand | Plain-language meaning |
|---|---|
| Patient portal | The patient-facing website/app |
| Care portal | The internal staff back office (admin, provider, care team, printer) |
| Task | A case — one purchased service being processed for one patient |
| Task type | The specific service a case is for (e.g. “Placard”, “Med Card”, “Tinted Window”) |
| Task tag | A sub-classification of a case, e.g. “New” vs. “Returning” (add-on), or a doctor’s-note reason (Work/School/Travel/Other) |
| Task status | Where a case currently sits in its lifecycle (unscheduled, scheduled, under review, ready for packaging, completed, refunded, etc.) |
| brandCode | The identifier that says which branded product a record belongs to, in a platform that runs multiple brands from one codebase |
| Service configuration | The per-brand/state/service/tag settings profile that controls price, appointment requirements, and processing flags |
| Service | A purchasable offering (see Services Catalog chapter) |
| EHR | An internal server-to-server patient/clinical record lookup the patient portal calls into; exact underlying system not confirmed — see open question below |
| Magic link | The one-time emailed sign-in link patients use instead of a password |
| Auth token / auth cookie | The signed session token stored in the patient’s browser after signing in |
| Cross-site auth cookie | The mechanism that lets a login cookie be recognized across the patient portal and other sites on the same root web domain |
| Lucia / session cookie (care portal) | The staff login/session mechanism used in the care portal, separate from the patient portal’s login system |
| Role / sub-role | A staff member’s access level in the care portal (role: admin, provider, or “outsider”; sub-role: doctor, super admin, care-team member, consent coordinator, dispute handler, printer) |
| State-forms / tinted-state-forms / prescription-forms | The per-state form-filling logic for placard-style certifications, tinted-window exemption certificates, and prescriptions respectively |
| Multi-form state | A state that supports more than one official form variant for the same service (e.g. placard vs. license plate) |
| generate-med-card | The main internal route that orchestrates filling, signing, and producing all documents for a case, despite its name applying to more than just medical marijuana cards |
| No-signature route | A variant of document generation that produces an unsigned copy of a document; exact trigger conditions not fully confirmed |
| Secure document storage (GCS) | The cloud storage system where every generated document is uploaded and served from |
| Signature capture | The one-time digital capture of a doctor’s signature, reused across every document they sign |
| App Event / dispatchAppEvent | The internal event hub that fans a single occurrence (case paid, appointment booked, etc.) out to email, text, in-app messaging, phone outreach, and CRM sync |
| Thread / thread message | The in-app messaging conversation tied to a case or patient, and an individual message within it |
| Automated phone outreach (Retell) | The AI-driven outbound calling system used for certain patient follow-ups |
| Text messaging providers (Twilio / Telnyx) | The two supported text-message/fax delivery providers, chosen per brand |
| Marketing/CRM sync (GHL) | The sync of patient contact data and marketing tags to an external customer-relationship-management system |
| Secondary notification system (Novu) | A second notification layer used mainly for workflow-triggered, marketing-style patient messages |
| Support webhook | An outbound mirror of every new in-app message to an external helpdesk/support tool |
| Care-team queues | The named work lists (overdue, consent overdue, contacted, unresponsive, incorrect, insufficient, received, reviewed, resolved, faxes, active) that care-team/consent-coordinator staff work from |
| Saved filter / “View” | A named, reusable set of case-list filter criteria staff can save for repeated use |
| Follow-ups | Reminders/nudges attached directly to a case, distinct from scheduled appointment reminders |
| Print-station queues | The named fulfillment work lists (urgent, stamped-needed, hand-sign, remail, tasks) print-station staff work from |
| Post-processing | The step of marking a case’s physical fulfillment complete, which triggers the “documents mailed” patient notification |
| Referral code / ref_code cookie | A patient’s personal referral link identifier, and the 90-day browser cookie used to attribute a new signup to it |
| Referral earning | A pending/confirmed/declined/paid record created automatically when a referred patient’s case is paid |
| Payout (patient payouts) | The mechanism (currently an Amazon gift card) used to pay out both referral earnings and review-participation rewards |
| Guides | Admin-authored landing pages that bundle multiple services into a themed marketing page |
| Upsell / add-on | An additional related service offered to a patient at specific moments in their case journey |
| Coupon | A brand-scoped fixed or percentage discount code |
| Discover | The pre-signup quiz where a visitor shares records/conditions to see which services they may qualify for, before creating an account |
| Agreement document | A reusable, macro-filled template (e.g. treatment consent) generated and signed per patient, distinct from the final government/medical document |
| Release-of-records request (medicalRecordRequests) | A signed authorization letting the platform request a patient’s existing medical records from an outside clinic on their behalf |
| Doctor medical license | A per-doctor, per-state/country record tracking license number, expiration, and issuing body, used to determine where a doctor can be assigned cases |
| Support webhook / helpdesk mirror | The real-time mirror of every new in-app thread message out to an external helpdesk tool |
| Crisp | The live-chat/support-widget tool that can have tickets created for it by the platform’s automated systems |
| Browser extension (packet-queue / task-details) | A separate staff-side browser extension that calls two dedicated care-portal endpoints to route a case into a print-station queue or pull its details inline |
| External partner API (v1/external) | A dedicated set of care-portal endpoints for outside systems (primarily the automated phone outreach assistant) to look up patients/cases and act on them |
| Guide | An authored, approvable landing page that bundles multiple services under one theme for patients to browse |
Open questions (things this wiki could not confidently confirm)
Section titled “Open questions (things this wiki could not confidently confirm)”- EHR lookup mechanism — the underlying system/vendor behind the patient portal’s server-to-server clinical/patient record lookup was not confidently identified. (Confirmed: the same
EHR_URL/EHR_TOKENconnection is also what powers the Discover eligibility-quiz analysis and patient file uploads — see Pre-Signup Eligibility Check — but the underlying system behind that URL is still unconfirmed.) - Calendar/booking technology — confirmed the patient-facing booking flow is fully custom-built and does not call an outside calendar product. A legacy webhook route and database fields referencing a third-party scheduling tool (“Cal.com”) still exist in the care portal but were confirmed to be unused by the current booking system.
- Referral cookie cleanup bug — prior documentation suggests the referral-attribution cookie may not be fully cleared after signup due to a cookie-name mismatch; not independently re-verified here.
- No-signature document trigger — the exact conditions under which an unsigned document variant is generated instead of a signed one.
- Multi-form variant selection logic — beyond a doctor’s manual choice, what (if anything) automatically determines which form variant applies for multi-form states.
- Coupon usage limits — whether coupon codes have any built-in usage caps (e.g. one redemption per patient), given that a reusable 100%-off coupon can fully bypass the payment processor.
- Brand-level configuration boundary — the complete list of settings that live on a brand’s own record versus the platform-wide settings table.
- Service production status — whether “Utility Discounts” and “Schedule R Tax Credit” are fully live, purchasable services today versus still in limited rollout.
- Physical shipping/carrier mechanism — how printed items are actually shipped to patients (carrier, label provider) was not confirmed.
- Discovery/AI matching logic — the exact AI model/method used to analyze uploaded medical records into matched condition tags for the Discover quiz was not confirmed beyond “an AI-assisted analysis step.”
- Referral earning claw-back on refund — whether a refund after a referral earning is already auto-confirmed by the background job triggers any automatic reversal, or requires manual admin action.
- License-expiration enforcement — whether an expired doctor medical license automatically blocks new case assignments in that state, or is a manual admin responsibility today.
- Browser extension’s own codebase — its full feature set lives in a separate repository not reviewed here; only its two care-portal API endpoints were confirmed.
- Internal API key vs. server-to-server token boundary — why some External Partner API endpoints require one pre-shared key and others require a different one wasn’t fully explained in the code.
- General FAQ/help-center content — no help-center section distinct from the “Guides” feature was found in either portal.
Where this comes from
Section titled “Where this comes from”Every chapter in this wiki has its own “Where this comes from” section citing the specific files used. This glossary aggregates terms encountered across all of them, plus the following documents used specifically to identify jargon and historical-vs-current framing:
parkingmd-care-portal/docs/care-portal-kt-guide.mdparkingmd-care-portal/docs/forms-architecture-blueprint.md(historical/proposed — used only to identify terms, not as current-state fact)parkingmd-care-portal/docs/MULTI_FORM_SYSTEM.mdparkingmd-patient-portal/documentation/service-flow.mdparkingmd-patient-portal/documentation/add-new-service.mdparkingmd-patient-portal/documentation/routing.mdparkingmd-patient-portal/documentation/referral-system.mdparkingmd-patient-portal/documentation/cross-site-auth-cookie.mdparkingmd-patient-portal/documentation/design.mdparkingmd-patient-portal/src/config.ts